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

はじめに：なぜIT監査の証跡が重要なのか

IT監査において、「証跡（エビデンス）」は監査の生命線です。どれだけ優れた監査手続きを実施しても、適切な証跡が残っていなければ、その監査結果の信頼性を担保することはできません。

私自身、IT監査の現場で15年以上の経験を持っていますが、証跡の残し方ひとつで監査品質が大きく左右される場面を数多く見てきました。特に近年は、内部統制報告制度（J-SOX）の定着、サイバーセキュリティリスクの増大、そしてリモートワークの普及により、IT監査の重要性はますます高まっています。

本記事では、IT監査における証跡の残し方について、実務で即座に活用できるノウハウを体系的に解説します。監査担当者はもちろん、被監査部門としてIT監査を受ける立場の方にも参考になる内容です。

背景・概要：IT監査における証跡とは

証跡（エビデンス）の定義

IT監査における証跡とは、監査手続きの実施内容と結果を客観的に証明する記録・資料のことです。英語では「Audit Evidence（監査証拠）」と呼ばれ、国際的な監査基準でも重要な概念として位置づけられています。

証跡は大きく分けて以下の3種類があります：

物理的証跡：紙の帳票、サーバールームの入退室記録、ハードウェアの設置状況写真など
電子的証跡：システムログ、設定ファイル、スクリーンショット、データベースの出力結果など
証言的証跡：担当者へのヒアリング記録、インタビューメモ、会議議事録など

証跡が求められる理由

IT監査において証跡が重視される背景には、以下の3つの理由があります。

1. 監査品質の担保

監査法人や規制当局によるレビュー（品質管理レビュー）において、証跡は監査手続きが適切に実施されたことを示す唯一の証拠となります。証跡が不十分な場合、監査意見そのものの信頼性が問われることになります。

2. 法的・規制要件への対応

J-SOX対応、PCI DSS（クレジットカード業界のセキュリティ基準）、ISO 27001（情報セキュリティマネジメントシステム）など、多くの規制・基準で証跡の保管が義務付けられています。例えば、J-SOXでは監査調書の保存期間は原則として7年間と定められています。

3. 継続的改善の基盤

適切に残された証跡は、翌年度以降の監査計画策定や、セキュリティ改善活動の基礎資料として活用できます。過去の証跡を分析することで、リスクの傾向把握や対策の有効性評価が可能になります。

IT監査特有の課題

IT監査は、財務監査や業務監査と比較して、証跡の収集・保管に特有の課題があります。

技術的複雑性：システム設定やログの取得には専門知識が必要
データ量の膨大さ：1日あたり数GB〜数TBのログが生成されることも珍しくない
改ざんリスク：電子データは意図的・偶発的な改変が容易
揮発性：一時的なメモリ上のデータや上書きされるログは消失しやすい

これらの課題を踏まえ、次章から具体的な証跡の残し方について解説していきます。

具体的な手順と要点：実務で使える8つのポイント

ポイント1：証跡収集計画を事前に策定する

証跡収集は場当たり的に行うのではなく、監査計画の段階で「何を」「いつ」「どのように」収集するかを明確にしておくことが重要です。

証跡収集計画に含めるべき項目：

項目	具体例
監査対象システム	基幹業務システム、Webサーバー、Active Directory
収集対象の証跡	アクセスログ、設定ファイル、権限一覧
収集タイミング	監査期間中の特定日（例：2026年4月10日時点）
収集方法	システム管理者立会いのもとエクスポート
担当者	監査担当：山田、被監査側：IT部門鈴木

実務ポイント： 証跡収集計画は被監査部門と事前に共有し、合意を得ておきましょう。これにより、監査当日の作業がスムーズになり、必要な証跡の漏れを防ぐことができます。

ポイント2：スクリーンショットは「5W1H」を意識して取得する

IT監査で最も頻繁に使用される証跡がスクリーンショットです。しかし、単に画面を撮影するだけでは不十分です。

スクリーンショット取得時の必須要素：

When（いつ）：システム日時を画面内に表示（タスクバーの時計など）
What（何を）：対象画面の全体像がわかるようにタイトルバーを含める
Where（どこで）：サーバー名やURL、システム名を画面内に含める
Who（誰が）：ログインユーザー名を画面内に表示
How（どのように）：設定値や実行結果を明確に表示

良いスクリーンショットの例：

[スクリーンショットに含まれる情報]
- タイトルバー：「Active Directory ユーザーとコンピューター」
- サーバー名：DC01.example.local
- 操作対象：ユーザー「admin_tanaka」のプロパティ
- 設定値：アカウントの有効期限「2026年12月31日」
- システム日時：2026年4月17日 14:32:05（タスクバー表示）

実務ポイント： Windows標準のSnipping Toolではなく、スクリーンショット専用ツール（例：Greenshot、ShareXなど）を使用すると、自動でタイムスタンプを付与できて便利です。

ポイント3：ログ証跡は「生データ」と「加工データ」の両方を保管する

システムログは、IT監査における最重要証跡の一つです。しかし、ログの取り扱いには注意が必要です。

保管すべきログの形式：

生データ（Raw Data）
- システムから出力されたそのままの形式
- CSV、TSV、JSON、XML、またはバイナリ形式
- 改ざんがないことを証明するためハッシュ値を記録
加工データ（Processed Data）
- 分析しやすいよう整形したデータ
- Excelやスプレッドシート形式
- フィルタリング条件や加工手順を明記

ハッシュ値の記録例：

ファイル名：access_log_20260417.csv
ファイルサイズ：2,457,893 bytes
SHA-256：a3b8c9d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9
取得日時：2026年4月17日 15:00:00
取得者：監査担当 山田
取得元：Webサーバー WEB01（192.168.1.10）

実務ポイント： ログの保管期間は監査基準や法規制によって異なります。J-SOXでは7年、PCI DSSでは最低1年（オンライン3ヶ月）が目安です。保管期間を明確にし、期限管理を徹底しましょう。

ポイント4：ヒアリング証跡は「事実」と「意見」を分けて記録する

IT監査では、システム担当者へのヒアリングが不可欠です。しかし、ヒアリング内容を適切に記録しなければ、証跡としての価値が低下します。

ヒアリング記録のフォーマット例：

## ヒアリング記録

### 基本情報
- 日時：2026年4月17日 10:00〜11:30
- 場所：本社会議室A
- 出席者：
  - 被監査側：IT部門 鈴木課長、佐藤主任
  - 監査側：山田（記録者）、田中

### 質問と回答

**Q1. パスワードポリシーの設定内容を教えてください。**

【事実】
- 最小文字数：12文字
- 複雑性要件：大文字・小文字・数字・記号のうち3種類以上
- 有効期限：90日
- 履歴保持：過去12回分

【回答者の見解】
「現行ポリシーは3年前に策定したもので、最新のガイドラインと比較すると
パスワード有効期限の考え方が異なる可能性がある」（鈴木課長）

【監査人のメモ】
→ NIST SP 800-63Bでは定期的なパスワード変更を推奨しない方向に
  変化しているため、ポリシー見直しの必要性を指摘事項候補とする

実務ポイント： ヒアリング記録は当日中に作成し、可能であれば被監査側の確認（レビュー）を受けることで、記録の正確性を担保できます。確認を受けた記録には「確認済み」の旨と確認者名を記載しましょう。

ポイント5：設定ファイルは「差分比較」ができる形式で保管する

IT監査では、セキュリティ設定やシステム構成の妥当性を評価することが多くあります。設定ファイルを証跡として保管する際は、前回監査時との差分比較ができるよう工夫しましょう。

推奨される保管方法：

テキスト形式での保存
- バイナリ形式の設定は、可能な限りテキストでエクスポート
- 例：レジストリ設定は.regファイルとしてエクスポート
命名規則の統一
- {システム名}_{設定種別}_{取得日付}.{拡張子}
- 例：WebServer01_IIS_config_20260417.xml
差分管理ツールの活用
- WinMerge、Beyond Compare、diffなどのツールで変更点を可視化
- 差分結果も証跡として保管

設定ファイル保管のチェックリスト：

ファイル名に取得日付が含まれている
文字コードが統一されている（UTF-8推奨）
改行コードが統一されている（Windows: CRLF、Linux: LF）
ハッシュ値を記録している
機密情報（パスワード等）がマスキングされている

実務ポイント： 設定ファイルにパスワードやAPIキーなどの機密情報が含まれる場合は、マスキング処理を行ってから保管します。ただし、マスキング箇所と元の文字数は記録しておきましょう。

ポイント6：証跡の命名規則とフォルダ構成を標準化する

大量の証跡ファイルを効率的に管理するには、命名規則とフォルダ構成の標準化が不可欠です。

推奨するフォルダ構成：

IT監査_2026年度/
├── 01_監査計画/
│   ├── 監査計画書_v1.0.docx
│   ├── リスク評価シート.xlsx
│   └── 監査スケジュール.xlsx
├── 02_証跡/
│   ├── 01_アクセス制御/
│   │   ├── AD_ユーザー一覧_20260417.xlsx
│   │   ├── AD_グループ一覧_20260417.xlsx
│   │   └── screenshots/
│   │       ├── AD_パスワードポリシー_20260417_143205.png
│   │       └── AD_アカウントロックアウト設定_20260417_143412.png
│   ├── 02_変更管理/
│   ├── 03_運用管理/
│   └── 04_ログ管理/
├── 03_ヒアリング記録/
├── 04_分析資料/
├── 05_報告書/
└── 99_参考資料/

ファイル命名規則の例：

【基本形式】
{カテゴリ}_{内容}_{日付}_{連番}.{拡張子}

【具体例】
SC_Webサーバー設定確認_20260417_001.png
LOG_アクセスログ_20260401-20260430.csv
INT_IT部門ヒアリング_20260417.docx

実務ポイント： フォルダ構成と命名規則は、監査プロジェクト開始時にチーム内で合意し、文書化しておきましょう。また、ファイル名に日本語を使用する場合は、文字化けに注意が必要です。

ポイント7：電子署名・タイムスタンプを活用して改ざん防止を図る

電子的証跡は改ざんが容易なため、証拠能力を高めるための対策が重要です。

改ざん防止の手法：

ハッシュ値の記録
- SHA-256などの暗号学的ハッシュ関数を使用
- ハッシュ値は別ファイル・別媒体で保管
電子署名の付与
- PDF文書への電子署名
- コードサイニング証明書によるファイル署名
タイムスタンプサービスの利用
- 認定タイムスタンプ局（TSA）による時刻証明
- e-文書法対応が必要な場合は認定タイムスタンプが必須
WORM（Write Once Read Many）ストレージの活用
- 書き換え不可能なストレージへの保管
- クラウドサービス（AWS S3 Object Lock等）の活用

ハッシュ値計算の実行例（PowerShell）：

# SHA-256ハッシュ値の計算
Get-FileHash -Path "C:\監査証跡\access_log.csv" -Algorithm SHA256

# 出力例：
# Algorithm       Hash                                                                   Path
# ---------       ----                                                                   ----
# SHA256          A3B8C9D1E2F3A4B5C6D7E8F9A0B1C2D3E4F5A6B7C8D9E0F1A2B3C4D5E6F7A8B9      C:\監査証跡\access_log.csv

実務ポイント： 特に重要な証跡（経営者確認書、監査報告書など）には、認定タイムスタンプの付与を検討しましょう。タイムスタンプ費用は1件あたり数円〜数十円程度であり、訴訟リスクを考慮すれば十分に投資価値があります。

ポイント8：証跡のレビューと品質チェックを実施する

収集した証跡は、監査報告書の作成前に品質チェックを実施することで、不備や漏れを早期に発見できます。

証跡品質チェックの観点：

チェック観点	確認項目
十分性	監査目的を達成するために必要な証跡が揃っているか
適切性	証跡の内容が監査手続きと整合しているか
信頼性	証跡の出所が明確で、改ざんの恐れがないか
適時性	証跡の取得時期が監査対象期間と整合しているか
完全性	証跡に欠損や途切れがないか

証跡レビューチェックリスト：

## 証跡レビューチェックリスト

### 基本情報
- レビュー対象：アクセス制御に関する証跡一式
- レビュー日：2026年4月20日
- レビュー者：田中（シニアマネージャー）

### チェック結果

| No. | 証跡名 | 十分性 | 適切性 | 信頼性 | 適時性 | 完全性 | 備考 |
|-----|--------|--------|--------|--------|--------|--------|------|
| 1 | AD_ユーザー一覧 | ○ | ○ | ○ | ○ | ○ | - |
| 2 | 特権ID棚卸表 | △ | ○ | ○ | ○ | ○ | 承認者の捺印なし→要追加取得 |
| 3 | アクセスログ | ○ | ○ | ○ | × | ○ | 3/15-3/20の期間が欠損→要確認 |

### 総合評価
- 追加取得が必要な証跡：2件
- 是正が必要な証跡：1件

実務ポイント： 証跡レビューは、できれば証跡を収集した担当者以外の者が行うことで、客観性を確保できます。監査チームが少人数の場合でも、相互レビューの仕組みを取り入れましょう。

よくある質問（FAQ）

Q1. 証跡の保管期間はどのくらいが適切ですか？

証跡の保管期間は、適用される法規制や社内規程によって異なります。以下に主な基準を示します。

規制・基準	保管期間	備考
J-SOX（内部統制報告制度）	7年	会計帳簿の保存期間に準拠
PCI DSS	最低1年（直近3ヶ月はオンライン）	バージョン4.0での要件
ISO 27001	組織で定義（一般的に3〜5年）	リスクアセスメントに基づき決定
会社法	10年	計算書類等の保存期間

実務上の推奨事項：

複数の規制が適用される場合は、最も長い保管期間に合わせることをお勧めします。また、訴訟リスクを考慮して、重要な証跡は10年程度保管する企業も少なくありません。

保管期間の管理には、証跡台帳を作成し、保管期限と廃棄予定日を明記しておくと便利です。

Q2. クラウドサービスの監査証跡はどのように取得すればよいですか？

クラウドサービス（AWS、Azure、Google Cloudなど）の監査では、従来のオンプレミス環境とは異なるアプローチが必要です。

クラウド証跡取得の基本戦略：

管理コンソールのスクリーンショット
- 設定画面、ポリシー設定、ユーザー管理画面など
- URL、ログインユーザー、タイムスタンプを含める
監査ログ・アクティビティログの取得
- AWS：CloudTrail、Config
- Azure：Activity Log、Azure Monitor
- Google Cloud：Cloud Audit Logs
設定情報のエクスポート
- Infrastructure as Code（IaC）のテンプレート
- CLI/APIによる設定出力
SOC報告書（SOC 1/SOC 2）の入手
- クラウドベンダーが提供する第三者保証報告書
- 自社で検証できない統制の代替証跡として活用

AWS CloudTrailログの取得例：

# 過去30日間のログイベントを取得
aws cloudtrail lookup-events \
  --start-time 2026-03-17T00:00:00Z \
  --end-time 2026-04-17T00:00:00Z \
  --output json > cloudtrail_events_20260317-20260417.json

実務上の留意点：

クラウドサービスでは、ログの保管期間がデフォルトで短く設定されていることがあります（例：AWS CloudTrailのイベント履歴は90日間）。長期保管が必要な場合は、S3バケットへのログ転送やログアーカイブの設定を事前に行っておくことが重要です。

Q3. 被監査部門から「証跡を出せない」と言われた場合、どう対応すべきですか？

IT監査において、被監査部門から証跡の提出を拒否される、または「存在しない」と言われるケースは珍しくありません。このような状況への対応策を紹介します。

状況別の対応アプローチ：

ケース1：技術的に取得できない場合

代替証跡の検討（例：ログがない場合は、ログ設定の画面キャプチャ＋設計書で代替）
補完的な手続きの実施（例：担当者へのヒアリング、実機での動作確認）
「証跡が取得できなかった」こと自体を記録として残す

ケース2：機密性を理由に出せない場合

閲覧のみで記録を取らない方法の提案
機密情報をマスキングした上での提出依頼
監査人との秘密保持契約（NDA）の締結

ケース3：業務負荷を理由に出せない場合

取得範囲の縮小（サンプリング件数の削減など）
取得タイミングの調整
監査人自身による取得（被監査側の立会いのもと）

証跡が入手できない場合の記録例：

## 証跡入手不可の記録

### 対象証跡
- 証跡名：特権ID利用申請書（過去1年分）
- 取得依頼日：2026年4月10日
- 回答日：2026年4月14日

### 入手不可の理由
被監査部門より「紙の申請書は保管期間（6ヶ月）経過後に廃棄しており、
2025年9月以前の申請書は存在しない」との回答あり。

### 代替手続き
1. 2025年10月以降の申請書（現存分）を証跡として取得
2. 特権ID利用ログと申請書の突合検証を実施
3. 申請書の保管期間が不十分である旨を指摘事項として記載

### 監査上の判断
入手できた証跡の範囲内で手続きを実施し、監査意見への影響は限定的と判断。
ただし、文書保管ルールの改善を提言事項として報告書に記載する。

実務上のポイント：

証跡が入手できない場合でも、「入手できなかった事実」と「その理由」を必ず記録に残しましょう。これにより、監査品質レビュー時に「手続きを省略した」のではなく「実施したが入手できなかった」ことを説明できます。

まとめ：効果的な証跡管理のために

本記事では、IT監査における証跡の残し方について、実務で活用できる8つのポイントを中心に解説しました。

本記事の要点：

事前計画の重要性：証跡収集は場当たり的ではなく、計画的に実施する
5W1Hの意識：スクリーンショットには日時・対象・取得者などの情報を含める
生データと加工データの両方を保管：トレーサビリティを確保する
事実と意見の分離：ヒアリング証跡では客観的事実と主観的意見を区別する
差分比較可能な形式での保管：継続監査に備えてテキスト形式を推奨
命名規則とフォルダ構成の標準化：大量の証跡を効率的に管理する
改ざん防止対策：ハッシュ値、電子署名、タイムスタンプの活用
品質レビューの実施：収集した証跡の十分性・適切性を確認する

IT監査の品質は、証跡の品質によって大きく左右されます。本記事で紹介したノウハウを活用し、信頼性の高い監査を実現していただければ幸いです。

次のステップとして推奨する取り組み：

自組織の証跡管理ルールの見直し・文書化
証跡収集ツール・テンプレートの整備
チーム内での証跡品質に関する勉強会の実施

IT監査やセキュリティ監査に関するご質問があれば、コメント欄でお気軽にお寄せください。今後も実務に役立つ情報を発信していきます。

*本記事は2026年4月時点の情報に基づいています。法規制や技術仕様は変更される可能性がありますので、最新情報をご確

はじめに：なぜIT監査の証跡が重要なのか#

背景・概要：IT監査における証跡とは#

証跡（エビデンス）の定義#

証跡が求められる理由#

IT監査特有の課題#

具体的な手順と要点：実務で使える8つのポイント#

ポイント1：証跡収集計画を事前に策定する#

ポイント2：スクリーンショットは「5W1H」を意識して取得する#

ポイント3：ログ証跡は「生データ」と「加工データ」の両方を保管する#

ポイント4：ヒアリング証跡は「事実」と「意見」を分けて記録する#

ポイント5：設定ファイルは「差分比較」ができる形式で保管する#

ポイント6：証跡の命名規則とフォルダ構成を標準化する#

ポイント7：電子署名・タイムスタンプを活用して改ざん防止を図る#

ポイント8：証跡のレビューと品質チェックを実施する#

よくある質問（FAQ）#

Q1. 証跡の保管期間はどのくらいが適切ですか？#

Q2. クラウドサービスの監査証跡はどのように取得すればよいですか？#

Q3. 被監査部門から「証跡を出せない」と言われた場合、どう対応すべきですか？#

まとめ：効果的な証跡管理のために#