【要約】S3 Iceberg外部表とOracle DBローカル表を統合し、SELECT AI（NL2SQL）で顧客分析してみた [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
以下の課題を解決する。
- ・データレイク（S3）と業務DB（Oracle）の分断による分析の困難さ。
- ・大規模データのETLに伴うコストと遅延。
- ・複数の表を直接JOINすることによる、売上データの二重計上リスク。
- ・SQLスキルを持たないユーザーによる、複雑な横断分析の限界。
// Approach
以下のステップで解決を図る。
1.**外部表の参照**: S3上のIcebergデータをOracle ADBから外部表として参照。
2.**ローカルデータの構築**: 受注、キャンペーン、サポート情報をOracle DB内に作成。
3.**統合ビューの作成**: 集計ミスを防ぐため、顧客単位で集計した
V_CUSTOMER_360 を構築。4.**メタデータの整備**:
COMMENT ON を用い、AIが理解しやすいよう列定義を記述。5.**AIプロファイル設定**:
DBMS_CLOUD_AI.CREATE_PROFILE で、対象ビューとOCI GenAIを紐付け。6.**自然言語実行**:
DBMS_CLOUD_AI.GENERATE を使い、自然言語からSQLを生成・実行。// Result
外部データと内部データを統合した「顧客360度分析」を、SQL記述なしで実現。セグメント別の売上、キャンペーン反応、サポート状況を横断した高度な分析が可能となった。データ移動を最小限に抑えた柔軟な分析基盤を構築できる。
Senior Engineer Insight
> 実戦投入における評価は高い。特に、外部表とローカル表をビューで抽象化し、AIの参照範囲を絞る設計は、計算コストと精度の両面で理にかなっている。ただし、AIの回答精度は
COMMENT の記述力に直結する。現場では、データカタログの整備をAI導入の前提条件とすべきだ。また、集計ロジックをビュー側に隠蔽する手法は、ユーザーの誤った分析を防ぐための強力なガードレールとなる。スケーラビリティの観点では、Iceberg側のパーティショニング設計が、結合時のパフォーマンスを左右する鍵となるだろう。