※小説ではない※専門書 要約資料集 為替(換算)3.9万円でもらう 紐解集生成 専門 初入門 資料 作：｛作者名｝
※物語はフィクションです ※
※即時通報案件は専門家にご通報ください※
※お手数ですが疑問点は各分野でご確認いただけましたら幸いです※
# BOOK-0371 情報防衛と復旧シリーズ 第12巻(最終巻): セキュアな再構成の実務 — 「もう一度、緑から始める」ための段階判断
> 情報防衛と復旧シリーズ(BOOK-0360〜0371・全12巻)第12巻・最終巻。ガイド役: Fable 5 監修 / Sonnet 5 執筆(脚本班)
> トーン規約: GAKUMON_UNIVERSE.md準拠。専門用語は初出で必ず説明する。
> **値札**: 「一日停止・全システム再構成の段階判断」という特命業務そのものを体系化する最終巻。バイト同一移植(既存構成を寸分違わず再現できることの確認)+境界の作り直し(信頼できない状態からの再構築の設計)+再検定(チェッカー・監査の再取得=緑への復帰)という三本柱を軸に、なぜ「再構成」という大がかりな手段が必要になるのか(水準一)から、本シリーズ全12巻がどう束ねられて最終判断に至るか(水準十二)までを歩く。
> **安全枠(§16.18・全巻共通・変更不可・最重要)**: 本書は**防御・検知・復旧に限定**する。実在システムへの侵入手順・動作するエクスプロイト・攻撃の再現コード・検知回避手法は一切書かない。脆弱性や欠陥は「何が起きるか(仕組み)・どう防ぐか・どう検知するか」という防御的視点でのみ扱う(IMPORTANT: authorized security testing / defensive security の枠内)。**誇張禁止(§16.5)**: 「これで完璧に復旧できる」「これさえ守れば二度と事故は起きない」等は書かない。再構成は突破された後の被害を最小化し信頼を再確立する手段であり、次の事故を絶対に防ぐ保証ではない、という正直な水準で書く。
> 接続先: →BOOK-0360『情報セキュリティ総論』(CIA三要素・多層防御という全巻の土台)、→BOOK-0361『認証認可とアクセス制御』(境界の作り直しで再利用する最小権限の設計)、→BOOK-0362『脆弱性の防御的理解と対策』(なぜ境界が汚染されるかの前提)、→BOOK-0363『インシデント対応の一本道』(本書が引き継ぐ「復旧」段階と、本書が予告のみにとどめていた「バイト同一移植」の詳しい手順)、→BOOK-0364『フォレンジクスとログ解析』(基準線を確保する前段の判定作業)、→BOOK-0365『バックアップと災害復旧』(本書が前提とする基準線そのものの作り方)、→BOOK-0366『可用性・信頼性工学』(冗長化・段階的縮退という、再構成に踏み切らずに済ませるための備え)、→BOOK-0367『監視と観測可能性』(再検定で使う検知の下敷き)、→BOOK-0368『監査・統制とコンプライアンス』(再構成の記録を制度に接続する最終段)、→BOOK-0369『鍵管理とPKIの実務』(境界の作り直しで再利用する鍵ローテ・PKIの実務。本書の執筆過程で`gakumon/`実地確認により本文・検定とも刊行が確認できた)・→BOOK-0370『ネットワーク防御の設計』(境界の作り直しで再利用するセグメンテーション・ゼロトラストの設計。本書の執筆過程で本文の刊行は確認できたが、本書の検定確認の時点では検定〈quiz/answers〉の刊行はまだ確認できなかった)。
> 水準: 一〜十二(なぜ再構成が必要になる事態が起きるかという入口から、三本柱の定義、防御の系譜の中の位置づけ、一日という制約の中での時間軸の深掘り、基準線の確保と検証、バイト同一移植の実務、境界の特定と隔離、境界の作り直し、再検定による緑への復帰、監査証跡と制度への接続、段階判断そのものの設計、そして本シリーズ全体がどう束ねられて最終判断に至るかという講師級のメタ的推移までを扱う)。
---
# BOOK-0371 情報防衛と復旧シリーズ 第12巻(最終巻): セキュアな再構成の実務 — 「もう一度、緑から始める」ための段階判断
> 情報防衛と復旧シリーズ(BOOK-0360〜0371・全12巻)第12巻・最終巻。ガイド役: Fable 5 監修 / Sonnet 5 執筆(脚本班)
> トーン規約: GAKUMON_UNIVERSE.md準拠。専門用語は初出で必ず説明する。
> **値札**: 「一日停止・全システム再構成の段階判断」という特命業務そのものを体系化する最終巻。バイト同一移植(既存構成を寸分違わず再現できることの確認)+境界の作り直し(信頼できない状態からの再構築の設計)+再検定(チェッカー・監査の再取得=緑への復帰)という三本柱を軸に、なぜ「再構成」という大がかりな手段が必要になるのか(水準一)から、本シリーズ全12巻がどう束ねられて最終判断に至るか(水準十二)までを歩く。
> **安全枠(§16.18・全巻共通・変更不可・最重要)**: 本書は**防御・検知・復旧に限定**する。実在システムへの侵入手順・動作するエクスプロイト・攻撃の再現コード・検知回避手法は一切書かない。脆弱性や欠陥は「何が起きるか(仕組み)・どう防ぐか・どう検知するか」という防御的視点でのみ扱う(IMPORTANT: authorized security testing / defensive security の枠内)。**誇張禁止(§16.5)**: 「これで完璧に復旧できる」「これさえ守れば二度と事故は起きない」等は書かない。再構成は突破された後の被害を最小化し信頼を再確立する手段であり、次の事故を絶対に防ぐ保証ではない、という正直な水準で書く。
> 接続先: →BOOK-0360『情報セキュリティ総論』(CIA三要素・多層防御という全巻の土台)、→BOOK-0361『認証認可とアクセス制御』(境界の作り直しで再利用する最小権限の設計)、→BOOK-0362『脆弱性の防御的理解と対策』(なぜ境界が汚染されるかの前提)、→BOOK-0363『インシデント対応の一本道』(本書が引き継ぐ「復旧」段階と、本書が予告のみにとどめていた「バイト同一移植」の詳しい手順)、→BOOK-0364『フォレンジクスとログ解析』(基準線を確保する前段の判定作業)、→BOOK-0365『バックアップと災害復旧』(本書が前提とする基準線そのものの作り方)、→BOOK-0366『可用性・信頼性工学』(冗長化・段階的縮退という、再構成に踏み切らずに済ませるための備え)、→BOOK-0367『監視と観測可能性』(再検定で使う検知の下敷き)、→BOOK-0368『監査・統制とコンプライアンス』(再構成の記録を制度に接続する最終段)、→BOOK-0369『鍵管理とPKIの実務』(境界の作り直しで再利用する鍵ローテ・PKIの実務。本書の執筆過程で`gakumon/`実地確認により本文・検定とも刊行が確認できた)・→BOOK-0370『ネットワーク防御の設計』(境界の作り直しで再利用するセグメンテーション・ゼロトラストの設計。本書の執筆過程で本文の刊行は確認できたが、本書の検定確認の時点では検定〈quiz/answers〉の刊行はまだ確認できなかった)。
> 水準: 一〜十二(なぜ再構成が必要になる事態が起きるかという入口から、三本柱の定義、防御の系譜の中の位置づけ、一日という制約の中での時間軸の深掘り、基準線の確保と検証、バイト同一移植の実務、境界の特定と隔離、境界の作り直し、再検定による緑への復帰、監査証跡と制度への接続、段階判断そのものの設計、そして本シリーズ全体がどう束ねられて最終判断に至るかという講師級のメタ的推移までを扱う)。
---
## 入口の物語 — 「直す」のではなく、「もう一度、正しく建て直す」
第4巻『インシデント対応の一本道』の入口では、こんな朝の光景を描いた。「昨夜から様子がおかしい」という一本の連絡。ログは静かなまま、画面も普段どおりに動いている。ただ、どこか一箇所だけ、数字が合わない。あの巻はそこから、判定・封じ込め・根絶・復旧・教訓という六段階の一本道をたどり、最後にこう予告して終わった——「疑わしい部分だけを1件ずつ直すのではなく、システム全体を、疑いのない土台から丸ごと建て直す」という、もう一段大がかりな手段があり、その詳しい手順はシリーズの最終巻に委ねる、と。
本書が扱うのは、まさにその「もう一段大がかりな手段」である。個々の欠陥を1件ずつ修復する**部分修復**では、もう追いつかない場面がある。基準線(疑いのない、確実に正常だったとわかる状態)がどこにあるのか自体が怪しくなったとき。汚染された範囲がどこまで及んでいるのか、境界線を引けなくなったとき。こうした場面では、担当者は決断しなければならない——「今日一日、システムを止めて、丸ごと建て直す」。
この決断は、軽々しく下してよいものではない。システムを一日止めるということは、利用者に迷惑をかけ、業務を止め、信頼を一時的に犠牲にするということである。だからこそ、この決断そのものを、思いつきではなく、体系立った判断の手順として持っておく必要がある。「どういう兆候が揃ったら、部分修復をあきらめて全システム再構成に切り替えるべきか」「一日という限られた時間の中で、何から手をつけ、何にどれだけの時間を割くべきか」「建て直した後、本当に元どおり信頼してよいと、何をもって確認するのか」。この一連の問いに答えることこそが、このプロジェクトの内部で実際に交わされた特命——「一日停止・全システム再構成の段階判断」という業務——の正体であり、本書はこの段階判断そのものを、一冊まるごと使って体系化する。
再構成という言葉には、もう一つ大切な含みがある。それは「壊れたものを直す」という発想ではなく、「もう一度、疑いのない土台から正しく建てる」という発想である。壊れた部分だけをつぎはぎで直そうとすると、直したはずの場所にまた別の欠陥が紛れ込む余地が残る。そうではなく、疑う必要のない部分は寸分違わずそのまま複製し(これを本書では**バイト同一移植**と呼ぶ)、疑わしい境界の部分だけは、古い設定や鍵をそのまま引き継がずにゼロから設計し直し(これを**境界の作り直し**と呼ぶ)、最後に、建て直した全体が本当に正しく動いているかを、チェッカーと監査によってもう一度確かめる(これを**再検定**と呼ぶ)。この三本柱こそが、本書全体を貫く一本の糸である。
この巻はまた、シリーズ全体の締めくくりでもある。第1巻から第11巻までが積み上げてきた、土台・予防・検知・判定・対応・復旧という一つひとつの技能は、最終的にはすべて、この「一日停止・全システム再構成」という最も重い決断を、落ち着いて、正しい順序で下すためにある。最終章(第十二章)では、この積み上げの全体像を、講師の視点からあらためて俯瞰する。まずは、なぜこのような重い決断が必要になる事態がそもそも起きるのか、という入口から歩き始めよう。
---
## 第一章: なぜ「再構成」が必要になる事態が起きるか(水準一)
### 「直せば済む」で終わらない場面
情報を扱う現場で欠陥が見つかったとき、多くの場合は**部分修復(ぶぶんしゅうふく、水準一: 発見された欠陥の箇所だけをピンポイントで修正し、それ以外の部分はそのまま動かし続ける対応)**で十分である。欠陥のある1行を直し、独立した担当者が再実測して一致を確認すれば、それで対応は完了する。第4巻で扱った「緑を騙る赤」(FUNC-0278番のカードの一件)も、この部分修復で解決した典型例だった。
しかし、すべての事態が部分修復で済むとは限らない。ときには、次のような重い決断を迫られる場面がある。**全システム再構成(ぜんシステムさいこうせい、水準一: 個々の欠陥を1件ずつ修復するのではなく、システムを構成する要素全体を、あらためて疑いのない状態から組み立て直すこと)**である。部分修復と全システム再構成は、どちらも「正しい状態に戻す」という目的は同じだが、手段の重さがまったく違う。前者は外科手術のように患部だけに手を入れる。後者は、土台から立て直す大工事に近い。
### 再構成に踏み切らせる、二つの引き金
なぜ、部分修復では足りず、全システム再構成にまで踏み切る必要が生じるのか。実務でよく見られる引き金は、大きく二つに整理できる。
```
引き金1: 基準線喪失(きじゅんせんそうしつ、水準一: どの状態が「疑いのない
正常な状態」だったのかを示す確かな記録・複製そのものが、
失われている、あるいは汚染されている疑いが生じること)
引き金2: 境界不明(きょうかいふめい、水準一: 汚染の疑いがある範囲が
どこまで及んでいるのか、確信を持って線引きできない状態)
```
基準線が確実に残っているなら、疑わしい箇所だけを基準線と突き合わせて直せばよい。汚染の範囲がはっきり分かっているなら、その範囲だけを封じ込めて根絶すればよい。しかし、基準線そのものが信用できなくなったり、汚染がどこまで広がったか分からなくなったりすると、「どこを直せば安全なのか」という問い自体が成立しなくなる。この状態に陥ったとき、担当者に残された現実的な選択肢は、疑わしい部分を1件ずつ追いかけることではなく、システム全体を、確実に信頼できる別の土台からあらためて組み立て直すことになる。
### 点検1 — 部分修復で足りるか、全システム再構成が要るか
次の2つの事態を比べてみよう。
```
事態A: 総関数辞書のうち1枚のカードに欠陥が見つかった。欠陥の原因は
特定でき、修補後に別の担当者が独立に再実測して一致を確認できた。
他のカードへの影響は確認されていない。
事態B: 管理者権限を持つアカウントの認証情報が、いつから、どの経路で
漏れた可能性があるのか特定できず、また直近のバックアップ自体が
いつ汚染された可能性があるのかも判別できない状態にある。
```
事態Aは、原因が特定でき、影響範囲も限定されており、基準線(修補前の正しいカードの記録)も確実に残っている。これは部分修復で十分に対応できる典型例である。事態Bは、境界(いつからどこまで汚染されたか)が不明であり、なおかつ基準線(バックアップ自体)の信頼性まで揺らいでいる。この場合、疑わしい箇所を1件ずつ追いかけるやり方では「本当にすべて洗い出せたのか」を誰も保証できない。事態Bこそが、本書が扱う全システム再構成の対象である(点検成立)。
### コラム — 「止める」という決断のコスト
全システム再構成には、必ず「システムを止める」という代償が伴う。この代償を正直に見積もらずに再構成を選ぶと、部分修復で済んだはずの事態にまで大がかりな手段を持ち出し、無駄に業務を止めてしまうことになる。逆に、本当は再構成が必要な事態を「部分修復で何とかなる」と過小評価してしまうと、疑わしい箇所を追いかけ続けるだけで時間を浪費し、その間も汚染が広がり続ける。この二つの誤りのどちらにも陥らないための判断基準を体系立てて示すことこそが、本書、とりわけ第十一章の主題になる。
### よくある誤解 — 「迷ったら、とりあえず全部作り直した方が安全」という誤解
基準線や境界について少しでも迷いが生じると、「念のため、全部作り直しておこう」という判断に流れたくなることがある。しかし本書は、この判断を誇張なく戒めておく。全システム再構成は、第一章冒頭で確認したとおり、疑わしい箇所を1件ずつ追いかけるやり方が通用しなくなったときに初めて選ぶべき、重い手段である。迷いのすべてを「とりあえず全部」で解消しようとすると、システムを止める代償ばかりが積み重なり、しかも第六章以降で扱う三本柱を急いで済ませようとするあまり、かえって新しい間違いを持ち込む危険もある。「迷ったら丸ごと作り直す」ではなく、「迷ったら、まず基準線喪失と境界不明という二つの引き金が本当に当てはまっているかを、落ち着いて点検する」という順序を、本書は一貫して勧める。
---
> **定着量の目安(第一章)**: 「部分修復で済む欠陥」と「全システム再構成が要る事態」の違いを、基準線と境界という2つの言葉を使って自分の言葉で説明できるようにしておく。身の回りの小さな例(たとえば「1本のねじを締め直せば直る家具のガタつき」と「土台から歪んでいて建て直しが要る古い小屋」)に当てはめて考える練習も有効である。
---
## 第二章: 再構成の三本柱(水準二)
### バイト同一移植・境界の作り直し・再検定
第一章で確認したとおり、全システム再構成は「疑わしい部分を1件ずつ追いかける」やり方が通用しなくなったときの手段である。この手段を、行き当たりばったりの作業にしないために、本書は再構成を三つの柱に分けて扱う。
```
柱1: バイト同一移植(バイトどういついしょく、水準二: 汚染前の既知の
正常な状態を、1バイトの違いもなく複製することで、疑いのない
土台をまず確保する技法)
柱2: 境界の作り直し(きょうかいのつくりなおし、水準二: 信頼できないと
判定された境界部分について、既存の設定・鍵・権限をそのまま
引き継がず、ゼロから設計し直すこと)
柱3: 再検定(さいけんてい、水準二: チェッカーや監査をあらためて実行し、
白・黄・緑という検定文化の中で「緑」の状態を、確かな根拠とともに
再び確立し直すこと)
```
この三本柱は、順番に積み上がる関係にある。まず柱1(バイト同一移植)で、疑う必要のない土台を確保する。次に柱2(境界の作り直し)で、疑わしい部分だけをゼロから設計し直す。最後に柱3(再検定)で、組み上がった全体が本当に正しく動いているかを、機械的に確かめる。この順序を逆にすることはできない。土台が確保される前に境界を作り直そうとしても、何を基準に「作り直せた」と判断すればよいか定まらない。境界の作り直しが終わる前に再検定をしても、まだ手を入れていない部分まで含めて「合格」と誤認してしまう危険がある。
### なぜ「作り直し」ではなく「移植」なのか
柱1がわざわざ「移植」という言葉を使っているのには理由がある。疑う必要のない部分まで新しく作り直してしまうと、作り直す過程そのものに新しい間違いを持ち込む機会が増える。これは第4巻第十章のコラムで確認した教訓——「全部作り直すより、境界だけ作り直すほうが確実である」——と同じ考え方である。バイト同一移植は、「複製する」という単純な操作に徹することで、新しい間違いが入り込む余地を最小限に抑える。
### 点検2 — 三本柱のどれに当たるか
次の3つの作業を、三本柱のどれに当たるか分類してみよう。
```
作業ア: 汚染前の設定ファイル一式を、ハッシュ値が完全に一致することを
確認しながら複製した。
作業イ: 汚染の疑いがあった認証情報をすべて無効化し、最小権限の考え方に
沿って新しいアカウント体系をゼロから設計した。
作業ウ: 再構成後のシステムに対し、独立した担当者が改めてチェッカーを
実行し、白・黄・緑のうち「緑」の状態にあることを確認した。
```
作業アは柱1(バイト同一移植)、作業イは柱2(境界の作り直し)、作業ウは柱3(再検定)に当たる(点検成立)。この3つが揃って初めて、全システム再構成は完了したと言える。
### コラム — 三本柱と、第4巻の一日再構成プレイブック
第4巻『インシデント対応の一本道』第四章では、一日再構成プレイブックとして「0〜2時間: 判定」「2〜6時間: 封じ込め」「6〜18時間: 復旧」「18〜24時間: 再検定」という時間配分を紹介した。この配分表のうち「6〜18時間: 復旧」という12時間の枠の中身こそが、本書の柱1と柱2(バイト同一移植と境界の作り直し)であり、「18〜24時間: 再検定」がそのまま本書の柱3に対応する。第4巻が要約にとどめた部分を、本書はここから先、一段深く掘り下げていく。
---
> **定着量の目安(第二章)**: バイト同一移植・境界の作り直し・再検定という三本柱の名前と意味を、順番を含めて空で言えるようにしておく。「なぜこの順番でなければならないか」を自分の言葉で説明できると、以降の章の理解がより滑らかになる。
---
## 第三章: 防御の系譜の中の位置づけ — 最終防波堤(水準三)
### 予防・検知・対応・復旧、そのさらに先
第4巻第三章では、インシデント対応を多層防御の中の「最後から2番目の層」と位置づけた。本書が扱う全システム再構成は、その、さらに一段奥にある。**最終防波堤(さいしゅうぼうはてい、水準三: 予防・検知・対応のすべてが実質的に機能しなかった、あるいは機能したかどうか自体が疑わしいときに発動する、最後の手段としての全面的な立て直し)**という位置づけである。
予防の層(→BOOK-0361認証認可、→BOOK-0362脆弱性の防御的理解、→BOOK-0369鍵管理、→BOOK-0370ネットワーク防御)がどれだけ厚くても、突破される確率をゼロにはできない。検知の層(→BOOK-0367監視と観測可能性)がどれだけ精緻でも、気づくのが遅れることはある。対応の層(→BOOK-0363インシデント対応、→BOOK-0364フォレンジクス)がどれだけ手順化されていても、基準線や境界そのものが揺らぐ事態には、部分修復では追いつかない。こうしたすべての層が力を発揮しきれなかったときに、初めて発動するのが、本書が扱う全システム再構成である。
### 「最後の手段」であることの意味
最終防波堤という位置づけは、二つのことを同時に意味している。一つは、全システム再構成が「めったに使わない、重い手段」であるということ。日常的に使うべき手段ではなく、他のすべての層が機能しなかったときに限って発動する、というのが本来の姿である。もう一つは、それでも「最後の頼みの綱として、必ず機能しなければならない」ということ。他の層がすべて崩れたとしても、この最終防波堤だけは確実に機能する、という信頼性が求められる。この二重の要求——めったに使わないが、使うときには確実に機能する——が、本書が扱う技法(バイト同一移植・境界の作り直し・再検定)に一貫して要求される厳密さの理由である。
### 点検3 — どの層が最終防波堤に当たるか
次の4つの層のうち、本書が扱う「最終防波堤」に当たるのはどれだろうか。
```
層1: 認証・認可による最小権限の設計(予防)
層2: ログとメトリクスによる異常の検知(検知)
層3: 六段階の一本道による判定と封じ込め(対応)
層4: 基準線からの丸ごとの建て直しと、緑への再検定(再構成)
```
層1〜3は、それぞれ予防・検知・対応という、事態が深刻化する前、あるいは深刻化した直後に働く層である。層4だけが、他の層が機能しなかった、あるいは機能したかどうか自体が疑わしいという、最も重い状況で発動する層であり、これが本書の扱う最終防波堤に当たる(点検成立)。
### コラム — 「最終防波堤」という言葉を、他の層の言い訳にしない
最終防波堤という位置づけを紹介すると、ときどき「多少予防が甘くても、最後に再構成すれば取り返せる」という誤った安心につながることがある。しかし本書はこの読み方を誇張なく否定する。全システム再構成は、システムを一日止めるという重い代償を払い、しかも第五章以降で扱うとおり、確実な基準線が残っていることを前提にして初めて機能する手段である。予防の層が薄ければ薄いほど、基準線そのものが汚染される確率も上がり、最終防波堤自体が機能しなくなる危険が高まる。最終防波堤は、予防の層の手抜きを埋め合わせる保険ではなく、予防・検知・対応のすべてが最善を尽くしてもなお起き得る、まれな事態のための備えである、という位置づけを誤らないようにしたい。
### コラム — 最終防波堤を鍛えることの意味
最終防波堤を鍛えるという営みは、一見すると「予防を怠ってよい」という話に聞こえるかもしれないが、これは正確ではない。予防・検知・対応の層が厚ければ厚いほど、最終防波堤の出番そのものが減る。しかし、出番が少ないからといって、最終防波堤を鍛えずに放置してよいわけではない。むしろ出番が少ない手段こそ、いざというときに手順が曖昧なまま右往左往しやすい。本書が扱う三本柱を、実際に事態が起きる前から体系立てて理解しておくことこそが、最終防波堤としての信頼性を支える。
---
> **定着量の目安(第三章)**: 予防・検知・対応・再構成という4つの層を、自分の言葉でそれぞれ1文ずつ説明し、「なぜ再構成が最後の層に位置するのか」を答えられるようにしておく。
---
## 第四章: 一日停止・全システム再構成の時間軸設計(水準四)
### 第4巻の配分表を、もう一段深く割る
第4巻第四章で紹介した一日再構成プレイブックは、「6〜18時間: 復旧」「18〜24時間: 再検定」という2つの大きな枠を示していた。本書はこの2つの枠を、三本柱(バイト同一移植・境界の作り直し・再検定)に沿って、さらに細かい時間割へと分割する。
```
0〜2時間 : 判定(→BOOK-0363・0364が詳しく扱う段階。本書は前提として扱う)
2〜6時間 : 封じ込め(→BOOK-0363が詳しく扱う段階。本書は前提として扱う)
6〜8時間 : 基準線確保 — 疑いのない既知の正常な状態を確定し、
複数の独立した経路から同一性を確認する(第五章)
8〜14時間 : バイト同一移植の実行 — 基準線をそのまま複製し、
複製後にハッシュ値の一致を確認する(第六章)
14〜18時間 : 境界の作り直し — 疑わしい境界部分だけを、既存の設定を
引き継がずゼロから設計し直す(第七・八章)
18〜20時間 : 構造層再検定 — 燃費の低い自動チェックで全件を検査する(第九章)
20〜23時間 : 挙動層再検定 — 実行して基準線と突き合わせ、
独立した担当者が再実測する(第九章)
23〜24時間 : 最終承認と記録 — 再検定の結果を監査証跡として残し、
指揮役が復帰を最終承認する(第十章)
```
### なぜ基準線確保にまず2時間を割くのか
一見、バイト同一移植(複製作業そのもの)にすぐ着手したくなるかもしれないが、本書はあえて「基準線確保」という確認作業に、先立つ2時間を割く。複製そのものは単純な操作だが、「何を複製すべきか」が間違っていれば、どれだけ正確に複製しても意味がない。複製元となる基準線が本当に疑いのない状態かどうかを、複数の独立した経路から確かめる作業は、後続のすべての工程の土台になるため、急いで飛ばしてはならない。この考え方の詳しい中身は、次の第五章で扱う。
### 点検4 — 時間配分の誤りを見つける
次の時間配分案を点検してみよう。
```
案: 基準線確保に30分、バイト同一移植の実行に10時間、
境界の作り直しに30分、再検定は省略して即座に復帰させた。
```
この案には二つの誤りがある。一つは、基準線確保という土台の確認作業を極端に切り詰めている点(疑わしい土台の上に複製を重ねる危険がある)。もう一つは、再検定を省略している点である。第4巻第十章で確認したとおり、「動いて見える」ことは復旧完了の根拠にならない。再検定を省略したまま復帰させることは、「緑を騙る赤」を自ら作り出す行為に等しい(点検成立)。
### コラム — 時間配分は現場ごとに調整してよい
第4巻のコラムで確認したとおり、「一日」という制約は、あくまで最も厳しい条件下での練習台である。本章で示した細かい時間割も、絶対に守るべき固定値ではない。基準線の量が多ければ基準線確保に多くの時間が必要になるし、境界が広ければ境界の作り直しに多くの時間が必要になる。大切なのは、判定と封じ込めを短く鋭く終え、土台の確保・移植・境界の作り直しに厚く時間を配分し、最後に必ず再検定の時間を確保するという、配分の思想そのものである。
---
> **定着量の目安(第四章)**: 本章で示した6区分の時間割(基準線確保/バイト同一移植の実行/境界の作り直し/構造層再検定/挙動層再検定/最終承認)を、何も見ずに順番どおり書き出せるようにしておく。
---
## 第五章: 基準線の確保と検証(水準五)
### 「疑いのない状態」を、どうやって疑いのない状態だと確認するのか
全システム再構成の土台になるのは、疑いのない既知の正常な状態、すなわち**基準線(きじゅんせん、水準五: システムが正しく機能していたことが確実にわかっている、比較の基準となる状態)**である。しかし、ここには一つの厄介な問いが潜んでいる——その基準線自体が汚染されていないと、なぜ言い切れるのか。
この問いに安易な答えはない。しかし、実務で使える現実的な備えはある。**単一障害点(たんいつしょうがいてん、水準五: たった一つが失われる、あるいは汚染されるだけで、全体の信頼性が崩れてしまう、その一点)**を作らないことである。基準線を1か所にしか置かないと、その1か所が汚染された瞬間に、再構成全体の土台が崩れる。これに対し、基準線を複数の独立した経路(物理的に離れた保存先、異なる時刻に取得した複数の世代、異なる担当者が個別に検証した記録)に分散して確保しておけば、そのうちの1つが疑わしくても、他の経路と突き合わせることで、本当に信頼できる基準線を絞り込める。
### 保存則検査という考え方の再利用
基準線の信頼性を確かめる手段の一つに、第4巻第六章で紹介した改竄検知の考え方がある。本プロジェクトの`tools/check_conservation.js`は、個々の記録の見た目上の正しさだけでなく、台帳全体の帳尻(生成の合計から消滅の合計を引いた値が、全所有者の残高の合計と一致するかどうか)を機械的に突き合わせる、**保存則検査**(FUNC-0769)を実装している。この考え方は、金融台帳に限らず、基準線の検証にもそのまま応用できる。「この基準線の中身は、既知の総量や構造上の帳尻と矛盾していないか」を機械的に確かめることは、1件ずつ目視で確認する検定では見抜けない改竄を、構造から検出する手がかりになる。
基準線同士、あるいは基準線と再構成後の状態を突き合わせる場面では、**最終状態ハッシュ照合**(FUNC-0644・final state hash matching)の考え方も有効である。複製した結果のハッシュ値が、基準線のハッシュ値と完全に一致するかどうかを機械的に確認することは、次章で扱うバイト同一移植の合否判定そのものの土台になる。
### 点検5 — どちらの基準線確保がより信頼できるか
次の2つの基準線確保のやり方を比べてみよう。
```
やり方甲: 直近1回分のバックアップだけを確認し、内容に問題がなさそうな
ので、それをそのまま基準線として採用した。
やり方乙: 物理的に異なる2か所に保存された、異なる世代のバックアップを
突き合わせ、両者が一致する部分を基準線とし、一致しない部分は
さらに別の独立した記録(ログや台帳)と照合して確定させた。
```
やり方甲は、単一障害点を作ってしまっている。その1回分のバックアップ自体が汚染されていた場合、それに気づく手立てがない。やり方乙は、複数の独立した経路を突き合わせることで、単一障害点を避けており、本章が求める基準線確保の水準を満たしている(点検成立)。
### 実例 — 基準線を「読む」だけでなく「組み立てて動かす」ことの重要性
第4巻第八章で確認したFUNC-0278番のカードの一件は、基準線の検証という文脈でも重要な教訓を残している。この一件では、4回にわたる「読んで確認する検定」がいずれも欠陥を見抜けず、5回目の「実際に組み立てて実行する検定」によって初めて欠陥が明らかになった。この教訓は、基準線の検証にもそのまま当てはまる。基準線の候補となる複製を、ファイル一覧やサイズだけを見て「問題なさそうだ」と判断するのは、いわば「読んで確認する検定」に相当する。これに対し、実際にその基準線を使ってシステムを組み立て、期待どおりに動作するかどうかまで確認するのは、「実際に組み立てて実行する検定」に相当する。一日という制約の中で、すべての基準線候補についてここまで丁寧な確認を行う時間は取れないかもしれないが、少なくとも再構成の土台として採用する基準線については、単なる目視の確認にとどめず、実際に組み立てて動かしてみるところまで踏み込むべきである、というのが本章の立場である。
### コラム — 基準線が本当に見つからないとき
第4巻第四章のコラムで確認したとおり、一日再構成プレイブックが機能する前提は、「基準線がどこかに確実に残っている」ことである。もし基準線そのものが本当にどこにも残っていない場合、本書が扱う技法はそのままでは機能しない。この場合に取れる現実的な選択肢は、影響範囲をさらに広く見積もり、より古い、確実に信頼できる世代まで遡ることである。基準線を普段から複数の独立した経路で確保しておくこと(→BOOK-0365『バックアップと災害復旧』が専門に扱う)こそが、この章の議論そのものを不要にする、最も確実な備えである。
---
> **定着量の目安(第五章)**: 「単一障害点を作らない基準線確保」を、自分の言葉で説明できるようにしておく。自分の大切なデータ(写真・書類など)の保存先が、実際に何か所の独立した経路に分散しているかを数えてみる練習も有効である。
---
## 第六章: バイト同一移植の実務(水準六)
### 「複製する」という、単純だが厳密な操作
基準線が確保できたら、次はいよいよ柱1、**バイト同一移植**の実行である。この技法の核心は、複雑な判断を挟まず、「複製する」という単純な操作に徹することにある。単純であることは手抜きではない。第4巻第十章のコラムで確認したとおり、複雑な作業ほど新しい間違いが入り込む余地が大きく、単純な複製操作に徹することこそが、新しい間違いを持ち込まない、確実な土台の作り方である。
複製が終わったら、複製元(基準線)と複製先が本当に1バイトも違わないことを、ハッシュ値の一致によって機械的に確認する。この確認作業には、**決定的再計算検証**(FUNC-0643・deterministic recomputation verification)や、**スナップショット突合状態復元検証**(FUNC-1146・snapshot restore verify)といった考え方が使える。目視で「同じに見える」ことと、ハッシュ値が完全に一致することは、まったく別の水準の確認である。
### 実例 — マウント越しの複製で実際に起きた事故と、そこから確立されたレシピ
バイト同一移植が単純な操作でありながら、なぜ厳密さが要るのかを示す、生きた実例がこのプロジェクトの記録に残っている。本プロジェクトでは、ホスト側フォルダとVM(仮想環境)側のマウント経由で同じファイルを扱う場面があるが、ある日、20キロバイトを超えるファイル(editor.html v2)について、VM側から見たファイルサイズが31,742バイトという、ホスト側の実体よりも古い・不完全なサイズで見えるという事故が2026年7月3日に実証された。原因は、VMマウントがキャッシュを剥離し、古い状態を見せてしまうことにあった。もしこの状態に気づかず、VM側で見えている(実は古い)内容を基準にして追記や改訂を行っていたら、ホスト側の正しい内容を巻き戻してしまうところだった——実際、この事故の直後には、まさにその巻き戻りが発生したことも記録されている。
この事故から確立されたレシピは、本書が扱うバイト同一移植の考え方そのものを体現している。**ホスト側で内容を確認する(正の経路)→別の検査用の経路(たとえばコマンド経由でのファイル転写)を通じて、期待どおりの内容が実際に反映されているかを確認する**、という2段構えである。1つの経路(この場合はVMマウント越しの見た目)だけを信じず、複数の独立した経路で内容を突き合わせて初めて、「本当に同一である」と言える——これは、第五章で扱った単一障害点を避ける基準線確保の考え方と、まったく同じ構造をしている。マウント経由の見た目だけを信じることは、基準線を1か所だけに置くことと同じ危うさを持つ、という教訓である。
### 点検6 — バイト同一移植として十分かどうかの判定
次の2つの報告のうち、バイト同一移植が完了したと言える根拠として十分なものはどちらだろうか。
```
報告A: 「複製先のフォルダを開いて、ファイル名と大まかなサイズが
基準線と同じであることを目視で確認した」
報告B: 「複製先の全ファイルについてハッシュ値を計算し、基準線の
ハッシュ値と完全に一致することを確認した。加えて、複製経路とは
別の独立した経路からも同じ内容が反映されていることを確認した」
```
報告Aは目視での確認にとどまっており、第六章で紹介した実例(VMマウントの見た目が古いサイズを示していた事故)と同じ落とし穴に陥る危険がある。報告Bは、ハッシュ値による機械的な一致確認と、複数経路での突き合わせの両方を満たしており、本章が求めるバイト同一移植の完了基準を満たしている(点検成立)。
### コラム — 「追記」と「改訂」にも、同じ厳密さが要る
バイト同一移植は、初回の複製だけでなく、複製後に内容を追記・改訂する場面にも同じ考え方が及ぶ。信頼できない経路(たとえば古い状態を見せている可能性のある経路)を土台にして読み書きを行うと、正しい内容を巻き戻してしまう危険がある。追記や改訂は、必ず確認済みの正の経路を土台にして行う、という原則を徹底することが、バイト同一移植で確保した土台を、その後の作業で台無しにしないための鍵になる。
### よくある誤解 — 「バイト同一移植さえ終われば、境界の作り直しは要らない」という誤解
柱1(バイト同一移植)が無事に完了すると、「疑いのない土台が戻ってきたのだから、これで再構成は終わりだ」と早合点してしまうことがある。しかしこれは正確ではない。バイト同一移植が確保するのは、あくまで「疑う必要のない部分」だけである。境界として特定された部分(第七章)は、定義上、まだ疑いが晴れていない範囲であり、そこにバイト同一移植を適用することはできない——疑わしいものをそのまま複製しても、疑いはそのまま複製されるだけだからである。境界の部分には、必ず柱2(境界の作り直し、第八章)を別途適用する必要がある。この2つの柱を混同しないことが、再構成全体の質を左右する。
---
> **定着量の目安(第六章)**: 「目視での確認」と「ハッシュ値による機械的な一致確認」の違いを、自分の言葉で説明できるようにしておく。あわせて、「1つの経路だけを信じない」という考え方を、第五章の基準線確保の議論と結びつけて説明する練習をすると、両者のつながりが定着しやすい。
---
## 第七章: 境界の特定と隔離(水準七)
### 境界二層戦略を、再構成の場面に応用する
第4巻第四章で紹介した**境界二層戦略**(システムの大部分を燃費の低い自動チェックで面として守り、汚染の疑いが具体的に生じた境界部分だけに、時間のかかる詳しい検査を集中的に投じる、という時間配分の戦略)は、判定の場面だけでなく、再構成の場面にもそのまま応用できる。バイト同一移植で土台を確保した後、次に必要なのは、「どこからどこまでが、境界の作り直しを必要とする範囲なのか」を、できるだけ正確に絞り込む作業である。
この絞り込みは、まず構造層(外部への依存を持たず、短時間で全件を検査できる自動チェック)によって、疑わしい候補範囲を広く洗い出すところから始める。次に、絞り込んだ候補範囲だけに、挙動層(実際に動かして確かめる、より手間のかかる検査)を投じ、本当に境界として扱うべき範囲を確定する。全件に対して挙動層の検査をいきなり投じるのは、一日という制約の中では現実的でない。
### 実例 — quarantinedという隔離状態の再利用
第4巻第七章で紹介した、素材(画像)を辞書へ登録する仕組みにおける**quarantined(隔離済み)**という状態は、境界の特定と隔離の場面でもそのまま再利用できる考え方である。境界として特定された範囲に属する資産を、通常の資産が並ぶ場所とは物理的に別の場所へ移送し、白・黄・緑という検定の合格の階段のいずれにも昇格できない状態に置く。この隔離によって、境界の外側(バイト同一移植で確保した土台)が、境界の内側の作業によって汚染される事故を防ぐことができる。
境界を特定する際には、**参照先存在検査**(FUNC-0953・reference target existence check)の考え方も有効である。境界の内側にある資産が、境界の外側(すでに信頼できると確認済みの土台)にある何を参照しているのかを機械的に洗い出し、参照先が本当に存在し、かつ信頼できる状態にあるかを確認する。参照先が不明な、あるいは存在しない箇所が見つかれば、それは境界をさらに広げて再検討すべき手がかりになる。
### 点検7 — 境界を正しく絞り込めているか
次の2つの絞り込み方を比べてみよう。
```
絞り込み方X: 汚染の疑いがある1つのアカウントに関連する設定ファイルだけを
境界とし、そのアカウントが参照していた他の資産は
確認しないまま、境界の外側として扱った。
絞り込み方Y: 汚染の疑いがあるアカウントに関連する設定ファイルを境界の
出発点とし、そこから参照先存在検査を行って、そのアカウントが
実際に参照していた資産をすべて洗い出したうえで、
境界の範囲を確定した。
```
絞り込み方Xは、参照関係を確認しないまま境界を狭く区切ってしまっており、実際には汚染が及んでいたかもしれない参照先を見逃す危険がある。絞り込み方Yは、参照関係を機械的に洗い出したうえで境界を確定しており、本章が求める境界特定の水準を満たしている(点検成立)。
### コラム — 境界を広く取りすぎることの代償
境界を安全側に倒して広く取りすぎると、境界の作り直しにかかる時間と労力が膨らみ、一日という制約の中で再検定の時間まで確保できなくなる危険がある。逆に境界を狭く取りすぎると、汚染の見落としにつながる。この綱引きに絶対の正解はないが、参照先存在検査のような機械的な手がかりを使って境界を確定させることで、担当者の勘だけに頼らない、根拠のある線引きに近づけることができる。
---
> **定着量の目安(第七章)**: 構造層による広い洗い出しと、挙動層による絞り込んだ確認という二段構えを、境界特定の場面に当てはめて自分の言葉で説明できるようにしておく。
---
## 第八章: 境界の作り直し — 信頼できない状態からの再構築設計(水準八)
### なぜ、境界の内側は「引き継がない」のか
境界が特定できたら、いよいよ柱2、**境界の作り直し**である。ここで最も重要な原則は、境界の内側にあった既存の設定・鍵・権限を、そのまま引き継がないということである。境界の内側は「信頼できない状態」として扱われているのだから、そこにあったものをそのまま流用してしまっては、汚染の疑いをそのまま引き継いでしまうことになる。
この考え方は、→BOOK-0361『認証認可とアクセス制御』が扱う**最小権限**の設計思想と地続きである。境界の作り直しでは、権限を「引き継ぐ」のではなく、「必要な範囲だけを、ゼロからあらためて割り当て直す」。認証情報についても同様で、境界の内側にあった鍵やパスワードは、汚染の疑いの有無にかかわらず、すべて無効化したうえで新しいものに置き換える。これは第4巻第九章で扱った根絶の代表的な型(侵害の疑いがある鍵や認証情報を無効化し、新しいものに置き換える鍵ローテ)を、境界全体という単位に拡張したものだと言える。
### 予防の層との接続 — 第10巻・第11巻という2つの隣人
境界の作り直しで再利用する技法の詳しい中身——鍵のローテーションやPKI(公開鍵基盤)の実務は→BOOK-0369『鍵管理とPKIの実務』が、ネットワークの区画分けやゼロトラストの設計は→BOOK-0370『ネットワーク防御の設計』が、それぞれ専門に扱う。本書の執筆過程で`gakumon/`を実地に確認したところ、第10巻(BOOK-0369)は本文・検定(quiz/answers)ともに刊行が確認できた。第11巻(BOOK-0370)は本文の刊行が確認できたが、本書の検定を確定させた時点では、検定一式(quiz/answers)の刊行はまだ確認できなかった。この確認結果自体、本書執筆の最中に両巻の刊行作業が並行して進んでいたことを示しており、「刊行済み」という状態が一瞬で固定されるものではなく、確認した時点でのスナップショットに過ぎないことを、この場を借りて正直に記しておく。境界の作り直しという作業の骨格そのものは、本書が示す「引き継がず、ゼロから設計し直す」という原則で足りるが、鍵管理やネットワーク区画の実務の詳しい手順は、この2巻の本文にすでに委ねられている。
### 点検8 — 境界の作り直しとして十分かどうかの判定
次の2つの対応を比べてみよう。
```
対応甲: 境界内のアカウントについて、パスワードだけを変更し、
権限の設定はそれまでと同じものをそのまま引き継いだ。
対応乙: 境界内のアカウントをすべて無効化し、認証情報を新しく発行し
直したうえで、権限も最小権限の考え方に沿って、必要な範囲だけを
ゼロから割り当て直した。
```
対応甲は認証情報こそ更新しているが、権限の設定を無条件に引き継いでしまっており、もし過剰な権限が汚染の一因だった場合、その問題を温存してしまう。対応乙は認証情報と権限の両方をゼロから設計し直しており、本章が求める境界の作り直しの水準を満たしている(点検成立)。
### コラム — 「作り直し」は「疑うこと」であって「非難すること」ではない
境界の作り直しという作業は、その境界に関わっていた設定や権限を「疑う」作業ではあるが、それを設計・運用していた担当者を「非難する」作業ではない。第4巻第十一章で確認した「非難しない文化」の原則は、境界の作り直しの場面にもそのまま当てはまる。過去の設定を疑うことと、過去の判断をした人を責めることは、まったく別の話である。
---
> **定着量の目安(第八章)**: 「引き継がず、ゼロから設計し直す」という境界の作り直しの原則を、認証情報と権限それぞれについて具体的に説明できるようにしておく。
---
## 第九章: 再検定 — チェッカーと監査の再取得、緑への復帰(水準九)
### 「建て直した」と「合格した」は別の話
柱1(バイト同一移植)と柱2(境界の作り直し)が終わっても、それだけでは全システム再構成は完了しない。第4巻第十章で確認した教訓——「動いて見える」ことは復旧完了の証拠にならない——は、全システム再構成という、より大がかりな作業の締めくくりにこそ、いっそう強く当てはまる。柱3、**再検定**は、建て直した全体が本当に正しく動いているかを、機械的に、かつ独立した立場から確かめる作業である。
### 検査系不動点原則 — 誰が検定するかを、誰が検定されるかから切り離す
再検定という作業を成立させる土台に、**検査系不動点原則**という考え方がある。これは、検定を行う仕組みそのものが、検定される対象の内部から自己完結してしまわないよう、検証の核を常に系の外側に置く、という原則である。本プロジェクトでは、この原則を体現する複数の考え方が、実際の道具として実装されている。
まず、**検定の鍵分離**(FUNC-1100・test oracle separation from implementation)は、検定の合否を判定する基準(オラクル)を、検定される実装そのものから切り離して持つ、という考え方である。実装した担当者自身が「これで正しいはずだ」と自己申告するだけでは、検定として成立しない。第4巻第八章で紹介したFUNC-0278番のカードの一件でも、修補が本当に効いているかどうかを、発見した担当者とは別の担当者が独立に再実測する、という手順が踏まれていた。この「別の担当者による確認」を仕組みとして支えるのが、**独立再実行検証**(FUNC-0774・independent re-execution verification)という考え方である。
再検定ではまた、システム全体の帳尻が崩れていないかを確かめる**保存則検査**(FUNC-0769・conservation law check)、境界の作り直しで新しく割り当てた参照関係に不備がないかを確かめる**参照先存在検査**(FUNC-0953・reference target existence check)、複数の担当者が並行して境界の作り直しを行った場合に生じうる**ID重複検出**(FUNC-0958・duplicate ID detection)といった機械検査も、あわせて実行する。これらはいずれも、担当者の目視や記憶に頼らず、機械的に、かつ網羅的に確かめられるという共通の性質を持っている。
### 実例 — 構造層と挙動層、二段構えの再検定
第4巻第六章で紹介した`tools/check_funcdict_langs.js`が持つ構造層(外部への依存を持たず、約1秒程度で全件を検査できる、燃費0の網羅チェック)と挙動層(実際にコードを実行させて言語間の出力を突き合わせる、対象言語が実行環境に依存する検査)という二層構造は、再検定の場面でもそのまま使える型である。第四章で示した時間割のとおり、まず構造層で全件を素早く網羅的に検査し、次に挙動層で、実行して基準線と突き合わせる、より手間のかかる検査を行う。
さらに、台帳全体の完全性を検査する`tools/check_conservation.js`、そして番号帯の整合を監査する`tools/gen_ledger_audit.js`(NUMBER_REGISTRY.mdとディスク実体の突合を、読み取り専用・約1秒で実行する道具)といった、このプロジェクトに実在する複数の検査器が、再検定の具体的な手段として使われている。
### コラム — 架空のID引用が、再検定そのものを汚す
再検定という作業には、もう一つ見落とされがちな落とし穴がある。検定の記録の中で、実在しないID(たとえば、実際には`outputs/func_dict_index.json`の`byId`に存在しない番号)を、あたかも実在するかのように引用してしまうことである。仮に「悪い引用例」として存在しないFUNC番号を示したい場合であっても、実在ID形式(`FUNC-`に続けて数字4桁)にそのまま一致してしまう表記を使ってしまうと、後日、全巻を横断してID参照の整合性を検査する監査の際に、誤検出(偽陽性)を引き起こす。本書では、そうした架空の例を示す必要がある場合、`FUNC-XXXX(架空・存在しない番号の例)`のように、数字4桁パターンには一致しない表記を用いる。この配慮そのものが、実は本章が扱う参照先存在検査という考え方の、最も身近な実践例になっている——検定記録に書かれたID参照は、常に実在確認が取れて初めて、信頼してよい記録になる。
### コラム — 「緑」への昇格条件を、あらかじめ決めておく
再検定を通じて「緑」の状態へ復帰させるかどうかは、その場の空気で決めるべきものではない。このプロジェクトの運用では、資産の種類ごとに、あらかじめ緑昇格の既定条件を定めておく、という考え方が採られている。たとえば、読み物として作られた資産であれば読者による通読と再構築の確認を、検定として作られた資産であれば抜き取り検定と是正の完了、鍵漏洩がないことの確認を、それぞれ緑昇格の条件として先に決めておく。全システム再構成の場面でも同様に、「何を満たせば緑と呼んでよいか」を、再検定に着手する前に明文化しておくことが、担当者の主観に左右されない再検定を支える。あらかじめ条件を決めておかず、検定の途中で基準を緩めてしまうと、それは第4巻第八章で扱った「緑を騙る赤」を、今度は制度の側から作り出す行為に等しくなる。
### 点検9 — 再検定として十分かどうかの判定
次の2つの再検定の進め方を比べてみよう。
```
進め方甲: 境界の作り直しを担当した本人が、動作を目視で確認し、
「問題なさそうだ」と判断して復帰を決めた。
進め方乙: 境界の作り直しを担当していない別の担当者が、構造層の
網羅チェックと挙動層の実行確認の両方を独立に実行し、
保存則検査・参照先存在検査を含めて、基準線との一致を
機械的に確認したうえで復帰を承認した。
```
進め方甲は、検定の鍵分離が成立しておらず、担当者自身の目視判断に依存している。進め方乙は、鍵分離・独立再実行検証・保存則検査・参照先存在検査という複数の機械的な裏付けを備えており、本章が求める再検定の水準を満たしている(点検成立)。
---
> **定着量の目安(第九章)**: 「検定の鍵分離」と「独立再実行検証」という2つの言葉を、自分の言葉で説明できるようにしておく。あわせて、「架空のIDを実在ID形式で書いてはいけない理由」を、参照先存在検査という考え方と結びつけて説明できるようにしておくと、この章の核心が定着しやすい。
---
## 第十章: 再構成後の監査証跡と制度への接続(水準十)
### 再検定の記録は、それ自体が資産になる
第九章で確認した再検定の作業は、ただ「合格した」という結果だけを残すのでは不十分である。誰が、いつ、どの経路で、何を基準に確認したのかという過程そのものを記録に残すことで、初めてその再検定は、後から検証可能な**監査証跡**になる。この記録には、**監査ログ記録**(FUNC-0399・audit log)の考え方が使われる。誰が・いつ・何を行ったかを構造化して記録しておくことは、再構成が完了した直後だけでなく、その後しばらく経ってから「あのとき本当に正しく再構成されたのか」を問われた場合にも、根拠を示せる備えになる。
再構成の過程で新しく割り当てたID(境界の作り直しで発行し直したアカウントや資産の番号)についても、番号帯そのものが崩れていないかを確かめる**台帳番号帯監査**(FUNC-0777・ledger ID-band audit)の考え方が有効である。第九章のコラムで扱った「架空のID引用」の問題は、実は検定記録だけでなく、再構成後に新しく発行するIDの採番にもそのまま当てはまる。新しいIDが、既存の番号帯と衝突していないか、飛び番や重複がないかを機械的に確認しておくことが、後々の監査を軽くする。
### 制度側との接続 — 本書は法的助言ではない
再構成が完了し、監査証跡が整ったら、その記録は→BOOK-0368『監査・統制とコンプライアンス』が扱う、より広い制度の文脈に接続される。規制業種であれば、システムの停止や再構成そのものが、監督当局への報告対象になる場合もある。ここで本書は誇張なく明記しておく——本書、および本シリーズ全体は、監査・コンプライアンスの型を扱う教材であり、特定の法的助言ではない。実際の規制対応は、有資格の専門家や監督当局の最新の指針に従う必要がある。
### 点検10 — 監査証跡として十分かどうかの判定
次の2つの記録を比べてみよう。
```
記録A: 「再構成が完了し、正常に動作していることを確認した」という
1行の報告だけが残されている。
記録B: 誰が基準線を確保し、誰がバイト同一移植を実行し、誰が境界を
作り直し、誰がどの経路で再検定を独立に実行したかが、
時系列に沿って構造化して記録されている。
```
記録Aは、結果だけが記されており、後から「本当に正しい手順を踏んだのか」を検証する手がかりがない。記録Bは、監査ログ記録の考え方に沿って過程が構造化されており、本章が求める監査証跡の水準を満たしている(点検成立)。
### コラム — 番号帯監査を、この本自身にも適用する
第九章のコラムで扱った「架空のID引用」の問題は、実は本書自身の執筆過程でも、実際に警戒すべき対象だった。本書がFUNC-IDを引用する際は、`outputs/func_dict_index.json`の`byId`に実在することを1件ずつ確認したうえで引用している。この手順そのものが、台帳番号帯監査(FUNC-0777)という考え方を、書籍という資産の執筆工程に適用した一例になっている。監査証跡を残すという営みは、再構成が終わった後の成果物だけでなく、その記録を書き記す執筆や報告そのものにも、同じ厳密さで及ぶべきだ、という点を、この場を借りて明記しておく。
### コラム — ポストモーテムとの接続
第4巻第十一章で紹介したポストモーテム(非難を目的とせず、何が起きたか・なぜ気づくのが遅れたか・何が功を奏したか・次に何を変えるかを時系列に沿って記録する報告の型)は、全システム再構成という重い決断の後にこそ、いっそう丁寧に行う価値がある。一日という時間をかけて再構成したという事実そのものが、次にどんな準備を厚くすべきかという、極めて具体的な教訓の宝庫になる。
---
> **定着量の目安(第十章)**: 「結果だけの記録」と「過程が構造化された監査証跡」の違いを、自分の言葉で説明できるようにしておく。
---
## 第十一章: 段階判断そのものを設計する — 部分修復か、全システム再構成か(水準十一)
### 本書の核心 — 「いつ踏み切るか」を体系化する
ここまでの十章で、全システム再構成という手段そのものの中身(三本柱と、その一つひとつの実務)を丁寧に確かめてきた。しかし、実務で本当に難しいのは、多くの場合、技法そのものよりも「この事態は、部分修復で足りるのか、それとも全システム再構成に踏み切るべきなのか」という、最初の一歩の決断である。本章では、この段階判断そのものを、思いつきではなく体系立てて扱う。
### 段階判断を導く四つの信号
実務でこの決断を支える手がかりとして、次の四つの信号が有効である。いずれか一つでも強く当てはまる場合、部分修復から全システム再構成への切り替えを検討すべき局面にある。
```
信号1: 基準線の唯一性喪失 — 疑いのない正常な状態を示す記録・複製が
1か所しか残っておらず、かつその1か所の信頼性にも疑いが
生じている(第五章)
信号2: 境界の特定不能 — 参照先存在検査などの機械的な手がかりを
用いても、汚染の疑いがある範囲の外縁を確信を持って
線引きできない(第七章)
信号3: 「緑を騙る赤」の複数箇所での再発 — 検定記録上は合格している
資産の中から、実際には欠陥を抱えていた事例が、単発ではなく
複数箇所で見つかっている(第4巻第八章)
信号4: 権限系統の根への疑い — 汚染の疑いが、末端のアカウントではなく、
他の権限を発行し直す立場にある、権限系統の根に近い部分にまで
及んでいる疑いがある(第八章)
```
これら四つの信号は、いずれも「疑わしい範囲を、確信を持って絞り込めない」という共通の性質を持っている。逆に言えば、基準線が確実に残っており、境界が明確に線引きでき、「緑を騙る赤」が単発の事例にとどまり、権限系統の根が汚染されていないと確認できるなら、多くの場合は部分修復で対応できる。
### 点検11 — 信号を読み取り、段階判断を下す
次の事態を点検してみよう。「管理者権限を発行する立場にあったアカウント自体が、いつから汚染されていたか特定できず、そのアカウントが発行した他のアカウントの権限にも疑いが及んでいる。バックアップは1世代分しか残っていない」。
この事態には、信号1(基準線が1世代分しか残っておらず唯一性を欠く)と信号4(権限系統の根への疑い)が、同時に強く当てはまっている。この場合、部分修復——疑わしいアカウントを1つずつ確認して直す——というやり方では、「本当にすべての汚染箇所を洗い出せたのか」を誰も保証できない。この事態は、本書が扱う全システム再構成に踏み切るべき典型例である(点検成立)。
### コラム — 段階判断は、一人に背負わせない
四つの信号を使えば機械的に答えが出る、というわけではない。最終的な決断には、判断を下す人の経験と、第4巻第十二章で扱った体制(指揮役・実行役・記録役・連絡役)が欠かせない。特に、システムを一日止めるという重い決断を、指揮役一人だけの独断に背負わせてしまうと、判断が遅れたり、逆に過剰に慎重になりすぎたりする危険がある。四つの信号を、あらかじめ卓上演習(第4巻第十二章)で確認しておき、実際の事態でどの信号が当てはまるかを、記録役が同時進行で記録しながら、指揮役が最終判断を下す、という体制を整えておくことが、この判断の質を支える。
### 実例 — 四つの信号を、実際の判断の場でどう使うか
四つの信号は、紙の上の分類表として眺めるだけでは実務に活きない。実際の運用では、指揮役が信号の該当・非該当を1つずつ声に出して確認し、記録役がその場で記録していく、という形を取ることが多い。「基準線は何世代残っているか」「境界の外縁は、参照先存在検査でどこまで絞り込めたか」「緑を騙る赤は、今回1件だけか、それとも複数箇所か」「汚染の疑いは、権限を発行する側のアカウントにまで及んでいるか」——この4つの問いに、指揮役と実行役が具体的な数字や事実で答えられる状態にあること自体が、段階判断の質を底上げする。逆に、いずれかの問いに「わからない」としか答えられない場合、それはその項目についてさらに調査が必要である、という意味であり、無理に部分修復か全システム再構成かを即断すべきではない。
### よくある誤解 — 「信号が1つでもあれば、必ず再構成すべき」という誤解
四つの信号のうち1つでも当てはまれば機械的に全システム再構成へ切り替えるべきだ、と読み違えてはいけない。信号は、あくまで「疑うべき度合いが高まっている」という手がかりであり、絶対の基準ではない。信号が弱く当てはまる場合でも、境界二層戦略による絞り込みが功を奏し、部分修復で対応しきれることもある。本書が誇張なく伝えたいのは、「これらの信号が強く、複数重なるほど、全システム再構成という重い手段を検討する根拠が強まる」ということであり、機械的な二択の判定表ではない、という点である。
---
> **定着量の目安(第十一章)**: 四つの信号(基準線の唯一性喪失・境界の特定不能・「緑を騙る赤」の複数箇所での再発・権限系統の根への疑い)を、何も見ずに書き出せるようにしておく。身の回りの小さなトラブルに当てはめて、「これは1つ直せば済むか、根本から見直すべきか」を判断する練習をすると、段階判断の感覚が定着しやすい。
---
## 第十二章: 本シリーズの束ね — 読了系統と最終判断(水準十二・講師級)
### 全12巻が、一つの判断のために積み上げられている
ここまでの十一章は、本書単独でも一つの実務書として成立するが、本書は同時に、情報防衛と復旧シリーズ全12巻の最終巻でもある。この最終章では、講師の視点から一歩引いて、シリーズ全体がどのように積み上げられ、本書が扱う「一日停止・全システム再構成の段階判断」という、最も重い決断へとどう収束していくのかを俯瞰する。
まず、本書の執筆にあたり`gakumon/`を実地に確認したところ、シリーズの刊行状況は次のとおりである(2026年時点、本書の検定を確定させた時点でのスナップショット)。第1巻から第10巻までは、本文・検定(quiz/answers)ともに実際のファイルとして刊行が確認できた。第11巻(BOOK-0370)は本文の刊行は確認できたが、検定一式の刊行は、確認した時点ではまだ見つからなかった。この確認作業そのものが示しているのは、本書が繰り返し強調してきた「検定記録は、実在確認が取れて初めて信頼してよい」という原則である——確認できていないものを確認できたかのように書かず、また確認できたものを確認できていないかのように古いまま書き残しもしない、という姿勢を、この最終章でも一貫させる。
```
本文・検定とも刊行確認済み(全10巻・gakumon/実地確認済み):
第1巻 BOOK-0360 情報セキュリティ総論
第2巻 BOOK-0361 認証認可とアクセス制御
第3巻 BOOK-0362 脆弱性の防御的理解と対策
第4巻 BOOK-0363 インシデント対応の一本道
第5巻 BOOK-0364 フォレンジクスとログ解析
第6巻 BOOK-0365 バックアップと災害復旧
第7巻 BOOK-0366 可用性と信頼性工学
第8巻 BOOK-0367 監視と観測可能性
第9巻 BOOK-0368 監査と統制とコンプライアンス
第10巻 BOOK-0369 鍵管理とPKIの実務
本文のみ刊行確認済み(検定は本書確認時点で未確認):
第11巻 BOOK-0370 ネットワーク防御の設計
最終巻(本書):
第12巻 BOOK-0371 セキュアな再構成の実務
```
### 読了系統 — 全巻がどの順で、どの段階を担うか
CATALOG_情報防衛と復旧シリーズ.md §1が定める読了系統は、次のとおりである。
```
1(土台) → 2・3・10・11(予防) → 8(検知の前提) → 5(判定)
→ 4(対応の背骨) → 6・7・12(復旧と再構成) → 9(制度で締める)
```
この系統を、各巻の担う段階とあわせて、あらためて一覧にする。
```
土台 : 第1巻(BOOK-0360)— CIA三要素・脅威モデル・多層防御という、
全巻が前提にする共通言語を用意する
予防 : 第2巻(BOOK-0361・認証認可)/第3巻(BOOK-0362・脆弱性の
防御的理解)/第10巻(BOOK-0369・鍵管理・本文検定とも刊行済み)/
第11巻(BOOK-0370・ネットワーク防御・本文は刊行済み、
検定は本書確認時点で未確認)
— 事態が起きる確率とコストを上げ、そもそも再構成が
要らない状態を目指す層
検知の前提: 第8巻(BOOK-0367・監視と観測可能性)
— 気づくための下敷き(ログ・メトリクス・トレース)を用意する
判定 : 第5巻(BOOK-0364・フォレンジクスとログ解析)
— 何が起きたか、いつから起きたかを、タイムラインと
改竄検知によって確定する
対応の背骨: 第4巻(BOOK-0363・インシデント対応の一本道)
— 準備→検知→封じ込め→根絶→復旧→教訓という六段階を、
一日という制約の中に配分する
復旧と再構成: 第6巻(BOOK-0365・バックアップと災害復旧)/
第7巻(BOOK-0366・可用性・信頼性工学)/
第12巻(本書・セキュアな再構成の実務)
— 基準線を確保し、冗長化・段階的縮退で持ちこたえ、
それでも足りない場合に丸ごと建て直す
制度で締める: 第9巻(BOOK-0368・監査・統制とコンプライアンス)
— 一連の対応と再構成の記録を、組織の制度と監督当局への
説明責任へと接続する
```
### なぜ、この順で束ねると「最終判断」に至るのか
この読了系統を俯瞰すると、一つの構造が浮かび上がる。土台(第1巻)の上に、予防(第2・3・10・11巻)という厚い層が積まれ、それでも事態は起き得るという前提のもと、検知の前提(第8巻)が気づくための下敷きを整え、判定(第5巻)が「何が起きたか」を確定し、対応の背骨(第4巻)が六段階の一本道を歩む。そして、対応の背骨が「封じ込めと根絶だけでは足りない」と判断した場面で、復旧と再構成(第6・7・12巻)が引き継ぐ。第6巻が基準線そのものの作り方を、第7巻が冗長化によって再構成に踏み切らずに済ませる備えを、そして本書(第12巻)が、それでも再構成が避けられない場面での、最も重い決断の体系を担う。最後に、制度で締める(第9巻)が、この一連の判断と行動を、組織の外側への説明責任へと接続する。
この構造が示しているのは、本書第十一章で扱った「段階判断そのものを設計する」という営みが、実は本書単独の話ではなく、シリーズ全12巻の総体そのものだ、という事実である。第十一章の四つの信号(基準線の唯一性喪失・境界の特定不能・「緑を騙る赤」の複数箇所での再発・権限系統の根への疑い)は、いずれも、予防・検知・判定・対応という手前の層が、それぞれの持ち場でどこまで踏ん張れたかによって、強まったり弱まったりする。予防の層が厚く、検知が早く、判定が正確で、対応が手順どおりであれば、全システム再構成という最終防波堤の出番そのものが減る。逆に、手前の層のどこかが薄ければ、四つの信号は強く重なり、最終防波堤の出番が増える。
### 点検12 — シリーズ全体の構造を俯瞰する
次の問いに答えてみよう。「予防の層(第2・3・10・11巻)と、本書(第12巻)は、どのような関係にあるか」。予防の層は、事態が起きる確率とコストを上げることで、本書が扱う全システム再構成という最も重い手段の出番そのものを減らす役割を担っている。両者は対立する関係ではなく、予防の層が厚いほど、本書の技法を実際に使う機会は減り、それでも使わざるを得ない場面では、予防の層で培われた最小権限・鍵管理・ネットワーク区画の考え方が、境界の作り直し(第八章)にそのまま再利用される、という補い合う関係にある(点検成立)。
### 講師からの最後の一言 — 「緑」は、いつも仮の状態である
本シリーズを通じて繰り返し登場した「緑を騙る赤」という言葉に、最後にもう一度立ち返っておきたい。白・黄・緑という検定文化の一方向ラチェットは、「緑になれば、もう二度と疑わなくてよい」ということを意味しない。緑とは、「今、確認できる範囲では、機械的な検査に合格している」という、あくまで仮の、しかし確かな根拠を伴った状態である。本書が扱ってきたバイト同一移植・境界の作り直し・再検定という三本柱もまた、一度実行すれば未来永劫安全が保証されるという魔法の手順ではない。予防・検知・判定・対応・復旧・再構成という全12巻の一本道を、必要になるたびに、また一から丁寧に歩き直す——その地道な繰り返しこそが、情報を扱う仕事における、誇張のない、しかし確かな備えである。
---
> **定着量の目安(第十二章)**: 本シリーズ12巻の担当段階(土台/予防/検知の前提/判定/対応の背骨/復旧と再構成/制度で締める)を、何も見ずに書き出せるようにしておく。あわせて、自分の身の回りにある仕組み(家庭・学校・職場)で、予防・検知・対応・再構成のそれぞれに当たる備えが実際にあるかどうかを1つずつ探してみる練習をすると、シリーズ全体の構造が実感として定着しやすい。
---
## 三つの実践解(§16.21) — 紙とペン、そして自分の端末の標準機能でできる実践
理論を、実際に手を動かして確かめる方法を三つ紹介する。いずれも特別な工具や外部サービスを必要とせず、紙とペン、あるいは自分の端末に最初から入っている標準機能だけで完結する、安全な実践解である。攻撃的な操作は一切含まない。
1. **ハッシュ値を確認する実践**: 多くのOSには、ファイルのハッシュ値(内容から計算される、内容が1バイトでも変わると別の値になる符号)を計算する標準機能が用意されている(具体的な操作手順は各OSの説明に従う)。同じファイルを2か所に複製し、両方のハッシュ値を計算して一致することを確認してみる。これは第六章で扱ったバイト同一移植の合否判定を、自分の端末で先取りして体験する練習になる。
2. **保存先の分散を点検する実践**: 自分にとって大切なファイルが、実際に何か所の独立した保存先に分散しているかを数えてみる。パソコン本体・外部媒体・クラウドサービスなど、最低2種類以上の異なる経路に同じデータがあるかどうかを確かめる。これは第五章で扱った単一障害点を作らない基準線確保の考え方を、自分の身の回りで体験する練習になる。
3. **段階判断の卓上演習を紙の上でやってみる実践**: 第十一章で紹介した四つの信号(基準線の唯一性喪失・境界の特定不能・「緑を騙る赤」の複数箇所での再発・権限系統の根への疑い)を紙に書き出し、架空の事態を1つ設定して、それぞれの信号が当てはまるかどうかを○×で点検してみる。信号がいくつ当てはまれば、自分なら部分修復と全システム再構成のどちらを選ぶかを、理由とともに書き添えてみる。
---
## まとめ — 「もう一度、緑から始める」ための一本道
本書では、部分修復では追いつかなくなる事態——基準線喪失と境界不明という二つの引き金——から出発し(第一章)、バイト同一移植・境界の作り直し・再検定という三本柱を定義し(第二章)、この三本柱が防御の系譜の中で最終防波堤に位置することを確かめた(第三章)。続いて、一日という制約の中に三本柱をどう配分するかという時間軸の設計を深掘りし(第四章)、基準線の確保と検証(第五章)、バイト同一移植の実務(第六章)、境界の特定と隔離(第七章)、境界の作り直し(第八章)を、それぞれ実在の記録や道具と結びつけながら扱った。そのうえで、検査系不動点原則に基づく再検定(第九章)、監査証跡と制度への接続(第十章)、部分修復と全システム再構成のどちらを選ぶかという段階判断そのものの設計(第十一章)を経て、最後に、本シリーズ全12巻がどう束ねられて、この最終判断に至るのかを俯瞰した(第十二章)。
「動いているように見える」ことと「本当に正しく動いている」ことは別の話である、という第4巻の一文は、本書でも一貫して生きている。バイト同一移植は目視でなくハッシュ値で確認し、境界の作り直しは引き継ぎでなくゼロからの設計で行い、再検定は自己申告でなく独立した鍵分離のもとで行う。三本柱のすべてに共通するのは、「見た目の安心」を機械的な根拠に置き換える、という一貫した態度である。
本シリーズは、これで全12巻の一本道を歩き終える。土台から予防、検知から判定、対応から復旧と再構成、そして制度で締める——この道のりのどこか一歩でも欠ければ、次に事態が起きたとき、また一から手探りで対応することになる。この一本道を体系立てて手にしておくことこそが、「一日停止・全システム再構成」という最も重い決断を、恐れながらではなく、落ち着いて、正しい順序で下すための、本シリーズ最大の値札である。
---
## 章末: 三本柱と読了系統のまとめ図
まず、第四章で扱った一日再構成の時間配分を、三本柱に沿ってあらためて帯グラフの形で見てみよう。
```
0h 2h 6h 8h 14h 18h 20h 23h 24h
├判定─┼─封じ込め─┼基準線┼─バイト同一移植──┼境界の作り┼構造層┼─挙動層──┼最終┤
(前提) (前提) 確保 (第六章) 直し(第八章) 再検定 再検定(第九章) 承認
(第五章) (第九章) (第十章)
```
続いて、本書全体の歩みを階段図としてまとめる。
```
[水準十二] 本シリーズの束ね
読了系統/全12巻がどう最終判断に収束するか(点検12)
▲
│ 予防が厚いほど、最終防波堤の出番は減る
[水準十一] 段階判断そのものの設計
四つの信号/部分修復か全システム再構成か(点検11)
▲
│ 技法より先に、踏み切るかどうかの判断が要る
[水準十] 監査証跡と制度への接続
監査ログ記録/台帳番号帯監査(点検10)
▲
│ 記録が、後から検証可能な資産になる
[水準九] 再検定
検査系不動点原則/鍵分離・独立再実行検証(点検9)
▲
│ 建て直したことと、合格したことは別の話
[水準八] 境界の作り直し
引き継がず、ゼロから設計し直す(点検8)
▲
│ 疑わしい部分だけを、信頼できない前提で建て直す
[水準七] 境界の特定と隔離
境界二層戦略の応用/quarantined(点検7)
▲
│ 疑う範囲を、機械的な手がかりで絞り込む
[水準六] バイト同一移植の実務
ハッシュ値照合/VMマウント剥離事故の実例(点検6)
▲
│ 複製は単純な操作に徹する
[水準五] 基準線の確保と検証
単一障害点を作らない/保存則検査(点検5)
▲
│ 土台そのものの信頼性を、複数経路で確かめる
[水準四] 時間軸の設計(深掘り)
6区分の時間割/基準線確保からの積み上げ(点検4)
▲
│ 三本柱を、一日という制約の中に配分する
[水準三] 防御の系譜の中の位置づけ
最終防波堤(点検3)
▲
│ 予防・検知・対応が機能しなかった最後の層
[水準二] 再構成の三本柱
バイト同一移植/境界の作り直し/再検定(点検2)
▲
│ 順番に積み上がる、3つの柱
[水準一] なぜ再構成が必要になる事態が起きるか
基準線喪失/境界不明という二つの引き金(点検1)
横の広がり:
[水準五] 基準線確保 ←(同じ構造)→ [水準六] VMマウント越しの経路確認
[水準七] 境界の絞り込み ←(境界二層戦略で連結)→ [水準四] 判定の絞り込み
[水準九] 検定の鍵分離 ←(同じ原則)→ [水準十] 監査証跡の第三者検証可能性
現在のフロンティア(第六章・第九章):
2026年7月3日 VMマウントのキャッシュ剥離事故が実証され、
「正の経路を確認してから読み書きする」レシピが確立される
2026年 本プロジェクト内でFUNC-0278の「緑を騙る赤」の教訓が
このシリーズ全体の色運用の出発点になる
※本書で扱った三本柱・段階判断の四つの信号は、未解決の謎ではなく、
現在進行形で実務に使われ続けている現役の設計原理という意味での
フロンティアである。
本書はシリーズ最終巻。次の一歩は、読者自身の現場で、
基準線を複数経路で確保しておくことから始まる。 ─────▶
```
---
## 参照文献(定番指針・一般規格・本プロジェクトの実在記録)
1. アメリカ国立標準技術研究所(NIST)による『コンピュータセキュリティインシデント対応ガイド』(NIST SP 800-61)系列。本書が扱う再構成は、この指針が示す「復旧」局面の、より重い一形態として位置づけられる(→第4巻BOOK-0363も参照)。
2. 本プロジェクトの実在記録: `CLAUDE.md`「独自ルーティンマクロ」節(2026年7月3日のVMマウントキャッシュ剥離事故の実証記録と、確立されたバイト同一移植レシピ)。
3. 本プロジェクトの実在記録: `gakumon/NUMBER_REGISTRY.md`(FUNC-0278「緑を騙る赤」の発見と修補の記録、セッション上限事故〈ULTRA-28〉のディスク実地棚卸しと回収の記録)。
4. 本プロジェクトの実在実装: `tools/check_conservation.js`(保存則監査器)、`tools/check_funcdict_langs.js`(構造層・挙動層の二層構造を持つ定期チェッカー)、`tools/gen_ledger_audit.js`(台帳とディスク実体の突合を読み取り専用で行う監査器)。
5. 本プロジェクトの設計書: `gakumon/CATALOG_情報防衛と復旧シリーズ.md`(本シリーズ全12巻の部構成表・読了系統・安全枠の正)。
6. 総関数辞書の意味素カード: `outputs/func_dict_index.json`の`byId`に実在確認済みのFUNC-0769(保存則検査)・FUNC-0774(独立再実行検証)・FUNC-1100(検定の鍵分離)・FUNC-0953(参照先存在検査)・FUNC-0958(ID重複検出)・FUNC-0643(決定的再計算検証)・FUNC-0644(最終状態ハッシュ照合)・FUNC-1146(スナップショット突合状態復元検証)・FUNC-0399(監査ログ記録)・FUNC-0777(台帳番号帯監査)。
---
（本冊子は情報防衛と復旧シリーズ BOOK-0371。全12巻中の第12巻(セキュアな再構成の実務)であり、シリーズの最終巻・締めくくりに当たる。第4巻BOOK-0363が予告にとどめた「バイト同一移植」の詳しい手順、第6巻BOOK-0365が扱う基準線の作り方、第9巻BOOK-0368が扱う制度への接続を、本書が「再検定」という最後の段階として一本にまとめた。本書の執筆過程でBOOK-0369(鍵管理とPKIの実務・本文検定とも刊行確認済み)・BOOK-0370(ネットワーク防御の設計・本文は刊行確認済み、検定は本書確認時点で未確認)の刊行が進んだことも確認しており、本書第八章の境界の作り直しに関する記述は、両巻の本文とすでに接続されている。CATALOG_情報防衛と復旧シリーズ.md・GAKUMON_UNIVERSE.md 進捗台帳を参照。）
# BOOK-0371 情報防衛と復旧シリーズ 第12巻(最終巻): セキュアな再構成の実務 — 「もう一度、緑から始める」ための段階判断