AI エージェント向けデータ層の設計：トランザクションシステムから MCP とセマンティックモデルへ

https://www.infoq.com/ のホーム

プレゼンテーション一覧

AI エージェント向けデータレイヤーの設計：トランザクションシステムから MCP、セマンティックモデルへ

プレゼンテーションを見る

再生時間:

ダウンロード

51:35

スライド 1/presentations/enterprise-data-architecture-ai-agents/en/slides/slide-1786964496782.jpg)

まとめ

Fabiane Nardon 氏は、トークン消費の激しい AI エージェントに対応するために TOTVS がどのように企業データを準備しているかを解説します。精度、セキュリティ、コストのバランスを取りながら、決定論的なロジックと非決定的な大規模言語モデル（LLM）をどう統合するかについて議論します。また、データメッシュ、低遅延データベースアーキテクチャ、セマンティックオントロジー、そして文脈ウィンドウの最適化やトランザクションシステムにおけるトークンオーバーヘッド削減のための動的 MCP ツール選択などについても詳しく説明します。

登壇者紹介

Fabiane Nardon 氏は、20 年以上にわたり大規模データシステムのアーキテクチャを手がけてきた技術リーダーです。現在、TOTVS でデータインテリジェンス部門を率いています。ガバナンス、セキュリティ、コスト効率の高い運用（トークン使用量の最適化や信頼性の高い検索を含む）を基盤とし、LLM やエージェント駆動型製品の実現を支えています。Java Champion であり、SouJava の共同創設者でもあります。

コンファレンスについて

QCon AI は、これらのワークロードを安全にスケールさせるために必要なエンジニアリングの分野に特化した、実践者主導のイベントです。参加者は、他社が本番環境で採用しているアーキテクチャのプレイブックや障害指標に直接アクセスできます。

INFOQ EVENTS

9 月 17 日午後 1 時（EDT）

PR の向こう側：エージェント型ソフトウェアデリバリーの新たなコントロールプレーン

登壇者：モヒト・スーマン氏（Harness 上級プロダクトマネージャー）

詳細はこちら

10 月 8 日午後 12 時（EDT）

AI が開発を加速させる中、CI パイプラインは追いつけるか？

登壇者：エリック・メタジ氏（Datadog ソフトウェアデリバリープロダクトマーケティングマネージャー）、ロヒン・チャンドラ氏（Datadog CI/CD 最適化プロダクトマネージャー）

詳細はこちら

講演要旨

ファビアーネ・ナルドン： 私はファビアーネと申します。TOTVS で働いています。TOTVS は、おそらく皆さんが聞いたことのない最大のテック企業のひとつでしょう。同社は過去 40 年間、ブラジルでエンタープライズシステムの構築に注力してきました。SaaS やオンプレミス型など、あらゆる形態のシステムを提供しています。ブラジルの GDP の約 4 分の 1 が、当社のシステムを通じて処理されています。ブラジルは決して小さな市場ではなく、世界第 10 位の経済大国です。

AI エージェントの開発を始めた際、私たちが直面した課題はデータの不足ではありませんでした。むしろその逆で、データが多すぎて困ったのです。しかも、エージェントがアクセスできる状態に整えられてはいませんでした。ここ数年、エージェントの構築に関する知見は大きく進化しました。現在では複数のエージェント・フレームワークやオーケストレーション手法、評価指標も確立されています。

しかし、私たちのデータは本当に準備できていたのでしょうか？数分間に数百もの予測不能なクエリを発行し、トークン消費が激しくレイテンシに敏感な推論ループに対応できるでしょうか。トランザクションシステムに蓄積されたデータは、あくまでアプリケーションからのアクセスを前提として最適化されているのです。

データレイクに蓄積されたデータは、データアナリストやダッシュボードによるアクセスを前提として最適化されています。しかし、AI エージェントがそのデータを直接利用することを想定した設計にはなっていません。

さらに別の課題もあります。エンタープライズグレードのエージェントについて語る際、私たちは通常 99.99% の精度が求められるトランザクションシステムを指しているのです。一方で、AI エージェントは確率的な推論に基づいて動作します。トランザクションシステムと同じレベルの精度をエージェントに求めることは不可能であり、この現実とどう向き合うかが問われます。

おそらく、AI を組み込んだエンタープライズシステムが導入されることで、ユーザーがシステムとどのように関わるかという仕組み自体も変化していくでしょう。

本講演では、OpenClaw などで作成可能なコーディングエージェントや個人向けエージェントの話はしません。私が取り上げるのは、エンタープライズグレードのエージェントです。これらのアプリケーションを構築する際に、データをどう準備し、どう提供すべきかに焦点を当てて解説します。

決定論的モデルと非決定論的モデル

現在、AI と従来のソフトウェアを組み合わせる開発において重要なのは、決定論的なソフトウェアの性質を理解することです。過去40年間にわたって構築されてきたソフトウェアは、すべて決定論的な計算モデルに基づいていました。しかし今や、非決定論的な計算モデルも登場し、両者が融合する時代を迎えています。

この2つを組み合わせることで、はるかに強力なアプリケーションを実現できます。どちらか一方のモデルを選ぶという問題ではなく、「どの部分を決定論的モデルに委ね、どの部分をAI に任せるか」をどう設計するかという課題です。アプリケーションの成否は、両者の境界線をどこに引くかを理解しているかどうかにかかっています。具体的には、ソフトウェアのどの機能を決定論的部分へ送り、どの機能を生成AI やLLM（大規模言語モデル）へ委ねるべきかという判断が問われます。

この判断基準となるのは、「精度」「セキュリティ」「コスト」という3 つの変数からなる公式です。これら 3 つは、いかにしてこれらのシステムにデータを供給するかによって大きく左右されます。

精度

精度、つまりエージェントがより良い回答を出すための方法について話し始めましょう。特に私たちにとって最初の課題は、多くのシステムがオンプレミスで稼働しているトランザクションシステムであるという点です。データはどこから取得するかを決定する必要があります。もちろん、データの主要なソースは ERP や CRM などのトランザクションシステムになります。システムは SaaS でもオンプレミスでも構いませんが、そこが主要なデータ源となります。

AI をトランザクションシステムに直接接続するだけでは、いくつかの問題が生じる可能性があります。通常、これらのシステムは予測不能な多数のクエリを受け付けるように設計されていないからです。また、データを準備するために必要な履歴処理を実行するための十分な計算リソースを持っていない場合もあります。あるいは、ノイズの多い不良データが含まれており、エージェントに送信する前にデータのクリーニングが必要になることもあります。さらに、セマンティック検索の実行が必要なケースもありますが、これらの古いデータベースやレガシーシステムではセマンティック検索がサポートされていない可能性があります。

ベクトルデータベースや同様の仕組みが必要です。データをデータプラットフォームへコピーする理由はいくつかありますが、プラットフォーム上で必要な準備を整えた後、エージェントが MCP やその他のデータアクセスプロトコルを通じてそのデータを利用できるようにします。

ここで注意すべき点は、データプラットフォーム内の情報はトランザクションシステムに比べて常にわずかに遅延していることです。ワークフローや実施内容によっては、データを直接トランザクションシステムから取得する必要があります。

重要なのは、どちらか一方だけを使うかという選択ではなく、解決しようとするワークフローに応じてこれらの2つのデータソースを組み合わせることです。これが当社の推奨事項であり、いつトランザクションシステムからデータを取得し、いつデータプラットフォームを利用するかという判断基準となります。

トランザクションシステムへのアクセスは、データを書き込む必要がある場合に限定すべきです。データプラットフォームに一旦書き込んでからトランザクションシステムへ転送するような迂遠な手順は避けるべきでしょう。書き込み操作が必要な場合は、直接トランザクションシステムを参照します。

また、データプラットフォームにある遅延のあるデータでは対応できないほど鮮度（フレッシュネス）が求められる場合も、やはりトランザクションシステムにアクセスする必要があります。あるいは、トランザクションシステム内に実装されたビジネスルールを実行したい場合にも、同様にそこへ向かうべきです。

一方、多少の古さ（ステイルデータ）を許容できる場合や、履歴データの処理が必要な場合、トランザクションシステムでは提供できないようなセマンティック検索機能が必要となる場合は、データプラットフォームを利用するのが適切です。さらに、外部ソースからデータを取得して精度を高める必要がある場合も、データプラットフォームが適しています。

このように、データの鮮度要件や処理目的に応じて、適切なデータソースを選択することが重要です。

AI エージェント時代に向けたデータプラットフォームの準備についてお話ししましょう。

ここ数年、多くの企業がデータメッシュアーキテクチャへの投資を決定しました。特に企業内に複数の部署に大量のデータが存在する場合、このアーキテクチャは非常に興味深いものです。データメッシュではデータを分割し、ドメイン間で分散配置します。各ドメインは特定のビジネス領域やデータ種別に特化しており、それらすべてのユーザーがセルフサービス型のデータプラットフォームを利用できます。これにより、各ドメインのデータアナリストはビジネスに集中してデータを準備でき、基盤となるデータプラットフォーム自体の管理を気にする必要がなくなります。

このようなアーキテクチャは非常に人気を集め、特に組織内のデータを整理しようとする企業のガバナンス課題を数多く解決しました。データメッシュには、データアーキテクチャにとって不可欠な重要な概念があります。

それが「データプロダクト」という概念です。データプロダクトとは、他者がアクセスできるように準備されたデータの塊を指します。これには必ずデータオーナーが配置され、データの品質維持や管理の責任を負う人物が必要です。また、共有するデータのスキーマを変更しないよう、安定したインターフェース契約も必須です。さらに、適切なドキュメント、検索性、そして品質に関する SLA（サービスレベルアグリーメント）も整っている必要があります。データプロダクトは、データにおけるマイクロサービスのようなものです。企業内のデータを整理し、他者と共有するための非常に優れた方法と言えます。

MCP ツールの設計を始めた際、私たちはデータプロダクトと連携してデータを取得するよう MCP ツールを設計することを決断しました。各ツールはデータプロダクトの一部として位置づけられます。

つまり、すべてのツールには明確な所有者がおり、安定したインターフェース契約、ドキュメント、検索性、そして品質に関する SLA（サービスレベルアグリーメント）が必須となります。これらの要件を満たすことで、MCP ツールはデータプロダクトと非常に相性が良くなります。

このアプローチを採用すれば、データメッシュから得られるガバナンスの恩恵をそのまま享受できます。なぜなら、ツールがドメインごとに整理され、データメッシュ内に配置されるからです。各ツールの所有者が誰であるかも明確になり、それを支えるデータプラットフォームからは利用状況やパフォーマンスに関する統計情報を取得可能です。

具体的には、「このツールは現在も使われているか」「どのように利用されているか」「性能はどうかなど」を把握できます。企業内でツールが多すぎると管理が行き届かなくなる「ナイトメア」状態に陥りがちですが、こうした仕組みがあれば、誰がどのツールの責任者なのかを明確にできるのです。

データメッシュとそのアーキテクチャを支えるデータプラットフォームを構築済みであれば、MCP ツールをデータプロダクトに接続するだけで、同じアーキテクチャを活用したガバナンスが自動的に実現します。従来の get_schema や generate_query のような汎用的なツールを使うのではなく、データを理解し、ビジネスの文脈に沿った正確で実用的な方法でデータを取得できる専用ツールを用意しましょう。データプロダクトごとに、その業務データとルールを熟知するツール所有者が最適なツールを作成すれば、汎用ツールに頼る必要はなくなります。

しかし、それを実現してもなお、あらゆる企業で共通して直面する「意味論的な問題」が残ります。例えば、「アクティブな顧客」とは何かと社内の各部門に尋ねれば、マーケティング部門と財務部門では異なる答えが返ってくるのが普通です。

合意形成は非常に困難です。かつて私が勤務していた企業では、関係者全員が納得できる「チャーン（離脱）」の定義一つを定めるために、会議に1週間も費やしましたが、結局合意には至りませんでした。問題となるのは定義が複数存在することそのものではなく、「たった一つの定義しかない」と思い込んでいる点にあります。そんな状況は決して起こり得ません。

しかし、複数の定義が存在するからこそ、人間同士のコミュニケーションではうまく機能します。マーケティング担当者と会話している際、「アクティブな顧客」について話せば、その企業で長く働いている人なら、自分にとってそれが何を意味するかを理解できるでしょう。

ところが、LLMやAIエージェントに対して同じことを行うと、彼らにはそのような感覚がありません。そのため、エージェントが概念をより深く理解できるよう、私たちはより多くの情報を提供する必要があります。

実は、その課題を解決してくれる非常に古い技術がすでに存在します。それが「セマンティック・ウェブ（Semantic Web）」です。

2001 年、ウェブの父と呼ばれるティム・バーナーズ＝リーは、ウェブ上に存在する情報に意味を持たせるための一連の標準規格を提案しました。今回の登壇準備のために、私は彼が 2001 年に『サイエンティフィック・アメリカン』誌に掲載した記事を読み直しました。そこではセマンティック・ウェブの概念とその仕組みが詳しく解説されていました。

その記事を読むと、エージェント同士が互いに意思疎通を行い、理解し合い、人々の課題を整理して解決する世界が描かれています。具体的には、あるエージェントが医療処置のスケジュール調整を試みる様子が紹介されていました。

この 25 年前の記事を読み返した際、実際にこの技術を応用してセマンティックな問題を解決できる段階に至るまでに、これほど長い年月がかかったことに驚きました。

記事の中で、著者は AI エージェントが『スター・ウォーズ』の C-3PO のような大規模な人工知能を必要とせずとも、これらの情報をすべて把握できると述べています。しかし、彼は少し楽観的すぎました。実際にここまでの技術到達には 25 年もの歳月がかかったのです。

現在では、この技術を自らのために活用する時代がやってきました。朗報は、その 25 年の間に蓄積された膨大な事例を基に現在の LLM（大規模言語モデル）が訓練されている点です。そのため、セマンティック・ウェブで提案される技術の理解も非常に深まっており、これが私たちの大きな助けとなっています。

では、セマンティック・ウェブとは何でしょうか？ティム・バーナーズ＝リーは RDF という標準規格を提唱しました。RDF の核心となる考え方は、扱うべき各概念に一意の識別子（ID）を与えることです。例えば「アクティブ顧客」という概念の場合、マーケティング部門用と財務部門用でそれぞれ異なる識別子を割り当てます。名前は同じでも、異なる識別子を持つことで複数の概念を区別し、曖昧さを排除することが可能になります。

オントロジーを表現するための標準規格も存在します。オントロジーを用いることで、異なる概念間の関係を定義できます。これに RDF（Resource Description Framework）を組み合わせれば、概念の意味論的な側面を明確にできます。

この情報を大規模言語モデル（LLM）に与えれば、AI エージェント向けの文脈グラフが構築され、データの意味論的構造が確立されます。私は 20 年前、インテリジェントシステムにおける推論能力の向上を目指して「セマンティック・ウェブ技術」を専攻し、博士号を取得しました。

当時はオントロジーを作成することが最大の課題でした。特定のドメインに特化したオントロジーを作るには膨大な労力が必要だったのです。しかし現在では、データに関するドキュメントを整備し、LLM を活用すれば、オントロジーの作成は非常に容易になりました。これが、これらの技術を実際に実用化するまでに時間がかかった理由の一つです。

SF の世界から、現実の世界でこれがどう機能するかを見てみましょう。これは特別なトレーニングや特別な設定を行わない通常の ChatGPT で私が作成した例です。

ChatGPT に 3 つのデータを与えました。「Acme はサーバーを 10 台購入した」「Beta はライセンスを 50 個購入した」「Gamma はキーボードを 20 本購入した」という情報です。そして「どの顧客がハードウェアを購入したか？」と質問しました。

LLM は、サーバーはおそらくハードウェアであると推論できるという自身の知識に基づき、「Acme と Gamma がハードウェアを購入した」と回答しました。

ここで ChatGPT にオントロジー（概念体系）を与えてみます。OWL はセマンティック・ウェブの標準規格の一つで、オントロジーを表現するために使われます。「以下の質問に答える際、この OWL オントロジーを考慮してください」と指示します。

オントロジー内では、概念間の関係性をマッピングしました。具体的には、「サーバーはクラウドサービスのサブクラスである」と定義しています。つまり、LLM に対して「これはハードウェアではなく、ソフトウェア、すなわちサービスである」と伝えているのです。

その後、ChatGPT に再度事実を提示した際、単に「サーバーを購入しました」と答えるのではなく、概念の一意識別子（ID）を活用しました。具体的には、「Acme が 10 台のサーバーを購入した」という文脈で、私が言及しているのが特定の RDF 識別子を持つサーバーであることを明示したのです。

同じ質問を再度投げかけたところ（「どの顧客がハードウェアを購入したか」）、ChatGPT は以下のような回答を返しました。これにより、ChatGPT がオントロジーの構造を十分に理解し、適切な回答を提供できることが確認できました。

ここ数年、こうした技術と大規模言語モデル（LLM）の活用を比較する研究が複数行われており、精度向上の可能性が示されています。例えば 2024 年のある研究では、オントロジーに基づくセマンティック層を追加することで、LLM の回答精度が 40% 向上することが実証されました。より高い正答率を示す最新の研究成果もありますが、その効果はデータのフォーマットやドメインの特性に依存します。

これは、単に LLM をデータに適用するだけの場合と比較して、非常に優れた成果です。

ここで重要なのは、セマンティック（意味情報）を付与したデータ製品を MCP ツールに接続し活用することです。このアプローチの利点は、私が熟知しているデータ製品の文脈に基づき、必要なセマンティック情報を正確に返却できる点にあります。MCP ツールとデータ製品を連携させることで、オントロジー全体をコンテキストに送信するのではなく、そのデータ製品に関連する部分だけをフィルタリングして提供できます。大企業ではオントロジーが膨大な規模になることが多いため、必要な情報だけを抽出して送ることは、コンテキストの効率化において極めて重要です。

ここ数年、データプラットフォームが単一のツールから多様な機能を備えた「工具箱」へと進化していることに気づいた方も多いでしょう。数年前であれば、データプラットフォームは Apache Spark しか使えないか、あるいは Athena や Hadoop に依存するものでした。

しかし現在では、複数のデータプラットフォームがそれぞれ異なる種類のツールを提供しています。これは AI エージェントの文脈において特に理にかなっています。例えば、当社のデータプラットフォームには3つのレイヤーが存在します。

まず一つ目は、Parquet ファイルのバッチ処理を行う高遅延レイヤーです。Apache Spark を基盤としており、大規模なデータ量を低コストで処理できます。

次に必要となったのが中程度の遅延を持つレイヤーです。当社のケースでは Google BigQuery がこれに該当します。こちらも大量のデータを扱えますが、コストは高くなります。BigQuery は無限の予算があれば非常に高速に動作しますが、現実的にはそうはいかないため、費用対効果を考慮する必要があります。

エージェント向けに必要だったのは、データプラットフォーム内に低遅延のレイヤーを提供することです。当社のケースでは Postgres と DuckDB を基盤としており、小規模なデータ量をより低コストで処理できる仕組みを構築しました。ただし、すべての処理はデータプラットフォーム内の統一されたインターフェースによってオーケストレーションされています。

その理由の一つは、統合された環境が必要だからです。これにより、Spark でデータパイプラインを作成する際と同じ感覚で、BigQuery や Postgres 上でも同じようにパイプラインを構築できます。当社ではすでにそのような統一インターフェースを提供しています。

最近、いくつかのデータプラットフォームベンダーが同様の発表をしているのに気づいた方もいるでしょう。例えば Databricks も、Postgres のサポートを開始すると発表しました。当社はすでに約2年間この取り組みを進めており、エージェントへの対応と低遅延オプションの提供が必要だったからです。

AI エージェントにおいて、なぜ低レイテンシが必要なのでしょうか。これは興味深い点です。従来、データプラットフォームについて語る場合、その目的は履歴データの処理にありました。データアナリストやデータサイエンティストがダッシュボードを作成し、トランザクションシステムから直接アクセスするのではなく、このデータを活用していました。

しかし今、データプラットフォームを通じて AI エージェントにデータを提供する場合、求められるものは異なります。依然としてデータプラットフォーム内では履歴処理を行い、データの準備を続ける必要がありますが、そのデータをサービス提供する際のレイテンシは、以前とは全く異なるものが求められます。

データプラットフォームにおける低レイテンシには、2 つの側面があります。まず 1 つ目は「処理時の低レイテンシ」です。データプラットフォームにデータを受信した瞬間から、そのデータが提供可能な状態になるまでの時間を、極めて短く保つ必要があります。

AI エージェントがデータを取得し、クリーニングし、利用可能にし、最新の状態に保つためには、可能な限り最短時間で処理を完了させる必要があります。もちろん、すべてのデータ処理を高速で行うことは現実的ではありません。特に大規模で複雑な処理が必要なケースでは、Apache Spark などのツールを用いることになりますが、その結果として得られたデータをエージェントが低遅延で検索・取得できる状態に整えることが不可欠です。

ここで言う「低遅延」には二つの側面があります。一つは処理自体の高速化であり、もう一つはデータ検索時の応答速度です。我々が低遅延レイヤーを設計する際、ベンダーロックインを避け複数のクラウド環境で活用できる汎用性のあるアーキテクチャを目指しました。同時に、コスト効率が高く、高速かつ信頼性があり、セマンティック検索（意味に基づく検索）もサポートできる仕組みを構築することを重視しています。

まず、最初のステップでデータを取得した際に、変換パイプラインが即座に起動するように設計する必要があります。このパイプラインは高速で動作し続けることが求められます。

さらに重要なのは、このパイプラインを「アトミック（不可分）」なものとすることです。つまり、データの整合性が保たれるようにします。データを取得した瞬間から処理が開始され、最終的に正しいデータが揃うことを確信したいのです。

ここで言及しているのは、少し古く感じる技術かもしれません。しかし、この問題を解決できる非常に優れた技術が存在し、それは「トランザクションデータベース」です。私たちは Postgres を採用してこの課題を解決しました。

最初のレイヤーで生データ（raw data）を取得すると、トリガーが作動します。これにより一連のストアドプロシージャが実行され、最終的にパイプラインの末端でトランザクションが完了し、データの整合性が保証されます。派手な技術ではありませんが、非常に効果的です。

このパイプラインは、処理内容に応じてミリ秒から数秒で実行可能です。PostgreSQL を基盤とし、データプラットフォーム上の他の技術と組み合わせることで、非常に興味深い活用が可能です。例えば、Parquet ファイル形式の BigQuery データを Apache Spark で結合し、その結果を PostgreSQL テーブルに保存することもできます。ユーザーにとっては、統一された処理インターフェースを通じてこれらの操作が透明に行われるため、意識することなく利用できます。

データプラットフォームを利用すれば、必要なだけ多くのデータパイプラインを作成でき、使用するエンジンを選択するだけで済みます。こうしてデータを結合・加工することで、最終的に AI エージェントが活用できる状態に整えることができます。異なる処理手法を組み合わせることも可能です。

低レイテンシ層は、エージェントからの質問への即時回答や、PostgreSQL 内のベクトルデータベースを活用したセマンティック検索に対応しています。現在、私は「意味情報を持つデータプロダクト」「低レイテンシ層」「その上にある MCP ツール」という3つの要素を構築しています。

ツールとは、事前に定義された PostgreSQL クエリのことです。また、データプラットフォーム自体にも、新たなツールを作成するための機能を提供しています。すべてのツールが別々のシステムやプログラムで管理されているわけではありません。PostgreSQL データベースを活用してデータプラットフォーム内で作成され、低レイテンシでのアクセスを可能にしています。

セキュリティ

セキュリティについて話しましょう。データベースからデータを取得する際、非常に一般的なアプローチとして、スキーマを読み取って LLM にクエリを書かせる汎用ツールを作成する方法があります。もちろんこれは柔軟性が高い反面、プロンプトインジェクションに対して脆弱です。

より安全なアプローチが存在します。私たちが採用しているのがそれです。具体的には、パラメータ付きのツールを作成し、セキュリティをツールコードに組み込むことで、LLM にコード生成を行わせないようにする手法です。もちろんこれは柔軟性が低下しますが、エージェントがアクセスできるのは、それを取得できるツールが存在するデータに限られます。

一方で、プロンプトインジェクションに対する耐性は高まります。複数のツールを作成する場合でも、誰がエージェントを呼び出しているかを把握する必要があります。つまり、特定のユーザーが見られるデータのみを取得できるように制限できるのです。

私たちが行っているのは、以下のような仕組みです。AI エージェントはまず企業の ID プロバイダにアクセスしてログインします。この場合、人間の関与が介在することもあります。企業の ID プロバイダからログインしたユーザー情報が返されます。

その後、AI エージェントが MCP サーバーを呼び出す際、OAuth を用いて認証を行います。取得した OAuth トークンには、ログインしたユーザーの情報が含まれています。この情報をツールに伝播させることで、必要なデータをフィルタリングすることが可能です。例えば、「このログインユーザーの部下」である従業員のみを取得するといった制御ができます。

このように、ID の伝播を活用して情報をツールへ渡す仕組みは、私たちのデータプラットフォーム側で自動的に実現されています。MCP サーバーを呼び出す際、常に企業の ID プロバイダから取得したログインユーザー情報が付与されます。

コスト

最後にコストについてお話ししましょう。オーストリアの作家によるブラジルの有名な言葉に「ブラジルは未来の国である」というものがあります。ブラジル人たちはこれに少しユーモアを交えて、「いつまでもそうあり続けるだろう」と付け加えるのが通例です。

しかし、実はある一つの側面において、ブラジルはすでに未来を生きているのです。それがトークン経済の現実です。Claude Code の利用料が 100 ドルだと聞くと、私たちにとっては 500 ドルに感じられます。これはブラジルの最低賃金の約 3 分の 1 に相当します。

トークンのコストは、あなた方が感じるよりも遥か以前から私たちの生活に響き始めています。ここ数ヶ月でトークンコストに関する議論が盛り上がりを見せましたが、私たちは何年も前からこの現実と向き合ってきました。これは良いことでもあります。制約こそが創造性を高めるからです。

私たちもトークンコストとの戦いに直面しています。データ構造はトークンコストに大きな影響を与えます。より精密なツールを使用し、不要なデータを返さないようにするだけでなく、特にロジックをプロンプト側ではなくツール側に移すことで、トークンの使用量を大幅に削減できるのです。

エージェント向けに複数のMCPサーバーを作成することを決定しました。しかし、ここで課題が発生します。あるMCPサーバーは一度しか呼ばれず、別のサーバーは頻繁に利用され、さらにいくつかのサーバーは一切使用されない可能性があります。エージェントを構築する段階では、ユーザーがどのようにこのエージェントを利用するか、どのような呼び出しが行われるかを事前に予測することは不可能です。

そこで私たちは、独自に設計した「MCP Fabric」というパターンを実装しました。これは、複数のMCPサーバーを個別にデプロイするのではなく、単一のサービス内で複数の仮想MCPサーバーを提供するという考え方です。具体的にはSpring AIを活用し、各MCPサーバーを単一サービス内のURLとして定義しています。これにより、各サーバーごとに独立したサービスの運用コストをかけずに、数百ものMCPサーバーを構築することが可能になります。

これで、アジェンシー型データプラットフォームの最終的なアーキテクチャが完成しました。このシステムは、高遅延・中遅延・低遅延という複数のレイヤーを備え、すべての処理を統一的なインターフェースで管理しています。そのため、背後で何が行われているかを気にする必要はありません。

データプラットフォーム内では、「データプロダクト」「セマンティクス（意味情報）」「ツール作成機能」「MCP 作成機能」といった概念が定義されています。これらはすべて MCP Fabric を活用して構築されており、多数の MCP サーバーや OAuth、セキュリティを担うアイデンティティ伝播をサポートします。新しいツールや MCP サーバーの作成は、容易かつ高速で、コストも非常に低く抑えられます。

また、LLM が必要とする形式でツールが応答することで、トークン消費量を削減することも可能です。しかし、コンテキスト内にツールが多すぎると、トークンコストが高騰するという重大な問題が発生します。これを解決するために、「階層型トークンエコノミー」を導入しました。まず、各エージェントに対して 1 つの MCP サーバーを作成することを決定しています。

MCP サーバーは作成が非常に安価で簡単かつ高速であるため、各エージェントごとに専用のサーバーを構築できます。こうすることで、各 MCP サーバーにはそのエージェントが必要とするツールのみが含まれるようになります。これにより動的なツールの検索が可能になります。

具体的な仕組みとしては、各エージェントに対して MCP サーバーを作成します。MCP ゲートウェイを利用している場合も同様のアプローチとなります。MCP ゲートウェイを使用する際は、仮想 MCP サーバー内で利用可能なツールを選択することになります。つまり、特定のエージェントには必要な数少ないツールだけを備えた MCP サーバーを割り当てるのです。

我々の実装でも同じ考え方を採用していますが、MCP ゲートウェイは使用していません。代わりにデータプラットフォーム自体が MCP ゲートウェイの役割を果たします。各エージェントごとに MCP サーバーを作成し、利用可能なツールのサブセットを提供しています。

このように、特定のエージェントや MCP サーバーが多数のツールを持つ場合、コンテキストがすぐに溢れてしまう問題が発生する可能性があります。これを解決するために「動的ツール検索」の仕組みも用意されています。

基本的なアイデアは以下の通りです。エージェントはまず MCP サーバーにアクセスし、利用可能なツールのリストを要求します。MCP サーバーは、利用可能なすべてのツールとその説明などを返します。しかし、これらをそのままコンテキストに追加するのではなく、エージェントはこれらのツール情報を検索サービスへ送ります。

検索ツールサービス側では、各ツールの説明データを保持しています。そして、エージェントが特定の課題を解決するために必要な情報を探している際、この検索ツールサービス内の search_tool を呼び出します。すると、検索ツールサービスはその問題に最適な候補となるツールを返却します。この検索プロセスは、問題の種類に応じて、セマンティック検索や Lucene、あるいは正規表現などを用いて実行されます。

コンテキストに 5 つのツールを格納すれば、エージェントはそれらを呼び出せます。動的ツール検索を用いたベンチマークでは、10 個、25 個、50 個、そして 100 個のツールを使用した場合のトークン使用量が確認できます。オレンジ色の棒グラフが動的ツール検索を採用した結果、青い棒グラフは全ツールをコンテキストに含めた場合です。このようにアプローチを変えることで、大幅なトークンの節約が可能です。

トークンをさらに削減する別の方法として、ツールのレスポンス形式を見直すことが挙げられます。通常、精度を重視するなら JSON が最適で、扱いやすくエクスポートも容易、ネストされた構造の表現にも優れています。しかし、その分冗長になりがちで、多くのトークンを消費します。もし扱うデータがフラットな構造のみであれば、CSV 形式で返すことで、ツールレスポンスにおけるトークン使用量を最大 50% 削減できます。

現在テスト中の新しい規格として「TOON」があります。この形式は、混合された表形式データと複雑なデータを表現でき、結果において 30% から 60% のトークンを節約可能です。ただし、TOON は非常に新しい規格であるため、LLM が長年 CSV や JSON ファイルで訓練されているのに対し TOON では訓練されていないという事情から、精度が必ずしも安定しない場合があります。精度を向上させるための手法は存在しており、現在その検証を進めています。

概要

本稿で紹介する技術は、精度向上やセキュリティ課題の解決、トークンコストの削減など、多岐にわたる目的で活用できます。これらすべてが、AI エージェントにより良質なデータを供給するために役立ちます。

コードをソフトウェアの「決定論的部分」へ押し込むことで、システムはより高精度になり、セキュリティも強化され、コスト効率も向上します。一方、「非決定論的部分」こそが魔法のような体験を生む領域です。ここではエージェントが自然言語を理解し、不完全な情報に基づいて推論を行い、曖昧さを乗り越えてナビゲーションを行います。

ソフトウェアの成功は、この二つの計算モデルの境界線をどこに引くかを理解し、エージェントに必要なデータを適切に提供できるかにかかっています。魔法のような体験を実現するためには、この線引きが極めて重要です。

質疑応答

参加者1: より確立されたシリアライゼーションメカニズムを利用する可能性はないでしょうか？例えば、セマンティック・スキーマ（意味論的スキーマ）が存在する限り、Protocol Buffer 型のプロトコルを使用してデータを圧縮しつつ、JSON が持つ優れた特性をすべて維持することはできないのでしょうか？

ファビアーネ・ナルドン氏： はい、ケースによります。私は Protobuf やそれに類する形式を直接テストしたことはありませんが、重要なのは LLM（大規模言語モデル）がそれをどのように解釈し、適切な回答を返せるかです。例えば、TOON と JSON を比較すると、LLM は通常、曖昧さが少ない JSON の方が理解しやすい傾向があります。使用するプロトコルや、その標準をどの程度正確に理解できるかによって、得られる精度は変わります。現在私たちは、精度とコスト効率のバランスを取るための最適な地点を探る実験を進めています。

参加者 2 氏： RDF やオントロジーにおける一意なエンティティ識別についてお話しされましたが、セマンティック・オントロジーを表現する際の重複データ（デデュプリケーション）の問題にはどのように取り組まれましたか？

ファビアーネ・ナルドン氏： オントロジー内のデータの重複除去のことですね。

参加者 2 氏： グラフ構造においてもです。

ファビアーネ・ナルドン氏： グラフにおいてですか。もちろん、RDF やオントロジーを表現するのは容易ではありません。これも一種の芸術と言えるでしょう。実装方法によっては、同じ概念に対して異なる識別子が付与されてしまうこともあります。私たちはデータをドメインやデータプロダクト単位で整理しているため、重複を完全に排除することはできませんが、大幅に削減は可能です。各ドメインを担当するチームがオントロジーの一部を作成し、それをより大きなオントロジーに接続していく仕組みだからです。完璧ではありませんが、ドメインとデータプロダクトによる組織化によって、この問題をある程度解決できるのです。

参加者 3: 資料の一枚で、MCP の検索機能を実装した際の詳細についてお話しされていました。特に印象的だったのは、主要なオーケストレーターチャットにおいて、最初に 100 個のツールを検索してもコンテキストが全く汚染されなかった点です。その後、二次的な呼び出しによって対象が絞り込まれ、最終的に約 5 つのツールだけがメインエージェントに渡されたようです。このように、初期段階で 100 個のツールを検索しながらもコンテキストを汚染させない仕組みについて、もう少し詳しくお話しいただけますか？

ファビアーネ・ナルドン: おそらく少し簡略化しすぎたかもしれません。もちろん、検索ツール自体はコンテキストに含まれています。私たちが行ったのは、Spring AI を活用してエージェントに渡すツールを「検索ツール」の 1 つだけに絞ることです。Spring AI を使えば、コンテキスト内に 2 つの参照を注入できます。呼び出しを行い、5 つのツールが返ってきたら、その 5 つだけをコンテキストに追加するのです。

参加者 3: 100 個から 5 個へ絞り込むプロセスについてですね。

ファビアーネ・ナルドン: MCP サーバーを呼び出し、「利用可能なツールのリスト」を取得しようとする際、MCP サーバーは利用可能なツールの一覧を返します。これはすべてのツールとその説明を表したものであり、通常、MCP クライアントが MCP サーバーと初めて通信する際に取得する情報です。

参加者 3：私の理解が間違っていたようです。要するに、検索ツール自体が独立したエージェントとして機能し、そのコンテキスト内に留まりながら、5 つのツールを返すのが次のステップだということですね。

Fabiane Nardon：はい、その通りです。2 つのサービスがあります。検索ツール側にはすべてのツールが含まれていますが、エージェント側のコンテキスト内では、動的なツール検索で取得したツールのみが表示されます。

参加者 4：データプラットフォームの上に簡単にツールを作成できる仕組みが素晴らしいと思います。通常、誰がツールを作成しているのでしょうか？データプロダクトチームでしょうか、それとも実際にそれを利用するエージェントチームでしょうか？

Fabiane Nardon：両方のケースがありますね。一般的には、データをより深く理解しているデータチームがツールを作成します。一方、エージェントを開発しているチームも、自社のデータ構造を理解していればツールを活用できます。特に私たちのビジネスでは、その知識が不可欠です。

ただし、状況は異なります。私たちは社内のシステム向けにエンタープライズエージェントを構築しています。例えば GitHub 向けのツールを作成し、誰でもアクセスできるようにする場合とは事情が違います。私たちの場合、エージェントを作成する人々は通常、データへのアクセス権限を持っています。

あるドメインのチームがデータを取得するためのツールを作成し、別のチームがそのツールを活用して他ドメインから必要なデータの一部を取得し、エージェントを構築するというケースもよくあります。つまり、一方のチームがツールの作成を担当し、もう一方のチームがエージェントの開発を行うという分担が行われることもあります。結局のところ、これはチーム間の連携による混合モデルと言えるでしょう。

参加者 4: データプロダクトチームもエージェントチームも、どちらもツールを作成する能力を持っています。また、両者に計測機能（インストルメンテーション）はあるのでしょうか？

ファビアーネ・ナルドン: はい、データへのアクセス権があれば、エージェントチームもツールを作成できます。同じチームが担当する場合もあれば、異なるチームが担当する場合もあります。さらに、他ドメインですでに用意されているツールの利用も可能です。

必要に応じて、他ドメインの既存ツールをそのまま利用することもできますし、そのドメインのデータチームに「特定のツールを作ってほしい」と依頼して作成させることもできます。自社のプロダクト向けにエージェントを作成し、複数の異なるドメインからツールを組み合わせて活用することが可能です。状況によりますね。

一般的には、ビジネスとデータスキーマを最もよく理解しているデータチームが、データ関連のツールを作成するのが通例です。これが主流の進め方となっています。

transcript付きの他の登壇資料はこちら もご覧ください。