2026年7月7日、欧州中央銀行（ECB）は監督下にあるすべての銀行の最高経営責任者に対し、AIを用いたサイバー攻撃に対する正式な行動計画を策定し、10月31日までに担当の監督チームへ提出するようにという内容を記載した書簡を送りました。
　書簡は、監督理事会議長、Claudia Buch氏直筆の署名が付いており、フロンティアAIのサイバーリスクに関してこれまでに公開された規制当局のプレイブックの中でも詳細に書かれた内容となっています。対象範囲は、名前に「ヨーロッパ」が付いた銀行だけでなく、JP Morgan Chase、Goldman Sachs、Citi、Morgan Stanleyがユーロ圏に持っている子会社もECBの監督下にあるとして、フランクフルトやパリの銀行と同じ期限を守ることになっています。American Banker（米国・ニューヨークを拠点とする、金融・銀行業界に特化した歴史ある独立系の専門メディア）の報告によれば、米国のどの規制当局も同等の要件を設定していない一方で、米国の主要金融機関はすでに同様のリスクについて監督当局から「対処できない程の膨大な質問が寄せられている」状態のようです。

こうした状況を踏まえると、欧州におけるECBは、日本やアメリカを含む世界の先行事例となる可能性があるといえるでしょう。

書簡の内容で注目すべき点は、ECBが求めている項目の大半がソフトウェア・サプライチェーンに関わるものであるという点です。すなわち、第三者が開発したソフトウェアやオープンソースコンポーネント、開発パイプラインといった銀行がここ10年にわたってあらゆるものに組み込んできたものを指します。

なぜ今なのか：原因はたった数分で構築できる攻撃コード

　ECBは、新たに登場しているAIモデルは「かつてない速度で脆弱性を発見・攻撃コードを生成でき、脆弱性の発見から攻撃コードの生成までの時間を縮める」と率直に見立てています。Buch氏は、これを「一時的な現象や特定のツールに結びついたリスクではなく、脅威となる環境の長期的な変化」とみなしています。
　同日、欧州システミックリスク理事会は、フロンティアモデルは完全自動化した攻撃を実行でき、人間が「数日または数週間」かかるところを「数分または数時間」で動作する攻撃コードを構築できるという内容の警告を公式に発表しており、この変化を「対応の時間的猶予が崩壊」していると捉えています。同理事会が一番懸念しているのは、被害規模です。脆弱性をついた脅威の波が多くの金融機関を同時に襲った場合、「利用できる有効なリスク軽減の枠組みがゼロ」になると考えています。

　そして、その仮説は現実味を帯びています。今年のはじめ、Anthropicは、厳重に制限されたフロンティアモデルが、主要なオペレーティングシステムやブラウザにそれまで気づかなかった脆弱性を数多く発見したことを報告しました。ECBの書簡の付属文書に記されている英国のNCSCはセキュリティ担当者に対し「脆弱性パッチの波」へ備えるよう伝えています。
　攻撃コードの開発が数週間から数分へと縮まると、人間の速度を前提とするあらゆるプロセス（月ごとのパッチサイクル、四半期ごとの依存関係レビュー、年単位での侵入テストなど）はいつ破綻してもおかしくない状態に陥ってしまいます。

ECBが実際に要求している項目とは

提出期限が10月31日である行動計画には、具体的な措置内容、責任者の氏名、割り当てられた予算および人員、そして実施日程を含めなければなりません。これらはすべて以前から取り上げているDigital Operational Resilience Act（DORA）に基づく既存の義務を満たすものとして位置づけられています。書簡の付属文書には、6つの重要な分野が説明されています。そのうち3つは、アプリケーションセキュリティとソフトウェア・サプライチェーンに直接関わる分野です。

攻撃対象領域を保護する最初のステップは、自分の所有する資産を知ること　

　書簡では、短期的な最優先事項として「第三者が開発したソフトウェアやオープンソースコンポーネントなど」のICT資産を特定することを挙げており、「修正対応の優先順位付けをする上での鍵」だと説明しています。インベントリを把握できていないものは、攻撃への対策、パッチ対応や廃止を実施することはできません。そして多くの銀行の場合、それはアプリケーションの下のオープンソースの依存関係ツリーです。

脆弱性管理とパッチ管理は「大規模に」加速しなければならない

　ECBは、「ベンダーやオープンソースコミュニティ―、さらには社内で開発されたソフトウェアが脆弱性を素早く特定し修正」できるようになれば、「パッチ対応の頻度や量が改善」すると見込んでいます。ECBは脆弱性スキャンを優先し、さらには安全対策、人間による監督、そして堅牢なリスク管理を含めることを条件に、AIを用いたセキュリティツールの環境づくりを強く推奨しています。

セキュリティ・バイ・デザインで問題を上流で解決・削減

　構造対策において「セキュリティ・バイ・デザインに基づいたソフトウェア開発の実践は、納期だけでなく安全なコードの適切な考慮によって、デプロイ前の脆弱性の対策」につながります。デプロイ後の欠陥が少ないほど、その後の緊急パッチ対応も少なくなります。これこそ、四六時中襲ってくる攻撃コードに対して持続的に機能する対策です。
　その他の分野（監視と検知、ガバナンスとサプライチェーンの保証、そしてオペレーショナル・レジリエンス）も同様です。理事会は、ICTの予算、人員、さらにはツールの環境づくりが加速するパッチ対応にとってプラスに働くかを検証しなければならず、金融機関はICTを提供する事業者の「加速する脆弱性の開示とパッチ対応への準備状況」を把握しなければなりません。
　ECBは、銀行はこの取り組みに集中できるようにするため、年次のIT Risk Questionnaireの提出期限を2026年9月から2027年2月へ変更しました。

要求内容と対応時間とのギャップ

セキュリティチームにとって「パッチ管理を大規模に加速せよ」とは、どれくらいの規模を指すのかが正直な疑問です。

当社では、最近、実際の侵入事案から1,000件を超えるAIエージェントの攻撃セッションを分析しました。結果はECBの見立てと変わりませんでした。つまり、攻撃側はAIが発見した特殊なゼロデイ脆弱性を悪用する代わりに既知かつ公開済みのCVEを露出しているインフラに対して、超高速で24時間休みなく兵器化し、さらに、侵入経路の入口やリスクが発生した際は遮断できる状態でも、それを行う時間が足りないことが問題だということです。

これが、ECBがいま理事会レベルで義務化に着手している「トリアージ」、つまり優先順位付けの問題です。典型的な企業のアプリケーションをみると、その組織以外が書いたコード（オープンソースのパッケージ、推移的依存関係、ベンダー提供のコンポーネント）が大半を占め、バックログが数千件に達している状態です。脆弱性の公開から悪用までの時間が短縮されると、「次のスプリントで対応する」は、そのリスクを引き受けるという判断になります。ECBは、その判断を理事会が正式に自らの責任として引き受け、指標と許容度の限界をリスク許容度の枠組みに盛り込むことを求めています。
　これはECBが書簡に前提として定めているように、人間のみで対応できる規模ではありません。だからこそ、銀行に対して単なる努力を促すのではなく、AIを活用した対策とスキャンに優先順位をつけることを推奨しています。

要求への対応：自動化可能な部分を自動化

ここでは、現代的なアプリケーションセキュリティのプラットフォームがECBのチェックリスト項目に直接紐づいている部分を紹介します。

オープンソースも含めて、自社の攻撃対象領域を把握すること

Mend.ioは、推移的依存関係も含め、アプリケーション内のすべてのオープンソースおよび第三者が開発したコンポーネントの完璧かつ継続的に更新されるインベントリを構築し、規格に基づいたソフトウェア部品表（SBOM）として表現します。これは書簡で最初に記載されている要件（優先順位を付けた修正対応の基礎としての資産の特定）を満たすもので、サプライチェーンの保証担当チームに、DORAのレビュー担当者が求める証拠を提供します。

規制当局が求める優先順位付けを実施すること

ECBが「脆弱性スキャンに優先順位」を求めているのは、CVEの総数が対処しきれないほどのレベルにのぼっているからです。Mend.ioの到達性分析は、アプリケーションが実行するコードに潜む脆弱性と、長く使用されていない経路のなかにある脆弱性を区別します。そうすると、チームは短縮した修正対応の時間を、AIを活用した攻撃側が実際に到達しうる侵入経路の発見に充てることができます。

超高速でパッチ対応を行うこと

　「量の多いパッチ対応」は、まさに依存関係の自動化が存在する理由です。Mend Renovateは、古くなった依存関係や脆弱性を含んだ依存関係を自動的に検出し、テスト済みの新しいプルリクエストを作成し、エンジニアが時間を消費することなく大量のリポジトリを最新の状態に保ちます。
　それによって、パッチの波は人員不足の危機から裏側で自動的に実行される処理へと変わります。これこそが、ECBが説明する「AIベースのツール……適切な対策[と]人間による監督を伴う」という自動化による提案、人間による承認を経て記録されるという形です。

デプロイ前にセキュリティを確認

　書簡が説明するセキュリティ・バイ・デザインは、本番環境ではなくパイプラインで行うことが求められています。Mend SASTとコンテナスキャンは、自社で書いたコードとイメージの欠陥をリリース前に検知します。Mend AIは、同じ規律を最新の攻撃対象領域、すなわちアプリケーションに組み込まれているAIモデル、エージェント、AI生成コードにまで広げます。

　以上の項目は、ECBが求めるすべての項目を網羅するものではありません。古い基幹システムの廃止、ネットワークのセグメンテーション、危機管理訓練は、AppSecプラットフォームでは代行できないインフラ作業です。しかし、要求項目の中でソフトウェア・サプライチェーンにあたる分野は自動化が可能です。それを自動化すれば、自動化できない分野に人員を割けることができます。

規制当局からの書簡が届く前にやるべきこと

OCCはすでに、AIが「サイバー脅威の環境を大きく変えつつある」と述べています。イングランド銀行、FCA、英国財務省は、5月にフロンティアAIとサイバーレジリエンスに関する共同声明を発表しました。FS-ISACは、業界に向けてAIを利用した脆弱性の発見に関する注意喚起を公開しています。Five Eyesに参加している各国も共同声明を出しています。ECBからの書簡は提出期限に関する情報だけでなく、Buch氏はすでにポスト量子暗号についての続報を発表すると約束しています。
ECBの監督下にある金融機関は、10月31日が行動計画の提出期限です。つまり、インベントリの構築や優先順位付け、自動化の下地づくりは、いまから始める必要があります。監督下にない金融機関でも予告として受け取ってください。
いずれにせよ、ECBがリストの一番目に記載したように、自社のソフトウェア、そしてその構成要素を正確に把握することが最初のステップです。