Claude Codeを無人で回していると、処理が失敗したことよりも「いつまで待てばいいのか分からない」ことの方が困ります。MCPサーバーの起動待ちで止まり続ける、メモリが膨らんでから急に不安定になる。どちらも、作業そのものが間違っているとは限りません。
Claude Code v2.1.274では、メモリ使用量が危険域に入ったときの警告と、非対話ターンでMCP接続を待つ時間に上限を設ける環境変数が追加されました。この記事では、公式リリースノートで確認できる範囲をもとに、無人実行の停止条件としてどう使うかを整理します。
「待つ」と「粘る」は同じではない
人が画面を見ているなら、MCPが起動するまで少し待つ判断は簡単です。ログが増えている、プロセスが起動中、ネットワークが一時的に遅い、といった状況を見て待てます。
しかし、スケジュール実行では事情が変わります。待ち時間が無制限だと、後続タスクが始まらず、利用上限やジョブのタイムアウトにも気づけません。無人処理では「待つこと」自体に上限が必要です。
私のタスクループでも、外部APIの取得失敗と、ツールが起動を待ち続ける状態は別に記録しています。前者は再試行できる一時障害かもしれません。後者は、その場で止めて次回に再開できるようチェックポイントを残すべき状態です。
v2.1.274で確認できる二つの変更
公式リリースノートのv2.1.274には、今回のテーマに直結する変更が二つあります。
- メモリ使用量が危険な状態に入ったときに警告し、安全な再起動や解放を促す
- 非対話ターンのMCP接続待ちを
CLAUDE_CODE_MCP_STARTUP_WAIT_MSで制限する
ここで重要なのは、どちらも「処理を必ず成功させる」機能ではないことです。メモリ警告は無理に続行しないためのサインであり、待ち時間の上限は接続できないジョブをいつまでも抱えないための境界です。
CLAUDE_CODE_MCP_STARTUP_WAIT_MSの考え方
環境変数名の通り、MCPの起動を待つ時間をミリ秒単位で指定します。たとえば、まず待たずにターンを進めたい場合は次のように設定できます。
$env:CLAUDE_CODE_MCP_STARTUP_WAIT_MS="0"
claude -p "run the read-only check"0は「待たない」という明示的な境界です。ただし、これを常に推奨する意味ではありません。ローカルでMCPプロセスが毎回数秒かかる環境なら、短い待ち時間を設定した方が一時的な起動遅れを吸収できます。
# 例: 10秒だけ待つ
$env:CLAUDE_CODE_MCP_STARTUP_WAIT_MS="10000"
claude -p "run the scheduled check"この値を大きくすれば成功率が上がる、という単純な関係ではありません。MCPサーバーが落ちている、認証が切れている、接続先が応答しない、といった原因なら、10分待っても成功しません。
無人ランでは「待ち時間」と「再試行」を分ける
待ち時間の上限を決めるとき、再試行回数まで一緒に増やしたくなります。しかし、両方を無制限にすると、障害時にジョブ全体が長時間占有されます。
私なら、次の三層に分けます。
- MCP起動待ちには短い上限を置く
- 一時的な通信エラーだけ、決めた回数まで再試行する
- それでも失敗したら、証跡を残して次回に持ち越す
この分離があると、「MCPが起動しなかった」のか「起動したがAPIが失敗した」のかを後から説明できます。
メモリ警告が出たら何を残すか
メモリ警告を見たとき、最初にすべきことは作業を続けることではありません。直前のタスク、使用したツール、長時間残っていたプロセス、再起動の有無を短く記録します。
timestamp=2026-09-22T09:03+09:00
task=T-013
warning=memory usage critical
action=stop and resume next run秘密情報やアクセストークンをログに書く必要はありません。バージョン、タスクID、警告の有無、次に再開する位置だけで十分です。
再起動で解決する場合もありますが、原因が毎回同じなら別の問題です。MCPサーバーの数、出力の大きさ、長時間セッションの維持方法を見直す必要があります。
チェックポイントと相性がいい
待ち時間の上限やメモリ警告は、途中停止を前提にした運用と組み合わせて初めて役に立ちます。複数のユニットを処理するタスクなら、完了したIDと次のIDを保存します。
CHECKPOINT: done=001,002,003 next=004次の起動でこの行を読めば、完了済みの作業を繰り返さずに済みます。反対に、チェックポイントがない状態で無理に最後まで走らせようとすると、利用上限やメモリ問題が起きた時に進捗が曖昧になります。
私の運用では、環境障害で処理できなかったタスクは未着手のまま戻し、run reportに失敗理由と再試行日を残します。仕様が間違っている場合は要設計に分けます。環境障害と仕様問題を混ぜないことが、復旧を早くします。
設定値を記録しても、実際の動作を証明したことにはならない
CLAUDE_CODE_MCP_STARTUP_WAIT_MSを設定したからといって、MCPがその時間内に起動したとは限りません。設定値は「そう指定した」という証拠であり、接続成功の証拠ではありません。
検収では、MCPの接続結果、コマンドの終了コード、変更されたファイルやAPIの戻り値を別に確認します。設定と実測を同じものとして扱わないのは、無人運用全般で大切な習慣です。
最小の切り分け手順
まず、現在のバージョンと環境変数を確認します。
claude --version
$env:CLAUDE_CODE_MCP_STARTUP_WAIT_MS次に、読み取りだけの小さなターンでMCP接続を試します。最初から本番の一括処理を使わず、待ち時間を短くしたケースと通常値のケースを比較します。
$env:CLAUDE_CODE_MCP_STARTUP_WAIT_MS="10000"
claude -p "list the available MCP tools and return only their names"失敗した場合は、待ち時間を増やす前に、MCPプロセスが起動しているか、認証が有効か、接続先が応答しているかを確認します。待ち時間の問題に見えて、実際は接続設定の問題ということがあるからです。
待ち続けないことは、失敗を増やすことではない
無人処理で大切なのは、すべてのジョブを一度で成功させることではありません。失敗したときに、どこまで進んだか、なぜ止まったか、次に何をすべきかが分かることです。
MCP起動待ちに上限を置くと、一見すると成功するまで粘らなくなります。しかし、その分だけ後続の監視や次回実行へ制御を返せます。メモリ警告も同じで、危険な状態を「まだ動くから」と見過ごさずに済みます。
まとめ
Claude Code v2.1.274では、メモリ使用量の危険域を知らせる警告と、非対話ターンのMCP接続待ちを制限するCLAUDE_CODE_MCP_STARTUP_WAIT_MSが追加されました。
0なら待たない、正の値なら指定した時間だけ待つ、という境界を使えます。ただし、待ち時間を増やす前に、MCPの起動・認証・接続先の応答を切り分けるべきです。
無人ループでは、短い待ち時間、限定的な再試行、チェックポイント、そして警告の記録を組み合わせます。止まる条件を決めることは、作業を諦めることではなく、次の実行に責任を持って引き継ぐための設計です。
コメント