メインコンテンツへスキップ
ブログ一覧に戻る
Web制作・運用

冪等性とは?「もう一度送っていい処理か」を決めていないAPIの弱点

2026年9月18日
最終更新: 2026年10月8日
6分で読めます

この記事でわかること

冪等性を「同じ意図された効果を繰り返せる性質」とRFC 9110へ戻り、PUT・DELETE・安全なメソッド、POSTの自動再送、標準化されていないIdempotency-Keyを分けて読みます。2026年10月7日に確認した失効ドラフトの状態と、二重実行の損害からAPIを点検する順序を整理します。

2026年10月8日にRFC 9110の冪等メソッド節とIETFのIdempotency-Key Header draft-07ページを再確認した。RFC 9110は同一要求の複数回送信が意図したサーバー効果を一回の送信と同じにする性質を説明し、PUT・DELETE・安全なメソッドを冪等とする一方、非冪等要求を根拠なく自動再送しないよう述べる。draft-07はページ上でExpired・archived、意図されたRFC statusなしと表示されるため、ヘッダー名や既存API利用を否定せず、IETF標準として確定した契約とは扱わない。

30秒で要点

冪等性は「同じリクエストを何度送っても、サーバーへの意図された効果が一回分と同じ」という性質です。メソッド名、再送の規範、Idempotency-Keyの実装、二重実行の業務損害を別の判断にします。

  • RFC 9110では、PUT・DELETE・安全なメソッドが冪等と定義される
  • 冪等性は意図された効果に限られ、ログや監査履歴などの副作用を禁止しない
  • 非冪等な要求の自動再送は推奨されず、プロキシは自動再送してはならない
  • Idempotency-KeyのIETFドラフトは2026年10月7日確認時点でExpired・archivedで、保持期間や重複時の挙動はAPIごとに違う
APIの冪等性を意図された効果、再送、キー、損害の四つに分ける図解
メソッドの性質、クライアントの再送、キーの契約、二重実行の損害を分けて確認する。

1. RFC 9110の定義へ戻る

RFC 9110 §9.2.2は、同じメソッドの同一リクエストを複数回送ったとき、サーバーへの意図された効果が一回のときと同じなら冪等だと定義します。仕様上、PUT、DELETE、安全なメソッド(GETなど)がこの性質を持ちます。

ここでいう「同じ」は、全ての観測可能な出来事が一回分になるという意味ではありません。RFC 9110は、サーバーがリクエストごとにログを残したり、改訂履歴を保存したりすることを許容します。守る対象は、利用者が要求した状態変更の効果です。

2. 自動再送の規範と実装のずれ

通信が途中で切れると、クライアントは「サーバーが処理したか」を知れない場合があります。冪等な要求なら、同じ意図された効果を期待して再送できます。RFC 9110は、非冪等な要求を、実際の意味が冪等だと知る手段や未適用を確認する手段なしに自動再送すべきではない、とします。プロキシには非冪等要求の自動再送を禁止しています。

同じ条文は、応答の一部も受け取る前に接続が切れたとき、クライアントが危険を推測してPOSTを再送することがあるとも記載します。仕様が推奨することと、SDK・HTTPクライアント・ジョブ基盤が実際にすることは別です。

表が収まらない場合は、横にスクロールできます

確認対象問い残す記録
メソッド意図された効果は繰り返しても一回分かRFCとAPI契約
クライアント接続切断やタイムアウトで再送するかライブラリ設定・ログ
サーバー同じ要求を受けたとき何を変更するか状態差分・監査履歴
業務二重実行時に何が起きるか金額・在庫・通知の影響

3. Idempotency-Keyの現在地

IETF Datatrackerのドラフトを2026年10月7日に確認すると、draft-ietf-httpapi-idempotency-key-header-07はExpired・archivedで、ページの最終更新は2026年4月18日、最新revisionは2025年10月15日、意図されたRFC statusはありません。これは、ヘッダー名や実装が存在しないという意味ではなく、IETF標準として確定した仕様ではないという意味です。

API提供者が同じキーを受け取ったときの契約は、少なくとも次を分けて読みます。

  • キーを保持する期間と、期間を過ぎた再送の扱い。
  • 同じキーで同じ本文を送った場合のレスポンス再利用。
  • 同じキーで違う本文を送った場合の拒否・上書き・別処理。
  • 同時に届いた同じキーを一つにまとめるか、競合として返すか。
  • タイムアウト後に最初の処理結果を照会する方法。

ヘッダーを付けるだけで二重課金が消えるとは言いません。サーバーがどこでキーを保存し、いつ削除し、どのレスポンスを返すかが業務契約になります。

4. 二重実行の損害から優先順位を決める

実装方法より先に、同じ要求が二度適用されたときの影響を分類します。

  1. 決済、返金、在庫引当、権限付与など、二重実行の損害が大きい操作を特定する。
  2. 一意な業務ID、状態遷移、重複検知、再照会の経路を決める。
  3. API提供者のキー契約と、クライアントの再送条件を突き合わせる。
  4. 実際にタイムアウト・接続切断・同時送信を再現し、業務状態とレスポンスを確認する。

PUTに寄せれば解決する、キーを付ければ解決する、という一手の答えはありません。副作用の許容、復旧手順、利用者への説明を含めて判断します。

5. AIエージェントの呼び出しも同じ境界で見る

AIエージェントやジョブ基盤は、タイムアウトを失敗と見て自動再送することがあります。呼び出し先が注文、決済、通知、権限変更を行うなら、エージェントの自律性を上げる前に、再送時の意図された効果と重複照会を確認します。

テストでは、レスポンスだけでなく、注文数、請求数、在庫、通知、監査ログを別々に比較します。ログが二件でも決済が一件なら、冪等性の定義と監査の副作用を混同せずに説明できます。

6. 冪等性はラベルではなく契約

冪等性はメソッドのラベルではなく、同じ要求を繰り返したときの意図された効果に関する契約です。RFC 9110の自動再送の規範、クライアントの実装、失効したIdempotency-Keyドラフト、API提供者の個別仕様を分けます。二重実行の損害から優先順位を付け、状態とレスポンスを実測してから再送を自動化してください。

よくある質問(FAQ)