9月12日、Cassie Shumが「From Retrieval to Reasoning: Building Production-Ready Agentic AI Systems with Knowledge Graphs」と題した講演をInfoQで公開した。この講演では、ナレッジグラフをRAGの代替ではなくアジェンティックAIシステムの基盤として活用するための4つのアーキテクチャパターンと、本番環境で機能するシステム設計の実践知について詳しく紹介されている。

「RAGの時代は終わった」という問いへの回答

LLMの性能向上に伴い、「グラフから検索する必要があるのか？」「もはやGraphRAGは死んだのでは？」という問いが業界で出始めている。Cassie Shumはこれに対し、「検索（Retrieval）の用途においてはその通りかもしれない」と認めたうえで、主張の軸を転換する。

ナレッジグラフは検索の最適化ツールではなく、システム全体の基盤（substrate）であるべきだ、というのがこのセッションの核心だ。

単一のプロンプトウィンドウにすべてのコンテキストを詰め込んでLLMに投げれば、確かに良い結果が返ってくる。だがShumが問うのは「それは組織・チーム間で再現可能か、一貫性があるか、監査できるか」という点だ。個人が手元で動かすデモと、組織が本番で運用するシステムとの間には大きな溝がある。

用語メモ：GraphRAGとは、Microsoftが提案したアプローチで、ナレッジグラフを活用してRAG（Retrieval-Augmented Generation）の精度と推論能力を高める手法。通常のRAGがベクトル検索で「近い文書」を取得するのに対し、GraphRAGはエンティティ間の関係性をグラフ構造で保持し、より複雑な多段階クエリに対応できる点が特徴とされる。

ナレッジグラフが「基盤」である理由

Shumが示すナレッジグラフの定義は単純なグラフデータベース（Neo4j等）とは異なる。エンティティ間の関係性に加え、ビジネスルールや意思決定のロジックを埋め込んだリッチなセマンティック層を持つものを指す。

用語メモ：ナレッジグラフとは、現実世界のエンティティ（人・組織・概念など）とその関係性をノードとエッジで表現したグラフ構造のデータモデル。ベクトルDBが「意味的な近さ」を数値ベクトルで表現して類似検索に特化するのに対し、ナレッジグラフは「A社はB規制の対象である」「C製品はDカテゴリに属する」といった明示的な関係性と推論ルールを保持できる点が異なる。セマンティック層とは、この関係性の意味的な定義や業務ルールを構造として持つ層を指す。

金融機関の顧客事例として挙げられるのが具体的でわかりやすい。ChatGPTやClaude Codeに「どのコンプライアンス規制に従うべきか」「Tier 1とはここでは何を指すか」「先四半期に何が決定されたか」と問いかけても、汎用的な回答しか返ってこない。一方、組織固有のナレッジグラフを参照するエージェントであれば、その組織・ドメイン特有の答えを高い精度で返せる。

さらにShumが強調するのが「意思決定の系譜（lineage）」の追跡だ。5年前のWikiページに書かれたルールが、いつの間にか複数箇所にデッドコードとして再実装されている——そういった組織の「部族知識（tribal knowledge）」の問題を、ナレッジグラフへのフィードバックループで解消できると主張する。具体的には以下の用途を挙げている：

• 信頼できる共有コンテキスト：チーム間でコンテキストを統一するソースになる
• 監査可能性：意思決定のタイミングとその変遷を追跡できる
• クロスドメイン結合：マイクロサービス時代に分断されたドメイン間の依存関係を可視化する
• 組織知識の保全：ベテランの頭の中やConfluenceの陳腐化したページに散在する知識を構造化する

4つのアーキテクチャパターン

Shumは自社（RelationalAI）の内部開発ツールをナレッジグラフ上に構築した実体験から、4つのパターンを導き出している。セッション後半ではそれぞれのパターンに対応するデモも行われている。以下は講演トランスクリプトに基づいた各パターンの概要だ。

パターン1：コンテキスト共有（Shared Context）

組織内の複数エージェントやチームが、同一のナレッジグラフをコンテキストソースとして参照する構成。各エージェントが独自にコンテキストを保持するのではなく、グラフを「単一の真実源（single source of truth）」として扱うことで、チーム間の解釈の不一致や重複した定義の乱立を防ぐ。組織横断的なアジェンティックシステムにおいて、一貫した挙動を担保するための土台となるパターンだ。

パターン2：意思決定追跡（Decision Lineage）

エージェントが下した判断とその根拠をグラフに書き戻し、後から監査・再利用できるようにする構成。「なぜそう判断したか」の根拠をグラフに記録することで、規制対応・コンプライアンス要件への説明責任を果たせるようになる。また、過去の判断をグラフ上でたどることで、同種の意思決定を再利用したり、誤った判断が下された経緯を遡って調査したりすることも可能になる。

パターン3：クロスドメイン統合（Cross-Domain Integration）

複数のマイクロサービスドメインにまたがる依存関係をグラフで表現し、エージェントが横断的に参照できるようにする構成。マイクロサービスアーキテクチャではドメイン間の依存関係がコードや仕様書に散在しがちだが、それをグラフとして明示することで、影響範囲の把握や変更管理が格段に容易になる。エージェントはこのグラフを参照することで、ドメイン境界をまたいだ推論や提案が可能になる。

パターン4：フィードバックループ（Knowledge Feedback Loop）

エージェントの学習結果や新たに発見された関係性をグラフに反映し、継続的に知識を更新していく構成。エージェントを使い続けることでグラフが育ち、システム全体の推論精度が向上していく。一方向のデータ取り込みではなく、エージェントとグラフが相互に強化し合うループを設計することが、長期的な本番運用においては重要だとShumは主張する。

「モデルは堀（moat）にならない」

Shumのもう一つの主張が「競争優位の源泉はモデルではなくドメインナレッジだ」という点だ。モデルは日々改善され、ファインチューニングも容易になっている。それよりも、自社ドメインの知識をいかに構造化してグラフに落とし込めるかが差別化になるという見方だ。

この視点はRAGアーキテクチャへの関心が高まるなかで、エンジニアリングチームがベクトルDBやチャンクサイズの最適化に集中しがちな現状へのカウンターアーギュメントとして機能する。

Shumは「これはナレッジグラフを使うべきという教義ではなく、自分の経験から得た教訓だ」と断ったうえで、変化が速い現在のAI開発において基盤を固めておくことの重要性を一貫して訴えている。

詳細はFrom Retrieval to Reasoning: Building Production-Ready Agentic AI Systems with Knowledge Graphsを参照していただきたい。