ナレッジグラフとは｜企業のAI活用で重要視される理由

自社でのAI活用に向けたデータ基盤の整備を検討しはじめると、頻繁に現れる言葉の1つに「ナレッジグラフ」というものがあります。

ナレッジグラフは、企業でのAI活用が進む中で非常に重要視されている基盤技術です。

本記事では、用語の定義から始め、なぜ今AI活用の文脈でナレッジグラフが重要視されているのか、企業のデータ基盤に組み込むと何が変わるのか、そして自社に必要かをどう判断すればよいのかまで、順を追って整理します。

ナレッジグラフとは

ナレッジグラフとは、ヒト・モノ・概念を「点（ノード）」、それらの関係を「線（エッジ）」でつなぎ、情報の関係性をグラフ構造で表現する技術です。
ナレッジグラフを理解するには、まず「グラフ」という言葉の定義から見ていきます。

まず「グラフ」とは何か｜点と線で関係を表す考え方

「グラフ」と聞くと、多くの方はまず棒グラフや折れ線グラフを思い浮かべるかもしれません。
ここで記載しているグラフは、それとは別のものです。
数学の「グラフ理論」に由来する、点と線で物事の関係を表す考え方を指しています。

グラフ理論では、対象を「ノード（節点・頂点）」、対象同士の関係を「エッジ（辺）」と呼び、ノードの集合とエッジの集合でグラフを表現します。

身近な例で言うと、鉄道の路線図、SNS上の友人関係、組織の相関図といった「モノ・人・場所」を点として置き、それらの関係を線でつないだ表現は、すべてこの意味での「グラフ」にあたります。

グラフとは「点と線で関係を表現する考え方」であり、棒グラフや折れ線グラフとは別物です。

ナレッジグラフとは、情報を点と線でつなぎ、関係性をグラフ構造で表現する

このグラフの考え方を「情報」に適用したものが、ナレッジグラフです。

ナレッジグラフとは、人、モノ、場所、出来事、概念などを「点」として、それらの関係を「線」としてつないだデータの集まりのことを指します。

もう少し具体的に見ていきます。
たとえば社内の情報を、次のような点と線の集まりとして表したとします。

• 「案件A」という点と、「株式会社◯◯」という点を、「契約している」という線でつなぐ

• 「株式会社◯◯」という点と、「製造業」という点を、「業界に属する」という線でつなぐ

• 「田中さん」という点と、「案件A」という点を、「担当している」という線でつなぐ

• 「案件A」という点と、「製品X」という点を、「提供している」という線でつなぐ

こうやってつなげていくと、「田中さんが担当している案件Aは、製品Xを対象としており、顧客は製造業の株式会社◯◯である」という情報が、ノードとエッジの網目として表現できます。

このように、ヒト・モノ・概念を点として置き、それらの関係を線でつないだデータの集まりが、ナレッジグラフです。

個別のデータを孤立した情報として持つのではなく、「何と何が、どういう関係で結びついているか」までを一緒に持っているというのが特徴です。

なぜ今、AI活用の文脈でナレッジグラフが重要視されているのか

ナレッジグラフの歴史

ナレッジグラフの元となる考え方は、実は今から60年ほど前、1960年代の人工知能研究のなかで「セマンティックネットワーク」として既に提案されていました。
「知識を点と線のネットワークで表す」という発想自体は、決して新しいものではありません（出典: Knowledge graph｜Wikipedia）。

「ナレッジグラフ」という言葉が一般に広く知られる契機になったのは、Googleが2012年5月に検索機能へ「Knowledge Graph」として取り入れたことです。
（出典: Introducing the Knowledge Graph: things, not strings｜Google Blog）。

身近な例として、有名人や企業名をGoogleで検索したときに、結果の右側に生年月日・出身地・代表作といった要約パネルが表示されることがあるかと思います。
あの表示は、Googleが持つナレッジグラフから、その人物や企業に関する事実と関係を引き出して構成されているものです。（出典: Googleのナレッジグラフの仕組み｜Googleヘルプ）。

企業のデータ管理では長らく使われてこなかった

概念自体は60年ほど前から存在し、Googleの検索裏側では2012年から実用化されてきたにもかかわらず、多くの企業のデータ基盤の議論の中心にナレッジグラフが登ってくることは、長らくありませんでした。
その背景には、企業データの中心が表形式の構造化データにあった、という事情があります。

企業のデータ管理は、長らく、行と列でデータを表現する表形式のリレーショナルデータベース（RDB）を中心に発展してきました。
企業の中核業務（会計、受発注、在庫管理、顧客管理）で扱うデータは、行と列にきれいに収まる性質のものが多く、この業務データの性質と表形式の表現がよく噛み合ったことが、RDBが長らく主流だった大きな理由です（出典: RDBとNoSQLにみるDB近現代史｜AMBI）。

その一方で、議事録・契約書・メール・画像・音声といった、行と列に収まらない情報、いわゆる非構造化データは、社内に大量に存在していたにもかかわらず、扱う技術も動機も限定的な状態が続いていました。
個別のファイルとして共有ドライブに置かれ、そこから先の活用は人間の記憶と手作業に委ねられてきた企業が多いのではないでしょうか。

業務のなかで発生する問いも、「先月の売上」「在庫回転率」「顧客数の推移」のように、あらかじめ設計された切り口で数字を返してもらう形が中心でした。
表形式のデータで完結する用途がほとんどだったため、モノとモノの関係を「点と線」で辿るナレッジグラフの出番は少なかったと言えます。

生成AIの登場で、AI活用の文脈で重要視されるようになった

この構図が2020年代に入って動き出したきっかけが、生成AIの登場と業務への浸透です。

生成AIは、これまで扱いが難しかった議事録・契約書・メール・画像・音声といった非構造化データを、人間に近い形で読み解いて要約したり分類したりできるようにしました。
社内に眠っていた膨大な非構造化データが、AI経由で業務活用の対象に組み込まれ始めた、と言い換えられます。

これに伴い、社内データに対して人間が投げる問いのタイプも大きく変わってきました。
これまでは、BIツールで数字のグラフを見る、業務システムから条件を指定してレコードを取り出す、といった「あらかじめ設計された切り口で結果を返してもらう」形が中心でしたが、生成AIの登場後は、話し言葉で「あの取引先の直近の状況を、契約書と議事録も踏まえて教えて」と問えるようになり、単発の検索や個別テーブルの参照を超えて、複数の情報を関係で辿って束ねた答えを求めるようになっています。

ここで、非構造化データの扱いの難しさが同時に浮上してきました。
議事録・契約書・メールといった非構造化データでは、「この議事録はどの案件のもので、どの担当者が参加していて、直前のどの契約書と関係しているのか」といったつながりが、テキストのなかに埋もれていて、明示的には保持されていません。

社内データをAIから使いやすい形で活かすためには、「どのデータがどう関係しているか」までを一緒に持たせておく必要が出てきます。
ここで役割を果たすのが、モノとモノの関係を点と線で保持するグラフ形式のデータ表現、そしてその応用であるナレッジグラフです。

ノードとエッジで関係を保持するグラフのモデルは、ちょうどこの「関係を深く辿る」用途で強みを発揮するため、非構造化データの活用が進むほど、グラフとナレッジグラフの必要性が業務データ基盤の議論の中心に浮かび上がってきている、というのが現在ナレッジグラフが重要視されている背景です（出典: グラフデータベースとは何か｜i Magazine、ナレッジグラフとは？｜SAP）。

企業のデータ基盤にナレッジグラフを入れるとどう変わるか

企業のデータ基盤にナレッジグラフを入れると、社内に散在するデータの「意味」と「関係」がAIから読み取れる状態になり、AIに投げられる問いが関係を辿った洞察にまで広がります。

社内データの「意味」がAIから見えるようになる

多くの企業で、社内のデータは複数のシステムに分散して保管されています。
CRMには顧客情報と商談履歴、契約管理システムには契約書、共有ドライブには提案書や議事録、人事システムには組織と担当者の情報、といった具合です。

これらのデータは、システムごとに個別のフォーマットで格納されていて、「どのデータとどのデータが、どういう関係にあるか」はシステム側では明示的に持っていないことがほとんどです。
人間の担当者は経験と業務知識で結びつけて解釈していますが、その結びつけはシステムには残らないため、AIには渡せません。

ここにナレッジグラフを介在させると、たとえば次のような状態を作ることができます。

「案件Aという点は、顧客のB社という点と『対象顧客』でつながっており、B社は『業界』で製造業と、『担当営業』で田中さんとつながっている。田中さんは『所属』で営業2課と、『過去の担当案件』で案件C・案件Dと、それぞれ線でつながっている。契約書eは『対象案件』で案件Aと、『契約種別』で年間保守契約と結ばれている」

このように、個別のデータそれ自体だけでなく、データ同士の関係までを一緒に持たせておくことで、AIから見て「この情報が何なのか」「他と何がどうつながっているのか」が読み取れる状態になります。

イメージとしては、共有ドライブにバラバラに置かれていた書類の山が、索引と相互参照の付いた辞書のように整理し直された状態に近いかと思います。
書類そのものは同じでも、探し方・辿り方が変わるため、活用の幅が大きく広がっていきます。

AI活用がどう変わるか｜答えられるようになる問い

社内データの意味と関係が整理されると、AI活用の実感としてもっともわかりやすく変わるのは、AIに投げられる問いが広がることかと思います。

従来型のRAGで得意なのは、たとえば次のような単発の問いです。

• 「就業規則の在宅勤務に関する条項はどこにありますか」

• 「製品Xの仕様書の中で、消費電力について書かれている箇所を引用してください」

これらは「近い意味の文書を1本探してくる」タイプの問いであり、ベクトル検索型のRAGでも十分に対応できます。

一方で、ナレッジグラフを組み合わせると答えられるようになってくるのは、次のような「関係を辿らないと答えられない問い」です。

• 「あの取引先の直近3年の取引履歴と、担当者の異動を踏まえて、次の一手の候補を教えて」

• 「クレームが多い製品Xと同じ部品を使っている他の製品を、影響範囲として一覧化して」

• 「◯◯部の田中さんと業務内容が近く、田中さんが困りごととして挙げている論点に詳しい人が、他部門にいないか教えて」

• 「過去5年の全案件のうち、失注理由が『価格』と記録されているもののなかで、実は商談後半で意思決定者が変わったことが後から議事録で明らかになっている案件はいくつあるか」

こうした問いは、複数のデータや文書を、関係を辿りながら束ねて答える必要があります。

ナレッジグラフを併用すると、AIは点と点を辿りながら回答を組み立てられるようになるため、こうした問いに現実的な答えが返せる状態に近づいていきます。

ナレッジグラフが必要な3つの場面

最後に、自社にナレッジグラフが必要かは、「問いに対して『なぜ』が含まれる回答がほしいか」「顧客・業務の全体像を横断的に把握したい場面があるか」「生成AIの誤回答（ハルシネーション）を避けたいか」の3つの場面に、いくつ強く当てはまるかで判断できます。

ここまで読み進めていただくと、「ナレッジグラフがどんなものか」「なぜAI活用の文脈で重要視されているのか」「隣接概念とどう違うのか」は、それなりに掴めた状態になっているかと思います。
残る問いは、自社にとって本当に必要なのか、という判断です。

ここでは、ナレッジグラフが当てはまるタイプの業務・組織の状況を、3つの場面として整理します。自社の状況に照らして、いくつが強く当てはまるかを見ていただくことで、必要性の見立てをつけるための判断材料としてお使いいただけると幸いです。

場面1｜質問の回答に「なぜ」がほしいとき

まず、業務でAIに問いたいことの中身が、単発の検索のような問いにとどまらず、複数の情報を関係で辿った洞察を求めるものになっているかを見てみます。

「就業規則のこの条項はどこにありますか」「先週の議事録を要約してください」といったFAQ的な問いだけであれば、通常の生成AIが行う検索でも十分に対応できます。
むしろナレッジグラフを持ち込むと、オーバースペックになる場面が多いかと思います。

一方で、次のような問いを業務のなかで立てていく場合は必要になってきます。

• 「なぜこの案件は失注したのか」を、商談履歴・議事録・顧客の変化・担当の異動を横断して読み解きたい

• 「同じような課題を抱えている顧客は他にどこか」を、業種・規模・過去の相談内容・製品構成を跨いで探したい

• 「この製品にクレームが多い理由は、部品・工程・仕入先のどこにあるのか」を、複数のデータをまたいで辿りたい

こうした「なぜ」「どうつながっているか」を問うタイプの問いは、点と点を関係で辿らないと答えられません。
この種類の問いが業務のなかで日常的に発生しているのであれば、ナレッジグラフを検討する意味が出てくる場面かと思います（出典: Microsoft Research GraphRAG）。

場面2｜顧客や業務の全体像を横断的に把握したいとき

次に、複数のシステムに分散している情報を横串で把握したい場面が、業務のなかでどのくらいあるかを見てみます。

たとえば営業の現場では、A社の全体像を掴もうとすると、営業支援システムの商談履歴、サポートの問い合わせ履歴、契約管理の契約書、経理の請求データ、担当営業の異動履歴といった、複数のシステムをまたぐ必要があります。
個別のダッシュボードやレポートを都度作れば見られなくはありませんが、追加の問いが出るたびに連携処理を追加するのは、持続しにくい構造だと思います。

こうした「横串で全体像を掴む」用途は、RDBで扱おうとすると複数テーブルの結合が何段も深くなり、実行性能面でも設計面でも限界が見えてくることが知られています。

複数システムをまたいだ全体像の把握が業務の中核にある組織では、ナレッジグラフの構造が合いやすいと想定しています。

場面3｜AIの誤回答（ハルシネーション）を避けたいとき

3つ目は、すでに生成AIを業務に入れていて、AIの誤回答が課題として浮上している場合です。

生成AIの誤回答（ハルシネーション）は、多くの場合、AIが参照している情報の「意味」と「関係」が曖昧なときに起こりやすくなります。

文書の中に「山田さん」と書かれていても、それが顧客のA社の山田さんなのか、社内の山田さんなのか、あるいはB案件のパートナー会社の山田さんなのか。
文脈だけで判断させると、AIはもっともらしい間違いを返すことがあります。

ナレッジグラフでデータの意味と関係を明示しておくと、AIは点と線を辿って回答を組み立てるため、根拠が追える回答になりやすくなります。

ハルシネーションを「AIモデルの性能問題」として捉える見方もありますが、AIに渡すデータ側の意味と関係を整えることで大きく改善する余地がある、というのが最近の重要な視点かと思います。

AIの性能を上げるのと同じくらい、AIに渡すデータの側を整えるという発想が、ハルシネーション対策としても重要になってくる、と理解しておくとよいかと思います。

まとめ

本記事では、ナレッジグラフをグラフの定義から順に整理してきました。

• ナレッジグラフとは、ヒト・モノ・概念を「点」、それらの関係を「線」でつなぎ、関係性をグラフ構造で表現する技術です。

• AI活用の文脈では、生成AIの登場によって「複数の情報を関係で辿って答える」ことへの要求が急速に上がり、その基盤としてナレッジグラフが改めて重要視されています。

• ナレッジグラフが必要になる場面は、「AIの回答に『なぜ』がほしいとき」「顧客・業務の全体像を横断的に把握したいとき」「AIの誤回答を避けたいとき」の3つが挙げられます。

ナレッジグラフは、企業のAI活用において重要な要素になります。
目指すべき企業のAI活用の姿と、そこに到達するために必要な要素を理解することがAI活用の成否に深く関係していると考えます。

本記事が、AI活用に必要な要素を理解する一歩目になると幸いです。