SIEMのログ保存期間を、調査で遡る期間と結果を得るまでの許容時間から設計。即時検索と長期保管の違い、要件表、遅延ログ、復元テスト、容量試算の手順を一次資料とともに解説します。
SIEMのログ保存期間は、「何日残すか」だけでは決められません。不審な操作を後から調べる際、対象のログが残っていても、取り出す権限がない、検索に必要な項目が失われている、復元にかかる時間を把握していない状態では調査が止まります。
この記事では、情シス・SOCの担当者が、保存期間と検索方法を一緒に決める手順を整理します。製品の料金比較はSIEMの比較・費用、接続直後の確認はログ連携の受入テストで扱い、ここでは運用を始めた後の過去ログ調査に焦点を当てます。
保存期間は「調べたい期間」と「待てる時間」から決める
最初に決めるのは製品の設定値ではなく、調査の要件です。次の3点を、認証・端末・クラウド操作などのログごとに書き出してください。
どこまで遡るか：不審な事象に気づいた時点から、過去の何を確認する必要があるか。
いつまでに結果が必要か：対応中にすぐ検索するのか、翌営業日の調査でも間に合うのか。
何を説明するか：誰が、いつ、どの対象に、何をしたかを、どの項目で確認するか。
ACSCなどが共同公表したログ管理のガイダンスも、保持期間をリスクや適用される要件から決め、容量不足による上書きまで考慮するよう案内しています。標準設定をそのまま自社の要件とみなさないことが出発点です。出典：Best practices for event logging and threat detection
全社一律に「長く保存すればよい」と決めると、費用やアクセス管理の負担も増えます。業務上の必要性、社内規程、契約・適用要件を確認し、必要な情報と保存目的を明確にします。本記事では全組織に共通する保存日数を定めません。
すぐ検索する期間と、取り出して調べる期間を分ける
要件表には「保存期間」だけでなく、次の2つを別々に記入します。
即時検索の期間：通常の調査画面から、必要な時間内に検索結果を得られる期間。
長期保管を含む総期間：別の検索処理や復元手順を使う場合も含め、調査に利用できるデータを保持する期間。
名称は製品によって異なります。例えばAzure Monitor Logsは、テーブルのプランに応じて分析用保持と長期保持を区別し、Analytics・Basicの長期保持データには検索ジョブを使用します。Auxiliaryは扱いが異なるため、「アーカイブは必ず同じ方法で復元する」と一般化できません。出典：Azure Monitor Logsのデータ保持設定
調査担当者には「1年間保存できます」ではなく、「どのログを、どの画面や手順で、誰が、どれくらい待って検索できるか」を説明できる状態を目指します。検索速度の要求は保存期間とは別に合意し、実測で確認してください。
ログごとの要件表に残す8項目
以下は社内で要件を整理するための記入項目です。最初から数値を埋めず、根拠が不明な欄は「要確認」として担当者を付けます。
ログ源と対象範囲：製品名、対象アカウント・機器、対象外の環境。
調査シナリオ：不審な認証、権限変更、大量取得など、説明したい操作。
必須項目：発生時刻、ユーザーID、対象、操作、結果、元イベントの識別子など。
必要な遡及期間：何日前まで調べるかと、その根拠・承認者。
検索方法と許容時間：通常検索・検索ジョブ・復元の区分と、結果を得るまでの目標時間。
保存期間の起点：イベント発生時刻か取り込み時刻か、遅延到着時の扱い。
取得・保全の担当：実行者、承認者、代行者、必要な権限、取り出したデータの保管先。
確認記録：最後に取り出せた日、測定結果、証跡、未解決の不足、次回確認日。
例えば不審な認証の調査では、認証成功・失敗の件数だけでなく、ユーザーや端末を他のログと結び付けられるかが重要です。ユーザー名が変更されても追える識別子や、時刻のタイムゾーンを要件に含めます。具体的な必須項目は、自社のシナリオで確かめて決めてください。
保存期間の起点と、遅れて届くログを確認する
同じ「180日保存」でも、発生した日から数えるのか、取り込んだ日から数えるのかで、遅れて届いたログの残存期間は変わります。
Google Security Operationsの公式資料では、rawログの保持は取り込み時刻、UDMイベントの保持はイベント時刻が基準と説明されています。自社の検索対象がどちらかを確認せず、取り込み日だけで削除時期を見積もると齟齬が生じます。出典：Google Security Operationsのデータ保持
テストでは、発生時刻と取り込み時刻を分けて記録し、転送停止後に再送したデータや時刻ずれのあるデータが検索対象に入るかを確認します。設定を延長すれば削除済みのログまで戻るとは考えないでください。Microsoftの資料でも、延長の対象は取り込み済みでまだ削除されていないデータとされています。
過去ログの取り出しを確認する6段階のテスト
次の手順は、運用開始前と構成変更時に行う確認の一例です。頻度や合否基準は自社の要求に合わせて合意します。設定変更や削除を伴うテストは、承認済みの検証環境・データで行ってください。
対象を決める。通常検索の範囲内、長期保管へ移った後、保持期限に近い期間から、識別できるテストイベントを選びます。期待する日時、件数、IDを先に記録します。
通常の担当者の権限で実行する。管理者だけが操作できる状態では、夜間や不在時の運用を検証できません。申請・承認を含め、定めた担当者が手順を実行できるか確認します。
検索条件と所要時間を残す。要求受付、承認、処理開始、検索可能、調査完了の時刻を分けます。待ち時間の原因が権限か、処理か、担当者の作業かを区別します。
中身を照合する。想定イベントの有無だけでなく、ID、発生時刻、取り込み時刻、必須項目、件数を確認します。0件の場合は「事象なし」とせず、対象範囲・権限・時刻条件・欠損を切り分けます。
別ログと結び付ける。同じユーザーや端末を認証・端末・クラウドのログで追い、調査の問いに答えられるか確認します。単一ログだけ取り出せても、相関に必要な期間が揃っていなければ不十分です。
費用と後処理を確定する。検索・復元・転送の数量、必要な作業、取得先の権限、複製データの保持・削除手順を記録します。証跡の保全が必要な場合は、その手順を優先します。
合格条件は「操作が成功した」ではなく、必要な期間のイベントを、必要な項目と権限で、合意した時間内に調査できることです。未達の場合は期間の短縮で帳尻を合わせず、ログ欠損、検索方式、権限、処理能力、運用体制のどこに原因があるかを残します。
容量の試算は、取り込み量と課金対象量を混同しない
例えば平均20GB/日、総保持180日、即時検索30日を仮定します。圧縮・削除・重複・形式変換を考慮しない単純な数量なら、全期間は20×180＝3,600GB、直近30日は600GB、残り150日は3,000GBです。これは考え方を示す架空の条件で、推奨日数や製品の課金額ではありません。
実際の保存量や請求額には、圧縮、索引、複製、無料枠、契約上の保持方式、検索・復元回数などが影響します。期間ごとのデータを別の層に移す構成なのか、同じデータを複製する構成なのかも確認してください。ピーク時のログ量と検索負荷を測り、必要容量と費用をそれぞれ見積もります。
保存設定を変える前の確認事項
短縮する場合：現在の調査、保全対象、社内規程・契約上の要件に影響しないか。
延長する場合：どのデータに適用され、既に消えたデータを含まないか。
保管先を移す場合：検索・復元手順、権限、暗号鍵、転送費用、終了時の取得方法が変わらないか。
ログ量が増える場合：期限より先に容量上限へ達しないか。取得停止・欠損を誰が検知するか。
設定変更の前後に同じテストを実施し、要件表の根拠、確認日、担当者を更新します。保存設定のスクリーンショットだけでなく、実際の検索結果や取り出し記録も合わせて残すと、引き継ぎ時に判断しやすくなります。
相談前にそろえるもの
製品一覧、ログ別の日次量、遡りたい調査シナリオ、結果を得るまでの許容時間、現在の保存・検索方式を1枚にまとめてください。分からない項目は推測で埋めず、測定・確認事項として持ち込みます。
ヤグラのAI SIEMやAI SOCを検討する場合も、この要件表をもとに対象ログ、保存・検索条件、人が担う作業を導入相談で確認できます。本記事はヤグラ製品の特定の保存日数や復元時間を保証するものではありません。
関連：同じ条件でSIEMの費用を比較する ／ 監視開始前のログ連携受入テスト
一次資料確認日：2026年10月13日。製品の保持方式・プランは変更されるため、設定変更や契約時にはリンク先の最新情報と実環境を照合してください。
