Vertex AI Feature Storeとは？仕組み・使い方と2026年の改称・廃止情報を実装目線で解説

Vertex AI Feature Storeは、機械学習の特徴量をBigQueryを核に一元管理し、学習（トレーニング）と推論（オンライン予測）の両方へ同じ定義で供給するGoogle Cloudのマネージドサービスです。狙いは、特徴量の重複開発と、学習時と本番で入力データがずれるトレーニング/サービング スキューを構造的に防ぐことにあります。2026年にはVertex AI自体がGemini Enterprise Agent Platformへ改称され、旧世代の「Feature Store (Legacy)」やオンライン提供の一部が廃止予定に入りました。本記事は、仕組み・使い方・機能を実装目線で整理し、この2026年の変化まで押さえます。

まとめ：先に押さえる7つの要点

• 正体：BigQuery上の特徴量を登録し、学習用（オフライン）とリアルタイム推論用（オンライン）に同じ定義で提供する特徴量ストア。
• 中核リソース：特徴量グループ（FeatureGroup）・特徴量（Feature）・オンラインストア（FeatureOnlineStore）・特徴量ビュー（FeatureView）。オフラインストアはBigQueryそのもの。
• 最大の価値：学習と推論で特徴量定義を共有し、トレーニング/サービング スキューの発生源（前処理の二重実装・取得タイミングのズレ）を断つ。
• 2026年の改称：2026年4月のCloud Next 2026でVertex AIはGemini Enterprise Agent Platformへ改称（移行は2026年5月下旬に完了）。APIエンドポイントは不変で、既存コードは動き続けます。
• 旧版の廃止：旧「Feature Store (Legacy/V1)」は2026年2月に廃止告知、2027年2月に提供終了予定。現行の特徴量グループ方式へ移行が必要です。
• オンライン提供の整理：Optimizedオンライン提供は2026年5月以降新機能なし・2027年2月終了予定で、Bigtableオンライン提供への移行が推奨。埋め込みの近傍検索はVector Search（旧Matching Engine）を併用します。
• 不要な場合：単一モデル・バッチ推論だけならFeature Storeは過剰で、BigQuery直読みで足ります（後述の判断ポイント）。

以下で、定義と2026年の位置づけ、仕組み、使い方、機能、スキュー対策、ユースケース、導入判断の順に掘り下げます。

Vertex AI Feature Storeの定義と2026年時点の位置づけ

特徴量ストアとは、複数のモデルで使う特徴量の定義と値を共通リポジトリに集約し、再利用と一貫性を担保する基盤です。Vertex AI Feature Storeはその実装で、特徴量の実体をBigQueryに置きつつ、推論用に最新値を低レイテンシで返すオンライン提供を組み合わせる点が中心的な設計です。

特徴量ストアが必要になる理由

各チームが特徴量を個別に作ると、同じ「直近7日のログイン回数」を別々に再実装する無駄が生まれ、算出ロジックの差異がモデル精度のばらつきに直結します。特徴量を一箇所で定義・共有すれば、開発工数の削減だけでなく、後述するスキューの予防にもつながります。特徴量管理はMLOpsの一部であり、パイプライン全体の設計はMLOpsの仕組みと導入判断の整理とあわせて捉えると位置づけが明確になります。

2026年の改称：Vertex AIからGemini Enterprise Agent Platformへの移行

2026年4月23日のGoogle Cloud Next 2026で、Vertex AIはGemini Enterprise Agent Platformへ改称され、移行は同年5月下旬に完了しました。ドキュメント上、Feature StoreもGemini Enterprise Agent Platform上のFeature Storeとして同基盤の一機能に位置づけ直されています。ただしこれは名称と体系の再編で、APIエンドポイントと既存APIは変更されておらず、これまでのコードやSDK呼び出しはそのまま動きます。検索・呼称としては引き続き「Vertex AI Feature Store」で通用します。改称全体の背景はGemini Enterprise Agent Platform改称後の全体像で確認できます。

旧Feature Store（Legacy）と現行版の違い

初期のVertex AI Feature Storeは、featurestore配下にエンティティタイプを作る「Legacy/V1」方式でした。これは2026年2月17日に廃止が告知され、2027年2月17日に提供終了予定（以後APIは利用不可）です。現行版はBigQueryのテーブル/ビューを直接データソースとし、特徴量グループと特徴量ビューで管理する方式に変わりました。Legacyを使っている場合は現行方式への移行が前提になります。廃止日は変更されうるため、最新はGoogle Cloud公式のデプリケーション一覧で確認してください。

オフラインストア（BigQuery）とオンラインストアの違い

Feature Storeでは、同じ特徴量を用途で2つのストアに分けます。学習・分析はオフライン、本番推論はオンラインです。役割が違うため、鮮度・レイテンシ・コストのバランスが変わります。

オフラインストア＝BigQuery

オフラインストアは専用基盤を新設せず、BigQueryのテーブルがそのまま担います。全エンティティの長期履歴を保持でき、学習時にはSQLで対象期間・対象キーを一括抽出して訓練データセットを作ります。ウィンドウ関数で派生特徴量を計算できるため、数億行規模の履歴集計にも耐えます。

オンラインストアと提供タイプの選択

オンラインストアは、推論時にエンティティIDをキーにして最新値をミリ秒単位で返すための領域です。提供タイプにはBigtableオンライン提供とOptimizedオンライン提供の2種があり、前者は大規模・高スループット、後者は超低レイテンシと埋め込み検索を狙った選択肢でした。ただしOptimizedは2026年5月17日以降は新機能追加がなく（重要パッチのみ）、2027年2月17日に提供終了予定です。新規構築ではBigtableオンライン提供を選ぶのが現行の推奨で、Optimizedを使っている場合は移行を計画します。

鮮度・レイテンシ・コストのトレードオフ

実運用では両者を併用します。BigQueryで特徴量を蓄積・更新し、必要な最新値だけをオンラインストアへ同期して、本番APIはオンライン経由で提供する流れが基本です。

使い方：特徴量の登録から提供までの手順

登録の流れは、BigQueryでの特徴量テーブル準備 → 特徴量グループ登録 → 特徴量ビューでオンライン同期、の3段階です。データソースはBigQueryに寄せる設計が前提になります。

BigQueryでの特徴量テーブル準備

各行を一意のエンティティID（ユーザーIDやデバイスIDなど）で識別し、各列を特徴量、そして特徴量のタイムスタンプ列を持たせます。タイムスタンプは、最新値の参照と、過去時点の学習データ再現（時点整合）の両方に必要です。集計はSQLやデータパイプラインで日次・週次に更新します。

CREATE OR REPLACE TABLE ml_features.user_features AS
SELECT
  user_id AS entity_id,
  COUNTIF(event_name = 'login') AS login_count_7d,
  AVG(purchase_amount) AS avg_purchase_amount_7d,
  CURRENT_TIMESTAMP() AS feature_timestamp
FROM raw.user_events
WHERE event_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY)
GROUP BY user_id;

特徴量グループと特徴量の登録

準備したBigQueryテーブル（またはビュー）を特徴量グループとして登録し、エンティティID列とタイムスタンプ列を対応づけます。次に、テーブルの各列を個別の特徴量リソースとして定義し、データ型や説明をメタデータとして付けます。ここで登録した情報が特徴レジストリに蓄積され、他チームが検索・再利用できるようになります。特徴量の登録自体は任意ですが、ガバナンスの観点から推奨されます。

特徴量ビューでのオンライン提供設定

オンライン提供には、まずオンラインストアを作成し（提供タイプはBigtableを選択）、その上に特徴量ビューを定義します。特徴量ビューは、どのBigQueryソースのどの特徴量をオンラインへ載せるかを指定する単位で、同期スケジュールを設定するとBigQueryからオンラインストアへ定期的にデータがコピーされます。これにより、本番の予測時に常に最新に近い特徴量をキー参照で取得できます。

主な機能：特徴レジストリ・モニタリング・埋め込み対応

Feature Storeは単なるデータ置き場ではなく、再利用・品質監視・高度なデータ型対応まで含む基盤です。

特徴レジストリと再利用

特徴レジストリは、登録済みの特徴量グループ・特徴量の定義、データ型、データソース、更新頻度、オーナーなどのメタデータを一元管理するカタログです。新規モデル開発時に既存特徴量を検索して流用でき、似た特徴量の二重作成を防ぎます。レジストリ情報はDataplexのデータカタログと統合され、組織のデータ資産として横断検索や系譜（どのソースから算出されたか）の把握が可能です。特徴量の由来を追えることは、モデル不調時の原因究明を早めます。

特徴量モニタリングによるドリフト・スキュー検知

学習時と提供時の特徴量統計（平均・分散・カテゴリ比率など）を比較し、分布のドリフトやスキューの兆候を検知してアラートを出せます。設計段階でスキューを抑えても、時間経過やデータ変化でズレは生じうるため、本番での継続監視が再学習の起点になります。

埋め込みとVector Searchの併用

画像・テキスト・行動履歴を圧縮した埋め込み（ベクトル）を特徴量として扱う場面が増えています。近傍探索（似たユーザーや類似商品の検索）をスケーラブルに行うには、Feature Store単体ではなく、専用のVector Search（旧称Matching Engine）を併用するのがGoogleの推奨です。ベクトル検索の考え方はベクトル検索とセマンティック検索の違いで仕組みごと整理できます。

Feature Storeによるトレーニング/サービング スキューの抑止

トレーニング/サービング スキューとは、学習時にモデルが見た特徴量と、本番推論で与える特徴量の内容・分布がずれる問題です。オフライン評価は良好なのに本番で精度が出ない典型的な原因で、放置すると的外れな改良を重ねる悪循環に陥ります。

主因は2つです。1つは前処理の二重実装で、学習はバッチ、推論は別コードという構成だと、欠損補完やエンコード方法の差が入り込みます。もう1つは取得タイミングの差で、学習時は将来情報まで使えてしまう一方、本番では直近データしか得られず、情報リークとして表面化します。

Feature Storeは、学習も推論も同じ特徴量定義・同じデータソースを参照させることで、前処理の二重実装を不要にし、この2つの発生源を断ちます。さらにモニタリングで学習と提供の統計を突き合わせられるため、万一ズレても早期に検知できます。スキュー対策こそがFeature Storeを導入する最大の実利です。

主なユースケース

低レイテンシで最新特徴量を必要とする領域ほど効果が出ます。代表例は次のとおりです。

• リアルタイム推薦：直近の閲覧・クリック履歴から嗜好を判断し、ページ読み込み時にパーソナライズしたランキングを返す。
• 不正検知：取引回数や通常利用地域からの距離などの最新特徴量をミリ秒で取得し、決済ごとにスコアリングして即時ブロックや追加認証を判断する。
• 予知保全：センサーの振動・温度から算出した特徴量を蓄積し、各機械の異常スコアをダッシュボードでリアルタイム更新する。
• 需要予測・在庫管理：商品ID・店舗IDをエンティティに、販売実績や季節性指標の履歴を学習に使い、発注計画へ反映する。

導入可否を分ける判断基準

Feature Storeは万能ではありません。まずオンライン提供が要らないなら導入しないと割り切るのが現実的です。単一モデル・バッチ推論だけの構成なら、BigQueryから直接学習データを引くほうが単純で、オンラインストアのノード稼働コストも同期の運用負荷も発生しません。Feature Storeが効くのは、複数モデルで特徴量を共有する、あるいはリアルタイム推論で低レイテンシ提供が要る場合です。

導入する場合は、次の3点を先に設計します。1つ目は権限設計で、登録・変更できる管理者と閲覧のみのロールをIAMで分け、機密データ由来の特徴量はアクセスを限定します。2つ目はスケーリングで、オンラインストアのノード数・同期頻度・BigQueryのクエリ負荷を想定利用量に合わせます。3つ目は費用対効果で、BigQueryのストレージ/スキャン費用とオンラインストアの稼働費が、開発効率と精度の改善に見合うかをPoCで測ります。加えて、新規構築は前述のとおりBigtableオンライン提供を前提に組むと、廃止予定のOptimizedへの後戻りを避けられます。

よくある質問

Vertex AI Feature Storeは無料で使えますか？

専用の定額料金ではなく、使ったリソースへの従量課金です。オフライン側はBigQueryのストレージとクエリスキャン量、オンライン側はオンラインストアのノード稼働と同期に対して費用が発生します。オンライン提供を使わなければBigQuery側の費用だけで運用できます。実額は構成と利用量で変わるため、公式の料金ページで見積もってください。

Vertex AIがGemini Enterprise Agent Platformに変わりましたが、Feature Storeはどうなりますか？

2026年4月の改称で、Feature Storeも同プラットフォームの機能として位置づけ直されました。ただしAPIエンドポイントと既存APIは変更されておらず、これまでのコードはそのまま動きます。呼称としては「Vertex AI Feature Store」で引き続き通用します。

旧Feature Store（Legacy）はいつ使えなくなりますか？

Legacy/V1は2026年2月17日に廃止が告知され、2027年2月17日に提供終了予定です。以後はAPIが利用できなくなるため、BigQueryテーブルを直接データソースにする現行の特徴量グループ方式へ移行が必要です。日付は変更される可能性があるので、公式のデプリケーション情報で最新を確認してください。

BigQueryだけで特徴量を管理するのと何が違いますか？

BigQuery直読みでも学習用データは作れますが、リアルタイム推論に必要な低レイテンシ提供、特徴量の再利用を促す特徴レジストリ、学習と提供の統計を比較するスキュー監視が加わる点が違いです。逆にリアルタイム提供も再利用も不要なら、BigQuery直読みで十分です。

オンラインストアはBigtableとOptimizedのどちらを選ぶべきですか？

新規構築ではBigtableオンライン提供を選びます。Optimizedオンライン提供は2026年5月17日以降は新機能追加がなく、2027年2月17日に提供終了予定のため、既存でOptimizedを使っている場合もBigtableへの移行を計画してください。埋め込みの近傍検索は、Feature Storeではなく専用のVector Searchを併用します。

関連記事

• Vertex AI Agent Builderとは？Gemini Enterprise Agent Platform改称後の全体像・料金・使い方
• ベクトル検索とセマンティック検索の違い｜包含関係・仕組み・使い分けを実装目線で整理
• MLOpsとは？機械学習の運用を支える仕組みと導入判断をわかりやすく解説