gaipack本部 AIDD技術部 AIDD営業推進室 室長の西田です。最近、データや AI の文脈で「オントロジー」という言葉を目にする機会が急に増えました。Palantir の躍進とともに広まり、Databricks や Snowflake も相次いで「意味の層」を製品に組み込み始めた一方で、言葉だけが先行してバズワード化している感もあります。この記事では、オントロジーという言葉の起こりから、セマンティックレイヤーとの違い、Databricks での実装までを、ビジネス層にも伝わる形で整理します。

「オントロジー」という言葉が広まった3つの波

オントロジーは 2020 年代に生まれた言葉ではありません。哲学に始まり、AI 研究を経て、いまエンタープライズの現場に降りてきた言葉です。それぞれの時代で指すものが少しずつ違うため、この変遷を押さえておくと会話の混線を避けられます。

第1の波：哲学の「存在論」

オントロジー（Ontology）はもともと哲学用語で、日本語では「存在論」と訳されます。「この世界には何が存在するのか」「存在するものはどう分類できるのか」を問う学問領域で、源流はアリストテレスの形而上学までさかのぼります。ここで覚えておきたいのは「世界にあるものを分類し、体系立てて記述する」という発想そのものです。この発想が、のちにコンピュータサイエンスへ輸入されます。

第2の波：AI研究の「知識の設計図」

1990 年代、AI 研究者たちは「コンピュータに知識を扱わせるには、概念を機械可読な形で定義する必要がある」という課題に直面していました。スタンフォード大学の Tom Gruber は 1993 年の論文で、オントロジーを「概念化の明示的な仕様（explicit specification of a conceptualization）」と定義します。「顧客とは何か」「注文とは何か」「顧客と注文はどう関係するか」を、人間の暗黙知ではなく機械が読める仕様として書き下ろす、という考え方です。

この流れは 2000 年代のセマンティック Web 構想に受け継がれ、W3C が OWL（Web Ontology Language）という記述言語を標準化しました。2012 年には Google がナレッジグラフを発表し、「文字列ではなく、実体を（things, not strings）」というコピーとともに、概念と関係のネットワークで検索を賢くするアプローチを一般に知らしめました。

第3の波：エンタープライズの「業務のデジタルツイン」

言葉を現在の文脈で再定義したのが Palantir です。同社はデータ分析基盤 Foundry の中核に「Ontology」という名前のレイヤーを置き、公式ドキュメントで「組織のオペレーショナルレイヤー」「組織のデジタルツイン」と位置付けました。学術用語だったオントロジーを「業務をそのままソフトウェアの中に写し取る仕組み」として製品化したことで、この言葉はデータ業界の共通語になっていきます。

3つの波を整理すると次のとおりです。

なぜ今、オントロジーが再注目されるのか

再注目の理由は一言でいえば AI エージェントです。LLM を業務に入れた企業が最初にぶつかる壁が「意味の壁」であり、オントロジーはその処方箋として脚光を浴びています。

足りないのは知能ではなく企業文脈

LLM は一般知識について驚くほど賢い一方、あなたの会社の「売上」の定義は知りません。Databricks Data + AI Summit 2026 のレポート記事でも紹介したとおり、Databricks の CEO は基調講演で「AI に足りないのは知能ではなく、企業文脈（自社データ）である」と指摘しました。モデルの性能競争が一段落した今、差がつくのは「自社の業務の意味をどれだけ AI に渡せるか」に移っています。

意味のズレが生むハルシネーション

たとえば「今月の売上を教えて」と AI に聞いたとき、経理部門の「売上」（検収基準・税抜）と営業部門の「売上」（受注ベース・税込）のどちらで答えるべきかを、AI は自力では判断できません。定義が曖昧なまま答えさせると、もっともらしい間違った数字が返ってきます。これは AI の知能の問題ではなく、組織側が意味を揃えて渡していないことの問題です。人間同士なら会議で「その売上ってどっちの意味？」と確認できますが、AI エージェントが自律的に動く世界では、意味の定義を事前に機械可読な形で用意しておく必要があります。その置き場所がオントロジーです。

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

このテーマで必ず出てくるのが「セマンティックレイヤーと何が違うのか」という疑問です。両者は重なる部分も多いのですが、守備範囲が違います。

セマンティックレイヤーは BI の世界で長く使われてきた考え方です。1990 年代の BusinessObjects が「ユニバース」と呼ぶ意味定義層を持っていたのが原型で、その後 Looker の LookML や dbt Semantic Layer に受け継がれ、「売上」「解約率」といった指標の計算定義をツールの外側で一元管理するアプローチとして定着しました。会議のたびに部門間で数字が合わない、という古典的な課題への答えです。

一方オントロジーは、指標の手前にある 「概念そのもの」 を扱います。顧客とは何か、案件とは何か、顧客と案件はどうつながるか、案件に対して何ができるか。指標の計算式だけでなく、業務世界の登場人物・関係・操作まで含めて定義します。

対立する概念ではなく、包含関係に近いと捉えるのが実態に合っています。オントロジーが揃えようとする幅広い「意味」のうち、指標の計算定義という一部分を先に実用化してきたのがセマンティックレイヤーだ、と捉えると両者の関係がつかみやすいはずです。実際に後述する Databricks では、両者が地続きの機能群として提供されています。

Palantir Ontology：オントロジーを「動かせる」ものにした実装

現在のオントロジー・ブームの震源地である Palantir の実装は、言葉の意味を理解するうえで避けて通れません。Palantir Foundry の Ontology は、データセットやモデルといったデジタル資産を現実世界の対象物（工場・設備・製品から、注文・取引といった概念まで）に結びつける層で、大きく2種類の要素で構成されます。意味を記述する「セマンティック要素」と、業務を動かす「キネティック要素」です。

セマンティック要素：オブジェクト・プロパティ・リンク

Palantir のドキュメントでは、組織に存在する実体やイベントを「オブジェクトタイプ」、その属性を「プロパティ」、オブジェクト同士の関係を「リンクタイプ」として定義します。「顧客」「注文」「配送センター」といった業務の登場人物と、その関係のネットワークです。ここまでは第2の波の知識工学やナレッジグラフの延長線上にあります。

キネティック要素：アクションとファンクション

キネティック（kinetic）は「動きの・動的な」を意味する言葉で、Palantir の特徴は、意味の記述にとどまらず、この名のとおり「操作」まで定義する点です。オブジェクトをどう変更できるかを「アクションタイプ」、ビジネスロジックを「ファンクション」として定義します。「注文をキャンセルする」「在庫を引き当てる」といった業務操作そのものがオントロジーに含まれるため、AI エージェントや現場アプリケーションは、意味を理解したうえで実際に業務を動かせます。読むだけの辞書ではなく、書き戻せる業務モデルにしたこと。これが Palantir がオントロジーという言葉に加えた再定義であり、「業務のデジタルツイン」と呼ばれる理由です。

Databricksでの実装：Unity Catalogセマンティクスと Genie Ontology

では、汎用データ基盤側はオントロジーをどう実装しているのか。Databricks を例に見ていきます。Databricks は 2026 年の Data + AI Summit で、ガバナンス層である Unity Catalog に「意味」を管理する機能群 Unity Catalog semantics を打ち出しました。人が定義する層と機械が学ぶ層の 2 段構えになっているのが設計の特徴です。

人が定義する層：Metric Views・Domains・Glossary

Unity Catalog semantics は、ビジネス KPI を SQL オブジェクトとして定義・統制する Metric Views、データ資産を業務ドメイン単位で束ねる Domains、業務用語の正式な定義を管理する Glossary、資産に「認定済み」「廃止予定」の信頼シグナルを付ける Certification で構成されます。DAIS 2026 の発表時点のステータスは次のとおりです（2026 年 8 月時点）。

セマンティックレイヤーの機能（Metric Views）と、オントロジー的な機能（Domains・Glossary によるエンティティと用語の定義）が、同じカタログ上で地続きに提供されている点が、前の章で述べた「両者は包含関係」の実例になっています。

機械が学ぶ層：Genie Ontology

Databricks のドキュメントは、これら人手で定義した資産を「Genie Ontology の human-modeled layer（人がモデリングした層）」と呼びます。Genie Ontology は、利用ログやデータからも用語・定義を継続的に学習するエンタープライズ文脈層で、自然言語でデータ分析ができる Genie や各種エージェントの推論を支えます。

Palantir との対比で言えば、Palantir が専用プラットフォーム上に業務全体を人手でモデリングしていくアプローチなのに対し、Databricks は既存のデータカタログに人手の定義を足し、機械学習で補完していくアプローチです。導入済みのレイクハウスの延長線で始められる分、着手のハードルは下がっています。どちらの実装でも目指す先は同じで、人と AI が同じ意味を参照する Single Source of Truth を作ることにあります。

開発現場での応用：gaipackのドメインオントロジー試作

オントロジーはデータ基盤だけの話ではありません。私たちは AI 駆動開発（AIDD）の現場でも、プロジェクトのドメイン知識を小さなオントロジーとして管理する仕組みを社内で試作しています。Palantir の 4 プリミティブ（オブジェクト・リンク・アクション・ファンクション）を汎用化し、「何が存在するか」をエンティティ、「どう関係するか」を関係定義、「何ができるか」をアクション、「どう計算・検証するか」をビジネスロジックとして、それぞれ YAML ファイルに構造化する構成です。AI コーディングエージェントは、この YAML 群を Single Source of Truth として参照しながらコードを書きます。仕組みの全体像は、ディレクトリ構成や YAML のサンプルも含めて gaipack セマンティック APM プラグインの紹介記事で解説しています。

仕組みの面では、用語辞書が表記揺れ（同じ概念を「顧客」と「クライアント」で呼び分けてしまう類）を正の用語に解決するほか、セッション開始時に定義済み用語の一覧を AI に注入しておき、通常の会話中に未知の業務用語・表記揺れ・暗黙のビジネスルールが現れたら検出して保留リストに積む、という受動的な検出フローを組み込んでいます。積まれた用語はあとから人がまとめて定義を確定するため、オントロジーはプロジェクトの会話を重ねるほど育っていきます。定義の可視化ビューも用意しており、概念の関係図やどこにもつながっていない孤立ノードを確認できます。

品質を守るために置いているのが 3 つの原則です。定義には根拠ドキュメントの記載を必須にする（出典必須）、未知の用語を AI に推測させず人に確認する（推測禁止）、新しい定義の追加には人の承認を挟む（承認必須）。AI に定義を自動生成させ放題にすると、もっともらしい誤定義が正本に混ざるためです。仕組み自体はまだ試作段階で、社内プロジェクトで検証を重ねている最中です。

なぜ開発でここまで意味の整備にこだわるかというと、AI の出力品質はインプットの品質で決まるからです。gaipack の AIDD スキームでは、開発スピード 2 倍以上という効果を掲げていますが、これはインプット品質 80% 以上という条件付きの数字です。用語と概念の定義が揃ったインプットを渡せるかどうかが、この条件を満たす土台になります。AI に渡す文脈を設計する考え方の全体像はコンテキストエンジニアリングの記事で詳しく解説しています。

オントロジーに関するよくある質問

オントロジーについて、お客様との会話でよく出てくる質問をまとめました。

オントロジーとナレッジグラフの違いは何ですか？

ナレッジグラフは実体と関係を格納した 「データ」 で、オントロジーはそのデータが従うべき型・語彙・ルールを定めた 「スキーマ（設計図）」 です。「顧客 A 社は案件 X を発注した」という個々の事実の集まりがナレッジグラフ、「顧客というものが存在し、案件と発注という関係を持ちうる」という定義がオントロジーにあたります。両者はセットで使われることが多いです。

セマンティックレイヤーがあればオントロジーは不要ですか？

BI の数字を揃えることが目的なら、指標定義を管理するセマンティックレイヤーで足ります。ただし AI エージェントに業務を任せたい場合は、指標の手前にある概念・関係・操作の定義が必要になり、オントロジーの領域に踏み込むことになります。Databricks の Unity Catalog semantics のように両者が地続きで提供され始めているため、Metric Views のような指標定義から始めて段階的に広げるのが現実的です。

オントロジーの整備は何から始めればよいですか？

全社の業務を最初から網羅しようとすると、定義すべき用語と関係が膨大になり頓挫しやすくなります。まず AI に任せたいユースケースを 1 つ決め、そこで使う用語・KPI・エンティティだけを定義することから始めるのが定石です。「会議で数字が合わない KPI」や「部署によって意味が違う用語」は、意味のズレが既に顕在化している場所なので、着手点として優先度が高いです。

RAG で社内文書を検索できれば十分ではないですか？

RAG は文書の断片を検索して AI に渡す仕組みで、文書間で用語の定義が食い違っている場合、その食い違いごと AI に渡してしまいます。オントロジーは食い違いを解消した正の定義を渡す仕組みなので、役割が異なります。検索の再現率を上げる RAG と、意味の正確性を担保するオントロジーを組み合わせることで、回答品質を両面から支えられます。

まとめ

オントロジーという言葉の現在地を整理しました。

• オントロジーは哲学の「存在論」に始まり、AI 研究の「知識の設計図」を経て、Palantir が「業務のデジタルツイン」として再定義した言葉
• 再注目の背景は AI エージェント。足りないのは AI の知能ではなく、業務の意味を機械可読にした企業文脈
• セマンティックレイヤーは指標の計算定義を揃える層、オントロジーは概念・関係・操作まで揃える層で、両者は地続き
• Databricks は Unity Catalog semantics（人が定義）と Genie Ontology（機械が学習）の 2 段構えで実装
• 開発の現場でも、ドメイン用語の定義を揃えることが AI の出力品質に直結する

バズワードとして消費するにはもったいない、実務の効き目がはっきりした概念です。KDDIアイレットでは、Databricks をベースに用語・KPI・業務ルールを Unity Catalog 上のセマンティックレイヤーとして整備し、人と AI が同じ定義を参照できる BI 環境を構築する gaipack BI を提供しています。「AI に聞いても自社の数字を正しく答えてくれない」とお悩みの方は、お気軽にKDDIアイレットへお問い合わせください！