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 プロジェクトを指定した従量課金方式を用います。しかし、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 を使用できる 使用可能なボリュームは、以下のように決まる (ライセンス数) × (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

G-gen の菊池です。Gemini Enterprise のサブスクリプションでライセンス数を削減しようとした際に直面するエラーと、その解決策について解説します。 事象 原因 ライセンス削減の仕様制限 サブスクリプションを新規作成する際の壁 対処の手順 概要 手順1: 自動更新の停止 手順2: 契約の期限切れを待つ 手順3: 新しいサブスクリプションの購入 手順4: ライセンスの自動更新 事象 Google Cloud の請求先アカウントに紐づく、Gemini Enterprise のサブスクリプション（月間プラン、または年間プラン）を利用している環境を想定します。 利用者の減少などにより、不要になったライセンス分の課金を停止したいケースがあります。公式ドキュメントでは、Google Cloud コンソールのサブスクリプションの詳細画面からライセンス数の更新が可能であると記載されています。この画面からライセンス数を 増やす 場合は、問題なく変更を保存できます。 しかし、同じ画面でライセンス数を 減らそうと した際、以下のエラーが表示され、変更を保存できない事象が発生しました。 ライセンス数は、現在のライセンス数以上である必要があります 参考 : Get subscriptions and assign licenses for Gemini Enterprise - Update subscription settings なお、Gemini Enterprise の正式名称は Gemini Enterprise app ですが、公式ドキュメントでも多くの場合で単に Gemini Enterprise と記載されているため、当記事でも Gemini Enterprise の名称を採用します。 原因 ライセンス削減の仕様制限 公式ドキュメントを確認すると、2026年8月現在、Gemini Enterprise の仕様上、有効なサブスクリプション契約の期間中にライセンスの合計数を減らすことはできないことが明記されています。 参考 : Frequently asked questions about Gemini Enterprise subscriptions and licenses - Can I reduce the license count Can I reduce the license count? No, you can't reduce the license count during an active subscription term. License reductions are only possible when the subscription term ends or is up for renewal. (引用者訳: いいえ、有効な契約期間中はライセンス数を減らすことはできません。ライセンス数の削減は、契約期間が終了するか、更新時期が近づいた場合にのみ可能です。) また、Gemini Enterprise では、途中解約、残期間分の支払いの免除や返金もできません。 そのため、契約途中に実際の利用人数に合わせて、Google Cloud コンソールの画面からライセンス数を減らすことはできません。なお、契約期間中であってもライセンス数を 増やす ことは可能です。 ライセンス数を減らすには、現在のサブスクリプションの自動更新をオフにして、契約期間が切れてから、適切なライセンス数で 新しいサブスクリプションを作成 する必要があります。 この対応は、月間プランであれば月単位で各月の契約満了時に実施でき、年間プランであれば年単位になります。 サブスクリプションを新規作成する際の壁 前述の通り、ライセンス数を減らすには「現在の契約が切れてから新規購入する」必要があります。しかし、Google Cloud コンソールでサブスクリプションを購入する際、契約の開始日を選択する項目はありません。未来の開始日を指定してサブスクリプションを予約購入することはできず、購入が完了した日から即座に有効になります。 よって、ライセンス数を減らして新しいサブスクリプションを購入しようとすると、古い契約が失効してから新しい契約を購入するまでの間に、Gemini Enterprise が利用できない空白期間が発生することになります。 そこで、このリードタイムをなくすための代替案として、「一時的な重複課金を許容してでも、元の契約期間がわずかに残っている時点で、あらかじめ少ないライセンス数の新しいサブスクリプションを購入しておく」というアプローチが考えられます。 しかしこの代替案にも、 Subscription already exists エラー というシステム上の仕様が存在するため、 実現できません 。 Gemini Enterprise のサブスクリプションは、プロジェクト単位ではなく、請求先アカウントレベルで管理されます。 同一の請求先アカウント内において、「同じエディション（例: Standard）」かつ「同じ期間（月間または年間）」のサブスクリプションを重複して保持しようとすると、Subscription already exists エラーが発生し、購入がブロックされます。 例えば、別プロジェクトでサブスクリプションを管理したいといった理由で、既存契約とは別のプロジェクトにサブスクリプションを新規作成しようとした場合であっても、同様にエラーが発生します。重複はあくまで、請求先アカウントのレベルでチェックされるからです。 単に別プロジェクトで Gemini Enterprise を利用したい場合であれば、既存サブスクリプションのライセンスを別プロジェクトへ配布（Distribute）することで対応できます。しかし、今回のように「ライセンス数を削減したい」という目的を達成するためには、配布による運用では対応できないため、次章で解説する手順が必要です。 参考 : Get subscriptions and assign licenses for Gemini Enterprise - Distribute licenses 対処の手順 概要 前述のエラーと仕様制限を回避してライセンス数を削減するには、 現在のサブスクリプションが失効するのを待ってから新規購入 する必要があります。 この手順を採用する場合、契約期間が満了して古い契約が失効してから、新しい契約を購入するまでの間、Gemini Enterprise が利用できない空白期間が発生します。 その点に留意したうえで、以下の手順を実施します。 手順1: 自動更新の停止 Google Cloud コンソールの「サブスクリプションを管理」画面から、現在のサブスクリプションの [ 編集 ] を開きます。自動更新が有効なままだと、削減前のライセンス数のまま次回の契約が更新されてしまうため、自動更新をオフに設定し、現在の契約期間の満了を待ちます。 手順2: 契約の期限切れを待つ サブスクリプションの契約期間が終了し、完全に失効（Expired）状態になるのを待ちます。契約期間が満了するまでは新規購入がエラーとなります。 手順3: 新しいサブスクリプションの購入 既存契約の失効を確認した後、削減後の必要なユーザー数を指定した新たなサブスクリプションを購入します。 手順4: ライセンスの自動更新 ユーザーが Gemini Enterprise を使えない空白期間を最小限にするため、手動での割り当てだけでなく、新しいライセンスが自動的に割り当てられる設定が推奨されます。Google Cloud コンソールの Gemini Enterprise ページから [ ユーザーの管理 ] を開き、以下の設定を行います。 [ ライセンスを自動的に割り当てる ] を選択し、手順 3 で購入した新しいサブスクリプションを指定する。 [ 期限切れのライセンスを自動更新する ] を選択する。 この設定により、古いサブスクリプションの有効期限が切れたユーザーが次にログインした際、新しいサブスクリプションからライセンスが自動的に付与されます。 参考 : Get licenses for Gemini Notebook Enterprise - Automatically transfer users to an active subscription 菊池 健太 (記事一覧) 事業開発部クラウドサポート課。2024年7月より、G-genに入社。群馬出身のエンジニア。前職でLookerの使用経験はあるが、Google Cloudは未経験なので現在勉強中。

G-gen の松尾です。当記事では、Google Cloud と Amazon Web Services（AWS）をプライベートに接続する Partner Cross-Cloud Interconnect for AWS について解説します。 概要 Partner Cross-Cloud Interconnect for AWS とは 対応リージョン transport リソース Cross-Cloud Interconnect との比較 料金 接続方式 接続方式の違い VPC ネットワークピアリング Network Connectivity Center 2 つの方式の比較 接続の表示・更新・削除 注意点 概要 Partner Cross-Cloud Interconnect for AWS とは Partner Cross-Cloud Interconnect for AWS は、Google Cloud と Amazon Web Services（以下、AWS）の間にプライベートな専用線接続を提供するマネージドサービスです。対応するペアリングロケーションであれば、両クラウドのリソースをインターネットを経由することなくセキュアに相互接続できます。 本サービスの最大の特徴は、ネットワークサービスプロバイダーとの回線契約や、クラウド間のポート申請等の物理回線の手配が不要である点です。Google Cloud と AWS の両社が共同設計したインフラを利用するため、数ステップの操作を行うだけで、わずか数分で専用線の接続ができます。Google Cloud 側では、VPC ネットワークピアリングや Network Connectivity Center スポークといったクラウドリソースとして接続を管理できます。 参考 : AWS 向け Partner Cross-Cloud Interconnect の概要 参考 : 画期的な AWS とのコラボレーションで Google Cloud のクロスクラウド ネットワークを拡大 なお2026年8月現在、Google Cloud および AWS の東京リージョンや大阪リージョンには対応していない点に注意が必要です。 対応リージョン Partner Cross-Cloud Interconnect for AWS では、Google Cloud のリージョンと AWS のリージョンが、あらかじめ決められたペアとして定義されています。2026年8月現在、対応するリージョンペアは以下のとおりです。最新の一覧は以下の公式ドキュメントを参照してください。 Google Cloud リージョン AWS リージョン asia-southeast1（シンガポール） ap-southeast-1（シンガポール） europe-west2（ロンドン） eu-west-2（ロンドン） europe-west3（フランクフルト） eu-central-1（フランクフルト） us-east4（バージニア） us-east-1（バージニア北部） us-west1（オレゴン） us-west-2（オレゴン） us-west2（ロサンゼルス） us-west-1（北カリフォルニア） 参考 : ペアリング ロケーションを選択する transport リソース このサービスの中心となるのが transport リソースです。物理的な相互接続や VLAN アタッチメント、Cloud Router インスタンスをひとまとめに抽象化したマネージドサービスのリソースです。 従来の Cross-Cloud Interconnect では、こうした構成要素を 1 つずつ自分で用意して管理する必要がありました。一方の Partner Cross-Cloud Interconnect for AWS では、Google Cloud 側の transport リソースと AWS 側の Direct Connect ゲートウェイを結びつけるだけで、セキュアなマルチクラウド専用接続の確立が完了します。 Google Cloud と AWS のリソース同士を結びつけるために アクティベーションキー を使用します。起点となるクラウド側でキーを発行し、もう一方がそのキーを登録して自クラウドのリソースを作成する仕組みです。この相互連携により、プロビジョニングをどちらのクラウドからでも開始できます。 参考 : AWS 向け Partner Cross-Cloud Interconnect のプロビジョニングの概要 Cross-Cloud Interconnect との比較 Cross-Cloud Interconnect は、Google Cloud と AWS をはじめとする他社クラウドのネットワークを、専用の物理接続でプライベートに接続するサービスです。Partner Cross-Cloud Interconnect for AWS は Cross-Cloud Interconnect の発展形と位置づけられています。 従来の Cross-Cloud Interconnect では、物理回線を手配し、VLAN アタッチメントなどのネットワークリソースを自分で設定する必要がありました。Partner Cross-Cloud Interconnect for AWS ではこの工程がなくなり、接続が使えるようになるまでの時間は大きく縮まります。冗長性も基盤側にあらかじめ組み込まれているため、利用者が冗長構成を設計したり管理したりする必要はありません。 Cross-Cloud Interconnect についての詳細は、以下の記事を参照してください。 blog.g-gen.co.jp Cross-Cloud Interconnect と Partner Cross-Cloud Interconnect for AWS の主な違いは、以下のとおりです。 項目 Cross-Cloud Interconnect Partner Cross-Cloud Interconnect for AWS 接続先 OCI、AWS、Azure、Alibaba Cloud など AWS 物理的な配線工事 発生する 発生しない 物理ポート申請（LOA の取得・提出） 必要 不要 接続の発注元 Google Cloud から発注 Google Cloud または AWS の双方向 料金 Cloud Interconnect 接続・VLAN アタッチメント・下り（Egress）トラフィックに課金 transport リソースのみに課金 参考 : AWS 向け Partner Cross-Cloud Interconnect の概要 - Cross-Cloud Interconnect との比較 料金 Partner Cross-Cloud Interconnect for AWS の料金は、 transport リソースの時間単位の課金 で構成されます。transport がアクティブな時間に対して、選択した帯域とリージョンに応じた料金が発生します。 特徴は、 データ転送量に対する従量課金がない点 です。従来の Cross-Cloud Interconnect では、接続の時間課金に加えて、Virtual Private Cloud（以下、VPC）ネットワークからの下り（Egress）データ転送にも料金がかかりました。しかし、Partner Cross-Cloud Interconnect for AWS では、上り（Ingress）・下り（Egress）ともにデータ転送料金は発生しません。 なお、後述する 2 つの接続方式である VPC ネットワークピアリングと Network Connectivity Center（NCC）のどちらを選んでも、Partner Cross-Cloud Interconnect for AWS 自体の料金は変わりません。料金はあくまで transport リソースの帯域に対する時間課金で決まるためです。 ただし、料金には注意点が 2 つあります。1 つは、NCC を使用する場合、Partner Cross-Cloud Interconnect for AWS の料金とは別に NCC の利用料金が発生する点です。もう 1 つは、接続先となる AWS 側でも、AWS Interconnect（multicloud オプション）など対象サービスの料金が別途発生する点です。 詳細は以下の公式ドキュメントを参照してください。 参考 : Cloud Interconnect pricing - Partner Cross-Cloud Interconnect 参考 : Network Connectivity pricing 接続方式 接続方式の違い Partner Cross-Cloud Interconnect for AWS では、Google Cloud 側のネットワーク構成として、 VPC ネットワークピアリング を使用する方式と、 Network Connectivity Center （NCC）を使用する方式の 2 つがあります。 前者は単一の VPC ネットワークと AWS を 1 対 1 で接続するシンプルな構成、後者は複数の VPC やハイブリッド接続を集約管理する規模の大きいネットワーク向けの構成です。 参考 : AWS 向け Partner Cross-Cloud Interconnect のプロビジョニングの概要 VPC ネットワークピアリング VPC ネットワークピアリングを使用する方式は、transport リソースを単一の VPC ネットワークに接続する構成です。特定の VPC ネットワークと AWS を 1 対 1 でプライベートに接続したい場合に適しています。 transport リソースを作成すると、中継用のピアリング VPC ネットワークが自動的に生成されます。利用者は、この自動生成されたピアリング VPC ネットワークと、自身のワークロード VPC ネットワークを VPC ネットワークピアリングで接続します。これにより、ワークロード VPC（図最左部）と AWS のリソース（図右部）が、自動的に交換されるルートを通じて通信できます。構成のイメージは以下のとおりです。 VPC ネットワークピアリングを使用する場合 参考 : Google Cloud から開始する接続を作成する - VPC ネットワーク ピアリングを使用する 参考 : AWS から開始する接続を作成する - VPC ネットワーク ピアリングを使用する VPC ネットワークピアリングについての詳細は、以下の公式ドキュメントを参照してください。 参考 : VPC ネットワーク ピアリングの概要 Network Connectivity Center Network Connectivity Center（NCC）を使用する方式は、transport リソースを NCC のハブにスポークとして接続する構成です。NCC は、複数の VPC ネットワークやハイブリッド接続をハブアンドスポークのモデルで集約的に管理するためのサービスです。NCC を使用すると、複数の VPC ネットワークや他の外部接続をまたいでルートを一元的に管理できます。複数の VPC や複数のクラウド接続を統合的に扱いたい、規模の大きいネットワークに適した方式です。 なお NCC を使用する方式は 2026年8月現在、Preview ステージです。Preview ステージの機能には技術サポートや SLA が提供されないこと、また一般公開せずに終了したり、一般提供の際に仕様が変更される可能性がある点に留意してください。Preview 版のサービスや機能を使用する際の注意点は、以下の記事も参照してください。 blog.g-gen.co.jp transport リソースを NCC のハブにスポークとして接続すると、ハブが各スポーク間でルートを伝播します。これにより、ハブに接続した複数の VPC ネットワークやハイブリッド接続（オンプレミスとの接続等）と AWS との間で、ルートを一元的に交換できます。VPC ネットワークピアリング方式が単一の VPC との 1 対 1 接続であるのに対し、NCC 方式は複数のネットワークを 1 つのハブに集約できる点が大きな違いです。構成のイメージは以下のとおりです。 Network Connectivity Center を使用する場合 参考 : Google Cloud から開始する接続を作成する - Network Connectivity Center を使用する 参考 : AWS から開始する接続を作成する - Network Connectivity Center を使用する NCC についての詳細は、以下の記事を参照してください。 blog.g-gen.co.jp 2 つの方式の比較 2 つの方式の違いを以下に整理します。 観点 VPC ネットワークピアリング NCC 提供ステージ 一般公開（GA） Preview Google Cloud 側の接続先 単一の VPC ネットワーク NCC のハブ（スポークとして接続） 適した規模 単一 VPC と AWS の 1 対 1 接続 複数 VPC・複数接続の集約管理 接続の表示・更新・削除 接続の表示、更新、削除は、transport リソースを通じて行います。gcloud CLI、Google Cloud コンソールまたは API を使用します。 当記事では、gcloud CLI を使用した場合の操作を紹介します。 接続を一覧表示するには、 gcloud network-connectivity transports list コマンドを使用します。リージョンを指定すると、transport の名前、プロファイル、帯域、状態（State）が一覧で確認できます。 gcloud network-connectivity transports list \ --region = LOCATION 特定の transport の詳細を確認するには、 gcloud network-connectivity transports describe コマンドを使用します。説明（description）の更新や、広告されるルート（advertisedRoutes）の確認ができます。 transport を削除するには、 gcloud network-connectivity transports delete コマンドを使用します。 gcloud network-connectivity transports delete TRANSPORT_NAME \ --region = LOCATION transport を削除しても AWS 側のリソースは削除されません。接続を完全に解除する際は、Google Cloud 側と AWS 側の両方をクリーンアップする必要がある点に注意してください。 参考 : 接続を管理する 注意点 transport リソースにはプロジェクトごと・リージョンごとのクォータがあり、デフォルトでは各プロジェクトがリージョンあたり 1 つに制限されます。複数必要な場合は、クォータの引き上げを検討してください。 Google Cloud のワークロード VPC と AWS VPC の MTU は揃える必要があります。MTU が一致していないと、パケットのドロップやフラグメンテーションが発生します。その結果、データ損失・スループットの低下・インターコネクト全体での接続切断につながります。 VPC ネットワークピアリング方式を利用して transport リソースを作成する際、 Network MTU 1460B does not match the peer's MTU 8896B といった警告が表示されることがあります。これは、ワークロード VPC と、前述のピアリング VPC ネットワーク（8896 バイト固定）との MTU 差分を検知した警告です。ピアリング VPC ネットワークは最大値で固定されているため、この区間自体がボトルネックになることはありません。一方で、ワークロード VPC と AWS VPC の MTU は前述のとおり一致させる必要があります。この警告が表示されても、両端の MTU が揃っていれば通信に問題はありません。 SLA は、Google と AWS がそれぞれ自社の管理する接続区間に対して提供します。 各項目の詳細は、以下のドキュメントを参照してください。 参考 : Create a connection initiated from AWS with VPC Network Peering 参考 : AWS Interconnect が一般提供され、ラストマイル接続を簡素化する新しいオプションが追加されました 松尾 和哉 (記事一覧) クラウドソリューション部 これまで主にAWSを活用する企業でインフラエンジニアとして従事していました。Google Cloudに魅力を感じてG-genにジョイン。アウトプットを経てコミュニティへの還元や自己研鑽をしたいと思っています。

G-gen の武井です。当記事では Cloud Billing の新機能である Spend cap budgets を用いて、意図しない課金を防ぐ方法を解説します。 はじめに Spend cap budgets とは パートナーの請求先アカウントでの使用について 対象サービス 制約 必要な権限 設定方法 予算の作成 1. 定義 2. 範囲 3. 金額 4. 操作 動作確認 確認内容 Cloud Run 50% 到達時 80 % 到達時 100 % 到達時 一時停止解除 Gemini Enterprise Agent Platform はじめに Spend cap budgets とは Spend cap budgets とは、上限額に到達した際に対象サービスの利用を自動的に一時停止する機能です。2026年4月の Google Cloud Next '26 で発表され、2026年7月27日にパブリックプレビューになりました。 従来の予算とアラート機能は上限額に到達した際に指定の宛先に通知するもので、支出そのものを止める仕組みは含まれていませんでした。Spend cap budgets は、この「止める」処理を予算とアラートの拡張機能として提供します。 動作の流れは以下のとおりです。 目標金額の 50%・80% に到達した時点でアラートメールが送信される 100% に到達すると対象サービスへの新規リクエストがブロックされる 上限は自動解除されず、ユーザーが手動で解除するまで停止が継続する ただし、最も重要な制約として、後述のように、当機能は Google Cloud パートナーから発行された請求先アカウントでは使用できません 。当機能が使用できるのは、Google との直接契約を結んでいる場合のみです。 参考 : Manage spend cap budgets パートナーの請求先アカウントでの使用について Spend cap budgets が使用できるのは Google Cloud と直接、契約を結んでいる場合に限定されます。G-gen 社のような Google Cloud パートナー（リセラー）の請求先アカウントでは、当機能が使用できないことが明記されています。 Spend cap budgets are limited to first-party Google Cloud customers. Reseller accounts are out of scope. ただし、当記事の検証を行った2026年7月下旬時点で、当社が販売パートナーとして保有する請求先アカウント配下のサブアカウントで実施したところ、予算の作成、各閾値でのアラートメールの受信、上限額到達時のサービス停止まで、いずれも正常に動作しました。 ただし、ドキュメントに明記されている以上、今後の仕様変更によって予告なく利用できなくなる可能性があります。そのため、パートナーから発行された請求先アカウントを使用している場合、当機能の本番環境での使用は推奨されません。 対象サービス 2026年7月現在、Spend cap budgets の対象サービスは以下のとおりです。これら以外のサービスでは、従来通り予算とアラート機能によるアラート通知のみが提供されます。 Gemini API Gemini Enterprise Agent Platform（旧称 Vertex AI） Cloud Run Cloud Run functions 参考 : Services that are eligible for spend cap budgets 制約 Spend cap budgets には以下の制約があります。 分類 制約内容 スコープ 単一プロジェクト、かつ単一の対象サービスにのみ設定可能 期間 毎月 1 日開始の「月別」に固定。変更不可 契約形態 Google Cloud 直接契約の顧客のみ。リセラー経由の請求先アカウントは対象外 上限額 割引やクレジットを含まない総額ベースで計算 適用範囲 従量課金、確約利用割引（CUD）、プロビジョンドスループット（PT） ※ サブスクリプションベースの費用は停止対象外 反映遅延 判定処理の遅延に伴う上限超過分は通常どおり課金される 既存予算 「アラートのみ」の予算からは変換不可。削除したうえで新規作成が必要 注意が必要なのは、 上限到達時のサービス停止が即時反映ではない点 です。そのため、設定の際は想定する上限額に対し、やや低い金額を設定することが推奨されています。 参考 : Limitations of spend cap budgets 必要な権限 Spend cap budgets の作成および管理には、以下のいずれかの権限が必要です。 請求先アカウントに対する Billing Account Administrator（ roles/billing.admin ） 対象プロジェクトに対する Project Owner（ roles/owner ） 請求先アカウントに対する Billing Account Costs Manager（ roles/billing.costsManager ）と、対象プロジェクトに対する Project Editor（ roles/editor ）の組み合わせ 参考 : Permissions required to manage spend cap budgets 設定方法 予算の作成 対象のプロジェクトから 課金 > リンクされた請求先アカウント > 予算とアラート と進み、 Create budget を選択します。ウィザードは 4 つのステップで構成されています。 1. 定義 利用額上限の適用（一部のサービスで利用可能） にチェックを入れて名前を入力します。 2. 範囲 次に、対象プロジェクトと対象サービスを選択します。対象サービスについては前述の通りです。なお、期間は月別に自動設定されており、変更できません。 3. 金額 次に上限額を入力します。今回は動作確認のため ¥100 としていますが、実際の設定においては、即時反映ではないことを考慮した上限額を設定してください。 4. 操作 操作については変更ができません。また、現時点では従来の予算とアラートのように通知先チャネルの選択もできません。最後に設定内容に問題がなければ保存します。 今回の例では Cloud Run と Gemini Enterprise Agent Platform に対し、それぞれ上限額を ¥100 とした Spend cap budgets を2つ設定しました。 動作確認 確認内容 対象のサービスの利用額が 50% / 80% / 100% に到達したときの挙動を確認します。 Cloud Run 50% 到達時 課金管理者およびプロジェクトオーナーに対し、 上限額の50%に到達した旨 の通知がありました。 80 % 到達時 上記同様、課金管理者およびプロジェクトオーナーに対し、 上限額の80%に到達した旨 の通知がありました。 100 % 到達時 100% に到達した際の通知は 50% や 80% 到達時とは異なり、 サービスの一時停止を知らせる旨 （ Service paused ）の通知がありました。 通知受領前の Cloud Run の状態は以下の通りでした。 通知受領後の画面では、 利用額上限に達したため、サービスが一時停止された旨 の警告が表示されています。 この状態で新たに Cloud Run をデプロイしようとしても、API が一時的に停止しているためエラーとなりました。 # Cloud Run サービスのデプロイ yutakei@cloudshell:~ ( yutakei ) $ gcloud run deploy spend-cap-test2 \ --image = us-docker.pkg.dev/cloudrun/container/hello \ --region = us-central1 \ --cpu = 4 \ --memory = 2Gi \ --min-instances = 2 \ --max-instances = 2 \ --no-cpu-throttling \ --no-allow-unauthenticated Deploying container to Cloud Run service [ spend-cap-test2 ] in project [ yutakei ] region [ us-central1 ] Deploying new service... Creating Revision...failed Deployment failed # エラーログ ERROR: ( gcloud.run.deploy ) The user-provided container failed to start and listen on the port defined provided by the PORT = 8080 environment variable within the allocated timeout. This can happen when the container port is misconfigured or if the timeout is too short. The health check timeout can be extended. Logs for this revision might contain more information. Logs URL: https://console.cloud.google.com/logs/viewer? project =yutakei & resource =cloud_run_revision/service_name/spend-cap-test2/revision_name/spend-cap-test2-00001-gnl & advancedFilter =resource. type %3D%22cloud_run_revision% 22 %0Aresource.labels.service_name%3D%22spend-cap-test2% 22 %0Aresource.labels.revision_name%3D%22spend-cap-test2-00001-gnl% 22 For more troubleshooting guidance, see https://cloud.google.com/run/docs/troubleshooting #container-failed-to-start 一時停止解除 該当の Spend cap budgets はステータスが 適用済み となっています。適用済みの場合、 指定されたサービスは手動で上限を解除するまで一時停止 されます。 解除には 利用額上限を解除 をクリックします。 なお、解除時には以下の留意事項が表示されます。 解除すると、対象プロジェクトの当該サービスのみが再開する 同一の請求月内に解除した場合、目標金額を引き上げない限り、その月の残り期間は再度発動しない 翌月にはリセットされ、再び上限額の到達で発動する 完全に再開するまでに1時間程度かかる場合がある 解除すると解除の旨を伝えるメール通知とともに再開されます。画面からも設定した上限額を多少超過したところで停止されていたことがわかります。 再検証のため（同一月内で再度発動するようにするため）、上限額を ¥200 に引き上げて確認します。 完全に再開するまでに 1 時間程度かかる場合がある とありましたが、手元の環境では再開後まもなく、先程は失敗した Cloud Run サービスのデプロイに成功しました。 # Cloud Run サービスのデプロイ（リトライ） yutakei@cloudshell:~ ( yutakei ) $ gcloud run deploy spend-cap-test2 \ --image = us-docker.pkg.dev/cloudrun/container/hello \ --region = us-central1 \ --cpu = 4 \ --memory = 2Gi \ --min-instances = 2 \ --max-instances = 2 \ --no-cpu-throttling \ --no-allow-unauthenticated Deploying container to Cloud Run service [ spend-cap-test2 ] in project [ yutakei ] region [ us-central1 ] Deploying... Setting IAM Policy...done Creating Revision...done Routing traffic...done Done. Service [ spend-cap-test2 ] revision [ spend-cap-test2-00002-ckj ] has been deployed and is serving 100 percent of traffic. Service URL: https://spend-cap-test2-933617552181.us-central1.run.app Proxy locally with: gcloud run services proxy spend-cap-test2 --region us-central1 --project yutakei その後は、50%および80%到達時、そして100％到達時の一時停止を知らせる旨のメール通知を再度受信しました。サービスについては再度一時停止状態となりました。 # Cloud Run サービスのデプロイ yutakei@cloudshell:~ ( yutakei ) $ gcloud run deploy spend-cap-test3 \ --image = us-docker.pkg.dev/cloudrun/container/hello \ --region = us-central1 \ --cpu = 4 \ --memory = 2Gi \ --min-instances = 2 \ --max-instances = 2 \ --no-cpu-throttling \ --no-allow-unauthenticated Deploying container to Cloud Run service [ spend-cap-test3 ] in project [ yutakei ] region [ us-central1 ] Deploying new service... Creating Revision...failed Deployment failed # エラーログ ERROR: ( gcloud.run.deploy ) The user-provided container failed to start and listen on the port defined provided by the PORT = 8080 environment variable within the allocated timeout. This can happen when the container port is misconfigured or if the timeout is too short. The health check timeout can be extended. Logs for this revision might contain more information. Logs URL: https://console.cloud.google.com/logs/viewer? project =yutakei & resource =cloud_run_revision/service_name/spend-cap-test3/revision_name/spend-cap-test3-00001-mlx & advancedFilter =resource. type %3D%22cloud_run_revision% 22 %0Aresource.labels.service_name%3D%22spend-cap-test3% 22 %0Aresource.labels.revision_name%3D%22spend-cap-test3-00001-mlx% 22 For more troubleshooting guidance, see https://cloud.google.com/run/docs/troubleshooting #container-failed-to-start Gemini Enterprise Agent Platform こちらの動作確認では、Gemini で生成した以下の画像生成スクリプトを実行して上限到達時の挙動を確認しました。 for i in $( seq 1 40 ) ; do TS = $( date ' +%Y-%m-%d %H:%M:%S ' ) CODE = $( curl -s -o /tmp/resp.json -w ' %{http_code} ' -X POST \ -H " Authorization: Bearer $( gcloud auth print-access-token ) " \ -H " Content-Type: application/json " \ " $ENDPOINT " \ -d ' { "contents": [{"role": "user", "parts": [{"text": "A photorealistic Japanese garden in autumn"}]}], "generationConfig": {"responseModalities": ["TEXT", "IMAGE"]} } ' ) if [ " $CODE " = "200" ]; then TOK = $( jq -r ' .usageMetadata.candidatesTokenCount // 0 ' /tmp/resp.json ) echo " ${TS} ${i} 枚目 HTTP 200 出力 ${TOK} tokens " | tee -a " $LOG " else echo " ${TS} ${i} 枚目 HTTP ${CODE} " | tee -a " $LOG " echo " --- エラー応答 --- " | tee -a " $LOG " cat /tmp/resp.json | tee -a " $LOG " echo | tee -a " $LOG " break fi sleep 10 done 比較的すぐに100%に到達したためか、50%と80%到達時のメール通知がなく、100%到達時のメールのみを受信しました。 また、スクリプトについても100%到達後しばらくしてエラー終了しました。 2026-07-29 18:30:29 28 枚目 HTTP 200 出力 1303 tokens 2026-07-29 18:30:46 29 枚目 HTTP 200 出力 1303 tokens 2026-07-29 18:31:05 30 枚目 HTTP 200 出力 1290 tokens 2026-07-29 18:31:23 31 枚目 HTTP 200 出力 1303 tokens 2026-07-29 18:31:41 32 枚目 HTTP 200 出力 1302 tokens 2026-07-29 18:31:59 33 枚目 HTTP 200 出力 1295 tokens 2026-07-29 18:32:17 34 枚目 HTTP 200 出力 1295 tokens 2026-07-29 18:32:34 35 枚目 HTTP 200 出力 1303 tokens 2026-07-29 18:32:53 36 枚目 HTTP 200 出力 1303 tokens 2026-07-29 18:33:11 37 枚目 HTTP 200 出力 1304 tokens 2026-07-29 18:33:29 38 枚目 HTTP 200 出力 1301 tokens 2026-07-29 18:33:48 39 枚目 HTTP 200 出力 1303 tokens 2026-07-29 18:34:07 40 枚目 HTTP 403 --- エラー応答 --- { " error " : { " code " : 403 , " message " : " Spend cap breached for project: projects/123456789 for service: aiplatform.googleapis.com. Correlation id: -94604043111382696 " , " status " : " PERMISSION_DENIED " } } 上限に到達した状態では、Cloud Run 同様 API コールがエラーになりました。 2026-07-29 22:55:33 1 枚目 HTTP 403 --- エラー応答 --- { " error " : { " code " : 403 , " message " : " Spend cap breached for project: projects/123456789 for service: aiplatform.googleapis.com. Correlation id: 5729569255055718255 " , " status " : " PERMISSION_DENIED " } } 武井 祐介 (記事一覧) クラウドソリューション部。 Google Cloud Partner Top Engineer 2026 選出。 Follow @ggenyutakei

G-gen の佐々木です。当記事では、Agent Runtime にデプロイしたエージェントの呼び出し元を IAM 拒否ポリシーで特定のプリンシパルのみに制限する方法を、Gemini Enterprise アプリからの接続を例に紹介します。 前提知識 Agent Runtime とは Gemini Enterprise とは IAM ポリシーの仕組み 当記事のシナリオ アクセス制限の考え方 エージェントの呼び出しに必要な権限 Gemini Enterprise の呼び出し元 ID 制限に使用する2つの IAM 機能 リソースレベルの IAM ポリシーによる許可の最小化 IAM 拒否ポリシーによる拒否の強制 制限の粒度に関する注意点 IAM で制限できる粒度 専用プロジェクトへの分離によるアプリ単位の制限 マルチエージェント構成での例外設定 当記事で採用しないアクセス制御手段 Agent Gateway の Client-to-Agent（ingress）モード VPC Service Controls による制限 設定手順 前提条件 リソースレベルでのロール付与 プロジェクトレベルでロール付与する場合 IAM 拒否ポリシーの適用 動作確認 直接呼び出しが拒否されること Gemini Enterprise からも拒否されること 例外を追加して Gemini Enterprise から呼び出せること 前提知識 Agent Runtime とは Agent Runtime （旧称 Agent Engine）は、Gemini Enterprise Agent Platform（旧称 Vertex AI、以下 Agent Platform と記載）が提供するフルマネージドなエージェントの実行環境です。Agent Development Kit（以下 ADK と記載）などのフレームワークで開発した AI エージェントをデプロイすると、API エンドポイント経由で呼び出せるようになります。 Agent Runtime にデプロイしたエージェントは、Google Cloud 上では reasoningEngine というリソースとして管理されます。当記事の主題であるアクセス制御も、このリソースに対する IAM の権限制御として実現します。 blog.g-gen.co.jp Gemini Enterprise とは Gemini Enterprise （旧称 Google Agentspace）は、企業内のユーザーが検索・アシスタント・AI エージェントを利用するための Google Cloud のサービスです。Agent Runtime にデプロイした ADK エージェントを Gemini Enterprise アプリに登録すると、エンドユーザーは Gemini Enterprise の Web アプリからそのエージェントと対話できます。 参考 : Agent Runtime でホストされている ADK エージェントの登録と管理 Gemini Enterprise の詳細については、以下の記事をご一読ください。 blog.g-gen.co.jp なお、正式名称は Gemini Enterprise app ですが、公式ガイドをはじめほとんどのドキュメントでは Gemini Enterprise と呼称されていますので、当記事でも Gemini Enterprise app を指して Gemini Enterprise と呼称します。 IAM ポリシーの仕組み Google Cloud の IAM の仕組みについて、以下のような概念の正確な理解が必須です。 リソースの IAM ポリシー IAM 権限の継承 IAM 権限とロール IAM 拒否ポリシー このような概念の解説については、以下の記事を参照してください。 blog.g-gen.co.jp 当記事のシナリオ Agent Runtime にデプロイしたエージェントは、必要な IAM 権限を持つプリンシパルであれば誰でも API 経由で直接呼び出せます。後述のとおり、この権限は基本ロールの閲覧者（ roles/viewer ）のような広く付与されがちなロールにも含まれるため、デフォルトの状態では「想定したフロントエンドを経由せずにエージェントを直接呼び出す」経路が広く開いています。 当記事では、エージェントの利用経路を特定の呼び出し元のみに限定し、それ以外の直接呼び出しを拒否する構成を、IAM の2つの機能を組み合わせて実現します。例として Gemini Enterprise アプリからの接続を許可対象としますが、Cloud Run にデプロイしたフロントエンドアプリケーションからエージェントを呼び出す構成など、呼び出し元のプリンシパルを特定できる構成であれば同じ考え方を適用できます。 当記事のシナリオ：Agent Runtime 上のエージェント呼び出し元を Gemini Enterprise アプリのみに制限する なお、当記事の記述については、記事を執筆した2026年7月下旬現在のプロダクト仕様に基づいている点に注意してください。最新の製品仕様やアーキテクチャ、ベストプラクティスについては公式ドキュメントを参照し、確認してください。 アクセス制限の考え方 エージェントの呼び出しに必要な権限 Agent Runtime のエージェントの呼び出し（ query / streamQuery メソッド）には、対象の reasoningEngine リソースに対する aiplatform.reasoningEngines.query 権限が必要です。 この権限は、以下のような事前定義ロールに含まれています。オーナーや編集者だけでなく、 閲覧者（ roles/viewer ）にも含まれる 点に注意が必要です。 ロール 備考 オーナー（ roles/owner ）、編集者（ roles/editor ）、閲覧者（ roles/viewer ） 基本ロール。閲覧者でも呼び出し可能 Agent Platform 管理者（ roles/aiplatform.admin ） Agent Platform ユーザー（ roles/aiplatform.user ） Agent Platform 閲覧者（ roles/aiplatform.viewer ） 閲覧者系ロールにも含まれる Discovery Engine サービス エージェント（ roles/discoveryengine.serviceAgent ） サービスエージェント専用ロール。一般のプリンシパルには付与しない 参考 : Gemini Enterprise Agent Platform roles and permissions Gemini Enterprise の呼び出し元 ID Gemini Enterprise アプリは、登録されたエージェントを Discovery Engine サービスエージェント の ID で呼び出します。サービスエージェントのメールアドレスは以下の形式で、 <プロジェクト番号> には Gemini Enterprise アプリがあるプロジェクトの番号が入ります。 service-<プロジェクト番号>@gcp-sa-discoveryengine.iam.gserviceaccount.com したがって、当記事のようにエージェントのアクセス元を Gemini Enterprise アプリのみに制限したい場合は、 この Discovery Engine サービスエージェントにのみ aiplatform.reasoningEngines.query 権限を持たせ、 それ以外のプリンシパルには持たせない ようにするか、あるいはそれ以外のプリンシパルからのアクセスを 明示的に拒否 します。 Cloud Run にデプロイしたフロントエンドアプリケーションなど、Gemini Enterprise 以外を唯一の呼び出し元としたい場合も、許可対象のプリンシパルをその実行サービスアカウントなどに読み替えれば、同じ設計を適用できます。 参考 : Multi-agent private networking patterns in Google Cloud - Gemini Enterprise apps to custom agents 制限に使用する2つの IAM 機能 リソースレベルの IAM ポリシーによる許可の最小化 1つ目は、 リソースレベルの IAM ポリシー による許可の最小化です。 reasoningEngine リソース（Agent Runtime 上のエージェント）は、個々のエージェント単位で IAM ポリシーを設定できます。プロジェクトレベルではなく対象のエージェントに対してのみ、 aiplatform.reasoningEngines.query 権限を含むロールを Discovery Engine サービスエージェントに付与することで、許可の範囲を必要最小限に近づけられます。 ただし、リソースレベルの IAM ポリシーは上位（プロジェクト・フォルダ・組織）の許可ポリシーに 加算 されるだけで、上位の付与を打ち消すことはできません。プロジェクトレベルで閲覧者や Agent Platform ユーザーのロールを持つプリンシパルは、リソースレベルの設定と関係なくエージェントを呼び出せてしまいます。 参考 : エージェントを共有する IAM 拒否ポリシーによる拒否の強制 2つ目は、 IAM 拒否ポリシー による制限の強制です。 拒否ポリシーは許可ポリシーより先に評価されるため、プロジェクトレベルの広いロールを持つプリンシパルにも確実に効きます。 aiplatform.googleapis.com/reasoningEngines.query は拒否ポリシーに対応しており、「全プリンシパルに対して拒否し、例外として Discovery Engine サービスエージェントのみ許可する」というポリシーを作成すれば、当記事の目的を実現できます。 Discovery Engine サービスエージェントのみエージェント呼び出しを許可する IAM 拒否ポリシー IAM 拒否ポリシーの詳細については、以下の記事もご一読ください。 blog.g-gen.co.jp 参考 : Permissions supported in deny policies 制限の粒度に関する注意点 IAM で制限できる粒度 Discovery Engine サービスエージェントは、特定の Gemini Enterprise アプリ専用の ID ではありません。プロジェクト単位で1つ作成される Discovery Engine API のサービスエージェントであり、 同一プロジェクト内のすべての Gemini Enterprise アプリ が同じ ID でエージェントを呼び出します。また、Agent Search（旧称 Vertex AI Search）のデータ取り込みなど、Discovery Engine API の他の機能でも同じ ID が使用されます。 このため、IAM で表現できる制限の粒度は「どのプロジェクトの Gemini Enterprise からか」までです。同一プロジェクトで複数の Gemini Enterprise アプリを運用している場合、そのうち特定のアプリだけを許可する、といった アプリ単位での呼び出し元の制御は IAM ではできません 。 プロジェクト内の単一の Gemini Enterprise アプリのみエージェントの呼び出しを許可することはできない 専用プロジェクトへの分離によるアプリ単位の制限 どうしても呼び出し元を特定のアプリのみに制限したい場合は、そのアプリを専用プロジェクトに分離し、エージェントをクロスプロジェクト構成で登録したうえで、アプリ側プロジェクトのサービスエージェントのみを許可します。 ただし、この構成でも IAM の判定がプロジェクト単位である点は変わらず、専用プロジェクト内に別のアプリを作成すると、そのアプリも同じサービスエージェントの ID でエージェントを呼び出せます。このため、専用プロジェクトでのアプリの作成やエージェントの登録の権限を統制し、プロジェクトとアプリの1対1の対応を維持する運用が前提です。 クロスプロジェクト構成では、エージェント側プロジェクト（図中プロジェクト A）でアプリ側プロジェクト（図中プロジェクト B）のサービスエージェントに Discovery Engine サービス エージェント（ roles/discoveryengine.serviceAgent ）ロールを付与します。 クロスプロジェクト構成で単一のアプリのみエージェントを呼び出せるようにする 参考 : プロジェクト間の ADK エージェント アクセスを構成する マルチエージェント構成での例外設定 エージェントから別のエージェントを呼び出すマルチエージェント構成では、呼び出し側エージェントの実行 ID にも aiplatform.reasoningEngines.query 権限が必要です。 実行 ID は、デフォルトでは service-<プロジェクト番号>@gcp-sa-aiplatform-re.iam.gserviceaccount.com 形式のサービスエージェント、Agent Identity（エージェント固有の ID）を有効にしている場合はその Agent Identity です。拒否ポリシーを設定する場合は、これらの ID も例外に追加してください。 拒否ポリシーにより、Agent Runtime 上のエージェント間の呼び出しも拒否されてしまう Agent Runtime 上のエージェントの ID を拒否ポリシーの例外に追加する Agent Identity の詳細については、以下の記事をご一読ください。 blog.g-gen.co.jp 参考 : デプロイされたエージェントのアクセスを管理する 当記事で採用しないアクセス制御手段 Agent Gateway の Client-to-Agent（ingress）モード Agent Platform には、エージェントの通信を統制する Agent Gateway というコンポーネントがあります。Agent Gateway には、エージェントからツールや他のエージェントへの発信を統制する Agent-to-Anywhere（egress）モード と、クライアントからエージェントへの着信を統制する Client-to-Agent（ingress）モード があります。 このうち、 IAM ポリシー によるアクセス制御に対応しているのは egress モードのみです。2026年7月現在、ingress モードでは IAM ポリシーがゲートウェイで適用されないため、当記事の主題である「エージェントへのアクセス元の制限」を Agent Gateway の IAM ポリシーで実現することはできません。 Agent Gateway の詳細については、以下の記事をご一読ください。 blog.g-gen.co.jp VPC Service Controls による制限 ネットワーク境界による類似の制御として、 VPC Service Controls （以下、VPC-SC と記載）を使用する方法もあります。Agent Runtime は VPC-SC に対応しており、Agent Platform の API（ aiplatform.googleapis.com ）をサービス境界で保護すると、境界外からのエージェントの直接呼び出しをブロックできます。Gemini Enterprise と Agent Runtime 間の接続は VPC-SC に準拠しているため、Gemini Enterprise 経由の利用を維持したまま、境界外からの直接呼び出しを遮断する構成にできます。 ただし、VPC-SC の制御はアクセス元のネットワークコンテキスト（境界の内外どちらにいるか）に基づくもので、同じ境界内のプリンシパルによる直接呼び出しは制限できません。また、制御の粒度はサービス単位であり、エージェント単位の制御はできません。このため、当記事で構成するような IAM による制御の代替ではなく、データ漏洩対策のガードレールとして併用する位置づけです。併用する場合は、以下の副作用に注意してください。 サービス境界の保護対象はプロジェクトの Agent Platform API 全体であり、Agent Runtime 以外の機能の利用にも影響する。境界外の開発者やコンソールからの操作を許可するには、アクセスレベルや ingress ルールの整備が必要 境界内では、エージェント自身からインターネットへのアクセスもブロックされる。外部 API を呼び出すエージェントをデプロイする場合、VPC 内に配置したプロキシを経由する egress 経路の構成が必要 エージェントのデプロイ方式によっては、Agent Runtime のサービスエージェントや Artifact Registry などへの ingress ルールの追加が必要 エージェントは、プロジェクトをサービス境界に追加した後にデプロイする必要がある。境界への追加前にデプロイしたエージェントは VPC-SC で保護されない 参考 : Gemini Enterprise Agent Platform での VPC Service Controls 設定手順 前提条件 以下の構成を前提とします。 Agent Runtime に ADK エージェントがデプロイ済み 同一プロジェクトの Gemini Enterprise アプリに、そのエージェントが登録済み Gemini Enterprise アプリにアクセス制御対象のエージェントを登録してある状態 Gemini Enterprise アプリからアクセス制御対象のエージェントを選択できる状態 それぞれの手順は、以下のドキュメントを参照してください。 参考 : Agent Development Kit を使用して Agent Runtime にエージェントを開発してデプロイする 参考 : Agent Runtime でホストされている ADK エージェントの登録と管理 リソースレベルでのロール付与 事前定義ロールの Agent Platform ユーザー（ roles/aiplatform.user ）を、対象エージェントのリソースレベルで Discovery Engine サービスエージェントに付与します。2026年7月現在、gcloud は reasoningEngine リソースの操作に対応していないため、対象エージェントのリソース ID は以下のように Agent Runtime の REST API で確認します。 # 対象エージェントを表示名でフィルタし、name 末尾のリソース ID を確認する $ curl -s -H " Authorization: Bearer $( gcloud auth print-access-token ) " \ " https://<リージョン>-aiplatform.googleapis.com/v1/projects/<プロジェクトID>/locations/<リージョン>/reasoningEngines " \ | jq -r ' .reasoningEngines[] | select(.displayName == "<エージェントの表示名>") | .name ' ----- 出力例 ----- projects/ < プロジェクト番号 > /locations/ < リージョン > /reasoningEngines/ < リソースID > リソースレベルのロール付与も同様に gcloud コマンドに対応しておらず、Python クライアントライブラリまたは Terraform で設定します。以下は Python の例です。 from google.cloud.aiplatform_v1 import ReasoningEngineServiceClient from google.api_core.client_options import ClientOptions PROJECT_ID = "<プロジェクトID>" GE_PROJECT_NUMBER = "<プロジェクト番号>" # Gemini Enterprise アプリ側プロジェクトの番号 LOCATION = "<リージョン>" REASONING_ENGINE_ID = "<リソースID>" client = ReasoningEngineServiceClient( client_options=ClientOptions(api_endpoint=f "{LOCATION}-aiplatform.googleapis.com" ) ) resource = f "projects/{PROJECT_ID}/locations/{LOCATION}/reasoningEngines/{REASONING_ENGINE_ID}" policy = client.get_iam_policy(request={ "resource" : resource}) binding = policy.bindings.add() binding.role = "roles/aiplatform.user" binding.members.append( f "serviceAccount:service-{GE_PROJECT_NUMBER}@gcp-sa-discoveryengine.iam.gserviceaccount.com" ) client.set_iam_policy(request={ "resource" : resource, "policy" : policy}) 付与の結果は、 getIamPolicy メソッドで確認できます。付与したバインディングが出力されれば成功です。 # リソースレベルの IAM ポリシーを確認する $ curl -s -X POST \ -H " Authorization: Bearer $( gcloud auth print-access-token ) " \ -H " Content-Type: application/json " -d ' {} ' \ " https://<リージョン>-aiplatform.googleapis.com/v1/projects/<プロジェクトID>/locations/<リージョン>/reasoningEngines/<リソースID>:getIamPolicy " ----- 出力例 ----- { " version " : 1 , " etag " : " BwZXrJSu7Nc= " , " bindings " : [ { " role " : " roles/aiplatform.user " , " members " : [ " serviceAccount:service-<プロジェクト番号>@gcp-sa-discoveryengine.iam.gserviceaccount.com " ] } ] } Agent Platform ユーザーのロールには、エージェントの呼び出しに必要な aiplatform.reasoningEngines.query 以外の権限も含まれています。付与する権限を最小限にしたい場合は、 aiplatform.reasoningEngines.query 権限のみを含むカスタムロールを作成し、事前定義ロールの代わりにリソースレベルで付与してください。 プロジェクトレベルでロール付与する場合 エージェント単位の許可の最小化が不要な場合は、リソースレベルの代わりにプロジェクトレベルでロールを付与することもできます。プロジェクトレベルの付与は gcloud コマンドに対応しています。 # プロジェクトレベルで Agent Platform ユーザーのロールを付与する $ gcloud projects add-iam-policy-binding < プロジェクトID > \ --member =" serviceAccount:service-<プロジェクト番号>@gcp-sa-discoveryengine.iam.gserviceaccount.com " \ --role =" roles/aiplatform.user " ただし、プロジェクトレベルで付与したロールはプロジェクト内のすべてのリソースに適用されるため、Discovery Engine サービスエージェントには プロジェクト内のすべての Agent Runtime エージェントに対するアクセス権 が与えられます。呼び出しを許可するエージェントを特定の1つに限定したい場合は、前節のリソースレベルでの付与を使用してください。 IAM 拒否ポリシーの適用 すべてのプリンシパルに対して reasoningEngines.query を拒否する拒否ポリシーを作成します。 最終的には例外として Discovery Engine サービスエージェントのみを許可しますが、ポリシーの動作確認を「拒否 → 許可」の順で行うため、まずは例外を設定しないポリシーを適用します。以下の内容で policy.json を作成します。 { " displayName ": " Deny reasoningEngines.query ", " rules ": [ { " denyRule ": { " deniedPrincipals ": [ " principalSet://goog/public:all " ] , " deniedPermissions ": [ " aiplatform.googleapis.com/reasoningEngines.query " ] } } ] } 作成した policy.json を、拒否ポリシーとしてプロジェクトにアタッチします。 # policy.json の内容を、プロジェクトを対象とする拒否ポリシーとして作成する $ gcloud iam policies create deny-agent-query-except-ge \ --attachment-point = cloudresourcemanager.googleapis.com/projects/ < プロジェクトID > \ --kind = denypolicies \ --policy-file = policy.json 拒否ポリシーはプロジェクト内のすべての reasoningEngine リソースに適用されます。ポリシーの反映まで、3分程度待ちます。 動作確認 直接呼び出しが拒否されること 拒否ポリシーの適用後、Agent Runtime のエージェントを API 経由で直接呼び出すと、プロジェクトのオーナーであっても拒否されます。以下は Python での呼び出し例です。 import agentplatform client = agentplatform.Client(project= "<プロジェクトID>" , location= "<リージョン>" ) agent = client.agent_engines.get( name= "projects/<プロジェクトID>/locations/<リージョン>/reasoningEngines/<リソースID>" ) for event in agent.stream_query(message= "Hello" , user_id= "test-user" ): print (event) 実行すると、拒否ポリシーによる拒否であることが明示されたエラーが返ります。 google.genai.errors.ClientError: 403 PERMISSION_DENIED. {'error': {'code': 403, 'message': "Permission 'aiplatform.reasoningEngines.query' denied on resource '//aiplatform.googleapis.com/projects/<プロジェクトID>/locations/<リージョン>/reasoningEngines/<リソースID>' due to an IAM deny policy. Remediate access with this Troubleshooter URL or share it with your administrator - https://console.cloud.google.com/iam-admin/troubleshooter/summary;errorId=<省略> .", 'status': 'PERMISSION_DENIED', 'details': [{'@type': 'type.googleapis.com/google.rpc.ErrorInfo', 'reason': 'IAM_PERMISSION_DENIED', 'domain': 'aiplatform.googleapis.com', 'metadata': {...（省略）...}}]}} Gemini Enterprise からも拒否されること この時点では拒否ポリシーに例外を設定していないため、Gemini Enterprise の Web アプリからエージェントに発話しても、エージェントの応答はエラーになります。Gemini Enterprise がエージェントの呼び出しに使用する Discovery Engine サービスエージェントにも、拒否ポリシーが効いていることが確認できます。 拒否ポリシーによりエージェントの呼び出しが失敗する 例外を追加して Gemini Enterprise から呼び出せること 次に、Discovery Engine サービスエージェントを拒否の例外に設定します。 policy.json に exceptionPrincipals を追加し、以下の内容に更新します。 { " displayName ": " Deny reasoningEngines.query ", " rules ": [ { " denyRule ": { " deniedPrincipals ": [ " principalSet://goog/public:all " ] , " exceptionPrincipals ": [ " principal://iam.googleapis.com/projects/-/serviceAccounts/service-<プロジェクト番号>@gcp-sa-discoveryengine.iam.gserviceaccount.com " ] , " deniedPermissions ": [ " aiplatform.googleapis.com/reasoningEngines.query " ] } } ] } 拒否ポリシーを削除し、更新した policy.json で再作成します。 gcloud iam policies update コマンドでも更新できますが、既存ポリシーの etag を取得して policy.json に含める必要があるため、当記事では削除と再作成で更新します。 # 例外なしの拒否ポリシーを削除する $ gcloud iam policies delete deny-agent-query-except-ge \ --attachment-point = cloudresourcemanager.googleapis.com/projects/ < プロジェクトID > \ --kind = denypolicies # 例外を追加した policy.json で拒否ポリシーを再作成する $ gcloud iam policies create deny-agent-query-except-ge \ --attachment-point = cloudresourcemanager.googleapis.com/projects/ < プロジェクトID > \ --kind = denypolicies \ --policy-file = policy.json 反映後に再度 Gemini Enterprise の Web アプリからエージェントに発話すると、今度は正常に応答が返ります。一方、例外に含まれないプリンシパルによる直接呼び出しは、引き続き拒否されたままです。 例外の有無だけを差し替えた2つの結果から、拒否ポリシーの例外指定によってエージェントの利用経路を Gemini Enterprise 経由のみに限定できたことが確認できました。 Discovery Engine サービスエージェントを拒否ポリシーの例外としたため、アプリからのみエージェントを使用できる Cloud Run にデプロイしたフロントエンドアプリケーションを呼び出し元とする場合は、Discovery Engine サービスエージェントの代わりに Cloud Run サービスの実行サービスアカウントを exceptionPrincipals に指定します。 開発者によるテスト実行や CI からの呼び出しなど、ほかに許可すべき経路がある場合も、同様にそのプリンシパルを exceptionPrincipals に追加してください。 佐々木 駿太 (記事一覧) クラウドソリューション部 クラウドエンジニアリング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 Next Tokyo 26 の2日目に行われたカスタマーセッション「 非エンジニアが安心してバイブ コーディングして公開するには？セキュアな AI 駆動開発ハーネスの仕組み 」のレポートです。 他の Google Cloud Next Tokyo 26 の関連記事は Google Cloud Next Tokyo 26 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 生の AI 駆動開発の問題点 AI 駆動開発ハーネス「Exoloop」 Exoloop とは Exoloop が提供する主な Skill 群 バイブ コーディング SDK「VibeBox」 VibeBox とは 登場人物と役割分担 導入から運用の 3 フェーズ 従来のバイブ コーディングと VibeBox の比較 関連記事 セッションの概要 本セッションは、TieUps株式会社 CTO の土井優紀氏が講演しました。AI の進化によってアプリケーションを「作る」ハードルが下がった一方で、非エンジニアが直面する「本番公開におけるセキュリティ」という課題に対する解決策が紹介されました。 生成 AI を使用したバイブ コーディングにおいて、AI の暴走や品質のばらつき、機密情報の漏洩を防ぐための AI 駆動開発ハーネス Exoloop によって開発プロセスの標準化と暴走防止、知見の自動蓄積を実現し、バイブ コーディング SDK VibeBox によって非エンジニアでも安全に Google Cloud 上へアプリをデプロイ・運用できる環境を整える仕組みや使用法が紹介されました。 生の AI 駆動開発の問題点 生成 AI を用いたバイブ コーディングは、アイデアを即座にコードへ変換できる画期的な手法ですが、生の LLM に開発を行わせる場合、以下の 3 つの大きな課題が発生します。 暴走 AI が想定外のコマンドやファイル操作を実行してしまうリスクです。例えば rm -rf などの破壊的なコマンドや terraform destroy を誤って実行し、本番環境のデータベースやクラウドインフラを削除してしまう危険性があります。 品質のばらつき 同じプロンプトを入力しても出力品質が安定しない問題です。人間による過去のコードレビューでの指摘事項が次の開発に活きず、規約やテストの抜け落ちなど同一のミスを繰り返し、担当者のスキルに依存します。 セキュリティ ソースコード内への .env や API キーの誤コミットによる機密情報の漏洩リスクです。また、外部からの Prompt Injection（プロンプトインジェクション）攻撃による指示の乗っ取りや、悪意ある野良 Skill の無検証でのインストール、OWASP Top 10 / Agentic AI Top 10 で指摘される脆弱性への対応漏れが懸念されます。 参考 : プロンプトインジェクションの解説とGoogle Cloudによる対策 参考 : The Ten Most Critical Web Application Security Risks AI 駆動開発ハーネス「Exoloop」 Exoloop とは Exoloop は、AI の動作を制御する開発ハーネスです。後述の VibeBox に包含されて提供されており、AI に対してもプロジェクトマネジメント（PM）や設計・開発の知識を与えるとともに、開発フローやセキュリティの枠組み（ハーネス）を設定することで、AI の暴走を防ぎ安全な開発を実現します。また、開発サイクルを回すことで、過去の開発の知見が蓄積され、開発精度が継続的に向上していきます。 参考 : AI駆動開発ハーネス — AIチームが設計からデプロイまで。 - Clickan 参考 : ハーネスエンジニアリングとは？AIエージェントの生産性を最大化する環境設計 Exoloop は主に以下の 4 つの構成要素で成り立っています。 構成要素 概要・説明 Skills 要件定義、設計、PR（Pull Request）作成、レビュー対応、E2E テスト、デプロイなどの開発手順や知識を Skill 化 Agents 実装、テスト、レビュー、知見の反映などを分担して並列実行するサブエージェント Hooks 機密情報の自動検査（ gitleaks ）や悪性スキルの遮断（ SkillSpector ）、 lint や typecheck の自動実行 Rules プロジェクト固有のナレッジ（LLM Wiki）使用ルール、ブランチ運用ルール、コーディング規約の定義 Exoloop が提供する主な Skill 群 Exoloop では、開発プロセス全体をカバーする様々な Skill 群が定義されています。主な Skill の役割と概要は以下の通りです。 スキル名 概要・役割 security-settings 要求セキュリティレベル（緩和/標準/厳格）に応じて、 settings.json の AI のセキュリティ設定（サンドボックス、deny ルール、通信制限）を切り替える start-issue Issue 着手から PR 作成までを 3 フェーズ（Phase A: Plan、Phase B: Build、Phase C: Ship）で一括管理する codex-team 実装・テスト・レビューのサブエージェントを並列起動し、受入基準を満たすまで自律ループを実行する create-pr Mermaid 記法を用いて実装構造を図解化した changes.md を作成し、テンプレートを組込んで PR を自動作成する address-pr-review PR のレビューコメントを自動取得して修正コミットと返信を実行し、得られた知見を LLM Wiki に蓄積する e2e Markdown 形式のテストシナリオに基づき、 agent-browser または chrome-devtools で E2E テストを実行しテスト結果を報告する auto-dev GitHub Issue を定期取得し、前述のスキルを使用して計画作成から PR 作成まで全自動で開発を進行する バイブ コーディング SDK「VibeBox」 VibeBox とは VibeBox は、非エンジニアであってもセキュアな環境でアプリケーションを開発し、Google Cloud へ安全に公開・運用できるようにする SDK です。 開発中の安全枠として前述の Exoloop を内包しているほか、クラウド環境へのデプロイやデータベース操作を MCP（Model Context Protocol）経由に限定することで、AI による誤操作や危険なインフラ変更を自動でブロックします。 参考 : Vibe Box — セキュリティ対策済みのバイブコーディング基盤 - Clickan Google Cloud の MCP サーバーについては、以下の当社記事で詳しく解説しています。 blog.g-gen.co.jp 登場人物と役割分担 VibeBox では、開発・運用において以下の役割分担がなされています。 役割 対象 概要 管理者 エンジニア推奨 セキュリティ対策が施された基礎インフラを Terraform 等で事前構築し、鍵情報（Service Account Key）を払い出す バイブコーダー 非エンジニア可 VibeBox を通じて AI と会話しながら、安全にアプリの構築・デプロイ・運用を行う 導入から運用の 3 フェーズ 構築フェーズ（管理者の作業） 管理者は Google Cloud プロジェクトを作成し、Terraform を使用して Cloud Load Balancing、Cloud Armor（WAF）、Identity-Aware Proxy（IAP）、VPC、Secret Manager、Cloud SQL などをセキュリティ設定済みの状態で構築します。生成された Service Account Key ファイルや設定情報をバイブコーダーへ渡します。 参考 : External Application Load Balancer (外部アプリケーションロードバランサ) を徹底解説！ 参考 : Cloud Armorを徹底解説。GoogleのフルマネージドWAF 開発フェーズ（バイブコーダーの作業） バイブコーダーは CLI コマンド apm install および setup を実行して環境を準備し、管理者から受け取った鍵を配置します。あとは会話ベースでアイデアを伝え、Exoloop と MCP ガードレールの保護下でバイブ コーディング、インフラの設定を進めます。 運用フェーズ（アクセス制御・運用操作） 本番稼働後は、Cloud Load Balancing → Cloud Armor → IAP によるエッジ防御が機能し、正規ユーザーのみを通し、DDoS 攻撃や SQL インジェクション、XSS などのサイバー攻撃を Google Cloud の手前で遮断します。また、運用操作も MCP ツールを通じて会話ベースで安全に行うことができます。 参考 : Identity-Aware Proxy(IAP)とCloud Armorを使用してCloud Runサービスへのアクセス制御を実装する 従来のバイブ コーディングと VibeBox の比較 従来の開発手法と VibeBox を導入した場合の比較は以下の通りです。 比較項目 従来のバイブ コーディング VibeBox インフラ構築 手作業で設定（設定漏れのリスク） Terraform で定義されたセキュアなインフラを自動構築 必要な知識 クラウドやアプリ開発の深い専門知識 Exoloop、MCP、定義済みインフラが知識を補完 セキュリティ 個人の知識・手作業に依存し設定漏れが生じやすい エッジ防御や最小権限、アプリ内セキュリティが標準適用 操作方法 Google Cloud や DB を直接操作するため誤操作リスクが高い MCP 経由で操作し、危険な操作は自動ブロック テナント分離 設定なし、アプリ間でのデータ混在リスクが存在 IAM、Cloud Run、DB 単位で明確に分離 関連記事 blog.g-gen.co.jp 高宮 怜 (記事一覧) クラウドソリューション部ソリューションアーキテクト課 2025年6月より、G-genにジョイン。前職は四国のSIerで電力、製造業系のお客様に対して、PM／APエンジニアとして、要件定義から運用保守まで全工程を担当。現在はGoogle Cloudを学びながら、フルスタックエンジニアを目指してクラウドエンジニアとしてのスキルを習得中。 Follow @Ggen_RTakamiya

G-gen の奥田です。当記事は、Google Cloud Next 26 Tokyo の1日目に行われたカスタマーセッション「 CDP だけで顧客理解は不十分？Google Cloud と生活者データで実現する「Why 分析」最前線 」のレポートです。 他の Google Cloud Next Tokyo 26 の関連記事は Google Cloud Next Tokyo 26 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 データはあるのに顧客が見えない データの量ではなく種類が足りない 再発する 5 つの症状 Why を補ってきた「勘と経験」の正体 5W1H を同時に読む力 勘と経験がもつ 3 つの限界 生活者データという「Why の辞書」と Why 分析の方法 Why の辞書とは ID 突合ではなく確率的な意味マッチング 処理の 4 ステップ 既存テーブルを変更せずに列が増える Google Cloud だから実現できた 3 つの発見 Google Cloud を選定した理由 実運用から得られた発見 発見 1: 直感を再現する VECTOR_SEARCH 発見 2: Gemini による出力品質の独立検査 発見 3: 承認済みルーティンによる双方の資産保護 Why 分析の先にあるもの AI の均質化とブランドらしさ 業種を越えた共通フレームワークへ 関連記事 セッションの概要 当セッションでは、株式会社博報堂による発表が行われました。CDP（Customer Data Platform、顧客データを個人単位で統合管理する基盤）だけでは捉えられない「顧客が行動した理由（Why）」を、生活者データと BigQuery の機能を組み合わせて補完する手法が紹介されました。 セッションは以下の 5 章で構成されていました。 データはあるのに顧客が見えない Why を補ってきた「勘と経験」の正体 生活者データという「Why の辞書」と Why 分析の方法 Google Cloud だから実現できた 3 つの発見 Why 分析の先にあるもの 当記事では BigQuery の基礎的な説明は割愛します。BigQuery そのものについては、以下の記事を参照してください。 blog.g-gen.co.jp データはあるのに顧客が見えない データの量ではなく種類が足りない セッション前半では、多くの企業が直面する課題として「データ量は十分にあるが、データの種類が足りていない」という点が提示されました。 CDP に記録されるのは、会員属性、購買履歴、行動ログ、解約記録といった「What（結果）」のデータです。一方、価値観、生活文脈、意思決定の傾向、不安や願望といった「Why（原因）」は、CDP のどこにも記録されません。登壇者はこれを氷山にたとえ、水面上に見えるのが What、水面下に隠れているのが Why であると説明しました。 たとえば「妥協して選んだ」という本音は、購買履歴という結果データからは読み取れません。同じ商品を買った顧客でも、買った理由は三者三様です。 再発する 5 つの症状 この構造的な欠落が原因となり、データを精緻化しても再発する症状として、以下の 5 つが挙げられました。 セグメントの画一化 メッセージの一律化 LTV（Life Time Value、顧客生涯価値）向上の頭打ち 静かな離反の見落とし 新規獲得の非効率 登壇者は、CDP や CRM（Customer Relationship Management、顧客関係管理システム）の整備自体は不可欠な土台であり、ID 統合、行動ログの蓄積、施策の自動化という期待された役割は果たしていると強調しました。問題は、CDP だけではカバーできない領域（なぜ買ったのか、なぜ離れたのか、なぜ選んだのか）が存在することです。 Why を補ってきた「勘と経験」の正体 5W1H を同時に読む力 これまで Why の欠落を埋めてきたのは、マーケターの「勘と経験」でした。セッションでは、その正体は「5W1H を同時に読む力」であると定義されました。 ベテランマーケターは、Who（どんな生活状況か）、When（いま何が起きそうか）、Where（どこで接点を持つか）、Why（なぜその選択か）、How（どう情報収集し選ぶか）を、過去事例の蓄積による暗黙のパターンマッチで同時に推論しています。たとえば「40 代男性が SUV を購入した」という購買データから、「家族の安全を重視する層である」と言い当てる、といった推論です。 勘と経験がもつ 3 つの限界 一方で、この勘と経験には 3 つの構造的な限界があると指摘されました。 スケールしない: 顧客一人ひとりに勘と経験を働かせるのは物理的に不可能 引き継げない: ベテランの退職は「顧客理解資産」の消失を意味する 共有できない: 「なんとなく刺さる」という判断では合意形成が属人的になる 生活者データという「Why の辞書」と Why 分析の方法 Why の辞書とは この課題に対する解決策として、博報堂が保有する生活者データを「Why の辞書」として使用し、マーケターの脳内プロセスを機械化する手法が紹介されました。材料となるのは、圧倒的な量の Why の語彙と、生活者インサイト（購買行動の背後にある価値観や動機）を推論する技術の 2 つです。 博報堂独自の観点として、価値観、動機、幸福感といった軸（たとえば購入時の価値観として、価格、幸せ、機能性など）が生活者データの中で 5W1H により体系化されています。 ID 突合ではなく確率的な意味マッチング 特徴的なのは、顧客データと生活者データを ID 突合（異なるデータベース間で共通の ID をキーにレコードを結合すること）ではなく「確率的な意味マッチング」で接続する点です。これにより以下の 3 点が実現されます。 個人を特定しない 既存の CDP をそのまま使用できる Cookie 規制（サードパーティ Cookie によるトラッキングの制限）の影響を受けにくい 処理の 4 ステップ 処理は以下の 4 ステップで構成されます。 翻訳: 企業ごとに異なる顧客 CDP の項目を、生活者データの共通言語にマッピングする 数値化: 顧客データと生活者データを「意味の座標」上に配置し、意味の近さを距離として比較できるようにする 検索: 生活者データの中から、意味的に最も近い人を選ぶ 特徴付与: 生活者データに近い特徴を顧客データにも付与する 既存テーブルを変更せずに列が増える この手法の利点は、既存の顧客テーブルを変更する必要がないことです。顧客 ID、属性、購買金額といった従来の列はそのままに、以下のような生活者インサイトの列が追加されます。 価値観（なぜ買うのか。指名買い、コスパ重視など） 意思決定傾向（どう選ぶのか。SNS 影響、即決型など） ライフスタイル（どう生きるのか。都市型ライフ、子育て重視など） 既存の顧客データ基盤が、そのまま顧客理解基盤へ進化するという表現が用いられました。 Google Cloud だから実現できた 3 つの発見 Google Cloud を選定した理由 博報堂独自の生活者データを AI 時代に使用するには 3 つの条件が必要であり、Google Cloud はそのすべてを満たすと説明されました。 意味の近さを計算できる BigQuery が標準機能としてベクトル検索（テキストなどを数値ベクトルに変換し、意味の近さで検索する仕組み）を備えています。 マーケターが直接触れる SQL やダッシュボードで完結し、ノーコードまたはローコードで操作できるため、マーケター自身が仮説をすぐ検証できます。 データを動かさない 顧客データは企業環境から一切出さず、顧客環境内で処理が完結します。 実運用から得られた発見 発見 1: 直感を再現する VECTOR_SEARCH セッション後半では、実運用から得られた発見として次の3点が紹介されました。1 つ目は、マーケターの直感を SQL で再現できたことです。「この人は、こんな価値観の人と似ているな」というベテランマーケターの頭の中の処理は、これまで言語化も再現もできない暗黙知でした。この処理を、BigQuery の標準機能である VECTOR_SEARCH 関数への変換（SQL Translation）によって再現しています。 これにより「意味の近さ」が可視化され、感覚でしかなかった判断を数字として表現できるようになりました。 参考 : ベクトル検索の概要 発見 2: Gemini による出力品質の独立検査 2 つ目は、出力品質を Gemini で独立検査する仕組みです。付与されたインサイトが施策の判断材料になる以上、品質に責任を持つ必要があります。人間による品質検査には量的な限界があるため、Gemini による5観点の独立評価を、品質保証レイヤーとして組み込んでいます。これは LLM ジャッジ（Large Language Model による評価）と呼ばれる、大規模言語モデルに出力の良し悪しを判定させる手法です。5 観点は以下のとおりです。 一貫性: 矛盾するタグがないか 妥当性: その人らしいか 網羅性: 必要な観点があるか 不足検出: タグの抜けはないか 実用性: マーケティング施策に使えるか 発見 3: 承認済みルーティンによる双方の資産保護 3 つ目は、データを守りながらロジックも守る仕組みです。顧客データは企業環境から一切出さない一方で、博報堂の推論ロジックも公開しません。この双方の資産保護を、BigQuery の承認済みルーティン（Authorized Routine）で実現しています。承認済みルーティンは、呼び出し元に定義内容を開示せず、実行権限のみを付与できる機能です。 参考 : 承認済みルーティン Why 分析の先にあるもの AI の均質化とブランドらしさ 最終章では、AI エージェントが購買の意思決定を担う時代の展望が語られました。購買が AI エージェント経由になるほど、効率最適化により「どのブランドも同じ答え」に収束するリスク（AI の均質化）があります。 エージェントが最適解を出す時代では、生活者の「なぜ（Why）」への深い理解こそがブランドらしさの源泉であり、ブランドに求められるのは最適化ではなく「選ばれる理由」を持ち続けることである、と締めくくられました。 業種を越えた共通フレームワークへ また、この設計様式は博報堂だけの話ではない、という点も強調されました。ID 突合に依存しないポストクッキー時代（サードパーティ Cookie が使えなくなる時代）のマーケティング手法として、また「データを動かさず、処理を動かす」という厳格なデータガバナンス下で AI 利用を進めるための共通フレームワークとして、規制業界を含むデータを持つすべての企業に波及していくという展望が示されました。対象業種の例として、小売、金融、通信、旅行、メディアが挙げられました。 関連記事 blog.g-gen.co.jp 奥田 梨紗 (記事一覧) クラウドソリューション部データインテリジェンス課 Google Cloudの可能性に惹かれ、2024年4月G-genにジョイン。 Google Cloud Partner Top Engineer 2025&2026 Follow @risa_hochiminh

G-gen の今村です。当記事は、Google Cloud Next Tokyo 26 の2日目に行われた Google セッション「 Gemini Enterprise Agent Platform 入門！進化した次世代エージェント構築基盤の全貌 」のレポートです。 他の Google Cloud Next Tokyo 26 の関連記事は Google Cloud Next Tokyo 26 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 Gemini Enterprise Agent Platform とは サービス提供の背景 機能の全体像 Build（構築） 概要 Model Garden Agent Studio Agent Development Kit その他の開発ツール Scale（スケーリング） 概要 Agent Runtime Agent Sandbox Session と Memory Bank Govern（管理） 概要 Agent Registry Agent Gateway Agent Identity Governance Policies Optimize（最適化） 概要 OpenTelemetry Agent Observability Traces と Tool Usage Evaluation（評価） 概要 評価アプローチ オフライン評価とオンラインモニタリング まとめ 関連記事 セッションの概要 当セッションでは、Google Cloud における次世代の AI エージェント構築基盤である Gemini Enterprise Agent Platform の全体像や各機能レイヤー、および主要な機能群についての発表と解説が行われました。 当セッションは、Google Cloud の AI 技術統括本部 アプライド AI エンジニアである牧氏によって行われました。 Gemini Enterprise Agent Platform とは サービス提供の背景 企業で AI エージェントを構築し使用する際、開発者と使用部門の間で溝が生じるケースがあります。例えば「特定部門のために開発されたエージェントが使われない」「想定した業務用途に合致しない」といった課題です。 AI エージェント導入のハードル Gemini Enterprise Agent Platform は、このような課題を解消する目的で提供されました。開発者と使用者の双方にとっての使いやすさを追求し、エンタープライズ要件に応えるエージェントプラットフォームとして設計されています。 参考 : Agent Platform の概要 Gemini Enterprise Agent Platform の立ち位置 Gemini Enterprise Agent Platform の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp 機能の全体像 Gemini Enterprise Agent Platform は、あらゆるシナリオに対応可能なオープンで包括的な基盤として位置づけられています。 機能は大きく分けて4つのレイヤーで構成されています。 Build （構築） Scale （スケーリング） Govern （管理） Optimize （最適化） また、これら4つのレイヤーによるライフサイクル運用に加え、デプロイ前後におけるエージェントの品質や応答精度を担保するための Evaluation （評価）アプローチを組み合わせて使用します。 参考 : Agent Platform の概要 - Gemini Enterprise Agent Platform のコンポーネント 4つのレイヤー Build（構築） 概要 Build（構築）レイヤーは、AI エージェントの迅速な開発と検証を支える仕組みです。多様な技術スタックや開発手法に対応できるよう、オープンソースのフレームワーク、最先端のモデル、およびローコードからハイコードまでの開発環境を選択できます。開発者のスキルセットやプロジェクトの要件に応じた柔軟な開発を可能にします。 参考 : Agent Platform の概要 - 構築 Gemini Enterprise Agent Platform を使用する理由 Model Garden Model Garden を通じて、Google の最新 Gemini モデルをはじめ、サードパーティ製のモデルやオープンモデルなどを柔軟に選択して使用できます。 参考 : Model Garden の概要 Model Garden Agent Studio Agent Studio は、コンソール画面（GUI）から直感的にエージェントを作成する機能です。 Python などのプログラミング知識がない場合でも、自然言語でディスクリプションやインストラクション（動作指示）を記述するだけでエージェントを構築できます。Google 検索ツールとの連携や、作成したエージェントのテストからデプロイまでを同一画面内で完結できます。 参考 : Agent Studio の概要 AI エージェント開発の選択肢 Agent Development Kit Agent Development Kit （以下、ADK）は、さまざまなプログラミング言語に対応したオープンソースのフレームワークです。 学習コストを抑えつつ、Google Cloud 上でオープン性を重視したエージェント開発が可能です。 参考 : Agent Development Kit Agent Development Kit その他の開発ツール コードファーストでの開発や自動化を支援するため、以下のツールが用意されています。 Agents CLI コマンドラインからエージェントのライフサイクル管理や Skills の実行を行うツールです。 参考 : Agent Platform で ADK と Agents CLI を使用してエージェントを構築する Agents CLI Antigravity エージェントと会話しながらコーディングを進められる開発・自動化プラットフォームです。 参考 : Google Antigravity Antigravity Managed Agents API セキュアなサンドボックス環境からエージェントを直接呼び出すための API です。 参考 : Agent Platform の Managed Agents API の概要 Managed Agents CLI Scale（スケーリング） 概要 Scale（スケーリング）レイヤーは、ローカル環境で作成されたエージェントを全社規模の運用へ適応させるための基盤です。サーバーレスなデプロイ環境やセキュアなサンドボックスにより、トラフィック負荷に耐えうるインフラの自動スケーリングを実現します。また、高度なコンテキスト（会話履歴や記憶）管理機能を備えています。 参考 : Agent Platform の概要 - スケーリング Scale の概要 Agent Runtime Agent Runtime は、エージェントのインスタンスをサーバーレス環境にデプロイし、自動スケーリングや運用管理を担う機能です。ノーコードで作成されたエージェントと、コードベースの複雑なエージェントまで幅広く対応します。呼び出しプロセスやパラメータを一元的に可視化・追跡できるため、組織内で把握されない「野良エージェント」の乱立リスクを抑えられます。 参考 : エージェント ランタイム Agent Runtime の概要 Agent Runtime の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp Agent Sandbox Agent Sandbox を使用することで、セキュアでカスタマイズ可能な実行環境を用意できます。GUI ベースの自動化ワークフローなどを安全に検証・実行できます。 参考 : サンドボックスの概要 Agent Sandbox の概要 Session と Memory Bank 業務でエージェントを使用する場合、1回の応答で処理が完了することは少なく、会話のコンテキスト保持が重要となります。 Session （セッション）と Memory bank （メモリーバンク）機能により、短期記憶と長期記憶を、それぞれフルマネージドなデータストアに保存できます。ユーザーごとの参照データや属性情報を考慮した、柔軟な応答を実現します。 参考 : Agent Platform セッションの概要 参考 : Agent Platform メモリバンク Session と Memory Bank Govern（管理） 概要 Govern（管理）レイヤーは、エンタープライズに要求されるセキュリティ、コンプライアンス、ID 管理を一括制御する層です。管理用レジストリやセキュリティポリシーを適用し、情報漏洩や不正アクセスのリスクを極小化しながら、組織全体での安全なエージェント使用を統制します。 参考 : Agent Platform の概要 - 管理 ガバナンスを遵守するための全体アーキテクチャ Agent Registry Agent Registry は、デプロイ前のコアエージェントや Model Context Protocol（以下、MCP）サーバーを一元管理する機能です。サードパーティ製コンポーネントの登録にも対応しており、不正なエージェントやコストが高騰している設定を一覧画面から早期に識別できます。 参考 : Agent Registry Agent Registry の概要 Agent Registry の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp Agent Gateway Agent Gateway は、外部システムや社内サービスからのトラフィックを集約・管理するエンドポイントです。トラフィックの入り口を統一することで、リソース制御や認証管理を効率化できます。 参考 : Agent Gateway の概要 Agent Gateway の概要 Agent Gateway の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp Agent Identity Agent Identity は、エージェントに対してセキュアで一意な識別子（ID）を付与・管理する機能です。部署をまたいだデータ参照を行う際も、定義されたアクセス制御に基づいて情報資産を守ります。 参考 : エージェント ID の概要 Agent Identity の概要 Agent Identity の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp Governance Policies Governance Policies は、Google Cloud の Identity and Access Management（以下、IAM）の権限体系と連携して動作する制御機能です。Agent Runtime 等にホストされたエージェントへのアクセス権限は、Agent Gateway を通じて、Governance Policies により制御されます。 参考 : ポリシーの概要 Governance Policies の概要 Google Cloud の IAM については、以下の記事を参照してください。 blog.g-gen.co.jp 本セッションのデモでは、住宅ローン審査のアシスタントエージェントが例として挙げられました。個人情報を含むメールを外部送信しようとした際、権限不足により不許可となる挙動が確認できました。環境内では Model Armor 等のセキュリティ機能と組み合わせ、システム的に個人情報をブロックする設計が施されています。 参考 : Model Armor の概要 Governance Policies の使用例 Model Armor の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp Optimize（最適化） 概要 Optimize（最適化）レイヤーは、本番環境で稼働する AI エージェントの運用コスト、パフォーマンス、および応答の正確性を計測・制御するための層です。トレースやログ分析を通じて、不要なモデル呼び出しによるコストの抑制や、レイテンシ障害の迅速な検知・解析が可能です。 参考 : Agent Platform の概要 - 最適化 OpenTelemetry オープンな標準規格である OpenTelemetry に準拠しており、世界基準に則ったテレメトリーデータ収集を実装できます。 参考 : OpenTelemetry とは OpenTelemetry の概要 Agent Observability Agent Observability は、Cloud Logging や Cloud Storage へ各種運用データを保存し、モニタリングを行う機能です。短文要約のような簡易タスクに対して、オーバースペックな高コストモデルが呼び出されていないかなどを可視化・管理します。 参考 : オブザーバビリティの概要 参考 : Cloud Logging の概要 参考 : Cloud Storage のプロダクト概要 Agent Observability の概要 Cloud Logging の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp Cloud Storage の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp Traces と Tool Usage Traces 機能により、処理のボトルネックやアクセススパイクを分析できます。併せて、呼び出されたツールやモデルを Tool Usage 画面で確認し、想定外の動作が発生していないかを検証可能です。 参考 : エージェントのトレースを表示する Traces の概要 Traces の Tool Usage 機能 Evaluation（評価） 概要 Evaluation は、エージェントが出力する回答の正確性や定義した業務フローの遵守状況を、客観的・定量的に分析するための仕組みです。テスト段階の事前評価と運用中のリアルタイム監視を組み合わせることで、ハルシネーション（誤回答）や品質の低下を未然に防ぎます。 参考 : エージェントの評価 エージェントの成功指標を計測 評価アプローチ エージェントの出力品質を定量化するため、主に以下の3つのアプローチを組み合わせて検証を行います。 ルールベース評価 あらかじめ定義した制約ルール（必須キーワードや指定の出力フォーマットなど）に適合しているかを自動判定します。 LLM-as-Judge 評価 評価用として調整された大規模言語モデル（LLM）を判定者として用い、回答文の定性的な妥当性や文脈の論理性を自動スコアリングします。 適応型（Adaptive Rubrics）評価 評価基準（ルーブリック）を段階的に配置し、特定の処理ステップごとに期待されたビジネスロジックに従っているかを動的に評価します。 評価アプローチ 適応型ルーブリック オフライン評価とオンラインモニタリング 評価の実行環境として、デプロイ前後に最適化された以下の機能が備わっています。 GenAI Evaluation Service（オフライン評価） デプロイ前のテストフェーズにおいて、準備したデータセットと定義したルーブリックを基に一括で評価処理を実行します。 Offline 評価 GenAI Evaluation Service の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp Agent Evaluation / Online Monitors（オンライン評価） 稼働中の対話データを継続的にモニタリングする機能です。エージェントがツールを呼び出した順番などの実行軌跡（Traces）をトラッキングし、運用中の応答精度や制御状態をリアルタイムで追跡します。 Online Monitors 参考 : Gen AI Evaluation Service の概要 参考 : エージェントの評価 まとめ Gemini Enterprise Agent Platform の概要をはじめ、AI エージェントの開発・運用に不可欠な「Build（構築）」「Scale（スケーリング）」「Govern（管理）」「Optimize（最適化）」の各機能群の要点を解説して、本セッションは締めくくられました。 まとめ なお、今回のセッション内容には Gemini Enterprise（Gemini Enterprise app）の解説は含まれていません。Gemini Enterprise の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp 関連記事 blog.g-gen.co.jp 今村 壱生 (記事一覧) クラウドソリューション部 ソリューションアーキテクト課 2026年3月にG-genへ入社。約7年間 Web 広告運用やウェブ解析に携わり、その後は社内 SE として開発業務に従事。広告運用の現場感と技術的な視点、その双方を併せ持つ経験をベースに、現在は Google Cloud のスキルアップに注力。データ活用とクラウド技術を融合させ、お客様のビジネス成長を支えるエンジニアを目指している。 Follow

G-gen の杉村です。2026年7月に発表された、Google Cloud や Google Workspace のイチオシアップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに Google Cloud Next Tokyo 26 の開催 Google Cloud のアップデート Bigtable で Google フロントエンドをバイパスする Direct connectivity が登場 Gemini Enterprise app で東京リージョン（asia-northeast1）がサポート Cloud Run でサブプロセスとしてのサンドボックス環境が Preview 公開 C4N マシンシリーズが一般公開 BigQuery で多段階集計（Multi-level aggregation）が記述可能に（Preview） BigQuery の予約の Project caps（scheduling policies）が Preview BigQuery Conversational Analytics で AI.AGG 関数が使用可能に Google Skills 受講で資格の1年間延長が可能に Cloud NGFW Enterprise ティアで WildFire によるマルウェア検知が Preview Cloud SQL の Data API（executeSql）で Secret Manager 認証が可能に 「Gemini 3.6 Flash」と「Gemini 3.5 Flash-Lite」が公開（GA） コードセキュリティエージェント「CodeMender」が Preview 提供開始 AlloyDB for PostgreSQL で Transparent query forwarding が Preview 公開 利用料金に上限を設ける Spend cap budget が Public Preview 公開 BigQuery で追加・変更履歴を確認できる APPENDS/CHANGES関数が一般公開 AlloyDB で書き込みエンドポイントが Preview 公開 AlloyDB でクロスリージョンフェイルオーバーが Preview 公開 Dataform で Deployments 機能が Preview 公開 Google Cloud の Agent Platform で Feedback service が Preview 公開 Gemini 2.5 系モデルが Extended Lifecycle Access（ELA）扱いに Global external passthrough Network Load Balancer が Preview 公開 Google Workspace のアップデート Google Vids で Google スライドの動画へのAI変換機能が日本語に対応 Google Workspace でインバウンド SCIM API が一般公開（GA） Google Chat で組織外ユーザーとのグループ DM が使用可能に Google スプレッドシートが「集合縦棒 - 折れ線」などのグラフタイプに対応 Google Meet で録画や議事メモが会議ごとのサブフォルダに整理されるように Google Meet の自動メモ作成で投影物のスクリーンショット保存されるように Google ドキュメントで、画像、図、インフォグラフィックを生成可能に Google Forms で自然言語指示によるクイズ自動生成が可能に はじめに 当記事では、毎月の Google Cloud（旧称 GCP）や Google Workspace（旧称 GSuite）のアップデートのうち、特に重要なものをまとめます。 また当記事は、Google Cloud に関するある程度の知識を前提に記載されています。前提知識を得るには、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp リンク先の公式ガイドは、英語版で表示しないと最新情報が反映されていない場合がありますためご注意ください。 Google Cloud Next Tokyo 26 の開催 Google Cloud の年次旗艦イベントの東京版、Google Cloud Next Tokyo が、東京ビッグサイトにおいて7月29日（木）から30日（金）までの2日間、開催された。 スポンサーによるエキスポエリアでの展示や、キーノート（基調講演）、各種ブレイクアウトセッション、スポンサーセッションなどが行われ、国内での AI エージェント事例などが発表された。 キーノート（基調講演）については、以下の記事を参照されたい。 blog.g-gen.co.jp Google Cloud のアップデート Bigtable で Google フロントエンドをバイパスする Direct connectivity が登場 Direct connectivity (2026-07-06) Bigtable で Google フロントエンドを介さずにバックエンドへ直接通信する「直接接続（Direct connectivity）」が利用可能に。 VPC 内の VM からの通信、かつ特定条件を満たすトラフィックに適用されネットワークのホップ数が減り、レイテンシ低減とスループットが向上。 Gemini Enterprise app で東京リージョン（asia-northeast1）がサポート Gemini Enterprise release notes - July 06, 2026 (2026-07-06) Gemini Enterprise app および NotebookLM Enterprise で、東京（asia-northeast1）と英国（europe-west2）リージョンがサポート。 ただし Allowlist 付き一般公開（GA with allowlist）のため申請が必要。 これにより、データの保管（DRZ）と機械学習の処理（MLP）を日本国内のインフラで完結できる。Gemini 3.5 Flash モデルも対象に含まれる。 Cloud Run でサブプロセスとしてのサンドボックス環境が Preview 公開 Configure sandboxes for services (2026-07-08) Cloud Run サービスで、サブプロセスとしてサンドボックス環境を起動し AI エージェントツールや信頼できないコードを実行できる機能が Preview 公開。 メインのアプリから分離して動的なコード実行が可能。以下の解説記事も参照。 blog.g-gen.co.jp C4N マシンシリーズが一般公開 C4N machine series (2026-07-08) Compute Engine で C4N マシンシリーズが一般公開。C4N は、ネットワーク最適化マシンシリーズ。 スペック 第5世代 Intel Xeon Scalable processors（Emerald Rapids）を搭載 ネットワーク帯域 最大 400 Gbps ストレージ I/O 最大 25 GiB/s、1M IOPS （Hyperdisk Extreme） ユースケース ネットワーク・セキュリティアプライアンス 高性能データベース 大規模データ分析 分散ファイルシステム BigQuery で多段階集計（Multi-level aggregation）が記述可能に（Preview） Multi-level aggregation (2026-07-08) BigQuery の SQL で多段階集計（Multi-level aggregation）が記述可能になった（Preview）。集計関数の引数に別の集計関数を入れられる。 サブクエリや CTE を使わず、単一の SELECT 句で記述可能になり、クエリが簡素化する。以下はクエリのサンプル。 SELECT Product, AVG ( SUM (revenue) GROUP BY DATE (time)) AS avg_daily_sales FROM Sales GROUP BY Product ORDER BY Product; BigQuery の予約の Project caps（scheduling policies）が Preview Project caps and scheduling policies (2026-07-13) BigQuery の予約（Reservation）で、プロジェクト単位で最大スロット使用量と同時実行数（並列度）を制限できる Project caps（scheduling policies）が Preview 提供開始。 特定プロジェクトによるリソースの独占を防ぎワークロードの優先順位付けが可能になる。 BigQuery Conversational Analytics で AI.AGG 関数が使用可能に BigQuery AI and ML support (2026-07-14) BigQuery の Conversational Analytics（会話型分析）で AI.AGG 関数が使用可能になった。 AI.AGG は「意味論的な集計」とでもいえる機能で、マルチモーダルなデータを要約したり分析して文字列を返す関数。画像分析、コンテンツ要約、ログ分析などに使用できる。AI.AGG 関数自体はまだ Preview 公開である点に留意が必要。 Google Skills 受講で資格の1年間延長が可能に Google Cloud 認定資格を最新の状態に保ち、キャリアアップを図る新しい方法 (2026-07-15) Google Cloud 認定資格に、新しい更新方法が登場。 従来は試験を受験する必要があったが一部の資格は Google Skills（オンラインラボ）の所定コース受講でも更新（1年間延長）できるようになった。CDL、ACE、PCA、PDE がこの更新方法に対応している。 Cloud NGFW Enterprise ティアで WildFire によるマルウェア検知が Preview WildFire overview (2026-07-20) Google Cloud の Cloud NGFW Enterprise ティアで Palo Alto の脅威分析サービス「WildFire」によるマルウェア検知が Preview 提供開始。 サンドボックスとリアルタイム機械学習を組み合わせ VPC を通過するファイル転送を詳細に検査。ゼロデイ攻撃にも対応可。 Cloud SQL の Data API（executeSql）で Secret Manager 認証が可能に データベース ユーザーを構成する (2026-07-20) Cloud SQL for PostgreSQL/MySQL の Data API（executeSql）で Secret Manager による認証が可能になった。 Data API（executeSql）とは、Cloud SQL Admin API 経由で SQL を実行できる機能。 データベースのパスワードを Secret Manager のリージョンシークレットに保存しておき、API リクエスト時にそのリソース名を渡すことで認証。これにより、アプリケーション側でパスワードを保持する必要がなくなり、認証情報の漏洩リスク低減と管理の簡素化に繋がる。 「Gemini 3.6 Flash」と「Gemini 3.5 Flash-Lite」が公開（GA） Introducing Gemini 3.6 Flash, 3.5 Flash-Lite, and 3.5 Flash Cyber (2026-07-21) Google が新しい AI モデル「Gemini 3.6 Flash」と「Gemini 3.5 Flash-Lite」を公開（GA）。 コード生成やマルチモーダル推論の精度などが向上したほか、Flash については 3.5 よりもトークン効率が向上したとされる。top-K、top-P パラメータは使用できなくなった。レスポンスも高速化された印象。 また Google が「Gemini 3.5 Flash Cyber」を発表。脆弱性の発見、検証、パッチ適用を行うサイバーセキュリティモデル。limited-access pilot program として政府機関および信頼できるパートナー企業のみに提供される。 コードセキュリティエージェント「CodeMender」が Preview 提供開始 Now in preview: Find and fix software vulnerabilities with CodeMender (2026-07-22) Google がコードセaキュリティエージェント「CodeMender」を Preview 提供開始。 CI/CD パイプラインや IDE との統合や CLI を通じ、脆弱性の検知、修復、パッチ適用を補助。 AlloyDB for PostgreSQL で Transparent query forwarding が Preview 公開 Optimize resources and isolate read queries with transparent query forwarding (2026-07-20) AlloyDB for PostgreSQL で Transparent query forwarding が Preview 公開。 プライマリノードへの読み取りクエリが、自動的にリードプールインスタンスにフォワードされ、負荷分散される。アプリ側でエンドポイントを意識せずとも読み取り負荷の分散が可能になる。 従来は、 書き込みワークロードはプライマリインスタンス（書き込み/読み取り IP アドレス）へ、読み取りワークロードはリードプールインスタンス（読み取り IP アドレス）へ、それぞれ差し向ける必要があった。今後（Transparent query forwarding 使用）は、Transparent query forwarding を有効化して、すべてのクエリをプライマリインスタンスへ投入するだけでよくなる。 利用料金に上限を設ける Spend cap budget が Public Preview 公開 Manage spend cap budgets (2026-07-27) Google Cloud の利用料金に上限を設ける Spend cap budget が Public Preview 公開。予算を超過した際に新規リクエストを停止してそれ以上の課金を防止できる。 対応サービスは Gemini API、Agent Platform、Cloud Run、Cloud Run functions。 ただし重要な制限として、Google Cloud パートナー経由の請求先アカウントで 当機能は使用できない 。 2026年7月下旬現在、実際には使用できてしまっているが、今後修正され使用不可になる見込み。 BigQuery で追加・変更履歴を確認できる APPENDS/CHANGES関数が一般公開 Work with change history (2026-07-27) BigQueryでテーブルの追加・変更履歴を確認できる APPENDS() 関数、 CHANGES() 関数が一般公開（Preview → GA）。 それぞれ、指定期間内に追加された行 / 変更された行の一覧を返す関数。データパイプラインの増分更新やデータ監査に有用。CHANGES 関数は事前にテーブルでオプションを有効化する必要あり。 AlloyDB で書き込みエンドポイントが Preview 公開 Manage database connections with write endpoints (2026-07-27) AlloyDB で書き込みエンドポイントが Preview 公開。プライマリインスタンスを指すDNS名。 任意のインスタンスを指すよう設定できるため、バックアップから新規インスタンスを起動した際等も、アプリ側の構成変更が不要なまま新しい向き先を指定できる DB 移行の際にも使用できる。 AlloyDB でクロスリージョンフェイルオーバーが Preview 公開 Advanced disaster recovery (2026-07-27) AlloyDB でクロスリージョンフェイルオーバーが Preview 公開。 セカンダリクラスタをプライマリに昇格した際、旧プライマリの再構築を自動化し、レプリケーション構成を維持することが可能。従来は必要だったクラスタの手動削除や再作成が不要になる。 Dataform で Deployments 機能が Preview 公開 Create and manage deployments (2026-07-27) Dataform で Deployments 機能が Preview 公開。 リモート Git リポジトリ上のコードをスケジュール実行する機能。従来より対応する GitHub、GitLab、Bitbucket、Azure DevOps Services などに格納する SQLX ソースコードを直接呼び出して実行できる。 Google Cloud の Agent Platform で Feedback service が Preview 公開 Feedback service overview (2026-07-29) Google Cloud の Agent Platform で Feedback service が Preview 公開。 Agent Runtime の session と紐づけてユーザーフィードバック（サムズアップ、ダウン）を送信。Google Cloud コンソールでも結果を閲覧できる。 Gemini 2.5 系モデルが Extended Lifecycle Access（ELA）扱いに Model versions and lifecycle (2026-07-30) Google からの管理者宛て通知で、Gemini 2.5 Pro、Flash、Flash Liteが 2026-10-20 から Extended Lifecycle Access (ELA) に入ることが通知された。ただし、ELA についてはドキュメントに記載がなく、通知メールのみ。 モデルが ELA 期間に入ると、値上げされる代わりに継続利用できる。移行先として推奨されるモデルがドキュメントに掲示されている。 Global external passthrough Network Load Balancer が Preview 公開 Cloud Load Balancing release notes - July 31, 2026 (2026-07-31) Global external passthrough Network Load Balancer が Preview 公開。 external passthrough なロードバランサーはこれまで Regional しかなかった。TCP/UDP に加え、ESP や GRE、ICMP など多様なプロトコルに対応。 Google Workspace のアップデート Google Vids で Google スライドの動画へのAI変換機能が日本語に対応 Convert your Google Slides to videos in 7 additional languages (2026-07-08) Google Vids で Google スライドの動画へのAI変換機能が日本語に対応。これまでは英語のみだったが、今回、日本語、フランス語、ドイツ語、イタリア語、韓国語、ポルトガル語、スペイン語にも対応した。 当機能は、スライド資料から台本、ナレーション、BGM、アニメーションを含む動画を自動生成するもの。Google Workspace Business Starter 以上が必要。 Google Workspace でインバウンド SCIM API が一般公開（GA） Streamline identity lifecycle management in Google Workspace with new inbound SCIM support (2026-07-09) Google Workspace でインバウンド SCIM API が一般公開（GA）。 外部の IdP や人事システムからディレクトリ情報をリアルタイムで同期可能。同期されたグループを Google Workspace 側で編集できないようにロックする機能等も備わる。ID 管理運用の簡素化に繋がる。 Google Chat で組織外ユーザーとのグループ DM が使用可能に Now available: group conversations with external collaborators in Google Chat (2026-07-15) Google Chat で、組織外のユーザーを交えたグループダイレクトメッセージ（DM）の作成が可能になった。 これまで外部ユーザーとのコミュニケーションは、1対1のDMか「スペース」の作成に限定されていたが、このアップデートにより、複数の外部メンバーを含むグループ DM を開始できる。外部メンバーがいるグループには視覚的なバッジが表示される。 Google スプレッドシートが「集合縦棒 - 折れ線」などのグラフタイプに対応 Import and create combo charts in Google Sheets (2026-07-20) Google スプレッドシートが「集合縦棒 - 折れ線」や「第 2 軸を使用した集合縦棒 - 折れ線」などのグラフタイプに対応。 Excel からインポートする際の互換性向上にもなる。 Google Meet で録画や議事メモが会議ごとのサブフォルダに整理されるように Import and create combo charts in Google Sheets (2026-07-20) Google Meet で、録画や議事メモが会議ごとのサブフォルダに整理されるようになった。定期会議の出力は同じフォルダに作成される。 フォルダにアクセス権限をつけておけば毎回録画を共有する必要がなくなるなどのメリットがあると想定される。 2026-07-22 より順次展開。 Google Meet の自動メモ作成で投影物のスクリーンショット保存されるように Visual screenshots in Google Meet meeting notes will soon be generally available, pre-configure admin settings in advance (2026-07-27) Google Meet の自動メモ作成（Take notes for me）で投影されたスライドなどのスクリーンショットがメモ内に保存されるようになる。 ただし機能の展開は2026年第3四半期（10月〜）が予定されている。許可の粒度を決める管理者設定のみ、既に公開されている。 Google ドキュメントで、画像、図、インフォグラフィックを生成可能に Generate and edit visuals with Gemini in Google Docs (2026-07-28) Google ドキュメントの Gemini サイドパネル/下部バーで、画像、図、インフォグラフィックを生成できるようになった。 編集画面を離れることなく文章に付随するビジュアルを生成できる。画像の編集も可能。2026-07-28から15日程かけて段階的にロールアウト。 Google Forms で自然言語指示によるクイズ自動生成が可能に Use Gemini in Google Forms to quickly create a new quiz (2026-07-30) Google Forms で、自然言語で指示することで Gemini がクイズを自動生成。 Google ドライブ上のドキュメント、スライド、PDF などを情報源として、理解度チェッククイズなどを生成できる。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の今村です。当記事は、Google Cloud Next 26 Tokyo の1日目に行われたカスタマーセッション「 ツール導入ではない、企業のスタイルを創る「AI 戦略」としての Gemini Enterprise 」のレポートです。 他の Google Cloud Next Tokyo 26 の関連記事は Google Cloud Next Tokyo 26 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 AI イノベーションラボの取り組みと背景 業務への AI の組み込み 自作 AI ツールの展開と終了 Gemini Enterprise の選定理由 検索精度とガバナンス要件 サードパーティ製品との連携 具体的な活用事例 事例1 : オンボーディングの効率化 事例2 : 上長の簡易クローンの作成 事例3 : Deep Research を用いた社内情報の統合 AI の使用状況と分析 高いアクティブユーザー率の維持 使用状況の可視化とスタイル分析 今後の展望 業務プロセスの変革と AI との協働 ツール導入で終わらせないために 関連記事 セッションの概要 当セッションでは、Ｓｋｙ株式会社の社内における AI 活用の試行錯誤や、Gemini Enterprise を活用した業務プロセスの変革事例について発表されました。 Gemini Enterprise については、以下の記事を参照してください。 blog.g-gen.co.jp 参考 : Gemini Enterprise とは何ですか？ AI イノベーションラボの取り組みと背景 業務への AI の組み込み AI イノベーションラボ部門は、業務の中に AI を組み込むための部隊として活動しています。これまでに200ものシステムを開発し、社内で試行錯誤を続けています。取り組みの初期段階では、AI が組み込まれていることに気づかれないケースもあり、効率化や売上向上への貢献が見えづらいという課題がありました。 AI 導入への問題提起 自作 AI ツールの展開と終了 2022年に AI アプリケーションが使用可能になり、社内での活用検討が始まりました。内製を好む組織文化を背景に、「SKYAI」と呼ばれるツールや「SkyDeepResearch」の機能が独自に開発されました。これらのツールは常に使用される状態となり、主に管理職を中心に使用が拡大しました。 内製 AI の社内浸透 SKYAI の概要 AI を日常的に使う土台を作るため、調べ物の前に AI を配置したり、モバイル端末を貸与して OCR に対応させたりといった導線作りが行われました。さらに、プロンプトエンジニアリングの研修を実施し、AI 自身がプロンプトを評価して改善案を提示する機能も導入されました。これらの仕組みにより、ナレッジがフィードとして共有される環境が構築されました。 一方で、開発したツールを保守し続けることは、次のステップへ進む際の阻害要因になると判断されました。そのため、戦略的に SKYAI を終了させました。 SKYAI の戦略的終了 Gemini Enterprise の選定理由 検索精度とガバナンス要件 SKYAI の終了後、経営陣の意向を踏まえて新しい AI ツールとして Gemini Enterprise が選定され、全社員に一斉配布されました。選定の大きな理由の一つは、検索精度の高さです。自社のデータと組み合わせた際の検索精度が優れていることが、重要な評価ポイントとなりました。 Gemini Enterprise の導入開始 また、エンタープライズ向けのガバナンス要件を満たしていることも決め手となりました。生成 AI の成果物を知的財産としてビジネスに使用するためには、情報の保護などの要件に応える必要がありました。Gemini Enterprise は拡張性や安全性が高く、外部公開を制限する要件にも対応できるため、導入リスクが低いと判断されました。 Gemini Enterprise の選定理由 サードパーティ製品との連携 同社では Google Workspace を導入していませんでしたが、Gemini Enterprise は Microsoft などの他社製品（サードパーティ製品）との連携に寛容であったため、これが導入の障壁にはなりませんでした。 参考 : サードパーティのデータソースを接続する 具体的な活用事例 事例1 : オンボーディングの効率化 AI は、社内のオンボーディングにも活用されています。新しくチームに加わったメンバーにとって、大量の資料を読み込むことは負担であり、理解度にばらつきが生じるという課題がありました。 この課題を解決するため、部署ごとに整理した社内情報を Gemini Notebook に読み込ませ、学習ガイドを作成しました。これにより、新メンバーが自律的に学習を進められるようになり、早期の立ち上がりが実現しました。また、AI が読み取りやすい形式を意識してナレッジを蓄積する文化も生まれました。 事例1 Gemini Notebook については、以下の記事を参照してください。 blog.g-gen.co.jp blog.g-gen.co.jp 事例2 : 上長の簡易クローンの作成 業務の効率化を目的として、Agent Builder を使用した「上長の簡易クローン」が作成されました。社内ブログなどでアウトプットを行う文化を活かし、上長の判断基準や思考プロセスを学習させています。 メンバーがマークダウン形式でまとめた相談事項に対し、この簡易クローンが一次レビューを行います。これにより、あらかじめ指摘されそうな点をメンバー自身が改善できるようになり、上長の確認時間も短縮され、業務プロセスそのものの改善に繋がりました。 事例2 Agent Builder については、以下の記事を参照してください。 blog.g-gen.co.jp 事例3 : Deep Research を用いた社内情報の統合 社内に特化した AI 活用研修の調査において、情報の分散が課題となっていました。そこで Deep Research の機能を導入し、社内の蓄積情報と Web 検索の結果を掛け合わせる仕組みを構築しました。これにより、他社事例を単に模倣するのではなく、自社に最適なプランを効率的に作成できるようになりました。 事例3 参考 : Gemini Enterprise の概要 AI の使用状況と分析 高いアクティブユーザー率の維持 Gemini Enterprise 導入後、アクティブユーザー率は98%という非常に高い水準を維持しています。これは、社員が AI を一過性のツールとしてではなく、日々の業務に不可欠なものとして認識していることを示しています。ほぼすべての社員が継続的に AI を使用しています。 アクティブユーザー数 使用状況の可視化とスタイル分析 社員がどの程度 AI を使いこなせているかを把握するため、「スタイル分析」が行われています。スライド作成や提案書作成など、複数の AI ツールの使用状況を統合し、一つの基準で評価できる可視化ツールが内製されました。 この分析データをもとに、AI を活用できていない層に対して原因を特定し、アプローチを行うサイクルが確立されています。 スタイル分析 今後の展望 業務プロセスの変革と AI との協働 AI の活用は、ツールの導入にとどまらず、業務プロセスや組織のカルチャーを変革する段階に入っています。今後は、エンジニアリングの強化やオントロジーを用いたデータ形成により、さらなるカスタマイズが進められる予定です。 ここでいうオントロジーとは、社内のデータや知識の「概念と関係性」を定義・体系化する仕組みのことです。単に社内ドキュメントを蓄積するだけでなく、データ同士のつながりや定義を整理して AI に読み込ませることで、AI が社内文脈をより正確に理解し、高精度な回答や自律的なタスク処理を行える環境を目指しています。 AI Native への変革 また、AI が社員のプラットフォームに参加し、チャットのログから社員の困りごとを能動的に抽出するような「AI と働く」環境が構想されています。これにより、人間はより本質的なコア業務に集中できるようになります。プロンプトの内容や使用要件を定量・定性の両面から分析し、次なる戦略の立案にも役立てられています。 社内チャットに AI 社員の参加 ツール導入で終わらせないために AI の導入を単なる「ツールの導入」で終わらせてはいけません。経営の視点から将来のあり方やワークスタイルを明確に描き、それに適した AI を選択することが重要です。Gemini Enterprise はその選択肢の一つであり、効果的に活用することで、組織の働き方を次のフェーズへと引き上げられます。 関連記事 blog.g-gen.co.jp 今村 壱生 (記事一覧) クラウドソリューション部 ソリューションアーキテクト課 2026年3月にG-genへ入社。約7年間 Web 広告運用やウェブ解析に携わり、その後は社内 SE として開発業務に従事。広告運用の現場感と技術的な視点、その双方を併せ持つ経験をベースに、現在は Google Cloud のスキルアップに注力。データ活用とクラウド技術を融合させ、お客様のビジネス成長を支えるエンジニアを目指している。 Follow

G-gen の杉村です。当記事では、Google Cloud Next Tokyo 26 の、1日目のキーノートに関する速報レポートをお届けします。 Google Cloud Next Tokyo 26 イベント概要 キーノートの概要 AI による産業の革新 NTTデータの事例 Google の AI エージェントエコシステム Gemini Enterprise のデモ 損害保険ジャパンの事例 Ｓｋｙの事例 スクウェア・エニックスの事例 Agentic Workplace の実現 AI 時代のサイバーセキュリティ 関連記事 Google Cloud Next Tokyo 26 イベント概要 Google Cloud の旗艦イベントである Google Cloud Next の東京版、Google Cloud Next Tokyo 26 は、2026年7月30日（木）と31日（金）の2日間で開催されます。本年は昨年と同様、東京ビッグサイトで開催されました。 東京ビッグサイト ビッグサイト入口 G-gen 社によるセッションレポートは、以下の記事一覧から確認できます。 blog.g-gen.co.jp キーノートの概要 初日のキーノート（基調講演）では、AI の社会実装に向けた Google Cloud の AI エージェントエコシステムの紹介や、Google Workspace を活用した自律的なワークプレイスの実現、そして Gemini Enterprise app を中心としたエンタープライズ企業における導入事例が紹介されました。 今回の講演は、技術的なアップデートや新製品の新発表をするというよりも、過去の Google Cloud Next や Google の関連イベントの発表内容を踏襲し、Google の AI エコシステムの紹介や、エージェンティックな仕事改革といった概念の紹介、また日本国内の Google 製品事例にフォーカスしたものでした。 キーノート会場 AI による産業の革新 最初に登壇したのは、Google Cloud Japan 代表の三上智子氏です。 同氏は、産業革命において電気の発明から産業構造の変革まで30年を要したことと現代の AI ブームを比較します。産業革命では工場の各個別の機械にモーターを組み込んだことで革新が起きたことから、現代でも各個別の業務に AI を組み込んで再設計することでこそ、より速いスピードで革新が訪れるのである、という考えを示しました。 Google Cloud 三上智子氏 AI 利用者の約半数がシャドー AI を経験しているという調査結果について言及し、AI ガバナンスの重要性を強調しました。また2030年に向けて、AI を活用した労働力不足への対策や、個人の「暗黙知」「匠の技」を継承していくことが課題となっていくであろうという展望を示しました。 また従来から強調されているとおり、Google が Gemini モデルや AI アプリケーション、プラットフォームのみならず、TPU といった物理レイヤに至るまで、AI 関連技術をフルスタックで開発していることを強調しました。 Google は AI 関連技術をフルスタックで開発 NTTデータの事例 続いて、株式会社NTTデータの常務執行役員 テクノロジーセグメント長 Chief AI Officer、西村忠興氏が登壇しました。 同氏は、NTTデータが2026年6月に Google Cloud と包括契約を締結し、 Google Workspace と Gemini Enterprise を大規模に活用していくことを決定したと述べました。提供者自らが最初の顧客としてソリューションを大規模に導入・活用する「クライアントゼロ」の取り組みを通じてノウハウを蓄積し、顧客へ提供していくとしています。 NTTデータ 西村忠興氏 「クライアントゼロ」 Gemini Enterprise は、Google Cloud が提供する AI エージェント Web アプリケーションです。正式名称は Gemini Enterprise app ですが、多くの公式ドキュメントで単に Gemini Enterprise と言及されていることから、当記事でも Gemini Enterprise の呼称を使用します。 blog.g-gen.co.jp Gemini Enterprise の導入の理由として、 自律的 AI ワークプレイスの実現 というビジョンへの共感や、Google Workspace と Gemini Enterprise が厳格な検証をクリアし、高いセキュリティとガバナンスを備えていることを挙げました。同社は、「チャット型 AI」主体の AI 利用から「自律型 AI エージェント」の利用へと移行し、これを社会に実装することで価値を実現していく考えを示しました。 Google の AI エージェントエコシステム Google Cloud アウトバウンド プロダクト マネジメント ディレクター、リリー・マクニーラス氏が登壇し、Gemini Enterprise Agent Platform などの全体像を解説しました。同氏は、Gemini Enterprise Agent Platform がシンプルさ、安全性、費用対効果を備え、エンタープライズクラスの企業の課題に対処できることを強調しました。 Google Cloud リリー・マクニーラス氏 Gemini Enterprise Agent Platform は、Google Cloud が提供する AI エージェント開発・運用のための統合プラットフォームです。リモート AI エージェントをホストするフルマネージドサービスである Agent Runtime 、エージェントを登録するレジストリとなる Agent Registry 、エージェントの通信制御を担う Agent Gateway のほか、先述の Gemini Enterprise も、Gemini Enterprise Agent Platform のサービス群の1つです。 blog.g-gen.co.jp 同氏は、以下のような紹介を行いました。いずれも新発表ではなく、2026年4月に米国ラスベガスで行われた Google Cloud Next 等のイベントで発表済みのものを、再度強調するものでした。 最新の生成 AI モデル、Gemini 3.5 Flash、Gemini Flash-Lite、Gemini 3.6 Flash、Gemini 3.1 Pro Gemini 3.5 Pro は従来どおり「Coming Soon」 Gemini 3.5 Flash は日本リージョンに対応しており、データ所在の規制要件などに対応可能であること 動画の生成やインタラクティブな編集が可能な Gemini Omni Flash 高度なアルゴリズム開発や課題解決用のエージェントである AlphaEvolve（ロジスティクス、半導体、ゲノミクス向け） 顧客向け（B to C）の AI エージェントを提供する Gemini Enterprise for Customer Experience また、AI と統合されたアプリケーション開発環境である Google Antigravity の企業向けバージョンである Google Antigravity for Enterprise についても再度、紹介されました。Google Antigravity は Gemini Enterprise Agent Platform の API を通じて Gemini モデルなどを呼び出せるようになっており、今後、管理・統制関係の機能も強化されていくことが従来から発表されています。今回の講演では、統制機能に関する詳細やロードマップなどは発表されませんでした。 Gemini Enterprise のデモ Google Cloud のアプライド AI エンジニアである岡本充洋氏により、小売業における Gemini Enterprise のデモが行われました。 同氏は、スーパーバイザーが店舗に臨店し、店舗の状況を音声で記録して報告書を自動作成し、Teams で共有するまでの一連の業務を、Gemini Enterprise の画面から離れずに完了させる様子を実演しました。 また、Gemini Spark を使用し、前日に分析レポートの作成を指示しておき、翌朝に Inbox で結果のレポートを受け取り、PDF として OneDrive に保存するというデモも披露しました。 Gemini Spark は、ユーザーが指示を出すとバックグラウンドで非同期にタスクを処理し、後から結果を得ることができる AI エージェント機能です。2026年7月現在、日本では「数週間以内に個人向けの Google AI Pro プランで利用可能になる」ことが発表されています。 参考 : 「Gemini Spark」： 24 時間 365 日対応する自分だけの AI エージェントが日本の Pro ユーザーにも拡大 Gemini Spark 今回の講演では、Google Workspace や Gemini Enterprise で Gemini Spark が利用可能になるかどうかは明言されませんでした。またイベント終了後の2026年8月3日、複数のユーザーから Google Workspace で Gemini Spark が使用可能になったことが報告されましたが、これは手違いによって一時的に利用可能になったものであり、すぐに使用不可能に（機能が画面に表示されなく）なりました。今後、正式なリリースがあるのかないのか自体、2026年8月初旬現在では不明です。 Gemini Spark 損害保険ジャパンの事例 ＳＯＭＰＯホールディングス株式会社 デジタル・データ戦略部長 兼 損害保険ジャパン株式会社 執行役員 ＣＤＯ ＤＸ推進部長の中島正朝氏が登壇し、既存事業を横断的に DX する「ヨコのDX」における AI 活用事例を紹介しました。 ＳＯＭＰＯホールディングス株式会社 中島正朝氏 同社は、新規事業等における DX を「タテの DX」、既存事業等を横断するものを「ヨコの DX」と位置づけています。 同氏は、Gemini Enterprise 導入の決め手として Gemini Notebook（旧称 NotebookLM）を挙げました。社内の規定類をデータソースとして登録して利用しているほか、会議の録音を自動的に Gemini Notebook に追加することで議事録の作成を不要にした事例を紹介しました。本社公式のノートブックを作成しており、本社へ問い合わせる前にまず AI に確認する習慣が醸成されているとしました。 また、以下のような業務特化型エージェントの市民開発が進んでいることを紹介しました。 モクさぽ（目標設定のためのエージェント） モジおこ（会議の内容を文字起こし） レカみる（レッカー費用などの一次検証） トップダウンでの発信により、AI エージェントの WAU（Weekly Active Users）は80％に達し、AI によって浮いた時間は高付加価値業務に充てられていると述べました。 モクさぽ モジおこ レカみる Ｓｋｙの事例 Ｓｋｙ株式会社の執行役員 太田雅尚氏が登壇し、Gemini Enterprise の全社導入事例を紹介しました。 Ｓｋｙ株式会社 太田雅尚氏 同社では、「コーディング」「検索、質問」「文章作成」などが AI の用途の半分を占めていること、残りの半分が、それらの混合と思われ分類できない「その他」の用途であることを述べました。 AI の用途 同氏は、選定の理由として「処理精度」、「高度な検索」、そして「ガバナンス」を挙げました。導入から5か月間で20,000個のエージェントが作成され、個人の暗黙知やローカルデータの可視化に大きく貢献していると語りました。 スクウェア・エニックスの事例 株式会社スクウェア・エニックスの AI&エンジン開発ディビジョン ジェネラル・マネージャー、荒牧岳志氏が登壇しました。 スクウェア・エニックス 荒牧岳志氏 同氏は、同社における「新しいゲーム体験の創出」と「開発サポート」という2つの異なる場面における AI 活用を紹介し、AI がゲーム画面を見て、考えて、動くことができるマルチモーダル性の重要性を説きました。 Gemini Enterprise Agent Platform を採用し、「ドラゴンクエスト10オンライン」において、ゲーム画面を見て自ら話しかけてくる「おしゃべりスラミィ」を実装した事例を紹介しました。また、開発現場では QA の自動化にも活用されていると述べました。 Agentic Workplace の実現 Google Cloud の Google Workspace プロダクト担当 バイス プレジデント、ユリー クォン キム氏が登壇しました。 Google Cloud ユリー クォン キム氏 同氏は、企業におけるデータの断片化という課題を指摘し、Agentic Workplace の時代が到来したことを述べました。 Workspace Intelligence により分散したデータが統合され、AI に安心して業務を任せられる環境が構築されることを強調しました。 Workspace Intelligence は、2026年4月に発表された、Google Workspace の標準機能です。Gmail、Google ドライブ、Google カレンダー、Google チャットなどを横断して、AI が情報を収集し、コンテキストとして使用してユーザーのタスクを実行します。Gmail 等のサイドパネルで AI に指示をするだけで、これらのアプリを横断した情報収集とタスクの実行が可能です。 参考 : 生成 AI 機能の Workspace Intelligence を制御する 加えて、以下のような実例が紹介されました。 朝、Gmail から優先して読むべきメールをピックアップし、自然言語で質問するとファイルを検索してサマリを表示 Sheets Canvas を使用し、スプレッドシート上で AI がカンバンボードなどのミニアプリを自動作成 Google Meet で、複数言語で会話してもお互いの言語へリアルタイムに AI 同時翻訳を実行 Sheets Canvas で作成されたカンバンボード 続いて、カスタマー エンジニアである服部淳氏によるデモが行われました。Google Pics での画像編集や、Slides のサイドパネルから指示を出して Google チャット、Gmail、Google ドキュメントなどの情報を読み取り、Google スライドで資料を自動生成する様子が紹介されました。 AI を使ったスライドの作成と編集 なお Google Pics とは、AI を使った画像編集ツールです。近日中に Google Workspace で使用可能になることが発表されています。 参考 : Google Pics: AI 画像生成および編集ツール | Google Workspace AI 時代のサイバーセキュリティ 最後に、三上智子氏が再び登壇しました。 同氏は、AI 時代におけるサイバーセキュリティの重要性を強調し、 AI Threat Defense とその機能の一部である CodeMender を紹介してキーノートを締めくくりました。 CodeMender AI Threat Defense は、Google が提唱する AI エージェントを活用したセキュリティフレームワークです。AI モデルである Gemini、セキュリティ製品である Wiz、ソースコードの脆弱性修復エージェントである CodeMender、脅威インテリジェンスである Mandiant を組合わせて、セキュリティを向上させる考えです。 参考 : Google AI Threat Defense 発表：攻撃者の先を行くために 関連記事 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の min です。 Gemini Enterprise Agent Platform の AutoML でバッチ推論（Batch Prediction）ジョブを実行した際、クォータの上限に達してエラーになる事象が発生しました。原因と対処法を記載します。 事象 原因 対処法 割り当ての上限緩和申請 ジョブの実行間隔の調整 事象 Gemini Enterprise Agent Platform（旧称 Vertex AI、以下 Agent Platform）の表形式データを使用した AutoML のバッチ推論ジョブを実行した際、ジョブが失敗し、以下のようなエラーメッセージが表示されました。 エラーメッセージ The following quotas are exceeded: AutoMLTablesConcurrentBatchPredictionJobs また、Google Cloud コンソールから該当の API の割り当てや使用状況を確認すると、以下のように上限に達していることがわかりました。 使用状況グラフの表示画面 原因 このエラーは、Agent Platform のバッチ推論における1リージョンあたりの同時実行ジョブ数が、Google Cloud によって規定されているクォータの上限に達したことを意味しています。 2026年7月現在、AutoML の表形式データにおけるバッチ推論の同時実行ジョブ数のデフォルトの上限値は、1リージョンあたり5です。この制限値は、意図しないリソースの乱用やコストの高騰を防ぐために設定されています。 参考 : Gemini Enterprise Agent Platform quotas and limits | AutoML model quotas なお、AutoML の表形式データに限らず、カスタムモデルや画像、テキストなど他のデータ型のモデルを用いたバッチ推論においても、それぞれ個別の割り当てが設定されています。 対処法 割り当ての上限緩和申請 バッチ推論ジョブの同時実行数をデフォルトの制限値より増やす必要がある場合は、Google Cloud のコンソールから上限緩和の申請を行います。 具体的な申請手順は以下のとおりです。 Google Cloud コンソールのナビゲーションメニューから [IAM と管理] > [割り当てとシステム上限] を選択する。 フィルタにエラーメッセージに対応する割り当て名（例 : AutoML tables concurrent batch prediction requests per region ）を入力して検索する。 対象のリージョン（例 : asia-northeast1 ）の三点リーダー「⋮」のメニューから、 [割り当てを編集] をクリックする。 割り当てを編集 右側に表示されるパネルで、 [新しい値] と [リクエストの説明] を入力する。 ステップ 1/2 [名前] を入力し、 [リクエストを送信] をクリックする。 ステップ 2/2 申請後、数時間から数営業日以内に審査が行われ、承認されると新しい上限値が適用されます。 参考 : 割り当ての表示と管理 - 割り当ての調整をリクエストする 参考 : Cloud Quota の概要 - 割り当ての調整について ジョブの実行間隔の調整 上限緩和の申請が承認されない場合や、申請を行わずにエラーを回避したい場合は、アプリケーション側の実装やジョブのスケジュールを見直す必要があります。 複数のバッチ推論ジョブを同時に実行するのではなく、実行中のジョブ数が上限を超えないように、先行するジョブが完了してから次のジョブを投入するように制御してください。 佐々木 愛美 (min) (記事一覧) クラウドソリューション部 データアナリティクス課。2024年7月 G-gen にジョイン。G-gen 最南端、沖縄県在住。最近覚えた島言葉は、「マヤー（猫）」。

G-gen の佐々木です。当記事では、Google Cloud の生成 AI 開発・運用プラットフォームである Gemini Enterprise Agent Platform に統合された評価サービス、 Gen AI Evaluation Service を解説します。生成 AI の出力品質を客観的・データドリブンに評価できるサービスです。 概要 Gemini Enterprise Agent Platform とは Gen AI Evaluation Service とは 当記事で扱うインターフェース Gen AI Evaluation Service の評価方法 評価方法の分類 適応型ルーブリックによる評価 評価指標 ルーブリックベースの指標 計算ベースの指標 カスタム指標 エージェント評価指標 評価データセット 利用にあたっての注意点 サービスエージェントの自動作成 対応リージョン 料金 評価の実行方法 評価のインターフェース 評価のワークフロー 使用例（適応型ルーブリック） SDK のインストールと初期化 推論と評価の実行 複数モデルの比較 比較結果の確認 実践と応用 概要 Gemini Enterprise Agent Platform とは Gemini Enterprise Agent Platform （旧称 Vertex AI、以下 Agent Platform と記載）は、Google Cloud が提供する生成 AI / 機械学習モデルの開発・デプロイ・運用を統合的に扱うプラットフォームです。基盤モデルの呼び出し、チューニング、エージェントの構築とデプロイ、評価までを一貫して行えます。 Agent Platform 全体の概要は、以下の記事で解説しています。 blog.g-gen.co.jp Gen AI Evaluation Service とは Gen AI Evaluation Service は、Agent Platform の機能の1つで、生成 AI のモデル・アプリケーション・エージェントの出力品質を客観的に評価するためのサービスです。 生成 AI の出力は「正解が1つに定まらない」ため、従来の機械学習のように単純な正解率では品質を測れません。Gen AI Evaluation Service は、別の大規模言語モデル（LLM）を評価者（ジャッジ）として使う手法（LLM-as-a-judge）や、参照回答との一致を測る決定論的なアルゴリズムを組み合わせ、出力品質を数値とフィードバックの形で可視化します。 主な用途は以下のとおりです。 モデルのバージョン間で挙動の差を比較し、移行可否を判断する Google のモデルとサードパーティ製モデルを同じ基準で比較し、最適なモデルを選定する 評価結果をフィードバックループに組み込み、プロンプトを最適化する ファインチューニングの前後の品質を、一貫した基準で評価する ツールの使用やトラジェクトリ（実行の軌跡）など、エージェント固有の観点を測る 参考 : Gen AI Evaluation Service の概要 当記事で扱うインターフェース 当記事で解説するのは、Google が推奨する Agent Platform SDK の GenAI クライアントを使った評価方法です。公式で推奨されてはいるものの、2026年6月現在はプレビュー機能として提供されている点に注意してください。 一方、以前から提供されている評価モジュール（ EvalTask ）は GA（一般提供）ですが、当記事で扱う適応型ルーブリックには対応していません。両インターフェースの違いは、後半の「評価のインターフェース」で改めて整理します。 Gen AI Evaluation Service の評価方法 評価方法の分類 はじめに、当記事で繰り返し登場する評価関連の用語を整理します。 用語 定義 ルーブリック（rubric） 回答をどう評価するかの基準。「良い回答が満たすべき条件」を合否形式のチェック項目として定めたもの 指標（metric） ルーブリックなどの基準に照らして回答を測定したスコア。流暢さ・安全性・参照回答との一致など、何を測るかを表す 参照回答（reference） 入力に対して期待する正解（お手本）の出力。 グラウンドトゥルース とも呼ぶ。計算ベースの指標などが、モデルの出力と突き合わせてスコアを算出する際の基準とする ルーブリックが評価の「ものさし」で、そのものさしで測った結果が指標のスコアにあたります。 Gen AI Evaluation Service の評価指標は、大きく以下の4つのカテゴリに分かれます。 指標カテゴリ 評価方法・例 概要 参照回答 ルーブリックベースの指標 適応型ルーブリック（推奨）・静的ルーブリック LLM を評価者（ジャッジ）として、回答を合否項目で採点する 指標による 計算ベースの指標 BLEU・ROUGE など 決定論的なアルゴリズムで参照回答との一致度を計算する 必要 カスタム指標 カスタム関数・リモートカスタム関数・LLMMetric Python 関数や独自プロンプトで評価ロジックを定義する 任意 エージェント評価指標 ツール使用・実行軌跡の評価 ツールの呼び出しや実行軌跡など、エージェント固有の観点を評価する 指標による このうち適応型ルーブリックは、参照回答なしで多様なプロンプトを評価できるため、まず試す方法として推奨されています。各カテゴリに含まれる個別の指標は、後述の「評価指標」で解説します。 参考 : Gen AI Evaluation Service の概要 - 評価指標 参考 : 評価指標を定義する 適応型ルーブリックによる評価 適応型ルーブリック （adaptive rubric）は、Gen AI Evaluation Service が推奨する評価方法です。プロンプトの内容に応じて「このプロンプトに対する良い回答が満たすべき条件」を合否形式のチェック項目として自動生成し、その項目ごとに回答を検証します。 たとえば、後半の使用例で使う次の2つのプロンプトでは、それぞれ以下のような評価項目（ルーブリック）が動的に生成されます。 プロンプト例 生成される評価項目 「Cloud Run と GKE の使い分けを、専門用語を使わずに、ちょうど2つの箇条書きで、各項目40文字以内で説明してください」 ・日本語で書かれているか ・Cloud Run の使いどころを説明しているか ・GKE の使いどころを説明しているか ・専門用語を避けているか ・ちょうど2つの箇条書きか ・各項目が40文字以内か ・非専門家にも分かりやすいか 「Infrastructure as Code の利点を、句読点を含めてちょうど50文字で述べてください」 ・日本語で書かれているか ・IaC の利点を述べているか ・句読点を含めてちょうど50文字か 各項目の合否でスコアが決まり、スコアはルーブリックの合格率として0〜1の範囲で表されます。 固定の採点基準を全プロンプトに適用する 静的ルーブリック と異なり、適応型ルーブリックはプロンプトごとに評価観点を作り分けるため、多様なタスクを含むデータセットでも適切に評価できます。 当記事後半の使用例でも、この適応型ルーブリックに分類される GENERAL_QUALITY と INSTRUCTION_FOLLOWING を指標に選び、実際に評価を実行します。 評価指標 ルーブリックベースの指標 ルーブリックベースの指標 は、Gemini などの LLM を評価者として使い、回答の品質を採点する指標です。流暢さ・指示への準拠・安全性といった、機械的には測りにくい定性的な観点の評価に向いています。 代表的なマネージド指標は以下のとおりです。SDK では types.RubricMetric 経由でアクセスします。 指標 種別 概要 GENERAL_QUALITY 適応型 指示への準拠・書式・トーン・スタイルを総合評価する。デフォルトの指標 TEXT_QUALITY 適応型 流暢さ・一貫性・文法を評価する INSTRUCTION_FOLLOWING 適応型 プロンプトの制約・指示にどれだけ適切に従っているかを評価する GROUNDING 静的 与えたコンテキストに対する事実性・整合性を評価する。RAG 向け SAFETY 静的 ヘイトや個人情報など、安全性ポリシーへの違反を評価する FINAL_RESPONSE_MATCH 静的 回答が参照回答（ reference ）と一致しているかを評価する 評価では、指標ごとに異なる回数のジャッジ呼び出しが行われます。たとえば GENERAL_QUALITY は Gemini 2.5 Flash（2026年6月現在）を6回、 SAFETY は10回呼び出します。 まずは GENERAL_QUALITY から始め、必要に応じて観点を絞った指標を追加するのが基本的な進め方です。また、 GENERAL_QUALITY などの指標には独自のガイドラインを追加して、評価の観点を絞り込むこともできます。 参考 : 評価指標を定義する 参考 : マネージド ルーブリック ベースの指標の詳細 計算ベースの指標 計算ベースの指標 は、参照回答との一致度を決定論的なアルゴリズムで計算する指標です。LLM を介さないため高速で、結果が安定します。要約や翻訳のように、期待する出力が明確なタスクに向いています。 指標 概要 bleu n-gram の一致度を測る。翻訳品質の標準的な指標 rouge_1 / rouge_l n-gram の適合率を測る。要約の評価に向く exact_match 参照回答と完全に一致した割合を測る いずれの指標も、評価データセットに参照回答（ reference ）の列が必要です。出力を参照回答と突き合わせてスコアを計算するため、以下のように入力・出力・参照回答を組にしたデータを用意します。 入力（ prompt ） 出力（ response ） 参照回答（ reference ） 「Good morning」を日本語に訳してください おはよう おはようございます 次の文を要約してください : 〜（本文） 売上は前年比10%増だった 売上は前年同期比で10%増加した 日本の首都はどこですか 東京 東京 たとえば bleu であれば、出力「おはよう」と参照回答「おはようございます」の n-gram の重なりからスコアを算出します。SDK では types.Metric(name="bleu") のように指定します。 参考 : 評価指標を定義する - 計算ベースの指標 カスタム指標 マネージドな指標では測れない独自の観点を評価したい場合は、カスタム指標を定義できます。カスタム指標には以下の3種類があります。 種類 概要 カスタム関数指標（ custom_function ） Python 関数で評価ロジックを書き、各行に対して実行する リモートカスタム関数指標（ remote_custom_function ） ネットワーク非接続のサンドボックス環境で評価ロジックを実行する 静的なカスタム指標（ LLMMetric ） 独自のプロンプトで LLM に採点させる 参考 : 評価指標を定義する - カスタム関数指標 参考 : 評価指標を定義する - リモートカスタム関数指標 エージェント評価指標 Gen AI Evaluation Service は、最終的な回答テキストだけでなく、エージェントがツールを呼び出して回答に至るまでの過程も評価できます。これにより、「正しいツールを正しい引数で呼べているか」「無駄な手順を踏んでいないか」といった、エージェント固有の品質を測れます。 指標 概要 FINAL_RESPONSE_QUALITY エージェントの最終回答の品質を評価する TOOL_USE_QUALITY ツール（関数）呼び出しの正確性を評価する HALLUCINATION 回答が根拠に基づいているか（グラウンディング度）を評価する MULTI_TURN_TRAJECTORY_QUALITY マルチターン会話でのツール呼び出しの軌跡（トラジェクトリ）の質を評価する 参考 : Agent Platform SDK の生成 AI クライアントを使用して生成 AI エージェントを評価する 評価データセット Gen AI Evaluation Service は、一般的なデータ形式を自動で判別するため、手元のデータを大きく変換せずに評価へ渡せます。必要なフィールドは評価の目的によって変わります。 目的 必須フィールド 新しく回答を生成して評価する prompt 既存の回答を評価する prompt 、 response 計算ベースの指標で評価する prompt 、 response 、 reference 評価データセットは、pandas の DataFrame のほか、Gemini のバッチ予測形式や OpenAI Chat Completion 形式の JSONL ファイル、Cloud Storage 上のファイルとして渡せます。マルチターン会話を含む JSONL は自動的に解析され、最後のユーザー発話が prompt 、それより前のやり取りが会話履歴、モデルの返答が response に振り分けられます。 たとえば、既存の回答を評価する場合の pandas DataFrame は以下のように用意します。 import pandas as pd eval_dataset = pd.DataFrame( { "prompt" : [ "「Good morning」を日本語に訳してください" , "日本の首都はどこですか" , ], "response" : [ "おはよう" , "東京" , ], } ) 計算ベースの指標で評価する場合は、ここに参照回答（ reference ）の列を追加します。 eval_dataset = pd.DataFrame( { "prompt" : [ "「Good morning」を日本語に訳してください" , "日本の首都はどこですか" , ], "response" : [ "おはよう" , "東京" , ], "reference" : [ "おはようございます" , "東京" , ], } ) JSONL ファイルとして渡す場合は、1行が1件の評価対象となります。 { " prompt ": " 「Good morning」を日本語に訳してください ", " response ": " おはよう ", " reference ": " おはようございます " } { " prompt ": " 日本の首都はどこですか ", " response ": " 東京 ", " reference ": " 東京 " } 参考 : 評価データセットを準備する 利用にあたっての注意点 サービスエージェントの自動作成 ルーブリックベースの指標など、LLM がジャッジとして採点する評価を初めてリクエストすると、プロジェクトにサービスエージェント service-<プロジェクト番号>@gcp-sa-vertex-eval.iam.gserviceaccount.com が自動的に作成され、 roles/aiplatform.rapidevalServiceAgent ロールが付与されます。 自動的に作成されるサービスエージェント 対応リージョン 2026年6月現在、Gen AI Evaluation Service は us-central1 などの米国リージョンの一部と、 europe-west1 などの欧州リージョンの一部、および global エンドポイントで利用できます。対応リージョンの最新情報は公式ドキュメント（原文）を参照してください。 参考 : Gen AI evaluation service overview - Supported regions 料金 Gen AI Evaluation Service の評価時にジャッジとして LLM を呼び出す場合、評価に使われるモデルの利用料金が発生します。実際の課金については、最新の公式の料金ページを確認してください。 参考 : Agent Platform での AI モデルの構築とデプロイの費用 評価の実行方法 評価のインターフェース Gen AI Evaluation Service は、以下の3つのインターフェースから利用できます。 インターフェース アクセス方法 Agent Platform SDK の GenAI クライアント（プレビュー） from vertexai import Client Agent Platform SDK の評価モジュール（GA・旧インターフェース） from vertexai.evaluation import EvalTask Google Cloud コンソール（プレビュー） コンソール画面 当記事で解説する適応型ルーブリックは、新しい GenAI クライアント 方式で利用できる機能です。2026年6月現在、この GenAI クライアント方式はプレビューとして提供されています。旧インターフェースである従来の評価モジュール（ EvalTask ）は GA ですが、適応型ルーブリックには対応しておらず、下位互換性維持のための提供となっています。 なお、Gen AI Evaluation Service の SDK は Agent Platform 配下の機能ですが、2026年6月現在、パッケージ名やインポートは引き続き Vertex AI 系（ vertexai 、 google-cloud-aiplatform ）を使います。 参考 : Gen AI Evaluation Service の概要 - 評価の開始 評価のワークフロー GenAI クライアントを使ったモデル評価は、以下の流れで進めます。 評価データセットを用意する（プロンプトと、必要に応じて参照回答） 評価指標を選ぶ モデルに推論させて回答を生成する（ run_inference ） 生成した回答を評価する（ evaluate ） 評価結果を表示・解釈する（ show ） 既にモデルの回答が手元にある場合は、ステップ3を省いて評価から始めることもできます。各ステップの具体的なコードは、後述の使用例で示します。 なお、大規模なデータセットを評価する場合は、評価を非同期で実行して結果を Cloud Storage に出力する batch_evaluate メソッドも利用できます。 参考 : 評価を実行する - 非同期の大規模な評価 使用例（適応型ルーブリック） SDK のインストールと初期化 ここからは、Agent Platform SDK の GenAI クライアントを使ってモデルの回答を生成し、評価するまでの最小の流れを試します。Google Cloud への認証が通る Python 環境であれば実行できますが、評価結果がインタラクティブな HTML レポートとして表示されるため、Colab Enterprise や Agent Platform Workbench（旧称 Vertex AI Workbench）などのノートブック環境を推奨します。 以降のコードは、ノートブックのセルに分けて上から順に実行していく前提で進めます。各セルを実行して結果を確認しながら読み進めてください。 まず、評価用の追加コンポーネントを含めて SDK をインストールします。ノートブックでは、最初のセルに次を貼り付けて実行します。 # Agent Platform SDK のインストール %pip install -q google-cloud-aiplatform[evaluation] ターミナルから実行する場合は、 %pip の代わりに pip を使います。 # 評価コンポーネント付きで Agent Platform SDK をインストール $ pip install -q google-cloud-aiplatform [ evaluation ] なお、Colab Enterprise などのマネージドなノートブック環境では、インストール時に以下の警告が出ることがあります。この警告は Gen AI Evaluation Service の利用に影響しないため、そのまま進めて問題ありません。 ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts. wandb 0.27.0 requires click>=8.2.0, but you have click 8.1.8 which is incompatible. gradio 5.50.0 requires pydantic<=2.12.3,>=2.0, but you have pydantic 2.12.5 which is incompatible. 続いて、次のセルで GenAI クライアントを初期化します。 <プロジェクト ID> は実際の Google Cloud プロジェクト ID に置き換えてください。ここではリージョンに依存しない global エンドポイントを使用します。特定のリージョンに固定したい場合は、対応リージョンから選んで指定してください。 # GenAI クライアントの初期化 from vertexai import Client PROJECT_ID = "<プロジェクト ID>" LOCATION = "global" client = Client(project=PROJECT_ID, location=LOCATION) 推論と評価の実行 次のセルでは、評価したいプロンプトを pandas の DataFrame で用意し、モデルに推論させて回答を生成します。 import pandas as pd from vertexai import types # 評価したいプロンプトを pandas の DataFrame で用意する prompts_df = pd.DataFrame({ "prompt" : [ "Cloud Run と GKE の使い分けを、専門用語を使わずに、ちょうど2つの箇条書きで、各項目40文字以内で説明してください。" , "Infrastructure as Code の利点を、句読点を含めてちょうど50文字で述べてください。" , ], }) # モデルにプロンプトを推論させて回答を生成する eval_dataset = client.evals.run_inference( model= "gemini-2.5-flash" , src=prompts_df, ) 生成した回答に対して、次のセルで評価指標を指定して評価を実行します。ここでは総合品質（ GENERAL_QUALITY ）と指示への準拠（ INSTRUCTION_FOLLOWING ）の2つを指定します。 # 評価指標を指定して評価を実行する eval_result = client.evals.evaluate( dataset=eval_dataset, metrics=[ types.RubricMetric.GENERAL_QUALITY, types.RubricMetric.INSTRUCTION_FOLLOWING, ], ) metrics を省略した場合は、デフォルトで GENERAL_QUALITY が使われます。 生成した回答の評価結果は、 show メソッドでインタラクティブな HTML レポートとして表示できます。 # 評価結果を HTML レポートとして表示する eval_result.show() レポートは大きく2つのブロックで構成されます。先頭の Summary Metrics には、データセット全体での指標ごとの平均スコアと標準偏差が並び、評価全体の傾向を一目で把握できます。 データセット全体での指標ごとの平均スコアと標準偏差（Summary Metrics） 続く Detailed Results では、プロンプト1件ごとに、入力プロンプト・モデルの回答・指標ごとのスコアが展開されます。適応型ルーブリックの指標では、スコアの内訳として、そのプロンプト向けに動的生成されたチェック項目（ルーブリック）ごとの合否と、その判定理由を確認できます。 たとえば「専門用語を使わずに、2つの箇条書きで各40文字以内に説明する」という制約付きのプロンプトであれば、「専門用語を使っていないか」「箇条書きがちょうど2つか」「各項目が40文字以内か」といった項目ごとに合否が並び、どの観点を満たし、どこで失点したのかを項目単位でたどれます。 Case #0（1つ目のプロンプト）の Detailed Results Case #1（2つ目のプロンプト）の Detailed Results 実際に今回の評価では、Cloud Run と GKE の使い分けを問うプロンプト（Case #0）は全項目を満たして1.00になった一方、Infrastructure as Code の利点を「ちょうど50文字」で求めたプロンプト（Case #1）は、回答が35文字だったため字数のルーブリックが Fail となり0.67にとどまりました。 GENERAL_QUALITY のような適応型ルーブリックは合格した項目の割合をスコアにするため、厳密な制約を1つ外すだけでもスコアが明確に下がります。 複数モデルの比較 次のセルでは、同じプロンプトに対して複数のモデルで推論を実行し、その結果をリストとして evaluate() に渡して、モデル間の比較評価を行います。 # 比較したいモデルごとに推論を実行する inference_result_1 = client.evals.run_inference( model= "gemini-2.5-flash" , src=prompts_df, ) inference_result_2 = client.evals.run_inference( model= "gemini-3.5-flash" , src=prompts_df, ) # 複数モデルの結果をリストで渡して比較評価する comparison_result = client.evals.evaluate( dataset=[inference_result_1, inference_result_2], metrics=[types.RubricMetric.GENERAL_QUALITY], ) モデルの比較は、このようにモデルごとに評価した結果を並べる ポイントワイズ方式 で行います。なお、2つの回答を直接比較する ペアワイズ方式 による評価も可能です。 参考 : 評価指標を定義する - ポイントワイズ評価とペアワイズ評価のどちらかを選択する 比較結果の確認 比較評価の結果も、同じく show メソッドで表示できます。 # 比較評価の結果を HTML レポートとして表示する comparison_result.show() 比較レポートの Summary Metrics には、モデルごとの平均スコアと標準偏差に加えて、 Win/Tie Rates （勝率・引き分け率）が表示されます。これは指標ごとに、プロンプト単位でどちらのモデルのスコアが高かったかを集計したものです。 今回の比較では、Cloud Run と GKE の使い分けを問うプロンプトは両モデルとも全項目を満たして1.00で並び、引き分けとなりました。一方、Infrastructure as Code の利点を「ちょうど50文字」で求めたプロンプトでは、48文字で回答した gemini-2.5-flash が字数のルーブリックを外して0.67となり、ちょうど50文字で回答した gemini-3.5-flash が1.00で上回りました。 その結果、Win/Tie Rates は gemini-3.5-flash の勝率50.0%・引き分け50.0%となっています。 比較レポートの Summary Metrics Detailed Comparison では、プロンプトごとに各モデルの回答が横並びで表示され、回答・スコア・ルーブリックの内訳を並べて比較できます。 総合スコアが並んだ場合でも、回答そのものを見比べれば、たとえ方や説明の構成といった定性的な違いを確認できます。スコアだけで差がつかないときは、観点を絞ったマネージド指標やカスタム指標を追加すると、モデル間の差を切り分けやすくなります。 比較レポートの Case #0（1つ目のプロンプト）の Detailed Results 比較レポートの Case #1（2つ目のプロンプト）の Detailed Results 参考 : 評価を実行する 参考 : 評価結果を表示して解釈する 実践と応用 当記事で紹介する Gen AI Evaluation Service を使っているわけではありませんが、以下の記事では、ライオン株式会社様が GitHub Copilot と SpecKit 等を用いて本格的なデータパイプライン開発を行った実例が紹介されています。記事中では、LLM による品質評価も試みられています。AI 駆動開発における参考にしてください。 zenn.dev なお関連して、2026年7月30日から31日に開催される Google Cloud Next Tokyo '26 では、ライオン株式会社様や株式会社 G-gen が各種セッションで登壇します。これらのセッションも参考にしてください。 日時 実施会社 セッション種別 タイトル 2026年7月30日 (木) 13:00 - 13:30 ライオン株式会社 カスタマーセッション 生成 AI による SAP を中心とした AI-ready なデータ基盤の実践的な構築 2026年7月30日 (木) 15:00 - 15:30 ライオン株式会社 ブース内セッション (G-gen 出展ブース) ライオンのデータモデル Deep Dive 2026年7月31日 (金) 15:00 - 15:30 株式会社G-gen スポンサーセッション AI エージェント時代のクラウド インフラ設計ガイドラインの重要性 Google Cloud Next Tokyo '26 には、以下から申し込み可能です。 申込URL　: Google Cloud Next Tokyo '26 招待コード: NxT26_pt023 佐々木 駿太 (記事一覧) クラウドソリューション部 クラウドエンジニアリング1課 北海道在住 大学院まで社会心理学を専攻し、AI に興味を持ち IT 業界へ。2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出（2024 / 2025 Fellow / 2026）。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。最近は法律の勉強にも目覚め、2級知的財産管理技能士を取得。 Follow @sasashun0805