「試す」から「本番で動かす」へ――Agentic AI Summit '26 Fall Day2 Track 1レポート

公開：2026年11月10日

CodeCampが提供するDX人材育成が可能なプログラミングやITが学べる公開講座

Day2基調講演。AIエージェントを「試す」段階から本番へ移す条件が議論された。
現地撮影／Day2

Day2 Track 1は、AIエージェントを「作れる」状態から「任せられる」状態へ進めるための技術を一日かけて分解した。

基調講演、Production Architecture、Antigravity、Agent Swarm、Knowledge Map、すかいらーく。開発、評価、データ、コスト、実世界まで、AIエージェント本番化の論点を追う。

この記事の要点

1. 本番化には品質評価・責務境界・セキュリティ・コストを同時に設計する必要がある。
2. 開発者の役割は、コードを書く人から、エージェントが開発できる環境・評価・制約を作る人へ広がる。
3. 自律性やマルチエージェントは目的ではない。任せられる範囲を根拠を持って広げることが本番化である。

1. 基調講演――汎用機能は任せ、自社固有の業務へ開発力を集中する
2. Production Architecture――評価・責務・安全・コストを分解する
3. Antigravity――「コードを書くAI」から長時間働く開発エージェントへ
4. Agent Swarm――速さのために5倍のオーバーヘッドを払うか
5. Knowledge Map――AIへ会社固有の「地図」を渡す
6. すかいらーく――人・AI・ロボットを店舗で協調させる
7. Track 1の結論――本番化とは、任せられる状態を作ること

2026年10月の背景

10月13日、GoogleはAgent Development Kit（ADK）がPython、Go、TypeScript、Java、Kotlinの5言語に対応したと発表した。エージェント開発は特定の実験環境から、既存のソフトウェア開発スタックへ入りつつある。

7月にはAlphaEvolveがGoogle CloudでGAとなった。今回のセッション内容そのものではないが、AIがコードを書く段階から、候補を生成・評価・改善する試行錯誤のループまで担う方向へ進んでいることを示す背景になる。

基調講演――汎用機能は任せ、自社固有の業務へ開発力を集中する

Day2基調講演のテーマは「エージェント開発の最前線。試すから、本番で動かすへ」。Day1が全社利用や組織変革を中心に扱ったのに対し、Day2は開発者側から「本番」を分解していった。

基調講演で繰り返されたのは、AIエージェントのすべてを自社で作る必要はないという考え方だ。汎用的な検索、Workspaceとの連携、エージェント実行基盤、ID・権限、モデル選択といった部分はプラットフォームへ任せ、自社が持つ独自業務・データ・判断基準へ開発力を集中する。

実際、企業側の事例では、最初から理想形を目指すのではなく、処理できる範囲から本番へ出し、成果を回収しながら広げるアプローチが示された。AIエージェントを「PoCで完璧になるまで待つ」のではなく、責任境界を決めて小さく本番化する。

また、技術だけでなく、現場で得られる暗黙知を要件へ変えることも重要なテーマだった。モデルが賢くなっても、現場の業務を理解しなければ本番で価値を出せない。この点はAsk the SpeakerでKaz Sato氏が語った「現場で本当に便利と言われるところまで持っていく」という話と一致する。

Production Architecture――評価・責務・安全・コストを分解する

「AIエージェントを本番に載せるアーキテクチャ設計」は、Day2で最も実務的な設計論の一つだった。本番化を「品質／評価」「責務／境界」「安全／権限」「コスト／レイテンシ」の4つに分ける。

まず品質。生成AIは非決定的なので、単体テストのように毎回完全一致を求められない。その代わり、代表的な質問・期待する振る舞いを評価データセットとして持ち、継続的にスコアを測る。講演では基準データをCI/CDへ組み込み、一定スコアを下回ったらリリースを止めるという考え方も示された。モデルやプロンプトを変えるたびに「何となく良くなった」で判断しない。

次が責務。巨大な一つのエージェントへ全部を任せると、何が失敗したか分かりにくく、権限も広くなりやすい。発注、在庫、予算確認などをドメインで分割し、A2AやMCPで接続すれば、各エージェントへ必要な権限だけを与えられる。一方、分割しすぎればセッション管理や認証の複雑さも増える。マイクロサービスと同様、分割自体を目的にしない。

安全性では、エージェントID、ホワイトリスト、Model Armor、入力・出力側のガード、Human-in-the-loopを組み合わせる。無限リトライや意図しない支払い処理のように、モデルが「動き続ける」ことでコスト・業務事故へつながるケースには、回数・金額・時間の上限や人間承認を入れる。

最後がコスト。高性能モデルと軽量モデルでは処理単価に大きな差がある。どこに高い知能が必要かを評価データで判断し、簡単な処理は軽量モデルへ寄せる。ここでも評価設計がコスト最適化の前提になる。さらにトレースを使い、MCPや各エージェントのどこに時間がかかっているかを可視化すれば、レイテンシのボトルネックも改善できる。

このセッションの意味

本番化はプロンプト調整ではなく、テスト・責務分割・最小権限・コスト計測という従来のソフトウェア工学をAIへ持ち込むことでもある。

Antigravity――「コードを書くAI」から長時間働く開発エージェントへ

Antigravityの基礎セッションでは、エージェントを単なるコード補完としてではなく、長時間のタスクを任せる開発パートナーとして扱う操作がデモされた。エディタだけでなく、ターミナルやブラウザ、複数のツールをまたいで作業し、成果物を確認しながら進める。

ここで開発者の役割は「一行ずつコードを書く」から、「何を完成条件とするか」「どの情報をコンテキストへ渡すか」「どこまで自動実行を許すか」を設計する側へ移る。エージェントの仕事が長くなるほど、指示の詳細さより、目的・制約・検証方法の設計が効く。

また、複数のエージェントを同時に走らせる場合、並列化によって作業時間を縮められる一方、各エージェントの成果をどう統合し、競合をどう避けるかという新しい問題も出てくる。開発速度が上がるだけでなく、開発プロセスの管理単位が変わる。

このセッションの意味

AIコーディングの次の段階では、開発者はコードの作者であると同時に、エージェントが安全に開発できる環境の設計者になる。

Agent Swarm――速さのために5倍のオーバーヘッドを払うか

Agent Swarmのセッションは、「複数エージェントなら常に優れている」という期待を検証するものだった。主要なフレームワークとモデルを実測し、単一エージェントと複数エージェントの速度、品質、コストを比較する。

複数エージェントなら、調査、実装、レビューなどを並列で進められる。しかし、エージェント間の調整、コンテキスト共有、追加のモデル呼び出しが必要になるため、オーバーヘッドも増える。小規模なアプリであれば、単一エージェントの方がシンプルで安い場合がある。

セッション後のAsk the SpeakerでKaz Sato氏は、検証したケースについて「5倍とかかかっちゃう」とコスト面のオーバーヘッドへ触れた。一方、大規模開発には複数エージェントが必要になると見ている。重要なのは「新しいから使う」のではなく、並列化や専門分業による価値が追加コストを上回るかを見ることだ。

これはTokenomicsともつながる。エージェント数を増やすとトークン消費も増える。設計段階で、単一エージェント、サブエージェント、Swarmのどこまで必要かを選ぶ必要がある。

このセッションの意味

マルチエージェントは成熟度の証ではない。追加の複雑さとコストを払うだけの並列性・専門性が必要な仕事で使う。

Knowledge Map――AIへ会社固有の「地図」を渡す

「AIエージェントが迷わないナレッジの地図」は、企業データへAIをつなぐ際の典型的な失敗から始まった。注文データだけを見て売上を計算すると、キャンセルや確定条件を考慮できず、会社が信頼する数字とずれる。データへのアクセス権があっても、業務の意味を理解していなければ正しい回答にはならない。

講演では、売上の定義、テーブル間の関係、指標の計算方法、データの由来などを「ナレッジの地図」としてエージェントへ渡す。データの保存場所がBigQueryだけとは限らないため、複数のクラウドやシステムにあるデータでも、意味のレイヤーを共通化する考え方が重要になる。

Knowledge Catalogは、メタデータ、リネージ、ビジネス用語、セマンティックモデルを一つのコンテキストグラフへ集める。さらに、利用者とエージェントのやり取りから「不足している説明」を見つけて補う自己学習型のエンリッチメントも発表された。静的なカタログではなく、使われるほど文脈を補強する方向だ。

このセッションの意味

AI時代のデータ基盤は、データを置く場所ではなく、企業の『意味』をAIと人間で共有する基盤へ変わる。