※小説ではない※専門書 要約資料集 為替(換算)3.9万円でもらう 紐解集生成 専門 初入門 資料 作：｛作者名｝
※物語はフィクションです 即時通報案件は専門家にご通報ください※お手数ですが疑問点は各分野でご確認いただけましたら幸いです※
# BOOK-0363 情報防衛と復旧シリーズ 第4巻: インシデント対応の一本道 — 一日という制約の中で、何から手をつけるかを決めるための地図
> 情報防衛と復旧シリーズ(BOOK-0360〜0371・全12巻)第4巻。ガイド役: Fable 5 監修 / Sonnet 5 執筆(脚本班)
> トーン規約: GAKUMON_UNIVERSE.md準拠。専門用語は初出で必ず説明する。
> **値札**: 「一日停止・全システム再構成の段階判断」という特命業務の**背骨**にあたる一冊。判定→封じ込め→根絶→復旧→教訓という一本道を、時間という有限の資源の中でどう配分するかまで踏み込んで扱う。
> **安全枠(§16.18・全巻共通・変更不可・最重要)**: 本書は**防御・検知・復旧に限定**する。実在システムへの侵入手順・動作するエクスプロイト・攻撃の再現コード・検知回避手法は一切書かない。脆弱性や欠陥は「何が起きるか(仕組み)・どう防ぐか・どう検知するか」という防御的視点でのみ扱う(IMPORTANT: authorized security testing / defensive security の枠内)。**誇張禁止(§16.5)**: 「これさえ読めば絶対に防げる」等は書かない。多層の備えは突破される確率とかかる手間を上げるが、ゼロにはしない、という正直な水準で書く。
> 接続先: →BOOK-0073/0133『暗号』第1〜2巻(鍵と暗号の理論はそちらに詳しい。本書は鍵の運用や事故対応の側から必要な分だけ再利用する)、→BOOK-0070/0119『ネットワーク』第1〜2巻(通信の仕組みはそちらの土台を借りる)、→BOOK-0006/0340/0358g『OS』(権限分離・プロセスの仕組みの土台)、→BOOK-0358t『PC創造大全 目録X OS導入と保守の技』(保守という日常業務との接続)、→BOOK-0359b/d『Editor創造大全』第2部・第4部(保存則監査・生成器検定という、本書が「改竄検知」の一般例として引用する実装の詳しい解説)、→次巻BOOK-0364『フォレンジクスとログ解析』(本書が要約する「判定」段階の詳しい技法はそちらが引き継ぐ)、→BOOK-0365『バックアップと災害復旧』(本書が要約する「復旧」段階の詳しい技法はそちらが引き継ぐ)、→BOOK-0371『セキュアな再構成の実務』(本書が予告するだけにとどめる「バイト同一移植」による再構成の詳しい手順はそちらが引き継ぐ)。
> 水準: 一〜十二(事象と事故の違いという入口から、対応の六段階、一日という制約の中での時間配分、トリアージ、検知の質、封じ込め、検定文化の色運用への翻訳、根絶、復旧、事後の教訓化、そして対応体制そのものを設計し訓練する実務までを扱う)。
---
# BOOK-0363 情報防衛と復旧シリーズ 第4巻: インシデント対応の一本道 — 一日という制約の中で、何から手をつけるかを決めるための地図
> 情報防衛と復旧シリーズ(BOOK-0360〜0371・全12巻)第4巻。ガイド役: Fable 5 監修 / Sonnet 5 執筆(脚本班)
> トーン規約: GAKUMON_UNIVERSE.md準拠。専門用語は初出で必ず説明する。
> **値札**: 「一日停止・全システム再構成の段階判断」という特命業務の**背骨**にあたる一冊。判定→封じ込め→根絶→復旧→教訓という一本道を、時間という有限の資源の中でどう配分するかまで踏み込んで扱う。
> **安全枠(§16.18・全巻共通・変更不可・最重要)**: 本書は**防御・検知・復旧に限定**する。実在システムへの侵入手順・動作するエクスプロイト・攻撃の再現コード・検知回避手法は一切書かない。脆弱性や欠陥は「何が起きるか(仕組み)・どう防ぐか・どう検知するか」という防御的視点でのみ扱う(IMPORTANT: authorized security testing / defensive security の枠内)。**誇張禁止(§16.5)**: 「これさえ読めば絶対に防げる」等は書かない。多層の備えは突破される確率とかかる手間を上げるが、ゼロにはしない、という正直な水準で書く。
> 接続先: →BOOK-0073/0133『暗号』第1〜2巻(鍵と暗号の理論はそちらに詳しい。本書は鍵の運用や事故対応の側から必要な分だけ再利用する)、→BOOK-0070/0119『ネットワーク』第1〜2巻(通信の仕組みはそちらの土台を借りる)、→BOOK-0006/0340/0358g『OS』(権限分離・プロセスの仕組みの土台)、→BOOK-0358t『PC創造大全 目録X OS導入と保守の技』(保守という日常業務との接続)、→BOOK-0359b/d『Editor創造大全』第2部・第4部(保存則監査・生成器検定という、本書が「改竄検知」の一般例として引用する実装の詳しい解説)、→次巻BOOK-0364『フォレンジクスとログ解析』(本書が要約する「判定」段階の詳しい技法はそちらが引き継ぐ)、→BOOK-0365『バックアップと災害復旧』(本書が要約する「復旧」段階の詳しい技法はそちらが引き継ぐ)、→BOOK-0371『セキュアな再構成の実務』(本書が予告するだけにとどめる「バイト同一移植」による再構成の詳しい手順はそちらが引き継ぐ)。
> 水準: 一〜十二(事象と事故の違いという入口から、対応の六段階、一日という制約の中での時間配分、トリアージ、検知の質、封じ込め、検定文化の色運用への翻訳、根絶、復旧、事後の教訓化、そして対応体制そのものを設計し訓練する実務までを扱う)。
---
## 入口の物語 — 「動いているように見える」が、いちばん危ない
ある日の朝、担当者の元に一本の連絡が入ったとしよう。「昨夜から様子がおかしい」。ログを見ても派手な壊れ方はしていない。画面は普段どおりに動いている。エラーメッセージも出ていない。だが、どこか一箇所だけ、数字が合わない。担当者はしばらく考えたあと、こう気づく——「動いているように見える」ことと、「本当に正しく動いている」ことは、まったく別の話なのだ、と。
情報を扱う仕事における最も厄介な瞬間は、派手に壊れた瞬間ではない。派手に壊れれば、誰の目にも「壊れた」とわかるので、すぐに手が動く。本当に厄介なのは、壊れているのに壊れていないふりをしている瞬間である。検定に通ったはずの資産が、実は内側で欠陥を抱えたまま動き続けている。信号が青のまま、実は赤信号が中に潜んでいる。この状態を、本書では終始一貫して**「緑を騙る赤」**という言葉で呼ぶことになる(第八章で詳しく扱う)。この言葉が生まれた経緯そのものが、実は本書の執筆母体であるこのプロジェクト自身の実際の記録に残っている、机上の作り話ではない一次資料である。
この巻がたどるのは、「何かがおかしい」という違和感から、「もう大丈夫だ」と胸を張って言える状態まで、一歩ずつ歩いていく一本道である。しかもこの一本道には、もう一つ大きな制約がかかっている——**時間**である。多くの現場では、システムを止められる時間には限りがある。「一日だけ止めてよい」「半日だけ止めてよい」という制約の中で、判定にどれだけ時間を使い、封じ込めにどれだけ時間を残し、復旧と再検定にどれだけ時間を確保するか。この時間配分そのものを設計する力が、単なる知識を実務にする最後の一段である。本書はこの一段まで、正面から踏み込む。
新人担当者に、先輩がこう言ったという話がある。「事故そのものより、事故に気づくのが遅れることのほうが、たいてい高くつく。そして、事故に気づいた後も、順番を間違えると余計に高くつく」。この巻(第4巻)が扱うのは、まさにその「順番」である。準備し、検知し、封じ込め、根絶し、復旧し、教訓にする——この六つの言葉の意味を、一つひとつ丁寧に確かめながら、一日という有限の時間の中にどう配置するかまでを、自分の言葉で語れる場所まで歩いていこう。
もう一つ、先輩は付け加えたという。「怖がって何もしないことと、落ち着いて順序どおりに動くことは、まったく別物だ。怖がっている暇があるなら、次に何をすべきかを思い出せ」。この一言は、本書全体の姿勢そのものでもある。本書は、実在システムへ侵入する手順や、検知をすり抜ける技法を教える本ではない。あくまで、事故が起きた後に、防御する側がどう考え、どう動けば被害を最小限に抑え、信頼をもう一度確立できるかという、防御と回復のための一本道だけを扱う。この前提を胸に置いたうえで、最初の一段——「インシデントとは、そもそも何なのか」という定義から歩き始めよう。
---
## 第一章: インシデントとは何か(水準一)
### 「何かが起きた」と「事故が起きた」は違う
情報を扱う現場では、毎日おびただしい数の出来事が記録されている。ログインの成功、ファイルの保存、通信の送受信——これらすべてを**イベント(event、事象、水準一: システムやネットワークの中で観測される、あらゆる出来事)**と呼ぶ。イベントのほとんどは、何の問題もない、ごくふつうの動作の記録である。
これに対して、**インシデント(incident、事故、水準一: 情報の機密性・完全性・可用性のいずれかを損なう、または損なう明確なおそれがあると判断された事象)**は、単に「何かが起きた」という**イベント(event、事象、水準一: システムやネットワークの中で観測される、あらゆる出来事)**とは区別される。ログに記録される正常なログイン試行もイベントの一種だが、それがすべてインシデントというわけではない。深夜に見慣れない場所から管理者権限でのログインが成功していた、という記録は、単なるイベントではなく、インシデントとして扱うべき強いサインになる。
この「機密性・完全性・可用性」という3つの言葉は、情報を守るという仕事全体の土台になる考え方であり、**CIA三要素(シーアイエーさんようそ、水準一: 機密性〈Confidentiality・関係者以外に見られないこと〉・完全性〈Integrity・許可なく書き換えられていないこと〉・可用性〈Availability・使いたいときに使えること〉という3つの柱)**として広く整理されている。この三要素の詳しい解説と、脅威モデルという考え方の全体像は→BOOK-0360『情報セキュリティ総論』が土台として扱う。本書ではこの三要素を、「何を守れなかったから、これはインシデントなのか」を判定するための、最小限のものさしとして再利用する。
### 事象・事故・違反という3つの言葉の階段
もう少し細かく見ると、深刻度の階段は次のように整理できる。
```
イベント(event) ── ただの出来事。正常なものが大半
│ 「これは怪しい」という判断が加わる
アノマリー(anomaly、異常、水準一: 通常のパターンから外れている、注意を要する事象)
│ CIA三要素のいずれかを損なう、または損なうおそれがあると確定する
インシデント(incident) ── 対応が必要な事故
│ 実際に被害(情報漏えい・データ破損・停止時間)が確定する
被害確定インシデント ── 事後報告・法務対応が必要になる段階
```
すべてのイベントを事故として扱っていては、担当者はいくら人手があっても足りなくなる。かといって、すべてを様子見にしていては、本当の事故を見逃す。この「どこからをインシデントとして扱うか」という線引きそのものが、次章以降で扱う対応の出発点になる。
### 点検1 — 3つの出来事を、この階段に当てはめてみる
次の3つの出来事を、上記の階段に当てはめて考えてみよう。
```
出来事A: 社内の担当者が、いつもどおりの時刻に、いつもどおりの場所からログインした。
出来事B: 深夜3時、これまで一度も使われたことのない国からの接続で、
管理者アカウントへのログインが3回失敗し、4回目で成功した。
出来事C: 定期のバックアップジョブが、予定どおりの時刻に、予定どおりの容量で完了した。
```
出来事Aと出来事Cは、パターンから外れておらず、ふつうのイベントとして扱ってよい。出来事Bは、「これまで使われたことのない場所」「深夜という時間帯」「複数回の失敗後の成功」という3つの要素が重なっており、アノマリーとして扱い、CIA三要素のうち機密性(管理者権限を持たない者がログインできた可能性)を損なうおそれがあると判断できるため、インシデントとして正式に扱うべき事例である(点検成立)。
### コラム — 「インシデント対応」という仕事の始まり
情報を扱う組織が「インシデント対応」という専門の仕事を持つようになった歴史は、それほど古くない。1988年、当時まだ黎明期にあったインターネットで、ある自己増殖するプログラムが多数のコンピュータに広がり、通信網の一部が実質的に機能しなくなるという出来事が起きたと伝えられている(この出来事は「モリスワーム事件」として広く知られているが、本書は防御の教材であるため、その技術的な仕組みには立ち入らない)。この出来事をきっかけに、アメリカのカーネギーメロン大学に**CERT/CC(コンピュータ緊急対応チーム、水準一: 情報セキュリティ上の事故に組織的に対応するための、世界で最初期に作られた専門チームの一つ)**という組織が1988年に設立されたとされている。この一件が、「事故は起きるものであり、起きたときに落ち着いて対応する専門の体制が要る」という考え方の出発点になったと、情報セキュリティの歴史では広く語られている。
### コラム — ニアミス(ヒヤリハット)という第4の言葉
第一章冒頭で示した「イベント→アノマリー→インシデント」という階段には、もう一つ挟み込んでおくべき言葉がある。**ニアミス(near miss、ヒヤリハット、水準一: 実際の被害には至らなかったが、一歩間違えば被害が確定していたはずの、危うい事象)**である。たとえば、退職した元担当者のアカウントが、退職後もしばらく無効化されずに残っていたが、そのアカウントが実際に悪用される前に気づいて無効化できた、という場合がこれに当たる。被害そのものは確定していないため、狭い意味でのインシデントには含まれないが、ニアミスを記録し、なぜ危うい状態が生まれたのかを振り返ることは、第十一章で扱う教訓化の、最も安価で最も効果の高い材料になる。実際に被害が出てから学ぶよりも、ニアミスの段階で学ぶほうが、はるかに授業料が安いという考え方は、情報セキュリティに限らず、安全工学全般で広く共有されている知恵である。
---
> **定着量の目安(第一章)**: 身の回りで実際に見聞きした出来事(ニュースで見た情報漏えい報道でもよい)を5件ほど選び、それぞれを「イベント」「アノマリー」「インシデント」のどの段階に当てはまるかを自分の言葉で説明する練習をすると、本章の分類感覚が定着しやすい。
---
## 第二章: 対応の六段階(水準二)
### なぜ段階に分けるのか
インシデントが起きたとき、闇雲に手を動かしても、たいてい事態は悪化する。慌てて汚染された機器の電源を切ってしまい、原因究明に必要な手がかりまで消してしまう——というのは、よくある失敗の典型である。だからこそ、対応には**決まった順序**が要る。
アメリカの国立標準技術研究所(NIST)が策定した『コンピュータセキュリティインシデント対応ガイド』は、2004年に最初の版が発表されたとされ、検知と分析→封じ込め・根絶・復旧→事後対応という局面を軸に据えた、実務者が広く参照する代表的な指針の一つとして知られている。原典ではおおむね4つの大きな局面としてまとめられることが多いが、本書ではこの一連の流れを、学習しやすいように**準備→検知→封じ込め→根絶→復旧→教訓**という六つの段階に分けて扱う。段階を細かく割ることで、次章以降で扱う「時間配分の設計」がより具体的に考えやすくなる、というのが分割の理由である。
### 六段階、それぞれの意味
```
①準備(じゅんび、水準二: インシデントが起きる前に、検知の仕組み・連絡経路・
役割分担・道具立てをあらかじめ整えておくこと)
②検知(けんち、水準二: 何かが起きている、あるいは起きたことに気づくこと)
③封じ込め(ふうじこめ、水準二: 被害がこれ以上広がらないように、汚染の疑いがある
範囲を隔離すること)
④根絶(こんぜつ、水準二: インシデントの直接の原因そのものを取り除くこと)
⑤復旧(ふっきゅう、水準二: 汚染された資産を作り直すのではなく、既知の正常な
状態を基準線として、機能と信頼をあらためて確立し直すこと)
⑥教訓(きょうくん、水準二: 何が起きたか・なぜ気づくのが遅れたか・次はどう
防ぐかを記録し、制度として次に活かすこと)
```
この6つは、名前だけを見ると単純な流れ図に思えるかもしれないが、実務ではそれぞれが独立した専門技能である。準備が薄ければ検知が遅れる。検知が遅れれば封じ込めが遅れる。封じ込めが甘ければ根絶が終わらない。根絶が不完全なら復旧してもすぐに再発する。教訓化を怠れば、次のインシデントでまた同じ準備不足に苦しむ——この6つは輪のようにつながっており、教訓が次の準備に還元される、という循環そのものが、対応の質を年を追うごとに上げていく仕組みになっている。
なお、組織によっては、この6つの言葉の呼び方や区切り方が少しずつ異なることがある。「検知」を「検知と分析」とまとめて呼ぶ場合もあれば、「封じ込め・根絶・復旧」を1つの大きな局面としてまとめて呼ぶ場合もある。呼び方の違いに惑わされる必要はない。大切なのは、名前そのものではなく、「気づく前にどう備えるか」「気づいた後、被害を広げないためにまず何をするか」「原因をどう取り除くか」「どう元の信頼を取り戻すか」「次にどう活かすか」という、5つの問いに対応する中身のほうである。
### 点検2 — 六段階のどこで足を止めるべきか
次の場面を考えてみよう。「深夜に管理者アカウントへの不審なログインを検知した。担当者はすぐに、そのアカウントのパスワードを変更し、該当のセッションをすべて強制的に切断した」。この担当者が行ったのは六段階のどれに当たるだろうか。
ログインという事象に気づいた時点までが②検知であり、パスワード変更とセッション切断は、被害がこれ以上広がらないようにする措置なので③封じ込めに当たる(まだ「なぜそのログインが成功したのか」という根本原因は取り除かれていないため、④根絶はまだ完了していない、という点に注意する。原因を取り除かないまま安心してしまうことが、次章以降で繰り返し警告する典型的な誤りである)。
### コラム — 段階を守らなかった典型的な失敗
情報セキュリティの実務でよく語られる教訓の一つに、「証拠を消してしまう初動」がある。侵入の疑いに気づいた担当者が、慌てて汚染機器の電源を切ったり、ディスクを初期化したりしてしまうと、その機器に残っていたはずの手がかり(いつから・どこから・何が起きたか)が失われ、④根絶や⑥教訓の段階で「結局、原因がわからないまま」という最悪の結末を迎えることがある。②検知の直後に必要なのは、慌てて消すことではなく、まず記録を保全しながら③封じ込めへ進む、という順序である。本書はこの順序そのものを繰り返し強調する。
### コラム — 国際規格の側からも、同じ骨格が確認できる
対応の段階を整理した指針は、NIST SP 800-61だけではない。国際標準化機構(ISO)が策定した`ISO/IEC 27035`という情報セキュリティインシデント管理の国際規格も、準備・検知・評価・対応・学習という、本書の六段階と非常に近い局面を扱っているとされる。策定の経緯も参照する専門家層も異なる2つの文書が、細部の切り方こそ違えど「事故は起きるものとして備え、起きたら順序立てて対応し、学びを次に活かす」という同じ骨格に行き着いている、という事実は、この六段階が特定の1組織だけの流儀ではなく、分野を越えて繰り返し発見されてきた普遍的な型であることの、ささやかな裏付けになっている。
---
> **定着量の目安(第二章)**: 六段階の名前と意味を、何も見ずに順番どおり書き出せるようになるまで繰り返すと、以降の章の理解が大きく助けられる。特に「検知の直後にまず何をすべきか(封じ込めへ進むこと)」を即答できるようにしておくと、実務での初動の迷いが減る。
---
## 第三章: 防御の系譜の中にインシデント対応を置く(水準三)
### 一枚の壁ではなく、幾重もの壁
情報を守る仕事は、一枚の頑丈な壁を作れば終わり、というものではない。鍵をかけ、誰が入れるかを管理し、通信経路を見張り、それでも突破された場合に備えて中の部屋をさらに小分けにしておく——このように、守りの層を幾重にも重ねる考え方を**多層防御(たそうぼうぎょ、水準三: 単一の防御策に頼らず、複数の異なる種類の防御を層のように重ねることで、一つが破られても他の層が被害を食い止める設計思想)**と呼ぶ。
本書が扱うインシデント対応は、この多層防御という考え方の中で、いわば「最後から2番目の層」に当たる。鍵の管理(→BOOK-0369)、認証と権限の最小化(→BOOK-0361)、ネットワークの区画分け(→BOOK-0370)、脆弱性の防御的理解(→BOOK-0362)——これらの層をどれだけ丁寧に積んでも、突破される確率をゼロにすることはできない。だからこそ、「突破された後にどう動くか」を専門に扱う本書のような一冊が、防御の系譜の中で欠かせない役割を持つ。
### 検知の前提という下敷き
対応の六段階のうち②検知は、何もないところから急に生まれるものではない。ログが記録されていなければ、そもそも気づきようがない。この「気づくための下敷き」を作る仕事は、→BOOK-0367『監視と観測可能性』が専門に扱う。本書では、この下敷きがすでにある前提で、「気づいた後、どう動くか」に集中する。
### 点検3 — 多層防御の一枚が破られたときの心構え
「鍵をかけた」「監視カメラを設置した」「万一に備えて避難経路も確保した」という3つの備えを持つ建物を考える。もし鍵が破られたとして、この建物は無防備になるだろうか。答えは「いいえ」である。監視カメラという次の層が異常を検知し、避難経路というさらに次の層が被害の拡大を防ぐ。多層防御の思想は、「一枚が破られること」自体を想定に織り込んでおり、破られた後にどう振る舞うかの設計こそが、次章以降で扱うインシデント対応そのものである、という点検が成り立つ。
### この巻が、他の巻とどうつながっているか
情報防衛と復旧シリーズ全12巻を、読了系統(→CATALOG_情報防衛と復旧シリーズ.md §1)に沿って一覧にすると、本書の立ち位置がより明確になる。
```
土台 : BOOK-0360(総論・CIA三要素・脅威モデル・多層防御)
予防 : BOOK-0361(認証・認可)/0362(脆弱性の防御的理解)/0369(鍵管理)/0370(ネットワーク防御)
検知の前提: BOOK-0367(監視と観測可能性)
判定 : BOOK-0364(フォレンジクスとログ解析)
対応の背骨: BOOK-0363(本書・インシデント対応の一本道)
復旧と再構成: BOOK-0365(バックアップと災害復旧)/0366(可用性・信頼性工学)/0371(セキュアな再構成)
制度で締める: BOOK-0368(監査・統制とコンプライアンス)
```
本書がこの並びの中で担う役割は、いわば「川の本流」である。土台と予防の層をどれだけ厚く積んでも、いつかは何かが起きる。そのときに、判定から教訓までの一本道をどう歩くかを一冊にまとめて示すのが本書の値札であり、両隣にある判定(BOOK-0364)と復旧(BOOK-0365)の詳しい技法は、隣接する巻にそれぞれ委ねる、という役割分担になっている。
---
> **定着量の目安(第三章)**: 自分が知っている建物や仕組み(自宅・学校・オンラインサービスなど)を1つ選び、そこにどんな「層」が重なっているかを3つ以上書き出す練習をすると、多層防御という考え方が身近な実感として定着する。
---
## 第四章: 時間軸の設計 — 一日という制約の中で(水準四)
### なぜ時間配分そのものを設計する必要があるのか
インシデント対応の教科書の多くは、六段階の「やり方」までは丁寧に説明するが、「限られた時間の中で、どの段階にどれだけの時間を割くか」までは踏み込まないことが多い。しかし実務では、システムを止められる時間には必ず限りがある。半日しか止められない現場もあれば、丸一日(24時間)を確保できる現場もある。この「時間という有限の資源をどう配分するか」という設計判断こそが、本書が背骨として扱う特命業務——「一日停止・全システム再構成の段階判断」——の核心である。
### 一日再構成プレイブックという実例
このプロジェクトの内部設計記録には、まさにこの時間配分を具体的な表として設計した一次資料が残っている。汚染の疑いが生じてから丸一日以内に、判定から再検定までを完了させるという想定のもとに作られた、次のような時間の割り当てである。
```
0〜2時間 : 判定 — 「緑を騙る赤」の特定。記録(棋譜・台帳・保存則ログ)を
突き合わせ、破損が始まった時刻を確定する
2〜6時間 : 封じ込め — 汚染の疑いがある資産を赤カード化し、隔離する。
既知の正常な状態(基準線)を確認しておく
6〜18時間 : 復旧 — ゼロから作り直さない。バイト同一移植(既知の正常な
状態をそのまま複製する方式)と機械的な突き合わせで正常部分を
復元し、境界(汚染が疑われた部分)だけを作り直す
18〜24時間: 再検定 — チェッカーで緑を再取得する。合格の基準は「動いて
見える」ことではなく、「実行して比べた結果が一致すること」
```
この配分表が示している考え方は明快である。**判定に使う時間はできるだけ短く切り上げ、封じ込めと復旧に多くの時間を厚く配分し、最後に必ず再検定の時間を確保する**、というものだ。判定にいつまでも時間をかけていては、封じ込めが遅れて被害が広がる。逆に、判定を疎かにしたまま封じ込めや復旧に進むと、間違った箇所を隔離・復旧してしまい、後で手戻りが発生する。「短く鋭く判定し、厚く丁寧に復旧し、最後に必ず検算する」という配分の思想は、次章以降で扱うトリアージや根絶の考え方とも一貫してつながっている。
### なぜ「全数を疑う」のではなく「境界だけを疑う」のか
一日という制約の中で、システムを構成するすべての要素を一つひとつ手作業で疑っていくことは、物理的に不可能である。そこでこのプレイブックが採用している考え方が、**境界二層戦略(きょうかいにそうせんりゃく、水準四: システムの大部分を、燃費の低い自動チェックで面として守り、汚染の疑いが具体的に生じた境界部分だけに、時間のかかる詳しい検査を集中的に投じる、という時間配分の戦略)**である。全体を一瞬で見渡せる自動チェック(第六章で扱う「検知の質」に関わる)によって「疑わしい範囲」を先に絞り込み、その絞り込んだ境界だけに、人手や実行検証といった高コストな検査を集中させる。この考え方があるからこそ、一日という限られた時間の中でも、判定と再検定を両立させることができる。
### 点検4 — 24時間のうち、どこに時間を厚く配分すべきか
次の2つの配分案を比べてみよう。
```
案イ: 判定に14時間、封じ込めに2時間、復旧に6時間、再検定に2時間
案ロ: 判定に2時間、封じ込めに4時間、復旧に12時間、再検定に6時間
```
案イは判定に時間を使いすぎており、封じ込めと再検定が薄い。判定に時間をかけすぎると被害が広がる時間も長くなり、また再検定を薄くすると「動いて見えるだけ」で終わってしまう危険がある。案ロは、判定を短く鋭く終え、封じ込めと復旧を厚く配分し、再検定にも十分な時間を残しており、前節で確認したプレイブックの思想により近い(点検成立)。
### コラム — 「一日」という数字の意味
なぜ本書は「一日」という時間を繰り返し例に使うのか。それは、実務の現場で最も現実的に確保できる停止時間が、しばしば「深夜から翌朝まで」「週末の1日」といった単位で区切られるためである。時間が短ければ短いほど、判定を鋭くし、境界二層戦略で疑う範囲を絞り込む重要性が増す。逆に、もし数週間という余裕があるなら、全数をより丁寧に検査する選択肢も取れる。本書が示す「一日」という枠は、あくまで最も厳しい制約の下での練習台であり、時間に余裕がある現場ではこの配分をそのまま緩めてよい、という点は誇張なく明記しておく。
### よくある誤解 — 「一日あれば、どんなインシデントでも解決できる」
第四章で示した時間配分表を見て、「この配分どおりに動けば、24時間以内に必ず解決する」と読み違えてはいけない。この配分表が前提にしているのは、あくまで「既知の正常な状態(基準線)が、どこかに確実に残っている」という条件である。もし基準線そのものが失われていたり、被害の範囲がシステム全体に及び境界を絞り込めなかったりする場合は、この配分どおりには進まない。本書が誇張なく伝えたいのは、「一日という制約は、時間配分の設計を鍛えるための優れた練習台になる」ということであり、「一日あれば必ず解決する」という保証ではない。基準線を普段から確実に確保しておくこと(→BOOK-0365『バックアップと災害復旧』が専門に扱う)こそが、この時間配分表が機能するための、目に見えない前提条件である。
---
> **定着量の目安(第四章)**: 自分の身の回りにある「止めてよい時間」を1つ想定し(たとえば「休日の半日だけ使えるとしたら」)、判定・封じ込め・復旧・再検定に何時間ずつ配分するかを自分で書き出す練習を3回ほど繰り返すと、時間配分の設計感覚が定着しやすい。
---
## 第五章: トリアージ — 何から手をつけるか(水準五)
### 医療の言葉を借りた優先順位づけ
複数の異常が同時に見つかったとき、すべてに同時に全力で対応することはできない。この状況で「どれから手をつけるか」を判断する技術を、医療現場で使われる言葉を借りて**トリアージ(triage、水準五: 限られた時間と人手の中で、どの問題から手をつけるかを、影響の大きさと拡大の速さに基づいて判断すること)**と呼ぶ。
### 優先度を決める2つの軸
トリアージの判断は、しばしば次の2つの軸の掛け合わせで整理される。
```
拡大が速い 拡大が遅い
影響大きい [最優先] すぐ着手 [優先] 早めに着手
影響小さい [注意] 監視を強化 [後回し] 記録して様子見
```
「影響の大きさ」は、CIA三要素(第一章)のどれをどれだけ損なうかで測る。「拡大の速さ」は、放置した場合に被害範囲がどれだけの勢いで広がるかで測る。両方が大きい事象こそ、他のすべてを差し置いて最優先で着手すべき対象になる。
### 点検5 — 2つの異常のどちらを先に扱うか
次の2つの異常が同時に見つかったとする。
```
異常X: 1台の個人端末で、普段使わないアプリのアイコンが増えていることに
気づいた(被害はその端末に限定されており、拡大の兆候はまだない)。
異常Y: 共有サーバーの管理者アカウントで、短時間のうちに複数の重要な
設定ファイルが次々と書き換えられている(進行中で、他のサーバーへ
広がる経路もある)。
```
異常Xは影響範囲が限定的で拡大も遅く、記録した上で優先度を下げて扱ってよい。異常Yは影響が大きく(管理者権限・複数ファイル)、拡大も速い(進行中・他への経路あり)ため、他の作業を止めてでも最優先で着手すべき対象である(点検成立)。
### コラム — トリアージを誤ると起きること
トリアージを誤り、影響の小さい事象に長時間張り付いてしまうと、その間に本当に危険な事象が野放しになる。これは第四章で扱った時間軸の設計とも直結する——一日という限られた時間の中で判定を鋭く終えるためには、複数の異常が並んだ瞬間に、まずこのトリアージの型を素早く一度通すことが欠かせない。
### コラム — 優先度を「重大・高・中・低」のように段階で表す工夫
実務では、影響の大きさと拡大の速さという2軸の掛け合わせを、いちいち図に描く代わりに、あらかじめ「重大・高・中・低」といった段階(重大度ランク)に落とし込んでおく工夫もよく使われる。たとえば「管理者権限が奪われた疑いがあり、かつ他システムへの拡大経路がある」なら重大、「一般利用者の1アカウントに限定され、拡大の兆候がない」なら低、というように、あらかじめ組み合わせの型を決めておくと、深夜に一人で判断するときでも迷いが減る。この重大度ランクを誰が・どの基準で割り当てるかという役割分担は、第十二章で扱う体制設計の重要な一部になる。
---
> **定着量の目安(第五章)**: 身の回りで同時に起きうる3つのトラブルを想定し(たとえば「家の鍵をなくした」「約束の時間に遅れそう」「スマホの充電が切れそう」)、影響の大きさと拡大の速さの2軸でどれから対応すべきかを並べ替える練習をすると、トリアージの判断が体に馴染みやすい。
---
## 第六章: 検知の質を上げる(水準六)
### 気づかなければ、何も始まらない
対応の六段階は、②検知がなければそもそも始まらない。だからこそ検知の質——「異常に気づく力」——を上げることが、対応全体の速さを底上げする。検知には大きく分けて2つの層がある。
```
構造層(こうぞうそう、水準六: 外部への依存を持たず、短時間で全件を網羅的に
検査できる、燃費の低い自動チェック)
挙動層(けいどうそう、水準六: 実際にコードやデータを動かしてみて、期待どおりの
振る舞いをするかどうかを突き合わせる、より手間のかかる検査)
```
### 実例 — 定期チェッカーという発想
本プロジェクトには、この二層構造をそのまま体現した実際の道具がある。総関数辞書という、多数の言語で同じ処理を書き並べた辞書資産を検査する`tools/check_funcdict_langs.js`という道具である。この検査器は**構造層(こうぞうそう、水準六: 外部への依存を持たず、約1秒程度で全件を検査できる、燃費0の網羅チェック)**と**挙動層(けいどうそう、水準六: 実際にコードを実行させて言語間の出力を突き合わせる、対象言語が実行環境に依存する検査)**という二層構造を持つ。構造層は、1,358件のカード×12言語という全件を約1秒で検査し、外部サービスを一切呼ばないため「毎日でも回せる」性質を持つ。一方、挙動層は実際にプログラムを実行して言語間で結果が一致するかを確かめるため、実行環境(どの言語のランタイムが手元にあるか)に依存し、対象を正直に限定して表示する設計になっている。
この道具が生まれた直接のきっかけは、後の章(第八章)で詳しく扱う「緑を騙る赤」という一件の欠陥の発見だった。一度見つかった欠陥のクラスを、二度と見逃さないための恒久的な見張りとして、この定期チェッカーが新設された、という経緯そのものが、⑥教訓の段階(第十一章)が実際にどう制度へつながるかの生きた実例になっている。
### 実例 — 改竄検知という、もう一つの検知の形
検知が見張るべき対象は、「言語間で結果が食い違っていないか」だけではない。データそのものが、正規の手続きを経ずに数字だけこっそり書き換えられていないか、という**改竄検知(かいざんけんち、水準六: 記録された総量や履歴が、あるべき計算上の帳尻と一致しているかどうかを、機械的に突き合わせて確かめること)**も、検知の重要な一形態である。本プロジェクトの`tools/check_conservation.js`は、アイテムの生成・移動・消滅を記録した台帳を対象に、この改竄検知を行う道具である。この道具のねらいは、ファイル冒頭のコメントにこう記されている。「個々のイベントの見た目上の正しさだけでなく、台帳全体の帳尻(保存則)から構造的に検出することが目的」。1件ずつのログが正しく見えても、台帳全体を通して集計したときに数が合わなければ、どこかで不正な増減が起きた証拠になる——この考え方は、後の章(第八章)で扱う「緑を騙る赤」の発見(1件ずつ読んで確認する検定では見抜けなかった欠陥)と、同じ根っこを持っている。1件ずつの見た目ではなく、全体を通した帳尻を機械的に突き合わせることこそが、検知の質を底上げする、という教訓である。
### コラム — 「定期監査」という発想を、自分の道具で内製する
`tools/check_funcdict_langs.js`のファイル冒頭コメントは、この道具の位置づけを次のように説明している。「金融庁型の『定期脆弱性チェック』の内製版に相当する」。規制業種で義務づけられる定期的な監査という重い仕組みを、外部に頼らず、約1秒で回せる自作の道具として持っておく、という発想である。定期監査という制度そのものの詳しい設計は→BOOK-0368『監査・統制とコンプライアンス』が扱うが、本書の文脈で伝えたいのは、「検知の質を上げる」という作業は、一度きりの見張りを立てることではなく、**同じ種類の欠陥を二度と見逃さないための、繰り返し回せる仕組みを作ること**だ、という点である。
### 点検6 — 構造層と挙動層、どちらを毎日回すべきか
「全件を1秒で検査できるが、実行はしない構造層」と、「実行して確かめられるが、時間がかかり対象言語も限られる挙動層」の2つがあるとき、どちらを毎日の定期実行に向けるべきだろうか。答えは構造層である。燃費が低く全数をカバーできる検査は日常的に回し、コストの高い挙動層は、構造層で絞り込んだ疑わしい境界だけに投入する——これは第四章で扱った境界二層戦略と同じ考え方の、検知の場面での応用である(点検成立)。
### コラム — 誤検知とアラート疲れ
検知の質を上げようとするあまり、あらゆる些細な出来事にまで警報を鳴らす設計にしてしまうと、担当者は膨大な数の**誤検知(ごけんち、水準六: 実際には問題がないのに、異常として通知されてしまうこと)**に埋もれ、本当に重要な警報さえ見逃すようになる。この状態を**アラート疲れ(あらーとづかれ、水準六: 大量の誤検知にさらされ続けることで、担当者の注意力や警報への反応速度が下がってしまう現象)**と呼ぶ。検知の仕組みを作る際は、「多く鳴らす」ことよりも、「鳴ったときには本当に確認する価値がある」ことのほうを優先して設計する必要がある。監視と観測可能性の詳しい設計は→BOOK-0367が扱う。
---
> **定着量の目安(第六章)**: 自分の身の回りにある通知(スマホの通知・メールのフィルタなど)を思い浮かべ、「構造層に相当する軽い確認」と「挙動層に相当する重い確認」に分類してみる練習をすると、二層構造の感覚が定着しやすい。
---
## 第七章: 封じ込め — 被害の拡大を止める(水準七)
### 短期封じ込めと長期封じ込め
トリアージで優先度を決め、検知で異常の所在を絞り込んだら、次に行うのが③封じ込めである。封じ込めには、性格の異なる2つの段階がある。**短期封じ込め(たんきふうじこめ、水準七: 被害の拡大を今すぐ止めるための、応急的で一時的な隔離措置)**と、**長期封じ込め(ちょうきふうじこめ、水準七: 応急措置の後、根絶作業が終わるまでの間、安定した状態で被害の再拡大を防ぎ続ける、より計画的な隔離措置)**は、目的も時間軸も異なる。
短期封じ込めの例としては、疑わしいアカウントを一時的に無効化する、疑わしい通信経路を遮断する、といった「まず止血する」動きが挙げられる。長期封じ込めの例としては、根絶作業が終わるまでの間、隔離した環境を安定して維持し、監視を強化しながら通常業務との境界を明確に保つ、といった動きが挙げられる。短期封じ込めだけで満足してしまい、長期封じ込めを怠ると、根絶作業の途中で被害が再び広がってしまう危険がある。
### 実例 — 隔離を仕組みとして担保する
封じ込めを「その場の判断」に頼らず、仕組みとして担保している実例が、本プロジェクトの資産管理の設計に見つかる。素材(画像)を辞書へ登録する仕組みでは、出所を示す証跡(ライセンスタグ)を欠いた投入物を、**quarantined(隔離済み、水準七: 通常の検定合格の階段〈白・黄・緑〉のいずれにも昇格できない、行き止まりの状態)**という専用の状態に置き、通常の資産が並ぶ場所とは物理的に別のフォルダへ移送する設計が採用されている。この設計は、スキーマ(データの型そのもの)・工程(隔離用フォルダへの機械的な仕分け)・検査(隔離フォルダと通常フォルダが互いに混ざっていないかを確認する機械検査)という三重の仕組みで担保されており、担当者の注意力だけに頼らない封じ込めの一例になっている。
### 点検7 — 封じ込めの深さを比べる
次の2つの対応を比べてみよう。
```
対応甲: 疑わしいアカウントのパスワードだけを変更し、そのまま様子を見た。
対応乙: 疑わしいアカウントを無効化し、関連するセッションをすべて切断した
うえで、隔離した状態を維持しながら原因調査を並行して進めた。
```
対応甲は短期封じ込めとしても不完全であり(パスワードを知られた経路そのものが塞がれていない可能性が残る)、長期封じ込めの要素(隔離状態の維持・並行調査)も欠けている。対応乙は短期・長期の両方の要素を満たしており、次章で扱う根絶・第十章の復旧へ安全に橋渡しできる封じ込めの型になっている(点検成立)。
### コラム — なぜ「証拠を保全してから」隔離するのか
第二章のコラムで触れたとおり、慌てて汚染機器の電源を切ったり初期化したりすると、④根絶や⑥教訓に必要な手がかりが失われる。封じ込めの基本は「動きを止める」ことであって、「痕跡を消す」ことではない。可能な限り、まずログや状態のコピーを取ってから隔離する、という順序を守ることが、この先の段階すべての土台になる。
### コラム — 隔離は「見捨てる」こととは違う
赤カードを貼られた資産や、quarantinedという状態に置かれた投入物は、二度と日の目を見ないわけではない。第九章で扱う根絶によって原因が取り除かれ、第十章で扱う復旧によって基準線との一致が確認できれば、隔離は解かれ、あらためて検定の階段(白・黄・緑)を上り直すことができる。隔離とは「見捨てる」ことではなく、「疑いが晴れるまでの間、被害が広がらない場所に置いておく」という、一時的だが必要な措置である。この点を誇張なく明確にしておかないと、担当者は「隔離=最終的な廃棄」だと思い込み、封じ込めの判断そのものをためらってしまう。ためらいなく封じ込めを実行できることこそが、被害の拡大を最小限に抑える最大の鍵になる。
---
> **定着量の目安(第七章)**: 「短期封じ込め」と「長期封じ込め」の違いを、自分の言葉で1文ずつ説明できるようにしておくと、実務での初動判断が速くなる。あわせて、身の回りの仕組み(家庭・学校・職場)で「隔離」に相当する仕組みが実際にあるかどうかを1つ探してみる練習も有効である。
---
## 第八章: 検定文化を色運用に翻訳する — 「緑を騙る赤」(水準八)
### 白・黄・緑という検定の一方向ラチェット
このプロジェクトの開発文化には、資産の品質を色で表す**検証ラチェット(けんしょうラチェット、水準八: white〈白・未検証〉→yellow〈黄・部分的に検証済み〉→green〈緑・機械検査に合格〉という一方向の昇格の仕組み。一度緑になった資産が、検証なしに白へ逆戻りすることはない)**という考え方が根付いている。ラチェットとは本来、歯車が一方向にしか回らないようにする機械部品を指す言葉であり、ここでは「品質が後戻りしない」という性質のたとえとして使われている。
この白・黄・緑という3色は、いずれも「合格へ向かう途中の段階」を表す色であり、「事故が起きている状態」を表す色ではなかった。しかしインシデント対応の文脈では、もう一つ別の軸——**汚染されている疑いがあるかどうか**——を表す色が必要になる。本書ではこの状態を**赤カード(あかカード、水準八: 汚染の疑いがある資産に貼る印。白・黄・緑という検定の合格軸とは別に設ける、隔離のための印)**と呼び、白・黄・緑という検定の一方向ラチェットとは別の軸として扱う。ある資産は「検定はまだ黄色(部分検証)だが、赤カードも貼られていない(汚染の疑いなし)」という状態もあれば、「検定はかつて緑だったが、今は赤カードが貼られている(汚染の疑いあり)」という状態もあり得る。**赤カード=白黄緑の逆戻りではなく、別の軸に立つ隔離の印**である、という整理が、本章の核心である。
### 「緑を騙る赤」という最悪の状態
白・黄・緑・赤という4色のうち、実務上もっとも危険なのは、単純な「赤」そのものではない。検定を通ったフリをしている状態が一番危険である、という意味を込めて、本書ではこれを**「緑を騙る赤」(みどりをかたるあか、水準八: 検定に合格した〈緑〉ように見えながら、実際には欠陥を抱えている〈赤〉資産)**と呼ぶ。単純な赤(検定に落ちたまま、あるいは未検証のまま)は、誰の目にも「まだ信用できない」とわかるため、扱いを誤りにくい。しかし「緑を騙る赤」は、検定の記録上は合格しているため、誰もが安心して使い続けてしまう。この安心こそが、被害を静かに広げる最大の要因になる。
### 実例 — FUNC-0278という一件
このプロジェクトの記録には、「緑を騙る赤」がどのように発見されたかを示す、具体的な一件が残っている。総関数辞書と呼ばれる資産の中には、同じ処理を複数のプログラム言語で書き並べたカードが多数収められている。そのうちの1枚、FUNC-0278番のカードは、4回にわたる過去の検定(内容を読んで確認する検定)をいずれも通過し、記録上は「緑」の状態にあった。しかし、辞書の中身を実際に組み立てて実行するという5回目の検定によって、初めて欠陥が明らかになった。本プロジェクトの記録によれば、総関数辞書のFUNC-0278番の資産は、python欄がjs欄と同じ乱数シードを与えられているにもかかわらず異なる数列を生成しており、原因は`ToInt32`という変換処理の1行が欠落していたことにあった。
この一件が示す教訓は明快である。「読んで確認する検定」は、書かれている内容がもっともらしいかどうかは確認できるが、「実際に動かしたときに、期待どおりの結果になるかどうか」までは保証しない。過去4回の検定がいずれも見抜けなかった欠陥を、実際に組み立てて実行する検定だけが見抜けた——この事実こそが、「緑」という表示を無条件に信頼してはいけない、という本章の中心的な主張の根拠になっている。発見後の対応は、欠陥のあった1行を修補し、修補後にあらためて言語間の出力が完全に一致することを別の担当者が独立に再実測する、という手順で行われた。修補が終わった資産は、あらためて緑として扱われる——これが色の状態遷移の一巡である。
### 色の状態遷移をまとめる
```
発覚前 : 検定記録は「緑」/実態は「赤」 → 「緑を騙る赤」(最悪の状態)
発覚時 : 赤カードを貼り、隔離する → 「隠れ赤」が「表の赤」になる
修補後 : 独立した担当者が再実測し、一致を確認 → 「緑」へ復帰
未実測面: まだ検証が及んでいない範囲 → 「黄」のまま扱う(過信しない)
```
この状態遷移が示すもう一つの教訓は、「黄」という色そのものを恐れる必要はない、ということである。「黄」は「まだ全部は確認していません」という正直な申告であり、危険なのはむしろ、確認していないのに「緑」を名乗ってしまうことのほうである。
### 点検8 — 4つの状態を見分ける
次の4つの状態を、色で分類してみよう。
```
状態a: 一度も検定を受けていない、できたばかりの資産
状態b: 検定に合格した記録があるが、実行して確かめたことは一度もない
状態c: 実行して確かめる検定に合格し、独立した担当者の再実測でも一致した
状態d: 検定記録は合格だが、実は内部に欠陥があることが後から判明した
```
状態aは「白」、状態bは「黄」(記録上は前進しているが実行確認は未了)、状態cは「緑」、状態dはまさに本章が扱う「緑を騙るを赤」——発覚した瞬間に赤カードを貼って隔離すべき対象である(点検成立)。
### よくある誤解 — 「赤カード」は検定に落ちた印(赤点)と同じ、という誤解
赤カードという言葉の響きから、「検定に不合格だった資産に貼る印」だと誤解されることがあるが、これは正確ではない。検定に一度も提出されていない資産は「白」であり、検定に不合格だった資産は、白のまま昇格していないだけであって、それ自体は赤カードの対象ではない。赤カードが貼られるのは、**汚染の疑いが具体的に生じた**資産に対してであり、その資産がかつて緑だったか黄だったかは問わない。むしろ本章が繰り返し強調してきたとおり、実務上もっとも警戒すべきなのは「かつて緑だった資産に、後から赤カードが必要になる」状態、すなわち「緑を騙る赤」である。白・黄・緑という合格の階段と、赤カードという隔離の印は、上下関係にある一つの物差しではなく、直交する2本の軸である——この整理を取り違えないことが、第七章で扱った封じ込めを迷いなく実行するための土台になる。
---
> **定着量の目安(第八章)**: 「白・黄・緑」という検定の合格軸と、「赤カード」という隔離の軸が、別々の判断であることを、自分の言葉で説明できるようにしておく。あわせて、「緑を騙る赤」という言葉を、身の回りの例(たとえば「大丈夫だと言われていたのに実は壊れていたもの」)に当てはめて説明する練習をすると、この章の核心が定着しやすい。
---
## 第九章: 根絶 — 原因そのものを取り除く(水準九)
### 「症状を消す」ことと「原因を消す」ことの違い
封じ込めによって被害の拡大が止まっても、それだけでは対応は終わらない。**根絶(こんぜつ、水準九: インシデントの直接の原因そのものを取り除く作業)**は「なぜ起きたか」を消す作業であるのに対し、封じ込めは「これ以上広がらないようにする」作業にすぎない。原因を取り除かないまま封じ込めだけで安心してしまうと、隔離を解いた瞬間に同じ問題が再発する。
### 根絶の代表的な型
根絶の具体的なやり方は状況によって様々だが、防御的な観点から一般化できる型としては、次のようなものが挙げられる。
```
・侵害の疑いがある鍵や認証情報を無効化し、新しいものに置き換える(鍵ローテ)
・脆弱性が指摘されている箇所に、提供元が配布する修正(パッチ)を適用する
・不要になった権限やアカウントを整理し、最小限まで絞り込む
・原因となった設定ミスを修正し、同じ設定ミスが起きないよう仕組み化する
```
本書は防御・検知・復旧に限定するという安全枠(冒頭参照)に従い、これらの具体的な操作手順(コマンドの一つひとつ)には立ち入らない。ここで伝えたいのは、根絶とは「表面的な症状を隠す」ことではなく、「症状を生んでいた土台そのものに手を入れる」作業だという考え方である。
### 実例 — 抜け穴そのものを構造で塞ぐという、根絶の一段上の形
根絶には、もう一段深い形がある。個別の欠陥を1件ずつ直すのではなく、その欠陥が生まれる**構造上の抜け穴そのもの**を塞いでしまう、という形である。第六章で紹介した`tools/check_conservation.js`のコードには、この考え方を体現した一節が残っている。所有者の残高を減らす処理を行う関数のコメントに、次のような一文がある。「罠: ownerがnullなら『誰からも減算されない』ため、この分岐こそが複製バグの構造的な抜け穴そのもの」。つまり、あるアイテムを「増やす」処理と「減らす」処理が対になっていなければならないのに、「減らす」側の処理が特定の条件下で静かにすり抜けてしまう、という抜け穴が、複製(データが不正に増えてしまう)という欠陥を生む温床になっていた。この抜け穴に気づいた設計者は、個々の複製事例を1件ずつ後から直すのではなく、「生成の合計から消滅の合計を引いた値は、必ず全所有者の残高の合計と一致する」という不変の等式そのものを機械検査の対象にすることで、この種の抜け穴が二度と見逃されない仕組みを作った。これは、症状(複製されたデータ)を消すだけでなく、症状を生み続ける構造そのものを検査の網にかけてしまう、根絶の一段上の形だと言える。
### 点検9 — 根絶が終わったかどうかの判定
「侵入経路として使われた古いソフトウェアを削除した」という対応は、根絶として十分だろうか。もし、そのソフトウェアが使っていた認証情報(パスワードや鍵)がそのまま残っていて、他の経路からも使い回されていたとしたら、根絶はまだ終わっていない。「侵入経路そのものを塞ぐ」ことと、「その経路が使っていた鍵や権限まで無効化する」ことの両方が揃って初めて、根絶が完了したと言える(点検成立)。この「もれなく塞げているか」を確認する作業は、次章で扱う復旧の前提条件になる。
### コラム — 根絶と検定文化のつながり
第八章で扱った「緑を騙る赤」の発見後、実際にどのような根絶が行われたかを振り返ると、根絶の型がより具体的に見える。原因(変換処理の1行欠落)を特定した後、その1行を修補し、修補が本当に効いているかどうかを、発見した担当者とは別の担当者が独立に再実測する、という手順が踏まれている。この「原因の除去」と「独立した確認」の2段構えは、次章で扱う復旧・再検定の考え方にそのままつながっていく。
---
> **定着量の目安(第九章)**: 「症状を消すだけの対応」と「原因まで取り除く対応」の違いを、自分の身の回りの小さなトラブル(たとえば「水漏れ」)に当てはめて、それぞれどんな対応が症状消しで、どんな対応が原因除去に当たるかを書き出す練習をすると、根絶という考え方が実感として定着する。
---
## 第十章: 復旧 — 作り直しではなく、信頼の再確立(水準十)
### 「元に戻す」ことの本当の意味
根絶が終わったら、次はいよいよ**復旧(ふっきゅう、水準十: 汚染された資産を作り直すのではなく、既知の正常な状態を基準線として、機能と信頼をあらためて確立し直す作業)**である。ここで大切な考え方は、復旧とは単に「動く状態に戻す」ことではなく、「もう一度信頼できる状態を、確かな根拠とともに確立し直す」ことだ、という点である。
第四章で紹介した一日再構成プレイブックのうち、6〜18時間という最も長い時間が割り当てられていたのが、この復旧の段階だった。この配分の理由は明快である。復旧は「ゼロから全部を作り直す」作業ではなく、「既知の正常な状態(基準線)をそのまま複製し、疑わしかった境界の部分だけを作り直す」という、効率のよいやり方が取れるからこそ、他の段階より多くの時間をかけて丁寧に行う価値がある。
### バイト同一移植という考え方
**バイト同一移植(バイトどういついしょく、水準十: 汚染前の既知の正常な状態を、1バイトの違いもなく複製することで、疑いのない土台をまず確保する復旧の手法)**は、この考え方を体現する具体的な技法の名前である。すべてを新しく作り直すのではなく、「疑う必要のない部分」はそのまま複製して土台にし、「疑わしい境界だけ」に手を入れる——この考え方こそが、第四章で扱った境界二層戦略が、復旧の段階にも一貫して適用されている証拠である。バイト同一移植の詳しい手順と、境界の作り直し方については、本シリーズの最終巻→BOOK-0371『セキュアな再構成の実務』が専門に扱う。本書では、この技法が「作り直し」ではなく「信頼の再確立」という考え方から生まれていることだけを、正確に押さえておく。
### 復旧の合格基準 — 「動いて見える」では足りない
復旧が終わったかどうかを判定する基準について、本書は誇張なく明確に線を引く。**「画面が動いているように見える」ことは、復旧が完了した証拠にはならない**。第八章で扱った「緑を騙る赤」がまさにこの罠の実例である——検定記録の上では動いているように見えたが、実際には内部で欠陥を抱えたまま動き続けていた。この教訓から導かれる復旧の合格基準は、「実行して比べた結果が、期待する基準線と一致すること」である。この基準を確かめる作業こそが、次に扱う「再検定」であり、これは対応の六段階でいう④根絶・⑤復旧の締めくくりであると同時に、⑥教訓の段階へつながる橋渡しでもある。
### 点検10 — 復旧の完了をどう判定するか
次の2つの報告のうち、復旧完了の根拠として十分なものはどちらだろうか。
```
報告あ: 「システムを再起動したところ、画面が正常に表示されるようになった」
報告い: 「基準線となる既知の正常な状態と、復旧後の状態を実行して突き合わせた
ところ、出力が完全に一致した。この確認は、復旧作業を行った担当者
とは別の担当者が独立に再実行した」
```
報告あは「動いて見える」ことしか示しておらず、内部に欠陥が残っていないことの根拠にはならない。報告いは、基準線との突き合わせという実測と、独立した担当者による再確認という2つの要素を備えており、本書が求める復旧完了の基準を満たしている(点検成立)。
### コラム — 「全部作り直す」より「境界だけ作り直す」ほうが、なぜ確実なのか
一見すると、疑わしい部分を残さず、すべてをゼロから作り直したほうが安全に思えるかもしれない。しかし実務ではむしろ逆であることが多い。すべてを作り直す作業は、作業量が膨大になるだけでなく、作り直す過程そのものに新しい間違いを持ち込む機会を増やしてしまう。これに対し、疑う必要のない既知の正常な状態をそのまま複製するバイト同一移植は、「複製する」という単純な操作しか行わないため、新しい間違いが入り込む余地が小さい。そのうえで、本当に疑わしい境界の部分だけに、人手による丁寧な作り直しを集中させる——これは、第四章で扱った境界二層戦略が、判定や検知だけでなく、復旧という作業そのものの設計にも一貫して流れている証拠である。「疑う範囲を絞り込み、絞り込んだ範囲にだけ手間をかける」という考え方は、本書を通じて繰り返し姿を変えて登場する、一本の共通した糸である。
---
> **定着量の目安(第十章)**: 「動いて見える」ことと「基準線と突き合わせて一致することを確かめた」ことの違いを、自分の言葉で説明できるようにしておくと、復旧という作業の質が大きく変わる。身の回りの修理(自転車のパンク修理など)を例に、「動くようになった」と「元どおり安全に走れることを確かめた」の違いを考えてみるのもよい練習になる。
---
## 第十一章: 事後の教訓化 — 再発防止の制度化(水準十一)
### 教訓は、書いて終わりではない
対応の六段階の最後、⑥教訓は、単に「反省文を書く」ことではない。**教訓化(きょうくんか、水準十一: インシデントの経緯・原因・対応・かかった時間を記録し、その記録から得られた気づきを、次の準備段階に具体的な仕組みとして組み込むこと)**という言葉が示すとおり、教訓は必ず①準備へと還元されて初めて意味を持つ。書いただけで棚にしまわれる記録は、教訓化とは呼べない。
### 実例 — 記録が、次の事故を軽くした
このプロジェクトの開発記録には、教訓化がどのように機能したかを示す実例が残っている。ある時期、外部サービス側の利用上限によって、作業中の複数の担当班が同時に処理を中断させられるという事故が起きた。本プロジェクトの記録には、API側のセッション上限によって複数班が途中終了し、対応はまずディスクを実地に確認する棚卸しから始まった、という経緯が記されている。この事故そのものは避けられなかったが、記録として残されたことで、「同じ種類の事故が起きたとき、まずディスクの実地確認から始める」という手順が、次に同じ種類の事故が起きたときの初動を大きく速めることになった。さらにこの記録は、「今後は一度に投入する班の数を絞る」という具体的な準備段階の制度変更にまでつながっている。これはまさに、⑥教訓が①準備へ還元された、生きた実例である。
### ポストモーテムという型
教訓を記録するための型として、実務では**ポストモーテム(post-mortem、事後検証、水準十一: 非難を目的とせず、何が起きたか・なぜ気づくのが遅れたか・何が功を奏したか・次に何を変えるかを、時系列に沿って淡々と記録する報告の型)**という言葉がよく使われる。「非難を目的としない」という点が特に重要である。対応にあたった担当者を責める文化のもとでは、担当者は都合の悪い事実を隠すようになり、結果として記録の質が下がり、教訓化そのものが機能しなくなる。何が起きたかを正直に記録できる文化こそが、教訓化の土台である。
```
ポストモーテムの型(骨子):
1. タイムライン: いつ・何が・どの順で起きたか(判定・封じ込め・根絶・
復旧それぞれに要した時間も含める)
2. 根本原因: なぜそのインシデントが起き得たか
3. うまくいったこと: 対応のどの部分が功を奏したか
4. うまくいかなかったこと: どこで時間を無駄にしたか・何を見逃したか
5. 次への具体的な変更: ①準備の段階に、どんな仕組みとして組み込むか
```
### 点検11 — 教訓化が機能したかどうかの判定
次の2つの対応のうち、教訓化として機能しているのはどちらだろうか。
```
対応A: インシデントの経緯を報告書にまとめ、関係者にメールで共有して終わった。
対応B: インシデントの経緯を記録し、そこから見えた準備不足を具体的な
制度変更(たとえば「一度に扱う件数の上限を定める」)として
次回から実際に適用した。
```
対応Aは記録として残ってはいるが、①準備への還元がなされていないため、教訓化としては不完全である。対応Bは、記録から得られた気づきが具体的な仕組みの変更として①準備段階に組み込まれており、教訓化の輪が完成している(点検成立)。
### コラム — 非難しない文化と、非難しない「だけ」では終わらない文化の違い
「非難を目的としない」という原則は、しばしば誤解される。非難しないことは、責任の所在をうやむやにすることでも、原因究明を甘くすることでもない。むしろ逆で、担当者個人を責める空気がないからこそ、当事者は「自分がなぜその判断をしたのか」を正直に話せるようになり、根本原因(なぜその判断が起きたかを生んだ、仕組み側の不備)まで踏み込んだ記録が残せる。本プロジェクトの記録に残るセッション上限事故の振り返りでも、担当者個人の不注意を責める記述ではなく、「一度に投入する班の数」という仕組み側の設計を見直す記述になっている点は、非難しない文化が実際にどう機能するかを示す、地に足のついた実例である。
---
> **定着量の目安(第十一章)**: 自分が過去に経験した小さな失敗(遅刻・忘れ物など)を1つ選び、ポストモーテムの型(タイムライン・根本原因・うまくいったこと・うまくいかなかったこと・次への具体的な変更)に沿って書き出してみると、教訓化という作業の実感が身につく。
---
## 第十二章: インシデント対応体制を設計・訓練する実務(水準十二)
### 一人では回らない
ここまでの十一章で扱ってきた六段階・時間配分・トリアージ・検知・封じ込め・色運用・根絶・復旧・教訓化は、すべて「誰かがその判断を下し、誰かがその作業を行う」ことを前提にしている。実務では、この「誰が」を事前に決めておくことが、対応の速さを大きく左右する。
### 役割分担の基本形
インシデント対応の体制は、規模の大小にかかわらず、おおむね次のような役割に分けて考えることができる。
```
指揮役(インシデントコマンダー、水準十二: 対応全体の意思決定を担い、
六段階のどこにいるかを常に把握し、優先順位を最終的に決定する役割)
実行役(検知・封じ込め・根絶・復旧の実作業を、それぞれの専門性に応じて担当する役割)
記録役(タイムラインを同時進行で記録し、後のポストモーテムの土台を作る役割)
連絡役(関係者・利用者への状況共有、外部への連絡窓口を担う役割)
```
小さな組織では一人が複数の役割を兼ねることもあるが、「今、誰が指揮役なのか」が曖昧なまま対応が始まると、第五章で扱ったトリアージの判断が割れ、時間が無駄に失われる。役割を事前に決めておくこと自体が、①準備の中核をなす。
### エスカレーション経路
判断に迷ったとき、あるいは自分の権限を超える対応が必要になったとき、誰に、どの順番で連絡すべきかをあらかじめ定めておく経路を**エスカレーション経路(えすかれーしょんけいろ、水準十二: 判断の権限が及ばない事態に直面したとき、誰に・どの順で・どんな基準で連絡を引き継ぐかを、あらかじめ定めておく連絡の道筋)**と呼ぶ。深夜に一人で判断に迷ったとき、この経路が事前に定まっていなければ、貴重な時間が「誰に連絡すればよいか調べる」ことに浪費されてしまう。
### 卓上演習という訓練の型
体制を紙の上で決めただけでは、実際のインシデントで機能するとは限らない。実務でよく使われる訓練の型に、**卓上演習(たくじょうえんしゅう、テーブルトップ演習、水準十二: 実際のシステムを止めることなく、想定シナリオを紙とペン・会話だけで進行させ、六段階それぞれで誰が何を判断・実行するかを確認する訓練)**がある。「もし深夜に管理者アカウントへの不審なログインが検知されたら」という架空の場面を設定し、指揮役・実行役・記録役・連絡役がそれぞれどう動くかを、実際のシステムに触れずに紙の上でシミュレーションする。この演習を定期的に行うことで、役割分担やエスカレーション経路の抜けが、実際の事故が起きる前に見つかる。
### Runbookという実務の型
対応中に「次に何をすべきか」を都度考えていては、時間がかかりすぎる。よくある種類のインシデントについて、あらかじめ手順の道筋を書き記しておく文書を**Runbook(ランブック、水準十二: 特定の種類のインシデントに対して、検知から封じ込め・根絶・復旧までの標準的な手順の道筋を、あらかじめ文書化しておいたもの)**と呼ぶ。本書がこれまで扱ってきた六段階・トリアージ・色運用の考え方は、いずれもこのRunbookを組み立てるための部品であり、体制の設計とは、これらの部品を自分たちの現場に合わせて組み立て、訓練で磨き上げていく作業そのものである。
### 点検12 — 体制の抜けを見つける
次の体制を点検してみよう。「指揮役は決まっているが、記録役が決まっておらず、対応のたびに誰かが手が空いたときにメモを取っている」。この体制にはどんな弱点があるだろうか。記録役が固定されていないと、タイムラインの記録が抜け落ちたり、担当者ごとに記録の粒度がばらついたりして、第十一章で扱ったポストモーテムの質が下がる。記録役をあらかじめ固定の役割として定めておくことが、教訓化の質を底上げする(点検成立)。
### 実例 — Runbookの骨組みを、実際に1つ書いてみる
Runbookがどのような形をしているか、具体的な骨組みを1つ示しておく。ここでは「管理者アカウントへの不審なログインを検知した場合」という、よくある種類のインシデントを例にする。
```
Runbook: 管理者アカウントへの不審なログイン検知時の対応
前提: 検知の仕組み(第六章)が、見慣れない場所・時間帯からのログイン成功を
アラートとして通知した場合に発火する
①準備 : 誰が指揮役かを事前に確認できる連絡先一覧を、担当者全員が
いつでも参照できる場所に置いておく
②検知 : アラートを受け取った担当者は、まず記録役へ一次連絡し、
タイムラインの記録を開始する
③封じ込め: 短期封じ込めとして、該当アカウントを一時的に無効化し、
関連するセッションを切断する(第七章)
④根絶 : なぜそのログインが成立したのかを確認し、原因となった
認証情報や設定を無効化・修正する(第九章)
⑤復旧 : 基準線との突き合わせで一致を確認したうえでアカウントを
復帰させる(第十章)
⑥教訓 : ポストモーテムの型(第十一章)に沿って記録し、
①準備の内容を必要に応じて更新する
```
この骨組みそのものは、本書がここまで積み上げてきた各章の内容を、実際のインシデントの型に当てはめて並べ直しただけのものである。Runbookを整備するという作業の正体は、目新しい知識を新たに仕入れることではなく、**本書で学んだ一本道を、自分たちの現場の言葉で書き下すこと**にほかならない。
### コラム — 体制そのものも、検定文化の対象になる
第八章で扱った白・黄・緑という検定文化は、資産(コードやデータ)だけでなく、体制そのものにも応用できる。卓上演習を一度も行っていない体制は「白」、演習は行ったが実際のインシデントでは未検証の体制は「黄」、実際のインシデント対応(あるいは十分にリアルな演習)を経て、ポストモーテムまで一巡した体制は「緑」——というように、体制の成熟度を色で捉える発想は、本シリーズが繰り返し使う一方向ラチェットの考え方と地続きである。
---
> **定着量の目安(第十二章)**: 指揮役・実行役・記録役・連絡役という4つの役割を、身近な小さな組織(家族・部活・サークルなど)に当てはめて、「もし何かトラブルが起きたら誰がどの役割を担うか」を書き出す練習をすると、体制設計という考え方が実感として定着する。余裕があれば、簡単な卓上演習(架空のトラブルシナリオを1つ作り、六段階に沿って自分ならどう動くかを書き出す)を実際にやってみることを強く勧める。
---
## 三つの実践解(§16.21) — 紙とペン、そして自分の端末の標準機能でできる実践
理論を、実際に手を動かして確かめる方法を三つ紹介する。いずれも特別な工具や外部サービスを必要とせず、紙とペン、あるいは自分の端末に最初から入っている標準機能だけで完結する、安全な実践解である。攻撃的な操作は一切含まない。
1. **自分のログイン履歴を眺めてみる実践**: 多くのオンラインサービスやOSには、「最近のログイン履歴」「最近のアクティビティ」を確認できる標準機能が用意されている(具体的な操作手順は各サービスの説明に従う)。この履歴を眺め、第一章で学んだ「イベント」と「アノマリー」の区別を、実際の自分のデータに当てはめてみる。見慣れない場所・見慣れない時間帯の記録がないかを確認するだけの、完全に受動的で安全な実践である。
2. **卓上演習を自分一人で書いてみる実践**: 第十二章で紹介した卓上演習を、紙の上で一人分だけ簡略化してやってみる。「もし自分のメールアカウントが乗っ取られたら」という架空の場面を1つ設定し、六段階(準備・検知・封じ込め・根絶・復旧・教訓)それぞれで自分が具体的に何をするかを、1〜2行ずつ書き出す。書き終えたら、第四章の時間配分の考え方に沿って、それぞれに何時間ずつかけるつもりかも書き添えてみる。
3. **バックアップの実在を確認する実践**: 自分にとって大切なファイル(写真・書類など)が、実際に複数の場所に保存されているかどうかを点検する。パソコン本体だけでなく、外部媒体やクラウドサービスなど、少なくとも2種類以上の異なる保存先に同じデータがあるかどうかを確かめる。これは第十章で扱った「バイト同一移植」の考え方——疑う必要のない既知の正常な状態を、あらかじめ確保しておく——を、自分の身の回りで先取りして体験する練習になる(バックアップと災害復旧の詳しい設計は→BOOK-0365が専門に扱う)。
---
## まとめ — 「動いて見える」を疑う一本道
本書では、「何かが起きた」というただのイベントと、CIA三要素を損なう「インシデント」の違いから出発し(第一章)、準備・検知・封じ込め・根絶・復旧・教訓という六段階の意味を確かめ(第二章)、この対応が多層防御という大きな系譜のどこに位置するかを見て(第三章)、一日という有限の時間の中に六段階をどう配分するかという、本書の背骨に当たる時間軸の設計を扱った(第四章)。続いて、複数の異常が同時に起きたときにどれから手をつけるかを判断するトリアージ(第五章)、気づく力そのものの質を上げる検知の二層構造(第六章)、被害の拡大を止める封じ込めの短期・長期の区別(第七章)を確かめ、このプロジェクトの検定文化である白・黄・緑という一方向ラチェットに、赤カードという隔離の軸を重ね、「緑を騙る赤」という最も危険な状態の見分け方を扱った(第八章)。そのうえで、原因そのものを取り除く根絶(第九章)、作り直しではなく信頼を再確立する復旧(第十章)、記録を次の準備へ還元する教訓化(第十一章)、そして最後に、対応そのものを担う体制を設計し訓練する実務(第十二章)までをたどってきた。
「動いているように見える」ことと「本当に正しく動いている」ことは別の話である——この巻の入口で確かめたこの一文は、実は本書全体を貫く一本の糸だった。判定は短く鋭く、封じ込めと復旧は厚く丁寧に、そして最後に必ず、基準線と突き合わせる再検定の時間を確保する。この時間配分の思想と、「緑」という表示を無条件に信頼しない色運用の思想は、一日という制約の中でこそ、その真価を発揮する。
本書がたどってきた一本道には、もう一つ共通する糸があった。「全数を疑うのではなく、境界だけを疑う」という境界二層戦略である。検知では構造層と挙動層に分け(第六章)、封じ込めでは短期と長期に分け(第七章)、復旧では基準線の複製と境界の作り直しに分けた(第十章)。姿を変えながら同じ考え方が繰り返し登場したのは、偶然ではない。一日という有限の時間の中で対応を成立させるためには、「疑う範囲を絞り込み、絞り込んだ範囲にだけ手間をかける」という思想を、六段階のすべてに一貫して通す必要があるからである。
ここまでの内容は、あくまで対応の一本道そのものである。この一本道の中の「判定」をより深く掘り下げるのが→BOOK-0364『フォレンジクスとログ解析』であり、「復旧」をより深く掘り下げるのが→BOOK-0365『バックアップと災害復旧』であり、そして本書が予告するにとどめた「バイト同一移植による再構成」を専門に扱うのが、本シリーズの最終巻→BOOK-0371『セキュアな再構成の実務』である。一本道の背骨を手にした今、この先は各巻が、それぞれの段階をより深く、より実務的に掘り下げていく。
---
## 章末: 時間軸と色運用のまとめ図
まず、第四章で扱った一日再構成の時間配分を、あらためて帯グラフの形で見てみよう。
```
0h 2h 6h 18h 24h
├─判定────┼──封じ込め───────┼──────復旧(バイト同一移植)──────────┼─再検定─┤
(短く鋭く) (赤カード・隔離) (境界二層戦略・境界だけ作り直す) (基準線と一致)
```
続いて、本書全体の歩みを階段図としてまとめる。
```
[水準十二] 体制の設計・訓練
指揮役・実行役・記録役・連絡役/卓上演習/Runbook(点検12)
▲
│ 六段階を、誰がどう回すかまで決めておく
[水準十一] 事後の教訓化
ポストモーテムの型/教訓を①準備へ還元する(点検11)
▲
│ 記録が、次の対応を速くする
[水準十] 復旧
バイト同一移植/「動いて見える」では足りない(点検10)
▲
│ 作り直しでなく、信頼を再確立する
[水準九] 根絶
症状ではなく原因そのものを取り除く(点検9)
▲
│ 封じ込めだけでは再発する
[水準八] 検定文化の色運用
白・黄・緑+赤カード/「緑を騙る赤」=FUNC-0278(点検8)
▲
│ 「合格」の表示を無条件に信頼しない
[水準七] 封じ込め
短期封じ込め/長期封じ込め/quarantined(点検7)
▲
│ 被害の拡大をまず止める
[水準六] 検知の質
構造層(燃費0)/挙動層(実行して確かめる)(点検6)
▲
│ 気づかなければ何も始まらない
[水準五] トリアージ
影響の大きさ×拡大の速さの2軸(点検5)
▲
│ 何から手をつけるかを決める
[水準四] 時間軸の設計
一日再構成プレイブック(0-2h判定/2-6h封じ込め/
6-18h復旧/18-24h再検定)(点検4)
▲
│ 有限の時間をどう配分するか
[水準三] 防御の系譜の中の位置づけ
多層防御の「最後から2番目の層」(点検3)
▲
│ インシデント対応は一枚の壁ではない
[水準二] 対応の六段階
準備→検知→封じ込め→根絶→復旧→教訓(点検2)
▲
│ 決まった順序で動く
[水準一] インシデントとは何か
イベント→アノマリー→インシデントという階段(点検1)
横の広がり:
[水準八] 白・黄・緑(合格の軸) ←(別の軸)→ 赤カード(隔離の軸)
[水準七] 短期封じ込め ←(目的が異なる)→ 長期封じ込め
[水準六] 構造層(燃費0・全数) ←(境界二層戦略で連結)→ 挙動層(高コスト・境界限定)
現在のフロンティア(第一章コラム・第八章):
1988年 モリスワームの一件を機にCERT/CCが設立されたとされる
2004年 NISTがインシデント対応ガイドの最初の版を発表したとされる
2026年 本プロジェクト内でFUNC-0278の「緑を騙る赤」が実際に発見・修補される
※本書で扱った六段階・時間配分・色運用の考え方は、未解決の謎ではなく、
現在進行形で実務に使われ続けている現役の設計原理という意味でのフロンティアである。
次の巻(情報防衛と復旧シリーズ): BOOK-0364(フォレンジクスとログ解析
─タイムライン再構成→ハッシュと差分による改竄検知→ログの相関分析) ─────▶
```
---
## 参照文献(定番指針・一般規格・本プロジェクトの実在記録)
1. アメリカ国立標準技術研究所(NIST)による『コンピュータセキュリティインシデント対応ガイド』(NIST SP 800-61)系列。検知・分析→封じ込め・根絶・復旧→事後対応という局面を軸に据えた、実務者が広く参照する代表的な指針として知られる(初版は2004年発表とされる)。
2. 情報セキュリティ事故対応の歴史に関する定番文献群(1988年のモリスワームの一件とCERT/CC設立の経緯を扱う、計算機科学史の定番教材群)。
3. 本プロジェクトの実在記録: `gakumon/NUMBER_REGISTRY.md`(セッション上限事故〈ULTRA-28〉のディスク実地棚卸しと回収の記録、およびFUNC-0278「緑を騙る赤」の発見と修補の記録)。
4. 本プロジェクトの実在実装: `tools/check_conservation.js`(保存則監査器・改竄検知の一般例。詳しい解説は→BOOK-0359b第四章)、`tools/check_funcdict_langs.js`(構造層・挙動層の二層構造を持つ定期チェッカー)。
5. 本プロジェクトの実在設計書: `docs/DOC-0021_皮工場_要件定義.md`(quarantined状態によるライセンス無タグ資産の隔離設計)、`docs/DOC-0082_専門誌設計_言語間整合と検定文化の監査方法論.md`(色の状態遷移・一日再構成プレイブックの原設計)。
---
（本冊子は情報防衛と復旧シリーズ BOOK-0363。全12巻中の第4巻(インシデント対応の一本道)であり、シリーズの背骨に当たる。次巻BOOK-0364(フォレンジクスとログ解析)では、本書が要約にとどめた「判定」段階を、タイムライン再構成と改竄検知の技法として詳しく掘り下げる予定。CATALOG_情報防衛と復旧シリーズ.md・GAKUMON_UNIVERSE.md 進捗台帳を参照。）
# BOOK-0363 情報防衛と復旧シリーズ 第4巻: インシデント対応の一本道 — 一日という制約の中で、何から手をつけるかを決めるための地図