処理役の本数の上限を外したら、メモリの門は空き49%と出て一度も閉じなかった

Claude Codeの処理役 (作業を受け持つセッション) の同時3本の上限を外し、メモリの空きが20%未満の時だけ新しい処理役を止める門に任せたが、門は閉じなかった。計測では、swapが8,004MB / 9,216MBまで埋まっていても門の物差しの空きは49%と出た。その後、本数はCPUの負荷と週の枠でも削られ、門の条件を作り直して本数の上限を戻した。作り直した後の効果は、決定の記録の検証期日がまだ来ていない。

門が閉じず本数も出なかった

上限を外す前から、本数は詰まりの元だった。3本は10月21日に1本から並べた時の値で、測った根拠の記録は無い。その後、PRを見回るpr-sweepと、Linearの依頼を拾って処理役を開くlinear-pickupが同じ3本を分け合うようになり、Linearの依頼が待ち行列の5番目で数時間待った。記録には、撤廃の理由として「制限のせいでここ何日かの作業がものすごく遅くなった」という私の指示が残っている。

上限を外した後の影響は、門が閉じないことで出た。A2 (社内の開発機の名前) は物理16GBで、swap 7.87GB・圧縮6.01GB・プレッシャー黄・CPUのアイドル0% の時も門は閉じない見込みだった (確信度70%)。門が閉じた時に出るSlackの通知は、導入から1通も無かった。A2が逼迫したら端末B (32GBのMacBook Air) へ依頼を回す仕組みも、門が閉じないので一度も動かなかった。

二つ目の影響はCPUだった。依頼をまとめて回した日にA2のloadは60〜96 / 10コアに達し、3本の処理役が60分応答せず、全件のテストは1時間以上終わらなかった。それでもBには回らなかった。

三つ目は週の枠だ。夕方に一つ目のアカウントの週の枠が赤 (消費86% / 予定38.5%) になり、Bの上限は6から3に、A2も3本に下がった。指示役のAIの見立てでは、夜の大半で上限が2〜3本に下がり、これが夜の本数を最も長く削った (確信度80)。

物差しが一つで理由も見えなかった

一つ目の原因は物差しの選び方だ。門が見ていたmemory_pressureの空きの値は、圧縮とswapを空きに数える。swapが埋まるほど逼迫していても、値は閉じる線の20%より高く出た。

二つ目は、門がメモリしか見ていなかったことだ。CPUの詰まりの原因は、各処理役が手元で全件のテストを流したことだと記録にある (事実90)。メモリより先にCPUが尽きた。

三つ目は本数の数え方だ。処理役の数はClaude Codeのclaude agents --jsonのstatusがbusyの物だけで数えていた。裏でCIなどを待つ処理役は数えから漏れた。60分応答しない処理役を回収する仕組みはプロセスを止めず、あるissueでは回収の後に依頼が戻り、同じissueに2本目が開き得た。A2とBのClaude Code 2.1.319では、対話のセッションにstateの欄が無く、19件を読んでstateを持つ物は0件だった。

四つ目は週の枠の判定だ。本数を下げる判定は「今のアカウントの消費 / 経過の予定」で、3アカウントの残りを見ていなかった。

五つ目は、閉じた理由が外から見えなかったことだ (確信度90)。指示役のAIは原因をメモリと言い続けたが、ある朝のA2の閉じは本数の上限によるものだったと処理役の実測で分かった。LinearのIn Progressの数を処理中の本数と取り違え、実際は3本だったこともあった。

条件を足し本数の上限を戻した

メモリの門は、四つの条件のORに直した。空きの値、プレッシャーの段階が2以上、swapが4096 MB超、Bでは使える残りが残す量12288 MBと新しい処理役の見込み2048 MBの和を下回る時に閉じる。閾値は環境変数で変えられ、端末ごとの初期値はscriptの先頭の一か所にある。A2の本番では、空き35%でも段階2で閉じ、続けてswapが4470 MBの時に閉じた。Bは使える残りが8358 MBの時に閉じた。swap・圧縮・段階・空きは5分ごとに記録する形にした。

CPUは二つの手で受けた。依頼ごとにA2とBの負荷の低い方で処理役を開く形にし、6本の試しで両方に振り分けた。loadがコア数を超えたら新しい処理役を開かない門も足した。

本数の上限は戻した。処理中10本ではload 60〜96で60分応答なしが3本、処理中7本ではload5 4.17 / 10で安定した。これを根拠にA2 6本・B 4本を上限にし、翌日にBを6本 (私が手元で使う間は4本) に上げた。その後、11月8日に上限をA2・Bとも8本に上げ、Bの残す量は4096 MBに下げた (確認日の値)。数え方は、busyに加えて、裏の作業を待つ物も足す形に変えた。同じissueに生きたセッションがあれば新しく開かず、回収する時はプロセスも止める。

週の枠は、私が3アカウントの合計で判定する案を選んだ。閉じた理由は、Slackに固定の1通を置き、受けられる本数・動いている本数・待ち件数・絞りの理由を5分ごとに書き換える案を選んだ。48GBの新しいMacは今は買わず、測ってから決めることにした。記録には、48GBにしてもコア数が大きく増えなければ同じ詰まり方をする (推測70) とある。

次は自動で止まるのか

メモリとswapの門は、本番のログで閉じたことを確かめた。閉じる側の試験は、閾値を100にしたdry-runで閉じる判定を出す形で、門の試験は9件が通った。負荷での振り分けは6本の試しで確かめたが、Bを眠らせた時に全部A2に回るかの実機の確認は残っている。

本数の上限と数え方は、決定の記録の予測を待っている。60分応答しない処理役が0件になる確率は65%と70%の見立てで、どちらも検証期日はまだ来ていない。本数そのものの確信度は70%で、本数を増やすと完了件数が減るというのも推測70%で、本数ごとに測った数字ではない。

効かなかった場面は週の枠の直しだ。3アカウントの合計で判定する直しが入った後も、朝の見回りではまだ効いておらず、Bの処理役は60分応答なしで止められていた。その後A2はCPUの負荷 (5分平均10.2 / 閾値8.0) で閉じた。門は閉じたが、本数は出なかった。指示役のAIの見立ては、絞りの本当の原因は本数ではなく、処理役が同時に走らせる重い処理と、常駐する検査のソフトだった (確信度70)。claude本体は200〜300 MB・CPU 1〜10% だった。

私が注目したのは、上限を外す時も戻す時も、本数の値が測った数字から決まっていない点だ。3本には根拠の記録が無く、6本も確信度70%の見立てだ。

読者が先に入れておく物

処理役を並べて動かす前に、次の物を先に入れておくと、同じ詰まり方を避けやすい。

• 門の物差しを一つにせず、メモリの空き、プレッシャーの段階、swap、load ÷ コア数をORで見る。閾値は環境変数で変えられるようにする。
• 閾値を極端にしたdry-runで、閉じる判定が出ることを試験する。
• 閉じた理由と待ち件数を、外から読める通知に出す。
• 裏でCIやsubagentを待つ処理役も「動いている」と数え、回収する時はプロセスも止める。
• 使用量の枠は、使える枠の合計で判定する。
• 本数の上限を置くなら、決めた計測を記録に残す。

筆者の見方

次は、作り直した門と本数の上限で、応答しない処理役が無くなるかを計測で確かめ、まだ詰まるなら新しいMacを買うかを決める。重い処理を手元で流さない手と合わせて見る。この仕組みを自社で2週間で作りたい時は、スプリント0で相談を受けている。

この記事の作り方：社内の開発の記録 (issueと決定の記録) を材料に、処理役が下書きし、別のAIがレビューした。

数字は全て記録から写し、記録の無い数字は書いていない。