デベロッパー

エージェントを強化する: 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 0x7f39d0a5e190>)])]>

パート 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 0x7f39d0a5ebe0>)])]>

ルーティングパイプラインを構成するには、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 0x7f39d0a5ef40>)])]>

上記の 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 0x7f39d0a5e0d0>)])]>

具体的な指示とこのカスタムツールセットを装備したエージェントは、外部のコンテキストを積極的に収集することでアラートを自律的に調査します。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

Google Cloud のアプリケーションロードバランサへの移行: 実践ガイド

Tue, 21 Apr 2026 01:10:00 +0000

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

既存のアプリケーションロードバランサインフラストラクチャをオンプレミスのハードウェアソリューションから Cloud Load Balancing に移行すると、スケーラビリティと費用効率が大幅に向上し、Google Cloud エコシステム内での緊密な統合が実現します。しかし、多くの場合、「現在のロードバランサ構成はどうなるのか」という根本的な疑問も生じます。

既存のオンプレミスロードバランサの構成には、トラフィック操作のためのビジネスクリティカルなロジックが何年分も蓄積されていることがよくあります。こうした既存の機能は完全に移行できます。加えて、この移行は、トラフィック管理をモダナイズして簡素化する絶好の機会にもなります。

このガイドでは、既存のロードバランサを Google Cloud のアプリケーションロードバランサに移行するための実践的なアプローチを紹介します。このアプローチでは、一般的な機能に対応するために、宣言型構成と革新的なイベントドリブン型 Service Extensions エッジコンピューティング機能の両方を活用します。

シンプルで段階的な移行アプローチ

命令型のスクリプトベースシステムからクラウドネイティブな宣言型ファーストモデルへの移行には、体系的な計画が必要です。そこで、4 つのフェーズからなるシンプルなアプローチをおすすめします。

フェーズ 1: 調査とマッピング

移行を開始する前に、現状を把握する必要があります。現在のロードバランサの構成を分析して分類しましょう。各ルールの意図は何ですか？単純な HTTP から HTTPS へのリダイレクトを行っていますか？HTTP ヘッダーの操作（追加または削除）に関与していますか？それとも、複雑なカスタム認証ロジックを扱っていますか？

ほとんどの構成は、次の 2 つの主なカテゴリに分類されます。

一般的なパターン: リダイレクト、URL の書き換え、基本的なヘッダー操作、IP ベースのアクセス制御リスト（ACL）など、ほとんどのウェブアプリケーションに共通するロジック。
カスタムビジネスロジック: カスタムの独自トークン認証、高度なヘッダーの抽出 / 置換、HTTP 属性に基づく動的なバックエンド選択、HTTP レスポンス本文の操作など、アプリケーションに固有の複雑なロジック。

フェーズ 2: Google Cloud における同等機能の選択

ルールを分類したら、次はそれらを適切な Google Cloud 機能にマッピングします。これは 1 対 1 の置き換えではなく、戦略的な選択となります。

オプション 1: 宣言型の方法（ルールの約 80%）一般的なパターンの大部分については、通常はアプリケーションロードバランサに組み込まれている宣言型機能を活用することが最適なアプローチです。スクリプトの代わりに、構成ファイルで望ましい状態を定義します。これにより、管理、バージョン管理、スケーリングが容易になります。

宣言型機能マッピングの一般的なパターン:

リダイレクト / 書き換え -> アプリケーションロードバランサの URL マップ
ACL / スロットリング -> Google Cloud Armor のセキュリティポリシー
セッションの永続性 -> バックエンドサービス構成

オプション 2: プログラムによる方法（複雑なカスタムルールの場合）複雑なカスタムビジネスロジックを扱う場合、プログラムによる同等の方法として Service Extensions があります。これは、Rust、C++、Go で記述したカスタムコードをロードバランサのデータパスに直接挿入できる強力なエッジコンピューティング機能です。このアプローチにより、最新のマネージド型高パフォーマンスフレームワークで柔軟性を確保できます。

このフローチャートは、各構成に適した Google Cloud の機能を判断するためにお役立てください。

フェーズ 3: テストと検証

構成に適した方法を選択したら、本番環境のセットアップを反映したステージング環境に新しいアプリケーションロードバランサ構成をデプロイする準備が整います。移行対象のロジックに特に注意しながら、アプリケーションのすべての機能を徹底的にテストします。自動テストと手動 QA を組み合わせて、リダイレクトやセキュリティポリシー、そしてカスタムの Service Extensions ロジックが想定どおりに動作することを検証します。

フェーズ 4: 段階的なカットオーバー（カナリアデプロイ）

すべてのトラフィックについて切り替えを一度に行うのではなく、段階的な移行戦略を実施します。最初は、本番環境トラフィックの少ない割合（5～10% など）を新しい Google Cloud ロードバランサにルーティングします。この初期段階では、レイテンシ、エラー率、アプリケーションのパフォーマンスなどの主要な指標を必ずモニタリングしてください。確信が持てたら、アプリケーションロードバランサにルーティングするトラフィックの割合を徐々に増やしていきます。重大な問題が発生した場合に備えて、以前のインフラストラクチャに戻すための明確なロールバック計画も常に用意しておきましょう。

スムーズな移行のためのベストプラクティス

Google の実践経験に基づき、ロードバランサの移行計画を立てる際に役立つ推奨事項を以下にまとめます。

先に分析してから移行する: 既存の構成を徹底的に分析することが最も重要なステップです。不要になったロジックの「リフト＆シフト」を行わないようにします。
宣言型を優先する: デフォルトとして、Google Cloud のマネージド型、宣言型の機能（URL マップ、Cloud Armor）を常に先に使用します。これらの機能は、よりシンプルでスケーラブルであり、メンテナンスも少なくて済みます。
Service Extensions は戦略的に使用する: Service Extensions は、宣言型機能では処理できない複雑なカスタムビジネスロジックのために取っておきます。
すべてをモニタリングする: 移行中は、既存のロードバランサと Google Cloud ロードバランサの両方を継続的にモニタリングします。トラフィック量、レイテンシ、エラー率などの主要な指標を注視して、問題が発生した場合は即座に検出して対処します。
チームのトレーニングを行う: Cloud Load Balancing のコンセプトについて、チームにトレーニングを提供します。これにより、チームは新しいインフラストラクチャを効果的に運用、維持できるようになります。

既存のオンプレミスロードバランサインフラストラクチャからの移行は、単なる技術的なタスクではなく、アプリケーション配信をモダナイズする機会です。現在のロードバランシングの構成と機能を、宣言型のアプリケーションロードバランサ機能またはプログラムによる Service Extensions のいずれかに入念にマッピングすることで、スケーラビリティ、復元力、費用対効果に優れたインフラストラクチャを構築し、将来の需要に対応できます。

移行を始めるには、アプリケーションロードバランサと Service Extensions の特徴や高度な機能を確認して、アプリケーションに適した設計を考案します。詳細なガイダンスや複雑なユースケースについては、Google Cloud チームにお問い合わせください。

- Google Cloud、カスタマーエンジニア、Gopinath Balakrishnan

- Google Cloud、カスタマーエンジニア、Xiaozang Li

データレイヤの有効化によるプロダクションレディな AI の実現

Fri, 17 Apr 2026 02:00:00 +0000

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

生成 AI を使用したアプリケーションやシステムとそれらがもたらす新たな機会について議論する際、データはエコシステム内で代替不可能なコンポーネントとして位置づけられます。具体的には、企業が日々収集、保持、使用しているデータが該当します。このデータは、アプリケーション、分析、ナレッジベースなどの支柱として機能します。データの保存と操作にはデータベースが使用されます。AI を活用したイニシアチブや新しいアプリケーションのほとんどは、このデータレイヤを使用することになります。

では、AI システムでデータを使用するにはどうすればよいでしょうか。Google データベースでデータを準備して AI モデルに使用する方法を解説するラボをいくつかご紹介します。

セマンティック検索: データベース内のテキストエンベディング

はじめに、セマンティック検索用のデータを準備して最初のテストを実行し、セマンティック検索の結果に基づいて生成 AI モデルの回答をグラウンディングすることで回答を強化します。グラウンディングデータは、RAG（検索拡張生成）の基盤となります。その後、最新のインデックス作成手法を使用してエンベディングをインデックス化することで、検索のパフォーマンスを向上させることができます。

そのための選択肢の一つとなるのが Google AlloyDB データベースです。AlloyDB は AI モデルと直接統合されており、要求の高いワークロードにも対応できます。次のラボでは、AlloyDB クラスタの作成、サンプルデータの読み込み、エンベディングの生成から、それらのエンベディングを使用して生成 AI モデルから拡張回答を生成するまでのすべての手順を説明します。

aside_block: <ListValue: [StructValue([('title', 'ラボに移動'), ('body', <wagtail.rich_text.RichText object at 0x7f39d2b44040>), ('btn_text', ''), ('href', ''), ('image', None)])]>

AI の統合は AlloyDB に限定されません。すべての Google Cloud データベースに AI が統合されており、セマンティック検索用のエンベディングの生成や利用が可能です。たとえば、Cloud SQL を使用している場合は、既存の PostgreSQL または MySQL インスタンス内で直接、セマンティック検索用のエンベディングを生成して使用することもできます。

次の 2 つのラボは上で紹介したラボとよく似ていますが、Google AlloyDB for PostgreSQL の代わりに Cloud SQL for PostgreSQL と Cloud SQL for MySQL を使用し、モデルの回答のグラウンディングエンジンとしてセマンティック検索を使用します。SQL 言語やデータベースエンジンの違いにより、一部の手順は異なりますが、主な考え方は同じです。つまり、データを使用してモデルの回答をグラウンディングし、出力を改善します。

aside_block: <ListValue: [StructValue([('title', 'ラボに移動'), ('body', <wagtail.rich_text.RichText object at 0x7f39d2b44970>), ('btn_text', ''), ('href', ''), ('image', None)])]>

テキストデータを使用したセマンティック検索は、回答の信頼性と有用性を高めるための基礎となる重要な機能の一つですが、Google の生成 AI モデルが提供できる機能はそれだけにとどまりません。次に、マルチモーダル検索を紹介します。

マルチモーダルエンベディング: 検索に画像を取り入れる

現実の世界では、当然のことながら視覚を含むすべての感覚を使って周囲の世界を評価します。Google のマルチモーダルエンベディングモデルは、理解のレイヤをさらに追加し、テキストだけでなく画像にもエンベディングを使用することで検索を改善します。

次のラボでは、AlloyDB に格納され、Google Cloud Storage の画像で補完された商品のカタログを使用します。このラボでは、テキストの説明と画像の両方をセマンティック検索に使用します。テキストと画像を相互に補完または置換させることで画像入力に基づく検索を自然に回答に組み込む方法を示します。

aside_block: <ListValue: [StructValue([('title', 'ラボに移動'), ('body', <wagtail.rich_text.RichText object at 0x7f39d2b44070>), ('btn_text', ''), ('href', ''), ('image', None)])]>

RAG と検索に利用できるツール全般について理解するにはデータを準備して最初の一歩を踏み出すことが重要ですが、Google はデータの準備なしで AI との直接的な統合によってデータ分析を行う機能を提供しています。

AlloyDB AI 関数と再ランキング

Google AlloyDB データベースは、データの準備なしで一部の AI 機能を使用できる追加の AI 統合を備えています。たとえば、AI.IF 関数を使えばセマンティック検索を即座に実行できます。この関数は、自然言語クエリを使用して感情の評価や列のデータの比較を行い、クエリ条件でフィルタリングされた結果を返します。また、検索出力にランキング関数を適用して、最終的な結果を改善することもできます。以下のラボで新しい機能を試して、ご自身のユースケースに役立つかどうか感想を聞かせてください。

aside_block: <ListValue: [StructValue([('title', 'ラボに移動'), ('body', <wagtail.rich_text.RichText object at 0x7f39d2b44b20>), ('btn_text', ''), ('href', ''), ('image', None)])]>

ところで、SQL にあまり詳しくない人や、データベースのデータ構造に慣れていない人はどうすればよいでしょうか。そうした人に対応するのが AlloyDB NL2SQL です。

AlloyDB AI の自然言語を使用して SQL を生成する

AlloyDB の「alloydb_ai_nl」拡張機能を使用すると、すぐに利用できるデフォルトのメタデータに基づいて SQL クエリを生成できるだけでなく、自動またはカスタムのコンテキストを構築して、クエリ生成機能を最大限に活用できます。

NL2SQL 関数は、テーブルの実際のデータサンプルに基づいて、データ構造、テーブル間の関係、メタデータを記述するレイヤを追加できます。データ自体を損なうことなく、AI モデルが最適なクエリを構築する方法を理解するのに必要な情報を提供します。次のラボでは、新しい機能の使用を開始し、データスキーマに基づいて最初のクエリを生成する方法を説明します。

aside_block: <ListValue: [StructValue([('title', 'ラボに移動'), ('body', <wagtail.rich_text.RichText object at 0x7f39d2b44160>), ('btn_text', ''), ('href', ''), ('image', None)])]>

テストから本番環境へ

これらのラボは、Google の Google Cloud でのプロダクションレディな AI プログラムの「データ基盤から高度な RAG へ」モジュールの一部です。Google Cloud のサービスとツールが提供する AI 機能を導入するのに役立つ他のモジュールもご確認ください。これらのモジュールが、最新のテクノロジーの可能性を最大限に活用した高品質なアプリケーションの構築に役立つことを願っています。

また、AlloyDB と Cloud SQL のリリースノートにもご注目ください。エンジニアリングチームは、新機能と改善に取り組んでいます。無料試用をお楽しみください。

- データベース、Cloud アドボケイト、Gleb Otochkin

Envoy: エージェント型 AI ネットワーキングのための将来を見据えた基盤

Fri, 17 Apr 2026 01:30:00 +0000

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

昨今のエージェント型 AI 環境では、ネットワークに新たな責任が課せられています。

従来のアプリケーションスタックでは、ネットワークは主にサービス間でリクエストを移動するものでした。しかし、最近のホワイトペーパー Cloud Infrastructure in the Agent-Native Era で説明されているように、エージェントシステムでは、モデル呼び出し、ツール呼び出し、エージェント間のやり取り、エージェントができることを定義するポリシーの決定の間にネットワークが位置します。多様なフレームワーク上に構築されることが多いエージェントが急速に普及しているため、すべてのエージェントパスにわたってガバナンスとセキュリティを一貫して大規模に適用する必要があります。これを実現するには、適用レイヤがアプリケーションレベルから基盤となるインフラストラクチャに移行する必要があります。つまり、ネットワークはもはや盲目的なトランスポートレイヤとして機能することはできず、より多くのことを理解し、より適切に適用を行い、より迅速に適応する必要があります。この移行において役立つのが Envoy です。

Envoy は、高パフォーマンスの分散プロキシおよびユニバーサルデータプレーンとして、大規模なスケーリングに対応するように構築されています。Google Cloud を含む要求の厳しいエンタープライズ環境で信頼されており、単一サービスのデプロイから、上り（内向き）、下り（外向き）、サイドカーの各パターンを使用した複雑なサービスメッシュまで、あらゆるものをサポートします。Envoy は、優れた拡張性、堅牢なポリシー統合、運用上の成熟度により、プロトコルが急速に変化し、制御が不十分な場合のコストが高くなる時代に特に適しています。エージェント型 AI を構築するチームにとって、Envoy は単なるコンセプトではなく、実用的でプロダクションレディな基盤です。

エージェント型 AI がネットワーキングの問題を変える

エージェントワークロードは依然としてトランスポートとして HTTP を使用することが多いですが、従来の HTTP 仲介役が依存する前提の一部には従いません。Model Context Protocol（MCP）や Agent2agent（A2A）などのプロトコルは、HTTP 上で JSON-RPC または gRPC を使用し、標準の HTTP リクエスト / レスポンスセマンティクスに加えて、クライアントとサーバーがそれぞれの機能を交換する MCP 初期化などのプロトコルレベルのフェーズを追加します。仲介役が適応する必要がある、エージェントシステムの主な側面は次のとおりです。

企業ガバナンスの多様な要件。主な課題は、安全性、セキュリティ、データプライバシー、規制遵守に関する、企業にとって譲れない幅広い要件を満たすことです。これらのニーズは、標準的なネットワークポリシーの枠を超えることが多く、内部システムとの緊密な統合、カスタムロジック、新しい組織ルールや外部規制に迅速に適応する能力が必要になります。そのため、企業が独自のガバナンスモデルを組み込める、拡張性の高いフレームワークが求められます。
ポリシー属性は、ヘッダーではなくメッセージ本文内に存在する。パスやヘッダーなどのポリシー入力に簡単にアクセスできる従来のウェブトラフィックとは異なり、エージェントプロトコルでは、重要な属性（モデル名、ツール呼び出し、リソース ID など）が JSON-RPC または gRPC ペイロードの奥深くに埋もれていることがよくあります。このため、仲介役はメッセージの内容を解析して理解し、コンテキストに応じたポリシーを適用できる必要があります。
多様で進化するプロトコルの特性に対応する。エージェントのプロトコルは一様ではありません。Streamable HTTP を使用する MCP のような一部のプロトコルでは、（Mcp-Session-Id などを使用した）分散プロキシ全体でのセッション管理が必要となるステートフルなインタラクションが導入されることもあります。このような多様な動作をサポートする必要性と、将来のプロトコルのイノベーションにより、本質的に適応性と拡張性に優れたネットワーキング基盤の必要性が高まっています。

これらの要因により、企業は単なる接続性以上のものを必要としています。ネットワークは、前述した重要なガバナンスのニーズを満たす中心的な役割を果たす必要があります。これには、プロトコルとエージェントの動作の急速な進化に対応しながら、一元化されたセキュリティ、包括的な監査可能性、きめ細かいポリシーの適用、動的なガードレールなどの機能を提供することが含まれます。簡単に言えば、エージェント型 AI はネットワークを単なるトランジットパスから重要な制御ポイントに変えます。

Envoy がこの移行に対応できる理由

Envoy は、以下の 3 つの理由から、エージェント型 AI ネットワーキングに最適です。

実証済み。Envoy は、セキュリティが重要な大規模環境で企業がすでに利用しており、新世代のトラフィック管理とポリシー適用を支える信頼できるプラットフォームとなっています。
拡張可能。Envoy は、ネイティブフィルタ、Rust モジュール、WebAssembly（Wasm）モジュール、外部処理パターンを通じて拡張できます。これにより、プラットフォームチームは、エコシステムが変化するたびにネットワーキングレイヤを再構築することなく、新しいプロトコルを採用できるようになります。
今すぐ運用に役立つ。Envoy はすでに、コントロールプレーンのゲートウェイ、適用ポイント、オブザーバビリティレイヤ、統合サーフェスとして機能しています。そのため、標準が定着するのを待たずに今すぐ移行する必要がある組織にとって、実用的な選択肢となります。

Envoy は、以下の中核的な強みを基盤として、エージェントネットワーキングに特有のニーズを満たすアーキテクチャの進歩を遂げています。

1. Envoy はエージェントトラフィックを理解する

エージェントネットワーキングの最初の要件はシンプルです。ゲートウェイはエージェントが実際に何をしようとしているのかを理解する必要があるということです。

ただし、これはそれほど簡単ではありません。MCP、A2A、OpenAI スタイルの API などのプロトコルでは、重要なポリシーシグナルがリクエスト本文内に存在することがあります。従来の HTTP プロキシは、本文を不透明なバイトストリームとして扱うように最適化されています。この設計は効率的ですが、プロキシで適用できることが制限されます。JSON メッセージを使用するプロトコルの場合、プロキシはポリシーの適用に必要な属性値を見つけるために、リクエスト本文全体をバッファリングする必要がある場合があります。特に、それらの属性が JSON メッセージの末尾にある場合はその必要性が高まります。使用されたトークンに基づくレート制限など、生成 AI プロトコルに固有のビジネスロジックでも、サーバーのレスポンスの解析が必要になる場合があります。

これに対処するために、Envoy は、HTTP で伝送されるプロトコルメッセージをデフレーミングし、有用な属性をフィルタチェーンの残りの部分に公開します。生成 AI プロトコルの拡張性モデルは、次の 2 つの目標を指針としています。

RBAC（ロールベースアクセス制御）やトレーサーなど、生成 AI プロトコルにそのまま対応する既存の HTTP 拡張機能を簡単に再利用できる。
デベロッパーが HTTP や JSON エンベロープを処理する必要がなく、生成 AI のビジネスロジックに集中できるように、生成 AI 固有の拡張機能用のデフレーミングされたメッセージに簡単にアクセスできる。

これらの目標に基づき、生成 AI プロトコルの新しい拡張機能は、依然として HTTP 拡張機能として構築され、HTTP フィルタチェーンで構成されます。これにより、OAuth や mTLS 認証などの HTTP ネイティブのビジネスロジックと生成 AI プロトコルのロジックを 1 つのチェーンで混在させる柔軟性が得られます。デフレーミング拡張機能は、HTTP で伝送されるプロトコルメッセージを解析し、抽出された属性、さらには解析されたメッセージ全体を含むアンビエントコンテキストを、既知のフィルタ状態とメタデータ値を介してダウンストリームの拡張機能に提供します。

Envoy では、すべてのポリシーコンポーネントが JSON エンベロープやプロトコル固有のメッセージ形式を独自に解析することを強制するのではなく、これらの属性を構造化されたメタデータとして利用できるようにします。ゲートウェイがプロトコルメッセージをデフレーミングすると、ext_authz や RBAC などの既存の Envoy 拡張機能がプロトコルプロパティを読み取り、MCP のツール名、A2A のメッセージ属性、OpenAI のモデル名などのプロトコル固有の属性を使用してポリシーを評価できます。

アクセスログには、モニタリングと監査を強化するためのメッセージ属性を含めることができます。プロトコル属性は Common Expression Language（CEL）ランタイムでも使用できるため、RBAC や複合拡張機能で複雑なポリシー式を簡単に作成できます。

バッファリングとメモリ管理Envoy は、HTTP リクエストをプロキシする際にできるだけ少ないメモリを使用するように設計されています。しかし、エージェントプロトコルの解析には、特に拡張機能でメッセージ全体をメモリに格納する必要がある場合、変動する量のバッファ領域が必要になることがあります。特に、信頼できないトラフィックが存在する場合は、拡張機能でより大きなバッファを使用できる柔軟性と、メモリ枯渇からの適切な保護のバランスを取る必要があります。

これを実現するために、Envoy ではリクエストごとにバッファサイズを制限できるようになりました。リクエストデータを保持するバッファもオーバーロードマネージャーと統合されているため、アイドルタイムアウトの短縮や、長期間にわたって最も多くのメモリを消費するリクエストのリセットなど、メモリ不足時のあらゆる保護アクションが可能になります。これらの変更により、Envoy はリソース効率を損なうことなく、生成 AI プロトコルのゲートウェイおよびポリシー適用ポイントとして機能できるようになっています。

2. Envoy は重要な事項に関するポリシーを適用する

トラフィックを理解することは、ゲートウェイがそれに基づいて動作できる場合にのみ役立ちます。

エージェントシステムでは、ポリシーはエージェントがアクセスできるサービスだけでなく、エージェントが呼び出せるツール、使用できるモデル、提示する ID、消費できる量、追加の制御が必要な出力の種類も規定するものです。これらは、単純なレイヤ 4 またはパスベースの制御よりも価値の高い決定であり、エージェントが企業に代わって行動することを許可する場合に、企業が重視する種類の制御です。

この点において Envoy は、トランスポートレベルのセキュリティとアプリケーション対応のポリシー適用を組み合わせることができるため、優れています。チームは、mTLS と SPIFFE ID でワークロードを認証し、RBAC、外部認証、外部処理、アクセスロギング、CEL ベースのポリシー式を使用してプロトコル固有のルールを適用できます。

この機能は、プラットフォームチームがエージェントの開発と適用を切り離せるため、非常に重要です。デベロッパーは有用なエージェントの構築に集中でき、オペレーターはツール、モデル、プロトコルが変化し続けても、ネットワークレイヤで一貫したゼロトラスト体制を維持できます。このゼロトラストの分離の好例は、「エージェントの背後にユーザーがいる」重要なシナリオ、つまり AI エージェントが人間のユーザーに代わってタスクを実行する必要がある場合です。従来、ユーザーの認証情報をアプリケーションに直接渡すことは、重大なセキュリティリスクをもたらします。エージェントが侵害されたり、プロンプトインジェクションによって操作されたりした場合、攻撃者は認証情報を抜き取ったり、不正使用したりできるためです。ID 管理を Envoy にオフロードすることで、プロキシはインフラストラクチャレイヤでユーザー委任トークンをアウトバウンドリクエストに自動的に挿入できます。エージェントが機密性の高い認証情報を直接保持することはないため、侵害されたエージェントがトークンを不正使用したり漏洩させたりするリスクは完全に排除され、アクションはユーザーの実際の権限に厳密にバインドされたままになります。

ケーススタディ: エージェントを特定の GitHub MCP ツールに制限するGitHub の問題をトリアージするエージェントを考えてみましょう。

GitHub MCP サーバーは数十のツールを公開している可能性がありますが、エージェントに必要なのは、list_issues、get_issue、get_issue_comments など、ごく一部の読み取り専用のツールのみである場合があります。ほとんどの企業にとって、この違いは重要です。有用なエージェントが、無制限のエージェントに自動的に変わるべきではありません。

MCP サーバーの前に Envoy を配置することで、ゲートウェイは mTLS handshake 中に SPIFFE を使用してエージェントの ID を検証し、デフレーミングフィルタを介して MCP メッセージを解析し、リクエストされたメソッドとツール名を抽出して、その特定のエージェント ID に対して承認されたツール呼び出しのみを許可するポリシーを適用できます。RBAC は、MCP デフレーミングフィルタによって作成されたメタデータを使用して、MCP メッセージ内のメソッドとツール名をチェックします。

code_block: <ListValue: [StructValue([('code', 'envoy.filters.http.rbac:\r\n "@type": type.googleapis.com/envoy.extensions.filters.http.rbac.v3.RBACPerRoute\r\n rbac:\r\n rules:\r\n policies:\r\n github-issue-reader-policy:\r\n permissions:\r\n - and_rules:\r\n rules:\r\n - sourced_metadata:\r\n metadata_matcher:\r\n filter: envoy.http.filters.mcp\r\n path: [{ key: "method" }]\r\n value: { string_match: { exact: "tools/call" } }\r\n - sourced_metadata:\r\n metadata_matcher:\r\n filter: envoy.http.filters.mcp\r\n path: [{ key: "params" }, { key: "name" }]\r\n value:\r\n or_match:\r\n value_matchers:\r\n - string_match: { exact: "list_issues" }\r\n - string_match: { exact: "get_issue" }\r\n - string_match: { exact: "get_issue_comments" }\r\n principals:\r\n - authenticated:\r\n principal_name:\r\n exact: "spiffe://cluster.local/ns/github-agents/sa/issue-triage-agent"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f39d07d2640>)])]>

この真の価値は、ポリシーがトラフィックに近い場所で、一元的に、エージェントの実際の動作に合った条件で適用されるという点です。

静的ルールの枠を超えて: 外部認証

RBAC ルールを使用して表現できない複雑なコンプライアンスポリシーは、ext_authz プロトコルを使用して外部認証サービスに実装できます。Envoy は、ext_authz RPC のコンテキストで、HTTP ヘッダーとともに MCP メッセージ属性を提供します。また、ピア証明書からエージェントの SPIFFE ID を転送することもできます。

code_block: <ListValue: [StructValue([('code', 'http_filters:\r\n - name: envoy.filters.http.ext_authz\r\n typed_config:\r\n "@type": type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthz\r\n grpc_service:\r\n envoy_grpc:\r\n cluster_name: auth_service_cluster\r\n include_peer_certificate: true\r\n metadata_context_namespaces:\r\n - envoy.http.filters.mcp'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f39d3343e20>)])]>

これにより、エージェントや MCP サーバーがポリシーレイヤを認識する必要なく、エージェント ID、MCP メソッド、ツール名、その他のプロトコル属性の完全な組み合わせに基づいて、外部サービスが認証の決定を行うことができます。

プロトコルネイティブのエラーレスポンス

Envoy がリクエストを拒否した場合、返されるエラーは呼び出し元のエージェントにとって意味のあるものである必要があります。MCP トラフィックの場合、Envoy は local_reply_config を使用して、HTTP エラーコードを適切な JSON-RPC エラーレスポンスにマッピングできます。たとえば、403 Forbidden は、isError: true および人間が読めるメッセージを含む JSON-RPC レスポンスにマッピングできます。これにより、エージェントは不透明な HTTP ステータスコードではなく、プロトコルに適した拒否を受け取ることができます。

3. Envoy はステートフルなエージェントのインタラクションを大規模にサポートする

エージェントトラフィックのすべてがステートレスであるわけではありません。MCP の Streamable HTTP など、一部のプロトコルはセッション指向の動作に依存する場合があります。特に、トラフィックが複数のゲートウェイインスタンスを通過してスケーラビリティと復元力を実現する場合、仲介役にとって新たな課題が生じます。MCP セッションは、そのセッションを確立したサーバーにエージェントを効果的にバインドします。すべての仲介役は、受信 MCP 接続を正しいサーバーに転送するために、このことを認識する必要があります。

1 つのバックエンドでセッションが確立された場合、その会話における後のリクエストは正しい宛先に到達する必要があります。単一プロキシのデプロイでは簡単そうに聞こえますが、水平方向にスケールされたシステムでは、複数の Envoy インスタンスが同じエージェントからの異なるリクエストを処理する場合があり、より複雑になります。

パススルーゲートウェイ

よりシンプルなパススルーモードでは、Envoy はダウンストリーム接続ごとに 1 つのアップストリーム接続を確立します。主な用途は、外部 MCP サーバーに対するクライアントの認可、RBAC、レート制限、認証など、一元化されたポリシーの適用です。仲介役の間で転送されるセッション状態には、最初の HTTP 接続でセッションを確立したサーバーのアドレスのみが含まれる必要があります。これにより、セッション関連のすべてのリクエストがそのサーバーに送信されます。

異なる Envoy インスタンス間でのセッション状態の転送は、MCP サーバーから提供された MCP セッション ID に、エンコードされたセッション状態を追加することで実現されます。Envoy は、リクエストを宛先 MCP サーバーに転送する前に、セッション ID からセッション状態の接尾辞を削除します。このセッションの永続性は、Envoy の envoy.http.stateful_session.envelope 拡張機能を構成することで有効になります。

集約ゲートウェイ

集約モードでは、Envoy は複数のバックエンド MCP サーバーの機能、ツール、リソースを集約することで、単一の MCP サーバーとして機能します。これにより、ポリシーが適用されるだけでなく、エージェントの構成が簡素化され、複数の MCP サーバーのポリシー適用が統合されます。

このモードでのセッション管理はより複雑になります。セッション状態に、ツールとリソースから、それらをアドバタイズしたサーバーアドレスとセッション ID へのマッピングも含まれる必要があるためです。Envoy がエージェントに提供するセッション ID は、ツールやリソースが認識される前に作成され、マッピングはその後、Envoy とバックエンド MCP サーバー間の MCP 初期化フェーズが完了した後に確立される必要があります。

現在 Envoy で実装されているアプローチの一つは、ツールやリソースの名前と、その配信元サーバーの識別子およびセッション ID を組み合わせるというものです。通常、正確なツール名やリソース名はエージェントにとって意味がなく、この追加の来歴情報を伝えることができます。変更されていないツール名やリソース名が必要な場合は、マッピングのない Envoy インスタンスを使用し、特定のツールを呼び出す前に tools/list コマンドを発行してマッピングを再作成するというアプローチもあります。このアプローチは、レイテンシと引き換えに、MCP セッションの外部グローバルストアをデプロイする複雑さが伴います。現在、ユーザーからのフィードバックに基づいて計画中です。

これは、Envoy が単純なトラフィック転送にとどまらないことを意味するため重要です。これにより、Envoy は、実際のエージェントワークフロー（複数のリクエスト、ツール、バックエンドにわたるものを含む）の信頼できる仲介役として機能できます。

4. Envoy はエージェントの検出をサポートする

Envoy は、既知の AgentCard エンドポイントを介した A2A プロトコルとエージェントの検出のサポートを追加しています。エージェント機能が記載された JSON ドキュメントである AgentCard は、スキル、認証要件、サービスエンドポイントをアドバタイズすることで、検出とマルチエージェントの調整を可能にします。AgentCard は、直接レスポンス構成を介して静的にプロビジョニングすることも、xDS API または ext_proc API を介して一元化されたエージェントレジストリサーバーから取得することもできます。A2A の実装とエージェントの検出の詳細は、今後のブログ投稿で公開する予定です。

5. Envoy はエージェントネットワーキングの課題に対する包括的なソリューション

Envoy は、要求の厳しいデプロイで MCP プロトコルのポリシー適用が可能になった基盤と同じ基盤を基に、OpenAI と、エージェントプロトコルの RESTful HTTP API へのコード変換のサポートを追加しています。このコード変換機能により、生成 AI エージェントと既存の RESTful アプリケーションの統合が簡素化されます。また、OpenAPI ベースのアプリケーションがすぐにサポートされ、動的モジュールまたは Wasm 拡張機能を通じてカスタムオプションを利用できます。Envoy は、コード変換に加えて、割り当て管理などの高度なポリシー適用、生成 AI システムの OpenTelemetry セマンティック規則に準拠した包括的なテレメトリー、安全なエージェント運用を実現する統合ガードレールなど、本番環境への対応に不可欠な領域で強化されています。

安全なエージェントのためのガードレール

投資対象となる次の重要な分野は、すべてのエージェントトラフィックのガードレールの一元管理と適用です。現在、ポリシー適用ポイントを外部のガードレールと統合するには、特注の実装が必要ですが、この問題領域は標準化の機が熟しています。

コントロールプレーンがこれを運用可能にする

ゲートウェイは、ソリューション全体の一部にすぎません。このポリシー管理とロールアウトを大規模に実現するにあたり、xDS プロトコル（ユニバーサルデータプレーン API とも呼ばれる）を使用してデータプレーンを動的に構成するために別のコントロールプレーンが必要になります。

そこで重要になるのがコントロールプレーンです。Cloud Service Mesh は、Envoy AI Gateway や kube-agentic-networking などのオープンソースプロジェクトとともに、Envoy をデータプレーンとして使用しながら、オペレーターがエージェントワークロードのポリシーをより高いレベルで定義、管理できるようにします。

この組み合わせは強力です。Envoy はトラフィックパスに適用機能と拡張性を提供し、コントロールプレーンはチームがその機能を一貫してデプロイするために必要な運用モデルを提供します。

このソリューションが重要な理由

エージェントシステムや生成 AI プロトコル（MCP、A2A、OpenAI など）への移行に伴い、ネットワーク仲介役の進化が求められています。Envoy が主に対応する複雑な課題は次のとおりです。

プロトコルの詳細な検査。プロトコルデフレーミング拡張機能は、HTTP リクエストの本文からポリシーに関連する属性（ツール名、モデル名、リソースパス）を抽出し、従来のプロキシでは不透明なバイトストリームしか確認できなかった状況で正確なポリシー適用を可能にします。
きめ細かいポリシーの適用。これらの内部属性を公開することで、RBAC や ext_authz などの既存の Envoy 拡張機能は、プロトコル固有の基準に基づいてポリシーを評価できます。これにより、ネットワークオペレーターは、統一されたゼロトラストのセキュリティポスチャーを適用し、エージェントが特定のツールやリソースのアクセスポリシーに準拠するようにできます。
ステートフルなトランスポート管理。Envoy は、MCP で使用される Streamable HTTP トランスポートのセッション状態の管理をサポートしており、仲介役のフリート全体でも、パススルーゲートウェイモードと集約ゲートウェイモードの両方で堅牢なデプロイを可能にします。

エージェント型 AI プロトコルはまだ初期段階にあり、プロトコルの状況は今後も進化し続けます。まさにそのために、ネットワーキングレイヤには適応性が必要なのです。新しいエージェントフレームワーク、トランスポートパターン、ツールプロトコルが普及するたびに、企業がセキュリティとトラフィックのインフラストラクチャを再構築する必要はありません。制御を犠牲にすることなく変化を吸収できる基盤が必要です。

Envoy は、本番環境での実証済みの成熟度、高度な拡張性、エージェントワークロードのプロトコル認識の向上という、一度に持ち合わせることが難しい 3 つの特性を兼ね備えています。Envoy をエージェントゲートウェイとして活用することで、組織はセキュリティとポリシーの適用をエージェント開発コードから切り離すことができます。

これにより、Envoy は AI トラフィックを処理するプロキシ以上の存在になり、エージェント型 AI ネットワーキングの未来を見据えた基盤となります。

^{このブログ記事の共同執筆者である、Google のソフトウェアエンジニア Boteng Yao、Google のソフトウェアエンジニア Tianyu Xia、Google のシニアプロダクトマネージャー Sisira Narayana に感謝します。}

- Google、スタッフソフトウェアエンジニア、Yan Avlasov

- Tetrate、プロダクトおよびプロダクトマーケティングマネージャー、Erica Hughberg 氏

Google ADK、MCP、Cloud Run を使用して専門家向けコンテンツ用のマルチエージェントシステムを構築する - パート 1

Thu, 09 Apr 2026 01:00:00 +0000

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

私のチームのミッションは、コードの作成から Google Cloud で安全な AI ワークロードを実行するまで、デベロッパーの取り組みを加速させることです。デベロッパーの成功を支援するため、Google はデベロッパーが最も切実に求めている質問を特定し、簡単に実装できるわかりやすいソリューションを提供するデモを構築することに重点を置いています。

最近、新しい Developer Knowledge MCP サーバーがリリースされたとき、私にはひらめきが湧きました。そこで、Google Agent Development Kit（ADK）を使用して設計されたマルチエージェントシステムである Dev Signal を構築し、Reddit から技術的な質問を特定し、公式ドキュメントを使用して調査し、詳細な技術ブログ記事の下書きを作成しました。Dev Signal には、Nano Banana Pro を使用したカスタムビジュアルも備わっています。エージェントが私の好みのスタイルやブログ記事の書き方を記憶できるように、長期記憶レイヤも統合しました。

コーディングアシスタントである Gemini CLI をデベロッパーナレッジ MCP サーバーに接続することで、このシステム全体をわずか 2 日で構築して Google Cloud Run にデプロイしました。

ここでは、長期記憶を備えた複雑なマルチエージェントシステムを設計する方法、ローカルおよびリモートの MCP サーバーを利用してツールを標準化する方法、安全な Cloud Run デプロイのための詳細な Terraform スクリプトを作成する方法など、さまざまな方法をご紹介します。

今すぐコードを見てご自分のペースで調べる場合は、こちらからリポジトリをクローニングできます。

学習内容

4 回に分けてお届けするこのブログシリーズでは、このプロジェクトをどのように実現したのか、その手順を段階的にご紹介します。各ブログ投稿では、Dev Signal の構築とデプロイの過程を説明します。

パート 1: エージェント機能を構築するためのツール – まず、プロジェクト環境をセットアップし、Model Context Protocol（MCP）を使用してエージェントにツールを装備します。トレンドの発見に Reddit を、技術的なグラウンディングに Google Cloud ドキュメントを、画像生成にカスタム Nano Banana Pro ツールを使用する方法を学びます。
パート 2: 長期記憶を備えたマルチエージェントアーキテクチャ – ルートオーケストレーターと専門エージェントチームを実装して、システムの「頭脳」を構築します。また、Vertex AI Memory Bank を統合することで、エージェントがセッション全体でユーザーの好みを学習して保持できるようになります。
パート 3: エージェントをローカルでテストする – クラウドに移行する前に、エージェントのコンポーネントを同期し、ワークステーションでエージェントのパフォーマンスを検証します。専用のテストランナーを使用して、検出、調査、マルチモーダル作成のライフサイクル全体をシミュレートします。特に、ローカルエージェントをクラウドベースの Vertex AI Memory Bank に直接接続して、長期記憶の永続性を検証することに重点を置きます。
パート 4: Cloud Run へのデプロイと本番環境への移行 – 最後に、再現可能なインフラストラクチャを実現するため、Terraform を使用して Google Cloud Run にサービスをデプロイします。また、高品質で安全な本番環境システムに必要な次のステップについても説明します。

Dev Signal の概要

Dev Signal は、ノイズをフィルタして価値を生み出すように設計されたインテリジェントなモニタリングエージェントです。Dev Signal は次のように動作します。

発見: Reddit を調査して、エンゲージメントの高い技術的な質問を見つけます。
グラウンディング: 正確性を確保するために、Google Cloud の公式ドキュメントを使用して回答を調査します。
作成: 調査結果に基づいて、プロフェッショナルな技術ブログ投稿の下書きを作成します。
マルチモーダル生成: これらの投稿のカスタムインフォグラフィックヘッダーを生成します。
長期記憶: Vertex AI Memory Bank を使用して、さまざまなセッションにわたってフィードバックを記憶します。

前提条件

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

Python 3.12 以降

uv（Python パッケージ管理システム）: curl -LsSf https://astral.sh/uv/install.sh | sh
Google Cloud SDK（gcloud CLI）（インストールおよび認証済み）
Terraform（Iinfrastructure as Code 用）
Node.js と npm（Reddit MCP ツールに必要）

次も必要です。

課金を有効にした Google Cloud プロジェクト。
有効な API: Vertex AI、Cloud Run、Secret Manager、Artifact Registry。
Reddit API 認証情報（クライアント ID、シークレット）- Reddit デベロッパーポータルから入手できます。
Developer Knowledge API Key（Google Cloud ドキュメント検索用）- 入手方法については、こちらをご覧ください。

プロジェクトのセットアップ

Dev Signal システムは、Remigiusz Samborski 氏と Vlad Kolesnikov 氏による Agent Factory のエピソードで説明されている自動化されたアーキテクトワークフローに従って、まず Agent Starter Pack を実行して構築されました。この基盤により、エージェントロジック、サーバーコード、ユーティリティ、ツール間の関心を分離するために使用される、プロジェクトのモジュール式ディレクトリ構造が用意されました。

Starter Pack は、プロフェッショナルなインフラストラクチャ、CI / CD パイプライン、オブザーバビリティツールの作成を数秒で自動化するため、強力な出発点となります。これにより、基盤となるプラットフォームのセキュリティとスケーラビリティを確保しながら、エージェント独自のインテリジェンスに十分集中できるようになります。Gemini CLI と Antigravity の AI アシスタンスを使用して、生成されたボイラープレートを基に構築することで、開発プロセスが大幅に加速されます。

Agent Starter Pack のアーキテクチャの概要:

1. プロジェクトを初期化する

プロジェクト用の新しいディレクトリを作成し、初期化します。ここでは、非常に高速な Python パッケージ管理システムである uv を使用します。

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

2. フォルダ構造

このプロジェクトは次の構造に従います。これらのファイルにデータを段階的に入力していきます。

code_block: <ListValue: [StructValue([('code', 'dev-signal/\r\n├── dev_signal_agent/\r\n│ ├── __init__.py\r\n│ ├── agent.py # Agent logic & orchestration\r\n│ ├── fast_api_app.py # Application server & memory connection\r\n│ ├── app_utils/ # Env Config\r\n│ │ └── env.py\r\n│ └── tools/ # External capabilities\r\n│ ├── __init__.py\r\n│ ├── mcp_config.py # Tool configuration (Reddit, Docs)\r\n│ └── nano_banana_mcp/# Custom local image generation tool\r\n│ ├── __init__.py\r\n│ ├── main.py\r\n│ ├── nano_banana_pro.py\r\n│ ├── media_models.py\r\n│ ├── storage_utils.py\r\n│ └── requirements.txt\r\n├── deployment/\r\n│ └── terraform/ # Infrastructure as Code\r\n├── .env # Local secrets (API keys)\r\n├── Makefile # Shortcuts for building/deploying\r\n├── Dockerfile # Container definition\r\n└── pyproject.toml # Dependencies'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f39cf922430>)])]>

3. 依存関係を定義する

必要な依存関係を使用して pyproject.toml を更新します。エージェントフレームワークには google-adk を、モデルのインタラクションには google-genai を使用します。

code_block: <ListValue: [StructValue([('code', '[project]\r\nname = "dev-signal"\r\nversion = "0.1.0"\r\ndescription = "A multi-agent system for monitoring and content creation."\r\nreadme = "README.md"\r\nrequires-python = ">=3.12, <3.14"\r\ndependencies = [\r\n "google-adk>=0.1.0",\r\n \xa0"google-genai>=1.0.0",\r\n "mcp>=1.0.0",\r\n \xa0"python-dotenv>=1.0.0",\r\n "fastapi>=0.110.0",\r\n "uvicorn>=0.29.0",\r\n "google-cloud-logging>=3.0.0",\r\n "google-cloud-aiplatform>=1.38.0",\r\n \xa0"fastmcp>=2.13.0",\r\n "google-cloud-storage>=3.6.0",\r\n "google-auth>=2.0.0",\r\n "google-cloud-secret-manager>=2.26.0",\r\n]'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f39cf922af0>)])]>

uv sync を実行してすべてインストールします。

エージェントコード用の新しいディレクトリを作成します。

code_block: <ListValue: [StructValue([('code', 'mkdir dev_signal_agent\r\ncd dev_signal_agent'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f39cf922340>)])]>

エージェント機能の構築: MCP ツール

エージェントは外部とやり取りする必要があります。これを標準化するために、Model Context Protocol（MCP）を使用します。Model Context Protocol（MCP）は、AI エージェントを外部のデータやツールに接続するための普遍的な基準です。カスタム API ラッパーを記述する代わりに、標準の MCP サーバーを使用します。これにより、共通のインターフェースを使用して、API（Reddit）、ナレッジベース（Google Cloud ドキュメント）、さらにはローカルスクリプト（Nano Banana Pro を使用した画像生成）にも接続できます。エージェントツール用の新しいディレクトリを作成します。

code_block: <ListValue: [StructValue([('code', 'mkdir tools\r\ncd tools'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f39cf922cd0>)])]>

ツールの構成

ツールセットは dev_signal_agent/tools/mcp_config.py で定義します。

このファイルでは、3 つの主要なツールの接続パラメータを定義します。

Reddit: ローカル stdio サブプロセス経由で接続されます。
デベロッパーナレッジ: リモート HTTP エンドポイント経由で接続されます。
Nano Banana: ローカル stdio サブプロセス（Google のカスタム Python スクリプト）経由で接続されます。

Reddit 検索（発見ツール）

Reddit MCP サーバーは Reddit API へのブリッジとして機能し、複雑な API ラッパーを記述しなくても、トレンドとなっている投稿をエージェントが発見してエンゲージメントを分析できるようにします。移植性を確保するために、コードでは「検索またはフェッチ」戦略が使用されています。まずローカルインストールをチェックし、見つからない場合は npx を使用してサーバーをオンデマンドでダウンロードして実行します。

ネットワーク接続の代わりに、エージェントはサーバーをローカルサブプロセスとして起動し、標準入出力（stdio）を介して通信します。Google ADK 内の McpToolset クラスは、これらの接続を標準化する普遍的なラッパーとして機能し、エージェントが共通のインターフェースを使用して、コミュニティリソースからカスタムスクリプト（Nano Banana 画像生成ツールなど）まで、さまざまなツールとやり取りできるようにします。環境変数を介して API 認証情報を安全に渡すことで、システムはこれらの「プラグアンドプレイ」モジュールが AI と外部プラットフォーム間のシームレスなブリッジとして機能することを保証します。

次のコードを dev_signal_agent/tools/mcp_config.py に貼り付けます。

code_block: <ListValue: [StructValue([('code', 'import os\r\nimport shutil\r\nfrom mcp import StdioServerParameters\r\nfrom google.adk.tools import McpToolset\r\nfrom google.adk.tools.mcp_tool import StreamableHTTPConnectionParams, StdioConnectionParams\r\n\r\ndef get_reddit_mcp_toolset(client_id: str = "", client_secret: str = "", user_agent: str = ""):\r\n """\r\n Connects to the Reddit MCP server.\r\n This server runs as a local subprocess (stdio) and proxies requests to the Reddit API.\r\n """\r\n # Check if \'reddit-mcp\' is installed globally, otherwise use npx to run it\r\n cmd = "reddit-mcp" if shutil.which("reddit-mcp") else "npx"\r\n args = [] if shutil.which("reddit-mcp") else ["-y", "--quiet", "reddit-mcp"]\r\n \r\n # Inject secrets into the environment of the subprocess only\r\n env = {\r\n **os.environ, \r\n "DOTENV_CONFIG_SILENT": "true", \r\n "LANG": "en_US.UTF-8"\r\n }\r\n\r\n if client_id: env["REDDIT_CLIENT_ID"] = client_id\r\n if client_secret: env["REDDIT_CLIENT_SECRET"] = client_secret\r\n if user_agent: env["REDDIT_USER_AGENT"] = user_agent\r\n\r\n return McpToolset(\r\n connection_params=StdioConnectionParams(\r\n server_params=StdioServerParameters(\r\n command=cmd, \r\n args=args, \r\n env=env # Pass injected secrets directly to the subprocess\r\n ),\r\n timeout=120.0\r\n )\r\n )'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f39bd7de760>)])]>

Google Cloud ドキュメント（ナレッジツール）

Developer Knowledge MCP サーバーは、エージェントが Google Cloud の公式ドキュメントのコーパス全体を検索できるようにすることで、エージェントのグラウンディングを提供します。これは、ローカルの Reddit サーバーとは異なり、Google がホストするマネージドサービスであり、インターネット経由でリモートエンドポイントとしてアクセスされます。セマンティッククエリ用の google_developer_documentation_search や、完全なマークダウンコンテンツを取得するための google_developer_documentation_fetch などの特殊なツールが公開されており、エージェントが技術的な主張を行うたびに、最新の確かな事実によって裏付けられるようになっています。

注: Gemini CLI や Antigravity などのコーディングアシスタントツールをデベロッパーナレッジ MCP サーバーに接続して、最新の便利な Google Cloud ドキュメントをアシスタントに提供することもできます。このブログ記事を書くときも使っています。

接続するために、エージェントは McpToolset クラスと StreamableHTTPConnectionParams を使用し、ローカルプロセスを起動する代わりにウェブ URL を指定します。リクエストヘッダーで渡される DK_API_KEY（API キーを作成）を使用して安全に認証し、エージェントが単一の標準化されたインターフェースを通じて、公式ドキュメント、コミュニティの感情、より広範なウェブコンテキスト全体で「包括的な調査スイープ」を実行できるようにします。

次のコードを dev_signal_agent/tools/mcp_config.py に貼り付けます。

code_block: <ListValue: [StructValue([('code', 'def get_dk_mcp_toolset(api_key: str = ""):\r\n """\r\n Connects to Developer Knowledge (Google Cloud Docs).\r\n This is a remote MCP server accessed via HTTP.\r\n """\r\n headers = {}\r\n if api_key:\r\n headers["X-Goog-Api-Key"] = api_key\r\n else:\r\n # Fallback to os.environ for local testing if not passed via API\r\n headers["X-Goog-Api-Key"] = os.getenv("DK_API_KEY", "")\r\n\r\n return McpToolset(\r\n connection_params=StreamableHTTPConnectionParams(\r\n url="https://developerknowledge.googleapis.com/mcp",\r\n headers=headers\r\n )\r\n )'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f39bd7dee80>)])]>

画像生成ツール（Nano Banana MCP）

Reddit とドキュメントには外部 MCP サーバーを使用しましたが、特定の Python ロジックをラップする独自のカスタム MCP サーバーを構築することもできます。この例では、Gemini 3 Pro Image（Nano Banana Pro とも呼ばれます）を搭載した画像生成ツールを作成します。これは、任意の Python 関数を、任意のエージェントが理解できるツールに標準化できることを示しています。

画像生成の仕組み:

FastMCP: fastmcp ライブラリを使用してサーバーの作成を大幅に簡素化し、数行のコードで Python 関数をツールとして登録できるようにします。
Gemini のインテグレーション: サーバーは Google GenAI SDK を使用して gemini-3-pro-image-preview モデルを呼び出し、エージェントの説明的なプロンプトを未加工の画像バイトに変換します。
GCS へのアップロードとホスティング: エージェントインターフェースでは通常、画像を表示するために URL が必要となるため、サーバーは生成されたバイトを Google Cloud Storage（GCS）に自動的にアップロードし、公開リンクを返します。

このローカルツールを接続するには、StdioConnectionParams を使用します。これは、サーバーが標準入出力を介して通信するローカルサブプロセスとして実行されるためです。この転送方法は、サーバーのエントリポイントで定義する transport="stdio" 構成に直接一致し、カスタムのローカルスクリプトのシームレスな接続を保証します。

次のコードは、dev_signal_agent/tools/mcp_config.py で MCP 接続を定義します。uv run を使用して、すべての依存関係が正しくインストールされている、隔離された環境でサーバーが起動するようにします。

次のコードを dev_signal_agent/tools/mcp_config.py に貼り付けます。

code_block: <ListValue: [StructValue([('code', 'def get_nano_banana_mcp_toolset():\r\n """\r\n Connects to our local \'Nano Banana\' image generator.\r\n This demonstrates how to wrap a local Python script as an MCP tool.\r\n """\r\n path = os.path.join("dev_signal_agent", "tools", "nano_banana_mcp", "main.py")\r\n bucket = os.getenv("AI_ASSETS_BUCKET") \r\n return McpToolset(\r\n connection_params=StdioConnectionParams(\r\n server_params=StdioServerParameters(\r\n command="uv", \r\n args=["run", path], \r\n env={**os.environ, "AI_ASSETS_BUCKET": bucket}\r\n ),\r\n timeout=600.0 # Image generation can take time\r\n )\r\n )'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f39bd7ded60>)])]>

Nano Banana Pro サーバーロジックの実装

次に、このサーバーの実際のロジックを実装します。この実装は、Remigiusz Samborski 氏による Agent Factory デモのコードに基づいています。Remi の元のコードには、MCP サーバーを Cloud Run にデプロイする手順が記載されていますが、ここでは開発とテストを迅速に行うために、ローカルサブプロセスとして実行します。

まず、新しいサーバー用のディレクトリを作成します。

code_block: <ListValue: [StructValue([('code', 'mkdir -p dev_signal_agent/tools/nano_banana_mcp\r\ncd dev_signal_agent/tools/nano_banana_mcp'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f39bd7de7f0>)])]>

サーバーエントリポイント（`main.py`）

このファイルは、MCP サーバーを初期化して起動する「頭脳」として機能します。

FastMCP の初期化: FastMCP ライブラリを使用して、「MediaGenerators」という名前のサーバーを作成し、generate_image 関数をツールとして登録します。
安全なロギング: _initialize_console_logging 関数が重要な役割を果たします。この関数はすべてのログを sys.stderr に強制的に出力します。これは、MCP の「stdio」転送がエージェントとツールの間の通信に sys.stdout を使用するためです。stdout に送信される標準ログは、そのプロトコルを破損させます。
実行: mcp.run(transport="stdio") 行は、サーバーをローカルサブプロセスとして起動し、標準入力経由でエージェントからのリクエストをリッスンできるようにします。

次のコードを dev_signal_agent/tools/nano_banana_mcp/main.py に貼り付けます。

code_block: <ListValue: [StructValue([('code', 'import logging\r\nimport os\r\nimport sys\r\nfrom fastmcp import FastMCP\r\nfrom dotenv import load_dotenv\r\nfrom nano_banana_pro import generate_image\r\n\r\ndef _initialize_console_logging(min_level: int = logging.INFO):\r\n # Ensure logs go to STDERR so they don\'t break the MCP stdio protocol\r\n handler = logging.StreamHandler(sys.stderr)\r\n logging.basicConfig(level=min_level, handlers=[handler], force=True)\r\n\r\ntools = [generate_image]\r\nmcp = FastMCP(name="MediaGenerators", tools=tools)\r\n\r\nif __name__ == "__main__":\r\n load_dotenv()\r\n _initialize_console_logging()\r\n mcp.run(transport="stdio")'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f39bd7de070>)])]>

生成ロジック（`nano_banana_pro.py）`

ここでは、Gemini を使用して実際に画像が生成されます。

GenAI クライアント: Google の生成モデルとやり取りするために、genai.Client() を初期化します。
モデルの選択: 具体的には gemini-3-pro-image-preview モデルを対象とします。response_modalities を「IMAGE」に設定して、テキストだけでなくピクセルも必要であることをモデルに伝えます。
堅牢性: コードには、一時的な生成エラーを処理するための MAX_RETRIES ループ（5 に設定）が含まれており、エージェントが有効な画像を複数回取得できるようにしています。
バイト処理: モデルが画像を生成すると、未加工のインラインデータとして届きます。これらのバイトを抽出し、ヘルパーを呼び出してクラウドに移動します。
URI 変換: 最後に、内部の gs:// パスを、ブラウザからアクセス可能な https:// URL に置き換え、ユーザーが実際に画像を見られるようにします。

次のコードを dev_signal_agent/tools/nano_banana_mcp/nano_banana_pro.py に貼り付けます。

code_block: <ListValue: [StructValue([('code', 'import logging\r\nfrom typing import Literal, Optional\r\nfrom google import genai\r\nfrom google.genai import types\r\nfrom media_models import MediaAsset\r\nfrom storage_utils import upload_data_to_gcs\r\n\r\nAUTHORIZED_URI = "https://storage.mtls.cloud.google.com/"\r\nMAX_RETRIES = 5\r\n\r\nasync def generate_image(\r\n prompt: str,\r\n aspect_ratio: Literal["16:9", "9:16"] = "16:9",\r\n) -> MediaAsset:\r\n """Generates an image using Gemini 3 Image model."""\r\n genai_client = genai.Client()\r\n content = types.Content(parts=[types.Part.from_text(text=prompt)], role="user")\r\n \r\n logging.info(f"Starting image generation for prompt: {prompt[:50]}...")\r\n asset = MediaAsset(uri="")\r\n \r\n for _ in range(MAX_RETRIES):\r\n response = genai_client.models.generate_content(\r\n model="gemini-3-pro-image-preview",\r\n contents=[content],\r\n config=types.GenerateContentConfig(\r\n response_modalities=["IMAGE"],\r\n image_config=types.ImageConfig(aspect_ratio=aspect_ratio)\r\n )\r\n )\r\n if response and response.parts:\r\n for part in response.parts:\r\n if part.inline_data and part.inline_data.data:\r\n # Upload the raw bytes to GCS\r\n gcs_uri = await upload_data_to_gcs(\r\n "mcp-tools",\r\n part.inline_data.data,\r\n part.inline_data.mime_type\r\n )\r\n asset = MediaAsset(uri=gcs_uri)\r\n break\r\n if asset.uri: break\r\n\r\n if not asset.uri:\r\n asset.error = "No image was generated."\r\n else:\r\n # Convert gs:// URI to an HTTP accessible URL if needed\r\n asset.uri = asset.uri.replace(\'gs://\', AUTHORIZED_URI)\r\n logging.info(f"Image URL: {asset.uri}")\r\n \r\n return asset'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f39bd7de940>)])]>

GCS アップロードヘルパー（`storage_utils.py）`

エージェントは画像を表示するためにリンクを必要とするため、このユーティリティは Google Cloud Storage（GCS）でホスティングを処理します。

バケットの動的な選択: 環境変数でバケット名を探し、AI_ASSETS_BUCKET から LOGS_BUCKET_NAME にフォールバックして、データの保存場所が常に確保されるようにします。
一意のファイル名: 未加工の画像データの MD5 ハッシュを使用して、一意のファイル名を作成します。これにより、ファイル名の競合を防ぐことができ、同じ画像の重複アップロードを回避する簡単な方法として機能します。
クラウドアップロード: blob.upload_from_string メソッドは、未加工の画像バイトを GCS バケットに直接 push します。

次のコードを dev_signal_agent/tools/nano_banana_mcp/storage_utils.py に貼り付けます。

code_block: <ListValue: [StructValue([('code', 'import hashlib\r\nimport mimetypes\r\nimport os\r\nfrom google.cloud.storage import Client, Blob\r\nfrom dotenv import load_dotenv\r\n\r\nload_dotenv()\r\nstorage_client = Client()\r\nai_bucket_name = os.environ.get("AI_ASSETS_BUCKET") or os.environ.get("LOGS_BUCKET_NAME")\r\nai_bucket = storage_client.bucket(ai_bucket_name)\r\n\r\nasync def upload_data_to_gcs(agent_id: str, data: bytes, mime_type: str) -> str:\r\n file_name = hashlib.md5(data).hexdigest()\r\n ext = mimetypes.guess_extension(mime_type) or ""\r\n blob_name = f"assets/{agent_id}/{file_name}{ext}"\r\n blob = Blob(bucket=ai_bucket, name=blob_name)\r\n blob.upload_from_string(data, content_type=mime_type, client=storage_client)\r\n return f"gs://{ai_bucket_name}/{blob_name}"'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f39bd7de3a0>)])]>

データモデル（`media_models.py`）

このファイルにより、データが厳格な構造（スキーマ）に従うことが保証されます。

構造化された出力: Pydantic BaseModel を使用することで、ツールが常に uri（リンク）とオプションの error メッセージを含む一貫した JSON オブジェクトを返すことを保証します。これにより、AI エージェントがツールの結果を理解して処理することがはるかに容易になります。

次のコードを dev_signal_agent/tools/nano_banana_mcp/media_models.py に貼り付けます。

code_block: <ListValue: [StructValue([('code', 'from typing import Optional\r\nfrom pydantic import BaseModel\r\n\r\nclass MediaAsset(BaseModel):\r\n uri: str\r\n error: Optional[str] = None'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f39bd7dea00>)])]>

ツールの依存関係（`requirements.txt）`

コードの実行には uv を使用しますが、requirements.txt ファイルは、Nano Banana サーバーが機能するために uv がインストールする必要がある特定の依存関係を定義するため、依然として不可欠です。これにより、隔離された環境をサーバーの起動前にセットアップするために必要な「材料」が提供されます。

このファイルには、このツールに必要な 3 つのコアライブラリがリストされています。

google-cloud-storage: 生成された画像をクラウドでホストするために使用されます。
google-genai: Gemini 3 Pro の画像生成のロジックを提供します。
fastmcp: Python スクリプトを標準化された MCP ツールに変えるフレームワークです。

次のコードを dev_signal_agent/tools/nano_banana_mcp/requirements.txt に貼り付けます。

code_block: <ListValue: [StructValue([('code', 'google-cloud-storage==3.6.*\r\ngoogle-genai==1.52.*\r\nfastmcp==2.13.*'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f39bd7de310>)])]>

まとめ

シリーズのパート 1 では、Model Context Protocol（MCP）を通じて外部統合を標準化することにより、エージェントのコア機能を確立することに焦点を当てました。高速な依存関係管理のために uv を使用してプロジェクトを初期化し、トレンド発見のための Reddit、技術的なグラウンディングのための Google Cloud ドキュメント、マルチモーダル画像生成のためのカスタム「Nano Banana」MCP サーバーという 3 つの重要なツールセットを構成しました。Google ADK の McpToolset を利用することで、複雑な API ロジックをシンプルなプラグアンドプレイモジュールに抽象化し、ツールが共通のインターフェースを共有してインテリジェンスから統合を切り離せるようにしました。

技術的基盤について詳しく確認するには、Developer Knowledge MCP サーバーでナレッジグラウンディングの詳細を確認するか、Google ADK GitHub リポジトリでフレームワークのコア機能について調べることができます。

ツールセットが完全に構成され、使用できる状態になったので、パート 2 に進みましょう。パート 2 では、マルチエージェントアーキテクチャを構築し、Vertex AI Memory Bank を統合してこれらの機能をオーケストレートします。さらに詳しく調べる場合は、GitHub リポジトリでシリーズ全体の詳細なコードを確認できます。

この記事に対して、レビューとフィードバックを提供してくださった Remigiusz Samborski 氏に心より感謝いたします。

このようなコンテンツをさらにご覧になりたい場合は、LinkedIn と X で私をフォローしてください。

- AI / プロダクト / DevRel 責任者、Shir Meir Lador

LLM 推論の効率的フロンティアに到達するための 5 つの手法

Wed, 08 Apr 2026 02:10:00 +0000

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

モデル推論に費やした費用の分だけ、レイテンシとスループットのグラフ上で良いポジションが得られます。上の図には、ハードウェアから可能な限り最大のパフォーマンスを引き出した、最適な構成の曲線が示されています。この曲線は、金融のポートフォリオ理論から借用したもので、効率的フロンティアと呼ばれます。

ハードウェアの予算が固定されていると仮定すると、レイテンシとスループットをトレードオフできます。ただし、フロンティア曲線自体が移動しない限り、一方を改善するには他方を犠牲にする必要があります。根本的に異なる 2 つのダイナミクスが作用しており、これは本番環境で LLM を実行するすべての人にとって重要なインサイトです。

最初のダイナミクスはフロンティアに到達することです。これには、現在利用可能なあらゆる手法を適用することが含まれます。この部分は、自分で制御できます。継続的なバッチ処理、アテンションの分割、インテリジェントルーティング、投機的デコーディング、量子化はすべて、現在存在する手法です。これらの手法を使用していない場合、運用がフロンティアを下回り、パフォーマンスを最大限に引き出すことができません。

2 つ目のダイナミクスは、フロンティア自体が常に外側に移動していることです。この部分は、ほとんどの場合、自分で制御できません。研究者は新しいアルゴリズムを発表し、ハードウェアベンダーは新しいアーキテクチャを出荷し、オープンソースプロジェクトは成熟します。ブレイクスルーが起こるたびに、物理的に達成可能なことが再定義され、曲線が拡大されるため、昨日の最適な構成が今日の非効率になります。

プラットフォームエンジニアの仕事は、フロンティアにできるだけ近い位置を維持しながら、新しい進歩がもたらされるたびにそれを吸収できる十分な柔軟性を持つインフラストラクチャを構築することです。この記事では、そのためのツールをご紹介します。

推論に効率的フロンティアがある理由

すべての LLM リクエストには 2 つの計算フェーズがあり、それぞれ異なるハードウェアリソースでボトルネックが発生する可能性があります。

1. プレフィル（コンピューティングバウンド）: このフェーズでは、GPU が入力プロンプト全体を一度に処理して、アテンション機構の Key-Value（KV）キャッシュを構築します。命令は並列でバッチ処理されるため、GPU のコンピューティングコア（テンソルコア）の使用率が高くなります。このフェーズは高速かつ効率的です。プロセッサは、大規模な行列乗算を実行するために必要なすべてのデータをすぐに利用できます。プロンプトが長くなると、単純に計算量が増えます。

2. デコード（メモリ帯域幅バウンド）: このフェーズでは、新しいトークンが一度に 1 つずつ自己回帰的に生成されます。1 つのトークンのみを生成する場合、GPU は作業をバッチ処理できません。モデル全体の重みと増大する KV キャッシュを高帯域幅メモリ（HBM）からコンピューティングコアにフェッチする必要があります。その後、GPU はその 1 つのトークンを計算し、次のトークンに対して再び同じ処理を行うのを待ちます。

この不一致こそが、フロンティアが存在する根本的な理由です。トレードオフなしに、単一のシステムを同時に両方のフェーズ向けに最適化することはできません。

推論の 2 つの軸

LLM 推論の効率的フロンティアでは、リスクとリターンの代わりに、ハードウェア予算が固定されているという前提で、別の基本的なトレードオフが測定されます。

軸	測定される主な指標	ハードウェアの制約
レイテンシ（X 軸）	最初のトークンまでの時間（TTFT）+ トークン間の時間（TBT）	コンピューティング（プレフィル）とメモリ帯域幅（デコード）
スループット（Y 軸）	すべての同時ユーザーの 1 秒あたりの合計トークン数	バッチサイズ × メモリ容量

費用は、レイテンシとスループットのグラフ自体を購入する制約です。ハードウェアの予算を増やすか、業界が画期的な新しいアルゴリズムを発明すると、フロンティア曲線全体が外側にシフトします。特定の予算とソフトウェアスタックで、最適ではない状態からそのフロンティアに向かって移行するための現在のベストプラクティスを適用できます。

フロンティアに到達する: 制御可能な 5 つの手法

現在、本番環境における大部分の推論システムの運用は、フロンティアを下回っています。優れた手法は存在するものの、そのような手法をまだ採用していないために、パフォーマンスが向上していないのです。このセクションで説明する手法はすべて、現在利用可能なものです。これらの手法を適用しない場合、運用が曲線を下回ることになります。

1. モデル階層間のセマンティックルーティング

すべてのクエリに 4,000 億パラメータのモデルが必要なわけではありません。単純な分類、要約、書式設定のタスクは、トークンあたりの費用が桁違いに安い、より小さな量子化モデルにルーティングできます。ゲートウェイエッジの軽量分類器がクエリの複雑さを分析し、それに応じてルーティングします。難しい推論にはフロンティアクラスのモデル、それ以外には小規模モデルを使用します。

セマンティックルーティングにより、システムは理論上の最大スループットに劇的に近づき、簡単なタスクでの無駄なサイクルが回避されます。集約された出力の品質が犠牲になることはありません。

2. プレフィルとデコードの分離

プレフィルフェーズとデコードフェーズを異なるハードウェアに物理的に分離することは、現在利用可能な、アーキテクチャ上最も重要な最適化の一つです。

プレフィルフェーズには、コンピューティング能力の高い GPU が必要です。デコードフェーズには、高帯域幅メモリが必要です。両方のフェーズを同じ GPU に強制的に割り当てると、一方のリソースが常に十分に活用されない状態になります。

両方のフェーズをそれぞれ理論上のハードウェア上限に近づけるには、専用のプレフィルクラスタとデコードクラスタを実行します。これらのクラスタを、圧縮された KV キャッシュの状態のみを同じ GPU に転送する高速ネットワークで接続すると、一方のリソースが常に十分に活用されない状態になります。

3. 量子化: 精度と速度のトレードオフ

モデルの重みを FP16 から INT8 または INT4 形式に減らすと、メモリ使用量を半分または 4 分の 1 に削減できます。デコードフェーズにはメモリ帯域幅の制限があるため、4 ビットの重みは 16 ビットの重みよりも最大 4 倍速く読み取ることができます。このアプローチにより、TBT が直接改善されます。

単純な量子化ではモデル出力の品質が低下するため、品質とのトレードオフが生じます。Activation-aware Weight Quantization（AWQ）や GPTQ などの最新の手法では、重要な重みの品質を維持しながら、他の重みを積極的に圧縮して、INT4 の速度で FP16 に近い品質を実現します。

4. コンテキストルーティング: ほとんどのチームが見落としている最大の要素

数十個のモデルレプリカを使用した本番環境でのデプロイでは、ルーティングレイヤが、現在最大の競争優位性を獲得できるかどうかの分かれ目となっています。

2026 年は、接頭辞のキャッシュ保存が基盤となっています。10 人のユーザーが 100 ページの RAG ドキュメントについてまったく同じ質問をしたり、同一の膨大なシステムプロンプトを使用したりする場合、コンピューティング負荷の高いプレフィルフェーズを 10 回実行すべきではありません。KV キャッシュを一度計算して保存し、他の 9 人のユーザーが再利用できるようにする必要があります。このアプローチにより、TTFT を最大 85% 短縮し、コンピューティング費用を大幅に削減できます。

ただし、注意点があります。標準の L4 ロードバランサはリクエストをランダムに分散します。ユーザー 2 のリクエストがユーザー 1 のリクエストとは異なる GPU に到達した場合、接頭辞のキャッシュは役に立たず、システムはキャッシュをゼロから再計算する必要があります。

コンテキスト認識型 L7 ルーティングが差別化要因となるのはこのためです。インテリジェントルーターは、受信したプロンプトの接頭辞を検査し、そのコンテキストをキャッシュにすでに保持している特定の Pod に意図的にリクエストをルーティングします。冗長な作業にコンピューティング能力を無駄に費やすことがなくなり、レイテンシとスループットをハードウェアの物理的な上限に即座に近づけることができます。

5. 投機的デコーディング

重要な点として、デコードフェーズでは、メモリ帯域幅にボトルネックがあるため、テンソルコアはほとんどアイドル状態です。投機的デコーディングは、この無駄な計算能力を利用します。

小規模で高速な「ドラフト」モデルが、複数の候補トークンを低コストで生成します。その後、大規模なターゲットモデルが、すべての候補を単一のフォワードパスで検証します。これは、シーケンシャルメモリバウンドのオペレーションではなく、並列コンピューティングバウンドのオペレーションです。ドラフトモデルが候補を正しく予測した場合、1 トークンのメモリコストで 4～5 トークンを生成したことになります。

このアプローチにより直接、メモリ帯域幅によって設定された TBT の下限よりも短い TBT を達成できます。レイテンシの影響を受けやすいワークロードに投機的デコーディングを使用していない場合、利用可能な最も効果的な最適化の一つを活用できていないことになります。

ドラフトモデルを追加すると、運用が多少複雑になり、コンピューティング費用がわずかに増加する可能性がありますが、ドラフトモデルはメインモデルに比べて比較的小さなものです。これとレイテンシをトレードオフする価値はあります。

なお、一部の新しいモデルでは自己投機的デコーディングが導入されており、2 つ目のモデルを管理するオーバーヘッドがなくなります。これらのモデルは、将来の追加トークンを同時に予測するようにトレーニングされた特殊な内部レイヤ（多くの場合、予測ヘッドと呼ばれる）を使用します。これらのモデルは一般に、非常に有意義なトークンヒット率を達成します。

ケーススタディ: Vertex AI がフロンティアに近づいた方法

Vertex AI エンジニアリングチームは、標準の Kubernetes Gateway API を基盤として構築された GKE Inference Gateway を採用したときに、フロンティアに近づきました。Inference Gateway はレイヤ 7 でリクエストをインターセプトし、2 つの重要なインテリジェンスレイヤを追加しました。

負荷認識ルーティング: モデルサーバーの Prometheus エンドポイントからリアルタイムの指標（KV キャッシュ使用率やキューの深さなど）を直接スクレイピングしました。このプロセスでは、リクエストを最も迅速に処理できる Pod にルーティングします。
コンテンツ認識ルーティング: リクエストの接頭辞を検査し、そのコンテキストを KV キャッシュにすでに保持している Pod にトラフィックをルーティングしました。このプロセスでは、コストのかかる再計算を回避できます。

本番環境のワークロードをこのインテリジェントなルーティングアーキテクチャに移行したところ、ネットワークレイヤの最適化が、大規模なパフォーマンス向上を実現する鍵であることが、Vertex AI チームによって証明されました。本番環境のトラフィックで検証した結果は、以下のとおりです。

Qwen3-Coder（コンテキストの多いコーディングエージェントワークロード）で TTFT が 35% 短縮
DeepSeek V3.1（バースト性の高いチャットワークロード）の P95 テールレイテンシが 2 分の 1（52%）に改善
接頭辞キャッシュヒット率が 2 倍（35% から 70% に最適化）

まとめ

LLM 推論には効率的フロンティアがあります。効率的フロンティアとは、特定のコンピューティング予算に対してレイテンシとスループットの最適なバランスが取れた絶対的な境界を表します。

効率的フロンティアに到達することは、自分で制御できます。現在、継続的なバッチ処理、アテンションの分割、インテリジェント L7 ルーティング、投機的デコーディング、量子化、プレフィルとデコードの分離といった手法が存在します。GKE Inference Gateway のケーススタディでは、ハードウェア、モデル、クラスタサイズを変更せずに、ルーティングのみで、TTFT が 35% 短縮され、キャッシュ効率が 2 倍になったことが示されています。フルスタックを適用しない場合、運用は曲線を下回り、トークンごとに過剰な料金を支払うことになります。

フロンティア自体が外側に移動し続けています。この部分は、自分で制御できません。研究者は新しいアルゴリズムを発表し、ハードウェアベンダーは新しいアーキテクチャを出荷し、オープンソースのサービングフレームワークはこれらのアルゴリズムとアーキテクチャを統合します。18 か月前には最先端の最適化だったものが、今では基本的な必須事項となっています。次にどのようなブレークスルーが起こるかを予測するのではなく、ブレークスルーが起こったときにそれを吸収できる柔軟なインフラストラクチャを構築することが、あなたの仕事です。

推論エコノミクスで成功する組織は、GPU を最も多く保有している組織ではなく、現在のフロンティアとのギャップを体系的に埋めながら、明日のフロンティアに備える組織です。

これらの最適化手法をご自身の LLM 推論ワークロードに適用したことがある方は、その体験談をぜひお聞かせください。構築したものを LinkedIn、X、Bluesky で共有していただければ幸いです。

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

AI リテラシーの新しい形: 学生デベロッパーを対象とした調査結果

Tue, 07 Apr 2026 01:00:00 +0000

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

AI により、学生デベロッパーはかつてないレベルで作業を効率化し、難しい問題を解決したり、野心的なプロジェクトに取り組んだりできるようになりました。一方、この新技術の登場によって、技術専攻の学生たちは学習について本質的な問いに向き合うようになってきています。

それは、AI をどの程度、何に使用すべきか、という問題です。

Google の DORA 2025 レポートによると、現在、日々の業務で AI を使用している技術者は 90% に達しています。こうした状況の中で、次世代が AI ツールとどう付き合っているのかを理解することがこれまでになく重要になっています。カリフォルニア大学バークレー校の学生を対象とした Google の調査では、学業における不正行為や知的作業の省略といった懸念を覆す結果が明らかになりました。学生は AI を近道としてではなく、学習パートナーとして捉え、タスクによって意図的に使用したり、使用を控えたりしています。

AI がソフトウェア開発の基盤となるにつれ、AI ツールを導入するかどうかよりも、懸命な活用方法が焦点になってきています。カリフォルニア大学バークレー校の学生たちは、その答えの一つを示してくれます。それは、彼らのもつ好奇心や、慎重さ、学習に対する純粋な意欲を、AI は支えることはできても、取って代わることはできない、ということです。

調査

カリフォルニア大学バークレー校の 4 人の学生チーム（Andrew Harlan、Mindy Tsai、Kenny Ly Hong、Karissa Wong）が、学業での AI の利用状況を把握するため、コンピュータサイエンス、電気工学、デザイン、データサイエンス専攻の学生を対象に調査を実施しました。この調査には、混合手法を使用しています。

また、同校の別のチーム（Edward Fraser、Jessie Deng、Eileen Thai）が、デベロッパー歴 1～5 年の人々を対象に、アイトラッキング技術を使って AI コーディングアシスタントの使用状況を観察しました。両チームとも専任メンターの支援のもと調査を進め、混合手法調査については Google 社員の Harini Sampath、Becky Sohn、Derek DeBellis が、アイトラッキング調査についてはカリフォルニア大学バークレー校の John Chuang 教授（博士）が助言を行っています。

これらの調査から、学生が AI を活用すると同時に、真の専門知識を身につけるためにどのような方法をとっているのか、3 つの重要な結果が明らかになりました。学生の間で見られるパターンは、実際に開発職に就いている人々を対象にした DORA の調査結果とよく似通っています。

調査結果その 1: 24 時間 365 日、いつでも頼れる先生

AI は近道ではなく家庭教師

調査で AI との関係性について尋ねられた学生は皆一様に、学びの場ならではの言葉を使いました。AI のことを、アシスタントや生産性向上ツールではなく、「家庭教師」や「先生」と呼んでいたのです。

「AI は教師のような存在です。内容の濃い資料を解説してもらったり、データベースにあらかじめ記述されているコードを部分的に説明してもらったりするなど、プロジェクトの基礎的な部分について理解を深めるためにとても役立っています。」

「[AI を] お抱えの家庭教師として利用しています。授業や講義の特定のトピックの [理解を深める] ために。コンピュータサイエンスだけでなく、あらゆる授業で使っています。」

ここで重要なのは、学生が AI に依存せず、計画的に使用しているということです。AI に課題を完成させるのではなく、自分の理解度を踏まえて AI を使用し、知識の抜けを特定したり、不確かな概念を明らかにしたり、学習プロセスをリードしてもらったりしています。回答の中には、講義で取り上げられた複数の学術論文を要約してもらい、どれを深く読みこむべきかを判断するといった使い方や、コードでエラーが発生する理由を AI に説明してもらう、といったものがありました。

ある学生は、学習プロセスに次のように組み込んでいます。

「教授の説明がわからなかったときは AI に尋ねます。たとえば、ある概念や、コードの機能について説明してもらったりします。また、ラボのどこから手をつけたらよいかわからないときは、AI にプロンプトで尋ねます。それからコードを書き始め、修正すべき点を尋ねるといった具合です。」

学習障がいのある学生にとっては、常に利用できるという点が、不利な状況を克服するために役立っています。

「私は学習障がいがあるため、問題を理解するのに人より時間がかかります。AI にはすごく助けられています。24 時間 365 日、いつでも付いていてくれるサブ教師のような存在です。」

AI を使えば、学校の営業時間に縛られることなく、いつでも理解を掘り下げられます。AI のおかげで脳の処理能力に余裕が生まれ、より高度な思考が可能となります。

「実際にコーディングする時間は減り、全体のアイデアを練るのに時間をかけられるようになりました。今では、手動でコードを生成する代わりに、ロジックとコンセプトの検討や、アイデアの創出に時間を費やしています。」

こうしたコメントから、AI が最終的な作品を仕上げるためではなく、探索ツールとして利用されている様子が浮かび上がります。これは、DORA の調査結果と一致しています。調査によると、AI がルーチンワークを引き受けることで、デベロッパーはユーザーへの価値提供に専念できるようになっています。

調査結果その 2: 過度な依存に対する積極的な抵抗

学びのプロセスを守るために、境界線を設ける

学生たちは、AI を学習ツールとして活用する一方で、AI への過依存への不安を率直に表現しました。

「AI がなくなったら、自分で解決方法を探すのに苦労してしまうかもしれません。」

エッセイ執筆中の脳活動を脳波検査で測定した最近の研究では、AI の利用者は、検索エンジンやツールを使用しない人に比べ、認知エンゲージメントのパターンが弱いことがわかりました。また、AI のヘビーユーザーが、アシスタントを使わずにエッセイを書いてみたところ、以前に書いた作品についての記憶があまりなく、自分の作品であるという意識も低いことがわかりました。このことを、論文の著者は「認知の負債」と表現しています。1

一方で、ポジティブな兆候が明らかになりました。学生たちは、この認知上のリスクをただ受け入れるのではなく、意図的に境界線を設けて対応しています。

機械工学専攻のある学生は、電子機器を何年も使用するうちに、以下のように能力ベースの AI 使用ルールを確立したといいます。

「サーボや超音波などの基本的センサーなら自分でコーディングできますが、複雑なセンサーで、かつ、機能を厳密に把握する必要性がないときは、AI を使用します」と回答し、次のように説明しています。「何かがうまくいかないとき、その理由を理解できても、問題を解決するための直接的な言語を知らない場合があります。AI は、そのような状況で役立ちます。」

この学生は、最近携わったプロジェクト（触って操作できるストーリーテリングツールの構築）において、基本的なコンセプトを理解した後、カウントおよび比較のシステム構築のために助けを求めたとのことです。「AI は、基本構造のセットアップに大変役立ちましたが、その後、微調整のコーディングは自力でやる必要がありました。」また、作業の振り分けについては、次のように明確な意見を述べています。「自分でも引き続き、コードを書いています。技術者のように丸投げするわけではなく、AI と共同で作業を進め、私が司令塔となって AI にやってほしいことを指示します。ただやみくもにリクエストしても、まったく役に立ちません。」

学生が AI を利用する際には、明確な利用ルールを設けているケースが多く見られました。

「AI にはたまに、完全な答えではなく方向性だけを示すように頼みます。」

過度な依存を避けるため、学生は以下のような具体策を編み出しています。

高度なモデルの利用を避ける:

「料金制の AI ツールを使用するつもりはありません。AI モデルを使いすぎてしまう恐れがありますから。」

AI の使用、不使用を交互に繰り返す:

「for ループの処理など、一部の処理はまた自分で書くようになりました。」

「バイブコーディング」を警戒する:

「AI ツールがデベロッパーの生産性を高めるために役立つことは間違いありません。ただし、バイブコーディングに慣れてしまわないよう、十分な注意が必要です。AI が生成するコードを理解して検証し、適切な方法で使用するということが大前提です。」

こうした懸念は、学生たちが認知について意識的に考えているということを示しています。彼らは、一番楽な方法が最も学習効果が高いわけではないと認識しています。これは DORA の調査結果とも一致しています。調査によると、AI の導入率が 90% にのぼるにもかかわらず、利用者の約 30% が AI が生成したコードをほとんど（あるいはまったく）信用していないと答えています。AI を効果的に使用するには、単に導入するだけでなく、厳しい評価と検証の方法を習得することが求められます。

調査結果その 3: AI の使いどころを心得ている

アイトラッキングデータからわかったこと

アイトラッキング技術を使用した調査では、人の動作の面から検証を行いました。1～5 年の経験を持つデベロッパーを対象に、AI コーディングアシスタントとやり取りする様子を観察したところ、タスクの種類によって AI の利用に大きな違いがあることがわかりました。

思考と深い理解が必要なタスク: AI への視覚的注目が 1% 未満
機械的なタスク（ボイラープレートコードなど）: AI への視覚的注目が 19%

高度な作業においては、たとえ AI の提案が正確で時間の節約につながるような場合でも、敢えて無視されていることがわかりました。深い理解が必要なときは、AI は認知上の負担となります。熟練デベロッパーは、AI をオフにすべきときを心得ています。

すべてを任せるのではなく、意図的に取り入れる

学生への聞き取り調査からも、学生が AI を用途に応じて使い分けている様子が伺えます。

「私は普段、とっかかりとなるアイデアを得るために AI を使っています。」

「AI の使用が許可されていることは知ってましたが、学習と試行錯誤のプロセスを大事にしました。創造性の余地も必要です。」

カスタマイズが肝

現在、ほとんどの AI コーディングアシスタントは、インライン提案のオン / オフを切り替えたり、オンデマンド専用モードに設定したり、提案頻度を調整したりできます。これらの設定を試して、タスクとその認知要件に応じて AI を使い分けることで、ルーチンワークでは助けてもらいつつ、自分で深く考えたい仕事の邪魔をされないようにすることができます。

この調査結果が業界において意味すること

AI を利用した開発の未来を形作っていくのは、今の学生たちです

調査に協力してくれた学生たちは、時代の一歩先をいっており、すでに AI リテラシーを身につけています。用途に応じた使い分けや、出力の検証方法を心得ており、自らの理解力を維持するためにときには敢えて手動で作業するといった対策をとっています。AI 導入を検討中の方にとって、こうした学生の経験は、進むべき方向を探るヒントとなります。

さまざまなカスタマイズ設定を試す: 作業の妨げとならず、助けとなるような設定を見つけましょう。
ワークフローに検証プロセスを取り入れる: AI の提案を無批判に受け入れないようにしましょう。
自分の聖域を確保する: スピードよりも深い理解が重要となる高度な問題には、AI の助けを借りずに自分で取り組むようにしましょう。

業界の専門家が AI の導入をどのように進めているかについて詳しくは、2025 年 DORA レポート: AI 支援によるソフトウェア開発の現状をダウンロードしてご覧ください。カリフォルニア大学バークレー校の研究者との共同研究による論文全文もあわせてお読みいただけます。

^{1. Kosmyna, Nataliya, et al. "Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task." arXiv, 10 June 2025, doi:10.48550/arXiv.2506.08872.（参照日付: 2026 年 1 月 28 日）}

- Andrew Harlan 博士（独立系 UX リサーチャー兼クリエイティブテクノロジスト）

- Steve Fadden 博士（Google、UX リサーチ担当リード）

分散 AI エージェントの構築

Thu, 02 Apr 2026 03:00:00 +0000

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

率直に言って、1 回だけ動作する AI エージェントを構築するのは簡単です。しかし、本番環境で確実に動作する AI エージェントを構築し、既存の React や Node.js アプリケーションと統合する場合は、まったく別の話です。

（説明は省略して、コードに直接移動したい場合は、GitHub のコース作成エージェントのアーキテクチャをご覧ください。）

身近な例で考えてみましょう。トピックを調査し、コンテンツを生成して、それを評価するという複雑なワークフローがあるとします。このワークフローを、1 つの巨大な Python スクリプトまたは大きなプロンプトに詰め込んだとしましょう。ローカルマシンでは正常に動作しましたが、スマートな外観のフロントエンドに接続しようとすると、厄介なことになります。レイテンシが急上昇し、デバッグが困難で、スケールするためにモノリス全体の複製が必要となります。

一方、AI に対応するために、アプリケーション全体を書き換える必要がないとしたらどうでしょうか。プラグを差し込むだけで使えるとしたら？

この投稿では、オーケストレーターパターンという優れた方法について説明します。具体的には、すべてを請け負う強力なエージェントを 1 つだけ作るのではなく、複数の特化した分散マイクロサービスから成るチームを構築します。このアプローチにより、モノリスの書き換えに悩まされることなく、強力な AI 機能を既存のフロントエンドアプリケーションに直接統合することが可能となります。

そのために、Google の Agent Development Kit（ADK）を使ってエージェントを構築し、Agent-to-Agent（A2A）プロトコルによって複数のエージェントを接続して相互通信し、Cloud Run 上でスケーラブルなマイクロサービスとしてデプロイします。

分散エージェントを使用する理由（フロントエンドチームに感謝される理由）

すでに完成された状態の Next.js アプリケーションがあるとします。これに、「コース作成ツール」という機能を追加したいとしましょう。

そのためにモノリスエージェントを構築すると、フロントエンドは、長時間かかる単一プロセスがすべて完了するまで待たされることになります。調査部分が滞ると、リクエスト全体がタイムアウトになります。また、個々のエージェントを必要に応じてスケールするといったこともできません。たとえば、評価エージェントがより多くの処理能力を必要とする場合、評価エージェントだけでなく、すべてのエージェントをスケールアップすることになります。

これに対し、分散オーケストレーターパターンを使用すれば、スケーラビリティと柔軟性が得られます。

シームレスなインテグレーション: フロントエンドは 1 つのエンドポイント（オーケストレーター）と通信し、オーケストレーターがバックグラウンドで複雑な処理を管理します。
個別にスケーリング: 評価ステップに時間がかかる場合は、そのサービスだけを 100 インスタンスにスケールアップし、調査サービスは小規模のままにできます。
モジュール式: 高パフォーマンスのネットワーキング部分を Go で、データサイエンス部分を Python で記述できます。これらの通信には HTTP を使用します。

全体的な設計: コース作成アプリ

では、コース作成システムを構築しましょう。以下の 3 つのスペシャリストに分けて考えます。

調査担当: 情報を掘り起こすスペシャリスト。
評価担当: 品質を保証する QA スペシャリスト。
オーケストレーター: 作業間の調整を行い、フロントエンドと通信するマネージャー。

ステップ 1: スペシャリスト（リサーチャー）の配備

まず、調査の担当者が必要です。ADK を使って、Google 検索の部分のみを担当するエージェントを構築しましょう。

code_block: <ListValue: [StructValue([('code', '# researcher/app/agent.py\r\nfrom google.adk.agents import Agent\r\nfrom google.adk.tools import google_search\r\n\r\nresearcher = Agent(\r\n name="researcher",\r\n model="gemini-2.5-flash",\r\n description="Gathers information on a topic using Google Search.",\r\n instruction="""\r\n You are an expert researcher. Your goal is to find comprehensive information.\r\n Use the `google_search` tool to find relevant information.\r\n Summarize your findings clearly.\r\n """,\r\n tools=[google_search],\r\n)'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f39bd6cfe50>)])]>

ご覧のように、とても簡単です。このエージェントは、コースやフロントエンドについては関知しません。調査のみを行います。

ステップ 2: 評価担当者（構造化されたデータ出力）

エージェントからの長ったらしい説明はいりません。コード側で判断しやすいよう、合格（pass）または不合格（fail）の厳密な評価が必要です。Pydantic を使って、このデータ規定を適用しましょう。

code_block: <ListValue: [StructValue([('code', '# judge/app/agent.py\r\nfrom pydantic import BaseModel, Field\r\nfrom typing import Literal\r\n\r\nclass JudgeFeedback(BaseModel):\r\n status: Literal["pass", "fail"] = Field(\r\n description="Whether the research is sufficient (\'pass\') or needs more work (\'fail\')."\r\n )\r\n feedback: str = Field(\r\n description="Detailed feedback on what is missing."\r\n )\r\n\r\njudge = Agent(\r\n name="judge",\r\n model="gemini-2.5-flash",\r\n description="Evaluates research findings.",\r\n instruction="""\r\n You are a strict editor. Evaluate the findings.\r\n If they are missing key info, output status=\'fail\' and provide feedback.\r\n """,\r\n output_schema=JudgeFeedback, # Enforce the contract!\r\n)'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f39bd6cf880>)])]>

これで、評価担当者が JSON で話すようになり、アプリケーションロジックはそれを信頼できます。

ステップ 3: 共通言語（A2A プロトコル）

ここでマジックを使いましょう。A2A プロトコルを使って、これらのエージェントをウェブサービスとしてラップします。エージェントの共通言語のようなものとお考えください。エージェントは機能を説明し（agent.json）、標準の HTTP で通信します。

code_block: <ListValue: [StructValue([('code', '# researcher/app/server.py\r\nfrom fastapi import FastAPI\r\nfrom a2a.server.apps import A2AFastAPIApplication\r\nfrom app.agent import app as adk_app\r\n\r\n# ... setup runner ...\r\n\r\n# Create the A2A App wrapper\r\na2a_app = A2AFastAPIApplication(agent_card=agent_card, http_handler=request_handler)\r\n\r\napp = FastAPI(lifespan=lifespan)\r\n\r\n# Register routes: /.well-known/agent.json and /rpc\r\na2a_app.add_routes_to_app(app)'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f39d0642f10>)])]>

これで、リサーチャー（ポート 8000 で実行されるマイクロサービス）を配備できました。このサービスを、オーケストレーターなど、あらゆるものから呼び出すことが可能です。

ステップ 4: オーケストレーターパターン

では、すべてを組み合わせましょう。オーケストレーターは、請負業者のようなものです。つまり、自分で調査を行わず、リサーチャーを雇います。自分で判断を下さず、評価担当者に尋ねます。

重要な点は、フロントエンドはこのエージェントのみを識別できればよいということです。

code_block: <ListValue: [StructValue([('code', '# orchestrator/app/agent.py\r\nfrom google.adk.agents import LoopAgent, SequentialAgent\r\nfrom google.adk.agents.remote_a2a_agent import RemoteA2aAgent\r\n\r\n# Connect to the remote Researcher service\r\nresearcher = RemoteA2aAgent(\r\n name="researcher",\r\n agent_card="http://researcher-service:8000/.well-known/agent.json",\r\n description="Gathers information on a topic."\r\n)\r\n\r\n# Connect to the remote Judge service\r\njudge = RemoteA2aAgent(\r\n name="judge",\r\n agent_card="http://judge-service:8000/.well-known/agent.json",\r\n description="Evaluates research findings."\r\n)\r\n\r\n# The Orchestrator manages the loop\r\nresearch_loop = LoopAgent(\r\n name="research_loop",\r\n sub_agents=[researcher, judge, escalation_checker],\r\n max_iterations=3,\r\n)\r\n\r\n# The full pipeline\r\nroot_agent = SequentialAgent(\r\n name="course_creation_pipeline",\r\n sub_agents=[research_loop, content_builder],\r\n)'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f39d06426a0>)])]>

オーケストレーターが複雑な処理（再試行、ループ、状態管理）を担当するため、フロントエンドはクリーンかつシンプルに保たれます。

デプロイ:「食料品店」モデル

このシステムを Cloud Run にデプロイすることを、私は「食料品店」モデルと呼んでいます。チェックアウトの列（リサーチャーのタスク）が長くなっても、新しい店舗を建設する必要はありません。レジを増やせばいいだけです。Cloud Run は、調査の負荷増大に対応するために調査サービスのみをスケールし、評価サービスはそのまま保たれます。

注意事項、セキュリティ上の配慮

もちろん、大いなる力には大きな責任が伴います（そして、セキュリティチェックが必要となります）。

認証: このデモでは、エージェントはオープンな HTTP を介して通信しています。本番環境では、このアクセスを制限する必要があります。mTLS、OIDC、または API キーを使用して、オーケストレーターのみがリサーチャーと通信できるようにします。
レイテンシ: ホップごとに時間が追加されます。オーケストレーターパターンは、詳細レベルの頻繁なインタラクションではなく、ざっくりとしたタスク（「このトピックを調査して」など）に使用するようにしましょう。
エラー処理: ネットワークにはエラーがつきものです。オーケストレーターには、タイムアウトと再試行を適切に処理できるような堅牢性が必要です。

構築を始めるにあたって

あらゆる作業を請け負う 1 つの巨大なエージェントを構築するのはやめましょう。オーケストレーターパターンと分散マイクロサービスを使用することで、スケーラブルで保守が容易な AI システムを構築できるだけでなく、既存のアプリとスムーズに連携できるというメリットも得られます。

コードについては、GitHub のコース作成エージェントのアーキテクチャで詳細をご確認ください。

準備ができたら、Cloud Run、ADK、A2A を使ってさっそくエージェントチームを結成しましょう。

- AI デベロッパーリレーションズエンジニア、Amit Maraj

マルチクラスタ GKE Inference Gateway のご紹介: 世界中で AI ワークロードをスケール

Wed, 25 Mar 2026 03:00:00 +0000

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

AI の世界は急速に変化しており、モデルのサービングを大規模かつ確実に行う必要性も高まっています。このたび、マルチクラスタ GKE Inference Gateway のプレビュー版がリリースされましたのでお知らせいたします。これにより、複数の Google Kubernetes Engine（GKE）クラスタにわたり（異なる Google Cloud リージョンにまたがる場合も含め）、AI / ML 推論ワークロードのスケーラビリティ、復元力、効率性を強化できます。

GKE Gateway API の拡張機能として構築されたマルチクラスタ Inference Gateway は、マルチクラスタ Gateway の機能を活用して、特に要求の厳しい AI アプリケーション向けに、モデル対応のインテリジェントなロードバランシングを提供します。

AI 推論にマルチクラスタを使用する理由

AI モデルの複雑性が増し、ユーザーのグローバル化が進むにつれて、単一クラスタのデプロイでは次のような課題に直面する可能性があります。

可用性のリスク: リージョンの停止やクラスタのメンテナンスがサービスに影響を及ぼす可能性があります。
スケーラビリティの上限: 単一のクラスタまたはリージョン内で、ハードウェアの上限（GPU / TPU）に達してしまいます。
リソースのサイロ化: あるクラスタで十分に活用されていないアクセラレータ容量を別のクラスタで使用できません。
レイテンシ: サービスを提供しているクラスタから離れているユーザーはレイテンシが高くなる可能性があります。

マルチクラスタ GKE Inference Gateway は、これらの課題に正面から取り組み、次のようなさまざまな機能とメリットを提供します。

信頼性とフォールトトレランスの強化: 異なるリージョン間を含め、複数の GKE クラスタにわたってトラフィックをインテリジェントにルーティングします。1 つのクラスタまたはリージョンで問題が発生した場合、トラフィックは自動的に再ルーティングされ、ダウンタイムが最小限に抑えられます。
スケーラビリティの向上とリソース使用量の最適化: さまざまなクラスタから GPU / TPU リソースをプールして活用できます。単一クラスタの容量を超えてバーストすることで需要の急増に対応し、利用可能なアクセラレータをフリート全体で効率的に活用できます。
グローバルに最適化されたモデル対応のルーティング: Inference Gateway は、高度なシグナルを使用してスマートなルーティング判断を下すことができます。GCPBackendPolicy を使用して、リアルタイムのカスタム指標（モデルサーバーの KV キャッシュ使用率指標など）に基づいてロードバランシングを構成できるので、最適なバックエンドインスタンスにリクエストが送信されるようになります。処理中リクエストの制限など、他のモードもサポートされています。
運用の簡素化: モデルを複数の「ターゲットクラスタ」で実行しながら、専用の GKE「構成クラスタ」で 1 つの Inference Gateway 構成を使用して、グローバルに分散された AI サービスへのトラフィックを管理できます。

仕組み

GKE Inference Gateway には、InferencePool と InferenceObjective という 2 つの基本リソースがあります。InferencePool は、同じコンピューティングハードウェア（GPU や TPU など）とモデル構成を共有する Pod のリソースグループとして機能し、スケーラブルで高可用性のサービングを実現します。InferenceObjective は、特定のモデル名を定義し、サービングの優先順位を割り当てます。これにより、Inference Gateway はトラフィックをインテリジェントにルーティングし、レイテンシの影響を受けやすいタスクと緊急性の低いワークロードを多重化できます。

このリリースでは、Kubernetes カスタムリソースを使用して、分散推論サービスが管理されます。各「ターゲットクラスタ」の InferencePool リソースは、モデルサーバーのバックエンドをグループ化します。これらのバックエンドはエクスポートされ、「構成クラスタ」で GCPInferencePoolImport リソースとして表示されます。構成クラスタ内の標準の Gateway リソースと HTTPRoute リソースは、エントリポイントとルーティングルールを定義し、トラフィックをこれらのインポートされたプールに転送します。CUSTOM_METRICS や IN_FLIGHT リクエストの使用など、きめ細かいロードバランシングの動作は、GCPInferencePoolImport にアタッチされた GCPBackendPolicy リソースを使用して構成されます。

このアーキテクチャにより、グローバルな低レイテンシのサービング、障害復旧、容量のバースト、異種ハードウェアの効率的な使用などのユースケースが可能になります。

GKE Inference Gateway のコアコンセプトについて詳しくは、ガイドをご覧ください。

使ってみる

AI 推論サービングワークロードをより多くの場所とより多くのユーザーにスケールする際に、マルチクラスタ GKE Inference Gateway をぜひお試しください。詳細と利用方法については、次のドキュメントをご覧ください。

- シニアプロダクトマネージャー、Arman Rye

- シニアスタッフソフトウェアエンジニア、Andres Guedez

Vertex AI で復元力の高い LLM アプリケーションを構築し、429 エラーを減らす

Mon, 23 Mar 2026 02:00:00 +0000

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

Vertex AI で大規模言語モデル（LLM）を活用したアプリケーションを構築するのは楽しいことですが、429 エラーが発生すると、イライラの原因になることがあります。これらのエラーは、リクエストの受信速度が、その時点でサービスが処理できる量を上回っていることを示しています。

昨年、Google はこれらの 429 エラーの処理に関するガイドを公開しました。この記事では、Vertex AI の使用量モデルについて詳しく掘り下げ、リクエストフローを管理するためのアーキテクチャのベストプラクティスについて説明します。これにより、スムーズで復元力が高く、真にスケーラブルな AI アプリケーションを構築できます。

適切な使用量オプションの選択

Vertex AI は、さまざまなタイプとボリュームの API トラフィックに対応するように設計された、幅広い使用量モデルが用意されています。429 エラーを最小限に抑えるための主な戦略は、アプリケーション固有のトラフィックパターンに最も適した使用量モデルを選択することです。

デフォルトオプション: Vertex AI の Gemini におけるデフォルトオプションは、Standard 従量制（Paygo）です。Standard 従量制（Paygo）トラフィックの場合、Vertex AI は使用量ティアシステムを使用します。この動的なアプローチでは、共有プールからリソースが割り当てられ、組織の過去の費用に基づいて使用量ティアとベースラインスループット（TPM）が決まります。このベースラインにより、一般的なワークロードの予測可能なパフォーマンスの下限が決まるものの、アプリケーションは引き続きベストエフォートベースでそれ以上のパフォーマンスを発揮できます。

予測不可能で、Standard Paygo よりも高い信頼性を必要とする、重要なユーザー向けトラフィックをアプリケーションが生成する場合は、Priority Paygo が適しています。リクエストに優先度ヘッダーを追加することで、そのトラフィックを優先すべきであることを示し、スロットリングされる可能性を減らします。

リアルタイムトラフィックの量が常に多いアプリケーションの場合、共有 PayGo プールから分離できる使用量オプションはプロビジョンドスループット（PT）だけであり、PayGo における競合が激しい場合でもエクスペリエンスが安定します。PT では、保証されたスループットを予約して料金を支払うことで、重要なトラフィックがスムーズに流れるようにします。Vertex AI での PT について詳しくは、こちらのガイドをご覧ください。

費用対効果の高いオプション: Vertex AI には、レイテンシの影響を受けにくいトラフィック向けに、費用対効果の高いオプションが用意されています。Flex PayGo は、レイテンシが許容されるトラフィックに適しており、リクエストを低料金で処理します。オフライン分析や一括データ拡充などの大規模な非同期ジョブは、Batch で処理するのが最適です。このサービスは、スケーリングや再試行を含むワークフロー全体をより長い期間（約 24 時間）にわたって管理し、メインのアプリケーションをこの高い負荷から保護します。

複雑なアプリケーションとハイブリッドアプローチ: 複雑なアプリケーションでは、ハイブリッドアプローチがよく利用されます。PT は最も重要なリアルタイムトラフィック、Priority Paygo は変動するトラフィック、Standard Paygo は一般的なリクエスト、Batch / Flex はレイテンシが許容されるオフラインのリクエストフローに使用されます。

Vertex AI で 429 エラーを減らす 5 つの方法

1. スマート再試行の実装

アプリケーションで 429（リソース不足）や 503（サービス利用不可）などの一時的なオーバーロードエラーが発生した場合、すぐに再試行することは推奨されません。ベストプラクティスとして、ジッターを伴う指数バックオフと呼ばれる再試行戦略を実装できます。指数バックオフとは、再試行の間隔が指数関数的に長くなり、通常は事前定義された上限まで長くなることを意味します。これにより、サービスが過負荷状態から回復する時間を確保できます。

SDK とライブラリ: Google Gen AI SDK には、クライアントパラメータの HttpRetryOptions を使用して構成できるネイティブの再試行動作が含まれています。ただし、Tenacity（Python 用）などの専用ライブラリを活用したり、カスタムソリューションを構築したりすることもできます。詳しくは、こちらのブログ投稿をご覧ください。
エージェントワークフロー: エージェントを開発するために、Agent Development Kit（ADK）には Reflect and Retry プラグインが用意されています。このプラグインは、429 エラーを自動的にインターセプトすることで、AI ワークフローに復元力を組み込みます。
インフラストラクチャとゲートウェイ: Apigee によるサーキットブレーキングも、復元力を高めるためのもう一つの堅牢なオプションです。これにより、トラフィックの分散を管理し、正常な障害処理を実装できます。

2. グローバルモデルルーティングの活用

Vertex AI のインフラストラクチャは複数のリージョンに分散されています。デフォルトでは、特定のリージョンエンドポイントをターゲットにした場合、リクエストはそのリージョンから処理されます。これは、その単一リージョンの容量に基づいてアプリケーションの可用性が決まることを意味します。そして、グローバルエンドポイントが、可用性と復元力を高めるための効果的なツールとなります。グローバルエンドポイントは、1 つのリージョンに限定されるのではなく、可用性がより高い可能性のあるリージョンフリート全体にトラフィックをルーティングし、潜在的なエラー率を低減します。

3. コンテキストキャッシュによるペイロードの削減

Vertex AI の負荷を軽減する効果的な方法として、繰り返しクエリの呼び出しを避けることができます。多くの本番環境アプリケーション、特に chatbot やサポートシステムでは、似たような質問が頻繁に寄せられます。それらの質問を再処理する代わりに、コンテキストキャッシュを実装できます。コンテキストキャッシュ保存を使用すると、Gemini は事前に計算されたキャッシュトークンを再利用するため、API トラフィックとスループットを削減できます。これにより、費用を節約できるだけでなく、プロンプト内の繰り返しコンテンツのレイテンシも短縮されます。

4. プロンプトの最適化

各リクエストのトークン数を減らすと、TPM の使用量と費用が直接削減されます。

Flash-Lite による要約: Gemini Pro などのモデルに長い会話履歴を送信する前に、Gemini 2.5 Flash-Lite などの軽量モデルを使用してコンテキストを要約します。
エージェントメモリ最適化: エージェントワークロードでは、Vertex AI Agent Engine Memory Bank を活用できます。メモリーの抽出と統合などの機能により、会話から意味のある事実を抽出できるため、エージェントは未加工のチャット履歴がなくてもコンテキストアウェアな状態を維持できます。
プロンプトの衛生: プロンプトを確認し、詳細すぎる JSON スキーマの説明（モデルがすでに精通している場合）を減らし、過剰な空白や冗長な書式設定を削除します。

5. トラフィックのシェイプ

リクエストの急激なバーストは、429 エラーの主な原因です。平均トラフィックレートが低くても、急激に増加するとリソースに負荷がかかる可能性があります。目標は、トラフィックを平滑化し、長期間にわたってリクエストを分散することです。

使ってみる

ご紹介したパターンを実際に使用される場合は、 GitHub の Vertex AI サンプルを確認するか、Google Cloud 初心者向けガイドの Vertex AI クイックスタートを使用して次のプロジェクトをすぐに開始するか、Agent Development Kit（ADK）で次の AI エージェントの構築を開始してください。

- Google Cloud シニアプロダクトマネージャー、Richard Liu

- Cloud AI テクニカルエバンジェリスト、Pedro Melendez

Ollama、GKE の GPU 共有、vCluster を使って、費用対効果の高い AI を実現する

Tue, 17 Mar 2026 02:00:00 +0000

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

組織が AI ワークロードをスケールすると、主に 2 つの課題が浮上します。1 つは、使用率の低い GPU に費用がかさむということ、もう 1 つは、複数チームの分離環境を管理運用するのが複雑であるということです。経験則として、GPU 全体を 1 つの Pod に割り当てるのは非効率です。また一方で、チームごとに個別のクラスタを管理すると、運用上の負担が大きくなるという問題があります。

この投稿では、Google Kubernetes Engine（GKE）の GPU タイムシェアリングと、マルチテナンシー用の vCluster を組み合わせて、この両方の問題を解決する方法を紹介します。具体的には、分離した複数の仮想環境に Ollama をデプロイしてオープンモデル（Mistral など）を提供し、これらの環境で 1 つの物理的な GPU インフラストラクチャを共有します。

アーキテクチャ: 共有ハードウェア上の仮想クラスタ

このアーキテクチャでは、GKE Autopilot を活用して物理インフラストラクチャを抽象化しています。ワークロードをデプロイすると、Autopilot が GPU やドライバなどの必要なハードウェアをオンデマンドでプロビジョニングしてくれるため、ノードの管理は不要です。

これにより複数のチームがそれぞれ分離された環境内で、API、Ollama インスタンスや、場合によっては異なるモデルを使用しながら、これらをすべて費用対効果の高い同じ共有 GPU ノードで実行することが可能となります。たとえば、チーム A（法務調査など）とチーム B（カスタマーサポートなど）が、GPU リソースを共有しながら、別々の環境で作業できます。

vCluster では、既存の Kubernetes クラスタ上に仮想 Kubernetes クラスタを作成できます。vCluster はさまざまなテナンシーモードをサポートしています。たとえば、この図に示されている共有ノードモデルでは、各仮想クラスタが独自の分離したコントロールプレーンを取得しながら、基盤となるワーカーノードを共有しています。個々の仮想クラスタには、そのクラスタへのフルアクセスを持つ管理者がアクセスでき、他のチームとの干渉は発生しません。このモデルでは、ホストクラスタ機能も適宜利用できるほか、各仮想クラスタ内に独自のコントローラや CRD をデプロイできます。

vCluster では、次のいずれかのテナンシーモードを使用できます。

共有ノード: このモードでは、複数の仮想クラスタが同じ物理 Kubernetes ノードでワークロードを実行できます。この構成は、リソース使用率の最大化が最優先のシナリオに最適です。特に、社内の開発環境、CI / CD パイプラインや、コスト重視のユースケースに適しています。
プライベートノード: このモードでは、ホストクラスタのワーカーノードを共有せず、個々の vCluster にそれぞれワーカーノードを追加します。これらのプライベートノードはその vCluster のワーカーノードとして機能し、同じホストクラスタ内の他の vCluster には共有されません。
自動ノード: ノードとリソースの要件に基づいて、ワーカーノードを自動的にプロビジョニングして追加するように vCluster を構成します。自動ノードを使用するには、vCluster Platform をインストールし、それに vCluster を接続する必要があります。
スタンドアロン: これは、コントロールプレーンとノードに関してアーキテクチャが異なるモードです。スタンドアロンモードでは、ホストクラスタは不要です。他の Kubernetes ディストリビューションと同様、vCluster はノードに直接デプロイされます。スタンドアロンの vCluster は、ベアメタルノードや VM など、あらゆるタイプのノードで実行できます。コントロールプレーンやワーカーノードの共有ホストクラスタがないため、ワークロードを最も厳格に分離できます。

デプロイ

デプロイ手順に沿って進めるには、次のものがインストールされていることを確認してください。

ステップ 1: GKE Autopilot クラスタを設定して作成する

GKE Standard とは異なり、ノード数を計算したり、ノードプールを手動で構成したりする必要はありません。自動的にクラスタが作成されて、認証情報が取得されます。

環境変数を設定し、GKE Autopilot クラスタを作成します。

export PROJECT_ID=YOUR_PROJECT_ID

export REGION=YOUR_REGION_ID

# GKE Autopilot クラスタを作成する

gcloud container clusters create-auto vcluster-gpu-sharing \

--region=$REGION --project $PROJECT_ID
YOUR_PROJECT_ID と YOUR_REGION_ID は、使用する Google Cloud プロジェクトとリージョンに置き換えます。
ローカルの kubectl を構成するために、認証情報を取得します。

gcloud container clusters get-credentials vcluster-gpu-sharing \

--region $REGION --project $PROJECT_ID

ステップ 2: 仮想クラスタ（vCluster）を作成する

Autopilot クラスタを実行すると、テナントに対して分離環境を作成できるようになります。ここでは、demo1 と demo2 の 2 つの vCluster を作成します。構成には vcluster.yaml マニフェストファイルが必要です。

GKE Autopilot を使用する場合、最初の vCluster の作成には数分かかることがあります。これは、独自のコントロールプレーンの Pod が稼働するのを待機するためです。Autopilot はこの新しいワークロードに対して基盤となるノードを動的にプロビジョニングするため、インフラストラクチャが初期化されるまで少々遅延が発生します。

code_block: <ListValue: [StructValue([('code', '# Create the vcluster configuration file\r\ncat <<EOF > vcluster.yaml\r\n# Place your vCluster configuration here. \r\n# For GPU workloads on GKE Autopilot, this typically involves \r\n# enabling node synchronization so the vCluster can see the \r\n# underlying GPU nodes provided by Autopilot.\r\nsync:\r\n fromHost:\r\n ingressClasses:\r\n enabled: true\r\n nodes:\r\n enabled: true\r\n toHost:\r\n ingresses:\r\n enabled: true\r\nEOF\r\n\r\n# Create the first virtual cluster\r\nvcluster create demo1 -n demo1 -f vcluster.yaml\r\n\r\n# Create the second virtual cluster\r\nvcluster create demo2 -n demo2 -f vcluster.yaml'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f39cc11fc70>)])]>

注: vCluster を別の vCluster 内に作成しようとしているというエラー警告が表示された場合は、[no] を選択して、正しいホストコンテキストに切り替えてください。

ステップ 3: Ollama を仮想クラスタにデプロイする

まず、Ollama のデプロイマニフェストを作成します。このマニフェストによって Ollama をデプロイし、Kubernetes Service を使用してポート 11434 で公開します。

Ollama のデプロイマニフェストを作成します。このマニフェストによって Ollama をデプロイし、Kubernetes Service を使用してポート 11434 で公開します。GPU タイムシェアリングを使用するノードを選択します。

# Ollama のデプロイマニフェストを作成する

cat <<EOF > ollama.yaml

apiVersion: apps/v1

kind: Deployment

metadata:

name: ollama

namespace: default

spec:

replicas: 1

selector:

matchLabels:

app: ollama

template:

metadata:

labels:

app: ollama

spec:

nodeSelector:

# GPU タイムシェアリングを使用するノードを選択する。

# 基盤の GPU を一定数のコンテナで共有することを

# 許可するノードを選択する。

# Nvidia L4 GPU を搭載したノードを選択する。

cloud.google.com/gke-gpu-sharing-strategy: "time-sharing"

cloud.google.com/gke-max-shared-clients-per-gpu: "5"

cloud.google.com/gke-accelerator: nvidia-l4

containers:

- name: ollama

image: ollama/ollama:latest

ports:

- containerPort: 11434

resources:

limits:

nvidia.com/gpu: 1

---

apiVersion: v1

kind: Service

metadata:

name: ollama

namespace: default

spec:

selector:

app: ollama

ports:

- port: 11434

targetPort: 11434

type: ClusterIP

EOF
vCluster がアクティブになったら、コンテキストを切り替えて demo1 内で作業します。

# 仮想クラスタ demo1 に接続する

vcluster connect demo1 -n demo1
仮想環境に Ollama をデプロイします。

# デプロイマニフェストを適用する

kubectl apply -f ollama.yaml
仮想クラスタ内にいても、GPU をリクエストする Pod を作成すると、このリクエストはホストに同期されます。GKE Autopilot はこのリクエストを検出し、ワークロードを実行するノードに必要な GPU ハードウェアを自動的にアタッチします。

ステップ 4: モデルの pull とテスト

サーバーが実行されたら、仮想クラスタのコンテキスト内で、モデルの pull とテストを実行します。

# Pod 内で pull コマンドを実行する

kubectl exec -it <pod-name> -- ollama pull mistral
API を検証します。

# Ollama サービスをポート転送する

kubectl port-forward svc/ollama 8080:11434

# 新しいウィンドウでチャットリクエストを送信する

curl -s http://localhost:8080/api/chat \

-H "Content-Type: application/json" \

-d '{ "model": "mistral", "stream": false, "messages": [ {"role": "user", "content": "Explain GKE Autopilot"} ] }' | jq -r '.message.content'

ステップ 5: Ollama を vCluster demo2 にデプロイする

同じ手順を繰り返して、Ollama をデプロイし、モデルを 2 つ目の仮想クラスタに pull します。

code_block: <ListValue: [StructValue([('code', '# 仮想クラスタに接続する\r\nvcluster connect demo2 -n demo2\r\n\u200b\r\n# デプロイマニフェストを適用する\r\nkubectl apply -f ollama.yaml\r\n\u200b\r\n# Pod 内で pull コマンドを実行する\r\nkubectl exec -it <pod-name> -- ollama pull mistral\r\n\u200b\r\n# Ollama サービスをポート転送する\r\nkubectl port-forward svc/ollama 8080:11434\r\n\u200b\r\n# 新しいウィンドウでチャットリクエストを送信する\r\ncurl -s http://localhost:8080/api/chat \\\r\n-H "Content-Type: application/json" \\\r\n-d \'{ "model": "mistral", "stream": false, "messages": [ {"role": "user", "content": "Explain GKE Autopilot"} ] }\' | jq -r \'.message.content\''), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f39cc11f070>)])]>

基盤となるインフラストラクチャを検証する

それでは、ホストクラスタのコンテキストに戻って、何が起こっているかを確認しましょう。

プロビジョニングされたノードの数と、Ollama Pod が実行されている場所を確認します。

# 利用可能なコンテキストを一覧表示する

kubectx

# ホストクラスタのコンテキストに切り替える

kubectx gke_$PROJECT_ID_$REGION_vcluster-gpu-sharing

# ノードを一覧表示する

Kubectl nodes
2 つのノードが表示されるはずです。1 つは vCluster コンポーネントを実行しています。もう 1 つは、L4 GPU を使用して Ollama インスタンスを実行しています。出力は次のようになります（ノード名は異なります）。

# kubectl get nodes の出力

$ kubectl get nodes

NAME STATUS ROLES AGE VERSION

gk3-vcluster-gpu-sharing-nap-1w88cyly-895203e4-xbqk Ready <none> 7h8m v1.33.5-gke.2072000

gk3-vcluster-gpu-sharing-pool-2-0a984fed-7mff Ready <none> 4d v1.33.5-gke.2072000
Ollama Pod が実行されている場所を確認します。

# Ollama Pod を実行しているノードを確認する

kubectl get pods -n demo1 -o wide

kubectl get pods -n demo2 -o wide
両方の Ollama Pod が同じノードで実行されていることに注目してください。このノードは GKE Autopilot によってプロビジョニングされ、L4 GPU と GPU 共有を使用するように構成されています。

まとめ

この例では、GKE Autopilot を使用することで、GPU ノードプールやタイムシェアリングを手動で構成せずに済んでいます。Autopilot によってリソースが動的に提供される一方で、vCluster によって、チーム A の法務調査データとチーム B のカスタマーサポートの bot が完全に分離されています。この実装方法により、AI ワークロードのスケーリングにおいて堅牢でメンテナンスの少ないプラットフォームを実現できます。

- シニアクラウドデベロッパーアドボケイト、Abdel Sghiouar

- vCluster デベロッパーリレーションズ、 Saiyam Pathak

プロダクションレディな AI エージェントに関するデベロッパーガイド

Tue, 17 Mar 2026 00:00:00 +0000

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

この 1 年間で、デベロッパーコミュニティに変化が生じました。AI エージェントは、「興味深い研究コンセプト」から「チームが実際に構築しているもの」へと進化したのです。プロトタイプは機能しています。デモが示す可能性には目を見張るものがあります。ところが、ここで難題が持ち上がります。AI エージェントをどのようにリリースすればよいのでしょうか？

この問いは多面的です。エージェントは従来のソフトウェアのようには動作しません。推論し、行動し、適応するという性質から、エージェントにはテスト、メモリ、オーケストレーション、セキュリティに対して異なるアプローチが求められます。決定的なコードで有効だったパターンをそのまま適用することはできません。

開発者がこれらの課題を解決できるよう、Google はエージェントのライフサイクル全体を網羅したガイド集を公開しました。これらのリソースは、Kaggle の 5 日間 AI エージェント集中講座で初めて公開されました。そこで非常に高い人気と有用性が確認されたことから、より多くのユーザーに向けて公開する運びとなりました。

これらのガイドでは、実用的なフレームワークとコードサンプルが提供されており、自身のプロジェクトに合わせて柔軟に適用できます。以下では、エージェントのアーキテクチャから本番環境へのデプロイまで、主要なコンセプトを順を追って説明します。それに基づき、どのテーマについてより深掘りすべきかを判断してください。

エージェントとは

エージェントの中核をなすものは、推論、行動、経時的な改善を行う自律的なエンティティです。エージェントの頭脳は大規模言語モデルです。これは、タスクを理解し、回答を生成し、コンテキストに基づいて意思決定を行う認知エンジンです。エージェントは静的なツールとは異なり、動作する中で適応します。思考、行動、観察という再帰的なループに基づいて機能します。各サイクルでエージェントは進歩し、その過程でアプローチを洗練させます。

この中核の周囲にあるのがオーケストレーションレイヤであり、これは通信とデータフローを管理する神経系の役割を果たします。専門的なツールや外部サービスを調整する指揮者のようなものです。これには、即座に思い出すための短期記憶（セッションの状態）、過去のインタラクションを保持するための長期記憶（メモリサービス）、情報検索（RAG）、外部の世界でアクションを実行するためのモジュール（ツールの使用）などが含まれます。セキュリティフレームワークにより、エージェントが安全に、意図された境界内で動作することが保証されます。このアーキテクチャの目的は、インテリジェントで有用かつ信頼できるアシスタントを作成することです。

これらの基本コンセプトの詳細については、エージェントの概要に関するガイドをご覧ください。

ツールと相互運用性

エージェントが真に有用であるためには、ツール、データソース、他のエージェントとやり取りできる必要があります。2 つの新しいプロトコルが、そうした接続に対する標準化されたアプローチを提供します。

Anthropic の Model Context Protocol（MCP）により、エージェントは外部のデータソースやステートレスツールに標準化された方法で接続できます。デベロッパーは、サービスごとにカスタム統合を構築する代わりに、MCP の標準化されたインターフェースを使用して開発を簡素化し、相互運用性を向上させることができます。

Google の Agent2Agent プロトコル（A2A）はさらに一歩踏み込み、基盤となるフレームワークにかかわらずエージェント間の直接通信を可能にします。A2A を使用するエージェントは、安全かつ構造化されたメッセージの交換を通じて、互いの能力を把握し、やり取りの方法を交渉し、連携してタスクを処理します。

これらのプロトコルを組み合わせることで、ツール、データ、他のエージェントとの接続を通じてより広範なエコシステム内で動作するエージェントの基盤が構築されます。ツールと MCP による相互運用性に関するガイドでは、実装例とともにこれら 2 つのプロトコルについて詳しく説明しています。

コンテキストエンジニアリング

LLM がエージェントの脳であるとすれば、コンテキストエンジニアリングは、適切な情報を適切なタイミングで LLM に提供する手法です。これには、プロンプト設計、検索メカニズム、ツールの選択、会話履歴など、エージェントが各リクエストを理解して応答する方法を形作るすべてのものが含まれます。

コンテキストエンジニアリングにより、汎用モデルがパーソナライズされたアシスタントに変わります。コンテキストエンジニアリングは、どのメモリを取得するか、どのツールを提供するか、各インタラクションをどのように構成するかを決定します。効果的なコンテキストエンジニアリングにより、複数のセッションをまたいで一貫性を保持する有用なエージェントが作成されます。コンテキストエンジニアリングが実装されない場合、エージェントは記憶を忘却したり、同じことを繰り返したり、的外れな回答を返したりすることになります。

コンテキストエンジニアリングガイドでは、コンテキストエンジニアリングのフレームワークと実装のための実用的な手法について説明しています。

テストと評価

自律エージェントには、品質保証に対する新しいアプローチが必要です。エージェントが独自の判断を下す場合、その成否は正しい出力を生成できるかという点だけでなく、プロセス全体にわたって正しい判断ができているかという点にもかかっています。

エージェントを評価するにあたっては、最終的な回答の正しさだけでなく、エージェントが結果に至るまでに行う一連の意思決定と行動の軌跡に重点が置かれます。2 つのエージェントがまったく異なる経路で同じ結論に達する可能性があり、その経路を理解することが重要です。優れた評価では、ツールの選択、推論の質、エラー回復、エージェントが明確化のための質問をすべきときに質問したかどうかを調べます。

実用的な評価アプローチには、個々のコンポーネントの単体テスト、複数ステップの意思決定シーケンスの軌跡分析、サンドボックスからカナリア、本番環境への段階的な公開が含まれます。各ステージでは、より多くのユーザーに公開する前に、エージェントの動作のさまざまな側面を検証します。

評価フレームワークとテスト方法の詳細については、エージェントの品質ガイドをご覧ください。

エージェントの本番環境へのデプロイ

プロトタイプから本番環境に移行するには、エージェント固有のニーズに合わせて設計されたインフラストラクチャが必要です。状態を維持し、ツールを動的に使用し、自律的に動作するシステムを実現するには、従来型のデプロイパターンに適応性を持たせることが求められます。

本番環境のエージェントには、インタラクション全体でコンテキストを維持するためのセッション管理、長期記憶のための永続的なメモリシステム、適切な認証と権限によるツール統合、エージェントの意思決定とアクションを追跡するためのリアルタイムのロギングが必要です。

ほとんどのチームは、内部テスト用のサンドボックス、限定的な実環境でのテスト用のカナリア、完全なロールアウト用の本番環境という段階でデプロイします。各ステージでパフォーマンスを検証し、アクセスを拡大する前に問題を検出します。

プロトタイプから本番環境へのガイドでは、プロダクションレディなエージェントインフラストラクチャを構築するためのアーキテクチャに関するガイダンスとコードサンプルを提供しています。

出発点

どこから始めるべきかは、お客様の取り組みの段階によって異なります。エージェントの概要ガイドでは基本的なコンセプトを説明し、ツールと MCP による相互運用性やコンテキストエンジニアリングのガイドでは構築の実践的な課題を取り上げます。検証とリリースを行う準備ができた段階では、エージェントの品質とプロトタイプから本番環境へのガイドが役立ちます。

エージェントの分野は急速に進化していますが、一人で解決する必要はありません。現在の課題に合ったリソースを選んで、構築を始めましょう。

- テクニカルソリューションマネージャー、Kanchana Patlolla

- Google、シニアスタッフ ML エンジニア兼生成 AI 集中講座創設者、Anant Nawalgaria

RAG 対応生成 AI アプリケーションのプライベートネットワーク接続の設計

Fri, 13 Mar 2026 03:00:00 +0000

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

Google Cloud は柔軟性に優れており、企業が AI ワークロード向けに安全で信頼性の高いアーキテクチャを構築することを可能にします。この投稿では、検索拡張生成（RAG）対応生成 AI アプリケーションのプライベート接続のリファレンスアーキテクチャについて説明します。このアーキテクチャは、システム全体で通信にプライベート IP アドレスを使用する必要があるようなシナリオで、通信がインターネットを通過してはならないような場合に適しています。

RAG の効力

RAG は、大規模言語モデル（LLM）の出力を最適化するために使用されるパワフルな手法であり、LLM の出力を、元のトレーニングデータ以外の特定の信頼できるナレッジベースにグラウンディングできます。アプリケーションから RAG を使って、ドキュメント、データソース、データベースから関連情報をリアルタイムで取得することができます。ここで取得したコンテキストは、ユーザーのクエリとともにモデルに提供されます。これにより、AI の回答を正確で検証可能なものにするとともに、業務内容との関連性を高めます。この仕組みによって、回答の質が向上し、ハルシネーションが減少します。

このアプローチは、生成 AI においてモデルの既存の知識のみに依存することなく、指定された信頼できる情報源を使用できるため、モデル自体を再トレーニングやファインチューニングしなくて済むという点で利便性に優れています。

設計パターンの例

RAG アプリケーションのプライベート接続向けにネットワークを設定するということを念頭におきながら、このようなリージョン設計のパターンを見ていきましょう。

このネットワークは、外部ネットワーク（オンプレミスおよび他のクラウド）と Google Cloud 環境で構成されています。Google Cloud 環境は、ルーティングプロジェクト、RAG 用の共有 VPC ホストプロジェクト、3 つの特化したサービスプロジェクト（データ取り込み、サービング、フロントエンド）で構成されています。

この設計では、次のサービスを使用してエンドツーエンドのソリューションを提供します。

Cloud Interconnect または Cloud VPN: オンプレミスまたは他のクラウドからルーティング VPC ネットワークに安全に接続する
Network Connectivity Center: VPC スポークおよびハイブリッドスポークを介して、ルーティング VPC ネットワークと RAG VPC ネットワーク間の接続を管理するオーケストレーションフレームワーク
Cloud Router: ルーティングプロジェクト内で、外部ネットワークと Google Cloud 間の動的な BGP ルート交換を行う
Private Service Connect: ルーティング VPC ネットワークにプライベートエンドポイントを提供し、パブリックインターネットを経由せずに Cloud Storage バケットにアクセスしてデータを取り込めるようにする
共有 VPC: 複数のサービスプロジェクトで、共通の一元的な VPC ネットワークを使用できるようにするホストプロジェクトアーキテクチャ
Google Cloud Armor とアプリケーション ロードバランサ: フロントエンドサービスプロジェクトに配置され、ユーザーインタラクションに対してセキュリティとトラフィック管理を提供する
VPC Service Controls: すべてのリソースの周囲にマネージドセキュリティ境界を作成し、データ漏洩のリスクを軽減する

トラフィックフロー

RAG の挿入フロー

上の図の緑色の点線が RAG の挿入フロー（データエンジニアからベクトルストレージへとデータが移動する仕組み）を表しています。

外部ネットワークからのデータが、Cloud Interconnect または Cloud VPN 経由で渡されます。
ルーティングプロジェクト内の Private Service Connect エンドポイントを使って Cloud Storage バケットにアクセスします。
データ取り込みサービスプロジェクト内のデータ取り込みサブシステムが Cloud Storage バケットからの元データを処理します。
AI モデルがチャンクからベクトルを作成し、データ取り込みサブシステムに返します。データ取り込みサブシステムはこれを受け、サービングサービスプロジェクトの RAG データストアに書き込みます。

推論フロー

上の図のオレンジ色の点線が推論フロー（お客様またはユーザーのリクエスト）を表しています。

リクエストは、Cloud Interconnect または Cloud VPN 経由でルーティング VPC ネットワークに渡され、その後、VPC スポーク経由で RAG VPC ネットワークに渡されます。
リクエストは、Cloud Armor で保護されたアプリケーションロードバランサ に到達し、許可されるとフロントエンドサブシステムに渡されます。
フロントエンドサブシステムはリクエストをサービングサブシステムに転送します。サービングサブシステムは、RAG データストアのデータでプロンプトを拡張し、AI モデルを介して回答を生成します。
上記によってグラウンディングされた回答が、リクエスト元に同じパスで返されます。

管理とルーティング

上の図の青い点線は、Network Connectivity Center のハイブリッドスポークと VPC スポークが、ルーティングネットワークと RAG VPC ネットワーク間のコントロールプレーンとルートオーケストレーションを管理する様子を表しています。これにより、外部ネットワークから学習したルートが環境全体に適切に伝播されます。

IAM 権限、VPC Service Controls、デプロイに関する考慮事項などについて詳しくは、アーキテクチャドキュメント「RAG 対応生成 AI アプリケーションのプライベート接続」をお読みください。

次のステップ

クロスクラウドネットワークの詳細や、RAG を使用した生成 AI に関する以下のガイドをご覧ください。

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

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

エージェント型 chatbot に高速で信頼性の高い長期メモリを提供

Thu, 12 Mar 2026 00:00:00 +0000

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

会話エージェントを大規模展開する際は、データレイヤの設計が成否を左右することが少なくありません。数百万人規模のユーザーを支えるには、会話の継続性が欠かせません。つまり、応答性の高いチャットを維持しつつ、バックエンドのモデルが必要とするコンテキストも保ち続ける能力です。

この記事では、Google Cloud のソリューションを用いて、AI の 2 つのデータ課題（リアルタイムチャットのコンテキスト更新を高速化すること、長期履歴の検索を効率化すること）をどう解決するかをご紹介します。また、Redis、Bigtable、BigQuery を組み合わせるポリグロットなアプローチにより、直近のやり取りから数か月前のアーカイブまで、エージェントが細部と文脈の連続性を保てるようにする方法も解説します。

短期、中期、長期の履歴に対応するポリグロットストレージアプローチ

ポリグロットアプローチとは

ポリグロットアプローチとは、単一のデータベースに集約するのではなく、用途に特化した複数のデータサービスを組み合わせ、データのライフサイクルに応じて使い分ける多層型のストレージ戦略です。これにより、たとえば、高速化のためのインメモリキャッシュ、大規模データを扱うための NoSQL、非構造データを置くための Blob ストレージ、分析のためのデータウェアハウスといったように、それぞれの強みを活かしながら、データの「鮮度」や量に応じて効率的に処理できます。

短期、中期、長期メモリに対する Google Cloud での定義例

会話の継続性を保つため、Google Cloud 上では次のように組み合わせて、このポリグロットアプローチを実装できます。すなわち、ミリ秒未満で「ホット」なコンテキストを取得する用途には Memorystore for Redis を、永続的な履歴を蓄積するペタバイト規模の記録基盤には Cloud Bigtable を、長期アーカイブや分析的な洞察には BigQuery を用います。また、画像や音声などの非構造マルチメディアは Cloud Storage で扱い、Pub/Sub と Dataflow による非同期パイプラインで連携させます。

1. 短期メモリ: Memorystore for Redis

ユーザーは、新しいチャットを開始する場合でも、以前の会話を続ける場合でも、チャット履歴が瞬時に読み込まれることを期待しています。会話のコンテキストについては、Memorystore for Redis が主要なキャッシュとして機能します。フルマネージドのインメモリデータストアである Redis は、自然な会話の流れを維持するために必要なサブミリ秒レベルの低レイテンシを提供します。チャットセッションはメッセージが順次追加されていくリスト構造のため、履歴は Redis リストを使って保存します。ネイティブの RPUSH コマンドを使えば、アプリケーションは最新のメッセージだけを追加すればよく、Memcached のような単純なストアで発生しがちな「読み取り → 更新 → 書き込み」というネットワーク負荷の大きい処理を避けることができます。

2. 中期メモリ: Cloud Bigtable

会話が時間とともに増えていくにつれ、エージェント型アプリケーションは、増え続けるチャット履歴をより大規模に、かつ長期的に保存できる設計を考える必要があります。そこで、Bigtable が、永続性を備えた中期ストアとして、また全チャット履歴の正式な記録として機能します。Bigtable は、高速で書き込みが集中するワークロード向けに設計されたペタバイト級の NoSQL データベースで、数百万件の同時チャットを取り込む用途に適しています。大量のデータを扱いつつも、ガベージコレクションポリシーを設定すれば、アクティブなクラスタを必要最小限に保てます。たとえば、高性能ティアには直近 60 日分だけ残すといった運用が可能です。検索を高速化するため、キーは user_id#session_id#reverse_timestamp というパターンで設計します。これにより、同一セッションのメッセージが近接して格納され、範囲スキャンで直近のメッセージを効率よく取り出せるため、履歴の再読み込みがスムーズになります。

3. 長期メモリと分析: BigQuery

アーカイブと分析のため、データは BigQuery に移されます。BigQuery は、このシステムにおける長期メモリの役割を担います。Bigtable が稼働中のアプリケーション向け処理に最適化されているのに対し、BigQuery は大規模な複雑 SQL クエリを実行するために設計された Google のサーバーレス型データウェアハウスです。これにより、チームは単なるログ保存にとどまらず、そこから分析的なインサイトを引き出せるようになります。最終的には、この運用データがフィードバックループとして機能し、ユーザー向けコンポーネントのパフォーマンスに影響を与えることなく、エージェントやユーザー体験の改善につながります。

4. アーティファクトストレージ: Cloud Storage（GCS）

ユーザーが分析のためにアップロードしたものでも、生成モデルが生成したものでも、画像や音声などの非構造データ（マルチメディアファイル）は、非構造アーティファクトの保管に適した Cloud Storage に格納します。ここではポインタ戦略を採用します。Redis や Bigtable のレコード側には、実体データそのものではなく、オブジェクトを指し示す URI（例: gs://bucket/file）を保持します。セキュリティ面では、アプリケーションが署名付き URL を使ってファイルを配信し、バケットを公開することなく、クライアントに期限付きのアクセス権だけを付与します。

データの流れを最適化するハイブリッド同期 / 非同期戦略

以下のシーケンス図で示すとおり、このハイブリッド同期 / 非同期戦略では、前述のストレージ群を組み合わせることで、高速で整合性のある処理と耐久性のある永続化を両立させます。

次の図は、ユーザーのメッセージと、それに対応するエージェントの応答が、アーキテクチャ内をどのように流れていくかを示しています。

次の図は、ユーザーが特定のセッションのチャット履歴を取得する際に、データがアーキテクチャ全体をどのように流れるかを示しています。

今すぐ構築を開始

堅牢な永続化レイヤを備えたエージェントを構築する準備はできていますか？

エージェントをすばやく構築: Vertex AI Agent Builder を使って、エージェント型ワークフローのプロトタイピングを始めましょう。
キャッシュを構成する: レイテンシと可用性の要件に合わせて、最適な Memorystore for Redis の構成を決定します。
堅牢な Bigtable スキーマを設計する: スキーマ設計のベストプラクティスを確認しましょう。
分析へつなぐ: Bigtable の Change Stream から BigQuery へのテンプレートを活用し、ライブチャットログを実用的なビジネスインサイトへと変換します。
分析でデータを活用する: Looker Conversational Analytics を使って、ビジネスインテリジェンスに基づいたプロダクトの意思決定を行いましょう。

- AI ソリューションアクセラレーションアーキテクト Aishwarya Prabhat

- プリンシパルアーキテクト Yun Pang

Java SDK「MCP ツールボックス」リリースのお知らせ

Tue, 10 Mar 2026 02:00:00 +0000

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

エンジニアリングチームは、単純な chatbot から、ミッションクリティカルなデータベースと直接やり取りするエージェントシステムの構築へと移行しています。しかし、このようなエンタープライズエージェントを構築する際には、カスタムのグルーコード、脆弱な API、複雑なデータベースロジックという統合の壁にぶつかることがよくあります。

これらのハードコードされたボトルネックをセキュアで統合されたコントロールプレーンに置き換えるために、このたび、「データベース向け Model Context Protocol（MCP）ツールボックス」Java SDK をリリースしました。このリリースにより、世界で最も広く採用されているエンタープライズエコシステムで、最高水準の型安全なエージェントオーケストレーションが実現します。Java の成熟したアーキテクチャは、このような厳しい要求に対応できるよう構築されており、本番環境でミッションクリティカルな AI エージェントを安全にスケールするために必要な高い同時実行性、厳格なトランザクションの整合性、堅牢な状態管理を提供します。

MCP: AI エージェント向けの USB Type-C

Model Context Protocol（MCP）は、AI のユニバーサルトランスレータのようなものです。

MCP は、AI モデルが外部のツールやデータセットに接続する方法を標準化するために作成されており、カスタムの断片的な統合スクリプトをセキュアなユニバーサルプロトコルに置き換えます。エージェントがトランザクション SQL クエリの実行、数千ものポリシードキュメントの検索、REST API のトリガーなどを行うときに、MCP が単一の統合インターフェースを提供します。

データベース向け MCP ツールボックスを使用すると、このプロトコルの実装が簡単になります。

データベース向け MCP ツールボックス

データベース向け MCP ツールボックスは、データベース用のオープンソース MCP サーバーです。AlloyDB、Cloud SQL、Cloud Spanner をはじめ、サードパーティを含む 42 種類のデータソースをネイティブにサポートしています。重要なのは、AI エージェントの自然言語の意図を特定のデータベース操作に直接、安全にマッピングするカスタムツールを定義できることです。これにより、接続プーリングや認証などの複雑な処理に対応して、ツールの開発をより簡単、迅速、セキュアに行うことができます。

Python、JavaScript、TypeScript、Go 向けの堅牢かつプロダクションレディな SDK はすでに提供していました。しかし、高い同時実行性、トランザクションの整合性、会話の状態管理が不可欠な Day 2（2 日目からの）本番環境ワークロードに関しては、Java と Spring Boot が依然として圧倒的な存在です。

この新しい Java SDK を使用すると、好みの技術スタックから離れることなく、ステートフルで同時実行性の高いマルチエージェントシステムをネイティブに構築できます。この SDK は、場合によってはエンタープライズアーキテクトにとって最優先事項となる、最高水準の型安全なオーケストレーションを Java にもたらします。

この Java SDK を使ってみる

「MCP ツールボックス」Java SDK は、企業チームがスムーズに利用できるように設計されています。今すぐエージェントの構築を開始できます。

依存関係の追加

MCP ツールボックスは、pom.xml に次の依存関係を追加するだけで、Java または Spring Boot のプロジェクトに組み込むことができます。

code_block: <ListValue: [StructValue([('code', '<dependency>\r\n <groupId>com.google.cloud.mcp</groupId>\r\n <artifactId>mcp-toolbox-sdk-java</artifactId>\r\n <version>0.2.0</version>\r\n</dependency>'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f39d0a45a30>)])]>

これで準備は完了です。以下のエンタープライズグレードのユースケース例でも同じ操作を行っています。

実際の例: 自律型の交通機関コンシェルジュ

「MCP ツールボックス」Java SDK を AlloyDB と組み合わせて活用する例として、交通機関のユースケースを見てみましょう。

Cymbal Transit は架空の都市間バス交通ネットワークです。利用者は、旅行を計画するのに、15 個ものプルダウンメニューをクリックしたくはありません。次のように質問できれば理想的です。

「明日の朝、ニューヨークからボストンまで移動する必要があります。ゴールデンレトリバーを連れて行くことはできますか？できる場合は、最も早い便を予約して。」

AI エージェントがこの質問に答えるには、非構造化データ（ペットに関するポリシー）と構造化データ（運行スケジュール、座席の空き状況）をシームレスに相互参照し、会話のコンテキストを記憶しながらトランザクション（予約）を実行する必要があります。

このケースは、「MCP ツールボックス」Java SDK を使用して次のように構築します。

基盤となるデータベース（ネイティブエンベディングを備えた AlloyDB スキーマ）

AlloyDB は、リレーショナルデータと高次元の AI ベクトルを単一のクエリエンジンで処理するため、この目的に最適なエンジンです。AlloyDB はさらに、google_ml_integration 拡張機能を使用してエンベディングをネイティブに生成できるため、構築する Java アプリケーションとエンベディング API との間でテキストをやり取りする必要がありません。

まず、こちらのクイック設定ラボに沿って、AlloyDB のクラスタとインスタンスを設定します。

次に、以下の SQL ステートメントを使用してデータベースオブジェクトを設定します。

code_block: <ListValue: [StructValue([('code', "-- AI セマンティック検索とエンベディング生成に必要な拡張機能を有効にする\r\nCREATE EXTENSION IF NOT EXISTS vector;\r\nCREATE EXTENSION IF NOT EXISTS google_ml_integration;\r\n\u200b\r\n-- 表 1: 交通機関のポリシー（RAG 用の非構造化データ）\r\nCREATE TABLE transit_policies (\r\n policy_id SERIAL PRIMARY KEY,\r\n category VARCHAR(50),\r\n policy_text TEXT,\r\n policy_embedding vector(768)\r\n);\r\n\u200b\r\n-- 表 2: 都市間バスの運行スケジュール（構造化データ）\r\nCREATE TABLE bus_schedules (\r\n trip_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),\r\n origin_city VARCHAR(100),\r\n destination_city VARCHAR(100),\r\n departure_time TIMESTAMP,\r\n arrival_time TIMESTAMP,\r\n available_seats INT DEFAULT 50,\r\n ticket_price DECIMAL(6,2)\r\n);\r\n\u200b\r\n-- 表 3: 予約台帳（トランザクションアクションデータ）\r\nCREATE TABLE bookings (\r\n booking_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),\r\n trip_id UUID REFERENCES bus_schedules(trip_id),\r\n passenger_id VARCHAR(100),\r\n status VARCHAR(20) DEFAULT 'CONFIRMED',\r\n booking_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f39d0a45d60>)])]>

テーブルを定義し、ベクトルサポートを有効にしたことで、AlloyDB が構造化されたトランザクションデータとセマンティックナレッジベースの両方に対応する統合ブレインとして機能する準備が整いました。

レコードの取り込みと現実的なエンベディングの生成

エージェントのコンテキストウィンドウで推論に使用できる現実的なオプションを確保するには、堅牢なデータセットが必要です。AlloyDB で PostgreSQL の強力な generate_series を使用すると、翌日以降の現実的なバス旅行のデータ 200 件以上を即座にデータベースに供給できます。このデモアプリケーションのモックデータの取り込みには、このアプローチを採用しました。

code_block: <ListValue: [StructValue([('code', '-- 1. AlloyDB で非構造化ポリシーを挿入し、現実的なエンベディングをネイティブに生成する\r\nINSERT INTO transit_policies (category, policy_text, policy_embedding)\r\n...（完全なステートメントはリポジトリを参照）\r\n\u200b\r\n-- 2. generate_series を使用して、今後 7 日間の現実的なスケジュールを 200 件以上生成する\r\nINSERT INTO bus_schedules (origin_city, destination_city, departure_time, arrival_time, ticket_price, available_seats)\r\n...（完全なステートメントはリポジトリを参照）'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f39d0a45d00>)])]>

完全なコードについては、リポジトリをご覧ください。

このようにして、現実的なスケジュールとネイティブに生成されたエンベディングがデータベースに動的に入力され、AI エージェントはデータが豊富でクエリ可能な環境に即座にアクセスできるようになります。

Spring Boot のステートフルエージェントアーキテクチャ

会話型 UI の構築で最も難しいのはセッション管理です。ユーザーが「空いている時間は？」と尋ねた後、「午前 8 時の便を予約して」と言った場合、エージェントはコンテキストを覚えている必要があります。

「MCP ツールボックス」Java SDK を Spring Boot、LangChain4j と併せて使用すると、HTTP セッションで会話の記憶をシームレスに維持し、エージェントの思考プロセスに注入できます。最新のフロントエンドと、このステートフルバックエンドを組み合わせることで、エンタープライズアプリケーションは連続的でインテリジェントなワークスペースになります。

ユーザーの意図を解析するために大量の if / else ブロックを記述する代わりに、宣言型の AI インターフェースを定義し、それに MCP ツールをバインドするだけです。詳細なクエリをハードコードしたり、静的な条件コードのブロックを追加したりすることなく、オーケストレーションのロジックをコードに組み込むことがいかに簡単かを示します。

code_block: <ListValue: [StructValue([('code', 'interface TransitAgent {\r\n @SystemMessage({\r\n "You are the Cymbal Transit Concierge.",\r\n "Use the \'querySchedules\' tool for finding schedules.",\r\n "Use \'bookTicket\' to execute transactions.",\r\n "Use \'searchPolicies\' to look up luggage and pet rules."\r\n })\r\n String chat(@MemoryId String sessionId, @UserMessage String userMessage);\r\n}\r\n\u200b\r\n@Service\r\nclass TransitAgentTools {\r\n // これらのメソッドは、データベース向け MCP ツールボックスサーバーを自動的に呼び出します。\r\n @Tool("Query specific schedules between an origin and destination city.")\r\n public String querySchedules(String origin, String destination) { ... }\r\n\u200b\r\n @Tool("Book a ticket for a passenger.")\r\n public String bookTicket(String tripId, String passengerName) { ... }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f39d0a45070>)])]>

LangChain4j により、LLM プロンプトのロジックが実際のツールの実行から明確に分離されるため、エージェントは目標を失うことなく、予測可能で、時間が経過しても非常に簡単にメンテナンスできる状態が維持されます。最新のフロントエンドと、このステートフルな Spring Boot バックエンドを組み合わせることで、エンタープライズアプリケーションは、つながりのない一連のプロンプトではなく、連続的でインテリジェントなワークスペースになります。

意図と SQL のマッピング: tools.yaml

データベース向け MCP ツールボックスの真の魅力は、これらのカスタムツールの定義方法にあります。Java アプリケーションは SQL に直接アクセスする必要がなく、LLM はテーブルスキーマに関してハルシネーションを起こす必要がありません。代わりに、MCP サーバーにクリーンな tools.yaml 構成を提供します。このファイルは、エージェントのツール呼び出しを AlloyDB のパラメータ化された SQL ステートメントにセキュアにマッピングします。

code_block: <ListValue: [StructValue([('code', 'tools:\r\n query-schedules:\r\n kind: postgres-sql\r\n source: alloydb\r\n description: Find available bus schedules between cities.\r\n parameters:\r\n - name: origin\r\n type: string\r\n - name: destination\r\n type: string\r\n statement: |\r\n SELECT CAST(trip_id AS TEXT) AS trip_id, departure_time, ticket_price\r\n FROM bus_schedules\r\n WHERE lower(origin_city) = lower($1) AND lower(destination_city) = lower($2)\r\n\u200b\r\n search-policies:\r\n ... 完全な tools.yaml については、リポジトリを参照してください'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f39bcbe28e0>)])]>

このシンプルな宣言型構成により、データベーススキーマを LLM に直接公開することなく、自然言語の意図と複雑な SQL クエリのギャップを埋めることができます。

点と点をつなぐ: Java でのツールのリスト表示、呼び出し、実行

データベースとツールを構成したら、それらとのやり取りという手間のかかる作業は、「MCP ツールボックス」Java SDK が処理します。この SDK は、直感的で型安全な API を提供し、Spring Boot サービスからトランザクションをセキュアに検出、クエリ、実行できます。

code_block: <ListValue: [StructValue([('code', '// 1. クライアントの初期化\r\nMcpToolboxClient mcpClient = McpToolboxClient.builder()\r\n .baseUrl("https://toolbox-my-project-uc.a.run.app")\r\n .apiKey(myIdToken)\r\n .build();\r\n\u200b\r\n// 2. 検出可能なツールのリスト表示\r\nmcpClient.listTools().thenAccept(tools -> {\r\n System.out.println("Successfully discovered " + tools.size() + " tools.");\r\n});\r\n\u200b\r\n// 3. ツールの呼び出し（読み取り専用データ）\r\nString schedules = mcpClient.invokeTool("query-schedules", Map.of(\r\n "origin", "New York",\r\n "destination", "Boston"\r\n)).join().content().get(0).text();\r\n\u200b\r\n// 4. トランザクションツールの実行（バインドされた認証が必要）\r\nAuthTokenGetter toolAuthGetter = () -> CompletableFuture.completedFuture(myIdToken);\r\n\u200b\r\nString bookingConfirmation = mcpClient.loadTool("book-ticket", Map.of("google_auth", toolAuthGetter))\r\n .thenCompose(tool -> {\r\n // 認証されたユーザーコンテキストをセキュアにバインドする\r\n tool.bindParam("passenger_name", "Jane Doe");\r\n // 可変トランザクションを実行する\r\n return tool.execute(Map.of("trip_id", "123e4567-e89b-12d3-a456-426614174000"));\r\n }).join().content().get(0).text()'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f39bcbe22e0>)])]>

これで完了です。型安全な Java のコード数行で、Spring Boot アプリケーションがローカルメソッドかのようにリモートツールをセキュアに検出して実行します。上の bindParam メソッドに注目してください。この強力な機能を使用すると、アプリケーションレベルのコンテキスト（認証されたユーザーの ID など）をデータベーストランザクションにセキュアに直接挿入し、LLM を完全にバイパスできます。詳しくは、「MCP ツールボックス」Java SDK のドキュメントをご覧ください。

アプリケーションのデフォルト認証情報（ADC）によるゼロ構成のセキュリティ

ハードコードされたシークレットや JSON キーの管理が不要であることに注目してください。Java アプリケーションは、Google のアプリケーションのデフォルト認証情報（ADC）を使用して、バックグラウンドで myIdToken を取得することで、環境から直接、セキュアな ID を自動的に継承します。gcloud CLI を使用してローカルで開発する場合でも、本番環境で実行する場合でも、アプリケーションはデフォルトでセキュアに保たれ、手動で認証情報を構成する必要がありません。

フリートを Cloud Run にデプロイ

先ほど説明した「2 日目」のエンタープライズ要件を覚えているでしょうか。高い同時実行性、トランザクションの整合性を適切に処理し、ステートフルな会話を大規模に維持するには、アーキテクチャが堅牢である必要があります。データベース向け MCP ツールボックスと Spring Boot エージェントは完全に分離されているため、Google Cloud Run で個別にスケーリングして、これらの正確な需要に対応できます。

まず、オープンソースのデータベース向け MCP ツールボックスを独自のセキュアなサービスとしてデプロイします。

code_block: <ListValue: [StructValue([('code', '# ツールボックスの CLI をダウンロードする\r\nexport VERSION=0.27.0\r\ncurl -L -o toolbox https://storage.googleapis.com/genai-toolbox/v$VERSION/linux/amd64/toolbox\r\nchmod +x toolbox'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f39bcbe2880>)])]>

次に、ローカルのツールボックスサーバーを Cloud Run にデプロイします。公式ドキュメントのこちらの手順に沿って操作します。

ツールボックスは、稼働状態になると、データベースと外部の世界との間のセキュアでスケーラブルなブリッジとして機能します。

次に、Java Spring Boot エージェントをデプロイし、動的に生成された MCP ツールボックスの URL と Vertex AI の設定を環境変数として挿入します。

Cymbal Transit エージェントアプリは次の手順で設定します。

リポジトリのクローンを作成します。
次に、Java Spring Boot エージェントをデプロイし、動的に生成された MCP ツールボックスの URL と Vertex AI の設定を環境変数として挿入します。

code_block: <ListValue: [StructValue([('code', 'gcloud run deploy cymbal-transit \\\r\n --source . \\\r\n --allow-unauthenticated \\\r\n --set-env-vars GCP_PROJECT_ID=my-project,GCP_REGION=us-central1,GEMINI_MODEL_NAME=gemini-2.5-flash,MCP_TOOLBOX_URL=https://toolbox-...'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f39bcbe24f0>)])]>

たった 1 つのコマンドで、ステートフルなマルチエージェントのエンタープライズアプリケーションが Cloud Run にデプロイされ、ユーザーに代わってワークフローをセキュアにオーケストレートする準備が整いました。

統合をハードコードする時代は終了

ステートレスな chatbot から自律型のトランザクションエージェントへの移行は、この 10 年間の技術的変化を象徴するものです。しかし、エージェントの能力は、セキュアにやり取りできるシステムによって決まります。

「データベース向け MCP ツールボックス」Java SDK を使用することで、企業開発者はようやく、ネイティブでエレガントかつスケーラビリティの高い方法で、ビジネスを運営するミッションクリティカルな記録システムに対する読み取り / 書き込みアクセスを AI エージェントに付与できるようになります。

独自のステートフルなエンタープライズエージェントを構築する準備はできましたでしょうか。まず、「MCP ツールボックス」Java SDK の公式 GitHub リポジトリをご覧ください。また、デモアプリケーション、Cymbal Bus エージェントの GitHub リポジトリで完全なソースコードを確認し、今すぐお試しください。

- Google スタッフデベロッパーアドボケイト Abirami Sukumaran

- Google ソフトウェアエンジニア、Anubhav Dhawan

データ戦略 = AI 戦略シリーズ: Google Cloud で開発者を AI アーキテクトに進化させる

Tue, 10 Mar 2026 02:00:00 +0000

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

エージェントの性能は、データによるグラウンディングの質に左右されます。データが整理されていないと、エージェントは高い確信度で回答していても、実際にはハルシネーションを起こしている可能性があります。2026 年には、データ戦略と AI 戦略は実質的に同じものになります。どちらか一方だけでは成り立ちません。

このシリーズ「データ戦略 = AI 戦略」では、この戦略のさまざまな側面を取り上げ、自律エージェントを構築しながら、より決定論的なワークフローを設計する方法をご紹介します。本投稿は、データと AI アーキテクチャの融合に焦点を当てたシリーズの第 1 回です。

業界は重要な転換点を迎えつつあります。2024 年と 2025 年は「API 時代」と定義され、開発者はアプリやエンドポイントを通じて LLM を統合する方法を学びました。2026 年には、エンタープライズアーキテクチャへの移行が求められます。本番環境に対応したアプリケーションを構築するには、プロンプトを書く段階から、インテリジェントなエンドツーエンドのスタックを設計する段階へと移行する必要があります。

課題は、使用する AI モデルだけではありません。それを支えるインフラストラクチャも重要です。アプリケーションがエンタープライズグレードであるためには、スピード、スケール、セキュリティという 3 つの重要な柱の要件を満たす必要があります。本記事では、AI の導入を目的としたエージェントの構築から、十分に戦略化されたコンテキストに基づくエージェントの設計へと移行するという観点から、これらの柱に焦点を当てます。具体的には、このブログとリンク先の Codelab において実践的な学習プログラムを提供し、Google のデータクラウドを活用してアーキテクチャを構築する方法を示します。このアプローチでは、PostgreSQL と完全互換のリレーショナルデータベースを使用します。

戦略的転換: コンテキストエンジンとしてのデータベース

最新の AI スタックでは、データベースはもはや単なるストレージレイヤではなく、コンテキストエンジンとしての役割を担うようになっています。Google の戦略は、AlloyDB for PostgreSQL や Cloud SQL など、PostgreSQL と完全互換のサービスを活用し、本番環境における AI の主なボトルネックであるレイテンシ、AI 機能、検索精度を解消することに重点を置いています。

この学習プログラムでは、開発者からアーキテクトへの移行を支援するために、インフラストラクチャに伴う負担を減らし、高レベルのアーキテクチャ設計に集中できるようにすることを重視しています。

1. インフラストラクチャ税の解消

これまで、ローカルでのプロトタイピングからクラウド規模のデプロイへ移行する際には、「インフラストラクチャ税」とも呼ばれる問題が大きな障壁となっていました。これは、クラスタ、インスタンス、VPC ネットワークピアリングの設定などに多くの時間を費やさなければならないことを指します。自動設定ユーティリティを導入することで、開発者はこうした構成上の障壁を回避できるようになります。

その結果、焦点はインフラストラクチャの管理から、安全なデータフローや高スループットのベクトルパイプラインの設計へと移ります。最近開催されたインストラクター主導の Code Vipassana セッションでは、参加した開発者が、この変化により、各ラボで 1 時間以上の時間を節約できました。このアプローチにより、本番環境への移行を効果的に加速できます。

2. スケーラビリティを前提とした設計: 100 万ベクトル、ループなし

エンタープライズアーキテクチャを構築するには、小規模なデモの段階を超える必要があります。そのため、ベクトル検索を高速化するために、エンベディングのバッチ処理に重点を置いています。AlloyDB では、データベースレイヤ内でエンベディングを大規模に直接生成できます。この機能を活用することで、従来のループ処理に伴うレイテンシを解消し、大規模なデータセットに対してリアルタイム分析を行えるようになります。

3. ソブリンインテリジェンスと行レベルセキュリティ（RLS）

AI におけるセキュリティは、単にファイアウォールを設ければよいというものではなく、データガバナンスまで含めて考える必要があります。そのため Google は、アクセスが許可された特定のデータのみにアクセスするように AI エージェントを制御する仕組みとして、行レベルのセキュリティ（RLS）の活用を重視しています。このプライベート Vault アーキテクチャは、データの分離が不可欠な規制業種において特に重要です。たとえば、ユーザーがエージェントと対話する中で、他のユーザーに関する情報やベンチマーク情報まで知ることができてしまう状況を想像してみてください。データレベルのセキュリティをデータベースに組み込むことは、もはや任意ではありません。誰に何を知らせるべきかという判断を、エージェント任せにすることはできません。

アーキテクチャ学習プログラム

Google は、エンタープライズ AI 開発の全体像を体系的に理解できるよう、一連のハンズオン形式の技術ラボを用意しました。各ラボは、インテリジェントスタックを構成する特定のレイヤに対応しています。

多くのラボでは AlloyDB を使用します。ただし、このアーキテクチャ戦略の流れは Cloud SQL のエコシステムにも広がっています。そのため、この学習プログラムには Cloud SQL for PostgreSQL ユーザー向けの代替ラボもいくつか含まれています。

推奨される学習プログラムには、次のコアアーキテクチャラボが含まれています。

AlloyDB クイックセットアップラボこのラボは、必要な VPC とネットワーク設定を備えた高性能な AlloyDB クラスタを数分でプロビジョニングする方法を紹介するアーキテクト向けの入門ラボです。ここでは、後続のすべての AI ロジックのための安全でスケーラブルな基盤を確立するための「デイゼロ」オペレーションに焦点を当てます。
アプリを AlloyDB データに接続して Cloud Run にデプロイする（または Cloud SQL に接続して Cloud Run にデプロイする）デプロイの段階に進み、このラボではサーバーレスアプリケーションのアーキテクチャを取り上げます。開発者は、セキュリティ向上のためにマネージド ID や接続文字列を活用しながら、Cloud Run サービスを AlloyDB（または Cloud SQL）に接続する方法を学びます。このアプローチにより、アプリケーションレイヤもデータレイヤと同様に堅牢な構成にすることができます。
リアルタイム余剰エンジンを構築する: Gemini 3 Flash と AlloyDB（または Gemini 3 Flash と Cloud SQL）このラボでは、エンドツーエンドのデータドリブン AI アプリケーションを構築し、スピードの柱に対応します。高効率な Gemini 3 Flash モデルを用いてストリーミングデータを処理し、リアルタイムのインサイトを生成する方法をご紹介します。このアプローチにより、データベースとエンドユーザーの間に応答性の高いフィードバックループが構築されます。
100 万ベクトル、ループなし: AlloyDB によるスケーリングスケールに焦点を当てたこのラボでは、ベクトル検索のプロセスについて詳しく説明します。アーキテクトは、データベース内でエンベディングのバッチ処理を直接実装する方法を学びます。このアプローチにより、アプリケーションレイヤのボトルネックを回避し、エンタープライズグレードのパフォーマンスで数百万規模のベクトルの取り込みと検索を実現できます。
プライベート Vault: RLS によるゼロトラストインテリジェンスアーキテクチャのパズルの最後のピースは、セキュリティの強化に焦点を当てています。このラボでは、開発者向けにゼロトラストエージェントの構築方法をご紹介します。PostgreSQL で RLS を実装することで、AI エージェントがユーザーごとのデータ境界を確実に尊重する仕組みを構築できます。このアプローチは、セキュリティを強化しながらコンプライアンスにも対応した AI システムを設計するための指針となります。

未来をデザインする

インフラストラクチャの負担を減らし、スピード、スケール、セキュリティという基本原則に注力することで、新世代の AI アーキテクトを育成することができます。この戦略的な転換により、現在構築されているアプリケーションが、将来の本番環境の要件にも対応できるようになります。

今後開催されるインストラクター主導のハンズオンセッションに参加し、開発者からアーキテクトへのステップアップを始めたい方は、Code Vipassana にご登録ください。

- Google、スタッフデベロッパーアドボケイト Abirami Sukumaran

Gemini 3 Pro Image を使ってみる

Thu, 05 Mar 2026 00:00:00 +0000

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

前回の投稿では、AI の世界に少し足を踏み入れてみました。Gemini API キーを取得し、最初の「Hello World」AI アプリを構築しました。さらに、Google AI Studio のバイブコーディングを活用してウェブアプリを作成し、Cloud Run にデプロイしました。

しかし、Google Cloud プロジェクトを設定しないままパート 2 の [デプロイ] ボタンを押そうとすると、少し手間取ったかもしれません。Google Cloud プロジェクトを作成すれば、AI アプリのホスティングや大規模データセットの保存が可能になるほか、Nano Banana Pro（Gemini 3 Pro Image）をはじめとする Gemini Pro モデルの機能をフル活用できるようになります。

これらは無料で始められるうえ、試しに使えるクレジットも提供されます。この投稿では、Google Cloud 無料トライアルへの具体的な登録方法と、実際にどのような特典が受けられるのかを詳しく解説します。

Google Cloud アカウントが必要な理由

Google AI Studio はプロトタイピングやテストに最適な環境であり、アプリケーションを Cloud Run に直接デプロイすることもできます。しかし、アプリケーションが成長していくと、拡張や運用管理のために、より幅広い Google Cloud のサービスが必要になります。具体的には、次のようなサービスです。

ホスティング: 有効期限のない URL で AI アプリを公開したい場合。
ストレージ: ユーザーやアプリケーションのデータ、画像、ファイルを保存および検索できる場所が必要な場合。
コンピューティング: バックグラウンド処理を行うワーカーや仮想マシンが必要になる場合。
グローバルスケール: ソリューションを複数のリージョンにデプロイし、世界中のユーザーに高可用性と低レイテンシを確保したい場合。

Google Cloud はこうしたニーズに応えます。Google 検索や YouTube と同じインフラストラクチャをご自身のプロジェクトにも活用できます。

無料で利用できるもの

登録手続きに進む前に、まずは無料で利用できる内容を確認しておきましょう。Google Cloud の無料特典は、次の 2 つで構成されています。

300 ドル分のクレジット（無料トライアル） - 新規のお客様には、91 日間利用できる 300 ドル分の無料クレジットが提供されます。このクレジットは、さまざまな Google Cloud プロダクトにご利用いただけます。
Google Cloud の無料枠 - こちらは開発者にとって心強い制度です。トライアル期間が終了した後も、多くのサービスで毎月更新される無料利用枠が用意されています。利用上限の範囲内であれば、料金は発生しません。

無料枠の主な内容は次のとおりです。

Cloud Run: 1 か月あたり 200 万回の呼び出し（パート 2 で構築したアプリに最適です）。
Compute Engine: 1 か月あたり非プリエンプティブル e2-micro VM インスタンス 1 台（特定の米国リージョンのみ）。
Cloud Storage: 1 か月あたり 5 GB-月分の Regional Storage（米国リージョンのみ）。
BigQuery: 1 か月あたり 1 TiB のクエリ処理と 10 GiB のストレージ。
このほかにも、多くの無料枠が用意されています。

注: 利用上限や対象リージョンは変更される場合があります。最新情報については、無料枠の公式ドキュメントを必ずご確認ください。

ステップごとの登録手順

次の 2 つの条件をいずれも満たしている場合、無料トライアルをご利用いただけます。

これまでに Google Cloud、Google Maps Platform、または Firebase を有料で利用したことがない。
これまで無料トライアルに登録したことがない。

条件を満たしていることを確認できたら、次の手順に沿って進めていきましょう。

ステップ 1 - 開始する

cloud.google.com/free にアクセスします。[無料で利用開始] または [無料で開始] というボタンが表示されるはずです、

注: [無料で開始] ボタンが表示されない場合は、過去に Google Cloud アカウントを有効化している可能性があります。ただし、その場合でも無料枠は利用できます。

ステップ 2 - ログインする

Google アカウント（Gmail アドレス）でログインします。Google AI Studio で使用しているものと同じアカウントを使用できます。

注:「Google アカウント（ユーザー名@gmail.com）をすでにお持ちのようです。別のプロバイダのメールアドレスで新しいアカウントを作成するには、[キャンセル] をクリックしてください。」というメッセージが表示された場合は、[ログイン] をクリックして続行してください。

ステップ 3 - 利用規約に同意する

お住まいの国を選択します。これにより、使用する通貨や適用される利用規約が決まります。続行するには、利用規約に同意する必要があります。

注: スペシャルオファーなどに関するメールを定期的に受信することを希望する場合は、チェックボックスをオンにします。

ステップ 4 - 本人確認を行う

不安を覚えている方もいらっしゃるかもしれませんので、明確にしておきたいと思います。Google では本人確認と不正行為防止のために、クレジットカードなどのお支払い方法の登録を必須としています。

自動請求はありません: 無料トライアルが終了しても、自動的に課金されることはありません。トライアル終了後も引き続きリソースを利用するには、有料アカウントに手動でアップグレードする必要があります。

無料クレジットが付与される前に、銀行口座の確認の一環としてカードが使用される場合があります。確認方法は地域によって異なります。

続行するには、連絡先情報とお支払い方法を入力してください。

ステップ 5: 構築を始める

確認が完了するとコンソールが表示され、画面上部のバナーおよび [請求先アカウント] セクションに、300 ドル分の無料トライアルクレジット残高が表示されます。通常は「My First Project」などのデフォルトのプロジェクトが用意されており、そこから作業を開始できます。必要に応じて、新しいプロジェクトを作成することも可能です。

注: クレジット残高は、現地通貨で表示される場合があります。

AI Studio に戻る

課金が有効なプロジェクトを作成できたので、Google AI Studio に戻りましょう。有料 API キーの入力を求められた場合は、このプロジェクトを使用して Nano Banana Pro を利用できます。

新しいプロジェクトを Google AI Studio にインポートする

新しくインポートしたプロジェクトと連携する新しい API キーを作成する

新しい API キーで Nano Banana Pro を呼び出す

次のステップ

300 ドル分のクレジットと強力なクラウドプラットフォームをご利用いただけるようになりました。では、実際にどのようなものをビルドできるのでしょうか。次回の投稿では、これらを利用して次世代の AI アプリケーションやエージェントをビルドする例をいくつかご紹介します。

それまでの間は、ぜひ Google の豊富な Codelab ライブラリをご覧いただき、次のアイデアの実現に取り組んでみてください。

- リードデベロッパーリレーションズエンジニア、Remigiusz Samborski

Conversational Analytics API を使用して BigQuery で会話型エージェントを構築する

Wed, 04 Mar 2026 01:10:00 +0000

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

データを BigQuery に取り込むことで情報は一元化できますが、真の課題はそのデータを利用できるようにすることです。技術的な障壁のために、知りたいことがある人（経営幹部からアナリストまで）が必要な回答を得られない、ということが少なくありません。

Gemini を搭載した Conversational Analytics API を使用すれば、複雑なシステムを使わなくてもインサイトが得られます。この API は、自然言語を理解し、BigQuery データをクエリして、テキスト、テーブル、グラフで回答を提供する、コンテキスト認識型エージェントの構築を支援するよう設計されています。

現在、API と連携できるソリューションであれば、どのようなものでも構築できます。たとえば、Agent Development Kit（ADK）と統合してマルチエージェントシステムを構築したり、以下のようなデータ戦略を実装したりすることができます。

運用担当者向けのセルフサービストリアージ: サポートチームやセールスチームなどに、データに関する質問に即座に回答するエージェントを提供します。「Why did signups drop last week?（先週、登録者数が減ったのはなぜ？）」といった質問をチケットで問い合わせなくても、すぐに回答を得ることができます。
SaaS プロダクトを差別化: 優れたチャットインターフェースをプラットフォームに直接埋め込むことで、プラットフォームを差別化できます。お客様は平易な英語を使用して、独自の使用状況データをクエリ、可視化できます。
動的なレポート: 静的な PDF を超えるレポート機能です。核となるレポート機能を自動化し、レポートをリアルタイムの会話バージョンに効果的に置き換え、関係者が微妙なニュアンスのフォローアップの質問をしてより詳細な調査ができるようにします。

この投稿では、Conversational Analytics API を使用して BigQuery で会話型エージェントを構築する方法をご紹介します。

ステップ 1: エージェントを構成して作成する

データ分析エージェントをデプロイするには、最終的な作成呼び出しを行う前に、アクセス、コンテキスト、環境を構成する必要があります。

ご紹介する例では Python SDK を使用していますが、Conversational Analytics API はユーザーの好みや環境に応じて他の多くの言語にも対応しています。

クライアントを初期化し、BigQuery ソースを定義する

まず、API とのやり取りに必要なクライアント（DataAgentServiceClient）をインスタンス化します。このクライアントは、明示的な BigQueryTableReference オブジェクトと組み合わせて使用します。BigQueryTableReference オブジェクトは、エージェントが特定のテーブル（project_id、dataset_id、table_id で定義）にアクセスすることを承認します。こうした個々の参照は、bq フィールドの下の DatasourceReferences オブジェクトに集約されます。

code_block: <ListValue: [StructValue([('code', 'from google.cloud import geminidataanalytics\r\n\r\n# Set project-specific variables (client, location, project IDs)\r\ndata_agent_client = geminidataanalytics.DataAgentServiceClient()\r\nlocation = "global"\r\nbilling_project = "your-gcp-project-id"\r\ndata_agent_id = "google_trends_analytics_agent"\r\n\r\n# Define the BigQuery table sources\r\nbq_top = geminidataanalytics.BigQueryTableReference(\r\n project_id="bigquery-public-data", dataset_id="google_trends", table_id="top_terms"\r\n)\r\nbq_rising = geminidataanalytics.BigQueryTableReference(\r\n project_id="bigquery-public-data", dataset_id="google_trends", table_id="top_rising_terms"\r\n)\r\ndatasource_references = geminidataanalytics.DatasourceReferences(\r\n bq=geminidataanalytics.BigQueryTableReferences(table_references=[bq_top, bq_rising]))'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f39d3366790>)])]>

エージェントコンテキストを設定する

system_instruction（エージェントの動作 / ロールを定義）と datasource_references（エージェントがアクセスできるデータを定義）をバンドルして、コンテキストオブジェクトを構築します。完成したコンテキストは、最終オブジェクト DataAgent の DataAnalyticsAgent 構造体の中でネストされます。

文字列ベースのシステム指示を与えることもできますが、より堅牢なコンテキストオブジェクトを使用してエージェントに指示を与えることをおすすめします。さらに、オブジェクトに追加のシステム指示を与えて、補足ガイダンスを提供できるようにすることもできます。

code_block: <ListValue: [StructValue([('code', '# Set the context using our system_instruction string\r\npublished_context = geminidataanalytics.Context(\r\n system_instruction=system_instruction,\r\n datasource_references=datasource_references\r\n example_queries=example_queries\r\n)\r\n\r\ndata_agent = geminidataanalytics.DataAgent(\r\n data_analytics_agent=geminidataanalytics.DataAnalyticsAgent(\r\n published_context=published_context\r\n ),\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f39d3366f40>)])]>

エージェントを作成する

data_agent_client.create_data_agent を呼び出します。このリクエストには、親リソースパス（projects/{billing_project}/locations/{location}）、一意のdata_agent_id、デプロイを完了できるようにすべて構成された data_agent オブジェクトが含まれます。

code_block: <ListValue: [StructValue([('code', '# Create the agent\r\ndata_agent_client.create_data_agent(request=geminidataanalytics.CreateDataAgentRequest(\r\n parent=f"projects/{billing_project}/locations/{location}",\r\n data_agent_id=data_agent_id,\r\n data_agent=data_agent,\r\n))'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f39d3366b80>)])]>

これで、エージェントが作成され、published_context によって定義されます。

ステップ 2: 会話を作成する（ステートフルとステートレス）

Conversational Analytics API は、以下の 2 つの方法で会話を処理できます。

ステートレス: 質問とエージェントコンテキストを送信します。会話履歴は自身のアプリケーションで管理し、新しいリクエストごとに送信する必要があります。
ステートフル: サーバーで「会話」を作成します。API が履歴を管理します。これにより、ユーザーはフォローアップの質問をすることができます。

ここでは、ステートフルな会話を構成します。新しいエージェントに関連付けられた会話オブジェクトを作成します。

code_block: <ListValue: [StructValue([('code', 'def setup_conversation(conversation_id: str):\r\n data_chat_client = geminidataanalytics.DataChatServiceClient()\r\n conversation = geminidataanalytics.Conversation(\r\n agents=[data_chat_client.data_agent_path(\r\n billing_project, location, data_agent_id)],\r\n )\r\n request = geminidataanalytics.CreateConversationRequest(\r\n parent=f"projects/{billing_project}/locations/{location}",\r\n conversation_id=conversation_id,\r\n conversation=conversation,\r\n )\r\n try:\r\n # Check if it already exists\r\n data_chat_client.get_conversation(name=data_chat_client.conversation_path(\r\n billing_project, location, conversation_id))\r\n except Exception:\r\n response = data_chat_client.create_conversation(request=request)\r\n print("Conversation created successfully.")\r\n\r\nconversation_id = "my_first_conversation"\r\nsetup_conversation(conversation_id=conversation_id)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f39d3366b20>)])]>

ステップ 3: ストリーミングチャットループを作成する

インタラクティブな分析を可能にするため、会話フローを管理する関数 stream_chat_response を実装します。Data Analytics Agent API は、レスポンスをストリームとして返すように設計されています。この処理は、エージェントの最新の進捗状況をリアルタイムで提供するために不可欠です。

一般的なレスポンスストリームには、以下のような個別のコンポーネントが含まれます。

スキーマ: テーブルの解像度の確認。
データ（クエリ）: 生成された SQL クエリ（デバッグと透明性の確保に適しています）。
データ（結果）: 結果のデータ構造体（Pandas のような DataFrame など）。
グラフ: データ可視化のための Vega-Lite JSON 仕様。
テキスト: 合成された自然言語での最終的な要約。

関数を定義する

この関数は、ユーザーの質問を受け付けるように定義されています。内部では、DataChatServiceClient を初期化し、ストリーミング完了後にグラフをレンダリングする必要があるかどうかを追跡するための単純なフラグ（chart_generated_flag）を定義します。ユーザーの質問は、API リクエストに必要な Message オブジェクトにラップされます。

code_block: <ListValue: [StructValue([('code', "def stream_chat_response(question: str):\r\n data_chat_client = geminidataanalytics.DataChatServiceClient()\r\n chart_generated_flag = [False] # Flag to help with visualization\r\n \r\n # Format the user's question into an API-ready Message object\r\n messages = [\r\n geminidataanalytics.Message(\r\n user_message=geminidataanalytics.UserMessage(text=question)\r\n )\r\n ]"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f39d07e5910>)])]>

ストリームを処理する

ConversationReference は必須です。ステートフルな会話に関連付け、先ほど作成した特定の data_agent にリンクします。親パス、メッセージ、参照を使ってリクエストオブジェクトを完全に構築したら、data_chat_client.chat を呼び出します。

次に、返されたストリームを反復処理します。ここでは、ユーティリティ関数 show_message を使用して、さまざまなレスポンスタイプ（テキスト、グラフ、データ）を解析し、ユーザーに合わせて適切にフォーマットしています。最後に、ストリーム内で chart_generated_flag が設定されていた場合は、後処理ユーティリティ（preview_in_browser）が可視化のレンダリングを処理します。

code_block: <ListValue: [StructValue([('code', '# Reference the stateful conversation and the created Data Agent\r\n conversation_reference = geminidataanalytics.ConversationReference(\r\n conversation=data_chat_client.conversation_path(\r\n billing_project, location, conversation_id\r\n ),\r\n data_agent_context=geminidataanalytics.DataAgentContext(\r\n data_agent=data_chat_client.data_agent_path(\r\n billing_project, location, data_agent_id\r\n ),\r\n ),\r\n )\r\n \r\n # Prepare the chat request\r\n request = geminidataanalytics.ChatRequest(\r\n parent=f"projects/{billing_project}/locations/{location}",\r\n messages=messages,\r\n conversation_reference=conversation_reference,\r\n )\r\n \r\n # Process the streaming response\r\n stream = data_chat_client.chat(request=request)\r\n for response in stream:\r\n # \'show_message\' is a utility function that formats\r\n # and prints the different response types (text, data, chart)\r\n show_message(response, chart_generated_flag)\r\n\r\n # If a chart was generated, \'preview_in_browser\'\r\n # is a utility to save and serve it as HTML\r\n if chart_generated_flag[0]:\r\n preview_in_browser()'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f39d07e54c0>)])]>

ステップ 4: エージェントと会話する

質問する

では、成果を見てみましょう。stream_chat_response 関数を使用して会話できます。

コンテキストを確認する

まず、エージェントがそのコンテキストを理解しているかどうかを確認しましょう。

Python

code_block: <ListValue: [StructValue([('code', 'question = "Hey what data do you have access to?"\r\nstream_chat_response(question=question)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f39d07e5130>)])]>

エージェントは、system_instruction で指定した説明を使用して、top_terms テーブルと top_rising_terms テーブルの概要を返します。

自然言語から SQL、そしてグラフへ

今度は、複雑なクエリを見てみましょう。平易な英語でグラフをリクエストしていることに注目してください。

Python

code_block: <ListValue: [StructValue([('code', 'question = "What are the top 20 most popular search terms last week in NYC based on rank? Display each term and score as a column chart"\r\nstream_chat_response(question=question)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f39d07e5f70>)])]>

エージェントは、このプロセスを以下のようにストリーミングします。

生成された SQL クエリを表示します。このクエリは、top_terms テーブルにアクセスし、dma_name = 'New York NY' と直近の 1 週間でデータをフィルタします。
結果のデータをテーブルとして出力します。
Vega グラフの仕様を生成します。
preview_in_browser ユーティリティがこれを、縦棒グラフを表示する index.html ファイルとして提供します。

ステートフルなフォローアップ

ここで、ステートフルな会話（ステップ 2）が力を発揮します。

Python

code_block: <ListValue: [StructValue([('code', 'question = "What was the percent gain in growth for these search terms from the week before?"\r\nstream_chat_response(question=question)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f39d07e5f10>)])]>

エージェントは、「these search terms（これらの検索語句）」が質問 2 の結果を指していることを記憶しています。新しいクエリを生成し、今回は（join_instructions の指示に沿って）top_terms テーブルと top_rising_terms テーブルを INNER JOIN して、同じ語句リストの percent_gain を取得します。

ステップ 5: エージェントを管理する

エージェントとメッセージのライフサイクル管理について詳しくは、Conversational Analytics API ドキュメントの、実行できるさまざまな API リクエスト（HTTP / Python）に関するページをご確認ください。エージェントの管理方法、SetIAM API、GetIAM API 経由で新たにユーザーを招待して共同作業を行う方法などについても説明しています。

上級者向けのヒント: データと人のギャップを埋める

明確なシステム指示とスキーマ説明を与えることで、単なる会話型エージェントではなく、該当分野のエキスパートとなるエージェントを構築できます。このインタラクティブなアプローチは、静的なダッシュボードを越え、真に利用できるデータ分析を実現します。

始める

- デベロッパーリレーションズエンジニア、David Tamaki Szajngarten

- デベロッパーアドボケイト、Wei Hsia

デベロッパー

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

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

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

AI エージェントの構築

AI エージェントの拡張

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

AI エージェントの最適化

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

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

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

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

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

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

パート 3: ADK と Vertex AI Agent Engine

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

まとめ

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

Google Cloud のアプリケーション ロードバランサへの移行: 実践ガイド

シンプルで段階的な移行アプローチ

スムーズな移行のためのベスト プラクティス

データレイヤの有効化によるプロダクション レディな AI の実現

セマンティック検索: データベース内のテキスト エンベディング

マルチモーダル エンベディング: 検索に画像を取り入れる

AlloyDB AI 関数と再ランキング

AlloyDB AI の自然言語を使用して SQL を生成する

テストから本番環境へ

Envoy: エージェント型 AI ネットワーキングのための将来を見据えた基盤

エージェント型 AI がネットワーキングの問題を変える

Envoy がこの移行に対応できる理由

1. Envoy はエージェント トラフィックを理解する

2. Envoy は重要な事項に関するポリシーを適用する

3. Envoy はステートフルなエージェントのインタラクションを大規模にサポートする

4. Envoy はエージェントの検出をサポートする

5. Envoy はエージェント ネットワーキングの課題に対する包括的なソリューション

コントロール プレーンがこれを運用可能にする

このソリューションが重要な理由

Google ADK、MCP、Cloud Run を使用して専門家向けコンテンツ用のマルチ エージェント システムを構築する - パート 1

学習内容

Dev Signal の概要

前提条件

プロジェクトのセットアップ

1. プロジェクトを初期化する

2. フォルダ構造

3. 依存関係を定義する

エージェント機能の構築: MCP ツール

ツールの構成

Reddit 検索（発見ツール）

Google Cloud ドキュメント（ナレッジツール）

画像生成ツール（Nano Banana MCP）

Nano Banana Pro サーバー ロジックの実装

サーバー エントリポイント（main.py）

生成ロジック（nano_banana_pro.py）

GCS アップロード ヘルパー（storage_utils.py）

データモデル（media_models.py）

ツールの依存関係（requirements.txt）

まとめ

LLM 推論の効率的フロンティアに到達するための 5 つの手法

推論に効率的フロンティアがある理由

推論の 2 つの軸

フロンティアに到達する: 制御可能な 5 つの手法

ケーススタディ: Vertex AI がフロンティアに近づいた方法

まとめ

AI リテラシーの新しい形: 学生デベロッパーを対象とした調査結果

調査

調査結果その 1: 24 時間 365 日、いつでも頼れる先生

調査結果その 2: 過度な依存に対する積極的な抵抗

調査結果その 3: AI の使いどころを心得ている

すべてを任せるのではなく、意図的に取り入れる

カスタマイズが肝

この調査結果が業界において意味すること

分散 AI エージェントの構築

分散エージェントを使用する理由（フロントエンド チームに感謝される理由）

全体的な設計: コース作成アプリ

ステップ 1: スペシャリスト（リサーチャー）の配備

ステップ 2: 評価担当者（構造化されたデータ出力）

ステップ 3: 共通言語（A2A プロトコル）

ステップ 4: オーケストレーター パターン

デプロイ:「食料品店」モデル

注意事項、セキュリティ上の配慮

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

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

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

Google Cloud のアプリケーションロードバランサへの移行: 実践ガイド

スムーズな移行のためのベストプラクティス

データレイヤの有効化によるプロダクションレディな AI の実現

セマンティック検索: データベース内のテキストエンベディング

マルチモーダルエンベディング: 検索に画像を取り入れる

1. Envoy はエージェントトラフィックを理解する

5. Envoy はエージェントネットワーキングの課題に対する包括的なソリューション

コントロールプレーンがこれを運用可能にする

Google ADK、MCP、Cloud Run を使用して専門家向けコンテンツ用のマルチエージェントシステムを構築する - パート 1

Nano Banana Pro サーバーロジックの実装

サーバーエントリポイント（`main.py`）

生成ロジック（`nano_banana_pro.py）`

GCS アップロードヘルパー（`storage_utils.py）`

データモデル（`media_models.py`）

ツールの依存関係（`requirements.txt）`

分散エージェントを使用する理由（フロントエンドチームに感謝される理由）

ステップ 4: オーケストレーターパターン

プロダクションレディな AI エージェントに関するデベロッパーガイド

RAG 対応生成 AI アプリケーションのプライベートネットワーク接続の設計

トラフィックフロー

短期、中期、長期の履歴に対応するポリグロットストレージアプローチ

ポリグロットアプローチとは

戦略的転換: コンテキストエンジンとしてのデータベース

3. ソブリンインテリジェンスと行レベルセキュリティ（RLS）

ステップ 3: ストリーミングチャットループを作成する