AI版CVSS誕生か・Anthropicが脆弱性4軸評価を提案・8/1に次の期限

なぜ「共通言語」が要るのか——具体例で考える
いま、あるモデルが「ジェイルブレイクされた」というニュースが出ても、その一言だけでは深刻度が分からへん。「ちょっとした不適切発言を引き出せた」のか「重要インフラを攻撃するコードを吐かせられた」のか、天と地ほど差があるのに、同じ「ジェイルブレイク」で語られてしまう。今回の4軸は、これをソフトウェア業界のCVSS（脆弱性を0〜10で採点する国際標準）のように整理する試みだ。たとえば「①能力獲得は小さいが④発見容易性が高い」なら広く知られる前に潰すべき、「①能力獲得が大きく③武器化も容易」なら最優先で即対応、といった具合に、企業や政府が優先順位を揃えて動ける。買い手にとっても「そのモデルはどれくらい危ういか」を頭一つの見出しでなく構造で判断できるようになる。

最severeクラスには即対応——24時間監視とHackerOne賞金
最も深刻なクラス（重要インフラに実害を与えるレベル）には、深刻度が確認され次第すぐに暫定対策を講じるとしている。加えて、ジェイルブレイクの報告チャネルを24時間監視する専任チームを設置。研究者が新たなFable 5のジェイルブレイクを報告できるHackerOne（バグ報奨金）プログラムも立ち上げた。復活のきっかけを作ったAmazonの脆弱性報告に対しては、その手法を99%超の確率で遮断する新分類器を導入済みだ。「見つけて→採点して→優先度をつけて対処する」という一連の流れを、業界横断で回そうという設計だ。

正直な留保——これは「Anthropicの提案」であって既成事実ではない
ここは冷静に線を引いておきたい。この枠組みは、あくまでAnthropic自身のブログ投稿に基づくものだ。AI Weeklyが的確に指摘する通り、99%という分類器の遮断率も、MicrosoftとGoogleが実際に自社製品へどこまで採用するかも、独立検証されたわけやない。投稿はフレームワークの主導執筆者を明示せず、公開時期も定めず、参加ラボの意見が割れたときの調停方法も説明していない。つまり現時点では「方向性の提示」であって、確立した標準ではない。とはいえ、CVSSのような共通尺度がAIにできれば、買い手が脆弱性を語る土台が上がるのは確かで、意義そのものは大きい。

Anthropicが負った3つの継続義務
NBC Newsが確認したLutnick書簡によれば、Anthropicは①セキュリティ問題を自ら能動的に探索する、②Mythos・Fable・将来モデルのプロトコル・基準・リリースで政府と協調する、③悪意ある利用を発見したら米政府に報告する、という3点に合意した。さらに、国家安全保障に関わる能力を大きく前進させるモデルについては、指定政府パートナーに「事前アクセス」を提供し、独立した能力評価と安全装置テストを受け入れると表明。技術スタッフを政府評価者と並走させるとも述べている。「解除」と引き換えに、継続的な関与が制度として組み込まれた形だ。

因果関係を整理——なぜ輸出規制という『強制手段』だったのか
ここは深掘りする価値がある。6月2日の大統領令は、フロンティアモデルを公開前に政府が審査する「任意の」経路を作った。だがFable 5はその経路を通っていない。にもかかわらず政府が動けたのは、輸出規制という「強制手段」を使ったからだ。The Hacker Newsが鋭く指摘する通り、これは「ワシントンがフロンティアモデルに素早く介入したいとき、拘束力ある正式な手続きがまだ存在せず、即席の手段しかない」ことの証左だ。任意の枠組みと強制の現実の間にギャップがある——このズレが、19日間の混乱の制度的な根っこだった。

次の焦点は8月1日——「どのモデルが審査対象か」を決める機密ベンチ
では、そのギャップはどう埋まるのか。鍵は8月1日だ。この日までにNSA・財務省・CISAが、「どのモデルが審査対象（covered）に該当するか」を判定する機密ベンチマークを策定する期限となっている。これが定まれば、「任意」だった事前審査が、対象モデルには実質的な前提条件になっていく。Anthropicが今回受け入れた事前アクセスの約束は、その制度化を先取りした動きとも読める。復活は事件の終わりではなく、フロンティアAIを「政府承認技術」として恒久的に制度へ組み込む過程の、一つの通過点だ。

なぜEUは「構造的に不利」なのか——3つの理由
innfactoryの分析が整理する通り、EU企業は三重の不利を負った。第一に、プロバイダ自身がプロセスを制御できない。Anthropicは口頭通知のみを受け、数時間内に対応を迫られた。第二に、制限が国籍に紐づくため、EUリージョンに技術配置していても外国人条項でEUユーザーが排除される。第三に、Mythosクラスはゼロデータ保持(zero-data-retention)オプションを持たず、そもそもGDPR準拠の利用が難しい。「最良のモデルを選んでその上にアプリを構築する」という常識的な発想が、いかに脆いか——2026年6月の出来事はそれを突きつけた。

答えは「モデル非依存・データ主権」——具体的な設計
では、どう備えるか。推奨される構成は、特定モデルに縛られない抽象化層(ゲートウェイ)を設けることだ。具体的には、複数モデルを同じインターフェースの裏で差し替え可能にし、あるモデルが止まっても別モデルに自動でフォールバックできる状態を作る。データ主権の面では、機密データを外部APIに出さずに済む選択肢(自社リージョン内で完結するモデルやオープンウェイト)を、用途に応じて併用する。「一社の一モデルに本番を賭けない」——これがEU企業の出した結論であり、Fable停止という実地の教訓から導かれた現実解だ。

両面で見る——「主権」にもコストとトレードオフがある
ただし、データ主権やモデル非依存を一方的に礼賛するのも公平やない。抽象化層を挟めば運用は複雑になり、各モデルの個性(得意分野・APIの癖)を活かしきれない場合もある。オープンウェイトや自社運用は制御と機密性を得られる一方、最新フロンティアの性能や安全ツールの成熟度では商用API勢に劣ることが多い。つまり「主権」と「性能・利便性」はトレードオフの関係にあり、どちらに振るかは用途とリスク許容度次第だ。全面的な脱・米国依存が正解とは限らず、重要度に応じて使い分ける冷静な線引きが要る。