title: "「オントロジー」を原典4件で読み比べたら、実行を含むのは1件だけだった"
emoji: "📖"
type: "tech"
topics: ["ai", "llm", "オントロジー", "設計", "knowledgegraph"]
published: true
自分の作った収集ボットに統制語彙を入れるかどうか検討していたとき、「オントロジー」という言葉に何度もぶつかりました。ところが読む資料ごとに指しているものが違う気がして、そこが気持ち悪いまま先に進めなくなってしまいました。
定義を一度そろえてから決めようと思い、原典を4つ開きました。解説記事はいっさい経由しておらず、全部 2026-08-27 に自分で原文を確認したものです。
結論
- 読み比べた4件は、抽象度も、含んでいるものも違った。しかも4件目は「オントロジー」を名乗っていない（同じ文脈に並べられるだけの隣接概念）
- 決定的な分かれ目は「実行（アクション）を含むか」で、この4件では含むのは1件だけ
- ここを区別せずに「オントロジーを入れよう」と言うと、作るものが語彙定義から運用基盤まで振れる
前回、収集ボットで「分類の揺れは、下流がその値を使うときだけ問題になる」ことを実測しました。そのうえで下流を作ることにしたので、構造化の水準を選ぶ必要が出てきたわけです。ところが選択肢を調べ始めると、どこを見てもすぐこの言葉に当たってしまうので、選ぶ前にまず言葉のほうを整理しないといけませんでした。
以下、時系列順に4つ並べていきますが、どれが「正しいか」の判定はしません。どれも、その文脈の中では正しいので。では何が違うのか？ 読み比べると差は2つの軸に出ます。何を対象にしているか（概念と関係か、指標か）と、実行を含むかです。
1. Gruber (1993) — AI 研究における定義
情報科学で「オントロジー」の定義として最も引用されるのが、Thomas R. Gruber の 1993 年の論文です。
【一次情報】Gruber, "A Translation Approach to Portable Ontology Specifications", Knowledge Acquisition, 5(2), 1993, pp. 199-220（著者サイトの本文 / 2026-08-27 取得）
有名なのはこの一文です。
"An ontology is an explicit specification of a conceptualization."
（オントロジーとは、概念化の明示的な仕様である）— §1 Introduction
「概念化（conceptualization）」のほうは直前で定義されています。
"A body of formally represented knowledge is based on a conceptualization: the objects, concepts, and other entities that are presumed to exist in some area of interest and the relationships that hold them (Genesereth & Nilsson, 1987)."
（形式的に表現された知識の体系は概念化にもとづく。概念化とは、ある関心領域に存在すると想定されるオブジェクト・概念・その他の実体と、それらを結ぶ関係である）
同じ論文に、もう1つの定義があった
これは PDF を最初から最後まで読んで初めて気づいたことなのですが、Abstract には、もっと限定的な定義が書かれています。
"A specification of a representational vocabulary for a shared domain of discourse — definitions of classes, relations, functions, and other objects — is called an ontology."
（共有される議論領域のための表現語彙の仕様、つまりクラス・関係・関数・その他オブジェクトの定義を、オントロジーと呼ぶ）— Abstract
ただし、これは「後から誰かが定義を広げた」という話ではありません。原典自身が2つの顔を最初から持っていたわけです！ Introduction のほうは「概念化の明示的な仕様」で、広くて哲学に接続する定義。対する Abstract のほうは「表現語彙の仕様」という、狭くて実装に接続する定義になっています。
広く引用されるのは Introduction の短いほうです。「オントロジーとは何か」への答えが人によってブレる一因は、伝言ゲームというより、出発点の論文が最初から2つの抽象度を持っていたことにあると考えています（あくまで解釈であって、論文はこの2つを矛盾とは扱っていません）。
Abstract だけ読んで止めていたら、たぶん一生気づけなかったと思います。今回の発見は Abstract と Introduction の差そのものだったので。
含んでいるのは語彙、つまりクラス・関係・関数の定義と、解釈を制約する形式的な公理まで。逆に含んでいないのが実行で、オントロジーはあくまで知識の記述であって、何かを動かす仕組みではありません。
2. W3C OWL 2 (2012) — Web 標準における定義
Gruber の系譜を機械可読な標準に落としたのが、W3C の OWL（Web Ontology Language）です。
【一次情報】OWL 2 Web Ontology Language Document Overview (Second Edition)（2026-08-27 取得）
"Ontologies are formalized vocabularies of terms, often covering a specific domain and shared by a community of users."
（オントロジーとは、形式化された用語の語彙であり、多くの場合、特定のドメインを対象とし、利用者のコミュニティで共有される）
こちらは Gruber と同系統で、「語彙の仕様」という Abstract 側の定義を、そのまま Web 標準に落とし込んだものと読めます。OWL 2 が提供するのはクラス・プロパティ・個体・データ値を記述する構造で、これが RDF グラフとして保存・交換されます。
含んでいるのは機械可読な語彙と、そこに与えられた意味論です。「あるクラスが別のクラスに含まれる」といった論理的帰結を実際に導くのは reasoner などのツールで、OWL 2 自体は言語であり、その意味論を定めている側になります。いずれにせよ実行は含まれておらず、業務のアクションが起きることはありません。
OWL 2 には「プロファイル」、EL / QL / RL という軽量版があって、表現力と引き換えに推論の効率を得る設計になっています。ここは次回と第6回で扱います。
3. Palantir Foundry — 製品における定義
近年この言葉を大きく広めているのが、Palantir 社の製品ドキュメントです。
【一次情報】Palantir Foundry — Ontology overview（2026-08-27 取得）
"The Palantir Ontology is an operational layer for the organization."
（Palantir オントロジーは、組織のための運用レイヤーである）
Gruber も OWL も、オントロジーは「記述」でした。ところが Palantir の定義は operational、運用の・動かすためのもの、と言い切っています。構成要素を見ると違いがはっきりします。
"Defining the semantics of your organization happens by mapping existing datasources into objects, properties, and links in the Ontology."
（組織のセマンティクスの定義は、既存のデータソースをオントロジーのオブジェクト・プロパティ・リンクへ対応づけることで行う）
"The kinetics of the organization—enabling change while complying with organizational controls and governance—are defined in the Ontology using action types and functions."
（組織のキネティクス、すなわち統制とガバナンスに従いながら変化を起こすことは、アクションタイプと関数によってオントロジーの中で定義される）
semantic elements、object types と link types のほうは Gruber や OWL のクラス・関係に対応物があります。一方 kinetic elements、action types と functions に対応するものはありません。ここは注意が要る箇所で、Gruber の定義にも functions という語は出てきます。ただしそちらは表現語彙としての関数であって、Palantir がデータを書き換えるために実行する関数とはまったく別物なので、語が同じでも中身は重なりません。
Palantir の「オントロジー」は、語彙の記述に加えてデータを書き換えるアクションまで含んだ製品基盤です。ここでは「読み・書き両方の層」と整理していますが、この読み/書きという言い方は原典の分類にはありません。並べて比べるためにこちらで持ち込んだ枠組みだという点は、断っておきます。 そのうえで言えば、Gruber / OWL の意味でのオントロジーは読みの側にしか踏み込んでいません。
実務でなぜこの区別が効くか
「オントロジーを導入しよう」という会話で、話し手が Palantir 型をイメージしている場合、作ることになるのは語彙の定義ではありません。アプリケーション基盤のほうです。語彙の定義なら設定ファイルとレビュー体制で始められますが、アクションを含む運用レイヤーとなると、権限・ガバナンス・実行系まで抱え込むことになります。作るものの種類が変わってしまうので、見積もりは比較になりません（どれくらい変わるかは案件によるので、倍率までは言えません）。
4. dbt Semantic Layer — BI 文脈で隣に置かれるもの
最後の1つは、厳密には「オントロジー」を名乗っていないものの、同じ文脈で頻繁に並べられる「セマンティックレイヤー」です。代表として dbt の定義を引きます。
【一次情報】dbt Docs — dbt Semantic Layer（2026-08-27 取得）
"The dbt Semantic Layer, powered by MetricFlow, simplifies the process of defining and using critical business metrics, like
revenuein the modeling layer (your dbt project). By centralizing metric definitions, data teams can ensure consistent self-service access to these metrics in downstream data tools and applications."
（dbt Semantic Layer は、revenueのような重要なビジネスメトリクスの定義と利用を単純化する。メトリクス定義を一元化することで、下流のツール間で一貫したアクセスを保証する）
Gruber / OWL / Palantir が扱うのは「概念と関係」で、何が存在して、どう繋がっているかという話です。一方 dbt Semantic Layer が扱うのは「指標の計算定義」、revenue をどう計算するかです。
どちらも「言葉の意味を一元管理する」という動機は共通なので、同じ文脈に並ぶのはある意味自然かもしれません。ただ成果物は別物です。「オントロジーを入れたい」という要望に「では dbt で」と応じると、概念体系が欲しかったのに指標定義の仕組みが納品される、というすれ違いが起きかねません。
4つを1枚で
この図は範囲の違いだけを示しています。 4件のあいだに派生関係や発展の順序があるという意味ではありません
（「OWL 2 に実行を足すと Palantir になる」わけではなく、そもそも別の系統の成果物です）。
| # | 出典 | ひとことで言うと | 実行を含むか | 対象 |
|---|---|---|---|---|
| 1 | Gruber (1993) | 概念化の明示的な仕様 / 語彙の仕様 | 含まない | 概念と関係 |
| 2 | W3C OWL 2 | 機械可読な語彙の標準（推論の意味論を定める。推論自体は reasoner が行う） | 含まない | 概念と関係 |
| 3 | Palantir | 語彙 + アクションを含む運用基盤 | 含む | 概念と関係と操作 |
| 4 | dbt Semantic Layer | メトリクス定義の一元化 | 含まない | 指標（概念体系ではない） |
会話で「オントロジー」が出たら、この表のどれを指しているのかを最初に確認する。 それだけで、見積もりと期待値のすれ違いはかなり防げるのではないでしょうか。
自分のシステムに入れるかを検証するのは、1と2の系統、つまり語彙の記述だけにします。Palantir 型は個人の収集ボットに運用レイヤーが過大なので扱いませんし、dbt SL のほうも、課題が分類の語彙であって指標の計算定義ではないので外します。
ただ1・2の系統の中でも、どこまでやるかという問いはそのまま残ります。フラットな語彙で足りるのか、階層まで要るのか、それとも関係まで入れるべきなのか。それが次の話になります。
この整理をそのまま持ち帰れない条件
- 4つは代表例であって網羅ではありません。学術分野（生命科学の GO など）や他製品（Databricks 等）にも、それぞれの用法があります
- 「定義のブレの一因は原典が2つの抽象度を持つこと」は私の解釈で、引用の分布を測ったわけではありません
- Palantir の記述は公開ドキュメントの範囲です。製品の実体は使って確認していません
- dbt SL の代表性は1社分なので、セマンティックレイヤーの他社定義（Cube / AtScale など）は未確認です
- 翻訳は私によるものです。正確には原文を参照してください（すべて本文中にリンクがあります）
- この記事は実測を含みません。一次資料の突き合わせだけです
言葉の整理はここまでにして、次はこの「語彙の記述」を実装の選択肢に翻訳していきます。
制約なし → 例示 → enum → フラットな統制語彙 → 階層 → 関係つき、という6段階に並べて、それぞれの実装コストと保守責任を比べる予定です。前回見た「制約なし」と「enum」は、その段階1と段階3にあたります。