AIエージェントの自動復旧｜2層に分ける実装と停止条件

セッションは、こちらの都合と関係なく終わります。クラッシュ、再起動、アップデート。作業そのものはディスクに残っていても、「どこまでやったか」が失われると、次に開いた側はゼロから状況を組み立て直すことになります。

やっかいなのは、止まったことに誰も気づかない場合です。担当が思い出したときだけ再開する運用は、思い出さなかった回にそのまま止まります。

この記事は、止まった作業をAIエージェント自身が拾い直す自動復旧を、実装のかたちで扱います。素材は運用中のSessionStartフックと再開スキル、そして常駐監視が利用者の作業を止めた事故の記録です（2026-08-03検証）。

進行役は3人です。高梨課長が自分の手で動かす側から聞き、大森部長が体制と責任の側から聞き、鈴木さん（本誌監修）が答えます。

01AIエージェントの自動復旧って、そもそも何が自力で動くんですか？

高梨課長

高梨課長の発言

セッションが落ちても続きを勝手にやってくれる、という理解でいいのでしょうか。

鈴木さん

鈴木さんの発言

半分だけ合っています。自力で動くのは「続きを探すところ」と「手前まで進めるところ」で、最後の一歩はこちらに返ってきます。夜勤の引き継ぎに近い形です。

高梨課長

高梨課長の発言

最後の一歩、というのは。

鈴木さん

鈴木さんの発言

送る・出す・消すです。そこはAIエージェントに越えさせません。

自動復旧とは、中断した作業をAIエージェント自身が見つけ直し、人の判断が要る地点の手前まで進める仕組みです。単一の機能ではなく、役割の違う2つの層でできています。

• 検知層：セッションが始まった瞬間に、止まっている作業があるかどうかを画面へ出す。表示するだけで、書き換えも実行もしない。
• 再開層：検知層が出した一覧のうち、再開してよいものだけを、人間ゲートの手前まで進める。

WEBMARKSはこの2層構成を2026-06-13に導入しました。導入時点で棚卸しした進行中案件8件を台帳へ初期登録したところ、作業データの消失はゼロで、止まっていたのは最終報告のステップだけでした。失われていたのは成果物ではなく、「どこまでやったか」という状態のほうだった、ということです。

自動化全体の中での位置づけは、AIエージェントの自動化は4層｜着手する順番と稼働の数え方の1レイヤーにあたります。再開までに何をどの順で読むかはAIエージェントのセッション継続｜作業を失わない読む順序5段に譲り、本記事は実装と停止条件に絞ります。

02検知と再開を、AIエージェントの自動復旧ではなぜ分けるんですか？

分ける理由は3つあります。

1. 気づきに依存させないため。 検知はハーネス側に強制させます。AIが「そういえば止まっていました」と思い出す運用は、思い出さなかった回に止まります。
2. 検知に実行させないため。 一覧を出すだけの層に書き換えの力を渡さなければ、誤って検知しても実害が出ません。
3. 止まる場所を1か所にするため。 手を動かすのが再開層だけなら、境界の設計もそこだけで済みます。

2つの層の役割は、次のとおりです。

検知層に実行の力が無いのは、社内の取り決めである以前に、ツール側の仕様です。SessionStartは公式ドキュメント上、セッションをブロックできない表示専用のフックと明記されています（出典: Claude Code公式ドキュメント、2026-08-03確認）。

時間の軸で見ると、2つの層は幅が違います。検知は起動の瞬間だけの点で、再開はそこから壁までの区間です。点と区間を1つの部品にまとめると、点のほうが区間ぶんの権限を持ってしまいます。

03自動復旧を組む前に、AI導入の現場では何を用意しておくんですか？

高梨課長

高梨課長の発言

設定ファイルにフックを書けば、その場から効き始めるのでしょうか。

鈴木さん

鈴木さんの発言

そこは1回ずれます。配線した回ではなく、次に開いたセッションから効きます。自分で自分の権限を書き換えられないようにしてある仕様なので、書いた直後に試して「動かない」と判断しないほうがいいです。

着手前に用意するものは3つです。

1. 状態を書き続ける台帳：自動復旧はゼロから状況を推測しません。着手時・節目ごと・人間ゲート到達時・完了時に、AIエージェント自身が台帳へ書き込む運用が前提です。書かれていない状態は再開できません。
2. フックを配線する権限：.claude/settings.jsonのhooks.SessionStartへの登録には、ハーネス側の承認ダイアログでの許可が要ります。効き始めるのは次のセッションからです。
3. 常駐監視デーモンを作らない、という決定：絶えず動き続けて見張るプロセスではなく、起動した瞬間にだけ発火するフックで作ります。この判断の根拠は、後述する事故です。

3つのうち、抜けたときにいちばん静かに壊れるのは1つ目です。フックが無ければ「何も出ない」とすぐ分かります。台帳が薄い場合は、それらしい一覧が出たうえで再開できないという形になり、原因にたどり着くまで時間がかかります。

たとえで並べると、自動復旧は特別な技術ではありません。交代前にメモを残し、次の担当が机の上を見て、続きから手を動かす。その流れを、落ちても消えない場所へ置き直したものです。

04自動復旧で台帳のどの状態を、AI社員は再開してよいものとして扱うんですか？

台帳が持つ状態は5種類です。検知層はこの文字列だけを根拠に振り分けます。

再開してよいのは🔴だけです。🟡は「AI側の仕事が終わっている」状態なので、ここに手を出すと人の判断を追い越すことになります。

05台帳の1件は、AIエージェントが読み直せる形でどう書くんですか？

台帳1件は、次の形式で書きます。パーサはこの書式だけを契約として読みます。

### TASK-221 ｜ 記事執筆バッチの自動復旧
- 状態: 進行中
- フォルダ: 06-todo/クロード構築_進行中_20260624/...
- 最終更新: 2026-08-03
- 次の一手: 手順②のコード検証を終わらせる
- 人間ゲート: （未到達）

再開の質を決めているのは「次の一手」の1行です。 ここが「続きをやる」で終わっていると、次に開いたAIエージェントは、何が続きなのかを本文から推測する羽目になります。推測から始まった再開は、たいてい前の担当と違う方向へ進みます。

登録の設定ファイルは、次のような形になります。matcherにはstartup（新規開始）やresume（再開）などの値を指定でき、発火条件を絞り込めます（出典: Claude Code公式ドキュメント）。

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/check-unfinished-tasks.py"
          }
        ]
      }
    ]
  }
}

06手順①｜SessionStartフックは、AIエージェントの中断をどうやって見つけるんですか？

検知層の実体は.claude/hooks/check-unfinished-tasks.pyです。セッションが始まるたびに発火し、台帳を読んで結果を画面へ出すだけの、実行力を持たないフックです。

def main():
    root = project_dir()
    ledger = os.path.join(root, LEDGER_REL)
    if not os.path.isfile(ledger):
        return 0

    validation_error = ()
    try:
        validation_error, parse_ledger, render_summary = load_governance(root)
        with open(ledger, encoding="utf-8") as handle:
            tasks = parse_ledger(handle.read())
        print(render_summary(tasks))
    except Exception as exc:  # フックは止めず、構造エラーを可視化する。
        if validation_error and isinstance(exc, validation_error):
            print(f"❌ タスク台帳エラー: {exc}")
        else:
            print(f"⚠️ タスク継続チェック判定不能: {exc}")
    return 0

読みどころは、どの枝を通ってもreturn 0へ合流する点です。台帳が無くても、書式が壊れていても、想定外の例外が飛んでも、セッションは続きます。壊れているときは❌タスク台帳エラー、それ以外の例外では⚠️タスク継続チェック判定不能を出し分けて画面へ表示するだけで、起動そのものは止めません。

例外を握りつぶしているのではありません。画面には出したうえで、起動は続ける。「気づける」と「止める」を分けているのが、この数行です。

07検知した結果を、AIエージェントに実行させないのはなぜ安全なんですか？

Claude Codeの公式ドキュメントは、SessionStartをブロックできないフックと明記しています。exit code 2を返してもセッションは止まりません。トランスクリプト（会話記録）にエラー表示が残るだけで、Claude自身はその内容を見ません（出典: Claude Code公式ドキュメント、2026-08-03確認）。「止めない」は設計の方針であると同時に、ツール側から与えられた制約でもあります。

台帳の分類ロジックは、状態欄の文字列を読んで3種類に振り分けます。

さらに、最終更新の日付が実行日より前の進行中タスクには「⚠️前回更新が本日以前＝中断疑い」という注記が1行足されます。これは日付文字列の単純な比較で、複雑な時刻計算はしていません。

判定を素朴に保っているのは、手抜きではありません。表示しかしない層で誤って検知しても、出るのは余分な1行だけです。同じ判定を実行できる層に持たせていたら、この素朴さは危険側へ働きます。どこまで簡単に作ってよいかは、その層が何をできるかで決まります。

08手順②｜resume-tasksは、AIエージェントの作業をどこまで進めるんですか？

高梨課長

高梨課長の発言

再開が始まったら、どこまで勝手に進むのでしょうか。止まる位置が読めないと任せづらいです。

鈴木さん

鈴木さんの発言

走り出す前に、これから何件やるかを先に出させています。読めないまま動き始めるのがいちばん怖いので、一覧を見てから走る順番にしてあります。

検知層が🔴を提示したら、再開層であるresume-tasksスキルが実際の再開を担当します。「やり残し確認して」と手で呼び出すことも、フックの提示を見て起動することもできます。

手順は7段です。

1. 台帳をロードする
2. in-progressフォルダとgit履歴を突き合わせ、台帳と実態のズレ（ドリフト）を検知する
3. 状態ごとに仕分ける（進行中＝再開対象／人間ゲート待ち＝再開しない／保留＝触らない）
4. 🔴の一覧を先に提示し、これから何件を自動再開するかを明示する
5. 各タスクの次の一手を読み、人間ゲートの手前まで作業を進める
6. 到達した状態（人間ゲート待ち・完了・続行中のいずれか）に応じて台帳を書き直す
7. 進めた内容・止めた人間ゲート・次に人がすべきことを報告する

自動で再開してよいのは、4の一覧提示のあと、かつ🔴に分類されたタスクだけです。🟡人間ゲート待ちと保留（意図的）は、一覧に載せるだけで対象から外します。

2つの層が共有しているものは、台帳の状態だけです。検知層はそれを読み、再開層は読んだうえで書き直します。互いを呼び出さず、同じ1つの文字列を見ているだけなので、片方が止まってももう片方は道連れになりません。

2段目のドリフト検知は、見落とされやすい工程です。台帳が「進行中」でも、成果物は既に出来上がっていることがあります。ここを飛ばすと、完成済みの仕事をもう一度作り直すという、いちばん高くつく失敗が起きます。

09暴走させないために、AIエージェントの自動復旧にはどんな境界を引くんですか？

境界は4つのHARD GATEとして明文化されています。

4つに共通するのは、どれも「やらない」の形で書かれていることです。やってよいことを列挙する書き方だと、書き漏れた操作が自動的に許可側へ落ちます。

1つ目の条件は、手順書だけに頼っていません。git pushのような操作は、別のフックでも二重に拒否されます。実際に本記事の取材中、保護対象のフック本体をgrepで覗こうとしただけで、次のメッセージとともに拒否されました（2026-08-03実測）。

⛔ bash-guard: R0のguard/policy/固定拒否入口は人間確認なしに変更できません。

読み取るだけのコマンドでも、保護対象への操作とみなされて止まっています。手順書に書いた境界は守られる前提の約束で、機械が返す拒否は守らせる仕組みです。 自動復旧のように、人が画面を見ていない時間帯に動くものほど、後者を重ねておく価値があります。止める処理そのものの書き方はClaude CodeのPreToolUseで危険コマンドを遮断する4つの判定で扱っています。

10常駐監視が利用者の作業を止めた事故から、AIエージェントの自動復旧は何を学ぶんですか？

大森部長

大森部長の発言

自動で直しに行く仕組みは、うちでも作れそうです。危ないとしたら、どこですか。

鈴木さん

鈴木さんの発言

対象の選び方です。ファイルや台帳なら止めても誰も困りませんが、その人がいま触っているアプリに手を出すと、体感は「勝手に動いた」になります。

大森部長

大森部長の発言

条件を絞れば済む話ではないのですか。

鈴木さん

鈴木さんの発言

そう思って絞りました。それでも苦情は消えませんでした。

WEBMARKSには、似た発想で作った常駐監視が、実際に利用者の作業を止めた記録が残っています（2026-07-28、社内タスク台帳より）。

Claudeデスクトップアプリを複数アカウントで併用する構成を整えていたときのことです。「Dockから開き直すと共有プロファイルに戻る」という不具合を塞ぐため、次の2つの常駐プロセスを導入しました。

結果は、アプリが利用者の操作と無関係に立ち上がったり消えたりする状態でした。社内タスク台帳には「めちゃくちゃ」「意味がわからないくらいやばい」という強い苦情が記録されています。

原因は権限の広さではありません。利用者が直接操作しているアプリを、AIの判断だけで終了・再起動させる設計そのものが誤りでした。「起動から60秒以内だけ動く」という条件を足しても、利用者から見た体感は「勝手に動く」のままでした。

是正は同日中に行われ、常駐2本はlaunchctl bootoutで停止し、設定ファイルは削除せず無効化用フォルダへ退避されました。再設置には、環境変数を明示しない限り起動しない安全装置が加えられています。

11生成AIに任せる自動復旧の対象は、どこで線を引くんですか？

事故を受けて確定した原則は2つです。

1. 検知して報告するが、終了は人がやる。 自動復旧が扱ってよいのは、利用者が直接触っていない対象（ファイル・台帳・バックグラウンドのジョブ）に限ります。
2. 常駐監視デーモンではなく、発火するフックで作る。 タスク台帳の自動復旧がSessionStartという起動の瞬間にだけ発火するフックを採用しているのは、この種の事故を避ける設計判断でもあります。

対象を決めるときの問いは1つです。「これは、利用者が今まさに直接触っているものか」。 答えがはいなら、自動復旧の対象から外します。生成AIに任せる範囲を広げたいときほど、この問いを先に通します。

言い換えると、自動復旧の安全性は権限の細かさでは決まりません。触る相手が、いま誰の手の中にあるかで決まります。同じ「終了させる」操作でも、放置されたバックグラウンドのジョブと、画面の前で使われているアプリでは、意味がまったく違います。

12動いていることは、AIエージェントの自動復旧のどこで確かめるんですか？

大森部長

大森部長の発言

導入したかどうかは、何をもって言えばいいのでしょう。

鈴木さん

鈴木さんの発言

直近の実行結果が見えたときだけです。設定を書いた事実と、いま動いている事実は、別に数えています。

自動復旧が機能しているかどうかは、次の基準で判定します。

• SessionStartフックが、セッション開始のたびに🔴・🟡の一覧を表示しているか
• 表示だけで、ファイルの書き換えやコマンド実行が発生していないか（git statusの差分に検知層由来の変更が無いこと）
• resume-tasksが再開したログの中に、送信・公開・削除・push・先方提示に相当する実行コマンドが1件も無いか
• 人間ゲート待ちに到達したタスクの台帳が、「人間ゲート」欄に具体的な待ち内容を書いた状態で止まっているか
• 仕組み自体が生きているかを、実行記録の鮮度で定期的に確かめているか

最後の項目は見落としやすい観点です。WEBMARKSは、利用量上限が明けたタイミングで自動再開を試みる仕組みも別途設計しています。ただしその実行記録ファイルは、最終更新が2026-07-13のまま止まっていることが2026-07-28の実測で判明しました。止まってから15日間、誰も気づいていません。

自動復旧は、静かに止まります。 動いていないときの画面は、うまく動いているときの画面と見分けがつきません。どちらも何も出ないからです。鮮度を見に行く人がいない限り、止まった事実は次の事故まで表に出ません。

13よくある質問

14まとめ｜今日やる3つのこと

自動復旧は、賢い仕組みを1つ作る話ではありませんでした。見つける役と進める役を分け、止まる場所を先に決め、動いていることを人が見に行く。この3つが揃ったときにだけ、止まった作業は拾い直されます。

<!-- moc-backlink -->