フィーチャーストア

フィーチャーストアとは

フィーチャーストア (feature store) は、機械学習モデルが入力として使う特徴量 (feature) を一元的に管理し、モデルの学習時と本番推論時で同じ定義の特徴量を提供するためのデータ基盤である。特徴量の計算ロジック、保存、配信、再利用を集約することで、チーム全体で同じ特徴量を共有できるようにする。

特徴量とは「ユーザーの過去 30 日の購入回数」「商品の平均レビュー点数」のように、生データから加工してモデルに与える値を指す。フィーチャーストアはこの加工済みの値を管理対象とする。

なぜ必要なのか (training-serving skew)

フィーチャーストアが解決する最大の課題は、学習と推論で特徴量の計算がずれる training-serving skew (学習・推論間の乖離) である。

フィーチャーストアがない場合
  学習: バッチ SQL で「過去 30 日の購入回数」を集計
  推論: アプリのコードで同じ指標を別ロジックで再実装
        → 集計期間の境界や欠損の扱いが微妙に異なる
        → オフライン評価は良いのに本番精度が落ちる

フィーチャーストアがある場合
  特徴量の定義を 1 か所で記述
  学習・推論の双方が同じ定義から値を取得
        → 計算ロジックの二重実装が消え、乖離が起きない

同じ「過去 30 日の購入回数」でも、学習用バッチと推論用アプリで別々に実装すると、わずかな差がモデル精度を静かに蝕む。フィーチャーストアは特徴量の定義を単一の真実とすることで、この乖離を構造的に防ぐ。

オフラインストアとオンラインストアの比較

フィーチャーストアは用途の異なる 2 つの保存層を持つのが一般的である。

観点	オフラインストア	オンラインストア
主な用途	モデルの学習、バッチ推論	リアルタイム推論
扱うデータ量	大量の履歴データ	各エンティティの最新値のみ
求められる特性	大規模スキャン、低コスト	低レイテンシな単一キー参照
代表的なストレージ	データウェアハウス、データレイク	インメモリ KVS、低レイテンシ DB

学習では過去すべての履歴を大量にスキャンするため、安価で大容量なストレージが向く。一方、推論では「このユーザーの今の特徴量」を数ミリ秒で 1 件引く必要があるため、低レイテンシなストアが向く。両者へ同じ定義から値を書き込み、整合性を保つのがフィーチャーストアの役割である。

主な機能

特徴量の定義と登録: 計算ロジックをコードやレジストリで宣言し、バージョン管理する
オフライン / オンラインへの配信: 同一定義から学習用と推論用の両方へ供給する
時点整合性 (point-in-time correctness): 学習データを作る際、予測時点より未来の情報を混ぜない (データリーケージの防止)
特徴量の再利用と発見: 他チームが作った特徴量をカタログから検索して使い回す

特に時点整合性は重要で、「予測したい時点ではまだ得られていない未来の値」を学習に混ぜると、評価指標だけが不当に高くなり、本番でまったく再現しないモデルができてしまう。

導入の判断

フィーチャーストアは万能ではなく、運用する基盤自体のコストがかかる。導入が見合うのは次のような状況である。

複数チーム・複数モデルで同じ特徴量を共有したい
リアルタイム推論があり、training-serving skew が実害になっている
特徴量の再利用と発見を組織的に進めたい

逆に、モデルが少数でバッチ推論のみ、特徴量も使い回さない段階では、データウェアハウス上の管理で十分なことが多い。早すぎる導入はかえって複雑さを増やす。MLOps 全体の文脈は MLOps、特徴量として頻出するベクトル表現は埋め込み (embedding)、その格納先としてはベクトルデータベースもあわせて参照してほしい。

よくある誤解

「データウェアハウスがあれば不要」: ウェアハウスは大規模分析向きで、ミリ秒単位の単一キー参照には向かない。オンライン提供の要件が加わると別の層が要る。
「特徴量を貯める場所」だと捉える: 本質は保存ではなく、学習と推論で同じ定義を共有することにある。保存だけならストレージで足りる。
「導入すれば精度が上がる」: 精度を上げるのは特徴量設計そのものであり、フィーチャーストアは乖離を防ぎ再利用を促す基盤にすぎない。

フィーチャーストア