株式会社G-genのブログ - TECH PLAY

TECH PLAY

株式会社G-gen

株式会社G-gen の技術ブログ

全888件

G-gen の今村です。当記事では、Cloud SQL で提供されているパフォーマンス最適化機能の1つである インデックスアドバイザー について解説します。 概要 インデックスアドバイザーとは 仕組み 料金と要件 料金 対象エディションと要件 有効化の手順 推奨事項の確認 推薦インデックスの確認方法 画面に表示される評価データの内容 Gemini による支援 推奨事項の適用 概要 インデックスアドバイザーとは Cloud SQL の インデックスアドバイザー 機能は、Cloud SQL で実行されたクエリを自動的に分析し、パフォーマンス向上につながる最適なインデックスを提案する機能です。当機能は Cloud SQL の Enterprise Plus エディションでのみ使用できます。 2026年6月現在、Cloud SQL の主要な3つのデータベースエンジン(MySQL、PostgreSQL、SQL Server)のすべてでサポートされています。各データベースエンジンにおける基本的な機能の目的や仕組みに大きな違いはありません。 リレーショナルデータベースの運用において、クエリの実行速度低下を解決するためのインデックス追加は非常に有効な手段です。しかし、どのカラムにどのようなインデックスを定義すべきかの判断には、高度な知識と経験が必要です。インデックスアドバイザーを使用することで、システムが実際のクエリ負荷に基づいて具体的な推奨インデックスを提示するため、データベース管理者の運用負荷を大幅に削減できます。 参考 : インデックス アドバイザーを使用する | Cloud SQL for PostgreSQL Cloud SQL の機能の詳細は、以下の記事を参照してください。 blog.g-gen.co.jp 仕組み インデックスアドバイザーがクエリを分析する際は、具体的な数値や文字列などのリテラルを除外した「正規化クエリ」と呼ばれる共通のパターンで追跡されます。例えば、検索する数値が異なっていても、同じ型のクエリとしてまとめて統計が取られる仕組みです。 このデータを基に、パフォーマンス向上につながる新しいインデックスが自動で識別され、具体的な CREATE INDEX 文として推奨事項に保存されます。生成された推奨事項は、Google Cloud コンソールの Query Insights ダッシュボードや推奨事項画面からいつでも確認できます。 なお当機能が提案するのは、データの検索速度を高めるためのインデックスであり、主キーや外部キーなどのテーブル構成の推奨事項などは生成されません。またリレーショナルデータベースの一般的な仕様として、テーブルにインデックスを追加すると、データ更新時にインデックス更新も同時に行われることで書き込み処理の負荷が増加する点にも留意が必要です。 よって、インデックスアドバイザーによる推奨事項を無条件に採用するのではなく、パフォーマンス影響等を考慮して、適用の可否を判断してください。 料金と要件 料金 インデックスアドバイザー機能自体の使用に追加料金はかかりません。Cloud SQL の Enterprise Plus エディションを利用していれば、無料で使用できます。 対象エディションと要件 インデックスアドバイザーを使用するには、Cloud SQL の Enterprise Plus エディション を使用している必要があります。また、インスタンスで Query Insights 機能が有効化されていることが要件となります。 Query Insights が収集する指標データは、原則として Cloud SQL インスタンスのストレージ領域を占有しません。指標は Cloud Monitoring に保存されるため、インスタンス自体のディスク容量を圧迫しない設計になっています。ただし、収集された指標の転送や API リクエストに伴い、Cloud Monitoring 側の料金が適用される場合がある点に留意してください。 参考 : Cloud SQL のエディションの選択 | Cloud SQL for PostgreSQL Cloud Monitoring の機能の詳細は以下の記事を参照してください。 blog.g-gen.co.jp 有効化の手順 インデックスアドバイザーを有効化する手順は以下の通りです。 Cloud SQL の「インスタンス」ページに移動し、対象のインスタンス名をクリック 概要ページから「編集」をクリック 「構成の編集」をクリック 「インスタンスのカスタマイズ」セクションで「Query Insights」を展開 「Query Insights を有効にする」チェックボックスをオンにする 「インデックスアドバイザーを有効にする」チェックボックスをオンにする 「保存」をクリックして設定を反映 インデックスアドバイザーを有効にするには、インスタンスの再起動が必要です。本番環境で実施する際は、必ずメンテナンス可能な時間帯を計画してください。 参考 : Query Insights を使用してクエリのパフォーマンスを向上させる | Cloud SQL for SQL Server 推奨事項の確認 推薦インデックスの確認方法 推奨インデックスを確認する手順は以下の通りです。 Cloud SQL の「インスタンス」ページに移動 対象のインスタンス名をクリックし、「Query Insights」をクリック 「上位のクエリとタグ」セクションで目的のクエリをクリック 画面に表示される評価データの内容 クエリの詳細画面では、推奨されたインデックスを適用すべきかを総合的に判断するための情報がまとまっています。 まず確認したいのがパフォーマンスへの影響です。推定クエリ速度が「高」「中」「低」の3段階で示されるため、導入によってどれほどの速度向上が見込めるかが一目でわかります。次に、その効果に対してどれほどのリソースが必要になるかを、影響を受けるテーブルと必要な追加ストレージサイズの推定値から見積もります。さらに、そのインデックスがシステム全体のどれほど多くの処理に貢献するかを、影響を受けるクエリの数で評価します。 このように、見込める効果とリソースへの影響を天秤にかけて適用の可否を判断した上で、画面上の「インデックスの作成」をクリックすると、実行すべき具体的な DDL が表示されます。 推奨事項は、自動的にデータベースへ適用されるわけではありません。そのため、ユーザー自身がコンソール画面から CREATE INDEX 文をコピーし、手動で適用作業を行う必要があります。 Gemini による支援 2026年6月現在、Cloud SQL ではインデックスアドバイザーによる自動分析だけでなく、生成 AI モデル Gemini を使用したクエリ作成のアシスタンス機能も提供されています。 Google Cloud コンソールの Cloud SQL Studio などの画面において、自然言語のプロンプトから SQL の生成や、クエリ構造の説明を取得できます。これにより、インデックスアドバイザーが提案した CREATE INDEX などの DDL の意図を深く理解したり、最適化されたクエリの記述を効率化できます。機能の具体的な使用方法や最新の要件については、公式ドキュメントを参照してください。 参考 : Gemini を使用して SQL クエリを作成する | Cloud SQL for PostgreSQL 推奨事項の適用 推奨事項を適用するには、コピーした CREATE INDEX 文を、Cloud SQL インスタンス内のデータベースに対して手動で実行します。実行にあたり、普段運用で使用しているデータベース管理ツール経由で DDL を実行することも、Google Cloud コンソール上で直接 SQL を実行できる Cloud SQL Studio を使用することもできます。 一般的に、インデックスの作成処理は、既存のテーブル内にあるレコードを読み込んだうえで新しくインデックスを構築してディスクに書き込むため、データベースの CPU やディスク I/O などのリソースを大きく消費します。対象テーブルのデータ量によっては処理に長い時間がかかり、本番環境のパフォーマンスに影響を与える可能性がある点に留意してください。 そのため、本番環境へ適用する際は、事前に検証環境で処理時間や影響度を確認し、システムへの負荷を最小限に抑えられるよう、利用者の少ない時間帯に実行を計画してください。 今村 壱生 (記事一覧) クラウドソリューション部 ソリューションアーキテクト課 2026年3月にG-genへ入社。約7年間 Web 広告運用やウェブ解析に携わり、その後は社内 SE として開発業務に従事。広告運用の現場感と技術的な視点、その双方を併せ持つ経験をベースに、現在は Google Cloud のスキルアップに注力。データ活用とクラウド技術を融合させ、お客様のビジネス成長を支えるエンジニアを目指している。 Follow
G-gen の三浦です。当記事では、Google SecOps の AI エージェントである トリアージと調査エージェント (TIN)と、それを Playbook に組み込む エージェントの自動化 (Agentic Automation)を使い、アラートの一次対応を自動化した結果を紹介します。 概要 Google SecOps とは トリアージと調査エージェント(TIN)とは TIN の無償トライアル エージェントの自動化(Agentic Automation)とは 注意点 検証の手順 TIN の有効化 アラートの確認 概要 TIN なし(有効化前のアラート) TIN あり(有効化後のアラート) TIN を組み込んだ Playbook の作成 Playbook の作成 起動条件の設定 AI Agents ステップの追加 条件分岐の設定 Branch のアクション設定 Playbook の動作確認 概要 Google SecOps とは Google Security Operations (以下、Google SecOps)は、Google Cloud のセキュリティ運用プラットフォームです。SIEM、SOAR、脅威インテリジェンス、Gemini を利用した AI による運用支援を一つのプラットフォームで提供します。 詳細は以下の記事をご参照ください。 blog.g-gen.co.jp トリアージと調査エージェント(TIN)とは トリアージと調査エージェント (Triage and Investigation Agent、以下 TIN )は、Google SecOps に組み込まれた AI ベースの調査エージェントです。関連するイベントやユーザー・端末・IP の確認・分析などを自動で行います。 TIN は、アラートを受け取ると主に以下の 3 つを出力します。 出力 内容 判定 アラートが実際の脅威か、誤検知かを分類する 確信度 判定にどれだけ自信があるかを High Confidence (高い確信度)などのラベルで示す アラートと調査結果の要約 判定の根拠と推奨される次のアクションを記述する TIN は、アラート発生後に自動で調査を開始する 自動調査 と、管理者が必要に応じて開始する 手動調査 の両方に対応しています。 参考 : トリアージ エージェントと調査エージェントを使用してアラートを調査する TIN の無償トライアル 2026 年 4 月 1 日〜6 月 30 日の期間、TIN の無償トライアルが提供されています。対象は Google SecOps の Enterprise / Enterprise Plus サブスクリプション、および Google Unified Security です。 トライアル期間中の 1 時間あたりの実行回数の上限は以下のとおりです。 対象サブスクリプション 実行回数の上限(1 時間あたり) 内訳 Enterprise 10 回 自動 5 回、手動 5 回 Enterprise Plus / Google Unified Security 20 回 自動 10 回、手動 10 回 参考 : Google エージェント SOC のトライアルの詳細 参考 : Google Unified Security エージェントの自動化(Agentic Automation)とは エージェントの自動化 (以下、 Agentic Automation )は、Google SecOps の Playbook(アラート対応手順を自動化するワークフロー)に AI Agent を 1 つのステップとして組み込める仕組みです。AI の判定に応じて、後続の対応を分岐・自動化できます。 参考 : エージェントの自動化 参考 : [Playbooks] ページを確認する 当記事では、TIN と Agentic Automation を以下のように組み合わせます。 機能 役割 TIN AI がアラートを一次調査し、判定・確信度・アラートと調査結果の要約を出力する Agentic Automation TIN の調査結果に応じて、後続の対応を自動で振り分ける 注意点 Agentic Automation は、2026 年 5 月現在、 Preview 版 です。当記事で解説する内容は一般提供(GA)の際に変更される可能性がある点に留意してください。 Preview 版のサービスや機能を使う際の注意点は、以下の記事も参考にしてください。 blog.g-gen.co.jp 検証の手順 当記事では、以下の流れで検証を行います。 項番 内容 説明 1 TIN の有効化 Google SecOps コンソールから TIN を有効化します。 2 アラートの確認 同種のアラートが TIN の有効化前と有効化後で管理者にどのように見えるかを確認します。 3 TIN を組み込んだ Playbook の作成 Playbook に TIN を組み込み、誤検知の可能性が高いと判定したケースを自動でクローズする条件分岐を設定します。 4 Playbook の動作確認 アラートを再度発生させ、新規のケースがクローズされることを確認します。 TIN の有効化 Google SecOps の管理画面で Gemini アイコンを選択し、[Gemini Investigations] を有効化します。 TIN の有効化 TIN の実行設定は [Settings] > [SIEM Settings] > [Gemini Investigations] から確認・変更できます。 TIN の設定確認 参考 : トリアージ エージェントと調査エージェントを使用してアラートを調査する アラートの確認 概要 TIN を有効化する前と後で、同じ種類のアラートが管理者にどう見えるかを比較します。 当検証では、Google Workspace の監査ログから検知されたアラート 「Two Factor Authentication Enforcement Removal by a Workspace Admin User」 (Google Workspace 管理者による組織全体の 2 段階認証プロセス強制設定の無効化を示すアラート)を使用します。 TIN なし(有効化前のアラート) TIN が有効化されていない場合のアラート画面です。画面上部の [Run investigation] から手動で TIN の調査を実行することもできます。 アラート(TIN 未使用) TIN あり(有効化後のアラート) TIN が有効化された状態では、アラート発生後に自動で調査が実行され、結果が表示されます。[View investigation] を選択することで、詳細を確認できます。 アラート(TIN 使用) TIN によるアラート調査結果1 TIN によるアラート調査結果2 上記の調査結果から分かることは以下のとおりです。 項目 結果 判定 False Positive(誤検知) 確信度 High Confidence(高) アラート要約 日本国内の Google Workspace 管理者ユーザーによる、組織レベルの 2 段階認証設定の無効化 調査結果の要約 同じユーザーが同じ IP アドレスから、2 段階認証に関する設定変更を短時間で実施していたことが判明 推奨される次のアクション 5 件提示。うち 2 件は TIN が自動で追加調査できる項目、3 件は管理者による確認・対応が必要な項目 調査タイムライン 関連 IP・ユーザーに関するログ検索を自動実行し、時系列を表示 TIN を組み込んだ Playbook の作成 Playbook の作成 [Response] > [Playbooks] > [Create a new Playbook] を選択します。 Playbook の作成1 以下を選択し、[Create] を選択します。 設定項目 値 補足 Type Playbook 単体で実行可能なワークフロー全体(Block は複数の Playbook から呼び出せる再利用可能な処理ブロック) Choose Folder Default Playbook の整理用フォルダー Environment Default Environment 適用先のテナント環境 Playbook の作成2 参考 : [Playbooks] ページを確認する 参考 : ハンドブックのブロックを操作する Playbook の編集画面が開きます。画面上部の [Create Playbook with Gemini] から Gemini を使って作成することもできます。 Playbook の編集画面 参考 : Gemini でハンドブックを作成、編集する 起動条件の設定 左側の [Drag a trigger over here] エリアに、 Triggers から All(すべてのアラート) をドラッグして追加します。Trigger は Playbook の起動条件で、対象アラートを絞り込む役割を持ちます。 Trigger の設定 参考 : ハンドブックでトリガーを使用する 参考 : ハンドブックでアラートタイプ トリガーを使用する AI Agents ステップの追加 右側の [Drag a step over here] エリアに、 AI Agents タブから Triage and Investigation Agent (TIN)をドラッグして追加します。 AI Agent ステップの追加 追加した AI Agent ステップをダブルクリックし、[Settings] へ移動することで設定を確認できます。 設定項目 内容 Action Type Automatic :Playbook 実行時に自動で TIN を起動。 Manual :ケース画面から手動で実行 Retry on failure 実行失敗時に再試行するか If step fails Stop playbook :実行失敗時に以降のステップを停止。 Skip step :実行失敗時はスキップして次のステップへ TIN の設定 参考 : エージェントの自動化 条件分岐の設定 Flow タブから Condition をドラッグして AI Agent ステップの後に配置します。Condition は Branch (条件式に一致した経路)と ELSE (いずれにも一致しなかった経路)で構成されます。 条件分岐の設定 追加した Condition_1 をダブルクリックし、Branch の条件式を設定します。左側のフィールド入力欄を選択し、[Playbook] > [Triage and Investigation Agent_1.JsonResult] > [Builder] を選択します。 Branch の条件設定1 verdict (TIN の判定)を選択し、[Insert] を選択します。 Branch の条件設定2 右側の項目で手動で False Positive と入力すると、1 つ目の条件「Verdict = False Positive」が完成します。続いて + で条件を追加し、同様に Builder を開きます。 Branch の条件設定3 confidence (TIN の確信度)を選択し、[Insert] を選択します。 Branch の条件設定4 右側の項目で手動で High Confidence と入力し、[Save] を選択します。2 つ目の条件「Confidence = High Confidence」が完成します。 Branch の条件設定5 設定後の Playbook は次のように動作します。 段階 条件 動作 起動 すべてのアラート Playbook が起動し、TIN が一次調査を実施 条件一致 Verdict が False Positive かつ Confidence が High Confidence (誤検知の可能性が高い) ケースを自動クローズ 条件不一致 上記以外 Playbook 側では追加処理を行わない(管理者は通常どおりアラート画面で確認) 参考 : ハンドブックでフローを使用する Branch のアクション設定 Actions タブから、条件を満たした際の動作を設定します。当検証では、アラートを含むケース単位でクローズするため、 Close Case を選択し、Branch 側の [Drag a step over here] エリアに配置します。 Close Case の設定1 Siemplify_Close Case_1 をダブルクリックし、以下を設定して [Save] を選択します。 設定項目 値 補足 Reason Not Malicious クローズの理由:悪意なし/誤検知 Root Cause Lab test 根本原因:検証目的のテスト Comment TIN による自動クローズ( False Positive / High Confidence ) クローズ時に記録する任意のコメント Close Case の設定2 参考 : ケースを解決してクローズする これで、TIN が False Positive / High Confidence (誤検知の可能性が高い)と判定した場合に、ケースが自動的にクローズされる Playbook が完成します。最後に、右上の [Save] を選択して Playbook を保存します。 Playbook の保存 Playbook の動作確認 作成した Playbook の動作を検証するため、前述の 2 段階認証の設定変更を再度実施します。発生したアラートに対して TIN の調査が自動的に走り、対象ケースが自動でクローズされていることを確認します。 ケースの確認 Playbook の状況確認1 Playbook の状況確認2 三浦 健斗 (記事一覧) クラウドソリューション部 2023年10月よりG-genにジョイン。元オンプレ中心のネットワークエンジニア。 ネットワーク・セキュリティ・唐揚げ・辛いものが好き。 Google Cloud Partner All Certification Holders 2025 / Google Cloud Partner Top Engineer 2026
G-gen の佐々木です。当記事では、Google Cloud にデプロイした AI エージェントに固有のアイデンティティを付与する Agent Identity の仕組みと、Agent Identity を用いた認証方式について解説します。 概要 Agent Identity とは サービスアカウントとの違い Agent Identity の基本 SPIFFE 形式の識別子 エージェント認証情報 セキュリティとガバナンス 認証方式 サポートされる認証方式 認証マネージャー 認証プロバイダー Agent Identity の設定例 概要 Agent Identity とは Agent Identity は、Google Cloud 上で動作する AI エージェントに SPIFFE 標準に基づく安全なアイデンティティを付与する仕組みです。これにより、エージェントは MCP サーバー、Google Cloud リソース、外部 API、他のエージェントに対して、自身の権限で安全に認証できます。 参考 : Agent Identity overview 参考 : SPIFFE 2026年9月現在、Agent Identity を使用した認証に対応しているエージェント実行基盤は以下の3つです。 Agent Runtime(旧称 Vertex AI Agent Engine) Gemini Enterprise Cloud Run(2026年9月現在 Preview 公開) Cloud Run では、サービスまたはジョブのデプロイ時に Agent Platform 機能を有効化することで、Agent Identity が割り当てられます。 Cloud Run での設定方法については、以下の記事を参照してください。 blog.g-gen.co.jp サービスアカウントとの違い 従来、エージェントの実行環境にはサービスアカウントを利用するのが一般的でしたが、この方式ではサービスアカウントが本来意図しない用途で使用される可能性があります。Agent Identity はこの問題を解決するもので、サービスアカウントとは以下の点で異なります。 項目 サービスアカウント Agent Identity 複数ワークロードでの共有 可能 複数のエージェントで同じサービスアカウントを使い回すこともできてしまう 不可 エージェント単位で ID が発行される 権限借用(impersonation) 可能 別のプリンシパルにサービスアカウントの借用(なりすまし)を許可することもできてしまう 不可 エージェント自身以外は ID を使用できない 長期キーの手動生成 可能 サービスアカウントキーはデフォルトで有効期限がなく、漏洩した場合は無効化しない限り悪用され続けてしまう 不可 トークンのバインド なし アクセストークンを入手した第三者がそのまま使用できてしまう あり トークンが X.509 証明書と紐付き、意図された実行環境以外では使用できない Agent Identity の基本 SPIFFE 形式の識別子 Agent Identity に対応した環境にエージェントをデプロイすると、エージェントに固有の SPIFFE ID が自動で割り当てられます。Agent Identity が付与する ID は SPIFFE ID と呼ばれ、書式は以下のとおりです。 spiffe://<トラストドメイン>/resources/<サービス名>/<リソースパス> IAM ポリシーで SPIFFE ID を参照する際は、プレフィックスとして spiffe:// ではなく principal:// もしくは principalSet:// を使用します。 対象 識別子 単一エージェント(Agent Runtime) principal://agents.global.org-<組織ID>.system.id.goog/resources/aiplatform/projects/<プロジェクト番号>/locations/<ロケーション>/reasoningEngines/<エンジンID> 単一エージェント(Gemini Enterprise) principal://agents.global.org-<組織ID>.system.id.goog/resources/discoveryengine/projects/<プロジェクト番号>/locations/global/collections/default_collection/engines/<アプリID> 単一エージェント(Cloud Run サービス) principal://agents.global.org-<組織ID>.system.id.goog/resources/run/projects/<プロジェクト番号>/locations/<リージョン>/services/<サービス名> 単一エージェント(Cloud Run ジョブ) principal://agents.global.org-<組織ID>.system.id.goog/resources/run/projects/<プロジェクト番号>/locations/<リージョン>/jobs/<ジョブ名> プロジェクト内の全エージェント principalSet://agents.global.org-<組織ID>.system.id.goog/attribute.platformContainer/aiplatform/projects/<プロジェクト番号> 組織内の全エージェント principalSet://agents.global.org-<組織ID>.system.id.goog/* エージェント認証情報 Agent Identity を有効化したエージェントには、24時間有効な X.509 証明書が自動でプロビジョニングされます。エージェントはこの証明書を使用して Google Cloud アクセストークンを取得します。 デフォルトで Context-Aware Access ポリシーが適用され、DPoP(Demonstrable Proof of Possession)と mTLS の使用が強制されます。これによりアクセストークンが X.509 証明書にバインドされ、エージェントの実行環境以外では使用できない仕組みになっています。 参考 : RFC 9449: OAuth 2.0 Demonstrating Proof-of-Possession (DPoP) セキュリティとガバナンス Agent Identity では、Google Cloud の各種セキュリティ関連サービスとの統合により、認証情報の保護とアクセス制御のための多層的な仕組みが提供されています。 機構 内容 Context-Aware Access デフォルトで Google マネージドのポリシーが適用され、DPoP と mTLS により証明書にバインドされたトークンを保護する(前述) IAM ポリシー Allow ポリシー / Deny ポリシーによる標準的なアクセス制御をエージェントの ID に適用できる プリンシパルアクセス境界ポリシー 他の IAM 権限付与にかかわらず、エージェントがアクセスできるリソースの範囲を制限できる VPC Service Controls サービス境界の Ingress / Egress ルールでエージェントの ID を条件に指定できる。また、Agent Identity API( agentidentity.googleapis.com )と Agent Identity Credentials API( agentidentitycredentials.googleapis.com )をサービス境界で保護できる 参考 : Google CloudのIAMにおけるDenyポリシーを解説 - G-gen Tech Blog 参考 : プリンシパルアクセス境界ポリシー(Principal access boundary policies)を解説 - G-gen Tech Blog 参考 : VPC Service Controlsを分かりやすく解説 - G-gen Tech Blog 認証方式 サポートされる認証方式 エージェントが「何に対して」「どの権限で」認証するかによって、選択する方式が変わります。Agent Identity でサポートされる方式は以下のとおりです。 方式 権限タイプ 認証対象 主な用途 クラウドベースの ID エージェント自身 Google Cloud Google Cloud の他サービスへアクセスする 3-legged OAuth ユーザー委任 外部ツール・サービス ユーザーの同意を得て、その代理で Jira や GitHub などにアクセスする 2-legged OAuth エージェント自身 外部ツール・サービス ユーザー同意なしにエージェント自身の資格情報で認証する API キー エージェント自身 外部ツール・サービス API キーで認証する外部サービスにアクセスする HTTP Basic Auth エージェント自身 外部ツール・サービス 非推奨(平文パスワード) 5つの方式はいずれもエージェントに付与された SPIFFE ID を前提としますが、その使われ方が異なります。 Google Cloud へのアクセス(クラウドベースの ID)では、Agent Identity が発行する SPIFFE ID と X.509 証明書そのものが資格情報となり、エージェントの SPIFFE ID に IAM ロールを付与するだけで利用できます。一方、外部ツールへの 3-legged OAuth・2-legged OAuth・API キーの3つの方式では、Agent Identity を起点に、後述する認証マネージャーに保管された外部サービス用の認証情報を取り出して使います。 認証マネージャー Agent Identity 認証マネージャー は、外部サービスへの認証情報(API キー、OAuth クライアント ID / シークレット、エンドユーザー OAuth トークン)を Google マネージドのボールトに保管し、エージェントの実行時に自動で注入する仕組みです。エージェント開発者がコード内に秘匿情報をハードコードしたり、自前で安全に保管したりする必要がなくなります。 ボールトに保管された認証情報はすべてエージェントの SPIFFE ID に帰属する形で管理されるため、どのエージェントがどの認証情報を使用したかを IAM ポリシーと監査ログの両方で追跡できます。 参考 : Agent Identity auth manager overview 認証プロバイダー 認証プロバイダー は、認証マネージャーが管理する認証情報を登録するためのリソースで、認証先のサービスごとに作成します。 認証マネージャーによってエージェントが外部サービスにアクセスする際の流れは以下のとおりです。 エージェントの SPIFFE ID と認証先のサービスの情報を元に、対応する認証プロバイダーが特定される 認証プロバイダーに紐付く認証情報がボールトから取り出される エージェントに認証情報が注入される エージェントが注入された認証情報を使用して外部サービスにアクセスする 認証プロバイダーは認証方式ごとに以下の3種類があり、いずれもプロジェクト内、ロケーション単位で管理されます。 種類 認証対象の例 ユーザー同意 特徴 3-legged OAuth 認証プロバイダー Jira、GitHub などの外部 SaaS 必須 ユーザーの代理でアクセスする。認証マネージャーが同意画面へのリダイレクトとトークン保管を仲介する 2-legged OAuth 認証プロバイダー ServiceNow、Salesforce など 不要 エージェント自身のアイデンティティでクライアント認証情報を交換する API キー認証プロバイダー Google Maps API など — API キーを Google マネージドのボールトに保管し、コードへのハードコードを避けられる 認証プロバイダーは Agent Identity API ( agentidentity.googleapis.com )のリソースとして、 projects/<プロジェクトID>/locations/<ロケーション>/authProviders/<認証プロバイダー名> の形式で管理されます。 作成した認証プロバイダーをエージェントから使用するには、この認証プロバイダーのリソースに対して、エージェントの SPIFFE ID に Agent Identity User( roles/agentidentity.user )ロールを付与します。 なお、認証マネージャーが Preview 公開だった期間は、IAM Connectors API( iamconnectors.googleapis.com )で認証プロバイダーを管理していました。この API は GA にならず、2026年8月現在は Agent Identity API に置き換えられています。 IAM Connectors API で作成した認証プロバイダーは、Agent Identity API 側に自動でミラーされます。 一方、 projects/<プロジェクトID>/locations/<ロケーション>/connectors/<認証プロバイダー名> 形式のリソース名を参照するエージェントのコードと、IAM Connector User( roles/iamconnectors.user )ロールの付与は、移行ガイドに従って更新する必要があります。 その他、具体的な登録手順やエージェントからの使用方法は、以下の公式ドキュメントを参照してください。 参考 : Authenticate using 3-legged OAuth with auth manager 参考 : Authenticate using 2-legged OAuth with auth manager 参考 : Authenticate using API key with auth manager 参考 : Manage Agent Identity auth providers 参考 : Migrate to Agent Identity API 参考 : Agent Identity locations Agent Identity の設定例 ここでは、最も基本的なクラウドベースの ID で Google Cloud のサービスにアクセスする方式(認証マネージャー / 認証プロバイダーの登録が不要な方式)の例を示します。 Agent Identity を有効化するには、エージェントをデプロイする際に、 config.identity_type として AGENT_IDENTITY を指定します。Agent Runtime の場合は、 client.agent_engines.create() を使用する際に config に以下を含めます。 import vertexai from vertexai import types from vertexai.agent_engines import AdkApp client = vertexai.Client( project= "PROJECT_ID" , location= "LOCATION" , http_options= dict (api_version= "v1beta1" ) ) app = AdkApp(agent=agent) # 新規作成するエージェントで Agent Identity を有効化する remote_app = client.agent_engines.create( agent=app, config={ "identity_type" : types.IdentityType.AGENT_IDENTITY, # Agent Identity を有効化 "requirements" : [ "google-cloud-aiplatform[agent_engines,adk]" ], }, ) 既存のエージェントを更新して Agent Identity を有効化する場合は、 update() を使用します。 # 既存のエージェントで Agent Identity を有効化する remote_app = client.agent_engines.update( name=resource_name, config={ "identity_type" : types.IdentityType.AGENT_IDENTITY, }, ) エージェントには projects/<プロジェクト番号>/locations/<ロケーション>/reasoningEngines/<エンジンID> 形式のリソース名と、これに対応する SPIFFE ID が自動で割り当てられます。 Agent Runtime のエンジン ID は、コンソールから確認できるほか、以下のようなコマンドを使用して確認できます。 # Agent Runtime のエンジン ID を確認する $ curl -X GET \ -H " Authorization: Bearer $( gcloud auth print-access-token ) " \ " https://<ロケーション>-aiplatform.googleapis.com/v1/projects/<プロジェクトID>/locations/<ロケーション>/reasoningEngines " \ | jq -r ' .reasoningEngines[] | select(.displayName == "<エージェントの表示名>") | .name | split("/") | last ' 例として、エージェントから Cloud Run サービスを呼び出すために、対象の Cloud Run サービスに roles/run.invoker ロールを付与するコマンドを以下に示します。エージェントの SPIFFE ID は principal:// プレフィックスで指定します。 # エージェントの SPIFFE ID に Cloud Run の呼び出し権限を付与する $ gcloud run services add-iam-policy-binding < Cloud Run サービス名 > \ --region =< リージョン > \ --member =" principal://agents.global.org-<組織ID>.system.id.goog/resources/aiplatform/projects/<プロジェクト番号>/locations/<ロケーション>/reasoningEngines/<エンジンID> " \ --role =" roles/run.invoker " Agent Identity を有効化したエージェントに権限を付与する 参考 : Authenticate using an agent's own authority 参考 : Use Agent Identity with Agent Runtime 佐々木 駿太 (記事一覧) クラウドソリューション部 クラウドエンジニアリング1課 北海道在住 大学院まで社会心理学を専攻し、AI に興味を持ち IT 業界へ。2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出(2024 / 2025 Fellow / 2026)。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説(SF、ミステリ)、カラオケなど。最近は時計がマイブーム Follow @sasashun0805
G-gen の川村です。Google Workspace の生成 AI ツールである Gemini アプリや Gemini Notebook(旧 NotebookLM) を安全に運用するためのセキュリティ設定や、管理者が注意すべき点について解説します。 はじめに 概要 付属の生成 AI ツール 生成 AI ツールの外部共有機能 エンタープライズグレードのデータ保護 機能へのアクセス制御 生成 AI サービスのアクセス制御 サイドパネルのアクセス制御 CAA によるゼロトラスト制御 シャドー IT 対策と端末管理 シークレットウィンドウの使用禁止 ウェブプロキシによる個人アカウントの使用禁止 GCPW のエンドポイント保護 Chrome Enterprise Premium によるブラウザのポリシー強化 データ共有範囲の最適化 Google ドライブの共有設定 DLP でのデータ漏洩防止 IRM でのデータ持ち出し無効化 AI 分類機能 クライアントサイド暗号化の適用 運用・監査・データ保持 会話履歴の削除とデータ保持の管理 Google Vault によるデータ保持と検索 保持ポリシーの適用 データ検索 モニタリング・ログ管理 Gemini レポート Google Workspace with Gemini のログイベント AI コントロールセンター はじめに 概要 Google Workspace では Gemini アプリや Gemini Notebook などの生成 AI 機能が標準搭載されています。Google Workspace の生成 AI ツールにはエンタープライズグレードのデータ保護機能が標準で適用されていますが、組織のセキュリティポリシーやガバナンス要件に応じて、最適な環境を構築することが重要です。 管理者が意識すべき、セキュリティ対策のポイントは以下の通りです。 機能へのアクセス制御 シャドー IT 対策と端末管理 データ共有範囲の最適化 運用・監査・データ保持 当記事では、Google Workspace で上記のポイントを実現するための管理設定について紹介します。 付属の生成 AI ツール 2026年6月現在、以下のような生成 AI ツールが Google Workspace のコアサービスとして使用できます。今後もアップデートによりコアサービスが追加される可能性があります。 対象サービス 機能 特徴 Gemini アプリ 質問応答、文章生成、アイデア出し Web ブラウザやモバイルアプリからアクセスして使用できる対話型生成 AI サービス Gemini Notebook 要約、FAQ、メモの生成 アップロードしたドキュメントや PDF などのソース情報を基に回答する生成 AI サービス Google Workspace with Gemini サイドパネルでの生成 AI 補助 Gmail や Google ドライブなどのアプリケーション内で直接使用可能 Google Workspace Studio 生成 AI でのワークフローの作成 プログラミングなしで、自社の業務に合わせた生成 AI 搭載の自動化ワークフローを構築できる環境 Google Vids 動画作成・編集 生成 AI 支援でビジネス向けの動画やプレゼンテーションを容易に作成・編集できるツール 参考 : Google Workspace 利用規約 - Google Workspace 各サービスの基本機能については、以下の記事を参照してください。 blog.g-gen.co.jp 生成 AI ツールの外部共有機能 また、生成 AI によって業務が効率化できる一方、管理者が特に注意すべき 外部共有に関連する機能 が各生成 AI ツールに実装されています。以下の機能一覧を参照し、改めて組織のセキュリティポリシーに沿った設定になっているか見直すことを推奨します。 対象サービス 機能 特徴 Gemini アプリ 会話の共有 チャット内容の 外部公開機能 。組織外へのチャット履歴共有をユーザーに許可する。 Gemini アプリ Gems カスタムプロンプトの共有機能。データは Google ドライブに保存され、既存の 外部共有ポリシーが適用 される。 Google Meet Google AI によるメモの共有 作成した 議事録のデフォルトの共有先 の設定。組織外のゲスト / 組織内のゲスト / 主催者 から選択する。 Gemini Notebook ノートブックの共有 ソース資料のドライブ権限を問わない組織内共有機能 。ノートブックへのアクセス権のみでソース情報を確認できる。(※1) ※1 : Gemini Notebook のノートブック自体を外部共有することはできません。 エンタープライズグレードのデータ保護 Google Workspace ユーザーの場合、 エンタープライズグレードのデータ保護 がデフォルトで適用されています。そのため、プロンプトを含むユーザーの入力データが Google の AI モデルの学習に使用されたり、人間のレビュアーによって内容を確認されることは ありません 。 参考 : Generative AI in Google Workspace Privacy Hub | Google Workspace with Gemini | Google Workspace Help ただし、組織内での過剰な共有設定や個人アカウントの利用といったリスクには、管理者が別途対策を講じる必要があります。ここからは、セキュリティ維持のために、管理者として理解すべき機能や設定について解説します。 機能へのアクセス制御 生成 AI サービスのアクセス制御 Google Workspace で生成 AI 機能を有したサービスを使用する場合、 グループ単位や組織部門単位でのサービスへのアクセス制御が可能 です。全社展開でなく、パイロット運用として一部の組織部門から展開する場合などに設定します。 管理コンソールの「生成 AI」メニューから、以下の各サービスの「サービスのステータス」を、グループ、もしくは組織部門単位でオンまたはオフにします。 Gemini アプリ Gemini Notebook Gemini Enterprise(Google Workspace データへのアクセス制御) 参考 : Turn the Gemini app on or off | Google Workspace with Gemini | Google Workspace Help また、以下の各サービスについては、「アプリ」>「Google Workspace」からステータスを変更できます。 Workspace Studio Google Vids (「ドライブとドキュメントの設定」箇所から可能) サイドパネルのアクセス制御 Enterprise Standard 以上のエディションの場合、Gmail、Google ドライブなどの各アプリケーションで提供される Google Workspace with Gemini (サイドパネル)機能に対するアクセス制御も可能です。「生成 AI」メニューの「Google Workspace with Gemini」の項目から個別にオンまたはオフにできます。 参考 : Manage access to Gemini features in Workspace services | Google Workspace with Gemini | Google Workspace Help CAA によるゼロトラスト制御 Google Workspace の Context-Aware Access を使用すると、IP アドレスや端末の状態に基づいて、Gemini アプリや Gemini Notebook などの Google Workspace コアアプリへのアクセスを細かく制御できます。 たとえば、社外からの生成 AI の使用を禁止するために「社内 IP アドレス、かつデバイス承認が完了している端末からのアクセスのみ、Gemini アプリの使用を許可する」といった複合条件を設定できます。 blog.g-gen.co.jp シャドー IT 対策と端末管理 シークレットウィンドウの使用禁止 セキュリティポリシーによっては、シークレットウィンドウを無効化することでユーザーのブラウザ環境を常に管理下の状態に保ち、抜け道を使用したデータの持ち出しやシャドー IT の試行を防ぐことができます。 管理コンソールの「デバイス」>「Chrome」>「設定」> 「ユーザーとブラウザの設定」 箇所から適用できます。 参考 : Chrome ブラウザ ポリシーを管理する - 組織の Chrome デバイスを管理する ウェブプロキシによる個人アカウントの使用禁止 個人の Google アカウント( @gmail.com )を使用してコンシューマー向けの無償版 Gemini アプリが使用されてしまうと、データは Google により再学習等に使用されてしまう可能性があります。 ChromeOS で自組織の社内ネットワークのウェブプロキシサーバーを使用している場合、これを防ぐためにウェブプロキシサーバーにおけるドメイン制限をかけることができます。プロキシサーバー側で HTTP ヘッダー( X-GoogApps-Allowed-Domains )を追加し、これを Google 側でチェックすることで、ログイン可能なドメインを自社ドメインに限定でき、個人のアカウントの使用を防ぐことができます。 参考 : 一般ユーザー向けアカウントからのサービス利用を防ぐ | Security & data protection | Google Workspace Help GCPW のエンドポイント保護 Windows 端末を使用している環境では、 Google Credential Provider for Windows (通称、GCPW)を導入することも効果的です。 GCPW により、Windows 端末へのログイン時に Google Workspace アカウントを使用できます。ログインと同時に Google Chrome ブラウザの仕事用プロファイルに自動でログイン状態が引き継がれるため、仕組みとして会社アカウントの使用を徹底できます。 また、Windows ログイン時に Google の 2 段階認証が適用されセキュリティを向上させます。 参考 : Windows 用 Google 認証情報プロバイダをインストールする | Device management | Google Workspace Help Chrome Enterprise Premium によるブラウザのポリシー強化 ユーザーが Chrome ブラウザ上でプロンプトに組織の機密情報をアップロードしたり、コードをペーストしたりする操作自体をブラウザレベルで禁止したい場合は、 Chrome Enterprise Premium が使用できます。 追加ライセンスを購入して Chrome Enterprise Premium を設定することで、特定の Web ページに対するファイルのアップロードやコピー&ペーストのブロックなど、高度な データ漏洩防止ポリシー を Chrome ブラウザに強制できます。 blog.g-gen.co.jp データ共有範囲の最適化 Google ドライブの共有設定 Gemini アプリは、 操作ユーザーがアクセス権を持つ Google ドライブ上のファイルを参照 して回答を生成します。そのため、Google ドライブの権限管理が適切に行われている必要があります。 たとえば、人事部が社員の給与テーブルを「組織全員」に公開した状態で保存していると、本来権限を持つべきでない従業員が Gemini に質問するだけで、その機密情報が回答に含まれてしまうリスクがあります。 これは生成 AI の導入によるリスクではなく、そもそも従業員がアクセスすべきでないファイルにアクセスできる状態であり、Google ドライブの権限管理自体の不備に起因するものです。生成 AI の導入を機に、過剰な共有設定の棚卸しを実施してください。 適切な権限管理を行うには、「共有ドライブ」でのデータ運用が不可欠です。共有ドライブの仕組みや権限整理の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp DLP でのデータ漏洩防止 Data Loss Prevention (以下、DLP)は、Enterprise Standard 以上のエディションで使用でき、クレジットカード番号やマイナンバーなどの機密情報を自動検出し、組織外への情報流出を防ぐ技術です。 blog.g-gen.co.jp DLP ルールは Gemini アプリ使用時にも適用 されます。例えば、DLP ルールでドライブ内の機密ファイルの外部共有を制限している場合、Gemini アプリで生成したコンテンツにもドライブの DLP が適用され、共有がブロックされます。そのため、ユーザーがコンテンツを明示的に共有しない限り、Gemini の使用によりデータが組織外に漏洩することはありません。 参考 : Generative AI in Google Workspace Privacy Hub - How can I prevent sensitive data entered into prompts from being leaked outside my organization? Do Workspace Data Loss Prevention (DLP) capabilities apply to interactions with Gemini? IRM でのデータ持ち出し無効化 Information Rights Management (以下、IRM)とは、Google ドライブ上のデータにおけるダウンロード、コピー、印刷を権限に基づいて無効化する機能です。IRM が適用されたファイルには各生成 AI ツールがアクセスできなくなるため、前述の DLP と組み合わせて IRM を自動適用する手法が有効です。 DLP ポリシーで機密ファイルを検知し、IRM を自動適用することで、Gemini アプリをはじめとする各種生成 AI 機能は、そのファイルをもとにした回答を 生成できなく なります。これにより、意図しない機密情報の参照を根本的に遮断できます。 参考 : ユーザーがファイルをダウンロード、印刷、コピーできないようにする | Security & data protection | Google Workspace Help 参考 : Google Workspace with Gemini におけるエンタープライズ セキュリティの管理 - IRM 制御を適用して Gemini から機密データへのアクセスを制限 参考 : Generative AI in Google Workspace Privacy Hub | Google Workspace with Gemini | Google Workspace Help - Do Workspace Data Loss Prevention (DLP) capabilities apply to interactions with NotebookLM? AI 分類機能 Enterprise Plus では AI を使用したデータ分類機能 が使用できます。 Google ドライブ内のファイルをスキャンして、自動的に機密ファイルにラベルを付与できます。 通常の DLP との違いは、事前定義されたルールでは判断できない曖昧な内容を AI でパターン化して分類できる点です。このラベルをもとに DLP ルールを適用することで、組織でのデータ保護管理が容易になります。 参考 : Label Google Drive files automatically using AI classification | Security & data protection | Google Workspace Help クライアントサイド暗号化の適用 Enterprise Plus 以上のエディションでは、機密データや規制対象データをさらに厳重に保存したい場合に、 クライアントサイド暗号化 の機能を使用できます。 Google Workspace の組織のデータはデフォルトで暗号化されていますが、組織で独自の暗号鍵を使用して暗号化のレイヤを追加できる機能です。 クライアントサイド暗号化されたコンテンツは Google やサードパーティで復号できず、Gemini アプリなどの 生成 AI ツールもアクセスできません 。そのため、センシティブなデータを取り扱う政府機関や大規模な組織への導入に有効です。 参考 : Google Workspace の生成 AI に関するプライバシー ハブ | Google Workspace with Gemini | Google Workspace Help ‐ 自組織内の他の部署に機密情報が漏洩しないようにするために、Google ではどのような手法を採り入れていますか? 運用・監査・データ保持 会話履歴の削除とデータ保持の管理 ユーザーによる会話履歴データの削除可否、データの保持期間はプロダクトの仕様によって異なります。 2026年6月現在、Google Workspace ユーザーの場合、 Gemini アプリではユーザーが個別に会話履歴を削除することはできません 。管理コンソールの「Gemini 会話履歴」をオンに設定した場合、ユーザーの会話履歴が強制的に保存され、オフにするとシステム内で最大 72 時間保持された後に削除されます。 一方、 Google Workspace with Gemini (サイドパネル)での会話履歴は、管理コンソールの 「会話の履歴と削除」設定から ユーザーでの削除操作を許可 できます。 また、 Gemini Notebook では管理者での制御なしに、チャット履歴やソースとしてアップロードしたファイル・作成したノートブックに対する ユーザーでの削除操作が可能 です。 これらの各生成 AI ツールにおける、データ保持期間や制御可否については以下の表の通りです。 対象サービス データ型 保持期間 管理者 ユーザー Google Workspace with Gemini(サイドパネル) プロンプトと回答 90 日から無制限 ユーザーでの削除可否を制御 組織で許可されている場合、削除可能 Gemini アプリ プロンプトと回答 最大 36 か月 保存有無や自動削除期間を制御 削除不可 NotebookLM プロンプトと回答 - なし 削除可能 ソースデータ / ノートブック 条項第 6 条に準拠 * なし 削除可能 参考 : Cloud Data Processing Addendum | Google Cloud 参考 : Google Workspace での生成 AI のプライバシー ハブ - Gemini データの保持 参考 : Chat in NotebookLM: A powerful, goal-focused AI research partner Google Vault によるデータ保持と検索 保持ポリシーの適用 Gemini アプリのデータ保持については、管理コンソール内の「Gemini 会話履歴」の設定が Google Vault にも適用 されます。保存期間を「3 か月」「18 か月」「36 か月」から選択でき、期間内でのデータ保持・検索ができます。 Google Meet で生成 AI が作成する議事録は、Google Meet の保持ポリシーに準拠します。なお、Google Meet 固有のルールが有効になっていない場合はドライブのルールが適用されます。 参考 : サポートされているサービスとデータタイプ - Google Vault ヘルプ - Vault でサポートされるドライブと Meet のファイル データ検索 Google Vault に「案件」を作成することで、Gemini アプリのプロンプト、回答内容、トピック、日時などの メタデータを検索・監査 できます。ただし、プロンプトに添付されたファイルや生成されたファイル自体の検索には現在対応していません。 案件の作成方法は、以下の記事を参照してください。 blog.g-gen.co.jp モニタリング・ログ管理 Gemini レポート 生成 AI ツールを導入した後は、誰がどのように使っているかを把握するための継続的な監査が重要です。「生成 AI」>「Gemini レポート」から確認できるレポートでは、組織全体の Gemini アプリ使用状況やアクティブユーザー数を可視化 できます。レポート情報はスプレッドシートや CSV でのエクスポートが可能です。 Google Workspace with Gemini のログイベント 「レポート」>「監査と調査」>「Google Workspace with Gemini のログイベント」から、ユーザーが各アプリケーションでのコンテンツの生成や要約を行った際の イベントログを確認 できます。例えば「特定のユーザーが過去1週間にどのような生成 AI 機能を使用したか」といった検索や調査、エクスポートが可能です。 AI コントロールセンター 「生成 AI」>「AI コントロール センター」から確認できる AI コントロール センターでは、組織内の生成 AI 使用に当たって 包括的にレポートや各生成 AI 機能の設定を確認 できます。適切な設定が行えているか、定期的にチェックすることを推奨します。 参考 : Explore the AI control center | Google Workspace with Gemini | Google Workspace Help 川村真理 (記事一覧) クラウドソリューション部 クラウドサポート課 美容業界からITへ転身。Google Workspace 専任サポートから Google Cloud にも興味が湧き日々奮闘中。海外旅行が大好きで11カ国突破、これからも更新予定
G-gen の三浦です。当記事では、Gemini CLI から Antigravity CLI への移行を検証し、移行後に簡単な Web アプリを作成して Cloud Run へデプロイした結果を紹介します。 前提知識 Google Antigravity とは Antigravity CLI とは Gemini CLI の提供終了と Antigravity CLI への移行 概要 Antigravity CLI と Gemini CLI の違い 移行作業の対象 検証手順 移行検証用の設定 概要 Agent Skills MCP サーバー Extensions Antigravity CLI のインストールと初期設定 インストールと認証 その他の初期設定 設定の移行 Extensions の移行 Agent Skills の読み込み確認 MCP サーバーの手動移行 動作確認(開発とデプロイ) 前提知識 Google Antigravity とは Google Antigravity (以下、Antigravity)は、自然言語による指示でコードの生成、修正、実行、検証などを AI エージェントに任せられる開発プラットフォームです。このように、AI エージェントを駆使した開発スタイルは バイブコーディング (vibe coding)とも呼ばれます。 参考 : Welcome to Google Antigravity 参考 : vibe コーディングとは 2026年2月執筆時点の内容ですが、以下の記事で Antigravity を検証していますので参照してください。 blog.g-gen.co.jp Antigravity CLI とは Antigravity CLI は、Antigravity のエージェント機能をターミナルから利用できるコマンドラインツールです。 agy コマンドを通じて自然言語で指示し、コード生成、修正、調査、検証、デプロイなどを進められます。 参考 : Google Antigravity CLI Gemini CLI の提供終了と Antigravity CLI への移行 概要 Google は、個人利用者向けの Gemini CLI を Antigravity CLI へ移行する方針を発表しました。これに伴い、 2026年6月18日 以降、個人向け利用区分で使用している Gemini CLI および Gemini Code Assist の IDE 拡張機能では、リクエストが処理されなくなります。 参考 : An important update: Transitioning Gemini CLI to Antigravity CLI 提供が終了するのは個人向けの利用区分です。組織向けの Gemini Code Assist Standard / Enterprise ライセンスで利用している場合は、引き続き利用できます。 利用区分ごとの影響と対応方針は以下のとおりです。 利用区分 2026年6月18日以降 対応方針 無料(Gemini Code Assist for individuals) 利用不可 Antigravity CLI へ移行 Google AI Pro 利用不可 Antigravity CLI へ移行 Google AI Ultra 利用不可 Antigravity CLI へ移行 Gemini Code Assist Standard / Enterprise 影響なし(継続利用可能) 対応不要 Antigravity CLI と Gemini CLI の違い Antigravity CLI と Gemini CLI は、いずれもターミナル上で AI エージェントに開発作業を依頼できる CLI ツールですが、Antigravity CLI は Antigravity のエージェント基盤を利用しており、Gemini CLI とはコマンド名や一部の設定構成が異なります。 主な違いは以下のとおりです。 項目 Gemini CLI Antigravity CLI 起動コマンド gemini agy 利用モデル Gemini 系モデル Antigravity で提供される複数モデルから選択可能 拡張機能 Extensions plugins MCP サーバー settings.json で設定 mcp_config.json で設定 参考 : Antigravity CLI Features 参考 : Migrating from Gemini CLI 移行作業の対象 移行作業の対象となるのは、主に以下の設定です。 移行対象 移行作業 Antigravity CLI での扱い Agent Skills(グローバル) 不要 ~/.gemini/skills/ の skill はそのまま読み込まれる Agent Skills(ワークスペース) 要 <プロジェクト>/.gemini/skills/ から <プロジェクト>/.agents/skills/ へ手動で移行する Extensions 要 agy plugin import gemini で plugin として移行される MCP サーバー 要 手動で移行する システムプロンプト( GEMINI.md ) 不要 そのまま読み込まれる 参考 : Migrating from Gemini CLI 検証手順 検証手順は以下のとおりです。Gemini CLI から Antigravity CLI へ移行し、移行後の環境で Web アプリケーションを Cloud Run にデプロイします。 項番 内容 説明 1 インストールと初期設定 Antigravity CLI をインストールし、セットアップを実施します。 2 Gemini CLI からの移行 Agent Skills、Extensions、MCP サーバーの移行状況を確認します。 3 Web アプリの作成と Cloud Run へのデプロイ 移行後の環境から、 agy で Web アプリを Cloud Run へデプロイします。 当記事の検証で使用した環境は以下のとおりです。 項目 値 OS Windows 11 Pro 実行環境 WSL2(Ubuntu) 移行元 Gemini CLI バージョン 0.44.1 Antigravity CLI バージョン 1.0.3 移行検証用の設定 概要 Gemini CLI から Antigravity CLI への移行を確認するため、移行元の Gemini CLI に skill、MCP サーバー、Extensions を用意します。これらの設定が Antigravity CLI 側でどのように引き継がれるかを確認します。 Agent Skills Agent Skills は、AI エージェントに専門的な手順や知識を追加するための機能です。skill は配置する場所によって移行作業の要否が変わるため、当検証ではグローバルとワークスペースの両方を用意します。 参考 : Agent Skills グローバル グローバル( ~/.gemini/skills/ )に配置した skill は、Antigravity CLI からもそのまま読み込まれるため、移行作業は不要です。ここでは、Flask で Web アプリの雛形を作成する skill を用意します。 --- name: flask-webapp description: Flask で簡単な Web アプリを作成する手順。Web アプリの雛形を作りたいときに使う。 ---   # Flask Web アプリ作成   1. `requirements.txt` に flask と gunicorn を記載する。 2. `main.py` にルーティングとエンドポイントを定義する。 3. 環境変数 `PORT` を参照してリッスンする(Cloud Run 対応)。 4. ローカルで起動し、ブラウザで表示を確認する。 Gemini CLI に Agent Skills が登録されていることを確認します。 $ gemini skill list   flask-webapp [ Enabled ] Description: Flask で簡単な Web アプリを作成する手順。Web アプリの雛形を作りたいときに使う。 Location: /home/miurak/.gemini/skills/flask-webapp/SKILL.md ワークスペース プロジェクトごとのワークスペース( <プロジェクト>/.gemini/skills/ )に配置した skill は、Antigravity CLI 用のディレクトリ( <プロジェクト>/.agents/skills/ )へ手動で移動する必要があります。ここでは、移行を確認するための skill を用意します。 --- name: hello-workspace description: ワークスペースに配置した移行確認用のサンプル skill。 ---   # ワークスペース skill   1. ワークスペースの移行確認用のサンプルです。 Gemini CLI に Agent Skills が登録されていることを確認します。 $ gemini skill list   ~省略~   hello-workspace [ Enabled ] Description: ワークスペースに配置した移行確認用のサンプル skill。 Location: < プロジェクト > /.gemini/skills/hello-workspace/SKILL.md MCP サーバー MCP サーバー は、AI エージェントに外部サービスやツールを操作するための機能を提供するサーバーです。当検証では、Google が提供している Cloud Run のリモート MCP サーバーを使用します。 参考 : MCP servers with Gemini CLI 参考 : Google Cloud MCP servers overview 参考 : Cloud Run リモート MCP サーバーを使用する Gemini CLI に MCP サーバーが登録されていることを確認します。 $ gemini mcp list   ✓ cloud-run: https://run.googleapis.com/mcp ( http ) - Connected Extensions Extensions は、Gemini CLI に機能を追加するための拡張機能です。当検証では、AI エージェントがライブラリの最新ドキュメントやコード例を参照できるように、 Context7 を利用します。 参考 : Build Gemini CLI extensions 参考 : Context7(Gemini CLI Extensions) Gemini CLI に Extensions が登録されていることを確認します。 $ gemini extensions list   ✓ context7 ( 1 . 0 . 0 ) ~省略~ Antigravity CLI のインストールと初期設定 インストールと認証 公式ドキュメントに従い、Antigravity CLI をインストールします。WSL(Linux)の場合、以下のコマンドでインストールします。 curl -fsSL https://antigravity.google/cli/install.sh | bash   ⠋ Detecting system environment... ✓ Platform detected: linux_amd64 ⠋ Querying release repository... ✓ Latest available version: 1 . 0 . 3 ⠋ Downloading release package... ✓ Download complete and checksum verified. ⠋ Extracting binary from archive... ⠋ Configuring shell environment...   ✅ Antigravity CLI installed successfully at /home/miurak/.local/bin/agy Run ' agy ' to start the CLI 以下のコマンドで Antigravity CLI を実行します。 $ agy 初回起動時には、ログイン方式を選択します。当検証では 1. Google OAuth を選択します。 ログイン方式 紐づけ先 Google OAuth Google アカウント Use a Google Cloud project Google Cloud プロジェクト     ▄▀▀▄ ▀▀▀▀▀▀ ▀▀▀▀▀▀▀▀ ▄▀▀ ▀▀▄ ▄▀▀ ▀▀▄   Welcome to the Antigravity CLI. You are currently not signed in .   Select login method: > 1 . Google OAuth 2 . Use a Google Cloud project   [ Use arrow keys to navigate, Enter to select ]   参考 : Installation & auth 参考 : Getting Started with Antigravity and Gemini Enterprise Agent Platform ブラウザが起動するので、Google アカウントを選択します。 Google アカウントの選択 認証コードが表示されるので、ターミナルに戻ってコードを貼り付け、Enter キーを押します。   If you aren ' t automatically redirected, paste the authorization code below:   ★コードをペーストする★   その他の初期設定 テーマを選択します。当検証では terminal を選択しました。また、同じ画面の下部に Gemini CLI からの移行オプションが表示されていたため、 Import extensions from Gemini CLI を選択し、 Next を選択します。   Welcome to Antigravity CLI!   Choose your color scheme: ╭─────────────────────────────────────────────────────────────╮ │ > you: add a greeting function │ * terminal │ │ light │ Here ' s the change: │ solarized light │ │ colorblind-friendly light │ 3 import "fmt" │ dark │ 4 │ solarized dark │ 5 - func main() { │ colorblind-friendly dark │ 5 + func greet(name string) { │ tokyo night │ 6 + fmt.Printf("Hello, %s!\n", name) │ │ 7 } │ │ │ │ ▾ Thought Process │ │ I need to add a greeting function. I ' ll use fmt.Printf. │ │ ⚙ tool: write_file main.go │ │ ◉ task: Implementing greeting │ │ ✗ error: compilation failed │ │ ⚠ warning: deprecation warning │ │ → link: file:///path/to/main.go │ │ ★ accent: highlighted text │ │ · dim: press Enter to continue │ ╰─────────────────────────────────────────────────────────────╯   Migration options:   [ x ] Import extensions from Gemini CLI ( 1 found: context7 )   > Next   ↑/↓ Navigate · enter Confirm   次に、利用規約とデータ利用に関する確認画面が表示されます。Interactions data は Antigravity CLI とのやり取りに関するデータです。当検証では、収集・利用に同意するチェックボックスが選択されていたため、チェックを外して Done を選択しました。   Terms of Service & Data Use   AI coding agents are known to have certain security risks, including autonomous code execution, data exfiltration, prompt injection and supply chain risks. Ensure that you monitor and verify all actions taken by the agent.   -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------   [ ] Yes, I agree to help improve Antigravity CLI by allowing Google to collect and use my Interactions data, subject to the Google Antigravity CLI Terms of Service and Google Privacy Policy. I understand I can choose to opt out later whenever I want via my settings.   Links: - Terms of Service: https://antigravity.google/terms - Privacy Policy: https://policies.google.com/privacy   [ Previous ] > Done     ↑/↓ Navigate · enter Confirm     現在の作業フォルダを信頼するかどうかの確認画面が表示されるので、 Yes, I trust this folder を選択します。 Accessing workspace:   /home/miurak/work/develop/blog   Do you trust the contents of this project?   Antigravity CLI requires permission to read , edit, and execute files here.   > Yes, I trust this folder No, exit   ↑/↓ Navigate · enter Confirm   初期設定は以上です。 設定の移行 Extensions の移行 インストール時に Import extensions from Gemini CLI を選択しましたが、当検証環境ではインストール直後に agy plugin list で確認したところ、import 済みの plugin は1件も表示されませんでした(2026年5月現在の検証状況)。 $ agy plugin list No imported plugins. そのため、明示的に以下のコマンドを実行し、Gemini CLI の Extensions を Antigravity CLI の plugin へ移行しました。 $ agy plugin import gemini [ ok ] context7 ✔ skills : 3 processed - agents : skipped ( not found ) - commands : skipped ( not found ) ✔ mcpServers : 1 processed - hooks : skipped ( not found )   Staged to /home/miurak/.gemini/config   以下のコマンドで移行されていることを確認します。 $ agy plugin list { " imports " : [ { " name " : " context7 " , " source " : " gemini-cli " , " importedAt " : " 2026-05-30T03:02:51Z " , " components " : [ " skills " , " mcpServers " ] } ] } ここで表示されている skills および mcpServers は、Context7 plugin に同梱されている設定です。事前準備した移行検証用の skill や MCP サーバーとは別物です。 参考 : Migrating from Gemini CLI Agent Skills の読み込み確認 Antigravity CLI を起動し、 /skills コマンドで移行検証用の skill が表示されることを確認します。 グローバル(移行不要) グローバルに配置した flask-webapp は、移動なしで Shared skills に表示されました。 /skills   Skills 4 skills   Create new skills Workspace: ~/work/develop/blog/.agents/skills/ { skill_name } /SKILL.md Global: ~/.gemini/antigravity-cli/skills/ { skill_name } /SKILL.md Shared: ~/.gemini/skills/ { skill_name } /SKILL.md   Shared skills · From ~/.gemini/skills flask-webapp: Flask で簡単な Web アプリを作成する手順。Web アプリの雛形を作りたいときに使う。   /home/miurak/.gemini/antigravity-cli/plugins/context7/skills · From ~/.gemini/antigravity-cli/skills.json   ~省略~   ワークスペース(手動移行) ワークスペースの hello-workspace は、移動前のためまだ表示されていません。Gemini CLI のディレクトリ( <プロジェクト>/.gemini/skills/ )から Antigravity CLI 用のディレクトリ( <プロジェクト>/.agents/skills/ )へ移動します。 $ mkdir -p .agents/skills $ mv .gemini/skills/hello-workspace .agents/skills/hello-workspace 再度 /skills コマンドで確認すると、 hello-workspace が Workspace skills に表示されました。 /skills   Skills 5 skills   Create new skills Workspace: ~/work/develop/blog/.agents/skills/ { skill_name } /SKILL.md Global: ~/.gemini/antigravity-cli/skills/ { skill_name } /SKILL.md Shared: ~/.gemini/skills/ { skill_name } /SKILL.md   Workspace skills · Workspace config hello-workspace: ワークスペースに配置した移行確認用のサンプル skill。   Shared skills · From ~/.gemini/skills flask-webapp: Flask で簡単な Web アプリを作成する手順。Web アプリの雛形を作りたいときに使う。   /home/miurak/.gemini/antigravity-cli/plugins/context7/skills · From ~/.gemini/antigravity-cli/skills.json   ~省略~   MCP サーバーの手動移行 Gemini CLI と Antigravity CLI では MCP の設定形式が異なるため、Cloud Run のリモート MCP サーバーは Antigravity CLI の MCP 一覧に表示されませんでした。そのため、手動で移行します。 /mcp   MCP Servers   Plugins ( ~/.gemini/antigravity-cli/plugins ) > ✓ context7 Tools: resolve-library-id, query-docs   移行元の Gemini CLI 側( ~/.gemini/settings.json )の記述は以下のとおりです。 { " mcpServers ": { " cloud-run ": { " httpUrl ": " https://run.googleapis.com/mcp ", " headers ": { " Authorization ": " Bearer ${ACCESS_TOKEN} " } } } } Antigravity CLI 側の MCP 設定ファイル(当検証環境では ~/.gemini/config/mcp_config.json )に、以下の内容を配置します。Gemini CLI の httpUrl は、Antigravity CLI では serverUrl に変更します。 { " mcpServers ": { " cloud-run ": { " serverUrl ": " https://run.googleapis.com/mcp ", " headers ": { " Authorization ": " Bearer ${ACCESS_TOKEN} " } } } } Antigravity CLI を起動し、 /mcp コマンドで Cloud Run MCP サーバーが認識されていることを確認します。 /mcp   MCP Servers   Plugins ( ~/.gemini/antigravity-cli/plugins ) > ✓ cloud-run Tools: get_service, list_services, deploy_service_from_image, deploy_service_from_archive, deploy_service_from_file_contents ✓ context7 Tools: resolve-library-id, query-docs 参考 : Migrating from Gemini CLI 動作確認(開発とデプロイ) Antigravity CLI を起動し、以下のプロンプトで Web アプリの作成と Cloud Run へのデプロイを依頼します。 現在時刻を表示する簡単な Flask の Web アプリを作成し、Cloud Run にデプロイして公開 URL を教えてください。 現在時刻(日本時間: JST)を表示する Flask の Web アプリケーションを作成し、Google Cloud Run にデプロイしました。   公開 URL: https://time-app-XXXXXX.asia-northeast1.run.app   アプリケーションの概要: - JST の現在時刻を表示 - ブラウザ上で 1 秒ごとに時刻を更新 - Cloud Run の `PORT` 環境変数に対応 表示された公開 URL へアクセスし、Web ページが表示されることを確認します。 Web ページの確認 三浦 健斗 (記事一覧) クラウドソリューション部 2023年10月よりG-genにジョイン。元オンプレ中心のネットワークエンジニア。 ネットワーク・セキュリティ・唐揚げ・辛いものが好き。 Google Cloud Partner All Certification Holders 2025 / Google Cloud Partner Top Engineer 2026
G-gen の杉村です。2026年5月に発表された、Google Cloud や Google Workspace のイチオシアップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに Google I/O 2026 が開催 Google Cloud のアップデート SCC で Compliance Manager がプロジェクト単位で有効化可能に Agent Search で agentic retrieval が Allowlist 付き一般公開 BigQuery の reservation groups が一般公開(GA) Google Cloud で Certificate Manager (2nd gen) が Preview 公開 Gemini Notebook Enterprise でスライド作成/インフォグラフィックが使用可能に 新機能 Skill Registry が登場(Preview) 新機能 AI Content Detection API が登場(Private Preview) 新機能 Managed Agents API が登場(Preview) Gemini 3.5 Flash が登場(GA) AI 統合型開発ツール「Antigravity」が一新 Antigravity 2.0 が Google Cloud 認証に対応 BigQuery の Python UDF(ユーザー定義関数)が Preveiew → 一般公開(GA) Security Command Center (Premium) で Artifact guard が Preview 公開 Security Command Center の Enterprise ティアが提供終了へ Knowledge Catalog の Data products 機能が一般公開(GA) Gemini Deep Research Agent が Preview 公開 Gemini Enterprise app で Slack データストアが一般公開(GA) Nano Banana 2 と Nano Banana Pro が一般公開(GA) gemini-2.5-flash、gemini-3-flash-preview 等が新規利用の受付停止 Google Workspace のアップデート Google ドキュメントの Gemini でカスタムインストラクションを設定可能に Gemini アプリで会話結果から各種ファイルを直接生成可能に Google Workspace の公式リモート MCP サーバーが Public Preview 公開 Google Workspace Studio の Google Meet 関連が強化 Gmail の Help me write(文章作成補助)機能が強化 Google Workspace Studio で Ask Gemini Notebook が使えるようになった Google Chat のメッセージ推敲が日本語を含む多言語に対応 Gemini Notebook で Google ドライブとの自動同期が可能に はじめに 当記事では、毎月の Google Cloud(旧称 GCP)や Google Workspace(旧称 GSuite)のアップデートのうち、特に重要なものをまとめます。 また当記事は、Google Cloud に関するある程度の知識を前提に記載されています。前提知識を得るには、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp リンク先の公式ガイドは、英語版で表示しないと最新情報が反映されていない場合がありますためご注意ください。 Google I/O 2026 が開催 100 things we announced at I/O 2026 (2026-05-19 〜 2026-05-20) Google の開発者向け年次カンファレンス「Google I/O」が開催。以下のような発表がされた。 Gemini 3.5 Flash : Gemini 3.5 ファミリーが発表。Flash モデルを先行投入(Preview ではなく一般公開) Gemini Omni : 動画生成モデル。編集も可能で動画版 Nano Banana といえる Gemini Spark : バックグラウンド動作する AI エージェントサービス。まず米国の Google AI Ultra サブスクリプション 登録者向けに提供 Google Antigravity : 機能が一新され Antigravity 2.0 となった。Antigravity CLI も発表 Google Cloud のアップデート SCC で Compliance Manager がプロジェクト単位で有効化可能に Enable Compliance Manager (2026-05-11) Security Command Center で Compliance Manager がプロジェクト単位で有効化可能になった。 Compliance Manager は CIS や ISO 27001 といったセキュリティ標準への適合性をチェックできる機能。これまで組織レベルでしか使用できなかった。 Agent Search で agentic retrieval が Allowlist 付き一般公開 Stream answers using agentic retrieval (2026-05-13) Agent Search(旧 Vertex AI Search)で agentic retrieval(streamAnswer メソッド)が Allowlist 付き一般公開。 エージェンティックに複数のデータストアに対して検索。回答はストリーミングで取得。ソースコードを開発することなく、容易に検索エージェントを構築できるのが利点。 BigQuery の reservation groups が一般公開(GA) Prioritize idle slots with reservation groups (2026-05-18) BigQuery の reservation groups が一般公開(GA)。 Idol slot が生まれたときに、他の reservation に貸し出す前に、まずは同一グループ内の reservation へ優先的に割り当てる。より緻密なスロット制御が可能になった。 Google Cloud で Certificate Manager (2nd gen) が Preview 公開 Certificate Manager (2nd gen) overview (2026-05-19) Google Cloud で Certificate Manager (2nd gen) が Preview 公開。 SSL/TLS 証明書の管理サービスの次世代版。ロードバランサー向けだった1st gen に比べてGKE、Compute Engine、ハイブリッド環境への対応が強化。有効期限の一覧表示ビューなども提供。 Gemini Notebook Enterprise でスライド作成/インフォグラフィックが使用可能に Gemini Enterprise release notes ‐ May 19, 2026 (2026-05-19) Gemini Notebook Enterprise(Gemini Enterprise appに付属)でスライド作成とインフォグラフィック機能が使用可能になった(GA)。 Google Workspace 版や個人版 Gemini Notebook との差異が1つなくなり、用途が広くなった。 新機能 Skill Registry が登場(Preview) Skill Registry overview (2026-05-19) Gemini Enterprise Agent Platform の一部として、新機能 Skill Registry が登場(Preview)。 Agent Skills 用のレポジトリ。Skill を zip して base64 エンコードしてアップロードできる。組織内で Skills を効果的に共有し、車輪の再開発を防ぐことができる。 新機能 AI Content Detection API が登場(Private Preview) Detect AI-generated images (2026-05-19) Gemini Enterprise Agent Platform の一部として、新機能 AI Content Detection API が登場。 Private Preview なので要申請。AI で生成された画像を検知できる API。形式は JPEG、PNG、WebP に対応。 あくまで推定を提供するものなので注意が必要。 新機能 Managed Agents API が登場(Preview) Managed Agents API on Agent Platform overview (2026-05-19) Gemini Enterprise Agent Platform の一部として、新機能 Managed Agents API が登場(Preview)。 エージェントをクラウドのサンドボックス内で実行。システムインストラクション、ツール、コード実行などをパッケージして保存し、いつでも呼び出せる。 ドキュメントに以下が明記されている(機械翻訳)。 (略)現在様々な段階の社内テストおよびレビューを受けています。そのため、これらの製品で機密情報、秘密情報、またはその他の機密データを使用しないでください。これらの製品は、限定的なテストおよび評価のためにのみお客様に提供されており、商用または本番環境での使用はできません。 Gemini 3.5 Flash が登場(GA) Gemini 3.5:行動を起こす最先端の知能 (2026-05-19) Gemini 3.5 Flash が登場(GA)。3.5 Pro も来月提供予定。 Gemini アプリや Gemini Enterprise app のほか、Agent Platform(旧 Vertex AI)や Google AI Studio から API 経由で利用可能。 Flash モデルながら 3.1 Pro を性能で凌駕するとされている。 Gemini 3.5 Flash 料金に注意が必要。Gemini 3 Flash Preview よりもトークンあたりの単価が高額になっている。 参考 : Cost of building and deploying AI models in Agent Platform AI 統合型開発ツール「Antigravity」が一新 エージェントが主導する未来の構築:Google I/O 2026 デベロッパー向けハイライト (2026-05-20) Google の AI 統合型開発ツール Antigravity が一新し、Antigravity 2.0 となった。 従来の Antigravity は IDE(エディタを含む統合開発環境)だったが、Antigravity 2.0 は Agent Manager 機能に専念したデスクトップアプリ。複数のエージェントを動作させるためのオーケストレーターとして動作する。Antigravity 2.0 は、他の IDE などと組み合わせて使われる想定。 旧来のようなエディタ画面を持つ IDE は、Antigravity IDE として提供され続ける。Antigravity IDE は、Agent Manager を搭載していない。 また、Antigravity CLI が提供開始され、Gemini CLI は廃止の方向になる。個人アカウントでは2026年6月18日には Gemini CLI が使えなくなる。Google Workspace の Gemini Code Assist では引き続き使える(EoS 明記なし)。 Antigravity 2.0 が Google Cloud 認証に対応 Google Antigravity in Gemini Enterprise (2026-05-20) Google の AI 統合型開発ツール「Antigravity 2.0」が Google Cloud 認証に対応。Google Cloud 利用規約が適用され、入出力データは再トレーニングに使用されない。 Gemini Enterprise Agent Platform(旧 Vertex AI)経由で LLM を呼び出す。LLM は従量課金。 今後も統制関係機能が追加予定。 BigQuery の Python UDF(ユーザー定義関数)が Preveiew → 一般公開(GA) Work with user-defined functions in Python (2026-05-20) BigQuery の Python UDF(ユーザー定義関数)が Preveiew → 一般公開(GA)。 これまでは SQL 版と JavaScript 版が GA だったが、Python 版も GA になった。PyPI や Cloud Storage 上のパッケージも使用可能。 Security Command Center (Premium) で Artifact guard が Preview 公開 Artifact guard overview (2026-05-21) Security Command Center Premium および Enterprise ティアで新機能 Artifact guard が Preview 公開。 ビルド中にポリシーに準拠しているかどうかをスキャン。脆弱性のあるパッケージがデプロイされるのを未然に防止。Cloud Build、GitHub Actions、Jenkins、GKE などに対応。 Security Command Center の Enterprise ティアが提供終了へ Security Command Center release notes ‐ May 21, 2026 (2026-05-21) Security Command Center の Enterprise ティアが提供終了へ。 2027-05-21 には終了して Premium ティアへ自動移行。Enterprise は、AWS や Azure の構成チェックもできる最上位ティアだった。 付属の SecOps(SIEM)などの件は営業チームと相談を。 Knowledge Catalog の Data products 機能が一般公開(GA) About data products (2026-05-25) Knowledge Catalog(旧 Dataplex Universal Catalog)で Data products 機能が Preview から一般公開(GA)になった。 データ管理者がデータを論理的にパッケージして利用者にキュレートできる。アクセスリクエストからの承認もフロー化できる。 Gemini Deep Research Agent が Preview 公開 Use the Gemini Deep Research Agent (2026-05-26) Gemini Deep Research Agent が Preview 公開。API(REST / SDK)経由で利用可能。 パブリック Web (Google 検索)や企業データ(MCP、Agent Search、ファイル添付)に基づいて包括的なレポートを生成する。進捗のストリーミング受信も可能。 Gemini Enterprise app で Slack データストアが一般公開(GA) Overview (2026-05-27) Gemini Enterprise app で Slack データストアが Private Preview → 一般公開(GA)。 Slack に対して検索を行い、AI が回答したりタスクをこなしたりできる。 Slack 側の契約が Slack AI search をサポートするプラン(Business+ 以上)である必要あり。 Nano Banana 2 と Nano Banana Pro が一般公開(GA) Agent Platform Gemini 3.1 Flash Image and Gemini 3 Pro Image (2026-05-28) Gemini Enterprise Agent Platform(旧 Vertex AI)で画像生成モデル Gemini 3.1 Flash Image(Nano Banana 2)と Gemini 3 Pro Image(Nano Banana Pro)が Preview → 一般公開(GA)に。 4k 画像の出力は Preview 提供。また Flash は動画の入力を受けられる。これも Preview 提供。 Preview 版モデルは 2026-07-17 に廃止されるため要注意。 gemini-2.5-flash、gemini-3-flash-preview 等が新規利用の受付停止 Google Cloud からユーザーにメールで通知 (2026-05-28) 2026-06-15 以降、以下のモデルの新規利用はできなくなる。 gemini-2.5-flash gemini-2.5-flash-lite gemini-3-flash-preview 既に利用中プロジェクト、すなわち過去90日以内に上記モデルの呼び出し履歴があるプロジェクトでは、引き続きこれらのモデルが使える。 なお、正式な廃止予定(Shutdown date)は以下のとおり。 gemini-2.5-flash : October 16, 2026 gemini-2.5-flash-lite : October 16, 2026 gemini-3-flash-preview : No shutdown date announced Google Workspace のアップデート Google ドキュメントの Gemini でカスタムインストラクションを設定可能に Set custom instructions for Gemini in Google Docs (2026-05-04) Google ドキュメントの Gemini サイドパネルでカスタムインストラクションを設定できるように。 文体や要約時のトーンなどを指定できる。2026-05-04から段階的ロールアウト。 Gemini アプリで会話結果から各種ファイルを直接生成可能に Move from conversation to creation with file generation in Gemini (2026-04-27) Gemini アプリで会話結果から以下のファイルを直接生成可能になった。 Google ドキュメント、Google スプレッドシート、Google スライド PDF .docx .xlsx .csv .md ... など Google Workspace の公式リモート MCP サーバーが Public Preview 公開 New: Agent tools and security updates for Google Workspace developers (2026-05-01) Google Workspace の公式リモート MCP サーバーが Public Preview 公開。 管理操作ではなくメールやファイル取得、カレンダー予定、チャットなど、ユーザー側の操作が可能。ただし、Developer Preview に申請しないと使えないとの情報もあり。 同時に Google Workspace 系 API に新しいクォータや超過分の課金体系が整備された。AI エージェントと Google Workspace の連携で業務自動化が進むことが期待される。 Google Workspace Studio の Google Meet 関連が強化 Improvements to the Meet starter step and Calendar time-blocking capabilities in Google Workspace Studio (2026-05-06) Google Workspace Studio の Google Meet 関連が強化。 複数会議をトリガーとして指定。カレンダー上に予定を確保(ただし自分しか招待できない)。自動議事メモ(transcript)もしくは Gemini メモ(take notes for me)の完成をトリガにできる。 Gmail の Help me write(文章作成補助)機能が強化 Improvements To Help Me Write in Gmail (2026-05-01) Gmail の Help me write(文章作成補助)機能が強化。 (1) トピックコンテキスト: Googleドライブや他のメールのコンテキストを取り込んで文章を作成 (2) スタイルのパーソナライズ: 以前のメールにあわせて文体をパーソナライズ Google Workspace Studio で Ask Gemini Notebook が使えるようになった Use NotebookLM in your Google Workspace Studio flows (2026-05-12) Google Workspace Studio で Ask Gemini Notebook が使えるようになった。 例として「メール受信 → Gemini Notebook のナレッジをもとに返信文のドラフトを作成」のような業務が自動化できる。 Google Chat のメッセージ推敲が日本語を含む多言語に対応 Expanding language support for refining messages with Gemini in Google Chat (2026-05-14) Google Chat のメッセージ推敲が日本語を含む多言語に対応。 従来は英語のみだったが、新たに日本語、フランス語、ドイツ語、イタリア語、韓国語、ポルトガル語、スペイン語の 7 言語が対応。チャット入力欄の「Refine」アイコンをクリックするか、特定のテキストを選択することで、Gemini に語彙の調整、文法やスペルの修正、トーンの改善を依頼できる。 Gemini Notebook で Google ドライブとの自動同期が可能に Keep your sources up to date with automatic Drive syncing in NotebookLM (2026-05-26) Gemini Notebook で Google ドライブとの自動同期が可能になる。 これまでは Google ドライブ側のファイルが更新されると手動で同期ボタンを押す必要があった。2026-05-26から15日間かけて段階的ロールアウト。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X(旧 Twitter)では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it
G-gen の勝島です。当記事では、Gemini Enterprise Agent Platform と Cloud Monitoring の MCP サーバーを組み合わせて、エラーログの検知から AI による原因分析、Slack 通知までを自動化します。 はじめに Gemini Enterprise Agent Platform とは MCP(Model Context Protocol)とは 当記事について 背景と構成 本構成の狙い システムの構成 環境構築 環境変数の設定 API の有効化 ログルーティングの設定 サービスアカウントと IAM ロール アプリケーションの実装 ディレクトリ構成 requirements.txt main.py ソースコードの解説 Cloud Run functions へのデプロイ デプロイコマンドの実行 Cloud Run の呼び出し権限の付与 動作確認 はじめに Gemini Enterprise Agent Platform とは 2026年4月現在、 Gemini Enterprise Agent Platform (以下、Agent Platform)は、Google Cloud が提供する AI エージェントの構築・運用のための統合プラットフォーム(プロダクト群)です。 同年4月の Google Cloud Next '26 で、従来の Vertex AI から名称変更されました。Agent Platform は、エージェントの開発、スケール、ガバナンス、最適化のためのプロダクト群であるといえます。 MCP(Model Context Protocol)とは Model Context Protocol (以下、 MCP )は、AI モデルが外部ツールを呼び出すための標準プロトコルです。 Google Cloud では、Cloud Monitoring や Cloud Logging などの主要サービス向けに、フルマネージドなリモート MCP サーバーである Google Cloud MCP Servers が提供されています。当記事の構成では、AI モデルがこの MCP サーバー経由で Cloud Monitoring のメトリクスをツールとして自律的に呼び出し、原因分析に使用します。 参考 : Google Cloud MCP servers overview 参考 : MCP Reference: monitoring.googleapis.com Google Cloud MCP Servers の概要や認証方式の詳細については、以下の記事も参照してください。 blog.g-gen.co.jp 当記事について 当記事では、Cloud Logging で severity >= ERROR のログを検知した際に、Gemini モデルが MCP サーバー経由で関連メトリクスを取得し、Cloud Logging の関連ログも横断的に検索したうえで、原因の仮説と対処アクションを Slack に通知する AI エージェントを構築します。 なお、当記事の構成で使用する Cloud Run functions の全体像については以下の記事も参照してください。 blog.g-gen.co.jp 背景と構成 本構成の狙い Cloud Monitoring の標準の アラート 機能でも、しきい値ベースでの通知や Error Reporting によるエラー集計は可能です。しかし、これらは「何が起きたか」を伝えてくれるものの、「なぜ起きたのか」「どう対処すべきか」までは教えてくれません。 エラー発生時にメトリクスとログを横断的に確認し、根本原因の仮説を立てるという作業は、依然としてエンジニアの手作業に依存しています。当構成では、この一次切り分けの作業を AI エージェントに委譲することで、対応のリードタイム短縮を狙います。 システムの構成 ユーザー側で severity >= ERROR のログが Cloud Logging に書き込まれると、ログシンクを経由して Pub/Sub にメッセージが転送されます。 Pub/Sub のメッセージを受信した Cloud Run functions は、Agent Platform 経由で Gemini モデルを呼び出します。 Gemini モデルは MCP サーバー経由で Cloud Monitoring からメトリクスを取得し、さらに Cloud Logging から関連ログを検索しながら、原因の仮説と対処アクションを生成し Slack へ通知します。 構成図 なお、Pub/Sub を中心とした疎結合アーキテクチャの考え方や、Cloud Logging のログルーター(シンク)の仕組みの詳細については、以下の記事を参照してください。 blog.g-gen.co.jp blog.g-gen.co.jp 環境構築 環境変数の設定 以降のコマンドで使用する環境変数を設定します。 PROJECT_ID と SLACK_WEBHOOK_URL は、実際の環境に合わせて変更してください。 export PROJECT_ID = " your-project-id " export REGION = " asia-northeast1 " export TOPIC_NAME = " error-alerts-topic " export SINK_NAME = " error-logs-sink " export SA_NAME = " ai-ops-agent-sa " export SA_EMAIL = " ${SA_NAME} @ ${PROJECT_ID} .iam.gserviceaccount.com " export SLACK_WEBHOOK_URL = " https://hooks.slack.com/services/xxxx/xxxx/xxxx " API の有効化 対象プロジェクトをセットし、必要な API を有効化します。 gcloud config set project $PROJECT_ID gcloud services enable \ logging.googleapis.com \ pubsub.googleapis.com \ cloudfunctions.googleapis.com \ run.googleapis.com \ aiplatform.googleapis.com \ monitoring.googleapis.com \ cloudbuild.googleapis.com \ eventarc.googleapis.com 主要な API の役割は以下の通りです。 API 役割 logging.googleapis.com エラーログを検知し、Pub/Sub へルーティングする pubsub.googleapis.com エラーログを受け取り、Cloud Run functions に通知する cloudfunctions.googleapis.com 通知をトリガーに分析処理を実行する aiplatform.googleapis.com Gemini モデルでエラーの原因分析を行う monitoring.googleapis.com MCP サーバー経由でメトリクスを参照する ログルーティングの設定 Cloud Logging から Pub/Sub へエラーログを転送するための ログシンク と Pub/Sub トピック を作成します。 # Pub/Sub トピックの作成 gcloud pubsub topics create $TOPIC_NAME # ログシンクの作成(テスト用ログのみ転送) gcloud logging sinks create $SINK_NAME \ pubsub.googleapis.com/projects/ $PROJECT_ID /topics/ $TOPIC_NAME \ --log-filter =" severity>=ERROR AND logName= \" projects/ ${PROJECT_ID} /logs/my-test-log \" " --log-filter で logName を my-test-log に限定することで、動作確認用のログだけを Pub/Sub に転送する構成にしています。本番運用ではこのフィルタを実際のサービスログに合わせて変更してください。 続いて、ログシンクが Pub/Sub に書き込めるよう、ログシンクのサービスアカウントに Publisher 権限を付与します。 SINK_SA = $( gcloud logging sinks describe $SINK_NAME --format =' value(writerIdentity) ' ) gcloud pubsub topics add-iam-policy-binding $TOPIC_NAME \ --member = $SINK_SA \ --role = roles/pubsub.publisher サービスアカウントと IAM ロール Cloud Run functions が Agent Platform、Cloud Monitoring、MCP を使用するためのサービスアカウントを作成し、必要なロールを付与します。 # サービスアカウントの作成 gcloud iam service-accounts create $SA_NAME \ --display-name =" AI Ops Agent " || true # Agent Platform ユーザー gcloud projects add-iam-policy-binding $PROJECT_ID \ --member =" serviceAccount: ${SA_EMAIL} " \ --role =" roles/aiplatform.user " # Monitoring 閲覧者 gcloud projects add-iam-policy-binding $PROJECT_ID \ --member =" serviceAccount: ${SA_EMAIL} " \ --role =" roles/monitoring.viewer " # ログ閲覧者 gcloud projects add-iam-policy-binding $PROJECT_ID \ --member =" serviceAccount: ${SA_EMAIL} " \ --role =" roles/logging.viewer " # MCP ツールユーザー gcloud projects add-iam-policy-binding $PROJECT_ID \ --member =" serviceAccount: ${SA_EMAIL} " \ --role =" roles/mcp.toolUser " 各ロールの目的は以下の通りです。 ロール 目的 Agent Platform ユーザー( roles/aiplatform.user ) Gemini モデルの呼び出し Monitoring 閲覧者( roles/monitoring.viewer ) MCP 経由でのメトリクス取得 ログ閲覧者( roles/logging.viewer ) 関連ログの参照 MCP ツールユーザー( roles/mcp.toolUser ) MCP ツールの呼び出し なお、Google Cloud の MCP サーバーは「MCP プロトコル自体を呼び出す権限( roles/mcp.toolUser )」と「対象サービスのデータを参照する権限( roles/monitoring.viewer など)」の二段階の認可で保護されています。両方を付与する必要がある点に注意してください。 アプリケーションの実装 ディレクトリ構成 以下の構成でファイルを作成します。 ai-ops-function(任意のフォルダ名) ├── main.py └── requirements.txt requirements.txt 必要なライブラリを定義します。 functions-framework==3.* google-cloud-pubsub google-cloud-logging google-genai google-auth requests main.py main.py は、Pub/Sub から受け取ったエラーログを Gemini に解析させ、Slack に通知するアプリケーション本体です。 import base64 import json import os from datetime import datetime, timedelta, timezone import requests from google import genai from google.cloud import logging_v2 import google.auth from google.auth.transport.requests import Request SLACK_WEBHOOK_URL = os.environ.get( "SLACK_WEBHOOK_URL" ) PROJECT_ID = os.environ.get( "PROJECT_ID" ) MCP_SERVER_URL = "https://monitoring.googleapis.com/mcp" def get_mcp_headers (): scopes = [ "https://www.googleapis.com/auth/cloud-platform" ] credentials, _ = google.auth.default(scopes=scopes) credentials.refresh(Request()) return { "Authorization" : f "Bearer {credentials.token}" , "Content-Type" : "application/json" } def list_monitoring_mcp_tools () -> str : """MCP サーバーから使用可能なツール一覧を取得する""" payload = { "jsonrpc" : "2.0" , "method" : "tools/list" , "id" : 1 } res = requests.post(MCP_SERVER_URL, json=payload, headers=get_mcp_headers()) if not res.ok: return f "MCP tools/list API エラー (HTTP {res.status_code}): {res.text[:1000]}" result_data = res.json().get( "result" , {}) simplified_tools = [] for tool in result_data.get( "tools" , []): schema = tool.get( "inputSchema" , {}) simplified_props = {} for k, v in schema.get( "properties" , {}).items(): simplified_props[k] = { "type" : v.get( "type" , "unknown" ), "description" : v.get( "description" , "" )[: 100 ] } simplified_tools.append({ "name" : tool.get( "name" ), "description" : tool.get( "description" , "" )[: 200 ], "required_args" : schema.get( "required" , []), "properties" : simplified_props }) return json.dumps({ "tools" : simplified_tools}, indent= 2 , ensure_ascii= False ) def call_monitoring_mcp_tool (tool_name: str , arguments_json_str: str ) -> str : """指定した MCP ツールを実行してメトリクスを取得する""" arguments = json.loads(arguments_json_str) payload = { "jsonrpc" : "2.0" , "method" : "tools/call" , "id" : 2 , "params" : { "name" : tool_name, "arguments" : arguments} } res = requests.post(MCP_SERVER_URL, json=payload, headers=get_mcp_headers()) if not res.ok: return f "MCP tools/call API エラー (HTTP {res.status_code}): {res.text[:1000]}" response_data = res.json() if "result" in response_data and "content" in response_data[ "result" ]: text_result = " \n " .join( [item.get( "text" , "" ) for item in response_data[ "result" ][ "content" ]] ) return text_result[: 3000 ] + " \n ...(省略)" if len (text_result) > 3000 else text_result return f "MCP エラー: {response_data.get('error', '不明なレスポンス')}" def search_cloud_logs (filter_str: str , hours: int = 2 ) -> str : """Cloud Logging で過去 N 時間のログを検索する""" client = logging_v2.Client(project=PROJECT_ID) start_time = datetime.now(timezone.utc) - timedelta(hours=hours) full_filter = f '{filter_str} AND timestamp>="{start_time.isoformat()}"' entries = client.list_entries(filter_=full_filter, max_results= 20 ) results = [] for entry in entries: results.append({ "timestamp" : entry.timestamp.isoformat() if entry.timestamp else "" , "severity" : str (entry.severity), "resource" : entry.resource.type if entry.resource else "" , "payload" : str (entry.payload)[: 500 ] }) if not results: return "該当するログは見つかりませんでした。" text = json.dumps(results, indent= 2 , ensure_ascii= False ) return text[: 3000 ] + " \n ...(省略)" if len (text) > 3000 else text def analyze_error (event, context): """Pub/Sub からエラーログを受け取り、Gemini で分析して Slack に通知する""" pubsub_message = base64.b64decode(event[ 'data' ]).decode( 'utf-8' ) log_data = json.loads(pubsub_message) error_msg = log_data.get( "textPayload" ) or log_data.get( "jsonPayload" ) client = genai.Client(vertexai= True , project=PROJECT_ID, location= "us-central1" ) log_str = json.dumps(log_data, indent= 2 )[: 5000 ] prompt = f """ 以下のエラーログが検知されました。MCP サーバーおよび Cloud Logging と連携して調査してください。 【ログ内容】 {log_str} 【厳守事項】 原因分析にあたり、以下のステップを必ずすべて実行してください。推測(ハルシネーション)による回答や、一部のツール呼び出しの省略は許可されません。 1. `list_monitoring_mcp_tools` でツール一覧を確認してください。 2. `call_monitoring_mcp_tool` でプロジェクト {PROJECT_ID} の直近 10 分のメトリクスを取得してください。取得対象はログの文脈(「リクエストが処理しきれません」等)から判断し、Cloud Run のリクエスト数(例: metric.type="run.googleapis.com/request_count")など、負荷状況がわかる確実な標準メトリクスを指定してください。無効なクエリは避けてください。 3. `search_cloud_logs` で直近 10 分の関連するログを検索してください(severity>=WARNING など)。 【出力フォーマット】 分析結果は、必ず以下の Markdown 構造に厳密に従って出力してください。ツール名は記載せず、自然な日本語で記載してください。 ### 調査結果 1. **メトリクス分析:** (実際に取得したメトリクスの数値やスパイクの有無など、客観的な事実のみを記載) 2. **ログ分析:** (実際に検索した関連ログの件数や内容など、客観的な事実のみを記載) ### 原因の仮説 (上記の客観的データに基づき、なぜエラーが発生したのかの考察を記載) ### 対処アクション (具体的な解決策を記載) """ res = client.models.generate_content( model= 'gemini-2.5-flash' , contents=prompt, config={ "tools" : [list_monitoring_mcp_tools, call_monitoring_mcp_tool, search_cloud_logs]} ) requests.post(SLACK_WEBHOOK_URL, json={ "text" : f "🚨 *【AI 自動分析】* \n *ログ:* \n ``` \n {str(error_msg)[:1000]} \n ``` \n *分析:* \n {res.text}" }) ソースコードの解説 上記のソースコードは、大きく分けて「Gemini に渡すツール関数群」と「Pub/Sub をトリガーにエージェントを起動するエントリーポイント」の2つのパートで構成されます。 まずは、ツール関数群について解説します。このパートは、 list_monitoring_mcp_tools 、 call_monitoring_mcp_tool 、 search_cloud_logs で構成されます。 list_monitoring_mcp_tools MCP サーバーから使用可能なツール一覧を取得します。Cloud Monitoring が返すスキーマは大きく、そのまま Gemini に渡すとコンテキスト上限を超える恐れがあるため、プロパティ情報を必要最小限に絞り込んでいます。 call_monitoring_mcp_tool 指定された MCP ツールを実行し、メトリクスを取得します。 search_cloud_logs Cloud Logging から関連ログを検索します。Gemini がメトリクスだけでは原因を判断できない場合に、追加の調査手段として呼び出されます。 次に、エントリーポイント( analyze_error() )のパートについて解説します。 Pub/Sub イベントの受信 Pub/Sub から渡されたメッセージをデコードし、含まれるエラーログの内容を取り出します。 Gemini モデルの呼び出し プロンプトと使用可能ツールの一覧を渡して generate_content を実行します。プロンプトには、ツールの呼び出し順序と、最終的に出力すべき内容(原因の仮説と対処アクション)を明記しています。 Slack への通知 Gemini から返された応答を、Slack Webhook 経由で指定チャンネルに POST します。 Cloud Run functions へのデプロイ デプロイコマンドの実行 ターミナルで ai-ops-function ディレクトリに移動し、Cloud Run functions にデプロイします。 # プロジェクト番号の取得 export PROJECT_NUMBER = $( gcloud projects describe $PROJECT_ID --format =' value(projectNumber) ' ) # デプロイの実行(クリーン版) gcloud functions deploy ai-ops-analyzer \ --gen2 \ --runtime = python311 \ --region = $REGION \ --source = . \ --entry-point = analyze_error \ --trigger-topic = $TOPIC_NAME \ --service-account = $SA_EMAIL \ --trigger-service-account = ${PROJECT_NUMBER} -compute@developer.gserviceaccount.com \ --set-env-vars = SLACK_WEBHOOK_URL = $SLACK_WEBHOOK_URL , PROJECT_ID = $PROJECT_ID \ --quiet Cloud Run の呼び出し権限の付与 Cloud Run functions は、内部的には Cloud Run service として展開されます。Pub/Sub 経由でのトリガー時に正しく認証が通るよう、サービスアカウントに Cloud Run の呼び出し権限を付与します。 # プロジェクト番号の取得 export PROJECT_NUMBER = $( gcloud projects describe $PROJECT_ID --format =' value(projectNumber) ' ) # Compute Engine デフォルトサービスアカウントに Cloud Run 起動権限を付与 gcloud run services add-iam-policy-binding ai-ops-analyzer \ --region = $REGION \ --member =" serviceAccount: ${PROJECT_NUMBER} -compute@developer.gserviceaccount.com " \ --role =" roles/run.invoker " 動作確認 デプロイしたエージェントの動作確認として、以下の手順で疑似的なインシデント状況を作り出してテストします。意図的にメトリクスの負荷スパイクを発生させ、テスト用エラーログを書き込むことで、AI による原因分析が正しく実行されるかを確認します。 1.Cloud Shell から、デプロイした関数に対してリクエストを送り、メトリクス上にスパイクを発生させます。 # 自分の関数の URL を取得 URL = $( gcloud run services describe ai-ops-analyzer --region = $REGION --format =' value(status.url) ' ) TOKEN = $( gcloud auth print-identity-token ) # 1 分間、並列でリクエストを送り続ける(スパイクを作成) echo " 負荷を発生させています(約 1 分間)... " for i in { 1 .. 100 } ; do curl -s -H " Authorization: Bearer $TOKEN " $URL > /dev/null & done sleep 30 for i in { 1 .. 100 } ; do curl -s -H " Authorization: Bearer $TOKEN " $URL > /dev/null & done wait echo " 負荷生成完了。 " 2.負荷をかけてから2〜3分のタイミングで、テスト用のエラーログを書き込みます。 gcloud logging write my-test-log \ " CRITICAL: サービス応答遅延が発生しています。リクエストが処理しきれません。 " \ --severity = ERROR 3.Slack 上で、AI による分析結果が通知されることを確認します。 勝島 祐太郎 (記事一覧) クラウドソリューション部 ソリューションアーキテクト課 2025年1月G-genにジョイン!飲食業界からIT業界に転身したエンジニア。 コーヒーが好きです。
G-gen の福井です。当記事では、AI エージェントツールに専門知識やワークフローを追加するためのオープンフォーマットである Agent Skills について、概念や動作の仕組み、スキルの構造、使い方などを解説します。 概要 Agent Skills とは Skills が可能にすること Skills の実体 Agent Skills の仕組み 基本的な動作 コンテキスト肥大化の防止 Skills と MCP の関係 Skills の構造 ディレクトリ構成 SKILL.md の中身 使い方 対応ツール Skills ファイルの配置場所 インストール Gemini CLI からスキルを呼び出してみる 概要 Agent Skills とは Agent Skills は、生成 AI エージェントツールに専門知識やワークフローを追加するためのオープンフォーマットです。Anthropic が策定したオープンスタンダードであり、現在は Anthropic 社外のさまざまなツールでも採用が進んでいます。 Agent Skills は、Claude Code、Gemini CLI など、さまざまな AI エージェントツールで使用することができます。 なお当記事内では、文脈に応じて Agent Skills のことを「スキル」「Skill(s)」と表記する場合があります。 参考 : https://agentskills.io/ 参考 : Agent Skills - Claude API Docs 参考 : Agent Skills | Gemini CLI Skills が可能にすること Agent Skills が提供する典型的な能力としては、以下のようなものが挙げられます。 特定領域の専門知識(例: Google Cloud の各製品の正確な仕様や最新の API) 繰り返し実行されるワークフロー(例: コードレビューの観点、リリース手順) 組織やチーム固有のルール(例: 社内のコーディング規約、ドキュメントテンプレート) AI エージェントツールは、Agent Skills を必要なときにだけ読み込むので、LLM のコンテキストウインドウを不必要に圧迫することがありません。 システムインストラクション(システムプロンプト)や tools を必要なときにだけ読み込むことで、 コンテキストウインドウを効率的に使用できるようにする のが Agent Skills の最大のメリットといえます。 Skills の実体 Agent Skills の実体は、 SKILL.md というマークダウン形式のテキストファイルを含む 1 つのフォルダ(ディレクトリ)です。フォルダの中には SKILL.md に加えて、参照ドキュメントや実行スクリプトなどのアセットを任意で配置できます。 AI エージェントツールはこのフォルダをスキルとして認識し、必要に応じて読み込んで使用します。 Agent Skills と AI エージェントツールの関係 Agent Skills の仕組み 基本的な動作 Agent Skills は、 progressive disclosure (段階的開示)と呼ばれる仕組みで動作します。これは、必要なときに必要な情報だけを読み込むことで、AI エージェントツールのコンテキストを効率的に使うための仕組みです。 progressive disclosure では、AI エージェントツールはスキルを次の 3 段階に分けて読み込みます。 1 つ目の段階は Discovery (発見)です。AI エージェントツールの起動時に、使用可能なすべてのスキルの name(名前)と description(説明文)だけを読み込みます。この段階では、各スキルがどのような場面で使えるのかを把握するための最小限の情報のみが読み込まれます。 2 つ目の段階は Activation (有効化)です。ユーザーからのタスクが、あるスキルの description にマッチした場合、AI エージェントツールはそのスキルの SKILL.md 本文をすべて読み込みます。これにより、そのスキルに書かれた指示の詳細をタスク遂行に使用できます。 3 つ目の段階は Execution (実行)です。AI エージェントツールは SKILL.md の指示に従ってタスクを進めます。必要に応じて、スキルに同梱されたスクリプトを実行したり、参照ドキュメントを追加で読み込んだりします。 progressive disclosure の 3 段階 このように、すべての情報を一度に読み込むのではなく、必要な情報を必要なタイミングだけ読み込む仕組みであるため、多数のスキルを導入した場合でも、LLM のコンテキストウインドウを節約できます。 コンテキスト肥大化の防止 Agent Skills が解決しようとしている課題の 1 つに、AI エージェントツールに特有の コンテキスト肥大化 (Context Bloat)があります。 AI エージェントツールが特定領域で正確に動作するためには、LLM が正確な知識を参照する必要があります。必要な情報を AI に参照させるには、システムインストラクションやユーザープロンプトとして大量の情報を読み込ませたり、あるいは Model Context Protocol(MCP)サーバー経由でドキュメントを取得させるといった方法が挙げられます。例えば Google は、Google Cloud のドキュメントを提供する MCP サーバーを公開しています。 しかし、長大なプロンプトや MCP サーバーによる情報取得を多用すると、大量のドキュメントが常時、コンテキストウィンドウに読み込まれることになり、LLM の応答精度や応答速度が下がるほか、トークン消費量の増加にも繋がります。これがコンテキスト肥大化です。 一方、Agent Skills では、AI エージェントツールが、 必要なスキルだけを必要なタイミングで 読み込みます。これにより、コンテキストを節約しつつ、特定領域に関する正確な知識を LLM に与えることができます。 Skills と MCP の関係 前のセクションでも触れた MCP は、外部システムへのアクセスを標準化するためのプロトコルです。一方の Agent Skills は、専門知識やワークフローをパッケージ化して AI エージェントツールに配信するためのフォーマットです。両者は競合するものではなく、 役割が異なる補完的な関係 です。 MCP は、LLM が外部のシステムやデータソースにアクセスする手段を提供します。たとえば、Google ドライブのファイルを読み込む、データベースにクエリを発行する、Slack にメッセージを投稿する、といった操作を、LLM が API 経由で実行しやすくするプロキシのような役割を果たすのが MCP です。 一方の Agent Skills は、AI エージェントツールが特定の領域やタスクで、人間の意図どおりに振る舞うための知識と手順(プロンプト)や、tools(スクリプト等)をパッケージしたものです。Agent Skills の実体は 1 つのディレクトリにまとめられたファイル群であるため、1 度開発すれば容易に他人に共有できます。また、スキル内からは、同梱のスクリプトをツールとして使うこともできれば、MCP サーバーを呼び出すこともできます。 Agent Skills と MCP は 併用 できます。たとえば、組織の開発のワークフローに沿うために以下のような Agent Skills を作成できます。 ユーザーが指示した CSV ファイルを分析し、適切な BigQuery テーブルの設計を行う(パーティショニング、クラスタリング、カラムの説明などを作成) BigQuery 用の MCP サーバーを呼び出して、設計に基づいてテーブルを作成する CSV を新規のテーブルにロードする Skills の構造 ディレクトリ構成 Agent Skills は、 SKILL.md を必須ファイルとして含む 1 つのフォルダで構成されます。 SKILL.md 以外のファイルやフォルダは、用途に応じて任意で配置できます。 代表的なディレクトリ構成は以下のとおりです。 skill-name/ ├── SKILL.md (必須)スキルのメタデータと指示 ├── references/ (任意)詳細な参照ドキュメント ├── scripts/ (任意)スキルから呼び出される実行スクリプト └── assets/ (任意)テンプレートやリソース それぞれのファイルやフォルダの役割は、以下の通りです。 構成要素 必須/任意 役割 SKILL.md 必須 スキルのメタデータと、AI エージェントツールがタスクを遂行する際に従う指示を記述するファイル references/ 任意 SKILL.md の指示の中で参照される詳細なドキュメントを格納するフォルダ。AI エージェントツールは、SKILL.md の指示に従って必要なときだけ読み込む scripts/ 任意 スキルから呼び出される実行可能なスクリプトを格納するフォルダ。フォーマット変換スクリプトや API 呼び出しのヘルパースクリプトなどを配置する assets/ 任意 スキルが使用するテンプレートファイルやリソース(画像、設定ファイルなど)を格納するフォルダ シンプルなスキルであれば SKILL.md だけで構成することも可能ですし、複雑なスキルであれば references/ や scripts/ を組み合わせて表現できます。スキルの複雑さに応じて柔軟に構成できる、軽量なフォーマットといえます。 参考 : Specification - Agent Skills SKILL.md の中身 SKILL.md は、先頭にメタデータを記述する YAML フロントマター(ファイルの冒頭に YAML 形式で記述されるメタデータのこと)があり、それに続いて、AI エージェントツールがタスクを遂行する際に従う指示を Markdown 形式で記述する構造になっています。 YAML フロントマターには、name(スキル名)と description(スキルの説明)の 2 つを必ず記述します。description は、AI エージェントツールがどのスキルを使うべきかを判断する際の最も重要な情報です。「このスキルがどのような場面で使われるべきか」を具体的に書きます。 google/skills リポジトリで公開されている bigquery-basics スキルの SKILL.md から、構造が分かる範囲を抜粋して以下に示します。 参考 : google/skills - bigquery-basics/SKILL.md (Apache 2.0 ライセンス、抜粋) --- name: bigquery-basics description: >- Manages datasets, tables, and jobs in BigQuery, and integrates with BigQuery ML and Gemini for advanced data analytics and AI-driven insights. Use when you need to interact with BigQuery, run SQL queries, manage BigQuery resources, or leverage BigQuery's built-in ML capabilities. Also use when performing data analysis, ingesting data into BigQuery, or developing AI applications on BigQuery. --- # BigQuery Basics BigQuery is a serverless, AI-ready data platform that enables high-speed analysis of large datasets using SQL and Python. Its disaggregated architecture separates compute and storage, allowing them to scale independently while providing built-in machine learning, geospatial analysis, and business intelligence capabilities. ## Setup and Basic Usage (中略) ## Reference Directory - [ Core Concepts ]( references/core-concepts.md ): Storage types, analytics workflows, and BigQuery Studio features. - [ CLI Usage ]( references/cli-usage.md ): Essential ` bq ` command-line tool operations for managing data and jobs. - [ Client Libraries ]( references/client-library-usage.md ): Using Google Cloud client libraries for Python, Java, Node.js, and Go. (以下省略) このサンプルから、YAML フロントマター( name と description )、Markdown 本文( # BigQuery Basics 以降)、 references/ 配下のファイルへの参照( ## Reference Directory )という、これまで説明してきた構造が実際にどう書かれているかを確認できます。 description には、「いつこのスキルを使うか」を具体的に書くことが重要です。AI エージェントツールは、起動時に全スキルの description を読み込み、ユーザーのタスクと照合して「どのスキルを使うか」を判断します。description が曖昧だと、本来使われるべきスキルが選ばれない、または不適切な場面で使われてしまう、といった問題が発生します。 bigquery-basics スキルの description を見ると、「Use when you need to interact with BigQuery, run SQL queries...」のように、「いつ使うか」が具体的な動詞で複数列挙されているのが分かります。これにより、AI エージェントツールがユーザーのタスクと正確にマッチングできるようになっています。 使い方 対応ツール 規格に準拠した AI エージェントツールであれば、開発元を問わず Agent Skills を使用できます。主要なツールは以下のとおりです。 ツール名 提供元 種別 Antigravity Google IDE Gemini CLI Google CLI Claude Code Anthropic CLI Cursor Anysphere IDE GitHub Copilot GitHub IDE 拡張 Codex OpenAI CLI Anthropic、Google、OpenAI、GitHub などの主要 AI ベンダーが提供するツールが揃って Agent Skills の規格に対応しており、特定ベンダーに閉じない普遍的なフォーマットとして広く採用されていることがわかります。 なお、後述する npx skills install コマンドは、2026年5月現在で合計 55 個の AI エージェントツールへのインストールに対応しています。 Skills ファイルの配置場所 スキルは、決められたディレクトリに配置することで認識されます。AI エージェントツールは、起動時にこのディレクトリ配下を走査して、スキルを検出します。 Agent Skills の規格では、配置場所として Workspace スコープ と User スコープ の 2 種類が定義されています。 スコープ 説明 用途 Workspace スコープ プロジェクト(リポジトリ)単位でスキルを配置する形式。プロジェクトのカレントディレクトリ配下に配置され、プロジェクトと一緒に Git 管理できる プロジェクトメンバー間でスキルを共有する場合に使用する User スコープ ユーザー単位でスキルを配置する形式。ホームディレクトリ配下に配置され、すべてのプロジェクトから横断的に使用できる 個人で使うスキルや、プロジェクトを問わず使用するスキルに適している 主要なツールごとの、各スコープの配置場所は以下のとおりです。 ツール名 Workspace スコープ User スコープ Universal(Antigravity、Gemini CLI、Cursor 等に共通) .agents/skills/ ~/.agents/skills/ Gemini CLI .gemini/skills/ ~/.gemini/skills/ Claude Code .claude/skills/ ~/.claude/skills/ Augment .augment/skills/ ~/.augment/skills/ AiderDesk .aider-desk/skills/ ~/.aider-desk/skills/ 上記の表で「Universal」としているのは、複数のツールで使用される配置場所のことです。Antigravity、Gemini CLI、Cline、Codex、Cursor、GitHub Copilot などは、共通の .agents/skills/ ディレクトリ配下に配置されたスキルを認識します。 一方、Claude Code や Augment、AiderDesk など、独自のディレクトリを持つツールは、それぞれ専用のディレクトリにスキルを配置する必要があります。 なお、Gemini CLI については、上記の Universal エイリアス( .agents/skills/ )に加えて、ツール固有のパスである .gemini/skills/ も同時にサポートしています。両者は併用可能で、Gemini CLI は起動時に両方のディレクトリを走査します。同一スコープ(Workspace スコープまたは User スコープ)内で同名のスキルが両方のディレクトリに存在する場合は、 .agents/skills/ 配下のスキルが優先される仕様です。 参考 : Gemini CLI | Agent Skills Discovery tiers インストール 自前で作成したスキルを使用する場合は、前述に示したディレクトリに、 SKILL.md を含むスキルフォルダを直接配置します。AI エージェントツールは起動時に該当ディレクトリを走査してスキルを検出するため、特別なインストール作業は不要です。社内向けのスキルや、自身で作成したスキルを使う場合はこの方法が適しています。 一方、GitHub などで公開されているスキルは、 npx skills install コマンドでインストールできます。 npx skills は、Vercel 社(Vercel Labs)が提供するオープンソースの CLI ツールです。GitHub リポジトリ上の SKILL.md を取得し、AI エージェントツールの所定の配置場所に展開する役割を担います。 参考 : vercel-labs/skills - GitHub なお、 npx コマンドは Node.js に同梱されているコマンド実行ツールです。Node.js は、JavaScript ベースのコマンドラインツールやスクリプトを動かすためのランタイム環境で、Windows、macOS、Linux のすべてに対応しています。手元の環境で npx コマンドが使えない場合は、まず Node.js をインストールしてください。 参考 : Node.js 公式サイト - ダウンロード 以下のように GitHub リポジトリの URL を指定してコマンドを実行することで、スキルを導入できます。ここでは Google が公開している公式リポジトリ google/skills を例に挙げます。 npx skills install github.com/google/skills 処理を続行するか問われるため「y」を入力します。 Need to install the following packages: skills@ 1 . 5 . 5 Ok to proceed? ( y ) y インストールするスキルを選択します。リポジトリに含まれるスキルが一覧で表示されるため、必要なものだけを選択できます。 ┌ skills │ ◇ Source: https://github.com/google/skills.git │ ◇ Repository cloned │ ◇ Found 13 skills │ ◆ Select skills to install ( space to toggle ) │ ◻ alloydb-basics │ ◼ bigquery-basics ( Manages datasets, tables, and jobs in BigQuery, and integ... ) │ ◻ cloud-run-basics │ ◻ cloud-sql-basics │ ◻ firebase-basics │ ◼ gemini-api ( Guides the usage of the Gemini API on Agent Platform with... ) │ ◻ gke-basics │ ◼ google-cloud-recipe-auth ( Provides expert guidance on authenticating and authorizin... ) │ ◼ google-cloud-recipe-networking-observability ( Investigates Google Cloud networking issues by analyzing ... ) │ ◼ google-cloud-recipe-onboarding ( Guidance for a developer ' s first steps on Google Cloud, c...) │ ◼ google-cloud-waf-cost-optimization (Generates cost optimization guidance for Google Cloud wor...) │ ◼ google-cloud-waf-reliability (Generates reliability-focused guidance for Google Cloud w...) │ ◼ google-cloud-waf-security (Generates security-focused guidance for Google Cloud work...) インストール対象の AI エージェントツールを選択します。 Universal (.agents/skills) の下部に記載されているツールは、いずれも .agents/skills ディレクトリに配置されたスキルを認識します。一方、Claude Code など独自の配置場所を持つツールは、Additional agents の一覧から個別に選択する必要があります。 ◇ 55 agents ◆ Which agents do you want to install to? │ │ ── Universal ( .agents/skills ) ── always included ──────────── │ • Amp │ • Antigravity │ • Cline │ • Codex │ • Cursor │ • Deep Agents │ • Dexto │ • Firebender │ • Gemini CLI │ • GitHub Copilot │ • Kimi Code CLI │ • OpenCode │ • Warp │ │ ── Additional agents ───────────────────────────── │ Search: │ ↑↓ move, space select, enter confirm │ │ ○ AiderDesk ( .aider-desk/skills ) │ ○ Augment ( .augment/skills ) │ ○ IBM Bob ( .bob/skills ) │ ❯ ○ Claude Code ( .claude/skills ) │ ○ OpenClaw ( skills ) │ ○ CodeArts Agent ( .codeartsdoer/skills ) │ ○ CodeBuddy ( .codebuddy/skills ) │ ○ Codemaker ( .codemaker/skills ) │ ↓ 32 more │ │ Selected: Amp, Antigravity, Cline + 10 more 次に、インストールのスコープを選択します。 Project はカレントディレクトリ配下にスキルを配置する形式で、プロジェクトと一緒に Git 等で管理できます。Global はホームディレクトリ配下にスキルを配置する形式で、すべてのプロジェクトから横断的に使用できます。プロジェクトごとに使うスキルが異なる場合は Project、すべてのプロジェクトで共通して使う場合は Global を選びます。 ◆ Installation scope │ ● Project ( Install in current directory ( committed with your project )) │ ○ Global インストール確認に対する承認を行うため「Yes」を選択します。 インストール内容に加えて、各スキルに対する Gen、Socket、Snyk によるセキュリティリスク評価が表示されます。Agent Skills は AI エージェントツールが持つ権限で実行されるため、信頼できるソースのスキルだけをインストールすることが重要です。セキュリティリスク評価を確認することで、インストール前にリスクを把握できます。 セキュリティリスク評価に関する詳細は、 Security Risk Assessments の Details のリンク先から確認できます。 ◇ Installation Summary ──────────────────────────────────────────────────────────────────╮ │ │ │ ~/blog_work/google-skills/.agents/skills/bigquery-basics │ │ copy → Amp, Antigravity, Cline, Codex, Cursor + 8 more │ │ │ │ (中略) │ │ │ ├─────────────────────────────────────────────────────────────────────────────────────────╯ │ ◇ Security Risk Assessments ──────────────────────────────────────────────────────────╮ │ │ │ Gen Socket Snyk │ │ bigquery-basics Safe 0 alerts Low Risk │ │ gemini-api Safe 0 alerts Med Risk │ │ (中略) │ │ │ │ Details: https://skills.sh/google/skills │ │ │ ├──────────────────────────────────────────────────────────────────────────────────────╯ │ ◆ Proceed with installation? │ ● Yes / ○ No インストールが完了します。 └ Done! Review skills before use; they run with full agent permissions. Vercel 社が公開している「find-skills」のインストール確認があります。今回は不要ですので「No」を選択します。 ◆ Install the find-skills skill? It helps your agent discover and suggest skills. │ ○ Yes / ● No Gemini CLI からスキルを呼び出してみる これまで解説してきた Agent Skills の仕組みが実際にどう機能するかを、 Gemini CLI を例にとって実演します。 Gemini CLI の概要やインストール方法については、以下の記事で詳しく解説しています。 blog.g-gen.co.jp 今回は、題材として google/skills リポジトリで公開されている bigquery-basics スキルを使用します。ここからは、すでにこのスキルが導入済みである前提で紹介します。 参考 : google/skills - bigquery-basics/SKILL.md (Apache 2.0 ライセンス、抜粋) bigquery-basics スキルが導入された Gemini CLI に対して「BigQuery のデータセットを作りたい」と入力した結果が以下です。 > BigQuery のデータセットを作りたい BigQuery Dataset Creation Research: Activating the BigQuery skill to assist with dataset creation. ╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯ ╭────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮ │ Action Required │ │ │ │ ? Activate Skill "bigquery-basics": Manages datasets, tables, and jobs in BigQuery, and integrates with BigQuery ML and Gemini for advanced data analytics and AI-driven insights. Use when … │ │ │ │ You are about to enable the specialized agent skill bigquery-basics. │ │ │ │ Description: │ │ Manages datasets, tables, and jobs in BigQuery, and integrates with BigQuery ML and Gemini for advanced data analytics and AI-driven insights. Use when you need to interact with BigQuery, │ │ run SQL queries, manage BigQuery resources, or leverage BigQuery's built-in ML capabilities. Also use when performing data analysis, ingesting data into BigQuery, or developing AI │ │ applications on BigQuery. │ │ │ │ Resources to be shared with the model: │ │ Showing up to 200 items (files + folders). │ │ │ │ /home/xxx/blog_work/google-skills/.agents/skills/bigquery-basics/ │ │ ├───SKILL.md │ │ └───references/ │ │ ├───cli-usage.md │ │ ├───client-library-usage.md │ │ ├───core-concepts.md │ │ ├───iac-usage.md │ │ ├───iam-security.md │ │ └───mcp-usage.md │ │ Do you want to proceed? │ │ │ │ ● 1. Allow once │ │ 2. Allow for this session │ │ 3. No, suggest changes (esc) │ ╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯ ここで起こっているのは、progressive disclosure の Activation(有効化)の段階です。Gemini CLI は起動時に全スキルの description を読み込んでおり(Discovery)、ユーザーのプロンプト「BigQuery のデータセットを作りたい」が bigquery-basics スキルの description にマッチしたため、 SKILL.md 本文を読み込もうとしています。 ユーザーが有効化を承認すると、Gemini CLI は bigquery-basics スキルの SKILL.md を読み込み、その指示に従ってタスクを進めます。ここから progressive disclosure の Execution(実行)の段階です。 SKILL.md の指示に基づいて、データセット作成に必要な情報を Gemini CLI が対話形式で確認してきます。最初に、データセット名を尋ねられます。今回は my_dataset と入力します。 ╭────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮ │ Answer Questions │ │ │ │ ← ✓ Dataset Info │ □ Location │ ≡ Review → │ │ │ │ データセット名は何にしますか? │ │ │ │ > my_dataset │ │ │ │ │ │ Enter to submit · Tab/Shift+Tab to switch questions · Esc to cancel │ ╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯ 続いて、データセットを作成するロケーション(リージョン)を尋ねられます。US や EU といったマルチリージョンに加えて、asia-northeast1(東京リージョン)などの選択肢が提示されます。今回は asia-northeast1 を選択します。 ╭────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮ │ Answer Questions │ │ │ │ ← ✓ Dataset Info │ □ Location │ ≡ Review → │ │ │ │ ロケーション(リージョン)はどこにしますか? │ │ │ │ ▲ │ │ 1 . US │ │ US multi-region │ │ 2 . EU │ │ EU multi-region │ │ ● 3 . asia-northeast1 │ │ Tokyo region │ │ ▼ │ │ │ │ Enter to select · ←/→ to switch questions · Esc to cancel │ ╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯ 入力した情報の確認画面が表示されます。データセット名 my_dataset 、ロケーション asia-northeast1 で問題ないため、そのまま確定します。 ╭────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮ │ Answer Questions │ │ │ │ ← ✓ Dataset Info │ ✓ Location │ ≡ Review → │ │ │ │ Review your answers: │ │ │ │ Dataset Info → my_dataset │ │ Location → asia-northeast1 │ │ │ │ Enter to submit · Tab/Shift+Tab to edit answers · Esc to cancel │ ╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯ 入力した情報を元に、Gemini CLI が実行すべき gcloud コマンドと bq コマンドが提示されました。ここでは、BigQuery API の有効化( gcloud services enable bigquery.googleapis.com )とデータセット作成( bq mk --dataset --location=asia-northeast1 my_dataset )を 1 行で実行する形になっています。コマンドの実行を承認します。 ╭────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮ │ ? Shell gcloud services enable bigquery.googleapis.com && bq mk --dataset --location = asia-northeast1 my_dataset │ │ ╭────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮ │ │ │ gcloud services enable bigquery.googleapis.com && bq mk --dataset --location = asia-northeast1 my_dataset │ │ │ ╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯ │ │ Allow execution of [ gcloud ] ? │ │ │ │ ● 1 . Allow once │ │ 2 . Allow for this session │ │ 3 . No, suggest changes ( esc ) │ ╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯ コマンドが実行され、BigQuery のデータセットが作成されました。Gemini CLI から、データセットの作成完了と次のステップの提案が返ってきます。 ✦ BigQuery のデータセット my_dataset を asia-northeast1(東京)リージョンに作成しました。 次のステップとして、テーブルの作成やデータのインポートなど、お手伝いできることはありますか? このように、Agent Skills の仕様に準拠したスキルは、AI エージェントツールが認識できる場所に配置されていれば、ユーザーがスキルを意識して呼び出すことなく、ユーザーのプロンプトに応じて自動的に起動します。「Discovery」「Activation」「Execution」の 3 段階を経て動作する progressive disclosure の仕組みが、Gemini CLI で実際に動作していることが確認できました。 福井 達也 (記事一覧) カスタマーサクセス課 エンジニア 2024年2月 G-gen JOIN 元はアプリケーションエンジニア(インフラはAWS)として、PM/PL・上流工程を担当。G-genのGoogle Cloudへの熱量、Google Cloudの魅力を味わいながら日々精進
G-gen の佐々木です。当記事では、単一の API 呼び出しでマネージドな自律エージェントを構築・実行できるサービスである Managed Agents API on Agent Platform について解説します。 概要 Agent Platform とは Managed Agents API on Agent Platform とは プレビュー段階での注意点 他のエージェント構築手段との比較 Managed Agents API の基本 2つの API ツールの利用 料金 サンドボックス環境について プリインストール済ソフトウェアと組み込みツール ファイルシステムと永続化 スキルのマウント セキュリティ 利用手順 事前準備 API の有効化 IAM ロールの付与 認証 エージェントの作成 エージェントの呼び出し エージェントの削除 概要 Agent Platform とは Gemini Enterprise Agent Platform (旧称 Vertex AI、以下 Agent Platform と記載)は、Google Cloud が提供する生成 AI とエージェントの開発・運用プラットフォームです。基盤モデルの API 提供、エージェントの開発フレームワーク、デプロイ基盤、評価・モニタリング・ガバナンスなどの運用機能を統合的に提供します。 Agent Platform の全体像や提供機能の詳細は、以下の記事で解説しています。 blog.g-gen.co.jp Managed Agents API on Agent Platform とは Managed Agents API on Agent Platform (以下 Managed Agents API と記載)は Agent Platform の機能の1つで、単一の API 呼び出しで自律的なエージェントを構築・実行できるマネージドサービスです。2026年5月現在はプレビュー提供です。 エージェントは Antigravity ハーネス を搭載しており、隔離された Linux サンドボックス内で以下の操作を行います。 推論と計画 Python コードの実行 bash コマンドの実行 ファイルの読み書き Web 検索によるグラウンディング MCP サーバー経由での外部システム連携 Antigravity ハーネスは、Google I/O 2026 で発表された Antigravity プラットフォームの中核をなすエージェント実行基盤で、Gemini 3.5 Flash と協調するよう最適化されています。Google 自社のエージェント製品も同じハーネスを搭載しており、Managed Agents API はこれを Google Cloud から API 経由で利用できるようにしたサービスです。 Managed Agents API は REST API および Python SDK(Google Gen AI SDK)から利用できます。2026年5月現在の対応リージョンは global のみです。 参考 : Agent Platform の Managed Agents API の概要 参考 : I/O 2026: Antigravity 2.0 と新しい Gemini のエージェントツール プレビュー段階での注意点 2026年5月現在はプレビュー提供のため、本番採用にあたっては以下の制約に留意が必要です。 プレビュー期間中のサービス利用規約が適用される 機密データの投入は推奨されない API 仕様は変更される可能性がある 2026年5月現在の以下の公式ドキュメントの冒頭部分には「これらの pre-GA プロダクトは、内部テストとレビューのさまざまな段階にあります。そのため、これらのプロダクトで機密データやその他の機密データを使用しないでください 。これらのプロダクトは、限定的なテストと評価のみを目的としてお客様にご提供するものであり、商用目的や本番環境での使用はできません。」と明記されていることから、この点には十分留意する必要があると考えられます。 参考 : Agent Platform の Managed Agents API の概要 なおプレビュー提供されている Google Cloud サービスの考え方については、以下の記事も参照してください。 参考 : Preview版のサービスを使うとはどういうことなのか 他のエージェント構築手段との比較 Google Cloud 上でエージェントを構築する手段は Managed Agents API のほかにも存在します。Managed Agents API は、ノーコードでの構築とフルコード開発の中間に位置するサービスです。 エージェント構築手段 抽象度 カスタマイズ性 主な利用者 Gemini Enterprise のノーコードエージェント構築 高 低(プリセットの設定) 業務ユーザー Managed Agents API 中 中(API でハーネスの動作を設定) アプリケーション開発者 Agent Development Kit(ADK) 低 高(コードで自由に記述) エージェント開発者 Managed Agents API の基本 2つの API Managed Agents API は以下の2つの API で構成されます。 API 役割 Agents API (コントロールプレーン) エージェント設定(以下、例)の作成・取得・更新 ・システム指示 ・ツール ・ネットワーク許可 ・マウントするファイル Interactions API (データプレーン) デプロイ済みエージェントへのリクエスト(以下、例) ・マルチターン会話 ・ストリーミング応答 まず Agents API を使用してエージェントを定義し、以降は Interactions API の呼び出しを通じて会話を行うのが基本的な流れです。 ツールの利用 Managed Agents API では、エージェントが利用できるツールを定義できます。たとえば以下のようなツールをアタッチできます。 ツール 機能 code_execution Python コードの実行 filesystem サンドボックス内のファイル操作 google_search Web 検索によるグラウンディング url_context 指定 URL からのコンテンツ抽出 mcp_server MCP サーバーへの接続 ツールは Agents API でエージェント設定に永続的に紐づける方法と、Interactions API のリクエスト単位でオーバーライドする方法のどちらでも指定できます。リクエスト単位で tools を渡した場合、そのターンではエージェント設定側のツール定義は無視され、リクエスト側のツール指定のみが有効になります。 料金 Managed Agents API では、エージェントが使用するモデル使用料が Agent Platform の標準レートで課金されます。 Managed Agents API 自体の料金については、2026年5月現在、公式ドキュメントに記載されていません。 参考 : Gemini Enterprise Agent Platform 料金 サンドボックス環境について プリインストール済ソフトウェアと組み込みツール サンドボックスには以下のソフトウェアがプリインストールされています。 種別 ソフトウェア UNIX コマンド bc 、 curl 、 fd-find 、 gawk 、 gcloud 、 git 、 htop 、 iproute2 、 jq 、 lsof 、 procps 、 ripgrep 、 rsync 、 tree 、 unzip 、 wget 、 which Python 3.11 ast-grep-cli 、 beautifulsoup4 、 google-genai 、 numpy 、 pandas 、 pyyaml 、 requests Node.js 20 create-next-app 、 create-vite 、 typescript 外部ネットワーク接続が許可されているサンドボックスでは、 pip install や npm install で上記以外のパッケージを追加することもできます。 加えて、以下のツールは設定不要で常時利用できる「組み込みツール」です。前述「ツールの利用」のアタッチ式ツールとは別カテゴリで、 tools への指定なしに呼び出せます。 ツール 機能 bash サンドボックスでのシェルコマンド実行 file_system ファイルの読み書き・削除、ディレクトリの一覧表示 最新情報については以下の公式ドキュメントを確認してください。 参考 : Managed Agents API on Agent Platform sandbox environment - プリインストールされているソフトウェア ファイルシステムと永続化 サンドボックスのファイルシステムは会話をまたいで永続化されます。TTL は7日で、新しいインタラクションが発生するたびに TTL がリセットされます。エージェント設定自体は API で明示的に削除するまで永続的に保持されます。複数のエージェントで同じサンドボックスを共有するには、リクエスト時に同じ environment_id を渡します。 外部ネットワーク接続が許可されているサンドボックスでは、 pip install や npm install でインストールしたパッケージも環境スナップショットに保持され、同じ environment_id を再利用するインタラクションで引き続き利用可能です。 スキルのマウント エージェントが実行されるサンドボックス内のパスに対して、Cloud Storage バケットや Skill Registry に登録してある再利用可能なスキルをマウントできます。 リソース 説明 gcs Cloud Storage バケットに配置したスキルフォルダからカスタムスキルを追加する skill_registry Skill Registry に登録済みのスキルを追加する 参考 : エージェントの作成と管理 - エージェントにスキルを割り当てる 参考 : Managed Agents API on Agent Platform sandbox environment - スキル マウント アーキテクチャ セキュリティ サンドボックスでは、実行プロセス・マウント・外部接続のそれぞれにセキュリティ制限が組み込まれています。 対象 セキュリティ制限 サンドボックスプロセス 管理者権限を持たない一般ユーザーとして起動される 外部ネットワーク接続 デフォルトで無効。許可リストで指定したドメインへのアクセスのみ許可 Cloud Storage や Skill Registry のマウント 指定したディレクトリまたはスキルのみアクセスできるダウンスコープトークンで行われる MCP サーバーの認証ヘッダー 定義した MCP エンドポイントへのアクセス時にだけ送信される 外部ネットワーク接続の許可ドメインは、エージェントの定義で以下のように列挙します。 " network ": { " allowlist ": [ { " domain ": " example.com " } , { " domain ": " * " } ] } "*" を指定すると全ドメインへのアクセスが許可されますが、セキュリティ上、許可範囲はできるだけ狭く絞ることが推奨されます。 参考 : Managed Agents API on Agent Platform sandbox environment - サンドボックスの権限とセキュリティ 利用手順 事前準備 API の有効化 Agent Platform の API を有効化します。プロジェクト ID は適宜置き換えてください。 # API を有効化 $ gcloud services enable aiplatform.googleapis.com --project =< プロジェクトID > IAM ロールの付与 API を呼び出すユーザーまたはサービスアカウントに、以下のいずれかの IAM ロールを付与します。 Vertex AI ユーザー( roles/aiplatform.user ) Vertex AI 管理者( roles/aiplatform.admin ) 認証 REST API の呼び出しには、Bearer トークンとして gcloud で取得したアクセストークンを使用します。事前に gcloud auth login でログインを済ませておきます。 # gcloud で認証 $ gcloud auth login アクセストークンは gcloud auth print-access-token で取得できます。以降の例では $(gcloud auth print-access-token) の形でリクエスト時にその場で取得します。 エージェントの作成 「数値計算を Python コードで解いて答えるエージェント」を作成します。Agents API のエンドポイント POST /agents にリクエストを送信します。プロジェクト ID は適宜置き換えてください。 # エージェントの作成 $ curl -X POST \ " https://aiplatform.googleapis.com/v1beta1/projects/<プロジェクトID>/locations/global/agents " \ -H " Authorization: Bearer $( gcloud auth print-access-token ) " \ -H " Content-Type: application/json " \ -d ' { "id": "hello-agent", "base_agent": "antigravity-preview-05-2026", "description": "数値計算を Python コードで解いて答えるサンプルエージェント", "system_instruction": "あなたは数値計算のアシスタントです。ユーザーから与えられた計算は必ず Python コードを実行して解き、コードと結果の両方を日本語で示してください。", "tools": [ {"type": "code_execution"}, {"type": "filesystem"} ] } ' 参考 : エージェントの作成と管理 - エージェントを作成する エージェントの呼び出し 作成したエージェントを Interactions API で呼び出します。 POST /interactions にリクエストを送信します。Interactions API には Api-Revision ヘッダーが必須です。 # エージェントの呼び出し $ curl -X POST \ " https://aiplatform.googleapis.com/v1beta1/projects/<プロジェクトID>/locations/global/interactions " \ -H " Authorization: Bearer $( gcloud auth print-access-token ) " \ -H " Content-Type: application/json " \ -H " Api-Revision: 2026-05-20 " \ -d ' { "stream": true, "background": true, "store": true, "agent": "hello-agent", "environment": {"type": "remote"}, "input": [ { "type": "user_input", "content": [ {"type": "text", "text": "1から100までの整数のうち、3の倍数の合計はいくつですか。"} ] } ] } ' 新しいサンドボックスが払い出され、エージェントが Python コードを生成・実行し、結果を返します。 "stream": true を指定しているため、レスポンスは Server-Sent Events(SSE)形式で逐次到着します。 event: interaction.created data: { " interaction " : { " id " : " ChBhNTAxNGNmOWJmN2Q1M2Y5EAgaAzAwMSoEbWFpbg " , " status " : " in_progress " , " object " : " interaction " } , " event_type " : " interaction.created " } event: interaction.status_update data: { " interaction_id " : " ChBhNTAxNGNmOWJmN2Q1M2Y5EAgaAzAwMSoEbWFpbg " , " status " : " in_progress " , " event_type " : " interaction.status_update " } event: step. start data: { " index " :0, " step " : { " id " : " bbe14e24-ac0b-4898-87b2-ab44efb71763 " , " type " : " function_call " , " name " : " run_command " , " arguments " : {}} , " event_type " : " step.start " } event: step.delta data: { " index " :0, " delta " : { " arguments " : " { \" CommandLine \" : \" python3 -c \\\" print(sum(i for i in range(1, 101) if i % 3 == 0)) \\\"\" , \" Cwd \" : \" /workspace \" , \" explanation \" : \" Calculate the sum of multiples of 3 between 1 and 100 using python3. \" , \" WaitMsBeforeAsync \" :5000, \" toolSummary \" : \" Run Python command \" , \" toolAction \" : \" Running Python script \" } " , " type " : " arguments_delta " } , " event_type " : " step.delta " } event: step. stop data: { " index " :0, " event_type " : " step.stop " } event: step. start data: { " index " :1, " step " : { " call_id " : " bbe14e24-ac0b-4898-87b2-ab44efb71763 " , " signature " : "" , " type " : " function_result " , " name " : " run_command " } , " event_type " : " step.start " } event: step.delta data: { " index " :1, " delta " : { " name " : " run_command " , " is_error " :false, " type " : " function_result " , " result " : { " ExitCode " :0, " Output " : " [STDOUT] \n 1683 \n\n\n [STDERR] \n " }} , " event_type " : " step.delta " } event: step. stop data: { " index " :1, " event_type " : " step.stop " } event: step. start data: { " index " :2, " step " : { " type " : " model_output " } , " event_type " : " step.start " } event: step.delta data: { " index " :2, " delta " : { " text " : " 1から100までの整数のうち、3の倍数の合計を求めるためのPythonコードと計算 " , " type " : " text " } , " event_type " : " step.delta " } event: step.delta data: { " index " :2, " delta " : { " text " : " 結果は以下の通りです。 \n\n ### Pythonコード \n\n```python\n # 1から100までの整数のうち、","type":"text"},"event_type":"step.delta"} event: step.delta data: { " index " :2, " delta " :{ " text " : " 3の倍数の合計を計算します \n total_sum = sum(i for i in range(1, 10 " , " type " : " text " }, " event_type " : " step.delta " } event: step.delta data: { " index " :2, " delta " :{ " text " : " 1) if i % 3 == 0) \n print(total_sum) \n```\n\n ### 計算結果\n\n**","type":"text"},"event_type":"step.delta"} event: step.delta data: { " index " :2, " delta " :{ " text " : " 1683** \n\n --- \n **作業サマリー**: \n - 1から100までの範囲 " , " type " : " text " }, " event_type " : " step.delta " } event: step.delta data: { " index " :2, " delta " :{ " text " : " で3の倍数を抽出し、その合計を計算するPythonコードを実行しました。 \n - 計算の結果、合計 " , " type " : " text " }, " event_type " : " step.delta " } event: step.delta data: { " index " :2, " delta " :{ " text " : " は **1683** になることを確認しました。 " , " type " : " text " }, " event_type " : " step.delta " } event: step. stop data: { " index " :2, " event_type " : " step.stop " } event: interaction.completed data: { " interaction " :{ " id " : " ChBhNTAxNGNmOWJmN2Q1M2Y5EAgaAzAwMSoEbWFpbg " , " status " : " completed " , " usage " :{ " total_tokens " :15326, " total_input_tokens " :13786, " input_tokens_by_modality " : [ { " modality " : " text " , " tokens " :13786 } ] , " total_output_tokens " :309, " output_tokens_by_modality " : [ { " modality " : " text " , " tokens " :309 } ] , " total_thought_tokens " :1231}, " created " : " 2026-05-24T13:56:20Z " , " updated " : " 2026-05-24T13:56:20Z " , " environment_id " : " env_CAEQgICAgIDQ_PE1GiA1M2FhMTMzM2NlYjc0NDRmYjAwMTFmNzFkYzY1NDNlNA " , " object " : " interaction " }, " event_type " : " interaction.completed " } event: done data: [ DONE ] 各ステップは step.start / step.delta / step.stop のイベントで区切られ、 function_call (コマンド実行)、 function_result (実行結果)、 model_output (モデル応答)が順次ストリーミングされます。 最終イベント interaction.completed には interaction.id 、 environment_id 、消費トークン数( usage )が含まれます。次回リクエストで previous_interaction_id に interaction.id を、 environment に environment_id を渡すと、マルチターン会話とサンドボックスを引き継げます。 なお、エージェント作成直後は Interactions API のリクエスト時に以下のレスポンスが返ることがあります。作成リクエストから Interactions API でエージェントが解決可能になるまでに時間差があるため、このエラーが返った場合は数十秒ほど待ってから再送してください。 { " error ": { " message ":" Result not found. "," code ":" not_found " }} 参考 : エージェントを操作する エージェントの削除 最後にエージェント設定を削除します。 DELETE /agents/{AGENT_ID} により、サンドボックスとエージェント設定がまとめて破棄されます。 # エージェントの削除 $ curl -X DELETE \ " https://aiplatform.googleapis.com/v1beta1/projects/<プロジェクトID>/locations/global/agents/hello-agent " \ -H " Authorization: Bearer $( gcloud auth print-access-token ) " 参考 : エージェントの作成と管理 - エージェントを削除する 佐々木 駿太 (記事一覧) G-gen 最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出(2024 / 2025 Fellow / 2026)。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説(SF、ミステリ)、カラオケなど。 Follow @sasashun0805
G-gen の西田です。当記事では、Google Workspace の共有ドライブのデータに対する操作に対して必要なアクセス権について解説します。 共有ドライブのアクセス権の仕組み 共有ドライブの最上位レベルでのアクセス権付与 個別ファイルでのアクセス権付与 外部への共有 データの移動 共有ドライブのアクセス権の仕組み 共有ドライブ は Google ドライブの機能であり、チームでファイルを保存、検索、アクセスすることができます。 アクセス権は「 共有ドライブの最上位レベル 」、「 フォルダごと 」、「 ファイルごと 」にそれぞれ付与することができ、付与されたアクセス権によって実行できる操作が異なります。 「共有ドライブの最上位レベル」に権限を付与した場合、その権限は配下のすべてのフォルダやファイルに 継承 されます。そのうえで「フォルダごと」または「ファイルごと」に個別に追加の権限を付与することもできます。 アクセス権は個々のユーザー(Google アカウント)またはグループに割り当てることができます。異動や退職に少ない運用工数で対応できるよう、権限は グループに付与することが望ましい とされます。 共有ドライブの概要および制限事項などについては、以下のドキュメントを参照してください。 参考 : 共有ドライブとは 参考 : Google ドライブにおける共有ドライブの制限 共有ドライブの最上位レベルでのアクセス権付与 共有ドライブ自体(共有ドライブの最上位レベル)において、 メンバー (Google アカウントやグループ)に対する アクセス権 を付与することで、メンバーは共有ドライブ内のファイルやフォルダを操作することができるようになります。アクセス権には以下があります。 管理者 コンテンツ管理者 投稿者 閲覧者(コメント可) 閲覧者 なお、共有ドライブの最上位レベルでアクセス権の追加や削除ができるのは、共有ドライブに 管理者 権限を持つメンバーのみです。 ファイルやフォルダに対する基本的な操作とそれに必要なアクセス権は、以下の表の通りです。 操作\アクセス権 管理者 コンテンツ管理者 投稿者 閲覧者 (コメント可) 閲覧者 閲覧 ◯ ◯ ◯ ◯ ◯ 作成 ◯ ◯ ◯ (※) 編集 ◯ ◯ ◯ (※) 削除 ◯ ◯ 復元 ◯ ◯ ◯ 共有ドライブ内にファイルやフォルダを作成したり、編集したりするには 投稿者以上 の権限が必要です。また、削除には コンテンツ管理者以上 の権限が必要です。 仕様上の制約として、パソコン版 Google ドライブでは、投稿者によるファイルの追加や編集はできません。 パソコン版 Google ドライブ または Chrome OS ファイル アプリ内のファイルに対しては、[投稿者] のアクセス権はファイルに対する読み取りのみのアクセスになります。パソコン版 Google ドライブ や Chrome OS の共有ドライブ内でユーザーがファイルを作成、アップロード、編集できるようにするには、ユーザーに [コンテンツ管理者] または [管理者] 権限を付与します。 参考 : 共有ドライブのファイルへのアクセスの仕組み 参考 : パソコン版 Google ドライブを使用する 個別ファイルでのアクセス権付与 共有ドライブの最上位レベルにおいて適切なアクセス権を持っていれば、共有ドライブ配下の個々のファイルやフォルダに対して、 共有ドライブのメンバーでない人にもアクセス権を付与 できます。 なお、ファイルやフォルダに個別のアクセス権を付与することを指して、ドキュメント上や UI 上では「 共有する 」等と表現されることがあります。 ユーザーが共有ドライブの最上位レベルでどのアクセス権を持っているかによって、共有可能な対象が異なります。 権限付与対象\アクセス権 管理者 コンテンツ管理者 投稿者 閲覧者 (コメント可) 閲覧者 フォルダ (※1) ◯ ◯ (※2) ファイル (※1) ◯ ◯ ◯ ※1 : ユーザーによるアクセス付与は、共有ドライブの設定で「共有ドライブのメンバー以外のユーザーにファイルへのアクセスを許可する」が有効な場合に限ります。 ※2 : コンテンツ管理者がフォルダに対してアクセスを付与する操作も、共有ドライブの設定で「コンテンツ管理者にフォルダの共有が許可する」が有効な場合に限ります。 参考 : 共有ドライブのファイルへのアクセスの仕組み 外部への共有 ファイルやフォルダは、異なるドメイン(別の組織)の Google Workspace ユーザーやグループに対しても共有できます。しかし共有する情報によっては、それがセキュリティ面で望ましくない場合もあります。 ドメイン外のユーザーへアクセス権が付与されることを制御する方法については、以下の記事を参照してください。 blog.g-gen.co.jp また、ファイルやフォルダはインターネットに公開することもできます。これは共有リンクを知っていれば誰でもアクセスできる状態であることを意味し、多くの場合でセキュリティ上、望ましくありません。 ファイルやフォルダのインターネット公開を防ぐ方法については、以下の記事を参照してください。 blog.g-gen.co.jp データの移動 共有ドライブの ファイルやフォルダ移動の操作 に必要な権限は、以下の図と表の通りです。移動できる対象(ファイルかフォルダ)や対象の移動先、移動元はユーザーが持つアクセス権によって異なります。 操作 対象 管理者 コンテンツ管理者 投稿者 ①異なる共有ドライブ間の移動 フォルダ, ファイル ◯ ②共有ドライブ→マイドライブに移動 フォルダ, ファイル ◯ ③マイドライブ→共有ドライブに移動 フォルダ ◯ ファイル ◯ ◯ ◯ ④単一の共有ドライブ内での移動 フォルダ, ファイル ◯ ◯ 移動操作における詳細は、以下の記事で解説しています。 blog.g-gen.co.jp 西田 匡志 (記事一覧) クラウドソリューション部 美容商社→物流→情シスを経て、2025年6月G-genにジョイン。Google Cloud を通じて多くの人に貢献できるよう日々精進!
G-genの菊池です。Looker におけるデータモデリングにおいて、複雑な分析や集計を効率化する 派生テーブル (Derived Tables)について、その機能分類と選定の基準を解説します。 Looker の派生テーブルとは 定義方法による分類 概要 ネイティブ派生テーブル SQL ベースの派生テーブル データの保持方法による分類 概要 一時的な派生テーブル 永続的な派生テーブル(PDT) 永続性戦略 概要 トリガーベースの戦略 保存期間ベースの戦略 データベースが管理する戦略(マテリアライズドビュー) 増分 PDT 概要 利用するための必須条件 Looker 派生テーブルの選定基準 概要 定義方法の選定基準 データの保持方法の選定基準 PDT の永続性戦略や増分 PDT の選定基準 Looker の派生テーブルとは Looker の 派生テーブル とは、LookML 内で定義したクエリ結果を、データベース内の実際のテーブルのように使用できるようにする機能です。 派生テーブルを使用することで、複数の種類のデータを事前結合したり大量のデータを集計したりした結果を、あたかも1つのテーブルであるかのように扱うことができます。 例えば、顧客が行った注文の数や初回注文日時など、顧客ごとの集計値を事前に計算した派生テーブルを作成することで、データベース内の他のテーブルと同じようにデータ探索ができます。 参考 : Lookerの派生テーブル 定義方法による分類 概要 派生テーブルは定義に方法に応じて「ネイティブ派生テーブル」「SQL ベースの派生テーブル」に分類することができます。 参考 : Lookerの派生テーブル - ネイティブ派生テーブルとSQLベースの派生テーブル ネイティブ派生テーブル ネイティブ派生テーブル は、LookML を使用して定義される派生テーブルです。既存の Explore (エクスプローラ)の定義を再利用して作成します。 ネイティブ派生テーブルの大きなメリットとして、まずデータモデルの可読性と保守性が向上します。ネイティブ派生テーブルは、LookML 内ですでに定義されているディメンションやメジャーを参照して定義されます。そのため、SQL を直接記述するアプローチと比較して、データをモデル化するときの読みやすさと理解しやすさが向上します。 また、コードを記述する手間を大幅に削減できるという利点があります。Looker の Explore 機能の画面上で派生テーブルとして表示したいデータの形を整えた後、そこからネイティブ派生テーブル用の LookML を自動生成してコピーできるため、一から手動でコードを記述する手間を省くことができます。 Explore 機能で表示データ作成 ネイティブ派生テーブルの LookML を取得 さらに、フィルタ機能の簡単な適用とシームレスな連携が可能です。豊富なフィルタ機能をLookMLの構文で直接適用できることに加え、 bind_filters や bind_all_filters といった機能を使用することで、元の Explore でユーザーが設定した日付などのフィルタ条件を、派生テーブル側のクエリにも簡単に連携させることができます。 ネイティブ派生テーブルの注意点として、ネイティブ派生テーブルは LookML の構文に依存しているため、複数ステップの処理を必要とする SQL 構文やカスタム DDL(データ定義言語)が必要なケースには対応できません。 さらに、既存の LookML モデルへの依存度が高い点も挙げられます。ネイティブ派生テーブルは既存の Explore(エクスプローラ)の定義をベースに構築されるため、参照したいテーブルや結合関係が LookML 上にまだ定義されていない場合は、まずその基礎となるデータモデリングから始める必要があります。 SQL ベースの派生テーブル SQL ベースの派生テーブル は、標準的な SQL クエリを直接記述して定義する派生テーブルです。 SQL ベースの派生テーブルの大きなメリットとして、まず既存の SQL 資産を手軽に流用できる点が挙げられます。Looker の「SQL Runner」機能で作成・テストした SQL クエリを、そのまま派生テーブルの定義へと簡単に変換できるショートカット機能が用意されています。これにより、すでに動作確認済みの SQL や、データアナリストが書き慣れた SQL クエリを素早く Looker のデータモデルに組み込むことができます。 SQL Runner 機能で SQL クエリ作成 SQL ベース派生テーブルの LookML を取得 また、ネイティブ派生テーブル(LookML)では表現が難しい、高度で複雑な処理を実現できる点も重要な強みです。単一の SQL ステートメントでテーブルを作成できず複数ステップの処理が必要な環境や、BigQuery ML のようなデータベース固有のカスタム DDL コマンドを実行したいといった、極めて高い柔軟性が求められるケースに対応できます。 ただし、保守性や運用面においては注意が必要です。SQL ベースの派生テーブルは、基盤となるデータベースのスキーマで列の追加や削除などがされた際、エラーを防ぐために手動で SQL の記述を修正しなければなりません。そのため、基本的には可読性やメンテナンス性が高いネイティブ派生テーブルの利用を第一に検討し、どうしても SQL の直接記述や特殊な機能が必要な場面に限って SQL ベースの派生テーブルを採用することが推奨されます。 データの保持方法による分類 概要 派生テーブルは「ネイティブ派生テーブル」「SQL ベースの派生テーブル」という分類のほかに、データの保持方法に応じて「一時的な派生テーブル」「永続的な派生テーブル(PDT)」にも分類できます。 それぞれの組み合わせで、4種類の派生テーブルがあり得ることになります。 参考 : Lookerの派生テーブル - 一時的な派生テーブルと永続的な派生テーブル 一時的な派生テーブル 一時的な派生テーブル は、データベースに物理的なテーブルとして書き込まれない派生テーブルです。 ユーザーが Explore などでデータをリクエストするたびに、Looker が派生テーブルの定義を使用して SQL クエリを構成し、都度データベースに対して新しいクエリを実行します。 ただし、有効なキャッシュが存在する場合はそれが使用されます。 データベースに実際のテーブルを作成しないため、Looker 用の書き込み権限や専用のスキーマを事前に準備する必要がありません。 また、リクエストのたびにクエリが実行されるため、常にベースとなるテーブルの最新のデータ状態を反映した結果を得ることができます。そのため、一時的な派生テーブルは、常に最新データを取得したい場合や、実行速度が速くデータベースに過度な負荷をかけない軽量なクエリに向いています。 一方で、クエリの実行に長時間を要する重い処理の場合は、パフォーマンスの低下を避けるために永続的な派生テーブル(PDT)を使用します。 永続的な派生テーブル(PDT) 永続的な派生テーブル (Persistent Derived Tables、略称 PDT)は、定義されたクエリの実行結果をデータベース上の スクラッチスキーマ (書き込み用の一時スキーマ)に実際のテーブルとして書き込み、指定したスケジュール(永続性戦略)に基づいて再構築する派生テーブルです。 一時的な派生テーブルがクエリのたびに都度計算されるのに対し、PDT は計算済みのデータをデータベース内に保持する仕組みを持っています。 PDT の最大のメリットは、頻繁に実行されるクエリの結果を保持することで、実行速度を向上させ、データベースへの負荷を大幅に削減できる点です。 特に、大量のデータや複数種類のデータを扱う場合(例:初回注文日を基準に顧客をコホート別に分類するなど)に有効で、リアルタイムで実行すると重い処理を事前に1度だけ計算し、その結果を PDT として再利用できます。 さらに、開発を効率化できる点も魅力です。データベース管理者(DBA)のサポートがなくても、Looker 上でインデックスやソートキーなどの最適化オプションを自らテストし、パフォーマンスの向上を確認してから DBA に本番環境への適用を依頼することができます。 永続性戦略 概要 永続性戦略 とは、永続的な派生テーブル(PDT)の再構築タイミングを決める設定のことです。PDT はデータベース上に実テーブルとして書き込まれることになるため、データを最新化するタイミングが重要になります。 特定の値が変化したことなどを検知するトリガーベースの戦略、時間経過をきっかけとする保存期間ベースの戦略、データベースが管理する戦略(マテリアライズドビュー)があります。 参考 : Lookerの派生テーブル - 永続性戦略 トリガーベースの戦略 データグループ( datagroups )を使用する、最も推奨される戦略です。 データベースの特定の値を監視する SQL クエリ( sql_trigger )を定義し、その値が変化したとき(例として ETL 処理の完了を示すフラグが立ったとき)に PDT を再構築します。これにより、ソースデータの更新に合わせて効率的にテーブルを更新できます。 保存期間ベースの戦略 persist_for パラメータを使用して、PDT を保持する時間を指定します。 指定した時間が経過した後にクエリが実行されると、PDT が再構築されます。厳密な更新タイミングを必要としない場合や、設定の簡略化を優先する場合に使用します。 データベースが管理する戦略(マテリアライズドビュー) Google Cloud の BigQuery など、データベース側の マテリアライズドビュー 機能を利用する戦略です。 LookML で materialized_view: yes を指定することで、Looker の PDT 管理ロジックではなく、データベース側の自動更新ロジックに委ねることができます。 増分 PDT 概要 増分 PDT (Incremental PDTs)は、PDT をすべて作り直すのではなく、新しく追加されたデータのみを既存のテーブルに追加する機能です。 通常の PDT は再構築のたびにテーブル全体を削除して作成し直しますが、増分 PDT では increment_key (日付やタイムスタンプなど)を基準に、新しいデータのみを取得して追加します。 これにより、テーブルの再構築にかかる時間とデータベースのリソース消費を大幅に削減できます。 参考 : 増分 PDT 利用するための必須条件 増分 PDT を導入する際には、システム上必須となる条件(必須条件)と、パフォーマンスに影響する推奨条件の2つがあります。 まず、増分 PDT を有効にするための必須条件について説明します。 増分 PDT は、再構築のタイミングを制御する「永続性戦略」において、必ずトリガーベースの戦略を採用していなければなりません。保存期間をベースとする戦略では、Looker の仕様上サポートされていないためです。 また、新しいデータの追加範囲を Looker に認識させるため、照会期間を定義する increment_key パラメータの設定が不可欠です(SQL ベースの場合はさらに Liquid フィルタの追加も必要になります)。 加えて、派生テーブルの定義方法にも制約があります。SQL ベースで定義する場合、必ず標準の sql パラメータを使用する必要があります。複雑なカスタム DDL ステートメント( sql_create など)を利用すると、Looker が正確な増分作成に必要なコマンドを判別できなくなり、構築に失敗してしまうためです。 また、制約として、接続先のデータベース自体が増分更新に必要な操作に対応している(行の削除や挿入を行う DDL コマンドをサポートしている)必要があります。これらを一つでも満たしていない場合、増分 PDT という機能を利用することができません。 一方、システム的な必須条件ではないものの、実運用において強く求められる推奨条件が存在します。 それは、元のソーステーブルに対して、時間ベースのクエリに向けた最適化(パーティショニングやインデックス、並べ替えキーの付与など)を施しておくことです。 増分 PDT はテーブルを更新するたびに、まずソーステーブルに対してクエリを実行し、増分キーの「最新値」を調べるという仕様になっています。もしソーステーブルが最適化されていないと、この最新値を探し出す処理そのものに膨大な時間とコストがかかってしまいます。つまり、この条件を満たしていなくても増分 PDT を構築すること自体は可能ですが、構築時間を短縮するという本来のメリットが失われ、かえって非効率になってしまうため、事前の最適化が強く推奨されています。 Looker 派生テーブルの選定基準 概要 基本的には、メンテナンス性の高いネイティブ派生テーブルかつ、データベースに負荷をかけない一時的な派生テーブルから構築を始めるのが第一選択です。 その後、クエリの重さに応じて一時的なテーブルを使うか、PDT を使うか検討します。 さらにデータ量が多く再構築コストが高ければ全体の再構築を伴う PDT ではなく、増分 PDT を使用することを判断します。 このように、パフォーマンス要件に合わせて最適な設定を選択するのが、Looker の派生テーブルのベストプラクティスです。 詳細を、以下に記載します。 定義方法の選定基準 派生テーブルのクエリをどのように記述するかによる分類です。基本的にはメンテナンス性の高いネイティブ派生テーブルを第一選択とします。 分類 定義 有用なケース 向いていないケース ネイティブ派生テーブル LookML (Explore やフィールド参照)を使用して定義する派生テーブル 既存の LookML 指標を再利用したい場合。データモデルの読みやすさと理解しやすさ(保守性)を高めたい場合 単一のSQLで完結しない処理やカスタムDDLが必要な場合など、特殊なSQL構文を要するケース SQL ベースの派生テーブル 標準的な SQL クエリを直接記述して定義する派生テーブル LookMLだけでは表現が難しい特殊な処理や複数ステップの処理が必要な場合。SQL Runner でテスト済みのクエリをそのまま流用したい場合 スキーマ変更の影響を受けやすいため、保守性を重視する場合。既存の LookML 指標を参照したい場合 データの保持方法の選定基準 クエリ結果をデータベースに物理的に保存するかどうかの分類です。絶対に不可欠になるまでは一時的な派生テーブルを使用し、パフォーマンス要件に応じて PDT 化を検討するのがベストプラクティスです。 分類 定義 有用なケース 向いていないケース 一時的な派生テーブル リクエストのたびにデータベースで都度クエリが実行され、物理的に保存されない派生テーブル 実行速度が速くデータベースへの負荷が低いクエリの場合。常に最新のデータ状態を反映した結果を得たい場合。データベースが読み取り専用の環境である場合 クエリの実行に長時間を要する重い処理や、頻繁に実行される複雑な事前集計の場合 永続的な派生テーブル(PDT) クエリの結果をデータベースの専用スキーマに実際のテーブルとして書き込み、保持する派生テーブル 大量のデータの事前結合や集計が必要な重い処理を1度だけ計算し、結果を再利用してパフォーマンスを向上させたい場合 パフォーマンス上の問題がなく常に最新のデータが必要な場合。ストレージやリソースコストの消費が許容できない場合 PDT の永続性戦略や増分 PDT の選定基準 PDT を使用する場合、永続性戦略や(再構築のタイミング)や増分 PDT を使用するか否かも選定する必要があります。 分類(戦略・種類) 定義 有用なケース 向いていないケース トリガーベースの戦略 指定したデータグループや時間間隔等に基づき自動的に再構築する戦略 複雑な重い処理で、ユーザーにクエリ完了の待機時間を発生させたくない場合(構築中も古いデータを返すため) ユーザー属性やテンプレートフィルタを使用するクエリ(サポート対象外) 保存期間ベースの戦略 最初にクエリを実行したタイミングで構築され、指定期間保持された後に削除される戦略 常に最新である必要はなく、一定期間結果を保持して再利用できれば十分な場合 期限切れ後にクエリを実行するユーザーに待機時間を発生させたくない場合。増分 PDT を利用したい場合 データベース管理 (マテリアライズドビュー) データベース側のマテリアライズドビュー機能を利用してテーブル更新を管理する戦略 データベース側で新しいデータが検出されるたびに更新されるため、リアルタイムなデータが必要なシナリオ データベース側が非対応な場合。マテリアライズドビューに関する高度な知識がない環境 増分 PDT 全体を再構築するのではなく、新しいデータ(増分)のみを追加して構築する設定 データ量が膨大で、テーブル全体の初期構築や再構築に大きなコストや時間がかかる場合 ソーステーブルの時間ベースの列がクエリ用に最適化(パーティショニング等)されていない場合。保存期間ベースの戦略を採用している場合 菊池 健太 (記事一覧) 事業開発部クラウドサポート課。2024年7月より、G-genに入社。群馬出身のエンジニア。前職でLookerの使用経験はあるが、Google Cloudは未経験なので現在勉強中。
G-gen の杉村です。当記事では、Google Cloud を管理・運用していくうえで必須となる 課金レポート の基本的な見方について、またコスト分析と対策を効率的に行うためのテクニックについて解説します。 課金レポートとは 課金レポートへのアクセスと権限 概要 請求先アカウントのスコープで閲覧 アクセス権限 アクセス手順 プロジェクトのスコープ アクセス権限 アクセス手順 レポートの基本的な見方 グループ化条件とフィルタ サービス単位での表示の限界 SKU とは グループ条件を SKU に設定する 表示対象の絞り込み その他のコスト分析テクニック 料金スパイクの原因を調査 特に料金が発生しているプロジェクトの特定 異常検知(Anomaly Detection) クレジット(割引)を考慮した分析 想定外の Google AI Studio 利用を発見 想定外のリージョン利用を発見 Tips レポート表示のタイムゾーンは PST レポート表示は約1日遅れ コスト予測の表示 カスタマイズしたレポートを保存・共有 BigQuery エクスポート 課金レポートとは Google Cloud の 課金レポート (請求レポートまたは Billing report とも呼称)は、Google Cloud の利用料金を確認したり、詳細な分析をするための画面です。Google Cloud コンソールで提供されています。 参考 : Analyze billing data and cost trends with Reports 課金レポートは 請求先アカウント ごとに表示できます。Google Cloud 再販パートナー経由で Google Cloud を利用している場合、課金レポートが閲覧できるかどうかはパートナーによりますが、例として株式会社 G-gen の顧客の場合、適切な IAM ロールをもってさえいれば、課金レポートを閲覧できます。 請求先アカウントの概念の詳細については、以下の記事を参照してください。 参考 : Google Cloudの請求の仕組みを徹底解説! - G-gen Tech Blog 課金レポート レポート画面では、期間の指定、サービスのフィルタリング、コストのグルーピングなどが自由に行えます。しかし、各種フィルタの使い方を理解しなければ「どのリソースがコスト高の原因なのか」を正確に突き止めることはできません。 当記事では、課金レポートの基本的な見方と、フィルタやグループ条件を使いこなして課金の状況を深掘りするコツを紹介します。 課金レポートへのアクセスと権限 概要 課金レポートを閲覧する際、レポートの閲覧スコープには2種類あります。 請求先アカウントのスコープで閲覧 プロジェクトのスコープで閲覧 1. は、特定の請求先アカウントに紐づくすべてのプロジェクト等の課金情報を横断して閲覧したり、フィルタリングして閲覧できます。 2. では、自分が管理権限を持っているプロジェクトに対してのみ、課金情報を閲覧できます。それぞれ、手順と必要な権限が異なります。 請求先アカウントのスコープで閲覧 アクセス権限 請求先アカウントのスコープで課金レポートを閲覧するには、操作者アカウントが、該当の請求先アカウントに対して少なくとも「請求先アカウント閲覧者( roles/billing.viewer )」ロールを持っている必要があります。権限が不足している場合、前述のプルダウンリストの中に請求先アカウントが表示されません。 ほかにも「請求先アカウントの費用管理者( roles/billing.costsManager )」ロールや「請求先アカウント管理者( roles/billing.admin )」ロールなどでも構いません。 このような権限を持つことで、ある請求先アカウントに紐づくすべての Google Cloud プロジェクトの請求情報を閲覧できます。 参考 : Analyze billing data and cost trends with Reports ‐ Full billing account permissions 請求先アカウントにロールを付与するには、該当の請求先アカウントに既に「請求先アカウント管理者( roles/billing.admin )」ロールを持っている人に依頼をして、ロールを付与してもらう必要があります。 アクセス手順 以下の手順で、特定の請求先アカウントの課金レポートにアクセスできます。 Google Cloud コンソール( https://console.cloud.google.com/ )にログイン 検索ボックスに「レポート」と入力 サジェストされた「レポート / プロダクト ページ・課金」をクリック プルダウンリストから請求先アカウントを選択 「レポートページに移動」をクリック 3. サジェストされた「レポート / プロダクト ページ・課金」をクリック 4. プルダウンリストから請求先アカウントを選択 / 5. 「レポートページに移動」をクリック なお、もし請求先アカウントの ID( 01230A-12A3B4-AB123C のようにハイフンで区切られた英数字)が分かっている場合には、以下の形式の URL に接続することで、課金レポートにクイックにアクセスできます。 https://console.cloud.google.com/billing/01230A-12A3B4-AB123C/reports プロジェクトのスコープ アクセス権限 プロジェクトのスコープで課金レポートを閲覧するには、該当のプロジェクトに対して、操作者アカウントが以下のいずれかの IAM ロールを持っている必要があります。 オーナー( roles/owner ) 編集者( roles/editor ) 閲覧者( roles/viewer ) Cloud Hub オペレーター( roles/cloudhub.operator ) サポート ユーザー( roles/iam.supportUser ) 上記に加えて、請求先アカウントに対して「プロジェクトの請求費用管理者( roles/billing.projectCostsManager )」ロールを持っていれば、複数のプロジェクトの課金情報を1つの課金レポート上で閲覧できます。つまり、プロジェクト A とプロジェクト B があり、どちらも請求先アカウント A に紐づいているとき、ある操作者が両方のプロジェクトに閲覧者ロールを持ち、かつ請求先アカウント A に「プロジェクトの請求費用管理者」ロールを持っていれば、1つの課金レポートでこれらのプロジェクトの課金を両方見ることができます。 このような権限設定は、「ある請求先アカウントに紐づくすべてのプロジェクトの課金情報を見せたいわけではない」「しかし、複数のプロジェクトの課金情報を見られる状態にしたい」といったときに有効です。 参考 : Analyze billing data and cost trends with Reports ‐ Project-scoped billing permissions 参考 : Cloud 請求先アカウントへの複数プロジェクトの費用閲覧権限を設定する アクセス手順 操作者が特定の Google Cloud プロジェクトのみの課金に関するレポートを閲覧したい場合は、以下の手順でレポートにアクセスできます。必要な IAM ロールについては、後述します。 Google Cloud コンソール( https://console.cloud.google.com/ )にログイン 左上のプロジェクトセレクタで対象のプロジェクトを選択 検索ボックスに「課金」と入力 サジェストされた「課金 / プロダクト・さまざまな課金とコストの管理ツール」をクリック 「リンクされた請求先アカウントに移動」をクリック 上記の手順 2. で、課金を確認したい対象プロジェクトを正しく選択するように注意してください。手順 4. のあとでプロジェクトを選択しなおしても構いません。 4. サジェストされた「課金 / プロダクト・さまざまな課金とコストの管理ツール」をクリック 5. 「リンクされた請求先アカウントに移動」をクリック レポートの基本的な見方 課金レポート画面にアクセスすると、初期状態では、当月の1日から現在までの課金状況が表示されます。グラフの上部には各種フィルタパネルが表示されており、グルーピングの方法や、対象サービスや SKU のフィルタリング、表示対象の期間などをコントロールできます。これらのフィルタパネルを駆使して、コスト分析を進めることになります。 課金レポート 表示されている料金は、請求先アカウントに紐づくすべての Google Cloud プロジェクトの合算値です。棒グラフは、初期状態だとサービス(BigQuery、Cloud Storage、Compute Engine、Vertex AI など)ごとに色分けされており、その内訳は棒グラフの下部に表形式で表示されます。 初期状態では「サービス」でグルーピングされている なお、該当の請求先アカウントに紐づく Google Cloud プロジェクトの一覧は、左部ペインの最下部の「アカウント管理」を押下することで確認できます。この画面の右ペインでは、この請求先アカウントにロールを紐づけられているプリンシパル(アカウント、グループ等)の一覧を確認できるほか、ロールの追加も可能です。 プロジェクトの一覧。右ペインでは請求先アカウントのロールを管理可能 グループ化条件とフィルタ サービス単位での表示の限界 課金レポート画面にアクセスすると、初期状態では、「グループ条件」フィルタで「サービス」が選択されています。「サービス」単位の表示では、BigQuery、Cloud Storage、Compute Engine といったサービスごとの合計金額が表示されます。 この表示方法では、各サービス内で「なぜ」課金が発生しているのかを理解することができません。 例えば BigQuery の料金を節約したいと考えたとき、スキャン量に対する課金が多いのか、あるいはストレージ料金が多いのかを区別しなければ、適切な対策を打つことができません。 例えば以下のスクリーンショットでは、「Networking」「Compute Engine」「Vertex AI」で特に課金が大きいことは分かりますが、「何に使っているのか」「誰が使っているのか」はわからない状態です。 この表示方法では情報が足りない SKU とは 「何に使っているのか」を理解するのに重要になるのが、 SKU (Stock Keeping Unit)単位での表示です。SKU とは、Google Cloud における課金単位です。 例えば BigQuery であれば、以下のような SKU があります。 SKU name SKU ID 説明 Analysis (asia-northeast1) 82D5-BCCE-5431 東京リージョンにおけるオンデマンドクエリのスキャン料金 Active Logical Storage (asia-northeast1) 709C-E503-30BF 東京リージョンにおけるアクティブなストレージ料金 レポートを SKU 単位で表示することで、コスト削減に向けた具体的な打ち手を検討できるようになります。 参考 : SKU Groups - BigQuery 参考 : SKU Groups グループ条件を SKU に設定する 左上の「グループ化」フィルタで「SKU」を選択すると、グラフの凡例が SKU ごとに細分化されます。 以下のスクリーンショットの例では、「Networking」という大まかな分類で示されていた内訳が、SKU 単位で表示されるようになったことで、「Cloud Load Balancing」と「Cloud Armor ポリシー」の課金であることがわかるようになりました。 SKU にグループ化条件を変更すると内訳が詳細化する なお、グループ条件には SKU のほかにも以下のような項目が指定可能です(一部抜粋)。 プロジェクト : プロジェクトごとのコストを表示 プロジェクト階層 : 組織、フォルダ、プロジェクトの構造に基づいた表示 ロケーション : リージョンやマルチリージョンごとのコストを表示 ラベル : リソースに付与したラベルのキーごとのコストを表示 表示対象の絞り込み フィルタを設定することで、特定の SKU だけを表示対象として絞り込むことができます。 先程のスクリーンショットの続きの作業として、特に課金が大きかった「Cloud Load Balancer Forwarding Rule Minimum Global」という SKU が、どのプロジェクトで発生しているのかを調査してみます。上部の「SKU」フィルタで「Cloud Load Balancer Forwarding Rule Minimum Global」のみを選択し、他は表示対象外とします。これで、この SKU に関する課金だけがレポートに表示されるようになります。次に、「グループ化」フィルタで「プロジェクト」を選択します。特定の SKU だけに絞られた表示が、プロジェクトごとにグルーピングされるようになりました。 特定の SKU の課金がどのプロジェクトで発生しているか判明 該当のプロジェクトの管理者を特定することで「誰が使っているのか」が判明します。管理者に SKU 情報などを連絡することで、検証用の Cloud Load Balancer の削除などの対策を打つことができます。 このように、グループ条件(切り口)とフィルタ(絞り込み)を交互に切り替えることで、課金データの中からボトルネックを特定できます。次に、その他のコスト分析テクニックの例をいくつか挙げます。 その他のコスト分析テクニック 料金スパイクの原因を調査 ある月で、Google Cloud 利用料金が意図せず高額になった(スパイクした)とします。以下のようにしてスパイクした SKU を特定し、さらにその SKU の課金が発生したプロジェクトを特定します。これは、当記事内の前述の例で示したものと同じ手法です。 グループ条件を「SKU」に変更 特に料金のかかっている SKU を特定 「SKU」フィルタで、特定した SKU だけに表示を絞り込む グループ条件を「プロジェクト」に変更 特にその SKU が多く発生しているプロジェクトを特定 該当プロジェクトの担当者と連携して、技術的に原因を調査 課金レポートを開いてすぐは、デフォルトでグルーピングが「サービス」になっており、スパイクの原因を直接的に特定しづらい状態です。まずはグループ条件を SKU にして、発生した課金の正体を特定することが重要です。 特に料金が発生しているプロジェクトの特定 組織全体で同じ請求先アカウントを使っているようなケースで、組織のクラウド管理者や情報システム部門が、特に料金が高いプロジェクトを特定して、担当者に改善を促すようなケースでは、以下の手順が参考になります。 グループ条件を「プロジェクト」に変更 特に料金のかかっているプロジェクトを特定 「プロジェクト」フィルタで、特定したプロジェクトだけに表示を絞り込む グループ条件を「SKU」に変更 これにより該当プロジェクトで特に料金が高い SKU を特定 該当プロジェクトの担当者に、情報提供しつつ対策を指示 先に紹介した例だと、まず SKU を絞ってからプロジェクトでグルーピングしていますが、この例では順序が逆です。SKU(課金の要素、原因)に先に注目するか、プロジェクト(誰が課金を発生させているか)に先に注目するかの違いです。 異常検知(Anomaly Detection) Google Cloud の請求先アカウントには、過去の利用傾向から逸脱した課金が発生した際に自動で検知する 異常検知(Anomaly Detection) 機能が備わっています。 意図しない設定ミスや、想定外のトラフィック急増などによるコストスパイクを早期に発見するために有効です。異常が検知されると、詳細画面から「どのサービス、どの SKU が原因か」といった根本原因分析(RCA)の結果を確認できます。 参考 : 費用の異常を表示して管理する 参考 : Google Cloud請求先アカウントの異常検知(Anomaly Detection)を解説 - G-gen Tech Blog クレジット(割引)を考慮した分析 課金レポート上部のフィルタパネルにある「コスト削減」フィルタを使うことで、費用ベースの確約利用割引(CUD)やプロモーション用クレジット、無料枠の適用状況をコントロールできます。 「特定のサービスの利用量そのものが増えているか」を調べたいときはクレジットを除外し、「最終的にいくら支払うのか」を調べたいときはクレジットを含める、といった使い分けができます。 想定外の Google AI Studio 利用を発見 以下の記事では、Gemini API の不正利用に警戒する目的から、Google AI Studio(Gemini API)の使用有無を、課金レポートを使って特定する手順を紹介しています。 blog.g-gen.co.jp 想定外のリージョン利用を発見 セキュリティガバナンスやデータ主権の観点から、利用リージョンを制限している場合に役立つテクニックです。意図しないリージョンでのリソース作成は、シャドー IT の発見やコスト最適化のヒントになることが多くあります。 グループ条件を「ロケーション」に設定 リストの中から、利用を許可していないリージョン(例: us-east1 )が含まれていないか確認 想定外のリージョンがあれば、まず「ロケーション」フィルタで該当のリージョンのみを選択して表示をフィルタリングする 次にグループ条件を「プロジェクト」に変更して、どのプロジェクトで課金が発生しているか特定 Tips レポート表示のタイムゾーンは PST 課金レポートの表示日付のタイムゾーンは PST (太平洋標準時、UTC-8)です。JST(日本標準時、UTC+9)とは マイナス17時間 の時差があります。 例えば、実際に課金が発生したのが日本時間の「2026年5月11日(月)10:00」だとしても、レポート上は「2026年5月10日(日)」の課金として表示されます。以下の記事も参照してください。 blog.g-gen.co.jp レポート表示は約1日遅れ Google Cloud プロジェクトで課金が発生してから、それが課金レポートの表示に反映されるまで、 1日間程度の遅れ があります。 注意が必要なのは、前述のとおりレポート表示のタイムゾーンは PST なので、レポート上で2026年5月11日の課金として表示される課金が実際に発生したのは、日本時間2026年5月11日 17:00 から2026年5月12日 16:59 の間ということになります。そのため、レポートの日付だけに注目すると、以下のスクリーンショットのように1日以上遅れて見えることになります。 レポートを閲覧しているのは5月4日の午前 上記のスクリーンショットのレポートを閲覧しているのは5月4日の午前10時ころです。毎日7,000円以上の課金が発生しているのが通常なのに、まだ5月3日の分が1,000円程度しかレポートに反映されていないところを見ると、一見、5月3日の午前3時ころまでしかレポートが反映されておらず、反映が31時間ほど遅れているように感じます。しかし実際には、レポートのタイムゾーンは PST ですので、5月3日の午前3時(PST)は5月4日の午後8時(JST)です。14時間程度の遅延で済んでいることがわかります。 参考 : Analyze billing data and cost trends with Reports - Why are my usage date costs different than my invoice month costs? Typically, your cost details are available within a day, but can sometimes take more than 24 hours. (通常、料金の詳細は1日以内に確認できるようになりますが、場合によっては24時間以上かかることもあります。) コスト予測の表示 期間フィルタで指定する期間に将来の日付が含まれていると、過去の利用傾向に基づいた機械学習による予測値が、グラフ上に薄いグレーの棒として表示されます。予算超過の兆候を早めに察知するために便利です。 カスタマイズしたレポートを保存・共有 フィルタやグループ条件を細かく設定したレポートは、他人に共有できます。レポート上部の「共有」ボタンを押下すると、フィルタの設定情報を含んだ共有用 URL が発行されます。 また、レポートは「保存済みレポート」として名前を付けて保存することもできます。 BigQuery エクスポート 課金データを BigQuery へエクスポートすることで、SQL で詳細な分析を行ったり、データポータル(英名 Data Studio、旧称 Looker Studio)でオリジナルのコスト可視化ダッシュボードを作成できます。 参考 : Cloud Billing データを BigQuery にエクスポートする BigQuery エクスポートを初めて有効にすると、前月の1日の課金データまで遡って BigQuery にエクスポートされます。最初のデータのエクスポートが完了するまで5日ほどかかりますが、それ以降は1日1回、課金データがエクスポートされます。前月の1日以前のデータをエクスポートすることはできません。 参考 : BigQuery 内の Cloud Billing データテーブルについて - データの可用性 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X(旧 Twitter)では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it
G-gen の佐々木です。当記事では、Google Cloud の AI エージェント開発プラットフォームである Gemini Enterprise Agent Platform の概要を解説します。 Gemini Enterprise Agent Platform とは Studio 概要 Agent Studio Agents - Build 概要 Agent Garden(プレビュー) Agent Development Kit Managed Agents API(プレビュー) MCP サーバー スキルレジストリ(プレビュー) RAG Engine(プレビュー) Vector Search Agent Search Agents - Scale 概要 Agent Runtime セッション メモリバンク サンドボックス フィードバックサービス(プレビュー) Agents - Govern 概要 Agent Registry ポリシー Agent Gateway セキュリティ Agents - Optimize 概要 オブザーバビリティ エージェントの評価 Example Store(プレビュー) Models 概要 Model Garden 使用オプション モデルのチューニング Gen AI Evaluation Service Model Registry エンドポイント バッチ推論 Models - その他のサービス 概要 データセット Feature Store トレーニング Experiments ML メタデータ Pipelines モデルモニタリング Notebooks 概要 Colab Enterprise Agent Platform Workbench Gemini Enterprise Agent Platform とは 2026年4月に開催された Google Cloud Next '26 で、AI エージェントを構築・運用するための統合プラットフォームとして Gemini Enterprise Agent Platform (旧称 : Vertex AI、以下 Agent Platform と記載)が発表されました。 Agent Platform は、これまで Vertex AI が提供してきた機械学習基盤を組み込みつつ、エージェント中心のコンポーネントを新たに統合したサービスです。 Agent Platform はエージェントのライフサイクルを Build 、 Scale 、 Govern 、 Optimize の4領域で整理し、それらを横断する開発環境として Studio 、モデル基盤として Models 、開発作業環境として Notebooks を提供します。 当記事では、Agent Platform を構成する各コンポーネントを概要レベルで紹介します。記事内のカテゴリは、基本的には2026年8月現在の Google Cloud コンソールで選択できる項目に対応しています。また2026年8月現在、 asia-northeast1 (東京リージョン)においてプレビュー提供となっているコンポーネントについては、見出しに(プレビュー)と付記しています。 カテゴリ コンポーネント 概要 Studio Agent Studio エージェント開発の作業を一元化したコラボレーションワークスペース Agents - Build Agent Garden 事前構築済みエージェントサンプルを提供する厳選ライブラリ Agents - Build Agent Development Kit エージェントの構築・デバッグ・デプロイ用のオープンソースフレームワーク Agents - Build Managed Agents API 単一の API 呼び出しでマネージドな自律エージェントを構築・実行できるサービス Agents - Build MCP サーバー Google Cloud サービスをリモート MCP 経由で AI アプリに接続する仕組み Agents - Build スキルレジストリ エージェントの機能を拡張するスキルを一元管理する低レイテンシなプライベートリポジトリ Agents - Build RAG Engine 検索拡張生成(RAG)を容易にするデータフレームワーク Agents - Build Vector Search ScaNN を基盤とするセマンティック検索エンジン Agents - Build Agent Search Google 品質のセマンティック検索と生成 AI を組み合わせた検索基盤 Agents - Scale Agent Runtime エージェントを HTTP サーバーとしてホストするマネージドランタイム Agents - Scale セッション ユーザーとエージェント間のやり取り履歴を保持する機能 Agents - Scale メモリバンク エージェントとの会話に基づいて長期記憶を動的に生成・管理するマネージドサービス Agents - Scale サンドボックス コード実行・ブラウザ操作などをエージェント本体と隔離された環境で安全に実行する機能群 Agents - Scale フィードバックサービス エージェントとのやり取りに対するユーザーフィードバックを収集・分析する機能 Agents - Govern Agent Registry エージェント・MCP サーバー・エンドポイントを管理する統合カタログ Agents - Govern ポリシー Agent Gateway が用いる IAM 許可ポリシーとセマンティック ガバナンス ポリシーの総称 Agents - Govern Agent Gateway エージェントインタラクションを保護・管理するネットワーキング基盤 Agents - Govern セキュリティ デプロイ済みエージェントを継続監視し検出結果を確認する機能 Agents - Optimize オブザーバビリティ エージェントと MCP サーバーのパフォーマンス・健全性監視 Agents - Optimize エージェントの評価 エージェントのパフォーマンス・安全性・品質を測定する評価機能 Agents - Optimize Example Store Few-shot サンプルを保存・動的に取得するマネージドサービス Models Model Garden Google・パートナー・OSS の各モデルを横断的に扱うモデルライブラリ Models 使用オプション 生成 AI モデルの5種類の課金・提供方式の体系 Models モデルのチューニング Gemini をラベル付きデータセットで特定タスクに適応させる機能 Models Gen AI Evaluation Service 生成 AI モデルを客観的・データドリブンに評価するツール Models Model Registry ML モデルのライフサイクルを管理する中央リポジトリ Models エンドポイント オンライン推論用にモデルを関連付ける物理リソース Models バッチ推論 大規模データ向け非同期・高スループット・低コストの推論サービス Models - その他のサービス データセット AutoML やカスタムモデル用ソースデータの一元管理サービス Models - その他のサービス Feature Store 機械学習で使う特徴量を一元管理する特徴管理サービス Models - その他のサービス トレーニング 独自 ML モデルを学習させる機能群(AutoML / カスタムトレーニング / Ray on Agent Platform) Models - その他のサービス Experiments モデル開発のプロセスを追跡・比較・分析する実験管理ツール Models - その他のサービス ML メタデータ ML システムが生成するメタデータとアーティファクトの記録管理サービス Models - その他のサービス Pipelines ML ワークフローをサーバーレスでオーケストレーションするマネージドサービス Models - その他のサービス モデルモニタリング 本番環境のモデル品質劣化を検出・追跡するモニタリングサービス Notebooks Colab Enterprise チーム利用に最適化されたマネージド Jupyter ノートブック環境 Notebooks Agent Platform Workbench VM インスタンス上で動作するカスタマイズ性の高い JupyterLab 環境 参考 : Agent Platform の概要 参考 : Introducing Gemini Enterprise Agent Platform, powering the next wave of agents Studio 概要 このカテゴリでは、Build / Scale / Govern / Optimize の各ライフサイクルを横断する開発環境である Agent Studio が提供されています。モデル探索からシステム指示の改良、プロンプト最適化、Web アプリケーションとしてのデプロイまでを一元的に行える開発フロントエンドとして位置づけられています。 Agent Studio Agent Studio は、エージェント開発に必要な作業を一元化した、Google Cloud コンソール内のコラボレーションワークスペースです。コードの編集とプレビューを並行して行える「インタラクティブキャンバスビュー」を備え、自然言語での対話を起点にプロンプトとシステム指示を組み立てていきます。 モデルの探索においては、後述の Model Garden を経由して候補となるモデルを選び、同じ入力に対する挙動を Agent Studio 上で並列に比較できます。システム指示も Agent Studio に自動生成させたうえで、複数バージョンを並べて結果を見比べることで素早く改良できます。 チャットインターフェースを用いたモデルの挙動比較 外部知識の取り込みも幅広く、Google 検索 / Google マップによるリアルタイムグラウンディングのほか、後述の RAG Engine や Agent Search、Elasticsearch などを介して自社データを参照させられます。あわせて、思考レベル、構造化出力、安全フィルタといったモデル挙動の細かな制御もコンソールから調整できます。 仕上げたプロンプトはそのまま Web アプリケーションとして本番環境にデプロイでき、Google Cloud エコシステム全体と統合された API・デプロイ経路を経由してエージェントを公開することができます。 参考 : Agent Studio の概要 Agents - Build 概要 このカテゴリでは、エージェント本体とその周辺機能を構築するためのコンポーネント群を扱います。事前構築済みのエージェントサンプルを提供する Agent Garden 、エージェントのオープンソースフレームワークである Agent Development Kit 、単一の API 呼び出しでマネージドなエージェントを構築・実行できる Managed Agents API 、Google Cloud サービスへの接続口となる MCP サーバー 、エージェントの機能を拡張するスキルを一元管理する スキルレジストリ 、エージェントの知識基盤となる RAG Engine / Vector Search / Agent Search が含まれ、エージェントのロジックとデータソースの両方をカバーします。 Agent Garden(プレビュー) Agent Garden は事前構築済みのエージェントのサンプルを提供するライブラリです。2026年8月現在はプレビュー提供となっています。 サンプルエージェントは RAG Engine、ベクトル検索、Gemini モデルなど他のコンポーネントとシームレスに連携できるように構成されており、ドキュメントに基づくカスタマーサポートや業種特化の調査統合といった、特定タスクに合わせた素早い立ち上げを支援します。 また、GitHub に公開されているサンプルエージェントのソースコードにアクセスし、ロジックを独自にカスタマイズすることもできます。 Agent Garden では多数のサンプルエージェントが提供される Agent Garden からサンプルエージェントをデプロイする 参考 : Agent Garden Agent Development Kit Agent Development Kit (以下、ADK)は、オープンソースの AI エージェント開発用フレームワークであり、エンタープライズ規模の信頼性の高いエージェントの構築・デバッグ・デプロイを容易にします。 単純なタスクを処理するエージェントから、複数のエージェントが協働して複雑なタスクを処理するマルチエージェントシステムまで、柔軟に設計・実装できます。 開発したエージェントは、後述の Agent Runtime や Vertex AI、Cloud Run、Google Kubernetes Engine(以下、GKE)など、マネージドな実行環境にデプロイすることができます。 参考 : Agent Development Kit ADK を使用したエージェントの開発、ユースケースについては、以下の記事カテゴリで取り上げています。 blog.g-gen.co.jp Managed Agents API(プレビュー) Managed Agents API on Agent Platform は、単一の API 呼び出しでマネージドかつ自律的なエージェントを構築・実行できるサービスです。2026年8月現在はプレビュー提供となっています。 エージェントは Google の Antigravity ハーネスで駆動され、隔離された Linux サンドボックスの内部でコード実行、ファイル操作、Web 検索、MCP サーバー経由の外部システム連携などを自律的に行います。Antigravity ハーネスは Google 自社のエージェント製品も動作する実行基盤で、Gemini 3.5 Flash と相互に最適化されています。 ADK のようなフレームワークでロジックを記述する必要がなく、Agent Runtime へのデプロイ作業も不要なため、コード実行を伴う自律エージェントを API 呼び出しだけで素早く立ち上げたいケースに向いています。 サービスの詳細については、以下の記事をご一読ください。 blog.g-gen.co.jp 参考 : Agent Platform の Managed Agents API の概要 MCP サーバー Google Cloud MCP servers は、Google および Google Cloud が提供するフルマネージドのリモート MCP サーバーです。 Google および Google Cloud の各サービスを、エンタープライズレベルのガバナンス・セキュリティ・アクセス制御を備えたリモート MCP サーバー経由で利用することができます。IAM でユーザーアクセスを制御し、専用の HTTP エンドポイントを通じて Gemini CLI などの AI クライアントからすぐに使い始めることができます。 リモート MCP サーバーは Google が管理するインフラストラクチャ上で動作するため、ユーザーによる運用管理は不要です。また、Apigee や Cloud Run を使用することで、独自に実装した MCP サーバーを公開することもできます。 参考 : Google Cloud MCP servers overview Google Cloud が提供するリモート MCP サーバーについては、以下の記事で解説しています。 blog.g-gen.co.jp スキルレジストリ(プレビュー) スキルレジストリ (Skill Registry)は、エージェントの機能を拡張する スキル (Skill)を一元管理するための、安全かつ低レイテンシなプライベートリポジトリです。2026年8月現在はプレビュー提供となっています。 スキルは、構造化された手順、実行可能なコード、ドキュメントをひとまとめにした自己完結型のパッケージです。スキルレジストリに登録されたスキルは、ユーザーの意図に応じて関連性の高いものをエージェントが動的に検出・読み込みでき、複数のエージェント間で同じスキルを共有・再利用することもできます。 スキルレジストリでは、表示名・タイムスタンプ・ラベルなどのメタデータとコンテンツを持つトップレベルのリソースである スキル と、そのスキルの特定バージョンを表す不変のスナップショットである スキルリビジョン (Skill Revision)の2階層でリソースが管理されます。スキル自体は可変ですが、リビジョン単位ではコンテンツが固定されるため、過去バージョンの再現性を保ちながらリビジョンを切り替えて段階的に更新していくバージョン管理が可能です。 スキルの本体は zip アーカイブで登録し、ルートに YAML フロントマターと Markdown 本文からなる SKILL.md を配置することでスキルを定義します。スキルの作成・更新時にはペイロードが非同期で自動検証され、アーカイブサイズ(10MB 以下)、解凍後の総ファイルサイズ(500MB 以下)、ファイル数(10,000 個以下)、 SKILL.md の文字数(500,000 文字以下)といった制約に違反していないかが確認されます。 参考 : スキル レジストリの概要 RAG Engine(プレビュー) RAG Engine は、検索拡張生成(Retrieval-Augmented Generation、以下 RAG)を容易にするためのコンポーネントです。2026年8月現在はプレビュー提供となっています。 ローカルファイル、Cloud Storage、Google Drive など複数のデータソースから取り込んだデータを、変換・インデックス化のパイプラインを通じて コーパス (検索用に最適化されたデータのインデックス)として整備します。エージェントの応答生成時にコーパスを検索して LLM のコンテキストに独自のデータを加えることで、ハルシネーションを抑制します。 コーパスは検索対象のデータの論理的な単位であり、データの実体が保存されるベクトルデータベースが別途必要となります。ベクトルデータベースのインフラは2つのモードから選択することができ、インフラ管理を完全に抽象化した サーバーレスモード と、専用の Cloud Spanner インスタンスを使用し、高いカスタマイズ性を実現できる Spanner モード が存在します。 RAG Engine は、2026年8月現在 europe-west3 、 europe-west4 などのリージョンでは GA となっていますが、 asia-northeast1 を含む多数のリージョンではプレビュー提供となっています。なお us-central1 、 us-east4 も GA ですが、いずれも許可リスト(allowlist)への登録が必要で、新規プロジェクトでは他のリージョンの利用が案内されています。最新のリリース状況については以下のドキュメントを参照してください。 参考 : Gemini Enterprise Agent Platform RAG Engine の概要 Vector Search Vector Search は、Google Research が開発した ScaNN アルゴリズムを基盤とするセマンティック検索エンジンで、Google 検索、YouTube、Google Play と同じ技術スタックを利用したエンタープライズ向けのベクトル検索基盤を利用できます。 ユーザー側で用意した埋め込みベクトルを Cloud Storage に保存し、それを元にインデックスを作成します。作成したインデックスはエンドポイントとしてデプロイすることで、アプリケーションからエンドポイント経由でベクトル検索を使用することができます。 検索方式は、意味の近さで探す 高密度エンベディング検索 、キーワード一致を重視する スパースエンベディング検索 、両者を組み合わせた ハイブリッド検索 の3方式に対応しています。 参考 : ベクトル検索 Agent Search Agent Search (旧称 : Vertex AI Search)は、前述の Vector Search 同様、Google 品質のセマンティック検索(意味論検索)機能をフルマネージドで利用できるコンポーネントです。過去には Generative AI App Builder、Vertex AI Search and Conversation、Vertex AI Agent Builder、AI Applications など複数のブランド名を経てきた経緯があります。 Vector Search が埋め込みベクトルの類似検索エンジンに特化しているのに対し、Agent Search はドキュメントの取り込み・パース・自然言語理解・要約までを内包したフルマネージドの検索ソリューションとなっており、 検索 と レコメンデーション を2本柱の主軸機能として提供します。 データソースとして Cloud Storage や BigQuery に保存した構造化・非構造化データのほか、一般公開ウェブサイトのデータもインデックスとして登録できます。自然言語クエリによる検索とレコメンデーションに加えて、検索結果の要約生成やフォローアップ質問を踏まえたマルチターンの回答生成といった LLM 機能も内蔵しており、外部 LLM のグラウンディングソースとしても利用できます。 汎用のカスタム検索のほかに、映画・動画・音楽向けの メディア検索 や、FHIR 形式の医療データ向けの ヘルスケア検索 といった業種特化ソリューションも提供されています。 参考 : Agent Search の概要 Agent Search の詳細については、以下の記事もご一読ください。 blog.g-gen.co.jp Agents - Scale 概要 このカテゴリでは、構築したエージェントを本番ワークロードとして提供するための実行基盤群を扱います。エージェントをマネージドにホストする Agent Runtime 、ユーザーとエージェント間のやり取りを保持する セッション 、会話に基づいて長期記憶を生成・管理する メモリバンク 、コード実行やブラウザ操作などリスクを伴う処理を隔離環境で実行する サンドボックス 、エージェントに対するユーザーフィードバックを収集・分析する フィードバックサービス が組み合わさり、ステートを伴うエージェントの安定運用を支えます。 Agent Runtime Agent Runtime (旧称 : Agent Engine)は、開発した AI エージェントをリモートからアクセス可能な HTTP サーバーとしてホストするフルマネージドの実行基盤です。 ADK をはじめ、LangChain や LangGraph といった様々なエージェントフレームワークのデプロイを容易にするテンプレートが提供されており、テンプレートに適合しない場合でもカスタムエージェントとして構築できます。ただし、2026年7月現在、Agent Runtime にデプロイできるエージェントは Python で開発されたもののみとなっています。 自動スケーリング機能、モニタリング、ロギングなど、エージェントの運用に必要な機能を組み込みで利用することができるほか、後述のセッションやメモリバンクと連携して記憶や履歴を伴うマルチターンのエージェントの会話を容易に実現できます。 参考 : エージェントをデプロイする Agent Runtime の詳細については以下の記事もご一読ください。 blog.g-gen.co.jp セッション セッション (Sessions)は、ユーザーとエージェント間のやり取りの履歴を保持し、エージェントが会話のコンテキストを参照するための機能です。 セッションは「ユーザーとエージェントシステム間の一つの会話の流れにおけるメッセージとアクション(イベント)の時系列」と定義され、イベントには会話の内容のほか関数呼び出しなどエージェントが実行したアクションが保存されます。 コアコンセプトとして、現在の会話中のみに関連する一時データを表す「状態」と、特定のユーザーの複数のセッションでアクセスできるパーソナライズされた情報を表す「記憶」が分離されている点が特徴です。記憶の保存・参照が必要な場合は後述のメモリバンクを使用します。 単一セッション内の会話の状態を管理する ADK で開発したエージェントを Agent Runtime にデプロイした場合、セッション管理はデフォルトで使用されます。その他のフレームワークで開発したエージェントの場合は、API を使用してセッション管理を行うことができます。 参考 : Agent Platform セッションの概要 メモリバンク メモリバンク (Memory Bank)は、ユーザーとエージェントの会話に基づいて長期記憶を動的に生成・管理するマネージドサービスです。 メモリバンクは内部的に LLM を用いて、セッションのイベント(会話履歴)からユーザーの嗜好や事実を抽出・要約し、ユーザー単位で保存します。これにより、エージェントとの会話(セッション)を一度中断しても、後の会話でユーザーごとにパーソナライズされた応答を返すことができるエージェントを構築できます。 不変のドキュメントを根拠とする RAG とは異なり、メモリバンクはユーザーごとに進化していく動的なコンテキストを扱う点が特徴です。 セッションとメモリバンクは独立した機能ですが、併用できます。セッションが単一会話内の状態(短期記憶)を、メモリバンクが複数セッションを跨ぐ長期記憶を担うため、両者を組み合わせることで、会話中の文脈維持と、過去の会話を踏まえたパーソナライズを両立できます。 メモリバンクを使用してユーザーごとの記憶を生成・管理する ADK では組み込みの機能として VertexAiMemoryBankService が提供されており、エージェントのツールおよびコールバックとして組み込むだけでメモリバンクとの連携を実現できます。その他のフレームワークで開発したエージェントの場合、セッション同様に API が提供されています。 参考 : Agent Platform メモリバンク 以下の記事では、ADK で開発したエージェントを Agent Runtime で実行する際にメモリバンクを利用する方法を解説しています。 blog.g-gen.co.jp サンドボックス サンドボックス (Sandbox)は、エージェントの代わりに特定のタスクを実行するために起動される隔離コンピューティング環境を提供する機能群の総称です。 エージェントが生成したコードやブラウザ操作といったリスクを伴う処理を、エージェント本体とは別の短命な環境に隔離して実行することで、ホストシステムや他のエージェントへの影響を防ぎます。隔離・セキュリティ・安全性の3つを基本原則とし、コンテナベースのサンドボックス境界によって、有害なコマンドやリソースを大量に消費するループの影響範囲をサンドボックス内に閉じ込めます。 サンドボックスでは、以下の機能が提供されます。 機能 説明 Code Execution エージェントが生成したコードを隔離サンドボックス上で実行する機能。LLM が苦手な厳密な数値計算・データ処理・可視化などをコード実行で補強し、財務計算・データサイエンスワークフロー・信頼できないコードの隔離実行といったユースケースで利用される。サンドボックスは1秒未満で起動でき、ファイルシステムへのアクセスは制限され、外部ネットワークへのアクセスも遮断されている Computer Use (プレビュー) コンテナ化されたブラウザ環境を提供し、エージェントが URL ナビゲーション・要素クリック・テキスト入力・スクリーンショット取得などの操作を実行できる機能。Chrome DevTools Protocol(CDP)経由で Playwright などのブラウザ自動化フレームワークから操作することも可能 カスタムコンテナ (プレビュー) サンドボックスの実行環境としてユーザー独自の Docker イメージを持ち込める Bring Your Own Container(BYOC)機能。標準のサンドボックスでは利用できない依存ライブラリ・ランタイムバージョン・プロプライエタリツールを伴うワークロードに対応する。コンテナイメージは Artifact Registry に格納する スナップショット (プレビュー) サンドボックスの状態(インストール済みライブラリ・ファイルシステムの変更・メモリ状態など)を保存して後から復元できる機能。チェックポイントによる復旧や、同一スナップショットからの分岐実行で複数のアプローチを並行検証する用途で利用できる なお、上記のうち Computer Use、カスタムコンテナ、スナップショットの3機能は2026年8月現在プレビュー提供となっています。また、Code Execution は2026年8月現在、 us-central1 リージョンでのみ利用できます。 参考 : Sandboxes overview 参考 : Code Execution 参考 : Computer Use 参考 : Custom container sandbox overview 参考 : Manage snapshots フィードバックサービス(プレビュー) フィードバックサービス (Feedback Service)は、Agent Runtime でホストされているエージェントとユーザーのやり取りに対するフィードバックを収集・分析するための機能です。2026年8月現在はプレビュー提供となっています。 ユーザーの反応を高評価・低評価( thumbs_up / thumbs_down )の2値で記録できるほか、評価の理由を示すラベルと自由記述のテキストを付加できます。ラベルには accurate (正確)や helpful (有用)などのポジティブラベルと、 inaccurate (不正確)や hallucination (ハルシネーション)などのネガティブラベルが、それぞれ8種類ずつ事前定義されています。 フィードバックはセッション ID とイベント ID を指定して登録するため、前述のセッションが保持する会話のタイムラインのうち、特定の会話ターンやイベントに紐づけて管理できます。また、オプションの FeedbackContext リソースとして会話ログを添付しておくことで、元のセッションが削除された後も、分析に必要な会話のコンテキストをフィードバック側に保持できます。 フィードバックの作成・取得・更新・削除・一覧表示は REST API または Python SDK から実行でき、フィードバックの保存基盤がマネージドで提供されるため、フィードバック用のデータベースを独自に構築・運用する必要がありません。 また、Agent Runtime で Cloud Trace によるトレースを有効化している場合は、コンソール上でトレースイベントと並べてフィードバックを確認できます。 参考 : フィードバック サービスの概要 Agents - Govern 概要 このカテゴリでは、エージェントの動作と通信を統制するためのガバナンスコンポーネント群を扱います。MCP サーバー / ツール / エージェントを一元管理する Agent Registry 、認証・認可と自然言語ベースの統制を担う ポリシー 、ネットワーク境界を保護する Agent Gateway 、Security Command Center 連携でリスクを可視化する セキュリティ機能 で構成されます。 Agent Registry Agent Registry は、Google Cloud 内のエージェント、MCP サーバー、エンドポイントを保存・検出・管理できる、一元化された統合カタログです。 Agent Registry が備える主要機能は以下のとおりです。 機能 説明 カタログ機能 エージェント、MCP サーバー、エンドポイントを登録する 検索 / 検出機能 レジストリへのクエリで利用可能な機能を特定する メタデータ管理機能 エージェントの「スキル」や MCP サーバーの「ツール」を抽出する Agent Registry では、エージェント( Agent )、MCP サーバー( McpServer )、エンドポイント( Endpoint )の3種類を サービス ( Service )としてカタログに登録します。Agent Runtime にデプロイしたエージェントや、Google Cloud が公式で提供するエージェント、MCP サーバーなどは自動で登録され、外部リソースや A2A プロトコルを実装していないエージェントなど、自動検出がサポートされていないものは手動で登録できます。 サービスの種類 説明 エージェント ユーザーが開発、もしくは Google Cloud が提供する自律的な AI エージェント MCP サーバー ユーザーが開発、もしくは Google Cloud やサードパーティが提供する MCP サーバー エンドポイント エージェントがアクセスする外部ターゲット URL を管理可能なリソースとして抽象化したもの 登録されているエージェントと他のサービス(エージェント、MCP サーバー、エンドポイント)との間で バインディング ( binding )を確立することで、エージェントから他サービスへの呼び出し関係をカタログ上にマッピングできます。サービスの利用に認証が必要な場合は、エージェントと認証プロバイダとのバインディングを作成し、認証情報を委任することができます。なお、呼び出しの実際の可否は後述の Agent Gateway と IAM 許可ポリシーで制御されるため、バインディング自体はアクセス制御の主体ではない点に注意してください。 このように、サービスを1つのカタログで一元管理することで、AI ワークロードでありがちな「ツールアクセスの断片化」「データの分離」「冗長なサービス」といった課題を解決します。A2A や MCP といったオープンプロトコルと密接に連携することで、既存スキルやツールの再利用、統合の簡素化を実現しています。 参考 : Agent Registry の概要 参考 : バインディングを管理する Agent Registry については、以下の記事で詳細に解説されています。 blog.g-gen.co.jp ポリシー ポリシー (Policies)は、後述の Agent Gateway がエージェントと他のサービス間の通信を安全に管理するために用いる、 IAM 許可ポリシー と セマンティック ガバナンス ポリシー の総称です。 IAM 許可ポリシーは IAM ベースの静的な権限管理で、Identity-Aware Proxy(以下、IAP)を用いた認証と認可を実現します。Agent Registry の各サービスに「読み取り専用」、「破壊的変更の許可」といった条件を指定したポリシーを紐づけることで、エージェントがサービスを介して行える操作を制限します。 セマンティック ガバナンス ポリシーは、エージェントのプロンプトや MCP ツール呼び出しの「内容」を監視・制御するための制約であり、エージェントの振る舞いがユーザーの意図と組織の制約の両方に適合するように制御します。Agent Gateway は実行時に各エージェントのプロンプトとツール呼び出しの内容を分析し、制約に基づいてアクションを決定します。なお、2種類のポリシーのうちセマンティック ガバナンス ポリシーについては、2026年8月現在プレビュー提供となっています。 参考 : ポリシーの概要 参考 : セマンティック ガバナンス ポリシーの概要 参考 : セマンティック ガバナンス ポリシーを構成する 参考 : セマンティック ガバナンス ポリシーを構成する - セマンティック ガバナンスの例 Agent Gateway Agent Gateway はユーザーとエージェント、エージェントとツール、エージェント同士など、すべてのエージェントインタラクションを保護・管理するネットワークコンポーネントです。 Agent Gateway は Client-to-Agent (クライアントからエージェントへの内向き)と Agent-to-Anywhere (エージェントから任意の宛先への外向き)という2つのモードで動作します。 動作モード 説明 Client-to-Agent(内向き) Agent Gateway がエージェントのフロントエンドとして機能し、クライアント(Gemini CLI、Claude Code など)と Google Cloud 上で実行されているエージェント(およびツール)間の通信を保護する Agent-to-Anywhere(外向き) Google Cloud 上で実行されているエージェントと、任意の場所で実行されているエージェント、ツール、API などの外部サービスとの間の双方向の通信を保護する この2種類の通信に対して、先述の IAM 許可ポリシー、セマンティック ガバナンス ポリシーを適用することで、一元的なアクセス制御を実現します。また、Agent Gateway を経由するプロンプトとレスポンスは Model Armor で検査・サニタイズでき、プロンプトインジェクションや機密情報の漏洩といったリスクを一元的に低減できます。 Agent Gateway はネットワークレイヤですべてのエージェントインタラクションのテレメトリを生成し、Cloud Logging や Cloud Trace に連携できるため、後述のオブザーバビリティ機能と組み合わせてセキュリティ調査やパフォーマンス分析を行えます。 Agent Gateway の動作モードのイメージ Agent Gateway を利用するには、対象のエージェントと、その接続先となるエンドポイントや MCP サーバーを、あらかじめ Agent Registry に登録しておく必要があります。そのうえで、Agent Runtime へのエージェントのデプロイ時、または Gemini Enterprise アプリの管理設定で使用するゲートウェイを指定すると、以降のトラフィックは自動的に Agent Gateway 経由でルーティングされます。一方、それ以外のデプロイ先(Cloud Run や GKE など)からのトラフィックを Agent Gateway 経由とする手順は2026年7月現在の公式ドキュメントには明示されていません。そのため現時点では、Agent Runtime と Gemini Enterprise が主な利用対象となります。 参考 : Agent Gateway の概要 参考 : ゲートウェイで Model Armor を構成する Agent Gateway については、以下の記事で詳細に解説されています。 blog.g-gen.co.jp セキュリティ Agent Platform の セキュリティ タブでは、デプロイ済みの AI エージェントを継続的に監視し、セキュリティ検出結果(findings)を確認できます。 Security Command Center(Premium / Enterprise)との連携により、AI Protection、エージェントの脆弱性評価、センシティブデータの検出、AI Discovery、攻撃パスシミュレーションといったセキュリティ監視・分析を行うことができます。 セキュリティタブには、Security Command Center の検出結果を集約した総合リスク指標、コンプライアンスステータス、アクティブな脅威数が表示されます。 また、重大度別の AI リスク(脆弱性、構成ミス、有害な組み合わせ)、AI 脅威(異常な IAM 権限付与、マルウェア、ラテラルムーブメント)、過剰な権限を持つエージェント、業界セキュリティ基準への適合状況、コンテンツ違反などをウィジェット形式で確認できます。 参考 : セキュリティに関する検出結果を表示する Agents - Optimize 概要 このカテゴリでは、デプロイ済みエージェントの品質と動作を継続的に改善するためのコンポーネント群を扱います。実行のパフォーマンスや健全性、トポロジを可視化する オブザーバビリティ 、エージェントのパフォーマンス・安全性・品質を測定する エージェントの評価 、Few-shot サンプルを保存・動的に取得して回答品質を改善する Example Store により、本番運用後のモニタリングと改善サイクルを担います。 オブザーバビリティ オブザーバビリティ (Observability)では、デプロイされたエージェントと MCP サーバーのパフォーマンス、動作、健全性を包括的に監視・分析できます。 主要な指標のモニタリング、実行パスのトレース、マルチエージェントシステムのトポロジの可視化によって、問題を診断し、リソース消費を最適化し、エージェントの信頼性を向上させることができます。 これらの分析を行うためには、エージェントから OpenTelemetry 形式でテレメトリーデータを Google Cloud Observability(Cloud Monitoring / Cloud Logging / Cloud Trace)に送信するように構成する必要があります。送信されたテレメトリーデータは、Agent Registry のコンソール上で以下の3種類のシグナルとして確認することができます。 シグナル 主な内容 メトリクス トークン使用量、レイテンシ(p50 / p95 / p99)、エラー率、セッション統計、ハルシネーション率、CPU・メモリ使用量 トレース 実行パス(スパン)、入出力の有向非巡回グラフ、エージェント間呼び出し ログ プロンプト・レスポンス、エラー、フィルタ可能なエージェント生ログ 参考 : オブザーバビリティの概要 エージェントの評価 エージェントの評価 (Agent Evaluation)は、エージェントのパフォーマンス、安全性、品質を測定して改善するための評価機能です。 エージェントの評価では以下のような機能が利用できます。既存のテストデータがなくても初期評価スイートを構築できる点が特徴です。 機能 説明 シナリオ生成 / ユーザーシミュレーション エージェントのシステム指示とツール定義に基づいて多様なマルチターンの合成テストシナリオを自動生成する 環境シミュレーション ツール呼び出しをインターセプトしてカスタム動作やシミュレートされたエラーを挿入する マルチターン評価 会話履歴全体を自動的に評価する プロンプト最適化 洗練されたシステム指示をプログラムで生成・検証する 評価プロセスは「評価ケース定義 → 評価ケース実行 → トレース生成 → 指標の計算 → 指標の分析 → エージェント最適化」の6つのステップで構成され、ローカル開発でのイテレーションと、デプロイ済みエージェントに対する評価の両シナリオで利用できます。 また、評価指標に対してしきい値を設定し、超過時に自動通知を送る 品質アラート (Quality Alerts)も提供されています。タスクの成功スコアやツール使用品質といった指標を Cloud Monitoring 経由で監視し、しきい値超過時に Slack、メール、Cloud Pub/Sub への通知を発信することで、基盤モデルが変わっていなくても、ユーザーの行動やデータパターンの変化に起因するエージェントの品質低下を早期に検知できます。 参考 : エージェントの評価 参考 : 品質アラートを構成する Example Store(プレビュー) Example Store は、エージェントが LLM に渡すプロンプトに含めるための Few-shot サンプル(少数ショットの例)を保存・動的に取得できるマネージドサービスです。2026年8月現在はプレビュー提供となっています。 LLM に期待する回答パターンを提示することで、類似のクエリに対する応答の品質、精度、整合性を向上させることができます。プロンプトに直接サンプルを書き込む場合と異なり、プロンプトの内容に応じてストアから関連性の高いサンプルだけが動的に取り出されるため、プロンプトサイズや複雑性を抑えながらより多くのユースケースをカバーできます。 ADK で開発したエージェントの場合は、事前に Example Store インスタンスを指定しておくことで、プロンプトの内容に応じてサンプルが自動的に取得され LLM へのリクエストに含められます。それ以外のフレームワークで開発したエージェントの場合は、API を介して手動でサンプルを検索・取得します。 参考 : Example Store の概要 Models 概要 Models は、Agent Platform で生成 AI / ML モデルを取り扱うための基盤コンポーネント群です。これまで Vertex AI として提供されてきた生成 AI / 機械学習関連のサービスが、当カテゴリ配下に集約されています。具体的には、Google・パートナー・OSS のモデルを横断的に発見できる Model Garden 、5種類の課金・提供方式を体系化した 使用オプション 、 Gemini のチューニング 、 Gen AI Evaluation Service による評価 、ML モデルのライフサイクル管理を担う Model Registry 、 オンライン推論用のエンドポイント 、 大規模データ向けのバッチ推論 といった、モデルの選定からサービングまでを担う機能を扱います。 Model Garden Model Garden は、Google、パートナー、OSS が提供するモデルやアセットを探索、テスト、カスタマイズ、デプロイするための AI / ML モデルライブラリです。 2026年7月現在、Model Garden で扱えるモデルのカテゴリごとの詳細と、具体的なモデルの例を以下に示します。 カテゴリ 説明 モデルの例 基盤モデル 事前学習済みのマルチタスク大規模モデル。後述のモデルのチューニング機能や、システム指示・RAG などによるカスタマイズで特定タスクに適応できる Gemini、Anthropic Claude、Mistral、Grok ファインチューニング可能なモデル ノートブックやパイプラインで自前でファインチューニングできるモデル Gemma、Llama、DeepSeek、Qwen タスク固有のソリューション 画像・動画・音楽・音声・翻訳など特定タスク向けの構築済みモデル。多くは独自データでカスタマイズ可能 Imagen、Veo、Lyria、Chirp 後述のモデルのチューニング機能、Gen AI Evaluation Service、エンドポイントといった Agent Platform の他機能と統合されており、モデルの選定から本番サービングまでを一貫したワークフローで扱えます。 また、組織のポリシー( vertexai.allowedModels 制約)を使用すると、組織・フォルダ・プロジェクト単位で特定のモデルへのアクセスを制御でき、組織で承認したモデルだけを使用させる運用ができます。 参考 : Model Garden の概要 参考 : Model Garden モデルへのアクセスを制御する 使用オプション Agent Platform では、Gemini などの生成 AI モデルを利用する際の課金・提供方式として5種類の 使用オプション が体系化されています。デフォルトでは Standard PayGo が適用されます。各オプションは課金方式、スループット保証の有無、リクエスト処理の優先度といった観点で性質が異なり、ワークロードの特性に応じて使い分けます。 使用オプション 特徴 主な用途 プロビジョンドスループット 1週間〜1年のコミットで容量とスループットを予約。固定料金制で超過料金なし SLA 必須の定常ワークロード チャットボット・エージェントなど一貫したユーザー体験が求められる本番用途 Priority PayGo Standard PayGo より優先的に処理される従量課金 Standard 以上の信頼性が求められるケース プロビジョンドスループット容量超過分のスピルオーバー先としても使用可能 Standard PayGo 前払い不要の従量課金(デフォルト) トラフィックが変動する日常的な用途 Flex PayGo(プレビュー) Standard PayGo より処理の優先度が低く、割安な従量課金 コスト優先でレイテンシが許容できるユースケース バッチ推論 非同期・高スループットの大量処理 結果が比較的長期で必要な大規模ジョブ プロビジョンドスループットは Gemini や Veo などの Google 製モデルに加えて、一部のパートナーモデル・OSS モデルにも対応しています(対応モデルの詳細は参考ドキュメント参照)。本番ワークロードでは、プロビジョンドスループットでベースラインの容量を確保し、超過分は Priority PayGo で処理する組み合わせも選択できます。 参考 : 使用オプション 参考 : プロビジョンド スループットの概要 参考 : プロビジョンド スループットでサポートされているモデル モデルのチューニング モデルのチューニング 機能は、Gemini モデルをラベル付きデータセットで特定タスクに適応させる、Agent Platform のマネージドチューニング機能です。プロンプト設計だけでは難しい複雑なタスクや、特定のドメイン知識をモデルに獲得させたい場合に利用します。 モデルのチューニングでは、以下の2種類の手法が提供されます。 手法 説明 教師ありファインチューニング ラベル付きの入出力ペアでモデルに目的の動作を模倣させる、最も標準的な手法 プリファレンスチューニング 人間によるフィードバックデータを使って、教師ありファインチューニングだけでは定義しにくい主観的な好みを学習させる手法 運用上のオプション機能として、チューニング途中の状態を保存して複数の状態を比較・選択できる チューニングチェックポイント と、既存のチューニング済みモデルやチェックポイントを起点に追加データで学習を続けられる 継続的チューニング が提供されます。 2026年7月現在、対象モデルは Gemini 2.5 Pro、Gemini 2.5 Flash、Gemini 2.5 Flash-Lite で、チューニング用データセットはテキスト・画像・動画・音声・ドキュメントなど複数モダリティに対応しています。 参考 : チューニング Gen AI Evaluation Service Gen AI Evaluation Service では、生成 AI モデルを客観的・データドリブンに評価するツールが提供されます。モデルの移行やプロンプト最適化などの開発タスクを支援します。 モデルの評価方法として、以下の4つが提供されています。推奨とされている 適応型ルーブリック はソフトウェア開発の単体テストに似た位置づけで、プロンプトごとに pass/fail を判定することで、さまざまなタスクでモデル品質を客観的に評価できます。 評価方法 説明 適応型ルーブリック(推奨) 評価用データセットの各プロンプトごとに評価項目を動的に生成して採点する方式 静的ルーブリック 評価用データセットの全プロンプトに固定の評価基準を適用する方式 計算ベース指標 ROUGE や BLEU などの指標を用いて、参照テキストとの一致度を数値で算出する方式 カスタム関数 Python で独自の評価ロジックを実装する方式 生成 AI モデルだけでなく、エージェントの評価や予測 AI モデルの評価にも対応しており、Google / サードパーティモデルの直接比較、ファインチューニング品質評価、プロンプト最適化、モデルバージョン間の比較といった用途で使われます。 Gen AI Evaluation Service の詳細については、以下の記事もご一読ください。 blog.g-gen.co.jp 参考 : Gen AI Evaluation Service の概要 Model Registry Model Registry は、ML モデルの整理・バージョン管理・本番デプロイを一元化する中央リポジトリです。 モデルのバージョン管理、後述の エンドポイント へのデプロイや バッチ推論 の実行、モデルの性能評価・パフォーマンス指標の閲覧といった機能を備えます。 対応するモデルタイプは、後述の トレーニング 機能で作成したカスタム学習モデルや AutoML モデル、BigQuery ML モデルです。これらに加えて、外部で学習したモデルについてもアーティファクトを Cloud Storage に配置することでインポートして登録できます(フレームワーク・形式の要件あり)。 参考 : Model Registry の概要 参考 : Model Registry へのモデルのインポート エンドポイント エンドポイント (Endpoint)は、学習済みモデルを用いてオンライン推論を実行するための物理リソースです。モデルをエンドポイントにデプロイすると、推論を実行するマネージド推論ノードがプロビジョニングされ、推論リクエスト用のサービス URL が提供されます。 1つのエンドポイントには複数のモデルやモデルバージョンをデプロイでき、各モデルへのトラフィック比率を指定する トラフィック分割 によって、新旧モデルを段階的に置き換えるローリングデプロイができます。 推論ノードは同時リクエスト数に応じて 自動スケーリング するため、負荷に応じたコスト効率と応答性能を両立できます。 パブリックエンドポイント(共有・専用)、Private Service Connect エンドポイント、プライベートサービスアクセスエンドポイントの3種類があり、ネットワーク要件に合わせて選択できます。 参考 : エンドポイントにモデルをデプロイする バッチ推論 バッチ推論 は、大規模データ処理向けの非同期・高スループット・低コストの推論サービスです。オンライン推論と異なりエンドポイントへのモデルデプロイが不要で、入力データをまとめて投入するだけで実行できます。 入力ソースは Cloud Storage と BigQuery に対応し、リアルタイム応答ではなく非同期処理として動作します。 バッチ推論では、前述の Model Registry に登録したカスタム学習モデル、AutoML モデル、BigQuery ML モデル、インポートモデルに加えて、各種 Gemini モデルが使用できます(対応モデルの詳細は参考ドキュメント参照)。 コンテンツ生成、データ分類・アノテーション、要約・抽出・翻訳といったオフライン分析など、緊急性の低い大規模タスクに最適な選択肢です。 参考 : Gemini を使用したバッチ推論 参考 : カスタム トレーニング済みモデルからバッチ推論を取得する Models - その他のサービス 概要 Models に含まれるその他のサービスとして、生成 AI 系サービスの登場以前から Vertex AI として提供されてきた機械学習サービスが統合されています。 データセット データセット (Datasets、別名 : マネージドデータセット)は、後述の AutoML やカスタムトレーニングで使うソースデータを Agent Platform 上で一元管理する機能です。AutoML モデルの学習では使用が必須となっています。 データの実体は Cloud Storage に保管されます。データセットのメタデータは Knowledge Catalog に統合されており、プロジェクトやリージョンを横断して検索できます。 また、コンソール上でアノテーションセットを作成し、画像データへのラベル付けを行うこともできます。 参考 : Gemini Enterprise Agent Platform でのマネージド データセットの作成の概要 Feature Store Feature Store は、機械学習で使う特徴量(Feature)を一元管理し、トレーニングと推論の両方に提供するための特徴管理サービスです。 ユーザー行動ログなどから集計する特徴量(例 : ユーザーの過去30日の購入回数)は計算コストが高く、推論リクエストごとに作るとレイテンシが破綻します。Feature Store は事前計算した特徴量を保管し、推論時に即座に取り出せるようにする基盤です。トレーニングと推論で同じ特徴量定義を共有できるため、両者で特徴量の中身が食い違う training-serving skew も防げます。 データソースは BigQuery で、Feature Store 自体は BigQuery テーブルを Feature View として登録するだけで、データを物理コピーせずに参照できます。オンライン推論向けには Bigtable をバックエンドとしたオンラインサービングが用意されています。 Knowledge Catalog と連携して特徴メタデータを追跡できるため、トレーニングや再トレーニングでの再利用が容易です。また 特徴モニタリング 機能では、登録済みの特徴データを定期ジョブで監視し、特徴ドリフト(Feature drift)の検出ができます。 参考 : Gemini Enterprise Agent Platform での特徴管理の概要 参考 : Agent Platform Feature Store について トレーニング Agent Platform は、独自の機械学習モデルを学習させる機能群を提供します。学習結果はモデルアーティファクトとして Cloud Storage に保存され、前述の Model Registry に登録できます。 目的とコード制御の必要度に応じて以下の3つの方式から選択できます。 方式 概要 AutoML トレーニング用のコードを書かずに、データ準備・モデル選択・ハイパーパラメータ調整・デプロイまでを全て自動化する方式。表形式(分類・回帰・予測)と画像(分類・物体検出)データに対応 カスタムトレーニング ユーザー自身が書いたトレーニング用のコードを Agent Platform のマネージドインフラ上で実行する方式。任意の ML フレームワークを使用できる Ray on Agent Platform OSS の分散処理フレームワーク Ray を Agent Platform 上でマネージド提供する方式。分散トレーニングや並列処理が必要な ML ワークフローに向く カスタムトレーニングでは、トレーニング用のコードをコンテナイメージとしてパッケージ化して実行します。TensorFlow / PyTorch / scikit-learn など任意の ML フレームワークを使用でき、標準的なフレームワーク向けには事前構築済みコンテナが提供されているほか、特殊な依存関係がある場合は独自のカスタムコンテナを使用することもできます。実行環境の特性に応じて、以下の2つの方式から選択できます。 実行方式 概要 サーバーレストレーニング コードをカスタムジョブとして投入するサーバーレス実行方式。インフラはオンデマンドで起動・解放される トレーニングクラスタ A100 / H100 などの高性能アクセラレータを専用クラスタとして予約してカスタムジョブを実行する方式 Ray on Agent Platform は既存の OSS Ray コードを最小限の変更でそのまま動かせる点が特徴で、BigQuery や前述のエンドポイントといった Google Cloud サービスとシームレスに連携します。 データ処理・評価・デプロイなど複数ステップの本格的な MLOps ワークフローが必要な場合は、後述の Pipelines を使用するのが推奨されます。 参考 : 独自のモデルをトレーニングして使用する 参考 : トレーニング方法を選択する 参考 : Agent Platform での Ray の概要 Experiments Experiments は、機械学習モデル開発のプロセスを追跡・比較・分析するための実験管理ツールです。モデル選択やトレーニングの最適化に役立ちます。 前処理・トレーニングといった手順、入力パラメータやアルゴリズム、出力されたモデルやチェックポイント、評価指標などをまとめて記録できます。複数のモデルや構成をテスト実行(Run)単位でグループ化して比較でき、ハイパーパラメータやアーキテクチャの違いによる性能差を検証できます。 後述の ML メタデータと統合してアーティファクトのリネージを追跡できるほか、TensorBoard との統合により学習過程の時系列指標を可視化できます。 後述の Pipelines と組み合わせれば、パイプライン実行を Experiments の Run として記録でき、構成の異なるパイプラインを Run 単位で横断比較する用途にも使えます。 参考 : Gemini Enterprise Agent Platform Experiments の概要 ML メタデータ ML メタデータ (ML Metadata)は、機械学習システムが生成するメタデータとアーティファクトを記録・管理するサービスです。 データセットや学習済みモデルといったアーティファクト、トレーニングや評価といった実行、それらを束ねるコンテキストをノードとし、ノード間の入出力関係をエッジとして表現するメタデータグラフを保持します。各ノードには、モデルの精度や再現率などのメトリクスやプロパティを Key-Value で付加できます。 「データセット → モデル → 予測結果」のような依存関係をリネージとして追跡できるため、本番 ML システムの実行分析、ハイパーパラメータの効果比較、ワークフロー再実行時の同一条件での再現、監査・ガバナンス対応といった用途で利用されます。 前述の Experiments や後述の Pipelines と密接に連携する基盤となるコンポーネントです。 参考 : Gemini Enterprise Agent Platform ML メタデータの概要 Pipelines Pipelines は、ML ワークフローをサーバーレス実行基盤でオーケストレーションするサービスです。 ML パイプラインは MLOps ワークフローを移植可能・拡張可能な形で記述したもので、複数のパイプラインタスクを有向非巡回グラフ(DAG)の形式で結び、依存関係に従って実行します。 パイプラインの記述には Kubeflow Pipelines または TensorFlow Extended(TFX)の SDK を利用でき、定義 → コンパイル(YAML 生成) → 実行 → モニタリングというライフサイクルで運用します。 前述の ML メタデータと連携してアーティファクトのリネージを追跡できるため、再現性とガバナンスを保ちながらデータ前処理・モデルトレーニング・デプロイを統合的に自動化できます。 継続的な再トレーニングや本番 MLOps の自動化基盤として中核となるコンポーネントです。 参考 : Gemini Enterprise Agent Platform Pipelines の概要 Pipelines の詳細については、以下の記事もご一読ください。 blog.g-gen.co.jp モデルモニタリング モデルモニタリング (Model Monitoring)は、本番環境にデプロイされた機械学習モデルの品質劣化を検出・追跡するためのモニタリングサービスです。顧客 LTV 予測のように入力データの分布が時間とともに変わるシナリオで特に有効です。 入力特徴量や推論結果の分布のドリフト、特徴アトリビューション(各特徴量のモデルに対する寄与度)の変化といった観点でモデルの状態を継続的に監視し、これらの指標がしきい値を超えるとアラートを発することができます。 ベースラインとターゲットのデータセットの分布を重ね合わせて可視化できるため、差異を視覚的に把握して再評価や再トレーニングの要否判断に役立てられます。 参考 : モデル モニタリングの概要 Notebooks 概要 Notebooks は、生成 AI ワークフローやデータサイエンス・ML プロジェクトの構築・テスト・開発に使うマネージドノートブック環境の総称で、目的に応じて Colab Enterprise と Agent Platform Workbench の2つのソリューションから選択できます。 参考 : ノートブック 参考 : ノートブック ソリューションを選択する Colab Enterprise および Agent Platform Workbench の詳細については、以下の記事もご一読ください。 blog.g-gen.co.jp Colab Enterprise Colab Enterprise は、チーム利用に最適化されたマネージド Jupyter ノートブック環境で、Google グループや Google Workspace ドメイン単位でのノートブック共有と、複数ユーザーでのリアルタイム共同編集に強みがあります。 Gemini によるコード補完・コード生成に加えて、コードセルの説明、エラーの説明と修正、ノートブック内容についてのチャットといった AI アシスタンス機能が利用でき、SQL セルや可視化セルなどの機能と組み合わせて、協業とデータ分析を重視するシナリオに適しています。なお、2026年8月現在、これらのうちコードセルの説明、エラーの説明と修正、ノートブック内容についてのチャットの3機能はプレビュー提供となっています。 参考 : Colab Enterprise の概要 参考 : Gemini in Colab Enterprise Agent Platform Workbench Agent Platform Workbench は、VM インスタンス上で動作する JupyterLab 環境で、TensorFlow や PyTorch といったディープラーニング用フレームワークのプリインストールと GPU 構成への対応により、機械学習向けのノートブック環境をすぐに整えられます。 conda 環境によるカーネル拡張、ユースケースに合わせた独自のコンテナでのインスタンス作成など、開発環境を細かく作り込みたいケースに向いており、高いカスタマイズ性を備えています。また、Workforce Identity 連携によるサードパーティ ID プロバイダ認証にも対応しています。 参考 : Agent Platform Workbench の概要 佐々木 駿太 (記事一覧) クラウドソリューション部 クラウドエンジニアリング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 の佐々木です。当記事では、Agent Development Kit(ADK)で開発した AI エージェントで Agent Runtime(旧称 : Vertex AI Agent Engine)の Memory Bank 機能を使用することで、セッション間で情報を保持できるエージェントを構築していきます。 構成 当記事で使用するもの Agent Development Kit(ADK) Agent Runtime Memory Bank Cloud Run Memory Bank を使用するエージェントの開発 エージェントの概要 ディレクトリ構成 プロジェクトの準備 エージェントのソースコード(agent.py) Agent Runtime にエージェントをデプロイ Google Cloud の認証と設定 .env ファイルの作成 Agent Runtime へのデプロイ 動作確認(ADK Web) フロントエンドの構築 フロントエンドの概要 チャットボットの開発 ディレクトリ構成 プロジェクトの準備 app.py Dockerfile OAuth 同意画面の構成 Cloud Run へのデプロイ サービスアカウントの作成 デプロイ 動作確認 Memory Bank のカスタマイズ カスタマイズの概要 カスタマイズ用スクリプト(update.py)の作成 カスタマイズの適用 カスタマイズ後の動作確認 構成 当記事では、 Agent Development Kit (ADK)で定義した AI エージェントを Agent Runtime にデプロイし、また、フロントエンドとしてエージェントとやり取りを行うチャットボットを Cloud Run に構築していきます。 エージェントは、Agent Platform の Memory Bank 機能を使用するように構築します。これにより、一度チャットボットとの会話を終了した後でも、前の会話内容の一部を長期記憶として Memory Bank に保存しておくことができます。 また、Cloud Run では Identity-Aware Proxy (IAP)を有効化することで、Google アカウントで認証されたユーザーのみがチャットボットを利用できるようにします。その上で、IAP が付与する認証済みユーザーのメールアドレスを user_id として Memory Bank に送信することで、ユーザーごとの記憶を Memory Bank に蓄積できるようにします。 Memory Bank 機能を使用する Agent Runtime とチャットボットの構成 当記事で使用するもの Agent Development Kit(ADK) Agent Development Kit (ADK)は、Google Cloud が提供する AI エージェント構築のためのオープンソース フレームワークであり、単純なタスクをこなすエージェントから複数のエージェントが協働する複雑なワークフローまで容易に実装できます。 ADK には、Memory Bank と連携するための PreloadMemoryTool や、セッションイベントを Memory Bank に送信するための add_events_to_memory() といったユーティリティが標準で組み込まれており、長期記憶を扱うエージェントを少ないコードで実装できます。 参考 : Agent Development Kit 参考 : Agent Development Kit の概要 Agent Runtime Agent Runtime は Gemini Enterprise Agent Platform (旧称 : Vertex AI、以下 Agent Platform と記載)で提供されるサービスの1つであり、AI エージェントの実行基盤を提供するフルマネージドサービスです。 Agent Runtime では、エージェントとのマルチターン会話を実現するための組み込みの セッション機能 を利用することができるほか、Memory Bank のように、エージェントの機能拡張に必要な様々な機能が提供されています。 Agent Runtime の詳細については、以下の記事をご一読ください。 blog.g-gen.co.jp Memory Bank Memory Bank は Agent Platform が提供する 長期記憶 を実現するための機能です。Agent Runtime のセッション機能が一連の会話の中での短期的な記憶を扱うのに対し、Memory Bank はセッションをまたいで利用できる記憶を蓄積します。 Memory Bank は内部的に LLM を用いて、セッションのイベント(会話履歴)からユーザーの嗜好や事実を抽出・要約し、エージェントが認識しているユーザー ID( user_id )単位で保存します。これにより、エージェントとの会話(セッション)を一度中断しても、後の会話でユーザーごとにパーソナライズされた応答を返すことができるエージェントを構築できます。 エージェント側から以下の2つの操作を行うことで Memory Bank を利用できます。 記憶の生成・保存 : セッション中のイベントを Memory Bank に送信し、長期記憶として抽出・保存させる 記憶の参照 : 新しいセッションの開始時や会話中に、Memory Bank から関連する記憶を取得し、プロンプトに含めて LLM に渡す ADK ではこれらの操作を簡単に行うための add_events_to_memory() や PreloadMemoryTool といったユーティリティが提供されており、エージェントのコールバックやツールとして組み込むだけで Memory Bank を利用できます。 参考 : Agent Platform メモリバンク Cloud Run Cloud Run は Google Cloud のマネージドなコンテナ実行環境でアプリケーションを実行できる、サーバーレス コンテナコンピューティング サービスです。 当記事ではユーザーがエージェントとやり取りするためのフロントエンドとして使用します。 Cloud Run の詳細については、以下の記事をご一読ください。 blog.g-gen.co.jp Memory Bank を使用するエージェントの開発 エージェントの概要 当記事では、コーヒーに関する質問に回答する「コーヒーエージェント」を ADK で構築していきます。エージェントを Memory Bank と連携できるように実装することで、ユーザーごとの嗜好や過去のやり取りを長期記憶として蓄積できるようにします。 Agent Runtime を使用してエージェントを構築する ディレクトリ構成 最終的なディレクトリ構成は以下の通りになります。 coffee_agent ディレクトリで AI エージェントを実装していきます。 . ├── coffee_agent │ ├── agent.py │ ├── .env │ └── __init__.py ├── pyproject.toml # 自動で作成 └── uv.lock # 自動で作成 ADK ではエージェントのパッケージ(ここでは coffee_agent ディレクトリ)内に agent.py を配置し、そこにツール関数とエージェント定義を実装します。 プロジェクトの準備 エージェント開発用のディレクトリでプロジェクトを初期化します。 # uv プロジェクト初期化 $ uv init --no-readme # パッケージの追加 $ uv add " google-adk>=1.29.0 " 次に、エージェント用のパッケージディレクトリ( coffee_agent )を作成し、ADK がパッケージとして認識できるように __init__.py を配置します。 __init__.py では agent モジュールをインポートしておくことで、 adk コマンドからエージェントを参照できるようになります。 # エージェントのパッケージディレクトリを作成 $ mkdir coffee_agent # __init__.py を作成 $ cat <<EOF > coffee_agent/__init__.py from . import agent EOF エージェントのソースコード(agent.py) 当記事では、Google 検索でコーヒーに関する情報を調べるサブエージェントをツールとして内包するエージェントを構築し、Memory Bank との連携機能を組み込みます。 Memory Bank と連携するために、以下の2つの仕組みを利用しています。 PreloadMemoryTool : ADK が標準提供するツールで、エージェントの実行開始時に Memory Bank から user_id に紐付く記憶を取得し、プロンプトに自動で挿入します。エージェントは過去の会話の文脈を踏まえた応答が可能になります。 after_agent_callback : エージェントの応答が完了した直後に呼び出されるコールバックです。 callback_context.add_events_to_memory() を通じて、直近のセッションイベントを Memory Bank に送信し、記憶として抽出・保存させています。 generate_memories_callback では callback_context.session.events[-5:-1] のように直近のイベントをスライスして送信しています。これにより、応答完了時の最終イベントを除外しつつ、ユーザーの発話とエージェントの応答を含む直近のやり取りのみを Memory Bank に送信します。 from google.adk.agents import Agent from google.adk.tools import google_search from google.adk.tools.agent_tool import AgentTool from google.adk.agents.callback_context import CallbackContext from google.adk.tools.preload_memory_tool import PreloadMemoryTool # 記憶を Memory Bank に保存するコールバック関数 async def generate_memories_callback (callback_context: CallbackContext): # イベント単位で Memory Bank に送信する await callback_context.add_events_to_memory( events=callback_context.session.events[- 5 :- 1 ]) return None # Web 検索用エージェント search_agent = Agent( name= "search_agent" , model= "gemini-2.5-flash" , description= "Google検索でコーヒーに関する情報を調べるエージェント" , instruction= "ユーザーの質問に対してGoogle検索を使って情報を収集し、日本語で回答してください。" , tools=[google_search] ) # ルートエージェント root_agent = Agent( name= "coffee_agent" , model= "gemini-2.5-flash" , description= "コーヒーに関する情報を収集するエージェント" , instruction= """あなたはコーヒーの専門家アシスタントです。 ユーザーからの質問に対して、search_agentを活用しながらコーヒーに関する正確で有益な情報を提供してください。 対応できるトピックの例: - コーヒー豆の産地・品種・特徴 - 抽出方法(ドリップ、エスプレッソ、フレンチプレスなど) - 焙煎度合いと味わいの違い - カフェやコーヒーショップの情報 - コーヒーの健康効果や歴史 - ラテアートやバリスタの技術 回答は日本語で、わかりやすく丁寧に行ってください。""" , tools=[ AgentTool(agent=search_agent), PreloadMemoryTool() ], after_agent_callback=generate_memories_callback ) 参考 : Agent Development Kit によるクイックスタート Agent Runtime にエージェントをデプロイ Google Cloud の認証と設定 デプロイの前に、Google Cloud CLI での認証を行っておきます。 # プロジェクト ID を環境変数にセット $ export PROJECT_ID = < プロジェクトID > # 認証 $ gcloud auth login $ gcloud auth application-default login # プロジェクトの設定 $ gcloud config set project $PROJECT_ID .env ファイルの作成 エージェントの実行時に Gemini Enterprise Agent Platform (旧称 : Vertex AI、以下 Agent Platform と記載)を利用するための環境変数を、 coffee_agent ディレクトリ配下の .env ファイルに設定します。ADK は実行時にこのファイルを自動で読み込みます。 # coffee_agent/.env を作成 $ cat <<EOF > coffee_agent/.env GOOGLE_GENAI_USE_VERTEXAI=1 GOOGLE_CLOUD_PROJECT= $PROJECT_ID GOOGLE_CLOUD_LOCATION=asia-northeast1 EOF GOOGLE_GENAI_USE_VERTEXAI : 1 を指定することで、Gemini API ではなく Agent Platform 経由で Gemini モデルを利用します GOOGLE_CLOUD_PROJECT : エージェントをデプロイする Google Cloud プロジェクト ID GOOGLE_CLOUD_LOCATION : Agent Runtime およびモデルを利用するリージョン Agent Runtime へのデプロイ adk deploy コマンドを使用して、Agent Runtime にエージェントをデプロイします。 # Agent Runtime にエージェントをデプロイ $ uv run adk deploy agent_engine \ --project = $PROJECT_ID \ --region = asia-northeast1 \ --display_name =" Coffee Agent " \ coffee_agent デプロイが成功すると、以下のように Agent Runtime のリソース名が出力されます。 ✅ Created agent engine: projects/ < プロジェクト番号 > /locations/asia-northeast1/reasoningEngines/ < エージェント固有の数字 > このリソース名は、後続の動作確認やチャットボットのデプロイ時に使用するため、シェル変数にセットしておきます。 # 環境変数にリソース名をセット $ export RESOURCE_NAME =projects/ < プロジェクト番号 > /locations/asia-northeast1/reasoningEngines/ < エージェント固有の数字 > なお、すでにデプロイ済みの Agent Runtime を更新する場合は、 --agent_engine_id オプションでリソース名を指定して同じ adk deploy コマンドを実行します。 # 既存の Agent Runtime を更新する場合 $ uv run adk deploy agent_engine \ --project = $PROJECT_ID \ --region = asia-northeast1 \ --agent_engine_id = $RESOURCE_NAME \ --display_name =" Coffee Agent " \ coffee_agent 参考 : ADK CLI documentation - deploy 動作確認(ADK Web) ローカルで ADK Web UI を起動し、Memory Bank と連携した状態でエージェントの動作を確認します。 --memory_service_uri オプションに Agent Runtime のリソース名を指定することで、ローカルの Web UI から Agent Runtime の Memory Bank をエージェントの長期記憶ストアとして利用できます(エージェントはローカルで実行し、Memory Bank 用途でのみ Agent Runtime にアクセスしている状態)。 # Memory Bank を指定して ADK Web UI を起動 $ uv run adk web --memory_service_uri = agentengine:// $RESOURCE_NAME ブラウザで http://localhost:8000 を開き、チャットでエージェントと会話します。 adk web から起動した場合、Memory Bank には user という固定のユーザー ID で記憶が保存されていきます。 まず最初のセッションでは、コーヒーの好み(例: 「私は酸味の強いコーヒーが好きです。おすすめのコーヒー豆はありますか」)をエージェントに伝えます。 最初のセッションでエージェントに好みを伝える Agent Runtime のコンソールから Memory Bank の中身を確認することができます。ADK Web のユーザー( user )に関する記憶として、「私は酸味の強いコーヒーが好きです。」という情報が記録されています。 Memory Bank に好みに関する情報が記録されている その後、ADK Web UI 上で新しいセッションを開始し、「私の好みに合う抽出方法を教えて」などと質問することで、Memory Bank に保存されている個人的な好みに関する情報を踏まえた応答が返ってくることを確認できます。 最初のセッションで伝えた好みに関する情報が新しいセッションに引き継がれている 参考 : ADK CLI documentation - web フロントエンドの構築 フロントエンドの概要 機械学習モデルのデモ用 Web UI を容易に作成できる Gradio という Python ライブラリを使用してチャットボットを実装します。 チャットボット Cloud Run にデプロイし、Web サービスとして公開できるようにします。Cloud Run では Identity-Aware Proxy(IAP)を有効化し、Google アカウントで認証されたユーザーのみがアクセスできるようにします。 IAP による認証つきのチャットボットを構築する 参考 : Gradio チャットボットの開発 ディレクトリ構成 フロントエンドはエージェントとは別のディレクトリで構築します。最終的なディレクトリ構成は以下の通りになります。 app.py にチャットボットを実装していきます。 . ├── app.py ├── Dockerfile ├── pyproject.toml # 自動で作成 └── uv.lock # 自動で作成 プロジェクトの準備 エージェントとは別のディレクトリで uv プロジェクトを初期化します。 # uv プロジェクト初期化 $ uv init --no-readme # パッケージの追加 $ uv add " google-cloud-aiplatform[agent-engines]>=1.142.0 " " gradio>=5.29 " app.py app.py では以下の処理を実装しています。 vertexai.init() で Agent Platform に接続し、 agent_engines.get() で Agent Runtime にデプロイしたエージェントを取得 IAP が付与するリクエストヘッダ( x-goog-authenticated-user-email )からユーザーのメールアドレスを取り出し、Agent Runtime のセッションおよび Memory Bank の user_id として使用 Agent Runtime のセッション機能( create_session )を使い、ユーザーごとにマルチターンの会話を管理 agent.stream_query() でエージェントにメッセージを送信し、ストリーミングで応答を受信 gr.Blocks で Gradio のチャット UI を構築 Memory Bank の記憶は user_id ごとに分離して保存されるため、 user_id の決め方がそのままユーザーごとのパーソナライズの単位となります。ここでは IAP が付与する認証済みメールアドレスをそのまま user_id として用いることで、ブラウザやデバイスをまたいでも同一ユーザーであれば一貫した記憶を参照できる構成にしています。 import os import gradio as gr import vertexai from vertexai import agent_engines AGENT_ENGINE_ID = os.environ[ "AGENT_ENGINE_ID" ] # Identity-Aware Proxy (IAP) が認証済みユーザーのメールアドレスを付与するヘッダ IAP_EMAIL_HEADER = "x-goog-authenticated-user-email" def get_agent (): vertexai.init( project=os.environ.get( "GOOGLE_CLOUD_PROJECT" ), location=os.environ.get( "GOOGLE_CLOUD_LOCATION" ), ) return agent_engines.get(AGENT_ENGINE_ID) agent = get_agent() # IAP から渡されるリクエストヘッダを元にユーザーを一意に特定する def get_user_id (request: gr.Request) -> str : # IAP は "accounts.google.com:user@example.com" の形式で付与するため、 # プレフィックスを除去してメールアドレス部分のみを取り出す raw = request.headers.get(IAP_EMAIL_HEADER, "" ) return raw.split( ":" , 1 )[ 1 ] if ":" in raw else raw def chat (message: str , history: list , session_state: dict , request: gr.Request) -> tuple [ str , dict ]: # IAP で認証されたユーザーのメールアドレスをそのまま Agent の user_id として利用する user_id = get_user_id(request) if not user_id: raise gr.Error( "IAPからユーザー情報を取得できませんでした。" ) session_state[ "user_id" ] = user_id session_id = session_state.get( "session_id" ) if not session_id: session = agent.create_session(user_id=user_id) session_id = session[ "id" ] session_state[ "session_id" ] = session_id response_text = "" for event in agent.stream_query( message=message, user_id=user_id, session_id=session_id, ): if event.get( "content" ) and event[ "content" ].get( "parts" ): for part in event[ "content" ][ "parts" ]: if part.get( "text" ): response_text += part[ "text" ] yield response_text, session_state with gr.Blocks( title= "コーヒーエージェント" , fill_height= True , css= """ .title-row { text-align: center; margin-bottom: 0; } .caption-row { text-align: center; margin-top: 0; color: #666; font-size: 0.9em; } .input-row { position: sticky; bottom: 0; background: var(--background-fill-primary); padding: 10px 0; } """ , ) as demo: gr.Markdown( "<h1 class='title-row'>☕ コーヒーエージェント</h1>" "<p class='caption-row'>コーヒーに関するあれこれをお答えします</p>" ) session_state = gr.State(value={}) chatbot = gr.Chatbot( show_label= False , scale= 1 , avatar_images=( None , "https://em-content.zobj.net/source/google/412/hot-beverage_2615.png" ), placeholder= "質問を入力すると、ここに会話が表示されます" , ) with gr.Row(elem_classes= "input-row" ): textbox = gr.Textbox( placeholder= "コーヒーについて質問してください(例: エスプレッソとドリップの違いは?)" , show_label= False , container= False , scale= 7 , ) def respond (message, history, session_state, request: gr.Request): history = history + [ { "role" : "user" , "content" : message}, ] yield history, session_state, gr.update(value= "" , interactive= False ) assistant_text = "" for text, updated_state in chat(message, history, session_state, request): assistant_text = text session_state = updated_state yield ( history + [{ "role" : "assistant" , "content" : assistant_text}], session_state, gr.update(interactive= False ), ) yield ( history + [{ "role" : "assistant" , "content" : assistant_text}], session_state, gr.update(interactive= True ), ) textbox.submit( respond, inputs=[textbox, chatbot, session_state], outputs=[chatbot, session_state, textbox], ) if __name__ == "__main__" : port = int (os.environ.get( "PORT" , 8080 )) demo.launch(server_name= "0.0.0.0" , server_port=port) Dockerfile Cloud Run にデプロイするためのコンテナイメージを定義します。uv の公式イメージからバイナリをコピーし、依存パッケージのインストールとアプリケーションの起動を行います。 FROM python:3.14-slim COPY --from=ghcr.io/astral-sh/uv:latest /uv /uvx /bin/ WORKDIR /app COPY pyproject.toml uv.lock ./ RUN uv sync --frozen --no-dev COPY app.py . EXPOSE 8080 CMD [ " uv ", " run ", " python ", " app.py " ] OAuth 同意画面の構成 Cloud Run で IAP を有効化すると、Cloud Run 上のサービスへのアクセス時に Google アカウントでのログインが求められるようになり、許可されたユーザーのみがチャットボットを利用できます。 プロジェクトで OAuth 同意画面の構成をまだ行っていない場合、以下のドキュメントを参照して実施してください。 参考 : OAuth 同意画面を設定し、スコープを選択する Cloud Run へのデプロイ サービスアカウントの作成 Cloud Run 用のカスタムサービスアカウントを作成し、Agent Runtime へのアクセスに必要な Agent Platform ユーザー ( roles/aiplatform.user )ロールを付与します。 # サービスアカウントの作成 $ gcloud iam service-accounts create coffee-agent-frontend \ --display-name =" Coffee Agent Frontend " # Agent Platform User ロールの付与 $ gcloud projects add-iam-policy-binding $PROJECT_ID \ --member =" serviceAccount:coffee-agent-frontend@ ${PROJECT_ID} .iam.gserviceaccount.com " \ --role =" roles/aiplatform.user " デプロイ gcloud run deploy コマンドで Cloud Run にデプロイします。 --source オプションを指定すると、Cloud Build によるコンテナイメージのビルドとデプロイが自動で行われます。 --no-allow-unauthenticated と --iap を指定することで、IAP で認証されたユーザーのみがアクセスできるようにしています。 --service-account で先ほど作成したカスタムサービスアカウントを指定します。また、 --set-env-vars でデプロイ済みの Agent Runtime のリソース名を環境変数として渡します。 $ gcloud run deploy coffee-agent-frontend \ --source . \ --region asia-northeast1 \ --set-env-vars " GOOGLE_CLOUD_PROJECT= $PROJECT_ID ,GOOGLE_CLOUD_LOCATION=asia-northeast1,AGENT_ENGINE_ID= $RESOURCE_NAME " \ --service-account coffee-agent-frontend@ ${PROJECT_ID} .iam.gserviceaccount.com \ --cpu 1 \ --memory 1Gi \ --no-allow-unauthenticated \ --iap 動作確認 デプロイが完了したら、Cloud Run サービスの URL にブラウザでアクセスします。 # デプロイ後に出力されるサービス URL Service URL: https://lawapi-frontend- < プロジェクト番号 > .asia-northeast1.run.app IAP が有効化されているため、Google アカウントでのログインが求められます。 IAP で保護されたウェブアプリ ユーザー ( roles/iap.httpsResourceAccessor )ロールが付与されたユーザーでログインします。 Google アカウントでログインする まず最初のセッションでは、普段飲むコーヒーについての情報(例: 「私は中浅煎りのコスタリカをよく飲みます。おすすめの抽出方法を教えてください」)をエージェントに伝えます。 最初のセッションで普段飲んでいるコーヒー豆についての情報をエージェントに伝える Memory Bank の中身を確認すると、IAP でログインしたユーザーのメールアドレスを user_id として、「私は中浅煎りのコスタリカをよく飲みます。」という情報を保持する記憶が作成されていることがわかります。 IAP でログインしたユーザーのメールアドレスを user_id として記憶が作成される 再度、別ブラウザから同じユーザーを使用してチャットボットにログインして、「私の好みに合うコーヒー豆を探してください」と伝えてみます。前回伝えたコーヒーの好みが Memory Bank に記憶されているため、その情報を元にした回答が返ってきます。 ユーザーごとに保存された好みに関する情報が別のセッションに引き継がれている Memory Bank のカスタマイズ カスタマイズの概要 Memory Bank はデフォルト設定でもユーザーの嗜好などを自動的に抽出して長期記憶として保存してくれますが、実際にエージェントとやり取りを繰り返してみると、思うように抽出されない場合もあります。 Memory Bank では、カスタマイズ設定を適用することで、抽出する情報の種類や挙動をユースケースに合わせて調整することができます。 Memory Bank では主に以下の項目をカスタマイズできます。 項目 説明 トピック Memory Bank が保存すべきと判断する情報の種類を定義します。Google Cloud が提供する managed トピック ( USER_PERSONAL_INFO 、 USER_PREFERENCES 、 KEY_CONVERSATION_DETAILS 、 EXPLICIT_INSTRUCTIONS )と、ラベルと抽出指示を自分で定義できる custom トピック の2種類があります。 生成モデル 記憶の生成に使用する LLM を指定できます(デフォルトは gemini-2.5-flash )。 埋め込みモデル 記憶の検索や統合の判定に使用する埋め込みモデル(embedding model)を指定できます(デフォルトは text-embedding-005 )。日本語など英語以外の会話を扱う場合は、 gemini-embedding-001 や text-multilingual-embedding-002 といった多言語対応モデルを指定することで検索品質を向上できます。 有効期限(TTL) 生成・更新された記憶の有効期限を自動設定するルールを定義できます。 Few-shot Examples 抽出してほしい記憶の例をいくつか与えることで、Memory Bank の抽出挙動を調整できます。 カスタマイズ項目の詳細については、以下のドキュメントを参照してください。 参考 : メモリバンク 用に Agent Platform インスタンスを構成する カスタマイズ用スクリプト(update.py)の作成 adk コマンドからは Memory Bank のカスタマイズを直接適用することはできないため、Agent Platform SDK を使用するスクリプトで、デプロイ済みの Agent Runtime インスタンスを更新します。 ここではコーヒーエージェントのユースケースに合わせて、コーヒーに関する情報を重点的に抽出するための custom トピックを定義します。具体的には、以下の5つのトピックを Memory Bank に登録します。 トピック 種類 抽出対象 USER_PREFERENCES managed ユーザーの一般的な嗜好 coffee_taste_preferences custom 好む / 苦手な味わいの傾向(酸味・苦味・フレーバーノート・焙煎度合いなど) brewing_methods custom 普段使用している抽出方法と器具 favorite_beans_and_origins custom 好みの豆の産地・品種・銘柄・ロースター coffee_habits_and_restrictions custom 飲用習慣やカフェイン制限などの制約 また、日本語での会話における検索の品質を高めるため、 similarity_search_config で多言語対応の埋め込みモデル gemini-embedding-001 を指定します。 スクリプトの内容は以下のようになります。 client.agent_engines.update() に context_spec.memory_bank_config.customization_configs を渡すことで、デプロイ済みの Agent Runtime インスタンスに対してカスタマイズ設定のみを反映できます。 import os import vertexai from vertexai.types import ( MemoryBankCustomizationConfig as CustomizationConfig, MemoryBankCustomizationConfigMemoryTopic as MemoryTopic, MemoryBankCustomizationConfigMemoryTopicCustomMemoryTopic as CustomMemoryTopic, MemoryBankCustomizationConfigMemoryTopicManagedMemoryTopic as ManagedMemoryTopic, ManagedTopicEnum, ) client = vertexai.Client( project=os.getenv( "PROJECT_ID" ), location=os.getenv( "LOCATION" , "asia-northeast1" ), ) # Memory Bank に保存する記憶のトピック定義 memory_topics = [ # ユーザーの好み(managed トピック) MemoryTopic( managed_memory_topic=ManagedMemoryTopic( managed_topic_enum=ManagedTopicEnum.USER_PREFERENCES ) ), # 味わいの好み MemoryTopic( custom_memory_topic=CustomMemoryTopic( label= "coffee_taste_preferences" , description=( "ユーザーが好む / 苦手なコーヒーの味わいの傾向。" "酸味・苦味・甘み・ボディ感、フレーバーノート(フルーティ、" "ナッティ、チョコレートなど)、焙煎度合い(浅煎り / 中煎り / 深煎り)。" ), ) ), # 抽出方法・器具 MemoryTopic( custom_memory_topic=CustomMemoryTopic( label= "brewing_methods" , description=( "ユーザーが普段使っている、または興味のあるコーヒーの抽出方法と器具。" "ハンドドリップ、エスプレッソ、フレンチプレス、エアロプレス、サイフォンなど、" "および使用しているグラインダーやドリッパーなどの器具情報。" ), ) ), # 好みの豆・産地 MemoryTopic( custom_memory_topic=CustomMemoryTopic( label= "favorite_beans_and_origins" , description=( "ユーザーが好む / 過去に飲んだコーヒー豆の産地・品種・銘柄・ロースター。" "例: エチオピア イルガチェフェ、ゲイシャ、ブルーマウンテン、特定のロースター名など。" ), ) ), # 飲用習慣・カフェイン制限 MemoryTopic( custom_memory_topic=CustomMemoryTopic( label= "coffee_habits_and_restrictions" , description=( "ユーザーのコーヒーの飲用習慣(1日の杯数、飲む時間帯)、" "カフェイン制限の有無、デカフェ志向、乳製品アレルギーや代替ミルクの好みなど。" ), ) ), ] customization_config = CustomizationConfig(memory_topics=memory_topics) # 類似性検索に使用する埋め込みモデル(多言語対応の gemini-embedding-001 を指定) project = os.getenv( "PROJECT_ID" ) location = os.getenv( "LOCATION" , "asia-northeast1" ) embedding_model = ( f "projects/{project}/locations/{location}/publishers/google/models/gemini-embedding-001" ) # 既存の Agent Runtime を Memory Bank カスタマイズ付きで更新 resource_name = os.environ[ "RESOURCE_NAME" ] agent_engine = client.agent_engines.update( name=resource_name, config={ "context_spec" : { "memory_bank_config" : { "customization_configs" : [customization_config], "similarity_search_config" : { "embedding_model" : embedding_model, }, }, }, }, ) print ( "Memory Bank customization applied." ) print (f "Resource Name: {agent_engine.api_resource.name}" ) カスタマイズの適用 スクリプトを実行する際は、デプロイ済みの Agent Runtime のリソース名( projects/<プロジェクトID>/locations/<ロケーション>/reasoningEngines/<エージェントID> )を環境変数 RESOURCE_NAME にセットしておきます。 # 環境変数のセット $ export PROJECT_ID = < プロジェクトID > $ export LOCATION =asia-northeast1 $ export RESOURCE_NAME = < エージェントのリソース名 > # カスタマイズの適用 $ uv run python update.py スクリプトの実行が成功すると、Agent Runtime インスタンスに Memory Bank のカスタマイズ設定が反映されます。 コンソールからは、類似性検索に使用する埋め込みモデルが gemini-embedding-001 に更新されていることが確認できます。 類似性検索に使用するモデルが変更されている カスタマイズ後の動作確認 Cloud Run にデプロイしたチャットボットにログインし、「私は酸味が美味しいコーヒーが好きで、コスタリカ、パナマ、ケニア、エチオピアが特に好みです。ハンドドリップで1日に4杯ほど飲みます。好みに近いおすすめの豆を教えてください」のような内容でメッセージを送信してみます。 Memory Bank を確認すると、設定したトピックごとに記憶が作成されていることがわかります。 設定したトピックごとの記憶が Memory Bank に記録される 佐々木 駿太 (記事一覧) G-gen 最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出(2024 / 2025 Fellow / 2026)。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説(SF、ミステリ)、カラオケなど。 Follow @sasashun0805
G-gen の荒井です。当記事では、Google Cloud Next '26 で発表された Google Workspace に関する新機能について、公式の投稿記事およびセッションの内容をもとに紹介します。 G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '26 に関連する記事を発信します。 blog.g-gen.co.jp はじめに Keynote Features Workspace Intelligence(GA) Rapid Enterprise Migration(GA) Drive & Document Editor New Gemini capabilities in Sheets, Docs, and Slides(Preview) Ask Gemini in Drive(GA) Third-party data in Sheets(Preview) Collaboration Ask Gemini in Chat(Preview) AI Inbox and AI Overviews in Gmail(Preview) Help from Gemini in every meeting(Preview) AI Features Workspace skills(Coming Soon) Custom Avatars in Vids(GA) Auto browse with Gemini in Chrome(GA) Workspace MCP Server(Developer Preview) Gemini Enterprise app Workspace capabilities in the Gemini Enterprise app(Private Preview) Management Simplified agent governance(GA) New sovereign controls and client-side encryption(Coming Soon) はじめに 以下の Google 公式投稿および実際に現地で行われたセッションを参考に、Google Cloud Next '26 で発表された Google Workspace に関する新機能を紹介します。なお、当記事で紹介する機能の提供ステータス(GA / Preview / Coming Soon)は 2026年4月29日現在の情報です。 参考 : 10 more announcements from Google Workspace at Cloud Next ‘26 参考 : 260 things we announced at Google Cloud Next '26 – a recap Keynote Features Workspace Intelligence(GA) 1日目のキーノートで発表された Workspace Intelligence は、Google Workspace における発表の中で最も重要なアップデートです。 新しいアプリケーションや操作ボタンとして表示されるものではなく、Google Workspace 内の抽象化されたセマンティックレイヤーとしてバックグラウンドで稼働する仕組みです。 公式投稿から引用 Workspace Intelligence は、Google Workspace の各種アプリケーションに保存されたファイルや、Gmail および Google Chat のメッセージ、インターネット上の情報からコンテキストを収集し、ユーザーの立場や業務内容を分析します。これにより、ユーザーが求めるアウトプットを的確に理解し、Gemini がパーソナライズされた回答を生成します。主要な機能は以下のとおりです。 情報収集 Google Workspace およびインターネットの情報から様々なコンテキスト情報を収集します。 状況認識 Gemini の推論技術を用いることで、今ユーザーにとって何が最も重要かを理解し、重要なタスクを把握します。 パーソナライゼーション 過去の仕事やコミュニケーションパターンを学習し、独自の仕事スタイル、話し方、書式設定の好みを理解し、パーソナライゼーションしたアウトプットを行います。 参考 : Google Cloud Next '26速報レポート - キーノート(1日目) - G-gen Tech Blog 参考 : Introducing Workspace Intelligence 参考 : Workspace
Intelligence Contextual AI for the enterprise 参考 : Introducing Workspace Intelligence, with admin controls Rapid Enterprise Migration(GA) 同じく1日目のキーノートで発表された Rapid Enterprise Migration については、キーノート内での詳細な発表はありませんでしたが、ブレイクアウトセッション「Fast-track to Google Workspace: Smooth migration, adoption, and interoperability」にて具体的な内容が紹介されました。 「Fast-track to Google Workspace: Smooth migration, adoption, and interoperability」のセッション内容は以下の記事を参照してください。 参考 : Fast-track to Google Workspace: Smooth migration, adoption, and interoperability(Google Cloud Next '26速報) - G-gen Tech Blog 実質的には、従来より提供されていた Data Import 機能に該当します。Data Import は従来「データ移行(新規)」という名称でしたが、管理コンソールやドキュメントも Data Import と名称が変更されています。 参考 : Introducing data import: An easier, faster, and higher-fidelity migration to Google Workspace at no additional tool cost 参考 : データ インポート ツールについて データ移行ツールは Data Import に集約され、Microsoft 365 から容易にデータ移行を行えます。スライド内で言及されている「データ移行速度が5倍」という点については、従来 Google Workspace に実装されていたデータ移行ツールに比べて速度が速くなったことを意味しています。 当機能は「データ移行(新規)」として既にプレビューで実装されていた機能です。当社による検証結果は、以下の記事で公開しています。 参考 : Microsoft OneDriveからGoogle ドライブへのデータ移行を検証してみた - G-gen Tech Blog 参考 : Microsoft TeamsからGoogle Chatへのデータ移行を検証してみた - G-gen Tech Blog 参考 : Microsoft SharePoint OnlineからGoogle ドライブへのデータ移行を検証してみた - G-gen Tech Blog 参考 : DropboxからGoogleドライブへのデータ移行を検証してみた - G-gen Tech Blog Drive & Document Editor New Gemini capabilities in Sheets, Docs, and Slides(Preview) 自然言語を用いてドキュメント(スプレッドシートやスライド)の作成や編集ができます。サイドパネルの Gemini に自然言語で指示をするだけで、複数枚のスライドやデータに基づいたインフォグラフィックの作成、コメントのフィードバックに基づいた編集が実行できます。作成されたスライドは編集可能な状態を維持するため、後日資料の再編集もできます。 さらに、企業ブランドを反映したテンプレートを参照しドキュメント作成をすることもできるため、ブランドテンプレートへ変換する手間がなくなります。 参考 : New ways to create faster with Gemini in Docs, Sheets, Slides and Drive 参考 : New Gemini capabilities in Google Docs help you go from blank page to brilliance 参考 : Build and edit complex spreadsheets with Gemini in Google Sheets 実際の動作イメージについては、Google から公開されている以下の動画を参照してください。 youtu.be Ask Gemini in Drive(GA) Ask Gemini in Drive を使用することで、自然言語で探したい情報を素早く検索し要約を作成できます。またソースとなるデータも列挙されるため確実な情報を瞬時に入手することができます。 情報検索時はユーザーのアクセス権限を越えた検索はできません。またコピーや複製は行われないため、安全に使用できます。 参考 : New ways to create faster with Gemini in Docs, Sheets, Slides and Drive 参考 : Ask Gemini in Drive now generally available 参考 : AI Overviews in Drive now generally available Third-party data in Sheets(Preview) HubSpot や Salesforce などのアプリからサードパーティデータを Google スプレッドシートにインポートできるようになりました。 また、スプレッドシートの表から、ダッシュボードやヒートマップ、かんばんボードといった簡易アプリを作成できます。アプリ内のデータはソースとなる表のデータとリアルタイム接続されており、リアルタイムに情報が更新されます。生成したアプリはチームメンバーと共有できます。 表データからアプリを生成するデモンストレーションは、以下の動画で確認できます。 youtu.be Collaboration Ask Gemini in Chat(Preview) Google Chat 内に Ask Gemini が追加され、Workspace Intelligence によりパーソナライズ化された Gemini と会話を行うことができます。 重要タスクの確認やメールの検索、ドキュメントの作成など網羅的に業務支援を行います。 参考 : Get started with Ask Gemini in Google Chat Ask Gemini in Chat を用いてスライドを作成するイメージについては、以下の動画を確認してください。 youtu.be AI Inbox and AI Overviews in Gmail(Preview) Gmail に AI Inbox というトレイが追加されます。受信したメールに対して、 AI を使用した以下の機能を提供します。 To-Do リストの作成 返信が必要なメールを探す キーワードではなく、自然言語でのメール検索 受信メールやスレッドの要約 参考 : Search faster and smarter with AI Overviews in Gmail search Help from Gemini in every meeting(Preview) Google Meet の Gemini 機能により、対面での会議でも、Gemini が音声を記録し、議事録を作成できます。また他社の Web 会議ツールを使用していてもデバイスのマイク機能から議事録の作成ができます。Gemini が会議内容やアクションアイテムを記録することで、ユーザーはより一層会話に集中することができます。 参考 : 対面会議で「自動メモ生成」を使用する 当機能についてはブレイクアウトセッション「Transform meetings into outcomes using Google Workspace with Gemini」でも一部言及されています。以下のセッションレポートも参照してください。 blog.g-gen.co.jp AI Features Workspace skills(Coming Soon) Workspace Studio 内で繰り返しタスクを自動化し、Skill として登録できます。Skill は組織に共有可能であり、Google Workspace 内のあらゆる Gemini からその Skill を起動できるようになります。 Custom Avatars in Vids(GA) Nano Banana 2 の機能により、Google Vids のアバターにブランディング要素を追加できます。企業ロゴをアップロードすることで、アバターにロゴを反映できます。アバターの T シャツにロゴを挿入するなどの編集が、簡単にできます。 参考 : Create custom branded avatars in Google Vids with Nano Banana 2 Auto browse with Gemini in Chrome(GA) 当機能は米国の Google Workspace ユーザーにおけるアップデートです。日本のユーザーは、まだ対応していません。 Chrome Enterprise ライセンスを保有する場合、Gemini の自動ブラウジング機能を有効化できます。Web サイトやアプリを横断し複数ステップのタスクを実行します。Workspace のエンタープライズグレードのセキュリティ機能が適用されるため、機密情報は保護されます。 参考 : The new era of browsing: Putting Gemini to work in Chrome Workspace MCP Server(Developer Preview) Workspace MCP Server を使用することで、ドキュメント作成や Gmail の返信の作成など、高度な Workspace 機能を AI アプリケーションやエージェントに組み込むことができます。 参考 : Google Workspace MCP サーバーを構成する Gemini Enterprise app Workspace capabilities in the Gemini Enterprise app(Private Preview) Gemini Enterprise app から Google Workspace の各種アプリケーションへアクセスし、シームレスに作業を進めることができます。Google カレンダーから会議をスケジュールしたり、ドキュメントやスライドを作成・編集できます。 Management Simplified agent governance(GA) Google Workspace 管理コンソールに AI 関連の制御を包括的に管理できる AI コントロールセンター が導入されました。Workspace 内のデータへのエージェントアクセスを監視、制御、監査することで、AI 活用に関するセキュリティリスクを軽減できます。 New sovereign controls and client-side encryption(Coming Soon) Google Workspace の一部エディションではデータの保管場所を米国および EU に限定することができます。 参考 : データの地理的な保管場所を選択する 今後はドイツやインドなど、さらに多くの国がサポートされる計画が発表されました。 また機密性の高いデータについては、クライアント暗号化により、Google を含む様々なエンティティからのアクセスを禁止するセキュリティ機能が実装されます。 荒井 雄基 (記事一覧) クラウドソリューション部 クラウドサポート課 オンプレ環境のネットワーク・サーバーシステムを主戦場としていたが、クラウド領域にシフト。現在は Google Workspace を中心に企業の DX 推進をサポート。 ・ Google Cloud Partner Top Engineer 2025 / 2026 ・Google Cloud 認定資格 7冠 ・Jagu'e'r エバンジェリスト Follow @arapote_tweet
G-gen の杉村です。2026年4月に発表された、Google Cloud や Google Workspace のイチオシアップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに Google Cloud Next '26 の開催 プロダクトの名称変更 概要 Looker Studio → Data Studio(和名: データポータル) Dataplex Universal Catalog → Knowledge Catalog Cloud Composer → Managed Service for Apache Airflow BigLake → Google Cloud Lakehouse Dataproc → Managed Service for Apache Spark Vertex AI → Gemini Enterprise Agent Platform Google Cloud のアップデート オープンモデル Gemma 4 がリリース Cloud Armor に match condition builder が登場(Preview) Google の動画生成 AI モデル Veo 3.1 Lite が Preview 公開 Google Cloud の VPC で Hybrid Subnets が使用可能に Google Cloud コンソールでも Load Balancer 作成時に Certificate Manager 証明書アタッチが可能に Pub/Sub で AI Inference Single Method Transform (SMT)機能が一般公開 BigQuery に AI.AGG 関数が登場(Preview) Cloud SQL でストレージの縮小ができるように すべての Google Cloud 認定資格で日本語版が受験可能に BigQuery Graph が Preview 公開 Privileged Access Manager(PAM)で将来の IAM 権限付与を予約できるように Colab Enterprise で visualization cells が使えるように Cloud Run woker pools が Preview 版 → 一般公開(GA) Google Cloud〜AWS間のPartner Cross-Cloud Interconnectが一般公開(GA) Gemini Enterprise 用の専用 IAM ロールが登場 データポータルで BigQuery の Conversational Analytics が使用可能に Cloud Run でエフェメラルディスクが Preview 公開 Gemini Cloud Assist のサイドパネルが強化 Gemini Enterprise app でカスタム MCP サーバーが接続可能に BigQuery の CDC テーブルからマテリアライズドビューを作成可能に Compute Engine、GKE、Cloud Storage で「AI Zone」が公開 Google SecOps が VPC Service Controls に対応 VPC Service Controls の ingress/egress ルールで IAM ロールが使用可能に Google Workspace のアップデート Google Vids から YouTube への直接エクスポートが可能に Chrome 拡張機能 Google Vids Screen Recorder が登場 Gemini アプリの macOS 版ネイティブデスクトップアプリが登場 Gemini アプリで会話結果から Docs や PDF を生成可能に Google Meet の Take notes for me(自動議事録)のカスタマイズが可能に はじめに 当記事では、毎月の Google Cloud(旧称 GCP)や Google Workspace(旧称 GSuite)のアップデートのうち、特に重要なものをまとめます。 また当記事は、Google Cloud に関するある程度の知識を前提に記載されています。前提知識を得るには、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp リンク先の公式ガイドは、英語版で表示しないと最新情報が反映されていない場合がありますためご注意ください。 Google Cloud Next '26 の開催 Google Cloud の旗艦イベントである Google Cloud Next が、米国ネバダ州ラスベガスにおいて4月22日(水)から24日(金)までの3日間、開催された。 Agentic(エージェンティックな、自律的な)をテーマに、数多くの新機能が発表された。発表された機能の中には、既に一般公開(GA)されているもの、Preview 公開されているもの、まだ使用可能になっていないものなどが混同している。 主要な発表がされたキーノート(基調講演)については、以下の記事を参照されたい。 blog.g-gen.co.jp blog.g-gen.co.jp また G-gen では、現地に派遣したエンジニアや日本からリモートで情報収集するエンジニアが、各種セッションレポートを公開している。以下のカテゴリ一覧から、Google Cloud Next '26 の関連記事にアクセスできる。 blog.g-gen.co.jp プロダクトの名称変更 概要 2026年4月には以下のように、プロダクトの名称変更が相次いだ。 旧名称 新名称 Looker Studio Data Studio(和名: データポータル) Dataplex Universal Catalog Knowledge Catalog Cloud Composer Managed Service for Apache Airflow BigLake Google Cloud Lakehouse Dataproc Managed Service for Apache Spark Vertex AI Gemini Enterprise Agent Platform Gemini Enterprise Gemini Enterprise app Looker Studio → Data Studio(和名: データポータル) Data Studio returns as new home for Data Cloud assets (2026-04-11) Looker Studio は Data Studio(和名: データポータル)に名前が再変更された。昔の名前に戻ったことになる。経緯は以下のとおり。 もともとは「英名: Data Studio / 和名: データポータル」という名称だった 日本では商標の関係で「Data Studio」という名称が使えないため「データポータル」と表記される 2022年10月の Google Cloud Next '22 で「Looker Studio」に名前が変更され、Looker ブランドに統一された。Looker と Looker Studio の2つの製品が存在する状態になり、混乱を呼んだ 2026年4月に「英名: Data Studio / 和名: データポータル」に戻った システム的には以下の変更がされた。 UI 上の表記が「データポータル(Data Studio)」になった 従来の URL( lookerstudio.google.com )にアクセスすると、新しい URL( datastudio.google.com )にリダイレクトされる Dataplex Universal Catalog → Knowledge Catalog Knowledge Catalog release notes - April 10, 2026 Dataplex Universal Catalog は Knowledge Catalog に改名された。 フルマネージドのデータカタログサービス。今回で4回目の名称変更となる。名称の変遷は以下のとおり。 Data Catalog → Dataplex Catalog → BigQuery universal catalog → Dataplex Universal Catalog → Knowledge Catalog Cloud Composer → Managed Service for Apache Airflow Cloud Composer release notes - April 15, 2026 Cloud Composer は Managed Service for Apache Airflow に改名された。 フルマネージドの Apache Airflow であり、データパイプラインの実装等に使われるマネージドサービス。 BigLake → Google Cloud Lakehouse What is Google Cloud Lakehouse? (2026-04-20) BigLake が Google Cloud Lakehouse に改称。 Google Cloud Lakehouse は、Apache Spark、Apache Flink、Trino といったオープンソースのクエリエンジンとの互換性を持つ、レイクハウスフレームワーク。BigQuery を基幹技術とする。 Dataproc → Managed Service for Apache Spark Managed Service for Apache Spark cluster deployment overview (2026-04-22) Dataproc が Managed Service for Apache Spark に改称。 Managed Service for Apache Spark はその名のとおり、フルマネージドの Apache Spark クラスタ。 Vertex AI → Gemini Enterprise Agent Platform Vertex AI to Gemini Enterprise Agent Platform naming changes (2026-04-22) Vertex AI は、Gemini Enterprise Agent Platform と改名された。これに伴い、これまで Gemini Enterprise と呼ばれていた Web サービスは、Gemini Enterprise app と改名された。また Vertex AI プロダクト群は、以下のように名称が変更となる(一部のみ抜粋)。 旧称 新名称 Vertex AI Gemini Enterprise Agent Platform Gemini Enterprise Gemini Enterprise app Generative AI on Vertex AI Generative AI Vertex AI Studio Agent Studio Vertex AI API Agent Platform API Vertex AI Agent Engine Agent Runtime Vertex AI Search Agent Search Vertex AI Search for Commerce Agent Search for Commerce Vertex AI Conversation Agent Conversation Vertex AI Vector Search Vector Search Vertex AI Training Agent Platform Managed Training Vertex AI Pipelines Agent Platform Pipelines Google Cloud のアップデート オープンモデル Gemma 4 がリリース Gemma 4 モデルの概要 (2026-03-31) オープンモデル Gemma 4 がリリース。商用利用可。以下の種類がある。 E2B / E4B : モバイル、エッジ、ブラウザ向け 31B : より高密度 26B A4B : 高スループットで高度な推論向け Cloud Armor に match condition builder が登場(Preview) Use the match condition builder (2026-03-31) フルマネージド WAF である Cloud Armor に match condition builder が登場(Preview)。 CEL 文を書く時の UI 補助ツール。ルールを書く負担が軽減される。 Google の動画生成 AI モデル Veo 3.1 Lite が Preview 公開 Veo 3.1 Lite Generate Preview (2026-04-02) Google の動画生成 AI モデル Veo 3.1 Lite が Preview 公開。 Veo 3.1 < 3.1 Fast < 3.1 Lite の順で生成秒数あたりの料金単価が安く、Lite が最も安価なモデルとなる。 Google Cloud の VPC で Hybrid Subnets が使用可能に About migrating to Google Cloud with Hybrid Subnets (2026-04-03) Google Cloud の VPC で Hybrid Subnets が使用可能になった。 クラウド側サブネットにオンプレと同じ CIDR を持たせ、IP アドレスを変えずにサーバーをクラウドへ移行できる。オンプレ側ルーターに Proxy ARP の設定が必要であり、またクラウド側のルーティングも少しトリッキーになる。 Google Cloud コンソールでも Load Balancer 作成時に Certificate Manager 証明書アタッチが可能に Google Cloud release notes - April 05, 2026 (2026-04-05) Cloud Load Balancer 作成時に Certificate Manager 証明書のアタッチが Google Cloud コンソールでもできるようになった。 従来は DNS 認証した証明書だと gcloud コマンド等を使う必要があった。今後は証明書マップを UI 上で選択できる。 Pub/Sub で AI Inference Single Method Transform (SMT)機能が一般公開 AI Inference SMT (2026-04-06) Pub/Sub で AI Inference Single Method Transform (SMT)機能が一般公開。Pub/Sub トピックまたはサブスクリプション内のメッセージを Gemini 等の AI モデルで加工。以下のような用途がある。 メッセージに対してリアルタイムで AI モデルによる推論結果を追加(エンリッチメント) アプリケーション側の処理のオフロード 以下の記事も参照。 blog.g-gen.co.jp BigQuery に AI.AGG 関数が登場(Preview) The AI.AGG function (2026-04-06) BigQuery に AI.AGG 関数が登場(Preview)。Cloud Storage 上の非構造化データ(画像またはテキスト)に対して Gemini を使い「意味的な集計」のような処理ができる。感情分析、コンテンツ要約、ログ分析など。 Cloud SQL でストレージの縮小ができるように About storage shrink (2026-04-06) Cloud SQL でストレージの縮小ができるようになった。従来は拡大はできたが縮小はできなかった。インスタンスの再起動が必要。 プライマリインスタンスとリードレプリカの両方で可能。 すべての Google Cloud 認定資格で日本語版が受験可能に Google Cloud 認定資格の一覧を解説。全部で何個ある?難易度は? (2026-04-08) これまで日本語版しか提供されていなかった以下の2試験の日本語版が公開された。 Professional Security Operations Engineer Professional Cloud Database Engineer これをもって、14種類すべての Google Cloud 認定資格が、日本語で受験可能になった、 以下の記事も参照。 blog.g-gen.co.jp BigQuery Graph が Preview 公開 Introduction to BigQuery Graph (2026-04-09) BigQuery Graph が Preview 公開。 Graph Query Language(GQL)を使ってデータ間の関係性を可視化できる。CREATE PROPERTY GRAPH 文でノードテーブル・エッジテーブルを事前に定義。 Privileged Access Manager(PAM)で将来の IAM 権限付与を予約できるように Grant scheduling (2026-04-13) Privileged Access Manager(PAM)で将来の IAM 権限付与を予約できるようになった。最大7日後の予約が可能。 Colab Enterprise で visualization cells が使えるように Use visualization cells (2026-04-13) Colab Enterprise で visualization cells が使えるように。データフレームに入れた値を基にチャート(図表)を簡単に UI で作成できる。BigQuery → df → 可視化を UI 上で簡単に行える。 Colab Enterprise の visualization cells Cloud Run woker pools が Preview 版 → 一般公開(GA) Deploy worker pools to Cloud Run (2026-04-14) Cloud Run woker pools が Preview 版 → 一般公開(GA)。 Pub/Sub などに対してタスクを取得する pull 型ワークロードを実行するためのフルマネージドのコンテナ基盤。高いコスト効率でコンテナのジョブを実行できる。 Google Cloud〜AWS間のPartner Cross-Cloud Interconnectが一般公開(GA) Partner Cross-Cloud Interconnect for AWS overview (2026-04-14) Google Cloud と AWS を容易に専用線接続できる Partner Cross-Cloud Interconnect が一般公開(GA)。 VPC ピアリングまたは Network Connectivity Center 経由で接続できるため、かなり手軽に Google Cloud 〜 AWS 間で専用線確立が可能。 最短で当日中に接続を確立できる。帯域は1Gbps〜100Gbps。 Gemini Enterprise 用の専用 IAM ロールが登場 IAM roles and permissions (2026-04-15) Gemini Enterprise 用の専用 IAM ロールが登場。 Gemini Enterprise 管理者( roles/discoveryengine.agentspaceAdmin ) Gemini Enterprise ユーザー( roles/discoveryengine.agentspaceUser ) これまでは事前定義ロールとして「ディスカバリー エンジン管理者( roles/discoveryengine.admin )」および「ディスカバリー エンジン ユーザー( roles/discoveryengine.user )」が存在していた。 なお2026年4月現在、これらのロールはそれぞれ名称が違うだけで、含まれている権限が全く同一である。 Gemini Enterprise 管理者 <=> ディスカバリー エンジン管理者 Gemini Enterprise ユーザー <=> ディスカバリー エンジン ユーザー データポータルで BigQuery の Conversational Analytics が使用可能に Data agents in Data Studio (2026-04-16) データポータル(先日、Looker Studio から改名した)の画面から、BigQuery の Conversational Analytics(会話型分析)を使用できるようになった。 データポータル Proライセンスは不要。BigQuery でデータエージェントを作成して、一般従業員にエージェントを配ることが容易になった。 データポータルから BigQuery のデータエージェントを使用する Cloud Run でエフェメラルディスクが Preview 公開 Configure an ephemeral disk for Cloud Run services (2026-04-20) Cloud Run でエフェメラルディスクが Preview 公開。 ext4 フォーマットの一時ディスク。インスタンス停止で消去される。 service、job、worker pool いずれでも使用可。従来の /tmp はインメモリのためメモリ料金を消費したが、今後は一時ディスクに逃がせる。 Preview 公開されている2026年4月現在、料金の表記はない。 Gemini Cloud Assist のサイドパネルが強化 Gemini Cloud Assist release notes - April 22, 2026 (2026-04-22) 日本語でも使える 表示させているコンソール画面をコンテキストとして読み取る グラウンディング有無を設定 カスタムインストラクション など。その他にも Private Preview で MCP への対応など。 Gemini Cloud Assist のサイドパネルが強化 Gemini Enterprise app でカスタム MCP サーバーが接続可能に Set up your custom MCP server data store (2026-04-22) Gemini Enterprise app でカスタム MCP サーバーをデータストアとして接続できるようになった(Preview)。 認証は OAuth。MCP 準拠の外部システムや社内データに Gemini Enterprise app からアクセスできる。 BigQuery の CDC テーブルからマテリアライズドビューを作成可能に Tables with active change data capture (2026-04-28) BigQuery の CDC(change data capture)適用テーブルをベーステーブルとして、マテリアライズドビューを作成可能になった。 ストリーミングデータを受け取るテーブルをベースに、自動更新のマテビューを作成でき、運用負荷の軽減になる。 Compute Engine、GKE、Cloud Storage で「AI Zone」が公開 AI Zones (2026-04-27) Google Cloud で「AI Zone」が公開。Compute Engine、GKE、Cloud Storage が対応。 us-south1-ai1b のような名称の特殊なゾーン。GPU や TPU が優先的に提供される代わりに一部サービスは提供されない。オランダ、テキサス、アイオワのリージョンで使用可能。地理的に隔離されているため、通常ゾーンとのレイテンシは比較的大きい。 Google SecOps が VPC Service Controls に対応 Configure VPC Service Controls for Google SecOps (2026-04-30) Google SecOps の VPC Service Controls 対応が一般公開(GA)。Google SecOps は Google の SIEM 製品。VPC Service Controls による IP アドレス制御や、コンテキストアウェアなアクセス制御が可能になった。 VPC Service Controls の ingress/egress ルールで IAM ロールが使用可能に Configure IAM roles in ingress and egress rules (2026-04-30) VPC Service Controls の ingress/egress ルールで、IAM ロールを使用した許可設定が可能に(Preview → GA)。 これまでプリンシパルやメソッドの指定ができたが特定の IAM ロールを持っている場合のみアクセス許可するよう設定できるようになった。以下の記事も参照。 blog.g-gen.co.jp Google Workspace のアップデート Google Vids から YouTube への直接エクスポートが可能に Export Google Vids directly to YouTube (2026-04-02) Google Vids から YouTube への直接エクスポートが可能に。 MP4 で一度エクスポートする必要がない。限定公開動画のエクスポートも可能。 Chrome 拡張機能 Google Vids Screen Recorder が登場 Record your screen directly from Chrome with the Google Vids Screen Recorder Chrome Extension (2026-04-02) Chrome 拡張機能「Google Vids Screen Recorder」が登場。ブラウザ画面を録画して直接 Google Vids に記録できるため編集や共有が容易になる。 Google Workspace でも個人アカウントでも利用可能。 Gemini アプリの macOS 版ネイティブデスクトップアプリが登場 Gemini アプリが Mac に登場 (2026-04-15) Gemini アプリの macOS 版ネイティブデスクトップアプリが登場。 Web 版にない機能として、画面共有して Gemini に質問する機能などがある。 Gemini アプリで会話結果から Docs や PDF を生成可能に Move from conversation to creation with file generation in Gemini (2026-04-27) Gemini アプリで会話結果から Google ドキュメント、スプレッドシート、Microsoft Word(.docx)、Microsoft Excel(.xlsx)、PDF などのファイルを直接、生成可能になった。その他の対応フォーマットは以下のとおり。 Google Workspace files (Docs, Sheets, and Slides) PDF file Microsoft Word (.docx) Microsoft Excel (.xlsx) CSV file (.csv) LaTeX (.tex) Plain Text (.txt) Rich Text Format (.rtf) Markdown (.md) Gemini アプリで会話結果から Docs や PDF を生成可能に Google Meet の Take notes for me(自動議事録)のカスタマイズが可能に New ways to customize AI-generated meeting notes (2026-04-30) Google Meet の Take notes for me(自動議事録)のカスタマイズが可能に。メモの長さや決定事項を入れるかどうかなど。 ただし、一部機能は英語にしか対応していない。詳細なカスタムプロンプトを入れられるわけではない。2026年4月30日から15日間かけて段階的ロールアウト。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X(旧 Twitter)では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it
G-gen の高宮です。当記事は、Google Cloud Next '26 in Las Vegas の 3 日目に行われたブレイクアウトセッション「 Accelerate CI/CD with coding agents 」のレポートです。 G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '26 に関連する記事を発信します。 blog.g-gen.co.jp セッションの概要 ソフトウェア開発の加速と CI/CD の課題 Google CI/CD Extension の概要と特徴 Google CI/CD Extension を用いたデモ 1. Cloud Run への自動デプロイとシークレットスキャン 2. 複数ステージの CI/CD パイプライン設計 3. Terraform による Infrastructure as Code の生成 セッションの概要 本セッションでは、Google の Haroon Chaudhry 氏(Software Development Manager)と Yeshwanth Gunasekaran 氏(Software Engineer)が登壇しました。 セッションでは、生成 AI を用いてコードを記述した後、本番環境へデプロイするまでの CI/CD パイプライン構築に関する課題と、それを解決するための新しい拡張機能である Google CI/CD Extension が発表され、デモを交えて紹介されました。 ソフトウェア開発の加速と CI/CD の課題 2026年4月現在、生成 AI の普及により、開発者の 90% が日常的に AI を使用しています。しかし、AI によって生成されたアプリケーションを本番環境へデプロイする際、約 60% の開発者が課題に直面していると語られました。安全な CI/CD パイプラインを構築するには、単にスクリプトを生成するだけでなく、多様なツールが混在する複雑な環境全体を適切に制御する必要があるからです。 複数の CI/CD プラットフォームの利用、DevSecOps ツールの統合、インフラストラクチャとコードの連携などの課題により、AI の CI/CD 領域での採用率は 27% に留まっています。AI エージェントは単なるコード生成ツールから、インフラストラクチャ全体を統合するオーケストレーターへと進化する必要があることが強調されました。 Google CI/CD Extension の概要と特徴 この課題を解決するため、Gemini エージェントを統合オーケストレーターとして機能させる Google CI/CD Extension が発表されました。 この拡張機能は、 Gemini CLI の拡張機能および Claude Code プラグインとして利用可能であり、オープンソースとして提供されます。 Cloud Run や Google Kubernetes Engine (GKE)などのランタイムに対応しており、自然言語を用いて CI/CD パイプラインの設計、構築、デプロイを行うことができます。 参考 : Gemini CLIを解説 - G-gen Tech Blog 参考 : GitHub Repository : Gemini CLI Extension for CI/CD Google CI/CD Extension は、以下の 4 つのコンポーネントで構成されています。 コンポーネント 説明 Skills CI/CD パイプラインの設計やデプロイに関する事前定義されたワークフローと知識。 Local MCP Server ユーザーの認証情報で実行され、Google Cloud の CI/CD ツールを管理するローカルの Model Context Protocol サーバー。 Grounding through knowledge base CI/CD のベストプラクティスやデプロイメントパターンをパッケージ化したナレッジベース。 Offline Evals オープンソースや独自開発のプロジェクトにおける設計・デプロイパターンをテストする評価システム。 Google CI/CD Extension を用いたデモ 1. Cloud Run への自動デプロイとシークレットスキャン 最初のデモでは、Cloud Code を用いて Python の Flask アプリケーションを Cloud Run にデプロイする様子が示されました。エージェントはアプリケーションの構成を理解し、 Buildpacks を使用してコンテナイメージを構築します。 参考 : Google Cloud の Buildpack 注目すべき点として、コンテナイメージをクラウド上にプッシュする前に、ハードコードされた認証情報がないかを確認するシークレットスキャンが、拡張機能の組み込みチェックとして自動的に実行されました。安全性が確認された後、ユーザーがリージョンや公開設定を指定すると、Cloud Run へのデプロイが完了しました。 2. 複数ステージの CI/CD パイプライン設計 2 つ目のデモでは、Gemini CLI を使用して、 Cloud Build と Cloud Deploy を使用した複数ステージのパイプライン設計が行われました。 参考 : Cloud Build の概要 参考 : Cloud Deploy の概要 以下のプロンプトで指示すると、エージェントは自律的なパイプライン構築ステップを開始しました。 アプリケーション向けに、ステージング環境と本番環境を含む CI/CD パイプラインを設計してください。失敗時に自動ロールバックを行い、Cloud Build と Cloud Deploy を使用してください。 CI/CD パイプライン構築のステップは以下のとおりです。 No 概要 内容 1 要件定義と計画 専用の Skills( google-cicd-pipeline-design 、 google-cicd-release-orchestration )を使用し、Google のベストプラクティスに基づいた計画を立案。 2 デプロイパイプライン構成生成 各環境の Cloud Deploy 構成ファイルを生成。承認ゲートや自動ロールバックルールを自動で組み込み。 3 インフラセットアップ Developer Connect による GitHub 接続、 Artifact Registry 作成、最小権限の IAM ロールを付与したサービスアカウントを準備。 4 ビルド構成の実装 Cloud Build 構成ファイルを作成。リポジトリへのプッシュをトリガーとしたエンドツーエンドのフローを完成。 参考 : google-cicd-pipeline-design 参考 : google-cicd-release-orchestration 参考 : 構成スキーマ リファレンス 参考 : ビルド構成ファイルを作成する 3. Terraform による Infrastructure as Code の生成 最後のデモでは、設計された CI/CD パイプラインのインフラストラクチャを、 Terraform を用いたコードとして生成する様子が披露されました。元のプロンプトに 「Terraform を生成して。」 の1文を追加するだけで、エージェントは専用の Skills google-cicd-terraform を呼び出し、必要な設定ファイルを出力します。 参考 : google-cicd-terraform 生成されたファイルには、Artifact Registry、Cloud Build、Cloud Deploy の設定に加え、専用のサービスアカウントや厳格な IAM ロールの付与までがコード化されており、本番環境レベルのパイプライン構築が対話のみで完結することが示されました。 高宮 怜 (記事一覧) クラウドソリューション部クラウドエクスプローラ課 2025年6月より、G-genにジョイン。前職は四国のSIerで電力、製造業系のお客様に対して、PM/APエンジニアとして、要件定義から運用保守まで全工程を担当。現在はGoogle Cloudを学びながら、フルスタックエンジニアを目指してクラウドエンジニアとしてのスキルを習得中。 Follow @Ggen_RTakamiya
G-gen の河野です。当記事では、 Gemini Enterprise と Agent Development Kit (ADK)を組み合わせて、Google Workspace のリソースを操作する独自の AI エージェントを開発しデプロイする手順を解説します。 はじめに Gemini Enterprise とは Agent Development Kit(ADK)とは 当記事について 背景と構成 なぜ独自開発が必要なのか エージェントの構成 ADK エージェントの実装 ディレクトリ構成 agent.py requirements.txt __init__.py .env Agent Engine へのデプロイ デプロイコマンドの実行 Gemini Enterprise との接続 Google Sheets API の有効化 OAuth クライアント作成 Gemini Enterprise アプリの作成 エージェントの接続設定 動作確認 はじめに Gemini Enterprise とは Gemini Enterprise は、組織内に分散しているデータを横断的に検索し、情報の発見を手助けする生成 AI サービスです。対話型のアシスタント機能や、AI エージェントのプラットフォームとしての機能を備えています。 Gemini Enterprise の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp Agent Development Kit(ADK)とは Agent Development Kit (以下、ADK)は、Google によって開発された AI エージェント構築用のフレームワークです。ADK を使用することで、エージェントへの関数処理組み込みや外部ツールの使用、マルチエージェントの実装が行えます。 以下の記事カテゴリも参照してください。 blog.g-gen.co.jp 当記事について 当記事では、Gemini Enterprise の標準機能だけでは実現が難しい「Google Workspace リソースへの複雑な操作」を、ADK を用いて実装する方法を解説します。 当記事で実装したのは、ユーザーがアップロードした議事録ファイルからタスクを抽出し、指定した Google スプレッドシートに自動で登録する AI エージェントです。 背景と構成 なぜ独自開発が必要なのか Gemini Enterprise には、 Google Workspace と連携するための標準コネクタが用意されています。しかし、標準コネクタでできることは、Google ドライブや Gmail などに対する横断検索や、カレンダーの予定作成、Gmail の送信といった一部の操作に限定されています。 参考 : Connect a Google data source - Supported actions 標準のコネクタでは実行できない操作や、複数の Google Workspace リソースを連携させた複雑な処理を実現したい場合などには、独自のエージェントの開発が必要です。 エージェントの構成 ユーザーが Gemini Enterprise の画面から Google ドキュメントで書かれた議事録を送信すると、 Vertex AI Agent Engine 上で稼働する ADK エージェントが、タスク管理表に抽出するべきタスクを抽出します。 その後エージェントは、ユーザーの権限(OAuth 認証で取得したアクセストークン)を使用して Google Sheets API を呼び出し、スプレッドシートのタスク管理表に、抽出したタスクを追記します。 構成図 ADK エージェントの実装 ディレクトリ構成 以下の構成で、ファイルを作成します。 agent_folder(任意のフォルダ名) ├── agent.py ├── requirements.txt ├── .env └── __init__.py agent.py agent.py は、議事録からタスクを抽出してスプレッドシートに書き込むための AI エージェント本体です。Python 用の ADK を用いてコーディングされています。 コード内の {auth_id} には、任意の値を設定してください。この値は、後述の Gemini Enterprise の設定で使用するので、控えておいてください。 {スプレッドシートID} と {シート名} はタスクの出力先となるスプレッドシートの情報に置き換えてください。 from typing import List, Dict from google.adk.agents.llm_agent import Agent from google.adk.tools.tool_context import ToolContext from google.oauth2.credentials import Credentials from googleapiclient.discovery import build def write_tasks_to_sheet (tool_context: ToolContext, tasks: List[Dict]) -> str : """ 抽出されたタスクのリストを受け取り、スプレッドシートに書き込む Args: tasks: 書き込むタスクのリスト。各タスクは「タイトル」「詳細」「担当者」「期限」のキーを持つ辞書。 Returns: 処理結果を文字列として返す。 """ # Gemini EnterpriseでのOAuth認証で得たアクセストークンを取得 access_token = tool_context.state.get( "{auth_id}" ) if not access_token: return "エラー: アクセストークンが使用できません。認証設定を確認してください。" # アクセストークンを使用して、スプレッドシートを操作するインスタンスを作成 creds = Credentials(token=access_token) service = build( 'sheets' , 'v4' , credentials=creds) # スプレッドシートに書き込む values = [[ task.get( 'タイトル' , '' ), task.get( '内容' , '' ), task.get( '担当者' , '' ), task.get( '期限' , '' ) ] for task in tasks] service.spreadsheets().values().append( spreadsheetId= "{スプレッドシートID}" , range = "{シート名}!A1" , valueInputOption= 'USER_ENTERED' , insertDataOption= 'INSERT_ROWS' , body={ 'values' : values} ).execute() return f "{len(tasks)} 件のタスクを正常に記録しました。" root_agent = Agent( model= 'gemini-2.5-flash' , name= 'root_agent' , description= '入力された議事録を分析し、タスクをスプレッドシートに記録するエージェント' , instruction=( "入力された議事録を分析し、タスクをスプレッドシートに記録するエージェント" "ユーザーからテキストまたはファイルにて議事録を受け取った場合、以下の手順で処理してください: \n " "1. 議事録のテキストを読み取り、内容を分析し、具体的なアクションアイテムを抽出します。 \n " "2. 各タスクを「タイトル」「内容」「担当者」「期限」のフィールドを持つJSONオブジェクトに変換します。" "不明なフィールドは「不明」とします。 \n " "例: {'タイトル':'タスク名','内容':'詳細','担当者':'名前','期限':'YYYY/MM/DD'} \n " "3. 抽出・変換したタスクのJSON配列を 引数`tasks`として、`write_tasks_to_sheet` ツールを呼び出します。" ), tools=[write_tasks_to_sheet], ) 上記のソースコードは、大きく分けて「AI エージェントの定義」と「スプレッドシートへの書き込み処理」の2つのパートで構成されます。 AIエージェントの定義(43~57行目) エージェントにおける AI の推論部分を担います。 instruction (システムプロンプト)の中で、AI に対して「議事録を受け取ったらタスクを抽出し、指定のフォーマットに整形してツールを呼び出す」ように手順を指示しています。 tools=[write_tasks_to_sheet] と定義することで、関数 write_tasks_to_sheet (抽出したタスクをスプレッドシートへ書き込む処理を行う)の呼出しができます。 スプレッドシートへの書き込み処理(9~41行目) 議事録から抽出したタスクのリストを受け取り、Google Sheets API を使って指定のスプレッドシートに追記する処理を担います。 引数 tool_context からユーザーが Gemini Enterprise 上で行った OAuth 認証のアクセストークンを取得し、安全にユーザー権限でスプレッドシートを操作します。 ADK において、ソースコードの Docstring(関数の説明文)は LLM がツールの用途を正しく理解するための重要な要素となるため、適切に記述することが推奨されます。 requirements.txt 必要なライブラリを定義します。2026年4月時点での最新バージョンを指定しています。 google-adk== 1.28 . 1 # ADKのフレームワーク google-auth== 2.49 . 1 # OAuth認証用 google-api-python-client== 2.193 . 0 # スプレッドシートAPI用 __init__.py エージェント起動時に agent.py が読み込まれるようにするためのファイルです。 from . import agent .env エージェント起動時に読み込まれる環境変数を定義します。 GOOGLE_GENAI_USE_VERTEXAI = 1 GOOGLE_CLOUD_PROJECT = { 自身のプロジェクトID } GOOGLE_CLOUD_LOCATION =us-central1 Agent Engine へのデプロイ デプロイコマンドの実行 ターミナルで agent_folder ディレクトリに移動し、ソースコードを Agent Engine にデプロイします。 ※ ライブラリ google-adk がインストールされた環境で実行して下さい。 cd agent_folder adk deploy agent_engine \ --project = 自身のプロジェクトID \ --region = us-central1 \ --display_name =" TaskCreateAgent " \ . デプロイ完了後、Google Cloud コンソールの [Vertex AI] > [Agent Engine] 画面で、エージェントがデプロイされていることを確認します。 後の手順で使用するため、デプロイされたエージェントの リソース名 を控えておきます。 Gemini Enterprise との接続 Google Sheets API の有効化 Google Cloud コンソールで「Google Sheets API」を検索し、有効化します。 OAuth クライアント作成 Google Cloud コンソールの [Google Auth Platform] > [クライアント] から、以下のパラメータで「OAuth クライアント ID」を作成します。以下の表に記載が無いパラメータについては、未入力でも問題ありません。 設定項目 設定値 アプリケーションの種類 ウェブ アプリケーション 名前 任意の名前 承認済みのリダイレクト URI https://vertexaisearch.cloud.google.com/oauth-redirect 承認済みのリダイレクト URI とは、認証後に取得したアクセス権をGemini Enterprise上で使用することを許可する設定です。 OAuth クライアントの作成後、表示される「クライアント ID」と「クライアント シークレット」を控えておきます。 Gemini Enterprise アプリの作成 Gemini Enterprise でエージェントを稼働させるためのアプリを作成します。アプリを作成するユーザーには、以下の IAM ロールが必要になります。 ディスカバリー エンジン管理者( roles/discoveryengine.admin ) 以下の手順でアプリを作成します。 Google Cloud コンソールの [Gemini Enterprise] > [アプリ] から [アプリを作成する] を選択します。 アプリ名に任意の値を入力し、場所は global を選択して作成します。 global 以外のロケーションを利用する場合、機能制限があるため、今回は global を選択しました。 参考 : マルチリージョンの制限事項 エージェントの接続設定 デプロイした Agent Engine のエージェントを、作成した Gemini Enterprise のアプリに接続します。 1.アプリの管理画面から [エージェント] > [エージェントを追加] をクリックし、「Agent Engine によるカスタム エージェント」を選択します。 2.「承認」の設定画面にて、以下のパラメータで「承認を追加」します。 設定項目 設定値 認証名 任意の値 認証ID agent.pyで入力した{auth_id}の値 クライアント ID 控えておいたOAuth クライアント ID クライアント シークレット 控えておいたOAuth クライアント シークレット トークン URI https://oauth2.googleapis.com/token 承認 URI https://accounts.google.com/o/oauth2/v2/auth?scope=https%3A//www.googleapis.com/auth/spreadsheets&include_granted_scopes=true&response_type=code&access_type=offline&prompt=consent&client_id={クライアントID} 設定値の トークン URI とは、Google提供のAPIを使用する際の「アクセストークン」を発行してくれる窓口です。 承認 URI とは、OAuth認証画面において承認するスコープ等を定義したURIです。今回はスプレッドシートを操作するスコープ( googleapis.com/auth/spreadsheets )を設定しています。 {クライアントID} の部分は実際のOAuthクライアントIDに置き換えて下さい。 参考: ウェブサーバー アプリケーションに OAuth 2.0 を使用する 3.「構成」の設定画面で、以下のパラメータで構成を「保存」します。 設定項目 設定値 エージェント名 任意の名前 エージェントの説明 エージェントの説明 Agent Engine 推論エンジン 控えておいたAgent Engine のリソース名 動作確認 以下の手順で、エージェントの動作確認を行います。 Google ドライブ上に、Google ドキュメントで議事録ファイルを、Google スプレッドシートでタスク管理用シートを作成します。 Gemini Enterprise で、エージェント一覧から、作成したエージェントを選択します。 アシスタントに、議事録ファイルを Google ドライブから追加したうえで「タスクを登録して」と入力します。 タスク管理用シートに、抽出されたタスクが登録されたことを確認します。 河野 利紀 (記事一覧) クラウドソリューション部 デジタルワークプレイス課 2025年10月にG-genに入社。 神奈川在住で、Google Cloud をマスターするため日々エンジニアとして修行中。
G-gen の高宮です。当記事は、Google Cloud Next '26 in Las Vegas の1日目に行われたブレイクアウトセッション「 Transform cloud operations and management with generative AI 」のレポートです。 G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '26 に関連する記事を発信します。 blog.g-gen.co.jp セッションの概要 ソフトウェア開発の加速と運用側の課題 Gemini Cloud Assist の進化 Gemini Cloud Assist の新しい特徴 エージェントの内部構造 プロアクティブなエージェントと自律化 MCP サーバーによるエコシステム連携 Gemini Cloud Assist を用いたデモ 1. ホリデーセールを想定した負荷テスト環境の構築 2. 既存環境のコンテキスト理解とプロビジョニング 3. 稼働状況の確認と調査の提案 4. インフラとアプリケーションコードの統合分析 5. 修復プランの提示と実行 Replit 社における活用事例 セッションの概要 本セッションでは、Google の Deepak Kallakuri 氏(Group Product Manager)、 Mark Church 氏(Group Product Manager)、そして Replit 社の Scott Kennedy 氏(VP of Engineering)が登壇しました。 セッションでは、生成 AI の普及によって爆発的に増加するアプリケーションを管理するために、 Gemini Cloud Assist がどのように進化し、プロアクティブかつ自律的なクラウド運用を実現するのかについて、デモを交えて紹介されました。 ソフトウェア開発の加速と運用側の課題 生成 AI とエージェントの登場により、ソフトウェア開発の障壁が下がり、かつてないスピードで新しいソフトウェアが生み出されています。しかし、その裏側で運用チームは、急速に開発されるアプリケーションを安全かつ確実にデプロイし、管理するという課題に直面しています。 生成 AI やエージェントを使用して開発されたアプリケーションには、従来のマニュアルが通用しない課題(品質、トレース、ハードウェア要件など)があります。 Gemini Cloud Assist を使用して運用チームがこの状況を解決するためには、単なる「対話型のエージェント」以上の、ワークフローを自動化するエンタープライズグレードの「自律的なエージェント」が必要であると語られました。 Gemini Cloud Assist の進化 Gemini Cloud Assist の新しい特徴 Gemini Cloud Assist はマニュアルなワークフローから、プロアクティブなクラウドライフサイクル管理へと進化しました。主な強化ポイントは以下の通りです。 カテゴリ 概要 詳細・特徴 Design & Deploy インフラ設計とデプロイ Terraform における YAML を用いたインテント駆動型設計。セキュリティ設計。 Operate & Manage リソース操作の代行 gcloud と kubectl、bq コマンドの連携。Human-in-the-Loop を伴うコマンドの実行。 Investigate 調査・トラブルシューティング プロアクティブな調査。サポートケースの作成と引継ぎ。 Optimize コストの分析と最適化 プロアクティブなコスト分析。コスト異常の検出。 参考 : Gemini Cloud Assist overview 参考 : Gemini Cloud Assist Investigationsを解説。AIエージェントでトラブルシューティング - G-gen Tech Blog エージェントの内部構造 Gemini Cloud Assist を支えるエージェントの内部構造として、大きく以下の3つの要素が追加・強化されたことが解説されました。 機能 概要 詳細・特徴 Reasoning loop 推論ループ ユーザーのプロンプトや解決すべき課題について推論し、ツールの呼び出しを実行。以前の実行結果に基づいて次の呼び出しを調整し、複雑なトラブルシューティングの際には複数の推論ループを並行して実行することが可能。 Agent Session History エージェントのセッション履歴 ユーザーのセッションを理解し、コンソール画面やプロジェクト内のリソースからコンテキストを取得。 Long-term memory 長期記憶 環境やユーザーの好みを長期的に学習することで、時間の経過とともにより的確な回答を返すように進化。 プロアクティブなエージェントと自律化 Proactive agents は、アラートが発生した際にエージェントが自律的に調査を開始する機能です。これまではアラートが発生してから人間が調査を開始していましたが、この機能により、深夜にアラートが発生しても、エージェントが自動的に関連するアラートをグループ化し、調査を実行して根本原因と修正案を作成しておきます。運用担当者が確認したときには、すでに解決の準備が整っているという、プロアクティブな運用への転換を実現します。 参考 : Set up Proactive Mode 参考 : Automate actions based on Proactive Agent results MCP サーバーによるエコシステム連携 Gemini Cloud Assist が Model Context Protocol (以下、 MCP )をサポートしました。これにより、 Gemini CLI や Claude Code 、あるいは自作のカスタムエージェントから、 Gemini Cloud Assist の調査機能やコスト分析機能をツールとして呼び出せるようになります。Google Cloud の専門知識を持つエージェントの能力を、既存の開発ワークフローにシームレスに組み込むことが可能です。 参考 : Integrate Gemini Cloud Assist with third-party tools using MCP 参考 : MCP Reference: geminicloudassist.googleapis.com 参考 : Google Cloud MCP Serversを解説 - G-gen Tech Blog Gemini Cloud Assist を用いたデモ 1. ホリデーセールを想定した負荷テスト環境の構築 セッションでは、強化された各機能を活用し、チャットアプリケーションの負荷テスト環境の構築から、それに伴う障害の調査と解決までを一気通貫で行うデモが披露されました。 デモのシナリオとして、チャットベースのアプリケーション(Chatly)に対してホリデーセールをシミュレーションするために、擬似的にトラフィックを生成するジェネレータを追加する状況が示されました。 Gemini Cloud Assist に対して、自然言語で「トラフィックジェネレータを追加して」と指示を出します。 2. 既存環境のコンテキスト理解とプロビジョニング 指示を受けたエージェントは、プロジェクト内の既存リソースの状態を理解し、必要なインフラ構成を推論します。この際、すでに別のトラフィックジェネレータが存在していることを検知すると、「すでに存在しますが、新しく作成しますか? それとも更新しますか?」とユーザーに確認を求めました。 これは、エージェントが単に指示を実行するだけでなく、環境のコンテキストを理解して重複作業を回避する能力を示しています。運用担当者が実行を承認( Human-in-the-loop )すると、エージェントがユーザーの権限を代理行使してトラフィックジェネレータをデプロイしました。 3. 稼働状況の確認と調査の提案 負荷テストの実行後、アプリケーションのトラフィック、レイテンシ、エラー率などを尋ねると、エージェントは Cloud Monitoring などから情報を収集し、それらを包括的に提示しました。ロードバランサから 503 エラーが返され、レイテンシが悪化していることを検知したエージェントは、自発的に「詳細な調査を実行しましょうか?」とユーザーに提案し、トラブルシューティングのフェーズへとスムーズに移行しました。 4. インフラとアプリケーションコードの統合分析 デモ環境は、フロントエンドおよびバックエンドの Cloud Run と、永続化層の Cloud SQL で構成される3層アプリケーションです。 Gemini Cloud Assist が調査を開始すると、複数の仮説を並行して検証しました。高い CPU 使用率や、ログに出力された OOM(Out of Memory)メッセージなどのインフラストラクチャのシグナルを収集します。 さらに、ソースコードのデプロイメントと連携し、アプリケーションのコードベースまで踏み込んだ調査を行いました。結果として、「アプリケーションコード内に、150万個の辞書オブジェクトを生成する非効率なループ処理が存在し、それが設定されたメモリ上限を超過させている」という根本原因を特定しました。 5. 修復プランの提示と実行 開発チームにコードの修正を依頼してデプロイを待つ間にもシステムを復旧させるため、 Gemini Cloud Assist は暫定的な修復プランとして「 Cloud Run のメモリ割り当てを 2GB に増やす」ことを提案しました。運用担当者が提案内容を確認し、実行を承認すると、エージェントが迅速に設定を変更し、障害を解消させました。 Replit 社における活用事例 Replit 社の Scott Kennedy 氏からは、同社のプラットフォーム上で稼働する 120 万以上の公開アプリを支えるために AI がいかに不可欠であるかが語られました。 Replit では、ユーザーがアプリを公開した後に直面する「運用の罠(コスト、信頼性、セキュリティの不安)」を解決するために、 Gemini Cloud Assist を活用しています。ワンクリックで稼働状況の調査、原因特定、そして修正の適用までを自律的に行える環境を構築しています。将来的には、AI が第 1 次オンコール担当となり、人間はより複雑なアーキテクチャの設計に集中できるようになると展望を述べました。 高宮 怜 (記事一覧) クラウドソリューション部クラウドエクスプローラ課 2025年6月より、G-genにジョイン。前職は四国のSIerで電力、製造業系のお客様に対して、PM/APエンジニアとして、要件定義から運用保守まで全工程を担当。現在はGoogle Cloudを学びながら、フルスタックエンジニアを目指してクラウドエンジニアとしてのスキルを習得中。 Follow @Ggen_RTakamiya
G-gen の山崎です。当記事は、Google Cloud Next '26 in Las Vegas の3日目に行われたライトニングトークセッション「 Humanoid robots in pediatric care 」のレポートです。 G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '26 に関連する記事を発信します。 blog.g-gen.co.jp セッションの概要 現在の高齢化社会における課題 ケアワーカーの人員不足 小児医療の現場における課題 高齢者介護の現場における課題 ヒューマノイドロボット Miroki の特徴 人中心のデザインと導入要件 ハードウェアインターフェースと安全性 医療および介護現場での導入事例 小児医療での利用 高齢者介護施設での利用 Google の AI 技術との統合 質疑応答 質問1 : 物理的な力が必要なタスクへの対応 質問2 : 感情の知覚 質問3 : ロボットのデザイン 質問4 : システム構築における課題 ブースでの実機レポート セッションの概要 Enchanted Tools 社の Firas Farraj 氏により、小児医療および高齢者介護の現場で活躍するヒューマノイドロボット「 Miroki 」と Google の AI 技術との統合について紹介されました。 現在の高齢化社会における課題 ケアワーカーの人員不足 現在の高齢化社会において、介護および医療業界は深刻な負担を強いられています。 高齢者、子供をケアするケアワーカー(介護・医療従事者)への負担は増大し続けており、2030年までに世界中で現在より 2,000万人 のケアワーカーが必要になると予測されています。 施設は人材の採用に苦労しており、人員不足の解決が急務となっています。 小児医療の現場における課題 小児医療の現場に目を向けると、毎年 40万人 の子供たちががんと診断されており、そのうちの 3分の1以上 が放射線治療を必要としています。 これまで経験したことのない新しい状況と慣れない環境での治療は、子供たちに大きな恐怖を与えます。 彼らには、時間をかけてそばに寄り添い、守ってくれるケアワーカーの存在が必要です。しかし、ケアワーカーは日々の膨大な業務に追われており、一人ひとりの子供に対して十分な時間を割くことは困難です。 高齢者介護の現場における課題 高齢者介護の現場においても状況は同様であり、高齢者介護施設のスタッフは毎年 40% が離職しているという事実が示されました。この高い離職率は、施設運営における知識の喪失や採用コストの増加など、ビジネスにとって非常に厳しい影響を及ぼします。 このような業界の課題を解決するため、ロボットが実行可能なタスクを担い、ケアワーカーを支援するアプローチが求められています。 ヒューマノイドロボット Miroki の特徴 人中心のデザインと導入要件 Enchanted Tools 社が開発しているヒューマノイドロボット Miroki は、これまでの産業用ロボットとは全く異なるコンセプトで設計されています。Firas Farraj 氏は、人の生活空間にロボットを導入するためには、以下の3つの要素が不可欠であると述べました。 信頼(Trusted) ロボットが常に安全に稼働し、100%の確率でタスクを遂行する。 有用性(Useful) 単に見た目が良いだけでなく、実際に現場で役立つ機能を持っている。 愛着(Loved) 利用者が「そばにいてほしい」と感じるデザインである。 もしロボットが威圧的なデザインや、70 kg もある巨大な機械であった場合、子供や高齢者のそばに置いておきたいと思う人は多くありません。 そのため Miroki は、魅力的で親しみやすいキャラクターとしてデザインされています。単なる実用性だけでなく、人を中心とした環境においては感情的なつながりを作り出すことが必要です。 ハードウェアインターフェースと安全性 ロボットが環境内のあらゆる物体を100%の成功率で操作することは、2026年4月現在のロボット工学の技術レベルにおいては困難です。 この課題を解決し、ロボットに何ができて何ができないかを利用者に明確に伝えるため、Enchanted Tools 社はロボット専用のハンドルとアクセサリーのエコシステムを開発しました。 Miroki は、この専用ハンドルが取り付けられた物体のみを安全に操作できるように設計されています。これにより、利用者はハンドルの有無を見るだけで、Miroki ができることを直感的に理解できます。 また、特殊な移動システムを採用しており、柔軟かつ静音性が高く、人のすぐそばで安全に稼働できるように設計されています。 医療および介護現場での導入事例 小児医療での利用 フランスのモンペリエにあるがん研究所では、小児がんの放射線治療において Miroki が導入されています。放射線治療室は地下壕のような構造になっており、治療中は患者以外は立ち入ることができません。治療自体に痛みはありませんが、巨大な機械が患者の周囲を動き回る空間は、子供たちにとって非常に恐ろしいものです。 これまで、恐怖心を和らげるために子供たちには事前に鎮静剤が投与されていました。そのため、本来は 10分 で済む治療プロセスが 1時間以上 かかっていました。 現在では、事前に子供と Miroki の間に関係性を築いた上で、治療室に Miroki が同席する取り組みが行われています。Miroki がそばにいることで子供たちは安心し、鎮静剤を使用せずに治療を受けることができるようになりました。この結果、1回のセッション時間が 50分 から 25分 へと半減し、同じ時間枠で2倍の数の子供たちをケアできるようになりました。 高齢者介護施設での利用 高齢者介護の環境において、Miroki はケアワーカーの業務を多角的に支援しています。具体的なタスクとしては、受付、高齢者向けの朝の体操の進行、記憶力ゲームの実施、食事トレイの運搬補助、グループ活動全般の支援などです。 Miroki がこれらの業務をサポートし、スタッフに寄り添うことで、スタッフと入居者双方の生活の質を向上させています。初期の導入結果では、スタッフと入居者の間で 80% の満足度が得られています。スタッフの満足度を高く保つことは定着率の向上につながり、課題である40%という高い離職率を低下させるための重要な要素です。 Google の AI 技術との統合 Enchanted Tools 社は、Google DeepMind 社と緊密に連携し、ロボットのアーキテクチャに Gemini を統合しています。 参考 : Google DeepMind 音声認識および対話機能には Gemini Live の音声機能が使用されており、自然なコミュニケーションを実現しています。また、周囲の環境を認識し理解する機能には Gemini Robotics が使用されています。 参考 : Gemini Live 参考 : Gemini Robotics セッション内のデモ動画では、利用者が「メガネをなくしてしまった」と伝えると、Miroki がエリアをスキャンしてメガネを発見し、さらに本を読むための居心地の良い場所を提案する様子が紹介されました。音声だけでなく状況を視覚的に捉え、複数のタスクを連続して支援する能力が示されました。 質疑応答 本セッションの後半では、参加者と登壇者による質疑応答が行われました。 質問1 : 物理的な力が必要なタスクへの対応 質問 高齢者介護において、患者や入居者を持ち上げたり移動させたりするような、物理的な力が必要なタスクへの対応はどのようになっているか。 回答 2026年4月現在、まだその段階には到達していないが、現在の技術の加速を考慮すると、2〜3年のタイムラインで物理的タスクにも対応できるようになると予測している。技術の進歩に合わせてケアワーカーを全面的に支援できるように機能を拡張していく方針だ。 質問2 : 感情の知覚 質問 誰かが怒っている、悲しんでいるといった感情の知覚についてどこまで進んでいるのか。 回答 感情の検出には、視覚分析、声のトーンや表現方法の分析、そして発話されるテキストの分析という3つのモダリティを使用している。Gemini のマルチモーダル機能により、人が感情を表現している場合は十分に把握可能となる。人が感情を表現していない場合は、非言語的なシグナルを読み取る必要があるため、難易度が高い。 質問3 : ロボットのデザイン 質問 なぜロボットがキツネのような見た目をしているのか。 回答 ロボットのデザインを人の外見に近づけすぎてしまうと、人ができることはすべてできるはずだと利用者が認識する可能性があるため、人とペットの中間のような、これまでにない新しいキャラクターをデザインした。 質問4 : システム構築における課題 質問 システムに Gemini を組み込むことによって直面した課題はあるか。 回答 Google DeepMind 社の素晴らしい働きにより、モデルのパフォーマンスに関する課題は発生していない。一方で、モデルをクラウド上で実行するため、ネットワークの通信環境が悪い環境下では課題が残っている。将来的にはオフライン環境下においても十分なパフォーマンスを発揮できるようにしたい。 ブースでの実機レポート セッション終了後、会場内の Enchanted Tools 社の展示ブースに立ち寄り、Miroki の実機を見ることができました。 展示ブースでは、スムーズに移動しながら展示ブースに訪れた人々と自然な会話を行う姿を見ることができ、ハードウェアの工夫と AI 技術の統合が実用的なレベルに達しつつあることを感じました。 山崎 曜 (記事一覧) クラウドソリューション部 元は日系大手SIerにて金融の決済領域のお客様に対して、PM/APエンジニアとして、要件定義〜保守運用まで全工程に従事。 Google Cloud Partner Top Engineer 2025 選出。 Google Cloud 全 13 資格保有。 フルスタックな人材を目指し、日々邁進。 Follow @Akira_Yamasakit