はじめに
前回までは、SageMaker の推論方式や Model Monitor、Data Drift について整理しました。
今回からは、もう少し MLOps 寄りの内容として、
SageMaker Feature Store について整理します。
機械学習では、モデルそのものだけでなく、
モデルに入力する 特徴量（feature） をどのように作り、管理し、再利用するかが非常に重要です。
実務では、以下のような問題がよく起きます。
- 学習時と推論時で特徴量の作り方が違う
- 同じ特徴量をチームごとに別々に作っている
- 特徴量の定義がどこにあるか分からない
- 過去に使った特徴量を再利用しにくい
- 本番推論で必要な特徴量をすぐ取得できない
- 特徴量の管理が属人化している
このような問題を解決するために使われるのが Feature Store です。
本記事では、
- Feature Store とは何か
- なぜ特徴量を管理する必要があるのか
- Online Store と Offline Store の違い
- 学習時と推論時で同じ特徴量を使う重要性
- Data Leakage との関係
- 実務や試験での見られ方
を、初心者にも分かりやすく整理します。
🎯 対象読者
- SageMaker Feature Store の役割を整理したい方
- 特徴量管理の考え方を理解したい方
- Online Store と Offline Store の違いが曖昧な方
- AWS の AI / ML 系資格を勉強している方
- MLOps の基礎を学びたい方
🧩 まず結論：Feature Store は「特徴量を管理・再利用するための場所」
Feature Store は、簡単に言うと、
機械学習で使う特徴量を保存し、管理し、再利用するための仕組み です。
一言で言うと、以下のように覚えると分かりやすいです。
Feature Store = 特徴量の保管場所・管理場所
特徴量は、モデルが予測を行うための入力情報です。
たとえば、顧客の解約予測モデルであれば、以下のようなものが特徴量になります。
- 年齢
- 会員ランク
- 過去30日のログイン回数
- 最終購入からの日数
- 過去6か月の購入金額
- サポート問い合わせ回数
- キャンペーン反応率
Feature Store を使うと、このような特徴量を一元的に管理し、
学習や推論で再利用しやすくなります。
🧠 そもそも特徴量とは？
特徴量とは、
モデルが予測を行うために使う入力データ のことです。
英語では feature と呼ばれます。
たとえば、EC サイトで「この顧客が商品を購入するか」を予測したい場合、
モデルは以下のような情報を見て判断します。
| 特徴量 | 説明 |
|---|---|
| age | 顧客の年齢 |
| purchase_count_30d | 過去30日の購入回数 |
| total_spend_180d | 過去180日の購入金額 |
| days_since_last_purchase | 最終購入からの日数 |
| page_view_count_7d | 過去7日の閲覧回数 |
| membership_rank | 会員ランク |
このような特徴量をもとに、モデルは
この顧客は購入しそうか
この顧客は解約しそうか
この取引は不正の可能性があるか
を予測します。
つまり、特徴量の品質はモデルの性能に直結します。
📌 なぜ Feature Store が必要なのか？
小さな学習実験であれば、特徴量を notebook の中で作って、そのままモデルに入れるだけでも十分かもしれません。
しかし、実務で機械学習を運用し始めると、特徴量管理には多くの課題が出てきます。
問題 1：同じ特徴量を何度も作ってしまう
たとえば、複数のチームがそれぞれ
過去30日の購入回数
最終ログインからの日数
過去6か月の購入金額
のような特徴量を使いたいとします。
Feature Store がない場合、それぞれのチームが別々に SQL や ETL を書いて特徴量を作ることがあります。
その結果、
- 定義が微妙に違う
- 計算タイミングが違う
- 欠損値処理が違う
- 再利用しにくい
という問題が起きます。
Feature Store を使うと、共通で使う特徴量を一元管理し、
他のモデルやチームでも再利用しやすくなります。
問題 2：学習時と推論時で特徴量がずれる
機械学習で非常に重要なのが、
学習時と推論時で同じ定義の特徴量を使うこと です。
たとえば、学習時には
過去30日の購入回数
を使っていたのに、本番推論では誤って
過去7日の購入回数
を使ってしまうと、モデルの入力の意味が変わってしまいます。
このようなズレが起きると、モデルの予測精度が下がります。
Feature Store を使うと、特徴量の定義を管理し、
学習時と推論時で同じ特徴量を使いやすくなります。
問題 3：特徴量の履歴を管理しにくい
モデル学習では、過去のある時点における特徴量が必要になることがあります。
たとえば、2024年1月時点の顧客情報を使って、
2024年2月に解約したかどうかを学習したい場合です。
このとき、未来の情報が混ざってしまうと、モデル評価が不自然に高くなる可能性があります。
Feature Store では、特徴量を管理し、
学習用データを作るときに過去時点のデータを扱いやすくなります。
🏗 SageMaker Feature Store の基本イメージ
SageMaker Feature Store では、特徴量を Feature Group という単位で管理します。
Feature Group は、簡単に言うと、
関連する特徴量をまとめたテーブルのようなもの です。
たとえば、顧客特徴量であれば、以下のようなイメージです。
| customer_id | age | purchase_count_30d | total_spend_180d | days_since_last_purchase |
|---|---|---|---|---|
| C001 | 35 | 5 | 120000 | 3 |
| C002 | 42 | 1 | 30000 | 28 |
| C003 | 29 | 8 | 210000 | 1 |
このように、1つの Feature Group に顧客関連の特徴量をまとめて保存します。
🔑 Record Identifier と Event Time
Feature Store では、特徴量を管理するときに、
以下のような情報が重要になります。
| 項目 | 説明 |
|---|---|
| Record Identifier | レコードを一意に識別する ID |
| Event Time | その特徴量が発生・観測された時刻 |
たとえば、顧客特徴量の場合は、
Record Identifier = customer_id
Event Time = 特徴量が作成・更新された時刻
のように考えます。
Event Time は、時系列で特徴量を管理したり、
過去時点のデータを使って学習データを作ったりするときに重要です。
⚡ Online Store とは？
Online Store は、
リアルタイム推論で使うために、特徴量を低遅延で取得する保存先 です。
一言で言うと、以下です。
Online Store = 本番推論用にすぐ特徴量を取り出す場所
たとえば、ユーザーが Web サイトで操作した瞬間に、
そのユーザーの特徴量を取得して、リアルタイムに予測したい場合があります。
ユーザーが画面操作
↓
customer_id で Online Store から特徴量を取得
↓
Endpoint に特徴量を送信
↓
モデルがリアルタイム予測
↓
結果を返す
このように、低レイテンシーで特徴量を取得したい場合に Online Store が向いています。
✅ Online Store が向いている場面
| 場面 | 理由 |
|---|---|
| リアルタイム推論 | すぐに特徴量を取得したい |
| Web API からの予測 | ユーザー操作に即時応答する必要がある |
| 不正検知 | 取引発生時にすぐ判断したい |
| レコメンド | その場でおすすめを返したい |
| 低レイテンシーが必要 | 推論前に素早く特徴量を取得したい |
Online Store は、Endpoint と組み合わせて使うイメージを持つと分かりやすいです。
🗄 Offline Store とは？
Offline Store は、
学習用データの作成や分析に使うために、特徴量を保存する場所 です。
一言で言うと、以下です。
Offline Store = 学習・分析用に特徴量を保存する場所
大量の履歴データを保存し、モデル学習やバッチ分析で使います。
たとえば、過去1年分の顧客特徴量を使ってモデルを学習したい場合、
Offline Store からデータを取得して training dataset を作成します。
✅ Offline Store が向いている場面
| 場面 | 理由 |
|---|---|
| モデル学習 | 過去データを使って training dataset を作る |
| 分析 | 特徴量の傾向を調べる |
| バッチ推論 | 大量データをまとめて処理する |
| 履歴管理 | 過去時点の特徴量を扱う |
| 再学習 | 新しいデータを使ってモデルを更新する |
Offline Store は、リアルタイム取得よりも、
学習や分析のために大量データを扱う用途に向いています。
🧭 Online Store と Offline Store の違い
Online Store と Offline Store の違いを整理すると、以下のようになります。
| 項目 | Online Store | Offline Store |
|---|---|---|
| 主な用途 | リアルタイム推論 | 学習・分析・再学習 |
| データ取得 | 低レイテンシー | 大量データ処理向け |
| 使う場面 | Endpoint で即時予測 | Training Job や分析 |
| データ量 | 直近・必要な特徴量中心 | 履歴データを含む |
| イメージ | すぐ取り出す | まとめて使う |
覚え方は以下です。
Online Store = 今すぐ使う特徴量
Offline Store = 学習や分析に使う特徴量
🔁 Training と Inference で同じ特徴量を使う重要性
Feature Store の大きな価値の1つは、
training と inference で特徴量の定義をそろえやすいこと です。
機械学習では、学習時と推論時で入力データの意味が違うと、
モデルの性能が大きく落ちる可能性があります。
たとえば、学習時には以下を使っていたとします。
purchase_count_30d = 過去30日の購入回数
しかし、本番推論で以下を使ってしまったとします。
purchase_count_7d = 過去7日の購入回数
この場合、列名が似ていても意味が違います。
モデルは「30日分の購入回数」として学習しているため、
「7日分の購入回数」を入力すると予測がずれる可能性があります。
Feature Store を使うと、特徴量の定義を一元管理し、
このような training-serving skew を減らしやすくなります。
⚠️ Data Leakage との関係
Feature Store を使うときに注意したいのが Data Leakage です。
Data Leakage とは、
本来モデルが学習時に使ってはいけない情報が混ざってしまうこと です。
たとえば、解約予測モデルを作る場合を考えます。
目的：来月解約するかを予測したい
このとき、学習データに
解約後に発生した問い合わせ履歴
解約後に更新されたステータス
未来の購入情報
のような情報が混ざってしまうと、モデルは未来を見て学習していることになります。
その結果、検証時の精度は高く見えるかもしれませんが、
本番では同じ情報が使えないため、性能が大きく落ちます。
Feature Store を使う場合も、Event Time やデータの時点を正しく扱い、
未来情報を混ぜないことが重要です。
🧪 Feature Store の具体例：解約予測
解約予測モデルで Feature Store を使う例を考えます。
使いたい特徴量
| 特徴量 | 説明 |
|---|---|
| login_count_30d | 過去30日のログイン回数 |
| support_ticket_count_90d | 過去90日の問い合わせ件数 |
| days_since_last_login | 最終ログインからの日数 |
| plan_type | 契約プラン |
| monthly_fee | 月額料金 |
学習時
Offline Store から過去の特徴量を取得し、
解約ラベルと組み合わせて training dataset を作ります。
Offline Store
↓
training dataset 作成
↓
Training Job
↓
モデル学習
推論時
本番では、customer_id をもとに Online Store から最新の特徴量を取得し、
Endpoint に渡して予測します。
customer_id
↓
Online Store から特徴量取得
↓
Endpoint で解約確率を予測
↓
結果をアプリや業務システムで利用
このように、Feature Store は学習と推論の両方で使えます。
☁️ AWS 試験での見られ方
AWS の AI / ML 系試験では、Feature Store は MLOps や特徴量管理の文脈で出てきやすいです。
特に、以下のようなキーワードが出たら意識するとよいです。
「特徴量を再利用したい」
複数のモデルやチームで同じ特徴量を使いたい場合は、Feature Store が候補になります。
特徴量の一元管理
再利用
標準化
「学習時と推論時で同じ特徴量を使いたい」
training-serving skew を減らしたい場合、Feature Store が役立ちます。
Training と Inference で同じ特徴量定義を使う
「リアルタイム推論で特徴量を低遅延取得したい」
この場合は Online Store を考えます。
Online Store = リアルタイム推論向け
「学習用に大量の履歴特徴量を使いたい」
この場合は Offline Store を考えます。
Offline Store = 学習・分析向け
👨💻 実務目線で見ると
実務では、Feature Store は単なる保存先ではありません。
むしろ、以下のような目的で重要になります。
- 特徴量定義をチームで共有する
- 同じ特徴量を再利用する
- 学習時と推論時のズレを減らす
- 過去時点の特徴量を管理する
- 再学習をしやすくする
- 特徴量の品質を管理する
特に、複数のモデルを運用するようになると、
特徴量の管理はかなり重要になります。
最初は notebook 内で特徴量を作るだけでも問題ないかもしれませんが、
実務でモデルが増えてくると、Feature Store の価値が大きくなります。
🧠 ここは特に覚えたいポイント
覚え方 1
Feature Store = 特徴量を保存・管理・再利用する場所
覚え方 2
Online Store = リアルタイム推論用
Offline Store = 学習・分析用
覚え方 3
Training と Inference で同じ特徴量定義を使うことが重要
覚え方 4
Feature Group = 関連する特徴量をまとめた単位
覚え方 5
Event Time を正しく扱い、Data Leakage を防ぐ
✅ まとめ
今回は、SageMaker Feature Store について整理しました。
重要なポイントは以下です。
- Feature Store は、特徴量を保存・管理・再利用するための仕組み
- 特徴量は、モデルが予測に使う入力情報
- Feature Group は、関連する特徴量をまとめて管理する単位
- Online Store は、リアルタイム推論で低遅延に特徴量を取得するために使う
- Offline Store は、モデル学習、分析、再学習で大量の履歴特徴量を使うために使う
- Training と Inference で同じ特徴量定義を使うことが重要
- Feature Store は、training-serving skew を減らすのに役立つ
- Event Time を正しく扱い、Data Leakage を防ぐ必要がある
機械学習では、モデルだけでなく、
特徴量をどう作り、どう管理し、どう再利用するか が非常に重要です。
Feature Store は、そのための MLOps 的な基盤として理解すると分かりやすいです。
📌 次回予告
次回は、MLOps の中心的なテーマである
- SageMaker Pipelines
- ML ワークフローの自動化
- 前処理、学習、評価、デプロイの流れ
について整理します。
機械学習を一度きりの作業ではなく、再現性のあるパイプラインとして管理する考え方を見ていきます。