「似た文書は見つかるのに、関係者・契約・履歴を正しくたどれない」なら、保存方式の選択が原因かもしれません。
最短の判断は、類似内容の検索ならベクトルデータベース、エンティティ間の関係や多段階の問い合わせならナレッジグラフです。両方が必要な本番AI Agentでは、ベクトル検索を召回、ナレッジグラフを関係検証に分けて使います。
このページが役立つ人
RAGアプリケーションの保存先を決めたい開発者向けの記事です。
複雑な関係、意思決定の追跡、監査ログまで扱うアーキテクチャ担当者や、併用構成の運用費を見積もるプラットフォームチームにも適しています。
最初に決めるべきなのは「何を探すか」です
ナレッジグラフとベクトルデータベースの違いは、単なる製品機能の差ではありません。検索対象の単位が違います。
ベクトルデータベースは、文書チャンクや会話記録を埋め込みに変換し、質問と意味が近い候補を探します。「返品条件を説明している箇所はどこか」「このエラーに似た過去事例は何か」といった問いに向いています。
一方、ナレッジグラフは、人物、製品、部署、契約、イベントなどをノードとして扱い、関係をエッジとして保存します。標準的なRDFでは、情報は主語・述語・目的語の3要素からなるトリプルで表現されます。関係そのものをデータとして扱える点が重要です。詳しくは公式RDF 1.1仕様で確認できます。(w3.org)
判断に迷ったら、質問を次の2種類に分けてください。
- 「似た内容、近い説明、関連する文章」を探すならベクトルデータベース
- 「誰が誰に所属するか、何が何に依存するか、どの経路を通ったか」を探すならナレッジグラフ
注意：ベクトル検索の類似度が高いことは、関係性が正しいことを意味しません。候補文書を見つける機能と、関係を確定する機能は分けて評価してください。
データの作り方と更新負荷は大きく異なります
ベクトル方式では、文書を一定の単位に分割し、各チャンクへ埋め込み、出典、更新日時、アクセス制御用の属性を付与します。更新時は、変更されたチャンクだけを再分割・再埋め込みする設計にすれば、全件処理を避けられます。
ただし、チャンクの切り方が悪いと、条件と例外が分離します。契約書の「適用条件」と「除外条件」が別チャンクになれば、検索結果は近くても回答は不完全になります。長期記憶として会話を保存する場合も、発言単位で保存するだけでは、同一人物や同一案件の識別が崩れやすくなります。
ナレッジグラフでは、エンティティの定義、識別子、関係の向き、関係の有効期間、出典を先に設計します。グラフ型データベースでは、ノード、関係、プロパティを中心にモデル化し、関係自体にも属性を持たせられます。グラフデータモデルの公式解説でも、関係には方向、種別、プロパティがあると説明されています。(neo4j.com)
そのため、初期の統合作業は重くなります。異なる表記の会社名を同一企業としてまとめる名寄せ、部署の変更履歴、削除された情報の伝播範囲まで決めなければなりません。しかし、一度整えた関係を複数のAgentや画面で再利用できるなら、長期的な価値は高くなります。
多段階の問い合わせでは差が明確になります
たとえば、次の質問を考えてみます。
「昨年変更された部品を使い、現在も供給停止リスクがある製品について、承認した担当部署と根拠文書を示してください。」
この問いには、製品、部品、変更履歴、供給状態、承認者、部署、根拠文書という複数の対象が含まれています。ベクトル検索だけでも関連しそうな文書を複数取得できますが、文書間の関係が正しい順序でつながっているかは別途確認が必要です。
ナレッジグラフなら、「製品が部品を使用する」「部品が変更された」「変更が承認された」「担当者が部署に所属する」といった経路を問い合わせとして表現できます。履歴を扱う場合は、関係に有効期間や発生日を持たせ、現在の関係と過去の関係を混同しないようにします。
GraphRAGの公式ドキュメントでも、特定エンティティを中心に検索するローカル検索と、データ全体のテーマを集約するグローバル検索を分けています。また、基本的なベクトルRAGとの比較機能も用意されています。GraphRAGの検索方式とグローバル検索の説明は、単一文書の近似検索と、データ全体の集約的な推論を分けて考える材料になります。(microsoft.github.io)
ここで重要なのは、ナレッジグラフを導入すれば自動的に正解になるわけではないことです。抽出モデルが誤った人物や製品を同一視すれば、グラフ上の経路も誤ります。関係ごとに出典、信頼度、適用期間を保持し、回答時に検証できる設計が必要です。
説明性、権限、削除処理を比較します
企業利用では、回答の速さだけでなく「なぜその回答になったか」を説明できることが求められます。
ベクトルデータベースでは、上位に返ったチャンク、類似度、出典文書を提示できます。ただし、複数のチャンクから推論した場合、どの関係を根拠にしたのかが見えにくくなることがあります。検索時に部署ID、顧客ID、文書区分などの属性フィルターを適用しないと、権限外の情報が候補に混ざる危険もあります。
ナレッジグラフでは、回答に使ったノードと関係の経路を示しやすくなります。一方で、アクセス権をノードだけに付けると不十分な場合があります。契約関係、承認記録、会話イベントなど、関係そのものに機密性があるためです。削除依頼を受けた場合も、元文書、抽出されたエンティティ、関係、要約、埋め込みをどこまで消すかを定義してください。
経験上、併用構成で最も起きやすい事故は、ベクトル側のチャンクIDとグラフ側のエンティティIDが対応していないことです。保存時に文書ID、チャンクID、エンティティID、出典位置を共通のメタデータとして持たせると、検証しやすくなります。
性能と費用は同じデータで測る必要があります
「どちらが速いか」を、異なるデータセットや異なるクエリで比較してはいけません。少なくとも、同一データ、同一ハードウェア、同一クエリ集合で、取り込み、更新、検索、再ランキング、生成処理を分けて計測します。
ベクトル検索では、完全近傍検索と近似近傍検索の違いを記録してください。たとえば、代表的なベクトル検索拡張では、HNSWとIVFFlatという2種類のインデックスを使えます。HNSWは速度と再現率のバランスを取りやすい一方、構築時間とメモリ使用量が増えます。IVFFlatは構築が速くメモリを抑えやすい一方、リスト数や探索範囲の調整が必要です。公式インデックス仕様にこのトレードオフが整理されています。(github.com)
ナレッジグラフでは、ノード数だけでなく、関係の密度、検索の深さ、同一性解決の精度、更新頻度が負荷を左右します。取り込み時のエンティティ抽出や関係抽出にモデル呼び出しが必要なら、データベース費用とは別に推論費用も見積もる必要があります。
評価指標は、次のように分けると比較しやすくなります。
- 検索品質：正しい根拠が上位に含まれるか
- 関係品質：対象エンティティと経路が正しいか
- 更新品質：変更や削除が反映されるまでの時間
- 応答品質：出典付きで回答できるか
- 運用負荷：再処理、監視、権限管理、障害復旧の手間
- 生成費用：検索後にモデルへ渡すコンテキスト量と呼び出し回数
条件別の選択マトリクス
| 利用条件 | 第一候補 | もう一方を追加する条件 | 主な検証項目 |
|---|---|---|---|
| 社内文書の検索と要約 | ベクトルデータベース | 文書間の関係確認が頻発する場合 | 上位検索の再現率、出典表示、権限フィルター |
| 個人化されたAI Memory | ベクトルデータベース | 人物、案件、時系列の混同が起きる場合 | 同一性解決、記憶の更新と削除 |
| サプライチェーンや組織関係 | ナレッジグラフ | 根拠文書の全文検索が必要な場合 | 多段階経路、期間条件、出典ID |
| 規制対応や意思決定監査 | ナレッジグラフ | 根拠資料の候補抽出を高速化したい場合 | 経路の再現性、権限、削除範囲 |
| 用途が混在する本番Agent | 併用 | データ量と運用チームが増えた場合 | ID対応、同期遅延、二重登録、障害時の整合性 |
単純なFAQや少量の文書検索であれば、最初からナレッジグラフを構築する必要はありません。まずベクトルデータベースで検索品質と失敗パターンを測り、同一性混同、多段階の関係確認、履歴の矛盾が継続して発生したらグラフ層を追加します。
反対に、承認経路、組織階層、製品依存関係、監査証跡が最初から要件に含まれるなら、後付けを前提に文書IDとエンティティIDを設計しておくべきです。ベクトル側だけで始める場合でも、将来グラフへ接続できる識別子を失わないことが重要です。
導入時に確認する5つの手順
-
実際の質問を分類します。
類似文書、単一エンティティ、関係経路、全体傾向、履歴確認に分けます。検索方式を先に決めず、質問の種類から始めてください。 -
正解データを作ります。
実際の質問に対して、正しい文書、エンティティ、関係、適用時点を人手で記録します。正解がないまま速度だけを測ると、誤った回答を高速化することになります。 -
最小構成を実装します。
文書チャンク、埋め込み、出典位置を持つベクトル検索を先に作るか、対象エンティティと主要関係だけの小さなグラフを作ります。両方を同時に全件導入しない方が原因を追いやすくなります。 -
失敗ログを分類します。
関連文書が取れない、同一人物を統合できない、関係の向きが逆、古い情報が優先される、権限外データが混ざる、といった原因に分けます。 -
併用時の責任範囲を固定します。
ベクトル側は候補の召回、グラフ側はエンティティ同定と関係検証、原文側は最終的な根拠提示というように、各層の役割を決めます。
KvmzenのMac環境を検証に使う場合も、同一データセット、同一クエリ、同一モデル条件をそろえてください。Mac環境を使った検証方法を確認し、短期のPoCと本番運用を分けて評価すると、構成差ではなく保存方式の差を見極めやすくなります。
検証環境をチームで共有する場合は、運用主体の情報を確認してください。保存方式の選定と実行環境の選定を分けて整理し、アクセス権、データ削除、ログの保存範囲を先に決めておくと、ハードウェアの違いを検索品質の差と取り違えにくくなります。
FAQ
ナレッジグラフとベクトルデータベースは何が違いますか？
ベクトルデータベースは、質問と意味が近い文書や記録を探すための保存先です。ナレッジグラフは、人物、製品、組織、契約などのエンティティと関係を明示的に保存します。前者は類似情報の発見、後者は関係性、経路、履歴、監査の確認に向いています。
AI Agentにはどちらを選ぶべきですか？
RAGのPoCや文書検索から始めるなら、ベクトルデータベースの方が導入しやすいです。組織関係、承認経路、製品依存関係、過去の判断を正確にたどるならナレッジグラフを優先します。両方の要件がある場合は、検索と検証を分担する併用構成を検討してください。
2つの方式を一緒に使うことはできますか？
併用できます。ベクトル検索で関連するチャンクを集め、共通の文書IDやエンティティIDを使ってグラフ上の対象を特定します。その後、グラフで関係、方向、時点、権限を確認し、原文チャンクを最終根拠として提示する構成が扱いやすいです。
多段階の質問にベクトル検索だけを使えない理由は何ですか？
ベクトル検索は意味的に近い文章を返しますが、複数の関係を正しい順番でつなぐ保証はありません。「担当者の所属部署が承認した契約」のような質問では、候補文書の取得後に人物、部署、承認、契約の対応関係を検証する必要があります。
ナレッジグラフを導入しなくてもよいケースはありますか？
単一文書の要約や検索で大半の質問が解決し、関係性の監査や多段階推論が不要なら、ナレッジグラフは後回しで構いません。まずベクトル検索で失敗ログを集め、同一性混同や履歴矛盾が継続する段階でグラフを追加する方が、初期の運用負荷を抑えられます。
現在の構成からMac環境へ切り替える判断
既存のWindowsやLinux環境、あるいは共有クラウドサーバーでPoCを続ける方法もあります。ただし、共有資源による実行時間の揺れ、権限設定の複雑さ、チームごとに異なる依存関係、検証終了後も残るサーバー費用が負担になりやすい点は見落とせません。
短期間だけローカルモデル、埋め込み生成、グラフ検索、ベクトル検索を同じ条件で比較したいなら、専用のMac環境をレンタルして検証範囲を固定する方が判断しやすい場合があります。長期の安定した高負荷処理や物理インターフェースが必要なら自社保有が適していますが、短期のAI Memory検証や構成比較では、まずKvmzenのMac環境で自分のデータを測り、併用する価値があるかを確認するのが現実的です。
よくある質問
ナレッジグラフとベクトルデータベースは何が違いますか？
ベクトルデータベースは、質問と意味が近い文章や埋め込みを探す仕組みです。一方、ナレッジグラフは、人物、製品、部署、契約などのエンティティと、その間の関係を明示的に保存します。前者は類似情報の発見、後者は関係性の追跡や多段階の問い合わせに向いています。
AI Agentにはナレッジグラフとベクトルデータベースのどちらを選ぶべきですか？
文書検索を早く始めたい、質問と近い根拠を返したい場合はベクトルデータベースから始めます。組織関係、依存関係、履歴、承認経路を正確にたどる必要がある場合はナレッジグラフが適しています。用途が混在する場合は、ベクトル検索で候補を集め、グラフで関係を検証する構成が現実的です。
ナレッジグラフとベクトルデータベースは一緒に使えますか？
併用できます。文書チャンクには埋め込みと出典IDを付け、抽出したエンティティにも同じIDを保持させます。ベクトル側は候補文書の召回、グラフ側は人物や製品などの同一性確認、関係性の追跡、権限判定を担当させると、役割が曖昧になりにくくなります。
多段階の質問はなぜベクトル検索だけでは難しいのですか？
ベクトル検索は、質問に意味的に近い文章を探すのが得意です。しかし「Aが所属する部署の責任者が承認した契約」のように、複数の関係を順番に確認する問いでは、近い文章が正しい経路を保証しません。候補の召回後に、エンティティID、関係の向き、時点を別途検証する必要があります。
どのような場合にナレッジグラフは不要ですか？
対象データが少なく、質問の大半が単一文書の要約や検索で解決し、関係性を監査する要件もない場合は、最初からグラフを作る必要はありません。文書分割、埋め込み更新、出典表示を整えたベクトル検索で始め、実際の失敗ログに多段階推論や同一性混同が増えた時点でグラフを追加する方が安全です。