金融庁・日銀のAIサイバー要請を読む:9項目を自社システムに落とす実務

金融庁・日銀が2026年5月22日に金融機関へ要請した、フロンティアAI時代の短期的なサイバー対応9項目をファクトチェックし、一般企業が今すぐ自社システムへ落とすための技術スタックと実務手順を整理します。

著者
岡崎 太
CTO / AIアーキテクト
公開日
読了時間
11分で読めます
Share

ITmedia NEWS は 2026 年 5 月 25 日、金融庁と日本銀行が金融機関に対して AI サイバー攻撃への短期対応を要請したと報じました。

元記事の見出しは、「金融庁・日銀、金融機関にAIサイバー攻撃の対策要請 対応の優先度決定など9項目」 です。この記事が扱っている「9項目」は、金融庁が 2026 年 5 月 22 日に公表した 「フロンティアAIによる脅威変化を踏まえた金融機関等の短期的な対応」に係る要請 と、その別添 PDF に対応しています。

本記事では、ITmedia の報道内容を一次情報で確認したうえで、金融機関に限らず、SaaS、業務システム、Web サービス、受託開発会社がどう読み替えるべきかを整理します。

結論から言うと、今回のポイントは「AI が怖い」という一般論ではありません。脆弱性の発見速度が上がり、攻撃コード化までの時間が短くなる前提で、資産管理、優先順位付け、パッチ適用、代替防御、停止判断を経営判断として準備することです。

ファクトチェック:報道内容はどこまで一次情報で確認できるか

まず、主要な事実関係を確認します。

確認項目判定根拠
金融庁と日銀が共同で要請した確認済み金融庁の公表ページは、2026 年 5 月 22 日に金融庁・日本銀行の連名で要請したと明記している
要請は「フロンティアAI」による脅威変化を前提にしている確認済み金融庁 PDF は、脆弱性発見・修正などのサイバーセキュリティ性能の急速な向上を前提にしている
短期対応は 9 項目確認済み金融庁 PDF の別添に ① から ⑨ までの対応項目が並ぶ
概ね 1 ヶ月程度を目途に対応が期待されている確認済み金融庁 PDF の脚注に、AI モデル開発企業の活動状況も踏まえて概ね 1 ヶ月程度とある
システムの能動的な停止も選択肢に含まれる確認済み⑧「優先サービス/IT システムの停止に備える」に、能動的停止を選択肢として検討すべきとある
Claude Mythos Preview の能力は外部評価でも確認されている一部確認済み英国 AISI は弱く防御された環境での攻撃能力を確認。一方で、十分に防御された実環境への攻撃可否までは断定していない

重要なのは最後の行です。Anthropic は Claude Mythos Preview のサイバー能力評価 で、重大な脆弱性発見能力を強調しています。英国 AI Security Institute も 評価結果 を公開し、CTF や模擬企業ネットワーク攻撃で大きな性能向上を確認しています。

ただし、AISI は「よく防御されたシステムを攻撃できる」とまでは言っていません。金融庁 PDF も同じ注意を置いたうえで、基本的なサイバーセキュリティ対策をより速く、着実に実行することが重要だと整理しています。

つまり、今回の対応はパニックではなく、守る側も AI を使って防御の運用速度を上げるべき段階に入ったという話です。

9項目を、一般企業のシステム対応に翻訳する

金融庁・日銀の要請は金融機関向けですが、実務の中身はほとんどの企業システムに通用します。ここでは 9 項目をすべて挙げ、対応に必要な技術スタックに翻訳します。

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

これは CISO や情報システム部門だけの話ではありません。脆弱性対応には、予算、人員、リリース判断、ベンダー調整、顧客説明が絡みます。経営が意思決定しなければ、優先順位は決まりません。

必要なスタックは、リスクレジスター、経営向けダッシュボード、インシデント指揮体制、意思決定ログ、セキュリティ予算の即時配分プロセスです。ツール名で言えば、GRC、チケット管理、BI、インシデント管理、Slack/Teams の緊急連絡ルームが最低限の土台になります。

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

すべてを同じ優先度で守ることはできません。まず外部公開されているシステム、認証・決済・個人情報・管理者機能を持つシステム、停止すると売上や顧客に直撃するシステムを切り出します。

必要なスタックは、CMDB、クラウド資産棚卸し、外部公開面のスキャン、ドメイン・サブドメイン管理、データ分類、SLO/SLA 管理、システム重要度タグです。AWS Config、Security Hub、Cloud Asset Inventory、Wiz、Prisma Cloud、OpenCTI、SecurityScorecard 系の可視化もこの層に入ります。

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

ここで言う技術負債は、古いライブラリだけではありません。不要なポート、残った特権 ID、サポート切れ OS、放置された管理画面、更新不能なミドルウェア、手作業でしかデプロイできない構成も含みます。

必要なスタックは、SCA、SAST、IaC スキャン、シークレットスキャン、EOL 検知、SBOM、CSPM、パッチ管理、構成管理です。GitHub Dependabot、Renovate、Snyk、Trivy、Semgrep、CodeQL、osv-scanner、Syft/Grype、Terraform scan、Ansible、MDM/EDR などが候補になります。

4. パッチ適用に係る人的リソースを追加する

AI によって脆弱性発見が増えるなら、パッチ判断、検証、リリース、ロールバックの人手も増えます。セキュリティ担当だけで抱えると詰まります。

必要なのは、脆弱性トリアージ担当、アプリケーション担当、インフラ担当、QA、ベンダー窓口を横断した短期チームです。技術的には、CI/CD、テスト自動化、ステージング環境、リリース承認フロー、当番表、Runbook、AI コードレビュー支援が必要です。

5. ベンダーとの維持保守契約の内容を確認する

自社だけ準備しても、保守ベンダーやクラウド事業者が動けなければ対応は止まります。夜間・休日の緊急対応、SLA/SLO、パッチ適用の対象範囲、報告義務、責任分界点を確認する必要があります。

必要なスタックは、契約台帳、SLA/SLO 管理、ベンダー連絡網、変更管理、共同 Runbook、クラウド事業者のセキュリティ通知購読、PSIRT 連携です。システム面では、委託先が何を持ち、何を直せるのかを、資産台帳と紐づけておくことが重要です。

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

CVSS が高い順に全部対応するだけでは不十分です。実際に攻撃されているか、外部公開されているか、自社の構成で攻撃が成立するか、回避策があるか、停止時の影響は何か。ここまで見て順番を決めます。

必要なスタックは、CVSS、EPSS、CISA KEV、JPCERT/CC や IPA の注意喚起、脅威インテリジェンス、実資産との突合、攻撃可能性評価、カナリアリリース、自動テスト、ロールバックです。AI はここで特に効きます。脆弱性情報と自社コード・構成を突き合わせ、「この CVE はこのサービスに影響するか」を一次判定させられるからです。

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

すぐにパッチを当てられないシステムは必ずあります。そのときに WAF、仮想パッチ、ボット対策、ネットワーク分離、MFA、EDR、ログ監視などで時間を稼ぎます。

必要なスタックは、WAF、WAAP、Bot Management、API Gateway、Rate Limit、Zero Trust Access、EDR/XDR、SIEM、SOAR、IDS/IPS、ネットワークセグメンテーション、特権 ID 管理、多要素認証です。Cloudflare、AWS WAF、Google Cloud Armor、Azure Front Door、Okta、Entra ID、CrowdStrike、Microsoft Defender、Datadog、Splunk、Elastic Security などが代表例です。

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

今回の要請で最も経営判断に近いのがここです。攻撃を防げない可能性を前提に、能動的にサービスを止める判断基準と手順を用意する。金融機関でなくても、これは必要です。

必要なスタックは、BCP、DR、バックアップ、復旧手順、ステータスページ、顧客連絡テンプレート、Feature Flag、Kill Switch、メンテナンスモード、トラフィック遮断、DNS 切替、Read-only モードです。LaunchDarkly、Unleash、Cloudflare、Fastly、各クラウドの Traffic Manager、ステータスページ、監視ツールが関係します。

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

AI によって情報量が増えると、自社だけで追い切るのは無理です。業界団体、ISAC、ベンダー、クラウド事業者、当局、コミュニティから情報を取りに行く必要があります。

必要なスタックは、脅威インテリジェンスの購読、セキュリティ通知の集約、CSIRT/PSIRT、情報共有コミュニティ、社内展開プロセスです。金融 ISAC に限らず、JPCERT/CC、IPA、各クラウドの Security Bulletin、OSS の Security Advisory、GitHub Security Advisory を日常的に監視する体制が必要です。

まず自社のソースコードに、生成AIで質問を投げる

ここからが、CTO としての私の実務的な見解です。

今回の要請を読んで、最初にやるべきことは大がかりなセキュリティ製品の導入ではありません。今ある自社システムのソースコード、IaC、依存関係、設定ファイルに対して、生成AIへ質問を投げることです。

たとえば、次のように聞きます。

このリポジトリを読んで、外部公開されているエンドポイント、
認証が必要な管理機能、個人情報・決済・ファイルアップロードを扱う処理、
高い権限を持つバッチや管理者APIを一覧化してください。
それぞれについて、優先的に脆弱性確認すべき理由も添えてください。

次に、もう一段具体化します。

このシステムについて、依存ライブラリ、Dockerfile、CI設定、
TerraformやCloudFormationなどのIaC、環境変数の参照箇所を確認し、
サポート切れ、過剰権限、不要な公開ポート、シークレット漏えいリスク、
パッチ適用時に壊れやすい箇所を洗い出してください。

この時点では、完璧な診断を期待しすぎなくて構いません。重要なのは、AI に「自社システムの地図」を作らせることです。どのサービスが外に出ているのか、どの依存関係が古いのか、どの設定が危ないのか、どのテストを通せば安全にリリースできるのか。これが見えていないと、9 項目のどれも実行できません。

事前にソースコードをAIで解析しておくと精度が上がる

スコープが大きいシステムでは、いきなり「脆弱性を探して」と聞いても精度は上がりません。AI が迷子になります。

先にやるべきことは、リポジトリの構造、主要モジュール、データフロー、認証境界、外部公開面、依存関係、テストコマンド、デプロイ方法を AI に整理させることです。いわば、AI が読める形のシステム棚卸しです。

私なら、最初に次の成果物を作らせます。

  1. システム全体のコードベースマップ
  2. 外部公開 API と画面の一覧
  3. 認証・認可・管理者権限の境界
  4. 個人情報、決済、機密データの流れ
  5. 依存ライブラリと実行基盤の一覧
  6. CI/CD、テスト、デプロイ、ロールバック手順
  7. 重要システムごとの停止判断と復旧手順のたたき台

この準備をしてから AI に脆弱性管理、パッチ適用、WAF ルール、テスト縮小、停止判断を相談すると、回答の精度が大きく上がります。AI は魔法の診断士ではありません。よい地図を渡されたエンジニアのように働かせるほうが、実務では強いです。

もちろん、ソースコードや設定ファイルを外部の生成AIサービスに投入する場合は、機密情報、顧客情報、シークレット、契約上の制約に注意が必要です。エンタープライズ契約、学習利用の有無、ログ保持、権限管理、ローカル実行環境の選択は必ず確認してください。

いま持つべき技術スタックの全体像

今回の 9 項目を自社で回すには、次のようなスタックが必要になります。

領域目的主な技術
資産管理何を守るかを決めるCMDB、クラウド資産棚卸し、SBOM、ドメイン管理
脆弱性検知何が危ないかを見つけるSCA、SAST、DAST、IaC スキャン、シークレットスキャン
優先度判断どれから直すかを決めるCVSS、EPSS、KEV、脅威インテリジェンス、実資産との突合
修正と検証速く安全に直すCI/CD、自動テスト、ステージング、カナリア、ロールバック
代替防御パッチ前に時間を稼ぐWAF、仮想パッチ、Rate Limit、EDR、MFA、ネットワーク分離
監視と対応攻撃・障害を見逃さないSIEM、SOAR、ログ基盤、APM、オンコール、Runbook
停止と復旧止める判断を実行できるBCP、DR、Feature Flag、Kill Switch、ステータスページ
AI活用棚卸しと判断を速くするコード解析エージェント、RAG、リポジトリマップ、AIレビュー

ここでの AI 活用は、セキュリティ担当者を置き換えるものではありません。むしろ、担当者が見るべき対象を絞り込み、初動の棚卸しと仮説出しを速くするためのものです。

岡崎太としての見解

今回の金融庁・日銀の要請は、金融機関だけの話として読まないほうがいいです。金融庁が先に明文化しただけで、同じ問題は SaaS、EC、医療、教育、製造、自治体、受託開発、社内業務システムにも来ます。

AI によって攻撃側の探索速度が上がるなら、防御側も「会議してから棚卸し」では遅い。まず自社のソースコード、依存関係、クラウド設定、公開面を AI に読ませ、重要システムの一覧とリスク仮説を出す。そのうえで、人間が優先順位とリリース判断を決める。ここまでを短いサイクルで回すべきです。

特に CTO や開発責任者は、次の 3 つをすぐに確認してください。

  1. 外部公開されている重要システムを 24 時間以内に一覧化できるか
  2. 重大 CVE が出たとき、自社への影響有無を 48 時間以内に判断できるか
  3. パッチを当てられない場合、WAF、MFA、停止、縮退運転のどれを選ぶか決めているか

この 3 つに答えられないなら、まず AI に質問して棚卸しを始めるだけでも前進です。完璧なセキュリティ体制を待つ必要はありません。最初の一手は、自社システムの現在地を AI と一緒に可視化することです。

参考資料

アイキャッチ画像:Rs1421, Kasumigaseki-Common-Gate-02.jpg, CC BY-SA 3.0。記事用にトリミングし、文字要素を重ねています。