はじめまして。stable株式会社 代表の宮﨑一輝（@ikki_mz）です。
stable株式会社は、データエンジニアリングを専門領域として、企業のデータ活用・データマネジメントに関するあらゆるご支援をしています。
今回は「#も読」の第2回の投稿です。
第2回となるこの記事では、ETLツールのAirbyteのテックブログで、AIエージェントにどのようにコンテキストを渡せばいいかということについて書かれた「The Missing Context Layer: Why Your LLM Agent Can't Do More Than Text-to-SQL」という記事について、紹介したいと思います。
記事が主張していること
Airbyteの共同創業者・Michel Tricotによるこの記事は、「セマンティックレイヤーを整備したのに、なぜAIエージェントはまだうまく動かないのか」という問いから始まります。
ちなみに、セマンティックレイヤーについて理解していることが前提となっているため、セマンティックレイヤーって何だ？という方は、以前私が作成した以下のスライドを参考にしてください。
セマンティックレイヤーを構築している会社では、dbt、LookML、Cube等のツールを導入し、メトリクスの定義を統一し、ダッシュボードで表示する指標定義が一致するよう整備してきました。しかし、それでもAIエージェントは正しい分析を行えないという問題が依然としてあります。
なぜ上手くいかないのかというと、AIエージェントが「StripeとZendeskとSalesforceのレコードが、同じ一人の顧客を指している」という事実を認識できないからだ、と筆者は主張しています。
つまり、セマンティックレイヤーは「メトリクスの意味」を定義するという課題の解決にはなるが、「エンティティの関係性」を定義するという課題には対応できていない、というのが記事で主張されている課題意識となっています。
セマンティックレイヤーの問題点
では、現在データチームで多く扱われているセマンティックレイヤーの何が問題なのでしょうか。記事では以下のような要素が不足していると説明されています。
- Identity：同一人物・同一企業を、バラバラなシステムのレコードから見つけ出す必要がある
- Relationships：エンティティがどのように接続されているか、それによってエージェントがエンティティ間を移動できる。
まず、「Identity」について。
一般に、企業の活動においては複数のシステムが運用されています。その中で「同じユーザーが別システムで管理されている」ということは多いです。例えば、Stripe, Zendeskでそれぞれ同一のユーザーが扱われるような場合です。
その際、そのユーザーが同一ユーザーであるということをAIエージェントが認識できないと、AIエージェントができる行動にはかなりの制限がかかってしまいます。そのため「Identity」の要素が必要となってきます。
また、「Relationships」について。
企業では一般に、課金・サポート・CRMなど複数のシステムが並行して運用されています。「顧客」というエンティティひとつとっても、Stripeには注文・返金レコードが、Zendeskにはサポートチケットが、SalesforceにはCRMコンタクトが、それぞれ別々に存在しています。
AIエージェントが横断的なタスクを実行するには、「この顧客には返金がある」「同じ顧客がサポートにも問い合わせている」というエンティティ間のつながりを辿れる必要があります。例えば「顧客」は「注文」と紐づき、「注文」は「決済」や「返金」と紐づくといった関係性をエージェントが参照できることが重要です。セマンティックレイヤーはこの関係性を十分に持っていないため、エージェントは各システムの情報をつなげられず、複雑なタスクで詰まってしまいます。
上記のように、現状のセマンティックレイヤーにおいては、これらの情報が欠落しています。したがって、AIエージェントが柔軟に分析やアクションを起こすには、コンテキストが不十分であるというのが、セマンティックレイヤーの問題点として指摘されています。
オントロジーとは何か
そこで、セマンティックレイヤーの弱点をカバーする代案として紹介されているのが「オントロジー」という概念です。
ここではセマンティックレイヤーの対比として、以下の表で説明されています。
"The Missing Context Layer: Why Your LLM Agent Can't Do More Than Text-to-SQL"
簡潔にいうと、セマンティックレイヤーが「指標や集計軸の意味」を記述したものであるのに対して、オントロジーは「物事のつながり」を定義したものです。
これがあることにより、AIエージェントが複雑な作業を行うことが可能になります。
例えば、「先週返金を受け、かつネガティブなサポート体験をした顧客に、履歴に基づいてパーソナライズしたメールを送る」というタスクに対して、エージェントは次のことを順番にこなす必要があります。
- 課金システムから返金レコードを取得する
- そのレコードを顧客エンティティに紐づける
- 同じ顧客のサポートチケットをサポートシステムから引き出す
- 「ネガティブな体験」という自社固有の定義を解釈する
- CRMのコンタクトとメール送信のアクション権限を確認する
- 書き込みを実行する
各ステップは前のステップの出力に依存します。これは単純な「指標の集計」ではなく、「横断的な分析とタスク」であり、指標を定義するだけのセマンティックレイヤーではナビゲートできません。だからオントロジーのような関係性の定義が必要だ、というのが筆者の主張です。
オントロジー導入の難しさ
概念として正しいとしても、オントロジーの導入には大きな壁が2つあります。技術的な壁と、組織的な壁です。
セマンティックレイヤーの延長にはない？
実は、dbt・Atlanといった既存のセマンティックレイヤーツールも、オントロジーの必要性には気づいていて、エンティティ解決や関係グラフの機能を後付けで追加する動きが出てきています。一見良い流れに見えますが、記事ではこれを「罠」として警鐘を鳴らしています。
メトリクス中心のアーキテクチャにエンティティ機能を足しても、設計の重力は変わりません。オントロジーが真に機能するには、最初からエンティティを中心に設計する必要があり、既存ツールの延長線上では限界がある、というのが筆者の主張です。
したがって、「オントロジー優先」で、まずオントロジーを構築し、その上にメトリクス定義を重ねていくようなアプローチが必要です。これはセマンティックレイヤーに無理やりオントロジーを追加していくのとは全く異なるアーキテクチャです。
誰が管理するのか？
もう一つの壁は、オントロジーの責任者が不在になってしまうという組織的な問題です。
「メトリクスの定義責任者は誰か」と聞けば、多くの組織でアナリティクスエンジニアやデータチームという答えが返ってきます。ではエンティティモデルの責任者は？多くの組織では、沈黙が返ってきます。
エンティティに関する知識は、社内の至る所に存在しています。「SalesforceのAcme CorpとStripeのAcme Corporation Ltdが同じ会社だ」ということは、営業担当者やカスタマーサクセスの人間なら知っています。しかしそれは誰かの頭の中にあるだけで、インフラとして形式化されているわけではありません。
誰の業務にも、「エンティティを保守する」という業務は含まれていません。したがって、誰も保守をしません。必然的に、オントロジーは構築されない、というのが記事の主張です。
逆に、セマンティックレイヤーが普及した背景には、アナリティクスエンジニアという役割が確立され、「メトリクスをコードで定義・管理する」という明確な責任が与えられたからです。オントロジーが同じように普及するには、エンティティモデルを所有し、維持する役割と文化が組織に根付く必要があります。ツールより先に、組織としてそこにコミットするという意思決定が必要となってきます。
感想
ここまで、記事で述べられていることを中心に、私の解釈も交えながら説明してきました。ここからは、私がこの記事を読んだ感想をいくつか書きたいと思います。
AIの発展によりデータ活用の幅が広がっている
まず、この記事が前提としている点として、「AIの発展によりデータ活用の幅が広がっている」という点があると感じました。
これまでは「MAU」「売上」のような、ビジネスにおける特定の断面を指標として定義することにより、ビジネスの状態を測ろうと試みてきました。つまり、「複雑なものを単純化して理解する」という営みが行われてきたのです。そして、そのコンテキストを管理する場所としてのセマンティックレイヤーが注目されてきました。
しかし、この記事で課題として挙げている「先週返金を受け、かつネガティブなサポート体験をした顧客に、履歴に基づいてパーソナライズしたメールを送る」というようなお題は、特定の指標を見るという行為とは全く異なり、AIが「複雑なものを複雑なまま理解」する営みへとシフトしてきています。
これまでのデータ活用では、人間の工数と認知の限界があったため、特定の断面に切り出してデータを見るということがされていましたが、AIはその限界を突破するポテンシャルがあります。より複雑なデータの海を探索的に分析し、インサイトを見つけたり、メールを送ったりといったパーソナライズされたアクションを実行できるようになります。
このように、人間からAIへとデータ活用の主体がシフトしていくことにより、データ活用の幅も広がり、「複雑なものを複雑なまま理解できる」ようになってきているということです。それをするために、複雑なものをコンテキストとして表現する技法に注目が集まっているという解釈をしました。
理想と現実解
今を生きる我々は、常に理想と現実の中で解を見出していく必要があります。
オントロジーの話は理想としては非常に納得感があり、それを構築することができれば、AIに自由にアクションさせることができるようになるので、ビジネスインパクトも大きいと思います。
しかし、想像の通り、オントロジーの構築は難易度が高いのは間違いありません。構築したから終わりという訳ではなく、その後もプロダクトの仕様変更などに追従する必要があるので、定常的なメンテナンスも求められるでしょう。
Palantirという会社は、オントロジーを構築するプラットフォームを提供しつつ、FDE（Forward Deployed Engineer）と呼ばれる専門エンジニアが導入支援を行うという事業モデルをとっています。このことからも、オントロジーの構築というのは、気軽にできるようなものではなく、専門性や投資が必要な領域であることは推察できます。
一方で、セマンティックレイヤーは現実的なソリューションとして機能し始めています。dbtやLightdashを使用している会社はよく聞くようになってきました。セマンティックレイヤーでカバーできる範囲は十分に広いと思うので、ひとまずは現実的な選択をするというのは理にかなっていると思います。
おわりに
この記事では、オントロジーとセマンティックレイヤーを対比させた記事を紹介しました。
最近はAIがデータ分析をすることもどんどん増えてきているので、AIにどのようなコンテキストを渡せばいいのかという論点も非常に盛り上がってきていますね。
オントロジーに関しては、概念としては昔から存在するものではあるものの、現実的なリソースで実装できるようになるまでは、もう少し時間がかかりそうなので、引き続きウォッチしていきたいと思います。
最後までお読みいただきありがとうございました。
今後もデータエンジニアリング領域の記事を書いていこうと思います。普段はXでデータエンジニアリングの情報を発信しているので、興味を持っていただけた方は、ぜひXの方もフォローいただけると幸いです。