公開から3日で停止──Fable 5/Mythos 5をめぐる米政府指令が示した、AIの新しい可用性リスク

公開から3日で停止──Fable 5/Mythos 5をめぐる米政府指令が示した、AIの新しい可用性リスク

こんにちは!

前回の記事では、Anthropicが2026年6月9日に発表したClaude Fable 5とClaude Mythos 5について取り上げました。

Mythos級の強力な能力にセーフガードを加え、一般ユーザーにも提供できる形へと降ろしたFable 5。

私たちはそれを、「神話が寓話になって降りてきた」と表現しました。

しかし、その寓話は、わずか3日で公開の場から姿を消すことになります。

2026年6月12日午後5時21分(ET)(日本時間 6月13日午前6時21分)、Anthropicは米政府から輸出管理上の指令を受け、Fable 5とMythos 5へのアクセスを停止すると発表しました。

指令の対象とされたのは、米国外の利用者だけではありません。

Anthropicの説明によれば、米国内にいる外国籍者や、同社で働く外国籍の従業員も含まれます。

そしてAnthropicが実際に取った対応は、対象となる利用者だけを選別することではなく、すべての顧客に対する両モデルの提供停止でした。

今回の出来事は、Fable 5のセーフガードが十分だったのかという技術論だけでは捉えきれません。

そこから見えてくるのは、AIモデルの可用性が、性能、料金、障害だけでなく、輸出管理、利用者の法的属性、政府の政策判断によって左右される時代の到来です。

※本稿は2026年6月14日時点で公開されている情報に基づいています。政府からAnthropicへ送られた指令の全文や、判断の根拠となった技術資料は公表されていません。


何が起きたのか

Anthropicは2026年6月9日、Fable 5とMythos 5を発表しました。

両者は同じ基盤モデルを使用していますが、提供方法が異なります。

Fable 5には、サイバーセキュリティ、生命科学、モデル蒸留などに関する要求を検知する安全分類器が組み込まれていました。分類器がリスクを検知した場合、Fable 5自身には回答させず、次に高性能なClaude Opus 4.8へ処理を切り替える仕組みです。

一方、Mythos 5は一部領域の制限を解除したモデルとして、サイバー防御組織や重要インフラ事業者など、限定された利用者に提供されていました。

Anthropicは、Fable 5の安全策について、無害な要求を誤って検知することがあるほど保守的に設計したと説明していました。

これは、まだ体感レベルではあるものの、以下のように当社でも実際に何度も体験しました。

upload in progress, 0
こんなかんじで、かなり広い範囲でセーフガードが発生している印象をもちました

それでも、Mythos級の能力を一般提供するには、この慎重さが必要だと判断したわけです。

ところが2026年6月12日、米政府は国家安全保障上の権限を理由として、外国籍者によるFable 5とMythos 5へのアクセスを停止するようAnthropicに指示しました。

Anthropicによれば、指令を受け取ったのは同日午後5時21分、米国東部時間でした。書簡には、国家安全保障上の懸念について具体的な説明がなかったとされています。

Reutersは、米商務省が外国籍者による両モデルへのアクセス停止を求める輸出管理指令を出したことを、米政府当局者に確認しています。

ただし、政府の指令文そのものや、技術的判断の根拠となった資料は、現時点では公開されていません。


政府の懸念と、Anthropicの反論

Anthropicは、
政府がFable 5の安全機構を回避する、いわゆるjailbreakの手法を把握したと理解している
と説明しています。

同社が確認したデモでは、特定のコードベースをモデルに読ませ、いくつかの既知の軽微な脆弱性を発見させていたとされています。

これに対してAnthropicは、次のように反論しています。

問題となった手法は、広範な安全機構を解除する「汎用的なjailbreak」ではなく、限定された状況でのみ成立する狭い手法であること。

発見された脆弱性は比較的単純で、他社の一般公開モデルでも、安全機構を回避せずに発見できること。

Fable 5の公開前には、米政府、英国AI Security Institute、外部機関、社内チームが合計数千時間に及ぶ検証を行っていたこと。

そして、現実の被害につながった重大なjailbreakについては、まだ報告を受けていないことです。

Anthropicは、完全に破られない安全機構を現時点で実現するのは難しいと認めています。そのうえで、個々の回避手法を狭くし、大規模な回避には高いコストがかかるようにし、監視によって発見・停止する「多層防御」を採用していました。

同社は、この程度の限定的な回避可能性だけで一般提供モデルを全面停止するのであれば、同じ基準は他社のフロンティアモデルにも適用され、事実上、新しいモデルを公開できなくなると主張しています。

ここで重要なのは、どちらかの主張を、公開情報だけで直ちに正しいと判断しないことです。

政府側の詳細な技術的根拠は公表されていません。一方、問題となった手法が限定的で、他社モデルと同程度だったという評価も、現時点では主にAnthropic側から示されているものです。

したがって現段階では、「政府の過剰反応だった」とも、「Fable 5に重大な欠陥があった」とも断定できません。

確認できるのは、
政府とモデル提供者のリスク評価が一致せず、政府側の判断によって、公開から3日後にモデル全体が停止されたという事実です。


「米国外を遮断する」だけでは済まない

今回の指令で、特に重要なのが対象者の区切り方です。

これは、単純な地域制限ではありません。

仮に「米国外からのアクセスを停止する」という条件であれば、完全ではないにしても、IPアドレス、契約主体、請求先、クラウドリージョンなどによって、ある程度の制御が可能です。

しかしAnthropicの説明によれば、今回の対象は、米国内にいる外国籍者にも及びます。

つまり、どこから接続しているかではなく、誰が接続しているかを判定しなければなりません。

米国の輸出管理には、管理対象となる技術やソースコードを米国内の外国人に開示した場合、それを当人の国籍国への輸出とみなす「deemed export」という考え方があります。

今回の指令に、通常のdeemed export規則が具体的にどのように適用されたのかは、指令文が公開されていないため確認できません。

しかし、米国内にいる外国籍者まで対象とされたこと自体は、
輸出管理において地理的な国境だけでなく、技術にアクセスする人の法的属性が問題になり得ることを示しています。

一般的なクラウドサービスは、すべての利用者について、国籍や在留資格まで確認する仕組みを持っているとは限りません。

個人向けサービスで把握しているのは、氏名、メールアドレス、電話番号、決済情報、接続地域などが中心です。これらの情報だけでは、その人が米国市民なのか、永住者なのか、外国籍の一時滞在者なのかを確実に判定できません。

企業利用では、さらに複雑になります。

一つの法人契約の中に、複数の国籍の従業員がいます。一つのAPIキーやサービスアカウントを、複数のチームやシステムが共有していることもあります。

米国企業が契約したAPIであっても、そのAPIを組み込んだ製品を、海外の利用者が使っている可能性があります。海外子会社、業務委託先、保守担当者が同じ環境へアクセスするケースもあります。

モデルを提供するAnthropicから見て、最終的に誰がその出力を利用しているかを、常に把握できるとは限りません。

さらに、制御すべき対象は、モデルへ直接プロンプトを送る利用者だけとは限りません。

管理画面へアクセスする担当者、ログを見る運用者、問い合わせに対応するサポート担当者、モデルを検証する開発者など、どこまでを「アクセス」とみなすかも整理する必要があります。

外国籍者だけを確実に除外するには、本人確認のやり直し、法的属性の確認、企業内の権限再設計、APIの再提供先の把握、委託先を含むアクセス管理などが必要になります。

これは、IPアドレスを一つ遮断するような変更ではありません。

Anthropicは、外国籍者だけを選別して停止するのではなく、すべての顧客への提供停止を選びました。

同社は、その技術的・運用的理由を詳細には説明していません。しかし、指令を受け取った直後に確実な法令順守を求められた状況では、対象者を不完全に選別して提供を続けるより、全体を停止する方が、現実的な選択だったと考えられます。

これは、米国人だけに提供を限定することが原理的に不可能だという意味ではありません。

厳格な本人確認と組織内アクセス管理を導入すれば、一定の限定提供は不可能ではないでしょうが、
世界中の個人、企業、クラウドサービスを経由して利用される既存のAIモデルを、短時間で、利用者の国籍や法的地位を基準に正確に分離することは、現在のサービス設計とは著しく相性が悪そうです。


輸出管理の対象が「モデルへのアクセス」に広がった

米国のAI輸出管理は、これまで主にGPUなどの高性能半導体、半導体製造装置、関連技術を中心に議論されてきました。

それらは、AIを作るための計算資源です。

今回起きたのは、計算資源ではなく、すでに学習されたモデルの能力に対するアクセスが制限されるという出来事です。

これは重要な違いです。

GPUであれば、物理的な出荷先、所有者、設置場所を追跡できます。

一方、APIとして提供されるAIモデルは、一つのサーバーから世界中へ同時に提供されます。米国のデータセンターで推論が行われていても、利用者は日本、欧州、アジア、あるいは米国内の外国籍者かもしれません。

また、利用者がモデルを直接操作しているとは限りません。SaaS、社内システム、開発ツール、業務エージェントの裏側で、知らないうちに特定のモデルが呼び出されている場合もあります。

モデルは物理的に輸出されなくても、その能力はネットワークを通じて国境を越えます。

今回の指令は、AIモデルそのものが、半導体や暗号技術と同じように、国家安全保障上の管理対象となり得ることを明確に示しました。


技術的な安全性だけでは、提供の継続を保証できない

Fable 5は、強力なモデルにセーフガードを加えることで、一般提供を可能にする試みでした。

Anthropicは、危険性の高い要求を分類器で検知し、より能力の低いモデルへ切り替える仕組みを設けました。監視のために、Fable 5では顧客データの30日間保存も必須としました。

つまり、Anthropicは技術的な安全策だけでなく、運用上の監視まで含む多層防御を設計していました。

しかし、その設計を政府が十分と判断するとは限りません。

企業が「安全に提供できる」と考え、外部機関が検証し、利用者が契約していたとしても、政府が異なるリスク評価を下せば、モデルは停止します。

ここで、安全性を判断する主体が一つではなくなります。

モデルを作る企業。

第三者の評価機関。

クラウド事業者。

顧客企業。

そして政府です。

それぞれが異なる情報を持ち、異なる基準でリスクを評価します。

問題は、政府がAIモデルを止める権限を持つべきかどうか、という単純な二択ではありません。

Anthropic自身も、重大な危険があるモデルについて、政府が提供を止められる制度は必要だと述べています。

問われるべきなのは、その判断が、どのような基準で行われるのかです。

どの程度の能力があれば規制対象となるのか。

限定的なjailbreakが一件確認されただけで停止するのか。

他社モデルにも同じ能力がある場合、同じ基準を適用するのか。

モデル提供者は、根拠となる技術資料へアクセスできるのか。

判断に異議を申し立て、第三者が再検証する手続きはあるのか。

これらが明確でなければ、モデル提供者も利用企業も、どの条件を満たせば安全に提供を続けられるのか分かりません。

安全規制には、強い権限だけでなく、予測可能性と検証可能性が必要です。


日本企業にとっても、対岸の火事ではない

今回の対象は、Anthropicの二つのモデルです。

しかし、企業側が受け取るべき教訓は、特定のベンダーに限られません。

これまでAIモデルの可用性リスクというと、次のようなものが中心でした。

  • API障害
  • レート制限
  • 料金改定
  • モデルの廃止
  • 利用規約の変更
  • 性能や出力傾向の変化

今後は、ここに政策・規制リスクが加わります。

昨日まで利用できていたモデルが、輸出管理、安全保障上の判断、国籍要件、クラウド事業者への命令によって、突然利用できなくなる可能性があります。

日本企業が米国企業のAIモデルを利用する限り、米国の政策判断から完全に独立することはできません。

だからといって、すべてを国産モデル("国産"の定義も、おそらく難しいテーマとなりそうです)へ置き換えれば解決する、という単純な話でもありません。

重要なのは、
モデルが利用できなくなることを例外的な事故として扱わず事業継続上のシナリオとして設計に入れる
ことです。

1. 特定モデルへの密結合を避ける

モデルごとに異なるAPI仕様、ツール呼び出し、プロンプト形式を、アプリケーションへ直接埋め込みすぎないようにします。

モデル切り替え層を設け、代替モデルへ移行できる構造を持つことが重要です。
(ただし、これは我々実務家としては 言うは易し であることを認識しています)

2. 停止時の縮退運転を決める

高性能モデルが使えなくなった場合に、下位モデルで継続するのか、処理を人間へ戻すのか、一部機能を停止するのかを、あらかじめ決めておきます。

単に代替モデルへ切り替えればよいとは限りません。性能や安全性が異なるモデルへ切り替えた結果、品質基準を満たせなくなる場合もあります。

3. 評価資産を持ち運べるようにする

切り替え前後のモデルを比較できるよう、実業務に基づく評価データ、期待出力、失敗例を自社で保有しておきます。

ベンダーのベンチマークだけでは、
自社業務における代替可能性は判断できません。

4. 契約先だけでなく、提供経路も把握する

同じモデルでも、Anthropicの直接API、AWS、Google Cloud、Microsoftの基盤など、複数の経路で提供される場合があります。

今回、AWSでも全地域・全利用者へのアクセス撤回が求められたと報じられています。

当然、クラウドを変えれば規制を回避できるとは限りません。どの企業がモデルを管理し、どの国の法制度が適用され、停止判断がどの経路へ波及するのかを把握する必要があります。

5. SLAだけでなく、政策停止を想定する

通常のSLAは、稼働率や障害復旧時間を対象とします。

しかし政府命令による停止は、一般的な障害とは異なります。
復旧時期をモデル提供者自身が決められず、代替提供の義務も限定される可能性があります。

重要業務へAIを組み込む場合には、サービス終了、モデル撤回、規制による提供停止が契約上どのように扱われるのかも確認すべきです。


jailbreakだけを見ていると、安全性の全体像を見失う

今回、政府が問題視したとAnthropicが説明しているのは、安全機構を回避し、本来制限される能力を引き出すjailbreakです。

これは、止めるべきものを止められない、いわば安全機構の「見逃し」の問題です。

しかし、安全機構には反対側の失敗もあります。

・無害な要求を危険だと判断する誤検知。

・実際には起きていない攻撃を、起きたと説明する作話。

・安全機構が何を検知したのかを、利用者が後から検証できない不透明さ。

モデルが切り替わったことで、どのモデルがどの出力を生成したのか追跡しにくくなる監査上の問題です。

私たちは今回の政府指令が出る以前から、
Fable 5を利用していたClaude Codeのセッションで、存在しないプロンプトインジェクションが報告された事例
を調査していました。(別記事を投稿予定です)

これは、政府が懸念したとされるjailbreakとは別の事象です。

一方は、危険な能力を引き出せてしまった可能性。

もう一方は、攻撃が存在しないのに、攻撃を検知して拒否したという説明が生成された事例です。

両者を混同すべきではありません。

しかし、どちらも同じ問いにつながります。

安全機構は、何を止めたかだけで評価できるのでしょうか。

何を見逃したか。

何を誤って止めたか。

なぜ止めたのかを正しく説明できたか。

後から独立した記録によって検証できるか。

安全性を評価するには、これらすべてを見る必要があります。

私たちが経験した事例については、
生ログを使った検証と、そこから構築した防御策を、別の記事で詳しく紹介します。


おわりに
昨日まで使えた「知能」が、政策によって消える

Fable 5は、Mythos級の能力を安全に一般提供するという、野心的な試みでした。

しかし、技術的な安全策を積み重ねても、提供の継続まで保証されるわけではありませんでした。

今回の出来事を、米政府とAnthropicの対立や、一つのjailbreakをめぐる論争だけで捉えると、本質を見落とします。

見えてきたのは、AIモデルが国家安全保障上の戦略資産となり、その提供範囲が政策によって決められる時代です。

そして、ネットワークを通じて世界中へ提供されるAIの能力を、利用者の国籍で正確に区切ることの難しさです。

AI導入における可用性リスクとは、サーバーが落ちることだけではありません。

モデルの料金が上がることでも、APIの仕様が変わることでもありません。

昨日まで業務を支えていた「知能」そのものが、政府の判断によって、翌日には利用できなくなる

企業は、その可能性を前提にAIシステムを設計する段階へ入りました。

性能の高いモデルを選ぶことは、もちろん重要です。

しかしこれからは、そのモデルが使えなくなったときにも事業を続けられるか。

そこまで含めて、AI導入の設計品質が問われることになります。

特定のモデルに依存しない、企業のためのAI基盤を

株式会社Qualitegが提供する「Bestllam」は、複数の生成AIモデルとAIエージェントを、企業の業務環境に統合するためのエンタープライズAI基盤です。

GPT、Claude、Geminiをはじめとする30以上のLLMに対応し、タスクに応じてモデルの選択や、複数モデルの同時利用が可能です。特定のモデルだけに業務を密結合させるのではなく、用途、性能、コスト、提供状況に応じて選択肢を持てる構成を目指しています。

また、社内システムとの連携、企業専用の隔離実行環境、個人情報・機密情報を保護するLLM-Audit®など、AIを実証実験で終わらせず、継続的に業務で利用するための機能を備えています。

Qualitegでは、Bestllamの提供に加え、モデルの選定、マルチモデル構成、停止時の縮退運転、評価データの整備、既存システムとの連携まで、企業のAI導入を設計・開発の両面から支援しています。

特定モデルへの依存を見直したい方や、モデル環境の変化に耐えられるAI基盤を検討されている方は、ぜひQualitegへご相談ください。

それでは、また次回、お会いしましょう!

Read more

ついに一般公開、Claude Mythos5(ミュトス)/  Fable 5(フェイブル) を実務視点で読み解く

ついに一般公開、Claude Mythos5(ミュトス)/ Fable 5(フェイブル) を実務視点で読み解く

こんにちは! Qualitegプロダクト開発部です。 2026年6月9日、Anthropicから Claude Fable 5(フェイブル5)と Claude Mythos 5(ミュトス5)が発表されました。 この記事では、 Fable 5 とは何か、Mythos 5 と何が違うのか、 Claude Code やAIエージェントを実務で使う立場から見て何が変わるのか を整理します。当社ブログを読んでくださっている方は、4月の「強すぎて出せないモデル "Mythos"」や「Mythosレベルのオープンモデルはいつ出るのか」でも触れた、あの Mythosクラスの一般公開版がついに来た、という話でもあります。 この記事でわかること * Fable 5 と Mythos 5 は「同じ基盤モデルだが、安全装置の有無が違う」こと * 高リスク領域では応答が Opus 4.

By Qualiteg コンサルティング, Qualiteg プロダクト開発部, Qualiteg 研究部
Claude Codeで正規の運用作業が「Usage Policy違反」になる理由 ── リアルタイム・サイバーセーフガードの誤検知と対処法

Claude Codeで正規の運用作業が「Usage Policy違反」になる理由 ── リアルタイム・サイバーセーフガードの誤検知と対処法

こんにちは! 今日は、Claude Code を使っていると突然出てくる「Usage Policy違反」エラー いわゆる リアルタイム・サイバーセーフガードの誤検知(false positive) について、その傾向と対処法を詳しく解説します! 自社サーバへのデプロイ作業中や、ごく普通のインフラ運用の最中に、こんなメッセージが出て手が止まった経験はありませんか? API Error: Claude Code is unable to respond to this request, which appears to violate our Usage Policy. This request triggered cyber-related safeguards. やっていたのは、自分のサーバー への SSH デプロイと、自社リポジトリへのコミット指示だけ。 攻撃的な操作は何ひとつ含まれていないはずなのに、ブロックされてしまう… そんな状況に心当たりのある方は、

By Qualiteg プロダクト開発部
個人情報検出の精度を、どう正しく語るか ― Recall、信頼区間、代表性から考える評価設計

個人情報検出の精度を、どう正しく語るか ― Recall、信頼区間、代表性から考える評価設計

こんにちは。Qualiteg研究部です。 私たちは、個人情報(PII)や機密情報、要配慮個人情報を含むセンシティブな情報を検出・マスキングする技術(https://pii-fi.com)の開発に取り組んでいます。 その中で日々向き合っているのが、 「精度の数字を、どうすれば正直に、正しく語れるのか」 という問題です。 たとえば、検出器の Recall(再現率)が 0.95 だったとします。 これは高い数字に見えます。しかし、その数字はどの種類の文書で測ったものなのか。正解データはどう作ったのか。サンプル数は十分なのか。別の業務文書にも同じ数字を当てはめてよいのか。 精度の数字は、単独ではほとんど意味を持ちません。 「何を、どの条件で、どう数えたか」とセットになって、はじめて実務で使える数字になります。 本記事では、私たちが PII 検出の精度評価に取り組む中で得た、精度を誠実に語るための考え方を紹介します。アルゴリズムの中身ではなく、評価のしかたに焦点を当てます。 1. はじめに:「Recall 0.95

By Qualiteg 研究部
一文の依頼で、調査から資料作成まで。AIエージェント「Bestllam」のデモ動画を公開しました

一文の依頼で、調査から資料作成まで。AIエージェント「Bestllam」のデモ動画を公開しました

こんにちは! 本日は当社の統合AIプラットフォーム "Bestllam®" の AIエージェント機能のデモをご紹介いたします! 「指示は出せても、AIが本当に仕事を仕上げてくれるのか」 生成AIを業務に取り入れる企業が増えています。 しかし現場からは、こんな本音も聞こえてきます。 「使い方を覚えるより、自分でやったほうが早い」 「指示を細かく出し直しているうちに、結局時間がかかる」 「便利なのは分かるが、機密情報を入力していいのか不安」 AIを"個人の便利ツール"の域から、"部門の成果"へと引き上げる。 これが当社の法人向け統合AIプラットフォーム Bestllam(ベストラム) が掲げるテーマです。 今回、そのAIエージェント機能を実際の操作画面とともに紹介する動画を公開しました。 たった一文の依頼が、7枚のレポートになるまで 動画のデモはシンプルです。エージェントに、こう入力します。 「先月の売上を年代別に分析し、資料にまとめてください」 これだけです。すると、エージェントはまず自分でTODOリストを組み立て、何をどの順番で進めるかという段取りを示します

By Qualiteg ビジネス開発本部 | マーケティング部