オントロジーとは

情報科学での標準的な定義は、1993年にトム・グルーバーが示した「概念化の明示的な仕様（an explicit specification of a conceptualization）」である。1998年にルディ・シュトゥーダーらがこれを拡張し、「共有された概念化の、形式的で明示的な仕様（a formal, explicit specification of a shared conceptualization）」とした。現在広く引用されるのは後者で、四つの語がそれぞれ要件を表している。

• 形式的（formal）：人間の読解に頼らず、機械が処理できる
• 明示的（explicit）：暗黙の了解に委ねず、すべて書き出す
• 仕様（specification）：解釈の余地を残さない定めである
• 共有された（shared）：一者の便宜ではなく、複数の主体の合意に基づく

この四つ目が実務上もっとも重い。自社の中だけで通じる定義はオントロジーとは呼ばない。

もとは哲学の用語で、日本語では「存在論」と訳される。語そのものは17世紀初頭に作られたラテン語の造語（ontologia）で、1606年のロルハルトの著作が最初期の用例とされる。問いはそれより古く、アリストテレス以来、「存在するとは何か」「世界はどのような種類のものから成るか」を扱う形而上学の一部門を指してきた。

1980年代から人工知能の研究者がこの語を借り、1990年代に上の定義が定着した。計算機に世界を扱わせるには、その世界にどんな種類のものがあり、それらがどう関係するのかを、あらかじめ書き下しておく必要があったからである。哲学が思索として問うたことを、情報科学は設計として実装した。

オントロジーは、しばしば用語集や分類体系と混同される。実際には表現力に段階があり、下の段から順に積み上がる。

1. 1用語集（glossary）：語とその説明の一覧。関係は表現しない
2. 2分類体系（タクソノミー）：上位・下位の階層関係を持つ。商品分類や生物の分類がこれにあたる
3. 3シソーラス：階層に加え、同義・関連といった関係を持つ
4. 4オントロジー：クラス、属性、関係、制約を形式的に定める。「Aは必ずBを一つ持つ」「AとCは同時に成立しない」といった規則を書けるため、機械が推論できる
5. 5ナレッジグラフ：オントロジーをスキーマとして、実際のデータ（個々の事例）を載せたもの

分類体系は「何がどこに属するか」を示す。オントロジーは加えて「何が何をどうするか」「何が禁じられているか」を示す。この差が、機械に判断を委ねられるかどうかを分ける。

実務でもう一つ混同されやすいのが、データモデルとの違いである。データモデルはデータの入れ物の設計図で、テーブルや項目をどう持つかを決め、実際のデータと直接つながる。オントロジーは言葉の意味の辞書と関係図で、項目名が何を指し、他の項目とどう関係するかを決める。前者は格納と処理に強く、後者は意味の統一に強い。実務では、データモデルを骨格にして、意味の食い違いが問題になる箇所からオントロジーで定義を深めていくのが現実的である。どちらにも共通する基本要素は、何のデータか、他と何の関係にあるか、何で識別するか、どの粒度か、いつの時点か、どういう意味か、の六つである。

記述の標準はW3C（World Wide Web Consortium）が定めている。RDFがデータの表現形式、RDFSとOWLがオントロジーの記述言語、SKOSが分類体系・シソーラス向けの簡易な語彙、SPARQLが問い合わせ言語にあたる。

実際に運用されている代表例として、生物学のGene Ontology（1998年発足。遺伝子産物の機能を国際的に統一した語彙で記述する）、金融のFIBO（Financial Industry Business Ontology）、ウェブ全般のschema.org（2011年にGoogle、Microsoft、Yahoo!が共同で開始し、ページの意味を検索エンジンに伝える）がある。

産業のデータ連携では、国際データスペース協会（IDSA）の情報モデルや、欧州の自動車業界が構築したCatena-Xのセマンティックモデルが、参加企業間の共通言語として機能している。

理由は二つある。

第一に、企業や業界を越えたデータ連携が現実の課題になったこと。日本の「ウラノス・エコシステム」や欧州のCatena-Xのように、複数の企業が同じ基盤にデータを持ち寄る仕組みでは、「同じ言葉が同じ意味で使われている」ことの保証が不可欠になる。回線がつながっても、語の意味が揃っていなければデータは突き合わせられない。この保証を与えるのがオントロジーである。技術的な相互接続（インターオペラビリティ）に対して、意味の相互運用性（セマンティック・インターオペラビリティ）と呼ばれる。

第二に、生成AIの普及。大規模言語モデルは統計的な連想には強いが、「この文書のAとあの文書のAが同じものを指すのか」を厳密に保証しない。社内文書を検索して回答させる仕組み（RAG）や、業務を自動で進めるエージェントでは、この曖昧さが誤りに直結する。明示的に定義された概念体系を土台に置くことで、統計的な推論の足元を固める使い方が広がっている。

企業が保有するデータを外部に提供しようとするとき、最初に立ちはだかるのは技術の壁ではない。定義の壁である。

社内で長く使われてきたデータは、部署ごとに項目名の意味が違い、粒度が揃わず、コード体系が独自のものであることが多い。社内では暗黙の了解で運用できていても、外部の相手に渡した瞬間、その了解は失われる。「そのまま渡せるデータ」がほとんど存在しないのはこのためである。業界の標準や共通基盤が上から用意されても、受け皿となる自社のデータ定義が揃っていなければ、標準に接続することすらできない。

データマネタイゼーション、すなわちデータに値段がつき取引が成立するかどうかは、この整理が済んでいるかどうかで決まる。何が、どの粒度で、どの定義に基づいて記録されているのか。相手の側でどう解釈されるのか。当社がデータ資産アドバイザリーで最初に行うのは、この暗黙の了解を書き出す作業である。

オントロジーという語を掲げるかどうかにかかわらず、データの取引はすべて、意味を揃える作業から始まる。