本記事は2026年9月時点の公開情報をもとに整理しています。記載内容は個人の見解です。

この記事では、AI Agentが企業データを単に「読める」だけでなく、企業固有の用語・関係・ルールを踏まえて業務を理解するための意味のレイヤーを、アーキテクチャ上の概念として Enterprise Ontology と呼びます。

Oracleの特定製品名ではありません。Oracle AI Data Platformでは Business Ontologies / Semantic Layer という表現が使われています。この記事では、それらを含む、企業全体の意味モデルという観点で整理します。

TL;DR

AIが企業データにアクセスできても、企業固有の「意味」まで理解できるわけではない
Enterprise Ontologyは、Vocabulary（用語）・Relationships（関係）・Rules / Metrics（ルール・指標） を明示し、人とAIが業務コンテキストを共有するための土台になる
形式的なOntology（RDF / OWL）を使うと、明示していない事実を推論で導ける。これはテーブルやProperty Graphにはない特徴である
Ontologyは一度作って終わりではない。ユースケース単位で始め、Business Ownerとともに育てる企業資産である

はじめに

このシリーズでは、第1回でAgentic Data Platformの全体像を、第2回でその土台となるData Platform for AIの7つの要件を整理しました。

今回は、第2回の要件④ Business Context / Semantics を掘り下げます。Data Platform for AIとAI Agentの間をつなぐ 「意味のレイヤー」 がテーマです。

今回も、シリーズの通し事例を使います。

「関西エリアの売上が前月より下がった理由を調べて」

1. 「データを読める」と「業務を理解できる」は違う

通し事例の依頼に正しく答えるには、AIは少なくとも次の点を理解している必要があります。

確認したいこと	あり得る解釈
「関西エリア」の範囲	2府4県 / 営業組織上の関西支社管轄
「売上」の種類	受注額 / 出荷額 / 会計上の売上高
税・キャンセル	税込か税抜か / キャンセルを含むか
「前月」の期間	暦月 / 会計期間
原因の判断基準	どのKPIやルールで「低下」と判断するか

人は業務経験や組織内の暗黙知でこれらを補いますが、AIには明示的に与えない限り伝わりません（数値の意味の違いについては、第1回で詳しく扱っています）。

つまり、Data Access ≠ Business Understanding です。データにアクセスできることと、業務を理解できることは別の問題です。

2. Enterprise Ontologyとは

この記事では、Enterprise Ontologyを次のように整理します。

企業内で使われる主要な概念・用語・関係・ルールを、部門やシステムをまたいで共有できる形で体系化した意味モデル。

Oracle AI Data Platformの公式ブログでは、ビジネス・セマンティクスを次の3つの層で説明しています。

要素	問い	例
Vocabulary （用語）	その言葉は何を意味するか	「Active Customer」は、直近30日ログインか、90日以内購入か、有効契約ありか
Relationships （関係）	概念同士はどうつながるか	Customer → Order → Product、Order → Revenue
Rules / Metrics （ルール・指標）	どう計算・判定するか	Revenueの計算方法、優良顧客の判定条件

特に重要なのはRules / Metricsです。たとえば「Revenue」には、会計上の売上高と管理会計上の売上高のように、正当な理由で複数の定義が存在することがあります。

問題になるのは、定義が複数あることそのものではありません。どの場面で、どの定義を使うのかが決まっていないことです。

3. 通し事例をOntologyで表現してみる

Vocabulary

概念	定義例
Revenue	出荷基準で計上された税抜売上高（キャンセル除く）
Kansai Region	大阪・京都・兵庫・奈良・滋賀・和歌山を含む営業地域
Active Customer	有効契約があり、直近90日以内に取引がある顧客
Sales Decline	前月比でRevenueが5%以上低下した状態

Relationships

Rules / Metrics

Revenue  = 出荷基準の税抜金額 − キャンセル済み取引
前月比   = (当月Revenue − 前月Revenue) ÷ 前月Revenue
低下判定 = 前月比 ≦ −5%

これらの定義が共有されていれば、AI Agentは「売上」や「関西」を毎回推測する必要がありません。さらに、同じ定義をBI・Analytics・AI Agent・Workflowで再利用できるため、ツールによって答えが変わることも防げます。

4. なぜAI AgentにOntologyが必要なのか

Ontologyがなくても、LLMは質問に回答できます。しかし企業で利用すると、次のような問題が起きやすくなります。

問題	具体例
指標の意味を推測する	「利益率は？」と聞かれて、Gross Margin・Operating Margin・Contribution Marginのどれかを、もっともらしく選んでしまう
Agentごとに回答が変わる	営業Agentと経営分析Agentが別の「売上」定義を使い、同じ質問に異なる数字を返す
システム横断の推論ができない	顧客 → 契約 → 受注 → 請求 → 問い合わせのつながりが分からず、原因分析が単一システムの中で止まる
回答を説明できない	Lineageで「どこから来たデータか」は追えても、「業務上どういう定義か」までは分からない

最後の点は重要です。AIの回答を説明可能にするには、データの由来（Lineage）と意味（Ontology）の両方が必要です。

5. AI AgentはOntologyをどう使うのか

Ontologyは検索対象そのものというより、ユーザーの依頼を企業の業務コンテキストに変換するための共通言語として働きます。

OntologyがAgentそのものになるわけではありません。Agentが企業の言葉を正しく解釈するためのContext Layerとして機能します。

6. 形式的なOntologyで何ができるのか：推論の例

第1回で触れたように、テーブル・列コメントやビュー、SQL Property Graphでも「意味・関係・ルール」の一部は表現できます。一方、RDF / RDFS / OWLといった形式的なOntologyには、それらにはない特徴があります。それが 推論（Inference） です。

通し事例を、W3C標準のRDF（Turtle形式）で表現してみます。

以下は、RDF / OWLの考え方を説明するための概念的なサンプルです。私の環境での動作検証は行っていません。

kansai_ontology.ttl

@prefix :     <http://example.com/ont#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl:  <http://www.w3.org/2002/07/owl#> .

# 概念（クラス）と階層
:Customer        a owl:Class .
:PremiumCustomer a owl:Class ; rdfs:subClassOf :Customer .

# 関係：「所在」は推移的（A⊂B、B⊂C なら A⊂C）
:locatedIn a owl:TransitiveProperty .

# 事実
:OsakaBranch :locatedIn :Osaka .
:Osaka       :locatedIn :Kansai .
:CustomerA   a :PremiumCustomer ;
             :servedBy :OsakaBranch .

このデータには、「大阪支店は関西にある」「顧客AはCustomerである」とは直接書かれていません。しかし推論を行うと、次の事実が導かれます。

推論された事実	根拠
大阪支店は関西にある	`locatedIn` が推移的な関係であるため
顧客AはCustomerである	PremiumCustomerがCustomerのサブクラスであるため

その結果、「関西の顧客」を問い合わせると、顧客Aが正しく含まれます。

SELECT ?c WHERE {
  ?c a :Customer ;
     :servedBy ?branch .
  ?branch :locatedIn :Kansai .
}

組織変更で支店と地域の関係が変わっても、Ontology側の事実を1か所直すだけで、それに依存する問い合わせ全体に反映されます。「意味」をデータやSQLに埋め込まず、独立したレイヤーとして管理することの価値がここにあります。

Property Graphとの使い分け

観点	SQL Property Graph	RDF / RDFS / OWL
主な用途	実データの関係の探索・分析	概念・関係・意味の形式的な定義
得意なこと	経路探索、つながりの分析	概念階層、推論、意味に基づく問い合わせ
推論	なし	あり（サブクラス、推移関係など）

両者は競合するものではなく、目的によって使い分ける技術です。

7. Oracle / OCIで考えるEnterprise Ontology

上図は製品構成図ではありません。この記事のEnterprise Ontologyという概念に、Oracle / OCIの関連機能を対応付けたイメージです。

領域	Oracle / OCIの関連機能
企業全体の意味管理	Oracle AI Data PlatformのBusiness Ontologies / Semantic Layer
形式的なOntologyと推論	Oracle AI Database 26aiのRDF Graph（RDF / RDFS / OWL）
実データの関係探索	SQL Property Graph
用語集・分類	AI Data Platformの統合カタログ、OCI Data Catalogのビジネス用語集
定義の収集・初期整備	Schema Discovery Agent（パターンとして公開）

Oracle AI Data Platform

製品ページでは、Business Ontologies / Semantic Layerとして、ドメインOntologyやビジネス概念間のセマンティックな関係を定義できると説明されています。

ビジネス用語集、セマンティックOntology、ドメイン分類、AIが生成する同義語によって、テーブル名ではなく意味でデータを探せるようにする方向性です。AI Agentがこのセマンティックな理解を自動的に引き継ぐ点も示されています。

Oracle AI Database 26ai：RDF Graph

RDF Graph機能では、RDF・RDFS・OWLに基づくデータとOntologyの格納・推論・問合せを利用できます。なお、ドキュメント上ではOWLのサブセットに対応すると説明されています。6章のような推論は、組み込みのOWLルールベースを使って実行する形になります。

Schema Discovery Agent

2026年7月のOCIブログでは、既存DBのメタデータから、業務ドメイン、オブジェクトの説明、列レベルの意味、関係グラフを生成し、ガバナンスされたセマンティック・レイヤーに変換するSchema Discovery Agentのパターンが紹介されています。

生成された用語集の候補や機密データの分類は、AI Data Platformのカタログやガバナンスの基盤として利用できるとされています。10章の「現在の定義を集める」ステップを効率化する手段として注目しています。

8. 関連する用語との違い（詳細は次回）

Enterprise Ontologyを調べると、Data Catalog、Semantic Layer、Knowledge Graphといった言葉も登場します。関連はありますが、同じものではありません。

要素	ひと言でいうと
Data Catalog	どんなデータがあるかを見つける
Semantic Layer	指標の計算ルールを共通化する
Enterprise Ontology	概念・関係・ルールを体系化する
Knowledge Graph	実データのEntityと関係をつなぐ

それぞれの境界と使い分けは、次回（第4回）で詳しく整理します。

9. Ontologyは「作って終わり」ではない

新商品の追加、組織変更、KPIの定義変更、法規制への対応、M&Aなど、企業の業務は常に変化します。Ontologyも継続的な更新が必要です。

Enterprise Ontologyは、IT部門だけのデータモデルではありません。業務部門・データチーム・IT・ガバナンス担当が共同で育てる企業資産です。

10. 現実的な進め方

いきなり全社のOntologyを作ろうとすると、規模が大きくなりすぎます。ユースケースから始める方が現実的です。

Step	やること	通し事例での例
1	対象業務を1つ決める	関西エリアの売上低下要因の分析
2	重要な用語を洗い出す	Revenue、Customer、Region、Campaign
3	現在の定義を集める	BIレポート、SQL、Excel、列コメント、ヒアリング
4	関係を整理する	Customer → Order → Product、Customer → Region
5	ルール・指標を明文化する	Revenueの定義、低下判定の閾値
6	Ownerを決める	Revenueの定義は経理部門が決める
7	AI・Analyticsで共通利用する	BI、NL2SQL、RAG、AI Agent、Workflow

Step 3では、同じ用語に部門ごとに異なる定義が見つかることがよくあります。これは失敗ではなく、Ontologyづくりの本来の成果です。

11. 私が考える、つまずきやすいポイント

最初から全社Ontologyを作ろうとする：完成する前に業務が変わります。重要なユースケースとData Productから始め、段階的に広げる方が進めやすいと私は考えています。
ER図と同じだと考える：ER図は物理的なテーブル構造を表しますが、Ontologyは企業の概念・意味・ルールを扱います。既存のER図をそのまま移しても、Ontologyにはなりません。
Graphを作ればOntologyになると考える：Graphは関係を表す強力な方法ですが、作っただけで業務上の意味や制約が定義されるわけではありません。
定義を1つに統一しすぎる：会計向けと経営管理向けのように、正当な複数の定義は存在します。無理に統一するより、どのコンテキストでどの定義を使うかを決める方が現実的です。
Ownerがいない：Ownerがいなければ業務変更に追従できず、AIは古い定義を使い続けます。技術面のOwnerだけでなく、Business Ownerを決めることが最も重要だと私は考えています。

12. チェックリスト：AIに企業の「意味」を渡せているか

Vocabulary

主要な業務用語が定義されている
同義語・略語が整理されている
部門によって異なる用語を把握している

Relationships

Customer、Order、Productなど主要概念の関係を説明できる
複数システムをまたいだ関係を把握している
階層構造（地域、組織、商品分類など）が明確になっている

Rules / Metrics

KPIの計算方法が明文化されている
業務ルール・判定条件が明確になっている
複数の定義がある場合、使い分けるコンテキストが明確になっている

Governance

各定義のBusiness Ownerが決まっている
定義変更の承認プロセスと変更履歴がある
AI Agentが利用する意味情報を管理できる

すべてを最初から形式的なOntologyにする必要はありません。重要なのは、企業の暗黙知を、人とAIが共通して使える明示的なビジネス・コンテキストに変えていくことです。

まとめ

AIがデータにアクセスできても、企業固有の意味まで理解できるわけではない
Enterprise Ontologyは、Vocabulary・Relationships・Rules / Metrics を体系化し、AI AgentのContext Layerとして機能する
RDF / OWLによる形式的なOntologyでは推論が可能になり、意味をデータやSQLから独立して管理できる
Oracleでは、AI Data PlatformのBusiness Ontologies / Semantic Layer、Oracle AI Database 26aiのRDF Graph、Schema Discovery Agentのパターンなどが関連する
Ontologyは、ユースケース単位で始め、Business Ownerとともに育てる企業資産である

次回は、今回簡単に触れた Data Catalog・Semantic Layer・Ontology・Knowledge Graphの違い を詳しく整理する予定です。

参考情報

シリーズ（にしたい。。。）

第1回：【Agentic Data Platform】AI Agentが業務で動くためのデータ基盤をレイヤー構造で整理する
第2回：【Data Platform for AI】AIが使える企業データ基盤に必要な7つの要件を整理する
第3回：【Enterprise Ontology】AI Agentに企業・業務を理解させる「意味のレイヤー」とは ← この記事
第4回：【Enterprise Ontology】Data Catalog・Semantic Layer・Ontology・Knowledge Graphの違いを整理する（予定）
第5回：【Agentic Data Platform】Data・Ontology・AI Agentをつなぐリファレンスアーキテクチャ（予定）