「同じ特徴量を使ったはずなのに、学習時と推論時で結果が違う」――MLエンジニアなら一度は経験するこの現象、多くは特徴量の定義と計算が散在していることに原因があります。本記事では特徴量ストアは学習時と推論時の一貫性を保つためのデータ基盤であり、複数モデルで特徴量を共有したい、リアルタイム推論で一貫性を担保したい、というニーズが出てきた段階で導入を検討すべき、という実務判断をお伝えします。
特徴量ストアとは
特徴量ストア(Feature Store)は、機械学習で使う特徴量を一元管理し、学習時と推論時で一貫したデータを提供するための基盤です。データ基盤(DWH/DataLake)とMLモデルの間に位置し、特徴量の定義・計算・配信を担います。
【特徴量ストアの位置づけ】
[データソース] --> [ETL/ELT] --> [DWH/Lake]
|
v
[特徴量ストア]
|
+-------------------------+---------------------+
| |
v v
[オフラインストア] [オンラインストア]
(学習用、低レイテンシ不要、 (推論用、ミリ秒単位の
大量データ向き) 高速アクセス)
| |
v v
[学習ジョブ] [推論サービス]
| |
v v
[学習済みモデル] [予測結果]
※ 同じ特徴量定義が学習と推論の両方に適用されるため、
「train/serve skew(学習と推論のズレ)」を防げるなぜ特徴量ストアが必要か
特徴量ストアが必要になる理由は、ML開発の中で「特徴量」という資産が急速に増えることにあります。モデルが1つだけなら、SQLで計算した特徴量をPandasに読み込んで学習すれば事足ります。しかし、モデル数が5つ、10つと増え、それぞれが部分的に同じ特徴量を使うようになると、同じロジックがあちこちで書かれるようになり、一貫性を保てなくなります。
さらに深刻なのが「train/serve skew」です。学習時はバッチ処理で特徴量を計算し、推論時はリアルタイムAPIで計算する――この2つの処理パスで微妙に計算ロジックがずれると、本番で精度が学習時より大幅に下がります。特徴量ストアは、同じ特徴量定義を両方のパスに供給することで、この問題を根本から解決します。
主要特徴量ストアの比較
2026年時点で主要な特徴量ストアを比較します。
| ツール | OSS/商用 | リアルタイム対応 | オフライン対応 | スケール | 料金 |
|---|---|---|---|---|---|
| Feast | OSS | あり(要セットアップ) | 強力 | 中〜大 | 無料(インフラ費のみ) |
| Tecton | 商用 | 非常に強力 | 強力 | 大 | エンタープライズ料金 |
| Hopsworks | OSS+商用 | 強力 | 強力 | 大 | OSS無料、商用は要問合せ |
| SageMaker Feature Store | 商用(AWSマネージド) | 強力 | 強力 | 大 | 従量課金 |
| Vertex AI Feature Store | 商用(GCPマネージド) | 強力 | 強力 | 大 | 従量課金 |
| Databricks Feature Store | 商用(Databricks内蔵) | 強力 | 非常に強力 | 大 | DBUに含まれる |
OSSでの出発点として最も人気のあるFeastの使い方を示します。
# feature_repo/features.py
from datetime import timedelta
from feast import Entity, FeatureView, Field, FileSource
from feast.types import Float32, Int64
customer = Entity(name="customer_id", join_keys=["customer_id"])
source = FileSource(
path="s3://ml-data/features/customer_stats.parquet",
timestamp_field="event_time",
)
customer_stats = FeatureView(
name="customer_stats",
entities=[customer],
ttl=timedelta(days=7),
schema=[
Field(name="avg_purchase_30d", dtype=Float32),
Field(name="session_count_7d", dtype=Int64),
Field(name="churn_risk_score", dtype=Float32),
],
source=source,
)
# 学習時: ポイントインタイム結合
from feast import FeatureStore
store = FeatureStore(repo_path=".")
training_df = store.get_historical_features(
entity_df=entity_df,
features=["customer_stats:avg_purchase_30d", "customer_stats:churn_risk_score"],
).to_df()導入判断のフレームワーク
特徴量ストアは強力ですが、全てのMLプロジェクトに必要なわけではありません。導入判断のマトリクスを示します。
| 条件 | 推奨 |
|---|---|
| モデル数: 1〜2、リアルタイム推論なし | 不要(SQLで十分) |
| モデル数: 3〜5、バッチ推論のみ | Feastのオフライン機能 |
| モデル数: 5以上、リアルタイム推論あり | Feast(本格運用)またはマネージド |
| SLOが厳しい本番サービス | Tecton、Databricks、SageMaker等の商用 |
| 組織横断で特徴量共有 | 特徴量カタログ付きの商用ツール |
判断ツリーを示します。
Q1. リアルタイム推論(ミリ秒応答)が必要?
├── Yes → Q2. 既存のクラウドプラットフォームは?
│ ├── AWS中心 → SageMaker Feature Store
│ ├── GCP中心 → Vertex AI Feature Store
│ ├── Databricks中心 → Databricks Feature Store
│ └── その他 → Feast(+ Redis/DynamoDB) or Tecton
└── No → Q3. 同じ特徴量を使う本番モデルが3つ以上ある?
├── Yes → Feast(オフラインのみの軽量構成)
└── No → 特徴量ストア不要(SQL + Parquetで十分)特徴量ストアの設計ベストプラクティス
特徴量ストアを活かすための設計原則を整理します。
- エンティティ設計を慎重に――customer_id、product_id、session_idなど、結合軸を先に決める。後から変えにくいため最初が肝心
- 命名規則を統一――avg_purchase_30d のように「統計関数_対象_期間」の順で命名すると検索性が上がる
- TTLを明確に――古くなった特徴量を自動破棄する仕組みを入れないと、ストアが肥大化する
- ポイントインタイム結合を徹底――学習時に未来のデータを使わないよう、必ずタイムスタンプベースの結合を行う
- モニタリング――特徴量の分布変化を監視し、ドリフトを早期検知する
# 特徴量パイプラインの例(バッチ)
import pandas as pd
from feast import FeatureStore
def build_customer_features(event_date):
df = spark.sql(f"""
SELECT customer_id,
AVG(amount) OVER (PARTITION BY customer_id ORDER BY purchase_date
ROWS BETWEEN 30 PRECEDING AND CURRENT ROW) AS avg_purchase_30d,
COUNT(session_id) FILTER (WHERE days_ago <= 7) AS session_count_7d,
'{event_date}' AS event_time
FROM fact_purchases
""").toPandas()
df.to_parquet(f"s3://ml-data/features/customer_stats/{event_date}.parquet")
FeatureStore(repo_path=".").materialize_incremental(end_date=event_date)まとめ
特徴量ストアは「MLが組織に広がるフェーズで効いてくる装置」です。モデル1個の段階では過剰ですが、複数モデル・複数チーム・リアルタイム推論が絡み始めると、それまでのSQL+Pandasでは耐えきれなくなります。Feastから始めて必要に応じてマネージドに移行するのが、失敗の少ない進め方です。関連記事としてMLOpsとは、MLパイプライン、モデルレジストリ、データ基盤とはもあわせてご参照ください。
よくある質問(FAQ)
Q1. 特徴量ストアとは何ですか?
A. 機械学習で使用する特徴量(入力データ)を一元管理し、学習時と推論時で一貫したデータを提供するための基盤です。特徴量の再利用、バージョン管理、リアルタイム提供を実現します。train/serve skew問題の根本解決策です。
Q2. 特徴量ストアはすべてのMLプロジェクトに必要ですか?
A. いいえ。モデル数が少なく特徴量の共有ニーズがない段階では不要です。複数モデルで同じ特徴量を使い回す場合や、リアルタイム推論で特徴量の一貫性が必要な場合に導入価値が高まります。初期はSQLとParquetだけで運用し、スケールアウトのタイミングで導入する流れが現実的です。
Q3. Feastとは何ですか?
A. 最も広く使われているオープンソースの特徴量ストアです。オフライン(学習用)とオンライン(推論用)の両方の特徴量提供に対応し、多くのデータソースやクラウド環境と連携できます。Python中心の軽量な実装でスタートでき、規模に応じてRedisやDynamoDBなどのオンラインストアを追加していけます。