- 公開日
AIエージェントの外部操作がタイムアウトしたときは、同じ処理を再実行する前に、元の要求と操作先の状態を照合します。要求IDが付いていても、操作先が重複を抑止するとは限りません。完了済みなら既存結果を使い、処理中なら照会を続け、結果不明で重複を防げない場合は再試行を保留します。
この表は、予約更新のように外部の状態を変える操作について、再試行を許可できるかを点検するためのものです。タイムアウトだけでなく、同時に動く担当、再起動、遅れて届いた結果も対象にします。判定は、確認した操作と構成に限って使います。結果不明時の照会と再試行の流れそのものの設計は、タイムアウトした外部操作を照会し、二重実行を避けて再試行するで扱っています。
点検対象と、証拠から付ける判定
最初に、対象サービスとAPIの版、利用アカウント、操作の種類、対象データ、承認された内容、確認日を固定します。APIは外部システムの機能を呼び出す窓口です。同じサービスでも操作によって重複防止の契約が異なるため、予約の新規作成と既存予約の更新を一括して合格にしません。
各行の判定は「はい／いいえ／未確認／対象外」です。「はい」は必要な照合を終えて命題に合う場合、「いいえ」は照合して合わない事実がある場合です。資料がない、版が違う、観測できない場合は「未確認」にします。「対象外」は、その副作用や実行経路を今回の構成に含めないと確認できた場合だけに使います。
仕様書に「重複しない」と書かれていることと、実際の同時要求が重複しないことは別々に判定します。前者に「はい」を付けても、後者の確認記録がなければ「未確認」です。動作の点検には、入力と版が特定できる評価記録、実際に送った要求、操作先の履歴を使います。AIの「完了しました」という発言だけを実行証拠にはしません。
以下の仕様、識別子、画面、履歴、判定はすべて架空の記入例です。実際の予約更新や障害試験は行っていません。現場では、許可された環境で得た対象版の証拠へ置き換えて判定します。
一件の予約変更を追う
利用者が、予約BK-42を2026年11月18日の10時〜11時から11時〜12時へ変更することを承認したとします。時刻は日本時間です。会議室、利用者、料金は固定し、変更前の予約版は4です。この架空サービスでは更新に伴う課金やメール通知は発生しないとします。
一件の承認済み変更を追跡する業務要求IDをR-42、重複判定に渡す冪等性キーをK-42、一回目の通信試行IDをT-1と置きます。冪等性とは、契約で定めた同じ要求を繰り返しても、追加の副作用を生じさせない性質です。副作用は、この例では予約内容の書き換えを指します。
T-1の応答が返らず待機が終了しました。この要求について手元で見られる実行記録は送信とタイムアウトだけで、外部の変更結果はまだ不明です。表では、この時点の証拠と、追加で確認する資料を分けます。後半では同じ予約と変更内容を保ち、照会結果、同時要求、再起動という条件を変えます。
要求IDと冪等性の契約を点検する
AWSのMaking retries safe with idempotent APIsは、応答不着でも変更が済んでいる場合と、呼出主体・要求内容・識別子を使ったサービス側の重複抑止を説明しています。ここから重要になるのは、IDの存在と、そのIDを使う契約の区別です。
| 確認する命題 | 確認資料・方法 | 架空例の判定 | いいえ・未確認時の対応 |
|---|---|---|---|
| A1：送った更新を、利用者・対象・承認内容・要求IDへ対応付けられる | R-42の承認記録とT-1の送信記録を照合 | はい：BK-42、変更前版4、11時〜12時が一致 | 対応が欠けたら履歴を回収。照合まで再送せず、対象違いなら是正する |
| A2：対象APIの仕様に、同一キーを重複抑止に使う条件が書かれている | 版付き仕様でアカウント・更新操作・キー・内容の範囲を確認 | はい：架空仕様では同じアカウント・更新・内容が条件 | 記載がなければ提供者へ確認。追跡用IDしかなければ重複抑止済みと扱わない |
| A3：同じ変更の再試行でR-42とK-42が維持される | 再試行の設定と出力する要求を、初回記録へ対照 | 未確認：再試行側の要求記録がない | キーの自動再発行を止め、同じ業務変更へ対応する条件を確認 |
| A4：同じキーで内容が変わった要求は、元の変更として適用されない | K-42のまま変更先を12時〜13時へ変えた架空の拒否記録を照合 | はい：例の記録では内容不一致として拒否 | 内容照合を是正。拒否や下流状態が確認できなければ、変更要求を保留 |
| A5：キーの保持期間と起点が分かり、今回の再試行が期間内である | 仕様の保持条件と操作先の受付時刻を照合 | 未確認：期間の記載はあるが初回受付時刻を確定できない | 有効性を確認するまで同じキーだから安全と判断しない。期限切れは照会へ回す |
通信試行IDは、送信のたびに異なって構いません。T-1とT-2の両方が同じR-42、K-42、変更内容に対応することを確かめます。同じ予約でも別の日程への変更は、新しい意図として扱います。元の要求が未解決のまま、新しいキーへ替えて処理を通す方法は採りません。
A2の仕様には、識別子の記録と予約更新を切り離さず扱う範囲も必要です。重複の確認だけを先に行い、実際の更新が別々に進めば、同時要求が両方通る余地が残ります。「原子的」という説明がある場合も、どの記録と変更が一体として扱われるのかを読みます。これはすべてのAPIに備わる機能ではありません。
タイムアウト後の照会と、完了状態を点検する
照会では、どのアカウントから、どの要求と対象を、いつ確認したかを残します。要求履歴と現在の予約画面は、答える問いが異なります。要求履歴はR-42がどう処理されたか、現在の画面は今どの予約内容かを示します。一方だけでは、別の人による変更や表示の遅れを区別できないことがあります。
| 確認する命題 | 確認資料・方法 | 架空例の判定 | いいえ・未確認時の対応 |
|---|---|---|---|
| B1：タイムアウトを、操作先での失敗確定と区別して記録する | T-1の通信記録と業務状態の表示を比較 | はい：例では「応答未受信・結果不明」と記録 | 失敗確定の表示を訂正し、外部状態を照会するまで自動再送を止める |
| B2：要求IDに対応した操作先の状態を照会できる | 対象アカウントでR-42とBK-42に対応する照会記録を確認 | 未確認：仕様に照会機能はあるが実際の結果を未入手 | 認可された照会経路か運用担当へ確認。機能の説明だけで結果を補わない |
| B3：完了という判定が、承認した変更と操作先の完了記録に対応する | R-42の終端状態、変更後版、日時を承認記録へ照合 | 未確認：完了記録がまだない | 成功を報告せず確認を続ける。内容不一致なら再送せず差異を調べる |
| B4：「記録なし」だけでは、未実行と判定しない | 照会範囲・反映遅延・古い要求の遅着条件と再送判断を比較 | いいえ：架空の判断案が「記録なし→新キーで再送」になっている | 判断案を修正し、重複抑止の有効性か未実行の確証を確認するまで保留 |
| B5：処理中の要求に新しい更新を重ねず、確認期限後も不明を保持する | 処理中・照会不能時の遷移記録と待機終了時の表示を確認 | 未確認：期限到達時の記録がない | 更新を保留し、確認担当と次の照会手段を指定。期限だけで失敗へ変えない |
この例でB2の資料を入手し、R-42の完了と、BK-42が版5・11時〜12時になったことを確認できたなら、B3を「はい」に更新して再送を終了します。記録上の結果と承認内容が一致することが条件です。R-42が処理中なら、完了と表示せず、同じ更新の新規発行を避けて照会へ進みます。
BK-42の画面が希望どおりでも、R-42との対応が取れなければ、「現在の予約内容は希望どおり、要求の実行結果は未確認」と分けます。逆にR-42が成功した後、他の人が版6へ変更した場合は、過去の成功と現在の内容が両立します。古い承認のまま版6を上書きして、帳尻を合わせません。
「失敗」と返った場合も、副作用が残っていないかを確認します。予約更新後の付随処理が失敗したサービスでは、全体を最初から繰り返すと更新済み部分を重ねるおそれがあります。失敗が終端状態か、部分適用があるか、同じキーへの再試行をどう扱うかを、対象APIの条件で判定します。
同時実行と再起動で、別要求に化けないか
一つの画面の再試行ボタンを止めても、別の担当や下位の通信処理が再送すれば、操作は増えます。次表は、同じ予約更新について複数の実行経路が存在する場合の点検です。確認するのは、同じ承認から別要求が生まれないことと、再開後も元の要求を追えることです。
| 確認する命題 | 確認資料・方法 | 架空例の判定 | いいえ・未確認時の対応 |
|---|---|---|---|
| C1：同じK-42の同時要求で、予約の変更が二回確定しない | 同時到着時の重複判定と操作先の更新履歴を対照 | 未確認：単独送信の記録しかない | サービス側の契約と同時実行の証拠を確認。仕様の記載だけで合格にしない |
| C2：複数の担当が、同じ承認を別キーの新規要求として実行しない | 同じ承認から作られた業務要求・担当・キーを照合 | いいえ：例では二担当がK-42とK-43を別々に割り当てる | 実行担当を一つに定め、同じ意図の重複開始を抑止。両要求の状態を照会 |
| C3：再起動後も、元の要求と未完了状態を復元できる | 送信前に保存した対応表と再開時の記録を比較 | 未確認：保存記録はあるが復元側の照合がない | 新しい要求を生成せず、R-42の履歴を復旧して照会から再開 |
| C4：アプリと通信部品の再試行を、全体として把握できる | 各層の設定、T-1以後の送信履歴、総回数を照合 | 未確認：通信部品の自動再送設定が不明 | 担当する層と上限を決め、隠れた再送を是正。設定不明のまま手動再送を足さない |
| C5：同じ要求の重複結果で、完了処理や再更新を重ねない | 元要求との対応、重複応答、現在の予約版を突き合わせる記録 | 未確認：遅着時の記録がない | 同じ要求の結果として突合し、通知や後続操作を新規に起動する前に確認 |
C1とC2は違う失敗を扱います。サービスが同じキーを抑止できても、二つの担当が別のキーを発行すれば、同一の変更だと認識されない場合があります。一方、クライアント側で担当を一人にしても、サービス側の同時受付や通信再送の問題まで解決したことにはなりません。
再起動時には、手元に完了記録がないことを未実行の証拠にしません。外部では更新済みで、結果を保存する直前にプロセスが落ちた可能性があるためです。反対に、送信前に「完了」と記録してしまうと、実際には未実行の操作を落とすおそれがあります。R-42の発行内容と状態を保存し、再開後は操作先の証拠と照合することを確認します。
複数層の再試行が要求数を増やす問題は、AWSのTimeouts, retries, and backoff with jitterでも扱われています。待ち時間を長くすることは負荷対策にはなっても、同じ変更が一度しか適用されない証明にはなりません。更新の再試行と、読み取り専用の状態照会を分けて管理します。
再試行の許可と、人への引継ぎを点検する
ここまでの不足が残る場合は、再試行を通すためにIDを付け替えず、確認へ回します。取消を送った場合にも照会は必要です。例えば、外部ツールとの接続に使われるMCP（Model Context Protocol）のCancellation仕様には取消の遅着や取消不能の扱いがあり、待機の終了や取消要求の送信から、外部更新が起きていないとは結論できません。
| 確認する命題 | 確認資料・方法 | 架空例の判定 | いいえ・未確認時の対応 |
|---|---|---|---|
| D1：再試行前に、権限・承認・対象版・要求内容を再照合する | 初回承認、現在の予約版、実行権限、再送内容を比較 | 未確認：現在版を照会できていない | 旧承認で変更できる範囲を確認し、対象が変わっていれば再判断 |
| D2：失敗した要求の再試行前に、更新済み部分の有無を確かめられる | 失敗の終端状態、部分適用の記録、再試行手順を照合 | 未確認：例には失敗時の部分適用を示す記録がない | 実行済み部分を確認するまで、失敗という表示だけで全体を再実行しない |
| D3：更新時の決済を重複させない仕組みを確認できる | この操作で発生する課金と接続処理の有無を確認 | 対象外：例は課金を発生させない構成 | 実構成が不明なら未確認。課金を追加する変更時に点検し直す |
| D4：人が確認を引き継いだ間、Agentが更新を再送しない | 引継ぎ記録と待機要求、再開後の送信可否を照合 | 未確認：人に渡す画面はあるが送信側の記録がない | 自動更新を保留し、照会担当と再開の権限を一つに定める |
| D5：再試行を許可した後も、受付と完了を区別して追跡する | T-2の受付記録とR-42の終端状態・予約内容を照合 | 未確認：今回は再試行条件が未成立 | 条件成立までT-2を出さず、実行後は受付だけで成功にしない |
この架空例の現在の結論は「自動再試行を保留」です。特にA5のキー有効性、B2の照会、C1の同時実行、C2の別キー発行が未解決です。はいの数を合算して導入可否を決めず、同じ操作を重ねるおそれがある経路ごとに、再試行を許せる証拠を確認します。
NG・未確認を、再開条件のある保留にする
点検記録には、行番号、命題、現在の証拠、不足、是正担当、確認期限、再開条件を残します。例えばC2なら、「K-42とK-43の状態を照会し、同じ承認から別要求を作る経路を是正する。外部に残る変更を確認するまで再送を保留」とします。すでに二要求が発行された可能性があるなら、片方のローカル記録を消して解決したことにはできません。
再試行を許せるのは、同じ内容を契約の範囲内で重複なく扱えると確認できた場合、または未実行と古い要求の残存がないことを確認し、新たな実行条件を満たした場合などです。どちらも、現在の権限・承認・対象状態と、サービスの再試行手順への適合が必要です。期限切れのキーや、意味の分からない失敗コードを推測で補いません。
照会でも結論が出ないときは、R-42、BK-42、承認内容、送信時刻、各試行、最後の照会結果、未確認の範囲を担当者へ引き継ぎます。案内は「予約変更の応答を受信できず、実行結果は未確認です。自動再送は保留しています」とします。確認期限が過ぎても状態は不明のまま保持し、誰が次の確認を行うかを決めます。
このチェックリストは、照会APIや副作用管理基盤そのものの実装設計を代替しません。また、一つの予約更新の冪等性から、通知・課金・別サービスまでを含む処理全体が一度だけ実行されるとはいえません。接続先、保持条件、再試行ライブラリ、並列数、再開方式を変えた場合は、影響する行を再点検します。必要な証拠を揃えられない操作を、曖昧なまま自動化の対象へ戻さないことが、実務上の判断になります。
