本記事は2026年9月時点の公開情報をもとに整理しています。記載内容は個人の見解です。
TL;DR
| 概念 | ひと言でいうと | AI Agentに提供するもの |
|---|---|---|
| Data Catalog | データの目録 | どのデータを使うか |
| Semantic Layer | 指標・業務用語・ 計算ロジックの共通化 |
どの定義で どう計算するか |
| Enterprise Ontology |
企業全体の 概念・関係・ルールの体系 |
どう解釈するか |
| Knowledge Graph |
EntityとRelationshipを 知識としてグラフで表現したもの |
何と何が つながっているか |
- 4つは重なる部分があるものの、中心となる役割は異なる
- 競合するものではなく、企業AIでは組み合わせて使うことが多い
- 自社に何が必要かは、「データが見つからない」「指標が揃っていない」「意味が伝わらない」「関係をたどれない」のどれが課題かで決まる
はじめに
このシリーズでは、第2回でData Platform for AIを、第3回でEnterprise Ontologyを整理しました。
第3回の中で、Data Catalog・Semantic Layer・Enterprise Ontology・Knowledge Graphの4つに簡単に触れました。いずれも「データに意味を持たせる」という文脈で登場するため、次のような疑問を持つ方も多いと思います。
- Data CatalogにBusiness Glossaryがあるなら、Ontologyは不要なのか？
- Semantic LayerとOntologyは何が違うのか？
- Ontologyを作れば、Knowledge Graphになるのか？
- 結局、AI Agentにはどれが必要なのか？
2026年8月のOracle AI Data Platformブログでも、呼び方（Semantic Layer、Ontology、Knowledge Graph）はさまざまでも、「生データへのアクセスだけでは足りない」という結論は共通していると述べられています。
この記事では、何を管理するのか、どの問題を解決するのか、AI Agentに何を提供するのかという3つの観点で、4つの違いを整理します。今回もシリーズの通し事例 「関西エリアの売上が前月より下がった理由を調べて」 を使います。
1. まず4つの違いを一言で整理する
| 概念 | 主に管理するもの | 主な問い |
|---|---|---|
| Data Catalog | データ資産とMetadata | どんなデータが、どこにあるか？ |
| Semantic Layer | 指標・業務用語・計算ルール | 「売上」はどう計算するか？ |
| Enterprise Ontology |
概念・関係・ルール | 顧客・注文・商品はどういう関係か？ |
| Knowledge Graph | EntityとRelationship | 顧客Aは何を買い、どこと関係しているか？ |
注意したいのは、役割が完全に分かれているわけではないことです。Data CatalogにBusiness Glossaryがあったり、Knowledge GraphがOntologyを内包したりすることもあります。製品の機能一覧で境界を引くより、中心となる役割は何かで考える方が分かりやすいと私は考えています。
2. Data Catalog：データを「見つけ、理解し、管理する」
Data Catalogの中心的な役割は、企業内のデータ資産を把握することです。データベース、Object Storage上のファイル、SaaSのデータなどに対して、Metadataを管理します。
| Metadata | 例（SALES_DATAの場合） |
|---|---|
| Owner | 営業データチーム |
| 更新日時 | 2026-09-28 08:00 |
| 説明 | 受注・売上分析向けデータ（正式データ） |
| Lineage | ERP_ORDERS → ETL → SALES_DATA |
| その他 | Schema / Column、データ分類、品質、アクセスポリシー |
これらが揃っていれば、似た名前の売上テーブルが複数あっても、人もAIも正しいデータを選べます。
Business GlossaryとOntologyの違い
多くのData CatalogはBusiness Glossaryを持っています。OCI Data CatalogのBusiness Glossaryも、組織で共通利用する業務用語を管理する仕組みです。カテゴリ・サブカテゴリ・用語の階層で構成され、用語を物理的なデータオブジェクトに紐付けられます。
Glossaryは「言葉と定義」の管理に非常に有効です。一方、Ontologyは概念間の関係・ルール・制約まで体系化します。GlossaryはOntologyの重要な入力になるものの、同じものではないと整理できます。
3. Semantic Layer：データを「共通のビジネスの言葉」で使う
Semantic Layerは、データベースの物理構造と利用者の間に、ビジネス上の意味を持つ共通レイヤーを置く考え方です。
利用者が知りたいのは SALES_AMOUNT や CANCEL_FLG といった列名ではなく、「売上高」「前月比」「顧客数」といった指標です。Semantic Layerでは、たとえばRevenueを次のような共通ルールとして定義します。
Revenue = SUM(SALES_AMOUNT) WHERE CANCEL_FLG = 'N'
営業部・財務部・経営企画がそれぞれ別のSQLやExcel式で「売上」を計算していると、AI Agentもどれを使えばよいか判断できません。Semantic Layerは、どのコンテキストで、どの指標定義を使うかを管理し、BI・NL2SQL・AI Agentが同じ意味を共有できるようにします。
Semantic Layerという言葉の範囲は、製品やベンダーによって異なります。この記事では、指標・業務用語・計算ルールを共通化し、物理的なデータ構造を意識せずに利用できるようにするレイヤーとして整理しています。
4. Enterprise Ontology：企業の「概念・関係・ルール」を体系化する
Enterprise Ontologyは、顧客・注文・商品・地域・売上といった企業の概念について、定義だけでなく、関係・概念階層・業務ルールまで体系化します（詳しくは第3回で扱っています）。
Semantic Layerとの違いは、「Revenue」を例にすると分かりやすくなります。
| 観点 | Semantic Layer | Enterprise Ontology |
|---|---|---|
| 主な関心 | Revenueをどう計算するか | Revenueは何という概念で、何とどう関係するか |
| 扱う内容 | 指標、計算式、集計ロジック | 概念、関係、階層、ルール、制約 |
| 例 | Revenue ＝ キャンセル除外後の税抜金額合計 | Order → generates → Revenue PremiumCustomer is-a Customer |
5. Knowledge Graph：「実際のEntity」を関係でつなぐ
Ontologyが定義するのは、主に「Customer → places → Order」のような概念レベルのモデルです。Knowledge Graphは、そのモデルに沿って具体的なEntityをつなぎます。
Ontologyが設計図だとすれば、Knowledge Graphは設計図に沿ってつながった具体的な知識です。
ただし、これは入門的な整理です。RDFベースのKnowledge Graphでは、Ontology（概念・関係の定義）とインスタンスデータ（具体的なEntity）を同じグラフの中で扱うことも一般的です。そのため、2つが必ず別のシステムである必要はありません。役割を区別したうえで、一体として使うケースもあります。
6. 通し事例を4つのレイヤーで見る
「関西エリアの売上が前月より下がった理由を調べて」という依頼を、AI Agentが処理する場面で考えます。
| レイヤー | Agentが得るもの | 通し事例での中身 |
|---|---|---|
| Data Catalog | 使うべきデータ | 正式な売上データはSALES_DATA。Ownerは営業データチームで、本日8時に更新済み |
| Semantic Layer | 計算ルール | Revenue＝キャンセル除外後の税抜金額合計、前月比の計算式 |
| Enterprise Ontology |
意味と関係 | 関西＝2府4県、Customer → Order → Product、Order → Revenue |
| Knowledge Graph | 具体的なつながり | 売上が減った顧客群 → 共通して購入を減らした商品X → 仕入先B |
Knowledge Graphを使うと、売上テーブルの集計だけでは見えない「仕入先の供給遅延」のような、複数ホップ先にある原因候補にたどり着ける可能性があります。
ただし、Knowledge Graphが見つけるのはあくまで「関係」であり、それだけで因果関係が証明されるわけではありません。原因を確定するには、時系列データや業務ルール、追加データによる検証が必要です。
7. 結局、どれを使えばよいのか
| やりたいこと | 中心になる技術 |
|---|---|
| どんなデータがあるか探したい | Data Catalog |
| Data OwnerやLineageを確認したい | Data Catalog |
| 「売上」「利益」などの指標を統一したい | Semantic Layer |
| NL2SQLで同じKPI定義を使いたい | Semantic Layer |
| 顧客・注文・商品などの業務概念を定義したい | Enterprise Ontology |
| AI Agentに業務ルールを理解させたい | Enterprise Ontology |
| 顧客Aと商品Xの具体的な関係を探索したい | Knowledge Graph |
| 複数ホップの関係を分析したい | Knowledge Graph |
実際には、1つだけを選ぶとは限りません。6章の通し事例のように、4つを組み合わせて使うことが多くなります。
8. よくある混同
Business GlossaryがあればOntologyは不要？
Glossaryが主に管理するのは、業務用語・定義・Owner・関連するデータ資産です。Ontologyは、概念階層・関係・ルール・制約まで含めて業務モデルを体系化します。Glossaryは、Ontologyを作る際の重要な入力と考えるのがよいと思います。
GlossaryとTaxonomyの違いは？
Taxonomyは、「商品 → 家電 → スマートフォン」のように、主に概念を階層的に分類するための仕組みです。OCI Data CatalogのGlossaryも、カテゴリ・サブカテゴリ・用語の階層を持ち、Taxonomyとして利用できます。Ontologyは、階層だけでなく、さまざまな関係・ルール・制約まで表現できる点で異なります。
Semantic LayerとOntologyは同じ？
どちらも「Revenueとは何か」を扱うため、重なる部分があります。ただし、Semantic Layerは指標を一貫して計算することに、Ontologyは企業全体の概念関係を扱うことに重心があります（4章の表を参照）。
Knowledge Graphを作ればOntologyになる？
必ずしもそうではありません。Property Graphで「顧客A → 注文123 → 商品X」を表現しても、「PremiumCustomerはCustomerの一種か」といった形式的な意味が定義されるわけではありません。
Ontologyを作ればKnowledge Graphは不要？
Ontologyは設計図なので、具体的な顧客・注文・商品のつながりを持たない場合があります。関係をたどって分析したいのであれば、Knowledge Graphが必要です。
9. Oracle / OCIではどう対応するのか
この対応は、製品を1対1で分類するものではありません。1つの製品が複数の役割を持つこともあります。
| 概念 | Oracle / OCIの関連機能 |
|---|---|
| Data Catalog | OCI Data Catalog（Business Glossary）、AI Data Platformの統合カタログ |
| Semantic Layer | AI Data PlatformのBusiness Ontologies / Semantic Layer、Oracle Analytics Cloud |
| Enterprise Ontology |
AI Data PlatformのBusiness Ontologies、Oracle AI Database 26aiのRDF Graph（RDF / RDFS / OWL） |
| Knowledge Graph | SQL Property Graph、RDF Graph |
第3回で扱った内容に加えて、今回の観点で押さえておきたいのは次の2点です。
- Oracle Analytics Cloud：AI Data Platformの公式ブログでは、統合カタログやLakehouseと連携し、ガバナンスされたデータをビジネスの洞察に変えるセマンティック・可視化レイヤーとして位置付けられています。
- RDF GraphからProperty Graphを作成できる：Property Graphは、URIによるグローバルな識別や、形式的意味論・推論を持たない、よりシンプルなモデルです。その代わり、80以上の組み込みアルゴリズムでグラフ分析ができます。RDF Graph上にProperty Graphを作成すれば、両者の強みを組み合わせられます。
RDF / RDFS / OWLで形式的な意味を表現し、必要に応じてProperty Graphに展開して関係探索やGraph Analyticsを行うという役割分担は、4つの概念を組み合わせる具体例の1つです。
10. 4つを「導入順序」ではなく「レイヤー」として考える
始める場所は企業によって違う
6章の図は、4つを必ずこの順番で導入するという意味ではありません。実際のスタート地点はさまざまです。
| パターン | 起点 | 広げ方 |
|---|---|---|
| A. ガバナンス起点 | Data Catalog | Metadata整備 → Business Glossary → Semantic Layer |
| B. BI起点 | Semantic Layer | KPIの統一 → AI Agentから再利用 → Ontology |
| C. 分析起点 | Knowledge Graph | 不正検知などの関係分析 → 業務概念をOntologyとして整理 |
AI時代に組み合わせる理由
これらは従来、ガバナンス（Catalog）、BI（Semantic Layer）、ナレッジ管理（Ontology）、グラフ分析（Knowledge Graph）と、別々の目的で使われてきました。
AI Agentの登場で、これらが1つのアーキテクチャの中で再び重要になっています。Agentは、データを見つけ、意味を理解し、ルールを適用し、関係をたどるところまでを、1回の依頼の中で行う必要があるからです。
「プロンプトに定義を書けばよいのでは？」と思うかもしれません。しかし前述のOracleブログでも、プロンプトごとに業務の説明をし直すのであれば、業務を理解しているのはモデルではなくプロンプトを書いた人だと指摘されています。プロンプト集は役に立つものの、Semantic Layerの代わりにはならない、という主張です。
私もこの点に同意します。定義を人やプロンプトの中に置くのではなく、企業の資産として4つのレイヤーに持たせることが、回答の一貫性と説明可能性につながると考えています。
11. 自社には何が不足しているか
私のおすすめは、製品から考えるのではなく、AIがつまずいている原因から逆算することです。
| AIがつまずく症状 | 不足している可能性が高いもの |
|---|---|
| 違うテーブルを使って回答する | Data Catalog |
| 聞く人やツールによって数字が変わる | Semantic Layer |
| 「関西」や「優良顧客」を誤って解釈する | Enterprise Ontology |
| 集計はできるが、原因の関係までたどれない | Knowledge Graph |
チェックリスト
Data Catalog
- どのデータが存在するか検索できる
- Data Owner、更新日時、品質、Lineageを確認できる
- 業務用語とデータ資産を関連付けられる
Semantic Layer
- 売上・利益・顧客数など主要KPIの定義が共通化されている
- 計算ルールがSQLやExcelの中に埋もれていない
- BIとAIで同じ指標定義を使える
Enterprise Ontology
- 主要な業務概念と、その関係を説明できる
- 業務ルール・制約が明文化されている
- Business Ownerが決まっている
Knowledge Graph
- 具体的なEntity間の関係をたどれる
- 複数システムにまたがるEntityを関連付けられる
- AI Agentが関係性をコンテキストとして利用できる
まとめ
- Data Catalogはデータを発見・管理し、Semantic Layerは指標・業務用語を共通の定義で使えるようにし、Enterprise Ontologyは概念・関係・ルールを体系化し、Knowledge GraphはEntityとRelationshipを知識としてつなぐ
- 4つは重なる部分があるものの、中心となる役割は異なり、AI Agentにそれぞれ異なるコンテキストを提供する
- 導入の順序は決まっていない。AIがつまずいている原因から、不足しているレイヤーを見極める
- 定義を人やプロンプトではなく、企業の資産としてレイヤーに持たせることが、企業AIの一貫性と説明可能性につながる
次回は、シリーズの総まとめとして、Data Platform for AI・Enterprise Ontology・AI Agentを1つのアーキテクチャとして整理する予定です。
参考情報
- Oracle AI Data Platform
- What is the AI Data Platform?（Oracle AI Data Platform Blog）
- Why Enterprise AI Needs Deep Business Semantics（Oracle AI Data Platform Blog）
- Your LLM Can Read Your Data. But It Still Doesn't Understand Your Business.（Oracle AI Data Platform Blog）
- Using Business Glossaries（OCI Data Catalog Documentation）
- Graph Developer's Guide for RDF Graph（Oracle AI Database 26ai）
- Creating Property Graphs from RDF Graphs（Oracle AI Database 26ai）
シリーズ
- 第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をつなぐリファレンスアーキテクチャ（予定）