ナレッジグラフとは

ナレッジグラフは、概念や物事（エンティティ）をノード、それらの間の関係をエッジで表すデータ構造です。

「グラフ」という言葉を聞くと棒グラフや折れ線グラフを思い浮かべるかもしれませんが、ここでのグラフは数学・グラフ理論の意味です。点と線でつながった構造そのものを指します。

有名な例が Google の検索結果に出る情報パネルです。「東京」と検索したとき右側に人口・面積・関連都市が並ぶあの表示は、Google が構築した大規模なナレッジグラフから引き出されています。「東京」「日本」「神奈川」「大阪」といったエンティティが、「首都である」「隣接する」「より大きい」といった関係のエッジでつながっているイメージです。

RDB との違い

リレーショナルデータベース（RDB）は行と列で構成された表にデータを格納します。関係を表すには外部キーを使い、複数のテーブルを JOIN して初めて「どのレコードとどのレコードがつながっているか」がわかります。

ナレッジグラフでは「関係そのもの」がファーストクラスのデータです。

RDB:
  users テーブル (id, name)
  posts テーブル (id, author_id, title)
  → JOIN して「誰が何を書いたか」がわかる

ナレッジグラフ:
  ノード: User("Alice"), Post("記事A")
  エッジ: User("Alice") --[書いた]--> Post("記事A")
  → エッジを辿るだけで関係がわかる

多対多の関係や、種類の異なるエンティティ同士の接続が自然に扱えるのが特徴です。RDB で多対多を表現するには中間テーブルが必要ですが、グラフではエッジを増やすだけです。

何が嬉しいのか

ナレッジグラフが力を発揮するのは、「A と B がどうつながっているか」を問いたい場面です。

  • 最短経路の探索 — 2 つのエンティティを結ぶ最短の関係経路を求められます
  • 意外な接続の発見 — A→B→C→D と辿ることで直接見えなかった関係が浮かび上がります
  • 構造を保ったクエリ — 「このノードから 2 ホップ以内に存在するエンティティ」のように、関係の深さを指定して検索できます

RDB が「このレコードの値は何か」を得意とするのに対して、ナレッジグラフは「このエンティティは何とつながっているか、その先は何か」を得意とします。

コードベースへの応用

この構造はコードベースの把握にも活かせます。

コードを構成するファイル・関数・モジュール・ドキュメントをノードとして、import・関数呼び出し・型参照・ドキュメントリンクをエッジとして表現すると、プロジェクト全体がひとつのグラフになります。

ノード: AuthController, UserService, Database, README
エッジ: AuthController --[呼び出す]--> UserService
        UserService    --[接続する]--> Database
        README         --[説明する]--> AuthController

このグラフがあれば、「この関数を変更したらどこに影響するか」「認証とデータベースはどこでつながっているか」といった問いにクエリで答えられます。ファイル数が増えて全体像が掴めなくなってきたとき、特に有効なアプローチです。

まとめ

  • ナレッジグラフはノード（エンティティ）とエッジ（関係）でできたデータ構造
  • 「グラフ」は可視化ではなく数学的な構造の話
  • RDB が「値」を中心に置くのに対して、ナレッジグラフは「関係」をファーストクラスで扱う
  • 多対多・異種エンティティ間の接続が自然に表現でき、つながりを辿るクエリが得意
  • コードベースにも適用できる——ファイルや関数をノード、依存関係をエッジにすれば、影響範囲や構造の把握が容易になる

次の記事では、この考え方を実装した graphify というツールを取り上げます。プロジェクトのコードベースをナレッジグラフとして自動生成する仕組みを見ていきます。