- 公開日
ツール連鎖を途中から再開するには、途中成果と実行状態を保存し、再開時に現在の依頼、権限、資料、対象システムの状態を照合します。保存ファイルがあるだけでは、外部更新の完了も、以前の承認が今も有効であることも分かりません。完了を確認できた操作は飛ばし、未実行の操作だけを現在の条件で進めます。結果不明の操作が残る場合は、再送より先に照会します。
チェックポイントを置く場所と、保存が証明する範囲
チェックポイントとは、中断後にどこから続けるか判断できるよう、途中成果と処理状態を関連付けた保存点です。資料取得、候補作成、承認、外部更新、更新結果の確認という連鎖なら、資料を使って判断する前と、外部を変更する前後が主な候補になります。
「次の処理で別の権限を使う」「対象を変更する」「変更を取り消しにくい」という場所では、進む前に確認する条件も変わります。そこへ保存点を置けば、何を確かめて再開するかを決めやすくなります。一方、変換のたびに資料全体を複製すると管理の負担が増えるため、元の版を保持した成果物への参照と差分で済む部分を選びます。
外部更新の前に保存が成功しても、それは「実行予定が残った」という証拠です。その後に更新要求を送ったかは別に記録します。また、更新が完了してからローカルの記録を保存するまでに中断すれば、保存点は古いままです。この隙間を無視して、最後に保存した行の次から無条件に実行すると、完了済みの操作を繰り返すおそれがあります。
AWSのMaking retries safe with idempotent APIsは、応答が届かなくても副作用が起きている可能性と、同じ意図の要求を再試行するためのサービス側契約を説明しています。ここでいう副作用は、申請状態の変更など外部に残る変化です。チェックポイントの保存と外部更新を一体で確定できない構成では、この不確実な区間を前提に再開方法を設計します。
成果物、許可、要求を同じ作業へ結び付ける
一つの「完了」欄ですべてを表すと、資料取得の完了と申請更新の完了が混ざります。次のように、作業全体の識別情報と各工程の状態を分けて持つ方法があります。これは実装の設計例であり、共通規格の必須項目ではありません。
| 保存する内容 | 再開時に照合すること |
|---|---|
| 作業ID、依頼の版、対象ID、次の工程 | 同じ目的・対象か。依頼変更や取消しはないか |
| 取得資料の識別子、版、取得時刻、必要な根拠箇所 | 参照可能か。更新や有効期間によって判断が変わらないか |
| 途中成果の版、作成に使った資料、未確認事項 | どの前提で作った成果か。何が未解決か |
| 実行主体、許可範囲、承認対象、期限 | 今の主体が同じ操作を許可されているか |
| 工程別の実行状態、要求ID、送信した内容 | 完了済み、未実行、処理中、失敗、不明のどれか |
| 対象システムの受付・完了記録、確認時刻 | 記録が指す要求と対象が一致するか |
| 再開担当、停止理由、次の確認先 | 別の担当が同時に再開していないか |
復旧メモにはパスワードやアクセストークンをコピーせず、認証情報を管理する仕組みと分けて保管します。記録には主体と認可記録の参照を残し、実行時の接続手段で有効性を確認します。資料や成果物にも閲覧・保持の条件があるため、保存先のアクセス範囲と保存期間を業務に合わせます。
チェックポイントの版やハッシュは、保存した内容の取り違えを見つける補助になります。ただし、記録の作成元や保管先が信頼できることは別に確認が必要です。内容が一致していても、古い許可を現在の許可へ変えたり、外部システムの完了証明にしたりはできません。
架空の申請処理を中断した場合
ここからは架空の社内申請A-17を使います。実際のシステム操作や復旧試験は行っていません。依頼は「添付資料を照合し、承認された場合に限り、申請を受付済みへ更新する」です。外部への通知は含めません。
申請は版4、資料はD-8の版2です。更新主体は担当アカウントU、承認記録PはA-17の版4に対する受付更新だけを対象とし、当日の17時まで有効という仮定にします。再開担当は一人に定めます。資料取得後の保存点Cには、照合結果と不足の有無、申請版4、承認Pへの参照、更新は未実行と記録されています。
外部更新前には、業務要求R、再試行用のキーK、送信する内容を記録する設計とします。Kは同じ要求を繰り返しても同じ更新を重ねないための冪等性キーです。対象サービスが定める主体・内容・保持期間などの条件内で使えるという仮定であり、文字列を付けるだけでは重複を防げません。
保存点が同じでも、再開時の判断は変わる
最初に、依頼の最新版と未処理の変更・停止指示を確認します。確認依頼への返答が必要なままなら、時間が経っても承認が得られたことにはなりません。以下では依頼変更がない条件を固定し、同じ対象、更新内容、保存点Cについて、再開時に見つかる条件を一つずつ変えます。表は期待する処理を示します。
| 再開時に分かったこと | 進め方と、その後の確認 |
|---|---|
| 権限と承認が有効、資料版2と申請版4が現行、Rは未送信と確認できる | 更新直前に条件を照合し、未実行の更新へ進む。要求Rの完了と申請状態を確認して記録する |
| Uの更新権限が失効している | 更新を停止する。認可担当の確認へ戻し、必要な権限が正式に認められるまで再開しない |
| 申請が版5へ変わっている | 差分を取得して照合結果と更新内容を作り直す。版4を対象としたPを流用せず、新しい内容の承認へ戻す |
| 資料D-8が版3へ更新されている | 変更が申請判断へ及ぶか確認する。影響がある照合結果を再計算し、承認対象の条件が変わるなら再承認する |
| 保存後にRを送った形跡があり、応答を保存できていない | 結果不明として要求Rを照会する。Cの「未実行」を根拠に再送しない |
権限失効のケースでは、別の強いアカウントへ切り替えて続けることを自動の復旧方法にしません。業務上の承認と、システムがその主体に許す操作は両方必要です。OWASPのLLM06:2025 Excessive Agencyは、必要な機能・権限に絞り、下流システムで認可を検証する考え方を示しています。保存した承認フラグだけで実行を通す構成は、この実行時の確認を代替できません。
資料が更新されていなくても、古い在庫や締切の情報を現在の判断に使えるとは限りません。資料ごとに、今回の判断に必要な鮮度と失効条件を定めます。「取得から何分以内」だけで一律に決めず、元資料の有効期間や対象業務の変化を照合します。更新の有無を調べられない場合は、鮮度を確認済みにせず、影響する判断を保留します。
保存点から実行へ戻る前に、五つの状態を確定する
再開担当は、記録の文字列だけでなく、その状態を示す根拠を確認します。外部要求については、対象システムが提供する正式な履歴や照会結果を使い、どの要求・対象・時点を示すかを揃えます。
- 実行前：送信管理の記録と実行担当の状態から未送信と確認でき、現在の条件も揃えば、予定した要求へ進めます。記録の空欄だけを未送信の証拠にはしません。
- 実行中：受け付けた処理がまだ進行しているなら、同じ操作を追加せず、その要求を追跡します。
- 成功：要求Rの完了と承認した内容との一致を確認できれば、その工程を再実行せず次へ進めます。
- 失敗：終わった失敗でも、部分的な変更が残っていないかを確認します。再試行可否は権限、対象状態、サービスの契約で判断します。
- 結果不明：送信や完了を確定できない場合です。照会できないことや履歴に見つからないことだけで未実行とみなしません。
Rが完了していると分かれば、更新後の申請版を保存し、未完の後続工程だけを選びます。現在の申請が受付済みでも、Rとの対応を示せなければ「R成功」とは記しません。他の担当者が更新した可能性があるため、既に目的が達成されたかと、前回要求がどう終わったかを分けて確認します。
結果不明のまま再試行を検討するなら、同じ主体・内容・Kを使えるか、サービスの保持期間内か、先行要求が遅れて届く場合にも重複を抑えられるかを確かめます。AWSの前掲資料も、遅着する要求や、同じIDに異なる意図を載せる問題を扱っています。これらの条件を確認できなければ自動再送を止め、要求IDと既知の状態を担当者へ引き継ぎます。
再開した後も、完了を確認して閉じる
再開を許した後に対象が変更されることもあります。外部システムが対応していれば、確認した版と一致する場合だけ更新する条件を実行時にも付けます。一致しなければ更新を止め、最新状態の確認へ戻します。そうした機能がない場合は、同時更新を抑える運用などで補える範囲を調べ、残る競合リスクが許容できなければ自動再開を見送ります。
また、同じ保存点を二つの実行担当が同時に拾わないよう、現在の担当と引継ぎ状態を管理します。担当が交代しても要求Rとの対応は保持し、担当変更を新規要求の理由にしません。既存の未解決要求を解消しないまま、同じ対象へ別経路の更新を始めることも避けます。
再開後は、要求の受付、処理完了、対象の変更、後続工程の残りを確認します。受付だけなら完了と報告せず、確認できた範囲を保存します。中止を選んだ場合も、中止の決定だけでは送信済み要求が取り消されたとは扱えません。残存する処理と副作用を確認し、追加操作が必要なら、その内容に対応する権限と承認を確認します。
運用前の確認では、権限失効、版変更、資料の鮮度不明、応答消失を含む模擬記録を使い、期待する分岐を照合します。保存内容を読み戻せるかに加え、完了済みを再送しないか、保留理由と次の確認先が残るかを見る必要があります。復旧手順を閉じるときには、どの工程を再利用し、どこをやり直し、何が未確認で残ったかを記録します。次の担当者も同じ保存点から判断を追える状態にします。
ツールを連続して使うエージェントの安全設計の基本は「ツールを連続して使うAIエージェントの安全設計の基本」、タイムアウトした外部操作を照会し、二重実行を避けて再試行する方法は「タイムアウトした外部操作を照会し、二重実行を避けて再試行する」で解説しています。
