動画で読む
まず結論 — モデルは「落ちる」だけでなく「消える」前提で設計する
結論を先に置きます。2026 年 6 月 12 日、Anthropic は米政府の輸出管理指令を受けて、Claude Fable 5 と Mythos 5 へのアクセスを全顧客向けに突然停止しました。ここから運用者が持ち帰るべき教訓は一つで、モデルは「一時的に落ちる」だけでなく「外的要因で消える」ことがある、という前提を設計に織り込むことです。
落ちるなら待てばいい。けれど消えると、待っても戻ってきません。今回のように国家安全保障を理由にした指令で特定モデルが商用提供から外れると、それは数分のリトライで吸収できる障害ではなくなります。可用性の設計図に「地政学で消える」という欄は、これまで多くの人が持っていなかったはずです。私も持っていませんでした。
6 月 12 日に何が起きたか — 米政府の輸出管理指令と突然の disable
事実関係を先に押さえます。Anthropic が公開した声明によれば、米政府は国家安全保障上の権限を根拠に、Fable 5 と Mythos 5 へのアクセスを「あらゆる外国籍（foreign national）」に対して停止するよう求める輸出管理指令を出しました。米国内外を問わず、外国籍の Anthropic 従業員まで含むとされています。
結果として Anthropic は、コンプライアンス確保のために両モデルを全顧客向けに即座に無効化しました。指令が届いたのは現地時間 6 月 12 日の 17
（ET）、それ以外の Anthropic モデルは影響を受けないと明記されています。CNBC や NBC News も同日に報じています。政府側の懸念は Fable 5 の「ジェイルブレイク（安全対策の回避）」手法にあると Anthropic は理解しており、同社は実演を確認したうえで、既知の軽微な脆弱性にとどまると反論しています。ここで運用者にとって重要なのは、ジェイルブレイクの是非そのものより、「自分のコードのバグでも、プロバイダの障害でもない理由で、使っているモデルが消える」という事象が現実に起きたという一点です。安全対策の議論は、以前 Anthropic の脆弱性発見ハーネスを扱ったこの記事で触れた攻防の延長線上にありますが、今回はその攻防が「商用提供の停止」という運用インパクトに直結しました。
「落ちる」と「消える」は別物 — リトライでは戻ってこない
対策を考える前に、障害の種類を分けておきます。一般的な API 障害は一時的（transient）で、指数バックオフ付きのリトライやサーキットブレーカーで吸収できる前提のもの。今回のような「モデルの引き上げ」は、いつ戻るか分からない、あるいは戻らないかもしれない別カテゴリの事象です。
この区別が大事なのは、打ち手が変わるからです。一時障害ならリトライとタイムアウトで足ります。恒久的に消える可能性に備えるなら、必要なのは「別のモデルへ切り替えられる構造」と「切り替えられないときに機能を落として動かし続ける構造」です。前者がフェイルオーバーとモデル抽象化、後者が縮退運転（一部機能を諦めてサービスを継続すること）。リトライ回数をいくら増やしても、消えたモデルは戻りません。
日本で個人開発をしている私の立場は、今回の指令だと「米国外の外国籍」にそのまま当てはまります。つまり、もし依存していたのが Fable 5 単体だったら、私のサービスは私に一切の落ち度がないまま止まっていた。この当事者感が、抽象的だった「ベンダーロックイン」を急に生々しくしました。
三つの守り — フェイルオーバー・モデル抽象化・縮退運転
守りは三層で考えると整理できます。フェイルオーバー（代替モデルへの自動切替）、モデル抽象化（呼び出し側がモデル ID を直接持たない設計）、縮退運転（代替もないときに機能を落として継続）。上から順に「同等品で代える」「代えやすくしておく」「代えられないなら諦めて生かす」と難易度と諦めの度合いが上がります。
- フェイルオーバー: 主モデルが 4xx/5xx や提供停止を返したら、あらかじめ決めた順序で副モデルへ落とす。同一プロバイダ内の別モデル（今回なら Fable/Mythos 以外）と、別プロバイダの両方を候補に持つのが理想です。
- モデル抽象化: 呼び出しコードに
claude-fable-5のような文字列を直書きしない。モデル ID は設定（環境変数や設定ファイル）に追い出し、ルーティング層で解決する。OpenRouter のようなルーティング層に値段が付くのは、まさにこの「差し替え可能性」を肩代わりしてくれるからです。 - 縮退運転: 代替が一つも使えないとき、AI 機能だけを一時的にオフにして、サービスの本体は動かし続ける。以前書いたLLM API のコストを「呼ばない」で防ぐ三段防御と発想は同じで、「呼ばずに済ませる道」を平時から用意しておくほど、消えた日の被害が小さくなります。
私ならこう備える — model id を設定に追い出す
私がまず直すのは、モデル ID のハードコードです。一番安く、一番効きます。claude-opus-4-8 のような文字列を散らかしておくと、差し替えが必要になった日に grep して 1 箇所ずつ直す羽目になります。
白状すると、私のブログ自動投稿パイプライン（AI が下書きを書き、私が公開前に確認して出す仕組み）では、初期にモデル ID を複数のスクリプトへ直書きしていました。あるモデルが deprecate されたとき、12 ファイルを手で書き換えて、しかも 1 箇所直し忘れて夜中にジョブが落ちました。そのとき初めて「モデル ID は設定値であって、コードに埋める定数ではない」と腹落ちしました。今は呼び出し口を 1 つにまとめ、主・副・縮退の三段を環境変数で切り替えられるようにしてあります。
抽象化の効用は、平時には見えません。動いているうちは「ただの設定ファイル」にしか見えない。けれど Fable 5 が消えた今日のような日に、設定を 1 行書き換えるだけで副モデルへ寄せられるかどうかが、その日の自分の睡眠時間を決めます。仕組みは、動かない日にだけ価値を見せます。
全部は守れない — どこで線を引くか
最後に正直な限界を書きます。フェイルオーバーは万能ではありません。特定モデルでしか出ない品質や、ファインチューニング済みの固有挙動に依存していると、副モデルは「動くが同じではない」状態にしかなりません。今回の指令のように外国籍を名指しで切るケースでは、組織によってはそもそも代替の前に利用資格を失います。
だからこそ、どこまでを仕組みで守り、どこから諦めるかの線引きを先に決めておくのが現実的です。これは始める前に「やめ方」を決めるで書いた撤退基準の話と地続きで、全機能をマルチプロバイダ対応にしようとすると、今度は運用そのものが重くて続きません。コア機能だけは縮退運転で生かし、付加機能はモデルが消えたら一時停止でよい、と優先順位を紙に書いておく。その紙が、外的要因で足元をすくわれた日の判断を肩代わりしてくれます。
よくある質問
- Fable 5 と Mythos 5 はなぜ停止されたのですか？
- 米政府が国家安全保障上の権限を根拠に、両モデルへのアクセスをあらゆる外国籍に対して停止するよう求める輸出管理指令を出したためです。Anthropic はコンプライアンスのため全顧客向けに即座に無効化しました。他の Anthropic モデルは影響を受けません。
- 一時的な API 障害と今回の「停止」は何が違いますか？
- 一時障害はリトライやタイムアウトで吸収できますが、今回はモデル自体が商用提供から外れる事象で、いつ戻るか分かりません。リトライ回数を増やしても消えたモデルは戻らないため、別モデルへ切り替える構造や機能を落として継続する構造が必要です。
- 単一モデルプロバイダ依存に最も安く効く対策は何ですか？
- モデル ID のハードコードをやめ、設定（環境変数や設定ファイル）に追い出すことです。呼び出し口を 1 つにまとめておくと、いざ差し替えが必要になった日に設定を 1 行変えるだけで副モデルへ寄せられます。
- フェイルオーバーを用意すればどんな停止にも耐えられますか？
- いいえ。特定モデルでしか出ない品質やファインチューニング済みの挙動に依存していると、副モデルは「動くが同じではない」状態になります。外国籍を名指しで切る指令では利用資格自体を失う場合もあるため、どこで諦めるかの線引きを先に決めておく必要があります。