政府がAIモデルを停止するとき：Fable 5とMythos 5の利用停止がセキュリティチームに意味すること

2026年6月12日の夜、Anthropicはアクセスを停止し、最新モデルのClaude Fable 5とClaude Mythos 5を世界中のすべての顧客が利用できないようにしました。障害や自社で発見した脆弱性が理由ではありません。同日午後5時21分（米国東部時間）に受け取った、国家安全保障当局を根拠とする米国政府の輸出管理指令に従うためでした。

セキュリティに携わる人にとって、政治的な側面以上に重要なのは詳細です。報告された発端は何だったのか、措置はどのように実施されたのか、そして他社のモデルに依存することについて何が明らかになったのか。政策論争でどの立場を取るにせよ、セキュリティチームが行動に移せる問いです。

AnthropicのFable 5とMythos 5で実際に何が起きたのか

正確に把握しておくことが大切です。オンラインで広まっている「政府がモデルを全面的に禁止した」という要約は、記録にある内容とは少し異なります。

Anthropicの声明によると、この指令は「米国内外を問わず、外国籍のすべての人（外国籍のAnthropic従業員を含む）によるFable 5およびMythos 5へのアクセスを停止する」よう同社に命じました。文面上、この制限の対象はすべてのユーザーではなく、外国籍の人によるアクセスでした。

世界規模での停止は、実務上の帰結でした。Anthropicの説明によると、「この命令の実質的な影響として、コンプライアンスを確保するため、すべてのお客様に対してFable 5とMythos 5を直ちに無効にせざるを得ません」。数億人のユーザーベースを対象に、とりわけ当日中の通知で、外国籍の人と米国人をリアルタイムに確実に区別する方法はありません。そのため同社は全ユーザーに対してモデルを停止しました。この違いは重要です。命令が対象としたのは外国籍の人によるアクセスでしたが、短期間でこれを徹底する唯一の方法は、一律に停止することでした。

公表された理由は、報告された「AI脱獄」でした。Anthropicは、提示された証拠について次のように説明しています。「政府から口頭で示されたのは、特定のコードベースをモデルに読み込ませ、ソフトウェアの欠陥を修正させるという、限定的で普遍的ではない脱獄の可能性に関する証拠だけです」。同社はさらに、「そこで示された能力は、OpenAIのGPT-5.5を含む他のモデルでも広く利用でき、システムを安全に保つ防御側の担当者が日々活用しています」と述べました。

政府は指令を公開しておらず、書簡にも具体的な技術的根拠は示されていないため、一般に知られている内容の大部分はAnthropicの説明に基づいています。最先端モデルのサイバー能力が国家安全保障上の懸念事項となるのは正当であり、報道によると、指令は第三者による脱獄の主張を受けて発令されました。ここで検討できるのは、機密扱いの詳細ではなく、措置のあり方と、確立されたセキュリティ慣行との比較です。

報告された発端：コードの分析と修正

モデルにコードベースを読み込ませて欠陥を修正させることは、特殊な攻撃ではありません。自動コードレビューや脆弱性の修正であり、静的解析、ファジング、AIを活用したコードレビュー、リリース前にスキャンを実行するセキュリティエンジニアが担うのと同じ作業です。防御側が日常的に使う能力であり、ほとんどのセキュリティ機能と同じく、本質的にデュアルユースです。

技術コミュニティはすぐにこの点を指摘しました。Hacker Newsでは、あるコメント投稿者が次のように述べています。「正しく読めているなら、『脱獄』とはモデルにコードベースを修正させるよう頼むと、欠陥を明らかにすることなのか？高い能力を維持しながら解決するのはほぼ不可能なギャップに思える。コードベースを修正できるようにしたいのだから」。脆弱性を修正できても、その内容を説明できない高性能なコーディングモデルはあり得ません。

停止前の数日間、一部のセキュリティ研究者は正反対の不満を抱いていました。Fable 5のガードレールが、正当な防御業務に対して厳しすぎるというのです。IBM X-ForceのValentina PalmiottiはTechCrunchにこう語っています。「サイバー関連の可能性が少しでもあるリクエストは、すべて拒否します」。同じ週のうちに、防御側には制限が厳しすぎると批判されたモデルが、防御に使われる能力を理由に提供停止となったのです。

能力はデュアルユースです。これはセキュリティ分野ではよく知られた性質です。ポートスキャナー、パケットアナライザー、ファザー、SASTエンジン、デバッガー、メモリ破損の概念実証はいずれも、使う人と目的によって「攻撃」ツールにも「防御」ツールにもなります。私たちはnmapを禁止していませんし、Wiresharkを武器とは見なしません。セキュリティ分野では、防御に必要なツールを禁止しては防御を強化できない、というのが一般的な結論です。

セキュリティ分野におけるデュアルユースのリスクへの対処

ここにある一般的な問題は、以前からあるものです。強力な能力が存在し、悪用される可能性がある。セキュリティ分野では何十年もかけて対処方法を築いてきました。この特定の措置をどう評価するにせよ、その方法は参考になります。いくつかの原則に基づいています。

調整された脆弱性開示。重大な欠陥が見つかった場合、確立された慣行では、修正できる関係者に非公開で報告し、対応期間を合意したうえで、修正が完了してから公表します。責任ある開示の目的は、エコシステムの発展を促しながら、被害を抑えることです。Anthropicの説明では、同社が受け取ったのは脱獄の可能性を示す口頭の証拠だけで、具体的な発見内容を書面では提供されませんでした。政府は自らのプロセスを公に説明していません。

多層防御。単一の対策に完全性を期待することはできません。そのため複数の対策を重ね、一部が失敗することを前提とします。Anthropicによれば、Fable 5はまさにこの原則に基づいて構築されており、リリース時にもこう説明していました。「どのモデル提供者にとっても、現時点で完璧な脱獄耐性を実現するのは不可能だと考えています」。そこで、脱獄を「限定的にするか……実行コストを非常に高く」し、「これに徹底した監視を組み合わせ、成功した攻撃をすばやく検知して遮断する」方針を採りました。これは、IDEでのスキャン、プルリクエストでのチェック、CIでのゲート、本番環境での監視を組み合わせる、多層的なアプリケーションセキュリティと同じ考え方です。何も侵入しないことを期待するのではありません。各層が侵入したものを検知し、封じ込めることを期待するのです。

リスクに基づく優先順位付け。成熟したセキュリティプログラムでは、すべての検出事項を最重要の緊急事態として扱いません。それは不可能であり、逆効果だからです。広く使われているnpmパッケージで重大なCVEが発見されても、エコシステム全体を停止させることはありません。悪用可能性と到達可能性を基準にトリアージし、実際に影響するものを優先して修正し、検証します。SnykがAI生成コードをセキュアにする取り組みをはじめ、アプリケーションセキュリティ全般で重視する考え方もこれと同じです。深刻度は必要な指標ですが、それだけでは十分ではありません。「どのリスクが現実に存在し、到達可能で、最優先で対処すべきか」を問うことが重要です。セキュリティチームが、完全に有効か完全に停止かという二択を迫られることはほとんどありません。実際のリスクに応じた段階的な対応を見極めるのが、現場の実践です。

政府がプロセスを説明していないため、公表されている情報だけで今回の措置がこれらの慣行にどう当てはまるのかを判断するのは困難です。これらの慣行が示すのは、その後の議論に共通の枠組みをもたらすことです。

Fable 5の停止をめぐる反応の分かれ方

世間の反応はすぐに分かれました。一方では、Anthropic自身がAIの導入に対する政府の権限を公に支持していたのに、その権限が自社に行使されると異議を唱えている、という意見がありました。Anthropicは声明で、政府は安全でない導入を阻止できるべきだとしつつ、それは「透明で、公平かつ明確で、技術的事実に基づく法定手続きの一環」であるべきだと述べ、「今回の措置はこうした原則に従っていない」と主張しました。政府が示した根拠は国家安全保障であり、最先端モデルのサイバー能力に対する懸念は正当なものです。また報道によると、指令は第三者による脱獄の主張を受けて発令されました。具体的な証拠は公開されていません。

どちらの当事者にもほとんど関心を持たない反応もありました。Fable 5を使って開発していた開発者は信頼性に注目し、多くの人が、外部から停止されることのないオープンウェイトモデルやセルフホスト型モデルを選ぶべきだという根拠として、この一件を受け止めました。IPO前の宣伝活動ではないかと懐疑的に見る人もいました。Simon Willisonは、アクセスが途絶えた瞬間を記録しました。

過去にも前例があります。1990年代、米国は強力な暗号技術を規制対象の軍需品として扱い、輸出を制限しました。最終的に米国の裁判所は、セキュリティコードの公開は保護される表現行為であるとの判断を下しました。こうした規制は輸出を制限するものであり、国内ユーザー向けにすでに提供されている製品の利用を停止させるものではありません。この点が今回の事例と異なるところの一つです。

セキュリティチームが見過ごせない信頼性の問題

法的な論点はいったん脇に置きましょう。政策論争の行方に左右されない、運用上の教訓があります。

一つの指令により、一般に利用できる製品が数時間のうちに世界中のすべてのユーザーに対して停止されました。Fable 5をワークフローに組み込んでいた人にとって、モデルの利用可否は、自分たちやベンダーの管理が及ばない力によって覆されるものでした。事態にリアルタイムで対応した開発者たちが行き着いた結論は明白です。モデルの冗長化は、コストやパフォーマンス上の検討事項にとどまらず、レジリエンスを確保するための必須要件になっています。ホスト型モデル一つだけに依存するのは単一障害点です。障害、課金上の問題、ポリシー変更、政府からの書簡のいずれが原因であっても、単一障害点はセキュリティ上の問題です。

これは、Snykがソフトウェアサプライチェーン全体に適用する原則と同じです。見えないものは管理できません。だからこそ、AIの影響範囲を把握し、資産検出を通じてAIコンポーネントや依存関係がシステム内のどこにあるかを棚卸しし、いずれかが機能しなくなった場合に備えることが、今や不可欠になりつつあります。Fable 5の停止は、その理由をリアルタイムで示す出来事です。

連携して守る：セキュリティツールの役割

政策論争の結論がどうであれ、セキュリティチームは業務を続けなければなりません。実務上の課題は、日々の業務でデュアルユースのAI能力をどう管理するかです。この分野には、すでに確立された手法があります。Snykでは、AIツールそのものにもこの問題が現れていることを確認しています。ToxicSkillsの調査では、AIエージェントのスキル約4,000件を監査し、3分の1以上に、プロンプトインジェクションやシークレットの露出からマルウェアまで、少なくとも1つのセキュリティ上の欠陥があることがわかりました。

調整された脆弱性開示、多層防御、継続的な監視、リスクに基づく優先順位付けは、抽象論ではありません。脆弱性が絶えず発見される中でも、世界中でソフトウェア開発を続けるための日々の実践です。これらは、AIを活用して開発・運用する際にもそのまま応用できます。

• モデルが生成するコードを継続的にセキュアにする。AIによって、より多くのコードをより速く書けるようになりましたが、すべてが安全とは限りません。AI生成コードの作成時とプルリクエスト時にスキャンし、可能な場合は自動修正することで、スピードと安全性を両立できます。これが、SnykがAIを活用したセキュアな開発とAIコード生成をセキュアにする型レベルのアプローチで推奨する方法の中心です。

• AIの動作にガードレールを設ける。通常、有効な制御の単位はモデル全体ではなく、個々のアクションです。SnykがAIコーディングアシスタントのガードレールやAIエージェントセキュリティの未来に取り組むのもこのためです。エージェントが実行できることを制限し、その動作を監視して、必要な箇所に絞って介入します。

• AIシステムを、すでに管理している攻撃対象領域の一部として扱う。プロンプトインジェクション、機微情報の開示、その他のOWASP Top 10 for LLMsに挙げられたリスクは、アプリケーションのリスクであり、アプリケーションセキュリティの原則に沿って対処できます。前述のToxicSkillsの調査結果も、まさにこの種のリスクです。現実に存在し、測定可能で、すでに防御側が持つツールとプロセスで対処できます。

AI生成コードのセキュリティ確保は、多くのチームが最初に取り組むことです。Snykのこちらの短い解説では、実際の進め方をご紹介します。

Play Video: The Secret to Secure AI Code

AIコードを安全に保つ秘訣（AIが生成するコードの量と速度が増す中で、その安全性を保つ方法）

「AIは安全」か「AIは危険」か、どちらかを選ぶ必要はありません。これは、セキュリティ業界があらゆる強力なテクノロジーに対して取ってきたのと同じアプローチです。リスクがあることを前提に、管理するための多層防御を構築し、連携して脆弱性を開示・修正し、防御側が適切なツールを使える状態を保つのです。

セキュリティチームと開発者が押さえておくべきこと

1. 特定のホスト型モデルを単一障害点にしない。 重要なシステムには、モデルの冗長性と柔軟なフォールバックを組み込みましょう。自分で制御できない可用性は、計画に織り込むべきリスクです。

2. 技術スタック内でAIが使われている箇所を把握する。 資産を検出できなければ、影響範囲を判断することはできません。どのサービス、パイプライン、製品が、どのモデルやAIコンポーネントに依存しているかを把握しましょう。

3. AI生成コードは例外ではなく、標準でスキャンする。 AI生成コードの量と速度を考えると、コード作成時やプルリクエスト時にスキャンし、自動修正することが、現実的に対応し続けるための方法です。

4. キルスイッチよりも、ガードレールとモニタリングを優先する。 AIの行動を制限して監視し、必要な範囲に絞って介入しましょう。全面的な停止は、本当に必要な場合に限り、どのような場合に実施するかをあらかじめ定めておきます。

5. 協調的な脆弱性開示を実践し、他者にも求める。 発見を把握できなければ、修正することもできません。根拠と修正計画を求めるとともに、同じ対応を他者にも提供しましょう。

まとめ

Fable 5とMythos 5の停止については、法的・政治的な観点から今後もしばらく議論が続くでしょう。政府が稼働中のモデルを停止できるべきかについても、意見は分かれるはずです。セキュリティチームにとって、長く活かせる教訓は、どちらの意見が正しいかに左右されません。争点の中心にある機能は、防御側が日常的に活用しているものです。そして、世界中で利用可能だった依存先が数時間以内に停止されたという現実は、冗長性と可視性を確保する必要性を具体的に示しています。

強力で、攻撃にも防御にも使える機能は、今に始まった問題ではありません。セキュリティ分野には、すでにそのための定石があります。特定のプロバイダーを単一障害点にしないだけのモデル冗長性を確保し、技術スタック内でAIが使われている箇所を把握し、AI生成コードが取り込まれる段階でスキャンし、キルスイッチに頼るのではなくAIの行動にガードレールを設け、双方で協調的な脆弱性開示を実践することです。これを継続的に実践することで、チームはデュアルユースのリスクに対応しながら開発を続けられます。Snykをはじめとするセキュリティツールも、その取り組みを支えます。それが、互いを補完し合う最善の道です。