「JPCERT/CCの『インシデント調査報告書チェックリスト』から見える、事故の前にやっておくべき5つのこと」

2026年11月11日、JPCERTコーディネーションセンター（JPCERT/CC）が「インシデント調査報告書チェックリスト」を公開しました。ランサムウェア被害や情報漏えいが起きたとき、フォレンジック調査を外部の調査会社に頼むのはいまや当たり前になっています。ところが、頼む側の多くは初めてのインシデント対応で、「何をお願いすればいいのか」「届いた報告書は妥当なのか」「もう収束したと言っていいのか」を判断できずに困っている。今回のチェックリストは、まさにそこを埋めるための資料です。

中身を読んでみると、単に報告書の書き方をまとめたものではありませんでした。「調査を頼む前に何を決めておくべきか」が細かく書かれていて、裏返せば「平時のうちに準備しておかないと、いざというときに困ること」の一覧にもなっています。今回はチェックリストの内容を整理したうえで、そこから見えてくる「事業者がいまのうちにやっておきたいこと」を考えてみます。

公開された資料の全体像

資料はGitHub上で公開されており、次の3点で構成されています。

チェックリストはブラウザ上でそのままチェックでき、検索・絞り込み・進捗表示・結果の保存や印刷にも対応しています。入力内容はブラウザ内に保存され、外部には送信されないと明記されているので、社内の実案件で使っても安心です。Markdown版の原稿も公開されていて、ライセンスはクリエイティブ・コモンズ表示-継承4.0（CC BY-SA 4.0）。自社の調達仕様やインシデント対応手順書に組み込みやすい形になっています。

なお、チェックリスト自体にも「インシデント調査や報告書の完全な正しさを保証するものではない」と明記されています。調査の技術的な品質やエビデンスの妥当性の精査には専門知識が必要で、不安があればJPCERT/CCなどの専門家に相談してほしい、という位置づけです。

ユーザー向け：調査を「頼む前」に合意すべき10項目

被害組織向けのチェックリストは、前半が「調査方針の合意」、後半が「報告書のレビュー」です。前半の10項目を要約すると次のとおりです。

特に1-7では、「新たな侵害対象が見つかった」「情報漏えいの評価が変わった」「封じ込めが不十分とわかった」「調査範囲や費用、完了予定が変わる」といった場面で、定例を待たずに臨時報告をもらえるかを確認するよう勧めています。公表や監督官庁への報告のタイミングに直結する部分なので、見落とせないポイントです。

ユーザー向け：受け取った報告書のどこを見るか

後半のレビュー項目は、技術の専門家でなくても確認できる観点に絞られています。主なものを挙げます。

• 合意した目的への回答があるか：調査目的ごとに、答えか「答えられない理由」が書かれているか。
• サマリーと本文が矛盾していないか：エグゼクティブサマリー、各章の説明、タイムラインの記述が食い違っていないか。
• 調査対象「外」が書かれているか：調べたシステム・ログ・期間だけでなく、調べなかったものも明記されているか。
• 根拠を追えるか：主要な結論に、証拠ID、ログの抜粋、対象システム、日時などが添えられているか。
• わからなかったことの扱い：ログ不足や暗号化、ファイル削除で調べられなかった事項について、不足情報と残るリスクが書かれているか。
• 再発防止策が自社向けか：一般的な推奨事項の羅列ではなく、今回の調査で確認された内容に基づく対策になっているか。
• IoCが使える形で渡されているか：侵害の痕跡（IoC）が種別・値・概要つきで記載され、できればテキストやExcelで別途受け取り、監視や検索にそのまま使えるか。

さらに参考として、章ごとの詳細な確認ポイントも用意されています。たとえば影響範囲については、調べた各システムが「侵害を確認した」「痕跡は確認されなかった」「ログ不足などで判断できない」のどれなのかが明示されているかを確認します。情報漏えいについても同様に、次の4つのどれに当たるのかがはっきり書かれているかが問われます。

1. 漏えいを確認した
2. 漏えいした可能性がある
3. 漏えいを示す痕跡は確認されなかった
4. 判断できない

「漏えいの痕跡は確認されなかった」と「判断できない」は、被害公表の文面でもまったく意味が違います。この区別を報告書の段階で求めておくことは、社外への説明の正確さに直結します。

レポーター向け：調査会社に求められている水準

調査を受ける側のチェックリストは、事前合意、証拠保全、報告書、付属資料の4部構成です。依頼する側から見ても、「プロに何を期待してよいか」の物差しになります。印象的だった項目をいくつか紹介します。

• 直接証拠がないことを断定しない（必須）：直接的なログやエビデンスがない事項は、推測や仮説だとわかるように書く。初期侵入を断定できない場合は、その理由（ログの欠損、証拠不足など）を書く。
• 経営層が判断できるサマリー（必須）：何が起きたか、影響、未解決事項、直ちに必要な対応を、非技術者が理解できるように書く。
• 証拠IDの一意な付与（推奨）：すべての証拠にIDを振り、報告書の結論と対応づける。被害組織から再確認を求められたときに説明しやすくなる。
• タイムゾーンの明記（必須）：海外拠点などで複数のタイムゾーンが混ざる場合はUTCで統一する。
• 業務を把握したうえで封じ込め策を提案する（必須）：停止できる時間やシステムの依存関係を把握できていない場合は、その旨と、提案を実施したときに想定される影響を書く。
• 攻撃関連のIPアドレスやドメインはdefang形式で書く（必須）：誤ってアクセスしないよう、自動でリンクにならない形に書き換える（下記の例）。

203[.]0[.]113[.]10
example[.]com
hxxps://example[.]com/

付属資料としては、証拠保全記録、侵害されたアカウントやホストの一覧、窃取された（疑いのある）データの一覧、IoC一覧、YARA・Sigma・SIEM検索クエリ、マルウェアの詳細分析、MITRE ATT&CKとの対応表が挙げられています。報告書サンプルも、VPN装置からの侵入、Active Directoryでの認証情報の悪用、ファイルサーバーへのマルウェア配置といった架空の事案を、証拠IDつきで記載していて、「良い報告書」の具体像がつかめます。

チェックリストから見える「いますべきこと」

ここからが本題です。このチェックリストは「インシデントが起きてから使うもの」に見えますが、実際の項目を並べてみると、事故が起きてからでは間に合わない準備がいくつも前提になっています。事業者がいまのうちに手をつけておきたいことを5つに整理しました。

1. 報告書を「誰に何のために見せるか」を先に決めておく

ユーザー向けチェックリストの最初の項目は「調査目的と報告書の利用目的」です。個人情報保護委員会などの監督官庁への報告、サイバー保険の請求、取引先や親会社への説明、被害公表。どれに使うかで、必要な報告書の形式も共有範囲も変わります。インシデントの最中にこれを一から議論するのは現実的ではありません。自社の業種で報告が必要になる先、加入している保険の条件、主要取引先との契約上の通知義務などを、平時に一覧にしておくと判断が早くなります。

2. 「判断できない」を減らすためにログを見直す

チェックリスト全体を通じて何度も出てくるのが、「ログ不足で判断できない」というケースです。侵入経路や情報漏えいの有無は、エビデンス不足で特定できない可能性があると最初から明記されています。そして調査会社がどれだけ優秀でも、存在しないログは調べられません。VPN装置、Active Directory、ファイルサーバー、クラウドの監査ログ、EDRなど、どのログをどこに何日分残しているかを棚卸ししておくことが、将来の報告書の質を決めます。侵入の時期がわからないと、より長い期間のログが必要になるという指摘もあります。

3. 調査会社を平時に選び、合意事項のひな形を用意しておく

ユーザー向けの10項目は、そのまま「調査依頼書」や「見積もり依頼」のひな形として使えます。事故が起きてから慌てて調査会社を探すのではなく、平時に候補を決めておき、このチェックリストの項目に沿って「どこまで対応してもらえるか」を確認しておくのがおすすめです。納品後の問い合わせ対応や追加費用、IoCを別ファイルで受け取れるかなど、契約前に聞いておきたいことがはっきりします。EDR製品のベンダーに調査を頼む場合は、その製品が集めた情報が調査の中心になる点もチェックリストで触れられています。

4. 「復旧優先か、調査優先か」を決める人を決めておく

復旧を急げば証拠が失われ、調査を優先すれば業務再開が遅れる。チェックリストはこのトレードオフを理解したうえで優先順位を決めるよう求めています。これは技術ではなく経営判断です。誰が決めるのか、判断のために何を説明してもらう必要があるのかを、インシデント対応計画の中で決めておく必要があります。あわせて、自社の業務やシステムの依存関係、止められる時間をまとめた資料があれば、調査会社がより現実的な封じ込め策を提案できます。

5. 報告書を受け取ったあとの「使い道」まで用意しておく

報告書を受け取って終わりではありません。IoCを監視や検索にすぐ使えるか、YARAやSigmaのルールを自社のSIEMやEDRに入れられるか、再発防止策を優先度順に実行する担当と予算があるか。受け取ったものを運用に回す体制がなければ、どれだけ良い報告書でも効果は半減します。また、報告書のレビューを社内の誰が担当するのかを決め、技術的な評価に不安がある場合の相談先（JPCERT/CCや別のセキュリティ事業者など）も確保しておきたいところです。

まとめ

JPCERT/CCの「インシデント調査報告書チェックリスト」は、調査を頼む側と書く側が同じ物差しを持つための資料です。依頼時の合意、報告書のレビュー、証拠の示し方までが具体的に整理されていて、初めてインシデントに直面した組織にとって心強い道しるべになります。

ただ、本当に価値があるのは、事故が起きる前に読んでおくことだと感じました。報告書の利用目的、ログの保存状況、調査会社との契約、復旧と調査の判断者、受け取った成果物を運用に回す体制。チェックリストの項目を自社に当てはめて「いま答えられないもの」を洗い出せば、それがそのまま平時に取り組むべき課題リストになります。まずはユーザー向けの10項目だけでも、社内のインシデント対応手順書と見比べてみてはいかがでしょうか。

本記事は、JPCERT/CCの公開資料（2026年11月12日時点のGitHub公開版）をもとに整理したものです。項目の要約は筆者によるもので、正確な文言は原資料をご確認ください。チェックリストの内容は今後更新される可能性があります。実際のインシデント対応では、必ず最新の公式資料を参照し、必要に応じて専門家にご相談ください。

参考情報

• 「インシデント調査報告書チェックリスト」公開のお知らせ（JPCERT/CC）
• インシデント調査報告書チェックリスト／報告書サンプル（JPCERT/CC、GitHub Pages）
• JPCERTCC/ir_report_checklist（GitHubリポジトリ）
• 侵入型ランサムウェア攻撃を受けたら読むFAQ（JPCERT/CC）
• インシデント対応とは（JPCERT/CC）
• インシデント相談・情報提供（JPCERT/CC）