はじめに
こんにちは、KDDIアイレット株式会社の伊藤です。
2026 年 7 月 30 日に開催された Google Cloud Next Tokyo ’26 で、Google Cloud のデータ基盤に関するセッションを聴講してきました。
- テーマ: AI エージェント時代にデータ基盤の役割はどう変わるか
- 中心となる主張: データ基盤を “System of Insight (SoI)” から “System of Action (SoA)” へ転換すべき
- 主な内容: エージェントがもたらす負荷・コストの変化と、それに対する Google Cloud のアプローチ
LLM はコモディティへ。差別化は「データ」と「プロセス」に
セッションはまず、AI エージェントの定義 (認識・推論/計画・行動・記憶/学習・自律性) と、AI モデルの進化の速さの整理から始まりました。例として挙げられたのは Gemini 3.5 Flash です。GA になり、前世代の Gemini 3.1 Pro を上回る性能を 3 分の 1 のコストで出せるようになった、という話でした。
一方で、最新の LLM は誰もが使える「コモディティ」なツールになりつつあり、AI 単体の性能差はもはや差別化要因になりにくい。真の競争優位性を生むのは次の 2 点だと整理されていました。
- 企業が保有する独自データの活用 — 顧客の声や現場の生きたデータを「エージェントがいつでも使える状態」にする
- 意思決定・業務プロセスの変革 — 「一部の業務に AI を使う」のではなく「エージェントを前提とした業務プロセス」へ
私は普段サポートデスク向けの AI チャットボットを運用していますが、モデルの乗り換え自体は環境変数の変更程度で済むことが多く、世代交代のたびに追随してきました。乗り換えで差がつかない以上、回答品質を決めるのは「エージェントに渡せる自社データがどれだけ整備されているか」だというのは、実感と一致します。
データ基盤の役割の変化 — SoI から SoA へ
本セッションの中心となる主張がこの転換です。
- これまで (SoI): SAP や Salesforce など計画・実行を担う各種システムからデータを集め、「答え合わせ」や予測のための分析を行う基盤
- これから (SoA): AI エージェントがワークフローに参画することを前提とした、事業・サービス運営のための業務インフラ
両者の違いは 3 つの観点で整理されていました。
| 観点 | SoI | SoA |
|---|---|---|
| 規模・スケール | 人間の規模 | エージェントの規模 |
| 求められる役割 | 受動的なインテリジェンス | 自律的な実行 (Action) |
| 必要なアセット | データ | データ + 意味を持つナレッジ |
「データ分析の主体は人から自律型 AI へ移行した」という言い切りには議論の余地があるとしても、エージェントを業務に組み込むほどデータ基盤が「分析のための置き場」から「業務の実行系」に近づいていく、という方向性には同意できます。
エージェントがかける負荷は、人とは質が違う
人が操作する基盤では、抽出の前提や背景知識は人の頭の中で処理され、負荷がかかるのは SQL の実行時だけ。接続数や頻度も人の動作が前提なので、負荷は予測しやすく、コストも制御しやすい構造でした。
これがエージェント主体になると、次のように変わります。
- “前処理” の時点から負荷がかかる: どう抽出するかを考えるコンテキスト理解・前提確認の段階から基盤にアクセスする
- 接続数・頻度が機械前提になる: 人の何十倍〜何百倍。複数のエージェントが連動して動く
- スパイクの予測が困難: 負荷のタイミングと規模がエージェントの挙動に依存する
- コスト制御が難しい: 推論・クエリ生成・実行・エラー分析・修正のループが回り続け、リソース消費とトークン数が膨らみやすい
これは運用で日々感じている点です。チャットボットではユーザーの 1 つの質問に対して、検索ワードの生成、複数データソースへの検索、取得ドキュメントの有用性判断、回答生成、やりとりの要約と、内部で何段もの LLM 処理と検索が走ります。ユーザーから見えるのは 1 往復の会話でも、基盤側の処理量はその何倍にもなる。「同時接続数は従業員の数と比較して指数関数的に増える」という説明も、この構造を踏まえるとよく分かります。
回答品質を支える「コンテキスト」の整備
後半は、エージェントが期待通りに動くために必要なコンテキストの話でした。整備すべきコンテキストは 3 層です。
- Technical metadata: スキーマなど、構造化・非構造化データの技術側面の理解
- Business semantics: 自社の用語、ロジック、オントロジー (関係性)、指標の理解
- Personalization: 対話履歴から個々のユーザーのプロファイルや傾向を理解する
これが欠けると、エージェントはテーブルの結合関係を推測しなければならず、無数の確認クエリと推論・エラーの無駄なループ (ReACT ループ) が発生します。「売上」という言葉一つとっても部門によって見たい軸が異なり、かといってすべての社内用語や前提条件を毎回プロンプトに詰め込むのは、トークン制限の観点からも非現実的です。
解決策として紹介されたのが Knowledge Catalog (ナレッジ カタログ) です。SaaS アプリ、オペレーショナル DB、GCS、分析系データなどを Context federation でつなぎ、LookML のセマンティクスも取り込んで、各種エージェントに一貫したコンテキストを供給する universal context engine と位置付けられていました。
チャットボットの運用でも、回答品質の改善は結局モデルではなくナレッジ側の整備 (データの構造化、検索対象の選別、用語の揺れの吸収) に行き着くことが多く、「セマンティクスを基盤側で持つ」方向性は歓迎したいところです。一方で、用語やナレッジの鮮度を保つ運用は人の仕事として残るはずで、カタログを導入すれば終わりという話ではない点は意識しておきたいです。
BigQuery のアップデート
こうした負荷・コストの課題への Google Cloud の回答として、BigQuery のアップデートが 2 つ紹介されました。
BigQuery Graph Analytics (プレビュー)
散在するデータ間の相関をプロパティグラフとして構造化し、エージェントに「点と点をつなぐ」洞察力を与える機能です。既存テーブルの上に CREATE PROPERTY GRAPH でグラフを定義できるため、データを移動せずに始められます。前段の Business semantics で「オントロジー (関係性)」が強調されていたこととつながる機能だと理解しました。
BigQuery Fluid Scaling (GA)
エージェント時代の課金体系への変更です。
- 実際に使用した計算リソースに対する秒単位の課金
- オートスケール時にあった 60 秒の最低課金時間を撤廃 (最低課金時間ゼロ)
- 事前設定不要で瞬時に自動拡張。コスト削減効果は 34% と紹介
エージェントのワークロードは前述の通りスパイクが読めないので、「短時間のバーストに対して使った分だけ課金される」モデルは、エージェント前提の設計として理にかなっていると感じます。人の分析ならスロットの事前確保で足りていた場面でも、エージェントが裏で大量の短いクエリを発行する世界では、この粒度の課金が効いてくるはずです。
まとめ
セッション全体のメッセージは、「AI エージェントの活用はモデル選びではなく、データ基盤の設計の話である」という点に尽きると思います。前処理からの負荷、機械前提の接続数、予測できないスパイク、膨らむコスト — いずれも AI エージェントを本番運用していると具体的に思い当たる課題でした。
エージェントの見た目の賢さはモデルが担ってくれる一方、業務で使える回答品質と安定性は、その下のデータとコンテキストの整備で決まります。自分たちのチャットボットでも、ナレッジの構造化やセマンティクスの持たせ方は改善の余地が大きい領域なので、Knowledge Catalog や BigQuery Graph Analytics のようなコンテキストを基盤側で支える機能は、今後の設計の参考にしていきたいと思います。
簡単30秒