中断したAIエージェントの作業を再開する前に:実行済みの外部操作と未完了の操作を点検する
AIを使いこなすClaudeで執筆し、GPTで自動校閲・修正しています。

結論から言うと、中断したエージェントに「続けて」と送る前に、メール送信・予定登録・ファイル更新・削除など外部で変わったことを、会話の記録ではなく外部の実物で確認してください。会話の履歴は「何を依頼し、どう返ってきたか」の記録です。「いま外部がどうなっているか」の保証ではありません。ここがずれたまま再開すると、二重送信や二重登録、取り消し漏れが起きえます。 この記事では、点検を3段階に分けます。(1) 再開を止めて記録を集める、(2) 操作を一つずつ外部で確かめて分類する、(3) 分類結果を渡して再開する。各段階で使える依頼文と、書き込み式の「再開前点検表」を用意しました。
この記事の目次
先に押さえる:再開機能が保証しないこと
Claude Codeのセッション管理のドキュメントによると、再開したセッションでは会話履歴(メッセージ、ツール呼び出し、結果)が復元されます。一方で、プロセス終了時に実行中だったツール呼び出しは、再開しても再実行されないと書かれています。バックグラウンドのBashコマンドなどは復元されず、「終わらなかった」という注記として記録に現れます。--mcp-configなどの起動時オプションも、再開時に渡し直す必要があります。
ここから言えるのは次の点です。再開機能は勝手に二重実行しないように作られていますが、実行中だった操作の結果は記録上あいまいなまま残ります。外部サービスに届いていたかどうかは、記録だけでは分かりません(これは上記の仕様説明からの私見を含む整理です)。そこで、AIに「たぶん未完了です」と判断させず、人が確認する工程を挟みます。
巻き戻し機能にも限界があります。チェックポイントの説明では、追跡対象はファイル編集ツールによる変更で、Bashコマンドだけで変わったファイルや、セッション外の変更は追跡されないとされています。メールやカレンダーなど外部サービスの変更は、ファイルの巻き戻しの対象外と考えて計画してください。ここは文書がファイルについて述べている内容からの推論です。
手順1:まず再開を止めて、記録を集める
中断直後に「続きをお願いします」と送るのは避けます。エージェントが記録を読み、未完了と思った操作をその場で再実行する恐れがあるためです。
- 実行環境の操作ログ、またはツール呼び出し履歴を開きます。MCPの仕様は、ツール呼び出しの監査と確認に役立つ情報をユーザーに表示するよう推奨しています。ログがある環境なら、会話よりそちらが一次情報に近くなります。
- 書き込み系のツール(送信、作成、更新、削除、支払い、公開)に絞って一覧にします。
- 次の「点検依頼文」で、AIに読み取りだけをさせて一覧を作らせます。
AIに渡す点検依頼文
作業が途中で中断しました。まだ何も新しく実行しないでください。
次のことだけ行ってください。
1. これまでのツール呼び出しのうち、外部の状態を変えうるもの
(送信・作成・更新・削除・公開・課金)を時系列で一覧にする
2. 各操作について、記録上の状態を「成功の応答あり/エラー応答/応答なし(結果不明)/未着手」で分類する
3. 各操作について、実際に変わったか確認する方法(開く画面、検索条件、確認用の読み取りツール)を提案する
4. 書き込み・削除・送信は一切行わない。読み取りで確認できない点は「不明」と書くAIが出した一覧は下書きとして扱います。MCPの仕様では、ツールの注釈(読み取り専用かなどの説明)は信頼できるサーバーからのものでない限り信頼してはならないとされています。ツールの説明書きだけを根拠に「この操作は安全」と判断しないでください。
手順2:外部で確かめて、再開前点検表に書く
次の表が、本記事の成果物である再開前点検表です。1操作1行で、コピーして使えます。
- 1、依頼内容:、記録上の状態:成功/エラー/結果不明/未着手、外部で確認した実状態(場所・時刻):、分類:実行済み/未完了/二重実行の恐れ、再開時の扱い:再実行しない/再実行する/人が実施/取り消す
「外部で確認した実状態」の欄が空の行は、分類できません。記録上は「結果不明」でも、送信済みフォルダに実物があれば「実行済み」になります。反対に記録上は「成功」でも、確認画面に実物がなければ、別の問題を調べる必要があります。
説明用の例
次は架空の作業で埋めた例です。実際に操作した結果ではありません。作業は「社内勉強会の案内を出す」です。
- 1、依頼内容:カレンダーに勉強会を登録、記録上の状態:成功、外部で確認した実状態:該当日に予定が1件ある、分類:実行済み、再開時の扱い:再実行しない
- 2、依頼内容:参加者へ案内メールを送信、記録上の状態:結果不明、外部で確認した実状態:送信済みに同じ件名が1通ある、分類:実行済み(記録に残っていないだけ)、再開時の扱い:再実行しない
- 3、依頼内容:参加者名簿シートに3行追記、記録上の状態:結果不明、外部で確認した実状態:追記が2行だけ、分類:未完了+二重実行の恐れ、再開時の扱い:人が3行目を確認し、不足分だけ追記
- 4、依頼内容:古い案内の予定を削除、記録上の状態:未着手、外部で確認した実状態:古い予定が残っている、分類:未完了、再開時の扱い:手順3で改めて承認してから実行
行2が重要です。記録だけを見ると「結果不明」なので、再開したエージェントは再送するかもしれません。送信済みを確認していれば、それを止められます。
手順3:分類を渡して、範囲を絞って再開する
点検表ができたら、その内容を貼り付けて再開を依頼します。「全部やり直して」ではなく、「この行だけ」と範囲を限定するのがポイントです。
点検表を貼ります。この内容を事実として扱ってください。
- 「実行済み」の行は、再実行も確認のための再送もしないこと
- 「未完了」の行だけ、上から順に実行すること
- 「二重実行の恐れ」の行と、削除・送信・公開・課金は、
実行前に対象と内容を私に見せて、承認を待つこと
- 各操作の後、外部の状態を読み取りで確認し、結果を点検表の形式で報告することMCPの仕様は、ツール呼び出しを拒否できる人の関与があるべきだとし、確認画面の提示を推奨しています。再開時は特に、承認を省略せず、承認の前に操作内容が見える状態にしておくと安全です。
操作の種類ごとの判断表
再実行してよいかは、操作の性質で変わります。これは編集上の目安で、公式の規則ではありません。
- 読み取り、例:検索、一覧取得、二重実行の影響:ほぼなし、再開前に確認すること:不要(再実行可)
- 上書き、例:同じ値を設定、二重実行の影響:同じ結果に落ち着きやすい、再開前に確認すること:他の人が間に変更していないか
- 追記・新規作成、例:メール送信、行追加、予定登録、二重実行の影響:重複が生じる、再開前に確認すること:同じ内容が既に存在するか
- 削除・公開・課金、例:ファイル削除、投稿、決済、二重実行の影響:取り返しがつきにくい、再開前に確認すること:必ず人が実状態を確認し、承認後に実施
追記・新規作成は、実行前に「同じ内容がもうあるか」を読み取りで調べさせる指示にすると、重複を防ぎやすくなります。
中断の原因別に、追加で見る点
- 通信切れやタイムアウト:相手側で処理が完了している可能性があります。応答が返らなかった操作ほど、外部の確認を優先します。
- 途中で内容を直した:中断前の古い指示が残っていることがあります。点検表には最新の意図だけを書いてください。
- 複数のエージェントやサブエージェントが動いていた:Claude Codeの説明では、サブエージェントの編集は通常のチェックポイントに載らないことがあります。誰が何を実行したかを分けて点検します。
- 同じ作業を別の画面から人が進めていた:記録に出ない変更が入っています。外部の実状態が最終判断の根拠になります。
点検表の行が埋まるまでは、再開しない。これを守るだけで、二重実行と取り消し漏れの大半の入口を塞げます。

