8月29日、InfoQが「Architecting the Data Layer for AI Agents: From Transactional Systems to MCP and Semantic Models」と題した記事を公開した。発表者はFabiane Nardon氏。ブラジル最大級のエンタープライズソフトウェア企業TOTVSのCTOであり、同社は40年間にわたってERP・CRMなどの業務システムを構築してきた。ブラジルGDPの約4分の1が同社のシステムを通じて動く——そのスケールのエンタープライズ環境で、AIエージェントにデータ基盤をどう設計するかという問いに向き合ってきた当事者だ。

「データが足りなくて困った」のではない。「データが多すぎて、AIエージェントが使える形になっていなかった」——これがNardon氏の出発点だ。ブラジルGDPの4分の1を処理するシステムが抱えるデータ量でさえ、そのままではエージェントに渡せない。この逆説的な現実が、本発表の核心を貫いている。

トランザクションシステムのデータは「エージェント向けではない」

従来のトランザクションシステム（ERP、CRM等）のデータは、アプリケーションからの決定論的なクエリに最適化されている。データレイクのデータは、データアナリストやダッシュボード向けに最適化されている。どちらも、数分間に何百もの予測不能なクエリを投げてくる推論ループには耐えられない設計だ。

さらに根本的な問題がある。トランザクションシステムは99.99%の精度を前提に設計されているが、AIエージェントは確率的推論を使う。この2つを同じ土俵で比較することはできないし、そのギャップを直視しなければならない。

どこからデータを取るか：トランザクションシステム vs データプラットフォーム

Nardon氏はデータ取得元の使い分けを明確に整理している。

トランザクションシステムに直接アクセスすべき場面：

• データを書き込む必要がある場合
• リアルタイムの最新データが必要な場合
• トランザクションシステム内のビジネスロジックを実行する必要がある場合

データプラットフォームを使うべき場面：

• 多少の遅延データで問題ない場合
• 過去データの分析が必要な場合
• セマンティック検索が必要な場合（レガシーDBでは非対応のことが多い）
• 外部データソースとのエンリッチメントが必要な場合

データプラットフォームへのアクセスにはMCP（Model Context Protocol）などのデータアクセスプロトコルを使う構成を推奨している。MCPはAnthropicが提案した、LLMとデータソース・ツールをつなぐ標準プロトコルだ。

MCPツールをデータメッシュの「データプロダクト」に紐づける

TOTVSが採用したアーキテクチャの核心は、MCPツールをデータメッシュのデータプロダクトと対応させるという設計だ。

データメッシュはドメインごとにデータを分散管理するアーキテクチャで、ガバナンス問題の解決策として近年多くの企業が採用している。その中心概念がデータプロダクト——他者が利用できる形に整えられたデータの単位で、オーナー、安定したインターフェース契約、ドキュメント、品質SLAを持つ。「データのマイクロサービス」と表現するとわかりやすい。

MCPツールをこのデータプロダクトに対応させることで、ツールのオーナー、利用状況、パフォーマンス統計などのガバナンスがデータメッシュの仕組みをそのまま流用できる。ツールが増えすぎたときの「このツール誰が管理してるの？」問題を構造的に解決できる点が実用的だ。

また、get_schemaやgenerate_queryのような汎用ツールではなく、各データプロダクトのビジネス知識を持つオーナーが設計したドメイン特化型のツールを作ることで、精度が上がる。

最大の難問：セマンティックの曖昧さをOntologyで解く

Nardon氏が最も力を入れて語るのが、企業内の意味的曖昧さの問題だ。

「アクティブな顧客とは何か？」——マーケティングと財務では答えが違う。Nardon氏はかつて在籍した企業で、「チャーン」の定義を全社で統一しようと1週間会議を続けたが、合意に至らなかったという経験を持つ。

人間同士なら文脈から意味を推測できる。しかしLLMにはその「空気を読む」能力がない。明示的に意味を与える必要がある。

そこで活用するのがSemantic Web技術だ。2001年にTim Berners-Leeが提唱したRDFやOWLなどの標準規格で、概念に一意なIDを付与し、概念間の関係をオントロジーとして表現する。「マーケティングのアクティブ顧客」と「財務のアクティブ顧客」は同名でも別IDを持つため、曖昧さが除去される。

Nardon氏自身がPhDをSemantic Web技術で取得しているが、当時の最大の課題は「オントロジーの作成コストが高すぎること」だった。現在はLLMを使えばドキュメントからオントロジーを容易に生成できる。これが「なぜ25年かかったか」の答えの一つだ。

ChatGPTでの実証例

Nardon氏はChatGPTを使ったデモで効果を示す。

• Acme社がサーバー10台を購入
• Beta社がライセンス50本を購入
• Gamma社がキーボード20台を購入

「ハードウェアを購入した顧客は？」と聞くと、通常のChatGPTは「AcmeとGamma」と答える（サーバー＝ハードウェアと推論）。

しかしOWLオントロジーで「サーバーはクラウドサービスのサブクラスである（＝ソフトウェアサービス）」と定義し、RDF識別子付きで同じ質問をすると、ChatGPTは正しく「Gammaのみ（キーボード）」と回答した。

発表内で引用された研究によると、オントロジーベースのセマンティック層を追加することでLLMの回答精度が40%向上したと報告されている。

精度・セキュリティ・コストの3変数

Nardon氏はAIと従来ソフトウェアを組み合わせる際の判断軸を「精度（Precision）・セキュリティ（Security）・コスト（Cost）」の3変数で整理している。どの処理を決定論的なコードに任せ、どこをAIに委ねるか——この線引きの判断がアプリケーションの成否を左右し、その判断の質はデータをどう提供するかに大きく依存する。

3変数の関係は相互にトレードオフになりやすい。精度を高めようとセマンティック層を厚くすればコストが上がる。セキュリティを厳格にすればエージェントがアクセスできるコンテキストが狭まり精度に影響する。Nardon氏はこの3変数を設計の「ダイヤル」として捉え、ユースケースごとに意図的に調整することを推奨している。発表ではTOTVSの実装例として、財務系の処理では精度とセキュリティを優先して決定論的コードの比率を高く保ち、AIへの委任範囲を絞る方針が示されている。一方、顧客向けの対話系エージェントではコストと利便性のバランスを重視し、セマンティック層でカバーできる範囲でAIの自律度を高める設計が採られているという。

詳細はArchitecting the Data Layer for AI Agents: From Transactional Systems to MCP and Semantic Modelsを参照していただきたい。