AI時代のBCP再設計｜脆弱性の即日悪用に備える停止判断チェックリスト

結論を先に言います。 これからのBCP（事業継続計画）は「災害で建物や人が動けなくなる」だけでなく、「重大な脆弱性が公表され、その日のうちにパッチが間に合わず、サービスを止めるかどうかを迫られる」場面を主要シナリオとして組み込む必要があります。AI（フロンティアAI）は脆弱性の発見や攻撃コードの生成を速める方向に働くため、「公開されてから数週間の準備期間」を前提にした従来の運用は、そのまま通用しなくなりつつあります。中小企業がまずやるべきは、高価なツールの導入ではなく、「誰が止める判断をするか」「止めたとき何で代替するか」「保守ベンダーは何時間で動くか」を紙一枚で決めておくことです。

この記事では、災害型BCPしか持っていない企業が、脆弱性緊急対応のシナリオを最小構成で追加するための判断フレーム、失敗パターン、発注前チェックリスト、机上訓練カードまでを、一次情報の裏取りとともに整理します。技術的なパッチ適用の設計は脆弱性診断で公開面の穴を洗い出す、検知と初動の常時監視はマネージドSOCで検知から初動までを一本化する、事故が起きた後の封じ込めはインシデント対応支援で初動の迷いを消すと、それぞれ役割が分かれます。本記事はその手前、「経営として事業を止めるか続けるかを決める工程」を扱います。

---

この記事を読むべき人

• BCPは作ったが、中身が地震・水害・ランサムウェアだけで、脆弱性公表シナリオが入っていない経営者・総務責任者
• 情シスが兼任1名、あるいは外部委託で、緊急時に「止めていいか」を誰も判断できないと感じている中小企業の経営層
• 外部公開のWebサービス・ECサイト・予約システム・VPN・クラウド管理コンソールを持っている事業責任者
• 保守ベンダーに任せているが、契約書に「緊急時に何時間で動くか」が書かれているか確認したことがない担当者
• 金融庁・日本銀行の要請（後述）を見て、「うちは金融ではないが、同じ備えが要るのでは」と感じた決裁者

一つでも当てはまるなら、この記事の停止判断ルールとチェックリストは、次の投資判断より前に手をつけるべき「無料でできる備え」を示します。

---

なぜ今、BCPに脆弱性シナリオが必要になったのか

背景には、公的機関が相次いで出した具体的な要請があります。2026年5月22日、金融庁は日本銀行と連名で「フロンティアAIによる脅威変化を踏まえた金融機関等の短期的な対応」に係る要請を公表しました（金融庁の公表ページ、日本銀行の公表ページ）。これは、経営トップを含む経営層の直接関与のもと、概ね1か月程度を目途に取り組むことが期待される9項目の短期的対応を示したものです。9項目のなかには、体制整備、パッチ適用体制の確保、ベンダー契約の見直しといった項目が並び、そのひとつに「優先サービス／ITシステムの停止に備える」ことが含まれています。つまり監督当局が、パッチが間に合わない可能性を前提に、止めた後の事業継続を先に設計しておけと求めているわけです。

この要請の名宛人は金融機関等ですが、根拠になっている脅威観は業種を選びません。フロンティアAIによって脆弱性の発見や攻撃コードの生成が速まるという変化は、外部にサービスを公開している企業すべてに共通します。加えて内閣サイバーセキュリティセンター（NISC）も2026年5月18日付で重要インフラ事業者等に向けた注意喚起（PDF）を出しており、公表から対応着手までの時間短縮が、金融・重要インフラの外側にも波及するテーマになっていることがうかがえます。

「うちは大企業でも金融でもないから関係ない」とは言えません。実際の被害統計はむしろ中小企業に集中しています。警察庁「令和7年上半期におけるサイバー空間をめぐる脅威の情勢等について」（PDF）によれば、令和7年上半期に報告されたランサムウェア被害は116件で高水準が続いており、感染経路はVPN機器が63.4%、リモートデスクトップが18.3%と、この2つだけで8割を超えます。そして被害企業の6割以上が中小企業です。VPNやリモート接続機器は、まさに「重大な脆弱性が公表されたら真っ先に狙われる外部公開面」です。攻撃者は会社の規模ではなく、放置された穴を見ています。

なお、「パッチ適用が遅い」という日本企業の傾向については、民間ベンダーの調査で平均適用日数が1か月を超えるという報告もあります（民間調査のため数値は調査ごとに幅があります）。数字の厳密さより重要なのは、「攻撃が速くなる」×「自社の適用が遅い」＝間に合わない時間帯が構造的に生まれるという事実です。この時間帯をどう乗り切るかがBCPの新しい役割です。

---

従来のBCPが想定していなかった4つの穴

災害型BCPを脆弱性シナリオに流用しようとすると、次の4か所で必ず詰まります。ここを埋めることが再設計の中身です。

災害型BCPの発想は「復旧目標時間（RTO）を決めて、いかに早く元に戻すか」です。ところが脆弱性シナリオでは、早く戻すこと自体が危険になる場面があります。穴が塞がっていないまま復旧すれば、また入られるからです。「戻す前に塞ぐ」「塞げないなら止め続ける」という判断が入る点が、災害型と決定的に違います。ここを理解しないままテンプレートのBCPを流用すると、緊急時に「早く再開しろ」という号令と「まだ危ない」という現場の判断が衝突し、対応が止まります。

---

AI時代BCPの再設計フレーム：5つの判断軸

GXOが企業の事業継続を見るときに使う判断軸は5つです。ツールや文書の量ではなく、「緊急時に迷わず動けるか」を測るための軸です。自社がどこで詰まるかを、この順で確認してください。

軸1：止める権限は誰が持っているか（停止判断）

最も多い失敗は、「サービスを止める判断を誰も持っていない」ことです。止める決定は売上と顧客に直結するため、現場は勝手に止められません。かといって経営者に連絡がつかなければ、被害が広がるのを見ているしかなくなります。平時に「この条件なら止めてよい」という基準と、判断者・代理者を決めておくだけで、緊急時の空白がなくなります。

軸2：止めたとき何で回すか（代替業務・縮退運転）

止める判断ができても、止めた後に事業が完全に停止してしまうなら、経営者は結局止めさせません。だから「止めても最低限は回る」代替手段を先に用意しておくことが、止める判断を可能にします。受注を電話・メールに切り替える、ログインを手動発行に切り替える、といった代替フローが1枚あるだけで、「止める」という選択肢が現実になります。

軸3：ベンダーは何時間で動くか（保守契約のパッチSLA）

自社に技術要員がいない中小企業ほど、緊急時に頼るのは保守ベンダーです。ところが多くの保守契約は「平日日中の問い合わせ対応」しか定めておらず、「重大脆弱性が公表されたとき、何時間以内に、誰が、どこまでやるか」が書かれていない。これが緊急時に最も効いてくる盲点です。契約書の文言を読み直すことは、費用ゼロでできる最重要の備えです。

軸4：影響資産を何分で特定できるか（資産台帳とリードタイム）

「公表された脆弱性が、うちのどの機器・どのソフトに関係するか」を即座に言えなければ、対応は始まりません。資産台帳（何のソフトをどのバージョンで、どこで使っているか）が古い、あるいは存在しないと、影響の有無を確認するだけで半日が溶けます。台帳の鮮度は地味ですが、対応速度を決めるボトルネックです。

軸5：経営層は緊急時に関与できるか（意思決定の経路）

停止・公表・顧客連絡は経営判断です。金融庁・日本銀行の要請でも経営層の直接関与が強調されています。担当者だけで抱えると、判断が遅れるか、逆に現場が忖度して報告を上げず被害が拡大します。休日・夜間でも経営層に一報が届く経路を決めておくことが、実は最も安上がりで効く対策です。

---

高速パッチ時代のBCP見直しチェックリスト

上の5軸を、自社で点検できる形に落としました。「整備済みの基準」を満たさない領域から、契約・人事が絡む項目（パッチSLAと経営層関与）を優先して着手すると、時間のかかるものから片づきます。

このチェックリストは、外注しなくても社内で回せます。埋まらない欄が「発注や相談で埋めるべき優先課題」です。自社だけで判断が難しい場合は、AI・DXの現状を第三者の目で棚卸しするAI導入診断のように、外部の視点で「どこが弱いか」を先に可視化してから投資を決めると、順番を間違えにくくなります。

---

段階別アクションプラン（平時／公表時／発生時）

チェックリストで洗い出した課題は、「いつ何をするか」を段階で割り当てると運用に落ちます。平時の準備が薄いほど、公表時・発生時が場当たりになります。

平時のアクションが整っていれば、公表時と発生時は「すでに決めたルールを発動するだけ」になります。逆に平時を省くと、緊急時に「判断者を探す」「手順をその場で作る」という作業が同時多発し、対応が確実に遅れます。BCPの価値は、緊急時に新しく考える量をゼロに近づけることにあります。

---

BCPに加えるべき「重大脆弱性公表翌朝」シナリオ

訓練で想定する時間軸を具体的に置きます。以下の時間・数値は運用設計の一例であり、確定した基準ではありません。自社の資産配置と業種に応じて調整してください。

このシナリオを年1回以上の机上訓練に組み込むと、実際の緊急時に担当者が「次に何をするか」で迷わなくなります。訓練環境は不要で、シナリオカードと役割分担表さえあれば始められます。

---

停止判断ルールと代替業務フローの作り方

停止判断ルールの例

次の条件が一つでも当てはまるとき、停止判断者へ即時エスカレーションする基準を、文章で決めておきます。

• 管理画面・VPNに重大な脆弱性があり、悪用が確認されている
• 認証回避を許す脆弱性が、外部公開サービスに影響する
• 不審なアクセスがログで確認された
• パッチが72時間以内に提供される見通しが立たない

重要なのは、この基準を「技術者が決める」のではなく、経営が事前に承認しておくことです。緊急時に技術者が「止めましょうか」と聞き、経営が「売上が…」と迷う——この往復が被害を広げます。基準を先に承認しておけば、現場は基準に照らして淡々と動けます。

パッチ適用の優先度づけ（深刻度×公開面）

すべてを今すぐ当てるのは不可能なので、「深刻度」と「公開面」で優先度を機械的に決めます。以下はあくまで運用設計の一例で、閾値は自社で調整してください。

• CVSS 9.0以上かつ外部公開資産で悪用が確認 → 最優先。暫定策を当日中に実施し、停止判断者へ即時エスカレーション
• CVSS 7.0〜8.9で外部公開だが悪用は未確認 → 高優先。数日内の適用計画を立て、それまでの暫定策を検討
• CVSS 7.0未満、または内部限定の資産 → 通常運用。定例の適用サイクルで対応

この整理があると、「全部を今すぐ」ではなく「どれを止めてでも先に処理するか」を判断でき、限られた人手が最も危険な穴に集中します。検知から優先度づけまでの工程を常時回すには、マネージドSOCで検知と初動を仕組みにする方法もありますが、まずは机上でこの優先度表を1枚作るところからで十分です。

代替業務フローの設計

顧客向けサービスを止めるなら、止めた瞬間に事業が死なないよう、代替を先に用意します。

顧客連絡文面を事前に用意しておくのは軽視されがちですが効果が大きい備えです。緊急時に文面をゼロから書くと、時間を食ううえに、動揺が伝わって信頼を損ないます。「調査中・影響範囲・復旧見込み・問い合わせ先」の骨子だけでも先に作っておきます。

---

よくある失敗パターン（発注・運用の落とし穴）

現場を見ていると、BCPの脆弱性対応でつまずく箇所はだいたい決まっています。発注前に自社で当てはまりを確認してください。

• BCPを「作って満足」してしまう：分厚い文書を作ったが、更新も訓練もされず、いざというとき誰も中身を知らない。1枚のシナリオカードと年1回の訓練のほうが、100ページの文書より役に立ちます。
• 停止判断を技術者に丸投げする：技術者は「止めていいか」を経営判断として抱え込めません。基準の事前承認がないと、判断が宙に浮きます。
• 保守契約のSLAを読んでいない：緊急時に電話しても「対応は翌営業日です」と言われて初めて、契約に時間基準がなかったと気づく。契約更新のたびに緊急時条項を確認します。
• 資産台帳が古い：「うちにその機器あったっけ」から始まると、影響確認だけで半日。棚卸しは地味でも最優先です。
• BCPとインシデント対応計画（IRP）が別々：脆弱性緊急対応では「止める判断（BCP）」と「技術的封じ込め（IRP）」が同時に必要です。別ファイルだと現場が二冊を行き来して混乱します。連動させて設計します。
• ツール導入を先にやる：EDRやWAFは有効ですが、「誰が止めるか」が決まっていないと、アラートが鳴っても止められません。判断設計が先、ツールは後です。

---

発注・見積もりの前にベンダーへ確認すべきこと

BCP設計やセキュリティ支援を外部に頼むとき、見積書の金額だけを比べると失敗します。同じ「BCP支援」でも、文書を1本作って終わりの提案と、訓練まで伴走する提案では、緊急時の使えるかどうかが天と地ほど違います。次の問いを、発注前にそのままベンダーへ投げてください。

• 停止判断ルールと代替業務フローまで、成果物に含まれますか。文書だけですか、訓練までやりますか
• 私たちの保守ベンダー契約を読み、緊急時条項の不足を指摘してもらえますか
• 資産台帳の棚卸しは、こちらの作業ですか、そちらでやりますか。範囲はどこまでですか
• 訓練は年何回で、シナリオは私たちの事業に合わせて作りますか。汎用テンプレートの流用ですか
• 納品後、BCPを更新し続ける運用は誰が担いますか。更新が止まったときの想定はありますか

これらに具体的に答えられないベンダーは、「作って納品して終わり」の可能性が高いと考えてよいでしょう。見積書の読み方としては、「文書作成費」だけでなく「訓練・更新・伴走」の項目が入っているかを見ます。安い見積もりは、たいてい訓練と更新が抜けています。AI活用や自動化を絡めた継続的な運用まで見据えるなら、AI開発・自動化の要件から相談できる窓口や、問い合わせ・初動対応をAIエージェントで支える構成の相談も、体制設計の選択肢として検討する価値があります。

---

第三者検証の観点：自社のBCPは本当に動くか

BCPは「作った」ことより「動く」ことが重要です。自社で作った、あるいはベンダーに作ってもらったBCPが実際に機能するかを、第三者の目で検証するときの観点を挙げます。

• 反証で崩れないか：「判断者が出張中で連絡がつかない」「保守ベンダーが連休中」という現実的な例外を入れても、手順が回るか。理想状態だけを想定した計画は現場で崩れます。
• 数字の根拠があるか：「30分以内に影響資産を特定」と書くなら、実測でできるのか。訓練で計ったことがない目標時間は絵に描いた餅です。
• 他部門と整合しているか：情シスの停止判断と、営業の顧客対応、広報の発表が矛盾しないか。部門ごとにBCPが分断されていないか。
• 更新の担い手がいるか：資産や体制は変わります。半年後に読んで陳腐化していないか、更新責任者が決まっているか。

これらを社内だけで検証すると、「作った人が採点する」構図になり、甘くなりがちです。投資の前に弱点を客観的に洗い出したいなら、現状を第三者視点で棚卸しするAI導入診断・第三者診断で「どこから直すべきか」を先に整理する方法があります。診断で優先順位が見えてから、脆弱性診断や監視の投資に進むと、順番を間違えずに済みます。

---

GXOはどう支援するか

GXOは、開発の実装力とセキュリティの視点を併せ持つ立場から、脆弱性緊急対応シナリオを含むBCPの再設計を支援します。初回の相談では、現在のBCPに脆弱性シナリオが入っているか、外部公開システムを把握できているか、緊急時の連絡・判断体制があるかを確認し、投資の前に「どこから手をつけるべきか」の優先順位を整理します。文書を作って終わりにせず、机上訓練で「本当に動くか」まで検証する設計を重視します。案件ごとの具体的な進め方や費用感は、外部公開資産の規模や既存契約によって変わるため、まずは現状の棚卸しからご相談ください。

---

GXOに相談すべきタイミング

• BCPに脆弱性・パッチ・停止判断のシナリオが入っていないことに、この記事で気づいたとき
• 保守ベンダーの契約に緊急時条項がなく、更新交渉をどう進めるか迷っているとき
• 外部公開システム（VPN・EC・予約・クラウド管理）が増えたのに、資産台帳が追いついていないとき
• 「止めていいか」を判断できる人が社内にいない、または属人化しているとき
• セキュリティ投資（EDR・WAF・診断・監視）の順番と優先度を、投資前に第三者に整理してほしいとき

「事故が起きてから」ではなく、「気づいたとき」が相談すべきタイミングです。停止判断ルールと代替業務フローの整備は、費用をかけずに始められる部分が多く、早く着手するほど効果が出ます。

---

よくある質問（FAQ）

Q1. パッチを当てれば、サービスを止めなくてよいのでは？

パッチが出る前の期間や、適用に時間がかかる場合があります。その間の攻撃に備える暫定策（アクセス制限・WAF・一時停止）と、被害が出たときの停止判断フローの両方が必要です。「パッチさえ当てればよい」という前提は、間に合わない時間帯を無視しています。

Q2. 中小企業でも脆弱性対応のBCPシナリオは要りますか？

外部公開のWebサービス、VPN、クラウド管理コンソールがあれば必要です。警察庁の統計でも被害の6割以上が中小企業で、感染経路の8割超がVPN・リモート接続機器です。止めたときの手作業手順と顧客連絡文面を用意するだけでも、緊急時の混乱が大きく減ります。

Q3. BCPとインシデント対応計画は、どちらを先に作ればよいですか？

まず「重大脆弱性公表翌朝」の机上訓練を1回だけ実施することをおすすめします。訓練で必ず出てくる「誰が判断するか」「どう代替するか」という問いが、BCPとインシデント対応計画（IRP）の両方の弱点を同時に教えてくれます。文書作成より訓練が先です。

Q4. パッチ適用のリードタイムは、どこまで短くすればよいですか？

一律の目標はありません。検知・評価・適用の各工程に目安時間を置き、外部公開資産ほど短くする考え方が現実的です。まず現状の所要時間を測り、最も遅い工程から詰めると、全体のリードタイムが縮みます。測っていない目標は改善できません。

Q5. 保守ベンダーとのパッチSLAは、何を取り決めればよいですか？

重大脆弱性公表時の連絡先、初動の対応時間、緊急パッチの提供範囲、適用作業の役割分担を明文化します。契約に時間基準がなければ、次回更新時に緊急時条項を追加できないか確認します。ここは費用ゼロで交渉できる、効果の大きい備えです。

Q6. 縮退運転と完全停止は、どう使い分けますか？

封じ込めで被害拡大を抑えられる見込みがあるなら、機能を絞った縮退運転で事業を続けます。認証回避のように封じ込めが難しい脆弱性では、完全停止を選びます。サービスごとに「どの条件でどちらを選ぶか」を事前に決めておくと、緊急時に迷いません。

---

まとめ

AI時代のBCPは、「災害で動けなくなる」だけでなく「脆弱性が公表され、パッチが間に合わず、止めるか続けるかを迫られる」場面を主役に据えます。やるべきことの多くは、高価なツールではなく、紙一枚の判断設計です。止める権限、代替手段、保守ベンダーの初動時間、資産台帳、経営層の関与——この5軸を平時に決め、年1回の机上訓練で「本当に動くか」を確かめる。ここまでを最小構成でやり切れば、公表翌朝の緊急事態でも、あなたの会社は「新しく考える」のではなく「決めたことを発動する」だけで済みます。まずは自社のBCPに脆弱性シナリオが入っているか、この記事のチェックリストで確認するところから始めてください。

---

参考情報（一次・公式）

• 金融庁・日本銀行「『フロンティアAIによる脅威変化を踏まえた金融機関等の短期的な対応』に係る要請について」（2026年5月22日）：金融庁 https://www.fsa.go.jp/news/r7/sonota/20260522-5/20260522.html ／ 日本銀行 https://www.boj.or.jp/finsys/release/frel260522a.htm
• 警察庁「令和7年上半期におけるサイバー空間をめぐる脅威の情勢等について」（令和7年9月）：https://www.npa.go.jp/publications/statistics/cybersecurity/data/R7kami/R07_kami_cyber_jyosei.pdf
• 内閣サイバーセキュリティセンター（NISC）「重要インフラ事業者等に対する注意喚起」（2026年5月18日）：https://www.cyber.go.jp/pdf/press/20260518_AI_CS_Critical_Infrastructure.pdf
• 内閣府「事業継続ガイドライン（BCP策定）」：https://www.bousai.go.jp/kyoiku/kigyou/keizoku/sk.html

※「日本企業のパッチ適用に平均1か月超を要する場合がある」という記述は民間ベンダー調査に基づく傾向であり、数値は調査により幅があります。統計の具体値は一次情報（警察庁資料・各公表ページ）でご確認ください。

---

AI時代の脆弱性シナリオを、あなたのBCPに組み込みませんか

GXOは、脆弱性緊急対応を含むBCPの再設計、停止判断フローの文書化、代替業務フローの整備、インシデント対応計画との連動設計、そして「本当に動くか」を確かめる机上訓練までを一連で支援します。投資の前に、まず現状の棚卸しと優先順位づけからご相談ください。

BCPの脆弱性対応設計を相談する