公開3日でAIが消えた｜脱・単一モデル戦略

監修者伊東雄歩

株式会社ウォーカー CEO。東北大学卒。MENSA会員、JDLA認定講師、健全AI教育協会理事。生成AI×教育・学習科学を専門とし、2億円超のシステム開発プロジェクトを統括。

2026年6月、公開からわずか3日で最上位AI「Claude Fable 5」が世界中で使えなくなった経緯
原因は障害でもメンテナンスでもなく、米政府の輸出管理指令だったこと
復旧までおよそ18日間。現場では設計工程が止まり、後続のエラーが増えた
脱・単一モデルの2つの道（オープンウェイトの自社運用／複数モデルを束ねる基盤）
切り替えで実際につまずくポイントと、今日から始められる4ステップ

いま使っているAIが、明日いきなり使えなくなったら。想像したことはありませんか。2026年6月、それは実際に起きました。公開3日目の最上位モデルが、障害でもメンテでもない理由で世界中から消えたのです。この記事では、その18日間で何が止まり、日本企業が次に何を備えるべきかを整理します。

公開3日で消えた「Claude Fable 5」——18日間の空白

6月9日に公開、6月12日に全面停止

2026年6月9日、AnthropicはフラッグシップのAI「Claude Fable 5」を一般公開しました。

ところが、その3日後に状況が一変します。

6月12日、米国政府が輸出管理指令を発令。外国籍のユーザーへの提供を停止するよう命じる内容でした。

Anthropicは指令に従い、Fable 5と上位の「Mythos 5」を全顧客に対して即座に無効化します。

サーバー障害でも計画メンテでもありません。規制という、技術では回避しようのない理由で最上位モデルが消えたのです。

米商務省が規制を解除したのは6月30日。提供が再開されたのは7月1日でした。空白はおよそ18日間に及びます。

現場で止まったのは「考える工程」だった

ITmedia AI＋に寄稿したインキュデータの担当者は、当時の様子をこう振り返っています。

常時3体のAIエージェント（自分で判断して作業を進めるAI）を走らせていた業務が、途中で中断したというのです。

痛かったのは、単に作業が遅れたことではありません。

高性能モデルでなければ回せない「設計」の工程が止まったことです。

設計が雑になると、その後ろのすべての工程にエラーが波及します。実際、後続工程の失敗が増え、生産性が落ちたと報告されています。

AIはもう1本の便利な道具ではなく、業務の背骨になっていた。抜けた瞬間に、それがはっきり見えたわけです。

「1つのAIに全部任せる」がなぜ危ないのか

今回は輸出管理でしたが、AIが使えなくなる理由はそれだけではありません。

止まる理由は、思っているより多い

規制・輸出管理：今回のケース。自社の技術力では避けられない
大規模障害：提供元のクラウドが落ちれば、AI機能が一斉に沈む
料金改定：単価が上がっても、乗り換え先がなければ受け入れるしかない
モデルの引退：旧モデルが廃止され、挙動の違う後継へ強制的に移される
社内ポリシーの変更：情報の取り扱い方針が変わり、特定サービスが使えなくなる

どれも珍しい話ではありません。「いつか起きること」として設計しているかどうかだけの差です。

身近な3つの「止まった日」

もう少し具体的に考えてみましょう。

ある中小企業の経理担当者は、月末に数百件の請求書をAIに読み取らせています。締め日の朝にAPIが止まれば、その日の作業はまるごと手作業に戻ります。数百件を人の目で確認する残業が、その場で確定します。

コールセンターでは、問い合わせの一次回答をAIが下書きしています。使うモデルが変わると文体まで変わり、口調のばらつきをオペレーターが直す手間が上乗せされます。

開発チームでは、コードレビューをAIエージェントが担っています。上位モデルが止まると、レビューの粗さに気づかないまま本番リリースが進んでしまいます。

いずれも「便利だから任せた」結果、AIが抜けた穴がそのまま業務の穴になっています。

脱・単一モデル、2つのアプローチ

元記事は、依存から抜ける道を大きく2つ挙げています。

A：オープンウェイトを自社で動かす

1つ目は、GPUサーバーを自社で用意し、重みが公開されたモデル（オープンウェイト）を自前で動かす方法です。

代表格が、Googleが2026年4月2日に公開した「Gemma 4」です。Gemmaシリーズで初めてApache 2.0ライセンスを採用し、商用利用も無料になりました。

上位の26B・31Bクラスは256Kトークンの文脈を扱え、ツール呼び出し（AIが外部のアプリやAPIを操作する機能）にも対応します。

量子化版（モデルを軽く圧縮したもの）なら、RTX 4090で毎秒45トークン前後。手元のワークステーションでも実用的な速度が出ます。

誰かの都合で止められない。これが自社運用の最大の価値です。

その代わり、GPUの初期投資と運用担当者は自前で抱えることになります。

B：複数モデルを束ねる基盤を使う

2つ目は、複数のモデルをチームとして編成し、協調させる方法です。

元記事が挙げているのが、Sakana AIが2026年6月22日に正式提供を始めた「Sakana Fugu」です。

中心にいるのは約70億パラメータの「Conductor（指揮者）」。質問を受け取ると、まず自分で答えられるかを判断します。難しければエージェントプールから適切な専門AIを選び、その場でチームを編成します。

技術的な裏付けは、ICLR 2026に採択された2本の論文「TRINITY」と「Conductor」です。

つまり1つのAPIを叩くだけで、裏側では複数のモデルが分担して答えを作る仕組みになっています。

同じ発想はクラウド側でも進んでいます。Google CloudはAPI Gatewayにモデルルーティング機能をパブリックプレビューで追加しました。

OpenAI互換のリクエストを受け取り、Gemini・Claude・OSS-GPTへ動的に振り分けます。アプリ側にモデル名を焼き付けずに済むのがポイントです。

料金は月200万回まで無料、超過分は100万回あたり3.00ドル。推論そのものの費用は別途かかります。

差し替えれば動く、とは限らない

ここが最大の落とし穴です。

元記事の担当者も、オープンウェイトのGemma 4へ移したときにツール呼び出しの挙動が違い、タイムアウトが多発したと書いています。

モデルが違えば、指示の受け取り方も、道具の使い方も変わります。

「APIのURLを書き換えれば終わり」ではありません。プロンプトも、リトライの設計も、タイムアウトの秒数も作り直しになることがあります。

備えは、止まってからでは作れません。動いているうちに一度試したかどうかで、その日の結果が変わります。

主要な選択肢を比較する

脱・単一モデルの手段は、いくつかの層に分かれています。整理しておきましょう。

Sakana Fugu：指揮者AIが複数モデルを自動で使い分ける国産サービス。1つのAPIで完結する手軽さが魅力
Google Cloud API Gateway：サーバーレスの振り分け層。OpenAI互換で受けてGemini・Claude・OSS-GPTへ流す。現時点ではテキストのみ、同一ホストのバックエンドのみという制限あり
LiteLLM：100種類以上のAPIを1つの形式に統一するオープンソースのプロキシ。自社で運用し、統制も自社で握る前提
OpenRouter：多数のモデルへの入口と請求をまとめてくれるマネージド型。とにかくすぐ試せる
Amazon Bedrock：複数ベンダーのモデルを1つのクラウド契約で使える。LiteLLMと組み合わせる構成例をAWS自身が公開している
Gemma 4などの自社運用：外部の都合に一切左右されない代わりに、GPUと人手を自社で抱える

違いはざっくり、「賢く振り分けてほしい」「事故なく差し替えたい」「そもそも外に出したくない」の3つに分かれます。

多くの企業にとって現実的なのは、まず2番目です。いつでも差し替えられる形にしておくことが出発点になります。