「ゼロデイ脆弱性」という言葉をニュースで目にする機会が、この1〜2年で急激に増えました。大手企業のシステム停止・顧客情報漏えい・業務メール停止といった被害事例が続き、経営層や監査部門から「うちの外注しているシステムは大丈夫なのか」と問われる情報システム部門の担当者も少なくないはずです。
しかし、いざ自社の保守契約書を開いてみると、脆弱性対応やパッチ適用に関する条項は曖昧で、何が保守料の範囲内で、何が追加費用の対象なのか判然としない。ベンダーに問い合わせても「一般的な保守の範囲内で対応します」と抽象的な回答が返ってくるだけで、実際に攻撃を受けた際にどれだけの体制で動いてくれるのかは見えてこない。こうしたモヤモヤを抱えたまま、次のインシデントに怯えている担当者は多いのではないでしょうか。
本記事は、そのような発注者側の担当者が「明日から動ける状態」になることをゴールに書いています。ゼロデイ脆弱性の技術的な詳細に深入りするのではなく、「発注者として保守契約に何を書き込めばよいか」「ベンダー定例で何を確認すべきか」「万一攻撃を受けた際に最初の72時間で何を判断すべきか」を、契約論と運用フローの2軸で整理します。
セキュリティ製品の導入判断ではなく、既に締結している保守契約・これから発注する新規案件で使える契約・運用ノウハウを中心に据えている点が、本記事の特徴です。技術用語の解説は必要最小限にとどめ、契約用語・意思決定フローを主軸に展開します。
失敗しないためのシステム保守の引継ぎチェックリスト
この資料でわかること
システム保守会社の変更を検討中の方が、引継ぎ作業で見落としがちなポイントを網羅した実践的なチェックリストです。
こんな方におすすめです
- 現在の保守会社のサービスに不満を感じている方
- 保守会社の変更を検討しているが、何から始めればよいか分からない方
- 引継ぎ作業でトラブルを避けたい方
入力いただいたメールアドレスにPDFをお送りします。
ゼロデイ脆弱性とは何か（発注者向けの最短理解）
まず、発注者として押さえるべき最小限の定義から整理します。技術的な仕組みの詳細ではなく、「時系列で何が起きるのか」を把握することが、以降の契約論を理解する土台になります。
ゼロデイ脆弱性とゼロデイ攻撃の違い
「ゼロデイ脆弱性（Zero-Day Vulnerability）」とは、ソフトウェア製品に存在する未知の欠陥のうち、修正パッチや対策情報が製品ベンダーからまだ提供されていない状態にあるものを指します。一方、「ゼロデイ攻撃（Zero-Day Attack）」は、そのパッチ未提供の脆弱性を突いて実行される攻撃です。
時系列で並べると、以下のような流れになります。
- 0 日目: 脆弱性が発見される（発見者は製品ベンダー、独立研究者、または攻撃者のいずれかの可能性がある）
- 0〜N 日目: 攻撃者が先に発見し、パッチが公開されるまでの間に攻撃を仕掛ける期間。この期間の攻撃を「ゼロデイ攻撃」と呼ぶ
- N 日目以降: 製品ベンダーから修正パッチが公開される。以降は「Nデイ脆弱性」となり、パッチが適用されていないシステムが攻撃対象となる
ここで発注者が理解しておくべきポイントは、「ゼロデイ攻撃が始まった時点では、有効な公式パッチが世の中に存在しない」という一点です。したがって、被害の拡大を防ぐためには、パッチが提供されるまでの間、応急的な対策（アクセス制御・機能無効化・仮想パッチ・監視強化等）を講じる必要があります。この応急対応こそが、保守契約の範囲に含まれるかどうかで発注者の負担が大きく変わる領域です。
発注者が最低限押さえるべき 3 つの事実
技術的な議論に深入りする前に、契約論を進める上で必要な3つの事実を押さえておきましょう。
- パッチは間に合わないことがある: 製品ベンダー（OSやミドルウェアの開発元）からの公式パッチ提供は、脆弱性の複雑さによっては数日〜数週間かかることがあります。その間の応急対応をどうするかが実務上の争点になります。
- 対応はベンダー依存になる: 発注者が自社でパッチを開発することは、通常できません。開発を委託しているベンダー、あるいは製品を提供している別のベンダーが動かなければ、システムを守る手は限られます。
- 被害の帰属先は発注者: システムを実際に運用し、顧客情報や業務データを保有しているのは発注者です。万一攻撃を受けて被害が出た場合、監督官庁・顧客・取引先への説明責任は発注者側にあります。ベンダーはあくまで技術的な対応の担い手であって、社外への説明責任を代行してくれるわけではありません。
この 3 つの事実は、次の章で見る「発注者にとってのゼロデイ攻撃の脅威度」を理解するための前提になります。
なぜ発注者にとってゼロデイ攻撃は特に脅威なのか
同じゼロデイ攻撃でも、内製主体の企業（自社にエンジニアを抱え、自社でパッチや暫定対策を実装できる企業）と、外注主体の企業（開発・保守を外部ベンダーに委託している企業）では、攻撃発生時に取れる打ち手の速度と幅がまったく違います。この章では、外注主体の発注者が抱える構造的な制約を可視化します。
発注者は「自社で緊急パッチを作れない」構造上の制約
外注型のシステム運用体制では、コードベースや本番環境への深いアクセス権をベンダーが握っていることが一般的です。発注者側にコードのフォークや直接修正の権限があっても、保守契約の対象外の変更を独断で行えば、以降の保守責任範囲が変質してしまいます。「自社で緊急対応してもよいですか」とベンダーに事前確認する時間が、被害拡大の時間そのものになります。
この構造上、発注者側で取れる意思決定は、実質的には以下の3つに絞られます。
- ベンダーに緊急対応を依頼する（保守契約の範囲内で対応してもらう / 別途見積で対応してもらう）
- システムを停止させる（サービスを止めてでも被害を最小化する）
- 一時的にアクセス経路を制限する（ネットワーク層・アプリ層で該当機能を封鎖する）
この 3 つの選択肢のどれを、誰が、いつ判断するのかを事前に決めておかないと、攻撃発生時に「関係者調整」で数時間が消え、その間に被害が広がります。
保守契約の範囲外に置かれがちな 4 つのグレーゾーン
保守契約書には、通常「対象システム」「対象範囲」が明記されていますが、以下の4つの領域は契約書の記述が曖昧で、いざという時に「対象外です」とベンダーから返答されがちなグレーゾーンです。
- サードパーティ製ミドルウェア: データベース、Web サーバ、フレームワーク、ライブラリなど、開発ベンダーが選定したが自社では作っていない製品群。CVE（共通脆弱性識別子）が公開された際に、パッチ適用作業が保守範囲内なのかは契約書で明確化されていないことが多い
- OS・カーネル層: サーバ OS のセキュリティ更新は「インフラベンダーの管轄」とされて、開発ベンダーとインフラベンダーの間で押し付け合いが発生しがち
- SaaS 連携部分: 外部 SaaS（決済、認証、メール配信等）との連携部分。連携先 SaaS 側の脆弱性は誰の責任か、連携部分の修正費用は誰が負担するかが曖昧
- オンプレ基盤・ハードウェア: 自社データセンター運用の場合、ネットワーク機器・仮想化基盤のファームウェア更新は保守契約に含まれていないことがある
これら4領域は、開発当初は「使っている本人が対応するだろう」という暗黙の了解で契約書から漏れることが多いのですが、いざ CVE が発表されると、どのベンダーの担当範囲かを確認するだけで数日を要する事態になります。
攻撃発生から復旧までのボトルネックは「ベンダーが動ける契約条件」
ゼロデイ攻撃が発覚してから復旧までの時間を分解すると、多くの時間が「ベンダーが動ける条件を整える調整」に費やされます。具体的には、以下のような時間軸の分解が現実的です。
- 検知から通報まで（社内・ベンダー）: 数時間〜半日
- 対応範囲・費用の合意形成: 数時間〜数日（契約書に予め記載があれば即時、なければ稟議・見積が必要）
- 実際の対応作業（パッチ適用・暫定対策・ログ調査）: 数時間〜数日
- 事後の影響範囲調査・報告: 数日〜数週間
このうち、「対応範囲・費用の合意形成」の部分は、契約書の記載で大幅に短縮できる領域です。裏を返せば、契約書の準備が不十分だと、この調整だけで攻撃者に数日のリードタイムを与えることになります。ここが、ゼロデイ攻撃対策の契約論を軽視できない最大の理由です。
2025 年の主要事例から読み解く発注者への影響
2025 年には、日本国内でも複数のゼロデイ脆弱性・実質ゼロデイ攻撃と呼べる事例が公開されました。ここでは、それらの事例そのものを詳細に解説するのではなく、「発注者側にどんな追加コストと意思決定が発生したか」の観点から教訓を抽出します。
主要事例の概要
2025 年に注目された主な事例として、以下があります。
- QUALITIA Active! mail の脆弱性: 業務用メールソフトウェアの脆弱性が公表され、複数の企業でメールシステムの一時停止・調査対応が発生しました（出典: QUALITIA 社の脆弱性情報 、2025 年）
- Oracle E-Business Suite の脆弱性: 基幹業務システムに広く使われている Oracle EBS で、ランサムウェアグループによる悪用が確認された事案が国内外で報告されました（出典: 各種セキュリティレポート、2025 年）
- MOTEX LanScope Endpoint Manager の脆弱性: 情報資産管理・エンドポイント管理ソフトウェアの脆弱性が公表され、緊急対応を求められた企業がありました（出典: MOTEX 社の脆弱性情報 、2025 年）
- TOKAI コミュニケーションズのインシデント: サービス基盤で発生したインシデントにより、利用企業側で顧客通知・代替手段の整備が必要になった事案です（出典: 各種報道、2025 年）
これらの事例に共通するのは、「発注者側で開発しているシステムではなく、その上で使っている製品・基盤の脆弱性」であるという点です。つまり、開発ベンダーが直接コードを書いた部分ではなく、その周辺の製品・SaaS・基盤層の脆弱性に対して、発注者側がどう対応するかが問われました。
発注者側で発生した意思決定と追加コスト
上記のような製品・基盤層の脆弱性が発覚した際、発注者側では以下のような判断と負担が発生します。
- 緊急対応費用の負担交渉: 保守契約に「サードパーティ製品の脆弱性対応」が明記されていない場合、緊急パッチ適用・回避策実装は「別途見積」となりがちです。休日夜間対応の割増、緊急対応チーム編成のコストが上乗せされ、想定外の出費になります
- サービス停止判断: 攻撃可能性が高いと判断された場合、被害拡大を防ぐためにサービスを一時停止する判断が求められます。停止による売上機会損失・顧客への影響を秤にかける必要があります
- 顧客・取引先への通知: 情報漏えいの可能性がある場合、顧客・取引先への通知、監督官庁への報告が必要になります。通知文の作成、コールセンター増員、報道対応など、開発ベンダーの守備範囲外の業務が発生します
- 代替手段の運用: 該当機能を停止している間、業務を継続するための代替手段（別サービスの一時利用、手作業への切り戻し等）を運用する必要があります
これらの意思決定は、いずれも「発注者が主体的に判断する」領域であり、ベンダーは技術情報の提供者に留まります。契約書に「ベンダーは通知・被害範囲調査・応急策提案を◯時間以内に行う」と明記されていれば、意思決定に必要な情報を素早く得られますが、そうでなければ発注者は「情報を待つ」時間で疲弊します。
事例が示唆する保守契約の 3 つの穴
上記事例群から抽出できる、多くの保守契約に共通する「穴」は以下の3点です。
- 通知遅延: 製品ベンダー・脆弱性情報公開機関からの CVE 情報を、開発ベンダーが発注者にいつ通知するかの時間軸が定義されていない。ベンダーが情報を掴んでから発注者に伝わるまでの間、発注者は無防備な状態に置かれる
- パッチ提供 SLA の不在: 「重大な脆弱性が発覚した場合、ベンダーは何時間以内に応急策を提示する」といったサービスレベルの定義がない。緊急度に応じた対応速度の合意が事前になされていない
- 費用境界の曖昧さ: 月額保守料の範囲でどこまで対応するのか、どの時点から追加料金が発生するのかの線引きが曖昧。緊急時に費用交渉から始めることになり、対応が遅延する
これら 3 つの穴を埋めることが、次に述べる 5 つの契約条項の主要な目的になります。
保守契約に組み込むべき 5 つの条項
ここからが本記事の中核です。発注者が現行の保守契約書を見直す、または次回契約更新時に追記すべき条項を、5 つのカテゴリで整理します。ここでは契約書の一字一句の文面ではなく、「押さえるべき論点と、盛り込むべき要素」の粒度で提示します。法務チームとの調整前段階で使える論点整理として活用してください。
なお、独立行政法人 情報処理推進機構（IPA）が公開している「情報システム・モデル取引・契約書」（IPA モデル契約書）には、保守運用に関する契約書のひな型が用意されています。実際に契約書を作成・改定する際は、こうした公的資料も併せて参照することをお勧めします。
条項1: 脆弱性通知義務
盛り込むべき要素:
- ベンダーが、担当システムに影響する CVE や製品ベンダー発表を認知した場合、発注者に何時間以内に通知するか（例: 重大度 Critical の CVE は 24 時間以内、High は 72 時間以内）
- 通知の内容に含めるべき項目（脆弱性の概要、担当システムへの影響評価、想定される対応方針、追加調査に要する時間）
- 通知の連絡経路（メール、電話、専用ポータル等）と、緊急連絡先の事前登録
- 発注者側の担当窓口の複数化（担当者不在時のフォールバック）
なぜ必要か: 情報を受け取るタイミングが遅れれば、それだけ被害が拡大します。CVE 情報が公開されてから発注者に届くまでのラグを短縮するのが、この条項の目的です。
条項2: 緊急パッチ提供 SLA
盛り込むべき要素:
- 脆弱性の重大度別に、応急対応（暫定策）を開始・完了する時間定義（例: Critical は 24 時間以内に暫定策を提示、72 時間以内に本パッチまたは仮想パッチを適用）
- 応急対応が難しい場合の代替措置（機能無効化、アクセス制限、監視強化等）の合意
- 対応時間の起算点（CVE 公開時点か、ベンダーが認知した時点か、発注者から要請があった時点か）
- 対応チーム編成の要件（担当エンジニアの氏名・スキルレベルまで明記するか）
なぜ必要か: 「できるだけ早く対応します」では、実際にどの程度の速度で動いてくれるのかが読めません。SLA として時間を明文化することで、発注者は経営層への説明もしやすくなり、ベンダーも体制を整えやすくなります。
条項3: 費用範囲の境界線
盛り込むべき要素:
- 月額保守料の範囲内で対応する内容（定常的なパッチ適用、軽微な脆弱性対応等）
- 別途見積になる内容の判断基準（工数閾値、緊急度、時間外対応等）
- 緊急対応時の単価表（時間単価、休日夜間割増率、最低請求時間等）
- 見積提示のリードタイム（緊急時は 1 営業日以内、通常時は 3 営業日以内など）
- 発注者側の稟議短縮のための「事前承認枠」（例: 50 万円以内の緊急対応は事後承認可）
なぜ必要か: 攻撃発生時に費用交渉から始めることになると、対応開始が数日遅れます。事前に境界線を引いておくことで、緊急時の意思決定を短縮できます。バグと不具合、エラーの違いなど、責任範囲に関わる基本用語の整理はバグと不具合・エラーの違いも参考にしてください。
条項4: 監視・検知の分担
盛り込むべき要素:
- 監視の対象範囲（アプリケーション層、OS 層、ネットワーク層、外部アクセス層）
- 監視を担う主体（開発ベンダー、インフラベンダー、専任のセキュリティベンダー、発注者側）
- 検知時のエスカレーションフロー（誰から誰に、どの経路で、何分以内に）
- 監視ログの保管期間・提供義務・分析責任
- 監視サービスが月額保守内か別枠契約かの明示
なぜ必要か: 攻撃を検知できなければ、条項1〜3 の通知や対応も始まりません。監視の空白領域が発生していないかを、契約書で網羅的にチェックする必要があります。
条項5: 免責範囲と責任分界
盛り込むべき要素:
- サードパーティ製品・OSS の脆弱性に対するベンダーの対応範囲（情報提供のみか、パッチ適用作業まで含むか）
- 発注者持ち込み構成（発注者が指定したライブラリ、発注者側で追加開発したモジュール等）の扱い
- 攻撃発生時の損害賠償の上限・免責事項
- 顧客情報漏えい時の責任分担（技術的責任と対外説明責任の切り分け）
- 保険（サイバー保険）の付保有無と、保険適用の条件
なぜ必要か: 万一の際に「これは対象外です」で足止めされないよう、境界を予め合意しておく必要があります。免責範囲を明確化することは、ベンダーにとっても法務リスクを可視化できるメリットがあります。
契約締結前・見直し時にベンダーに確認すべき質問リスト
契約書を書き換える前に、まず「現状でベンダーがどこまで動けるか」を把握することが有効です。次のベンダー定例や、契約更新のヒアリングの場でそのまま使える質問例を、目的別に整理します。
現行保守契約が対応する脆弱性の範囲を確認する 5 つの質問
- 「現在の保守契約書で、脆弱性対応はどの条項に該当しますか。具体的な条文番号と対応範囲を教えてください」 — 契約書上の位置づけを明確化する
- 「Critical / High / Medium といった脆弱性の重大度別に、対応の優先順位や時間軸に違いはありますか」 — SLA の有無を確認する
- **「サードパーティ製ミドルウェア（データベース、Web サーバ、フレームワーク等）で CVE が発表された場合、通知と対応は保守契約の範囲内ですか」— 曖昧領域の実運用を確認する
- 「OS のセキュリティ更新は、貴社の担当ですか、それとも別のインフラベンダーの担当ですか。担当が分かれている場合の連携フローはどうなっていますか」 — 分担のグレーゾーンを解消する
- 「重大な脆弱性が発覚した場合、貴社から弊社への通知は、CVE 公開から何時間以内に届く運用になっていますか」 — 通知の実務運用を確認する
過去のインシデント対応実績を尋ねる 3 つの質問
- 「過去 1〜2 年で、貴社が担当している他社案件でゼロデイ脆弱性への対応事例があれば、可能な範囲で概要を教えてください」 — 対応経験を把握する
- 「その際の対応時間、対応チーム編成、費用範囲はどうでしたか」 — 実績値からの見積感を得る
- 「対応後の振り返りで、貴社として今後改善したいと考えている点はありますか」 — ベンダーの学習姿勢を確認する
サブベンダー・OSS 依存箇所の責任所在を尋ねる質問
- 「弊社システムで使用している OSS ライブラリのリストは、貴社側で最新のインベントリを保有していますか。SBOM（ソフトウェア部品表）の提供は可能ですか」 — 依存関係の可視化を求める
- 「サブベンダー（貴社が委託している別会社）が担当している部分での脆弱性は、どのような連絡経路で弊社まで届きますか」 — 多層構造の実運用を確認する
- 「クラウドサービス（AWS、Azure、GCP 等）側の脆弱性が発表された場合、弊社への通知や対応は誰の担当ですか」 — クラウド事業者との責任分界を確認する
これらの質問は、契約書を書き換える前に、まず「現状のベンダー体制で何が可能か」を可視化するためのものです。回答内容によっては、契約書の書き換えではなく別のセキュリティベンダーへの追加委託が必要になる領域も見えてきます。
ゼロデイ攻撃を受けたときの発注者の初動フロー
契約書と質問リストの準備が整っていても、実際にゼロデイ攻撃を受けたときの発注者の判断は容易ではありません。ここでは、万一自社システムが攻撃対象となった際に、最初の 24 時間・72 時間・1 週間で発注者担当者が何を判断すべきかを、フェーズごとに整理します。
検知フェーズ（〜24 時間）: ベンダー通知・被害範囲確認・システム隔離判断
攻撃または脆弱性発覚から最初の 24 時間は、情報収集と初動判断が中心になります。
- ベンダーへの通知と連携開始: 契約書に定めた通知経路で開発ベンダー・インフラベンダーに連絡し、状況共有と対応要請を開始する
- 被害範囲の一次確認: どのシステム、どのデータ、どの利用者に影響が及んでいるか、既知の情報を集約する
- システム隔離判断: 攻撃が進行中の場合、被害拡大を防ぐためのシステム停止・機能無効化・ネットワーク隔離を判断する。この判断は経営層への即時報告と並行して行う
- 社内エスカレーション: 経営層、法務、広報、顧客対応部門への一次連絡を行う
このフェーズで重要なのは、「完璧な情報を待たない」ことです。不完全な情報でも、被害拡大を止めるための初動を打つことが優先されます。
対応フェーズ（〜72 時間）: 緊急パッチ適用・仮想パッチ導入・費用交渉の初期化
初動が済んだら、本格的な対応フェーズに入ります。
- 緊急パッチまたは仮想パッチの適用: 製品ベンダーからパッチが提供されていればその適用、まだ提供されていなければ WAF・IPS 等による仮想的な防御策の導入を検討する
- 監視強化: 攻撃者が別の経路で再侵入を試みることを想定し、監視レベルを一時的に引き上げる
- 費用交渉の初期化: 契約書の費用条項に基づき、対応費用の見積・請求方針を早期に確認する
- 顧客・取引先への一次通知の検討: 情報漏えいの可能性がある場合、法令上・契約上の通知義務がいつ発生するかを法務と確認する
このフェーズでは、契約書に予め費用範囲や SLA が明記されているかどうかが、対応スピードに直結します。事前準備の差が最も表れる段階です。
事後フェーズ（〜1 週間）: 顧客通知・監督官庁報告・保守契約の見直し発意
72 時間を過ぎたら、事後対応と再発防止のフェーズに入ります。
- 顧客・取引先への正式通知: 情報漏えいや業務影響が発生した場合、正式な通知文を用意し、必要な範囲で通知を実施する
- 監督官庁への報告: 個人情報保護委員会など、業種・情報種別に応じた監督官庁への報告義務を確認し、期限内に報告する
- 経営層・監査部門への詳細報告: 攻撃の経緯、被害範囲、対応コスト、再発防止策を整理し、経営層への報告を行う
- 保守契約の見直し発意: 今回の対応で明らかになった契約書の穴を洗い出し、次回契約更新時の交渉ポイントとして整理する
このフェーズは、単にインシデントの終息だけでなく、「同じ状況が再発した際に、もっと早く対応できる体制を作る」ためのフェーズでもあります。契約書の見直しはこのタイミングで発意することが、実務上最も現実的です。
発注前・契約時・運用時に押さえる 3 つのチェックポイント
最後に、記事全体の要点を「新規発注時」「既存契約更新時」「日常運用時」の 3 場面に整理し、明日から使える最小行動リストとしてまとめます。
新規開発を発注するときに RFP・契約書に含めるべき事項
これから開発を発注する場合は、RFP（提案依頼書）や契約書のドラフト段階から脆弱性対応を含めておきましょう。
- RFP に脆弱性対応方針の記載を求める: 「脆弱性発生時の通知プロセス」「対応 SLA」「費用範囲」を提案書に含めるようベンダーに求める
- 保守契約書のひな型に条項1〜5 を組み込む: 開発契約と保守契約は分離することが多いため、保守契約側で先述の 5 条項を必ずカバーする
- SBOM（ソフトウェア部品表）の提出を要求する: 使用する OSS・サードパーティ製品の一覧を納品物に含めるよう明記する
- 監視・検知の分担を初期設計段階で決める: 開発ベンダー、インフラベンダー、セキュリティベンダーの役割分担を、システムの初期設計時に確定させる
現行の保守契約を今日見直すときの優先順位
既に締結済みの保守契約がある場合、いきなり契約書を書き換えるのは現実的ではありません。以下の優先順位で段階的に進めるのが実務的です。
- 【最優先】現行契約書の脆弱性対応条項を読む: どの条項に該当するか、SLA・費用範囲・免責範囲がどう書かれているかを可視化する
- 【優先】ベンダーへヒアリングを実施する: 先述の質問リストを使い、現行運用の実態を確認する。書面と実態のギャップを把握する
- 【中期】次回契約更新時の交渉ポイントを整理する: 洗い出した課題を整理し、法務チームと共に契約書修正案を準備する
- 【並行】応急的な覚書・別紙合意を検討する: 契約更新まで待てない場合、覚書や別紙で緊急連絡体制のみ先に合意する
日常運用で発注者側が続けるべき最小限のチェック
契約と初動フローを整えても、日常運用でのチェックを怠れば、実効性は下がります。以下は、発注者側で最低限続けたい運用チェック項目です。
- CVE 情報の定期チェック: 使用製品の CVE 情報を月次で確認する（IPA、JPCERT/CC 等の公的機関の発信を購読する）
- ベンダー定例での脆弱性トピック: 月次または四半期のベンダー定例に「脆弱性対応の実績・予定」を議題として加える
- 緊急連絡体制の年次確認: 緊急連絡先、担当者、経路が最新化されているか、年1回は確認する
- 簡易的な演習（テーブルトップ演習）: 「今、Critical CVE が発表されたら誰が何をする？」を関係者で口頭確認するだけでも実効性が上がります
これらの運用チェックは、いずれも大がかりなツール導入を必要としません。契約書と質問リストを整えた後、日常業務に組み込める最小限のルーチンとして続けることが、実際の攻撃発生時の初動速度に直結します。
ゼロデイ脆弱性への備えは、突き詰めると「攻撃発生前に、意思決定を減らしておく」ことに集約されます。契約書に予め通知義務・SLA・費用範囲・分担・免責を明文化しておけば、攻撃発生時にゼロから交渉する必要がなくなり、初動の時間を実際の防御作業に充てられます。技術製品の導入は、その意思決定基盤ができたうえで初めて意味を持ちます。
まずは今日、自社の保守契約書を開いて「脆弱性」というキーワードで検索してみることから始めてみてください。何が書かれていて、何が書かれていないかを把握することが、発注者としてゼロデイ脆弱性に向き合う最初の一歩になります。
失敗しないためのシステム保守の引継ぎチェックリスト
この資料でわかること
システム保守会社の変更を検討中の方が、引継ぎ作業で見落としがちなポイントを網羅した実践的なチェックリストです。
こんな方におすすめです
- 現在の保守会社のサービスに不満を感じている方
- 保守会社の変更を検討しているが、何から始めればよいか分からない方
- 引継ぎ作業でトラブルを避けたい方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- 現行の保守契約書にゼロデイ対応の条項がなく、契約更新までまだ時間がある場合はどうすればいいですか？
契約更新を待たず、覚書や別紙合意で緊急連絡体制だけ先に合意するのが現実的です。通知経路と緊急連絡先に加えて、重大度別の一次対応窓口や暫定対応の可否まで書面化しておくことで、契約書の正式な書き換えを待たずに攻撃発生時の初動リードタイムを短縮できます。
- サードパーティ製ミドルウェアの脆弱性は、保守契約の対象に含まれますか？
契約書に明記されていない限り「対象外」と回答されがちなグレーゾーンです。データベースやWebサーバ、フレームワークなどでCVEが公開された際、パッチ適用作業が保守範囲内かは曖昧なため、ベンダーに個別確認するとともに、次回契約更新時に条項として明文化しておくことをお勧めします。
- 緊急対応の費用は、契約書にどこまで取り決めておくべきですか？
月額保守料の範囲、別途見積の判断基準、緊急対応時の単価表、事前承認枠の4点を明記しておくことが重要です。特に見積提示のリードタイムや稟議を短縮する事前承認枠を定めておくと緊急時の意思決定が速くなります。金額水準はベンダーごとに異なるため、個別見積もりで交渉してください。
- ゼロデイ攻撃が疑われる状況で、原因究明が終わるまで社内が動けなくなっています。どうすればいいですか？
完璧な情報を待たず、被害拡大を防ぐ初動（ベンダー通知・被害範囲の一次確認・システム隔離判断など）を優先してください。経営層への即時報告と並行して判断を進め、詳細な原因究明は72時間以降の対応フェーズで進めれば十分です。
- 保守契約の見直しに着手する際、最初に何をすべきですか？
まず現行契約書の脆弱性対応条項を読み、SLAや費用範囲、免責範囲がどう書かれているかを可視化してください。次に質問リストを使ってベンダーにヒアリングし、書面と実態のギャップを把握することが最優先です。契約書の書き換えはその後で構いません。
