JPCERT/CCは2026年11月11日、外部の調査会社に依頼したインシデント調査の報告書を、依頼した側と書く側が同じ物差しで確認するための「インシデント調査報告書チェックリスト」を公開しました。依頼する組織向けは58項目、報告書を書く調査担当者向けは76項目です。この記事では、2つのチェックリストの構成と、発注前に合意しておく項目、受け取った報告書をレビューする手順を順番に整理した解説です。チェック結果をCSVで管理するPythonスクリプトと、報告書のIoC一覧を監視基盤へ入れるための変換コードも載せています。内容は2026年11月12日時点の公開資料にもとづきます。
まとめ：受領した報告書はユーザー向けの第2章23項目から当てて不足を差し戻す
報告書を受け取ったら、まずユーザー向けチェックリストの第2章「調査結果（報告書等）のレビュー」にある23項目を当ててください。合意した調査目的ごとに答えか「答えられない理由」が書かれているか、主要な結論に証拠IDやログ抜粋などの根拠が付いているか、の2点が欠けていれば、その報告書は経営判断にも外部への説明にも使えません。不足は項番を添えて調査会社へ差し戻します。
差し戻しで揉めないためには、調査を始める前に合意しておくことが有効です。第1章の10項目で目的・対象範囲・報告書に入れる5項目を決め、メールなど記録の残る形で受け取っておけば、レビューの基準がそのまま契約上の合意になります。調査会社の選び方や費用相場など依頼前の検討は、フォレンジック調査とは？種類・流れ・費用の実額と調査会社の選び方で整理しています。
「判断できない」と書かれた項目は、それだけで不備にはなりません。どのログが足りず、何が残るリスクなのかまで書かれていれば受け入れてよく、書かれていなければ差し戻す。この線引きを本文の後半で具体的に示します。
JPCERT/CCのインシデント調査報告書チェックリストの構成と公開形式
チェックリストはJPCERT/CCの公開告知から、GitHub Pagesのインシデント調査報告書チェックリストへ誘導される形で配布されています。ランサムウェアや情報漏えいの調査を外部へ委託する組織が増えた一方、初めて対応する組織は調査の妥当性や収束の判断に迷う、というのが作成の背景です。
ユーザー向け58項目とレポーター向け76項目の役割分担と章立て
チェックリストは読み手ごとに2本に分かれています。調査を依頼する組織が使う作成依頼時のチェックリスト（ユーザー向け）と、調査会社の担当者が使う作成時のチェックリスト（レポーター向け）です。項番の数をMarkdown版から数えると、次のようになります。
| 文書 | 章 | 項目数 | 使う時点 |
|---|---|---|---|
| ユーザー向け | 1 調査方針の合意 | 10 | 発注前 |
| ユーザー向け | 2 調査結果のレビュー | 23 | 報告書の受領時 |
| ユーザー向け | 3 詳細確認ポイント（参考） | 25 | 章ごとの精読時 |
| レポーター向け | 1〜3 合意・証拠保全・報告書 | 69 | 調査と執筆の全期間 |
| レポーター向け | 4 付属資料 | 7 | 納品時 |
レポーター向けの69項目には「必須」41、「推奨」18、「任意」10の区分が付いています。依頼する側も、調査会社が必須項目を満たしているかを確かめる目的でレポーター向けを読んでおくと、レビューの指摘が具体的になります。
HTML・Markdown・42ページのPDFサンプルの3形式とCC BY-SA 4.0
配布形式はHTML、Markdown、PDFの3つです。HTML版はブラウザ上でチェックを付けられ、Markdown版は社内の文書管理やGitで差分を取る用途に向きます。PDFのインシデント調査報告書サンプルは42ページで、VPN装置からの侵入を想定した架空の組織の最終報告書として、調査概要・エグゼクティブサマリー・調査結果・対象別の詳細・推奨対策と、IoC一覧やMITRE ATT&CK対応表などの付録AからEまでを収めています。
ライセンスはクリエイティブ・コモンズ 表示-継承 4.0 国際です。自社の発注仕様書や監査手順に取り込んで改変することもでき、その場合は出典を表示し、改変した部分を同じライセンスで公開する条件に従います。原稿はGitHubのJPCERTCC/ir_report_checklistで管理されているため、改訂の有無はリポジトリの履歴で追えます。
対象はマルウェア感染を伴うネットワーク侵害で内部不正には合わない項目がある
チェックリストが想定しているのは、マルウェア感染などを伴う外部からのネットワーク侵害です。従業員による持ち出しのような内部不正を疑う調査では、初期侵入やC2通信の項目がそもそも当てはまりません。サンプルPDFの冒頭も、内部不正の報告書は目的や記載内容が大きく異なると断っています。
もう1つの前提は、このチェックリストで報告書の正しさまでは判定できない点です。ユーザー向けの冒頭には、調査の技術的な品質や再発防止策の妥当性を精査するには専門知識が必要で、懸念があればJPCERT/CCなどの専門家へ相談するよう書かれています。チェックリストが見るのは「書かれているか」であり、「中身が合っているか」は別の確認が要ります。
調査を発注する前に合意する10項目とメールで残すべき決定事項
ユーザー向け第1章の10項目は、調査会社と最初に打ち合わせる議題の一覧として使えます。全部を同じ重さで扱う必要はありません。報告書の質を左右するのは、目的・優先順位・報告書の中身の3つを先に決めたかどうかです。
調査目的と優先確認事項を決めるときに復旧と証拠保全がぶつかる場面
項番1-1と1-2では、何を明らかにする調査なのかと、侵入経路の特定・侵害範囲の特定・情報漏えいの有無・封じ込め・復旧支援のうち何を優先するかを合意します。ここで迷うのが、業務の再開を急いでサーバーを初期化すると証拠が消える場面です。
チェックリストは、復旧を優先すれば証拠が失われ、調査を優先すれば業務再開が遅れるという影響を説明してもらったうえで判断するよう求めています。レポーター向けの1-2には、証拠保全だけを先に済ませて詳細調査を後日に回すという選択肢の記載もあります。侵入経路や漏えいの有無は、ログが足りなければ最後まで特定できない場合もあるため、注意が必要です。その可能性を発注前に聞いておくと、報告書の「判断できない」に驚かずに済みます。
調査報告書に最低限入れる5項目と簡易報告で済ませてよい用途の条件
項番1-6が挙げる最低限の中身は、エグゼクティブサマリー、初期侵入の原因、影響範囲、被害内容、再発防止策の5つです。監督官庁・保険会社・取引先への説明、被害公表、法的対応、監査に使う予定があるなら、正式な報告書を依頼します。
個人データの漏えいが疑われる事案は、個人情報保護委員会への報告に報告書の記載を使うことになります。速報と確報の期限は個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務で整理しており、報告書の納期をこの期限から逆算しておくと手戻りが減ります。
反対に、報告書の用途が決まっておらず、確認したいことが明確なら、口頭説明や簡易報告で足りると項番1-3は述べています。正式な報告書を作らない場合も、その理由と最終成果物として何を受け取るかは合意します。
調査会社から速報を受ける4つの条件と報告の頻度を上げすぎない理由
項番1-7は、定例の中間報告とは別に、速報や臨時報告を受ける条件を4つ挙げています。
- 新たな侵害対象が確認されたとき
- 情報漏えいの評価が変わったとき（漏えいを確認した等）
- 新しい事実で封じ込めが不十分と分かり、復旧の進め方を見直すとき
- 調査範囲、追加費用、完了予定の変更が必要になったとき
同じ項番に、報告の機会を増やしすぎると調査の進捗を妨げるとの注意もあります。毎日の定例会を求めるより、この4条件で必ず連絡をもらう取り決めにして、連絡手段（メールかオンライン会議か）を先に決めておく方が、調査担当者の時間を分析に回せます。合意した内容は項番1-10のとおり、口頭で済ませずメールなど記録の残る形で受け取ってください。
受領した報告書をレビューする手順とチェック結果をCSVで管理する方法
報告書が届いたら、ユーザー向け第2章の23項目を1つずつ当て、該当ページと質問を書き留めていきます。複数の部署で分担するなら、チェックの状態をファイルで受け渡せる形にしておくと便利です。
チェックリスト画面のlocalStorage保存とJSON出力の仕様を押さえる
HTML版のチェックリストは、付けたチェックをブラウザのlocalStorageにir-checklist:checklist_for_customer:checksというキーで保存します。サーバーへは送られないため、別の端末や別の担当者とは共有されません。
共有したいときは、画面上部のボタンでチェック結果をJSONとして書き出します。2026年11月12日時点のHTMLのスクリプトを読むと、ファイル名はchecklist_for_customer-result.jsonで、中身は次の形です。読み込み側は文書IDが違うファイルを拒否し、原稿の版が違う場合は項番が一致する項目だけを読み込むか確認を求めます。
{
"format": "ir-checklist-state",
"documentId": "checklist_for_customer",
"exportedAt": "2026-11-12T00:00:00.000Z",
"checks": { "1-1": true, "1-2": true, "2-1": true }
}項番をキーにした単純な構造なので、表計算ソフトや社内のチケットへ転記する処理を簡単に書けます。次のスクリプトはこのJSONを入力に使います。
Markdown版から確認シートを作るPythonスクリプトの実行手順
レビューでは「チェックが付いたか」だけでなく、報告書のどのページで確かめたか、調査会社に何を聞くかを項目ごとに残したくなります。次のスクリプトはユーザー向けのMarkdownを取得して表の行を拾い、58項目のCSVを作ります。引数に前節のJSONを渡すと、確認済みの項目に「済」を入れる仕組みです。
import csv, json, re, sys, urllib.request
URL = "https://jpcertcc.github.io/ir_report_checklist/markdown/checklist_for_customer.md"
ROW = re.compile(r"^\|\s*([0-9][0-9.\-]*)\s*\|\s*([^|]+?)\s*\|")
def load_rows():
req = urllib.request.Request(URL, headers={"User-Agent": "checklist-review/1.0"})
text = urllib.request.urlopen(req, timeout=30).read().decode("utf-8")
section = ""
for line in text.splitlines():
if line.startswith("#"):
section = line.lstrip("# ").strip()
m = ROW.match(line)
if m:
yield {"項番": m.group(1), "章": section, "項目": m.group(2)}
checks = {}
if len(sys.argv) > 1:
with open(sys.argv[1], encoding="utf-8") as f:
checks = json.load(f).get("checks", {})
rows = list(load_rows())
with open("review_sheet.csv", "w", newline="", encoding="utf-8-sig") as f:
w = csv.DictWriter(f, fieldnames=["項番", "章", "項目", "確認", "該当頁", "質問"])
w.writeheader()
for r in rows:
w.writerow({**r, "確認": "済" if checks.get(r["項番"]) else "", "該当頁": "", "質問": ""})
todo = [r["項番"] for r in rows if not checks.get(r["項番"])]
print(f"{len(rows)}項目を書き出し、未確認{len(todo)}件: {', '.join(todo[:10])}")Python 3.14で、1-1・1-2・2-1の3つにチェックを付けたJSONを渡して実行すると、出力は次のとおりでした。
$ python checklist_to_csv.py checklist_for_customer-result.json
58項目を書き出し、未確認55件: 1-3, 1-4, 1-5, 1-6, 1-7, 1-8, 1-9, 1-10, 2-2, 2-3CSVはExcelで開けるようBOM付きのUTF-8で書いています。第1章の10項目は発注前の確認なので、受領時のレビューでは章の列で第2章と第3章に絞り込んでから配ると、担当者が迷いません。原稿が改訂されたら同じスクリプトを流し直し、項番の増減を前回のCSVと比べます。
証拠IDとハッシュ値で主要な結論の根拠を追跡する確認コマンド
レビュー項目2-5は、主要な結論ごとに証拠ID・ログ抜粋・対象システム・日時など、根拠を追える情報があるかを問います。レポーター向けの2-8と2-9は、すべての証拠に一意の証拠IDを付け、証拠一覧で証拠ID・ファイル名・対象機器・取得日時・ハッシュ値が対応しているかを確認するよう求めています。
保全したディスクイメージやログを報告書と一緒に受け取ったなら、証拠一覧のハッシュ値と手元のファイルが一致するかを確かめます。WindowsとLinuxの標準コマンドで足ります。
# Windows（PowerShell）
Get-FileHash -Algorithm SHA256 .\evidence\* | Format-Table Hash, Path
# Linux：証拠一覧から「ハッシュ値 ファイル名」の形式で作ったファイルを照合
sha256sum -c evidence_sha256.txt証拠一覧のハッシュ値が報告書と食い違う、あるいは一覧そのものが無い場合は、項番2-5を満たしていないとして差し戻します。保全手順の記録項目は、デジタル・フォレンジック研究会の証拠保全ガイドライン第10版が詳しく、レポーター向けの2-1もこのガイドラインか同等の手順を参照するよう書いています。
報告書のIoC一覧をSIEMやEDRの照合に使うためのdefang解除と形式確認
報告書に載るIoC（侵害の痕跡を示すIPアドレス・ドメイン・URL・ハッシュ値）は、読むだけでなく自社の監視に流し込んで初めて役に立ちます。ユーザー向けの2.3-3も、報告書とは別にテキストやExcelでIoCだけを受け取ると、システムへの適用が容易になる場合があると書いています。
IoCのdefang表記の3つの型と監視基盤へ入れる前の戻し方
レポーター向けの3.1-5は、攻撃に関わるIPアドレスやドメインを203[.]0[.]113[.]10、example[.]com、hxxps://example[.]com/のようなdefang形式で書くことを必須にしています。誤ってクリックして感染したり、攻撃者に調査を気付かれたりするのを防ぐためです。
そのままではSIEMやEDRの検索条件に使えないため、取り込む前に元の表記へ戻し、種別の記載ゆれも機械的に確かめます。次のスクリプトは「種別,値,概要」の3列で受け取ったCSVを変換します。
import csv, ipaddress, re, sys
def refang(value):
v = re.sub(r"^hxxp", "http", value.strip(), flags=re.I)
return v.replace("[.]", ".").replace("[:]", ":")
def classify(value):
try:
ipaddress.ip_address(value)
return "ip"
except ValueError:
pass
if re.fullmatch(r"[0-9a-fA-F]{64}", value):
return "sha256"
if re.fullmatch(r"https?://\S+", value):
return "url"
if re.fullmatch(r"(?:[a-zA-Z0-9-]+\.)+[a-zA-Z]{2,}", value):
return "domain"
return "unknown"
with open(sys.argv[1], encoding="utf-8-sig") as src, \
open("ioc_for_siem.csv", "w", newline="", encoding="utf-8") as dst:
w = csv.writer(dst)
w.writerow(["type", "value", "note", "check"])
for row in csv.DictReader(src):
value = refang(row["値"])
kind = classify(value)
w.writerow([kind, value, row["概要"], "OK" if kind == row["種別"] else "種別不一致"])文書用の予約アドレスで作った5行を入れると、5行目の「domain,198[.]51[.]100[.]7」だけが種別不一致になりました。値はIPアドレスなのに種別がドメインと書かれた例です。こうした記載ゆれは、そのまま取り込むと検索条件の型が合わず、照合から漏れます。変換後のファイルは自社の監視基盤にだけ置き、ブラウザでは開かないでください。
種別・値・概要がそろわないIoC一覧を差し戻す基準と照合の手順
ユーザー向けの2.3-2は、各IoCに種別・値・概要が付いているかを確認項目にしています。値だけが並んだ一覧は、どの通信先がC2サーバーでどれが配布元なのかが分からず、遮断の優先順位を付けられません。概要が欠けていれば差し戻します。
取り込んだIoCで社内のログを検索する作業そのものは、プロキシやDNS、ファイアウォールのログを順に当たる地道な手順です。ログの種類ごとの確認方法は不正アクセスの調べ方｜ログの確認方法と痕跡を見つけるコマンド例、IoCとYARAルールでの照合例はUNC2814（DARK CASTLE）とGRIDTIDEのIoC・YARA照合手順にまとめています。報告書にMITRE ATT&CKの対応表が付いていれば、検知ルールを追加すべき攻撃手法もそこから選べます。
報告書を差し戻す不備と受け入れてよい「判断できない」の線引き
チェックリストは「書かれているか」を確かめる道具なので、項目が埋まっていても使えない報告書はあります。依頼した側が判断に迷いやすい3つの場面について、受け入れる条件と差し戻す条件をはっきりさせておきます。
「漏えいなし」と書いてあっても調べたログが示されない報告書は差し戻す
情報漏えいの結論は、外部への説明と個人情報保護委員会への報告に直結します。詳細確認ポイントの3.2.3-3は、結論を「漏えいを確認した」「漏えいした可能性がある」「痕跡は確認されなかった」「判断できない」の4つのどれかで明示するよう求め、3.2.3-4はそのために確認したログやデータの記載を求めています。
「漏えいの痕跡は確認されなかった」とだけ書かれ、どの期間のどの通信ログを見たのかが無い報告書は受け入れません。プロキシのログが30日分しか残っていなかったなら、それより前の持ち出しは見えていないからです。逆に「判断できない」でも、不足したログ、残るリスク、追加調査で確認できる可能性（2-7と2-8）が書かれていれば受け入れてよく、その内容を外部への説明にそのまま使えます。
再発防止策が一般論だけで調査結果の番号と結び付かないときの直し方
「多要素認証の導入」「パッチ管理の徹底」だけが並ぶ再発防止策は、どの調査結果に対応するのかが分からず、優先順位も決められません。ユーザー向けの2.2-1は対応する調査結果の明記を、2.2-3は当該事案で確認された内容にもとづく対策を求めています。
サンプルPDFの封じ込め・復旧の表は、対策ごとに「対応する調査結果」の欄に3.1や4.1といった章番号を書き、優先度の判断基準まで別表で示しています。この形を見本として示し、「VPN装置のファームウェア更新は3.1の初期侵入に対応」のように章番号を付け直してもらってください。そのうえで高優先度の対策から、自社で直すもの・委託先に頼むものを振り分けます。
調査報告書のレビューで社内では判断しきれない技術事項を外部の専門家に回す条件
侵入経路の推定が妥当か、調査範囲の選び方に漏れがないか、といった中身の評価は、チェックリストでは判定できません。次のどれかに当たるときは、社内だけで結論を出さず、調査会社とは別の専門家の意見を取ってください。
- 報告書を監督官庁・保険会社・取引先へ提出する予定がある
- 初期侵入の原因が「推測」のまま、同じ機器を使い続ける判断を迫られている
- 再発防止策に、公開しているWebシステムや業務システムの改修が含まれている
3つ目は、報告書を読む段階から直す段階へ移るところです。侵入口になった公開システムに同種の穴が残っていないかは、脆弱性診断・セキュリティ診断で洗い出してから改修の範囲を決めると、報告書の指摘だけを塞いで別の入口を残す事態を避けられます。
インシデント調査報告書チェックリストの使い方でよくある質問と回答
公開されたチェックリストを使い始めるときに出てきやすい疑問に、2026年11月12日時点の公開資料の範囲で答えます。
チェックリストは誰でも無料で使えますか？社内様式に改変してもよいですか？
GitHub Pagesで公開されており、誰でも無料で閲覧・ダウンロードできます。ライセンスはCC BY-SA 4.0なので、社内の発注仕様書や監査手順へ組み込む改変も可能です。改変した場合は出典を表示し、改変版を同じライセンスで提供する条件が付きます。JPCERT/CCは改変部分について責任を負わない旨も明記しているため、改変版には元の版との違いを書き添えておくと後で困りません。
インシデント調査報告書のサンプルやひな形はどこで入手できますか？
JPCERT/CCがチェックリストと同時に、42ページのPDFサンプルを公開しています。架空の組織がVPN装置から侵入された想定で、調査概要からエグゼクティブサマリー、対象別の調査結果、推奨対策、IoC一覧などの付録までを収めています。記載のIPアドレスやドメインには実際の攻撃に使われたものが含まれるとの注意書きがあるので、アクセスしないでください。
調査会社がチェックリストに沿った報告書を出してくれない場合はどうしますか？
発注前の打ち合わせで、ユーザー向け第1章の項番1-6が挙げる5項目を報告書に含めることを合意し、メールで残してください。合意が無いまま納品された報告書に後から全項目を求めると、追加費用の交渉になりがちです。既に納品済みなら、第2章の項番を添えて不足箇所を質問し、問い合わせ対応の範囲と期間（項番1-9）を確認します。
内部不正や情報の持ち出しの調査にもこのチェックリストを使えますか？
そのままは使えません。チェックリストはマルウェア感染などを伴うネットワーク侵害を想定しており、初期侵入やC2通信など内部不正では当てはまらない項目があると明記されています。調査目的と範囲の合意、根拠の追跡、判断できない事項の扱いといった第1章と第2章の考え方は流用できるので、当てはまらない項番を除いて使ってください。
報告書のどこから読めば経営層への報告に間に合いますか？
最初に読む箇所はエグゼクティブサマリーです。詳細確認ポイントの3.1-1から3.1-6が、発覚日時ときっかけ、侵害されたシステムやアカウント、確認された影響、確認済み・可能性・判断不能の区別、残るリスク、直ちに必要な対応を求めているので、この6点が揃っているかを先に確かめます。揃っていれば、サマリーだけで経営判断の材料になります。
関連記事
- CSIRT（シーサート）とは？役割・SOCや情シスとの違い、体制の種類と構築手順：調査会社との窓口になる社内体制の作り方です。
- EDRとは？EPP・XDRとの違いと検知の仕組み・導入判断を実装者向けに解説【2026年時点】：調査対象になるEDRの記録とその限界を整理しています。
- インシデント管理とは？ITIL準拠のプロセスと監視・オンコールの実装を運用目線で解説【2026年版】：報告書を受けた後の再発防止を運用の仕組みに落とす方法です。
- Qilinランサムウェアとは：Talosが確認した侵入から暗号化までの手口と痕跡を調べるコマンド：報告書のタイムラインに出てくる攻撃手順の具体例です。
- Renta!はいつ再開？不正アクセスでメールアドレス等が流出したおそれ・再開時のパスワード再設定と運営側の対応：証拠保全と段階的な再開を判断した事例です。
