「Fable禁止」で仕事が止まったあの日々を振り返る　日本企業が取るべき「脱・単一モデル」戦略

　2026年6月9日、米AnthropicはAIモデル「Claude Fable 5」（以下、Fable 5）を一般公開した。一般公開は危険なレベルだと自ら公言していた「Claude Mythos 5」（以下、Mythos 5）に安全施策を施した高性能モデルだ。ところが、そのわずか3日後に、米国政府が輸出管理指令を発令し、Mythos 5とFable 5を外国籍ユーザーに提供することを禁止。Anthropicはユーザーの識別が困難だとして全ユーザーへの提供を停止した。そして、米国政府と調整後、約18日後に提供を再開した。

　もし、あなたが日本企業で全社または統括部門のAI導入を決裁する立場であれば、この一連のドタバタ劇を、単なる米国企業のサービス停止騒動と考えるべきではない。これは「AI時代の新しい地政学的リスク」であり、対策を検討すべき事象だ。今や、AIモデルの性能は国際競争力に影響し、単一モデルに依存することは業務の継続性を脅かすリスクになる。

　本稿では、この新しいリスクにどう備えればよいのか、日本企業が今から検討すべき「止まらない生成AI基盤」の具体策を整理する。

新たな地政学リスク「Fable停止で私の業務は止まった」

　米政府はAnthropicに対し、「米国内外を問わず、外国籍の全ての者」のFable 5へのアクセスを停止するよう命じた。Anthropicは同日中にサービスを停止している。

　筆者自身も、この停止の影響を直接受けた一人だ。筆者は業務のかなりの部分をAIエージェント化し、少人数での納品数最大化を進めてきた。今では、3体のAIエージェントが常に稼働し、私の代わりに設計から納品まで担っている。

　しかし、Fable 5が事前の通知なく遮断され、私のAIエージェントチームのワークフローは即座に沈黙した。

　AIエージェントによる業務の自律化には、高度な設計が不可欠であり、これは「高性能なAIモデルと私が対話する」ことで初めて実現する。私はFable 5と対話して、設計書を作成し、以降の作業は「Claude Sonnet」シリーズなどの比較的安価で生成が速いモデルに任せていた。

　重要なのは設計だ。設計さえ良ければ、後続の作業が数日にわたる長期間作業であっても、私がたまに進捗を確認するだけで、エージェントたちはほぼ自律的に完成まで進めてくれた。逆に設計がダメなら、後続の作業にも私が伴走しなければならなくなる。だから、設計時には高性能モデルが欲しい。

　Fable 5が遮断された日、私は性能が一段劣る「Claude Opus」シリーズと設計するしかなかった。後続の作業エージェントたちは品質の劣る設計書に基づいて作業し、それによって、いつもより多くのエラーが報告され、私が対応しなければならないレビューと修正指示は増加した。

　明らかに私の生産性は落ちた。おそらく、他の日本企業でも同様だっただろう。私たちの競争優位性は米国政府にコントロールされている。ゆえに、これは「地政学リスク」なのだ。

「モデルの乗り換え」は簡単ではない

　「他のモデルで代用すればよいのでは。オープンウェイトモデルもある」と思うかもしれない。私も同意見だ。しかし、それほど単純ではなかった。

　私は、個別業務ごとの要件に対応するため、モデルの挙動を最適化していた。その結果、モデルを差し替えると、精度が落ちるどころか、動作そのものが怪しくなった。

　例えば、「Claude Haiku」（Claudeの下位モデル）で動かしていたエージェントを、米Googleのオープンウェイトモデル「Gemma 4」に差し替えようとしたところ、ツール呼び出しの挙動が異なり、タイムアウトが頻発してまったく動かなかった。どうやら、PCのスペックから見直す必要もありそうだった。「オープンウェイトモデルならトークン費用はタダ」と楽観したのもつかの間、結局、オープンウェイトモデルを前提としたエージェント構成をゼロから再構築する羽目になった。

日本企業が取りうる対策

　リスク対策の原則は分散だ。Anthropicや米OpenAI、Googleだけでなく、米国以外のモデルやオープンウェイトモデルも検討する必要がある。

　以降では日本企業が取りうる、リスクの分散アプローチを2つ紹介する。

アプローチA：インフラとモデルを自社で管理（オンプレミス化）

　一つは、GPUサーバーを自社で運用し、オープンウェイトモデルを動かす方法だ。膨らみ続けるAPI利用コストの抑制にもつながり、どの国のモデルにも依存しない土台を自社の手の内に置ける点が強みになる。

　私の個人的な意見ではあるが、執筆時点（26年7月）では設計後の作業であればオープンウェイトモデルでも十分な性能を発揮できる。

　ただし、GPUサーバーの調達と運用が前提になる。さらに、「vLLM」や「Ollama」などの推論基盤を、自社が動かすモデルに合わせてチューニングする必要もある。加えて、商用に管理されたモデルよりもセキュリティ性能が低いことが一部で懸念されている。これらを担う専門のエンジニアが必要だろう。

アプローチB：モデルを分散させた統合基盤の活用

　自社開発のコストは避けたいが、リスクは分散したい。そんな企業に向いているのが、マルチモデル統合基盤の活用だ。

　例えば、Sakana AIの「Fugu」はタスクに応じて複数モデルのチームを編成・協調させる「オーケストレーションモデル」だ。単体のフロンティアモデルと同等以上の性能をうたう。特定モデルを選択肢から除外でき、あるプロバイダーが利用を制限しても動的に迂回して稼働を続けることも可能だという。

　同様のサービスは他にも登場している。モデルの差し替えに伴う開発に割く余力がないなら、こうした基盤に任せるという判断も現実的だ。

　一方で、統合基盤の運営が日本企業でも、ルーティング先の最上位モデルが米国製なら、米国発の規制の影響は完全には消えない。「代替モデルで動き続ける」と言っても、同等性能の維持は未知数だ。

そろそろ、AI時代の新しいリスクに備えよう

　Fable 5の一件で、高性能なAIモデルが輸出管理の対象になり得ることが示された。今後の国際情勢次第で、突然の提供停止は再び起こり得る。そのモデルに自社の業務が依存していると、外国政府の意向で業務がストップするリスクをはらむ。

　読者の皆さんが所属する企業でも、「特定モデルに依存する」のではなく「モデルを分散できる基盤」へ、投資の軸足を移すタイミングが来ているのではないだろうか。オープンウェイトモデルの性能は向上し続けており、複数のモデルを切り替えられる統合基盤も登場した。

　最初の一歩は、自社で稼働しているエージェントの把握だ。致命的なタスクを担っているエージェントがあれば、それが最初の対策候補になる。一度、主力モデルを止めて代替モデルで業務を回す「切り替え演習」を試してみてほしい。さらに踏み込むなら、モデル切り替えの影響度を測る評価テストを常備し、切り替え演習の合否を判定することも考えられる。

　本稿があなたの会社のAIリスク対策を検討するきっかけになれば幸いだ。

エンタープライズAI　導入実務の勘所（ITmedia AI＋）

企業のデータ活用やAI導入支援を手掛けるインキュデータの執筆陣が、AI導入時の勘所や注意点を解説します。

この連載の記事をもっと見る

この記事の著者

関連記事

• 

  なぜ「純国産AIは無理」なのか？　さくらとSakana AIが示す「ソブリンAI」の現実解

• 

  なぜPFNは「国産AI」をゼロから開発するのか　担当者に聞く“自家製ならではの利点”

• 

  Anthropic、「Mythos 5」「Fable 5」の提供を一時停止　米政府指示を受け