この記事は、ナレッジグラフエージェントを実際にどう作るかの実装ガイドです。概念の説明ではありません。「ナレッジグラフエージェントとは何か」「GraphRAGとRAGの違い」はAIエージェントの機能を実務レベルに上げる方法とGraphRAGとは？ベクトルRAGとの違いにまとめてあるので、そちらを前提に進めます。
説明は、Beekleが実際に構築・運用している2つのシステムの設計判断から起こします。ひとつはカスタマーサポート向けの社内ナレッジ検索、もうひとつは要件トレーサビリティ・プロジェクト管理のシステムです。どちらもNeo4jのナレッジグラフとベクトル検索を組み合わせ、AIエージェントに検索を道具として渡す構成です。実際に動かしているものなので、机上の話ではありません。
全体像：4層で組む
ナレッジグラフエージェントは、大きく4層に分けて考えます。
層 | 役割 | 実装の例 |
|---|---|---|
データ源 | 既存の文書・データベース・議事録など | PDF、Wiki、チャット、業務DB、文字起こし |
グラフ・オントロジー層 | 要素と関係を「型」で持つ持続記憶 | Neo4j（ノードと意味づけした関係） |
検索・接地インターフェース | 問いに応じて複数経路で取り出し、統合・検証する | ベクトルDB＋全文＋グラフ探索、リランク、RRF |
エージェント本体 | 計画し、道具を使い、記録する | LLM＋MCPなどの道具接続、read/writeループ |
下の層ほど、その上の精度を左右します。ここからは各層をSTEPで作っていきます。
STEP1：オントロジーを先に決める（型＝ノードと関係）
まず決めるのは、業務の型です。その業務にどんな種類のものがあって、それらがどう関わるか。これをオントロジーと呼びます。エージェントが答えるべき問いは、この型から決まります。モデルや検索手法を選ぶのはその後です。ここを飛ばして部品から組むと、現場の問いに構成がかみ合いません。
この要件トレーサビリティのシステムでは、SDLC（要件開発の流れ）をそのままグラフの型にしています。要素（ノード）と、意味づけした関係（エッジ）で持ちます。
- ノードの例：要求、要件、シナリオ、受入基準、ストーリー、タスク、テスト結果、不具合、意思決定（ADR）。
- 関係の例：要求は要件に「精緻化される（REFINES）」、要件は「シナリオを持つ（HAS_SCENARIO）」、シナリオは「受入基準を持つ（HAS_AC）」、タスクは「テストで検証される（VERIFIED_BY）」、不具合は要件やシナリオに「影響する（AFFECTS）」。
関係は意味づけして持ちます（typed edge）。ただつながっている、ではなく、何のつながりかまで型にする。こうしておくと「この要件を検証しているテストは?」「この不具合が影響する要件は?」に、グラフをたどるだけで答えが出ます。
ノードのラベルと関係の種類は、あらかじめ決めた一覧（enum）に限っておきます。型を固定しておくと、あとでLLMに検索クエリ（Cypher）を書かせるとき、想定外のラベルや関係が紛れ込みません。Cypherインジェクションも、LLMが捏造したクエリも、この時点で塞げます。ナレッジグラフ設計の型はエンタープライズのナレッジグラフ設計パターンも参考にしてください。
STEP2：データを取り込み、関係と埋め込みに落とす
型が決まったら、データをグラフとベクトルの両方に入れます。背景や言い換えを拾うのはベクトル、関係や正確さを担うのはグラフ。片方だけだと、どちらかの問いで必ず穴が出ます。
- チャンク分割：長い文書は段落・見出しを基準に分割し、前後を少し重ねて文脈の断絶を防ぐ。各チャンクに「どの文書の何章か」「更新日」「機密度」のメタデータを付ける。
- エンティティと関係の抽出：本文から、STEP1で決めたノードと関係を取り出してグラフに書き込む。ここの抽出精度がそのまま回答精度に響く。PDFの表や段組みで崩れやすい点はGraphRAGの精度はデータ抽出で決まるで詳述。
- 埋め込み生成：チャンクをベクトル化してベクトルDBに格納する。埋め込みモデルと次元は用途で選ぶ。私たちの構成では、社内ナレッジ検索は4096次元の多言語モデル、要件システムは1536次元のモデルを使い分けている。
- 再埋め込みの回避：本文のハッシュをキーにキャッシュし、変わっていないチャンクは埋め込みをやり直さない。運用コストが大きく変わる。
ベクトル検索は、案件やプロジェクト単位で必ず絞れるようにしておきます。要件システムでは常にプロジェクトIDでスコープをかけ、案件をまたいだ情報漏れを設計で止めています。
STEP3：検索を多戦略で並列に走らせ、統合する
ベクトル検索ひとつでは、ここから先が伸びません。問いのタイプで得意な経路が変わるので、複数を並列に走らせて1つにまとめます。精度が業務で通るかどうかは、だいたいここで決まります。
要件システムでは、まず軽量なモデルで問いの意図を分類し、次の戦略を並列に走らせます。
戦略 | 取り出すもの | 得意な問い |
|---|---|---|
グラフクエリ（Cypher） | 型に沿った関係を直接たどる | 「AとBの関係は?」など構造がはっきりした問い |
ハイブリッド | ベクトル（意味の近さ）＋全文（キーワード一致） | 言い換え・表記揺れを含む問い |
グラフ拡張 | ヒットしたノードの周辺関係を広げる | 複数文書をまたぐ横断的な問い |
GraphRAG | 関係のかたまり（コミュニティ）の要約 | 全体像・傾向をつかむ問い |
並列で集めた候補は玉石混交なので、2段で整えます。まずクロスエンコーダのリランカーで問いとの関連度を測り直し、上位に絞る。そのうえで、経路ごとの順位をRRF（Reciprocal Rank Fusion）で1本にまとめる。社内ナレッジ検索では、メタデータ・全文・ベクトル・グラフ近傍・主張の5経路をRRF（k=60）で束ねています。
類似度も、ベクトルの距離ひとつでは決めません。要件システムの「似た要件・重複要件の検出」は、3層で採点します。
- 1層目：ベクトルのコサイン類似度（意味の近さ）。
- 2層目：過去に人が「採用した・却下した」フィードバックで加減点する。使うほど自社の判断に寄る。
- 3層目：グラフ構造でブーストする。タグの重なり、関係する担当者の一致、共通の親をたどれるか。
意味の近さだけでなく、過去の判断と関係構造まで見て並べる。単純なベクトル検索が取りこぼす分を、この3層で拾います。回答精度の底上げは生成AIの回答精度を業務レベルに引き上げる方法にもまとめました。
STEP4：エージェントのread/writeループと道具化
ここまでの検索を、エージェントが使う道具として渡します。道具の接続にはMCP（Model Context Protocol）を使っています。要件システムでは、グラフとベクトルへのアクセスを100以上のツールとして公開し、AIが読む・考える・書き戻すを自分で回します。
ただの検索と違うのは、見つけたことを記憶に書き戻すところです。要件システムに分かりやすい例があります。クローズした不具合から、LLMが再発防止案を起こし、新しい要求や要件としてグラフに書き戻す。次に似た要求が来ると、過去の不具合の履歴が関連スコアを押し上げ、同じ失敗を踏みにくくなります。読むだけなら記憶は静的なままですが、書き戻しまで回すと、使うほど賢くなります。
STEP5：事実で自己チェックさせる（ハルシネーション対策）
回答を作る段では、事実との突き合わせを組み込みます。プロンプトで指示するだけでは足りません。
- 回答は参照した事実のみに基づく：参考資料にない場合は「資料上は確認できません」と答えさせ、埋めさせない。
- 根拠を必ず添える：どのノード・どのチャンクを根拠にしたかを回答に含める。利用者が裏取りでき、監査にも耐える。
- 回答後の突き合わせ（Evidence Verification）：生成した回答を、引用元やグラフの事実と再照合し、食い違えば差し戻す。社内ナレッジ検索では、この検証を回答生成の後段に必ず置いている。
- 型による物理的なガード：STEP1でラベルと関係をenumに固定してあるので、LLMが捏造したラベルや不正なクエリはそもそも実行されない。プロンプトが破られても、この層で止まる。
STEP6：運用（鮮度・品質・アクセス制御・型の進化）
作って終わりにはなりません。実務に耐えるかは、運用の作り込みで決まります。
- 鮮度：データ源が更新されたらグラフとベクトルも更新する。定期ジョブで同期し、放置された古い情報（stale）を検出する。要件システムでは、滞留の検出やスナップショットを日次バッチで回している。
- 品質：孤立したノード、重複したエンティティを定期的に検出して直す。抽出漏れを放置すると精度が静かに落ちる。
- アクセス制御：誰がどのノードを見られるかを、グラフ上のアクセス権（ACLエッジ）とロール・スコープで制御する。私たちの要件システムは、すべての検索クエリにテナント境界を必ず差し込む二重防御にしている。情シス観点の確認は社内文書を生成AI・RAGで扱う情報漏洩リスクと対策を参照。
- 型の進化：業務が変われば型も足す。ノードや関係の追加は、スキーマ移行として管理し、既存データと整合させる。
スタック選定とVPS・マネージドの判断
グラフDBはNeo4jのほか、PostgreSQLにpgvectorやApache AGEを載せる、Kùzuを使う、といった選択肢があります。ベクトルDBもMilvusやpgvectorなど幅があります。正解は一つではありません。扱うデータ量と運用体制で選びます。
中小規模なら、基盤はVPSで十分動きます。上の2システムも、自社サーバー（VPS）で運用しています。マネージド（Neo4j AuraDBなど）は規模を問わず運用の手間を減らせますが、従量課金なので自前VPSより割高になりがちです。判断軸は「超大規模かどうか」ではなく、手間とコストのどちらを取るか。可用性を強く求める、急なスケールに備える、なら手間を金で買う。コストを抑えて自分で回せるなら、VPSで足ります。基盤の考え方は生成AIシステムのインフラはVPSで十分かにまとめました。
要件をぶらさないために、受入基準やシナリオ（Given/When/Thenのふるまい）を先に仕様として固め、そこから実装と検証をつなぐ進め方も採っています。何を作れば正解かが決まっていれば、エージェントの出力も評価しやすくなります。
どこから始めるか・落とし穴
いきなり全社をグラフ化しない。これが鉄則です。誤答すると困る業務を1つ選び、その範囲だけオントロジーを作る。効果を見てから広げます。つまずくのは、だいたい3か所です。抽出を軽く見る（STEP2）、ベクトル検索ひとつで止める（STEP3）、検証と運用を後回しにする（STEP5・6）。どれも、デモは動くのに本番で精度が崩れます。PoCから本番への進め方はPoCから本番運用へ進めるための判断基準を参考にしてください。
Beekleの取り組み
この記事の内容は、Beekleが実際に構築・運用している2つのシステムの設計そのものです。ひとつはカスタマーサポート向けの社内ナレッジ検索で、メタデータ・全文・ベクトル・グラフ近傍・主張の5経路をRRFで統合し、回答後に引用元と突き合わせて検証する構成。もうひとつは要件トレーサビリティ・プロジェクト管理システムで、要件のSDLCを型付きグラフで持ち、多戦略の検索と、不具合から要件への書き戻し学習ループ、テナント境界を二重に守るアクセス制御まで作り込んでいます。どちらもNeo4jとベクトル検索を組み合わせ、AIエージェントに検索を道具として渡し、VPS上で運用しています。
業務の型から逆算して、必要な構成だけを当てる。これが「使えるAI」への近道です。手法をいくつ積んだかは関係ありません。まず小さく試して判断したい方は、初期費用0円のゼロスタート（PoC開発・MVP開発）からご相談ください。
よくある質問（FAQ）
Q. グラフDB（Neo4j等）は必須ですか？ベクトル検索だけではだめですか？
A. 用途しだいです。関係をたどる・数える・抜けを探す・根拠を示す問いが業務にあるなら、グラフを持つ価値が出ます。単純な1問1答ならベクトル検索だけで十分です。実務では、意味の近さはベクトル、関係と正確さはグラフに任せ、両方を統合するのが無難です。
Q. ナレッジグラフエージェントはVPSで運用できますか？
A. できます。中小規模なら自社サーバー（VPS）上でNeo4jとベクトルDBを動かして十分に運用できます。Beekleの2システムとも自社VPSで運用しています。可用性を強く求める場合や急スケールに備える場合は、マネージドを手間とコストのトレードオフで検討します。
Q. 既存のRAGチャットボットから移行できますか？
A. 段階的に移せます。既存のベクトル検索は残したまま、まずグラフ経路とリランク、回答後の検証を足すところから始めます。オントロジーは対象業務の分だけ小さく作り、効果を見ながら広げます。詳しくは社内ナレッジAIの精度を上げる作り方を参照してください。
Q. 社内データをグラフ化して、情報漏洩しませんか？
A. 設計で防げます。データを外部に出さないクローズドな構成（VPS内で完結）にし、誰がどのノードを見られるかをグラフ上のアクセス権とロールで制御する。検索クエリにテナント境界を必ず差し込めば、権限外の閲覧も案件をまたいだ漏れも抑えられます。
Q. 構築にはどれくらいの開発規模が必要ですか？
A. スコープによります。1業務のオントロジーと検索・検証を通したPoCから始め、運用の作り込み（鮮度・品質・アクセス制御）を経て本番化します。費用の考え方は生成AI開発の費用相場を参考にしてください。開発会社・SIerの立場で実装力の見極めや協業をご検討の場合も、お問い合わせから承ります。
Beekleにご相談ください Beekleでは、生成AI／CDP／業務システムの企画・要件定義・開発・運用までワンストップで支援しています。「何を作れば成功か」の整理、検証フェーズの設計、本番化判断まで、発注側の判断材料が揃うように伴走します。費用感の概算だけでも歓迎です。