Coworkで並列タスクが落ちる理由。Claude Codeとの仕様差をログで実測

📖 この記事で分かること – Coworkのタスクが落ちる原因はセッション退去の仕組み – 退去の選定基準は「待機時間」だという実測結果 – デスクトップのCoworkはローカルの仮想マシンで動く – 低スペック機ほど先に落ちる理由と5つの回避策

💡 知っておきたい用語 – セッション:Claudeに1つの仕事を任せている「作業窓口」1本ぶん。窓口を増やすほど、席(メモリ)を取り合う – 退去(eviction):席が足りなくなったとき、待っているだけの窓口を先に閉めて空きを作る仕組み

最終更新日: 2026年7月30日

▶ 公式ページ – Claude Coworkの使い方(公式ヘルプ)(Claude Help Center) – エージェントの並列実行(公式ドキュメント)(Claude Code Docs)

「複数タスクが途中で落ちる」という相談

この記事のポイント

• Claudeのデスクトップアプリには同時セッション数の上限があり、超えると待機中のタスクが強制終了される(筆者環境で上限8、2026年7月時点)。
• デスクトップのCoworkタスクはAnthropicのサーバーではなく、自分のMac上のLinux仮想マシン(4コア・メモリ4GB、2026年7月時点)で動いていた。
• 退去の引き金はメモリ不足なので、メモリ16GBのノート機は同時2〜3本でも発症する。

業務でClaudeを使っている方から、こういう相談を受けました。「Coworkで複数の処理を同時に走らせると、途中で落ちたりエラーになったりする」。

同時実行が原因という見立ては合っていました。ただ、筆者がアプリのログを実測したところ、原因は使用量の上限(レート制限)でも通信の不調でもなく、アプリに内蔵された「セッション退去」の仕組みでした。しかもこれはバグではなく、設計された保護機構です。以下、実測で分かったことを順に説明します。

なぜこの話題か

筆者がこの話題を取り上げるのは、原因の説明が公式ドキュメントに載っていないためです。公開されている情報だけを読むと、CoworkとClaude Codeの違いを高い確率で誤解します。実際、相談を受けた時点で筆者自身も誤解していました。

もう1つの理由は、この故障がメモリ不足を引き金に起きるため、マシンのスペックが低いほど早く発症する点です。「同じ2〜3本しか動かしていないのに、自分の環境だけ落ちる」という現象に説明がつきます。原因が分からないまま使い方を制限してしまうのは、もったいない状況です。

ログを実測して分かった3つのこと

以下は筆者の環境(Apple SiliconのMac、メモリ24GB、デスクトップアプリ)で2026年7月30日に確認した内容です。検証は1台のみなので、数値の普遍性は確認できていません。

上限に達すると、待機中のタスクが追い出される

アプリのログ(~/Library/Logs/Claude/main.log)の警告・エラーを分類すると、最多の項目が[CliGovernor]で3,837件ありました。2位の189件を桁で上回っています。実際のログはこうなっています。

[CliGovernor] at cap=8; would evict local_xxx (idle 40s) for warm spawn
[CliGovernor] at cap; yielding warm spawn
[CliGovernor] at cap=8; would evict local_xxx (idle 100s) for user spawn
[CliGovernor] memory pressure (warning): would evict 0 idle session(s), 2 effective

ここから読み取れることが4点あります。

第1に、同時に動かせるローカルセッションに明示的な上限があることです。cap=8とあり、筆者環境では8でした。サーバー側の混雑ではなく、アプリ内で持っている値です。

第2に、上限に達したときの挙動が2種類あることです。evictは既存セッションの強制終了、yieldは新規起動の見送りを意味します。つまり新しいタスクを始めると、既存のタスクが犠牲になるケースがあります。

第3に、退去の選定基準が待機時間であることです。ログにはidle 40sからidle 100sへと数字が伸びていく記録が残っていました。長く黙っているセッションが先に選ばれます。さらにfor user spawn(利用者が手で始めた起動)はfor warm spawn(アプリの先読み起動)より優先されます。

第4に、メモリ不足でも待機セッションが退去対象になることです。would evict 0 idle session(s)は「追い出したいが、待機中のものが0件だったので今回は誰も終了させなかった」という意味です。逆に言えば、待機状態のセッションがあれば終了させます。

利用者から見ると「順調に動いていたタスクが急に止まった」という体験になります。再現条件がタスクの種類ではなく本数 × 待機時間 × 空きメモリの組み合わせで決まるため、原因の切り分けが難しくなっています。

デスクトップのCoworkは、自分のMacの中のLinuxで動いている

公式ヘルプには「Claude’s work runs on Anthropic’s servers, in an isolated environment(Claudeの作業はAnthropicのサーバー上の隔離された環境で動く)」と書かれています。シェルコマンドやコードもその環境内で実行される、という記述もあります。

ところが、デスクトップアプリのログには別の実行環境が記録されていました。

- CPUs: 4
- Memory: 4GB
Ubuntu 22.04.5 LTS

AppleのVirtualization機能を使い、macOSの上にLinuxの仮想マシンを1台立てています。ゲストOSはUbuntu 22.04.5 LTS(2026年7月時点)で、割り当ては4コア・メモリ4GB。設定で変更する項目は見つかりませんでした。

仮想マシンの中では常駐プロセスがセッションを管理しており、セッションごとに別のLinuxユーザーとして隔離されます。筆者の環境では13ユーザー分の履歴が蓄積していました。通信は中継プロキシ経由、ホスト側のファイルは共有マウント経由で参照します。アプリを終了すると仮想マシンも停止します。

整理すると、実行される場所は3種類あります。

公式ヘルプが説明しているのは3番目だけです。1番目と2番目は文書化されていないため、公開情報だけを読むと「クラウドで動くから自分のPCは軽いはず」という理解になります。ここが誤解の入り口です。

レート制限の証跡はなかった

最初に疑ったのは使用量の上限でした。しかし429(レート制限)や529(過負荷)、rate_limit_error、overloaded_errorといった文字列を厳密に検索した結果、ヒットは0件でした。

ここで1つ、ログ調査でやりがちな失敗を共有します。筆者は粗い検索で「429が200件、529が102件」という結果を得て、一度レート制限が原因だと考えました。実際にはsys_free_raw=429MBのようなメモリ量の数値に部分一致していただけで、完全な偽陽性でした。数字だけを検索すると、桁の一致で無関係な行を拾います。

ただしCoworkが通常のチャットより使用量を消費しやすいのは事実です。1つのタスクが内部で補助の作業者を立て、ツール呼び出しとファイル操作を大量に発生させます。条件が違えばレート制限が主因になる可能性は残ります。筆者環境では証跡がなかった、という範囲の話です。

なお、クラウドセッションを中継する通信部分のエラーも調べました。こちらは全件がネットワーク切り替えとスリープ復帰に由来するもので、再接続の仕組みも動いていました。タスクの本数とは無関係でした。

Cowork と Claude Code、仕様はどこが違うのか

実測を踏まえて比較すると、両者の差は「誰が並列を決めるか」ではなく「落ちたときに誰が犠牲になるか」に表れます。

補助作業者の並列数は見落としやすい点です。同時実行数は「コア数から2を引いた値」で決まりますが、Coworkの仮想マシンは4コアなので実効値は2です。ホストが8コアだからと6本と見積もると、3倍の過大評価になります。

そして、低スペック機で問題が起きる理由がここに集約されます。筆者の環境はメモリ24GBですが、生の空きメモリは常時65〜100MB、スワップは2GB中1.2GBが使われていました。この上に仮想マシンが4GBを要求します。

現在Appleが販売するMacBookはメモリ16GBが最小構成です(2026年7月時点)。24GBの環境ですでに余裕がない状態なら、16GBの構成では削れる余地がさらに小さくなります。退去の引き金がメモリ不足である以上、同時本数が少なくても先に発症するという結論になります。

筆者はこう見ている

評価軸を3つ挙げます。

判断軸1: 「クラウドだから自分のPCは軽い」は成り立たない。 デスクトップアプリのCoworkでは、自分のマシンの空きメモリが、同時に走らせられる本数の上限を実質的に決めています。筆者はこの点を最も重要な訂正だと考えます。根拠は、退去の警告3,837件がすべてメモリ圧迫を契機に出ていたことです。

判断軸2: 自動並列化の利便性と、制御を手放すことは表裏。 Coworkは「適切なら並列で調整する」と公式に説明されており、実際にその通り動きます。一方で、いつどのセッションが退去されるかを利用者が指定する手段はありません。便利さの代償として、タスクの生死を自分で握れない構造になっています。

判断軸3: 重い常設処理はClaude Code側に置く。 筆者はこの判断を推します。理由は、各処理が独立したプロセスとして走るため、1つが落ちても他に波及しないことです。並列を自分で設計する手間は増えますが、確実に完走させたい定期処理では、その手間に見合います。逆に、手元の資料整理や単発の調査であれば、Coworkの自動分割のほうが速く終わります。

まだ分からないこと。 上限値8がプラン依存なのか、マシン性能依存なのか、共通の固定値なのかは特定できませんでした。設定項目も見つかりませんでした。仮想マシンの4コア・4GBが固定かどうかも同様です。組織のポリシーで仮想マシンの利用を必須化できそうな設定キーの存在は確認しましたが、動作は未確認です。検証は1台のみで、数値の普遍性は保証できません。

読者への提案

具体的に取れる行動を挙げます。

1. 同時に走らせる本数を、上限より2本ほど手前で止める。 筆者環境では上限8に対し、実際に効いていたセッション数は最大7でした。上限直前では既存タスクが犠牲になります。メモリ16GBの環境では、まず3本を上限の目安にして様子を見るのが安全です。

2. 長時間タスクを「黙らせない」設計にする。 退去の選定基準が待機時間である以上、定期的に進捗を出力する処理は生き残りやすくなります。逆に、長いスリープや長い通信待ちで完全に沈黙する設計が最も危険です。処理を分割し、途中経過を出すだけで生存率が変わります。

3. 仮想マシンを使う他アプリと同時に動かさない。 Dockerのようなコンテナ環境を併用していると、Coworkの仮想マシンが要求する4GBと正面から競合します。重い並列処理をする前に、そちらを止めておく判断が効きます。

4. 落ちたときは推測せず、ログを見る。 次のコマンドで、退去が起きていたかどうかを自分の環境で確認できます。

# 同時セッションの上限と退去の記録
grep "\[CliGovernor\]" ~/Library/Logs/Claude/main.log | grep -i cap

# メモリ不足による退去警告の件数
grep -c "memory pressure" ~/Library/Logs/Claude/main.log

# ローカル仮想マシンの割り当て
grep -E "CPUs:|Memory:" ~/Library/Logs/Claude/cowork_vm_swift.log

タスクが止まった時刻の前後にevictやyieldの記録があれば、原因はほぼ確定します。文書化されていない挙動に運用が依存している状況では、利用者側が観測手段を持つことが唯一の対策になります。

よくある質問

Q: 上限に達したかどうかは、アプリの画面で分かりますか?

A: 筆者が確認した範囲では、画面上に明示的な表示はありませんでした。ログのat capという記録で判断する必要があります。上のgrepコマンドで確認できます。

Q: メモリを増設すれば解決しますか?

A: 退去の引き金の1つがメモリ不足なので、余裕が増えれば発症頻度は下がると考えられます。ただし同時セッション数の上限そのものはメモリとは別の値なので、上限に達したときの退去は残ります。またAppleのMacは購入後にメモリを増設できません。

Q: Claude Codeなら絶対に落ちませんか?

A: 落ちにくい、が正確です。各処理が独立したプロセスなので1つの失敗が他に波及しませんが、同じMac上で動かす限りCPUとメモリは共有します。台数を分ければ完全に分離できます。

まとめ

Coworkで並列タスクが落ちる原因は、アプリ内蔵のセッション退去の仕組みでした。同時セッションに上限があり、上限到達時とメモリ不足時に、待機時間の長いセッションから終了されます。バグではなく保護機構であるため、再現条件が本数・待機時間・空きメモリの組み合わせで決まり、原因が見えにくくなっています。

もう1つの発見は、デスクトップアプリのCoworkタスクがAnthropicのサーバーではなく、自分のMac上のLinux仮想マシンで動いていた点です。公式ヘルプはクラウド経路のみを説明しているため、公開情報だけでは誤解が生じます。筆者はこの2点が、CoworkとClaude Codeを使い分ける際の実質的な判断材料だと考えます。

【用語解説】

• 仮想マシン: 1台のパソコンの中に、ソフトウェアでもう1台別のコンピューターを作る技術。ここではmacOSの中にLinuxが1台立っている状態を指す
• サブエージェント: 1つの仕事を分担するために内部で作られる補助の作業者。同時に動かせる数は、割り当てられたコア数で決まる
• スワップ: メモリが足りなくなったとき、あふれた分を一時的にストレージへ退避させる仕組み。使われ始めると動作が遅くなる

引用元:

• [1] Get started with Claude Cowork(Claude Help Center)
• [2] Run agents in parallel(Claude Code Docs)
• [3] MacBook Air (13-inch, M4, 2025) – Tech Specs(Apple Support)

この記事について: AI 支援で執筆、編集部が事実確認・編集しています。誤りや追加情報があれば Contact よりお知らせください。