はじめての方へ Genox Cybersecurity AIを3分でご紹介 → 24時間インシデント受付
Verdict trace

判定記録(トレース)の
読み方

Threat Correlatorは、判定ごとに何を見て、どのツールを呼び出し、どの根拠で結論を出したかを記録に残します。
公開できる実際の実行記録はまだないため、このページでは記録の構造を説明し、サンプルを一件、最初から最後まで読んでいきます。

Structure

一件の記録に含まれるもの

上から下へ読むと、判定ができあがった順序と同じになります。
一つの判定には複数のステップ(step)が付き、ステップごとに観察、ツール呼び出し、証拠、推論が一つのまとまりになっています。

フィールド内容読むときの確認ポイント
input_hash判定に使った入力一式全体のSHA-256再実行時に同じ入力を使ったかを、この値で照合します
sources入力の取得元(EDR、メールゲートウェイ、プロキシなど)と時間範囲欠けているソースがあれば、判定の範囲もその分狭くなります
steps[].observationそのステップで注目した事実元ログを要約した文なので、下の証拠と合っているかを確認します
steps[].tool_call呼び出したツール、引数、結果の要約時間範囲やホスト名などの引数が正しいかを確認します
steps[].evidence証拠ID、元データの場所、ハッシュ引用したログが元データに実在するかを自動照合した結果も付きます
steps[].reasoning証拠から結論に至った理由、ATT&CKの手法ID根拠の文はそれぞれ証拠IDを指している必要があります
verdict · confidence判定ラベル、リスク度、確信度と、確信度を下げた理由確信度が低い理由が書かれているかを確認します
recommended_actions推奨する対応と、承認の要否ホストの隔離とアカウントのロックは常に承認の対象です
approval承認者のロールID、承認・修正・却下、時刻、コメント承認までにかかった時間もここから分かります
versionsモデルのバージョン、プロンプトテンプレートのバージョン、ポリシーのバージョンプロンプトの文言が変わっただけでも、判定基準が変わったことになります
replay後日同じ条件で再実行した結果と、元の判定との差分文章は違っても構いません。ラベルとリスク度が同じかを確認します
Example trace

サンプル記録を一件、最初から読んでみます

サンプル記録 · 実際のお客様のデータや実行記録ではありません。MITRE ATT&CKに整理されているランサムウェア初期段階の手法(フィッシングの添付ファイル、PowerShellの実行、シャドウコピーの削除)をつなぎ合わせて当社が作成した記録です。ホスト名、アカウント、時刻、確信度はすべて説明用で、ドメインとIPには文書用に予約された値(.example、203.0.113.0/24)を使っています。

サンプル記録 · 実際のお客様のデータや実行記録ではありませんfin-ws-0412
1 観察マクロ付き添付ファイルのメールを受信 · T1566.00109:12
2 観察WINWORD.EXEがpowershell.exeを起動 · T1059.00109:14
3 観察vssadminでシャドウコピーを削除 · T149009:14
判定真陽性 · ランサムウェア実行の準備 · CRITICAL · 確信度 0.9109:15
承認ホスト隔離を承認(analyst-07)09:17
再実行ラベル · リスク度は一致、文章は一部異なる10/22

この記録でまず見るところ

まず、判定行の確信度が0.91で止まっている理由を見ます。このサンプルでは、ファイルの暗号化がまだ観察されていないこと、ダウンロードされた実行ファイルのハッシュが脅威インテリジェンスと一致しなかったことが書かれています。逆に、確信度だけが高く、下げた理由が空欄の記録であれば、そちらのほうを疑うべきです。

次は承認行です。ホストの隔離は、ポリシー上自動では実行されません。判定が出てから、アナリストが根拠を読んで承認するまでに2分あまりかかったことも、この記録から読み取れます。

ステップごとに読む

  1. メール受信(step 1)。メールゲートウェイのログに、billing@invoice-notice.exampleから届いたメールがあり、添付ファイルは견적서_1021.docm(「見積書」)です。AIはmail.search(message_id=…)でメール原本のメタデータを、intel.domain_whois("invoice-notice.example")でドメイン情報を照会しました。結果はドメイン作成から3日目。根拠の文は「マクロ付きOffice添付ファイルと新規ドメインの組み合わせ、T1566.001の可能性」で、証拠E1、E2を指しています。このステップだけでは判定を出していません。
  2. PowerShellの実行(step 2)。Sysmonのイベント ID 1(プロセス作成)に、親がWINWORD.EXE、子がpowershell.exe -NoP -W Hidden -enc JABjAD0A…の行があります。AIはedr.process_tree(host="fin-ws-0412", from="09:12", to="09:20")でプロセスツリーを取得し、エンコードされたコマンドをデコードして、https://203.0.113.45/u.ps1をダウンロードするコードであることを確認しました。baseline.parent_child(host, 30d)の照会では、このホストで過去30日間にOfficeアプリがPowerShellを起動したことはありませんでした。根拠はT1059.001、証拠はE3、E4です。
  3. シャドウコピーの削除(step 3)。Sysmonのイベント ID 11(ファイル作成)でC:\Users\user01\AppData\Local\Temp\upd.exeが作成され、20秒あまり後にイベント ID 1でvssadmin.exe delete shadows /all /quietが記録されました。親はupd.exeです。intel.hash_lookupは一致なしでした。根拠はT1490(Inhibit System Recovery、システム回復の妨害)で、ATT&CKのT1490の項目にも、暗号化の前にまずシャドウコピーを削除したランサムウェアの事例が複数掲載されています。
  4. 判定。真陽性、ランサムウェア実行の準備段階、リスク度CRITICAL、確信度0.91。確信度を下げた理由として「大量のファイル変更は未観察」「upd.exeのハッシュが脅威インテリジェンスと不一致」の2点が記載されています。
  5. 推奨する対応と承認。ホストのネットワーク隔離(承認が必要)、同じ添付ファイルのハッシュを持つメールの回収、送信元ドメインと203.0.113.45のブロック。隔離はanalyst-07が09:17に承認し、「ファイルサーバーへのSMBセッションの確認を依頼」というコメントを残しました。ブロック2件は、お客様と合意した自動対応ポリシーの範囲内のため、承認なしで実行されました。
  6. 再実行。翌日、同じinput_hash、モデルのバージョン、ポリシーのバージョンで再実行した結果、ラベルとリスク度は同じで、確信度は0.89、根拠の文の表現は一部異なりました。文章は比較の対象外のため、「一致」として記録されます。
Raw record

同じ記録を原文の形で見ると

上のサンプルを、記録の形式のまま短くして載せました。
フィールド名は説明用で、実際のエクスポート形式はリリース時にドキュメントとして公開します。

// サンプル記録 · 実際のお客様のデータや実行記録ではありません
{
  "trace_id": "VT-EXAMPLE-0001",
  "input_hash": "sha256:9f3a…c21e",
  "sources": [
    {"type": "mail_gateway", "range": "09:00~09:20"},
    {"type": "edr_sysmon",   "host": "fin-ws-0412", "range": "09:00~09:20"}
  ],
  "steps": [
    {"n": 1,
     "observation": "マクロ付き添付ファイル(견적서_1021.docm)、送信元ドメインは作成から3日目",
     "tool_calls": ["mail.search(message_id=…)", "intel.domain_whois(\"invoice-notice.example\")"],
     "evidence": [{"id": "E1", "ref": "mailgw/2026/10/21/09.log#L2207", "sha256": "1c0d…7be2", "verified": true},
                  {"id": "E2", "ref": "intel/whois/invoice-notice.example", "verified": true}],
     "reasoning": "E1+E2: スピアフィッシングの添付ファイルの可能性", "attack": ["T1566.001"]},
    {"n": 2,
     "observation": "WINWORD.EXE → powershell.exe -NoP -W Hidden -enc …",
     "tool_calls": ["edr.process_tree(host=\"fin-ws-0412\", from=\"09:12\", to=\"09:20\")",
                    "baseline.parent_child(host=\"fin-ws-0412\", window=\"30d\")"],
     "evidence": [{"id": "E3", "ref": "sysmon:EventID=1 RecordID=884213", "verified": true},
                  {"id": "E4", "ref": "baseline/fin-ws-0412/parent_child", "verified": true}],
     "reasoning": "E3: OfficeアプリがエンコードされたPowerShellを実行、E4: 過去30日間に前例なし",
     "attack": ["T1059.001"]},
    {"n": 3,
     "observation": "upd.exe作成後に vssadmin.exe delete shadows /all /quiet",
     "tool_calls": ["edr.process_tree(…)", "intel.hash_lookup(\"sha256:3b7e…a19f\")"],
     "evidence": [{"id": "E5", "ref": "sysmon:EventID=11 RecordID=884240", "verified": true},
                  {"id": "E6", "ref": "sysmon:EventID=1 RecordID=884251", "verified": true}],
     "reasoning": "E6: 復旧手段を削除、暗号化の前段階と判断", "attack": ["T1490"]}
  ],
  "verdict": {"label": "true_positive", "severity": "critical",
              "summary": "ランサムウェア実行の準備段階",
              "confidence": 0.91,
              "confidence_notes": ["大量のファイル変更は未観察", "upd.exeのハッシュが脅威インテリジェンスと不一致"]},
  "recommended_actions": [
    {"action": "isolate_host", "target": "fin-ws-0412", "requires_approval": true},
    {"action": "recall_mail", "match": "attachment_sha256", "requires_approval": false},
    {"action": "block", "targets": ["invoice-notice.example", "203.0.113.45"], "requires_approval": false}
  ],
  "approval": {"action": "isolate_host", "by": "analyst-07", "decision": "approved",
               "at": "2026-10-21T09:17:40+09:00", "comment": "ファイルサーバーへのSMBセッションの確認を依頼"},
  "versions": {"model": "correlator-model-x.y", "prompt_template": "triage-vNN", "policy": "auto-response-YYYY.MM"},
  "replay": {"at": "2026-10-22T10:05:12+09:00", "same_input_hash": true,
             "label_match": true, "severity_match": true, "confidence": 0.89,
             "text_diff": "根拠の文の表現が一部異なる"}
}

verifiedは、引用したログが元データの保管先に実在するかを自動照合した結果です。一つでもfalseがあれば判定は保留され、アナリストに引き継がれます。この照合の数え方は、AI判定の品質のページの「出力の捏造検知」に記載しています。

How to use it

記録を受け取った側で行うこと

判定記録は、Genoxだけが見る内部ログでは終わりません。
お客様のセキュリティチームや監査人が直接開いて読むことを前提に作っています。

監査対応

監査やインシデント調査で「なぜこのホストを隔離したのか」と聞かれたら、記録一件で答えられます。何を見たかはevidenceに、誰が承認したかはapprovalに、そのときどのモデルとポリシーで動いていたかはversionsにあります。証拠は場所とハッシュで残すため、元ログの保存期間を判定記録の保存期間とそろえておく必要があります。

誤検知の分析

誤検知と確定した判定は、どのステップでずれたのかを探します。ツール呼び出しの引数が誤っていたのか、ベースラインの照会結果が空だったのか、推論が証拠の範囲を超えていたのかは、stepを一つずつたどれば多くの場合見えてきます。当社が月次レポートに誤検知の事例を載せるときも、この記録をそのまま添付します。

ルールの改善

同じ理由で確信度が下がった判定が繰り返されていれば、収集範囲や検知ルールの見直しどころが分かります。上のサンプルでは、ファイルサーバーの監査ログがsourcesになかったため、横展開の有無を確認できませんでした。ポリシーを修正した後は、過去の判定を新しいポリシーのバージョンで再実行し、差分を確認します。

What's next

実際の記録は
準備ができしだい公開します

Research Labの隔離環境で公開済みの攻撃手法を再現し、Threat Correlatorが判定した記録を整理しています。お客様のデータが混ざらない実行記録がたまったら、このページに原文のまま掲載します。それまでは、このページの記録はすべてサンプルです。

公開する際のルール

  • 判定が外れた記録も、当たった記録と同じように掲載します
  • 再現に使った手法IDと再現手順をあわせて記載します
  • 記録ごとにモデル・ポリシーのバージョンを残し、バージョンが変われば再実行の結果を追記します
  • 隔離環境のホスト名とアカウントは、実際のお客様の環境と重ならないように作成します

Genoxのセキュリティ専門家に
ご相談ください。

お問い合わせ