1日500コミットを続けたら、Macが熱で落ちるようになりました

1日500コミットという超並列環境でMacが熱で強制終了するようになった経験記である。環境は30体のエージェントを同時実行、各worktreeで単体テストとlintを回すという構成。その結果load averageが100を超え、20コアのCPUでもリソース不足になった。だがここからが興味深い。さらに負荷を下げようと調査を進めると、犯人は自分が動かしているエージェントやテストではなく、OS側のSpotlightとTime Machineだったのだ。worktreeは作るたびに6万ファイルが一気に生まれ、Spotlightが律儀にそれらを索引しに行き、worktree破棄時に6万ファイルが消えて、再度索引を更新する。数時間で消えるファイルを永遠に索引し続ける、という無駄の塊。

AIの鬼がここに見るのは、「高速化・並列化のボトルネックは、層によって全く別の形で現れる」という普遍的な真実だ。技術者は往々にして見えている層（CPU使用率、メモリ、API呼び出し数）だけに目を向け、その下の層（OS設定、ネットワーク制限、ディスク I/O、契約条件）を見落とす。記事で特に秀逸なのは、「テストがタイムアウトすると変更のせいに見える。実は負荷のせいなのに、コードを疑って書き直す。しばらくして負荷が下がったら何もしていないのに通る」という虚しい経験の描写である。これは多くの開発者が経験しているはずの現象だが、ほとんど言語化されていない。本人にとっては「自分のコードが悪い」という認識のまま、実は環境のせいだったという、気付きようのない失敗。作者は最後、CLAUDE.md に「load averageを見てから新しい作業を足す」というルールを入れた。判断ではなく、手順に落とし込むことが重要だと明記している。

中小企業でも同じ轍を踏む。業務自動化やマルチエージェント化を進める際、「CPU使用率が高い」「レスポンス時間が長い」という表面的な指標だけで判断してはいけない。その下の層に本当のボトルネックがある。API上限かもしれないし、OS設定かもしれない。契約数が足りないのかもしれない。実装の前に、システム全体の層構造を把握し、各層の制約を列挙する習慣が必須である。