売上データは Database、ログは Object Storage に、契約書や仕様書は SharePoint に、分析用データは異なるクラウドに——。
「データがあちこちに散らばっていて、AI に使いたくても使えない」
データ活用の世界では、長い間、Data Warehouse と Big Data が別々の文脈で発展してきました。
Data Warehouse は、構造化された業務データを高品質に管理し、BI やレポーティングに使うための基盤です。
一方で Big Data は、ログ、センサーデータ、Webアクセス、JSON、画像、ドキュメントなど、大量・多様・高速に発生するデータを扱うための文脈で広がりました。
その Big Data の受け皿として、データをまず生の形で蓄積する Data Lake が登場しました。
そして現在は、Data Lake の柔軟性と Data Warehouse の管理性・性能を組み合わせる Lakehouse が注目されています。
特に Oracle Autonomous AI Lakehouse の文脈では、単に「Object Storage にデータを置く」だけではありません。Oracle AI Database を中心に、Iceberg、Object Storage、外部表、Database Link、SharePoint、SaaS、Vector Search、BI、AI を つなげて使う ところに大きな意味があります。
たとえば、こんなことが SQL の世界からできるようになります。
- SharePoint 上の Word / PDF から、PL/SQL 一発で Vector Index を作って RAG 化する
- Databricks Unity Catalog や Snowflake Polaris の Iceberg テーブルに直接つないで問い合わせる
- BigQuery や Snowflake 上のデータを、Database Link 経由で Oracle 側のデータと JOIN する
「え、それ Database からできるの？」と思った方は、ぜひ最後まで読んでみてください。
読み終える頃には、Oracle Autonomous AI Lakehouse が単なる Lakehouse 製品ではなく、OCI・Azure・GCP・AWS をまたいでデータをつなぐ All-Platform な基盤 に見えてくるはずです。
ということで、本稿では、Oracle Autonomous AI Lakehouse を軸に、Lakehouse で扱うデータ、Oracle AI Database から見た Lakehouse、そして実際に「どこに何を置くべきか」を整理します。
Agenda
-
1. Lakehouse で扱うデータ
-
2. Oracle AI Database から見る Lakehouse
-
3. Oracle Autonomous AI Lakehouse とは何か
-
4. Autonomous AI Database で広がるデータ接続
-
5. どこに何を置くべきか
-
最後に：Oracle Autonomous AI Lakehouse は “全てをつなぐ” データ基盤へ
-
参考資料
■ 1. Lakehouse で扱うデータ
Lakehouse で扱うデータは、一言でいうと かなり幅広いです。
従来の Data Warehouse では、売上、顧客、注文、在庫、会計などの構造化データが中心でした。一方で Lakehouse では、構造化データに加えて、JSON、ログ、PDF、画像、音声、動画、IoT、イベント、Embedding なども扱います。
Oracle のドキュメントでも、Lakehouse は CSV や Parquet、Iceberg などのオープンなファイル・テーブル形式を利用し、構造化、半構造化、非構造化データを格納・処理するものとして説明されています。また、PDF、Word、画像などの非構造化データも Lakehouse の対象として挙げられています。
参考: Autonomous AI Lakehouse - Oracle Documentation
ここではまず「データの形」として、構造化・半構造化・非構造化の3つに分けます。
そのうえで、実務でよく登場するデータを用途別に整理すると、次のようになります。
データの形 → 構造化 / 半構造化 / 非構造化
実務上の分類 → 業務データ / ログ / IoT / 外部データ / 文書 / AIデータ
データの成熟度 → Bronze / Silver / Gold / AI-ready
- データ種別
| データ種別 | 具体例 | 主な用途 |
|---|---|---|
|
構造化データ 表形式で管理しやすいデータ |
売上、顧客、注文、在庫、会計、人事 | BI、KPI、レポート、業務分析 |
|
半構造化データ ある程度構造はあるが表に固定されないデータ |
JSON、XML、API レスポンス、アプリログ | イベント分析、アプリ分析、データ統合 |
|
非構造化データ 表形式にしにくいデータ |
PDF、Word、画像、音声、動画、メール | 検索、要約、RAG、AI 分析 |
Lakehouse の特徴は、この3種類をまとめて扱える点です。従来の DWH は構造化データが中心でしたが、Lakehouse ではログ、ファイル、画像、AI向けデータなども対象になります。
- 実務でよく使われるデータの種類
実務目線では、たとえば業務データ、ログ、IoT、ドキュメント、AI・機械学習用データなどが代表的です。細かい分類は次の表に折りたたんでおきます。
実務でよく使われるデータの種類（クリックで展開）
| 種類 | 具体例 | 主な用途 |
|---|---|---|
| 業務データ | 受注、売上、請求、顧客、契約、在庫 | BI、レポート、経営分析 |
| マスタデータ | 商品マスタ、顧客マスタ、組織マスタ、拠点マスタ | データ統合、名寄せ、分析の基準 |
| トランザクションデータ | 注文履歴、決済履歴、出荷履歴、予約履歴 | 需要分析、不正検知、顧客分析 |
| ログデータ | アプリログ、Webアクセスログ、監査ログ、システムログ | 障害分析、セキュリティ分析、利用状況分析 |
| イベントデータ | クリック、閲覧、検索、カート投入、アプリ操作 | 行動分析、レコメンド、マーケティング |
| IoT・センサーデータ | 温度、圧力、振動、位置情報、稼働状況 | 予兆保全、設備監視、リアルタイム分析 |
| ストリーミングデータ | Kafkaイベント、CDC、リアルタイム取引 | リアルタイムダッシュボード、即時検知 |
| 外部データ | 天気、市場データ、人口統計、SNS、パートナーデータ | 需要予測、リスク分析、補助データ |
| ドキュメントデータ | PDF、契約書、仕様書、問い合わせ文面 | 検索、要約、生成AI、ナレッジ活用 |
| 画像・音声・動画 | 製品画像、監視カメラ、通話録音、検査画像 | AI分析、品質検査、音声認識 |
| 地理空間データ | GPS、住所、配送ルート、店舗位置 | 商圏分析、物流最適化、移動分析 |
| AI・機械学習用データ | 特徴量、ラベル、学習データ、推論結果、埋め込みベクトル | モデル学習、MLOps、生成AI/RAG |
ここで重要なのは、データの種類だけでなく、データの成熟度も分けて考えることです。
Lakehouse の世界では、Bronze / Silver / Gold というレイヤーでデータを整理する考え方がよく使われます。Databricks の Medallion Architecture では、Bronze は Raw、Silver は validated、Gold は enriched というように、データ品質の段階として説明されています。
参考: Databricks Medallion Architecture
Oracle Autonomous AI Lakehouse で考える場合も、この整理は非常に使いやすいです。
Bronze / Silver / Gold + AI-ready のレイヤー
Bronze / Silver / Gold という3層に、AI活用では Feature / AI-ready を加えて考えます。
| レイヤー | 内容 | Oracle でのイメージ |
|---|---|---|
| Raw / Bronze | 取り込んだままの生データ | Object Storage、Iceberg、Parquet、CSV、JSON、PDF、ログ |
| Cleaned / Silver | クレンジング、型変換、重複排除、結合済みデータ | Database Table、External Table、Iceberg Table |
| Curated / Gold | BI や業務利用向けに整理されたデータ | Table、View、Materialized View、Analytic View |
| Feature / AI-ready | AI / ML / RAG で使いやすい形にしたデータ | VECTOR 列、Embedding Table、Chunk Table、Metadata Table |
つまり Lakehouse では、単に「いろいろなデータを置ける」だけでは不十分です。
生データ → 整形済みデータ → 分析用データ → AI活用データ
のように段階的に管理することが多いです。
大切なのは、
生データを保持すること、
分析しやすい形に整えること、
業務で使える意味のあるデータにすること、
そして AI が使える形に変換することです。
Lakehouse で利用されるデータは、細かく見ると無数にあります。
ただし、実務上は次の一文にまとめると十分です。
Lakehouse は、DWH 的な業務データと、Data Lake 的な多様な生データをまとめて扱う基盤です。
■ 2. Oracle AI Database から見る Lakehouse
Oracle AI Database から Lakehouse を見ると、少し面白い見方ができます。
一般的な説明では、Lakehouse は Object Storage や Iceberg のようなストレージ層を中心に語られることが多いです。しかし Oracle の場合、Database 側が非常に強力です。Oracle Autonomous AI Database は、JSON、Graph、Vector、Oracle Machine Learning、Spatial などを扱える統合的なデータ基盤として位置づけられています。
参考: Autonomous AI Lakehouse - Oracle Documentation
つまり、Oracle AI Database は単なる「構造化データを入れる箱」ではありません。
Oracle AI Database では、リレーショナルデータだけでなく、JSON、Text、Vector、Spatial、Graph などを同じ Database の中で扱えます。特に JSON については、トランザクション、索引、宣言的な SQL クエリ、View などのリレーショナルデータベース機能と組み合わせてネイティブに扱えます。さらに、JSON データをリレーショナルデータと JOIN したり、外部表上の JSON を Database 内から問い合わせたりできます。
参考: JSON in Oracle AI Database
AI の観点では、Oracle AI Vector Search が重要です。Oracle AI Database 26ai では VECTOR データ型により、Embedding を業務データと同じ Database 内に格納できます。非構造化データを Embedding に変換し、セマンティック検索や RAG に利用できます。
参考: Oracle AI Vector Search Overview
この点が、Oracle らしい Lakehouse の特徴です。
一般的な Lakehouse では、
- Lake にデータを置く
- 別のエンジンで分析する
- 別の Vector DB に Embedding を置く
というように、複数のコンポーネントを組み合わせることが多くなります。
一方で Oracle AI Database を使う場合は、次のように考えられます。
Object Storage / Iceberg / 外部データ
↓
External Table / DBMS_CLOUD / Catalog / Database Link
↓
Oracle AI Database
↓
SQL / JSON / Text / Vector / Spatial / Graph / ML / BI / RAG
もちろん、すべてのデータを Database 内にコピーする必要はありません。Object Storage 上のファイルは外部表として問い合わせられます。Autonomous AI Database では、DBMS_CLOUD.CREATE_EXTERNAL_TABLE を使って Cloud 上のファイルに対する外部表を作成でき、OCI Object Storage、Azure Blob / ADLS、Amazon S3、Google Cloud Storage 互換ストレージなどが対象に含まれます。
参考: Query External Data with Autonomous Database
そのため、Oracle AI Database から見る Lakehouse は、次のように捉えると分かりやすいです。
Lakehouse ストレージ上のデータを、Oracle AI Database の SQL、ガバナンス、View、Materialized View、JSON、Vector、Text、Graph、Spatial、AI 機能で活用するアーキテクチャ
性能面では In-Memory も重要です。Oracle AI Database の Database In-Memory は、リアルタイム分析や混在ワークロードの性能改善を目的とした機能で、テーブル、パーティション、サブパーティション、Materialized View、さらに外部表も In-Memory 化の対象として説明されています。
参考: Use Database In-Memory with Autonomous Database
そのため、In-Memory は「保存先」ではなく、高速化レイヤーとして考えることができます。
また、Oracle Autonomous AI Database では、Lakehouse を高速化する機能 Lake Cache / Data Lake Accelerator (DLA) があります。
Lake Cache と Data Lake Accelerator は、オブジェクトストレージ（OCI Object Storage、AWS S3、Azure Blob、GCPなど）上の外部データを高速にスキャン・クエリするためのコア機能です。両者は「データレイクハウス環境のクエリ高速化」という目的は同じですが、アプローチが異なります。
・高速化レイヤー
| 機能 | 主な役割 | 仕組み | 適したユースケース |
|---|---|---|---|
| In-Memory | Database 内データの分析高速化 | Table、Partition、Materialized View、外部表などを In-Memory Column Store に列形式で保持する | Database 内のホットデータ、繰り返し実行される分析クエリ、集計、JOIN |
| Lake Cache | 外部データの繰り返しアクセス高速化 | 外部表や Mounted Catalog Table の頻繁に使われるデータを Autonomous AI Database 内にローカルキャッシュする | 定期ダッシュボード、定型レポート、同じ外部データを繰り返し参照する分析 |
| Data Lake Accelerator | 大規模な外部データスキャンの高速化 | Oracle-managed VM cluster 上の追加コンピュートにより、外部データの scan / filtering / projection / decompression をオフロードする | 大規模履歴データ、アドホック分析、TB〜PB級の広範囲スキャン |
■ 3. Oracle Autonomous AI Lakehouse とは何か
Oracle Autonomous AI Lakehouse は、Oracle Autonomous AI Database と Apache Iceberg を組み合わせた、オープンでマルチクラウド対応の Lakehouse プラットフォームとして位置づけられています。
この説明で重要なのは、Apache Iceberg です。
Iceberg は、オープンなテーブル形式です。データを特定ベンダーの閉じた形式に閉じ込めるのではなく、複数のエンジンから読み書きしやすい形で管理できるのが大きな特徴です。
そして、Oracle Autonomous AI Database から Iceberg を使う場合、接続方法は実務上、次の 3パターン に整理して考えると分かりやすいです。
-
Direct metadata.json
S3 や Object Storage 上の Iceberg テーブルのmetadata.jsonを直接指定して読む方法 -
Iceberg REST Catalog
Databricks Unity Catalog などの REST Catalog を経由してテーブルを参照する方法 -
Mounted Catalog
Snowflake Open Catalog（Polaris）などの Catalog 全体を Oracle 側にマウントして使う方法
この3つを理解しておくと、Iceberg 接続で技術的に迷いにくくなります。
- 単一テーブルを手軽に読みたい → Direct metadata.json
- Catalog 管理された最新テーブルを標準的に使いたい → Iceberg REST Catalog
- Catalog 全体を Oracle から一覧・参照したい → Mounted Catalog
以下、それぞれを順番に見ていきます。
3-1. Direct metadata.json：まず試すのに一番シンプルな方法
もっともシンプルなのは、Iceberg テーブルの root metadata、つまり metadata.json を直接指定する方法です。
たとえば、AWS S3 上の Iceberg テーブルであれば、metadata.json の URL を DBMS_CLOUD.CREATE_EXTERNAL_TABLE に渡すだけで、Oracle Autonomous AI Database から外部表として問い合わせできます。
-- S3 上の Iceberg テーブルを外部表として定義（metadata.json を直接指定）
BEGIN
DBMS_CLOUD.CREATE_EXTERNAL_TABLE(
table_name => 'CUSTOMERS_ICEBERG_EXT',
credential_name => 'S3_CRED',
file_uri_list => 'https://<bucket>.s3.<region>.amazonaws.com/<path>/metadata/<xxxx>.metadata.json',
format => '{"access_protocol":{"protocol_type":"iceberg"}}'
);
END;
/
-- あとは普通の表と同じように SELECT できる
SELECT COUNT(*) FROM CUSTOMERS_ICEBERG_EXT;
この方法の良いところは、とにかく手軽 なことです。
- Catalog を用意しなくてよい
- 単一テーブルをすぐ読める
- 検証や PoC に向いている
一方で、この方式は 指定した時点のスナップショットを読む 形になります。
つまり、Iceberg テーブルの最新状態に自動追従したい場合には少し不向きです。
そのため、この方式は次のような場面に向いています。
- まず 1 テーブルを読んでみたい
- PoC や動作確認をしたい
- スナップショット固定でも問題ない
3-2. Iceberg REST Catalog：標準的に Catalog 管理された Iceberg を使う方法
次に重要なのが、Iceberg REST Catalog を経由する方法です。
Lakehouse の世界では、単に Object Storage にファイルが置いてあるだけでは不十分です。
どのテーブルがどこにあり、どのスキーマで、どの権限で、どのエンジンから利用できるのか——そうした情報を管理する Catalog が重要になります。
Oracle Autonomous AI Database では、Databricks Unity Catalog などの Iceberg REST 互換 Catalog に接続し、その管理下のテーブルを問い合わせることができます。
この方式の特徴は、次の通りです。
- Catalog 管理されたテーブルを使える
- 最新スナップショットに追従しやすい
- Lakehouse の標準的な運用に乗せやすい
つまり、PoC の次の段階、あるいは実運用で「Iceberg をちゃんと Catalog 管理して使いたい」場合は、この方式が本命になります。
コードのイメージも見てみます。Databricks Unity Catalog を例にすると、format パラメータに REST Catalog の接続情報を指定して外部表を作成します。
-- Databricks の Service Principal（OAuth2）を資格証明として登録
BEGIN
DBMS_CLOUD.CREATE_CREDENTIAL(
credential_name => 'UNITY_OAUTH',
username => '<client_id>',
password => '<client_secret>');
END;
/
-- Unity Catalog の Iceberg REST エンドポイント経由で外部表を作成
BEGIN
DBMS_CLOUD.CREATE_EXTERNAL_TABLE(
table_name => 'CUSTOMERS_ICEBERG',
credential_name => '<オブジェクトストレージの資格証明>',
format => '{
"access_protocol": {
"protocol_type": "iceberg-rest",
"protocol_config": {
"iceberg_catalog_type": "unity",
"rest_catalog_endpoint": "https://<workspace-host>/api/2.1/unity-catalog/iceberg",
"rest_authentication": {
"rest_auth_cred": "UNITY_OAUTH",
"rest_auth_endpoint": "https://<workspace-host>/oidc/v1/token"
},
"table_path": ["<catalog>","<schema>","customers_iceberg"]
}
}
}'
);
END;
/
SELECT COUNT(*) FROM CUSTOMERS_ICEBERG;
Databricks 側で管理されているテーブルに、Oracle 側から普通の SQL で届く——これが「つなげて使う」の実感です。
3-3. Mounted Catalog：Catalog 全体を Oracle から扱う方法
さらに面白いのが、Catalog 自体を Oracle 側にマウントして使う方法 です。
Snowflake Open Catalog（Polaris）では、単一テーブルをその都度定義するのではなく、Catalog 全体を Oracle Autonomous AI Database にマウントできます。
-- Polaris の OAuth2 資格証明を登録（トークン自動リフレッシュ付き）
BEGIN
DBMS_SHARE.CREATE_BEARER_TOKEN_CREDENTIAL(
credential_name => 'POLARIS_OAUTH',
bearer_token => '<初回取得したアクセストークン>',
token_endpoint => 'https://<org>-<account>.snowflakecomputing.com/polaris/api/catalog/v1/oauth/tokens',
client_id => '<client_id>',
client_secret => '<client_secret>',
token_refresh_rate => 3600,
token_scope => 'PRINCIPAL_ROLE:ALL',
grant_type => 'client_credentials');
END;
/
-- Polaris カタログをマウント
BEGIN
DBMS_CATALOG.MOUNT_ICEBERG(
catalog_name => 'MY_POLARIS',
endpoint => 'https://<org>-<account>.snowflakecomputing.com/polaris/api/catalog/v1/<カタログ名>',
catalog_credential => 'POLARIS_OAUTH',
data_storage_credential => '<S3 の資格証明>',
catalog_type => 'ICEBERG_POLARIS');
END;
/
-- マウントしたカタログの中身を、ディクショナリビューのように覗ける
SELECT owner, table_name FROM all_tables@MY_POLARIS;
-- Snowflake が S3 に書いた Iceberg テーブルを、そのまま SELECT
SELECT * FROM "SALES_NS"."CRSK_SALES"@MY_POLARIS;
この方式の特徴は、次の通りです。
- 複数テーブルをまとめて扱いやすい
- Catalog 内のテーブル一覧を Oracle から参照できる
- 単一テーブル接続よりも、Catalog 全体との連携感が強い
たとえば、all_tables@MY_POLARIS のように、Database Link に近い感覚で Catalog 内のテーブル一覧を確認できます。
さらに、Snowflake が S3 上に保持している最新の Iceberg テーブルを、データ移動なしで Oracle 側から参照できます。
この方式は、次のような場面に向いています。
- 1テーブル単位ではなく、Catalog 単位で使いたい
- 複数のテーブルを一覧・探索しながら利用したい
- Snowflake Open Catalog / Polaris との連携を強くしたい
3-4. Iceberg 接続パターンの使い分け
ここまでの 3 パターンを、使い分けの観点でまとめると次のようになります。
| 接続方式 | 向いている用途 | 特徴 |
|---|---|---|
| Direct metadata.json | 単一テーブルをすぐ読みたい、PoC、手軽な検証 | シンプル、軽量、ただし特定スナップショット寄り |
| Iceberg REST Catalog | 実運用、Catalog 管理、最新追従 | 標準的、運用しやすい、Lakehouse らしい構成 |
| Mounted Catalog | 複数テーブル、Catalog 全体の活用、一覧参照 | 可視性が高い、Catalog ごと使える、連携感が強い |
この 3 パターンを理解しておくと、Iceberg 接続を「単なるファイル参照」としてではなく、
どのレベルで Lakehouse とつながるのか
という観点で整理できるようになります。
個人的には、Oracle Autonomous AI Database から見る Iceberg 接続は、
「ファイルを読む」 → 「Catalog を使う」 → 「Catalog を丸ごと使う」
という段階で理解すると、とても分かりやすいです。
■ 4. Autonomous AI Database で広がるデータ接続
Oracle Autonomous AI Lakehouse の面白さは、Object Storage や Iceberg だけではありません。
Autonomous AI Database を中心に見ると、接続できるデータの範囲がかなり広がります。
対象は、クラウドストレージ、SharePoint、SaaS、業務アプリケーション、他社製クラウドデータベース、Oracle Database、外部データカタログなど、多岐にわたります。
さらに、Autonomous AI Database では Oracle-managed heterogeneous connectivity により、
非Oracleデータベースや一部の外部サービスに対して Database Link 経由で問い合わせる構成を取ることができます。
Oracle の製品ページでも、Autonomous AI Lakehouse はオープンテーブル形式や多数のデータベース・アプリケーションソースに接続し、構造化、半構造化、非構造化データをネイティブにサポートする統合分析プラットフォームとして説明されています。
参考: Oracle Autonomous AI Lakehouse
Object Storage / Cloud Storage
まず基本となるのは Object Storage です。
Raw / Bronze のデータ、つまり生ログ、CSV、JSON、Parquet、ORC、Avro、PDF、画像などは、Object Storage に置くのが自然です。Autonomous AI Database からは、外部表や DBMS_CLOUD を通じてこれらのデータを参照できます。
すべてのデータを最初から Database にロードする必要はありません。
必要に応じて、外部表として問い合わせる、ロードして Database Table にする、Materialized View で集計する、といった選択ができます。
たとえば AWS S3 上の Parquet ログを外部表にして、Database 内の顧客表とそのまま JOIN できます。
-- AWS のアクセスキーを資格証明として登録
BEGIN
DBMS_CLOUD.CREATE_CREDENTIAL(
credential_name => 'S3_CRED',
username => '<AWS Access Key ID>',
password => '<AWS Secret Access Key>');
END;
/
-- S3 上の Parquet ファイル群を外部表として定義（列定義は Parquet から自動導出）
BEGIN
DBMS_CLOUD.CREATE_EXTERNAL_TABLE(
table_name => 'SALES_LOG_EXT',
credential_name => 'S3_CRED',
file_uri_list => 'https://<bucket>.s3.<region>.amazonaws.com/sales_logs/*.parquet',
format => '{"type":"parquet","schema":"first"}');
END;
/
-- S3 上のログを、Database 内の顧客表と普通に JOIN
SELECT c.customer_name, SUM(s.amount) AS total_amount
FROM sales_log_ext s
JOIN customers c ON c.customer_id = s.customer_id
GROUP BY c.customer_name;
「S3 のファイル」と「Oracle の表」が、同じ SELECT 文の中に並ぶ。ETL を組む前に、まずこの形で試せるのが Lakehouse らしいところです。
SharePoint
業務データ活用で非常に面白いのが SharePoint 連携です。
多くの企業では、重要な情報がデータベースではなく、SharePoint 上の Word、Excel、PDF、PowerPoint に存在しています。従来、これらは分析基盤から見ると扱いにくいデータでした。
Autonomous AI Database では、DBMS_CLOUD と DBMS_CLOUD_PIPELINE を使って Microsoft SharePoint 上のファイルにアクセスできます。Oracle のドキュメントでは、SharePoint 上のファイルを list / retrieve し、外部コンテンツをダウンロードして後続の分析や索引作成に利用できると説明されています。さらに、DBMS_CLOUD_AI.CREATE_VECTOR_INDEX を使って SharePoint ファイルから直接 Vector Index を作成する例も示されています。
参考: Use DBMS_CLOUD with Microsoft SharePoint
これは Lakehouse の文脈ではかなり重要です。
なぜなら、SharePoint 上の文書を単なるファイルとして放置するのではなく、抽出テキスト、チャンク、Embedding、Metadata として Oracle AI Database 側に取り込み、RAG やセマンティック検索につなげられるからです。
イメージとしては、次のような PL/SQL で SharePoint 上の文書から Vector Index を作成できます。
（パラメータは簡略化しています。詳細は上記ドキュメントを参照してください）
BEGIN
DBMS_CLOUD_AI.CREATE_VECTOR_INDEX(
index_name => 'SHAREPOINT_DOCS_IDX',
attributes => '{"vector_db_provider": "oracle",
"location": "<SharePoint サイトのフォルダ URL>",
"profile_name": "<AI プロファイル名>",
"object_storage_credential_name": "<資格証明名>"}'
);
END;
/
SharePoint の文書群が、SQL の世界からそのままセマンティック検索の対象になる——これは実際に動かしてみると、なかなか感動があります。
セマンティック検索は、キーワードが完全一致する文書を探すのではなく、質問の意味に近い内容を持つ文書を探す仕組みです。RAG は、その検索で見つかった関連チャンクを LLM に渡し、文書の内容を根拠にして自然言語で回答を生成する仕組みです。
つまり、SharePoint 上の文書を抽出テキスト、チャンク、Embedding、Metadata として Oracle AI Database 側に取り込むことで、「文書検索」から一歩進んで、「文書を根拠にした自然言語回答」につなげられます。
このあたりのハンズオンは、また別の記事で「してみてみた」としてまとめたいと思います。
SaaS / 業務アプリケーション
SaaS や業務アプリケーションとの接続も重要です。
Oracle Autonomous AI Lakehouse の Data Studio は、データのロード、変換、分析、共有を支援するセルフサービスのデータエンジニアリング機能として位置づけられています。Oracle の製品ページでは、Data Studio により、100 以上のアプリケーション、クラウドサービス、データベースソースと統合できると説明されています。
参考: Oracle Autonomous AI Lakehouse
また Data Transforms は、Autonomous AI Database 向けにデータロード、データフロー、ワークフローをローコードで設計するための機能です。データロード、結合、フィルタ、集計、マッピング、スケジュール、監視などを GUI ベースで扱えるため、SaaS データや業務アプリケーションデータを Lakehouse に取り込む際の実装手段になります。
参考: About Data Transforms
他社製クラウドデータベース / 異機種間接続
さらに、Autonomous AI Database では Oracle-managed heterogeneous connectivity により、非 Oracle Database への Database Link を作成できます。
Oracle のドキュメントでは、Amazon Redshift、Microsoft SQL Server、Azure SQL、Azure Synapse Analytics、Databricks、Google BigQuery、MongoDB、MySQL、PostgreSQL、Salesforce、ServiceNow、Snowflake、SharePoint などが db_type の例として挙げられています。ただし、この Oracle-managed heterogeneous connectivity は remote database に対して query-only で、更新はサポートされない点に注意が必要です。
参考: Create Database Links to Non-Oracle Databases with Oracle-Managed Heterogeneous Connectivity
この機能により、すべてのデータを物理的に移動しなくても、Oracle AI Database から他社製データベース上のデータを参照し、Oracle 側のデータと組み合わせて分析できます。
たとえば Snowflake への Database Link は、次のように作成できます。
-- 接続先 Snowflake のユーザー資格証明を登録
BEGIN
DBMS_CLOUD.CREATE_CREDENTIAL(
credential_name => 'SNOWFLAKE_LINK_CRED',
username => '<Snowflake ユーザー>',
password => '<パスワード>');
END;
/
-- Oracle-managed heterogeneous connectivity で Database Link を作成
BEGIN
DBMS_CLOUD_ADMIN.CREATE_DATABASE_LINK(
db_link_name => 'SNOWFLAKE_LINK',
hostname => '<Snowflakeアカウント識別子>', -- snowflakecomputing.com は不要（ドライバが付与）
port => '443',
service_name => '<Snowflake のデータベース名>',
credential_name => 'SNOWFLAKE_LINK_CRED',
gateway_params => JSON_OBJECT('db_type' value 'snowflake'),
ssl_server_cert_dn => NULL);
END;
/
-- あとは通常の Database Link と同じ感覚で問い合わせできる（参照のみ）
SELECT * FROM orders@SNOWFLAKE_LINK;
ODBC ゲートウェイのセットアップや証明書の管理は Oracle 側がマネージドで面倒を見てくれるため、利用者から見ると「資格証明を登録して、Link を作るだけ」です。Snowflake が、昔ながらの @db_link 構文の向こう側にいるのは、Oracle 経験者ほどグッとくるところだと思います。
Google BigQuery も同じ枠組みで接続できます。BigQuery の場合は OAuth2 タイプの資格証明を使い、gateway_params に project を指定します。
-- BigQuery は OAuth2 タイプの資格証明を使う
BEGIN
DBMS_CLOUD.CREATE_CREDENTIAL(
credential_name => 'BIGQUERY_LINK_CRED',
params => JSON_OBJECT(
'gcp_oauth2' value JSON_OBJECT(
'client_id' value '<client_id>',
'client_secret' value '<client_secret>',
'refresh_token' value '<refresh_token>')));
END;
/
-- Database Link を作成（project の指定が必須）
BEGIN
DBMS_CLOUD_ADMIN.CREATE_DATABASE_LINK(
db_link_name => 'GOOGLE_BIGQUERY_LINK',
hostname => 'example.com', -- BigQuery では hostname は使用されない
port => '443',
service_name => '<BigQuery のデータセット名>',
credential_name => 'BIGQUERY_LINK_CRED',
gateway_params => JSON_OBJECT(
'db_type' value 'google_bigquery',
'project' value '<GCP プロジェクト名>'),
ssl_server_cert_dn => NULL);
END;
/
-- BigQuery / MySQL / PostgreSQL では表名を二重引用符で囲む
SELECT count(*) FROM "sales"@GOOGLE_BIGQUERY_LINK;
対応データベースは Snowflake、BigQuery のほか、Amazon Redshift、Azure SQL / Synapse、PostgreSQL、MySQL、MongoDB、Databricks など多数あります。ちょっとした Tips ですが、接続タイプごとのサンプルコードは Database 内のビューからも確認できます。
-- 各 db_type のサンプル PL/SQL が SAMPLE_USAGE 列に入っている
SELECT * FROM HETEROGENEOUS_CONNECTIVITY_INFO
WHERE DATABASE_TYPE = 'google_bigquery';
なお、Oracle-managed heterogeneous connectivity は 参照専用（query-only） で、リモート側への更新はできない点には注意してください。
これは Lakehouse の考え方を広げます。
従来は、
データを集めてから分析する
という考え方が中心でした。
しかし Autonomous AI Lakehouse では、
必要なデータを、必要な形で、Oracle AI Database からつなげて使う
という発想ができます。
ただし、Database Link で外部 DB を参照できるからといって、すべての処理を毎回リモート参照にする必要はありません。
性能、コスト、再利用性、安定性を考えると、よく使うデータは Oracle AI Database 側に取り込む設計も有効です。
たとえば、Snowflake、BigQuery、Redshift、PostgreSQL などの外部 DB 上のデータを、まず Database Link 経由で参照し、必要な範囲だけ INSERT INTO ... SELECT や CREATE TABLE AS SELECT で Oracle 側に取り込むことができます。
外部DB上のデータを Oracle AI Database 側に取り込むイメージ
CREATE TABLE sales_from_snowflake
AS
SELECT * FROM sales@SNOWFLAKE_LINK
WHERE sales_date >= DATE '2026-01-01';
このようにして Oracle AI Database 側に取り込めば、Oracle の SQL、索引、View、Materialized View、In-Memory、Vector Search、AI 機能と組み合わせやすくなります。
さらに、参照中心の分析データであれば、Hybrid Columnar Compression などの列型圧縮を使うことで、容量を抑えながら分析用データとして保持できます。
つまり、外部 DB 接続は次のように段階的に考えると分かりやすいです。
まず試す
→ Database Link で外部 DB を直接 SELECT
よく使う
→ INSERT INTO ... SELECT / CTAS で Oracle 側に取り込む
分析で繰り返し使う
→ View / Materialized View / In-Memory / HCC などで最適化
AI / RAG で使う
→ Chunk / Embedding / VECTOR Table / Metadata Table として AI-ready 化
Database Link は「外部 DB をそのまま使う入口」であり、Oracle AI Database 側に取り込むことで、さらに高速化・再利用・AI活用へ広げることができます。
■ 5. どこに何を置くべきか
ここまで見てくると、扱えるデータと接続先がかなり広いことが分かります。
では実際に、どこに何を置くべきでしょうか。
私の整理では、Oracle Autonomous AI Lakehouse におけるデータ配置は、次の考え方が分かりやすいです。
| データ / レイヤー | 推奨配置 | 理由 |
|---|---|---|
| Raw / Bronze | Object Storage、Iceberg、Parquet、CSV、JSON、PDF | 原本性、低コスト、大量保存、再処理に向く |
| 生ログ / イベント / 履歴データ | Object Storage、Iceberg | 増え続けるデータをそのまま保持しやすい |
| 半構造化 JSON の原本 | Object Storage または External Table | まず原本を残し、必要に応じて構造化する |
| 頻繁に JOIN / 検索する JSON | Oracle AI Database の JSON 列 / Table | SQL、索引、View、トランザクションと組み合わせやすい |
| Cleaned / Silver | Database Table または Iceberg Table | 品質保証済みデータとして再利用しやすい |
| Curated / Gold | Table、View、Materialized View、Analytic View | BI、KPI、業務レポートに使いやすい |
| 高頻度分析データ | In-Memory、Materialized View、Lake Cache / Table Cache | レスポンス改善、ダッシュボード高速化 |
| PDF / Word / 画像などの原本 | SharePoint、Object Storage | 原本管理、監査、再処理に向く |
| 抽出テキスト | Database Table / CLOB | 検索、要約、チャンク化の元データ |
| チャンク | Database Table | RAG の検索単位として管理 |
| Embedding | VECTOR 列を持つ Database Table | 業務データと一緒にセマンティック検索できる |
| Metadata | Database Table | ファイル名、URL、権限、作成日、部門などを管理 |
| Feature / AI-ready | Feature Table、VECTOR Table、View、Materialized View | ML、AI、RAG、推論で再利用しやすい |
| 他社 DB の参照データ | Database Link / Heterogeneous Connectivity | 移動せずに参照・結合できる |
| SaaS データ | Data Studio / Data Transforms でロードまたは連携 | 定期連携、変換、業務データ化に向く |
この表をさらにシンプルにまとめると、次のようになります。
Raw / Bronze
→ Object Storage / Iceberg / SharePoint / 外部ストレージ
Cleaned / Silver
→ Database Table または Iceberg Table
Curated / Gold
→ Table / View / Materialized View / Analytic View
Performance Layer
→ In-Memory / Lake Cache / Table Cache / Materialized View
AI-ready
→ VECTOR / Embedding / Chunk / Metadata / Feature Table
ここでのポイントは、構造化データだから必ず Database、非構造化データだから必ず Object Storage と固定しないことです。
より実践的には、次の基準で考えるとよいです。
原本・大量・低頻度アクセスのデータは Lakehouse ストレージへ
ログ、履歴ファイル、PDF 原本、画像、JSON 原本、Parquet ファイルなどは、Object Storage や Iceberg に置くのが自然です。
これらは、あとで再処理したり、監査用に残したり、別のエンジンからも使う可能性があるため、オープンな形式で保持しておく価値があります。
品質保証済み・再利用されるデータは Database Table または Iceberg Table へ
クレンジング済み、型変換済み、重複排除済み、業務キーで結合済みのデータは、Silver レイヤーとして扱います。
Oracle AI Database で高速に JOIN、検索、AI 処理したい場合は Database Table にするのが自然です。一方で、複数エンジンから共有したい大規模分析データであれば Iceberg Table として管理する選択もあります。
BI・KPI・ダッシュボード用データは Gold として整理する
経営指標、部門別売上、顧客セグメント、在庫回転率、SLA、利用状況など、業務利用されるデータは Gold レイヤーとして整理します。
ここでは、Table、View、Materialized View、Analytic View が候補になります。高頻度に使われる集計は Materialized View、低頻度だが定義を共通化したいものは View、性能要件が高いものは In-Memory などを検討します。
AI-ready データは Database 側に寄せると扱いやすい
生成 AI / RAG で使う場合、原本ファイルそのものよりも、次のような派生データが重要になります。
| AI-ready データ | 内容 |
|---|---|
| Extracted Text | PDF や Word から抽出したテキスト |
| Chunk | RAG で検索しやすい単位に分割したテキスト |
| Embedding | Chunk や文書をベクトル化したもの |
| Metadata | 文書名、URL、権限、カテゴリ、作成日、部門 |
| VECTOR Index | セマンティック検索用の索引 |
| Text Index | キーワード検索・全文検索用の索引 |
| Access Control Metadata | 部門、所有者、閲覧権限、SharePoint URL、公開範囲 |
Oracle AI Database では、Embedding を VECTOR データ型として業務データと同じ Database に格納できます。これにより、セマンティック検索だけでなく、顧客、契約、製品、問い合わせ、権限情報などの構造化データと組み合わせた RAG を設計しやすくなります。
参考: Oracle AI Vector Search Overview
たとえば、SharePoint 上の技術文書を RAG 化する場合は、次のような配置が考えられます。
SharePoint
- Word
- PDF
- Excel
- PowerPoint
↓ DBMS_CLOUD / DBMS_CLOUD_PIPELINE
Oracle AI Database
- Document Metadata Table
- Extracted Text Table
- Chunk Table
- Embedding Table with VECTOR column
- Vector Index
- Text Index
↓
Select AI / RAG Application / Chatbot / BI / Search
この構成では、SharePoint は文書原本の置き場であり、Oracle AI Database は検索・分析・AI 活用のための実行基盤になります。
■ 6. まとめ：Lakehouse は「集める基盤」から「つなげて使う基盤」へ
Lakehouse というと、最初は「Data Lake と Data Warehouse を組み合わせたもの」と説明されることが多いです。
しかし、Oracle Autonomous AI Lakehouse の文脈で見ると、それだけでは少し物足りません。
Oracle Autonomous AI Lakehouse の面白さは、Object Storage や Iceberg にデータを置けることだけではありません。Oracle AI Database を中心に、構造化データ、半構造化データ、非構造化データ、SharePoint、SaaS、他社製クラウドデータベース、外部表、Database Link、Vector Search、BI、AI、RAG をつなげて使えるところにあります。
従来の発想では、分析するためにはまずデータを 1 か所に集める必要がありました。
もちろん、今でもデータを集めて整えることは重要です。特に Curated / Gold や AI-ready のように、品質と再利用性が求められるデータは、Oracle AI Database 側に整理しておく価値があります。
しかし、すべてのデータを無理に移動する必要はありません。
原本は Object Storage や SharePoint に置く。
大規模なオープン分析データは Iceberg に置く。
業務で頻繁に使うデータは Database Table に置く。
BI 用のデータは View や Materialized View にする。
高速化したいデータは In-Memory や Cache を使う。
生成 AI で使うデータは Chunk、Embedding、Metadata として AI-ready にする。
このように考えると、Lakehouse は単なる「データを集める基盤」ではなくなります。データをどこに置き、どの形にし、どのタイミングで Database に寄せるか——その 判断軸 が Lakehouse 設計の中心になります。
Oracle Autonomous AI Lakehouse は、その判断軸を Oracle AI Database の強みと組み合わせて実現しようとしているアーキテクチャです。
特に Oracle ユーザーにとっては、既存の Oracle Database 資産、SQL、View、Materialized View、セキュリティ、ガバナンス、In-Memory、JSON、Spatial、Graph、Vector Search を活かしながら、Object Storage、Iceberg、SharePoint、SaaS、他社製データベースへ広げていける点が大きな魅力です。
次の章では、この判断軸を実際の配置パターンとして一覧にまとめます。
■ 最後に：Oracle Autonomous AI Lakehouse は “全てをつなぐ” データ基盤へ
最後に、この記事の要点を一枚でまとめると次のようになります。
| 判断軸 | 配置先 |
|---|---|
| 原本を残したい | Object Storage / SharePoint / Iceberg |
| 大量データを低コストで保持したい | Object Storage / Iceberg |
| 複数エンジンで共有したい | Iceberg / Open Table Format |
| SQL で頻繁に JOIN したい | Oracle AI Database Table |
| JSON を業務データと一緒に扱いたい | Oracle AI Database JSON |
| BI / KPI に使いたい | View / Materialized View / Analytic View |
| 高速化したい | In-Memory / Lake Cache / Table Cache |
| RAG に使いたい | Chunk Table / VECTOR Table / Metadata Table |
| 他社 DB を参照したい | Database Link / Heterogeneous Connectivity |
| SaaS データを取り込みたい | Data Studio / Data Transforms |
| SharePoint 文書を検索したい | DBMS_CLOUD / DBMS_CLOUD_AI / Vector Index |
Oracle Autonomous AI Lakehouse を考えるときのキーワードは、
「集める」だけでなく「つなげて使う」 です。
そして Oracle らしいポイントは、
つなげた先で Oracle AI Database の SQL、AI、Vector、JSON、Graph、Spatial、ガバナンスを使えること
にあります。
ここからは、今回いろいろ調べて実際にコードを書いてみた、個人的な感想です。
個人的に今回一番強く感じたのは、Oracle Autonomous AI Lakehouse は、単なる Lakehouse 機能ではなく、All-Platform なデータ基盤 として、これからの AI 時代にあるべき姿に近づいているということです。
これまでデータ活用では、どのクラウドに置くか、どのストレージに置くか、どの分析エンジンで処理するか、どの AI 基盤に渡すかを、それぞれ個別に考える必要がありました。
しかし、Oracle Autonomous AI Lakehouse では、OCI だけでなく、Azure、Google Cloud、AWS まで含めて、分散したデータを Oracle AI Database からつなげて使うという考え方ができます。
Object Storage、Iceberg、SharePoint、SaaS、Databricks、Snowflake、BigQuery、他社 DB、そして Oracle Database。
これらを別々の世界として扱うのではなく、Oracle AI Database の SQL、View、Database Link、外部表、Vector Search、Select AI、RAG、ガバナンスの世界に引き寄せて使える。
ここが本当に面白いところです。
Oracle Autonomous AI Lakehouse は、データを一か所に無理やり集めるためのものではなく、全てをつなぐもの だと思います。
そして、つないだ先で SQL も BI も AI も RAG も使える。
Oracle Database を長く触ってきた人ほど、この進化にはグッとくるものがあるはずです。
Oracle Autonomous AI Lakehouse は、AI 時代の “全てをつなぐ” Oracle データ基盤 なのだと思います。
さて、ここまでで「バラバラなデータをつなげて使えるようにする」ところまで整理できました。
次に気になるのは、つないだデータを使って、実際に何ができるのか です。
Select AI で自然言語から SQL を生成したり、Private Agent Factory でエージェントを組んだり、APEX でアプリケーションを作ったり——
このあたりは、また別の記事で「してみてみた」としてまとめたいと思います。
■ 技術解説
■ 参考資料
-
Create Database Links to Non-Oracle Databases with Oracle-Managed Heterogeneous Connectivity
-
Using DBMS_DCAT with OCI Data Catalog / AWS Glue / Iceberg REST Catalogs
-
Query Databricks Native Iceberg Tables from Oracle Autonomous AI Database
-
Step-by-Step Guide to Querying Data in Snowflake Using Autonomous Database
■ おまけ
