AIの無人実行が止まる原因3つ｜エラーが出ない停止の見つけ方

「夜のうちに終わっているはずの作業が、朝見たら何も進んでいない」「エラーは出ていないのに、成果物だけが無い」——AIを無人で走らせ始めた人が、必ず一度はぶつかる状況です。

結論から言うと、無人実行の失敗はエラーではなく「静かな停止」として来ます。2026年9月16日（協定世界時）に配布された Claude Code 2.1.274 には、この「静かな停止」にあたる修正と追加が3種類まとめて入りました。設定が落ちる・待ちで止まる・メモリで止められる、の3つです。

株式会社Fyveは、常時起動の Mac mini 1台で毎日十数本のAIジョブを人手を介さずに回しています。この記事では、その運用者の視点から、3つの型それぞれについて「何が起きていたのか」と「自分の環境でどう確かめるか」を、変更履歴とnpmレジストリという一次の配布物に当たって整理します。

無人実行では、失敗が「エラー」ではなく「静かな停止」として来る

対話でAIを使っているとき、異常は画面が教えてくれます。止まれば気づきますし、変な出力が出れば読んだ瞬間に分かります。人間が監視ループの中にいるので、異常は自然に検知されます。

無人実行では、この検知がまるごと消えます。cron や launchd から起動されたジョブに画面はなく、結果だけが後から残ります。そしてやっかいなことに、無人実行で起きる不具合の多くは「終了コード0で、何も起きずに終わる」形を取ります。

失敗として記録されないので、監視も通知も反応しません。気づくのは「そういえば、あのジョブの成果物を最近見ていない」と人間がふと思い出したときです。私の運用でも、暗黙の既定に依存していた経路が期限切れで静かに止まり、長期間それに気づけなかったことがありました。エラーが出ていれば1日で直っていたはずのものです。

2.1.274 に入った3つは、いずれもこの型に当てはまります。順に見ていきます。

型①　明示した設定が、自動更新のたびに落ちていた

変更履歴に書かれていること

公式の変更履歴（CHANGELOG）の 2.1.274 に、次の1行があります。

Fixed claude agents losing --model, --effort, --permission-mode, --allow-dangerously-skip-permissions and --agent after an auto-update relaunch

日本語にすると、claude agents（コマンドから下請けのAIを走らせる経路）が、自動更新による再起動のあとに、指定していたモデル・思考量・権限モード・エージェントの指定を失っていたのを修正した、という意味です。

ここで重要なのは、これが「指定を書き忘れた人」の話ではないことです。正しく書いた人が、書いたとおりに動いていなかったという話です。

なぜ、これが無人運用に刺さるのか

私の運用では、cron や launchd から呼ぶすべての非対話実行に、使うモデルを明示することを絶対ルールにしています。マシンの既定に任せると、どのモデルで走ったのかが誰にも分からなくなるからです。この規律そのものについては別記事で詳しく書きました。

Claude CodeAIを無人で回すコスト規律｜claude -pの--model明示

ところが今回の修正が示しているのは、その規律が、道具の側の再起動で無効化され得たという構図です。起動コマンドには確かに指定が書いてある。ジョブ定義を読めば意図は明らかです。それでも、自動更新が挟まった回だけは、その指定が引き継がれていなかった可能性があります。

つまり「明示した」は「効いた」ではない。ここが本記事でいちばん持ち帰ってほしい一文です。

さらに悪いことに、この失敗はエラーになりません。指定が落ちても、既定の設定でそのまま走ります。ジョブは完走し、成果物も出ます。違うのは「どのモデルで・どの権限で走ったか」だけです。コスト側なら請求が静かに膨らみ、品質側なら成果物の質が静かに落ちます。

確かめ方

• ジョブ定義ではなく、実行記録の側を見る。起動コマンドに何と書いたかは証拠になりません。実際に使われたモデル・権限が実行ログに残っているかを確認します
• 自動更新が走った時刻と、ジョブの実行時刻を突き合わせる。更新直後に走った回だけ挙動が違っていないかを見ます
• 残っていなければ、残す工程を足す。無人ジョブの実行記録に「そのジョブが何のモデルで走ったか」が出ていない状態では、この種の取り違えは永久に検知できません

読者特典・無料ダウンロードClaude Codeを「素のまま」使うな無料でダウンロード →↓

型②　1ターン目が、つながらない外部ツールを待って止まる

待ち時間を秒で決める設定が追加された

同じ 2.1.274 に、次の追加があります。

Added CLAUDE_CODE_MCP_STARTUP_WAIT_MS to bound how long the first non-interactive turn waits for connecting MCP servers (0 = don't wait)

MCP（AIと外部の道具をつなぐ口）のサーバーが接続中のとき、非対話セッションの1ターン目がそれをどれだけ待つかの上限を、ミリ秒で指定できるようになりました。0 を指定すれば待ちません。

裏を返せば、この設定が追加されるまで、その待ち時間は利用者側から制御できなかったということです。無人ジョブが「何も出力しないまま長時間経過している」とき、原因が処理の重さではなく、つながらない外部ツールの接続待ちだった、という可能性があります。

同じ版に入った「待ち」関連の修正

この版には、外部ツール接続まわりの修正が他にも入っています。変更履歴から関連するものを挙げます。

• 約5分で切れていた: サーバーごとに長いタイムアウト（timeout）を設定していても、呼び出しが約5分で打ち切られていたのが修正されました。設定したのに効いていなかったという点で、型①とまったく同じ構図です
• 権限不足が「サインイン切れ」と誤って報告されていた: 403（権限不足）で拒否された呼び出しが、期限切れのサインインとして報告されていました。修正後は不足している権限名が出るようになっています。誤った原因が表示されると、人は誤った側を直し続けます
• 「変更あり」の宣言が無いと一覧が更新されなかった: サーバーが変更通知を送っても、その宣言（listChanged）が無いと、プロンプトやリソースの一覧が更新されていませんでした
• 1ターン目の固定待ちが解消: --input-format stream-json のセッションで、1ターン目が接続中のサーバーを最大2秒待つのをやめました
• 空の設定でも待っていた: --strict-mcp-config に空の設定を渡した場合に、無関係なサーバーの分だけ1ターン目が待たされていたのが修正されました

5件のうち4件が「待つ必要のないものを待っていた」「設定した時間が効いていなかった」という内容です。外部ツールを何本つないでいるかが、無人ジョブの起動時間に直結していたということでもあります。

確かめ方

• つないでいる外部ツールの本数を数える。無人ジョブが実際に使っているのは、そのうち何本でしょうか。使っていないものが繋がっているだけで、毎回の起動が遅くなります
• 使っていないものを外す。これが最も効きます。設定で待ち時間を詰めるのは、外せないものが残ったときの次善策です
• それでも遅いなら、待ち上限を明示する。外部ツールを1ターン目で使わないジョブなら、待たない指定にできます
• 「サインインが切れた」と出ていた記録を洗い直す。それが実は権限不足だった可能性があります。再認証を繰り返しても直らなかった経験があるなら、ここを疑う価値があります

型③　「30分で止まった」の本当の原因はメモリだった

止まる理由がログに出るようになった

3つ目です。変更履歴に2件あります。

Added a visible warning when memory usage is critical, with steps to free memory or restart safely

Fixed background commands being stopped after 30 idle minutes on machines under mild memory pressure; they're now stopped only when memory is critically low, and the debug log says why

後者が本題です。バックグラウンドで走らせたコマンドが「30分アイドルで停止」させられていた本当の理由が、軽度のメモリ逼迫だった——これが修正され、本当に限界のときだけ停止し、停止した理由がデバッグログに出るようになりました。前者は、メモリ使用量が危険域に達したときに、逃がし方と安全な再起動の手順つきで警告が出るという追加です。

なぜこれが「静かな停止」の典型なのか

この件のたちの悪さは、提示されていた理由が間違っていた点にあります。「30分アイドルで停止」と言われれば、人は時間切れだと解釈します。そして「時間のかかる処理だから仕方ない」「分割しよう」と、時間の側を直そうとします。

ところが実際の原因はメモリでした。時間の側をいくら直しても再発します。原因の誤診を配ってしまうと、利用者は正しい手順で間違った場所を直し続けることになります。

常時起動のマシンに無人ジョブを同居させている環境では、これは他人事ではありません。1台の上で複数のジョブが重なった瞬間だけメモリが逼迫し、そのとき走っていたバックグラウンド処理が落ちる——という形で、再現しない不具合として現れるからです。再現しないので、調べても原因に辿り着けません。

確かめ方

• 止まった時刻と、メモリの記録を突き合わせる。「30分で止まった」と記録されている作業があるなら、その時刻に何本のジョブが同時に走っていたかを見ます
• 「時間切れだと思って諦めた作業」を洗い出す。原因が別なら、諦める必要はなかったかもしれません
• 版を上げて、止まる理由が出る状態にする。理由が出れば、次からは推測せずに済みます
• 同時に走らせる本数を減らす。実行時刻をずらすだけで解消する場合があります

3つに共通するのは「動いていたか」ではなく「指定が効いたか」

ここまでの3つを並べると、同じ形が見えてきます。

3つとも、画面にエラーが出ないまま損が積み上がる型です。そして3つとも、提示されている情報を信じると、違う場所を直してしまうという性質を持っています。

だから無人運用の点検では、確認する問いを変える必要があります。「動いていたか」ではなく「指定が効いていたか」です。前者はジョブの成否を見れば分かりますが、後者は実行記録に残していない限り、あとから確かめる方法がありません。

これは無人ジョブの設計全般に言えることで、落ちても流し直せる形にしておくのと同じくらい、「何が効いた状態で走ったか」を記録に残しておくことが効きます。

Claude CodeAIの長時間タスクは"落ちても流し直せる"設計にする

静かな停止のもう一つの形——止まらずに、同じ失敗を繰り返す

ここまでの3つは「進まなくなる」型でした。無人運用にはもう一つ、逆向きの型があります。止まらないまま、同じ失敗を延々と繰り返す型です。同じ 2.1.274 に、これにあたる修正が2件入っています。

終わらないリトライ

1件目は、セッションが特定のエラー（unexpected tool_use_id の400エラー）で無限にリトライし続けて止まらなくなっていたものです。修正後は、壊れた記録を可能な範囲で自動修復し、それができない場合は明確なエラーで打ち切る形になりました。

2件目は、自前で用意した実行環境（self-hosted runner）のセッションが、トークンの更新に数回失敗したあと次の定期更新まで毎ターン401で失敗し続けていたものです。修正後は401を受けた時点で新しいトークンを取りに行くようになりました。

この2つがなぜ「静かな停止」の仲間かというと、無人ジョブから見れば、無限リトライは停止と区別がつかないからです。人が見ていれば「同じエラーが延々と流れている」と一目で分かりますが、見ていない時間に起きた場合、残るのは「終わらなかった」という結果だけです。しかも時間と費用は消費され続けます。

見えないところで無駄に呼ばれていた分

もう2件、無人・SDK経路の効率に関する修正があります。

• バックグラウンド処理の完了ごとに、別々のモデル呼び出しが走っていたのが、まとめて1回に統合されました。並列で多数の処理を走らせる無人ジョブほど、この差は積み上がります
• claude -p --resume で再開したとき、前のプロセスが終えられなかったバックグラウンド作業が報告されていなかったのが修正されました。再開したのに、やり残しの存在自体が伝わっていなかったということです

いずれも画面には何も出ません。前者は請求書の側に、後者は「やったつもりで終わっていない作業」の側に現れます。無人運用の損失は、ほとんどがこの形で発生します。

今日できる4手

ここまでを、そのまま作業に落とします。所要は30分程度です。

1. 無人で走らせているコマンドを一覧にする

cron・launchd・タスクスケジューラから呼んでいる非対話実行を、すべて書き出します。そのうえで、各行にどのモデル・どの権限を指定しているかを並べます。ここで「指定していない行」が見つかったら、それは型①以前の問題です。

2. 実行記録の側で、指定が効いたかを確認する

ジョブ定義ではなく、実行ログを見ます。使われたモデルや権限が残っていない場合は、残す工程を足すところから始めます。入口の指定が「防御」なら、実行記録は「点検」です。両方そろって初めて、無人で回した結果を信用できます。

3. 外部ツールの接続本数を数えて、使っていないものを外す

起動が遅いジョブほど効きます。外せないものが残るなら、1ターン目の待ち上限を明示します。

4. 「止まった」記録の原因を、時刻で突き合わせる

止まった時刻・同時に走っていた本数・そのときのメモリを並べます。時間切れだと思っていたものが、別の原因だったかもしれません。

版の選び方——stable と latest は同じものではない

ここで注意が要ります。この記事で扱った修正は、安定版を選んでいる人にはまだ届いていません。

npm レジストリの配布タグを2026年9月18日午前6時台（日本時間）に確認したところ、次の状態でした。

stable は 2.1.267 のまま8日間据え置きで、latest との差は7版ぶんあります。つまり安定版を選んでいる環境では、本記事の3つの修正はまだ適用されていません。

無人ジョブに使う版をどう選ぶかは、ひとつの判断です。安定版を選ぶのは事故を避けるための合理的な方針ですが、「安定版を選んでいる」ことは「今日の不具合が直っている」ことを意味しません。どちらを選ぶにせよ、いま自分の環境で動いている版の番号を把握しておくことが前提になります。

なお、無人実行そのものの上限設定（暴走を防ぐ側の設計）については、別記事にまとめています。

Claude CodeClaude Code無人運用｜暴走を防ぐ上限設定まとめ

この版には公式の告知が無く、設定は変更履歴にしか書かれていない

最後に、情報の取り方そのものについて2点、確認できた事実を書いておきます。

1つ目。npm に出ている最新版が、変更履歴の最上段より先に進んでいます。 上の表のとおり next は 2.1.275 ですが、2026年9月18日午前6時台に取得した変更履歴の最上段は 2.1.274 でした。配布物が先に出て、変更履歴が後から追いつく順序になっています。

2つ目。今回追加された CLAUDE_CODE_MCP_STARTUP_WAIT_MS は、公式ドキュメントの設定リファレンスに記載がありませんでした。 同ページには45個の CLAUDE_CODE_ 系環境変数が列挙されていますが、この設定名は同日時点で検索しても出てきません（サンドボックスと使用状況モニタリングの各ページでも0件でした）。つまりこの設定は、現時点では変更履歴を読んだ人にしか存在が分からない状態です。

この2つから言えることは、ひとつです。道具は告知なしに毎日変わっており、告知を待つ運用は成立しません。 更新のたびに通知が来るのを待つのではなく、変更履歴と配布タグを自分で見に行く日を決めるほうが、結果的に早く正確です。週に1回、10分で足ります。

特に無人で回している人にとっては、これは単なる情報収集ではありません。ここまで見てきたとおり、自分のジョブが静かに止まっていた理由が、変更履歴の1行にしか書かれていないことがあるからです。

よくある質問

この3つの不具合は、自分の環境でも起きていたと考えるべきですか

断定はできません。変更履歴は「修正した」とだけ書いており、影響範囲や発生条件までは記載されていないためです。確かめる方法は本文の「今日できる4手」で示した突き合わせになります。起きていた前提で点検し、証拠が無ければそれでよい、という順序をおすすめします。

対話でしか使っていない場合も関係しますか

型①と型②は非対話（無人）実行に関する記述なので、対話利用への影響は限定的です。型③のメモリによる停止は、バックグラウンドで走らせるコマンドに関わるため、対話利用でも該当し得ます。

すぐに最新版へ上げるべきですか

無人ジョブを日常的に回しているなら、上げる価値のある版だと考えています。ただし本記事は自社の運用方針を述べたもので、環境によって判断は変わります。上げる前に走っていた分は「指定が効いていなかった可能性がある」前提でログを確認する——この一手だけは、版を上げる・上げないにかかわらず有効です。

変更履歴はどこで読めますか

公式リポジトリの CHANGELOG.md が一次情報です。本記事の引用はすべてそこと npm レジストリの配布タグ情報から取りました。各項目の原文は英語なので、気になる行だけを訳して読む形で十分です。

まとめ

無人で回しているAIの失敗は、エラーではなく静かな停止として来ます。2.1.274 に入った3つは、いずれもその型でした。

• 型①：明示したモデル・権限の指定が、自動更新の再起動で落ちていた。「明示した」は「効いた」ではない
• 型②：1ターン目が、つながらない外部ツールを待って止まっていた。待ち上限を指定できるようになった
• 型③：「30分アイドルで停止」の本当の原因はメモリ逼迫だった。止まる理由がログに出るようになった

3つに共通するのは、提示されている情報を信じると違う場所を直してしまうという点です。だから点検の問いを「動いていたか」から「指定が効いていたか」へ切り替える必要があります。

そして道具の側は、告知なしに毎日変わります。私たちは、変更履歴と配布タグを定点で見る日を運用に組み込むことを推奨しています。無人化とは、人が見ない時間を作ることではなく、人が見ていない時間に何が起きたかを、あとから確かめられる状態を作ることだと考えています。

無人ジョブの設計や点検の仕組みづくりを外部と一緒に進めたい場合は、Claude Code導入支援・環境構築のサービスでも扱っています。

※本記事の記載は2026年9月18日時点で確認した公式の変更履歴およびnpmレジストリの情報に基づきます。版の状況は日々変わるため、導入前に最新の一次情報をご確認ください。