Feastとは：学習と推論で特徴量を共有するOSS Feature Store

機械学習のモデル開発を進めると、ある時点で「特徴量のコピペ問題」にぶつかります。「学習データで使った『過去30日の購入合計』を、推論時にも同じ定義で計算したい」「同じ特徴量を別のモデルでも使い回したい」。これらを場当たり的にコピペすると、定義のずれと運用の重さが爆発します。

Feastは、特徴量を一元定義し、学習と推論の両方で同じ値を返すOSS Feature Storeです。Goji Networkが開発し、いまはオープンソースコミュニティが運営しています。基本構造と使い方を整理します。

Feature Storeの2つの顔

Feature Storeは、同じ特徴量定義を学習（Offline）と推論（Online）の両方に提供するのが本質です。Feastはこの2つを統合管理します。

Feastの構造

特徴量の定義例

# feature_repo/customer_features.py
from datetime import timedelta
from feast import Entity, FeatureView, Field, FileSource
from feast.types import Int64, Float32

customer = Entity(name="customer_id", value_type="INT64")

customer_source = FileSource(
    path="s3://bucket/customer_features.parquet",
    timestamp_field="event_timestamp",
)

customer_features = FeatureView(
    name="customer_features",
    entities=[customer],
    ttl=timedelta(days=30),
    schema=[
        Field(name="purchase_total_30d", dtype=Float32),
        Field(name="purchase_count_30d", dtype=Int64),
        Field(name="days_since_last_purchase", dtype=Int64),
    ],
    source=customer_source,
)

「customer_features」というFeature Viewで、3つの特徴量を定義しました。データソースはParquetファイル、エンティティ（主キー）は customer_id、TTLは30日です。

学習データ生成

from feast import FeatureStore
import pandas as pd

store = FeatureStore(repo_path="feature_repo")

# ラベル付きエンティティ（学習対象）
entity_df = pd.DataFrame({
    "customer_id": [1, 2, 3],
    "event_timestamp": pd.to_datetime(["2026-01-15", "2026-01-15", "2026-01-15"]),
})

# 過去時点の特徴量を取得（point-in-time correct）
training_data = store.get_historical_features(
    entity_df=entity_df,
    features=[
        "customer_features:purchase_total_30d",
        "customer_features:days_since_last_purchase",
    ],
).to_df()

「2026年1月15日時点で、各顧客の特徴量はどうだったか」をPoint-in-Time correctnessを保ったまま取得します。データリーケージ（未来情報の混入）を防ぐ仕組みが組み込みです。

推論時の特徴量取得

# Onlineストアから特徴量を取得（ミリ秒応答）
features = store.get_online_features(
    features=[
        "customer_features:purchase_total_30d",
        "customer_features:days_since_last_purchase",
    ],
    entity_rows=[{"customer_id": 42}],
).to_dict()

# モデル推論
prediction = model.predict([features])

学習時と同じFeature View定義で、推論時にもOnline Storeから特徴量を取得します。「定義のずれ」が物理的に発生しないのがFeature Storeの価値です。

dbtとの連携

多くの組織で、特徴量の元データはdbtで作るSilver/Goldテーブルです。Feastはこれらのテーブルを直接Offline Sourceとして参照できます。dbtで集計したテーブルがそのまま特徴量定義の元になる、という自然な役割分担になります。dbtの実装はdbt実装ガイド、incremental設計はincremental models設計を参照してください。

Tecton等の商用代替

FeastはOSSで運用負担はありますが、コストとロックイン回避が強みです。Tectonは商用で運用が楽な一方で費用がかかります。Vertex AI Feature StoreやSageMaker Feature Storeなどのクラウド組込みもあり、選択肢は広がっています。

向く・向かない場面

• 向く：複数モデルで特徴量を共有、リアルタイム推論で過去集計が必要、データリーケージを物理的に防ぎたい、OSSで自社運用したい
• 向かない：モデルが1〜2個で特徴量共有のニーズが低い、運用人員が薄い（→Tecton/クラウド組込み）、推論がバッチで完結（→dbtテーブルで足りる）

まとめ

• Feastは「学習と推論で同じ特徴量を使う」OSS Feature Store。
• Offline（学習用・バッチ）とOnline（推論用・低遅延）を統合管理。
• Feature View定義で、データソースから特徴量への変換とTTLを宣言する。
• Point-in-time correctnessでデータリーケージを物理的に防ぐ。
• dbtテーブルを自然なソースとして使え、データ基盤との統合がしやすい。

全体像はMLOpsツール選び方ガイド、隣接の選択肢はMLflow とは・クラウドMLOpsプラットフォーム比較にあります。Feature Store導入や設計の壁打ちは、DE-STKの初回相談（30分・無料）もご利用ください。

よくある質問（FAQ）

Q. dbtテーブルでFeature Storeの代わりになりませんか？

A. バッチ推論ならdbtで作ったテーブルで足ります。「リアルタイム推論で過去の集計値が必要」「複数モデルで特徴量を共有」「Point-in-time correctnessを物理的に保証したい」場面でFeature Storeの価値が出ます。最初はdbtテーブルで運用し、痛みが出てから導入するのが現実的です。

Q. Online Storeに何を選ぶべき？

A. 「速さと運用のしやすさ」のバランスで選びます。Redisは速くてシンプル、DynamoDBはAWSなら運用が楽、Cassandraは超大規模に強い、といった違いがあります。中小規模ならRedisが無難な選択です。「最大同時推論数」「許容遅延」「データ量」で要件を出し、それに合うストレージを選びます。

Q. Streaming Feature（リアルタイム特徴量）も扱えますか？

A. 扱えますが、Feast単体ではストリーム処理エンジンの代わりはしません。Kafka→Flink→Online Storeのパイプラインを組み、Feastの定義に紐付ける構成が一般的です。ストリーミング基盤はバッチ vs ストリーミングの選び方を参照してください。

Q. クラウドのFeature Store（Vertex AI、SageMaker等）との違いは？

A. クラウドのものはマネージドで運用負担が小さい一方でベンダーロックインがあります。Feastはマルチクラウド・マルチストレージ対応で、ロックイン回避が強みです。「クラウドを横断したい」「ロックインを避けたい」ならFeast、「単一クラウドで素早く運用したい」ならクラウド組込み、と分かれます。