オントロジー？ナレッジグラフ？AI時代のデータ基盤用語をざっくり理解する

はじめに

AI-readyなデータ基盤という文脈で、オントロジー、ナレッジグラフといった言葉を聞くことが増えてきました。
どれも何となく聞いたことはあるけれど、正直よくわからない。

この記事では、

• グラフ
• オントロジー
• ナレッジグラフ
• セマンティックレイヤー
• データカタログ

の位置づけを整理してみます。
ちょっと長いですが、なるべくさらさら読めるように整理をしています。
隙間時間に、気軽に読んでもらえたら嬉しいです。

この記事では、厳密な理論や仕様よりも、
データ基盤や生成AI活用の文脈でどう捉えると分かりやすいか
を重視して整理します。

ざっくりまとめ

先に全体像をまとめると以下のようなイメージです。

用語	ざっくり言うと	実体の例
グラフ	データ同士のつながりを表す形	ノード・エッジ、RDFトリプル、グラフDB、関係テーブル
オントロジー	業務の世界に出てくる言葉と関係のルール	OWL/RDF、用語集、概念モデル、メタデータ定義
ナレッジグラフ	意味づけされた知識のつながり	顧客・契約・商品・文書などをつないだグラフデータ
セマンティックレイヤー	利用者やAIが業務用語でデータを扱うための変換レイヤー	BIのセマンティックモデル、指標定義、SQLビュー、メトリクス定義
データカタログ	データを見つけて、意味や管理情報を確認するための台帳	データカタログサービス、DWHのカタログ機能、メタデータ管理機能

そもそもAI-readyなデータ基盤とは何か

AI-readyなデータ基盤という言葉は、
単に「AIに使うデータを大量にためておく場所」という意味ではありません。

もちろん、データをためることは大事ですが、それだけではAIにとって使いやすい状態とは言えません。

たとえば、社内に次のようなデータがあるとします。

• 顧客マスタ
• 契約情報
• 商品マスタ
• 請求データ
• 問い合わせ履歴
• 提案書PDF
• FAQ
• 営業メモ

これらがバラバラに存在しているだけだと、AIに聞いたときに困ります。

たとえば、

このお客様に関係する契約と、最近の問い合わせ内容を踏まえて、提案時に注意すべき点を教えて

と聞いたとしても、AI側から見ると、

• 「このお客様」とはどの顧客IDなのか
• 契約データと問い合わせ履歴はどう結びつくのか
• 商品名と社内コードは対応しているのか
• 同じ会社が別名で登録されていないか
• どの情報を信頼してよいのか

が分からないと、正しく答えられません。

つまり、AI-readyなデータ基盤では、
データそのものだけでなく、データの意味・関係・信頼性まで整理されていること が重要になります。

なぜ「グラフ」が出てくるのか

従来のデータ基盤では、データはテーブルで扱うことが多いです。

たとえば、顧客テーブル、契約テーブル、商品テーブルのように、行と列で整理します。

顧客テーブル
- 顧客ID
- 顧客名
- 業種

契約テーブル
- 契約ID
- 顧客ID
- 商品ID
- 契約開始日

商品テーブル
- 商品ID
- 商品名
- カテゴリ

これはとても分かりやすく、集計や検索にも向いています。

一方で、AI活用やナレッジ活用では、
「このデータとあのデータがどうつながっているか」
をたどりたい場面が増えます。

たとえば、

• 顧客Aは、商品Xを契約している
• 商品Xは、サービスカテゴリYに属している
• 顧客Aは、問い合わせZをしている
• 問い合わせZは、障害Kに関係している
• 障害Kは、商品Xの既知の問題である

のような関係です。

このような つながりそのもの を扱いやすくする考え方が、グラフです。

グラフとは何か

グラフは、「 点と線でデータの関係を表す考え方」 です。

• 点：ノード、頂点
• 線：エッジ、関係

たとえば、次のように考えます。

この例では、

• 顧客A
• 商品X
• 問い合わせZ
• 障害K

がノードです。

そして、

• 契約している
• 問い合わせた
• 関係する
• 影響する

がエッジです。

つまりグラフは、
「何があるか」だけでなく、「何と何がどうつながっているか」を表す ためのデータ表現です。

グラフは必ずしも最初から専用のグラフDBを使わないと考えられないものではありません。
実運用では、グラフDB、RDFストア、RDBのグラフ機能、DWH上のノード表・エッジ表など、いろいろな実装方法があります。

テーブルとグラフの違い

テーブルとグラフは、どちらが常に便利という話ではありません。 得意なことが違います。

観点	テーブル	グラフ
得意なこと	集計、一覧、条件検索	関係の探索、つながりの把握
見方	行と列で見る	点と線で見る
例	売上合計、顧客一覧	顧客と商品と問い合わせの関係
向いている質問	今月の売上はいくら？	この顧客に関係する問題は何？

たとえば、 「商品カテゴリ別の売上合計を出す」なら、テーブルの方が自然です。

一方で、 「この顧客に影響しそうな障害や関連ドキュメントをたどりたい」という場合は、グラフの考え方が効いてきます。

グラフがAI-readyでうれしい理由

AI-readyなデータ基盤でグラフが注目される理由は、 AIに渡したい文脈が、単一のテーブルだけでは表しにくい ことが多いからです。

たとえば生成AIに対して、単に文書を検索して渡すだけでは、次のようなことが起こります。

• 似た文章は取れるが、業務上の関係が分からない
• 顧客名や商品名の別名をうまく扱えない
• どの情報がどのマスタに紐づくか分からない
• 回答の根拠をたどりにくい

グラフを使うと、 AIが回答に使うべき関係性を明示しやすくなります。

たとえば、

顧客Aに関係する契約、契約している商品、商品に紐づく既知問題、関連するFAQをたどる

という処理がしやすくなります。

これは、RAGやAIエージェントの文脈でも重要です。
AIが「似ている文書」を探すだけでなく、 業務上つながっている情報をたどれる ようになるからです。

では、オントロジーとは何か

ここで次に出てくるのが、オントロジー です。

正直、言葉だけ見るとかなり難しそうです。
ただ、データ基盤の文脈では、まず次のように捉えると分かりやすいです。

オントロジーは、
ある業務領域で使う言葉・分類・関係・ルールを整理した設計図 です。

たとえば、営業や契約管理の世界なら、次のような言葉があります。

• 顧客
• 法人顧客
• 個人顧客
• 契約
• 商品
• 請求
• 問い合わせ
• 障害
• 担当者

これらは、ただ単語として存在しているだけではありません。

• 法人顧客は顧客の一種である
• 顧客は契約を持つ
• 契約は商品に紐づく
• 問い合わせは顧客から発生する
• 障害は商品に影響する
• 担当者は顧客を担当する

のような関係があります。

これを整理するのがオントロジーです。

オントロジーは「言葉の辞書」だけではない

オントロジーは、単なる用語集ではありません。

用語集は、たとえば次のようなものです。

用語	意味
顧客	商品やサービスを利用する個人または法人
契約	顧客と企業の間で成立した利用条件
商品	顧客に提供するサービスや製品

もちろん、これも大事です。

ただ、オントロジーではさらに、
用語同士の関係や制約 も表します。

たとえば、

• 顧客は契約を0件以上持つ
• 契約は必ず1つ以上の商品に紐づく
• 法人顧客は顧客の一種である
• 問い合わせは必ず発生元の顧客を持つ
• 障害は複数の商品に影響することがある

のようなルールです。

つまりオントロジーは、 業務の世界を、AIやシステムが扱えるように整理した“意味の設計図” と考えると分かりやすいです。

オントロジーの実体は何か

では、オントロジーは実際には何として存在するのでしょうか。

これはかなり重要で、オントロジーは必ずしも「専用の画面を持ったサービス」として存在するとは限りません。

実体としては、たとえば次のようなものです。

• OWL / RDF / Turtle などの機械可読なファイル
• グラフDBやRDFストアに登録されたスキーマ情報
• データカタログ上のビジネス用語集
• YAMLやJSONで管理された業務概念の定義
• ExcelやMarkdownで整理された軽量な概念モデル
• アプリケーションやAIエージェントが参照するメタデータ定義

厳密にやるなら、OWL や RDF のような標準形式を使って、クラス、プロパティ、関係、制約を定義します。

一方で、最初からそこまで厳密に作る必要があるとは限りません。たとえば、小さく始めるなら、次のような表でも十分に「軽量なオントロジー」として機能します。

概念	種類	説明	関係
顧客	クラス	商品やサービスを利用する個人または法人	契約を持つ
法人顧客	クラス	法人として登録された顧客	顧客の一種
契約	クラス	顧客と企業の間で成立した利用条件	商品に紐づく
商品	クラス	顧客に提供するサービスや製品	契約の対象になる
問い合わせ	クラス	顧客から発生した質問や依頼	顧客から発生する

より機械的に書くなら、たとえば次のようなイメージです。

Customer はクラスである
CorporateCustomer は Customer の一種である
Contract はクラスである
Customer は Contract を持つ
Contract は Product に紐づく

つまり、オントロジーの実体は、「 業務概念と関係を、システムやAIが参照できる形にしたメタデータ」 です。

ここで大事なのは、オントロジー自体は基本的に「顧客A」や「契約123」のような個別データそのものではない、という点です。

オントロジーが定義するのは、

• 顧客とは何か
• 契約とは何か
• 顧客と契約はどう関係するのか
• 契約中と解約済みはどう違うのか

といったルールです。

個別の顧客や契約を実際につないだものは、次に出てくるナレッジグラフに近くなります。

グラフとオントロジーの違い

ここが少し混乱しやすいところです。

グラフとオントロジーは似ていますが、役割が違います。

観点	グラフ	オントロジー
主な役割	データ同士のつながりを表す	そのつながりの意味やルールを定義する
例	顧客A → 契約している → 商品X	顧客とは何か、契約とは何か、契約できる対象は何か
近いイメージ	地図	地図の凡例・ルールブック
AIにとっての価値	関係をたどれる	関係の意味を理解しやすい

たとえば、グラフだけだと、

顧客A → 商品X

というつながりは分かります。

でも、それが

• 購入した
• 契約している
• 問い合わせた
• 解約した
• 興味がある

のどれなのか分からないと、意味が変わってしまいます。

そこで、オントロジーによって 「この線はどういう意味なのか」「このノードはどういう種類のものなのか」 を定義します。

ナレッジグラフとは何か

ここまでくると、ナレッジグラフも少し見えてきます。

ナレッジグラフは、 単にデータをつないだグラフではなく、オントロジーで定義した概念や関係に沿って、実データをつないだもの知識のネットワーク です。

たとえば、

このとき、

• 法人顧客Aは「顧客」の一種
• クラウドサービスXは「商品」の一種
• 障害Kは「既知問題」の一種
• FAQ記事は「ドキュメント」の一種

という意味づけがあると、AIは関係をたどりやすくなります。

つまりナレッジグラフは、「グラフ構造に、オントロジー的な意味づけを加えた知識ネットワーク」と見ると分かりやすいです。

ナレッジグラフとオントロジーの違い

オントロジーが、

顧客は契約を持つ
契約は商品に紐づく
法人顧客は顧客の一種である

という設計図だとすると、ナレッジグラフは、

顧客A は 法人顧客である
顧客A は 契約123 を持つ
契約123 は 商品X に紐づく
商品X は 障害K の影響を受けている
障害K は FAQ記事F で説明されている

のような、個別データ入りのネットワークです。

つまり、

• オントロジー：型やルールを定義する
• ナレッジグラフ：実際のデータをその型やルールに沿ってつなぐ

という関係です。

実装としては、ナレッジグラフは次のような場所に保存されることがあります。

• グラフDB
• RDFストア / トリプルストア
• RDB上のノード表・エッジ表
• DWH / レイクハウス上の関係テーブル
• 検索基盤やRAG基盤のメタデータストア

たとえば、ナレッジグラフでは「何が」「どんな関係で」「何につながっているか」を、次のような形で表します。

何が	どんな関係か	何につながっているか
顧客A	契約している	契約123
契約123	対象商品	商品X
商品X	関連障害	障害K
障害K	対応手順	FAQ記事F

このように、個別のデータを点として置くだけでなく、データ同士の「関係」も一緒に保存する のがナレッジグラフの特徴です。

そのため、AI活用の文脈では、このナレッジグラフを使うことで、AIが単に似ている文書を探すだけでなく、

顧客A → 契約123 → 商品X → 障害K → FAQ記事F

のように、関係をたどりながら必要な情報に近づけます。

セマンティックレイヤーとは何か

次にセマンティックレイヤーです。

セマンティックレイヤーは、 利用者やAIが、物理的なテーブル構造を意識せずに、業務用語でデータを扱えるようにするレイヤー です。

たとえば、データベースの中では次のようなテーブルやカラム名になっているかもしれません。

T_CUST
- CUST_ID
- CUST_NM
- STS_CD

T_ORD
- ORD_ID
- CUST_ID
- ORD_DT
- AMT

このままだと、利用者から見ると分かりにくいです。

そこでセマンティックレイヤーでは、たとえば次のように整理します。

業務用語	実体
顧客	T_CUST
顧客名	T_CUST.CUST_NM
注文	T_ORD
売上金額	T_ORD.AMT
有効顧客数	STS_CD = 'ACTIVE' の顧客数
月次売上	ORD_DT を月単位に集計した AMT

つまり、セマンティックレイヤーは、 物理データを業務用語に翻訳するレイヤー です。

セマンティックレイヤーの実体としては、 BIツールや分析基盤に設定する、業務用語と物理データの対応表
となります。
実装としては、次のような形で存在します。

• BIツールのセマンティックモデル
• ダッシュボード用のデータセット定義
• SQLビュー
• メトリクス定義
• dbtなどの変換・メトリクス定義
• 分析アプリやAIエージェントが参照するメタデータ設定

オントロジー が「業務概念そのものの関係」を整理するのに対して、 セマンティックレイヤー は「その概念を実際のデータからどう計算・取得するか」を整理します。

たとえば、

顧客とは何か
契約とは何か
法人顧客は顧客の一種である

を考えるのはオントロジー寄りです。

一方で、

有効顧客数はどのテーブルのどの条件で数えるのか
売上は税込か税抜か
月次売上は受注日ベースか請求日ベースか

を定義するのはセマンティックレイヤー寄りです。

オントロジーとセマンティックレイヤーの違い

ここも混乱しやすいところです。

どちらも「意味」を扱います。

ただし、見る角度が違います。

観点	オントロジー	セマンティックレイヤー
主な役割	業務概念と関係を定義する	業務用語と物理データを対応づける
関心	「顧客とは何か」「契約とは何か」	「顧客数はどのテーブルからどう計算するか」
近いイメージ	業務世界の概念モデル	データ利用の翻訳レイヤー
主な利用先	ナレッジグラフ、推論、文脈理解	BI、分析、NL2SQL、AIエージェント
例	法人顧客は顧客の一種	有効顧客数 = status='ACTIVE' の distinct customer_id

たとえば、オントロジーでは、

法人顧客は顧客の一種である
顧客は契約を持つ
契約は商品に紐づく

のように、業務概念の関係を定義します。

一方、セマンティックレイヤーでは、

有効顧客数 = CUSTOMER テーブルのうち STATUS = 'ACTIVE' の CUSTOMER_ID 数
月次売上 = ORDER テーブルの AMOUNT を ORDER_DATE の月単位で合計

のように、利用者が使う言葉と実際のデータ構造を結びつけます。

つまり、

• オントロジー：業務の意味を整理する
• セマンティックレイヤー：その意味を使ってデータを問い合わせやすくする

という関係です。

データカタログとは何が違うのか

ここで、データカタログとの違いを見ていきます。

データカタログは、
社内にどんなデータがあり、どこにあり、誰が管理していて、どういう意味なのかを探せるようにする仕組み
です。

たとえば、

• テーブル名
• カラム名
• 説明
• オーナー
• 更新頻度
• データ品質
• リネージュ
• 個人情報の有無
• アクセス権限

などを管理します。

一方、ナレッジグラフやオントロジーは、 データや業務概念同士の意味的な関係 をより明示的に表します。

観点	データカタログ	グラフ／オントロジー
主な目的	データを見つけて理解しやすくする	データ同士の意味的な関係を表す
管理するもの	テーブル、カラム、所有者、品質、リネージュなど	エンティティ、関係、分類、ルールなど
強み	データ探索、ガバナンス、管理	関係探索、推論、文脈理解
AI活用での役割	使えるデータを見つける	使うべきデータの関係をたどる

どちらか一方があればよいというより、 データカタログで探し、オントロジーで意味を整理し、セマンティックレイヤーで使いやすくする という関係になります。

データカタログは、比較的「サービス」としてイメージしやすいものです。
たとえば、クラウドベンダーが提供するデータカタログサービスを使う場合もありますし、DWH、レイクハウス、BIツール、データ基盤製品の中にカタログ機能として組み込まれている場合もあります。

実体ベースで一度整理する

ここまでを、実際に作るもの・管理するものという観点で整理すると次のようになります。

用語	実際に作る・管理するもの	例
データカタログ	データ資産のメタデータ	テーブル一覧、カラム説明、オーナー、タグ、リネージュ
オントロジー	業務概念と関係の定義	顧客、契約、商品、問い合わせ、障害の関係定義
ナレッジグラフ	実データ同士の意味付きネットワーク	顧客A → 契約123 → 商品X → 障害K → FAQ
セマンティックレイヤー	業務用語と物理データの対応	売上、契約中サービス、有効顧客数、解約率の計算定義
グラフ	つながりを表すデータ構造	ノード表・エッジ表、RDFトリプル、グラフDB

具体例：顧客対応AIで考える

たとえば、顧客対応AIを作るとします。

ユーザーが次のように質問します。

顧客Aから「最近サービスが遅い」と問い合わせが来ています。
契約内容と既知障害を踏まえて、回答案を作ってください。

このとき、AIが見るべき情報は1つではありません。

• 顧客Aの契約情報
• 利用中の商品
• 商品に紐づく障害情報
• 過去の問い合わせ
• 対応済みチケット
• FAQ
• SLA
• 担当営業

これらが全部バラバラだと、AIは「似ていそうな文書」を探すことはできても、
業務的に本当に関係する情報 を正しくたどるのは難しくなります。

そこでグラフを使うと、

のように、必要な情報のつながりを表せます。

さらにオントロジーがあれば、

• 顧客には法人顧客と個人顧客がある
• 契約中サービスだけを回答対象にする
• 障害は影響範囲を持つ
• SLA違反の可能性がある場合はエスカレーションする

といったルールも整理できます。

これにより、AIは単に文章を生成するだけでなく、
関係する情報をたどったうえで回答する
方向に近づきます。

全部そろえることがAI-readyではない

ここまで、グラフ、オントロジー、ナレッジグラフ、セマンティックレイヤー、データカタログについて整理してきました。

ただし、AI活用のためにこれらをすべて最初から用意しなければならない、というわけではありません。

むしろ、全部を一気にそろえようとすると、かなり大変です。
オントロジーを作るには業務概念の整理が必要ですし、ナレッジグラフを作るには実データ同士の関係を継続的に管理する必要があります。セマンティックレイヤーでは指標や集計ロジックをそろえる必要があり、データカタログも説明、オーナー、品質、権限などを運用し続ける必要があります。

つまり、これらは作るコストだけでなく、維持するコストもかかります。

そのため大事なのは、理想形を全部そろえることではなく、AIで実現したい用途に対して、どこまで意味づけや関係整理が必要かを見極めることです。

たとえば、社内文書を検索して回答するシンプルなRAGであれば、まずは文書の所在、権限、鮮度、信頼性を整理することが重要です。この場合は、データカタログやメタデータ管理の考え方が効いてきます。

一方で、自然言語で売上や顧客数を分析したい場合は、「売上とは何か」「有効顧客数はどう数えるのか」といった定義が必要になるため、セマンティックレイヤーが重要になります。

また、顧客対応AIのように、顧客、契約、商品、問い合わせ、障害、FAQを横断して回答したい場合は、業務上の関係をたどる必要があります。この場合は、ナレッジグラフやオントロジーの考え方が効いてきます。

つまり、用途によって必要なものは変わります。

AI-readyなデータ基盤づくりは、特定の技術要素を全部そろえるチェックリストではありません。
どの業務でAIを使いたいのか、そのためにどのデータの意味や関係を整理すべきなのかを考え、費用対効果に合わせて必要なものから整備していく取り組みです。

小さく始めるなら、まずは使いたいデータや文書を明確にし、その意味、品質、権限、鮮度を整理するところからで十分な場合もあります。そこから必要に応じて、セマンティックレイヤー、ナレッジグラフ、オントロジーへと広げていくのが現実的です。

重要なのは、「全部作るか、何も作らないか」ではなく、AI活用の目的に対してちょうどよい意味づけの深さを選ぶことです。

終わりに

今回は、AI-readyなデータ基盤の文脈で出てくる、グラフ、オントロジー、ナレッジグラフ、セマンティックレイヤー、データカタログの位置づけを整理しました。

特に分かりにくいオントロジーとナレッジグラフは、

• オントロジー：業務概念や関係のルールを定義する設計図
• ナレッジグラフ：その設計図に沿って、実データ同士を意味付きでつないだもの

と考えると整理しやすいです。

また、データカタログやセマンティックレイヤーも含めて見ると、それぞれの役割は次のように分けられます。

• データカタログは、データを探して理解するための台帳
• オントロジーは、業務の意味や関係を整理する設計図
• ナレッジグラフは、実データを意味付きでつないだネットワーク
• セマンティックレイヤーは、業務用語でデータを使うための翻訳レイヤー
• グラフは、つながりを表すデータ構造

AI活用では、単にデータをためるだけでなく、AIが 「このデータは何を意味していて、他のデータとどう関係しているのか」 をたどれる状態にすることが重要になります。

最初から大きな仕組みを作る必要はありませんが、まずは1つのユースケースに絞って、
業務用語、データの場所、データ同士の関係 を整理するところから始めると、AI-readyなデータ基盤のイメージがかなりつかみやすくなると思います。