金融庁・日銀「フロンティアAIによる脅威変化を踏まえた金融機関等の短期的な対応」要請で何をしたら良いのか

シンジです。金融機関等の経営層に向けた短期的な対応要請が公開されました。実務者においてもこの文章がいったい何を求めているのか解説します。

結論（要点）

• 2026年5月22日、金融庁は日本銀行と連名で「フロンティアAIによる脅威変化を踏まえた金融機関等の短期的な対応」に係る要請を公表しました。政府全体パッケージ「Project YATA-Shield」（5月18日公表）の金融分野における実装です。
• 要請文の実務的な完成度は高く、外部公開資産の優先特定から契約のSLA/SLO、能動的なシステム停止まで、現場を理解した構成になっています。
• 主な論点は項目6（パッチ適用のリスクベース化）にあります。要請文はCVSSそのものを否定しているわけではありませんが、本文の「CVSSスコア」という語が、公開されたBaseスコア中心の運用を指すのか、Threat/Environmentalまで含む補正後の評価を指すのかが曖昧です。本来の意図は「CVSS基本値だけのしきい値ゲートをやめ、自組織への影響と攻撃成立の蓋然性を加えて優先順位を決めよ」と読むべきです。
• さらに重要なのは前提です。本要請は「大量パッチへの対応」に重心がありますが、フロンティアAI時代の中心課題は「そもそもパッチもCVEも間に合わない段階をどう守るか」にもあります。英国AISIが組織に求める基本対策は、定期的な更新適用に加え、堅牢なアクセス制御・セキュリティ設定・包括的なログ取得です。パッチ適用を否定するのではなく、検知・対応・要塞化（assume breach）をパッチ適用と同格の防御層として読むべきです。

この記事でわかること

• 今回の要請が「何を求めているのか」を9項目で把握できます。
• 多くの実務者がつまずく6の「CVSS否定→リスクベース」の正体（「CVSSスコア」という語の粒度の曖昧さ）がわかります。
• CVSS・EPSS・SSVC・CISA KEV をどう使い分ければよいかが整理できます。
• 「大量パッチ対応」より深刻な「CVE化・パッチ化されない脆弱性」への備え方の方向性が見えてきます。

前提となるキーワードの定義

本題に入る前に、登場する用語を一次情報の定義に沿って簡潔に整理します。

• フロンティアAI：最先端の高性能AIモデルの総称です。脆弱性の発見や高度な攻撃コードの生成に優れ、防御・攻撃の双方を高速化させると指摘されています。
• Project YATA-Shield：2026年5月18日に内閣官房国家サイバー統括室をはじめ関係府省庁（連名は計14主体）が公表した、AI性能の高度化を踏まえたサイバーセキュリティ対策強化のための政府横断パッケージです。
• CVSS（共通脆弱性評価指標）：FIRSTが公開する評価枠組みです。技術的深刻度を測る基本評価基準（Base）に加え、攻撃コードの出現状況（Threat）や対象システム環境で想定される脅威（Environmental）まで織り込んで深刻度を評価できます（v4.0ではSupplementalを含む4群）。
• EPSS（Exploit Prediction Scoring System）：その脆弱性が今後30日以内に実際に悪用される確率を予測する指標です。
• CISA KEV（Known Exploited Vulnerabilities）：実際に悪用が観測された脆弱性のカタログです。
• SSVC（Stakeholder-Specific Vulnerability Categorization）：悪用状況や露出・影響を意思決定木で分類し、対応要否を判断する手法です。

金融庁のフロンティアAI要請とは？まず結論から

2026年5月22日、金融庁は日本銀行と連名で、金融機関等に対し「フロンティアAIによる脅威変化を踏まえた金融機関等の短期的な対応」に係る要請を公表しました。政府全体のパッケージ「Project YATA-Shield」（5月18日公表）の金融分野における実装にあたるものです。

シンジは一次情報を一通り当たったうえで、この文書を精読しました。総評を一言でいえば、「実務的に手堅い文書であり、議論の核は項目6のCVSS記述の読み方にある」というものです。手堅さの根拠と、その論点を、以下で順に説明していきます。

なぜ今このタイミングなのか？要請に至る時系列

この要請は単発の文書ではなく、フロンティアAIの能力向上、AISI評価、金融分野の官民連携、Project YATA-Shieldという一連の流れの中で出てきたものです。一次情報を日付で並べると、少なくとも公開情報上は、どのような問題意識が短期間で金融分野の要請に接続されたのかを追うことができます。

公開情報上は、特定のフロンティアモデル（Mythos Preview）の能力ステップと、それを評価した第三者機関（AISI）の報告、さらにAIによる脆弱性発見の実例が短期間に積み上がり、約6週間で制度的対応へ接続された、という流れが読み取れます。なお要請文・YATA-Shieldは、これらを背景要因として参照しており、特定のモデルを単独の引き金と断定しているわけではありません。

YATA-Shield 本体は、内閣官房国家サイバー統括室や金融庁・経済産業省など、内閣官房・内閣府の各部局を含む計14の主体が連名する横断パッケージで、その背景認識として、Claude Mythos Preview をはじめとするフロンティアAIによる脆弱性の発見・修正性能の急速な向上に備える必要を明示しています。本要請は、そのうち金融分野を金融庁・日銀が引き取った格好です。

なお、要請文・YATA-Shield のいずれも、諸外国のAISIやAI開発者との連携を前提として明記している点は押さえておきたいところです。国際協調を土台にした動きであることは一次情報で裏が取れます。一方で「G7など特定の規制当局の枠組みが直接の引き金になった」という具体まで踏み込んだ説明は、現時点で公開された一次情報からは確認できません。状況証拠（金融当局が主導し、フロンティアAIを軸に、国際協調を明記している点）はその読みと整合しますが、ここは断定を避けておきます。

要請は何を求めているのか？9つの短期対応

要請の別添は、金融機関等が「概ね1ヶ月程度を目途」に講じるべき短期対応を9項目に整理しています。あくまで応急的措置であり、中長期的には脆弱性対応の自動化等への移行が必要、という但し書きが付く点も重要です。

1. フロンティアAIへの対応を経営課題として扱う：IT・セキュリティ部門に閉じず、経営トップのコミットメントと全社横断の連携を求めています。
2. 優先的に対応すべきサービス/ITシステムを特定する：リソースは有限という前提で、インターネットバンキング等の外部公開システムを最優先に位置づけています。
3. 特定した資産の技術負債を解消しておく：構成の再確認、不要ポートの閉塞、特権IDの削除、サポート切れ製品の更新を求めています。
4. パッチ適用に係る人的リソースを追加する：自社・ベンダー双方でリソース確保を事前に確認すべきとしています。
5. ベンダーとの維持保守契約の内容を確認する：パッチ適用が契約に含まれるか、夜間・休日対応、SLA/SLOの遵守可否を確認すべきとしています。
6. パッチ適用プロセスをリスクベースにする：本稿の主題です（後述します）。
7. パッチ適用以外の対策も強化する：仮想パッチ（WAF）、ボット対策、ネットワーク分離、特権IDのMFA、EDR、横展開対策を挙げています。
8. 優先サービス/ITシステムの停止に備える：能動的停止という選択肢の事前検討、BCPの有効性点検を求めています。
9. 外部との連携を維持・強化する：金融ISACや業界団体、当局との情報共有を促しています。

1,2,3,5,7,8の組み立ては手堅い内容です。特に5の「夜間・休日も含めて適時対応可能な契約か」「複数機関で同時多発した場合もSLA/SLOを守れるベンダー側リソースがあるか」という指摘や、7と8で仮想パッチ・EDR・能動的停止・BCPまで射程に入れている点は、現場を知る書き手の手によるものと考えられます。

そのうえで、議論の余地が最も大きいのが6です。

論点1｜6の「リスクベース」はCVSSの否定なのか？

本文が言っていること

6の本文から、論点に関わる部分を引用します（［…］は中略）。

CVSS スコアが高くない脆弱性であっても実際の攻撃に利用されている実態があり、こうした傾向は、フロンティア AI により、今後さらに加速することも想定される。［…］発見された脆弱性が自組織のサービス／IT システムに及ぼし得る影響を適切に把握するとともに、攻撃が成立する蓋然性も踏まえた評価を行うことが重要である。（金融庁・日本銀行 要請文 別添 6 より引用）

ここで押さえるべきは、要請文は「CVSSを捨てよ」とは書いていない点です。むしろ本文自身が、CVSSスコアや攻撃コードの有無だけに頼らず、自組織への影響と攻撃成立の蓋然性を加えたリスクベース判断を求めています。

それでも違和感が残るのは、「CVSSスコア」も「攻撃コードの有無」も、それ自体がリスク指標の一つだからです。指標を引き合いに出して戒めたうえで「リスクベースで」と続けると、一見すると循環して見えます。

脚注5が言っていること

ところが、同じ文書の脚注5は、CVSSを次のように説明しています（［…］は中略）。

CVSS は［…］基本評価基準（Base Metrics）に加え、攻撃コードの出現状況や対象のシステム環境において想定される脅威に基づき、0.0〜10.0 までのスコアで脆弱性の深刻度を評価する指標である。（金融庁・日本銀行 要請文 別添 脚注5 より引用）

ここが重要です。脚注5は、CVSSをBaseスコアだけの指標ではなく、攻撃コードの出現状況（Threat）や対象環境で想定される脅威（Environmental）まで含めて評価し得る枠組みとして説明しています。

つまり、脚注5はCVSSの射程（環境・脅威まで含む）を理解しているのに、本文の「CVSSスコア」という語は、実務でよく使われる公開Baseスコア中心の運用を指しているように読めます。これは「内部矛盾」というより、同じ『CVSSスコア』という語の粒度が、本文と脚注で揃っていないという問題です。6に対して多くの実務者が抱く「逆説しているのにリスクベースと言う」という気持ち悪さの正体は、この語の曖昧さにあります。

では「リスクベース」の中身とは？

6が求めるリスクベースの評価軸は、本文を丁寧に読むと2つに分解できます。(a) 自組織への影響の把握と、(b) 攻撃が成立する蓋然性の評価です。これを指標に対応させると、次のようになります。

要するに、6が求める「攻撃成立の蓋然性」と「自組織への影響」の相当部分は、CVSSのThreat/Environmental、EPSS、CISA KEV、SSVCで補助できます。ただし、CVSSのThreatは攻撃成立確率そのものではなく、悪用コードの成熟度や悪用状況を反映する入力の一つであり、確率モデルであるEPSSとは性質が異なります。ただし、業務停止の影響、規制要件、顧客影響、経営判断としてのリスク受容はCVSSの外側にあります。CVSSはリスク判断への入力であって、リスク判断そのものではありません。 その意味で、CVSSはリスクベースの「対立概念」ではなく「構成要素の一つ」と位置づけるのが正確です。

本文を一言、次のように補えば、誤読は起きませんでした。

• ✕ 「CVSSスコアや攻撃コードの有無等に基づき……」
• ○ 「CVSS基本値（Base）のみに依存し、攻撃コードの有無を二値の判断材料とする運用に偏ると……」

なぜEPSSやSSVCを名指ししなかったのか

おそらく意図的な単純化だと考えます。宛先は経営トップ・CIO・CISOであり、文書の性格は手法を規定しない原則ベース（金融庁ガイドラインの伝統的なスタイル）です。ここで特定手法を名指しすれば過剰規定になりますし、1ヶ月でEPSS連携やSSVC意思決定木を新規導入するのは多くの機関で非現実的でもあります。だからこそ「蓋然性と影響を見てリスクで並べよ」という成果だけを書いた、という読みが自然です。

その判断自体は理解できます。なお本稿は、要請文にEPSSやSSVCの名指しを求めるものではありません。あくまで実務者が6を読み替えるための対応例として示しています。ただし代償として、「CVSSスコア」という一語が、CVSSそのものを「やめるべきもの」と誤読させかねない本文になりました。経営層まで巻き込む短期要請という性格を踏まえると、ここは一言の補いがあってよかったと考えます。

論点2｜公開アドバイザリ「88」という数字は何を物語るのか？

要請文の前提を問い直すうえで、参照しておくべき一次情報があります。Anthropicが公開している協調的脆弱性開示（CVD）ダッシュボードです。フロンティアAIが実際にOSSの脆弱性をどれだけ見つけ、そのうちどれだけが世に出ているかを、数字で追えます。

2026年5月22日時点のファネルは、おおむね次の通りです。

ここから読み取れることは大きいです。

第一に、公開アドバイザリ（88件）は、候補（約23,019件）の0.4%程度、報告分（1,596件）の5%強にすぎません。 しかも律速段階は発見能力ではなく、人手によるトリアージとパッチ作成・開示調整です。少なくともこのスナップショットを見る限り、公開アドバイザリとして表に出ているのは候補全体のごく一部にとどまります。これは、CVEやGHSAといった公開カタログを起点にした運用だけでは、AIによる発見速度に追いつけない可能性を示しています。

第二に、これはあくまで「防御側の、協調的開示を前提としたパイプライン」の数字だという点です。なお、報告された1,596件は、外部セキュリティ企業のレビューを経たものだけでなく、Anthropicがメンテナの要請等に応じて直接報告したもの（偽陽性を含み得る）も含みます。いずれにせよ、トリアージし、開示窓を待ち、メンテナと調整するという律速があるため、2026年5月22日時点では、約23,019件の候補のうち公開アドバイザリに至っているものは88件にとどまります（同ダッシュボードは特定時点のスナップショットであり、パッチ化は遅行指標です）。攻撃側が同等の能力を持つAIを使う場合、協調的開示に伴うトリアージや開示窓を待たず、発見から悪用までの時間が大幅に短縮されるリスクがあります。

この2点を重ねると、要請文の前提が見えてきます。本要請は「大量の脆弱性とパッチが短期間に発見・提供される」前提で組み立てられています。しかし、より厳しく、かつより本質的なレジームは「そもそもパッチが存在しない／CVEが付かないまま悪用される」側にあります。CVEが付与されることを起点に優先順位を決める運用は、カタログ自体が疎で遅れるこの世界では、前提から揺らぎます。

公平に言えば、要請文もこの問題を半分は認識しています。7（仮想パッチ・WAF・EDR・分離・特権MFA）と8（能動的停止・BCP）は、まさに「パッチが間に合わない／存在しない」場合の備えです。中長期的には自動化へ移行せよ、とも書いています。ただし7,8は短期対応の一部として明記されてはいるものの、紙幅と見出しの重心は2〜6のパッチ管理側に置かれており、読者の注意もそちらに寄りやすい構成です。

論点3｜「基本をしっかり」とは具体的に何を指すのか？

要請文は、ある意味で安心材料として英国AISIの評価を引いています。曰く、フロンティアAIは「十分に防御されたITシステムに対しては、攻撃を達成できるとは言えない」。だから金融庁ガイドラインに基づく基本的な対策を、より迅速・着実に実行することが引き続き重要だ、という展開です。

ここで、AISIの原文に当たると、ニュアンスの差が見えてきます。

第一に、AISIは「防御されたシステムに勝てないと確認した」とは言っていません。評価レンジに能動的な防御者や防御ツールが欠けており、アラートを発報する行為への罰則も無かったため、十分に防御されたシステムを攻撃できるかは「断定できない」、という評価環境の限界としての留保です。つまり「できると確認されていない」と同時に「できないとも確認されていない」のです。さらにAISIは、将来のフロンティアモデルはさらに高性能になるため、今の防御投資が不可欠だと釘を刺しています。要請文のAISI要約自体は大筋で外れていませんが、AISIが強調する「評価環境には能動的な防御者や防御ツールが欠けていた」という制約は、要請文ではほぼ省略されています。読者には「十分に防御されていれば安全」と受け取られないよう、原文の留保を併せて読む必要があります。

第二に、そしてこちらが本質ですが、AISIが「評価レンジに欠けていた防御」として名指ししているのは、能動的な防御者・防御ツール・EDR・リアルタイムのインシデント対応です。AISI自身が今後の評価方針として、能動監視・EDR・リアルタイム対応を備えた要塞化環境のレンジで測る、と述べています。

裏を返せば、AISIが防御の根拠として挙げるのは、パッチ適用だけではなく、検知・対応・要塞化の層を含む運用全体だということです。AISIが組織に推奨する「基本」も、定期的なセキュリティ更新の適用に加え、堅牢なアクセス制御・セキュリティ設定・包括的なログ取得という、運用と可視化の束です。

参考までに、AISIの評価そのものは能力の階段状の向上を明確に示しています。専門家レベルのCTF（2025年4月以前はどのモデルも完答できなかった難度）でMythos Previewは約73%成功し、人間の専門家でおよそ20時間を要すると見積もられる32手順の企業ネットワーク攻撃シミュレーションを、10回中3回、最初から最後まで完遂しました（全試行平均で32手順中22手順、次点モデルは平均16手順）。能力は確実に上がっています。だからこそ、防御の論点を「パッチ速度」だけに矮小化してはなりません。

ここから導かれる「基本」の読み方は明確です。フロンティアAI時代に守るべき「基本」には、パッチ適用に加えて次の層が当然に含まれます。

• 攻撃対象領域（ASM）の最小化と外部露出の削減
• 特権IDへのMFAをはじめとするアイデンティティの要塞化
• ネットワーク分離による横展開の封じ込め
• EDR/SOCと、検知から対応までの速度

これは要するに「侵害される前提（assume breach）」「ゼロトラスト」のポスチャです。要請文は7,8でパッチ以外の対策と能動的停止まで明記しており、この点自体は重要です。ただし、文書の紙幅と見出し構成上、読者の注意は2〜6のパッチ管理に寄りやすくなっています。フロンティアAI時代を踏まえれば、検知・対応・分離・BCPは「パッチの代替策」ではなく「同格の主戦場」として読むべきです。「基本をしっかり」の「基本」には、この検知・対応・要塞化の層が当然に含まれます。

金融機関・経営層は何をすべきか？

最後に、この要請をどう受け止めて動くかを、短期と中長期に分けて整理します。

短期（要請が求める1ヶ月の範囲で）

• 6を「CVSSをやめろ」と読まないことです。CVSS基本値だけのしきい値ゲートをやめ、Threat/Environmental（実装としてはEPSS・CISA KEV・SSVC）まで踏まえてリスクで並べる、と読み替えます。手元にEPSS等が無くても、「自組織で本当に露出しているか」「悪用が観測されているか」の2軸を足すだけで運用は前進します。
• 2で特定した外部公開システムについて、3の技術負債解消（不要ポート閉塞・特権ID削除・サポート切れ更新）を先に終わらせます。これは「リスクベース」以前の、攻撃対象領域そのものの削減です。
• 5のベンダー契約点検は、同時多発を前提に行います。複数機関で大量パッチが同時発生したときにSLA/SLOを守れるベンダー側リソースがあるかは、契約書ではなく実態で確認します。

中長期（要請が但し書きで認める「自動化への移行」の本丸）

• 重心を「大量パッチへの対応」から「パッチが間に合わない前提で守る」へ広げます。具体的には7,8、すなわち仮想パッチ、EDR/SOC、ネットワーク分離、特権MFA、能動的停止とBCPへの投資を、補助ではなくパッチ適用と同格の本命として位置づけます。
• 防御側もフロンティアAIを使います。AIによる脆弱性発見が攻撃側だけの武器になるなら一方的に不利ですが、検知・分析・対応の側にAIを組み込めれば、AISIが言う「断定できない（＝防御が効きうる）」側に自組織を置けます。勝負は「自組織で検出・分析・対応できるか」「攻撃側の速度を上回れるか」「ASMをどこまで小さくできるか」というゲームになります。

まとめ｜大量パッチ対応だけでなく、CVE化されない脆弱性に備える

金融庁・日銀の本要請は、短期の応急要請として実務的に手堅い文書です。外部公開資産の優先特定から、契約のSLA/SLO、能動的停止とBCPまで、現場を理解した構成になっています。

論点は「CVSS」という一語の使い方に集約されます。本文の「CVSSスコア」が公開Baseスコア中心の運用を指すように読めるため、「CVSSをやめよ」とも受け取れてしまいます。脚注5が示すとおりCVSSは環境・脅威まで織り込める枠組みであり、要請の主旨は「基本値だけのゲートをやめよ」です。一言の補いで解消できる曖昧さですが、経営層まで巻き込む短期要請ゆえに、そのコストは小さくありません。

そして、より大きな論点は前提の置き方にあります。「88/1596」、さらにその背後の「約23,019候補」という数字が示すのは、公開アドバイザリに現れるのが候補のごく一部にとどまるという事実です。要請文の重心は大量パッチへの対応に置かれていますが、AISIが防御の根拠として挙げるのは更新適用に加えた検知・対応・要塞化の層であり、フロンティアAI時代の本丸はそこにもあります。要請文の7,8と「中長期は自動化へ」という但し書きが指している方向こそ、本来はもっと前面に置かれてよい、というのが、一次情報を読み終えたシンジの結論です。

よくある質問（FAQ）

Q. 金融庁の「フロンティアAIによる脅威変化を踏まえた金融機関等の短期的な対応」要請とは何ですか？

2026年5月22日に金融庁が日本銀行と連名で公表した、金融機関等向けの短期的なサイバーセキュリティ対応の要請です。フロンティアAIによって脆弱性が短期間に大量発見・顕在化し、それに伴ってパッチが短期間に多数提供される可能性を前提に、資産管理・脆弱性管理・パッチ適用・監視対応・レジリエンスなどの態勢を点検・強化することを、経営トップの直接関与のもとで求めています。

Q. Project YATA-Shieldとは何ですか？

2026年5月18日に内閣官房国家サイバー統括室をはじめ関係府省庁（連名は計14主体）が公表した、AI性能の高度化を踏まえたサイバーセキュリティ対策強化のための政府横断パッケージです。今回の金融庁・日銀の要請は、このパッケージの金融分野における実装にあたります。

Q. なぜ金融庁はこの要請を出したのですか？

2026年4月7日に公表されたフロンティアAI（Claude Mythos Preview）の能力向上と、4月13日の英国AISIによる評価、AIによる脆弱性発見の実例が短期間に積み上がったためです。4月24日に官民連携会議、5月14日に作業部会、5月18日のProject YATA-Shieldを経て、5月22日に本要請が公表されました。

Q. 要請の6はCVSSを否定しているのですか？

否定していません。本文の「CVSSスコア」という語が公開Baseスコア中心の運用を指すように読めるため否定的に見えますが、脚注5はCVSSを攻撃コードの出現状況や環境要素まで含めて評価し得る枠組みとして説明しています。要請の主旨は「Baseスコアだけのゲートをやめ、自組織への影響と攻撃成立の蓋然性を加えよ」であり、その相当部分はThreat/Environmental・EPSS・CISA KEV・SSVCで補助できます。ただし業務影響や経営判断としてのリスク受容はCVSSの外側にあり、CVSSはリスク判断の入力であって判断そのものではありません。

Q. CVSS Baseスコアだけで優先順位を決めるのはなぜ不十分なのですか？

Baseスコアは脆弱性そのものの技術的深刻度を示しますが、実際に悪用されているか、自組織で露出しているか、業務影響がどれほど大きいかは別問題だからです。そのため、EPSS（悪用確率）、CISA KEV（悪用観測）、SSVC（意思決定木）、自組織の資産重要度を組み合わせて判断する必要があります。

Q. CVSS・EPSS・SSVCはどう使い分けるのですか？

CVSSの基本値（Base）は技術的深刻度を、Threat・EPSS・CISA KEVは悪用の蓋然性を、Environmental・SSVCは自組織環境での影響と対応要否を評価します。基本値だけで優先順位を決めず、これらを組み合わせて自組織で本当に刺さるかを判断することが、要請が求めるリスクベースの実装です。

Q. 「パッチがない脆弱性」にはどう備えるべきですか？

WAF等による仮想パッチ、攻撃対象領域の縮小、特権IDのMFA、ネットワーク分離、EDR/SOC、包括的なログ取得、能動的停止を含むBCPで備えます。パッチ適用は引き続き重要ですが、パッチ提供前・CVE付与前の攻撃を想定した防御層が不可欠です。

Q. 金融機関は短期的に何をすべきですか？

外部公開システムを優先特定し、不要ポート閉塞・特権ID削除・サポート切れ更新で攻撃対象領域を減らし、CVSS基本値だけのゲートをやめて悪用観測と自組織露出の2軸を足し、ベンダー契約のSLA/SLOを同時多発前提で点検します。中長期的には、仮想パッチ・EDR/SOC・ネットワーク分離・特権MFA・能動的停止とBCPといった検知・対応・要塞化の層への投資を、パッチ適用と同格の本命として位置づけます。

参照（一次情報）

• 金融庁・日本銀行「『フロンティアAIによる脅威変化を踏まえた金融機関等の短期的な対応』に係る要請について」（2026年5月22日）：https://www.fsa.go.jp/news/r7/sonota/20260522-5/20260522.html （要請本文PDF：https://www.fsa.go.jp/news/r7/sonota/20260522-5/01.pdf ）
• 内閣官房 国家サイバー統括室ほか「AI性能の高度化を踏まえたサイバーセキュリティ対策の強化について 〜Project YATA-Shield〜」（2026年5月18日）：https://www.cyber.go.jp/pdf/press/20260518_AI_CS_Package.pdf
• UK AI Security Institute (AISI), "Our evaluation of Claude Mythos Preview's cyber capabilities"（2026年4月13日）：https://www.aisi.gov.uk/blog/our-evaluation-of-claude-mythos-previews-cyber-capabilities
• Anthropic, "Coordinated vulnerability disclosure dashboard"（2026年5月22日時点のスナップショット）：https://red.anthropic.com/2026/cvd/

---

本記事は公開された一次情報に基づくシンジ個人の分析であり、所属組織の見解を代表するものではありません。CVSS / EPSS / SSVC 等の枠組みの定義は各管理団体（FIRST、CISA等）の公開仕様に基づきます。