AIこんにちは。SCSKの松渕です。 先日、発表されたばかりの Google Antigravity を インストール＆簡易WEBサイト構築 してみましたが、 今回はもう少しアプリ開発をしてみた実体験をブログに書きます！ はじめに Antigravityとは AWSのKiroと同様に、 AIエージェント型統合開発環境（Agentic IDE） と呼ばれるものです。 Antigravityのポイントとしては、特に以下の点になるかと思っております。 　・ AIによる ブラウザ操作も可能 　・ AIによる 自律的な実装 　・ アウトプット品質の高さ （これはGemini 3のポイントではありますが） ・ Google Cloud環境とのシームレスな連携 類似サービスとの比較は以下の通りです IDE/プラットフォーム 開発元 主な設計思想と特徴 類似サービスとの差別化ポイント Antigravity Google エージェント・ファースト 。AIが自律的にタスクを計画・実行・検証する。 マルチエージェント によるタスクのオーケストレーション。 自律性のレベル と End-to-End （ブラウザ操作を含む）実行能力。開発の 監督 に特化。 Kiro AWS 仕様駆動開発（Spec-Driven Development） 。要件→設計→タスク分解をAIと共同で体系的に進める。 Specモード と Vibeモード 。 開発プロセスの構造化 。ドキュメント（仕様書）を起点とし、 検証可能なコード品質 を重視。エンタープライズ親和性が高い。 Cursor Cursor, Inc. AIアシスタント型IDE 。コードの生成、編集、質問応答を強力にサポートする。AIチャットが非常に軽快で対話的。 AIはあくまで アシスタント であり、線形的なチャットベースの対話が中心。 即応性と軽快さ に優れる。 VS Code Microsoft 広く普及した 高機能なコードエディタ/IDE 。AI機能は 拡張機能 （例: Copilot）として追加される。 AI機能は拡張機能 であり、IDEのコア機能ではない。 今回作るアプリ 私は、ブログを書くとき画面キャプチャ画像をぺたぺた貼り付けることが多いです。 その際行う、以下 2点の加工をするアプリ を作ってみました。 公開すべきではない情報を 黒塗り 処理 注目箇所を 赤枠で囲う 処理   Antigravityへの初回指示だし Antigravityへの指示だしを行います。 Antigravityの環境設定 私の前回のブログ の通り、インストールおよび環境構築を実施いたします。   Agentモードでの指示プロンプト全文 Antigravityを起動し、 「Ctrl + E」でAgentモード起動 します。 以下のようなプロンプトでアプリ開発を指示しました。 ちょっと長くなりますが全文載せます。 # 目的 ブログ用のキャプチャ画像編集プログラムを作成したいです。 やりたいことは2つです。 ①公開すべきではない情報を黒塗りする機能 ②画像の中で、選択するべき項目、クリックする項目、箇所を赤枠で囲う # 動作説明 ##メニュー画面で、①公開すべきではない情報を黒塗りする機能　と　 　②画像の中で、選択するべき項目、クリックする項目、箇所を赤枠で囲うのどちらを利用するか選択する画面を出してください。 ##①の処理 ①-1複数枚の画面キャプチャをインプットとして受け付ける。 　pngもしくはjpegのみの前提でいいです。 　1枚当たり最大500kbとしてください。 　10枚程度想定としてください。 ①-2それらの画面をgeminiにてブログで公開するには公開すべきではない情報を黒塗りする個所を 　画像上のどの部分かを提示してください。 　GoogleCloudのプロジェクトIDやプロジェクト名、GithubのID等は公開したくありません。 　また、写真の場合は人の顔部分を黒塗りにしてください。 　そのほかは、一般的な判断で構いません。 ①-3インプット画像の1枚1枚をユーザが確認して、黒塗りの箇所をOKとするか、黒塗りから戻したり、追加したりなどユーザ側で修正します。 　修正できるようなＵＩをお願いします。 　画像上で、マウスで範囲をドラックすると黒塗り範囲指定できるような仕様をイメージしてます。 ①-4インプット全量の画像で①-3が完了したら、最後に一覧表示して最終確認画面に出します。 ##②の処理 ②-1　複数枚の画面キャプチャ　と、　ブログ文章　をインプットとして受け付けます。 　前提として、技術ブログにおける、システム検証の画面キャプチャをインプット画像となる想定です。 　インプット画像の中で、注目すべき項目と、次の手順に進むためにクリックする項目/箇所を赤枠で囲ってください。 　ブログ文章をインプットにしてください。 ②-2　赤枠で囲う想定の箇所が画像上のどの部分かを提示してください。 ②-3インプット画像の1枚1枚をユーザが確認して、赤枠で囲う箇所OKとするか、赤枠から外したり、追加したりなどユーザ側で修正します。 　修正できるようなＵＩをお願いします。 　画像上で、マウスで範囲をドラックすると赤枠範囲指定できるような仕様をイメージしてます。 ②-4インプット全量の画像で①-3が完了したら、最後に一覧表示して最終確認画面に出します。 # 環境前提 Pythonを想定してますが、環境について提案あれば言ってください。検討できます。 ## 開発環境：PC上 ローカル環境はPC上で、そちらの環境で動作するものをまず作成ください。 これは、簡易的な動作確認用です。 Google AI StudioのAPIキー 　[実際のプロンプトにはキー記載] ## 本番環境：Cloud Run上 他者も利用できるようにGoogleCloud環境上でも動作するようにします。 その際、公開アクセスにはしない下さい。 ## 環境差異 2点だけです。 ①GeminiのAPI呼び出しの方法が変わります。 　PC上ではGoogle AI StudioのAPI使います。 　Cloudrun上では、vertex aiのAPIを使ってgemini呼び出しをしてください。 ②入力/出力ファイルの保存先 　PC上の場合、PCに保存。 　Cloudrun上の場合、GoogleCloudStorageに保存。     実装計画確認 プロンプトを実行すると、実装計画を出力します。 　→　   最初は英語で実装計画出してきたので、日本語で出してというと出してくれます。 実装環境は提案してといった通り、提案してくれてます。   →　     検証計画 も立ててくれており、その中には自動テストの他に手動検証もあります。 つまり、 人間側の検証も計画まで 立ててくれております。 “人間がAIに使われる時代が来る”なんて冗談半分で話題になりますが、これ見るとすこし背筋がぞっとしてきますね。     実装とローカル環境での動作確認 実装開始 実装計画に従って実装の依頼をします。 コンテナで実装するため、Dockerの拡張機能のインストールを依頼されたので、インストールします。 　→　 →     Cloud Runでの実装の前にローカルで動作確認を依頼されました。 すごいのは、 プロンプトで指示していないのに こういった段階テストおよび実装の計画を立ててくれています。     言われるがままテストしてみます。すごい。 画面イメージについて一切指示しなくてもここまで実装 してくれてます。 　→　    Geminiバージョンエラー おっと、画面キャプチャ選んで黒塗り箇所をAIで判断させる処理でエラー出ました。 エラーコードを見ると、もう EOLになっている Gemini 1.5 flashを使おうとしてます 。 Julesの時もありました が、このGeminiバージョンミスは なかなか解消しない もんですね。。 修正依頼出して修正してもらいます。Gemini 3 preview版を使います。 →　  　→　     ローカルでの動作確認完了 このエラーだけでうまくいきました！！ 古いGeminiのモデルを指定された時はヒヤッとしましたが、やはり大幅に進化はしてます！さすがGemini 3ですね。 以下の簡易テストもクリアしました！ ほとんどやり直しなしでここまでとは・・・ 。すごいの一言。 若干黒塗りずれている気もしますが、、そういう時は手動で直す方針とします。 （名前はそもそも公開しているから黒塗りしなくてもいいですし。） 手動での黒塗り箇所修正機能のテスト 編集後画像の一括ダウンロードテスト 赤枠で囲う動作も同様にテスト     Cloud Runでの実装 Cloud Runでの実装を依頼 ローカルでの動作確認は完了したのでCloud Runでの実装を依頼します。 細かい依頼出します。数分でデプロイしてくれました。 　→　   しれっと書いてますが、今回のCloud Runは公開状態にはしたくなかったので非公開にしてます。 ローカルでproxy経由のアクセスということで、 アクセスするための手順まで 何も言わなくとも連携 してくれました。 気が利きすぎますね。   リージョンとサービスアカウントの修正 リージョン指定していなかったら、us-central1での実装になってます。 前回 は自動でasia-northeast1になってたので気にしてませんでした。 前回は、 gcloud CLIのデフォルトリージョンをasia-northeast1（東京）にしていた ので、東京でのデプロイされたのだと思います。今回は、2025/12現在、 Gemini 3のCLIがグローバルエンドポイントのみ利用可能 な状況のためus-centralが適していると、Gemini 3が判断したのかもしれません。（ここは推察） いずれにしても、 リージョンを気にするのであれば明示的に依頼 するべきでしょう。     また、サービスアカウントも社内検証環境ルールに準拠していないので合わせて修正します。 これも単なる プロンプト（指示する側）の不足 であってGemini 3は何も悪くない・・・・。           asia-northeast1（東京）で作成されましたね。   画像提供方式エラーと修正 動作確認していきます。 キャプチャを指定してアップロードしたらエラー出ました。 　→　 　→　       雑に修正依頼出します。文言コピペして投げます。 そしたら、署名付きURLの秘密鍵がないためとのことで、 方式変更してくれました 。 　→　 　→　     タイムアウトエラーとメモリエラー 次にタイムアウトエラーが出たので、同じように雑に投げます。 ※そもそも”10枚前後”って最初に要件（プロンプト）出しておいて、50枚近く投げている私が悪いだけな気もしてます。 　→　   Antigravityは Google Cloudのログなら自律的に確認可能 ですので、「ログ見て」の一言でも分析してくれます！     次にまたエラー発生しました。 雑に依頼したらメモリエラーと分析して、 メモリ増強まで自動で実施 してくれました。 　→　 初期インストール時の設定 で、AIにかなり自律的にお任せの設定をしたので自動でデプロイしております。 どこまでAIに自律的に任せるかは設定可能 です。   動作確認 動作確認していきます。 今度はエラー等出ずに動作 しました！ 赤枠付与のほうも同じように確認しました。 　→　   AIによる黒塗り、赤枠付けは正直期待通りとは言えませんでした 。 が、そこの指示プロンプトも適当ですし、手動で直す機能はイメージ通りで、画像編集効率化の目的は達成されてます。 いったん深掘りしないでＯＫとしてます。     Antigravityでの画像編集アプリ開発した感想 素晴らしい点 高品質で自律的に実施してくれる 正直前回と同じ感想なのですが、 品質のレベルが今までと段違い だと感じました。 若干のエラーはあったものの、感覚で行くと 今までのAIとのやり取りが1/10くらいに減った印象 です。 人間へのフォローまで 人間の検証含めた全体検証計画を立ててくれたり、人が実施する手順のフォローをしてくれたりと、すごいの一言。 もはや怖い領域 に入ってきてますね。 もったいない点 無料枠のクォータが少ない。 Gemini 3が人気すぎて、すぐ利用クォータの上限に引っ掛かります。これは仕方ないのですが。。 最新情報への対応 Gemini1.5 flashを使おうとしてましたね。 最新情報補完するためにインターネットへのグラウンディングは当然されているはずと思いますが、1.5の情報のほうがインターネット上に多いってことでしょうか。まだpreviewなのでGAまでにさらなる品質向上がなされるかもしれませんね！ まとめ 今回のブログでは、GoogleのAIエージェント型IDE「 Antigravity 」と Gemini 3 を使い、複雑な要件を持つ画像編集アプリを開発し、Cloud Runへデプロイする過程をご紹介しました。  AntigravityのようなAIエージェント型IDEは、開発の初期段階からデバッグ、インフラ設定、そしてリソース増強といった 広範な領域を自律的に担当 してくれます。これにより、私のようなインフラエンジニアでも、コードの実装からデプロイまでを非常に高い品質で完結できる時代になりました。 一方で、これは エンジニアの責任が「コードを書くこと」から「AIの出力を監督し、評価すること」へシフトした ことを意味します。 エージェントの自律的なリソース増強（メモリやCPUの変更）が クラウドコストに与える影響 。 エージェントが選択したリージョンやサービスアカウントが 組織のルールに適合しているか 。 これらの セキュリティ や コスト 、 アーキテクチャ といった本質的な観点から、AIの行動を監査し、軌道修正できる能力こそが、これからのエンジニアに最も求められるスキルでしょう。 ぜひ一度 Antigravity を試してみて、この新しい開発の波に乗ってみてはいかがでしょうか。

本記事は TechHarmony Advent Calendar 2025 12/12付の記事です 。 こんにちは。SCSK 中山です。 今回は X1600 LTEモデル を実際に触る機会がありましたので、その詳細なレビューをお届けしようかと思います。 検討にあたりスペックシート上で見たことはあっても、実物や管理画面を直接見たことがある人はまだ少ないかと思います。本記事が、導入を検討されている方々の参考になれば幸いです。 尚、このX1600 LTEモデルは4G/LTEに対応したモデルのため、残念ながら5Gには対応しておりません。 【実機写真で比較】X1600とX1500、見た目の違いはどこにある？ まずは筐体の外観から見ていきましょう。 X1600は、おなじみのX1500と比較すると一回り大きいサイズ感です。 写真の通り、背面のLTE用のアンテナ接続端子が追加されているのが大きな特徴です。設置の際は、このアンテナ部分のスペースも考慮する必要があるかもです。   ▼X1500(上)とX1600(下)の比較   ただのLTE対応じゃない！スペックから読み解くX1600の強み 次に、X1600 LTEモデルの主要なスペックを確認します。 詳細なスペックシートは公式サイトにまとまっています。 Cato Socket Deployment Guides and Data Sheets 特に注目すべきポイントは以下の通りです。 ポート数 : 合計8つのLANポートを搭載。ポート1～4は1Gbps、ポート5～8は2.5Gbpsに対応しているのと、標準でSFPポートを搭載しているため、高速なLAN環境を構築できます。 SIMスロット : 本体背面にSIMスロットを2つ搭載。これにより、物理的なインターネット回線とは別に、モバイル（LTE）回線を利用したCato Cloudへの接続が可能です。 回線冗長化 : 有線回線とLTE回線の2系統を利用できるため、容易に回線の冗長化を実現できます。 対応LTEバンド : X1600 LTEモデルは、日本国内の主要キャリアが利用する周波数帯に幅広く対応しています。技術的な対応バンドの詳細は以下の公式ドキュメントに記載されていますが、日本のキャリアで使われる主要なバンドは網羅されているため、国内であれば基本的にSIMキャリアを選ばずに利用できるのが強みです。 X1600 LTE Socket – Frequency Bands キモはLTE設定にあり！接続から通信設定までをステップ解説 X1600の接続 Siteの作成からCato Cloudへの接続までの基本的な流れは、 X1500と全く同じ手順 で進めることができます。Cato製品に慣れている方であれば、迷うことはないでしょう。 ただし、いくつか注意すべき差異点があります。 Site作成時のType選択 : CMA（Cato Management Application）でSiteを新規作成する際、SocketのTypeとして「 X1600 LTE 」を正しく選択する必要があります。 MGMTポートの位置 : Socketの初期設定で使用するMGMTポートが、X1600では 8番ポート に割り当てられています。X1500とは物理的な場所が違うため、注意が必要です。 今回は、通常のインターネット回線（有線）とLTE回線の2系統を接続し、冗長構成のテストを行いました。   LTEの設定 LTE回線を利用するためには、Socketに対してAPN（アクセスポイント名）などの情報を設定する必要があります。 この設定はSocketのWeb UIから行います。PCをMGMTポートに接続して直接アクセスするか、すでに有線回線でCato Cloudに接続済みの場合は、CMA経由でリモートアクセスすることも可能です。 ▼設定手順 Socket UIにログインし、左側メニューから「Network Setting」を選択します。 設定画面をスクロールしていくと「LTE」という項目があります。 ここに、契約しているSIMキャリアから提供されたAPN情報、および必要に応じてユーザー名/パスワードを入力し、保存します。 （APN情報や認証情報は契約キャリアによって異なります。不明な場合はキャリア側へお問い合わせください。） 正しく設定が完了すると、SocketはLTE網を認識し、Cato Cloudへの接続経路として利用可能になります。   通信の優先度設定 LTE回線の設定が完了すると、デフォルトでは「 Last-resort 」というモードで動作します。 これは「最後の手段」という意味で、メインの有線回線が両方とも切断された場合にのみ通信を行う、純粋なバックアップ回線としての設定です。この状態では、通常時のLTEデータ通信量はほぼ発生せず、コストを抑えることができます。 Catoでは、回線の優先度を以下のように柔軟に設定できます。 Active : 常に通信を行い、トラフィックを負荷分散させるプライマリ回線。 Passive : Active回線がダウンした際に切り替わるセカンダリ回線。 Last-resort : ActiveとPassiveの両方がダウンした際に利用される最終バックアップ回線。 この優先度設定（ Active > Passive > Last-resort ）をうまく活用することで、コストと可用性のバランスを取ったネットワーク設計が可能になります。   【実機検証】LTEへの切り替えはスムーズ？気になる通信断と速度をテスト！ せっかく実機があるので、皆さんが特に気になるであろうポイントを実際に検証してみました！ （私の手違いで検証結果のスクリーンショットが消えてしまったので、今回は文字だけのレポートとなる点、ご容赦ください…！） 検証①：LTE回線への切り替わりで通信は途切れるのか？ LTE回線をバックアップとして利用する上で最も重要なのが、メイン回線障害時の切り替え（フェイルオーバー）のスムーズさです。この時、Cato経由でアクセスしているユーザーの通信はどの程度影響を受けるのでしょうか。 ▼検証方法 X1600に有線接続したPCからインターネット上のサーバーへPingを打ち続けた状態で、X1600のWAN側ケーブルを物理的に引き抜きます。この瞬間のPingの応答ロスを確認しました。 ▼検証結果 結果としては、 Pingがタイムアウトしたのはケーブルを抜いた直後の1回のみ で、すぐにLTE回線経由での通信に切り替わり、Pingは正常に応答し続けました！ 正直なところ、もう少し通信が不安定になるかと想像していたので、このシームレスさにはちょっと感動しました（笑）。 Pingでのロスが1回ということは、通常のWeb会議や業務アプリケーションなどの通信であれば、ユーザーは切り替わりに気づくことなく業務を継続できるレベルと言えるのではないでしょうか。   検証②：LTE回線でも十分な速度は出るのか？ 「モバイル回線は、やっぱり有線より遅いのでは？」というイメージをお持ちの方も多いかと思います。そこで、LTE接続時の通信速度についても簡易的なテストを行いました。 ▼検証方法 有線接続時とLTE回線のみでの接続時、それぞれでSocket配下のPCからスピードテストサイトを利用し、通信速度を計測しました。 ▼検証結果 結果は、 有線・LTE回線ともに約25Mbps となり、明確な速度差は確認できませんでした。 これは、今回利用した環境のSiteライセンス上限が25Mbpsに設定されていたため、どちらの回線もその上限値に達してしまった、というのが実情です。 そのため、この結果自体はあまり意味のある比較ではありませんが、「 少なくともライセンスで許可された帯域は、LTE回線でも十分に使い切れる 」という一つの参考値として捉えていただければと思います。実際の速度はご利用になるSIMキャリアや電波状況に依存します。   【余談】2.5Gbpsポートで1Gbpsの壁は越えられるのか？ 今回検証を進める中で、チーム内である疑問が話題になりました。それは「 X1600のスループットは公称値以上に向上させられるのか？ 」という点です。 前述の通り、X1600のポート5～8は物理的に2.5Gbpsに対応しています。そして、これらのポートはCMAからWANポートとして設定変更が可能です。 一方で、Catoの公式ナレッジでは、X1600の最大スループットは 1Gbps と記載されています。 では、2.5Gbps対応ポートをWANとして利用すれば、この1Gbpsの壁を越えられるのではないか？という仮説です。 結果としては… Socket側のスループットの上限があるため、ポート側が2.5Gbps対応でも1Gbpsを超えることはできないとのことでした。。 とはいえ、2.5GbpsポートをLAN側で利用すれば、拠点内の高速なデータ転送には大いに貢献します。   どんな時に活躍する？X1600 LTEモデルが輝く2つのユースケース ここまでの仕様や検証結果を踏まえ、X1600 LTEモデルが特に有効なユースケースを考えてみました。   ユースケース①：手軽に回線の冗長性を確保したい 最も代表的なケースです。 通常、回線の冗長性を確保するには、主回線とは別のキャリアで物理回線をもう1本契約し、開通工事を行う必要があります。これには時間も手間もコストもかかります。 しかし、X1600 LTEモデルであれば、 SIMカードを1枚契約するだけ で、すぐにバックアップ回線を用意できます。これにより、工事日程の調整といった煩わしさから解放され、迅速に事業継続性を高めることが可能です。SIMのプランによっては、月々の通信コストも抑えられます。   ユースケース②：仮設拠点や光回線が引けない場所で利用したい 次に思いつくのが、物理的な回線工事が困難な場所での利用です。 建設現場やイベント会場などの 仮設オフィス 迅速な出店・撤退が求められる ポップアップストア このような環境では、電源さえ確保できれば、X1600 LTEモデルを使って即座にセキュアな企業ネットワークを構築できます。LTE回線を主回線として利用することで、ビジネスの機動力を大幅に向上させることができるでしょう。 まとめ 今回は、 Cato Networks X1600 LTEモデル を実機でレビューしました。 設定方法は従来のX1500とほとんど変わらず、直感的に扱うことができます。LTEモジュールが内蔵されたことで、これまで以上に「手軽」で「迅速」な回線冗長化と拠点展開が可能になった点が最大のメリットだと感じました。 回線工事の手間をかけずにBCP対策をしたい 多拠点展開をスピーディーに進めたい 仮設拠点でも本社と同じセキュリティレベルを保ちたい このような課題をお持ちの企業にとって、X1600 LTEモデルは非常に強力な選択肢となるはずです。 #5G対応モデルも出て欲しいー

  本記事は TechHarmony Advent Calendar 2025 12/11付の記事です 。 ログ出力の抑制の必要性 Cato クラウドでは、提供されるネットワークやセキュリティ機能の様々なログが “イベント” という形でクラウド側で保管され、Web 画面を通じてログを検索・絞り込みしつつ参照できるようになっています。この機能はシステム運用やセキュリティ運用において非常に活躍してくれるものですので、弊社のお客様にはログをできるだけ全て出力することを推奨しています。 一方で、Cato においてはログ出力できるイベントの量には、 1時間あたり250万件まで という上限があります。 参考： Guide to Cato Data Lake – Cato Learning Center ログを全て出力しておくようにしていると、その上限に達してしまい、本来必要なログが出力されないといった問題を引き起こすことがあります。実際、弊社の複数のお客様環境でもこの上限を超えてログが出力されなくなる事態が発生し、 “Cato events Quota Exceeded” と書かれた Cato からの通知メールを受信して初めて気付くということもありました。 こういった事態の発生を解消・予防するには、不要なログの出力を抑制するという運用も必要となってきます。 そこで本記事では、ログ出力に関する考え方や、実際に抑制する方法について解説します。 ログ出力の目的 Cato クラウドの利用に限ったことではありませんが、システムにおけるログ出力・ログ管理の目的は、一般的に次の3種類に大別できると考えています。 監査証跡 ログイン履歴やアクセスログなど、監査証跡として残しておかなければならないログを保管する。 監査目的で定期的にログを参照するだけでなく、なんらかの不正発生時にも参照する。 ログを数年は保管し続ける必要がある。 システム管理 システムの動作確認やトラブルシューティングなど、システムが正常に利用できる状態を保つためにログを利用する。 いつでもログを見れるようにしておく必要がある。 長期に渡ってログを残しておく必要はない。 価値創出 ログを含めた様々なデータを分析し、価値を発見・創出する。 Cato クラウドの利用においては、主に2のシステム管理の目的でログを出力し、実際に利用されているものと思います。また、お客様によっては事業上の要件やセキュリティポリシーにより、1の監査証跡の目的でもログを保管されているのではないでしょうか。 ログ出力の戦略 監査証跡が目的のログは法律や規則の求めにより必要となるものですので、出力すべきログは明確に決まっているはずです。 一方、システム管理が目的のログは何を出力すべきか明確というわけではありません。特にトラブルシューティングを行う状況において、ログは多ければ多いほど解決に役立ちますので、Cato を利用開始するお客様には出力できるログは全部出力しておくというシンプルな戦略を推奨しています。 しかし、冒頭に記載した通り Cato ではログ出力できる量に上限があります。Cato を導入して大規模に利用する段階になると、ログ出力が上限に達してしまい、必要なログが出力されない問題が生じる可能性があります。 Cato では追加ライセンスを契約すればログ出力の上限を増やせますが、その分の費用が必要となってきますので、上限に達してから機動的にライセンスを追加契約するという選択肢は採りにくいです。また、外部の SOC サービス等を利用している場合も、通常はログ量が増えると費用も増えていきます。 そのため、Cato を導入して支障なく利用できる状況になってきたら、次は目的に照らし合わせてログ出力を抑制していく運用も重要となってきます。 ログ出力の抑制方針 さて、ログ出力の抑制とは具体的にどのように進めていけばいいのでしょうか。 不正発生時やトラブルシューティング時にもログを利用することから、必要なログを予め特定してそれだけを出力することはできません。そのため、明確に不要なログを出力しないようにする方針で進めていくことになります。 具体的には、次のようなログのうち、大量に出力されているログの出力を抑制していくのが良いと考えます。 Internet Firewall のイベントのうち、全社的な統制のもと許可またはブロックしている通信に関するログ WAN Firewall のイベントのうち、通信内容が明確なログ 1についですが、例えば Microsoft 365 や Google Workspaces を全社的に導入しているお客様の場合、それらサービスへのWebアクセスが Monitor として多数記録されているのではないでしょうか。全ての社員が当然利用するサービスのログは、その内容を解析して何かアクションを行うこともないでしょうから、出力を抑制してもおそらく問題ないでしょう。 また他にも、Cato では標準のルールとして QUIC (HTTP/3) がブロックされるようになっていますが、それも出力を抑制しても問題ないと思います。インターネットアクセスで HTTP/3 がブロックされたとしても、通常は HTTP/2 や HTTP/1.1 にフォールバックされ、Cato では別のイベントとしてログ出力されますので、監査でもトラブルシューティング等でも特に問題はないはずです。 2についてですが、弊社のお客様の例ではありますが、Windows Update の配信最適化機能により多数の Windows マシン間で通信が行われ、膨大なログが出力されているケースがありました。この機能を有効にするか無効にすべきかという議論はさておき、このログは解析することもないため抑制して良いでしょう。他にも、多数の機器への監視 (SNMP や Zabbix など) の通信もログが多くなりがちで、これも通信内容が明確ですので抑制して良いと思います。 ログ出力の抑制方法 ログ量が多い通信を見つける ログ出力の抑制に先立って、CMA の Events 画面にてログ量が多い通信を見つけましょう。 様々なフィルタを駆使して少しずつ絞り込んで見つけていくわけですが、最初は Events 画面の左側にある “Sub-Type” を展開してみてください。 おそらく Internet Firewall や WAN Firewall のログが非常に多く出力されているのではないでしょうか。展開して表示された箇所にマウスポインタを当てると “⊕” や “－” のアイコンが表示されますので、”⊕” のアイコンをクリックして選択したログだけが表示されるようにフィルタを適用しましょう。 次は同様に “Destination Port” を展開してみてください。上部の入力欄に “port” と入力すると見つけやすいです。 Internet Firewall でフィルタした場合、どのお客様も443番ポート (HTTPS) 宛の通信が最も多いのではないでしょうか。その後に80番ポート (HTTP) や53番ポート (DNS) 宛の通信が並ぶだろうと思います。 ここでさらに443番ポート宛の通信だけが表示されるようフィルタを適用した後、”Domain Name” を展開してみてください。 Microsoft 365 をお使いの会社ですと “microsoft.com” や “office.com” などを含むドメイン名が上位に並んでいるかと思います。他にも、OS が標準的に行う通信 (Windows Update や iOS 関連) や、全社的に導入しているシステムのドメイン名も上位に来るのではないでしょうか。上位に表示される中で、信頼できるドメイン名のものがログ出力を抑制する候補となります。 WAN Firewall でフィルタした場合は、”Destination Port” の上位に来るものの傾向は Internet Firewall の場合と異なるはずで、次のような宛先ポートが並ぶのではないでしょうか。 7680番 : Windows Update の配信最適化機能 53番 : DNS 161, 162番 : SNMP 監視 10050, 10051番 : Zabbix 監視 389番 : LDAP 445番 : Windows ファイル共有 そして、ポート番号ごとに “Destination IP” や “Source IP” も見て通信の多い宛先・送信元IPアドレスも把握し、ログ出力を抑制する候補を見つけましょう。システム的に行われる通信のログは抑制してしまって良いと考えており、上記ですと宛先・送信元IPアドレスも考慮した上で7680, 161, 162, 10050, 10051, 389番ポートの通信は抑制しても良さそうです。 Internet Firewall / WAN Firewall のルールを変更する ログ出力を抑制する通信を決めたら、実際に Internet Firewall や WAN Firewall のルールを追加または変更し、ログが出力されないようにしましょう。 先ほどまで見ていた Events 画面の右側には個別のイベントログの内容も表示されており、その中の “Rule” というフィールドにはそのイベントがマッチした Internetl Firewall や WAN Firewall のルール名が表示されています。該当のルールを変更してログ出力されないようにするか、そのルールよりも上位にログ出力をしないルールを追加しましょう。 例えば Microsoft 365 をお使いのお客様がその通信のログ出力を抑制するなら、Internet Firewall では次のような設定内容になるかと思います。 App/Category で “microsoft.com” や “office.com” ドメインを対象と、Track では何もチェックを入れず “N/A” となるようにしています。ルールを追加する際、Action を “Allow” に変更しない通信できなくなってしまいますので、ご注意ください。 また、例えば Windows Update の配信最適化機能と SNMP 監視の通信のログ出力を抑制するなら、WAN Firewall では次のような設定内容になるかと思います。 Windows Update の配信最適化機能は任意のPC同士で TCP 7680 番ポートを宛先とした通信を行います、上の画像では Source や Destination を指定せず、Service/Port では Custom Service として “TCP/7680” を指定し、ログ抑制対象の通信を限定しています。Action を “Allow” にするか “Block” にするかは、お客様の環境によって異なります。 また、SNMP は、特定 SNMP マネージャから多数の SNMP エージェントの UDP 161 番ポート宛に行うポーリングや、逆に SNMP エージェントから SNMP マネージャの UDP 162 番ポート宛に行うトラップの2種類の通信がありますので、それぞれをルールに設定しています。SNMP マネージャは少数でIPアドレスは明確でしょうから、上の画像では仮に “10.1.1.1” とし、その SNMP マネージャが発着信する通信に限定しています。 まとめ 本記事では Cato クラウドの利用時におけるログ出力量の上限到達という問題への対応方法として、ログ自体の目的を踏まえたログ出力を抑制する方法を解説しました。こういった運用に関する知見は Cato 公式ドキュメントには記載されておりませんので、本記事を参考にしていただけると幸いです。 また、ログ出力の抑制は、単にログ量を削減して追加ライセンスを購入しなくて済むようにするというだけのものではありません。不要なログが多いと CMA の画面上でのログの参照に時間がかかったり、トラブルシューティング時に余計な手間がかかったりもします。 Cato クラウドを安定的に利用するにはログの存在は不可欠ですので、ログを扱いやすくして効率的な運用を行えるようにするためにも、ログ出力ルールを継続的に見直していきましょう！

こんにちは。SCSKの井上です。 New Relicを導入する際には、いくつかの鍵を正しく設定する必要があります。この記事では、ライセンスキーとユーザーキーの概要、用途、発行手順、そしてセキュリティを確保するための管理方法を解説します。鍵の種類や管理方法を理解するための参考になれば幸いです。   はじめに New Relicへデータを送る際に使用する鍵（ライセンスキー/ブラウザキー）と、データを操作する際に使用する鍵(ユーザーキー)があります。これらの鍵は、外部システムとの連携や内部操作を安全に行うために不可欠な要素です。特に、APIキーは発行したユーザーの権限を継承するため、 誰が発行するかによって操作可能な範囲が大きく変わります 。どんな鍵があり、どの点に注意すべきかを解説していきます。 この記事はNew Relicを全く触ったことがないかたを対象としています。New Relicの無料プラン※を利用して操作を行いますので、New Relicを費用無しで実施いただくことができます。 ※無料プランに含まれる内容は、月間100GBまでのデータ容量と全機能にアクセスできるユーザー1名です(Basicユーザについては無償)。無料プランの場合、一部機能に制約がある可能性はあります。   New Relicで扱う設定鍵について アプリやサーバーからNew Relicにデータを送るためには、License Keyが必要です。New Relicのコンソールで見るだけならUser Keyは不要ですが、NerdGraph APIを使ってアラート設定やダッシュボードをスクリプトで自動化やAWSやAzureなどの外部連携する場合は、必要になります。 キータイプ 意味 主な用途 発行対象 Ingest – License Key New Relicにデータを送る「入口の鍵」。 データ送信用のAPIライセンスキー。APM、Infrastructure、ログなどのデータをNew Relicに送るために使用。 エージェント設定ファイル、環境変数、サードパーティー製品との連携など アカウント （組織単位） Ingest – Browser Key New Relicにデータを送る「入口の鍵」。 ブラウザ監視用のAPIライセンスキー。Webページに埋め込まれたNew RelicのJavaScriptエージェントがデータを送るために使用。 Browser monitoring Webページに埋め込むJavaScriptエージェント用 アカウント （組織単位） User Key 送られたデータを分析や設定を操作する「操作の鍵」。 API操作用の個人キー。ユーザーがNew Relicの設定やデータにアクセス・操作するために使用。NRAK-から始まる規則となっている。 NerdGraph API、Terraform設定など 個人 （ユーザー単位）   New Relicに初めてサインアップすると、デフォルトのLicense KeyとBrowser Keyが自動で作成されます。この鍵はアカウントに紐づいており、削除や変更はできません。セキュリティ上の理由から、独自に新しい鍵を発行して使用することが推奨されています。 デフォルトの鍵は、初期設定時に誰でも知り得る可能性や、デフォルトのライセンスキーは削除することができないため、外部に漏れた際にサポートに問い合わせて新たな鍵を発行いただく間に、脅威は進行してしまいます。Full platform user権限を持つユーザであれば、いくつでもLicense keyおよびBrowser keyを作成することができ、削除も可能ですので、デフォルトの鍵は使わないようにした方が良いですね。 エージェントがデータを送る対象が「サーバーやバックエンド」からのデータであればLicense Key、「フロントエンド」からのデータであればBrowser Keyになります。Browser KeyはWebブラウザに埋め込むため、不特定多数に閲覧されます。もし、License KeyとBrowser Keyを分けずに使用した場合、予期せぬデータをNew Relicへ大量に送信し、課金されてしまう恐れがあります。そのため、リスクを抑えるためにも二つに分かれている設計になっているのですね。 モバイルアプリトークン用の鍵もありますが、モバイルエージェント導入時に説明することとして、この記事では割愛します。   New Relic APIキー | New Relic Documentation Types of New Relic API keys, who can use them, and how to add, update, or delete API keys. docs.newrelic.com   New Relicライセンスキーの発行方法 ここでは実際にNew Relicのライセンスキーの発行手順について解説していきます。Full platform user権限を持つユーザーがライセンスキーを何度でも作成することができます。ライセンスキーの発行にお金もかかりません。ライセンスキーがたくさん作成されてしまうと管理が大変になりますので、組織に一つ、環境ごとに一つ、チームで一つなどセキュリティのリスクに応じて使い分けることを推奨します。 ライセンスキーはアカウント単位で管理されるため、誰が作成したかはNew Relicのコンソールから確認できません。命名規則を設けるか、備考欄にどのような用途の鍵なのかを記載しておくことで鍵の管理がしやすくなります。以下の手順にて作成ができます。 １．左下のユーザーアイコンをクリックし、「API Keys」をクリックします。 ２．「Create a Keys」をクリックします。すでに鍵は2つ作られています。NoteにOriginal accountと記載されている鍵はデフォルトの鍵を指します。 ３．Key type欄のプルダウンメニューから「Ingest -License」を選択します。その後、Name、Notesを入力し、「Create a key」をクリックします。 ４．ライセンスキーが上部に表示されますので、「Copy Key」をクリックして、必ずメモします。 【補足】名前や備考欄を変更したい場合は、該当のレコードの右横にある「・・・」をクリックし、「Edit」を選択してください。       New Relicユーザーキーの発行方法 ここでは実際にNew Relicのユーザーキーの発行手順について解説していきます。ユーザーキーも何度でも発行は可能です。お金もかかりません。 ライセンスキーと異なり、ユーザーキーについては自身以外に開示しないでください 。ユーザーキーの発行はUser API Keys (for self)のロール権限が付与されていれば、Full platform user権限がなくても作成することができます(Standard rolesにおいて、Billing Userロール以外は付与されています)。 ユーザーキーは、発行したユーザーに割り当てられたロールの権限に基づいて動作します。たとえば、管理者ロールを持つユーザーが発行した場合、そのキーには管理者権限が付与されます。一方、Read-onlyロールのみを持つユーザーが発行した場合、そのキーは読み取り専用の権限しか持ちません。必要に応じて外部連携との設定する際は、ロール権限を最小限に抑えた専用のユーザーを推奨します。 【New Relic】New Relicアカウントの基本構造 この記事では実際にNew Relicを使う前の導入ステップとして、New Relicアカウントの基本構造について解説していきます。アカウントを管理していく上で、必要となる前提知識のため、ユーザ作成する前に知識を深める一助になれば幸いです。 blog.usize-tech.com 2025.11.12   ユーザーキーはユーザー単位で管理されるため、誰が作成したかNew Relicのコンソールから確認できます。以下の手順にて作成ができます。 １．左下のユーザーアイコンをクリックし、「API Keys」をクリックします。 ２．「Create a Keys」をクリックします。すでに鍵は2つ作られています。NoteにOriginal accountと記載されている鍵はデフォルトの鍵を指します。 ３．Key type欄のプルダウンメニューから「User」を選択します。その後、Name、Notesを入力し、「Create a key」をクリックします。 ４．ユーザーキーが上部に表示されますので、「Copy Key」をクリックして、必ずメモします。 表示画面から遷移後、画面上から確認することはできなくなります。 【補足】名前や備考欄を変更したい場合は、該当のレコードの右横にある「・・・」をクリックし、「Edit」を選択してください。       発行済のNew Relicライセンスキーの確認方法 発行した鍵はNew Relicにログインすることで見れてしまうのか気になりますね。以前まではNew Relicコンソールにログインすることで見ることができていましたが、セキュリティ向上のため見ることができなくなりました。 発行済のライセンスキーはライセンスキーのIDとユーザーキーの２つをもって確認 することができます。ユーザーキーもわからない場合は、ユーザーキーを新規発行いただいてから、この手順を実施することができます。他のユーザーが発行したライセンスキーも見ることができます。 １．左下のユーザーアイコンをクリックし、「API Keys」をクリックします。 ２．確認したいライセンスキーの右横「・・・」から、「Copy key ID」をクリックします。 ３．左ペインより「Apps」をクリック後、検索ボックスにAPIと入力し、「NerdGraph API Explorer」を選択します。 ４．User Keyの欄に自身のユーザーキーを入力し、「Submit」をクリックします。 ５．下記クエリ文※をコピーし、INGEST_KEY_ID部分を書き換えて実行します。 ６．実行後、赤枠の部分がライセンスキーになります。 ※クエリ文 query { actor { apiAccess { key(id: "INGEST_KEY_ID", keyType: INGEST) { key name type ... on ApiAccessIngestKey { ingestType } } } } }   NerdGraphチュートリアル。APIキーの管理 | New Relic Documentation Use New Relic NerdGraph (our GraphQL API) to create and manage license keys and user keys. docs.newrelic.com   鍵の管理方法について 各種鍵について、定期的なローテーションや設定鍵の棚卸、誤って設定キーが外部に流出しないよう、環境変数で管理することを推奨します。これにより、セキュリティリスクを抑えられます。Ingest License Key をローテーションする場合、古い鍵を使っているエージェントやアプリケーションが新しい鍵に更新されるまで、データ送信が停止する可能性があります。そのため、ローテーションする際は、すべてのデータが転送できていることをコンソール上から確認した上で、古い鍵を消す考慮が必要です。 鍵を作成したユーザーを削除した場合、鍵はどうなるのでしょうか。ユーザーキーはユーザーに紐づいていますが、ユーザーを削除してもそのユーザーが作成した鍵は残っています。ユーザーキーを完全に削除するには、API Keys画面より削除が必要です。ライセンスキーは アカウントに紐づいています。ユーザーキー同様にユーザーが削除されても そのユーザーが作成したライセンスキーは引き続き有効です。誤って設定鍵が外部に流出しないためにも、環境変数で管理することでリスクを抑えることも重要です。   モバイルアプリトークンについては、トークンを削除したり、追加のトークンを作成したりすることはできない旨、記載されています。トークンが流出した場合の対処については、公式の情報がないため、New Relic サポートに連絡することが必要です。   New Relic APIキー | New Relic Documentation Types of New Relic API keys, who can use them, and how to add, update, or delete API keys. docs.newrelic.com   さいごに New Relicへデータを送る際に使用する「鍵」と、データを操作する際に使用する「鍵」について解説しました。特に、APIキーは発行したユーザーの権限を継承するため、誰が発行するかによって操作可能な範囲が変わることについて、この記事を読んで、New Relicの設定鍵の運用に少しでもお役に立てれば幸いです。 SCSKはNew Relicのライセンス販売だけではなく、導入から導入後のサポートまで伴走的に導入支援を実施しています。くわしくは以下をご参照のほどよろしくお願いいたします。

本記事は TechHarmony Advent Calendar 2025 12/10付の記事です 。 こんにちは！　Catoクラウド担当、佐藤です。 以前、AWSのvSocket構築手順を解説したブログを作成しました。 本記事では、vSocketを冗長化したHA構成の構築手順について解説いたします。 HA構成とは HA(High Availability）構成 とは、システム障害時でもサービスを継続するための構成のことです。複数の機器や経路を組み合わせて冗長化し、単一の機器が停止してもシステム全体しないようにします。 特にネットワークの停止は日常業務に大きな影響を与えるため、冗長化によってトラブル時でもシステムを維持できる構成が必要です。 CatoクラウドのAWS vSocketにおいても、2台以上のvSocketを配置することで冗長化を実現します。 プライマリvSocket：通常時のトラフィックを処理 セカンダリvSocket：プライマリ障害時に自動フェイルオーバー プライマリ側に障害が発生した場合でも、自動的にセカンダリに切り替わることで、組織の内部環境とCatoクラウドの接続を維持することができます。以下はイメージとなります。   事前準備 プライマリvSocketの構築 AWS vSocketでHA構成を構築するには、プライマリとセカンダリのvSocketをデプロイする必要があります。 この後の手順説明では、 プライマリvSocketがすでに構築されていることを前提 に進めます。 そのため、まずはプライマリvSocketの構築をお願いします。構築方法については、以下のブログをご参照ください。 ※すでに構築済みの方はスキップしていただいて構いません。 【Catoクラウド】AWS環境でのvSocket構築手順を解説 AWS環境上にvSocketを構築し、Catoクラウドと接続するまでの手順を紹介します。 blog.usize-tech.com 2025.10.28 使用可能なElastic IPの確認 １台のvSocketのデプロイには２つのElastic IP（MGMT用、WAN用）が必要になります。 さらに、別々のAZ（Availability Zone)にて2台のvSocketをデプロイしてHA構成を組む場合、合計で４つのElastic IPを使用します。 デフォルトでは、AWSアカウントでリージョン当たり５つのElastic IPが割り当てられております。現在の割り当て状況をご確認の上、空きがない場合はご用意をお願いいたします。 AWSマネジメントコンソールで、「 EC2 」＞「 Elastic IP 」より上限の確認が可能です。 HA構成の構築手順 HA構成のための設定手順を説明していきます。 以下のステップで設定を進めます。 １. Cato クラウド CMA上での Site 設定 ２ . AWS 設定 　 2-1. セカンダリ vSocket のデプロイ 　 2-2. IAM ロールの作成 　 2-3. IAM ロールのアタッチ 3. 接続確認   本記事は2025年12月1日時点での構築手順です。 内容については今後変更の可能性がありますこと、ご了承ください。 図例は一例としてご参考いただけますと幸いです。                 Cato社が提供する構築手順は下記となりますので、本記事と合わせてご参照ください。          AWS vSocketのHAを構成する-ナレッジベース                 プライマリvSocketが構築されていることを前提に説明を進めます。vSocketの構築手順については、本記事の「 事前準備 」をご参照ください。 1. Catoクラウド CMA上でのSite設定 HA構成を構築したいSiteに対してCMA上でセカンダリvSocketを追加する設定を行います。 １．CMAのメニューから、「 Network 」＞対象のSiteをクリック ２．「 Site Configuration 」＞「 Socket 」＞「 Add Secondary Socket 」をクリック   ３．Secondary Socketの設定項目は3つあります。以下の設定項目を入力し、「 Apply 」を実行します。 ・LAN ENI IP Address：セカンダリvSocketで作成するLANネットワークインタフェースのIPアドレス ・LAN ENI Subnet：セカンダリvSocketで作成するLANサブネットのアドレス範囲 ・Route-Table ID： プライマリvSocket で作成したLAN用ルートテーブルのルートテーブルID   4.　サイトの設定が完了すると以下の画面になるので、セカンダリvSocketのシリアル番号をメモなどに控えておいてください。 ※シリアル番号はAWSでのインスタンス起動時の設定で使用します。 2. AWS設定 次に、AWS側での設定を行います。 AWSマネジメントコンソールにおける具体的な操作手順については、上で紹介した関連ブログに詳しくまとめていますので、必要に応じてご参照ください。   2-1. セカンダリvSocketのデプロイ セカンダリvSocketのデプロイ手順を説明します。 必要な設定事項は以下になります。 ・ElasticIPアドレス取得（MGMT用、WAN用） ・サブネット作成（MGMT用、WAN用、LAN用） ・ルートテーブルの関連付け ・ENI（ネットワークインタフェース）作成 ・インスタンスの起動 ElasticIPアドレス取得（MGMT用、WAN用） MGMT ENIとWAN ENIに割り当てるためのElastic IPを取得します。 AWSマネジメントコンソール 「 VPC 」＞「 Elastic IP 」＞「 Elastic IPアドレスを割り振る 」より設定が可能です。 通常のAWS vSocket構築と同様の手順で、 MGMT用 、 WAN用 のEIPをご用意ください。   サブネット作成（MGMT用、WAN用、LAN用） こちらも通常のAWS vSocket構築と同様の手順で、以下3つのサブネットを作成してください。 AZはプライマリと別のものを選択してください。 MGMT用サブネット WAN用サブネット LAN用サブネット ※プライマリとセカンダリが同じAZの場合MGMT用、WAN用のサブネットは不要です。 AWSマネジメントコンソール 「 VPC 」＞「 サブネット 」＞「 サブネットを作成 」より設定が可能です。 ここで設定した「 LANサブネットのIPアドレス範囲 」が、 CMA上でのSecondary Socket設定の2つ目「 LAN ENI Subnet 」に入る値となります。   ルートテーブルの関連付け ルートテーブルの追加作成は必要ありません。 プライマリvSocketで作ったものにセカンダリのサブネットを割り当てます。 内容は以下の通りです。 MGMT・WAN用ルートテーブルに関連付けるもの ・セカンダリvSocket用のMGMTサブネット ・セカンダリvSocket用のWANサブネット LAN用ルートテーブルに関連付けるもの ・セカンダリvSocket用のLANサブネット ※MGMTとWANのルートテーブルは分けて2つになっていても問題ありません。それぞれ対応するサブネットの関連付けを行ってください。 以下の操作で設定が可能です。 AWSマネジメントコンソール 「 VPC 」＞「 ルートテーブル 」＞対象のルートテーブルを選択 「 サブネットの関連付け 」タブ　＞　明示的なサブネットの関連付けの「 サブネットの関連付けを編集 」をクリック   ENI（ネットワークインタフェース）作成 セカンダリvSocketで用いるENIを作成します。 プライマリ同様以下3点のENIを作成してください。 セキュリティグループは特に指定がなければ、プライマリvSocketで作成したもので問題ありません。 MGMT用　ENI WAN用　ENI LAN用　ENI ※ENI作成手順はすべて通常のvSocketと同じです。詳細はvSocket構築手順のブログをご参照ください。 ここで設定した「 LAN用ENIのIPアドレス 」が、 CMA上でのSecondary Socket設定の1つ目「 LAN ENI IP Address 」に入る値となります。 注意点 ・ MGMT用ENI と、 WAN用ENI へ Elastic IP を忘れずに割り当てて下さい。 ・LAN用ENIに対して、「 送信元/送信先チェック 」の無効化を忘れずに行ってください。   インスタンスの起動 最後に、セカンダリvSocket用のEC2インスタンスの起動を行います。 こちらもプライマリvSocketでの設定とすべて同じになります。 最後の「 高度な詳細 」ではセカンダリvSocketのシリアル番号を「ユーザーデータ」に貼り付けてください。 設定をすべて終えたら、右下の「 インスタンスを起動 」をクリックします。   2-2. IAMロールの作成 Cato vSocketのHA構成ではプライマリvSocketにトラブルが生じた際、自動でvSocketがルートテーブルを変更し、セカンダリvSocketへの切り替えを行います。そのために必要な権限をIAMロールで作成し、インスタンスにアタッチします。 まず、IAMロール用のポリシーを作成していきます。 IAMポリシーに書き込む権限は以下の3つです。 ec2:CreateRoute ec2:DescribeRouteTables ec2:ReplaceRoute 1. AWSマネジメントコンソールから「 IAM 」＞「 アクセス管理 」＞「 ポリシー 」＞「 ポリシーの作成 」をクリックします。   2. 「 アクセス許可を指定 」で「 JSON 」を選択し、以下のポリシーを「 ポリシーエディタ 」に張り付け、「 次へ 」をクリックします。 { "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "ec2:CreateRoute", "ec2:DescribeRouteTables", "ec2:ReplaceRoute" ], "Resource": "*" } }   3. 任意のポリシー名を入力し、「 ポリシーの作成 」をクリックします。   次に、作成したポリシーを用いてロールの作成を行います。 4. AWSマネジメントコンソールから「 IAM 」＞「 アクセス管理 」＞「 ロール 」＞「 ロールの作成 」をクリックします。   5. 信頼されたエンティティタイプを「 AWSのサービス 」、ユースケースを「 EC2 」と選択し「 次へ 」をクリックします。   6. 「 許可ポリシー 」の項目で先程作成したポリシーを検索し、選択した後、「 次へ 」をクリックします。   7. 任意のロール名を入力し、「 ロールを作成 」をクリックします。   2-3. IAMロールのアタッチ 続いて作成したIAMロールを、プライマリ、セカンダリの両方のvSocketにアタッチします。 アタッチ方法について説明します。 1.  AWSマネジメントコンソールから「 EC2 」＞「 インスタンス 」＞vSocketのインスタンスを選択します。 2. 「 アクション 」＞「 セキュリティ 」＞「 IAMロールを変更 」をクリックします。     3. 作成したIAMロールを選び、「 IAMロールの更新 」をクリックします。 3. 接続確認 最後に接続確認を行います。 1.  AWSマネジメントコンソールから「 EC2 」＞「 インスタンス 」＞プライマリとセカンダリvSocketのインスタンスを選択します。 2. 「 インスタンスの状態 」＞「 インスタンスを開始 」をクリックし、各インスタンスを起動してください。 ※すでに起動してある場合はスキップしてください。 １～2分ほど待ち、CMA上で状態を確認します。 3. CMA上で「 Network 」＞「 Site Configuration 」＞「 Socket 」と進みます。 4. 以下のように各Socketが「 Connected 」、中央のHA Statusが「 Ready 」となっていることを確認してください。   接続がうまくいかない場合 まずは、これまでの手順の中で、以下の項目が正しく設定されているかご確認ください。 １）Elastic IPアドレスがMGMT ENI、WAN ENIに割り当てられている ２）MGMT・WAN用のルートテーブルがセカンダリのMGMT・WANサブネットに関連付けられている ３）各vSocket（EC2インスタンス）にIAMロールが正しくアタッチされている 私が検証した際は、設定したつもりだった部分が設定されておらず接続できていなかったことがありました。 正常に接続できない方は上記事項を再度ご確認いただければと思います。 それでも改善しない場合は、以下SCSKが提供するFAQサイトもご活用ください。 AWS vSocketでHA切り替えが動作しない | よくあるご質問 | Cato Cloud ケイトクラウド - SCSK AWS vSocketをHA構成にて構築し、正しく構成されているにもかかわらず、Primaryダウン時にLAN側のルートテーブルが意図どおり書き換わらない場合には、以下の設定をご確認ください。HA構... cato-scsk.dga.jp   おわりに 本記事では、AWS vSocketのHA構成について解説を行いました。 実際に構築を行ってみて、接続が正常にできない場合に「どこまで正しく動いているのか」を意識しながら確認項目を絞ることで、原因が特定しやすくなると感じました。 今回は主に構築手順の解説となりましたが、HA環境での実際の挙動などについて検証してブログにまとめられたらと考えています。 最後までお読みいただき、ありがとうございました！

こんにちは。SCSKの星です。 今回はServiceNowのバージョンアップ期限に間に合わない場合の対応方法について書いていきます。 はじめに（注意） バージョンアップには期限があります。基本的には期限内に終わらせることが好ましいです。 ※期限内のスケジュール変更や期限の確認方法についてはこちらをご覧ください。 → 【ServiceNow】バージョンアップのスケジュール変更方法 – TechHarmony ただどうしても期限に間に合わない場合もあると思います。その場合はServiceNowにお願いして延長してもらうことも可能です。 ただ、毎回この方法が有効なのかもわかりませんし、場合によっては拒否されてしまうこともあるようです。 そもそもServiceNowの担当者にご迷惑をおかけするのも、あまり望ましくありません。ですので、 「この方法でServiceNow社に延長お願いすればいいや」と思うのではなく、業務上の都合や対応日程など、どうしてもバージョンアップが間に合わなかった場合の手段 としてご認識ください。   延長申請手順 延長申請フォームを要求する 延長をするには、NowSupportで延長申請フォームのリンクをもらう必要があります。 そのためまずはNowSupportにログインします。 https://support.servicenow.com/now ※誰でも作成可能なServiceNowIDではなく、NowSupport専用のアカウントが必要です。わからない場合はライセンス管理者にお問い合わせいただくとよいかと思います。 ログイン後、上部にあるタブから インスタンス > インスタンスダッシュボード を開きます。 インスタンスダッシュボードからバージョンアップを延長したいインスタンスを選択します。   予定されている変更一覧から、メジャーバージョンアップに関するものの変更番号をクリックすることで開きます。 「Family EOL Upgrade…」と書いてあるのが該当します。   開いた変更スケジュールページのアクティビティタブにバージョンアップが間に合わない旨のメッセージを送ります。 こちらにメッセージを送ることでServiceNow担当者が内容を確認し、延長申請フォームのリンクを送ってくれます。 下の図はVancouverバージョン時に延長をお願いした時の例です。   延長願いを出すと、バージョンの期限切れに関する変更チケットに延長申請用のフォームURLが共有されます。 Xanadu→Zurichバージョンアップの際のチケットの名前は「2025 Xanadu End of Life Upgrade」でした。 延長申請用URLが記載されたメッセージは以下の通りです。 ※もしかしたら「Family EOL Upgrade…」のチケットではなく、既にチケットが作成されていれば「2025 Xanadu End of Life Upgrade」チケットに直接延長願いをした方が良いかもしれません。試したことがないのでわかりませんが…   延長申請フォームを記入する ServiceNowから延長申請フォームリンクを共有いただいたら、そちらを記入していきます。 全項目必須回答となっており、不完全な回答を送信すると延長申請は却下されるそうですので慎重に回答ください。 質問は選択肢式の設問が多く、希望延長日時や期限内にバージョンアップできない理由、バージョンアップ計画などについて計22項目聞かれます。また英語での質問・回答になりますのでご注意ください。 またこの際に CISOまたは情報セキュリティ担当者の氏名と連絡先情報を記入する必要 があります。 事前にどなたが該当するか等の確認・調整が必要な場合がありますのでご注意ください。 フォーム送信後、審査にかけられパスすれば自動的に希望した日時でバージョンアップがスケジュール設定されます。   以上となります。この記事が役に立つ場面がないことが理想ですがどなたかの役に立てば幸いです。  

こんにちは、ひるたんぬです。 この度「 AWS re:Invent 2025 」に参加できることになりましたので、現地での出来事や参加したセッションについてのレポートをお送りしたいと思います！ 今回は、帰国の路と振り返りをしていきます！ あっという間の帰国… 帰国時は午前4時前の集合でした。 私は寝てしまうと起きられないリスクがあったので、集合時刻までは寝ずに過ごしました。 ▼ 帰国前の預け荷物。半分空けたところ（＆ 現地で消費して空いた部分）が全て埋まるくらいの荷物です！ ※ 空港で計量したところ、アメリカ国内線の手荷物重量制限ギリギリでした…（49.5 / 50 ポンド） ▼ 行きと同様、空港まではバスで移動します。 ▼ チェックイン後、外を眺めると朝焼けが綺麗でした。 ▼ 国内線でサンフランシスコ国際空港へ移動。 到着後は、トラムで国際線ターミナルへ移動します。 ▼ 国際線のチェックイン。 見慣れた日系企業のロゴを見て少し安心しました。 ▼ 成田空港到着！ 約11時間のフライトでしたが、機内食以外は寝ていたためあっという間に着いてしまいました。 荷物受取時に、スーツケースの持ち手が手前に揃えられている姿は、やはり日本のおもてなしの心なのだなと改めて実感しました。 振り返り 最後に、今回のAWS re:Invent 2025に参加した振り返りをしていきます。 参加したセッション 今回は以下のセッションに参加しました。 それぞれのレポートについては、リンク先をご参照ください。 KeyNote Opening Keynote with Matt Garman A Special Closing Keynote with Dr. Werner Vogels WorkShop Optimize mission critical workloads with CloudWatch MCP & Amazon Q CLI Build trustworthy AI applications with Amazon Bedrock Guardrails GameDay・Jam The Frugal Architect GameDay: Building cost-aware architectures AWS Jam: DevOps & Modernization AWS Jam: Generative AI その他イベント AWS re:Invent 5k Race Japan Night re:Play 初参加ということに加え、過去に参加されていた方から「現地でしか体験できないことを優先するべき」というアドバイスをいただいていたため、WorkShopやGameDay・Jamなどのセッションを中心とし、空き時間もExpo見学やHouse of Kiroなど、現地でしかできない体験をするようにしていました。 その結果、re:Inventのスケールの大きさを実感しつつ、国を超えた多くの交流をすることができました。 この経験は、今後の私のAWSに対する学習意欲を間違いなく高めてくれました。 改めて、今回このイベントに参加できたことを嬉しく思います。 持ち物について この連載の初回に、私の持ち物についてご紹介しましたが、帰国した今、改めて持ち物について振り返りをしていきます。 あくまで、私個人の振り返りとなりますので、要・不要は個人によって大きく異なる点ご了承ください。 https://blog.usize-tech.com/reinvent2025-report-1/#toc1 持って行って良かったもの・持っていけばよかったもの 泊数分の着替え → 洗濯する時間はほとんどなかったので、服装に関しては日数分持って行って正解でした。 保湿グッズ → 砂漠地帯ということは油断ならなかったです。顔については保湿グッズを持っていったので良かったですが、手については持っていっていなかったため、最終日付近はささくれが大量発生しました。 リップクリーム → 保湿グッズと類似するところもありますが、普段唇のケアをあまりしない私にとって、初めてリップクリームの重要さを知るきっかけとなりました。それくらい必携なものです。 ボディバッグ → 手荷物検査が厳しいところでは特に役立ちました。現地では中身をすべてチェックされることもあるので、小さいに越したことはないです。 日本のお菓子 → GameDayや食事会場で会話した外国の方にお渡ししました。これをきっかけに会話が弾むことが多かったので、持って行って大正解でした。（「お菓子外交」と名付けていました。） 水 → 会場内では水の補給ができますが、ホテル内などでは必須でした。帰りはなくなっているので、持って行って損はないと思います。 ※ 現地調達もできますが、値段や水との相性のリスクを考えると、持って行ったほうが良いと思います。 サンダル → 機内やホテルはこれで快適に過ごせました。サンダルでもそこそこ歩くため、履き慣れたサンダルだとより良いかと思います。 ヘッドホン・アイマスク → 特に機内で睡眠する際に重宝します。アイマスクは近くの席の方が読書灯を使用されると、そこそこ眩しいので必須でした。 歯ブラシセット → 機内で快適に過ごせるという点で、私は持って行って正解だと思いました。 なくても良かったもの 折りたたみ傘 → 今回は雨が降ることもなかったですし、会場内はほとんどが屋内移動になるので不要かなと思いました。事前に天気予報などをみて、降りそうだったら持って行く、などでも良かった気がしています。 ポータブル給湯器・粉末のお茶 → 今回は三日目くらいに温かいお茶が飲みたくなったので使いましたが、必須というものではありませんでした。 保湿マスク → 私は普通のマスクで問題ありませんでした。ホテル室内でも、就寝前に多めに水分を摂ることで問題なく過ごすことができました。 のど飴 → 会場内で頻繁に水分補給を意識すれば、特段不要かと思います。 終わりに 出発から到着まで計8日間の出来事でしたが、最初から最後まで大変充実した日々を過ごすことができました。 私自身は周りの経験者の方の多くの助言によって、今回のイベントを楽しく、そして有意義に過ごすことができたので、今度は私もこれからre:Inventに参加される方向けにアドバイスをしていけたら良いなと思っております。 本記事が、来年以降re:Inventに参加される方の参考に少しでもなれば幸いです。 最後までご覧いただき、ありがとうございました！

本記事は TechHarmony Advent Calendar 2025 12/9付の記事です 。 Catoクラウドの管理機能「Advanced Groups」について紹介します。 はじめに：GroupsとAdvanced Groups Catoクラウドの設定、運用管理を行う上で、「『工場』に該当する拠点からのアクセスのみを許可/拒否するようにしたい」「いくつかの特定IPレンジに対するルールを設定したい」など、複数の対象をひとまとめに扱いたいという状況に直面することが考えられます。 こういった需要に応える機能が、2025年に入ってから実装された「Advanced Groups」です。 ……しかし、Catoには以前から同じような用途の「Groups」機能が存在していました。 「Advanced Groups」は「Groups」の名前を変えたものではなく、別機能として従来の「Groups」と共存しています。 では、何が違うのか？ この記事では、「Advanced Groups」がどうAdvancedなのか、これまでの「Groups」との違いを解説していきます。 Advanced Groupsのメリット 「Advanced Groups」には、既存の「Groups」よりも優れた点が複数存在します。 メンバーにできる属性が多い 「Groups」と「Advanced Groups」は、メンバーとして入れられる項目の属性が異なります。 2025/12現在、「Advanced Groups」でしか指定できない属性が存在する一方で、逆はありません。この点においては、「Advanced Groups」は既存の「Groups」を上回っています。 なお、「Advanced Groups」にて指定できる属性は今後も追加予定とアナウンスされています。 「Groups」での属性名 「Advanced Groups」 での 属性名 備考 Site Site   Network Interface Network Interface   Interface Subnet Site Network Subnet Advanced Groupsでは、 「Interface Subnet」と「Grobal Range」が 「Site Network Subnet」に統合されています。 Grobal Range Floating Subnet Floating Subnet CMAの[Resources] > [Floating Ranges]にて定義したFloating Rangeを選択できます。 Hosts Hosts 各Siteの[Site Configuration > Static Host Reservations]にて、Static Hostとして登録したHostsを選択できます。 – Global IP Range CMAの[Resources] > [IP Ranges]にて定義したIP Rangeを選択できます。 「Advanced Groups」でしかメンバーにできない属性 です。 メンバー属性の識別機能 「Groups」「Advanced Groups」は共に様々な属性のオブジェクトをまとめて登録することができますが、それぞれの属性は使用する目的が微妙に異なります。 例えば、「Link Health Rule」はSiteの状態を監視して条件を満たした場合にメールで自動連絡をさせることが可能な機能です。この機能が「Source」として指定する対象は当然Siteであり、IPレンジでの指定には対応していません。 しかし、上記の状況で「Source」としてGroupsを使用すると、IPレンジがメンバーとして登録されているGroupを 対象に指定できてしまいます 。 幸い、この例であればCato側で無視されるため問題は生じませんが、誤設定に気が付かない、思わぬ不具合の引き金になるといったリスクが存在します。 「Advanced Groups」はこの問題を解決します。 Catoが自動的に「メンバーと設定しようとしている項目に互換性があるか」をチェックし、 互換性のないAdvanced Groupは選択肢に表示されない ようになっています。 さらに、何らかのポリシーに利用されているAdvanced Groupは、 互換性が無くなるようなメンバーの追加がブロックされる ように制御されます。 不具合の危険を排除できるほか、使えない属性のGroupが大量表示されて本命を探すのが大変……といった悩みも解決できるうれしい機能です。 充実した管理機能 「Advanced Groups」は、既存の「Groups」と比べてUIや管理機能が大幅に向上しています。 簡単に判別できる一覧UI 従来の「Groups」の一覧は、名前とDescriptionだけが表示される仕様です。 このため、似たような名前のGroupが多数存在する場合、「どれがどれだかわからない」問題が発生する恐れがありました。 もちろんDescriptionに詳しく書けば対策にはなりますが、更新されているかどうかまでは中を見なければわかりません。   一方、「Advanced Groups」は、入っているメンバーの属性と数、最終変更日、変更者まで一覧で確認できるようになりました。 これにより、各Advanced Groupがどのような目的のものなのか、大幅に判別しやすくなっています。また、最終変更日が確認できるため、「許可していない対象を勝手に追加する」といった行為が万一発生した場合でもすぐに特定可能であり、変更者表示から誰の作業で変更されたのかも確認可能です。 セキュリティ面も大きく向上している と言えます。   RBAC機能に完全対応 「Advanced Groups」は、RBAC（Role-Based Access Control）機能に対応しています。 CMAの[Account] > [Administrators]から、管理者ユーザ毎に、Advanced Group個別で編集権限 / 閲覧権限を付与可能です。大きな組織で、各拠点の管理者には対応するAdvanced Groupだけの編集を許可する……といった運用が可能です。 この項目は従来の「Groups」も対象として追加はできるのですが、 メンバーが「Site」のGroup以外を指定した場合は機能しないという仕様がありました。 「Advanced Groups」ではそのようなことは無く、どのような属性のメンバーが入ったAdvanced Groupであっても個別の権限設定が可能です。   APIでの編集にも対応 「Groups」はCMAでの手動更新にのみ対応していますが、「Advanced Groups」はAPIでの設定に対応しています。大規模な設定変更や、メンバーが大量に存在する場合の管理に力を発揮することが期待されます。   Advanced Groupsのデメリット 「Advanced Groups」は比較的最近になって実装された機能であるため、制約も少なからず存在します。 DNSやDHCPの設定には未対応 既存の「Groups」は、各Groupに紐づける形でDNS、DHCPの設定を行うことが可能です。 一方、「Advanced Groups」は2025/12現在、これに対応していません。 グループ個別でのDNS設定を行いたい、といった場合は既存のGroupを使用する必要があります。 （機能追加予定とされていますが、時期は未定です。） 設定先に使える場所が少ない 2025/12月現在、「Advanced Group」を対象として 利用できるのはInternet FirewallとWAN Firewallだけ となっています。 せっかくのメンバー属性識別機能も、現状では使える場所が少なすぎてまともに機能しないというのが現実です。 こちらも対象は順次追加予定であるようなので、今後に期待しておきましょう。 おわりに 「Advanced Groups」機能は、既存の「Groups」では手の届かない細かなアップデートが光る一方、実用性はまだ発展途上といえる機能です。 Catoは今後「Advanced Groups」を主流としていく方針を発表しており、いずれは利用可能箇所も大きく増加することが見込まれます。 既存の「Groups」も併存していますが、今のうちに少しずつ触れてみても良いかもしれません。

前にEligible user(有資格者)側としてPIMを利用していました。 【Azure】Microsoft Entra PIM で権限管理（有資格者編） Microsoft Entra Privileged Identity Management（PIM）を利用して権限の申請しました。通常の運用よりも安全に権限管理できる頼もしい技術でした。 blog.usize-tech.com 2025.07.29 今回は Administrator(管理者)側の操作 を検証してみます。   やりたいこと PIMグループを作成して、 アクティブ化の承認 を実施する。 承認依頼のメールとか、承認完了までの操作をブログに記載したい。   PIMの設定 ユーザー情報 ユーザーは2人設定。 Administrator：ad_tomioka Eligible user：kottomioka kottomiokaがPIMのアクティブ化を依頼し、 ad_tomiokaが承認 します。 現時点でkottomiokaは何も権限を有していません。   権限 リソースグループrg-tomiokaをターゲットに、kottomiokaに対して 共同作成者をPIMで割り当てます 。   グループ作成 まずはグループを作成します Azure Portal > Entra IDで検索 > グループ > 新しいグループ から「PIM-tomioka-共同作成者」のグループを作ります。 所有者にad_tomioka、メンバーにkottomiokaを指定しています。                                 グループ作成後、アクティビティ>Privileged Identity Management  から「このグループのPIMを有効にする」をクリックします。 これでグループ作成完了です。   PIMの設定 Azure Portal > PIMで検索 >管理 > Azureリソース からリソースグループrg-tomiokaを指定し、リソースの管理を押します。                             管理>割り当て から割り当ての追加を押します。                   ロールの選択： 共同作成者 、選択されたメンバー： PIM-tomioka-共同作成者 を指定します。                                   これからアクティブ化に承認が必要な設定をします。 PIM-tomioka-共同作成者の画面より、割り当て>設定 から ロールのMemberをクリック します。 余談ですがこの画面にいくまで少し苦労しました。           編集画面が出てきて、「アクティブにするには承認が必要です」にチェックを付けて、承認者を設定します。                                       これでPIMグループ作成完了です。   アクティブ化の承認やってみた kottomiokaでポータルにログインし、PIMでアクティブ化の申請をします。 そしたら メール が来ました。                       ad_tomioka側で承認ボタン押すと、 承認者にも理由が求められました 。                   承認後 す ぐにkottomiokaに対してアクティブ化 されました。   さいごに ずっとやってみたかったPIMの承認を体験しました。 承認する際にも理由を記載しないといけないことが判明しました。 手作業で承認するので実際の運用では、要求が来るたびに承認するのか、時間を指定して一斉に承認するかの考慮が必要そう。

こんにちは、SCSK斉藤です🐧 2025年11月にSnowflake Intelligenceがついに一般提供(GA)になりました。こちらは生成AIを利用して自然言語によるデータ検索や要約を可能にしてくれるインテリジェンスエージェントサービスです。 前回のブログでは、Snowflake Intelligenceの概要とセットアップ方法について弊社松岡より紹介しました。今回はその続きとして、実際にSnowflake Intelligenceを利用する為の過程・SCSKならではの支援について案内します！ Snowflake Intelligence を始めるためのアカウント設定 Snowflake Intelligenceは、生成AIを利用して自然言語によるデータ検索や要約を可能にしてくれる機能です。利用開始するために必要なアカウント設定の手順を紹介します。 blog.usize-tech.com 2025.10.02 はじめに 企業が生成AIを活用するためには、データ活用が必要不可欠です。 Snowflake Intelligenceを活用することで「データが散在している」「非構造化データが活用できない」「誰が使えるのか不明」などの課題を解決することが可能です。   具体的には データの一元管理：構造化・非構造化データを統合 権限設計：部門や役割に応じたアクセス制御を設定   Snowflake Intelligenceにより、現場の意思決定スピードが飛躍的に向上します。 つまり、データ活用は生成AI活用のスタートラインであり、Snowflake Intelligenceはその上で最大の効果を発揮するツールです。   利用シーン 例えばsnowflake Intelligenceは、こんな利用シーンがあります。 営業部門： SQLやデータ分析に不慣れな営業担当者でも、「今月の地域別売上を教えて」と入力するだけで即座に分析結果を取得可能です。営業戦略の意思決定が迅速化。 製造部門： 設備稼働率や不良率などのデータが散在しがちな現場で、「今週のライン別稼働率を比較したい」といった質問を簡単に実行できます。改善活動に直結。   各機能の概要 それではSnowflake Intelligenceを利用するための準備をしていきましょう。 以下の4つの主要機能で構成されており、それぞれが異なる役割を担っています。ここでは、機能の概要をご紹介します。 また4つの機能は全て、Snowflakeの[AIとML]からアクセスできます。 1.Cortex Analyst 自然言語で問い合わせた内容を SQL に変換する Text-to-SQL サービスです。 会話型の質問をSQLクエリに変換することで、SQLの専門知識を持たないユーザーでも容易にデータへアクセスすることを実現します。   例）住んでいる国、ユーザー名、購入した商品のデータの場合 本機能により、「国ごとの購入数を教えてください」といった自然言語を解釈してSQLを組み立てることが可能 Cortex Analyst | Snowflake Documentation 2.Cortex Search Snowflake内の非構造化データに対する高品質・低レイテンシの検索サービスです。 ベクトル検索とキーワード検索のハイブリッドアプローチを活用し、検索やAIチャットボット向けのRAG（Retrieval Augmented Generation）などのユースケースをサポートします。   例）住んでいる国、ユーザー名、購入した商品のデータの場合 本機能により、SQLを使わず日本のユーザーの検索が可能 Cortex Search | Snowflake Documentation 3.Cortex Agents 構造化・非構造化データの両方を横断してインサイトを提供するオーケストレーションサービスです。上述のCortex Analyst（構造化データ用）・Cortex Search（非構造化データ用）をツールとして活用し、LLMと組み合わせてデータ分析を実行します。   例）住んでいる国、ユーザー名、購入した商品のデータの場合 本機能により、AIボットが検索と分析を交えた回答を可能 また関西弁で回答する設定もできるんやで Cortex Agents | Snowflake Documentation 4.Snowflake Intelligence 自然言語を使用してグラフなどのチャート作成や、テキストでの分析結果の返答を行います。 Cortex Analyst・Cortex Search を活用することにより、構造化データと非構造化データを含む様々なデータソースにアクセスし、統合的なデータ分析を行うことが可能です。 ガバナンス、セキュリティの観点としてはすべての回答については、その元となるソース（SQLクエリまたはドキュメント）まで追跡が可能です。また、Snowflake の既存のロールベースアクセス制御を活用することが可能です。   例）住んでいる国、ユーザー名、購入した商品のデータの場合 本機能により、一般ユーザーがチャット形式でデータ分析が可能 Snowflake Intelligence の概要 | Snowflake Documentation   SCSKならこんなサポートができます みなさんSnowflake Intelligenceについて興味を持ってもらえたでしょうか？ Snowflake Intelligenceローンチパートナーの弊社ならではのサービスの一環として、以下が提供できます。 1.Snowflake Intelligence作成の伴走型支援 Snowflake Intelligenceの導入にあたり、業務に合わせたAIボットの設計から、実装・運用までを弊社がサポートしながら進める「伴走型支援」を提供します。 具体的には以下のような支援内容を想定しております。   SCSKならではの支援例） ・ユースケースに沿った生成AIモデルを選べるようサポート ・回答精度を上げる「整備→QA作成→検証→誤り修正」サイクルをサポート ・お客様のデータの特性や業務に合わせてCortex Agents、Cortex Analyst、Cortex Searchそれぞれの最適な分割方針を提案 ・Snowflake Intelligence活用にあたり事前考慮すべきチャットやデータへの最適な閲覧/利用権限設計を提案 2.Snowflake導入から支援可能 Snowflake Intelligenceだけではなく、DWH/ETL基盤としてのSnowflakeの導入支援も可能です。PoC（概念実証）から始めて、段階的に本番導入まで進めることが可能です。 データ活用上流から運用/データ活用高度化まで一気通貫でサポートします。 サービスに関する最新URLは以下をご参照ください！ Snowflakeソリューション│SCSK株式会社｜サービス｜企業のDX戦略を加速するハイブリッドクラウドソリューション   最後に 一般的なデータ活用のファーストステップとして、BIの固定帳票/ダッシュボードの開発・リリースを目標として掲げられるお客様が多いかと思います。 ただ、実際にはプロジェクトの中で現場関係者を巻き込み切れず、各利用部門のニーズを正確に把握しきれないまま進めた結果、導入したものの「使われないBI」になってしまうという事態に陥ってしまうことも多いのではないでしょうか。   Snowflake Intelligenceを活用することで、会話型のやり取りを通じて構造化・非構造化データの分析が可能になります。これにより、事業部門側でのデータ利活用が促進され、現場から多様なニーズが顕在化することが期待できます。 さらに、Snowflake Intelligenceでは、ユーザーが入力するプロンプトや利用状況のログを分析できます。これにより、よくある問い合わせや分析軸を抽出し、固定帳票/ダッシュボードに反映することが可能です。 このように、Snowflake Intelligenceの活用とその利用状況をもとにしたBIのブラッシュアップを組み合わせることで、現場にとって「本当に使える BI」を提供し、社内全体のデータ利活用をさらに加速できると考えています。   引き続き、Snowflake Intelligenceの可能性を一緒に探っていきましょう！

SCSK いわいです。 前回からだいぶ間が空いてしまいましたが、今回はRaspberry Pi 5で気温/気圧/湿度センサーを使って測定し、 Webで表示するシステムを構築したいと思います。 DBに取得データを格納し、あとから検索できるといろいろ便利です。 今回は前回セットアップした環境をそのまま流用します。(Rapspberry Pi5のみ) Raspberry PiでWebサーバ(冗長構成)を構築②　今度はセンサー 前回はRaspberry Pi 2台でWebサーバを冗長化し、LED点灯を行いました。今回は気温/気圧/湿度センサーを使って情報取得部分を冗長化します。 blog.usize-tech.com 2025.02.17   下準備 使用するRaspberry Piは前回同様に以下のものです。 【Raspberry Pi 5】 CPU: Broadcom BCM2712 quad-core Arm Cortex A76 processor @ 2.4GHz Memory: 8GB OS: Bookworm 前回同様にflaskを利用してWeb画面に測定結果を表示、DBから過去の測定結果を表示できるシステムを組んでみます。 【追加で用意するもの】 温湿度・気圧センサーモジュールキット(BME280使用)  ジャンパーケーブル×５ ブレッドボード×1 Webサーバアクセス用PC   システムのイメージ PythonでFlaskアプリケーションを作成します。今回はWeb画面に測定結果をグラフ表示するようにしてみます。 さらにDB（sqlite3）を使用して、センサーでの測定結果をローカルDB(bme280_data.db)に格納し、 過去のデータを検索できるようにします。 イメージはこんなカンジで。   今回のシステムで導入する機能と各ライブラリの説明は以下のとおりです。 機能 ライブラリ 説明 Webサーバ Flask 軽量なWebフレームワーク。センサー値や予測結果をWebアプリとしてブラウザに表示。 センサー通信 Smbus2 ラズパイとI2C通信する。BME280と通信するために利用。   bme280 Bosch製の温湿度・気圧センサー BME280用のPythonライブラリ。データ取得する。 データ保存 sqlite3 軽量な組み込み型データベースSQLiteを操作するためのライブラリ。計測データをローカルDBに保存・検索するために利用。 時刻処理 datetime 計測時刻の記録に利用。ローカルDBに保存するtimestampを生成。 Flaskとsmbus2とbme280は前回導入済み、sqlite3とdatetimeはデフォルトでインストールされているライブラリです。   温湿度・気圧センサーモジュールキットとRaspberry Piを接続する 前回同様にブレッドボードに温湿度・気圧センサーモジュールキットを接続します。 ※BME280のSDOもRaspberry Piの6ピンに接続します。 　　　 次に回路とRaspberry Pi 5を接続します。 センサ側 Raspberry Pi 5 BME280 VDD 3.3V：1ピン BME280 GND GND：9ピン BME280 SDI GPIO2(SDA)：3ピン BME280 SDO GND：6ピン BME280 SCK GPIO3(SDL)：5ピン 【Raspberry Pi 5のピン配置】 Raspberry Pi 5 Pinouts including GPIO for the 40 Pin Header – element14 Community 接続が終わったら、以下のコマンドを実行します。 sudo i2cdetect -y 1 実行結果に「76」という表記があれば、正常に接続できています。   Pythonスクリプトの作成 ファイル名はtemp_DB.pyにしてみました。 ChatGPTを利用してPythonスクリプトを作りました。 Pythonスクリプトで実行していることは以下です。 センサーからデータを読む BME280から温度・湿度・気圧の最新値を取得します。 データを保存する 取得した値を毎回データベース(SQLite)に記録していきます。 Webページで表示する FlaskでWebページを作り、以下を表示します。 最新の値（温度・湿度・気圧） データをグラフ化したもの 期間や間隔を指定した検索グラフ   2秒ごとに自動更新 ブラウザは2秒ごとに新しい測定値を取りに行き、自動でグラフや数値を更新します。 データ検索 期間と間隔を指定して、過去データをまとめてグラフ表示します。 Pythonスクリプトの実行 次に各Raspberry PiでWebサーバを起動します。 python3 temp_DB.py   Webブラウザからアクセス Webサイトアクセス用PCでブラウザを起動し、以下のURLにアクセスします。 http://Raspberry Pi 5のIPアドレス:5000 センサーが稼働し、2秒ごとに現在の「温度」「気圧」「湿度」が表示されます。 画面右側では2秒ごとに「温度」「気圧」「湿度」のグラフが表示されます。 画面下側では過去データの検索結果を表示します。 これで乾燥対策もばっちりです。 次はDBに格納したデータを使っていろいろ試してみたいと思います。

こんにちは、SCSK株式会社の中野です。 Zabbixは、システム監視・運用に欠かせないオープンソースの監視ツールです。しかし企業や各種プロジェクトでは、外部インターネットに直接アクセスできない、「オフライン環境」でZabbixを導入しなければならないケースも多くあります。 通常の導入手順では、公式リポジトリやインターネット経由でのパッケージ取得が前提となっていますが、オフラインではこの方法は使えません。 本記事では、AWS環境に構築したRed Hat Enterprise Linux 9.6上に、Zabbix 7.0を「オフライン環境」で導入する手順についてご紹介します。 導入手順 今回の構成は以下とさせていただきます。 ZABBIX VERSION: 7.0 LTS OS DISTRIBUTION: Red Hat Enterprise Linux OS VERSION: 9 DATABASE: MySQL WEB SERVER: Apache SELinux: 無効 Firewalld: 無効 オフライン環境として、インターネットにアクセスできない状態を想定しています。そのため、Zabbixインストールに必要なファイルや依存パッケージは、事前に外部環境からダウンロードして持ち込む必要があります。 この記事では、Zabbix本体や必要なライブラリ・依存パッケージの準備からインストールまで、実際に試した手順をベースに解説します。 Zabbix関連パッケージのダウンロード オフライン環境でZabbixを導入するためには、事前に必要なパッケージ類をすべてダウンロードしておく必要があります。 今回は、yumコマンドの–downloadonlyオプションを利用して、Zabbix関連パッケージをまとめて取得します。 # 関連パッケージのダウンロード sudo yum install --downloadonly --downloaddir=/tmp/zabbix <パッケージ名> ※ <パッケージ名> はzabbix-server、zabbix-webなど必要なパッケージ名に置き換えてください この作業には、インターネットに接続されたオンライン環境のRHEL9サーバーが1台必要です。オンライン環境はあくまでダウンロード用に利用するだけなので、検証機や既存のRHEL9環境を流用しても構いません。 取得したパッケージはファイル転送コマンドや、USBメモリなどのメディアでオフライン環境へ持ち込んでください # 関連パッケージのダウンロード(mysql, httpd) sudo yum install --downloadonly --downloaddir=/tmp/mysql mysql-server sudo yum install --downloadonly --downloaddir=/tmp/httpd httpd # 関連パッケージのダウンロード(zabbix) rpm -Uvh https://repo.zabbix.com/zabbix/7.0/rhel/9/x86_64/zabbix-release-7.0-5.el9.noarch.rpm sudo yum install --downloadonly --downloaddir=/tmp/zabbix zabbix-server-mysql sudo yum install --downloadonly --downloaddir=/tmp/zabbix zabbix-web-mysql sudo yum install --downloadonly --downloaddir=/tmp/zabbix zabbix-web-japanese sudo yum install --downloadonly --downloaddir=/tmp/zabbix zabbix-apache-conf sudo yum install --downloadonly --downloaddir=/tmp/zabbix zabbix-sql-scripts sudo yum install --downloadonly --downloaddir=/tmp/zabbix zabbix-agent2 関連パッケージのインストール、DB初期設定 関連パッケージをダウンロードしましたので、オフライン環境でZabbixをインストールします。まずはMySQLとApacheをインストールします。 # MySQLのインストール dnf localinstall /tmp/mysql/* # MySQLのインストール dnf localinstall /tmp/httpd/* # データベースを起動 systemctl start mysqld systemctl enable mysqld 続いて、Zabbix用データベースを作成します。　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　DB名、アカウント名やパスワード環境に応じて設定いただければと思います。 # DBへの接続 mysql -uroot -p Enter password: （MySQLのrootアカウントのパスワードを入力） # DB、アカウントを作成 > CREATE DATABASE zabbix CHARACTER SET utf8mb4 COLLATE utf8mb4_bin; > CREATE USER zabbix@localhost IDENTIFIED BY 'zabbix'; > GRANT all privileges ON zabbix.* TO zabbix@localhost; > SET global log_bin_trust_function_creators = 1; > exit Zabbixサーバのインストール 続いてZabbixをインストールします。 # Zabbixサーバのインストール dnf localinstall /tmp/zabbix/* 続いて、Zabbix用データベースへ初期データをインポートします。 # DBへ初期データをインポート zcat /usr/share/zabbix-sql-scripts/mysql/server.sql.gz | mysql --default-character-set=utf8mb4 -uzabbix -p zabbix Enter password: （MySQLのzabbixアカウントのパスワードを入力） 初期データのインポート後、log_bin_trust_function_creatorsを無効にします。 # DBへの接続 mysql -uroot -p Enter password: （MySQLのrootアカウントのパスワードを入力） > SET global log_bin_trust_function_creators = 0; > exit その後、Zabbixサーバーの設定と起動を行います。 # 各パラメータ設定 /etc/zabbix/zabbix_server.conf DBHost=localhost DBName=zabbix DBUser=zabbix DBPassword=zabbix # サービスの起動 systemctl start zabbix-server zabbix-agent2 httpd php-fpm systemctl enable zabbix-server zabbix-agent2 zabbix-agent httpd php-fpm Zabbix WEBコンソールへのアクセス Zabbixのインストールは完了しましたので、Webコンソール上でセットアップしていきます。 ブラウザを立ち上げて、以下にアクセスします。 http://xxx.xxx.xxx.xxx/zabbix xxxには、今回構築したIPアドレスを入れてください。例えば、もしZabbixサーバーのIPアドレスが192.168.0.1なら、アドレスバーには”http://192.168.0.1/zabbix”と入力します。 言語を【日本語（ja_JP）】に変更して、【次のステップ】をクリックします。 すべての項目が「OK」になっていることを確認し、【次のステップ】をクリックします。 パスワード欄に先ほど設定したZabbixDBのパスワードを入力し、【次のステップ】をクリックします。 タイムゾーン欄で【(UTC+9:00) Asia/Tokyo】を選択、Zabbixサーバ名を記入し、【次のステップ】をクリックします。 設定内容に問題がなければ、【次のステップ】をクリックします。 【終了】をクリックすると、以下のようなログイン画面が表示されます。 初期状態でユーザーが登録されているので、以下のユーザー名・パスワードでログインします。 ユーザ名：Admin パスワード：zabbix ログインすると、WEBコンソール画面が表示されます。 以上でZabbixのインストールは完了です。 最後に 今回は、オフライン環境でのZabbix導入手順についてご紹介しました。ネットワークに接続できない制約がある場合でも、事前に必要なパッケージをダウンロードし、オフライン環境に持ち込むことでZabbixを導入することが可能です。 監視システムの導入は、障害の早期発見や安定稼働のために大変重要な作業です。Zabbixはオープンソースでありながら高機能な監視を実現できますので、ぜひ今回の記事を参考に、オフライン環境でもZabbixの導入・活用にチャレンジしてみてください。 オフライン環境ならではのハードルもありますが、事前準備をしっかり行うことで、その壁を乗り越えることができます。 本記事がみなさまの環境構築のお役に立てば幸いです。最後まで読んでいただき、ありがとうございました。

本記事は TechHarmony Advent Calendar 2025 12/7付の記事です 。 こんにちは！SCSKの安藤です。 毎年恒例、 TechHarmonyのアドベントカレンダー企画 です！🎉🎉🎉 今年は、前半の約3分の1日程で Zabbix枠 を頂くことになり、投稿のお誘いをいただきましたので参加させていただくことになりました。   はじめに Zabbixは、オープンソースの監視ソリューションとして世界中で利用されています。 その進化の方向性を示す「 Zabbix Roadmap 」と、Zabbix Conference Japan 2025での発表内容から、次期バージョン Zabbix 8.0 LTSの、注目すべきポイントを整理しました。   1. Zabbix 8.0 LTSのリリース時期 2026年Q2にリリース予定 以下のページには2026年Q1と記載ありますが、大方の予想はQ2とのことです。 Zabbix Life Cycle and Release Policy   2. Zabbix8.0LTSの注目機能 Conferenceのテーマと公式ロードマップの情報より、以下の注目機能があげられます。 オブザーバビリティの強化 OpenTelemetry対応、ログベース監視、クラウドネイティブ環境でのトレーシング モバイルアプリ刷新 iOS/Android対応で外出先から問題管理 イベント処理自動化 タグ変更、重複排除、カスタムJavaScript対応 ネットワーク監視強化 NetFlowデータ収集、リアルタイムストリーミング セキュリティ強化 SSO証明書UIアップロード、権限管理改善   オブザーバビリティの強化 監視からオブザーバビリティへ Zabbix8.0LTSの注目機能の１つとして、オブザーバビリティがあります。 「監視（Monitoring）」と「オブザーバビリティ（Observability）」は似ているようで、目的とアプローチが異なります。   監視（Monitoring） オブザーバビリティ（Observability） アプローチ システムや構成要素の状態を定常的に観察 閾値を設定してアラートを発報 システム内部の状態を把握するため、メトリクス・ログ・トレースなど多様なデータを収集・分析 問題発生時に「なぜ起きたか」を探ることが可能 目的 障害検出や稼働状態の把握 障害調査や原因分析 イメージ 症状の確認 診断と治療   監視では、なぜ問題が起きたかまでは分かりません。 環境やサービスが分散・分割され、変化し続けていくクラウドネイティブや分散システムでは、障害調査や原因分析に強いオブザーバビリティが不可欠です。   オブザーバビリティの構成要素 メトリクス ：CPU使用率、メモリ、ネットワークなど定量データ ログ ：アプリケーションやシステムのイベント記録 トレース ：複数サービス間のリクエストやトランザクションの流れ（※Zabbixは今後対応予定）   OpenTelemetry対応とテレメトリーの活用 Conferenceでは、 OpenTelemetry がオブザーバビリティ実現の鍵として紹介されました。 OpenTelemetryとは？ APM（アプリケーション性能管理）を実現するための標準規格 テレメトリーデータ送受信のプロトコル標準を定義し、APIやSDKを提供 テレメトリーとは？ OSやアプリケーションから送信される内部稼働状況のデータ Zabbix + OpenTelemetryの可能性 アプリ側でテレメトリーデータ送信処理を実装 高価なフル機能Observabilityツールを導入せず、既存Zabbix環境に部分的なテレメトリ監視を追加 将来的には、 アプリケーションのトランザクションをZabbixで監視できる世界 が実現   モバイルアプリ刷新 Zabbixのモバイルアプリが登場します。 新しいiOS/Android対応アプリでは、問題通知、履歴データ参照、問題管理が可能になり、外出先でも迅速な対応が実現します。 SREや運用担当者にとって、スマートフォンからの監視・管理は大きな利便性向上です。 実は随分前にはリリースされていたとの話もありますが、私は見かけたことはなく、公開されたら自分のスマホにインストールしてみたいと思っています！ イベント処理自動化 複雑なイベント管理を効率化するため、エンタープライズアラームコンソールが導入されます。 タグや重大度の変更、フィルタリング、重複排除、さらにカスタムJavaScriptによる高度なパターンマッチングが可能。 セキュリティ監視や不正検知にも活用でき、運用負荷を大幅に削減します。 ネットワーク監視強化 ネットワークの可視化と分析機能が強化されます。 NetFlowデータ収集・可視化により、帯域使用状況や通信経路を詳細に把握可能。 さらに、ネットワーク機器からのリアルタイムストリーミング対応で、異常検知のスピードが向上します。 セキュリティ強化 Zabbixのセキュリティ機能も進化します。 SSO証明書のUIアップロード により、認証設定がより簡単に。 また、プロキシやプロキシグループに対する 権限ベースの可視化モデル が導入され、アクセス管理がより安全で柔軟になります。     まとめ Zabbixは「監視」から「オブザーバビリティ」へ進化し、クラウドネイティブやSREのニーズに応える機能を拡充していきます。 Zabbix 8.0 LTS は、企業の監視基盤を次のレベルへ引き上げる重要なアップデートになるでしょう。   最後まで読んでいただき、ありがとうございました。明日のアドベントカレンダーもお楽しみに！ 弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。 ★Zabbixの基礎をまとめたeBookを公開しております！★ Zabbix資料ダウンロード｜SCSK Plus サポート for Zabbix Zabbix監視構築に必要な知識と最新機能についての資料をダウンロードできるページです。世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします。 www.scsk.jp   ★SCSK Plus サポート for Zabbix★ SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします。 www.scsk.jp   ★YouTubeに、SCSK Zabbixチャンネルを開設しました！★ SCSK Zabbixチャンネル SCSK Zabbixチャンネルでは、Zabbixのトレンドや実際の導入事例を動画で解説。明日から使える実践的な操作ナレッジも提供しており、監視業務の効率化に役立つヒントが満載です。 最新のトピックについては、リンクの弊社HPもしくはXアカ... www.youtube.com   ★X（旧Twitter）に、SCSK Zabbixアカウントを開設しました！★ https://x.com/SCSK_Zabbix x.com

本記事は TechHarmony Advent Calendar 2025 12/6付の記事です 。 皆さん、師走のZabbixライフを満喫していますか？こんにちは、SCSK株式会社 片井です。 今回はZabbixLTS Ver7.0で新しく実装されたZabbix APIメソッド「history.push」について紹介します。 Zabbix APIの基本的な使い方は、当ブログの記事「Zabbix APIの使用方法」にて解説していますので、まだ触ったことがない方は、 ぜひそちらからご覧ください。 Zabbix APIの使用方法 ZabbixはAPIが豊富に用意されており、データの抽出や外部システムとの連携が容易になっております。今回はcurlコマンドを使ってAPIを実行する方法を紹介いたします。 blog.usize-tech.com 2023.07.27 これは何？ シンプルに言うと「 Zabbixの各アイテムに監視データを送信できるAPI 」です。 history.push www.zabbix.com さらに言うと「APIで指定したアイテムに任意の監視データを投入し、その値がZabbixのヒストリデータとして検知・モニタリングできるようにする」機能です。 Zabbixは様々なアイテムのタイプが用意されており、幅広い監視に対応しています。 しかし中には以下のような要件で、 監視対象のホスト から Zabbixサーバ に対して、監視データを送りつけたいケースが存在 します。 NW制約の関係でZabbixサーバから監視対象のホストにポーリング（監視データを取りに行くこと）ができない Zabbixサーバから 定期的に データを取りに行くのではなく、 問題が起きた時にリアルタイムで データを送信→検知させたい 上記は一例ですがこういったケースの場合、おなじみの「Zabbix Agent」や、後述する「Zabbix sender」、 そして今回紹介するhistory.pushメソッドを活用することによって、 監視対象ホスト→Zabbixサーバという方向でのデータ送信 によるリアルタイム監視を行うことができます。 具体的な処理の流れは以下のようになります。 監視機器など監視される側のホストから、curlなどHTTPクライアントを使用して、監視データをZabbix WebUIのAPIエンドポイントにPOSTする POSTされたリクエストは、まずZabbix WebUIが受け取る APIキーを元に認証されたデータは、その後ZabbixサーバによってDBに書き込まれる 既存方式の紹介 – Zabbix sender ここまでの話を聞くと、Zabbix経験者の方は「 あれ？それって”Zabbix sender”と同じじゃない？ 」と思われるかもしれません。 「Zabbix sender」とは、一言でいうと監視データをZabbixサーバに送信するためのコマンドラインユーティリティです。 6 zabbix_senderコマンド www.zabbix.com APIとコマンドラインユーティリティということで方式は異なりますが、実現される機能としてはほぼ同一です。 Zabbix senderも同様に各アイテムに監視データを投入、ヒストリデータとして検知/モニタリングすることができます。 上記の方式の違いについては後述します。 使ってみよう 実際に使ってみましょう。 事前準備 今回はAPI実行が内容に含まれます。API実行が実践できていない方は、先に下記URLの[データの単純取得]が出来るところまで進めてみてください。 Zabbix APIの使用方法 ZabbixはAPIが豊富に用意されており、データの抽出や外部システムとの連携が容易になっております。今回はcurlコマンドを使ってAPIを実行する方法を紹介いたします。 blog.usize-tech.com 2023.07.27 APIパラメータ 今回の手順で必要なパラメータは以下になります。 パラメータ 入力内容 アイテムID 監視データを投入したいアイテムのID ヒストリデータ 監視データの内容(ステータスの場合:FAILED,SUCCESSなど任意の数値/テキスト) UNIX時刻 Zabbixで監視データ取得時刻として扱われる時刻 ※ZabbixはUNIXタイムで監視データを時刻管理するため形式を合わせる ナノ秒 監視データ取得時刻の重複回避のために参照される時刻、ナノ秒単位で入力   実施手順 Zabbix WebUIのURLに対して、http/httpsで疎通可能なサーバにログインしてください。 以下のcurlコマンドを実行してください。(LinuxOS,curlコマンドインストール環境を想定しています) curl -s -k -d ' { "auth": "<APIキー>", "method": "history.push", "id": 1, "params": [ { "itemid": <アイテムID>, "value": <ヒストリデータ>, "clock": <UNIX時刻>, "ns": <ナノ秒> } ], "jsonrpc": "2.0" } ' -H "Content-Type: application/json-rpc" http://<ZabbixURL>/zabbix/api_jsonrpc.php | jq '.result' curlコマンド実行後、以下のように応答結果が返ってきます。 今回は”6″という監視データの値を、ID:48474のアイテムに投入しています。                 ※失敗した場合は、errorのカラムとerror内容が出力されます。 ZabbixのWebUIで投入先のアイテム最新データを見ると、入力したパラメータに従って、”6″の監視データが アイテムのヒストリデータとして投入されていることが分かります。   注意点 アイテムタイプは 「Zabbixトラッパー」 もしくは 「HTTPエージェント」タイプで[トラッピングの有効化]のオプションを指定 することが必須になります。 そのため例えば、 「Zabbixエージェント」のアイテムタイプを指定して、普段は監視データをエージェントから取得、問題が起きた際にhistory.pushで直接監視データを投入する 、といった使い方は不可になります。 後述のZabbix senderとの比較で記載していますが、 データ送信先はZabbixサーバではなく、Zabbix WebUIのURL になります。 そのため、上記WebUIがZabbixサーバから独立している構成の場合は、WebUIサーバとの疎通が確保されている必要があります。 Zabbix senderとの比較 冒頭でZabbix Senderと機能が似ていると触れましたが、実際には以下のような比較ポイントがあります。 比較項目 History Push API Zabbix sender ソフトインストール HTTP,JSON関連ライブラリがインストール済みであれば不要 Zabbix Senderのインストール必須 監視データ送信先 Zabbix WebUI Zabbixサーバまたは Zabbixプロキシ データ形式 JSON形式 Zabbix Senderコマンド/Senderプロトコル （内部的にはJSON形式で処理） 使用ポート Zabbix WebUI のHTTP,HTTPSポート(80, 443) Zabbixサーバまたは Zabbixプロキシ の Trapperポート（デフォルト: 10051） セキュリティ認証 APIトークンベースでの認証 なし（Zabbixサーバ側設定で監視データを受け入れるIPを指定）   インストールさえできれば、データ形式の観点からAPI実行文とコマンド文を書く労力の差でZabbix Senderの方が手軽な印象です。 より対応幅が広いのはhistory.push方式になります。エージェントレスの監視をせざるを得ない、アプライアンス機器やアプリ製品では、Zabbix Senderはインストールできないが、HTTP関連ライブラリとJSONは扱える、というケースが多いです。 セキュリティ観点では、API認証で認証情報を管理できるhistory.push方式の方がよりセキュアです。 まとめと今後の展望 今回は、監視データ送信方法として、history.push APIの紹介をさせていただきました。 監視データ送信については、既存の方式としてZabbix senderがありますが、上記比較のように使い分けができるポイントが何点かあるため、 これまでZabbix senderでは実現できなかったと諦めていた監視についても、この実装を機に再考してみてはいかがでしょうか？ 所感ですが、生成AIの活用によりZabbix APIの学習・作成コストが非常に低減されており、Zabbix sender方式とのコスト差がより縮まっていくと感じています。 上記比較のように、history.pushはsender方式と比較して、よりセキュア・モダンな方法での監視方式となり、 今後Zabbixのセキュリティ要件がより厳格に求められる方向性で発展していった際は、こういった方式でのデータ投入が必須になっていくのではないでしょうか。 SCSK Plus サポート for Zabbix SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします。 www.scsk.jp ★YouTubeに、SCSK Zabbixチャンネルを開設しました！★ SCSK Zabbixチャンネル SCSK Zabbixチャンネルでは、Zabbixのトレンドや実際の導入事例を動画で解説。明日から使える実践的な操作ナレッジも提供しており、監視業務の効率化に役立つヒントが満載です。 最新のトピックについては、リンクの弊社HPもしくはXアカ... www.youtube.com ★X（旧Twitter）に、SCSK Zabbixアカウントを開設しました！★ https://x.com/SCSK_Zabbix x.com

こんにちは、ひるたんぬです。 この度「 AWS re:Invent 2025 」に参加できることになりましたので、現地での出来事や参加したセッションについてのレポートをお送りしたいと思います！ 今回は、最終日の出来事を振り返ります！ 半日しか開催がないため内容が少なくなっている点、ご了承ください。 Day 5 最終日は午前中のみの開催です。 ▼ 朝6時半頃に撮影した光景。朝焼けと月のコラボが美しかったです。 Build trustworthy AI applications with Amazon Bedrock Guardrails 最後はWorkShopに参加しました。 このWorkShopではAmazon Bedrock Guardrailsを用いて信頼できるAIアプリケーションを構築することが目的です。 Amazon Bedrock Guardrailsについては、下記記事をご参照ください。 Bedrock ガードレール 生成 AI のユースケースと責任ある AI ポリシーに合わせてカスタマイズされたガードレールを使用して LLM を保護します。 aws.amazon.com 企業がAIアプリケーションを導入する上の課題は主に「規則・規制」と「監査」の二点です。 前者は例えばEUの法令や各企業のガバナンスルールを指し、後者は、例えば医療分野や金融分野においてAIを利活用して判断した根拠を提示できるか、という点です。 特に後者では「ハルシネーション」のリスクがあり、これにおける対策としては人間によるチェックが行われている現状があります。この現状により思うように生成AIを活用することによる生産性向上に繋がっていないということが課題です。 ある報告書によると、労働者は週4.3時間（週の労働時間の約10%）を上記のチェック作業に費やしているようです。 The Reality of AI Hallucinations in 2025 - Drainpipe.io By: Dominick Romano and Chris Gaskins Introduction AI hallucinations are a consistent and unwanted behavior exhibited by... drainpipe.io この問題に対処するために「Amazon Bedrock Guardrails」があります。 今回のWorkShopでは、航空会社のラウンジアクセスというユースケースを対象として、Amazon Bedrock Guardrailsの機能・効果を体験しました。 ▼ 自動推論ポリシーの定義。ポリシーのテストもコンソール上から実行できます。 ▼ ガードレールの作成。自動推論ポリシーもここからアタッチします。 ▼ ガードレールのテスト。ポリシーに準拠しているかのテストが実施されています。 ※ 画面右下Automated Reasoning内に、ポリシーのテスト結果が表示されます。   終わりに AWS re:Invent 2025はこれにて終了です。 参加前は「一週間なんて長いな…」という思いもあったのですが、いざ始まってみると一瞬で過ぎ去ってしまいました。 それだけ充実した日々を過ごすことができたのだと思います。 一方、日本には「家に帰るまでが遠足」という言葉があります。 私も「家に帰るまでがre:Invent」と肝に銘じ、帰国・帰宅するまで安全を最優先に過ごしたいと思います。 初日から最終日まで5日間にわたり連続投稿をしておりましたが、本投稿にて連続投稿は終了となります。 次回は帰国・振り返り編を投稿予定ですので、お楽しみに！

こんにちは、ひるたんぬです。 この度「 AWS re:Invent 2025 」に参加できることになりましたので、現地での出来事や参加したセッションについてのレポートをお送りしたいと思います！ 今回は、四日目の出来事を振り返ります！ 今回の記事も比較的写真が多めの記事となります。ご了承くださいませ。 Day 4 re:Inventもいよいよ終盤に差し掛かってきました！ 今日も目玉イベントが目白押しです！ BuilderCards受け取り まずは、BuilderCardsを受け取りに行きました。 最近、弊社内でもBuilderCardsの普及に取り組まれている方がおり、少しずつではありますが、社内の認知度も高まっているのではないかと思っております。 Day 4に来た理由としては、この日に日本語版が配布される、ということだったのですが、配布時間は夕方頃とのこと… 残念ではありましたが、英語版のBuilderCardsはいただけたので、ひとまず目標は達成です。 ▼ BuilderCards受け取り。私の前後にも多くの日本人の方がいらっしゃっていました。 ▼ 実際にBuilderCardsで遊べるブースも。 Sports Forum見学 ここではAWSの技術を利活用している様々なスポーツ分野を知る・体験することができます。 詳細は、下記記事をご参照ください。 AWS re:Invent 2025 Sports Forum | Amazon Web Services See how AWS helps professional sports organizations come to life. Don’t miss the chance to watch, play, and experience s... reinvent.awsevents.com ▼ やはり、アメリカンスポーツと言ったらアメフト、なんですかね。 ▼ AIでシュミレーションするゴルフ いくつかの戦略（パラメータ）を設定し、カップインを狙います。 ラスベガスでF1が開催されたこともあってか、F1に関する展示が数多くありました。 ▼ AWSが活用されている場面 @F1 映像配信やラップタイムの分析にAWS基盤が用いられているようです。 F1におけるラップタイム分析（Track Pulse）の詳細は、下記記事をご参照ください。 Real-time storytelling: The AWS architecture behind Formula 1® Track Pulse | Amazon Web Services On a FORMULA 1® (F1) race day, broadcasts face a significant challenge: identifying the most impactful stories for fans ... aws.amazon.com ▼ F1のタイヤ交換体験 実際に参加しましたが、ホイールガンがとても重かったです。逆にタイヤは軽かったです。 ▼ ここで偶然S3くん？に遭遇。ハグかと思いきや…抱っこされました。 ※ 顔が驚きすぎていたので、モザイクをさせていただきました… Optimize mission critical workloads with CloudWatch MCP & Amazon Q CLI Amazon Q CLIはKiro CLIに改名されましたが、本WorkShopでは旧名称だったので、本記事では旧名称に統一します。 続いて、WorkShopに参加しました。 WorkShopは個人作業で手を動かしながらサービスについて学ぶことができるセッションです。 このセッションでは、MCPサーバを構成し、様々な人間の立場からAmazon Q CLIでトラブルシューティングする流れを体験しました。 ▼ 使用したMCPサーバーの一つ。 この他にもAWSから提供されているMCPサーバーは数多く存在します。 AWSが提供するMCPサーバーについては、下記記事をご参照ください。 Welcome to AWS MCP Servers | AWS MCP Servers Get started with AWS MCP Servers and learn core features. awslabs.github.io また、人間の持つ役割に応じた権限設定を実現するためのガードレールについても紹介されていました。 エージェントの作成方法は、下記記事をご参照ください。 Creating custom agents - CLI - Docs - Kiro Learn how to create and configure custom agents for specialized workflows kiro.dev ▼ エージェントを業務の役職ごと複数定義し、役職外の操作を行おうとした場合 今回のWorkShopでは、hookに特定の条件下でエラーを発生させる（操作を拒否する）コマンドを入力していました。 hooksなどのConfigurationの設定方法は、下記記事をご参照ください。 Agent configuration reference - CLI - Docs - Kiro Complete reference for agent configuration file format kiro.dev A Special Closing Keynote with Dr. Werner Vogels Werner氏によるクロージングのKeyNoteです。 初日にサイン本をいただいたこともあり、必ず参加したかったものです。 Werner氏は今年のre:InventにてKeyNoteでの登壇を引退されるとのことだったので、今回が最後となるようです。 ▼ KeyNote開始前は弦楽器の生演奏でした。Werner氏のKeyNoteでは定番の演出のようです。 雰囲気がガラッと変わっていて、これも良かったです。 ▼ 過去の登壇映像とともに登場するWerner氏 ▼ 今回のテーマは「The Renaissance Developer」です。 Werner氏が実際に紹介していた「The Renaissance Developer」に関する参考記事は下記に記載しております。 The Kernel A one of a kind re:Invent newspaper. thekernel.news ▼ 「The Renaissance Developer」に求められる事項をまとめています。 また、KeyNote内でWerner氏が読むべき宿題として与えていた文献は下記の記事です。 私もこの宿題に取り組もうと思います。 Leverage Points: Places to Intervene in a System - The Donella Meadows Project By Donella Meadows~ Folks who do systems analysis have a great belief in “leverage points.” These are places within a co... donellameadows.org Werner氏のKeyNoteでは、以下の点が個人的には印象的でした。 仕事は「あなた（人間）」のもの。ツール（AIなど）のものではない → 仕事に対しては人間が責任を持ち続ける必要がある 人間同士の会話は曖昧性があるが、人間とコンピュータとの会話は厳密なものだった。 しかし、AIを含む自然言語処理技術の登場により、人間とコンピュータとの会話も曖昧になった。 → 人間とコンピュータの会話に齟齬が生じるリスクが出てくる → これを自然言語で厳密に会話していく仕組みが仕様駆動開発である Werner氏から贈られたメッセージは、日本に帰国してからももう一度ゆっくり噛み締めたいと思いました。 気になる方は、是非下記リンクより動画をご覧ください。 - YouTube YouTube でお気に入りの動画や音楽を楽しみ、オリジナルのコンテンツをアップロードして友だちや家族、世界中の人たちと共有しましょう。 www.youtube.com re:Play re:Inventの締めくくりと言ったら、おそらくこのイベント。 今までセッションが開催されていた会場とは異なる屋外でのイベントです。 re:Playについての詳細は、下記記事をご参照ください。 AWS re:Invent 2025 re:Play | Amazon Web Services You’ve earned it. Celebrate the end of another successful AWS re:Invent with the greatest party in tech. reinvent.awsevents.com ▼ 会場の様子。このイベントのためだけに広大な敷地に様々なアトラクションがあります。 ▼ バドミントンのコートも！皆さんre:inventでの思い出を残すべく楽しまれていました。 ▼ 弊社re:Invent参加メンバーで一枚。 初参加のメンバーが多かったですが、それぞれが充実した日々を過ごすことができました。 終わりに Werner氏のKeyNoteを初めて現地で見ましたが、エンジニアの一員として働く身に刺さる内容ばかりで、改めて現地で講演を見ることができて光栄だなと思った次第です。 いよいよre:Inventも明日（の午前中）で終了となります…！ 驚くほどあっという間に時間が過ぎていきました。。 次回の投稿も引き続きお楽しみに！

こんにちは、ひるたんぬです。 この度「 AWS re:Invent 2025 」に参加できることになりましたので、現地での出来事や参加したセッションについてのレポートをお送りしたいと思います！ 今回は、四日目の出来事を振り返ります！ 今回の記事も比較的写真が多めの記事となります。ご了承くださいませ。 Day 4 re:Inventもいよいよ終盤に差し掛かってきました！ 今日も目玉イベントが目白押しです！ BuilderCards受け取り まずは、BuilderCardsを受け取りに行きました。 最近、弊社内でもBuilderCardsの普及に取り組まれている方がおり、少しずつではありますが、社内の認知度も高まっているのではないかと思っております。 Day 4に来た理由としては、この日に日本語版が配布される、ということだったのですが、配布時間は夕方頃とのこと… 残念ではありましたが、英語版のBuilderCardsはいただけたので、ひとまず目標は達成です。 ▼ BuilderCards受け取り。私の前後にも多くの日本人の方がいらっしゃっていました。 ▼ 実際にBuilderCardsで遊べるブースも。 Sports Forum見学 ここではAWSの技術を利活用している様々なスポーツ分野を知る・体験することができます。 詳細は、下記記事をご参照ください。 AWS re:Invent 2025 Sports Forum | Amazon Web Services See how AWS helps professional sports organizations come to life. Don’t miss the chance to watch, play, and experience s... reinvent.awsevents.com ▼ やはり、アメリカンスポーツと言ったらアメフト、なんですかね。 ▼ AIでシュミレーションするゴルフ いくつかの戦略（パラメータ）を設定し、カップインを狙います。 ラスベガスでF1が開催されたこともあってか、F1に関する展示が数多くありました。 ▼ AWSが活用されている場面 @F1 映像配信やラップタイムの分析にAWS基盤が用いられているようです。 F1におけるラップタイム分析（Track Pulse）の詳細は、下記記事をご参照ください。 Real-time storytelling: The AWS architecture behind Formula 1® Track Pulse | Amazon Web Services On a FORMULA 1® (F1) race day, broadcasts face a significant challenge: identifying the most impactful stories for fans ... aws.amazon.com ▼ F1のタイヤ交換体験 実際に参加しましたが、ホイールガンがとても重かったです。逆にタイヤは軽かったです。 ▼ ここで偶然S3くん？に遭遇。ハグかと思いきや…抱っこされました。 ※ 顔が驚きすぎていたので、モザイクをさせていただきました… Optimize mission critical workloads with CloudWatch MCP & Amazon Q CLI Amazon Q CLIはKiro CLIに改名されましたが、本WorkShopでは旧名称だったので、本記事では旧名称に統一します。 続いて、WorkShopに参加しました。 WorkShopは個人作業で手を動かしながらサービスについて学ぶことができるセッションです。 このセッションでは、MCPサーバを構成し、様々な人間の立場からAmazon Q CLIでトラブルシューティングする流れを体験しました。 ▼ 使用したMCPサーバーの一つ。 この他にもAWSから提供されているMCPサーバーは数多く存在します。 AWSが提供するMCPサーバーについては、下記記事をご参照ください。 Welcome to AWS MCP Servers | AWS MCP Servers Get started with AWS MCP Servers and learn core features. awslabs.github.io また、人間の持つ役割に応じた権限設定を実現するためのガードレールについても紹介されていました。 エージェントの作成方法は、下記記事をご参照ください。 Creating custom agents - CLI - Docs - Kiro Learn how to create and configure custom agents for specialized workflows kiro.dev ▼ エージェントを業務の役職ごと複数定義し、役職外の操作を行おうとした場合 今回のWorkShopでは、hookに特定の条件下でエラーを発生させる（操作を拒否する）コマンドを入力していました。 hooksなどのConfigurationの設定方法は、下記記事をご参照ください。 Agent configuration reference - CLI - Docs - Kiro Complete reference for agent configuration file format kiro.dev A Special Closing Keynote with Dr. Werner Vogels Werner氏によるクロージングのKeyNoteです。 初日にサイン本をいただいたこともあり、必ず参加したかったものです。 Werner氏は今年のre:InventにてKeyNoteでの登壇を引退されるとのことだったので、今回が最後となるようです。 ▼ KeyNote開始前は弦楽器の生演奏でした。Werner氏のKeyNoteでは定番の演出のようです。 雰囲気がガラッと変わっていて、これも良かったです。 ▼ 過去の登壇映像とともに登場するWerner氏 ▼ 今回のテーマは「The Renaissance Developer」です。 Werner氏が実際に紹介していた「The Renaissance Developer」に関する参考記事は下記に記載しております。 The Kernel A one of a kind re:Invent newspaper. thekernel.news ▼ 「The Renaissance Developer」に求められる事項をまとめています。 また、KeyNote内でWerner氏が読むべき宿題として与えていた文献は下記の記事です。 私もこの宿題に取り組もうと思います。 Leverage Points: Places to Intervene in a System - The Donella Meadows Project By Donella Meadows~ Folks who do systems analysis have a great belief in “leverage points.” These are places within a co... donellameadows.org Werner氏のKeyNoteでは、以下の点が個人的には印象的でした。 仕事は「あなた（人間）」のもの。ツール（AIなど）のものではない → 仕事に対しては人間が責任を持ち続ける必要がある 人間同士の会話は曖昧性があるが、人間とコンピュータとの会話は厳密なものだった。 しかし、AIを含む自然言語処理技術の登場により、人間とコンピュータとの会話も曖昧になった。 → 人間とコンピュータの会話に齟齬が生じるリスクが出てくる → これを自然言語で厳密に会話していく仕組みが仕様駆動開発である Werner氏から贈られたメッセージは、日本に帰国してからももう一度ゆっくり噛み締めたいと思いました。 気になる方は、是非下記リンクより動画をご覧ください。 - YouTube YouTube でお気に入りの動画や音楽を楽しみ、オリジナルのコンテンツをアップロードして友だちや家族、世界中の人たちと共有しましょう。 www.youtube.com re:Play re:Inventの締めくくりと言ったら、おそらくこのイベント。 今までセッションが開催されていた会場とは異なる屋外でのイベントです。 re:Playについての詳細は、下記記事をご参照ください。 AWS re:Invent 2025 re:Play | Amazon Web Services You’ve earned it. Celebrate the end of another successful AWS re:Invent with the greatest party in tech. reinvent.awsevents.com ▼ 会場の様子。このイベントのためだけに広大な敷地に様々なアトラクションがあります。 ▼ バドミントンのコートも！皆さんre:inventでの思い出を残すべく楽しまれていました。 ▼ 弊社re:Invent参加メンバーで一枚。 初参加のメンバーが多かったですが、それぞれが充実した日々を過ごすことができました。 終わりに Werner氏のKeyNoteを初めて現地で見ましたが、エンジニアの一員として働く身に刺さる内容ばかりで、改めて現地で講演を見ることができて光栄だなと思った次第です。 いよいよre:Inventも明日（の午前中）で終了となります…！ 驚くほどあっという間に時間が過ぎていきました。。 次回の投稿も引き続きお楽しみに！

本記事は TechHarmony Advent Calendar 2025 12/5付の記事です 。 メリークリスマス、SCSK株式会社の小寺崇仁です。 （今回はAIを使ってブログ記事を作成しています） 近年、監視ツールの分野では「 APM（Application Performance Monitoring） 」と「 オブザーバビリティ（Observability） 」というキーワードが急速に注目されています。APMはアプリケーションの応答時間・エラー率・リソース使用率といった性能指標を監視して問題を発見します。一方オブザーバビリティは、複数のメトリックス、ログ、トレースを相関的に分析し、より深い原因究明を可能にする考え方です。 監視の世界は数値監視から文字列監視、そして今――画像を解析対象とする「 画像監視 」へと進化しつつあります。各製品がオブザーバビリティ機能を強化する中、 ZabbixもVersion 8.0から本格的に対応 を進めています。 以下では、「Zabbix × AI によるサンタクロース検知」を題材に、画像監視の新たな可能性を実験的に紹介します。 なぜ今「画像監視」なのか 従来の監視はCPU負荷やメモリ、サービス応答時間といった定量的なメトリックス中心でした。しかし、数値では表せない現場の状態――防犯カメラ、天候、道路状況、作業手順の逸脱など――にも重要な監視情報が存在します。 画像を監視対象とすることで、人間の「目」が担っていた判断を自動化し、監視の範囲を飛躍的に拡張できます。これが「オブザーバビリティの次の段階」と考えられます。 検証概要：Zabbix×AIによるサンタクロース検知 本実験の目的は、Zabbixを中心にAI画像解析を連携し、視覚的なイベントを監視対象にできるかを検証することです。 実際には作業PCのカメラが撮影した画像をZabbixに送信し、AIがその画像内に「サンタクロースらしいもの」が写っているか判定します。 今回はAI環境に ローカルLLM（Large Language Model） を採用しました。クラウドAIを利用する場合、API利用料や画像送信の通信コストが発生しますが、ローカル運用であれば コストを抑制し、内部データを安全に処理 できます。GPUを搭載したPC上で動作することで、 クラウドコストゼロ・低遅延・オフライン分析 を同時に実現できました。 検証環境構成 作業PC環境 機種：弊社標準ノートPC（Let’sNote） カメラ操作：PowerShell＋FFmpegをユーザーパラメータ経由で実行 データ送信：撮影画像をBase64変換しZabbixへ送信 Zabbix環境 仮想アプライアンス：ZV-700 構成：CPU 2コア / メモリ 4GB AI解析環境 CPU：Ryzen 5 7600 メモリ：32GB GPU：RTX 4060 AI実行環境：WSL2＋Docker＋Ollama AIモデル：llama3.2-vision（ローカルLLM） 実装手順 1. カメラ撮影設定（作業PC側） FFmpegのインストール winget install ffmpeg 撮影スクリプト（photo.ps1） $CamName="USB HD Webcam" $FfmpegPath="C:\Users\scsk-kodera\AppData\Local\Microsoft\WinGet\Packages\Gyan.FFmpeg_Microsoft.Winget.Source_8wekyb3d8bbwe\ffmpeg-8.0.1-full_build\bin\ffmpeg.exe" $FilePath="C:\zabbix\photo.jpg" & $FfmpegPath -y -f dshow -i "video=$CamName" -frames:v 1 $FilePath -loglevel quiet 2>&1 | Out-Null $Bytes = Get-Content -Path $FilePath -Encoding Byte -Raw $Base64String = [System.Convert]::ToBase64String($Bytes) Write-Output $Base64String Zabbix Agent設定 UserParameter=get.file.photo[*],"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -ExecutionPolicy Bypass -File "C:\zabbix\photo.ps1" 2. 画像監視設定（Zabbix側） (1) 撮影アイテム 名前 撮影アイテム アイテムキー get.file.photo 監視間隔 1m (2) 画像保存アイテム 名前 画像アイテム タイプ 依存アイテム データ型 バイナリ マスターアイテム 撮影アイテム (3) AI画像判定アイテム 名前 サンタクロース判定アイテム タイプ 依存アイテム データ型 文字列 マスターアイテム 撮影アイテム 保存前処理（Javascript） AI_URL = 'http://192.168.0.244:11434/api/generate' ai_req = new HttpRequest(); ai_data = { "model": 'llama3.2-vision', "prompt": 'Does the person in the image look like Santa Claus? Answer only with "yes" or "no".', "images": [value], "stream": false, "options": { "num_predict": 5, "temperature": 0.0 } }; ai_resp = ai_req.post(AI_URL, JSON.stringify(ai_data)); ai_resp = JSON.parse(ai_resp); return ai_resp.response; ※ここでプロンプトを指定しています (4) トリガー設定 名前 サンタクロース検知 条件式 find(/pc/san,,,”Yes”)=1 3. AI環境構築 # Ubuntu導入 wsl --install -d Ubuntu-22.04 wsl -d Ubuntu-22.04 # Dockerセットアップ sudo mkdir -m 0755 -p /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y # Nvidiaのドライバ設定 curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg distribution=$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list | \ sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \ sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list apt install -y nvidia-container-toolkit # Ollama起動（ローカルLLM） docker run -d --gpus all -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama docker exec -it ollama ollama pull llama3.2-vision # Windows側からアクセス設定 netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=11434 connectaddress=172.23.36.218 connectport=11434 検証結果 定期監視で撮影された画像がZabbix上に表示され、AI判定結果（Yes/No）が確認できます。サンタの風船を写したタイミングではAIが「YES」と回答し、トリガーが検知しました GPUリソースが正しく利用されており、ローカルLLMによる推論が安定して実行されています。クラウドに画像を送信しない設計のため、セキュリティ面でも保護された構成となりました。 注意点 Zabbixの保存前処理のタイムアウトは10秒です（変更不可）。 AI処理にはGPU性能が大きく影響します。 クラウド利用料やAPIトークンコストを避けるため、ローカルLLMを活用しています。 レスポンスを安定させるため、「num_predict=5」「temperature=0.0」でYes/No回答に限定しています。 まとめと今後の展望 今回のアドベントカレンダー記事では「サンタクロース検知」を通して、Zabbix×AI連携の新しい監視アプローチを検証しました。AI解析にはローカルLLM（llama3.2-vision）を活用し、クラウド依存のない低コスト・セキュアな画像監視基盤を構築しています。 今後の展開としては、AIを使った画像監視の高度化 が期待されます。 AIが物体や動きのパターンを学習することで、単純な「Yes/No判定」から「異常検知」「状態分類」「傾向分析」へとステップアップし、よりインテリジェントな監視が可能になります。 製造ラインでの品質検査や異常検知 天候・災害監視の自動化 道路交通や防犯映像のリアルタイム分析 オフライン環境でのローカルAI監視 OSSとAIによるオブザーバビリティ拡張の未来―― Zabbix × ローカルLLMによる AIを使った画像監視 が、監視の新しい形を切り開こうとしています。 SCSK Plus サポート for Zabbix SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします。 www.scsk.jp ★YouTubeに、SCSK Zabbixチャンネルを開設しました！★ SCSK Zabbixチャンネル SCSK Zabbixチャンネルでは、Zabbixのトレンドや実際の導入事例を動画で解説。明日から使える実践的な操作ナレッジも提供しており、監視業務の効率化に役立つヒントが満載です。 最新のトピックについては、リンクの弊社HPもしくはXアカ... www.youtube.com ★X（旧Twitter）に、SCSK Zabbixアカウントを開設しました！★ https://x.com/SCSK_Zabbix x.com

こんにちは、ひるたんぬです。 この度「 AWS re:Invent 2025 」に参加できることになりましたので、現地での出来事や参加したセッションについてのレポートをお送りしたいと思います！ 今回は、三日目の出来事を振り返ります！ 今回の記事も比較的写真が多めの記事となります。ご了承くださいませ。 Day 3 5K Race Day 3では、re:Invent定番のイベントの一つと言っても過言ではない「5K Race」が開催されます！ 一言で言うと、日の出時刻辺りからラスベガス市街を5km走る、というイベントです。 イベント概要は、以下をご覧ください。 AWS Builder Center Connect with builders who understand your journey. Share solutions, influence AWS product development, and access useful... builder.aws.com 私は初日に参加受付をしていたので、朝5時に起床して会場に向かいました。 ▼ 事前受付後にもらえるゼッケン。ゼッケン（左側の白い帯）にはタイムを記録するためのタグが埋まっているようでした。 ホテルからスタート地点の会場まではバスによる送迎があります。あらゆるイベントにおいて、送迎があるのはとても助かります。 ▼ ウォーミングアップ会場。飲み物や軽食が提供されます。 ▼ レース中。朝の気温は約7℃でしたが、走るにはちょうどよい気候でした。 ▼ やっとの思いでゴール！記念にチェキも撮ってもらえます。 ゴール後は、専用のサイトから自分の順位やタイムを確認することができます。 私は30分程度でゴールできたのですが、半分くらいの順位でした。 上位の方は20分かからずゴールしているので…こちらの攻略は難儀を極めそうです。 ▼ 私の結果。専用のサイトより記録をエクスポートすることができます。 なお、余談ですが当日のレースの様子がFOX Newsに取り上げられているようですね。 ※ あくまで道路封鎖のお知らせですが… Amazon conference 5K shuts down I-15 off-ramp near Las Vegas Strip Amazon’s Web Service conference is in town this week, and every year, attendees participate in a 5K. www.fox5vegas.com AWS Jam: Generative AI 次はAWS Jamへの参加です。 こちらは「NVIDIA」がスポンサーのセッションなので、内容も生成AIに関するものでした。 ▼ 事前説明での一節。生成AIやエージェンティックAIを使いこなし、2026, 2027年以降に備えよう！と説明がありました。 今回は日本人4人でのチームで参加し、前回（Day 1）の参加経験を踏まえて挑みました。 意識したことは、 取り組む問題テーマをチームメンバーと話し合って決める （それぞれの経験有無等によって、取り組む問題の難易度や分野を分けたい） 二問目以降に取り組むときは取り組むテーマを宣言する （同じテーマに取り組んで時間ロスが起きることを防ぐ） ヒントは臆せず使う （30分悩んだ30点よりも、15分で解いた20点を意識する） → 時間が余るということは無さそうだったので、ひたすら解くことを優先するようにしました いざ、ゲーム開始です！ ▼ 途中経過。上位3チームには順位を示す風船が置かれました。 私たちのチームは3位、2位…と調子が良いです！！ 問題と格闘すること約3時間。あっという間に終了しました。 さて、気になる私たちの順位は…？ 4位…惜しい！入賞まで70ポイント弱の差でした。 前回が真ん中（30位前後）であったことを考えると、内容やチームメンバーが変わっているのでなんとも言えないところではありますが、戦略の方向的には間違っていなかったのかなと感じました。 次回こそは、入賞…いや優勝したいですね。。 チーム名「EDLEN」の由来は、テーブルに置いてあったコンセントタップに書かれていた単語です。 記事執筆時に調べたところ、ラスベガスにあるイベントでの用品レンタル会社のようでした… 問題に取り組む中でKiroのSpec駆動開発やVibeコーディングをしたり、MCPサーバの利用設定をしたり…生成AIならではの作業やプロセスが一部でも体験できたことは非常に有意義でした。 ただしJamの形式上、入賞を目指し時間を意識して取り組んだので、改めてゆっくり時間をかけて触れたいなと思いました。 終わりに 三日目は名物のマラソンからAWS Jam参加…と、頭も体もフル活用した一日となりました。 re:Inventも残すところ後二日…最後まで満喫したいと思います！ 次回以降の投稿も引き続きお楽しみに！

こんにちは！2年目の秋葉です！ 入社2年目でまだまだ勉強中ですが、最近業務で「 Amazon FSx for Windows File Server（以下FSx） 」を触る機会がありました。 その中で、“PowerShellからシャドーコピーを設定してみる” という作業を経験したので、 同じようにFSxを扱う方や、これからPowerShell操作にチャレンジする方へ向けて、私の学びを共有したいと思います。 FSx、ボリュームシャドーコピーとは ここで、本記事の要となるFSx・シャドーコピーについて簡単に説明します。 FSx ：WindowsファイルサーバーをAWS上にまるごと構築してくれるマネージドサービスです。 ボリュームシャドーコピー ：ファイルやフォルダの過去バージョンを自動的に保存しておく仕組み 似た言葉で「スナップショット」といわれるものがありますが、シャドーコピーはあくまで「 仕組み 」です。 スナップショットはシャドーコピーで作成される成果物だと考えましょう。   今回使用する構成図 今回はWorkSpacesを使用してFSxのボリュームシャドーコピーを設定していきます。 AWS WorkSpacesとは、AWSが提供するマネージド型の仮想デスクトップサービスです。 クラウド上にWindowsまたはLinuxデスクトップ環境を構築でき、利用ユーザーは自宅や社内、出張先など、 どこからでも安全にアクセスできるようになります。 PowerShellからFSxに接続してみる 早速、WorkSpacesに接続してPowerShellを起動します。 ここでひとつ注意点があります。 ボリュームシャドーコピーの設定は、誰でもできるわけではありません。 FSx構築時に「 委任された管理者グループ 」として登録されたグループに所属しているユーザーのみが設定操作を行えるため、 自分のアカウントにその権限がない場合は、対象の管理者ユーザーとして実行する必要があります。 別ユーザーとしてPowerShellを起動出来たら、以下コマンドを使用してFSxに接続します。 “Windows Remote PowerShell EndPoint”は、FSxのマネコン上で確認可能です。 Enter-PSSession -ComputerName "Windows Remote PowerShell EndPoint" -ConfigurationName fsxremoteadmin 赤枠部分が適切なWindows Remote PowerShell エンドポイントであれば成功です。 シャドーコピーの設定 シャドーコピーの容量設定 今回は以下コマンドを使用して設定しました。 「-Default」 オプションを使用すると、シャドウストレージの量をボリュームの 10% に、シャドウコピーの最大数を 20 に設定します。 Set-FsxShadowStorage -Default スケジュール設定 スケジュールを設定する前に、[exit]コマンドを使用して、一度FSxから切断します。 以下コマンドを使用して、Windows スケジュールタスクトリガーを作成します。 JST時刻 で毎日00:00にシャドウコピーを取得するように取得しています。 $trigger1 = new-scheduledTaskTrigger -weekly -DaysOfWeek Sunday,Monday,Tuesday,Wednesday,Thursday,Friday,Saturday -at 00:00 次に、FSxにもう一度接続し、以下コマンドを使用してシャドーコピーのスケジュールを設定します。 Set-fsxshadowcopyschedule -scheduledtasktriggers $Using:trigger1 -Confirm:$false 設定時刻は UTC時刻 で表記されるので、間違えないように注意してください。 その他コマンド コマンド 説明 Get-FsxShadowStorage シャドウコピーストレージを表示 Get-FsxShadowCopySchedule シャドウコピースケジュールの表示 Remove-FsxShadowCopySchedule シャドウコピースケジュールの削除 New-FsxShadowCopy シャドウコピーの作成（手動） Get-FsxShadowCopies 既存のシャドウコピーの表示 Remove-FsxShadowCopies -Oldest 最も古いシャドウコピーの削除 Remove-FsxShadowStorage シャドウコピーのストレージ、スケジュール、およびすべてのシャドウコピーを削除する   まとめ 今回は、FSxのボリュームシャドーコピーをPowerShellから有効化・スケジュール設定する流れをまとめました。 実際にやってみて感じたことをいくつか挙げます。 GUIよりも仕組みを理解しながら設定できる FSx構築時に「 委任された管理者グループ 」として指定したグループがかなり重要！（最初、ここでハマりました） スケジュール設定時は、一度FSxから 切断 する！（次に、ここでもハマりました） スケジュール設定時刻は JST表記 だが、表示時刻は UTC表記 に注意！（最後に、ここでハマりました） まだまだ学ぶことは多いですが、実際に構築してみると仕組みがぐっと分かりやすくなります。 これからFSxを運用していく方や、PowerShellを活用したい方の参考になれば幸いです。