AIが動くための「見えないインフラ」― データ基盤設計の実践ガイド

AIの精度を上げることに集中した結果、本番稼働できない——そういうプロジェクトを何度も見てきた。モデルの品質を左右するのは、アルゴリズムの選択よりもデータの品質と供給の安定性だ。AIが動き続けるための「見えないインフラ」、データ基盤の設計について整理する。

なぜデータ基盤が先なのか

PoC段階では、CSVをダウンロードしてJupyter Notebookで読み込む、という方法でも動く。しかし本番では以下が必要になる。

リアルタイムまたはバッチでのデータ更新
データ品質の自動チェック
複数システムからのデータ統合
過去データへの遡及アクセス
監査ログ（誰が何のデータを使ったか）

これらをPoC後に慌てて作ろうとすると、モデルの修正も一緒に発生し、手戻りコストが膨大になる。データ基盤はPoC前に設計し、PoC中に整備するのが正しい順序だ。

データ基盤の3層アーキテクチャ

[Raw Layer]     生データの保存。変換しない。削除しない。
    ↓
[Staging Layer] クレンジング・型変換・重複排除
    ↓
[Mart Layer]    分析・AI学習用に最適化されたテーブル

Raw Layer（生データ層）

ソースシステムから届いたデータをそのまま保存する層だ。変換・加工を一切行わないことがポイント。なぜなら、後から「あのとき生データに戻りたい」というニーズは必ず発生するからだ。

BigQueryではパーティションテーブルを使い、取り込み日時でパーティションを切る。

CREATE TABLE `project.raw.orders`
PARTITION BY DATE(ingested_at)
OPTIONS (partition_expiration_days = 365)
AS SELECT *, CURRENT_TIMESTAMP() AS ingested_at
FROM EXTERNAL_QUERY(...);

Staging Layer（加工層）

型変換、NULLの処理、重複排除を行う層。ここでデータ品質チェックも実施する。dbt（data build tool）との相性が良く、SQL変換とテストを同一リポジトリで管理できる。

# dbt schema.yml
models:
  - name: stg_orders
    columns:
      - name: order_id
        tests:
          - unique
          - not_null
      - name: amount
        tests:
          - not_null
          - dbt_utils.accepted_range:
              min_value: 0

Mart Layer（分析・AI用マート）

AIモデルの学習・推論に最適化されたテーブル。特徴量エンジニアリングをSQLで実装し、BigQuery MLと組み合わせることで、Pythonを書かずに基本的なMLパイプラインを構築できる。

ETLパイプラインの設計

データの流れを設計する際に意識すべき3点がある。

冪等性（べきとうせい）の確保

同じパイプラインを何度実行しても、結果が同じになる設計にする。INSERT ではなく MERGE（upsert）を使い、再実行時に重複データが発生しないようにする。

MERGE `project.staging.orders` AS target
USING `project.raw.orders` AS source
ON target.order_id = source.order_id
  AND DATE(target.ingested_at) = CURRENT_DATE()
WHEN NOT MATCHED THEN
  INSERT (order_id, user_id, amount, created_at, ingested_at)
  VALUES (source.order_id, source.user_id, source.amount,
          source.created_at, source.ingested_at);

スキーマ変更への対応

ソースシステムのスキーマは必ず変わる。BigQueryの INFORMATION_SCHEMA を使って差分を検知し、Slackに通知するモニタリングを組み込んでおくと、無言のデータ破損を防げる。

バックフィル設計

過去データを再処理する必要が生じることを想定し、日付範囲を指定して実行できる設計にしておく。Cloud Composerの execution_date を使うか、パイプライン引数に start_date/end_date を設けることで対応する。

AI学習パイプラインとの接続

データ基盤の最終的な目的地はAIモデルの学習だ。Vertex AI Pipelinesと連携する場合、以下の構成が実績として多い。

BigQuery Mart → Vertex AI Feature Store → Vertex AI Training
                                        → Vertex AI Prediction

Vertex AI Feature Storeを介すことで、学習時と推論時で同じ特徴量定義を使えることが保証される。学習・推論間の特徴量の不一致（training-serving skew）はAIシステムの品質劣化の主要原因の一つで、Feature Storeはその防止策として有効だ。

データ基盤は地味な仕事に見えるが、AIの精度と安定性を決定する最重要インフラだ。「モデルを作る前に基盤を作る」——この原則を徹底できるチームが、本番稼働率を上げることができる。