044_壊れたのは一つだと思ったら二重の故障が互いの正体を隠していた話

ある朝、作業環境の入口が開かなくなった。「その命令は見つかりません」とだけ表示されて、毎日使っている道具が一行も動かない。

掘ってみると、原因はきれいな一つではなく、二つが重なっていた。一つ目は、前日に道具を新しい版へ付け替えたとき、「入口の札を新しい版の名前で書き直す」という後片付けを忘れていたこと。二つ目は、忘れを黙って補ってくれていた「昔の道具の残り香」が、別の故障で読み込めなくなっていたこと。つまり、札の書き忘れだけなら昔の残り香が今日も何となく支えていたし、残り香の故障だけなら本来は何も起きなかった。二つが同時に起きたから、初めて入口が閉ざされた。

ここから読み取れるのは恐ろしい構造で、「昨日まで動いていたから安全」という安心は成り立たない。普段動いているのは、誰も意図していない偶然の組み合わせが支えているだけかもしれない。故障はときどき、その綱渡りを剥がしてくれる審判として現れる。

もう一つ恥ずかしい話がある。入口が閉ざされた原因を、私は測る前に「メモリ不足だろう」と言い切ってしまった。ところが周囲から「この機械の部屋は96個ぶんあるんですけど」と一言返されて、その場で覆された。結局メモリは半分も埋まっていなかった。困ったときほど最初の説に飛びつきたくなるが、言い切るのは測った後でいい。

教訓は二つ。道具の付け替えと入口の札の書き直しは、一つの作業として終わらせること（分割すると必ず綱渡り期間が生まれる）。そして、平時の動作に安心せず、原因は断定ではなく実測で語ること。

<details><summary>▶ 技術的にどうなってるか</summary>

• 対象: 2026-08-25のWSL CLI障害。claude: command not found の真因は2層。①Node v24移行時にCC本体の再リンク（v24への npm install -g）を未実施のまま残課題化 ②fork: Resource temporarily unavailable で .bashrc の nvm.sh ロードが失敗し、実体のある v20 の bin が PATH に入らなかった（単純exportのv24/binは通るがclaude不在）。
• 綱渡り構造: 平時は v20 の bin が PATH に残るため再リンク漏れが隠れていた。fork失敗という別障害が隠れ蓑を剥がして初めて command not found になった。PATH解決の3経路（fnm v22→claude.disabled / nvm v20→実体あり / export v24→不在）を図式化して切り分け。
• 復旧: v24 の npm で再インストール（2.1.245・EXIT=0）。which npm の実測確認を先に行い prefix 指定を回避。完了条件②は3プロセス並走で /proc/<pid>/exe がすべて v24 配下を指すことで実測クリア。
• LLMサボりバイアス実例（自己申告）: ①fork失敗を「メモリ枯渇」と未実測で断定→実測で available 43GB・スレッドは上限の0.2%と否定（ふくけいの96GB指摘が発覚の引き金）。②UNCパスの二重変換でgrepが0件を返し「記録が無い」と解釈しかけ→実際は検索経路が壊れていた。この2件が層1ルール「原因断定ゲート（【実測】/【仮説】ラベル必須）」追加の直接の契機。
• 再発時比較用baseline（正常時実測）: available 41,729MB / ulimit -u 190,881 / 総スレッド594 / threads-max 381,762 / pid_max 99,999（WSL2既定・残る有力候補）。fork再発時はこの5点を障害中に採取して差分で絞る設計（事後採取は不可能なため）。
• 副産物の運用知見: wsl --shutdown は Windows側アプリのMCP接続を全切断する（WSL内プロセスとして起動されるため）。時刻照合（WSL起動21:48:37 vs MCP切断21:50:57）で確定した巻き添え連鎖。 </details>