AI 部下に任せた Blender が 9.8 GB に膨らんで、AI 上司ごと OOM で死んだ日

8月25日の朝、Linuxマシンの上で「AI上司」と呼ぶ自律型エージェントが突然消えた。その数時間後に気づいたという、衝撃的な実体験ポストが話題を集めている。きっかけはBlenderの異常膨張だ。3D部品の接合ずれを直すため部下のAIに任せたBlenderが9.8GBまでメモリを食い潰し、LinuxのカーネルがカーネルのOOM killerを発動。ここまでなら個別の事故だが、問題はAI上司とBlenderが同じ「箱」の中に居たことだ。systemdの用語で言うcgroupという限界枠組みを共有していたため、部下の暴走が上司を巻き添えにした。

技術的には初歩的な設計漏れだが、AIシステムを自動化で運用するようになった層にとって、これは対岸の火事ではない。「重い仕事は部下に投げるから上司は軽いままだ」という素朴な仮定が、投げた先が上司自身の懐の中だった可能性を示している。つまり、マイクロサービスの思想でAIエージェントを配置しても、リソース分離を明示的にしなければ、一つの故障が全体を止める古いシステムと変わらないということだ。

著者の対処は興味深い。まず死んでも勝手に戻るwatchdog機構を作ったが、これは最初失敗した。本命は、systemdのsliceで「守る側」と「譲る側」にリソースを3層に分割する設計だ。上司のセッションを4GB保証し、下の作業を6GBの固い天井と5GBの警告ラインで押さえた。効果は実測値で確認済み──ただしコストが1.37倍増えた。性能と安全のトレードオフを数字で示した点が本記事の価値だ。中小企業がAI運用の自動化に踏み込む時、こういう「見えない設計上の雷管」が何本潜んでいるか、まだ誰も数えていない。