フロンティア AI による脅威変化への備え – 金融庁・日本銀行から金融機関等への要請と AWS サービスの活用

2026 年 5 月 22 日、金融庁と日本銀行は「フロンティア AI による脅威変化を踏まえた金融機関等の短期的な対応」に係る要請 (金総政第 3245 号ほか) を公表し、経営トップを含めた経営層の直接関与の下で、短期的な対応に取り組むよう金融機関等に要請しました。

要請では、いわゆる「フロンティア AI」により、脆弱性の発見・修正等のサイバーセキュリティ性能の急速な向上が見込まれることを踏まえ、これに対応する取組が必要不可欠とされています。フロンティア AI を用いてソフトウェアの脆弱性を発見・修正する取り組みとしては、2026 年 4 月に Anthropic が発表した Project Glasswing と、その中核となる新クラスのモデル Claude Mythos があります。AWS はこの取り組みのローンチパートナーの一社であり、AWS Blog 「AI を活用した大規模なセキュリティ防御の構築 – 脅威が出現する前に」で自らの取り組みを公開しています。

本記事では、金融庁・日本銀行の要請が求める 9 つの短期的対応のそれぞれについて、AWS のサービスと機能がどう役立つかを整理します。本記事で取り上げるサービスや機能は代表的な例であり、利用可能な選択肢のすべてを網羅するものではありません。また、AWS の利用だけで要請への対応が完了するものではなく、最終的な評価・統制・意思決定は各金融機関が行うものです。実際の対策の選定にあたっては、自組織のリスク特性やシステム構成を踏まえてご検討ください。

要請が指摘する脅威の変化

要請では、フロンティア AI により、従来は発見が困難だった脆弱性が短期間に発見され得ることに加え、脆弱性の発見から攻撃に至るまでの期間が大幅に短縮され得ることが指摘されています。規模の目安として、次の数字があります。2025 年の 1 年間に公開された CVE (共通脆弱性識別子) は 48,185 件 (前年比約 20% 増) でした。一方、Anthropic が公表した経過報告 (Project Glasswing: An initial update) によれば、Project Glasswing では約 50 のパートナー組織が Claude Mythos Preview を使い、開始から約 1 か月で深刻度 High または Critical の脆弱性を 1 万件超発見しています。さらに Anthropic 自身も 1,000 以上のオープンソースプロジェクトをスキャンし、モデルの推定を含め 23,019 件 (うち High/Critical は推定 6,202 件) の脆弱性候補を発見しました。Anthropic は発足時に、プロジェクトで得られた知見を 90 日以内に公に報告すると表明し、上記の経過報告として公開しました。また、発見された個々の脆弱性は、協調的脆弱性開示 (CVD) ポリシーに沿って、独立した検証とメンテナーへの通知、修正のための開示猶予期間を経て順次公開されています。これらの数字は、公開済みの CVE 件数とは期間・対象・検証状況が異なるため直接比較はできないものの、発見の後に続く検証・開示・修正の工程の処理能力が課題になり得ることを示しています。

ここで課題になるのが、パッチ適用までの時間差です。脆弱性が公表されパッチが公開されても、それを適用し終えるまでは脆弱性が残ります。この、公表から N 日が経過した既知の脆弱性を狙う攻撃は「N デイ攻撃」と呼ばれます (未知の脆弱性を狙うゼロデイ攻撃と対になる用語です)。Amazon の脅威インテリジェンスチームは、攻撃者が公開されたエクスプロイトを開示から数時間～数日で攻撃に転用する状況を観測しています。しかもこの速度は国家支援型のグループに限りません。公開された PoC や生成 AI の活用により、高度な技術を持たない攻撃者にも広がりつつあります。「四半期ごとに」「十分なテストを経てから」パッチを当てるという従来モデルでは、対応が間に合わない可能性があります。金融庁・日本銀行の要請でも、短期的に脆弱性やパッチが集中的に発見・提供される可能性を踏まえ、「経営トップを含めた経営層の直接関与」の下で迅速かつ適切に対応できる態勢の点検・強化が求められています。

一方で、英国 AI Security Institute (AISI) の評価報告 (Our evaluation of Claude Mythos Preview’s cyber capabilities) では、現時点のフロンティア AI は十分に防御された IT システムに対しては攻撃を達成できるとは言えないとされています。つまり、金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」に基づく基本的な対策を、より迅速かつ確実に実行していくことが、引き続き最も重要な出発点になります。

9 つの短期的対応に AWS サービスがどう役立つか

要請は 9 つの短期的対応を挙げています。これらは IT・サイバーセキュリティ担当部署のみで完結するものではなく、経営トップの正確な理解と危機意識の下で必要なリソース (予算・人員) を確保することが不可欠、というのが要請全体を貫く前提です。以下、各項目について AWS のサービスと機能でできることを整理します。

① フロンティア AI への対応を経営課題として扱う

この脅威は IT・サイバーセキュリティ部門にとどまらず、各業務所管部門・リスク管理・財務部門が横断的に連携すべき全社的な経営課題です。AWS では、サポート階層にかかわらず無料で利用できる Security Health Improvement Program (SHIP) や、AWS セキュリティ成熟度モデルを通じて、自組織の現状を客観的に把握し、経営として優先順位とリソース配分を判断するための材料を提供しています。セキュリティ成熟度モデルは過去 1 年間で世界の 50,000 を超えるお客様に利用されています。

② 優先的に対応すべきサービス/IT システムを特定する

どのシステムが重要業務を支えているか、その業務影響の評価はお客様自身にしかできない判断です。技術面で支援できるのは、その判断の前提となる資産の把握です。AWS Config や AWS Systems Manager のインベントリ機能を使うと、AWS 上のリソース構成や導入ソフトウェアを継続的に記録でき、「どこに何があるか」を洗い出す作業を支援します。そのうえで、Amazon Inspector がワークロードを継続的に監視し、新しい脆弱性が公開されるとニアリアルタイムで再スキャンして、CVSS (共通脆弱性評価システム) のスコアだけでなくネットワーク到達性や悪用可能性を加味したリスクスコアを算出するため、インターネットバンキング等を支える外部公開システムから優先的に対処する、といったリスクベースの絞り込みに役立ちます。さらに、後述する AWS Continuum (限定プレビュー) は、インフラ・アクセス許可・ネットワーク構成に加え、ドキュメントやビジネス上の優先事項といった組織のコンテキストを取り込み、IT 資産の重要度を考慮した対応の優先順位付けを支援します。

③ 特定した資産の技術負債を解消しておく

優先対象について、ソフトウェア構成・ネットワーク構成を再確認し、脆弱性発見時に即座にパッチ適用対象を特定できる状態を確保します。不要なネットワークポートの閉塞、特権 ID の削除、サポート終了製品のサポート対象バージョンへの更新が重要です。Amazon Inspector は監視対象リソースのソフトウェア部品表 (SBOM) を CycloneDX/SPDX 形式でエクスポートでき、サプライチェーンを含む構成の可視化に役立ちます。また、スタンドアロンツールの Amazon Inspector SBOM Generator を使うと、CI/CD パイプラインの中でコンテナイメージ等の SBOM を生成し、デプロイ前の脆弱性検出に活用できます。加えて、後述のマネージドサービスへの移行そのものが、OS・ミドルウェア層の技術負債を構造的に減らす有効な手段になります。

④ パッチ適用に係る人的リソースを追加する / ⑤ ベンダーとの維持保守契約を確認する

人的リソースの追加やベンダー契約 (SLA/SLO、夜間・休日対応、責任分担) の確認は、まず組織・契約面の課題です。技術面からは、2 つの時間軸で補完できます。

短期的には、今あるサーバーのパッチ作業自体の自動化です。AWS Systems Manager Patch Manager は、パッチベースラインとメンテナンスウィンドウを定義して、Amazon EC2 上のサーバーだけでなくオンプレミスのサーバーも含めてパッチの適用状況の確認と適用を自動化できます。手作業の適用・確認に費やしている時間を減らすことは、人的リソースの追加と同じ方向の効果を持ちます。

中長期的には、パッチ適用の対象そのものを減らすという考え方があります。AWS Lambda、Amazon API Gateway、AWS Fargate、Amazon Aurora Serverless、Amazon DynamoDB などのサーバーレス・マネージドサービスを活用すると、責任共有モデルのもとで、基盤となるインフラストラクチャや AWS が管理するランタイムのパッチ適用が AWS の責任範囲となり、お客様はアプリケーションコード、コンテナイメージ、およびそれらの依存関係など、お客様の責任範囲に集中できます。

マネージドサービスへの移行に際して、AWS 側で行われる基盤メンテナンスが業務に影響しないか、気になるかもしれません。この点は、AWS がマネージドサービスをどのような構造で提供しているかという、責任共有モデルの AWS 側の設計から説明できます。

ホワイトペーパー「AWS 障害分離境界」が説明するとおり、Amazon DynamoDB や Amazon SQS などのマネージドサービスの多くは「リージョンサービス」として提供されます。リージョンサービスは、AWS が物理的に分離された複数のアベイラビリティーゾーン (AZ) の上に構築したサービスであり、お客様が複数 AZ の活用方法を設計する必要はありません。たとえば Amazon S3 はリクエストとデータを複数の AZ に分散し、1 つの AZ の障害から自動的に回復するように設計されています。この冗長な構造が、基盤の一部を更新しながらサービス全体は稼働を続ける、という運用の土台になっています。各サービスには、月間稼働率のサービスコミットメントと未達時の取り扱いを定めた SLA (サービスレベルアグリーメント) が公開されています。

その更新のプロセスについて、AWS は CSA (Cloud Security Alliance) の Consensus Assessments Initiative Questionnaire (CAIQ) への回答の中で、本番環境へのすべての変更が「中断を最小化するための実装・ロールバック計画」「非本番環境でのテスト」「ピアレビュー」「承認」を経て、可能な限り手動ステップを排した継続的デプロイのパイプラインで実施されることを説明しています。個別のサービスにもこの設計は表れており、Amazon DynamoDB はバージョンやメンテナンスウィンドウという概念自体を持たず「アップグレードやダウンタイムを必要とせず、可用性、信頼性、パフォーマンス、セキュリティ、機能を継続的に改善」し、Amazon Aurora のダウンタイムのないパッチ適用 (ZDP: Zero-Downtime Patching) はエンジンのアップグレード中もクライアント接続の維持を試みます。実例として、Log4Shell (CVE-2021-44228) の際には、稼働中の JVM にライブでパッチを当てるホットパッチを AWS が開発してオープンソースとして公開し、AWS Fargate や AWS Lambda などのマネージドサービスの基盤には、お客様のアクションを必要とせず数日で展開しました。なお、要請ではクラウド事業者により提供される IT システムについて、パッチ適用に関する SLA/SLO の内容や適用状況が適切に報告される契約内容となっていることの確認が求められており、上記のホワイトペーパー・CAIQ 回答・SLA は、その確認の際の参考になります。

⑥ パッチ適用プロセスをリスクベースにする

CVSS スコアが高くない脆弱性でも実際の攻撃に使われる実態があり、この傾向はフロンティア AI によりさらに加速する可能性があります。Amazon Inspector は EPSS スコアや CISA の Known Exploited Vulnerabilities カタログ、公開された攻撃コードの有無、推奨パッチ適用期間といった脅威インテリジェンスを取り込み、攻撃が成立する蓋然性を踏まえた優先順位付けを可能にします。アプリケーションのテストとデリバリーについては、AWS CodePipeline を中心とした CI/CD パイプラインで自動ビルド・自動テスト・段階デプロイ・自動ロールバックを構成することで、テスト不足によるシステム障害リスクを抑えつつパッチ適用期間を短縮できます。

⑦ パッチ適用以外の対策も強化する

多層防御は、単一の対策の突破を前提に複数の防御層を重ねる、すべてのセキュリティ対策の基本です。パッチ適用も防御層の 1 つであり、適用そのものが困難な場合や適用までに時間を要する場合でも、他の層が攻撃の成立を防ぎ、被害を抑えます。要請では、こうした対策の例として、クラウド型の WAF 等を用いた「仮想パッチ」(個々の脆弱性に対応した侵入防御ルールにより、本来のパッチを早急に適用することが難しい場合に攻撃通信をブロックする暫定的なソリューション) の適用が挙げられています。AWS では、ウェブアプリケーションの層は AWS WAF が WAF 機能を提供し、既知の脆弱性を悪用する通信パターンをブロックするルールをまとめたマネージドルールが AWS により更新・提供されています。ネットワークの経路上では AWS Network Firewall が Suricata 互換の侵入防止システム (IPS) 機能を提供し、脆弱性を悪用する通信をシグネチャで検知・遮断するルールをまとめたマネージドルールグループが AWS により更新・提供されています。いずれも、アプリケーションやサーバーを修正するまでの間の防御層として利用できます。なお要請の脚注にあるとおり、こうした対策は恒久的な対応ではなく、パッチ適用までの暫定措置と位置づけることが重要です。このほか、ネットワーク分離、特権 ID への多要素認証、端末での不正検知・対応 (EDR) などがあります。要請が挙げる内部侵入後の横展開への対策としては、検知の層も必要です。

この多層防御の各層で活用できるのが、AWS の脅威インテリジェンスです。AWS は 1 日あたり 400 兆を超えるネットワークフローを分析し、ハニーポットシステムの MadPot と、その脅威インテリジェンスをもとに悪意のあるアクティビティを自動的に制限する Sonaris を核とするアクティブディフェンスを運用しています。2025 年だけで Amazon S3 上のファイルへの不正暗号化の試み 3 億件超をブロックしました。この脅威インテリジェンスは AWS 内部の防御にとどまらず、お客様が利用できるサービスにも組み込まれています。Amazon GuardDuty は AWS とサードパーティーの脅威インテリジェンスを機械学習と組み合わせてアカウントとワークロードのログを継続的に分析し、既知の脅威アクターとの通信や認証情報の悪用など、侵入後の横展開の兆候を検出します。AWS Network Firewall のアクティブ脅威防御は、MadPot が追跡するマルウェア URL やボットネットの C&C サーバー等の攻撃インフラを、マネージドルールグループ「AttackInfrastructure」として提供し、これらとの通信を自動的にブロックします。前述の AWS WAF マネージドルールも、この脅威インテリジェンスの還元先の 1 つであり、パッチ適用までの防御層として機能します。実例として、React2Shell (CVE-2025-55182) では公開から数時間以内に国家支援型グループの悪用試行を MadPot で観測し、Sonaris・AWS WAF マネージドルール等による多層の自動保護を展開したことをブログで公開しています。

⑧ 優先サービス/IT システムの停止に備える

各種対策を徹底してもサイバー攻撃を防ぎきれない可能性を前提に、事業継続計画 (BCP) の有効性や緊急時の連絡体制、能動的なサービス停止の判断基準を明確にしておくことが求められます。これは共同運営形態やクラウド事業者が提供する IT システムについても同様です。マネージドサービスを活用している場合、基盤の可用性は AWS の責任範囲に含まれますが、業務要件に応じた構成、復旧目標、依存関係の整理、停止判断はお客様が設計・検証します。業務停止時の顧客対応手順も、引き続きお客様側で整備しておく必要があります。停止後の復旧の備えとしては、AWS Backup の論理的にエアギャップされたボールトへのバックアップ保管が、ランサムウェア等でデータが侵害された場合の復旧手段の 1 つになります。

⑨ 外部との連携を維持・強化する

フロンティア AI に関する情報は短期間に多数公開されるため、自組織のみでの網羅的な把握は困難です。金融 ISAC や各業界団体・当局からの情報に積極的にアクセスするとともに、AWS からは AWS Security Bulletins や、Amazon の脅威インテリジェンスチームによる注意喚起ブログを通じた情報を継続的に提供しています。

AI の活用で脆弱性の発見を早める

要請への対応は「公開されるパッチにいかに追いつくか」が中心です。一方で Anthropic は、Project Glasswing の拡大発表の中で、6～12 か月以内に他の多くの AI 企業も Mythos クラスのモデルを持つと予想され、悪用を防ぐセーフガードなしにリリースされる可能性があると述べています。同様の能力が広く利用可能になれば、パッチが存在しない未知の脆弱性を突くゼロデイ攻撃への備えも重要性を増します。その 1 つとして、お客様自身が AI を活用して脆弱性を発見・修正するアプローチがあります。

AWS Security Agent (現在は AWS Continuum の一部) は、一般提供が開始されたオンデマンドペネトレーションテストにより、24 時間 365 日稼働する自律型のテストを手動テストと比べてわずかなコストで提供します。潜在的な脆弱性を特定した後に実際にエクスプロイトを試み、正当なリスクであることを検証したうえで、CVSS スコア・再現手順・修正提案付きでレポートします。設計ドキュメントや設計・ソースコードからの脅威モデリング (STRIDE 形式、プレビュー)、プルリクエストごとの自動スキャンとリポジトリ全体の深い分析の両方に対応するコードレビュー (プレビュー)、数時間で完了するペネトレーションテストと、設計からデプロイまでの開発ライフサイクル全体をカバーします。ペネトレーションテストは、AWS 上の環境だけでなく、他社クラウド上で稼働するシステムやオンプレミス、SaaS 環境にも対応します。新規のお客様は 2 か月間の無料トライアルを利用できます。

さらに、脆弱性を「見つけた後」の工程をマシンスピードで処理するのが AWS Continuum です。フロンティア AI により脆弱性の発見は速く・安価になった一方、どの脆弱性が自社のビジネスにとって重要かを判断し、実際に悪用可能かを検証し、修正までつなげる後工程は、人手による判断と部門間の調整に依存したままでは追いつきません。Anthropic 自身も、Project Glasswing の教訓として「制約は脆弱性を見つける速さではなく、検証・開示・修正の速さに移った」と述べています。Continuum for code vulnerabilities (限定プレビュー) はこの工程を対象とし、発見・優先順位付け・検証・緩和と修復という 4 つのフェーズを、脅威が生まれるのと同じマシンスピードで継続的に実行します。既存ツールの検出結果と独自スキャンを取り込み、インフラ・アクセス許可・ネットワーク構成などのコンテキストからビジネス影響を評価して優先順位付けし、隔離されたサンドボックス内で再現可能なエクスプロイトの構築を試みることで、悪用可能性が確認された問題に絞り込んだうえで、コードパッチやポリシー変更を提案します。これは、発見された脆弱性について「攻撃が成立する蓋然性も踏まえた評価」と「リスクベースの優先順位付け」を求める要請⑥の趣旨に沿ったアプローチです。動作は人間が推奨内容を確認して承認する learn モードから始まり、お客様の判断で自動修復 (enforce モード) へ段階的に引き上げる設計です。なお Continuum for code vulnerabilities は限定プレビューの段階にあり、金融サービス業界のお客様のフィードバックとともに形作られています。

独自のセキュリティワークフローを構築したい組織には、Amazon Bedrock 上で複数のプロバイダーの最新フロンティアモデルから用途に合ったものを選ぶ選択肢があります。AWS PrivateLink の VPC エンドポイントを介して、インターネットを経由せずお客様の VPC から Bedrock に接続できます。ポリシー適用型のアクセス制御、モデルの検出効果を測る組み込みの評価ツール、お客様が定義したポリシーやドメインルールとの論理的一貫性を形式的手法で検証する自動推論チェック (AWS が公表した評価の範囲で最大 99% の検証精度)、カスタマイズ可能なガードレールを備え、自社のソースコードのスキャンを支援するワークフローの構築に活用できます。Amazon Bedrock は、日本政府のクラウドサービス評価制度である「政府情報システムのためのセキュリティ評価制度 (ISMAP)」の対象範囲に含まれています。また、Amazon Bedrock Marketplace を除き、Payment Card Industry Data Security Standard (PCI DSS) の対象範囲にも含まれています。これらの情報は、お客様が自組織のセキュリティ・コンプライアンス要件への適合性を評価する際の参考資料として利用できます。

まとめ – 今すぐ着手すること、中長期で取り組むこと

フロンティア AI による脅威変化への対応は、2 つの観点から整理できます。

Project Glasswing 以降のパッチ公開ペースの変化に対しては、 今すぐパッチ適用を日常業務化し、インシデント対応体制を変革すること。中長期では、マネージドサービスを多用した IT システムのモダナイズにより、基盤レイヤーのパッチ運用の一部を AWS に委ね、お客様の運用負荷を軽減していくこと。

フロンティア AI の一般化により攻撃の高度化やゼロデイ攻撃のリスクが高まる可能性に対しては、 今すぐ AI を活用した脆弱性スキャンとセキュリティレビュー (AWS Security Agent、Amazon Bedrock + 最新モデル) で発見を早めること。中長期では、侵害を前提とした多層防御を徹底し、攻撃の影響を最小化すること。

いずれも、金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」に基づく基本的な対策を確実に実行することが土台です。まずは自組織の現状把握から始めることをお勧めします。無料アセスメントプログラムの SHIP と AWS セキュリティ成熟度モデルをご活用いただけますので、担当の AWS アカウントチームにお気軽にお声がけください。

早見表 – 金融庁・日本銀行の要請と AWS サービスの活用

金融庁・日本銀行が求める 9 つの短期的対応について、AWS のサービス・機能がどう役立つかを一覧に整理しました。

加えて、公開されるパッチへの追随の先にある、AI による攻撃の高度化やゼロデイ攻撃への備えとして、AWS Security Agent (一般提供のペネトレーションテストに加え、脅威モデリングとコードレビューはプレビューで提供)、AWS Continuum (限定プレビュー。脆弱性の発見から優先順位付け・検証・修復までのライフサイクル全体をマシンスピードで自律処理)、Amazon Bedrock + 最新フロンティアモデル (ソースコードのセキュリティレビューを支援するワークフローの構築。VPC エンドポイント経由で接続可能) をご活用いただけます。

関連情報

• 「フロンティア AI による脅威変化を踏まえた金融機関等の短期的な対応」に係る要請について (金融庁)
• AI を活用した大規模なセキュリティ防御の構築 – 脅威が出現する前に
• AWS Continuum のご紹介: マシンスピードで実現するセキュリティ
• AWS Security Agent のオンデマンドペネトレーションテストの一般提供を開始
• FISC 安全対策基準・解説書に関する AWS の情報

本記事は、金融庁・日本銀行「フロンティア AI による脅威変化を踏まえた金融機関等の短期的な対応」に係る要請 (2026 年 5 月 22 日) および AWS の公開情報に基づいて作成しています。本記事で紹介するサービス・機能は代表的な例であり、すべての選択肢を網羅するものではありません。また、特定の対策の実施により被害の防止を保証するものではありません。記載のサービス仕様・提供状況・料金は変更される場合があります。最新情報は各サービスの公式ドキュメントをご確認いただき、具体的な対策の選定は自組織の環境に応じてご判断ください。

著者

能仁 信亮 (Shinryo Nonin) – 金融ソリューション本部 プリンシパルソリューションアーキテクト

中島 章博 (Akihiro Nakajima) – パブリックセクター技術統括本部 シニアセキュリティソリューションアーキテクト