@shirok(Shiro Kobayashi)Team Energy Drinkin

S3上の大量ログを Oracle Autonomous AI Lakehouseで分析する：外部表、Parquet、SQL、Vector Search、RAGの使い分け

Last updated at 2026-07-14Posted at 2026-07-13

AWS S3上に大量のログがあり、Amazon Athenaで検索・分析している環境に対して、Oracle Autonomous Database / Autonomous AI Lakehouseを使ってさらに AI分析できないか、という相談を受けることがあります。

たとえば、S3上に以下のようなログがあるケースです。

Amazon Aurora / RDSのError Log
Slow Query Log
DB Audit Log
OS Log
Application Log
CloudTrailなどの操作監査ログ
Jiraの障害チケット、変更チケット、対応履歴

このとき、最初に誤解しやすいのが、

AI Databaseを使うなら、すべてのログをVector Storeに入れてRAGするのでは？

という考え方です。
結論から言うと、すべてのログをVector化してRAGする必要はありません。
ログのような大量・時系列・構造化しやすいデータは、まずSQLで扱うのが基本です。そのうえで、エラーメッセージ、スタックトレース、Jiraコメント、障害対応メモなど、意味検索が必要なテキストだけをVector Search / RAGの対象にするのが現実的です。

この記事では、以下の流れで整理します。

1. まず用語整理
2. S3ログをOracle Autonomous Databaseから読む方法
3. Raw Log直接参照とCurated Parquet参照の違い
4. Curated Parquetは「ログ種別ごと」に作る
5. パーティション設計
6. 外部表を高速化する3つの選択肢：Lake Cache、Data Lake Accelerator、Gold Data
7. SQLでやるべきこと
8. Vector Searchでやるべきこと
9. RAGでやるべきこと
10. おすすめHybrid構成
11. PoCで確認するポイント

なお、本記事では Oracle Autonomous AI Database を総称して ADB と表記します。Lakehouse文脈の話をする場合のみ、Autonomous AI Lakehouseと記載します。

ADBでは、Object Storage上のファイルにアクセスするためにCredentialを登録し、DBMS_CLOUD.CREATE_EXTERNAL_TABLEで外部表を作成できます。Amazon S3上のデータもこの外部表アクセスの対象にできます。
参考: Query External Data with Autonomous Database

1. まず用語整理

S3、Athena、Glue、ADB、AI Lakehouseの話をしていると、次の言葉が混ざりやすいです。

データ
スキーマ
メタデータ
カタログ

データ

データは、実際の中身です。

たとえば、S3にある以下のParquetファイルの中身です。

s3://log-bucket/curated/rds_audit_log/dt=2026-07-06/hour=00/part-0001.snappy.parquet

ログ1行1行、Audit Event、SQL実行履歴、エラー行などがデータです。

スキーマ

スキーマは、データの構造です。

たとえば、RDS Audit Logを以下のような列で扱うなら、これがスキーマです。

event_time      TIMESTAMP
db_identifier   VARCHAR2
user_name       VARCHAR2
client_ip       VARCHAR2
operation       VARCHAR2
object_name     VARCHAR2
return_code     VARCHAR2
message         VARCHAR2

つまり、スキーマは、

どんな列があるか
各列のデータ型は何か
どの列が日時か
どの列が文字列か
どの列が数値か

を定義するものです。

メタデータ

メタデータは、データを読むための説明情報です。

たとえば、以下のような情報です。

データの場所:
  s3://log-bucket/curated/rds_audit_log/

ファイル形式:
  Parquet

圧縮形式:
  Snappy

列定義:
  event_time, user_name, operation, message

パーティション:
  dt, hour

スキーマバージョン:
  v1

パーサーバージョン:
  rds_audit_parser_v3

重要なのは、スキーマはメタデータの一部ということです。

メタデータ
  ├─ スキーマ情報
  │  ├─ 列定義
  │  ├─ データ型
  │  ├─ NULL可否
  │  └─ スキーマバージョン
  │
  ├─ 保存場所・ファイル情報
  │  ├─ S3の場所
  │  ├─ ファイル形式
  │  ├─ 圧縮形式
  │  ├─ パーティション情報
  │  ├─ 更新日時
  │  └─ サイズ
  │
  ├─ 処理情報
  │  ├─ パーサーバージョン
  │  ├─ 生成ジョブ名
  │  └─ 取込日時
  │
  └─ 管理情報
     ├─ 権限
     ├─ 所有者
     ├─ タグ
     └─ 説明

このように、スキーマ情報はメタデータの一部です。
メタデータには、列定義だけでなく、S3上の保存場所、ファイル形式、圧縮形式、パーティション、生成ジョブ、権限やタグなど、データを管理・利用するための情報も含まれます。

カタログ

カタログは、メタデータを管理する台帳です。

代表例は以下です。

カタログ	役割
AWS Glue Data Catalog	Athenaがよく使うメタデータ台帳
Oracle Data Dictionary	Oracle Database内部のメタデータ台帳
Iceberg Catalog	Iceberg Tableのメタデータ台帳
Hive Metastore	Hadoop / Spark系のメタデータ台帳
自作カタログ表	ADB内に自分で作る軽量メタデータ管理表

Athenaでは、AWS Glue Data Catalogを使ってS3上のデータに対するデータベース、テーブル、スキーマ情報を管理できます。また、Glue Crawlerを使うとS3上のデータからスキーマを推定できます。
参考: Using AWS Glue Data Catalog with Athena

一方、Glueを使わずにADBからS3を直接読む場合は、Oracle側の外部表定義としてメタデータを作成します。

Parquetとカタログの関係

Parquetは、データ本体だけでなく、列名、データ型、Row Group、列ごとの統計情報、圧縮方式などのメタデータをファイル内部に保持する列指向ファイル形式です。

一方、Object Storage上の保存場所、パーティション、複数ファイルをまとめたテーブル定義、権限、説明などは、パス構造や外部表定義、Glue Data Catalog、Iceberg Catalogなど、Parquetファイルの外側で管理されます。

つまり、Parquetは「データとファイル内部のメタデータ」を持ち、カタログは「複数のParquetファイルをテーブルとして管理するメタデータ」を持つ、と整理できます。

2. S3ログをOracle Autonomous Databaseから読む方法

ADBからS3ログを読む基本形は、DBMS_CLOUD.CREATE_EXTERNAL_TABLEです。

ざっくり言うと、以下を指定します。

1. どこにあるか
   → S3のファイルパス / prefix / URI

2. どう読むか
   → CSV, JSON, Parquet, 圧縮形式, 区切り文字など

3. どんな列として見せるか
   → column_list、またはParquet内のスキーマ情報

Oracleのドキュメントでは、Cloud上のファイルを問い合わせる場合、Object Storageの資格情報をデータベースに保存し、その後 DBMS_CLOUD.CREATE_EXTERNAL_TABLE で外部表を作成する流れが説明されています。
参考: Query External Data with Autonomous Database

Credentialを作成する

S3にアクセスするためのCredentialをOracle側に登録します。

BEGIN
  DBMS_CLOUD.CREATE_CREDENTIAL(
    credential_name => 'AWS_S3_CRED',
    username        => '<AWS_ACCESS_KEY_ID>',
    password        => '<AWS_SECRET_ACCESS_KEY>'
  );
END;
/

なお、上記はアクセスキー方式の例です。
DBMS_CLOUD.CREATE_CREDENTIALは、paramsパラメータでAWS IAMロールのARN（aws_role_arn）を指定するロールベース認証もサポートしています。

BEGIN
  DBMS_CLOUD.CREATE_CREDENTIAL(
    credential_name => 'AWS_S3_CRED_ARN',
    params          => JSON_OBJECT(
      'aws_role_arn'     value 'arn:aws:iam::123456789012:role/ADB_S3_READ_ROLE',
      'external_id_type' value 'database_ocid'
    )
  );
END;
/

長期有効なアクセスキーをデータベースに保存せずに済み、AWS側のRoleとPolicyでアクセス範囲を制御できるため、本番ではロールARN方式を推奨します。事前にADB側でのARN利用有効化と、AWS側でのRole / Policy / Trust Relationshipの設定が必要です。
参考: Use Amazon Resource Names (ARNs) to Access AWS Resources

いずれの方式でも、本番では権限を絞ったIAM Role / Policy、ネットワーク制御、鍵管理、監査を含めて設計する必要があります。

CSV / Textログを外部表として読む

CSVやテキストログの場合、ファイル自体に明確なスキーマがないことが多いため、Oracle側でカラム定義を指定します。

BEGIN
  DBMS_CLOUD.CREATE_EXTERNAL_TABLE(
    table_name      => 'EXT_RDS_AUDIT_LOG',
    credential_name => 'AWS_S3_CRED',
    file_uri_list   => 'https://log-bucket.s3.ap-northeast-1.amazonaws.com/raw/rds_audit/2026/07/06/audit.csv',
    column_list     => '
      event_time      VARCHAR2(50),
      db_identifier   VARCHAR2(128),
      user_name       VARCHAR2(128),
      client_ip       VARCHAR2(64),
      operation       VARCHAR2(64),
      object_name     VARCHAR2(512),
      return_code     VARCHAR2(64),
      message         VARCHAR2(4000)
    ',
    format          => '{
      "type":"csv",
      "delimiter":",",
      "skipheaders":1
    }'
  );
END;
/

作成後は、通常の表のようにSQLでアクセスできます。

SELECT
  event_time,
  db_identifier,
  user_name,
  operation,
  message
FROM ext_rds_audit_log
WHERE operation = 'DROP';

このとき、データ本体はS3に残ったままです。
Oracle側には、S3の場所、ファイル形式、カラム定義などの外部表メタデータが登録されます。

Parquetの場合

Parquetの場合は、CSVやテキストログと少し違います。

Parquet、ORC、Avroはファイル内にメタデータを持っており、ADBでは DBMS_CLOUD.CREATE_EXTERNAL_TABLE がこのメタデータを利用して外部表作成を簡素化できます。
参考: Query External Data in Parquet, Avro, or ORC Format

たとえば、Parquetファイルを外部表にする場合は、以下のようにできます。

BEGIN
  DBMS_CLOUD.CREATE_EXTERNAL_TABLE(
    table_name      => 'EXT_RDS_AUDIT_PARQUET',
    credential_name => 'AWS_S3_CRED',
    file_uri_list   => 'https://log-bucket.s3.ap-northeast-1.amazonaws.com/curated/rds_audit_log/*.parquet',
    format          => '{
      "type":"parquet",
      "schema":"first"
    }'
  );
END;
/

この場合、Parquetファイル内のスキーマ情報を利用して、Oracle側の列定義を作成できます。

3. Raw Log直接参照とCurated Parquet参照の違い

S3ログをOracleから読む方法には、大きく2つあります。

方式A:
  Raw Logを直接外部表として読む

方式B:
  Raw LogをCurated Parquetに変換してから読む

今回のような大量ログ分析では、PoCではRaw Log直接参照、本番分析ではCurated Parquet参照と考えるのが現実的です。

3.1 直接Raw Log外部表参照

Raw Log直接参照は、S3上のCSV、JSON、テキストログをそのまま外部表として読む方式です。

S3 Raw Log
  ↓
DBMS_CLOUD外部表
  ↓
SQL検索

向いている用途は以下です。

PoC
簡易調査
ログ形式が比較的きれい
CSV / JSONとして読める
対象ログ種類が少ない
対象期間が限定されている

たとえば、アプリログをまず1行テキストとして読み、SQLの LIKE や REGEXP_SUBSTR で調査することもできます。

SELECT
  message
FROM ext_raw_app_log
WHERE message LIKE '%Exception%'
   OR message LIKE '%timeout%';

Oracle Databaseに接続するアプリケーションのログであれば、message LIKE '%ORA-%' のようなOracleエラーコード検索も有効です。

ただし、Raw Log直接参照には限界があります。

マルチラインログに弱い
スタックトレースの扱いが難しい
ログ形式が途中で変わると壊れやすい
timestampやseverityの抽出が都度必要
大量分析では性能や保守性が厳しい
JiraとのJOINやAI分析に使いにくい

そのため、Raw Log直接参照は「まず読めるか確認する」用途に向いています。

3.2 Curated Parquet外部表参照

Curated Parquet参照は、Raw Logを事前に整形して、分析しやすいParquet形式に変換してからOracleで読む方式です。

S3 Raw Log
  ↓
ETL / Parser
  ↓
S3 Curated Parquet
  ↓
Oracle外部表
  ↓
SQL / Vector Search / RAG

Parquet化には、Athena CTAS、AWS Glue Spark ETL、EMR / Spark、Lambda / ECS / Batchなどを使えます。

AthenaのCTASは、クエリ結果から新しいテーブルを作成する機能で、ソーステーブルを別形式のテーブルに変換する用途にも使えます。AthenaではCTASでParquet形式を指定することもできます。
参考: CREATE TABLE AS - Amazon Athena

たとえば、Athena CTASでRawログをParquet化するイメージです。

CREATE TABLE curated_rds_audit_log
WITH (
  external_location = 's3://log-bucket/curated/rds_audit_log/',
  format = 'PARQUET',
  parquet_compression = 'SNAPPY',
  partitioned_by = ARRAY['dt', 'hour']
) AS
SELECT
  event_time,
  db_identifier,
  user_name,
  client_ip,
  operation,
  object_name,
  return_code,
  message,
  date_format(event_time, '%Y-%m-%d') AS dt,
  date_format(event_time, '%H')       AS hour
FROM raw_rds_audit_log;

なお、Athena CTASには1クエリで作成できるパーティションが100までという制限があります。大量の過去ログを初回変換する場合は、CTASでテーブルを作成した後に INSERT INTO で期間を分割して投入するか、Glue ETLの利用を検討してください。
参考: Use CTAS and INSERT INTO to work around the 100 partition limit

AWS Glueでも、S3上のデータをParquetへ変換するETLジョブを構成できます。AWSのPrescriptive Guidanceでは、AWS Glueの複数のジョブタイプを使ってS3データをApache Parquetへ変換するパターンが紹介されています。
参考: Use AWS Glue ETL jobs to convert data to Apache Parquet

4. Curated Parquetは「ログ種別ごと」に作る

大量ログをParquet化するときは、1つの巨大なテーブルにすべてを押し込むより、まずログ種別ごとにCurated Parquetデータセットを作るのがよいです。

s3://log-bucket/curated/
  rds_error_log/
  rds_audit_log/
  aurora_slow_query_log/
  os_syslog/
  app_log_event/
  cloudtrail_event/

たとえば、RDS Audit LogとSlow Query Logではカラムが大きく違います。
無理に1つのテーブルへまとめると、NULLだらけになり、保守しづらくなります。

そのため、まずは以下のようにログ種別ごとの詳細テーブルを作ります。

Curatedテーブル	内容
`rds_error_log`	RDS / Auroraエラーログ
`rds_audit_log`	DB監査ログ
`aurora_slow_query_log`	Slow Queryログ
`os_syslog`	OSログ
`app_log_event`	アプリケーションログ
`cloudtrail_event`	AWS API操作ログ

さらに、Jira連携やAI分析用に、全ログ横断用の共通テーブルも作ります。

log_event_common

共通ログテーブルのスキーマ例です。

event_time
source_type
aws_account_id
region
environment
service_name
host_name
db_identifier
severity
user_name
client_ip
operation
object_name
error_code
message
normalized_message
trace_id
request_id
raw_s3_uri
parser_version
schema_version
attributes_json

ポイントは、すべてのログ固有項目を無理に列にしないことです。
ログ種別ごとにしか使わない項目は、attributes_json のような列に逃がす設計も有効です。

5. パーティション設計

Curated Parquetでは、S3 prefixをHive形式にしておくと扱いやすくなります。

s3://log-bucket/curated/log_event_common/
  source_type=rds_error/dt=2026-07-06/hour=00/part-0001.snappy.parquet
  source_type=rds_error/dt=2026-07-06/hour=01/part-0002.snappy.parquet
  source_type=rds_audit/dt=2026-07-06/hour=00/part-0003.snappy.parquet
  source_type=app_log/dt=2026-07-06/hour=00/part-0004.snappy.parquet

パーティションキーは、まず以下で十分です。

source_type
dt
hour

必要に応じて、以下を追加します。

aws_account_id
region
environment
service_name

ただし、以下のようなカーディナリティが高すぎる項目は、安易にパーティションキーへ含めない方がよいです。

host_name
user_name
trace_id
request_id
customer_id

パーティションを細かくしすぎると、小さいファイルやフォルダ、メタデータが増え、かえって検索や運用が複雑になります。

5.1 暗黙的パーティション化とは

Autonomous AI Databaseでは、Object Storage上の階層的なフォルダ構造からパーティション列と値を導出する、暗黙的パーティション化を利用できます。

たとえば、次のS3パスを考えます。

s3://log-bucket/curated/log_event_common/
  source_type=rds_error/
    dt=2026-07-06/
      hour=00/
        part-0001.snappy.parquet

このパスには、次のパーティション情報が含まれています。

source_type = rds_error
dt          = 2026-07-06
hour        = 00

source_type、dt、hourがParquetファイル内の列として保存されていない場合でも、ADBはフォルダ名から列と値を導出できます。

source_type=rds_error
  ├─ 列名: source_type
  └─ 値:   rds_error

dt=2026-07-06
  ├─ 列名: dt
  └─ 値:   2026-07-06

暗黙的パーティション化では、パーティション列と値が問合せ実行時に検出されます。また、S3上でファイルやフォルダが追加・削除された場合も、Object Storage構造の変更を実行時に検出できます。

新しいログファイルをS3へ追加
  ↓
外部表の再作成やパーティション同期は不要
  ↓
次回の問合せ時に新しいファイルを検出

明示的な外部パーティション表で必要になる同期処理を省略できるため、ログのようにファイルが継続的に追加されるデータと相性がよいです。

さらに、SQLでパーティション列を絞り込むと、ADBは関連するObject Storage上のファイルだけへアクセスします。

SELECT
  service_name,
  error_code,
  COUNT(*) AS error_count
FROM ext_log_event_common
WHERE source_type = 'rds_error'
  AND dt = '2026-07-06'
  AND hour = '00'
GROUP BY
  service_name,
  error_code;

このSQLでは、主に次のパスに該当するファイルが検索対象になります。

source_type=rds_error/
  dt=2026-07-06/
    hour=00/

全期間・全ログ種別のファイルを読み取らずに済むため、Object Storageから読み取るデータ量とクエリ時間を削減できます。

5.2 Hive形式とPath Tail形式

暗黙的パーティション化では、主に次の2つのフォルダ形式を利用できます。

Hive形式

Hive形式では、フォルダ名にパーティション列名と値を含めます。

<table>/
  source_type=rds_error/
    dt=2026-07-06/
      hour=00/
        part-0001.parquet

=の左側が列名、右側が値として認識されます。

source_type=rds_error
列名        値

パスを見ただけでデータの内容を理解でき、AthenaやAWS GlueなどのAWSサービスとも連携しやすいため、今回のログ分析ではHive形式を利用するのがわかりやすいです。

Path Tail形式

Path Tail形式では、フォルダ名に値だけを格納します。

<table>/
  rds_error/
    2026-07-06/
      00/
        part-0001.parquet

この場合、パスだけでは各値が何を表しているか判断できないため、外部表の定義でパーティション列を順番どおりに指定します。

1番目のフォルダ:
  source_type

2番目のフォルダ:
  dt

3番目のフォルダ:
  hour

Path Tail形式では、フォルダの値の順番と、指定するパーティション列の順番を一致させる必要があります。

5.3 Hive形式の暗黙的パーティション外部表を作成する

Hive形式のS3データを、暗黙的パーティション化された外部表として作成する例です。

BEGIN
  DBMS_CLOUD.CREATE_EXTERNAL_TABLE(
    table_name      => 'EXT_LOG_EVENT_COMMON',
    credential_name => 'AWS_S3_CRED',
    file_uri_list   =>
      'https://log-bucket.s3.ap-northeast-1.amazonaws.com/curated/log_event_common/*.parquet',
    format          => '{
      "type":"parquet",
      "schema":"first",
      "implicit_partition_config":{
        "partition_type":"hive",
        "partition_columns":[
          "source_type",
          "dt",
          "hour"
        ],
        "strict_column_order":true
      }
    }'
  );
END;
/

implicit_partition_configでは、以下を指定しています。

partition_type:
  hive

partition_columns:
  パスから導出するパーティション列と順序

strict_column_order:
  Hive形式のパーティション列が固定順序で存在することを前提に、
  Object Storageのパス検索計画を最適化

Parquet、Avro、ORCのような構造化ファイルでは、ファイル内のスキーマを利用できるため、column_listを省略できます。パーティション列は、partition_columnsで指定したS3パスから導出されます。

作成した外部表に対しては、通常の表と同じように問い合わせられます。

SELECT
  source_type,
  dt,
  hour,
  service_name,
  error_code,
  COUNT(*) AS error_count
FROM ext_log_event_common
WHERE source_type = 'rds_error'
  AND dt = '2026-07-06'
  AND hour BETWEEN '00' AND '06'
GROUP BY
  source_type,
  dt,
  hour,
  service_name,
  error_code
ORDER BY
  error_count DESC;

このSQLでは、指定したsource_type、dt、hourに該当するパーティションのファイルだけを対象にできます。

なお、file_uri_listでワイルドカードを使用する場合、ワイルドカードは最後のスラッシュ/より後ろに指定します。

5.4 `strict_column_order`を使う場合の注意点

strict_column_order=trueは、非常に多くのファイルやサブフォルダを持つHive形式のデータで、問合せ実行前のパス一覧取得や計画時間を短縮するための最適化です。

ADBは、あらかじめ定義されたパーティション列の順番を利用して、検索条件に関係しないディレクトリを早い段階でスキップできます。

ただし、すべてのS3パスでパーティション列が同じ順番に並び、途中の列が欠落しない場合にのみtrueを指定します。

source_type=<value>/dt=<value>/hour=<value>/

たとえば、次のようにすべてのパスが統一されている必要があります。

source_type=rds_error/dt=2026-07-06/hour=00/
source_type=rds_audit/dt=2026-07-06/hour=01/
source_type=app_log/dt=2026-07-07/hour=00/

一方、次のように列が欠落したり、順番が変わる場合は利用できません。

source_type=rds_error/dt=2026-07-06/hour=00/
source_type=app_log/hour=00/
dt=2026-07-06/source_type=rds_audit/hour=00/

フォルダ構成が一定でない場合は、strict_column_orderをfalseにするか、省略します。

また、運用開始後にパーティション列の追加、削除、並べ替えなどでフォルダ規則を変更した場合は、partition_columnsも更新し、必要に応じてstrict_column_orderを無効化します。

パス規則が固定されている:
  strict_column_order = true

パス規則が一定でない:
  strict_column_order = false または省略

暗黙的パーティション化は、単にS3のフォルダを列として見せるだけではありません。

S3上のパーティション構造
  ↓
問合せ時に列と値を検出
  ↓
関連するファイルだけを参照
  ↓
ファイル追加・削除も実行時に検出

この仕組みにより、大量ログの全量をADBへ取り込まず、S3に置いたまま効率的にSQL分析できます。

参考: 暗黙的パーティション化を使用した外部表の問合せ

6. 外部表を高速化する3つの選択肢：Lake Cache、Data Lake Accelerator、Gold Data

外部表は、S3上のデータをADB内部へコピーせず、そのままSQLで参照できる便利な仕組みです。

一方、外部表の性能は、ADBとS3間のネットワーク、読み取るデータ量、ファイル形式、ファイル数、ファイルサイズ、パーティション設計、SQLの検索条件などに影響されます。

そのため、最初からすべてのログをADB内部へ取り込むのではなく、まず以下を最適化します。

Raw LogをCurated Parquetへ変換する
適切なファイルサイズにまとめる
source_type、dt、hourなどでパーティション化する
検索条件で不要なパーティションを読み取らない
SELECT *を避け、必要な列だけを参照する

特にParquetは列指向形式であるため、クエリに必要な列を中心に読み取れる点が大量ログ分析に向いています。

そのうえで、参照頻度や処理内容に応じて、次の3つの選択肢を検討します。

1. Lake Cache
   → 頻繁に参照する外部データをADB内へキャッシュする

2. Data Lake Accelerator
   → 大量の外部データスキャンへ追加の計算リソースを割り当てる

3. 内部表（Gold Data）
   → JOIN、加工、索引、Vector化が必要なデータをADB内部へ取り込む

この3つは、同じ目的の代替機能ではありません。

6.1 Lake Cacheで繰り返し参照を高速化する

Lake Cacheは、外部表やMounted Catalog Tableで頻繁に参照するデータを、Autonomous AI Database内へキャッシュする機能です。

通常の外部表アクセス:

SQL
  ↓
ADB外部表
  ↓
ネットワーク
  ↓
S3 Curated Parquet


Lake Cache利用時:

SQL
  ↓
ADB外部表
  ↓
Lake Cache
  ↓
キャッシュにないデータのみ外部参照

Lake Cacheはアプリケーションに対して透過的に利用されるため、既存の外部表を参照するSQLやダッシュボードを書き換えずに、キャッシュされたデータをADB内部から読み取れます。

以下のような用途に向いています。

毎日同じ期間のログを参照するダッシュボード
同じParquetデータを繰り返しスキャンする定型レポート
直近7日や30日のログを頻繁に調査する処理
複数ユーザーが同じ外部表へアクセスする環境
別Cloudや別Regionへの繰り返しアクセスを減らしたい場合
Gold表を別途作成せず、既存の外部表SQLを高速化したい場合

Lake Cacheを作成し、外部表全体をキャッシュする例です。

BEGIN
  DBMS_EXT_TABLE_CACHE.CREATE_CACHE(
    owner          => 'LOG_ANALYTICS',
    table_name     => 'EXT_LOG_EVENT_COMMON',
    partition_type => 'PATH'
  );
END;
/

BEGIN
  DBMS_EXT_TABLE_CACHE.ADD_TABLE(
    owner      => 'LOG_ANALYTICS',
    table_name => 'EXT_LOG_EVENT_COMMON'
  );
END;
/

キャッシュは作成直後には空であり、ADD_TABLEなどで対象ファイルを登録します。直近に更新されたファイルだけをキャッシュすることもできます。

BEGIN
  DBMS_EXT_TABLE_CACHE.ADD_LATEST_FILES(
    owner      => 'LOG_ANALYTICS',
    table_name => 'EXT_LOG_EVENT_COMMON',
    since      => INTERVAL '7' DAY,
    max_files  => 100,
    force      => TRUE
  );
END;
/

Lake Cacheでは、テーブル全体だけでなく、一部のファイルや列を選択してキャッシュすることもできます。キャッシュはスキーマのQuotaとADB内部ストレージを使用するため、全期間を無条件にキャッシュするのではなく、アクセス頻度の高い期間や列に絞るのがポイントです。

また、Lake Cacheには、対象ファイルの追加、Refresh、Retireなどを明示的に管理するPolicy-based方式と、ワークロードに応じてDatabaseが管理するAutomatic方式があります。

注意点として、Policy-based方式のキャッシュは、S3側でファイルが更新されても自動では反映されません。更新されたファイルは再Populateが必要で、S3側で削除されたファイルのキャッシュは即時無効になります。

ログのような追記型データの場合は、Gold表への日次取り込みと同様に、ADD_LATEST_FILESをDBMS_SCHEDULERでジョブ化し、新着ファイルを定期的にキャッシュへ追加する運用が相性よいです。

なお、Lake CacheはOracle AI Database 26ai からの機能です。利用するAutonomous AI Databaseのバージョンとサービス構成を事前に確認してください。

参考: Use Lake Cache to Improve Performance for External Tables and Mounted Catalog Tables

6.2 Data Lake Acceleratorで大量スキャンを高速化する

Data Lake Acceleratorは、Object Storage上の外部データをスキャン、フィルタリング、射影、解凍する処理を、Oracle管理の専用Computeへオフロードする機能です。

Lake Cacheが「頻繁に参照するデータをADB内部へ置く」機能であるのに対し、Data Lake Acceleratorは「外部データを処理する計算能力を増やす」機能です。

Lake Cache:
  頻繁に読むデータをADB内部へキャッシュする
  → 同じデータの繰り返し参照に向く

Data Lake Accelerator:
  外部データのスキャン処理を専用Computeへオフロードする
  → 長期間・大容量データの並列スキャンに向く

以下のような用途に向いています。

数TB以上のParquetデータを広範囲に検索する
長期間のログを横断的に集計する
アドホック調査で大量の外部データをスキャンする
月次や年次の大規模集計を実行する
外部表への同時アクセスが増える
外部データのスキャンでADB本体のComputeを圧迫したくない

たとえば、次のように長期間のログを横断集計する処理では、直近データをキャッシュするLake Cacheよりも、Data Lake Acceleratorでスキャン能力を拡張する方が適している場合があります。

SELECT
  source_type,
  service_name,
  error_code,
  COUNT(*) AS error_count
FROM ext_log_event_common
WHERE dt BETWEEN '2025-01-01' AND '2026-06-30'
  AND severity = 'ERROR'
GROUP BY
  source_type,
  service_name,
  error_code
ORDER BY error_count DESC;

Data Lake Acceleratorは、Autonomous AI Databaseの Provisioning時、Clone時、または既存InstanceのTool Configurationから有効化し、外部データ処理用のECPU数を設定します。ECPU数はデフォルト32で、32〜1024の範囲を32刻みで指定します。クエリ需要に応じて追加CPUが割り当てられ、実際に割り当てられたECPUに対して課金されます。アイドル時間は最大10分（変更不可）で、その後リソースは解放されます。

PoCでは、以下を比較して効果とコストを確認します。

Data Lake Acceleratorなし／ありの実行時間
スキャン対象データ量
割り当てたECPU数
同時実行数
処理時間短縮に対する追加コスト

なお、公式ドキュメントでは、Data Lake Acceleratorを利用できるAI LakehouseのPlatformとして、OCI、Microsoft Azure、Google Cloud Platformが記載されています。S3上のデータを参照する場合も、利用するAutonomous AI Databaseの配置先、Region、サービス構成での提供状況を確認してください。

参考: Data Lake Accelerator

Data Lake AcceleratorのECPU設定例

Data Lake Acceleratorは、SQLやPL/SQLから有効化する機能ではなく、Autonomous AI Databaseの管理画面にあるTool Configurationから設定します。

既存のAutonomous AI Databaseで設定する場合は、OCI Consoleで以下の順に操作します。

Autonomous AI Database
  ↓
対象Databaseの詳細画面
  ↓
Tool configuration
  ↓
Data Lake Accelerator
  ↓
Edit

編集画面では、Data Lake Acceleratorを有効化し、割り当てを要求するECPU数を指定します。

Status:
  Enabled

ECPU count:
  32〜1024 ECPU

指定単位:
  32 ECPU単位

たとえば、128 ECPUを要求する場合は、以下のように設定します。

Status     = Enabled
ECPU count = 128

指定できる値は、次のようになります。

デフォルトは32 ECPUです。

ここで指定するECPU数は、Data Lake Accelerator用としてユーザーが要求する割当ECPU数です。外部表クエリの需要に応じてリソースが使用され、実際に割り当てられたECPUに対して課金されます。

Data Lake Acceleratorでは、クエリ実行時に必要なリソースが割り当てられます。アイドル状態が続くとVMが終了し、最大アイドル時間は10分で、現在は変更できません。

なお、Data Lake AcceleratorのECPUは、Autonomous AI Database本体へ割り当てるECPUとは別の設定です。

Autonomous AI Database本体のECPU:
  SQL、JOIN、集計、Vector Searchなどに使用

Data Lake AcceleratorのECPU:
  Object Storage上の外部データの
  スキャン、フィルタリング、射影、解凍などに使用

たとえば、以下のように個別に設計できます。

Autonomous AI Database:
  8 ECPU

Data Lake Accelerator:
  128 ECPU

この場合、通常のDatabase処理にはADB本体の8 ECPUを使用し、外部データ処理にはData Lake Accelerator用として128 ECPUを要求します。

PoCでは、まず32 ECPUから開始し、64、128 ECPUと増やしながら、処理時間とコストの変化を比較します。

テスト1:
  Data Lake Acceleratorなし

テスト2:
  32 ECPU

テスト3:
  64 ECPU

テスト4:
  128 ECPU

ただし、ECPU数を増やしても、性能が比例して向上するとは限りません。

以下の条件も合わせて確認します。

スキャンするデータ量
Parquetのファイルサイズ
ファイル数
パーティションプルーニング
参照する列数
同時実行数
ADBとObject Storageの配置

なお、Data Lake AcceleratorはAI Lakehouse向けの機能として、OCI、Microsoft Azure、Google Cloud Platformで提供されています。
利用するDatabaseのバージョン、Platform、Regionでの提供状況を確認してください。

6.3 JOIN・加工・Vector化が必要なデータはGold表へ取り込む

Lake CacheやData Lake Acceleratorを利用しても、外部表はObject Storage上のデータを参照するための表です。

以下のような処理が必要な場合は、ADB内部の通常表へデータを取り込む方が適しています。

Oracle索引を作成したい
Oracle Partitioningで保持期間を管理したい
UPDATE、DELETE、MERGEを行いたい
Jiraや業務表と頻繁にJOINしたい
データクレンジングや名寄せを行いたい
集計済みデータを保持したい
Vector化対象を継続的に生成したい
安定した応答時間が求められる
Database内のトランザクション管理が必要

この分析用の内部表を、本記事ではGold Dataと呼びます。

いわゆるメダリオンアーキテクチャに当てはめると、以下のようになります。

Bronze: S3 Raw Log
  → 生ログを全量保管

Silver: S3 Curated Parquet
  → 整形・型付け・パーティション化済みデータ

Acceleration:
  Lake Cache
    → 頻繁に参照する外部データをローカルキャッシュ

  Data Lake Accelerator
    → 大量の外部データスキャンを追加Computeで高速化

Gold: ADB内部表
  → JOIN、集計、加工、Vector化に使用

Lake CacheとData Lake Acceleratorは、Bronze、Silver、Goldのような新しいデータ層ではありません。Silver層にある外部データへのアクセスを高速化するための機能と考えると整理しやすくなります。

Gold表への取り込み方法は3つ

外部表からGold表への取り込みには、主に3つの方法があります。

方法	向いている用途
`CREATE TABLE AS SELECT`（CTAS）	初回の一括取り込み
`INSERT INTO ... SELECT`	日次・時間ごとの増分取り込み
`DBMS_CLOUD.COPY_DATA`	外部表を介さないS3からの直接ロード

CTASで初回取り込み

まず、外部表から必要な期間だけを内部表として作成します。

CREATE TABLE log_event_gold
AS
SELECT *
FROM ext_log_event_common
WHERE dt BETWEEN '2026-06-01' AND '2026-07-06';

本番では、日付でパーティション化した内部表を先に定義しておくと、古いパーティションの削除（保持期間管理）や日付範囲検索が効率的になります。

INSERT INTO SELECTで増分取り込み

2回目以降は、前日分など増分だけを取り込みます。

INSERT /*+ APPEND */ INTO log_event_gold
SELECT *
FROM ext_log_event_common
WHERE dt = '2026-07-06';

COMMIT;

APPEND ヒントを付けるとダイレクトパスロードになり、大量データの取り込みが高速になります。日次取り込みは DBMS_SCHEDULER でジョブ化するのが定番です。

DBMS_CLOUD.COPY_DATAで直接ロード

ADBには、外部表を介さずにS3上のファイルを内部表へ直接ロードする DBMS_CLOUD.COPY_DATA もあります。

BEGIN
  DBMS_CLOUD.COPY_DATA(
    table_name      => 'LOG_EVENT_GOLD',
    credential_name => 'AWS_S3_CRED',
    file_uri_list   => 'https://log-bucket.s3.ap-northeast-1.amazonaws.com/curated/log_event_common/source_type=rds_audit/dt=2026-07-06/*.parquet',
    format          => '{"type":"parquet"}'
  );
END;
/

ロード結果は USER_LOAD_OPERATIONS ビューで確認でき、不正行があった場合のログも残るため、定期ロードの運用に向いています。
参考: Load Data from Files in the Cloud

なお、source_typeやdtなどのパーティション値がParquetファイル内ではなくS3パスにのみ存在する場合は、COPY_DATAによって対象列へ自動的に設定されることを前提にしない方が安全です。

パスから導出したパーティション列をGold表へ取り込みたい場合は、暗黙パーティションを設定した外部表からINSERT INTO ... SELECTでロードするか、Curated Parquetの生成時にパーティション列をファイル内部にも保持する設計を検討します。

外部表、Lake Cache、Data Lake Accelerator、Gold表の使い分け

観点	通常の外部表	Lake Cache	Data Lake Accelerator	内部表（Gold）
データ本体	S3	S3 + ADB内Cache	S3	ADB内部
主な目的	データを移動せず参照	繰り返し参照を高速化	大量スキャンを高速化	JOIN・加工・定型分析
SQLの変更	不要	原則不要	原則不要	参照先変更が必要
ADBストレージ	基本的に不要	Cache分を使用	データ格納には不要	Gold表分を使用
外部処理用Compute	ADBのCompute	ADBのCompute	専用ECPUを使用	ADBのCompute
Oracle索引	作成不可	作成不可	作成不可	作成可能
DML	基本的に不可	基本的に不可	基本的に不可	可能
データ鮮度	S3上のデータ	Cacheの更新方式に依存	S3上のデータ	取込タイミングに依存
向く処理	低頻度の探索	Dashboard・反復検索	長期間・大規模集計	Jira JOIN・Vector化元

今回のログ分析では、以下のように使い分けます。

全期間のログ保管:
  S3 Raw Log / Curated Parquet

低頻度の過去ログ調査:
  通常の外部表

直近データを繰り返し参照するDashboard:
  外部表 + Lake Cache

長期間の大規模な横断集計:
  外部表 + Data Lake Accelerator

Jiraとの頻繁なJOINや定型レポート:
  ADB内部表（Gold）

Vector SearchのEmbedding生成元:
  ADB内部表（Gold）

したがって、単純に「外部表は遅いから、すべてGold表へロードする」という設計にはしません。

1. Parquet、ファイルサイズ、パーティションを最適化する

2. 繰り返し参照するデータにはLake Cacheを検討する

3. 大量スキャンにはData Lake Acceleratorを検討する

4. JOIN、DML、索引、Vector化が必要なデータだけGold表へ取り込む

全量をADBへロードする必要はありません。S3を安価な全量保管層として活かしながら、Cache、Compute、内部表を用途に応じて選択するのがポイントです。

なお、直近パーティションを内部、過去パーティションをS3上の外部データに置けるハイブリッド・パーティション表（DBMS_CLOUD.CREATE_HYBRID_PART_TABLE）という選択肢もあります。1つの表で「ホットは内部、コールドはS3」を実現できるため、保持期間管理を含めて設計したい場合は検討する価値があります。

7. SQLでやるべきこと

ここが一番重要です。

構造化できるログ項目は、RAGではなくSQLで扱うべきです。

たとえば、以下のような項目はSQL向きです。

event_time
source_type
service_name
host_name
db_identifier
severity
error_code
user_name
client_ip
operation
object_name
trace_id
request_id

以下のような質問は、SQLで正確に処理できます。

昨日ERRORが多かったサービスは？
特定DBでDROP操作したユーザーは？
Auroraのerror_code別件数は？
Jira障害チケット発生前後2時間のログは？
特定IPからの監査操作は？
リリース後に増えたエラーは？
特定サービスでWarningが急増した時間帯は？

例です。

SELECT
  service_name,
  error_code,
  COUNT(*) AS cnt
FROM ext_log_event_common
WHERE dt = '2026-07-06'
  AND severity = 'ERROR'
GROUP BY service_name, error_code
ORDER BY cnt DESC;

Hiveパーティション由来の dt 列は文字列型として導出されるのが一般的なため、ここではDATE型リテラルではなく文字列で比較しています。

JiraチケットとログをJOINすることもできます。

なお、ここではJiraチケットをJira REST APIなどで事前にエクスポートし、ADB内の表（またはS3上のCurated Parquetを参照する外部表）として jira_issue を保持している前提です。Jiraデータ連携の実装は本記事の範囲外とし、別記事で扱う予定です。

SELECT
  j.issue_key,
  j.summary,
  l.service_name,
  l.error_code,
  COUNT(*) AS error_count,
  MIN(l.event_time) AS first_seen,
  MAX(l.event_time) AS last_seen
FROM ext_log_event_common l
JOIN jira_issue j
  ON l.service_name = j.component
 AND l.event_time BETWEEN j.created_at - INTERVAL '2' HOUR
                      AND j.created_at + INTERVAL '2' HOUR
WHERE j.issue_type IN ('Incident', 'Bug')
  AND l.severity = 'ERROR'
GROUP BY
  j.issue_key,
  j.summary,
  l.service_name,
  l.error_code
ORDER BY error_count DESC;

このような分析は、Vector SearchよりSQLの方が向いています。

理由は明確です。

正確に絞り込める
件数を数えられる
時系列で集計できる
JOINできる
監査証跡として説明しやすい
コストを見積もりやすい

8. Vector Searchでやるべきこと

一方で、SQLだけでは弱い領域があります。

それが「意味的に似ているものを探す」検索です。

たとえば、以下です。

似たエラーメッセージを探す
似たスタックトレースを探す
類似Jiraチケットを探す
過去障害との類似度を出す
文言は違うが意味が近い障害を探す
過去の対応メモから似た事例を探す

Oracle AI Vector Searchは、意味や値に基づいて構造化データと非構造データを検索するための機能として説明されています。
参考: Oracle AI Vector Search

ここで重要なのは、すべてのログ行をVector化しないことです。

悪い例です。

100億行のRaw LogをすべてVector化する

これは、コスト、性能、運用、精度の面でかなり重くなります。

よい例です。

同じエラーパターンを集約する
stack traceをhash化する
error_signature単位で代表メッセージを作る
Jira障害チケットと解決コメントをVector化する
Runbookや障害対応メモをVector化する

たとえば、Vector化対象のテーブルを以下のように作ります。

LOG_KNOWLEDGE_VECTOR
  doc_id
  doc_type
  source_ref
  service_name
  error_code
  severity
  text_for_embedding
  embedding_vector

doc_type には以下のような値を入れます。

log_signature
jira_issue
jira_comment
runbook
incident_report

類似障害検索のイメージは、たとえば以下のようになります。

SELECT
  doc_id,
  doc_type,
  service_name,
  text_for_embedding,
  VECTOR_DISTANCE(embedding_vector, :query_vector, COSINE) AS distance
FROM log_knowledge_vector
WHERE doc_type IN ('log_signature', 'incident_report')
ORDER BY distance
FETCH FIRST 5 ROWS ONLY;

:query_vector は、調査中のエラーメッセージなどをEmbeddingモデルでVector化したものです。Embeddingの生成（DBMS_VECTOR パッケージなど）やVector索引の設計を含む実装詳細は、次回の実践編で検証します。

つまり、Vector Searchは、大量ログ全体の検索エンジンではなく、曖昧検索・類似検索のための補助エンジンとして使うのがよいです。

9. RAGでやるべきこと

RAGは、Retrieval Augmented Generationの略です。

Oracle Select AI with RAGでは、指定したVector Storeから意味的類似性に基づいてコンテンツを検索し、その内容を使って自然言語応答を補強できます。
参考: Select AI with Retrieval Augmented Generation

RAGが向いているのは、以下のような処理です。

SQLやVector Searchの結果を自然言語で説明する
障害原因候補を要約する
Jiraチケットを自動要約する
Runbookや過去対応履歴を使って回答する
調査結果を人間向けに整理する
「次に見るべきログ」を提案する

たとえば、ユーザーが以下のように質問します。

昨日の決済サービスのERROR増加について、関連Jiraと過去障害を使って原因候補を説明して

この場合、内部的には以下のような流れにします。

1. SQLで対象ログを絞る
   - dt
   - service_name
   - severity
   - error_code

2. SQLでJiraチケットとJOINする
   - service_name
   - component
   - created_at
   - release_version

3. Vector Searchで類似障害を探す
   - message
   - stack_trace
   - Jira summary
   - incident report

4. RAGで自然言語説明を生成する
   - 発生状況
   - 影響範囲
   - 類似障害
   - 原因候補
   - 次の調査観点

Select AIを使う場合は、AI ProfileとVector Indexを設定したうえで、以下のようなイメージで自然言語のまま問い合わせできます。

SELECT AI narrate
昨日の決済サービスのERROR増加について、関連Jiraと過去障害を使って原因候補を説明して;

AI Profileの作成、Vector Indexの構成、RAGパイプラインの実装詳細も、次回の実践編で検証します。

ここでのポイントは、RAGを「検索そのものの主役」にしないことです。

SQL
  = 正確に絞る、数える、JOINする

Vector Search
  = 似ている文章・障害・チケットを探す

RAG
  = 検索結果を人間が読める形に説明・要約する

10. おすすめHybrid構成

今回のようなS3ログ + Athena + Jira + Oracle Autonomous AI Lakehouseの構成では、以下のHybridがよいと考えます。

S3 Raw Log
  ↓
ETL / Parser
  ↓
S3 Curated Parquet
  ↓
ADB外部表
  ├─ 繰り返し参照 → Lake Cache
  ├─ 大量スキャン → Data Lake Accelerator
  └─ JOIN・加工・Vector化 → 内部表（Gold）
  ↓
SQL分析 / Jira JOIN
  ↓
必要なテキストだけVector化
  ↓
Vector Search
  ↓
RAGで説明・要約

もう少し具体化すると、以下です。

[大量ログ本体]
S3 Curated Parquet
  - rds_error_log
  - rds_audit_log
  - aurora_slow_query_log
  - os_syslog
  - app_log_event
  - log_event_common

[外部表の高速化]
Lake Cache
  - 直近データや同じファイルを繰り返し参照
  - 既存SQLを変更せずにローカルCacheを利用

Data Lake Accelerator
  - 長期間・大容量データを横断スキャン
  - 外部データ処理を専用Computeへオフロード

[Gold Data（ADB内部表）]
  - JOIN、加工、索引、DMLが必要なデータ
  - CTAS / INSERT INTO SELECT / COPY_DATAで取り込み
  - 定型レポート、Jira JOIN、Vector化元

[Oracle SQL分析]
Autonomous Database External Table + Gold Table
  - 日時検索
  - 件数集計
  - エラーランキング
  - Audit Log検索
  - Jira JOIN
  - リリース影響分析

[Vector Search対象]
  - normalized_message
  - stack_trace
  - error_signature
  - Jira summary / description / comments
  - Runbook
  - 障害対応メモ

[RAG対象]
  - SQL分析結果
  - 類似障害検索結果
  - Jira関連情報
  - Runbook
  - 過去対応履歴

この構成のメリットは以下です。

S3上の既存ログ資産を活かせる
Athena資産を完全に捨てなくてよい
大量ログをOracle DB内部にすべてロードしなくてよい
繰り返し参照はLake Cache、大量スキャンはData Lake Acceleratorで高速化できる
JOINやVector化が必要なデータだけGold表へ取り込める
構造化項目はSQLで正確に分析できる
曖昧検索だけVector Searchに任せられる
自然言語説明だけRAGに任せられる
コストを抑えやすい
PoCから段階的に拡張できる

11. PoCで確認するポイント

PoCでは、いきなり全ログを対象にしない方がよいです。

まずは以下のように対象を絞ります。

対象ログ:
  - RDS / Aurora Error Log
  - RDS Audit Log
  - Application Error Log
  - 既知障害発生期間のログ

対象Jira:
  - Incident
  - Bug
  - Change
  - Release
  - 障害対応コメント

対象期間:
  - 直近30日
  - 既知障害1〜2件を含む期間

確認ポイントは以下です。

確認項目	内容
Raw Log直接参照	DBMS_CLOUD外部表でS3上のRaw Logを読めるか
Parquet化	Athena CTASまたはGlue ETLでCurated Parquetを作れるか
スキーマ設計	ログ種別ごとの詳細テーブルと共通テーブルを設計できるか
パーティション	`source_type`, `dt`, `hour` で効率よく絞れるか
Lake Cache	繰り返し参照する外部データをCacheし、通常の外部表との性能差を確認できるか
Data Lake Accelerator	長期間・大容量スキャンで、なし／ありの実行時間と追加コストを比較できるか
Gold表取り込み	CTAS / INSERT INTO SELECT / COPY_DATAで内部表を作成し、JOIN・加工・定型分析の性能を確認できるか
SQL分析	エラー件数、監査操作、Jira JOINがSQLで実現できるか
Vector Search	類似エラー、類似Jira、類似障害を検索できるか
RAG	SQL結果とVector結果を自然言語で説明できるか
コスト	Athena、ETL、ADB、AI処理のコスト感を比較できるか
運用性	スキーマ変更、ログ追加、パーサー更新に耐えられるか

まとめ

今回のようなS3上の大量ログ分析では、最初からすべてをAI処理しようとしないことが重要です。

基本方針は以下です。

大量ログの保管:
  S3

分析しやすい形式:
  Curated Parquet

Oracleからのアクセス:
  外部表

繰り返し参照の高速化:
  Lake Cache

長期間・大容量スキャンの高速化:
  Data Lake Accelerator

JOIN・加工・Vector化が必要なデータ:
  内部表（Gold Data）へ取り込み

構造化項目の分析:
  SQL

曖昧検索:
  Vector Search

説明・要約:
  RAG

つまり、こう考えると整理しやすいです。

ログ分析の基本はSQL。
似た障害を探すのはVector Search。
説明・要約するのはRAG。
大量ログ本体はS3 + Parquet。
Oracleからは外部表でSQLアクセス。
繰り返し参照はLake Cache、大量スキャンはData Lake Acceleratorで高速化。
JOIN・加工・Vector化が必要なデータだけ内部表（Gold）へ取り込み。

最終的な推奨構成は以下です。

S3 Raw Log
  ↓
S3 Curated Parquet
  ↓
ADB外部表
  ├─ 繰り返し参照 → Lake Cache
  ├─ 大量スキャン → Data Lake Accelerator
  └─ JOIN・加工・Vector化 → 内部表（Gold）
  ↓
SQLで正確に検索・集計・JOIN
  ↓
message / stack_trace / JiraコメントだけVector化
  ↓
Vector Searchで類似障害検索
  ↓
RAGで自然言語説明・要約

この構成にすると、「AI Databaseだから全部Vector化する」という誤解を避けつつ、SQLの正確性とAIの柔軟性を両立できます。

特に顧客提案では、以下の一文が重要です。

すべてのログをRAG対象にするのではなく、構造化できるログ項目はSQLで正確に分析し、意味検索が必要なmessage、stack trace、Jiraコメント、過去障害対応メモだけをVector化します。SQL分析結果とVector Search結果をRAGで説明・要約するHybrid構成を推奨します。

この考え方で設計すると、S3 / Athenaの既存資産を活かしながら、Oracle Autonomous AI LakehouseのAI分析価値を追加できます。

Oracleを中心にしながら、AWSのデータやサービスもそのまま活かせるところが、私がMulti CloudやOracle AI Databaseを触っていて面白いと感じる部分です。

Oracleだけですべてを置き換えるのではなく、それぞれのCloudやサービスが得意なところを活かしながら、Oracle DatabaseのSQL、Vector Search、Select AI、RAGへつなげていく。

このような構成を考えていると、Oracle Databaseが単なるDatabaseではなく、さまざまなCloud上のデータを集めて分析するAI Data Platformのような存在になってきていることを感じます。

今回は設計編として、外部表、Parquet、SQL、Vector Search、RAGの使い分けを整理しました。次回は、S3外部表の作成から Lake Cache、Vector Search、Select AI with RAGまでを検証してみたいです。