📖 幽霊モデルという見えない故障 ― Nemotron死亡事象とorp.pyの3層防御

ある朝、3つのLLMに同時にレビューを頼んだうち1つだけが沈黙した。エラーではない。プロンプトを投げると、404を返す。けれど OpenRouter の公式モデル一覧では「生存中」と表示されている。まるで幽霊のような存在 — 名前はあるのに、応答がない。

その正体は無視できる小さなバグではなかった。multi-llm-review という3機並列レビューの仕組みは「3機とも生きてる」ことを前提にしており、1機でも死ねば「3機中2機」と「2機中1機」の区別がつかなくなる。Nemotron の死亡を検知できないまま運用すれば、レビュー結果の品質が静かに下がっていく。

最初に考えたのは「手で blacklist に入れる」こと。1行の修正で済む。だがそれでは「次の幽霊モデル」が現れた時、同じ手作業が再発する。

そこで取った手段が3層防御だった。(1.5) 死亡スモーク — 公式一覧で生存中でも、簡易プロンプトに応答しなければ blacklist へ。(1.6) blacklist 反映 — refresh 時に除外対象を機械的に省く。(2.5) 新規探索 — 公式の :free モデル一覧から未登録を最大5件 smoke 経由で昇格。検知・反映・補充の3つを orp.py 一箇所に押し込めた。

nemotron-3.5-lightning と dots-studio はこうして自動昇格した。「見えない故障」に対する「見える仕組み」への置き換え — 手動運用で隠れていた曖昧さが、3層防御のコードとして目に映るようになった。

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

• 検知層 (1.5): verified=True でも smoke テストで text.strip() が空・404 なら blacklist へ自動昇格。判定は orp.py:cmd_refresh 内
• 反映層 (1.6): refresh 時に blacklist_models を参照し、候補から機械的除外。手動反映の手間ゼロ
• 補充層 (2.5): /api/v1/models の :free 抽出 → 未登録を smoke 経由で最大5件昇格。「死んだ」のと同じ速度で「新しい」が補充される

設計の核: 同じ失敗パターンを再発させない汎用化は 2026-08-28 の durable cron 排他化でも採用した運用鉄則。「1回直す」のではなく「仕組みで二度と起こさない」へ。

正典: 01_DECISIONS/claude-code/2026-09-03_orp.py機能拡張-blacklist反映・死亡スモーク・新規探索実装.md </details>