G-gen の杉村です。当記事では、Google Cloud の AI エージェント向けネットワークセキュリティ機能である Agent Gateway について解説し、仕様の把握や設計時の考慮事項の検討に役立つ情報を提供します。 概要 Agent Gateway とは アーキテクチャ メリット 通信制御 概要 通信制御の対象 Identity-Aware Proxy（IAP） Model Armor セマンティックガバナンスポリシー Service Extensions デプロイと運用 エージェントへのルール適用（Gemini Enterprise app） エージェントへのルール適用（Agent Runtime） Agent Gateway の使用を強制 プロジェクト構成 ロギング ドライラン ゲートウェイ ゲートウェイとは 設定値 デプロイメントモード Identity-Aware Proxy（IAP） IAM ポリシーとは 設定値 設定イメージ セマンティックガバナンスポリシー 概要 ネットワーク要件 技術的な詳細 プロトコル 通信の暗号化と認証 概要 Agent Gateway とは Agent Gateway は、AI エージェントが行う通信についてセキュアな接続とガバナンスを提供する、Google Cloud のセキュリティ機能です。 なお Agent Gateway は、Google Cloud が提供する AI 開発・運用プラットフォームである Gemini Enterprise Agent Platform （以下、Agent Platform）のコンポーネントの1つです。 Agent Gateway は「ユーザーとエージェント」「エージェントとツール」「エージェントと他のエージェント」の間の通信など、エージェントが行うさまざまな通信の出入り口として機能します。 組織のセキュリティ管理者は Agent Gateway を使うことで、エージェントに対するセキュリティとガバナンスポリシーを強制することができます。具体的には、明示的に許可されていない外部の API や MCP サーバー、他のエージェント等に対するエージェントからのリクエストを一元的に防いだり、Model Armor によるトラフィックの検査を強制することができます。 参考 : Agent Gateway overview なお、Agent Gateway を含む、AI エージェント開発プラットフォームである Gemini Enterprise Agent Platform の全体像については、以下の記事を参照してください。 blog.g-gen.co.jp アーキテクチャ Agent Gateway は、以下のようなイメージで、エージェントの通信を制御します。 Agent Gateway のアーキテクチャ Agent Gateway を使用することで、Google Cloud にホストされた AI エージェントの通信を一元的に統制できます。例として、リスクのある外部 API や MCP サーバーなどへのアクセスを拒否したり、不必要な AI エージェント間の通信を制限したりすることができます。 メリット Agent Gateway の導入により、AI 開発者とインフラ管理者（セキュリティ管理者）の双方に利点があります。 AI 開発者にとっての利点は、複雑なネットワーク管理やセキュリティのオーバーヘッドを意識することなく、エージェントの開発に集中できることです。mTLS ハンドシェイクの自動処理や、MCP、Agent-to-Agent（A2A）、REST、gRPC などによる通信の制御をプラットフォーム側でシームレスに行うことができます。また Agent Gateway は Cloud Monitoring や Cloud Logging と統合されているため、Agent Gateway を介することでオブザーバビリティが向上し、エージェントの動作の把握に役立ちます。 インフラ管理者（セキュリティ管理者）にとっては、エージェントの通信や外部システムへのアクセスに対して、一元的なガバナンスを効かせられるメリットがあります。また Identity and Access Management（以下、IAM）を用いた最小権限の原則の適用や、Model Armor を用いたプロンプトインジェクション保護などの AI セキュリティガードレールを実装できます。またエージェントと Agent Gateway の間では、Agent Identity や mTLS といった技術により自動的にセキュアな通信が確立されます。 通信制御 概要 Agent Gateway は、ゲートウェイを通過するトラフィックに対して、以下の仕組みを適用することでエージェントの通信を制御します。 名称 説明 適用可能なゲートウェイ Identity-Aware Proxy（IAP） エージェントから他のエージェント、MCP サーバー、API エンドポイントへの呼び出し可否を制御 egress モードのみ Model Armor LLM への入出力（プロンプトとレスポンス）を検査して危険なコンテンツをブロック egress / ingress モード セマンティックガバナンスポリシー（SGP） 自然言語でルールを記述してエージェントのツール呼び出しや Agent Skills 呼び出しを制御 egress モードのみ Service Extensions カスタム認可エンジンをゲートウェイに統合 egress / ingress モード 参考 : Agent Gateway overview - Access control policies Agent Gateway を適切に設定すると、制御対象のエージェントの外部への通信や LLM とのデータ入出力がゲートウェイによってインターセプト（傍受）されて、上記の仕組みにルーティングされて評価され、その結果としてブロックされたりロギングされたりします。 それぞれ、egress / ingress モードのどちらのゲートウェイに適用できるかが決まっています。ゲートウェイのデプロイモードについては後述します。 なお、トラフィックがゲートウェイによって検査されるようにするためには、Agent Gateway を展開するだけでなく、 エージェント側にも設定が必要 です。既存および新規にデプロイされるエージェントが Agent Gateway を必ず経由するようにするためには、後述する組織のポリシーを設定する必要がある点に注意してください。 通信制御の対象 Agent Gateway が通信制御の対象にできるのは、以下の環境で動作するエージェントのみです。 Agent Runtime （旧称 Vertex AI Agent Runtime） Gemini Enterprise app 上記以外の環境にホストされているエージェントは、Agent Gateway による制御の対象外です。 参考 : Agent Gateway overview - Agent runtimes Agent Runtime にホストするエージェントの場合、Agent Gateway の制御対象とするには、以下の条件があります。 エージェントのデプロイ時にゲートウェイを明示的に指定している エージェントが Agent Identity を持っている 同一プロジェクトの同一リージョンでは同じ Agent Gateway（egress / ingress ごと）に紐づける Agent Runtime のエージェントについては、組織のポリシーを使うことで、必ず承認されたゲートウェイを指定しないとデプロイできないように統制可能です。 参考 : Route Agent Runtime traffic through Agent Gateway 参考 : Route Agent Runtime traffic through Agent Gateway - Restrict Agent Runtime to approved Agent Gateways Gemini Enterprise app のエージェントの場合、アプリの管理設定で、使用するゲートウェイを明示的に指定する必要があります。 参考 : Route Gemini Enterprise traffic through Agent Gateway Identity-Aware Proxy（IAP） Agent Gateway は Identity-Aware Proxy （以下、IAP）の仕組みを使って、エージェントから他のエージェント、MCP サーバー、API エンドポイントへの呼び出し可否を決定します。 IAP による通信制御が使用できるのは Agent-to-Anywhere（egress）モードのゲートウェイのみです。Client-to-Agent（ingress）、つまりエージェントに入ってくる通信を IAP で制御することはできません。よって、Agent Gateway を介さないエージェントの呼び出しについては、エージェント側の認証・認可やネットワーク制御で適切に担保する必要があります。 制御のルールは、 IAM ポリシー によって定義します。詳細は後述します。 Model Armor Model Armor は、Google Cloud が提供する LLM 用の保護機能であり、LLM へのインプット（プロンプト）と出力されるアウトプット（レスポンス）を検査するサービスです。ゲートウェイで Model Armor を有効化すると、ゲートウェイを通るプロンプトやレスポンスが検査されるようになります。 Model Armor についての詳細は以下の記事を参照してください。 blog.g-gen.co.jp セマンティックガバナンスポリシー セマンティックガバナンスポリシー （Semantic Governance Policy、以下 SGP）は、自然言語を使って定義するセキュリティポリシーです。エージェントのツール呼び出し時や Agent Skills の呼び出し時に評価され、ユーザーの意図と組織のルールの両方に合致しているかどうかがチェックされます。 SGP は自然言語で定義され、LLM によって評価されるため、動的にポリシーを適用できるのが特徴です。SGP についての詳細は後述します。 参考 : Configure semantic governance policies Service Extensions Service Extensions を使うことで、独自の認可エンジンやサードパーティのエンジンに認可を委任できます。日本語の Google Cloud コンソール上では「サービス拡張機能」などと表記されます。 Service Extensions はもともと、Cloud Load Balancing と Cloud CDN の機能拡張のためにリリースされた機能であり、軽量な処理を Rust、Go、C++ などの言語で記述してアドオンできるプラグイン機能です。そのうちの Authorization extensions と同じ基盤を用いているのが、Agent Gateway の Service Extensions 機能です。 参考 : Delegate authorization with Service Extensions 参考 : Cloud Load Balancing and Cloud CDN extensions overview なお Agent Gateway でゲートウェイを作成して IAP を有効化したり Model Armor を有効化すると、それぞれに対応した Service Extensions が自動的に作成されます。Agent Gateway のバックエンドでは、実質的にこの Service Extensions が動作していることがわかります。 ゲートウェイ詳細画面 デプロイと運用 エージェントへのルール適用（Gemini Enterprise app） Gemini Enterprise app のエージェントに Agent Gateway の統制を適用するには、アプリの管理設定において、明示的にゲートウェイを指定します。 使用するゲートウェイは、アプリの管理画面の「セキュリティ > 構成」画面から設定できます。 また、Discovery Engine サービスエージェントと呼ばれる特殊なサービスアカウントに、所定の権限を付与する必要がある点にも注意してください。詳細は公式ドキュメントを参照してください。 参考 : Route Gemini Enterprise traffic through Agent Gateway エージェントへのルール適用（Agent Runtime） Agent Runtime にホストするエージェントを Agent Gateway の制御対象とするには、以下の条件があります。 エージェントのデプロイ時にゲートウェイを明示的に指定する エージェントが Agent Identity を持っている 同一プロジェクトの同一リージョンでは同じ Agent Gateway（egress / ingress ごと）に紐づける なお、ゲートウェイを作成するより前に既にデプロイされていたエージェントについては、ゲートウェイを指定してデプロイし直す必要があります。 参考 : Route Agent Runtime traffic through Agent Gateway Agent Gateway の使用を強制 組織のポリシーのカスタム制約を使用すると、Agent Runtime にデプロイされるエージェントが特定のゲートウェイを必ず使用するように強制することができます。組織としての統制のため、全エージェントのトラフィックが必ず Agent Gateway を通過するようにするためには、以下のドキュメントを参考にして組織のポリシーのカスタム制約を設定してください。 参考 : Route Agent Runtime traffic through Agent Gateway - Restrict Agent Runtime to approved Agent Gateways これらにより、組織内で Agent Gateway の使用を強制し、エージェントの通信に統制を効かせることができます。 プロジェクト構成 Agent Gateway のゲートウェイと、制御対象の Agent Runtime エージェントは、 同一プロジェクト ・ 同一リージョン に存在している必要があります。Gemini Enterprise app を制御対象とする場合も同様に、Agent Gateway のゲートウェイと、Gemini Enterprise app のアプリは同じプロジェクト・対応するリージョンに存在している必要があります。 よって組織全体でエージェントに対する統一した統制ルールを設定し、それを単一チームで運用するには、例として以下のような構成が考えられます。 案1: エージェントは単一の Google Cloud プロジェクトにデプロイ（組織のポリシーで制御）する。このプロジェクトで管理チームによって Agent Gateway が管理されている。 案2: 開発者チームごとに Google Cloud プロジェクトを払い出す。エージェントはそれらのプロジェクト内に存在している。Agent Gateway は管理チームが IaC 等で管理し、各プロジェクトに展開する。 案1 の構成では、エージェントデプロイ用の権限を持ったサービスアカウントを開発者チームに借用させたり、あるいは開発者チームにデプロイ権限を付与する、または CI/CD パイプラインによる自動デプロイでゼロタッチな本番デプロイをさせる、などによって実現することが考えられます。 案1: ゲートウェイを中央管理 ロギング Agent Gateway を通過するトラフィックは、Cloud Logging によって記録されます。ログには以下のような情報が含まれます。 タイムスタンプ Agent Registry リソース名（呼び出し元エージェント、呼び出し先の MCP サーバーなど） MCP のメソッド名（tools/call など） アクセス制御を処理した Service Extensions 拡張機能の情報 このログは、設定ミス等のトラブルシューティングのほか、ドライランモードで動作させている場合のポリシー監査に役立ちます。 ログエントリは networkservices.googleapis.com/Gateway リソースタイプとして記録されます。ログエクスプローラで以下のようなクエリを実行することで、Agent Gateway が出力したログを抽出できます。 resource. type=" networkservices.googleapis.com/Gateway " 参考 : Monitor traffic through Agent Gateway ドライラン 既存のエージェント環境に Agent Gateway を適用する場合は、事前にドライランを行って設定が適切であることを確かめてから、ポリシーを実際に適用することが推奨されます。 ゲートウェイの「アクセス認可」設定を「監査のみ」に設定することで、ロギングのみが行われブロックは行われないように設定されます。トラフィックのログは、前述のとおり Cloud Logging で確認できます。 ゲートウェイ ゲートウェイとは ゲートウェイ （Gateway）は、Agent Gateway の管理単位です。Google Cloud プロジェクト内に作成します。ingress モードと egress モードがあり、プロジェクト内に複数作成できます。 参考 : Set up Agent Gateway 設定値 ゲートウェイの作成時には、以下のような設定値を指定します。 リージョン ゲートウェイを展開するリージョンを指定します。制御対象の Agent Runtime のエージェントと同じリージョンを指定する必要があります。制御対象が Gemini Enterprise app のエージェントであれば、Gemini Enterprise app のアプリを作成したリージョンに対応したリージョンを指定する必要があります。例として Gemini Enterprise app のアプリが global リージョンにあれば、ゲートウェイは us-central1 に配置する必要があります。 Agent Registry ゲートウェイが制御対象とする Agent Registry のレジストリを指定します。制御対象の Agent Runtime エージェントと同じリージョンのレジストリを指定します。対象レジストリはグローバルレジストリ、リージョンレジストリ、US マルチリージョンレジストリ、EU マルチリージョンレジストリのいずれかから選択する必要があり、 //agentregistry.googleapis.com/projects/my-project/locations/asia-northeast1 のようにプロジェクト ID とロケーションの組み合わせで表されます。 デプロイメントモード（管理対象アクセスパス） Google Cloud コンソール上は「管理対象アクセスパス」、公式ガイド上は「デプロイメントモード」と表記されています。Client-to-Agent（ingress）または Agent-to-Anywhere（egress）から選択します。作成するゲートウェイが、エージェントに入ってくる通信を制御するものなのか、エージェントから出ていく通信を制御するものなのか、を決定する設定値です。詳細は後述します。 アクセス認可 デプロイメントモードが「Agent-to-Anywhere（egress）」のときだけ指定可能です。「監査のみ」または「ポリシーを適用」から選択します。前者を指定した場合はドライランとなり、ログが記録されるのみで、実際のアクセス制御は適用されません。後者の場合は、実際に IAM を使用したアクセス制御が適用され、明示的な許可がされていない通信はブロックされます。まずは前者でテストを行い、ポリシーが適切であると確かめられたら後者に変更する運用が想定されます。 Model Armor Model Armor の使用有無と、使用するテンプレートを指定します。 デプロイメントモード Agent Gateway には2つの デプロイメントモード （Deployment modes）があります。デプロイメントモードは、ゲートウェイを作成するときに選択します。Google Cloud コンソール上では「管理対象アクセスパス」と表記されています。 Client-to-Agent（ingress） Agent-to-Anywhere（egress） なお Google Cloud コンソール上では、前者は 「クライアントからエージェントへ（内向き）」、後者は「エージェントから任意の宛先へ（外向き）」と表記されています。 図左寄りが ingress モード、右寄りが egress モード Client-to-Agent（ingress） Client-to-Agent（ingress）は、クライアント（Claude Code、Gemini CLI、Antigravity CLI など）からエージェントへの通信を保護するためのモードです。エージェントに入ってくる通信に対して Model Armor のルールなどを適用できます。 Agent-to-Anywhere（egress） Agent-to-Anywhere（egress）は、エージェントから外部のサーバー、他のエージェント、ツール、MCP サーバー、API などへの通信を保護するモードです。IAP と IAM ポリシーによる認可や、Model Armor による検査などが適用できます。 Identity-Aware Proxy（IAP） IAM ポリシーとは ゲートウェイを通るトラフィックは、Identity-Aware Proxy（IAP）により検査されます。このとき IAP は IAM ポリシー （IAM policies）を使ってトラフィックを評価します。デフォルトではすべてのトラフィックが拒否されますが、ポリシーで指定されたソースとターゲットに合致したトラフィックであれば、許可されます。 参考 : IAM policies overview 参考 : Create IAM agent policies Agent Gateway における IAM ポリシーの実体は、IAP リソースが持つ IAM 許可ポリシーです。この概念を正確に理解するには、Identity and Access Management（IAM）の基本的な仕組みと、許可ポリシーについての理解が必要です。以下の記事も参照してください。 参考 : Google CloudのIAMを徹底解説！ - G-gen Tech Blog 設定値 IAM ポリシーは「Google Cloud コンソールの Agent Platform > エージェント > Policies」画面や gcloud コマンドラインを使い、プロジェクト内に複数作成できます。IAM ポリシーには、以下のような設定値があります。 参考 : IAM policies overview ‐ Policy components 接続元エージェント（ソースエージェント） アクセスを許可する対象の、接続元エージェントです。ゲートウェイに紐づけられたすべてのエージェントを指定することもできますし、個々のエージェントを指定することもできます。 ターゲット ポリシーが認可する接続先（ターゲット）を定義する設定値です。ターゲットとしては、Agent Registry に登録されているエージェント、MCP サーバー、API エンドポイントを選択できます。また、特定の Agent Registry に所属するすべてのターゲットを許可することもできます。 条件（Condition） 通常の IAM 許可ポリシー同様、条件（Condition）を指定することもできます。ただし指定可能な条件には制限があります。詳細は公式ガイドを参照してください。 設定イメージ Google Cloud コンソールの設定画面では、以下のスクリーンショットの上部の赤枠がソースエージェント、下部の赤枠がターゲットを指します。 IAM エージェントポリシー作成画面 ターゲットの Agent Registry としては、 グローバルレジストリ とリージョンごとの リージョンレジストリ が選択できます。Agent Registry では、エージェントや MCP サーバー、API エンドポイントを登録する際に、登録先としてグローバルレジストリまたはリージョンレジストリが選択できるので、対象が登録されているレジストリを適切に選択する必要があります。 グローバルレジストリまたはリージョンレジストリ セマンティックガバナンスポリシー 概要 セマンティックガバナンスポリシー （Semantic Governance Policy、以下 SGP）は、自然言語を使って定義するセキュリティポリシーです。エージェントのツール呼び出し時に評価され、ユーザーの意図と組織のルールの両方に合致しているかどうかがチェックされます。 参考 : Configure semantic governance policies 例として、出張手配エージェントが、宿泊先の手配をするツールを呼び出すケースを考えます。ツールは宿泊先の予約 API を実行するものですが、呼び出しの際に SGP が評価され「2万円を超える金額の自動的な決裁は禁止する」というルールに抵触している場合は、事前の設定に応じてツールの呼び出しを中止するか、人間の承認を求めます。このように、内容によって動的にポリシーを適用できるのが SGP の特徴です。 また SGP は、Agent Skills のロードに関するエージェントの挙動も傍受して制御できます。エージェントが実行する list_skills 、 load_skill 、 run_skill_script ツールなどを傍受して、ポリシーを適用できます。 ネットワーク要件 SGP を Agent Gateway で有効化するには、VPC ネットワークやプロキシ専用サブネット、Cloud DNS のプライベート DNS ゾーン、Private Service Connect エンドポイントなど、追加のネットワークコンポーネントが必要です。 参考 : Configure semantic governance policies ‐ Configure SGP policies and the SGP engine 技術的な詳細 プロトコル Agent Gateway は、MCP、A2A プロトコル、REST、gRPC など、HTTP ベースのトラフィックをサポートします。通信のペイロードは暗号化されます。 なお、エージェントの開発に使用するフレームワークは問いません。Agent Development Kit（ADK）でも、LangChain など Google 以外から提供するフレームワークでも、Agent Gateway で制御できます。 参考 : Agent Gateway overview - Key benefits 通信の暗号化と認証 ゲートウェイとエージェントとの間の通信は、mTLS（相互 TLS）によって暗号化されており、また Agent Identity に基づいて Demonstrable Proof of Possession（DPoP）による所有権証明も行われます。 これにより、エージェントになりすましたリクエストが困難になり、セキュリティが確保されます。 参考 : Agent Gateway overview - Integration with the Agent Platform ecosystem 参考 : IAM policies overview - IAP and Context-Aware Access provide end-to-end security Agent Identity については以下の記事で詳細に解説されています。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の武井です。当記事では、Google SecOps で検知したアラートの是正対応を Playbooks で自動化する方法を解説します。 はじめに Google SecOps とは Playbooks（ハンドブック）とは 検証の流れ カスタムルールの設定 インテグレーションの設定 インテグレーションとは カスタムインテグレーションとは カスタムインテグレーションの作成 カスタムアクションの作成 インスタンス設定 Playbooks の設定 Playbooks の構成 トリガー コンディション アクションの設定 動作確認 はじめに Google SecOps とは Google Security Operations （以下 Google SecOps、旧称 Chronicle）は、Google Cloud が提供する 統合セキュリティ運用プラットフォーム です。 SIEM、SOAR、脅威インテリジェンス、Gemini を利用した AI による運用支援を提供します。これらにより、脅威の検知・調査・対応を一元的に行えます。結果として、セキュリティ運用の効率化と高度化を実現できます。 以下の記事も参考にしてください。 blog.g-gen.co.jp Playbooks（ハンドブック）とは Playbooks （和名表記はハンドブック）では、SIEM によって検知されたアラートに対してあらかじめ一連の対応手順を定義することで、自動または半自動でアクションを実行します。これにより、対応プロセスを標準化・迅速化できます。 Playbooks は次の要素で構成されます。 要素 概要 トリガー （Triggers） Playbooks を起動する条件。特定のアラートやイベントの発生時、またはスケジュールを契機に自動実行される アクション （Actions） 実行される処理。例えば「VirusTotal への照会」、「Jira チケット起票」、「ユーザーの無効化」など フロー （Flows） 条件分岐や承認を制御する仕組み。自動判断やアナリストの入力を挟みながら次の処理を決定する ブロック （Blocks） 再利用可能な処理単位。複数の Playbooks で共通利用できる部品化されたモジュール ループ （Loops） 配列（リスト）に対する繰り返し処理。for each として、アラート内のエンティティ群やリスト項目を1件ずつ反復し、各項目に対して同じアクションを実行する AI エージェント （AI Agents） AI エージェントを組み込み、自律的な分析・判断を行わせるステップ。 Triage and Investigation Agent （TIN）で、アラートを自律調査して True/False Positive の判定・信頼度スコアを返し、その結果を後続の分岐に利用できる 参考 : Playbook and automation overview 参考 : Embed AI agents in playbooks 検証の流れ 当記事では GitHub の Private リポジトリが意図せず Public リポジトリに変更されたというシナリオのもと、以下の段取りで検証を行います。 順序 設定項目 設定箇所 1 カスタムルールの設定 Google SecOps 2 カスタムインテグレーションの設定 Google SecOps 3 Playbooks の設定 Google SecOps 4 動作確認 Google SecOps および GitHub なお、GitHub の監査ログを Google SecOps に取り込む方法については、以下の記事で解説しています。 blog.g-gen.co.jp カスタムルールの設定 前述のシナリオに該当するログを取り込んだ際、それをアラートとして検知できるよう、検知ルールを準備します。 Google SecOps には事前定義済みの検知ルールが多数用意されていますが、今回のシナリオ向けに独自のカスタムルールを作成します。事前定義済みの検知ルールを参考にしつつ、 Gemini in Google SecOps を使用したルール作成が効果的です。 参考 : Generate rules with Gemini 作成したカスタムルール（今回の例では g_gen_github_repo_visibility_to_public ）は以下の通りです。また、作成したルールでアラート検知ができるよう、 Detecting と Alerting を有効にします。 rule g_gen_github_repo_visibility_to_public { meta: author = "G-gen" description = "Detects a GitHub repository whose visibility is changed to public" severity = "HIGH" tactic = "TA0010" technique = "T1567" events: $e.metadata.product_name = "GITHUB" $e.metadata.product_event_type = "repo.access" $e.additional.fields["visibility"] = "public" nocase outcome: $repo_name = array_distinct($e.target.resource.name) $actor_id = array_distinct($e.principal.user.userid) $new_visibility = array_distinct($e.additional.fields["visibility"]) $previous_visibility = array_distinct($e.additional.fields["previous_visibility"]) condition: $e } Detecting と Alerting を有効にしないとアラートは検知されない インテグレーションの設定 インテグレーションとは Playbooks は、それ単体で GitHub のような外部サービスを操作できません。外部サービスへの接続と操作を担うのが インテグレーション です。 Google SecOps では、VirusTotal や Slack をはじめ数多くの外部サービスに対応したインテグレーションが Content Hub（マーケットプレイスに相当）で提供されています。 参考 : Google Security Operations response integrations カスタムインテグレーションとは カスタムインテグレーション とは、Google SecOps 組み込みの IDE （統合開発環境）を使って独自に作成するインテグレーションです。 2026年7月現在、GitHub に関するインテグレーションは存在しないため、「GitHub への接続」と「リポジトリの可視性（公開範囲）変更」の2つのアクションを含むカスタムインテグレーションを作成し、これらを後段の Playbooks から呼び出します。 参考 : Use the IDE カスタムインテグレーションの作成 SecOps の管理コンソールから Response > IDE > + と遷移し、インテグレーション（今回の例では GitHubCustom ）を作成します。 次に、インテグレーションの歯車アイコンをクリックします。 画面が遷移したら、以下2つのパラメータを追加します。 API Token を必須（Mandatory）にすると既定値の入力を求められ、秘匿値が残ってしまうため、ここでは必須を Off にします。 パラメータ タイプ 既定値 必須 API Root String https://api.github.com On API Token Password （空） Off カスタムアクションの作成 インテグレーション（土台）の次に、その上で動く アクション を作成します。アクションには即座に結果が返る Sync と、長時間処理向けの Async がありますが、今回はいずれも即応答のため Sync を選択します。 先程同様、 Response > IDE > + と遷移し、以下2つのアクションを作成します。 接続確認用アクション （ Ping ）: GitHub に正しく接続できるかを確認します。Google SecOps では、すべてのインテグレーションがこの接続テスト用アクションを1つ持つ必要があります。 可視性変更用アクション （ Set Repository Visibility ）: GitHub REST API の PATCH /repos/{owner}/{repo} を呼び出し、リポジトリの可視性を変更します。 接続確認用アクション （Ping） では GitHub の GET /user を呼び出し、トークンが有効であることを確認します。 from SiemplifyAction import SiemplifyAction from SiemplifyUtils import output_handler from ScriptResult import EXECUTION_STATE_COMPLETED, EXECUTION_STATE_FAILED import requests INTEGRATION_NAME = "GitHubCustom" @ output_handler def main (): siemplify = SiemplifyAction() siemplify.script_name = "Ping" api_root = siemplify.extract_configuration_param(INTEGRATION_NAME, "API Root" , default_value= "https://api.github.com" ) token = siemplify.extract_configuration_param(INTEGRATION_NAME, "API Token" ) status = EXECUTION_STATE_COMPLETED result_value = "true" try : resp = requests.get( f "{api_root}/user" , headers={ "Authorization" : f "Bearer {token}" , "Accept" : "application/vnd.github+json" , "X-GitHub-Api-Version" : "2022-11-28" , }, timeout= 30 , ) resp.raise_for_status() output_message = f "Successfully connected to GitHub as {resp.json().get('login')}." except Exception as e: status = EXECUTION_STATE_FAILED result_value = "false" output_message = f "Failed to connect to GitHub: {e}" siemplify.end(output_message, result_value, status) if __name__ == "__main__" : main() 可視性変更用アクション（Set Repository Visibility） では実行のたびに外から渡す入力パラメータを2つ定義します。 設定パラメータがインテグレーション全体で共通の接続情報であるのに対し、入力パラメータは実行ごとに変わる値（対象リポジトリなど）を受け取ります。 パラメータ タイプ 既定値 必須 Repository Full Name String （空） Off Target Visibility String private On Repository Full Name は、後段の Playbooks でアラートから動的に渡すため、ここでの必須は Off で問題ありません。 from SiemplifyAction import SiemplifyAction from SiemplifyUtils import output_handler from ScriptResult import EXECUTION_STATE_COMPLETED, EXECUTION_STATE_FAILED import requests INTEGRATION_NAME = "GitHubCustom" @ output_handler def main (): siemplify = SiemplifyAction() siemplify.script_name = "Set Repository Visibility" api_root = siemplify.extract_configuration_param(INTEGRATION_NAME, "API Root" , default_value= "https://api.github.com" ) token = siemplify.extract_configuration_param(INTEGRATION_NAME, "API Token" ) full_name = siemplify.extract_action_param( "Repository Full Name" , print_value= True ) target = siemplify.extract_action_param( "Target Visibility" , default_value= "private" , print_value= True ) status = EXECUTION_STATE_COMPLETED result_value = "true" try : owner, repo = full_name.split( "/" , 1 ) url = f "{api_root}/repos/{owner}/{repo}" resp = requests.patch( url, headers={ "Authorization" : f "Bearer {token}" , "Accept" : "application/vnd.github+json" , "X-GitHub-Api-Version" : "2022-11-28" , }, json={ "visibility" : target}, timeout= 30 , ) if resp.status_code == 200 : siemplify.result.add_result_json(resp.json()) output_message = f "Reverted {full_name} to {target}." else : status = EXECUTION_STATE_FAILED result_value = "false" output_message = f "Failed ({resp.status_code}): {resp.text}" except Exception as e: status = EXECUTION_STATE_FAILED result_value = "false" output_message = f "Error: {e}" siemplify.end(output_message, result_value, status) if __name__ == "__main__" : main() パラメータ（オレンジ枠）の入力画面 インスタンス設定 作成したカスタムインテグレーションは、 インスタンス として有効化することで使用可能になります。 SecOps の管理コンソールから Response > Integrations Setup > 環境区分（今回は Default Environment）> + と遷移し、先程作成したカスタムインテグレーションを選択してインスタンスを作成します。 インスタンスが作成できたら、歯車アイコンからパラメーターを入力し、 Test > Save の順で保存します。 なお、今回は検証のため、個人アカウントで発行した Personal Access Token を使用していますが、本番運用では Fine-grained PAT や GitHub App による認証が望ましいです。 Test は成功して✔がつくこと Playbooks の設定 Playbooks の構成 ここまでで、アラートを検知するカスタムルールと、是正対応を実行するカスタムインテグレーションが揃いました。最後に、これらを束ねて「検知から是正までを自動化する」ワークフローを Playbooks として組み立てます。 今回作成する Playbooks は、以下の流れで構成します。SecOps の管理コンソールから Response > Playbooks > + と遷移して新規 Playbooks（今回の例では GitHub_Public_to_Private_Demo ）を作成します。 順序 要素 設定内容 1 トリガー カスタムルールでアラートを検知した場合に起動 2 コンディション 特定の GitHub Organization 配下のリポジトリかを判定 3 アクション① #2 が True の場合、カスタムインテグレーションで可視性を変更 4 アクション② ケースにコメントを記入 5 アクション③ ケースのクローズ 参考 : Create your first playbook トリガー トリガー は Playbooks の起動条件です。今回は、カスタムルールが検知したアラートにのみ反応させるため、Alert Type が g_gen_github_repo_visibility_to_public である場合に設定します。これにより、このアラート以外では Playbooks が起動しません。 コンディション コンディション は Playbooks 内の条件分岐です。ある条件を満たす場合のみ後続の処理へ進み、満たさない場合は別ルート（ ELSE ）へ分岐させられます。 コンディションを挟んだ理由は、是正の対象を特定の Organization のリポジトリに限定するためで、今回の例では g-gen-secops-test/ で始まる場合のみ、後続のアクションへ進むよう設定します。 アクションの設定 アクション は Playbooks で実行する実際の処理です。今回はコンディションの条件を満たした場合、3 つの処理を実行します。 1つ目は、Public に変更されたリポジトリの可視性を Private に戻す処理（ Set Repository Visibility ）です。カスタムインテグレーションで作成したインスタンスを選択し、入力パラメータを以下のように設定します。 対象のリポジトリはプレースホルダ（ Event.event_target_resource_name ）とすることで、発火したアラートから動的に判断します。 2つ目は、ケースにコメントを記入する Case Comment です。これは Google SecOps 標準の Siemplify インテグレーションに含まれるアクションで、ケースに任意のコメントを記入するために使用します。Comment に自動対応の記録を残します。 3つ目は、対応が完了したケースをクローズする Close Case です。先程同様 Siemplify インテグレーションに含まれるアクションで、自動対応の済んだケースを未対応のまま残さずクローズするために使用します。 動作確認 動作確認を行うため、カスタムルールの検知対象となる操作（リポジトリの可視性を Public に変更）を実行します。 しばらくすると、Google SecOps のケース画面にてアラートを検知していたことがわかりますが、その時点で既にケースがクローズされています。 Playbooks の起動条件を満たすアラートが検知されたため、可視性変更からケースのクローズまでの一連処理が自動的に実行され、かつ、正常終了していることがわかります。 ケースの詳細を確認すると、 Case Comment で定義したコメントが入力済みです。 肝心の GitHub リポジトリの可視性についても Public -> Private に変更されていることを確認できました。 武井 祐介 (記事一覧) クラウドソリューション部。 Google Cloud Partner Top Engineer 2026 選出。 Follow @ggenyutakei

G-gen の武井です。当記事では、Google が提供する SIEM / SOAR 製品である Google SecOps に、GitHub の監査ログを取り込む方法について解説します。 はじめに Google SecOps とは データフィードとは 設定の流れ Google Cloud の設定 サービスアカウント Cloud Storage バケット IAM Policy GitHub の設定 監査ログのストリーミング Google SecOps の設定 データフィード 動作確認 応用 はじめに Google SecOps とは Google Security Operations （以下 Google SecOps、旧称 Chronicle）は、Google Cloud が提供する 統合セキュリティ運用プラットフォーム です。 SIEM、SOAR、脅威インテリジェンス、Gemini を利用した AI による運用支援を提供します。これらにより、脅威の検知・調査・対応を一元的に行えます。結果として、セキュリティ運用の効率化と高度化を実現できます。 以下の記事も参考にしてください。 blog.g-gen.co.jp データフィードとは Google SecOps では、AWS、Azure、その他 SaaS など、Google Cloud 以外の環境のログデータを取り込む仕組みとして データフィード機能 があります。 SecOps UI もしくは Feed Management API を用いて、ログソース（Amazon S3、Cloud Storage、Pub/Sub、Webhook など）を指定し、各種ログを SecOps に取り込む設定を行います。 ソースタイプ 概要 ストレージ Google Cloud、AWS、Azure のクラウドストレージバケットに保存されたログデータを定期的に取得 Amazon SQS S3 バケットの通知をキュー経由で受信し、ログデータを取得（リアルタイムかつ安定的に取り込み） ストリーミング Amazon Data Firehose、Cloud Pub/Sub、Webhook などを経由し、SIEM の HTTPS エンドポイントにログデータをストリーミングでプッシュ サードパーティ API CrowdStrike、SentinelOne、Palo Alto など、外部 SaaS から API 経由でログデータを取得 参考 : フィード管理の概要 設定の流れ 当記事では以下の構成のもと、Cloud Storage バケットに格納した GitHub の監査ログを、データフィード機能を使って Google SecOps に取り込みます。 大まかな設定手順は、以下のとおりです。 順序 設定項目 設定箇所 1 サービスアカウントの設定 Google Cloud 2 Cloud Storage バケットの設定 Google Cloud 3 IAM Policy の設定 Google Cloud 4 監査ログストリーミングの設定 GitHub 5 データフィードの設定 Google SecOps 6 動作確認 Google SecOps 参考 : GitHub 監査ログを収集する Google Cloud の設定 サービスアカウント GitHub の監査ログを Cloud Storage にエクスポートする際に必要となるサービスアカウント（今回の例では github-to-secops-demo ）を作成します。 その際 JSON キーが必要となるため、キーもあわせて作成します。なお、キー情報は漏洩することがないよう、厳重に管理してください。 手順は以下を参照してください。 参考 : サービス アカウントを作成する 参考 : サービス アカウント キーの作成と削除 もし発行時に「サービス アカウント キーの作成が無効になっています」というエラーメッセージが表示された場合、以下の記事を参照してください。 blog.g-gen.co.jp Cloud Storage バケット GitHub の監査ログを格納するための Cloud Storage バケット（今回の例では github-to-secops-demo ）を作成します。 手順は以下を参照してください。 参考 : Google Cloud Storage バケットを作成する IAM Policy 作成したバケットに対し、以下の IAM Policy を設定します。No.2 および No.3 は Google SecOps のサービスアカウント（今回の例では project-880039012961 ）で、後述するフィード作成画面から確認できます。 # サービスアカウント IAM ロール 目的 1 github-to-secops-demo Storage オブジェクト作成者（ roles/storage.objectCreator ） Cloud Storage へのログ連携 2 project-880039012961 Storage オブジェクト閲覧者（ roles/storage.objectViewer ） Google SecOps へのログ連携 3 project-880039012961 Storage バケット閲覧者（ roles/storage.bucketViewer ） 同上 なお公式ドキュメントでは、Google SecOps サービスアカウントに対しては Storage オブジェクト作成者ロールのみを付与する旨の記載がありますが、 Storage バケット閲覧者ロール （に含まれる storage.buckets.get 権限）がないとフィード設定時にエラーが発生します。 参考 : サービス アカウントに GCS バケットへの書き込み権限を付与する 参考 : Google SecOps サービス アカウントに IAM 権限を付与する GitHub の設定 監査ログのストリーミング GitHub の 監査ログストリーミング とは、組織やエンタープライズの操作履歴（リポジトリの作成、メンバーの追加、権限の変更など）を、リアルタイムかつ自動的に外部のクラウドストレージや SIEM サービスへ連携する機能です。 Cloud Storage バケットを転送先とした設定については以下を参照してください。 参考 : Google Cloud Storage へのストリーミングの設定 なお、本設定は Workload Identity 連携（キーレス認証）に対応していないため、先程の手順で作成したサービスアカウントの JSON キーを使用します。 Google SecOps の設定 データフィード GitHub の監査ログが格納された Cloud Storage バケットの URI、Google SecOps サービスアカウント情報をデータフィードを設定し、ログの取り込みを行います。 なお、Google SecOps のサービスアカウント情報は、この設定画面から確認可能です。 なお、先の手順でも説明した通り、Google SecOps のサービスアカウントがログ格納先バケットに対する storage.buckets.get 権限を持ち合わせていないと、以下のようなエラーとなります。 Generic::failed_precondition: feed creation failed: generic::failed_precondition: Failed to obtain the location of the GCS bucket github-to-secops-demo Additional details: project-880039012961@storage-transfer-service.iam.gserviceaccount.com does not have storage.buckets.get access to the Google Cloud Storage bucket. Permission 'storage.buckets.get' denied on resource '//storage.googleapis.com/projects/_/buckets/github-to-secops-demo' (or it may not exist). Remediate access with this Troubleshooter URL or share it with your administrator 動作確認 GitHub はデフォルトパーサーが用意されているため、Google SecOps にログが取り込まれると自動的に UDM イベントにパースされます。 ログの取り込み自体は、データフィードによって正常に取り込まれていることがわかります。 SIEM Search（UDM 検索）メニューから以下のクエリを入力して実行すると、ログが取り込まれていることを確認できます。 metadata.log_type = "GITHUB" また今回は、ログ取り込み後、SIEM の Detection Rules によって検知されたアラートも確認できました。アラートやケースの検知、Playbook による対処の自動化（SOAR）については別の記事で解説予定です。 応用 以下の記事では、SecOps の Playbooks 機能を使い、GitHub の Private リポジトリが意図せず Public リポジトリに変更された際に Private リポジトリに変更するという実践的なシナリオを紹介しています。 blog.g-gen.co.jp 武井 祐介 (記事一覧) クラウドソリューション部。 Google Cloud Partner Top Engineer 2026 選出。 Follow @ggenyutakei

G-gen の高宮です。当記事では、Cloud Storage バケットをバックエンドとして、安全に静的ウェブサイトをホスティングする手順を解説します。 はじめに Cloud Storage とは 静的 Web サイトホスティングの手法 各手法の比較 事前準備 バックエンドバケットへのサービスアカウント認証 手順の概要 Cloud Storage バケットの作成 バックエンドバケットの作成 バケットへの権限付与 ロードバランサーの作成 プライベートオリジンの認証 手順の概要 サービスアカウントの作成 HMAC キーの作成 Cloud Storage バケットの作成 バケットへの権限付与 NEG の作成 ロードバランサーの作成 動作確認 はじめに Cloud Storage とは Cloud Storage とは、Google Cloud が提供する、高い堅牢性、スケーラビリティ、セキュリティを備えたオブジェクトストレージサービスです。容量無制限かつインフラの運用なしで、安価に大量のデータを保管することができます。 Cloud Storage の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp 静的 Web サイトホスティングの手法 Cloud Storage は本来、安価に大容量のデータを保存するためのクラウドストレージですが、HTML や JavaScript のみで構成される静的な Web サイトをホスティングすることもできます。Cloud Storage で静的 Web サイトホスティングを実現するには、以下の手法があります。 バックエンドバケットへのサービスアカウント認証 プライベートオリジンの認証 いずれの手法も、Cloud Storage バケットの手前に、フルマネージドなロードバランサーサービスである グローバル外部アプリケーションロードバランサ を配置します。ロードバランサーを使用しないことも可能ですが、その場合はプロトコルとして非暗号化の HTTP のみが使用でき、HTTPS は使用できません。またその場合、バケットは一般公開となり、バケット内のすべてのオブジェクトにインターネットからアクセスできるようになるほか、フルマネージドの WAF サービスである Cloud Armor などのセキュリティポリシー適用もできません。 当記事で紹介する手法は、いずれもロードバランサーを使用するものであり、プロトコルが HTTPS になります。これに加え、ロードバランサーを迂回して Cloud Storage にアクセスすることができなくなるため、Cloud Armor のセキュリティポリシー等を必ず適用できます。 各手法の比較 前者の バックエンドバケットへのサービスアカウント認証 は、所定のサービスアカウント（サービスエージェント）に、バケットに対するオブジェクト閲覧権限を与えることで、バケットを限定公開のまま配信できる手法です。 参考 : Set up a backend bucket - Make your Cloud Storage bucket private 後者の プライベートオリジンの認証 は、HMAC キーと呼ばれる仕組みを使うことでロードバランサーとバケットの間の認証を行う手法です。 参考 : 非公開送信元の認証を構成する 前者の手法は、後者の手法よりも後の時期（2026年7月ころ）に使用可能になった手法であり、より簡易的に設定できるため、通常の用途であれば 前者が推奨 されます。後者は従来から使えた手法であり、Cloud Storage バケットだけでなく Amazon S3 互換のストレージに対応しているため、クロスクラウドで Web サイト配信を設定するとき等に用います。 当記事では、これらの2つの手法の設定手順を紹介します。 事前準備 当記事で紹介するいずれの手法の場合でも、以下の準備が完了していることを前提とします。 以下の API が有効化されていること。 Compute Engine API Identity and Access Management（IAM）API Certificate Manager API ロードバランサで使用するための、静的なグローバル外部 IP アドレスが予約されていること。 HTTPS による通信保護を行うための、Google マネージドの SSL 証明書等の SSL/TLS 証明書が準備済みであること。 以下の公式ドキュメントも参照してください。 参考 : Google Cloud プロジェクトで API を有効にする 参考 : 静的外部 IP アドレスの予約 参考 : Google マネージド SSL 証明書を使用する バックエンドバケットへのサービスアカウント認証 手順の概要 「バックエンドバケットへのサービスアカウント認証」手法で構築を行う手順は、以下のとおりです。 静的ファイルを配置する Cloud Storage バケットの作成 バックエンドバケットの作成 バケットへの権限付与 外部アプリケーションロードバランサ（Cloud Load Balancing）の作成 Cloud Storage バケットの作成 Web サイトのコンテンツとなる静的ファイルを配置する Cloud Storage のバケットを作成します。 Google Cloud コンソールで 「Cloud Storage」 > 「バケット」 に移動し、 「作成」 をクリックします。 以下の設定で 「作成」 をクリックし、バケットを作成します。 項目 値 バケット名 グローバルで一意となる名称 ロケーションタイプ 「Region」 で任意のリージョンを選択 データの保存方法 「デフォルトのクラスを設定する」 で 「Standard」 を選択 公開アクセスの防止 「このバケットに対する公開アクセス禁止を適用する」 にチェック アクセス制御 「均一」 を選択 オブジェクト データを保護する方法 デフォルト バケットの作成 バケットが作成できたら、公開したい静的ファイル（HTML 等）をアップロードします。 ファイルのアップロード バックエンドバケットの作成 次に、 バックエンドバケット を作成します。バックエンドバケットとは、ロードバランサーのバックエンドコンテンツを配信する Cloud Storage バケットを指すための論理的なオブジェクトであり、ロードバランサーの構成要素の1つです。1つのバックエンドバケットは、1つの Cloud Storage バケットとひも付きます。 Google Cloud コンソールで 「ロード バランシング」 > 「バックエンド」タブ に移動し、 「バックエンド バケットを作成」 をクリックします。 バックエンド バケットを作成 次の画面で、バックエンドバケットの詳細な設定を指定します。 項目 値 バックエンド バケット名 任意 説明 任意 ロードバランサの種類 グローバル外部アプリケーション ロードバランサ Cloud Storage バケット コンテンツを配置する Cloud Storage バケットを指定 Cloud CDN 任意 Cloud Armor エッジ セキュリティ ポリシー 任意 「Cloud CDN を有効にする」は任意ですが、有効化することで、Google が世界中に保持するエッジロケーションにコンテンツがキャッシュされるようになり、ユーザー体験が改善されます。「Cloud Armor エッジ セキュリティ ポリシー」も任意です。Cloud Armor はフルマネージドの WAF サービスであり、様々なセキュリティポリシーを適用できます。 参考 : Cloud CDN の概要 参考 : Cloud Armorを徹底解説。GoogleのフルマネージドWAF - G-gen Tech Blog 設定を入力したら、「作成」ボタンを押下します。 バックエンドバケットの詳細設定 バケットへの権限付与 次に、Cloud Storage バケットの IAM ポリシーにおいて、Cloud Load Balancing の サービスエージェント に対するオブジェクト閲覧権限を付与します。なおサービスエージェントとは、Google Cloud サービスが使用する特殊なサービスアカウントのことです。 参考 : サービスエージェントとは何か - G-gen Tech Blog このサービスエージェントは、 service-${PROJECT_NUM}@https-lb.iam.gserviceaccount.com という名称であり、プロジェクトで一度でもバックエンドバケット等を作成すると自動的に作成されます（ただしサービスアカウント一覧画面には表示されません）。そのため当記事では、手順の順番として、バックエンドバケットの作成の後に実施します。過去にサービスエージェントが既に作成済みであれば、この手順は Cloud Storage バケットの作成直後に行っても構いません。 ${PROJECT_NUM} の部分は、自身のプロジェクトのプロジェクト番号に置き換えてください。プロジェクト番号が 12345 であれば、サービスアカウント名は service-12345@https-lb.iam.gserviceaccount.com になります。プロジェクト番号は、Google Cloud コンソールのトップ画面（ https://console.cloud.google.com/welcome ）またはプロジェクトの設定画面（ https://console.cloud.google.com/iam-admin/settings ）で確認できます。 バケット詳細画面の 「権限」 タブに移動し、 「アクセスを許可」 をクリックします。 権限タブ このバケットにおいて、サービスアカウント service-${PROJECT_NUM}@https-lb.iam.gserviceaccount.com に、「Storage オブジェクト閲覧者（ roles/storage.objectViewer ）」の IAM ロールを付与します。 バケットへの IAM ロール付与 ロードバランサーの作成 外部アプリケーションロードバランサを作成します。なお、外部アプリケーションロードバランサの詳細については、以下の記事を参照してください。 参考 : External Application Load Balancer (外部アプリケーションロードバランサ) を徹底解説！ - G-gen Tech Blog Google Cloud コンソールで 「ネットワークサービス」 > 「ロード バランシング」 に移動し、 「ロードバランサの作成」 をクリックします。表示されるウィザードに沿って以下の設定を選択したうえで 「構成」 をクリックします。 項目 値 ロードバランサのタイプ アプリケーション ロードバランサ（HTTP / HTTPS） インターネット接続または内部 インターネット接続（外部） グローバルまたはシングル リージョンのデプロイ グローバル ワークロードに最適 ロードバランサの世代 グローバル外部アプリケーション ロードバランサ 左上のテキストボックス「ロードバランサの名前」には任意の値を入力してください。 次に、以下の設定で、フロントエンドを構成します。 項目 値 名前 任意 プロトコル HTTPS（HTTP/2 と HTTP/3 を含む） IP バージョン IPv4 IP アドレス 事前準備で予約した IP アドレス 証明書リポジトリを選択 証明書マップを使用する 証明書マップの選択 事前準備で作成した証明書マップ SSL ポリシー GCP のデフォルト HTTP/3（QUIC）ネゴシエーション 自動（デフォルト） 早期データ（0-RTT） 無効 HTTP から HTTPS へのリダイレクトを有効にする チェックしない 次に、左部ペインで「バックエンドの構成」をクリックします。プルダウンメニュー「バックエンド サービスとバックエンド バケット」で、事前に作成したバックエンドバケットを選択します。 バックエンドの構成 次に、左部ペインで「ルーティング ルール」に進みます。ルーティング ルールのモードとして 「単純なホストとパスのルール」 を選択します。 最後に「確認と完了」に進み、設定内容を確認してから、画面下部の 「作成」 ボタンをクリックします。 「作成」ボタンをクリック これで、構成は完了です。当記事末尾の「動作確認」に進んでください。 プライベートオリジンの認証 手順の概要 「プライベートオリジンの認証」手法で構築を行う手順は、以下のとおりです。 専用のサービスアカウントの作成 Cloud Storage にアクセスするための HMAC キーの生成 静的ファイルを配置する Cloud Storage バケットの作成 バケットへの権限付与 バケットへのアクセス経路となるインターネット Network Endpoint Group（以下、NEG）の作成 外部アプリケーションロードバランサ（Cloud Load Balancing）の作成と Cloud CDN へのプライベートオリジンの認証の設定 サービスアカウントの作成 HMAC キーを発行するための、専用の IAM サービスアカウントを作成します。 Google Cloud コンソールで 「IAM と管理」 > 「サービス アカウント」 に移動し、 「サービス アカウントを作成」 をクリックします。 任意のサービスアカウント名を入力し、作成します。 サービスアカウントの作成 HMAC キーの作成 作成したサービスアカウントを使用して、Cloud Storage にアクセスするための HMAC キー を生成します。 なお HMAC （Hash-based Message Authentication Code）は、送信データと送信者・受信者しか知らない共通鍵（HMAC キー）をハッシュ関数にかけ、メッセージ認証コード（MAC）を生成する技術です。送信者はデータと共にこの MAC を相手に送付します。受信者は HMAC キーを使って手元でデータを計算し、ハッシュ値が一致することを検証します。 Google Cloud コンソールで 「Cloud Storage」 > 「設定」 に移動し、 「相互運用性」 タブを開きます。 ページ下部の 「サービス アカウントのアクセスキー」 セクションで、 「サービス アカウント用にキーを作成」 をクリックします。 「サービス アカウント用にキーを作成」を押下 作成したサービスアカウントを選択し、キーを生成します。 キーの生成 生成された アクセスキー と シークレット をメモします。シークレットは作成時にしか表示されないため、紛失しないよう十分注意してください。 アクセスキーとシークレットをメモ シークレットは一度しか表示されない Cloud Storage バケットの作成 次に、Cloud Storage のバケットを作成します。 Google Cloud コンソールで 「Cloud Storage」 > 「バケット」 に移動し、 「作成」 をクリックします。 以下の設定で 「作成」 をクリックし、バケットを作成します。 項目 値 バケット名 グローバルで一意となる名称 ロケーションタイプ 「Region」 で任意のリージョンを選択 データの保存方法 「デフォルトのクラスを設定する」 で 「Standard」 を選択 公開アクセスの防止 「このバケットに対する公開アクセス禁止を適用する」 にチェック アクセス制御 「均一」 を選択 オブジェクト データを保護する方法 デフォルト バケットが作成できたら、公開したい静的ファイル（HTML 等）をアップロードします。 バケットへの権限付与 バケット詳細画面の 「権限」 タブに移動し、 「アクセスを許可」 をクリックします。 バケットに対して、先ほど作成した専用のサービスアカウント（任意のサービスアカウント名）に、「Storage オブジェクト閲覧者（ roles/storage.objectViewer ）」の IAM ロールを付与します。 バケットへの IAM ロール付与 これにより、専用サービスアカウントはバケット内のオブジェクトにアクセスする権限を得ます。HMAC キーを介して、ロードバランサーはこのサービスアカウントの権限を借り受けて、バケット内のオブジェクトを配信できます。 NEG の作成 次に、ロードバランサーを Cloud Storage バケットと関連付けるための論理オブジェクトである、グローバルインターネット NEG を作成します。 Google Cloud コンソールで 「Compute Engine」 > 「ネットワーク エンドポイント グループ」 に移動し、 「ネットワークエンドポイントグループを作成」 をクリックします。 以下の設定で 「作成」 をクリックし、NEG を作成します。 項目 設定値 名前 任意の NEG 名 ネットワークエンドポイントグループの種類 「インターネット NEG（グローバル、リージョン）」 を選択 範囲 「Global」 を選択 デフォルトポート 443 追加手段 「完全修飾ドメイン名とポート」 を選択 Fully qualified domain name（FQDN） [バケット名].storage.googleapis.com 参考 : インターネット NEG を使用して外部バックエンドを設定する NEG の作成 ロードバランサーの作成 外部アプリケーションロードバランサを作成します。 Google Cloud コンソールで 「ネットワークサービス」 > 「ロード バランシング」 に移動し、 「ロードバランサの作成」 をクリックします。 表示されるウィザードに沿って以下の設定を選択したうえで 「構成」 をクリックします。 項目 値 ロードバランサのタイプ アプリケーション ロードバランサ（HTTP / HTTPS） インターネット接続または内部 インターネット接続（外部） グローバルまたはシングル リージョンのデプロイ グローバル ワークロードに最適 ロードバランサの世代 グローバル外部アプリケーション ロードバランサ 左上のテキストボックス「ロードバランサの名前」には任意の値を入力してください。 次に、以下の設定で、フロントエンドを構成します。 項目 値 名前 任意 プロトコル HTTPS（HTTP/2 と HTTP/3 を含む） IP バージョン IPv4 IP アドレス 事前準備で予約した IP アドレス 証明書リポジトリを選択 証明書マップを使用する 証明書マップの選択 事前準備で作成した証明書マップ SSL ポリシー GCP のデフォルト HTTP/3（QUIC）ネゴシエーション 自動（デフォルト） 早期データ（0-RTT） 無効 HTTP から HTTPS へのリダイレクトを有効にする チェックしない 次に、左部ペインで「バックエンドの構成」をクリックします。バックエンドの構成は、以下の手順で行います。 プルダウンメニュー「バックエンド サービスとバックエンド バケット」をクリックして表示される 「バックエンド サービスを作成」 をクリックします。 以下の設定で、バックエンドサービスを構成します。 項目 値 名前 任意 バックエンド タイプ インターネット ネットワークエンドポイント グループ プロトコル HTTP/2 新しいバックエンド（インターネット ネットワークエンドポイント グループ） 作成した NEG Cloud CDN 有効化 キャッシュモード Cache-Control ヘッダーに基づいて送信元の設定を使用する キャッシュキー デフォルト（リクエスト URL のすべてのコンポーネントを含む） プライベートオリジンの認証 「この送信元に対するリクエストを AWS 署名バージョン 4 で認証する」 にチェック キー ID 生成した HMAC アクセスキー キー 生成した HMAC シークレット 鍵のバージョン 任意の一意の識別名 リージョン Cloud Storage バケットと同じリージョン（例: asia-northeast1） Cloud Armor 未選択 その他の CDN オプション デフォルト 制限付きコンテンツ Cloud CDN によりキャッシュされたコンテンツへの公開アクセスを許可する（推奨） カスタム リクエスト ヘッダー ヘッダー名 : Host 、ヘッダーの値 : [バケット名].storage.googleapis.com Cloud CDN の詳細 次に、左部ペインで「ルーティング ルール」に進みます。ルーティング ルールのモードとして 「単純なホストとパスのルール」 を選択します。 最後に「確認と完了」に進み、設定内容を確認してから、画面下部の「作成」ボタンをクリックします。 「作成」ボタンをクリック これで構成は完了です。次の「動作確認」へ進みます。 動作確認 アップロードした静的ファイルが、ロードバランサ経由で正常に配信されるか確認します。 Cloud Storage 内に、動作確認用の index.html として以下のシンプルな HTML コードを格納し、CSS、JavaScript、画像ファイルが正常に配信されるか確認します。 <!DOCTYPE html> < html lang = "ja" > < head > < meta charset = "UTF-8" > < meta name = "viewport" content = "width=device-width, initial-scale=1.0" > < title > GCS 静的ウェブサイトホスティング 動作確認 </ title > < link rel = "stylesheet" href = "assets/css/style.css" > < link rel = "icon" type = "image/png" href = "assets/img/icon.png" > </ head > < body > < div class = "container" > < h2 > GCS ホスティングテスト </ h2 > < p > （JavaScript & CSS の読み込み・動作確認用） </ p > < div id = "timeDisplay" class = "time-display" ></ div > </ div > < script src = "assets/js/app.js" ></ script > </ body > </ html > 以下の URL 形式を参考に、Web ブラウザでロードバランサにアクセスします。ページが正常にレンダリングされ、非公開バケット内のファイルが意図通りにブラウザ上に表示されることを確認します。 https://{Google マネージド証明書のホスト名}/index.html また、Cloud Storage のオブジェクトの公開 URL を使用して、直接オリジンにアクセスすると、アクセスが拒否されることも確認できます。 高宮 怜 (記事一覧) クラウドソリューション部ソリューションアーキテクト課 2025年6月より、G-genにジョイン。前職は四国のSIerで電力、製造業系のお客様に対して、PM／APエンジニアとして、要件定義から運用保守まで全工程を担当。現在はGoogle Cloudを学びながら、フルスタックエンジニアを目指してクラウドエンジニアとしてのスキルを習得中。 Follow @Ggen_RTakamiya

G-gen の今村です。当記事では、Google Cloud（旧称 GCP）の仮想マシンサービスである Compute Engine で Windows Server VM を起動し、リモートデスクトップでログインするまでの手順について解説します。 はじめに VM の起動 新規 VM の設定画面へ遷移 VM の設定 概要 マシンの構成 OS とストレージ データの保護 ネットワーキング オブザーバビリティ セキュリティ 詳細 設定を確認して作成 管理者アカウントとパスワード 初期パスワードの発行 初期パスワードの変更 リモートデスクトップ接続の設定 ファイアウォールルールの構成 RDP での接続確認 接続経路の保護 その他の設定と Tips Windows Server の日本語設定 Windows Server のライセンス費用 はじめに Compute Engine の基本的な概念や操作方法、およびマシンタイプやネットワークなどのその他設定については、以下の記事を参照してください。当記事では Windows Server 固有の手順に絞って解説します。 blog.g-gen.co.jp blog.g-gen.co.jp VM の起動 新規 VM の設定画面へ遷移 Google Cloud コンソール上部の検索窓で「Compute Engine」を検索し、「VM インスタンス」をクリックします。 次に、遷移した先で「インスタンスを作成」をクリックします。 Compute Engine を検索 インスタンスを作成 インスタンスの作成には、Compute インスタンス管理者（v1）（ roles/compute.instanceAdmin.v1 ）の IAM 権限が必要です。作業するユーザーに対して、当該のロールが付与されていることを確認してください。 IAM については以下の記事を参照してください。 blog.g-gen.co.jp VM の設定 概要 VM インスタンスの設定画面は大きく、マシンの構成、OS とストレージ、データ保護、ネットワーキング、オブザーバビリティ、セキュリティ、詳細の7セクションに分かれています。 当記事では、それぞれのセクション内での設定項目については詳細な説明を割愛します。細かい設定や推奨される利用方法など、公式ドキュメントを参照しながら利用要件に合わせて適切な設定を行ってください。 なお、設定項目及び UI は2026年6月現在のものであり、当記事で解説する内容は変更される可能性がある点に留意してください。 マシンの構成 リージョンやゾーン、マシンタイプ等を設定します。 マシンの構成セクション OS とストレージ 使用する OS やディスクサイズを設定します。 OS とストレージセクション デフォルトでは Windows 以外の OS が選択されているため、以下の手順で「Windows Server」に切り替えます。使用するバージョンは、利用要件に合わせて適切なものを選択してください。 オペレーティングシステムを変更 Windows Server を選択 バージョンを選択 選択をクリック データの保護 バックアップのスケジュールやレプリケーションの設定を行います。 データの保護セクション ネットワーキング ファイアウォールルールや使用するネットワークを個別に設定できます。ただし、本来ネットワーク関連の権限を持たないユーザーが、個別のネットワーク設定を行えることはセキュリティ上の懸念となります。 そのため、通信を許可するファイアウォールルール等の設定は、後述の Virtual Private Cloud（以下、VPC）で一元的な管理を行うことが推奨されます。 ネットワーキングセクション オブザーバビリティ ログや指標の収集、アプリケーション監視についての設定を行います。 オブザーバビリティセクション セキュリティ アタッチするサービスアカウントや VM の保護設定等を行います。 デフォルトのサービスアカウントには、編集者（ roles/editor ）という強力な権限が付与されています。セキュリティリスクを回避するため、必要なロールのみに絞ったサービスアカウントをアタッチすることが推奨されます。 セキュリティセクション Compute Engine にアタッチするサービスアカウントの考え方については、以下の記事を参照してください。 blog.g-gen.co.jp 詳細 VM を削除から保護する設定や起動スクリプト、メタデータの設定を行います。 詳細セクション 設定を確認して作成 セクション内の項目を一通り確認し、要件通りの設定になっているか、エラーがないか、などをチェックします。確認が終わったら画面下部の「作成」ボタンをクリックして、VM の作成処理を開始します。VM が完全に起動して接続可能になるまでは数分ほどかかります。 作成 管理者アカウントとパスワード 初期パスワードの発行 Windows Server インスタンスの作成が完了した直後は、OS にログインするための管理者アカウント（Administrator）やパスワードが用意されていません。 ログインするためには、Google Cloud コンソールの VM インスタンス詳細画面から「Windows パスワードを設定」を実行する必要があります。この操作を行うことで、指定したユーザー名のアカウントが作成され、ランダムな初期パスワードが生成されて画面に表示されます。なお、VM の起動命令を出した直後はこの操作が行えない場合があります。数分後に再度、実施してください。 このパスワードは一度画面を閉じると再確認できないため、必ず安全な場所に控えてください。 参考 : Windows VM のアカウントと認証情報を管理する - 認証情報を生成する VM 編集画面 ユーザー名を設定 自動でパスワードが生成される 初期パスワードの変更 Google Cloud コンソールで生成した初期パスワードも強力ですが、会社としてセキュリティガバナンスを定めている場合、その規定に沿ったパスワードへの変更を推奨します。ログイン後は Windows の管理機能を使用して変更できます。 参考 : Windows VM のアカウントと認証情報を管理する - パスワードを変更する リモートデスクトップ接続の設定 ファイアウォールルールの構成 Windows Server へログインするには、リモートデスクトッププロトコル（以下、RDP）を使用します。 RDP 接続を許可するために、対象の VPC ネットワークでポート番号「3389」（TCP）のインバウンド通信を許可するファイアウォールルールを追加してください。セキュリティリスクを低減するため、送信元 IP アドレス範囲はすべての通信（ 0.0.0.0/0 ）とはせず、接続元のオフィスや環境のグローバル IP アドレスのみに制限することを強く推奨します。 VPC ネットワークやファイアウォールルールの詳細については、以下の記事を参照してください。 blog.g-gen.co.jp blog.g-gen.co.jp RDP での接続確認 ファイアウォールルールの設定が完了したら、ローカル PC の RDP クライアントを起動します。 接続先として VM インスタンスの外部 IP アドレスを指定し、先ほど発行したユーザー名とパスワードを入力することで、Windows Server へログインできます。 操作方法や UI は、使用する RDP クライアントアプリケーションにより異なる点に留意してください。 RDP クライアントアプリケーションでアカウントを追加 RDP クライアントアプリケーションで Windows Server に接続 参考 : RDP を使用して Windows VM に接続する 接続経路の保護 前述のように、ファイアウォールルールによって外部からの RDP 接続を特定の IP アドレスに制限することは有効なアプローチであり、Google Cloud から非推奨とされているわけではありません。 しかし、インターネット経由の直接接続よりもさらにセキュリティを高めたい場合は、Identity-Aware Proxy（以下、IAP）という機能を使用して、よりセキュアな RDP 接続を構成できます。IAP の詳細や、RDP で利用する方法については、以下の記事を参照してください。 blog.g-gen.co.jp blog.g-gen.co.jp また、Cloud VPN を経由することで、自組織のネットワークと VPC ネットワークを接続し、内部 IP アドレスを使ったプライベート接続を確立することもできます。Cloud VPN については、以下の記事を参照してください。 blog.g-gen.co.jp 参考 : Identity-Aware Proxy の概要 参考 : Cloud VPN の概要 その他の設定と Tips Windows Server の日本語設定 起動した Windows Server のデフォルトの言語設定は英語となっています。言語設定を英語のまま運用した場合、導入したアプリケーションによっては文字化けや不整合が発生する可能性がある点に留意してください。 こうした意図しない挙動を防ぐため、Windows Server を日本語設定に変更する必要があります。Windows Server の日本語化手順については、以下の記事を参照してください。 blog.g-gen.co.jp Windows Server のライセンス費用 当記事の手順は、 プレミアムイメージ と呼ばれる、Google が用意したライセンス埋め込み型のイメージから Windows Server を起動する手順です。この場合、ライセンス費用は VM インスタンスの利用料金に含まれ、時間単位で課金されます。ライセンス費用は、VM インスタンスに割り当てられた vCPU 数に応じて変動します。 なお既に自組織で Windows Server の OS ライセンスを所有している場合は、ライセンスの持ち込み（BYOL）が可能な 単一テナントノード を使用することもできます。大規模かつ長期の運用では独自のライセンスを使用することで費用を削減できる可能性がありますが、単一テナントノードの追加費用が発生します。また、ライセンスの持ち込み条件などについては、公式ドキュメントを十分に確認してください。 参考 : Google Cloud での Microsoft ライセンス 今村 壱生 (記事一覧) クラウドソリューション部 ソリューションアーキテクト課 2026年3月にG-genへ入社。約7年間 Web 広告運用やウェブ解析に携わり、その後は社内 SE として開発業務に従事。広告運用の現場感と技術的な視点、その双方を併せ持つ経験をベースに、現在は Google Cloud のスキルアップに注力。データ活用とクラウド技術を融合させ、お客様のビジネス成長を支えるエンジニアを目指している。 Follow

G-gen の杉村です。2026年6月に発表された、Google Cloud や Google Workspace のイチオシアップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに Google Cloud のアップデート BigQuery Editions の最小課金時間が1秒になる fluid scaling が一般公開（GA） Cloud Interconnect のシングルリージョン構成で 99.99% SLA BigQuery の生成 AI 関数で上限（クォータ）が任意に設定できるように 利用料の BigQuery エクスポートで FOCUS 形式での出力が可能に（Preview） NW・Web アプリ監視機能である Cloud Network Insights が一般公開（GA） Gemini Cloud Assist で BigQuery の管理・運用支援が可能に（Preview） Gemini Cloud Assist で BigQuery のクエリの最適化が可能に（Preview） Gemini Enterprise app でモバイルアプリが一般公開（GA） 課金レポートで「プロダクト」「発生元サービス」フィルタが使用可能に Gemini Enterprise app が Slack から呼び出せるように（GA） Gemini Enterprise app で Skills が使用可能に（Allowlist 付き GA） BigQuery の自動エンベディング生成が一般公開（GA） Security Command Center Premium で External Exposure が Preview 公開 データポータルで閲覧者権限でもデータの更新ができるようになった Gemini Enterprise app でワークフローエージェントが Allowlist 付き一般公開 Cloud Shell 環境のデフォルトから terraform CLI が削除 BigQuery の Conversational Analytics（会話型分析）が一般公開（GA） BigQuery pipelines でトリガーベースのスケジューリングが Preview 公開 BigQuery の VECTOR_SEARCH 関数で「ハイブリッド検索」が Preview Gemini Enterprise app に Agent Registry からのエージェント登録が可能に VPC Service Controls が Agent Identity や SPIFFE 形式 ID に対応 Gemini Enterprise app の SharePoint / OneDrive のフィルタ（Preview） Google Workspace のアップデート Google ドライブの「ファイルの整理」機能が一般公開（GA） Google Workspace Studio でリストに対するループ処理が可能に Google カレンダーの Data Loss Prevention がベータ版 → 一般公開（GA） Ask Gemini in Drive で Gmail をソースとして追加できるように Google Vault が Gemini アプリに対応 GWS 版 Gemini アプリで「一時チャット」「会話履歴削除」が可能に スプレッドシートで Gemini による作成・編集機能が日本語に対応 スプレッドシートで Gemini による数式エラートラブルシューティング Google Workspace で増分エクスポートが使用可能に Google Meet の管理者設定で動画帯域幅のダウンリンクを制限できるように はじめに 当記事では、毎月の Google Cloud（旧称 GCP）や Google Workspace（旧称 GSuite）のアップデートのうち、特に重要なものをまとめます。 また当記事は、Google Cloud に関するある程度の知識を前提に記載されています。前提知識を得るには、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp リンク先の公式ガイドは、英語版で表示しないと最新情報が反映されていない場合がありますためご注意ください。 Google Cloud のアップデート BigQuery Editions の最小課金時間が1秒になる fluid scaling が一般公開（GA） BigQuery fluid scaling (2026-06-03) BigQuery Editions スロットの最小課金時間が1秒になる「fluid scaling」が一般公開（GA）。 Reservation で有効化すると、通常1分の最低課金時間が1秒になる。小規模クエリが断続的に実行されるような環境で、コスト最適化に繋がる可能性がある。 ただ idol slots の共有され方に影響がでる可能性もあるため留意が必要。 Cloud Interconnect のシングルリージョン構成で 99.99% SLA Cloud Interconnect release notes - June 02, 2026 (2026-06-02) Cloud Interconnect（Dedicated Interconnect / Cross-Cloud Interconnect）で条件を満たせばシングルリージョン構成かつシングル Metro 構成でも、99.99% の SLA が適用されるようになった。 VLAN アタッチメント4つと2施設で構成。 BigQuery の生成 AI 関数で上限（クォータ）が任意に設定できるように Control costs with token quotas (2026-06-08) BigQuery の生成 AI 関数（AI.GENERATE 等）で消費されるトークン量に対して1日あたりの上限（クォータ）を設定する機能が一般公開（GA）。 入出力トークンのクォータを設定でき、費用の制御に役立つ。 利用料の BigQuery エクスポートで FOCUS 形式での出力が可能に（Preview） Set up Cloud Billing data export to BigQuery (2026-06-08) Google Cloud 利用料金の BigQuery エクスポートで FOCUS（FinOps Open Cost and Usage Specification）形式での出力が可能に（Preview）。 FOCUS とは、クラウドベンダーごとに異なる請求データのスキーマを標準化して、一貫したコスト分析を可能にするオープン仕様。 NW・Web アプリ監視機能である Cloud Network Insights が一般公開（GA） Cloud Network Insights overview (2026-06-08) Network Intelligence Center でマルチクラウド・ハイブリッドネットワーク全体を監視・可視化する Cloud Network Insights が一般公開（GA）。 ネットワークや Web アプリのレイテンシ、パケロスなどを可視化。Web アプリの監視時は、Selenium がで実際に動作して HTML/JavaScript をレンダリング。 時間課金もしくは監視パス数あたりのサブスクリプション形式で料金が発生する。 Gemini Cloud Assist で BigQuery の管理・運用支援が可能に（Preview） Administer BigQuery (2026-06-11) Gemini Cloud Assist で BigQuery の管理・運用支援が可能に（Preview）。 パフォーマンス監視、キャパシティ分析、コスト最適化に関する洞察を AI が提供。 従来の Gemini Cloud Assist in BigQuery は SQL 生成等のみだった。 Gemini Cloud Assist で BigQuery のクエリの最適化が可能に（Preview） Optimize a query (2026-06-15) Gemini Cloud Assist で BigQuery のクエリの最適化が可能に（Preview）。 クエリ構造を分析し、スロット時間を短縮できるようサジェスト。BigQuery Studio のクエリエディタのツールバーから使用可能。 BigQuery Editions 利用ユーザーが対象。 Gemini Enterprise app でモバイルアプリが一般公開（GA） Configure the mobile app (2026-06-12) Gemini Enterprise app で、モバイルアプリが一般公開（GA）。 まずは Google Identity 向け（Google Workspace ユーザーでの認証）。 Entra ID などでの認証は、Allowlist 付き GA の扱い。 課金レポートで「プロダクト」「発生元サービス」フィルタが使用可能に Cloud Billing release notes - June 15, 2026 (2026-06-15) Google Cloud課金レポートで「プロダクト」「発生元サービス」という2つのフィルタ/グルーピングオプションが新しく使えるようになった。 「プロダクト」は Firebase App Hosting のように複数 SKU を跨ぐ論理的な単位（従来からある「サービス」とはまた別軸）。 「発生元サービス」は GKE が Compute Engine を消費する場合等に、コストの起点となったサービスを特定するためのフィルタ/グルーピングオプション。 Gemini Enterprise app が Slack から呼び出せるように（GA） Configure the Gemini Enterprise app for Slack (2026-06-17) Gemini Enterprise app が Slack から呼び出せるように（GA）。 DM、スラッシュコマンド、メンションで Gemini Enterprise を呼び出しインタラクションや検索ができる。 Slack AI アドオン（と記載だがおそらく Slack Business+ プラン以上のこと）が必要。 Gemini Enterprise app で Skills が使用可能に（Allowlist 付き GA） Create and manage skills (2026-06-17) Gemini Enterprise app で Skills が使用可能に（Allowlist 付き GA）。 Agent Skills の標準企画に準拠。Agent Skills とは、AI に特定のタスクに特化した振る舞いを行わせることができる拡張機能のこと。skills.md というマークダウンファイルで、自然言語で AI の振る舞いを定義する。Gemini Enterprise app の Skills は、Bash または Python のスクリプトも実行できる。 Agent Skills については、以下の記事も参照。 blog.g-gen.co.jp BigQuery の自動エンベディング生成が一般公開（GA） Autonomous embedding generation (2026-06-17) Preview だった BigQuery の自動エンベディング生成が一般公開（GA）。 CREATE/ALTER TABLE 文で設定することで、ソース列のデータ追加/変更に合わせて BigQuery が自動的にエンベディング列をメンテナンスしてくれる。 よって、常に最新情報でベクトル検索が可能。 Security Command Center Premium で External Exposure が Preview 公開 Use the External Exposure service to detect exposed resources (2026-06-18) Security Command Center（Premium ティア）で External Exposure が Preview 公開。 Google Cloud 環境全体で外部公開の IP アドレス、ホスト名、ドメイン名、URL を継続スキャンして偶発的な公開やシャドウリソースを検出。継続的な検知により、アタックサーフェイス縮小に役立つ。 データポータルで閲覧者権限でもデータの更新ができるようになった Viewer data refresh (2026-06-18) データポータル（英名 Data Studio、旧称 Looker Studio）で閲覧者権限でもデータの更新ができるようになった。 「ファイル > レポートの設定」からレポートごとに有効化可能。データスタジオ Pro だと管理者設定で禁止も可能。 Gemini Enterprise app でワークフローエージェントが Allowlist 付き一般公開 Gemini Enterprise release notes ‐ June 18, 2026 (2026-06-18) Gemini Enterprise app でワークフローエージェントが Allowlist 付き一般公開。使用には申請が必要（公式ガイドへのアクセスも承認が必要）。 従来の Agent Designer（ノーコードエージェント作成 UI）より詳細なワークフローを Web UI で定義できる。 Cloud Shell 環境のデフォルトから terraform CLI が削除 Cloud Shell release notes ‐ June 20, 2026 (2026-06-20) Google Cloud の Cloud Shell 環境のデフォルトから terraform CLI が削除される。 今後は手動または .customize_environment でインストールする必要あり。 BigQuery の Conversational Analytics（会話型分析）が一般公開（GA） BigQuery release notes ‐ June 23, 2026 (2026-06-23) BigQuery の Conversational Analytics（会話型分析）が Preview → 一般公開（GA）。 GA 公開と同時に、高速/思考モードの切替や、エージェントからの逆質問などが実装され、より高度になった。 BigQuery pipelines でトリガーベースのスケジューリングが Preview 公開 Trigger-based scheduling (2026-06-23) BigQuery pipelines で、対象テーブルが更新されたタイミングで自動的に処理を実行できる「トリガーベースのスケジューリング」が Preview 公開。 上流テーブルのデータが到着次第、すぐに後続処理を開始できる。最小・最大待機時間も設定可能で頻度をコントロールできる。 BigQuery の VECTOR_SEARCH 関数で「ハイブリッド検索」が Preview BigQuery release notes - June 25, 2026 (2026-06-25) BigQuery の VECTOR_SEARCH 関数で、ベクトル検索とキーワード検索を組み合わせた「ハイブリッド検索」が Preview 提供開始。 AI.SEARCH 関数の HYBRID モードも同時に提供開始。ベクトルインデックスにキーワード検索用の列を加えることも可能に。 Gemini Enterprise app に Agent Registry からのエージェント登録が可能に Import A2A agents from Agent Registry (2026-06-25) Gemini Enterprise app に Agent Registry から A2A エージェントや MCP サーバーを登録できるようになった。 Registry に登録されたエージェントは Agent Gateway によるトラフィック制御も可能。 VPC Service Controls が Agent Identity や SPIFFE 形式 ID に対応 Supported identities for ingress and egress rules (2026-06-29) VPC Service Controls が Agent Identity や、Workload / Workforce Identitity 連携された SPIFFE 形式 ID に対応（GA）。 AI エージェントのアクセス制御を VPC SC 境界で厳密に行うことができる。以下の記事も参照。 blog.g-gen.co.jp Gemini Enterprise app の SharePoint / OneDrive のフィルタ（Preview） Gemini Enterprise release notes - June 29, 2026 (2026-06-29) Gemini Enterprise app の SharePoint コネクタおよび OneDrive コネクタでフィルタが使用可能に（Preview）。 サイトやパスにフィルタをかけられる。除外フィルタと包含フィルタが指定可能。 Google Workspace のアップデート Google ドライブの「ファイルの整理」機能が一般公開（GA） Organize My Files in Drive now generally available (2026-06-01) Google ドライブの「ファイルの整理」機能が一般公開（GA）。 AI モデル Gemini がフォルダの作成とファイルの移動先を提案して、簡単にファイルを整理。まずは英語版で利用可能になった。2026-07-15 からはエディションごとの使用回数上限が適用される見込み。 Google Workspace Studio でリストに対するループ処理が可能に Introducing the ability to loop over a list of items in Workspace Studio (2026-06-02) AI ワークフローツール「Google Workspace Studio」でリストに対するループ処理が可能に。 Ask Gemini の出力をリスト形式にでき、その出力リストの各項目に対して後続ステップでループ処理を実行できるようになった。 スプシデータの行ごとに処理するようなことも可能。 Google カレンダーの Data Loss Prevention がベータ版 → 一般公開（GA） Data loss prevention policies for Google Calendar now available in GA (2026-06-03) Google カレンダーの Data Loss Prevention（DLP、データ損失防止）がベータ版 → 一般公開（GA）。 予定タイトル、説明、場所をスキャンして機密情報を検知。デフォルトではオフ。 Ask Gemini in Drive で Gmail をソースとして追加できるように Gmail as a source in Ask Gemini in Drive now generally available (2026-06-03) Ask Gemini in Drive で Gmail をソースとして追加できるように。 Ask Gemini in Drive は Google ドライブ内の特定ファイルをソースとして AI にタスクを行わせる機能（NotebookLM に似る）。ここにメールを加えられるようになる。 2026-06-03から15日間かけてロールアウト。 Google Vault が Gemini アプリに対応 Google Vault now supports retention rules and litigation holds for Gemini app (2026-06-11) Google Workspace の Google Vault が Gemini アプリに対応。 Vault は監査・訴訟向けにデータを保存・検索可能にする機能。Gemini アプリの会話内容を保持・検索・エクスポート可能になった。 Business Plus や Enterprise Standard / Plus 等で提供。 GWS 版 Gemini アプリで「一時チャット」「会話履歴削除」が可能に Control whether your users can have temporary chats and delete conversations in the Gemini app (2026-06-16) Google Workspace 版の Gemini アプリで「一時チャット」「会話履歴削除」が可能に。 個人版では以前からできたが、Google Workspace 版ではこれまでできなかった。管理者設定でオン・オフ可能（デフォルトでオン）。 利用者側には2026-06-21から1週間程度かけてロールアウト。 なお会話を削除しても、Google Vault のリテンションルールに従ってデータは保持される。 スプレッドシートで Gemini による作成・編集機能が日本語に対応 Expanded language support for building and editing spreadsheets with Gemini (2026-06-18) Google スプレッドシートの Gemini による作成・編集機能が正式に日本語を含む28言語に対応。 自然言語による指示でスプシ全体を編集したり分析したり、図表を作ったりできる。 スプレッドシートで Gemini による数式エラートラブルシューティング Troubleshoot formula errors quickly with Gemini in Google Sheets (2026-06-22) Google スプレッドシートで Gemini による数式エラートラブルシューティングが利用可能に。 数式セルだけでなく周囲のデータ構造も解釈して、数式の修正をサジェスト。エラーとなってるセルから1クリックで呼び出せる。2026-06-22から段階的ロールアウト。 Google Workspace で増分エクスポートが使用可能に Streamline your data backups with incremental exports for Google Workspace (2026-06-26) Google Workspace で増分エクスポートが使用可能になった。 これまでも Cloud Storage バケットへのフルエクスポートが可能だったが、今後は定期的に Gmail、Drive、Chat などのデータを増分でバックアップできる。 Google Meet の管理者設定で動画帯域幅のダウンリンクを制限できるように Updated admin setting for improved video quality in Google Meet (2026-06-29) Google Meet の管理者設定で、動画が使う帯域幅のダウンリンク（ダウンロード）側を制限できるように。これまではアップリンク側しか制限できなかった。 ユーザー側の設定ではなく管理者側の設定のみ。社内ネットワークの帯域のコントロールが精密になる。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の本間です。BigQuery の自動化機能であるスケジュールドクエリ（Scheduled queries）を解説します。 概要 スケジュールドクエリとは ユースケース 料金 主な機能と特徴 スケジュール設定 クエリ結果の書き込み 書き込み方式の概要 DML を使用した書き込み 宛先テーブルを指定した書き込み ランタイムパラメータの利用 権限と IAM ロール クエリの実行主体 スケジュール作成者に必要な権限 クエリ実行主体に必要な権限 注意点と制限事項 毎正時（00分）指定における重複実行のリスク 実行遅延の可能性 概要 スケジュールドクエリとは スケジュールドクエリ（Scheduled queries） とは、BigQuery において SQL クエリの実行を自動化し、指定したスケジュールで繰り返し実行できる機能です。 日本語の公式ドキュメントでは「スケジュールされたクエリ」と表記されていますが、当記事では実務でも馴染みのある「スケジュールドクエリ」で表現を統一します。 データ分析の現場では、毎日特定の時間に集計レポートを作成したり、1 時間ごとに生データを集計用テーブルに書き込んだりするタスクが頻繁に発生します。スケジュールドクエリを使用することで、外部のオーケストレーションツールやサーバーを用意することなく、BigQuery 単体でこれらのバッチ処理を自動化できます。 またスケジュールドクエリは、BigQuery Data Transfer Service（以下、DTS）の仕組みをベースに提供されています。そのため、内部的には DTS の転送設定として管理されます。 参考 : クエリのスケジューリング 参考 : BigQuery Data Transfer Service の概要 BigQuery の詳細は、以下の記事を参照してください。 blog.g-gen.co.jp ユースケース スケジュールドクエリは、以下のようなユースケースに役立ちます。 毎日深夜に、前日分のログデータを集計して日次レポート用テーブルを更新する 1 時間ごとに、生データから不要なカラムを除外したクレンジング済みテーブルを作成する 定期的に特定のクエリを実行し、結果を別のデータセットにあるテーブルへエクスポートする 料金 スケジュールドクエリ自体の機能利用に対する追加料金は発生しません。無料で使用できます。 ただし、スケジュールによって実行された SQL クエリがスキャンしたデータ量に応じて、通常の BigQuery クエリ料金（オンデマンド料金または容量制料金）が発生します。また、クエリ結果を保存するテーブルのストレージ料金も通常通り発生します。 参考 : BigQuery の料金 主な機能と特徴 スケジュール設定 クエリを実行する頻度は柔軟に設定できます。2026年6月現在、以下のような指定方法がサポートされています。 スケジュールの種類 詳細 事前定義された頻度 分、時間、日、週、月 カスタムスケジュール App Engine Cron 形式による柔軟な日時指定 オンデマンド スケジュールなし（任意のタイミングで手動実行） カスタムスケジュールを使用することで、「毎月第 1 月曜日の朝 9 時（1st monday of month 09:00）」や「毎日 10 時から 14 時の間、30 分おき（every 30 minutes from 10:00 to 14:00）」といった複雑なスケジュールにも対応できます。 参考 : クエリのスケジューリング - スケジュールされたクエリを設定する クエリ結果の書き込み 書き込み方式の概要 スケジュールドクエリの代表的なユースケースは、先述の通りログの定期的な集計や、データマートの作成（ELT 処理）です。そのため、スケジュール実行されたクエリの処理結果は、別のテーブル（ターゲットテーブル）に書き出して保存するのが一般的です。 スケジュールドクエリで処理したデータをターゲットテーブルに書き込むには、主に2つの方法があります。1つは SQL 文内で DML（データ操作言語）を使用する方法、もう1つはスケジュールの設定で「クエリ結果の宛先テーブル」を指定する方法です。 DML を使用した書き込み クエリの SQL 文内に INSERT 、 UPDATE 、 DELETE 、 MERGE などの DML を直接記述して、テーブルのデータを操作します。複雑な条件でのデータ更新や、複数テーブルに対する柔軟な処理を行う場合に適しています。 参考 : データ操作言語（DML）を使用してデータを更新する 宛先テーブルを指定した書き込み クエリには SELECT 文のみを記述し、スケジュール設定画面で「クエリ結果の宛先テーブル」オプションを有効化して書き込み先を指定する方法です。この機能を使用する場合、ターゲットテーブルへの書き込みモードとして以下の 2 つから動作を選択します。 モード 動作 テーブルの上書き（ WRITE_TRUNCATE ） 既存のターゲットテーブルのデータをすべて削除し、今回のクエリ結果で完全に置き換えます。 テーブルへの追加（ WRITE_APPEND ） 既存のターゲットテーブルのデータを保持したまま、今回のクエリ結果を末尾に追記します。 ランタイムパラメータの利用 スケジュールドクエリでは、クエリの実行予定時間を動的に表すランタイムパラメータを SQL 文中で使用できます。 利用可能なランタイムパラメータは以下の 2 つです。 パラメータ 説明 @run_time クエリが実行される予定のタイムスタンプ（UTC） @run_date クエリが実行される予定の日付（UTC） これらを SQL の WHERE 句などに使用することで、「実行時点の前日分のデータだけを抽出する」といった動的な処理ができます。これにより、スケジュール実行のたびに毎回同じデータ全体を無駄にスキャンしたり、処理したりすることを防ぐことができます。 以下の SQL は、実行時点の「前日分」のデータだけを抽出する動的なフィルタリングの例です。 SELECT user_id, COUNT (event_id) AS event_count, @run_date AS summary_date FROM `my-project.raw_data.events` WHERE -- イベント発生日（event_date）が「実行日の前日」であるデータを抽出 event_date = DATE_SUB(@run_date, INTERVAL 1 DAY) GROUP BY user_id なお @run_date や @run_time は UTC（協定世界時）で評価されます。日本時間（JST）を基準とした厳密な日次バッチ処理を行う場合は、SQL 内でタイムゾーンの変換（ DATE(@run_time, 'Asia/Tokyo') など）を考慮して設計してください。 参考 : クエリのスケジューリング - 利用可能なパラメータ 権限と IAM ロール クエリの実行主体 スケジュールドクエリには、「スケジュールを設定・管理するプリンシパル（ユーザー）」と「指定した時間に実際にクエリを実行するプリンシパル」の2つが関与します。 スケジュールドクエリを実行するプリンシパルは、デフォルトでは スケジュールを設定したユーザー となります。 この状態で運用を続けると、ユーザーの異動や退職によってアカウントが削除されたり、権限が変更された際に、クエリが失敗する原因になり得ます。 そのため、本番環境の運用では、 サービスアカウントをクエリの実行主体として指定 することが推奨されます。これにより、スケジュールを設定したユーザーが異動して権限が変更されたり、退職してアカウントが削除されてもスケジュールドクエリに影響が出ないため、安全に運用できます。 BigQuery の認証・認可の詳細は、以下の記事を参照してください。 blog.g-gen.co.jp スケジュール作成者に必要な権限 スケジュールの設定画面を操作し、ジョブを登録するユーザーには以下の権限が必要です。 目的 必要な IAM ロール 割り当て対象 スケジュールの作成と管理 BigQuery 管理者（ roles/bigquery.admin ） プロジェクトレベル サービスアカウントの割り当てと選択 サービスアカウントユーザー（ roles/iam.serviceAccountUser ） サービスアカウント閲覧者（ roles/iam.serviceAccountViewer ） 実行を委譲する サービスアカウント クエリ実行主体に必要な権限 バックグラウンドで実際にクエリを実行し、データの読み書きを行うアカウントやサービスアカウントには、以下の権限を付与します。 目的 必要な IAM ロール 割り当て対象 クエリの実行 BigQuery ジョブユーザー（ roles/bigquery.jobUser ） プロジェクトレベル ソースデータの閲覧 BigQuery データ閲覧者（ roles/bigquery.dataViewer ） プロジェクトまたはデータセットレベル（抽出元） ターゲットへの書き込み BigQuery データ編集者（ roles/bigquery.dataEditor ） プロジェクトまたはデータセットレベル（書き込み先） BigQuery の仕様として、「BigQuery データ編集者（ roles/bigquery.dataEditor ）」ロールにはデータの閲覧権限も含まれています。そのため、データの抽出元と書き込み先が同じデータセット内で完結する場合や、プロジェクトレベルでBigQuery データ編集者ロールを付与する場合は、ソースデータに対して別途「BigQuery データ閲覧者（ roles/bigquery.dataViewer ）」ロールを付与する必要はありません。プロジェクトやデータセットをまたいで処理を行う場合のみ、抽出元のデータセットに対して閲覧権限を付与してください。 参考 : クエリのスケジューリング - 必要な権限 注意点と制限事項 毎正時（00分）指定における重複実行のリスク スケジュールを「毎時 00 分（例 : 09:00）」など、「正時」のタイミングに設定すると、内部的なトリガーが複数回起動してしまい、同一のクエリが重複して実行される事象が稀に発生します。 結果として、追記モード（ WRITE_APPEND ）の際にデータが二重に取り込まれてしまうリスクがあります。これを防ぐため、公式ドキュメントでも 08:58 や 09:03 など、 正時から数分ずらしたスケジュールを設定すること が推奨されています。 参考 : クエリに関する問題のトラブルシューティング - スケジュールされたクエリが重複して実行される 実行遅延の可能性 スケジュールドクエリの基盤である DTS の仕様上、秒単位での厳密な実行タイミングが保証されているわけではありません。リソース状況等により、実際の実行時刻に遅延（Pending）が発生する可能性がある点に留意して設計してください。 また、Google Cloud の一般的なベストプラクティスとして、「クエリ A の完了を待ってからクエリ B を実行する」といった依存関係の制御や、高度なエラーハンドリングが必要なワークロードにおいては、スケジュールドクエリではなく、Dataform や Cloud Workflows といった専用のワークフロー管理サービスの利用が推奨されています。 参考 : ワークロードのスケジュールを設定する 参考 : Dataform の概要 参考 : ワークフローの概要 本間 優太郎 (記事一覧) クラウドソリューション部 クラウドエンジニアリング2課 北海道在住 2026年6月に G-gen にジョイン。前職では社内SE、Sler としてアプリ/インフラ開発業務に従事。アプリ/インフラ双方の経験をベースに現在はGoogle Cloudの学習を進めている。 好きなことは子供と遊ぶこと、ゲームをすること。

G-gen の福井です。Google Workspace Studio のループ機能を使用して、Google Meet の文字起こしから議事録を作成し、会議で決まったタスクを Google Tasks へ自動登録するフローを作成する手順を紹介します。 はじめに 当記事の概要 Google Workspace Studio とは ループ機能（Repeat for each）とは 作成するフロー 処理の全体像 注意事項 フローの作成手順 開始条件 : フォルダへのアイテム追加 議事録の作成 議事録ファイル名の生成 Google ドキュメントへの保存 タスク一覧の抽出 ループによるタスク登録 動作確認 はじめに 当記事の概要 当記事では、Google Workspace の自動化ツールである Google Workspace Studio を使用して、議事録の作成からタスク登録までを自動化するフローを作成します。具体的には、Google Meet の文字起こしデータをもとに議事録を作成して Google ドキュメントとして保存し、続けてその議事録から会議で決まったタスクを抽出して、1件ずつ Google Tasks に登録します。 これまでの Google Workspace Studio では、文字起こしデータから議事録を作成することはできても、会議で挙がったタスクを1件ずつ Google Tasks へ登録するような繰り返し処理はできませんでした。2026年6月にループ機能が追加されたことで、この繰り返し処理ができるようになりました。当記事では、このループ機能を中心にフローの作成手順を解説します。 Google Workspace Studio とは Google Workspace Studio は、Google Workspace のアプリケーションを連携させて定型業務を自動化できる、Gemini を搭載したノーコードの自動化ツールです。あらかじめ用意された開始条件（トリガー）とステップ（アクション）を組み合わせて「フロー」を作成することで、プログラミングなしに業務を自動化できます。 たとえば「特定のフォルダにファイルが追加されたら、その内容を Gemini で要約して Google Chat に通知する」といった処理を、コードを書かずに実現できます。 Google Workspace Studio の概要や基本的な使い方は、以下の記事で詳しく解説しています。当記事ではフローの作成手順に絞るため、基礎的な概念は以下を参照してください。 blog.g-gen.co.jp ループ機能（Repeat for each）とは ループ機能は、リスト形式のデータに含まれる項目を1件ずつ取り出し、同じ処理（サブステップ）を繰り返し実行する機能です。2026年6月に Google Workspace Studio へ追加されました。 この機能とあわせて、Gemini に相談（Ask Gemini）ステップに「回答の形式」という設定が追加されました。回答の形式で「リスト」を選ぶと、Gemini の出力をリスト形式で受け取れます。このリストをループ機能に渡すことで、リストの各項目に対して同じステップを繰り返し実行できます。 参考 : Introducing the ability to loop over a list of items in Workspace Studio 作成するフロー 処理の全体像 今回作成するフローは、Google ドライブの特定フォルダに Google Meet の文字起こしファイルが追加されたことをきっかけに動き出します。フロー全体は、次の7つのステップで構成されます。 完成したフローの全体像 ステップ 種類 処理内容 1 開始条件 フォルダへのアイテム追加を検知する 2 Gemini に相談 文字起こしから議事録を作成する 3 Gemini に相談 議事録のファイル名を生成する 4 ドキュメントを作成 議事録を Google ドキュメントとして保存する 5 Gemini に相談 議事録からタスク一覧をリスト形式で抽出する 6 繰り返し タスクのリストを1件ずつループする 7 タスクを作成する 各タスクを Google Tasks に登録する（ステップ6のサブステップ） ステップ5でタスクをリスト形式で抽出し、ステップ6のループでそのリストを1件ずつ処理する点が、当記事のポイントです。ステップ7はステップ6のサブステップとして動作し、ループのたびに Google Tasks へタスクを1件ずつ登録します。 注意事項 ループ機能で処理できるのは先頭100件まで ループ機能（繰り返し）が処理できるのは、リストの先頭100件までです（2026年6月現在）。1回の会議から抽出されるタスクが100件を超えることはまれですが、大量のタスクを扱う場合は注意してください。 Google Tasks には担当者を割り当てる項目がない Google Tasks は個人のタスク管理を目的としたツールのため、タスクに担当者を割り当てる項目はありません。そのため当フローでは、会議で決まった担当者と期限日を、タスクの詳細（メモ）欄にテキストとしてまとめて記録します。登録先は、フローを実行したユーザー本人の「マイタスク」です。 フローの作成手順 開始条件 : フォルダへのアイテム追加 開始条件（トリガー）は、フローが動き出すきっかけとなるイベントです。Google Workspace Studio では、スケジュール実行やメールの受信など複数の開始条件が用意されています。 当フローでは [フォルダにアイテムが追加されたとき] を開始条件に選びます。Google Meet で文字起こしを有効にすると、その文字起こしは Google ドライブの Meet Recordings フォルダに Google ドキュメントとして保存されます。このフォルダを監視し、文字起こしが追加されたタイミングでフローを起動します。 開始条件の選択画面で [フォルダにアイテムが追加されたとき] を選択します。 開始条件の選択 続いて、監視するフォルダを指定します。[ドライブ] をクリックし、文字起こしが保存される Meet Recordings フォルダを選択します。 監視するフォルダの選択 これで、対象のフォルダに新しいファイルが追加されるたびに、フローが実行されます。 議事録の作成 開始条件の次に、文字起こしから議事録を作成するステップを追加します。アクションの [ステップの選択] から [Gemini に相談] を選択します。 Gemini に相談ステップの追加 [Gemini に相談] は、入力したプロンプトに沿って Gemini にテキストを生成させるステップです。 ステップを追加すると、プロンプトの入力欄が表示されます。ここに、Gemini へ議事録作成を指示するプロンプトを入力します。 プロンプトの入力 入力したプロンプトの全文は次のとおりです。画面では省略していますが、議事録の体裁を出力フォーマットとして細かく指定したうえで、後続のタスク登録を見据えてアクションアイテムを「1タスク1依頼事項」に分割するよう指示しています。 # 命令書 あなたは、議事録作成のプロフェッショナルです。与えられた「会議の文字起こしデータ（テキスト）」から、会議の目的、議論の詳細なプロセス、結果が正確に理解できる、構造化された議事録を作成してください。 # 制約条件 * 【文章の整形】文字起こしデータ特有の誤字、脱字、フィラー（「えーと」「あのー」など）は、文脈を正確に読み取り、削除・修正（ケバ取り）し、自然で分かりやすい文章にしてください。全体のトーンはビジネス文書として客観的かつ中立的に記述してください。 * 【敬称ルール】発言者の名前は「さん」付けで統一してください。 * 【情報の網羅性】アイスブレイク等は省略して構いませんが、本題に関する議論の過程（どのような意見や懸念が出て、なぜその結論に至ったのか）は決して省略せず、すべての内容を集約させてください。過度な要約による情報欠落を固く禁じます。 * 【ファクトチェック】音声認識エラーと思われる不自然な単語や人名は、前後の文脈を元に論理的に推測し、正しい表記に補正してください。数字、日付、システム要件などの事実は特に正確に記載してください。資料の内容と実際の発言に差異がある場合は、発言内容（最終的な合意）を正とし、その変更に至ったニュアンスを含めて記載してください。 * 【決定事項の記述】決定事項は、単なる結果だけでなく、資料との差異や最終的な合意内容のニュアンスを含めて具体的に記述してください。すべての決定事項においてこのルールを適用します。 * 【アクションアイテムの記述】「誰が」「いつまでに」「何をするか」を明確にしてください。1つのタスクに複数の依頼事項（例：権限付与とインスタンス起動など）を含めず、必ず「1タスク1依頼事項」に分割すること。また要素を漏らさず全て記載してください。すべてのタスクにおいてこのルールを適用します。 * 【不明瞭な箇所】文脈や資料から合理的な推測が不可能な箇所は無理に補完せず `[要確認：発言内容不明瞭]` と記述してください。 # 思考プロセス（ステップ4実行時に内部で行う処理） 1. **全体把握と完全な理解** 入力された「文字起こしデータ」の全体を注意深く読み込みます。会議の主要な目的、全体的な議論の流れ、各参加者の立場や発言の意図、そして最終的な結論（全体像）を完全に理解・把握します。 2. **情報の抽出と詳細へのブレークダウン** 理解した全体構成から、指定フォーマットの各項目へとブレークダウンし、情報を漏れなく抽出します。「決定事項（合意に至ったニュアンスや資料からの変更点）」、「アクションアイテム（付随する細かな依頼内容、担当、期限の全要素）」、およびアジェンダごとの「議論のプロセス（なぜその結論に至ったかの過程）」を、過度な要約をせずに拾い上げます。 3. **構造化と清書** 抽出した情報を指定のMarkdownフォーマットに当てはめ、制約条件（敬称のルール適用、ケバ取り、中立的なトーンへの調整など）を厳格に適用して議事録として清書します。 # 出力フォーマット 以下のMarkdown形式のテンプレートに厳密に従って、議事録を作成してください。 --- ## 議事録 **会議名:** （会議の名称を記述） **日時:** YYYY年MM月DD日 HH:MM - HH:MM **場所:** （会議の場所を記述。オンライン等） **出席者:** （出席者リストを「さん」付けで記述） --- ### 1. 決定事項 * （決定事項の内容） * （決定事項の内容） --- ### 2. アクションアイテム * **TODO:** （タスク内容 ※必ず1タスク1依頼事項） * **担当:** （担当者名） * **期限:** YYYY年MM月DD日 * **TODO:** （タスク内容 ※必ず1タスク1依頼事項） * **担当:** （担当者名） * **期限:** YYYY年MM月DD日 --- ### 3. 議題とディスカッション #### 3.1. （議題1のタイトル） * **（発言者名）:** * （発言内容） * **（発言者名）:** * （発言内容） #### 3.2. （議題2のタイトル） * **（発言者名）:** * （発言内容） === 以下「会議の文字起こしデータ」=== プロンプト末尾の === 以下「会議の文字起こしデータ」=== の下に、文字起こしデータを渡します。[+ 変数] をクリックし、開始条件（ステップ1）の アイテムへのリンク を挿入します。 変数の挿入 挿入した変数には、フォルダに追加された文字起こしファイルへのリンクが入ります。Gemini はこのリンク先のファイルを読み取り、議事録を作成します。 次に、プロンプトの下にある [Gemini が使用できるソース] を設定します。[ウェブ検索] をオフにし、[Workspace] のみをオンにします。 ソースの設定 議事録は文字起こしの内容だけにもとづいて作成すべきであり、ウェブ検索の結果が混ざると事実と異なる内容が含まれるおそれがあるため、ウェブ検索はオフにします。 最後に、画面下部の [回答の形式] で [テキスト] を選択します。議事録は1つの文章として出力するためです。 議事録ファイル名の生成 続いて、作成する議事録に付けるファイル名を生成するステップを追加します。ステップ2と同様に [ステップの選択] から [Gemini に相談] を選択します。 Gemini に相談ステップの追加 1つの [Gemini に相談] ステップで生成できる回答は1つのため、議事録の本文とファイル名を1つのステップで同時に作ることはできません。そのため、議事録本文とは別に、ファイル名を生成する専用のステップを用意します。 プロンプトには、ファイル名を生成する指示を入力します。このとき、あとで変数を埋め込む箇所は 「」 を空けたままにしておきます。あわせて、ファイル名の生成にウェブ検索は不要なため、[ウェブ検索] をオフにします。 ファイル名を生成するプロンプト 入力したプロンプトは次のとおりです。 # 命令書 会議の文字起こしデータを格納したファイルのファイル名「」から「会議実施日付」と「会議名」を抽出し、議事録のファイル名を生成してください。 # 出力フォーマット [会議実施日付（例：20260601）]_[会議名]_議事録 次に、空けておいた 「」 の中に変数を挿入します。[+ 変数] をクリックし、開始条件（ステップ1）の アイテムの表示名 を選択します。 変数（アイテムの表示名）の選択 「」 の中に アイテムの表示名 が挿入されました。 変数が挿入されたプロンプト アイテムの表示名 には、フォルダに追加された文字起こしファイルの名前が入ります。Google Meet の文字起こしファイルの名前には会議名や日時が含まれるため、そこからファイル名を組み立てられます。 Google ドキュメントへの保存 作成した議事録を Google ドキュメントとして保存するステップを追加します。[ステップの選択] から [ドキュメントを作成] を選択します。 ドキュメントを作成ステップの追加 このステップでは、作成するドキュメントの名前と本文を、それぞれ前のステップの出力から指定します。ステップ2とステップ3はどちらも [Gemini に相談] のため、変数の名前はいずれも Gemini で作成されたコンテンツ と表示されます。ステップ番号で見分けて選択してください。 [新しいドキュメントの名前] には、[+ 変数] からステップ3の Gemini で作成されたコンテンツ （ステップ3で生成したファイル名）を選択します。[追加するコンテンツ] には、ステップ2の Gemini で作成されたコンテンツ （ステップ2で作成した議事録の本文）を選択します。 ドキュメントの名前と本文の指定 最後に、保存先を指定します。[ドライブ] をクリックし、保存先のフォルダを選択します。 保存先フォルダの指定 これで、生成した議事録が、指定したファイル名の Google ドキュメントとして保存されます。 タスク一覧の抽出 ここからが、ループ機能を活かす中心部分です。議事録から会議で決まったタスクを抽出し、後続のループで1件ずつ登録できるよう、リスト形式で出力させます。 ステップ4の次に、再び [Gemini に相談] を追加します。プロンプトには、[+ 変数] からステップ2の Gemini で作成されたコンテンツ （議事録の本文）だけを指定します。 タスクを抽出するプロンプト タスクを抽出する具体的な指示は、このあと設定するフィールドの「Gemini の説明」に記述します。そのため、プロンプト本文には議事録の変数のみを置き、指示は書きません。 次に、[回答の形式] で [リスト] を選択します。続けて [リスト形式] で カスタム構造化データ を選び、タスク1件が持つフィールドとして タスク名 ・ 期限日 ・ 担当者 を定義します。各フィールドの「Gemini の説明」に、議事録のアクションアイテムから対応する情報を抽出する指示を記述します。 リスト形式とフィールドの定義 [リスト] を選ぶことで、Gemini の出力をリスト形式で受け取れ、後続のループ（繰り返し）で1件ずつ処理できます。各フィールドの「Gemini の説明」に設定した内容は次のとおりです。 フィールド名 Gemini の説明 タスク名 会議議事録の「アクションアイテム」に定義された内容から「タスク名」を原文のまま抽出すること 期限日 会議議事録の「アクションアイテム」に定義された内容から「期限日」を「2026年06月01日（月）」の形式で抽出。日付形式で期限日が指定されていない場合はブランクとすること 担当者 会議議事録の「アクションアイテム」に定義された内容から「担当者」を原文のまま抽出。担当者が指定されていない場合はブランクとすること ループによるタスク登録 最後に、抽出したタスクのリストをループで1件ずつ Google Tasks に登録します。 ステップ5の次に、ループ処理を行う [それぞれについて繰り返す] を追加します。 繰り返しステップの追加 これがループ機能（繰り返し）です。指定したリストの各アイテムに対して、この中に置いたサブステップを順番に実行します。処理されるのはリストの先頭100件までです。 続いて、ループの対象とするリストを指定します。[+ 変数] からステップ5の 詳細リスト - Gemini が作成したリスト を選択します。 ループ対象リストの選択 これで、ステップ5で抽出したタスクのリストを1件ずつ処理できます。リストの各アイテムは、 タスク名 ・ 期限日 ・ 担当者 の3つのフィールドを持ちます。 次に、ループの中で実行する処理を追加します。[サブステップを追加] から、Google Tasks にタスクを登録する [タスクを作成する] を選択します。 タスクを作成するサブステップの追加 このサブステップは、ループのたびに（タスク1件ごとに）実行されます。 [タスクを作成する] では、タスクのタイトルと詳細を、ループの各アイテムの値から指定します。[タスクのタイトル] には、[+ 変数] からステップ6の タスク名 を指定します。[タスクの詳細] には、 期限日： と入力してその後ろにステップ6の 期限日 を、改行して 担当者： と入力してその後ろにステップ6の 担当者 を挿入します。 タスクのタイトルと詳細の設定 以上で、文字起こしの追加から議事録の作成、タスクの登録までを自動化するフローが完成です。 動作確認 フローが完成したら、画面左上のフロー名を分かりやすい名前（ここでは「議事録作成・タスク登録」）に変更し、[オンにする] でフローを有効化します。 フローの有効化 フローをオンにすると、 Meet Recordings フォルダに文字起こしが追加されるたびに、自動で実行されます。実行結果は、画面右上のアクティビティ（グラフのアイコン）から確認できます。今回はフローが正常に完了しています。 アクティビティでの実行結果の確認 文字起こしが追加されると、まず議事録が Google ドキュメントとして作成されます。プロンプトで指定した出力フォーマットのとおり、決定事項やアクションアイテムが整理されています。 作成された議事録 続いて、議事録から抽出されたタスクが、1件ずつ Google Tasks に登録されます。各タスクのタイトルにはタスク名が、詳細欄には期限日と担当者が記録されています。 Google Tasks に登録されたタスク 福井 達也 (記事一覧) クラウドソリューション部 元はアプリケーションエンジニア(インフラはAWS)として、PM/PL・上流工程を担当。G-genのGoogle Cloudへの熱量、Google Cloudの魅力を味わいながら日々精進 Google Cloud Partner Top Engineer 2026 選出。

G-gen の西田です。ノーコードで Google Workspace のタスクを自動化できる Google Workspace Studio に導入された、リストデータを繰り返し処理できる ループ処理機能 について解説します。 はじめに Google Workspace Studio とは ループ処理機能の概要 検証シナリオ 設定手順 動作確認 はじめに Google Workspace Studio とは Google Workspace Studio とは、プログラミングを行うことなく、Google Workspace の各アプリケーションや Gemini を組み合わせた自動化フローを作成できる AI エージェントツール です。 ユーザーは「ステップ」と呼ばれる個々のタスクを順に配置することで、複雑な業務プロセスを自動化できます。例えば、「メールを受信したら Gemini で内容を要約し、Google Chat に投稿する」といったフローを直感的に構築可能です。 Google Workspace Studio の詳細やコンセプトについては、以下の記事を参照してください。 blog.g-gen.co.jp ループ処理機能の概要 Google Workspace Studio のフローにおいて、2026年6月に リストをループ処理する機能 が導入されました。これにより、リスト形式のデータに対して同じ処理を繰り返し実行できるようになりました。これまでは1つのデータに対して1つの処理を行うフローが中心でしたが、今回のアップデートにより、リストデータを一括で処理する高度な自動化が容易になります。導入された機能は主に以下の2つです。 機能 概要 Ask Gemini のリスト出力 「Ask Gemini」ステップの「Response format」設定に リスト形式 が追加されました。Gemini に相談した結果を構造化されたリストとして後続のステップに渡すことができます。 Repeat for each Gemini に相談した結果のリストの各項目や Google スプレッドシートの各行に対して、指定した一連の処理（サブステップ）を 繰り返し実行 するステップです。 参考 : Introducing the ability to loop over a list of items in Workspace Studio - Google Workspace Updates 検証シナリオ ループ機能の具体的な活用例として、社内パソコンの管理台帳（Google スプレッドシート）を参照し、OS のサポートが切れている端末の利用者へ案内メールの下書きを作成するフローを構築します。 検証用の管理台帳には、端末管理ソフト等で取得できるデータの一部である、「端末 ID」「マシンベンダー」「OS」「最終起動日」「ログイン ID」「メールアドレス」の項目を持つリストを使用します。 フローでは以下の処理を自動化します。 Gemini で案内メールのテンプレートを作成 管理台帳からデータを取得 各行の OS 情報をチェックし、サポート切れの場合はメールの下書きを作成 管理台帳の「ステータス」列を Done に更新 設定手順 Google Workspace Studio で以下のステップを持つフローを作成します。 ステップ1: トリガー設定 フローが実行されるトリガーを設定します。今回は特定の日時に開始するように設定します。 ステップ2: メール文面作成 サポート切れのパソコンの利用者に向けた案内メールの文面を作成します。検証では「Gemini に相談」を利用して文章を作成します。 なお本来、ここで指定するメールの文面は定型文で問題ありませんが、当記事では Gemini による生成機能の説明を目的として「Gemini に相談」を使用しました。 ステップ3: リストデータ取得 「シートのコンテンツを取得」アクションを選択し、対象のスプレッドシートのシートからリストデータを取得します。すべての行を取得するため「値を取得する行を検索」では、「すべて」を指定します。 ステップ4: ループ処理開始 ループ処理を設定します。日本語の画面では、「それぞれについて繰り返す」というツールを選択します。 「リストを選択します」の変数ボタンから、ステップ3で取得したシートのコンテンツを選択し、「詳細リスト - 一致する値」を指定します。 ステップ5: 処理対象か確認 ループ内のサブステップとして、「OS がサポート切れであるか」を判定するロジックを記述するため、AI アクションの「決定」を追加します。 処理行の「OS」の値を取得するため、プロンプト入力欄の変数ボタンから、ステップ4のループ処理を選択し、その中から「一致する値 "OS" の各アイテム」を指定します。 ここでは、「処理行の OS がサポート切れである」という条件から真偽値を判定させます。 ステップ6: 条件分岐 条件分岐のステップでは、ステップ5の結果が "真" である場合、後続のステップに進ませるようにします。 ステップ7: 下書き作成 条件に一致した行の "メールアドレス" 宛のメールの下書きを作成します。宛先のメールアドレスは、ステップ4のループ処理の中から「一致する値 "メールアドレス" の各アイテム」を指定します。メッセージ（本文）は、ステップ2で作成した文面を指定します。 ステップ8: 台帳更新 下書きを作成した行については、作成済みの記録を入力する処理を設定するため「行を更新」というステップを選択します。更新対象のスプレッドシート、シート、対象の行および入力する値をそれぞれ指定します。 動作確認 フローをテスト実行すると、管理台帳の各行が順番に処理されます。 管理台帳を確認すると、Windows 11 の行以外については、サポート切れ OS と判定され、G 列に下書きが作成された記録が入力されています。 また、作成された下書きメールは以下の通りです。今回の管理台帳では対象となる行が45行ありましたので、同様の下書きメールも45件作成されました。 なお、ループ処理できる行の数は画面の注意書きに記載の通り、100件までです。 101件目以降のデータを処理する場合は、スプレッドシートのシートからのリストデータ取得時に条件を加えるなどして調整します。上記の手順では、ステップ3の「シートのコンテンツを取得」のステップに、「下書き作成」が空白であるといった抽出条件を加えます。 西田 匡志 (記事一覧) クラウドソリューション部 美容商社→物流→情シスを経て、2025年6月G-genにジョイン。Google Cloud を通じて多くの人に貢献できるよう日々精進！

G-gen の武井です。当記事では、Google Cloud のセキュリティ対策を観点ごとに整理し、網羅的にまとめます。 はじめに 全体像 証跡管理 概要 関連サービス・機能 Cloud Audit Logs Cloud Logging Cloud Asset Inventory 予防的統制（統制の基盤を整備する） 概要 関連サービス・機能 組織（Organization） 階層構造 組織を使わないリスク 予防的統制（ID・認証基盤を整備する） 概要 関連サービス・機能 Google Workspace / Cloud Identity MFA / パスキー Workforce Identity Federation（外部 IdP 連携） Workload Identity Federation（ワークロード間の認証） 予防的統制（コンソール・API へのアクセスを制御する） 概要 関連サービス・機能 Chrome Enterprise Premium Identity-Aware Proxy Access Context Manager Context-Aware Access VPC Service Controls 予防的統制（最小権限の原則を徹底する） 概要 関連サービス・機能 Identity and Access Management（IAM） Privileged Access Manager（PAM） 拒否ポリシー（Deny policies） 予防的統制（組織横断で一貫した統制を適用する） 概要 関連サービス・機能 組織のポリシー（Organization Policy） カスタム制約（Custom Constraints） タグ（Tags） 予防的統制（ネットワークレベルで防御する） 概要 関連サービス・機能 Cloud NGFW（Next Generation Firewall） Cloud Armor Cloud NAT Secure Web Proxy Cloud IDS 予防的統制（データを暗号化・保護する） 概要 関連サービス・機能 Cloud KMS Cloud HSM / Cloud EKM Sensitive Data Protection VPC Service Controls（再掲） Certificate Authority Service Certificate Manager 予防的統制（コンテナやコードの安全性を担保する） 概要 関連サービス・機能 Artifact Registry / Artifact Analysis Binary Authorization GKE セキュリティ機能 Software supply chain security 発見的統制 概要 関連サービス・機能 Security Command Center IAM Recommender（Active Assist） Cloud Monitoring Google SecOps（SIEM / SOAR） Mandiant 是正的統制 概要 関連サービス・機能 Config Controller Eventarc + Cloud Run functions / Workflows Google SecOps（SOAR） 経済的統制 概要 関連サービス・機能 Cloud Billing 予算アラート Spend Caps コスト異常検知（Anomaly Detection） Quotas（割り当て） 生成 AI 特有のセキュリティ 概要 生成 AI 基盤の選択 関連サービス・機能 Model Armor Agent Identity Agent Gateway / Agent Registry AI Protection（Security Command Center） Google Workspace はじめに Google Cloud にはセキュリティに関連するサービスが数多く存在します。しかし、いざ Google Cloud 環境をセキュアにしたいと考えたとき、どのサービスをどう組み合わせればよいかを俯瞰的に把握するのは容易ではありません。 当記事では、 セキュリティ上の観点 （何を守りたいか、何を実現したいか）を軸にサービスを分類し、それぞれの課題に応じて必要なサービスを素早く特定できることを目指します。 全体像 当記事では、Google Cloud のセキュリティサービスを以下の5つに分類して解説します。 # 分類 概要 1 証跡管理 「いつ・だれが・何を・どのように」操作したかを記録し、追跡を可能にする 2 予防的統制 不適切な操作や攻撃を未然に防ぐ。 アクセス制御・認証・暗号化・ネットワーク防御等 3 発見的統制 セキュリティ事象や設定ミスを速やかに検知し、可視化する 4 是正的統制 不適切な状態が発生した際に自動的に修復し、あるべき状態を維持する 5 経済的統制 クラウド利用料金の異常な増加から組織を保護する（EDoS 対策を含む） また、各分類に該当する Google Cloud のサービスについては以下のとおりです。 # 目的（分類） 該当サービス 1 操作ログ・資産情報を記録する （証跡管理） ・Cloud Audit Logs ・Cloud Logging ・Cloud Asset Inventory 2 統制の基盤を整備する （予防的統制） ・組織（Organization） ・階層構造 3 ID・認証基盤を整備する （予防的統制） ・Google Workspace / Cloud Identity ・MFA・パスキー ・Workforce Identity Federation ・Workload Identity Federation ・Secret Manager 4 コンソール・API へのアクセスを制御する （予防的統制） ・Chrome Enterprise Premium ・Identity-Aware Proxy ・Access Context Manager ・Context-Aware Access ・VPC Service Controls 5 最小権限の原則を徹底する （予防的統制） ・Identity and Access Management ・Privileged Access Manager ・拒否ポリシー 6 組織横断で一貫した統制を適用する （予防的統制） ・組織のポリシー ・カスタム制約 ・タグ 7 ネットワークレベルでの防御を行う （予防的統制） ・Cloud NGFW ・Cloud Armor ・Cloud NAT ・Secure Web Proxy ・Cloud IDS 8 データを暗号化・保護する （予防的統制） ・Cloud KMS ・Cloud EKM ・Cloud HSM ・Sensitive Data Protection ・VPC Service Controls ・Certificate Authority Service ・Certificate Manager 9 コンテナやコードの安全性を担保する （予防的統制） ・Artifact Registry / Artifact Analysis ・Binary Authorization ・GKE セキュリティ機能 ・Software supply chain security 10 脅威・設定ミスを把握する （発見的統制） ・Security Command Center ・IAM Recommender（Active Assist） ・Cloud Monitoring ・Google SecOps（SIEM / SOAR） ・Mandiant 11 不適切な状態を修復する （是正的統制） ・Config Controller ・Eventarc + Cloud Run functions / Workflows ・Google SecOps（SOAR） 12 クラウドの利用料金を保護する （経済的統制） ・Cloud Billing 予算アラート ・Spend Caps ・コスト異常検知 ・Quotas なお、近年トピックとして重要性が増している 生成 AI 特有のセキュリティ については、独立した章で解説します。 証跡管理 概要 証跡管理 とは、「いつ・だれが・何を・どのように」操作したかを記録し、いつでも追跡可能な状態にしておくための取り組みで、インシデント発生時の原因究明、内部監査・外部監査への対応、内部統制（J-SOX 等）において重要な要素となります。 Google Cloud では、 Cloud Audit Logs が API 操作の監査証跡を自動的に記録し、それらを集約・保管する基盤として Cloud Logging があります。 さらに Cloud Asset Inventory によって、リソース構成の変更履歴を時系列で追跡できます。 関連サービス・機能 Cloud Audit Logs Cloud Audit Logs とは、Google Cloud 上で発生した管理操作・データアクセス・システムイベント等を記録する監査ログサービスです。 Cloud Audit Logs には、以下の4種類のログがあります。 # 名称 説明 料金 デフォルト 1 管理アクティビティ監査ログ リソースに対する管理的な更新系の API リクエストが記録される 無料 有効（無効化できない） 2 データアクセス監査ログ リソースやデータに対する更新系・読み取り系の API リクエストが記録される。有効化するとログ容量が大きくなる可能性があるため注意 有料 無効（BigQuery のみデフォルト有効） 3 システム イベント監査ログ ユーザではなくGoogle Cloudサービスによって行われたリソース構成変更が記録される 無料 有効（無効化できない） 4 ポリシー拒否監査ログ セキュリティポリシー違反（VPC Service Controls や組織のポリシー等）によって拒否された API リクエストが記録される 有料 有効（除外フィルタ設定可能） 特に注意したいのが データアクセス監査ログ です。有効化するとログ量が膨大になり Cloud Logging の料金に影響するため、機密データを扱う API・サービスに絞ってデータアクセス監査ログを有効化するのも一案です。 参考 : Cloud Audit Logsを解説。Google Cloudの証跡管理 - G-gen Tech Blog Cloud Logging Cloud Logging とは、Google Cloud 上のあらゆるログを収集・保管・分析するための基盤サービスで、以下の機能によって構成されます。前述の Cloud Audit Logs もここに集約されます。 特にログシンクは、長期保管目的での Cloud Storage 連携、BigQuery を使った分析、後述の Google SecOps 等 SIEM への連携の起点となる重要な機能です。 # 機能 説明 1 ログエクスプローラ ログクエリ言語による高速なログ検索 2 ログバケット ログエクスプローラでログを可視化するための専用ストレージ 3 ログシンク ログを Cloud Storage、BigQuery、Pub/Sub 等へ転送する機能 4 ログベースのアラート 特定のログパターン検知時のアラート発報 5 ログベースのメトリクス ログから定義可能なカスタムメトリクス 参考 : Cloud Loggingの概念と仕組みをしっかり解説 - G-gen Tech Blog Cloud Asset Inventory Cloud Asset Inventory とは、Google Cloud 上のリソース構成、IAM ポリシー、組織のポリシー等のメタデータを、時系列のスナップショットとして保存・検索できるサービスです。 本サービスは無料で利用できる他、主に以下の用途で利用する機会が多いです。 # 用途 説明 1 資産棚卸 現在のリソース構成を CSV / JSON 等で一括エクスポート （監査・コンプライアンス対応で利用） 2 構成変更履歴の追跡 リソースの状態を時系列で保持し、過去のある時点の構成を確認可能 3 リソース横断検索 組織内のフォルダ、プロジェクトを横断したリソース検索 4 IAM ポリシーの検索 「誰が、どのリソースに、どの権限を持っているか」の俯瞰 5 変更通知 リソース変更時に Pub/Sub へ通知を送信し、後続処理のトリガーとして利用 これらのうち、リソース構成のスナップショット保存・変更履歴の追跡は証跡管理に該当しますが、変更通知を起点とした 設定ドリフトの検知 は発見的統制、それを受けての 自動修復 は是正的統制の観点から後述します。 参考 : Cloud Asset Inventoryを徹底解説！ - G-gen Tech Blog 予防的統制（統制の基盤を整備する） 概要 Google Cloud を組織的に利用するにあたり、最初に行うべきは 組織（Organization）の作成 です。 組織は Google Cloud 環境を統制ならびに管理するためのリソースで、後述する IAM、組織のポリシー、VPC Service Controls、Security Command Center など、ほぼすべてのセキュリティ施策の前提となります。 組織がなくても Google Cloud を利用できますが、その場合、組織的な統制やガバナンスに必要な機能の多くが利用できません。企業や官公庁で Google Cloud を利用する場合、組織の構成は必須といえます。 関連サービス・機能 組織（Organization） 組織（Organization）とは、Google Cloud リソースの階層構造における最上位のリソースです。組織は Google Workspace または Cloud Identity のドメインと 必ず 1:1 で紐づきます。 例えば my-domain.com という Google Workspace ドメインがある場合、自動的に my-domain.com という組織リソースが作成されます。このように、Google Workspace を利用している組織では、Google Workspace のドメインに紐づく形で Google Cloud 組織が自動的に作成されます。 Google Workspace を利用していない場合でも、Cloud Identity（Free エディションは 50 アカウントまで無料）を登録することで組織が作成できます。 参考 : Google Cloudの組織(Organization)を徹底解説 - G-gen Tech Blog 参考 : Cloud Identityの登録・組織作成手順 - G-gen Tech Blog 階層構造 組織作成後は、 フォルダとプロジェクト で構成されるリソースの階層構造（ツリー構造）を設計します。 リソース 役割 プロジェクト Google Cloud リソースの最も基本的な管理単位（AWS でいうアカウントに相当） フォルダ プロジェクトを部署、環境区分（本番・開発）、サービスなどの単位でグルーピングするためのリソース 階層構造はセキュリティの観点で非常に重要です。組織機能を使って複数プロジェクトを 組織下に束ねる ことにより、組織のポリシーや IAM、VPC Service Controls などの統制を、リソースツリーの親から子へ 継承 （inheritance）の性質を活かして適用できるため、現実的な工数で効果的かつ効率的な統制が実現できます。 組織を使わないリスク 組織を使用しない場合、前述の通り組織的な統制やガバナンスに必要な機能の多くが利用できません。また、個人の Gmail アカウントなどによる「野良プロジェクト」の存在を許すことになり、意図しないセキュリティ事故のリスクが高まります。 そのため、Google Cloud を利用する場合は、たとえ最初は Google Cloud プロジェクトを1つしか使わない場合でも、 将来の拡張性も見込んで最初から組織を作成しておき 、組織下でプロジェクトを管理することが望ましいと言えます。 予防的統制（ID・認証基盤を整備する） 概要 組織の次は Google アカウント（ユーザー ID）と認証 を整備します。「誰が Google Cloud を利用できるのか」「どのように本人確認を行うのか」を明確にすることは、すべてのアクセス制御の基本となります。 関連サービス・機能 Google Workspace / Cloud Identity 前述の通り、組織で Google Cloud を利用する場合、Google アカウントやグループは Google Workspace もしくは Cloud Identity で作成・管理 します。 アカウントは 1 人に 1 つ発行することを原則とし、共用アカウントの利用はパスワード漏洩や監査ログからの実行者特定の困難さにつながるため避けるべきです。 また、メンバーの異動・退職時の管理等、運用効率とセキュリティを加味し、Google グループで役割ごとにアカウントをグルーピングし、グループ単位で IAM ロールを付与することが推奨されます。 参考 : Google Cloudの利用に必要なGoogleアカウントを徹底解説！ - G-gen Tech Blog MFA / パスキー Google アカウントの認証強度を高めるため、 2 段階認証の有効化 が推奨されます。特に管理者アカウントには、フィッシング耐性の高いセキュリティキー（FIDO2）やパスキーの利用が強く推奨されます。Google Workspace や Cloud Identity の管理コンソールから、組織単位で 2 段階認証を必須化できます。 参考 : 2 段階認証プロセスを導入する Workforce Identity Federation（外部 IdP 連携） Workforce Identity Federation とは、OIDC や SAML 2.0 に対応した IdP（ID プロバイダ。Microsoft Entra ID や Okta 等）を利用するユーザーに、Google Cloud コンソールや Google Cloud リソースへのアクセスを提供する機能です。 外部 IdP 経由でシングル サインオン（SSO）を行い、Google Cloud コンソールにアクセスできるため、Google アカウントの作成は不要です。 参考 : SAMLでGoogle Cloudにシングルサインオンする方法（Workforce IdentityによるOktaからのSSO） - G-gen Tech Blog Workload Identity Federation（ワークロード間の認証） Workload Identity Federation とは、AWS や Azure 、あるいは GitHub Actions 等、外部のワークロードから Google Cloud の API を呼び出す際に、サービスアカウントキーを使わずに認証を行う仕組みです。サービスアカウントキーの発行と管理に伴うセキュリティリスクを排除できます。 参考 : キーを使用せずに AWS から Google Cloud にアクセスする方法 - G-gen Tech Blog 参考 : GitHub Actions を使って Google Cloud 環境に Terraform を実行する方法 - G-gen Tech Blog 予防的統制（コンソール・API へのアクセスを制御する） 概要 Google Cloud コンソール（Web UI）や gcloud コマンド、API へのアクセスを、接続元の IP アドレスやデバイスの状態などの条件に基づいて制限したいケースがあります。たとえば「社内ネットワークからのみ操作を許可したい」「会社承認のデバイスからのみアクセスさせたい」といった要件です。 関連サービス・機能 Chrome Enterprise Premium Chrome Enterprise Premium （以下、CEP）とは、Chrome ブラウザを前提とした Google のゼロトラスト（社内ネットワークの内側であっても無条件に信頼せず、アクセスのたびに検証する考え方）ソリューションです。 VPN を使わずに、ユーザー ID、接続元 IP アドレス、デバイス情報といった コンテキスト （背景情報）に基づき、Google Cloud をはじめ、社内システムや SaaS などへのアクセス制御を行います。 なお、CEP の主要な構成要素は以下のとおりです。 コンポーネント 概要 役割 Identity-Aware Proxy リバースプロキシ 社内システムなど接続を中継する Google Cloud 上の仕組み（フルマネージド） Identity and Access Management（IAM） 権限管理機構 Google アカウントなどのプリンシパルと権限を紐づける仕組み Access Context Manager ルールエンジン デバイス情報、アカウント情報、接続状況など各種背景情報からアクセス可否を判断する仕組み Endpoint Verification エンドポイントエージェント ユーザーのデバイス情報を収集する Google Chrome 拡張機能 参考 : Chrome Enterprise Premium（旧BeyondCorp Enterprise）を徹底解説 - G-gen Tech Blog Identity-Aware Proxy CEP の構成要素である Identity-Aware Proxy （以下、IAP）はフルマネージドのリバースプロキシサービスです。 主な利用用途としては、Google Cloud 上で稼働する Web アプリケーションへのアクセス制御や、踏み台サーバ無しでの VM マシンに対する Google アカウントを用いたログイン制御があげられます。これら IAP の基本機能については、Google Cloud ユーザーであれば無料で利用できます。 IAP が中継を許可するかどうかは、後述の IAM や Access Context Manager で定義したルールに基づきアクセス可否が判断されるため、サービスを安全に利用することができます。 参考 : 踏み台サーバはもういらない。IAP(Identity-Aware Proxy)の便利な使い方 - G-gen Tech Blog Access Context Manager 同じく CEP の構成要素である Access Context Manager （以下、ACM）は、ユーザー情報、接続元 IP アドレス、デバイス情報（OS バージョン、暗号化の有無など）、地理的な場所などのコンテキスト情報を アクセスレベル （条件）として管理するためのルールエンジンです。定義したアクセスレベルは、Chrome Enterprise Premium や VPC Service Controls と組み合わせて使用します。 参考 : Access Context ManagerでGoogle CloudコンソールとAPIへのアクセスを制限する Context-Aware Access Google Workspace にも前述同様の機能として Context-Aware Access （以下、CAA）がありますが、機能面に差はなく、呼称の違いと捉えていただいて構いません。 両者ともに共通の API（Access Context Manager API）を使用しており、ACM（Google Cloud）で作成したアクセスレベルは、CAA（Google Workspace）側にも自動的に共有されます。 Google Workspace では、Gmail、Google Drive、Gemini といった各種アプリケーションに対するアクセス条件として使用できます。 参考 : コンテキストアウェアアクセスでGoogle Workspaceのセキュリティを強化してみた - G-gen Tech Blog VPC Service Controls VPC Service Controls とは、Google Cloud 上の機密データやサービスを保護し、意図しないデータ流出やデータアクセスを防ぐための機能です。主に機密データを取り扱うプロジェクトにおいて多く実装され、情報漏洩リスクの軽減に寄与します。 具体的には、 サービス境界 という論理的な囲いを設け、信頼できるネットワークや認証情報以外からの API リクエストを制限します。 アクセス条件の部分については前述の ACM との組み合わせも可能で、ACM で定義した背景情報にもとづく API アクセス制御の実現も可能です。 参考 : VPC Service Controlsを分かりやすく解説 - G-gen Tech Blog 参考 : VPC Service Controlsのリソース構成を図解 - G-gen Tech Blog 予防的統制（最小権限の原則を徹底する） 概要 Google Cloud のリソースに対して「誰が」「何をできるか」を適切に管理することは、セキュリティの根幹です。最小権限の原則（必要最小限の権限付与）を徹底することで、内部不正や設定ミスによるリスクを低減できます。 関連サービス・機能 Identity and Access Management（IAM） Identity and Access Management （以下、IAM）とは Google Cloud リソースに対するアクセス制御を司る仕組みです。「誰（プリンシパル＝ユーザーやグループ、サービスアカウントなどの操作主体）が」「どのリソースに対して」「何をできるか（ロール・権限）」を管理します。事前定義ロール、カスタムロール、基本ロールの使い分けや、後述する拒否ポリシー（Deny policies）で強制的な権限制限も可能です。 参考 : Google CloudのIAMを徹底解説！ - G-gen Tech Blog 参考 : Google CloudのIAMで最小権限の原則を実現する方法 - G-gen Tech Blog Privileged Access Manager（PAM） Privileged Access Manager （PAM）は IAM ロールを一時的に付与するための仕組みです。IAM は恒久的な権限付与ですが、PAM は承認フローを含むジャスト・イン・タイム（JIT）アクセスを実現し、常時特権を保持することによるリスクを低減できます。 参考 : Privileged Access Manager（PAM）を解説！ - G-gen Tech Blog 拒否ポリシー（Deny policies） 拒否ポリシー とは、特定のプリンシパルが特定の権限を使用することを強制的に禁止できる IAM の機能です。拒否ポリシーは 許可ポリシーよりも優先して評価 されるため、たとえ IAM ロールを通じて権限を持っていても、拒否ポリシーで禁止されている操作は実行できません。 例えば、何らかのロールによって resourcemanager.projects.delete 権限を持ったユーザーがいたとしても、拒否ポリシーによって当該操作を実行できるのはプロジェクト管理自動化ジョブに紐づくサービスアカウントのみとし、それ以外のプリンシパルによる操作を禁止するといった制御が可能です。 参考 : Google CloudのIAMにおけるDenyポリシーを解説 - G-gen Tech Blog 予防的統制（組織横断で一貫した統制を適用する） 概要 組織に複数のプロジェクトが存在する環境では、各プロジェクトに対し、組織として一貫したルールやガードレール（逸脱を防ぐための共通の制約・歯止め）の適用が必要不可欠です。 例えば、「特定のリージョン以外でリソースを作成させない」、「Cloud Storage バケットを公開設定にさせない」、「サービスアカウントキーを作成させない」といった統制を、IAM とは別のレイヤから強制的に適用するための仕組みが 組織のポリシー です。 組織のポリシーは、組織・フォルダ・プロジェクトといったリソース階層の上位から下位へ 継承 することができるので、リソース階層の設計（前述）と組み合わせることで、現実的な工数で組織横断のガバナンスを実現できます。 関連サービス・機能 組織のポリシー（Organization Policy） 組織のポリシー （Organization Policy）とは、組織・フォルダ・プロジェクトに対してガードレールを設定し、Google Cloud リソースの利用方法に制約を課す仕組みです。 IAM が「誰が何をできるか」を制御するのに対し、組織のポリシーは 「組織として何を許容し、何を許容しないか」 を制御します。 例えば、以下のような統制が可能です。 制約名 役割 gcp.resourceLocations リソースを作成できるリージョンを限定する storage.publicAccessPrevention Cloud Storage の公開アクセスを禁止する compute.vmExternalIpAccess 外部 IP アドレスを持つ VM の作成を禁止する iam.disableServiceAccountKeyCreation サービスアカウントキーの作成を禁止する 組織のポリシーは Google Cloud があらかじめ用意した 制約 （Constraint）から選択して適用します。 組織・フォルダで設定したポリシーは下位リソースに継承されるため、組織レベルで共通的なガードレールを定義し、必要に応じてフォルダ・プロジェクトレベルで上書きするという運用が可能です。 参考 : 組織のポリシーを解説 - G-gen Tech Blog カスタム制約（Custom Constraints） カスタム制約 （Custom Constraints）とは、Google Cloud があらかじめ用意した組織ポリシーの制約だけでは要件を満たせない場合に、独自のポリシー条件を CEL （Common Expression Language）で定義し、組織のポリシーとして適用できる機能です。 例えば「VM のマシンタイプは n2-standard シリーズのみ許可する」、「Cloud Storage バケット名に特定のプレフィックスを必須にする」といった、組織固有の要件に応じた統制が実現できますが、サポートサービスが限定されている点には注意が必要です。 参考 : カスタム制約の作成と管理 タグ（Tags） タグ （Tags）は、組織またはプロジェクトレベルで定義したキーバリューペアをリソースに紐づけ、 ガバナンス・統制の条件として利用するための機能 です。 具体的には、IAM ポリシーの条件（Condition）や組織のポリシーの条件付き制約として利用でき、タグを軸とした条件付きの統制を実現できます。 似た機能として ラベル （Labels）があり、いずれもキーバリューの文字列ペアという性質は共通しますが、別の機能です。 最も重要な違いは、タグはそれ自体がリソースとして扱われるため、組織横断のリソースとして事前定義する必要があるのに対し、ラベルはリソースに付与する単なるメタデータである点です。 # 比較項目 タグ（Tags） ラベル（Labels） 1 性質 キー・バリュー・バインディングがそれぞれリソース リソースに付与するメタデータ 2 事前定義 組織またはプロジェクトでキー・バリューの事前定義が必要 事前定義不要 3 階層継承 子リソースに継承される 継承されない 4 主な用途 権限管理・統制（IAM 条件、組織のポリシー条件） リソース整理、課金分析 5 IAM 条件として利用 可能 不可 6 組織のポリシー条件として利用 可能 不可 組織ポリシーにタグを組み合わせることで、例えば、 environment=prod タグが付いたプロジェクトには、外部 IP の利用を禁止する組織のポリシーを適用するといったタグを軸とした条件付き統制を実現できます。 参考 : 組織のポリシーをタグで制御してみた - G-gen Tech Blog 参考 : タグとラベルの違い（Tags / Labels） - G-gen Tech Blog 予防的統制（ネットワークレベルで防御する） 概要 Google Cloud 上のワークロードを、外部からの不正アクセス、DDoS 攻撃、Web 攻撃、内部ネットワークからの脅威などから保護したい。あるいは、外部から VM への直接的な接続を許さず、必要な通信は制御された経路のみに限定したいといったケースが考えられます。 これらの課題に対応するため、Google Cloud では複数のネットワークセキュリティサービスが提供されています。しかし、それぞれが守る対象やレイヤが異なるため、要件に応じて組み合わせて利用することが推奨されます。 関連サービス・機能 Cloud NGFW（Next Generation Firewall） Cloud NGFW （Next Generation Firewall）とは、Google Cloud の VPC ネットワークに対するファイアウォール機能の総称です。従来の VPC ファイアウォールから発展した次世代ファイアウォール製品で、以下の3つの形態でルールを定義できます。 # 種類 適用範囲 ユースケース 1 VPC ファイアウォールルール VPC ネットワーク 従来からの VPC 単位のファイアウォール 2 ネットワークファイアウォールポリシー 特定リージョンまたは複数リージョンの VPC ネットワーク プロジェクト内の複数の VPC ネットワークに対して同じルール群を適用 3 階層型ファイアウォールポリシー 組織・フォルダ 組織横断のガードレールとして適用 例えば 階層型ファイアウォールポリシー を利用することで、組織レベルで「インターネットからの SSH 接続を一律拒否する」といった共通のガードレールを設定し、配下のすべての VPC に強制的に適用できます。 また、Cloud NGFW の機能は Essentials（無償） / Standard（有償） / Enterprise（有償） ティアのいずれかに分類され、Standard ティアでは FQDN オブジェクトや Threat Intelligence 連携が、最上位の Enterprise ティアではこれらに加えて侵入防止（IPS）や TLS インスペクションといった L7 セキュリティ機能が利用できます。 参考 : Cloud Next Generation Firewall(Cloud NGFW)を徹底解説！ - G-gen Tech Blog Cloud Armor Cloud Armor とは、Google Cloud のロードバランサーに対して DDoS 攻撃対策 と WAF （Web Application Firewall）機能を提供するサービスです。Google が提供する大規模なエッジネットワーク（Google Front End）と統合されており、アプリケーションに到達する前の段階で攻撃トラフィックをフィルタリングします。 主な機能は以下のとおりです。 # 機能 説明 1 DDoS 攻撃対策 L3/L4 の大量トラフィック攻撃（ボリューム型攻撃）に対する自動的な防御 2 WAF ルール OWASP Top 10 等の Web 攻撃（SQL インジェクション、XSS 等）に対するプリセットおよびカスタムルール 3 エッジセキュリティポリシー 地理的条件、IP アドレス、リクエストヘッダ等に基づくアクセス制御 4 Adaptive Protection 機械学習を用いた異常トラフィック検知（Enterprise エディションのみ） 5 bot 対策 reCAPTCHA Enterprise との連携によるボット判定 Cloud Armor には Standard と Enterprise の2つのエディションがあり、Enterprise では Adaptive Protection や脅威インテリジェンス連携といった高度な機能が利用できます。 参考 : Cloud Armorを徹底解説。GoogleのフルマネージドWAF - G-gen Tech Blog Cloud NAT Cloud NAT （Network Address Translation）とは、外部 IP アドレスを持たない VM や GKE Pod 等から インターネットへのアウトバウンド通信 を可能にするためのフルマネージドの NAT サービスです。 セキュリティ観点での主な意義は、 ワークロードを外部 IP なしで運用しつつ、必要な外部通信のみ実現できる 点にあります。外部 IP を持たないことで、インターネット側からの直接的な攻撃対象とならず、攻撃面（アタックサーフェス）を縮小できます。 外部 IP は、本来はインターネット側にサービスを提供するためのものですが、外部 API 呼び出しやパッケージのダウンロード等、アウトバウンド通信のためだけに外部 IP を付与しているケースは少なくありません。このような場合、Cloud NAT を利用することで外部 IP を排除し、より安全な構成にできます。 参考 : Cloud NAT の概要 Secure Web Proxy Secure Web Proxy （以下、SWP）とは、Google Cloud 上のワークロードからの アウトバウンド通信 （HTTP/HTTPS）を制御するためのフォワードプロキシサービスです。 主な機能は以下のとおりです。 接続先 URL（FQDN・パス）に基づくフィルタリング TLS インスペクション（HTTPS 通信の中身の検査） ユーザー・サービスアカウントに基づくポリシー適用 Cloud NAT がアウトバウンド通信の経路そのものを提供するのに対し、SWP はその上で「どのワークロードが、どの URL に通信できるか」を制御します。データ持ち出し対策や、信頼できる外部サービスへのみ通信を許可するゼロトラスト的な構成において有用です。 参考 : Secure Web ProxyでVMからのWebアクセスを制御してみた - G-gen Tech Blog Cloud IDS Cloud IDS （Intrusion Detection System、侵入検知システム）とは、VPC ネットワーク内のトラフィックを検査し、 ネットワーク侵入や脅威の兆候を検知 するためのマネージド型 IDS サービスです。バックエンドには Palo Alto Networks の脅威検知エンジンが採用されています。 VPC 内のトラフィックを パケットミラーリング によって IDS エンドポイントに複製し、不審な通信や既知の攻撃パターンを検知してアラートを発報します。検知のみを行い、通信の遮断は行わない点が IPS（Intrusion Prevention System、侵入防止）との違いです。 なお、前述の Cloud NGFW Enterprise エディションで IPS 機能が利用できるため、要件（検知のみ / 検知 + 遮断）に応じて使い分けることができます。 参考 : Google CloudのCloud IDSを徹底解説 - G-gen Tech Blog 参考 : Cloud NGFWのIPS機能を試してみた - G-gen Tech Blog 予防的統制（データを暗号化・保護する） 概要 Google Cloud に保存されるデータは、ユーザーが特別な設定を行わなくても、デフォルトで暗号化されています。このとき暗号鍵は Google 側で自動的に生成・管理・ローテーションされるため、ユーザーが意識する必要はありません。これを デフォルトの保存データの暗号化 と呼びます。 しかし、情報セキュリティ監査上の要件や、より強固なセキュリティが求められる場合には、ユーザー側で暗号鍵を独自に管理したい、機密データの所在を把握して保護したい、通信を暗号化する証明書を統制したい、といった要件が生じます。 本章では、こうした 暗号化・データ保護 に関連するサービスとして、暗号鍵を管理する Cloud KMS （およびその保護レベルである Cloud HSM ・ Cloud EKM ）、機密データを検出・保護する Sensitive Data Protection 、データ流出を防ぐ VPC Service Controls 、そして証明書を管理する Certificate Authority Service ・ Certificate Manager を解説します。 関連サービス・機能 Cloud KMS Cloud KMS （Cloud Key Management Service）とは、Google Cloud の暗号鍵を作成・保管・管理するための鍵管理サービスです。前述のとおり Google Cloud のデータはデフォルトで暗号化されますが、その鍵をユーザー自身で管理したい場合に Cloud KMS を利用します。 ユーザーが Cloud KMS で管理する鍵を、各種 Google Cloud サービスのストレージ暗号化に利用することを 顧客管理の暗号鍵 （Customer-Managed Encryption Keys、以下 CMEK）と呼びます。CMEK は Cloud Storage バケット、Compute Engine の永続ディスク、BigQuery のデータセットなど、多くのサービスでサポートされており、鍵の無効化・破棄をユーザーの管理下に置けるため、監査・コンプライアンス上の要件に応えやすくなります。 Cloud KMS の鍵は、鍵マテリアルの保護方法に応じて以下の 保護レベル から選択します。 # 保護レベル 説明 1 SOFTWARE ソフトウェアモジュールで鍵を保護する標準的な保護レベル 2 HSM Cloud HSM（後述）の専用ハードウェアで鍵を保護する 3 EXTERNAL / EXTERNAL_VPC Google Cloud 外部の鍵管理システム（Cloud EKM 経由、後述）で管理される鍵を利用する なお、Cloud KMS にはユーザー側で生成した既存の鍵をインポートする機能（BYOK : Bring Your Own Key）や、CMEK の鍵を自動でプロビジョニング・割り当てする Autokey といった機能もあり、鍵運用の負荷を軽減できます。 参考 : Cloud KMSを徹底解説 - G-gen Tech Blog Cloud HSM / Cloud EKM Cloud HSM と Cloud EKM は、いずれも独立した別サービスというよりも、前述の Cloud KMS の 保護レベル として選択できる鍵管理の選択肢です。どちらも Cloud KMS の API を通じて利用するため、操作方法やアクセス制御（IAM）は通常の Cloud KMS 鍵と共通です。 Cloud HSM は、FIPS 140-2 レベル3認定のハードウェアセキュリティモジュール（HSM）によって鍵を保護するフルマネージドの仕組みです。一方の Cloud EKM （Cloud External Key Manager）は、Google Cloud の外部に存在する鍵管理システムに格納された鍵を、Cloud KMS 経由で利用するための仕組みで、鍵をクラウド外部で保持・管理したい（HYOK : Hold Your Own Key）という要件に対応します。 # 機能 概要 主なユースケース 1 Cloud HSM FIPS 140-2 レベル3認定の HSM で鍵を生成・保護する ハードウェアで保護された鍵が求められる規制・監査要件 2 Cloud EKM Google Cloud 外部の鍵管理システムの鍵を Cloud KMS 経由で利用する 鍵をクラウド事業者の管理外に置きたい要件 要件に応じて、標準的な SOFTWARE 保護レベルで十分なのか、ハードウェア保護（Cloud HSM）が必要なのか、あるいは鍵そのものを外部に置く必要があるのか（Cloud EKM）を見極めて選択します。 参考 : Cloud HSM | Cloud Key Management Service Sensitive Data Protection Sensitive Data Protection （旧称 Cloud Data Loss Prevention、Cloud DLP）とは、個人識別情報（PII）等の機密データを 検出・分類・保護 するためのフルマネージドサービスです。 主な機能は以下のとおりです。Cloud Storage や BigQuery 等に保存されたデータをスキャンする使い方のほか、API 経由でテキストを送信して検査する使い方もあります。 # 機能 説明 1 検出（Discovery） 組織・フォルダ・プロジェクトを横断してデータをプロファイリングし、機密データの所在とリスクを可視化する 2 検査（Inspection） Cloud Storage、BigQuery、Datastore 等のデータや、API 経由のテキストに含まれる機密データを検出する 3 匿名化（De-identification） マスキングや仮名化（pseudonymization）等により、機密データを別の文字列に置き換えて保護する 4 リスク分析 k-匿名性などの指標を用いて、データの再識別リスクを測定する 代表的なユースケースとして、データ処理パイプラインの中で Sensitive Data Protection を用いて PII を検知・除去してからデータを保存する、といった構成が挙げられます。なお、生成 AI の入出力テキストに含まれる機密データの検査については、現在では Model Armor に統合されています。 参考 : Sensitive Data Protection の概要 VPC Service Controls（再掲） VPC Service Controls は、 サービス境界 という論理的な囲いを設け、信頼できるネットワークや認証情報以外からの API リクエストを制限することで、機密データの意図しない流出（データ持ち出し）を防ぐ機能です。当記事では「予防的統制（コンソール・API へのアクセスを制御する）」の章で詳しく解説しています。 データ保護の観点では、暗号化（Cloud KMS）や機密データの検出（Sensitive Data Protection）が「データそのものを守る」のに対し、VPC Service Controls は「データを取り扱う API アクセスの境界を守る」役割を担うものとして、組み合わせて活用することが推奨されます。 Certificate Authority Service Certificate Authority Service （以下、CA Service）とは、プライベート認証局（CA）の構築・運用・管理を簡素化・自動化するためのフルマネージドサービスです。組織内のシステムやワークロードに対して証明書を発行する仕組みを、CA サーバーやハードウェアを自前で運用することなく利用できます。 CA Service では、自己署名証明書を持つ ルート CA と、別の CA によって署名される 下位 CA （subordinate CA）の両方を作成でき、複数の CA を CA プール にまとめることでスケーラビリティを高められます。主なユースケースとしては、サービス間通信（mTLS）で利用するワークロード証明書の発行、内部向けロードバランサで使うプライベート証明書の発行、IoT デバイスの認証などが挙げられます。 手動での証明書の作成・更新作業を排除し、厳格なアクセス制御のもとで証明書のライフサイクルを管理できる点が、セキュリティ上の主な意義です。 参考 : Certificate Authority Service の概要 Certificate Manager Certificate Manager とは、Cloud Load Balancing（ロードバランサ）で利用する SSL/TLS 証明書の作成・管理・デプロイを行うサービスです。多数の証明書を扱う構成でも、証明書マップを通じて効率的に管理できます。 Certificate Manager で扱える証明書には、以下の2種類があります。Certificate Manager で管理する証明書は、合計100枚までは無料で、それを超えると枚数に応じた月額課金が発生します。また、前述の CA Service と連携することで、プライベートな Google マネージド証明書を発行することも可能です。 # 証明書の種類 説明 1 Google マネージド証明書 Google により発行・自動更新されるドメイン認証（DV）証明書 2 セルフマネージド証明書 ユーザーが外部で取得した証明書をアップロードして利用する CA Service が「証明書を発行する認証局そのもの」を提供するのに対し、Certificate Manager は「発行された証明書をロードバランサに紐づけて運用する」役割を担う、と整理すると分かりやすいでしょう。 参考 : GoogleマネージドSSL/TLS証明書をDNS認証で作成する方法 - G-gen Tech Blog 予防的統制（コンテナやコードの安全性を担保する） 概要 アプリケーションをコンテナとしてビルドし、GKE や Cloud Run にデプロイする運用が一般的になるなかで、 ソフトウェアサプライチェーン のセキュリティが重要な課題となっています。 具体的には、「コンテナイメージに既知の脆弱性が含まれていないか」「許可されていない、あるいは検証されていないイメージが本番環境にデプロイされていないか」「ビルドからデプロイ、実行に至る一連の経路が信頼できるものか」といった点を担保したい、という要件です。Google Cloud では、これらの課題に対応するためのサービスが提供されています。 関連サービス・機能 Artifact Registry / Artifact Analysis Artifact Registry とは、コンテナイメージや各種言語パッケージを保存・管理するためのフルマネージドのリポジトリサービスです。Cloud Run や GKE などのコンテナランタイムへイメージを提供する基盤となり、アクセス制御は IAM によってきめ細かく管理できます。 その Artifact Registry に保存されたアーティファクトの安全性を担保するのが Artifact Analysis （旧称 Container Analysis）です。Artifact Analysis は、ソフトウェア構成分析（脆弱性スキャン）とメタデータの保存・取得を提供するサービスで、イメージを既知の脆弱性情報と照合します。 スキャンには以下の2種類があり、特に自動スキャンは新たな脆弱性が発見されるたびに情報が継続的に更新されるため、過去に push されたイメージについても最新の脆弱性状況を把握できます。 # スキャン種別 説明 1 自動スキャン イメージを Artifact Registry に push した時点で自動的にスキャンが実行される。脆弱性情報は継続的に更新される 2 オンデマンドスキャン gcloud コマンドにより手動でスキャンを実行する。ローカルやレジストリ上のイメージを対象にできる Artifact Analysis による脆弱性検出結果は、後述の Security Command Center に集約され、プロジェクト横断で他のセキュリティリスクと併せて確認できます。また、次に述べる Binary Authorization と連携し、脆弱性のあるイメージのデプロイを抑止する用途にも利用されます。 参考 : Artifact Analysis の概要 Binary Authorization Binary Authorization とは、GKE、Cloud Run、Google Distributed Cloud（GDC）などへのコンテナイメージのデプロイ時に、信頼できるイメージのみがデプロイされることを保証する デプロイ時のセキュリティ統制 の仕組みです。 Binary Authorization では、組織のデプロイ要件を ポリシー として定義します。イメージが CI/CD パイプラインの各段階を通過する際に、その通過を示す署名（ 証明 / attestation ）が生成され、デプロイ時にはアドミッションコントローラ（リソース作成要求を受け付ける前に検査・制御する Kubernetes の仕組み）がポリシーを評価して、要件を満たさないイメージのデプロイをブロックします。証明を発行する主体は アテスター（attestor） と呼ばれます。 前述の Artifact Analysis と組み合わせることで、「一定以上の深刻度の脆弱性が検出されたイメージはデプロイを許可しない」といった、脆弱性スキャン結果に基づく統制も実現できます。なお、障害対応など緊急時には、ポリシーを一時的に迂回する breakglass（ブレークグラス）の仕組みも用意されています。 参考 : Binary Authorization の概要 GKE セキュリティ機能 GKE（Google Kubernetes Engine）には、コンテナワークロードを安全に運用するためのセキュリティ機能が数多く実装されています。とりわけ Autopilot モード では、Google のベストプラクティスに基づいたハードニング済みの構成がデフォルトで適用され、ノードの管理（スケーリング・修復・セキュリティパッチ適用）も Google に委任できます。 代表的なセキュリティ機能は以下のとおりです。 # 機能 説明 1 Autopilot モード ハードニング済みの構成をデフォルト適用し、危険な構成や設定ミスが起きやすい機能をブロックする 2 Workload Identity Pod に対し、サービスアカウントキーを使わずに Google Cloud リソースへの認証を提供する 3 Shielded GKE Nodes ノード VM のセキュアブートや整合性監視により、ノードの改ざんを検知する 4 限定公開クラスタ ノードに外部 IP を付与せず、攻撃面（アタックサーフェス）を縮小する 5 Pod セキュリティの制御 特権 Pod など危険な構成を、アドミッションコントローラによって制限する Standard モードでもこれらの機能は個別に有効化できますが、Autopilot モードを選択することで、セキュリティのベースラインを最初から確保できる点が大きなメリットです。 参考 : Google Kubernetes Engine（GKE）を徹底解説 - G-gen Tech Blog Software supply chain security Software supply chain security とは、特定の単一サービスを指す名称ではなく、ソフトウェアサプライチェーン全体をエンドツーエンドで保護するための製品群の総称です。 開発環境からビルド、アーティファクトの保管、デプロイ、実行に至る各段階を保護するために、Cloud Workstations（セキュアな開発環境）、Cloud Build（ビルド）、本章で解説した Artifact Registry / Artifact Analysis、Binary Authorization、Assured Open Source Software（検証済み OSS パッケージ）といったサービスが組み合わされています。すなわち、ここまでに解説してきた各サービスを、サプライチェーンセキュリティという観点で束ねた包括的なフレームワークと捉えるとよいでしょう。 参考 : ソフトウェア サプライ チェーンのセキュリティ 発見的統制 概要 予防的統制をどれだけ整備しても、すべての設定ミスや新たな攻撃手法を完全に防ぐことは困難です。 発見的統制 は、発生した（あるいは発生しつつある）セキュリティ事象や設定ミスを速やかに検知し、可視化するための仕組みであり、予防的統制を補完する重要な役割を担います。 Google Cloud では、構成ミス・脆弱性・脅威の検出を統合的に行う Security Command Center を中核に、過剰権限の検出を支援する IAM Recommender （Active Assist）、運用監視を担う Cloud Monitoring 、より広範なログ分析と脅威検知を行う Google SecOps 、そして脅威インテリジェンス・インシデント対応サービスを提供する Mandiant が用意されています。 関連サービス・機能 Security Command Center Security Command Center （以下、SCC）とは、Google Cloud 環境の 構成ミス・脆弱性・脅威・コンプライアンス違反 を一元的に検出・可視化する統合セキュリティプラットフォームです。各検出機構が出力した結果は 検出結果（Findings） として集約され、SCC のダッシュボード上で横断的に確認できます。 SCC が提供する主な検出カテゴリは以下のとおりです。 # 検出カテゴリ 説明 1 構成ミスの検出 IAM・ネットワーク・ストレージ等の設定ミスを継続的に検出する（Security Health Analytics） 2 脆弱性の検出 Web アプリケーションの脆弱性（Web Security Scanner）、Artifact Registry のコンテナイメージ脆弱性等を検出する 3 脅威の検出 Cloud Audit Logs 等のログから攻撃の兆候を検出する（Event Threat Detection、Container Threat Detection 等） 4 コンプライアンス CIS Benchmarks、PCI DSS 等の業界標準に対する準拠状況を可視化する SCC は2026年6月現在 Standard ・ Premium ・ Enterprise の3つのサービスティアで提供されていますが、Enterprise ティアは2027年5月21日に EOL の予定です。 # ティア 概要 1 Standard 基本的な構成ミスの検出と、コンプライアンス順守状況の管理。Google Cloud を対象とする 2 Premium Standard に加え、攻撃パス分析、脅威検出、コンプライアンスモニタリング、DSPM（Data Security Posture Management。機密データの所在やリスクを可視化・管理する仕組み）等の高度機能を提供 3 Enterprise マルチクラウド対応の CNAPP（Cloud-Native Application Protection Platform、クラウドネイティブなアプリを開発から実行まで包括的に保護する統合プラットフォーム）として AWS と Azure に対応。Mandiant の脅威インテリジェンスや Google SecOps との統合を含む包括的なソリューション SCC の検出結果は Pub/Sub 経由で外部システムへ通知したり、後述の Google SecOps と統合して SIEM 側でより高度な分析・自動対応につなげたりすることも可能で、運用ワークフローの起点として利用できます。 参考 : Security Command Centerを徹底解説。Google Cloud(GCP)の脆弱性を自動検知 - G-gen Tech Blog IAM Recommender（Active Assist） IAM Recommender とは、IAM ポリシーの利用状況を機械学習で分析し、 実際には使われていない過剰な権限を特定して推奨事項を提示する 機能です。最小権限の原則を「すでに付与済みの権限を整理する」観点で支援するもので、Google Cloud の推奨機能群である Active Assist の一部として提供されます。 IAM Recommender は、過去の権限利用履歴を分析し、付与されているロールに対して実際に必要だった権限を割り出した上で、より粒度の細かいロールへの差し替えや、未使用権限の削除といった推奨を生成します。推奨事項はコンソール上で確認し、レビューの上で適用する運用が基本となります。 IAM Recommender 自体は無料で利用できますが、生成される推奨事項の範囲は SCC のティアに依存する点に注意が必要です。 # 対象ロール・スコープ 必要な SCC ティア 1 基本ロール（オーナー、編集者、閲覧者） Standard 2 ・基本ロール以外 ・組織、フォルダ、プロジェクト以外のリソースに付与されたロール Premium 以上 Active Assist には IAM Recommender 以外にも、放置プロジェクトの検出、未使用リソースの検出など、コスト・パフォーマンス・セキュリティに関する各種の Recommender が含まれており、組み合わせることで運用全体の最適化にも貢献します。 参考 : Google CloudのIAMで最小権限の原則を実現する方法 - G-gen Tech Blog Cloud Monitoring Cloud Monitoring は、Google Cloud リソースの指標（メトリクス）を収集・可視化し、しきい値超過時に通知を発報する統合監視サービスです。本来はパフォーマンス監視や可用性監視を主目的としますが、セキュリティ運用においても重要な役割を果たします。 特に、前述の Cloud Logging に集約された Cloud Audit Logs 等のログに対するログベースのアラート と組み合わせることで、「特定の高権限操作が実行された」「想定外のリージョンでリソースが作成された」といった事象を即時に検知し、運用チームへ通知できます。 # 機能 セキュリティ運用での主な用途 1 アラートポリシー 監査ログのパターンや異常なメトリクスに基づくインシデント通知 2 通知チャネル メール、Slack、PagerDuty、Pub/Sub 等への通知発報 3 稼働時間チェック 外形監視によるサービスの可用性監視 4 ダッシュボード セキュリティ関連メトリクスの可視化 SCC が「Google Cloud 全体のセキュリティ状態（ポスチャ）」を扱うのに対し、Cloud Monitoring は「自社で構築したワークロード固有のメトリクスやログ」をきめ細かく監視する役割を担い、両者は補完関係にあると整理できます。 参考 : Cloud Monitoringを徹底解説！ - G-gen Tech Blog Google SecOps（SIEM / SOAR） Google SecOps （Google Security Operations、旧称 Chronicle）は、 SIEM （Security Information and Event Management）、 SOAR （Security Orchestration, Automation and Response）、脅威インテリジェンス、Gemini を統合した、Google Cloud のセキュリティ運用プラットフォームです。 従来、ログの収集・検索、検知ルール管理、インシデントの調査と対応はそれぞれ別々の製品で行う必要があり、運用面での課題となっていました。Google SecOps はこれらを単一のクラウドネイティブな基盤上で統合し、ログ分析から脅威検知、調査、自動対応までを一気通貫で実現します。Google Cloud のログだけでなく、AWS や Azure、各種オンプレミス機器や SaaS のログも取り込むこともできます。 発見的統制の文脈では、特に SIEM の側面が重要です。Google SecOps は取り込んだログを UDM （Unified Data Model）という共通スキーマに正規化した上で、検知ルールと突き合わせて脅威を検出します。後述する Mandiant および VirusTotal の脅威インテリジェンスが標準で組み込まれており、IoC（Indicator of Compromise、侵害の痕跡）との照合による検知が可能です。なお、検知された事象に対する自動対応（SOAR）の側面については、是正的統制の章で改めて解説します。 参考 : Google SecOps(Google Security Operations)を徹底解説！ - G-gen Tech Blog Mandiant Mandiant は、2022年に Google が買収したサイバーセキュリティ企業で、脅威インテリジェンス、インシデント対応、攻撃面管理といった分野で世界的に知られています。買収後も Mandiant ブランドは維持され、現在は Google Cloud のセキュリティポートフォリオの一部として位置づけられています。 Mandiant が提供する主なサービスは以下のとおりです。 # サービス 概要 1 Mandiant Threat Intelligence 攻撃者の戦術・技術・手順（TTP）に関する脅威インテリジェンスを提供する 2 Mandiant Attack Surface Management（ASM） 組織のインターネット側からの露出範囲（攻撃面）を発見・継続監視する 3 Mandiant Managed Defense 24時間365日のマネージド検知・対応（MDR）サービス 4 Mandiant Incident Response インシデント発生時の調査・対応支援サービス Google Cloud との統合という観点では、前述の SCC Enterprise および Google SecOps に Mandiant の脅威インテリジェンスが標準で組み込まれており、最前線の知見に基づく検知・分析機能が利用できます。 参考 : Security Command Center Enterprise 発表: AI を活用した SecOps とクラウド セキュリティを融合した初のマルチクラウド リスク管理ソリューション 是正的統制 概要 発見的統制によってセキュリティ事象や設定ミスを検知できても、その是正を人手のみに頼っていては対応が追いつかず、ミスや遅延も生じます。 是正的統制 は、検知された不適切な状態を、人手を介さず（あるいは最小限の人手で）自動的に修復し、あるべき状態を維持するための仕組みです。 代表的な適用例としては、本来あるべき構成から逸脱した状態（ 設定ドリフト ）を自動的に元へ戻す、検知した脅威に対して定型の対応手順を自動実行する、といったものが挙げられます。Google Cloud では、宣言的なリソース管理で構成を維持する Config Controller 、イベントを起点に修復処理を実行する Eventarc + Cloud Run functions / Workflows 、そして脅威対応を自動化する Google SecOps の SOAR 機能 が用意されています。 関連サービス・機能 Config Controller Config Controller とは、 Config Connector （Kubernetes を用いて Google Cloud リソースを宣言的に管理できる Kubernetes アドオン）のマネージドサービスです。リソースの「あるべき状態」を Kubernetes のマニフェストファイルとして定義し、その状態を維持します。 是正的統制の観点で重要なのが、Kubernetes の Reconciliation Loop（調整ループ） の仕組みです。マニフェストで定義した「理想の状態」と「実際の環境」との間に差分（ドリフト）が生じた場合、Config Connector が自動的に理想の状態へ戻します。たとえば、誰かが手動で設定を変更してしまっても、定義した状態へ自動修復されるため、構成の一貫性を保てます。 Config Controller の実体は GKE クラスタであり、以下のコンポーネントがプリインストールされています。これらを組み合わせることで、GitOps による構成管理とガードレールの適用を実現できます。 # コンポーネント 役割 1 Config Connector Kubernetes マニフェストで Google Cloud リソースを宣言的に管理する 2 Config Sync Git リポジトリと連携し、格納されたマニフェストを継続的に同期する（GitOps） 3 Policy Controller ポリシーに違反するリソースの作成を検出・拒否する（ガードレール） 参考 : Config Controller(Config Sync)でGoogle Cloudブループリントを利用してGitOpsなリソース管理を実現する - G-gen Tech Blog Eventarc + Cloud Run functions / Workflows Eventarc とは、サーバーレスかつ標準化されたイベント配信により、Google Cloud 上でイベントドリブンアーキテクチャを容易に構築できるフルマネージドサービスです。これを Cloud Run functions や Workflows と組み合わせることで、「特定の事象が発生したら自動的に修復処理を実行する」という是正フローを構築できます。 是正的統制の典型的な構成は、 Cloud Audit Logs や Cloud Asset Inventory のイベント （リソースの作成・更新・削除など）を Eventarc トリガーで捕捉し、後続の処理を起動するというものです。 例えば、「公開設定にされた Cloud Storage バケットを検知して自動的に非公開へ戻す」「許可されていない構成のリソースが作成されたら自動で削除・通知する」といった処理を、サーバーレスで実装できます。Eventarc で利用できる主なイベントソースとコンシューマは以下のとおりです。 # 区分 主な選択肢 1 イベントソース Cloud Audit Logs イベント（リソースの作成・更新・削除等）、Cloud Storage、Pub/Sub、サードパーティ（Datadog 等） 2 イベントコンシューマ Cloud Run、Cloud Run functions、Workflows 後続処理には、単一の修復処理であれば Cloud Run functions を、複数ステップを順序立てて実行する必要があれば Workflows を利用する、といった使い分けが可能です。なお、証跡管理の章で触れた Cloud Asset Inventory の変更通知（Pub/Sub 連携）を起点とすれば、設定ドリフトの検知から自動修復までを一連のフローとして構築できます。 参考 : Eventarc + Cloud Run で Google Cloud リソースの作成を Slack 通知する - G-gen Tech Blog Google SecOps（SOAR） 発見的統制の章で解説した Google SecOps は、SIEM による脅威検知だけでなく、検知後の対応を自動化・オーケストレーションする SOAR （Security Orchestration, Automation and Response）の機能も備えています。是正的統制の文脈では、この SOAR の側面が中心となります。 SOAR では、検知された脅威の種類に応じた対応手順を プレイブック として定義しておき、インシデント発生時に自動実行します。たとえば「不審なアクティビティを検知したら、該当アカウントの権限を制限し、関係者へ通知し、チケットを起票する」といった一連の対応を、人手を介さずに（あるいは承認を挟みつつ）実行できます。これにより、対応の標準化と初動の高速化が図れます。 経済的統制 概要 クラウドは従量課金制であるため、設定ミスや想定外のトラフィック、あるいは意図的な攻撃によって、利用料金が異常に増加するリスクを常に抱えています。特に、リソースを大量消費させて経済的な損害を与える攻撃は EDoS（Economic Denial of Sustainability） と呼ばれます。 経済的統制 は、こうした想定外のコスト増から組織を保護するための仕組みです。Google Cloud では、予算超過を通知する Cloud Billing 予算アラート 、プロジェクト単位で費用上限を自動適用する Spend Caps 、機械学習による コスト異常検知 、そしてリソース使用量そのものに上限を設ける Quotas（割り当て） を組み合わせて、多層的にコストを保護できます。 関連サービス・機能 Cloud Billing 予算アラート 予算アラート とは、Cloud Billing で予算（budget）としきい値を設定し、指定期間の請求額がしきい値を超えた際に通知を発報する機能です。予期しない請求の発生に早期に気づくための、コスト保護の基本となる仕組みです。 ここで極めて重要な注意点として、 予算アラートはあくまで「通知」であり、支出を自動的に停止するものではない という点が挙げられます。しきい値を超えても、リソースの利用や課金がその時点で止まるわけではありません。支出を実際に抑制したい場合は、Pub/Sub トピックへ連携した自動アクションや、後述の Spend Caps による上限の適用が必要になります。 通知先としては、メール（請求先アカウントのロールベースの宛先、または Cloud Monitoring の通知チャネルで指定したメールアドレス）が利用できます。さらに、プログラムによる後続処理につなげるための通知先として Pub/Sub トピックを指定できます。 参考 : 予算アラートの設定方法 - G-gen Tech Blog Spend Caps Spend Caps とは、2026年4月の Google Cloud Next '26 で発表された、プロジェクト単位で費用の上限を自動的に適用する機能です。Google Cloud の予算（budget）と連携して動作し、管理者が設定した上限に基づいてコストを制御します。2026年6月現在では非公開プレビュー（Private Preview）で、一般提供（GA）はされていない点にご留意ください。 この機能が登場した背景には、AI ワークロード特有のコスト急増リスクがあります。AI は TPU / GPU といった高価な専用ハードウェアを使用するため、制御不能になった単一のトレーニングジョブや最適化されていないモデルが、ごく短時間で予算を使い果たしてしまう可能性があります。従来の費用管理ツールは管理者へアラートを送るのみで上限を強制適用しないため、各社は課金の無効化のような影響の大きい操作を含む独自のガードレールを構築せざるを得ませんでしたが、それを Google Cloud ネイティブな仕組みで解決するのが Spend Caps となります。 対象サービスは、Google AI Studio、Gemini Enterprise Agent Platform（旧称 Vertex AI）、Cloud Run、Cloud Run functions、Google Maps Platform となっており、挙動としては、設定した上限に到達するとアラートを送信し、予算に達すると API トラフィックが一時停止 されますが、課金無効化のようにリソースそのものが削除・停止されるわけではなく、リソースは保持されたまま残ります。トラフィックを再開したい場合は、Spend Caps を停止するだけで済みます。 参考 : AI 時代に向けた次世代の FinOps コスト異常検知（Anomaly Detection） 異常検知（Anomaly Detection） とは、Google Cloud の請求先アカウントに標準で付属する、突発的な課金を検知する機能です。請求先アカウント単位で過去の使用傾向が機械学習により学習され、普段と異なるパターンの課金が発生すると「異常（anomaly）」として検知されます。 予算アラートが「あらかじめ設定したしきい値」を基準とするのに対し、異常検知は「過去の利用傾向からの逸脱」を基準とする点が特徴で、想定外の急激なコスト増を捉えるのに適しています。検知結果はコンソールで確認できるほか、メールや Pub/Sub への通知が可能で、Pub/Sub 連携により後続の自動処理につなげることもできます。なお、異常が検知される対象は6ヶ月間以上の利用実績があるプロジェクトに限られる点には留意が必要です。 参考 : Google Cloud請求先アカウントの異常検知（Anomaly Detection）を解説 - G-gen Tech Blog Quotas（割り当て） 割り当て（Quota） とは、Google Cloud の各種サービスに設定された、リソース使用量や API 呼び出し回数の上限です。本来はサービスの過負荷を防ぎ、意図しない大量のリソース作成を防止するための仕組みで、組織・プロジェクト・ユーザーなど様々な粒度で設定されています。 経済的統制の観点では、割り当てを「利用拡大に応じて緩和するもの」としてだけでなく、 あえて任意の上限値を設定することで突発的な課金を防ぐガードレール として利用できます。 代表的な例として、BigQuery の「1 日あたりのクエリ使用量（Query usage per day）」の割り当てが挙げられます。かつてこの割り当ては課金有効プロジェクトでデフォルト無制限でしたが、2025年9月1日以降、デフォルトで 1 日 200 TiB に設定されるよう変更されました。それでも上限としては大きいため、ワークロードに合わせてより低い値を明示的に設定しておくことで、想定外の高額課金をより確実に防げます。 予算アラートやコスト異常検知が「課金の発生を検知して通知・対応する」事後的なアプローチであるのに対し、割り当ては「リソース消費そのものに上限を設ける」事前的なアプローチであり、両者を組み合わせることでより堅牢なコスト保護が実現できます。 参考 : Google Cloudで割り当て（Quota）を上限緩和する方法 - G-gen Tech Blog 参考 : BigQueryのオンデマンドクエリの利用量にフタをする (上限を設ける) - G-gen Tech Blog 生成 AI 特有のセキュリティ 概要 これまで解説してきたセキュリティ統制の多くは、「人間のユーザー」と「あらかじめ定められた動作をするアプリケーション」を前提としていましたが、生成 AI の利用はこの前提に新たな脅威をもたらします。 具体的には以下の3点です。 自然言語の入力そのものが攻撃の経路になり得ること モデルが確率的に予期しない出力を返し得ること AI エージェントが自律的に判断して他システムを操作し得ること そのため、生成 AI のセキュリティでは、以下のような生成 AI 特有の脅威領域を意識する必要があります。 # 脅威領域 代表的なリスク 1 入出力（プロンプト、レスポンス） ・プロンプトインジェクション、ジェイルブレイク ・機密データの入/出力 ・有害コンテンツの生成 ・悪意のある URL の出力 2 データ ・RAG（グラウンディング。外部データを検索して回答の根拠とする手法）における過剰権限 ・入力データの学習利用 ・データの保存場所（レジデンシー） 3 AI エージェント ・自律的に動作するエージェントの過剰権限 ・エージェントのなりすまし ・外部ツール連携時の認証情報管理 本章では、前提となる基盤の選択、またこれらに対応する生成 AI 特化のサービスとして Model Armor （入出力のスクリーニング）、 Agent Identity （エージェントの認証）、 Agent Gateway 、 Agent Registry 、 AI Protection を中心としたエージェントのガバナンスを解説します。 生成 AI 基盤の選択 Google で生成 AI を利用する主な経路には、Google Cloud に統合された Gemini Enterprise Agent Platform （旧称 Vertex AI）と、Google アカウントだけで手軽に始められる Google AI Studio があり、どちらを選ぶかはそれ自体がセキュリティ・統制上の判断になります。 前者は Google Cloud に統合されているため、IAM によるアクセス制御、VPC Service Controls や Cloud Armor による保護、Cloud Audit Logs による監査、そして本章で解説する Model Armor・Agent Identity・Agent Gateway といった ガバナンス機能を組み合わせて 利用できます。管理者が利用状況を可視化し、問題のある振る舞いを検知した際にサービスアカウントの停止やアクセス権の剥奪を行う、といった統制も可能です。 一方の後者は API キーを発行してすぐにモデルを呼び出せる手軽さが魅力ですが、 組織レベルの統制やアクセス制御機能は備わっていません。 そのため、個人開発やプロトタイピングには適しているものの、企業・官公庁・研究機関などが組織として生成 AI アプリケーションを開発・運用する場合は、 統制機能の整った Gemini Enterprise Agent Platform が推奨されます。本章で扱うセキュリティ機能の多くも、この基盤を前提としています。 参考 : Google AI Studio vs Vertex AI。違いや選び方を解説 - G-gen Tech Blog 関連サービス・機能 Model Armor Model Armor とは、生成 AI・エージェントのプロンプト（入力）とレスポンス（出力）をスクリーニングし、LLM が悪意のあるコンテンツや機密性の高いコンテンツにさらされたり、それらを生成したりするのを防ぐランタイムセキュリティサービスです。 Model Armor が提供する主な検知・フィルタ機能は以下のとおりです。 # フィルタ 説明 1 プロンプトインジェクション・ジェイルブレイク検出 LLM に指示や安全フィルタを無視させようとする入力を特定・ブロックする 2 機密データの保護 Sensitive Data Protection と連携し、PII・財務情報・認証情報等の機密データを入出力の両方で検出する 3 悪意のある URL の検出 入出力に含まれる悪意のあるリンクやフィッシングリンクを検出する 4 有害コンテンツのフィルタリング 露骨な性的表現・危険・ハラスメント・ヘイトスピーチ等を検出し、責任ある AI の原則に沿わせる Model Armor の挙動は テンプレート で定義します。テンプレートには各フィルタと、検知の確信度を表す しきい値 を設定でき、アプリケーションのリスク許容度に応じて適用の強さを調整できます。利用方法としては、API へ直接スクリーニングリクエストを送る方法と、Gemini Enterprise Agent Platform（旧称 Vertex AI）に統合して使う方法があります。Model Armor の検出結果は SCC に送られ、他のセキュリティリスクと併せて確認できます。 参考 : Model Armorを徹底解説！ - G-gen Tech Blog Agent Identity Agent Identity とは、Google Cloud 上で動作する AI エージェントに、 SPIFFE （ワークロードに標準化された ID を付与するためのオープン標準）に基づく固有のアイデンティティを付与する仕組みです。これにより、エージェントは MCP サーバー、Google Cloud リソース、外部 API、他のエージェントに対して、自身の権限で安全に認証できます。 従来、エージェントの実行環境にはサービスアカウントを利用するのが一般的でしたが、共有（使いまわし）や権限借用（なりすまし）が可能であること、サービスアカウントキーの漏洩リスクなどの課題がありました。 Agent Identity はこの問題を解決するもので、サービスアカウントとは以下の点で異なります。 項目 サービスアカウント Agent Identity 複数ワークロードでの共有 可能 複数のエージェントで同じサービスアカウントを使い回すこともできてしまう 不可 エージェント単位で ID が発行される 権限借用（impersonation） 可能 別のプリンシパルにサービスアカウントの借用（なりすまし）を許可することもできてしまう 不可 エージェント自身以外は ID を使用できない 長期キーの手動生成 可能 サービスアカウントキーはデフォルトで有効期限がなく、漏洩した場合は無効化しない限り悪用され続けてしまう 不可 トークンのバインド なし アクセストークンを入手した第三者がそのまま使用できてしまう あり トークンが X.509 証明書と紐付き、意図された実行環境以外では使用できない 参考 : Google CloudのAgent Identityを解説 - G-gen Tech Blog Agent Gateway / Agent Registry 前述の Agent Identity が「エージェントが何者か（認証）」を担うのに対し、エージェントが「何にアクセスでき、どのような通信・内容が許されるか」を統制するのが Agent Gateway です。 Agent Gateway は、ユーザーとエージェント、エージェントとツール、エージェント同士といった、 エージェントが関わるすべての通信を保護・管理するネットワーク基盤 です。クライアントからの内向き通信（Client-to-Agent）と、外部サービスへの外向き通信（Agent-to-Anywhere）の双方を仲介し、通過するプロンプトとレスポンスを前述の Model Armor で検査し、危険な内容を除去（サニタイズ）できます。 また、すべての通信のログ・メトリクス（テレメトリ）を Cloud Logging や Cloud Trace へ送信できるため、セキュリティ調査や監査にも活用できます。 Agent Gateway は、通信に対して ポリシー を適用することでアクセス制御を実現します。ポリシーには以下の2種類があります。 # ポリシー 内容 1 IAM 許可ポリシー Identity-Aware Proxy を用いた静的な権限制御。「読み取り専用」「破壊的変更の許可」といった条件で、エージェントが行える操作を制限する 2 セマンティック ガバナンス ポリシー プロンプトや MCP ツール呼び出しの「内容」を実行時に分析し、エージェントの振る舞いがユーザーの意図と組織の制約の両方に適合するよう制御する 特に セマンティック ガバナンス ポリシー は、入力や呼び出しの「内容」そのものを評価して制御する点で、生成 AI 特有の統制といえます。 これらの前提として、エージェント・MCP サーバー・エンドポイントを一元的に登録・管理する統合カタログである Agent Registry があります。 Agent Gateway を利用するにはエージェントを Agent Registry に登録しておく必要があり、Agent Registry によって エージェントやツールが組織内に散在し、どこに何があるか・誰が呼び出せるかを把握できなくなる 、といった管理課題を解消します。 なお、2026年6月現在 Agent Registry がプレビュー、Agent Gateway は非公開プレビューです。 参考 : Gemini Enterprise Agent Platformを徹底解説！ - G-gen Tech Blog 参考 : Agent Gateway の概要 AI Protection（Security Command Center） ここまで解説した Model Armor やエージェントのガバナンス機能による検出結果は、発見的統制の章で解説した SCC の AI Protection という機能群に集約され、他のクラウドリスクと同じダッシュボード上で一元的に確認できます。 AI Protection は、組織内の AI 資産（モデル・データセット・アプリケーション、Agent Registry に登録された MCP サーバー等）を自動的に検出・棚卸しし、それらに対するリスクや脅威を管理するための機能です。前述の Model Armor を中核コンポーネントとして取り込みつつ、AI 特有のリスクを可視化します。SCC の Premium または Enterprise ティアで、組織レベルの有効化により利用できます。 個々のサービス（Model Armor 等）が「入口で守る」役割を担うのに対し、AI Protection は「組織全体の AI セキュリティ状態（ポスチャ）を俯瞰する」役割を担うものと整理できます。 参考 : AI Protection overview Google Workspace Google Workspace の生成 AI 機能（Gemini アプリ・NotebookLM 等）のセキュリティについては、以下の記事を参照してください。 blog.g-gen.co.jp 武井 祐介 (記事一覧) クラウドソリューション部クラウドエンジニアリング課。 Google Cloud Partner Top Engineer 2026 選出。 Follow @ggenyutakei

株式会社 G-gen の菊池です。Looker では LookML （Looker Modeling Language）を用いてデータモデルを定義しますが、これらのコードはすべて Git リポジトリで管理されます。当記事では、Git 連携の仕組みや品質管理設定について解説します。 Looker におけるバージョン管理の概要 LookML プロジェクトと Git リポジトリの連携 開発モードと本番環境の分離 IDE 内での Git 操作 Git リポジトリとの接続方法 概要 HTTPS を使用した接続 SSH を使用した接続 ベア Git リポジトリ デフォルトのワークフロー 概要 開発ブランチへの変更のコミット 開発ブランチを本番環境ブランチにマージする Looker 本番環境への本番環境ブランチのデプロイ 品質と安全性を高める設定 概要 LookML バリデーションの必須化 データテストの必須化 プルリクエスト（PR）の統合 高度なデプロイモード Looker におけるバージョン管理の概要 LookML プロジェクトと Git リポジトリの連携 Looker の LookML プロジェクトは、 Git リポジトリと 1 対 1 に紐づけることでバージョン管理を構成します。バージョン管理構成にすることで、複数人での共同開発や変更履歴の追跡、安全な本番環境へのデプロイができます。 リモートリポジトリが準備できていない場合や素早く開発を始めたい場合は、Looker サーバー上にローカルの Git リポジトリを作成して単独でバージョン管理を開始することも可能です。 参考 : Git 接続の設定とテスト 開発モードと本番環境の分離 Looker には Development Mode （開発モード）と Production Mode （本番環境モード）という 2 つの環境が分離して存在します。 Development Mode は開発者が LookML を安全に編集、テストできる個人のサンドボックス環境であり、各ユーザーには他のデベロッパーに影響を与えない独自の開発ブランチ（dev- で始まりデベロッパー名を含むブランチ）が割り当てられます。 対して Production Mode はすべての一般ユーザーがアクセスする共有環境であり、ユーザーはこの環境でデータモデルを探索しダッシュボードを構築します。デフォルトの構成では、本番ブランチ（通常は master または main）の最新コードが本番環境で実行されますが、高度な設定を用いることで、特定のリリースバージョン（コミットやタグ）のコードを実行するよう厳密に管理することも可能です。 開発モードの場合、画面上部に「現在は Development Mode です。」というテキストが表示されたバナーが配置されます。右上にある「Exit Development Mode（Development Mode を終了）」という部分をクリックすると、本番環境モードへ切り替わり、このバナーは消えます。 開発モードから本番環境モードへの切替 本番環境モードから開発モードへ切り替える場合は、画面左上にあるメインメニューをクリックして開き、メニューの下部にある「Development Mode」をオンにします。開発モードと本番環境モードのオン・オフは、キーボードショートカット Mac : Control + Shift + D / Windows : Ctrl + Shift + D でもすばやく切り替えることが可能です。 本番環境モードから開発モードへの切替 LookML を変更する場合は、開発モードで作業する必要があります。LookML のコードを修正すると、「Save Changes」というボタンが表示されます。 LookMLの修正（例：列名の修正） このボタンをクリックすると変更内容が保存され、作業している個人の開発環境に変更が反映されます。 開発モードのダッシュボード 一方で、すべてのユーザーが共有する本番環境モードには、まだこの変更内容は反映されません。 本番環境モードのダッシュボード 個人の開発環境での変更を本番環境モードのユーザーにも見えるようにするためには、保存した変更を Git に「コミット」し、本番ブランチへ「デプロイ」するバージョン管理のステップを踏む必要があります。 参考 : Development Mode and Production Mode（開発モードと本稼働モード） IDE 内での Git 操作 Looker の統合開発環境（IDE）には、Git コマンドを操作するための GUI ボタン（IDE 右上、またはメインナビゲーションメニューの「Git Actions」パネル）が備わっています。開発者は複雑な Git コマンドを直接入力することなく、ボタン操作のみでコミットやリモートからのプル、本番環境へのデプロイといった一連のワークフローを実行できます。 特に便利なのは、この Git ボタンが現在の開発ステータス（ファイルの変更有無や他の開発者による更新状況など）に応じて、次に必要なアクションのみを動的に表示する点です。これにより、開発者は手順に迷うことなく、安全かつスムーズにバージョン管理を行うことができます。 参考 : Using version control and deploying（バージョン管理機能の使用とデプロイ） 参考 : Git コマンドのリファレンス Git リポジトリとの接続方法 概要 新規にプロジェクトを作成する際、まず Git リポジトリの構成設定を行います。 Git リポジトリは、外部の Git プロバイダと連携する「HTTPS を使用した接続」、「SSH を使用した接続」、または外部連携を行わずに Looker サーバー上にローカルリポジトリを作成する「ベア Git リポジトリ」の 3 つの構成オプションのいずれかを選択できます。 HTTPS を使用した接続 HTTPS 接続では、ユーザー名と 個人用アクセストークン（Personal Access Token） を使用して認証を行います。 運用方法として、プロジェクト全体で 1 つの Git アカウントを共有する設定と、Looker の「ユーザー属性」機能を用いてデベロッパーごとに個別の Git アカウントを使用する設定が選択可能です。 なお、単一の Git アカウントを共有する場合でも、Looker は各デベロッパーの Looker ユーザー名を使用してコミットを行うため、誰が変更を加えたかの履歴は正しく追跡されます。 ただし、注意点として Looker は現在、GitHub の きめ細かい個人用アクセス トークン（Fine-grained personal access tokens） をサポートしていません。そのため、GitHub を利用する場合は、必ず 「Tokens (classic)」 のオプションを使用してトークンを作成してください。 参考 : HTTPS を使用した Git への接続 参考 : GitHub - Managing your personal access tokens SSH を使用した接続 SSH 接続では、 Looker が生成する公開鍵を Git プロバイダー側に登録することで認証を行います。手順としては、 Looker 側で SSH 公開鍵を生成してコピーし、 Git プロバイダーのリポジトリ設定画面で「Deploy Key」として登録します。この際、 Looker からリポジトリへ変更をプッシュできるよう、書き込みアクセスを許可（Allow write access）を有効にする必要があります。 参考 : SSH を使用した Git への接続 ベア Git リポジトリ リモートの Git プロバイダーを準備していない場合や、すぐに開発を開始したい場合、 Looker サーバー上にローカルリポジトリを作成する ベア Git リポジトリ 構成も選択できます。 ただし、ベア Git リポジトリではプルリクエストの作成など一部の機能が使用できないため、あくまで一時的な利用にとどめることが推奨されます。最初はベアリポジトリで開始し、後からリモートの Git プロバイダーへ接続し直すことも可能ですが、その場合は「まだ Git 履歴を持たない空のリポジトリ」に接続する必要がある点に注意してください。 参考 : ベア Git リポジトリの構成 デフォルトのワークフロー 概要 Looker の標準的なデプロイフローは、開発モード（個人の開発ブランチ）での作業から、共通のリモートリポジトリを経由して、本番環境へと反映される一連のステップで進行します。 開発ブランチへの変更のコミット 開発モードで LookML の修正が完了したら、LookML の検証（Validate LookML）ボタンをクリックします。 LookML にエラーが見つからなければ、ボタンは「Commit Changes & Push」に変わります。 エラーがあった場合は、LookML の検証欄にエラー内容が表示されます。 LookMLの検証 「Commit Changes & Push」ボタンをクリックすることで、コミットのメッセージを入力する画面が表示されます。 コミットの内容をメッセージ欄に入力して、「Commit」ボタンをクリックすることで、変更を開発ブランチに保存（コミット）します。 この操作により、作業内容に名前を付けて保存し、後から履歴を追えるようになります。 メッセージを入力してコミット プロジェクトの設定によっては、変更をコミットする前に LookML Validator によるエラー修正や、データテストへの合格が必須となる場合があります。 開発ブランチを本番環境ブランチにマージする コミットされた変更は、共有のリモートリポジトリへプッシュされます。デフォルト設定の Looker では、IDE 上の「本番環境にデプロイ（Deploy to Production）」ボタンをクリックすることで、開発ブランチの内容が本番ブランチ（通常は master または main ）へマージされます。 本番環境にデプロイ Looker 本番環境への本番環境ブランチのデプロイ IDE での「本番環境にデプロイ」操作を行うと、マージに続いて Looker の本番環境（Production Mode）が自動的に本番ブランチの最新コミットを参照するように更新されます。これにより、エンドユーザーが参照するダッシュボードや Explore に最新の定義が即座に反映されます。 本番モード環境のダッシュボード 品質と安全性を高める設定 概要 「プロジェクト構成（Project Configuration）」ページの設定を変更することで、より厳格なリリース管理を実現できます。これらは、複数人での大規模開発においてコードの品質と環境の安定性を維持するために重要です。 参考 : Configuring project version control settings（プロジェクトのバージョン管理の設定） LookML バリデーションの必須化 LookML Validator によるエラーチェックを、変更をローカルブランチに コミットする前の必須条件 として設定できます。設定により「エラーと警告の両方を修正」または「エラーのみを修正」を必須にすることが可能です。これにより、構文エラーを含んだ不正なコードがプロジェクトの履歴に混入することを未然に防ぐことができます。 データテストの必須化 LookML 内に test パラメータを定義してモデルのロジックを検証するデータテストを作成している場合、本番環境へデプロイする前にこれらのテストに合格することを必須条件に設定できます。なお、新しく作成された LookML プロジェクトでは、このオプションがデフォルトで有効になっています。 プルリクエスト（PR）の統合 Pull Request Required 設定を有効にすると、デベロッパーは Looker IDE 内で直接本番ブランチへマージすることができなくなります。変更を本番環境に反映させるためには、必ず GitHub 等の外部サービス上でプルリクエストを作成し、第三者によるコードレビューを経てマージする必要があります。これにより、開発ガバナンスを大幅に高めることができます。 Looker は「マージコミット」方式のみをサポートしているため、この機能を利用する場合は、Git プロバイダ側で「スカッシュマージ」や「リベースマージ」のオプションを使用不可にしておくことが推奨されます。 参考 : プロジェクトの pull リクエストを統合する 高度なデプロイモード Advanced Deploy Mode（高度なデプロイモード） を有効にすると、常に本番ブランチの最新状態を自動デプロイするデフォルトの動作が解除されます。代わりに、デプロイ権限を持つ担当者が特定のコミット SHA や Git タグ（リリースバージョンなど）を明示的に指定して本番環境へ反映させることが可能です。 この機能により、Git 上でのマージと Looker へのリリース反映タイミングを完全に切り離し、Webhook や API を利用した複雑なリリースパイプラインを構築できます。ただし、このモードを有効にした場合、本番環境への「最初の1回目」のデプロイは、必ず Looker IDE 内の Deployment Manager から手動で実行する必要がある点に注意してください。 参考 : 高度なデプロイモード 菊池 健太 (記事一覧) 事業開発部クラウドサポート課。2024年7月より、G-genに入社。群馬出身のエンジニア。前職でLookerの使用経験はあるが、Google Cloudは未経験なので現在勉強中。

G-gen のバロキです。当記事では、Anthropic の Claude Code と Google Cloud の データサイエンスエージェント という 2 つの AI ツールに、同一のデータセットと指示を与えて比較しました。自動生成されるデータ分析ノートブックに、どのような違いが生まれるかを検証しました。 概要 はじめに データサイエンスエージェントとは Claude Code とは 検証の前提条件 使用したデータセット 投入したプロンプト 評価の観点 生成されたノートブックの全体像 データサイエンスエージェントの特徴 Claude Code の特徴 観点別の比較 コードの量と構造 可視化のスタイル 説明可能性 データクレンジングへの姿勢 コードの再利用性 設計思想の対比 ユースケース別の使い分け データサイエンスエージェントが向いているケース Claude Code が向いているケース 概要 はじめに 「データを渡すと、AI が分析ノートブックを生成してくれる」という体験が、一般的になりつつあります。Google Cloud のデータサイエンスエージェントや、Claude Code をはじめとする大規模言語モデル（Large Language Model、以下、LLM）ベースのエージェントツールは、いずれもデータ分析の自動化を可能にします。 しかし実際に検証してみると、同じデータセットと同じ指示を与えても、ツールによって出力されるノートブックに違いがあるケースがあります。当記事では、両者の成果物を並べて比較し、その差がどこから生まれるのかを読み解きます。 結論を先に述べると、2 つのツールに優劣はなく、想定されている用途やユーザー層が異なります。なお、当記事の内容は、検証を行った2026年5月現在の仕様に基づいています。 データサイエンスエージェントとは データサイエンスエージェント は、Google Cloud の Colab Enterprise に組み込まれた、 Gemini をベースとするデータ分析エージェントです。タスクをサブタスクに分解し、ステップごとに思考プロセスを示しながら処理を進める点が特徴です。BigQuery テーブルや CSV ファイルを入力に、自然言語の指示から動作する Colab ノートブックを生成します。 参考 : データ サイエンス エージェントを使用する - Colab Enterprise 以下の記事も参照してください。 blog.g-gen.co.jp Claude Code とは Claude Code は、Anthropic が提供する、ターミナル上で動作するエージェント型のコーディングツールです。プロンプトを受け取ると、ノートブック全体の構成をあらかじめ設計し、一括で書き下ろすスタイルが特徴です。 参考 : Claude Code overview 検証の前提条件 使用したデータセット 検証には、Kaggle で公開されている「Japanese Universities」データセットを使用しました。1872 年以降の日本の大学情報を網羅したオープンデータです。 参考 : Japanese Universities - Kaggle データセットの主な仕様は以下のとおりです。 項目 仕様 公開者 webdevbadger 内容 1872 年以降の日本の大学情報（所在地、創立年、評判、難易度など） ライセンス Open Data Commons Public Domain Dedication and License（ODC-PDDL） 行数 / 列数 813 校 / 22 列 対象範囲 47 都道府県すべてを網羅 創立年範囲 1872 年 11 月（明治期）〜 2022 年 4 月（近年） 設置主体内訳 Private 626 校 / Public 101 校 / National 86 校 主なカラム code 、 name 、 name_jp 、 type （National / Public / Private）、 address 、 state_jp 、 latitude 、 longitude 、 found （YYYY-MM）、 faculty_count 、 department_count 、 review_rating 、 review_count 、 difficulty_SD 、 difficulty_rank （A〜F） 当データセットは、設置主体や地域の分布に明確な構造を持ち、創立年の時間軸も広いため、探索的データ分析（exploratory data analysis、以下 EDA）の検証素材として適しています。EDA とは、本格的なモデリングに入る前に、データの分布や欠損、変数間の関係を可視化しながら把握する作業です。AI に EDA を依頼し、その出力の質を比較する用途にも向いています。 投入したプロンプト 両者には、以下の 4 つの観点を網羅する EDA を依頼する同一の本文を、いずれも日本語のプロンプトで与えました。 データ品質 : 欠損、重複、異常値、基本特性、数値変数間の関係 地理的分析 : 大学の空間分布と都道府県・地域別の設置主体構成 機関特性 : National / Public / Private を規模と評判の両面から比較 時系列分析 : 創立の経年トレンドと設立時期別の設置主体構成 加えて、最終成果物に「分析から得られた重要な気づきを 5 つ」を含めること、および日本語テキストが正しく表示されることを条件としました。 なお、公平性のため分析を依頼する本文は両者で同一にしていますが、成果物の保存先の指示だけは実行環境に合わせて変えています。Claude Code はローカルのターミナルで動作するため、「成果物を output/ フォルダに保存する」よう明示的に指示しました。一方、データサイエンスエージェントは Colab Enterprise 上でノートブック自体が保存されるため、この指示は与えていません。 データサイエンスエージェントに入力したプロンプト（分析本文は Claude Code と同一） Claude Code のターミナルに入力したプロンプト 評価の観点 生成されたノートブックの品質を、以下の軸で観察しました。 実行性（エラーなく走るか） カバレッジ（プロンプトの要求項目を満たしているか） コード品質（慣用的か、再利用可能か） 可視化の量と質 説明可能性（各ステップの意図が読み取れるか） 構造の見通しの良さ 生成されたノートブックの全体像 データサイエンスエージェントの特徴 データサイエンスエージェントは、タスクをサブタスクに分解し、各ステップの目的を明示してから実行します。出力されたノートブックでは、各コードセルの直前に「 Reasoning : ...」という Markdown セルが配置され、これから何を行うか、なぜその処理が必要なのかが自然言語で解説されます。 主な特徴は以下のとおりです。 各セルが自己完結する（必要なインポートをセル内で都度実行する） 「データの読み込み → 欠損値の確認 → 補完処理 → 可視化」のように段階を明示する 各ステップに Reasoning ブロックを付与する エラーや警告が発生した場合、それを検知して次のセルでリカバリするプロセスが記録される ステップごとの透明性の確保が、データサイエンスエージェントの設計思想の中核と言えます。 データサイエンスエージェントのコードセル上部に表示される Reasoning マークダウン Claude Code の特徴 Claude Code は、ノートブック全体を 1 つの完成品として設計してから書き下ろします。プロンプトを受けると、内部で全体構造をプランニングし、必要なライブラリ、再利用するカラーパレットや定数、セクション構成を最初に決定したうえで、一括でノートブックを出力します。 主な特徴は以下のとおりです。 インポート文とグローバル定数（ TYPE_ORDER 、 TYPE_PALETTE など）を冒頭に集約する 同じ可視化スタイルを全セクションで一貫させる セルあたりのコード密度が高く、1 つのセルで複数のグラフを配置する 各セクションの最後に「ポイント」として短い解釈を記述する 観点別の比較 コードの量と構造 出力されたノートブックの構成を数値で示します。 項目 Claude Code データサイエンスエージェント 総セル数 55 41 コードセル 30 16 Markdown セル 25 25 総コード行数 約 353 行 約 286 行 インポートの位置 冒頭に集約 各セルで都度実行 セル数やコード行数の違いは、それぞれの設計思想を反映しています。Claude Code は完成されたレポートとしての密度を重視し、データサイエンスエージェントはステップごとの実行ログとしての読みやすさを重視していると言えます。 可視化のスタイル Claude Code はライブラリ選択の幅が広く、 folium による地図プロット、 seaborn の violinplot 、 pairplot 、 heatmap などを柔軟に使い分けます。1 つの観点に対して多角的にアプローチする構成です。 データサイエンスエージェントは、 plotly express による地図プロットや、 matplotlib と seaborn を組み合わせたシンプルな boxplot 、積み上げ棒グラフが中心です。種類を絞ることで、初学者でもプロセスを追いやすい一貫性を持たせています。 Claude Code が生成した Folium 地図と violinplot/heatmap データサイエンスエージェントが生成した Plotly Express 地図と box plot 説明可能性 ここが 2 つのアプローチで最も大きく分かれるポイントです。 Claude Code が生成するノートブックは、コードは洗練されているものの、「なぜその可視化手法を選んだのか」といった意図はコードから読み解く必要があります。一定以上のデータ分析リテラシーを前提としたレポート構成です。 一方、データサイエンスエージェントでは、各セルの直前に処理の意図が明記されます。例えば欠損値処理のフェーズでは、以下のような Reasoning が出力されます。 Reasoning: Based on the analysis of missing values, I will impute phone with 'Unknown' as it is a categorical identifier. For numerical columns review_rating, review_count, and difficulty_SD, I will use median imputation as it is more robust to outliers. For the categorical column difficulty_rank, I will use mode imputation. データサイエンスエージェントの Reasoning 付き欠損値補完セル Claude Code の可視化中心の欠損値処理セル 「何を、どう処理して、なぜそうするのか」が逐一言語化されるため、データ分析を学習中のメンバーにとって、ノートブック自体が良質なチュートリアル教材となります。 データクレンジングへの姿勢 データクレンジングに対する姿勢も対照的です。 Claude Code は欠損値を可視化して報告するに留め、欠損のまま分析を進めます。EDA としては伝統的な進め方で、欠損のパターン自体に情報があるため、むしろ望ましいという見方もあります。 データサイエンスエージェントは、欠損値を統計的に補完（インピュテーション）します。インピュテーションとは、欠損したセルを平均値や中央値などで埋める処理のことです。 phone は 'Unknown' 、数値カラムは中央値、カテゴリカラムは最頻値で埋める、という戦略を文章で宣言してから実行します。下流のモデリングに繋ぐパイプラインを想定すると、この明示性は実務で有用です。 どちらが正解ということはなく、Claude Code は分析者の判断を読者に委ね、データサイエンスエージェントは判断を逐一表に出す、という思想の違いです。 コードの再利用性 Claude Code はグローバル定数（ TYPE_ORDER 、 TYPE_PALETTE ）と再利用可能なヘルパー関数（ iqr_outliers ）を冒頭で定義し、以降のセルがそれを参照する構造になっています。コードベースとして手入れし続ける用途に適しています。 データサイエンスエージェントはセルごとに自己完結しているため、一部のセルだけを別のノートブックにコピーして流用するのが容易です。「特定の処理だけ使い回したい」というユースケースには、データサイエンスエージェントのスタイルが向きます。 設計思想の対比 これまでの検証を踏まえ、両者の設計思想の違いを一覧にまとめます。 観点 Claude Code データサイエンスエージェント 出力の性格 完成形のレポート 実行ログ・チュートリアル プランニング 上位から一括生成 ステップ単位で漸進的に実行 説明可能性 サマリでの論評 各セルに Reasoning を配置 カバレッジ 網羅的かつ深層的 コアとなる観点に集中 エラーハンドリング エラーを起こさない前提のコード エラー時は次セルでリカバリを実行 コードの密度 高い 低い（可読性重視） 再利用性 グローバル定義による一元管理 セルごとの自己完結型 介入の容易さ 低い 高い 想定ユーザー 経験豊富なアナリスト 学習者・ビジネス層・探索的分析 ユースケース別の使い分け データサイエンスエージェントが向いているケース データ分析の学習フェーズ Reasoning が併記されるため、分析者の思考プロセスを追体験する教材として使用できます。 対話的な探索フェーズ 「ここまでの結果を踏まえ、次は別の切り口で検証したい」といった、人間が途中で介入しながら進める探索に適しています。 ビジネス層によるデータ探索 非開発者が自然言語でデータを問い合わせる際、処理がブラックボックス化せず、結果の根拠をステップごとに確認できます。 Colab 環境での完結 Colab 起動を前提とした環境設定コードも含まれるため、ブラウザのみで即座に分析を開始したい場合に最適です。 パイプラインの部分流用 セル自己完結型のため、データクレンジングのセルだけを別ノートブックにコピーするといった部分流用がしやすくなります。 Claude Code が向いているケース 迅速なレポート作成 分析結果を素早くレポートとして共有したいケースで、一括生成が強みを発揮します。可視化のバリエーションが豊富で、レポートとしての完成度が高い特徴があります。 経験豊富なアナリストの叩き台 コードが慣用的で密度が高いため、これをベースに独自のカスタマイズや手動の書き換えを素早く行う用途に適しています。 要求項目の網羅（カバレッジ重視） プロンプトに指定したチェックリスト的な要求に対して、抜け漏れなく一括で対応させたい場合に有利です。 カスタムビジュアライゼーションの使用 folium のクラスタリング地図、scatter matrix、violin plot など、データ分析で慣習的に使われる可視化を幅広く使いたい場合に引き出しが多くなります。 ハサナル・バロキ (記事一覧) クラウドソリューション部 クラウドサポート課。インドネシア北スマトラ州ビンジャイ市出身。 YKK株式会社での金型設計を経て IT 業界へ転身。AI／システムエンジニアとしての経験を積み、現在は G-gen にてクラウドサポートに従事。 趣味は水泳と RAG チャットボット開発（OpenAI・Gemini・Vector Search 等）。好きな食べ物はラーメンと寿司。

G-gen の福井です。当記事では、Google が公開している公式 Agent Skills リポジトリ google/skills について、リポジトリの概要から、収録されているスキルの内容を解説します。 概要 google/skills リポジトリとは 公開背景 ライセンス 使い方 製品別スキル gemini-api alloydb-basics bigquery-basics cloud-run-basics cloud-sql-basics firebase-basics gke-basics Well-Architected Framework 柱別スキル google-cloud-waf-security google-cloud-waf-reliability google-cloud-waf-cost-optimization Recipe スキル google-cloud-recipe-onboarding google-cloud-recipe-auth google-cloud-networking-observability 概要 google/skills リポジトリとは google/skills は、Google が公開している公式の Agent Skills リポジトリです。GitHub 上で公開されており、Google Cloud の各製品やワークロードに関する専門知識を スキル としてパッケージ化したものが収録されています。 これらのスキルを AI エージェントツール（Gemini CLI、Claude Code、Cursor など）に導入することで、Google Cloud に関する正確な知識をもとにタスクを遂行できます。 google/skills が準拠している Agent Skills という規格（仕組み、スキルの構造、使い方など）については、以下の関連記事で解説しています。 blog.g-gen.co.jp 2026年5月現在、リポジトリに収録されているスキルは、以下の 3 つのカテゴリに分類されています。 カテゴリ 内容 製品別スキル Google Cloud の主要な製品（AlloyDB、BigQuery、Cloud Run、Cloud SQL、Firebase、Gemini API、GKE）ごとに、その使用方法やベストプラクティスをまとめたスキルです。 Well-Architected Framework 柱別スキル Google Cloud Well-Architected Framework の各柱に基づいた、アーキテクチャ設計のガイダンスを提供するスキル群です。製品別スキルが特定の製品をどう使うかを教えるのに対し、WAF 柱別スキルはワークロードをどのように設計・評価するかを扱います。 Recipe スキル Google Cloud で頻繁に行われる横断的なタスクを、手順の形でまとめたスキル群です。製品別スキルが特定の製品をどう使うか、Well-Architected Framework 柱別スキルがワークロードをどのように設計・評価するかを扱うのに対し、Recipe スキルは特定のタスクをどの順序で実行するかというレシピ（手順書）の形で、AI エージェントツールにタスクの遂行を支援させるスキルです。 参考 : google/skills - GitHub 参考 : Google Cloud Well-Architected Framework 当記事では、google/skills で公開されているスキルについて概要を紹介します。なお、紹介しているスキルは2026年6月現在、リポジトリで公開されているものです。 公開背景 google/skills リポジトリは、Google Cloud Next '26 のタイミングで Google から公開されました。Google Cloud に関する正確な知識を AI エージェントツールに反映させる手段として、Agent Skills を使うアプローチが Google から正式に提示されました。 Google が公開ブログで強調しているのは、 コンテキスト肥大化（Context Bloat） への対応です。コンテキスト肥大化とは、AI エージェントツールに大量のドキュメントを与えることで、AI エージェントツールの動作が不安定になる現象を指します。Google は、MCP サーバーで全ドキュメントを動的に取得するアプローチに加えて、よく使われる知識やワークフローをあらかじめスキルとしてパッケージ化して配布するという新しい選択肢を提供することを、google/skills の目的としています。 Google は、今後も google/skills リポジトリにスキルを追加していくことを公式ブログで明言しています。 参考 : Level Up Your Agents: Announcing Google's Official Skills Repository ライセンス google/skills リポジトリは、 Apache License 2.0 で公開されています。Apache License 2.0 は、商用利用、改変、再配布、プライベートでの使用が認められているライセンスです。スキルを業務で使用する場合や、スキルをカスタマイズして社内向けに配布する場合も、ライセンス条件に従えば自由に使用できます。 ライセンス条件として、スキルを再配布する場合は、元のライセンス表記と著作権表示を含める必要があります。また、スキルを改変して再配布する場合は、変更を加えた旨を明示する必要があります。 参考 : google/skills - LICENSE 使い方 google/skills のスキルは、Agent Skills の規格に準拠しています。そのため、規格に対応した AI エージェントツール（Gemini CLI、Claude Code、Antigravity、Cursor など）であれば、ベンダーを問わず使用できます。 スキルのインストールには、 npx skills install コマンドを使用します。以下のコマンドを実行することで、リポジトリに収録されたスキルから必要なものを選択してインストールできます。 npx skills install github.com/google/skills 製品別スキル gemini-api 概要 gemini-api は、Agent Platform（旧称 Vertex AI）上で Gemini API を使うための、統合ガイドとして機能するスキルです。 このスキルの特徴は、統合 SDK である Gen AI SDK の使用を強制し、レガシー SDK（ google-cloud-aiplatform 、 @google-cloud/vertexai 、 google-generativeai ）を明示的に禁止している点です。なお、Gen AI SDK のパッケージ名は言語ごとに異なり、Python の場合は google-genai 、Go の場合は google.golang.org/genai などとなっています。 モデル選定においても、 gemini-3.1-pro-preview （複雑な推論）や gemini-3-flash-preview （高速・バランス型）などの新世代モデルを推奨しています。一方で、 gemini-2.0-* 、 gemini-1.5-* 、 gemini-1.0-* 、 gemini-pro は legacy・deprecated として明示的に禁止しています。 主なユースケース 社内チャットボットやエージェントから Gemini を呼び出す Python、Go、Java、JavaScript、TypeScript、C# のコードの記述 社内文書を要約・分類・抽出するアプリケーションの実装 Live API によるリアルタイム音声・映像対話の実装 Nano Banana 系の画像生成モデルを使った、画像や動画の生成・編集アプリケーションの実装 社内データによる Gemini のファインチューニングコードの記述 大量データに対するバッチ予測の実行 alloydb-basics 概要 alloydb-basics は、AlloyDB for PostgreSQL のクラスタ・インスタンス・バックアップの管理と、AlloyDB 専用 MCP ツールとの連携を扱うスキルです。AlloyDB の主要な特徴である AlloyDB AI についても、SKILL.md 本文で言及されています。なお、AlloyDB AI には、ベクトル検索、ハイブリッド検索、AI 関数、自然言語機能などが含まれます。 このスキルの特徴は、セキュリティに関する指示が明記されている点です。クラスタ作成のサンプル手順では、本番環境向けにパスワード認証ではなく IAM データベース認証の使用を推奨しており、パスワードを使用する場合も Secret Manager 経由での管理を求めています。 また、 description 内で AlloyDB model context protocol（MCP）tools との統合を明示しています。AlloyDB 専用の remote MCP server と Gemini CLI extension の使い方を扱うリファレンスも備えており、Agent Skills と MCP を組み合わせる代表的なスキルとなっています。 主なユースケース gcloud CLI による AlloyDB のクラスタとプライマリインスタンスの作成・管理 Python・Java・Node.js・Go の各クライアントから AlloyDB に接続するコードの記述 AlloyDB remote MCP server と Gemini CLI extension を組み合わせた、AlloyDB 操作の AI エージェントツールからの自動化 Terraform による AlloyDB リソースの Infrastructure as Code としての管理 IAM データベース認証や事前定義ロールを使ったセキュリティ設定 bigquery-basics 概要 bigquery-basics は、BigQuery のデータセット・テーブル・ジョブの管理、SQL クエリ実行、データ取り込み、BigQuery ML や Gemini との統合を扱うスキルです。 このスキルの特徴は、 description 内で BigQuery ML と Gemini との統合による AI ドリブンなインサイト提供を明示している点です。これは、AI と統合された分析プラットフォームとしての BigQuery の位置づけを反映しています。 また、このスキルとは別に、BigQuery AI & ML 専用のスキルも用意されています。この専用スキルは google/adk-python リポジトリで公開されており、AI 関数（ generate 、 classify 、 forecast 、 search など）ごとに細かく分かれたリファレンスを備えています。これらのリファレンスは、SKILL.md の Related Skills セクションから参照する構成です。 主なユースケース bq CLI によるデータセットの作成、テーブルの作成・スキーマ管理、クエリ実行などの操作 Python・Java・Node.js・Go の各クライアントライブラリから BigQuery にアクセスするコードの記述 BigQuery remote MCP server と Gemini CLI extension を組み合わせた、BigQuery 操作の AI エージェントツールからの自動化 Terraform による BigQuery のデータセット・テーブル・予約（reservations）の Infrastructure as Code としての管理 IAM ロールと権限の設計、およびデータガバナンスのベストプラクティスに沿った権限設計 別途公開されている BigQuery AI & ML 専用スキルと組み合わせた、AI ドリブンな分析（分類、異常検知、予測、生成系関数など）の実装 cloud-run-basics 概要 cloud-run-basics は、Cloud Run の services、jobs、worker pools という 3 種類のリソースを使い分けて、アプリケーションをデプロイ・管理するスキルです。services は HTTP リクエストに応答するリソース、jobs は手動・スケジュール・イベント駆動でタスクを実行するリソース、worker pools は常時稼働のバックグラウンド処理を行うリソースです。 このスキルの特徴は、コード生成時の必須要件を重要ルールとして強制している点です。具体的には、デプロイされたコードは必ず 0.0.0.0 でリッスンし、注入された $PORT 環境変数を使用することを求めています。 デプロイ失敗時のトラブルシューティングも SKILL.md に組み込まれています。IAM/Permission エラー、Crash on Boot/Healthcheck 失敗、Native Dependency エラーの 3 パターンに対して、ログ取得コマンドや Buildpacks への切り替えといった具体的な対処手順が明記されています。 また、コンテナイメージのソースとしては Artifact Registry の使用が推奨されています。Docker Hub のイメージを使う場合も、1 時間キャッシュ制約を回避するため、Artifact Registry remote repository 経由が推奨されます。 主なユースケース Web アプリや API の HTTP サーバーをコンテナ化した Cloud Run service へのデプロイ バッチ処理や定期実行タスクの Cloud Run job としての実装、および並列タスクでの実行 Kafka・Pub/Sub・RabbitMQ コンシューマなど常時稼働のバックグラウンド処理の Cloud Run worker pool へのデプロイ ソースコードからの直接デプロイ（Buildpacks 自動ビルド、Dockerfile 使用、Preview の --no-build ） Terraform による services、jobs、worker pools、IAM バインディングの Infrastructure as Code としての管理 Cloud Run remote MCP server を使った、Cloud Run 操作の AI エージェントツールからの自動化 cloud-sql-basics 概要 cloud-sql-basics は、Cloud SQL のインスタンス、データベース、ユーザーの管理を扱うスキルです。 このスキルは、MySQL、PostgreSQL、SQL Server の 3 種類のデータベースエンジンを統一的に扱える設計となっています。Quick Start のサンプルには、PostgreSQL 18 が使用されています。 クライアントから Cloud SQL に接続する標準手段としては、Cloud SQL Auth Proxy が Quick Start に組み込まれています。これにより、インスタンス接続名（ PROJECT_ID:REGION:INSTANCE_NAME ）を経由したセキュアな接続パターンが示されている点が特徴です。 主なユースケース gcloud CLI による Cloud SQL の MySQL・PostgreSQL・SQL Server インスタンスの作成・管理 Python・Java・Node.js・Go の各クライアントライブラリから Cloud SQL に接続するコードの記述 Cloud SQL Auth Proxy を使ったセキュアな接続の構成 Cloud SQL remote MCP server と Gemini CLI extension を組み合わせた、Cloud SQL 操作の AI エージェントツールからの自動化 Terraform によるインスタンス・データベース・ユーザーの Infrastructure as Code としての管理 事前定義 IAM ロール、SSL/TLS 証明書、Auth Proxy を使ったセキュリティ設定 firebase-basics 概要 firebase-basics は、Firebase の製品・サービスを使うプロジェクト、特にモバイル・Web アプリ開発の作業全般を扱うスキルです。 このスキルの特徴は、SKILL.md の冒頭で別リポジトリ firebase/agent-skills のインストールを重要な事前要件として強く要求している点です。具体的には、プランニングモード使用時の事前タスク登録、npm の存在確認、Node.js のインストール案内、 npx -y skills add firebase/agent-skills -y の実行までを、順序立てて指示しています。 これは、outdated patterns（古いパターン）の使用を防ぐことを目的としています。そのため firebase-basics は単独では完結せず、 firebase/agent-skills リポジトリの別スキル群と組み合わせて使う前提の設計となっています。 主なユースケース Firebase CLI（ npx -y firebase-tools@latest ）を使った Firebase プロジェクトの作成・管理 JavaScript/TypeScript などのクライアントライブラリから Firebase に接続するコードの記述 Firebase MCP server や Terraform などの IaC ツールを使った構成 Firebase のセキュリティ機能の設定 firebase/agent-skills リポジトリの追加スキル群と組み合わせた、Firebase Hosting などの Firebase プロダクトを扱う作業 gke-basics 概要 gke-basics は、Google Kubernetes Engine（GKE）クラスタの設計、作成、構成、運用全般を扱うスキルです。 このスキルは、SKILL.md 内で推奨される Autopilot 構成をデフォルトとして強制しています。これにより、Standard モードではなく Autopilot を推奨する設計指針を、AI エージェントツールに与えます。 また、 description 内で「WHEN:」というキーワードを使い、AI エージェントツールがこのスキルを起動すべき具体的なトリガーキーワードを大量に列挙しています。トリガーキーワードには、 create GKE cluster 、 design GKE networking 、 secure GKE 、 optimize GKE cost 、 GKE inference 、 GKE upgrade などがあります。 リファレンスドキュメントの数も特徴的です。GKE のリファレンスドキュメントは 20 個以上あり、他の製品スキルの 3 倍以上の規模で、GKE の広い側面を網羅しています。なお、他の製品スキルのリファレンスドキュメントは 6 個程度です。さらに SKILL.md 本体には、シナリオ・トリガーキーワード・参照ファイルの対応表が明示されています。これにより、AI エージェントツールが Activation 後の Execution で適切なドキュメントを選択しやすい設計となっています。 主なユースケース Autopilot モードでの GKE クラスタのプロビジョニングと、クラスタ作成時のチェックリストに沿った本番環境のセットアップ VPC ネイティブ、プライベートクラスタ、Gateway API、Ingress などのネットワーク設計 Workload Identity、Secret Manager、RBAC、Binary Authorization を使ったセキュリティハードニングの実装 HPA、VPA、Cluster Autoscaler、Node Auto-Provisioning を使ったオートスケーリング設定 Spot VMs、ComputeClass、Committed Use Discount などを使ったコスト最適化の実装 GPU・TPU ノードプールと vLLM、GIQ などを使った LLM 推論ワークロードのデプロイ Prometheus、Grafana、Cloud Logging を使った可観測性の構築、およびマルチテナント、バッチ/HPC、バックアップ/DR の設計 Well-Architected Framework 柱別スキル google-cloud-waf-security 概要 google-cloud-waf-security は、Google Cloud Well-Architected Framework のセキュリティ柱に基づき、ワークロードのセキュリティ評価と設計推奨を行うスキルです。 このスキルは、製品別スキルと異なり references/ ディレクトリを持たない、設計指針型のスキルです。SKILL.md 本体に、概要、コア原則、関連する Google Cloud 製品、ワークロード評価のための質問、検証チェックリストの 5 セクションが記述されています。 WAF セキュリティ柱には 7 つの原則があり、それぞれに対応する Google Cloud 製品が明示的にマッピングされています。7 つの原則とは、Security by design、Zero trust、Shift-left security、Preemptive cyber defense、Use AI securely and responsibly、Use AI for security、Meet regulatory, compliance, and privacy needs です。 各原則には、それぞれ 10 個程度のワークロード評価のための質問と、検証チェックリストが用意されています。これにより、AI エージェントツールがユーザーのワークロードに対して、評価のための質問を体系的に投げかけられる構造を持つ点が特徴です。 主なユースケース 既存または計画中の Google Cloud ワークロードに対するセキュリティ評価の実施と、改善点の特定 新規プロジェクトの設計初期段階での、Security by Design の原則に沿った要件定義とアーキテクチャ設計 Zero Trust 原則（IAP、VPC Service Controls など）に基づくアクセス制御とネットワーク設計 Shift-left Security の原則に従った、Cloud Build、Binary Authorization、Artifact Registry を使ったセキュア CI/CD パイプラインの構築 Security Command Center、Google Threat Intelligence、Google SecOps を使った脅威検知と対応体制の整備 AI ワークロードのセキュリティ確保（モデル保護、データポイズニング対策、SAIF 準拠） 規制コンプライアンスやプライバシー要件（Assured Workloads、Organization Policy Service など）への対応 google-cloud-waf-reliability 概要 google-cloud-waf-reliability は、Google Cloud Well-Architected Framework の信頼性柱に基づき、ワークロードの信頼性評価と設計推奨を行うスキルです。 このスキルは、セキュリティ柱と同様の 5 セクションで構成された設計指針型のスキルです。信頼性柱には 9 つの原則があり、ユーザー体験に基づく信頼性定義、現実的な SLO 設定、リソース冗長性、水平スケーラビリティ、可観測性、グレースフルデグラデーション、障害復旧テスト、データ損失復旧テスト、ブレームレスなポストモーテムが示されています。 関連する Google Cloud 製品は、Compute、Networking、Storage and databases、Operations、Disaster recovery の 5 カテゴリでマッピングされています。 このスキルの特徴は、 SRE （Site Reliability Engineering）領域の概念が SKILL.md に組み込まれている点です。SLO、エラーバジェット、RTO/RPO、ブレームレス文化などがその例です。これにより、Google が SRE で長年蓄積した知見を、AI エージェントツールから引き出せる構造を持ちます。 主なユースケース 既存または計画中の Google Cloud ワークロードに対する信頼性評価の実施と、改善点の特定 ユーザー体験に基づく SLI/SLO の定義と、エラーバジェットを使った機能リリース速度の管理 単一障害点を排除する冗長構成（マルチゾーン、マルチリージョン）と、ロードバランシング、水平スケーリングの設計 Cloud Monitoring、Cloud Logging、Managed Service for Prometheus を使った可観測性の構築とアラート設計 サーキットブレーカ、リトライ、レート制限などのパターンを使ったグレースフルデグラデーションの実装 カオスエンジニアリングや game days を使った障害復旧テスト、および Backup and DR Service を使ったデータ損失からの復旧テスト（RTO/RPO）の計画 ブレームレスなポストモーテムプロセスの整備と、インシデントからの組織的な学習 google-cloud-waf-cost-optimization 概要 google-cloud-waf-cost-optimization は、Google Cloud Well-Architected Framework のコスト最適化柱に基づき、ワークロードのコスト評価とコスト効率設計の推奨を行うスキルです。 このスキルは、セキュリティ柱・信頼性柱と同様の 5 セクションで構成された設計指針型のスキルです。概要セクションでは、クラウドコストがオンプレミスの CapEx （資本的支出）モデルとは大きく異なる点を明示しています。そのうえで、 OpEx （運営支出）管理と FinOps 文化への移行を前提とした設計指針を提供しています。 コスト最適化柱には 4 つの原則があり、ビジネス価値とのアライメント、コスト意識の文化醸成、リソース利用の最適化、継続的最適化が示されています。これらの原則に対応する Google Cloud 製品は、可視化と監視、自動化と最適化ツール、効率的なインフラ、組織とガバナンスの 4 カテゴリに整理されてマッピングされています。 このスキルの特徴は、検証チェックリストが他の WAF 柱と比べて具体的・定量的である点です。たとえば「100% のリソースに env 、 team 、 app のラベル」「月次でのコミットメント見直し」「アイドルリソースの月次削除」などが挙げられます。これにより、AI エージェントツールがコスト最適化の現状を、実測可能な指標で評価できる構造を持ちます。 主なユースケース 既存または計画中の Google Cloud ワークロードに対するコスト評価の実施と、削減ポイントの特定 クラウド支出のビジネス価値との整合と、IT 投資の優先順位付け BigQuery billing export と Looker Studio を使ったコスト可視化ダッシュボードの構築 Recommender / Active Assist や FinOps hub を使った、アイドルリソース、リサイズ機会、未使用コミットメントなどの自動的な最適化提案の取り込み Spot VMs、Committed Use Discounts（CUD）、Cloud Storage Lifecycle Policies などを使ったコスト削減の実装 Resource Manager（組織・フォルダ・プロジェクト）、Labels、Organization Policy Service を使ったコスト配賦と支出ガバナンスの構築 Cloud Run、Cloud Run functions、GKE Autopilot などのマネージドサービスへの移行による運用コストの削減 Recipe スキル google-cloud-recipe-onboarding 概要 google-cloud-recipe-onboarding は、個人開発者が Google Cloud を初めて使い始めるための、アカウント設定からリソースデプロイまでの一連の手順をまとめたスキルです。 製品別スキルや WAF 柱別スキルと異なり、Recipe 形式の構造を持ちます。具体的には、7 段階の順次実行手順と、4 項目の完了判定ロジックで構成されており、AI エージェントツールが手順を逐次実行しながら、完了状態を検証できる設計となっています。 対象は、エンタープライズ向けではなく個人開発者です。SKILL.md には、個人開発者向けの簡略化された手順であると明記されています。なお、組織のオンボーディングが必要な場合は、SKILL.md 内から別途 Enterprise Setup Guide への参照が案内されます。 さらに SKILL.md の冒頭には、確認質問として 5 個の事前質問が配置されています。事前質問の内容は、Google アカウントの有無、個人と組織のどちらか、IT 管理者かどうか、最初に作りたいリソース、CLI/IDE/Console の選好です。これにより、AI エージェントツールがユーザーの状況を踏まえた手順を選択できる構造を持ちます。 主なユースケース Google Cloud を初めて使う個人開発者による、無料クレジット（$300）の有効化からプロジェクト作成、CLI セットアップ、最初のリソースデプロイまでの順次実行 最初のプロジェクトの作成と、Project ID の取得、および請求アカウントとの紐付け gcloud CLI のインストールと、 gcloud init によるローカル環境から Google Cloud を操作できる状態の構築 必要な API（Cloud Run、Compute Engine、Cloud Storage などの API）の gcloud services enable による有効化 用途に応じた Cloud Run、Compute Engine、Cloud Storage からの最初のリソースの選択とデプロイ Validation Logic による、Project 作成、Billing 連携、CLI 認証、Resource 動作の 4 つの確認と、オンボーディング完了の判定 google-cloud-recipe-auth 概要 google-cloud-recipe-auth は、Google Cloud のサービスや API への認証・認可全般を扱うスキルです。人間ユーザー、サービスアイデンティティ、ADC（Application Default Credentials）、外部クラウドからのアクセスまでを網羅しています。 このスキルの特徴は、Service Account Key の使用を強く非推奨している点です。SKILL.md 内では、Service Account Key を危険な JSON ファイルと表現し、ローカルでの使用を強く避けるよう指示しています。代わりに、Service Account Impersonation、リソースへのアタッチ、Workload Identity Federation を全面的に推奨しています。なお、検証チェックリストにも、キーをローカルで使っていないかを確認する項目が含まれます。 SKILL.md の冒頭には、確認質問として 4 個の事前質問が配置されています。事前質問の内容は、認証主体、実行環境、ターゲット、クライアントライブラリ使用の有無です。これにより、AI エージェントツールが状況に応じて適切な認証方式を選択できる構造を持ちます。 さらに、3 つの実用的な Examples も SKILL.md に含まれています。Human-to-Service（ローカル Python）、Service-to-Service（Cloud Run から Cloud SQL）、Custom App（OIDC ID Token）の 3 例であり、AI エージェントツールが具体的な実装パターンを参照しながらコードを生成できる作りとなっています。 主なユースケース ローカル開発での ADC（Application Default Credentials）のセットアップと、クライアントライブラリから Google Cloud にアクセスするコードの記述 Service Account Impersonation を使った、Service Account Key をダウンロードしないセキュアなローカル開発 Compute Engine、Cloud Run、Cloud Functions などのリソースへのカスタム Service Account のアタッチによる、サービス間認証の構成 GKE での Workload Identity Federation for GKE を使った、Kubernetes Pod から Google Cloud API へのキーレスアクセス AWS、Azure、オンプレなど外部クラウドのワークロードからの、Workload Identity Federation を使ったキーレスアクセスの構成 IAP や Identity Platform を使った、エンドユーザー（従業員や顧客）向け認証の Web アプリケーションへの組み込み IAM ロール（事前定義ロールを優先し、必要なら Custom ロール）の設計と付与 OIDC ID Token を使った、別の Cloud Run サービスへのプライベート呼び出しの実装 google-cloud-networking-observability 概要 google-cloud-networking-observability は、Google Cloud のネットワーク問題を、ログ・メトリクス・診断ツールを使って調査・診断するスキルです。 このスキルは、SKILL.md の冒頭に結果優先という基本方針を掲げています。これは、最小限のクエリで直接答えを出し、0 件や null の結果も結論として受け入れて即座に終了するよう、AI エージェントツールに指示するものです。これにより、冗長な調査を抑制する設計となっています。 さらに重要な制約事項として、多数の禁止事項を明示し、効率的な調査を強制している点が特徴です。具体的には、探索的クエリは 2 個までとすること、Tool A と Tool B の結果差を深掘りする「不一致ループ」の禁止、補助スクリプト（ .sh 、 .py ）の作成禁止、Monitoring API による BigQuery 結果のダブルチェック禁止などが挙げられます。 データソースとしては、Cloud Monitoring MCP、BigQuery MCP、Cloud Logging MCP の使用を最優先としています。特にボリューム分析や Top-N タスクでは、BigQuery 連携データセット（ _AllLogs ）を一次データソースに指定しています。このように、Agent Skills と MCP の組み合わせを前提とした調査フローを定義しています。 主なユースケース 「接続できない」「通信が遅い」「パケットが落ちる」などのネットワーク問題の、VPC Flow Logs、Firewall Logs、Cloud NAT Logs、Networking Metrics、Connectivity Tests を使った原因特定 VPC Flow Logs を BigQuery 連携データセットでアグリゲーションし、トラフィック量、傾向、top talkers の分析 Firewall Logs からの DENY/ALLOW イベントの抽出による、特定の通信がブロックされている原因のファイアウォールルールの特定 Cloud NAT Logs による NAT 翻訳の監査や、ポート枯渇のトラブルシュート Cloud Firewall Plus や Cloud IDS の Threat Logs からの、SQL インジェクションやマルウェアなどの悪意あるトラフィックパターンの検知 Networking Metrics によるスループット、RTT（レイテンシ）、パケットロスの時系列トレンドや過去の性能の分析 Connectivity Tests による、エンドポイント間のファイアウォールやルーティングの設定ミスの静的解析での特定 福井 達也 (記事一覧) カスタマーサクセス課 エンジニア 2024年2月 G-gen JOIN 元はアプリケーションエンジニア(インフラはAWS)として、PM/PL・上流工程を担当。G-genのGoogle Cloudへの熱量、Google Cloudの魅力を味わいながら日々精進

G-gen の今村です。当記事では、Cloud SQL で提供されているパフォーマンス最適化機能の1つである インデックスアドバイザー について解説します。 概要 インデックスアドバイザーとは 仕組み 料金と要件 料金 対象エディションと要件 有効化の手順 推奨事項の確認 推薦インデックスの確認方法 画面に表示される評価データの内容 Gemini による支援 推奨事項の適用 概要 インデックスアドバイザーとは Cloud SQL の インデックスアドバイザー 機能は、Cloud SQL で実行されたクエリを自動的に分析し、パフォーマンス向上につながる最適なインデックスを提案する機能です。当機能は Cloud SQL の Enterprise Plus エディションでのみ使用できます。 2026年6月現在、Cloud SQL の主要な3つのデータベースエンジン（MySQL、PostgreSQL、SQL Server）のすべてでサポートされています。各データベースエンジンにおける基本的な機能の目的や仕組みに大きな違いはありません。 リレーショナルデータベースの運用において、クエリの実行速度低下を解決するためのインデックス追加は非常に有効な手段です。しかし、どのカラムにどのようなインデックスを定義すべきかの判断には、高度な知識と経験が必要です。インデックスアドバイザーを使用することで、システムが実際のクエリ負荷に基づいて具体的な推奨インデックスを提示するため、データベース管理者の運用負荷を大幅に削減できます。 参考 : インデックス アドバイザーを使用する | Cloud SQL for PostgreSQL Cloud SQL の機能の詳細は、以下の記事を参照してください。 blog.g-gen.co.jp 仕組み インデックスアドバイザーがクエリを分析する際は、具体的な数値や文字列などのリテラルを除外した「正規化クエリ」と呼ばれる共通のパターンで追跡されます。例えば、検索する数値が異なっていても、同じ型のクエリとしてまとめて統計が取られる仕組みです。 このデータを基に、パフォーマンス向上につながる新しいインデックスが自動で識別され、具体的な CREATE INDEX 文として推奨事項に保存されます。生成された推奨事項は、Google Cloud コンソールの Query Insights ダッシュボードや推奨事項画面からいつでも確認できます。 なお当機能が提案するのは、データの検索速度を高めるためのインデックスであり、主キーや外部キーなどのテーブル構成の推奨事項などは生成されません。またリレーショナルデータベースの一般的な仕様として、テーブルにインデックスを追加すると、データ更新時にインデックス更新も同時に行われることで書き込み処理の負荷が増加する点にも留意が必要です。 よって、インデックスアドバイザーによる推奨事項を無条件に採用するのではなく、パフォーマンス影響等を考慮して、適用の可否を判断してください。 料金と要件 料金 インデックスアドバイザー機能自体の使用に追加料金はかかりません。Cloud SQL の Enterprise Plus エディションを利用していれば、無料で使用できます。 対象エディションと要件 インデックスアドバイザーを使用するには、Cloud SQL の Enterprise Plus エディション を使用している必要があります。また、インスタンスで Query Insights 機能が有効化されていることが要件となります。 Query Insights が収集する指標データは、原則として Cloud SQL インスタンスのストレージ領域を占有しません。指標は Cloud Monitoring に保存されるため、インスタンス自体のディスク容量を圧迫しない設計になっています。ただし、収集された指標の転送や API リクエストに伴い、Cloud Monitoring 側の料金が適用される場合がある点に留意してください。 参考 : Cloud SQL のエディションの選択 | Cloud SQL for PostgreSQL Cloud Monitoring の機能の詳細は以下の記事を参照してください。 blog.g-gen.co.jp 有効化の手順 インデックスアドバイザーを有効化する手順は以下の通りです。 Cloud SQL の「インスタンス」ページに移動し、対象のインスタンス名をクリック 概要ページから「編集」をクリック 「構成の編集」をクリック 「インスタンスのカスタマイズ」セクションで「Query Insights」を展開 「Query Insights を有効にする」チェックボックスをオンにする 「インデックスアドバイザーを有効にする」チェックボックスをオンにする 「保存」をクリックして設定を反映 インデックスアドバイザーを有効にするには、インスタンスの再起動が必要です。本番環境で実施する際は、必ずメンテナンス可能な時間帯を計画してください。 参考 : Query Insights を使用してクエリのパフォーマンスを向上させる | Cloud SQL for SQL Server 推奨事項の確認 推薦インデックスの確認方法 推奨インデックスを確認する手順は以下の通りです。 Cloud SQL の「インスタンス」ページに移動 対象のインスタンス名をクリックし、「Query Insights」をクリック 「上位のクエリとタグ」セクションで目的のクエリをクリック 画面に表示される評価データの内容 クエリの詳細画面では、推奨されたインデックスを適用すべきかを総合的に判断するための情報がまとまっています。 まず確認したいのがパフォーマンスへの影響です。推定クエリ速度が「高」「中」「低」の3段階で示されるため、導入によってどれほどの速度向上が見込めるかが一目でわかります。次に、その効果に対してどれほどのリソースが必要になるかを、影響を受けるテーブルと必要な追加ストレージサイズの推定値から見積もります。さらに、そのインデックスがシステム全体のどれほど多くの処理に貢献するかを、影響を受けるクエリの数で評価します。 このように、見込める効果とリソースへの影響を天秤にかけて適用の可否を判断した上で、画面上の「インデックスの作成」をクリックすると、実行すべき具体的な DDL が表示されます。 推奨事項は、自動的にデータベースへ適用されるわけではありません。そのため、ユーザー自身がコンソール画面から CREATE INDEX 文をコピーし、手動で適用作業を行う必要があります。 Gemini による支援 2026年6月現在、Cloud SQL ではインデックスアドバイザーによる自動分析だけでなく、生成 AI モデル Gemini を使用したクエリ作成のアシスタンス機能も提供されています。 Google Cloud コンソールの Cloud SQL Studio などの画面において、自然言語のプロンプトから SQL の生成や、クエリ構造の説明を取得できます。これにより、インデックスアドバイザーが提案した CREATE INDEX などの DDL の意図を深く理解したり、最適化されたクエリの記述を効率化できます。機能の具体的な使用方法や最新の要件については、公式ドキュメントを参照してください。 参考 : Gemini を使用して SQL クエリを作成する | Cloud SQL for PostgreSQL 推奨事項の適用 推奨事項を適用するには、コピーした CREATE INDEX 文を、Cloud SQL インスタンス内のデータベースに対して手動で実行します。実行にあたり、普段運用で使用しているデータベース管理ツール経由で DDL を実行することも、Google Cloud コンソール上で直接 SQL を実行できる Cloud SQL Studio を使用することもできます。 一般的に、インデックスの作成処理は、既存のテーブル内にあるレコードを読み込んだうえで新しくインデックスを構築してディスクに書き込むため、データベースの CPU やディスク I/O などのリソースを大きく消費します。対象テーブルのデータ量によっては処理に長い時間がかかり、本番環境のパフォーマンスに影響を与える可能性がある点に留意してください。 そのため、本番環境へ適用する際は、事前に検証環境で処理時間や影響度を確認し、システムへの負荷を最小限に抑えられるよう、利用者の少ない時間帯に実行を計画してください。 今村 壱生 (記事一覧) クラウドソリューション部 ソリューションアーキテクト課 2026年3月にG-genへ入社。約7年間 Web 広告運用やウェブ解析に携わり、その後は社内 SE として開発業務に従事。広告運用の現場感と技術的な視点、その双方を併せ持つ経験をベースに、現在は Google Cloud のスキルアップに注力。データ活用とクラウド技術を融合させ、お客様のビジネス成長を支えるエンジニアを目指している。 Follow

G-gen の三浦です。当記事では、Google SecOps の AI エージェントである トリアージと調査エージェント （TIN）と、それを Playbook に組み込む エージェントの自動化 （Agentic Automation）を使い、アラートの一次対応を自動化した結果を紹介します。 概要 Google SecOps とは トリアージと調査エージェント（TIN）とは TIN の無償トライアル エージェントの自動化（Agentic Automation）とは 注意点 検証の手順 TIN の有効化 アラートの確認 概要 TIN なし（有効化前のアラート） TIN あり（有効化後のアラート） TIN を組み込んだ Playbook の作成 Playbook の作成 起動条件の設定 AI Agents ステップの追加 条件分岐の設定 Branch のアクション設定 Playbook の動作確認 概要 Google SecOps とは Google Security Operations （以下、Google SecOps）は、Google Cloud のセキュリティ運用プラットフォームです。SIEM、SOAR、脅威インテリジェンス、Gemini を利用した AI による運用支援を一つのプラットフォームで提供します。 詳細は以下の記事をご参照ください。 blog.g-gen.co.jp トリアージと調査エージェント（TIN）とは トリアージと調査エージェント （Triage and Investigation Agent、以下 TIN ）は、Google SecOps に組み込まれた AI ベースの調査エージェントです。関連するイベントやユーザー・端末・IP の確認・分析などを自動で行います。 TIN は、アラートを受け取ると主に以下の 3 つを出力します。 出力 内容 判定 アラートが実際の脅威か、誤検知かを分類する 確信度 判定にどれだけ自信があるかを High Confidence （高い確信度）などのラベルで示す アラートと調査結果の要約 判定の根拠と推奨される次のアクションを記述する TIN は、アラート発生後に自動で調査を開始する 自動調査 と、管理者が必要に応じて開始する 手動調査 の両方に対応しています。 参考 : トリアージ エージェントと調査エージェントを使用してアラートを調査する TIN の無償トライアル 2026 年 4 月 1 日〜6 月 30 日の期間、TIN の無償トライアルが提供されています。対象は Google SecOps の Enterprise / Enterprise Plus サブスクリプション、および Google Unified Security です。 トライアル期間中の 1 時間あたりの実行回数の上限は以下のとおりです。 対象サブスクリプション 実行回数の上限（1 時間あたり） 内訳 Enterprise 10 回 自動 5 回、手動 5 回 Enterprise Plus / Google Unified Security 20 回 自動 10 回、手動 10 回 参考 : Google エージェント SOC のトライアルの詳細 参考 : Google Unified Security エージェントの自動化（Agentic Automation）とは エージェントの自動化 （以下、 Agentic Automation ）は、Google SecOps の Playbook（アラート対応手順を自動化するワークフロー）に AI Agent を 1 つのステップとして組み込める仕組みです。AI の判定に応じて、後続の対応を分岐・自動化できます。 参考 : エージェントの自動化 参考 : [Playbooks] ページを確認する 当記事では、TIN と Agentic Automation を以下のように組み合わせます。 機能 役割 TIN AI がアラートを一次調査し、判定・確信度・アラートと調査結果の要約を出力する Agentic Automation TIN の調査結果に応じて、後続の対応を自動で振り分ける 注意点 Agentic Automation は、2026 年 5 月現在、 Preview 版 です。当記事で解説する内容は一般提供（GA）の際に変更される可能性がある点に留意してください。 Preview 版のサービスや機能を使う際の注意点は、以下の記事も参考にしてください。 blog.g-gen.co.jp 検証の手順 当記事では、以下の流れで検証を行います。 項番 内容 説明 1 TIN の有効化 Google SecOps コンソールから TIN を有効化します。 2 アラートの確認 同種のアラートが TIN の有効化前と有効化後で管理者にどのように見えるかを確認します。 3 TIN を組み込んだ Playbook の作成 Playbook に TIN を組み込み、誤検知の可能性が高いと判定したケースを自動でクローズする条件分岐を設定します。 4 Playbook の動作確認 アラートを再度発生させ、新規のケースがクローズされることを確認します。 TIN の有効化 Google SecOps の管理画面で Gemini アイコンを選択し、[Gemini Investigations] を有効化します。 TIN の有効化 TIN の実行設定は [Settings] > [SIEM Settings] > [Gemini Investigations] から確認・変更できます。 TIN の設定確認 参考 : トリアージ エージェントと調査エージェントを使用してアラートを調査する アラートの確認 概要 TIN を有効化する前と後で、同じ種類のアラートが管理者にどう見えるかを比較します。 当検証では、Google Workspace の監査ログから検知されたアラート 「Two Factor Authentication Enforcement Removal by a Workspace Admin User」 （Google Workspace 管理者による組織全体の 2 段階認証プロセス強制設定の無効化を示すアラート）を使用します。 TIN なし（有効化前のアラート） TIN が有効化されていない場合のアラート画面です。画面上部の [Run investigation] から手動で TIN の調査を実行することもできます。 アラート（TIN 未使用） TIN あり（有効化後のアラート） TIN が有効化された状態では、アラート発生後に自動で調査が実行され、結果が表示されます。[View investigation] を選択することで、詳細を確認できます。 アラート（TIN 使用） TIN によるアラート調査結果1 TIN によるアラート調査結果2 上記の調査結果から分かることは以下のとおりです。 項目 結果 判定 False Positive（誤検知） 確信度 High Confidence（高） アラート要約 日本国内の Google Workspace 管理者ユーザーによる、組織レベルの 2 段階認証設定の無効化 調査結果の要約 同じユーザーが同じ IP アドレスから、2 段階認証に関する設定変更を短時間で実施していたことが判明 推奨される次のアクション 5 件提示。うち 2 件は TIN が自動で追加調査できる項目、3 件は管理者による確認・対応が必要な項目 調査タイムライン 関連 IP・ユーザーに関するログ検索を自動実行し、時系列を表示 TIN を組み込んだ Playbook の作成 Playbook の作成 [Response] > [Playbooks] > [Create a new Playbook] を選択します。 Playbook の作成1 以下を選択し、[Create] を選択します。 設定項目 値 補足 Type Playbook 単体で実行可能なワークフロー全体（Block は複数の Playbook から呼び出せる再利用可能な処理ブロック） Choose Folder Default Playbook の整理用フォルダー Environment Default Environment 適用先のテナント環境 Playbook の作成2 参考 : [Playbooks] ページを確認する 参考 : ハンドブックのブロックを操作する Playbook の編集画面が開きます。画面上部の [Create Playbook with Gemini] から Gemini を使って作成することもできます。 Playbook の編集画面 参考 : Gemini でハンドブックを作成、編集する 起動条件の設定 左側の [Drag a trigger over here] エリアに、 Triggers から All（すべてのアラート） をドラッグして追加します。Trigger は Playbook の起動条件で、対象アラートを絞り込む役割を持ちます。 Trigger の設定 参考 : ハンドブックでトリガーを使用する 参考 : ハンドブックでアラートタイプ トリガーを使用する AI Agents ステップの追加 右側の [Drag a step over here] エリアに、 AI Agents タブから Triage and Investigation Agent （TIN）をドラッグして追加します。 AI Agent ステップの追加 追加した AI Agent ステップをダブルクリックし、[Settings] へ移動することで設定を確認できます。 設定項目 内容 Action Type Automatic ：Playbook 実行時に自動で TIN を起動。 Manual ：ケース画面から手動で実行 Retry on failure 実行失敗時に再試行するか If step fails Stop playbook ：実行失敗時に以降のステップを停止。 Skip step ：実行失敗時はスキップして次のステップへ TIN の設定 参考 : エージェントの自動化 条件分岐の設定 Flow タブから Condition をドラッグして AI Agent ステップの後に配置します。Condition は Branch （条件式に一致した経路）と ELSE （いずれにも一致しなかった経路）で構成されます。 条件分岐の設定 追加した Condition_1 をダブルクリックし、Branch の条件式を設定します。左側のフィールド入力欄を選択し、[Playbook] > [Triage and Investigation Agent_1.JsonResult] > [Builder] を選択します。 Branch の条件設定1 verdict （TIN の判定）を選択し、[Insert] を選択します。 Branch の条件設定2 右側の項目で手動で False Positive と入力すると、1 つ目の条件「Verdict = False Positive」が完成します。続いて + で条件を追加し、同様に Builder を開きます。 Branch の条件設定3 confidence （TIN の確信度）を選択し、[Insert] を選択します。 Branch の条件設定4 右側の項目で手動で High Confidence と入力し、[Save] を選択します。2 つ目の条件「Confidence = High Confidence」が完成します。 Branch の条件設定5 設定後の Playbook は次のように動作します。 段階 条件 動作 起動 すべてのアラート Playbook が起動し、TIN が一次調査を実施 条件一致 Verdict が False Positive かつ Confidence が High Confidence （誤検知の可能性が高い） ケースを自動クローズ 条件不一致 上記以外 Playbook 側では追加処理を行わない（管理者は通常どおりアラート画面で確認） 参考 : ハンドブックでフローを使用する Branch のアクション設定 Actions タブから、条件を満たした際の動作を設定します。当検証では、アラートを含むケース単位でクローズするため、 Close Case を選択し、Branch 側の [Drag a step over here] エリアに配置します。 Close Case の設定1 Siemplify_Close Case_1 をダブルクリックし、以下を設定して [Save] を選択します。 設定項目 値 補足 Reason Not Malicious クローズの理由：悪意なし／誤検知 Root Cause Lab test 根本原因：検証目的のテスト Comment TIN による自動クローズ（ False Positive / High Confidence ） クローズ時に記録する任意のコメント Close Case の設定2 参考 : ケースを解決してクローズする これで、TIN が False Positive / High Confidence （誤検知の可能性が高い）と判定した場合に、ケースが自動的にクローズされる Playbook が完成します。最後に、右上の [Save] を選択して Playbook を保存します。 Playbook の保存 Playbook の動作確認 作成した Playbook の動作を検証するため、前述の 2 段階認証の設定変更を再度実施します。発生したアラートに対して TIN の調査が自動的に走り、対象ケースが自動でクローズされていることを確認します。 ケースの確認 Playbook の状況確認1 Playbook の状況確認2 三浦 健斗 (記事一覧) クラウドソリューション部 2023年10月よりG-genにジョイン。元オンプレ中心のネットワークエンジニア。 ネットワーク・セキュリティ・唐揚げ・辛いものが好き。 Google Cloud Partner All Certification Holders 2025 / Google Cloud Partner Top Engineer 2026

G-gen の佐々木です。当記事では、Google Cloud にデプロイした AI エージェントに固有のアイデンティティを付与する Agent Identity の仕組みと、Agent Identity を用いた認証方式について解説します。 概要 Agent Identity とは サービスアカウントとの違い Agent Identity の基本 SPIFFE 形式の識別子 エージェント認証情報 セキュリティとガバナンス 認証方式 サポートされる認証方式 認証マネージャー 認証プロバイダー Agent Identity の設定例 概要 Agent Identity とは Agent Identity は、Google Cloud 上で動作する AI エージェントに SPIFFE 標準に基づく安全なアイデンティティを付与する仕組みです。これにより、エージェントは MCP サーバー、Google Cloud リソース、外部 API、他のエージェントに対して、自身の権限で安全に認証できます。 参考 : Agent Identity overview 参考 : SPIFFE 2026年5月現在、Agent Identity を使用した認証に対応しているエージェント実行基盤は以下の2つです。 Agent Runtime（旧称 Vertex AI Agent Engine） Gemini Enterprise App サービスアカウントとの違い 従来、エージェントの実行環境にはサービスアカウントを利用するのが一般的でしたが、この方式ではサービスアカウントが本来意図しない用途で使用される可能性があります。Agent Identity はこの問題を解決するもので、サービスアカウントとは以下の点で異なります。 項目 サービスアカウント Agent Identity 複数ワークロードでの共有 可能 複数のエージェントで同じサービスアカウントを使い回すこともできてしまう 不可 エージェント単位で ID が発行される 権限借用（impersonation） 可能 別のプリンシパルにサービスアカウントの借用（なりすまし）を許可することもできてしまう 不可 エージェント自身以外は ID を使用できない 長期キーの手動生成 可能 サービスアカウントキーはデフォルトで有効期限がなく、漏洩した場合は無効化しない限り悪用され続けてしまう 不可 トークンのバインド なし アクセストークンを入手した第三者がそのまま使用できてしまう あり トークンが X.509 証明書と紐付き、意図された実行環境以外では使用できない Agent Identity の基本 SPIFFE 形式の識別子 Agent Identity に対応した環境にエージェントをデプロイすると、エージェントに固有の SPIFFE ID が自動で割り当てられます。Agent Identity が付与する ID は SPIFFE ID と呼ばれ、書式は以下のとおりです。 spiffe://<トラストドメイン>/resources/<サービス名>/<リソースパス> IAM ポリシーで SPIFFE ID を参照する際は、プレフィックスとして spiffe:// ではなく principal:// もしくは principalSet:// を使用します。 対象 識別子 単一エージェント（Agent Runtime） principal://agents.global.org-<組織ID>.system.id.goog/resources/aiplatform/projects/<プロジェクト番号>/locations/<ロケーション>/reasoningEngines/<エンジンID> 単一エージェント（Gemini Enterprise） principal://agents.global.org-<組織ID>.system.id.goog/resources/discoveryengine/projects/<プロジェクト番号>/locations/global/collections/default_collection/engines/<アプリID> プロジェクト内の全エージェント principalSet://agents.global.org-<組織ID>.system.id.goog/attribute.platformContainer/aiplatform/projects/<プロジェクト番号> 組織内の全エージェント principalSet://agents.global.org-<組織ID>.system.id.goog/* エージェント認証情報 Agent Identity を有効化したエージェントには、24時間有効な X.509 証明書が自動でプロビジョニングされます。エージェントはこの証明書を使用して Google Cloud アクセストークンを取得します。 デフォルトで Context-Aware Access ポリシーが適用され、DPoP（Demonstrable Proof of Possession）と mTLS の使用が強制されます。これによりアクセストークンが X.509 証明書にバインドされ、エージェントの実行環境以外では使用できない仕組みになっています。 参考 : RFC 9449: OAuth 2.0 Demonstrating Proof-of-Possession (DPoP) セキュリティとガバナンス Agent Identity では、Google Cloud の各種セキュリティ関連サービスとの統合により、認証情報の保護とアクセス制御のための多層的な仕組みが提供されています。 機構 内容 Context-Aware Access デフォルトで Google マネージドのポリシーが適用され、DPoP と mTLS により証明書にバインドされたトークンを保護する（前述） IAM ポリシー Allow ポリシー / Deny ポリシーによる標準的なアクセス制御をエージェントの ID に適用できる プリンシパルアクセス境界ポリシー 他の IAM 権限付与にかかわらず、エージェントがアクセスできるリソースの範囲を制限できる VPC Service Controls（プレビュー） サービス境界の Ingress / Egress ルールでエージェントの ID を条件に指定できる 参考 : Google CloudのIAMにおけるDenyポリシーを解説 - G-gen Tech Blog 参考 : プリンシパルアクセス境界ポリシー（Principal access boundary policies）を解説 - G-gen Tech Blog 参考 : VPC Service Controlsを分かりやすく解説 - G-gen Tech Blog 認証方式 サポートされる認証方式 エージェントが「何に対して」「どの権限で」認証するかによって、選択する方式が変わります。Agent Identity でサポートされる方式は以下のとおりです。 方式 権限タイプ 認証対象 主な用途 クラウドベースの ID エージェント自身 Google Cloud Google Cloud の他サービスへアクセスする 3-legged OAuth（プレビュー） ユーザー委任 外部ツール・サービス ユーザーの同意を得て、その代理で Jira や GitHub などにアクセスする 2-legged OAuth（プレビュー） エージェント自身 外部ツール・サービス ユーザー同意なしにエージェント自身の資格情報で認証する API キー（プレビュー） エージェント自身 外部ツール・サービス API キーで認証する外部サービスにアクセスする HTTP Basic Auth エージェント自身 外部ツール・サービス 非推奨（平文パスワード） 5つの方式はいずれもエージェントに付与された SPIFFE ID を前提としますが、その使われ方が異なります。 Google Cloud へのアクセス（クラウドベースの ID）では、Agent Identity が発行する SPIFFE ID と X.509 証明書そのものが資格情報となり、エージェントの SPIFFE ID に IAM ロールを付与するだけで利用できます。一方、外部ツールへの 3-legged OAuth・2-legged OAuth・API キーの3つの方式では、Agent Identity を起点に、後述する認証マネージャーに保管された外部サービス用の認証情報を取り出して使います。 認証マネージャー Agent Identity 認証マネージャー は、外部サービスへの認証情報（API キー、OAuth クライアント ID / シークレット、エンドユーザー OAuth トークン）を Google マネージドのボールトに保管し、エージェントの実行時に自動で注入する仕組みです。エージェント開発者がコード内に秘匿情報をハードコードしたり、自前で安全に保管したりする必要がなくなります。 ボールトに保管された認証情報はすべてエージェントの SPIFFE ID に帰属する形で管理されるため、どのエージェントがどの認証情報を使用したかを IAM ポリシーと監査ログの両方で追跡できます。 認証プロバイダー 認証プロバイダー は、認証マネージャーが管理する認証情報を登録するためのリソースで、認証先のサービスごとに作成します。 認証マネージャーによってエージェントが外部サービスにアクセスする際の流れは以下のとおりです。 エージェントの SPIFFE ID と認証先のサービスの情報を元に、対応する認証プロバイダーが特定される 認証プロバイダーに紐付く認証情報がボールトから取り出される エージェントに認証情報が注入される エージェントが注入された認証情報を使用して外部サービスにアクセスする 認証プロバイダーは認証方式ごとに以下の3種類があり、いずれもプロジェクト内、ロケーション単位で管理されます。 種類 認証対象の例 ユーザー同意 特徴 3-legged OAuth 認証プロバイダー Jira、GitHub などの外部 SaaS 必須 ユーザーの代理でアクセスする。認証マネージャーが同意画面へのリダイレクトとトークン保管を仲介する 2-legged OAuth 認証プロバイダー ServiceNow、Salesforce など 不要 エージェント自身のアイデンティティでクライアント認証情報を交換する API キー認証プロバイダー Google Maps API など — API キーを Google マネージドのボールトに保管し、コードへのハードコードを避けられる 作成した認証プロバイダーをエージェントから使用するには、エージェントの SPIFFE ID に IAM Connector User（ roles/iamconnectors.user ）ロールを付与します。 その他、具体的な登録手順やエージェントからの使用方法は、以下の公式ドキュメントを参照してください。 参考 : Authenticate using 3-legged OAuth with auth manager 参考 : Authenticate using 2-legged OAuth with auth manager 参考 : Authenticate using API key with auth manager 参考 : Manage Agent Identity auth providers Agent Identity の設定例 ここでは、最も基本的なクラウドベースの ID で Google Cloud のサービスにアクセスする方式（認証マネージャー / 認証プロバイダーの登録が不要な方式）の例を示します。 Agent Identity を有効化するには、エージェントをデプロイする際に、 config.identity_type として AGENT_IDENTITY を指定します。Agent Runtime の場合は、 client.agent_engines.create() を使用する際に config に以下を含めます。 import vertexai from vertexai import types from vertexai.agent_engines import AdkApp client = vertexai.Client( project= "PROJECT_ID" , location= "LOCATION" , http_options= dict (api_version= "v1beta1" ) ) app = AdkApp(agent=agent) # 新規作成するエージェントで Agent Identity を有効化する remote_app = client.agent_engines.create( agent=app, config={ "identity_type" : types.IdentityType.AGENT_IDENTITY, # Agent Identity を有効化 "requirements" : [ "google-cloud-aiplatform[agent_engines,adk]" ], }, ) 既存のエージェントを更新して Agent Identity を有効化する場合は、 update() を使用します。 # 既存のエージェントで Agent Identity を有効化する remote_app = client.agent_engines.update( name=resource_name, config={ "identity_type" : types.IdentityType.AGENT_IDENTITY, }, ) エージェントには projects/<プロジェクト番号>/locations/<ロケーション>/reasoningEngines/<エンジンID> 形式のリソース名と、これに対応する SPIFFE ID が自動で割り当てられます。 Agent Runtime のエンジン ID は、コンソールから確認できるほか、以下のようなコマンドを使用して確認できます。 # Agent Runtime のエンジン ID を確認する $ curl -X GET \ -H " Authorization: Bearer $( gcloud auth print-access-token ) " \ " https://<ロケーション>-aiplatform.googleapis.com/v1/projects/<プロジェクトID>/locations/<ロケーション>/reasoningEngines " \ | jq -r ' .reasoningEngines[] | select(.displayName == "<エージェントの表示名>") | .name | split("/") | last ' 例として、エージェントから Cloud Run サービスを呼び出すために、対象の Cloud Run サービスに roles/run.invoker ロールを付与するコマンドを以下に示します。エージェントの SPIFFE ID は principal:// プレフィックスで指定します。 # エージェントの SPIFFE ID に Cloud Run の呼び出し権限を付与する $ gcloud run services add-iam-policy-binding < Cloud Run サービス名 > \ --region =< リージョン > \ --member =" principal://agents.global.org-<組織ID>.system.id.goog/resources/aiplatform/projects/<プロジェクト番号>/locations/<ロケーション>/reasoningEngines/<エンジンID> " \ --role =" roles/run.invoker " Agent Identity を有効化したエージェントに権限を付与する 参考 : Authenticate using an agent's own authority 佐々木 駿太 (記事一覧) クラウドソリューション部 クラウドエンジニアリング1課 北海道在住 大学院まで社会心理学を専攻し、AI に興味を持ち IT 業界へ。2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出（2024 / 2025 Fellow / 2026）。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。最近は法律の勉強にも目覚め、2級知的財産管理技能士を取得。 Follow @sasashun0805

G-gen の川村です。Google Workspace の生成 AI ツールである Gemini アプリや NotebookLM を安全に運用するためのセキュリティ設定や、管理者が注意すべき点について解説します。 はじめに 概要 付属の生成 AI ツール 生成 AI ツールの外部共有機能 エンタープライズグレードのデータ保護 機能へのアクセス制御 生成 AI サービスのアクセス制御 サイドパネルのアクセス制御 CAA によるゼロトラスト制御 シャドー IT 対策と端末管理 シークレットウィンドウの使用禁止 ウェブプロキシによる個人アカウントの使用禁止 GCPW のエンドポイント保護 Chrome Enterprise Premium によるブラウザのポリシー強化 データ共有範囲の最適化 Google ドライブの共有設定 DLP でのデータ漏洩防止 IRM でのデータ持ち出し無効化 AI 分類機能 クライアントサイド暗号化の適用 運用・監査・データ保持 会話履歴の削除とデータ保持の管理 Google Vault によるデータ保持と検索 保持ポリシーの適用 データ検索 モニタリング・ログ管理 Gemini レポート Google Workspace with Gemini のログイベント AI コントロールセンター はじめに 概要 Google Workspace では Gemini アプリや NotebookLM などの生成 AI 機能が標準搭載されています。Google Workspace の生成 AI ツールにはエンタープライズグレードのデータ保護機能が標準で適用されていますが、組織のセキュリティポリシーやガバナンス要件に応じて、最適な環境を構築することが重要です。 管理者が意識すべき、セキュリティ対策のポイントは以下の通りです。 機能へのアクセス制御 シャドー IT 対策と端末管理 データ共有範囲の最適化 運用・監査・データ保持 当記事では、Google Workspace で上記のポイントを実現するための管理設定について紹介します。 付属の生成 AI ツール 2026年6月現在、以下のような生成 AI ツールが Google Workspace のコアサービスとして使用できます。今後もアップデートによりコアサービスが追加される可能性があります。 対象サービス 機能 特徴 Gemini アプリ 質問応答、文章生成、アイデア出し Web ブラウザやモバイルアプリからアクセスして使用できる対話型生成 AI サービス NotebookLM 要約、FAQ、メモの生成 アップロードしたドキュメントや PDF などのソース情報を基に回答する生成 AI サービス Google Workspace with Gemini サイドパネルでの生成 AI 補助 Gmail や Google ドライブなどのアプリケーション内で直接使用可能 Google Workspace Studio 生成 AI でのワークフローの作成 プログラミングなしで、自社の業務に合わせた生成 AI 搭載の自動化ワークフローを構築できる環境 Google Vids 動画作成・編集 生成 AI 支援でビジネス向けの動画やプレゼンテーションを容易に作成・編集できるツール 参考 : Google Workspace 利用規約 - Google Workspace 各サービスの基本機能については、以下の記事を参照してください。 blog.g-gen.co.jp 生成 AI ツールの外部共有機能 また、生成 AI によって業務が効率化できる一方、管理者が特に注意すべき 外部共有に関連する機能 が各生成 AI ツールに実装されています。以下の機能一覧を参照し、改めて組織のセキュリティポリシーに沿った設定になっているか見直すことを推奨します。 対象サービス 機能 特徴 Gemini アプリ 会話の共有 チャット内容の 外部公開機能 。組織外へのチャット履歴共有をユーザーに許可する。 Gemini アプリ Gems カスタムプロンプトの共有機能。データは Google ドライブに保存され、既存の 外部共有ポリシーが適用 される。 Google Meet Google AI によるメモの共有 作成した 議事録のデフォルトの共有先 の設定。組織外のゲスト / 組織内のゲスト / 主催者 から選択する。 NotebookLM ノートブックの共有 ソース資料のドライブ権限を問わない組織内共有機能 。ノートブックへのアクセス権のみでソース情報を確認できる。(※1) ※1 : NotebookLM のノートブック自体を外部共有することはできません。 エンタープライズグレードのデータ保護 Google Workspace ユーザーの場合、 エンタープライズグレードのデータ保護 がデフォルトで適用されています。そのため、プロンプトを含むユーザーの入力データが Google の AI モデルの学習に使用されたり、人間のレビュアーによって内容を確認されることは ありません 。 参考 : Generative AI in Google Workspace Privacy Hub | Google Workspace with Gemini | Google Workspace Help ただし、組織内での過剰な共有設定や個人アカウントの利用といったリスクには、管理者が別途対策を講じる必要があります。ここからは、セキュリティ維持のために、管理者として理解すべき機能や設定について解説します。 機能へのアクセス制御 生成 AI サービスのアクセス制御 Google Workspace で生成 AI 機能を有したサービスを使用する場合、 グループ単位や組織部門単位でのサービスへのアクセス制御が可能 です。全社展開でなく、パイロット運用として一部の組織部門から展開する場合などに設定します。 管理コンソールの「生成 AI」メニューから、以下の各サービスの「サービスのステータス」を、グループ、もしくは組織部門単位でオンまたはオフにします。 Gemini アプリ NotebookLM Gemini Enterprise（Google Workspace データへのアクセス制御） 参考 : Turn the Gemini app on or off | Google Workspace with Gemini | Google Workspace Help また、以下の各サービスについては、「アプリ」>「Google Workspace」からステータスを変更できます。 Workspace Studio Google Vids （「ドライブとドキュメントの設定」箇所から可能） サイドパネルのアクセス制御 Enterprise Standard 以上のエディションの場合、Gmail、Google ドライブなどの各アプリケーションで提供される Google Workspace with Gemini （サイドパネル）機能に対するアクセス制御も可能です。「生成 AI」メニューの「Google Workspace with Gemini」の項目から個別にオンまたはオフにできます。 参考 : Manage access to Gemini features in Workspace services | Google Workspace with Gemini | Google Workspace Help CAA によるゼロトラスト制御 Google Workspace の Context-Aware Access を使用すると、IP アドレスや端末の状態に基づいて、Gemini アプリや NotebookLM などの Google Workspace コアアプリへのアクセスを細かく制御できます。 たとえば、社外からの生成 AI の使用を禁止するために「社内 IP アドレス、かつデバイス承認が完了している端末からのアクセスのみ、Gemini アプリの使用を許可する」といった複合条件を設定できます。 blog.g-gen.co.jp シャドー IT 対策と端末管理 シークレットウィンドウの使用禁止 セキュリティポリシーによっては、シークレットウィンドウを無効化することでユーザーのブラウザ環境を常に管理下の状態に保ち、抜け道を使用したデータの持ち出しやシャドー IT の試行を防ぐことができます。 管理コンソールの「デバイス」>「Chrome」>「設定」> 「ユーザーとブラウザの設定」 箇所から適用できます。 参考 : Chrome ブラウザ ポリシーを管理する - 組織の Chrome デバイスを管理する ウェブプロキシによる個人アカウントの使用禁止 個人の Google アカウント（ @gmail.com ）を使用してコンシューマー向けの無償版 Gemini アプリが使用されてしまうと、データは Google により再学習等に使用されてしまう可能性があります。 ChromeOS で自組織の社内ネットワークのウェブプロキシサーバーを使用している場合、これを防ぐためにウェブプロキシサーバーにおけるドメイン制限をかけることができます。プロキシサーバー側で HTTP ヘッダー（ X-GoogApps-Allowed-Domains ）を追加し、これを Google 側でチェックすることで、ログイン可能なドメインを自社ドメインに限定でき、個人のアカウントの使用を防ぐことができます。 参考 : 一般ユーザー向けアカウントからのサービス利用を防ぐ | Security & data protection | Google Workspace Help GCPW のエンドポイント保護 Windows 端末を使用している環境では、 Google Credential Provider for Windows （通称、GCPW）を導入することも効果的です。 GCPW により、Windows 端末へのログイン時に Google Workspace アカウントを使用できます。ログインと同時に Google Chrome ブラウザの仕事用プロファイルに自動でログイン状態が引き継がれるため、仕組みとして会社アカウントの使用を徹底できます。 また、Windows ログイン時に Google の 2 段階認証が適用されセキュリティを向上させます。 参考 : Windows 用 Google 認証情報プロバイダをインストールする | Device management | Google Workspace Help Chrome Enterprise Premium によるブラウザのポリシー強化 ユーザーが Chrome ブラウザ上でプロンプトに組織の機密情報をアップロードしたり、コードをペーストしたりする操作自体をブラウザレベルで禁止したい場合は、 Chrome Enterprise Premium が使用できます。 追加ライセンスを購入して Chrome Enterprise Premium を設定することで、特定の Web ページに対するファイルのアップロードやコピー＆ペーストのブロックなど、高度な データ漏洩防止ポリシー を Chrome ブラウザに強制できます。 blog.g-gen.co.jp データ共有範囲の最適化 Google ドライブの共有設定 Gemini アプリは、 操作ユーザーがアクセス権を持つ Google ドライブ上のファイルを参照 して回答を生成します。そのため、Google ドライブの権限管理が適切に行われている必要があります。 たとえば、人事部が社員の給与テーブルを「組織全員」に公開した状態で保存していると、本来権限を持つべきでない従業員が Gemini に質問するだけで、その機密情報が回答に含まれてしまうリスクがあります。 これは生成 AI の導入によるリスクではなく、そもそも従業員がアクセスすべきでないファイルにアクセスできる状態であり、Google ドライブの権限管理自体の不備に起因するものです。生成 AI の導入を機に、過剰な共有設定の棚卸しを実施してください。 適切な権限管理を行うには、「共有ドライブ」でのデータ運用が不可欠です。共有ドライブの仕組みや権限整理の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp DLP でのデータ漏洩防止 Data Loss Prevention （以下、DLP）は、Enterprise Standard 以上のエディションで使用でき、クレジットカード番号やマイナンバーなどの機密情報を自動検出し、組織外への情報流出を防ぐ技術です。 blog.g-gen.co.jp DLP ルールは Gemini アプリ使用時にも適用 されます。例えば、DLP ルールでドライブ内の機密ファイルの外部共有を制限している場合、Gemini アプリで生成したコンテンツにもドライブの DLP が適用され、共有がブロックされます。そのため、ユーザーがコンテンツを明示的に共有しない限り、Gemini の使用によりデータが組織外に漏洩することはありません。 参考 : Generative AI in Google Workspace Privacy Hub - How can I prevent sensitive data entered into prompts from being leaked outside my organization? Do Workspace Data Loss Prevention (DLP) capabilities apply to interactions with Gemini? IRM でのデータ持ち出し無効化 Information Rights Management （以下、IRM）とは、Google ドライブ上のデータにおけるダウンロード、コピー、印刷を権限に基づいて無効化する機能です。IRM が適用されたファイルには各生成 AI ツールがアクセスできなくなるため、前述の DLP と組み合わせて IRM を自動適用する手法が有効です。 DLP ポリシーで機密ファイルを検知し、IRM を自動適用することで、Gemini アプリをはじめとする各種生成 AI 機能は、そのファイルをもとにした回答を 生成できなく なります。これにより、意図しない機密情報の参照を根本的に遮断できます。 参考 : ユーザーがファイルをダウンロード、印刷、コピーできないようにする | Security & data protection | Google Workspace Help 参考 : Google Workspace with Gemini におけるエンタープライズ セキュリティの管理 - IRM 制御を適用して Gemini から機密データへのアクセスを制限 参考 : Generative AI in Google Workspace Privacy Hub | Google Workspace with Gemini | Google Workspace Help - Do Workspace Data Loss Prevention (DLP) capabilities apply to interactions with NotebookLM? AI 分類機能 Enterprise Plus では AI を使用したデータ分類機能 が使用できます。 Google ドライブ内のファイルをスキャンして、自動的に機密ファイルにラベルを付与できます。 通常の DLP との違いは、事前定義されたルールでは判断できない曖昧な内容を AI でパターン化して分類できる点です。このラベルをもとに DLP ルールを適用することで、組織でのデータ保護管理が容易になります。 参考 : Label Google Drive files automatically using AI classification | Security & data protection | Google Workspace Help クライアントサイド暗号化の適用 Enterprise Plus 以上のエディションでは、機密データや規制対象データをさらに厳重に保存したい場合に、 クライアントサイド暗号化 の機能を使用できます。 Google Workspace の組織のデータはデフォルトで暗号化されていますが、組織で独自の暗号鍵を使用して暗号化のレイヤを追加できる機能です。 クライアントサイド暗号化されたコンテンツは Google やサードパーティで復号できず、Gemini アプリなどの 生成 AI ツールもアクセスできません 。そのため、センシティブなデータを取り扱う政府機関や大規模な組織への導入に有効です。 参考 : Google Workspace の生成 AI に関するプライバシー ハブ | Google Workspace with Gemini | Google Workspace Help ‐ 自組織内の他の部署に機密情報が漏洩しないようにするために、Google ではどのような手法を採り入れていますか？ 運用・監査・データ保持 会話履歴の削除とデータ保持の管理 ユーザーによる会話履歴データの削除可否、データの保持期間はプロダクトの仕様によって異なります。 2026年6月現在、Google Workspace ユーザーの場合、 Gemini アプリではユーザーが個別に会話履歴を削除することはできません 。管理コンソールの「Gemini 会話履歴」をオンに設定した場合、ユーザーの会話履歴が強制的に保存され、オフにするとシステム内で最大 72 時間保持された後に削除されます。 一方、 Google Workspace with Gemini （サイドパネル）での会話履歴は、管理コンソールの 「会話の履歴と削除」設定から ユーザーでの削除操作を許可 できます。 また、 NotebookLM では管理者での制御なしに、チャット履歴やソースとしてアップロードしたファイル・作成したノートブックに対する ユーザーでの削除操作が可能 です。 これらの各生成 AI ツールにおける、データ保持期間や制御可否については以下の表の通りです。 対象サービス データ型 保持期間 管理者 ユーザー Google Workspace with Gemini（サイドパネル） プロンプトと回答 90 日から無制限 ユーザーでの削除可否を制御 組織で許可されている場合、削除可能 Gemini アプリ プロンプトと回答 最大 36 か月 保存有無や自動削除期間を制御 削除不可 NotebookLM プロンプトと回答 - なし 削除可能 ソースデータ / ノートブック 条項第 6 条に準拠 * なし 削除可能 参考 : Cloud Data Processing Addendum | Google Cloud 参考 : Google Workspace での生成 AI のプライバシー ハブ - Gemini データの保持 参考 : Chat in NotebookLM: A powerful, goal-focused AI research partner Google Vault によるデータ保持と検索 保持ポリシーの適用 Gemini アプリのデータ保持については、管理コンソール内の「Gemini 会話履歴」の設定が Google Vault にも適用 されます。保存期間を「3 か月」「18 か月」「36 か月」から選択でき、期間内でのデータ保持・検索ができます。 Google Meet で生成 AI が作成する議事録は、Google Meet の保持ポリシーに準拠します。なお、Google Meet 固有のルールが有効になっていない場合はドライブのルールが適用されます。 参考 : サポートされているサービスとデータタイプ - Google Vault ヘルプ - Vault でサポートされるドライブと Meet のファイル データ検索 Google Vault に「案件」を作成することで、Gemini アプリのプロンプト、回答内容、トピック、日時などの メタデータを検索・監査 できます。ただし、プロンプトに添付されたファイルや生成されたファイル自体の検索には現在対応していません。 案件の作成方法は、以下の記事を参照してください。 blog.g-gen.co.jp モニタリング・ログ管理 Gemini レポート 生成 AI ツールを導入した後は、誰がどのように使っているかを把握するための継続的な監査が重要です。「生成 AI」>「Gemini レポート」から確認できるレポートでは、組織全体の Gemini アプリ使用状況やアクティブユーザー数を可視化 できます。レポート情報はスプレッドシートや CSV でのエクスポートが可能です。 Google Workspace with Gemini のログイベント 「レポート」>「監査と調査」>「Google Workspace with Gemini のログイベント」から、ユーザーが各アプリケーションでのコンテンツの生成や要約を行った際の イベントログを確認 できます。例えば「特定のユーザーが過去1週間にどのような生成 AI 機能を使用したか」といった検索や調査、エクスポートが可能です。 AI コントロールセンター 「生成 AI」>「AI コントロール センター」から確認できる AI コントロール センターでは、組織内の生成 AI 使用に当たって 包括的にレポートや各生成 AI 機能の設定を確認 できます。適切な設定が行えているか、定期的にチェックすることを推奨します。 参考 : Explore the AI control center | Google Workspace with Gemini | Google Workspace Help 川村真理 (記事一覧) クラウドソリューション部 クラウドサポート課 美容業界からITへ転身。Google Workspace 専任サポートから Google Cloud にも興味が湧き日々奮闘中。海外旅行が大好きで11カ国突破、これからも更新予定

G-gen の三浦です。当記事では、Gemini CLI から Antigravity CLI への移行を検証し、移行後に簡単な Web アプリを作成して Cloud Run へデプロイした結果を紹介します。 前提知識 Google Antigravity とは Antigravity CLI とは Gemini CLI の提供終了と Antigravity CLI への移行 概要 Antigravity CLI と Gemini CLI の違い 移行作業の対象 検証手順 移行検証用の設定 概要 Agent Skills MCP サーバー Extensions Antigravity CLI のインストールと初期設定 インストールと認証 その他の初期設定 設定の移行 Extensions の移行 Agent Skills の読み込み確認 MCP サーバーの手動移行 動作確認（開発とデプロイ） 前提知識 Google Antigravity とは Google Antigravity （以下、Antigravity）は、自然言語による指示でコードの生成、修正、実行、検証などを AI エージェントに任せられる開発プラットフォームです。このように、AI エージェントを駆使した開発スタイルは バイブコーディング （vibe coding）とも呼ばれます。 参考 : Welcome to Google Antigravity 参考 : vibe コーディングとは 2026年2月執筆時点の内容ですが、以下の記事で Antigravity を検証していますので参照してください。 blog.g-gen.co.jp Antigravity CLI とは Antigravity CLI は、Antigravity のエージェント機能をターミナルから利用できるコマンドラインツールです。 agy コマンドを通じて自然言語で指示し、コード生成、修正、調査、検証、デプロイなどを進められます。 参考 : Google Antigravity CLI Gemini CLI の提供終了と Antigravity CLI への移行 概要 Google は、個人利用者向けの Gemini CLI を Antigravity CLI へ移行する方針を発表しました。これに伴い、 2026年6月18日 以降、個人向け利用区分で使用している Gemini CLI および Gemini Code Assist の IDE 拡張機能では、リクエストが処理されなくなります。 参考 : An important update: Transitioning Gemini CLI to Antigravity CLI 提供が終了するのは個人向けの利用区分です。組織向けの Gemini Code Assist Standard / Enterprise ライセンスで利用している場合は、引き続き利用できます。 利用区分ごとの影響と対応方針は以下のとおりです。 利用区分 2026年6月18日以降 対応方針 無料（Gemini Code Assist for individuals） 利用不可 Antigravity CLI へ移行 Google AI Pro 利用不可 Antigravity CLI へ移行 Google AI Ultra 利用不可 Antigravity CLI へ移行 Gemini Code Assist Standard / Enterprise 影響なし（継続利用可能） 対応不要 Antigravity CLI と Gemini CLI の違い Antigravity CLI と Gemini CLI は、いずれもターミナル上で AI エージェントに開発作業を依頼できる CLI ツールですが、Antigravity CLI は Antigravity のエージェント基盤を利用しており、Gemini CLI とはコマンド名や一部の設定構成が異なります。 主な違いは以下のとおりです。 項目 Gemini CLI Antigravity CLI 起動コマンド gemini agy 利用モデル Gemini 系モデル Antigravity で提供される複数モデルから選択可能 拡張機能 Extensions plugins MCP サーバー settings.json で設定 mcp_config.json で設定 参考 : Antigravity CLI Features 参考 : Migrating from Gemini CLI 移行作業の対象 移行作業の対象となるのは、主に以下の設定です。 移行対象 移行作業 Antigravity CLI での扱い Agent Skills（グローバル） 不要 ~/.gemini/skills/ の skill はそのまま読み込まれる Agent Skills（ワークスペース） 要 <プロジェクト>/.gemini/skills/ から <プロジェクト>/.agents/skills/ へ手動で移行する Extensions 要 agy plugin import gemini で plugin として移行される MCP サーバー 要 手動で移行する システムプロンプト（ GEMINI.md ） 不要 そのまま読み込まれる 参考 : Migrating from Gemini CLI 検証手順 検証手順は以下のとおりです。Gemini CLI から Antigravity CLI へ移行し、移行後の環境で Web アプリケーションを Cloud Run にデプロイします。 項番 内容 説明 1 インストールと初期設定 Antigravity CLI をインストールし、セットアップを実施します。 2 Gemini CLI からの移行 Agent Skills、Extensions、MCP サーバーの移行状況を確認します。 3 Web アプリの作成と Cloud Run へのデプロイ 移行後の環境から、 agy で Web アプリを Cloud Run へデプロイします。 当記事の検証で使用した環境は以下のとおりです。 項目 値 OS Windows 11 Pro 実行環境 WSL2（Ubuntu） 移行元 Gemini CLI バージョン 0.44.1 Antigravity CLI バージョン 1.0.3 移行検証用の設定 概要 Gemini CLI から Antigravity CLI への移行を確認するため、移行元の Gemini CLI に skill、MCP サーバー、Extensions を用意します。これらの設定が Antigravity CLI 側でどのように引き継がれるかを確認します。 Agent Skills Agent Skills は、AI エージェントに専門的な手順や知識を追加するための機能です。skill は配置する場所によって移行作業の要否が変わるため、当検証ではグローバルとワークスペースの両方を用意します。 参考 : Agent Skills グローバル グローバル（ ~/.gemini/skills/ ）に配置した skill は、Antigravity CLI からもそのまま読み込まれるため、移行作業は不要です。ここでは、Flask で Web アプリの雛形を作成する skill を用意します。 --- name: flask-webapp description: Flask で簡単な Web アプリを作成する手順。Web アプリの雛形を作りたいときに使う。 --- 　 # Flask Web アプリ作成 　 1. `requirements.txt` に flask と gunicorn を記載する。 2. `main.py` にルーティングとエンドポイントを定義する。 3. 環境変数 `PORT` を参照してリッスンする（Cloud Run 対応）。 4. ローカルで起動し、ブラウザで表示を確認する。 Gemini CLI に Agent Skills が登録されていることを確認します。 $ gemini skill list 　 flask-webapp [ Enabled ] Description: Flask で簡単な Web アプリを作成する手順。Web アプリの雛形を作りたいときに使う。 Location: /home/miurak/.gemini/skills/flask-webapp/SKILL.md ワークスペース プロジェクトごとのワークスペース（ <プロジェクト>/.gemini/skills/ ）に配置した skill は、Antigravity CLI 用のディレクトリ（ <プロジェクト>/.agents/skills/ ）へ手動で移動する必要があります。ここでは、移行を確認するための skill を用意します。 --- name: hello-workspace description: ワークスペースに配置した移行確認用のサンプル skill。 --- 　 # ワークスペース skill 　 1. ワークスペースの移行確認用のサンプルです。 Gemini CLI に Agent Skills が登録されていることを確認します。 $ gemini skill list 　 ～省略～ 　 hello-workspace [ Enabled ] Description: ワークスペースに配置した移行確認用のサンプル skill。 Location: < プロジェクト > /.gemini/skills/hello-workspace/SKILL.md MCP サーバー MCP サーバー は、AI エージェントに外部サービスやツールを操作するための機能を提供するサーバーです。当検証では、Google が提供している Cloud Run のリモート MCP サーバーを使用します。 参考 : MCP servers with Gemini CLI 参考 : Google Cloud MCP servers overview 参考 : Cloud Run リモート MCP サーバーを使用する Gemini CLI に MCP サーバーが登録されていることを確認します。 $ gemini mcp list 　 ✓ cloud-run: https://run.googleapis.com/mcp ( http ) - Connected Extensions Extensions は、Gemini CLI に機能を追加するための拡張機能です。当検証では、AI エージェントがライブラリの最新ドキュメントやコード例を参照できるように、 Context7 を利用します。 参考 : Build Gemini CLI extensions 参考 : Context7（Gemini CLI Extensions） Gemini CLI に Extensions が登録されていることを確認します。 $ gemini extensions list 　 ✓ context7 ( 1 . 0 . 0 ) ～省略～ Antigravity CLI のインストールと初期設定 インストールと認証 公式ドキュメントに従い、Antigravity CLI をインストールします。WSL（Linux）の場合、以下のコマンドでインストールします。 curl -fsSL https://antigravity.google/cli/install.sh | bash 　 ⠋ Detecting system environment... ✓ Platform detected: linux_amd64 ⠋ Querying release repository... ✓ Latest available version: 1 . 0 . 3 ⠋ Downloading release package... ✓ Download complete and checksum verified. ⠋ Extracting binary from archive... ⠋ Configuring shell environment... 　 ✅ Antigravity CLI installed successfully at /home/miurak/.local/bin/agy Run ' agy ' to start the CLI 以下のコマンドで Antigravity CLI を実行します。 $ agy 初回起動時には、ログイン方式を選択します。当検証では 1. Google OAuth を選択します。 ログイン方式 紐づけ先 Google OAuth Google アカウント Use a Google Cloud project Google Cloud プロジェクト 　 　 ▄▀▀▄ ▀▀▀▀▀▀ ▀▀▀▀▀▀▀▀ ▄▀▀ ▀▀▄ ▄▀▀ ▀▀▄ 　 Welcome to the Antigravity CLI. You are currently not signed in . 　 Select login method: > 1 . Google OAuth 2 . Use a Google Cloud project 　 [ Use arrow keys to navigate, Enter to select ] 　 参考 : Installation & auth 参考 : Getting Started with Antigravity and Gemini Enterprise Agent Platform ブラウザが起動するので、Google アカウントを選択します。 Google アカウントの選択 認証コードが表示されるので、ターミナルに戻ってコードを貼り付け、Enter キーを押します。 　 If you aren ' t automatically redirected, paste the authorization code below: 　 ★コードをペーストする★ 　 その他の初期設定 テーマを選択します。当検証では terminal を選択しました。また、同じ画面の下部に Gemini CLI からの移行オプションが表示されていたため、 Import extensions from Gemini CLI を選択し、 Next を選択します。 　 Welcome to Antigravity CLI! 　 Choose your color scheme: ╭─────────────────────────────────────────────────────────────╮ │ > you: add a greeting function │ * terminal │ │ light │ Here ' s the change: │ solarized light │ │ colorblind-friendly light │ 3 import "fmt" │ dark │ 4 │ solarized dark │ 5 - func main() { │ colorblind-friendly dark │ 5 + func greet(name string) { │ tokyo night │ 6 + fmt.Printf("Hello, %s!\n", name) │ │ 7 } │ │ │ │ ▾ Thought Process │ │ I need to add a greeting function. I ' ll use fmt.Printf. │ │ ⚙ tool: write_file main.go │ │ ◉ task: Implementing greeting │ │ ✗ error: compilation failed │ │ ⚠ warning: deprecation warning │ │ → link: file:///path/to/main.go │ │ ★ accent: highlighted text │ │ · dim: press Enter to continue │ ╰─────────────────────────────────────────────────────────────╯ 　 Migration options: 　 [ x ] Import extensions from Gemini CLI ( 1 found: context7 ) 　 > Next 　 ↑/↓ Navigate · enter Confirm 　 次に、利用規約とデータ利用に関する確認画面が表示されます。Interactions data は Antigravity CLI とのやり取りに関するデータです。当検証では、収集・利用に同意するチェックボックスが選択されていたため、チェックを外して Done を選択しました。 　 Terms of Service & Data Use 　 AI coding agents are known to have certain security risks, including autonomous code execution, data exfiltration, prompt injection and supply chain risks. Ensure that you monitor and verify all actions taken by the agent. 　 ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 　 [ ] Yes, I agree to help improve Antigravity CLI by allowing Google to collect and use my Interactions data, subject to the Google Antigravity CLI Terms of Service and Google Privacy Policy. I understand I can choose to opt out later whenever I want via my settings. 　 Links: - Terms of Service: https://antigravity.google/terms - Privacy Policy: https://policies.google.com/privacy 　 [ Previous ] > Done 　 　 ↑/↓ Navigate · enter Confirm 　 　 現在の作業フォルダを信頼するかどうかの確認画面が表示されるので、 Yes, I trust this folder を選択します。 Accessing workspace: 　 /home/miurak/work/develop/blog 　 Do you trust the contents of this project? 　 Antigravity CLI requires permission to read , edit, and execute files here. 　 > Yes, I trust this folder No, exit 　 ↑/↓ Navigate · enter Confirm 　 初期設定は以上です。 設定の移行 Extensions の移行 インストール時に Import extensions from Gemini CLI を選択しましたが、当検証環境ではインストール直後に agy plugin list で確認したところ、import 済みの plugin は1件も表示されませんでした（2026年5月現在の検証状況）。 $ agy plugin list No imported plugins. そのため、明示的に以下のコマンドを実行し、Gemini CLI の Extensions を Antigravity CLI の plugin へ移行しました。 $ agy plugin import gemini [ ok ] context7 ✔ skills : 3 processed - agents : skipped ( not found ) - commands : skipped ( not found ) ✔ mcpServers : 1 processed - hooks : skipped ( not found ) 　 Staged to /home/miurak/.gemini/config 　 以下のコマンドで移行されていることを確認します。 $ agy plugin list { " imports " : [ { " name " : " context7 " , " source " : " gemini-cli " , " importedAt " : " 2026-05-30T03:02:51Z " , " components " : [ " skills " , " mcpServers " ] } ] } ここで表示されている skills および mcpServers は、Context7 plugin に同梱されている設定です。事前準備した移行検証用の skill や MCP サーバーとは別物です。 参考 : Migrating from Gemini CLI Agent Skills の読み込み確認 Antigravity CLI を起動し、 /skills コマンドで移行検証用の skill が表示されることを確認します。 グローバル（移行不要） グローバルに配置した flask-webapp は、移動なしで Shared skills に表示されました。 /skills 　 Skills 4 skills 　 Create new skills Workspace: ~/work/develop/blog/.agents/skills/ { skill_name } /SKILL.md Global: ~/.gemini/antigravity-cli/skills/ { skill_name } /SKILL.md Shared: ~/.gemini/skills/ { skill_name } /SKILL.md 　 Shared skills · From ~/.gemini/skills flask-webapp: Flask で簡単な Web アプリを作成する手順。Web アプリの雛形を作りたいときに使う。 　 /home/miurak/.gemini/antigravity-cli/plugins/context7/skills · From ~/.gemini/antigravity-cli/skills.json 　 ～省略～ 　 ワークスペース（手動移行） ワークスペースの hello-workspace は、移動前のためまだ表示されていません。Gemini CLI のディレクトリ（ <プロジェクト>/.gemini/skills/ ）から Antigravity CLI 用のディレクトリ（ <プロジェクト>/.agents/skills/ ）へ移動します。 $ mkdir -p .agents/skills $ mv .gemini/skills/hello-workspace .agents/skills/hello-workspace 再度 /skills コマンドで確認すると、 hello-workspace が Workspace skills に表示されました。 /skills 　 Skills 5 skills 　 Create new skills Workspace: ~/work/develop/blog/.agents/skills/ { skill_name } /SKILL.md Global: ~/.gemini/antigravity-cli/skills/ { skill_name } /SKILL.md Shared: ~/.gemini/skills/ { skill_name } /SKILL.md 　 Workspace skills · Workspace config hello-workspace: ワークスペースに配置した移行確認用のサンプル skill。 　 Shared skills · From ~/.gemini/skills flask-webapp: Flask で簡単な Web アプリを作成する手順。Web アプリの雛形を作りたいときに使う。 　 /home/miurak/.gemini/antigravity-cli/plugins/context7/skills · From ~/.gemini/antigravity-cli/skills.json 　 ～省略～ 　 MCP サーバーの手動移行 Gemini CLI と Antigravity CLI では MCP の設定形式が異なるため、Cloud Run のリモート MCP サーバーは Antigravity CLI の MCP 一覧に表示されませんでした。そのため、手動で移行します。 /mcp 　 MCP Servers 　 Plugins ( ~/.gemini/antigravity-cli/plugins ) > ✓ context7 Tools: resolve-library-id, query-docs 　 移行元の Gemini CLI 側（ ~/.gemini/settings.json ）の記述は以下のとおりです。 { " mcpServers ": { " cloud-run ": { " httpUrl ": " https://run.googleapis.com/mcp ", " headers ": { " Authorization ": " Bearer ${ACCESS_TOKEN} " } } } } Antigravity CLI 側の MCP 設定ファイル（当検証環境では ~/.gemini/config/mcp_config.json ）に、以下の内容を配置します。Gemini CLI の httpUrl は、Antigravity CLI では serverUrl に変更します。 { " mcpServers ": { " cloud-run ": { " serverUrl ": " https://run.googleapis.com/mcp ", " headers ": { " Authorization ": " Bearer ${ACCESS_TOKEN} " } } } } Antigravity CLI を起動し、 /mcp コマンドで Cloud Run MCP サーバーが認識されていることを確認します。 /mcp 　 MCP Servers 　 Plugins ( ~/.gemini/antigravity-cli/plugins ) > ✓ cloud-run Tools: get_service, list_services, deploy_service_from_image, deploy_service_from_archive, deploy_service_from_file_contents ✓ context7 Tools: resolve-library-id, query-docs 参考 : Migrating from Gemini CLI 動作確認（開発とデプロイ） Antigravity CLI を起動し、以下のプロンプトで Web アプリの作成と Cloud Run へのデプロイを依頼します。 現在時刻を表示する簡単な Flask の Web アプリを作成し、Cloud Run にデプロイして公開 URL を教えてください。 現在時刻（日本時間: JST）を表示する Flask の Web アプリケーションを作成し、Google Cloud Run にデプロイしました。 　 公開 URL: https://time-app-XXXXXX.asia-northeast1.run.app 　 アプリケーションの概要: - JST の現在時刻を表示 - ブラウザ上で 1 秒ごとに時刻を更新 - Cloud Run の `PORT` 環境変数に対応 表示された公開 URL へアクセスし、Web ページが表示されることを確認します。 Web ページの確認 三浦 健斗 (記事一覧) クラウドソリューション部 2023年10月よりG-genにジョイン。元オンプレ中心のネットワークエンジニア。 ネットワーク・セキュリティ・唐揚げ・辛いものが好き。 Google Cloud Partner All Certification Holders 2025 / Google Cloud Partner Top Engineer 2026

G-gen の杉村です。2026年5月に発表された、Google Cloud や Google Workspace のイチオシアップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに Google I/O 2026 が開催 Google Cloud のアップデート SCC で Compliance Manager がプロジェクト単位で有効化可能に Agent Search で agentic retrieval が Allowlist 付き一般公開 BigQuery の reservation groups が一般公開（GA） Google Cloud で Certificate Manager (2nd gen) が Preview 公開 NotebookLM Enterprise でスライド作成/インフォグラフィックが使用可能に 新機能 Skill Registry が登場（Preview） 新機能 AI Content Detection API が登場（Private Preview） 新機能 Managed Agents API が登場（Preview） Gemini 3.5 Flash が登場（GA） AI 統合型開発ツール「Antigravity」が一新 Antigravity 2.0 が Google Cloud 認証に対応 BigQuery の Python UDF（ユーザー定義関数）が Preveiew → 一般公開（GA） Security Command Center (Premium) で Artifact guard が Preview 公開 Security Command Center の Enterprise ティアが提供終了へ Knowledge Catalog の Data products 機能が一般公開（GA） Gemini Deep Research Agent が Preview 公開 Gemini Enterprise app で Slack データストアが一般公開（GA） Nano Banana 2 と Nano Banana Pro が一般公開（GA） gemini-2.5-flash、gemini-3-flash-preview 等が新規利用の受付停止 Google Workspace のアップデート Google ドキュメントの Gemini でカスタムインストラクションを設定可能に Gemini アプリで会話結果から各種ファイルを直接生成可能に Google Workspace の公式リモート MCP サーバーが Public Preview 公開 Google Workspace Studio の Google Meet 関連が強化 Gmail の Help me write（文章作成補助）機能が強化 Google Workspace Studio で Ask NotebookLM が使えるようになった Google Chat のメッセージ推敲が日本語を含む多言語に対応 NotebookLM で Google ドライブとの自動同期が可能に はじめに 当記事では、毎月の Google Cloud（旧称 GCP）や Google Workspace（旧称 GSuite）のアップデートのうち、特に重要なものをまとめます。 また当記事は、Google Cloud に関するある程度の知識を前提に記載されています。前提知識を得るには、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp リンク先の公式ガイドは、英語版で表示しないと最新情報が反映されていない場合がありますためご注意ください。 Google I/O 2026 が開催 100 things we announced at I/O 2026 (2026-05-19 〜 2026-05-20) Google の開発者向け年次カンファレンス「Google I/O」が開催。以下のような発表がされた。 Gemini 3.5 Flash : Gemini 3.5 ファミリーが発表。Flash モデルを先行投入（Preview ではなく一般公開） Gemini Omni : 動画生成モデル。編集も可能で動画版 Nano Banana といえる Gemini Spark : バックグラウンド動作する AI エージェントサービス。まず米国の Google AI Ultra サブスクリプション 登録者向けに提供 Google Antigravity : 機能が一新され Antigravity 2.0 となった。Antigravity CLI も発表 Google Cloud のアップデート SCC で Compliance Manager がプロジェクト単位で有効化可能に Enable Compliance Manager (2026-05-11) Security Command Center で Compliance Manager がプロジェクト単位で有効化可能になった。 Compliance Manager は CIS や ISO 27001 といったセキュリティ標準への適合性をチェックできる機能。これまで組織レベルでしか使用できなかった。 Agent Search で agentic retrieval が Allowlist 付き一般公開 Stream answers using agentic retrieval (2026-05-13) Agent Search（旧 Vertex AI Search）で agentic retrieval（streamAnswer メソッド）が Allowlist 付き一般公開。 エージェンティックに複数のデータストアに対して検索。回答はストリーミングで取得。ソースコードを開発することなく、容易に検索エージェントを構築できるのが利点。 BigQuery の reservation groups が一般公開（GA） Prioritize idle slots with reservation groups (2026-05-18) BigQuery の reservation groups が一般公開（GA）。 Idol slot が生まれたときに、他の reservation に貸し出す前に、まずは同一グループ内の reservation へ優先的に割り当てる。より緻密なスロット制御が可能になった。 Google Cloud で Certificate Manager (2nd gen) が Preview 公開 Certificate Manager (2nd gen) overview (2026-05-19) Google Cloud で Certificate Manager (2nd gen) が Preview 公開。 SSL/TLS 証明書の管理サービスの次世代版。ロードバランサー向けだった1st gen に比べてGKE、Compute Engine、ハイブリッド環境への対応が強化。有効期限の一覧表示ビューなども提供。 NotebookLM Enterprise でスライド作成/インフォグラフィックが使用可能に Gemini Enterprise release notes ‐ May 19, 2026 (2026-05-19) NotebookLM Enterprise（Gemini Enterprise appに付属）でスライド作成とインフォグラフィック機能が使用可能になった（GA）。 Google Workspace 版や個人版 NotebookLM との差異が1つなくなり、用途が広くなった。 新機能 Skill Registry が登場（Preview） Skill Registry overview (2026-05-19) Gemini Enterprise Agent Platform の一部として、新機能 Skill Registry が登場（Preview）。 Agent Skills 用のレポジトリ。Skill を zip して base64 エンコードしてアップロードできる。組織内で Skills を効果的に共有し、車輪の再開発を防ぐことができる。 新機能 AI Content Detection API が登場（Private Preview） Detect AI-generated images (2026-05-19) Gemini Enterprise Agent Platform の一部として、新機能 AI Content Detection API が登場。 Private Preview なので要申請。AI で生成された画像を検知できる API。形式は JPEG、PNG、WebP に対応。 あくまで推定を提供するものなので注意が必要。 新機能 Managed Agents API が登場（Preview） Managed Agents API on Agent Platform overview (2026-05-19) Gemini Enterprise Agent Platform の一部として、新機能 Managed Agents API が登場（Preview）。 エージェントをクラウドのサンドボックス内で実行。システムインストラクション、ツール、コード実行などをパッケージして保存し、いつでも呼び出せる。 ドキュメントに以下が明記されている（機械翻訳）。 （略）現在様々な段階の社内テストおよびレビューを受けています。そのため、これらの製品で機密情報、秘密情報、またはその他の機密データを使用しないでください。これらの製品は、限定的なテストおよび評価のためにのみお客様に提供されており、商用または本番環境での使用はできません。 Gemini 3.5 Flash が登場（GA） Gemini 3.5：行動を起こす最先端の知能 (2026-05-19) Gemini 3.5 Flash が登場（GA）。3.5 Pro も来月提供予定。 Gemini アプリや Gemini Enterprise app のほか、Agent Platform（旧 Vertex AI）や Google AI Studio から API 経由で利用可能。 Flash モデルながら 3.1 Pro を性能で凌駕するとされている。 Gemini 3.5 Flash 料金に注意が必要。Gemini 3 Flash Preview よりもトークンあたりの単価が高額になっている。 参考 : Cost of building and deploying AI models in Agent Platform AI 統合型開発ツール「Antigravity」が一新 エージェントが主導する未来の構築：Google I/O 2026 デベロッパー向けハイライト (2026-05-20) Google の AI 統合型開発ツール Antigravity が一新し、Antigravity 2.0 となった。 従来の Antigravity は IDE（エディタを含む統合開発環境）だったが、Antigravity 2.0 は Agent Manager 機能に専念したデスクトップアプリ。複数のエージェントを動作させるためのオーケストレーターとして動作する。Antigravity 2.0 は、他の IDE などと組み合わせて使われる想定。 旧来のようなエディタ画面を持つ IDE は、Antigravity IDE として提供され続ける。Antigravity IDE は、Agent Manager を搭載していない。 また、Antigravity CLI が提供開始され、Gemini CLI は廃止の方向になる。個人アカウントでは2026年6月18日には Gemini CLI が使えなくなる。Google Workspace の Gemini Code Assist では引き続き使える（EoS 明記なし）。 Antigravity 2.0 が Google Cloud 認証に対応 Google Antigravity in Gemini Enterprise (2026-05-20) Google の AI 統合型開発ツール「Antigravity 2.0」が Google Cloud 認証に対応。Google Cloud 利用規約が適用され、入出力データは再トレーニングに使用されない。 Gemini Enterprise Agent Platform（旧 Vertex AI）経由で LLM を呼び出す。LLM は従量課金。 今後も統制関係機能が追加予定。 BigQuery の Python UDF（ユーザー定義関数）が Preveiew → 一般公開（GA） Work with user-defined functions in Python (2026-05-20) BigQuery の Python UDF（ユーザー定義関数）が Preveiew → 一般公開（GA）。 これまでは SQL 版と JavaScript 版が GA だったが、Python 版も GA になった。PyPI や Cloud Storage 上のパッケージも使用可能。 Security Command Center (Premium) で Artifact guard が Preview 公開 Artifact guard overview (2026-05-21) Security Command Center Premium および Enterprise ティアで新機能 Artifact guard が Preview 公開。 ビルド中にポリシーに準拠しているかどうかをスキャン。脆弱性のあるパッケージがデプロイされるのを未然に防止。Cloud Build、GitHub Actions、Jenkins、GKE などに対応。 Security Command Center の Enterprise ティアが提供終了へ Security Command Center release notes ‐ May 21, 2026 (2026-05-21) Security Command Center の Enterprise ティアが提供終了へ。 2027-05-21 には終了して Premium ティアへ自動移行。Enterprise は、AWS や Azure の構成チェックもできる最上位ティアだった。 付属の SecOps（SIEM）などの件は営業チームと相談を。 Knowledge Catalog の Data products 機能が一般公開（GA） About data products (2026-05-25) Knowledge Catalog（旧 Dataplex Universal Catalog）で Data products 機能が Preview から一般公開（GA）になった。 データ管理者がデータを論理的にパッケージして利用者にキュレートできる。アクセスリクエストからの承認もフロー化できる。 Gemini Deep Research Agent が Preview 公開 Use the Gemini Deep Research Agent (2026-05-26) Gemini Deep Research Agent が Preview 公開。API（REST / SDK）経由で利用可能。 パブリック Web （Google 検索）や企業データ（MCP、Agent Search、ファイル添付）に基づいて包括的なレポートを生成する。進捗のストリーミング受信も可能。 Gemini Enterprise app で Slack データストアが一般公開（GA） Overview (2026-05-27) Gemini Enterprise app で Slack データストアが Private Preview → 一般公開（GA）。 Slack に対して検索を行い、AI が回答したりタスクをこなしたりできる。 Slack 側の契約が Slack AI search をサポートするプラン（Business+ 以上）である必要あり。 Nano Banana 2 と Nano Banana Pro が一般公開（GA） Agent Platform Gemini 3.1 Flash Image and Gemini 3 Pro Image (2026-05-28) Gemini Enterprise Agent Platform（旧 Vertex AI）で画像生成モデル Gemini 3.1 Flash Image（Nano Banana 2）と Gemini 3 Pro Image（Nano Banana Pro）が Preview → 一般公開（GA）に。 4k 画像の出力は Preview 提供。また Flash は動画の入力を受けられる。これも Preview 提供。 Preview 版モデルは 2026-07-17 に廃止されるため要注意。 gemini-2.5-flash、gemini-3-flash-preview 等が新規利用の受付停止 Google Cloud からユーザーにメールで通知 (2026-05-28) 2026-06-15 以降、以下のモデルの新規利用はできなくなる。 gemini-2.5-flash gemini-2.5-flash-lite gemini-3-flash-preview 既に利用中プロジェクト、すなわち過去90日以内に上記モデルの呼び出し履歴があるプロジェクトでは、引き続きこれらのモデルが使える。 なお、正式な廃止予定（Shutdown date）は以下のとおり。 gemini-2.5-flash : October 16, 2026 gemini-2.5-flash-lite : October 16, 2026 gemini-3-flash-preview : No shutdown date announced Google Workspace のアップデート Google ドキュメントの Gemini でカスタムインストラクションを設定可能に Set custom instructions for Gemini in Google Docs (2026-05-04) Google ドキュメントの Gemini サイドパネルでカスタムインストラクションを設定できるように。 文体や要約時のトーンなどを指定できる。2026-05-04から段階的ロールアウト。 Gemini アプリで会話結果から各種ファイルを直接生成可能に Move from conversation to creation with file generation in Gemini (2026-04-27) Gemini アプリで会話結果から以下のファイルを直接生成可能になった。 Google ドキュメント、Google スプレッドシート、Google スライド PDF .docx .xlsx .csv .md ... など Google Workspace の公式リモート MCP サーバーが Public Preview 公開 New: Agent tools and security updates for Google Workspace developers (2026-05-01) Google Workspace の公式リモート MCP サーバーが Public Preview 公開。 管理操作ではなくメールやファイル取得、カレンダー予定、チャットなど、ユーザー側の操作が可能。ただし、Developer Preview に申請しないと使えないとの情報もあり。 同時に Google Workspace 系 API に新しいクォータや超過分の課金体系が整備された。AI エージェントと Google Workspace の連携で業務自動化が進むことが期待される。 Google Workspace Studio の Google Meet 関連が強化 Improvements to the Meet starter step and Calendar time-blocking capabilities in Google Workspace Studio (2026-05-06) Google Workspace Studio の Google Meet 関連が強化。 複数会議をトリガーとして指定。カレンダー上に予定を確保（ただし自分しか招待できない）。自動議事メモ（transcript）もしくは Gemini メモ（take notes for me）の完成をトリガにできる。 Gmail の Help me write（文章作成補助）機能が強化 Improvements To Help Me Write in Gmail (2026-05-01) Gmail の Help me write（文章作成補助）機能が強化。 (1) トピックコンテキスト: Googleドライブや他のメールのコンテキストを取り込んで文章を作成 (2) スタイルのパーソナライズ: 以前のメールにあわせて文体をパーソナライズ Google Workspace Studio で Ask NotebookLM が使えるようになった Use NotebookLM in your Google Workspace Studio flows (2026-05-12) Google Workspace Studio で Ask NotebookLM が使えるようになった。 例として「メール受信 → NotebookLM のナレッジをもとに返信文のドラフトを作成」のような業務が自動化できる。 Google Chat のメッセージ推敲が日本語を含む多言語に対応 Expanding language support for refining messages with Gemini in Google Chat (2026-05-14) Google Chat のメッセージ推敲が日本語を含む多言語に対応。 従来は英語のみだったが、新たに日本語、フランス語、ドイツ語、イタリア語、韓国語、ポルトガル語、スペイン語の 7 言語が対応。チャット入力欄の「Refine」アイコンをクリックするか、特定のテキストを選択することで、Gemini に語彙の調整、文法やスペルの修正、トーンの改善を依頼できる。 NotebookLM で Google ドライブとの自動同期が可能に Keep your sources up to date with automatic Drive syncing in NotebookLM (2026-05-26) NotebookLM で Google ドライブとの自動同期が可能になる。 これまでは Google ドライブ側のファイルが更新されると手動で同期ボタンを押す必要があった。2026-05-26から15日間かけて段階的ロールアウト。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の勝島です。当記事では、Gemini Enterprise Agent Platform と Cloud Monitoring の MCP サーバーを組み合わせて、エラーログの検知から AI による原因分析、Slack 通知までを自動化します。 はじめに Gemini Enterprise Agent Platform とは MCP（Model Context Protocol）とは 当記事について 背景と構成 本構成の狙い システムの構成 環境構築 環境変数の設定 API の有効化 ログルーティングの設定 サービスアカウントと IAM ロール アプリケーションの実装 ディレクトリ構成 requirements.txt main.py ソースコードの解説 Cloud Run functions へのデプロイ デプロイコマンドの実行 Cloud Run の呼び出し権限の付与 動作確認 はじめに Gemini Enterprise Agent Platform とは 2026年4月現在、 Gemini Enterprise Agent Platform （以下、Agent Platform）は、Google Cloud が提供する AI エージェントの構築・運用のための統合プラットフォーム（プロダクト群）です。 同年4月の Google Cloud Next '26 で、従来の Vertex AI から名称変更されました。Agent Platform は、エージェントの開発、スケール、ガバナンス、最適化のためのプロダクト群であるといえます。 MCP（Model Context Protocol）とは Model Context Protocol （以下、 MCP ）は、AI モデルが外部ツールを呼び出すための標準プロトコルです。 Google Cloud では、Cloud Monitoring や Cloud Logging などの主要サービス向けに、フルマネージドなリモート MCP サーバーである Google Cloud MCP Servers が提供されています。当記事の構成では、AI モデルがこの MCP サーバー経由で Cloud Monitoring のメトリクスをツールとして自律的に呼び出し、原因分析に使用します。 参考 : Google Cloud MCP servers overview 参考 : MCP Reference: monitoring.googleapis.com Google Cloud MCP Servers の概要や認証方式の詳細については、以下の記事も参照してください。 blog.g-gen.co.jp 当記事について 当記事では、Cloud Logging で severity >= ERROR のログを検知した際に、Gemini モデルが MCP サーバー経由で関連メトリクスを取得し、Cloud Logging の関連ログも横断的に検索したうえで、原因の仮説と対処アクションを Slack に通知する AI エージェントを構築します。 なお、当記事の構成で使用する Cloud Run functions の全体像については以下の記事も参照してください。 blog.g-gen.co.jp 背景と構成 本構成の狙い Cloud Monitoring の標準の アラート 機能でも、しきい値ベースでの通知や Error Reporting によるエラー集計は可能です。しかし、これらは「何が起きたか」を伝えてくれるものの、「なぜ起きたのか」「どう対処すべきか」までは教えてくれません。 エラー発生時にメトリクスとログを横断的に確認し、根本原因の仮説を立てるという作業は、依然としてエンジニアの手作業に依存しています。当構成では、この一次切り分けの作業を AI エージェントに委譲することで、対応のリードタイム短縮を狙います。 システムの構成 ユーザー側で severity >= ERROR のログが Cloud Logging に書き込まれると、ログシンクを経由して Pub/Sub にメッセージが転送されます。 Pub/Sub のメッセージを受信した Cloud Run functions は、Agent Platform 経由で Gemini モデルを呼び出します。 Gemini モデルは MCP サーバー経由で Cloud Monitoring からメトリクスを取得し、さらに Cloud Logging から関連ログを検索しながら、原因の仮説と対処アクションを生成し Slack へ通知します。 構成図 なお、Pub/Sub を中心とした疎結合アーキテクチャの考え方や、Cloud Logging のログルーター（シンク）の仕組みの詳細については、以下の記事を参照してください。 blog.g-gen.co.jp blog.g-gen.co.jp 環境構築 環境変数の設定 以降のコマンドで使用する環境変数を設定します。 PROJECT_ID と SLACK_WEBHOOK_URL は、実際の環境に合わせて変更してください。 export PROJECT_ID = " your-project-id " export REGION = " asia-northeast1 " export TOPIC_NAME = " error-alerts-topic " export SINK_NAME = " error-logs-sink " export SA_NAME = " ai-ops-agent-sa " export SA_EMAIL = " ${SA_NAME} @ ${PROJECT_ID} .iam.gserviceaccount.com " export SLACK_WEBHOOK_URL = " https://hooks.slack.com/services/xxxx/xxxx/xxxx " API の有効化 対象プロジェクトをセットし、必要な API を有効化します。 gcloud config set project $PROJECT_ID gcloud services enable \ logging.googleapis.com \ pubsub.googleapis.com \ cloudfunctions.googleapis.com \ run.googleapis.com \ aiplatform.googleapis.com \ monitoring.googleapis.com \ cloudbuild.googleapis.com \ eventarc.googleapis.com 主要な API の役割は以下の通りです。 API 役割 logging.googleapis.com エラーログを検知し、Pub/Sub へルーティングする pubsub.googleapis.com エラーログを受け取り、Cloud Run functions に通知する cloudfunctions.googleapis.com 通知をトリガーに分析処理を実行する aiplatform.googleapis.com Gemini モデルでエラーの原因分析を行う monitoring.googleapis.com MCP サーバー経由でメトリクスを参照する ログルーティングの設定 Cloud Logging から Pub/Sub へエラーログを転送するための ログシンク と Pub/Sub トピック を作成します。 # Pub/Sub トピックの作成 gcloud pubsub topics create $TOPIC_NAME # ログシンクの作成（テスト用ログのみ転送） gcloud logging sinks create $SINK_NAME \ pubsub.googleapis.com/projects/ $PROJECT_ID /topics/ $TOPIC_NAME \ --log-filter =" severity>=ERROR AND logName= \" projects/ ${PROJECT_ID} /logs/my-test-log \" " --log-filter で logName を my-test-log に限定することで、動作確認用のログだけを Pub/Sub に転送する構成にしています。本番運用ではこのフィルタを実際のサービスログに合わせて変更してください。 続いて、ログシンクが Pub/Sub に書き込めるよう、ログシンクのサービスアカウントに Publisher 権限を付与します。 SINK_SA = $( gcloud logging sinks describe $SINK_NAME --format =' value(writerIdentity) ' ) gcloud pubsub topics add-iam-policy-binding $TOPIC_NAME \ --member = $SINK_SA \ --role = roles/pubsub.publisher サービスアカウントと IAM ロール Cloud Run functions が Agent Platform、Cloud Monitoring、MCP を使用するためのサービスアカウントを作成し、必要なロールを付与します。 # サービスアカウントの作成 gcloud iam service-accounts create $SA_NAME \ --display-name =" AI Ops Agent " || true # Agent Platform ユーザー gcloud projects add-iam-policy-binding $PROJECT_ID \ --member =" serviceAccount: ${SA_EMAIL} " \ --role =" roles/aiplatform.user " # Monitoring 閲覧者 gcloud projects add-iam-policy-binding $PROJECT_ID \ --member =" serviceAccount: ${SA_EMAIL} " \ --role =" roles/monitoring.viewer " # ログ閲覧者 gcloud projects add-iam-policy-binding $PROJECT_ID \ --member =" serviceAccount: ${SA_EMAIL} " \ --role =" roles/logging.viewer " # MCP ツールユーザー gcloud projects add-iam-policy-binding $PROJECT_ID \ --member =" serviceAccount: ${SA_EMAIL} " \ --role =" roles/mcp.toolUser " 各ロールの目的は以下の通りです。 ロール 目的 Agent Platform ユーザー（ roles/aiplatform.user ） Gemini モデルの呼び出し Monitoring 閲覧者（ roles/monitoring.viewer ） MCP 経由でのメトリクス取得 ログ閲覧者（ roles/logging.viewer ） 関連ログの参照 MCP ツールユーザー（ roles/mcp.toolUser ） MCP ツールの呼び出し なお、Google Cloud の MCP サーバーは「MCP プロトコル自体を呼び出す権限（ roles/mcp.toolUser ）」と「対象サービスのデータを参照する権限（ roles/monitoring.viewer など）」の二段階の認可で保護されています。両方を付与する必要がある点に注意してください。 アプリケーションの実装 ディレクトリ構成 以下の構成でファイルを作成します。 ai-ops-function（任意のフォルダ名） ├── main.py └── requirements.txt requirements.txt 必要なライブラリを定義します。 functions-framework==3.* google-cloud-pubsub google-cloud-logging google-genai google-auth requests main.py main.py は、Pub/Sub から受け取ったエラーログを Gemini に解析させ、Slack に通知するアプリケーション本体です。 import base64 import json import os from datetime import datetime, timedelta, timezone import requests from google import genai from google.cloud import logging_v2 import google.auth from google.auth.transport.requests import Request SLACK_WEBHOOK_URL = os.environ.get( "SLACK_WEBHOOK_URL" ) PROJECT_ID = os.environ.get( "PROJECT_ID" ) MCP_SERVER_URL = "https://monitoring.googleapis.com/mcp" def get_mcp_headers (): scopes = [ "https://www.googleapis.com/auth/cloud-platform" ] credentials, _ = google.auth.default(scopes=scopes) credentials.refresh(Request()) return { "Authorization" : f "Bearer {credentials.token}" , "Content-Type" : "application/json" } def list_monitoring_mcp_tools () -> str : """MCP サーバーから使用可能なツール一覧を取得する""" payload = { "jsonrpc" : "2.0" , "method" : "tools/list" , "id" : 1 } res = requests.post(MCP_SERVER_URL, json=payload, headers=get_mcp_headers()) if not res.ok: return f "MCP tools/list API エラー (HTTP {res.status_code}): {res.text[:1000]}" result_data = res.json().get( "result" , {}) simplified_tools = [] for tool in result_data.get( "tools" , []): schema = tool.get( "inputSchema" , {}) simplified_props = {} for k, v in schema.get( "properties" , {}).items(): simplified_props[k] = { "type" : v.get( "type" , "unknown" ), "description" : v.get( "description" , "" )[: 100 ] } simplified_tools.append({ "name" : tool.get( "name" ), "description" : tool.get( "description" , "" )[: 200 ], "required_args" : schema.get( "required" , []), "properties" : simplified_props }) return json.dumps({ "tools" : simplified_tools}, indent= 2 , ensure_ascii= False ) def call_monitoring_mcp_tool (tool_name: str , arguments_json_str: str ) -> str : """指定した MCP ツールを実行してメトリクスを取得する""" arguments = json.loads(arguments_json_str) payload = { "jsonrpc" : "2.0" , "method" : "tools/call" , "id" : 2 , "params" : { "name" : tool_name, "arguments" : arguments} } res = requests.post(MCP_SERVER_URL, json=payload, headers=get_mcp_headers()) if not res.ok: return f "MCP tools/call API エラー (HTTP {res.status_code}): {res.text[:1000]}" response_data = res.json() if "result" in response_data and "content" in response_data[ "result" ]: text_result = " \n " .join( [item.get( "text" , "" ) for item in response_data[ "result" ][ "content" ]] ) return text_result[: 3000 ] + " \n ...（省略）" if len (text_result) > 3000 else text_result return f "MCP エラー: {response_data.get('error', '不明なレスポンス')}" def search_cloud_logs (filter_str: str , hours: int = 2 ) -> str : """Cloud Logging で過去 N 時間のログを検索する""" client = logging_v2.Client(project=PROJECT_ID) start_time = datetime.now(timezone.utc) - timedelta(hours=hours) full_filter = f '{filter_str} AND timestamp>="{start_time.isoformat()}"' entries = client.list_entries(filter_=full_filter, max_results= 20 ) results = [] for entry in entries: results.append({ "timestamp" : entry.timestamp.isoformat() if entry.timestamp else "" , "severity" : str (entry.severity), "resource" : entry.resource.type if entry.resource else "" , "payload" : str (entry.payload)[: 500 ] }) if not results: return "該当するログは見つかりませんでした。" text = json.dumps(results, indent= 2 , ensure_ascii= False ) return text[: 3000 ] + " \n ...（省略）" if len (text) > 3000 else text def analyze_error (event, context): """Pub/Sub からエラーログを受け取り、Gemini で分析して Slack に通知する""" pubsub_message = base64.b64decode(event[ 'data' ]).decode( 'utf-8' ) log_data = json.loads(pubsub_message) error_msg = log_data.get( "textPayload" ) or log_data.get( "jsonPayload" ) client = genai.Client(vertexai= True , project=PROJECT_ID, location= "us-central1" ) log_str = json.dumps(log_data, indent= 2 )[: 5000 ] prompt = f """ 以下のエラーログが検知されました。MCP サーバーおよび Cloud Logging と連携して調査してください。 【ログ内容】 {log_str} 【厳守事項】 原因分析にあたり、以下のステップを必ずすべて実行してください。推測（ハルシネーション）による回答や、一部のツール呼び出しの省略は許可されません。 1. `list_monitoring_mcp_tools` でツール一覧を確認してください。 2. `call_monitoring_mcp_tool` でプロジェクト {PROJECT_ID} の直近 10 分のメトリクスを取得してください。取得対象はログの文脈（「リクエストが処理しきれません」等）から判断し、Cloud Run のリクエスト数（例: metric.type="run.googleapis.com/request_count"）など、負荷状況がわかる確実な標準メトリクスを指定してください。無効なクエリは避けてください。 3. `search_cloud_logs` で直近 10 分の関連するログを検索してください（severity>=WARNING など）。 【出力フォーマット】 分析結果は、必ず以下の Markdown 構造に厳密に従って出力してください。ツール名は記載せず、自然な日本語で記載してください。 ### 調査結果 1. **メトリクス分析:** （実際に取得したメトリクスの数値やスパイクの有無など、客観的な事実のみを記載） 2. **ログ分析:** （実際に検索した関連ログの件数や内容など、客観的な事実のみを記載） ### 原因の仮説 （上記の客観的データに基づき、なぜエラーが発生したのかの考察を記載） ### 対処アクション （具体的な解決策を記載） """ res = client.models.generate_content( model= 'gemini-2.5-flash' , contents=prompt, config={ "tools" : [list_monitoring_mcp_tools, call_monitoring_mcp_tool, search_cloud_logs]} ) requests.post(SLACK_WEBHOOK_URL, json={ "text" : f "🚨 *【AI 自動分析】* \n *ログ:* \n ``` \n {str(error_msg)[:1000]} \n ``` \n *分析:* \n {res.text}" }) ソースコードの解説 上記のソースコードは、大きく分けて「Gemini に渡すツール関数群」と「Pub/Sub をトリガーにエージェントを起動するエントリーポイント」の2つのパートで構成されます。 まずは、ツール関数群について解説します。このパートは、 list_monitoring_mcp_tools 、 call_monitoring_mcp_tool 、 search_cloud_logs で構成されます。 list_monitoring_mcp_tools MCP サーバーから使用可能なツール一覧を取得します。Cloud Monitoring が返すスキーマは大きく、そのまま Gemini に渡すとコンテキスト上限を超える恐れがあるため、プロパティ情報を必要最小限に絞り込んでいます。 call_monitoring_mcp_tool 指定された MCP ツールを実行し、メトリクスを取得します。 search_cloud_logs Cloud Logging から関連ログを検索します。Gemini がメトリクスだけでは原因を判断できない場合に、追加の調査手段として呼び出されます。 次に、エントリーポイント（ analyze_error() ）のパートについて解説します。 Pub/Sub イベントの受信 Pub/Sub から渡されたメッセージをデコードし、含まれるエラーログの内容を取り出します。 Gemini モデルの呼び出し プロンプトと使用可能ツールの一覧を渡して generate_content を実行します。プロンプトには、ツールの呼び出し順序と、最終的に出力すべき内容（原因の仮説と対処アクション）を明記しています。 Slack への通知 Gemini から返された応答を、Slack Webhook 経由で指定チャンネルに POST します。 Cloud Run functions へのデプロイ デプロイコマンドの実行 ターミナルで ai-ops-function ディレクトリに移動し、Cloud Run functions にデプロイします。 # プロジェクト番号の取得 export PROJECT_NUMBER = $( gcloud projects describe $PROJECT_ID --format =' value(projectNumber) ' ) # デプロイの実行（クリーン版） gcloud functions deploy ai-ops-analyzer \ --gen2 \ --runtime = python311 \ --region = $REGION \ --source = . \ --entry-point = analyze_error \ --trigger-topic = $TOPIC_NAME \ --service-account = $SA_EMAIL \ --trigger-service-account = ${PROJECT_NUMBER} -compute@developer.gserviceaccount.com \ --set-env-vars = SLACK_WEBHOOK_URL = $SLACK_WEBHOOK_URL , PROJECT_ID = $PROJECT_ID \ --quiet Cloud Run の呼び出し権限の付与 Cloud Run functions は、内部的には Cloud Run service として展開されます。Pub/Sub 経由でのトリガー時に正しく認証が通るよう、サービスアカウントに Cloud Run の呼び出し権限を付与します。 # プロジェクト番号の取得 export PROJECT_NUMBER = $( gcloud projects describe $PROJECT_ID --format =' value(projectNumber) ' ) # Compute Engine デフォルトサービスアカウントに Cloud Run 起動権限を付与 gcloud run services add-iam-policy-binding ai-ops-analyzer \ --region = $REGION \ --member =" serviceAccount: ${PROJECT_NUMBER} -compute@developer.gserviceaccount.com " \ --role =" roles/run.invoker " 動作確認 デプロイしたエージェントの動作確認として、以下の手順で疑似的なインシデント状況を作り出してテストします。意図的にメトリクスの負荷スパイクを発生させ、テスト用エラーログを書き込むことで、AI による原因分析が正しく実行されるかを確認します。 1.Cloud Shell から、デプロイした関数に対してリクエストを送り、メトリクス上にスパイクを発生させます。 # 自分の関数の URL を取得 URL = $( gcloud run services describe ai-ops-analyzer --region = $REGION --format =' value(status.url) ' ) TOKEN = $( gcloud auth print-identity-token ) # 1 分間、並列でリクエストを送り続ける（スパイクを作成） echo " 負荷を発生させています（約 1 分間）... " for i in { 1 .. 100 } ; do curl -s -H " Authorization: Bearer $TOKEN " $URL > /dev/null & done sleep 30 for i in { 1 .. 100 } ; do curl -s -H " Authorization: Bearer $TOKEN " $URL > /dev/null & done wait echo " 負荷生成完了。 " 2.負荷をかけてから2〜3分のタイミングで、テスト用のエラーログを書き込みます。 gcloud logging write my-test-log \ " CRITICAL: サービス応答遅延が発生しています。リクエストが処理しきれません。 " \ --severity = ERROR 3.Slack 上で、AI による分析結果が通知されることを確認します。 勝島 祐太郎 (記事一覧) クラウドソリューション部 ソリューションアーキテクト課 2025年1月G-genにジョイン！飲食業界からIT業界に転身したエンジニア。 コーヒーが好きです。