前のエントリで、「先進的AIイノベーションおよびセキュリティ大統領令」をみました(リンク)。また、日本において国家サイバーセキュリティ室(NCO)から「AI性能の高度化を踏まえたサイバーセキュリティ対策の強化について」も公表されています。

• Project YATA-Shieldのスライド(リンク)
• 実施する政策等(リンク)
• 重要インフラ事業者に対する注意喚起(リンク)
• ソフトウェア・ベンダに対する注意喚起(リンク)
• 各政府機関への依頼(リンク)

そうこうしてるうちに、米国が、アンソロピック社に対して、Mythos Fableの公開を停止するようにもとめたという事件がおきました(記事としてはアンソロピック、米政府指示でミュトス級AI提供停止　日本含む )。

先進的AIがサイバーセキュリティに引き起こしている影響をみるときに、その影響は、従来の「協調された脆弱性開示」の限界を明らかにした、ということと、両用ツールとしての性格を有すること、という観点から捉えるべきだろうと考えます。

「脆弱性発見ツールの法律問題-MythosとCVD/法規制/輸出規制」において、早急に基本的な考え方についてまとめたのですが、二つの観点を、文献等を調べて詳しくみたいとおもいます。特に、まずは、公開停止事件を受けて、輸出禁止法制との関係から。

1 両用ツールとしての性格

「脆弱性発見ツールの法律問題-MythosとCVD/法規制/輸出規制」において、ワッセナー・アレンジメントにおける侵入ソフトウエア（intrusion software）”に関するシステム等、4. E. 1. c.　”侵入ソフトウエア”の”開発”に係る”技術”。」との関係が問題になるのではないか、ということを指摘しました。その後、Mythos 5とFable 5が一般公開されたのですが、6月12日には、政府によって一般公開の停止を命じられたということになりました。

Fable 5は、その基盤となるAIモデルMythos上に構築されており、Mythosの強力なサイバーセキュリティ能力にユーザーがアクセスするのを防ぐためのセーフガードを備えています。すなわち、Mythos 5が高性能な土台、Fable 5が安全装置を加えて公開可能にした版、という構造です。Fable 5は、特定の高リスク領域での応答をブロックする新たなセーフガードによって、Anthropicがこれほど高度なモデルを初めて一般公開した事例でした。

1.1 時系列

時系列的な進展は、以下のようになります。政府との関係については、「Inside the whirlwind 24 hours that led the White House to slap export controls on Anthropic」の記事を参考にしています。

6月9日（公開）：AnthropicがClaude Fable 5とMythos 5を発表（Anthropicの launch post）。複数の業界ベンチマークで最先端と謳われました。

6月12日 午後5時21分（東部時間、指令受領）：Anthropicは政府から指令を受領。書簡には国家安全保障上の懸念の具体的な詳細は示されていませんでした。発出元は米商務省（Commerce Department）で、国家安全保障上の輸出管理を用いて、両モデルをいかなる外国人にも配布することを禁じるものでした。前のターンで触れたとおり、書簡は商務長官ラトニックからCEOアモデイ宛てでした。

6月12日 夜（即時無効化）：指令の対象が、米国外の者だけでなく、米国内にいる外国人——Anthropic自身の非市民従業員を含む——にも及ぶため、Anthropicはコンプライアンス確保のため全ユーザーに対しモデルを無効化するほかなかったと説明しています。他のClaudeモデル（Opus 4.8等）は影響を受けません。

6月12〜13日（声明）：Anthropicが公式声明を公表(リンク)。政府がFable 5の「ジェイルブレイク（脱獄）」手法を認識したと政府が考えている、というのが当社の理解だとしたうえで、これは誤解だと考えており、可能な限り早期のアクセス復旧に取り組むと表明しました。直後にユーザー向けにも、新規セッションは選択中の既定モデルかOpus 4.8で動作すると案内されています。

1.2 米国国内法の輸出規制法制

今回の米商務省（Commerce Department）で、国家安全保障上の輸出管理を用いて、両モデルをいかなる外国人にも配布することを禁じたという書簡については、現段階において公表はされていません。

Anthropic自身が、書簡には国家安全保障上の懸念の具体的な詳細が示されていなかったと述べています。発出が今夜の出来事であり、書簡の全文も具体的な引用条項も公開されていないため、「どの条文に基づくか」を断定できる一次資料は現時点で存在しません。

ということになります(Claudeの回答)。

ワッセナー・アレンジメントに対応する国内法制は、2018年輸出管理改革法（Export Control Reform Act of 2018, ECRA、50 U.S.C. §§ 4801以下）と、その下位規則である輸出管理規則（Export Administration Regulations, EAR、15 C.F.R. Parts 730–774）です。

もっとも、「national security authorities」という曖昧な表現にとどまっているため、理論的には国際緊急経済権限法（IEEPA、50 U.S.C. §1701以下）等の別系統の援用可能性も完全には排除できないということになるそうです。

これらを図解するとこのようになります。

以下、細かく解説していきます。

1.2.1 2018年輸出管理改革法の条文

ECRA（50 U.S.C. §§ 4801以下）ECRAは、輸出管理規則（EAR）の恒久的な授権法であり、規制対象品目の具体的な特定を商務省産業安全保障局（BIS）に委任する構造です。ECRAのリンクは、こちらです。授権の中核は§ 1753（50 U.S.C. § 4812、大統領・長官への授権）および§ 1754（50 U.S.C. § 4813、追加的権限（ライセンス制度の授権)）にあります。

§ 4812 — 大統領の権限（Authority of the President）
この条は、規制の根幹となる大統領への授権です。§ 4811に定める政策（同条(1)〜(10)）を遂行するため、大統領は、(1) 米国の管轄に服する品目（items）の輸出・再輸出・国内移転を、米国人によるものか外国人によるものかを問わず規制し、(2) 米国人が所在地を問わず行う特定の活動を規制すると定めます。司法省の運用例の表現を借りれば、ECRAは大統領に対し、米国の管轄に服する品目の輸出・再輸出・国内移転を規制する権限を付与する条文です。

§ 4813 — 追加的権限（Additional authorities）
§ 4812(a)を補完して、大統領は——商務省以外の連邦機関が所管する制定法・規則によって授権される範囲を除き——米国人に対し、所在地を問わず、(A) 一定の品目（本サブチャプターの規制対象外の品目を含む）の輸出・再輸出・国内移転、および (B) そうした品目の設計・開発・生産・使用・運用・設置・保守・修理・オーバーホール・改修を支え、または関連役務を遂行しうるその他の活動について、商務省のライセンスを申請・取得するよう求めなければならないと定めます。

したがって、それ自体には「侵入ソフトウエア（intrusion software）」を名指しする条項は存在しません。「侵入ソフトウエア」の実体的規制は、この授権の下でBISが定めるEAR（15 C.F.R. Parts 730–774）の商務管理品目リスト（CCL）に置かれています。

本件と関連しては、§ 4817の規定があります。§ 4817（新興・基盤技術の特定と輸出規制の要件、Requirements to identify and control the export of emerging and foundational technologies）の内容は以下のとおりです。

大統領が、商務長官・国防長官・エネルギー長官・国務長官その他の関係機関と連携して主導する、定期的・継続的な省庁間プロセスを設置・運営します。特定の対象は、(A) 米国の国家安全保障に不可欠であり、かつ (B) FIRRMA上の「重要技術（critical technologies）」の一部類型（§ 4565(a)(6)(A)(i)〜(v)）には当たらない、新興・基盤技術です。プロセスは、公開情報・機密情報（国家情報長官提供分を含む)・対米外国投資委員会（CFIUS）の審査情報・諮問委員会の助言など複数の情報源に基づき、外国での技術開発状況、規制が米国内開発に与える影響、規制の拡散防止効果を考慮し、かつ意見公募手続（notice and comment）を含むものとされます((a) 技術の特定)。(a)で特定された技術について、商務長官は、EARの下で輸出・再輸出・国内移転に関する適切な規制を設けるものとし、これには暫定的規制（たとえば、ある者にライセンスが必要である旨を通知すること）や追加規則の公布が含まれます(b)。

この商務省の規制の項目を訳すると

(b)商務省の規制
(1)一般規定
(a)(1)(B)項に規定する権限と矛盾しない範囲を除き、商務長官は、(a)項に基づき特定された技術の輸出、再輸出、または国内移転について、「輸出管理規則」に基づき適切な規制を定めるものとする。これには、必要に応じて暫定的な規制（輸出には許可が必要であることを関係者に通知することなど）を講じること、または追加の規則を公布することが含まれる。

という暫定的な対応が記載されています。

1.2.2. 輸出管理規則（EAR）

「15 CFR Chapter VII, Subchapter C — EXPORT ADMINISTRATION REGULATIONS」連邦規則集第15編 第VII章 サブチャプターC「輸出管理規則」ということになります。

EARの全体像

EARは、米国商務省産業安全保障局（BIS)が運用する、デュアルユース品目（軍民両用品目)——軍事にも民生にも使える物品・ソフトウェア・技術——の輸出・再輸出・国内移転を規律する規則群です(リンク)。ECRA（50 U.S.C. §§ 4801以下)を授権根拠とし、その委任を受けてBISが定めています。

完全な軍需品（武器そのもの)は国務省所管のITAR(国際武器取引規則)が扱うのに対し、EARは民生品とデュアルユース品目を担当する、という役割分担です。

主要なPart（部)の内容

§ 730・734（適用範囲)：EARの概要と、何が「EARの対象（subject to the EAR)」となるかの管轄範囲を定めます。米国原産品目、米国産部品を一定割合超含む外国製品（デミニミス・ルール)、米国技術を用いて外国で生産された直接製品（FDPルール)などが対象範囲に入ります。

§ 732（手順)：自社の取引にEARがどう適用されるかを判断する手順（ステップ・バイ・ステップ)を示します

§ 736（一般禁止事項)：輸出者が遵守すべき10の一般禁止事項（General Prohibitions)を列挙します。許可なき規制品目の輸出、禁輸国・規制対象者への移転などが含まれます。

§ 738・774（CCLと分類)：EARの心臓部です。

§ 774に商務管理品目リスト（Commerce Control List, CCL)が置かれ、規制品目がECCN(輸出管理分類番号)ごとに記載されます。

§ 738はCCLの読み方と、規制理由(NS・AT・RS等)が仕向先国とどう対応するかを示すCommerce Country Chart(国別対応表)を定めます。

§ 740（許可例外)：本来ライセンスが必要な取引のうち、一定条件下でライセンスなしに行えるもの（License Exceptions)を定めます。前のターンで触れた、サイバーセキュリティ品目向けの許可例外ACE(§ 740.22)もここにあります。

§ 742・744・746（規制理由・エンドユース/エンドユーザー・禁輸)：§ 742が規制理由ごとのライセンス政策、§ 744が懸念される最終用途・最終需要者に基づく規制(WMD拡散、軍事最終用途など。エンティティ・リストもここに関連)、§ 746が国別の禁輸・制裁(キューバ、ロシア等)を扱います。

§ 748・750（ライセンス申請・処理)：ライセンスその他の許可の申請手続と、BISによる処理を定めます。

§ 760（反ボイコット)：外国による非認可のボイコットへの加担を制限する規定です(ECRA第II編の反ボイコット法に対応)。

§ 762・764・766（記録保持・違反・行政手続)：記録保持義務、禁止行為と違反、行政上の制裁手続を定めます。前のターンで触れた一時的拒否命令(TDO)や罰則の運用面に関わります。

§ 772（定義)：EAR全体で用いる用語の定義集です。

ここで、問題となるのが、「intrusion software」の定義で、そこでは、「intrusion software（侵入ソフトウエア）」の定義は、EAR § 772.1 に置かれています。

「侵入ソフトウエア（Intrusion software）」とは、コンピュータまたはネットワーク対応機器の「監視ツール（monitoring tools）」による検知を回避し、または「防御的対抗措置（protective countermeasures）」を打ち破るよう「特別に設計（specially designed）」または改変された「ソフトウエア」であって、以下のいずれかを行うものをいう。

(a) コンピュータまたはネットワーク対応機器からのデータもしくは情報の抽出、またはシステムデータもしくはユーザーデータの改変、または
(b) 外部から提供された命令の実行を可能にするための、プログラムまたはプロセスの標準的な実行経路（standard execution path）の改変。

注1：「侵入ソフトウエア」には、以下のいずれも含まれない。

(a) ハイパーバイザー、デバッガー、またはソフトウエアのリバースエンジニアリング（Software Reverse Engineering, SRE）ツール。
(b) デジタル著作権管理（Digital Rights Management, DRM）の「ソフトウエア」。
(c) 資産追跡または回収（recovery）の目的で、製造者・管理者・利用者によるインストールを想定して設計されるツール。

注2：「ネットワーク対応機器」には、移動体機器および計測器（smart meters）が含まれる。

1.2.3. 商務管理品目リスト（CCL）

「侵入ソフトウエアの開発に係る技術」の根拠条文は、ECRAの条番号ではなく、CCL上の商務管理品目リスト（CCL）におけるECCN（輸出管理分類番号)として特定すされることになります。

上記輸出管理規則（EAR）の774.1条は、序です。

§ 774.1 はじめに。

(a) 管理リストの適用範囲。 本編において、EARへの言及は、15 CFR 第VII章、サブチャプターCへの言及を意味する。産業安全保障局（BIS）は、BISの権限の対象となる「品目」—すなわち、「物品」、「ソフトウェア」および「技術」—を含む商務省管理リスト（CCL）を管理している。CCLには、米国政府の他の省庁または機関によって輸出が専属的に規制されている品目は含まれていないが、他の機関が関連品目の規制を管理している場合には、CCLの記載にそのような規制への言及が含まれることがある。さらに、CCLには記載されていないが「EARの適用対象」となる品目は、「EAR99」という指定番号によって識別される。「EARの適用対象」となる品目については、EAR第734.2(a)項を参照のこと。EAR第738部には、CCLの構成およびカントリー・チャートとの関係についての説明が含まれている。

となっています。商務省管理リスト（CCL）は、ワッセナー・アレンジメント（2013年合意・2017年改訂）を国内実施するもので、BISが2021年10月の暫定最終規則（86 Fed. Reg. 58205, Oct. 21, 2021、2022年5月発効）で導入しました。

• eCFR(Part 774)：https://www.ecfr.gov/current/title-15/subtitle-B/chapter-VII/subchapter-C/part-774
• BIS(CCLの解説)：https://www.bis.gov/regulations/ear/commerce-control-list-ccl

CCLは10のカテゴリー(0:原子力関連、1:材料・化学・微生物・毒素、2:材料加工、3:エレクトロニクス、4:コンピュータ、5:通信・情報セキュリティ、6:センサー・レーザー、7:航法・航空電子、8:海洋、9:航空宇宙・推進)に分かれます。

各カテゴリー内が5つの製品グループ(A:システム・装置・部品、B:試験・検査・製造装置、C:材料、D:ソフトウエア、E:技術)に分かれます。

情報通信に関するものは、4:コンピュータ、5:通信・情報セキュリティということになります。

該当ECCN（カテゴリー4）

「侵入ソフトウエアの開発に係る技術」に直接対応するのは、ECCN 4E001.cです。侵入ソフトウエアに関連する主な条文は次のとおりです。

4A005（システム・装置）：侵入ソフトウエアの生成・指揮統制（command and control）・配送のために「特別に設計（specially designed）」または改変された「システム」「装置」およびそれらの「構成要素」を規制します。

4D004（ソフトウエア）：侵入ソフトウエアの生成・指揮統制・配送のために「特別に設計」または改変された「ソフトウエア」を規制します。

4E001（技術）——これは二つの号に分かれます。

既存の4E001.aは、新設の4A005および4D004によって規制される装置・ソフトウエアの「開発」「生産」または「使用」に係る技術を捕捉します。
新設の4E001.cは、「侵入ソフトウエア」の「開発」に係る技術に特化しています。

もっとも、これらについては、4E001のNote 1で記載された例外があります。

注1：4E001.a および .c は、「脆弱性の開示」または「サイバーインシデントへの対応」には適用されない。

と明示されています。

該当ECCN（カテゴリー5）

ECCN 5A001／5D001／5E001（カテゴリー5 Part 1：通信)：通信傍受・監視機能を伴うツールは、こちらの通信傍受関連の規制に触れる可能性があります。
ECCN 5A002／5D002／5E002（カテゴリー5 Part 2：情報セキュリティ／暗号)：脆弱性発見ツールが強力な暗号機能を組み込む場合は、暗号品目としてこちらで規制されうる場面があります。ただしこれは「脆弱性発見」ゆえではなく「暗号」ゆえの規制で、性質が異なります。

結論

先進的AIという概念を考えたときに、それが、脆弱性をよく探知しうるというだけでは、上記4E001のNote 1で記載された例外に該当するでしょう。他方、発見した脆弱性を実際に突いて検知回避下でのデータ抽出や実行経路改変を行う攻撃機能まで備える、もしくは、それを備えている後それを妨げる機能を有していないということなると4A005（システム・装置）、4D004（ソフトウエア）もしくは、4E001（技術）の射程に入るものと考えられます。

結局、どのような条項で、指示をだしたのか、というのが公表されていない段階では、先進的AIと輸出管理規制という論点について、どのような解釈論をとっているのかというのは、まったく想像できないということになりそうです。

2 「協調された脆弱性開示」の限界

協調された脆弱性開示(CVD)については、私のブログでも何回も触れています。

• 「脆弱性」と契約不適合、そして欠陥-日経新聞サーチライト記事に関して (2025年10月4日)
• 脆弱性の開示の枠組を深く勉強したい人に-ワクチンの予約システムの報道に関して(2021年5月19日)
• 情報処理推進機構「情報システム等の脆弱性情報の取扱における法律面の調査 報告書 改訂版」(平成31年度) (以下、便宜上 法律面の報告書といいます)

などがあるのは、すでにふれたとおりです。

で、国際的にみて、高性能AIによって、このCVDがどのような影響を受けているのかというのについて論じている論文を確認します。が論点としては、「脆弱性発見ツールの法律問題-MythosとCVD/法規制/輸出規制」においてふれていますが、「CVE提出数の爆発的増加とNVDの機能限界」と「ディスクロージャーウィンドウの実質的無効化」という二つの観点があげられるとしました。

その前に論点としては、LLM技術を使った脆弱性発見のリサーチがあるのでその点についても触れます。

2.1 LLM技術を使った脆弱性発見

ZE SHENGほか “LLMs in Software Security: A Survey of Vulnerability Detection Techniques and Insights”

この点についての論文としては

• “LLMs in Software Security: A Survey of Vulnerability Detection Techniques and Insights”（ACM Computing Surveys)(https://doi.org/10.48550/arXiv.2502.07049)

があります。この論文は、IEEE S&P・USENIX Security・ACM CCSといったトップ会議とIEEE Transactions on Software Engineering等の学術誌を起点に、キーワード駆動で約500〜600本を選別し、2019〜2024年の関連性の高い58本を抽出しています。従来の機械学習手法（CNN・RNN・LSTM）は対象外。LLM特化のサーベイとしては初の包括的なものと位置づけています。

分析は四つのリサーチクエスチョン（RQ1: どのLLMが使われたか、RQ2: ベンチマーク・データセット・指標、RQ3: 技術手法、RQ4: 課題と方向性）に沿って構成されています。

この論文の基本的な論述は、

---

肯定的側面（The Positive）：サイバーセキュリティのコミュニティはLLMから肯定的な影響を受けており、それは近年における発表論文数の大幅な増加によって裏づけられる。その貢献は、脆弱性の局在特定（localization）、検出、分析を含む複数の領域に及ぶ。C、Java、Solidityがこの領域における主要な焦点として浮上している。研究方法論は一貫して三つの主要な構成要素——LLMの実装、プロンプト工学、意味論的処理（semantic processing）の手法——を重視している。さらに、複雑な脆弱性検出の課題を扱いやすい部分問題へと分解できることから、マルチエージェント手法が広く用いられている。

主要な課題（Key Gaps）：

• 狭いスコープとリポジトリ単位のカバレッジの限定性：現状の研究は、小規模で特化したデータセット内での、関数単位の脆弱性の二値分類に自らを限定することが多い。さらに、クロスファイルの依存関係やより長い呼び出しスタック（call stack）が重大な課題となるリポジトリ単位での脆弱性の検出・再現に取り組む研究はわずかである。
• フロンティアLLMの急速な進歩：2023〜2024年のブレークスルーは、フロンティアLLMのファインチューニングと活用が今後の進展に決定的に重要であることを示している。にもかかわらず、これまでの研究の大半は、能力で劣る従来型のモデルに依拠している。
• 文脈認識の不足：複雑な多ファイル依存関係や長い呼び出しスタックへの注意が不足している。ニューロシンボリック（neuro-symbolic）なアプローチ（例：CodeQL、LLMと組み合わせたBear）は大規模プロジェクトで有望性を示しているものの、汚染伝播（taint propagation）のモデリングの改善、より効率的なLLMの推論、言語横断的な適応が依然として必要である。
• 脆弱性タイプの不均衡：メモリ関連の脆弱性（例：バッファオーバーフローの問題）は不釣り合いに高い検出精度を得ている一方で、論理的脆弱性（logical vulnerabilities）は相対的に十分研究されていないままである。
• データセットの限界：既存のデータセットはスコープが狭く、データ漏洩（data leakage）の問題を抱えている。基礎研究と応用研究の双方を推進するには、LLMベースの脆弱性検出のために特別に設計された、専用かつ包括的なデータセットが緊急に必要とされる。

—-

2.2 CVE提出数の爆発的増加とNVDの機能限界

「CVE提出数の爆発的増加とNVDの機能限界」について、検討します。いろいろな論考が検討の候補とされましたが、結局、

—

「LLMによって脆弱性報告が増大した」という命題そのものを正面から実証した文献は、査読済み・プレプリントを問わず、依然として手元にありません。最も近いのは、

HackerOneのプレスリリース（AI関連の脆弱性報告が前年比で大幅増という自社集計。ただし企業の自己申告で査読なし）
curl/libxml2等の個別プロジェクトの実例報告（逸話的証拠）

といった一次・二次資料にとどまり、いずれも学術的な測定研究ではありません。

—

ということにとなりました。で、このCVE提出数の爆発的増加について論じるものとして、Hacker Oneのブログがあるのでそれを紹介します。この点については、Hacker Oneのプレスリリース等が参考になります。Hacker Oneは、米サンフランシスコに本社を置く、攻撃的セキュリティ（offensive security）のプラットフォーム企業です。2012年に設立され、世界最大級のバグバウンティ／脆弱性開示プラットフォームを運営しています。

“The Vulnerability Apocalypse Is a Remediation Crisis”（HackerOne公式ブログ、2026年4月15日）
リンク：https://www.hackerone.com/blog/continuous-threat-exposure-management-remediation-crisis

記載内容を改めて整理すると、2026年3月にHackerOneプラットフォームの脆弱性提出が過去最高の46,947件に達し、前年比76%増となったこと、有効・悪用可能な脆弱性の割合は約25%で横ばいを保ったため、確認済みで悪用可能な発見が防御側に届く絶対数も比例して増加したことが報告されています。さらに、重大・高深刻度の脆弱性が検証済み発見の32%を占めるまで上昇し（歴史的な基準値26〜28%から上昇)、一方で修復スループットの改善は前年比19%にとどまったため、バックログも当月過去最高に達したとされ、重大な発見の修復までの中央値時間は過去1年で15日未満に短縮された一方、全体の修復スループットは19%しか増えておらず、76%の量的増加に対して追いついていないと論じています。

AIとの関連については、AI支援による提出が増えるなか、HackerOne自身も自社プラットフォームでAIを用いたトリアージと検証に多額の投資を行ってきたと記しています。

このブログでは、「The Remediation Crisis（修復クライシス）」として、有効な脆弱性が発見される速度と、組織がそれを修復する速度との乖離が拡大しているという点を指摘しています。明るい材料として、重大な発見の修復までの中央値時間は過去1年で15日未満に短縮され、セキュリティチームは重大脆弱性が即時対応を要することを内面化し、AIの支援も得て実行しているとされます。

しかし厳しい現実として、修復スループット全体の増加は19%にとどまり、76%の量的増加に追いついておらず、バックログが拡大している。有効な発見が未解決のまま放置される一日一日が、悪用可能な窓を意味すると指摘します。決定的なのは攻撃側の経済構造の変化です。かつて業界のリスク計算は「希少性」——大半の脆弱性は発見に手間・専門性・費用がかかりすぎて見つからない——を前提にしていたが、熟練研究者がAIエージェントをコードベースに向ければ翌朝には動くエクスプロイトが得られる今、その前提はもはや成立しない。攻撃者も同じAIツールを使い、発見を数か月でなく数時間で武器化する、と。Zero Day Clockを引いて、開示から武器化までの時間が数時間に圧縮されたと述べます。

結論として、ボトルネックは発見ではなく「find-to-fix（発見から修復まで）のサイクル」であり、抜きん出るのは最も多く脆弱性を見つける組織ではなく、最も速くトリアージ・検証・優先順位づけ・修復できる組織だと論じます（Phil Venablesは「速度こそ唯一の根本的防御」と論じています）。

「What the Data Says to Do（データが示す処方箋）」はしてあがっているのは、以下の四つです。

• 第一に、検証と修復を「網羅性」でなく「速度」のために作り直すこと。四半期ペンテストや年次評価といった定期バッチ型のリズムは時代遅れで、トリアージから修復までをAI支援の優先順位づけ・自動検証・脆弱性受付とエンジニアリング工程の直接統合・AIによるコード修正で圧縮すべき。手動の承認ステップは遅延を生み、遅延こそが主要なリスクだとします。
• 第二に、脆弱性の受付を「継続的なオペレーション」として扱うこと。ここで著者は、Anthropicの「発見量が一桁増加することに備えよ」という提言は仮説ではなく現に起きていると引用し、ライブ攻撃・バグバウンティ研究者・自動スキャナー・AIエージェント・内部ツールという多様な源からの持続的な量を吸収できる常時稼働の受付・トリアージ・対応能力を構築すべきだと述べます。
• 第三に、個々の発見ではなく「バグの類型」を修正すること。同じカテゴリの脆弱性が多数のエンドポイントに現れたら、50個の個別パッチではなく、フレームワークやアーキテクチャ層での systemic な修正を行う。将来の脆弱性面の80%を消す20%の作業を見つけよ、と。
• 第四に、外部の視点を構造的優位として受け入れること。内部チームには再現できない数千の多様な専門性をプラットフォームの研究者が持ち込み、AIがその各々を増幅する、という論旨です。

What Comes Next（今後）として脆弱性の発見・報告・検証・修復のあり方における構造的転換の入口にあり、量は増え続け、深刻度は上がり続け、発見から悪用までの窓は縮み続けると総括します。

“3 Signals from the 2025 Hacker-Powered Security Report”（2025年11月4日）https://www.hackerone.com/blog/ai-security-trends-2025 も、3で、67パーセントの調査者がAIを利用しており、反復的作業を効率化しているということを論じています。

あと、AIの脆弱性については

• “HackerOne Report Finds 210% Spike in AI Vulnerability Reports Amid Rise of AI Autonomy”（2025年10月1日、サンフランシスコ）
  リンク：https://www.hackerone.com/press-release/hackerone-report-finds-210-spike-ai-vulnerability-reports-amid-rise-ai-autonomy
• “Hacker-Powered Security Report – 9th Edition” https://www.hackerone.com/report/hacker-powered-security
• “The Top Researcher Signals From HackerOne’s 2025 HPSR”（2026年1月6日） https://www.hackerone.com/blog/2025-hpsr-researcher-signals

などの記事がでています。

3 その他の論点

Claudeを使って、ピックアップした論文ですが、脆弱性についての選球としては、LLMの脆弱性の発見、修正に関するエコシステムへの影響、AIによる脆弱性報告のトリアージについての論文とかがあります。

結局、論文を教えて、というプロンプトで出てきた論文は役に立たなかったという問題が露呈したわけです。

3.1 AIシステム自体の脆弱性について

“Mind the Gap—-AI Security and the Limits of Current Reporting Standards” (IEEE SaTML, 2026) 著者: L. Bieringer et al. (IBM Research)、(https://doi.org/10.48550/arXiv.2412.14855)

著者はBieringer, McGregor, Nichols, Paeth, Stängler, Wespi, Alahi, Grosseの8名です。

この論文が扱うのは、AIシステム「の中の」脆弱性（AI security incidents）の報告——回避攻撃（evasion）、データ汚染（poisoning）、モデル窃取（model stealing）のように、周辺のソフト・ハードではなくモデルやデータそのものを狙う攻撃——をどう報告・共有するか、という問題です。

AI security incidentsというのを中核の概念にしています。

（AI）セキュリティインシデント、すなわち、データやモデルを標的とした攻撃によって引き起こされる、AIシステムに関連するインシデント。

と定義されており、3つの基本的な攻撃例。

1) 機密性を標的とした攻撃：モデル窃取は、所有者の同意なしにモデルを複製するもの

2) モデルの完全性を標的とした攻撃：回避攻撃は、テスト入力を改ざんしてモデルの出力を変更するものである

3) 性能が著しく低下した場合のモデルの完全性または可用性に対する攻撃：ポイズニング攻撃は、分類器の全体的な性能を低下させるために、訓練データ、サンプル、またはラベルを改変する

をあげています。この論文は、むしろ、AIセキュリティという問題に絞っているので、具体的に今回の問題意識からはずれることになります。

また、同様の研究として“Establishing Minimum Elements for Effective Vulnerability Management in AI Software” (arXiv, 2025) 著者: M. Fazelnia, S. Moshtari, M. Mirakhorli、(https://doi.org/10.48550/arXiv.2411.11317)があります。

要約は

要旨—急速に進化する人工知能（AI）の分野において、脆弱性の特定、記録、および軽減は、堅牢かつ安全なシステムを確保するために極めて重要である。本論文では、AI脆弱性管理に必要な最低限の要素、および構造化されたモデル文書化のためのAI部品表（AIBOM）に支えられた人工知能脆弱性データベース（AIVD）の構築について論じる。

また、AI脆弱性の開示、分析、分類、および記録のための標準化されたフォーマットとプロトコルを提示する。本論文では、AIシステムの固有の側面に焦点を当てることで、このようなAIインシデントデータベースが従来の脆弱性の範囲を超えて拡張されなければならない理由について論じる。

さらに、AI脆弱性の多面的な性質に対処するために特別に設計された、新たな深刻度スコア、弱点列挙システム、および包括的な緩和戦略の必要性を含め、AI脆弱性管理における課題とギャップを明らかにする。

索引用語—AIインシデント、AIVD、AI脆弱性管理、AI部品表、AIBOM

ということです。そして

本論文の主な貢献は以下の5点である。

1) AIに特化した共通脆弱性分類（AI-CWE）の定義：AIシステムに特化した構造化された脆弱性分類システムを導入する。これは、AI特有の障害モードに焦点を当てる点で、従来のCWEとは異なる。

2) AI脆弱性に対するME：モデル、データ、およびデプロイメントの各レイヤーにわたるAI脆弱性を記述するために必要な、新しいMEのセットを定義し、一貫性のある報告と評価を支援する。

3) AI Bill of Materials（AIBoM）フレームワーク：SBOMのAI特化型拡張であるAIBoMの概要を示す。これは、システムコンポーネントや依存関係だけでなく、AIワークフローに特有の倫理的、環境的、および使用上の境界も捉えるものである。

4) AIを意識した深刻度スコアリング：CVSSの課題を分析し、AIの脆弱性により適したスコアリングシステムを開発するために、動的スコアリングとAI固有の影響度指標という2つの方向性を提案する。

5) AI脆弱性管理におけるギャップ分析と今後の課題：従来のソフトウェアセキュリティの実践とは異なる、AI脆弱性管理特有の重要な課題を特定し、体系化する。

というのが、本論文のポイントになります。

3.2 脆弱性調査における研究者の保護

Rampášekほか “Hunting for vulnerabilities: call for European protection of security researchers”(https://doi.org/10.1093/cybsec/tyag002) になります。

要約は

本論文は、進化を続けるEUのサイバーセキュリティ枠組みにおいて、脆弱性報告者、すなわちサイバーセキュリティ研究者の役割と法的保護について考察する。オランダ、マルタ、ドイツにおける注目すべき事例が示すように、これらの研究者がどのような存在であるか、その活動の価値、そして欧州全域で彼らが直面する法的リスクの高まりについて検証する。EU基本権憲章を含む国際的な人権枠組みを参照しつつ、本論文は、セキュリティ研究が「科学への権利」および「研究を行う自由」の下で保護されるべきであると論じる。

本論文は、「善意のセキュリティ研究」をEU法において法的に認められたセーフハーバーとして定義することを提唱する。国連サイバー犯罪防止条約、ブダペスト条約、 情報システムへの攻撃に関するEU指令、サイバーセキュリティ法、NIS2指令、サイバーレジリエンス法、およびオランダ、ベルギー、フランス、ドイツ、イタリア、スペイン、ポーランド、チェコ、スロバキア、マルタに加え、英国や米国を含むEU加盟国の一部の国家政策など、選定された国際的・EUの法的枠組みの比較分析により、保護体制が断片的で不十分であることが明らかになった。

この問題に対処するため、本論文は、相互に関連する2つの柱、すなわち（i）義務的な調整された脆弱性開示（CVD）手続き、および（ii）倫理的なセキュリティ研究に対する実質的な法的免除に基づき、EU全域にわたる首尾一貫した枠組みの構築を求めている。

デジタルインフラ事業者を対象とした最近のNIS2欧州委員会実施規則（EU）2024/2690は前進ではあるものの、研究者に対する明確な保護が欠けている。したがって、本論文は結論として、脆弱性開示方針が単に事業者に採用されるだけでなく、それに依存する研究者にとって法的に利用可能かつ安全なものとなるよう、法的および技術的なセーフハーバーをEUのサイバーセキュリティ法に組み込むことを求めている。

ということで、法律論文ということになります。構成としては

Abstract（要旨）

Introduction（序論）

Who are vulnerability reporters（脆弱性報告者とは誰か）

What is subject matter of the security research（セキュリティ研究の対象は何か）

• Legal risks of cybersecurity research（サイバーセキュリティ研究の法的リスク）
• Researchers of Radboud University sued in the Netherlands (2008)（オランダでのRadboud大学研究者の被訴〔2008年〕）
• University research blocked in the UK (2013)（英国での大学研究の阻止〔2013年〕）
• Maltese students and lecturer prosecuted (2023)（マルタの学生と講師の訴追〔2023年〕）
• IT consultant prosecuted in Germany (2024)（ドイツでのITコンサルタントの訴追〔2024年〕）
• Why some companies say no to researchers（なぜ一部の企業は研究者を拒むのか）
• Legal and ethical boundaries of good-faith security research（善意のセキュリティ研究の法的・倫理的境界）

Right to research cybersecurity vulnerabilities（サイバーセキュリティ脆弱性を研究する権利）

Good-faith security research（善意のセキュリティ研究）

Cyber security safe harbours in selected international and European cybercrime law（選定した国際・欧州サイバー犯罪法におけるサイバーセキュリティのセーフハーバー）

• Budapest Cybercrime Convention（ブダペスト・サイバー犯罪条約）
• EU directive on attacks against information systems（情報システムへの攻撃に関するEU指令）
• United Nations Convention Against Cybercrime（国連サイバー犯罪条約）

Comparative legal overview of cyber security safe harbours in EU（EUにおけるサイバーセキュリティ・セーフハーバーの比較法的概観）

• Bottom-up v a top-down approach（ボトムアップ対トップダウンのアプローチ）
  • Bottom-up, trust-based models with limited formal regulation（限定的な公式規制にとどまる、信頼ベースのボトムアップ型モデル）
  • Top-down, authority-driven models with procedural legal provisions（手続的法規定を伴う、当局主導のトップダウン型モデル）〔France／Slovakia and Czechia／UK 等を含む〕
  • Top-down, hard-law models with substantive legal provisions（実体的法規定を伴う、ハードロー型のトップダウン・モデル）〔Poland／Belgium／Germany を含む〕
  • The USA（米国）

Copyright law perspective of safe harbour（セーフハーバーの著作権法的観点）

Safe harbours in EU cybersecurity law（EUサイバーセキュリティ法におけるセーフハーバー）

• The NIS2（NIS2指令）
• The CSA（サイバーセキュリティ法）
• The Cyber Resilience Act（サイバーレジリエンス法）

Lack of technical safe harbours（技術的セーフハーバーの欠如）

Conclusions（結論）

Acknowledgements（謝辞）

Author contributions（著者の貢献）

Conflicts of interest（利益相反）

Funding（資金提供）

References（参考文献）

となっています。たしかに、この分野の研究については、欧州について、満遍なくというのは、困難だったりするので、このように全般的に調査しているものは助かります。

3.3 AIによる脆弱性報告のトリアージ

Zhengほか “From Reviewers’ Lens: Understanding Bug Bounty Report Invalid Reasons with LLMs” (https://doi.org/10.48550/arXiv.2511.18608)

これは、同論文の要約によると

—

要旨—バグ報奨金プラットフォーム（HackerOne、BugCrowdなど）は、クラウドソーシングによる脆弱性発見を活用して、継続的なカバレッジの向上や発見コストの削減を図り、社内のレッドチームを補完する重要な役割を果たしている。

AIによって生成されたバグ報告が増加する中、バグハンターがこれらの報告がなぜ無効と判定されるのかを理解するための研究はほとんど存在しない。報告の品質を向上させ、審査者の負担を軽減するためには、無効な報告を予測し、その理由を解釈することが極めて重要である。

本研究では、バグハンターが報告の妥当性を理解できるよう支援することを目的として、実証的研究を行う。1,400件の無効な報告を含む、公開された9,942件のバグ報奨金報告データセットを収集し、最先端の大規模言語モデルが無効な報告を識別できるかどうかを評価する。GPT-5、DeepSeek、および微調整されたRoBERTaといったモデルは、全体的な精度では高い性能を発揮するものの、無効なケースの検出には一貫して苦戦しており、レポートを過剰に受理する傾向が見られる。

無効判定の精度を向上させるため、情報漏洩の脆弱性に対する却下理由の分類体系を構築し、これを検索拡張生成（RAG）フレームワークに組み込んだ。このアプローチにより、分類の一貫性が大幅に向上し、バイアスが低減された。

また、レビュー担当者の判断がレポートの内容以外の要因によって影響を受ける可能性についても検証した。分析の結果、評判の高い報告者は境界線上のケースにおいてより好意的な結果を得やすい傾向があり、専門知識に対する評価がレビューの判断に影響を与え得ることが示唆された。全体として、本研究の知見は無効なレポートの特定における課題を浮き彫りにするとともに、LLMと構造化されたレビュー担当者の知識を組み合わせることで、より透明性が高く一貫性のある脆弱性レポートのレビューが可能になることを示している。

—

というものです。

3.3LLMの発展が、オープンソースに与える影響について

“Vibe Coding Kills Open Source” (2026)

著者  Miklós Koren, Gábor Békés, Julian Hinz, Aaron Lohmann (https://doi.org/10.48550/arXiv.2601.15494 )

この論文は、vibe codingやLLMがオープンソースのエコシステムに与える影響を論じています。