本記事は2026年9月時点の公開情報をもとに整理しています。記載内容は個人の見解です。
この記事では、AI Agentが企業データの意味・関係・ルールを理解して推論し、業務アクションにつなげるためのデータ基盤を、アーキテクチャ上の概念として Agentic Data Platform と呼びます。Oracleの特定製品名ではありません。
TL;DR
- AI Agentに企業の業務を任せるには、LLMの選択だけでなく、「データの意味（Semantics / Ontology）」と「権限・監査」の設計が重要になる
- Agentic Data Platformは、既存のDWHやLakehouseを置き換えるものではない。その上に 意味・Agent・アクション のレイヤーを重ねる考え方である
- Oracle / OCIでは、Select AI、Property Graph、RDF Graph、MCP Server、A2A Serverなどにより、この構造の多くをデータベースの近くで実現できる
この記事で扱うこと
- Data Platform for AIとAgentic Data Platformの関係
- Enterprise Ontologyが必要になる理由
- 各レイヤーの役割と、RAG・NL2SQL・MCP・A2Aの位置づけ
- Oracle / OCIの技術との対応関係
- 導入時の課題と段階的な進め方
本記事の通し事例
各レイヤーの役割を具体的に説明するため、本記事では次の依頼を通し事例として扱います。
「関西エリアの売上が前月より下がった理由を調べて、重要な要因があれば営業責任者に通知して」
1. データ基盤は「分析する基盤」から「行動につなげる基盤」へ
| 段階 | 主な目的 | 実行主体 | 得られるもの |
|---|---|---|---|
| DWH / BI | 集計・可視化 | 人 | レポート、KPI |
| Data Lake / Lakehouse | 多様なデータの統合・分析 | 人、分析基盤 | 分析結果、予測 |
| Data Platform for AI | AIが使えるデータの整備 | AI + 人 | 検索・生成・推論の材料 |
| Agentic Data Platform | AI Agentによる推論と業務アクション | AI Agent + 人 | 判断支援、業務実行、継続的改善 |
従来のデータ活用では、データとアクションの間に必ず人が入っていました。
ポイントは、AIがすべてを勝手に決めることではないという点です。業務の重要度に応じて人の承認（Human in the Loop：処理の途中に人の判断を組み込むこと）を挟みながら、データからアクションまでの距離を短くすることが狙いです。
2. Agentic Data Platformとは
この記事では次のように定義します。
企業データと、そのデータが持つ業務上の意味・関係・ルールを統合し、AI Agentが安全に検索・分析・推論し、必要に応じて業務アクションへつなげるためのデータプラットフォーム。
特徴は、Understand → Reason → Act の3段階を支えることです。
| 段階 | 内容 | 通し事例での動き |
|---|---|---|
| Understand（理解） | 企業固有の意味を理解する | 「関西エリア」はどの支店を含むか、「売上」は受注額か計上額か（税抜・キャンセル除く） |
| Reason（推論） | 複数データを関連付けて分析する | 売上・受注・在庫・顧客・キャンペーンを横断し、前月と比較する |
| Act（行動） | 業務アクションにつなげる | 要因レポートを生成し、ポリシーを確認したうえで営業責任者へ通知する |
Data Platform for AIとの関係は、次のように整理できます。
Data Platform for AI ＝ AIがデータを「使える」ようにする基盤
Agentic Data Platform ＝ AI Agentがデータの「意味を理解し、業務で行動できる」ようにする基盤
両者は対立するものではなく、前者が後者の土台となる段階的な関係です。
3. 主要レイヤーと役割
| レイヤー | 役割 | 主な要素 |
|---|---|---|
| Data Source | 企業データそのもの | 基幹システム、DB、SaaS、PDF・文書、ログ、IoT、外部データ |
| Data Platform for AI | AI Ready Dataの提供 | 統合、ストリーミング、品質、Catalog、Metadata、Lineage、Security |
| Semantic / Ontology | データに業務上の意味を与える | Business Glossary、Semantic Layer、Ontology、Knowledge Graph |
| AI / Retrieval | データを取り出し推論する | SQL / NL2SQL、RAG、Vector Search、GraphRAG、ML、LLM |
| AI Agent | ツールを選択し処理を組み立てる | 計画、ツール選択、複数Agentの協調 |
| Action / Integration | 業務システムとつながる | MCP、A2A、API、Workflow |
AI Ready Dataとは、単に保存されているデータではありません。正しい・最新・意味が分かる・由来を追える・権限管理されている・AIから利用できる という条件を満たしたデータを指します。
RAG・NL2SQL・Graphの使い分け
これらは競合する技術ではなく、質問の種類に応じて組み合わせて使います。
| 質問の例 | 主に使う技術 | 理由 |
|---|---|---|
| 「関西の売上を前月と比べて」 | SQL / NL2SQL | 構造化データの集計・比較 |
| 「関西向けキャンペーンの施策内容は？」 | RAG / Vector Search | 企画書・議事録などの文書検索 |
| 「売上が落ちた顧客と取引のある代理店は？」 | Graph / Knowledge Graph | エンティティ間の関係をたどる |
| 「"優良顧客"の売上だけで見て」 | Ontology / Semantic Layer | 業務定義に基づく条件の解釈 |
| 「来月も下がりそうか？」 | Machine Learning | 予測 |
MCPとA2Aの位置づけ
| 技術 | 接続する対象 | 役割 |
|---|---|---|
| MCP（Model Context Protocol） | Agent ⇔ ツール・データ | Agentが使えるツールやデータを標準的な方法で公開する |
| A2A（Agent2Agent Protocol） | Agent ⇔ Agent | 異なる基盤上のAgent同士が互いを発見し、呼び出す |
| API | Agent ⇔ 業務アプリ | 既存の業務サービスを実行する |
| Workflow | 業務プロセス | 承認フローなどの定型プロセスを管理する |
4. なぜEnterprise Ontologyが重要なのか
データ（Data）と意味（Meaning）は異なる
SALES_AMOUNT = 100,000,000
数値だけを見れば「1億円」です。しかし経営判断では、次の点が重要になります。
- 受注額（Booking：契約・注文が確定した金額）か、売上高（Revenue：会計上計上された金額）か
- 税込か税抜か、キャンセル分を含むか
- どの期間・どの地域・どの会計基準で集計したか
人は組織内の経験からこれを理解できますが、AI Agentには明示的に与えない限り伝わりません。定義が曖昧なままでは、LLMは「それらしい解釈」で回答してしまいます。
ビジネス・セマンティクスの3要素
| 要素 | 内容 | 例 |
|---|---|---|
| Vocabulary（用語） | 何を指すか | Customer、Product、Order、Revenue、Region |
| Relationships（関係） | どうつながるか | Customer —places→ Order —contains→ Product |
| Rules / Metrics（ルール・指標） | どう計算・判定するか | 優良顧客 ＝ 直近12か月の購入額が500万円以上、かつ直近3か月以内に取引あり |
Oracle AI Data Platformの公式ブログでも、ビジネス・セマンティクスを「用語」「関係（＝Ontology）」「ルールと指標」の3層で説明しています。同じ指標が部門ごとに異なる方法で計算されている状態は、問題として挙げられています。
Oracle Databaseで「意味・関係・ルール」を扱うための技術
これらを扱う技術は1つではなく、目的によって使い分けます。特に SQL Property GraphはOntologyそのものではない 点に注意が必要です。Property Graphは関係性の探索に適したモデルですが、RDFのような形式的意味論（formal semantics）や推論（Inference）の仕組みは持ちません。
| 技術 | 役割 | 位置づけ |
|---|---|---|
| Table / Column Comment | データの意味をメタデータとして記述する | Semantic Metadata |
| View | KPI・指標・業務ルールをSQLとして共通化する | Rules / Metrics |
| SQL Property Graph | 顧客・商品・注文などの関係性をグラフとして探索する | Relationships |
| RDF Graph（RDF / RDFS / OWL） | Ontologyを形式的に表現し、Semantic QueryやInferenceを行う | Formal Ontology |
| AI Data PlatformのSemantic Layer / Business Ontologies | 企業全体のビジネス・コンテキストを管理する | Enterprise Semantics |
以下のコードは、Oracle公式ドキュメントの仕様をもとにした説明用のサンプルです。実環境での動作検証は行っていません。テーブル構成は架空のものです。利用するDatabaseのバージョン、AIプロバイダー、リージョン、権限、モデルなどによって必要な設定は異なります。実装時は最新の公式ドキュメントを確認してください。
① Semantic Metadata：テーブル・列コメントで意味を記述する
COMMENT ON COLUMN orders.net_amount IS '税抜の受注金額（円）。キャンセル分は含まない。売上高(Revenue)ではない';
COMMENT ON COLUMN sales.revenue IS '会計上の売上計上額（円、税抜）。計上基準は出荷基準';
② Rules / Metrics：業務ルールをビューで共通化する
CREATE OR REPLACE VIEW premium_customers AS
SELECT c.customer_id, c.customer_name, c.region_code
FROM customers c
WHERE c.customer_id IN (
SELECT o.customer_id
FROM orders o
WHERE o.status <> 'CANCELLED'
AND o.order_date >= ADD_MONTHS(SYSDATE, -12)
GROUP BY o.customer_id
HAVING SUM(o.net_amount) >= 5000000
AND MAX(o.order_date) >= ADD_MONTHS(SYSDATE, -3)
);
COMMENT ON TABLE premium_customers IS
'優良顧客：直近12か月の税抜購入額500万円以上かつ直近3か月以内に取引がある顧客';
③ Relationships：SQL Property Graphで関係をたどる
CREATE PROPERTY GRAPH sales_graph
VERTEX TABLES (
customers KEY (customer_id) LABEL customer,
products KEY (product_id) LABEL product
)
EDGE TABLES (
order_items
KEY (order_item_id)
SOURCE KEY (customer_id) REFERENCES customers (customer_id)
DESTINATION KEY (product_id) REFERENCES products (product_id)
LABEL purchased
);
SELECT *
FROM GRAPH_TABLE ( sales_graph
MATCH (c IS customer WHERE c.region_code = 'KANSAI') -[IS purchased]-> (p IS product)
COLUMNS (c.customer_name, p.product_name)
);
「優良顧客は顧客のサブクラスである」といった概念階層やルールを形式的に定義し、推論に使いたい場合は、Oracle AI Database 26aiのRDF Graph（RDF / RDFS / OWL）が選択肢になります。
5. Oracle / OCIで考えるAgentic Data Platform
以下は製品の優劣を示すものではなく、アーキテクチャ上の対応関係を整理したものです。
| レイヤー | 主な製品・サービス | 主な機能・概念 |
|---|---|---|
| Data Source / Database | Oracle AI Database 26ai、Autonomous AI Database | 業務データ、JSON、ベクトル、グラフ |
| Data Integration | Oracle GoldenGate、OCI Data Integration | リアルタイム連携、ETL |
| Lakehouse / Platform | Oracle AI Data Platform、OCI Object Storage | Apache Iceberg、Spark |
| Catalog / Governance | AI Data Platformの統合カタログ、OCI Data Catalog | Metadata、Lineage、アクセス制御 |
| Semantic / Ontology | AI Data PlatformのBusiness Ontologies、RDF Graph、SQL Property Graph | Semantic Layer、Formal Ontology、Knowledge Graph |
| Retrieval / AI | AI Vector Search、Select AI | RAG、NL2SQL、ML |
| AI Agent | Select AI Agent、Data Science Agent、Oracle AI Data PlatformのAgent機能 | マルチエージェント、対話型ML |
| Agent Integration | Autonomous AI Database MCP Server、A2A Server | MCP、A2A、REST API |
| Security | Database Vault、VPD、OCI IAM | 認証・認可・監査 |
注目すべき動きは次の4点です。
- Oracle AI Data Platform：AI Agentを統合カタログ、Business Ontologies、企業システムと接続し、企業固有のコンテキストの中で推論させる方向性を打ち出しています。
- Oracle AI Database 26ai：23aiの後継となる長期サポートリリースです。AI Vector Searchに加え、MCPやApache Icebergへの対応が含まれています。
- Autonomous AI Database：MCP Serverにより、Select AI Agentのツールを、MCP対応クライアントから利用できるようにDBごとにマネージドで公開できます（26ai・19cで利用可能）。さらにA2A Serverにより、Select AIのエージェント・チームを外部から呼び出せるエージェントとして公開できます。
- Data Science Agent：Autonomous AI Database Serverless 26aiで一般提供（GA）されています。データのプロファイリング、特徴量準備、モデル学習、評価、推論用SQLの生成を、DB内で対話形式により実行できます。
つまりデータベースは、単にデータを保存する場所から、AI Agentが信頼できるデータに、DBの権限体系のまま安全にアクセスするための実行基盤へと役割を広げつつあります。
公式機能から見える実装イメージ
通し事例は、公式機能の組み合わせで次のように構成できると考えられます。
Step 1：Select AIでNL2SQLを使えるようにする
Select AIのプロファイルで "comments": "true" を指定すると、4章で記述したテーブル・列コメントがLLMに渡され、SQL生成に利用されます。
BEGIN
DBMS_CLOUD_AI.CREATE_PROFILE(
profile_name => 'SALES_AI',
attributes => '{
"provider" : "oci",
"credential_name" : "OCI_GENAI_CRED",
"object_list" : [
{"owner": "SALES", "name": "ORDERS"},
{"owner": "SALES", "name": "CUSTOMERS"},
{"owner": "SALES", "name": "PREMIUM_CUSTOMERS"}
],
"comments" : "true"
}'
);
END;
/
EXEC DBMS_CLOUD_AI.SET_PROFILE('SALES_AI');
-- 生成されるSQLを確認する
SELECT AI showsql 関西エリアの今月と前月の売上を商品カテゴリ別に比較して;
業務定義をコメントとしてメタデータ化すると、NL2SQLのSQL生成精度の改善が期待できます。これはEnterprise Ontologyそのものではありません。ただし、AIにビジネス・コンテキストを伝えるための基礎的なSemantic Metadataとして重要です。
Step 2：Select AI Agentで処理を束ねる
DBMS_CLOUD_AI_AGENT パッケージでは、SQLツールなどのTool、役割を持つAgent、指示を定義するTask、それらを束ねるTeamを定義し、RUN_TEAM で実行します。通し事例では「売上分析Agent」がStep 1のプロファイルを使うSQLツールで分析を行う、という構成になります。
Step 3：MCP / A2Aで外部と接続する
MCP Serverを有効化すると、Select AI Agentのツールを、MCP対応クライアントから呼び出せるようになります。A2A Serverを使えば、エージェント・チーム自体を外部のAgentから呼び出せます。そのため、別基盤の「通知Agent」などとも連携できます。
6. ガバナンス：後付けではなく前提条件
AI Agentが業務アクションを実行できるようになるほど、ガバナンスの重要性は増します。
| 観点 | 設計すべきこと |
|---|---|
| 認証・認可 | 利用者が本来見られるデータだけを、Agent経由でも見られるようにする（Agentに強い権限を与えない） |
| データガバナンス | データのオーナー、正式なデータソース、KPIの定義、更新時刻、由来を明確にする |
| Agent Governance | 利用できるツールとデータ、自動実行の範囲、承認が必要な処理、呼び出し元の制限を定める |
| Observability / Audit | 参照したデータ、実行したSQL、利用したツール、連携したAgent、実行したアクションを追跡する |
MCP ServerやA2A ServerがDBのロールやポリシーと統合されている点は、この観点で重要です。既存のDBセキュリティ設計を、そのままAgentのアクセス制御に生かせるからです。
7. 導入時の課題と限界
メリットばかりではありません。私は、次の点が導入のボトルネックになりやすいと考えています。
- Ontologyの整備・維持コスト：定義を作ること以上に、業務変更に合わせて保守し続けることが難しい領域です。オーナーのいないOntologyはすぐに陳腐化します。
- 部門間での定義の合意：「売上」の定義が経理と営業で異なることは珍しくありません。これは技術ではなく組織の課題であり、Agentの導入によって表面化します。
-
Agentの誤実行リスク：LLMは誤ったSQLや判断を返す可能性があります。
showsqlによる生成SQLの確認、読み取り専用ロールの利用、承認フローを前提に設計する必要があります。 - コストと性能：Agentは1つの依頼で複数回LLMやSQLを呼び出します。トークン費用とDB負荷の見積もりが必要です。
- 「Agentを入れること」の目的化：解決したい業務課題が曖昧なまま始めると、PoCで止まりやすくなります。
8. 段階的な進め方
最初からすべてを作り直す必要はありません。
| Step | 内容 | この段階で使えるもの |
|---|---|---|
| 1 | データ基盤を整備する（統合・品質・Catalog・Security） | BI、SQL |
| 2 | AI Ready Dataを増やす | RAG、NL2SQL（Select AI） |
| 3 | 業務コンテキストを整備する（コメント、ビュー、Glossary、Graph、Ontology） | 精度の高いNL2SQL、GraphRAG |
| 4 | 人が最終判断する領域で、限定的にAgentを導入する | 検索、レポート作成、分析支援 |
| 5 | ガバナンスと監査を整えたうえで、Actionを拡張する | MCP、A2A、API、Workflow |
特にStep 3は、テーブル・列コメントを書く、定義をビューに集約するといった地味な作業から始められます。私は、ここが最も費用対効果の高い一歩だと考えています。
まとめ
- モデルの選択に加えて、AIが利用するデータ基盤とビジネス・コンテキストの設計が、企業AIの品質を左右する重要な要素になる
- Agentic Data Platformは、Data Platform for AIの上に Semantic / Ontology・AI Agent・Action のレイヤーを重ね、全体をガバナンスで横断する構造である
- 「意味」を扱う技術は、コメント（Semantic Metadata）、ビュー（Rules）、Property Graph（Relationships）、RDF / OWL（Formal Ontology）と役割が異なり、目的に応じて使い分ける
- Oracle / OCIでは、Select AI、MCP Server、A2A Serverなどにより、DBの権限体系を維持したままAgentとつなぐ構成を取りやすい
「どのLLMを使うか」だけでなく、次の問いに答えられることが、今後のデータ基盤設計の中心になると考えています。
AIにどのデータを、どの意味で、どの権限で使わせ、どこまで行動させるのか
次回は、Agentic Data Platformの土台となる Data Platform for AI について、AI Ready Data、Data Catalog、Governanceの観点から整理する予定です。
参考情報
- Oracle AI Data Platform
- Why Enterprise AI Needs Deep Business Semantics（Oracle AI Data Platform Blog）
- Oracle AI Database 26aiの発表（Oracle Database Blog）
- 同・日本語訳（Oracle Engineer Blog）
- Autonomous AI Database MCP Server
- About Agent2Agent Protocol（Autonomous AI Database）
- Select AI Agent Teamsの作成
- DBMS_CLOUD_AI_AGENT Package
- Oracle Data Science Agent（Oracle Machine Learning Blog）