Google Cloud Next Tokyo 26（2026年7月30日 – 31日、東京ビッグサイト）で聴講した Google セッション
「AI エージェント時代を見据えたデータ基盤に求められる役割とは？ [非技術者・ビジネス部門向け]」のレポートです。
本記事では、AI エージェントの活用を検討している方に向けて、「エージェントに使わせるデータ基盤」は、これまで人が使ってきたデータ基盤と何が違うのか、という点を中心にまとめます。
なお、本記事に掲載しているスライド写真は、いずれも私が会場で撮影したものです。
セッション情報
| 項目 | 内容 |
|---|---|
| セッション ID | D1-DA-03（Google セッション） |
| 日時 | 2026年7月30日（木）14:00 – 14:30 |
| 会場 | Room 4 |
| 登壇者 | 國友 貴文さん（Google Cloud / データクラウド事業本部 セールス スペシャリスト） |
出発点：AI 単体の性能差は、もはや重要ではないのか
セッションは、AI エージェントが持つ5つの能力である「認識」「推論・計画」「行動」「記憶・学習」「自律性」の確認から始まり、その後、AI モデルがどれほど速い速度で進化しているかという話へ移りました。
Gemini 3.5 のベンチマーク比較が示されましたが、そのスライドには「注：2026 年 6 月末時点」という但し書きが添えられていました。
実際、この記事を書いている2026年8月時点では、すでに後継の Gemini 3.6 Flash が
一般提供（GA）になっています（2026年7月21日リリース）。
そのうえで投げかけられたのが、次の問いです。
最新の AI（LLM）は誰もが使える「コモディティ」なツールへ
AI 単体の性能差はもはや重要ではない時代に…?
ではどこで差がつくのか。示された答えは2つでした。
- 企業が保有する独自データの活用：顧客の声や現場の生きたデータを、「AI エージェントがいつでも使える状態」に
- 意思決定・業務プロセスの変革：「一部の業務に AI を使う」というのではなく、「AI エージェントを前提とした業務プロセス」へ
スライドは「重要ではない時代に…?」と疑問符のまま終わっており、モデル性能が無意味だとは言っていません。
ただ、直前に示されたベンチマーク比較へ「2026年6月末時点」という鮮度の但し書きが必要だったこと自体が、モデルの性能差だけを長期的な差別化の軸にしにくい理由を表しているようにも見えました。
示された2つの答えは、どちらもモデルそのものではなく、自社側で何を準備するかという話です。
以下では、1つ目の「AI エージェントがいつでも使える状態」とは具体的に何を指すのかを追っていきます。
データ基盤の役割は「分析基盤」から「業務インフラ」へ
データ基盤の位置づけは、これまでの「「答え合わせ」や予測の為の分析基盤 (SoI)」から「事業・サービス運営の為の業務インフラ (SoA)」へ変わる、と整理されていました。
SoI は System of Insight、SoA は System of Action の略です。続くスライドでは、その違いが3つの軸で示されました。
| System of insight (SoI) 人間の利用を前提とした分析を支える基盤 |
System of Action (SoA) Trusted な エージェントを支える “頭脳” |
|
|---|---|---|
| 規模・スケール | 人間の規模 | エージェントの規模 |
| 求められる役割 | 受動的なインテリジェンス | 自律的な実行 (Action) |
| 必要なアセット | データ | データ + 意味を持つナレッジ |
私が特に気になったのは、3行目でした。
必要なアセットが、単なる「データ」から「データ＋意味を持つナレッジ」に増えています。
この表だけでは、「意味を持つナレッジ」が具体的に何を指すのかまでは説明されていません。
ただ、人がデータを利用するときに頭の中で補ってきた「この指標はこう読む」「この売上にはこの範囲を含む」といった前提を、基盤側のアセットとして持たせるという宣言だと読めます。
中身は後半のコンテキストの3層で具体化されます。
本題：人が使う基盤と AI が使う基盤は、何が違うのか
同じ「データ基盤」でも、人が操作する前提の基盤と、AI エージェントが利用する前提の基盤とでは、負荷のかかり方が異なります。
ここが、このセッションで最もおもしろかった部分です。
人がデータ基盤を操作する場合、分析ユーザーの頭の中では同じ「売上」であってもマーケティング部門と製造部門では見たい範囲や切り口が異なる、といった判断が行われています。
データを抽出するときに必要な前提や背景知識は、「頭の中にある」か、必要に応じて個別に確認するものです。
データ基盤へ実際に負荷がかかるのは、その判断を終えてSQLを実行する段階でした。
一方、AI エージェントの場合は、SQLを発行する前に、次のような工程が発生します。
- コンテキストを理解し、前提を確認する
- 必要に応じて、他のエージェントと同期・連携する
- 最後に、データ抽出のためのSQLを発行する
両スライドの記載を並べると、違いは4つの観点で示されていました。
| 人が操作する前提の基盤 | AI エージェント時代の基盤 | |
|---|---|---|
| 負荷が発生する時点 | 人の「頭の中で処理されて」SQL による抽出時 | 考える「前処理」の時点から（コンテキストの理解を行う等、回答精度を上げる準備が必要） |
| 接続数・頻度 | 人の動作を前提とした接続数や頻度に対応できていればよかった | エージェント (機械) を前提とした接続数や頻度に対応できなければ業務が成り立たない（人の何十倍〜何百倍というレベル） |
| 負荷の予測 | 業務内容によってある程度負荷がかかるタイミングを予測することも可能 | 負荷がかかるタイミングと負荷の規模を予測することが困難 |
| コスト | データ基盤にかかるコストの制御も可能 | コストの制御について慎重に考える必要がある |
特に大きいのは、1行目の違いです。
人が「どうデータを抽出するか」を考える工程はこれまで基盤の外、つまり人の頭の中で完結していました。
しかし、AI エージェントは前提や背景を理解する工程でも、データ基盤やナレッジへ問い合わせます。
これまで基盤負荷として現れていなかった「考えるための前処理」まで、システム上の処理になるわけです。
接続数についても、AI エージェントは一人が一つだけ使うとは限りません。
複数のエージェントが役割を分担し、互いに連携して動く構成も考えられます。
そのため、スライドでは、同時接続数が従業員数との比較で「指数関数的に増加する」と表現されていました。数学的な意味で常に指数関数になるというより、人の利用数から単純に見積もれないほど増大し得る、という意図だと捉えています。
考慮すべきは「品質・性能」と「コスト」の2観点
この変化は、2つの観点に整理されていました。
処理の品質・性能については、AI エージェントがデータ基盤の利用者になることで、従来の「人が操作する前提のデータ基盤」と比較して、次の問題が発生します。
- エージェントの回答品質：正確かつユーザーの意図を理解した回答ができなければ、業務やサービスでは使えない
- 予測しづらい処理量に対応する基盤性能：処理負荷が発生するスパイクが読みにくくなる
- 指数関数的に増加する同時接続数
処理のコストについては、リソース消費やトークン数が大きく増える可能性があるため、これまで以上に精緻な検討が必要だと説明されていました。
- 処理前：「前提や背景を理解する」時点で負荷が発生するため、コストも同時に発生する
- 処理中：増大する処理量に必要なコンピュート リソースの効率化が必要
- 課金体系：AI エージェントの動きを見据えた内容になっているか
3つ目の「課金体系」は、基盤を選ぶ側の観点として実務的で、印象に残りました。
人が叩く回数を前提にした体系のままでは、読みが外れる可能性があります。
回答品質の鍵は、自社のコンテキストをどう持たせるか
エージェントが期待どおりに動かない原因として、2つが挙げられていました。
1つは 「AI の迷い」と不要な試行錯誤（ReACT ループ）。
AI は「どのテーブルとどのテーブルを結合すれば良いか」を推測しなければならず、
無数の確認クエリが走り、推論とエラーを繰り返す無駄なループが発生する。
2つ目は セマンティック（意味論）の欠如。
「「売上」という言葉一つとっても、マーケティング部門と製造部門では見たい軸が異なります」という例が挙げられ、
プロンプトにすべての社内用語や前提条件を毎回詰め込むのは、トークン制限の観点からも非現実的だと述べていました。
ではコンテキストをどう整備・運用するか。セッションでは3層に整理されていました。
- Technical metadata：データ資産全体のスキーマなど技術側面の理解
- Business semantics：自社ビジネス・データに関する用語、ロジック、オントロジー (関係性)、指標の理解
- Personalization：対話の履歴やインタラクションからの、個々のユーザーの傾向の理解
下2層は、自社で棚卸しが必要な部分だと感じました。
先ほどの「独自データの活用」が、ここで具体的な作業に落ちてきます。
Google Cloud が示した打ち手
ナレッジ カタログ（Knowledge Catalog） は
「途切れることのない universal context engine 〜全てのデータを知識の源泉へ〜」と紹介されていました。
SaaS アプリケーション・業務データベース・GCS・BigQuery などのデータソースを Context federation でつなぎ、
上段の各種エージェント
（Native Data agents / Conversational agents / Partner agents / Custom agents / Agentic BI）へ
コンテキストを供給する構成です。
コンテキストを個々のエージェントに持たせるのではなく、共通の層として置く形になっています。
BigQuery Graph Analytics は「散在するデータ間の相関をグラフで構造化し、
エージェントに “点と点をつなぐ” 高度な洞察力を与える」機能で、既存データの上にプロパティグラフを定義して使います。
3層の Business semantics にあるオントロジー（関係性）を、実際に表現するための手段の一つなのだと思います。
なお、登壇時点では New / プレビュー のバッジが付いていました。
BigQuery 自体も「AIエージェントの時代にも有用な性能を発揮します」として、
リアルタイム分析・フルマネージド サービス・エクサバイト単位までのシームレスなスケールの3点が挙げられていました。
おわりに
データ基盤を考えるうえでの論点はかなり具体的でした。
- 差別化の源泉はモデルの性能だけではない – 独自データの活用と、業務プロセスそのものの変革
- 負荷が発生する時点が変わる – SQL 実行時ではなく、エージェントが前提を理解する段階から
- データだけでは足りない – 必要なアセットは「データ + 意味を持つナレッジ」
3点目は今日から着手できる部分だと感じました。
社内用語の定義、指標の計算方法、テーブル間の関係性、部門ごとに異なるデータの見方。これまで人が暗黙に補ってきた前提を、エージェントが参照できる形で残していく作業です。
新しいAIモデルへ乗り換えるだけでは、この部分は整いません。
「AI エージェントを導入するか」ではなく、「AI エージェントが使う前提で、データ基盤と業務上の知識を見直しているか」。
非技術者向けと銘打たれたセッションでしたが、投げかけられた問いは、かなり実務的なものでした。
簡単30秒