Fable・Mythos公開停止問題が明らかにしたクラウドLLMの短所とローカルLLMの長所
この記事でわかること
- 米国政府によるFable 5・Mythos 5の公開停止(その後制限付きでアクセス再開)はモデルへのアクセス（API）が外部要因で遮断されることで業務が止まりうる、という構造的リスクを露わにした
- 単一モデルプロバイダーに依存すると、可用性とデータガバナンスの2面で、自社がコントロールできない要因に左右される
- 解決策は、ローカルLLM（オープンモデル）運用でモデルプロバイダー依存リスクを引き受け、業務が止まらない状態を作ること
- 選択肢は3つ：(1) DGX Spark等でオンプレ運用、(2) 既存オンプレ/プライベートクラウドへの組み込み、(3) クラウドGPU上での自社運用
- 対策の進め方は、業務影響の棚卸し→機能分解→評価基盤→フェイルオーバー実装→運用化、の順に整備すること
Fable 5・Mythos 5の公開停止
6月12日、Anthropicから衝撃的なリリースが行われました。6月9日にリリースした2つの最新LLMモデル (Fable 5・Mythos 5) を一般の全ユーザーに対して公開停止とするというブログ記事です。
その後、Anthropic社と米国政府との協議を経て、6月30日（現地時間）にアクセス自体は再開されたものの、以前と全く同じ条件で使えるわけではありません。特にサブスクリプションプラン（Pro、Max、Teamなど）においては利用上限が大幅に制限され、最終的にはプラン内での利用が廃止されて「usage credits（従量課金）」のみでの提供へと移行することが発表されています[2]。
図1 : Fable 5・Mythos 5の公開停止を表明したブログ記事。Statement on the US government directive to suspend access to Fable 5 and Mythos 5 - Anthropic Announcements [1]
この問題はなぜ起こり、生成AI活用にどのような影響を与えるのでしょうか？本記事では、以下の3つについて解説します。
- Fable 公開停止とは？
- クラウドLLMに依存するリスクについて
- クラウドLLMへの依存を減らすには？
Fable 5・Mythos 5の公開停止が露わにしたリスクとは
何が起きたのか
6月12日、Anthropicから衝撃的なリリースが行われました。6月9日にリリースした2つの最新LLMモデル (Fable 5・Mythos 5) を一般の全ユーザーに対して公開停止とするというブログ記事です。
Fable 5・Mythos 5は、「自律的な行動によるサイバー攻撃・脆弱性発見性能が高すぎるため危険」とされたモデル Mythos Preview の安全性能を高め、一般公開されたモデルです。Anthropic社は当初、Mythos Preview が高いサイバー攻撃性能・高い脆弱性発見性能により危険であることを認識していました。そのため、限られた企業だけに公開し、モデルに対しては米国政府やUK AISI (*2) などの外部機関と連携して “jailbreaking” (*3)を防止する取り組みを行い、モデルが危険な用途に使われないように対策を試みていました。
図2 Fable 5・Mythos 5の一連の出来事を時系列に沿って並べた関係図
Anthropic社と外部機関は対策の末、”jailbreaking”が起こらないことを確認でき安全性が確保されたと判断しました。2つの最新LLM、Fable 5・Mythos 5はAnthropic社により2026年6月9日に一般の全ユーザーに公開されました。しかし、2026年6月12日に米国政府はAnthropic社に向けて米国籍を持たないユーザーに対して公開停止を指示する輸出管理指令を発令しました。指令は以下のように記述されています。
- The US government, citing national security authorities, has issued an export control directive to suspend all access to Fable 5 and Mythos 5 by any foreign national, whether inside or outside the United States, including foreign national Anthropic employees.
- 米国政府は安全保障・情報機関を引用しつつ、Fable 5とMythos 5 について、米国の内外を問わずAnthropicの社員も含めた全ての外国籍の国民に対しアクセスを遮断する輸出管理指令を発令した。
指令を発令した背景には、米国政府が ”jailbreaking” の用途に使用されていると認識したことが指摘されています。指令後、Anthropic社はユーザーが米国籍を持つかどうかの区別が難しいことから、一般の全ユーザーに対して公開停止とすることを決定しました。
背景には、安全保障面で生成AIがデュアルユース技術(軍民両用技術)と認識され始めていることが挙げられます。Fable 5・Mythos 5ではサイバー攻撃能力が向上しています。この技術を外国籍のユーザーがアクセスし利用することで、サイバー攻撃が活発になり防御が疎かになる懸念が指摘されています。米国政府は、そのような最先端のモデルに一般ユーザー (特に中国やロシアのユーザー) がアクセスできることを問題視したと予想されます。
その後、Anthropic社は政府の輸出管理要件を満たす形での対応を進め、6月30日にFable 5およびMythos 5のグローバルアクセス再開（Redeploying）を発表しました[2]。しかし、この再開に伴い利用規約や提供プランが大きく変更されました。Web UI（Claude.ai）のサブスクリプションプランでは利用に制限がかけられ、基本料金とは別の従量課金プランでの利用が必須となります（今後のサブスクリプションプランへの組み込みは未定）。アクセスは復活したものの、ユーザー側は「ベンダー側の都合による突然のルール変更とコスト増」を強制される形となりました。
- *2 UK AI Security Institute (AISI): 英国のDepartment for Science, Innovation and Technology（科学・イノベーション・技術省）配下で、先端AIの安全・セキュリティに関する調査研究や評価を行う政府組織。
- *3 “jailbreaking” (ジェイルブレイキング、ジェイルブレイク)：生成AIの安全フィルターや制限を回避し、禁止された出力を引き出す行為（プロンプトインジェクション等を含む）。
止まったのは「インフラ」ではなく「モデルへのアクセス」だった
注意しておきたいのは、Amazon Web Services: AWSや Microsoft Azureなどのクラウドインフラが止まったわけではなく、モデルにアクセスするための権限が剥奪されたことです。
クラウドLLMはモデルプロバイダー(*4)が管理するクラウド上で動作しています。提供の概略を図3に示します。
図3 クラウドLLMの提供体制と今回の問題が対象とした層
今回の問題では、Fable 5・Mythos 5にアクセスするApplication Programming Interface (API) (*5)のみが遮断されました。APIの公開停止はサービス終了よりも容易に行うことができ、モデルプロバイダーの意思決定によりモデルを容易に公開停止することができます。公開停止により、生成AIを活用する業務は停止してしまいます。実際に、指令が出てから1日経たずに公開停止に至っていることからもそのリスクは大きいと予想されます。
- *4 モデルプロバイダー：クラウド上でLLMをホストし、API等を通じて企業・開発者が利用できる形で提供する事業者。代表的な事業者としてAnthropic (Claudeシリーズ)、OpenAI (GPTシリーズ)、Google (Geminiシリーズ)、IBM (WatsonXシリーズ)などが挙げられる。
- *5 Application Programming Interface (API)：ソフトウェア同士が定義・手順（プロトコル）に従って通信し、機能を呼び出すための仕組み。
クラウドLLM依存が事業に与える2つのリスク
今回の問題で最も重要なのは、Anthropic社が自社の意向で公開停止したのではなく、外部の米国政府による指令によって強制的に公開停止へ追い込まれたという点です。どれだけベンダー側が対策を講じていようと、政府の判断一つでアクセスが失われるリスクが浮き彫りになりました。
これはAnthropic社に限らず、OpenAIやGoogleなどすべてのクラウドLLMに共通するリスクです。クラウドLLMへの依存を放置したまま生成AIを事業に組み込むと、次の2つの致命的な問題に直面します。
可用性(*6)の担保が難しい
特定のモデルプロバイダーへの依存は、その国の規制やモデルプロバイダーの意思決定・障害に自社の業務が依存することにつながります。生成AIを基幹業務に組み込むほどモデルプロバイダーへの依存度が高まり、外部要因による「突然の業務停止リスク」は高まります。
今回のFable 5の再開において、サブスクリプションプランでの利用が突如制限され、従量課金（別料金）へと移行されたことからも分かる通り、サービスが継続したとしても「ベンダー側の都合でコストや利用ルールが急変する」というリスクも同時に露呈しました。仕様や運用のコントロール権が自社にない以上、安定した業務運用をクラウドLLMだけに委ねるのには限界があります。
データガバナンスが自社にない
クラウドLLMのAPIにデータを送信することは、そのデータが海外の法域・規制環境下に置かれることを意味します。今回のFable停止は、米国政府の判断が自社のデータアクセスや業務に直接影響しうることを明確にしました。
これはプロバイダーの信頼性の問題ではなく、外部のインフラを借りて通信する構造上、避けられないリスクです。生成AIをビジネスの核として扱うのであれば、このリスクをいかに低減させるかが極めて重要な課題となります。
- *6 可用性（Availability）：障害や停止が起きても、システム/サービスが継続して利用できる状態をどの程度維持できるか（稼働率などで評価される）。
クラウドLLM依存に対する3つの解決策
クラウドLLMによる事業停止の避けられないリスクがあるものの、生成AIは事業を加速させるエンジンとなります。そこで、モデル運用の自律性を確保することで、公開停止や外部要因による「急ブレーキ」の影響を小さくすることができます。
ここで言う自律性とは、単に「クラウドを使わない」ことではありません。重要なのは、
- (1) 代替手段を常に用意しておくこと
- (2) 代替へ切り替えられる運用を平時から作っておくこと
の2点です。以下に3つの解決策を示しますが、全ての選択肢の前提条件となるのはローカルLLMの活用（または、自社がコントロールできる環境での推論基盤の確保）です。
この数年でさまざまなソフトウェアのオープン化が進み、LLMも無料公開されているローカルLLMが各社から多くリリースされています。代表例はLlama・Gemma・Qwenなどです。
これらのモデルを自社で運用することが自律性の確保につながります。言い換えると、クラウドLLMに依存することで生まれる「業務が停止するリスク」をローカルLLM運用で引き受けることで、業務が止まらない状態を作れるということです。クラウドLLMだけでなく、ローカルLLMも組み合わせて運用することで可用性の高い仕組みを業務に組み込むことができます。
ただし重要なのは、ローカルLLMを「保険」として機能させる設計です。ローカルLLMを用意していても、切り替え条件・品質基準・運用手順が曖昧だと、有事に切り替えられず結局止まってしまうことがあります。そこで実務では、図3に示す4つの対策を打つのが有効です。
生成AIのセキュリティリスクについてはこちらの記事で解説しています。気になる方はぜひお読みください。
これらを踏まえた上で、3つの解決策を示します。
解決策1：オンプレ環境でのモデル自社運用
最も有力な選択肢は、DGX Spark (*7) 等のAI特化型コンピュータを用いてローカルLLMを自社インフラ上で運用する形です。これは3つの選択肢の中で、最も高いレベルでモデル運用の自律性を確保できる手段になります。
最大のポイントは、モデルへのアクセス・データ・運用のすべてが自社のコントロール下に置かれることです。外部要因で特定モデルAPIが遮断される状況でも、「業務の継続性」を自社側で担保しやすくなります。DGX Sparkは、クラウドLLMに匹敵するモデルを運用することが可能な性能を有しています。
またオンプレ環境であれば、
- 取り扱うデータを外部に出さずに運用できる
- 利用制御や監査ログなどのガバナンスを自社仕様で設計できる
- 「クラウドLLMが止まる」という外的要因から、業務を切り離せる
といった意味でも、基幹業務に近い領域ほど適用しやすくなります。
本記事の結論としては、この選択肢が理想形であり、DGX Sparkのような基盤を用いてローカルLLMを安全に運用できる状態を作ることが、クラウドLLM依存リスクに対する最も強い解決策になります。
💡DGX Sparkを活用して、セキュアなローカルLLM環境を構築したい企業様へ
Athena Technologiesでは、DGX Sparkを活用したローカルLLM環境の導入支援を行っています。
企業ごとのセキュリティ要件や利用目的に合わせて、外部にデータを送らずにLLMを活用できる環境づくりを行います。チャット画面や社内向けAIアプリからLLMを使えるようにする仕組みづくりに加え、LLMを安定して動かすための環境整備や、より大きなモデルを扱うための構成検討まで、実際の業務利用を見据えて対応します。
機密情報を外部サービスに送信せず、自社環境で安全に生成AIを活用したい企業様は、ぜひAthena TechnologiesのDGX Spark導入支援をご検討ください。
⇨Athena TechnologiesのDGX Spark導入支援について詳しくはこちら
解決策2：既存の自社インフラへの組み込み
すでに自社でオンプレ環境やプライベートクラウドを持っている場合は、その既存資産を活かしてオープンモデルを載せることで、新規投資を抑えながら自律性を確保できます。
この選択肢は「ゼロから専用基盤を作る」ほどの大きな投資をせずに、まずは止まらない仕組みを作りやすい点が魅力です。既存の監視・運用体制、ネットワーク設計、認証/認可の仕組みを活用できるため、導入スピードも高くなります。
位置付けとしては、
- すでにある資産でローカルLLM運用を始める
- クラウド依存のリスクをローカル側で受け止め、業務停止を回避できる状態を作る
- 効果が見えた段階で、より強い自律性（選択肢1）へ拡張する
という投資コストを抑えながら生成AIを業務に組み込む選択肢となります。
解決策3：クラウドサービスの活用
より大規模な運用を検討する場合はAWS・GCPなどのクラウドGPUリソース上でオープンモデルを自社運用する形を取ることが望ましくなります。クラウドの可用性メリットを享受しつつ、モデル依存リスクを回避できます。
注意するのは、クラウドを使うこと自体はリスクではないということです。リスクは、特定のモデルプロバイダーが提供するAPIに依存し、外部要因で遮断された瞬間に切り替え不能になってしまう点にあります。
そのためクラウドであっても、
- 自社がコントロールできる形でオープンモデルを運用する（=「モデルの自律運用」）
- 必要に応じてリージョン/クラウドをまたいだ運用や移行を設計できる
という条件を満たせば、十分に有効な選択肢になりえます。
全社で導入を進めたいが、既存のオンプレ環境・プライベートクラウドなどの計算資源がない場合に有効な選択肢となります。
- *7 DGX Spark: NVIDIAが製造しているAI用高性能コンピュータ。手のひらサイズの筐体にNVIDIA GB10 Grace Blackwell Superchipという最先端チップを搭載しており、128GBという大容量メモリで様々なAIを動作させることができる。
業務へローカルLLMを組み込む手順
最後に、自律性を担保しながら生成AIを業務に組み込む際に現場で進めやすいロードマップを提示します。以下の5段階に渡って業務への組み込みが進みます。
- 業務の棚卸し
- 生成AIが止まったときに影響が大きい業務を特定する（「止められない業務」と「止まってもよい業務」を分ける）。
- 重要機能の分解
- RAG、要約、分類、コード生成などを分け、代替モデルで継続すべき機能を定義する。
- 評価基盤の整備
- 自社データでの評価セットを作り、クラウド/ローカルを同一指標で比較できるようにする。
- フェイルオーバーの実装
- システム側でモデル差し替えを吸収し、停止時に自動/半自動で切り替えられるようにする。
- 運用に載せる
- 監査ログ、アクセス制御、モデル更新手順、インシデント対応を「日常業務」に組み込む。
ローカルLLMを安全に運用・構築するならAthena Technologiesの「DGX Spark導入支援」
「ローカルLLMを使えば止まらない」と分かっていても、実際には 「何から着手すればいいか」と「どこまでやれば業務で使える状態になるか」が見えないまま、検討が止まってしまうケースが多いです。
Athena Technologiesの「ローカルLLM導入支援・DGX Spark導入支援」は、単に機材を導入する支援ではありません。クラウドLLMの停止リスクをローカルLLM側で受け止め、業務が止まらない状態を「設計→構築→運用」まで一気通貫で作るための伴走支援です。
支援内容（例）：
- ユースケース棚卸し：止められない業務・最低限継続すべき機能の明確化
- モデル/構成設計：用途に応じたモデル選定、性能・コスト・セキュリティ要件の整理
- 評価と品質担保：評価データ作成、回帰テスト、現場運用に耐える基準作り
- 実装と運用設計：フェイルオーバー設計、監査ログ、アクセス制御、更新手順の整備
「クラウドLLM依存の不安」を「止まらない仕組み」に変えるところまで一緒に進めます。まずは現状の業務と制約条件（データ・規制・コスト・期限）を整理し、最短で前に進める導入計画から作成します。
利便性と可用性の両立を実現しながらAI活用を進めたい企業にとって、おすすめの選択肢です。ローカルLLM導入を検討している方は、ぜひAthena Technologiesにお問い合わせください。
参考文献
- [1] Statement on the US government directive to suspend access to Fable 5 and Mythos 5 - Anthropic Announcements
- [2] Redeploying Fable 5 - Anthropic Announcements
