G-gen の本間です。当記事では、 Migrate to Virtual Machines を使って、Amazon Web Services（AWS）から Google Cloud へ仮想マシンを移行する方法を解説します。 はじめに Migrate to Virtual Machines とは サポートされる環境 移行手順の概要 前提事項 AWS 側の設定 Google Cloud 側の設定 注意点 AWS 側の設定 Google Cloud 側の設定 インスタンスのレプリケーション ターゲットインスタンスの定義 テストクローンの作成と動作確認 カットオーバー レプリケーションの最終処理 はじめに Migrate to Virtual Machines とは Migrate to Virtual Machines は、オンプレミス環境や他のクラウド環境から Google Cloud の Compute Engine へ仮想マシンを移行するための Google Cloud サービスです。 このサービスでは、移行元の仮想マシンを稼働させたまま、Google Cloud 上にデータをレプリケーションできるため、移行に伴うダウンタイムを最小限に抑えられます。 参考 : Migrate to Virtual Machines のドキュメント サポートされる環境 Migrate to Virtual Machines では VMware、Amazon Web Services（以下、AWS）、Microsoft Azure が移行元としてサポートされています。ただし、それぞれの環境ごとにサポートされている OS が決まっているため、事前に確認する必要があります。 また、AWS からの移行においては、対象となる EC2 インスタンスの OS やディスクのタイプが、Migrate to Virtual Machines でサポートされているかについても事前に確認する必要があります。 なお、AWS 側からのデータ転送には、AWS のアウトバウンドデータ転送料金が発生します。移行対象のデータ量が多い場合は、コストに注意してください。 参考 : サポートされているオペレーティング システム 移行手順の概要 前提事項 当記事の解説における前提として、AWS 側では、VPC 内のパブリックサブネットに Windows Server 2025 の EC2 インスタンスを構築済みであり、インターネットゲートウェイ（IGW）経由でのルーティングおよびセキュリティグループの設定によりインターネットへのアウトバウンド通信の準備が完了しているものとします。 また、Google Cloud 側ではインスタンスを配置する対象リージョンの VPC ネットワークとサブネットの構築が完了しているものとします。移行先 VM の構築自体に特段通信要件はありませんが、移行工程でテストクローンを実施する場合、移行元 VM と移行先 VM が同時に起動する状態となります。予期しないトラブルを防止するため、移行先 VM と、移行元 VM および周辺システムが通信できないネットワーク設定とすることが推奨されます。 AWS 側の設定 AWS 側の手順では IAM ポリシーとユーザーの作成を行います。この際、アクセスキーとシークレットアクセスキーも発行します。 また、VPC や EC2 インスタンスが、前述の前提事項や後述の注意点に準拠していることを確認してください。 Google Cloud 側の設定 Google Cloud 側の大まかな手順は以下のとおりです。 インスタンスのレプリケーション ターゲットインスタンスの定義 テストクローンの作成と動作確認 カットオーバー レプリケーションの最終処理 最初に、AWS 側の VM のディスクデータを Google Cloud 側に同期します。この工程をレプリケーションと呼びます。この工程では Google Cloud 側に VM は起動せず、あくまでディスクのデータのみをコピーします。データは Migrate to Virtual Machines のマネージドなストレージに保管されます。 続いて、コピーしたデータを元にしてどのようなスペックで Google Cloud 側の VM として起動するかを定義し、その設定に基づいて実際に VM を起動します。テスト環境用に VM を起動することをテストクローンの作成、本番環境用に VM を起動することをカットオーバーといいます。 注意点 Google Cloud に移行する VM は、ブートパーティションに 128 MB 以上の空き容量が必要です。 レプリケーションは初回実施時から100日間、アクティブ状態が維持されます。100日経過後、EXPIRED 状態に移行し、レプリケーションサイクルが停止します。再びアクティブ状態にするには初回実施時から130日経過する前に存続期間を延長する必要があります。期間の延長は1回のみ可能で、追加で100日間アクティブ状態にできます。よって、VM の移行はこの期間内に完了させる必要があります。 Migrate to Virtual Machines では、レプリケーションのプロセスを通して OS 適応 というプロセスが自動的に実行されます。OS 適応は VM を Google Cloud 上で適切に動作させるために、パッケージのインストールやネットワーク設定等を行うプロセスです。このプロセスは Linux と Windows の両方で行われ、Linux VM では /root で最大640 MiB、/boot で最大128 MiB、/var で最大64 MiB、/tmp で最大32 MiB の空き容量が必要です。Windows VM では C ドライブに最大1.25 GiB の空き容量が必要です。 カットオーバー実行時は移行元の VM が停止されるため、注意してください。 参考 : 個々の VM を移行する - 前提条件 参考 : 移行中の VM のライフサイクル 参考 : Google Cloud で実行するように VM インスタンスを適応させる 参考 : VM の移行プロセス - カットオーバーフェーズ AWS 側の設定 当記事では、AWS 側の設定手順の詳細な解説は省略します。詳細は、公式ドキュメントを参照してください。 まずは AWS マネジメントコンソールにログインし、Migrate to Virtual Machines が必要とする権限を定義した IAM ポリシーを作成します。 参考 : AWS ソースを作成する - AWS IAM ポリシーを作成する 次に、作成した IAM ポリシーをアタッチした IAM ユーザーを作成します。この IAM ユーザーは、AWS リソースへのプログラムによるアクセス（API 経由でのアクセス）に使用されます。 IAM ユーザー作成後に IAM ユーザーの「セキュリティ認証情報」から、アクセスキーおよびシークレットアクセスキーを発行します。これらのキーは、Google Cloud 側の設定で使用するため、安全な場所に記録しておきます。 参考 : AWS ソースを作成する - IAM ユーザーを作成する Google Cloud 側の設定 インスタンスのレプリケーション 以下は、2026年8月現在の Google Cloud コンソール画面を前提とした手順です。 Google Cloud コンソールの上部検索ボックスに「Migrate to Virtual Machines」と入力して表示されるサジェストから「Migrate to Virtual Machines」画面へ進みます。表示された画面上部の「ソース」タブを選択し、「ソースを追加」から「AWS ソースを追加します」を選択します。 AWS ソースの作成画面から事前に発行した AWS IAM ユーザーのアクセスキーとシークレットアクセスキー、および対象の AWS リージョンを入力して、ソース環境を登録します。 このとき、AWS セキュリティグループやタグを使って対象のインスタンスをフィルタリングできます。 ソースを追加すると、指定した AWS リージョン内に存在する EC2 インスタンスのリストが自動的に取得されます。 このリストから移行対象とするインスタンスのチェックボックスにチェックを入れ、「移行を追加」プルダウンから「VM migration」を実行します。すると移行確認画面が表示されるため、「確認」を押下します。 完了後、画面上部の「VM の移行」タブを押下すると、先ほど選択したインスタンスが追加され、レプリケーションのステータスが準備完了となっていることが確認できます。続いて、対象インスタンスのチェックボックスにチェックを入れ、「移行」プルダウンから「レプリケーションを開始」を実行します。この処理により、AWS 上の仮想マシンデータが、Google Cloud 上に継続的にコピーされます。 ターゲットインスタンスの定義 レプリケーションが進行している間に、先行して Google Cloud 上で稼働させるインスタンスのスペック（マシンタイプ、ネットワーク設定、ディスクタイプなど）を定義します。 先ほどの画面から再び対象インスタンスのチェックボックスにチェックを入れ、「ターゲットの詳細を編集」を押下し、表示された編集画面を上から順に設定します。 なお、最下部の「Replication policy」設定でレプリケーション間隔を設定できます。デフォルトは2時間です。 テストクローンの作成と動作確認 しばらく待機し、先ほどの「VM の移行」画面から対象インスタンスのレプリケーションステータスが「有効」となっていることを確認します。この状態となっていれば初回レプリケーションは完了です。 以降は「Replication policy」で設定したレプリケーション間隔ごとに増分レプリケーションが実施されます。 参考 : VM の移行プロセス - レプリケーションフェーズ 次にテストクローンを実施します。テストクローン機能を使用すると、移行した VM のクローンを Compute Engine インスタンスとしてデプロイできます。テストクローンは省略可能ですが、本番環境へ移行する前に実施し、テスト環境で動作確認をすることが推奨されます。 参考 : VM の移行プロセス - テストクローンフェーズ 「VM の移行」画面から再び対象インスタンスのチェックボックスにチェックを入れ、「カットオーバーとテストクローン」プルダウンから「テストクローン」を実行します。するとテストクローン作成確認画面が表示されるため、「確認」を押下します。 しばらく待機し、「VM の移行」画面から対象インスタンスの「テストクローン/カットオーバーのステータス」が「クローンが完了しました」となっていることを確認します。 この状態になればテストクローン完了です。Google Cloud コンソールの上部検索ボックスに「Compute Engine」と入力して表示されるサジェストから「Compute Engine」画面へ進み、インスタンスが起動していることを確認します。 ここで、必要に応じてインスタンスにログインし OS 設定を確認したり、コンソール画面から Compute Engine インスタンスの設定値を確認したりして、想定どおりにデプロイされていることを確認します。 カットオーバー テストクローンによる事前確認完了後、カットオーバーを実施します。 カットオーバーを実行すると、最後のレプリケーションが実施され、VM が Compute Engine インスタンスにデプロイされます。この際、移行元の VM は停止されるため、注意してください。 また、Compute Engine は IP アドレスやインスタンス名が同じ VM を複数作成できません。そのため、テストクローン実施時に作成したインスタンスが存在している場合は、インスタンスを削除するか、「ターゲットの詳細を編集」から別のインスタンス名を設定してください。当記事の手順では、テストインスタンスを削除してから実行します。 「VM の移行」画面から再び対象インスタンスのチェックボックスにチェックを入れ、「カットオーバーとテストクローン」プルダウンから「カットオーバー」を実行します。するとカットオーバー確認画面が表示されるため、「確認」を押下します。 カットオーバーの状況については、先ほどの画面から対象インスタンス名を押下し、「テストクローン/カットオーバーの履歴」タブから確認できます。 しばらく待機し、「VM の移行」画面から対象インスタンスの「テストクローン/カットオーバーのステータス」が「カットオーバーが完了しました」となっていることを確認します。 この状態になればカットオーバー完了です。テストクローン実施時と同様に、Google Cloud コンソールの上部検索ボックスに「Compute Engine」と入力して表示されるサジェストから「Compute Engine」画面へ進み、想定どおりのインスタンスが起動していることを確認します。 レプリケーションの最終処理 カットオーバー完了後、レプリケーションの最終処理を実施します。カットオーバー完了時点で移行は完了していますが、レプリケーションの最終処理を実行するまではレプリケーションデータが保持された状態です。 「VM の移行」画面から再び対象インスタンスのチェックボックスにチェックを入れ、「移行」プルダウンから「レプリケーションを最終処理」を押下します。 しばらく待機し、「VM の移行」画面から対象インスタンスの「レプリケーションのステータス」が「最終処理済み」となっていることを確認します。 以上で AWS から Google Cloud への VM 移行作業は完了です。 本間 優太郎 (記事一覧) クラウドソリューション部 クラウドエンジニアリング2課 北海道在住 2026年6月に G-gen にジョイン。前職では社内SE、Sler としてアプリ/インフラ開発業務に従事。アプリ/インフラ双方の経験をベースに現在はGoogle Cloudの学習を進めている。 好きなことは子供と遊ぶこと、ゲームをすること。

G-gen の三浦です。当記事では、Google SecOps の AI エージェントである Detection Engineering エージェント を使い、ある脅威を既存のルールで検出できるかを Antigravity CLI から評価した結果を紹介します。 概要 Google SecOps とは Detection Engineering エージェントとは 注意点 検証の手順 事前準備 必要な IAM ロール 対象ログのパーサー Application Default Credentials の構成 Antigravity CLI への SecOps MCP サーバーの登録 コンテキストの設定 カバレッジ評価スキルの導入 Detection Engineering エージェントの有効化 検証 カバレッジの評価 生成された脅威検出の機会 生成された合成イベント 生成されたルールのレビューとルールの作成 作成したルールのロジック確認 ルールの状態確認 概要 Google SecOps とは Google Security Operations （以下、Google SecOps）は、Google Cloud のセキュリティ運用プラットフォームです。SIEM、SOAR、脅威インテリジェンス、Gemini による AI 運用支援を1つのプラットフォームで提供します。 詳細は以下の記事を参照してください。 blog.g-gen.co.jp Detection Engineering エージェントとは Detection Engineering エージェント は、Google SecOps に組み込まれた AI 搭載のエンジニアリングアシスタントです。 MCP サーバー経由で Antigravity や Claude Code などの AI クライアントから使用でき、既存の検出ルールが脅威に対応できているかを評価します。検出できない範囲があれば、それを埋める YARA-L ルール（脅威を検出するルール）の案も生成します。 カバレッジ評価では、主に以下の 4 つのツールを使用します。 ツール名 できること generate_threat_detection_opportunity セキュリティブログや脅威レポートなどの文章から脅威の情報を抽出し、優先順位を付けた 脅威検出の機会 を作成する generate_synthetic_events 脅威検出の機会をもとに、その攻撃が起きたときに記録されるであろうログ（ 合成イベント ）を生成する evaluate_rule_coverage_long_running Google SecOps インスタンスの既存のルールが生成された合成イベントを検出するかを確認する generate_rules カバレッジ評価で見つかった検出の抜けを埋めるための YARA-L ルールの下書きを作成する 参考 : Evaluate threat coverage with the Detection Engineering Agent 参考 : Detecting and containing AI-powered threats with Google Security Operations agents 参考 : Google Security Operations によるエージェント型防御 注意点 Detection Engineering エージェントは、2026年9月現在、 Preview 版 です。当記事で解説する内容は一般提供（GA）の際に変更される可能性がある点に留意してください。Google SecOps サービス固有の規約の pre-GA サービス規約が適用され、サポートは制限されます。 参考 : プレビュー版の機能を管理する Preview 版のサービスや機能を使う際の注意点は、以下の記事も参考にしてください。 blog.g-gen.co.jp 検証の手順 当記事では、以下の流れで検証を行います。 同意フィッシング と呼ばれる不正な OAuth アプリの同意により Gmail などのデータを窃取する攻撃をテーマに、ルールの作成、検証、評価を実施します。 参考 : Protecting You Against Phishing 項番 項目 内容 1 事前準備 IAM ロールを付与し、Antigravity CLI に SecOps MCP サーバーとカバレッジ評価スキルを登録します。 2 Detection Engineering エージェントの有効化 Preview 機能が解放されているかを確認し、解放されていなければ有効化します。 3 カバレッジの評価 脅威を自然言語で入力し、脅威検出の機会と合成イベントの生成から既存ルールの評価までをエージェントに実行させます。 4 生成されたルールのレビューとルールの作成 検出できない場合に生成される YARA-L ルールをレビューして作成し、生成済みの合成イベントと条件式を突き合わせて意図した判定になるかを確認します。 事前準備 必要な IAM ロール Detection Engineering エージェントを呼び出すプリンシパル（Google アカウント／サービスアカウント）に、SecOps インスタンスが紐付くプロジェクトで以下の IAM ロールを付与します。 MCP ツールユーザー（ roles/mcp.toolUser ） Chronicle API 閲覧者（ roles/chronicle.viewer ） Chronicle API 編集者（ roles/chronicle.editor ） Event Simulation の公式ドキュメントでは、この 3 つすべてが要件として挙げられています。 参考 : Use event simulation for detection coverage evaluation あわせて、後述する Preview 機能の有効化には、IAM ロールとは別に Google SecOps 内の 管理者 ロールが必要です。 参考 : Evaluate threat coverage with the Detection Engineering Agent 参考 : プレビュー版の機能を管理する 対象ログのパーサー パーサー は、取り込んだ生ログを Google SecOps 共通のデータ構造である Unified Data Model （以下、UDM）へ変換する仕組みです。主要なログタイプにはデフォルト パーサーが用意されており、Google SecOps 側で保守されます。 参考 : パーサーの概要 Detection Engineering エージェントは、評価したい脅威のログタイプに対応するパーサーが環境に存在することを前提としています。対応するパーサーがない場合、合成イベントの生成に失敗し、そのログタイプについてはカバレッジを評価できません。 参考 : Evaluate threat coverage with the Detection Engineering Agent Application Default Credentials の構成 Antigravity CLI から SecOps MCP サーバーへ接続する際に、Application Default Credentials（以下、ADC）を使用します。未構成の場合は、事前に以下を実行しておきます。 # ADC を構成する（ブラウザが開き、認証後に認証情報が保存される） gcloud auth application-default login Antigravity CLI への SecOps MCP サーバーの登録 Detection Engineering エージェントは MCP サーバー経由で操作します。当記事では AI クライアントとして Antigravity CLI を使います。Antigravity CLI のインストールと初期設定は、以下の記事で解説しています。 blog.g-gen.co.jp SecOps MCP サーバーの有効化と Customer ID の確認方法は、以下の記事をご参照ください。 blog.g-gen.co.jp Antigravity CLI の MCP 設定ファイル（当検証環境では ~/.gemini/config/mcp_config.json ）に、SecOps MCP サーバーを登録します。 PROJECT_ID と URL のリージョン（例： asia-northeast1 ）は環境に合わせて置き換えてください。 { " mcpServers ": { " secops ": { " serverUrl ": " https://chronicle.asia-northeast1.rep.googleapis.com/mcp ", " authProviderType ": " google_credentials ", " oauth ": { " scopes ": [ " https://www.googleapis.com/auth/chronicle " ] } , " headers ": { " x-goog-user-project ": " PROJECT_ID " } } } } agy コマンドで Antigravity CLI を起動し、 /mcp コマンドで MCP サーバーへの接続を確認します。ツール一覧が表示されれば、接続は成功です。 　 MCP Servers 　 Plugins ( ~/.gemini/config/plugins ) > ✓ secops Tools: get_case, list_case_comments, list_cases, update_case, get_case_alert, + 65 more 　 コンテキストの設定 SecOps MCP サーバーのツールは、リクエストごとに Customer ID・リージョン・プロジェクト ID を必要とします。毎回入力しなくて済むよう、公式ドキュメントは GEMINI.md にこれらを書いておくことを推奨しています。 # GEMINI.md 　 When using the GoogleSecOps MCP Server, use these parameters for EVERY request: Customer ID: CUSTOMER_ID Region: REGION Project ID: PROJECT_ID 参考 : Evaluate threat coverage with the Detection Engineering Agent - Set up a context file カバレッジ評価スキルの導入 公式ドキュメントは、Detection Engineering エージェントを detection-engineering-coverage-evaluation スキル 経由で操作することを強く推奨しています。 参考 : Evaluate threat coverage with the Detection Engineering Agent - Set up the skill to interact with the tools 参考 : SecOps Detection Coverage Skill 上記 skills は Google 公開のリポジトリに存在します。詳細は以下の記事を参照してください。 blog.g-gen.co.jp Antigravity CLI では、 ~/.gemini/skills/ 配下にスキル名のディレクトリを作り、 SKILL.md を配置すると読み込まれます。 # スキルを取得して配置する git clone https://github.com/google/skills.git mkdir -p ~/.gemini/skills cp -r skills/skills/cloud/detection-engineering-coverage-evaluation ~/.gemini/skills/ Antigravity CLI を起動して /skills を実行し、一覧に表示されれば読み込まれています。 　 Skills 11 skills 　 Create new skills Workspace: ~/work/develop/secops/dea-verification/.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 detection-engineering-coverage-evaluation: Automates the end-to-end detection engineering workflow in Google SecOps using MCP tools. Use when fetching threat intelligence from blogs,... 　 Detection Engineering エージェントの有効化 2026年9月現在、Detection Engineering エージェントは Public Preview のため、先に機能の有効化が必要です。 Google SecOps のコンソールで [Settings] > [SIEM Settings] > [Public Preview] を選択します。テナントで使用できる Public Preview 機能が一覧表示されます。 パブリック プレビュー機能の一覧 以下の 2 つの機能が無効になっている場合は、[PREVIEW STATUS] をオンにして有効化します。 機能名 内容 Event Simulation Enabled (for DEA) 合成イベントを Google SecOps に取り込み、既存のルールで評価できるようにする機能。取り込まれた合成データと、そこから生成された検出結果は、本番のケースやアラートから隔離される Detection Engineering Agent Features Detection Engineering エージェントのツール群を使用できるようにする機能 機能の有効化 参考 : プレビュー版の機能を管理する 検証 カバレッジの評価 Antigravity CLI を起動し、以下のプロンプトを入力します。 /detection-engineering-coverage-evaluation で前手順で導入したスキルを使用します。 /detection-engineering-coverage-evaluation 悪意のある OAuth アプリへの同意により Google Workspace の情報を窃取される攻撃について、現在の環境で検出できる状態になっているかを評価してほしい。 エージェントは、使用するツールのスキーマを読み込んだうえで、脅威検出の機会の生成、合成イベントの生成、既存ルールの評価を順に実行します。評価は非同期処理で、当検証では完了まで約 35 分かかりました。 　 # 出力例 　 ### ワークフロー実行結果 　 #### 1. 脅威インテリジェンスの抽出 (Step 1) 　 • 入力ソース: ユーザー指定テキスト（プロンプトインジェクション等の問題なし） • 対象脅威: 悪意のある OAuth アプリケーションへのアクセス権限付与（同意）による Google Workspace 情報の窃取 　 #### 2. 脅威検出オポチュニティ (TDO) の生成 (Step 2) 　 • 生成数: 1 件 • TDO ( t01 ) : OAuth 同意フィッシング（Illicit Consent Grant）を通じて、悪意あるアプリに権限が付与され Google Workspace 内の情報を窃取される挙動を検出。 • MITRE ATT&CK: T1528 ( Steal Application Access Token ) / Credential Access ( TA0006 ) • 関連ログタイプ: WORKSPACE_ACTIVITY 　 　 #### 3. 擬似イベント (Synthetic Events) の生成 (Step 3) 　 • 生成イベント数: 4 件 • シミュレートされた挙動: • WORKSPACE_ACTIVITY（token アプリケーション）における不審な OAuth クライアントへの権限認可（authorize）および権限失効（revoke）イベント（Gmail・Google Drive・Directory 等への読み取りスコープ要求）。 　 　 #### 4. ルールカバレッジ評価 (Step 4 & 5) 　 • 評価対象イベント数: 4 件 • 検出結果: No rules matched ( 既存ルールでの検知なし ) • 現在の環境において、当該の OAuth アプリ同意イベントをトリガーとする検出ルールが存在しないカバレッジギャップが確認されました。 　 　 #### 5. ギャップ緩和・新規ルール生成 (Step 6) 　 • 未検出となった TDO に対して、新規 YARA-L 2 . 0 ルール（ttp_saas_oauth_consent_grant）を生成し、構文検証（validate_rule）にパスしました。 ────── ### 検出カバレッジ評価サマリー (Structured Output) 　 TDO: Detects the illicit granting of consent to malicious OAuth applications designed to access and exfiltrate Google Workspace information ( OAuth Consent Phishing ) . 　 Coverage Eval: [] ( No rules matched ) 　 Missing Coverage: 　 • Summary: Google Workspace において悪意のある OAuth アプリケーションへの同意や権限付与（OAuth Consent Grant）を検知するルールが存在しませんでした。 • Generated Rule: 　 rule ttp_saas_oauth_consent_grant { ～省略～ } 　 Errors: [] ────── ### 次のステップ（ルールの作成確認） 　 生成された新規ルール ttp_saas_oauth_consent_grant を Google SecOps 環境に作成・登録しますか？ 承認いただける場合は、環境へのルール作成（create_rule）を実行いたしますのでお知らせください。 　 既存のルールに一致するものがないと評価され、新規で YARA-L ルール案が提示されています。 生成された脅威検出の機会 脅威検出の機会 （Threat Detection Opportunity、以下 TDO）は、対象の攻撃を「どのログで探すか」「どの攻撃手口に当たるか」まで落とし込んだ定義です。当検証では 1 件生成されました。 { " id ": " t01 ", " logTypes ": [ " WORKSPACE_ACTIVITY " ] , " mitreInfo ": { " detectionStrategy ": " Cloud APIs ", " platform ": " SaaS ", " procedure ": " creation_oauth_consent_via_application ", " tactics ": [ " Credential Access " ] , " techniques ": [ " T1528 - Steal Application Access Token " ] } , " summary ": " Detects the illicit granting of consent to malicious OAuth applications designed to access and exfiltrate Google Workspace information (OAuth Consent Phishing). " } MITRE ATT&CK は、実際に観測された攻撃の手口を体系的にまとめたナレッジベースです。 T1528 のような技法番号で、個々の手口を識別します。各キーの内容は以下のとおりです。 キー 内容 生成された値 id TDO の識別子 t01 （後続の評価結果でも、この ID で対象を指します） logTypes 攻撃を探す対象のログ Google Workspace の監査ログ（ WORKSPACE_ACTIVITY ） mitreInfo MITRE ATT&CK での分類 戦術は Credential Access、技法は T1528 （アプリケーションアクセストークンの窃取） summary 攻撃シナリオの要約 悪意のある OAuth アプリに同意させ、Google Workspace の情報を持ち出す 生成された合成イベント 合成イベント とは、攻撃が発生した場合に記録されるログを、攻撃を行わずに作成したものです。合成イベントは Google SecOps に実際に取り込まれ、取り込みクォータと検出クォータを消費します。TDO をもとに 4 件が生成されました。 # アプリ名 イベント 付与されたスコープ 検出の要否 1 O365 Mail Migration authorize gmail.readonly 、 drive 必要 2 O365 Mail Migration revoke 同上 不要 3 Zoom Integration for Google Workspace authorize admin.directory.user.readonly 、 contacts 不要 4 Zoom Integration for Google Workspace revoke 同上 不要 検出すべきログと、検出してはいけないログが混在しています。 4 件のうち 1 件目だけに一致するルール が、目指す状態です。 参考 : Use event simulation for detection coverage evaluation 生成されたルールのレビューとルールの作成 生成されたルールをそのまま作成すると、検出したい攻撃以外のログにも一致することがあります。公式ドキュメントも、生成されたルールは検出エンジニアがレビューしたうえでデプロイすることを前提としています。 内容を確認したらルールの作成を以下のように指示します。 確認したので、そのまま作成を進めてほしい。 　 # 出力例 　 Google SecOps 環境への新規ルール登録を完了しました。 　 ### 登録されたルール詳細 　 • Rule ID: ru_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx • Rule Name: google_workspace_malicious_oauth_consent_grant • Compilation State: SUCCEEDED • Severity: Medium • Run Frequency: LIVE 　 rule google_workspace_malicious_oauth_consent_grant { meta: author = " Detection Engineer " description = " Detects authorization/consent granting for OAuth applications requesting sensitive Google Workspace scopes (Gmail, Google Drive, Mail, or full mail access). " severity = " Medium " tactic = " TA0006 " technique = " T1528 " 　 events: $e .metadata.log_type = " WORKSPACE_ACTIVITY " $e .metadata.event_type = " USER_RESOURCE_ACCESS " $e .metadata.product_event_type = " authorize " $e .target.application = " OAuth Token " 　 // Sensitive scopes including full Gmail access ( mail.google.com ) and Google APIs scopes ( gmail, drive, mail ) re.regex ($e .target.resource.attribute.labels [" scope "] , ` ( https://mail \. google \. com/ | https://www \. googleapis \. com/auth/ ( gmail | drive | mail )) ` ) nocase 　 outcome: $app_name = $e .target.resource.name $granted_scopes = $e .target.resource.attribute.labels [" scope "] $principal_email = array_distinct ($e .principal.user.email_addresses ) $client_id = $e .principal.asset.attribute.labels [" client_id "] $client_type = $e .principal.asset.attribute.labels [" client_type "] $principal_ip = array_distinct ($e .principal.ip ) 　 condition: $e } 　 Google SecOps 環境でルールが正常にデプロイされ、検出エンジニアリングのカバレッジ評価およびギャップ緩和のワークフローが完了しました。 　 作成したルールのロジック確認 作成したルールの条件式が前手順の合成イベントで意図した通りに検出できるかを確認します。各イベントとルールの条件式を 1 件ずつ突き合わせ、判定とその理由をエージェントに示させます。 作成したルールが、先ほどの合成イベント 4 件のうちどれに一致するかを確認してほしい。推測で答えず、生成した合成イベントを実際に参照すること。イベントごとに、一致・不一致とその理由を示してほしい。 　 # 出力例 　 生成された合成イベント 4 件の UDM データを実際に参照し、作成したルール google_workspace_malicious_oauth_consent_grant の各条件と照合しました。 　 ### ルール判定条件 　 1 . $e .metadata.log_type = " WORKSPACE_ACTIVITY " 2 . $e .metadata.event_type = " USER_RESOURCE_ACCESS " 3 . $e .metadata.product_event_type = " authorize " 4 . $e .target.application = " OAuth Token " 5 . re.regex ($e .target.resource.attribute.labels[ " scope " ], ( https://mail.google.com/ | https://www.googleapis.com/auth/ ( gmail | drive | mail ))) nocase ────── ### 合成イベントごとの照合結果 　 #### イベント 1 (O365 Mail Migration への認可) 　 • 判定: 一致（Match） • UDM 参照値: • metadata.log_type: " WORKSPACE_ACTIVITY " ( 一致 ) • metadata.event_type: " USER_RESOURCE_ACCESS " ( 一致 ) • metadata.product_event_type: " authorize " ( 一致 ) • target.application: " OAuth Token " ( 一致 ) • target.resource.attribute.labels [" scope "] : " https://www.googleapis.com/auth/gmail.readonly , https://www.googleapis.com/auth/drive " ( 一致 ) • 理由: 悪意のある OAuth アプリへの認可イベントであり、機微スコープ（Gmail / Drive）が含まれているため、すべての条件に合致して検知されます。 ────── #### イベント 2 (O365 Mail Migration の権限失効) 　 • 判定: 不一致（Not Matched） • UDM 参照値: • metadata.event_type: " USER_RESOURCE_UPDATE_PERMISSIONS " ( 不一致 / ルールは USER_RESOURCE_ACCESS ) • metadata.product_event_type: " revoke " ( 不一致 / ルールは authorize ) • target.resource.attribute.labels [" scope "] : " https://www.googleapis.com/auth/gmail.readonly , https://www.googleapis.com/auth/drive " ( スコープ条件自体は合致 ) • 理由: スコープ条件には合致しますが、権限付与（authorize）ではなく権限の失効・取り消し（revoke）イベントであるため除外されます。 ────── #### イベント 3 (Zoom Integration への認可) 　 • 判定: 不一致（Not Matched） • UDM 参照値: • metadata.event_type: " USER_RESOURCE_ACCESS " ( 一致 ) • metadata.product_event_type: " authorize " ( 一致 ) • target.application: " OAuth Token " ( 一致 ) • target.resource.attribute.labels [" scope "] : " https://www.googleapis.com/auth/admin.directory.user.readonly , https://www.googleapis.com/auth/contacts " ( 不一致 ) • 理由: 権限認可イベント（authorize）ですが、付与されたスコープが連絡先（contacts）およびディレクトリ参照（admin.directory.user. readonly ）のみであり、ルールで指定した機微スコープ（Gmail / Drive / Mail）を含まないため意図どおり除外されます。 ────── #### イベント 4 (Zoom Integration の権限失効) 　 • 判定: 不一致（Not Matched） • UDM 参照値: • metadata.event_type: " USER_RESOURCE_UPDATE_PERMISSIONS " ( 不一致 ) • metadata.product_event_type: " revoke " ( 不一致 ) • target.resource.attribute.labels [" scope "] : " https://www.googleapis.com/auth/admin.directory.user.readonly , https://www.googleapis.com/auth/contacts " ( 不一致 ) • 理由: 権限失効イベント（revoke）であり、かつ機微スコープにも該当しないため除外されます。 ────── 　 作成したルールは、 4 件の合成イベントのうち 「機微スコープ（Gmail / Drive）へのアクセス権限が付与されたイベント（イベント 1 ）」のみに正確に一致し、通常のアプリ連携や失効イベントは誤検知することなく除外されています。 　 作成したルールが、今回生成した合成イベント 4 件に対して意図どおりの判定になることを確認しました。 なお、このルールは指定したスコープへの権限付与を検出するものであり、OAuth アプリ自体の悪性を判定するものではありません。本番環境で運用する場合は、許可済みアプリの除外など、環境に応じたチューニングが必要です。 参考 : YARA-L 2.0 で参照リストとデータテーブルを使用する ルールの状態確認 コンソールで [Detections] > [Rules & Detections] > [Rules Dashboard] を開き、作成したルールを確認します。 ルールの状態 作成したルールは、[LIVE STATUS] が Disabled、[ALERTING] が OFF でした。受信イベントに対する検出を開始するには [LIVE STATUS] を、検出結果をアラートとして扱う場合は [ALERTING] を、それぞれ有効にします。 参考 : ライブデータにルールを適用する 三浦 健斗 (記事一覧) クラウドソリューション部 2023年10月よりG-genにジョイン。元オンプレ中心のネットワークエンジニア。 ネットワーク・セキュリティ・唐揚げ・辛いものが好き。 Google Cloud Partner All Certification Holders 2025 / Google Cloud Partner Top Engineer 2026

G-gen の河野です。当記事では、Google が開発した最適化問題を解くためのオープンソースライブラリ「 OR-Tools 」を使用して、製品の生産計画を作成します。 OR-Tools とは 仕様 解きたい最適化問題の定義 ソルバーの決定 最適化問題を解く API 版との比較 検証 検証内容 データ処理フロー データ準備 OR-Tools のインストール Python コード 検証結果 出力結果 処理プロセス OR-Tools とは OR-Tools は、Google が開発した、 最適化問題 を解くためのオープンソースライブラリです。 最適化問題とは、「限られたルールの中で、最適な答えを見つける問題」のことで、複数の配達先を回る最も効率的なルートの決定や、工場での無駄のない生産計画の作成などがあります。OR-Tools を使うことで、本来であれば組み合わせが多すぎて手作業では見つけられない最適解を、数学的に導き出すことができます。 参考 : OR-Tools について OR-Tools には、以下のような利用事例が考えられます。 物流・配送ルート最適化 車両の積載容量、配送指定時間などの制約を考慮し、最短ルートや最少車両数での配送計画を作成できます。 シフトスケジューリング 必要な人員数、従業員の希望休、スキル要件などの制約を考慮し、公平で効率的な勤務表を作成できます。 タスク割り当て 各人の処理能力、タスクの優先度などの制約を考慮し、作業時間の最小化やリソースの最適配置を実現できます。 生産計画 機械の稼働能力、製品ごとの所要時間、需要などの制約を考慮した最適な生産計画を作成できます。 仕様 解きたい最適化問題の定義 OR-Tools で最適化問題を解く際は、まず、どのような問題を解くのかを定義します。最適化問題は以下の3つの要素から定義されます。 要素 説明 例 決定変数 求めたい答え 生産数 制約 答えを求める上で考慮すべきルール 機械の処理能力 目的関数 何を最大/最小化したいかという目標 利益の最大化 上記の表の例は、「限られた機械の処理能力（制約）の中で、利益を最大化（目的関数）するための最適な生産数（決定変数）を求める」という問題を定義しています。 ソルバーの決定 OR-Tools は、 ソルバー と呼ばれる最適化アルゴリズムを用いて、定義した最適化問題を解きます。ソルバーは、「制約」を全て満たしながら「目的関数」が最適となる「決定変数」の値を探索します。ソルバーにはいくつかの種類があり、それぞれ得意・不得意が存在します。OR-Tools に標準搭載されているソルバーは以下の3種類です。 ソルバー 得意な問題 主な用途例 CP-SAT 「何個・どれを・いつ」という整数で答えが出る問題 生産計画、シフトスケジューリング、配送ルート最適化 GLOP 比率や量の配分など、小数で答えが出る問題 リソース配分、原材料の配合比率最適化 PDLP GLOP と同じく小数で答えが出るが、変数・制約が膨大な問題 数百万規模の変数・制約を持つ大規模な最適化 参考 : OR-Tools とその解法の引用方法 最適化問題を解く 以下の最適化問題を例に、ソルバーがどのように問題を解くのかを説明します。 要素 内容 決定変数 製品A、Bの生産数 制約 稼働可能時間は 100 分、製品Aの加工時間は 20 分/個、製品Bの加工時間は 30 分/個 目的関数 利益（製品Aは 1 個 500 円、製品Bは 1 個 800 円）の最大化 以下の3ステップで、ソルバーは最適化問題を解きます。 ① 制約による探索範囲の絞り込み 稼働時間上限（100 分）の制約から、各決定変数の上限を算出する 製品A（加工時間 20 分/個）：100 分 ÷ 20 分 = 最大 5 個 製品B（加工時間 30 分/個）：100 分 ÷ 30 分 = 最大 3 個 ② 決定変数への値の割り当て 絞り込んだ範囲の中で決定変数に値を1つずつ割り当て、目的関数の値を記録する 「製品Aを 0 個」に設定すると、稼働可能時間は残り 100 分であるため「製品Bは最大 3 個まで加工可能」となり、「製品A=0 / 製品B=3 / 利益 2,400 円」が記録される ③ 目的関数の値をもとにした最適解の更新 ②の処理を反復し、記録された目的関数の値を上回る結果が算出されるたびに、最適解を更新する 製品A 製品B 総利益 結果 0 個 3 個 2,400 円 最適解を更新 1 個 2 個 2,100 円 更新なし（2,400 円を下回るため） 2 個 2 個 2,600 円 最適解を更新 製品A = 3〜5 個のパターンにおいて、残りの稼働可能時間を最大限使っても暫定の最適解を上回らないため、 製品A=2・製品B=2（総利益 2,600 円） が最適解として確定する API 版との比較 Google が提供する最適化問題を解くためのツールとしては、OR-Tools の他に Operations Research API があります。これらのツールの主な違いは以下の通りです。 観点 OR-Tools Operations Research API 実行方法 ライブラリを用いた関数呼び出し（Python、C++、Java、C#） REST API、gRPC 計算処理担当 実行サーバー上 Google のクラウドインフラ上 カスタマイズ性 高い（制約・目的関数を自由設計） 低い（用意された設定の範囲内） 使用制限 なし リクエスト数・データサイズ・実行時間に上限あり 成熟度 安定版 アルファ / ベータ段階（2026年7月現在） 費用 無料 無料（安定版リリースで変更の可能性あり） 参考 : Operations Research API 検証 検証内容 Python の OR-Tools ライブラリを使い、製品の生産計画を作成します。今回は、CP-SAT ソルバーで以下の最適化問題を解きます。 要素 内容 決定変数 生産数 制約 各製品の生産数が需要数を超えないこと、各機械の稼働可能時間上限を超えないこと 目的関数 総利益の最大化（利益単価 × 生産数の合計） 製品マスタなどの源泉データの格納、および処理結果の出力先には BigQuery を採用します。 データ処理フロー 本検証では、BigQuery からデータを読み込み、OR-Tools で最適化計算を行った後、計算結果を BigQuery に書き込みます。 データ準備 BigQuery に以下のレコード内容でテーブルを作成します。 products（製品マスタ） 製品ID 利益単価（円/個） P001 1,000 P002 4,000 process_times（サイクルタイムマスタ） 製品ID 機械ID 加工時間（分/個） P001 M01 30 P002 M01 60 demand_forecast（需要予測） 製品ID 需要日 需要数 P001 2025-07-01 8 P002 2025-07-01 5 machine_calendar（設備稼働カレンダー） 機械ID 日付 稼働可能時間（分） M01 2025-07-01 360 OR-Tools のインストール 以下のコマンドでライブラリをインストールすることで、OR-Tools が使用できます。 pip install ortools Python コード OR-Tools を実行するためのコードを作成します。 from ortools.sat.python import cp_model import pandas as pd from google.cloud import bigquery # --- 設定 --- PROJECT_ID = "your-project-id" DATASET_ID = "your_dataset" plan_date = "2025-07-01" # --- BigQuery からデータ読み込み --- client = bigquery.Client(project=PROJECT_ID) products_df = client.query(f "SELECT * FROM `{PROJECT_ID}.{DATASET_ID}.products`" ).to_dataframe() process_df = client.query(f "SELECT * FROM `{PROJECT_ID}.{DATASET_ID}.process_times`" ).to_dataframe() demand_df = client.query(f "SELECT * FROM `{PROJECT_ID}.{DATASET_ID}.demand_forecast` WHERE `需要日` = '{plan_date}'" ).to_dataframe() demand_df[ "需要日" ] = pd.to_datetime(demand_df[ "需要日" ]) calendar_df = client.query(f "SELECT * FROM `{PROJECT_ID}.{DATASET_ID}.machine_calendar` WHERE `日付` = '{plan_date}'" ).to_dataframe() calendar_df[ "日付" ] = pd.to_datetime(calendar_df[ "日付" ]) # --- 辞書化 --- products = products_df[ "製品ID" ].tolist() machines = calendar_df[ "機械ID" ].unique().tolist() dates = sorted (demand_df[ "需要日" ].unique()) demand = {(r.製品ID, r.需要日): r.需要数 for r in demand_df.itertuples()} capacity = {(r.機械ID, r.日付): r.稼働可能時間_分 for r in calendar_df.itertuples()} process_time = {(r.製品ID, r.機械ID): r.加工時間_分 for r in process_df.itertuples()} profit = dict ( zip (products_df[ "製品ID" ], products_df[ "利益単価" ])) # --- ソルバーの決定 --- # CP-SAT を利用 model = cp_model.CpModel() # --- 最適化問題の定義 --- # 決定変数: 製品p・機械m・日付d の生産数 assign = { (p, m, d): model.NewIntVar( 0 , demand[(p, d)], f "x_{p}_{m}_{d}" ) for d in dates for p in products for m in machines if (p, m) in process_time and (p, d) in demand } # 制約1: 各製品の合計生産量 <= 需要数 for d in dates: for p in products: vars_ = [assign[(p, m, d)] for m in machines if (p, m, d) in assign] if vars_: model.Add( sum (vars_) <= demand.get((p, d), 0 )) # 制約2: 各機械の稼働可能時間を超えない for d in dates: for m in machines: vars_ = [assign[(p, m, d)] * int (process_time[(p, m)] * 10 ) for p in products if (p, m, d) in assign] if vars_: model.Add( sum (vars_) <= capacity.get((m, d), 0 ) * 10 ) # 目的関数: 利益単価 × 生産数 の合計を最大化 model.Maximize( sum (var * profit.get(p, 0 ) for (p, m, d), var in assign.items())) # --- 実行 --- solver = cp_model.CpSolver() status = solver.Solve(model) # --- BigQuery へ出力 --- if status in (cp_model.OPTIMAL, cp_model.FEASIBLE): results = [ { "生産日" : str (d.date()), "製品ID" : p, "機械ID" : m, "計画生産数" : solver.Value(var), "利益合計" : solver.Value(var) * profit.get(p, 0 ), } for (p, m, d), var in assign.items() if solver.Value(var) > 0 ] result_df = pd.DataFrame(results) job = client.load_table_from_dataframe( result_df, f "{PROJECT_ID}.{DATASET_ID}.production_plan" , job_config=bigquery.LoadJobConfig(write_disposition= "WRITE_TRUNCATE" ), ) job.result() 検証結果 出力結果 作成したコードを実行すると、BigQuery で以下の結果が出力されます。 production_plan（生産計画） 生産日 製品ID 機械ID 計画生産数 利益合計 2025-07-01 P001 M01 2 2,000 円 2025-07-01 P002 M01 5 20,000 円 処理プロセス solver.Solve(model) を呼び出すと、CP-SAT ソルバーが以下の流れで最適解を導き出します。 ① 制約による探索範囲の絞り込み 稼働時間上限（360 分）と需要上限の2つの制約から、各決定変数の上限を算出する P001（加工時間 30 分/個）：360 分 ÷ 30 分 = 最大 12 個 → 需要上限 8 個と比較して 0〜8 個 に確定 P002（加工時間 60 分/個）：360 分 ÷ 60 分 = 最大 6 個 → 需要上限 5 個と比較して 0〜5 個 に確定 ② 決定変数への値の割り当て 絞り込んだ範囲の中で決定変数に値を1つずつ割り当て、目的関数の値を記録する 「P001 の生産数を 0 個」に設定すると、「P002 は最大 5 個（需要上限）まで加工可能」となり、「P001=0 / P002=5 / 利益 20,000 円」が記録される ③ 目的関数の値をもとにした最適解の更新 ②の処理を反復し、最適解の探索を行う P001 P002 総利益 結果 0 個 5 個 20,000 円 最適解を更新 1 個 5 個 21,000 円 最適解を更新 2 個 5 個 22,000 円 最適解を更新 P001 = 3〜8 個のパターンにおいて、残りの稼働可能時間を最大限使っても暫定の最適解を上回らないため、 P001 = 2・P002 = 5（総利益 22,000 円） が最適解として確定する 河野 利紀 (記事一覧) クラウドソリューション部 デジタルワークプレイス課 2025年10月にG-genに入社。 神奈川在住で、Google Cloud をマスターするため日々エンジニアとして修行中。

G-gen の西原です。Google Workspace 版の Gemini アプリの一時チャットと会話履歴の削除機能について、概要やデータ保存の仕様、管理コンソールでの制御手順を解説します。 概要 一時チャットとは チャット履歴の個別削除とは チャット履歴保存の仕様 通常チャット 一時チャット データの取り扱いとプライバシー 想定されるユースケース 一時チャットのユースケース 通常チャットのユースケース 管理者設定 Google 管理コンソールでの設定手順 Google Vault による保持 概要 一時チャットとは 一時チャット （Temporary Chats）とは、履歴に残らない特別なチャットセッションの中で Gemini アプリと会話ができる機能です。このモードで開始された会話は、チャットを閉じるとサイドバーの履歴一覧には表示されなくなります。その場限りの独立したブレインストーミングや、一時的なテキストの校正などに最適です。 チャット画面で右上のアイコン（画像赤枠）を押下することで、一時チャットを開始できます。 参考 : Gemini アプリで一時的なチャットとチャットの削除を管理する チャット画面で右上のアイコン（画像赤枠）を押下 一時チャット画面 チャット履歴の個別削除とは チャット履歴の個別削除とは、過去に Gemini アプリと行ったやり取りの中から、特定の会話を選択して個別に削除できる機能です。この機能により、不要になった古い会話や整理したい特定の会話だけをピンポイントで削除できるようになり、サイドバーの履歴画面をクリーンに保てます。 Gemini アプリの左部ペインから、削除したいチャット履歴の右側の三点リーダーを押下すると、プルダウンメニューが表示されます。ここで「削除」を選択することで、チャット履歴を削除できます。 参考 : Gemini アプリで一時的なチャットとチャットの削除を管理する 削除したいチャット履歴の右側の三点リーダーから削除を選択 チャット履歴保存の仕様 通常チャット 通常のチャット（一時チャットではない通常のセッション）では、ユーザーが手動で削除しない限り、履歴は保存されます。これにより、過去の指示内容（プロンプト）や、Gemini アプリから得られた回答をいつでも見返し、再使用できます。 通常のチャット履歴の仕様は以下のとおりです。 項目 仕様の詳細 履歴への表示 サイドバーの履歴一覧に常時表示される ユーザーによる削除 個別削除機能により、特定のセッションのみを削除可能 一時チャット 一時チャットは、ユーザーの画面上からはチャット終了後に即座に消去されます。 ただし、Google がバックエンドでデータを保存する仕様には注意が必要です。 Google の公式ドキュメントによると、一時チャットの内容はユーザーの履歴には表示されませんが、バックエンドで最大 72 時間保持されます。したがって、ユーザーの画面から消えても Google のサーバーから完全にリアルタイムで抹消されるわけではありません。ただし、このデータが外部に漏洩したり、一般の生成 AI モデルのトレーニングに使用されたりすることはない、とされています。 参考 : Gemini アプリのプライバシー ハブ また後述のように、組織で Google Vault が使用されている場合は、バックエンドに会話履歴が保存されており、管理者からデータを確認することが可能です。 データの取り扱いとプライバシー Google Workspace ユーザーが最も懸念する点の一つが、「入力したデータが AI の学習データとして使用されるのではないか」という点です。 Google Workspace 向けに提供されている Gemini サービスにおいて、ユーザーが入力したプロンプトや生成された回答は、Google の一般モデルのトレーニング（学習）に使用されることは一切ありません。これは、通常チャットであっても、一時チャットであっても同様です。企業の機密情報や社内データは保護されます。この仕様は、 エンタープライズグレードのデータ保護 と呼ばれます。 またこのデータ保護は Gemini アプリに限った話ではなく、Google Workspace に統合されているすべての AI 機能に共通で適用されます。 参考 : Google Workspace の生成 AI に関するプライバシー ハブ 想定されるユースケース 一時チャットのユースケース 一時チャットは、例として以下のような後から見返す必要性が低い作業に最適です。これらの作業を一時チャットで行うことで、通常のチャット履歴が不要な情報で埋め尽くされるのを防ぐことができます。 文章の単純な校正・翻訳 既存のメール文を英語に翻訳したり、誤字脱字をチェックしたりするだけの作業。 単発のコードデバッグ プログラミング中に出た短いエラーログの原因を特定するためだけの質問。 通常チャットのユースケース 反対に、以下のような「継続的なプロジェクトや、後からプロセスを確認したい作業」では、通常チャットを使用することが推奨されます。ただし、通常チャットに不要なやり取りが混ざってしまった場合でも、チャット履歴の個別削除により履歴を整理することができます。 アイデアの壁打ち まとまっていないブレインストーミングの段階で、キーワードをランダムに投入してアイデアを出す作業。 長期間にわたる企画書の作成 何日かに分けて、徐々にプロンプトをブラッシュアップしながらドキュメントを作り上げる場合。 複雑な調査業務 特定の技術や市場動向などについて、複数の角度から質問を重ねて深い知見を得る場合。 管理者設定 Google 管理コンソールでの設定手順 管理者は、組織部門（OU）や構成グループごとに、ユーザーが「一時チャット」や「履歴の個別削除」を使用できるかどうかを制御できます。具体的な設定手順のイメージは以下のとおりです。 [Google 管理コンソール] に管理者アカウントでログインします。 メニューから [生成 AI] ＞ [Gemini アプリ] ＞ [Gemini との会話の履歴と管理] の項目へと進みます。 新しく追加された [一時チャットと会話の削除コントロール] を確認します。 対象の組織部門を選択し、機能を「許可する」または「制限する」に設定し、[保存] をクリックします。 参考 : Gemini アプリで一時的なチャットとチャットの削除を管理する - 一時チャットとチャットの削除をオンにする Google Vault による保持 企業の法務部門やコンプライアンス担当者が確認すべき点として、Google Vault との連携仕様が挙げられます。 通常チャットの削除 ユーザーが手動で個別にチャットを削除した場合、そのデータはユーザーの画面には表示されなくなります。しかし組織で Google Vault が使用されている場合、Google Vault の保持ルールに従って管理者側で検索・エクスポートが可能です。 一時チャットのデータ保持 一時チャットとして実行された会話データが監査・保持の対象となるかは、組織の Google Vault の使用状況に依存します。Google Vault を使用している組織では、ユーザーが一時チャットを使用した場合でも、Google Vault の保持ルールが優先され、ユーザーには見えないところでデータが保存されます。このデータは、管理者側で検索・エクスポートが可能です。 参考 : Gemini アプリで一時的なチャットとチャットの削除を管理する - Vault と一時チャット、チャットの削除 西原 正真 (記事一覧) 事業開発部 クラウドサポート課 大阪府出身、北海道在住。2026年5月よりG-genにジョイン。 現在は Google Workspace を中心に、カスタマーサポートに従事。 Google Cloud 全 14 資格保有。 好きなものは写真と旅行。

G-gen の佐々木です。当記事では、Cloud Run にデプロイした AI エージェントや MCP サーバーにエージェント ID を割り当て、Agent Registry に自動登録する「 Cloud Run の Agent Platform 機能 」について解説します。 前提知識 Cloud Run とは Gemini Enterprise Agent Platform とは Agent Platform の概要 Agent Identity Agent Registry Cloud Run の Agent Platform 機能とは Agent Platform 機能の基本 機能タイプとアイデンティティタイプ 組み合わせによる挙動 エージェント ID への権限付与 自動付与される事前定義ロール Agent Registry への自動登録 注意点 制限事項 設定手順 当記事で扱う手順 事前準備 エージェントのデプロイ MCP サーバーのデプロイ 既存サービスの移行 エージェント ID の確認 Agent Registry での確認 エージェントの認証 Google Cloud API への認証 他の Cloud Run 上のエージェント・MCP サーバーへの認証 バインドトークンによる保護の強化 動作確認 検証構成 エージェントのソースコード デプロイ エージェントの呼び出し ロール付与前の動作 ロールの付与 ロール付与後の動作 監査ログでの確認 前提知識 Cloud Run とは Cloud Run は、コンテナを実行するための Google Cloud のフルマネージドなサーバーレスコンピューティングサービスです。サーバーの管理を必要とせず、コンテナイメージを指定するだけでアプリケーションを実行できます。 Cloud Run にはユースケースに応じたリソースタイプが存在し、Web アプリケーションや API のホスティング向けの Cloud Run services（以下、 サービス と記載）、バッチ処理やスケジュール実行向けの Cloud Run jobs（以下、 ジョブ と記載）、メッセージキューの pull 型処理向けの Cloud Run worker pools、長時間動作するエージェントなど、スケールしない単一プロセスの常駐向けの Cloud Run instances が提供されています。 Cloud Run の基本については、以下の記事を参照してください。 blog.g-gen.co.jp Gemini Enterprise Agent Platform とは Agent Platform の概要 Gemini Enterprise Agent Platform （旧称 Vertex AI、以下 Agent Platform と記載）は、AI エージェントの構築・デプロイ・管理のための機能群を提供する Google Cloud のプラットフォームです。 このうち、エージェントの統制を担う機能として、エージェント固有の ID を発行する Agent Identity 、エージェントやツールを登録して検出可能にする Agent Registry 、これらを参照して通信を制御する Agent Gateway があります。 Agent Platform の全体像については、以下の記事を参照してください。 blog.g-gen.co.jp Agent Identity Agent Identity は、Agent Platform のワークロード認証コンポーネントです。AI エージェントや MCP サーバーなどのワークロードに、ワークロードごとに固有で、証明書によって検証可能な ID（ エージェント ID ）を割り当てます。 エージェント ID は SPIFFE（Secure Production Identity Framework for Everyone）標準に基づく書式を持ち、IAM 許可ポリシーでは principal:// から始まるプリンシパル識別子として指定します。 エージェント ID は、サービスアカウントと異なり、複数のワークロード間で共有されず、権限借用もできず、長期キーも生成できません。Google Cloud API 向けのアクセストークンはワークロードの X.509 証明書と結び付けて発行されるため、トークンが窃取されても他のワークロードから再利用できません。 当記事では、この Agent Identity を Cloud Run のサービスやジョブで有効にし、割り当てられたエージェント ID で認証する方法を解説します。 Agent Identity の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp Agent Registry Agent Registry は、組織内で承認されたエージェントやツールを登録し、他の開発者やエージェントから検出可能にする Agent Platform の中央ライブラリです。エージェントはエージェントカタログに、MCP サーバーは MCP サーバーカタログに登録されます。Google Cloud 上のエージェントだけでなく、サードパーティの MCP サーバーも登録できます。 登録されたメタデータは、Agent Gateway がアクセス制御を行う際にも参照されます。ただし、2026年9月現在、Agent Gateway が通信を制御できるランタイムは Agent Runtime（旧称 Agent Engine）と Gemini Enterprise のみで、Cloud Run 上のエージェントは制御の対象外です。 当記事では、Cloud Run のワークロードが Agent Registry に自動登録される仕組みと、登録されたエントリの確認方法を解説します。 Agent Registry、Agent Gateway の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp blog.g-gen.co.jp Cloud Run の Agent Platform 機能とは Cloud Run の Agent Platform 機能 （Agent Platform features for Cloud Run）は、Cloud Run のサービスやジョブで Agent Identity と Agent Registry を有効にする機能です。対象となるワークロードは、AI エージェントと MCP サーバーです。デプロイ時にワークロードの用途（エージェントまたは MCP サーバー）と ID の種類を宣言するだけで、以下の2つが自動で行われます。 ワークロードに対して、ワークロード固有で、証明書によって本物であることを検証できるエージェント ID が割り当てられる ワークロードがプロジェクトの Agent Registry に自動登録され、他の開発者やエージェントから検出可能になる 従来、Cloud Run のワークロードは、サービスアカウントを使用して他のサービスや Google Cloud API への認証を行っていました。Agent Platform 機能を使用すると、エージェントはサービスアカウントの代わりに自身専用のエージェント ID で他のエージェント・ツール・Google Cloud API に認証できます。 なお、Cloud Run には4種類のリソースタイプがありますが、2026年9月現在、Agent Platform 機能を設定できるのはサービスとジョブの2種類です。 参考 : Configure Agent Platform features for Cloud Run 参考 : Authenticate your AI agents この機能は2026年9月1日に Preview 公開されました。Preview 段階の機能は、サポートが限定される場合や、GA までに仕様が変わる可能性があるため、本番環境での使用は推奨されません。 参考 : Cloud Run release notes - September 01, 2026 参考 : Preview版のサービスを使うとはどういうことなのか Agent Platform 機能の基本 機能タイプとアイデンティティタイプ Agent Platform 機能は、Cloud Run のサービスやジョブに 機能タイプ （functional type）と アイデンティティタイプ （identity type）の2つのプロパティを設定することで構成します。gcloud CLI では、デプロイ時に --functional-type と --identity-type の2つのフラグで指定します。 # 機能タイプとアイデンティティタイプを指定してデプロイ # 機能タイプ=agent、アイデンティティタイプ=agent-identity の例 $ gcloud beta run deploy < サービス名 > \ --image =< コンテナURL > \ --functional-type = agent \ --identity-type = agent-identity \ --region = asia-northeast1 --project =< プロジェクトID > エージェントと MCP サーバーそれぞれのデプロイコマンドは、後述の設定手順で解説します。 機能タイプは、ワークロードの主な用途を宣言するプロパティです。一度設定すると変更や解除ができません。 機能タイプ 意味 制約 agent ワークロードを AI エージェントとして登録する アイデンティティタイプは agent-identity が必須 mcp-server ワークロードをユーザー管理の MCP サーバーとして登録する どちらのアイデンティティタイプも使用できる アイデンティティタイプは、ワークロードに割り当てる ID の種類を指定するプロパティです。 アイデンティティタイプ 意味 agent-identity システム管理のエージェント ID を割り当てる。ID 証明書がデフォルトで有効になる service-account 従来どおりの Google Cloud サービスアカウントを使用する agent-identity を指定してデプロイすると、Agent Platform はワークロードの ID 証明書（X.509 証明書）をデフォルトで有効にします。証明書を使用しない場合は、 --no-identity-certificate フラグを付けるか、アノテーション run.googleapis.com/identity-certificate-enabled: "false" を設定します。 機能タイプ mcp-server では、アイデンティティタイプに service-account を指定するか省略すると、従来どおりサービスアカウントで動作します。この場合、MCP サーバーから Google Cloud API や他のサービスへの認証は、これまでと同じくサービスアカウントで行われます。 組み合わせによる挙動 機能タイプとアイデンティティタイプの組み合わせによって、ワークロードの挙動は以下のように変わります。 機能タイプ アイデンティティタイプ 挙動 agent agent-identity Agent Registry にエージェントとして登録され、エージェント ID が割り当てられる agent その他、または未指定 エラーになる mcp-server agent-identity 、 service-account 、または未指定 Agent Registry に MCP サーバーとして登録される。未指定の場合はサービスアカウントが使用される 未指定 service-account 通常の Cloud Run サービスまたはジョブとして動作する 機能タイプに agent を指定してアイデンティティタイプを省略すると、デプロイはサーバー側で拒否されます。gcloud CLI はデプロイ前に警告を表示しますが処理は止まらず、以下のエラーで失敗します。 ERROR: (gcloud.beta.run.deploy) spec.template.spec.identity_type: Identity type must be AGENT when functional type is AGENT. エージェント ID への権限付与 agent-identity を設定した Cloud Run のワークロードには、以下の形式のエージェント ID が割り当てられます。ワークロードが Google Cloud API や他の Cloud Run サービスにアクセスするための権限は、サービスアカウントの代わりにこのエージェント ID に対して付与します。IAM 許可ポリシーでは、この文字列をそのままプリンシパルとして指定します。 principal://agents.global.org-<組織ID>.system.id.goog/resources/run/projects/<プロジェクト番号>/locations/<リージョン>/services/<サービス名> エージェント ID で動作するリビジョンでは、サービスアカウントは使用されません。サービスアカウントに付与していたロールは残りますが、そのリビジョンからは参照されないため、必要なロールはエージェント ID に付け直します。 サービスアカウントではなくエージェント ID に権限を付与する利点は、権限の付与先とワークロードが1対1で対応する点です。エージェント ID はワークロードごとにシステムが自動で割り当てるため、サービスアカウントを作成して管理する手間がなく、複数のワークロードで1つの ID を共有して権限が過剰になることもありません。 また、権限借用や長期キーの発行ができないうえ、アクセストークンはワークロードの X.509 証明書に紐づくため、認証情報の漏洩や再利用のリスクも抑えられます。 監査ログにはプリンシパルとしてエージェント ID が記録されるため、どのワークロードが操作したかを個別に追跡できます。 組織に属さないプロジェクトでは、トラストドメイン（ principal:// の直後から /resources/ までの部分）の org-<組織ID> が project-<プロジェクト番号> になります。 principal://agents.global.project-<プロジェクト番号>.system.id.goog/resources/run/projects/<プロジェクト番号>/locations/<リージョン>/services/<サービス名> なお、Cloud Run のジョブの場合は末尾が jobs/<ジョブ名> になります。 principal://agents.global.org-<組織ID>.system.id.goog/resources/run/projects/<プロジェクト番号>/locations/<リージョン>/jobs/<ジョブ名> ジョブに割り当てられた ID は、ジョブ自体ではなく実行（execution）の詳細に表示されます。gcloud CLI では gcloud beta run jobs executions describe 、コンソールではジョブの「実行」タブから実行を選択して確認します。 エージェント ID は Agent Runtime や Gemini Enterprise のエージェントにも割り当てられますが、 resources/ 直後のサービス名の部分が run になっている点が Cloud Run の ID の特徴です。 参考 : エージェント ID の概要 参考 : Principal identifiers 自動付与される事前定義ロール プロジェクトで初めて機能タイプ agent のワークロードをデプロイすると、Google Cloud はそのプロジェクトの IAM ポリシーに以下のロールバインディングを自動で追加します。 ロール プリンシパル Cloud Run Agent - Agent Default Access Role（ roles/run.agentDefaultAccess ） principalSet://agents.global.org-<組織ID>.system.id.goog/attribute.platformContainer/run/projects/<プロジェクト番号> プリンシパルの principalSet:// 形式は、そのプロジェクトの Cloud Run 上で動作するすべてのエージェント ID をまとめて指すプリンシパルセットです。 このロールには、Agent Platform の推論（ aiplatform.endpoints.predict ）に加えて、Cloud Logging・Cloud Monitoring・Cloud Trace への書き込み権限が含まれます。 # 自動付与された事前定義ロールの内容を表示（2026年9月現在） $ gcloud iam roles describe roles/run.agentDefaultAccess ----- 出力例 ----- description: Default role for Cloud Run Agent identities providing basic AI and telemetry access. includedPermissions: - aiplatform.endpoints.predict - cloudtrace.traces.patch - logging.logEntries.create - logging.logEntries.route - monitoring.metricDescriptors.create - monitoring.metricDescriptors.get - monitoring.metricDescriptors.list - monitoring.monitoredResourceDescriptors.get - monitoring.monitoredResourceDescriptors.list - monitoring.timeSeries.create - telemetry.traces.write - trafficdirector.networks.getConfigs - trafficdirector.networks.reportMetrics name: roles/run.agentDefaultAccess stage: ALPHA title: Cloud Run Agent - Agent Default Access Role プロジェクト内の Cloud Run に紐づくエージェント ID 全てに Cloud Run Agent - Agent Default Access Role ロールが付与されている このため、Cloud Run 上のエージェントは追加のロール付与なしで、Agent Platform 経由で Gemini モデルの generateContent を呼び出せます。一方で、Cloud Storage や BigQuery など他の Google Cloud API へのアクセスには、後述の手順でエージェント ID に個別のロールを付与する必要があります。 Agent Registry への自動登録 機能タイプを agent または mcp-server に設定してデプロイした Cloud Run のリソースは、同じプロジェクトの Agent Registry に自動登録されます。エージェントはエージェントカタログ（ /agents ）に、MCP サーバーは MCP サーバーカタログ（ /mcpServers ）に登録されます。なお、自動登録の対象は同じプロジェクト内のリソースのみで、他のプロジェクトにデプロイしたエージェントを登録するには手動登録が必要です。 登録先のロケーションは Cloud Run のリソースと同じリージョンです。Cloud Run のジョブも、機能タイプ agent で作成するとエージェントとして登録されます。 Agent Registry は、登録時にエージェントからメタデータの取得を試みます。A2A プロトコルに対応したエージェントでは、 /.well-known/agent-card.json の Agent Card からスキルなどのメタデータが取り込まれます。A2A に対応していないエージェントでは、登録されたエントリに ID とランタイムへの参照（ RuntimeReference ）が設定されるだけで、説明やスキルなどのメタデータは自動では取り込まれません。 参考 : エージェントを登録する - 自動登録 参考 : 自動登録を使用する 注意点 機能タイプとアイデンティティタイプは一度設定すると変更や解除ができません。たとえば機能タイプ agent のサービスを mcp-server に変更しようとすると、以下のエラーになります。 ERROR: (gcloud.beta.run.services.update) spec.functional_type: Functional type cannot be updated or unset once set. また、サービスアカウントで動作している既存のサービスに、あとから Agent Platform 機能を設定してエージェント ID に切り替える場合、Cloud Run はそのサービスに新しいエージェント ID を割り当てます。 このエージェント ID は、以前のサービスアカウントに付与されていた権限を引き継ぎません。 接続断を避けるため、Policy Analyzer で必要なロールを洗い出して事前に付与するか、 --no-traffic フラグを付けて更新し、権限を付与してからトラフィックを移行してください。 参考 : 許可ポリシー用の Policy Analyzer 制限事項 2026年9月現在、以下の制限があります。 Agent Platform 機能を設定できるのは Cloud Run のサービスとジョブのみ。worker pools と instances には設定できない Agent Gateway の制御対象となるランタイムは Agent Runtime と Gemini Enterprise のみで、Cloud Run 上のエージェントは対象外。Cloud Run のエージェントに対する通信制御は、IAM ポリシーによる呼び出し元の制限や Identity-Aware Proxy（以下、IAP と記載）で行う 設定に使用する gcloud CLI のコマンドは、公式ドキュメントでは gcloud beta run コマンド群で案内されている Agent Identity の制限として、Cloud Storage のレガシー バケットロール（ roles/storage.legacyBucketReader など）はエージェント ID に付与できない 設定手順 当記事で扱う手順 当記事では、gcloud CLI を使用して Cloud Run のサービスに Agent Platform 機能を設定し、割り当てられたエージェント ID で Google Cloud API と他の Cloud Run サービスに認証する手順を扱います。 動作確認では、Agent Development Kit（以下、ADK と記載）で作成した BigQuery のデータ分析エージェントをエージェント ID 付きでデプロイし、ロール付与の前後で BigQuery へのアクセスがどう変わるかを示します。 開発者のローカル環境から IAP 経由で MCP サーバーに接続する手順と、Agent Identity auth manager を使ってエージェントがユーザーの代理で外部サービスに認証する方法は、当記事では扱いません。auth manager については、以下のドキュメントを参照してください。 参考 : エージェント ID 認証マネージャーの概要 参考 : ツールとリソースに対する認証 なお、当記事の記述については、記事を執筆した2026年9月現在のプロダクト仕様に基づいている点に注意してください。最新の製品仕様やアーキテクチャ、ベストプラクティスについては公式ドキュメントを参照し、確認してください。 事前準備 プロジェクトで以下の API を有効化します。 # 必要な API を有効化 $ gcloud services enable \ run.googleapis.com \ iam.googleapis.com \ agentregistry.googleapis.com \ apphub.googleapis.com \ --project =< プロジェクトID > Agent Registry API を有効化すると、そのプロジェクトで Agent Registry が使用できるようになります。 参考 : エージェント レジストリを設定する エージェントのデプロイ 機能タイプに agent 、アイデンティティタイプに agent-identity を指定してサービスをデプロイします。 # エージェントとしてサービスをデプロイ $ gcloud beta run deploy agent-a \ --image =< コンテナURL > \ --functional-type = agent \ --identity-type = agent-identity \ --region = asia-northeast1 --project =< プロジェクトID > ----- 出力例 ----- WARNING: Updating the functional type to an agent also requires updating its identity to agent_identity. Make sure to update the IAM policies on the agent_identity to ensure no issues with connectivity to other services. Deploying container to Cloud Run service [ agent -a] in project [< プロジェクトID >] region [ asia-northeast1 ] Deploying new service... Creating Revision.................................................................................done Routing traffic.....done Done. Service [ agent -a] revision [ agent-a-00001-nmz ] has been deployed and is serving 100 percent of traffic. Service URL: https://agent-a- < プロジェクト番号 > .asia-northeast1.run.app 冒頭の WARNING は、アイデンティティタイプを正しく指定していても毎回表示されます。エージェント ID に対する IAM ポリシーの整備を促す内容で、デプロイ自体は正常に完了します。 MCP サーバーのデプロイ 機能タイプに mcp-server を指定します。アイデンティティタイプは任意で、省略した場合はサービスアカウントが使用されます。 # MCP サーバーとしてサービスをデプロイ（アイデンティティタイプは省略） $ gcloud beta run deploy mcp-a \ --image =< コンテナURL > \ --functional-type = mcp-server \ --region = asia-northeast1 --project =< プロジェクトID > MCP サーバーにもエージェント ID を割り当てる場合は、 --identity-type=agent-identity を追加します。Cloud Run で MCP サーバーをホストする方法については、以下のドキュメントを参照してください。 参考 : Cloud Run で MCP サーバーをホストする 既存サービスの移行 サービスアカウントで動作している既存のサービスをエージェント ID に切り替える場合は、 --no-traffic を付けて更新します。新しいリビジョンはトラフィックを受けない状態で作成されます。 # 既存サービスをエージェント ID に更新（トラフィックは移行しない） $ gcloud beta run services update plain-svc \ --functional-type = agent \ --identity-type = agent-identity \ --no-traffic \ --region = asia-northeast1 --project =< プロジェクトID > ----- 出力例 ----- WARNING: Updating the functional type to an agent also requires updating its identity to agent_identity. Make sure to update the IAM policies on the agent_identity to ensure no issues with connectivity to other services. Deploying... Creating Revision......................done Routing traffic.....done Done. Service [ plain-svc ] revision [ plain-svc-00002-k94 ] has been deployed and is serving 0 percent of traffic. リビジョンの一覧を確認すると、新しいリビジョンは作成済みですが、トラフィックを受けているのは旧リビジョンのままです。 # リビジョンの一覧を表示 $ gcloud run revisions list --service = plain-svc --region = asia-northeast1 --project =< プロジェクトID > ----- 出力例 ----- REVISION ACTIVE SERVICE DEPLOYED DEPLOYED BY ✔ plain-svc-00002-k94 plain-svc 2026-09-02 01:14:45 UTC < ユーザー > ✔ plain-svc-00001-k5k yes plain-svc 2026-09-02 01:11:48 UTC < ユーザー > この状態で新しいエージェント ID に必要なロールを付与し、その後にトラフィックを移行します。 # 最新リビジョンにトラフィックを移行 $ gcloud run services update-traffic plain-svc --to-latest --region = asia-northeast1 --project =< プロジェクトID > ----- 出力例 ----- Updating traffic... Routing traffic.......................................................................................................................done Done. URL: https://plain-svc- < ハッシュ > -an.a.run.app Traffic: 100 % LATEST ( currently plain-svc-00002-k94 ) エージェント ID の確認 割り当てられたエージェント ID は、リビジョンの describe で確認できます。サービスの describe には ID の値が表示されないため、リビジョンを指定してください。 # リビジョンの詳細を表示 $ gcloud beta run revisions describe agent-a-00001-nmz --region = asia-northeast1 --project =< プロジェクトID > ----- 出力例 ----- ✔ Revision agent-a-00001-nmz in region asia-northeast1 Container < コンテナ名 > Image: < コンテナURL > Port: 8080 Memory: 512Mi CPU: 1000m Startup Probe: TCP every 240s Port: 8080 Initial delay: 0s Timeout: 240s Failure threshold: 1 Type: Default Identity: //agents.global.org- < 組織ID > .system.id.goog/resources/run/projects/ < プロジェクト番号 > /locations/asia-northeast1/services/agent-a Identity Type: agent-identity Identity Certificate Enabled: true Concurrency: 80 Timeout: 300s Execution Environment: Second Generation ✔ Deploying revision succeeded in 6 .28s. Identity の値は principal:// の接頭辞を除いた形式で表示されます。IAM ポリシーに指定する際は、先頭に principal: を付けて principal://agents.global... の形式にします。 Google Cloud コンソールでは、サービスの「リビジョン」タブでリビジョンを選択し、「セキュリティ」タブの「Identity」フィールドに表示されます。 Agent Registry での確認 自動登録されたエージェントは、gcloud CLI の gcloud agent-registry agents list コマンドで一覧できます。 一覧には Google Workspace エージェントなどの Google 提供のエージェントや、Agent Runtime 上のエージェントも含まれるため、以下の例では agentId に run: を含むエントリだけを表示しています。 # Agent Registry に登録された Cloud Run のエージェントを一覧 $ gcloud agent-registry agents list \ --location = asia-northeast1 --project =< プロジェクトID > \ --filter =" agentId ~ 'run:' " \ --format =" table(agentId,createTime) " ----- 出力例 ----- AGENT_ID CREATE_TIME urn:agent:projects- < プロジェクト番号 > :projects: < プロジェクト番号 > :locations:asia-northeast1:run:jobs:agent-job 2026-09-02T01:10:13.286069Z urn:agent:projects- < プロジェクト番号 > :projects: < プロジェクト番号 > :locations:asia-northeast1:run:services:agent-a 2026-09-02T01:07:49.566835Z urn:agent:projects- < プロジェクト番号 > :projects: < プロジェクト番号 > :locations:asia-northeast1:run:services:agent-b 2026-09-02T01:11:58.117538Z urn:agent:projects- < プロジェクト番号 > :projects: < プロジェクト番号 > :locations:asia-northeast1:run:services:plain-svc 2026-09-02T01:11:48.365980Z MCP サーバーは、gcloud CLI では gcloud agent-registry mcp-servers list 、API では agents の代わりに mcpServers を指定して一覧します。 mcpServerId は urn:mcp:...:run:services:<サービス名> の形式です。 エージェントの認証 Google Cloud API への認証 エージェントは、Cloud Run のメタデータサーバーから取得したアクセストークンで Agent Platform や Cloud Storage などの Google Cloud API に認証します。 この仕組みは従来のサービスアカウントと同じで、アプリケーションコードでは標準の Google Cloud クライアントライブラリを使用するだけで済みます。クライアントライブラリは Application Default Credentials（ADC）の仕組みでメタデータサーバーから短期のアクセストークンを自動取得します。 必要なロールは、エージェント ID をプリンシパルとして付与します。以下は Agent Platform ユーザー（ roles/aiplatform.user ）をプロジェクトレベルで付与する例です。 # エージェント ID に Agent Platform ユーザーのロールを付与 $ gcloud projects add-iam-policy-binding < プロジェクトID > \ --member =" <エージェントID> " \ --role =" roles/aiplatform.user " # 例 : プロジェクト myproject のサービス myagent のエージェント ID に付与 $ gcloud projects add-iam-policy-binding myproject \ --member =" principal://agents.global.org-111111111111.system.id.goog/resources/run/projects/222222222222/locations/asia-northeast1/services/myagent " \ --role =" roles/aiplatform.user " 前述のとおり、Agent Platform 経由の Gemini モデルの generateContent は、自動付与される事前定義ロールの権限で呼び出せます。Storage オブジェクト閲覧者（ roles/storage.objectViewer ）など、それ以外のアクセスには対象リソースに対して個別にロールを付与してください。 参考 : アプリケーションのデフォルト認証情報の仕組み 他の Cloud Run 上のエージェント・MCP サーバーへの認証 エージェント ID を持つ Cloud Run 上のエージェントや MCP サーバーが、Cloud Run 上の別のエージェントや MCP サーバーを呼び出す場合は、ID トークン（JWT）を使用し、Cloud Run 組み込みの Cloud Run 起動元（ roles/run.invoker ）による IAM チェックで検証します。A2A プロトコルに準拠したエージェントを呼び出す場合も同様です。 これは Cloud Run のサービス間認証と同じ仕組みで、呼び出し元のプリンシパルがエージェント ID になる点だけが異なります。 まず、呼び出し元エージェントの ID に対して、呼び出し先サービスの Cloud Run 起動元をサービスレベルで付与します。 # 呼び出し元エージェント ID に呼び出し先サービスの起動元ロールを付与 $ gcloud run services add-iam-policy-binding < 呼び出し先のサービス名 > \ --member =" <呼び出し元のエージェントID> " \ --role =" roles/run.invoker " \ --region = asia-northeast1 --project =< プロジェクトID > # 例 : プロジェクト myproject のサービス myagent のエージェント ID を呼び出し元として指定 $ gcloud run services add-iam-policy-binding < 呼び出し先のサービス名 > \ --member =" principal://agents.global.org-111111111111.system.id.goog/resources/run/projects/222222222222/locations/asia-northeast1/services/myagent " \ --role =" roles/run.invoker " \ --region = asia-northeast1 --project = myproject <呼び出し元のエージェントID> には、 principal:// から始まるエージェント ID の文字列をそのまま指定します。呼び出し先が MCP サーバーの場合も、コマンドの第1引数に MCP サーバーのサービス名を指定する点以外は同じです。 次に、呼び出し元のコンテナ内で、呼び出し先サービスの URL を audience に指定して ID トークンを取得し、 Authorization ヘッダーに付けてリクエストします。トークンの取得先はサービスアカウントの場合と同じメタデータサーバーで、アプリケーションコードの変更は不要です。 # 呼び出し先の URL を audience にして ID トークンを取得 $ TOKEN = $( curl -s -H " Metadata-Flavor: Google " \ " http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=<呼び出し先のサービスのURL> " ) # 取得したトークンで呼び出し先を呼び出す $ curl -H " Authorization: Bearer $TOKEN " < 呼び出し先のサービスのURL > 参考 : サービス間認証 参考 : Authenticate MCP servers バインドトークンによる保護の強化 前述の手順で取得した ID トークンは非バインドトークンと呼ばれる標準的なものです。エージェント ID を持つワークロードでは、これに加えてバインドトークンを使用できます。 方式 内容 非バインドトークン メタデータサーバーが生成する、audience 付きの標準的な ID トークン。サービス間認証・エージェント間認証のデフォルト バインドトークン mTLS により、トークンをワークロードの証明書と結び付ける。呼び出し元がリクエストに自身の証明書チェーンを含める どちらもメタデータサーバーが発行する ID トークンで、呼び出し元が誰かを証明する点は同じです。違いは、トークンを持っているだけで使えるかどうかにあります。非バインドトークンは、有効期限内であればトークンを持つ誰もが使えます。 一方、バインドトークンには呼び出し元のワークロード証明書のフィンガープリント（証明書のハッシュ値）が埋め込まれており、呼び出し先は TLS の接続時に提示された証明書がそのフィンガープリントと一致するかを検証します。証明書の秘密鍵はコンテナの外に出ないため、トークンだけが漏洩しても第三者は再利用できません。 どちらの方式になるかは、呼び出し先に指定する URL で決まります。通常の URL（ run.app ）を指定すると非バインドトークン、mTLS 用 URL（ mtls.run.app ）を指定するとバインドトークンを使用します。 標準の Google Cloud クライアントライブラリは、証明書がある環境では自動でバインドトークンを取得して証明書を提示する ため、通常は方式を意識せずに済みます。ID 証明書を無効化したワークロードや、サービスアカウントで動作する呼び出し元には証明書がないため、非バインドトークンのみ使用できます。 同じ仕組みは Google Cloud API への認証でも働いています。後述の動作確認では、BigQuery のクライアントライブラリが接続先として bigquery.mtls.googleapis.com を自動で選択しており、エージェント ID による Google Cloud API へのアクセスがデフォルトで mTLS になっていることを確認できます。curl でバインドトークンを手動取得する手順は、公式ドキュメントに記載されています。 参考 : Authenticate your AI agents - Fetch a bound ID token (mTLS) 参考 : A2A エージェントを Cloud Run にデプロイする 動作確認 検証構成 エージェント ID による認証の挙動を確認するため、ADK で作成した BigQuery のデータ分析エージェントを、エージェント ID を有効にした Cloud Run サービスにデプロイしました。エージェントは Gemini の呼び出しと BigQuery のクエリ実行の両方に、サービスアカウントではなくエージェント ID で認証します。 リソース 設定 役割 Cloud Run サービス bq-agent --functional-type=agent --identity-type=agent-identity ADK エージェント。ADK の API サーバーとして HTTP で質問を受け付ける Gemini（ gemini-3.5-flash 、asia-northeast1） 事前定義ロールで呼び出し可能 質問の解釈とツールの選択 BigQuery 公開データセット bigquery-public-data.samples.shakespeare エージェント ID に BigQuery ジョブユーザーを付与 エージェントがクエリを実行する対象 検証は以下の順で行いました。 エージェントをデプロイし、割り当てられたエージェント ID を確認する ロールを付与する前に、Gemini だけを使う質問と BigQuery を使う質問を送る エージェント ID に BigQuery ジョブユーザー（ roles/bigquery.jobUser ）を付与する 同じ質問を送り、結果を比較する Cloud Audit Logs で、BigQuery へのアクセスがエージェント ID として記録されていることを確認する エージェントのソースコード ディレクトリ構成は以下のとおりです。ADK の公式ドキュメントにある Cloud Run へのデプロイ構成に従っています。 bq-agent/ ├── bq_agent/ │ ├── __init__.py │ └── agent.py ├── main.py ├── requirements.txt └── Dockerfile エージェント本体は agent.py です。BigQuery ツールセットの認証情報には ADC を使用します。Cloud Run 上では、メタデータサーバーを通じてエージェント ID の認証情報が使われます。 # bq_agent/agent.py import os import google.auth from google.adk.agents import Agent from google.adk.tools.bigquery import BigQueryCredentialsConfig, BigQueryToolset from google.adk.tools.bigquery.config import BigQueryToolConfig, WriteMode # クエリを実行するプロジェクト PROJECT_ID = os.environ[ "GOOGLE_CLOUD_PROJECT" ] # Application Default Credentials を使用する # Cloud Run 上ではメタデータサーバー経由でエージェント ID の認証情報が使われる credentials, _ = google.auth.default() bigquery_toolset = BigQueryToolset( credentials_config=BigQueryCredentialsConfig(credentials=credentials), bigquery_tool_config=BigQueryToolConfig(write_mode=WriteMode.BLOCKED), tool_filter=[ "get_dataset_info" , "get_table_info" , "execute_sql" ], ) root_agent = Agent( name= "bq_agent" , model= "gemini-3.5-flash" , description= "BigQuery のデータについて質問に答えるエージェント" , instruction=( "あなたは BigQuery のツールを使ってデータの質問に答えるデータ分析エージェントです。" f "ツールの project_id には常に {PROJECT_ID} を指定してください。" "ツールの実行がエラーになった場合は再試行せず、エラーメッセージをそのまま回答に含めてください。" ), tools=[bigquery_toolset], ) # bq_agent/__init__.py from . import agent main.py は、ADK が提供する FastAPI アプリケーションをそのまま起動します。 # main.py import os import uvicorn from google.adk.cli.fast_api import get_fast_api_app AGENT_DIR = os.path.dirname(os.path.abspath(__file__)) app = get_fast_api_app(agents_dir=AGENT_DIR, web= False ) if __name__ == "__main__" : uvicorn.run(app, host= "0.0.0.0" , port= int (os.environ.get( "PORT" , 8080 ))) 依存関係は google-adk[gcp] の1行です。BigQuery ツールセットは BigQuery と Dataplex のクライアントライブラリを必要とし、これらは google-adk の gcp extra に含まれます。 # requirements.txt google-adk[gcp] # Dockerfile FROM python:3.13-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . CMD [ " sh ", " -c ", " uvicorn main:app --host 0.0.0.0 --port $PORT " ] デプロイ ソースから直接デプロイします。機能タイプとアイデンティティタイプのフラグに加えて、Gemini を Agent Platform 経由で呼び出すための環境変数を設定します。 # ADK エージェントをエージェント ID 付きでデプロイ $ gcloud beta run deploy bq-agent \ --source . \ --functional-type = agent \ --identity-type = agent-identity \ --set-env-vars =" GOOGLE_CLOUD_PROJECT=<プロジェクトID>,GOOGLE_CLOUD_LOCATION=asia-northeast1,GOOGLE_GENAI_USE_ENTERPRISE=True " \ --region = asia-northeast1 --project =< プロジェクトID > ----- 出力例 ----- WARNING: Updating the functional type to an agent also requires updating its identity to agent_identity. Make sure to update the IAM policies on the agent_identity to ensure no issues with connectivity to other services. Building using Dockerfile and deploying container to Cloud Run service [ bq-agent ] in project [< プロジェクトID >] region [ asia-northeast1 ] Building and deploying new service... Validating configuration..........done Uploading sources.........done Building Container.............................................done Creating Revision..............................................done Routing traffic.....done Done. Service [ bq-agent ] revision [ bq-agent-00001-9x6 ] has been deployed and is serving 100 percent of traffic. Service URL: https://bq-agent- < プロジェクト番号 > .asia-northeast1.run.app リビジョンの詳細で、エージェント ID が割り当てられていることを確認します。 # リビジョンの詳細からエージェント ID を確認 $ gcloud beta run revisions describe bq-agent-00001-9x6 --region = asia-northeast1 --project =< プロジェクトID > | grep Identity ----- 出力例 ----- Identity: //agents.global.org- < 組織ID > .system.id.goog/resources/run/projects/ < プロジェクト番号 > /locations/asia-northeast1/services/bq-agent Identity Type: agent-identity Identity Certificate Enabled: true コンソールから Cloud Run リビジョンのエージェント ID を確認する Agent Registry にも、エージェントとして自動登録されています。 # Agent Registry の登録を確認 $ gcloud agent-registry agents list \ --location = asia-northeast1 --project =< プロジェクトID > \ --filter =" agentId ~ 'bq-agent' " ----- 出力例 ----- --- agentId: urn:agent:projects- < プロジェクト番号 > :projects: < プロジェクト番号 > :locations:asia-northeast1:run:services:bq-agent attributes: agentregistry.googleapis.com/system/RuntimeReference: uri: //run.googleapis.com/projects/ < プロジェクト番号 > /locations/asia-northeast1/services/bq-agent createTime: ' 2026-09-02T16:43:08.933443Z ' displayName: bq-agent name: projects/ < プロジェクトID > /locations/asia-northeast1/agents/agentregistry-00000000-0000-0000-da87-53c426078b85 uid: agentregistry-00000000-0000-0000-da87-53c426078b85 updateTime: ' 2026-09-02T16:54:39.553087Z ' コンソールからエージェントが Agent Registry に自動登録されていることを確認する エージェントの呼び出し ADK の API サーバーは、セッションを作成してから /run に質問を送る形式です。サービスは未認証のリクエストを許可していないため、呼び出し側のユーザーの ID トークンを Authorization ヘッダーに付けます。当記事では、Cloud Run 管理者のユーザーで gcloud auth print-identity-token を使用しました。トークンなしで呼び出すと、Cloud Run が403で拒否します。 # ID トークンを取得 $ TOKEN = $( gcloud auth print-identity-token ) $ URL =https://bq-agent- < プロジェクト番号 > .asia-northeast1.run.app # セッションを作成 $ curl -s -X POST -H " Authorization: Bearer $TOKEN " -H " Content-Type: application/json " \ " $URL /apps/bq_agent/users/u1/sessions/s1 " -d ' {} ' # 質問を送る $ curl -s -H " Authorization: Bearer $TOKEN " -H " Content-Type: application/json " " $URL /run " \ -d ' {"app_name":"bq_agent","user_id":"u1","session_id":"s1","new_message":{"role":"user","parts":[{"text":"<質問>"}]}} ' /run の応答は、モデルの応答やツールの呼び出しと結果を含むイベントの配列です。以下では、応答からツールの呼び出し（ functionCall ）、ツールの結果（ functionResponse ）、最終回答（ text ）を抜粋して示します。 ロール付与前の動作 まず、BigQuery のツールを使わない質問を送ります。エージェント ID には Gemini の呼び出しに必要な権限が事前定義ロールで自動付与されているため、追加のロールなしで回答が返ります。 質問 : BigQuery のツールは使わずに答えてください。あなたは何ができますか。1文で答えてください。 回答 : 私は、BigQueryに格納されているデータに関する質問に対して、データの検索や分析を行ってお答えすることができます。 次に、BigQuery のクエリを必要とする質問を送ります。エージェントは SQL を組み立てて execute_sql ツールを呼び出しますが、エージェント ID にクエリを実行する権限が無いため、ツールの実行が403で失敗します。 質問 : bigquery-public-data.samples.shakespeare テーブルで、word_count の合計が最も多い corpus 上位3件を教えてください。 functionCall : execute_sql project_id : <プロジェクトID> query : SELECT corpus, SUM(word_count) AS total_word_count FROM `bigquery-public-data.samples.shakespeare` GROUP BY corpus ORDER BY total_word_count DESC LIMIT 3 functionResponse : status : ERROR error_details : 403 POST https://bigquery.mtls.googleapis.com/bigquery/v2/projects/<プロジェクトID>/jobs?prettyPrint=false: Access Denied: Project <プロジェクトID>: User does not have bigquery.jobs.create permission in project <プロジェクトID>. 回答 : 申し訳ありませんが、クエリを実行したところ、以下のエラーが発生しました。 エラーメッセージ: Access Denied: Project <プロジェクトID>: User does not have bigquery.jobs.create permission in project <プロジェクトID>. プロジェクト <プロジェクトID> において bigquery.jobs.create 権限がないため、クエリを実行することができませんでした。 エラーメッセージ中の BigQuery のエンドポイントが bigquery.mtls.googleapis.com になっている点にも注目してください。クライアントライブラリがコンテナ内のワークロード証明書を検出し、Google Cloud API との通信に mTLS のエンドポイントを自動で選択しています。前述のとおり、エージェント ID による Google Cloud API へのアクセスがデフォルトで mTLS になるという Agent Identity の仕様どおりの動作です。 ロールの付与 エージェント ID をプリンシパルにして、BigQuery ジョブユーザー（ roles/bigquery.jobUser ）をプロジェクトレベルで付与します。公開データセットのテーブルは誰でも読み取れるため、クエリを実行するプロジェクトに対するジョブ作成の権限があれば足ります。 # エージェント ID に BigQuery ジョブユーザーを付与 $ gcloud projects add-iam-policy-binding < プロジェクトID > \ --member =" principal://agents.global.org-<組織ID>.system.id.goog/resources/run/projects/<プロジェクト番号>/locations/asia-northeast1/services/bq-agent " \ --role =" roles/bigquery.jobUser " ----- 出力例 ----- Updated IAM policy for project [< プロジェクトID >] . bindings: // 省略 - members: - principal://agents.global.org- < 組織ID > .system.id.goog/resources/run/projects/ < プロジェクト番号 > /locations/asia-northeast1/services/bq-agent role: roles/bigquery.jobUser // 省略 ロール付与後の動作 同じ質問を新しいセッションで送ると、ツールの実行が成功し、クエリ結果に基づく回答が返ります。 質問 : bigquery-public-data.samples.shakespeare テーブルで、word_count の合計が最も多い corpus 上位3件を教えてください。 functionCall : execute_sql project_id : <プロジェクトID> query : SELECT corpus, SUM(word_count) AS total_word_count FROM `bigquery-public-data.samples.shakespeare` GROUP BY corpus ORDER BY total_word_count DESC LIMIT 3 functionResponse : status : SUCCESS rows : [{'corpus': 'hamlet', 'total_word_count': 32446}, {'corpus': 'kingrichardiii', 'total_word_count': 31868}, {'corpus': 'coriolanus', 'total_word_count': 29535}] 回答 : bigquery-public-data.samples.shakespeare テーブルにおいて、word_count の合計が最も多い corpus（作品）の上位3件は以下の通りです。 1. hamlet（ハムレット）: 32,446 2. kingrichardiii（リチャード三世）: 31,868 3. coriolanus（コリオレイナス）: 29,535 エージェントのコードには、サービスアカウントのキーや認証情報の設定は一切含まれていません。アイデンティティタイプを agent-identity にしてデプロイし、エージェント ID にロールを付与するだけで、クライアントライブラリが自動的にエージェント ID として認証しています。 監査ログでの確認 Cloud Audit Logs では、BigQuery へのアクセスがエージェント ID をプリンシパルとして記録されます。エージェント ID は principalEmail ではなく principalSubject フィールドに、 principal:// 形式で入ります。 # BigQuery の監査ログからエージェント ID のエントリを表示 $ gcloud logging read ' protoPayload.serviceName="bigquery.googleapis.com" AND protoPayload.authenticationInfo.principalSubject:"services/bq-agent" ' \ --project =< プロジェクトID > --limit = 2 --order = asc \ --format =" json(timestamp,protoPayload.methodName,protoPayload.status,protoPayload.authenticationInfo.principalSubject) " ----- 出力例 ----- [ { " protoPayload " : { " authenticationInfo " : { " principalSubject " : " principal://agents.global.org-<組織ID>.system.id.goog/resources/run/projects/<プロジェクト番号>/locations/asia-northeast1/services/bq-agent " } , " methodName " : " jobservice.insert " , " status " : { " code " : 7 , " message " : " Access Denied: Project <プロジェクトID>: User does not have bigquery.jobs.create permission in project <プロジェクトID>. " } } , " timestamp " : " 2026-09-02T16:55:19.161262Z " } , { " protoPayload " : { " authenticationInfo " : { " principalSubject " : " principal://agents.global.org-<組織ID>.system.id.goog/resources/run/projects/<プロジェクト番号>/locations/asia-northeast1/services/bq-agent " } , " methodName " : " jobservice.insert " , " status " : {} } , " timestamp " : " 2026-09-02T16:55:56.681213Z " } ] 1件目はロール付与前の拒否されたジョブ作成（ status.code が7、PERMISSION_DENIED）、2件目はロール付与後に成功したジョブ作成です。どちらもプリンシパルがエージェント ID になっており、どの Cloud Run サービスが BigQuery にアクセスしたかをサービス単位で追跡できます。 参考 : BigQuery tool for ADK 参考 : Cloud Run - Agent Development Kit (ADK) 佐々木 駿太 (記事一覧) クラウドソリューション部 クラウドエンジニアリング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 Studio を使用して、Google ドライブに追加されたファイルを Gemini Notebook（旧称 NotebookLM）にソースとして自動で追加するフローの作成手順を紹介します。 はじめに 当記事の概要 Google Workspace Studio とは Gemini Notebook とは 作成するフロー 処理の全体像 追加できるソースの種類 注意事項 フロー作成手順 ノートブックの作成 開始条件の指定 ソース追加ステップの設定 動作確認 はじめに 当記事の概要 当記事では、Google Workspace の業務自動化ワークフローツールである Google Workspace Studio を使用して、 Gemini Notebook （旧称 NotebookLM）へのソース追加を自動化するフローを作成します。具体的には、Google ドライブの特定フォルダにファイルが追加されたことをきっかけに、そのファイルを Gemini Notebook にソースとして自動で追加するよう設定します。 これまで Gemini Notebook にソースを追加するには、ユーザーがノートブックを開き、1つずつ手動で登録する必要がありました。Google Workspace Studio には、Gemini Notebook にソースを追加するステップ（以下、ソース追加ステップ）が用意されており、追加作業をフローに組み込めます。当記事では、このソース追加ステップを中心にフローの作成手順を解説します。 参考 : Workspace Studio の開始条件とステップに関するガイド - Workspace Studio ヘルプ Google Workspace Studio とは Google Workspace Studio は、Google Workspace のアプリケーションを連携させて定型業務を自動化できる、Gemini を搭載したノーコードの自動化ツールです。あらかじめ用意された開始条件（トリガー）とステップ（アクション）を組み合わせて「フロー」を作成することで、プログラミングなしに業務を自動化できます。 たとえば「特定のフォルダにファイルが追加されたら、その内容を Gemini で要約して Google Chat に通知する」といった処理を、コードを書かずに実現できます。 参考 : Google Workspace Studio の使用を開始する - Workspace Studio ヘルプ Google Workspace Studio の概要や基本的な使い方は、以下の記事で詳しく解説しています。当記事ではフローの作成手順に絞るため、基礎的な概念は以下を参照してください。 blog.g-gen.co.jp Gemini Notebook とは Gemini Notebook は、ユーザーが追加したソース（情報源）のみに基づいて回答を生成する、Google の AI リサーチツールです。 PDF や Google ドキュメント、Web URL などをソースとしてノートブックに追加すると、それらの内容に基づいた質問への回答や要約、音声概要（Audio Overview）の生成などを行うことができます。AI の回答がソースに基づくため、ハルシネーション（事実と異なる内容の生成）を抑制できる点が特徴です。 Gemini Notebook の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp 作成するフロー 処理の全体像 今回作成するフローは、Google ドライブの特定フォルダにファイルが追加されたことをきっかけに動き出します。フロー全体は、次の2つのステップで構成されます。 ステップ 種類 処理内容 1 開始条件 フォルダへのアイテム追加を検知する 2 アクション 追加されたファイルを Gemini Notebook にソースとして追加する ステップ1でファイルの追加を検知し、ステップ2でそのファイルを Gemini Notebook のソースに追加します。フォルダにファイルを保存するだけで、ノートブックの情報源が自動で拡充される点が、当記事のポイントです。 追加できるソースの種類 ソース追加ステップでは、以下の種類のソースを Gemini Notebook に追加できます。 テキスト Google ドライブファイルへのリンク Web または YouTube のリンク 当記事ではこのうち、Google ドライブファイルへのリンクを使用します。 注意事項 ソースの追加は即時だが、質問できるようになるまで数分かかる ソース自体はすぐに追加されますが、追加した内容がノートブックにインデックス化され、質問に反映されるまでには数分かかります。フローの実行直後にノートブックへ質問しても、追加したばかりのソースの内容が回答に反映されない場合があります。 Gemini Notebook のソース数には上限がある Gemini Notebook に追加できるソース数には、プランごとの上限があります。フローで自動追加する場合は、上限に達しないよう運用を設計してください。各プランの上限については、以下の公式ドキュメントを参照してください。 参考 : ノートブックの新しいソースを追加または検索する - Gemini Notebook ヘルプ フロー作成手順 ノートブックの作成 フローの作成に先立ち、ソースの追加先となる Gemini Notebook のノートブックを1つ用意します。既存のノートブックを使用する場合は、この手順は不要です。 開始条件の指定 開始条件 は、フローが動き出すきっかけとなるイベントです。Google Workspace Studio では、スケジュール実行やメールの受信など複数の開始条件が用意されています。 当フローでは [フォルダにアイテムが追加されたとき] を開始条件に選びます。監視対象のフォルダにファイルが追加されたタイミングで、フローを起動します。 開始条件の選択画面で [フォルダにアイテムが追加されたとき] を選択します。 続いて、監視するフォルダを指定します。[ドライブ] をクリックし、ソースとして追加したいファイルを格納するフォルダを選択します。 これで、対象のフォルダに新しいファイルが追加されるたびに、フローが実行されます。 ソース追加ステップの設定 開始条件の次に、追加されたファイルを Gemini Notebook のソースに追加するステップを設定します。アクションの [ステップの選択] から、[Gemini Notebook にソースを追加します] を選択します。 ステップを追加すると、ソースの追加先や追加する内容を指定するフィールドが表示されます。各フィールドを以下のとおり設定します。 フィールド名 値 追加先のノートブック ソースの追加先となるノートブックを指定 ソースの種類を選択 ドライブ を指定 ファイルまたはリンクを選択 ドライブ をクリックして ステップ 1: フォルダにアイテムが追加されたとき > アイテムへのリンク を指定 以上で、フォルダへのファイル追加を起点に、Gemini Notebook へソースを自動追加するフローが完成です。 動作確認 フローが完成したら、画面左上のフロー名を分かりやすい名前（ここでは「ナレッジソース自動追加」）に変更し、[オンにする] でフローを有効化します。 フローをオンにした状態で、監視対象のフォルダにファイルを追加します。 フローが実行されると、追加したファイルが Gemini Notebook のソースに追加されます。ノートブックを開くと、ソースの一覧に対象のファイルが表示されています。 なお、ソースの一覧に表示された後も、その内容がインデックス化され質問に反映されるまでには数分かかります。追加直後に質問する場合は注意してください。 フローの実行結果は、画面右上のアクティビティから確認できます。 勝島 祐太郎 (記事一覧) クラウドソリューション部 ソリューションアーキテクト課 2025年1月G-genにジョイン！飲食業界からIT業界に転身したエンジニア。 コーヒーが好きです。

G-gen の杉村です。2026年8月に発表された、Google Cloud や Google Workspace のイチオシアップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに Google Cloud のアップデート BigQuery で cross-cloud connections が Preview 公開 SCC で Malicious Skill runtime threat detectors が利用可能に BigQuery テーブルを AlloyDB へ同期する機能が Preview 公開 Gemini 3.7 Flash がリリース Gemini Enterprise app で Skills（スキル）が一般公開（GA） Agent Search の回答生成モデルに Gemini 3.5 Flash が登場 Antigravity in Gemini Enterprise がリリース Agent Identity auth manager が一般公開（GA） BigQuery の会話型分析（データエージェント）のモニタリング（Preview） Cloud SQL for PostgreSQL で「推奨事項の事前アセスメント」が Preview 公開 Cloud Run の新体系「Cloud Run instances」が Preview 公開 音声認識モデル Gemini 3.5 Transcribe が Preview 公開 新サービス Cloud FTP が一般公開（GA） 画像生成/編集モデル Gemini Omni 1.1 Flash が Preview 公開 VPC Flow Logs でドロップされたパケットのレコードが出力されるように Gemini Enterprise で Sensitive Data Protection のコンテンツポリシーが使用可能に BigQuery Graph が一般公開（GA） BigQuery の生成AI関数のトークンのクォータ（上限）が任意に設定できるように Google Workspace のアップデート Google Meet の自動メモ作成で投影物のスクリーンショット保存されるように Google Workspace Studio で Gemini Notebook にソースデータを追加可能に Excel ファイルを Google スプレッドシートにインポートする際の互換性が向上 Connected Sheets で「リストパラメータ」と「列名エイリアス」機能 Google Workspace のスプレッドシートで Sheets Canvas がリリース Take notes for me が Web 会議だけでなく対面会議でも使えるように Drive Inventory Reportingで外部共有関連の情報をエクスポートできるように Google Workspace Studio でエンタープライズ向けセキュリティ機能が強化 Google Chat に Workspace Intelligence のハブとなる Ask Gemini 画面が登場 Gemini アプリでインタラクティブな 3D モデルを生成できるように Microsoft OneDrive からのデータインポート（Advanced モード）が一般公開 Microsoft Teams からのチャット情報のデータインポート機能が一般公開 Google カレンダーで Teams や Zoom などからの招待がわかりやすく Google ドライブで AI によるデータ自動ラベリング機能がオープンベータ開始 予定主催者が受け取る出席可否メール通知をイベント単位で無効化できるように はじめに 当記事では、毎月の Google Cloud（旧称 GCP）や Google Workspace（旧称 GSuite）のアップデートのうち、特に重要なものをまとめます。 また当記事は、Google Cloud に関するある程度の知識を前提に記載されています。前提知識を得るには、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp リンク先の公式ガイドは、英語版で表示しないと最新情報が反映されていない場合がありますためご注意ください。 Google Cloud のアップデート BigQuery で cross-cloud connections が Preview 公開 Create cross-cloud connections (2026-08-03) BigQuery で cross-cloud connections が Preview 公開。 例として Amazon S3 上の Parquet ファイルを BigQuery から外部テーブルとしてクエリ可能。東京 / 大阪リージョンにも対応している。AWS、Azure、Salesforce Data 360 に対応 。 以下の記事も参照。 blog.g-gen.co.jp SCC で Malicious Skill runtime threat detectors が利用可能に Security Command Center release notes - August 04, 2026 (2026-08-04) Security Command Center で Malicious Skill runtime threat detectors が利用可能に。AI エージェントが悪意あるスキルをロードしたり実行したりすると検知。Agent Runtime、Cloud Run、GKE で実行されるエージェントに対応。脅威インテリジェンス「Google Threat Intelligence」を使用。 BigQuery テーブルを AlloyDB へ同期する機能が Preview 公開 Choose how to access BigQuery data from AlloyDB (2026-08-08) BigQuery テーブルを AlloyDB へ同期する機能が Preview 公開。 業務アプリ側から BigQuery データを利用可能になる。以下の手法から選択可能。 データを移動しない Lakehouse federation（処理は BigQuery 側にプッシュダウン） データ同期（ワンタイム） データ同期（定期スケジュール） Gemini 3.7 Flash がリリース Introducing Gemini 3.7 Flash (2026-08-13) Gemini 3.7 Flash がリリース。 「ソフトウェアエンジニアリング、知識労働、Web開発で大幅な改善」とされている。Agent Platform、Google AI Studio、Gemini Spark 等で利用可能。 また、Gemini 3.7 Flash および 3.6 Flash のトークンあたり料金が2026年12月31日までの限定で、半額で提供される。Agent Platform（Google Cloud）と Gemini Developer API（Google AI Studio）の両方でこの半額キャンペーンが適用される。 Gemini Enterprise app で Skills（スキル）が一般公開（GA） Create and manage skills (2026-08-13) Gemini Enterprise app で Skills（スキル）が一般公開（GA）。 タスクに特化したプロンプトや Bash/Python スクリプトを事前に定義しておける。呼び出し方は以下のいずれか。 アシスタントが自動で判断して読み込む プロンプト内でメンション形式で呼び出す プロンプト内の自然言語による指示で呼び出す Agent Search の回答生成モデルに Gemini 3.5 Flash が登場 Answer generation model versions and lifecycle (2026-08-13) Agent Search（旧称 Vertex AI Search）の回答生成モデルに Gemini 3.5 Flash が登場。 これまでの最新は gemini-3-flash-preview または gemini-3.1-pro-preview だった。RAG やそれにもとづく回答の精度向上に期待。 Antigravity in Gemini Enterprise がリリース Gemini Enterprise release notes - August 18, 2026 (2026-08-18) Antigravity in Gemini Enterprise がリリースされた。Gemini Enterprise 付属の Antigravity のことを指す。 少し前から既に使用可能だったが、正式にリリースノートに記載された。Gemini Enterprise の1ライセンスあたり、Standard なら$10、Plus なら $15 がプールされる。例として、Standard が 100 ライセンスあれば、$1,000 がプールされる。総ライセンス数分がプールされ、それをシェアして使用する形になる。 各種機能の有効化やロギングのオン・オフなども設定可能なほか、使用状況のモニタリングなど、各種統制機能が付帯しており、企業が Antigravity を使用するにあたり有用。詳細は以下の記事でも紹介。 blog.g-gen.co.jp Agent Identity auth manager が一般公開（GA） Agent Identity auth manager overview (2026-08-22) Agent Identity auth manager が一般公開（GA）。 AI エージェントによる外部ツール呼び出しの認証を一元管理でき、API キーやトークン保管、OAuth フローの実行、ヘッダーへの認証情報注入などをある程度マネージド化でき、セキュアになる他、コード簡素化にもなる。 BigQuery の会話型分析（データエージェント）のモニタリング（Preview） Create data agents (2026-08-24) BigQuery の会話型分析（データエージェント）のパフォーマンス、利用率、レイテンシ、コスト等を Cloud Monitoring 等で可視化可能になった（Preview）。 BigQuery の会話型分析の費用は、以下のとおり。2026-09-30まで無償トライアル期間であり、2026-10-01からの課金開始が予定されている。 参考 : Data Cloud Agent pricing and free trial Cloud SQL for PostgreSQL で「推奨事項の事前アセスメント」が Preview 公開 Assess recommendations for Cloud SQL in Database Center (2026-08-25) Cloud SQL for PostgreSQL で「推奨事項の事前アセスメント」が Preview 公開。 Database Center の推奨事項（マシンタイプ / エディション変更等）について、自動で事前にインスタンスをクローンしてベンチマークテストを行ってくれる。複製インスタンスの費用は発生する。 Cloud Run の新体系「Cloud Run instances」が Preview 公開 Assess recommendations for Cloud SQL in Database Center (2026-08-25) Cloud Run の新体系「Cloud Run instances」が Preview 公開。 既存の Cloud Run service と異なり、「単一リビジョン」「単一インスタンス」「長期稼働」「高コスト効率」。固有URLが与えられ起動停止等の管理が可能。ステートフルなワークロード等に使える。 以下の記事で詳細に解説。 blog.g-gen.co.jp 音声認識モデル Gemini 3.5 Transcribe が Preview 公開 Gemini 3.5 Transcribe (2026-08-26) 新しい音声認識モデル Gemini 3.5 Transcribe が Preview 公開。英語、日本語、韓国語、ポルトガル語、仏語など80以上の言語を正確に文字起こし。雑音や専門用語にも対応、フィラーは自動削除。リアルタイム用 API と、バッチ用の API がある。 Gemini Enterprise Agent Platform と Google AI Studio で提供開始。 新サービス Cloud FTP が一般公開（GA） Cloud FTP overview (2026-08-26) 新サービス Cloud FTP が一般公開（GA）。公開鍵認証で SFTP プロトコルの暗号化接続を確立し Cloud Storage との間でファイルをやりとりできる。 接続元 IP アドレス制限も可能。通常の SFTP なので Cyber​​duck、WinSCP などのクライアントが使用可能。 以下の記事も参照。 blog.g-gen.co.jp 画像生成/編集モデル Gemini Omni 1.1 Flash が Preview 公開 Gemini Omni 1.1 Flash Preview (2026-08-27) 画像生成/編集モデル Gemini Omni 1.1 Flash が Preview 公開。 マルチモーダルモデルであり入力として「テキスト、画像、動画」を、出力として「テキスト、動画 (音声付)」に対応。 Agent Platform と Google AI Studio で利用可能。 VPC Flow Logs でドロップされたパケットのレコードが出力されるように About VPC Flow Logs records (2026-08-27) VPC Flow Logs が、ファイアウォールルール等でドロップされたパケットのレコードを出力するようになった。 セキュリティ監査やネットワーク疎通エラーのトラブルシューティングに有用。既存 VPC で Flow Logs 料金（Network telemetry 料金）に注意が必要か。 Gemini Enterprise で Sensitive Data Protection のコンテンツポリシーが使用可能に Protect sensitive data in sources (2026-08-31) Gemini Enterprise と Gemini Notebook Enterprise で、Sensitive Data Protection のコンテンツポリシーが使用可能になった。 コンテンツポリシーをデータストアやアシスタントに割り当てることができ、機密情報の取得やアップロードを水際で防げる。テキスト、PDF、画像など様々な形式に対応。 コンテンツポリシーとは、ビルトインまたはカスタムの infoType 検出器をリアルタイム適用できる仕組み。 BigQuery Graph が一般公開（GA） Introduction to BigQuery Graph (2026-08-31) BigQuery Graph が一般公開（GA）。 BigQuery 上で大規模なグラフデータの格納や GQL（Graph Query Language）を用いたクエリ実行が可能。 GA に伴い CALL ステートメントや探索パスの特性を検査する関数（IS_ACYCLIC、IS_SIMPLE、IS_TRAIL）が追加され、より高度分析が可能になった。 BigQuery の生成AI関数のトークンのクォータ（上限）が任意に設定できるように Control costs with token quotas (2026-08-31) BigQuery の生成AI関数（AI.GENERATE_TEXTなど）の1日のトークンのクォータ（上限）が任意に設定できるようになった。 予期しない大量実行やループ処理によるトークンの過剰消費を抑制し、コスト管理を計画的・安全に制御できる。なお以前リリースされたが一時的に停止していた。 Google Workspace のアップデート Google Meet の自動メモ作成で投影物のスクリーンショット保存されるように Visual screenshots in Google Meet meeting notes will soon be generally available, pre-configure admin settings in advance (2026-07-27) Visual screenshots now included in Google Meet meeting notes (2026-08-03) Google Meet の自動メモ作成（Take notes for me）で投影されたスライドなどのスクリーンショットがメモ内に保存されるようになる。 2026-08-03から15日間かけてロールアウト。 Google Workspace Studio で Gemini Notebook にソースデータを追加可能に Automatically add sources to your Gemini Notebooks in Workspace Studio (2026-08-07) Google Workspace Studioで、Gemini Notebook（旧称 NotebookLM）にソースデータを追加するアクションが使えるようになった。 使用例として、Google ドライブへのファイル追加を検知して Notebook に自動追加などが可能。 Excel ファイルを Google スプレッドシートにインポートする際の互換性が向上 Improved file importing in Google Sheets with tables and linked pivot tables (2026-08-11) Excel ファイルを Google スプレッドシートにインポートする際の互換性が向上。アップデートは2点で、以下のインポート後の手直しが不要になった。 Excel の「テーブル」がスプシの「テーブル」として認識される Excel のテーブル範囲を参照するピボットテーブルがスプシでもピボットとして認識される Connected Sheets で「リストパラメータ」と「列名エイリアス」機能 Improved file importing in Google Sheets with tables and linked pivot tables (2026-08-11) Connected Sheets（BigQueryデータをスプレッドシートに読み込める機能）で「リストパラメータ」と「列名エイリアス」機能がリリース。 リストパラメータ: セルの内容に応じて SQL の WHERE 句を動的に生成 列名エイリアス: スプシ上で列のエイリアス名を任意に設定できる Google Workspace のスプレッドシートで Sheets Canvas がリリース Use Sheets canvas to visualize data in custom, interactive mini-apps (2026-08-13) Google Workspace のスプレッドシートで Sheets Canvas がリリース。 スプシにインタラクティブなアプリ（可視化ダッシュボードやカンバンボードなど）を組み込める。Gemini に自然言語で指示して作成。 Take notes for me が Web 会議だけでなく対面会議でも使えるように Take Notes for me for in-person meetings is now available (2026-08-13) Google Meet の自動議事メモ（Take notes for me）が Web 会議だけでなく対面会議でも使えるようになった。 会議音声をスマホ等で Meet に聞かせると、議事メモを作成して Google ドキュメントにまとめてくれる。要約やアクションアイテムも整理される。Business Standard 以上に順次展開。 Drive Inventory Reportingで外部共有関連の情報をエクスポートできるように Enhanced external sharing insights now available in Drive Inventory Reporting (2026-08-17) Drive Inventory Reporting（Google ドライブの使用状況レポートを BigQuery にエクスポートする機能）で外部共有に関する情報をエクスポートできるようになった。 外部組織やインターネットへの共有有無がわかりやすい。明示的にオンにする必要あり。 Google Workspace Studio でエンタープライズ向けセキュリティ機能が強化 New enterprise security controls for Workspace Studio enable expanded collaboration use cases (2026-08-17) Google Workspace Studio でエンタープライズ向けセキュリティ機能が強化。 Agent Identity: フローによる自動化処理は最小権限を持つ一意の ID で自動化処理を実行 監査ログ強化: Studio での設定および実行操作は、Studio の監査イベントに記録される。ドライブ内ファイルへの編集や Gmail でのメール送信など、操作に関する監査イベントには、一意のフロー識別子や所有者情報などのフローコンテキストが含まれる 管理者からの制御強化: OAuthスコープ取り消し、一時停止など Human-in-the-Loop の強制: 管理者設定で、人間の承認なしに外部へのデータ送信を禁止することが可能に Google Chat に Workspace Intelligence のハブとなる Ask Gemini 画面が登場 Introducing Ask Gemini in Chat: your new partner in productivity (2026-08-19) Google Chat に Ask Gemini 画面が登場する。Gemini が Google Workspace 全体からコンテキストを収集（Workspace Intelligence）して、タスクを行うためのハブとなる。ドライブ、Gmail、カレンダーなどを横断して Gemini が情報収集したうえで、質問への回答やコンテンツ生成、予定の作成など、さまざまなタスクの中心となる。 2026-08-26から順次展開開始、まずは英語版のみ。 Gemini アプリでインタラクティブな 3D モデルを生成できるように Generate interactive simulations and models in the Gemini app (2026-08-24) Gemini アプリでインタラクティブな 3D モデルを生成できるようになった。 DNA 構造などをインタラクティブに回転させたりズームインするなど。Google Workspace 等で既に展開済（Available now）。 Microsoft OneDrive からのデータインポート（Advanced モード）が一般公開 Introducing data import for Microsoft OneDrive: An easier, faster, and higher-fidelity migration to Google Workspace (2026-08-25) Google Workspace で Microsoft OneDrive からのデータインポート（Advanced モード）が一般公開。 複数のまとまりを同時並行でインポートできるため高速。並列度は、MS 側のクォータにあわせて調整可能。追加費用なし。移行時間の見積ツールも付帯している。 Microsoft Teams からのチャット情報のデータインポート機能が一般公開 Introducing data import for Microsoft Teams: An easier, faster, and higher-fidelity migration to Google Workspace (2026-08-25) Google Workspace で Microsoft Teams からのチャット情報のデータインポート機能が一般公開。 Teams のチャネル、チャネルメッセージ、グループチャット、DM を並列処理で高速に Google Chat に移行できる。追加費用なし。移行時間の見積ツールも付帯している。 Google カレンダーで Teams や Zoom などからの招待がわかりやすく Improving Google Calendar’s interoperability with third-party video conferencing solutions (2026-08-27) Google カレンダーで Microsoft Teams や Zoom など他媒体からの招待を受信したときの体験が改善。 予定の「場所」欄に会議 URL が記載されたり、招待の会議 ID、PIN コードなどが構造的に識別され「参加」ボタンがわかりやすく表示される等。 Google ドライブで AI によるデータ自動ラベリング機能がオープンベータ開始 Gemini-based data classification in Google Drive is now available in open beta (2026-08-28) Google ドライブで、Gemini によるデータ自動ラベリング機能がオープンベータ開始。 管理者が自然言語でプロンプトを定義するだけで、Gemini がファイルを評価して分類ラベルを自動的に付与する。機械学習用のデータ準備不要。大規模な DLP ポリシーの適用や保持ルールの徹底が簡素化できる。 予定主催者が受け取る出席可否メール通知をイベント単位で無効化できるように Suppress email responses to calendar invitations and updates (2026-08-28) Google カレンダーで、予定の主催者が受け取る出席可否のメール通知をイベント単位で無効化できるようになった。 「ゲストが回答したときにメールを受け取る」のチェックを外す。これで全社イベントなどで出欠通知が大量になりすぎるのを防げる。順次ロールアウト。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。Google Cloud のフルマネージドな SFTP サーバーサービスである Cloud FTP について、特徴やアーキテクチャ、接続方法、セキュリティ設定などを解説します。 Cloud FTP とは 概要 制限 ユースケース メリット 料金 アーキテクチャ 外部サーバーと内部サーバー ユーザー管理と認証・認可 ディレクトリマッピング サポートされる SFTP 操作 サポートされるコマンド一覧 注意点 監査ログ 概要 管理アクティビティログ データアクセス監査ログ VPC Service Controls との統合 概要 注意点 運用上の考慮事項 構築手順 必要な IAM ロール API の有効化 SFTP サーバーの作成 ユーザー用サービスアカウントの作成 ユーザー用サービスアカウントへの権限付与 サービスエージェントへのトークン作成者ロール付与 SFTP ユーザーの作成 PSC エンドポイントの作成（内部サーバーのみ） 接続手順 Cloud FTP とは 概要 Cloud FTP は、Google Cloud が提供するフルマネージドな SFTP（SSH File Transfer Protocol）サーバーサービスです。 当サービスを使うと、SFTP プロトコルを経由して、Google Cloud のオブジェクトストレージである Cloud Storage バケットに対してファイルをアップロードしたり、ダウンロードしたりできます。SFTP は、その経路が SSH によって暗号化されているプロトコルであるため、セキュアにファイルのやりとりが可能です。 クライアント側は、Cyberduck や FileZilla、WinSCP などの一般的な GUI クライアントや、Linux や macOS の標準的な sftp コマンドラインツールを使用して、従来の SFTP サーバーと同様の操作感で Cloud Storage を使用できます。 クライアントとサーバー間の認証は、公開鍵認証方式によって行われます。パスワード認証には対応していません。 参考 : Cloud FTP overview アーキテクチャのイメージ 制限 Cloud FTP は、限られたリージョンでのみ使用できます。2026年8月末現在、東京（asia-northeast1）リージョンや大阪（asia-northeast2）リージョンには Cloud FTP サーバーを作成できません。 ただし、Cloud FTP サーバーと Cloud Storage バケットのリージョンが一致している必要はありません。例えば、Cloud FTP サーバーを asia-northeast3（ソウル）リージョンに作成し、バックエンドの Cloud Storage バケットは東京（asia-northeast1）リージョンを指定する、といった設定が可能です。このようにすれば、データ転送速度やリージョン間転送コストの観点ではデメリットがあるものの、日本国内のユーザーが当サービスを使用できないわけではありません。 参考 : Cloud FTP locations ユースケース Cloud FTP は、以下のようなユースケースに適しています。 オンプレミスやレガシーシステムからのデータ転送 クラウドネイティブな API や SDK への移行が困難な既存バッチ処理・基幹システムから、従来の SFTP 手順を変更せずにデータを Google Cloud へ集約する。仮想サーバーに SFTP サーバーを構築したり、運用したりする必要はない。 社外とのファイル連携 Google Cloud アカウントを持たない外部ベンダーや取引先に対して、セキュアな SFTP インターフェースを提供し、指定した Cloud Storage バケットのみへのアクセスを許可する。 データ分析基盤のデータ受領 外部から SFTP 経由で受け取った CSV やログファイルを Cloud Storage に配置し、BigQuery などの分析基盤や Cloud Run functions 等によるイベント駆動処理へと連携する。 メリット Cloud FTP は、VM 等に通常の SFTP サーバーを構築することに比べて、以下のようなメリットがあります。 運用負荷の削減 Cloud FTP はフルマネージドサービスであるため、OS や SFTP ソフトウェアの構築、セキュリティパッチ適用、スケーリング、可用性維持などの管理は不要です。 Cloud Storage の耐久性と拡張性 バックエンドストレージが Cloud Storage であるため、高い耐久性と容量制限を意識しないスケーラビリティをそのまま享受できます。 Google Cloud セキュリティとの統合 接続元の IP アドレス制限や公開鍵認証に加え、IAM とサービスアカウントによるきめ細かなアクセス制御、VPC Service Controls によるデータ境界、Cloud Audit Logs による監査ログ取得が可能です。 料金 Cloud FTP は、 サーバーの稼働時間 と、 転送データ量 （アップロード / ダウンロード）に応じた従量課金です。 サーバー稼働時間については、1時間あたり $0.30 です。サーバーを停止している間は、課金されません。 転送データ量については、アップロード / ダウンロードともに、$0.04/GB です。 これらに加えて、通常の Cloud Storage 料金（データ保管料金やリクエストあたりの料金等）、またデータ転送料金など、関連サービスへの課金が発生します。 参考 : Cloud FTP pricing アーキテクチャ 外部サーバーと内部サーバー Cloud FTP では、用途とネットワーク要件に応じて2種類のサーバータイプから選択してプロビジョニングします。なお、一度サーバーを作成した後にアクセスタイプ（External / Internal）を変更することはできません。 項目 外部サーバー（External） 内部サーバー（Internal） アクセス経路 インターネット経由 VPC ネットワーク内経由（Private Service Connect、略称 PSC） エンドポイント パブリック IP アドレス PSC サービスアタッチメント（Service Attachment） ネットワーク制御 接続元 CIDR ブロック（最大500個） 許可プロジェクトリスト（最大500個）/ 拒否プロジェクトリスト（最大64個） 主な用途 外部取引先やインターネット越しのファイル送受信 社内システム、VPC 内の VM、オンプレミス（Cloud Interconnect / VPN 経由） 外部サーバーには、パブリック IP アドレスが割り当てられ、接続元 IP アドレス範囲を CIDR ブロックで登録してアクセスを制限します。 0.0.0.0/0 を指定して全ての接続元からのアクセスを許可することも可能です。 内部サーバーでは、Private Service Connect（PSC）のサービスアタッチメントが作成されます。コンシューマ VPC （アクセス元の VPC）側に PSC エンドポイントを作成することで、インターネットを経由せずプライベート IP アドレス経由で SFTP 接続を行います。これにより、専用線や VPN を経由してオンプレミスのクライアントから接続したり、あるいは VPC ネットワーク内の VM からアクセスできます。 参考 : Create an external SFTP server 参考 : Create an internal SFTP server ユーザー管理と認証・認可 Cloud FTP は、SFTP ユーザーの認証に SSH 公開鍵暗号方式 を使用します。パスワード認証には 対応していません 。 認可（権限管理）は、Google Cloud の IAM の仕組みによって行われ、ユーザーを サービスアカウント とマッピングすることで実現されます。 SFTP クライアントが SSH 秘密鍵を使用して Cloud FTP サーバーに接続 Cloud FTP サーバーが、登録された SSH 公開鍵でユーザーを認証 Cloud FTP サービスエージェントが、対象ユーザーに紐付けられたユーザー専用サービスアカウントの短期アクセストークンを生成（権限借用） 生成されたトークンを用いて、Cloud Storage バケットに対する読み取りや書き込み操作を実行 この仕組みにより、SFTP ユーザーごとに操作可能な Cloud Storage バケットやフォルダ、権限（読み取り専用 / 読み書き）を IAM によって厳密に制御できます。 参考 : Add users to an SFTP server ディレクトリマッピング Cloud FTP では、SFTP ユーザーがログインした際に見えるディレクトリ構造（論理ディレクトリ）と、実際の Cloud Storage バケット（およびフォルダプレフィックス）をマッピングします。 ディレクトリマッピングには以下の仕様・制限事項があります。 制限の概要 説明 バケット数の上限 1ユーザーにつき最大10個のバケットをマッピング可能 公開鍵数の上限 1ユーザーにつき最大10個の SSH 公開鍵を登録可能 フラットな論理ディレクトリ構造 ネストされた論理ディレクトリはサポートされない。例えば /dir1 と /dir2 を並列にマッピングすることは可能だが /dir1 と /dir1/dir2 のような階層構造を定義することはできない アクセス権限の指定 マッピングごとに READ_ONLY （読み取り専用）または READ_WRITE （読み書き可能）のパーミッションを指定可能 参考 : Add users to an SFTP server サポートされる SFTP 操作 サポートされるコマンド一覧 Cloud FTP では、標準的な SFTP コマンドおよびファイル操作がサポートされています。 コマンド 説明 備考 ls カレントディレクトリ内のファイル一覧表示 -1 , -a , -f , -h , -l , -r , -S , -t フラグをサポート cd ディレクトリの移動 マッピングされた論理ディレクトリ間を移動 pwd カレントのリモート作業ディレクトリを表示 - get ファイルのダウンロード -R フラグによるフォルダの再帰的ダウンロードに対応 put ファイルのアップロード -R フラグによるフォルダの再帰的アップロードに対応。既存ファイルは上書き mkdir ディレクトリの作成 Cloud Storage 上ではプレフィックス/空フォルダオブジェクトとして扱われる rm ファイルの削除 Cloud Storage 上のオブジェクトを削除 rmdir ディレクトリの削除 ディレクトリ内の全ファイルを削除した後に実行可能 rename ファイル名またはフォルダ名の変更 フォルダ名変更は階層型名前空間（Hierarchical Namespace）有効バケットのみ対応 progress 転送進行状況メーターの表示切り替え - version SFTP プロトコルバージョンの表示 - bye / exit / quit SFTP セッションの終了 - 参考 : Transfer data by using SFTP commands 注意点 Cloud FTP でファイルやディレクトリを操作する際は、以下の仕様に留意する必要があります。 概要 説明 フォルダのリネーム バックエンドがオブジェクトストレージのため、通常のバケットではフォルダのリネーム（ rename ）はサポートされない。フォルダのリネームを行いたい場合は、 階層型名前空間 （Hierarchical Namespace）を有効化した Cloud Storage バケットを使用する必要がある ディレクトリの削除 rmdir コマンドでディレクトリを削除する場合、ディレクトリ配下にオブジェクトが存在しない状態（空の状態）にしてから削除する必要がある ファイルの自動上書き put コマンドで同名ファイルをアップロードした場合、確認なしに既存の Cloud Storage オブジェクトが上書きされる 監査ログ 概要 Cloud FTP の管理操作およびデータアクセス操作は、Cloud Audit Logs の仕組みを使って記録され、Cloud Logging に出力されます。 Cloud Audit Logs については、以下の記事を参照してください。 blog.g-gen.co.jp Cloud FTP 関連の監査ログとしては「管理アクティビティ監査ログ」「データアクセス監査ログ」の2種類が出力されます。 参考 : Cloud FTP audit logging 管理アクティビティログ サーバーやユーザーの管理における更新系の操作は、Cloud FTP の 管理アクティビティ監査ログ として記録されます。管理アクティビティ監査ログは、プロジェクトでデフォルトで有効化されています。 具体的には、以下のようなアクションが記録されます。 サーバーやユーザーの作成（ CreateServer , CreateUser ） サーバーやユーザーの削除（ DeleteServer , DeleteUser ） サーバーの開始・停止（ StartServer , StopServer ） サーバーの設定更新（ UpdateServer , UpdateUser ） Cloud Logging のログエクスプローラで以下のクエリを実行することで、Cloud FTP の管理アクティビティ監査ログを抽出できます。 my-project はプレイスホルダーであるため、置換してください。 protoPayload.serviceName= " ftp.googleapis.com " AND logName= " projects/my-project/logs/cloudaudit.googleapis.com%2Factivity " データアクセス監査ログ 前述のとおり、SFTP 経由で行われた Cloud Storage に対するファイル送受信操作は、 Cloud Storage 側のデータアクセス監査ログ （ storage.googleapis.com ）として記録されます。Cloud Logging のログエクスプローラのクエリは以下のとおりです。 protoPayload.serviceName= " storage.googleapis.com " AND logName= " projects/my-project/logs/cloudaudit.googleapis.com%2Fdata_access " また、サーバーやユーザーの参照操作（ GetServer , GetUser , ListServers , ListUsers ）は、 Cloud FTP 側のデータアクセス監査ログ （ ftp.googleapis.com ）として記録されます。Cloud Logging のログエクスプローラのクエリは以下のとおりです。 protoPayload.serviceName= " ftp.googleapis.com " AND logName= " projects/my-project/logs/cloudaudit.googleapis.com%2Fdata_access " データアクセス監査ログは、デフォルトではプロジェクトで無効化されています。プロジェクト全体、またはサービスごとのデータアクセス監査ログを、明示的に有効化する必要があります。 参考 : データアクセス監査ログを有効にする VPC Service Controls との統合 概要 Cloud FTP は、機密データの流出を防止する VPC Service Controls に対応しています。VPC Service Controls の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp Cloud Storage バケットを保護するサービス境界内に Cloud FTP を統合する場合、以下の構成を行います。 保護対象プロジェクトの追加 : Cloud Storage バケットを含むプロジェクト、および SFTP サーバーを含むプロジェクトを同一サービス境界に追加します（別境界の場合は境界ブリッジを構成）。 制限対象サービスの追加 : ftp.googleapis.com および storage.googleapis.com を制限対象サービスに指定します。 アクセスレベルの定義 : 接続を許可する SFTP クライアントの IP アドレス / CIDR ブロックをアクセスレベルとして定義します。 内向きルールの設定 : 送信元（From）: 作成したアクセスレベル、およびユーザーのサービスアカウント 送信先（To）: 対象プロジェクト、サービス ftp.googleapis.com 上記は設定手順の概要です。詳細は以下のドキュメントを参照してください。 参考 : Configure VPC Service Controls for Cloud FTP 注意点 コンテキスト情報は使用不可 SFTP / SSH セッションにはデバイスポスチャーメタデータ（Chrome Enterprise Premium 等のデバイス健全性に関する属性）が付与されないため、内向きルールの評価に使えるのは、IP アドレスおよび ID 条件のみです。 内部サーバーにおける注意点 内部サーバーの場合、VPC Service Controls の境界の設定の適用は サーバー作成時にのみ 行われます。内部サーバー作成後にサービス境界の設定（メンバープロジェクトの変更や内向きルールの変更など）を更新しても、そのルールは適用されません。変更後のルールを適用するには、内部サーバーを再作成する必要があります。 運用上の考慮事項 クライアントの自動再試行 Cloud FTP はフルマネージドですので、定期的にインフラの自動メンテナンスやパッチ適用が行われます。その際、一時的なセッション切断が発生する可能性があります。クライアント側で自動再試行を有効にしておくことが推奨されます。 Cloud Asset Inventory 未対応 2026年8月現在、Cloud FTP リソースは Cloud Asset Inventory によるアセット追跡・検索に対応していません。 1ユーザーあたりのリソース上限 1ユーザーにマッピング可能な Cloud Storage バケット数は最大10個、登録可能な SSH 公開鍵は最大10個です。 サーバー作成時間 サーバーのプロビジョニングには約10分を要します。CI/CD パイプライン等で動的に作成・破棄する運用を検討する場合は、この所要時間を織り込む必要があります。 サーバー停止によるコスト削減（Start / Stop） データ転送が行われない夜間や休日、あるいはバッチ処理時間外などにサーバーを一時停止（Stop）することで、サーバーの稼働コストを削減できます。サーバーを停止すると、アクティブな接続は切断され、新規接続は拒否されます。データ送受信を再開したい時は、サーバーを開始（Start）します。 参考 : Start or stop an SFTP server 構築手順 必要な IAM ロール Cloud FTP のサーバーおよびユーザーの構築・管理を行う管理者は、以下の IAM ロールを保持している必要があります。 プロジェクトに対する、Cloud FTP 管理者（ roles/ftp.admin ） ユーザーごとのサービスアカウントに対する、サービス アカウント ユーザー（ roles/iam.serviceAccountUser ） 対象バケットに対する、Storage バケット閲覧者（ roles/storage.bucketViewer ） 対象バケットに対する、Storage オブジェクト閲覧者（ roles/storage.objectViewer ） なおプロジェクトレベルでオーナー（ roles/owner ）や編集者（ roles/editor ）を持っていれば、これらの権限はすべて内包されています。 API の有効化 Cloud FTP を使用するには、まず対象の Google Cloud プロジェクトで Cloud FTP API を有効化します。 gcloud services enable ftp.googleapis.com SFTP サーバーの作成 サーバーを作成するには、 gcloud alpha storage ftp servers create コマンドを実行します。サーバーのプロビジョニングには約10分かかります。 外部サーバー（External）の場合 外部サーバーを作成する場合は、 --access-type=EXTERNAL と --allowed-cidr-blocks を指定します。 gcloud alpha storage ftp servers create my-external-server \ --access-type = EXTERNAL \ --location = asia-northeast3 \ --allowed-cidr-blocks = 203 . 0 . 113 . 0 / 24 , 198 . 51 . 100 . 50 / 32 --location : サーバーを配置する Google Cloud リージョンを指定します。データ転送速度を最適化するため、マッピング先 Cloud Storage バケットと同一リージョン（または最も近いリージョン）を選択することが推奨されます。 --allowed-cidr-blocks : 接続を許可するクライアントの IP アドレス範囲をカンマ区切りで指定します（最大500個）。 --location オプションには Cloud FTP がサポートするリージョンを指定する必要がありますが、バックエンドの Cloud Storage バケットと異なるリージョンを指定しても構いません。2026年8月末現在、日本国内リージョンはサポートされていませんので、バケットが日本国内リージョンの場合は、地理的に近い asia-northeast3（ソウル）リージョン等が推奨されます。 参考 : Cloud FTP locations 内部サーバー（Internal）の場合 内部サーバーを作成する場合は、 --access-type=INTERNAL と --consumer-accept-list を指定します。 gcloud alpha storage ftp servers create my-internal-server \ --access-type = INTERNAL \ --location = asia-northeast3 \ --consumer-accept-list = my-consumer-project-id = 10 \ --consumer-reject-list = rejected-project-id --consumer-accept-list : Private Service Connect 経由で接続を許可するコンシューマプロジェクト ID（またはプロジェクト番号）と、作成可能なエンドポイント数の上限値（1〜250）を PROJECT_ID=LIMIT 形式で指定します（カンマ区切りで最大500プロジェクト）。 --consumer-reject-list : 接続を明示的に拒否するプロジェクトを指定します（任意、最大64プロジェクト）。 ユーザー用サービスアカウントの作成 クライアントとして接続する SFTP ユーザーを作成します。 SFTP ユーザーが Cloud Storage にアクセスするための専用サービスアカウントを作成します。ユーザーごとに個別のサービスアカウントを作成することが推奨されています。 gcloud iam service-accounts create sftp-user01-sa \ --description =" Service Account for SFTP user01 " \ --display-name =" sftp-user01-sa " 上記のコマンドの sftp-user01 は例です。ユーザーの判別ができる名称とすることが推奨されます。 次に、SFTP ユーザーを作成する管理者自身に、先ほど作成したサービスアカウントに対する roles/iam.serviceAccountUser ロールを付与します。 gcloud iam service-accounts add-iam-policy-binding sftp-user01-sa@my-project.iam.gserviceaccount.com \ --member =" user:admin@example.com " \ --role =" roles/iam.serviceAccountUser " ユーザー用サービスアカウントへの権限付与 ユーザー用サービスアカウントに対して、対象の Cloud Storage バケットへのアクセス権を付与します。 読み取り専用アクセスの場合は、 Storage オブジェクト閲覧者 （ roles/storage.objectViewer ）を付与します。 読み取りと書き込みができるアクセスの場合は、 Storage オブジェクト管理者 （ roles/storage.objectAdmin ）を付与します。 gcloud storage buckets add-iam-policy-binding gs://my-data-bucket \ --member =" serviceAccount:sftp-user01-sa@my-project.iam.gserviceaccount.com " \ --role =" roles/storage.objectAdmin " サービスエージェントへのトークン作成者ロール付与 Cloud FTP のサービスエージェントが、ユーザー用サービスアカウントのトークンを生成できるように、 サービス アカウント トークン作成者 （ roles/iam.serviceAccountTokenCreator ）ロールを付与します。 なお、サービスエージェントについては、以下の記事を参照してください。 blog.g-gen.co.jp まずは必要な前提情報を得るために、サーバーの詳細情報を取得してサービスエージェントのメールアドレスを確認します。 gcloud alpha storage ftp servers describe my-external-server \ --location = asia-northeast3 出力結果に含まれる serviceAgentEmail （例: p-1234567890-98765432109@gcp-sa-ftp.iam.gserviceaccount.com ）に対してロールを付与します。 gcloud iam service-accounts add-iam-policy-binding sftp-user01-sa@my-project.iam.gserviceaccount.com \ --member =" serviceAccount:p-1234567890-98765432109@gcp-sa-ftp.iam.gserviceaccount.com " \ --role =" roles/iam.serviceAccountTokenCreator " SFTP ユーザーの作成 認証情報ファイル（JSON）の準備 ユーザーの SSH 公開鍵（OpenSSH 形式）を記載した JSON ファイル（ credentials.json ）を作成します。 [ { " credentialName ": " user01-key ", " credentialType ": " PUBLIC_KEY ", " sshPublicKeyBody ": " ssh-rsa AAAAB3NzaC1yc2EAAAADAQD... " } ] SFTP ユーザーの作成 gcloud alpha storage ftp users create コマンドを実行して、ユーザーを作成し、ディレクトリマッピングを定義します。 gcloud alpha storage ftp users create user01 \ --server = my-external-server \ --location = asia-northeast3 \ --customer-service-account = sftp-user01-sa@my-project.iam.gserviceaccount.com \ --storage-directory-mapping = bucket =my-data-bucket, bucket_prefix =uploads, directory =/uploads, permission =READ_WRITE \ --user-credentials-from-file = credentials.json --storage-directory-mapping : bucket : 対象の Cloud Storage バケット名（ gs:// は不要）。 bucket_prefix : バケット内のフォルダパス（任意。省略時はバケットのルート）。 directory : SFTP ユーザーに見える論理パス（例 : /uploads ）。 permission : READ_ONLY または READ_WRITE 。 複数バケットをマッピングする場合は、このフラグを複数回指定します。 PSC エンドポイントの作成（内部サーバーのみ） 以下の手順は、内部サーバーの構築時のみ必要です。コンシューマ VPC（接続元の VPC ネットワーク）内に Private Service Connect（PSC）エンドポイントを作成します。 1. サービスアタッチメント URI の取得 内部サーバーの詳細情報から serviceAttachment の URI を確認します。 gcloud alpha storage ftp servers describe my-internal-server \ --location = asia-northeast3 URI の形式は projects/${SERVICE_PROJECT_ID}/regions/${REGION}/serviceAttachments/${SERVICE_NAME} のようになります。 2. Private Service Connect エンドポイントの作成 コンシューマ VPC 内で、転送ルール（フォワーディングルール）を作成して PSC エンドポイントを作成します。 ターゲット: 公開サービス（Published service） ターゲットサービス: 取得したサービスアタッチメント URI ネットワーク/サブネットワーク: クライアント VM が存在する VPC およびサブネット IP アドレス : エンドポイント用のプライベート IP アドレス なお、クライアント VM がサービスアタッチメントと異なるリージョンに存在する場合は、PSC エンドポイントの作成時にグローバルアクセス（Global access）を有効にする必要があります。 接続手順 SFTP サーバーの IP アドレスは gcloud alpha storage ftp servers describe コマンドで確認できます。 gcloud alpha storage ftp servers describe my-external-server \ --location = asia-northeast3 OpenSSH（sftp コマンド）の場合、ターミナルから SSH 秘密鍵を指定して接続します。 sftp -i ~/.ssh/sftp_user_key user01@ 34 . 22 .xx.xx また GUI クライアントの場合は、クライアントソフトに応じて適切に設定値を入力します。一例として、WinSCP での接続時の設定例を示します。 転送プロトコル : SFTP ホスト名 : サーバーの IP アドレス ポート番号 : 22 ユーザー名 : user01 設定 > SSH > 認証 > 「秘密鍵ファイル」で秘密鍵を指定 詳細は以下のドキュメントも参照してください。 参考 : Connect to an external SFTP server 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の佐々木です。当記事では、Cloud Run の新しいリソースタイプである Cloud Run instances に、 Agent Development Kit （以下、ADK と記載）で開発した AI エージェントをデプロイして使ってみます。 構成 当記事で使用するもの Cloud Run instances Agent Development Kit（ADK） エージェントの開発 uv プロジェクトの作成 ディレクトリ構成 __init__.py agent.py Dockerfile Google Cloud 側の準備 gcloud CLI の更新 API の有効化 サービスアカウントの作成 コンテナイメージのビルド デプロイ 動作確認 未認証アクセスの拒否 proxy 経由でのアクセス エージェントとの対話 ログの確認 停止とセッションの扱い 停止・起動 再起動 後片付け 構成 当記事では、ADK で開発したシンプルな AI エージェントを、Cloud Run instances のインスタンスとしてホストします。エージェントは Gemini 3.5 Flash をモデルとして使用し、現在時刻を返すカスタムツールを1つ持ちます。 Cloud Run instances は、 単一のインスタンスが長時間動き続ける という特性から、長寿命の AI エージェントのホスティングが主要なユースケースとして想定されています。公式チュートリアルでは n8n や Openclaw といった既製プラットフォームをホストする手順が紹介されていますが、当記事では ADK で開発した自作エージェントをデプロイします。 また、AI エージェントを社外に公開しない前提で、以下の2点をポイントとして構成します。 インスタンスの呼び出し元 IAM チェック（invoker IAM check）を有効のままにし、エージェントの REST API には proxy コマンド経由でアクセスする Gemini の呼び出しは API キーではなく、 Gemini Enterprise Agent Platform （旧称 Vertex AI、以下 Agent Platform と記載）とインスタンスのサービス ID（サービスアカウント）で認証する 参考 : Cloud Run インスタンスでエージェントをホストする 当記事で使用するもの Cloud Run instances Cloud Run instances は、Cloud Run 上で単一のコンテナインスタンスを個別に作成・管理できるリソースタイプです。リクエスト量に応じて水平スケーリングする Cloud Run サービスとは異なり、1つのリソースにつき常に1つのインスタンス（シングルトン）が継続的に稼働し、作成・停止・起動・削除といったライフサイクル操作を個別に行えます。 2026年8月現在、Cloud Run instances は Preview 公開の機能です。 Cloud Run instances の特徴やユースケース、他のリソースタイプ・サービスとの比較は、以下の解説記事を参照してください。 blog.g-gen.co.jp Agent Development Kit（ADK） ADK は、Google が開発した AI エージェント開発用のオープンソースフレームワークです。Python などのコードでエージェントの動作（モデル、指示、ツール）を定義し、開発用の Web UI や REST API を備えたサーバーとして実行できます。 参考 : Agent Development Kit エージェントの開発 uv プロジェクトの作成 Python のパッケージ管理には uv を使用します。 uv init コマンドでプロジェクトを作成し、 uv add コマンドで ADK を依存関係に追加します。 # uv プロジェクトを作成（--bare オプションで pyproject.toml のみを生成） $ uv init adk-agent --bare $ cd adk-agent # google-adk を依存関係に追加 $ uv add google-adk uv add を実行すると、 pyproject.toml の dependencies に google-adk>=2.7.1 が追記され、実際に解決されたバージョンが uv.lock に固定されます。筆者が検証した2026年8月現在の最新バージョンは 2.7.1 です。後述の Dockerfile では uv.lock に基づいて依存関係をインストールするため、ビルドする環境や時期によるバージョンの差異を排除できます。 また、 uv add はプロジェクト直下に仮想環境 .venv を作成します。 .venv はローカル実行用のディレクトリで、コンテナイメージには含めないため、以下の1行を記載した .gcloudignore を作成し、後述の Cloud Build へのアップロード対象から除外します。 .venv ディレクトリ構成 最終的なディレクトリ構成は以下のとおりです（ .venv は省略しています）。 pyproject.toml と uv.lock は uv が生成したファイルで、これ以外のファイルをこの後の手順で作成します。 adk-agent/ ├── .gcloudignore ├── Dockerfile ├── pyproject.toml ├── uv.lock └── my_agent/ ├── __init__.py └── agent.py __init__.py my_agent/__init__.py の内容は以下の1行です。 from . import agent agent.py エージェント本体の定義です。現在の日本時間を返すカスタムツール get_current_time を持つ、シンプルなアシスタントエージェントを定義します。モデルには gemini-3.5-flash を使用します。 import datetime import zoneinfo from google.adk.agents import Agent # 現在の日本時間を返すカスタムツール def get_current_time () -> dict : """現在の日本時間を返します。""" now = datetime.datetime.now(zoneinfo.ZoneInfo( "Asia/Tokyo" )) return { "current_time" : now.strftime( "%Y-%m-%d %H:%M:%S" )} root_agent = Agent( name= "my_agent" , model= "gemini-3.5-flash" , description= "時刻の質問にも答えられるシンプルなアシスタントエージェント" , instruction=( "あなたは親切なアシスタントです。ユーザーの質問に日本語で簡潔に答えてください。" "現在時刻を聞かれた場合は get_current_time ツールを使用してください。" ), tools=[get_current_time], ) Dockerfile コンテナの起動コマンドには adk api_server を使用します。 adk api_server は、エージェントを REST API として公開する、Web UI を含まないサーバーです。 ADK には、開発用の Web UI を備えた adk web コマンドもありますが、この Web UI は開発・テスト専用で、本番利用は公式に非推奨です。当記事では、デプロイには adk api_server を採用し、開発用 Web UI はローカル環境で uv run adk web を実行して使用する使い分けとします。 参考 : API Server - Agent Development Kit (ADK) 参考 : Use the Web Interface - Agent Development Kit (ADK) ベースイメージには、uv が同梱された公式イメージ ghcr.io/astral-sh/uv:python3.12-bookworm-slim を使用します。 uv sync --locked により、 uv.lock に固定されたバージョンのとおりに依存関係をインストールします。 FROM ghcr.io/astral-sh/uv:python3.12-bookworm-slim WORKDIR /app COPY pyproject.toml uv.lock ./ RUN uv sync --locked COPY my_agent/ ./my_agent/ CMD [ " uv ", " run ", " adk ", " api_server ", " --host ", " 0.0.0.0 ", " --port ", " 8080 " ] 参考 : Using uv in Docker | uv Google Cloud 側の準備 gcloud CLI の更新 Cloud Run instances を操作する gcloud beta run instances コマンド群は、Google Cloud SDK 582.0.0 以降に収録されています。それより古いバージョンでは、以下のようなエラーが発生します。 # 古い SDK で実行した場合のエラー（581.0.0 で確認） $ gcloud beta run instances list --region asia-northeast1 ----- 出力例 ----- ERROR: ( gcloud.beta.run ) Invalid choice: ' instances ' . This command is available in one or more alternate release tracks. Try: gcloud alpha run instances このエラーが発生した場合は、 gcloud components update コマンドで SDK を最新化してください。apt でインストールした環境ではコンポーネントマネージャが無効のため、代わりに sudo apt-get update && sudo apt-get --only-upgrade install google-cloud-cli を実行します。 API の有効化 当記事の手順で使用する API を有効化します。 # Cloud Run、Cloud Build、Artifact Registry、Agent Platform の API を有効化 $ gcloud services enable \ run.googleapis.com \ cloudbuild.googleapis.com \ artifactregistry.googleapis.com \ aiplatform.googleapis.com サービスアカウントの作成 インスタンスのサービス ID として使用するサービスアカウントを作成し、プロジェクトレベルで Agent Platform ユーザー（ roles/aiplatform.user ）ロールを付与します。エージェントは、このサービス ID の権限で Agent Platform の Gemini を呼び出します。API キーを発行・配布する必要がなく、権限の管理を IAM に一元化できるためです。 # サービスアカウントを作成 $ gcloud iam service-accounts create adk-agent-sa \ --display-name =" ADK Agent Service Account " # プロジェクトレベルで Agent Platform ユーザーロールを付与 $ gcloud projects add-iam-policy-binding < プロジェクトID > \ --member =" serviceAccount:adk-agent-sa@<プロジェクトID>.iam.gserviceaccount.com " \ --role =" roles/aiplatform.user " コンテナイメージのビルド Artifact Registry にリポジトリを作成し、Cloud Build でエージェントのコンテナイメージをビルドします。 # Artifact Registry リポジトリを作成 $ gcloud artifacts repositories create adk-agent-repo \ --repository-format = docker \ --location = asia-northeast1 # エージェントのディレクトリでイメージをビルド $ cd adk-agent $ gcloud builds submit \ --tag asia-northeast1-docker.pkg.dev/ < プロジェクトID > /adk-agent-repo/adk-agent:latest ----- 出力例 ----- latest: digest: sha256: < ハッシュ値 > size: 1992 DONE デプロイ ビルドしたイメージを、 gcloud beta run instances create コマンドでインスタンスとしてデプロイします。デプロイを実行するユーザーには、以下のロールを付与しておきます。 Cloud Run デベロッパー（ roles/run.developer ）をプロジェクトレベルで付与 サービス アカウント ユーザー（ roles/iam.serviceAccountUser ）を、インスタンスのサービス ID として使用するサービスアカウントに対して付与 # ADK エージェントをインスタンスとしてデプロイ $ gcloud beta run instances create adk-agent \ --image asia-northeast1-docker.pkg.dev/ < プロジェクトID > /adk-agent-repo/adk-agent:latest \ --region asia-northeast1 \ --port 8080 \ --service-account adk-agent-sa@ < プロジェクトID > .iam.gserviceaccount.com \ --set-env-vars GOOGLE_GENAI_USE_VERTEXAI =TRUE, GOOGLE_CLOUD_PROJECT = < プロジェクトID > , GOOGLE_CLOUD_LOCATION =asia-northeast1 環境変数 GOOGLE_GENAI_USE_VERTEXAI=TRUE を設定すると、ADK は Gemini API の API キーではなく Agent Platform 経由でモデルを呼び出し、認証にはインスタンスのサービス ID が使用されます。環境変数名には旧称（Vertex AI）に由来する VERTEXAI が残っていますが、2026年8月現在も有効な変数名です。 GOOGLE_CLOUD_LOCATION=asia-northeast1 により、モデルの呼び出しも東京リージョンのエンドポイントで処理されます。 また、 --no-invoker-iam-check フラグは指定せず、呼び出し元の IAM チェックを有効のままにします。これにより、インスタンスの URL への呼び出しには IAM 認証が必須となり、権限を持たない呼び出しは拒否されます。エージェントの API を、インターネットに公開しないためです。 ----- 出力例 ----- Creating Cloud Run instance [ adk-agent ] in project [< プロジェクトID >] region [ asia-northeast1 ] Creating instance... Importing container...done Provisioning resources...done Starting instance...done Done. Instance [ adk-agent ] has successfully been created. SSH with: gcloud beta run instances ssh adk-agent --region asia-northeast1 URL: https://adk-agent- < プロジェクト番号 > .asia-northeast1.run.app Proxy locally with: gcloud beta run instances proxy adk-agent --region asia-northeast1 --project < プロジェクトID > To make this URL public, use gcloud beta run instances update adk-agent --no-invoker-iam-check --region asia-northeast1 当記事執筆時の検証では、コマンド実行から約30秒でデプロイが完了しました。出力例のとおり、デプロイの完了時には、インスタンスへのアクセス用に割り当てられた一意の URL（ https://<インスタンス名>-<プロジェクト番号>.<リージョン>.run.app 形式）と、そのインスタンスに接続するための proxy コマンドが出力されます。これらは後述の動作確認で使用します。 参考 : Create and manage Cloud Run instances 参考 : gcloud beta run instances create 動作確認 未認証アクセスの拒否 まず、インスタンスの URL に認証情報なしでアクセスしてみます。呼び出し元の IAM チェックが有効のため、HTTP 403 で拒否されます。 # インスタンスの URL に未認証でアクセス $ curl -s https://adk-agent- < プロジェクト番号 > .asia-northeast1.run.app ----- 出力例 ----- < html ><head> < meta http-equiv =" content-type " content = " text/html;charset=utf-8 "> < title > 403 Forbidden < /title > < / head> < body text =# 000000 bgcolor =#ffffff > < h 1> Error: Forbidden < /h 1> < h 2> Your client does not have permission to get URL < code > / < /code > from this server. < /h 2> < h 2>< /h 2> < /body >< /html > proxy 経由でのアクセス 保護されたインスタンスへは、 proxy コマンドでアクセスします。このコマンドはローカルマシンにプロキシサーバーを起動し、localhost への通信に gcloud CLI にログイン中のユーザーの認証情報を付与して、インスタンスの URL へ転送します。呼び出し元の IAM チェックはこの認証情報で通過するため、ブラウザや curl の側で認証処理を意識することなく、IAM で保護されたインスタンスにアクセスできます。 # インスタンスを localhost:8081 にプロキシ $ gcloud beta run instances proxy adk-agent --region asia-northeast1 --port 8081 ----- 出力例 ----- Proxying to Cloud Run instance [ adk-agent ] in project [< プロジェクトID >] region [ asia-northeast1 ] http:// 127 . 0 . 0 .1:8081 proxies to https://adk-agent- < プロジェクト番号 > .asia-northeast1.run.app なお、 proxy コマンドの初回実行時には cloud-run-proxy コンポーネントのインストールを求められます。apt でインストールした環境ではコンポーネントマネージャが無効のため、 sudo apt-get install google-cloud-cli-cloud-run-proxy を実行してインストールしてください。 プロキシを起動した状態で、別のターミナルから /list-apps エンドポイントにアクセスすると、デプロイ済みのエージェントの一覧が返ります。IAM 認証を通過して、保護されたインスタンスに到達できていることが確認できます。 # proxy 経由でエージェントの一覧を取得 $ curl -s http://localhost:8081/list-apps ----- 出力例 ----- [" my_agent "] エージェントとの対話 引き続き proxy コマンド経由で、REST API からエージェントと対話します。まず、対話のセッションを作成します。 # セッションを作成 $ curl -s -X POST http://localhost:8081/apps/my_agent/users/user1/sessions/session1 \ -H " Content-Type: application/json " -d ' {} ' ----- 出力例 ----- { " id " : " session1 " , " appName " : " my_agent " , " userId " : " user1 " , " state " : {} , " events " : [] , " lastUpdateTime " :1787720433. 3737211 } 作成したセッションに対して、エージェントへの質問を送信します。 # エージェントに質問を送信 $ curl -s -X POST http://localhost:8081/run \ -H " Content-Type: application/json " \ -d ' {"appName":"my_agent","userId":"user1","sessionId":"session1","newMessage":{"role":"user","parts":[{"text":"いま何時ですか？"}]}} ' レスポンスとして、エージェントの動作を表すイベントの配列が返ります。以下は主要な部分の抜粋です。 // 1. モデルがカスタムツールの呼び出しを判断 " functionCall ": { " id ": " call_32411 ", " args ": {} , " name ": " get_current_time " } , // 2. ツールの実行結果 " functionResponse ": { " id ": " call_32411 ", " name ": " get_current_time ", " response ": { " current_time ": " 2026-08-26 14:00:34 " } } , // 3. エージェントの最終応答 " parts ": [ { " text ": " 現在は2026年8月26日の午後2時（14時）0分です。 " } ] , 質問を受けたエージェントが get_current_time ツールを呼び出し、その結果を使用して日本語で回答していることがわかります。イベントの modelVersion フィールドからは、応答が gemini-3.5-flash によって生成されたことも確認できます。Gemini の呼び出しに API キーは使用しておらず、インスタンスのサービス ID に付与した IAM ロールだけで認証されています。 ログの確認 インスタンスのログは Cloud Logging に自動で取り込まれます。 logs read コマンドで、ADK サーバーの起動ログを確認できます。ログエクスプローラでは、 resource.type="cloud_run_instance" のようにして、インスタンス専用のモニタリングリソースタイプ cloud_run_instance でフィルタリングできます。 # インスタンスのログを表示 $ gcloud beta run instances logs read adk-agent --region asia-northeast1 ----- 出力例 ----- 2026-08-26 13:33:35 2026-08-26 13:33:35, 957 - INFO - service_factory.py:266 - Using in-memory memory service 2026-08-26 13:33:35 2026-08-26 13:33:35, 968 - INFO - local_storage.py:89 - Using per-agent session storage rooted at /app 2026-08-26 13:33:35 2026-08-26 13:33:35, 968 - INFO - local_storage.py:121 - Using per-agent artifact storage rooted at /app // 省略 2026-08-26 13:33:36 INFO: Started server process [ 15 ] 2026-08-26 13:33:36 INFO: Waiting for application startup. 2026-08-26 13:33:36 INFO: Application startup complete . 2026-08-26 13:33:36 INFO: Uvicorn running on http:// 0 . 0 . 0 .0:8080 ( Press CTRL+C to quit ) ログエクスプローラでは resource.type="cloud_run_instance" でログを検索できる 停止とセッションの扱い 停止・起動 Cloud Run インスタンスは stop コマンドで停止し、 start コマンドで再び起動できます。ここで注意が必要なのは、インスタンスには永続ディスクストレージがなく、停止するとメモリ上のデータが失われる点です。 当記事で使用している ADK 2.7.1 の adk api_server は、デフォルトでセッションをコンテナ内のローカルファイル（エージェントディレクトリ配下の .adk/session.db にある SQLite データベース）に保存します。しかし、インスタンスのファイルシステムはメモリ上にあるため、このファイルも停止すると失われます。実際に、インスタンスを停止・起動した後に先ほどのセッションを取得すると、HTTP 404 が返り、対話の履歴が失われたことが確認できます。 # インスタンスを停止して起動 $ gcloud beta run instances stop adk-agent --region asia-northeast1 --quiet $ gcloud beta run instances start adk-agent --region asia-northeast1 # 再起動後に元のセッションを取得 $ curl -s http://localhost:8081/apps/my_agent/users/user1/sessions/session1 ----- 出力例 ----- { " detail " : " Session not found " } 対話の履歴を保持する必要がある場合は、ADK のセッションサービスを使用して、セッションをデータベースなどの外部ストレージに永続化してください。Google Cloud のマネージドなセッション管理機能である Agent Platform セッション （Agent Platform Sessions）も、ADK のセッションサービスとして使用できます。この場合、エージェント自体は Cloud Run インスタンスでホストしたまま、セッションの保存先だけをマネージドサービスに任せられます。 参考 : Session: Tracking individual conversations - Agent Development Kit (ADK) 参考 : Agent Platform セッションの概要 再起動 明示的な再起動用の restart コマンドも用意されていますが、当記事執筆時に検証した2026年8月現在では、停止までは成功するものの起動に失敗し、インスタンスが停止状態のまま残る事象が発生しました。 # インスタンスを再起動（2026年8月現在、起動フェーズで失敗する事象を確認） $ gcloud beta run instances restart adk-agent --region asia-northeast1 --quiet ----- 出力例 ----- Stopping [ adk-agent ] ... done . Starting [ adk-agent ] ... failed. ERROR: ( gcloud.beta.run.instances.restart ) Instance [ adk-agent ] could not be started: Instance stopped. 執筆時の検証では、 stop の完了直後に start を実行した場合にも同じエラーが発生し、20秒ほど待ってから再実行すると正常に起動しました。停止処理の完了直後の起動で発生する、タイミングに起因する事象とみられます。このエラーが発生した場合でもインスタンス自体は失われておらず、時間をおいて start コマンドを実行すれば復旧します。 いずれも Preview 段階の挙動のため、今後のアップデートで解消される可能性があります。 後片付け 検証が完了したら、作成したリソースを削除します。Cloud Run instances はインスタンスの稼働時間に基づいて課金されるため、インスタンスは忘れずに削除してください。 # インスタンスを削除 $ gcloud beta run instances delete adk-agent --region asia-northeast1 ----- 出力例 ----- Deleting [ adk-agent ] ... done . Deleted instance [ adk-agent ] . # Artifact Registry リポジトリを削除 $ gcloud artifacts repositories delete adk-agent-repo --location = asia-northeast1 # サービスアカウントを削除 $ gcloud iam service-accounts delete adk-agent-sa@ < プロジェクトID > .iam.gserviceaccount.com 佐々木 駿太 (記事一覧) クラウドソリューション部 クラウドエンジニアリング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 Cloud のサーバーレスコンテナサービスである Cloud Run の新しいリソースタイプ、 Cloud Run instances について解説します。 概要 Cloud Run とは Cloud Run instances とは ユースケース Cloud Run instances の基本 特徴 ライフサイクルと再起動ポリシー 主な設定項目 CPU のバーストとスロットリング 注意点 料金 他のリソースタイプ・サービスとの比較 Cloud Run のリソースタイプ間の比較 Cloud Run services との違い Compute Engine との違い Agent Runtime との違い 開始方法 概要 Cloud Run とは Cloud Run は、コンテナを実行するための Google Cloud のフルマネージドなサーバーレスコンピューティングサービスです。サーバーの管理を必要とせず、コンテナイメージを指定するだけでアプリケーションを実行できます。 Cloud Run にはユースケースに応じた リソースタイプ が存在し、当記事で解説する Cloud Run instances の他に、Web アプリケーションや API のホスティング向けの Cloud Run services、バッチ処理やスケジュール実行向けの Cloud Run jobs、メッセージキューの pull 型処理向けの Cloud Run worker pools が提供されています。 当記事で解説する Cloud Run instances 以外のリソースタイプについては、以下の記事を参照してください。 blog.g-gen.co.jp blog.g-gen.co.jp blog.g-gen.co.jp 参考 : デプロイ オプションとリソースモデル Cloud Run instances とは Cloud Run instances は、Cloud Run 上で 単一 のコンテナインスタンスを個別に作成・管理できるリソースタイプです。リクエスト量に応じて水平スケーリングする Cloud Run services とは異なり、1つのリソースにつき常に1つのインスタンスが継続的に稼働し（ シングルトン な性質）、Compute Engine のように、作成・停止・起動・削除といったライフサイクル操作を個別に行えます。いわば、 軽量なサーバーレス仮想マシン（VM） のように振る舞う実行環境です。 Cloud Run のリソースタイプとしては、Cloud Run services、Cloud Run jobs、Cloud Run worker pools に続く4番目のリソースタイプです。2026年8月現在、Cloud Run instances は Preview 公開の機能です（2026年8月25日公開）。 参考 : What is Cloud Run - Cloud Run instances ユースケース Cloud Run instances は、単一のインスタンスが長時間動き続けることを前提とするワークロードに適しています。想定されている主なユースケースは以下のとおりです。 複数ステップの実行計画を持つ長時間稼働の AI エージェントや、AI ワークフローエンジンのホスティング VPS（Virtual Private Server）に似た、常時稼働する軽量サーバーとしての利用 リモートデバッグやコード同期のための開発環境 参考 : What is Cloud Run - When to use Cloud Run instances Cloud Run instances の基本 特徴 Cloud Run services などの他の Cloud Run のリソースタイプでは、個々のコンテナインスタンスは Cloud Run が管理するスケーリングの単位であり、ユーザーが1つずつ操作する対象ではありません。これに対して、Cloud Run instances には以下の特徴があります。 特徴 説明 個別に操作できる 作成、更新、削除、起動、停止、モニタリングをインスタンス単位で実行できる 固有の URL でアクセスできる インスタンスごとに一意の URL が割り当てられ、外部から直接 HTTP リクエストを送信できる 長時間動き続けられる 数時間から数日にわたり中断なく稼働する。1〜2週間ごとの定期的なインフラストラクチャ更新の後に自動で再起動するよう構成すれば、さらに長期間実行できる 短時間で作成できる プロビジョニングから実行開始まで約20秒以内 ライフサイクルと再起動ポリシー Cloud Run インスタンスは、VM のように明示的な操作でライフサイクルの状態を遷移させて管理します。作成が完了すると RUNNING 状態で稼働を続け、停止操作で STOPPED に、復旧できない失敗が発生すると FAILED に遷移します。 Cloud Run instances のライフサイクル コンテナのプロセスが終了したときの挙動は、インスタンスごとの再起動ポリシー（ restartPolicy ）で制御します。 再起動ポリシー 挙動 on-failure （デフォルト） プロセスが非ゼロの終了コードで終了した場合や、インフラストラクチャ側の障害が発生した場合に再起動する always 終了コード 0 の正常終了を含めて、終了ステータスにかかわらず常に再起動する never 再起動しない。プロセス終了で直ちに STOPPED または FAILED 状態に遷移する 再起動ポリシーに on-failure または always を設定している場合、コンテナのプロセスが失敗すると、Cloud Run は再起動を連続で最大3回試行します。それでも失敗し続けた場合、インスタンスは FAILED 状態に遷移します。 また、複数のコンテナ（サイドカー）で構成されるインスタンスでは、いずれか1つのコンテナが失敗または終了すると、インスタンス全体が再起動の対象となります。 参考 : Cloud Run インスタンスのライフサイクル 参考 : Configure restart policy for instances 主な設定項目 Cloud Run instances では、Cloud Run services と同様の設定項目を構成できます。gcloud CLI（ gcloud beta run instances create / update コマンド）で設定できる主な項目は以下のとおりです。 設定項目 説明 フラグと設定できる値 CPU 上限 コンテナに割り当てる vCPU 数 --cpu 。 1 、 2 、 4 、 6 、 8 。マルチコンテナでは、合計で1 vCPU 以上になる範囲で個々のコンテナに1未満の小数も指定可。デフォルトは 2 メモリ上限 コンテナに割り当てるメモリ量 --memory 。 512Mi 〜 32Gi （CPU 数に応じた下限・上限あり）。デフォルトは 2Gi コンテナポート リクエストを受け付けるポート。値は環境変数 PORT にも設定される --port 。1〜65535 エントリポイント・引数 コンテナイメージのエントリポイントと引数の上書き --command 、 --args 環境変数 コンテナに設定する環境変数 --set-env-vars 、 --env-vars-file など シークレット Secret Manager のシークレットの参照 --set-secrets など ボリューム ボリュームの作成とコンテナへのマウント --add-volume 、 --add-volume-mount 。ボリュームの種類（ type キー）は cloud-storage （Cloud Storage FUSE）、 nfs 、 in-memory （メモリ上）、 ephemeral-disk （一時ディスク）の4種類 起動ヘルスチェック コンテナ起動時のヘルスチェック（startup probe）。HTTP、TCP、gRPC に対応 --startup-probe 再起動ポリシー コンテナのプロセス終了時の再起動の挙動（前述） --restart-policy 。 on-failure （デフォルト）、 always 、 never シャットダウン猶予期間 停止時の SIGTERM から SIGKILL までの猶予時間 --grace-period 。例 : 10s （ 0s で即時強制終了） サービス ID インスタンスの ID（アイデンティティ）となるサービスアカウント --service-account 。デフォルトは Compute Engine のデフォルトサービスアカウント Ingress インスタンスを呼び出せるトラフィック経路の制限 --ingress 。 all （デフォルト）、 internal 、 internal-and-cloud-load-balancing 呼び出し元の IAM チェック URL の呼び出しに IAM 認証を要求するかどうか。無効にすると未認証アクセスを許可する --[no-]invoker-iam-check 。デフォルトで有効 デフォルト URL インスタンス固有の URL（デフォルト URL）の有効 / 無効 --[no-]default-url 。デフォルトで有効 Direct VPC egress VPC ネットワークへ直接下り（外向き）トラフィックを送信する --network 、 --subnet 、 --vpc-egress 。 --vpc-egress は all-traffic または private-ranges-only （デフォルト） Cloud SQL 接続 Cloud SQL インスタンスへの接続 --set-cloudsql-instances CMEK 顧客管理の暗号鍵（CMEK）によるコンテナの暗号化 --key SSH アクセス デバッグ用の SSH シェル接続の有効 / 無効 --[no-]ssh 。デフォルトで有効 マルチコンテナ サイドカーコンテナの追加と、コンテナ間の依存関係（起動順序）の指定 --container 、 --depends-on デバッグ用途としてインスタンスのコンテナに SSH でシェル接続する機能（ gcloud beta run instances ssh コマンド）が提供されており、デフォルトで有効です（ --no-ssh フラグで無効化できます）。 なお、1つのインスタンスが同時に処理できるリクエスト数（同時実行数）は80で固定されており、構成できません。 参考 : Create and manage Cloud Run instances 参考 : gcloud beta run instances create 参考 : Configure CPU limits for instances CPU のバーストとスロットリング Cloud Run instances の CPU は、Cloud Run services のような常時割り当てではなく、ベースラインとバーストを組み合わせた共有割り当てモデルで管理されます。挙動は以下の4つの要素で構成されます。 要素 挙動 ベースライン 構成した vCPU あたり6.25%（16分の1）の CPU が常時割り当てられ、この範囲内では無期限に実行できる バースト 使用量がベースラインを下回っている間、未使用分がバースト残高として蓄積される（最大500秒分）。負荷の高い処理では、残高を消費して構成した vCPU の100%まで自動的にバーストする スロットリング 高負荷の継続でバースト残高を使い切ると、残高が再び蓄積されるまで CPU はベースラインまで制限される 残高の回復 CPU 使用量がベースラインを下回ると、バースト残高は再び蓄積される CPU を継続的に使い切るワークロードでは、この割り当てモデルを前提に処理性能を見積もってください。 参考 : Configure CPU limits for instances - CPU Burst and Throttling 注意点 Cloud Run インスタンスには永続ディスクストレージがありません。インスタンスを停止・更新すると、メモリ上のファイルや永続化していない状態は失われます。保持が必要なデータは、Cloud Storage ボリュームマウントなどを使用して外部ストレージに保存してください。 また、シングルトンで稼働するという性質上、複数インスタンスによる冗長性はありません。高可用性よりも、低コストと単一インスタンスの永続性を優先するワークロード向けの設計です。高可用性が必要な場合は、Cloud Run services の使用を検討してください。 なお、2026年8月現在、Cloud Run instances は Preview 公開のため、一般公開（GA）までに仕様が変更される可能性があります。Preview 段階の機能は SLA やテクニカルサポートの適用対象外で、原則としてテスト環境での利用が想定されているため、本番環境での利用は推奨されません。 参考 : プロダクトとサービス - プロダクトのリリース ステージ 料金 Cloud Run instances の課金は、インスタンスの稼働時間に基づき、割り当てた CPU とメモリ量に応じて従量課金されます。オプションとして、1年間または3年間の継続利用を確約することで適用される割引料金である Compute Flexible CUD （確約利用割引）も購入可能です。 2026年8月現在の東京リージョン（asia-northeast1）における、Cloud Run instances の料金単価は以下のとおりです。 Cloud Run instances の料金単価 リソース 通常料金（USD） Compute Flexible CUD 1年（USD） Compute Flexible CUD 3年（USD） CPU（vCPU 秒あたり） $0.00000027 $0.000000194 $0.000000146 メモリ（GiB 秒あたり） $0.00000193 $0.00000139 $0.000001042 参考 : Cloud Run pricing - Instances なお参考として、同じくインスタンスの稼働時間に基づいて課金される Cloud Run worker pools の料金単価表は以下のとおりです。Cloud Run instances のほうが CPU は割安（約40分の1）、メモリは割高（1.5倍程度）となっており、リソースの割り当て方法によっては安価になることがわかります。 Cloud Run worker pools の料金単価 リソース 通常料金（USD） Compute Flexible CUD 1年（USD） Compute Flexible CUD 3年（USD） CPU（vCPU 秒あたり） $0.000011244 $0.000008096 $0.000006072 メモリ（GiB 秒あたり） $0.000001235 $0.000000889 $0.000000667 他のリソースタイプ・サービスとの比較 Cloud Run のリソースタイプ間の比較 Cloud Run の4つのリソースタイプの違いは以下のとおりです。 項目 services jobs worker pools instances スケーリング 自動 / 手動 タスクの並列実行数を指定 手動のみ なし（常に1インスタンス） HTTP リクエストの処理 あり なし なし あり（任意） ゼロへのスケール あり（デフォルト） 実行完了で停止 なし なし 課金 リクエスト単位またはインスタンス単位 実行単位 インスタンス稼働時間 インスタンス稼働時間 主なユースケース Web アプリ、API バッチ処理、スケジュール実行 メッセージキューの pull 型処理 長時間稼働の AI エージェント Cloud Run services との違い HTTP リクエストを処理できるリソースタイプという点で、Cloud Run instances は Cloud Run services と共通しています。両者の主な違いは以下のとおりです。 項目 services instances インスタンス数 リクエスト量などに応じて自動で水平スケール。手動スケールも可 常に1 ゼロへのスケール あり。アイドル時はインスタンス数ゼロまで縮退できる なし。停止は手動操作 構成変更 新しいリビジョンが作成され、段階的なロールアウトやロールバック、トラフィック分割ができる インスタンスが再起動される 課金 リクエスト単位課金とインスタンス単位課金を選択できる インスタンスの稼働時間に基づく エンドポイント サービス単位の安定した HTTPS エンドポイント インスタンス単位の一意の URL 想定ワークロード Web アプリや API などのリクエスト駆動型 シングルトンで長時間稼働するワークロード Cloud Run services でも、手動スケーリングや最小インスタンス数の設定によって常駐に近い構成は実現できます。しかし services のインスタンスはあくまでスケーリングの単位であり、個々のインスタンスに URL を割り当てたり、特定のインスタンスだけを起動・停止したりすることはできません。また、アイドル状態のインスタンスは任意のタイミングでシャットダウンされる可能性があります。 1つの実行環境がメモリ上の状態を保持しながら動き続け、そのインスタンス自体を直接管理したいワークロードでは Cloud Run instances が、リクエスト量に応じたスケーラビリティや複数インスタンスによる可用性が必要なワークロードでは Cloud Run services が適しています。 スケール可能な Cloud Run services のコンテナインスタンス 個別にアクセス・管理できる Cloud Run instances のインスタンス 参考 : Cloud Run サービスでのインスタンスの自動スケーリングについて 参考 : ロールバック、段階的なロールアウト、トラフィックの移行 参考 : サービスの課金設定 Compute Engine との違い Cloud Run instances は軽量なサーバーレス VM のように振る舞うため、常時稼働するサーバーとしての用途は Compute Engine の VM と重なります。両者の主な違いは以下のとおりです。 項目 Compute Engine Cloud Run instances 実行単位 仮想マシン（ゲスト OS を含む） コンテナ インフラ・OS の管理 ゲスト OS の構成やパッチ適用はユーザーの責任 インフラ、ホスト OS、ネットワークは Cloud Run が管理 プロビジョニング マシンタイプやディスクなどを構成して VM を起動 コンテナイメージの指定のみで約20秒以内に起動 永続ディスク Persistent Disk などの永続ストレージをアタッチできる なし。データは Cloud Storage などの外部ストレージに保存 ホストのメンテナンス ライブマイグレーションにより、VM を稼働させたまま実施できる（一部の構成を除く） 1〜2週間ごとのインフラストラクチャ更新時に再起動が必要 エンドポイント 外部公開には IP アドレスやロードバランサ、証明書などを自前で構成 HTTPS の一意の URL が自動で割り当てられる OS レベルのカスタマイズや永続ディスク、任意のマシンタイプの選択が必要な場合は Compute Engine が適しています。一方、コンテナ化されたワークロードを OS の管理なしで常駐させたい場合は、Cloud Run instances によってより少ない運用負荷で同様の構成を実現できます。 参考 : メンテナンス イベント中のライブ マイグレーション プロセス Agent Runtime との違い AI エージェントのホスティングという主要ユースケースでは、 Agent Runtime （旧称 Vertex AI Agent Engine）も選択肢になります。Agent Runtime は、エージェントの実行に特化したフルマネージドの実行基盤で、セッション管理や自動スケーリングなどのエージェント向け機能が組み込まれています。両者の主な違いは以下のとおりです。 項目 Agent Runtime Cloud Run instances 位置づけ エージェントの実行に特化したフルマネージドの実行基盤 汎用のコンテナ実行環境（シングルトン） 実行モデル リクエスト駆動。負荷に応じてインスタンスが自動スケール 常に1インスタンスが継続稼働 セッション・メモリ管理 セッション機能や Memory Bank が組み込み 組み込みなし。ADK（Agent Development Kit）のセッションサービスなどで独自に永続化 デプロイ方法 Agent Platform SDK、Agents CLI、Terraform など（2026年8月現在、gcloud CLI には未対応） gcloud CLI、REST API、クライアントライブラリ 課金 確保したリソースの利用時間に基づく。アイドル時間は課金対象外 インスタンスの稼働時間に基づく Agent Runtime はリクエスト駆動で自動スケールするため、ユーザーからのリクエストに応答する一般的なエージェントのホスティングでは、セッションやメモリの管理まで含めてマネージドに任せられる Agent Runtime をまず検討するのが良いでしょう。ただし、リクエスト駆動であることから、起動中のインスタンスがない場合はコールドスタートによる応答遅延が発生します。 一方、リクエストへの応答ではなく、エージェント自身が常駐して長時間のタスクを自律的に実行し続けるバックグラウンドエージェントや、単一の実行環境がメモリ上の状態を保持し続ける構成では、Cloud Run instances が適しています。また、任意のコンテナをそのまま実行できるため、エージェントフレームワークの開発用 UI ごとホストする、エージェント以外のプロセスを同居させるといった、実行環境を自由に構成したい場合にも使用できます。 Agent Runtime の詳細は、以下の記事を参照してください。 blog.g-gen.co.jp 参考 : エージェント ランタイム 開始方法 インスタンスは gcloud beta run instances create コマンドで作成できます。なお、 gcloud beta run instances コマンド群は Google Cloud SDK 582.0.0 以降に収録されています。 # Cloud Run インスタンスを作成 $ gcloud beta run instances create my-instance \ --image us-docker.pkg.dev/cloudrun/container/hello \ --region asia-northeast1 \ --port 8080 \ --no-invoker-iam-check ----- 出力例 ----- Creating Cloud Run instance [ my-instance ] in project [< プロジェクトID >] region [ asia-northeast1 ] Creating instance... Importing container...done Provisioning resources...done Starting instance...done Done. Instance [ my-instance ] has successfully been created. SSH with: gcloud beta run instances ssh my-instance --region asia-northeast1 URL: https://my-instance- < プロジェクト番号 > .asia-northeast1.run.app 作成されたインスタンスには、 https://<インスタンス名>-<プロジェクト番号>.<リージョン>.run.app という形式の一意の URL が割り当てられます。 参考 : Quickstart: Create a Cloud Run Instance 佐々木 駿太 (記事一覧) クラウドソリューション部 クラウドエンジニアリング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 の佐々木です。当記事では、Model Armor の機密データ保護フィルタから Sensitive Data Protection のテンプレートを呼び出し、LLM へのプロンプトに含まれる個人情報を匿名化する方法を解説します。 概要 Model Armor とは Sensitive Data Protection とは 機密データ保護フィルタの構成 Basic 構成と Advanced 構成 検査テンプレートと匿名化テンプレート テンプレートの参照関係 制限事項 検出精度に関する注意事項 料金 匿名化したデータの再識別について Sensitive Data Protection 単体との違い 機能と権限の比較 Model Armor 経由で使用する利点 Sensitive Data Protection を直接呼び出す場面 当記事で扱う範囲 設定手順 事前準備 検査テンプレートの作成 匿名化テンプレートの作成 Model Armor テンプレートの作成 フィルタバージョンの指定 動作確認 sanitizeUserPrompt の実行 レスポンスの読み方 Basic 構成との比較 概要 Model Armor とは Model Armor は、LLM のプロンプトとレスポンスを検査する Google Cloud のサービスです。プロンプトインジェクションやジェイルブレイクの検出、悪意ある URL の検出、責任ある AI の安全性フィルタ、機密データの検出と匿名化といったフィルタを備えており、ステートレスなセキュリティレイヤーとして動作します。 有効化するフィルタとその設定は、 Model Armor テンプレート というリソースにまとめます。アプリケーションは、検査したいテキストをテンプレートに対して送信し、フィルタごとの検査結果を受け取ります。 Model Armor の全体像は以下の記事を参照してください。 blog.g-gen.co.jp Sensitive Data Protection とは Sensitive Data Protection （旧称 Cloud Data Loss Prevention）は、Google Cloud 内外の機密データを検出・分類・匿名化するためのフルマネージドサービスです。氏名やメールアドレスといった機密データの種類に対応する infoType 検出器で対象を特定し、マスキングや置換、トークン化などの方式で別の値に変換します。 Sensitive Data Protection による機密データの匿名化については、以下の記事で解説しています。 blog.g-gen.co.jp 機密データ保護フィルタの構成 Basic 構成と Advanced 構成 Model Armor の機密データ保護フィルタには Basic 構成 と Advanced 構成 の2つがあり、両者は排他でどちらか一方しか指定できません。Advanced 構成では Sensitive Data Protection のテンプレートをそのまま部品として使用できます。機密データの検出条件と変換方式を定義したテンプレートが、そのまま Model Armor のフィルタとして働く形です。 項目 Basic 構成 Advanced 構成 Sensitive Data Protection のテンプレート 使用しない 検査テンプレートが必須、匿名化テンプレートは任意 使用できる infoType 固定セットのみ 検査テンプレートで指定した任意の infoType カスタム infoType 使用できない 使用できる 対応する操作 検査のみ 検査と匿名化 Basic 構成で使用できる infoType は固定されています。2026年8月現在、すべてのリージョンで検査対象となるのは以下の5種類です。 クレジットカード番号 金融口座番号 Google Cloud の認証情報 Google Cloud API キー 設定ファイルやコードなどに書かれた平文のパスワード これに加えて、米国のリージョンに限り、米国社会保障番号（SSN）と米国個人納税者識別番号（ITIN）の2種類が検査対象に追加されます。東京リージョンを含む米国以外のリージョンでは前述の5種類のみが対象であり、日本の個人情報を対象とする検出器は含まれていません。氏名、メールアドレス、電話番号、マイナンバーといった日本のユースケースで想定される機密データを扱う場合、Advanced 構成が必要です。同じ日本語のテキストを Basic 構成で検査するとどうなるかは、当記事の後半で実際のレスポンスとともに示します。 参考 : プロンプトとレスポンスをサニタイズする - Sensitive Data Protection の基本構成 検査テンプレートと匿名化テンプレート Advanced 構成で指定する Sensitive Data Protection のテンプレートは、 検査テンプレート と 匿名化テンプレート の2種類です。いずれも検出条件や変換内容を再利用可能な形で保存したリソースであり、Model Armor テンプレートから参照できます。 検査テンプレートは検出設定（ InspectConfig ）を定義するテンプレートです。検出対象の infoType、検出とみなす確度の下限（ minLikelihood ）、検出した値そのものをレスポンスに含めるか（ includeQuote ）といった、何をどこまで検出するかの条件を定義します。 匿名化テンプレートは、変換設定（ DeidentifyConfig ）を定義するテンプレートです。ここでは検出された値をどの方式で別の値に置き換えるかを定義します。変換の指定方法には、テキスト中の infoType 単位で変換する infoType 変換 （ infoTypeTransformations ）と、テーブル形式のデータを列単位で変換する レコード変換 （ recordTransformations ）の2系統があります。Model Armor が扱うのは LLM のプロンプトとレスポンスのテキストであるため、使用するのは infoType 変換です。 infoType 変換では、infoType のグループごとに変換方式（ primitiveTransformation ）を1つ指定します。変換方式は2026年8月現在では12種類が提供されており、代表的なものは以下のとおりです。 変換方式 内容 replaceWithInfoTypeConfig 検出値を infoType 名に置き換える replaceConfig 検出値を指定した固定値に置き換える redactConfig 検出値を削除する characterMaskConfig 検出値の文字を指定した文字でマスクする cryptoDeterministicConfig 検出値を AES-SIV による確定的なトークンに置き換える dateShiftConfig 日付を乱数の日数分ずらす cryptoDeterministicConfig のような暗号ベースの方式は、暗号鍵を指定することで元の値へ戻せる可逆な変換です。ただし後述のとおり、Model Armor 自体は匿名化した値を元へ戻す機能を提供していません。 その他の変換方式については、以下の公式ドキュメントを参照してください。 参考 : テンプレート 参考 : 変換のリファレンス テンプレートの参照関係 Advanced 構成では、Model Armor テンプレートの filterConfig.sdpSettings.advancedConfig に、Sensitive Data Protection のテンプレートをリソース名で指定します。 { " filterConfig ": { " sdpSettings ": { " advancedConfig ": { " inspectTemplate ": " projects/<プロジェクトID>/locations/<ロケーション>/inspectTemplates/<検査テンプレートID> ", " deidentifyTemplate ": " projects/<プロジェクトID>/locations/<ロケーション>/deidentifyTemplates/<匿名化テンプレートID> " } } } } Model Armor テンプレートは検出設定を自前で持たず、Sensitive Data Protection 側のテンプレートを参照するだけの構造になっています。そのため、後から検出対象の infoType を追加したり変換方式を変更したりする場合は、Model Armor テンプレートではなく検査テンプレートと匿名化テンプレートを編集します。 匿名化を行うには、検査テンプレートと匿名化テンプレートの両方が必要です。検査テンプレートのみを指定した場合、フィルタはマッチ結果を報告するだけで匿名化は行いません。 参考 : Method: projects.locations.templates.create 参考 : REST Resource: projects.locations.templates - SdpAdvancedConfig 制限事項 機密データ保護フィルタによる匿名化を行う場合、2026年8月現在、以下の制限があります。 プロンプトに添付された PDF や DOCX などのファイルに対する匿名化は非対応。検出まではできるが匿名化はできない ストリーミングメソッドは匿名化に非対応 匿名化テンプレートに含まれるすべての infoType が、検査テンプレートにも含まれている必要がある Sensitive Data Protection のテンプレートは、Model Armor テンプレートと同一のロケーションに存在する必要がある Model Armor テンプレートのロケーションは、作成後に変更できない ストリーミングメソッドは、LLM の出力のように逐次流れてくるテキストを、全文が揃うのを待たずにチャンク単位で検査する gRPC の双方向ストリーミング API です。匿名化はテキスト全体の中で検出した値を置き換えて返す処理であるためチャンク単位の処理とは相性が悪く、非対応となっています。 また2026年8月現在、東京リージョンでは、複数言語のテキストを検査するための多言語検出（Multi-language detection）を有効化できません。有効化を試みると、以下のように対応していない旨のエラーが返ります。機密データ保護フィルタによる日本語テキストの検査自体は多言語検出を有効にしなくても動作しますが、プロンプトインジェクション検出など他のフィルタを日本語で使用する場合は、リージョンの選定時に確認が必要です。 { " error ": { " code ": 400 , " message ": " Region 'asia-northeast1' does not support the requested capabilities: 'Multi-language detection'. ", " status ": " INVALID_ARGUMENT " } } 参考 : プロンプトとレスポンスをサニタイズする 検出精度に関する注意事項 Sensitive Data Protection の組み込み infoType 検出器は、パターンマッチやチェックサム、機械学習、文脈解析などを組み合わせて機密データを検出します。ただし公式ドキュメントでは、組み込み検出器は 完全に正確な検出ができるものではなく、規制要件への準拠を保証するものでもない と明記されています。何を機密データとみなし、どう保護するかは利用者自身が判断し、設定が要件を満たすことをテストで確認することが推奨されています。 検出の確度は minLikelihood で調整します。値を高く設定すると誤検知は減りますが、その分だけ検出漏れが増えるというトレードオフがあります。また、検出器はパターンだけでなく周辺の文脈やチェックサムも評価するため、形式だけ似せたダミーデータは検出されないことがあります。動作確認では、本番で扱うデータに近い値を使用する必要があります。 参考 : 匿名化 - 組み込みの infoType 検出器 参考 : 一致の可能性 参考 : infoType と infoType 検出器 - 確実性とテスト 料金 Sensitive Data Protection は、単体で使用する場合、処理したデータ量に基づく従量課金のサービスです。一方 Model Armor は、プロンプトとレスポンスのトークン数に基づく課金です。 Model Armor の料金ページには、Model Armor 内で Sensitive Data Protection を有効にしても追加料金は発生しないと明記されています。したがって Advanced 構成で検査テンプレートや匿名化テンプレートを連携させても、課金は Model Armor のトークン課金のみで、Sensitive Data Protection 側の検査・変換の料金は別途発生しません。 参考 : Security Command Center pricing - Possible indirect charges associated with Model Armor 参考 : Sensitive Data Protection の料金 匿名化したデータの再識別について 2026年8月現在、公式ドキュメントには、Model Armor が匿名化したデータを再識別（re-identification）する機能についての記載はありません。Model Armor は匿名化した結果をレスポンスとして返すのみで、元の値へ戻す経路は提供されていません。 確定的暗号化やフォーマット保持暗号化（FPE）のような可逆な変換方式を使って LLM に渡す前に匿名化し、レスポンス受信後に元の値へ戻すというラウンドトリップを構成する場合は、Sensitive Data Protection の content.reidentify メソッドを呼び出す処理を自前で実装する必要があります。 参考 : Method: projects.locations.content.reidentify Sensitive Data Protection 単体との違い 機能と権限の比較 Sensitive Data Protection は、Model Armor を介さずアプリケーションから直接呼び出すこともできます。同じテンプレートを使っていても、Model Armor 経由と単体では、扱えるデータや権限の持ち方が異なります。 観点 Sensitive Data Protection 単体 Model Armor 経由（Advanced 構成） 呼び出すメソッド content.inspect 、 content.deidentify 、 content.reidentify sanitizeUserPrompt 、 sanitizeModelResponse 扱えるデータ テキスト、テーブル、画像、BigQuery や Cloud Storage 上のデータ プロンプトとレスポンスのテキスト 変換の指定方法 infoType 変換とレコード変換 infoType 変換 呼び出し側の権限 アプリケーション自身に DLP ユーザー（ roles/dlp.user ）が必要 アプリケーションには Model Armor の権限のみ 機密データ以外の検査 対象外 プロンプトインジェクションや悪意ある URL の検出などと同時に評価される 適用の強制 アプリケーションが呼び出さなければ適用されない サービスの統合により、アプリケーションの実装によらず適用できる 参考 : Sensitive Data Protection の概要 Model Armor 経由で使用する利点 検査テンプレートと匿名化テンプレートは Sensitive Data Protection のリソースそのものであるため、両者で共有できます。BigQuery のスキャンに使用している検査テンプレートを、そのまま Model Armor から参照するといった構成も可能です。検出ルールを一箇所で管理しながら、LLM の入出力にも同じ基準を適用できる点が、Advanced 構成の利点です。 運用面では、機密データの扱いをアプリケーションの実装から切り離せることが大きな差です。単体で使用する場合、アプリケーションが匿名化を呼び出さなければ機密データはそのまま LLM に渡ります。Model Armor では、Agent Gateway や Gemini Enterprise Agent Platform（旧称 Vertex AI）との統合により、アプリケーションの実装によらず検査を適用できます。 なお Advanced 構成では、Sensitive Data Protection の呼び出しは Model Armor のサービスエージェントが代行します。そのため、プロンプトを送信するアプリケーション側に Sensitive Data Protection の権限は不要です。別プロジェクトのテンプレートを参照する場合は、そのプロジェクトでサービスエージェントに権限を付与します。 参考 : Model Armor の統合の概要 参考 : プロンプトとレスポンスをサニタイズする - API を有効にする Sensitive Data Protection を直接呼び出す場面 一方で、Model Armor が扱えるのは LLM の入出力テキストに限られます。レコード変換やストレージ上のデータのスキャン、可逆な変換を使った再識別を含む処理は、Sensitive Data Protection を直接呼び出す構成が必要です。両者は排他ではないため、同じテンプレートを共有したうえで、用途に応じて使い分けます。 当記事で扱う範囲 当記事では、この2つのサービスの接続部分に絞って解説します。Advanced 構成の指定方法、gcloud での作成手順、そして匿名化されたテキストがどのような形で返るかを扱います。手順はすべて東京リージョン（ asia-northeast1 ）で実行します。 設定手順 事前準備 はじめに、必要な API を有効化します。 # Model Armor と Sensitive Data Protection の API を有効化 $ gcloud services enable modelarmor.googleapis.com dlp.googleapis.com --project =< プロジェクトID > 当記事の手順を実行するユーザーには、プロジェクトレベルで以下のロールが必要です。 Model Armor 管理者（ roles/modelarmor.admin ） DLP 管理者（ roles/dlp.admin ） Model Armor はリージョンエンドポイントを使用するサービスであり、公式ドキュメントでは gcloud を使用する際にエンドポイントの上書き設定が必要とされています。この設定をせずに --location で東京リージョンを指定して実行すると、以下のように権限エラーとなります。 # エンドポイント上書きなしで東京リージョンのテンプレートを一覧表示（エラーになる） $ gcloud model-armor templates list --location = asia-northeast1 --project =< プロジェクトID > ----- 出力例 ----- ERROR: ( gcloud.model-armor.templates.list ) PERMISSION_DENIED: Read access to project ' <プロジェクトID> ' was denied. This command is authenticated as < アカウント > which is the active account specified by the [ core/account ] property メッセージは権限の不足を示していますが、実際の原因は送信先のエンドポイントです。 --log-http を付けて実行すると、 --location の指定がパスには反映される一方で、ホスト名は US のままであることが確認できます。 # HTTP ログを出力して送信先ホスト名を確認 $ gcloud model-armor templates list --location = asia-northeast1 --project =< プロジェクトID > --log-http ----- 出力例 ----- uri: https://modelarmor.us.rep.googleapis.com/v1/projects/ < プロジェクトID > /locations/asia-northeast1/templates? alt =json status: 403 以下のように gcloud の設定でエンドポイントを上書きすると、東京リージョンのテンプレートを操作できます。 # Model Armor の API エンドポイントを東京リージョンに上書き $ gcloud config set api_endpoint_overrides/modelarmor https://modelarmor.asia-northeast1.rep.googleapis.com/ この設定は gcloud 全体に適用されます。他のロケーションの Model Armor テンプレートを操作する際は、 gcloud config unset api_endpoint_overrides/modelarmor で解除してください。 参考 : テンプレートの管理 - gcloud CLI を使用して API エンドポイントのオーバーライドを設定する 参考 : データ所在地とエンドポイント 検査テンプレートの作成 2026年8月現在、Sensitive Data Protection には gcloud のコマンドグループが提供されていないため、テンプレートの作成には REST API を使用します。以下の内容でリクエスト本文のファイル（ inspect-template.json ）を作成します。 { " templateId ": " jp-pii-inspect ", " inspectTemplate ": { " displayName ": " 日本の個人情報の検査 ", " description ": " 氏名、メールアドレス、電話番号、マイナンバーを検出する ", " inspectConfig ": { " infoTypes ": [ { " name ": " PERSON_NAME " } , { " name ": " EMAIL_ADDRESS " } , { " name ": " PHONE_NUMBER " } , { " name ": " JAPAN_INDIVIDUAL_NUMBER " } ] , " minLikelihood ": " POSSIBLE ", " includeQuote ": true } } } JAPAN_INDIVIDUAL_NUMBER はマイナンバー（個人番号）の検出器です。このように、Advanced 構成では日本固有の infoType を検出対象に指定できます。 テンプレートを作成します。ここで重要なのは、 エンドポイントにロケーションを含める ことです。公式ドキュメントに記載されているエンドポイントはロケーションを含まない形式であり、そのまま実行するとテンプレートは global に作成されます。 # 東京リージョンに検査テンプレートを作成 $ curl -s -X POST \ -H " Authorization: Bearer $( gcloud auth print-access-token ) " \ -H " x-goog-user-project: <プロジェクトID> " \ -H " Content-Type: application/json " \ -d @inspect-template.json \ " https://dlp.googleapis.com/v2/projects/<プロジェクトID>/locations/asia-northeast1/inspectTemplates " ----- 出力例 ----- { " name " : " projects/<プロジェクトID>/locations/asia-northeast1/inspectTemplates/jp-pii-inspect " , " displayName " : " 日本の個人情報の検査 " , " description " : " 氏名、メールアドレス、電話番号、マイナンバーを検出する " , " createTime " : " 2026-08-22T14:01:23.172799Z " , " updateTime " : " 2026-08-22T14:01:23.172799Z " , " inspectConfig " : { " infoTypes " : [ { " name " : " PERSON_NAME " } , { " name " : " EMAIL_ADDRESS " } , { " name " : " PHONE_NUMBER " } , { " name " : " JAPAN_INDIVIDUAL_NUMBER " } ] , " minLikelihood " : " POSSIBLE " , " limits " : {} , " includeQuote " : true } } レスポンスの name にロケーション（ asia-northeast1 ）が含まれていることを確認します。 作成した検査テンプレート（コンソール） 参考 : 機密データの保護の検査テンプレートの作成 匿名化テンプレートの作成 続いて匿名化テンプレートを作成します。当記事では、検出した値を infoType 名に置き換える replaceWithInfoTypeConfig を使用します。変換後のテキストを見たときに、どの位置にどの種類の機密データがあったかを読み取れるためです。 以下の内容でリクエスト本文のファイル（ deidentify-template.json ）を作成します。 { " templateId ": " jp-pii-deidentify ", " deidentifyTemplate ": { " displayName ": " 日本の個人情報の匿名化 ", " description ": " 検出値を infoType 名に置き換える ", " deidentifyConfig ": { " infoTypeTransformations ": { " transformations ": [ { " infoTypes ": [ { " name ": " PERSON_NAME " } , { " name ": " EMAIL_ADDRESS " } , { " name ": " PHONE_NUMBER " } , { " name ": " JAPAN_INDIVIDUAL_NUMBER " } ] , " primitiveTransformation ": { " replaceWithInfoTypeConfig ": {} } } ] } } } } transformations は配列であり、要素ごとに対象の infoType と変換方式の組み合わせを指定します。当記事では4つの infoType をまとめて1つの要素にしていますが、要素を分ければ、氏名は infoType 名への置換（ replaceWithInfoTypeConfig ）、メールアドレスは * によるマスキング（ characterMaskConfig ）のように、infoType ごとに異なる変換方式を使い分けることができます。 ここで指定する infoType は、検査テンプレート側にもすべて含まれている必要があります 。検査テンプレートで検出していない infoType を匿名化テンプレートに書いても、その値は変換されません。 # 東京リージョンに匿名化テンプレートを作成 $ curl -s -X POST \ -H " Authorization: Bearer $( gcloud auth print-access-token ) " \ -H " x-goog-user-project: <プロジェクトID> " \ -H " Content-Type: application/json " \ -d @deidentify-template.json \ " https://dlp.googleapis.com/v2/projects/<プロジェクトID>/locations/asia-northeast1/deidentifyTemplates " ----- 出力例 ----- { " name " : " projects/<プロジェクトID>/locations/asia-northeast1/deidentifyTemplates/jp-pii-deidentify " , " displayName " : " 日本の個人情報の匿名化 " , " description " : " 検出値を infoType 名に置き換える " , " createTime " : " 2026-08-22T14:20:22.343392Z " , " updateTime " : " 2026-08-22T14:20:22.343392Z " , " deidentifyConfig " : { " infoTypeTransformations " : { " transformations " : [ { " infoTypes " : [ { " name " : " PERSON_NAME " } , { " name " : " EMAIL_ADDRESS " } , { " name " : " PHONE_NUMBER " } , { " name " : " JAPAN_INDIVIDUAL_NUMBER " } ] , " primitiveTransformation " : { " replaceWithInfoTypeConfig " : {} } } ] } } } 作成した匿名化テンプレート（コンソール） 参考 : 機密データの保護の匿名化テンプレートの作成 Model Armor テンプレートの作成 作成した2つのテンプレートを参照する Model Armor テンプレートを、gcloud で作成します。Advanced 構成は --advanced-config-inspect-template と --advanced-config-deidentify-template の2つのフラグでそれぞれのテンプレート（検査・匿名化）を指定します。 # SDP テンプレートを参照する Advanced 構成の Model Armor テンプレートを作成 $ gcloud model-armor templates create ma-jp-pii \ --project =< プロジェクトID > \ --location = asia-northeast1 \ --advanced-config-inspect-template = projects/ < プロジェクトID > /locations/asia-northeast1/inspectTemplates/jp-pii-inspect \ --advanced-config-deidentify-template = projects/ < プロジェクトID > /locations/asia-northeast1/deidentifyTemplates/jp-pii-deidentify ----- 出力例 ----- Created template [ ma-jp-pii ] . Basic 構成を使用する場合は、代わりに --basic-config-filter-enforcement=enabled を指定します。前述のとおり両者は排他であるため、同時には指定できません。 作成されたテンプレートを確認します。 # 作成した Model Armor テンプレートの内容を表示 $ gcloud model-armor templates describe ma-jp-pii --location = asia-northeast1 --project =< プロジェクトID > ----- 出力例 ----- createTime: ' 2026-08-22T14:32:41.063443078Z ' filterConfig: sdpSettings: advancedConfig: deidentifyTemplate: projects/ < プロジェクトID > /locations/asia-northeast1/deidentifyTemplates/jp-pii-deidentify inspectTemplate: projects/ < プロジェクトID > /locations/asia-northeast1/inspectTemplates/jp-pii-inspect name: projects/ < プロジェクトID > /locations/asia-northeast1/templates/ma-jp-pii templateMetadata: dataResidencyCompliant: true updateTime: ' 2026-08-22T14:32:41.308232521Z ' 作成した Model Armor テンプレート（コンソール） Sensitive Data Protection のテンプレートが Model Armor テンプレートと異なるロケーションにある場合、テンプレートの作成時に以下のエラーとなります。 ----- 出力例 ----- ERROR: ( gcloud.model-armor.templates.create ) INVALID_ARGUMENT: Please check the SDP templates. Ensure that SDP templates are valid and present in the same location as the Model Armor templates. The format of the inspect template name should be ' projects/*/locations/*/inspectTemplates/* ' and the format of the deidentify template name should be ' projects/*/locations/*/deidentifyTemplates/* ' . メッセージはテンプレート名の書式について述べていますが、書式を projects/*/locations/*/inspectTemplates/* の形に修正しても、ロケーションが一致していなければ同じエラーが返ります。Sensitive Data Protection のテンプレートが Model Armor テンプレートと異なるロケーションにある場合は、同じロケーション（当記事では東京リージョン）に作り直してください。特に、前述のとおりロケーションを含まないエンドポイントで作成すると global に作られるため、注意が必要です。 参考 : テンプレートの作成と管理 フィルタバージョンの指定 gcloud で作成した直後の Model Armor テンプレートは、フィルタバージョン v1 で動作します。v1 は2026年9月1日に LEGACY へ移行するため、この状態でサニタイズを実行すると、レスポンスの sanitizationMetadata.filterVersionConfig に以下の警告が含まれます。 { " messageItems ": [ { " messageType ": " WARNING ", " message ": " WARNING: This filter version (V1) is in STABLE status and will be moved to LEGACY on 09-01-2026. Please migrate your template to the STABLE or LATEST version to ensure continued protection. " } ] } フィルタバージョンは templateMetadata.filterVersionSelector で指定しますが、2026年8月現在、 gcloud model-armor templates create には対応するフラグがありません（ gcloud beta model-armor も同様）。明示的に設定するには、REST API の PATCH、Google Cloud コンソール、Terraform のいずれかを使用します。当記事では、動作確認に進む前に REST API で FILTER_VERSION_ALIAS_LATEST を指定し、2026年8月現在の最新である v3 に切り替えます。 # フィルタバージョンを最新（LATEST）に設定 $ curl -s -X PATCH \ -H " Authorization: Bearer $( gcloud auth print-access-token ) " \ -H " x-goog-user-project: <プロジェクトID> " \ -H " Content-Type: application/json " \ -d ' {"templateMetadata": {"filterVersionSelector": {"alias": "FILTER_VERSION_ALIAS_LATEST"}}} ' \ " https://modelarmor.asia-northeast1.rep.googleapis.com/v1/projects/<プロジェクトID>/locations/asia-northeast1/templates/ma-jp-pii?updateMask=templateMetadata " LATEST エイリアスは、新しいフィルタバージョンがリリースされると自動で追従します。本番環境で挙動を固定したい場合は、 alias に FILTER_VERSION_ALIAS_STABLE を指定するか、 version で特定のバージョンにピン留めすることを検討してください。 Model Armor テンプレートのバージョンが「最新」になっている 動作確認 sanitizeUserPrompt の実行 作成した Model Armor テンプレートに対して、 sanitizeUserPrompt メソッドでプロンプトを検査します。以下の内容でリクエスト本文のファイル（ prompt.json ）を作成します。 { " userPromptData ": { " text ": " 山田太郎さんの連絡先は taro@example.com、電話番号は 090-1234-5678 です。マイナンバーは 123456789018 です。 " } } テキスト中のマイナンバーは、チェックディジットが有効な架空の値です。 JAPAN_INDIVIDUAL_NUMBER 検出器はチェックディジットを検証するため、桁数を合わせただけの値では検出されません。動作を試す際は注意してください。 # Advanced 構成のテンプレートでユーザープロンプトをサニタイズ $ curl -s -X POST \ -H " Authorization: Bearer $( gcloud auth print-access-token ) " \ -H " x-goog-user-project: <プロジェクトID> " \ -H " Content-Type: application/json " \ -d @prompt.json \ " https://modelarmor.asia-northeast1.rep.googleapis.com/v1/projects/<プロジェクトID>/locations/asia-northeast1/templates/ma-jp-pii:sanitizeUserPrompt " ----- 出力例 ----- { " sanitizationResult " : { " filterMatchState " : " MATCH_FOUND " , " filterResults " : { " sdp " : { " sdpFilterResult " : { " deidentifyResult " : { " executionState " : " EXECUTION_SUCCESS " , " matchState " : " MATCH_FOUND " , " data " : { " text " : " [PERSON_NAME]の連絡先は [EMAIL_ADDRESS]、電話番号は [PHONE_NUMBER] です。マイナンバーは [JAPAN_INDIVIDUAL_NUMBER] です。 " } , " transformedBytes " : " 59 " , " infoTypes " : [ " EMAIL_ADDRESS " , " JAPAN_INDIVIDUAL_NUMBER " , " PERSON_NAME " , " PHONE_NUMBER " ] } } } } , " sanitizationMetadata " : { " filterVersionConfig " : { " filterVersion " : " v3 " , " filterVersionAlias " : " FILTER_VERSION_ALIAS_LATEST " , " releaseDate " : { " year " : 2026 , " month " : 5 , " day " : 25 } , " projectedDeprecationDate " : {} , " messageItems " : [ { " messageType " : " INFO " , " message " : " NOTE: This filter version (V3) is in LATEST status and will be moved to STABLE on 09-01-2026. " } ] } } , " invocationResult " : " SUCCESS " } } レスポンスの読み方 レスポンスの要点を上から順に見ていきます。サニタイズの結果を示す部分だけを以下に抜粋しています。 { " sanitizationResult ": { " filterMatchState ": " MATCH_FOUND ", " filterResults ": { " sdp ": { " sdpFilterResult ": { " deidentifyResult ": { " executionState ": " EXECUTION_SUCCESS ", " matchState ": " MATCH_FOUND ", " data ": { " text ": " [PERSON_NAME]の連絡先は [EMAIL_ADDRESS]、電話番号は [PHONE_NUMBER] です。マイナンバーは [JAPAN_INDIVIDUAL_NUMBER] です。 " } , " transformedBytes ": " 59 ", " infoTypes ": [ " EMAIL_ADDRESS ", " JAPAN_INDIVIDUAL_NUMBER ", " PERSON_NAME ", " PHONE_NUMBER " ] } } } } , // 省略 " invocationResult ": " SUCCESS " } } 最上位の filterMatchState は、テンプレートで有効にしたフィルタ全体のマッチ状態です。今回は Sensitive Data Protection フィルタのみを有効にしているため、機密データが検出されたことを MATCH_FOUND が示しています。検出されなかった場合は NO_MATCH_FOUND です。 // 検出されたフィルタ全体のマッチ状態 " filterMatchState ": " MATCH_FOUND ", フィルタごとの結果は filterResults に格納されます。Sensitive Data Protection フィルタの結果は sdp.sdpFilterResult であり、Advanced 構成で匿名化テンプレートを指定している場合は、その中の deidentifyResult に匿名化の結果が入ります。 executionState は匿名化処理自体が正常に実行されたかを、 matchState は検出の有無を示します。 executionState が EXECUTION_SUCCESS 以外の場合はテキストが匿名化されていないため、 matchState が MATCH_FOUND であっても注意が必要です。 // 匿名化処理の実行状態と検出の有無 " deidentifyResult ": { " executionState ": " EXECUTION_SUCCESS ", " matchState ": " MATCH_FOUND ", 匿名化後のテキストは data.text に格納されます。検出された4種類の値がすべて infoType 名に置き換わっており、LLM へ渡すテキストとしてはこの値を使用します。氏名の「山田太郎さん」は、敬称を含めた範囲が [PERSON_NAME] に置換されています。 replaceWithInfoTypeConfig では検出器が判定した範囲がそのまま置換対象になるため、変換後のテキストがどうなるかは実際に確認することを推奨します。 // 匿名化後のテキスト " data ": { " text ": " [PERSON_NAME]の連絡先は [EMAIL_ADDRESS]、電話番号は [PHONE_NUMBER] です。マイナンバーは [JAPAN_INDIVIDUAL_NUMBER] です。 " } , infoTypes には検出された infoType の一覧が、 transformedBytes には変換されたバイト数が入ります。 infoTypes を見れば、どの種類の機密データが含まれていたかをテキストを解析せずに判定できるため、「マイナンバーが含まれていたらリクエストを中断する」のような分岐に使用できます。 // 変換されたバイト数と、検出された infoType の一覧 " transformedBytes ": " 59 ", " infoTypes ": [ " EMAIL_ADDRESS ", " JAPAN_INDIVIDUAL_NUMBER ", " PERSON_NAME ", " PHONE_NUMBER " ] なお、当記事では動作確認のために REST API で Model Armor を直接呼び出しています。この場合、Model Armor が行うのは検査と匿名化の結果を返すところまでであり、匿名化後のテキストを LLM へ渡すのか、リクエストを中断するのかは、レスポンスを受け取ったアプリケーション側で実装する必要があります。 実際のユースケースでは、Gemini Enterprise Agent Platform や Apigee、Agent Gateway などの統合を使用することで、アプリケーション側の実装なしに、トラフィックの経路上で Model Armor による検査とブロックを行うことができます。 参考 : Model Armor の統合の概要 Basic 構成との比較 同じテキストを Basic 構成のテンプレートで検査し、結果を比較します。比較用のテンプレートを作成します。 # 比較用の Basic 構成の Model Armor テンプレートを作成 $ gcloud model-armor templates create ma-basic-compare \ --project =< プロジェクトID > \ --location = asia-northeast1 \ --basic-config-filter-enforcement = enabled ----- 出力例 ----- Created template [ ma-basic-compare ] . 先ほどと同じ prompt.json を使用して、このテンプレートに対してサニタイズを実行します。 # Basic 構成のテンプレートでユーザープロンプトをサニタイズ $ curl -s -X POST \ -H " Authorization: Bearer $( gcloud auth print-access-token ) " \ -H " x-goog-user-project: <プロジェクトID> " \ -H " Content-Type: application/json " \ -d @prompt.json \ " https://modelarmor.asia-northeast1.rep.googleapis.com/v1/projects/<プロジェクトID>/locations/asia-northeast1/templates/ma-basic-compare:sanitizeUserPrompt " ----- 出力例 ----- { " sanitizationResult " : { " filterMatchState " : " NO_MATCH_FOUND " , " filterResults " : { " sdp " : { " sdpFilterResult " : { " inspectResult " : { " executionState " : " EXECUTION_SUCCESS " , " matchState " : " NO_MATCH_FOUND " } } } } , // 省略 " invocationResult " : " SUCCESS " } } 氏名、メールアドレス、電話番号、マイナンバーのいずれも検出されず、 NO_MATCH_FOUND となりました。Basic 構成の固定 infoType に日本の個人情報を対象とする検出器が含まれていないためです。 またレスポンスに含まれるのは inspectResult のみで、 deidentifyResult 自体が返っていません。Basic 構成が検査のみをサポートし、匿名化を行わないことが、レスポンスの構造にも表れています。日本の個人情報を扱う AI アプリケーションで機密データ保護フィルタを使用する場合は、Advanced 構成を選択したうえで、検出対象の infoType を検査テンプレートで定義してください。 参考 : Model Armor の概要 - Sensitive Data Protection 佐々木 駿太 (記事一覧) クラウドソリューション部 クラウドエンジニアリング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 の移行期やシステム運用の現場で役立つ テストドメインエイリアス （ test-google-a.com ）について、その仕組みと具体的な使用方法を解説します。 概要 テストドメインエイリアスとは 仕様 ユースケース1 : 段階的なシステム移行のための二重配信 ユースケース2 : 内部解決への対策 内部解決が発生する仕組み 内部解決を解消する方法 メール転送のための受信ゲートウェイ設定 概要 テストドメインエイリアスとは テストドメインエイリアス とは、Google Workspace のプライマリドメインを登録した際に、システムによって自動的に追加されるドメインエイリアスです。 通常、プライマリドメインが example.com である場合、 example.com.test-google-a.com という形式のドメインが自動生成されます。このテストドメインエイリアスは、Google Workspace を本番稼働させる前や、他社メールシステムからの段階的な移行期におけるメールのテストや転送に使用できます。 このドメイン宛てに送信されたメールは、通常のプライマリドメイン宛てと同様に、対象ユーザーの Google Workspace メールボックスに直接配送されます。また、既存の本番環境の MX レコード（DNS 設定）を変更しなくても Google Workspace 側の受信用アドレスとして機能します。 参考 : 二重配信を使用して複数の受信トレイにメールを配信する - テスト ドメイン エイリアスについて 仕様 テストドメインエイリアスは Google Workspace の基本機能として提供されているため、追加料金は発生せず無料で使用できます。また、グループメールアドレスでも使用できます。 Google Workspace のドメイン所有権確認が完了すると、自動的に有効化されます。 注意点として、テストドメインエイリアスはプライマリドメインのユーザーにのみ割り当てられます。後から追加したセカンダリドメインやユーザーエイリアスドメインのユーザーに対しては生成されません。 参考 : テスト用メールアドレス ユースケース1 : 段階的なシステム移行のための二重配信 他社のメールサーバー（オンプレミスの Exchange や他のホスティングサービス）から Google Workspace（Gmail）へ移行する際、使用される方法が 二重配信 です。 二重配信とは、既存のメールシステムに届いたメールのコピーを Google Workspace にも転送し、双方のメールボックスに同じメールを届ける手法を指します。これにより、ユーザーは既存システムを使い続けながら Google Workspace の操作感をテストできます。 二重配信を実現するアプローチには既存システム側で設定を行うサーバーベースの転送方法があります。当記事では、安全かつ手軽に検証環境を構築できる、テストドメインエイリアスを使用した方法を解説します。 本番環境の DNS の MX レコードが、現行の（Gmail に切り替える前の）メールサーバーを指している状態で、Google Workspace のユーザー（ user@example.com ）にメールを届けるためには、現行のメールシステムの転送設定でテストドメインエイリアス（ user@example.com.test-google-a.com ）を使用します。 具体的なメールの経路は以下のとおりです。 外部の送信者が user@example.com 宛てにメールを送信する DNS の MX レコードに基づき、現行のメールサーバーがメールを受信する 現行のメールサーバー側で、受信したメールのコピーを user@example.com.test-google-a.com 宛てに自動転送する Google 側で test-google-a.com 宛てのメールを受信し、Google Workspace の user@example.com のメールボックスへ配送する 二重配信 この方法を使用することで、本番環境の DNS レコード（ example.com の MX レコード）を Google Workspace 側に切り替える前に、実際のメールフローを用いた本番さながらの受信テストができます。 参考 : 二重配信を使用して複数の受信トレイにメールを配信する - サーバーベースの転送（推奨） 参考 : 二重配信を使用して複数の受信トレイにメールを配信する - オプション 2: 既存のサーバーをプライマリ サーバーとして設定する ユースケース2 : 内部解決への対策 内部解決が発生する仕組み 本番の MX レコードを Google Workspace に向けて設定完了した後でも、自社 Web サイトのお問い合わせフォームからのメールだけが Google Workspace に届かないトラブルが発生することがあります。この現象は、Web サーバーでの 内部解決 が原因で発生します。 この現象は、一般的なレンタルサーバー（Web サーバー機能と SMTP サーバー機能が同居している環境）を使用しており、後からメール機能だけを Google Workspace に移行した場合などによく発生します。 例えば Web サーバー上にある WordPress のフォームから、自社の代表アドレス（ info@example.com ）宛てに通知を送るとします。この時、メールを送信する SMTP サーバー（Postfix など）は、「 example.com は自分が管理しているドメインだ」と設定されたままになっています。そのため、メールサーバーはわざわざインターネット上の外部 DNS に配送先（MX レコード）を問い合わせず、「自分宛てだから内部で処理しよう」と判断し、同じサーバー内の受信トレイに配送して処理を完了させてしまいます。 結果として、外部からのメールは正常に届くのに、自社の Web フォームからの通知だけが Google Workspace の info@example.com に届かないという現象が発生します。 内部解決の仕組み 内部解決を解消する方法 この内部解決問題を解消するために、テストドメインエイリアスを使用します。Web サーバーのローカル配信設定を変更できない、あるいは内部処理を維持する必要がある場合でも、テストドメインエイリアス宛ての転送設定を追加することで Google Workspace へメールを配送できます。 Web サーバー内のメール転送設定を使用して、 info@example.com 宛てのメールを info@example.com.test-google-a.com へ転送するように設定します。 test-google-a.com ドメイン宛てにメールが転送される際、インターネット上の外部 DNS を参照するため Google Workspace のメールサーバーへ配送されます。 テストドメインエイリアスを使用した場合 メール転送のための受信ゲートウェイ設定 「ユースケース」で紹介したようなテストドメインエイリアスを用いたメール転送の運用を開始するにあたり、Google Workspace 管理コンソール上で既存のメールサーバーを 受信ゲートウェイ に設定することで、大量メールをスムーズに受信でき、転送されたメールが「なりすまし（迷惑メール）」と誤判定されるのを防げます。 この設定は必須ではありませんが、推奨されます。 参考 : 受信メールのゲートウェイを設定する 中川 涼介 (記事一覧) クラウドソリューション部 クラウドサポート課 2024年11月、G-genに入社。Google Cloudを日々勉強中。 最近は怪談の動画にハマってます。

G-gen の杉村です。Gemini Enterprise のライセンスを購入すると、同数の Gemini Code Assist のライセンスが付帯するほか、Gemini Enterprise のライセンスがアサインされたユーザーは、一定量の範囲内で Antigravity を使用できるようになります。当記事ではこれらのライセンス体系と、使用するための手順について解説します。 概要 Gemini Enterprise ライセンスと付帯物 Gemini Code Assist とは Google Antigravity とは 企業向けの Antigravity 付帯ライセンスの体系 Gemini Code Assist について Antigravity クレジットについて Antigravity のクォータ Gemini Code Assist ライセンスの割り当て手順 ライセンスの割り当て Google Cloud プロジェクトの設定 ユーザー側の設定 Antigravity の使用手順 ライセンスの配布の確認 ライセンスの割り当て Google Cloud プロジェクトの設定 ユーザー側の設定 概要 Gemini Enterprise ライセンスと付帯物 Gemini Enterprise のライセンスを購入すると、 同数の Gemini Code Assist （Standard ティア） のライセンスが付帯 するほか、Gemini Enterprise のライセンスがアサインされたユーザーは、 一定量の Google Antigravity クレジットを使用できる ようになります。 参考 : Compare editions of Gemini Enterprise Gemini Enterprise のライセンスとその付帯物について、ライセンスの体系と使用方法がやや複雑です。当記事ではライセンス体系の解説と、ライセンスを使用するための手順を解説します。 ライセンス体系の模式図 なお Gemini Enterprise の正式名称は Gemini Enterprise app ですが、2026年8月現在、公式ガイドをはじめほとんどのドキュメントで引き続き Gemini Enterprise と呼称されていますので、当記事でも Gemini Enterprise app を指して Gemini Enterprise と呼称します。 Gemini Enterprise の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp Gemini Code Assist とは Gemini Code Assist は、Google が提供するコーディング補助およびコーディングエージェントのためのツールおよびライセンスです。VS Code や JetBrains、Cloud Shell Editor、Cloud Workstations 等の開発環境で使用できます。 これらの開発環境で Gemini Code Assist を有効化すると、入力中のコード補完や、画面内チャットとの対話を通じたコード編集や解析、MCP と連携したエージェント機能などが使用できます。 参考 : Gemini Code Assist Standard and Enterprise overview Gemini Code Assist には Standard と Enterprise の2つのティアがあり、Gemini Enterprise サブスクリプションにはこのうち Standard ティアのライセンスが付帯しています。 Google Antigravity とは Google Antigravity とは、Google が提供する、AI ネイティブな開発を行うための AI エージェントツール群です。デスクトップアプリとして提供される AI エージェントオーケストレーションツールである Antigravity 2.0 や、VS Code ベースの IDE である Antigravity IDE、また CLI ツールである Antigravity CLI などから構成される製品群です。 参考 : Google Antigravity Google Antigravity については、以下の関連記事一覧も参照してください。 blog.g-gen.co.jp 企業向けの Antigravity Antigravity は、Google AI Pro や Google AI Ultra といった個人向けサブスクリプションプランを契約すると、サブスクリプションベースで使用できます。また企業向けには、Google Cloud プロジェクトを指定して、Gemini Enterprise Agent Platform（旧称 Vertex AI。以下、 Agent Platform ）の API 経由で LLM を呼び出す設定にすると、従量課金で使用できます。 企業のユーザーの場合は、原則的にこの Google Cloud プロジェクトを指定した従量課金方式を用います。つまり、企業が Antigravity を使用するにあたって Gemini Enterprise のサブスクリプションは必須ではありません（Google Cloud プロジェクトは必須です）。しかし、Gemini Enterprise のサブスクリプションを購入してユーザーにライセンスをアサインすることで、後述のとおりのクレジットが適用され、一定量の範囲内であればサブスクリプション形式で Antigravity を使用できます。 Antigravity の料金ページで Organization plan via Google Cloud と表記されているプランは、上記の両方（Agent Platform 経由および Gemini Enterprise ライセンス経由）を指していると考えられます。 参考 : Google Antigravity - Pricing さらに、Gemini Enterprise ライセンス経由で Antigravity を使用させることで、 使用状況の可視化 （アクティブユーザー数、トークン使用量など）、 各種機能の有効化・無効化 （ファイルアクセス、ブラウザアクセス、MCP サーバー等）、 ロギングの有効化・無効化 （プロンプトと回答のロギング、メタデータのロギング等）、 使用可能なモデルの限定 （高価なモデルを制限する等）など、さまざまな管理機能が使用できます。 Gemini Enterprise に付属しているこれら一連の企業向け Antigravity 管理機能は、 AI デベロッパーツール と呼ばれています。 つまり、企業の開発者向けには、Gemini Enterprise ライセンスを配布しなくても Agent Platform 経由で Antigravity を使用できますが、 統制下で開発者に Antigravity を使用させたい 場合は、上記のような追加の統制機能が適用できるため、Gemini Enterprise ライセンスを配布することが有用です。 参考 : AI developer tools overview 付帯ライセンスの体系 ライセンス体系の模式図（再掲） Gemini Code Assist について Gemini Enterprise のライセンスに付帯の Gemini Code Assist のライセンスについては、以下のような考え方で理解する必要があります。 Gemini Enterprise のライセンス（サブスクリプション）を購入すると、 同数の Gemini Code Assist Standard ライセンス が付帯する Gemini Code Assist のライセンスについては Gemini Enterprise のライセンスとは 別個 と考える。よって Gemini Code Assist ライセンスは、Gemini Enterprise ライセンスを割り当てられたユーザーとは 別のユーザーに割り当てる ことができる。また、割り当てるための 管理画面も別 である なお Gemini Code Assist のコード生成等に関するクォータ（割り当て、上限）については、以下のドキュメントを参照してください。 参考 : Quotas and limits Gemini Enterprise のサブスクリプションを購入すると、自動的に Gemini Code Assist のライセンスが追加されます。Gemini Code Assist のライセンスの購入作業を行う必要はありません。誤って購入すると、余分に課金が発生することになりますので、注意が必要です。 Antigravity クレジットについて Gemini Enterprise のライセンスに付帯の Antigravity クレジットについては、以下のような考え方で理解する必要があります。Antigravity クレジットは Gemini Code Assist のライセンスとは別個のものであり、独立している概念であることに注意してください。 Gemini Enterprise ライセンスを割り当てられたユーザー（Google アカウント）は、一定量の範囲で Antigravity 2.0 、 Antigravity CLI 、 Antigravity for IDEs を使用できる 使用可能なボリュームは、以下のように決まる (ライセンス数) × (1ライセンスあたりのクレジット量) がプロジェクトにプールされる (1ライセンスあたりのクレジット量) は、Gemini Enterprise Standard で $10/ユーザー/月、Plus で $15/ユーザー/月 上記のプールを、同じプロジェクトを指定して Antigravity を使用する全ユーザーが シェア する Antigravity のクォータ 前述のとおり、Antigravity の使用ボリュームは、プロジェクトごとのプール制です。例えば、50個の Gemini Enterprise Standard ライセンスが配布されている Google Cloud プロジェクトでは、50 users × $10 = $500/月 のクレジットがプールされ、各ユーザーはこのプールをシェアして Antigravity を使用できます。 ただし注意点として、プールの使用にあたっては、 7日間単位 で上限が適用されます。組織全体の1週間の割り当て量は、ユーザー1人あたりの月間値を4で割り、それにプロジェクトのライセンス数をかけて算出されます。各ユーザーは、この1週間あたりのプールからクレジットを消費します。使いきれなかった割り当ては翌週に繰り越されることはなく、消失します。なお1週間の起点は、プロンプトが初めて送信された時点です。 プールを超過した分については、プロジェクトで 超過料金 （Overages）が有効化されている場合は、Agent Platform（旧称 Vertex AI）API 経由で LLM（Gemini）が呼び出されるようになり、従量課金されます。超過料金を無効にしている場合、プールを使い切った時点で Antigravity が使えなくなります。 参考 : Quotas and overages - Overages 超過料金（Overages）の有効化 なお上述のクレジット量や仕様は、2026年8月現在のものです。最新情報は、以下の公式ドキュメントを参照するか、Google Cloud 販売パートナーの営業担当者、または Google の担当者、課金サポート等にお問い合わせください。 参考 : AI developer tools overview 参考 : Quotas and overages Gemini Code Assist ライセンスの割り当て手順 ライセンスの割り当て Gemini Code Assist ライセンスは、ユーザーの Google アカウントに明示的にアサインする必要があります。以下の概要に従って設定してください。 Google Cloud コンソールにサブスクリプションの管理権限を持つアカウントでログイン 「Gemini Enterprise > サブスクリプションを管理」に遷移 該当する Gemini Enterprise サブスクリプションをクリック 画面上部「Gemini Code Assist ライセンスを管理」をクリック ライセンスの自動割り当てまたは、明示的な割り当てを行う 4. 画面上部「Gemini Code Assist ライセンスを管理」をクリック 5. ライセンスの自動割り当てまたは、明示的な割り当てを行う 上記のうち、手順 5. についての詳細は、以下のドキュメントの見出し Automatically assign Gemini Code Assist Standard and Enterprise licenses または見出し Manually assign Gemini Code Assist Standard and Enterprise licenses to individual users が参考になります。 参考 : Manage Gemini Code Assist Standard and Enterprise licenses 上記のドキュメントは Gemini Code Assist サブスクリプションをスタンドアロンで購入したときのためのものですが、基本的な手順は同じです。また前述の手順 2. 〜 4. の方法のほか、Gemini Code Assist サブスクリプションをスタンドアロンで購入したときと同様、「Gemini の管理」画面から Gemini Code Assist ライセンスの管理画面に遷移することもでき、両者が行き着く画面は同じです。 Google Cloud プロジェクトの設定 ライセンスの割り当てに加えて、以下の手順を実行します。 API の窓口とする Google Cloud プロジェクトで、 Gemini for Google Cloud API （ cloudaicompanion.googleapis.com ）が有効になっている必要があります。 さらに、ライセンスを割り当てられたユーザーの Google アカウントは、そのプロジェクトに対して以下の IAM ロールを持っている必要があります。 Gemini for Google Cloud ユーザー（ roles/cloudaicompanion.user ） Service Usage コンシューマー（ roles/serviceusage.serviceUsageConsumer ） なおこれらの手順は、スタンドアロンで Gemini Code Assist ライセンスを購入した場合と変わりありません。詳細な手順は、以下の公式ドキュメントを参照してください。 参考 : Set up Gemini Code Assist Standard and Enterprise ユーザー側の設定 ユーザー側では、IDE の Gemini Code Assist 拡張機能等の設定で、先に設定した Google Cloud プロジェクトを指定して認証します。 この手順も、スタンドアロンで Gemini Code Assist ライセンスを購入した場合と変わりありません。詳細な手順は、前述の公式ドキュメントを参照してください。 Antigravity の使用手順 ライセンスの配布の確認 まずは、Gemini Enterprise ライセンスが、API の窓口とする Google Cloud プロジェクトに適切に配布されていることを確認します。通常は Gemini Enterprise サブスクリプションを購入する際に、紐づけ先の Google Cloud プロジェクトを選択します。念のためプロジェクトを確認したり、あるいは紐づけ先のプロジェクトを変更するには、以下の手順を行います。 Google Cloud コンソールにサブスクリプションの管理権限を持つアカウントでログイン 「Gemini Enterprise > サブスクリプションを管理」に遷移 該当する Gemini Enterprise サブスクリプションをクリック 画面上部「ライセンスを配布」をクリック 対象プロジェクトの確認、対象プロジェクトの変更等を行う 5. 対象プロジェクトの確認、または対象プロジェクトを編集等する サブスクリプションの管理や配布先プロジェクトの変更の詳細については、以下のドキュメントを参照してください。 参考 : Get subscriptions and assign licenses for Gemini Enterprise - Distribute licenses ライセンスの割り当て Gemini Enterprise のライセンスに付帯の Antigravity クレジットを使用するには、対象ユーザーに Gemini Enterprise ライセンスを明示的に割り当てる必要があります。「Gemini Code Assist ライセンスを割り当てる」のではなく「Gemini Enterprise ライセンスを割り当てる」ですので、混同に注意してください。 ライセンスの割り当て手順は、以下のとおりです。 Google Cloud コンソールにサブスクリプションの管理権限を持つアカウントでログイン ライセンスが紐づいている Google Cloud プロジェクトに遷移 「Gemini Enterprise > ユーザーの管理」に遷移 ユーザーのメールアドレスに明示的にライセンスを割り当てる 4. ユーザーのメールアドレスに明示的にライセンスを割り当てる なお「ライセンスを自動的に割り当てる」を有効化したことでライセンスが割り当てられている場合でも、Antigravity は使用可能です。「ライセンスを自動的に割り当てる」が有効化されている場合、Gemini Enterprise に初めてログインした際に、自動的に空いているライセンスが割り当てられます。 参考 : Get subscriptions and assign licenses for Gemini Enterprise - Manage user licenses Google Cloud プロジェクトの設定 API の有効化 当該の Google Cloud プロジェクトでは、以下の API が有効化されている必要があります。 Gemini Enterprise API（ discoveryengine.googleapis.com ） Business AI Code API（ businessaicode.googleapis.com ） IAM ロールの設定 さらに、Antigravity を使用するユーザーの Google アカウントは、当該プロジェクトに対して、以下の IAM ロールを持っている必要があります。 Gemini Enterprise ユーザー（ roles/discoveryengine.agentspaceUser ） AI デベロッパーツールの有効化 これらに加えて、当該プロジェクトで、「AI デベロッパーツール」が有効である必要があります。デフォルトでオンになっていますが、以下の手順で確認できます。 Google Cloud コンソールに Gemini Enterprise の管理権限を持つアカウントでログイン ライセンスが紐づいている Google Cloud プロジェクトに遷移 「Gemini Enterprise > 設定」に遷移 「AI デベロッパー ツール」タブに遷移 トグルスイッチ「AI デベロッパー ツール」を有効化 5. トグルスイッチ「AI デベロッパー ツール」を有効化 手順 4. 〜 5. の画面には、その他の関連設定も存在します。以下のドキュメントを参照してください。 参考 : Configure AI developer tools settings ユーザー側の設定 ユーザー側では、Antigravity 2.0 および Antigravity CLI において、先に設定した Google Cloud プロジェクトを指定して認証します。 Google アカウントを使った認証 ではなく 、Google Cloud プロジェクトを指定した認証方法を選択するという点に注意してください。 参考 : Antigravity in Gemini Enterprise Antigravity で Google Cloud を使って認証 Antigravity CLI については、既に別の方法で認証済みの場合、 /logout コマンドを実行することで上記の認証画面に戻ることができます。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の今村です。Cloud SQL for PostgreSQL を、 インプレースアップグレード という方法でメジャーバージョンアップする手順を解説します。当記事では、バージョン17からバージョン18へのアップグレードを例とします。 概要 インプレースアップグレードについて 手順の概要 事前準備 クローンインスタンスの作成 十分なディスク容量の確認 事前チェック 概要 チェックの実行 結果の確認 エラー詳細の確認 よくある事前チェックエラーと対策 拡張機能の互換性 テンプレートデータベースの文字セット インプレースアップグレードの実行 コンソールからの実行 gcloud コマンドからの実行 アップグレードの確認 クローン環境での仕上げ作業と動作検証 システム統計情報の更新 接続テストと動作検証 本番環境での実施 切り戻し 概要 バックアップからの復元手順 概要 インプレースアップグレードについて Cloud SQL for PostgreSQL におけるメジャーバージョンアップには、従来から用いられているダンプ＆リストアによるデータ移行方式と、インプレースアップグレード方式があります。 インプレースアップグレード方式は、既存のインスタンスをそのまま新しいバージョンにアップグレードする機能です。この方式には以下のようなメリットがあります。 データのエクスポート・インポートが不要なため、作業時間を大幅に短縮できる IP アドレスが変更されないため、アプリケーション側の接続設定の変更が不要 アップグレード前に自動でバックアップが取得されるため、安全性が高い なお、Cloud SQL では PostgreSQL のほかに MySQL や SQL Server でもインプレースアップグレード機能がサポートされています。ただし、データベースエンジンごとに事前チェックのエラー内容や、アップグレード完了後の仕上げ作業の仕様が異なります。そのため、当記事では Cloud SQL for PostgreSQL に特化して手順を解説します。 Cloud SQL の概要については、以下の記事を参照してください。 blog.g-gen.co.jp 参考 : データベースのメジャー バージョンのインプレース アップグレード 手順の概要 インプレースアップグレードは非常に強力な機能ですが、本番環境でいきなり実行することは推奨されません。安全にアップグレードを完了させるため、以下のようなロードマップで作業を進めます。 本番インスタンスのクローン作成（検証環境の準備） クローン環境での事前チェックの実行 クローン環境でのアップグレード実行 クローン環境での仕上げ作業とアプリケーションの動作検証 本番環境での事前チェックとアップグレード実行 本番環境での仕上げ作業（ANALYZE）と最終動作検証 事前準備 クローンインスタンスの作成 本番稼働に影響を与えないよう、[クローンを作成] から検証用インスタンスを作成します。まずは、このクローンインスタンスを対象にすべてのアップグレード工程を検証します。 クローンを作成 ID の設定とインスタンス状態の選択 クローンの確認 アップグレードを検証 右下のオペレーションログで正常に完了したことを確認 十分なディスク容量の確認 メジャーバージョンアップを実行する前に、十分なディスク容量が確保されていることを必ず確認してください。特にストレージの自動増量機能を有効にしていない場合は、注意が必要です。 クローンインスタンスでテストアップグレードを実行する前後でストレージ容量をメモしておくことで、実際に使用されるストレージ容量を把握できます。これに基づいて、本番環境のアップグレード前に容量を拡張すべきかどうかを判断してください。 事前チェック 概要 Cloud SQL には、アップグレードが成功するかどうかを事前に検証できる事前チェック機能が備わっています。クローンインスタンスに対してこの機能を実行することで、本番稼働に影響を与えることなく、データベースの設定や拡張機能の非互換性などの問題の洗い出しができます。 事前チェックでエラーや警告が出た場合は、アップグレードが失敗する可能性が高いため、必ず原因を特定して対処する必要があります。 チェックの実行 事前チェックは gcloud コマンドで実行します。以下のコマンドを実行することで、対象のインスタンスが PostgreSQL 18にアップグレード可能かを確認できます。 INSTANCE_NAME （クローンインスタンス名）、 PROJECT_ID （プロジェクト ID）、 TARGET_DATABASE_VERSION （今回は POSTGRES_18 ）を、それぞれ置き換えて実行してください。 gcloud sql instances pre-check-major-version-upgrade INSTANCE_NAME \ --project = PROJECT_ID \ --target-database-version = TARGET_DATABASE_VERSION 参考 : データベースのメジャー バージョンをインプレースでアップグレードする - 事前チェックを実行する 結果の確認 gcloud コマンドを実行して特にエラーが出ずに完了した場合、以下のようなメッセージが表示されます。 事前チェックの結果 赤枠で囲まれている主要な文言の意味は以下のとおりです。 No issues or warnings detected during pre-check. 事前チェックにおいて、アップグレードの妨げとなるエラーや警告が検出されなかったことを意味します。このメッセージが表示された場合は、対象のインスタンスが新しいデータベースバージョンへアップグレードできる状態であると判断できます。 PreCheckResults: [ ] 検出された問題の詳細が出力されるエリアです。エラーや警告が存在しない場合は、空の配列（ [] ）として表示されます。互換性のない拡張機能などの問題がある場合は、この中に具体的なエラー要因が出力されます。 Status: COMPLETED 事前チェックのプロセスが正常に完了したことを示します。 エラー詳細の確認 コマンドの出力結果にエラーが含まれている場合は、Cloud Logging のログエクスプローラから詳細なエラー内容を確認します。 Cloud Logging の概要や仕組みについては、以下の記事を参照してください。 blog.g-gen.co.jp 参考 : データベースのメジャー バージョンをインプレースでアップグレードする - 事前チェックの結果を確認する 参考 : データベースのメジャー バージョンをインプレースでアップグレードする - メジャー バージョン アップグレードの事前チェックでよく見られるエラー 参考 : データベースのメジャー バージョンをインプレースでアップグレードする - エラーログを表示する よくある事前チェックエラーと対策 拡張機能の互換性 データベースのメジャーバージョンをアップグレードしても、機能拡張はそのまま動作するケースが多いです。 ただし一部の拡張機能は、新しい PostgreSQL バージョンと互換性のあるバージョンに事前にアップデートしておく必要があります。拡張機能のバージョンが古いと、アップグレードがブロックされる可能性があります。 参考 : データベースのメジャー バージョンをインプレースでアップグレードする - 互換性のない拡張機能 参考 : PostgreSQL の拡張機能を構成する テンプレートデータベースの文字セット template などのテンプレートデータベースの文字セットや照合順序を確認します。これらの形式が新しいバージョンでサポートされていない場合、アップグレードは失敗します。 文字セットを en_US.UTF8 に変更するなど、事前に適切な設定に変更してください。 参考 : データベースのメジャー バージョンをインプレースでアップグレードする - メジャー バージョン アップグレードを準備する インプレースアップグレードの実行 コンソールからの実行 事前チェックをクリアしたら、まずはクローンインスタンスを対象に実際のアップグレードを実行します。なお、リードレプリカが存在する場合は、プライマリインスタンスをアップグレードするとレプリカも自動的にアップグレードされます。 Google Cloud コンソールから実行する場合は、インスタンスの詳細画面から [編集] をクリックし、次の手順に従ってアップグレードを進めます。 対象のインスタンスを編集 [アップグレード] をクリック [アップグレードページに移動] をクリック アップグレードのバージョンを確認して [続行] をクリック [インスタンス ID] を入力し [アップグレードを開始] をクリック gcloud コマンドからの実行 一方で、Google Cloud コンソールではなく gcloud コマンドを使用してアップグレードする場合は、以下のコマンドを実行します。 INSTANCE_NAME （クローンインスタンス名）、 DATABASE_VERSION （今回は POSTGRES_18 ）を、それぞれ置き換えて実行してください。 gcloud sql instances patch INSTANCE_NAME \ --database-version = DATABASE_VERSION コマンドからのアップグレードに時間を要する場合、以下のようなタイムアウトのエラーが起きる場合があります。 タイムアウトの表示 この表示はアップグレードの失敗を意味するものではありません。Google Cloud 側での処理はバックグラウンドで継続していますが、手元の gcloud コマンドの待ち時間を超えたために、一旦コマンドの同期処理が終了した状態です。 アップグレードが完了したかどうかを確認するには、ログに表示されている以下のコマンドをそのまま実行します。 gcloud beta sql operations wait --project PROJECT_ID OPERATION_ID このコマンドを実行することで、再びバックグラウンドの処理を追跡できるようになります。Cloud SQL のアップグレードはデータ量によって数十分以上の時間がかかるケースもあるため、このコマンドを使用して進捗を確認します。 参考 : データベースのメジャー バージョンをインプレースでアップグレードする - 単一インスタンスのメジャー バージョンをアップグレードする アップグレードの確認 コンソールからは、インスタンスの詳細画面で確認できます。 コンソールからアップグレードを確認 コンソールに出力された前述のコマンドを実行して、コマンドベースでの確認も可能です。 コマンドでアップグレードを確認 クローン環境での仕上げ作業と動作検証 システム統計情報の更新 アップグレード完了後、必ず実行すべき作業の1つがシステム統計情報の更新です。データベースに対して ANALYZE コマンドを実行し、クエリプランナーが最適な実行計画を立てられるようにします。これを行わないと、クエリのパフォーマンスが著しく低下する可能性があります。 ANALYZE VERBOSE; システム統計情報の更新は、アプリケーションが実際に使っているデータベースに接続して、それぞれ実行する必要があります。 [Cloud SQL Studio] をクリック データベースを選択してログイン 正常に完了したことを確認 接続テストと動作検証 アップグレードプロセスでは、 アップグレード前（Pre-upgrade） のバックアップと、 アップグレード後（Post-upgrade） のバックアップが自動的に作成されます。バックアップ一覧画面から、これらのバックアップが正常に取得されていることを確認します。いつでも元に戻せる状態であることを確認した上で、アプリケーションからの接続テストや動作検証を十分に実施してください。 自動バックアップの確認 参考 : データベースのメジャー バージョンをインプレースでアップグレードする - 自動アップグレードのバックアップ 本番環境での実施 クローン環境における事前チェック、アップグレードの実行、ANALYZE、そしてアプリケーションの動作検証にいたるまですべての工程が問題なく完了したら、いよいよ本番環境での作業に移ります。 本番環境で行う手順も、ここまでクローン環境で実施してきた流れと全く同じです。メンテナンスウィンドウ（データ停止が許容される時間帯）を確保した上で、以下のステップを進めてください。 本番インスタンスに対する事前チェックの実行 本番インスタンスのインプレースアップグレードの実行 アップグレード完了後のシステム統計情報の更新（ANALYZE）の実行 アプリケーションの接続テストと最終動作検証 クローン環境で一度一連のオペレーションと挙動を確認しているため、本番環境でも焦らず安全に作業を進められます。 切り戻し 概要 本番環境のアップグレード後に重大な不具合が発生し、アプリケーションが正常に動作しない場合は、切り戻し（ロールバック）を行います。 インプレースアップグレード自体を取り消す機能はありませんが、自動作成されたアップグレード前のバックアップから旧バージョンの新規インスタンスを復元し、トラフィックを切り替えることで対応できます。 復元時に既存のインスタンスを復元先として選択することもできますが（上書き復元）、今回のようなケースでは、データの安全性を確保するため新規インスタンスへ復元することが推奨されます。 バックアップからの復元手順 バックアップ履歴の画面から、対象の アップグレード前 バックアップを選択し、[復元] をクリックします。復元先の新規インスタンス名などを指定して復元を実行し、完了後にアプリケーションの接続先を新しいインスタンスに変更します。 バックアップから [復元] を選択 復元先を選択して実行 参考 : データベースのメジャー バージョンをインプレースでアップグレードする - プライマリ インスタンスを以前のメジャー バージョンに復元する 今村 壱生 (記事一覧) クラウドソリューション部 ソリューションアーキテクト課 2026年3月にG-genへ入社。約7年間 Web 広告運用やウェブ解析に携わり、その後は社内 SE として開発業務に従事。広告運用の現場感と技術的な視点、その双方を併せ持つ経験をベースに、現在は Google Cloud のスキルアップに注力。データ活用とクラウド技術を融合させ、お客様のビジネス成長を支えるエンジニアを目指している。 Follow

G-gen の今村です。当記事では、SQL ダンプファイルを使用して Cloud SQL for PostgreSQL にデータをインポートする手順を解説します。 はじめに 概要 前提条件 事前準備 ダンプファイルの種類と特徴 ダンプファイルの確認 IAM 権限付与 SQL ダンプファイルを Cloud Storage へアップロード データベースの作成 事前の作成が必要なケース 事前の作成が不要なケース インポートの実行手順 Cloud SQL コンソールでのインポート操作 インポートパラメータの設定 パラメータの設定手順 送信先データベースの選択基準 インポート処理のステータス確認 注意点 インポート実行中のサービスへの影響 リソース不足 PostgreSQL のバージョン互換性 はじめに 概要 当記事では、Cloud SQL for PostgreSQL インスタンスに対して、環境移行やデータ復元でよく使用される SQL ダンプファイルを用いた、データのインポートの具体的な手順を解説します。 参考 : Cloud SQL の概要 Cloud SQL の基本的な概要や機能について詳しく知りたい場合は、以下の記事を参照してください。 blog.g-gen.co.jp 前提条件 当記事の手順は、インポート作業を始める前に以下の条件が揃っていることを前提としています。 Cloud SQL for PostgreSQL インスタンスが起動していること インポート対象の SQL ダンプファイルが用意されていること SQL ダンプファイルを配置するための Cloud Storage バケットが用意されていること Cloud Storage については、以下の記事を参照してください。 blog.g-gen.co.jp 事前準備 ダンプファイルの種類と特徴 エクスポートの方法によって、SQL ダンプファイルに含まれる SQL 文が異なります。 CREATE DATABASE 文が含まれているかなどを事前に確認してください。 ダンプツール・オプション 含まれるデータ CREATE DATABASE 文 Cloud SQL での事前データベース作成 pg_dump 単一データベース なし（デフォルト） 必要 pg_dump -C 単一データベース あり 不要 pg_dumpall 複数（全）データベース あり 不要 参考 : pg_dumpall - PostgreSQLのデータベースクラスタをスクリプトファイルへ抽出する 参考 : pg_dump - PostgreSQLデータベースをSQLスクリプトまたは他の形式にエクスポートする ダンプファイルの確認 複数のデータベースが含まれている想定の SQL ファイルをインポートする際は、事前にファイルをテキストエディタなどで開き、内部に \connect や CREATE DATABASE という記述が正しく存在しているかを確認することが重要です。 ファイルサイズが数 GB 以上あり、テキストエディタで内部の記述を確認できない場合は、複数データベースが混ざった1つの巨大なファイルをそのままインポートするのではなく、データベースごとにファイルを分割してインポートする手法を推奨します。 具体的なアプローチとしては、以下のような方法があります。 既に巨大な SQL ファイルが存在する場合は、 Linux の csplit コマンドなどを使用して \connect 文を基準にファイルを物理的に分割する 可能であれば運用の手順を見直し、最初から pg_dumpall ではなく、データベースごとに pg_dump -C ユーティリティを実行して個別の SQL ファイルとしてエクスポートしておく IAM 権限付与 インポート作業を実行するユーザーには、Cloud SQL 管理者（ roles/cloudsql.admin ）のロール、Cloud SQL インスタンスのサービスアカウントには、Storage オブジェクト管理者（ roles/storage.objectAdmin ）のロールが必要です。 Google Cloud における Identity and Access Management（以下、IAM）については、以下の記事を参照してください。 blog.g-gen.co.jp 参考 : SQL ダンプファイルを使用したエクスポートとインポート - Cloud SQL for PostgreSQL へのインポートに必要なロールと権限 SQL ダンプファイルを Cloud Storage へアップロード Cloud SQL へのインポートは、原則として Cloud Storage バケットを経由して行います。用意した SQL ダンプファイルを、対象のバケットにアップロードしてください。 参考 : ファイル システムからオブジェクトをアップロードする データベースの作成 事前の作成が必要なケース 一般的な pg_dump ユーティリティを使用して取得した SQL ダンプファイルをインポートする場合です。SQL ダンプファイル内に CREATE DATABASE 文が含まれていないため、インポートを実行する前に、Cloud SQL 側で移行先となる空のデータベースを事前に作成しておく必要があります。 以下は、Google Cloud コンソールでデータベースを作成する場合の手順の例です。もちろん、通常の PostgreSQL クライアントを使用しても問題ありません。 Cloud SQL インスタンスを選択 データベースを選択 データベースを作成 参考 : データベースの作成と管理 事前の作成が不要なケース pg_dumpall ユーティリティを使用するなどして、SQL ダンプファイル内に CREATE DATABASE 文や \connect 文が明示的に含まれている場合です。この場合は、インポート処理の実行プロセスの中でデータベースが自動的に作成されるため、事前に Cloud SQL 側で空のデータベースを用意しておく必要はありません。 個別のデータベースをエクスポートする pg_dump ユーティリティの場合でも、 -C データベース名 オプションを付与することで CREATE DATABASE 文が含まれます。 インポートの実行手順 Cloud SQL コンソールでのインポート操作 Google Cloud コンソールから対象の Cloud SQL インスタンスを選択し、「インポート」メニューに進みます。 Cloud SQL インスタンスを選択 インポートをクリック インポートパラメータの設定 パラメータの設定手順 ファイルの形式、ソースとなる Cloud Storage のファイルパス、およびインポート先のデータベースを選択します。 ファイル形式を選択 ソースファイルを選択 送信先データベースを選択 インポートを実行するユーザーアカウントを指定 インポートをクリック 送信先データベースの選択基準 プルダウンで指定する「送信先データベース」は、インポートする SQL ファイルに含まれるデータベースの数によって選択肢が異なります。 単一のデータベースの場合 プルダウンから対象のデータベース名を明示的に指定してインポートします。 複数のデータベースが含まれる場合（pg_dumpall など） 原則として「SQL ファイルで指定」を選択します。ファイル内の \connect 文（切り替えコマンド）が読み取られ、それぞれのデータベースへ適切に割り振られてインポートされます。 インポート処理のステータス確認 インポートを開始した後は、コンソールのオペレーションログで処理が正常に完了したかを確認してください。 オペレーションログを確認 実際にデータがインポートされたかどうかは、Cloud SQL Studio で確認できます。 Cloud SQL Studio をクリック インポートしたデータベースを確認 テーブルに対してクエリを実行するなど、実際にデータがインポートされているかを確認します。 テーブルを確認 参考 : Cloud SQL Studio を使用してデータを管理する 注意点 インポート実行中のサービスへの影響 SQL ダンプファイルのインポート処理中は、対象の Cloud SQL インスタンスの CPU や I/O（ディスク読み書き）リソースが大量に消費されます。これにより、インスタンス全体のパフォーマンスが著しく低下し、同じインスタンス上で稼働している他のアプリケーションやサービスで遅延やタイムアウトが発生する可能性があります。 また、インポートされるデータ構造によっては、テーブル全体のロックが発生し、一時的に他のクエリの書き込み・読み込みがブロックされるケースもあります。 本番環境や稼働中のサービスがあるインスタンスに対してインポートを行う場合は、利用者の少ない夜間や休日など、メンテナンスウィンドウ（サービス停止時間・ダウンタイム）を設けて実行することを強く推奨します。 影響を最小限に抑えたい場合は、検証用の別インスタンスで事前にインポート処理をテストし、完了までにどれくらいの時間がかかるか（ダウンタイムの目安）を測定しておくと安全です。 リソース不足 Cloud SQL の CPU とメモリ使用量に十分なリソースがない場合、処理に時間がかかりタイムアウトが発生する可能性があります。必要に応じてインスタンスのスペックを一時的に変更する、またはデータを分割してインポートすることを検討してください。 参考 : トラブルシューティング - インポート PostgreSQL のバージョン互換性 既存のデータベース環境からデータを移行する際、移行元と移行先の間で PostgreSQL のメジャーバージョンに不整合があると、インポートが正常に完了しないリスクがあります。 特に、以下の2つの互換性ルールに注意してください。 データベースのメジャーバージョン不整合 古いバージョンから新しいバージョン（例 : v13 から v16）へのデータ移行は下位互換性があるため、エラーなしで成功する可能性が高いといえます。逆に、新しいバージョンから古いバージョンへのインポートは、構文の違いや新機能の影響によりエラーが発生する可能性が高いといえます。 ダンプツールのバージョン不整合 SQL ダンプファイルをエクスポートした環境の pg_dump や pg_dumpall ユーティリティのバージョンは、エクスポート対象のデータベースサーバーのバージョンと同じ、またはそれよりも新しい必要があります。ツールが古い状態で出力された SQL ダンプファイルは、構造が不完全となりインポート時に予期しない不具合を引き起こす可能性があります。 バージョンの不整合による失敗を防ぐため、Cloud SQL インスタンスを作成する前に、必ず移行元のデータベースのメジャーバージョンを確認し、それと同等かそれ以降のバージョンを選択してください。 参考 : データベースのバージョンとバージョン ポリシー 今村 壱生 (記事一覧) クラウドソリューション部 ソリューションアーキテクト課 2026年3月にG-genへ入社。約7年間 Web 広告運用やウェブ解析に携わり、その後は社内 SE として開発業務に従事。広告運用の現場感と技術的な視点、その双方を併せ持つ経験をベースに、現在は Google Cloud のスキルアップに注力。データ活用とクラウド技術を融合させ、お客様のビジネス成長を支えるエンジニアを目指している。 Follow

G-gen の武井です。当記事では、Google SecOps で検知したアラートの是正対応を Playbooks で自動化する方法を解説します。 はじめに Google SecOps とは Playbooks（ハンドブック）とは 検証の流れ Cloud Audit Logs の取り込み 検知ルールの確認 インテグレーションの設定 必要なインテグレーション BigQuery Slack ケース 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 検証の流れ 当記事では BigQuery のデータセットが意図せず Public 公開されたというシナリオのもと、以下の段取りで検証を行います。 順序 設定項目 設定箇所 1 Cloud Audit Logs の取り込み Google SecOps 2 検知ルールの確認 Google SecOps 3 インテグレーションの設定 Google SecOps 4 Playbooks の設定 Google SecOps 5 動作確認 Google SecOps および BigQuery Cloud Audit Logs の取り込み Google Cloud では、Cloud Audit Logs を始めとした各種ログを、 直接取り込み という方法でリアルタイムに Google SecOps に連携できます。 方法は簡単で、Google SecOps の設定画面にて、取り込み元の組織ドメインを選択し、 Google Security Operations へのデータの送信 を有効化するだけです。 詳細は以下の公式ドキュメントを参照ください。 参考 : Ingest Google Cloud logs 検知ルールの確認 次に、今回のシナリオであるデータセットの Public 公開が起こった際に、その事象を検知できるルールがあるかを確認します。 Google SecOps には Curated Detections と呼ばれる、Google Cloud Threat Intelligence（GCTI）チームが管理する事前定義済みの検知ルールセットが多数存在するため、まずはそこから該当するルールの有無を確認します。 確認方法は SecOps 管理コンソール > Rules & Detections > Curated Detections と遷移し、該当するルールが存在すればそれを使用し、なければ YARA-L によるカスタムルールを定義します。 今回の場合、 IAM Abuse と呼ばれるルールセットの中に BigQuery Data Opened to Public というルールがあるため、こちらのルールとアラート通知を有効化します。 ルールの詳細は以下のとおりで、データセットに対し、 allUsers または allAuthenticatedUsers に IAM 権限を付与した際の操作ログを検知し、アラートとして通知する仕組みです。 rule ttp_gcp_privilege_escalation_bq_public_members_added { meta : rule_name = "BigQuery Data Opened to Public" description = "Generates a finding when allAuthenticatedUsers or allUsers is added to the IAM policy of a dataset that is owned by the organization." severity = "Medium" tactic = "TA0004" technique = "T1098" events : $e.security_result.detection_fields[ "mute" ] != "MUTED" $e.metadata.log_type = "GCP_CLOUDAUDIT" $e.metadata.product_name = "BigQuery" $e.metadata.product_event_type = "google.iam.v1.IAMPolicy.SetIamPolicy" ( $e.target.resource.attribute.labels.key = /table_change_binding_deltas_action/ or $e.target.resource.attribute.labels.key = /dataset_change_binding_deltas_action/ ) ( ( $e.target.resource.attribute.labels[ "dataset_change_binding_deltas_action" ] = "ADD" and ( $e.target.resource.attribute.labels[ "dataset_change_binding_deltas_member" ] = "allUsers" or $e.target.resource.attribute.labels[ "dataset_change_binding_deltas_member" ] = "allAuthenticatedUsers" ) ) or ( $e.target.resource.attribute.labels[ "table_change_binding_deltas_action" ] = "ADD" and ( $e.target.resource.attribute.labels[ "table_change_binding_deltas_member" ] = "allUsers" or $e.target.resource.attribute.labels[ "table_change_binding_deltas_member" ] = "allAuthenticatedUsers" ) ) ) outcome : $risk_score = 65 $vendor_name = $e.metadata.vendor_name $product_name = $e.metadata.product_name $event_count = 1 $victim_uid = $e.target.resource.product_object_id $victim_name = $e.target.resource.name $adversary_name = $e.principal.user.userid $adversary_netid = array_distinct ($e.principal.user.email_addresses) $result = array_distinct ( if ($e.security_result.action = "ALLOW" , "succeeded" , "failed" )) $result_time = min ($e.metadata.event_timestamp.seconds) $target_resource_name = array_distinct ($e.target.resource.name) $target_binding_metadata_members = arrays. concat ( array_distinct ($e.target.resource.attribute.labels[ "table_change_binding_deltas_member" ]), array_distinct ($e.target.resource.attribute.labels[ "dataset_change_binding_deltas_member" ])) $target_binding_metadata_roles = arrays. concat ( array_distinct ($e.target.resource.attribute.labels[ "table_change_binding_deltas_role" ]), array_distinct ($e.target.resource.attribute.labels[ "dataset_change_binding_deltas_role" ])) $principal_email_addresses = array_distinct ($e.principal.user.email_addresses) condition : $e } 参考 : Manage curated detections インテグレーションの設定 必要なインテグレーション 想定されるシナリオが発生した際に、Playbooks で何を処理したいのかを考え、それに該当するインテグレーション（Playbooks に組み込むアクションの実態）を用意する必要があります。 当検証では、以下の3つのアクションを Playbooks に組み込みますが、その際の基本的な考え方として、まずは事前定義済みのインテグレーションを確認し、該当するインテグレーションがなければカスタム（独自の）インテグレーションを開発します。 事前定義済みインテグレーションは SecOps 管理コンソール > Content Hub > Response Integrations から確認可能です。 # 操作対象 操作内容 1 BigQuery データセットの公開設定の是正 2 Slack SOC 担当者への通知 3 ケース ケースの Close BigQuery BigQuery に関しては、 Google BigQuery というインテグレーションが提供されているため、インストールします。 今回はその中の Run SQL Query というアクションを使って、Public 公開されたデータセットの権限を是正します。 インテグレーションの基本設定は Configure から行いますが、その際に必要なリソースは以下のとおりです。 # 設定 説明 1 サービスアカウント SecOps インスタンスがデータセットの操作時に使用 2 IAM Policy 上記サービスアカウントがデータセットの操作に必要な権限 まずは任意のサービスアカウント（今回の例では secops-soar-bq-remediator ）を作成し、データセットの操作に必要な権限を付与します。 次に、SecOps インスタンスが作成したサービスアカウントを借用するため、SecOps インスタンス（実態は SOAR サービスアカウント）に対し、添付のように「サービスアカウントトークン作成者（ roles/iam.serviceAccountTokenCreator ）」ロールを付与する必要があります。 なお今回の検証では、借用元となる SOAR サービスアカウントを SecOps 管理コンソールから確認できなかったため、以下の方法で調査しました。 インテグレーションの基本設定で、 Workload Identity Email に借用するサービスアカウントを入力する。 Test をクリックする。 エラーログが出力されるので、そのログから 借用元である SOAR サービスアカウントを確認する。 以下が実際のエラーログで、この中に借用元、借用先それぞれのサービスアカウント情報が記録されています。 Status: 2: Result Value: false Output Message: Failed to connect to the Google BigQuery server! Error is Impersonation is not allowed for the provided service account secops-soar-bq-remediator@secops-sandbox-ggen.iam.gserviceaccount.com. Please add the "Service Account Token Creator" role to the service account: soar-python@f63f7024f298ef1d1p-tp.iam.gserviceaccount.com 今回の例では SOAR サービスアカウントが soar-python@f63f7024f298ef1d1p-tp.iam.gserviceaccount.com であることがわかります。 Slack Slack に関しても、 Slack というインテグレーションが提供されているため、インストールします。 今回はその中の Send Message というアクションを使って、メッセージの送信を行います。 なお、Slack インテグレーションはボットトークン方式のため、インテグレーションの基本設定で xoxb- で始まるトークンが必須です。 そのため、Slack 側では Slack App の作成 > ボットトークンの取得 > 通知先チャンネルへのボット招待 といった流れでセットアップが必要となります。詳細は Slack の公式ドキュメントを参照してください。 参考 : Slack developer docs ケース ケース管理については Siemplify というインテグレーションが提供されています。 こちらはデフォルトでインストール済みとなっており、BigQuery や Slack のようなインテグレーションの基本設定は不要です。Playbooks から直接組み込みます。 Playbooks の設定 Playbooks の構成 ここまでで、検知ルールの有効化とインテグレーションおよび関連リソースの初期設定が整いました。最後に、これらを束ねて「検知から是正ならびに通知までを自動化する」ワークフローを Playbooks として組み立てます。 今回作成する Playbooks は、以下の流れで構成します。SecOps の管理コンソールから Response > Playbooks > + と遷移して新規 Playbooks（今回の例では BigQuery Data Opened to Public ）を作成します。 順序 要素 設定内容 1 トリガー ルール（ BigQuery Data Opened to Public ）でアラートを検知した場合に起動 2 コンディション 特定のプロジェクトで発生した事象かを判定 3 アクション① #2 が True の場合、データセットに付与された Public 公開権限を削除 4 アクション② Slack にアラート検知ならびに対応完了の旨の通知 5 アクション③ ケースのクローズ 参考 : Create your first playbook トリガー トリガー は Playbooks の起動条件です。今回は、カスタムルールが検知したアラートにのみ反応させるため、Alert Type が BigQuery Data Opened to Public である場合に設定します。これにより、このアラート以外では Playbooks が起動しません。 コンディション コンディション は Playbooks 内の条件分岐です。ある条件を満たす場合のみ後続の処理へ進み、満たさない場合は別ルート（ ELSE ）へ分岐します。 コンディションを挟んだ理由は、是正の対象を特定のプロジェクトに限定するためで、今回の例ではプロジェクト ID が miura-gws-test の場合のみ、後続のアクションへ進むよう設定します。 アクションの設定 アクション は Playbooks で実行する実際の処理です。今回はコンディションの条件を満たした場合、3 つの処理を実行します。 1つ目は、データセットに付与された Public 公開権限を削除する処理です。Actions の Google BigQuery から Run SQL Query を選択し、マウス操作でフローの中に配置します。 対象のデータセットはプレースホルダ（ Event.event_target_resource_productObjectId ）とすることで、発火したアラートから動的に判断します。 2つ目は、Slack にアラート検知と是正完了の旨を通知する処理です。先程と同じ要領で、Actions の Slack から Send Message を選択し、マウス操作でフローの中に配置します。 設定の中で、通知先チャンネル ID と任意のメッセージを入力します。 3つ目は、ケースをクローズする処理です。Actions の Siemplify から Close Case を選択し、マウス操作でフローの中に配置します。 動作確認 動作確認を行うため、指定のプロジェクト（今回の例では miura-gws-test ）の任意のデータセットで、allUsers に対し「閲覧者（ roles/viewer ）」ロールを付与します。 しばらくすると、Slack にメッセージが通知され、通知文面に埋め込まれている URL からアラートを管理するケース画面に遷移します。 Google SecOps のケース画面に遷移すると、既にケースがクローズされています。 Playbooks の起動条件を満たすアラートが検知されたため、Public 公開権限の削除、Slack 通知、ケースのクローズまで一連処理が自動的に実行され、かつ、正常終了していることがわかります。 肝心のデータセットについても、allUsers に対して付与した閲覧者ロールが削除されていることを確認しました。 Cloud Logging から確認すると、Google SecOps によって自動的に上記処理が実行された旨を示すログが記録されていました。 武井 祐介 (記事一覧) クラウドソリューション部。 Google Cloud Partner Top Engineer 2026 選出。 Follow @ggenyutakei

G-gen の今村です。当記事では、Google ドライブにおける Gemini を使用したファイル整理機能である Organize my files について解説します。 機能の概要 使用条件 言語設定の制限 管理者およびユーザー向けの設定要件 対象範囲の制限 使用可能なエディションとプラン 使用回数に関する制限 ファイル整理の手順 自動提案の確認と承認 プロンプトやメニューによる調整 機能の概要 Organize my files とは、Google ドライブ内のファイルを Gemini が分析し、適切なフォルダへの分類や整理を提案する機能です。 当機能を使用することで、手動でのフォルダ分け作業の手間を省き、ドライブ内を常に整理された状態に保てます。Gemini がマイドライブ内の未整理ファイルをスキャンし、既存のフォルダへの移動や、新しいフォルダの作成を提案します。 ただし2026年8月現在、当機能を使用するにはアカウントの言語設定を 英語（English） に設定している必要があります。 参考 : Organize my files in Drive now generally available 使用条件 言語設定の制限 Google Workspace アカウントの言語設定を 英語（English） に設定している必要があります。日本語設定ではボタンが表示されず、機能が使用できません。 参考 : Gemini にファイルを整理してもらう 管理者およびユーザー向けの設定要件 この機能を使用するには、管理者側とユーザー側の双方で以下の設定が有効になっている必要があります。 管理者側の設定 Google Workspace の管理者は、管理コンソールから「Workspace サービスでの Gemini 機能へのアクセス」を有効化する必要があります。この設定がオフの場合、ユーザーは機能を使用できません。 参考 : Workspace サービスでの Gemini 機能へのアクセスを管理する ユーザー側の設定 ユーザーは、Google Workspace でスマート機能を有効化しておく必要があります。 参考 : Google Workspace とその他の Google サービスのスマート機能と設定について 対象範囲の制限 当機能の入り口となる「Suggest file moves」ボタンは、 マイドライブ（My Drive）およびその配下のフォルダでのみ表示 されます。組織で共同使用する共有ドライブ（Shared Drives）は対象外であり、当機能は使用できません。 使用可能なエディションとプラン 当機能は、Google Workspace のアドオンである Gemini ライセンス、または Google AI プランなどを付与されたユーザーが使用できます。公式アナウンスによる対象プランは以下の通りです。 ビジネスおよびエンタープライズ向けアドオン Gemini Business Gemini Enterprise 教育向けアドオン Google AI Pro for Education その他アドオンおよび一般ユーザー向けプラン AI Expanded Access Google AI Pro Google AI Ultra 使用回数に関する制限 この機能には、ユーザーごとの使用上限（回数制限）が設定されています。 具体的な情報は、以下のドキュメントを参照してください。 参考 : Compare Google AI expansion add‑ons ファイル整理の手順 自動提案の確認と承認 Gemini がドライブ内の未整理ファイルを検知すると、画面上に自動的にファイルを整理する提案が表示されます。 Gemini によるフォルダ整理の提案画面 ユーザーが提案内容（移動対象のファイルや移行先のフォルダ案）を確認して承認することで、自動的にフォルダが作成されてファイルが移動します。これにより、マイドライブ内にある未整理のファイルが一瞬で整理されます。 Gemini がファイルを分析 移動先フォルダの提案 Move files をクリックして移動 プロンプトやメニューによる調整 Gemini が提示した最初のフォルダ整理案が最適でない場合、画面上部の Refine ボタンから提案内容を細かくカスタマイズできます。 ドロップダウンを展開すると、自由な指示をテキストで入力できるほか、定義されたプリセットメニューから整理条件を瞬時に切り替えられます。 Refine によるフォルダ移動の調整 Refine を出現させるには、Suggest file moves で移動対象のファイルが全選択された状態を解除する必要があります。 全選択を解除 Refine メニューでは、以下のような指示を選択、または入力できます。 Refine with a prompt 「Refine with a prompt」のテキストボックスに、直接プロンプトを入力して自由な整理方法を Gemini に指示します。例えば「2026年のプロジェクトごとに分けて」「作成月ごとに分けて」といった要望を入力し、指示を出します。 Refine with a prompt で指示 新しく提案されたフォルダ Move files をクリックして移動 プリセットメニューによるクイック指示 テキスト入力をしなくても、以下のメニューを選択するだけで簡単に提案の傾向を変更できます。 メニュー 内容 More new folders 新しく作成するフォルダの数を増やし、より細かく分類する Fewer new folders 新しく作成するフォルダの数を減らし、大まかにまとめる Organize by project プロジェクト単位を基準としてファイルを整理する Organize meeting notes 会議メモ（議事録等）を優先的に集約して整理する Shorten folder names 提案される新規フォルダの名前を短く簡潔な名称に変更する Try again スキャンを最初からやり直す これらの機能を活用することで、自身の好みの整理ルールに沿った理想的なマイドライブの構成を、最小限の手間で構築できます。 今村 壱生 (記事一覧) クラウドソリューション部 ソリューションアーキテクト課 2026年3月にG-genへ入社。約7年間 Web 広告運用やウェブ解析に携わり、その後は社内 SE として開発業務に従事。広告運用の現場感と技術的な視点、その双方を併せ持つ経験をベースに、現在は Google Cloud のスキルアップに注力。データ活用とクラウド技術を融合させ、お客様のビジネス成長を支えるエンジニアを目指している。 Follow

G-gen の kiharu です。当記事では、Google Cloud において VPC Flow Logs が重複して複数行、出力される事象とその原因について解説します。 事象 原因（ケース1） サブネットの VPC Flow Logs の取得方法は2種類 従来方式（サブネット単位で有効化） 新方式（Network Management API） 今回発生した事象 なぜ二重出力が発生するのか 原因（ケース2） 概要 重複出力が発生する仕組み 対処法 重複取得を確認 推奨される対応 事象 Google Cloud において、VPC Flow Logs を有効にしている VPC ネットワークのある通信（フロー）に対するログエントリが、Cloud Logging に複数行、重複して出力される事象が発生しました。 通常、VPC Flow Logs はネットワーク内のトラフィックを可視化するために使用されますが、特定の条件下では、1 つのパケット転送に対して 2 つ以上のログエントリが生成されます。これにより、Cloud Logging のログ取り込み量とストレージ使用量が意図せず増え、コスト増加を招く原因となりえます。 なおこのように VPC Flow Logs が重複して出力される原因として、複数のケースが考えられます。当記事では、ケース1とケース2として、それぞれ紹介します。 原因（ケース1） サブネットの VPC Flow Logs の取得方法は2種類 当ケースを理解するための前提知識として、2026年8月現在、サブネットの VPC Flow Logs を取得する方法には、以下の2種類があります。 Compute Engine API を使用してサブネット単位でログ取得を有効化する 従来方式 Network Management API を使用して VPC Flow Logs を構成する 新方式 どちらの方式で有効化したかによって、ログの出力のされ方が異なります。Cloud Logging でログをフィルタリングする際にも、指定すべき logName の値が異なることなどに注意が必要です。 従来方式の logName 新方式の logName projects/プロジェクトID/logs/ compute .googleapis.com%2Fvpc_flows projects/プロジェクトID/logs/ networkmanagement .googleapis.com%2Fvpc_flows 参考 : VPC Flow Logs を構成する 参考 : フローログにアクセスする 従来方式（サブネット単位で有効化） 従来からある方式では、サブネットごとに VPC Flow Logs を有効化します。ログは Compute Engine API 経由で出力されます。 サブネットの設定画面で VPC Flow Logs をオンにすることで動作します。組織ポリシー（ constraints/compute.requireVpcFlowLogs ）により、この設定を強制できます。 サブネット設定で VPC Flow Logs をオンにする設定画面 参考 : VPC Flow Logs を構成する - サブネットで VPC Flow Logs を有効にする（Compute Engine API） 新方式（Network Management API） もう1つは、VPC Flow Logs 構成機能を利用する方式です。組織、VPC、サブネットなど、スコープ単位で定義できます。 この方式では Network Management API が使用されます。従来方式とは内部 API が異なる点が重要です。 VPC Flow Logs を構成する設定画面 参考 : VPC Flow Logs を有効にする - VPC Flow Logs を有効にする 今回発生した事象 当ケースでは、VPC Flow Logs が以下のように設定されていました。 組織ポリシー（ constraints/compute.requireVpcFlowLogs ）で、各サブネットの VPC Flow Logs 有効化を強制（従来方式） 同時に、VPC Flow Logs を組織レベルで構成（新方式） その結果、同一トラフィックに対して従来方式と新方式、両方のログが出力されました。 以下の画像は、ログエクスプローラのフィルタメニュー画面です。2種類の VPC Flow Logs が出力されていることが確認できます。 ログエクスプローラのフィルタメニュー画面 参考 : VPC Flow Logs の組織のポリシーに関する制約を構成する なぜ二重出力が発生するのか 両方式は、内部的に別の仕組みで動作します。 従来方式は、Compute Engine API 由来のサブネットリソースに設定された VPC Flow Logs 有効化に基づいてログを生成します。一方、新方式は Network Management API による VPC Flow Logs 構成に基づいてログを生成します。 これらは排他的な関係ではありません。すなわち、一方を有効にしても、もう一方は自動的に無効化されません。そのため、両方を有効にすると、それぞれが独立してログを生成します。結果として、ログが二重に出力されます。 特に注意が必要なのは、前述した 組織ポリシーで従来方式を強制している場合 です。新方式へ移行したつもりでも、サブネット作成時に VPC Flow Logs 有効化を強制されるため、二重取得が発生してしまいます。 ログの二重出力イメージ図 原因（ケース2） 概要 2つ目のケースでは、VPC Flow Logs が以下のように複数の箇所で設定されていました。 VPC Flow Logs を組織レベルで構成（新方式） 同時に、VPC Flow Logs を VPC レベルで構成（新方式） 新方式（Network Management API）の VPC Flow Logs 出力方法では、VPC Flow Logs 構成ごとに個別のログセットが生成されます。その結果、同一トラフィックに対して組織レベルの構成と VPC レベルの構成、両方のログが出力されていました。 参考 : フローログにアクセスする - ログの重複 重複出力が発生する仕組み 新方式では、サポートされている構成スコープ毎に VPC Flow Logs の構成をします。 例えば、組織レベルで VPC Flow Logs を構成した場合、組織配下のすべてのサブネット、VLAN アタッチメント、Cloud VPN トンネルの VPC Flow Logs が生成されます。また、VPC レベルで VPC Flow Logs を構成した場合、その VPC 配下のすべてのサブネット、VLAN アタッチメント、Cloud VPN トンネルの VPC Flow Logs が生成されます。 VPC Flow Logs 構成スコープイメージ図 参考 : VPC フローログ - サポートされている構成 上図からもわかるように、新方式で VPC Flow Logs を複数構成した場合、複数のリソースで重複して VPC Flow Logs が生成されます。VPC Flow Logs は構成ごとに個別のログセットが生成されるため、結果として、ログが二重にも三重にも出力されます。 ログのn重出力イメージ図（新方式） 対処法 重複取得を確認 VPC Flow Logs が重複取得されているかは、Google Cloud コンソールから確認ができます。 例えばサブネットの状態を確認したい場合、「VPC ネットワーク > サブネット」の一覧で「フローログ構成」を確認し、アイコンが2つ以上表示されていると重複取得されています。 以下画像の場合は、アイコンが2つ表示されているので重複取得されている状態であることを意味します。 左側のアイコンは VPC レベルで VPC Flow Logs が構成されていることを示している（新方式） 右側のアイコンは個別のサブネット設定で VPC Flow Logs がオンにされているか、もしくはサブネットレベルで VPC Flow Logs が構成されていることを示している（従来方式もしくは新方式） サブネットのフローログ構成状況例 以下画像の場合は、表示されているアイコンは1つですが、「2」と表示されているためこちらも重複取得されている状態です。 個別のサブネット設定で VPC Flow Logs がオンにされている（旧方式） サブネットレベルで VPC Flow Logs が構成されている（新方式） サブネットのフローログ構成状況例 推奨される対応 設計の一貫性と運用性の観点から、取得方式はどちらか一方に統一します。2026年8月現在、新方式である Network Management API 方式が推奨 されています。 Network Management API または Compute Engine API を使用して、サブネットに VPC Flow Logs を有効にできます。Network Management API には VPC Flow Logs を有効にするためのオプションが多数用意されているため、Network Management API を使用することをおすすめします。 さらに、新方式の構成では VPC Flow Logs が生成されるリソースが 重複しない設計 も重要です。 参考 : サブネットの VPC Flow Logs を有効にする方法を選択する kiharu (記事一覧) クラウドソリューション部 クラウドエンジニアリング課。 2024年8月G-genにジョイン。 手芸好きなエンジニアです。Follow @kiharuco_

G-gen の佐々木です。当記事では、Agent Development Kit（ADK）で開発したエージェントを Agent2Agent（A2A）プロトコルに対応させて Cloud Run にデプロイし、 Agent Registry に登録する手順を解説します。 構成 当記事で使用するもの ADK とは A2A プロトコルとは Agent Registry とは Cloud Run とは エージェントの開発 ディレクトリ構成 uv プロジェクトの作成 agent.py Dockerfile .dockerignore ローカルでの動作確認 Google Cloud 側の準備 API の有効化 IAM ロールの付与 Cloud Run へのデプロイ デプロイ Agent Card の確認 Agent Registry への登録 Agent Card ファイルの準備 エージェントの登録 登録の確認 動作確認 構成 当記事では、ADK で開発した「サイコロを振るエージェント」を、 A2A サーバー として Cloud Run にデプロイします。その後、エージェントのメタデータを記述した Agent Card を使用して、エージェントを Agent Registry に手動登録します。登録したエージェントは、組織内の他の開発者やエージェントから発見・再利用できるようになります。 当記事の作業の流れは以下のとおりです。 ADK でエージェントを開発し、 to_a2a() 関数で A2A サーバー化する Cloud Run にデプロイし、Agent Card が公開されることを確認する Agent Card を使用してエージェントを Agent Registry に登録する 別のエージェントから A2A 経由でリモート呼び出しして動作確認する 当記事で使用するもの ADK とは ADK は、Google が開発したオープンソースのエージェント開発フレームワークです。Python、TypeScript、Go、Java に対応しており、ツール呼び出しやマルチエージェント構成、エージェントの評価・デプロイまでをカバーします。 当記事では、ADK の to_a2a() 関数を使用して、既存のエージェントを最小限のコードで A2A サーバーに変換します。 参考 : Agent Development Kit A2A プロトコルとは A2A は、エージェント間の相互運用のためのオープンプロトコルです。エージェント同士がベンダーやフレームワークの違いを越えて通信するための標準仕様であり、各エージェントは自身の名前・スキル・エンドポイント URL などのメタデータを Agent Card と呼ばれる JSON（ /.well-known/agent-card.json で公開）で表明します。 2026年7月現在、Agent Registry は A2A 仕様のバージョン0.3と1.0をサポートしています。 参考 : Agent2Agent (A2A) Protocol 参考 : AgentCard Agent Registry とは Agent Registry は、Google Cloud 上で AI エージェント、MCP サーバー、ツールを一元管理するカタログサービスです。 Gemini Enterprise Agent Platform （旧称 Vertex AI、以下 Agent Platform と記載）において、エージェントのガバナンスと統合インベントリを担います。エージェントを登録すると、組織内の他の開発者やオーケストレーターエージェントがそのスキルを検索・発見できるようになります。 Agent Registry では、 Agent Runtime （旧称 Agent Engine、Agent Platform 上のマネージドランタイム）にデプロイしたエージェントは自動で登録されますが、2026年7月現在、Cloud Run にデプロイしたエージェントは自動登録の対象外のため、手動で登録を行う必要があります。 登録するエージェントの A2A 対応は必須ではなく、A2A 非対応の標準的な REST API エンドポイントなども登録できます。ただし A2A 非対応のエージェントは名前と説明を手動で指定して登録し、検索も名前・説明によるものに限られます。 一方、A2A 対応エージェントでは、Agent Card からスキルや機能のメタデータがレジストリに自動で取り込まれ、スキル単位での検索・発見が可能になります。こうした発見性の観点から、当記事ではエージェントを A2A に対応させたうえで登録します。 Agent Registry の詳細については、以下の記事もご一読ください。 blog.g-gen.co.jp Cloud Run とは Cloud Run は、コンテナを実行するフルマネージドのサーバーレスプラットフォームです。リクエスト数に応じた自動スケーリングが可能で、HTTP サーバーとして動作する A2A エージェントのホスティングに適しています。 Cloud Run の詳細については、以下の記事もご一読ください。 blog.g-gen.co.jp エージェントの開発 ディレクトリ構成 作成するプロジェクトのディレクトリ構成は以下のとおりです（ uv init が生成する README.md や .python-version などは省略）。 dice-agent/ ├── .dockerignore ├── Dockerfile # Cloud Run 用コンテナ定義 ├── agent.py # エージェント本体 ├── pyproject.toml └── uv.lock uv プロジェクトの作成 uv プロジェクトを初期化し、依存パッケージとして A2A サポートを含む ADK（ google-adk[a2a] ）と、A2A の Python SDK（ a2a-sdk[http-server] ）、ASGI サーバーの uvicorn を追加します。 # uv のセットアップ $ uv init dice-agent --python 3 . 13 $ cd dice-agent # 依存パッケージのインストール $ uv add " google-adk[a2a] " " a2a-sdk[http-server] " uvicorn # 不要な main.py の削除と、空ファイルの作成 $ rm main.py $ touch agent.py Dockerfile .dockerignore a2a-sdk 自体は google-adk[a2a] の依存として自動的にインストールされますが、2026年7月現在の組み合わせ（google-adk 2.5.0 と a2a-sdk 1.1.1）では、A2A サーバーの実行に必要な sse-starlette などが含まれず、起動時に ModuleNotFoundError が発生します。これらは a2a-sdk の http-server extra に含まれるため、 a2a-sdk[http-server] を明示的に追加します。 uv init が生成する main.py は当記事では使用しないため削除します。各ファイルの中身は以降の節で順に記述していきます。 pyproject.toml は以下のようになります。 [project] name = "dice-agent" version = "0.1.0" description = "Add your description here" readme = "README.md" requires-python = ">=3.13" dependencies = [ "a2a-sdk[http-server]>=1.1.1" , "google-adk[a2a]>=2.5.0" , "uvicorn>=0.51.0" , ] agent.py サイコロを振るツール roll_die を持つエージェントを定義し、 to_a2a() 関数で A2A サーバー（ASGI アプリケーション）に変換します。 import os import random from google.adk.a2a.utils.agent_to_a2a import to_a2a from google.adk.agents import Agent def roll_die (sides: int ) -> int : """指定された面数のサイコロを振り、出た目を返します。 Args: sides: サイコロの面数。 Returns: 出た目の整数値。 """ return random.randint( 1 , sides) root_agent = Agent( model= "gemini-2.5-flash" , name= "dice_agent" , description= "サイコロを振るエージェント。指定された面数のサイコロを振り、結果を返します。" , instruction=( "あなたはサイコロを振るエージェントです。" "サイコロを振るよう依頼されたら、必ず roll_die ツールを呼び出して結果を答えてください。" "面数の指定がない場合は 6 面のサイコロを振ってください。" ), tools=[roll_die], ) a2a_app = to_a2a(root_agent, port= int (os.environ.get( "PORT" , "8080" ))) to_a2a() は、エージェントのコードからスキルやメタデータを抽出して Agent Card を自動生成します。生成された Agent Card は、サーバー起動後に /.well-known/agent-card.json パスで公開されます。カスタムの Agent Card を使用したい場合は、 agent_card パラメータに AgentCard オブジェクトまたは JSON ファイルのパスを渡すこともできます。 参考 : Quickstart: Exposing a remote agent via A2A Dockerfile uv を使用してコンテナイメージをビルドする Dockerfile を作成します。依存パッケージを uv sync でインストールし、Cloud Run が指定するポート（環境変数 PORT ）で uvicorn を起動します。 FROM python:3.13-slim COPY --from=ghcr.io/astral-sh/uv:latest /uv /usr/local/bin/uv WORKDIR /app COPY pyproject.toml uv.lock ./ RUN uv sync --frozen --no-dev COPY . . ENV PATH= "/app/.venv/bin:$PATH" CMD [ " sh ", " -c ", " uvicorn agent:a2a_app --host 0.0.0.0 --port $PORT " ] .dockerignore .dockerignore に以下の内容を記述し、ローカルの .venv などをコンテナイメージのビルドコンテキストから除外します。 .venv __pycache__ *.pyc .git 後述のデプロイで使用する --source フラグは、カレントディレクトリ全体を Cloud Build にアップロードします。 .dockerignore で除外していない場合、 COPY . . の際にローカル環境用の .venv がコンテナ内に作成済みの .venv を上書きし、コンテナの起動に失敗するため注意してください。 ローカルでの動作確認 デプロイ前に、ローカル環境で A2A サーバーが起動することを確認します。 uv run で実行すると、プロジェクトの仮想環境が自動的に使用されます。 # ローカルで A2A サーバーを起動 $ uv run uvicorn agent:a2a_app --host localhost --port 8001 INFO: Uvicorn running on http://localhost:8001 ( Press CTRL+C to quit ) 別のターミナルから Agent Card を取得し、エージェントのメタデータが公開されていることを確認します。 # Agent Card の取得 $ curl http://localhost:8001/.well-known/agent-card.json | jq . 以下のような内容が表示されれば成功です。 { " name ": " dice_agent ", " description ": " サイコロを振るエージェント。指定された面数のサイコロを振り、結果を返します。 ", " supportedInterfaces ": [ { " url ": " http://localhost:8080 ", " protocolBinding ": " JSONRPC ", " protocolVersion ": " 1.0 " } ] , " version ": " 0.0.1 ", " capabilities ": { " streaming ": false , " pushNotifications ": false } , " defaultInputModes ": [ " text/plain " ] , " defaultOutputModes ": [ " text/plain " ] , " skills ": [ { " id ": " dice_agent ", " name ": " model ", " description ": " サイコロを振るエージェント。指定された面数のサイコロを振り、結果を返します。 あなたはサイコロを振るエージェントです。サイコロを振るよう依頼されたら、必ず roll_die ツールを呼び出して結果を答えてください。面数の指定がない場合は 6 面のサイコロを振ってください。 ", " tags ": [ " llm " ] } , { " id ": " dice_agent-roll_die ", " name ": " roll_die ", " description ": " 指定された面数のサイコロを振り、出た目を返します。 \n\n Args: \n sides: サイコロの面数。 \n\n Returns: \n 出た目の整数値。 ", " tags ": [ " llm ", " tools " ] } ] } Google Cloud 側の準備 API の有効化 デプロイ先のプロジェクトで、以下の API を有効化します。 # 当記事で使用する API の有効化 $ gcloud services enable \ run.googleapis.com \ cloudbuild.googleapis.com \ aiplatform.googleapis.com \ agentregistry.googleapis.com \ --project =< プロジェクトID > IAM ロールの付与 当記事の手順を実行するユーザーには、プロジェクトレベルで以下のロールが必要です。 ロール 用途 Cloud Run 管理者（ roles/run.admin ） Cloud Run サービスのデプロイ Cloud Run 起動元（ roles/run.invoker ） プロキシ経由でのサービスの呼び出し サービスアカウントユーザー（ roles/iam.serviceAccountUser ） ランタイムサービスアカウントの使用 Agent Registry API 編集者（ roles/agentregistry.editor ） Agent Registry への手動登録 また、Cloud Run サービスのランタイムサービスアカウントには、Gemini モデルを呼び出すための Agent Platform ユーザー（ roles/aiplatform.user ）を付与します。 参考 : エージェント レジストリを設定する Cloud Run へのデプロイ デプロイ 作成した dice-agent ディレクトリで、ソースコードから Cloud Run にデプロイします。環境変数で Agent Platform 経由の Gemini モデル使用を指定します。 # ソースコードから Cloud Run にデプロイ $ gcloud run deploy dice-agent \ --source . \ --region = asia-northeast1 \ --project =< プロジェクトID > \ --set-env-vars = GOOGLE_GENAI_USE_ENTERPRISE =True, GOOGLE_CLOUD_PROJECT = < プロジェクトID > , GOOGLE_CLOUD_LOCATION =asia-northeast1 \ --no-allow-unauthenticated --no-allow-unauthenticated で未認証アクセスを拒否し、IAM による認証を必須としています。 Agent Card の確認 デプロイしたサービスの Agent Card を取得し、A2A サーバーとして動作していることを確認します。サービスは未認証アクセスを拒否しているため、 gcloud run services proxy コマンドでプロキシを起動し、 http://localhost:8080 経由でアクセスします。 # Cloud Run サービスへのプロキシを起動 $ gcloud run services proxy dice-agent \ --project =< プロジェクトID > \ --region = asia-northeast1 別のターミナルから Agent Card を取得します。 # プロキシ経由で Agent Card を取得 $ curl http://localhost:8080/.well-known/agent-card.json | jq . このとき、レスポンスの supportedInterfaces 内の url フィールドが、以下のようにローカルアドレス（ http://localhost:8080 ）になっている点に注意してください。 " supportedInterfaces ": [ { " url ": " http://localhost:8080 ", Agent Card の url は、 agent.py で to_a2a() を呼び出した際の host パラメータ（デフォルトは localhost ）と port パラメータから、 http://<host>:<port> の形式で組み立てられます。デプロイ先の Cloud Run サービス URL が自動的に反映されるわけではないため、Cloud Run 上で動作しているエージェントでも、Agent Card にはローカルアドレスが設定されたままになります。この url は A2A クライアントがエージェントに接続する際の宛先となるため、Agent Registry への登録前に実際のサービス URL へ書き換えます。 Agent Registry への登録 Agent Card ファイルの準備 プロキシ経由で Cloud Run 上のエージェントから Agent Card をダウンロードし、 supportedInterfaces 内の url フィールドを実際のサービス URL に書き換えます。 # Agent Card のダウンロード $ curl -o agent-card.json http://localhost:8080/.well-known/agent-card.json # サービス URL をシェル変数に取得 $ SERVICE_URL = $( gcloud run services describe dice-agent \ --project =< プロジェクトID > \ --region = asia-northeast1 \ --format =' value(status.url) ' ) # Agent Card の url フィールドをサービス URL に書き換え $ sed -i '' ' s|"url":"[^"]*"|"url":" '" $SERVICE_URL "' "| ' agent-card.json Agent Card ファイルのサイズ上限は 10 KB です。エージェントの instruction はスキルの説明として Agent Card に含まれるため、長大な instruction を持つエージェントでは上限に注意してください。 エージェントの登録 gcloud agent-registry services create コマンドで、A2A 準拠エージェントとして登録します。手動登録では、Agent Registry の Service リソースを作成すると、レジストリが検索用の読み取り専用 Agent リソースを自動生成します。A2A 準拠エージェントの場合、 --agent-spec-content で渡した Agent Card からスキルが自動抽出されてレジストリに反映されます。 # A2A 準拠エージェントとして登録 $ gcloud agent-registry services create dice-agent \ --project =< プロジェクトID > \ --location = asia-northeast1 \ --display-name =" Dice Agent " \ --agent-spec-type = a2a-agent-card \ --agent-spec-content = agent-card.json なお、2026年7月現在、マルチリージョン（ us 、 eu ）では手動登録がサポートされていません。リージョン（ asia-northeast1 など）または global ロケーションを使用してください。 参考 : 手動登録を使用する 登録の確認 登録されたエージェントを一覧表示して確認します。 # 登録されたエージェントの一覧表示 $ gcloud agent-registry agents list \ --project =< プロジェクトID > \ --location = asia-northeast1 表示名でフィルタして特定のエージェントのみを確認することもできます。自動生成された Agent リソースの表示名には、Agent Card の name （ dice_agent ）が設定されています。 # 表示名でフィルタして表示 $ gcloud agent-registry agents list \ --project =< プロジェクトID > \ --location = asia-northeast1 \ --filter =" displayName='dice_agent' " --- agentId: urn:agent:projects- < プロジェクト番号 > :projects: < プロジェクト番号 > :locations:asia-northeast1:agentregistry:services:dice-agent card: content: （中略） type: A2A_AGENT_CARD createTime: ' 2026-07-17T14:39:35.352516Z ' description: サイコロを振るエージェント。指定された面数のサイコロを振り、結果を返します。 displayName: dice_agent location: asia-northeast1 name: projects/ < プロジェクトID > /locations/asia-northeast1/agents/agentregistry-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx protocols: - interfaces: - protocolBinding: JSONRPC url: https://dice-agent-xxxxxxxxxx-an.a.run.app protocolVersion: ' 1.0 ' type: A2A_AGENT skills: - description: （中略） id: dice_agent name: model tags: - llm - description: （中略） id: dice_agent-roll_die name: roll_die tags: - llm - tools uid: agentregistry-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx updateTime: ' 2026-07-17T14:39:35.352516Z ' version: 0 . 0 . 1 登録した Agent Card の内容が card に保持され、スキルが skills フィールドに抽出されていることが確認できます。 登録したエージェントの情報は、コンソールからも確認できます。 Agent Registry に登録したエージェントの情報を確認できる（コンソール） 参考 : エージェントを登録する 動作確認 最後に、Cloud Run 上のエージェントを別のエージェントから A2A 経由で呼び出して動作確認します。 なお、A2A の呼び出し自体は Agent Registry を経由せず、エージェントのエンドポイントへの直接通信で行われます。Agent Registry は接続先のエージェントを発見するためのカタログであり、実運用では「レジストリでエージェントを検索・発見し、得られた Agent Card の情報で接続する」という流れになります。当記事では接続先が既知のため、Cloud Run サービスから直接 Agent Card を取得します。 Cloud Run サービスは認証必須のため、プロキシを起動した状態で作業します。 # Cloud Run サービスへのプロキシを起動 $ gcloud run services proxy dice-agent \ --project =< プロジェクトID > \ --region = asia-northeast1 ローカル環境に以下の構成でコンシューマー側エージェントを作成します。ディレクトリは後述の adk web コマンドが Python のパッケージとしてインポートするため、ディレクトリ名にはハイフン（ client-agent ）ではなくアンダースコア（ client_agent ）を使用します。 client_agent/ ├── __init__.py # from . import agent と記載 └── agent.py agent.py の内容は以下のとおりです。ADK の RemoteA2aAgent クラスに Agent Card の URL を渡すと、リモートエージェント（ここでは Cloud Run 上の dice_agent ）をサブエージェントとして組み込めます。 from google.adk.agents import Agent from google.adk.agents.remote_a2a_agent import ( AGENT_CARD_WELL_KNOWN_PATH, RemoteA2aAgent, ) dice_agent = RemoteA2aAgent( name= "dice_agent" , description= "サイコロを振るリモートエージェント。" , agent_card=f "http://localhost:8080{AGENT_CARD_WELL_KNOWN_PATH}" , ) root_agent = Agent( model= "gemini-2.5-flash" , name= "client_agent" , instruction= "サイコロに関する依頼は dice_agent に委任してください。" , sub_agents=[dice_agent], ) AGENT_CARD_WELL_KNOWN_PATH は ADK が提供する定数で、A2A 仕様で定められた Agent Card の公開パス（ /.well-known/agent-card.json ）を表します。 agent_card にはプロキシのアドレスを指定します。サービスが公開する Agent Card 内の url （ http://localhost:8080 ）もプロキシのアドレスと一致するため、Agent Card の取得後に行われる A2A リクエストもプロキシ経由で送信されます。 client_agent の親ディレクトリで、ADK の開発用 Web UI（ adk web ）を起動します。 adk web は起動したディレクトリの配下からエージェントのパッケージを検出するため、 client_agent の中ではなく親ディレクトリで実行します。 uvx は uv に付属するコマンドで、一時的な仮想環境にパッケージをインストールしてコマンドを実行できます。 # client_agent の親ディレクトリで実行 $ uvx --from " google-adk[a2a] " adk web ブラウザで http://localhost:8000 を開き、「サイコロを振って」と入力すると、Cloud Run 上の dice_agent に処理が委任され、サイコロの結果が返ってきます。 Cloud Run 上で動作するエージェントに処理が委任されている 佐々木 駿太 (記事一覧) クラウドソリューション部 クラウドエンジニアリング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 の杉村です。当記事では、BigQuery cross-cloud connections と BigQuery Omni の違いについて解説します。いずれも Google Cloud のデータ分析用データベースである BigQuery と、Amazon S3 や Azure Blob Storage を接続するための仕組みです。 概要 BigQuery cross-cloud connections と BigQuery Omni 相違点のサマリ どちらを使うべきか 対応リージョン BigQuery cross-cloud connections BigQuery Omni 使用可能な機能 BigQuery cross-cloud connections BigQuery Omni コンピュートリソースの所在 BigQuery cross-cloud connections BigQuery Omni データセットの所在 BigQuery cross-cloud connections BigQuery Omni 料金 BigQuery cross-cloud connections BigQuery Omni 構築手順 概要 BigQuery cross-cloud connections と BigQuery Omni 当記事では、 BigQuery cross-cloud connections と BigQuery Omni の違いについて解説します。これら2つの機能は、いずれも Google Cloud のデータ分析用データベースである BigQuery と、Amazon Web Services（AWS）の Amazon S3 や、Microsoft Azure の Azure Blob Storage を接続するための仕組みですが、内部的な仕組み、パフォーマンス、料金体系などが異なります。 これらの仕組みを使うことで、BigQuery からクエリを実行してオンデマンドな分析を行ったり、INSERT 〜 SELECT によって AWS / Azure から BigQuery テーブルへデータを転送できます。 参考 : Create cross-cloud connections 参考 : Introduction to BigQuery Omni なお、BigQuery cross-cloud connections は2026年8月現在、Preview 公開であり、本番環境での使用は推奨されません。以下の記事も参考にしてください。 参考 : Preview版のサービスを使うとはどういうことなのか - G-gen Tech Blog 相違点のサマリ BigQuery cross-cloud connections と BigQuery Omni の違いをサマリすると、以下のようになります。詳細は、当記事の残りの部分で解説します。 項目 BigQuery cross-cloud connections BigQuery Omni コンピュートリソースの所在 BigQuery の標準リソース AWS/Azure リージョン内にデプロイされた専用ワーカー データ転送 AWS/Azure から Google Cloud へ生データが転送 AWS/Azure 側で処理が行われ、結果のみが Google Cloud へ返送 パフォーマンス・コスト 生データ転送により処理速度と外向き通信費用に課題が出る可能性 クラウドをまたぐ大規模転送を抑えられ、高速かつ外向き通信費用が小さい傾向 対応リージョン すべての BigQuery リージョンに対応 限定された AWS/Azure リージョンのみ対応 制限事項 通常の BigLake テーブルと同等。比較的制限が少ない BigQuery ML や一部の UDF、Azure Blob Storage のマテリアライズドビュー等が不可 料金体系 通常の BigQuery クエリ料金 + 外向き通信費用 BigQuery Omni 専用のコンピュート料金 (割高な単価) + 外向き通信費用 構築手順の違い BigQuery リージョンに接続 (Connection) を作成 BigQuery Omni 専用リージョン (aws-us-east-1 等) に接続を作成 どちらを使うべきか 前述のような相違点から、以下のいずれかに当てはまるケースでは BigQuery cross-cloud connections が適しており、それ以外のケースでは BigQuery Omni が適しているといえます。 小規模なクエリが中心で、AWS / Azure からの外向きトラフィック料金（data egress charges）を大きく気にする必要がない S3 バケット / Blob Storage コンテナが、BigQuery Omni に対応していないリージョンに配置されている 2026年8月現在、以下の日本国内リージョンは BigQuery Omni に対応していないため、BigQuery cross-cloud connections は有力な選択肢になります。 AWS 東京リージョン（ap-northeast-1） AWS 大阪リージョン（ap-northeast-3） Azure 東京リージョン（japaneast） Azure 大阪リージョン（japanwest） なお、大規模なデータ処理が必要だがデータソースが BigQuery Omni 非対応リージョンにあるといった場合は「AWS / Azure 側でデータを Omni 対応リージョンへ事前転送する」「AWS / Azure 側でデータを事前処理して小さくする」などのアーキテクチャを検討します。 対応リージョン BigQuery cross-cloud connections BigQuery cross-cloud connections は、すべての BigQuery リージョンで使用可能です。 参考 : Create cross-cloud connections - Region recommendations BigQuery Omni BigQuery Omni は以下のリージョンでしか使用できません（表は2026年8月現在のもの）。 AWS 名称 リージョン ID 米国東部（バージニア北部） us-east-1 米国西部（オレゴン州） us-west-2 アジア太平洋地域（ソウル） ap-northeast-2 アジア太平洋地域（シドニー） ap-southeast-2 ヨーロッパ（アイルランド） eu-west-1 ヨーロッパ（フランクフルト） eu-central-1 Azure 名称 リージョン ID East US 2 eastus2 参考 : Introduction to BigQuery Omni - Locations BigQuery Omni では、これらの対応リージョンに配置された S3 バケットや Blob Storage コンテナに対してのみ、クエリできます。非対応リージョンのバケット / コンテナに対しては、クエリできません。なおこれは、後述するコンピュートリソースの場所に関係しています。 前述のとおり、2026年8月現在、BigQuery Omni は東京および大阪の AWS / Azure リージョンに未対応であり、東京および大阪リージョンに配置された S3 バケットや Blob Storage コンテナにはクエリできません。 使用可能な機能 BigQuery cross-cloud connections BigQuery cross-cloud connections を使用して作成した外部テーブル（BigLake テーブル）には、通常の BigLake テーブルの制限が適用されます。 参考 : Introduction to BigLake tables - Limitations これに加えて BigQuery cross-cloud connections では、 EXPORT DATA ステートメントを使ったデータのエクスポート（ファイルへの書き出し）は使用できません。 EXPORT DATA を実行しようとすると、以下のようなエラーメッセージが表示されます。 EXPORT to AWS S3 is only supported for tables present in BigQuery Omni AWS regions. BigQuery Omni BigQuery Omni では、通常の BigLake テーブルの制限に加えて、使用可能な機能にいくつかの制限があります。以下は一部の抜粋です。 BigQuery ML は使用不可 Blob Storage の場合、マテリアライズドビューに対応していない JavaScript UDF（ユーザー定義関数）は使用不可 詳細は以下のドキュメントを参照してください。 参考 : Introduction to BigQuery Omni - Limitations なお BigQuery Omni では先述の EXPORT DATA ステートメントが使用可能であり、ファイルを S3 バケット等へ書き出すことができます。 EXPORT DATA WITH CONNECTION `aws-us-east -1 .connection- for -bigquery-omni` OPTIONS( uri= " s3://my-sample-bucket-n-virginia/* " , format= " CSV " ) AS SELECT 10002 , " mytestname2 " , " mytestvalue2 " , 9999 コンピュートリソースの所在 BigQuery cross-cloud connections BigQuery cross-cloud connections では、一度 BigQuery 上に Amazon S3 や Azure Blob Storage の生データを読み込んでから処理をします。そのため、BigQuery cross-cloud connections は、標準的な BigQuery のコンピュートリソースを使用してクエリを実行できます。 このことから、普段 BigQuery で使っているスロット予約（reservation）やコミットメントを、そのまま使用できます。 BigQuery cross-cloud connections の構成 BigQuery cross-cloud connections では、まず AWS / Azure から Google Cloud への生データの転送が発生することから、処理速度と外向きトラフィック料金が大きく発生する可能性があります。よって、処理速度とコストを最適化するには、対象の AWS / Azure リージョンから最も近い Google Cloud リージョンに、データセットを作成することが望ましいといえます。地理的に近いリージョン同士の対照表は、以下のドキュメントに記載されています。 参考 : Create cross-cloud connections - Region recommendations BigQuery Omni BigQuery Omni は、対象の AWS リージョンや Azure リージョンに、 専用のコンピュートワーカーをデプロイ して処理を行わせる仕組みです（図中の「BigQuery データプレーン」）。 クエリの処理は、AWS リージョンや Azure リージョンの中で完結します。BigQuery Omni が、サポートされているリージョンの S3 バケットまたは Blob Storage コンテナに対してしかクエリできない理由は、ここに起因しています。 参考 : Introduction to BigQuery Omni - Architecture BigQuery Omni の構成 例として BigQuery Omni における SELECT クエリは、AWS / Azure リージョン上のワーカーで処理され、結果だけが Google Cloud に返ります。これにより、大量のデータを処理する場合でも、クラウドをまたいだ大規模なデータ転送が発生しないため、処理速度が速いことに加え、結果のみが転送されるため AWS / Azure からの外向きトラフィック料金（data egress charges）が比較的小さくなります。この点が、BigQuery Omni の利点といえます。 データセットの所在 BigQuery cross-cloud connections BigQuery cross-cloud connections では、標準的な BigQuery リージョン（ us-east1 、 asia-northeast1 等）に BigQuery データセットを作成します。このデータセットに、S3 バケットや Blob Storage コンテナへの外部テーブル等を作成します。 BigQuery Omni BigQuery Omni は、BigQuery データセットを特殊なリージョンに作成します。これらのリージョンは、BigQuery 側では aws-us-east-1 や azure-eastus2 といった名称になり、ここに外部テーブルを設置します。 この特殊なリージョン名は、AWS / Azure のリージョン名の冒頭に aws- または azure- を付与したものです（後述の接続を作成するリージョンの ID と同じもの）。 料金 BigQuery cross-cloud connections BigQuery cross-cloud connections では、通常の BigQuery のクエリ料金（コンピュート料金）が発生します。これに加えて、AWS / Azure からデータが外部に出る際の外向きトラフィック料金が発生します。 BigQuery Omni BigQuery Omni では、AWS / Azure の外向きトラフィック料金に加えて、通常の BigQuery クエリ料金ではなく、BigQuery Omni 専用のコンピュート料金が発生します。この課金は、デフォルトではデータ処理量（TiB）あたりに発生します（Editions を選択することも可能）。この専用料金は、通常の BigQuery オンデマンド料金よりも、割高に設定されています。 通常の BigQuery 料金と異なる設定がされている理由は、AWS / Azure に専用のワーカーをデプロイしているためだと考えられます。 参考 : BigQuery pricing - BigQuery Omni pricing 構築手順 BigQuery cross-cloud connections を使う場合でも、BigQuery Omni を使う場合でも、セットアップ手順はほとんど同一です。 参考 : Create cross-cloud connections - Create AWS cross-cloud connections 参考 : Connect to Amazon S3 AWS との接続を例に取ると、構築手順は両手法とも、おおまかに以下のとおりです。 No 概要 説明 1 AWS 側で IAM をセットアップ IAM ポリシー、IAM ロールを作成する 2 Google Cloud 側で接続（Connection）を作成 認証情報を保存するための接続（Connection）を作成 3 Google Cloud 側で接続（Connection）から BigQuery Google Identity を取得 AWS 側の信頼関係ポリシー等に登録するための数字 4 AWS 側で IAM ロールの信頼関係ポリシーに BigQuery Google Identity を追加 5. とあわせて BigQuery はロールの引き受け（AssumeRole）が可能になる 5 AWS 側でカスタム ID プロバイダ accounts.google.com の Audience として BigQuery Google Identity を追加 4. とあわせて BigQuery はロールの引き受け（AssumeRole）が可能になる これらのうち、BigQuery cross-cloud connections と BigQuery Omni の違いは、手順 2. にあります。接続（Connection）を作成する際、BigQuery cross-cloud connections では、 --location パラメータとして以下のように通常の BigQuery リージョンを指定します。 bq mk --connection \ --connection_type =' AWS ' \ --location = asia-northeast1 \ --project_id = ${PROJECT_ID} \ --properties =' {"accessRole":{"iamRoleId":"arn:aws:iam::123456789012:role/RoleForBigQuery"}} ' \ connection-for-bigquery-cross-cloud 一方で BigQuery Omni の場合、 --location パラメータには以下のように AWS / Azure リージョンを示す独自の ID を指定します。この ID は、AWS / Azure のリージョン名の冒頭に aws- または azure- を付与したものです。 bq mk --connection \ --connection_type =' AWS ' \ --location = aws-us-east-1 \ --project_id = ${PROJECT_ID} \ --properties =' {"accessRole":{"iamRoleId":"arn:aws:iam::123456789012:role/RoleForBigQuery"}} ' \ connection-for-bigquery-omni 外部テーブル（BigLake テーブル）を作成する際に、Google Cloud リージョンに作成された接続を使うと BigQuery cross-cloud connections が使用され、AWS / Azure リージョンに配置された接続を使うと BigQuery Omni が使用されることになります。 外部テーブル（BigLake テーブル）作成時の DDL は以下のようなものです。WITH CONNECTION の後のリージョン ID に着目してください。 BigQuery cross-cloud connections 用の接続を使用する場合 CREATE EXTERNAL TABLE `my-project.my_dataset_tokyo.table_for_s3` WITH CONNECTION `asia-northeast1.connection- for -bigquery- cross -cloud` OPTIONS ( format = ' CSV ' , uris = [ ' s3://my-sample-bucket-tokyo/* ' ] ); BigQuery Omni 用の接続を使用する場合 CREATE EXTERNAL TABLE `my-project.my_dataset_n_virginia.table_for_s3` WITH CONNECTION `aws-us-east -1 .connection- for -bigquery-omni` OPTIONS ( format = ' CSV ' , uris = [ ' s3://my-sample-bucket-n-virginia/* ' ] ); 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it