ナレッジグラフとは：エンティティ、関係、根拠のモデル化

執筆：Ai Flowi · 公開日 2026-10-11

ナレッジグラフとは、識別可能なエンティティと、それらの間の関係を表すもので、通常は関係の意味を説明する属性も持ちます。文書、アカウント、人、その他の概念を、明示的なリンクで結び付けられます。有用なグラフでは、根拠と不確実性も記録します。エッジがあるというだけで、保存された関係を検証済みの事実と取り違えないためです。

以下の小さなグラフは、架空の業務文書を扱います。識別、関係の方向、情報源による裏付けを説明するもので、AI Flowi Workflowにグラフデータベース、クエリエンジン、推論機能があると述べたものではありません。

エンティティ、関係、トリプル

エンティティとは、アカウントや文書の特定の改訂版など、モデルが区別する対象です。安定した識別子と型を与えます。読みやすいラベルは人による確認に役立ちますが、識別子の代わりにしてはいけません。2つのアカウントが同じ名前を持つことも、1つのアカウントが同じエンティティのまま表示名を変えることもあります。

関係は、定義された意味と方向でエンティティを結び付けます。トリプルでは、主語が述語を通じて目的語につながります。たとえば、文書Dがbelongs_toでアカウントAにつながる、という形です。主語と目的語を逆にすれば、異なる主張になります。関係が文書全体の系列に適用されるのか、特定の改訂版に適用されるのかを決めます。そうしなければ、supersedesの意味が曖昧になります。

業務文書のグラフ例です。識別子はすべて架空です。狭い画面では、表の領域にフォーカスし、横にスクロールしてください。

evidence_refは、主張を裏付ける資料を指します。valid_fromフィールドは、その資料に基づき、関係がいつから適用されるかを表します。これらは説明用の仕様フィールドであり、すべてのグラフに共通の必須要件ではありません。情報源が観測日しか記録していない場合、それを黙って発効日と呼び替えてはいけません。

同じような名前でも、対象を統合せずに扱う

「Northstar Supplies」を検索すると、アカウントA17とアカウントA42が返ります。ラベルは一致しますが、識別子が異なるため、グラフでは2つのアカウントノードを保持します。D2を確認する担当者は、belongs_toエッジをたどってA17に到達します。文字列の類似性だけでD2を両方のアカウントに結び付けると、裏付けのない関係を作ることになります。

後から承認済みの情報源で、A42がA17の重複登録であると示された場合は、識別のリンクを変える前に、その照合・統合の判断と根拠を記録します。それまでは、2つのレコードは2つのままです。名前の一致は、レビュー候補を挙げる手掛かりにはなりますが、同一のエンティティであることを証明できません。

連絡先にも同じ注意が必要です。has_contact関係で連絡窓口を確認できても、署名権限が与えられるわけではありません。提案されたsigns_forリンクは、必要な根拠がないため不明です。モデルや都合のよいラベルで穴を埋めるより、その欠落を残すほうが有益です。

関係には出所と時間が必要です

採用したエッジごとに、情報源の参照と、それに至った解釈を保持します。情報源が関係を明記している場合も、担当者が文書化されたルールに従って導いた場合もあります。これらは異なる裏付けの経路です。導出した主張は、使用したルールやレビューの判断を含め、情報源からの引用文と区別できるようにします。

supersedesリンクは、提示された改訂通知に基づき、D2がD1を置き換えることを示します。D1のすべての記述が誤りだったという意味でも、履歴からD1を消すべきだという意味でもありません。以前の期間についての質問には、依然としてD1が必要な場合があります。関係が有効となる時点と、グラフが改訂を把握した時点を分けて保持します。

情報源が矛盾する場合は、競合する根拠と、関係の解釈が未確定であることを示すステータスを保存します。最新ファイルが未承認の下書きなら、それを自動的に選ぶ判断は誤りになり得ます。関係ごとに、どの情報源を正とするかを定めます。所属はアカウント台帳で、置き換えは改訂通知で確認する、といった形です。1つの情報源ですべてのエッジを扱う必要はありません。

ナレッジグラフとセマンティック検索の違いは何ですか？

セマンティック検索は、意味の類似性によって資料に順位を付けます。埋め込みは、適切な種類の文書に関する箇所を検索する助けになりますが、近いベクトルは明示的なbelongs_to関係ではありません。ナレッジグラフでは、関係ごとに名前と意味を定め、特定のエンティティ間のつながりを表します。その関係にも裏付けが必要です。

この2つの方法は補完し合えます。検索で根拠の候補を探し、レビュー済みのグラフで、採用した主張を結び付けられます。グラフに入れれば自動的に根拠が正確になるわけではなく、類似度のスコアが高くても証明にはなりません。質問が求めているのは、関連しそうな原文箇所なのか、既知のエンティティ間の裏付けられた関係なのかを判断します。

この例では、「アカウントA17に属する承認済みの改訂版はどれか」という質問には、アカウントの識別、所属関係、改訂の根拠が必要です。「アカウントのオンボーディングについて述べた文書を探す」は、類似性による検索タスクになり得ます。必要な根拠の違いを見極めずに両方を組み合わせると、関連して見えても、別のアカウントの文書を返す危険があります。

AI Flowi Workflowでの表現

レコードのインターフェースについては、JSON Object BuilderとJSON Operationsのリファレンスを使用してください。このグラフ表現の提案は、カタログに記載されていますが、Ai Flowiによる本番環境でのテストは行われていません。

記録されたテストではなく、設定例として、JSON Object Builderのfield_namesにsubject_id、relation、object_id、evidence_ref、valid_from、review_statusを列挙し、上のレビュー済みトリプルから値を渡します。意図する出力は主張のレコードです。情報源を検証するものでも、グラフの保存、オントロジー推論、動作するGraphRAG連携を確認するものでもありません。

関係を尋ねる質問の方向を確認する

「D2はどのアカウントに属するか」と尋ねます。提示されたbelongs_toエッジから、直接A17と答えられます。質問を「A17に属する文書はどれか」に変えると、belongs_toの目的語がA17である文書の主語を探す必要があります。同じ関係の主語としてA17を扱うと、意味が逆になります。逆関係を提供するグラフシステムもありますが、この教材用レコードでは作っていません。

次に、C8がD2に署名できるかを尋ねます。レコードには、A17への連絡先のつながりと、D2がA17に属するつながりがありますが、採用済みのsigns_forエッジはありません。2つの有効なエッジを組み合わせても、欠けている権限は補えません。利用可能な連絡先と文書の関連を返し、権限の問題は未解決のまま残します。これは提示された根拠の限界であり、十分に似た原文箇所を探せなかったという問題ではありません。

担当者は、D2の根拠参照を取り除いて主張が裏付けを失うことを確認したり、目的語をA42に変更して情報源と一致しなくなることを確認したりして、この小さなモデルを試せます。これらは確認ケースの提案であり、記録された製品の結果ではありません。JSONオブジェクトに期待されるキーがすべて含まれているかを確認するだけでなく、関係の意味と対象の識別を確かめます。

よくある誤りと関連資料

表示名でエンティティを統合したり、連絡先のリンクから権限を推測したり、履歴に関する質問から置き換えられた情報源を除いたり、抽出されたすべての関係を確定済みとして受け入れたりしないでください。根拠が欠けている場合は、明示的に不明として確認します。エッジを説明できる小さなグラフのほうが、対象の識別や出所が曖昧な大きなグラフより有用です。

類似性による検索は、セマンティック検索で扱います。ベクトルデータベースは埋め込みの保存を、ナレッジベースチャットボットのガイドは検索した根拠に基づく回答を説明しています。これらの内容は、ここに示す明示的な関係と根拠のモデルを置き換えるものではありません。