この記事は、経営者・リスク担当者・総務責任者が「事業継続工程」にパッチ対応シナリオを組み込む判断材料として書いています。パッチ適用の技術工程は「フロンティアAI時代のパッチ運用設計」を、SOCのトリアージ工程は「フロンティアAI時代のSOCトリアージ設計」をあわせてご覧ください。
2026年5月22日、金融庁・日本銀行の連名要請に含まれる9項目のうち⑧は「優先サービス／ITシステムの停止に備える」です。つまりパッチが間に合わない可能性を前提に、停止後の事業継続を設計しておくことが求められています。この要請では、各項目について概ね1か月程度を目途に対応が期待されると示されており、BCP側の整備も同じ時間感覚で進める必要があります。
これは金融機関だけの話ではありません。BCPに地震・ランサムウェアのシナリオしか入っていない企業は、脆弱性対応の緊急事態に対して白紙の状態です。内閣サイバーセキュリティセンターも2026年5月18日に重要インフラ事業者等へ注意喚起を行っており、脆弱性公表から対応着手までの時間短縮が、業種を問わず共通の課題になっています。
従来のBCPが想定していなかった脆弱性シナリオ
| シナリオ | 従来のBCPでの扱い | フロンティアAI時代に必要な扱い |
|---|---|---|
| 重大な脆弱性が公表される | 含まれていないことが多い | 「重大脆弱性公表翌朝」を訓練シナリオに追加 |
| パッチ適用中にサービス停止が必要 | 緊急メンテナンス扱い | 停止判断者・代替業務・顧客連絡を事前に定める |
| パッチが提供されない（ゼロデイ） | 想定なし | WAF・アクセス制限・一時停止の暫定策フローを整備 |
| ログに不審アクセスが出た | インシデント対応として別計画 | BCPと連動させ停止・隔離判断を一体化する |
EMERGENCY RESPONSE
この脆弱性、貴社システムは影響を受けますか？
影響範囲の一次評価を無料で実施。致命的脆弱性は24時間以内にアラートし、パッチ適用・恒久対応まで伴走します。
高速パッチ時代のBCP見直しチェックリスト
脆弱性公表からパッチ適用までのリードタイムが短くなる前提では、BCPの見直し範囲も「停止に備える」だけでなく、検知・評価・適用・保守契約・経営関与・訓練まで広がります。自社のどこが弱いかを洗い出すために、以下の領域ごとに整備状況を確認します。
| 領域 | 確認項目 | 整備状況の判断基準 |
|---|---|---|
| 検知・評価・適用のリードタイム | 脆弱性検知→影響評価→適用判断までの所要時間が定義されているか | 各工程の目標時間（例：検知から評価着手まで数時間以内）が文書化され、実測と比較できていれば整備済み |
| 優先サービス／ITシステムの停止 | 止めてよい業務・止められない業務が一覧化され、停止順序が決まっているか | 優先サービスごとに「停止可否」「停止時の代替」が表で管理されていれば整備済み |
| ベンダー保守契約のパッチSLA | 保守契約に緊急パッチの提供・適用時間に関する取り決めがあるか | 重大脆弱性時の連絡先・対応時間（例：翌営業日以内の初動）が契約書に明記されていれば整備済み |
| 経営層の関与 | 停止・公表・顧客連絡の最終判断者が決まり、連絡経路があるか | 判断者が不在時の代理者まで指名され、休日夜間でも連絡が取れる体制があれば整備済み |
| 代替運用・縮退運転 | 主要サービス停止時に手作業・縮退運転で事業を継続する手順があるか | サービス単位で代替手順書と再開手順があり、訓練で使われていれば整備済み |
| 復旧訓練 | 脆弱性公表を起点とした机上訓練を定期的に実施しているか | 年1回以上、停止判断と代替運用を含む訓練を実施し、改善点を記録していれば整備済み |
「判断基準」を満たさない領域から優先して着手します。とくにパッチSLAと経営層の関与は、契約・人事に関わるため整備に時間がかかりやすく、早めに手をつける価値があります。技術側の工程は「フロンティアAI時代のパッチ運用設計」で補完できます。
段階別アクションプラン（平時／脆弱性公表時／インシデント発生時）
チェックリストで洗い出した課題は、「いつ何をするか」を段階別に割り当てると運用に落とし込めます。平時の準備が薄いほど、公表時・発生時の対応が場当たり的になります。
| 段階 | 主なアクション | 主担当 |
|---|---|---|
| 平時 | 資産台帳の更新、優先サービスの停止可否整理、保守契約のSLA確認、判断者の指名、机上訓練の実施 | 情シス・総務・経営層 |
| 脆弱性公表時 | 影響資産の特定、悪用状況の確認、適用時間の見積もり、暫定策の要否判断、経営層への一報 | 情シス・SOC・保守会社 |
| インシデント発生時 | 停止・隔離の判断、代替運用への切り替え、顧客・取引先への連絡、ログ保全と封じ込め、復旧と記録 | 経営層・広報・全担当者 |
平時のアクションが整っていれば、公表時とインシデント発生時の判断は「すでに決めたルールを発動するだけ」になります。逆に平時の準備を省くと、緊急時に判断者探しと手順の即興設計が同時に発生し、対応が遅れます。
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
BCPに加えるべき脆弱性対応シナリオ
シナリオ：重大脆弱性が公表された翌朝
訓練で想定すべき時間軸と対応内容を以下に示します。
| 経過時間 | やること | 担当 | 判断基準 |
|---|---|---|---|
| 0〜1時間 | 影響資産の確認（台帳と照合）、悪用確認の確認 | 情シス・SOC | 外部公開かつ個人情報を扱う場合は緊急対応へ |
| 1〜3時間 | 暫定策（WAF、アクセス制限、VPN停止など）の実施 | 情シス・保守会社 | パッチ未提供または適用に時間がかかる場合 |
| 3〜当日中 | 停止判断の実施（必要な場合）、顧客・取引先への第一報 | 経営者・広報 | 顧客影響がある場合のみ |
| 翌営業日 | ログ確認、業務影響報告、再発防止策の検討 | 全担当者 | 記録は必ず残す |
このシナリオを年1回以上の机上訓練に入れることで、実際の緊急事態で担当者が迷わなくなります。
停止判断者と代替業務フローの事前設計
現場が一番迷うのは「サービスを止めてよいか」です。止める判断を誰も持っていない場合、被害が拡大してから止めることになります。
停止判断ルールの例
以下の条件が一つでも当てはまる場合、停止判断者へ即時エスカレーションする基準を事前に文書化します。
- 管理画面・VPNに重大脆弱性（悪用確認あり）
- 認証回避を許す脆弱性が外部公開サービスに影響
- 不審なアクセスがログで確認された
- パッチが72時間以内に提供されない見通し
例：パッチ適用判断フロー（CVSS等で優先度づけ）
以下は、記事の運用設計として示す一例です。実際の閾値は自社の資産配置や業種によって調整してください（数値はすべて運用設計の例であり、確定した基準ではありません）。
脆弱性が公表されたら、まず「深刻度」と「公開面」を組み合わせて優先度を決めます。
- 例：CVSS 9.0以上、かつ外部公開資産で悪用が確認されている → 最優先。暫定策を当日中に実施し、停止判断者へ即時エスカレーション
- 例：CVSS 7.0〜8.9、外部公開だが悪用未確認 → 高優先。数日内のパッチ適用計画を立て、適用までの暫定策を検討
- 例：CVSS 7.0未満、または内部限定の資産 → 通常運用。定例のパッチ適用サイクルで対応
このフローを使うと、「すべてを今すぐ当てる」のではなく、「どれを止めてでも先に処理するか」を機械的に決められます。優先度づけのトリアージ工程は「フロンティアAI時代のSOCトリアージ設計」とあわせて設計すると、検知から判断までが一本の線になります。
代替業務フローの設計
顧客向けサービスを止める場合、次の代替フローを事前に用意します。
| サービス | 停止時の代替手段 | 顧客連絡文面の準備 |
|---|---|---|
| 受注・決済 | 電話・メール受付に切り替え | ○ |
| ログイン・認証 | 仮パスワードの手動発行 | ○ |
| 外部向けAPI | メンテナンス画面の表示 | ○ |
| 社内基幹システム | 手作業による代替手順書 | × （社内向けに別途） |
BCP訓練に脆弱性対応シナリオを入れる方法
既存のBCP訓練に以下の机上シナリオを追加します。専用の訓練環境は不要で、シナリオカードと役割分担表があれば実施できます。
訓練シナリオカードの例：
午前9時、VPN製品の重大脆弱性（CVSS 9.8・認証回避・悪用確認）が公表された。パッチは提供予定だが適用には2日かかる。VPNは全社員のリモートアクセスに使用しており、顧客向けサービスの一部もVPN経由の管理作業を必要とする。
訓練の確認ポイント：
- 誰がいつどうやってこの情報を受け取るか
- 影響資産を30分以内に特定できるか
- 暫定策（アクセス制限、代替手段）を当日中に実施できるか
- 停止判断を出す権限者が連絡できる状態か
インシデント対応とBCPを連動させる
BCPとインシデント対応計画（IRP）は別ファイルで管理されることが多いですが、脆弱性緊急対応のシナリオでは両者が重なります。「止める判断」はBCPの停止判断フロー、「技術的な封じ込め」はIRPのインシデント対応手順として一体で設計しておくと、現場が二つの文書を参照する手間がなくなります。
GXOはどう支援するか
GXOでは、脆弱性緊急対応のシナリオを含むBCP訓練設計、停止判断フローの文書化、代替業務フローの整備、インシデント対応計画との連動設計を支援します。初回相談では、現在のBCPの内容（脆弱性シナリオの有無）、外部公開システムの把握状況、緊急時の連絡体制を確認し、優先して整備すべき項目を絞ります。
よくある質問
Q1. パッチを当てれば停止しなくてよいですか
パッチが出る前の期間や、適用に時間がかかる場合があります。その間に攻撃されるリスクへの暫定策（アクセス制限・WAF）と、被害が発生した場合の停止判断フローを両方用意しておく必要があります。
Q2. 中小企業でも脆弱性対応のBCPシナリオが必要ですか
外部公開のWebサービス、VPN、クラウド管理コンソールがあれば必要です。停止時の手作業手順と顧客連絡文面を準備するだけでも大きく違います。
Q3. BCPとインシデント対応計画はどちらを先に作ればよいですか
まず「重大脆弱性公表翌朝」の机上訓練を1回実施することをおすすめします。訓練で出てくる「誰が判断するか」「どう代替するか」という問いが、BCPとIRP両方の改善点を同時に教えてくれます。
パッチ適用のリードタイムはどこまで短くすればよいですか
一律の目標時間はありませんが、検知・評価・適用の各工程に目安時間を置き、優先度の高い外部公開資産ほど短くする考え方が現実的です。まずは現状の所要時間を測り、最も遅い工程から短縮していくと、全体のリードタイムが詰まります。
保守ベンダーとのパッチSLAは何を取り決めればよいですか
重大脆弱性が公表された際の連絡先・初動の対応時間・緊急パッチの提供範囲・適用作業の役割分担を明文化します。契約に時間基準がない場合は、次回更新時に緊急時条項を追加できないか確認しておくと安心です。
縮退運転と完全停止はどう使い分ければよいですか
被害拡大の恐れが封じ込めで抑えられる場合は、機能を絞った縮退運転で事業を継続し、認証回避など封じ込めが難しい脆弱性では完全停止を選びます。サービスごとに「どの条件でどちらを選ぶか」を事前に決めておくと、緊急時の迷いがなくなります。
参考情報
- 金融庁・日本銀行「フロンティアAIによる脅威変化を踏まえた金融機関等の短期的な対応」（2026年5月22日）：https://www.boj.or.jp/finsys/release/frel260522a.htm
- 内閣府「事業継続計画（BCP）策定ガイドライン」：https://www.bousai.go.jp/kyoiku/kigyou/keizoku/sk.html
- 内閣サイバーセキュリティ戦略室「重要インフラ事業者等に対する注意喚起」（2026年5月18日）：https://www.cyber.go.jp/pdf/press/20260518_AI_CS_Critical_Infrastructure.pdf
AI時代の脆弱性シナリオをBCPに組み込みませんか
GXOでは、脆弱性緊急対応のシナリオを含むBCP訓練設計、停止判断フローの文書化、インシデント対応計画との連動設計を一連で支援します。