オントロジーとは｜AIにデータの意味を渡す取り決めと、類似概念との違い

AI活用のために社内のデータ基盤を調べ始めた方は、どの資料も最後は同じ結論に行き着くことに気づいたかと思います。
データが存在するだけでは足りず、AIがそのデータの意味と文脈を理解できる状態になっていなければ使えない、という結論です。

ここまでは納得できても、次の一歩で手が止まります。
では意味と文脈をどう理解させるのかを調べ始めると、ナレッジグラフ、データカタログ、セマンティックレイヤー、メタデータ管理、そしてオントロジーという言葉が一気に出てきます。

各用語の解説は単独では成立しているのに、読み比べると説明範囲が重なっていて、どれとどれが同じことを言っているのかが分かりません。
なかでも特に立ち位置がつかみにくいのがオントロジーです。

本記事では、オントロジーの定義から、AI活用の文脈で必要になった順序、実際にどんな技術要素で作られどんなファイルとして保管されているのかまでを整理し、そのうえで1件の受注データを題材に、混同されやすい3つの用語との関係を整理します。

オントロジーとは、データの意味と関係を先に決めておくもの

オントロジーとは｜語と語のつながり方まで決める、社内データの文法

オントロジーとは、ある業務領域に登場する概念と、その概念が持つ項目、そして概念どうしの関係を、機械が読める形で定めた取り決めです。

受注データで考えてみましょう。

まず、この業務に登場するものの型を考えます。
「受注」「顧客」「商談」

次に、それぞれが持つ項目を決めます。
受注なら、受注番号・受注日・金額
顧客なら、顧客番号・社名・担当者
商談なら、商談番号・商談日・商談参加者・議事録
などです。

最後に、型と型のつながり方を決めます。
「受注は1つの顧客に紐づく」「受注は1つの商談から生まれる」といった内容です。

この3つの情報があると、例えば「受注1001」というデータから、どの顧客のどの商談から生まれたものなのかを、人が説明しなくても辿れるようになります。

そして、ここで「型」と呼んだものを「クラス」、型が持つ「項目」を「属性」、型と型の「つながり」を「関係」と呼びます。
この3つを書き出したものがオントロジーです。

もう少しイメージをつかみやすくすると、オントロジーは、言葉の文法です。
「顧客」と「受注」という語を並べただけでは、文になりません。
どちらがどちらに紐づくのかが決まって、はじめて文になります。

「単語と単語がどう繋がれるか」を決めるのが文法で、オントロジーは、社内のデータについての文法にあたると言えます。

情報科学の用語としてのオントロジーは、1990年代前半に、システムのあいだで情報をやりとりできるようにするための標準づくりのなかで、技術用語として定義されました（出典: Ontology（Tom Gruber、Encyclopedia of Database Systems、2009年））。

オントロジーという言葉の由来｜哲学の存在論から、情報科学の技術用語へ

オントロジーという言葉は、もともと哲学の分野で、存在とは何かを扱う領域を指します（同資料）。

情報科学に持ち込まれたときに、指すものが変わりました。
哲学のオントロジーが世界のありようを問うものだったのに対して、情報科学のオントロジーは、ある領域についての知識を表現できるようにするために設計された作りものを指します（同資料）。

オントロジーという言葉は、もともと哲学の用語です。存在とは何かを扱う領域、いわゆる存在論を指します（同資料）。

情報科学では、同じ言葉が別のものを指します。
情報科学のオントロジーは、人が目的をもって作る成果物です。
その目的は、ある領域の知識を書き表せるようにすることです（同資料）。

業務データを扱う製品も、この言葉を使っています。
データ分析基盤のPalantir Foundryは、オントロジーを製品の中核概念に置いています。
現実世界のモノや出来事に対応する型をオブジェクトタイプ、その特性をプロパティ、型どうしの関係をリンクタイプと呼び、それぞれを「スキーマ定義」と呼ばれています（出典: コア概念｜Palantir）。

なぜAI活用の文脈でオントロジーが必要になったのか

もともとは、別々に作られたシステムのデータをつなぐための仕組みだった

オントロジーが解こうとしていた問題は、AIより前からありました。
別々に作られたデータベースを、あとからつなぐという問題です。

システムごとに、同じものを違う名前で持っています。
たとえば、営業支援システムでは取引先を「アカウント」、会計システムでは「取引先マスタ」、問い合わせ管理のシステムでは「顧客」と呼んでいる、という状態です。
人が見れば同じ会社を指していると分かりますが、システムのあいだでは同じものとして扱えません。

オントロジーは、それぞれのデータベースの外側に、共通の意味の取り決めを1つ置く方法として使われてきました。
個々のデータベースの設計から独立しているため、独立して作られたシステムのあいだでもデータを行き来させられる、という位置づけです。

人が意味を補っていたので、企業のデータ管理では前に出てこなかった

企業のデータ管理の議論で、オントロジーが中心に出てくることは長らくありませんでした。
意味を補う役を、人が担っていたためです。

先に挙げた3つの呼び名が同じ会社を指していることは、現場の担当者が知っています。
部門をまたいでデータを渡すときは、人が突き合わせて対応表を作り、その対応関係は個人の頭と表計算ソフトのファイルに残りました。

業務のなかで立ち上がる問いも、あらかじめ決めた切り口で数字を返す形が中心でした。
先月の受注金額を製品別に見るという問いであれば、その集計を1つ作っておけば足ります。
データの中心が行と列に収まる表形式のものだった経緯は、ナレッジグラフとは｜企業のAI活用で重要視される理由でも整理しています。

AIに渡す段になって、人が補っていた意味を機械が読める形で用意する必要が出た

AIに社内データを扱わせようとすると、人が補っていた部分が空白として残ります。
AIは担当者の頭のなかにある対応関係を知らないため、テーブル名と列名だけを手がかりに意味を推測します。

この差は、検証で数字として出ています。
損害保険業界のデータモデルをもとにしたSQLスキーマに対して、日常のレポートから指標・KPIまでを求める43問をGPT-4に投げた検証では、データベースに直接質問した場合の正答率は16.7%でした。

同じデータに対して、オントロジーとマッピング（どの列がどの概念にあたるかの対応づけ）によって定義したナレッジグラフ（情報を点と線でつないだデータ）を経由して質問すると、正答率は54.2%まで上がりました。
約3倍の差です（出典: arXiv:2311.07509（企業のSQLデータベースへの質問で、ナレッジグラフが正答率に与える影響を測った研究）、査読前のプレプリント、2023年11月）。

はっきりした差が出たのは、答えを出すのに5つ以上のテーブルをまたぐ質問でした。
同検証は、テーブル数が5つ以上あり、正規化されてデータが複数のデータとつながる関係を挟むスキーマを、複雑な区分として分けています。
この区分では、データベースに直接質問した場合、1問も正しく答えられていません。

テーブルをまたぐというのは、業務の言葉で言えば「この顧客の商談と受注と請求を横断して答える」という形の問いです。
部門やシステムをまたいで答えを出す問いから先に落ちていく、ということになります。

オントロジーの実体｜何で作り、どんなファイルとして保管されるのか

オントロジーの実体は、取り決めを書き出したテキストファイルです。
何をどう書くかは、W3Cの標準として決まっています。

事実を3つ組で書く｜主語・述語・目的語のトリプルとRDF

意味と関係を機械が読める形で書くときの基本形は、1つの事実を3つの要素に分けて書くことです。主語、述語、目的語の3つです。

「受注1001は顧客A社に紐づく」という事実であれば、主語が「受注1001」、述語が「紐づく」、目的語が「顧客A社」になります。
この3つ組をトリプルと呼び、トリプルを積み上げて情報を表す枠組みがRDF（Resource Description Framework）です。

1つのトリプルは、述語が示す関係が主語と目的語のあいだに成り立っていることを表します。（出典: RDF 1.1 Concepts and Abstract Data Model）。

型と制約を書く｜クラス・属性・関係とOWL

トリプルは個々の事実を書く形式で、そこに登場する型そのものを決めるのは別の言語です。

「受注という型があり、受注は受注番号と金額を持ち、受注は1つの顧客に紐づく」という取り決めを書くために使われるのが、OWL（Web Ontology Language）です。
OWLで書いたものは、主にRDFの文書として交換されます。

OWLでは、型と関係に加えて、その制約も書けます。
「受注が紐づく顧客は1つ」という制約を書いておけば、受注と顧客のつながりが1対1であることが、実データとは別に取り決めの側に残ります。

用語の親子と関連だけを軽く書く｜SKOS

型と制約まで厳密に決めるのは重い作業になります。
用語の親子関係と関連だけを整理するところから始めるための標準も用意されています。
SKOS（Simple Knowledge Organization System）です。

SKOSは、「この語はこの語の下位にあたる」「この語はこの語と関連する」といった関係を書くための、軽い言語として位置づけられています。
仕様自身が、形式的な知識表現の言語ではないと明記しており、既存の用語集や分類体系をそのまま機械が読める形に移すための、低コストな道筋として設計されています。

厳密なオントロジーにするには、あらためて作り直す必要があるとされています。（出典: SKOS Simple Knowledge Organization System Reference、2009年8月勧告）

保管されるのはテキストファイル｜.ttlと、問い合わせのSPARQL

書き上げた取り決めは、拡張子のついた1つのテキストファイルになります。

RDFで書いた内容を人が読み書きしやすい形にしたのがTurtleという記法で、仕様には、ファイルの拡張子を.ttlにすることが推奨されると書かれています。

書き終えたファイルは、トリプルを保管して問い合わせられるように設計されたデータベースに読み込ませます。
トリプルストアと呼ばれるもので、点と線の形でデータを保持するグラフデータベースの一種です。
そこに問い合わせるための言語が、同じくW3Cの標準として定められているSPARQLです（出典: SPARQL 1.1 Overview、2013年3月勧告）。

混同されやすい概念との違い

オントロジーが何を決め、どんなファイルとして残るのかが分かると、混同されやすい用語との境目も引けます。3つの用語は、それぞれ別の役を持っています。

オントロジーとナレッジグラフの違い｜取り決めか、その取り決めどおりにつながった実データか

ナレッジグラフとは、情報を点と線でつなぎ、関係をグラフ構造で表現したデータのことです。
例えば、人間関係で言う人が「点」で、関係値が「線」です。

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

オントロジーとの違いは、取り決めか実データかという点にあります。
オントロジーが「受注という型と顧客という型があり、受注は1つの顧客に紐づく」と決める側で、ナレッジグラフは「受注1001は顧客A社に紐づく」「受注1002は顧客B社に紐づく」という個別の事実が実際にたまった側です。
オントロジーが文法、ナレッジグラフはその文法どおりに書かれた文章の集まりにあたります。

オントロジーとデータカタログの違い｜つながり方の取り決めか、どこに何があるかの目録か

データカタログとは、社内に散らばっているデータについての説明情報を一箇所に集めて、どこに何のデータがあるかを検索・発見できるようにする仕組みです。

（参考: データカタログとは｜メタデータとの違いとAI活用への影響）

オントロジーとの違いは、答える問いが別であることです。
データカタログが答えるのは「受注のデータはどのシステムのどこにあり、誰が管理し、いつ更新されたか」で、オントロジーが答えるのは「受注とは何を指し、何とどうつながるか」です。

文法にたとえれば、データカタログは、書かれたものがどこにあるかの目録です。
どの場所に何があるかは分かりますが、中身の文法までは決めません。

オントロジーとセマンティックレイヤーの違い｜語と語のつながりか、数の計算のしかたか

セマンティックレイヤーとは、データベースに格納された物理的なデータと、それを使うBIツール（データを集計してグラフや表で見るためのツール）やAIとのあいだに位置し、ビジネス指標の計算のしかたを一か所で定義する層です。

（参考: セマンティックレイヤーとは｜AIエージェント活用に不可欠な「意味の定義」を理解する）

オントロジーとの違いは、対象が関係か計算かという点にあります。
オントロジーが「受注は1つの顧客に紐づく」という型と型のつながりを決めるのに対して、セマンティックレイヤーは「今期の受注金額とは、受注日が今期に入る受注の、値引き後の金額を合計した数字」という計算のしかたを定めます。
文法にたとえれば、数を表す1語の中身を決める取り決めにあたります。

なお、製品によっては、オントロジーにあたる機能をセマンティックレイヤーと呼んでいる場合があります。
用語を突き合わせるときは、その製品が何を指してその語を使っているかを確かめる必要があります。

受注データで、4つの用語の立ち位置を並べる

1対1の違いが分かっても、4つが同時に並んだときの位置関係は別の問題です。
ここからは1件の受注データを題材にして、4つの用語を同じ土俵に置きます。

オントロジー｜何を何と呼び、どうつながるかを決める

最初に決まっていなければならないのが、オントロジーです。

受注という型、顧客という型、商談という型を置きます。
受注が持つ項目は受注番号・受注日・受注金額、顧客が持つ項目は顧客名・業種、商談が持つ項目は商談名・確度と決めます。
そのうえで、受注は1つの顧客に紐づく、受注は1つの商談から生まれる、担当者は複数の商談を持つ、という型と型のつながりを決めます。

この時点で、実際の受注データは1件も入っていません。
入っているのは、型と項目と関係だけです。

ナレッジグラフ｜取り決めどおりに実際につながったもの

オントロジーが決まると、実際のデータをそのつながりに沿って置けます。

受注1001は顧客A社に紐づき、A社の業種は製造業、受注1001は商談3050から生まれ、商談3050の担当者は営業2課に所属しています。
こうして個別の事実が点と線でつながった状態が、ナレッジグラフです。
AIが「A社の今期の受注は、どの商談から生まれたものか」と問われたときに辿るのは、この線です。

データカタログ｜どこに何があるかの目録

受注データがどこにあるかを答えるのが、データカタログです。

受注のデータは営業支援システムに、請求のデータは会計システムに、商談の議事録は共有ドライブに置かれています。
それぞれの管理者は誰で、いつ更新されたか。この情報を1か所に集めて検索できるようにします。

オントロジーが決まっていなくても、データカタログは作れます。
どこに何があるかを並べるだけなら、意味と関係の取り決めは要りません。

一方で、データカタログに並んだ「顧客テーブル」と「取引先マスタ」が同じものを指しているかどうかは、データカタログの側では決まりません。

セマンティックレイヤー｜「今期の受注金額」をどう計算するかを決める

受注データから数字を出すときの計算のしかたを決めるのが、セマンティックレイヤーです。

今期の受注金額とは、受注日が今期に入る受注の、値引き後の金額を合計した数字だと決めます。
営業が使う受注ベースの数字と、経理が使う請求ベースの数字は別のものとして、それぞれ定義しておきます。

こちらもオントロジーとは別に決められる取り決めです。
一方で、「受注」が何を指すかが揃っていない状態で計算のしかただけを決めると、部門ごとに違うものを合計した数字が並びます。

4つの立ち位置

4つのうち、オントロジーだけが他の3つと立ち位置が違います。
受注が何を指し、何とどうつながるか。この取り決めが決まっていなければ、ナレッジグラフはつなぐ先を決められず、セマンティックレイヤーは何を合計するのかを決められず、データカタログに並んだ2つのテーブルが同じものかどうかも判断できません。

先に決まっていなければならないのは、書き上げたファイルではなく、そこに書かれる取り決めの中身です。
オントロジーは、他の3つが乗る前提として先に決まる、意味と関係の取り決めです。

AIがデータの意味と関係を理解しているかで、何が変わるか

理解していない場合｜列名から推測して答える

意味と関係の取り決めがない状態で社内データを渡すと、AIはテーブル名と列名から意味を推測します。

「今期のA社からの受注金額を教えて」と聞かれたとき、AIはまず受注らしいテーブルを探します。
受注テーブルと請求テーブルの両方が見つかり、どちらにも金額の列があります。
A社は、営業支援システムでは「アカウント」、会計システムでは「取引先マスタ」として登録されています。

AIは、どのテーブルとどの登録名を選ぶかを推測で決めます。
返ってくる数字はもっともらしい形をしていますが、営業が見ている数字と一致するかどうかは分かりません。テーブルをまたぐ問いでは、そもそも辿り着けません。

理解している場合｜取り決めを引いてから答える

取り決めがある状態では、AIは推測する前に取り決めを引きます。

受注とは何を指し、どのテーブルのどの列がそれにあたり、顧客とどう紐づき、今期の受注金額はどう計算するのか。
ここが決まっていれば、AIは辿るべき線と合計すべき列が決まった状態で答えを組み立てます。

先と同じ問いであれば、A社という1つの顧客に辿り着き、そこに紐づく受注をたどって、今期の範囲で値引き後の金額を合計する、という経路が決まります。
営業が見ている数字と一致し、「その受注はどの商談から生まれたのか」と続けて聞かれても、同じ線をもう1本たどるだけで答えられます。
先に挙げた検証で、データベースに直接質問した場合とオントロジーを介した場合とで正答率が約3倍開いたのは、この差です。

全てを一気に整備する必要はない｜業務スコープを絞って始める

全社のオントロジーを一気に設計する必要はありません。
全社の概念を一度に定義しきろうとすると、対象が部門の数だけ広がり、合意を取る相手も増えます。専任のデータアーキテクトを置いていない体制では、定義を決めきる前に手が止まります。

始めるときの範囲は、1つの業務に絞れます。
AIに答えさせたい問いが受注まわりに集まっているなら、決めるのは受注・顧客・商談・担当者の4つの型と、そのあいだのつながりだけです。

形式も、最初から厳密にする必要はありません。
先に触れたSKOSは、用語の親子関係と関連だけを軽く書くための標準で、既存の用語集や分類体系を移すための道筋として設計されています。
社内に用語集やコード表があるなら、そこが出発点になります。

最終的に何と定義するかの判断は、外部に委託できません。
「自社では受注を何と呼び、何と紐づけるか」は社内でしか決まらないためです。
一方で、決まった取り決めをファイルに落とし、データベースに読み込ませる実装は外部に任せられます。

まとめ

オントロジーとは、ある業務領域に登場する概念と、その概念が持つ項目、概念どうしの関係を、機械が読める形で定めた取り決めです。

データそのものでもデータの置き場でもなく、そのデータが何を指し何とどうつながるのかを決める側にあります。
社内のデータについての文法にあたるもの、と捉えていただくと位置がつかみやすくなります。

混同されやすい3つの用語は、この取り決めの上で動きます。
ナレッジグラフは取り決めどおりに実際につながった実データ、
データカタログはどこに何があるかの目録、
セマンティックレイヤーは数の計算のしかたを決める取り決めです。
オントロジーは、この3つが乗る前提として先に決まります。

そしてその実体は、取り決めを書き出したテキストファイルです。
全社分を一度に作る必要はなく、AIに答えさせたい問いが集まっている1つの業務に絞れば、決めるのは数個の型とそのつながりだけになります。
社内の用語集やコード表を出発点に、まず受注や顧客の定義を書き出してみるところから始めていただけると幸いです。