「ログの海」で溺死する前に：証跡（Audit Trail）を作りすぎた一人情シスの末路
「念のため、全てのログを取っておこう」 「何かあった時に追跡できないと困るから」
情シス担当者が陥りがちな、最も危険な思考停止の一つです。 ストレージが安くなった現代、ログを保存すること自体は難しくありません。PCの操作ログ、ファイルサーバーのアクセスログ、防火壁の通信ログ、SaaSの監査ログ……。 これらを全てSIEM（SplunkやDatadogなど）に放り込めば、理論上は「完全な追跡可能性（Traceability）」が手に入ります。
しかし、その「完全なログ」は、いざという時にあなたを助けてくれるでしょうか？ それとも、膨大なノイズの山となって、真実を覆い隠してしまうでしょうか？
本稿では、「証跡の作りすぎ」が招く運用の破綻と、一人情シスが目指すべき**「必要十分なログ設計」**について論じます。
なぜ、ログは無限に増えるのか
1. 「不安」の裏返し
ログは「お守り」です。「見ているぞ」というポーズを取ることで、内部不正を抑止したい。あるいは、何か起きた時に「ログはあります（中身は見れてないけど）」と言い訳したい。 この不安が、過剰なログ収集のドライビングフォース（駆動力）になります。
2. 監査人の「とりあえず」質問
監査法人や親会社の監査部門は、テンプレートに従って質問してきます。 「特権IDの操作ログは取得していますか？」 「USBメモリの書き出しログは？」 「入退室ログとPCログの突合は？」
これらに「No」と答えたくない一心で、ツールを導入し、ログ設定をONにします。 しかし、「ログを取ること」と「ログを監視・分析できること」は天と地ほど違います。
証跡過多が招く「3つの破綻」
1. コストの破綻（クラウド破産）
ログは「水」のようなものです。最初はコップ一杯でも、集めれば湖になります。 クラウド型のログ分析基盤（SIEM）は、従量課金が一般的です。 「ファイアウォールのRejectログ（拒否ログ）」まで全て転送設定にした結果、翌月の請求書が数十万円跳ね上がった、という悲劇は珍しくありません。 保存期間を「念のため3年」などにした日には、ストレージコストだけで情シスの予算が飛びます。
2. 検索性の破綻（干し草の山から針を探す）
「Aさんがファイルサーバーから重要データを消したかもしれない。調べてくれ」 そう言われてログを見に行きますが、そこには「毎秒数百件」の無意味なシステムアクセスログが記録されています。 ウイルス対策ソフトのスキャンログ、バックアップソフトの読み取りログ、Windowsのバックグラウンド処理……。 これらのノイズを除去（フィルタリング）する設計をしていなければ、本当に必要な「AさんのDelete操作」の1行を見つけるのに、3日かかります。3日かかる調査は、実務上「不可能」と同じです。
3. アラート疲労（オオカミ少年）
「ログに『Error』という文字が出たらメール通知する」 素朴な設定をした結果、毎朝100通のメールが届きます。その99%は無視していいエラーです。 やがて情シスは、アラートメール用のフォルダを「既読にする」ボタンを押すだけの機械になります。 そして、その中に紛れ込んでいた「本物の致命的なエラー（HDD故障の予兆など）」を見落とします。
「脱・ログ収集」の思考法
では、どうすればいいのか。 発想を転換しましょう。「全て取る」から**「必要なもの以外は捨てる」**へ。
1. 監査は「制約条件」として交渉する
監査人から「ログを取れ」と言われたら、まずは「なぜですか？（リスクは何ですか？）」と問い返してください。 そして、以下のように交渉します。
- 監査：「全操作ログを3年保存してください」
- 情シス：「コストが年間500万かかります。リスクベースで考え、『個人情報を含むフォルダへのアクセスログ』のみに絞り、期間も1年としたいですが、いかがですか？ それなら予算内で収まり、週次でのレビューも可能です」
「取れません」ではなく**「スコープを絞れば、より確実に監視できます」**という提案です。 監査人も、闇雲にログを集めて欲しいわけではなく、統制が効いているかを知りたいだけなので、論理的であれば合意できます。
2. 「アイデンティティ」ログに全振りする
一人情シスが最優先で守るべきログは、**「誰が（Who）、いつ（When）、どこに入ったか（Login）」**です。 つまり、IdP（Okta, Entra ID, Google Workspace）の認証ログです。
- 操作ログ（何をしたか）は、量が多すぎて追えません。
- 認証ログ（誰が入ったか）は、量はそれほど多くなく、不正アクセスの検知に直結します。
「操作ログは取っていませんが、ログイン履歴は完璧に把握しており、怪しい国からのアクセスは即座に検知できます」。 これで十分なセキュリティレベルと言えます。
3. 「アーカイブ（塩漬け）」を活用する
どうしても全ログが必要な場合（法的な要請など）、「分析基盤（ホットストレージ）」に入れるのではなく、「安価なアーカイブストレージ（Amazon S3 Glacierなど）」にテキストファイルのまま流し込みます。
- 検索：できない（やるなら数時間かけて復元してから）。
- コスト：激安。
「ログはあります。ただ、取り出すのにコストと時間がかかります。それでも調査が必要な重大インシデント時のみ申請してください」 この運用フローにしておけば、日常の運用負荷はゼロになります。
説明責任との折り合い
「ログを取っていませんでした」は無能ですが、「リスクが低いので取らないと決めました」は経営判断です。
重要なのは、**ログ設計書（ポリシー）**を残すことです。
- 取得対象：認証ログ、重要サーバの操作ログ。
- 取得しない対象：一般PCの操作ログ、Web閲覧履歴。
- 理由：プライバシー保護およびコスト対効果の観点から、これらはインシデント発生時の事後調査（PCフォレンジック）で対応する。
これを紙（PDF）にして、リスク管理委員会で承認印をもらっておくこと。 これさえあれば、事故が起きた時に「なぜログがないんだ！」と詰められても、「全社で合意したポリシー通りです」と堂々と答えられます。
結論：ログは「読む」ためにある
読まれないログは、ただのゴミデータです。 一人情シスのあなたの時間は、ゴミを溜め込むためにあるのではありません。
「週に1回、30分で目視確認できる量」。 これが、あなたが扱うべきログの適量です。
大量のログ収集ツールとの契約書にサインする前に、自問してください。 「私は、このログを見るだろうか？」
答えがNoなら、その予算でもっと美味しいランチを食べに行きましょう。その方が、よっぽど生産性は上がります。
AIに相談するためのプロンプト（テンプレート）
「全部ログを取れ」という無茶な要求に対し、コストと運用負荷の観点から現実的な「ログポリシー」を策定するためのプロンプトです。
あなたはセキュリティ監視（SOC）とコスト管理の専門家です。
監査上の理由から「ログ管理ツール」の導入を検討していますが、全てのログを取ると予算（SIEMの従量課金）がパンクします。
記事にある「ログの断捨離（必要なものだけ見る）」に基づき、最適なログ取得方針を設計してください。
# 監視対象候補
1. 認証ログ（IdP）
2. PC操作ログ（全社員分）
3. ファイルサーバーのアクセスログ
4. ファイアウォールの通信ログ
5. 入退室ログ
# 制約条件
* 予算: [例: 月額5万円以内]
* 運用担当: [例: 1名（週に1時間しかログを見る時間がない）]
# 出力してほしい内容
1. **取得情報の選別**: 上記候補のうち、予算と運用リソース内で「絶対に取るべきログ」と「捨てていい（またはアーカイブでいい）ログ」に仕分けてください。
2. **ログポリシー案**: 「なぜPC操作ログを全件監視しないのか」と問われた際の、プライバシーとコストの観点からの回答ロジック。