「手元のJupyter NotebookではAUC 0.95を出していたモデルが、本番環境にデプロイした途端に0.7台まで落ちてしまった...」
開発現場では、このような事態に直面することが少なくありません。深夜までログを漁り、ようやく見つけた原因は、モデルのバグでもハイパーパラメータの問題でもなく、「データ処理のズレ」だった、という話はよく聞かれます。
学習時にはSQLで丁寧に加工したデータを使い、推論時にはアプリケーションコード（JavaやGoなど）で同じロジックを再実装して特徴量を作る。この「二重管理」が生む微細な差異こそが、モデルの精度を静かに、しかし確実に蝕むTraining-Serving Skew（学習と推論の不整合）の正体です。ビジネスの現場において、この精度の低下は直結して機会損失を生み出します。
本記事では、この厄介な問題をGoogle CloudのVertex AI Feature Storeを使って構造的に解決する方法を解説します。単なるツールの使い方ではなく、「なぜ精度が落ちるのか」という技術の根本原因を見抜き、それを防ぐための堅牢なMLパイプラインをスピーディーに構築するアプローチを見ていきましょう。まずは動くプロトタイプを作り、仮説を即座に形にして検証することが、ビジネスへの最短距離となります。
1. なぜ「特徴量ストア」が必要なのか：Training-Serving Skewの正体
コードを書き始める前に、解決すべき課題の本質を明確にしておきましょう。多くのエンジニアが「特徴量ストア（Feature Store）」を単なる「整理されたデータベース」と捉えがちですが、その真価は「時系列を考慮したデータの一貫性保証エンジン」にあります。
モデル精度を蝕む「学習と推論のデータのズレ」
機械学習プロジェクトの失敗原因として悪名高い「Training-Serving Skew（学習・推論の歪み）」は、主に以下の2つのパターンで発生します。
- ロジックの不整合: 学習用のPythonスクリプトやSQLと、本番環境のアプリケーションコードで、特徴量計算（例：過去30日間の購入平均）のロジックが微妙に異なってしまうケースです。
- データの鮮度（Freshness）のズレ: 推論時には「今」のデータが必要なのに、バッチ処理の遅延により数時間前、あるいは前日の古いデータに基づいて予測を行ってしまうケースです。
これらを個別のスクリプトや手動運用で管理しようとするのは、システムがスケールするにつれて事実上不可能になります。経営的視点から見ても、保守コストの増大と属人化のリスクは避けるべきです。
Vertex AI Feature Storeが解決する3つの課題
Vertex AI Feature Store（特にBigQueryとの統合が強化された最新のアーキテクチャ）を導入することで、以下の構造的なメリットが得られます。
- 特徴量の再利用と一元管理: 一度定義した特徴量をリポジトリとして管理し、学習（オフライン）と推論（オンライン）の両方で共有します。これにより、ロジックの二重管理とそれに起因するバグを排除します。
- Point-in-Time Correctness（時点の正確性）: 過去のデータを学習に使用する際、「その予測時点ですでに判明していた情報だけ」を正確に抽出します。未来の情報のリーク（Data Leakage）を自動的に防ぐこの機能は、時系列データを扱う上で不可欠です。
- 低遅延のオンラインサービング: リアルタイム予測のために、最新の特徴量をミリ秒単位で提供するスケーラブルなサービング基盤を提供します。
本記事で実装するパイプラインの全体像
本記事では、Vertex AIのエコシステムを活用し、以下のフローで堅牢なMLパイプラインを構築します。理論だけでなく「実際にどう動くか」を重視し、アジャイルに進めていきましょう。
- Setup: Feature Storeのプロビジョニングとデータモデルの定義
- Batch Ingest: BigQuery等のソースから過去データを取り込み、学習用データセットを生成
- Streaming Ingest: リアルタイムデータの書き込みと更新
- Serving: 推論エンドポイントからの特徴量取得と予測実行
それでは、アーキテクチャの理解を前提に、具体的な実装へと進みます。
2. 実装環境のセットアップとデータモデル設計
まずは環境構築です。Vertex AIは、最新のGeminiモデルやAgent Builderといった生成AI機能から、Feature StoreのようなMLOps基盤までを包括する統合プラットフォームです。このセクションでは、Feature Storeを利用するために必要なSDKのセットアップと、データモデルの設計について解説します。
Feature Storeのデータモデルは、ファイルシステムのような階層構造を持っています。
Feature Storeの階層構造（Featurestore -> EntityType -> Feature）
設計において最も重要なのがこの3階層の理解です。
- Featurestore: 最上位のコンテナ。プロジェクト全体またはドメインごとに作成します（例：
ecommerce_store）。 - EntityType: データの主キーとなる概念。RDBのテーブルに近いイメージです（例：
users,products）。 - Feature: 具体的な属性データ。RDBのカラムに相当します（例：
age,total_purchase_amount）。
Python SDKによる初期化コード
以下のコードは、Vertex AI SDKを使ってFeature StoreとEntityTypeを作成するものです。最新のVertex AI環境でも、基本的なリソース管理のアプローチは一貫しています。まずは動くものを作り、挙動を確かめることが重要です。
コンテキスト: この処理は一度だけ実行するインフラ構築作業です。既存のストアがある場合はスキップされます。
from google.cloud import aiplatform
# プロジェクト設定
# 実際の環境に合わせてプロジェクトIDとリージョンを設定してください
PROJECT_ID = "your-project-id"
REGION = "us-central1"
# Vertex AI SDKの初期化
aiplatform.init(project=PROJECT_ID, location=REGION)
# 1. Featurestoreの作成
# オンラインサービング用のノード数を指定します。
# コスト最適化のため、開発時は最小構成(min_node_count=1)で始めることを推奨します。
fs = aiplatform.Featurestore.create(
featurestore_id="ecommerce_featurestore",
online_store_fixed_node_count=1,
)
# 2. EntityType（ユーザー）の作成
# ここでは「ユーザーID」に紐づく特徴量を管理する箱を作ります。
users_entity_type = fs.create_entity_type(
entity_type_id="users",
description="User entity for recommendation model",
)
# 3. Feature（特徴量）の定義
# 具体的な特徴量の型と定義を追加します。
# value_typeはBOOL, BOOL_ARRAY, DOUBLE, DOUBLE_ARRAY, INT64, INT64_ARRAY, STRING, STRING_ARRAY, BYTESから選択可能
users_entity_type.create_feature(
feature_id="age",
value_type="INT64",
description="User age",
)
users_entity_type.create_feature(
feature_id="lifetime_value",
value_type="DOUBLE",
description="Total purchase amount",
)
print("Feature Store setup completed.")
これでデータの「器」ができました。Vertex AIのエコシステム内では、こうした構造化データと、Geminiなどのモデルが扱う非構造化データを連携させるケースも増えていますが、まずは堅牢なFeature Storeを構築することが第一歩です。次はここに魂（データ）を吹き込んでいきます。
3. 【Batch Ingestion】過去データの取り込みと学習用データセット生成
モデルの学習には、過去の大量のデータが必要です。Vertex AIは生成AI機能（Gemini等）で注目されがちですが、その基盤となる構造化データの管理、特にFeature Storeによる特徴量パイプラインの堅牢性は、信頼性の高いAIシステム構築において中核を担います。
ここでは、BigQueryなどのデータウェアハウスにあるデータをFeature Storeに取り込み（Ingest）、そこから学習用データを生成するプロセスを解説します。
BigQuery/GCSからのデータインジェスト実装
コンテキスト: データウェアハウスにあるマスターデータをFeature Storeに同期させます。これにより、Feature Storeが「正解データ」のハブとなり、Vertex AIプラットフォーム全体でのデータガバナンスを強化します。
# BigQueryからデータを取り込む設定
# entity_id_field: EntityTypeのID（ユーザーIDなど）に対応するBigQueryのカラム名
# feature_time: 特徴量が生成されたタイムスタンプのカラム名（これがPoint-in-Time Correctnessの鍵です！）
users_entity_type.ingest_from_bq(
feature_ids=["age", "lifetime_value"],
feature_time="update_timestamp",
bq_source_uri="bq://your-project-id.source_dataset.user_features_table",
entity_id_field="user_id",
disable_online_serving=False, # Trueにするとオフラインストアのみに書き込まれる
worker_count=2, # データ量に応じて調整
)
ポイント・イン・タイム検索による学習データの取得
ここがTraining-Serving Skew（学習と推論の乖離）を防ぐ最大のポイントです。
例えば、「ユーザーAが2023年1月1日に商品を購入したか？」を予測するモデルを作るとします。この時、学習データに入力する特徴量（例：過去の購入総額）は、「2023年1月1日時点での値」でなければなりません。もし、2023年12月時点の購入総額を使ってしまったらどうなるでしょうか？
それは「未来の情報をカンニング」していることになり、テスト精度だけが高く、本番環境では使い物にならないモデルが出来上がります（これをリークと呼びます）。Vertex AIの最新環境においても、このデータ整合性の原則は変わりません。
Vertex AI Feature Storeの batch_serve_to_bq メソッドは、このタイムトラベル処理を自動化し、正確な時系列データを再構築します。
# 学習用データの要求仕様（Read Instance）を定義
# 「誰の(entity_id)」「いつ時点の(feature_timestamp)」データが欲しいかを指定したテーブルを用意します。
read_instances_uri = "bq://your-project-id.training_dataset.training_labels"
# Feature Storeから学習用データを生成
fs.batch_serve_to_bq(
bq_destination_output_uri="bq://your-project-id.training_dataset.output_dataset",
serving_feature_ids= {
"users": ["age", "lifetime_value"]
},
read_instances_uri=read_instances_uri
)
この処理により、各学習データのタイムスタンプに合わせた正確な過去の特徴量が結合されます。複雑なSQLのWindow関数を手動で記述する必要がなくなり、データエンジニアリングの工数を大幅に削減できるだけでなく、人為的なミスによるリークも防ぐことができます。
4. 【Streaming Ingestion】リアルタイム予測のための最新特徴量更新
リアルタイム予測（例：Webサイトでのレコメンド）では、「今、ユーザーが何をしたか」を即座に反映させる必要があります。バッチ処理を待っていては遅すぎます。ビジネスのスピードに追従するためには、データの鮮度が命です。
write_feature_valuesによるストリーミング書き込み
コンテキスト: ユーザーの行動ログ（クリックや購入など）が発生した瞬間に、Feature Storeの値を更新します。これにより、数ミリ秒後の推論リクエストで最新の状態を参照できます。
import datetime
# 更新する特徴量データ
# タイムスタンプは「現在時刻」とします
current_time = datetime.datetime.now()
# ユーザーID 'user_123' の lifetime_value を更新
users_entity_type.write_feature_values(
instances=[
{
"entity_id": "user_123",
"feature_values": {
"lifetime_value": 1500.50
},
"feature_time": current_time
}
]
)
print("Real-time feature update sent.")
低遅延（Low Latency）を実現する書き込み設定
このストリーミング書き込みは、裏側でオンラインストア（通常はBigtableのようなNoSQL基盤）に即座に反映されます。注意点として、頻繁な書き込みはコストに影響するため、本当にリアルタイム性が必要な特徴量（例：直近1時間のクリック数）と、日次バッチで十分な特徴量（例：年齢）を区別して設計することが重要です。技術的な可能性とビジネス上の費用対効果を天秤にかける、経営的な視点がここで活きてきます。
5. 【Online Serving】推論時の低遅延特徴量フェッチと予測実行
いよいよ推論フェーズです。アプリケーション（予測API）からFeature Storeにアクセスし、特徴量を取得してモデルに入力します。
read_feature_valuesによるオンライン取得
コンテキスト: 推論リクエストが来た際、ユーザーIDだけを受け取り、必要な特徴量はFeature Storeから引いてきます。これにより、クライアント側が複雑な特徴量を送信する必要がなくなります。
# 推論対象のユーザーIDリスト
entity_ids = ["user_123"]
# オンラインストアから特徴量を取得
feature_values = users_entity_type.read(
entity_ids=entity_ids,
feature_ids=["age", "lifetime_value"]
)
# 取得結果の表示（実際はここでモデルの入力形式、例えばNumPy配列などに変換します）
for entity_id in entity_ids:
# データが見つからない場合のハンドリングも重要です
try:
data = feature_values[entity_id]
age = data.get("age", 0) # デフォルト値の設定
ltv = data.get("lifetime_value", 0.0)
print(f"User: {entity_id}, Age: {age}, LTV: {ltv}")
# ここで予測モデルへ入力
# prediction = model.predict([[age, ltv]])
except KeyError:
print(f"Data not found for user: {entity_id}")
エラーハンドリングとフォールバック戦略
実運用では、ネットワークエラーやデータの未登録（Cold Start問題）に備える必要があります。上記のコードのように try-except ブロックで囲み、データが取得できなかった場合のデフォルト値（平均値や0埋めなど）を事前に決めておくことが、システムの安定性を高める鍵です。長年の開発現場の経験から言えば、こうした地道な例外処理こそが、本番環境での信頼性を決定づけます。
6. 運用を見据えたベストプラクティスとコスト管理
Feature Storeは強力ですが、漫然と使用すればコストが高騰したり、管理不能な「データのゴミ屋敷」になったりするリスクがあります。ここでは、長期的な運用を成功させるための実践的なアドバイスをお伝えします。
ストレージとコンピュートリソースの最適化
コスト効率とパフォーマンスのバランスを保つためには、インフラ設定の継続的な見直しが不可欠です。
- リソース割り当ての最適化: オンラインサービングに使用するリソース（ノードやスロット数）は、QPS（Query Per Second）の要件に応じて適切に設定します。最初は最小構成で開始し、負荷テストの結果を見ながらオートスケーリングの設定を調整してください。最新のVertex AI Feature Store（BigQueryバックエンド）を利用する場合も、プロビジョニングされた容量が実際の需要とマッチしているか定期的に確認することが重要です。
- 不要なデータのライフサイクル管理: テスト作成したEntityTypeや、モデルの更新によって使われなくなったFeatureは、定期的にクリーンアップしましょう。Feature Storeは価値ある資産を保管する場所であり、「データの墓場」にしてはいけません。
精度監視とMLOpsの進化への対応
Feature Storeを一元管理のハブにすることで、Data Drift（データの分布変化）の検知も効率化されます。Vertex AI Model Monitoringと連携させれば、「最近、ユーザーの年齢層が急激に変わっていないか？」といった変化を自動で検知し、アラートを出すことも可能です。
さらに、MLOpsの領域は急速に進化しています。
- LLMOpsへの拡張: 生成AIの普及に伴い、特徴量としてテキスト埋め込み（Embedding）やプロンプトテンプレートを管理するケースが増えています。Feature Storeを、従来の数値データだけでなく、LLMアプリケーションを支える基盤として捉える視点も重要です。
- エッジAIとの連携: 推論環境がクラウドからエッジデバイスへと広がる中、特徴量の配信レイテンシを極小化する要件も高まっています。
このように、単なるデータの保管庫としてではなく、進化するAIエコシステムの中核としてFeature Storeを位置づけることが、MLOpsの成熟度を高める鍵となります。
まとめ
Training-Serving Skewは、データサイエンティストにとって長年の課題でした。しかし、Vertex AI Feature Storeを活用して「学習時と推論時のデータパイプラインを統一」することで、この問題は解決可能です。
- 一元管理: 特徴量の定義とロジックをFeature Storeに集約し、属人化を防ぐ。
- Point-in-Time: 学習データ作成時のタイムトラベル（時点復元）を自動化し、リークを防ぐ。
- Online Serving: リアルタイム推論でも、学習時と全く同じ定義のデータを低遅延で提供する。
この3つの柱を意識するだけで、AIプロジェクトの信頼性と開発スピードは飛躍的に向上します。まずは、小さなEntityTypeを一つ作成し、プロトタイプとしてその効果を体感してみることから始めてみてください。手を動かし、実際にどう動くかを確認することが、次なるイノベーションへの第一歩です。
この記事が、皆さんのMLOpsの旅路において確かな道標となることを願っています。疑問点があれば、ぜひチーム内で議論を深めてみてください。
Let's build reliable AI together!
コメント