デベロッパー

BGP ルートポリシー: お客様の需要に基づく上位 3 つのユースケース

Wed, 22 Jul 2026 01:30:00 +0000

※この投稿は米国時間 2026 年 7 月 8 日に、Google Cloud blog に投稿されたものの抄訳です。

1 年以上前に Cloud Router の BGP ルートポリシーの一般提供を開始した際、Google が目指したのは、ネットワーク管理者がネットワークパスの評価と伝播の方法を詳細にプログラムで制御できるようにすることでした。それ以来、Google はお客様がこの機能をどのように採用しているかを注意深く見守ってきました。そして、従来はサードパーティ製の仮想アプライアンスなしには実現が難しかった、極めて高度でレジリエンスの高いルーティングアーキテクチャを、多くのネットワークエンジニアリングチームが構築する姿を目にしてきました。

今年、Google は Cloud Router のポリシー名付きセットをリリースしました。ルーティング環境が複雑化するにつれて、これらのポリシー内の個々のプレフィックスやコミュニティの管理は煩雑になる可能性があります。

ポリシー名付きセットは、IPv4 / IPv6 プレフィックスまたは BGP コミュニティのリストを再利用可能な単一のエンティティにグループ化することで、この問題を解決します。構成が大幅に簡素化され、複数の Cloud Router にわたってルーティングルールのスケール、管理、更新が容易になります。

Common Expression Language（CEL）を基盤とする BGP ルートポリシーを使用すると、Cloud Router 内で BGP ルートをフィルタし、ルート属性を直接変更するための、きめ細かい順序付きルールを定義できます。

ポリシー名付きセットのリリースを記念して、過去 1 年間にお客様が BGP ルートポリシーを使用された方法のうち、特に効果的だった 3 つの事例と、ポリシー名付きセットを自分で作成する方法を記載したリソースをご紹介します。

1. 基盤: ルートフィルタリングとネットワーク保護

トラフィックパスを操作する前に、ネットワークの安定性を確保するには、ネットワークに出入りできるルートを厳密に制御する必要があります。多くのお客様が BGP ルートポリシーを幅広く活用し、ピアから学習した不要なルートをフィルタリングしたり、特定のサブネットプレフィックスが Virtual Private Cloud（VPC）からアドバタイズされないようにしたりしています。

BGP ルートポリシーはデフォルトでは「フェイルオープン」モデルで動作しますが、セキュリティを重視する多くの組織が、評価リストの最後の項目として「すべてドロップ」ポリシーを追加することで、「フェイルクローズ」環境を構築しています。これにより、受け入れられたネットワークルートを確実に把握し、ルーティングループを防ぎ、トラフィックが BGP ハイジャックされたり、意図せずにブラックホール化されたりしないようにできます。

詳細: ルートフィルタリング用の CEL 式を設定する方法の基本については、詳細ガイド「BGP ポリシーの概要」をご覧ください。

2. アクティブ/スタンバイアーキテクチャのトラフィックパスの制御

最適なトラフィック分散を実現するには、コストの最適化やアクティブ / スタンバイ構成の管理など、特定のパスにトラフィックを強制的に誘導しなければならない場面が多々あります。お客様は、オンプレミスのハードウェアに手を加えることなく、BGP ルートポリシーを使用して優先 BGP ルートに影響を与えてきました。

BGP Multi-Exit Discriminator（MED）属性を動的に変更することで、ネットワークチームは特定のピアを受信トラフィックの優先パスとして設定できるようになります。逆に、輻輳したリンクやバックアップリンクからトラフィックを誘導したい場合は、AS-PATH プリペンディングを使用します。これは、ルートの AS-PATH に 1 つ以上の値を追加して、より広範なネットワーク全体で優先順位を下げる方法です。

詳細: MED と AS-Path プレフィックスの管理に関する構成手順については、 BGP ポリシーを使用してトラフィックパスに影響を与えるをご覧ください。

3. BGP コミュニティで非対称ルーティングを解決する

過去 1 年間で最も要望が多く、かつ高度なユースケースの一つが、トラフィックの対称性の実現です。オンプレミスでステートフルファイアウォールや特定のネットワークアプライアンスを使用する企業の場合、戻りトラフィックは、発信元と同じアプライアンスを通過する必要があります。そうでない場合は、トラフィックがドロップされます。

お客様は、BGP ルートポリシーを使用して特定の標準 BGP コミュニティと照合することで、この問題を解決しています。オンプレミスで特定のコミュニティにルートをタグ付けすると、Cloud Router はインバウンドポリシーを介してこれらのタグを読み取り、それに応じて MED を操作してルートの優先度を調整できます。これにより、Google Cloud はオンプレミスネットワークのステートフルなトポロジを本質的に理解し、戻りトラフィックを対称的にルーティングできます。

詳細: BGP コミュニティタグを使用してステートフルトラフィックの対称性を設計する方法については、BGP コミュニティを使用してトラフィックの対称性を作成するをご覧ください。

使ってみる

動的ルーティングの制御はこれまで以上に簡単かつ堅牢になりました。BGP ルートポリシーを使用することで、ハイブリッドクラウド接続を最適化して保護する絶好の機会となります。

BGP ルートポリシーを本番環境にロールアウトする前に、ステージング環境でテストして CEL 式とルーティングロジックを確認することをおすすめします。技術ドキュメントについては、BGP ルートポリシーの概要をご覧ください。

- プロダクトマネージャー、Olivier Vautrin

- クラウドネットワーキング、テクニカルソリューションコンサルタント、Jonny Almaleh

Gemini Enterprise Agent Platform のフルマネージドリモート MCP サーバーでエージェントをさらに迅速に構築

Wed, 22 Jul 2026 00:10:00 +0000

※この投稿は米国時間 2026 年 7 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。

数か月前に、50 を超える Google マネージド MCP サーバーが利用可能になったことをお知らせしました。

今回は、Gemini Enterprise Agent Platform のリモート MCP サーバーを使用して、外部の AI エージェントを Google Cloud 環境内のリソースに安全に接続する方法について詳しく説明します。

IDE を Google Cloud に接続する

Agent Platform の MCP サーバーは、お気に入りの外部開発ツールと Google Cloud アーキテクチャの間の橋渡し役として機能します。

たとえば、Antigravity CLI または Claude Code でエージェントを構築している場合、Agent Platform の MCP サーバーを使用すると、そのエージェントから Agent Platform のリソースを安全に操作できます。エージェントは、プロジェクト内で直接、Model Garden のモデルを簡単に呼び出したり、共有されたプロンプトテンプレートを取得したり、ノートブックを管理したりできます。IDE を離れる必要はありません。

価値創出までの時間の短縮

価値を実現するまでのスピードが、最大の強みの一つです。しかし、外部の開発環境をクラウドインフラストラクチャに接続する場合、トレードオフが発生することがあります。開発者が最小限のセットアップで迅速に作業を進めることを望んでも、IT チームはデータアクセスに対する厳格なガバナンスを必要としています。

Agent Platform の MCP サーバーは、外部エージェントに単一の標準化されたインターフェースを提供します。このため、統合コードの作成にかかる時間を短縮し、便利な機能の構築に時間をかけることができます。また、MCP サーバーは完全に Google Cloud の安全なインフラストラクチャ内で実行されるため、開発を迅速化しながらデータを保護するエンドポイントが、すぐに使用できる状態で用意されています。

次のように、両方の長所を活かすことができます。

オープンスタンダードで構築: Google Cloud の外部で構築するエージェントは、オープンな MCP 仕様に完全に準拠します。外部の IDE やフレームワークは、クラウド環境とシームレスに連携できるため、独自仕様のエコシステムに縛られることはありません。
一元的な検出: Agent Platform の Agent Registry でアセットをカタログ化できます。これが組織の一元的なライブラリとして機能するため、チームはスキル、ツール、その他の AI 機能のインベントリ全体を安全に保存、検索、管理できます。
確かなセキュリティとガバナンスを備えた簡単アクセス: 接続はデフォルトで保護されます。IT チームは、ネイティブの Cloud IAM 拒否ポリシーを利用して、外部のデベロッパーフレームワークに、承認された Google Cloud リソースのみの操作を許可できます。

仕組み: 3 つの簡単なステップで接続

API を有効にする: Google Cloud プロジェクト内で Gemini Enterprise Agent Platform API を有効にすると、Gemini Enterprise Agent Platform のリモート MCP サーバーが自動的に有効になります。

2. クライアントを構成する: 構成手順に沿って AI アプリケーションを接続し、リモートサーバーを指定します。

3. ツールセットを使用する: 充実したツールセットエンドポイントのリスト（コピー可能）にアクセスして、Agent Platform リソースの操作をすぐに開始できます。

利用可能なツールセット:

MCP ツールセット
エンドポイント	説明	ツール
/mcp/generate	生成 AI ツール	主要な生成機能
/mcp/predict	予測ツール	推論と未加工の予測
/mcp/notebook	Colab Enterprise ノートブックツール	ノートブックのランタイムと実行の管理
/mcp/endpoints	エンドポイント管理ツール	モデルエンドポイントのライフサイクル管理
/mcp/models	モデルレジストリツール	モデルのアップロード、登録、デプロイ
/mcp/tuning	モデルのファインチューニングツール	ファインチューニングジョブの管理と追跡
/mcp/evaluation	品質評価ツール	モデルの品質とインスタンスの評価を自動化
/mcp/prompts	プロンプト管理ツール	プロンプトエンジニアリングとバージョン管理のワークフロー

使ってみる

Agent Platform のページにアクセスし、お気に入りのエージェントフレームワークを Agent Platform の MCP サーバーに接続して、今すぐ構築を始めましょう。

- Gemini Enterprise、シニアプロダクトマネージャー、Colby Hawker

- ソフトウェアエンジニア、Louis Lin

Cloud Run サンドボックスで AI 生成コードを安全に実行

Tue, 21 Jul 2026 01:00:00 +0000

※この投稿は米国時間 2026 年 7 月 10 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud では、「ホストアプリケーション、データ、クラウド認証情報を危険にさらすことなく、AI 生成コードや信頼できないバイナリを安全に実行するにはどうすればよいか？」という質問をよく受けます。これは言い換えると、「AI が作成したプログラムを実行するための安全なスペース（つまり、そのプログラムが、より高い権限を持つ信頼できるプログラムとは完全に分離されたスペース）をどのように確保すればよいか？」ということになります。

これまで、デベロッパーはコンテナクラスタを使用して複雑なサンドボックスインフラストラクチャを構築するか、サードパーティの専用 microVM ランタイムを有料で使用する必要がありました。

このたび、WeAreDevelopers World Congress で、Google Cloud Run サンドボックスの公開プレビュー版を発表しました。Cloud Run サンドボックスは、信頼できないコードやエージェントワークロードを実行するために特別に構築された、ネイティブでセキュアかつ超高速のランタイム環境であり、ミリ秒単位で起動します。

次の例では、1,000 個のサンドボックスを起動、実行、停止する Cloud Run サービスで、信頼できない Python コードを安全に実行するリクエストを送信します。平均レイテンシは 500 ミリ秒です。

この投稿では、この機能と主なユースケースについて詳しく説明します。

Cloud Run サンドボックスとは

Cloud Run サンドボックスは、既存の Cloud Run サービスインスタンス内にほぼ瞬時に生成できる、軽量で分離された実行境界です。

LLM で、動的に生成された Python スクリプトを実行してビジネスのマージンを計算する必要がある場合でも、ヘッドレスブラウザをスピンアップしてウェブ調査を行う必要がある場合でも、Cloud Run サンドボックスは、サーバーレス環境を離れることなくこれらのタスクを実行できるセキュアで分離されたサンドボックスを提供します。

主なユースケース

LLM コードインタープリタ: 高度なデータ分析機能を AI プロダクトに組み込みます。モデルで、Python、R、SQL コードを記述、実行して、データセットの分析、グラフの生成、複雑な数学的計算をセキュアに行うことができます。
ヘッドレスブラウザ: エージェントがブラウザを実行するためのセキュアな環境を提供します。ホストマシンを危険にさらすことなく、ウェブページのスクレイピング、スクリーンショットの撮影、ウェブワークフローの自動化を安全に行えます。
ユーザーが送信したコードの実行: AI 以外にも、Cloud Run でホストされているプラットフォームでは、サンドボックスを使用して、エンドユーザーがアップロードしたカスタムスクリプト、プラグイン、Webhook を安全に実行できます。

仕組み: デベロッパーエクスペリエンス

デプロイに 1 つのフラグを追加するだけで、Cloud Run サービスでサンドボックスを有効にすることができます。

ステップ 1: サンドボックスランチャーを有効にする

Cloud Run サービスをデプロイするときに、gcloud または YAML 構成でサンドボックスランチャーを有効にします。

code_block: <ListValue: [StructValue([('code', 'gcloud beta run deploy my-agent-service \\\r\n --image=gcr.io/my-project/agent-image \\\r\n --sandbox-launcher'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de0fb3940>)])]>

ステップ 2: コード内でサンドボックスをネイティブに生成する

有効にすると、軽量のサンドボックス CLI バイナリが自動的に実行環境にマウントされます。エージェントアプリケーションは、標準のサブプロセス呼び出しを使用して、サンドボックスをプログラムで生成できます。

LLM によって生成された信頼できない Python スクリプトを簡単に実行する方法は次のとおりです。

code_block: <ListValue: [StructValue([('code', 'import subprocess\r\n\r\ndef run_untrusted_code(llm_code: str):\r\n # 1. Write the untrusted LLM code to a local file\r\n with open("/tmp/generated_script.py", "w") as f:\r\n f.write(llm_code)\r\n \r\n # 2. Run it inside the secure sandbox\r\n # The sandbox shares your container\'s filesystem tools but runs in a secure silo\r\n result = subprocess.run(\r\n ["sandbox", "do", "--", "python3", "/tmp/generated_script.py"],\r\n capture_output=True,\r\n text=True,\r\n timeout=10\r\n )\r\n \r\n return result.stdout if result.returncode == 0 else result.stderr'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de0fb3910>)])]>

安全性を重視した設計: デフォルトでゼロトラスト

Cloud Run サンドボックスは、悪意のあるコードや誤ったコードの実行からホストアプリケーションとクラウドリソースを保護するように設計されています。ランタイムは、3 つの重要なセキュリティ境界を適用します。

1. 認証情報と環境の分離: これらのサンドボックスは、Cloud Run サービスの環境変数にアクセスできず、Google Cloud メタデータサーバーを呼び出すこともできません。

2. ロックダウンされた外向きネットワーク（デフォルトで拒否）: デフォルトでは、サンドボックスの送信ネットワークアクセスは無効になっています。エージェントが、悪意のあるサーバーにデータを流出させようとするスクリプトを実行するように騙された場合でも、ネットワークリクエストはシステムレイヤでブロックされます。明示的にリクエストされた場合にのみ、外向きを有効にできます。

code_block: <ListValue: [StructValue([('code', 'sandbox do --allow-egress -- curl https://api.github.com'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de0fb35e0>)])]>

3. 安全なファイルシステムオーバーレイ: サンドボックスは、コンテナのファイルシステムの読み取り専用ビューで実行されます（インストールされたパッケージ、Python ランタイム、バイナリを使用できます）。ただし、すべての変更は、分離された一時的なメモリオーバーレイに書き込まれます。サンドボックスの実行が終了すると、生成されたファイルはすべて破棄されます。サンドボックス間で再利用するために、必要に応じてファイルをインポートおよびエクスポートすることは可能です。

code_block: <ListValue: [StructValue([('code', '# Write data from the sandbox to an archive file that can be persisted\r\nsandbox do --write --export-tar=/tmp/work.tar \\\r\n -- /bin/bash -c "mkdir -p /tmp/work && echo \'task-complete\' > /tmp/work/status.txt"\r\n\r\n# Import the archive file in a new sandbox\r\nsandbox do --write --import-tar=/tmp/work.tar \\\r\n -- /bin/bash -c "cat /tmp/work/status.txt"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de0b78250>)])]>

ADK と ComputeSDK の組み込みサポート

Cloud Run サンドボックスは、Agent Development Kit の次のバージョンで、新しい CloudRunSandboxCodeExecutor によりサポートされます。このインテグレーションにより、次のように 1 行を追加するだけで、Cloud Run で実行される ADK エージェントがコードを実行できるようになります。

code_block: <ListValue: [StructValue([('code', 'from google.adk.agents import Agent\r\nfrom google.adk.integrations.cloud_run import CloudRunSandboxCodeExecutor\r\n\r\nanalyst_agent = Agent(\r\n name="cloud_run_data_analyst",\r\n model="gemini-3.1-pro-preview",\r\n system_instruction=(\r\n "You are an expert data analyst. Write and execute Python code to answer "\r\n "user questions and process data safely."\r\n ),\r\n code_executor=CloudRunSandboxCodeExecutor(),\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de0eb3940>)])]>

また、サンドボックスを実行するための、ベンダーに依存しない SDK である ComputeSDK にも Cloud Run サンドボックスが追加されました。この SDK を使用すると、サンドボックスを Cloud Run サービスの外部からリモートで呼び出すか、サービス上のローカルツールとして直接使用できます。Cloud Run サンドボックスでこの SDK を使用する方法については、こちらをご覧ください。

使ってみる

オンデマンドの仮想マシンに高額な料金を請求する専用のサンドボックスホスティングプラットフォームとは異なり、Cloud Run サンドボックスは既存の割り当て済み CPU とメモリで直接実行されます。サンドボックスは実行中のインスタンスのリソースを共有するため、この機能を使用しても追加料金や割増料金は発生しません。ドキュメントはこちらからご確認いただけます。

- プロダクトマネージャー、Ryan Pei

- ソフトウェアエンジニア、Greg Block

Gemini Enterprise と Google Cloud Marketplace でエージェントを公開するためのデベロッパーガイド

Fri, 17 Jul 2026 01:00:00 +0000

※この投稿は米国時間 2026 年 7 月 8 日に、Google Cloud blog に投稿されたものの抄訳です。

Software-as-a-Service（SaaS）は Agents-as-a-Service（AaaS）へと進化しています。

開発者は、複数の分離したアプリケーションではなく、相互運用する AI エージェントを作成するようになってきています。相互運用のためには、Agent2Agent（A2A）プロトコルなどの標準化されたオープンプロトコルを使用し、Gemini Enterprise Agent Platform などの一元的なエージェントプラットフォームを使ってオーケストレーションします。

どのようなユースケースであっても、高品質なエージェントの開発を常に目標とすべきであると Google は考えています。つまり、自律性を前提に、複数ステップの複雑なワークフローを確実に実行できるようなエージェントを開発し、明確なビジネス価値を提供する必要があります。このガイドでは、エージェントの構築 / 開発担当者向けに、Google Cloud Marketplace で有望なサードパーティエージェントを公開、販売する方法、ならびに、Gemini Enterprise app にデプロイする方法を紹介します。この詳細ステップに従うことで、Marketplace ですぐに公開できるような完全統合されたソリューションを実現できます。

ステップ 1: Marketplace との統合を想定して、エージェントアーキテクチャを設計する

最終的なアーキテクチャは、Google Cloud Marketplace の課金の仕組み、ID プロバイダ（IdP）のセキュリティ機能、そして、Gemini Enterprise Agent Platform を連係したものとなります。

このアーキテクチャの要素は、大まかにいって次のとおりです。

カスタマープロジェクト: ユーザーは、Google Cloud Marketplace 内の Agent Marketplace 専用カテゴリでエージェントを見つけます。また、Gemini Enterprise app を通じてこれらのエージェントとやり取りします。
パートナープロジェクト: エージェントに加え、調達ロジックを処理する Marketplace ハンドラ、認証のための動的クライアント登録（DCR）をホストします。
パートナー向け Marketplace プロジェクト: Marketplace のイベント（アカウントの作成や利用資格の承認など）に対応する Partner Procurement API と Pub/Sub トピックを管理します。

ステップ 2: Marketplace で販売するための組織の要件を確認する

Google Cloud パートナーネットワークに参加する。Marketplace でのソリューション提供が初めての場合は、Google Cloud パートナーネットワークに参加する必要があります。
Agent-as-a-Service のリスティング要件を確認する。Marketplace にソリューションを掲載するための要件を組織が満たしていることを確認します。
Marketplace ベンダー契約を確認する。Marketplace ベンダー契約（MVA）を確認して同意します。
Google Cloud Marketplace へのエージェント登録を申請する。Google Cloud の担当者にお問い合わせください。

Marketplace に掲載されるすべてのエージェントは、上記の標準要件を満たすものとします。また、エージェントに関して、以下の要件を満たす必要があります。

エージェントのユースケースの定義: 具体的なエージェントユースケースを定義することをおすすめします。現場の課題解決につながり、複数のエンタープライズカスタマーにスケールできるような、価値の高いエンタープライズ機能に焦点をあてるようにしましょう。
A2A プロトコルへの準拠: エージェントを相互運用するためには、A2A プロトコルの仕様に準拠する必要があります。このプロトコルには、リッチでインタラクティブなユーザーインターフェースを生成するための A2UI プロトコルが含まれます。
A2A エージェントカード: エージェントカード（JSON ファイル）を生成し、機能（スキル）、認証方法、サービスエンドポイントを宣言します。
認証: 一般公開アクセスまたは OAuth 2.0 認証コード付与フローをサポートする必要があります。
Marketplace との統合: 利用資格のライフサイクルを管理するために、Procurement API および Pub/Sub の統合が必須となります。

ステップ 3: Marketplace および Gemini Enterprise app との互換性のための技術要件を確認する

A2A プロトコル

エージェントを設計、実装する際は、A2A プロトコルのドキュメントに従ってください。このドキュメントには、エージェントが提供できるインタラクションパターンの種類（ストリーミングや非同期タスクなど）のほか、A2UI プロトコルによるインタラクティブな UI エクスペリエンスの組み込み方が記されています。A2UI を使えば、最先端かつ最高水準の UX コントロール（高度な動的グラフや最新のインタラクションモデルなど）を組み込めます。これらのネイティブのユーザーコントロールを活用することで、エージェントが確実に機能するようになるだけでなく、Gemini Enterprise app 内で、開発者のこだわりと特別感を打ち出した外観、印象、操作性を実現できます。

A2A エージェントカード

Marketplace に Agent-as-a-Service プロダクトを掲載するには、A2A エージェントカードを用意する必要があります。エージェントカードとは、エージェントの機能（スキル）、サポート対象の認証 / 認可方法、サービスエンドポイントを宣言した JSON ファイルです。

Gemini Enterprise app は、エージェントカードに従って以下を実行します。

エージェントの名前、説明、その他の必須のメタデータを表示する。
動的クライアント登録のエンドポイントを見つける（サポートされている場合）。
エージェントのエントリポイントを見つける（メッセージの送信や、タスク実行に関する最新ステータス取得のためのエントリポイント）。
必須の認証 / 認可方法を判断する。

以下に、定義済みのエージェントカードの例を示します。

code_block: <ListValue: [StructValue([('code', '{\r\n "name": "AI Agent Example",\r\n "protocolVersion": "1.0",\r\n "description": "Marketplace agent example.",\r\n "url": $AGENT_APP_URL,\r\n "preferredTransport": "JSONRPC",\r\n "provider": {\r\n "organization": $AGENT_PROVIDER_ORGANIZATION,\r\n "url": $AGENT_PROVIDER_URL\r\n },\r\n "version": "1.0.0",\r\n "capabilities": {\r\n "streaming": false,\r\n "pushNotifications": false,\r\n "extensions": [\r\n {\r\n "uri": "https://cloud.google.com/marketplace/docs/partners/ai-agents/setup-dcr",\r\n "params": {\r\n "target_url": $AGENT_DCR_URL\r\n }\r\n }\r\n ]\r\n },\r\n "defaultInputModes": [\r\n "application/json"\r\n ],\r\n "defaultOutputModes": [\r\n "application/json"\r\n ],\r\n "skills": [\r\n {\r\n "id": "current_time_generation",\r\n "name": "Current time generation",\r\n "description": "Generates a current time.",\r\n "tags": [\r\n "time"\r\n ],\r\n "examples": [\r\n "What time is it?"\r\n ]\r\n }\r\n ],\r\n "supportsAuthenticatedExtendedCard": false,\r\n "iconUrl": $AGENT_ICON_URL,\r\n "security": [\r\n {\r\n "oauth2": [\r\n $AUTH_SCOPE\r\n ]\r\n }\r\n ],\r\n "securitySchemes": {\r\n "oauth2": {\r\n "type": "oauth2",\r\n "flows": {\r\n "authorizationCode": {\r\n "authorizationUrl": $AUTHZ_URL,\r\n "tokenUrl": $TOKEN_URL,\r\n "refreshUrl": $REFRESH_URL,\r\n "scopes": {\r\n $AUTH_SCOPE: $AUTH_SCOPE_DESCRIPTION \r\n }\r\n }\r\n }\r\n }\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddb9e7d00>)])]>

$AGENT_APP_URL: A2A エージェントにアクセスするためのベース URL エンドポイント（必須項目）。エージェントに対するすべての API 呼び出しで、これがベースパスとして使用されます。
$AGENT_PROVIDER_ORGANIZATION: エージェントプロバイダの組織（必須項目）。
$AGENT_PROVIDER_URL: エージェントプロバイダのウェブサイトまたは関連ドキュメント（必須項目）。
$AGENT_DCR_URL: 動的クライアント登録（DCR）を実装する場合に必須の項目。
$AGENT_ICON_URL: エージェントのアイコンとして使用する画像ファイルの URL を指定する（省略可）。指定した場合、Gemini Enterprise app に表示されます。
$AUTH_SCOPE: クライアントがエージェントのオペレーションにアクセスするために必要なスコープ名の文字列のリスト。
$AUTH_SCOPE_DESCRIPTION: スコープの説明。例: 「ユーザーのメールアドレスを取得する権限」
$AUTHZ_URL: 認証コードフローの OAuth2 セキュリティスキーム定義に必須の要素。リソース所有者からの認可コードを取得する際に必要な、認可サーバーのエンドポイント URL を指定します。これは OpenAPI の仕様に準拠しています。
$TOKEN_URL、$REFRESH_URL: クライアントが認証コードをアクセストークンと更新トークンに交換するための URL（同じでも可）。

認証と認可

A2A プロトコルに従って、エージェントに認証と認可を実装します。Gemini Enterprise app からのエージェント呼び出しを許可するにあたり、以下のいずれかの方法を設定する必要があります。

一般公開: 認証は不要です。ユーザーデータや機密リソースにアクセスしないエージェントにのみ適しています。
OAuth 2.0 認証コード付与フロー: これは、ユーザーが権限を委任（認可）する場合の標準フローです。ユーザーは、エージェントがデータにアクセスしたり、ユーザーの代わりに操作したりすることを許可するよう求められます。

動的クライアント登録（DCR）

従来、サードパーティアプリをエンタープライズシステムに接続するには、クライアント ID とシークレットを手動でコピーする必要がありました。DCR では、Gemini Enterprise がエージェントの認可サーバーに OAuth クライアントとして自動登録されるため、この問題が解消されます。

DCR フローの仕組み:

検出: Gemini Enterprise app がエージェントカードを読み取り、DCR エンドポイントを見つけます。
リクエスト: Google が HTTP POST をエンドポイントに送信します。これには、software_statement（暗号技術を使って署名された JSON ウェブトークン（JWT））が含まれます。
検証: パートナー側のバックエンドで Google の公開鍵を使って JWT 署名を検証し、リクエストが本物であることを確認します。
プロビジョニング: 上記の処理が完了すると、パートナーのサーバーが、ID プロバイダ（Okta など）内に新しい OpenID Connect（OIDC）アプリケーションを作成し、client_id と client_secret を Gemini Enterprise に返します。

code_block: <ListValue: [StructValue([('code', 'DCR Request\r\n{\r\n "software_statement": "eyJhbGciOiJSUzI1NiIsImtpZCI6ImY1OTIwZDJmMjIyYjNjMTE3Y2MyZmQzZmQxYWJjNzM..."\r\n}\r\n\r\nJWT Decoded\r\nHere is the decoded value of software_statement parameter:\r\n\r\nHeader:\r\n{\r\n "alg": "RS256",\r\n "kid": "f5920d2f222b3c117cc2fd3fd1abc7367fd00402",\r\n "typ": "JWT"\r\n}\r\nPayload:\r\n{\r\n "aud": "https://your-provider.com",\r\n "auth_app_redirect_uris": [\r\n "https://vertexaisearch.cloud.google.com/oauth-redirect"\r\n ],\r\n "exp": 1766773074,\r\n "google": {\r\n "order": "xxxxxxxx-c3bc3976a8e0"\r\n },\r\n "iat": 1766772774,\r\n "iss": "https://www.googleapis.com/service_accounts/v1/metadata/x509/cloud-agentspace@system.gserviceaccount.com",\r\n "sub": "xxxxxxxx-xxxx-xxxx-xxxx-4656e5b81fe8"\r\n}\r\nDCR Response\r\n{\r\n "client_id": $CLIENT_ID,\r\n "client_secret": $CLIENT_SECRET,\r\n "client_secret_expires_at": 0\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de0880a60>)])]>

注: JWT を検証することで、リクエストが Google からのものであることを確認できます。なお、ユーザーが支払い済みであるかどうか確認するために、google.order ID とパートナー側のデータベースを照合する必要があります。

ステップ 4: Marketplace でエージェントを掲載、公開する

エージェントを構築したら、Google Cloud Marketplace で公開しましょう。そのために、エージェントの説明を記述し、提供方法と料金モデルを定義する必要があります。まず最初に、Google Cloud コンソールから Producer Portal にアクセスします。

ソリューションタイプの選択: Producer Portal で、プロダクトタイプとして [AI Agent as a Service] を選択します。
エージェントカードのアップロード: Google Cloud Storage（GCS）バケットを介して、エージェントカードの JSON ファイルを送信します。
提供方法: AI エージェントを、一般公開の料金で販売するか（セルフサービス）、プライベートオファーでのみ提供するかを決定します。
料金: 料金プランを決めて、Marketplace で収益化するための料金モデルを選択します。
技術的な統合: バックエンド側で調達を構成します。このソリューションタイプでは、フロントエンドの統合は不要です。
検証およびエンドツーエンドテスト: Google Cloud が、エージェントの機能、セキュリティ、料金モデルを確認したうえで、カタログに公開します。
公開: エージェントが正常に公開され、Google Cloud Marketplace に掲載されます。

ステップ 5: Marketplace と Gemini Enterprise app におけるトランザクション / 登録の管理

Google Cloud Marketplace と Gemini Enterprise app におけるエージェントの調達と登録のライフサイクルは、明確なフェーズに分かれています。このようなフェーズ分けは、厳格なエンタープライズガバナンスの確立、シャドー IT の防止、組織全体におけるシームレスなコンプライアンスの確保のために欠かせません。安全な管理の連鎖には、次の 3 つの主要なペルソナが介在します。課金管理者は、Google Cloud Marketplace での調達と支出を管理し、財務を監督します。Discovery Engine 管理者は、検証済みのエージェントを安全に登録するとともに、Gemini Enterprise における組織内でのアクセス権を決めるなど、技術的な「門番」の役割を果たします。Discovery Engine ユーザーは、ID に基づいて適切に認可を受けたうえで、Gemini Enterprise app 内でエージェントの全機能を安全に活用します。

1. 調達フロー: 非同期（Google Cloud Marketplace）

リスティングの公開を受け、バックエンドの調達シーケンスが次の流れで行われるようになります。

トリガー: 課金管理者の権限を持つ購入者が、 [登録] をクリックします（セルフサービス型のリスティングの場合）。または、プライベートオファーを承諾します（個別のプライベートオファーのみの場合）。
通知: Google が Pub/Sub 通知をパートナーの環境に送信します。
承認と保存: パートナーが統合した Marketplace ハンドラが、Partner Procurement API を介してアカウントと利用資格を承認します。
アクティベーション: ハンドラが、Firestore などのデータベースに一意の注文 ID を保存し、トランザクションを記録します。これにより、購入者のサブスクリプションやオファーが即座に有効になります。

上の例では、課金管理者はワンクリックで登録を済ませて、Lovable Agent の無料プランを有効にしています。これで、Cloud Marketplace からすでに調達、有効化済みの SaaS サブスクリプションと併せて、このエージェントを利用できるようになります。

2. 登録フロー: 同期（Gemini Enterprise）

調達が完了したら、購入者側の管理者が、実際の Gemini Enterprise app 環境にリンクします。

Gemini Enterprise へのリダイレクト: Discovery Engine 管理者に対して、Marketplace の調達済みリスティング上に [Gemini Enterprise に移動] オプションが表示されます。
プロジェクトの確認: このオプションをクリックすると、Gemini Enterprise ライセンスが割り当てられている Google Cloud プロジェクトにログインする画面が表示されます。なお、この Google Cloud プロジェクトが、調達時に使用した請求先アカウントにアクティブにリンクされていることを、購入者側で確認する必要があります。
DCR ハンドシェイク: Discovery Engine 管理者が、Gemini Enterprise app 内でエージェントを構成します。この段階で、動的クライアント登録（DCR）ロジックが、送られてきた JWT の注文 ID を Firestore レコードと照合、検証します。ID が一致すると、登録が安全に完了します。
エージェントの登録完了: エージェントが Gemini Enterprise に正常に登録されます。これで、Discovery Engine 管理者は、エージェントへのアクセスを特定のユーザーに与えられるようになります。

調達後、Discovery Engine 管理者が Lovable Agent を Gemini Enterprise app に登録し、組織内の承認済みユーザーが利用できるようにしています。

3. エンドユーザーの有効化フロー（Gemini Enterprise）

エージェントの登録が安全に完了すると、対象のエンタープライズユーザーがそのエージェントを見つけられるようになります。

Gemini Enterprise app 内でのエージェントの閲覧とリクエスト: エンドユーザーは、Gemini Enterprise app の Agent Gallery から、Cloud Marketplace で提供されているパートナーが構築したエージェントを閲覧し、直接アクセスをリクエストできます。このリクエストを受け、Discovery Engine 管理者が確認し、課金管理者と直接連携して、Google Cloud Marketplace からエージェントを調達できます。すでに調達、登録済みの場合は、エンドユーザーにアクセス権を付与できます。
アクセス: エージェントへのアクセス権が付与されると、アクティブな Gemini Enterprise app アカウントおよび Discovery Engine ユーザーロールおよびライセンスを持つ任意のエンドユーザーが Gemini Enterprise app 内でエージェントを呼び出せるようになります。
認証: 初回利用時に、ユーザーはパートナーシステムのユーザー名とパスワードを入力して OAuth 認証を完了するよう求められます。認証が完了すると、Gemini Enterprise app のチャットインターフェースからエージェントの全機能をシームレスに利用できるようになります。

エンドユーザーは Gemini Enterprise app 内から Lovable Agent をシームレスに呼び出し、パートナーからの 1 回限りの認証プロンプトを完了したうえで、リアルタイムの会話でタスクワークフローを始められます。

エンドユーザーが、Gemini Enterprise app の Agent Gallery から、Marketplace で公開されている別のエージェント Atlassian Rovo へのアクセスを直接リクエストしています。この例では、Marketplace からこのエージェントをすでに調達済みであるため、Discovery Engine 管理者は検証、統合を行って、アクセス権をただちに付与できます。

実際にやってみる

Gemini Enterprise および Google Cloud Marketplace 向けの AI Agent-as-a-Service ソリューションを構築することで、リーチを拡大し、数百万単位のエンタープライズユーザーの日常的なワークフローにエージェントを組み込んでもらえる可能性が広がります。

Agent Development Kit（ADK）などのツールを使用して今すぐ構築を開始してみましょう。また、エージェント主導のエンタープライズ時代に Google Cloud Marketplace で成長を加速する方法についてさらに詳しく学ぶことをおすすめします。

サポートが必要な場合は、Google Cloud Marketplace サポートチームまでお問い合わせください。

- Google Cloud、スタッフソリューションコンサルタント、Sunny Walia

- Lovable、フォワードデプロイドエンジニア、Victor Dantas

Google Cloud 向け Claude アプリゲートウェイを使ってみる

Wed, 15 Jul 2026 01:00:00 +0000

※この投稿は米国時間 2026 年 7 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。

Anthropic のエージェントコーディングツールである Claude Code が Google Cloud と連携するようになってから、しばらく経ちます。個々の開発者は簡単に、Google Cloud（GCP）プロジェクトを指すように CLAUDE_CODE_USE_VERTEX=1 を設定し、roles/aiplatform.user ロールを付与することができ、推論は Google Cloud の境界内に留まります。

このフローは、エンジニアが 1 人または数人の場合に最適です。しかし、組織全体に展開するには、企業が抱える摩擦に対処する必要があります。開発者ごとにクラウド認証情報を管理し、managed-settings.json を MDM 経由で各ノートパソコンに push する必要があり、また、ユーザーが適切に確認されないために、開発者ごとの使用状況を特定できなかったり、費用上限を簡単に適用できたりする状況にも対処する必要があります。

Claude アプリゲートウェイは、そのギャップを埋めるものです。同じ Claude バイナリが付属するセルフホスト型サービスで、ローカルの Claude Code クライアントと Google Cloud の間に直接配置されます。この投稿では、このゲートウェイを実行すべき理由と、Google Cloud での安全なデプロイの様子を詳しく説明します。

（注: 今すぐコードを参照するには、Google Cloud 上の Claude アプリゲートウェイのドキュメントで完全なチュートリアルをご覧ください。）

ゲートウェイを実行すべき理由

ゲートウェイを実行すると、開発者とプラットフォーム管理者がそれぞれ単独で行うガバナンス（ID、ポリシー、費用、ルーティングなど）を一元化できます。具体的には次のようになります。

ID: /login リクエストは、ID プロバイダ（IdP）である Google Workspace または OIDC（OpenID Connect）の ID プロバイダを経由してルーティングされ、ゲートウェイはトークンを有効期間の短いセッションに交換します。サービスアカウントキー、API キー、ANTHROPIC_VERTEX_PROJECT_ID などの機密情報が開発者のノートパソコンに保存されることはありません。オンボーディングは、ユーザーを IdP グループに追加するだけで行えます。オフボーディングも、ユーザーを削除するだけで行えて、そのユーザーの次のセッション更新は即座に失敗するようになります。

ポリシー: RBAC（ロールベースアクセス制御）ルールは gateway.yaml に一度だけ記述され、グループごとに解決されてサーバーサイドで適用されます。ゲートウェイは /v1/messages 呼び出しごとに availableModels を再チェックするため、ローカルの managed-settings.json を編集しても何も変わりません。ルールの更新は 1 時間以内にフリート全体に適用されます。

テレメトリー: すべての claude_code.token.usage 指標には、なりすましが可能な、クライアントで設定された OTEL_RESOURCE_ATTRIBUTES ではなく、セッション JWT（署名付きセッショントークン）からの確認済みのメールアドレスとグループが含まれます。ゲートウェイは、OTLP / HTTP 経由で、Cloud Monitoring、Grafana、Datadog など、ユーザーが実行するコレクタにそれらを送信します。

費用上限: 管理 API を使用して、ユーザー、グループ、組織ごとに 1 日、1 週間、または 1 か月あたりの費用上限を設定します。ゲートウェイは、Cloud SQL 台帳に対してトークンを測定し、上限に達すると 429 を返します。費用は正規料金で計算されるため、正確な請求料金の確認には使用せず、使用量の急増を防ぐためのガードレールとして使用してください（確約利用割引や交渉された料金は表示されません）。

ルーティング: 呼び出しは、単一の Cloud Run サービス ID で行われます。Agent Platform のグローバルエンドポイントに region: global を設定するか、2 つ目の upstreams: エントリを追加して、リストの順に 5xx / 429 / タイムアウトでフェイルオーバーします。どちらの場合でも、推論は GCP プロジェクト内に留まるため、割り当て、データ処理に関する契約、料金はすべて変更されません。

連携の仕組み

開発者のローカルまたはデプロイ済みの claude プロセスは、HTTPS 経由で推論トラフィックをゲートウェイに送信します。ゲートウェイは、以下に示すように Cloud Run 上のステートレスコンテナです。

ゲートウェイは独自の署名なしセッショントークンを検証し（Google Workspace にはログイン時とトークンの更新時にのみアクセスします）、ポリシーをチェックし、Cloud Run サービスアカウントを使用してリクエストを Agent Platform に転送します。Cloud SQL はデバイスコードのログイン状態と費用台帳を保持し、OTLP コレクタは特定された指標を受け取ります。

Google Cloud での設定

完全なチュートリアル、すべての gcloud コマンド、完全な gateway.yaml リファレンスは、Google Cloud 上の Claude アプリゲートウェイのドキュメントに記載されています。簡易版は次のとおりです。

ステップ 1: GCP 基盤をプロビジョニングする

Agent Platform、Cloud SQL、Secret Manager の各 API を有効にし、roles/aiplatform.user を持つ claude-gateway サービスアカウントを作成します。また、状態を保存するための小規模な Cloud SQL Postgres データベースインスタンスを立ち上げます。ゲートウェイは、Cloud Run サービス ID として Agent Platform に対する認証を行います。サービスアカウントキーは作成しません。最後に、Google Cloud コンソールで新しい OAuth クライアント（種類: ウェブアプリケーション）を作成します。この例では、ゲートウェイは Google Workspace に対して OIDC の証明書利用者として開発者の認証を行い、このクライアントはハンドシェイク用の client_id と client_secret をゲートウェイに発行します。これらの 2 つの値は、次のステップの oidc: ブロックに渡されます。承認済みのリダイレクト URI は、ゲートウェイ URL がわかってから、後で追加します。

ステップ 2: ゲートウェイを構成する

Google Workspace OIDC クライアント、Postgres 接続文字列、アップストリームとしての Agent Platform を指す gateway.yaml を記述します。このファイルを、OIDC クライアントシークレット、Postgres URL、JWT 署名鍵とともに、Secret Manager に保存します。

code_block: <ListValue: [StructValue([('code', 'listen:\r\n port: 8080\r\n public_url: https://<your-cloud-run-service-url> # the Cloud Run service URL — with --ingress=internal this resolves only inside your VPC / corporate network\r\noidc:\r\n issuer: https://accounts.google.com # Google Workspace\r\n client_id: <client-id>.apps.googleusercontent.com\r\n client_secret: ${OIDC_CLIENT_SECRET} # from Secret Manager\r\n allowed_email_domains: [yourco.com]\r\n\r\nupstreams:\r\n - provider: vertex\r\n region: us-east5\r\n project_id: <your-project>\r\n auth: {} # ADC via the Cloud Run SA, NO key file'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddbde6670>)])]>

次に、https://<public_url host>/oauth/callback を Google OAuth クライアントの承認済みリダイレクト URI として登録します。これは listen.public_url と完全に一致する必要があります。

ステップ 3: Cloud Run にデプロイする

gcloud run deploy を使用して、サービスアカウントをアタッチし、VPC 上で Cloud SQL 接続を行い、Secret Manager から構成をマウントします。コンテナはステートレスで、Cloud Run ロードバランサの背後で水平方向にスケーリングされます。GKE は、すでにプラットフォームとして使用している場合は、変わらず問題なく機能し、デプロイマニフェストのみが変更されます。

code_block: <ListValue: [StructValue([('code', 'gcloud run deploy claude-gateway \\\r\n --service-account="claude-gateway@${PROJECT_ID}.iam.gserviceaccount.com" \\\r\n --set-secrets=/etc/claude/gateway.yaml=gateway-config:latest \\\r\n --ingress=internal \\ # private — developers reach the gateway over the corporate network (VPN/Interconnect into the VPC)\r\n --no-invoker-iam-check # the gateway runs its OWN OIDC; clients carry no GCP token'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de10785b0>)])]>

開発者は企業ネットワーク経由で接続します。内部アプリケーションロードバランサを使用してサービスをフロントエンドに配置できます。Cloud Run のプライベートネットワークに関するドキュメントをご覧ください。

公開か内部かを問わず、開発者は構成した URL にアクセスできる必要があります。または、Cloud Run のデフォルトの URL を使用することもできます。以下の例では、https://claude-gateway.example.internal を使用します。

ステップ 4: 開発者をオンボーディングする

管理対象の設定を使用して、forceLoginMethod: "gateway" と forceLoginGatewayUrl を開発者のマシンに push します。これにより、手動で URL を入力しなくても、/login は接続先を把握します。組織への展開の場合は、MDM チャネルがこれに該当します。開発者は、ローカル管理者権限がある場合、MDM を使用しない最初の試行では、macOS の /Library/Application Support/ClaudeCode/managed-settings.json（または Linux の /etc/claude-code/managed-settings.json）に手動でファイルを書き込むことができます。

code_block: <ListValue: [StructValue([('code', '{\r\n "forceLoginMethod": "gateway",\r\n "forceLoginGatewayUrl": "https://claude-gateway.example.internal"\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddbad51c0>)])]>

開発者は Claude Code の起動時に、事前に入力されたゲートウェイのログイン画面で Enter キーを押して URL を確認します。ブラウザのゲートウェイの認証ページでデバイスコードを確認すると、Google Workspace にリダイレクトされるので、ログインします。その後、ブラウザで Google Workspace に対してデバイスコードフローを完了します。セットアップが正しく終了すると、以下のようにターミナルビューに Cloud Gateway が表示されます。

次のステップ

ここまでで、Google Cloud 上の Claude アプリゲートウェイを構成して使用する方法について理解を深められたはずです。おすすめする次のステップをいくつかご紹介します。

完全な構成リファレンス: すべての gateway.yaml フィールドは claude-apps-gateway-config にあります。IdP ごとの設定と GKE トラックは、claude-apps-gateway-deploy と claude-apps-gateway-on-gcp にあります。
グループスコープのポリシー: グループ対応の IdP でゲートウェイをフロントエンドに配置し、groups_claim を設定して、キャッチオールの上に match: { groups: [...] } ポリシーを追加し、チームごとに異なるモデルリストとツール権限を付与します。

今回は以上です。お読みいただきありがとうございました。ご質問やフィードバックがございましたら、ソーシャルメディア（Roy Arsan - Linkedin、X、Ivan Nardini - LinkedIn、X）でお気軽にお問い合わせください。

開発をお楽しみください。

- Anthropic、AI 応用エンジニア Roy Arsan 氏

- Google Cloud、AI エンジニア Ivan Nardini

Google AI Studio のスターターティアの解説

Fri, 10 Jul 2026 00:00:00 +0000

※この投稿は米国時間 2026 年 6 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。

あなたは Google AI Studio で実用的なプロトタイプを作成したところであると仮定しましょう。React フロントエンドに Node.js バックエンド、データベースも使っているとします。今は、チーム、ユーザー、試してみたがっている友人と共有するための一般公開 URL が必要です。

Google Cloud は、きめ細かな IAM 制御、請求管理、リージョン選択機能を備えた、本番環境アプリケーションをデプロイするための完全なプラットフォームを提供します。本格的なシステムを構築する場合は、まさにこれが必要です。一方、10 分以内にプロトタイプをオンラインで公開したいだけの場合、今ならもっと手っ取り早い方法を利用できます。

Cloud Run、Cloud Firestore、Cloud SQL for PostgreSQL、Firebase Authentication など、Google Cloud スターターティアのリソースは、フルマネージドプロジェクトでプロビジョニングされます。利用を開始するのに、お支払い方法（クレジットカードなど）や請求先アカウントは必要ありません。Google アカウントさえあれば、プロンプトの入力から一般公開 URL の取得まで、データベースや認証機能がすべて組み込まれた状態で実現できます。

スターターティアの概要

Google AI Studio でスターターティアサービスを設定すると、Google がバックグラウンドでフルマネージドプロジェクトをプロビジョニングします。ユーザー自身がプロジェクトを作成、構成、管理する必要はありません。リージョンの選択、API の有効化、セキュリティポリシーについては、Google が処理します。

スターターティアは現在、個人の Google アカウントでご利用いただけます。企業または教育機関の Google Workspace アカウントでログインしている場合、組織レベルの管理ポリシーにより、リソースをデプロイする機能が制限されることがあります。これは、各リージョンでの Google AI Studio の提供状況によっても変わります。

スターターティアは、IAM ロールの管理、API の有効化、請求先アカウントとの連携を行う標準の Google Cloud プロジェクトとは異なります。スターターティアプロジェクトは、設計上、最小限の機能しか備えていません。BigQuery や Pub/Sub を有効にすることはできません。リソースのリージョンも変更できません。これがポイントです。設定項目が少なければ少ないほど、軌道を外れる可能性も低くなります。

コンソールエクスペリエンスもこの理念に沿っています。スターターティアユーザーには、数百ものプロダクトページがある Google Cloud コンソール全体ではなく、プロトタイプにとって重要な要素（アプリケーションログ、パフォーマンス指標、基本的なコンテナ構成など）に焦点を当てたシンプルなビューが表示されます。サポート対象外のプロダクトにアクセスすると、課金対象のリソースを誤ってプロビジョニングしないよう、別個の無料トライアルを開始するよう促されます。

ご注意: スターターティアのリソースに標準の Google Cloud 利用規約は適用されません。これらはスターターティア追加利用規約の対象となります。プロトタイピングやビジネスアプリケーションで、これらの規約が障害になることはありません。

提供内容: 事前構成済みのスタック

スターターティアでは、Google Cloud カタログ全体を利用できるわけではありません。代わりに、アプリケーションアーキテクチャの要件に応じてオンデマンドでプロビジョニングされる、4 つのプロダクトの事前構成済みスタックが提供されます。

Cloud Run

Cloud Run はコンピューティングレイヤです。Google AI Studio でデプロイを行うたびに、HTTP トラフィックを処理する Cloud Run サービスが作成されます。スターターティアでは、Google アカウントごとに最大 2 つのアクティブなウェブアプリケーションを同時にデプロイできます。Cloud Run サービスは、受信トラフィックに応じて自動的にスケールし、アイドル状態になるとゼロまでスケールダウンします。つまり、使われていないときは、プロトタイプはリソースを消費しません。これらのサービスは、スターターティア環境を最初にプロビジョニングしたときに固定される、単一のリージョンで実行されます。

Firebase Authentication

アプリでユーザーログインが必要な場合、スターターティアでは Google ログインが事前構成された Firebase Authentication を利用できます。Google AI Studio の AI エージェントは、プロンプトの内容が暗にユーザー ID を必要としている場合（「共有の ToDo リストを作成して」など）、認証を自動的に有効にするよう提案します。

アプリケーションが Google Workspace のインテグレーションを基盤としている場合、このログインフローにより認証が簡素化されます。ユーザーがログインすると、アプリケーションは OAuth アクセススコープをリクエストし、Gmail、ドキュメント、カレンダー、スプレッドシートのデータを安全に操作できるようになります。これにより、要約ツールや受信トレイの整理ツールといった社内ツールのプロトタイプを簡単に作成できます。

Cloud Firestore

Cloud Firestore は、NoSQL データストレージを扱うデータベースサービスです。Google AI Studio エージェントは、プロンプトの内容から構造化データストレージが必要だと判断すると、自動的にプロビジョニングすることができます。AI エージェントは、クライアントサイドの同期コード（通常は /src/lib/firebase.ts ファイル）を生成し、アプリケーションに適した Firebase セキュリティルールのドラフトを作成します（たとえば、request.auth.uid を利用して、認証済みの作成者のみにドキュメントへのアクセスを制限します）。

「権限がない、または十分ではない」というエラーが発生した場合は、Google AI Studio で [エラーを修正] をクリックすると、更新されたアプリのロジックに合わせてエージェントがセキュリティルールを書き換えます。ただし、アプリを広く共有する前に、これらのセキュリティルールを手動でご確認ください。AI によって生成されたセキュリティルールはあくまで出発点であり、確実性を保証するものではありません。

Google AI Studio エージェントによって作成されたすべての Firestore データベースは、使用量の割り当てを共有します（詳しくは、下記の制限事項のセクションをご覧ください）。

Cloud SQL for PostgreSQL デベロッパーエディション

適切なスキーマ、結合、ACID コンプライアンスを備えたリレーショナルデータが必要な場合、スターターティアでは Cloud SQL for PostgreSQL デベロッパーエディションがプロビジョニングされます。これは、AI Studio エージェントとシームレスに連携するよう設計されています。デベロッパーエディションでは、即時のプロビジョニングとゼロへのスケーリングが可能で、迅速かつ低コストな開発環境を実現できます。また、pgvector などの機能を備えたオープンソース PostgreSQL の全機能を利用できるため、独立したベクトルデータベースを追加しなくても、セマンティック検索や RAG アプリケーションを構築できます。

プロンプトを使用してアプリケーションの改良を重ねていくと、Google AI Studio エージェントはアプリケーションの構築や公開の進行状況に合わせて、必要なスキーマの生成や移行を自動的に行います。

プロンプトの入力から一般公開 URL の取得までの 5 つのステップ

1. Google AI Studio のビルドモードを開く。Google AI Studio にアクセスし、ビルドモードに切り替えます。お支払い方法の登録もプロジェクトの設定も不要です。

2. アプリの説明を入力する。「Firebase をバックエンドとして使用する共有 ToDo リストアプリを作成して」のようなプロンプトを入力します。エージェントが React フロントエンドと Node.js バックエンドを生成し、画面の右側にライブプレビューを表示します。

3. Firebase を有効にする（メッセージが表示された場合）。プロンプトにユーザーデータや認証に関する内容が含まれていた場合、エージェントは Firebase を有効にするための構成カードを表示します。設定アイコンをクリックしてリージョンを選択し（これにより Cloud Run のリージョンも固定されます）、確認します。

4. [公開] > [使ってみる] > [アプリを公開] をクリックする。エージェントがコードをパッケージ化し、スターターティアプロジェクトに Cloud Run サービスをプロビジョニングします。

5. URL を取得する。数秒で一般公開の .run.app URL を取得できます。アプリケーションの状況は、デプロイ済みコンテナのログと指標を表示する、簡素化された Google Cloud コンソール画面からモニタリングできます。

以上です。Dockerfile も gcloud も YAML 構成ファイルも必要ありません。

スターターティアとの比較

Google Cloud には、無料で利用できる方法がいくつか用意されています。スターターティアと、新規ユーザーにとって最も一般的な利用開始方法である無料トライアルとの比較は、以下のとおりです。

	スターターティア	無料トライアル
提供内容	4 つのプロダクトを含む事前構成済みスタック（割り当てに上限あり）: Cloud Run Firestore Cloud SQL Firebase Authentication	$300 分のウェルカムクレジット Google Cloud の無料枠その他のプロダクト固有の無料トライアル料金が発生するリスクのない、90 日間の無料体験期間
必要なご対応	Google アカウントの登録スターターティア利用規約への同意	Google Cloud 利用規約への同意不正対策を目的とした、お支払い方法のご提供
時間制限	なし	90 日
プロジェクトの管理	Google が管理	ユーザーがすべてを管理
コンソールエクスペリエンス	シンプル	フル
最適な用途	AI Studio からのプロトタイピング	Google Cloud Platform 全体の評価
さらにご利用をご希望の場合	お支払い方法を追加して、有料アカウントにアップグレードしてください。請求先アカウントを初めて作成する場合は、$300 分のウェルカムクレジットと無料枠をご利用いただけます。アップグレード後は、無料枠と $300 のクレジットでカバーできない使用量に対して請求が発生します。	既存のプロジェクト、残っているクレジット、無料枠、プラットフォームへのフルアクセスを維持するには、有料の請求先アカウントにアップグレードしてください。アップグレード後は、無料枠と残っているクレジットでカバーできない使用量に対して請求が発生します。

スターターティアは、AI Studio でのプロトタイピングに最適です。BigQuery、GKE、Gemini Enterprise Agent Platform が必要な場合や、課金されるリスクなく 90 日間 GCP を幅広く評価したい場合は、無料トライアルをお選びください。どちらのコースでも、準備が整い次第、有料アカウントにシームレスにアップグレードして、すべての機能をご利用いただけます。

制限に備える

スターターティアはプロトタイピングには十分ですが、制限もあります。事前に把握しておけば、予期せぬトラブルを回避できます。

アプリケーションは 2 つまで。デプロイできるアプリケーションは最大 2 つです。アクティブなアプリケーションのいずれかを置き換える場合は、Cloud コンソールでサービスを手動で削除しようとせず、Google AI Studio で既存のアプリスロットにデプロイまたは上書きしてください。

リージョンは 1 つ。スターターティアプロジェクトのリソースはすべて、最初にスターターティアサービスをプロビジョニングしたときに選択した、1 つのリージョンに固定されます。たとえば、Cloud Run にデプロイする前に Firestore データベースをプロビジョニングすると、その時点でリージョンが選択されます。

API サーフェスは固定。スターターティアプロジェクトでは、追加の Google Cloud API（BigQuery、Pub/Sub、Cloud Functions など）を有効にすることはできません。これらが必要な場合は、アップグレードしていただく必要があります。

エフェメラルファイルシステム。公開された Google AI Studio アプリはサーバーレスの Cloud Run コンテナ内で実行されるため、一時的なファイルシステムを継承します。ディスクに直接書き込まれるファイル（アップロードされた画像、生成された PDF、ローカルの SQLite データベースなど）は、コンテナがゼロにスケールされるか、再デプロイされると消滅します。Google AI Studio はプロンプトのイテレーションごとにコンテナを再デプロイするため、この状況は頻繁に発生します。永続データは Firestore または Cloud SQL for PostgreSQL に保存してください。

Firestore の共有割り当て。Google AI Studio エージェントによって作成されたすべての Firestore データベースは、単一の共有割り当てグループを共有します。Google Cloud において、割り当ては、プロジェクトを保護し、不正使用を防ぐことを目的とする、使用量上限または 1 日の予算を表します。サーバー容量が確保されることを保証するものではありません。

割り当て指標	スターターティアの上限
合計保存データ	合計 1 GiB
外向きネットワーク	10 GiB/月
書き込みオペレーション	40,000 回/日
読み取りオペレーション	50,000 回/日
リアルタイム更新	50,000 回/日

グループ内のいずれかのデータベースが 1 日の使用量上限に達すると、そのグループ内のすべてのデータベースは、太平洋時間の午前 0 時頃まで一時停止されます。Firebase Authentication の使用量は個別に測定されるため、ログインが急増してもデータベースの割り当てが減ることはありません。

Cloud SQL の割り当ての共有: Cloud SQL で構築できるアプリは最大 2 つに制限されています。Cloud SQL の割り当てを超過した場合、AI Studio エージェントは自動的に Firestore にフォールバックします。サンドボックスから移行することで、割り当てを増やすことができます。

サンドボックスからの移行

スターターティアの最大の魅力は、そのアップグレード方法です。移行も、データエクスポートも、DNS の切り替えも不要です。スケーリングの準備ができたら、そのままアップグレードできます。

Google AI Studio の [プロジェクト] ページで、[お支払い情報を設定] をクリックします。Cloud 請求先アカウントを作成し、お支払い方法を入力して、Google Cloud の標準利用規約に同意します。Google Cloud を初めてご利用のお客様には、自動的に $300 分のウェルカムクレジットが提供され、トライアル期間中の使用料金に充当されます。アップグレードはダウンタイムなしで実行されます。Cloud Run サービスは稼働し続け、データベースはデータを保持し、.run.app URL は変更されません。

アップグレード後は、IAM を完全に制御できるようになり、任意の Google Cloud API の有効化や、すべてのリージョンとスケーリングオプションの利用が可能になります。以下のようなコスト対策が推奨されています。

予算アラートを設定する: Google Cloud Billing コンソールにアクセスし、使用量が予想（例: $10）を超えると通知するよう、予算アラートを設定します。
Cloud Run のインスタンス数の上限を設定する: スターターティアでは、Google によってコンテナインスタンスの最大数が 1 に固定されています。アップグレードしたら、トラフィックの急増による予期しないスケーリング料金が発生しないよう、インスタンス数の上限を設定（例: --max-instances 5）します。
API の割り当てを設定する: API の呼び出し（Gemini API や Firestore の読み取り / 書き込みなど）に上限を設定し、厳格な制限を使用量に適用します。

ご注意: Google AI Studio エージェントによって作成された Firestore データベースは、請求先を追加した後も共有割り当てグループに残っています。データベースの使用量割り当てを増やすには、Firebase コンソールにアクセスし、Firestore データベースに移動して [データベースをアップグレード] をクリックします。これにより、インスタンスが共有割り当てグループから削除され、標準の請求が適用されるようになります。ただし、課金される前に標準の Firestore 無料枠の上限が適用されます。

パス全体にわたる連続性により、このプロセスはスムーズに進みます。スターターティアでプロトタイプを作成し、数週間かけて改良を重ね、準備が整ったら、何も再構築することなく本番環境グレードの Google Cloud プロジェクトに移行できます。

スターターティアについてご質問がある方や、これを使って構築したものを伝えたい方は、ぜひ私にご連絡ください。また、サブレディットの r/GoogleCloud と r/Firebase では、コミュニティと意見を共有できます。

- デベロッパーリレーションズ担当ディレクター、Karl Weinmeister

Cloud Network Insights: クロスクラウドネットワークに対するエンドツーエンドのオブザーバビリティ

Fri, 03 Jul 2026 03:00:00 +0000

※この投稿は米国時間 2026 年 6 月 18 日に、Google Cloud blog に投稿されたものの抄訳です。

昨今のデジタル環境では、ネットワークは単一のデータセンターや一つのクラウドプロバイダの範囲に制限されません。クロスクラウド戦略を採用し、Google Cloud ワークロードをオンプレミス環境、AWS や Azure などの他のクラウド、インターネットに接続されたさまざまなアプリケーションに接続させる企業が増えています。この柔軟性はイノベーションを促進する一方で、運用上の複雑さを大幅に増大させる可能性もあります。アプリケーションのパフォーマンスが低下した場合、原因はネットワーク、アプリケーション、それとも他のどこにあるのかという重要な疑問が生じます。

このたび、Cloud Network Insights の一般提供が開始されました。すぐに使用できる Google Cloud ネイティブのソリューションである Cloud Network Insights は、複雑なマルチクラウド環境とハイブリッド環境全体でネットワークとデジタルエクスペリエンスのパフォーマンスを包括的に可視化します。

アクティブなモニタリングで可視性のギャップを解消

Broadcom AppNeta とのパートナーシップにより提供される Cloud Network Insights は、オブザーバビリティを Google Cloud の枠を超えてグローバルなデプロイ全体に拡大します。アクティブな合成プローブの利用によりユーザートラフィックがない場合でもネットワークルートをモニタリングできるため、事後対応ではなく予防的なモニタリングを可能にします。

クラウド、オンプレミスのデータセンター、インターネットアプリケーション、ISP、ラストマイル接続など、パフォーマンス低下の原因がどこにあるとしても、Cloud Network Insights を使用すればボトルネックの正確な場所を特定できます。

Cloud Network Insights は Google Cloud Observability スイートに直接統合されるため、高度なネットワークインテリジェンスを既存のツールに組み込むことができます。Cloud Network Insights は、次の機能を提供します。

エンドツーエンドのネットワークパスの可視性: 送信元と宛先の間のネットワークパスをホップバイホップ方式で可視化します。直接管理していないネットワークにおけるラウンドトリップ時間（RTT）、パケットロス、ジッターなどの重要な指標をモニタリングします。
デジタルエクスペリエンスに関する分析情報: ネットワーク層を超えて、ウェブアプリケーションのデジタルエクスペリエンスをモニタリングします。DNS の解決時間、HTTP レスポンスコード、ブラウザのページ全体の読み込み時間を測定して、アプリケーションのパフォーマンス低下がネットワークによるものか、アプリケーション自体によるものかを特定します。
プロアクティブな検出とアラート: シンセティックテストを使用して、顧客に影響が及ぶ前にパフォーマンスの低下を特定します。アラームは Cloud Monitoring および Cloud Logging と統合されており、メール、Slack、PagerDuty 経由でアラートを送信できます。
SLA の検証: ISP やサービスプロバイダがパフォーマンスのコミットメントを満たしているかを検証するのに必要なデータをチームに提供します。
迅速な根本原因分析: ネットワークの問題、アプリケーションレベルの問題、ブラウザのパフォーマンスへの影響をすばやく区別できます。
統合モニタリング: Google Cloud 内から直接指標とログにアクセスし、Cloud Monitoring と Cloud Logging を活用してダッシュボードとアラートを提供します。Google Cloud のオープンなパートナーエコシステムと、指標とログに利用される OpenTelemetry プロトコルのサポートを利用して、OTel SDK とコレクタによる直接取り込みを可能にします。
エージェントワークロードのモニタリング: シンセティックテストを使用して、接続とネットワークパフォーマンスをモニタリングし、エージェントとツールへの接続を最適化します。

Google Cloud、AWS、Azure との間のネットワークパフォーマンスとマルチパスルートを 1 つのビューで確認

仕組み: アクティブな合成プロービング

Cloud Network Insights は、3 つの主要コンポーネントで構成されるアクティブな合成プローブ技術を使用します。

モニタリングポイント: モニタリングポイントと呼ばれる軽量のソフトウェアエージェントを、中央 VPC、リモートブランチ、オンプレミスデータセンターなどの重要なネットワークセグメントにデプロイします。モニタリングポイントはコンテナまたは仮想マシンとしてデプロイできます。
合成プローブ: モニタリングポイントは、合成トラフィック（ユーザーまたはアプリケーションをシミュレート）の小さなバーストを頻繁にターゲットの宛先に送信します。これにより、ネットワーク上にユーザーが存在しない場合でも、24 時間 365 日パフォーマンスをモニタリングできます。
データ同期: モニタリングポイントは、リアルタイムのパフォーマンステレメトリーを中央のバックエンドサービスに送信します。このデータは Google Cloud に同期され、指標は Cloud Monitoring にエクスポートされ、アラームとイベントは Cloud Logging に送信されます。

核となる機能

Cloud Network Insights は、インフラストラクチャの全体像を把握するために、主に次の 2 種類のモニタリングをサポートしています。

1. ネットワークパフォーマンスのモニタリング（レイヤ 3 と 4）

これにより、送信元と宛先の間のネットワークをホップバイホップ方式で可視化できます。

取得される指標: ラウンドトリップ時間（RTT）、パケットロス、ジッター、パスの変更。
シングルエンドモード: エージェントは、モニタリングポイントがインストールされていない外部ターゲット（URL、IP アドレス、API エンドポイントなど）をプローブします。
デュアルエンドモード: モニタリングポイントが別のモニタリングポイントをプローブします。これにより、一方向のレイテンシの正確な把握と非対称ルーティング（データが送信時と受信時で異なるパスを通る場合）の検出が可能になり、より豊富なデータが提供されます。

Google Cloud コンソールに表示されたネットワークパス指標

2. デジタルエクスペリエンスモニタリング（レイヤ 7）

デジタルエクスペリエンスモニタリングを使用すると、ウェブアプリケーションのエンドツーエンドのエクスペリエンスを追跡できます。ここでは、次のいずれかを選択できます。

ブラウザモード: 実際のブラウザエンジン（Selenium）を使用してウェブページ全体を読み込み、JavaScript を実行してコンテンツをレンダリングします。ページの読み込み時間を完全に測定し、実際のユーザーエクスペリエンスを検証します。
HTTP モード: 合成 HTTP/S リクエストを URL または API エンドポイントに送信します。これにより、サーバーの可用性、レスポンス時間、DNS / TLS パフォーマンスの軽量なチェックを行います。

インテリジェンスと自動化

Cloud Network Insights には、さまざまなモニタリング機能とトラブルシューティング機能も用意されています。

プロアクティブなアラーム: Cloud Network Insights は自動ベースライン設定を利用し、過去の指標データに基づいてパフォーマンスしきい値を動的に設定します。定義されたパラメータから指標が逸脱すると、システムは Google Cloud でイベントを即座にトリガーし、メール、Slack、PagerDuty を介してアラートをチームに直接ルーティングします。
モニタリングポリシー: カスタムタグに基づいてパスを動的に作成または削除するポリシーを定義することで、大規模な環境全体でモニタリング設定を自動化できます。たとえば、主要なウェブアプリケーションのパフォーマンスを特定の地理的地域から自動で追跡できます。
根本原因分析: Cloud Network Insights は、ISP やトランジットネットワークなど、従来は「監視対象外」だった領域まで可視性を拡張するため、速度低下が Google Cloud 内で発生しているのか、ISP レベルで発生しているのか、AWS や Azure などの別のクラウド環境内で発生しているのかを即座に特定できます。
AI による分析情報: Gemini Cloud Assist との統合により、自然言語を使用して、より広範なインフラストラクチャデータとともに Cloud Network Insights テレメトリーを調査できます。ダッシュボードを手動で切り替えるのではなく、Gemini に Cloud Network Insights の特定の指標と他の Google Cloud の指標を相互参照させることで、平均解決時間（MTTR）を短縮します。

お客様の声

Cloud Network Insights に対しては、クロスクラウド運用を簡素化したいと考えているお客様からすでに大きな関心が寄せられています。すでに Sabre や Pexip などの組織は、ハイブリッド環境の透明性を高める目的で Cloud Network Insights を活用しています。

「Sabre のように複雑かつハイスケールな環境では、完全な可視性は単なる贅沢品ではなく、運用のレジリエンスを確保するための不可欠な要件です。Cloud Network Insights を使用することで、プロアクティブな最適化をさらに推進できます。グローバルなクラウドフットプリント全体にわたってきめ細かいリアルタイムのテレメトリーを提供することで、従来のネットワークの『ブラックボックス』を解消し、旅行者のエクスペリエンスに影響を与える前にチームがボトルネックを解決することを可能にします。」- Sabre、クラウドおよびインフラストラクチャ担当バイスプレジデント、Alfredo Rodriguez 氏

「Cloud Network Insights は、企業のプライベートネットワークとパブリッククラウドとの間の『可視性のギャップ』を埋め、共通のお客様がパフォーマンスのボトルネックを数時間ではなく数秒単位で特定することを可能にします。」- Broadcom、CIO、Alan Davidson 氏

Cloud Network Insights でネットワークの健全性を向上させた Pexip

使ってみる

複雑なデジタルエコシステムに対応するために可視性を犠牲にする必要はありません。Cloud Network Insights は、詳細なネットワークパフォーマンス指標とデジタルエクスペリエンスモニタリングを組み合わせることで、マルチクラウド環境とハイブリッド環境のギャップを埋めます。Google Cloud Observability と Gemini Cloud Assist に直接統合されているため、チームはインテリジェントなアラート、堅牢な SLA 検証、迅速な根本原因分析を利用できます。Google は、お客様がクロスクラウドネットワークの全体像をより明確に把握できるよう今後も支援を続けていきます。

Google Cloud コンソールで今すぐご利用いただけます。詳しくは、以下の資料をご参照ください。

モニタリングポイントのデプロイとポリシーの構成について詳しくは、プロダクトドキュメントをご覧ください。
最新のリリースノートで新機能に関する最新情報を確認できます。
概要動画を見る
Google Cloud と Broadcom のパートナーシップについて詳しくは、以下をご覧ください。

- プロダクトマネージャー、Poonam Yadav

お客様とのコラボレーションが切り拓く、Model Armor による生成 AI セキュリティの未来

Fri, 03 Jul 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 6 月 16 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud では、最高のプロダクトはお客様とのパートナーシップを通して構築されると考えています。お客様からのフィードバックや実際の経験は、Google のサービスを改良し、お客様の実際のニーズを満たすソリューションを提供するうえで非常に貴重です。2026 年 1 月、Google Cloud デベロッパーアドボカシーチームは、Google Cloud の大手顧客であり、通信業界のリーダーでもある企業との高ベロシティな技術スプリントに参加しました。

この共同作業を通じて得られた深いインサイトは、生成 AI およびエージェント AI 向けランタイムセキュリティサービスである Model Armor の情報エクスペリエンスを大幅に向上させる原動力となりました。

「徹底した当事者意識」による生成 AI 導入の加速

この取り組みの目的は、Google Cloud の Agent Development Kit（ADK）と Agent Platform を使用して構築された、次世代の生成 AI カスタマーサポートプラットフォームの運用化を支援することでした。お客様の開発者やセキュリティスペシャリストと直接対話することで、開発者が複雑なライブ環境で Gemini Enterprise Agent Platform をどのように操作しているかを観察するという貴重な機会を得ることができました。

この経験は、従来のドキュメント作成サイクルからは決して得られない、徹底した当事者意識をもたらしました。開発者が作業する際の摩擦ポイントを一つひとつ記録していくことで、機能的障害をリアルタイムの技術的インサイトへと変換し、曖昧な構成ガイダンスや詳細情報の欠如によって開発者が作業を妨げられている部分を正確に特定しました。

現場で得られた重要な知見

開発ワークフローを直接見せていただくことで、4 つの重要な摩擦ポイントを特定できました。

検索ファーストのワークフロー: 開発者がドキュメントの階層構造を順に辿ることは稀です。それよりも検索を駆使して、目的のコード例へ直接ジャンプすることがほとんどです。PII の秘匿化など、一般的なユースケースに対応する包括的でコピー＆ペースト可能なスニペットがないことが主な摩擦ポイントとなっていました。
信頼レベルの最適化: 包括的な脅威検出と、業務の妨げとなる誤検出の抑制との適切なバランスを見出すことは、想像以上に困難でした。たとえば、「低以上」といった厳格な設定を適用すると、本来スムーズであるべきカスタマーサポートの流れを止めてしまうような誤検出が頻発する結果となりました。
きめ細やかなガイダンスの必要性: Model Armor の基本コンセプトは理解されているものの、セキュリティと利便性を両立させるためのさまざまな適用方法が実務レベルでどう機能するのかに関する、より具体的な詳細情報が必要とされていることがわかりました。
インテグレーションを阻む壁（403 エラー）: Model Armor を Apigee などのサービスと連携させる際、開発者は 403 PERMISSION_DENIED エラーという壁に何度も突き当たっていました。これは、既存ドキュメントにサービスをまたぐ IAM ロールや権限の設定に関する説明が不足していたことを浮き彫りにしました。

知見を実践的に活用

このパートナーシップから得られた知見は、Model Armor のドキュメントとガイダンスの包括的な見直しにすぐに活かされました。

テスト済みのコピー＆ペースト可能なコードサンプル: 検索ファーストのワークフローに対応するため、ドキュメント全体にテスト済みのすぐに使用できるコードサンプルを多数追加しました。
信頼レベルのマトリックス: フィルタレベルごとのトレードオフをユーザーが直感的に把握できるよう、新たな技術リファレンスを追加しました。一般的なコンテンツについては、誤検出を最小限に抑えるために「高」または「中」のしきい値が推奨されることを明記しました。一方、「低以上」の設定は、プロンプトインジェクションやジェイルブレイク検出などの重大なセキュリティ脅威に限定して使用することを推奨しています。
明示的なインテグレーションガイド: Apigee、Gemini Enterprise Agent Platform、GKE に焦点を当ててインテグレーションガイドを更新しました。新しいガイドでは、スムーズでエラーのないデプロイにするために必要な特定の IAM ロール（roles/modelarmor.user など）が明示されています。
技術ドキュメントの拡充: 適用方法と現実世界におけるその応用例について、より深く踏み込んだ解説を追加してドキュメントを強化しました。

パートナーシップの力

今回は実際にお客様と「同じ部屋で過ごす」ことで、技術的な正確さと運用上の有用性のギャップを埋めることができました。こうした共創の取り組みにより、Model Armor はお客様の成功を後押しする確かな原動力へと進化していきます。更新されたドキュメントをぜひご覧いただき、皆様のフィードバックをお寄せください。生成 AI ワークロード向けの最も安全なプラットフォームを目指して、Google はこれからも進化を続けてまいります。

使ってみる:

更新された Model Armor ドキュメントを確認する

- Google Cloud、テクニカルライター Darshana Bhangare

- シニアデベロッパーリレーションズエンジニア、Leonid Yankulin

30 分でリモート MCP サーバーの構築と GKE へのデプロイを実行

Thu, 02 Jul 2026 02:40:00 +0000

※この投稿は米国時間 2026 年 6 月 17 日に、Google Cloud blog に投稿されたものの抄訳です。

30 分でリモート MCP サーバーを構築して GKE にデプロイする

ツールやデータソースのコンテキストを LLM に統合するのは簡単なことではなく、この点が AI エージェントの開発を難しくしています。この課題に対処するために、Anthropic は Model Context Protocol（MCP）を発表しました。これは、アプリケーションが LLM にコンテキストを提供する方法を標準化するプロトコルです。デベロッパーは、自分たちが開発した API をコンテキストとして他のデベロッパーのアプリケーションで利用してもらえるよう、専用の MCP サーバーを構築したいと考えることがよくあります。Google Kubernetes Engine（GKE）は、これらのリモート MCP サーバーをデプロイするためのスケーラブルで信頼性が高く安全な環境を提供します。

このガイドでは、GKE で安全なリモート MCP サーバーを簡単に設定する手順を示します。

MCP トランスポート

Model Context Protocol は、クライアント / サーバーアーキテクチャを採用しています。当初は、stdio トランスポートを使用したローカルでのサーバー実行のみをサポートしていました。その後の進化により、リモートアクセストランスポート、具体的には Streamable HTTP をサポートするようになりました。

Streamable HTTP を使用すると、サーバーは複数のクライアント接続を処理できる独立したプロセスとして動作します。このトランスポートは、HTTP の POST リクエストと GET リクエストを使用します。サーバーは、POST メソッドと GET メソッドの両方をサポートする単一の HTTP エンドポイントパス（https://example.com/mcp など）を提供する必要があります。トランスポートについて詳しくは、公式ドキュメントをご覧ください。

GKE で MCP サーバーを実行するメリット

GKE 上に構築した MCP サーバーをリモートで実行することには、次のようなアーキテクチャ上のメリットがあります。

スケーラビリティ: GKE Autopilot は、変動の大きいトラフィックを処理できるように構築されています。MCP サーバーのステートレスな性質から、GKE は水平スケーリングによって需要の急増に効率的に対応できます。
一元化されたアクセス: チームは一元化された MCP サーバーへのアクセスを共有できます。ローカルマシン、エージェント、またはパイプラインからサーバーに接続できるため、冗長化したローカルサーバーを実行する必要がなくなります。中央サーバーが更新されると、即座にすべてのユーザーに共有されます。
セキュリティの強化: Kubernetes Gateway API と SSL 証明書を組み合わせることで、トラフィックの安全な暗号化を簡単に強制できます。これにより、MCP サーバーへの安全な接続のみを許可し、不正アクセスを防止することができます。

前提条件

始める前に、次のツールがインストールされていることを確認してください。

Python 3.10 以降
uv（パッケージとプロジェクトの管理については、インストールに関するドキュメントをご覧ください）
Google Cloud SDK（gcloud）
kubectl コマンドラインツール

インストール

環境変数を準備します。

code_block: <ListValue: [StructValue([('code', 'export PROJECT_ID=$(gcloud config get-value project)\r\nexport REGION=us-central1'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de098d1f0>)])]>

サーバーとデプロイのコードを保存するため、mcp-on-gke という名称のフォルダを作成します。

code_block: <ListValue: [StructValue([('code', 'mkdir mcp-on-gke && cd mcp-on-gke'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de098da30>)])]>

次に、Google Cloud の認証情報を構成し、アクティブなプロジェクトを設定します。

code_block: <ListValue: [StructValue([('code', 'gcloud auth login\r\ngcloud config set project $PROJECT_ID'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de098ddc0>)])]>

GKE Autopilot クラスタの作成をバックグラウンドで開始します。このプロセスには数分かかるため、この段階で開始することで、残りの設定を完了させる間にクラスタをプロビジョニングできます。高速自動スケーリングに対してコスト最適化コンピューティング（CCOP）が有効になっている Autopilot バージョンを使用してください。

code_block: <ListValue: [StructValue([('code', 'gcloud container clusters create-auto mcp-cluster \\\r\n --region $REGION \\\r\n --release-channel rapid \\\r\n --async'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de098d5e0>)])]>

uv を使用してプロジェクトを作成します。これにより、pyproject.toml ファイルが生成されます。

code_block: <ListValue: [StructValue([('code', 'uv init'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de098d520>)])]>

次に、必要な追加ファイルとして、server.py（MCP サーバーコード用）、test_server.py（テスト用）、Dockerfile（コンテナのデプロイ用）を作成します。

数学 MCP サーバー

大規模言語モデルは、テキストの生成、アイデアの要約、コンセプトの推論など、非決定的なタスクに優れている一方、数学演算のような決定的なタスクでは信頼性に欠けるという欠点があります。これを解決するために、デベロッパーは重要なコンテキストを提供するツールを作成できます。Python で MCP サーバーを構築するためのフレームワークである FastMCP を使用すると、加算と減算の 2 つのツールを備えた単純な数学サーバーを作成できます。

まず、FastMCP を依存関係として追加します。

code_block: <ListValue: [StructValue([('code', 'uv add fastmcp\r\nuv add asyncio'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de098d610>)])]>

次のコードを server.py にコピーして、サーバーを作成します。

code_block: <ListValue: [StructValue([('code', 'from fastmcp import FastMCP\r\nfrom starlette.requests import Request\r\nfrom starlette.responses import PlainTextResponse\r\nimport asyncio\r\nimport logging\r\n\u200b\r\nlogger = logging.getLogger(__name__)\r\nlogging.basicConfig(format="[%(levelname)s]: %(message)s", level=logging.INFO)\r\n\u200b\r\nmcp_port=3000\r\n\u200b\r\n# FastMCP サーバーを初期化します\r\nserver = FastMCP(\r\n "Math Server",\r\n)\r\n\u200b\r\n@server.tool()\r\ndef add(a: int, b: int) -> int:\r\n """2 つの数値を合算します。"""\r\n return a + b\r\n\u200b\r\n@server.tool()\r\ndef subtract(a: int, b: int) -> int:\r\n """最初の数値から 2 つ目の数値を引きます。"""\r\n return a - b\r\n\u200b\r\n@server.custom_route("/healthz", methods=["GET"])\r\nasync def health_check(request: Request) -> PlainTextResponse:\r\n """200 OK をレスポンスとして返すシンプルなヘルスチェックエンドポイント"""\r\n return PlainTextResponse("OK")\r\n\u200b\r\nif __name__ == "__main__":\r\n logger.info(f" MCP server started on port {mcp_port}")\r\n # Cloud Run では、\'sse\' トランスポート、host="0.0.0.0" も使用できます。\r\n asyncio.run(\r\n server.run_async(\r\n transport="streamable-http",\r\n host="0.0.0.0",\r\n port=mcp_port\r\n )\r\n )'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f9de098db80>)])]>

この例では、リモートサーバーの推奨プロトコルである streamable-http トランスポートを使用しています。このスクリプトは、スケーラブルな MCP エンドポイントの実行に必要なロジックをカプセル化します。

MCP サーバーをローカルでテストする

MCP サーバーをテストするために接続する test_mcp_server.py スクリプトを作成します。GKE へのデプロイ前に MCP サーバーをテストするのに役立ちます。

code_block: <ListValue: [StructValue([('code', 'from fastmcp import Client, FastMCP\r\nimport asyncio\r\nimport logging\r\n\u200b\r\n# リモートの MCP サーバーに接続します\r\nclient = Client("https://localhost:3000/mcp")\r\n\u200b\r\nasync def test_remote_server():\r\n async with client:\r\n # 基本的なサーバーとのやり取り\r\n await client.ping()\r\n\u200b\r\n # 利用可能な操作をリストアップします\r\n tools = await client.list_tools()\r\n print(f"利用可能なツール: {tools} \\n")\r\n\u200b\r\n # 加算の操作を実行します\r\n result = await client.call_tool("add", {"a": 5, "b": 3})\r\n print(f"加算の結果: {result} \\n")\r\n\u200b\r\n # 減算の操作を実行します\r\n result = await client.call_tool("subtract", {"a": 5, "b": 3})\r\n print(f"減算の結果: {result} \\n")\r\n\u200b\r\nif __name__ == "__main__":\r\n asyncio.run(test_remote_server())'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f9de098dfa0>)])]>

MCP サーバーをローカルで実行して接続をテストする:

code_block: <ListValue: [StructValue([('code', 'uv run server.py'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de098d790>)])]>

次に、新しいターミナルでテストスクリプトを実行して、接続を確認します。

code_block: <ListValue: [StructValue([('code', 'uv run test_mcp_server.py'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de098d9a0>)])]>

出力には利用可能なツールおよび add ツールと subtract ツールを呼び出した結果が表示され、MCP サーバーが機能しているかを確認できます。

コンテナイメージのビルド

デプロイプロセスを高速化するために、クラスタの作成中にコンテナイメージをビルドします。

まず、Dockerfile を準備します。

code_block: <ListValue: [StructValue([('code', 'FROM python:3.10-slim\r\nCOPY --from=ghcr.io/astral-sh/uv:0.4.15 /uv /bin/uv\r\nWORKDIR /app\r\nCOPY pyproject.toml .\r\nCOPY server.py .\r\nRUN uv sync\r\nCMD ["uv", "run", "server.py"]'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de098ddf0>)])]>

次に、Artifact Registry を設定し、コンテナイメージをビルドします。

Artifact Registry を設定する

code_block: <ListValue: [StructValue([('code', 'gcloud artifacts repositories create mcp-repo \r\n--repository-format=docker \r\n--location=$REGION'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddbd0da30>)])]>

イメージのビルドと push を並列で実行する

code_block: <ListValue: [StructValue([('code', 'gcloud builds submit --tag $REGION-docker.pkg.dev/$PROJECT_ID/mcp-repo/math-mcp-server:latest'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddbd0dca0>)])]>

イメージのビルドが完了したら、クラスタが準備できていることを確認し、認証情報を取得します。クラスタの出力が「RUNNING」でない場合は、準備が整うまで待ちます。

code_block: <ListValue: [StructValue([('code', 'gcloud container clusters list\r\ngcloud container clusters get-credentials mcp-cluster --region $REGION'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddbd0d610>)])]>

Gateway API と SSL を使用して GKE にデプロイする

次のステップでは、サーバーワークロードをデプロイし、従来の Ingress ではなく Kubernetes Gateway API を使用して安全に公開します。これにより、SSL 証明書を介した安全な暗号化トラフィックが担保されます。

Kubernetes Deployment と Kubernetes Service を定義する deployment.yaml ファイルを作成します。プレースホルダを実際のプロジェクト ID とリージョンに置き換えます。

code_block: <ListValue: [StructValue([('code', 'apiVersion: apps/v1\r\nkind: Deployment\r\nmetadata:\r\n name: mcp-server\r\nspec:\r\n replicas: 2\r\n selector:\r\n matchLabels:\r\n app: mcp-server\r\n template:\r\n metadata:\r\n labels:\r\n app: mcp-server\r\n spec:\r\n containers:\r\n - name: mcp-server\r\n image: $REGION-docker.pkg.dev/$PROJECT_ID/mcp-repo/math-mcp-server:latest\r\n ports:\r\n - containerPort: 3000\r\n resources:\r\n requests:\r\n memory: "256Mi"\r\n cpu: "250m"\r\n limits:\r\n memory: "512Mi"\r\n cpu: "500m"\r\n livenessProbe:\r\n httpGet:\r\n path: /healthz\r\n port: 3000\r\n initialDelaySeconds: 15\r\n periodSeconds: 20\r\n readinessProbe:\r\n httpGet:\r\n path: /healthz\r\n port: 3000\r\n initialDelaySeconds: 5\r\n periodSeconds: 10\r\n---\r\napiVersion: v1\r\nkind: Service\r\nmetadata:\r\n name: mcp-service\r\nspec:\r\n selector:\r\n app: mcp-server\r\n ports:\r\n - port: 80\r\n targetPort: 3000'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddbd0d580>)])]>

この構成をクラスタに適用します。

code_block: <ListValue: [StructValue([('code', 'kubectl apply -f deployment.yaml'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddbd0da60>)])]>

Pod が稼働していることを確認します。

code_block: <ListValue: [StructValue([('code', 'kubectl get pods'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddbd0d700>)])]>

リモート MCP サーバーにアクセスできることを確認するために、ポート転送でサーバーにアクセスします。

code_block: <ListValue: [StructValue([('code', 'kubectl port-forward svc/mcp-service 8080:80'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddbd0d520>)])]>

テストスクリプトを実行して接続を確認します。テストスクリプトの MCP サーバー URL を http://localhost:8080/mcp に編集してください。

code_block: <ListValue: [StructValue([('code', 'uv run test_mcp_server.py'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddbd0d9a0>)])]>

次に、接続を保護します。これを行うには、Google マネージド SSL 証明書を Gateway API リソースにアタッチします。まず、ロードバランサ用の静的 IP アドレスを予約します。

code_block: <ListValue: [StructValue([('code', 'gcloud compute addresses create mcp-server-ip --global\r\nexport MCP_SERVER_IP=$(gcloud compute addresses describe mcp-server-ip --global --format="value(address)")\r\necho "Your IP: $MCP_SERVER_IP"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddbd0d670>)])]>

ドメインの DNS A レコードを $MCP_SERVER_IP に向けます。例: mcp.yourdomain.com

Google マネージド証明書を作成します。mcp.yourdomain.com は実際のドメインに置き換えてください。

code_block: <ListValue: [StructValue([('code', 'gcloud compute ssl-certificates create mcp-cert --domains mcp.yourdomain.com --global'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddbd0d760>)])]>

gateway.yaml ファイルを作成してロードバランサをプロビジョニングし、Transport Layer Security（TLS）の終端を構成します。

code_block: <ListValue: [StructValue([('code', '# Gateway: マネージド証明書と静的 IP を使用する HTTPS ロードバランサ\r\napiVersion: gateway.networking.k8s.io/v1beta1\r\nkind: Gateway\r\nmetadata:\r\n name: mcp-gateway\r\nspec:\r\n gatewayClassName: gke-l7-global-external-managed\r\n listeners:\r\n - name: https\r\n protocol: HTTPS\r\n port: 443\r\n tls:\r\n mode: Terminate\r\n options:\r\n networking.gke.io/pre-shared-certs: mcp-cert\r\n addresses:\r\n - type: NamedAddress\r\n value: mcp-server-ip\r\n---\r\n# HTTPRoute: トラフィックを MCP サーバーに転送します\r\napiVersion: gateway.networking.k8s.io/v1\r\nkind: HTTPRoute\r\nmetadata:\r\n name: mcp-route\r\nspec:\r\n parentRefs:\r\n - name: mcp-gateway\r\n hostnames:\r\n - "mcp.yourdomain.com"\r\n rules:\r\n - matches:\r\n - path:\r\n type: PathPrefix\r\n value: /mcp\r\n backendRefs:\r\n - name: mcp-service\r\n port: 80\r\n---\r\n# GCPBackendPolicy は、セッションアフィニティやその他のバックエンドを構成するために使用されます。\r\n# MCP サーバーはステートフルであるため、セッションアフィニティを有効にします。そうすることで、次のことが保証されます。\r\n# 同じクライアントからのリクエストは同じバックエンドに送信されます。\r\napiVersion: networking.gke.io/v1\r\nkind: GCPBackendPolicy\r\nmetadata:\r\n name: mcp-backend-policy\r\nspec:\r\n default:\r\n sessionAffinity:\r\n type: CLIENT_IP\r\n targetRef:\r\n group: ""\r\n kind: Service\r\n name: mcp-service\r\n---\r\n# HealthCheckPolicy は、MCP サーバー用にカスタムの正常性プローブを構成するために使用されます。\r\napiVersion: networking.gke.io/v1\r\nkind: HealthCheckPolicy\r\nmetadata:\r\n name: mcp-health\r\n namespace: default\r\nspec:\r\n default:\r\n checkIntervalSec: 15\r\n timeoutSec: 5\r\n healthyThreshold: 1\r\n unhealthyThreshold: 2\r\n logConfig:\r\n enabled: false\r\n config:\r\n type: HTTP\r\n httpHealthCheck:\r\n port: 3000\r\n requestPath: /healthz\r\n targetRef:\r\n group: ""\r\n kind: Service\r\n name: mcp-service'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddbd0d7c0>)])]>

この構成をデプロイすると、外部トラフィックを MCP サーバーに安全にルーティングするのに必要なインフラストラクチャが作成されます。

code_block: <ListValue: [StructValue([('code', 'kubectl apply -f gateway.yaml'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddbd0d130>)])]>

ロードバランサがアクティブになり、証明書がプロビジョニングされるまで数分待ちます。kubectl get gateway mcp-gateway を使用してステータスを確認できます。

リモート MCP サーバーにアクセスしてみます。テストスクリプトを実行して接続を確認します。テストスクリプトの MCP サーバー URL を https://mcp.yourdomain.com/mcp に編集してください。

code_block: <ListValue: [StructValue([('code', 'uv run test_mcp_server.py'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddbd0ddf0>)])]>

Cleanup

code_block: <ListValue: [StructValue([('code', 'kubectl delete -f deployment.yaml\r\nkubectl delete -f gateway.yaml\r\ngcloud compute addresses delete mcp-server-ip --global\r\ngcloud compute ssl-certificates delete mcp-cert --global\r\ngcloud artifacts repositories delete mcp-repo --location=$REGION\r\ngcloud container clusters delete mcp-cluster --region $REGION'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddbd0d4f0>)])]>

Antigravity 2.0 を使用して 1 日で Go を習得するための実践的な方法

Thu, 25 Jun 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 6 月 16 日に、Google Cloud blog に投稿されたものの抄訳です。

私は、NPM の依存関係オーバーヘッドからソフトウェアスタックを解放し、リソースを大量に消費する Node.js ランタイムをコンパイルされた単一バイナリの Go CLI に置き換える方法を模索してきました。その結果、skl という高速ツールが完成しました。エージェントスキルの管理に使用するツールで、起動時間はわずか 2 ミリ秒、使用するメモリはたった 11 MB です。

具体的に、私は何をしたと思いますか？

アーキテクチャに関する目標を設定して、ロジックを監査しただけです。その一方で、Antigravity がコードの変換、テストの生成、プラットフォームパスのマッピングといった機械的な作業をすべて実行してくれました。今回の投稿では、この移行ワークフローを順を追ってご紹介しますので、ご自身のワークフローの構築にお役立てください。

ステップ 0: 個人的な学習目標の「種まき」をする

コードを記述する前に、まずプロジェクトの境界を定義します。私たちの場合、外部パッケージの使用を最小限に抑えた、依存関係のないコアが必要でした。そして、開発する CLI ツールは高速である必要があり、セキュリティモデルは必要に応じてゼロトラストにしなければならないと決めました。その過程で、エージェントから具体的な制約が追加されました。すべての入力をサニタイズすること、パストラバーサルをブロックすること、フォルダスキャンに深さ制限を適用して CPU のハングを防止することです。

まず、代替スタックを監査し、そのトレードオフを比較検討するよう Gemini に指示しました。

code_block: <ListValue: [StructValue([('code', 'オンラインで TS の代替となる CLI ツール構築ソリューションを調査して 3～5 個教えてください。その理由（パフォーマンスとセキュリティを重視します）と、具体的な例およびリンクも記載してください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de0db4970>)])]>

私たちが検討した代替ソリューションは次のとおりです。

Rust: パフォーマンスが非常に優れていましたが、その借用チェッカーのルールを理解し、ライフタイムアノテーションを管理することは、私たちの単純なシンボリックリンクツールには負担が大きすぎました。
Python: ランタイムインタプリタを配布して仮想環境を管理する必要があり、pip を介したパッケージ化のオーバーヘッドを生じさせることになります。これは避けたいと考えました。
Zig: 優れた低レベルのメモリ制御とコンパイル速度を実現できましたが、HTTP 操作やアーカイブ抽出のための高レベルの標準ライブラリ抽象化がデフォルトで用意されていませんでした。
コンパイルされた Swift: macOS ではクリーンなスクリプトが提供されましたが、Windows と Linux 向けのクロスプラットフォームコンパイル機能は、私たちのマルチプラットフォーム要件には最適ではありませんでした。

私たちにとって、適切なバランスを備えていたのが Go でした。このツールは、同期型の線形コード、即時コンパイル機能、豊富な標準ライブラリを備えています。

他の誰かがすでに完了している作業を繰り返したくなかったため、プロジェクトを始めるにあたって、私は次のように直接的に質問しました。

code_block: <ListValue: [StructValue([('code', '「npx skills」を Go に移植したいのですが、以前にこれを行った人はいますか？'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de0db4fd0>)])]>

エージェントはウェブを調査し、vercel-labs/skills リポジトリの公式 Go ポートがないことを確認しました。また、公式 CLI は TypeScript ベースで npm を介して配布されますが、エージェントスキル仕様自体はオープンで言語に依存しないことも確認しました。つまり、コンパイルされた Go ポートをゼロから自由に構築できるということです。

また、この過程で多くのことを学びたかったため、Go 固有のヒント、コツ、落とし穴についても尋ねました。

code_block: <ListValue: [StructValue([('code', 'GO の正しい使い方と正しくない使い方を 3～5 パターン特定し、説明してください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de0db45e0>)])]>

ステップ 1: スキルの重要性

馴染みのない言語のベストプラクティスを最大限に活用するために、最もよく利用されている、評価の高いエージェントスキル（AI コーディングアシスタントをガイドするカスタム指示）を探してインストールしてから、コードの記述や計画を開始することにしました。まず環境のグラウンディングを行うことで、その後記述または計画されるコードがコミュニティの合意されたスタイルに確実に準拠するようになります。

スキル検索のプロンプト

エージェントに、Go で利用できるコミュニティエージェントスキルを尋ねました。

code_block: <ListValue: [StructValue([('code', '「Go」の主要なコミュニティエージェントスキルは何ですか？'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de0db4880>)])]>

エージェントから samber/cc-skills-golang が提案されたので、そのスキルパックをインストールするように指示しました。

code_block: <ListValue: [StructValue([('code', 'samber/cc-skills-golang のすべてのスキルを追加してください'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de0db4730>)])]>

インストール後、/golang- と入力して予測入力機能を呼び出し、スキルが検出されて準備が整っていることを手動で確認しました。

ステップ 2: ギャップ分析と計画

エージェントに次の指示を与えて、アーキテクチャに関する目標を定義しました。

code_block: <ListValue: [StructValue([('code', '「npx skills」の機能を 100% Go に移植する計画を立ててください。安全性とベストプラクティスを重視し、単体テストのカバレッジは 90% とします。リポジトリを pull して全体をマッピングし、質問があれば何でも聞いてください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de0db4280>)])]>

最初のトピックタスクは、動的なオンボーディングフローでした。デフォルトをどうすべきか尋ねられたので、エージェントが見つからない場合は antigravity-cli のインストールを促すように提案しました。また、複数のアクティブなエージェントが検出された場合の universal ディレクトリへのフォールバック動作も定義しました。

code_block: <ListValue: [StructValue([('code', 'MVP では、Antigravity 2 のデフォルトのサポートと、標準に準拠した「.agents」ディレクトリを通じた universal へのフォールバック（複数のエージェントが検出された場合）を目指します。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de08f11c0>)])]>

実装

私が計画を承認すると、Antigravity は 51 件以上あるエージェント構成レコードすべての体系的な変換を実行しました（すべての変換を明示的に要求したわけではありませんが、AI はタスクが十分にシンプルであるため MVP の範囲に含めることができると正しく特定しました）。TypeScript から Go に Aider、Claude Code、Cursor、Zed などの個別のディレクトリをマッピングすることで、すべての環境に対応できました。

コア構造は 1 つのファイル types.go にまとめられていて便利です。

code_block: <ListValue: [StructValue([('code', 'type AgentType string\r\n\u200b\r\ntype AgentConfig struct {\r\n Name string\r\n DisplayName string\r\n SkillsDir string\r\n GlobalSkillsDir string\r\n ShowInUniversalList bool\r\n DetectInstalled func(home, configHome, cwd string) bool\r\n}\r\n\u200b\r\n…'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de08f14f0>)])]>

このマッピングは効果的に動作します。たとえば、Zed の検出ロジックは、Linux（Flatpak）、macOS、Windows の構成を、次のようにわずか数行で動的に処理します。

code_block: <ListValue: [StructValue([('code', '"zed": {\r\n Name: "zed",\r\n DisplayName: "Zed",\r\n SkillsDir: ".agents/skills",\r\n GlobalSkillsDir: filepath.Join(home, ".agents/skills"),\r\n DetectInstalled: func(h, c, w string) bool {\r\n return exists(filepath.Join(c, "zed")) ||\r\n (zedAppDataHome != "" && exists(filepath.Join(zedAppDataHome, "Zed"))) ||\r\n (zedFlatpakConfigHome != "" && exists(filepath.Join(zedFlatpakConfigHome, "zed")))\r\n },\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de08f1a90>)])]>

その後、Antigravity のユーザーオンボーディングコードが自動マッピングに混在していることに気づきました。このようなデフォルトはユーザーが個人的に選択するものであり、独自のファイル agy-onboarding.go として分離する方が適しています。

code_block: <ListValue: [StructValue([('code', 'デフォルトの Antigravity 2 プロンプトを agy-onboarding.go に移動してください'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de08f1d00>)])]>

バージョン 0 がスキャフォールディングされ、テスト段階に入りました。

ステップ 3: 品質保証（QA）ループの実施

Go ポートが元の TypeScript CLI と同じように動作することを保証するために、テスト駆動開発（TDD）ループを採用しました。私はまず、プロンプトで次の指示を出しました。

code_block: <ListValue: [StructValue([('code', 'TDD の原則と https://preslav.me/2026/05/19/10-golang-error-handling-commandments/ を適用してください'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de08f1fd0>)])]>

これにより、TDD プロセスが開始されました。エージェントにスキルを使用するように明示的に指示するのではなく、サードパーティのベストプラクティスに関するブログ投稿を取得するように指示することで、関連するエージェントスキル（golang-how-to、golang-testing、golang-error-handling、golang-cli）をエージェントに思い出させました。Antigravity はサンドボックスを備えているため、これらのスキルを解析し、QA ループの実行を自動的に開始しました。今後も、機能コードを変更しようとするたびに、最新の軌跡でこれらの TDD 原則を再適用し続けます。

テストファーストのフロントマター解析

フロントマター解析で、エージェントはまず Go のテーブル駆動テストパターンを使用して frontmatter_test.go を記述しました（これは私にとって新しいパターンで、知ることができて嬉しく思いました）。

code_block: <ListValue: [StructValue([('code', 'func TestParseFrontmatter(t *testing.T) {\r\n tests := []struct {\r\n name string\r\n raw string\r\n wantData map[string]interface{}\r\n wantContent string\r\n }{\r\n {\r\n name: "valid frontmatter",\r\n raw: "---\\nname: my-skill\\n---\\n# Content\\n",\r\n wantData: map[string]interface{}{"name": "my-skill"},\r\n wantContent: "# Content\\n",\r\n },\r\n }\r\n for _, tt := range tests {\r\n t.Run(tt.name, func(t *testing.T) {\r\n gotData, gotContent, err := ParseFrontmatter(tt.raw)\r\n # 結果のアサート...\r\n })\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de08f1be0>)])]>

Antigravity が go test を実行すると、予想どおりにエラーが発生しました。次に、エージェントが frontmatter.go を生成しました。これは、ドキュメントを分割して YAML メタデータをアンマーシャルする線形文字列スキャンループを実装するものです。複雑な正規表現ではなく単純な線形スキャンを使用することで、アプリケーションをクラッシュさせる可能性のある正規表現サービス拒否攻撃（ReDoS）への脆弱性に対処するツールを強化しました。目標（最初のプロンプトで示したもの）に安全性を含めたことで、元の Node 実装では正規表現を使用していたにもかかわらず、より安全なコードが生成されました。

「エラーの十戒」によるグラウンディング

エラー処理の話が出たので、エラー構造をどのようにして Preslav Rachev 氏の 10 Golang Error Handling Commandments（Golang におけるエラー処理の十戒）に沿ったものにしたかについて、ここでご説明しておきましょう。Go では、エラー値を例外としてキャッチするのではなく、明示的に返す必要があります。これらのルールを統合することで、すべてのレベルでエラーを即座にチェックし（if err != nil）、コンテキストの詳細でラップ（fmt.Errorf("action: %w", err)）してから、コールスタックに継承するようエージェントに指示しました。生成されたコードの最終レビューを行っていると、Antigravity が次のベストプラクティスを忘れていることに気づいたので、思い出してもらいました。

code_block: <ListValue: [StructValue([('code', 'すべてのファイルでエラーメッセージを短くする、先頭の「failed to」を削除する、など。Golang の十戒を参照してください'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de08f1670>)])]>

Antigravity は、コードベース全体で迅速に修正を行いました。

単体テストだけで十分？

簡潔に言えば、いいえです。

変換プロセス中に AI が小さなバグやハルシネーションを発生させることがないよう、テストスイートの合格という結果を盲目的に信頼せず、コードレビューを実施しました。

生成されたテストを監査したところ、合格を示す緑色のチェックマークが付いただけでは不十分であることがわかりました。多数のインストール場所を対象としたテストと、エージェントなしの場合、エージェント 1 つの場合、複数のエージェントが同時にアクティブになっている場合といった、さまざまな組み合わせのテストが欠けていました。ゼロから書き直したコードであったため、一連のユーザー操作が最初から最後まで正しく機能することを総合的にテストする必要があると考えました。このギャップに対処するために、私は対象とする一連のシナリオを Antigravity にプロンプトで指示しました。

code_block: <ListValue: [StructValue([('code', '次の統合テストを追加してください。\r\n1. エージェントがインストールされていない: Antigravity にインストールされ、agy-cli のオンボーディングのヒントを出力することを確認します。\r\n2. 1 つを除くすべてのエージェントをサポート\r\n3. エージェントが 1 つだけインストールされている（同じパスが複数のエージェントに割り当てられている場合を含む）\r\n4. パラメータ化されていないエージェントをサポート'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de08f1970>)])]>

注: Claude Code や Codex などのパラメータ化されていないエージェントは、実行時にアクティブなワークスペースフォルダをスキャンするのではなく、パッケージの読み込み時に（または環境変数を介して）構成パスをグローバルに定義します。

これらのテストを追加した変更リストは、本番環境のファイルには一切触れておらず、ロジックは堅実なものでした。しかし、運に任せるのは嫌でした。特定の機能やワークフローが重要なのであれば、そのことを明確に伝える必要があります。総合的なテストの範囲を確認し、いくつかの堅実なテストを定義するために 5 分を費やすだけで、ユーザーがリリースの不具合に遭遇するのを防ぐことができます。

ステップ 4: CLI コマンド向けの並列サブエージェント

一連の CLI コマンド（init、add、list、remove、find、update など）をサブオプションとともに移植すると、対応が必要な範囲が広がってしまいます。順番に移行するのではなく、作業を並列化した方がよいかもしれません。今回のケースでは、各サブエージェントにツール全体を把握させるのではなく、特定のトピックに集中させることを目的としていたため、この方法が適していました。また、この方法によっていくつかのギャップを特定できました。

ただし、サブエージェントが常に最善の選択肢とは限りません。明確に境界が定められた、大量の独立したタスクの場合のみ、並列実行を優先する必要があります。適切に対処すれば、並列サブエージェントが消費するトークンが、長時間実行される単一のスレッドよりも大幅に多くなることはありませんが、並列サブエージェントは、大規模なコードベースの負担がかかっている場合に、メインのコーディネーターエージェントがコンテキスト圧縮の制限に達するのを防ぎます。ほとんどの単純なプロジェクトでは、このレベルの拡張は不要です。経験上、サブエージェントは、数十のサブ機能を持つ数十の機能に相当するワークロードに使用するとよいでしょう。

前のステップでは、MVP を迅速かつ効率的に構築するために、単一のエージェントを実行しました。しかし、コードが完全に移植されたかどうかはわかりませんでした。そこで、次のように直接的に尋ねてみました。

code_block: <ListValue: [StructValue([('code', '元の CLI の 100% を処理できましたか？\r\nサブエージェントに各オプションを個別に調査させ、各テストも調査させて、ギャップを埋めてください'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de08f10d0>)])]>

結果的に、これは正しい判断でした。サブエージェントはコマンドの詳細な監査を実施し、いくつかのオプションのギャップと欠落しているテストを特定しました。その後、これらはこちらの監査 commit に統合されました。

code_block: <ListValue: []>

各サブエージェントは 1 つのコマンドのみを処理しました。-g/--global や --copy などのフラグの組み合わせを分析し、テーブル駆動型の単体テストを作成して、コードが問題なくコンパイルされることを確認しました。報告を受けたメインコーディネーターは、変更を統合し、競合を解決して、結合されたプロジェクト全体が正常にコンパイルされることを検証しました。

象（Elephant）と金魚（Goldfish）

エージェントをこの移行に集中させ続けるために、Google Research の Elephants, Goldfish, and the New Golden Age of Software Engineering で文書化されているアーキテクチャパターンである「象と金魚」の例えを使用しました。これは、象（設計ルールとコードベースのメモリを保持する長期的なコーディネーターセッション）と金魚（バックグラウンド履歴なしで単一のタスクを実行するために生成する、一時的かつクリーンなサブエージェント）という 2 つの個別の役割に基づくものです。

Antigravity は自動セッション圧縮を使用してコンテキストサイズを管理しますが、コンテキストが少ないほど明瞭になる場合は、独自のチェックリストを維持し、作業を分離された一時的なサブエージェントに分割することで、コンテキストウィンドウを積極的に管理することをおすすめします。

ステップ 5: パッケージ構造、コンパイル、CI / CD

何度かやり取りするうちに、Go パッケージの構造と、考慮すべき制限事項がわかってきました。そして、ネイティブインストールをサポートする、明確な構造と充実したドキュメントを備えたパッケージ main.go が完成しました。

code_block: <ListValue: [StructValue([('code', 'go install github.com/alexastrum/skl@latest'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de08f15b0>)])]>

実装の詳細を把握し、後で参照できるように文書化するようエージェントに指示しました。

code_block: <ListValue: [StructValue([('code', '人間向けの結果を README.md に要約し、エージェント向けの考慮事項を AGENTS.md に要約してください'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de08f1400>)])]>

ビルドを確認し、テストを自動実行して、他のマシンでも動作することを確認するために、エージェントに次のように依頼しました。

code_block: <ListValue: [StructValue([('code', 'すべてのサポート対象プラットフォームでビルドされることを確認してください'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de08f1730>)])]>

Antigravity は、マトリックスビルドを実行するための ci.yml ワークフローを設定しました。このワークフローには、驚くべき依存関係がありました。

code_block: <ListValue: [StructValue([('code', 'env:\r\n FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: "true" # HMMMMMM ???\r\njobs:\r\n test:\r\n strategy:\r\n matrix:\r\n os: [ubuntu-latest, macos-latest, windows-latest]\r\n# ...'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de08f15e0>)])]>

予想外の注意点

矛盾しているようですが、Node から Go に移行したにもかかわらず、GitHub パイプラインは依然として、actions/checkout や actions/setup-go などの標準的な GitHub Actions ヘルパーに Node を使用しています。
このツールは、ローカルで実行およびコンパイルすることができます。ただし、事前にコンパイルされたバイナリを他のユーザーに配布する場合は、macOS と Windows 向けのコード署名を設定する必要があります。

コード署名を使用したカスタムアクションの構築は複雑なプロセスであるため、その説明はまたの機会に譲ります。

ステップ 6: エージェントスキルを作成する

プロセス自体を文書化する段階になりました。このワークフローを体系化するために、再利用可能なエージェントスキルを作成しました。

まず、最も重要な手順を含むスキル作成プロンプトを計画するようエージェントに指示しました。

code_block: <ListValue: [StructValue([('code', '最新の軌跡（受け入れられた結果を生成した私の具体的なプロンプトを含む）を確認し、「/cli-to-go-migration」スキルを作成する計画を立てましょう。スキルはどのような手順を踏むべきですか？'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de08f13d0>)])]>

プロンプトのドラフトが提示され、それを繰り返し改良しました。何度かやり取りした後、5 つの基本ルール（ただし、人によって異なります）に基づいて最終的な指示をまとめました。私が使用した最終的なプロンプトは次のとおりです。

code_block: <ListValue: [StructValue([('code', '最新の軌跡（受け入れられた結果を生成した私の具体的なプロンプトを含む）を確認し、「/cli-to-go-migration」スキルを作成する計画を立てましょう。ルールは次のとおりです。\r\n\u200b\r\n#### 1. 目標\r\nエージェントは、コードを提案する前に調査を開始する必要があります。ユーザーのより広範な目標を特定し、複数のスタックの代替案を検討し、以前の作業を確認して 1 つのターゲット言語に絞り込み、そのイディオムを調査してください。\r\n\u200b\r\n#### 2. 設定\r\nエージェントは、ファイルを変更する前に Git リポジトリを検証または初期化して、履歴をクリーンな状態に保ちます。その後、ダウンロードの失敗を直接報告し、すべての独立した作業が完了したら失敗の処理を安全に行う必要もあります。プレースホルダや終了しないループにフォールバックすることはありません。\r\n\u200b\r\n#### 3. 既存の知識のインポート\r\n必要な基礎スキル（「golang-cli」や「golang-testing」など）が欠けているにもかかわらず、プロンプトで明示的に指定されている場合、エージェントはデベロッパーが従うべき手順を出力するのではなく、実行をブロックし、確認を求めたうえで自動的にインストールすることを提案します。\r\n\u200b\r\n#### 4. ブレークポイント\r\nこのスキルは、AI の既知の課題が発生した場合にシステムを強制停止させます。エージェントは、特定の問題に遭遇した場合や混乱が生じた場合は常に、人間またはアルゴリズムによる検証のために停止します。\r\n\u200b\r\n#### 5. 整合性チェック\r\n不整合の兆候が見られたら、明示的なルールを設定する必要があります。たとえば、エージェントが一部のドキュメントを過剰に編集し、他のドキュメントを見落としていることに気づいた私は、エージェントが「/humanizer」スキルを適用するのは「README.md」やヘルプドキュメントなどの人間向けのファイルのみとし、「AGENTS.md」などの構造化されたデベロッパーコンテキストは、スタイルを編集せずにおくことで、他のエージェントがそのメタデータを正確に解析できるようにするというルールを設定しました。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9de08f1700>)])]>

万能なアプローチはありませんが、まずはいくつかのガードレールに基づくスキルを作成するようエージェントに依頼するとよいでしょう。実際には、エージェントの回答が目標に沿っていると感じるまで、複数のプロンプトを順番に推敲することになるでしょう。その後、AI に校正を依頼し、最終的には人間が SKILL.md の内容をレビューします。

まとめ

Go での skl の再構築は、ツールに関する個人的なニーズの解決につながる、楽しく有益な経験でした。うまくいったので、そのプロセスを文書化することにしたのです。今回の経験を経て、この取り組みそのものに価値があったことに気づきました。アーキテクチャの選択肢を再利用可能なスキルと個人的な経験に体系化することで、エンジニアとして成長できます。コンパイルされたバイナリは、プロセスが機能したことを示す物理的な証拠となります。

驚くべきことに、この移行中に私が経験した最も大きな変化は行動面に現れました。

IDE（統合開発環境）から離れて Antigravity 2.0 を使用することで、全体像を把握しやすくなり、移行中に発生した問題をその場で修正しようとしなくなりました。その代わりに、問題が発生した理由を理解し、Go 言語固有の詳細を把握できるよう、Antigravity が導いてくれました。

従来の IDE では、アシスタントが問題に遭遇すると、本能的にキーボードを手に取ってデバッグしたくなります。エディタなしで操作するということは、船の機関室で発生した火災に自ら対処するのではなく、造船技術者として航海船橋から機械を操縦するようなものです。私たちはまさに、こうしてエージェントを大規模に管理する方法を学びました。

- Antigravity、デベロッパーリレーションズ、Alex "Sandu" Astrum

次世代のグローバルイノベーションの拡大: 成功を収めている世界中のスタートアップを Google がどのようにサポートしているか

Thu, 25 Jun 2026 01:00:00 +0000

※この投稿は米国時間 2026 年 6 月 19 日に、Google Cloud blog に投稿されたものの抄訳です。

テクノロジー起業の世界はリスクが高く、優れたプロトタイプから市場を定義する拡大可能なビジネスへの飛躍は困難を伴います。創業者は資金だけでなく、詳細なアーキテクチャガイダンス、国家レベルの政策への対応、急速な成長が可能な技術システムも必要としています。

ジョイの法則からの抜粋:「誰であれ、最も賢い人のほとんどは他の誰かのために働いている。」

真のイノベーションは本質的に「他の場所」で起こるものだと Google は考えています。この理念に基づき、Google はイノベーション市場の多様な地理的フットプリントにわたってグローバルアクセラレータを積極的にサポートし、各地の優れた人材を活用しています。Google のアクセラレータプログラムは、10 年以上にわたり、この移行を促進する役割を果たしてきました。このプログラムは、起業家としての野心と Google の世界クラスのエンジニアリングエコシステムとのギャップを埋めることで、地球上で最も復元力が高く、パフォーマンスの高い数々のスタートアップ（ポートフォリオ）を静かに輩出してきました。

ネットワークの力: 10 年間の成果を数字で見る

多くのスタートアップアクセラレータは失敗率が高く、苦境に陥っていますが、Google のアクセラレータプログラムは長期的な成功のための高い基準を確立しています。このプログラムでは、トップクラスの創業者や CTO を適切なエキスパートと結び付け、Google からカスタマイズされた高度な技術的支援を提供し、過去の教訓から学んだ業界のベストプラクティスを示すことで、価値の高い企業やプロダクトの構築を継続的に支援しています。

このグローバルネットワークの影響範囲は驚くべきものです。

指標	これまでの成果
グローバルフットプリント	88 か国で 2,011 社のスタートアップを支援
プログラムの経験	10 年間で 144 のコホートが卒業
生存率	ポートフォリオの存続率は 93%
資金面の勢い	調達した資金は 463 億ドル、ポートフォリオの総評価額は 1,351 億ドル
スタートアップの雇用創出	スタートアップポートフォリオ全体で 305,900 人の従業員

開発者の付加価値: このプログラムは、ビジネスの概要を学ぶためのものではありません。アクセラレータのスタートアップの創業者たちは、高度な技術的問題を特定し、Google からカスタマイズされたサポートを受けながら、その解決に取り組みます。これらのスタートアップは、Google のエンジニアやプロダクトマネージャーと連絡を取れるほか、Google のプラットフォームやツールも利用できます。アーキテクチャに関するアドバイスから AI モデルパイプラインの最適化まで、Google のエキスパートが創業チームと直接連携して、最も複雑な技術的ハードルへの対処を支援します。

戦略的展開: 地政学、グリーンインフラストラクチャ、ロボット工学

スタートアップエコシステムは急速に変化しており、Google のアクセラレータプログラムもそれに合わせて進化しています。今年、Google は世界的な経済発展を支援し、重要な環境インフラストラクチャを調査して進化させるための新しい取り組みを開始しました。いくつか例をご紹介します。

国家レベルの政策と戦略的成果

オーストラリア: アクセラレータの卒業生は、Google AI スタックをオーストラリアの国家研究開発戦略に直接組み込むことに成功し、キャンベラの国会議員と直接連携しています。
カナダ: カナダのイノベーション・科学・経済開発省は、G7 サミットの公式レポートで、カナダのアクセラレータプログラムの影響を正式に認め、引用しました。

フロンティア領域の最先端プログラム

今年は、プログラムの対象が、フロンティア領域の専門的なテクノロジーの業種にまで大きく拡大しています。

Google DeepMind Accelerator（ヨーロッパ）: AI ネイティブのロボット企業向けの技術構築の強化に特化したプログラムで、ラボでのプロトタイピングと商業市場での成功のギャップを効果的に埋めます。
アジア太平洋地域の GDM Accelerator（AI for Planet）: Google DeepMind チームと Google のサステナビリティチームの共同イニシアチブ。このプログラムは、生物多様性基盤モデルに重点を置き、重要な ESG（環境、社会、ガバナンス）インフラストラクチャ市場の最前線に Google を位置付けることを目指しています。
日本での再開: アジアで最も重要なテクノロジーハブの一つで戦略的にプログラムを再開します。

集合知の可能性

このユニークなネットワークの力を最大限に引き出すため、今年、地域ごとに分かれていた卒業生ネットワークを Unified Alumni Community に統合しました。現在、90 か国以上で 1,750 社を超えるスタートアップと 3,000 人の創業者を、共有オンラインチャネルと対面式イベントへの参加機会を通じて結び付けています。創業者たちは、Google の上層部と連絡を取り、Google の最新のモデルやテクノロジーを利用し、ビジネスの成長をより効果的にサポートする新しい Google プロダクトの開発に直接影響を与える機会を得て、互いに学び、支え合っています。

お見逃しなく: 今後の Demo Day

各アクセラレータの集大成となるのが Demo Day です。このデモでは、トップレベルのコホートが技術的な構築と市場を定義する新しいコンセプトを紹介します。これらのマイルストーンは、YouTube の Google for Startups イベントで直接ライブ配信されます。2026 年の残りのデモの日程は以下のとおりです。

2026 年夏と秋

アフリカのアクセラレータ: 6 月 19 日
中東、北アフリカ、トルコのアクセラレータ: 6 月 26 日
韓国のアクセラレータ: 7 月 15 日
ブラジルのアクセラレータ: 7 月 16 日
ヨーロッパとイスラエルの DeepMind Accelerator（ロボット工学）: 9 月 11 日
インド: 9 月 30 日

2026 年冬

インドのアクセラレータ: 11 月 4 日
東南アジアのアクセラレータ: 11 月 13 日
北米のアクセラレータ（エネルギー）: 11 月 19 日
南アフリカのアクセラレータ: 12 月 11 日
ヨーロッパとイスラエル（エネルギー）: 12 月 11 日
グローバルな Google.org Accelerator（政府のイノベーション）: 12 月 11 日

お申し込み受け付け中または受付予定のプログラム

技術インフラストラクチャを大幅にスケールアップし、プロダクトの市場への適合性を最適化し、Google のグローバルな人材プールからエクイティフリーのサポートを受けたいと考えている創業者や CTO の皆様、お申し込みの受け付けが正式に開始されました。

現在お申し込み受付中のプログラム:

GFSA 東南アジア（東南アジアとシリコンバレーを結ぶ、新しく立ち上げられた AI スタートアップイノベーションコリドーを活用）
GFSA 中国
Google.org Accelerator: AI for Science

- デベロッパー採用担当ディレクター、Matt Thompson

デベロッパー必見: 開発に欠かせない 10 個のプロンプト

Mon, 22 Jun 2026 02:10:00 +0000

※この投稿は米国時間 2026 年 6 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。

開発者のプロンプト履歴を見ると、非常に具体的で、ときには雑然とした、その場限りのプロンプトが並んでいることがあります。AI を使って、個別のエラーメッセージをデバッグしたり、まとまりのないメールを整えたり、簡単な定型文を生成したりしているのです。

一方で、質の高い成果物を継続的に生み出している人たちと話してみると、興味深いことがわかります。そうした人たちは、単に思いつきでプロンプトを書いているわけではありません。時間をかけて調整と改善を重ね、ほぼすべてのプロジェクトで活用している定番のプロンプトを持っているのです。

そこで、同僚やリーダーにシンプルな質問を投げかけました。「最もよく使うプロンプトは何ですか。また、それを使う理由は何ですか。」

共有されたのは、単なるコマンドの寄せ集めではありませんでした。ここでは、私たちのチームにとって手放せないプロンプトと、さらに重要な、そのプロンプトを使う理由をまとめてご紹介します。

仕様を作成する

Maja Bilić

シニアアウトバウンドプロダクトマネージャー • エンジニアリング

LinkedIn でフォロー

プロンプト:

code_block: <ListValue: [StructValue([('code', '懐疑的なプリンシパルアーキテクト兼テクニカル PM として振る舞ってください。私は、[ユーザー] が [アクション] できる [プロダクト] を構築したいと考えています。コードは書かないでください。このコンセプトを分析し、技術、UX、アーキテクチャに関する上位 5 つの考慮事項を挙げてください。次に、その 5 つの考慮事項について、それぞれ重要な質問をしてください。そうすることで、仕様の作成を一緒に進められるようにします。すべての回答がそろったら、PRD ドキュメントと実装計画を作成してください。設計や実装計画を、過度に作り込みすぎたり、単純化しすぎたりしないでください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddbeb2580>)])]>

理由: 私は質の低いプロダクト要件定義書（PRD）を書いたこともありますし、質の低い PRD を数多く読んできました。このプロンプトでは、懐疑的なアーキテクト / PM というペルソナを使うことで、アイデアを整理し、アプローチやコンセプトを批判的に検討し、最も重要な要素を定義する作業を一緒に進めることができます。エージェントの助けを借りて計画を詰めながら、プロダクト設計のアイデアをさらに発展させることもできます。また、過度に作り込みすぎたり、単純化しすぎたりしないという制約も気に入っています。AI は、特にプロダクト設計ドキュメントを作成する際に、そうした方向に寄りがちだからです。

ウィジェットテスト

Andrew Brogdon

スタッフデベロッパーリレーションエンジニア • エンジニアリング

X、LinkedIn でフォロー

プロンプト:

code_block: <ListValue: [StructValue([('code', 'ウィジェットテストを作成して、このプロジェクトの堅牢性を高めたいと考えています。ぜひ協力してください。まだ読んでいない場合は、Flutter チームによるウィジェットテスト作成スキル（https://github.com/flutter/skills/tree/main/skills/flutter-add-widget-test）を確認してください。そのうえで、次のことを行いましょう。\r\n\u200b\r\n* アプリケーションのコードベースを調べ、UI / UX のうち適切にテストされていない領域を特定する。\r\n* 既存のコードがテストしやすい形で書かれているかを判断する（依存関係は注入されているか、ドメインは疎結合か密結合か、など）。\r\n* 他のドメインよりも厳密なテストが必要なドメインを特定する。\r\n* アプリケーション全体のテスト計画を作成する。\r\n* どの機能領域がすでにその計画に沿っており、どの領域でテストが不足しているかを判断する。\r\n* それらのテストを実装する計画を作成する。\r\n* その計画を実行する。\r\n\u200b\r\n自分の推論に完全に確信が持てない限り、次のステップに進まないでください。必要なだけ質問して構いません。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddbeb2190>)])]>

理由: エージェント型コーディングツールの使い方として私が特に気に入っているのは、プロジェクトでやるべきだと思いながらも、これまで後回しにしてきたことを実際に進められる点です。適切なテストは、まさにその一つです。Dart / Flutter チームの公式スキルは、優れたウィジェットテストがどのようなものかをエージェントに指示するうえで非常によくできています。このプロンプトと組み合わせることで、それらの手順を自分のコーディングワークフローに組み込み、信頼性が高く、安心して保守できるコードベースを維持するためのトイルを減らすことができます。

すべてのテストを確認する / コミット内容を整理する

Aja Hammerly

ビルダーリレーション担当ディレクター • エンジニアリング

X、LinkedIn でフォロー

プロンプト:

code_block: <ListValue: [StructValue([('code', 'すべてのテストを実行し、不足しているテストを特定して作成してください。エッジケースと競合状態に特に注意してください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddbeb2e20>)])]>

code_block: <ListValue: [StructValue([('code', 'このコミットに、使用されていないコード、残しておくべきではないコメント、コメントとコードの不一致、未解決の TODO など、本来含まれるべきではないものがないか確認してください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddbeb2c40>)])]>

理由: コードを書いていると、ユーザーに通ってほしい主要な経路である「ハッピーパス」に意識が偏ってしまうことがよくあります。その作業に集中している間は、まだ深く考えたくないエッジケースについて TODO や FIXME コメントを残しておくことがあります。また、コメントの更新を忘れたり、デバッグ用のコメントを残したままにしたりすることもあります。テスト駆動開発に従うよう努めてはいますが、すべてのエッジケースに対して必ずテストを用意できているわけではありません。私は通常、AI または人間のレビュアーに提出する前に、最初のコードレビューとして、この 2 つのプロンプトを新しい会話で実行します。その際、開発時のコンテキストは含めません。これにより、自分が作ったものを、他の人がレビューしやすく、使いやすい状態に整えることができます。

権限が正しく、コンプライアンスに準拠しているか確認する

Rich Hyndman

Antigravity デベロッパーリレーション責任者 • エンジニアリング

X、LinkedIn でフォロー

プロンプト:

code_block: <ListValue: [StructValue([('code', 'この Android プロジェクトを包括的にチェックし、すべての権限が正しく、コンプライアンスに準拠していることを確認してください。次の手順を行います。\r\n1. すべての AndroidManifest.xml ファイル（main、debug、フレーバー固有のマニフェストを含む）を特定して分析し、宣言されている <uses-permission> タグのマスターリストを抽出する。\r\n2. 宣言されている権限をコードベースと照合し、実際にどこで使用されているかを確認する。安全に削除できる過剰な権限や未使用の権限を特定する。\r\n3. Kotlin / Java のソースファイルを確認し、すべての実行時権限について、動的な実行時権限リクエストフロー（checkSelfPermission、onRequestPermissionsResult、または Activity Result API）が実装されていることを確認する。\r\n4. 権限に関連付けられているハードウェア機能（android.hardware.camera など）が正しく宣言されていることを確認する。\r\n調査結果を Markdown レポートとして出力してください。修正が必要な箇所については、ファイルパスと推奨されるコード差分を提示してください。計画を承認するまで、ファイルの編集は行わないでください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddbeb2ac0>)])]>

理由: Gemini 3.5 Flash と Android プラグインを備えた Antigravity は、Android 開発における優れたパートナーです。権限が正しく設定されているかを確認することで、アプリをスムーズに動作させ、Google Play ストアへのアップロード時の遅延を回避しやすくなります。

コードレビューを実施する

Shir Meir Lador

デベロッパーリレーション AI 責任者 • エンジニアリング

X、LinkedIn でフォロー

プロンプト:

code_block: <ListValue: [StructValue([('code', '本番環境への投入前のコードレビューを行い、厳格で分析力の高いプリンシパルエンジニアとして振る舞ってください。あなたは非常に高い基準を持っており、脆弱な「ハッピーパス」前提のコードを一切許容しません。あなたの目標は、私が堅牢で本番環境対応のシステムを書けるよう導くことです。\r\n未コミットの変更について、本番環境対応度を A から F までの評価で採点してください。\r\nコードが極めて堅牢でない限り、「A」は付けないでください。具体的には、次の観点で変更内容を分析してください。\r\n1. 効率性: 冗長な API 呼び出し、無駄なデータベースクエリ、キャッシュされていないリソース、リソースリーク。\r\n2. レジリエンス: サイレント障害が発生する箇所、明示的なエラー境界の欠如、レート制限時のフォールバック不足。\r\n3. アーキテクチャ: 密結合、関心の分離の不明確さ。\r\n各問題について、そのコードが実際の本番環境でどのような障害に対して脆弱なのかを実践的に説明してください。そのうえで、コードを改善して「A」を獲得するために必要な、正確な git diff を提示してください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddbeb2a90>)])]>

理由: LLM にコードレビューを依頼すると、多くの場合、丁寧な反応が返ってきます。命名がきれいだと言い、いくつか docstring を提案し、問題なしという評価を付けてくれます。しかし、丁寧なレビューでは本番環境の障害は防げません。このプロンプトが気に入っているのは、AI の当たり障りのない返答を取り除けるからです。モデルに厳しい基準で作業を評価させ、修正のために実際に使える git diff を求めることで、モデルを本当のパートナーにできます。モデルは推測するのをやめ、ネットワーク呼び出しやデータベースクエリを実際に読み取り、コードがどこで壊れるのかを見つけるようになります。妥協を許さないシニアデベロッパーが肩越しに見ていて、どこで手を抜いたのかを正確に指摘し、それを修正するためのコードまで渡してくれるようなものです。

意思決定を支援するためにトレードオフを説明する

James O'Reilly

スタッフデベロッパーリレーションエンジニア • エンジニアリング

X、LinkedIn でフォロー

プロンプト:

code_block: <ListValue: [StructValue([('code', '提案された実装計画を実行することのメリットとデメリットを説明してください。どのように進めるかについて十分な情報に基づいて判断できるよう、パフォーマンス、コスト、セキュリティ、保守性の観点から、どのようなトレードオフがあるのかを具体的に説明してください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddbeb23d0>)])]>

理由: 私は、AI に自分のロジックを厳しく検証させるようにしています。どのようなトレードオフがあるのかを尋ねることで、AI は戦略を再考し、こちらの具体的な実装により集中するようになり、曖昧で大ざっぱな回答を避けやすくなります。また、このアプローチにより、AI が最終判断者のように振る舞うことを防ぎ、意思決定の主導権を自分の側に保つことができます。

研究を通じて AI 生成コードを改善する

Emma Twersky

Flutter および Dart デベロッパーリレーション責任者 • エンジニアリング

X、LinkedIn でフォロー

プロンプト:

code_block: <ListValue: [StructValue([('code', "オンラインで調査してください。特に X のスレッド、Stack Overflow、GitHub Issues、技術ブログに注目し、AI で生成された INSERT_TECH_YOU'RE_USING_HERE コードによく見られるセキュリティ上の落とし穴、アーキテクチャ上の不整合、見落とされやすいロジックエラーを調べてください。その調査結果に基づき、プラットフォームチャネルの検証、ディープリンクのルーティング、クラッシュレポートでの機密データのロギングなど、高リスク領域を監査するための手動レビューチェックリストを作成してください。"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddbeb2610>)])]>

理由: AI はコード作成を 10 倍速くできる一方で、粗いコードを生成することも少なくありません。そうしたコードは一見筋が通っているように見えても、指定されていない詳細について誤った前提を置いているため、概念的にはバグを含んでいることがあります。調査によると、AI 生成コードの最大 40% に脆弱性が含まれており、開発者は自分のコード以上に AI のコードを信頼してしまう傾向があります。そのため、危険なミスマッチが生じます。私はこのプロンプトを使って、冗長な AI 生成の変更を深く検討しないまま承認してしまうことを防ぐ、的を絞ったチェックリストを作成しています。これにより、人間の判断を、モデルが失敗しやすい高リスクの境界部分に集中させることができます。タスクの生成には AI を使いながらも、最も重要な部分では人間が関与し続けられるようにしています。

イテレーションを通じて問題を見つける

Fred Sauer

フレームワークおよび言語担当デベロッパーリレーション責任者 • エンジニアリング

X、LinkedIn でフォロー

プロンプト:

簡略化すると、私が最後に使う一連のプロンプトは次のようなものです。

code_block: <ListValue: [StructValue([('code', '- 未コミットの変更をコードレビューしてください。\r\n\u200b\r\nあまり具体的にしすぎないほうがよいと考えています。過度に誘導すると、盲点が生まれる可能性があるためです。\r\n新しい「目」で見てもらうため、新しいチャットセッションを使うようにしています。\r\n返ってくる結果が退屈に感じられ、自分が満足できる状態になるまで、これを繰り返します。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddbeb2f10>)])]>

この最後のフェーズに入る時点で、たとえば「変更が複雑すぎる気がする」といった懸念がある場合や、その変更がどの程度「良い」のか十分に把握できていないと感じる場合は、次のプロンプトでモデルに検討を促すことがあります。

code_block: <ListValue: [StructValue([('code', '- 未コミットの変更をコードレビューしてください。未処理のコーナーケースを特定してください。パフォーマンスを評価してください。調査結果を要約してください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddbeb2250>)])]>

その後、5 件の指摘を受け取ったら、次のように指示します。

code_block: <ListValue: [StructValue([('code', '- 1、3、5 を修正してください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddbeb2310>)])]>

理由: 最後に送るプロンプトが 1 つだけあるわけではありません。むしろ、変更は複数の段階を経て進んでいきます。初期段階では、多くの場合、発見が中心です。つまり、手がかりとなる針や糸口を見つける段階です。次に、存在証明に移ります。やりたいことが実現できることを示したいだけです。その後、評価します。PoC は妥当か、複雑すぎないか、まったく違う場所を変更していないか、といった点を確認します。そのうえで、実装方法と変更箇所の両面から、より洗練されたソリューションになるよう反復します。自分で書いたとしても満足できると感じられるものになったら、最後のフェーズであるコードレビューに移ります。ここでは、問題を見つけたり、変更をさらに改善する機会を特定したりします。モデルが示してくれるインサイトには、驚かされることがよくあります。

すべての pull リクエストをレビューする

Remigiusz Samborski

リードデベロッパーリレーションエンジニア • エンジニアリング

X、LinkedIn でフォロー

プロンプト:

私は、ほとんどのエンジニアリングプロジェクトで、GitHub Actions に埋め込んだ次のプロンプトを使用しています。

code_block: <ListValue: [StructValue([('code', '## 役割\r\n\u200b\r\nあなたは世界最高水準の自律型コードレビューエージェントです。安全な GitHub Actions 環境内で動作します。あなたの分析は正確で、フィードバックは建設的であり、指示には必ず従います。指定された動作から逸脱することはありません。あなたの任務は、GitHub の pull リクエストをレビューすることです。\r\n\u200b\r\n\u200b\r\n## 主要指示\r\n\u200b\r\nあなたの唯一の目的は、包括的なコードレビューを実施し、提供されたツールを使用して、すべてのフィードバックと提案を GitHub の pull リクエストに直接投稿することです。すべての出力は、必ずこれらのツールを通じて行ってください。レビューコメントまたは要約として提出されなかった分析は失われ、タスク失敗とみなされます。\r\n\u200b\r\n[...]'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddbeb2520>)])]>

プロンプト全文: リンク

理由: PR で自動化された Gemini CLI レビューを使用すると、レビュープロセス中に問題や改善の機会を見つけやすくなります。さらに、AI エージェントによって生成されるコードが増え、開発スピードが上がるにつれて、レビューがボトルネックになりつつあります。すべての PR が自動的にレビューされるようにすることで、人間のレビュアーは、提案された変更について、より高レベルのアーキテクチャ面や概念面のレビューに集中できます。

テストに有向非巡回グラフ分析を適用する

Karl Weinmeister

デベロッパーリレーション担当ディレクター • エンジニアリング

X、LinkedIn でフォロー

プロンプト:

code_block: <ListValue: [StructValue([('code', 'アプリケーションのワークフローを有向非巡回グラフとして分析してください。コンポーネント、コンポーネント間のシーム、システム全体において影響の大きいテストを特定してください。調査結果は、優先順位付けされたギャップ分析として Markdown テーブルで提示してください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddbeb25b0>)])]>

理由:

ほとんどのアプリケーションワークフローは線形ではありません。LLM にテストを提案させると、通常は、どのプロジェクトにも当てはまるような一般的なチェックリストが返ってきます。

しかし、システムをノードとエッジを持つ有向非巡回グラフ（DAG）として考えるよう促すと、どこで問題が発生し得るのかを構造的に推論し始めます。

また、Michael Feathers 氏の著書『レガシーコード改善ガイド』で使われている「シーム」についても考慮するよう指示しています。

最後に、結果を優先順位付けされた改善機会の表として要約するようモデルに依頼しています。これにより、アプリのレジリエンスを高めるための明確なロードマップをエージェントに与えることができます。

まとめ

これらのプロンプトすべてに共通しているのは、人間の思い込みに伴うリスクを減らすという点です。見落としやすいエッジケースを探す場合でも、デベロッパー向けの表現をエンドユーザー向けに言い換える場合でも、コードを書く前にアーキテクチャをストレステストする場合でも同じです。私たちのチームは、AI を、あえて厳しい問いを投げかける思考のパートナーとして活用しています。つまり、細部に入り込んでいると見落としがちな点を指摘してくれる存在です。

こうした「必ず実行する」プロンプトを日々のワークフローに組み込むことで、単にリリースを速めるだけでなく、かつてはチーム全体でレビューしなければ得られなかったレベルの確信を持ってリリースできるようになります。

- Google Cloud、スタッフデベロッパーリレーションエンジニア James O'Reilly

サーフェスの選択: Antigravity 2.0、Antigravity CLI、Antigravity IDE、Antigravity SDK

Thu, 18 Jun 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 6 月 10 日に、Google Cloud blog に投稿されたものの抄訳です。

要約:

Antigravity 2.0: 独立したプロジェクトで並行して動作する複数の自律型エージェントをオーケストレートするデスクトップアプリ。
Antigravity CLI: コマンドラインワークフローとヘッドレス実行用に設計されたターミナルインターフェース。
Antigravity IDE: エージェントを利用しながら直接コードを記述したい開発者向けのエディタ。
Antigravity SDK: Antigravity Harness を使用する独自のカスタムエージェントを構築、デプロイするための Python ライブラリ。

比較早見表

機能	Antigravity 2.0	Antigravity CLI	Antigravity IDE	Antigravity SDK
インターフェース	デスクトップアプリ	ターミナル（TUI）	デスクトップアプリ	Python コード
最適な用途	複数タスクの同時実行	コマンドライン / ヘッドレス	コードの直接編集	カスタムエージェントの構築

Antigravity の 4 つのサーフェス

1. Antigravity 2.0

デフォルトのおすすめです。複数のプロジェクトにわたり、タスクを同時に管理します。

Antigravity 2.0 は、スタンドアロンのデスクトップアプリケーションです。メインのワークスペースをブロックすることなく、複数のタスクを実行できるよう設計されています。1 つの画面でさまざまなプロジェクトを簡単に切り替えてモニタリングすることができます。また、コードの品質チェックや古いパッケージの検出といったタスクを定期的に実行するようにスケジュール設定することも可能です。

2. Antigravity CLI

ターミナルワークフローとヘッドレス実行向けです。

高速性を追求して Go で構築された Antigravity CLI は、ターミナルで高速なキーボード操作やシンプルなショートカットを使って作業することを好むユーザーに適しています。アクティブなコマンドラインウィンドウをロックすることなく、ターミナルコマンドを使用してバックグラウンドエージェントを起動できます。ヘッドレス実行（SSH 経由での作業やリモートコンテナ内での作業など）が必要な場合は、CLI を選択してください。

3. Antigravity IDE

コードを直接表示して編集したい開発者向けです。

IDE サーフェスでは、エージェントが現在のワークスペース内に直接配置されます。エージェントが編集しているコードを正確に確認し、変更を 1 行ずつ承認または拒否したい場合は、これが最適な選択肢です。組み込みのデバッグ機能により、エージェントはランタイムエラーを確認し、エディタに修正案を表示できます。この修正は、ワンクリックで適用できます。

4. Antigravity SDK（Python）

カスタムエージェントロジックと自動化されたパイプラインの作成に最適です。

code_block: <ListValue: [StructValue([('code', 'import asyncio\r\nfrom google.antigravity import Agent, LocalAgentConfig\r\n\r\nasync def main():\r\n config = LocalAgentConfig(\r\n system_instructions="You are an expert assistant for codebase navigation.",\r\n # api_key="your_api_key_here",\r\n )\r\n async with Agent(config) as agent:\r\n response = await agent.chat("What files are in the current directory?")\r\n print(await response.text())\r\n\r\nasync def run():\r\n await main()\r\n\r\nif __name__ == "__main__":\r\n asyncio.run(run())'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f9de0f60f70>)])]>

Google Antigravity SDK は、独自のカスタムエージェントをゼロから構築できる Python ライブラリです。同じ共有ハーネス上で実行されるため、Google の公式 Antigravity ツールを支えているものとまったく同じツールやルールに直接アクセスできます。エージェントをローカルで記述し、コードを一切変更することなく Google Cloud にデプロイすることが可能です。

まとめ

各インターフェースの外観は異なりますが、すべて同じ基盤エージェントハーネス上で動作します。Antigravity のどのサーフェスを選択しても、プラグインやスキルなどはサポートされます。エージェントは同じコアロジックにアクセスできるため、ご自身のプロジェクトに最適なものを選択してください。ガイドやドキュメントについては、antigravity.google をご覧ください。使用を開始する準備が整いましたら、Antigravity ダウンロードページにアクセスしてください。

- Firebase、デベロッパーリレーションズ、Alex "Sandu" Astrum

- Google Cloud、デベロッパーアドボケイト、Luke Schlangen

Google Cloud Storage MCP サーバーを活用した AI エージェントと非構造化データの連携

Fri, 12 Jun 2026 00:30:00 +0000

※この投稿は米国時間 2026 年 6 月 3 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud Storage（GCS）は、最新のエージェント技術スタックの基盤コンポーネントであり、大規模な非構造化データの保存先に適しています。企業がエージェントを本番環境にデプロイしていくのにともない、重要な関心事項は、データをコンテキストに変換し、そのコンテキストにアクセスするための安全かつ標準化されたインテグレーションの構築へと移っています。これがスマートストレージの中核です。受動的なオブジェクトを推論のための豊富なコンテキストに変え、非構造化データを本質的にエージェント対応にします。複雑な財務ワークフローの自動化であれ、数秒で行うシステム障害の診断であれ、AI が成功するかどうかは、エージェントがこのインテリジェンスをどれだけシームレスに活用し、スマートで重要度の高い意思決定を行えるかにかかっています。

このブログ投稿では、お客様が GCS を使用して構築したエージェントの例を 3 つご紹介した後、Model Context Protocol（MCP）を使用してエージェントを GCS に安全かつ確実に接続する方法について解説します。自動アノテーションやオブジェクトコンテキストといったスマートストレージ機能と組み合わせることで、GCS MCP サーバーはエージェントのデプロイプロセス全体を簡単かつシンプルなものにします。

Google Cloud Storage でのエージェントの実際の成功事例

MCP と Google のエージェント技術スタックを活用してビジネス上の複雑な問題を解決しているお客様から、驚くべきイノベーションが次々と生まれています。

Palo Alto Networks は、画面を認識する AI アシスタントの Strata Co-Pilot エージェントを構築しました。このエージェントは、手順をハイライト表示したり直接実行したりして、ネットワークセキュリティ管理者が複雑な構成フローを進められるよう支援します。また、Gemini Live API を利用しており、GCS MCP サーバー経由で GCS に接続し、「履歴メモリ」として活用しています。
Airwallex は、ユーザーコンテキストを理解し、質問に答え、ユーザーに代わってワークフローを実行する AI アシスタントを開発しました。たとえば、経費ポリシーのドキュメントをスマートに分析し、詳細な承認ワークフローを生成できます。これは、通常なら手作業で何時間もかかるタスクです。エージェントは、ドキュメントと抽出された情報を、それぞれ GCS と GCS メタデータを使用して保存します。

（Airwallex AI アシスタントのご紹介: グローバルな財務処理を簡単に実現するコンシェルジュ）

Snap のジョブ最適化エージェントは、何千ものジョブの、GCS に保存された Flink と Spark のジョブ仕様、メタデータ、過去の指標を分析し、最適化の機会を特定して費用の見積もりを生成し、構成を調整します。このエージェントを使用することにより、Snap はすでに調査時間を 30 分から 30 秒に短縮しています。

上述 3 つのエージェントのすべてにおいて、GCS MCP サーバーはデータ操作を処理するだけでなく、標準の RBAC とアクセスポリシーを適用しています。

MCP を使用してエージェントを GCS に接続

MCP は、エージェントをデータソースに接続するための標準規格として急速に普及してきましたが、多くの場合、カスタムサーバーをゼロから構築することは、業務の妨げとなる、時間のかかるプロセスとなり、イノベーションに集中できなくなります。この方法では、認証やエラー処理から GCS の進化する機能への対応まで、あらゆることを管理しなければならないため、開発のオーバーヘッドとリスクが大幅に増大します。この問題を解決するため、GCS は 2 つの強力な MCP サーバーオプション（リモートとローカル）を提供し、お客様が基盤部分をオフロードして価値の創出に集中できるようにします。

1. リモート MCP サーバー: フルマネージド エージェントを Cloud Storage MCP サーバーに接続するのに、インフラストラクチャをデプロイする必要は一切ありません。エージェント構成でマネージドエンドポイントを指定するだけで、GCS 上の非構造化データに即座にアクセスできるようになり、運用上のオーバーヘッドの負担なくエージェントワークロードを簡単にスケールできます。

Cloud Storage MCP サーバーはオープンな MCP 標準に準拠しているため、ADK などの主要なエージェントフレームワークとシームレスに連携し、MCP クライアントとも適合します。設定でカスタムコネクタを追加することにより、Google Antigravity や Anthropic の Claude などのクライアントを簡単に接続できます。Cloud Storage MCP エンドポイントを指定するだけで、すぐに構築を開始できます。複雑な構成ファイルはいりません。

エージェントをストレージに接続するには、堅牢なセキュリティとガバナンスが必要です。GCS MCP サーバーは、Google Cloud の標準的な ID、オブザーバビリティ、セキュリティのフレームワークに基づいて構築されています。

ID ファーストのセキュリティ: 認証はすべて、共有キーではなく、Identity and Access Management（IAM）を通じて処理されます。これにより、エージェントはユーザーが明示的に承認したデータ（バケットとオブジェクト）にのみアクセスできるようになります。
完全なオブザーバビリティ: エージェントのアクティビティを追跡できるよう、これらの MCP サーバーを介して行われたリクエストとアクションはすべて Cloud Audit Logs に記録されます。これにより、セキュリティチームはすべてのやり取りの記録を取得し、可視性を維持しながら簡単にアクセスできます。
MCP セキュリティ - コンテンツスキャン: 必要に応じて、Google のコンテンツセキュリティサービスである Google Cloud Model Armor を使用して MCP エンドポイントを構成できます。これにより、直接的および間接的なプロンプトインジェクション攻撃、MCP ツールポイズニング攻撃、悪意のある URL / SQL インジェクションなど、一般的な MCP 攻撃ベクトルに対するセキュリティ対策を講じることができるほか、機密データの漏洩を防ぐことができます。

Cloud Storage MCP サーバーは、ほとんどの本番環境のユースケースに適しています。ただし、他のすべてのリモートサーバーと同様に、MCP ツールを完全にカスタマイズする機能は使用できません。

2. ローカル MCP サーバー: カスタマイズを管理できるセルフマネージド リモートサーバーが標準的なデータアクセスを処理する一方、ローカル MCP はビジネスロジックに固有のカスタムツールを構築する必要がある場合に適しています。たとえば、エージェントで特殊なデータ変換を実行する必要がある場合（GCS からファイルを読み取るたびに個人情報（PII）を削除したり、別の内部システムからコンテキストを追加したりする場合など）、ローカル MCP サーバーを使用すると、そうした独自の機能を定義できます。

GCS ローカル MCP サーバーは、Google が管理するツールのオープンソース GitHub リポジトリであり、データへの信頼性の高いブリッジを提供します。以下に、カスタムツールを設計する際に留意すべきポイントをいくつかご紹介します。

モデルによる誤った呼び出しを最小限に抑えるため、正確かつ明確な説明を提供する
モデルが自身の間違いを理解して自己修正できるよう、モデルに適したエラー処理を実装する

GCS ローカル MCP は、データベース向け MCP ツールボックスの一部にもなっています。これは、GCS、BigQuery、AlloyDB、Spanner、Cloud SQL などの主要なデータサービス向けのコネクタなどを単一のオープンソースリポジトリにまとめたもので、データエコシステムのモニタリングや管理を容易にします。このツールボックスは、ボイラープレートコードを削減して開発を簡素化し、OAuth2 と OIDC によってセキュリティを強化し、OpenTelemetry を統合してエンドツーエンドのオブザーバビリティを実現します。

使ってみる

Snap のような既存プロセスを最適化する場合でも、Airwallex のようなワークフローの作成を自動化する場合でも、非構造化データはエージェントにとって最大の資産の一つです。

一般提供されている GCS リモート MCP サーバーについてご確認ください。
カスタムツールの構築を今すぐ始めるには、GCS ローカル MCP の GitHub リポジトリをご確認ください。データベース向け MCP ツールボックスの一部として使用することも可能です。
GCS データを活用したエージェントのユースケースについては、Google までお問い合わせください。

- Google Cloud、プロダクトマネージャー、Himanshu Kohli

- Google Cloud、プロダクトマネージャー、Manjul Sahay

TPU、GKE マネージド DRANET、マルチクラスタ推論ゲートウェイを使用したテスト

Wed, 10 Jun 2026 01:00:00 +0000

※この投稿は米国時間 2026 年 6 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。

あるリージョンでワークロードに障害が発生しても、サービスを使用しなければならない場合、どうすればよいでしょう？これは、可用性や稼働時間に関してよく見られるケースです。Kubernetes エコシステムと動的リソース割り当て（DRA）や推論ゲートウェイなどの機能が最近強化されたことを受け、AI 推論ワークロードを使用した簡単なテストで、Google Cloud のこれらの機能を試してみることにしました。

このブログ投稿では、この設定について詳しくご説明します。また、こちらの Codelab（TPU、Cloud Storage FUSE、マネージド DRANET を使用してマルチクラスタ GKE Inference Gateway を構築する）で、詳細な構成をすぐに確認することもできます。

構成要素

このテストを構築するには、以下のプロダクト、機能、ツールを使用します。

Google Kubernetes Engine（GKE）マネージド DRANET: これは、Pod 間でリソースのリクエストや共有ができるマネージド機能です。GPU と TPU をサポートしています。このテストでは、2 つの異なるリージョンで TPU を使用し、マネージド DRANET を使用してネットワークを割り当てました。
マルチクラスタ GKE Inference Gateway: AI / ML 推論ワークロードを複数の GKE クラスタ間で負荷分散します。これはフェイルオーバーの状況で効果的です。今回のテストではこれを試します。このテストをサポートするタイプは、マルチクラスタクロスリージョン内部アプリケーションロードバランサ（gke-l7-cross-regional-internal-managed-mc）です。
Cloud Storage FUSE: データ、モデル、チェックポイント、ログを Cloud Storage に直接保存できるようにします。デプロイを高速化するために、オープンソースの Gemma モデルをこのストレージにダウンロードし、そこから取得するようにしました。
Virtual Private Cloud（VPC）: 分離された安全な通信を内部ロードバランサとコンピューティングノードに提供する、基盤となるグローバルネットワークです。
GKE フリート: フリートは、個別のリージョンクラスタを、統合された管理コントロールプレーン下にグループ化します。
TPU v6e: モデルのサービングに必要なハイパフォーマンスコンピューティングを提供する、Google のカスタム AI アクセラレータです。使われていた VM ファミリータイプは、2x2 スライスの ct6e-standard-4t でした。

設計パターンの例

目的は、異なるリージョンにある 2 つの GKE クラスタに LLM モデル（Gemma 3）をデプロイすることです。各クラスタは 4 つの TPU v6e チップを使用します。モデルは Cloud Storage に保存する必要があります。ワークロードは、マルチクラスタ対応の GKE Inference Gateway を使用して提供します。ユーザーに最も近いリージョンにトラフィックをルーティングする必要があります。また、いずれかのリージョンで障害が発生した場合は、もう一方のリージョンにフェイルオーバーする必要があります。

設定手順

2 つのリージョンでプロジェクトの TPU にアクセスするには、それらのリージョンで必要な割り当てを確保しておく必要があります。

最初の手順: 環境を設定する。

予約と同じゾーンに標準 VPC を作成し、ファイアウォールルールとサブネットを設定します。
プロキシ専用サブネットを作成します。これは、GKE Inference Gateway にアタッチした内部リージョンアプリケーションロードバランサで使用されます。
トラフィックとヘルスチェックを許可するファイアウォールルールを設定します。
ゲートウェイ用に両方のリージョンで静的内部 IP アドレスを予約します。
Cloud Storage FUSE バケットをプロビジョニングし、専用の IAM サービスアカウントを構成します。これを Kubernetes Workload Identity にバインドし、Pod がバケットを安全にマウントしてモデルの重みを直接読み取れるようにします。

次の手順: 標準の GKE クラスタとノードプールを作成する。

選択したリージョンに、構成済みの 2 つの独立した GKE クラスタをデプロイします。
クラスタの作成時に、Gateway API（--gateway-api=standard）と Cloud Storage FUSE CSI ドライバ（--addons GcsFuseCsiDriver）を有効にします。
両方のクラスタに、専用の TPU v6e ノードプール（ct6e-standard-4t）を作成します。
---accelerator-network-profile=auto フラグと --node-labels=cloud.google.com/gke-networking-dra-driver=true フラグを設定し、これらの TPU ノードプールでマネージド DRANET を有効にします。

次の手順: フリート登録を介してグローバルメッシュを確立する。

フリートの作成と登録の設定の手順に沿って、統合された GKE フリートに両方の GKE クラスタを登録します。
フリートでのマルチクラスタサービスディスカバリとマルチクラスタ Ingress を有効にします。
プライマリリージョンを構成ハブとして指定し、両リージョンにわたるルーティングルールのコントロールプレーンとして機能させます。

次の手順: AI ワークロードをデプロイする。

Kubernetes の一時ジョブを使用して、Gemma 3（gemma-3-27b-it）モデルの重みを Cloud Storage バケットに直接ダウンロードします。
割り当てモードが「All」に設定されたマネージド DRANET デバイスクラス（deviceClassName: netdev.google.com）を明示的にリクエストする、ResourceClaimTemplate を定義します。

code_block: <ListValue: [StructValue([('code', 'apiVersion: resource.k8s.io/v1\r\nkind: ResourceClaimTemplate\r\nmetadata:\r\n name: all-netdev\r\n namespace: default\r\nspec:\r\n spec:\r\n devices:\r\n requests:\r\n - name: req-netdev\r\n exactly:\r\n deviceClassName: netdev.google.com\r\n allocationMode: All'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddbacb0a0>)])]>

両リージョンの TPU ノードに推論サーバー（vLLM など）をデプロイします。Pod 仕様で 2x2 TPU トポロジのノードセレクタを使用し、4 つの TPU を正確にリクエストして、netdev クレームをマウントするようにします。これにより、Pod は標準のイーサネットとともに専用のアクセラレータネットワークを確実に利用できるようになります。

次の手順: マルチクラスタ推論ゲートウェイを構成します。

必要なカスタムリソース定義（CRD）をインストールし、Kubernetes が InferenceObjective などの特殊なルーティングオブジェクトを処理できるようにします。
KV キャッシュ使用量など、ハードウェアの使用状況を追跡する、AutoscalingMetric をデプロイします。
Helm を使用して、両方のリージョンから独立した AI デプロイを、単一の論理 InferencePool にグループ化します。
クロスリージョンゲートウェイとそれに関連付けられた HTTPRoute をデプロイし、受信するグローバルトラフィックを管理します。
ヘルスチェックとバックエンドポリシーをプールに適用し、ロードバランシングでカスタムハードウェア指標を使うようにします。

InferenceObjective を構成して、過負荷状態の TPU を回避し、可用性が最も高いリージョンにプロンプトをルーティングするよう、ゲートウェイに指示します。

code_block: <ListValue: [StructValue([('code', 'apiVersion: gateway.networking.k8s.io/v1\r\nkind: Gateway\r\nmetadata:\r\n name: cross-region-gateway\r\n namespace: default\r\nspec:\r\n gatewayClassName: gke-l7-cross-regional-internal-managed-mc\r\n addresses:\r\n - type: networking.gke.io/named-address-with-region\r\n value: "regions/europe-west4/addresses/gemma-gateway-ip-europe-west4"\r\n - type: networking.gke.io/named-address-with-region\r\n value: "regions/us-east5/addresses/gemma-gateway-ip-us-east5"\r\n listeners:\r\n - name: http\r\n protocol: HTTP\r\n port: 80\r\n---\r\napiVersion: gateway.networking.k8s.io/v1\r\nkind: HTTPRoute\r\nmetadata:\r\n name: gemma-route\r\n namespace: default\r\nspec:\r\n parentRefs:\r\n - name: cross-region-gateway\r\n kind: Gateway\r\n rules:\r\n - backendRefs:\r\n - group: networking.gke.io\r\n kind: GCPInferencePoolImport\r\n name: gemma-pool\r\n port: 8000\r\n---\r\napiVersion: networking.gke.io/v1\r\nkind: HealthCheckPolicy\r\nmetadata:\r\n name: gemma-health-check\r\n namespace: default\r\nspec:\r\n targetRef:\r\n group: networking.gke.io\r\n kind: GCPInferencePoolImport\r\n name: gemma-pool\r\n default:\r\n config:\r\n type: HTTP\r\n httpHealthCheck:\r\n requestPath: /health\r\n port: 8000\r\n---\r\napiVersion: networking.gke.io/v1\r\nkind: GCPBackendPolicy\r\nmetadata:\r\n name: gemma-backend-policy\r\n namespace: default\r\nspec:\r\n targetRef:\r\n group: networking.gke.io\r\n kind: GCPInferencePoolImport\r\n name: gemma-pool\r\n default:\r\n timeoutSec: 100\r\n balancingMode: CUSTOM_METRICS\r\n trafficDuration: LONG\r\n customMetrics:\r\n - name: gke.named_metrics.tpu-cache\r\n dryRun: false\r\n maxUtilizationPercent: 60\r\n---\r\napiVersion: autoscaling.gke.io/v1beta1\r\nkind: AutoscalingMetric\r\nmetadata:\r\n name: tpu-cache\r\n namespace: default\r\nspec:\r\n selector:\r\n matchLabels:\r\n app: gemma-server\r\n endpoints:\r\n - port: 8000\r\n path: /metrics\r\n metrics:\r\n - name: vllm:kv_cache_usage_perc\r\n exportName: tpu-cache\r\n---\r\napiVersion: inference.networking.x-k8s.io/v1alpha2\r\nkind: InferenceObjective\r\nmetadata:\r\n name: gemma-objective\r\n namespace: default\r\nspec:\r\n priority: 10\r\n poolRef:\r\n name: gemma-pool\r\n group: "inference.networking.k8s.io"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddbacb190>)])]>

フェイルオーバーのテスト

プライマリリージョンの障害をシミュレートして、高可用性アーキテクチャを検証します。プライマリのデプロイがオフラインになると、ゲートウェイは障害を自動的に検出し、その後のすべてのユーザーリクエストをアクティブなセカンダリクラスタへシームレスに再ルーティングします。これにより、トラフィックをドロップすることなく継続的な可用性が確保されます。

次のステップ

上述の機能に関するハンズオン Codelab と詳細については、以下をご覧ください。

ハンズオン Codelab: TPU、Cloud Storage FUSE、マネージド DRANET を使用してマルチクラスタ GKE Inference Gateway を構築する
ドキュメント一式: DRANET
ドキュメント: AI Hypercomputer

ご質問やご意見がございましたら、Linkedin 経由で筆者までご連絡ください。

- デベロッパーリレーションズエンジニア、Ammett Williams

Cloud Run での AI のコールドスタートに関するガイド

Thu, 04 Jun 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 5 月 28 日に、Google Cloud blog に投稿されたものの抄訳です。

あるデベロッパーが Reddit で、複数のリージョンにまたがる Cloud Run で AI のコールドスタートを管理する「賢明な方法」はないかと質問しているのを見かけました。最大 20 秒にも及ぶ起動レイテンシに悩まされており、ユーザーが応答を待っている間にインフラストラクチャがスピンアップするという状況にもどかしさを感じていました。

そのディスカッションには、サーバーレス GPU をほぼ諦めかけていたデベロッパーも多数参加しており、中にはレイテンシを回避するためだけに GKE に戻す人もいました。そこで私は、AI のコールドスタートの仕組みを深く掘り下げ、その「賢明な方法」を見つけ出せるかどうか確かめてみることにしました。

Cloud Run で Gemma 4 などのモデルをホストする方法について調査していたところ、Google Cloud Next '26 で Oded Shahar（Cloud Run のシニアエンジニアリングマネージャー）とゲストスピーカーの Ajay Nair 氏（Elastic のプラットフォーム担当グローバルバイスプレジデント）と一緒に共同プレゼンテーションを行う機会に恵まれました。

そのセッション「Cloud Run でカスタムモデルを使用して AI アーキテクチャを構築する」で、Nair 氏は、Cloud Run の「ゼロへのスケーリング」という効率性を維持しながら、17 種類以上のモデルバリエーションで 1 日数百万件のリクエストの処理を可能にした、Elastic の本番環境で実証済みの戦略を共有しました。

Cloud Run でカスタムモデルを使用して AI アーキテクチャを構築する

Nair 氏は、その秘訣はモデルそのもののみならず、GPU を管理すべきインフラストラクチャとしてではなく、代替可能なコンピューティングとして扱うことにあると教えてくれました。

その時、コールドスタートのレイテンシを最小限に抑えることは、単にモデルだけの問題ではなく、それを高速でスケーラブルかつ安全に維持するためのインフラストラクチャのパターンやアーキテクチャに関する決定も重要であることに気付いたのです。

AI のコールドスタートの仕組み

公式の Google Cloud GPU パフォーマンスのベストプラクティスで説明されているように、AI のコールドスタートは、標準的なウェブマイクロサービスのコールドスタートとは異なります。単にコードを起動するだけでなく、ギガバイト単位の重みを専用の物理アクセラレータに転送させるからです。

これは、4 段階のレースだと考えてください。各段階（フェーズ）を最適化しなければ、ユーザーを失うことになってしまいます。

フェーズ 1: インフラストラクチャのプロビジョニング（約 5 秒）

Cloud Run は物理 GPU を割り当て、プリインストールされた NVIDIA ドライバを追加します。Google がドライバを管理するため、Dockerfile が膨らむことはありません。

フェーズ 2: ブロックレベルのコンテナイメージストリーミング（1 ～ 2 秒）

Cloud Run は「イメージストリーミング」を採用しており、起動に必要なブロックのみを取得します。15 GB の CUDA イメージでも、実際は小さな Node.js アプリと同じくらいの速さで起動できます。

フェーズ 3: エンジンの初期化（5 ～ 15 秒）

ここで、推論エンジン（vLLM、Ollama）がウォームアップします。これは CPU 負荷が高い処理であり、多くのユーザーが気付かないうちにスロットリングされる部分です。

フェーズ 4: モデルの読み込みと VRAM への転送

これが最後の難関です。モデルの重みをストレージから GPU メモリへと転送します。CPU が重要視される標準的なウェブアプリとは異なり、ここでは GPU メモリが主な制約要因となります。モデルの重みが GPU メモリに収まりきらない場合、より低速なシステム RAM にスワップされるため、パフォーマンスが大幅に低下します。

AI のコールドスタートを処理するためのベストプラクティス

「賢明」な本番環境を構築するために、GPU を使用した AI 推論に関する Google Cloud の公式ドキュメントを参考に、いくつかの重要なポイントをご紹介します。

フェーズ 4 の最適化

適切なデプロイオプションの選択

フェーズ 4 は、ギガバイト単位の重みをストレージから GPU メモリへと転送する「最後の難関」です。ストレージの選択によって、この転送の速度が決まります。

Cloud Storage（同時ダウンロード）- 最速: Google Cloud CLI（gcloud storage cp）を使用すると、モデルファイルを並列でダウンロードできます。ネットワークスループットを最大化し、転送時間を大幅に短縮できるため、大規模な重みに対して推奨される方法です。
Cloud Storage（FUSE）- 最も簡単: バケットをローカルファイルシステムとしてマウントすることで、「コード変更を不要」にします。ただし、最初のダウンロードを並列化しないため、大規模なモデルの重みに対してはかなり遅くなります。
コンテナイメージ - 10 GB 未満に最適: 小規模なモデルの場合、Cloud Run のイメージストリーミングを使用してイメージに重みを付けるのが効率的です。ただし、10 GB を超えるモデルの場合、インポートやストリーミングのオーバーヘッドがボトルネックとなる可能性があります。
インターネット: 避けるべきです。本番環境での推論において、最も時間がかかり、かつ最も予測困難な方法です。

モデルの形式とサイズ

フェーズ 4（モデルの読み込みと VRAM への転送）の時間の短縮につながる「裏技」が、モデルの形式とサイズの最適化です。このフェーズは、ギガバイト単位のデータを VRAM に転送できる速度によって制約されるため、より小さく効率的なファイルが重要となります。

4 ビット量子化: これはコールドスタートの究極の裏技です。重みが小さいほど、ストレージから引き出すギガバイト数が減るため、フェーズ 4 のダウンロードと転送のプロセスが直接高速化されます。
高速な形式: 起動時間を最小限に抑えるために、GGUF のような読み込み時間が短いモデル形式を選択します。最も高速なパフォーマンスを得るには、Python の「pickle」ファイルの使用を避け、ゼロコピー読み込みを実現する Safetensors を使用します。
VRAM の容量の確保: 量子化モデルを使用して、重みが GPU メモリ内に完全に収まるようにします。モデルが VRAM を超えると、システムは非常に低速な RAM にスワップするため、フェーズ 4 が行き詰まってしまいます。

フェーズ 3 と 4 の最適化: インフラストラクチャとネットワークの活用手段

これらのインフラストラクチャ設定は、起動プロセスの最も要求の厳しい部分を高速化するために必要なリソースを提供します。

起動時の CPU ブースト（フェーズ 3 を高速化）

この機能により、起動時の CPU 性能が一時的に 2 倍になります。1 vCPU インスタンスが、起動中およびサービス提供開始後の最初の 10 秒間、2 vCPU に増強されます。エンジンの初期化は CPU 負荷の高い処理であるため、フェーズ 3 ではこの機能が不可欠です。

ダイレクト VPC 下り（外向き）と PGA（フェーズ 4 を高速化）

プライベート Google アクセス（PGA）でダイレクト VPC 下り（外向き）を利用すると、モデルの重み付けトラフィックが Google の内部高速バックボーン上に留まります。これにより、ネットワークパスが最適化され、ギガバイト単位の重みを VRAM に転送する時間が短縮されます。

同時実行のチューニング（コールドスタートの回避）:

Cloud Run において、「同時実行」とは、プラットフォームがスケールアウトして新しいインスタンスを起動する前に、単一インスタンスが処理できるリクエストの最大数を指します。AI ワークロードの場合、この設定はモデルエンジンの内部並列処理フラグ（例: vLLM の --max-num-seqs や Ollama の OLLAMA_NUM_PARALLEL）と合わせて調整する必要があります。

Cloud Run の最適な同時実行数を算出するには、公式の Google Cloud の数式を使用します。

（モデルインスタンスの数 ∗モデルあたりの並列クエリ数）+（モデルインスタンスの数 ∗理想的なバッチサイズ）

例: インスタンスが 3 つのモデルインスタンスを GPU に読み込み、各モデルインスタンスが 4 つの並列クエリを処理でき、理想的なバッチサイズが 4 である場合、Cloud Run の最大同時リクエスト数を 24 に設定します:（3 × 4）+（3 × 4）

計算方法: 目標は、GPU を完全に飽和状態に保ちながら、ユーザーが長いキューで待機しないようにすることです。この例では、合計 24 の同時リクエストが 2 つの機能グループに分割されています。

アクティブな処理（12 リクエスト）:（3 インスタンス × 4 クエリ）で計算され、GPU が任意の時点でアクティブに処理できるリクエストの合計数を表します。
「次のバッチ」バッファ（12 のリクエスト）:（3 インスタンス × 4 バッチサイズ）で計算されます。これらは、コンテナ内で「待機中」のリクエストです。GPU が最初のバッチを完了すると、すぐにこれらの待機中のリクエストを処理します。

この値を VRAM の許容範囲内で最大（通常 10 ～ 20 ユーザー）にチューニングすることで、1 つのウォームインスタンスで多数のリクエストを処理できるようになり、新しいスケールアウトイベントやそれに伴うコールドスタートをトリガーせずに済みます。

スケーリング制御（しきい値の調整）

上記の式は最大容量を定義するものですが、Cloud Run が次のインスタンスを起動するタイミングを調整することもできます。Cloud Run のオートスケーラーは通常、60% の使用率を目標としていますが、時間がかかる AI のコールドスタートの場合、スケーリング制御を使用して、このしきい値を 80% または 90% に引き上げることができます。

同時実行目標数: この値を大きくすると、スケールアウトがトリガーされる前に、単一のウォームインスタンスにより多くのリクエストを「詰め込む」ことができます。
CPU 目標値: CPU 目標値を引き上げることで、初期化や高負荷の推論によって CPU 使用率が一時的に急上昇しただけで、プラットフォームが新しいインスタンスを起動するのを防ぐことができます。

スケーリングと信頼性に関する戦略

コールドスタートを完全に回避するか、あるいは積極的に管理するのが、コールドスタートへの最善の対処法である場合があります。

単一リージョンの「常時稼働」のトレードオフ

グローバルにデプロイする場合、すべてのリージョンで最小インスタンス数を 1 に設定すると費用がかさみます。代わりに、1 つのリージョンのみで「常時稼働」のサービスを行うことを検討してください。グローバルネットワークの遅延が 100 ミリ秒でも、ローカルのコールドスタートに 20 秒かかるよりは、はるかに優れたユーザーエクスペリエンスを提供できます。

15 分間の猶予期間: よく聞かれる質問に、「リクエストの後、インスタンスはどのくらいの間ウォーム状態を維持しますか？」というのがあります。Cloud Run は通常、インスタンスがアイドル状態（リクエストを処理していない状態）になってから 15 分間インスタンスの稼働を維持します。トラフィックが予測可能で、10 ～ 12 分ごとに発生する場合、「常時稼働」のサービスは必要ないかもしれません。プラットフォームのデフォルトのシャットダウンポリシーにより、次のユーザーにウォームインスタンスが無料で準備されます。

「先手を打った措置」戦略

時として、コールドスタートに対処する最善の方法は、先手を打った措置を講じることです。たとえば、ユーザーが「新しいチャット」をクリックしたり、テキスト領域にカーソルを合わせたりした時など、UI で次のリクエストを予測できる場合は、サービスに向けてすぐに軽量なヘルスチェックを送信できます。ユーザーがプロンプトの入力を終える頃には、コールドスタートの最初の 2 つのフェーズ（インフラストラクチャのプロビジョニングとコンテナイメージのストリーミング）は、バックグラウンドですでに完了しています。

上級者向けのヒント: 非推論エンドポイントを使用します。この「先手を打った措置」を可能な限り高速化するには、「hi」のようなダミープロンプトを送信するのではなく、常に非推論エンドポイントを使用します。

高速な理由: 非推論エンドポイント（vLLM の /v1/models や Ollama の /api/tags など）は、コンテナのウェブサーバーが起動した瞬間に処理されます。そのため、時間のかかる「フェーズ 4」のモデルの読み込みや VRAM への転送の完了を待つことなく、成功レスポンスを送信できます。
チャット履歴への干渉なし: これらのエンドポイントはモデルの補完ロジックをトリガーしないため、ユーザーの実際のチャット履歴に干渉したり、バックエンドで誤ってセッションの作成をトリガーしたりすることはありません。

推奨されるエンドポイント:

vLLM: GET /health または GET /v1/models
Ollama: GET /api/tags または GET /api/version

VRAM の起動プローブの調整

AI モデルは、ストレージから GPU メモリにギガバイト単位の重みを転送するのにかなりの時間を要します（フェーズ 4）。起動チェックが何度も失敗すると、Cloud Run はコンテナが破損していると判断して強制終了します。

これを回避するには、以下を行います。

失敗しきい値を引き上げる: 高い failureThreshold を使用します（例: 60 以上）。許容される合計起動時間は failureThreshold \times periodSeconds の積であるため、しきい値を 60、間隔を 5 秒にすると、5 分間というモデルを読み込むために十分な時間が確保されます。
最大 30 分を活用: 標準サービスでは起動時間が 4 分に制限されていますが、Cloud Run では負荷の高いワークロードに対して、最大 30 分（1,800 秒）の合計起動時間をサポートしています。
偽陽性の回避（Ollama 対策）: Ollama のようなエンジンを使う場合、サービスの開始直後、モデルが実際に VRAM に読み込まれる前に TCP ポートが開かれることがあるため、注意が必要です。コンテナのエントリポイントスクリプトで必ずモデルをプリロードし、モデルが確実に推論を実行できる状態になった時点で起動プローブが成功するようにしてください。

Elastic の戦略から得られる教訓

NEXT ‘26 のセッションにおいて、Ajay Nair 氏は、Elastic が GPU を管理すべきインフラストラクチャとしてではなく、代替可能なコンピューティングとして扱うことを可能にした 3 つのアーキテクチャに関する決定事項について強調しました。

コンパイル費用の回避: vLLM で enforce_eager=True を設定することで、わずかなスループットを犠牲にする代わりに、コールドスタートが数分ではなく 1 分未満で完了するようにしました。
スタンドアロンのチェックポイント: 各 LoRA バリエーションを事前にスタンドアロンのチェックポイントに統合することで、実行時のアダプタの切り替えに伴うレイテンシを回避しました。
1 つのワークロード、1 つのサービス: モデル、タスクアダプタ、トラフィックパターンによって定義される、それぞれ個別のスケーラブルなワークロードは、独自の Cloud Run サービスとしてデプロイされます。これにより、約 15 のモデルファミリーで 30 以上のサービスが生成され、一部のモデルはタスク（例: v5 の取得とクラスタリング）やクエリ / パッセージの役割によって分割されています。

準備ができたら

コールドスタートのプロセスを最適化できるかどうかが、趣味のプロジェクトとプロダクションレディなアプリケーションとの違いを決定付けます。この最適化の最大のメリットは、Cloud Run が NVIDIA ドライバと CUDA のインストールを処理し、インスタンスを約 5 秒で起動できることです。

詳細については、次の公式ドキュメントをご覧ください。

技術的な詳細については、Google Cloud Next '26 のセッションの録画をご覧になることを強くおすすめします。サーバーレスインフラストラクチャで高性能なオープンモデルをホストするための最も包括的なブループリントを確認できます。

開発をお楽しみください。

この記事に対して、レビューとフィードバックを提供してくださった、Cloud Run チームの Sara Ford と Shane Ouchi、Elastic の Zac Li 氏に心より感謝いたします。

- Google Cloud デベロッパーリレーションズ、AI エンジニアリング責任者、Shir Meir Lador

Gemini API キーと Google API キーの保護

Tue, 02 Jun 2026 02:30:00 +0000

※この投稿は米国時間 2026 年 5 月 22 日に、Google Cloud blog に投稿されたものの抄訳です。

現在、AI サービスは API キーに大きく依存しています。ユーザーが AI エージェントを実行するには、有料トークン、サブスクリプション、または有料アカウントを示す API キーを提示する必要があります。API キーは簡単に使用できますが、安全でない方法で使用することも同じくらい簡単です。キーが盗まれると、環境が侵害され、不正使用や悪用につながります。

ユーザーが講じるべき自衛策についてのチュートリアルを求めるスレッドが Reddit 内の r/googlecloud ページに投稿されているのを見たことをきっかけに、このブログ投稿を書くことにしました。この投稿では、Google が作成した API キーのリスクを軽減し、セキュリティを向上させるための簡単な手順をいくつかご紹介します。

Google API キーは、Gemini やその他の AI Google プロダクト、あるいは Google Cloud API にアクセスするのに使用されます。Gemini API キーは、バックグラウンドで使用される標準の Google API キーです。ここでは Google API キーのセキュリティに焦点を当てますが、これらの推奨事項の一部は、他の場所で作成された API キーやプロダクトトークンにも適用できます。

ステップ 1: 新しい API キーを生成する

どこから始めても、最終的には Google Cloud プロジェクトのいずれかで新しい API キーを作成することになります。Cloud コンソールの [API とサービス] メニューにある [認証情報] を使用することになるでしょう。

代わりに gcloud services api-keys create コマンドを使用することもできます。また、新しい Google Cloud API キーを作成できる他のインターフェースもあります。経路やインターフェースにかかわらず、次のことを行う必要があります。

他の目的に使用されていないスタンドアロンプロジェクトでキーを作成する。
新しい API キーの API アクセスとクライアントアプリケーションを制限する。

これらの手順により、キーの潜在的なリーチが制限され、問題が発生した場合のトラブルシューティング作業が大幅に簡素化されます。

API の制限

API の制限では、キーを使用してアクセスできるサービスを指定します。制限のないキーは作成しないでください。キーが盗まれると、攻撃者は利用可能なサービスにユーザーの費用でアクセスできてしまうからです。

そのキーが使用されるサービスのリストを常に制限して、キーが乗っ取りや漏洩の被害にあった場合の潜在的な損害（影響範囲）を軽減します。間接的な UI を使用して新しいキーを作成する場合は、注意が必要です。たとえば、Firebase で API キーを作成するときは、使用できる API の数を Datastore、Firestore、Cloud SQL Admin などの 24 個に制限します。

Firebase を使用してウェブサイトを保存する場合は、ほとんどの API を使用しないでしょう。AI Studio で使用する API キーを作成するときは、アクセスできる API を「Gemini API」のみに制限してください。

注意点:

デフォルトでは、新しい API キーは制限なしで作成されます。
選択したい API を検索しても見つからない場合は、使用している Google Cloud プロジェクトでその API が有効になっていない可能性があります。まず Cloud コンソールの [API ライブラリ] に移動し、名前で API を検索して、有効にします。
Cloud コンソールまたは gcloud CLI では、すべてのアクションを実行できます。他のインターフェース（Firebase など）では、API キーの一部のパラメータにアクセスできない場合があります。

アプリケーションの制限

API 制限がキーを使用できるサービスを制限するのと同様に、アプリケーションの制限はキーを使用できるアプリケーションを制限します。たとえば、Google AI Studio でのみ使用する API キーを作成する場合、アプリケーションの制限をウェブサイト https://aistudio.google.com/ に設定すると、Gemini を利用して大量のトークンを大規模に消費する自動化でキーが使用されるのを防ぐことができます。

次のいずれかのタイプの制限を 1 つ以上設定できます。

URL のリストを使用してウェブサイトやウェブアプリケーションの制限を設定する
IPv4 や IPv6 アドレスのリストまたはサブネットマスクを使用してサービスの制限を設定する
バンドル ID のリストを使用して iOS アプリケーションの制限を設定する
パッケージ名と証明書フィンガープリントのペアのリストを使用して Android アプリケーションの制限を設定する

キーに対して適用できるアプリケーションの制限は 1 種類のみです。アプリケーションの種類ごとに指定の API キーを作成します。アプリケーション種類ごとにキーを用意しておくと、キーの使用状況を把握し、侵害された可能性のあるキーを調査する際に役立ちます。

ステップ 2: API キーを保存する

ここで今一度確認したいことは、API キーはユーザーの ID とペアになっていないということです。API キーは誰でも利用できます。そのため、キーを安全に保管することは、ステップ 1 でのキーの使用の制限と同じくらい重要です。

ルールは簡単です。キーを簡単に見える場所に保存してはいけません。

アプリケーションで API キーを使用する場合は、Secret Manager または同様のシークレット管理サービスに保存します。Secret Manager を使用すると、API キーを Cloud Run 環境と GKE 環境に簡単に挿入できます。ただし、キーの保護を強化するために、コードでキーを読み取ることもできます。例については、ドキュメントをご覧ください。

外部アプリケーションで API キーを使用する場合、キーの入力を求められたら、アプリケーションがキーをどのように管理しているかを確認する追加の手順を踏んでください。キーがどのように保存され、リクエストでどのように使用されているかを調べる必要があります。ウェブアプリケーションの場合は、ブラウザのデベロッパーツールを使用してアプリケーションのトラフィックを検査し、キーが暗号化されていない通信チャネルで送信されていないことを確認します。たとえば、Google AI Studio は暗号化されたローカルストレージを使用し、TLS で暗号化されたチャネルを介してキーを送信します。

問題が発生した場合

キーが侵害された疑いがある場合、どうすべきでしょうか？クレジットカードの場合と同じように、単純な手順で対処します。まず、キーを削除します。Cloud コンソールで削除するか、gcloud services api-keys delete コマンドを使用して削除できます。実際は侵害されていなかったことがわかった場合は、30 日以内であれば削除を取り消すことができます。

どのキーが侵害されたかわからない場合はどうすればよいでしょうか？その場合は、次の 2 つのステップで調査する必要があります。

組織またはプロジェクト内のすべての API キーを検出する
このキーでアクセスできる API の API 使用量のグラフを確認する

すべての API キーを確認する

API キーのリソースを見つける方法は複数あります。Cloud コンソールの [アセットインベントリ] を使用し、ダッシュボードを [リソースの種類] でフィルタリングして apikeys.Key を確認できます。このリソース種類が表示されない場合は、[さらに表示…] を見つけてクリックし、リソース種類のリストを展開します。削除された API キーもリストに表示されます。

CLI を使用する場合で、特定のプロジェクトがわかっている場合は、gcloud services api-keys list コマンドを使用できます。

組織内のすべてのアクティブなキーを表示するには、gcloud asset search-all-resources コマンドを使用し、その JSON 出力をクエリして削除されたキーを除外する必要があります。

code_block: <ListValue: [StructValue([('code', 'gcloud asset search-all-resources \\\r\n --scope=\'organizations/123456789012\' \\\r\n --asset-types=\'apikeys.googleapis.com/Key\' \\\r\n --read-mask="name,displayName,versionedResources" \\\r\n --format=json \\\r\n --order-by=\'createTime\' \\\r\n| jq \'.[] | select(.versionedResources | all(.resource.data.deleteTime == null))\''), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddba1c4f0>)])]>

API の使用量を確認する

API キーの使用状況を追跡する方法があります。Cloud Monitoring の serviceruntime.googleapis.com/api/request_count 指標を使用することです。この指標は、さまざまなサービスが呼び出された回数を示します。特定の API キーのサービスリクエスト数を確認するには、指標の credential_id ラベルを使用し、API キーの一意の ID でフィルタリングする必要があります。指標のデータを確認するには、Metrics Explorer を使用するか、次の PromQL 式で Monitoring API を呼び出します。

code_block: <ListValue: [StructValue([('code', 'sum(\r\n rate({\r\n "__name__"="serviceruntime.googleapis.com/api/request_count",\r\n "monitored_resource"="consumed_api",\r\n "credential_id"="apikey:00000000-0000-0000-0000-000000000000"\r\n }[${__interval}])\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddba1cc40>)])]>

service_name ラベルを使用して、API 名（例: mapstools.googleapis.com）でこの指標をさらにフィルタリングできます。

API キーの ID を確認するには、次のいずれかの方法を使用する必要があります。

Cloud コンソールを使用して [認証情報] ページを開き、目的の API キーを選択します。ブラウザで API キーページの URL を確認します。URL は https://console.cloud.google.com/apis/credentials/key/[KEY_ID]?project=[PROJECT_ID] のように表示されます。[KEY_ID] の部分をコピーします。
gcloud CLI を使用して、gcloud services api-keys list --format='value(displayName,uid)' コマンドを実行し、表示名でキーを見つけます。表示名の横にある UID をコピーします。

API 呼び出しが異常に多い場合は、通常、API キーが侵害され、悪意のあるユーザーによって API にアクセスするために使用されたことを示します。

ステップ 3: API キー管理のハイジーン

エンジニア、経験豊富なクラウドユーザー、あるいは単に試してみようという方であっても、環境が乗っ取られるのを防ぐためには、API キーの適切な管理が重要です。

すでに Google API キーを使用している場合は、今すぐ次の対応を行ってください。

所有しているすべての API キーを確認します。
使用しなくなったキーや認識できないキーをすべて削除します（30 日以内であれば復元できますので心配無用です）。
API キーがアクセスできる API を、使用する予定の API のみに制限します。可能であれば、API を使用できるクライアントもリストを使って制限します。
Google Cloud プロジェクトまたは組織を管理している場合は、API キーの管理に必要な作業を最小限に抑えるために apikeys.googleapis.com/Key 組織ポリシーを設定することを検討してください。
API キーを定期的にローテーション（更新）し、まったく同じ制限を共有するキーを新しく作成して置き換えることを検討してください。既存のキーが使用されているすべての場所を追跡して更新してからそのキーを削除するようにしてください。そうすることで、アプリケーションが予期せず破損したり、突然アクセスできなくなったりするのを防ぐことができます。

まとめ

API キーの保護は、クラウドエコシステムを保護するうえで重要なステップです。API とアプリケーションの厳格な制限の実装、安全な保管の利用、消費の積極的なモニタリングは、不正アクセスを防止する非常に効果的な方法です。これらの対策により、開発環境を悪用から保護し、予期しない請求を回避できます。

これらの手法を導入するのに役立つ、実用的なツールとリソースをいくつかご紹介します。

API についてさらに確認する: API キーの管理に関するベストプラクティスを確認し、「Google API を検索して選択する」のラボを実践します。
クイックチュートリアルを見る: Cloud Run シークレットの Secret Manager でのセキュアな管理に関する Google Cloud Tech の動画で、安全な保管のコンセプトが実際にどのように機能するかをご確認ください。
Codelab で実際に体験する: Codelab でPython または Spring Boot を使って Secret Manager を利用してみて、ガイド付き環境で認証情報を安全に取得する練習をします。

ドキュメントで詳細を確認する: 指標の選択、グラフの作成、アラートの設定を通じて API の使用状況を把握する方法をご確認ください。

- シニアデベロッパーリレーションズエンジニア、Leonid Yankulin

Gemini Live Agent Challenge: 受賞者とハイライトを発表

Tue, 02 Jun 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 5 月 16 日に、Google Cloud blog に投稿されたものの抄訳です。

Gemini Live Agent Challenge が無事に終了しました。このチャレンジでは、世界中のデベロッパーに従来の「テキストボックス」から脱却する次世代の AI エージェントの構築を呼びかけました。最初の発表から、151 か国 11,878 人の参加者と 1,536 件のプロジェクト応募まで、その結果は驚くべきものでした。

ミッションは、Gemini Live API、Agent Development Kit（ADK）、Google Cloud の堅牢なインフラストラクチャを使用して、マルチモーダル機能をシームレスに統合し、リアルタイムで「見る、聞く、話す、つくる」をサポートするエージェントを構築することでした。参加者は、ライブ対応のエージェント、クリエイティブストーリーテラー、UI ナビゲーターの 3 つのカテゴリで、インタラクティブ AI の限界に挑戦しました。

最優秀賞を受賞したビルダーの皆様、おめでとうございます。優勝チームは、技術的な正確さと大胆な想像力を組み合わせ、ユーザーがエージェントと対話して体験する方法を完全に一新しました。受賞者のうち 2 人の開発者は、Google Cloud Next 2026 の会場でも表彰されました。受賞エージェントの完全なリストとともに、受賞者の体験をご紹介します。

Google Cloud Next '26 で各部門の受賞者を発表

部門賞を受賞した Jeremiah Somoine 氏と Bryen Param 氏は、ラスベガスで開催される Google Cloud Next 2026 に招待され、より広範なデベロッパーコミュニティと自身の経験や知見を共有しました。受賞者 2 名は、展示会場のデベロッパーシアターでライトニングトークを行い、GDE および認定ラウンジのクリエイタースタジオポッドで独占インタビューを受けました。

イベント期間中、Bryen 氏は drone-copilot の開発における主なインスピレーションについて語りました。プロジェクトの原動力となったのは「モデルが現実世界とやり取りできたらどうなるだろうか？」という疑問だったと説明し、マルチモーダル機能が AI と物理環境のギャップを埋める方法を紹介しました。

現役大学生の Jeremiah 氏は、Sankofa の開発プロセスを振り返り、「技術的な制限に対する最善の対応は、創造力だった」と述べています。次世代の AI アプリケーションの構築を目指す他の学生たちへのアドバイスを求められたとき、彼はテクノロジーを実際に体験する機会があれば、すぐに始めることが重要だと強調しました。「学ぶには、実際にやってみるのが一番です」と語り、意欲的なデベロッパーに、とにかく飛び込んで構築を始めてみるよう促しています。

受賞者

最優秀賞: ORION - Operating Room Intelligent Orchestration Node 作成者: Aditya Shukla 氏

ORION（Operating Room Intelligent Orchestration Node）は、音声指示によるロボット手術の支援コパイロットです。外科医は、スクラブを破ることなく、自然に話してすぐに回答を得たり、ディスプレイにライブデータを表示したり、リアルタイムの視覚的支援を受けたりできます。

Orion - 音声指示による手術 AI アシスタント | Gemini Live Agent ハッカソン

ライブ対応エージェント部門の受賞者: drone-copilot 作成者: Bryen Param 氏

ドローンコパイロットは、ユーザーがジョイスティックや複雑なメニューを使用する代わりに、ドローンと自然なリアルタイムの会話ができるようにすることで、ハードウェアの操作方法を変革します。ユーザーは話すだけで、ドローンにナビゲーション、自律的な視覚検査、周囲の状況の説明を指示できます。ドローンはリアルタイムで音声応答し、アクションを確認します。

ドローンコパイロット: Gemini Live API を使用した音声制御ドローンと自律検査

クリエイティブストーリーテラー部門の受賞者: Sankofa 作成者: Jeremiah Somoine 氏

Sankofa は、マルチモーダル AI の「グリオ」（西アフリカの伝統的な語り部）として機能し、断片的な家族の歴史を没入感のある物語に変えます。ユーザーのわずかな詳細情報に基づいて、豊かな音声ナレーション、水彩画の画像、アンビエントサウンドスケープを織り交ぜて歴史物語を紡ぎ出します。ユーザーは、語り部とリアルタイムで音声会話をしながら、自分のルーツをさらに探ることができます。

Sankofa デモ動画

UI ナビゲーター部門の受賞者: Moonwalk 作成者: Enaiho Uwas Paul 氏、Aman Kumar Sah 氏

Moonwalk は、会話型のハンズフリーデスクトップアシスタントです。ユーザーは声だけでコンピュータを直感的に操作し、複雑なタスクを完了できます。個人の好みや過去のやり取りを記憶することで、インテリジェントなコパイロットとして機能し、マウスやキーボードをシームレスに制御して、フライトの予約やスプレッドシートの管理などの日常的なワークフローを実行します。ユーザーはただ座って話すだけです。

Moonwalk のデモ動画 #geminiliveagentchallenge

マルチモーダル統合とユーザーエクスペリエンス部門最優秀賞: Wand 作成者: David Li 氏

Wand は、ボイスファーストのポインタ対応ブラウザアシスタントです。自然な会話とハンドジェスチャーを組み合わせて、あらゆるウェブサイトをシームレスに操作できます。画面を指差して「この動画を再生して」や「ここを拡大して」などと話しかけるだけで、このライブ対応エージェントがクリック、検索、コマンドの実行を即座に行うお手伝いをします。マウスやキーボードに触れる必要はありません。

Wand -- ユーザーとともに見て、検索して、クリックするライブ対応エージェント

技術運用とエージェントアーキテクチャ部門の最優秀賞: JohnKeats.AI 作成者: Matthew Keats 氏

JohnKeats.AI は、ユーザーの言葉に積極的に耳を傾け、解決策を急いで提供することなく、ユーザーの気持ちに寄り添うことを目的としたボイスファーストの感情コンパニオンです。ピッチ、ペース、トーンなどの微妙な口調を処理することで、ユーザーの感情状態にリアルタイムで自然に反応し、深い思考で感情に寄り添う会話機能を提供します。

JohnKeats.AI — 黙るべき時を知るために構築された初の AI エージェント

イノベーションおよびソートリーダーシップ部門の最優秀賞: Rayan Memory 作成者: Yusuf Elnady 氏

Rayan Memory は、日々の学習内容を完全に探索可能な 3D の「記憶の宮殿」に変えることで、忘却という普遍的な問題に取り組んでいます。バックグラウンドエージェントが現実世界の音声を受動的に聞き取り、重要なアイデアを物理的なアーティファクトとして抽出します。ユーザーはテーマ別の仮想ルームを歩き回り、専用の AI コンパニオンと会話することで、正確な記憶を簡単に取り出すことができます。

Rayan - 3D の記憶の宮殿が聞き取り、記憶し、話しかける

特別賞: NagarDrishti 作成者: Nikita Dongre 氏、Omkar Dongre 氏

NagarDrishti は、運転中にハンズフリーの音声アシスタントを使用して、市民が安全に道路の穴や冠水を報告できるようにすることで、危険な道路状況に対処します。これらのリアルタイムレポートは、インタラクティブなダッシュボードに即座に表示されます。市の職員は自然言語を使用して、危険な場所を簡単に特定し、重要な修理を管理できます。

特別賞: Ekaette 作成者: Bassey John 氏

Ekaette は、通話とテキストメッセージの両方で動作する会話型のマルチモーダル AI アシスタントを使ってイライラする保留音を置き換えることでカスタマーサービスに革命を起こします。顧客は、通常の電話回線でエージェントと自然に会話しながら、WhatsApp を介してシームレスに写真を共有したり、製品オプションを確認したり、支払いを完了したりできます。

Ekaette - マルチモーダル AI 音声およびメッセージングアシスタント

特別賞: VibeCat 作成者: Sejun Kim 氏、Michael Chang 氏

VibeCat は、画面を継続的に監視し、コンテキストを理解して、ユーザーが尋ねる前に役立つアクションを提案する、プロアクティブな macOS デスクトップコンパニオンです。コマンドを待つのではなく、コードの欠落行の修正やターミナルコマンドの実行などを最初に提案し、ユーザーの許可を得てからタスクを完了します。

vibeCat - プロアクティブなデスクトップコンパニオン

特別賞: Call My Parts 作成者: Sugam Palav 氏、Nikhil Lohar 氏、Siddhant Panday 氏、Vishal Parekh 氏

Call My Parts は、中古車部品の調達という面倒で時間のかかるプロセスを自動化します。調査やベンダーへの連絡を代行してくれます。ユーザーは部品のリクエストを話すだけで、AI エージェントが自律的にベンダーのウェブサイトを検索し、サプライヤーに電話して価格と在庫を確認して、最適な選択肢をランク付けして読みやすいダッシュボードにまとめます。

Call My Parts AI Tool : ハッカソン Gemini Live 2026

特別賞: Relay 作成者: Faith Ogundimu 氏

Relay は、ウェブカメラを使用して物理電子工学プロジェクトをリアルタイムで監視し、ガイドするインタラクティブな AI ラボパートナーです。回路の組み立てを手順を追って支援する音声サポート、配線ミスを事前に検出する機能、組み込みの 3D シミュレーションサンドボックスとパーソナライズされたクイズによるスキルの強化機能が用意されています。

Relay - 電子機器向けのリアルタイム Voice AI および Vision AI チューター | Gemini Live API + Google Cloud

この流れを推し進めましょう

素晴らしいプロジェクトに触発されましたか？Google の最新のプログラムやイベントを通じて、構築を開始し、コミュニティとのつながりを維持しましょう。

Gemini Enterprise Agent Ready（GEAR）にご参加ください。このプログラムは、開発者や意思決定者を支援し、プロダクションレディな AI エージェントを構築、デプロイできるように設計されています
Google Cloud Next 2026 の最新情報: Google Cloud Next は大盛況のうちに終了しました。会場にお越しいただけなかった方、あるいはもう一度あの熱気を味わいたい方は、SNS とライブ配信のハイライトをご覧ください。魅力的な開発者の活躍の一部を会場の雰囲気とともにお楽しみいただけます。
新しいツール、プロダクトの最新情報、今後のハッカソンについていち早く知りたい方は、毎週火曜日のライブ配信をお見逃しなく。午前 9 時（太平洋夏時間）/ 正午（東部夏時間）に配信が開始されます。Google Cloud の最新情報をチェックしてください。

受賞者の皆様、参加者の皆様、本当におめでとうございます。皆様が次にどのようなものを構築されるのか楽しみにしています。

- Google Cloud、プロダクトマーケティングマネージャー、Dilasha Panigrahi

Google I/O '26 が Google Cloud でのエージェント開発にもたらすもの

Mon, 01 Jun 2026 01:00:00 +0000

※この投稿は米国時間 2026 年 5 月 20 日に、Google Cloud blog に投稿されたものの抄訳です。

Google I/O では、Antigravity 2.0 と Managed Agents API を備えた統合開発ツールキットをご紹介しました。これにより、デベロッパーは共有プロトコルレイヤ上でローカルに構築し、クラウドに安全にデプロイできるようになります。このブログ記事では、Gemini Enterprise Agent Platform と Google I/O で発表された新しいデベロッパーツールの組み合わせ方、構築における選択肢の幅を整理し、実際にまず何から試すのがおすすめかをご紹介します。

Vertex AI が Gemini Enterprise Agent Platform に進化し、セッションメモリや一元化されたガバナンスなどの新機能により、エージェントの構築、スケーリング、管理、最適化を行うための包括的なプラットフォームとなりました。そして今回、これらの機能をローカルの開発ツールに直接展開します。Google の目標は、高速なプロトタイピングと、安全でコンプライアンスに準拠した企業向けデプロイの間のギャップを埋めることです。そのために、クイックスタートワークフローか、あるいはスタックの特定のニーズに合わせて本番環境を完全に制御するかを選択できる、モジュール式のアプローチを提供しています。

幅広い選択肢の中で、これらの要素がどのように位置づけられるかを整理すると、次のようになります。

4 つの段階: エージェント構築方法の全体像

エージェント開発のエコシステムは、4 段のはしごのようなものだと考えています。これは、すぐに使える構成から完全なコードファーストの制御まで、ニーズに合わせて調整できるスライダーのように設計されています。これらは意図的に積み上げ式に構成されており、下の段階から素早く始めたとしても、より高度なカスタマイズが可能な上の段階への移行が制限されることはありません。

4 つの段階すべてを支えているのが A2A プロトコルです。この相互運用性により、最初の段階で構築されたエージェントを 4 番目の段階でサブエージェントとして呼び出すことができ、アーキテクチャ全体を同じインフラストラクチャ上でシームレスにスケールできます。

1 段目: Agent Studio（ローコード）

Agent Platform 内のビジュアルワークスペース。Model Garden でモデルを見つけ、プロンプトをエンジニアリングし、ツールを接続して、コードを記述せずにエージェントをリリースします。ビジネス部門のチームや迅速なプロトタイピングに最適です。ここで構築するエージェントは、その下にあるすべてのものとまったく同じランタイムで実行されます。

2 段目: Managed Agents API

I/O で新たに発表された Managed Agents API は、「マシンではなくミッションを管理したい」と考えている技術チームを対象としています。エージェントの動作を定義するだけで、Google Cloud が煩雑な作業を代行するため、管理不要のサービスとしてのエージェント（Agent as a Service）として機能します。

Managed Agents API を使用してエージェントを構成し、Interactions API を使用してエージェントを呼び出します。指示、スキル、ツールをパッケージ化して POST すると、Gemini がエージェントを構築して実行します。

これをデプロイ可能にしているのは、安全性を重視して設計された Google Cloud サンドボックスです。エージェントハーネスは Google のサーバーで実行され、各エージェントには、スキル、Model Context Protocol（MCP）サーバー、サーバーサイドツールがプロビジョニングされた独自の一時的なサンドボックスがあります。A2A および Agent Platform のガバナンスおよびセキュリティとの完全なインテグレーションは、近日公開予定です。

3 段目: Antigravity とその仲間たち

Antigravity は、コーディングタスクやエージェントオーケストレーションに AI を活用したいと考えているデベロッパー向けの主要なソリューションであり、チームがアプリの構築とデプロイの方法を変革できるようにします。デベロッパー向けのコーディング戦略を、複数のサーフェスで共有されるこの単一の強力なハーネスに統合しました。

Gemini モデルファミリーと相互に最適化されており、高い効率性により開発サイクルを加速し、コストを削減します。Antigravity で開発したスキルは、さまざまなサーフェスでそのまま利用できるように設計されています。

コーディングワークフロー内で Google の高度な推論機能を活用し、カスタム開発ループを実装して、アプリケーションの構築、デプロイ、管理の方法を変革したいと考えている開発チームを対象としています。

このたび、以下の新しいツールによってこの機能を拡張しました。

Antigravity 2.0: コーディングエージェントの操作、カスタマイズ、オーケストレーションを行う一元化されたワークスペースを提供する、新しいスタンドアロンのデスクトップアプリケーションです。デベロッパーはこれを使用して、コードのリファクタリング、単体テストの生成、仕様に基づく新しいサービスコンポーネントのスキャフォールディングなど、エージェントをオーケストレートする複雑なタスクを管理できます。エージェントは 1 つのプロンプトからサブエージェントを生成でき、マルチエージェントオーケストレーションによりタスクを並行して実行できます。
Antigravity CLI: このツールを使用すると、Antigravity のすべての機能をコマンドラインで利用できます。Antigravity 2.0 と同じハーネス、同じエージェント、同じ品質のインテリジェンスを備え、ターミナルに合わせたプロダクトエクスペリエンスを提供します。速度とオーバーヘッドの削減に最適化されており、ユーザーに合わせて柔軟に変化します。CLI はデスクトップアプリと緊密に統合されており、認証、コンテキスト、スキル、構成を共有しているため、どちらのインターフェースでも一貫したエクスペリエンスが得られます。独自のランタイムを構築するには、Antigravity SDK を使用します。
エンタープライズセキュリティとコンプライアンス: Google Cloud のお客様は、Gemini Enterprise Agent Platform プロジェクトで Antigravity 2.0 と Antigravity CLI を使用できるようになりました。Cloud OAuth でログインし、Agent Platform プロジェクト ID とリージョンを設定するだけです。その結果、すべてのエージェント推論は安全なクラウド境界内の Agent Platform モデルを介して実行され、Google Cloud の標準的なデータプライバシー保護と利用規約を継承します。これにより、顧客データをお客様自身の管理下に置き、リージョンのモデルエンドポイントを利用できるようになります。

他のコーディングエージェントの統合

Antigravity は Google が推奨するエージェントコーディングソリューションですが、Google Cloud は、お客様が選択したあらゆるコーディングエージェントと連携して機能するように設計されています。Google のプラットフォームはオープンであり、柔軟性を確保するために次のようなツールを用意しています。

Agent CLI と Agent Development Kit（ADK）を使用すると、Claude Code などのツールを含むさまざまなソースからエージェントを構築して操作できます。つまり、デベロッパーは多くの場合、基盤となる AI 推論を Google Cloud で実行しながら、使い慣れたインターフェースを使い続けることができます。このアプローチにより、ワークフローにおいて Google Cloud のセキュリティ、コンプライアンス、インフラストラクチャのメリットを確実に享受できます。
Next でリリースされた Google Skills for Google products は、複数のコーディングツールと互換性を持つように設計されており、一貫した機能セットでさまざまなエージェントを強化できます。

この柔軟性により、チームは使い慣れたツールやモデルを統合し、確立されたワークフロー内でシームレスかつコンプライアンスに準拠した運用を確保できます。

4 段目: Agent Development Kit（ADK 2.0）

コードファースト、低い導入障壁（ローフロア）、高い柔軟性（ハイシーリング）。Managed Agents が構成ファーストであるのに対し、ADK はエンジニアリングファーストです。これは、カスタムエージェントメッシュをゼロから構築したいソフトウェアエンジニア向けのツールです。アーキテクチャやモデルを問わず、制約のない自由な開発が可能です。

ADK の機能強化が Google Cloud Next で発表され、すべてのお客様にご利用いただけるようになりました。ADK には、動的なモデル主導の推論から厳格かつ決定論的なワークフローまでスライダーで調整できる、グラフベースの統合エンジンが導入されています。このフレームワークは、サブエージェント、ツール、データが相互にどのように受け渡されるかを管理し、マルチエージェントの連携という煩雑な作業を処理します。

コラボレーションワークフロー（Python v2.0.0）: 以前はタスクベースのエージェントコラボレーション API と呼ばれていました。これは、自己管理型エージェントチームを構築するための機能です。コーディネーターは、明示的な動作モードを使用してサブエージェントに委任します。

チャット: 完全なユーザーインタラクション、親エージェントへの手動での復帰。これは「サブエージェントへの会話の引き渡し」です。
タスク: ユーザーインタラクションによる明確化、親エージェントへの自動復帰。これは新しい「この課題での共同作業」であり、他の 2 つのオプションの長所を兼ね備えています。
シングルターン: ユーザーインタラクションなし、並列実行、自動復帰、「ツールとしてのエージェント」。

動的ワークフロー: ADK の動的ワークフローでは、グラフベースのパス構造を脇に置き、選択したプログラミング言語の機能を最大限に活用してワークフローを構築できます。動的ワークフローでは、シンプルなデコレータでワークフローを作成し、ワークフローノードを関数として呼び出し、複雑なルーティングロジックを構築できます。
ADK Kotlin（ベータ版）:「ADK for Android」。Kotlin のサポートが加わったことで、Python、Go、Java と合わせて対応言語が増え、オンデバイスのモバイルエージェントとバックエンドの Python エージェントをシームレスに連携させることができます。

最後に、Agents CLI は、ADK、評価、デプロイ、オブザーバビリティ、公開に関する Google のエキスパートスキルをパッケージ化し、あらゆる AI コーディングエージェント（Antigravity、Gemini CLI、Claude Code、Cursor など）をエージェントアプリ構築とエージェントオペレーションのエキスパートに変えます。これにより、AI エージェントに Google Cloud エージェントスタックを理解するスキルが与えられ、広大なエコシステムが、エージェント構築の山登りに挑むデベロッパーにとってシームレスな組み立てラインに変わります。

これからの展開にご期待ください

エージェントの分野は急速に進化しています。Agent Platform は、安全かつ柔軟性に優れた基盤を提供します。Agent Gateway、ID 管理、Skill Registry などのコアコンポーネントが連携して、エージェントのための堅牢で管理された環境を確保し、ベンダーロックインなしで柔軟にイノベーションを実現できます。

プロジェクトに合った段階を選んでも、チームが好むコーディングエージェントを導入しても、どちらの場合も、最終的に行き着くプラットフォームは同じです。データは常に Cloud プロジェクト内に留まります。

この投稿を読んだ後に 1 つだけドキュメントを読むなら、Agent Platform のドキュメントにあるエージェントの概要をおすすめします。興味深いものを作成された際は、ぜひ共有してください。優れた事例は、次回のテンプレートに採用させていただきます。

皆様が構築されるソリューションを楽しみにしております。

- Google Cloud AI、ディレクター、Addy Osmani

- Google Cloud、プロダクトマネージャー、Alan Blount

Gemini CLI DevOps 拡張機能を使用して、わずか数分でコードをリリース

Tue, 19 May 2026 02:30:00 +0000

※この投稿は米国時間 2026 年 5 月 9 日に、Google Cloud blog に投稿されたものの抄訳です。

Antigravity や Claude Code のような AI コーディングツールを使うと、実用的なウェブアプリを記録的な速さで構築できます。しかし、デプロイとなると話は別です。これまでの私なら、Dockerfile、IAM バインディング、YAML の設定に午後の残りの時間をすべて費やしていたでしょう。結局は、多くの開発者と同じ近道、つまり、デプロイしないことを選択したはずです。アプリは私のノートパソコンに残り続け、私の仕事がリリースされることはないでしょう。

これは、インナーループ（コードの記述やテストといった高速なローカルサイクル）とアウターループ（コンテナ化、CI / CD パイプライン、本番環境インフラストラクチャ）の間にある典型的な緊張関係です。ほとんどの開発者はどちらか一方では生産性を発揮しますが、もう一方では発揮できません。このギャップがプロジェクトの停滞につながります。

CI / CD 用の Gemini CLI 拡張機能は、このギャップを埋めます。単一のターミナルインターフェースから、迅速なデプロイと完全なパイプライン生成の両方を処理できます。その方法をご紹介しましょう。

Cosmic Guestbook アプリを構築する

このワークフローを実演するには、アプリが必要です。空のディレクトリから開始して、エージェントを使用し、Cosmic Guestbook というまったく新しいプロジェクトを「バイブコーディング」しましょう。

フルスタックアーキテクチャ（React フロントエンドと Node.js Express バックエンド API）を構築します。これを手動でスキャフォールディングする代わりに、アプリをすぐに作成するようエージェントに依頼します。

code_block: <ListValue: [StructValue([('code', '"Build a \'Cosmic Guestbook\' web app. I need a dynamic Node.js Express backend and a React frontend utilizing Vite. Make the frontend look like a beautiful, glassmorphic sci-fi interface."（「Cosmic Guestbook」というウェブアプリを構築して。動的な Node.js Express バックエンドと、Vite を利用した React フロントエンドが必要。フロントエンドは、美しいグラスモーフィズムの SF 風インターフェースにして。）'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddb598a90>)])]>

エージェントはすぐに、server.js を含む backend/ ディレクトリと、完全にスタイル設定された React アプリを含む frontend/ ディレクトリをスキャフォールディングします。これで、ノートパソコン上で動作する 2 層構造のウェブアプリが完成しました。

拡張機能をインストールする

しかし、ノートパソコン上のコードはリリースされません。このゲストブックをオンラインにするには、選択した環境に CI / CD 拡張機能を導入する必要があります。どのような設定であっても、まず gcloud CLI がインストールされていることを確認し、アプリケーションのデフォルト認証情報を使用して認証します（gcloud auth application-default login）。

次に、使用する開発環境に拡張機能をインストールします。

Gemini CLI の場合

ターミナルで次のコマンドを直接実行します。

code_block: <ListValue: [StructValue([('code', 'gemini extensions install https://github.com/gemini-cli-extensions/cicd'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddb5988b0>)])]>

Claude Code の場合

マーケットプレイスを追加し、ターミナルからプラグインを直接インストールします。

code_block: <ListValue: [StructValue([('code', '# 1. Marketplace を追加する\r\nclaude plugin marketplace add https://github.com/gemini-cli-extensions/cicd.git\r\n\r\n# 2. プラグインをインストールする\r\nclaude plugin install cicd'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddb598640>)])]>

Antigravity、および npx skills でサポートされているエージェントの場合

拡張機能の MCP サーバーをカスタム MCP として有効にし、スキルをワークスペースに追加します。

code_block: <ListValue: [StructValue([('code', '# スキルを追加する\r\nnpx skills add https://github.com/gemini-cli-extensions/cicd --global --all --agent antigravity'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddb598340>)])]>

仕組み

CI / CD 拡張機能は、これらすべてのエージェント環境で、インテントを安全かつプロダクションレディなインフラストラクチャに変換するよう設計された、強力な 3 層構造システムです。

スキル: google-cicd-deploy や google-cicd-pipeline-design などの専門的な AI スキルが拡張機能内で定義されています。これらは、AI エージェント（Gemini CLI、Claude Code、Antigravity）に思考方法を指示し、コードの分析、適切な質問、適切なエラー処理を支援します。
CI / CD MCP サーバー: バックグラウンドでは、Go ベースの専用 Model Context Protocol（MCP）サーバーが実行されています。このサーバーは、シークレットのスキャンから Cloud Run サービスのプロビジョニングまで、エージェントが Google Cloud を実際に操作するために必要な一連のツールを提供します。
ローカルナレッジベース: 最も正確な回答ができるよう、システムには、検証済みのアーキテクチャパターンを格納した、事前インデックス化済みの検索拡張生成（RAG）データベースが含まれています。これにより、エージェントは信頼できる情報源に基づいて設計上の判断を下すことができます。

選択した AI アシスタントが、これらのツールとパターンをオーケストレートし、一貫性のあるデプロイライフサイクルを実現します。

インナーループ

プロトタイプを構築したり、新機能をテストしたりする場合、大規模なマルチ環境 CI / CD パイプラインは必要ありません。必要なのは、Webhook をテストしたり、関係者にデモを見せたりするための公開 URL だけです。これがインナーループです。インナーループは高速である必要があります。

従来のアプローチでは、Dockerfile を手動で記述し、コンテナレジストリを使って認証を行い、イメージをビルドして push し、最後にデプロイします。CI / CD 拡張機能を使用すると、これが単一の自然言語プロンプト（gemini "Deploy this application to Google Cloud using the google-cicd-deploy skill"（google-cicd-deploy スキルを使用して、このアプリケーションを Google Cloud にデプロイして））に変わります。Claude Code を使用している場合は、claude -p "Deploy this application..." を使用してまったく同じようにプロンプトを入力できます。Antigravity では、デプロイリクエストを入力するだけです。

このプロンプトを実行すると、AI エージェントがローカルのワークスペースを分析して、最適なデプロイ方法を判断します。

ステップ 1: デプロイ前のセキュリティスキャン

シークレットの漏洩は、ソフトウェアにおいて最も一般的でコストのかかるセキュリティ障害の一つです。GitGuardian の The State of Secrets Sprawl 2025 レポートによると、1 年間で 2,380 万件の新しい認証情報が公開 GitHub 上にさらされ、2022 年に漏洩したシークレットの 70% が現在もなお有効であることが判明しています。ローカルテスト中にハードコードしたデータベースパスワードを削除し忘れたまま push してしまうなど、このような事態はあっという間に生じます。

この拡張機能は、問題になる前にこれを検出します。コードがマシンから送信される前に、ワークスペース全体に対してシークレットチェックが実行されます。ソース内に Stripe API キーやデータベース認証情報が見つかった場合、エージェントはデプロイを停止して警告を表示します。シークレットが誤ってクラウドに送信されることはありません。

ローカルホストで開発中にデータベースパスワードや Stripe API キーを誤って commit してしまっても、アシスタントがそれを検知してデプロイを阻止します。これこそが、実際の真のシフトレフトセキュリティです。

ステップ 2: アプリケーションの分析とコンテナ化

次に、エージェントは package.json または go.mod をチェックして、使用しているフレームワークを判別し、Google Cloud Storage（静的サイトの場合）と Cloud Run（動的サービスの場合）のどちらを使用するかを自動的に決定します。

Dockerfile がない動的サービスを構築する場合、拡張機能は Google Cloud の Buildpack を利用して、その場でコンテナ化します。

ステップ 3: 明確化とデプロイ

会話エージェントは、求められているアプリの構成をやみくもに推測するわけではありません。Google Cloud 環境に変更を加える前に、アシスタントはフローを一時停止し、分析中に判明した内容に基づいて優先順位付けの質問をします。

Cosmic Guestbook では、サービスを公開するかどうかやリージョンを指定しませんでした。アシスタントは一時停止し、その点について尋ねてきました。

「分析を完了し、Cloud Run への統合デプロイに向けてアプリケーションの準備を整えました。Node.js Buildpack では単一のエントリポイントが必要であるため、React フロントエンドを構築し、Express バックエンドがそれを静的に提供できるようにするカスタムビルドスクリプトを含むルート package.json を作成しました。

また、シークレットスキャンも正常に完了しました。機密性の高い認証情報は検出されませんでした。

Cloud Run のソースデプロイオプション（Buildpack）を使用してデプロイする前に、デプロイパラメータをいくつか明確にする必要があります。

リージョン / ロケーション: gcloud のデフォルト設定ではロケーションが指定されません。どの Google Cloud リージョン（例: us-central1、europe-west1）にデプロイしますか？
アクセス: このアプリケーションは一般公開しますか、それとも非公開にしますか？
サービス名: cosmic-guestbook というサービス名にすることを提案します。いかがでしょうか？」

このように会話が一時停止することで、高速なインナーループであっても、クラウドアーキテクチャを完全に制御し続けることができます。詳細を確認した後、エージェントはコードをライブ環境に push し、公開 URL を返します。

code_block: <ListValue: [StructValue([('code', '# 最終的な出力:\r\nYour application is now live and publicly accessible at the following URL:\r\nhttps://cosmic-guestbook-xxxxxxxx-uc.a.run.app'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddb598e20>)])]>

バックグラウンドでは、デプロイは cloudrun.deploy_to_cloud_run_from_source を使用して自動的に処理されます。

アウターループ

火曜日の午後にプロトタイプを作成するなら、おおざっぱなデプロイプロンプトで十分ですが、ノートパソコンから本番環境システムを運用することはできません。最終的には、自動テスト、ソース管理の統合、正式な継続的デプロイといったアウターループの厳格さが必要となります。

cloudbuild.yaml ファイルの作成や、必要なインフラストラクチャ（Artifact Registry リポジトリや Developer Connect を介した GitHub 接続など）のプロビジョニングは、非常に面倒でエラーが発生しやすい作業として知られています。google-cicd-pipeline-design スキルを使用すると、AI エージェントがパーソナルプラットフォームエンジニアリングコンサルタントとして機能します。

YAML をゼロから記述する代わりに、会話をします。エージェントは、テスト戦略とデプロイ先について質問し、必要な Google Cloud インフラストラクチャを自律的にプロビジョニングします。

ステップ 1: アーキテクチャの設計とフィードバック

このプロセスは、会話型インターフェースで直接開始します。

code_block: <ListValue: [StructValue([('code', '# エージェントにプロンプトを入力し、設計プロセスを開始する\r\ngemini "Design a CI/CD pipeline using the google-cicd-pipeline-design skill"\r\n# または\r\nclaude -p "Design a CI/CD pipeline using the google-cicd-pipeline-design skill"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddb598550>)])]>

アシスタントはブラックボックスの中で動作しているわけではありません。ナレッジベースから一般的な CI / CD パターンを取得し、最も関連性の高いナレッジに基づいて、確認用の具体的なプランを YAML で提案します。

ステップ 2: インフラストラクチャのプロビジョニング

プランを承認すると、アシスタントは必要なインフラストラクチャの手順を順番に実行します。たとえば、まずコンテナのレジストリを作成します。

code_block: <ListValue: [StructValue([('code', '// レジストリをプロビジョニングする MCP 呼び出しの例\r\n{\r\n "name": "create_artifact_repository",\r\n "arguments": {\r\n "repository_id": "demo-app-repo",\r\n "location": "us-central1",\r\n "format": "DOCKER"\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddb598520>)])]>

その後、Cloud Build がソースコードを読み取れるよう、Git 接続を設定する場合もあります。

ステップ 3: パイプラインの生成とトリガー

最後に、エージェントはパイプラインステージ（テスト、構築、デプロイ）を定義する実際の cloudbuild.yaml ファイルを生成します。以下は、リポジトリから生成された構成のスニペットです。初期ビルドステップが強調表示されています。

code_block: <ListValue: [StructValue([('code', 'steps:\r\n # ステップ 1: ツール（linter など）をインストールし、キャッシュをクリアする\r\n - name: \'golang:1.24\'\r\n id: \'Install Tools\'\r\n entrypoint: \'sh\'\r\n args:\r\n - \'-c\'\r\n - |\r\n set -e\r\n export PATH=/workspace/bin:$$PATH\r\n echo "Installing golangci-lint..."\r\n go install github.com/golangci/golangci-lint/cmd/golangci-lint@v1.64.8\r\n echo "Cleaning module cache..."\r\n go clean -modcache\r\n env:\r\n - \'GOPATH=/workspace\'\r\n dir: \'devops-mcp-server\''), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddb598d00>)])]>

パイプラインを定義したら、それを自動的に実行する方法が必要です。エージェントは、Cloud Build トリガーを作成して処理を終えます。このトリガーは GitHub リポジトリと Cloud Build を結び付ける役割を果たし、main ブランチへの push が行われるたびに cloudbuild.yaml のステップが自動的に実行されるようにします。

code_block: <ListValue: [StructValue([('code', '// トリガーを設定する MCP 呼び出しの例\r\n{\r\n "name": "create_build_trigger",\r\n "arguments": {\r\n "trigger_name": "main-branch-deploy",\r\n "filename": "cloudbuild.yaml",\r\n "branch_pattern": "^main$"\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ddb5983d0>)])]>

セキュリティと管理

AI を活用したインフラストラクチャ生成は素晴らしいことに思えますが、安全かどうか疑問に思うのはしごく当然です。

この拡張機能は、ローカルアプリケーションのデフォルト認証情報（ADC）の権限の範囲内で厳密に動作します。ユーザーができないことは、エージェントもできません。Model Context Protocol（MCP）を使用しているため、Artifact Registry の作成から Cloud Build トリガーの変更まで、エージェントが行うすべてのアクションは、厳密に型指定された検証可能なツールを介して実行されます。

提案されたパイプラインのステップが気に入らない場合は、エージェントに変更を指示します。インフラストラクチャの「編集長」は常にあなたです。ローカルの ADC と、生成されたパイプラインで使用するサービスアカウントの両方で、最小権限の原則を遵守することを強くおすすめします。

開発と運用の融合

コードを書きたいという思いとコードをリリースしなければならないという現実の間の葛藤が、ついに解消されつつあります。アプリをインターネット上に公開するには、YAML 形式に関する深い専門知識が不可欠だった時代は過ぎ去りました。

会話型 AI は、おおざっぱなインナーループと自動化されたアウターループの両方のボイラープレートを処理することで、開発者が本当に重要なビジネスロジックに集中できるようにします。

次のステップ

この融合を実際に体験してみたい方は、以下の手順に沿って進めてください。

ツールを入手する: Gemini CLI 用の CI / CD 拡張機能をインストールします。
インナーループをデプロイする: 既存のサイドプロジェクトを使用（または、選択したエージェントに Cosmic Guestbook のような新しいプロジェクトのスキャフォールディングを依頼）し、Google Cloud にデプロイするようプロンプトを入力すると、Cloud Run または Cloud Storage で即座に動作を確認できます。
アウターループを自動化する: 本番環境に移行する準備ができているリポジトリに対して設計コマンドを実行し、エージェントが cloudbuild.yaml を生成してインフラストラクチャをプロビジョニングする様子を確認します。

構成ファイルとの格闘はやめて、リリースを始めましょう。皆様が何を構築したのか、LinkedIn、X、Bluesky でぜひ教えてください。

- デベロッパーリレーションズ担当ディレクター、Karl Weinmeister

デベロッパー

BGP ルートポリシー: お客様の需要に基づく上位 3 つのユースケース

1. 基盤: ルートフィルタリングとネットワーク保護

2. アクティブ/スタンバイ アーキテクチャのトラフィック パスの制御

3. BGP コミュニティで非対称ルーティングを解決する

使ってみる

Gemini Enterprise Agent Platform のフルマネージド リモート MCP サーバーでエージェントをさらに迅速に構築

IDE を Google Cloud に接続する

価値創出までの時間の短縮

仕組み: 3 つの簡単なステップで接続

使ってみる

Cloud Run サンドボックスで AI 生成コードを安全に実行

Cloud Run サンドボックスとは

主なユースケース

仕組み: デベロッパー エクスペリエンス

ステップ 1: サンドボックス ランチャーを有効にする

ステップ 2: コード内でサンドボックスをネイティブに生成する

安全性を重視した設計: デフォルトでゼロトラスト

ADK と ComputeSDK の組み込みサポート

使ってみる

Gemini Enterprise と Google Cloud Marketplace でエージェントを公開するためのデベロッパー ガイド

ステップ 1: Marketplace との統合を想定して、エージェント アーキテクチャを設計する

ステップ 2: Marketplace で販売するための組織の要件を確認する

ステップ 3: Marketplace および Gemini Enterprise app との互換性のための技術要件を確認する

A2A プロトコル

A2A エージェント カード

認証と認可

ステップ 4: Marketplace でエージェントを掲載、公開する

ステップ 5: Marketplace と Gemini Enterprise app におけるトランザクション / 登録の管理

実際にやってみる

Google Cloud 向け Claude アプリ ゲートウェイを使ってみる

ゲートウェイを実行すべき理由

連携の仕組み

Google Cloud での設定

次のステップ

Google AI Studio のスターター ティアの解説

スターター ティアの概要

提供内容: 事前構成済みのスタック

Cloud Run

Firebase Authentication

Cloud Firestore

Cloud SQL for PostgreSQL デベロッパー エディション

プロンプトの入力から一般公開 URL の取得までの 5 つのステップ

スターター ティアとの比較

制限に備える

サンドボックスからの移行

Cloud Network Insights: クロスクラウド ネットワークに対するエンドツーエンドのオブザーバビリティ

アクティブなモニタリングで可視性のギャップを解消

仕組み: アクティブな合成プロービング

核となる機能

お客様の声

使ってみる

お客様とのコラボレーションが切り拓く、Model Armor による生成 AI セキュリティの未来

「徹底した当事者意識」による生成 AI 導入の加速

現場で得られた重要な知見

知見を実践的に活用

パートナーシップの力

30 分でリモート MCP サーバーの構築と GKE へのデプロイを実行

30 分でリモート MCP サーバーを構築して GKE にデプロイする

MCP トランスポート

GKE で MCP サーバーを実行するメリット

前提条件

インストール

数学 MCP サーバー

MCP サーバーをローカルでテストする

コンテナ イメージのビルド

Artifact Registry を設定する

イメージのビルドと push を並列で実行する

Gateway API と SSL を使用して GKE にデプロイする

Cleanup

Antigravity 2.0 を使用して 1 日で Go を習得するための実践的な方法

ステップ 0: 個人的な学習目標の「種まき」をする

ステップ 1: スキルの重要性

ステップ 2: ギャップ分析と計画

ステップ 3: 品質保証（QA）ループの実施

ステップ 4: CLI コマンド向けの並列サブエージェント

ステップ 5: パッケージ構造、コンパイル、CI / CD

ステップ 6: エージェント スキルを作成する

まとめ

次世代のグローバル イノベーションの拡大: 成功を収めている世界中のスタートアップを Google がどのようにサポートしているか

2. アクティブ/スタンバイアーキテクチャのトラフィックパスの制御

Gemini Enterprise Agent Platform のフルマネージドリモート MCP サーバーでエージェントをさらに迅速に構築

仕組み: デベロッパーエクスペリエンス

ステップ 1: サンドボックスランチャーを有効にする

Gemini Enterprise と Google Cloud Marketplace でエージェントを公開するためのデベロッパーガイド

ステップ 1: Marketplace との統合を想定して、エージェントアーキテクチャを設計する

A2A エージェントカード

Google Cloud 向け Claude アプリゲートウェイを使ってみる

Google AI Studio のスターターティアの解説

スターターティアの概要

Cloud SQL for PostgreSQL デベロッパーエディション

スターターティアとの比較

Cloud Network Insights: クロスクラウドネットワークに対するエンドツーエンドのオブザーバビリティ

コンテナイメージのビルド

ステップ 6: エージェントスキルを作成する

次世代のグローバルイノベーションの拡大: 成功を収めている世界中のスタートアップを Google がどのようにサポートしているか

戦略的展開: 地政学、グリーンインフラストラクチャ、ロボット工学

ウィジェットテスト

Cloud Run での AI のコールドスタートに関するガイド

AI のコールドスタートの仕組み

AI のコールドスタートを処理するためのベストプラクティス

ドローンコパイロット: Gemini Live API を使用した音声制御ドローンと自律検査

Ekaette - マルチモーダル AI 音声およびメッセージングアシスタント

vibeCat - プロアクティブなデスクトップコンパニオン

他のコーディングエージェントの統合