フィーチャーストア（ML特徴量基盤）

特徴量という成果物：分析基盤とMLの接点

機械学習モデルが実際に消費するのは生データではなく、特徴量（feature） です。「このユーザーの直近30日の購入回数」「この商品の過去1時間の平均クリック率」——生のイベントログを集約・加工した数値列こそが、モデルの入力になります。特徴量エンジニアリングは、分散データ処理でイベントの山を意味ある信号へ畳み込む営みであり、本質的に分析基盤の仕事です。

問題は、この特徴量が二つの異なる文脈で必要になることです。学習（training） では、過去の膨大なイベントから数千万行の特徴量テーブルを一括生成する——これは有界データのバッチ処理です。推論（serving） では、リクエストが来た瞬間に特定ユーザー1件の最新特徴量を数ミリ秒で引く——これは無界ストリームと低遅延キー引きの世界です。同じ「直近30日の購入回数」でも、計算基盤もアクセスパターンも真逆です。

フィーチャーストア（feature store） は、この二つの文脈を単一の特徴量定義で橋渡しする基盤です。特徴量を一度定義すれば、学習用のオフライン供給と推論用のオンライン供給の両方を、同じ意味論で生み出す。これがなければ、各チームが同じ特徴量を別々に実装し、学習と推論で微妙に食い違う値が流れ込みます。

オンライン・オフライン一貫性：二経路が同じ値を返すか

フィーチャーストアが解く第一の難問が、オンライン・オフラインの一貫性です。同じ特徴量が二つのストアに実体化されます。

素朴に作ると、この二つを別々のコードで実装しがちです。学習用はSQLで履歴集計し、推論用はアプリのロジックで再計算する。すると同じ「30日購入回数」でも、窓の境界の扱い、タイムゾーン、欠損の埋め方が少しずつずれ、学習時と推論時で異なる分布の値がモデルに入ります。これが次節の training-serving skew です。

一貫性を担保する定石は、特徴量を一つの定義（変換ロジック）から両ストアへ実体化することです。バッチで全履歴を計算してオフラインストアへ書き、その最新断面（または同じ定義のストリーム集約）をオンラインストアへマテリアライズする。オンラインストアは「各エンティティの現在値」だけを保持し、主キー（ユーザーIDなど）で引く——これは分析クエリではなく、キー引きの低遅延アクセスです。二経路を同一定義から生成することが、値の一致の唯一の担保になります。

point-in-time結合：未来を混ぜないための時間整合

学習データ生成における最大の落とし穴が時間の扱いです。学習データの各行は「あるラベルのイベント時刻において、その時点までに判明していた特徴量」で構成されねばなりません。ここを外すと、学習時だけ未来の情報が漏れ込む（data leakage、特に時間軸の look-ahead leakage） 事故が起きます。

具体例で考えます。「2026-06-20 10:00 に発生した申込みが不正か」を予測するモデルを学習するとき、特徴量「このユーザーの累計申込み回数」を、現在時点（学習実行日）の値で結合したらどうなるか。その値には 6/20 10:00 以降の申込みも含まれてしまう。本番の推論時には未来の申込みなど当然知り得ないのに、学習データにだけ未来が混入する。モデルはこの漏洩した信号を学習し、オフライン評価では非現実的に高精度、本番では無力になります。

これを防ぐのがpoint-in-time結合（時点整合結合、as-of join） です。ラベルのイベント時刻を基準に、その時刻以前で最新の特徴量値だけを結合します。

# ラベル（予測対象）
entity=user_42, label_time=2026-06-20 10:00, y=fraud

# 特徴量の時系列（feature: 累計申込み回数）
user_42, 2026-06-18 09:00 -> 3
user_42, 2026-06-20 08:30 -> 4     # ← label_time 以前で最新。これを採用
user_42, 2026-06-20 11:00 -> 5     # ← label_time より未来。使ってはいけない

# point-in-time 結合の結果（漏洩なし）
user_42, label_time=2026-06-20 10:00, feature=4, y=fraud

要点は、通常のキー結合（user_id で最新値を引く）では時間軸を無視して未来を掴んでしまうのに対し、point-in-time結合は「user_id が一致 かつ feature_time <= label_time」の中で**最大の feature_time**を選ぶことです。各ラベル行ごとに参照する特徴量の版が変わるため、実装は特徴量履歴を時刻でソートし、ラベル時刻に対する as-of 探索を行います。これにより、本番推論時の情報制約を学習データ上に忠実に再現できます。

イベント時刻という共通の軸

point-in-time結合が依拠するのは、特徴量とラベルの双方に刻まれたイベント時刻です。ここでストリーム処理と同じ論点が現れます。イベント時刻（事象が起きた時刻）と処理時刻（それを計算・記録した時刻）は別物であり、混同すると時間整合が崩れます。

特徴量値には「いつ有効になったか」のタイムスタンプが必要で、しかもそれはイベント時刻でなければなりません。処理時刻（バッチが走った時刻）で記録すると、遅延到着したイベントの反映がずれ、point-in-time結合が誤った版を選びます。オンライン側で特徴量を更新する場合も同様に、遅れて届いたイベントをどう扱うか——ウォーターマークで「もう来ない」を判定して窓を閉じるか、後から訂正するか——がオフラインとの一致に直結します。この時間の設計は/data-engineering/stream-watermarks-windowing/の枠組みそのものです。

つまりフィーチャーストアの時間整合は、ストリーム処理のイベント時間・ウォーターマーク・遅延データの理論を、学習データ生成へ適用したものと言えます。オフラインのpoint-in-time結合と、オンラインの遅延イベント処理が同じイベント時刻軸で揃って初めて、二経路の値が一致します。

再利用とバージョン管理：特徴量を共有資産にする

フィーチャーストアの第二の価値が特徴量の再利用です。多くの組織で、複数チームが「ユーザーの直近購入額」のような同じ特徴量を各自で再実装しています。重複計算はコストを二重化し、微妙に異なる定義がモデル間の不整合を生みます。

解決は、特徴量を名前付き・バージョン管理された成果物としてレジストリに登録することです。「user_purchase_amount_30d」を一度定義・実装すれば、他チームは名前で参照して再利用でき、実装の重複と定義のばらつきが消えます。これは特徴量の発見可能性（discoverability） の問題で、テーブルやジョブをメタデータで一元管理し依存を追跡する/data-engineering/data-lineage-catalog/の考え方を、特徴量へ特化させたフィーチャーレジストリが担います。

バージョン管理が再現性の要です。特徴量の定義（変換ロジック）は時間とともに変わります——窓を30日から60日に変える、欠損の埋め方を変える。定義が変わればモデルへの入力分布も変わるので、あるモデルがどの特徴量のどの版で学習されたかを記録しなければ、学習の再現も、精度劣化の原因追跡もできません。

二層アーキテクチャの全体像

これらをまとめると、フィーチャーストアは同一の特徴量定義を核に、二層のストアと登録層で構成されます。

        特徴量定義（変換ロジック・イベント時刻付き）
                     │
        ┌────────────┴────────────┐
   バッチ集約（全履歴）        ストリーム集約（最新）
        │                          │
   オフラインストア            オンラインストア
   （レイクの列指向テーブル）   （キー引き低遅延ストア）
        │                          │
   point-in-time結合で          主キーで最新値を
   学習データ生成               ミリ秒取得（推論）
        │                          │
      学習 ────► モデル ────► 推論
     （版を記録）           （同じ定義の値を消費）

学習側は全履歴のオフラインストアから、ラベル時刻に整合した特徴量をpoint-in-time結合で取り出す。推論側は各エンティティの最新値だけを持つオンラインストアから主キーで引く。両者は同じ定義から実体化されるため値が一致し、しかも学習データには未来が混入しない。この「単一定義・二経路・時間整合」の三点が、フィーチャーストアが分析基盤とMLの狭間で果たす本質的な役割です。

まとめ

• フィーチャーストアは特徴量を単一定義で管理し、学習用のオフライン（バッチ・全履歴） と推論用のオンライン（低遅延・最新値） の二経路へ一貫して供給する。特徴量計算はイベント集約であり分析基盤の産物。
• オンライン・オフライン一貫性は、二経路を別実装にすると崩れる。同一定義から両ストアを実体化し、値を定期照合しないとtraining-serving skew（学習は高精度・本番は劣化）を招く。
• point-in-time結合は、ラベルのイベント時刻以前で最新の特徴量だけを結合する。通常のキー結合は未来を掴みデータ漏洩を起こし、オフライン評価が嘘になる。
• 時間整合はイベント時刻を軸に成立し、ストリーム処理のウォーターマーク・遅延データの理論と地続き。処理時刻で記録すると版選択が狂う。
• 再利用は特徴量を名前付き成果物としてレジストリに登録して実現し、バージョン管理でモデルが使った特徴量の版を固定して再現性を担保する。学習データ生成はELTのバックフィルで、冪等性が前提。