← ブログに戻る

Knowledge Graphを7ステップで作る前に、AIエージェントが「見えていない」3層を可視化する

/ 9分で読めます / knowledge-graph · ai-agents · neo4j · graphrag · context

「Knowledge Graphの構築って7ステップで整理されていて分かりやすいよね」と言われるたびに、私は少し身構えます。整理されていることと、いきなり手を動かして良いことは別の話です。

私が過去3回ほどKG構築プロジェクトで見てきた失敗は、ほぼ全部Step 1の前で起きていました。「何を作るか」ではなく「何が今エージェントに見えていないのか」を可視化しないまま設計に入ると、ノードラベルが増えていくのにエージェントの回答は改善しません。ある案件では、5万ノード積み上げた末に「これ、そもそもLLMが読めば済んだのでは?」と全員が薄々気づいて凍結する、みたいなこともありました。オントロジー設計に週末を2回溶かした話は本のほうにも書きましたが、あれは私の一件目です。

この記事は、Knowledge Graph実践ガイドの第4章に入る前段として書いています。7ステップに飛び込む前に、そもそもLLMエージェントが今どこを見ていないのか、3層で分解して自分の頭に絵を描くための下地です。

そもそも「エージェントが見えていない」とはどういうことか

LLMベースのエージェントを触っている方なら、こういう挙動には心当たりがあると思います。

  • 昨日のセッションで決めたはずの命名規則を、今朝忘れている
  • 「このAPIを変更したら影響あるのはどれ?」と聞くと、リポジトリ内の1ファイルしか読まずに答える
  • チームBが管理している設定ファイルの存在は、そもそも認識できない

これは全部「見えていない」の症状です。ただ、それぞれ原因が違います。1つ目は時間の壁、2つ目は関係の壁、3つ目は境界の壁。この3層を最初に分けておかないと、あとから「Vector DBを足す」「RAGを追加する」「MCPを繋ぐ」と場当たりの処方箋が積み重なっていきます。

Anthropicのドキュメントを最近読み直すと、context window の中で「連続した会話履歴」と「明示的に渡した外部情報」を区別する記述が細かくなっているのに気づきます。エージェント側が「自分に何が見えていないか」を宣言的に扱おうとしている流れです。設計者側もこの粒度で見えていない領域を語れないと、話が噛み合いません。

AIエージェントが見えていない3層

第1層: 時間軸 — 「昨日の私」を忘れる層

一番浅くて、一番よく議論される層です。

LLMは基本的に、渡されたcontext windowの外側を見ることができません。Anthropic MessagesもOpenAI Responsesも、明示的にconversation IDでスレッドを引き継いだり、system promptに履歴を混ぜたりしないと、昨日の判断は消えます。「セッション」という言葉で誤魔化されがちですが、モデル本体は一貫した記憶を持っていないのが実態です。

ここが見えていないと何が困るか。私の実例だと「先週私が決めた命名規則」がプロジェクトを跨いで再議論される、みたいなことが起きます。エンジニアが5人いれば5回同じ議論をします。エージェントが5人いれば無限に議論します。

この層に対する処方箋は、大きく分けて3種類あります。

  • Session persistence: conversation IDやthread IDで直近の履歴を持ち回す。数日〜数週間のスパン
  • Vector memory: 過去発話をembedして意味検索。ふわっとした「前にも話した」を拾える
  • Structured memory: 決定事項をエンティティと関係として保存。「誰がいつ何を決めたか」を型で残せる

3番目こそがKnowledge Graphの守備範囲です。「session persistenceで足りるじゃん」と言う人は、まだ関係の層で殴られていない人です。

第2層: 関係 — 「AとBは繋がっている」を推せない層

エージェントに getUserById() の実装を見せると、その関数の中身は完璧に説明します。じゃあこの関数を変更したら誰が困るのか。呼び出し元のサービスは? 依存しているマイクロサービスは? APIクライアントを配布した外部パートナーは?

この問いに答えるには、コードだけでは足りません。エンティティ同士がどう繋がっているかという、明示的にどこにも書かれていない情報が要ります。

私が本の中で書いた第4章の例だと、こういう構造でした。

Service -[:EXPOSES]-> API
API -[:CALLS]-> API
Developer -[:MAINTAINS]-> Service
Service -[:HOSTED_IN]-> Repository

このグラフがあると、getUserById を変更したときに「呼び出し元API → そのAPIをEXPOSEしているService → そのServiceをMAINTAINしているDeveloper」まで一気に辿れます。RAGでコード片を検索するだけでは、この推論はできません。ベクトル検索は「似ているコード」を返すのが得意で、「繋がっているエンティティ」を返すのは苦手です。

Neo4jのブログでも2026年に入ってから、LangChain4jのProperty Graph統合がAgent Memory用途にフォーカスされてきた話が出ています。実際、ハイブリッド構成 (Vector + Property Graph) が2026年時点のプロダクションgradeエージェント記憶の主流に固まってきました。

面白いのは、この関係の層を見せると「え、Property Graphで持たなくてもRDFで十分なのでは?」という質問が必ず出ることです。RDFの方が国際標準感があって安心する気持ちは分かります。ただ実運用で聞くのは9割Property Graphです。Neo4jのLangChain統合の仕上がりも、Property Graph前提でLLMからCypherを生成する方向に振り切っています。標準化と実装のどちらを取るか、みたいな話なので、迷ったらProperty Graphから入ったほうが後戻りは少ないです。

第3層: 境界 — 「読めるけど推せない」層

ここが一番見落とされます。

エージェントに全社データベースへの読み取り権限を与えれば、技術的には「見える」状態になります。でも、それは「reasoningできる」とイコールではありません。

具体的にはこういうケースです。

  • チームAの設定ファイルは読めるが、それがなぜその値なのかはチームAだけが知っている
  • 全リポジトリのコミット履歴は読めるが、あるコミットがなぜマージされたのかはSlackの2023年8月の会話に埋まっている
  • 全社Wiki は読めるが、更新が3年止まっている記事と昨日更新された記事の重みは同じに見える

生のドキュメントを渡しても、エージェントには「どれが誰の権威の下にあるか」「どれが今も有効か」が判別できません。これは技術的に「見える」ことと、意思決定の材料として「使える」ことのギャップです。

Knowledge Graphのオントロジー設計は、ここで威力を発揮します。エンティティに owner, authority, expires_at, superseded_by みたいなプロパティを乗せておくと、エージェントは「この情報は先週まではチームBの承認済み仕様だったが、木曜のPRで supersede されている」といった判断ができます。ドキュメント単位ではなく、主張単位 で権威と有効期限を持たせる、という発想の切り替えです。

3層マッピング演習: 手を動かす前の30分

ここまでの3層を、自分のプロダクトで具体的にマップしてみるだけで、Step 1の質が変わります。30分で終わる演習にしました。

演習1 (10分): 時間の壁を書き出す

過去1ヶ月、エージェント (自作でも、Claude Codeでも、GitHub Copilot workspacesでも) に「同じ質問を2回以上した」ケースを3つ挙げます。3つ書けたら、そのうち何が「Vector memoryで解決可能」で、何が「構造化された決定履歴が必要」かを分けます。後者がKGの入口です。

演習2 (10分): 関係の壁を書き出す

自分のプロダクトのメインリポジトリで、「このファイルを変更したら誰に影響が出るか、30秒で答えられない」ファイルを3つ挙げます。そのファイルとエンティティ (Service, API, Team, Customer など) の関係を、雑でいいのでノード-エッジで描きます。この時点でオントロジーの下書きが半分できています。

演習3 (10分): 境界の壁を書き出す

自分のプロダクトの「誰も更新していないが、消すと壊れる設定ファイル」を3つ挙げます。それぞれについて owner, last_verified_at, expires_at を推測で埋めてみます。埋められない項目が、そのままKGに乗せたいプロパティです。

演習を終えたときに手元にあるのは、3層に分解された「うちのエージェントが今見えていないもの」のリストです。ここまで来て初めて、本の第4章に載せた7ステップのStep 1「ユースケースを定義する」に入る資格が発生します。

7ステップに入る前の3層マッピング演習

3層と7ステップの対応

第4章では設計・構築・運用の7ステップを書きましたが、実は最初の3ステップは3層と綺麗に対応しています。

前段 (この記事)7ステップ側
第1層: 時間軸を書き出すStep 1: ユースケースを定義する
第2層: 関係を描くStep 3: オントロジー/スキーマを設計する
第3層: 境界を埋めるStep 4-5: データモデリングと取り込み

前段の3層マッピングを飛ばして7ステップに入ると、Step 3で必ず戻ってきます。私が週末を2回溶かしたのはStep 3で戻ってきたときの手戻りコストでした。

逆に、3層をきちんと書き出したあとの7ステップは驚くほど淡々と進みます。Step 1のユースケース定義は「時間軸の壁で書き出した3つの困りごと」からそのままクエリが出てきます。Step 3のオントロジーは「関係の壁で描いたノード-エッジ図」の清書に近い作業になります。Step 4以降はもう手癖です。

まとめ

Knowledge Graph構築の7ステップは、それ自体は良く整理されたフローです。ただ、良く整理されているからこそ、その前に自分のエージェントがそもそも何を見ていないかを分解する30分を挟まないと、綺麗な設計図と役に立たないグラフが同時に生まれます。

  • 第1層 (時間軸): セッション外の記憶と決定履歴
  • 第2層 (関係): エンティティ間のリンクと影響範囲
  • 第3層 (境界): 権威・所有・有効期限といったメタ情報

この3層の穴を書き出してから、7ステップの構築に入る。それが、私が3回目のKG構築でようやく学んだ順番です。1回目と2回目は、書けばだいたい想像がつくとおりの流れで、Step 3で泣いて戻ってきました。