特徴量ストアとは？オンライン・オフライン二層構成と導入判断を実装目線で解説【2026年版】

特徴量ストアは、学習用に作った特徴量を保存し、推論時に同じ定義で取り出せるようにする基盤です。この記事では、オフラインストアとオンラインストアという二層構成の役割分担、学習データに未来の値を混ぜないpoint-in-time joinの実装、Feast 0.65系やSageMaker Feature Store、Databricks、Vertex AI Feature Storeの2026年8月時点の提供状況、導入が成立する条件と過剰投資になる案件の見極めまでを、受託開発の現場で判断する順に並べています。特徴量そのものの意味や作り方は特徴量とは？機械学習での意味と作り方・重要度の見方で扱うため、本記事は保存と配布の設計に絞ります。

まとめ：特徴量ストア導入の判断基準と、二層構成で解決できる範囲

特徴量ストアが実際に解くのは、学習時と推論時で特徴量の中身がずれる問題と、同じ集計ロジックが複数チームで再実装される問題の2つです。保管場所を1か所に寄せること自体には価値がありません。値の定義と参照時点をコードとして固定し、学習と推論の双方が同じ定義を呼ぶ形にしたときに効果が出ます。

構成は二層に分かれます。オフラインストアは履歴を全件残し、学習データセットの生成とバッチ推論を担当。オンラインストアはエンティティごとの最新値だけを保持し、リアルタイム推論に数ミリ秒から数十ミリ秒で応答します。この非対称性が二層構成の本質です。

導入判断は規模で決めます。オンライン推論があり、同じ特徴量を3本以上のモデルまたは複数チームが参照し、データ提供側と推論側が別チームに分かれている。この3条件が重なった案件でだけ、初期構築の工数を回収できます。日次バッチ推論のみでモデルが1本の案件なら、共通変換ライブラリと集計テーブルの整備で同じ効果が出ます。製品選定では2026年8月時点の提供状況を確認してください。Vertex AI Feature Store (Legacy) は2027年2月17日に完全終了する予定が公表されており、新規案件でLegacy版を前提にした設計は成り立ちません。

特徴量ストアの定義と、訓練推論スキューが生まれる実装上の構造

用語だけ聞くと「特徴量を入れるデータベース」に読めますが、それでは既存のデータウェアハウスとの違いが説明できません。まず、何を引き受ける仕組みなのかを機能で定義します。

特徴量ストアが引き受ける3つの機能と、データ基盤との責任境界

機能は3つに整理できます。第1に、特徴量の定義（どのテーブルのどの列をどう集計するか）をコードとして登録するレジストリ。第2に、その定義に沿って計算済みの値を保存するストレージ。第3に、学習用と推論用で異なる形に値を配布するサービング層です。

データウェアハウスとの責任境界はサービング層にあります。日次バッチで集計テーブルを作るところまではDWHとワークフローエンジンの仕事で、ここはデータパイプラインとは？構成要素と設計手順の領分。特徴量ストアはその出力を受け取り、「顧客IDを1件与えたら30ミリ秒で直近30日の購買回数を返す」というオンライン参照の口を追加します。オンライン参照の要件がない案件では、3機能のうち2つはDWHで足りてしまう計算です。

訓練推論スキューが起きる3パターンと、ストアで消える範囲の線引き

訓練推論スキュー（training-serving skew）は、学習時と推論時で与える特徴量が食い違う状態です。発生経路は3つ。

• 実装の二重化：学習はSQL、推論はアプリケーション側のコードで同じ集計を書き直し、境界条件がずれる
• 参照時点のずれ：学習時はバッチ実行日の値、推論時はリクエスト時点の値を読み、集計窓の切り方が変わる
• データ鮮度のずれ：オンライン側の更新が遅れ、学習時に前提とした鮮度より古い値が推論に入る

特徴量ストアが消せるのは1番目と2番目です。定義を1か所に登録して両方から呼ぶ構造にすれば、実装の二重化は構造的に起きません。3番目は消えず、鮮度監視の運用として残ります。特徴量の作り方そのものに起因するずれも特徴量エンジニアリングとは？変換・選択・自動化の工程と実装判断の範囲で、基盤側では吸収できません。

オフラインストアとオンラインストアの二層構成と書き込み経路の設計

二層構成は「同じデータを2か所に置く」設計ではありません。保持ポリシーと読み出しパターンが根本的に違うため、層を分けます。

履歴全件のオフラインと最新1件のオンラインで分かれる保持ポリシー

オフラインストアは追記専用です。SageMaker Feature Storeでは、同じレコード識別子に対する更新もすべて新しい行として蓄積され、過去のどの時点の値も引けます。学習データセットを作るには過去の状態が必要で、この履歴保持が前提になります。

オンラインストアは上書きです。レコード識別子ごとに、最新のイベント時刻に対応するレコードのみを保持し、GetRecord で1件を低レイテンシに返します。古い値は残りません。SageMaker Feature Storeのオンラインストアには TTL 設定があり、フィーチャーグループ単位でも個別レコード単位でも指定できます。TTL失効で物理削除されると、オフラインストア側にはtombstoneレコードが書かれる仕様。学習データ生成時にこれを除外しないと、削除済みの状態を有効な値として読み込みます。

エンティティ・特徴量グループ・イベント時刻というデータモデルの型

設計の最初に決めるのはエンティティの粒度です。顧客単位か、顧客×商品カテゴリ単位か、セッション単位か。粒度を細かくするほどオンラインストアの行数が増え、常時保持コストが線形に伸びます。後から粗くする変更は既存モデルの再学習を伴うため、初期に決め切ってください。

特徴量グループは、同じタイミングで更新される列をまとめた単位です。日次更新の購買履歴系とリアルタイム更新の行動ログ系を1つに混ぜると、更新頻度の高い側に引きずられて書き込み量が跳ねます。更新頻度で分けるのが実務上の原則。Databricksでは Unity Catalog 内の主キー制約を持つDeltaテーブルが特徴量テーブルとなり、catalog.schema.table の3階層名前空間で管理されます。

イベント時刻列は「その値がいつ有効になったか」を表す列で、レコード識別子との組み合わせでレコードが一意に定まります。書き込み時刻ではなく事象の発生時刻を入れるのが鉄則。取り違えると、遅れて到着したデータが後述のpoint-in-time joinで正しく除外されません。

バッチ実体化とストリーム書き込みで分かれる鮮度とコストの見積もり

オンラインストアへの書き込み経路は2通りあります。オフライン側で計算した結果を定期的に流し込むバッチ実体化と、イベントストリームから直接書き込むストリーム経路です。

バッチ実体化は、日次や時間次のジョブで対象エンティティ分をまとめてPutRecord相当の処理に流します。実装が単純で、失敗時の再実行も容易。難点は鮮度で、更新間隔より新しい行動は推論に反映されません。Databricksでは cron スケジュールによる自動的なバッチ実体化がAPIとして用意されています。

ストリーム経路は鮮度を秒単位まで詰められる代わりに、集計ロジックをストリーム処理側にも実装し、バッチ側との整合を別途担保する必要が生じます。「直近1時間の閲覧回数」のように短い窓が精度に効く案件でだけ選んでください。全特徴量のストリーム化は割に合いません。

point-in-time joinで学習データに未来情報を混ぜない実装手順

特徴量ストアを入れる技術的な理由の中心が、この処理にあります。単純な結合で学習データを作ると、精度が実力以上に高く出て、本番で崩れます。

単純なキー結合がラベル時点より後の値を引き込む、漏れの発生経路

解約予測を例にします。学習ラベルは「2026年3月1日時点で解約したか」、特徴量は「直近30日の問い合わせ回数」。顧客IDだけを鍵に特徴量テーブルと結合すると、テーブルに入っている最新の値、つまり3月1日より後の問い合わせ回数が結合されます。解約直前に問い合わせが急増する傾向があれば、モデルは未来の値を見て解約を当てているだけの状態です。

検証データにも同じ漏れが入るため、交差検証のスコアは高いまま。異常に気付くのは本番投入後になります。原因は特徴量の作り方ではなく学習データを組み立てる結合処理にあり、だからこそ基盤側で構造的に防ぎます。

イベント時刻列・許容遅延・TTLという3つの設定値の決定基準

point-in-time join（as-of join）は、ラベルの発生時刻を基準に「その時刻以前で最も新しい特徴量レコード」だけを引き当てる結合です。SageMaker Feature StoreのオフラインAPIはこのpoint-in-time精度を保った取り出しに対応し、重複レコードの除去や複数フィーチャーグループの結合も同じ枠組みで扱えます。Databricksも Unity Catalog 上の特徴量テーブルにpoint-in-time joinを提供します。

実装時に決める値は3つ。1つ目はイベント時刻列で、事象の発生時刻を入れます。2つ目は許容遅延（どこまで古い特徴量を有効とみなすか）で、無制限にすると半年前の値が最新として結合される事故が起きます。更新間隔の2倍から3倍を上限に置くのが実務的な設定。3つ目がオンラインストアのTTLで、保持コストと参照可能期間の綱引きで決めます。

3つの値はセットで整合させてください。許容遅延がTTLより長い設定は、学習では有効とみなした古い値が推論時にはオンラインストアから消えている状態を意味し、そのまま訓練推論スキューになります。

学習用データセットを取り出す手順と、再現性を担保する版管理の型

学習データセットの生成手順は、どの製品でも次の順序をたどります。

1. ラベルとエンティティID、ラベル時刻を並べたエンティティDFを用意する
2. 参照したい特徴量グループと列を指定する
3. point-in-time joinでラベル時刻以前の最新値を引き当てる
4. 生成結果をスナップショットとして保存し、モデルのメタデータに紐づける

4番目を省くと再現性が失われます。定義を変更した後で過去のモデルを再学習しようとしても、同じデータセットは二度と作れません。定義側のバージョンと生成済みデータセットのスナップショットを両方残すのが実務の型。モデル管理との連携はMLOpsツールの比較と選定で扱う実験管理・モデルレジストリと重なります。

主要な特徴量ストア実装の比較と、2026年8月時点の提供状況

選定で見るのは機能の多寡ではなく、既存のデータ基盤との相性と、製品のライフサイクルです。2026年8月時点の各社ドキュメント表記をもとに整理します。

Feast・SageMaker・Databricksの守備範囲と前提インフラの違い

FeastはOSSの特徴量ストアで、PyPIの表示では安定版が0.65.0（リリース日2026年7月20日）、必要Pythonは3.10.0以上です。ストレージを内包せず、オフライン側にBigQueryやSnowflake、オンライン側にRedisやDynamoDBを接続します。接続先の運用は自社持ちです。

SageMaker Feature Storeは、フィーチャーグループの作成からS3上のオフラインストア、キーバリュー型のオンラインストアまでをマネージドで提供します。取り込みはPutRecord、オンライン参照はGetRecordで、TTLとpoint-in-time精度の取り出しも標準機能。AWS内で完結する案件では最短で立ち上がります。

Databricksの Feature Engineering in Unity Catalog は、既存のDeltaテーブルに主キー制約を付けるだけで特徴量テーブルになります。Databricks Runtime 13.3 LTS ML以降とdatabricks-feature-engineeringパッケージが前提です。

Google Cloudでは、オフライン側をBigQuery、オンライン配信をBigtableに置く構成が現行世代です。

Vertex AI Feature Store（Legacy）の終了予定と移行先の選択

Google Cloud側は世代交代の途中にあります。Vertex AI Feature Store (Legacy) は非推奨となっており、2026年5月17日以降は新機能が追加されず重大なパッチのみの提供、2027年2月17日に完全終了してAPIも利用できなくなる予定が公表されています。あわせて Optimized online serving も非推奨となり、2026年5月時点ではBigtable online servingのみがサポート対象です。

新規案件でLegacy版を選ぶ理由は残っていません。既存システムがLegacy版で動いている場合は、2027年2月の期限から逆算して移行計画を立ててください。オフライン側をBigQuery、オンライン配信をBigtableへ寄せる構成が公式の移行先です。製品固有の設定手順と改称の経緯はVertex AI Feature Storeとは？仕組み・使い方と2026年の改称・廃止情報に整理しています。

導入が効く条件と、特徴量ストアが過剰投資になる見送りの判断基準

特徴量ストアは、MLOpsの構成図に載っているからという理由で入れると確実に持て余します。

オンライン推論と複数モデルでの再利用が重なる、導入の成立条件

導入が回収できるのは、次の3条件が同時に成り立つ案件です。第1に、リアルタイムのオンライン推論があること。バッチ推論だけならオンラインストアの層が丸ごと不要です。第2に、同じ特徴量を3本以上のモデルまたは複数のプロダクトが参照すること。定義を1か所に集める価値は参照者の数に比例します。第3に、特徴量を作るチームとモデルを動かすチームが分かれていること。同一人物が両方を書いている限り、実装の二重化はそもそも起きません。

3条件が揃えば、初期構築に2〜3人月かけても、その後の特徴量追加1本あたりの工数は半分以下に落ちます。

バッチ推論のみ・モデル1本の案件で導入を見送るべき2つの理由

日次バッチ推論だけ、モデルは1本、特徴量は単一のテーブルから引ける。この構成なら入れないでください。理由は2つ。

1つ目は、解くべき問題が存在しないこと。学習と推論が同じバッチジョブの中で同じSQLを呼ぶなら、訓練推論スキューは構造的に起きません。2つ目は、運用負債が純増すること。オンラインストアの常時稼働費用、レジストリの定義とテーブル実体の同期、製品バージョン追随。得るものがないまま、この3つが恒常的な運用項目として乗ります。

「将来オンライン化するかもしれないから今のうちに」という先回りも勧めません。要件が固まる前にエンティティ粒度を決めると、ほぼ確実に作り直しになるためです。特徴量の定義をSQLファイルとして版管理し、集計テーブルの生成をパイプラインに寄せておく。ここまでで、後から載せ替えるコストは十分に低く抑えられます。

ストアを入れずに一貫性を担保する、共通変換ライブラリという代替

見送ると決めた案件で、それでも学習と推論の一貫性は担保したい。その代替が共通変換ライブラリです。特徴量の計算を1つのPythonパッケージにまとめ、学習ジョブと推論APIの両方がそれをimportする形にします。

この方式で消えるのは実装の二重化だけで、参照時点のずれは残ります。学習データ生成側でラベル時刻より前の行に絞る条件を明示的に書き、レビューで担保してください。モデルが1〜2本の規模なら、こちらのほうが総工数は小さく収まります。

運用フェーズで決める鮮度監視・コスト抑制・権限分離の設計指針

構築後に効いてくるのは、監視とコストと権限の3点です。設計に含めずに引き渡すと、半年後に運用側が止まります。

特徴量の鮮度監視とドリフト検知で見る指標と、監視責任の切り分け

監視対象は2種類に分かれます。鮮度監視は「オンラインストアの値がいつ更新されたか」を見る運用監視で、イベント時刻と現在時刻の差分を特徴量グループ単位で計測。更新間隔の2倍を超えたら警告を出す閾値が扱いやすい水準です。バッチ実体化ジョブの失敗は、この指標で最初に現れます。

もう1つがドリフト検知で、値の分布が学習時から乖離していないかを見るモデル品質の監視にあたります。前者はデータ基盤チーム、後者はモデル担当という切り分けが実務では機能。同じダッシュボードに混ぜると、ジョブ障害とモデル劣化の切り分けに時間を取られます。

オンラインストアの費用が跳ねる条件と、書き込み量を抑える設計

費用が跳ねるのは、書き込み回数とエンティティ数の掛け算が大きくなったときです。1000万人の顧客に対して1時間ごとに全件を書き戻す設計なら、月間の書き込みは72億回に達します。実際には値が変わったエンティティだけを書けば足ります。

抑え方は3つ。差分だけを書き込む、更新頻度の異なる特徴量グループを分ける、オンライン参照が不要な特徴量をオフラインのみに置く。3番目が最も効きます。学習にしか使わない特徴量をオンラインストアに載せた構成は珍しくなく、棚卸しで書き込み量が半減する案件もあります。

受託開発で特徴量ストアを引き渡すときの権限設計と運用移管の範囲

引き渡しで揉めるのは、特徴量定義の変更権限をどちらが持つかです。定義を変えると過去のモデルの再現性に影響が及ぶため、追加は運用側で自由に、既存定義の変更と削除は承認フローを通す二段構えが落としどころになります。Unity Catalogのようにカタログ側の権限管理に乗る製品なら、この分離を権限設定でそのまま表現できます。

移管範囲では、鮮度監視の閾値とアラート先、TTLの根拠、エンティティ粒度を決めた理由の3点を文書に残してください。特にエンティティ粒度は、理由が残っていないと後任が安易に変更し、既存モデルが一斉に動かなくなります。特徴量ストアを含むMLOps基盤の設計・構築と運用移管を一貫して支援する体制は機械学習モデル開発のページで整理しています。

よくある質問

特徴量ストアの導入検討で実際に受ける質問を5つ挙げます。

特徴量ストアとデータウェアハウスは何が違いますか？

保存の仕組みではなく、配布の仕組みが違います。データウェアハウスは大量行の一括読み出しに向いた構造で、1件を数十ミリ秒で返すオンライン参照には向きません。特徴量ストアはDWH相当のオフライン層に加え、1件を低レイテンシで返すオンライン層と、両者へ同じ定義を配るレジストリを持ちます。オンライン推論の要件がない案件では、この差は価値になりません。

特徴量ストアを入れれば訓練推論スキューは完全になくなりますか？

なくなるのは、集計ロジックの二重実装と参照時点のずれによるスキューです。オンライン側の更新遅延で古い値が推論に入る問題は残り、鮮度監視で押さえることになります。前処理の一部を推論APIのコード側に書いている場合も、その部分はストアの管理外です。

Feastのような自前構築とマネージド製品はどちらを選ぶべきですか？

既存のクラウドとデータ基盤で決めるのが早いです。AWSで完結しているならSageMaker Feature Store、Databricksで基盤を組んでいるならFeature Engineering in Unity Catalog、複数クラウドにまたがるか既存のDWHとキーバリューストアを流用したいならFeastが噛み合います。Feastは接続先ストレージの運用を自社で持つ前提です。

小規模なチームでも特徴量ストアを導入する意味はありますか？

チーム規模ではなく、オンライン推論の有無とモデル本数で判断してください。3人でもリアルタイム推論があり、同じ特徴量を複数のモデルが参照しているなら効果は出ます。逆に10人いてもバッチ推論のみでモデル1本なら、共通変換ライブラリと集計テーブルの整備で足ります。軸は人数ではなく参照者の数と参照経路の種類です。

特徴量ストアの構築にはどれくらいの期間がかかりますか？

マネージド製品を選び、既存のデータパイプラインが動いている前提なら、最初の特徴量グループをオンライン推論に載せるまでで2〜3人月が目安です。内訳は、エンティティ粒度と特徴量グループの設計、point-in-time joinを含む学習データ生成の実装と検証、鮮度監視とアラートの整備。パイプラインが未整備なら、その構築期間が別途かかります。

関連記事

• 特徴量とは？機械学習での意味と作り方・重要度の見方：ストアに載せる対象そのものの定義です。
• 特徴量エンジニアリングとは？変換・選択・自動化の工程と実装判断：特徴量を作る工程側の設計です。
• Vertex AI Feature Storeとは？仕組み・使い方と2026年の改称・廃止情報：Google製品固有の仕様と移行情報です。
• MLOpsツールの比較と選定：実験管理・モデルレジストリまで含めた周辺スタックの選び方です。
• MLOpsとは？機械学習の運用体制：ストアが位置づく運用全体像を判断者向けに整理しています。