インシデント対応の現場では、机上では筋が通っているはずの計画や想定が、いざという瞬間に機能しない場面が少なくありません。その原因の多くは、技術力や担当者の努力不足ではなく、組織に染みついた「おかしな前提」にあります。たとえば「ログが必ず残っている」「連絡すれば担当者にすぐ繋がる」「影響範囲はすぐ特定できる」「バックアップがあれば必ず戻せる」といった前提です。現実の攻撃者は、まさにそれらの前提が崩れる状況を作ってきます。
本稿では、インシデント対応（IR）の実務で崩れがちな前提を整理し、初動と復旧を強くするための具体策を専門家の視点で解説します。狙いは「理想の計画」を増やすことではなく、「壊れない前提」を増やすことです。
インシデント対応で崩れやすい前提とは
インシデント対応は、証拠保全・封じ込め・根絶・復旧・再発防止を段階的に進めますが、実際には並行して判断が求められ、情報も不完全です。ここで致命的になりやすいのが、暗黙の前提です。手順書に書かれていない「なんとなく大丈夫」が、攻撃者や障害条件によって簡単に崩されます。
前提：ログは必要な期間・粒度で残っている
調査で最初にぶつかる壁は「見たいログが無い」「時刻が合っていない」「誰がどの端末で何をしたか追えない」です。EDRやSIEMを導入していても、ログの収集範囲が限定的だったり、クラウドサービス側の監査ログが未設定だったり、保存期間が短かったりします。さらに、攻撃者はログ消去や改ざん、ログ送信停止を狙います。
対策の要点は、収集対象（ID基盤、VPN、メール、プロキシ、DNS、端末、サーバ、クラウド監査ログ）を定義し、時刻同期（NTP）を徹底し、保存期間と改ざん耐性（WORM、別テナント/別アカウント保管、外部保管）を確保することです。加えて「調査時に参照する最小セット」を決め、欠損時の代替（ネットワーク機器のフローログ、クラウドの操作履歴、メールトレース等）も準備します。
前提：関係者はすぐに集まり、意思決定できる
夜間・休日、役職者不在、兼務体制、連絡網の陳腐化、委託先のSLA不明確などで、初動が止まることがあります。さらにランサムウェア等では、メールやチャットが使えず、社内連絡そのものが麻痺することもあります。
対策の要点は、指揮系統と権限移譲（代理決裁ライン）を明文化し、連絡手段を多重化することです。社内システム障害を前提に、社外連絡用の電話・SMS・緊急メッセンジャー、紙の連絡先、集合場所・オンライン会議の代替手段を用意します。委託先には「緊急時の連絡経路」「初動でやってよいこと・禁止事項」「ログ提供のリードタイム」を契約と運用に落とし込みます。
前提：影響範囲は短時間で確定できる
現場では「どのサーバが侵害されたか」「どこまで横展開したか」「情報流出があったか」を即断できず、業務継続の判断が遅れがちです。攻撃者は潜伏し、複数経路（VPN、クラウド、委託先、認証情報漏えい）を使うため、単一視点の調査では見落としが発生します。
対策の要点は、資産管理と依存関係の可視化（CMDB、クラウド資産台帳、SaaS一覧、通信経路図）を整備し、「重要業務に紐づく最重要資産」から優先的にトリアージすることです。調査は端末・サーバだけでなく、ID（特権・MFA状況・不審なトークン）、メール、クラウド操作、外向き通信（C2疑い）を同時に見ます。
前提：バックアップがあれば必ず復旧できる
バックアップは万能ではありません。取得頻度が足りない、世代管理が薄い、復旧手順が未検証、暗号化対象にバックアップ先が含まれる、認証情報が同一でバックアップも侵害される、といった問題が起きます。復旧作業では「データは戻ったが業務が動かない（依存関係の欠落）」も頻発します。
対策の要点は、3-2-1を基本に、オフライン/イミュータブルを組み合わせ、バックアップ環境を本番と権限分離することです。さらに、RTO/RPOを業務ごとに定義し、復旧のリハーサル（年1回ではなく、重要システムは四半期〜半期で）を行い、復旧に必要な手順・キー・媒体・アカウントを「本番が死んでも取り出せる場所」に保管します。
前提：セキュリティ製品が検知してくれる
検知は確率であり、設定・運用・監視体制が伴わなければ期待値は下がります。誤検知が多くアラート疲れが起きる、監視対象が抜けている、アラートの一次対応が止まる、などが典型です。攻撃者はLiving off the Land（正規ツール悪用）で検知を回避します。
対策の要点は、検知を「導入」ではなく「運用する」設計に変えることです。重要検知ユースケース（特権昇格、認証情報ダンプ、MFA無効化、異常なメール転送、クラウドの権限変更、バックアップ削除等）を定義し、アラートからの標準アクション（端末隔離、アカウント無効化、トークン失効、証跡保全）を手順化します。KPIはアラート件数ではなく、MTTD/MTTRや初動の自動化率、未監視資産の削減率で見ます。
初動を止めないための「壊れない前提」の作り方
指揮・判断・実行を分離し、最小限で回す
混乱時に全員が意思決定に参加すると遅くなります。指揮（全体最適の判断）、判断材料の収集（調査・状況把握）、実行（隔離・復旧）の役割を分け、少人数のコアで回す設計が有効です。初動で重要なのは、完璧な原因究明よりも「被害拡大の停止」「証拠の確保」「事業影響の最小化」です。
「遮断してよい条件」を事前合意する
ネットワーク遮断やアカウント無効化は、業務停止リスクを伴います。だからこそ、現場が迷わない基準が必要です。たとえば「特権アカウントの不審利用が確認された場合は即時失効」「ランサムの兆候（大量ファイル改変、バックアップ削除）が出たらセグメント遮断」といった条件を、情報システム・事業部門・経営で合意します。合意があれば、初動での躊躇が減り、被害総量が下がります。
クラウド・SaaS・委託先を含めた現実の境界で設計する
境界防御中心の想定は、クラウド利用やSaaS、ゼロトラスト化が進んだ組織では適合しません。侵害点は社内LANに限らず、ID、APIキー、OAuthトークン、委託先経由など多岐にわたります。IDを中心に、防御・監視・復旧を組み立てることが現実的です。具体的には、MFAの例外を最小化し、条件付きアクセスを整備し、特権IDは分離し、トークン失効やセッション強制終了を即時に実行できる運用を用意します。
再発防止を「反省会」で終わらせない
インシデント後に形だけの報告書を作っても、次の現場は救えません。再発防止は、次回の初動に効く変更に絞るべきです。たとえば、ログ保存期間の延長、MFA例外の廃止、バックアップの権限分離、資産台帳の更新フロー、緊急連絡手段の追加、委託先SLAの明確化など、実装と運用に落ちる施策が重要です。
また、訓練は「シナリオ通りに進める」より「前提が崩れる」状況を織り込むと効果が上がります。メールが使えない、当番が不在、ログが欠損、クラウド権限が奪われた、バックアップが暗号化された——そうした条件下で、何を根拠にどこまで判断し、誰が何を実行するかを確認します。
まとめ：理想より、壊れない前提を増やす
インシデント対応で本当に組織を守るのは、分厚い手順書よりも、崩れやすい前提を減らす取り組みです。ログ、連絡、権限、資産、バックアップ、委託先——どれも「普段は回っている」だけでは不十分で、攻撃者はその隙を突いてきます。現場の混乱を前提に、判断と実行を止めない設計へ移行できれば、被害の総量は確実に下がります。
次のインシデントは、準備が整った日に起きてはくれません。だからこそ、今日の運用の中で「おかしな前提」を一つずつ現実に合わせ、壊れない前提へ置き換えていくことが、最も費用対効果の高いセキュリティ投資になります。