市場はようやく理解した：データと分析エージェントが正しいコンテキストを持っていない場合、それは essentially 無意味だ
この記事は翻訳版です。原文は a16z からで、URLは：https://www.a16z.news/p/your-data-agents-need-context
最近、データと AI エージェントのコミュニティでは、コンテキストレイヤーとコンテキストグラフが避けて通れない話題となっている。データと AI に取り組むどの組織とも話をすれば、5分以内にコンテキストの話になる。
これは当然のことだ。過去1年、市場はようやく以下のことに気づいた：
データと分析エージェントは、正しいコンテキストがないと基本的に役に立たない
彼らは曖昧な問題を切り離せず、ビジネス定義を理解できず、散在するデータ間で効果的に推論することもできない。
これはエージェントのせいではない。現代のデータスタックは10年以上にわたって進化し、散在したデータソースから集約されたデータとクリーニングされた定義へと移行してきた。これは良いことだが、集約はいつも完璧ではなく、その過程で多くのノイズが導入されてきた。大まかな進化の流れは以下の通りだ：
1、モダンデータスタックの台頭
以前に dbt の Tristan Handy とこの話をしたことがあり、また自分の参照アーキテクチャの記事でも書いた。過去10年間、データアーキテクチャは取り込み、変換、ウェアハウス、ストレージの各段階で改革が行われ、データを一元化して素早く簡単に利用できるようにすることを目指してきた。理想的な姿は：データがきれいに整理され、チームが少し SQL を書くだけでデータウェアハウスからデータを取り出し、グラフやダッシュボードを作成し、組織全体でビジネスインテリジェンスを活用できる状態だ。
2、エージェントブーム
2024 年から 2025 年にかけて、LLM の能力は飛躍的に向上し、ほとんどすべての組織が既存のデータスタック上にエージェントを構築したいと考えている。以前にエージェントの定義について議論したことがある。組織の視点から見れば、より少ない時間でより多くのことを行い、効率を向上させるという自然な魅力が、みんなをエージェント志向のワークフローに引き寄せている。各社は「データとチャット」するチャットボットやカスタマーサービスエージェントの開発を始めた。このブームはボトムアップとトップダウンの両方で同時に起きている。開発者は最新かつ最も印象的な LLM 能力を使いたがり、経営層は AI の実装を圧力かけて自動化を促進し、コストを削減しようとしている。
3、壁にぶつかる
楽観的な見通しは長続きしなかった。すぐに、この種の取り組みのほとんどが失敗することが明らかになった。組織はエージェントを導入したが、壁にぶつかった。MIT は著名な「2025 年ビジネス AI の現状」レポートを発表し、AI の導入が「ほとんど失敗する理由は、脆弱なワークフロー、コンテキスト学習能力の欠如、そして日々の業務との乖離」であると述べた。
エージェントのパフォーマンスが悪化する重要な理由の一つは、
適切なデータコンテキストの欠如
である。今日の企業データは依然として極度に散在し、混乱している。データエージェントは「前四半期の収益増加率はどれくらい？」という質問にもうまく答えられない。なぜなら、構造化データと非構造化データのさまざまなアーキテクチャに直面しているからだ。
何年も前に掲げられた「完全セルフサービス分析」のビジョンは実現されておらず、データエージェントのビジョンについても同じ道を歩んでいるように見える。
最初のエージェント導入波がなぜうまくいかなかったのか、その根本的な問題は text-to-SQL だけではない。
当初は多くの人が、問題はモデル側にあると考えていた。つまり、データ推論能力や SQL コード生成能力が不足していると考えられていた。一般的な考え方はこうだ：モデルは自然言語クエリを受け取り、既存のデータシステムに対して推論を行い、従来の BI の方式に従って対応する SQL コードを生成し、正しいデータを取得して質問に答える。モデルが失敗したり不正確だったりすれば、それはモデルが SQL をうまく書けないからであり、時間が解決するだろうと考えていた。
この考え方も完全に間違いではない。モデルのコード生成と数学的推論能力は確かに大幅に向上したが、データ分野ではまだ遅れを取っている。Spider 2.0 や Bird Bench といった SQL ベンチマークがそれを裏付ける。モデルの能力は確かに飛躍的に向上したが、すぐに気づいたのは、問題が text-to-SQL の範囲をはるかに超えているということだ。
収益増加の例をもう少し詳細に見てみよう：
1. 組織内部にデータエージェントが構築されていると仮定する。最新の基盤モデルを使用し、必要なすべてのデータソースに接続し、見栄えの良いインターフェースを備えて、社内ユーザーがデータに関する質問をできるようにしている。
2. クエリが届く。「前四半期の収益増加率はどれくらい？」一見するととてもシンプルな質問だ。普段は Looker や Tableau のダッシュボードをちらっと見れば答えられるし、高度な知能を持つエージェントなら難しくないはずだ。
課題1：エージェントはこの組織における「収益」と「四半期」の定義をどうやって知るのか？収益は実際にはビジネス定義であり、データウェアハウスやパイプラインにハードコードされているわけではない。ユーザーは run rate 収益を見たいのか、ARR なのか？財務四半期の区切りは組織によって全く異なり、ある会社の「四半期」が他の会社では全く異なる3か月を指すこともある。どの時間窓を見るべきなのか？
3. 幸いにもデータプラットフォームの責任者が立ち上がって言った：「我々はこの問題を解決するためにセマンティックレイヤーを構築しました。収益の定義はそこにあります。」エージェントはすべてのセマンティックレイヤーをコンテキストとして取り込むべきだ。聞こえは良い。しかしチームがいくつかの YAML ファイルを調べたところ、これらのファイルは去年退職したデータチームのメンバーが更新したもので、BI ツールはもうそれを参照しておらず、さらにその後にリリースされた2つの製品ラインも含まれていなかった。エージェントは今日の収益がどのように計算されるのかを全く知らない。
4. この障壁を回避するために、誰かが収益と時間窓の定義をハードコードで組み込んだ。データエージェントは動作を続けるが、すぐにまた壁にぶつかる。
課題2：正しいデータソースはどこにあるのか？どれが真実のソースなのか？元データは複数のテーブルと複数のデータウェアハウスに散在している。財務チームは
fct_revenueテーブルを使っている——これが正解かもしれない。しかしデータチームは物理ビューも作成しており、mv_revenue_monthlyとmv_customer_mrrがそこに置かれている。
はっきりしているのは、データエージェントは業務定義とデータソース情報を備えた継続的に更新されるナレッジベースが必要だということだ。これによりこれらの障壁を乗り越えることができる。
コンテキストレイヤーの登場
問題の核心はここにある：
エージェントに適切なビジネスコンテキストが与えられていない
ため、最も基本的な質問にも答えられない。これはもっと大きな欠点を反映している。組織内部で自動化された AI システムを構築するには、継続的に更新・維持されるコンテキストが必要だ。このコンテキストは、企業の運営方法、データシステムの構造、そしてすべてをつなげる部族の知識を理解しなければならない。
そのためにコンテキストレイヤーが生まれた。今日の議論では、Context OS、Context Engine、コンテキストデータレイヤー、オントロジー（ontology）などさまざまな名前が出てくる。底辺の考え方は同じだ：企業内部の混在したデータをつなぎ合わせ、その上にエージェントがビジネスロジックを理解するのに役立つコンテキストレイヤーを追加し、それをカプセル化してエージェントが利用できるようにする。
コンテキスト管理の既視感
ここで立ち止まってみよう……私たちが言っていることは、意味レイヤー（semantic layer）と酷似していないか？
確かに類似点はある。しかしエージェントのワークフローが真に自律化されるためには、現在の意味レイヤーが提供できるもの以上のものが必要になる。
伝統的な BI の文脈における意味レイヤーは、収益、 churn rate、ARPU といった特定の指標定義の処理に長けている。しかし通常はデータチームが非常に特殊な構文を使って手作業で構築され、LookML のような専用レイヤーで記述され、Looker のような BI ツールに直接接続されている。
現代のデータコンテキストレイヤーは、従来の意味レイヤーがカバーする範囲のスーパーセットであるべきだ
特定の指標定義はもちろんハードコードできるが、エージェントの自律性を確保するためには、現代のコンテキストレイヤーはさらに多くを含まなければならない：標準化されたエンティティ、アイデンティティ解決、部族の知識を解明する具体的な指示、適切なガバナンスガイドラインなどである。
本文は主に伝統的なレコードシステムのデータをつなぐデータコンテキストに焦点を当てている。もうひとつ同様に重要で重複する機会は、組織の意思決定ロジックとワークフローロジックを捉えることだ。これにより真に汎用的なエージェントを作り出し、組織のすべてのデータと意思決定コンテキストに根ざさせることができる。
すべてをつなげる
最近のお客様とのやり取りと要件の理解に基づき、モダンなコンテキストレイヤーがエージェント志向のデータシステムとどのように連携すべきかを、ステップバイステップで示す。
1、正しいデータへの接続
最初にやるべきことは、すべての正しいデータがアクセス可能であることを確認することだ。これは基本中の基本。理想的には、組織はいかなる形のモダンデータスタックを使用し、レイクハウスアーキテクチャである程度の統一を行っているべきだ。それでも、エージェントが必要とするすべてのデータにアクセスできるようにする必要があり、それはウェアハウスやオペレーティングアプリケーション内に既にあるデータの範囲を超える可能性もある。社内システムに蓄積された部族の知識、GDrive 内のファイル、Slack の会話もすべて含まれる。
2、コンテキストの自動構築
データにアクセスできるようになったら、次はコンテキストレイヤーの構築を始める。LLM の利点は、初期のコンテキスト収集作業がかなりの程度自動化できる点だ。焦点を当てるべきは
高信号のコンテキスト
である。例えば過去のクエリログを振り返れば、最も参照されている表や最も一般的な JOIN を効率的に見つけ出すことができる。dbt や LookML といったデータモデリングツールは、ビジネス指標の明確な定義を提供できる。
3、人間による調整
自動的なコンテキスト構築は語彙の大部分をカバーできるかもしれないが、完全な絵を組み立てることはできない。エージェント自身が内部知識をすべて収集するというのは魅力的だが、最も重要なコンテキストのいくつかは暗黙的で条件付きであり、歴史的な偶然に関連しており、チーム内部の部族の知識の中にしか存在しない。
人間からの入力は、エージェントの真の自動化を可能にする最後の重要なつながりを提供する。例えば：「CRM データ、2025 年以降の北米での新規取引は Affinity を参照し、以前の全世界のリードは Salesforce を参照する。」
こうしてコンテキストレイヤーは、コードと自然言語が共存し、エージェントが必要とするすべてのコンテキストを捕捉する多次元のコーパスになる。開発者が .cursorrules ファイルを設定してエージェントを誘導し、出力動作を制御できるのと同じように、データ専門家も自身のルールとガイドラインを維持できる。
4、エージェントへの接続
コンテキストレイヤーが完成したら、それをエージェントに公開し、リアルタイムでアクセス可能にするだけだ。通常は API または MCP を介して実現される。
5、自己更新するコンテキストフロー
システムは構築されたが、データシステムは決して静的ではない。したがってコンテキストレイヤーも静的であってはならない。上流のデータソースやフォーマットは変わる可能性があり、担当者はビジネスニーズの変化に応じてカスタム指示を追加・削除・修正したいかもしれない。データエージェントが間違ったデータを出力した場合は修正が必要だが、その修正内容も当然コンテキストレイヤーにフィードバックすべきだ。こうすることで、コンテキストレイヤーは生き続け、進化し続けるコーパスになる。
コンテキストレイヤーアーキテクチャ
この一連のプロセスから見て取れるのは：
品質の高いデータエージェントを構築することは決して簡単ではない
技術的にはデータインフラストラクチャとエンジニアリングの課題があり、人的側面では部族の知識の収集という課題があり、これらが絡み合っている。
OpenAI チームは最近、自分たちの内部データエージェントの作成プロセスについて詳しく説明した優れた記事を発表した。透明性が高く、実装は細部にわたって洗練されているが、そこに到達するまでにどれだけの道のりが必要だったかも示している。Palantir は組織のためのオントロジー構築において長い歴史を持ち、混沌としたデータからクリアなコンテキストを引き出すことができる。これをビジネスとして大きく育ててきた。
市場の動向
上で述べたことは、外部ソリューションへの道を開く自然な流れだ。現実的に言えば、すべての企業が内部でこのシステムを構築できるわけではなく、すべきでもない。さまざまなソリューションが市場に現れ始めている。
私たちはまだ早期段階だと考えているが、今形成されているソリューションのハイレベルな市場マップは次のようになる：
市場地図
いくつかのカテゴリに分けて見ていこう：
データ引力プラットフォーム
Databricks と Snowflake などのプラットフォームは、データの取り込み、変換、保存のフルフローを経験済みで、データ引力効果が強い。これらのプラットフォームはすでに AI データ分析製品を提供している——例えば Databricks Genie と Snowflake Cortex Analyst——データウェアhouse の上に構築され、基盤モデルを使って text-to-SQL を行い、ユーザーが自然言語でデータをクエリできるようにしている。これらのプラットフォームは現在のところ成熟したコンテキストレイヤー機能を持っていないが、軽量なセマンティックモデリングをサポートしており、買収や内部開発を通じてプラットフォームにコンテキストレイヤーを組み込む道筋は開けている。
既存の「AI データアナリスト企業」
すでにいくつかの企業が登場し、AI を使って顧客に「データとチャット」させている。多くの企業は市場で試行錯誤を繰り返した結果、データエージェントを成功させる鍵は実はコンテキストレイヤーの構築にあることを悟った。そのため、いくつかの企業はデータコンテキストの構築を製品の核心部分にしている。
新興の専門コンテキストレイヤー企業
ゼロからコンテキストレイヤーを構築する新しいカテゴリが出現した。これらの企業は前述したフルパス——データの取り込み、部族の知識の収集など——を歩まなければならない。そして新しい顧客ごとに、このプロセスを最初からやり直す必要がある。
今後の展望
私たちは今、興味深い節目に立っている。コンテキスト不足という問題はようやくはっきりと見えてきたが、解決策の構築はまだ非常に早期段階にある。
未来は期待できる。もしかしたら真のセルフサービス分析のビジョンがついに完全に実現できる日が来るかもしれない。BI、データ分析、データサイエンスは、AI によって本当に変えられるかもしれない。
もちろん、まだ多くの疑問が残っている。このコンテキストレイヤーはどこに置くべきなのか？同時に複数の場所に存在できるのか？独立した製品になるのか？