500人の前で登壇してみた（オンライン）
2025年12月6日に開催されたISACA東京支部カンファレンスにて、
「平時の対応が監査を強くする ― IRの観点から分析するシステム監査準備」
というテーマで登壇しました。
本テーマは、日頃のインシデントレスポンス（以下 IR）活動と、監査準備・統制評価に深い共通構造があるにも関わらず、現場では別物として扱われている実態への問題提起です。監査対応は監査部門が「毎期のチェック作業」として進め、IRはセキュリティ部門が「緊急対応」として実施。ログ設計・証跡保管も結果的に二重設計・二重管理され、運用負荷とコストを増大させているのが現状だと考えています。
本記事では、登壇内容とそこで示した問題意識を、資料に基づいて整理し直します。
1. 問題意識の発端
発端は非常にシンプルな気づきでした。
「IRの平時対応と監査準備って、本質的には同じことをやっているのではないか？」
資料でも同様の問題提起を置きました。
IRも監査も、最終的に取り扱っている材料は「ログ」であり、そしてログが唯一の事実を示す証跡です。
例えば、誰がいつ何のアクションをしたかについて、会議体で話した内容も、口頭の説明も本質的には証拠にならず、最終的にはログに帰結します。
これはIRでは被害範囲の特定や侵入経路の復元、
監査では統制が有効に機能していたことの証明
という形で現れます。
しかしなぜか、それらの証跡設計は統一されず、別プロセスで別仕様となることが多いのが実態です。
2. IRと監査は一見違うが、構造は同じ
資料ではIRプロセスとしてNIST SP800-61の構造を示しました。
一方、一般的な監査のプロセスは以下の通りです。
これらを並べて意味づけすると、次のように一致します
| 見ている現実 | IR | 監査 |
|---|---|---|
| 前提を固める | 準備 | 計画策定 |
| 事実収集と理解 | 検知・分析 | 調査・証跡収集 |
| 判断の根拠形成 | 封じ込め・根絶 | 統制有効性評価 |
| 改善と再発防止 | 振り返り | フォローアップ |
つまり両者は
事実 → 分析 → 改善
というサイクルでは同じ構造を持っています。
にもかかわらず、日常業務上は別の部門が別の目的で進めるため重複が発生します。
3. 共通項は「ログの存在」
資料の中で最も強いメッセージは次の一文です。
「唯一の事実を示す証跡はログである」
つまり、どれだけ形式的に整えられた報告書があったとしても、
どれだけ関係者の証言が揃っていても、
ログがなければ事実は復元できません。
そして、
「IRの平時対応も監査準備も、最終的にはログを取得し、完全性を保ち、分析可能な状態にしておくことで成立する」
しかし——ここで問題が生まれます。
ログは単に「記録されていればよい」わけではありません。
- 改ざん不可能
- 正当な権限でアクセスできる
- 関係するイベントが時系列で紐付く
- 閉域性（どの範囲の対象なのか）が明確
- 復元可能な形式で保管されている
などが必要です。
そしてこうした要件が、実は
✔IRでは調査の迅速性を支える条件
✔監査では統制証跡の成立条件
となり、同じものを必要としているにも関わらず、現場では別設計になっているケースが非常に多いのです。
4. 「証跡不足」が両者で共通して発生している現実
■① ログ・証跡が存在しない
- 原因追跡が不能
- 統制有効性証明が不能
■② 資産・構成が不明確
これは主に CMDB整備不備によるものですが、実務では非常に深刻。
- 封じ込め範囲が曖昧
- 対象システムが定義できない
- 復旧優先度が決められない
■③ 権限変更履歴が追えない
実際の現場で最もよく見る問題です。
- 誰が設定変更を行ったのか
- 決裁されたのか
- 通常業務か不正操作か
これらが不明となります。
そしてこの課題は共通の原因に収束
ログ要件が平時に定義されていない
→ 要件定義が後追いになる
→ 改修する時点ではすでにログが存在しない
→ 調査も監査も成り立たない
つまり、
証跡は有事に確保するものではなく、平時に設計するもの
という結論になります。
5. ログ要求はそれぞれ違う正義を持っている
| 領域 | 正義 |
|---|---|
| Security（IR） | 追跡できないログは意味がない |
| Audit（監査） | 統制証跡にならないログは意味がない |
| Legal（法務） | 裁判で証拠にならないなら価値がない |
全員100%正しいのに
別々に設計すると破綻します。
これが現実の多くの企業で起きていることです。
6. なぜ統合すべきか？
ログ設計や証跡管理は「監査」「IR」「法務」「セキュリティ運用」「可観測性」といった複数の領域で、それぞれの目的を満たすために個別に整備されることが少なくありません。しかし、この分断こそが、結果として運用負荷を増やし、本来守るべき事実の完全性や追跡性を損なう要因となります。
統合すべき理由は単純です。
企業内部で発生した事実は1つなのに、証跡設計だけが複数系統化されていること自体が不合理だからです。
単独で設計された監査ログは、平時は成立要件を満たしても、いざインシデントが発生した瞬間には「痕跡を追えない」「粒度が足りない」「関連付けができない」といった形で使い物にならないことがあります。逆にIR用ログは、正式な承認情報や⾧期保全性の要件を満たさず、監査証跡として機能しないことがあります。
つまり両者のログ要求は重複しているにも関わらず、別々に構築することで、同じ“事実”を追うためのデータが別品質・別保存方式として存在し、運用コスト・調整コスト・説明責任がすべて二重化している状態です。
統合は、この非合理な重複を除去し、
- 抜け漏れのないログ要求を満たし
- IR時に初動速度を高め
- システム改修時の調整を一度で済ませ
- コストを最適化しながら
- 監査品質とセキュリティ品質を同時に上げる
という状態を実現します。
ガバナンス強化とセキュリティ強化は、本来トレードオフではありません。
証跡の設計と運用プロセスが統合されれば、それらは確実に「相乗効果」に変わります。
企業側にとって、ログとは運用のための副産物ではなく、正確な意思決定・説明責任・レピュテーション維持・事業継続のために欠かせない資産です。
だからこそ、
同じ事実を扱う証跡設計は一本化されるべきであり、企業体制として統合し続ける価値がある
と言えます。
7.実務的提言
(1) ログ要求の二者突合を行う
例：保持期間
| 要求対象 | IR | 監査 |
|---|---|---|
| 操作ログ | 調査完了まで不定 | 7年 |
| アクセスログ | 侵入兆候追跡 | 監査証跡用途 |
一度見える化するだけで効果あり。
(2) ログの品質指標を設定する
資料の3要素より
Integrity（完全性）
- 改ざん耐性
- WORM方式保存
Traceability（追跡性）
- ID連鎖性
- イベント間相関
Reproducibility（再現性）
- 誰が見ても再現できる説明可能性
(3) 設計を「運用プロセス」に落とす
例）
- ログ削除・変更は申請制にする
- システム更新時にログ要件棚卸しを必須化
- 認証方式変更時にログ仕様改定
8. まとめ
資料の最後では次のメッセージで締めています。
「ログ設計プロセスを統合することで、IRも監査も同時に強化される」
現場でよく見る
- 監査ではログが余る
- IR時はログが足りない
というねじれを解消し、
平時から二者を統合した設計を行うことで、企業のセキュリティレジリエンスは高まると思います。
監査人の独立性と協力姿勢の両立について考える
本発表の質疑では、
「ログ設計に監査部門が関与すると独立性が失われるのではないか」
という問いがありました。
確かに監査人にとって独立性は最も重要な原則の一つです。
しかしながら、「独立性」を理由として、ログ設計や証跡要件の議論に関与しないという姿勢は、企業のビジネス価値、リスク低減、説明責任強化という観点では望ましいとは言えない側面があります。
ログ要件そのものは、監査部門だけのための存在ではなく、
- IR（被害最小化）
- 法務（説明責任）
- 経営（事業継続）
と緊密に関係しています。
そして企業活動において最終的に重要なことは、
適切な証跡に基づき、企業の意思決定・説明責任・リスク判断を可能にすることです。
監査部門は、指摘するために存在しているわけではなく、
企業の統制環境（Internal Control Environment）を成熟させる役割を持っています。
その意味で、監査人は
- 設計責任を持たず
- 実装責任も負わず
- 運用責任にも踏み込まず
という独立性を維持したまま、
要求事項の明確化や方向性の助言には関与できるはずです。
事実、国際基準（IPPF）では次のように規定されています：
監査人は統制設計における助言を行ってよいが、
最終的な意思決定・設計責任を負ってはならない。
この原則に照らしても、
「対話参加」や「要求事項の提示」を避ける必要は全くありません。
むしろ現場では、
- 開発チームの構成
- クラウド移行
- SaaS利用
- 権限管理方式の変更
など 監査要件に影響する意思決定が日々行われています。
その意思決定過程に全く関与せず、後から
「証跡がないので統制不備」
「ログが不完全なので指摘対象」
となることは、監査側の価値提供として不十分です。
監査人が指摘することが企業価値向上につながっているか？
これは重要な本質的問いだと思います。
現場では次の問題が散見されます。
- 指摘のための指摘になっている
- 運用影響や投資対効果を考慮していない
- 不備解消や再発防止につながっていない
- 現場に負荷を増やしただけで終わる
これらは本来の監査の価値とは言えません。
監査部門は、対立の立場ではなく
組織の透明性と説明責任の担保を通じ、企業価値を高める支援者
であるはずです。
その意味で、監査人は
❌ 設計責任を負ってはいけません
⭕ 設計議論に参加し、要件を提示すべきです
なぜならログ設計は後戻りできないからです。
年月が経ってから証跡の欠損に気づいても、再現はできません。
だからこそ監査人は
◆ 設計フェーズで存在してはいけない責任
→ 設計者でも運用者でもない
一方で
◆ 設計フェーズで存在していなければいけない視点
→ 何が形式的証跡として成立条件となるか
を提示できます。
それは独立性を損なう行為ではなく、
むしろ 「価値提供による監査人としての存在証明」 に近いと考えています。
最後にまとめると、
企業にとっての本当の目的は
- 検知力の強化
- 説明責任能力の確保
- 意思決定の透明化
- 有事の損害最小化
- 事業継続性の確保
であり、監査もIRもセキュリティも、
結局は企業価値の維持・向上に奉仕する役割に過ぎません。
だからこそ監査側は
「独立性」を盾に距離を取るのではなく
「助言者としての協力姿勢」を示すべきだと思います。
その姿勢が、
- 形式的な監査から
- 実態価値ある監査へ
移行していく第一歩になると考えています。
今回の登壇が皆様の議論の一助になることを願います。