修正プログラム（パッチ）が一気に増えたら？直す順番の決め方をやさしく解説

金融庁と日本銀行が2026年5月に公表した要請では、ソフトウェアの弱点が一気にたくさん見つかり、それを直すための修正プログラムも一気に増える状況が想定されています。そうなったとき、全部にすぐ手を回すのは現実的ではありません。この記事では、そんなときの「順番の決め方」について、なるべく専門用語を使わずに説明します。

修正プログラム（パッチ）とは何か

ソフトウェアには、作った人が気づかないまま残ってしまう欠陥があります。これを「脆弱性（ぜいじゃくせい）」と呼びます。建物にたとえるなら、鍵のかかっていない窓のようなもので、悪い人に見つかると、そこから侵入されてしまいます。

この欠陥が見つかると、ソフトウェアを作った会社が修理用のプログラムを配ってくれます。これが「修正プログラム」、いわゆるパッチです。窓に鍵を取りつける修理にあたります。届いたら当てる（適用する）のが基本の流れです。

• 脆弱性：ソフトウェアに残ってしまった欠陥。鍵のかかっていない窓のようなもの
• パッチ：脆弱性を直すための修正プログラム。窓に鍵を取りつける修理にあたるもの
• CVSS：脆弱性の危険度を0.0〜10.0の点数で表した、世界共通のものさし
• ベンダー：システムの構築や保守を請け負っている外部の会社
• SLA：サービスの品質について、どこまで対応するかをあらかじめ約束した取り決め
  
  なお、そもそもフロンティアAIとは何か、なぜ各国がルールづくりを急いでいるのかについては、別記事で基礎から解説しています。
  「フロンティアAI」とは？なぜ今ルールづくりが進んでいるのかをやさしく解説

なぜパッチが一気に増えると考えられているのか

修理する箇所が1か所や2か所なら、順番に対応していけば済みます。ところが、フロンティアAIによって弱点が短い期間に大量に見つかると、修理の指示も一気に押し寄せます。窓の欠陥が100か所まとめて報告され、部品も100個まとめて届くような状況です。

ここで押さえておきたいのは、弱点を見つけるのが上手なのは攻撃する側だけではないという点です。ソフトウェアを作る会社やセキュリティの研究者も、同じようにAIを使って弱点を探せるようになります。その結果、弱点の発見とパッチの提供が両方とも速くなり、受け取る側の作業量が増えるという構図です。

要請の文書でも、この作業の負担が大きく増えることが想定されるとしたうえで、情報システム部門の人員を急に大幅に増やすのは現実的ではないと率直に書かれています。だからこそ、どこから手をつけるかを先に決めておくことが大事になるという流れです。

この話は金融だけの課題ではない

パッチが一気に増えるという課題は、金融機関に限った話ではありません。2026年5月18日に公表された政府全体の対策パッケージ「Project YATA-Shield」では、重要インフラ事業者に向けて、弱点がより高速かつ大量に発見・修正されることを前提とした対策の強化が求められています。重要インフラには電力、鉄道、医療、情報通信などが含まれます。

また同じパッケージでは、ソフトウェアを作る側のベンダーに向けても、AIの活用を含めてより早期に弱点を発見し修正することが求められました。パッチを出す側と受け取る側の双方に、対応の速さが求められているということですね。

まず「どれを優先して守るか」を決めておく

要請の文書では、優先して対応すべきサービスやシステムを決めておき、そこに人手や時間を重点的に振り向けるという考え方が示されています。すべてを同じ力加減で守ろうとすると、かえって大事なところが手つかずになってしまうためです。

優先の候補として文書に挙げられているのは、インターネットバンキングのように、重要な業務を支えていて外部から接続できるシステムです。外からアクセスできる分、狙われやすいという考え方ですね。また、複数の組織で共同運営しているシステムの場合は、利用する側と提供する側の双方で認識を合わせ、どちらがどこまで担当するのかをはっきりさせておく必要があるとされています。

パッチを当てる順番の決め方を見直す

順番を決めるとき、これまで多くの金融機関が使ってきたのが「CVSS」という点数です。脆弱性の危険度を10点満点で表した、世界共通のものさしです。点数が高いものから直していく、という運用が一般的でした。

ところが要請の文書では、点数が高くない脆弱性であっても、実際の攻撃に使われている例があると指摘されています。つまり点数だけを見ていると、危ないところを見落としてしまう可能性があるということです。

そこで文書が求めているのは、点数に次の2つの視点を足すことです。ひとつは、その弱点が自社のどのシステムに影響するのか。もうひとつは、実際にその弱点を使った攻撃が成り立ちそうかどうか。判断の材料を増やす見直し、と考えると分かりやすいかもしれません。

整理すると、次のような違いになります。

観点	これまでの決め方	要請が示す決め方
何を見るか	危険度の点数と、攻撃方法が公開されているかどうか	上記に加えて、自社のどこに影響するか／攻撃が成り立ちそうか
起こりやすい問題	点数が低い弱点を後回しにして、実際に狙われる	判断するための情報を集める手間はかかる

パッチ適用を速くする下ごしらえ（技術負債の解消）

順番を決めても、いざ修正プログラムが届いたときに「これは自社のどこに関係するんだろう」と調べ始めていては時間がかかります。そこで要請の文書では、優先すると決めたシステムについて、中身の構成をあらかじめ整理しておくことが求められています。どこに何のソフトウェアが使われているかがすぐ分かる状態にしておく、ということです。

あわせて、次のような「たまっている宿題」の片づけにも触れられています。

• 使っていない通信の出入口を閉じておく
• 使われていない管理者用のIDを削除する
• まだ当てていない修正プログラムを当てておく
• メーカーのサポートが終わった製品を、新しいものに切り替える（サポートが終わると修正プログラムが配られなくなるため）

どれも新しい取り組みというより、日々の運用でつい後回しになりがちな作業です。ここが片づいているだけで、いざというときの動きがぐっと速くなります。

ベンダーとの維持保守契約で確認したい点

多くの金融機関は、システムの保守を外部の会社（ベンダー）にお願いしています。そこで要請の文書では、契約の中身を確認しておくことが求められています。ポイントを整理すると次のとおりです。

• 修正プログラムを当てる作業が、そもそも今の契約に含まれているか
• 急ぎのときに、夜間や休日でも対応してもらえる契約になっているか
• 同じタイミングで他の金融機関からも依頼が集中したとき、約束した対応の水準（SLA）を守れる体制がベンダー側にあるか
• ベンダー側の手が回らなくなることも想定して、対象を絞る判断や、遅れをやむを得ないものとして受け入れる手続きを用意しておく
• 共同運営やクラウドで提供されているシステムについて、作業の内容や実施状況が自社に報告される契約になっているか

契約書を読み直す作業そのものにお金はかかりません。優先するシステムを決める作業と並行して進めやすい部分といえるかもしれません。

パッチをすぐ当てられないときの代替手段

修正プログラムをすぐに当てられない事情がある場合もあります。そのときの手段として、要請の文書では、攻撃をブロックする仕組みを通信経路に置く方法などが挙げられています。窓の修理が間に合わないので、とりあえず入口に見張りを立てるようなイメージです。

ただし文書では、これらはリスクを減らす手段にすぎず、ずっと使い続けられる対応ではないとはっきり書かれています。攻撃のやり方が少し変わると防げなくなることもあるためです。修理の代わりではなく、修理までの時間をかせぐ手段として位置づけられていると読めます。

これから脆弱性対応はどうなっていくのか

公表されている資料から読み取れる方向性を、2つ挙げます。

① 人手で追う対応から、自動化へ

要請の文書には、今回求めた対応はあくまで応急的な措置であり、中長期的には弱点への対応を自動化する仕組みへ移行することが必要だと明記されています。今のように担当者が一件ずつ判断して当てていくやり方は、当面の間の応急処置という位置づけです。

② 守る側もAIを使うようになる

政府全体のパッケージ「Project YATA-Shield」では、AIによって攻撃のリスクが高まるからこそ、防ぐためにもAIを積極的に活用するという方向性が示されています。ソフトウェアを作る側にも、AIの活用を含めた早期の弱点発見が求められました。攻撃側だけがAIを使う状況にはならない、という見通しです。

こちらの記事もご参照ください

「フロンティアAI」とは？なぜ今ルールづくりが進んでいるのかをやさしく解説
金融庁と日銀がフロンティアAI対応で出した要請とは？9項目をやさしく解説
サービスを止めることになったら？お客様への連絡とBCPの備えをやさしく解説

出典・参考

金融庁・日本銀行「『フロンティアAIによる脅威変化を踏まえた金融機関等の短期的な対応』に係る要請について」（2026年5月22日）https://www.boj.or.jp/finsys/release/frel260522a.htm
国家サイバー統括室「AI性能の高度化を踏まえたサイバーセキュリティ対策の強化について（Project YATA-Shield）」（2026年5月18日）
※本記事は2026年8月時点の公表資料に基づいています。最新の情報は各機関の公表資料をご確認ください。