知識グラフとは、「エンティティ」と「エンティティ間の関係」を網の目のように組織化した知識の表現方法である。例えば「張偉—あるIT企業に勤務—職位はエンジニア」といった「主語—関係—目的語」の三つ組（トリプル）をつなぎ合わせれば、一枚のグラフになる。表形式との最大の違いは、関係が第一級の存在であることだ。join しなくても関連を直接たどれる。
まずはその姿を理解する
最も直感的なイメージは「ノード＋エッジ」である。ノードは人・企業・場所・出来事などのエンティティ、エッジは「〜年に創業」「〜に所在」「〜を買収」といった関係だ。関係自体に名前が付いているため、機械は列名から推測するのではなく、関係を読んで意味を理解できる。検索エンジンのナレッジパネルや百科事典の情報ボックスの多くは、知識グラフの発想で動いている。
三つの境界線：「知識グラフではないもの」
第一に、意味検索ができるものは知識グラフではない。それはベクトルデータベースだ。ベクトルが格納するのは「何に似ているか」であり、知識グラフが格納するのは「どんな関係か」である。第二に、グラフデータベースは知識グラフとイコールではない。グラフデータベースはストレージエンジンであり、知識グラフは知識の組織化の方法だ。エンジンは知識グラフの格納に使えるが、別のグラフを格納することもできる。第三に、大規模言語モデル自体は知識グラフではない。モデルパラメータに暗黙的に含まれる知識は確率的で誤りうるが、知識グラフの各関係は明示的に宣言され、追跡可能である。
比較表：知識グラフ・ベクトルデータベース・RAG の役割分担
三者の関係を一言で整理すると、RAG は仕事をするフローであり、ベクトルデータベースと知識グラフはそのフローに知識を供給する二種類の知識ベースだ。
| 比較軸 | 知識グラフ | ベクトルデータベース | | 格納するもの | エンティティと明確な関係 | テキストを変換したベクトル | | 強み | 多段推論・精密な質疑応答 | あいまいな意味マッチング | | 典型的な問い | 「A社の創業者は他にどの会社を創業したか」 | 「意味の近い文章を探す」 | | 弱み | 構築コストが高く更新が遅い | とんちんかんな回答が出やすい |
RAG（検索拡張生成）は、検索した知識を大規模モデルに渡して回答させる一連のフローである。ベクトルデータベースでの意味検索も、知識グラフでの関係クエリも使え、両者を併用することもできる。この手法は学界で GraphRAG と呼ばれる。
よくある三つの誤解
誤解その1は「知識グラフは時代遅れで、ベクトル検索に置き換えられた」。実は逆で、関係型の問いはベクトル検索の弱点そのものだ。多段の問い（例：「ある製品の創業者の前職の会社を買収したのは誰か」）はベクトル検索では連鎖が切れやすく、グラフによる関係推論で補う必要がある。誤解その2は「知識グラフの構築＝グラフデータベースの導入」。エンジンは器にすぎず、本当の仕事はオントロジー設計とエンティティ照合にある。「北京」と「北京市」を同一ノードとみなすかどうかは、どのデータベースを選ぶかよりずっと重要だ。誤解その3は「中小企業には使えない」。全領域を手作業で構築するのは確かに高コストだが、現実的なやり方は「小さく、専門的に」だ。製品の故障事例集や法規制データベースなど、一つの業務領域に絞れば、最も効果が出やすい。
本当に得意な場面
金融リスク管理における関連当事者の追跡、EC における商品知識の質疑応答、医療における薬物相互作用の照会、カスタマーサポートにおける約款の追跡——共通点は、答えが精密で、説明可能で、具体的な関係にまで追跡できることでなければならない点だ。「似ているように見える」テキストでは足りない。知識グラフが答えるのは「それが一体何なのか」という問いであり、業務があいまいな答えを許さないとき、関係が明確な知識の網は依然として欠かせない基盤である。
