最先端 AI は、誰に使わせるかだけでは足りない

by

Anthropic は 2026 年 6 月 12 日、米政府から Fable 5 と Mythos 5 への外国籍者アクセスを停止する export control directive を受けたとして、両モデルを全顧客向けに無効化すると発表した[1]。Reuters も、米政府当局者による確認として、商務省が外国籍者アクセスを制限する指令を出したと報じている[2]。WIRED.jp も同じ事案を、米政府命令に従った提供停止として報じた[3]。

この出来事は、一見すると「米政府が危険な AI を止めた」という話に見える。最先端モデルがサイバーセキュリティ上の高い能力を持ち、その能力が国家安全保障上の懸念を生み、政府がアクセス制限を求めた。ここまでなら、輸出規制や安全保障管理の延長として理解できる。しかし、この読み方だけでは、今回の事案で本当に重要な構造を取り逃がす。なぜなら、政府が求めたのは単なる停止ではなく、「誰を止めるか」という境界を持った停止だったからである。

政府命令の単位は「外国籍者」だった。ところが Anthropic は、外国籍者だけを切り分けて停止するのではなく、Fable 5 と Mythos 5 を全顧客向けに無効化した。この差に注目する必要がある。もし制度上の境界をそのまま実装できるなら、措置は「外国籍者のアクセス停止」にとどまるはずである。しかし実際には、外国籍者だけを即時に、漏れなく、過剰に排除しすぎず、後から説明可能な形で止めることが難しかった。そのため、制度上は細い境界だったものが、運用上は全停止という粗い境界に置き換わった。

本稿が扱うのは、このずれである。最先端 AI の問題は、もはや「強いモデルを作ってよいか」だけではない。また、「誰に使わせるべきか」という政策判断だけでも足りない。より重要なのは、国家、企業、クラウド、API、社員、顧客、監査の各層をまたいで、能力利用の意味境界を保存できるかである。ここでいう意味境界とは、「誰が使ってよいか」「どの用途なら許されるか」「どの状態なら停止すべきか」という制度上の意味が、実際のシステム操作、アクセス権限、ログ、契約、運用手順の中でも同じ意味を保つことである。

この問題は、AI に固有の話であると同時に、より一般的な情報システムの問題でもある。ある層で与えられた意味は、別の層へ移るときに失われやすい。政策文書では「外国籍者」と書ける。契約書では「承認済み組織」と書ける。セキュリティ文書では「許可された利用」と書ける。しかし、実際のシステムは、その語をそのまま理解しない。システムが扱うのは、ユーザー ID、組織アカウント、API キー、モデル ID、権限ロール、ログ保持、リージョン、契約状態、監査証跡である。制度上の意味が、これらの実装単位へ正しく変換され、さらに運用中にも保たれなければ、境界は宣言されたほどには機能しない。

したがって、本稿の中心命題は次である。最先端 AI は、誰に使わせるかだけでは足りない。能力を配分するなら、その配分を支える意味境界を実装しなければならない。そして、その実装は単なるアクセス制御ではない。国家が定義した利用資格を、企業が運用可能な権限体系へ写し、クラウドや API の提供条件へ落とし込み、社員や顧客の権限に反映し、後から監査できる状態に保つことである。最先端 AI の統治は、モデルの安全性だけでなく、意味を壊さずに能力を流通させる設計能力を問う段階に入っている。

1. 問題は「停止」ではなく、境界を実装できなかったことである

最初に確認すべきなのは、今回の事案で起きたことの粒度である。Anthropic の声明によれば、米政府の指令は、Fable 5 と Mythos 5 への外国籍者アクセスを停止するものだった。しかも対象は、米国外の外国人だけでなく、米国内の外国籍者や Anthropic 社員にも及ぶと説明されている。この時点で、問題は単なる国別アクセス制御ではない。国境を越えた利用者だけを止めれば済む話ではなく、米国内にいる外国籍者、企業内の社員、顧客組織内の利用者、委託先、クラウド上のアカウント、API 経由の呼び出しがすべて関係してくる。

ここで重要なのは、「外国籍者」という言葉が、制度上は一つの分類に見えても、実装上は一つの分類ではないという点である。国籍は、通常のログインシステムが自然に持っている属性ではない。多くの業務システムは、ユーザーのメールアドレス、所属組織、支払い契約、ロール、利用リージョン、API キー、認証プロバイダーなどを扱う。しかし、国籍、在留資格、雇用関係、委託関係、実際の操作者、組織内での権限委譲まで、常に正確に保持しているとは限らない。制度上の境界が細かくなるほど、それをシステム内のどの属性で表現するのかが難しくなる。

たとえば、「米国外からのアクセスを止める」だけなら、IP アドレス、リージョン、請求先住所、法人所在地などを使って近似できる。しかし「外国籍者を止める」はそれとは異なる。米国内にいる外国籍者は IP アドレスでは判別できない。米国企業の社員であっても、国籍によって扱いが変わりうる。法人としては承認された顧客であっても、その組織内の全員が同じ資格を持つとは限らない。さらに API 利用では、実際に操作している個人が見えず、組織アカウントやサービスアカウントだけが見える場合もある。ここで制度上の「誰」は、実装上の「どのアカウントか」「どのキーか」「どの権限か」という問いへ分解される。

この分解が不完全であれば、二つの失敗が起こる。一つは過少制御である。本来止めるべき利用者が、組織アカウントや委託先経由でアクセスできてしまう。もう一つは過剰制御である。本来は利用を許されるはずの顧客や社員まで止めてしまう。Anthropic が全停止を選んだという事実は、少なくともその時点で、細い境界を安全に切り分けるより、粗い境界で全体を止めるほうが確実だと判断されたことを示している。

層 制度上の意味 実装上の問い
国籍 外国籍者かどうかがアクセス可否に関わる。 国籍情報を誰が確認し、どの時点で更新し、どの認証システムや顧客管理システムへ反映するのかが問われる。
所在地 米国内外の利用場所が規制対象の判断に関わる。 IP アドレス、請求先、法人所在地、実際の操作者の場所が一致しない場合に、どの情報を優先するのかが問われる。
法人 承認された組織かどうかが利用資格に関わる。 法人アカウント内の個別利用者、子会社、委託先、外部協力者、共同研究者をどう扱うかが問われる。
社員 提供企業の内部関係者であっても、国籍や担当業務によってアクセス可否が変わりうる。 開発者、評価担当者、サポート担当者、営業担当者、委託先エンジニアの権限をどこまで分けるのかが問われる。
API 特定モデルの利用可否が能力アクセスを左右する。 どの API キーがどのモデル ID を呼べるのかを、顧客、用途、地域、組織属性ごとに即時に切り替えられるかが問われる。
クラウド モデルがどの環境に配備されるかが、アクセス制御と監査可能性に関わる。 リージョン、テナント、ネットワーク境界、鍵管理、運用担当者の権限をどこまで分離できるかが問われる。
監査 許可された利用であったかを後から説明できなければならない。 誰が、いつ、どのモデルを、どの権限で、どの目的に近い操作として使ったのかを記録し、追跡できるかが問われる。

この表が示すように、政府命令は一文で書けるが、実装は一文では済まない。制度の語彙は「外国籍者」「承認組織」「国家安全保障」といった抽象語で動く。一方、システムは、ユーザー ID、権限、トークン、モデル ID、ログ保持、リージョン、契約状態で動く。この二つの間に変換層がなければ、制度上の境界は運用上の境界にならない。

ここでいう変換層とは、単なる管理画面や設定項目ではない。制度上の条件を、実行時に判定できる属性へ変換し、その属性を認証、認可、モデル選択、ログ保存、アラート、緊急停止、顧客通知に接続する仕組みである。たとえば「承認済み組織だけに提供する」という条件は、顧客管理データベースに承認状態を持たせるだけでは足りない。その状態が API の認可判定に反映され、モデルルーティングで拒否され、例外処理が記録され、サポート担当者が手動で回避できないようになっていなければならない。意味境界は、文書に書かれた時点ではなく、実行時に破られない形で保たれたときに初めて境界になる。

この構造を見落とすと、今回の事案は「AI が危険だから止められた」という単純な話になる。しかし、その読みでは、なぜ全停止が選ばれたのかを説明できない。危険だから止めるだけなら、対象モデルを止めたという結論だけで足りる。だが実際には、止めるべき対象が「全員」ではなく「外国籍者」だったにもかかわらず、全顧客停止になった。この差分こそが、制度境界と実装境界のずれを示している。

したがって、本稿の出発点は「AI が止められた」ではない。より重要なのは、止める対象を細かく指定されたとき、その指定を実行環境の中で保存できなかったことである。最先端 AI の統治で難しいのは、危険な能力を止めることそのものではない。止めるべき対象を、実運用上の境界として正確に表現し、その境界を複数の層にまたがって失わせないことである。

この視点に立つと、今回の出来事は AI 規制の事例であると同時に、情報システム設計の事例でもある。制度は「誰に使わせるか」を決める。しかしシステムは、その決定を自動的には理解しない。国家が引いた境界を、企業が実装できなければ、境界は粗くなる。粗くなった境界は、過剰な停止か、抜け穴のある制御か、どちらかに傾く。最先端 AI の統治は、この粗さをどこまで小さくできるかにかかっている。

2. Fable 5 と Mythos 5 は、普通のチャットモデルではなかった

この事案を理解するには、Fable 5 と Mythos 5 がどのような能力として説明されていたかを見る必要がある。単に「新しいチャットモデルが公開された」と考えると、問題の焦点を誤る。Anthropic は 2026 年 6 月 9 日、Fable 5 と Mythos 5 を発表し、Fable 5 を一般利用向けに安全策を加えた Mythos-class モデルとして説明した。一方で Mythos 5 は、Fable 5 と同じ基盤モデルを使いながら、一部の安全制限を外したサイバー防御向けモデルとして位置づけられていた[4]。つまり、両者は完全に別種の製品ではない。同じ能力を、異なる安全制約、異なる利用者、異なる提供範囲のもとで扱う関係にある。

この関係は、本稿の主題に直接つながる。もし Fable 5 と Mythos 5 が別々の能力であれば、問題は「危険なほうだけを止める」という単純な分類に近づく。しかし実際には、同じ基盤能力をどの制約で包むか、どの利用者に渡すか、どの領域では拒否し、どの領域では許可するかが問題になっている。ここでは、モデルの能力そのものと、その能力にかぶせる安全制御、さらにその能力を使える主体が分離されている。これは、最先端 AI が単なる製品ではなく、能力、制約、利用資格の組み合わせとして提供され始めていることを示す。

Anthropic は Project Glasswing を、重要なソフトウェアを AI 時代に防御する取り組みとして説明している[5]。さらに、同社は Project Glasswing の拡大について、参加組織がコードベースをスキャンし、多数の重大なセキュリティ欠陥を見つけていると説明したうえで、サイバー能力は防御者にも攻撃者にも力を与えるため、強く精密な安全策が必要だと述べている[6]。UK AI Security Institute も、Claude Mythos Preview のサイバー能力を評価した文書を公開している[7]。

ここで重要なのは、能力が二面性を持つことである。ソフトウェア脆弱性を発見できる能力は、防御者にとっては価値がある。未発見の脆弱性を早く見つけ、修正し、重要インフラやオープンソースソフトウェアを守ることができるからである。しかし同じ能力は、攻撃者にとっても価値がある。未発見の不整合を見つける速度が上がれば、攻撃準備の速度も上がる。防御に役立つ能力と攻撃に役立つ能力は、しばしば別々の能力ではない。同じ観測能力、同じ推論能力、同じ自動化能力が、どの履歴へ接続されるかによって意味を変える。

能力 防御側の意味 攻撃側の意味
脆弱性探索 既存システムの弱点を早く見つけ、修正の優先順位を付けられる。 未修正の弱点を早く見つけ、攻撃対象を絞り込める。
コード理解 大規模コードベースの依存関係、危険な実装パターン、境界条件の見落としを整理できる。 攻撃に利用できる経路、例外処理の抜け、入力検証の弱い箇所を探索しやすくなる。
長時間作業 人間が継続的に追うことの難しい調査、比較、再検証を補助できる。 探索、試行、絞り込みを反復し、攻撃準備の作業量を下げうる。
自動化 分類、再現手順の作成、修正候補の生成、影響範囲の確認を支援できる。 調査から実用化までの時間を短縮し、少人数でも広い対象を試せるようになる。

この表が示すように、問題は「よい能力」と「悪い能力」が最初から分かれていることではない。脆弱性探索、コード理解、長時間作業、自動化はいずれも、防御側にとって必要な能力である。同時に、それらは攻撃側にとっても利用価値を持つ。したがって、この種のモデルを扱うときには、能力そのものを善悪で分類するだけでは足りない。重要なのは、その能力がどの利用者に渡り、どの環境で使われ、どの記録に残り、発見された不整合が修正へ向かうのか、攻撃へ向かうのかである。

ここで「観測能力」という語を導入できる。観測能力とは、世界にすでに存在している不整合、欠陥、依存関係、境界条件の破れを、見える状態に変える能力である。脆弱性は、AI が作り出す前から存在している場合がある。危険な依存関係や誤った前提も、コードや運用の中にすでに埋め込まれていることがある。強力なモデルは、それらを新たに発生させるだけでなく、従来より速く、広く、高い精度で見つける。この点で、最先端 AI は単なる回答生成器ではなく、潜在的不整合を可視化する観測器として振る舞う。

既稿「Claude Mythos は世界をどう変えたのか」では、AI を、世界の中にすでに存在する不整合、依存関係、意味境界の破れ、制度上の観測限界を、より速く、広く、高解像度で露出させる観測器として整理した[8]。本稿は、その後続に位置づく。既稿で扱ったのは、AI によって何が見えるようになるのかだった。本稿で扱うのは、その見えるようになったものを、誰が、どの条件で、どの責任のもとで扱うべきかである。

この接続を明確にすると、Fable 5 と Mythos 5 の停止は、単なるモデル提供停止ではなくなる。観測能力が高くなるほど、その能力は防御者に渡したいものになる。しかし、同じ能力を無差別に渡せば、攻撃側にも観測速度を与えることになる。だからこそ、問題は「能力を持つべきか」から「能力をどの境界で配分するか」へ移る。さらに、その境界は宣言するだけでは足りない。前章で見たように、国籍、法人、API、クラウド、社員権限、監査の各層で保存されなければ、能力配分は実効性を持たない。

したがって、Fable 5 と Mythos 5 が普通のチャットモデルではなかったという事実は、本稿全体の前提になる。普通のチャットモデルなら、提供停止はサービス運用上の問題として読める。しかし、脆弱性探索や重要インフラ防御に関わる観測能力を持つモデルであれば、提供停止は能力配分の問題になる。そして、その能力配分は、誰に使わせるかという政策判断だけでなく、その判断を実装層で保てるかという意味境界の問題になる。

3. 「誰に使わせるか」は、政策判断だけでは完結しない

最先端 AI の利用を制限するとき、最初に見える問いは「誰に使わせるか」である。米国組織には使わせるのか。外国企業には使わせるのか。重要インフラ事業者には使わせるのか。研究者には使わせるのか。防御目的なら使わせるのか。これらは避けて通れない問いである。能力が危険にも有益にもなりうる以上、利用者、用途、組織、場所を区別せずに一律提供することは難しくなる。

しかし、「誰に使わせるか」という問いだけでは不十分である。なぜなら、それはまだ政策判断の段階にとどまっているからである。国家や規制当局は、「承認された組織には使わせる」「外国籍者には使わせない」「重要インフラ防御には使わせる」といった境界を言葉で定義できる。だが、その境界は、定義された時点ではまだ実効性を持たない。実効性を持つのは、その境界が実際の認証、認可、契約、ログ、監査、運用手順に変換されたときである。

ここで区別すべきなのは、政策上の利用資格と、実装上のアクセス権限である。政策上の利用資格とは、「この主体は使ってよい」「この用途なら許される」「この条件を満たす場合だけ提供できる」という判断である。一方、実装上のアクセス権限とは、あるユーザー、法人アカウント、API キー、サービスアカウント、社員ロールが、実際に特定モデルを呼び出せるかどうかを決める仕組みである。前者は意味の分類であり、後者は実行時の判定である。この二つが接続されなければ、利用資格はただのラベルにとどまる。

たとえば、政府が「承認された米国組織には使わせてよい」と判断したとする。この判断は、一見すると明確である。しかし、実際の組織は単純な一枚岩ではない。組織の中には、米国籍社員、外国籍社員、外部委託先、子会社、海外拠点、共同研究者、クラウド運用担当者、サポート担当者がいる。法人としては承認されていても、その法人に属する全員が同じ資格を持つとは限らない。反対に、個人としては米国籍であっても、利用目的や所属組織が承認範囲外である場合もあり得る。

このため、利用資格は単なる名簿管理ではない。制度上の分類を、実行環境へ移されるべき条件として扱わなければならない。外国籍者、承認組織、重要インフラ、防御目的、監査対象、提供リージョン、データ保持、緊急停止といった語は、政策文書や契約書では抽象的な分類である。しかしシステム上は、本人確認、組織確認、アクセス制御、権限委譲、モデル切替、ログ保持、監査証跡、例外処理の条件になる。

分類 政策判断としての意味 実装条件としての意味
外国籍者 国籍によって利用可否を分ける対象である。 本人確認、社員属性、顧客組織内の利用者属性、委託先属性を判定可能な形で保持する必要がある。
承認組織 国家や提供企業が信頼できると判断した組織である。 法人アカウント、子会社、部署、利用者グループ、外部協力者の範囲を明確にし、認可判定へ反映する必要がある。
防御目的 脆弱性修正、重要インフラ保護、セキュリティ評価などの正当利用である。 用途申告、利用ログ、出力の扱い、検出結果の報告先、攻撃転用を避ける運用条件を組み合わせる必要がある。
監査対象 許可された利用だったかを後から確認すべき対象である。 誰が、いつ、どのモデルを、どの権限で、どの組織として使ったかを追跡できるログを残す必要がある。

この変換に失敗すると、三つの失敗が起きる。第一に、過剰停止である。本来は一部の利用者だけを止めればよいのに、切り分けられないため全体を止める。第二に、過少制御である。本来止めるべき利用者や経路が、組織アカウント、サービスアカウント、委託先、手動運用、例外設定を通じて残る。第三に、監査不能である。アクセスできたこと、またはアクセスできなかったことは分かっても、それが許可された利用だったのか、禁止されるべき利用だったのかを後から説明できない。

失敗 起きること 問題になる点
過剰停止 本来は許可できる利用まで止まる。 防御、研究、重要インフラ保護、正当な企業利用まで失われる。
過少制御 本来は止めるべき利用が残る。 規制の目的が達成されず、危険な能力が想定外の経路へ流れる。
監査不能 誰が何を使ったかを後から説明できない。 違反があったかどうかだけでなく、許可された利用だったかどうかも判断できなくなる。

今回の全停止は、公表情報の範囲では過剰停止に近い。政府が求めた境界は「外国籍者アクセスの停止」だった。しかし、Anthropic は Fable 5 と Mythos 5 を全顧客向けに無効化した。これは、細い境界を短時間で安全に実装するより、粗い境界で能力全体を止めるほうが、法令遵守上は確実だったという判断を示している。ここで起きているのは、危険な能力の停止であると同時に、制度上の分類を実装上のアクセス制御へ写しきれなかったことによる停止である。

この点を誤解すると、AI 統治は「規制を強めればよい」「危険なモデルを止めればよい」という単純な話に見えてしまう。しかし、実際の統治はもっと細かい。危険な能力を全面禁止すれば、防御者もその能力を失う。反対に、利用を広く許せば、攻撃者にも観測能力を渡すことになる。したがって、必要になるのは、単純な禁止でも、単純な公開でもない。利用資格を定義し、その資格を実行環境の中で破れない形にすることである。

ここから、本稿の主要な問いが出てくる。AI 統治は、規制文言を書くことでは終わらない。規制文言の意味を、実行環境へ保存することが必要になる。国家が「この主体には許す」と言うだけでは足りない。企業は、それを実際のアクセス制御として実装し、運用中に境界が崩れないように保ち、後から説明できる形で記録しなければならない。

この意味で、最先端 AI の統治は、政策、法務、セキュリティ、クラウド運用、ID 管理、監査が分離したままでは成立しにくい。政策判断は、実装条件へ翻訳されなければならない。実装条件は、運用手順へ接続されなければならない。運用手順は、監査可能な記録として残らなければならない。どこか一箇所で意味が失われれば、「誰に使わせるか」という判断は、実際の能力配分を制御できなくなる。

4. 意味境界は、宣言するだけでは保存されない

ここまで見てきた問題は、AI 統治だけに固有のものではない。より一般的には、ある層で与えられた意味が、別の層へ移ったときにも同じ意味として保たれるか、という問題である。政策文書では「外国籍者は禁止」と書ける。企業契約では「承認組織に限る」と書ける。運用規程では「監査対象」と書ける。しかし、それらの意味は、API、クラウド、社員権限、顧客アカウント、ログ保存、サポート運用を通過するときに、自然に保存されるわけではない。

この構造は、既稿で扱った Linux カーネル脆弱性の議論と接続できる。既稿「CVE-2026-31431 について徹底的に考える」では、Copy Fail の本質を、読み取り専用であるはずの page cache が、暗号処理文脈では出力先として扱われる構造として整理した[9]。ここで壊れたのは、単なるファイル権限ではない。上位レイヤーでは「読み取り専用」として扱われるべきデータが、下位レイヤーの処理を通過したときに、書き込み可能な出力先として扱われてしまった。つまり、「読み取り専用」という意味が、処理層をまたいで保存されなかったのである。

このとき重要なのは、各部品がそれぞれ単独で危険だったとは限らない点である。page cache、暗号 API、zero-copy、in-place 処理は、それぞれ性能や効率のために意味を持つ仕組みである。しかし、それらを組み合わせたとき、ある層で「入力」として渡されたものが、別の層では「出力先」として扱われることがある。ここで、入力であること、共有されていること、読み取り専用であること、といった意味が保たれなければ、最適化は脆弱性へ変わる。

既稿「Dirty Frag が強化した不変原理」では、この教訓をさらに一般化した。Dirty Frag は Copy Fail と入口が異なる。しかし、上位レイヤーの read-only、shared、input という意味が、下位レイヤーの最適化、共有、断片化、in-place 処理を通過しても保存されなければならない、という原理を強化する事例として読める[10]。入口がファイルシステムであれ、ネットワーク処理であれ、暗号処理であれ、問題の中心は同じである。ある文脈で与えられた意味が、別の文脈へ渡ったときに壊れてはならない。

ここでいう不変原理とは、処理の途中で変わってはならない条件のことである。本稿の文脈では、「読み取り専用のものを破壊的に更新してはならない」「共有されているものを単独所有のように扱ってはならない」「入力として渡されたものを出力先にしてはならない」といった条件がそれに当たる。これらは、単なる実装上の細則ではない。システム全体が安全に動くために、層をまたいでも保たれなければならない意味である。

比較対象 上位レイヤーの意味 失敗の形 一般化
Copy Fail 読み取り専用由来の page cache は出力先にしてはならない。 別文脈へ渡った後に、書き込み可能な出力先として扱われる。 安全な意味は、暗号処理や in-place 処理を通過しても保存されなければならない。
Dirty Frag 共有された断片は、下位処理で破壊的に更新してはならない。 ネットワーク処理や暗号処理を経て、共有データの意味が崩れる。 入口が変わっても、意味保存の原理は変わらない。
最先端 AI 承認された主体、禁止された主体、監査対象の利用を区別しなければならない。 国籍、法人、API、クラウド、社員権限の間で分類が崩れる。 制度上の意味も、実装層を通過して保存されなければならない。

この接続は、単なる比喩ではない。どちらも、意味が複数の層を通る問題である。Linux カーネルでは、ファイルシステム、ページキャッシュ、暗号 API、ネットワーク処理をまたぐうちに、読み取り専用、共有、入力といった意味が失われることがある。AI 統治では、政府命令、企業契約、社員権限、顧客アカウント、API、クラウド、ログ監査をまたぐうちに、外国籍者禁止、承認組織限定、監査対象という意味が失われることがある。

違いは、前者では意味がメモリやバッファに関係し、後者では意味が人、組織、用途、責任に関係する点である。しかし、構造は似ている。ある層では明確に区別されていたものが、別の層では別の単位へ変換される。読み取り専用の page cache は、暗号処理ではバッファとして見える。承認済み組織は、API では組織アカウントとして見える。外国籍者は禁止という条件は、クラウド運用では社員ロール、委託先権限、サポート権限、サービスアカウントの問題として現れる。この変換過程で意味が失われれば、宣言された境界は実際の境界ではなくなる。

したがって、安全性とは、危険な操作を禁止すると宣言することだけではない。禁止という意味が、複数の層を通過しても失われないことである。同じように、許可もまた宣言だけでは足りない。承認された主体にだけ使わせるという意味が、認証、認可、モデル選択、ログ保存、監査、緊急停止の各段階で保たれなければならない。禁止と許可は、文書上では対になる語である。しかしシステム上では、どちらも実装され、運用され、監査されなければ効力を持たない。

この観点を入れると、AI 統治は法令や倫理だけの話ではなくなる。もちろん法令や倫理は必要である。しかし、それらは境界を定義するだけであって、境界を保存するわけではない。境界を保存するのは、ID 管理、権限設計、API 認可、クラウド分離、ログ設計、例外処理、サポート権限、監査手順である。つまり、最先端 AI の統治は、抽象的な規範と具体的なシステム設計を切り離したままでは成立しない。

ここから、次の論点が見えてくる。Fable 5 と Mythos 5 の問題は、単に「危険な能力を止めるかどうか」ではない。危険にも有益にもなりうる能力を、どの主体に、どの条件で、どの責任のもとで渡すか。そして、その条件が複数の層を通過しても失われないようにできるかである。意味境界が保存されなければ、能力配分は粗くなる。粗くなった能力配分は、全停止か、抜け穴のある提供か、どちらかへ傾く。

5. 停止から再配分へ移るとき、能力は商品ではなく資格付き資源になる

今回の事案を「停止」の話だけで終えると、本質を取り逃がす。重要なのは、停止の後に Mythos 5 の一部再開が報じられたことである。Reuters は、米政府が Anthropic に対し、100 を超える trusted U.S. organizations へ Claude Mythos 5 を再展開することを認めたと報じている[11]。WIRED も、選ばれた米国企業や政府機関に対して Mythos へのアクセスが認められたと報じた[12]。Reuters はさらに、Fable 5 の復旧についても協議が進んでいると報じている[13]。

この流れを見ると、起きていることは単なる禁止ではない。最初の段階では、Fable 5 と Mythos 5 は広く止められた。しかし次の段階では、Mythos 5 が一部の承認された主体へ戻される方向に動いた。つまり、能力は「危険だから全員から取り上げる」対象としてだけ扱われたのではない。「誰なら持ってよいか」を選んだうえで、限定的に再配分される対象として扱われたのである。

ここで構造が変わる。通常の製品停止であれば、問題はサービスを再開するかどうかである。障害が直れば再開する。安全対策が済めば再開する。需要があれば販売を戻す。しかし、最先端 AI の場合、再開は単なる復旧ではない。誰に戻すのか、どの組織なら信頼できるのか、どの用途なら許容できるのか、どのログや監査条件を付けるのかが同時に問われる。停止から再開へ移る過程で、能力は市場で自由に売られる商品ではなく、資格に応じて配分される資源として扱われ始める。

この変化は、通常のソフトウェアの発展方向とは異なる。多くのソフトウェアでは、性能が上がるほど、利用範囲は広がりやすい。機能が増え、価格が下がり、導入事例が増え、API やプラグインによってエコシステムが広がる。企業にとっては、より多くの顧客に届けることが成長につながる。しかし frontier AI、すなわち社会的リスクを伴うほど高い能力を持つ最先端 AI では、性能向上がそのまま普及拡大へ向かうとは限らない。能力が一定の閾値を超えると、防御能力だけでなく攻撃能力も上がる。すると、性能が高いこと自体が、利用者を選別する理由になる。

観点 通常のソフトウェア frontier AI
性能向上 機能の拡張、利便性の向上、処理効率の改善として評価される。 防御能力と攻撃能力の両方を引き上げるものとして評価される。
提供範囲 利用者を増やすことが成長と普及につながる。 利用者を選別することが安全保障、法令遵守、監査可能性に関わる。
再開条件 障害解消、品質改善、契約条件の整理によって再開される。 承認主体、利用目的、国籍、組織属性、監査条件、政府判断によって再開範囲が決まる。
企業価値 機能、価格、普及速度、エコシステム、開発者体験が重要になる。 能力、アクセス制御、監査、政府対応、停止可能性、限定配備能力が重要になる。

この表が示すように、frontier AI では「性能が高いほど広く売る」という単純な市場原理が崩れる。高性能であることは、商業的な魅力であると同時に、規制上の負荷でもある。多くの顧客に使わせれば売上は伸びる。しかし、使わせる相手を誤れば、国家安全保障上の問題、輸出管理上の問題、契約上の問題、監査上の問題が生じる。したがって、能力の価値は、能力そのものだけでなく、その能力を安全に、選別的に、説明可能な形で配れるかによって決まる。

ここで「資格付き資源」という見方が必要になる。資格付き資源とは、料金を払えば誰でも使える商品ではなく、一定の資格、条件、監査、責任を満たす主体だけが使える資源である。最先端 AI がこの性格を帯びると、利用可否は単なる購買能力では決まらない。組織が承認されているか。利用目的が防御や研究として妥当か。国籍や所在地の条件を満たすか。アクセス制御が実装されているか。ログが残るか。政府が許すか。これらの条件が、能力への入口になる。

このとき、企業が売っているものも変わる。従来の意味では、企業はモデルの性能、推論速度、価格、API の使いやすさを売る。しかし資格付き資源としての AI では、それだけでは足りない。企業は、能力を誰に渡し、誰には渡さず、どの条件で停止し、どの条件で再開し、後からその判断を説明できるかまで含めて提供しなければならない。つまり、提供されるのはモデル単体ではなく、能力配分の仕組みを含んだサービスである。

この変化は、前章で見た意味境界の問題と接続する。能力を資格付き資源として扱うなら、「承認された主体」「禁止された主体」「監査対象」「限定提供」という意味が、実装層で保たれなければならない。承認組織に戻すと言っても、その組織の中の誰が使えるのかを区別できなければならない。防御目的に限ると言っても、その利用が後から追跡できなければならない。政府が許す範囲で提供すると言っても、その範囲が API、クラウド、社員権限、顧客契約に反映されていなければならない。

したがって、Mythos 5 の一部再開は、単なるサービス復旧として読むべきではない。そこには、最先端 AI が「公開か禁止か」という二択を越えて、「誰に、どの条件で、どの責任のもとで使わせるか」という配分問題へ移っていることが表れている。能力そのものが価値であると同時に、その能力を配る境界を設計し、実装し、監査できることが価値になる。最先端 AI は、商品として売られるだけでなく、資格付き資源として管理される段階に入りつつある。

6. 境界管理は必要だが、中立ではない

既稿「AI 時代の危険な能力は、どこで止めるべきか」では、問うべきなのは能力を全面禁止するかどうかではなく、その能力が現実へ作用する境界をどこで確認し、記録し、必要に応じて止めるかであると整理した[14]。本稿は、その後続にある。既稿で扱ったのは、危険な能力をどこで止めるかという設計論だった。本稿で扱うのは、その境界を誰が引くのか、そしてその境界がどのような権力を持つのかである。

境界管理は必要である。Fable 5 や Mythos 5 のように、ソフトウェア脆弱性の発見、コード理解、長時間の探索、自動化に強い能力を持つモデルは、防御側にとって大きな価値を持つ。重要インフラ、オープンソースソフトウェア、政府システム、企業システムには、未発見の不整合が残っている可能性がある。防御者がそれを早く見つけ、修正へつなげられるなら、その能力を全面的に遠ざけることは、社会全体の安全性を下げる可能性がある。

しかし、同じ能力は攻撃側にも使われうる。脆弱性を早く見つける能力は、修正対象を見つける能力であると同時に、攻撃対象を見つける能力でもある。大規模コードベースを理解する能力は、保守や監査に役立つ一方で、入力検証の甘い箇所、例外処理の抜け、依存関係の弱点を探す助けにもなる。したがって、完全公開でも全面禁止でもなく、利用主体、用途、環境、記録、監査、停止条件を区切る必要がある。

ここまでは、境界管理の必要性である。問題は、その先にある。境界管理は、中立的な安全技術ではない。どこで止めるか、誰に使わせるか、どの組織を信頼するか、どの用途を正当とみなすかは、純粋に技術だけで決まるわけではない。そこには、国家安全保障、産業政策、同盟関係、企業競争、研究機関への信頼、重要インフラの保護責任が入り込む。

たとえば、trusted U.S. organizations という分類は、単に「技術的に安全な組織」を意味するだけではない。そこには、米国組織であること、米政府が信頼できると判断したこと、防御用途や重要インフラに関わること、国家安全保障上の利益に合うことが含まれる。誰を trusted と呼び、誰を foreign と呼び、誰に能力を配り、誰を境界の外側に置くかは、セキュリティであると同時に、政治的な配分でもある。

分類 安全管理としての意味 権力作用としての意味
trusted organization 監査、利用目的、運用体制を確認したうえで能力を渡せる組織である。 国家や提供企業が信頼に値すると認めた主体だけが、強い能力へアクセスできる。
foreign national 輸出管理や国家安全保障上、アクセス制限の対象になりうる利用者である。 同じ組織内にいても、国籍によって能力への距離が変わる。
defensive use 脆弱性修正、重要インフラ保護、セキュリティ評価などの正当利用である。 何を防御とみなし、何を攻撃準備とみなすかを、誰かが判断しなければならない。
approved access 事前に認められた条件のもとで、特定能力への利用を許可する状態である。 能力への入口が、料金や技術力ではなく、承認手続きによって左右される。

この表が示すように、境界管理には二つの面がある。一つは、危険な能力を無制限に流さないための安全管理である。もう一つは、能力へのアクセスを配分する権力作用である。安全のために境界を引くことは必要である。しかし、その境界は、誰を信頼できる主体とみなし、誰をリスクとみなし、誰に防御能力を集中させるかを同時に決める。

この構造は、DNA 合成の chokepoint と比較すると見えやすい。米国の Framework for Nucleic Acid Synthesis Screening は、合成核酸の注文について、配列スクリーニングや顧客スクリーニングを求める枠組みを示している[15]。International Gene Synthesis Consortium の Harmonized Screening Protocol v3.0 も、配列スクリーニングと顧客確認を組み合わせて、合成核酸の悪用リスクを下げる標準的な取り組みを示している[16]。HHS の Screening Framework Guidance も、合成核酸の悪用リスクに対応する best practice を示している[17]。

DNA 合成では、研究や知識そのものを禁止するのではなく、危険な配列が物理的な合成物として実体化する入口を管理する。ここでの chokepoint は、注文、配列スクリーニング、顧客確認、記録保存、自己証明といった手続きにある。もちろん、この仕組みも完全ではない。配列の意味は文脈によって変わる。顧客が正当かどうかの判断も難しい。国際的な抜け道もありうる。それでも、注文という比較的明確な入口があるため、どこで確認し、どこで止めるかを設計しやすい。

AI では、この入口がさらに分散する。最先端モデルへのアクセスは、単一の注文として現れるとは限らない。モデル重み、API、クラウド環境、社員権限、法人アカウント、サービスアカウント、委託先、ログ、サポート権限、プロンプト保持、モデルルーティングが能力の経路になる。危険な能力は、物として一箇所を通るのではなく、アクセス権限と実行環境の組み合わせとして流れる。

領域 止める対象 境界の作り方 難しさ
DNA 合成 危険な配列の合成注文、疑わしい顧客、目的不明の注文。 配列スクリーニング、顧客確認、注文記録、自己証明を組み合わせる。 配列の意味、顧客の正当性、国際的な抜け道をどう扱うかが問題になる。
最先端 AI 高いサイバー能力やデュアルユース能力へのアクセス。 モデル提供範囲、API 権限、法人承認、国籍確認、監査ログ、クラウド分離を組み合わせる。 能力がクラウド、社員、顧客、委託先、モデル ID、サービスアカウントをまたいで流れるため、単一の入口で止めにくい。

この比較から分かるのは、AI の chokepoint は、どこか一箇所の門ではないということである。DNA 合成では、少なくとも注文という比較的見えやすい入口がある。AI では、能力への入口が分散している。顧客が API を呼ぶ入口もあれば、社員が内部評価で触れる入口もある。クラウド運用担当者が関与する入口もあれば、承認組織内の利用者が組織アカウントを通じて呼び出す入口もある。したがって、AI の chokepoint は、単一の関門ではなく、能力が流れる経路全体に意味境界を保存する仕組みとして作られる。

ここで、境界管理の政治性がさらに強くなる。単一の門で止めるなら、判断主体は比較的明確である。しかし、能力の経路全体に境界を埋め込む場合、政府、AI 企業、クラウド事業者、顧客企業、監査主体、セキュリティ担当者がそれぞれ判断に関わる。どの情報を保持するか、どの属性を使って認可するか、どの例外を認めるか、どのログを残すかは、すべて能力配分の一部になる。

したがって、境界管理は避けられない。しかし、それを単なる安全設計としてだけ見ると不十分である。境界は、安全のために引かれる。同時に、能力を誰へ集中させ、誰を外側に置くかを決める。最先端 AI の統治では、危険な能力をどこで止めるかという問いに加えて、その境界を引く権限を誰が持ち、その判断がどのように記録され、異議申し立てや再評価の余地を持つのかまで問わなければならない。

7. 輸出管理は、物からアクセスへ広がる

今回の事案が示すもう一つの点は、輸出管理の対象が、物理的な物だけでなく、情報、アクセス、能力へ広がることである。輸出管理というと、半導体、製造装置、暗号装置、研究機材のように、国境を越えて移動する物を思い浮かべやすい。もちろん、その理解は間違っていない。高性能半導体や製造装置は、計算能力や産業基盤を左右するため、国家安全保障上の管理対象になってきた。しかし、現代の輸出管理は、物が国境を越える場面だけを見ているわけではない。

米国の Export Administration Regulations では、米国内で外国人へ controlled technology や source code を release することも、deemed export として扱われる[18]。BIS も、deemed export を、米国内で外国人に controlled technology や source code を共有または release することとして説明している[19]。ここで重要なのは、輸出が必ずしも荷物の移動を意味しないことである。技術やソースコードが外国籍者に開示されれば、物理的には米国内で起きた出来事であっても、規制上は輸出に準じて扱われうる。

この考え方は、今回の事案を理解するうえで重要である。問題は「海外へサーバーを置いたか」だけではない。米国内にいても、外国籍者が特定の技術や能力へアクセスすれば、それは規制上の問題になり得る。つまり、境界は地理的な国境だけでは決まらない。人の属性、情報の内容、アクセスの形、開示される能力の性質が、境界を作る。国境は消えたのではない。むしろ、国境の論理が、企業の内部システム、クラウド環境、社員権限、API アクセスの中へ入り込む。

この点を押さえると、Anthropic の事案で「米国内の外国籍者」や「Anthropic 社員」まで対象に含まれると説明された理由が見えやすくなる。国境を越えた通信だけが問題なら、米国内の社員や顧客組織内の利用者まで細かく分ける必要は薄い。しかし deemed export の考え方では、米国内であっても、controlled technology や source code が外国人に release されること自体が問題になりうる。AI モデルへのアクセスが、この枠組みとどのように対応するかには制度上の複雑さが残るが、少なくとも今回の事案は、地理的境界ではなく、人的属性と能力アクセスの組み合わせが統治対象になっていることを示している。

AI についても、物から能力への移行はすでに見えていた。2025 年 1 月の Framework for Artificial Intelligence Diffusion は、先端 AI モデルの model weights を規制対象として位置づけた[20]。model weights とは、モデルの出力を決める数値パラメータであり、強力な AI モデルの中核である。学習済みモデルの能力は、単なるプログラムの説明文や利用マニュアルではなく、この重みによって具体化されている。したがって、model weights を管理することは、モデルを動かす能力そのものを管理することに近い。

ただし、この rule は 2025 年 5 月に米商務省によって撤回されたため、現行制度としてそのまま扱うべきではない[21]。ここは慎重に区別する必要がある。重要なのは、撤回済みの制度を現在の根拠として使うことではない。重要なのは、先端 AI の中核要素である model weights が、国家安全保障上の管理対象として構想された事実である。つまり、米国の政策形成の中で、管理対象は半導体や製造装置だけでなく、AI モデルの中核能力そのものへ向かう可能性を示していた。

対象 従来の見え方 AI 時代の見え方
半導体 計算能力を生む物理的資源として管理される。 モデル訓練能力や大規模推論能力の上限を左右する入口として管理される。
製造装置 高度な半導体を作るための産業設備として管理される。 先端 AI を支える計算基盤を自前で作れるかどうかを左右する chokepoint として管理される。
source code 技術情報や実装内容として管理される。 能力の再現、改変、移植、制御回避につながりうる情報として管理される。
model weights ソフトウェアの内部パラメータとして見えにくい。 安全制御を外したり再利用したりできる中核資産として管理対象になりうる。
API アクセス オンラインサービスの利用権に見える。 高リスク能力への実時間アクセスとして、利用者資格、用途、監査条件と結びつく。
社員アクセス 企業内の権限管理に見える。 外国籍者、委託先、内部運用者が能力に触れる経路として管理される。

この表が示すように、AI 時代の輸出管理では、管理対象が段階的に広がる。最初に見えるのは、半導体や製造装置のような物理的な chokepoint である。次に、source code や model weights のように、能力を再現または移転できる情報が問題になる。さらに、クラウド API や社員アクセスのように、物もファイルも移動しないが、能力そのものへ触れられる経路が問題になる。

この変化は、企業にとって大きな実装負荷を生む。物の輸出であれば、出荷先、品目、数量、輸送経路、顧客を確認することが中心になる。しかし、アクセスの輸出では、誰が、どこから、どの権限で、どのモデルに、どの目的で触れるのかを継続的に判定しなければならない。しかも、利用者は法人単位とは限らない。社員、委託先、子会社、共同研究者、サービスアカウント、クラウド運用者が能力に触れる可能性がある。輸出管理がアクセス管理へ広がると、法令遵守は出荷管理ではなく、ID 管理、権限管理、ログ管理、監査管理の問題になる。

ここで起きているのは、国境線の消滅ではない。むしろ、国境線がシステム内部へ入り込むことである。かつて国境で止めていたものが、クラウドアカウント、API キー、社員権限、モデル ID、ログ監査の内部へ移る。国家は、荷物を止めるだけでなく、能力へのアクセスを止めようとする。ここに、AI 統治の実装負荷がある。

そして、この章の議論は、本稿の中心命題へ戻る。最先端 AI を誰に使わせるかは、外交、安全保障、産業政策の判断である。しかし、その判断は、アクセス制御として実装されなければ意味を持たない。輸出管理が物からアクセスへ広がるほど、制度上の境界は、システム内の属性、権限、ログ、監査へ翻訳される。能力利用の意味境界を保存できなければ、規制は過剰停止か過少制御へ傾く。だからこそ、最先端 AI の統治は、政策だけでなく、実装の問題になる。

8. frontier AI の安全枠組みは、能力閾値から運用統制へ移る

能力が一定の閾値を超えると、AI 企業は単に「安全に作る」と言うだけでは足りなくなる。どの能力を測るのか。どの水準を超えたら追加の安全策が必要なのか。どの段階で外部提供を制限するのか。どの条件で停止し、どの条件で再開するのか。これらをあらかじめ文書化し、実装し、運用中にも見直せるようにしなければならない。frontier AI の安全性は、モデル開発時の設計思想だけではなく、能力評価から配備後の統制までを含む管理体系へ移っている。

ここでいう能力閾値とは、モデルがある種類の行為をどの程度できるかを判断するための境目である。たとえば、サイバーセキュリティであれば、既知の脆弱性を説明できるだけなのか、未知の脆弱性を探索できるのか、探索結果を実用的な攻撃手順や修正手順へ近づけられるのかでは、意味が違う。生物・化学分野でも、一般知識を説明できることと、危険な実験計画を具体化できることは同じではない。能力閾値は、こうした違いを測り、どの段階から追加の統制が必要になるかを決めるために置かれる。

Anthropic の Responsible Scaling Policy は、高度な AI システムから生じる catastrophic risk、すなわち社会規模で重大な被害につながるリスクを管理するための枠組みとして公開されている[22]。OpenAI も Preparedness Framework Version 2 で、生物・化学、サイバーセキュリティ、AI self-improvement などの risk category を追跡する枠組みを示している[23]。AI Seoul Summit 2024 の Frontier AI Safety Commitments も、frontier AI の開発と配備におけるリスクの特定、評価、管理を求める方向を示している[24]。

これらの枠組みが示しているのは、能力評価だけではない。能力評価は出発点である。モデルがどの水準の能力を持つかを測ることは重要である。しかし、測定結果だけでは社会的な安全性は生まれない。高い能力が見つかったとき、誰に使わせるのか。どのガードレールを置くのか。どのログを残すのか。どの用途を拒否するのか。どの組織には限定提供するのか。どの条件で提供を止めるのか。ここまで決めなければ、能力閾値は実効性を持たない。

この点は、Fable 5 と Mythos 5 の事案と接続している。問題になったのは、モデルが高い能力を持っていたことだけではない。その能力をどの安全制約で包み、どの利用者に渡し、どの国籍や組織属性を境界として扱い、どの条件で止めるかだった。つまり、能力閾値は「このモデルは危険である」と名づけるためだけにあるのではない。能力が高いと判断された後に、提供範囲、アクセス条件、監査条件、停止条件を変えるためにある。

段階 見るべきこと 実装されるべきもの
評価 モデルがどの危険能力や有用能力を持つかを測る。 ベンチマーク、レッドチーミング、外部評価、能力分類が必要になる。
判断 その能力をどの条件で社会へ出すかを決める。 提供範囲、用途制限、承認条件、停止条件、再開条件が必要になる。
配備 判断された条件を実際のサービスに反映する。 アクセス制御、モデルルーティング、ログ保持、監視、監査、例外管理が必要になる。
運用 実際の利用が想定された範囲に収まっているかを確認する。 利用監視、アラート、濫用検知、サポート権限の制限、顧客対応手順が必要になる。
再評価 運用中の利用実態や新しいリスクを見直す。 インシデント対応、再訓練、ポリシー更新、提供停止と再開の手続きが必要になる。

この流れを見ると、frontier AI の安全性は、モデル単体の性質ではなくなる。もちろん、モデル内部の安全制御や拒否挙動は重要である。しかし、それだけでは不十分である。モデルが危険な要求を拒否することと、危険な能力を誰に配るかを制御することは別の問題である。さらに、拒否挙動が一定の確率で破られる可能性があるなら、運用側には、利用者制限、ログ監査、異常検知、緊急停止、限定再開といった外側の統制が必要になる。

ここで、能力閾値と運用統制の関係を取り違えてはならない。能力閾値は、モデルを分類するためのラベルではない。運用統制を発動するための条件である。ある能力が低い段階では、通常の提供で足りるかもしれない。しかし、能力が高くなるにつれて、提供範囲を狭める、利用者審査を強める、データ保持を延ばす、監視を強める、外部評価を追加する、政府や第三者との協議を求める、といった措置が必要になる。閾値とは、測定結果を運用上の行動へ変えるための接続点である。

能力の状態 安全上の意味 必要になる統制
低い能力 一般的な説明や補助にとどまり、重大な悪用へ直結しにくい。 通常の利用規約、基本的な拒否ポリシー、標準的な監視で足りる場合がある。
中程度の能力 専門的な作業を支援し、悪用時の作業負担を下げる可能性がある。 用途制限、濫用検知、顧客属性の確認、ログ保持、モデル別のアクセス制御が必要になる。
高い能力 未知の不整合の探索や高度な自動化を通じて、防御と攻撃の両方を強化しうる。 限定提供、事前承認、強化監査、外部評価、緊急停止、再開条件の明文化が必要になる。
閾値超過 通常提供では社会的リスクを管理しにくい水準に達している。 提供停止、提供範囲の再設計、政府・第三者との協議、運用体制の再構築が必要になる。

このように整理すると、Anthropic や OpenAI の安全枠組みは、単なる自主規制文書ではなく、能力を測り、分類し、配備条件へ接続するための運用文書として読める。もちろん、企業が自ら作る枠組みには限界がある。評価方法が十分か、外部から検証できるか、企業利益と安全判断が衝突したときにどうするか、政府との関係がどの程度透明かという問題は残る。それでも、frontier AI では、少なくとも企業が能力閾値と運用統制を結びつける枠組みを持たなければ、能力の社会的配備を説明できなくなる。

この章の論点は、本稿の中心に戻る。最先端 AI の安全性は、モデル内部の調整だけでは完結しない。評価によって能力を見つける。判断によって提供範囲を決める。配備によってその判断を実装する。運用によって逸脱を検出する。再評価によって停止や再開を見直す。この一連の流れを通じて、能力利用の意味境界が保たれる。能力閾値は、運用統制へ接続されて初めて意味を持つ。

9. AI 安全性は、モデル内部だけでは完結しない

AI safety は、しばしば alignment、jailbreak 耐性、危険出力の拒否といったモデル内部の問題として語られる。alignment とは、モデルの振る舞いを人間の意図や社会的に許容される範囲へ近づける考え方である。jailbreak 耐性とは、禁止された出力を引き出そうとする回避的なプロンプトに対して、モデルがどれだけ崩れずに拒否できるかという性質である。これらは重要である。しかし、本稿で見てきた事案が示しているのは、それだけでは足りないということである。

モデルがどれほど慎重に調整されていても、誰がアクセスできるのか、どの組織が使えるのか、どの用途が許されるのか、どのログが残るのか、どの条件で停止できるのかが設計されていなければ、安全な社会実装にはならない。危険な要求を拒否するモデルであっても、利用者の属性、組織の承認状態、利用目的、監査条件をモデル単体で完全に判断できるわけではない。したがって、AI safety はモデル内部の調整だけでなく、モデルの外側にある運用環境、権限管理、監査、停止手続きまで含めて考える必要がある。

NIST の AI Risk Management Framework は、AI リスクを組織が管理するための枠組みを示している[25]。NIST の Generative AI Profile は、生成 AI 特有のリスクを扱うための companion resource として公開されている[26]。また、NIST SP 800-53 は、情報システムと組織のためのセキュリティおよびプライバシー controls のカタログを示している[27]。これらの文書を並べると、AI の安全性は、モデルの振る舞いだけでなく、組織的なリスク管理、アクセス制御、監査、運用手順を含む問題として見えてくる。

さらに、NIST の Secure Software Development Framework と SP 800-218A は、生成 AI や dual-use foundation models を含む AI モデル開発について、ソフトウェア開発ライフサイクル全体での安全な開発実践を扱う方向を示している[28]。CISA の Secure by Design は、利用者にセキュリティ負担を押し付けるのではなく、製品の設計段階から安全性を組み込む考え方を示している[29]。NCSC などの Guidelines for secure AI system development も、AI システムの開発、配備、運用、保守における logging、monitoring、update management、incident management を重視している[30]。

ここで重要なのは、これらの枠組みが「モデルを安全に訓練する」だけを求めているわけではないことである。AI システムは、モデル、データ、API、利用者、組織、運用担当者、監査手順、更新手順、インシデント対応を含む全体として動く。モデルが危険な出力を拒否することは、その一部にすぎない。モデルがどこへ配備され、誰が呼び出し、どの権限で利用され、どのような記録が残り、問題が起きたときに誰が止めるのかまで設計されていなければ、社会的な安全性は成立しない。

観点 モデル内部の対策 運用上の対策
危険出力 危険な要求を拒否するように調整する。 危険な用途、利用者、組織、環境を検知し、必要に応じて停止する。
jailbreak 回避プロンプトに耐えるように訓練や評価を行う。 異常利用の監視、ログ分析、レート制限、アカウント停止を行う。
アクセス モデル自体は利用者の国籍、所属組織、契約状態を完全には知らない。 本人確認、法人確認、国籍確認、権限管理、API キー管理を行う。
用途 モデルは入力文から用途を推定できても、組織上の正当性までは保証できない。 用途申告、利用契約、承認フロー、監査対象化、例外管理を組み合わせる。
説明責任 モデル出力だけでは、誰が何を許可したかは残らない。 承認記録、利用ログ、監査証跡、インシデント対応履歴を残す。
停止可能性 モデル内部の拒否だけでは、提供範囲全体を止められない。 モデル別停止、顧客別停止、組織別停止、リージョン別停止、緊急遮断手順を用意する。

この区別は、暗号にも似ている。強い暗号アルゴリズムがあっても、鍵管理、アクセス権、バックアップ、退役処理、物理媒体の管理が壊れていれば情報は守れない。暗号の強度は重要である。しかし、実際の安全性は、鍵を誰が持つのか、どこに保管するのか、失効できるのか、復旧時に漏れないのか、廃棄時に残らないのかに左右される。同じように、高度な AI モデルに安全制御が入っていても、配備環境、権限管理、ログ、監査、停止権限が壊れていれば、社会的な安全性は成立しない。

この点は、Fable 5 と Mythos 5 の事案にそのまま当てはまる。仮にモデル内部の拒否挙動が改善されても、それだけでは「外国籍者に使わせない」「承認組織にだけ使わせる」「防御目的に限る」「後から監査できる」という条件は満たせない。これらはモデル内部の出力制御ではなく、モデル外部の統制である。利用者確認、組織確認、モデルルーティング、ログ保持、監視、例外処理、停止手順がそろって初めて、制度上の境界が実行環境の境界になる。

ここで、AI safety を二層に分けて考えると分かりやすい。第一の層は、モデルがどのように答えるかである。これは alignment、拒否挙動、レッドチーミング、危険能力評価に関わる。第二の層は、モデルがどのように社会へ配備されるかである。これはアクセス制御、顧客審査、国籍確認、ログ監査、運用監視、停止可能性に関わる。第一の層だけでは、危険出力を減らすことはできても、能力の配分を管理することはできない。第二の層だけでは、利用者を制限できても、モデル自体の危険な振る舞いを抑えることはできない。両者は代替関係ではなく、重ねて設計されるべき関係である。

層 中心になる問い 具体的な統制 限界
モデル内部 モデルは危険な要求を拒否し、許容される範囲で有用に応答できるか。 alignment、拒否ポリシー、危険能力評価、レッドチーミング、安全チューニングを行う。 利用者の国籍、組織の承認状態、契約条件、監査要件を完全には扱えない。
運用環境 誰が、どの条件で、どの能力へアクセスできるかを制御できるか。 ID 管理、API 認可、モデル別提供制御、ログ保持、監視、緊急停止を行う。 モデル自体が危険な出力を出す場合、それだけでは内容面の安全性を保証できない。
組織統治 能力提供の判断を誰が承認し、誰が監査し、誰が責任を負うのか。 承認フロー、顧客審査、内部権限分離、監査証跡、インシデント対応体制を整える。 判断基準が不透明であれば、境界管理は恣意的な配分になりうる。

この整理から分かるのは、AI 安全性が単一の技術課題ではないということである。モデルを安全にすること、システムを安全にすること、組織が安全に運用することは、それぞれ異なる課題である。しかも、最先端 AI では、これらが分離したままでは機能しない。モデル内部の拒否と、API の認可と、顧客契約と、政府の指令と、監査ログが接続されていなければ、意味境界は途中で失われる。

したがって、AI 安全性は、モデルの性質ではなく、能力が社会へ流れる経路全体の性質である。モデル内部の調整はその一部でしかない。能力が API を通り、組織に渡り、業務に組み込まれ、判断や防御や攻撃へ接続される。その経路全体で、誰に許され、誰に禁じられ、どの条件で記録され、どの時点で停止できるのかが保たれなければならない。

この章の結論は、本稿全体の結論へ直結する。最先端 AI を安全にするとは、危険な出力を減らすことだけではない。能力の通り道を設計し、その通り道の各所で意味境界を保存することである。安全なモデルを作ることと、安全に配備できることは同じではない。frontier AI の統治では、この差がますます大きな意味を持つ。

10. AI 企業は、モデル企業から統治実装企業へ変わる

既稿「生命科学は規制より速く進んでよいのか」では、技術と制度の速度差を扱った。技術は、対象の輪郭がまだ曖昧な段階でも進むことができる。研究者や企業は、可能になったことを試し、性能を測り、応用先を探し、既存の分類では扱いにくい対象を次々に生み出していく。一方、制度はそうはいかない。制度は、何を対象とするのか、誰に責任を割り振るのか、どこまでを許容し、どこからを禁止するのかを定義しなければならない[31]。この速度差は、生命科学に限らず、frontier AI にも現れる。

本稿で扱ってきた事案も、同じ構造を持つ。frontier AI は、制度が完全に整う前に能力を伸ばす。モデルは、コードを読み、脆弱性を探し、長時間の推論を行い、専門家の作業を補助し、ときには従来の制度分類では扱いにくい能力を示す。しかし、その能力が国家安全保障、重要インフラ、防御と攻撃の境界、輸出管理、外国籍者アクセスに関わる水準へ達すると、制度は何らかの線を引かなければならない。技術の進行を待ってから制度を考えるのでは遅いが、制度が技術の能力を完全に理解してから線を引くことも難しい。

このとき、AI 企業の役割も変わる。従来の見方では、AI 企業の中心能力は、強いモデルを作ることだった。より高い推論能力、より長いコンテキスト、より優れたコード能力、より低い推論コスト、より使いやすい API を提供することが競争力だった。もちろん、これは今後も重要である。しかし、本稿で見てきたように、能力が高くなるほど、その能力を誰に、どの条件で、どの責任のもとで渡すかが問題になる。すると、企業はモデルを作るだけでは足りなくなる。

既稿「生成 AI の競争軸は、モデルから業務実装へ移る」では、生成 AI 企業の競争軸が、モデル性能そのものから、企業業務への実装能力へ移ると整理した[32]。モデルが単体のチャット画面に閉じているうちは、性能や価格が目立ちやすい。しかし企業利用では、モデルは既存データ、権限、ワークフロー、承認手続き、監査、業務判断へ接続される。そこで重要になるのは、モデルそのものだけでなく、モデルを業務の中で使える形に落とし込む能力である。

本稿は、その先に位置づく。競争軸は、モデルから業務実装へ移るだけではない。さらに、業務実装から統治実装へ移る。業務実装とは、モデルを企業の作業手順や情報システムへ接続することである。統治実装とは、それに加えて、法制度、企業契約、アクセス制御、監査、停止手続き、政府対応、顧客提供、クラウド配備を、一つの運用可能な仕組みに落とすことである。

ここでいう統治実装は、抽象的な理念ではない。たとえば、政府が「外国籍者アクセスを止める」と求めたとき、企業はそれを実際のユーザー属性、社員権限、顧客アカウント、API キー、モデルルーティング、ログ監査へ反映しなければならない。政府が「承認された組織には使わせてよい」と判断したとき、企業はその組織の中の誰が使えるのか、委託先や子会社を含めるのか、利用ログをどこまで残すのか、サポート担当者が手動で回避できないかを設計しなければならない。これは、単なる法務対応でも、単なるセキュリティ設定でもない。制度上の意味を、動くシステムへ変換する作業である。

競争軸 中心になる能力 今回の事案との関係
モデル性能 高い推論能力、コード能力、サイバー能力、知識処理能力を持つモデルを作る。 Fable 5 と Mythos 5 の能力が国家安全保障上の問題として扱われる出発点になる。
業務実装 モデルを企業データ、権限、ワークフロー、既存システムへ接続する。 モデルが単体のチャットではなく、組織の防御、開発、監査、意思決定へ組み込まれる。
統治実装 利用資格、国籍、承認組織、監査、停止、再開、政府対応を実装する。 政府指令と実運用の境界を一致させられるかが、競争力と信頼性になる。

この表が示すように、統治実装は業務実装の外側にある余分な作業ではない。frontier AI では、能力が高くなるほど、業務実装そのものが統治条件を含むようになる。どの部署に使わせるか、どの顧客に使わせるか、どの国からのアクセスを許すか、どのモデルをどの用途に割り当てるか、どのログを残すか、どの時点で停止するかは、すべて業務利用の前提条件になる。企業が AI を業務に組み込むとき、その組み込み方は、同時に能力配分の設計にもなる。

この変化は、AI 企業に新しい能力を求める。第一に、モデルを能力単位で分ける力が必要になる。すべての顧客に同じモデルを同じ条件で提供するのではなく、一般向け、承認組織向け、防御者向け、内部評価向け、研究向けといった形で、能力と制約の組み合わせを設計しなければならない。第二に、利用者と組織を細かく識別する力が必要になる。個人、法人、部署、委託先、子会社、国籍、所在地、利用目的を、認可判定に使える形で管理しなければならない。第三に、提供停止と再開を実行できる力が必要になる。モデル全体を止めるだけでなく、顧客別、組織別、地域別、権限別に切り替えられることが重要になる。

統治実装の要素 必要になる仕組み 欠けた場合に起きること
能力分離 モデル、機能、ツール、拒否設定、提供範囲を能力単位で分ける。 危険度の異なる能力を一括で止めるか、一括で開くかしかできなくなる。
利用者識別 個人、法人、国籍、所在地、所属、委託関係、利用目的を認可に接続する。 本来止めるべき利用者が残るか、本来許可できる利用者まで止まる。
アクセス制御 API キー、組織アカウント、社員ロール、サービスアカウントごとに呼び出せる能力を制御する。 承認条件が実際のモデル呼び出しに反映されず、制度上の境界が崩れる。
監査証跡 誰が、いつ、どの能力を、どの権限で使ったかを記録する。 違反の有無だけでなく、許可された利用だったかどうかも説明できなくなる。
停止と再開 モデル別、顧客別、組織別、地域別、権限別に提供状態を切り替える。 細い境界で制御できず、全停止か抜け穴のある提供に傾く。

このように見ると、統治実装は企業の信頼性そのものに関わる。高性能モデルを作れることは重要である。しかし、強い能力を持つモデルほど、政府、重要インフラ、金融、医療、セキュリティ、クラウド事業者との接続が増える。そのとき、顧客や政府が見るのは、モデルが強いかどうかだけではない。その企業が、能力を限定提供できるか、ログを残せるか、監査に応じられるか、違反時に止められるか、条件が整ったときに安全に再開できるかである。

ここで AI 企業は、単なるモデル提供者ではなくなる。政府、重要インフラ、企業顧客、クラウド、監査主体をつなぎ、能力の流れを管理する主体になる。これは、企業にとって負担であると同時に、競争力にもなる。高性能モデルを持つだけの企業と、高性能モデルを統治可能な形で配備できる企業の差が開くからである。

この差は、今後さらに大きくなる可能性がある。モデル性能が各社で接近すれば、差別化は単純なベンチマークだけでは難しくなる。一方、政府対応、業界別の法令遵守、顧客ごとの権限設計、監査可能なログ、クラウド分離、緊急停止と再開の運用は、容易には模倣できない。これらは、技術、法務、セキュリティ、営業、顧客運用、政府対応が組み合わさった組織能力だからである。

したがって、frontier AI 企業の競争軸は、モデル性能から業務実装へ、さらに統治実装へ進む。強いモデルを作ることは必要条件である。しかし、国家管理下の frontier AI では、それだけでは十分条件にならない。強いモデルを、許可された主体へ、許可された用途で、監査可能な形で、必要なら停止し、条件が整えば再開できる企業が重要になる。最先端 AI の価値は、能力そのものだけでなく、その能力を壊れない境界の中で流通させる実装力によって決まる。

11. 結論 ―― 最先端 AI は、誰に使わせるかだけでは足りない

本稿で見てきた Anthropic / Fable 5 / Mythos 5 の事案は、「米政府が危険な AI を止めた」という単純な話ではない。たしかに、最初に見えるのは提供停止である。Anthropic は政府指令を受けたとして、Fable 5 と Mythos 5 を全顧客向けに無効化した。しかし、そこで起きていたことを停止だけで理解すると、重要な構造を取り逃がす。政府が求めた境界は「外国籍者アクセスの停止」だった。一方、実際に選ばれた措置は全顧客停止だった。この差分こそが、本稿の出発点である。

この差分が示しているのは、制度上の境界と実装上の境界が自然には一致しないということである。政策文書や政府指令の中では、「外国籍者」「承認組織」「防御目的」「監査対象」といった語を使って境界を引ける。しかし、実際のシステムは、その語をそのまま理解しない。システムが扱うのは、ユーザー ID、組織アカウント、API キー、社員ロール、モデル ID、クラウド環境、ログ、契約状態である。制度上の意味が、これらの実行単位へ正しく変換されなければ、境界は機能しない。

その後に報じられた Mythos 5 の限定再開は、さらに重要である。能力は完全に禁止されたのではない。承認された主体へ、条件付きで戻される方向に動いた。ここで最先端 AI は、広く販売される通常の商品ではなく、資格に応じて配分される資源として現れる。能力が高くなるほど、単に多くの人へ売ればよいのではなく、誰に、どの条件で、どの責任のもとで使わせるかが問われる。性能向上は普及拡大だけでなく、配布先の選別も生む。

しかし、誰に使わせるかを決めるだけでは足りない。承認された主体に使わせると言っても、その主体の中には社員、委託先、子会社、共同研究者、クラウド運用担当者がいる。外国籍者を止めると言っても、その属性は API キーやサービスアカウントから自動的に見えるとは限らない。防御目的に限ると言っても、その用途がログや監査証跡として残らなければ、後から説明できない。利用資格は、政策上のラベルではなく、実行環境へ移されるべき条件である。

ここで、既稿で扱った Copy Fail や Dirty Frag の議論が接続される。そこでは、read-only、shared、input といった上位レイヤーの意味が、下位レイヤーの最適化、共有、in-place 処理を通過する中で失われる問題を見た。AI 統治でも同じ構造が現れる。foreign national、trusted organization、approved use、monitored access といった制度上の意味は、API、クラウド、社員権限、法人契約、モデルルーティング、ログ監査を通過する中で失われうる。意味境界は、宣言するだけでは保存されない。

このため、AI 安全性はモデル内部だけでは完結しない。alignment、jailbreak 耐性、危険出力の拒否は必要である。しかし、それらは安全性の一部でしかない。誰が使えるか、どの環境で使えるか、どの権限で呼び出せるか、どの記録が残るか、誰が停止できるか、どの条件で再開できるかまで含めて、安全性は成立する。安全なモデルを作ることと、安全に配備できることは同じではない。

この点で、frontier AI 企業の役割も変わる。強いモデルを作る企業であるだけでは足りない。強いモデルを、許可された主体へ、許可された用途で、監査可能な形で提供し、必要なら止め、条件が整えば再開できる企業でなければならない。モデル性能、業務実装、法制度対応、アクセス制御、監査、クラウド配備、政府対応は分離できなくなる。最先端 AI の競争力は、能力そのものだけでなく、能力を壊れない境界の中で流通させる実装力によっても決まる。

最先端 AI の統治は、能力を禁止するかどうかでは終わらない。危険にも有益にもなりうる能力を、誰に、どの条件で、どの責任のもとで使わせるか。そして、その意味境界を国家、企業、クラウド、API、社員、顧客、監査の各層で保存できるかが問われる。最先端 AI は、誰に使わせるかだけでは足りない。使ってよいという意味、使ってはいけないという意味、監査されるべきという意味を、社会とシステムの各層で保ち続けられるかが、これからの AI 統治の中心になる。

参考文献

  1. Anthropic, Statement on the US government directive to suspend access to Fable 5 and Mythos 5（2026-06-12）. https://www.anthropic.com/news/fable-mythos-access
  2. Reuters, Anthropic disables top-tier AI models after US order limiting foreign access（2026-06-13）. https://www.reuters.com/technology/us-blocks-foreign-access-anthropics-most-advanced-ai-models-axios-reports-2026-06-13/
  3. WIRED.jp, Anthropic、「Claude Fable 5」を米政府命令に従い提供停止（2026-06-13）. https://wired.jp/article/anthropic-says-us-government-ordered-it-to-shut-down-mythos-models/
  4. Anthropic, Claude Fable 5 and Claude Mythos 5（2026-06-09）. https://www.anthropic.com/news/claude-fable-5-mythos-5
  5. Anthropic, Project Glasswing: Securing critical software for the AI era（2026）. https://www.anthropic.com/glasswing
  6. Anthropic, Expanding Project Glasswing（2026-06-02）. https://www.anthropic.com/news/expanding-project-glasswing
  7. UK AI Security Institute, Our evaluation of Claude Mythos Preview’s cyber capabilities（2026-04-13）. https://www.aisi.gov.uk/blog/our-evaluation-of-claude-mythos-previews-cyber-capabilities
  8. id774, Claude Mythos は世界をどう変えたのか（2026-05-08）. https://blog.id774.net/entry/2026/05/08/4737/
  9. id774, CVE-2026-31431 について徹底的に考える（2026-05-06）. https://blog.id774.net/entry/2026/05/06/4730/
  10. id774, Dirty Frag が強化した不変原理（2026-05-13）. https://blog.id774.net/entry/2026/05/13/4753/
  11. Reuters, US allows Anthropic to release Mythos AI to ‘trusted’ US organizations（2026-06-26）. https://www.reuters.com/technology/us-releases-anthropic-model-mythos-some-us-companies-semafor-reports-2026-06-26/
  12. WIRED, Trump Administration Allows Anthropic to Release Mythos to Select US Organizations（2026-06-26）. https://www.wired.com/story/anthropic-restores-access-to-mythos/
  13. Reuters, US close to allowing Anthropic to restore Fable 5 model, Axios reports（2026-06-27）. https://www.reuters.com/business/us-close-allowing-anthropic-restore-fable-5-model-axios-reports-2026-06-27/
  14. id774, AI 時代の危険な能力は、どこで止めるべきか（2026-06-16）. https://blog.id774.net/entry/2026/06/16/4892/
  15. White House Office of Science and Technology Policy, Framework for Nucleic Acid Synthesis Screening（2024）. https://bidenwhitehouse.archives.gov/wp-content/uploads/2024/04/Nucleic-Acid_Synthesis_Screening_Framework.pdf
  16. International Gene Synthesis Consortium, Harmonized Screening Protocol v3.0（2024-09-03）. https://genesynthesisconsortium.org/wp-content/uploads/IGSC-Harmonized-Screening-Protocol-v3.0-1.pdf
  17. Federal Register, Screening Framework Guidance for Providers and Users of Synthetic Nucleic Acids（2023-10-13）. https://www.federalregister.gov/documents/2023/10/13/2023-22540/screening-framework-guidance-for-providers-and-users-of-synthetic-nucleic-acids
  18. eCFR, 15 CFR § 734.13 — Export. https://www.ecfr.gov/current/title-15/subtitle-B/chapter-VII/subchapter-C/part-734/section-734.13
  19. Bureau of Industry and Security, Deemed Exports. https://www.bis.gov/deemed-exports
  20. Federal Register, Framework for Artificial Intelligence Diffusion（2025-01-15）. https://www.federalregister.gov/documents/2025/01/15/2025-00636/framework-for-artificial-intelligence-diffusion
  21. Bureau of Industry and Security, Department of Commerce Announces Rescission of Biden-Era Artificial Intelligence Diffusion Rule, Strengthens Chip-Related Export Controls（2025-05-13）. https://www.bis.gov/press-release/department-commerce-announces-rescission-biden-era-artificial-intelligence-diffusion-rule-strengthens
  22. Anthropic, Anthropic’s Responsible Scaling Policy（last updated 2026-05-26）. https://www.anthropic.com/responsible-scaling-policy
  23. OpenAI, Preparedness Framework, Version 2（2025-04-15）. https://cdn.openai.com/pdf/18a02b5d-6b67-4cec-ab64-68cdfbddebcd/preparedness-framework-v2.pdf
  24. GOV.UK, Frontier AI Safety Commitments, AI Seoul Summit 2024（updated 2025-02-07）. https://www.gov.uk/government/publications/frontier-ai-safety-commitments-ai-seoul-summit-2024/frontier-ai-safety-commitments-ai-seoul-summit-2024
  25. National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework (AI RMF 1.0)（2023）. https://www.nist.gov/itl/ai-risk-management-framework
  26. National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile（2024）. https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence
  27. National Institute of Standards and Technology, Security and Privacy Controls for Information Systems and Organizations, SP 800-53 Revision 5（2020）. https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
  28. National Institute of Standards and Technology, Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile, SP 800-218A（2024）. https://www.nist.gov/publications/secure-software-development-practices-generative-ai-and-dual-use-foundation-models-ssdf
  29. Cybersecurity and Infrastructure Security Agency, Secure by Design. https://www.cisa.gov/securebydesign
  30. National Cyber Security Centre, Guidelines for secure AI system development（2023-11-27）. https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development
  31. id774, 生命科学は規制より速く進んでよいのか（2026-06-13）. https://blog.id774.net/entry/2026/06/13/4886/
  32. id774, 生成 AI の競争軸は、モデルから業務実装へ移る（2026-06-25）. https://blog.id774.net/entry/2026/06/25/4922/