※小説ではない※専門書 要約資料集 為替(換算)3.9万円でもらう 紐解集生成 専門 初入門 資料

# BOOK-0364 情報防衛と復旧シリーズ 第5巻: フォレンジクスとログ解析 — 何が、いつ、どう壊れたかを、証拠から確定する

※物語はフィクションです　※
※即時通報案件は専門家にご通報ください※
※お手数ですが疑問点は各分野でご確認いただけましたら幸いです※


# BOOK-0364 情報防衛と復旧シリーズ 第5巻: フォレンジクスとログ解析 — 何が、いつ、どう壊れたかを、証拠から確定する

> 情報防衛と復旧シリーズ(全12巻・BOOK-0360〜0371・設計書=CATALOG_情報防衛と復旧シリーズ.md)第5巻。ガイド役: Fable 5 監修 / Sonnet 5 執筆(脚本班)
> トーン規約: GAKUMON_UNIVERSE.md準拠。専門用語は初出で必ず説明する。
> **値札**: 「一日停止・全システム再構成の段階判断」という特命業務のうち、本巻が担うのは**判定**の段階——何が、いつ、どのように壊れたのかを、証拠にもとづいて確定する仕事——である。憶測ではなく、記録と検算で語れる状態まで持っていく一冊。
> **安全枠(§16.18・本巻での適用範囲・最重要)**: 本巻は防御・検知・証拠保全・教育に限定する。実在システムへの侵入手順・動作するエクスプロイト・攻撃の再現コード・**痕跡消去やアンチフォレンジクスの実行手順**は一切書かない。アンチフォレンジクスという行為の**存在**には防御的な観点から言及するが、その実行方法は記載しない。脆弱性や攻撃は「何が起きるか(仕組み)・どう防ぐか・どう検知するか」の防御的視点でのみ扱う(IMPORTANT: authorized security testing/defensive securityの枠内)。「これを読めば絶対に改竄を見抜ける」といった誇張はしない——多層の検証は見逃しの確率を下げるが、ゼロにはしない、という正直な水準で書く。
> 接続先: →BOOK-0359b/d『保存則監査・生成器検定』(本巻第五章・第六章で一般化する保存則検査とFUNC-0278事件の検定文化は、そちらの実装が先行事例)、→BOOK-0360『情報セキュリティ総論』(全巻の土台。本巻はその上に立つ)、→BOOK-0363『インシデント対応の一本道』(次巻。本巻の判定結果を受け取り、封じ込め→根絶→復旧→教訓という一本道につなげる)、→BOOK-0367『監視と観測可能性』(本巻第三章で扱うログそのものの設計・収集基盤はそちらが引き継ぐ)、→BOOK-0368『監査・統制とコンプライアンス』(本巻第七章の証拠の連鎖は、そちらの制度側の要請と対になる)。
> 水準: 一〜十二(証拠とは何か・揮発性の順序という土台から、証拠保全、ログの種類と読み方、タイムライン再構成、改竄検知の一般化、「緑を騙る赤」の発見法、証拠の連鎖、相関分析、フォレンジクス体制と証跡設計の実務までを扱う。初心者→熟練者→上級専門家→講師級の四段は、おおむね第一〜三章/第四〜六章/第七〜八章/第九章に対応する)。

---

---

# BOOK-0364 情報防衛と復旧シリーズ 第5巻: フォレンジクスとログ解析 — 何が、いつ、どう壊れたかを、証拠から確定する

> 情報防衛と復旧シリーズ(全12巻・BOOK-0360〜0371・設計書=CATALOG_情報防衛と復旧シリーズ.md)第5巻。ガイド役: Fable 5 監修 / Sonnet 5 執筆(脚本班)

> トーン規約: GAKUMON_UNIVERSE.md準拠。専門用語は初出で必ず説明する。

> **値札**: 「一日停止・全システム再構成の段階判断」という特命業務のうち、本巻が担うのは**判定**の段階——何が、いつ、どのように壊れたのかを、証拠にもとづいて確定する仕事——である。憶測ではなく、記録と検算で語れる状態まで持っていく一冊。

> **安全枠(§16.18・本巻での適用範囲・最重要)**: 本巻は防御・検知・証拠保全・教育に限定する。実在システムへの侵入手順・動作するエクスプロイト・攻撃の再現コード・**痕跡消去やアンチフォレンジクスの実行手順**は一切書かない。アンチフォレンジクスという行為の**存在**には防御的な観点から言及するが、その実行方法は記載しない。脆弱性や攻撃は「何が起きるか(仕組み)・どう防ぐか・どう検知するか」の防御的視点でのみ扱う(IMPORTANT: authorized security testing/defensive securityの枠内)。「これを読めば絶対に改竄を見抜ける」といった誇張はしない——多層の検証は見逃しの確率を下げるが、ゼロにはしない、という正直な水準で書く。

> 接続先: →BOOK-0359b/d『保存則監査・生成器検定』(本巻第五章・第六章で一般化する保存則検査とFUNC-0278事件の検定文化は、そちらの実装が先行事例)、→BOOK-0360『情報セキュリティ総論』(全巻の土台。本巻はその上に立つ)、→BOOK-0363『インシデント対応の一本道』(次巻。本巻の判定結果を受け取り、封じ込め→根絶→復旧→教訓という一本道につなげる)、→BOOK-0367『監視と観測可能性』(本巻第三章で扱うログそのものの設計・収集基盤はそちらが引き継ぐ)、→BOOK-0368『監査・統制とコンプライアンス』(本巻第七章の証拠の連鎖は、そちらの制度側の要請と対になる)。

> 水準: 一〜十二(証拠とは何か・揮発性の順序という土台から、証拠保全、ログの種類と読み方、タイムライン再構成、改竄検知の一般化、「緑を騙る赤」の発見法、証拠の連鎖、相関分析、フォレンジクス体制と証跡設計の実務までを扱う。初心者→熟練者→上級専門家→講師級の四段は、おおむね第一〜三章/第四〜六章/第七〜八章/第九章に対応する)。

---

## 入口の物語 — 深夜3時、在庫管理システムが止まった

深夜3時、社内の在庫管理システムが突然応答を止めた。当直担当者があわてて再起動すると、システムは動き出したものの、朝になって確認すると一部の在庫データの数字が明らかにおかしい。多すぎる品目もあれば、少なすぎる品目もある。経営陣からは「今日一日、全システムを止めてでも原因を突き止めて直せ」という指示が下り、あなたのところに「判定」の仕事が回ってきた。

ここで最初にやってはいけないことがある。それは、原因をつきとめようと焦って、サーバーにあれこれログインし、ファイルを開き、設定を変え、プロセスを再起動して回ることである。良かれと思ってやったその一つひとつの操作が、実は原因究明の手がかりそのものを踏みつぶしてしまうかもしれない。犯人を捜す前に、まず現場を保存する——これが、本巻を貫く一番大きな教訓である。

デジタルの世界における「現場」とは、メモリの中身であり、実行中のプロセスの一覧であり、様々な種類のログファイルであり、ファイルのタイムスタンプである。これらは、紙の書類のように黙ってそこに留まっていてはくれない。電源を切れば消えるものがあり、次の書き込みで上書きされるものがあり、放っておけばローテーション(古い記録を捨てて新しい記録に入れ替える運用)で自動的に消えていくものもある。「何が、いつ、どう壊れたか」を語るためには、まずこの消えやすい証拠を、消えてしまう前に、正しい順序で、正しいやり方で確保しなければならない。

本巻は、この「判定」という仕事を、思いつきや勘に頼らず、誰が読んでも同じ結論にたどり着ける形で行うための技術を、一歩ずつ積み上げていく。証拠とは何か、どの順番で確保すべきか(第一章)。確保した証拠をどう改変せずに固定するか(第二章)。ログという記録をどう読むか(第三章)。複数のログをどう束ねて時系列を復元するか(第四章)。記録そのものが改竄されていないかをどう見抜くか(第五章)。もっと厄介な話として、検査には合格しているのに実は壊れている——本プロジェクトで実際に起きた「緑を騙る赤」という事件の実例(第六章)。証拠を扱った記録そのものをどう連鎖させて証明力を保つか(第七章)。一つひとつは無害に見える出来事の連なりから、何を読み取るか(第八章)。そして最後に、こうした判定の仕事を場当たりでなく、体制として設計するには何が要るか(第九章)。

在庫管理システムが深夜3時に止まった、あの朝の続きを、この一冊で最後までたどり切ろう。

---

## 第一章: 証拠とは何か、揮発性の順序(水準一)

### デジタル証拠という考え方

**デジタル証拠(でじたるしょうこ、水準一: 事件・事故の原因や経過を明らかにするために、システムやネットワークから収集される、電子的な記録)**には、メモリの内容、実行中のプロセスの一覧、ネットワーク接続の状態、ファイルのタイムスタンプ、そして本巻の中心テーマである各種の**ログ(水準一: システムやアプリケーションが、いつ・何が起きたかを時系列で書き残していく記録)**が含まれる。紙の書類や指紋と違い、デジタル証拠は目に見えず、しかも扱い方を誤ると本人も気づかないうちに書き換わってしまうという、独特の難しさを持っている。

フランスの犯罪学者**エドモン・ロカール(Edmond Locard、1877-1966)**は、リヨンに世界初期の警察science研究所を設けた人物として知られ、「あらゆる接触は痕跡を残す」という考え方(ロカールの交換原理と呼ばれる)を提唱したとされる。物理世界の犯罪現場で、加害者が現場から何かを持ち去り、現場に何かを残していくのと同じように、デジタルの世界でも、システムに対するあらゆる操作は——正規の利用であれ、障害であれ、不正な侵入であれ——ログやメモリやファイルのタイムスタンプに、何らかの痕跡を残す。フォレンジクスという仕事は、この「必ず残っているはずの痕跡」を、消えてしまう前に、正しい手順で見つけ出す仕事だと言い換えられる。

### 揮発性の順序 — 消えやすいものから先に確保する

コンピュータの中にある情報は、すべてが同じ寿命を持っているわけではない。電源を切った瞬間に消えてしまうものもあれば、何年もそのまま残り続けるものもある。この、情報がどれだけ長く残り続けるかという性質を、**揮発性(きはつせい、水準一: 電源が切れる、あるいは時間が経過すると、失われてしまう性質)**と呼ぶ。

証拠を集める際には、この揮発性が高い(=消えやすい)ものから優先して確保しなければならない。これを**揮発性の順序(きはつせいのじゅんじょ、order of volatility、水準一: 証拠を収集するときに、失われやすい〈揮発性の高い〉ものから優先して確保すべきだという原則)**と呼ぶ。この原則は、2002年に公表された**RFC 3227「証拠の収集と保管に関するガイドライン(Guidelines for Evidence Collection and Archiving)」**に整理された順序が、現在も広く参照されている。

### 検算1 — 揮発性の順序を、実際に並べてみる

RFC 3227が示す順序を、揮発性が高い(=先に確保すべき)ものから並べると、おおむね次のようになる。

```

1. レジスタ・CPUキャッシュ(電源が切れた瞬間に消える。もっとも短命)

2. ルーティングテーブル・ARPキャッシュ・プロセス一覧・カーネル統計・メモリ内容

3. 一時ファイルシステム(tmpfs等)

4. ディスク(電源を切っても残るが、次の書き込みで上書きされ得る)

5. 遠隔地のログ・監視データ(その時点でこそ生きている記録)

6. 物理的な構成・ネットワーク配線図

7. アーカイブ媒体(バックアップテープ等・もっとも長命)

```

検算として、深夜3時に止まった在庫管理システムの事例に当てはめてみよう。当直担当者が真っ先にすべきだったのは、(2)の「実行中のプロセス一覧」や「その時点のメモリ内容」の確保である。ところが実際には再起動が先に行われてしまった。再起動は、電源断ほど極端ではないにせよ、実行中のプロセスやメモリの内容という、揮発性の高い証拠の大半を失わせる操作である。一方で、(4)のディスク上のログファイルや(5)の遠隔地に転送済みのログは、再起動後も残っている可能性が高い——ここに、本巻第三章以降で扱う「ログを読む」仕事の重要性がある。揮発性の高い証拠を取り逃したときに、なお頼りになるのが、あらかじめ外部へ転送・保存されているログなのである。

### コラム — 「触ってしまった」ことを、無かったことにはできない

証拠保全の理想は「何も変えずに確保する」ことだが、現実には、障害対応の初動でシステムに何らかの操作(ログイン、コマンド実行、再起動)が行われてしまうことは珍しくない。このとき絶対にやってはいけないのは、「何も触っていない」と偽ることである。ロカールの交換原理が示すとおり、触れば必ず痕跡が残る。むしろ「いつ、誰が、何を行ったか」を正直に記録し、その操作がどの証拠にどう影響し得るかを添えて報告することのほうが、判定の信頼性を保つ。この「行った操作を隠さず記録する」という姿勢は、第七章で扱う証拠の連鎖の出発点でもある。

### コラム — フォレンジクスの三分野(ホスト・ネットワーク・メモリ)

デジタルフォレンジクスは、対象とする証拠の種類によって、大きく3つの分野に分けて語られることが多い。**ホストフォレンジクス(水準一: 1台のコンピュータ〈サーバーやPC〉のディスク・ログ・設定ファイルを対象とする解析)**は、本巻が主に扱う範囲であり、第二章〜第七章の技術の大半がここに属する。**ネットワークフォレンジクス(水準二: 通信経路を流れるパケットや、ルーター・ファイアウォールの通信記録を対象とする解析)**は、「どのサーバーから、どこへ、何が送られたか」を明らかにする分野で、姉妹巻BOOK-0370『ネットワーク防御の設計』の知見と密接に関わる。**メモリフォレンジクス(水準二: 実行中のプロセスの、揮発性の高いメモリ内容そのものを対象とする解析)**は、第一章の揮発性の順序でもっとも優先度が高いとされた領域であり、電源を落とす前にしか確保できないという制約から、特に難度が高い分野として知られる。本巻はこれら3分野に共通する「判定の考え方」を扱うが、各分野固有の専門ツール・専門技術の深掘りは、本巻の範囲を超える(§16.18の枠内で、仕組みの理解にとどめる)。

### 本巻での「判定」の位置づけ

情報防衛と復旧シリーズ全体は、検知→予防→判定→対応→復旧→制度という一本道を12巻でたどる構成になっている(→CATALOG_情報防衛と復旧シリーズ.md§1参照)。本巻が担うのは、そのうちの**判定**——「何が、いつ、どう壊れたか」を、証拠にもとづいて確定する段階——である。判定の結果は、次巻BOOK-0363『インシデント対応の一本道』が受け取り、封じ込め・根絶・復旧・教訓という後続の一本道へと引き継がれる。判定が甘ければ、その後のすべての対応が的外れになりかねない——本巻が扱う一つひとつの技術は、地味に見えても、この一本道全体の起点を支えている。

---

> **定着量の目安(第一章)**: RFC 3227の揮発性順序を、自分の言葉で(レジスタ→メモリ→ディスク→遠隔ログ→アーカイブ、という大づかみでよいので)説明できるようになるまで、10回程度復唱・書き出す練習をすると定着する。「なぜその順序なのか」を、消えやすさという一つの軸で説明できることが目安である。

---

## 第二章: 証拠保全の原則 — 改変しない、ハッシュで固定する(水準一〜二)

### 現状不変の原則

証拠を確保したら、次にやるべきことは、その証拠を**変えないまま保つ**ことである。これを**証拠保全(しょうこほぜん、水準一: 収集した証拠を、後から誰が見ても同一だと確認できる状態のまま、変更せずに保つこと)**と呼ぶ。証拠保全がなぜ大切かというと、判定の結論は最終的に「この証拠がこう語っている」という形で示されることになるが、その証拠自体が調査の途中で書き換わっていたら、結論の土台そのものが崩れてしまうからである。

実務では、収集した記憶装置の**原本(げんぽん、水準一: 最初に確保された、加工していない証拠そのもの)**には一切手を加えず、複製(作業コピー)を作ってから、その複製の上で解析作業を行う、という手順が広く使われる。原本への書き込みを物理的または論理的に禁止する装置を**書き込み防止装置(かきこみぼうしそうち、write blocker、水準二: 証拠となる記憶装置に接続しても、そこへの書き込みを物理的または論理的に禁止する装置)**と呼び、記憶装置をまるごと複製する作業を**イメージ取得(いめーじしゅとく、imaging、水準二: 記憶装置の中身を、使用領域だけでなく空き領域まで含めて、ビット単位でそのまま複製すること)**と呼ぶ。

### ハッシュ値で「同一である」ことを固定する

原本と複製が「本当に同一である」ことを、どうやって確認すればよいだろうか。ここで使われるのが**ハッシュ関数(はっしゅかんすう、水準一〜二: 任意の長さのデータを入力すると、決まった長さの値〈ハッシュ値〉を出力する関数で、同じ入力からは必ず同じ出力が得られ、1ビットでも入力が変わると出力が大きく変わる性質を持つ)**である。原本のハッシュ値と、複製のハッシュ値を計算し、両者が一致すれば「ビット単位で同一である」ことが検算できる。この考え方は、総関数辞書のFUNC-0188(ハッシュ化の概念、hash concept)に一般化された機能素として登録されている。

似た仕組みに**チェックサム(ちぇっくさむ、水準一: データが転送・保存の途中で壊れていないかを確認するために、データから計算する短い検査用の数値)**があり、こちらはFUNC-0189(チェックサム/CRC概念、checksum/CRC concept)として登録されている。チェックサムとハッシュ関数は、どちらも「元のデータから短い検査用の値を計算する」という点では似ているが、チェックサムは主に偶発的な誤り(通信ノイズ等)の検出を目的とし、ハッシュ関数(特に暗号学的ハッシュ関数)は意図的な改竄の検出にも耐えられるよう設計されているという違いがある。

### 検算2 — 簡易チェックサムで、1文字の書き換えを検出する

理屈を実感するために、手計算できるごく簡易なチェックサム(mod 256の加算チェックサム)を使って、改竄が検出できることを確かめてみよう。文字列の各文字の文字コード(ASCII、→BOOK-0358a第二章参照)を単純に足し合わせ、256で割った余りをチェックサムとする。

```

元のログ行(架空の一部): "OK 200"

各文字のASCIIコード: O=79, K=75, (空白)=32, 2=50, 0=48, 0=48

合計 = 79+75+32+50+48+48 = 332

チェックサム = 332 mod 256 = 76

```

ここで、もし何者かがこのログ行を "OK 500"(ステータスコードを200から500へ書き換え)に改竄したとする。

```

改竄後のログ行: "OK 500"

各文字のASCIIコード: O=79, K=75, (空白)=32, 5=53, 0=48, 0=48

合計 = 79+75+32+53+48+48 = 335

チェックサム = 335 mod 256 = 79

```

改竄前のチェックサム76と、改竄後のチェックサム79は一致しない(検算成立)。たった1文字の書き換えでも、チェックサムの値が変わったことで、「何かが変わった」ことを検出できる。ただし、この簡易チェックサムには弱点もある——加算だけで作っているため、複数の文字が互いに打ち消し合うように書き換えられると、偶然チェックサムが一致してしまう場合があり得る。実務でハッシュ関数(SHA-256系列など)が使われるのは、この「打ち消し合いによる見逃し」が起きにくいよう、はるかに複雑な計算で値を作っているためである。

### コラム — かつて広く使われたMD5というハッシュ関数の教訓

**MD5**は、1990年代前半に発表され、長年にわたって広く使われてきたハッシュ関数である。しかし2004年ごろ、研究者らによって、異なる2つの入力から意図的に同じMD5値を作り出す手法(衝突)が実証されたことが広く知られている。これにより、MD5は「改竄されていないことの証明」という用途には不十分だと判断されるようになり、現在の実務では、より衝突を起こしにくいよう設計された**SHA-256**などのハッシュ関数(SHA-2系列。米国NIST〈国立標準技術研究所〉が2000年代初頭に標準化したとされる)が広く推奨されている。この歴史は、「ハッシュ値が一致した」という検算そのものは強力だが、その検算に使うハッシュ関数自体の強度が時代とともに見直され続ける必要がある、という実務上の教訓を示している。

### コラム — ハッシュと、デジタル署名の違い

ハッシュ関数は「同一であることの検算」には強力だが、「誰が作ったか」までは証明できない。ハッシュ値だけを見ても、それを計算したのが正規の担当者なのか、改竄した本人なのかは区別がつかない。この弱点を補うのが、公開鍵暗号(→BOOK-0073・0133『暗号』で扱う理論、→BOOK-0369『鍵管理とPKIの実務』で扱う運用)を利用した**デジタル署名(でじたるしょめい、水準二: ハッシュ値を、秘密鍵を持つ本人にしか作れない形で暗号化して添付することで、「改変されていないこと」に加えて「誰が作ったか」まで検算できるようにする仕組み)**である。証拠保全の実務では、ハッシュ値だけを記録する場合と、そのハッシュ値にさらにデジタル署名を添える場合があり、後者のほうがより高い証明力を持つ。ただし本巻はあくまで判定(フォレンジクス)の技術を扱う巻であり、鍵の生成・運用そのものの実務は姉妹巻BOOK-0369に譲る。

### よくある誤解 — 「バックアップを取ってあるから安心」ではない

障害対応の現場では「定期バックアップがあるから、いざとなればそこから復元できる」という安心感を持ちがちである。しかし判定の観点からは、バックアップそのものが「いつのハッシュ値と一致する状態のバックアップなのか」が記録されていなければ、そのバックアップが改竄前の状態なのか改竄後の状態なのかを、後から証明することができない。バックアップと証拠保全は似て非なるものであり、バックアップ・災害復旧の実務(→BOOK-0365で扱う)と、証拠としての保全(本巻)は、目的が異なるために設計も異なる、という点を意識しておく必要がある。

---

> **定着量の目安(第二章)**: 簡易チェックサム(検算2の型)を使って、短い文字列を10種類程度、意図的に1文字だけ書き換えてチェックサムの変化を確認する練習をすると、「1ビットの変化が検出可能な値の変化につながる」という感覚がつかめる。あわせて「原本には触れず複製で作業する」「ハッシュ値で同一性を検算する」という2つの手順を、自分の言葉で説明できることを目安とする。

---

## 第三章: ログの種類と読み方(水準二〜三)

### ログという記録の基本構造

ログは、一般に「いつ・何が・どうなったか」という3つの要素を、1行あるいは1レコードにまとめて記録する。この基本構造を、目的別に大きく3種類に分けて理解しておくと、判定作業の見通しが良くなる。

**認証ログ(にんしょうログ、水準二: 誰が、いつ、どのアカウントで、ログインに成功した/失敗したかを記録するログ)**は、「誰がシステムに入ってきたか・入ろうとして失敗したか」を追う際の一次資料になる。**アクセスログ(あくせすログ、水準二: どのリソース〈ファイル・ページ・API〉に、誰が、いつアクセスしたかを記録するログ)**は、ログイン後に「何を見た・何を操作したか」を追う際の一次資料になる。**システムログ(しすてむログ、水準二: OSやサービスの起動・停止・エラー・設定変更など、システム自体の状態変化を記録するログ)**は、「システムそのものに何が起きたか(再起動・クラッシュ・設定変更・リソース枯渇等)」を追う際の一次資料になる。

深夜3時に止まった在庫管理システムの例で言えば、認証ログは「誰かが不正にログインした形跡があるか」を、アクセスログは「在庫データを操作したのは誰か・どの処理経路か」を、システムログは「サービスが落ちた直接の原因(メモリ不足・ディスク満杯・プロセスクラッシュ等)は何か」を、それぞれ語ってくれる可能性がある。3種のログは互いに補い合う関係にあり、どれか1種類だけを見て結論を出すのは危険である。

### ログの品質を左右する4つの性質

ログが判定の役に立つためには、次の性質が備わっている必要がある。

**構造化ログ(こうぞうかログ、structured logging、水準三: 自由な文章ではなく、キーと値の組(JSON等)のように、機械的に読み取れる決まった形式で記録するログ)**は、総関数辞書のFUNC-0396(構造化ログ出力、structured logging)に対応する。自由記述のログよりも、後から機械的に検索・集計しやすいという利点がある。**水準付きログ(すいじゅんつきログ、log with level、水準三)**はFUNC-0395(水準付きログ出力、log with level)に対応し、INFO・WARNING・ERRORのように重大度を分けて記録することで、大量のログの中から重要な行を絞り込みやすくする。この絞り込みの操作自体は、FUNC-0397(ログフィルタリング、filter logs by level)に対応する。

**ログローテーション(ろぐろーてーしょん、log rotation、水準三: 古いログファイルを一定の周期や容量で切り替え・圧縮・削除していく運用)**はFUNC-0398(ログローテーション、log rotation)に対応する。ここには判定業務にとって見過ごせない落とし穴がある——ログローテーションの保存期間が短すぎると、事件発生から発覚までに時間差があった場合、肝心の証拠が「もう消えてしまっている」ということが起こり得るのである。判定の仕事は、事後にログを読むだけでなく、そもそも十分な期間ログが残るよう、あらかじめ設計段階で保存期間を決めておく(→第九章)ことと表裏一体である。

そして、誰が・いつ・何の目的で、権限の変更や重要な操作を行ったかを、専用に記録するログを**監査ログ(かんさログ、audit log、水準三: 権限の変更や重要な操作を、誰が・いつ・何の目的で行ったかに絞って記録する、通常運用のログとは区別された記録)**と呼び、FUNC-0399(監査ログ記録、audit log)に対応する。通常のアクセスログが「何が起きたか」を広く記録するのに対し、監査ログは「誰の責任で、何が変更されたか」という説明責任(アカウンタビリティ)に焦点を絞って記録される点が特徴である。

### 検算3 — 3種のログを実際に読んでみる

架空の在庫管理システムで、深夜3時前後に記録された3系統のログを、それぞれ読み解いてみよう(いずれも教材用の架空データであり、実在の鍵・パスワード・個人情報は一切含まない)。

```

[認証ログ] 02:58:11 user=batch-svc action=login result=success source=10.0.0.5

[アクセスログ] 02:58:40 user=batch-svc method=POST path=/api/inventory/adjust status=200

[システムログ] 02:59:02 service=inventory-db level=ERROR msg="connection pool exhausted"

[システムログ] 02:59:03 service=inventory-app level=WARNING msg="retrying write (attempt 1/3)"

[アクセスログ] 02:59:03 user=batch-svc method=POST path=/api/inventory/adjust status=200

[システムログ] 03:00:15 service=inventory-app level=ERROR msg="process exited unexpectedly (code=137)"

```

この6行だけからでも、次のような仮説を立てられる。まず02:58:11に`batch-svc`という定型処理用アカウントがログインし、02:58:40に在庫調整のAPIを1回呼んでいる(status=200は成功を意味する)。ところが02:59:02にデータベース接続プールが枯渇するエラーが記録され、02:59:03にアプリケーション側が書き込みを再試行し、そのAPI呼び出し自体もstatus=200で成功している(=2回書き込みが行われた可能性がある)。そして03:00:15にプロセスが異常終了している。「同じ在庫調整の処理が、接続プール枯渇による再試行によって2回実行されたのではないか」という仮説が、3種のログを突き合わせることで初めて見えてくる——これが、次章で扱うタイムライン再構成の入り口である。

### コラム — ログの標準的な書式

ログの書式は組織やソフトウェアごとにさまざまだが、ネットワーク機器やUNIX系システムでは、2009年に公表された**RFC 5424「シスログプロトコル(The Syslog Protocol)」**に沿った書式が広く使われている。共通の書式に沿ってログを出すことは、複数の機器・複数のサービスのログを、後から1か所に集約して読み解く(第四章のタイムライン再構成)際に、大きな助けになる。書式がバラバラだと、そもそも「どの部分が時刻で、どの部分がメッセージか」を機械的に読み分けること自体が難しくなってしまうためである。

### コラム — 重大度を8段階に分ける、という発想の起源

RFC 5424が定めるsyslogの書式には、Emergency(緊急・システム利用不能)からDebug(デバッグ用の詳細情報)まで、8段階の重大度(severity)が定義されている。第三章で扱った「水準付きログ」(FUNC-0395)は、この8段階をより実務向けに簡略化したもの(INFO・WARNING・ERRORなど)だと理解すると、由来がつながって覚えやすい。重大度を段階分けしておく利点は、平常時には大量に出るINFOレベルのログをフィルタリング(FUNC-0397)で除外し、ERROR以上だけを常時監視する、といった運用を可能にする点にある。ただし、この効率化にも落とし穴がある——本来ERROR相当の異常が、開発時の設定ミスでINFOレベルとして出力されてしまうと、監視から漏れ落ちてしまう。重大度の割り当てそのものが正しいかどうかも、判定業務では検算の対象になり得る。

---

> **定着量の目安(第三章)**: 認証ログ・アクセスログ・システムログという3分類を、それぞれ実例(検算3のようなログ行)を10行程度読んで「これはどの種類のログで、何を語っているか」を自分の言葉で説明する練習をすると定着する。あわせて「ログローテーションの保存期間が短いと証拠が消える」という落とし穴を、具体的に説明できることを目安とする。

---

## 第四章: タイムライン再構成(水準四〜五)

### 複数のログを、一本の時系列に束ねる

**タイムライン再構成(たいむらいんさいこうせい、水準四: 複数の異なるログ・記録源から得られた事象を、共通の時刻軸の上に並べ直し、何が起きた順序かを復元する作業)**は、フォレンジクスの中心的な技術である。第三章の検算3では、幸い3種のログがすべて同じ時刻表記(時:分:秒)で記録されていたが、実務ではそう単純にいかないことが多い。サーバーAのログはローカル時刻で、サーバーBのログはUTC(協定世界時)で、アプリケーションのログはミリ秒付きのタイムスタンプで——というように、記録源ごとに時刻の表記がバラバラであることが珍しくない。

**協定世界時(きょうていせかいじ、UTC、水準四: 世界共通の時刻の基準。地域ごとのタイムゾーンによる時差の影響を受けない、共通の物差しとなる時刻)**にすべてのログの時刻を変換してから並べ直す、という手順が広く使われる。この変換を怠ったまま複数のログを見比べると、実際には1時間後に起きた出来事を「1時間前に起きた」と誤読してしまうような、致命的な取り違えが起こり得る。

時刻そのものを扱う基本操作は、総関数辞書ではFUNC-0266(現在時刻取得、now)とFUNC-0267(時刻差分、time diff)として一般化されている。タイムライン再構成とは、この「時刻を取得し、差分を計算する」という基本操作を、複数の記録源から集めた多数の事象に対して、体系的に繰り返す作業だと言い換えられる。

### 検算4 — 3系統のログをUTCに正規化し、1本のタイムラインへ束ねる

在庫管理システムの事例を、今度は現実的な設定——認証サーバーはJST(日本標準時、UTC+9)、アプリケーションサーバーはUTC——で記録されていた、という前提で再構成してみよう。

```

[認証ログ・JST表記] 12:00:11 user=batch-svc action=login result=success

[システムログ・UTC表記] 03:00:30 service=inventory-db level=ERROR msg="disk usage 98%"

[アクセスログ・UTC表記] 03:00:45 user=batch-svc method=POST path=/api/inventory/adjust status=200

```

まず認証ログのJST表記をUTCへ変換する(JSTはUTCより9時間進んでいるため、UTC = JST − 9時間)。

```

12:00:11(JST) − 9時間 = 03:00:11(UTC)

```

3系統の時刻をすべてUTCにそろえたうえで、時刻順に並べ直すと、次のタイムラインが得られる。

```

03:00:11(UTC) [認証ログ] batch-svcがログイン成功

03:00:30(UTC) [システムログ] ディスク使用率98%というエラー

03:00:45(UTC) [アクセスログ] batch-svcが在庫調整APIを呼び出し(成功)

```

タイムゾーンをそろえたことで、「ログインの19秒後にディスク使用率の警告が出て、さらに15秒後に在庫調整のAPI呼び出しが行われた」という、正しい前後関係が確定できた。もしJST表記のままUTC表記のログと単純に数字だけを比べていたら、「12:00:11」と「03:00:30」を見比べて「9時間近くも間が空いている」という誤った解釈をしてしまうところだった。この検算が示すとおり、**タイムゾーンの正規化は、タイムライン再構成の一番最初に済ませておくべき、省略の許されない手順**である。

### タイムラインの整合性そのものを検査する — 単調性チェック

タイムラインを再構成したあと、その時系列が「記録された順序どおりに、時刻が逆行していないか」を機械的に確認しておくことも重要である。tools/check_conservation.jsの検査(9)は、台帳イベントの記録順に対して、「tickが台帳の記録順で単調非減少」であることをC5として検査しており、この考え方はFUNC-0772(台帳時系列整合検査、ledger chronological integrity check)に一般化されている。同じ発想をログのタイムライン再構成に当てはめれば、「復元した時系列のなかで、時刻が巻き戻っている箇所はないか」を機械的にチェックすることができる。時刻が巻き戻っている箇所が見つかった場合、それは(a)複数の記録源の時計がそもそもずれている(NTP同期の不備)、(b)タイムゾーン変換を間違えている、(c)ログ自体が改竄されている、のいずれかを示す重要な手がかりになる。

### コラム — 時刻同期そのものが崩れていたら、正規化しても正せない

タイムゾーンの変換(検算4)は、あくまで「各サーバーの時計が正確である」ことを前提にした手順である。もしサーバーAとサーバーBの時計そのものが、数分・数秒単位でずれていたら、いくらタイムゾーンを正確に変換しても、正しい前後関係は復元できない。この土台を支えるのが**NTP(えぬてぃーぴー、Network Time Protocol、水準四: ネットワークを通じて、複数のコンピュータの時計を、共通の基準時刻に同期させ続けるための通信の手順)**である。判定業務の実務では、事件が起きてから「あのサーバーの時計は何秒ずれていたか」を調べるのは非常に困難であるため、そもそも全サーバーでNTP同期を常時有効にしておくことが、タイムライン再構成という技術が正しく機能するための前提条件になる。この「事前に仕込んでおく」という発想は、第九章で扱う証跡設計の考え方の先取りでもある。

### よくある誤解 — 「ログの並び順=発生順」ではない

ログファイルに書き込まれた行の順番が、必ずしも事象が実際に発生した順番と一致するとは限らない。バッファリング(書き込みをまとめて後からディスクへ反映する仕組み)、非同期I/O(処理と書き込みが並行して進む仕組み)、そして複数のサーバーの間での時計のわずかなズレ(NTP同期のドリフト)によって、実際にはAが先に起きたのに、ログ上ではBのほうが先に記録されている、という逆転が起こり得る。タイムライン再構成では、単純にログファイルの行番号順を信用するのではなく、各行に埋め込まれたタイムスタンプ(かつUTCに正規化した後の値)を基準に並べ直すことが欠かせない。

---

> **定着量の目安(第四章)**: 異なるタイムゾーン表記のログを3〜5系統用意し、検算4の型でUTCへ正規化してから1本のタイムラインに束ねる練習を10問程度こなすと、水準四の内容は定着する。あわせて「ログの並び順=発生順ではない」という落とし穴を、バッファリング・NTPドリフトという具体的な原因とともに説明できることを目安とする。

---

## 第五章: 改竄検知 — ハッシュ・保存則・追記専用台帳(水準五〜六)

### 改竄検知という問題の立て方

**改竄検知(かいざんけんち、水準五: 記録やデータが、正当な手続きを経ずに書き換えられていないかを確認すること)**は、第二章で扱った「証拠を変えないまま保つ」という受け身の話とは別に、「すでにある記録が、過去のどこかで書き換えられていないか」を能動的に見抜く技術である。ここで威力を発揮するのが、本プロジェクトのtools/check_conservation.jsで実装されている**保存則(ほぞんそく、水準五: ある系全体を見たとき、増えた量と減った量の帳尻が、常に一致していなければならないという性質)**の検査という考え方である。

check_conservation.jsは、もともとMMO型のゲームにおけるアイテム台帳の複製バグ(dupe)を検出するために作られた検査器だが、その本質は「アイテム」という対象に限定されない、はるかに一般的な仕組みである。ある系に対して「作られた量(mint)」と「消えた量(burn)」を全期間にわたって足し引きした値が、その時点で存在するはずの総量(全所有者の残高の合計)と一致していなければならない——この等式が成り立たなくなったとき、系のどこかで「正規の手続きを経ない増減」が起きたことが、構造的に検出できる。

### 検算5 — 保存則の等式で、改竄の有無を検算する

outputs/FUNC_closure_exam_report_5th.mdに記録されている実測例を引用しよう。ある台帳の検査で、次の結果が得られている。

```

mint合計=150 burn合計=20 残高合計=130 差分=0

保存則検査: PASS

二重消費検出: PASS(負残高なし)

```

保存則の等式は「mint合計−burn合計=全所有者残高の合計」である。この例では `150−20=130` であり、実際の残高合計130と一致している(差分=0)ので、検査はPASSする。ここでもし、何者かが正規の記録を経ずに残高を water増やしていた(たとえば実際の残高合計が140になっていた)とすると、`150−20=130` に対して実際の残高合計140は一致せず、差分は `140−130=10` となって検査はFAILする。**個々の記録が一見もっともらしく見えても、系全体の帳尻という一段上の視点に立つと、改竄は「差分がゼロでない」という、見逃しようのない形で必ず姿を現す**——これが保存則検査の核心である。この検査はFUNC-0769(保存則検査、conservation law check)に、また関連する二重消費(同じ残高を2回使う不整合)の検出はFUNC-0770(二重消費検出、double-spend detection)に、それぞれ一般化された機能素として登録されている。

### 追記専用台帳という設計

保存則の検算がそもそも成立するためには、大前提として「過去の記録が書き換えられていない」ことが必要である。この大前提を仕組みとして保証する設計が、**追記専用台帳(ついきせんようだいちょう、append-only ledger、水準六: 過去に記録された行を書き換えたり削除したりせず、新しい記録を常に末尾に追加する形式で運用される台帳)**であり、FUNC-0993(追記式保存、append-only storage)に一般化されている。

本プロジェクトのgakumon/NUMBER_REGISTRY.mdは、この追記専用台帳の実例である。番号の予約・使用の記録は、すでに書かれた行を書き換えるのではなく、常に末尾に新しい行を追加していく運用で管理されており(→CATALOG_情報防衛と復旧シリーズ.md制定時点でも577行を超える記録が積み重なっている)、過去のどの時点で誰が何を予約したかを、後から誰が読んでも同じ順序・同じ内容で確認できる。

追記専用という制約が、なぜ改竄検知に効くのか。もし過去の行を自由に書き換えられる台帳であれば、改竄した本人が「もともとこうだった」と装って辻褄を合わせることができてしまう。しかし追記専用の台帳では、改竄しようとする者は過去の行を消すことができず、代わりに「矛盾する新しい記録」を追加するしかない。その矛盾は、第四章で扱った時系列の整合性検査(FUNC-0772)や、本章の保存則検査(FUNC-0769)によって、必ず検出可能な痕跡として残る。「過去を隠せない」という制約そのものが、検知を可能にしているのである。この考え方は、FUNC-0667(台帳恒等式検査(湧き-消え=現存))やFUNC-0662(資源保存則検証、resource conservation invariant check)にも共通する、より広い一般原理として登録されている。

### コラム — ハッシュチェーンという発展形

追記専用台帳の考え方をさらに一歩進め、各記録に「直前の記録のハッシュ値」を含めて連鎖させる方式を、ハッシュチェーンと呼ぶ。ある行のハッシュ値には、その行自身の内容に加えて、直前の行のハッシュ値も入力として含まれる。そのため、もし過去のある行を書き換えると、その行のハッシュ値が変わり、それを参照している次の行のハッシュ値も変わり……という具合に、変更の影響が後続のすべての行に連鎖して伝わる。この性質のおかげで、「途中の1行だけをこっそり書き換えて、他は何も変えない」という改竄が構造的に不可能になる。ハッシュチェーンは、本巻第七章で扱う証拠の連鎖(chain of custody)の技術的な裏付けの一つとしても登場する。

---

> **定着量の目安(第五章)**: 検算5の型(mint合計・burn合計・残高合計の3つの数字から差分を計算し、PASS/FAILを判定する)を、正常なケース10問・改竄されたケース10問程度こなすと、保存則検査の考え方は定着する。あわせて「追記専用がなぜ改竄検知に効くのか」を、「過去を書き換えられないので矛盾が新しい記録として残るしかない」という理屈で自分の言葉で説明できることを目安とする。

---

## 第六章: 「緑を騙る赤」の発見法 — 記述検査では見えない欠陥(水準六〜七)

### 検定に合格している、のに壊れている

判定の仕事でもっとも厄介なのは、**「緑を騙る赤」(みどりをかたるあか、水準七: 定義された検査項目には全て合格している〈緑〉ように見えながら、実際には内部に欠陥〈赤〉を抱えている状態)**である。検査に合格しているのだから安全なはずだ、という思い込みが、実は一番危うい。本プロジェクトには、この現象が実際に起きた実例が記録されている。

### FUNC-0278事件 — 5回目の検定で、初めて見つかった欠陥

outputs/FUNC_closure_exam_report_5th.mdによれば、総関数辞書のFUNC-0278(シード付き決定的乱数、seeded RNG/mulberry32)というカードには、js(JavaScript)欄とpython欄の両方に、同じ乱数生成アルゴリズムの実装コードが記載されていた。1回目から4回目までの独立検定は、いずれもこのカードを含む辞書全体を「記述されたとおりに実在コードを説明できているか」という観点(記述閉包)で検査しており、**その4回とも合格していた**。

ところが5回目の検定で、初めて「辞書カードだけを参照して、実際に新しいプログラムを組んで動かす」という構成的検定が行われた。js欄とpython欄のコードを、それぞれ一字一句そのまま書き写し、同じシード値で実行した結果、次の食い違いが実測された。

```

js欄(そのまま) python欄(そのまま) 一致

0.6011037519201636 0.6011037519201636 ○

0.44829055899754167 0.44835159415379167 ×

0.8524657934904099 0.8525268286466599 ×

0.6697340414393693 0.6697340414393693 ○

```

8回中4回もの値が食い違っていた。原因は、python欄のあるコード行が、加算の結果を32ビットに再マスクしないままXOR演算に渡していたためだった。js側では`^`演算子が両辺を暗黙に32ビット整数へ変換するため、オーバーフローが自動的に処理される一方、pythonの整数は多倍長(桁数に上限がない)であるため、この暗黙変換が起こらず、値がずれていた。FUNC-0278のカードが約束する「同じシードなら同じ数列を再現する」という性質は、**単一言語の中では真だったが、言語をまたぐと偽になっていた**のである。

### なぜ4回の検定はこの欠陥を見逃したのか

過去4回の検定はいずれも、「カードに書かれたコードが、実在のシステム(js実装)を正しく説明できているか」という記述の正しさだけを検査していた。python欄を実際に実行して、js欄の実行結果と突き合わせるという工程が、構造的に存在しなかった。tools/check_funcdict_langs.jsは、この教訓を踏まえて設計された定期チェッカーであり、**二層構造**を持つ。1つ目は「構造層」——全カード・全12言語欄が空欄でないか、正規のキーがそろっているかを、外部依存ゼロ・約1秒で検査する層である。2つ目は「挙動層」——実行時系のカードだけを対象に、実際にjs/pythonの両方を走らせ、同じシードで出力が一致するかを実測で突き合わせる層である。構造層だけならFUNC-0278のカードは「全欄記入済み」で合格(緑)していたが、挙動層で初めて不一致(赤)が発覚した。**「書類が揃っている」という記述検査(きじゅつけんさ、水準七: 対象が「正しく書かれているか」「必要な項目がそろっているか」を、実行せずに確認する検査)と、「実際に動かして突き合わせる」という実行検査(じっこうけんさ、構成的検定、水準七: 対象を実際に動かし、その結果を突き合わせることで正しさを確認する検査)は、まったく別の検査であり、片方の合格がもう片方の合格を保証しない**——これが本事件の核心の教訓である。

### 検算6 — フォレンジクスにおける「緑を騙る赤」の一般化

この教訓は、辞書カードの検定に限らず、フォレンジクスの判定業務そのものに直接当てはまる。「ログに、正常に処理が完了したと記録されている」ことと、「実際にその処理が、記録どおりに正しく完了していた」ことは、別の主張である。ログの記録(記述)を読むだけの検査は、記述検査に相当する。一方、記録された処理の結果を、独立に再計算・再実行して突き合わせる検査は、実行検査(構成的検定)に相当する。総関数辞書では、この考え方がFUNC-0643(決定的再計算検証、deterministic recomputation verification)とFUNC-0686(申告結果と再計算の突合、claim vs recomputation cross-check)、そしてFUNC-0775(数量突合、quantity reconciliation)として一般化されている。

在庫管理システムの事例に当てはめよう。第三章の検算3で見た「status=200(成功)」というアクセスログの記録は、あくまで「処理が成功したとアプリケーションが申告した」という記述にすぎない。実際にその処理どおりに在庫データが正しく変更されたかどうかは、別途、変更後のデータを独立に再計算し、申告と突き合わせて初めて確定できる。ログが「成功」と書いてあることを鵜呑みにせず、実際のデータと突き合わせる——この一手間こそが、「緑を騙る赤」を暴く唯一の方法である。

### コラム — 定期チェッカーという防御の形

tools/check_funcdict_langs.jsの構造層(約1秒・LLMトークン0・外部依存ゼロ)は、金融庁型の「定期脆弱性チェック」の内製版に相当するとコード内コメントに明記されている。フォレンジクスの判定業務は、事件が起きてから重い腰を上げて調べるだけでなく、こうした軽量な定期チェッカーを常時回しておくことで、「緑を騙る赤」が長期間気づかれないまま放置される事態そのものを減らすことができる。定期チェッカーの設計思想は、本巻第九章(フォレンジクス体制と証跡設計の実務)で改めて扱う。

### よくある誤解 — 「一度合格したものは、ずっと信頼できる」ではない

FUNC-0278事件のもう一つの教訓は、「過去に4回検定に合格した」という実績そのものが、5回目の欠陥発見を妨げなかった、という点である。もし「4回も合格しているのだから、今さら疑う必要はない」という油断があれば、5回目の構成的検定そのものが行われなかったかもしれない。判定業務においても、「このログ基盤は昔から安定稼働している」「この監査プロセスは長年運用されてきた」といった実績への信頼が、かえって新しい種類の検査(実行検査・突合)を怠らせる油断につながることがある。過去の合格実績は、次の検定を省略してよい理由にはならない——これは、検証ラチェット(白→黄→緑の一方向の格上げ)の考え方とも一致する、一段上の検定は一段下の検定を代替しないという原則である。

---

> **定着量の目安(第六章)**: FUNC-0278事件の経緯(4回合格→5回目で発覚)を、自分の言葉で時系列を追って説明できるようになるまで、2〜3回読み返すとよい。あわせて「記述検査」と「実行検査(構成的検定)」の違いを、具体例(ログの記述 vs. 実データの再計算)を1つ自分で作って説明できることを目安とする。

---

## 第七章: 証拠の連鎖(chain of custody)(水準七〜八)

### 証拠は、扱われた記録ごと証拠である

どれほど正確にハッシュを取り、どれほど厳密にタイムラインを再構成しても、その証拠が「収集されてから報告書に使われるまでの間、誰にどう扱われたか」の記録が欠けていれば、判定の結論に説得力を持たせることができない。この考え方を**証拠の連鎖(しょうこのれんさ、chain of custody、水準七: 証拠が収集されてから報告書に使われるまでの間、誰が、いつ、何のために、どのように扱ったかを、途切れなく記録し続けること)**と呼ぶ。この用語はもともと法廷での物的証拠の取り扱いに由来する考え方だが、デジタルフォレンジクスにも、ほぼそのまま引き継がれている。

証拠の連鎖の記録には、次のような情報が含まれる——(1) いつ・誰が証拠を収集したか、(2) どのようなハッシュ値で固定したか(第二章)、(3) その後、誰が・いつ・何の目的でその証拠(あるいは複製)にアクセスしたか、(4) アクセスのたびにハッシュ値が変わっていないか。この一連の記録を残す機能素は、総関数辞書ではFUNC-0776(監査証跡記録、audit trail recording)とFUNC-0989(出典記録、source/provenance recording)に対応する。

### 検算7 — 簡易的な証拠の連鎖を、実際にたどってみる

架空の事例で、証拠の連鎖の記録がどう積み重なるかを見てみよう。

```

[記録1] 03:15 収集者=Aさん 対象=inventory-db-server1 ディスクイメージ取得

ハッシュ値(SHA-256の先頭8桁で略記)=8f3a1c02

[記録2] 09:40 解析者=Bさん 対象=[記録1]の複製 開封前にハッシュ値を再計算

再計算値=8f3a1c02(一致・改変なしを確認)

[記録3] 10:05 解析者=Bさん [記録2]の複製上でログ解析を実施(原本には触れず)

[記録4] 14:20 監査者=Cさん 対象=[記録1]の原本 報告書作成のため最終確認

再計算値=8f3a1c02(一致・原本は最初から最後まで無傷)

```

この4件の記録を見ると、原本のハッシュ値(8f3a1c02)が、収集された03:15から報告書作成直前の14:20まで、途中2回の再計算を経ても一貫して変わっていないことが確認できる。もし途中の[記録3]の段階で誰かが誤って原本に書き込んでしまっていたら、[記録4]で再計算したハッシュ値は8f3a1c02とは異なる値になっていたはずであり、その時点で「連鎖のどこかで何かが起きた」ことが検出できる。証拠の連鎖が途切れずにつながっていること自体が、「この証拠は最初から最後まで、記録どおりにしか扱われていない」という主張の裏付けになる。

この、連鎖の各リンクが途切れていないかを検査する考え方は、総関数辞書のFUNC-0965(参照整合検査、reference integrity check)やFUNC-0393(参照整合性検査、referential integrity check)にも通じる——ある記録が、それより前の記録を正しく参照できているか(前の記録が存在し、内容が一致しているか)という検査は、証拠の連鎖の検証そのものと同じ構造を持っている。

### アンチフォレンジクスという脅威の存在(手順は記載しない)

判定を妨害する目的で、証跡そのものを消去・偽装・隠蔽しようとする行為の総称を**アンチフォレンジクス(水準八: 調査を妨害する目的で、証跡を消去・偽装・隠蔽する行為の総称)**と呼ぶ。ログの削除、タイムスタンプの書き換え(タイムストンピング)、痕跡の上書きといった手口が存在することは、防御側として知っておく必要がある。しかし本巻は防御・検知・教育に限定するという安全枠(§16.18)にもとづき、こうした行為の**具体的な実行方法は一切記載しない**。防御側がこの脅威に備える方法は、これまでの章で扱ってきた技術そのものである——追記専用台帳(第五章)によって過去の記録を書き換え不能にしておくこと、集中ログサーバーへリアルタイムに転送しておくことで、攻撃者が最初に手を付けやすい「現地のログ」だけに証拠を頼らないようにしておくこと、そして証拠の連鎖(本章)を最初から仕組みとして運用しておくことである。「消される前提で、最初から複数箇所に痕跡を残しておく」という設計思想は、第九章で扱う証跡設計の実務に直結する。

### よくある誤解 — 「連鎖が1回でも途切れたら、証拠は無価値になる」わけではない

証拠の連鎖に空白時間や記録漏れが見つかった場合、それは直ちに証拠全体が無価値になることを意味しない。むしろ重要なのは、空白があったこと自体を正直に報告書に明記し、その空白の間に何が起こり得たか(起こらなかった可能性も含めて)を、ハッシュ値の再確認などの補助的な検算で裏付けることである。連鎖の完全性を偽って「一切空白はなかった」と報告するほうが、後になってより深刻な信頼の失墜を招く。誇張を避け、正直に限界を明記するという姿勢は、本シリーズ全体の安全枠(§16.5)とも一致する。

---

> **定着量の目安(第七章)**: 検算7の型(収集→複製→解析→最終確認、という4段階でハッシュ値を追跡する)を、自分で架空の事例を1つ作って書き出す練習をすると定着する。あわせて「証拠の連鎖が途切れた場合にどう報告すべきか(隠さず正直に明記する)」を説明できることを目安とする。

---

## 第八章: 相関分析 — 単独では無害な事象の連鎖を読む(水準八〜九)

### 相関分析とは何か

**相関分析(そうかんぶんせき、水準八: 単独では見過ごされる複数の事象を組み合わせて見ることで、そこに潜む意味やパターンを読み取る分析手法)**は、フォレンジクスの判定業務の中でも、もっとも「探偵的」な作業である。個々のログ行だけを見れば、まったく異常に見えない事象が、複数組み合わさることで、初めて重大な意味を持つ——これが本章のテーマである。

ここで、用語の混同を避けるために2つを区別しておきたい。1つは**統計的相関(とうけいてきそうかん、水準九: 二つの数量が、一方が増えるともう一方も一定の傾向で増減する度合いを、数値〈相関係数〉で表したもの)**であり、総関数辞書ではFUNC-0582(相関係数計算(二資産間)、calculateCorrelationCoefficient)として一般化されている。もう1つは、SIEM(セキュリティ情報イベント管理)などで使われる**イベント相関(いべんとそうかん、水準九: 複数の異なる種類の事象が、決まった時間内に、決まった順序やパターンで発生したかどうかを突き合わせる分析)**であり、こちらは数値の相関係数ではなく、「AがB秒以内にBに続いたか」といったルールベースの突き合わせによって行われることが多い。判定業務で「相関」と言うときは、多くの場合こちらのイベント相関を指す。

### 検算8 — 個々には軽微な事象の連鎖から、兆候を読み取る

架空の事例で、イベント相関の考え方を確かめよう。次の4つの事象は、それぞれ単独で見ると、どれも「よくあること」で片付けられかねない。

```

21:03〜21:11 IPアドレス203.0.113.7から、8つの異なるアカウントへのログイン失敗が

合計23件記録されている(認証ログ)

21:14 同じIPアドレスから、アカウント"guest-ops"へのログインが成功している(認証ログ)

21:16 アカウント"guest-ops"が、通常は使わない管理者権限のAPIエンドポイントへ

アクセスしている(アクセスログ)

21:19 アカウント"guest-ops"によって、10万件を超えるレコードが

一括エクスポートされている(アクセスログ)

```

1つ目の事象だけを見れば、単なる入力ミスの連続かもしれない。2つ目だけを見れば、正規のログインが成功しただけである。3つ目だけを見れば、単発の管理操作かもしれない。しかし4つの事象を時系列(第四章)で束ねて相関させると、「多数のアカウントへの総当たり的なログイン試行→たまたま成功した1アカウントでのログイン→権限昇格的な操作→大量データの持ち出し」という、一連の筋書きが浮かび上がる。個々の事象の重大度は低いか中程度でも、その連鎖全体は重大な兆候として扱うべきである、というのが相関分析の核心である。この種の異常な繰り返しパターンを機械的に見つけ出す考え方は、総関数辞書のFUNC-0597(取引ログ重複検出、detectDuplicateTransactions)にも通じる、頻度・重複に着目した検出アプローチの一例である。

### 相関≠因果、そして誤検知への誠実な向き合い方

統計の分野でよく言われる「相関は因果を意味しない」という注意は、フォレンジクスの相関分析にもそのまま当てはまる。ある事象の連鎖が浮かび上がったからといって、それが必ずしも一つの意図的な攻撃を意味するとは限らない。正規の運用担当者が、たまたま似た時間帯にパスワードを何度か間違え、その後たまたま正しくログインし、たまたま定例のデータエクスポート作業を行った、という偶然の重なりも現実にはあり得る。

実際には異常でない事象を、誤って異常だと判定してしまうことを**誤検知(ごけんち、false positive、水準九: 実際には異常でない事象を、誤って異常だと判定してしまうこと)**と呼ぶ。相関分析にもとづく判定は、誤検知の可能性を常に伴う。判定を担う者の誠実な姿勢は、「相関が見つかった=断定する」のではなく、「相関が見つかった=優先度を上げて、独立した裏付け(第六章の実行検査、第七章の証拠の連鎖)で確認する」という手順を踏むことである。誇張を避け、確度に応じた言葉遣いで報告するという姿勢(§16.5)は、相関分析の結果を報告する場面でこそ、もっとも強く求められる。

### コラム — SIEMという道具の考え方

実務では、複数のサーバー・機器から集めたログを1か所に集約し、あらかじめ定義したルールに沿って自動的に相関を検出する仕組みを、**SIEM(しーむ、Security Information and Event Management、水準九: 複数のログ・記録源を1か所に集約し、あらかじめ定めたルールに沿って自動的に相関分析・アラート発報を行う仕組み)**と呼ぶ。検算8で人手でたどった「総当たりログイン→成功→権限昇格操作→大量エクスポート」という連鎖は、SIEMのような仕組みがあれば、あらかじめ定義したルール(例えば「同一IPから短時間に一定件数以上のログイン失敗があり、その直後に同一IPからログイン成功があった場合に警報を出す」)によって、自動的かつリアルタイムに検出できる。ただし、SIEMのルールも人間が設計するものである以上、ルールが粗すぎれば誤検知が増え、細かすぎれば見逃しが増えるという、避けがたいトレードオフを抱えている。SIEMという道具そのものの設計・運用は、姉妹巻BOOK-0367『監視と観測可能性』でより詳しく扱う。

---

> **定着量の目安(第八章)**: 検算8のような複数事象の連鎖を、自分で3〜4事象からなる架空の事例として3パターン作り、それぞれ「個々には軽微だが、束ねると意味を持つ」筋書きを説明する練習をすると定着する。あわせて「相関は因果を意味しない」という注意を、誤検知という具体的な言葉とともに説明できることを目安とする。

---

## 第九章: フォレンジクス体制と証跡設計の実務(水準十〜十二)

### 判定を、個人技から体制へ

ここまでの章は、個々の技術——揮発性の順序、証拠保全、ログの読み方、タイムライン再構成、改竄検知、実行検査、証拠の連鎖、相関分析——を扱ってきた。しかし、これらの技術を一人の担当者の腕前だけに頼っていては、その担当者が不在のとき、あるいは判断を誤ったときに、組織全体の判定能力が揺らいでしまう。水準十二では、これらの技術を**体制**として組み込む実務を扱う。

体制設計の第一歩は、**職務分掌(しょくむぶんしょう、水準十一: 一人の人物が全ての権限を握らないよう、業務ごとに担当と権限を分けること)**である。証拠を収集する担当と、その証拠を解析する担当と、解析結果を監査・承認する担当を分けておくことで、一人の判断ミス(あるいは不正)が、判定結果全体を左右してしまう事態を防ぐ。検算7で見た「収集者Aさん・解析者Bさん・監査者Cさん」という役割分担は、まさにこの職務分掌を反映した例である。

### 証跡設計 — 事後に探すのではなく、あらかじめ仕込む

**証跡設計(しょうせきせっけい、水準十二: 事後に証拠を探すのではなく、システムを設計する段階からあらかじめ、何を、どう記録するかを組み込んでおくこと)**は、本巻全体の総まとめにあたる考え方である。第一章から第八章までの技術は、いずれも「証拠がすでにそこにある」ことを前提にしていた。しかし、その証拠がそもそも十分な粒度・十分な期間・十分な形式で残されていなければ、どれほど優れた解析技術を持っていても、判定は不可能である。

証跡設計の具体的な柱は、これまでの章で扱ってきた個々の技術と対応している。(1) 監査ログ(第三章)を、権限変更や重要操作について漏れなく出力するようアプリケーション設計に組み込むこと。(2) 追記専用台帳(第五章)を、書き換え不能な形で運用し、NUMBER_REGISTRY.mdのような実例を他のシステムにも一般化すること。(3) 構造化ログ(第三章)を採用し、後からの機械的な相関分析(第八章)がしやすい形式で記録すること。(4) 時刻同期(NTP等)をあらかじめ全サーバーで揃えておき、タイムライン再構成(第四章)の際のタイムゾーンの取り違えを未然に防ぐこと。(5) 十分なログ保存期間を、ログローテーション(第三章)の設計段階で確保しておくこと。

台帳の番号帯そのものを定期的に監査する考え方は、総関数辞書のFUNC-0777(台帳番号帯監査、ledger ID-band audit)に一般化されている。これは、個々の記録の正しさだけでなく、記録の「番号の割り振り方」自体に矛盾や重複がないかを検査する、体制側の視点に立った検査である。

### コラム — CSIRT・SOCという役割の型

体制として判定業務を担う専門チームは、一般に**CSIRT(しーさーと、Computer Security Incident Response Team、水準十一: セキュリティ上の事故が発生した際に、検知・判定・対応の窓口となる専門チーム)**や**SOC(えすおーしー、Security Operations Center、水準十一: ログ・アラートを常時監視し、異常の一次検知を担う専門部門)**と呼ばれる組織の型として整備されることが多い。SOCが日常的な監視(第八章のSIEM運用を含む)を担い、実際に事件が疑われる兆候が見つかった段階でCSIRTが判定(本巻の技術一式)に着手する、という役割分担が一般的である。この役割分担も、職務分掌の一形態であり、「監視する人」と「深く掘り下げて判定する人」を分けることで、日常監視の負荷と、事件発生時の集中的な調査という、性質の異なる2つの仕事を無理なく両立させている。

### 定期チェッカーという運用の型

第六章で扱ったtools/check_funcdict_langs.jsは、外部依存ゼロ・約1秒・LLMトークン0で回せる構造層の検査を、いつでも何度でも実行できる形で用意している。この設計思想は、判定業務を「事件が起きてから慌てて調べる」ものから、「日常的に、軽量な検査を回し続けることで、異常の芽を早期に見つける」ものへと転換させる。本プロジェクトの決定事項ログにも、「台帳監査は`node tools/gen_ledger_audit.js`(読み取り専用・約1秒)を定期実行して行う」という運用方針が記録されている。フォレンジクス体制の講師級の仕事とは、こうした軽量な定期チェッカーを、どこに・どの頻度で・誰が結果を見るかまで含めて設計し、判定という重い仕事の大半を、事件発生前の日常業務のうちに前倒しで済ませてしまうことだと言い換えられる。

### 本巻のまとめとしての一本道

ここまでの9つの章を、あらためて一つの流れとして振り返ってみよう。

```

証拠とは何か・揮発性の順序(第一章) → 証拠保全・ハッシュで固定(第二章)

→ ログの種類と読み方(第三章) → タイムライン再構成(第四章)

→ 改竄検知・保存則・追記専用台帳(第五章) → 「緑を騙る赤」の発見法(第六章)

→ 証拠の連鎖(第七章) → 相関分析(第八章) → 体制と証跡設計の実務(第九章)

```

消えやすい証拠を正しい順序で確保し(第一章)、確保した証拠を改変せずハッシュで固定し(第二章)、ログという記録を種類ごとに読み分け(第三章)、複数のログを時刻で束ねて事象の順序を復元し(第四章)、記録そのものが改竄されていないかを保存則で見抜き(第五章)、検査に合格していることを鵜呑みにせず実行検査で突き合わせ(第六章)、証拠を扱った記録自体を途切れなく連鎖させ(第七章)、単独では無害な事象の連なりから兆候を読み取り(第八章)、最後にこれらすべてを個人技でなく体制と設計に落とし込む(第九章)——この一本道をたどりきったとき、「何が、いつ、どう壊れたか」を、憶測ではなく証拠から確定するという、本巻の値札どおりの仕事ができる状態に到達する。

---

> **定着量の目安(第九章)**: 職務分掌と証跡設計という2つの考え方を、自分の言葉で(なぜ権限を分けるのか・なぜ事後でなく事前に仕込むのか)説明できるようになるまで、2〜3回読み返すとよい。あわせて、第一章から第八章までの技術を、証跡設計の5本の柱((1)監査ログ (2)追記専用台帳 (3)構造化ログ (4)時刻同期 (5)十分な保存期間)のどれに対応するかを、自分で対応表を作って整理する練習をすると、本巻全体の定着が確かなものになる。

---

## 三つの実践解(§16.21) — 手元の記録だけでできる、安全な実践

理論を、実際に手を動かして確かめる方法を三つ紹介する。いずれも実在システムへの侵入や、危険な操作を必要としない、安全な実践解である。

1. **自分のPCのログを、実際に3種類に分類してみる実践**: 自分が使っているパソコンには、すでに認証ログ(ログイン履歴)・アクセスログ(ブラウザの閲覧履歴等)・システムログ(OSのイベントビューアやシステムログ)に相当する記録が存在している。それぞれの記録を(閲覧のみで、変更や削除は行わずに)開いてみて、「これは第三章のどの種類のログに当たるか」「どんな時刻表記になっているか」を確認する。タイムゾーンの表記(ローカル時刻かUTCか)にも注目すると、第四章の内容と直接つながる。

2. **簡易チェックサムの自作実践**: 検算2で使った「文字コードを足してmod 256を取る」チェックサムを、紙とペン、あるいは表計算ソフトで自分の好きな短い文章について計算してみる。次に、その文章のどこか1文字だけをこっそり書き換えて、再度チェックサムを計算し、値が変わることを確認する。さらに、意図的に「合計が同じになるように2文字を同時に書き換える」実験をしてみて、チェックサムだけでは検出できない改竄が原理的に作れてしまうことを体験する(これが、実務で単純な加算チェックサムではなく、暗号学的ハッシュ関数が使われる理由の実感につながる)。

3. **架空タイムラインの再構成実践**: 第四章の検算4のように、自分で3〜4個の架空の事象(時刻・タイムゾーン表記付き)を作り、それをUTCに正規化してから時系列に並べ直す練習を、5パターンほど自作して解いてみる。余裕があれば、意図的に1つだけ時刻が矛盾する事象を混ぜておき、「タイムラインの単調性チェック(第四章)でその矛盾に気づけるか」を自分で確認してみるとよい。

---

## まとめ — 憶測ではなく、証拠で語る一本道

本巻では、「何が、いつ、どう壊れたか」を確定するという判定の仕事を、揮発性の順序という土台(第一章)から、証拠保全とハッシュによる固定(第二章)、ログの読み方(第三章)、タイムライン再構成(第四章)、保存則と追記専用台帳による改竄検知(第五章)、そして本プロジェクトで実際に起きたFUNC-0278事件を教材にした「緑を騙る赤」の発見法(第六章)、証拠の連鎖(第七章)、相関分析(第八章)、最後に体制と証跡設計の実務(第九章)までをたどってきた。

深夜3時に止まった在庫管理システムの物語に、もう一度戻ろう。焦って再起動する前に揮発性の高い証拠を確保し(第一章)、確保した証拠にハッシュ値で印をつけ(第二章)、3種のログを読み分け(第三章)、タイムゾーンをそろえて一本のタイムラインに束ね(第四章)、在庫データの残高が保存則の等式に合っているかを検算し(第五章)、「ログに成功と書いてある」ことを鵜呑みにせず実際のデータと突き合わせ(第六章)、証拠を扱った記録自体を途切れなく残し(第七章)、個々には軽微に見える事象の連鎖から兆候を読み取る(第八章)——この一連の作業を積み重ねてはじめて、「何が、いつ、どう壊れたか」を、誰が読んでも納得できる形で報告できる。

判定の結論は、次巻BOOK-0363『インシデント対応の一本道』に引き継がれ、封じ込め・根絶・復旧・教訓という後続の一本道へつながっていく。判定という地味な土台を丁寧に固めることこそが、「一日停止・全システム再構成の段階判断」という重い特命業務全体の、確かな出発点になる。

---

## 章末: タイムラインの検算図と、まとめの階段図

まず、第四章で組み立てたタイムライン正規化の手順を、図で振り返る。

```

[認証ログ・JST]12:00:11 ──(−9時間)──▶ 03:00:11(UTC)

[システムログ・UTC]03:00:30 ─────────▶ 03:00:30(UTC)

[アクセスログ・UTC]03:00:45 ─────────▶ 03:00:45(UTC)

時刻順に並べ替え: 03:00:11 → 03:00:30 → 03:00:45(単調性チェックOK・矛盾なし)

```

続いて、本巻全体の歩みを階段図としてまとめる。

```

[水準十〜十二] 体制と証跡設計の実務

職務分掌+証跡設計5本の柱(監査ログ/追記台帳/構造化ログ/時刻同期/保存期間)

▲

│ 個人技を、体制と設計に落とし込む

[水準八〜九] 相関分析

総当たりログイン→成功ログイン→権限昇格操作→大量エクスポート(検算8)

▲

│ 単独では無害な事象を束ねて意味を読む

[水準七〜八] 証拠の連鎖(chain of custody)

ハッシュ値8f3a1c02が収集から報告まで一貫(検算7)

▲

│ 証拠を扱った記録自体を、途切れなく連鎖させる

[水準六〜七] 「緑を騙る赤」の発見法

FUNC-0278・4回合格→5回目で言語間不一致を実測発見(検算6)

▲

│ 記述検査でなく、実行して突き合わせる

[水準五〜六] 改竄検知(保存則・追記専用台帳)

mint150-burn20=残高130・差分0=PASS(検算5)

▲

│ 系全体の帳尻という一段上の視点で改竄を見抜く

[水準四〜五] タイムライン再構成

JST12:00:11→UTC03:00:11に正規化して束ねる(検算4)

▲

│ 複数のログを共通の時刻軸に並べ直す

[水準二〜三] ログの種類と読み方

認証ログ・アクセスログ・システムログの3分類(検算3)

▲

│ 記録を目的別に読み分ける

[水準一〜二] 証拠保全(改変しない・ハッシュで固定)

チェックサム76→改竄後79・不一致で検出(検算2)

▲

│ 触れずに保ち、ハッシュ値で同一性を検算する

[水準一] 証拠とは何か、揮発性の順序

レジスタ→メモリ→ディスク→遠隔ログ→アーカイブ(検算1・RFC 3227)

横の広がり:

[水準一] ロカールの交換原理(あらゆる接触は痕跡を残す)という物理フォレンジクスからの一般化

[水準五] ハッシュ関数 ←(対をなす)→ チェックサム(暗号学的強度の有無という違い)

[水準九] 統計的相関(相関係数) ←(区別)→ イベント相関(ルールベースの突き合わせ)

現在のフロンティア(第六章の実例):

2026年 総関数辞書の5回目の独立検定で、FUNC-0278の言語間不一致が実測発見される

※構造層(記述の網羅性)だけでは見抜けず、挙動層(実行しての突き合わせ)で初めて発覚した

実例であり、本巻第六章の核心教材である。修補は司令塔裁定待ちとして正直に明記する。

次巻(情報防衛と復旧シリーズ): BOOK-0363(水準四〜十・インシデント対応の一本道

─判定結果を受け取り、検知→封じ込め→根絶→復旧→教訓の一本道を完成させる) ─────▶

```

---

## 参照文献(標準・原著・本プロジェクト内アンカー)

1. Brezinski, D. and Killalea, T. *RFC 3227: Guidelines for Evidence Collection and Archiving*, 2002年公表(揮発性の順序の整理・第一章)。

2. Kent, K., Chevalier, S., Grance, T., Dang, H. *NIST Special Publication 800-86: Guide to Integrating Forensic Techniques into Incident Response*, 米国国立標準技術研究所(NIST)刊(証拠保全・解析の標準的な実務指針・第二章)。

3. Gerhards, R. *RFC 5424: The Syslog Protocol*, 2009年公表(ログの標準的な書式・第三章コラム)。

4. エドモン・ロカール(Edmond Locard、1877-1966)の交換原理に関する、犯罪学・フォレンジクス史の定番文献群(「あらゆる接触は痕跡を残す」という考え方の出典として広く紹介される・第一章)。

5. デジタルフォレンジクス・インシデント対応に関する、大学・実務向けの標準的な教科書群(証拠の連鎖〈chain of custody〉・タイムライン分析の基礎を扱う定番の入門書群・第七章)。

6. 本プロジェクト内アンカー: tools/check_conservation.js(保存則検査の実装・第五章)、tools/check_funcdict_langs.js(構造層・挙動層の二層チェッカー・第六章)、gakumon/NUMBER_REGISTRY.md(追記専用台帳の実例・第五章)、outputs/FUNC_closure_exam_report_5th.md(FUNC-0278事件の実測記録・第六章)、outputs/func_dict_index.json(FUNC-ID実名確認の索引)。

---

（本冊子は情報防衛と復旧シリーズ BOOK-0364。全12巻(BOOK-0360〜0371)のうち第5巻(フォレンジクスとログ解析)。次巻BOOK-0363『インシデント対応の一本道』では、本巻が確定した判定結果を受け取り、封じ込め・根絶・復旧・教訓という一本道を完成させる予定。CATALOG_情報防衛と復旧シリーズ.md・GAKUMON_UNIVERSE.md進捗台帳を参照。安全枠(§16.18)遵守: 本巻には実在システムへの侵入手順・動作するエクスプロイト・アンチフォレンジクスの実行手順は一切含まれない。）

---

# BOOK-0364 情報防衛と復旧シリーズ 第5巻: フォレンジクスとログ解析 — 何が、いつ、どう壊れたかを、証拠から確定する