デベロッパー

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 0x7f7761b66bb0>)])]>

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

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

次に、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 0x7f7761b66df0>)])]>

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 0x7f7761b663a0>)])]>

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

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

次に、必要な追加ファイルとして、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 0x7f7761b669d0>)])]>

次のコードを 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 0x7f7761b66760>)])]>

この例では、リモートサーバーの推奨プロトコルである 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 0x7f7761b66c10>)])]>

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

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

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

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

出力には利用可能なツールおよび 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 0x7f7761b66940>)])]>

次に、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 0x7f7761b669a0>)])]>

イメージのビルドと 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 0x7f7761b662b0>)])]>

イメージのビルドが完了したら、クラスタが準備できていることを確認し、認証情報を取得します。クラスタの出力が「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 0x7f7761b66790>)])]>

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 0x7f7761b66220>)])]>

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

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

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

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

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

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

テストスクリプトを実行して接続を確認します。テストスクリプトの 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 0x7f7761b66ca0>)])]>

次に、接続を保護します。これを行うには、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 0x7f7761b668b0>)])]>

ドメインの 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 0x7f7761b66d30>)])]>

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 0x7f7761b66a60>)])]>

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

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

ロードバランサがアクティブになり、証明書がプロビジョニングされるまで数分待ちます。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 0x7f7761b66af0>)])]>

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 0x7f7761b66fd0>)])]>

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 0x7f77784bdf10>)])]>

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

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 0x7f77784bd820>)])]>

エージェントはウェブを調査し、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 0x7f77784bd070>)])]>

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

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

スキル検索のプロンプト

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

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

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

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

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

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

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

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

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

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

実装

私が計画を承認すると、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 0x7f77784bd4f0>)])]>

このマッピングは効果的に動作します。たとえば、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 0x7f77784bd790>)])]>

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

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

バージョン 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 0x7f77784bd9a0>)])]>

これにより、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 0x7f77784bddc0>)])]>

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 0x7f77784bd160>)])]>

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 0x7f77784bd5b0>)])]>

注: 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 0x7f77784bd3d0>)])]>

結果的に、これは正しい判断でした。サブエージェントはコマンドの詳細な監査を実施し、いくつかのオプションのギャップと欠落しているテストを特定しました。その後、これらはこちらの監査 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 0x7f77784bd7f0>)])]>

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

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

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

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

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 0x7f77784bdc70>)])]>

予想外の注意点

矛盾しているようですが、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 0x7f77784bdca0>)])]>

プロンプトのドラフトが提示され、それを繰り返し改良しました。何度かやり取りした後、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 0x7f7762e7b940>)])]>

万能なアプローチはありませんが、まずはいくつかのガードレールに基づくスキルを作成するようエージェントに依頼するとよいでしょう。実際には、エージェントの回答が目標に沿っていると感じるまで、複数のプロンプトを順番に推敲することになるでしょう。その後、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 0x7f7778536340>)])]>

理由: 私は質の低いプロダクト要件定義書（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 0x7f7778536a00>)])]>

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

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

Aja Hammerly

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

X、LinkedIn でフォロー

プロンプト:

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

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

理由: コードを書いていると、ユーザーに通ってほしい主要な経路である「ハッピーパス」に意識が偏ってしまうことがよくあります。その作業に集中している間は、まだ深く考えたくないエッジケースについて 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 0x7f7778536ca0>)])]>

理由: 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 0x7f7778536550>)])]>

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

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

James O'Reilly

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

X、LinkedIn でフォロー

プロンプト:

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

理由: 私は、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 0x7f7778536b50>)])]>

理由: 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 0x7f7778536d00>)])]>

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

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

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

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

理由: 最後に送るプロンプトが 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 0x7f77785366a0>)])]>

プロンプト全文: リンク

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

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

Karl Weinmeister

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

X、LinkedIn でフォロー

プロンプト:

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

理由:

ほとんどのアプリケーションワークフローは線形ではありません。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 0x7f7763661fd0>)])]>

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 0x7f7763794400>)])]>

両リージョンの 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 0x7f7763794a30>)])]>

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

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

次のステップ

上述の機能に関するハンズオン 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 0x7f77784fab20>)])]>

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 0x7f77784faf70>)])]>

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 0x7f7761a89fd0>)])]>

エージェントはすぐに、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 0x7f7761a89340>)])]>

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 0x7f7761a89280>)])]>

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 0x7f7761a896a0>)])]>

仕組み

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 0x7f7761a89760>)])]>

バックグラウンドでは、デプロイは 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 0x7f7761a89b80>)])]>

アシスタントはブラックボックスの中で動作しているわけではありません。ナレッジベースから一般的な 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 0x7f7761a89ee0>)])]>

その後、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 0x7f7761a89c70>)])]>

パイプラインを定義したら、それを自動的に実行する方法が必要です。エージェントは、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 0x7f7761a89eb0>)])]>

セキュリティと管理

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

AI を活用したコード移行の先駆け: Google が TensorFlow から JAX への移行を 6 倍高速化した方法

Thu, 14 May 2026 02:10:00 +0000

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

AI コーディングエージェントは、ソフトウェア業界全体で急速に普及しつつあり、デベロッパーが日常的にコードを記述、テスト、デバッグする方法を根本的に変えています。このツールは、ローカルで完結するタスクに優れた機能性を発揮しますが、大規模で体系的なコードベースの移行に適用するには、まったく新しいアプローチを必要とします。

Google には、多くの移行ワークフローに AI を組み込み、このような課題に対処してきた実績があります。たとえば、x86 から ARM への移行では Google Axion プロセッサでワークロードを有効にし、int32（32 ビット整数）識別子から int64（64 ビット整数）識別子への移行によって ID の枯渇を防ぎ、JUnit3 から JUnit4 への移行でテストを簡素化し、Joda-Time から java.time への移行で最新の時刻ライブラリを使用可能にしました。しかし、AI モデルの移行には新次元の複雑さがともない、AI による移行支援のためのさらに高度な手法が必要となります。

本番環境グレードの ML モデルを 1 つのフレームワークから別のフレームワークに変換する（たとえば、TensorFlow（TF）から JAX に変換する）ことは、単純な構文の更新ではありません。数千行のコードを解きほぐし、複数ファイルにまたがる複雑な状態管理を実現し、正確な数学的等価性を維持しなければならない、長期的な展望を必要とするタスクです。これは、汎用の単一エージェントによるコーディングアシスタントには過大な重圧となります。長いワークフローでは頻繁にコンテキストが失われ、API を巻き込んだハルシネーションが起きたり、リポジトリ全体でビルド可能なコード生成が行われなくなったりします。

この業界全体の問題に対し、Google AI / インフラストラクチャチームは、世界に先駆けて新しいアプローチを開発しました。このアプローチは、モデルの移行を 6 倍速くするという、先日の Google Cloud Next の基調講演で Sundar が強調したマイルストーンを達成するものとなりました。この投稿では、Google がどのように専用マルチエージェント AI システムをデプロイして、Google 最大規模の本番環境モデルを TF から JAX に移行したのかについて、ご紹介します。

TF から JAX への移行を加速

Google の多くのチームでは（業界全体にも言えることですが）、未来に向けたスケーラブルな ML は JAX を基盤として構築されています。関数型でステートレスなパラダイムを中心に設計された JAX は、最新の Tensor Processing Unit（TPU）インフラストラクチャと XLA コンパイル向けに最適化されており、最新 AI スタックの強固な基盤となるものです。

これは未来への進歩であると同時に、非常に大きな課題も提示しています。TensorFlow は、オブジェクト指向でステートフルレイヤの初期化と静的実行グラフを特徴とするフレームワークであり、現在、何千もの本番環境モデルが、この TF を基盤に構築されています。これらのモデルを JAX に手動で移行するには、レイヤの相互作用や状態管理の明示的な方法を根本的に見直す必要があります。このような移行は、それだけで大規模な組織全体における数百（場合によっては数千）のソフトウェアエンジニアリング（SWE）年数を必要とします。組織にとっては、この時間を新しいアーキテクチャの調査やプロダクトイノベーションの推進に費やす方がはるかに有益です。

この課題を AI で克服する取り組みは、Google AI / インフラストラクチャチームの野心的な実験として始まりましたが、今では社内全体の複雑なエンジニアリングの問題に対処可能な再現性のあるブループリントにまで進化しています。

単一エージェントコーディングからの脱却

エージェントによるコード変換は、初期の実験では単純なモデルへの有効性が確認されました。しかし、現実的な Google 規模の移行に直面したとき、つまり、複数のファイルにまたがる数千行のコードの複雑な本番環境グレードのモデルを扱うとき、汎用的な単一エージェントでは困難を極めました。高次元の構造ルールと現実のこまごまとした実行上の問題の折り合いがつかず、重要なファイルを上書きしたり、必要な機能をとばしたりと、さまざまな障害が発生しました。このような大規模な移行によくある課題を克服するために、Google は以下で構成される高度に専門化されたマルチエージェントアーキテクチャを開発しました。

Planner エージェント: 決定論的なコンパイラベースの静的分析を使用して、コードベースの依存関係全体をツリー構造にマッピングします。その後、他のエージェントと連携して移行を個別の段階的プランに分割し、「リーフノード」（依存関係のない未移行レイヤ）から上に向かって論理的に移行が行われるようにします。
Orchestrator エージェント: このエージェントはプロジェクトマネージャーとして機能します。プランステップを管理しやすいチャンクに動的にグループ化してコンテキストウィンドウの対象を絞り、必要なドメイン知識を注入します。ステップがビルドされない場合は障害復旧を適用します。
Coder エージェント: 推論と行動の役割を担う主力エージェントです。社内の IDE ツールに直接統合され、ファイルの読み取り、コードの記述、ビルドの実行、単体テストの実施が可能です。「テストと修正」のループで動作し、コンパイル可能で検証可能なコンポーネントをターゲット言語で生成するまで自己修正を繰り返せる点が最大の特長です。

図: 複雑なコードを移行するためのマルチエージェント AI システム。レガシーモデルコードを JAX に移行するマルチエージェントシステムの仕組みを表したプロセス図で、Gemini Nano Banana 2 で生成。

スケーラブルな検証と柔軟な Playbook

生成 AI モデルの性能は、提供されるコンテキストの質に左右されます。移行元と移行先のアーキテクチャが 1 対 1 でマッピングされることはほとんどないため、Google はスケーラブルで階層的な一連の Playbook を策定しました。

これらの Playbook は、一般的なリポジトリの手順から、手動移行の成功事例から抽出された非常に具体的な「模範例」まで多岐にわたります。クライアント固有の Playbook（たとえば、YouTube 独自のランキングモデルインフラストラクチャ向けに調整されたもの）を Orchestrator にフィードすることで、一般的なハルシネーションが回避され、組織内のコーディング基準が厳守されます。この Playbook の構成は特定のフレームワークに依存しないため、任意の 2 つのプログラミング言語やフレームワーク間の移行をガイドするように調整することができます。

さらに、生成されたコードが実際にプロダクションレディであることを確認するために、以下の厳格な品質指標も設定されています。

定量的検証: コードの正確性をユニットごとに数学的に検証します。TF から JAX への移行の場合、勾配上昇法のアルゴリズムを使用して元の TF レイヤと新しい JAX レイヤの間の最大誤差を検出し、関数的な同等性を数学的に検証します。
定性的評価: 移行されたコードを、一連の定性的基準に照らして評価します。TF から JAX への移行の場合、盲検監査の LLM Judge をデプロイして、移行後のコードをフレームワークに依存しないアーキテクチャチェックリストに照らして採点します。これにより、ドメイン固有の重要なロジックを確実に把握することができます。

移行のスピードを革新

このマルチエージェントシステムをデプロイすることで、ソフトウェア移行の経済的効率性は劇的に向上します。

実際の複雑な YouTube モデル（数千行のコード、数百のレイヤ、複雑なメトリック依存関係を含む）で評価したところ、マルチエージェントシステムは手動での移行よりも 6.4 倍から 8 倍の高速化を実現しました。従来は数か月分のソフトウェアエンジニアリング（SWE）作業が必要だったものが、わずか数週間の AI によるコード生成と、その後の専門家（人間）によるレビューで完了できるようになったのです。

ボイラープレートの効果的な処理、ターゲット言語のイディオム特定、依存関係のマッピング、単体テストの生成が自動的に行われ、エンジニアは手動のコード変換担当者ではなく、レビュアーやアーキテクトとしての役割を担えるようになります。

AI を活用する時代の展望

AI は技術革新のペースを変革しています。大規模な移行を推進する力は AI で加速する必要があります。組織はそれなしでは、手動の作業に追われ、最新のブレークスルーを取り入れたり、システムのセキュリティ、信頼性、パフォーマンスを維持したりすることが難しく、そのギャップはますます広がっていきます。

ML 実装を 1 つの ML フレームワークから別の ML フレームワークに移行する Google の取り組みは、決定論的静的分析、厳格なテストループ、特殊なマルチエージェントアーキテクチャを組み合わせることで、業界でも特に複雑なソフトウェアエンジニアリングの課題を安全に自動化できることを示しています。プロセスの詳細については、こちらの技術論文をご覧ください。

^{この取り組みは、Google 全体でのコラボレーションの成果です。主な貢献者である Stoyan Nikolov、Niyati Parameswaran、Bernhard Konrad、Moritz Gronbach、Niket Kumar、Ann Yan、Varun Singh、Yaning Liang、Antoine Baudoux、Xevi Miró Bruix、Daniele Codecasa、Madhura Dudhgaonkar、Elian Dumitru、Alex Ivanov、Christopher Milne-O’Grady、Ahmed Omran、Ivan Petrychenko、Assaf Raman、Stefan Schnabl、Yurun Shen、Maxim Tabachnyk、Niranjan Tulpule、Amin Vahdat、Jeff Zhou に感謝いたします。}

- ドメイン応用 ML / AI / インフラストラクチャプロダクト責任者、Jamie Rogers

- Google Fellow 兼 AI およびインフラストラクチャ担当バイスプレジデント、Parthasarathy Ranganathan

Next ’26: Google Cloud と Wiz が AI 時代のセキュリティを再定義

Mon, 11 May 2026 02:00:00 +0000

aside_block: <ListValue: [StructValue([('title', 'Next ’26 で本日発表した最新情報'), ('body', <wagtail.rich_text.RichText object at 0x7f7762743790>), ('btn_text', ''), ('href', ''), ('image', None)])]>

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

AI の時代には、セキュリティも新たな時代へと進む必要があります。組織は、AI の可能性を活用すると同時に、その悪用に対抗するという二重の課題に直面しています。Google Cloud は、こうした変化への適応と成長を支援します。

Google Cloud の最新調査によると、攻撃者は AI を利用して、攻撃の速度、規模、巧妙さを高めています。一方、M-Trends 2026 によると、脅威アクター間の連携強化により、初期アクセスからセカンダリ脅威アクターへの引き継ぎに要する時間は、過去 3 年間で 8 時間から 22 秒へと短縮されたことが示されています。

本日開催の Google Cloud Next では、ますます巧妙化する脅威への防御をマシンスピードで実現し、AI とマルチクラウド環境を保護しながら、大規模なクラウドワークロードを安全に運用するための Google Cloud の取り組みをご紹介します。

エージェント型防御の提供

チップからモデルまでをカバーする Google のフルスタック AI アプローチにより、優れた統合性とスピードを実現し、顧客保護を強化するための競争優位性をもたらします。さらに、グローバル規模の脅威モニタリングと Mandiant の最前線の専門家による分析情報に加え、Google DeepMind の最先端のインサイトや技術的ブレークスルーを活用し、お客様のプラットフォームのセキュリティ強化を支援します。

本日 Google は、Google Security Operations に、AI のスピードでの防御を支援する 3 つの新しいエージェントを発表しました。

現在プレビュー提供中の Threat Hunting エージェントは、従来の防御を回避する新たな攻撃パターンや、ステルス性の高い攻撃者の挙動を、チームが先回りして検出できるようにします。
現在プレビュー提供中の Detection Engineering エージェントは、カバレッジギャップを特定し、脅威シナリオに応じた新たな検出機能を生成します。手間のかかる作業を削減し、検出機能の作成を手作業中心の運用から自動化されたプロセスへと刷新します。
近日プレビュー提供予定の Third-Party Context エージェントは、サードパーティコンテンツから得られるコンテキストデータを活用し、ワークフローを強化します。

Threat Hunting エージェントで脅威ハンティングを開始

Triage and Investigation エージェントは、過去 1 年間で 500 万件以上のアラートを処理し、通常 30 分かかる手動分析を、Gemini の活用により 60 秒へ短縮しました。

「運用レジリエンスとサイバーセキュリティは、BBVA におけるお客様からの信頼を支える基盤です。Triage and Investigation エージェントのような高度な AI を導入することで、新たな形で運用を拡張できるようになります」と、BBVA のセキュリティテクノロジー責任者である Diego Martinez Blanco 氏は述べています。

また同氏は、「初期対応に伴う負荷の高い作業を担い、誤検知を取り除くことで、人による判断が必要な問題に優先的に対応できます。さらに、エージェントが判断根拠を明確に示すことで、チームは推奨事項を理解し、より複雑な調査にリソースを集中できるようになります」とも述べています。

Google Security Operations 向けリモート Google Cloud Model Context Protocol (MCP) サーバー対応が一般提供となり、独自のセキュリティエージェントを構築できるようになりました。さらに利便性を高めるため、プレビュー提供中の Google Security Operations のチャットインターフェースから、MCP サーバークライアントへ直接アクセスすることも可能です。

Google Cloud のエージェント型防御を活用し、インテリジェンス主導かつ AI による拡張を取り入れた最新のセキュリティ運用を進める組織は、高い ROI を実現できます。 Christopher Kissel 氏、IDC リサーチ担当バイスプレジデント

Threat Hunting エージェントが作成した検出結果レポート

セキュリティチームは、Google Security Operations のエージェント型自動化を活用することで、対応業務を自動化できます。さらに、チームの手動トリアージからエージェント型防御への移行を進めるため、Google Threat Intelligence にダークウェブインテリジェンスを導入しました。こちらは現在プレビュー提供中です。内部テストによると、この機能は 1 日あたり数百万件の外部イベントを 98% の精度で分析し、真に重要な脅威を優先的に特定できます。

「IDC は、AI を活用したコンテキストと自動化により、組織が平均検出時間と平均対応時間の大幅な短縮、誤検知の減少、アナリストの生産性向上など、定量的に把握できる運用成果を得ていることを明らかにしています。こうした運用上の改善は、業務中断期間の短縮、インシデント関連コストの削減、セキュリティポスチャーや意思決定に対する経営層の信頼感向上など、重要なビジネス成果につながります」と、IDC のリサーチ担当バイスプレジデントである Christopher Kissel 氏は述べています。「Google Cloud のエージェント型防御を活用し、インテリジェンス主導かつ AI による拡張を取り入れた最新のセキュリティ運用を進める組織は、高い ROI を実現できます。」

Google Security Operations の新しいパートナー連携ワークフロー

本日さらに、Google Security Operations 向けの充実した新しいパートナーインテグレーションも発表します。導入後すぐに利用できる高精度なセキュリティワークフローを提供する、Google Cloud Security 統合エコシステムの最新パートナーには、Darktrace、Gigamon、SAP などが含まれます。

あらゆるインフラストラクチャで、AI とクラウドアプリケーションを保護

AI とクラウドアプリケーションは、複数のプラットフォームやモデルにまたがって構築されています。これらをエンドツーエンドで保護するため、構築環境や方法にかかわらず、リスクをより簡単かつ迅速に軽減できるようにします。こうした保護機能は、アマゾンウェブサービス（AWS）、Google Cloud、Microsoft Azure、Oracle Cloud などの主要なクラウド環境に加え、OpenAI などの SaaS（Software as a Service）環境、さらにセルフホスト型の環境にも対応しています。

さらに、Wiz が Google Cloud の一員となったことで、お客様が構築し運用するアプリを保護する機能が拡大し、一段と強化されました。Wiz は、AI を迅速かつ安全な導入を可能にするとともに、AI 開発ライフサイクルの保護も強化します。

Wiz は、RSA Conference で AI-Application Protection Platform（AI-APP）を発表しました。AI アプリケーション向けに、高度な可視化、リスクポスチャーの把握、ランタイム分析が可能になります。また、Wiz Security Agents と Wiz Workflows も発表し、リスクや脅威をマシンスピードで特定し、迅速に対応できるようになりました。

Google は、あらゆるクラウド、プラットフォーム、AI 環境でお客様を保護する体制を一段と強化します。その一環として、Wiz は、Databricks に加えて、AWS Agentcore、Gemini Enterprise Agent Platform、Microsoft Azure Copilot Studio、Salesforce Agentforce などの新しいエージェントスタジオにも対応します。チームがどのプラットフォームを選んで構築しても、お客様は全体の可視性の確保が可能です。

Wiz は Google Cloud Apigee、Cloudflare AI Security for Apps、Vercel プラットフォームなど、クラウドの外側レイヤーとのインテグレーションによってセキュリティエコシステムとの連携を継続し、Wiz Security Graph の適用範囲をさらに拡張しています。また、Google は、Wiz Defend のセキュリティ検出機能と Google Security Operations および Mandiant Threat Defense との連携方法のアップデートにより、アナリストが脅威情報の自動転送をより容易に設定できるようになりました。

さらに、Wiz は、AI ネイティブな開発ライフサイクルを保護し、チームがより迅速かつ安全にイノベーションを進められる新機能も発表しました。

バイブコーディングアプリケーションを保護: Wiz は、5 月に一般提供予定の新しいインテグレーションを発表しました。これにより、Wiz のセキュリティスキャンを Lovable プラットフォーム内で直接実行できるようになります。Wiz が検出した脆弱性、シークレット、設定ミスは、Lovable の組み込みセキュリティビュー上に表示され、チームがすでに開発を進めている環境でそのまま確認することができます。
AI 生成コードの保護: Wiz は、AI 生成コードに含まれるリスクを、生成された瞬間に取り除きます。インライン AI セキュリティフックは、IDE やエージェントワークフローに直接統合され、プロンプトを評価するとともに、AI 生成出力を即座にスキャンします。これにより、コードがコミットされる前にセキュリティガードレールを組み込むことができます。
エージェントベースの修復: Wiz Skills は、コーディングエージェントや AI ネイティブ IDE に、コードからクラウドまでの包括的なコンテキストと、Wiz Security Graph による検証済みの攻撃対象領域に関する検出結果を提供します。この機能により、チームは、デベロッパー個人の IDE 上でも、バージョン管理システム内のリポジトリや pull リクエスト単位でも、エージェント主導の自動修復ワークフローを実行することができます。
シャドー AI の排除: Wiz の動的な AI-Bill of Materials（AI-BOM）は、環境全体に存在するすべての AI フレームワーク、モデル、IDE 拡張機能を自動的にインベントリ化します。これにより、スタック全体でどのツールがコード生成に使われているかを完全に可視化し、Gemini Code Assist や GitHub Copilot などの承認済みツールを管理すると同時に、未承認のシャドー AI プラグインを検出することができます。

Wiz の発表について詳しくは、こちらをご覧ください。

AI エージェントとエージェント型ウェブの保護

クラウドと AI ワークロードを保護するだけでなく、Google Cloud の安全性を重視して設計された基盤は、エージェント、不正対策、ウェブ領域に至るまで、AI 時代のスピードでイノベーションを加速します。

Gemini Enterprise Agent Platform によるエージェントの保護とガバナンスGoogle は本日、エージェントの構築、オーケストレーション、ガバナンス、最適化を支援する、Gemini Enterprise Agent Platform を発表しました。主な内容は次のとおりです。

Agent Identity により、アクセス管理と AI ガバナンスを大規模に実現できます。新機能では、エージェントごとに固有の ID を付与し、特定の認証フローや、ユーザーから範囲を限定して委任された権限のもとで、自律的に動作できるようになります。
Agent Gateway は、すべてのエージェント間接続およびエージェントとツール間の接続に対して、ポリシー適用を実現します。エンタープライズ向けエージェントトラフィックを管理するとともに、MCP や Agent2Agent（A2A）などのエージェントプロトコルに対応し、あらゆるエージェント間インタラクションを検査して保護します。
モデルとエージェントのインタラクションを保護するランタイム保護機能 Model Armor は、Agent Gateway、Agent Runtime、Langchain との統合をプレビュー提供します。Firebase との統合は一般提供となります。デベロッパーはコードを変更することなく、エージェントのトラフィックやインタラクションに対して、インラインでのポリシー適用と無害化処理を行うことができます。これらのインテグレーションにより、プロンプトインジェクション、ツールポイズニング、センシティブデータ漏洩などのランタイムリスクに対する Model Armor の保護範囲が、Google Cloud の各種サービスと AI 製品群全体に広がります。

Google Cloud Fraud Defense と Chrome Enterprise でエージェント型ウェブを保護本日、Google は reCAPTCHA をさらに進化させる新サービスとして、Google Cloud Fraud Defense をリリースしました。本サービスは一般提供されています。この包括的なプラットフォームは、ボット、人間、エージェントが正当な利用主体であり、適切な権限を持っているかどうかを見極められるよう設計されています。さらに、Fraud Defense は Google のエコシステム保護と同等のスケールおよびシグナルを活用し、人間ユーザーと AI エージェント向けの新機能をまもなくプレビュー提供します。これにより、アカウント作成やログインから、支払いやチェックアウトに至るまで、デジタルコマースジャーニー全体の安全性を強化します。

AI の安全性を確保するという Google の取り組みは、AI とのインタラクションに不可欠なエンドポイントであるブラウザにも広がっています。Chrome Enterprise は、企業データを守りながら AI を安全に活用するために必要な可視性とコントロールを提供し、AI 時代に向けた包括的なデータ保護を実現します。

現在プレビュー提供中の AI 拡張機能向け脅威検出機能は、高度な拡張機能テレメトリーを可視化し、セキュリティチームが AI エージェントの異常な挙動を検出し、迅速に対応できるようにします。
まもなく一般提供される新しいシャドー AI レポート機能は、従業員による未承認のウェブベース AI や SaaS アプリケーションの利用を検知することで、シャドー AI の利用実態を可視化できます。

Trusted Cloud の新機能

Google は、お客様の環境を保護するため、クラウドプラットフォーム全体で新たなセキュリティコントロールの提供を続けるとともに、ID、データ、ネットワーク領域にわたる機能強化を進めています。今回は、以下のアップデートをご紹介します。

最新の IAM による権限管理の簡素化最小権限を迅速かつシンプルに実現するため、事前定義ロールのカタログを簡素化し、管理者、編集者、閲覧者などの使いやすいロールに整理しました。あわせて、IAM role picker や機密性の高い操作に対する再認証機能なども提供します。

データセキュリティクラウドプラットフォームのデータセキュリティポートフォリオ向けに、最もセンシティブなデータを保護し、AI による変革を加速する複数の新機能を提供します。

Confidential Computing: NVIDIA とのパートナーシップにより、Google は本日、Confidential Computing の G4 VM 向けサポートを発表しました。Google Compute Engine（GCE）の Confidential G4 VM は、NVIDIA RTX PRO 6000 Blackwell Server Edition GPU を搭載し、グローバルでプレビュー提供されます。これにより、機密性の高いさまざまな AI ワークロードにおいて、機密性と完全性を強化します。さらに、Intel とのパートナーシップのもと、Google は C4 Confidential VMs のプレビュー提供も開始します。第 6 世代 Intel Xeon プロセッサに Intel TDX を採用し、業界をリードするコンピューティング密度とパフォーマンスを実現するとともに、さまざまな AI および分析ワークロードを保護します。
Cloud Key Management Services（KMS）: 新たに Confidential External Key Manager（cEKM）をプレビュー提供します。任意のリージョンで外部鍵をホストして保護しながら、機密環境内で検証可能な統制を維持できる柔軟な運用が可能になります。
ポスト量子暗号（PQC）: 新たに KMS Quantum Safe Key Imports をプレビュー提供します。これにより、耐量子アルゴリズムを用いた、お客様独自の鍵を持ち込めるようになります。
Secret Manager: パスワード漏洩防止とプロンプトインジェクションのリスク緩和に向け、Secret Manager と Agent Development Kit のネイティブ統合を一般提供します。

ネットワークセキュリティGoogle Cloud のクロスクラウドネットワークセキュリティ製品群に、複数の新機能を追加します。

Cloud NGFW: 巧みに検知を回避するゼロデイ脅威への防御強化に向け、Cloud NGFWの高度なマルウェアサンドボックスを、今年後半にプレビュー提供します。この機能は、Palo Alto Networks Advanced Wildfire を基盤としており、70,000 社を超える Palo Alto Networks の顧客から得られたデータを基にトレーニングし、既知か未知を問わずマルウェアの 99% を阻止します。
Cloud Armor: Thales Imperva を活用した新しい Cloud Armor マネージドルールをプレビュー提供します。レイヤ 7 のアプリケーション攻撃やゼロデイ CVE（React2Shell など）を検出できます。

SCC で Google Cloud のセキュリティを強化Google Cloud ネイティブのセキュリティソリューションである Security Command Center（SCC）は、Google Cloud 上の従来のアプリケーションと AI アプリケーションの両方を保護するために、クラウドセキュリティのベースラインを確立します。

AI エージェント、モデル、MCP サーバーは、継続的な検出と包括的なリスク分析により、脅威、脆弱性、設定ミスを特定することで保護されます。
SCC は、Google Cloud ワークロードのシャドー AI を把握するために、ランタイムの詳細な可視化を強化します。近日プレビュー提供予定の SCC では、エージェント、Cloud Run または GKE 上でホストされる MCP サーバー、GKE 上で稼働する推論エンドポイントなど、非管理下のエージェント型ワークロードを自動検出し、SCC 上でポスチャー検出結果として表示されます。
強化された Security Command Center Standard ティアは、データセキュリティポスチャー管理、コンプライアンス管理、脆弱性管理、リスク分析を備えています。これにより、Google Cloud のすべてのお客様は追加費用なしで、導入初日から強力なセキュリティ、コンプライアンス、リスク対応体制を確立できます。

次のステップ

Google をセキュリティチームの一員に迎えることで、インテリジェンス主導の AI ネイティブな防御力、安全性を重視して設計されたオープンクラウドの柔軟性、そして自社チームの延長として頼れる、業界屈指の現場経験を持つエキスパートを得られます。

こうした新たなイノベーションと、これから先を守る方法については、セキュリティスポットライトをご覧ください。また、Next ’26 の発表内容についてさらに詳しく知るには、ライブ配信またはオンデマンドで視聴できる多数のセキュリティ関連ブレイクアウトセッションもぜひご覧ください。

- Francis deSouza、Google Cloud COO 兼セキュリティプロダクト担当プレジデント

DevOps × AI Agent Hackathon 2026: AI エージェントを「つくる、まわす、とどける」夏

Fri, 08 May 2026 02:00:00 +0000

生成 AI の活用は、チャットで「答える」段階から、「自律的に実行する」へと急速に進化しています。エンジニアの皆さんも、業務のなかでその変化を肌で感じているのではないでしょうか。

そうした潮流のなかで、グーグル・クラウド・ジャパン合同会社は、ファインディ株式会社主催の、「DevOps × AI Agent Hackathon 2026」に協賛します。賞金総額 200 万円、最終ピッチの舞台は Google 渋谷オフィス（渋谷ストリーム）。エントリー受付がスタートしました。

参加はこちらから

企画から運用までを一気通貫で体験する「つくる、まわす、とどける」3 つのコンセプト

DevOps × AI Agent Hackathon 2026 は、Gemini Enterprise Agent Platform、Gemini などを必須技術として、AI エージェントの企画から開発、デプロイ、運用までを一貫して体験できるハッカソンです。単なるプロトタイピングにとどまらず、実運用を見据えた DevOps のプロセス全体をカバーします。

このハッカソンの背骨にしているのが、3 つの動詞です。

つくる。Google の AI、Gemini を中核に、実務で役立つ独創的な AI エージェントを設計・実装します。アイデアの面白さだけでなく、エージェントとしての必然性、自律的に判断しタスクを実行する設計まで踏み込んで評価します。

まわす。CI/CD など DevOps のフローを構築し、AI を継続的に改善するサイクルを参加者自身が回します。机上の理論ではなく、実装して動かしてみる。これが意外と、ハッカソンでは新鮮な経験になるはずです。

とどける。Google Cloud へのデプロイを通じて、スケーラブルな環境で本番品質のプロダクトをユーザーに届けます。動くものをつくる、ではなく、届くものをつくる。そこまでをゴールに置いています。

チームビルディング、Bootcamp、審査員フィードバック ― 学びを底上げする 3 つの仕掛け

「いきなり AI エージェントの実運用まで」と聞くとハードルが高そうに感じるかもしれません。そう感じた方も心配いりません。学びを支える仕組みを 3 つ用意しています。

1 つ目はチームビルディングイベントの開催。チーム開発を経験したい個人参加者向けに、2026 年 6 月 7 日（日）にチームビルディングイベントが実施されます。個人、チームでのワークショップを通して、アイデアの発散からチームづくりまでをサポートします。「気になるけれど 1 人だと不安」という方は、ここを最初の一歩にしてみてください。

2 つ目は Bootcamp。グーグル・クラウド・ジャパンは、6 月 1 日（月）〜 6 月 12 日（金）まで「Agentic AI Bootcamp 2026」と題し、実践的なオンラインハンズオンセミナーを開催します。（無料受講・事前申込制）。Agent Development Kit (ADK)、Gemini Enterprise Agent Platform、Cloud Run、Gemini API など、ハッカソン本番で使う技術をハンズオンで身につけ、参加者全員のベースラインを引き上げます。

登録はこちらから

3 つ目は審査員によるフィードバック。AI エージェント開発およびその周辺領域で実績を持つエンジニアが、提出作品に具体的なフィードバックを行います。さらに、9 月開催予定のアフターイベント（オンライン）では、惜しくも入賞には至らなかったものの、優れた着想や技術が光る「審査員の推し作品」を取り上げ、その魅力や工夫をたたえます。

ハッカソンに挑むみなさんへ

AI エージェントは、エンジニアにとっての遊び道具にも、業務の主役にもなり得るテクノロジーです。AI エージェントが業務の中心へと進んでいくいまこそ、企画から運用まで一気通貫で挑める場が必要だと考えています。このハッカソンが、腕試しの場であり、新しい仲間と出会う場であり、そしてキャリアのなかで記憶に残る夏になることを願っています。「つくる、まわす、とどける」という 3 つの動詞を、皆さんならどう実装するのか。本ハッカソンを通じて、AI エージェントを本番環境へ展開するまでの一連のイメージを、皆さんが具体的につかんでいただければと思います。

エージェントを強化する: Google 公式 Skills リポジトリを発表

Mon, 27 Apr 2026 02:00:00 +0000

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

AI モデルの性能向上に伴い、Firebase や Gemini API、BigQuery、GKE などの Google Cloud プロダクトを活用した開発にエージェント型 AI ツールを取り入れる技術者が増えています。では、こうしたテクノロジーに関する正確かつ最新の情報を、モデルにどのように与えればよいのでしょうか。

その方法の一つが、AI エージェントを、グラウンディングされたリアルタイム情報源に接続することです。たとえば Google は、デベロッパー向けドキュメント用の Model Context Protocol（MCP）サーバーを提供しています。ただし、MCP サーバーを過度に利用すると、「コンテキストの肥大化」と呼ばれる問題が生じることがあります。大量のコンテキストがコンテキストウィンドウに読み込まれることで、モデルが混乱し、トークンコストもかさんでしまうのです。

そこで必要になるのが、エージェントに追加の、しかも凝縮された専門知識を持たせる仕組みです。それを実現するのが Agent Skills（エージェントスキル）です。

スキルとは、「エージェントに新たな機能と専門知識を与えるための、シンプルでオープンな形式」です。特定のテクノロジーやタスクについて、エージェント向けに最適化された簡潔なドキュメントだと考えると分かりやすいでしょう。スキルは Markdown で記述され、参照ファイル、コードスニペット、そのほかのアセットを含めることができます。エージェントは必要なときにだけスキル情報を読み込むため、コンテキストの肥大化を抑えられます。

そして、Google Cloud Next 2026 の初日に、Google 公式の Agent Skills リポジトリの公開を発表いたしました。

github.com/google/skills

このリポジトリは、Google Cloud テクノロジーに特化した 13 のスキルからスタートします。

対応プロダクト: AlloyDB、BigQuery、Cloud Run、Cloud SQL、Firebase、Gemini API、Google Kubernetes Engine（GKE）
Well-Architected の柱うち 3 つに対応したスキル: セキュリティ、信頼性、コスト最適化
Google Cloud のオンボーディング、認証、ネットワークオブザーバビリティ向けの「レシピ」スキル

npx skills install github.com/google/skills を実行すると、Antigravity、Gemini CLI、サードパーティのエージェントなど、任意のエージェントにこれらのスキルをインストールできます。

このリポジトリには、今後数週間から数か月にかけて、さらに多くのスキルを追加していく予定です。続報をお待ちください。

それでは、さっそく構築を始めましょう。

- Google Cloud、シニアスタッフデベロッパーアドボケイト Megan O'Keefe

次世代のエージェントを推進する Gemini Enterprise Agent Platform を発表

Wed, 22 Apr 2026 03:49:00 +0000

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

生成 AI の黎明期において、安全で信頼性の高いビジネスツールを構築するには、膨大なエンジニアリングリソースと、試行錯誤に対する高い許容度が必要でした。私たちは、AI 開発プラットフォームである Vertex AI を通じて、こうした課題の解決を支援してきました。しかし現在、新たな段階の複雑さが課題となっています。AI エージェントが複数のシステム間で相互作用する中で、セキュリティやガバナンスのガードレールが十分に整備されないまま運用が行われているのが現状です。

AI エージェントがチームの一員として独立性と信頼性を持って行動できる真の自律的エンタープライズへと進化するためには、信頼性を維持できる強固な基盤が必要です。

新機能のご紹介：本日、AI エージェントの構築、スケーリング、ガバナンス、最適化を支援する、新しい包括的なプラットフォーム Gemini Enterprise Agent Platform を発表します。本プラットフォームは、Vertex AI の進化形であり、多くのお客様から高く評価されているモデルの選択、構築、エージェントの構築機能に加え、エージェントの統合、DevOps、オーケストレーション、セキュリティに関する新機能を統合しています。

Gemini Enterprise Agent Platform は、技術チームが製品、サービス、運用を変革する AI エージェントを構築するためのワンストップの拠点となります。これらのエージェントは、Gemini Enterprise appを通じて従業員にシームレスに提供され、IT 運用と緊密に統合することで、拡張する際にも、制御、ガバナンス、セキュリティの確保を支援します。

このプラットフォームは Model Garden を通じて、200 以上の主要なモデルへのアクセスを提供します。Gemini 3.1 Pro、Gemini 3.1 Flash Image、Lyria 3 を含む最新のファーストパーティ製モデルに加え、Gemma 4 などのオープンモデル、また、Anthropic の Claude Opus、Sonnet、Haiku といったサードパーティ製モデルもサポートしており、お客様は業務要件に合わせて最適なモデルを柔軟に選択できます。

今後、次世代のエージェント開発を推進するため、すべての Vertex AI のサービスとロードマップの拡充は、スタンドアロンのサービスとしてではなく、Gemini Enterprise Agent Platform を通じて一元的に提供されます。

Gemini Enterprise Agent Platform がビジネスにもたらす価値：Gemini Enterprise Agent Platform は、個々の AI タスクの管理から、信頼に基づいたビジネス成果の創出への移行を支援します。

構築：新しい Agent Studio のローコードで直感的なインターフェースから、アップグレードされた Agent Development Kit（ADK）のコードファーストのロジックまで、業務に最適な環境を選択できます。AI ネイティブなコーディング機能により、開発ライフサイクル全体を簡素化し、本番グレードのエージェントの迅速なリリースを支援します。
拡張：再設計された Agent Runtime により、本番環境への円滑なデプロイを実現します。数日間にわたって状態を維持する長時間実行型のエージェントをサポートし、永続的かつ長期的なコンテキストを保持する Memory Bank によって支えられています。
ガバナンス：Agent Identity、Agent Registry、Agent Gateway により、一元的な管理体制を確立します。これらの機能により、Gemini Enterprise Agent Platform 上で構築されたエージェントから、パートナーエコシステムのエージェントまで、すべてのエージェントが追跡可能な ID を持ち、エンタープライズグレードのガードレール内で動作することを支援します。
最適化：Agent Simulation、Agent Evaluation、Agent Observability により、品質を保証します。これらのツールは、完全な実行トレースとエージェントの推論に対するリアルタイムな可視性を提供し、エージェントが常に目標を達成できるよう支援します。

Gemini Enterprise Agent Platform を使い始めましょう：Google Cloud コンソールの Gemini Enterprise Agent Platform にアクセスして、新機能をお試しいただき、今すぐ構築を開始できます。

最新リリースの詳細や、Gemini Enterprise Agent Platform があらゆる段階で信頼できる本番環境対応エージェントの実現をどのように支援するかについては、以下をご覧ください。

お客様が Gemini Enterprise Agent Platform で実現していること

「Burns & McDonnell では Gemini Enterprise Agent Platform を使用し、組織の知識を企業全体に適用する方法を変革しています。ADK を活用することで、数十年にわたるプロジェクトデータをリアルタイムで実用的なインテリジェンスに変換する AI エージェントを構築しています。Gemini Enterprise Agent Platform は、確定的なビジネスルールと確率的な推論を組み合わせることで、このイノベーションを責任ある形でスケーリングできます。これにより、AI は単なる生産性向上ツールではなく、信頼できる運用機能となります。Gemini Enterprise Agent Platform により、私たちは単に知識を管理するのではなく、経験を活性化させることで、より迅速で自信を持った意思決定を推進しています。」Burns & McDonnell、チーフイノベーションオフィサー、Matt Olson 氏

「Color Health では、エンドツーエンドのケアを提供する Virtual Cancer Clinic を Gemini Enterprise Agent Platform で強化しています。Color Assistant を Agent Development Kit（ADK）で構築し、Agent Runtime を介してスケーリングすることで、より多くの女性が乳がん検診を受けられるよう支援しています。Color Assistant は、ユーザーに検診の適格性を確認するよう促し、臨床医に繋ぎ、予約をサポートします。このエージェントの強みはそのスケーラビリティにあり、より多くの人々にリーチし、個々のリスクや適格性にリアルタイムで対応することを可能にします。」

Color、AI プラットフォーム責任者、PhD.、Jayodita Sanghvi 氏

「Comcast の Xfinity Assistant を Agent Development Kit（ADK）で再構築したことで、単純なスクリプト型の自動化を超え、パーソナライズされたトラブルシューティングやセルフサービスサポートを顧客に提供する、対話型の生成インテリジェンスへと進化しました。Agent Runtime は Gemini を介した安全でグラウンディングされたやり取りを確実にしつつ、デジタルコンテインメントを向上させる高度なマルチエージェントアーキテクチャの展開を加速しています。私たちは、顧客の問題を初回で解決して再度の問い合わせを減らすだけでなく、顧客体験を大規模に再定義しています。」

Comcast、コネクティビティ＆プラットフォーム、チーフテクニカルオフィサー、Rick Rioboli 氏

「Geotab では、AI Agent Center of Excellence の急速な加速に Gemini Enterprise Agent Platform を活用しています。Google の Agent Development Kit（ADK）は、単一のガバナンスされた本番環境への経路のもとで、さまざまなフレームワークを運用できる柔軟性を提供します。同時に、構築、テスト、デプロイのサイクルを大幅に短縮する卓越した開発者体験を提供しています。Geotab にとって ADK は、エージェンティック AI ソリューションを企業全体で迅速かつ安全に拡張するための基盤です。」

Geotab、データ＆アナリティクス担当副社長、Mike Branch 氏

「ぐるなびでは Gemini Enterprise Agent Platform を活用し、AI 飲食店探索アプリ『UMAME!』を開発しており、ユーザーのコンテキストを深く理解するために Memory Bank を活用しています。従来のプロンプトベースのシステムとは異なり、エージェントはユーザーの過去の行動や好みを記憶し、最適な選択肢を積極的に提示します。これにより手動検索の手間が不要となり、ユーザー満足度を 30% 以上向上させるシームレスな体験を生み出します。私たちは、このメモリ機能が新しい食体験の未来にとって不可欠な機能であると考えています。」

株式会社ぐるなび、CTO、岩本俊明氏

「L'Oréal において Beauty Tech は単なるサポート機能ではなく、世界を動かす美を創造するための強力な原動力です。この目標を実現するため、L'Oréal は Google Cloud を基盤とした独自の Beauty Tech Agentic Platform を構築しています。Agent Development Kit（ADK）を活用し、決定論的なワークフローの自動化から、自律的な成果志向のエージェント運用への根本的な転換を推進しています。エージェントは、孤立した存在ではなく、Model Context Protocol（MCP）を通じて Beauty Tech Data Platform や主要な業務アプリケーションを含む、信頼できる企業の実体に安全に接続されています。Google Cloud は、人間による監視を中心に据えながら、このプラットフォームをグローバルに拡張するために必要なレジリエンス、マルチ LLM の柔軟性、エンタープライズグレードの信頼フレームワークを提供してくれます。」

L'Oréal、グループ CIO、Etienne BERTIN 氏

「Payhawk では、Gemini Enterprise Agent Platform を使用して AI エージェントを単純なタスク実行者から真の財務アシスタントへと変革しています。Memory Bank を活用することで、ステートレスな対話から長期的なコンテキストの保持へと移行しました。私たちのエージェントは専任のチームメンバーのように、ユーザー固有の制約や履歴を自律的に記憶します。例えば、Financial Controller Agent はユーザーの習慣を記憶して経費を自動提出するため、提出までにかかる時間を 50% 以上削減しています。この変化により、エージェントはプロンプトに反応するだけでなく、過去の行動に基づいてニーズを予測できるようになります。」

Payhawk、プリンシパルアプライド AI エンジニア、Diyan Bogdanov 氏

「PayPal では、Gemini Enterprise Agent Platform を使用してエージェントを迅速に構築し、本番環境にデプロイしています。具体的には、Agent Development Kit（ADK）と視覚的なツールを使用してエージェントの相互作用を検査し、マルチエージェントワークフローを管理しています。これにより、インテントと支払い権限のフローの段階的な可視性が得られます。Gemini Enterprise Agent Platform 上の Agent Payment Protocol（AP2）は、信頼できるエージェント決済のための重要な基盤となり、私たちのエコシステムが安全なエージェントベースのコマース体験を迅速に提供できるよう支援します。」

PayPal、AI プリンシパルエンジニア、Nitin Sharma 氏

AI エージェントの構築

開発者からビジネスユーザー、さらにはその中間に位置するあらゆるユーザーが、AI エージェントを大規模に構築し、デプロイできるよう支援することで、迅速かつ容易な AI エージェント作成を支援します。

よりスマートなエージェントを、より迅速に構築

ADK の大幅なアップグレード：Gemini モデルでは、ADK を通じて毎月 6 兆以上のトークンが処理されています。エージェントをサブエージェントのネットワークとして組織化することで、より高度な推論機能を実現します。この新しいグラフベースのフレームワークにより、エージェントが連携して複雑な問題を解決するための、明確で信頼性の高いロジックを定義できます。
セキュリティバイデザインのワークスペース：コアシステムから分離され、bash コマンドの実行やファイルの安全な管理を許可する、強化されたサンドボックス環境をエージェントに提供します。
マルチモーダルストリーミング：ライブ音声や映像キューに対するマルチモーダルサポートにより、リアルタイムの対話において人間に近い安定性をもたらします。

エージェントをエンタープライズに接続

あらゆるシステムへの安全なアクセス：Native Ecosystem Integrations によるプラグアンドプレイアーキテクチャを使用し、カスタムコーディングなしでエージェントを社内データやツールに接続します。
バックグラウンド運用の自動化：バッチ＆イベント駆動型エージェントにより、BigQuery や Pub/Sub のデータを活性化させます。これにより、コンテンツ評価やデータ分析などの大規模な非同期タスクをバックグラウンドで実行できます。

アイデアから本番環境へ数時間で

AI ドリブン開発の実現：エージェントが Google の包括的なエージェント機能群にアクセスするためのプログラマティックインターフェースを提供し、ユーザーに代わって本番環境対応エージェントの構築、評価、デプロイを行えるようにします。
Agent Studio で直接エージェント構築が可能に：Agent Studio 内で、シンプルなプロンプトの作成から複雑なエージェントのデプロイまでをシームレスに移行できるようになりました。高度なカスタマイズが必要になった場合は、ロジックを直接 ADK にエクスポートし、フルコード環境で開発を継続できます。
構築済みのエージェントによる迅速な開始：Agent Garden で厳選されたエージェントテンプレートにアクセスできます。これにはコードのモダナイゼーション、財務分析、経済調査、請求書処理などが含まれており、マルチエージェントシステムの即時構築要素として活用できます。

AI エージェントの拡張

概念実証（PoC）からライブ環境へ移行するには、実際の業務におけるパフォーマンス、状態管理、セキュリティ要件に対応できるプラットフォームが必要です。

高性能なエージェント実行の推進

最新の Agent Runtime：刷新された Agent Runtime は、1 秒未満のコールドスタートを実現し、新しいエージェントを数秒でプロビジョニングできます。
数日間にわたるワークフローのサポート：数日間にわたって自律的に実行される長時間実行型エージェントをデプロイできるようになりました。これにより、営業のプロスペクティングシーケンスの管理など、長期的な持続性を必要とする複雑な多段階ワークフローや深い推論タスクをエージェントが管理できるようになります。
セキュリティバイデザイン環境での自律アクション：Agent Sandbox は、モデルが生成したコードを安全に実行し、ホストシステムにリスクを与えることなくブラウザベースの自動化などのコンピュータユースタスクを実行するための強化された環境を提供します。
エージェント間のオーケストレーション：エージェントが複雑で、生成型、および確定的な運用パターンのサポートを含め、互いにシームレスにタスクを委譲できるようにします。これにより、コンプライアンスなどの重要なフローにおいて、エージェントは常に規定の経路に従います。

一時的なセッションデータを超えた、高精度なコンテキストの実現

インタラクションのパーソナライズ：Agent Memory Bank は、会話から長期的な記憶を動的に生成し、管理します。新しい Memory Profiles を使用することで、エージェントは低レイテンシで高精度な詳細情報を想起でき、コンテキストが失われることはありません。
AI の対話と既存レコードの連携：Agent Sessions を使用して履歴を保存、管理します。Custom Session IDs により、独自の識別子を使用してセッションを追跡し、社内データベースや CRM レコードに直接マッピングできます。
リアルタイムで人間のような対話を実現：Bidirectional Streaming 向けの WebSocket プロトコルを使用することで、顧客や従業員とのリアルタイムのやり取りにおいてエージェントの応答性を高め、遅延なく音声や映像を処理できるよう支援します。

AI エージェントのガバナンス

Gemini Enterprise Agent Platform 上で構築されたものからパートナーエコシステムから提供されたものまで、組織内のあらゆるエージェントにエンタープライズグレードの厳格さを適用する、セキュリティバイデザインアーキテクチャでガバナンスを実現します。

ID およびアクセス管理に関する信頼できる企業の実体を通じて、すべてのエージェントを一元管理します。

すべてのエージェントに検証可能な ID を付与：Agent Identity は、すべてのエージェントに固有の暗号化 ID を付与することで、エージェントのセキュリティ体制を向上させます。これにより、エージェントが行うすべての操作について、定義された認可ポリシーに紐付いた、明確で監査可能なトレースを作成します。
承認済みツールの一元ライブラリを維持：新しい Agent Registry は、信頼できる企業の実体を提供します。すべての社内エージェント、ツール、スキルをインデックス化することで、検索を簡素化し、ガバナンスおよび承認された資産のみをユーザーが利用できるようにします。
単一の制御ポイントからエージェント群を管理：Agent Gateway は、エージェントエコシステムにおける管制塔のような役割を果たします。あらゆる環境におけるエージェントとツールの間に安全で統合された接続性を提供すると同時に、一貫したセキュリティポリシーとプロンプトインジェクションやデータ漏洩から保護する Model Armor の適用を徹底します。

AI を活用したインサイトを活用し、ビジネスに影響が出る前に潜在的リスクや不審な挙動を検知

不審な挙動をリアルタイムで検知：Agent Anomaly Detection は、統計モデルと LLM-as-a-judge フレームワークを使用して、異常な推論にフラグを立てます。これは Agent Threat Detection と連携して、リバースシェルや既知の不正な IP アドレスへの接続といった悪意のある活動を可視化します。
脆弱性の自動発見：Security Command Center を基盤とした新しい Agent Security ダッシュボードが、脅威検知とリスク分析を統合します。これにより、チームはエージェントとモデル間の関係のマッピング、アセット検出の自動化、基盤となるオペレーティングシステムや言語パッケージの脆弱性スキャンを行えるようになります。

AI エージェントの最適化

Gemini Enterprise Agent Platform は、AI のパフォーマンスを把握するために必要な可視性を提供し、ロジックの改善や継続的な学習を容易にします。

リリース前のエージェントのテスト

リアルな会話をシミュレート：Agent Simulation を使用し、制御された環境下で、人間のような合成ユーザーインタラクションや仮想化されたツールに対してエージェントをテストします。エージェントは、多段階の会話全体にわたるタスクの成功率と安全性に基づいて自動的にスコアリングされます。

本番環境での監視と改善

ライブパフォーマンスの追跡：Agent Evaluation を使用し、単一の応答だけでなく会話全体のロジックを評価できるマルチターン自動評価機能を用いて、実際のトラフィックに対してエージェントを継続的にスコアリングします。すぐに利用可能なダッシュボードと Agent Observability により、複雑な推論を視覚的にトレースし、問題が発生した際にデバッグできます。
エージェントの改善を自動化：ログを手動で調査する代わりに、Agent Optimizer が実際の失敗を自動的にクラスタリングし、精度を向上させるための洗練されたシステム指示を提案します。

詳細なテクニカルガイドおよびアップデートの完全なリストは、更新されたドキュメントとリリースノートでご確認いただけます。Gemini Enterprise Agent Platform は、実験段階から本番規模でのインパクトへと移行するための、エンタープライズエージェント開発の新しい標準です。

BigQuery、Pub/Sub、ADK を使用したイベントドリブンデータエージェントの構築

Tue, 21 Apr 2026 02:00:00 +0000

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

リアルタイムの自律エージェントの必要性

データは、それに基づいて行動できる能力があってこそ価値を発揮します。現代の企業では、イベントが発生してから数時間、あるいは数分後に対応しても、手遅れになることがよくあります。金融詐欺や流動的なサプライチェーンの混乱に対処する場合も、一分一秒が重要になります。

しかし、多くのシステムは依然として、処理の遅いスケジュールされたバッチジョブや、変更を pull し続ける脆弱なマイクロサービスに依存しています。問題が表面化したときには、手遅れになっていることがよくあります。そのため、人間の調査担当者は、ログやデータベースクエリを掘り下げて情報をかき集め、それらをつなぎ合わせる作業に追われることになります。時間がかかり、骨の折れるプロセスで、スケーラビリティもありません。

イベントドリブンデータエージェントの登場

時間のかかるパイプラインや手動のトリアージを待つ代わりに、データプラットフォームが異常を検出するとすぐにアラートを push し、自律型 AI エージェントが調査して解決してくれるとしたらどうでしょうか。

これがイベントドリブンデータエージェント アーキテクチャのメリットです。BigQuery の継続的クエリ、Pub/Sub、Vertex AI Agent Engine 上の ADK エージェントを組み合わせることで、イベントをリアルタイムでトリアージして自律的に調査するパイプラインを構築できます。エージェントは高度な推論を使用してコンテキストを収集し、データを分析して、問題をその場で解決するか、人間参加型の介入が必要な場合は担当者にエスカレーションします。

ハイブリッドアーキテクチャ: 仕組み

このイベントドリブンパイプラインは、次の 3 つの主要な構成要素を活用します。

検出: BigQuery の継続的クエリは、ライブデータストリームをモニタリングし、ルールベースのエンジンを使用して異常を検出します。
ルーティング: Pub/Sub は、単一メッセージ変換（SMT）を使用してペイロードを AI エージェントが期待する正確な形式に再形成し、これらのイベントを確実に配信します。これにより、エージェントパイプラインがトリガーされ、調査が開始されます。
解決: Vertex AI エージェント（ADK で構築）がイベントを受信し、カスタムツールを使用して調査し、意思決定をログに記録します。

各コンポーネントについて詳しく見ていきましょう。具体例として、不正な金融取引をリアルタイムで検出および調査するという、シンプルなユースケースをご紹介します。

パート 1: BigQuery の継続的クエリ

BigQuery の継続的クエリでは、標準 SQL を使用してリアルタイムのイベントストリームをネイティブに構築できます。これらは、継続的に実行される永続的な SQL クエリです。受信データを分析し、SQL の結果を Pub/Sub などの宛先に即座にエクスポートします。

BigQuery でストリーミングイベントを pull 型からネイティブな push 型へと移行することで、標準 SQL を使用してデータウェアハウス内で複雑な異常（ユーザーが指定した期間内に 2 つの異なる国で取引を行うなど）を検出できます。データを別のストリーミング分析エンジンに移動する必要はありません。

この変革は、BigQuery 継続的クエリのステートフルデータ処理の公開プレビュー版のリリースによって実現しました。これにより、ストリーム間の JOIN、ウィンドウ集計、タンブリングウィンドウのネイティブサポートが導入されます。BigQuery で分散したデータストリームを関連付け、移動平均や総計などの複雑な指標を直接計算できるようにすることで、あらゆる SQL ユーザーがストリーム処理を行えるよう、その民主化を推進しています。その結果、イベントの発生を検知して即座に対応するリアルタイムの「アクションシステム」を構築するために、専門の外部ツールや高度なデータサイエンスの専門知識は必要なくなります。このアプローチは、LLM トークンの費用管理にも役立ちます。ステートフル SQL を使用して特定の異常をフィルタリングすることで、エージェントが元データに圧倒されることなく、まさに必要なコンテキストのみを処理できるようになります。

この実装は簡単です。標準 SQL クエリと EXPORT DATA ステートメントを組み合わせることで、一致する行が発生した瞬間に、その行を Pub/Sub トピックに直接ルーティングできます。

code_block: <ListValue: [StructValue([('code', 'EXPORT DATA OPTIONS (\r\n format = "CLOUD_PUBSUB",\r\n uri = "https://pubsub.googleapis.com/projects/YOUR_PROJECT_ID/topics/cymbal-bank-escalations-topic"\r\n) AS (\r\n WITH TransactionHeuristics AS (\r\n SELECT\r\n *,\r\n _CHANGE_TIMESTAMP AS bq_changed_ts,\r\n FROM APPENDS(TABLE `cymbal_bank.retail_transactions`, CURRENT_TIMESTAMP() - INTERVAL 10 MINUTE)\r\n )\r\n SELECT\r\n TO_JSON_STRING(STRUCT(\r\n window_end,\r\n user_id,\r\n COUNT(*) AS tx_count,\r\n SUM(amount) AS total_window_spend,\r\n MAX_BY(merchant_name, amount) AS highest_value_merchant,\r\n MAX_BY(merchant_category_code, amount) AS highest_value_mcc,\r\n 100 AS final_risk_score,\r\n STRUCT(\r\n APPROX_COUNT_DISTINCT(location_country) > 1 AS is_impossible_travel,\r\n LOGICAL_OR(NOT is_trusted_device) AS has_security_mismatch\r\n ) AS logic_signals\r\n )) AS data\r\n FROM TUMBLE(TABLE TransactionHeuristics, "bq_changed_ts", INTERVAL 2 MINUTE)\r\n GROUP BY window_start, window_end, user_id\r\n HAVING APPROX_COUNT_DISTINCT(location_country) > 1\r\n);'), ('language', 'lang-sql'), ('caption', <wagtail.rich_text.RichText object at 0x7f777826b3d0>)])]>

パート 2: Pub/Sub と単一メッセージ変換（SMT）

Pub/Sub でスキーマのギャップを埋める。継続的クエリからエクスポートされたイベントデータは、Pub/Sub トピックに直接送信されます。この元データを AI エージェントが使用できるようにするには、エージェントが想定するスキーマに合わせてペイロードを変換する必要があります。

専用の Cloud Functions などをデプロイしてこれらのメッセージを再フォーマットする代わりに、単一メッセージ変換（SMT）を使用して Pub/Sub サブスクリプション内だけで完結させることができます。SMT を使用すると、軽量なインライン JavaScript ユーザー定義関数（UDF）を Pub/Sub 内で直接実行して、ペイロードをその場でマッピング、再形成、クリーンアップできます。

たとえば、BigQuery ペイロードをインターセプトし、Agent Engine が想定する正確なクエリ形式を抽出する JavaScript スニペットを記述した transform.yaml を定義できます。

code_block: <ListValue: [StructValue([('code', 'function process(res) {\r\n let bq_payload = JSON.parse(res.message.data);\r\n res.message.data = JSON.stringify({"query": bq_payload});\r\n return res;\r\n}'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f777826b610>)])]>

ルーティングパイプラインを構成するには、Pub/Sub push サブスクリプションを作成します。このサブスクリプションは、変換されたすべての BigQuery イベントを AI エージェントの Webhook エンドポイントへ、自動的に直接 push します。

code_block: <ListValue: [StructValue([('code', 'gcloud pubsub subscriptions create cymbal-bank-escalations-sub \\\r\n --topic=projects/$PROJECT_ID/topics/cymbal-bank-escalations-topic \\\r\n --message-transforms-file=setup/transform.yaml \\\r\n --push-endpoint="https://YOUR_AGENT_WEBHOOK_URL" \r\n --push-no-wrapper \\\r\n --ack-deadline=600 \\\r\n --push-auth-service-account="adk-agent-sa@$PROJECT_ID.iam.gserviceaccount.com"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f777826b250>)])]>

上記の push-endpoint パラメータに注目してください。この Webhook URL は、アーキテクチャの最後の部分である AI エージェント自体によって生成されます。

パート 3: ADK と Vertex AI Agent Engine

エージェントが Vertex AI Agent Engine にデプロイされると、プラットフォームは、これらの受信イベントを受け取るために特別に設計された安全な streamQuery エンドポイントを自動的にプロビジョニングします。

これはオペレーションの頭脳です。異常が検出され、Pub/Sub 経由でルーティングされると、Vertex AI にデプロイされた ADK エージェントがメッセージによってトリガーされます。

推論ループを実装するには、ツールを備えたエージェントを定義してデプロイします。

code_block: <ListValue: [StructValue([('code', 'investigation_agent = Agent(\r\n model="gemini-2.5-flash",\r\n name="fraud_investigation_agent",\r\n description="Expert fraud analyst agent that autonomously investigates alerts...",\r\n instruction=(\r\n "You are an expert fraud investigator for Cymbal Bank. "\r\n "Your goal is to investigate financial transaction alerts, "\r\n "determine if they are fraudulent, and take appropriate action. "\r\n "Use the BigQuery toolset to analyze data in the transactions table.."\r\n "Use the Google Search toolset to search for the merchant..."\r\n "Conslidate your findings and use the escalate_to_human tool if required..."\r\n ),\r\n tools=[\r\n bigquery_toolset,\r\n google_search,\r\n ],\r\n)'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f777826b070>)])]>

具体的な指示とこのカスタムツールセットを装備したエージェントは、外部のコンテキストを積極的に収集することでアラートを自律的に調査します。BigQuery にクエリを実行してユーザーの取引履歴を取得したり、領収書などの非構造化データを分析したり、Google 検索で調査結果をグラウンディングして販売者の評判を確認したりできます。最終的には、その取引を FALSE_POSITIVE として分類するか、ESCALATION_NEEDED としてフラグを立てます。

人間参加型のメリット

このアプローチは、アーキテクチャのスケーラビリティの中核をなすものです。ノイズを効果的にフィルタリングすることで、運用上のオーバーヘッドを大幅に削減し、調査担当者が最も複雑なケースにのみ時間を費やせるようにします。ADK は豊富なツールとインテグレーションを提供しているため、エージェントはイベントを幅広いエンタープライズシステムにエスカレーションできます。これにより、人間参加型（Human-in-the-loop）のエンゲージメントを実現できるほか、人間監視型（Human-on-the-loop）オブザーバビリティを使用してパイプラインをエンドツーエンドで自動化することもできます。

すべてを 1 つに: エージェント分析

パイプラインが稼働したら、作業は構築からモニタリングに移行します。従来型のソフトウェアとは異なり、自律エージェントはバックグラウンドで永続的に実行されます。バックグラウンドで動作するため、何を行っているか、どのくらいの時間がかかっているか、どのくらいの費用がかかっているかを詳細に把握できることが重要です。

デプロイ時に BigQuery Agent Analytics プラグインを初期化することで、ADK はすべてのトレースデータ、ツールの使用状況、実行レイテンシを BigQuery に直接自動的に記録します。

このトレースデータをエージェントが出力した構造化された意思決定と結合することで、高度な分析が可能になります。これにより、動的なダッシュボードを構築し、カスタムアラートを設定して、AI ワークフォースをリアルタイムでモニタリングできるようになります。エージェント分析プラグインの使用方法について詳しくは、こちらの Codelab をご覧ください。

まとめ

リアルタイムデータストリーミングとエージェント型 AI の融合により、運用上のアラートの処理方法が変わろうとしています。

BigQuery の継続的クエリを使用してリアルタイムで検出する。
Pub/Sub SMT を使用して変換とルーティングを行う。
Vertex AI Agent Engine を使用して調査し、解決する。
BigQuery Agent Analytics プラグインを使用して分析する。

このアーキテクチャにより、ガバナンスが効いたスケーラブルなサーバーレスの Google Cloud 環境内で、異常が発生した瞬間に対応できる、プロアクティブで自律的なワークフォースを構築できます。

実際に使ってみる準備はできましたか？

Codelab では、この Cymbal Bank パイプラインをゼロから構築する方法を段階的に説明しています。

- Google、デベロッパーアドボケイト、Rachael Deacon-Smith

- BigQuery プロダクトマネージャー、Nick Orlove

デベロッパー

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 がどのようにサポートしているか

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

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

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

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

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

仕様を作成する

ウィジェット テスト

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

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

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

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

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

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

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

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

まとめ

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

Antigravity の 4 つのサーフェス

まとめ

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

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

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

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

使ってみる

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

構成要素

設計パターンの例

設定手順

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

次のステップ

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

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

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

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

フェーズ 4 の最適化

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

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

準備ができたら

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

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

API の制限

アプリケーションの制限

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

問題が発生した場合

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

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

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

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

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

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

ウィジェットテスト

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

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

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

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

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

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

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

単一エージェントコーディングからの脱却

あらゆるインフラストラクチャで、AI とクラウドアプリケーションを保護

BigQuery、Pub/Sub、ADK を使用したイベントドリブンデータエージェントの構築

イベントドリブンデータエージェントの登場

ハイブリッドアーキテクチャ: 仕組み