冪等性

冪等性とは

冪等性(べきとうせい・idempotency)は、同じ操作を1回行っても複数回行っても、結果が同じになる性質のことです。

ネットワークは必ず失敗します。「リクエストを送ったが応答が返ってこない」とき、処理が実行されたのか分からないままリトライ(再送)するしかありません。このとき操作が冪等なら、たとえ実は1回目が成功していても、2回目で二重処理にならず安全です。

冪等な操作   : 「ステータスを発送済みにする」→ 何度やっても発送済み
冪等でない操作: 「残高から1000円引く」→ 2回実行すると2000円引かれる!

HTTPメソッドと冪等性

[[HTTP]] のメソッドは、仕様上の冪等性が定義されています。

メソッド	冪等?	理由
GET	○	取得するだけで状態を変えない
PUT	○	「この内容に置き換える」ため何度やっても同じ状態になる
DELETE	○	削除済みのものを再度削除しても結果は同じ
POST	×	「新規作成」は実行のたびに増える

[[REST API]] の設計でメソッドを選ぶとき、この性質が判断材料になります。問題は冪等でない POST — 決済や注文の作成でリトライすると二重決済・二重注文が起きてしまいます。

冪等キーによる対策

POST を安全にリトライできるようにする定番の仕組みが冪等キー(Idempotency Key)です。

クライアントがリクエストごとに一意なキーを生成し、ヘッダーに付けて送る
サーバーはキーと処理結果を保存しておく
同じキーのリクエストが再度来たら、処理を実行せず保存済みの結果を返す

決済サービスの Stripe が採用したことで広く知られるようになったパターンで、リトライしても課金は1回しか発生しません。

初学者向けポイント

[[Webhook]] の受信処理は再送が前提です — イベントIDで処理済みかを確認してから処理する、が基本形です
[[メッセージキュー]] の多くは「少なくとも1回配信」(同じメッセージが2回届き得る)なので、受信側の冪等性が必須です
「この処理、2回動いたらどうなる?」と自問する癖をつけましょう。分散システム設計の基本の問いです

関連技術とのつながり

[[REST API]] — メソッド選択と冪等キー設計の実践の場
[[HTTP]] — GET / PUT / DELETE は冪等、POST は非冪等という仕様上の性質
[[Webhook]] — 再送される通知を安全に処理するために冪等性が必要
[[メッセージキュー]] — 重複配信があり得るため受信側の冪等化が前提
[[エラーハンドリングとリトライ設計]] — 冪等性を前提に安全な再試行を組む方法
[[分散トランザクションとSaga]] — 冪等性が実際に効く代表的な分散設計

Q: 冪等性の説明として正しいのはどれ?
- [x] 同じ操作を何度実行しても結果が変わらない性質
- [ ] 処理が必ず1秒以内に完了する性質
- [ ] データが暗号化されて保存される性質
解説: 冪等性は実行回数によらず結果が同じになる性質で、安全なリトライの土台になります。

Q: HTTPメソッドのうち仕様上冪等でないのはどれ?
- [ ] PUT
- [ ] DELETE
- [x] POST
解説: POST は新規作成のため実行のたびに結果が増えます。GET・PUT・DELETE は仕様上冪等です。

Q: 冪等キーを受け取ったサーバーが、同じキーの再送に対して行うことはどれ?
- [ ] 毎回新しく処理を実行して最新の結果を返す
- [x] 処理を実行せず、保存しておいた1回目の結果を返す
- [ ] エラーとして接続を強制切断する
解説: 同じキーなら保存済みの結果を返すことで、リトライしても処理は1回しか実行されません。