Amazon SageMaker Feature Store、更新レコード機能「UpdateRecord」を導入

Amazon SageMaker Feature Store に、レコードレベルではなく特徴量（フィーチャー）単位での書き込み機能「UpdateRecord」が追加されました。

Amazon SageMaker Feature Store は、機械学習（ML）モデルの訓練や予測生成に使用される処理済みデータである「特徴量」を保存・共有・管理するために設計された、フルマネージド型の専用リポジトリです。新しく導入された UpdateRecord API を利用すれば、レコード全体を読み込んで書き直すことなく、単一の呼び出しで 1 つ以上の特定の特徴量の値を更新できるようになりました。この機能は、Amazon DynamoDB にバックエンドを持つ「Standard」ティアと、Amazon ElastiCache にバックエンドを持つ「In-Memory」ティアの両方で利用可能です。

すべての変更に対してレコード全体を書き込むという課題

Feature Group（特徴量グループ）とは、関連する特徴量の論理的な集合体であり、1 つ以上の ML モデルによって、新しいモデルの訓練や推論予測の生成に使用されます。これまで、Feature Group 内の単一の特徴量の値を更新する場合でも、PutRecord を用いて「読み取り→修正→書き込み」のフルサイクルを実行する必要がありました。

例えば、不正検出パイプラインで顧客の risk_score（リスクスコア）を更新する必要がある場合、アプリケーションは次の手順を踏まなければなりませんでした。

完全なレコード（全特徴）を取得するには、GetRecord を使用します。

新しい値はアプリケーション側でマージ処理を行います。

その後、PutRecord を用いてレコード全体を書き戻します。

このパターンでは、更新ごとに追加のレイテンシが発生し、不要な読み取り容量を消費するだけでなく、複数のパイプラインが同じレコード内の異なる特徴を同時に更新しようとした際に競合状態（race condition）を引き起こすリスクがあります。最悪の場合、あるパイプラインによる書き込みが別のパイプラインの結果を静かに上書きしてしまうという「失われた更新」の問題が発生します。

レイテンシや整合性の問題に加え、読み取り→修正→書き戻しというパターンにはコスト増の課題もあります。各書き込み処理の前に必要な追加の GetRecord 呼び出しにより、Read Capacity Units (RCUs) の使用量が増え、課金額が嵩みます。大規模な特徴グループを扱い、更新頻度が高い環境で運用している顧客にとっては、これらのコストはすぐに大きな負担となります。

UpdateRecord の紹介

UpdateRecord API は、読み取り→修正→書き戻しのサイクルを不要にします。変更したい特徴のみを指定すればよく、Amazon SageMaker Feature Store が既存のレコードに対して原子性を持って更新を適用します。リクエストに含まれていない特徴は、そのまま保持されます。

UpdateRecord API のデータフロー

以下の図は、UpdateRecord API が部分的な書き込みリクエストを処理し、オフラインストアと同期する様子を示しています。

図 1: UpdateRecord API のオンラインおよびオフラインストアへのデータフロー

クライアントアプリケーションは、変更された特徴量のみを指定して UpdateRecord API を呼び出します。Feature Store サービスは、AWS Identity and Access Management (IAM) の権限を検証し、EventTime の順序を確認して古い書き込みを拒否した後、アトミックなマージ処理を実行します。

青い矢印は、変更された特徴量のみをオンラインストアに書き込む単一の操作を表しています。一方、完全なレコードのスナップショットは自動的にオフラインストアへ複製され、トレーニングデータの正確性が保たれます。クリックストリーム、購入履歴、スコアリングなど複数のパイプラインがそれぞれ独立して同じレコードに特徴量を書き込むことも可能ですが、これら間の調整は不要です。

リクエストの形状

POST /FeatureGroup/{FeatureGroupName}/Record

{
  "RecordIdentifierValueAsString": "user_123",
  "Features": [
    { "FeatureName": "risk_score", "ValueAsString": "0.87" },
    { "FeatureName": "last_login", "ValueAsString": "2026-07-21T08:15:00Z" }
  ],
  "TtlDuration": {  // optional
    "Unit": "Days",
    "Value": 30
  }
}

• FeatureGroupName — 対象となる特徴量グループを指定します。
• RecordIdentifierValueAsString — 更新するレコードの主キーです。この API は既存のレコードを更新するためのものであり、存在しないレコードを作成するアップサート機能ではありません。
• Features — 設定する 1 つ以上の値を持つ特徴量のリストです。1 回の呼び出しで最大 100 個まで指定できます。
• TtlDuration (オプション) — レコードごとの有効期限 (TTL) を上書きまたは設定します。このパラメータを指定する場合、EventTime も同時に含める必要があります。

EventTime の更新

レコードに保存される EventTime（必須フィールドの 1 つ）も更新したい場合は、*Features* パラメータリストで新しい値を指定してください。この変更を確実に反映させるには、指定する EventTime が既存の記録よりも新しいタイムスタンプ（より後の時刻）である必要があります。そうでない場合、HTTP 409 エラーが発生し、更新レコードの呼び出し自体が拒否されます。

エラーの詳細については、こちら のドキュメントをご覧ください。

知っておくべきこと：新しいストレージ形式 Standard_V2

AWS SageMaker Feature Store のオンラインストレージ は従来、バックエンドストレージプロバイダが異なる 2 つのティアを提供していました。*Standard Tier* は Amazon DynamoDB を基盤としており、*In-Memory Tier* は Amazon ElastiCache (Redis OSS) を基盤としています。

現在、Standard Tier の新しいストレージ形式として Standard_V2 が導入されました。これはシリアライズフォーマットが異なり、フィーチャーレベルでの書き込みなど、追加の機能をサポートしています。

注意: In-Memory タイプを使用している場合、新しいストレージタイプは不要です。既存のすべての In-Memory 特徴グループで、標準設定のまま特徴レベルでの書き込みが可能になります。

Standard タイプで特徴レベルでの書き込みを利用するには、新しい Standard_V2 ストレージ形式が必要です。この形式は特徴グループ作成時に以下の構文でオプトインします：

import boto3

sm = boto3.client("sagemaker")

sm.create_feature_group(
    FeatureGroupName="user-profile-fg",
    RecordIdentifierFeatureName="user_id",
    EventTimeFeatureName="event_time",
    OnlineStoreConfig={
        "EnableOnlineStore": True,
        "StorageType": "Standard_V2"  # enables feature-level writes
    },
    FeatureDefinitions=[
        {"FeatureName": "user_id", "FeatureType": "String"},
        {"FeatureName": "event_time", "FeatureType": "String"},
        {"FeatureName": "risk_score", "FeatureType": "Fractional"},
        {"FeatureName": "last_login", "FeatureType": "String"},
        {"FeatureName": "balance", "FeatureType": "Fractional"},
    ],
)

既存の特徴グループを Standard から Standard_V2 へ移行する

すでに元の Standard ストレージタイプ上にある特徴グループをお持ちの場合、Standard_V2 へ移行することで特徴レベルでの書き込みの恩恵を受けつつ、Standard タイプが持つ機能はそのまま維持できます。以下のセクションでは、2 つの移行戦略について説明します。どちらを選ぶかは、ダウンタイムへの許容度、移行タイミングの希望、ロールバックオプションの有無によって決定してください。

戦略 A：Feature Processor による一括移行

• Feature Processor SDK を使用して、既存の Standard 特徴グループからレコードを読み取り、新しい Standard_V2 特徴グループへ再取り込みします。

• メリット：移行タイミングを自分で制御できます。移行中は元の特徴グループがそのまま残ります。ロールバックも容易で、古い特徴グループに戻すだけで済みます。

• デメリット：管理された移行ジョブが必要です。データセット全体について、読み書きのコストを事前にすべて支払う必要があります。また、アプリケーションのクライアント側で、新しい特徴グループ名を指すように設定を変更する必要があります。

戦略 B：UpdateFeatureGroup API を用いたインプレイス制御済み切り替え

OnlineStoreConfig.StorageType = "Standard_V2" を指定して UpdateFeatureGroup を呼び出すことで、フィーチャーグループのストレージ形式をインプレイスで切り替えることができます。

import boto3
sm = boto3.client("sagemaker")

sm.update_feature_group(
    FeatureGroupName="my-existing-fg",
    OnlineStoreConfig={"StorageType": "Standard_V2"}
)

フィーチャーグループが Standard_V2 形式であると宣言された後、PutRecord または BatchWriteRecord の呼び出しにより、基盤となるデータフォーマットも自動的に Standard_V2 に更新されます。

このアプローチではダウンタイムは発生せず、実際に書き換えられたレコードに対してのみ移行コストが発生します。また、フィーチャーグループ名や API エンドポイントが変更されないため、既存のアプリケーションコードをそのまま維持できます。ただし、Standard_V2 への切り替えは不可逆であり、一度も書き込まれないコールドデータは、アクセスされるまでレガシー形式のまま残ります。

推奨事項：ほとんどの顧客にとって、戦略 B（インプレイスでの UpdateFeatureGroup）が、ダウンタイムゼロと「触れた分だけ課金」という経済性から最も適したアプローチです。完全に可逆的な移行経路が必要である場合や、フィーチャーグループの名前変更・再構築が必要な場合に限り、戦略 A を使用してください。

EventTime：組み込まれた時系列順序付け

UpdateRecord は、PutRecord と同様に EventTime ベースの順序付けをサポートしています。リクエストに EventTime を含める場合:

• 指定された EventTime がレコードの現在の EventTime よりも新しい、または等しい場合、更新が適用され、レコードの EventTime は進みます。
• 指定された EventTime がレコードの現在の EventTime よりも古い場合、409 ConflictException で更新は拒否されます。これにより、古びたデータや順序が入れ替わったイベントが、より新しいデータを上書きするのを防ぎます。

EventTime を省略すると、更新は新しい特徴値を適用する一方で、レコードに既に存在する EventTime は変更されません。これは、異なるパイプラインがそれぞれ別の特徴を担当し、共通のイベントクロックを共有しないマルチパイプラインアーキテクチャにおいて特に有効です。

使用例

以下のユースケースは、UpdateRecord が一般的な特徴エンジニアリングワークフローをどのように簡素化するかを示しています。

ストリーミング特徴のハイドレーション

リアルタイムおよびストリーミングシナリオでは、通常、異なる頻度で発生する複数のストリームによって生成されたデータを必要とします。

シナリオ: リアルタイムのクリックストリームパイプラインは、数秒ごとに page_views と session_duration のデータを受信し、夜間のバッチパイプラインも...

lifetime_value と customer_segment のデータを更新します。

UpdateRecord を利用すれば、各パイプラインは自分が所有する特徴量のみをコアレコードに送信すればよく、他との調整や更新の消失を気にする必要がありません。

新しい特徴量のバックフィル

Amazon SageMaker Feature Store を利用すれば、フィーチャーグループを支えるテーブルスキーマを変更し、新しい列（フィーチャー）を追加することが可能です。

シナリオ: チームが既存のフィーチャーグループに preferred_language と notification_opt_in を追加したとします。すべてのレコードを書き換える代わりに、UpdateRecord を呼び出して新規フィールドの値のみを指定すれば済みます。これにより、既存のフィーチャー値はそのまま維持されます。

大規模なエラー修正

データサイエンスや MLOps のチームが、既存の機能データの不一致に気づいた場合、それを効率的に修正するための措置を講じることができるようになりました。

シナリオ: データ品質ジョブが customer_segment 属性を 50,000 件のレコードで誤分類していることを発見しました。UpdateRecord を使えば、他の特徴値の破損リスクを負うことなく、数千件にわたるレコード内の単一フィールドのみを修正できます。

高速な特徴更新

Feature Groups（特徴グループ）には、生成や取得のタイミングが異なる複数のトランザクションデータフィールドが含まれていることが一般的です。

シナリオ: 不正検知システムはカードスワイプごとに transaction_velocity を受け取ります。UpdateRecord を使えば、各書き込みで変更された単一の特徴のみを処理できるため、大規模な環境でもレコード全体を書き込む際のオーバーヘッドを排除できます。

エンタープライズ向けマルチプロデューサー特徴グループ

大規模組織では、Feature Store（特徴ストア）の設計を中核となるビジネスエンティティに合わせることが多く、各エンティティタイプごとに 1 つの特徴グループを設け、数十もの独立したプロデューサーが同じレコードへ特徴を提供する構成をとります。

シナリオ: 企業は、ビジネスエンティティ（顧客、保険契約、車両など）ごとに単一のフィーチャーグループを維持しています。このグループには数百万件のレコードと、異なるチームやバッチ ETL ジョブ、ストリーミング分析、リアルタイムスコアリングエンジンによって生成された数百のフィーチャーが含まれています。

UpdateRecord を使用しない場合、各プロデューサーは完全なレコードを読み取り、自身のサブセットを挿入してエンティティ全体を書き戻す必要があります。これにより、コンパクションジョブの実行や競合状態が発生し、読み書き操作にかかる月額コストが増大します。

一方、UpdateRecord を利用すれば、各プロデューサーは自身のフィーチャーのみを原子的に記述できます。これにより、カスタムコンパクションソリューションの必要性がなくなります。

細粒度アクセス制御

UpdateRecord は IAM と連携するため、どのユーザーがどの特徴量を更新できるかを厳密に制御できます。新たに 2 つの IAM 条件キーが追加されました。

• sagemaker:IsUpdateRecord (Bool) — 部分更新操作と完全な PutRecord 書き込みを区別します。

• sagemaker:UpdatableFeatures (ArrayOfString) — プリンシパルが更新できる特徴量名を制限します。

例：機密性のある機能への更新を禁止する

{
  "Effect": "Allow",
  "Action": "sagemaker:PutRecord",
  "Resource": "arn:aws:sagemaker:*:*:feature-group/user-profile-fg",
  "Condition": {
    "Bool": { "sagemaker:IsUpdateRecord": "true" },
    "ForAllValues:StringEquals": {
      "sagemaker:UpdatableFeatures": ["age", "score", "last_activity"]
    }
  }
}

このポリシーにより、主体は age、score、last_activity に対して UpdateRecord を呼び出すことができますが、それ以外の機能への更新はブロックされます（例：

「SSN」や「給与情報」などの機密データをブロックし、直接の PutRecord 呼び出しを制限します。 （原文の技術表記: ssn、salary）

完全に互換性を保つ。

後方互換性

SageMaker:PutRecord を拒否する既存の IAM ポリシーは、UpdateRecord にも自動的に適用されます。セキュリティ制御を有効にするために顧客が移行を行う必要はありません。

オフラインストアとの連携

UpdateRecord を通じて行われた更新は、PutRecord が使用するのと同じレプリケーションパイプラインを通じてオフラインストアに自動反映されます。各更新では完全なレコードスナップショットがオフラインストアへ送信されるため、正確なトレーニングデータセットや履歴分析を維持しやすくなります。

• レコードの存在が必要 UpdateRecord は厳密に修正操作です。まずは PutRecord を呼び出してレコードを作成してください。
• 特徴量の定義が必要 特徴グループのスキーマに含まれていない特徴量を追加することはできません。スキーマに準拠した完全な書き込みには PutRecord を使用してください。
• レコード識別子は不変 UpdateRecord を使って主キーを変更することはできません。
• TTL には EventTime の指定が必要 TtlDuration を指定する場合は、リクエスト内に必ず EventTime も含めてください。

料金

UpdateRecord は PutRecord と同じ課金モデルを採用しています。Standard タイプでは、DynamoDB の書き込み容量ユニット (WCU) 料金は更新後のアイテムサイズに基づいて計算されます。ただし、従来の「読み取り→修正→書き込み」パターンで必要だった読み取り容量の費用は節約できます。詳細については Amazon SageMaker Feature Store の料金ページ をご確認ください。

今日から始めよう

Amazon SageMaker Feature Store の「UpdateRecord」機能による特徴量レベルの書き込みが、SageMaker Feature Store が提供されているすべての AWS リージョンで利用可能になりました。使い始めるには以下の手順に従ってください。

• StorageType に Standard_V2（Standard タイア）を指定して特徴量グループを作成するか、既存の In-Memory 特徴量グループを使用します。
• 通常通り PutRecord を使用してレコードを取り込みます。
• UpdateRecord を呼び出して、レコード全体を書き換えることなく個別の特徴量を更新できます。

詳細については、『Amazon SageMaker Feature Store 開発者ガイド』および『UpdateRecord API リファレンス』をご覧ください。

結論

UpdateRecord API を使用した特徴量レベルの書き込みにより、以前は部分的な更新ごとに数ミリ秒の遅延を引き起こしていた「読み取り→修正→書き込み」のサイクルが不要になりました。これにより、単一の特徴量の更新における遅延とデータ転送コストを削減でき、複数のパイプラインを持つアーキテクチャで更新が失われるリスクも最小限に抑えられます。

細粒度の IAM コントロールやオフラインストアの自動レプリケーションと組み合わせることで、より効率的で信頼性の高い特徴量エンジニアリングワークフローを構築できます。リアルタイムで単一のリスクスコアを更新する場合でも、共有される企業全体の特徴量グループへ数十の独立したプロデューサーが書き込む場合でも、UpdateRecord は生データから本番環境対応の特徴量への道筋を簡素化します。

詳細については、Amazon SageMaker Feature Store の開発者ガイド（Amazon SageMaker Feature Store Developer Guide）および API リファレンス（