ナレッジグラフの価値は、つながりの数ではなく関係の定義で決まる

ナレッジグラフ(Knowledge Graph)は、ものごととその間の関係を網の目のように記録する知識の表し方です。ただ、網の目が細かいほど賢いと考えるのは早合点で、価値を決めるのはつながりの数ではなく、関係にどんな名前を付け、その名前を誰がどう定義したかです。この記事では、定義と仕組みを短く押さえたうえで、関係の定義が判断のどこで効くのか、どこで誤りを増幅するのかを示します。

ナレッジグラフは、実体と関係と型の定義でできています

ナレッジグラフは、ある領域の概念をノード(節点)、概念どうしの関係をエッジ(辺)として、グラフの形で体系的に表した知識データの総称です。「AはBの子会社である」「XはYで使われる技術である」といった関係でつなぐことで、データの羅列ではなく、データ同士の意味のつながりを持たせます。

ナレッジグラフの定義

一般に、次の三つがそろうものをナレッジグラフと呼びます。

  • エンティティ(人名、地名、組織名、書籍、化合物など)の集まり
  • エンティティ間の関係(所属、親子、依存など)の集まり
  • 関係や概念の型の定義(スキーマやオントロジー)。RDF Schema(RDFS)やOWLが代表例

データの持ち方には二つの流儀があります。主語、述語、目的語の三つ組で表すRDF(Apache Jena、Virtuosoなど)と、ノードとエッジに属性を付けるプロパティグラフ(Neo4j、ArangoDBなど)です。RDFはすべてをURIで表すため、DBpediaやWikidataのようなリンクトデータの土台になります。プロパティグラフは意味の厳密さで劣る代わりに、実装しやすく問い合わせが速い。問い合わせ言語は、RDFならSPARQL、Neo4jならCypher、Apache TinkerPopならGremlinです。

エッジは事実ではなく、事実の解釈を固定したものです

worksAt(Alice, 会社X)という一本のエッジを考えます。Aliceが業務委託で週に一日だけ会社Xの仕事をしている場合、このエッジを引くかどうかは、データを入れる人の解釈で決まります。所属を雇用契約と定義すれば引かない。継続的に仕事をしていることと定義すれば引く。Aliceについての事実は一つなのに、グラフは二通りになります。

この違いは、推論エンジンを通すと大きくなります。推論エンジンは、明示していない関係を定義から導きます。「すべてのPersonはAnimalである」と定義しておけば、Personに属するものは自動的にAnimalにも含まれます。同じ仕組みで、所属の定義がゆるければ、会社Xの機密資料を見てよい人の一覧に、週一日の委託先が論理的に正しく加わります。推論エンジンは、間違った定義を、間違いのない手順で全社に配ってくれる優秀な配達員です。

だから、ナレッジグラフづくりで最も重いのは、データを集める作業より、関係の名前と意味を決める作業です。金融のFIBO、臨床試験のCDISCのような業界標準のオントロジーが参照されるのは、この定義を一から自分たちで争わずに済むからです。

他の仕組みとの境目

リレーショナルデータベースとの違いは、表の設計を最初に固めなくてもデータを登録できることと、つながりを最初から重視しているので何段階もの結合を簡単に扱えることです。グラフ型のデータベースを使っていれば、それだけでナレッジグラフになるわけではありません。型と関係の定義がなければ、点と線が並んだだけのデータです。

RAG(検索拡張生成)との境目も押さえておきます。ベクトル検索は意味の近さで資料の断片を探しますが、関係の向きや種類は分かりません。そこでグラフから関連知識を引き、事実の正確さを補う使い方が広がっています。ただし、グラフの関係の定義が誤っていれば、AIはその誤りを根拠つきの事実として回答に使います。

使われている場面と、運用でつまずく点

Googleは2012年にKnowledge Graphを導入し、検索語を概念として理解して、関連する人物や作品を構造的に表示するようになりました。ほかにも、好みとジャンルの関係を使った推薦、遺伝子、タンパク質、疾患、薬剤の関係を表す創薬研究、部門ごとのデータをつなぐ社内の知識管理で使われています。

構築は、目的を決め、概念と関係を洗い出して定義し、既存のDBやCSVからデータを集めて形式をそろえ、同じ人物や会社が別の表記で入っていないかを突き合わせ(エンティティ解決)、更新履歴を持って保守する、という順で進みます。運用では、数百万から数十億のノードに及ぶときの性能、誤ったリンクが推論を狂わせる品質の問題、アクセス制御、増え続ける新しいクラスや関係への対応が課題になります。

関係の定義に正解があるとは限りません。所属の定義は、人事の目的と情報管理の目的で違ってよいはずです。一つのグラフに一つの定義を押しつけるか、目的ごとに関係を分けるかは、規模とコストしだいで、決まった答えはありません。

あなたの組織で、部署によって違う意味で使われている関係の言葉はどれでしょうか。所属、担当、顧客、そのどれかの定義を一つ変えたら、どの判断の結論が変わるでしょうか。

この記事の背景にある考え方は、拙著『GoogleのAI NotebookLM 意思決定の強化書』の1章3節「前提と定義が結論を決める」に書きました。買収の検討で、シナジーという一語の定義を広げるか狭めるかで、AIの結論が積極推奨から見送りまで動く例を扱っています。「重要な用語をどう定義するかによって、AIが出す結論は180度変わります。」この節を読むと、データの量を増やす前に、どの言葉の定義を固めるべきかを自分で見極められるようになります。

同じ資料を見ているのに、なぜ結論が割れるのか。

GoogleのAI NotebookLM 意思決定の強化書 表紙

『GoogleのAI NotebookLM 意思決定の強化書』

前提が結論を決める。意思決定を根拠、前提、結論の三層に分け、前提を対象、目的、制約、評価基準の四つで言葉にする本です。

読み終えたとき、手元に残るもの

  • 意思決定の設計図になる前提リスト
  • 資料を事実、意見、噂、ゴミに仕分けるFORT
  • 同じ物差しで比べる選択肢表と採点表
  • 始める条件と止める条件を書いた決定書

NotebookLMは2026年7月にGemini Notebookへ名称が変わりました。本の手法は、使うAIの種類を問いません。

Amazonで見る

著者プロフィール・お問い合わせ