AIエージェントが毎回データを取りに行く設計の限界
AIエージェントが毎回データを取りに行く設計の限界
この記事は独立して読めます（約8分）
以前の記事「MCPの課題とナレッジグラフ」では、MCP/RAGアーキテクチャが抱えるscatter-gather問題（毎回バラバラのシステムに問い合わせて寄せ集める方式）を論じました。また「特許から読むDevRevの思想」では、その背景にある設計思想を特許から読み解きました。本記事ではその設計回答、すなわち「ではどう設計するか」を具体的に示します。
問題：PoCは動くが、本番では使われない
「AIエージェントのPoCは動いたのに、本番に出すと遅い・不正確・使われない」
日本のエンジニアと話すと、この話が繰り返し出てきます。技術的には確かに動いている。しかしユーザーからは「遅い」「答えが微妙にずれている」「信用できない」という反応が返ってくる。
原因の多くは、複数システムにまたがる質問に答えられない設計にあります。たとえば、kintoneに顧客情報、SmartHRに組織情報、SalesforceにCRMデータが分散している状況で、「この顧客の担当者は誰で、直近の案件状況は？」という問いに答えようとすると、エージェントは3つのシステムを個別に叩く必要があります。
これがscatter-gather問題です。詳細なメカニズムは前掲記事に譲り、ここでは構造上生じる3つのコストだけ確認します。
- レイテンシ: 最も遅いAPIが全体の応答速度を律速する
- トークン消費: コンテキストを毎回ゼロから再構築するため、無駄な入力が積み上がる
- 精度劣化: システムをまたいだ「関係性」が見えないため、断片的な回答しか生成できない
エージェントは毎回3往復の通信を行い、返ってきた断片情報を自力でつなぎ合わせます。「A社の担当者は誰で、その人は現在どの案件を持っているか」という関係性はLLMがその場で推論するしかなく、精度は安定しません。
ナレッジグラフはどう貢献するか
設計の分岐点
AIエージェントのアーキテクチャには、根本的な設計の分岐があります。
推論時データ収集型: LLMが推論の過程でツールを呼び出し、必要なデータをその都度取得する設計です。LangChainのAgentExecutor、OpenAI Function Calling、MCPの多くの実装がこのパターンです。
事前統合型（Memory-first）: 推論が始まる前に、関連データが統合済みの状態にしておく設計です。LLMはデータ収集ではなく、すでに整理された知識の上での推論に集中します。
2つのパターンを並べると、違いが明確になります。
推論時データ収集型
事前統合型（Memory-first）
どちらが「正解」かという話ではありません。シンプルなユースケース、システム数が少ない構成では推論時データ収集型で十分です。しかしデータソースが増え、複数システムをまたいだ推論が必要になるとき、設計コストの差が顕在化します。
なぜRDBやキャッシュではなくナレッジグラフか
「事前にデータを統合するならRDBやRedisでよいのでは？」という疑問は自然です。
RDBやRedisは「個々のレコード」を高速に返すことに長けています。一方で、「レコード間の関係性」を表現・走査する構造を本来は持っていません。テーブル結合で関係性を扱えますが、3段、4段と深くなるにつれてクエリが複雑になり、スキーマ変更のたびにJOINの書き直しが発生します。
scatter-gather問題の本質は「各システムのデータを集めること」ではなく、「データ間の関係を推論に使うこと」です。「この顧客は先週も同じ問題を報告している」「この障害は先月のデプロイに起因する」といった推論は、ノードとエッジで関係性を構造化したナレッジグラフであれば、クエリ1本で取得できます。深い関係性の走査がナレッジグラフの設計的な強みです。
ナレッジグラフが貢献できる範囲
- 複数システムのエンティティ統合: CRMの「A社」とサポートシステムの「A社」を同一ノードとして扱える。エージェントは「どのシステムのA社か」を意識せずにクエリできる
- 関係性の永続化: エンティティ間の関係がエッジとして保存されているため、毎回クエリで再構築しない。推論のたびにコンテキストを組み直すコストがゼロになる
- アクセス権限のグラフ表現: 「誰が何に触れるか」をグラフ構造で表現できる。権限制御への応用はAIエージェントを本番に出せない本当の理由で詳しく扱っています
設計上の帰結: 関係性込みのコンテキストが推論開始前に揃っているため、LLMがその場で関係を「推測」する無駄な推論が不要になります。推測のためのトークン消費が減り、応答が速くなり、かつ推測に起因するハルシネーションも減ります。
ナレッジグラフだけでは不十分な領域
ナレッジグラフは「事前にデータが揃っている」という前提で動きます。しかしKG単体では、外部システムのデータをKGに取り込む仕組みを持ちません。
50のシステムからリアルタイムにデータをKGへ流し込むには「同期インフラ」が別途必要です。これはKGの責務ではなく、その外側の問題です。また、全データソースをカバーすることが現実的でないケースもあります。何を統合するかの設計判断が、KGの設計と同じくらい重要です。
ナレッジグラフは「データ統合コストを前払いする」設計です。この前払いが価値を生むかどうかは、統合するデータの規模と、そこから得たい推論の複雑さによります。
参照実装：DevRev Computer の設計
ナレッジグラフをエージェント基盤として実際に本番スケールで稼働させているシステムの一つとして、DevRev Computer v2があります。その設計の一部は公開されたホワイトペーパーと特許から読み取れます。
Computer Memory（KGベースのエージェント基盤）
DevRevはナレッジグラフを「Memory」として位置づけ、エージェントが推論に使う知識の基盤としています。カスタマーサポート・プロダクト開発・セールスにまたがるデータが、単一のMemoryレイヤに統合される設計です。
AirSync（リアルタイム同期インフラ）
KGだけでは解けない「外部システムのデータをどうKGに取り込むか」という問題を補完するのが、CDCベース（Change Data Capture）の双方向リアルタイム同期エンジンであるAirSyncです。Salesforce、Zendesk、Jiraなど50以上のシステムのデータを、パーミッション情報を保持したままKGへ取り込みます。
「Memory（KG）+ AirSync（同期インフラ）」の組み合わせが、scatter-gather問題への設計回答です。エージェントは各システムに問い合わせるのではなく、統合済みのKGに一度クエリするだけで回答を生成できます。
また、「SalesforceのAcme Corp」と「ZendeskのAcme」が同一企業かどうかを自動判定するEntity Resolution（名寄せ）が、同期インフラのレベルで組み込まれています。この設計の詳細はナレッジグラフをエージェントの「記憶」にする設計で扱っています。
DevRevの公開情報でこの設計が強調するのは、「50番目のユースケースを5番目と同じコストで立ち上げられる」という点です。新しいシステムを統合するたびにエージェント側の実装を変える必要がなく、同期インフラにコネクタを追加するだけで済む構造になっています。これはシステム数が増えるほど、scatter-gather型との設計コスト差が広がることを意味します。
今日から始める1ステップ
設計を変えるための最初の一手は、自分の業務に関わる5つのシステム間の関係をMermaid図で1枚書くことです。
このとき、ひとつだけ問いを立ててください。
「顧客」は各システムでどう呼ばれているか？それは同一の人（企業）か？
この問いに答えられないなら、scatter-gather問題はすでにあなたのシステムにあります。ナレッジグラフが解くべき問題の最初の輪郭が、この図から見えてきます。
ナレッジグラフとRAGの根本的な違いについてはこちらの記事でより詳しく解説しています。
RAGを超える知識統合。ナレッジグラフで"つながる推論"を実現する
経営層・技術リーダーの方へ: 自社のAIエージェントが「毎回データを取りに行く設計（scatter-gather）」か「事前にデータが統合された設計（Memory-first）」かを、AIチームに聞いてみてください。前者であれば、この記事の課題がそのまま当てはまります。
ナレッジグラフの設計をどう始めるか（スキーマ設計と名寄せ）は、こちらの記事で扱っています。
ナレッジグラフをエージェントの「記憶」にする設計
「ツールが増えてもエージェントが賢くならない問題」はこちらの記事で扱っています。ナレッジグラフの設計より先にエージェントアーキテクチャの問題に興味がある方は、そちらから読んでも独立して理解できます。
ツールを100個並べてもAIエージェントは賢くならない
このシリーズの記事
| 記事 | テーマ |
|---|---|
| AIエージェントが毎回データを取りに行く設計の限界 | scatter-gather問題の設計回答（本記事） |
| ナレッジグラフをエージェントの「記憶」にする設計 | スキーマ設計と名寄せ |
| ツールを100個並べてもAIエージェントは賢くならない | Skillの先にあるデータ基盤の問題 |
| AIエージェントを本番に出せない本当の理由 | 権限・監査・ロールバック |
更新履歴
- 2026-05-24: 初版公開
フィードバック受け付け
本記事は AI を活用して執筆しています。内容に誤りや追加情報があれば、Zenn のコメントよりお知らせください。
Discussion