---
type: guideline
title: ログ取得・分析の目的設定に関する基本指針
source: デジタル庁
ds_code: ds-222
category: security
updated: 2026-03-31
source_url: https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/1548903d/20260331_resources_standard_guidelines_technical_report_01.zip
---

# ログ取得・分析の目的設定に関する基本指針

表 2-1 の「ログ取得・分析の目的設定」で定義したステップに沿って、ログ取得・分析の目的を設定する際の基本指針を示す。

## ログの取得・分析目的の明確化

本書では、ログ取得・分析の目的として、主に「脅威の検知・対応」を扱う。脅威の検知・対応とは、サイバー攻撃等の脅威をログから発見し、適切に対処する一連の活動を指す。具体的には、脅威及びその兆候の検出、被害範囲・攻撃経路の特定、封じ込め策の検証、復旧後のシステム稼働状況確認、原因究明等が含まれる。これらの活動はいずれもセキュリティインシデント対応において重要であるが、本書では、セキュリティインシデントの被害を最小限に抑えるために最も重要な初動対応として、「脅威及びその兆候の検出」を具体的な目的として定めて解説する。

なお、ログ取得・分析の目的は脅威の検知・対応に限定されるものではない。システムの健全性の確認を目的とする場合や、監査を目的とする場合等、多様な目的が存在する。ログ取得・分析を実施する際は、各システムを取り巻く状況や要件に応じて、何のために取得・分析するのかを明確にすることが重要である。

参考として、以下に「脅威の検知・対応」以外の主要な目的とその具体例を示す。

表 3-1ログ取得・分析のその他の主要目的と具体例

<table>
<colgroup>
<col style="width: 26%" />
<col style="width: 73%" />
</colgroup>
<thead>
<tr>
<th>目的</th>
<th>具体例</th>
</tr>
</thead>
<tbody>
<tr>
<td>システムの健全性の<br />
確認</td>
<td><ul>
<li><p>資産インベントリの補完</p></li>
<li><p>構成設定の逸脱等を伴う脆弱な資産の特定</p></li>
<li><p>アクセス制御や認証機能の正常性確認</p></li>
<li><p>パッチ適用状況の監視</p></li>
</ul></td>
</tr>
<tr>
<td>監査</td>
<td><ul>
<li><p>セキュリティ対策の有効性評価や改善点の特定</p></li>
<li><p>監督者の意思決定補助</p></li>
</ul></td>
</tr>
</tbody>
</table>

## 目的及び対象システムの特性に応じた分析事象・観点の決定

分析事象・観点を適切に検討するためには、第一に、目的に応じた事象、今回の場合は検知したい脅威及びその兆候を具体的かつ明確に決定することが必要である。情報システムに影響を与える脅威は、システムの特性に応じて異なるため、ログ取得・分析の目的の検討に先立ち、対象システムにおいて想定される脅威を適切に洗い出すために脅威分析[^2]を行うことが求められる。また、検知したい脅威及びその兆候は、監視対象のシステムの特性も考慮して決定することが求められる。第二に、決定した脅威及びその兆候について、When（いつ）、Where（どこで）、Who（誰が）、What（何を）、Why（なぜ）、How（どのように）という5W1Hの考え方を参考に分析観点を整理することが有用である。これらを行うことで、分析に必要な情報を網羅的に整理することが可能となる。「脅威及びその兆候の検出」に関する分析観点を具体化した一例を以下に示す。

表 3-2 脅威及びその兆候に関する分析観点（5W1H）

<table style="width:100%;">
<colgroup>
<col style="width: 9%" />
<col style="width: 33%" />
<col style="width: 56%" />
</colgroup>
<thead>
<tr>
<th>5W1H</th>
<th>概要</th>
<th>具体的な着眼点</th>
</tr>
</thead>
<tbody>
<tr>
<td>When</td>
<td>脅威若しくはその兆候の発生時刻</td>
<td><ul>
<li><p>いつアクセスが発生したか</p></li>
<li><p>いつ異常な操作が行われたか</p></li>
</ul></td>
</tr>
<tr>
<td>Where</td>
<td>脅威の対象となったシステム/コンポーネント</td>
<td><blockquote>
<p>どのシステムで事象が発生したか（VPN装置、CMS、DB、PC等）</p>
</blockquote></td>
</tr>
<tr>
<td>Who</td>
<td>攻撃者の情報</td>
<td><ul>
<li><p>どのIPアドレスから接続されたか</p></li>
<li><p>どのユーザIDで操作されたか</p></li>
<li><p>どこにデータが送信されたか</p></li>
</ul></td>
</tr>
<tr>
<td>What</td>
<td>発生した事象や被害状況</td>
<td><ul>
<li><p>どのような操作が行われたか</p></li>
<li><p>どのような通信が発生したか</p></li>
<li><p>システムにどのような影響があったか</p></li>
</ul></td>
</tr>
<tr>
<td>Why</td>
<td>攻撃者の動機や意図</td>
<td><blockquote>
<p>何を目的とした攻撃か（金銭目的、要機密情報窃取、ハクティビズム（政治的、社会的な主張等））</p>
</blockquote></td>
</tr>
<tr>
<td>How</td>
<td>攻撃者が利用したテクニック</td>
<td><blockquote>
<p>どのような攻撃手法が用いられたか（DDoS、マスカレーディング、XSS等）</p>
</blockquote></td>
</tr>
</tbody>
</table>

ただし、Why、Howの要素は、検証に時間を要する、若しくは、そもそも特定が困難な場合が多い。よって、脅威及びその兆候を検知するための分析観点を具体化する際は、まずWhen、Where、Who、Whatの要素を優先する必要がある。これらの分析観点を具体化することにより、ログの取得や保存・保全、点検・分析といった後続のプロセスで、円滑な設計や実装の検討が可能になる。