本記事は2026年9月時点の公開情報をもとに整理しています。記載内容は個人の見解です。
この記事では、これまでのシリーズで扱ってきた Data Platform for AI、Enterprise Ontology、AI / Retrieval、AI Agent、Business Action を、1つのアーキテクチャとしてつなぎます。
ここで示す「Agentic Data Platform」は、Oracleの特定製品名ではありません。AI Agentが企業データを安全に理解・推論し、業務アクションにつなげるための概念的なリファレンスアーキテクチャとして整理しています。
TL;DR
- Agentic Data Platformは、AI Agentを置くだけでは成り立たない。Data・意味・検索手段・Agent・Action・Governanceを一体で設計する必要がある
- 全体を 6つのレイヤー＋横断レイヤー（Security / Governance / Observability） で整理する
- リファレンスアーキテクチャとして重要なのは、レイヤーの一覧よりも、レイヤー間で何を受け渡すか・Identityをどう伝播させるか・何をどこで記録するかである
- 導入は Data Foundation → AI Ready Data → Semantic / Ontology → Agent Assist → Governed Action の順に段階的に進める
はじめに
このシリーズでは、次の順番で整理してきました。
| 回 | テーマ | 扱った問い |
|---|---|---|
| 第1回 | Agentic Data Platform | 全体像はどうなっているか |
| 第2回 | Data Platform for AI | AIが使えるデータとは何か |
| 第3回 | Enterprise Ontology | AIに業務の意味をどう伝えるか |
| 第4回 | Catalog・Semantic・Ontology・KG | 意味を扱う技術をどう使い分けるか |
第1回では全体像を概念的に示しました。最終回の今回は、それを設計に使えるリファレンスアーキテクチャとして具体化します。
通し事例は、第1回と同じ依頼です。
「関西エリアの売上が前月より下がった理由を調べて。重要な要因があれば営業責任者へ通知して」
1. 全体像：6レイヤー＋横断レイヤー
| # | レイヤー | 主な役割 | 詳しくは |
|---|---|---|---|
| ① | Data Sources | 企業内外のデータを提供する | 第2回 |
| ② | Data Platform for AI |
データを統合・品質管理し、AI Readyにする | 第2回 |
| ③ | Semantic / Ontology |
データに業務上の意味・関係・ルールを与える | 第3回・第4回 |
| ④ | AI / Retrieval | 質問に応じた方法で情報を取得・分析する | 第1回 |
| ⑤ | Agent / Orchestration |
依頼を分解し、Toolを選んで実行し、結果を統合する | この記事 |
| ⑥ | Action / Integration |
業務システムや他のAgentにつなげる | この記事 |
Security / Governance / Observabilityは、最後に追加する機能ではありません。すべてのレイヤーに最初から組み込む設計要件です。
2. レイヤー間で「何を受け渡すか」を設計する
リファレンスアーキテクチャで最も重要なのは、レイヤーの一覧よりもレイヤー間のインターフェースだと私は考えています。各レイヤーが次のレイヤーに何を渡すのかを決めておくと、責任の境界がはっきりします。
| 受け渡し | 渡すもの | 通し事例での例 |
|---|---|---|
| ① → ② | 生データ | ERPの受注・売上、CRMの顧客、キャンペーン資料 |
| ② → ③ |
Data Product （データ＋Metadata） |
「Sales Performance」：Owner、毎日8時更新、品質検証済み、Lineage、アクセス権 |
| ③ → ④ | 業務定義と関係 | 関西＝2府4県、Revenue＝出荷基準・税抜・キャンセル除外、Customer → Order → Product → Supplier |
| ④ → ⑤ | Toolの実行結果と根拠 | 集計結果＋生成されたSQL、検索した文書、たどったGraphの経路 |
| ⑤ → ⑥ | アクション要求 | 「営業責任者へ通知」＋重大度＋根拠＋承認要否 |
ポイントは、④から⑤へ結果だけでなく根拠も渡すことです。根拠が失われると、後から「なぜこの結論になったのか」を説明できません。
3. Layer ⑤ Agent / Orchestration：推論とTool利用をつなぐ
AI Agentの役割は、LLMに質問を投げることではありません。計画し、Toolを選び、結果を評価し、必要なら計画を修正することです。
Autonomous AI DatabaseのSelect AI Agentは、この考え方をDB内で実装したフレームワークです。公式ドキュメントでは、推論と行動を繰り返すReActパターンを採用していると説明されています。また、Planning・Tool Use・Reflection・Memory Managementの4層で構成されています。Toolとしては、組み込みのRAGとNL2SQL、独自のPL/SQLプロシージャ、外部REST APIを利用できます。
2026年7月28日の機能拡張では、次の機能が追加されました。
- Tool・Agent Teamの検出と呼び出し
- Teamの実行状態の確認
- Agentから直接Toolを呼ぶセッション
- Memoryの深さの設定
- Managed MCP Server・A2A Serverとの統合
Agent MemoryとOntologyは別物
ここは混同しやすいポイントです。
| Enterprise Ontology | Agent Memory | |
|---|---|---|
| 保持するもの | 企業に共通する意味・関係・ルール | Agentが経験した会話・結果・好み |
| 例 | 「優良顧客とは何か」 | 「このユーザーは前回、商品別の内訳を好んだ」 |
| 共有範囲 | 全社・全Agentで共通 | Agent Team単位・利用者単位 |
Select AI Agentは、Agent Teamごとに短期・長期Memoryを持ちます。また、別製品の Oracle AI Agent Memory は、Oracle AI Database上に構築された、エンタープライズAI Agent向けの永続的なMemory基盤として提供されています。
どちらを使う場合も、業務定義をMemoryに持たせないことが重要です。定義が会話ごとに学習されると、Agentによって解釈がずれていく原因になります。
4. Layer ⑥ Action / Integration：「答えるAI」から「動くAI」へ
| 方法 | 主な役割 |
|---|---|
| REST API | 既存の業務システムとの連携 |
| MCP | Agentから、Tool・データへの標準化された接続 |
| A2A | Agent同士の発見・委譲・連携 |
| Workflow | 定型業務の実行・管理 |
| Human Approval | 人による確認・承認 |
Autonomous AI Databaseでは、Managed MCP ServerがSelect AI AgentのToolをMCP対応クライアントに公開します。また、2026年7月7日に公開されたA2A Serverにより、Select AIのAgent Teamを外部のA2A対応Agentから発見・呼び出しできるようになりました。これにより、Agentのロジックとデータアクセスをデータベース内に保ったまま、マルチエージェントのワークフローに参加できます。
ここで重要なのは、接続できることと、自動実行してよいことは別という点です。どこまで自動化してよいかは、Actionのリスクで決めます。
| Action | 自律性の例 |
|---|---|
| データ検索・レポート生成 | 自動 |
| 社内担当者への通知 | 条件付き自動 |
| 顧客へのメール送信・発注変更 | 承認あり |
| 金銭を伴う取引 | 厳格な承認とPolicy |
目指すのは「AIに全部任せる」ことではなく、「どこまで任せられるかをGovernできる」ことです。
5. Identityを端から端まで伝播させる
Agent経由でデータにアクセスするとき、最も事故が起きやすいのが権限の扱いです。AI専用に強い権限を持つ共通アカウントを作ると、Agent経由で権限の境界を越えてしまいます。
理想は、利用者のIdentityが、Agent・Tool・データまで一貫して伝わることです。
Oracleの開発者ブログ（2026年5月）では、Managed MCPのToolは実際のDBユーザーの権限で実行されると説明されています。既存のネットワーク制御・VPDポリシー・監査証跡がそのまま適用されるため、別の信頼基盤を作る必要がないとされています。
実務上の注意点として、同ブログでは、MCP向けのVPDや監査ポリシーを書く際は、SESSION_USER に頼らず、MCPのコンテキスト属性を使うよう推奨されています。Agent経由のアクセスでは、「誰の依頼か」の取り方が通常のセッションと変わる点は、設計時に押さえておきたいポイントです。
6. 何をどこで記録するか：Observabilityの設計
追跡すべき対象は、最終回答だけではありません。記録先はレイヤーごとに異なるため、どこで何が取れるかを事前にマッピングしておく必要があります。
| 追跡したいこと | 記録先の例 | 補足 |
|---|---|---|
| データの由来・加工 | AI Data PlatformのData Lineage | 2026年8月にPreview提供。対象はNotebook・Workflowの系譜（列レベル含む） |
| Agentの思考過程 | Select AI Agentのビュー （ USER_CLOUD_AI_CONVERSATION_PROMPTS） |
Reflectionの内容を問い合わせで参照できる |
| Toolの実行・データアクセス | Unified Audit | 既定の保持期間は約14日。長期保管・集中管理にはData Safe |
| Actionの承認 | Workflow / 業務システム側 | 承認者・承認日時・判断理由 |
注意したいのは、1つの仕組みですべては追えないことです。たとえばData Lineage（Preview）はデータエンジニアリングの系譜が対象で、Agentが使ったプロンプトやToolまでは含みません。
これらを依頼ID（相関ID）でつなげられるように設計しておくことが、後から「何を見て、何を実行したか」を説明するための鍵になると私は考えています。
7. 通し事例をリファレンスアーキテクチャで処理する
Agentが整理する原因候補の例です。
| 観察された事実 | 使ったTool |
|---|---|
| 売上低下の70%が商品Xに集中 | NL2SQL |
| 同時期のキャンペーンは商品Xを対象外にしていた | RAG |
| 商品Xの仕入先Bに納期遅延の履歴がある | Graph |
これらから、「仕入先Bの供給遅延に伴う、商品Xの販売機会減少」 を原因候補として提示します。
Knowledge GraphやAgentが見つけた「関係」は、因果関係の証明ではありません。原因を確定するには、時系列データ、追加データ、業務ルール、人による確認などが必要です。
8. Oracle / OCIへのマッピング
この対応は、Oracleの公式な製品構成図ではありません。この記事で定義した6レイヤーに、関連するOracle / OCIの機能を対応付けたものです。1つの機能が複数のレイヤーに関係する場合があります。
| レイヤー | Oracle / OCIの関連機能 |
|---|---|
| ① Data Sources | Oracle AI Database、Autonomous AI Database、OCI Object Storage、SaaS、外部データ |
| ② Data Platform for AI | Oracle AI Data Platform（統合カタログ、External Catalog、Data Lineage）、Oracle GoldenGate |
| ③ Semantic / Ontology | AI Data PlatformのBusiness Ontologies / Semantic Layer、Oracle Analytics Cloud、RDF Graph |
| ④ AI / Retrieval | Select AI（NL2SQL）、AI Vector Search、Property Graph / RDF Graph、Data Science Agent |
| ⑤ Agent / Orchestration | Select AI Agent（Agent Teams、Tools、短期・長期Memory）、Oracle AI Agent Memory |
| ⑥ Action / Integration | Managed MCP Server、A2A Server、REST API、Workflow |
| 横断 | OCI IAM、DBのロール・VPD、Unified Audit、Data Safe |
全体を通して見ると、Oracleのアプローチの特徴は、AgentのロジックとTool実行をデータの近くに置き、DBの権限・監査の仕組みをそのままAgentに適用する点にあります。5章・6章で見たIdentityの伝播や監査は、この特徴があるからこそ設計しやすくなります。
9. 段階的に導入する
| Phase | 名前 | やること | 主な対象レイヤー |
|---|---|---|---|
| 1 | Data Foundation | 統合・品質・Catalog・Securityを整える | ①② |
| 2 | AI Ready Data | 重要データをData Product化する | ② |
| 3 | Semantic / Ontology | 主要な用語・KPI・関係・ルールを明文化する | ③ |
| 4 | Agent Assist | 人が最終判断する領域（検索・分析・レポート）から始める | ④⑤ |
| 5 | Governed Action | 監査・認可・Policyを整えてからActionを広げる | ⑥ |
Phase 4の段階から、5章のIdentity伝播と6章の記録先マップを設計に含めておくことをおすすめします。Agentを先に作り、後から権限や監査を組み込もうとすると、作り直しになりやすいためです。
10. チェックリスト
① Data Sources
- AIが使うデータソースとSystem of Recordが明確になっている
② Data Platform for AI
- 正式なData Productを識別でき、品質・鮮度・Lineageを確認できる
③ Semantic / Ontology
- 主要KPIの定義と、概念間の関係を説明できる
④ AI / Retrieval
- SQL・RAG・Graphを目的に応じて使い分け、結果とともに根拠を返せる
⑤ Agent / Orchestration
- 使えるToolが制御され、Memoryに業務定義を持たせていない
⑥ Action / Integration
- 自動実行できるActionと、承認が必要なActionが定義されている
横断：Security / Governance / Observability
- 利用者のIdentityがデータまで伝播し、依頼IDで記録を横断的に追える
まとめ：シリーズを通して
5回のシリーズで、Agentic Data Platformを次の流れで整理してきました。
シリーズを書き終えて、私が最も伝えたかったのは、AI Agentそのものを出発点にしないということです。Agentの性能は急速に向上していますが、企業で継続的に使われるかどうかを決めるのは、Agentの手前にあるデータと意味、そしてAgentの周りにある権限と監査の設計だと考えています。
第1回の最後に置いた問いを、改めて掲げます。
AIにどのデータを、どの意味で、どの権限で使わせ、どこまで行動させるのか
Agentic Data Platformとは、AIを追加したデータ基盤ではなく、Data・Meaning・Reasoning・ActionをGovernanceのもとでつなぐ基盤です。この問いに答えられる設計を、既存のデータ基盤から一歩ずつ積み上げていくことが、現実的な道筋だと考えています。
最後まで読んでいただき、ありがとうございました。
参考情報
- Oracle AI Data Platform
- Why Enterprise AI Needs Deep Business Semantics（Oracle AI Data Platform Blog）
- Trace and Understand Data Lineage in Oracle AI Data Platform（Oracle AI Data Platform Blog）
- About Select AI Agent（Autonomous AI Database Documentation）
- Select AI Agent Framework Enhancements（2026-07）
- Expose Select AI Agent team as agent through A2A protocol（2026-07）
- Managed MCP in Autonomous AI Database: remote, governed tools per database（Oracle Developers Blog）
- Oracle AI Agent Memory
- Oracle Data Science Agent（Oracle Machine Learning Blog）
- Graph Developer's Guide for RDF Graph（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をつなぐリファレンスアーキテクチャ ← この記事