A2A、MLOps、AIネイティブ開発、データカタログ――Agentic AI Summit '26 Fall Day2 Track 2・3レポート

ビデオリサーチのデータカタログセッション。Day2 Track 2・3では、データ基盤やナレッジまで含む本番実装が議論された。
現地撮影／Day2

Day2 Track 2・3では、「本番化」が企業ごとの実装へ落ちた。

コロプラ、NTT DATA、Datadog、メルカリ、損保ジャパン、ビデオリサーチ、Cloud Ace、NRI、Asana、サテライトオフィス。10セッションから、AIエージェントを企業システムへ組み込む周辺設計を追う。

コロプラ――作り方は自由、つなぎ方はA2A

コロプラは、全社のAIエージェントを一つの開発方式へ統一するのではなく、「各チームは自由に作り、つなぐ境界だけをA2Aでそろえる」設計を紹介した。中央チームがすべてのエージェントを作る方式では、現場の速度と専門性を損ないやすい。

MCPはエージェントがツールやデータへアクセスするための縦方向の接続、A2Aは別チーム・別所有者のエージェントへ仕事を依頼する横方向の接続として整理された。他チームの機能を自分のエージェントへ直接抱え込まず、相手側のエージェントを呼ぶ。

この方式には権限面の利点もある。生データや強い権限を利用者へ配らず、データを所有するチームのエージェントが自分の権限で処理し、必要な結果だけを返せる。A2Aは技術的な通信仕様であると同時に、組織境界を守るための契約にもなる。

さらにコロプラは「場」の概念を重視した。全社共有の場、部署の場、本人だけの1対1の場では、呼べるエージェントも見てよい情報も異なる。LLMの判断だけに権限制御を任せず、接続関係そのもので境界を作る。エージェントの記憶も、誰が見てよいかという範囲で分ける。

実装ではADK、Agent Runtime、Agent Registry、Gemini Enterpriseなどを組み合わせ、A2UIも含めて画面側まで連携する例が示された。「作り方は自由」という言葉は、無秩序を許すという意味ではない。接続・権限・場という共通ルールを持つから、各チームの自由を残せる。

NTT DATA――AI導入を経営変革の入口から成果までつなぐ

NTT DATAは、Google WorkspaceやGemini Enterpriseの導入を「業務ツールの刷新」で終わらせず、経営変革のトリガーとして扱う考え方を示した。個人の生産性向上だけでなく、複数システムに分散した情報をつなぎ、業務プロセスそのものを変え、最終的にコスト構造や意思決定まで変える。

一方、企業では導入後に壁が生まれる。社員が「何に使えばよいか分からない」、業務データが分散していてエージェントへ安全につなげられない、PoCを作っても成果へ変えられない。技術だけではなく、業務、人材、データ、セキュリティが分断されていることが原因になる。

NTT DATAは、基盤・ID・権限・セキュリティを整える導入層、ユースケースと人材を育てる活用層、業務課題に入り込んでエージェントを実装するFDE的な支援を一気通貫でつなぐ姿を示した。構想策定、PoC、本番化を別々のプロジェクトとして切らない。

AIエージェント導入の難しさは、モデルを選ぶことより「成果へ至る経路が長い」ことにある。経営テーマから業務へ落とし、データと権限をつなぎ、現場で使えるものへ調整し、KPIで成果を示す。この橋渡しができるかが、全社展開の分かれ目になる。

Datadog――開発がAIで速くなるなら、運用とセキュリティも速くする

Datadogのセッションは、AI駆動開発でコードが速く作られるほど、レビュー・運用・セキュリティが次のボトルネックになるという問題から始まった。開発量が3倍になっても、レビューする人員が3倍になるわけではない。その差分が運用負荷として現れる。

必要なのは「AIを運用すること」と「AIで運用すること」の両方だ。AIアプリケーションのモデル、トークン、レイテンシ、コストを観測する一方、インフラやアプリの障害検知・調査・修復自体にもAIを使う。

セッションでは、いきなり自動修復から始めないことが強調された。まずObserveでメトリクス・トレース・ログなどをつなぎ、次にDetect、Investigateへ進む。AIが複数の仮説を並列に検証できれば、人間が一つずつ仮説を追うより調査時間を短縮できる。

その後にRemediateへ進むが、修復には人間が決めた方針、権限、承認条件、ロールバック手順が必要になる。AIが勝手に本番環境を直すのではなく、「どこまでなら自動修復できるか」を先に設計する。

また、過去のインシデント、ランブック、ベテランの調査記録をAIチームが再利用できる形にすることで、属人化した運用知識を組織へ残す。ここでもナレッジの複利が起きる。

メルカリ――AIネイティブな開発とTPUを支える人・基盤

メルカリのテーマは、AI機能を追加することではなく、会社そのものをAIネイティブへ変えていくことだった。AIによって開発量や実験速度が増えると、推論インフラのコスト、性能、モデルの展開速度も事業上の論点になる。

セッションでは、人とAIの役割も明確に分けられた。AIは大量の実装・試行を進められるが、人は方針を決め、判断し、レビューし、成果へ責任を持つ。AI PDLCの考え方では、作業をAIへ渡すだけでなく、プロダクト開発ライフサイクル全体をAI前提へ組み直す。

TPUについても、単に「GPUより速い」といった比較ではなく、モデルを移植し、運用し、改善するまでの人的支援を含めて語られた。以前はモデルをTPUへ移すだけでも複数人の専門家が必要だったが、Google側のエンジニアや支援チームと連携しながら、実際にモデルを載せ替えていった。

紹介されたケースでは、TPUを使った構成でコストや性能に改善が出た例も示された。重要なのはハードウェア単体ではない。モデル、推論基盤、開発者、サポート体制を合わせて初めて、AI機能を大規模に運用できる。

損保ジャパン――全部をAIへ任せず、境界を引き直す

損保ジャパンは、MLOpsの実験サイクルをAIエージェントで短縮する取り組みを紹介した。計画、実行、評価をエージェントへつなげれば速くなる。しかし、最初に「全部をAIへ任せる」方向へ寄せたところ、何の実験が走っているのか分かりにくい、承認内容が会話へ埋もれる、レビュー情報が多すぎるといった問題が出た。

そこで、人・エージェント・システムの役割を再設計した。計画や分析のようにLLMの柔軟性が効く部分、Cloud Runジョブの起動など確定的に実行する部分、方針や結果を人が承認する部分を分ける。承認はチャットの中ではなく、後から誰でも追える画面へ記録する。

この再設計で、実験サイクルは従来約1週間かかっていた状態から1〜2日へ、さらに条件がそろうケースでは30分〜1時間程度まで短縮された。単にAIが速いからではなく、人が読む情報を絞り、承認と実行を構造化したことが効いている。

一方、次のボトルネックは人の承認待ちになる。将来は金額・計算資源・時間などの上限内なら自動承認するなど、リスクベースで人を外せる範囲を広げる考え方も示された。その前提として、エージェントごとのサービスアカウント、最小権限、監査ログ、安全な実行環境が必要になる。

ビデオリサーチ――データを「探せる・分かる」へ

ビデオリサーチの課題は「データがない」ことではなかった。視聴データ、マスタ、集計条件、SQL、業務上の知識などが大量に存在する一方、利用者が「どのデータを使えばよいか」「どう集計すればよいか」を知るには熟練者の支援が必要だった。

そこで、Knowledge Catalog、Spanner Graph、複数のAIエージェントを組み合わせたデータカタログ「デタミル」を構築した。親エージェントの下に、テーブルを探す、関係性をたどる、集計パターンや手順を説明するといった役割の子エージェントを置く。

Knowledge Catalogで技術メタデータやビジネス用語を管理し、Spanner Graphでは集計パターン、SQLステップ、条件、利用データの関係をグラフとして表現する。これまで人の頭の中やバラバラな資料にあった「この分析ならこのデータをこの条件で使う」という知識を、AIが辿れる形に変える。

目標は「データを検索できる」だけではない。利用者が「なぜこのデータなのか」「どういう意味なのか」まで分かることだ。将来的には社内だけでなく、顧客が同社のデータセットを理解し、活用する入口として広げる構想も語られた。

詳しく読む：膨大なデータを「探せる・分かる」基盤を、社内から、お客さまのもとへ

Cloud Ace――ダッシュボードから対話型分析へ

Cloud Aceのセッションは、BIを「作られたダッシュボードを見る」状態から、「必要な問いをその場で言語化し、データと対話する」状態へ変える話だった。ダッシュボードは共通KPIを継続監視するには強いが、想定外の疑問が出るたびに新しいグラフを作ってもらう必要がある。

Conversational AnalyticsやBigQuery系のエージェントを使えば、自然言語から必要なデータを調べ、説明を返せる。さらに、エージェントをGemini EnterpriseのAgent Registryへ登録し、A2Aで別のエージェントから呼び出す構成も示された。

ここでも「自然言語でSQLを書ける」だけが価値ではない。人が見ていたダッシュボードと同じ指標定義・データをエージェントが参照し、必要に応じて別エージェントからも利用できるようにすることで、分析機能を組織の共通部品へ変える。

NRI――金融知識だけでなく、熟練者の問いと判断を残す

NRIは、金融業務における「攻めのナレッジ」と「守りのガバナンス・Tokenomics」を一体で扱った。AIエージェントが安定して価値を出し続けるには、業務知識を入れるだけでは足りない。

一つ目は、熟練者の知識や思考プロセス、業界・業務知識をAIが使える共通基盤へ変えること。過去資料の検索だけでなく、「何を問い、どの観点で判断するのか」まで残す。人間も同じ基盤を参照できるため、AI専用のブラックボックスにしない。

二つ目はセキュリティとガバナンス。金融では、誰がどの情報へアクセスし、どの回答を出したかを追える必要がある。三つ目はTokenomicsで、トークン利用量、モデル選択、コストを監視し、経済性を持続させる。

NRIが目指すのは、知識を投入して終わるRAGではなく、知識・ガバナンス・経済性を継続的に更新する基盤だ。AIが作業を代替するほど、人間側には「何を問うべきか」「どの判断をするか」という価値が残る。

NRIのナレッジ駆動開発セッション。
現地撮影／Day2

詳しく読む：AIは「作業」を自動化するが「問い」は自動化できない。ベテランの価値観と思考プロセスまで集める、NRIの「ナレッジ駆動開発」

Asana――AIが働ける「仕事の環境」を整える

Asanaの問いは「AIを入れたのに、なぜ仕事が進まないのか」だった。AIが賢くても、目標、担当者、期限、依存関係、過去の議論、進捗がバラバラなら、何をすべきか判断できない。人間に見えない仕事はAIにも見えない。

Asanaは仕事のデータを一つのWork Graphへ整理し、AIエージェントがチームメンバーの一人として参照できる状態を作る。タスクを受けると要素分解し、必要な情報を集め、案を作り、人へレビューを求め、フィードバックを反映して成果物を更新する。

単発の壁打ちAIと違うのは、AIが「仕事の状態」を継続的に見られることだ。メールやチャットで人間へ状況を聞き直すのではなく、最新のタスク、目標、進捗、関連資料を共通データとして使う。

エージェントをチームへ入れるほど、ソースオブトゥルース、アクセス権限、監査ログも重要になる。AIが仕事を進められるかは、モデルの性能だけでなく、組織側の仕事がどれだけ構造化されているかに左右される。

サテライトオフィス――Google Workspace導入支援5,000社以上の経験を生かすAI仕事術

サテライトオフィスは、5,000社以上のGoogle Workspace導入支援で培った経験を背景に、企業で実際に使いやすいAI仕事術をデモ中心で紹介した。プレゼン資料作成、動画要約、SWOT分析、新規事業計画、名刺データ処理、設計書作成など、現場で繰り返し発生する仕事をテンプレート化している。

重要なのは「何でも一発でAIに作らせる」ことではなく、社員が使える形に入口を用意することだ。AIに慣れている人だけが自由にプロンプトを書く方式では、利用率が伸びにくい。よくある業務をエージェントやテンプレートとして配ることで、初心者でも成果を得やすくする。

開発のデモでは、要件、詳細設計、データベース設計、テストまでAIを使う一方、最後の総合テストは人間の目で確認するという線引きも示された。自動化範囲を広げながら、最終責任まで無条件にAIへ渡してはいない。

また、企業導入ではセキュリティや個人情報、不正アクセスへの懸念も大きい。利用を広げるには、便利なユースケースと守りをセットで提示する必要がある。

Track 2・3の結論――本番AIは周辺設計で差が出る

Track 2・3の10セッションを並べると、モデルそのものの話より「周辺」の話が多い。A2A、ID、権限、可観測性、MLOps、TPU、セキュリティ、データカタログ、ナレッジ、Work Graph。AIエージェントが企業システムになるほど、モデル以外の設計が成果を左右する。

また、全部をAIへ渡す方向より、境界を細かく設計する事例が多かった。コロプラはチームの境界をA2Aで守り、損保ジャパンは人・AI・システムの役割を分けた。NRIは知識とガバナンス・コストを一体で扱い、Asanaは仕事の文脈そのものをAIへ渡した。

本番AIを作るとは、エージェントを一つ完成させることではない。作る、つなぐ、守る、測る、改善する、そして人が責任を持つ。その運用ループを企業の中に作ることだ。