要約
- 期限が切れて保存版となったHTTPAPIのIdempotency-Key草案は、キーのライフサイクルと失効方針をリソース側の契約に置く。Stripeの現行文書とAWSの事例は、サービスごとに異なる保持境界を示しており、共通の有効期間を定めてはいない。
- 重複排除の記憶と、結果を生む権限は別々に管理すべきだ。認識期間を過ぎた古い操作の結果が不明なら、状態を照合するか保留する。キーが見つからないことは、最初の処理が行われなかった証拠ではない。
返事がないことと、仕事が行われていないことは同じではない。クライアントがタイムアウトを記録した時点で、サーバーはまだ要求を受け付けていないかもしれない。処理の途中かもしれない。完了後に応答だけが失われたのかもしれない。別のサービスへ処理が渡るなら、手前の失敗と奥の成功が併存することもある。
冪等性の仕組みは、この不確実性の中で同じ要求を再び渡せるようにする。クライアントが識別子を付け、サービスが契約の範囲で重複を認識する。以前の結果を返したり、実行中だと知らせたりすることで、不要な二度目の処理を避ける。
しかし、クライアントが識別子を持ち続けるだけでは足りない。サーバーが何を記憶し、何と何を同じ要求と見なし、いつまで記憶するかが重要だ。数日停止したワーカーが元の要求とキーを再送したとき、対応する記録はすでに削除されているかもしれない。同じデータが、認識の仕組みには初回として見える。
そこで新しい意思が生まれたとは限らない。変わったのは片側の記憶である。
draft-ietf-httpapi-idempotency-key-header-07は、この契約を考える材料になる。第07版は2025年10月15日に公開され、構造化されたヘッダーの文字列値、キーの一意性、任意の要求フィンガープリント、完了後と実行中の重複の扱いを提案する。キーのライフサイクルと適用される失効方針の公開はリソース側の責務として扱われる。
文書は2026年4月18日に期限を迎えた。調査時点のDatatrackerでは、HTTPAPIワーキンググループの期限切れInternet-Draftとして保存されている。活動中の草案でもRFCでも承認済み標準でもない。ワーキンググループの文書であることを、IETFの合意と取り違えてはならない。本稿はその提案と実際のサービス文書を比較するもので、普遍的なHTTPの義務へ格上げするものではない。
再試行の安全性はヘッダーだけにない
RFC 9110がいうメソッドの冪等性は、同じメソッドを繰り返したときの意図された効果に関する性質である。ログや応答が毎回同じであることではなく、複数システムを通じた実行が必ず一回になる保証でもない。POSTやPATCHにサービス独自の冪等契約を与えることはできるが、ランダムなキーを添えただけで任意の処理が端から端まで一度だけになるわけではない。
草案も、一般的なクライアントは事前の知識なしにサーバーがキーを尊重すると仮定できないとする。識別の範囲、要求の比較、保持期間、進行中の応答を知らなければ、「安全な再試行」の意味を判断できない。
完了した要求の重複なら、提案上は以前の結果を返す。結果がエラーであっても同様だ。完了前なら競合を示す。同じキーを異なるペイロードに使えば別の問題になる。どれも「キーを新しくしてもう一度」という一つの操作へまとめてよい状態ではない。
ペイロードのフィンガープリントも、単なるハッシュ計算ではない。全体を見るか一部を見るかで、どの差が新しい意味を持つかが決まる。業務上重要になった新しいフィールドを比較から外せば異なる意思を混同する。無害な形式変更で別物扱いすれば、同じ指示を複数に分ける。十分なエントロピーは衝突を減らすが、意味の誤りを修正しない。
記憶の期間は保障の一部である
あらゆるキーと応答を永久に保持するのは、費用やプライバシーの面で適切とは限らない。リソースの寿命、識別子の範囲、遅延の可能性も考える必要がある。重要なのは削除を禁止することではなく、削除後の再送がどの契約に入るかを明示することだ。
Stripeの現行公式文書は、エンドポイントの実行開始後に最初のステータスとボディーを保存し、エラーも含めると説明する。実行前のパラメーター検証失敗や競合では、その結果を保存しない。キーが少なくとも24時間経過した後には削除でき、削除されたキーを再利用すると新しい要求を生成する。
これはすべてのキーが正確に24時間で失効するという保証ではない。他のサービスの一般ルールでも、重複請求が起きたという報告でもない。あくまで特定の契約である。数日後に復旧して古い仕事を送り直すクライアントは、その回復期間を保持境界と比較しなければならない。
AWSのBuilders Libraryは別の例を示す。最初に作ったリソースを別の主体が削除した後、遅い再試行が届くことがある。EC2の事例ではリソースを再作成せず、意味的に同等な応答を維持する。文書はリソースの生存期間に遅い到着のための間隔を加えた保持を説明し、要件はサービスとリソースによって異なるとする。
この二つから共通のTTLを作ってはいけない。数秒のSDK再試行、長く切断された機器、バックアップの復元、手動のサポートは、異なる時間軸で古い要求を戻す。保持より長い回復期間は、照合の問題である。バックオフを増やしても、消えた記録は戻らない。
キーと操作と結果と新たな意思を分ける
第一の識別は、契約内で再送を認識する重複排除キーである。第二は、許可された業務上の操作そのもの。第三は、実際に作成または変更された結果やリソース。第四は、追加の結果を求める新しい意思である。互いを結びつける必要はあるが、同一視してはならない。
新しいキーは新しい意思の証明ではない。削除後の古いキーは以前の失敗の証明ではない。リソースの削除は、それが最初から存在しなかったことを意味しない。一方、同じパラメーターで二度目の操作を正当に望む場合もある。バイトの一致だけでは、どちらの意思か判断できない。
通常の重複認識期間より長く使える、簡潔な操作記録が役立つ。要求者の範囲、許可された指示、パラメーターへのコミットメント、受け付け時刻、終端状態、結果への参照、照合経路を保持できる。すべての機密データや応答を永久保存する必要はない。用途とアクセスと期間は正当化されなければならない。
これは草案にある新しい必須ヘッダーの提案ではない。サービスは異なる実装で同じ管理上の目的を満たせる。守るべき条件は限定的だ。重複排除の記憶を消したとき、古い不明な指示が再び動いてよいかを判断する唯一の証拠まで失わせないことである。
期限後の扱いを先に決める
失効方針には、いつから数えるか、どの要求者と操作に適用するか、完了したエラーや実行中の仕事をどう扱うかを含めるべきだ。さらに、遅れて届く要求が、拒否、状態照会、照合、確認可能な保留のどこへ進むのかを説明する。
期限を超えた曖昧な再送を、新しい実行として自動処理するべきではない。クライアントは自動送信を止め、既知の操作やリソースを照会し、必要なら判断を上げる。新しい結果が本当に必要なら、古い回復要求とは区別できる新しい意思を明示する。
削除後の再利用を新規要求として処理すると公開するサービスもあり得る。その場合でも、クライアントの流れが昔の保障を延長して語ってよいわけではない。送信可能という技術的条件と、もう一度動く権限は分かれる。
人の再試行にも同じ境界がある。障害から三日後のサポート操作は、数秒後のSDK再送と異なる契約に入るかもしれない。競合を避けるためにキーを変えると、未確定の結果を解決せず二番目の操作を始めることになる。ボタンや手順は、その判断を見えるようにする必要がある。
記録と結果が食い違う場所を試す
キーだけ記録してリソースを作らなければ、虚偽の完了になり得る。リソースだけ作ってキーを記録しなければ、再実行が可能になる。AWSの説明は、キーの記録と関連する変更を一体の原子的な処理として協調させる重要性を示す。
ただし一つのローカルトランザクションが、別システムの全結果を覆うとは限らない。手前が行を確定し、奥が指示を実行し、応答だけが失われることもある。操作の終端状態は、各結果について権威を持つシステムへ結びつけなければならない。最初のデータベースで完了しても、連鎖全体の完了証明にはならない。
保持期間の後に届く要求、リソース削除後の再送、異なるペイロード、要求者の範囲変更、下流だけの部分的完了を試験する。合格条件は整ったステータスだけではない。許可されない二つ目の結果が発生せず、不明なものを不明と説明できることである。
古いバックアップ、遅く再接続する機器、サポートのエクスポートは、すでに照合済みの仕事を再び動かせる。これらは特殊な攻撃ではなく、回復の通常経路だ。平常時に再試行が短いという理由だけで、長い回復を設計から外してはならない。
出典
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加