【Google Cloud Next Tokyo 26】AIエージェント開発は「インフラ」で差がつく！4つのレイヤーと「結局一番重要なこと」

AI Agent 最前線： ADK とインフラ基盤の要点＆「結局重要なこと」

Google Cloud Next Tokyo 2026 の Developer Stage にて、株式会社メルカリの山田直史氏によるセッションが実施されました。社内向けデータエージェントの運用で直面した実課題をもとに、エージェント開発の出発点から安全なシステムを構築するためのインフラ構成アイデアが提示されました。
え、エージェントを作るのも考えつつインフラも考えなきゃいけないの！？とセッションを聞いててドギマギしてしまいました、私です笑　簡潔に、私が調べたことも含めて AI エージェントでのインフラについてどのように考えて行けばよいのか書いてみました！読んでいただけますと幸いです！！！

1. AI Agent の作り方と拡張のステップ（Build）

AI エージェントを構築する際は、どこまで作り込むかに応じて 3 つの開発パスと「開発しない」選択肢が存在します。

開発パスの選択肢

• Low-code （Agent Studio）
  UI 上で組み込み部品を活用し、コード生成から直接デプロイまでを手軽に行う「頑張らない」スタイルです。
• Managed code （Managed Agents API）
  HTTP リクエストで簡単に呼び出し、「MCP （Model Context Protocol）だけ頑張る」スタイルです。
• Custom code （Agent Development Kit / ADK）
  Python などのコードベースで自由度の高いロジックを自作する「“全部” 頑張る」スタイルです。

また、ゼロから開発しないアプローチとして、 Coding Agent （Google Antigravity） の活用や、 Conversational Analytics API などの特化型機能を組み合わせる手法も紹介されました。

エージェントの段階的強化

エージェントは一元的に複雑なものを作るのではなく、段階的に機能を拡張していきます。

1. LLM + Prompt （基本的な指示と応答）
2. LLM + Retrieval （RAG ・検索の追加）
3. LLM + Retrieval + Actions （外部ツール呼び出しやアクションの実行）
4. Many Tools & Reasoning Loop （多数のツールと複雑な推論ループ）
5. Multi Agent Systems （複数エージェントによる連携・協調）

2. エージェントを支える「Gemini Enterprise Agent Platform」

AI エージェントを実験段階から本番規模の運用へ移行させるため、 Google Cloud では Gemini Enterprise Agent Platform が提供されています。プラットフォームは大きく 4 つのレイヤーで構成されています。

3.  AI エージェントのインフラで「結局一番重要なこと」とは？

セッションやプラットフォームの全体像から見えてくる、 AI エージェントのインフラにおける結論は以下の通りです。

「単にモデルを呼んで動かす（Build）だけでなく、自律動作するエージェントを制御し、記憶させ、評価し続けられる『統合的な運用基盤（Scale / Govern / Optimize）』を最初から組み込むこと」

従来のチャットボットと異なり、 AI エージェントは自律的に推論を回し、複数システムをまたいでアクションを実行します。そのため、以下の 3 点がインフラ選びの決定的な差となります。

• ガバナンスとセキュリティ（Govern）
  エージェントに明確な身元（Agent Identity）を与え、 Gateway で「誰が・どのツールに・どんな権限でアクセスできるか」を制御・監査できなければ、野良エージェントの乱立や誤動作を防げません。
• 文脈と記憶の保持（Scale）
  セッションが切れてもユーザーの好みや業務履歴を正しく再現できる記憶基盤（Memory Bank）や、長時間のワークフローを実行できる環境が不可欠です。
• 定量的な評価とデバッグ（Optimize）
  単発の応答精度だけでなく、複数ターンのやり取りで「最終的にタスクを完遂できたか」や「ハルシネーションが発生していないか」をスコア化し、継続的に追跡・最適化できる仕組みが必要です。

4. 深掘り!!  AI エージェントの本番運用で「本当に重要なインフラ」とは？

従来のチャットボットと異なり、最新の AI エージェントは 1 つのプロンプトから複数のシステムを横断し、自律的な推論ループやワークフローを連続実行します。

こうした非線形な処理負荷により、調査では 83 % の組織が「エージェント型 AI に対応するためのインフラのアップグレードが必要」と回答しています。

単に高度な LLM を呼び出すだけでは本番運用で破綻してしまいます。 AI エージェントのインフラにおいて「結局何が一番重要なのか」、その核心を 3 つのポイントにまとめました。

重要なこと 1 ：データとコンテキストへの直接アクセス

エージェントが正確に判断し実行するには、社内の膨大なデータや業務コンテキストにアクセスできる環境が不可欠です。しかし、 43 % の IT リーダーが「既存システムやデータソースとの統合の難しさ」を主要なギャップとして挙げています。

• 無駄なデータ移動の削減：データを都度複製・移動するとコストと遅延が跳ね上がります。データを置いたまま直接読み取れる統合データレイヤ（Agentic Data Cloud やレイクハウス）の整備が重要です。
• リアルタイム性と長期記憶：過去のやり取りやユーザーの好みを保持する長期記憶基盤（Memory Bank）があることで、クエリごとの再処理を防ぎ、一貫した文脈で推論できます。

重要なこと 2 ：「推論税」と運用の複雑さを抑える柔軟性

エージェントが推論ループを回し続けることで発生するコストや運用の複雑さは、深刻な問題となっています。実際、 62 % のリーダーがデータ転送やストレージ膨張による「推論税」に直面し、 81 % が運用の複雑さを隠れたコストと感じています。

• フルイド コンピューティングの導入：タスクの性質に応じて最適なハードウェアを動的に割り当てるアプローチです。
• 用途に応じた最適化：学習には大規模スケーラビリティを持つ TPU 8 t 、低レイテンシ推論には TPU 8 i 、オーケストレーションには Axion CPU など、モデル・データ・チップを垂直統合することで費用対効果を高めます。

重要なこと 3 ：制御（ガバナンス）と継続的な品質評価

エージェントが自律的に外部ツールや API を叩くようになると、「野良エージェントの乱立」やセキュリティリスクが急増します。 79 % のリーダーがガバナンスや MLOps を最大の課題と捉えています。

• 暗号化 ID と管制塔による統制：エージェントに固有の身元（Agent Identity）を与え、 Agent Gateway を介して「誰が・何の権限で・どこにアクセスしたか」を一元管理・監査する仕組みが不可欠です。
• マルチターンの評価と最適化：単発の応答精度だけでなく、複数ターンのやり取りの中で「タスクを完遂できたか」や「ハルシネーションがないか」を可視化・自動評価（Agent Observability / Evaluation）し、継続的に改善する運用環境が必要です。

5. まとめ

AI エージェント開発は「 ADK などを用いてどう作るか（Build）」から始まりますが、本番環境で成果を出すためには「どうスケールさせ、どうガバナンスを効かせ、どう改善し続けるか」というインフラ設計が成功の鍵を握ります。

これからエージェント構築に取り組む方は、自社の目的に合った開発パスを選びつつ、本番運用を見据えたプラットフォーム機能を上手に活用していきましょう！

個人的まとめ

AI エージェントのインフラは正直そこまで考えていませんでした。本当にお恥ずかしい。そのため、このセッションを聞いて、自分で深堀りしてこのブログを書けて知識が増えて本当に良かったです。

AI エージェントが主流になってくるのが予測できるいま、「作る（Build）」だけでなく、「広げる（Scale）」「護る（Govern）」「高める（Optimize）」を最初から見据えたインフラ設計を進めていけたら最強ですね。これからもチェックしていきたいと思います！