前回からの接続と、この講義の役割
前回のK-09では、重い処理をリクエストから切り離すジョブキューを学び、失敗したジョブは再実行できると触れました。では、その再実行は本当に安全なのでしょうか。通信は必ずいつか失敗します。この講義では、失敗したときにもう一度実行する仕組みと、それを安全に行うための考え方を、カテゴリKの締めくくりとして扱います。
このスライドのポイント
- K-09: 重い処理をジョブキューへ切り離し、失敗したジョブは再実行できると触れた
- では、その再実行は本当に安全か
- 通信は必ずいつか失敗する。失敗への備えがカテゴリKの締めくくり
3つの用語の定義と核心
用語を3つ定義します。タイムアウトとは、応答をいつまで待つかの上限で、無限に待たないための仕組みです。再試行とは、失敗やタイムアウトのときにもう一度実行することで、D-06で触れた再試行を設計として扱うものです。冪等性とは、同じ操作を何度実行しても結果が1回分と同じである性質です。ここで核心をお伝えします。再試行を安全にするには、その操作が冪等でなければなりません。送信は届いたのに応答だけが失われた場合、再試行するとサーバー側では二重に実行されてしまうからです。
このスライドのポイント
- タイムアウト: 応答をいつまで待つかの上限（無限に待たない）
- 再試行: 失敗・タイムアウト時にもう一度実行すること（D-06の再試行の設計版）
- 冪等性: 同じ操作を何度実行しても結果が1回分と同じである性質
- 核心: 再試行を安全にするには、操作が冪等でなければならない
なぜ必要か
これを知らないと、決済の再試行で二重課金、申請の再送で二重登録という、最悪級の事故を設計の段階で防げません。通信が不安定なとき、利用者やプログラムは善意でもう一度送信します。そのとき操作が冪等でなければ、送るたびに被害が増えていきます。これはA-09で学んだ高リスクな変更の、通信版だと考えてください。お金やデータに関わり、元に戻すのが難しい領域です。
このスライドのポイント
- 知らないと: 決済の再試行で二重課金、申請の再送で二重登録という最悪級の事故を防げない
- 通信が不安定なとき、人もプログラムも善意でもう一度送信する
- 冪等でなければ、送るたびに被害が増える
- A-09の高リスクな変更の通信版（お金・データに関わり、戻しにくい）
事故の系譜と防止のしくみ
事故がどう起きるかを順に見ます。まず送信し、サーバー側では処理が成功します。ところが応答だけが途中で失われ、送った側には失敗したように見えます。そこで再試行すると、同じ操作がもう一度実行され、二重処理になります。これを防ぐのが冪等キーです。同じ操作には同じIDを付け、サーバーは同じIDの2回目以降を無視して、初回の結果を返します。
このスライドのポイント
- 事故の流れ: 送信 → 処理は成功 → 応答だけ喪失 → 失敗に見える → 再試行 → 二重処理
- 防止: 冪等キー（同じ操作には同じIDを付ける）
- サーバーは同じIDの2回目以降を無視し、初回の結果を返す
具体例: 経費申請の送信
経費申請の送信で考えます。冪等キーを付けておけば、通信が不安定で3回再送されても、登録されるのは1件だけです。2回目と3回目のリクエストは同じキーを持つため、サーバーが初回の結果を返すだけで、新しい登録は起きません。D-05で、GETは何度繰り返しても安全だと学びました。あの安全な性質を、登録や更新のような変更を伴う操作にも人工的に与えるのが、冪等キーの役割です。
このスライドのポイント
- 冪等キー付きなら、通信が不安定で3回再送されても登録は1件
- 2回目・3回目は同じキーを持つため、サーバーは初回の結果を返すだけ
- D-05で学んだ「GETは繰り返しても安全」を、変更系の操作に人工的に与えるのが冪等キー
技術サンプルカード
サンプルは、冪等キーを付けたPOSTリクエストの擬似例です。種別はhttp、目的は、同じ操作を安全に再試行できる形を確かめることです。ヘッダーにIdempotency-Keyという行があり、値のidemp-key-0001はダミー値です。読み方は2点です。1つ目、このキーが「同じ操作」であることの証明になります。2つ目、同じキーで再送しても、サーバーは初回の結果を返すだけで、二重処理は起きません。つまり再試行は、冪等キーとセットにして初めて安全になります。AIへの質問例は、「この操作は再試行されても二重処理になりませんか。冪等性はどう担保していますか」です。
混同しやすい概念
混同しやすい2つを対比します。一方は、再試行すれば直る失敗で、一時的な障害が典型です。もう一方は、再試行すると壊れる失敗で、冪等でない変更操作がこれにあたります。D-06では、失敗の種類によって再試行してよいかを判断しました。そこに今回、操作そのものの性質という軸が加わります。同じ失敗でも、操作が冪等かどうかで、再試行してよいかが変わるのです。
バイブコーディングでの確認点
バイブコーディングでの確認点です。外部連携、決済、申請のような変更を伴う操作すべてに、「二重実行されたら何が起きますか」と問いかけてください。加えて、タイムアウトが設定されていないコードにも注意します。応答を無限に待つ作りは、処理が止まったことに気づけません。AIが生成した連携には、タイムアウトの上限と、再試行時の冪等性の担保が入っているかを確認しましょう。
このスライドのポイント
- 外部連携・決済・申請など変更を伴う操作すべてに「二重実行されたら何が起きますか」を問う
- タイムアウト未設定（無限待ち）のコードは要修正
- 生成された連携に、タイムアウトの上限と再試行時の冪等性の担保が入っているか確認
一問一答とまとめ
最後に一問一答です。同じ操作を何度実行しても、結果が1回分と同じになる性質を何と呼ぶでしょうか。（間）答えは、冪等性です。30秒でまとめます。タイムアウトで待つ上限を決め、失敗したら再試行し、その再試行を冪等性で安全にする。この3点セットが、失敗に強い連携の土台です。これでカテゴリKは修了です。つなぐ、待つ、失敗に備える、の一式が揃いました。次回からはカテゴリL、データの保存の本丸であるデータベースへ進みます。関連資料は「API連携 超入門」「Webhook入門」「テスト観点プロンプト50」です。
このスライドのポイント
- 一問一答: 同じ操作を何度実行しても結果が1回分と同じ性質は？ → 冪等性
- 30秒まとめ: 待つ上限を決め（タイムアウト）、失敗したら再試行し、それを冪等性で安全にする
- カテゴリK修了。つなぐ・待つ・失敗に備える一式が揃った
- 次回: カテゴリL、データの保存の本丸データベースへ
- 関連資料: 「API連携 超入門」「Webhook入門」「テスト観点プロンプト50」
