ECサイトで特定ブランドのトップスを見ているとき、同じブランドの服だけでなく「似たテイストの別ブランドの服」や「このトップスに合うボトムス」まで出てくることがある。商品同士に「テイストが近い」、「一緒に着られる」といった関係や属性をあらかじめ定義しておくと、こうした意味のつながりをたどれるようになるからだ。
オントロジーとは、ある領域に登場する用語に対して、その属性や関係、意味そのものを明示的に定義し、関係者全員が同じ意味で使えるようにそろえた共通の語彙体系を指す。単なる用語の一覧ではなく、概念どうしのつながりまで記述する点に特徴がある。
もともとは情報科学・知識工学で育った概念だが、生成AIや大規模言語モデル（LLM）の業務活用が広がるなかで、その価値が改めて注目を集めている。
語源・提唱者
オントロジーの語源は古代ギリシャ哲学にさかのぼるが、情報科学の用語としては、1993年にスタンフォード大学の研究者Tom Gruber氏が論文『A Translation Approach to Portable Ontology Specifications』のなかで定義し、現代的な意味を確立した。この論文を載せた学術誌『Knowledge Acquisition』はのちに『International Journal of Human-Computer Studies』へ統合され、本論文はその誌系で最も多く引用された論文として知られる。
Gruber氏はこれを「概念化の明示的な仕様である（An ontology is an explicit specification of a conceptualization）」と定義し、人工知能やソフトウェア同士が知識を共有するための工学的なツールとして位置づけた。
階層で分けるタクソノミー、関係でつなぐオントロジー
オントロジーはよくタクソノミーと比べられる。タクソノミーは「〜は〜である（is-a）」という親子関係で、概念を縦の階層に並べる分類法を指す。「鳥類のなかにスズメがいる」のような上下関係を整理するのが得意だ。
オントロジーはこの縦の階層に加えて、「部分と全体（has-a）」「使われ方（used-for）」「因果」「制約」といった多様な関係を、網の目のように定義する。たとえば「自転車」は「乗り物である（is-a）」と同時に「車輪を持つ（has-a）」「道路で使う（used-for）」という複数の関係を一度に背負う。タクソノミーが一本の樹だとすれば、オントロジーは概念どうしを縦横に結んだ地図だと捉えるとよい。
オントロジーが持つ要素の全体像
実務でオントロジーを構築する場面では、次の要素まで一体で書き残すのが一般的になっている。
- 概念（クラス）：「顧客」「注文」「リリース予定」のように、その世界に登場するモノやコトを表す
- 属性（プロパティ）：「顧客の業種」「予定の確度」など、各クラスが持つ性質を記述する
- 関係（リレーション）：「顧客は注文を行う」「予定は担当営業を持つ」のように、クラス同士のつながりを定義する
- 制約（コンストレイント）：「注文金額は0以上」「顧客には必ず1人の担当営業がつく」など、値の範囲や多重度（カーディナリティ）のルールを定める
- 権限・ガバナンス：「機密タグの付いたデータは特定の目的でのみ参照できる」のように、誰がどのクラスの何を参照・更新できるかを取り決める
- アクション・振る舞い：「出荷する」「契約を更新する」のような、副作用を伴う更新操作のルールを書き残す
- 履歴・監査：誰がいつ何をどう変えたかを追跡できるよう、変更の記録を残す
このうち、Gruber氏の古典的定義（1993年）が直接の対象としていたのは、前半の概念・属性・関係・制約の4要素である。後半の権限・ガバナンス、アクション、履歴まで一体で扱うのは、記事後半で触れるPalantirのような近年のAI運用基盤が広げた拡張版のオントロジーにあたる。
RAGやファインチューニングと分けて考える理由
ここまでは情報科学としてのオントロジーを見てきた。ここからは、生成AIの普及でオントロジーが改めて注目される理由を見ていく。まず、よく混同されるRAGやファインチューニングとの違いから整理する。
オントロジーは、RAGやファインチューニングとは扱う情報が異なる。RAGは事実情報（「主要顧客はA社・B社・C社」など）を外部から検索してLLMに渡す手法であり、ファインチューニングはその知識をモデルの重みに学習させる手法を指す。どちらも「中身（事実・知識）」を載せる。
一方オントロジーは、その手前で「自社が『顧客』と呼ぶのは契約済みか商談中か」という言葉の意味合いそのものを決める。
オントロジーをRAGやファインチューニングと分けて管理する理由は、定義を独立した層に置くことでAIに「守らせる前提」へ格上げでき、回答や動作を間違えにくい構造を作れるからである。
「間違い」を制御するアーキテクチャで、複雑なビジネス環境にAIを適応させる
生成AIや大規模言語モデル（LLM）を業務に組み込む際、最大の難所はハルシネーション（根拠のない回答）への対処である。LLMは確率的に文章を生成するため、社内データの正確な参照と、安全な書き込み操作の両方を任せるには工夫が必要となる。
オントロジーをLLMの手前に挟むと、3つの効果が得られる。第一に、AIエージェントは「言葉の意味合いとその関係」を読み取れるため、社内データを正確に解釈できる。第二に、AIが実行できる操作（在庫を移す、注文を承認するなど）をオントロジー側でアクションとして定義することで、LLMが暴走しても定義済みの範囲を超えない。第三に、権限とガバナンスをオントロジー層で一元管理できるため、AIエージェントに渡してよいデータと渡してはいけないデータを切り分けられる。
つまり、オントロジーはAIエージェントが現実世界に干渉するための「安全で構造化された手足と目」を提供する。複雑なビジネス環境で自律的なAIを動かすうえで、オントロジーは事実上の必須条件として浮上している。
発注業務でたどる、オントロジー経由の動き
抽象的な説明だけではイメージしにくいため、部品の発注業務を例に、AIエージェントがオントロジーを通してどう動くかを順に追う。
- 購買担当者が発注アプリ（LLM）に「来週の生産に足りない部品を発注したい」と依頼する。
- LLMは実行する前にオントロジーを参照し、自社で「発注」や「在庫」が何を指すかを理解する。
- LLMはオントロジーを通して在庫データベースにつなぎ、いまの在庫状況を正確に把握する。
- LLMが購買担当者に「部品Aが安全在庫を下回る。500個の発注はどうか」と提案する。
- 購買担当者が内容を確認し、承認する。
- 承認を受けて、LLMはもう一度オントロジーに実行を指示する。
- オントロジーが発注機能に発注登録のアクションを渡し、発注機能が発注を登録する。
注目したいのは、読むとき（2・3）も実行するとき（6・7）も、AIが必ずオントロジーを通る点である。意味の理解・権限のチェック・実行のルールが同じ層に集まるため、LLMは決められた範囲の外へ出られない。しかも最終判断は人が握る（4・5）ので、全自動とは違い、誤発注や暴走を防ぎながらAIに業務を任せられる。
オントロジーをAIプラットフォームの中核に据えるPalantirモデル
オントロジーをAI基盤の中核に据えた代表例として、アメリカのパランティア・テクノロジーズの製品群（Foundry / AIP）が挙げられる。同社のPalantir Ontologyは、企業内に散在するERPやCRMのデータを「顧客」「注文」「設備」「車両」といったオブジェクトとして統一的に表現し、それぞれの関係や、データを更新するためのアクション（出荷する・在庫を移す・契約を更新するなど）まで一体で定義する。
データ・ロジック・アクション・セキュリティをオントロジーがどう一体に束ねるかは、Palantirの公式ドキュメントが構成図つきで公開している。
Palantir公式ドキュメント：The Ontology system
実際にPalantirを早期採用した米食肉大手タイソン・フーズは、構築したオントロジーを基盤に20のユースケースをLLMでサポートすることで、2年間で2億ドル規模のコスト削減につなげたと公表している。
このアプローチはしばしば「Palantirモデル」と呼ばれる。オントロジーをBIのような分析の補助線にとどめず、AIに「読ませて・書かせて・学習させる」土台として現実の業務運用に格上げした設計思想の代表例である。
オントロジーが効きやすい場面
オントロジーを導入する価値が高い場面には、いくつか共通点がある。
- 複数のシステムや部門が、同じ対象をそれぞれ違う名前で呼んでいる
- 用語の解釈が人によってずれ、議論や設計が空転している
- AIエージェントやRAGに、正確なドメイン知識を渡したい
- 業務オペレーションをアプリケーションコードから切り離し、AIや別チームが安全に呼び出せる形にしたい
逆に、扱う領域がごく小さく、関係者全員が口頭で意思疎通できる場合は、明示的なオントロジー構築のコストが見合わないことも多い。組織やプロダクトが拡大し、AIエージェントの導入を真剣に検討し始めたタイミングが、オントロジーの導入を考える目安となる。
