【Data Platform for AI】AIが使える企業データ基盤に必要な7つの要件を整理する

Posted at 2026-09-27

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

この記事では、生成AIやAI Agentが企業データを安全かつ継続的に利用するためのデータ基盤を、アーキテクチャ上の概念として Data Platform for AI と呼びます。Oracleの特定製品名ではありません。

TL;DR

AIに必要なのは「大量のデータ」ではなく、信頼でき、意味が分かり、権限管理され、AIから利用できるデータ（AI Ready Data） である
Data Platform for AIは、既存のDWHやLakehouseを置き換えるものではない。AIが利用できる状態まで拡張する考え方である
必要な要件は Integration / Quality / Catalog / Business Context / Governance / Lineage / AI Accessibility の7つ
「Agentを作ってからデータを整える」のではなく、Data → Context → Agent の順で考える

はじめに

前回の記事では、AI Agentが企業データを理解し、業務アクションにつなげるための基盤として Agentic Data Platform を整理しました。今回は、その土台にあたる Data Platform for AI を扱います。

どれほど優れたLLMやAgentを導入しても、利用するデータが次のような状態では、業務で安心して使うことはできません。

古い、または間違っている
どこにあり、どれが正式なデータなのか分からない
同じ指標でも部門ごとに定義が異なる
誰がアクセスしてよいのか分からない

この記事では、第1回と同じ通し事例 「関西エリアの売上が前月より下がった理由を調べて」 を使い、AIがこの依頼に正しく答えるためにデータ基盤に何が必要かを整理します。

1. Data Platform for AIとは

この記事では次のように定義します。

企業内外のデータを統合・管理し、品質・意味・権限・由来を明確にしたうえで、Analytics、ML、生成AI、AI Agentから安全かつ効率的に利用できる状態を提供するデータ基盤。

従来のデータ基盤との最大の違いは、データの利用者にAIが加わることです。

データ基盤	主な利用者	主な用途
DWH	人	BI、レポート、集計
Data Lake	人、Data Scientist	大規模分析、ML
Lakehouse	人、Analytics、ML	SQLと大規模データ処理
Data Platform for AI	人 + AI	Analytics、RAG、NL2SQL、ML、AI Agent

これまでは、「この項目は売上高だ」「このNULLは業務上問題ない」「このテーブルは昨日更新された」といった判断を、人が暗黙知で補っていました。AIが直接データを使う場合、この暗黙知は前提にできません。そのため、データ基盤そのものに明示的な情報を持たせる必要があります。

2. AI Ready Dataとは

この記事では、AI Ready Dataを次のように整理します。

AIが安全かつ適切に利用するために必要な、品質・鮮度・意味・権限・由来が整備されたデータ

次のデータを例に考えます。

CUSTOMER_ID : 10001
REGION      : KNS
SALES       : 12000000
STATUS      : A

社内の人であれば、経験から次のように読み取れるかもしれません。

項目	社内の人の解釈
REGION = KNS	関西エリア
SALES	会計上計上された税抜売上高
STATUS = A	現在取引可能な有効顧客

しかしAIには、こうした企業固有の前提知識はありません。「KNS」が関西だと分からなければ、通し事例の「関西エリアの売上」という依頼にすら正しく答えられません。

データをAI Readyにするには、値そのものに加えて、説明・業務上の意味・品質・更新日時・所有者・アクセス権・由来を提供できる必要があります。

3. Data Platform for AIに必要な7つの要件

#	要件	一言でいうと
①	Data Integration	必要なデータにつながる
②	Data Quality / Freshness	正しく、新しい
③	Catalog / Metadata	見つけられ、説明がある
④	Business Context / Semantics	業務上の意味が分かる
⑤	Security / Governance	使ってよい範囲が決まっている
⑥	Lineage / Observability	由来と利用履歴を追える
⑦	AI Accessibility	AIから適切な方法で使える

以下、1つずつ見ていきます。

4. 要件① Data Integration：必要なデータにつながる

企業データは、Database、ERP / CRM、SaaS、Object Storage、Excel / CSV、PDF、ログ、IoT、外部サービスなどに分散しています。生成AIやAI Agentでは、構造化データだけでなく、文書などの非構造化データも重要になります。

通し事例では、売上（DB）、顧客（CRM）、キャンペーン企画書（PDF）、在庫（ERP）を横断する必要があります。

すべてを1か所にコピーする必要はない

従来のDWHでは、ETLでデータを1か所に集めるのが一般的でした。現在はそれに加えて、Federation、Data Sharing、Zero Copy、External Catalogなど、データを元の場所に置いたまま利用する選択肢が増えています。

重要なのは「すべてを1か所に集めること」ではなく、必要なデータに、適切なガバナンスのもとでアクセスできる状態を作ることです。

5. 要件② Data Quality / Freshness：正しく、新しい

AIは間違ったデータでも答えてしまう

入力データに問題があっても、AIが「このデータでは判断できません」と答えるとは限りません。不正確なデータから、それらしい説明を生成してしまう可能性があります。

観点	確認すること
Accuracy	データは正しいか
Completeness	必要な項目が揃っているか
Consistency	システム間で矛盾していないか
Freshness	必要な鮮度を満たしているか
Uniqueness	重複していないか
Validity	業務ルールに従っているか

正しいSQLでも、正しい判断とは限らない

通し事例で、売上データの取り込みが先週止まっていたとします。AIが生成したSQLが完璧でも、「関西の売上が急減した」という誤った結論が導かれます。

Data Platform for AIでは、品質だけでなく、データがいつ時点の状態なのかをAIに伝えられることが重要です。

6. 要件③ Catalog / Metadata：見つけられ、説明がある

「関西の売上を分析したい」と考えたとき、次の点が分からないケースは珍しくありません。

どのテーブルを使えばよいか
どれが正式なデータか
誰が管理しているか
いつ更新されたか

これを解決するのが Data CatalogとMetadata です。Catalogでは、データ名、説明、オーナー、スキーマ、列の意味、業務用語、更新日時、品質、Lineage、アクセスポリシーなどを管理します。

CatalogはAIのコンテキストにもなる

Catalogは、人がデータを探すための仕組みにとどまりません。AI Agentが 「どのデータを使うべきか」を判断するためのコンテキスト にもなります。似た名前の売上テーブルが複数ある環境では、Catalogに「正式データ」と記載されているかどうかが、Agentの回答品質を左右します。

7. 要件④ Business Context / Semantics：業務上の意味が分かる

「売上」という言葉だけでも、受注金額・出荷金額・売上計上額、税込・税抜、キャンセルを含むか・含まないか、と意味が分かれます。一方、DB上では SALES_AMOUNT NUMBER としか定義されていないかもしれません。

最初から高度なOntologyは不要

Enterprise Ontologyは重要ですが、最初から大規模に構築する必要はありません。次のような作業から始められます。

テーブル・列の説明を書く
KPIの定義を統一する
Data Ownerを決める
Business Glossaryを整備する
計算ルールを明文化する

これらもAIにビジネス・コンテキストを伝えるための重要な土台です（テーブル・列コメントやビューを使った具体例は、第1回で紹介しています）。

8. 要件⑤ Security / Governance：使ってよい範囲が決まっている

「AIだから特別扱い」しない

「AI専用の強い権限を持つアカウントを1つ作ればよい」という設計は危険です。重要なのは、AI Agent経由であっても、利用者が本来アクセスできる範囲だけを利用できることです。

通し事例でいえば、関西の営業担当者がAgentに依頼した場合、Agentが参照できるのは、その担当者が見てよい顧客・売上データだけであるべきです。

主な構成要素は次のとおりです。

分類	要素
認証・認可	Authentication、RBAC、Least Privilege
データ保護	Data Masking、Row / Column Level Security
運用	Secrets Management、Audit

ガバナンスと使いやすさの両立

ガバナンスが強すぎると「データはあるのに誰も使えない」状態になり、弱すぎると「AIが見るべきでないデータまで参照できる」状態になります。目指すのは、Discoverable（見つけられる）・Accessible（使える）・Governed（統制されている） が同時に成り立つ状態です。

9. 要件⑥ Lineage / Observability：由来と利用履歴を追える

AIを業務で使うほど、「なぜこの回答になったのか」を後から説明できることが重要になります。

たとえばAgentが「関西の売上は前月比12%減」と回答した場合、次の経路をたどれれば、結果を検証できます。

Data LineageからAgent Observabilityへ

AI Agentでは、データだけでなく、Prompt、Model、SQL、Tool、Agent、Output、Action も追跡対象になります。今後は、Data Lineage・AI Observability・Agent Observabilityを一体として考える必要があります。

10. 要件⑦ AI Accessibility：AIから適切な方法で使える

AIが企業データにアクセスする入口は1つではなく、用途によって適切な技術が異なります。

利用したい内容	主な技術
売上データを集計する	SQL
自然言語でDBを検索する	NL2SQL
PDFや文書から情報を探す	RAG / Vector Search
顧客・商品の関係をたどる	Graph
将来を予測する	Machine Learning
業務ツールを実行する	API / MCP

通し事例では、売上の集計（NL2SQL）、キャンペーン企画書の検索（RAG）、売上が落ちた顧客と代理店の関係の探索（Graph）を組み合わせることになります。複数の入口を、同じガバナンスのもとで提供できることがポイントです。

11. AI Ready Dataを段階的に作る：Medallion構造とData Product

Bronze / Silver / Gold

データを段階的に整備する方法として、Bronze / Silver / GoldのMedallion構造があります。

レイヤー	内容	例
Bronze	元の形で保持する	CSV、JSON、ログ、ソーステーブル
Silver	利用しやすく整える	重複除去、型統一、コード変換、標準化
Gold	業務で使える形にする	KPI、集計済みデータ、ML用Feature

ただし、Goldに置けば自動的にAI Readyになるわけではありません。品質・Metadata・ビジネス・コンテキスト・Security・Lineageが揃って、初めてAIが安心して使えるデータになります。

Data Productとして提供する

そこで有効なのが、データを単なるテーブルではなく Data Product として提供する考え方です。Data Productには、データ本体に加えて、Metadata、Owner、品質、SLA、アクセスポリシー、業務定義を含めます。

つまり、「このテーブルを使ってください」ではなく、「この用途には、この信頼済みData Productを使ってください」 という状態を作ります。

通し事例なら、数万のテーブルの中から探させるのではなく、「Sales Performance（地域別売上）」というData Productとして公開しておけば、人もAgentも迷わず正しいデータを選べます。

12. Oracle / OCIで考えるData Platform for AI

7つの要件をOracle / OCIに当てはめると、次のように整理できます。製品の優劣を示すものではなく、アーキテクチャ上の対応関係です。

要件	Oracle / OCIの主な製品・機能
① Integration	Oracle GoldenGate、OCI Data Integration、AI Data PlatformのExternal Catalog
② Quality	SQL、AI Data PlatformのData Engineering（Spark）
③ Catalog	AI Data Platformの統合カタログ、OCI Data Catalog
④ Business Context	AI Data PlatformのSemantic Layer / Business Ontologies、表・列コメント
⑤ Governance	Database Security、VPD、OCI IAM、AI Data Platformの権限モデル
⑥ Lineage	AI Data PlatformのData Lineage、Unified Audit
⑦ AI Access	Select AI、AI Vector Search、Property Graph、MCP Server

特に注目したいのは、Oracle AI Data PlatformのExternal Catalogです。2026年8月の公式ブログでは、Oracle以外のSnowflake、Azure SQL、MySQLも外部カタログとして登録でき、データを複製せずに、スキーマやオブジェクトの発見・利用ができるようになったと紹介されています。

アクセスはカタログ単位で制御され、列名・データ型・説明などのメタデータも表示されます。これは要件①（コピーしないIntegration）、③（Catalog）、⑤（Governance）を同時に満たす例といえます。

データプラットフォームの役割が、データを1か所に集めることから、分散したデータを統一されたガバナンスのもとで使える状態にすることへ広がっていることが分かります。

13. 全体像と、Agentic Data Platformへのつながり

Agentに本当に必要なのは、大量のデータではなく、信頼できるデータ・ビジネス・コンテキスト・ガバナンス・利用しやすいインターフェースです。Data Platform for AIは、この土台を提供します。そのため、Data → Context → Agent の順で考えることが重要です。

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

「データ基盤は整っている」という思い込み：BI用に整備されていても、列の意味やオーナーが人の頭の中にしかないケースは多くあります。AIから見れば、それはAI Readyではありません。
Catalogを作って終わる：導入直後は充実していても、更新されなければすぐに信頼されなくなります。Catalogの鮮度も、データの鮮度と同じくらい重要です。
ガバナンスを後回しにする：PoCで強い権限のアカウントを使うと、本番化の段階で権限設計をやり直すことになりがちです。最初から「利用者の権限で動く」前提で設計しておく方が、結果的に早く進みます。

15. チェックリスト：自社のデータ基盤はAI Readyか

Data / Quality

AIに使わせたいデータが明確になっている
正式なデータソースが決まっている
必要な鮮度でデータを提供できる
重複や不整合を管理できる

Catalog / Business Context

データを検索・発見できる
Data Ownerと最終更新日時が分かる
テーブルや列の意味が記述されている
KPIの定義と業務ルールが明文化されている

Security / Governance

AI経由でも既存の権限を維持できる
機密データの扱いが定義されている
AIがアクセスしてよい範囲を説明できる

Lineage / AI Accessibility

データの由来と加工処理を追跡できる
AIがどのデータを使い、何を実行したか確認できる
SQL・自然言語・文書検索など、複数の方法でAIから利用できる

すべてを最初から満たす必要はありません。重要なのは、AIを導入してからデータを整えるのではなく、AIが使えるデータを継続的に生み出せる仕組みを、データ基盤側に持たせることです。

まとめ

Data Platform for AIは、単にAIサービスを追加したデータ基盤ではなく、人とAIが共通して利用できるデータ基盤へ進化させる考え方である
必要な要件は、Integration / Quality / Catalog / Business Context / Governance / Lineage / AI Accessibility の7つである
AIの業務利用が広がるほど、「AIに何を答えさせるか」以上に、何を根拠に答えたのか、そのデータは正しいのか、使ってよいのか、何を意味しているのかを説明できることが重要になる

そして、AI Agentに企業固有の業務を理解させるうえで鍵になるのが Semantic Layer / Enterprise Ontology です。次回はこのテーマで、Data・Metadata・Semantic Layer・Ontologyの関係を整理する予定です。

参考情報

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

第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をつなぐリファレンスアーキテクチャ（予定）

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up