IT監査の証跡の残し方：実務で役立つノウハウ

はじめに：なぜ証跡管理がIT監査の成否を分けるのか

「監査対応で証跡を求められたが、どこに何があるかわからない」 「証跡として提出したが、不十分と指摘されてしまった」

IT監査の実務に携わる方なら、一度はこのような経験をされたことがあるのではないでしょうか。

IT監査における**証跡（エビデンス）**とは、統制活動が適切に実施されていることを証明するための記録や文書のことです。監査人が「この統制は有効に機能している」と判断するためには、客観的で検証可能な証跡が不可欠です。

本記事では、IT監査の証跡を効果的に残すための実務ノウハウを、具体的な手順とともに解説します。内部監査部門の担当者はもちろん、システム部門でIT統制を担当されている方、外部監査への対応を行う方にも役立つ内容となっています。

背景・概要：IT監査における証跡の重要性

IT監査とは

IT監査とは、組織の情報システムに関連するリスク管理、内部統制、ガバナンスが適切に機能しているかを評価・検証するプロセスです。具体的には以下のような観点から評価が行われます。

• ITガバナンス：IT戦略と経営戦略の整合性
• IT全般統制（ITGC）：プログラム変更管理、アクセス管理、運用管理など
• IT業務処理統制：アプリケーション上での入力・処理・出力の正確性
• 情報セキュリティ：機密性・完全性・可用性の確保

証跡が求められる理由

証跡は、監査において以下の役割を果たします。

1. 客観性の担保：口頭説明だけでなく、文書化された記録により事実を客観的に示す
2. 再現性の確保：同じ証跡を見れば、誰でも同じ結論に到達できる
3. 説明責任の履行：ステークホルダーに対して統制の有効性を説明できる
4. 継続的な改善：過去の記録を参照することで、改善点を特定できる

証跡不備がもたらすリスク

証跡管理が不十分な場合、以下のようなリスクが生じます。

実際に、ある上場企業では、IT全般統制の証跡不備が原因で内部統制報告書に「重要な欠陥」を記載せざるを得なくなった事例もあります。証跡管理は、単なる事務作業ではなく、企業価値を守るための重要な活動なのです。

具体的な手順・要点：証跡を適切に残すための7つのポイント

ポイント1：証跡の「5W1H」を明確にする

証跡として有効と認められるためには、以下の要素が明確に記録されている必要があります。

• Who（誰が）：実施者・承認者の氏名または識別情報
• What（何を）：実施した統制活動の内容
• When（いつ）：実施日時（タイムスタンプ）
• Where（どこで）：対象システム・環境
• Why（なぜ）：実施の根拠・理由
• How（どのように）：具体的な手順・方法

実務ポイント：システムから出力したログやレポートには、上記の要素が自動的に含まれていることが多いです。しかし、手動で作成する証跡（チェックリストや承認記録など）では、意識的にこれらの要素を盛り込む必要があります。

具体例：アクセス権レビューの証跡

【証跡として不十分な例】
「アクセス権の確認を実施しました」

【証跡として適切な例】
実施日：2026年4月15日
実施者：情報システム部 山田太郎
対象システム：基幹会計システム（SAP S/4HANA）
対象期間：2026年1月〜3月の新規付与・変更アクセス権
確認項目：
 - 付与申請書との照合：OK（全42件一致）
 - 職務分掌違反のチェック：問題なし
 - 不要アカウントの確認：2件検出、4/18までに削除予定
承認者：情報システム部長 鈴木一郎（2026年4月16日承認）

ポイント2：証跡の保存形式と命名規則を統一する

証跡管理で最も混乱を招くのが、保存形式と命名規則の不統一です。担当者ごとにバラバラなルールで保存していると、後から証跡を探し出すのに膨大な時間がかかります。

推奨する保存形式

命名規則の例

[対象システム]_[統制項目]_[対象期間]_[バージョン].[拡張子]

例：SAP_AC-001_アクセス権レビュー_202604_v1.0.pdf

実務ポイント：命名規則は、監査対象期間ごとにフォルダを分けることと組み合わせると、さらに管理しやすくなります。

/IT監査証跡
  /2026年度
    /Q1（4月〜6月）
      /アクセス管理
      /変更管理
      /運用管理
    /Q2（7月〜9月）
    ...

ポイント3：リアルタイムで証跡を残す習慣をつける

「後でまとめて記録しよう」という考えは、証跡管理の大敵です。時間が経つと記憶が曖昧になり、重要な情報が抜け落ちてしまいます。また、事後的に作成された証跡は、監査人から「後付けではないか」と疑われるリスクもあります。

リアルタイム記録を実現するための施策

1. ワークフローシステムの活用：申請・承認プロセスをシステム化し、自動的にログが残る仕組みを構築する

2. 定型フォーマットの準備：毎回ゼロから作成するのではなく、テンプレートを用意しておく

3. デイリー/ウィークリーでの記録習慣：まとめて記録するのではなく、日次・週次で小まめに記録する

4. チェックリストの電子化：紙のチェックリストではなく、Microsoft Forms、Google Forms、または専用の監査管理ツールを使用する

具体例：変更管理の証跡をリアルタイムで残す

変更管理では、以下の各フェーズで証跡を残すことが重要です。

① 変更要求（リクエスト）
   → 変更管理チケット（ServiceNow、Redmine等）の起票
   
② 影響分析・テスト
   → テスト計画書、テスト結果報告書
   
③ 承認
   → CAB（変更諮問委員会）議事録、電子承認記録
   
④ 実装
   → 作業ログ、スクリーンショット、デプロイ記録
   
⑤ 完了確認
   → 本番確認チェックリスト、完了報告

ポイント4：証跡の完全性・真正性を確保する

証跡は「改ざんされていないこと」が前提です。特に外部監査や規制当局への報告では、証跡の完全性・真正性が厳しく問われます。

完全性・真正性を確保するための方法

実務ポイント：クラウドサービスを利用している場合、AWS CloudTrail、Azure Monitor、Google Cloud Audit Logsなどのサービスを活用することで、改ざん困難な監査ログを自動的に収集できます。

ポイント5：サンプリングと母集団の関係を明確にする

監査では、すべての取引・処理を確認することは現実的ではないため、**サンプリング（抽出検査）**が行われます。この際、以下の点を証跡として明確に残すことが重要です。

サンプリング証跡に必要な要素

1. 母集団の定義と件数

   • 例：「2026年1月〜3月のプログラム変更申請 全125件」

2. サンプリング方法

   • 無作為抽出（乱数表、Excel RAND関数等）
   • 層別抽出（重要度や金額帯で層を分ける）
   • 属性抽出（特定の条件に該当するものを抽出）

3. サンプル数の根拠

   • 統計的サンプリング：信頼水準95%、許容誤差率5%で必要なサンプル数を算出
   • 非統計的サンプリング：リスクに応じて25件、40件などを設定

4. サンプルの一覧

   • 抽出した個々のサンプルの識別情報（申請番号、日付等）

具体例：サンプリング記録シートのテンプレート

【サンプリング記録】
対象統制：AC-002 アクセス権の付与承認
対象期間：2026年1月1日〜3月31日
母集団：アクセス権付与申請 全87件
サンプリング方法：Excelの乱数関数による無作為抽出
サンプル数：25件（ISA 530に基づく統計的サンプリング）
抽出日：2026年4月10日
抽出者：内部監査部 佐藤花子

【サンプル一覧】
No. | 申請番号 | 申請日 | 申請者 | テスト結果
1   | AR-20260115-003 | 2026/1/15 | 営業部 田中 | OK
2   | AR-20260122-008 | 2026/1/22 | 経理部 伊藤 | OK
...

ポイント6：例外事項・逸脱事象も漏らさず記録する

監査では、「うまくいっていること」だけでなく、「うまくいかなかったこと」の記録も極めて重要です。例外事項や逸脱事象を正直に記録し、それに対する対応も含めて文書化することで、統制の実効性を示すことができます。

記録すべき例外事項の例

• 承認者が不在で、代理承認が行われた
• 緊急変更により、通常の承認プロセスを省略した
• テスト環境の制約により、一部のテストをスキップした
• セキュリティパッチの適用が計画より遅延した

例外事項の記録フォーマット

【例外事項報告】
発生日：2026年3月5日
対象統制：CM-003 変更管理の承認プロセス
事象：緊急のセキュリティパッチ適用のため、CAB承認を事後承認とした
理由：CVE-2026-XXXXの脆弱性が公開され、24時間以内の対応が必要と判断
実施した対応：
 - 当日中にパッチを適用
 - 翌営業日にCABにて事後承認を実施
 - インシデント報告書を作成
承認者：IT部門長 高橋（2026年3月6日）
再発防止策：緊急変更プロセスの手順書を見直し、24時間対応体制を検討

実務ポイント：例外事項を記録することをためらう組織もありますが、むしろ例外事項を適切に管理・記録していることが、成熟した統制環境の証拠となります。監査人は、例外が「ゼロ」の組織よりも、例外を適切に認識・対応している組織を評価します。

ポイント7：証跡の保存期間と廃棄ルールを定める

証跡は「残せばよい」というものではなく、適切な保存期間と廃棄ルールを定める必要があります。

保存期間の目安

廃棄時の注意点

1. 廃棄記録の作成：何を、いつ、誰が、どのように廃棄したかを記録
2. 機密情報の安全な廃棄：シュレッダー処理、データ消去ソフトの使用
3. リーガルホールド：訴訟や調査が見込まれる場合は廃棄を保留

よくある質問（FAQ）

Q1：証跡として画面キャプチャを取る際のベストプラクティスは？

A1：画面キャプチャは手軽に取得できる証跡ですが、以下の点に注意してください。

推奨されるプラクティス

1. タイムスタンプを含める

   • PCの日時表示が画面に映るようにする
   • Windowsの場合、タスクバーの時計を含める
   • 可能であれば、NTPサーバーとの同期を確認しておく

2. 全体と詳細の両方を撮る

   • 画面全体のスクリーンショット（コンテキストを示す）
   • 確認した箇所のズームアップ（詳細を示す）

3. 連番で管理する

   • 一連の作業の流れがわかるように連番を付ける
   • ファイル名に日時を含める

4. 注釈を加える

   • 赤枠や矢印で確認ポイントを明示
   • ただし、元データの改ざんと誤解されないよう、元の画像は別途保存

使用ツールの例

• Windows：Snipping Tool、Win + Shift + S
• Mac：Shift + Command + 4
• 専用ツール：Snagit、Greenshot、ShareX

実務ポイント：「画面キャプチャだけでは不十分」と指摘されることもあります。可能な限り、システムから出力したレポート（PDF、CSV等）と組み合わせて証跡とすることを推奨します。

Q2：クラウドサービス（SaaS）利用時の証跡はどのように取得すべきか？

A2：クラウドサービスでは、オンプレミス環境と異なり、直接ログファイルにアクセスできないことが多いです。以下の方法で証跡を取得します。

取得方法の例

1. 管理コンソールからのエクスポート

   • 多くのSaaSでは、管理者向けに監査ログのエクスポート機能がある
   • 例：Microsoft 365 監査ログ、Google Workspace 監査ログ、Salesforce 設定変更履歴

2. API経由での取得

   • REST APIやGraphQL APIを使って定期的にログを取得
   • 自動化することで、証跡取得の漏れを防止

3. SIEM/ログ管理ツールとの連携

   • Splunk、Sumo Logic、Azure Sentinelなどにログを集約
   • リアルタイムで取得・保存される

4. ベンダーからのSOC報告書の取得

   • SOC 1/SOC 2報告書を取得し、ベンダー側の統制を確認
   • 自社で直接確認できない統制の代替証跡となる

主要クラウドサービスのログ保存期間（参考）

実務ポイント：SaaSの監査ログは、ベンダーの都合で保存期間が変更されることがあります。重要なログは、自社で別途保存する運用を構築しておくことを強くお勧めします。

Q3：監査人から「証跡が不十分」と指摘された場合、どう対応すべきか？

A3：まず、冷静に指摘内容を正確に把握することが重要です。

対応ステップ

Step 1：指摘内容の明確化

• 何が不足しているのか（情報の欠落、形式の問題、タイミングの問題など）
• どのレベルの証跡が求められているのか
• 代替証跡で対応可能か

Step 2：追加証跡の収集

• システムから追加情報を取得できないか確認
• 関係者へのヒアリング結果を文書化
• 補完的な証跡の提供

Step 3：発生原因の分析と改善

• なぜ証跡が不十分だったのか（プロセス、ツール、人員の問題）
• 再発防止のために何を改善すべきか
• 改善計画を策定し、監査人と共有

注意すべき点

• 言い訳をしない：「昔からこうだった」「他社もこの程度」という主張は逆効果
• 事後的な作成に注意：指摘を受けてから証跡を「作成」することは、証跡の真正性を損なう
• 建設的な対話：監査人は敵ではなく、統制の改善パートナーと捉える

具体例：指摘への対応事例

【指摘内容】
変更管理の承認証跡について、承認者のIDは記録されているが、
承認日時が記録されていない。

【対応】
① 現状の調査
   → ITSMツール（ServiceNow）の設定を確認し、
     承認日時が項目として存在するが表示されていなかったことを特定

② 追加証跡の提供
   → データベースから承認日時を含むレポートを出力し、追加提供

③ 恒久対策
   → 標準レポートに承認日時フィールドを追加
   → 今後のレビュー用チェックリストに「承認日時の確認」を追加

まとめ：証跡管理を成功させるためのチェックリスト

ここまで、IT監査における証跡の残し方について、7つの重要ポイントを中心に解説してきました。最後に、実務で活用できるチェックリストをまとめます。

日常的な証跡管理チェックリスト

☐ 5W1Hを意識して記録しているか

• 誰が、何を、いつ、どこで、なぜ、どのように実施したかが明確か

☐ 統一されたルールで保存しているか

• ファイル命名規則、フォルダ構成が統一されているか
• 証跡の保存形式が適切か

☐ リアルタイムで記録しているか

• 後からまとめて作成していないか
• 自動化できる部分は自動化しているか

☐ 完全性・真正性を確保しているか

• タイムスタンプが正確に記録されているか
• 改ざんを防止・検知する仕組みがあるか

☐ サンプリングの根拠を残しているか

• 母集団とサンプル数の関係が明確か
• 抽出方法が文書化されているか

☐ 例外事項も記録しているか

• 通常と異なる処理を行った場合、その理由と対応を記録しているか

☐ 保存期間と廃棄ルールを定めているか

• 法令や社内規程に基づいた保存期間を設定しているか
• 廃棄時の手順が明確か

定期的に見直すべき事項

• 年1回以上：証跡管理手順書の見直し
• 監査終了後：監査人からのフィードバックを反映
• システム変更時：新システムでの証跡取得方法の確認
• 法令・規制変更時：保存期間や記録要件の見直し

最後に

IT監査の証跡管理は、一見すると地道で面倒な作業に思えるかもしれません。しかし、適切な証跡があることで、監査対応の工数は大幅に削減でき、組織の信頼性も向上します。

証跡管理の成功の鍵は、**「監査の時だけ頑張る」のではなく、「日常業務の中に証跡を残す仕組みを組み込む」**ことです。本記事で紹介したポイントを参考に、ぜひ自社の証跡管理プロセスを見直してみてください。

適切な証跡管理は、監査対応のためだけでなく、組織全体のガバナンス強化、ひいては企業価値の向上につながる重要な取り組みです。今日から、できるところから改善を始めてみましょう。

関連キーワード：IT監査、証跡管理、エビデンス、IT全般統制、ITGC、J-SOX、内部統制、監査対応、アクセス管理、変更管理、監査ログ、コンプライアンス