2026 年 6 月 12 日 (金) 午後 5 時 21 分 (米国東部時間)、Anthropic は米国商務省から 1 通の書簡を受け取りました。その日の業務終了までに、公開からわずか 3 日だった Fable 5 および Mythos 5 モデルは利用停止となりました。一部のユーザーだけが使えなくなったわけではありません。特定の地域だけが対象になったわけでもありませんでした。すべての顧客、すべてのワークフロー、すべての本番環境デプロイメントが、事前通知なしに利用不能になったのです。

これは、半年間の移行期間が設けられたモデル廃止ではありませんでした。移行ガイド付きの終了通知でもありません。ジェイルブレイクの疑いがあるとして政府が輸出規制措置を発動した結果、世界有数の AI プロバイダーである Anthropic には法令に従う以外の選択肢はありませんでした。

もし皆様の AI 戦略が単一のプロバイダーと単一のモデル エンドポイントに依存しているのであれば、この出来事は、将来発生し得るインシデントの現実的なシナリオを示した出来事だったと言えるでしょう。

これはサプライ チェーンの問題です

AI 業界はソフトウェア業界から多くを学びました。バージョン管理、CI/CD、マイクロサービスなどがその例です。しかし、十分に取り入れられていない重要な考え方があります。それがサプライ チェーン管理です。

従来のソフトウェア開発では、SBOM (Software Bill of Materials：ソフトウェア部品表) によって、システムを構成するライブラリ、バージョン、ライセンス、既知の脆弱性情報 (CVE) を正確に把握できます。組織は依存関係を監査し、ポリシーを適用し、問題が発生したコンポーネントを迅速に交換できます。

しかし AI 分野には、まだこのような管理が標準的には存在していません。

多くの組織は次のような基本的な情報に答えられません。

• 現在本番環境で利用しているモデルのバージョン
• 使用されているファインチューニング データ
• 組み込まれているアダプターや安全性分類器
• モデルの来歴 (プロビナンス)

Fable と Mythos が突然利用停止になった際、多くの企業はこうした問いにリアルタイムで答えようと奔走することになりました。しかも適切なツールを持たない状態でです。

AI Bill of Materials (AIBOM) は単なるコンプライアンス対応のためのチェック項目ではありません。

現在利用しているモデルが突然利用できなくなった場合に、何を代替すべきかを把握するための前提条件なのです。

AIBOM (AI Bill of Materials) は、モデル名だけでなく、ベース モデル、ファインチューニング レイヤー、ガードレール コンポーネント、推論基盤、アクセス依存関係までを包括的に管理します。これにより、問題発生時や政府命令によるサービス停止時にも、何を置き換える必要があるのか、どこに影響が及ぶのかを即座に把握できます。

セルフホスト型 AI コントロール プレーンが必要な理由

今回の Fable/Mythos の出来事は、AI アプリケーションを単一プロバイダーの可用性から切り離す必要性をこれ以上ないほど明確に示しました。Prediction Guard の AI コントロール プレーンは、AI エージェントとモデル/ツール層の間に配置され、自社環境内で稼働します。これにより、単一ベンダーに依存することなく、ポリシーの適用、エージェントのアクセス制御、モデルのトラフィック制御、アクセス管理、エージェントの監視、プロバイダー障害時のフェイルオーバーを実現できます。

AIBOM によるサプライ チェーンの可視化

AI スタックの各レイヤーに何が含まれているのかを正確に把握できます。モデルが利用停止になったときも、影響範囲や互換性のある代替手段をインシデント発生前から把握できます。CycloneDX を使用して AIBOM エクスポート機能を開発した理由に関する詳細は、こちらの記事 (英文) をご覧ください。

アクセス継続性とフェイルオーバー

単一プロバイダー向けの API キーは、単一障害点 (SPOF) になり得ます。ベンダーに依存しない AI コントロール プレーンを導入すれば、1 社のモデルに対する政府規制がそのまま自社サービスの停止に直結することはありません。

モデル ポータビリティを前提とした設計

プロンプト、ガードレール、評価ロジックは、特定の AI ベンダーに依存すべきではありません。コンポーザブルな AI アーキテクチャを採用することで、Fable から別モデルへ、あるいはセルフホスト型のモデルへ移行する際も、大規模な作り直しを行わずに対応できます。また、ポリシーの適用、悪意ある入力への対策、個人情報 (PII) のフィルタリング、出力の監視、各種コンプライアンスの制御といったコンプライアンス機能もコントロール プレーン側に集約できます。監査も更新も一元的に実施できます。

モデル ポータビリティは必要不可欠となっています

これまでベンダー ロックインは、将来的に解消すべき戦略上の課題として扱われていました。しかしこの出来事をきっかけに、Fable や Mythos に依存していた企業にとって運用上の緊急事態となりました。

こうした状況から迅速に復旧できた組織には、次のような共通点がありました。

• 既にモデル抽象化レイヤーを導入していた
• オープンウェイト モデルを検証していた
• 複数のバックエンドでプロンプトを継続的にテストしていた

モデル ポータビリティとは、モデルを固定的な依存先ではなく、容易に差し替え可能な構成要素として扱う考え方です。これにより、安全性ロジックをアプリケーションとともに移行できるだけでなく、API モデルからセルフホスト型のモデルへの切り替えを設定変更で実現したり、金曜日の午後 5 時 21 分に政府命令が発動されても「危機」ではなく「インシデント」として対応したりできるようになります。

さらに今回の出来事は、「最も高性能な最先端モデルほど規制当局の注目を集めやすい」という、今後数年にわたりエンタープライズ AI を左右する重要な現実も示しました。

Mythos はサイバーセキュリティ脆弱性の発見能力が極めて高かったため、Anthropic は当初一般公開を見送っていました。つまり、高い能力こそがその価値の源泉である一方で、規制リスクの要因にもなり得るのです。

今すぐ取り組むべきこと

まずは AI 資産の棚卸しから始めましょう。本番環境で運用しているすべての AI システム、AI エージェント、AI アプリケーションについて AIBOM を整備しましょう。次に、どのような依存関係が存在するのか、単一モデルが消失した場合に影響を受ける業務は何かを明確にしてください。この作業だけでも、多くの組織が認識していなかったリスクが見つかるはずです。

その上で、モデルを柔軟に差し替え、アクセス ポリシーを集中管理し、フェイルオーバーを自動化できる、コントロール プレーン中心のアーキテクチャを構築することが重要です。重要なのは、次の停止を予測することではありません。次の停止が発生しても、自社サービスの可用性に影響を与えない仕組みを作ることです。

Fable と Mythos の事例が最後になることはありません。規制強化は続き、ジェイルブレイクは今後も発生し、地政学的リスクは予測できません。これをベンダーとの関係問題としてではなく、サプライ チェーン エンジニアリングの問題として捉える組織こそが、将来も安定して AI サービスを提供し続けられるでしょう。

Prediction Guard の AI コントロール プレーンは、AIBOM による可視化、マルチプロバイダーのフェイルオーバー、ガバナンスの組み込み、モデル ポータビリティを実現し、まさにこうした課題に対応するために設計されています。

AI ガバナンスやマルチモデル戦略をご検討中の方へ

今回の事例が示したように、単一の AI モデルや単一プロバイダーへの依存は、技術的な課題だけでなく、規制やサプライ チェーンの観点からも大きなリスクとなり得ます。

エクセルソフトでは、現在利用中の生成 AI サービスや LLM のリスク、PII や機密情報への対応方針、AI ガバナンス要件などの整理から、セルフホスト型 AI 基盤の検討や Prediction Guard の評価および導入支援にわたり、日本語で支援します。

「現在の AI 環境が単一ベンダーへ過度に依存していないか確認したい」 「AI ガバナンスや監査対応に不安がある」 「マルチモデル戦略やセルフホスト環境を検討したい」という方はお気軽にお問い合わせください。

---

この記事は、Prediction Guard 社の Web サイトで公開されている「When the Government Pulls the Plug on Your AI Stack」の日本語参考訳です。原文は更新される可能性があります。原文と翻訳文の内容が異なる場合は原文を優先してください。

---