AIエージェントを長時間放置する前に確認する6つのこと──Claude Codeの公式ドキュメントから逆算するチェックリスト

Claude Codeには、席を外している間もエージェントを働かせ続けるための機能が複数ある。完了条件を指定して回し続ける/goal、外出先のスマホから同じセッションを覗ける Remote Control、コードの変更をPRの段階でチェックする Code Review、一定間隔でプロンプトを繰り返す/loop。それぞれの公式ドキュメントを読み比べると、「放置して大丈夫な範囲」と「放置してはいけない境目」が機能ごとに違う形で設計されていることが分かる。この記事では、その境目を4つの公式ドキュメントから拾い上げ、放置前に確認すべき6項目としてまとめた。

3行まとめ

1. /goalは「条件を満たした」「不可能と判断した」「直せないエラーが起きた」の3パターンでしか自動的に止まらない。レート制限のような一時的なエラーではゴールが放置され続ける
2. Remote Controlは「もう1台の端末が同じセッションを乗っ取った」状態を検知できるが、乗っ取られたことに気づくのは自分がその端末を確認しに行った時だけ。Code Reviewは指摘を出すだけでPRを承認もブロックもしない
3. /goal・/loopはどちらもセッションが生きていることが前提の機能で、ターミナルを閉じれば止まる。公式ドキュメントは、本当に無人で回したいなら「Routines」「GitHub Actions」「Desktop scheduled tasks」を使うよう案内している

1. 完了条件は「Claudeの発言だけ」で判定できる形か

/goalの判定を行う評価モデルは、コマンドを実行したり、ファイルを開いて中身を確認したりはしない。公式ドキュメントは評価の限界をこう明記している。

The evaluator runs on whichever provider your session is configured for. It does not call tools, so it can only judge what Claude has already surfaced in the conversation.

つまり、「テストが通っている」という条件を設定しても、Claude自身がnpm testを実行してその結果を会話に出力していなければ、評価モデルは判定のしようがない。放置する前に、完了条件が「Claudeの作業ログに現れる形で証明できるか」を確認する必要がある。公式ドキュメントも、条件には「測定可能な終了状態」「どう証明するかの一文（npm testが0で終了する、など）」「途中で崩してはいけない制約」の3つを含めるよう推奨している。

2. 「止まらない」のは異常時にどちらの方向か

/goalが自動的にクリアされる（＝止まる）のは、次の4種類のエラーが起きたときだけだと公式ドキュメントは明記している。

• An authentication failure, when Claude Code manages its own credentials(...)
• An exhausted credit balance
• A context overflow that auto-compaction couldn't clear
• A model that isn't available

逆に言えば、レート制限やサーバー過負荷のような一時的なエラーでは、ゴールはクリアされず、そのまま生き続ける（"After any other failure, including transient errors such as rate limits and overloaded servers, Claude Code leaves the goal active."）。放置している間に一時的なエラーが起きても自動では止まらない、という前提で見に行く頻度を決める必要がある。

3. バックグラウンド作業の「チェックイン」間隔を知っているか

サブエージェントやバックグラウンドのシェルコマンドが動いている間、/goalの完了判定はスキップされ続ける。公式ドキュメントによれば、この待機が30分続くと最初の「チェックイン」が発生し、以降は前回の2倍の間隔（1時間後、2時間後…最大で最初の間隔の4倍まで）で繰り返される。

対話セッションでは、チェックインのタイミングでClaude Code側から自発的にターンを開始してくれる。ただし公式ドキュメントは、この自発的な「アイドル中チェックイン」が1つのゴールにつき最大3回までしか発生しないと明記している。

Claude Code starts at most three idle check-ins per goal between your prompts. In the third idle check-in, Claude Code says that idle check-ins are paused until you send another prompt.

そして、-pで起動した非対話セッションでは、このアイドル中チェックインの仕組み自体が使えない。バックグラウンド作業が止まったまま何も報告せず、次にあなたがプロンプトを送るまで気づく手段がない、という状態になりうる。CI・自動化スクリプトから/goalを非対話で回すなら、この制限は事前に知っておく価値がある。

4. 遠隔から「今何が起きているか」を確認できる状態か

Remote Controlを使えば、スマホやブラウザから同じローカルセッションを確認できる。ただし利用条件には制約がある。公式ドキュメントには次のように明記されている。

Subscription: available on Pro, Max, Team, and Enterprise plans. API keys are not supported.

APIキーだけで動かしている自動化パイプラインには、Remote Controlは使えない。また、複数端末から同じセッションを操作できる設計上、「別の端末がセッションを乗っ取った」状態も起こりうる。公式ドキュメントは、乗っ取られた場合の挙動をこう説明している。

Another device or Claude Code session took the session over: run /remote-control only if you want to take it back from that device.

つまり、乗っ取られたこと自体を能動的にプッシュ通知してくれるわけではなく、次に自分がその端末を確認しに行ったときに初めて分かる仕組みだ。「あとで見れば大丈夫」ではなく、「見に行く」行為そのものが検知の起点になる。

5. コードの変更を、どの段階で人間が見るか

Code Review（GitHub PR向けの自動レビュー機能）は、ロジックの誤りやセキュリティ上の懸念を検出して指摘コメントを付ける。しかし公式ドキュメントは、この機能の位置づけをこう明記している。

Findings are tagged by severity and don't approve or block your PR, so existing review workflows stay intact.

指摘は🔴（重要）🟡（軽微）🟣（既存バグ）の3段階でタグ付けされるが、PRを承認も差し止めもしない。レビューが走ったという事実は「誰も見ていない」ことの証明にはならず、マージするかどうかの最終判断は依然として人間側の作業として残る。長時間の放置運用で「コードの変更点をどのタイミングで、誰が実際に読むか」を決めておかないと、Code Reviewの指摘がついたまま気づかれずにマージされる状態が起こりうる。

6. 「セッションを閉じても回り続ける」と思い込んでいないか

/goalと並んで長時間運用の選択肢に挙がる/loop（プロンプトを一定間隔で繰り返す機能）について、公式ドキュメント「Run prompts on a schedule」（curlで確認）は、この機能がセッションに紐づく点を明記している。

"Tasks only fire while Claude Code is running and idle. Closing the terminal or letting the session exit stops them firing."

タスクはClaude Codeが起動していて、かつアイドル状態のときにしか発火しない。ターミナルを閉じる、あるいはセッションが終了すると、発火自体が止まる。同ドキュメントはさらに、「新しい会話を始めるとセッション紐づけのタスクは全て消える」「予定時刻を逃したタスクにキャッチアップの仕組みはなく、次にアイドルになったタイミングで1回だけ発火する」とも明記している。

/goal・/loop・Stop hookという3つの「セッションを回し続ける」アプローチの違いを、同ドキュメントの表（curlで確認）から整理するとこうなる。

本当に「セッションを閉じて放置」したいなら、/goal・/loopのどちらもセッションが生きていることが前提の機能であり、ターミナルを閉じれば止まる。ドキュメントは、無人での定期実行が本当に必要な場合の選択肢として、クラウド上でスケジュール実行される「Routines」、GitHub Actionsのscheduleトリガー、ローカルのデスクトップスケジュールタスクの3つを別途挙げている。「放置」のつもりが実は「ターミナルを開きっぱなしにする」だっただけ、というズレは、放置前に確認しておく価値がある。

この4つの公式ドキュメントを横断した記事は他に見当たらなかった

• これら4機能を横断して使うことを想定した公式のベストプラクティスやチェックリストは見当たらなかった。 本記事の6項目は、それぞれ独立した公式ドキュメントの記述を編集部側で突き合わせて構成したものであり、Anthropicが公式に「この6つを確認しろ」と推奨しているわけではない。
• チェックイン間隔（30分・1時間・2時間…）やアイドル中チェックインの上限回数（3回）は、Claude Codeのバージョンによって変わる可能性がある。 ドキュメント中にも「Idle check-ins require Claude Code v2.1.236 or later」「Before v2.1.246, idle check-ins were uncapped」といったバージョン依存の記述があり、手元の環境のバージョンによって挙動が異なりうる。
• 「Routines」「Desktop scheduled tasks」など、/loopの代替として公式が挙げる無人実行の選択肢そのものは、本記事では中身を検証していない。 scheduled-tasksドキュメントが「無人実行にはこちらを使え」と案内している先のドキュメントまでは踏み込んでおらず、それぞれの仕組み・制約は別途確認が必要。
• 他社（Codex、Devinなど）の同種機能との比較は本記事では行っていない。 ここで扱ったのはClaude Code単体の公式仕様に限定している。
• 実際に長時間放置して事故が起きた事例のデータは持っていない。 本記事はドキュメントの仕様読解であり、放置運用の実測データに基づくものではない。

あわせて読みたい

• Claude Codeの/goalコマンド──「続けて」を打ち続ける代わりに完了条件を渡す
• Claude Code、8月14日からautoモードがデフォルトに──「人間の承認は危険コマンドの13.6%しか止めていない」
• Claude Codeがエラーで動かない時の切り分け手順──400・401・403は「認証の優先順位」を疑う
• Claude Codeとは──コード生成に留まらない「仕事を渡せる」AIエージェント
• Claude Code・Codex・Devin──「APIキーを配らない」認証への移行が同時に進んでいる