Amazon SageMaker UpdateRecord、部分的な特徴量変更におけるレコード全体の書き換えを不要に

Amazon SageMaker UpdateRecordは特徴量レベルの書き込みを導入し、部分的な変更のたびにレコード全体を読み取り、書き換えるという長年の要件を解消する。1回のAPI呼び出しで最大100個の特徴量を更新でき、リクエストから省略されたすべての特徴量は保持される。

この変更は、リアルタイム機械学習インフラにおける特定の弱点を対象としている。特徴量レコードは、多くの場合、それぞれ異なるスケジュールで稼働する別々のパイプラインが生成した値を組み合わせている。たとえばクリックストリーム処理は数秒ごとにアクティビティを更新し、夜間ジョブは顧客セグメントを更新する。

これまで、こうしたパイプラインは読み取り・変更・書き込みのパターンに依存することが多かった。各プロデューサーは現在のレコードを取得し、担当フィールドを変更してから、完全なレコードを再送信していた。このパターンは読み取りを増やし、変更されていないデータも転送し、同時書き込みを行う処理同士が互いの変更を上書きする機会を生んでいた。

AWSはこの経路をアトミックな部分更新メカニズムに置き換える。サービスは権限と任意のイベント時刻順序を適用しながら、選択された値を既存レコードにマージする。本質は、SageMakerのエンドポイントがもう1つ増えたことではない。AWSが調整ロジックを顧客アプリケーションからマネージド特徴量ストアへ移している点にある。

Amazon SageMaker UpdateRecordが書き込み経路を変える

UpdateRecordは、部分的な特徴量変更を、顧客側で調整する読み取り、マージ、全体書き換えではなく、単一のマネージド書き込みに変える。

AWSは2026年9月8日に特徴量レベルの書き込みを発表した。この機能は、SageMaker Feature Storeが稼働するAWSリージョンで利用できる。

クライアントは既存レコードを特定し、変更が必要な特徴量の値だけを送信する。SageMaker Feature Storeはリクエストを検証し、それらの値をアトミックにマージし、省略されたすべての特徴量を変更せずに残す。

特徴量レコードは幅広い情報を含み得るため、この動作は重要だ。顧客プロファイルには、アカウント履歴、直近のアクティビティ、リスクシグナル、レコメンデーション、運用メタデータが含まれる場合がある。1つのリスクスコアを更新するために、アプリケーションが無関係な値すべてを転送し、書き換える必要はない。

APIは少なくとも1つの特徴量を受け付け、1回の呼び出しで最大100個の特徴量をサポートする。UpdateRecord APIによると、更新が成功すると空のHTTP 200レスポンスを返す。

UpdateRecordはupsert操作ではない。対象レコードはオンラインストアにすでに存在している必要があり、存在しないレコードまたは論理削除されたレコードではResourceNotFoundエラーが発生する。レコード作成時には引き続きPutRecordを使用する必要がある。

レコード識別子も不変のままである。クライアントは、定義された条件下でイベント時刻の特徴量を含む保存済み特徴量を更新できるが、このエンドポイントで主キーを変更することはできない。

特徴量名は、特徴量グループのスキーマにすでに存在していなければならない。UpdateRecordはスキーマ内の値を変更するものであり、新しい特徴量を定義する別経路を提供するものではない。

こうした境界により、APIの役割は明確に保たれる。既存オンラインレコードに対する部分変更を扱い、レコード作成とスキーマ管理は別の操作として維持される。

ストレージ要件にも同等の注意が必要だ。標準オンラインストアは、部分更新を受け付ける前に新しいStandard_V2形式を使用する必要がある。インメモリ特徴量グループは、別のインメモリストレージ形式を採用せずにUpdateRecordをサポートする。

AWSはStandardをDynamoDBベースのオンライン階層、In-MemoryをRedis OSSを使用するElastiCacheベースの選択肢として説明している。同社の更新されたオンラインストアガイドでは、Standard、Standard_V2、InMemoryが異なる選択肢として列挙されている。

この違いにより、今回の発表は単なるSDKの利便性向上にとどまらない。AWSは、残りのレコードを保持しながら部分更新を適用できるストレージ表現を追加する必要があった。

したがってStandardの顧客にとって、このアーキテクチャ上の利点は形式選択とともにもたらされる。特徴量グループを作成するチームはStandard_V2を選択できる一方、既存のStandard導入環境は、文書化された移行経路とその運用上の影響を評価する必要がある。

読み取り・変更・書き込みパターンこそが真の相手だった

今回のリリースでAWSが対抗しているのは、別の特徴量ストアベンダーではなく、アプリケーションの設計パターンである。

1つの顧客レコードに書き込む3つのパイプラインを考えてみよう。クリックストリームジョブはpage_views、トランザクションサービスはpurchase_total、モデルパイプラインはrisk_scoreを担当する。

読み取り・変更・書き込みの設計では、各パイプラインはまずレコード全体を取得する。担当する値を変更し、その後に完全な置き換えデータをストアへ送信する。

この一連の処理は、書き込み元が1つだけの場合には安全に見える。複数の書き込み元が同時に動作すると、脆弱になる。

クリックストリームパイプラインがバージョンAを読み取るとする。スコアリングパイプラインもその直後に同じバージョンを読み取る。クリックストリームパイプラインは、新しいアクティビティ数を含むバージョンBを書き込む。

その後、スコアリングパイプラインは、変更したバージョンAのコピーを送信できる。アプリケーションが競合を検出しない限り、そのレコード全体への書き込みは、リスクスコアを更新しつつ古いアクティビティ数を復元してしまう可能性がある。

開発者は、オーケストレーション、ロック、条件付きロジック、キュー、または所有権ルールでこの問題に対処できる。だが、どの解決策も特徴量ストアの外側にコードと運用状態を追加する。

UpdateRecordは書き込み対象を限定する。スコアリングパイプラインはrisk_scoreだけを送信し、クリックストリームパイプラインはアクティビティ特徴量だけを送信する。どちらのパイプラインも、もう一方が所有する値を再現する必要はない。

AWSによると、マージはアトミックに行われる。この主張は、1つの部分リクエストに含まれる値の組み合わせが、途中まで書き込まれた状態として公開されるべきではないことを意味する。

アトミック性があらゆるパイプライン設計を正しくするわけではない。それでも、無関係なフィールドを置き換えることで発生する、最も明白な更新消失の原因は取り除く。

この変更により、アプリケーションが既知の値を設定するだけでよい場合、事前のGetRecordリクエストも不要になる。読み取りが減れば、ネットワーク往復回数が減り、Standard階層を通じて課金されるワークロードでは読み取りキャパシティ料金も減少する。

AWSは、普遍的なレイテンシ削減を示す独立ベンチマークを公表していない。実際の削減幅は、レコード幅、リクエスト頻度、ネットワーク配置、再試行動作、アプリケーション設計に左右される。

そのようなベンチマークがなくとも、方向性は明確だ。1回のリクエストで実行されるアプリケーション側の作業は、読み取りの後に完全書き込みを行う場合より少ない。

レコードに多数の特徴量が含まれる一方、各イベントで変わるのが1つか2つだけであれば、ネットワークトラフィックも減少し得る。クライアントは保存済みの全フィールドをシリアライズする代わりに、レコード識別子と変更値を送信する。

書き込み課金には、より細かな理解が必要だ。AWSによると、Standard階層の書き込みキャパシティは、送信した特徴量ペイロードだけでなく、更新後のアイテムサイズに基づく。最も明確な直接的削減は、先行する読み取りをなくすことにある。

SageMakerの料金モデルでは、特徴量ストアの読み取り、書き込み、ストレージが別々に計上される。チームは削減率を見積もる前に、自身のアクセスパターンをモデル化すべきだ。

したがって今回のリリースは、責任を2つのレベルで移す。SageMakerがアトミックな特徴量マージを担う一方、顧客は引き続きワークロード測定とキャパシティ計画を担う。

独立したパイプラインに、より明確な所有権モデルをもたらす

特徴量レベルの書き込みにより、すべてのプロデューサーが完全なレコードを理解しなくても、選択したフィールドを所有できる。

ストリーミング特徴量システムでは、すべての値が同じ頻度で更新されることはほとんどない。セッションアクティビティは継続的に変化し、金融上の合計値はトランザクションに従い、人口統計属性の更新頻度はそれよりはるかに低い場合がある。

単一のレコード全体の契約は、こうしたパイプラインに不要な調整を強いる。各プロデューサーは、すべてのフィールドの最新状態を把握するか、別のコンポーネントが変更をマージすると信頼しなければならない。

UpdateRecordは、より単純な境界を作る。プロデューサーは自らが所有する値を送信し、それ以外を省略できる。特徴量ストアは省略された値を保持する。

この手法は、複数のイベントソースが現在のオンライン表現を徐々に構築するストリーミング特徴量ハイドレーションに適している。クリックイベントは、バッチパイプラインが割り当てたセグメントに触れることなく、セッション統計を更新できる。

バックフィルも別の実用的なケースとなる。スキーマ定義済みの特徴量を追加した後、チームは以前に保存されたすべての特徴量を再送信せずに、その値を既存レコード全体に投入できる。

データ修正も同じ論理に従う。AWSは、50,000件の誤分類された顧客レコードを含むシナリオを説明している。修正ジョブは、それらのレコード内の無関係なフィールドを危険にさらすことなくcustomer_segmentを変更できる。

これらの例は、より大きなアーキテクチャ上の効果を示している。部分更新により、各プロデューサーが安全に書き込む前に必要とする共有コンテキストの量が減る。

また、より限定的な権限もサポートする。AWSは部分書き込みを制御するために、sagemaker:IsUpdateRecordおよびsagemaker:UpdatableFeaturesのIAM条件キーを追加した。

管理者は、選択した特徴量に対してのみサービスがUpdateRecordを呼び出せるようにできる。スコアリングサービスはscoreとlast_activityを更新できる一方、salaryやその他の機密フィールドは変更できないようにできる。

UpdateRecordは、ポリシー評価において引き続きsagemaker:PutRecord IAMアクションを使用する。AWSによると、既存ポリシーでPutRecordを拒否している場合、部分更新もブロックされる。

この後方互換性のある動作により、新しい書き込み経路を意図せず開放するリスクが減る。ワークロードがこの操作を利用する前に、管理者は適切なアクセスを明示的に付与しなければならない。

特徴量レベルの認可は、プロデューサー所有権モデルも強化する。境界はアプリケーションの規律だけに依存しなくなる。IAMは、別のプロデューサーのフィールドを変更しようとするパイプラインを拒否できる。

ただし、特徴量の所有権には継続的なガバナンスが必要だ。スキーマが進化し、サービスの責任範囲が変わり、新たに追加された特徴量に機密情報が含まれるようになる場合、チームはポリシーを維持しなければならない。

広範なワイルドカードポリシーは、その利点の多くを失わせる可能性がある。新しい条件キーは制御メカニズムを提供するが、AWSが各ワークロードに対する最小権限ルールを自動的に設計するわけではない。

部分書き込みは、AWSの最近のより広範な取り込み操作に関する取り組みも補完する。BatchWriteRecordは1回のリクエストで特徴量グループをまたいで最大25レコードを処理し、UpdateRecordは1つの既存レコード内の選択した値を変更する。

これらのAPIは異なるボトルネックを解決する。バッチ書き込みはレコード間のリクエストオーバーヘッドを減らし、特徴量レベルの書き込みはレコード内の不要な作業を減らす。

どちらの操作も、もう一方を置き換えるものではない。今回のリリースでは複数レコードに対する部分更新バッチではなく特徴量数の上限が文書化されているため、大規模な修正ジョブでは依然として多数のUpdateRecord呼び出しが必要になる可能性がある。

この違いは、大量のバックフィルを計画するチームにとって重要だ。より安全なフィールドレベル変更を得られる一方で、同時実行数の制限、再試行処理、進捗追跡、障害復旧は依然として必要となる。

EventTimeは条件付きで古い書き込みを防ぐ

UpdateRecordは意図しない上書きを減らすが、安全な順序付けは依然としてプロデューサーがEventTimeをどう使用するかに左右される。

各特徴量グループには、レコードまたはイベントが発生した時刻を表すイベント時刻の特徴量がある。UpdateRecordでは、変更するフィールドとともに、この特徴量のより新しい値を含めることができる。

送信された EventTime が保存済みの値以上である場合、SageMaker は更新を適用します。これより前の場合、サービスはリクエスト全体を ConflictException と HTTP 409 レスポンスで拒否します。

このチェックにより、遅延したイベントがより新しいレコード時刻に紐づく値を上書きすることを防げます。パイプラインには、順序どおりに届かない配信に対するマネージドな防御策が提供されます。

この仕組みは、単一の論理イベントストリームにおける連続した状態を複数のメッセージが表す場合に特に有用です。遅れて届いたメッセージによって、レコードが古いイベント時刻へ静かに巻き戻されることはありません。

ただし、EventTime はレコードレベルのメタデータです。特に異なるソースから無関係な特徴量を更新する場合、別々のプロデューサーが意味のある共通の時計を共有しているとは限りません。

AWS は、クライアントが EventTime を省略できるようにすることで、このケースに対応しています。その場合、サービスはレコードの既存イベント時刻を保持したまま特徴量の変更を適用します。

これを省略すれば、無関係なパイプライン間で人為的な競合が生じることを避けられます。たとえば夜間のセグメンテーション処理では、自身が管理するフィールドを一つ更新するだけのためにレコードの時計を進める必要はありません。

この柔軟性には重要なトレードオフがあります。EventTime を含まない更新では、レコードの時系列比較を用いて値がより新しいことを証明できません。

各チームは、プロデューサーが共有レコードの順序付けに参加するのか、独立して動作するのかを決める必要があります。この判断は API の利便性だけでなく、特徴量の意味に依存します。

日付付きトランザクションストリームから導出されたリスクスコアには、厳格な順序付けが必要になるかもしれません。一方、修正された言語設定では、別の特徴量として保存する個別のソースタイムスタンプが必要になる場合があります。

アプリケーションのリトライにも注意が必要です。409 レスポンスは一時的なサービス障害ではなく、古い EventTime を示します。同じリクエストを盲目的に再試行しても、そのタイムスタンプが新しくなることはありません。

クライアントは、競合をスロットリングや一時的なエラーとは別に分類すべきです。古い更新を破棄する、再計算する、または例外処理ワークフローに送ることができます。

Time-to-live の処理には別の条件も加わります。リクエストで TtlDuration を指定する場合、EventTime も含めなければなりません。そうでなければ、SageMaker は検証エラーを返します。

TTL の有効期限は、EventTime に指定期間を加算して計算されます。両方の値を必須にすることで、サービスが曖昧な有効期限を設定することを防ぎます。

これらのルールにより、UpdateRecord は制限のないパッチエンドポイントより安全になります。ただし、プロデューサー間で文書化された時系列モデルが必要であることは変わりません。

チームは、各特徴量が従う時計、更新が遅れて到着し得るか、どのサービスが競合を解決するかを定義すべきです。こうした判断がなければ、API は古いレコードを拒否できても、ビジネス上の真実を判断することはできません。

Standard_V2 が導入時の主要な課題となる

インメモリグループでは機能をすぐに利用できますが、Standard の顧客はストレージ形式の移行を考慮する必要があります。

AWS によれば、特徴量レベルの書き込みは両方のオンラインストア階層で機能しますが、有効化までの経路は異なります。既存の In-Memory feature group では、別のストレージ形式を選択せずにこの操作を利用できます。

Standard feature group には Standard_V2 が必要です。更新されたドキュメントでは、このストレージタイプでグループを作成するか、既存の Standard グループをインプレースで移行できると説明されています。

文書化された移行では、UpdateFeatureGroup を使用してオンラインストレージ設定を変更します。AWS は、この操作により feature group が保持され、データの再取り込みを回避できるとしています。

これは本番の feature store を再構築するより簡単に聞こえますが、元に戻せる切り替えではありません。AWS は、Standard から Standard_V2 への移行は一方向であると警告しています。

また、ドキュメントでは移行完了後、UpdateRecord が利用可能になるまで数分かかる場合があるとされています。そのためアプリケーションには、この機能移行を考慮したロールアウト計画が必要です。

本番チームは、SDK のバージョン、インフラストラクチャテンプレート、IAM ポリシー、監視、フォールバック動作をテストすべきです。ストレージ移行を、単なるソースコードの編集として扱うべきではありません。

混在環境では複雑さが増す可能性があります。新しい feature group は Standard_V2 を使用する一方、古いグループは Standard のまま残り、UpdateRecord が環境の一部でしか利用できない状態になり得ます。

クライアントライブラリは、すべての SageMaker feature group が部分更新を受け付けると想定すべきではありません。API リファレンスでは、この操作は Standard_V2 と InMemory のオンラインストレージに限定されています。

チームはオンラインとオフラインの動作も区別する必要があります。feature group にオフラインストアがある場合でも、UpdateRecord には常にオンラインストアのレコードが必要です。

関連するオフラインストアを持つ構成では、部分的な変更は完全なスナップショットとしてレプリケーションプロセスを通じて反映されると AWS は説明しています。この設計により、履歴トレーニングデータはマージ後のオンラインレコードと整合します。

In-Memory feature group には別の注意点があります。AWS のドキュメントによると、この階層は現在オンライン専用のグループをサポートしており、対応するオフラインストアへのレプリケーションは提供していません。

したがって、このリリースを、すべてのストレージタイプにおける普遍的なオンラインからオフラインへの同期と解釈すべきではありません。レプリケーションは、feature group の構成にオフラインストアが含まれる場合に適用されます。

オフライン履歴内の完全なスナップショットも、下流での解釈に影響します。各クライアントが選択した特徴量だけを送信した場合でも、複数の部分更新によって連続する完全レコード版が生成される可能性があります。

トレーニングデータの利用者は、引き続きイベント時刻、履歴行、ポイントインタイムの正確性を扱わなければなりません。UpdateRecord が変更するのは取り込み経路であり、オフライン履歴の分析上の意味ではありません。

公開された独立系の本番ベンチマークがないことも、依然として不確実性です。AWS はレイテンシの低下、データ転送量の削減、読み取り回数の減少を説明していますが、ワークロード固有の結果は定量化されていません。

Standard 階層の書き込み料金も、更新後のアイテムサイズに依存します。幅広いレコードに対する小さなリクエストでも、請求がその小さなリクエストだけを反映するとは限りません。

したがって実測が次の実務的なステップです。移行前に、リクエスト数、p95 書き込みレイテンシ、読み取りキャパシティの使用量、競合率、アプリケーションエラー率を比較すべきです。

また、部分更新がインシデント対応を簡素化するかも確認すべきです。調整コンポーネントが減れば運用負荷は軽くなりますが、新しい IAM ルールと競合処理ルールには独自の障害モードがあります。

開発者が次に注視すべき点

Amazon SageMaker UpdateRecord の価値は、導入データ、移行の信頼性、より複雑な書き込みパターンへの対応によって決まります。

最初の指標は、本番環境における Standard_V2 の移行動作です。チームは移行時間、デプロイ失敗、ロールバック計画、UpdateRecord が利用可能になるまでの遅延を確認すべきです。

安定した移行経路が実現すれば、既存の Standard 顧客も feature group を再構築せずに部分書き込みを導入できるという AWS の主張を強めるでしょう。API がより洗練されていても、運用上の想定外は導入を遅らせます。

2 つ目の指標は、測定されたワークロード改善です。有用な根拠には、GetRecord の量の減少、読み取りキャパシティ消費の削減、エンドツーエンド更新レイテンシの短縮、更新消失インシデントの減少が含まれます。

これらの測定は、比較可能なワークロードから得る必要があります。差異を UpdateRecord に帰属させる前に、テストではレコード幅、更新頻度、ネットワーク配置、並行性を維持しなければなりません。

競合率には専用のダッシュボードを設ける価値があります。HTTP 409 レスポンスが頻発する場合、イベントの遅延、時計の不整合、またはフィールドレベルの順序付けがより適切な場面でプロデューサーが EventTime を使用していることを示している可能性があります。

3 つ目の指標は、AWS が部分書き込みモデルを拡張するかどうかです。UpdateRecord は既存の 1 レコードと最大 100 の特徴量を扱いますが、BatchWriteRecord は複数レコードに対する完全な書き込みを対象としています。

大規模な修正を行う顧客は、バッチ処理の特徴量レベル操作を求めるかもしれません。その不在は現在の機能を弱めるものではありませんが、クライアント側オーケストレーションが必要な範囲を示しています。

開発者は SDK、Infrastructure as Code、オブザーバビリティのサポートにも注目すべきです。プロビジョニングツールが機能を一貫して公開し、監視が異なる障害クラスを可視化できると、サービス機能は運用しやすくなります。

現在このリリースを評価するチームにとって、最も安全なテストは対象を絞ったものです。頻繁に孤立した更新があり、複数の独立したプロデューサーを持つ feature group を選びます。

コードを変更する前にフィールドの所有権を文書化してください。その境界に合致する IAM 条件を追加し、各プロデューサーが EventTime を送信すべきかを定義します。

重要度の低い Standard_V2 グループを作成または移行するか、既存の In-Memory グループを使用します。同等の負荷条件で、従来の読み取り・変更・書き込み経路と新しい部分書き込み経路を測定します。

平均レイテンシだけでなく、p95 と p99 のレイテンシ、読み取りリクエスト、書き込み失敗、古いイベントによる競合、ペイロードサイズ、運用復旧に要する労力も比較してください。

ロールアウト中は制御されたフォールバックを維持してください。UpdateRecord では存在しないレコードを作成できないため、アプリケーションには初回取り込みを PutRecord 経由で行う明確な経路が引き続き必要です。

エンジニアリングチームは、アーキテクチャ上の判断、フィールドの所有権、イベント時刻ポリシーも検索可能な状態に保つべきです。継続的に管理された技術ナレッジベースは、後続サービスによるこれらの契約違反を防ぐことができます。

Amazon SageMaker UpdateRecord は、オンライン特徴量パイプラインにおける重複作業の実際的な原因を取り除きます。完全レコードの調整を、部分的なアトミック書き込みとより限定的な認可制御に置き換えます。

残る問いは概念的なものではなく、運用上のものです。Standard_V2 の移行は予測可能なままなのか。また、読み取り回数の減少が意味のある節約につながることを本番メトリクスは裏付けるのか。

頻繁な孤立変更が発生する幅広いレコードを運用するチームには、今や具体的に実施できる実験があります。両方の経路を比較し、競合を精査し、アプリケーション側のマージがなお存在意義を持つかを判断してください。