SIEMとは?「ログは取っている」のに、調べられない理由
被害に遭った組織で、必要なログを全部そろえられたのは約4分の1でした。
30秒でわかる「SIEM」
- バラバラの機器のログを1か所に集めて、つなげて見て、危ない組み合わせを知らせる仕組みです。読み方は「シーム」。
- 攻撃の痕跡は1台のログだけでは意味を成さず、複数のログを突き合わせて初めて形になります。
- 2025年のランサムウェア被害組織のうち、必要なログを「全て保全」できたのは102件中25件。残りは一部または全部が使えませんでした(警察庁)。
- 誤解:「SIEMを入れれば検知できる」。実際は検知ルールを育てる作業が本体で、買って終わりにはなりません。
- 今日やること:いま何日分のログが残っているかを1つだけ確認する。侵入から発覚までの中央値は14日です。
この記事の地図(全8章)
SIEMは、この分野の用語のなかでも特に「説明を読んでも実感が湧かない」ものだと思います。ログを集める。相関分析する。可視化する。どれも正しいのですが、それで何が変わるのかが伝わりません。
この記事は、SIEMが解こうとしている問題のほうから説明します。その問題は、警察庁の統計にはっきり数字で出ています。被害に遭った組織で、調査に必要なログを全部そろえられたのは4分の1だけ——ここが出発点です。
この記事は2026年8月16日時点の内容です。国内の統計は警察庁『令和7年におけるサイバー空間をめぐる脅威の情勢等について』(2026年3月公表)の統計編、国際的な傾向はGoogle Cloud / Mandiant「M-Trends 2026」(2026年3月公表)、定義はNIST SP 800-92 から引用し、出典を記事末に記載しています。
機器やサービスごとの既定のログ保存期間は製品・契約プランによって大きく異なります。本記事では具体的な日数を断定せず、確認すべき項目として整理しています。実際の値はご自身の環境でご確認ください。
SIEMとは(やさしい定義)
「ログを集める箱」から一歩進んだもの
サーバー・ネットワーク機器・クラウド・端末などバラバラの場所に出るログを1か所に集めて保存し、横断して検索でき、危ない組み合わせが出たら知らせるための仕組みです。
NISTの用語集では、SIEMは次のように定義されています。
A program that provides centralized logging capabilities for a variety of log types.
(さまざまな種類のログに対して、集中的なログ管理の機能を提供するプログラム)
ずいぶん素っ気ない定義に見えます。しかし、この「集中的な(centralized)」という一語がすべてです。ログはもともと、それぞれの機器の中に、それぞれの形式で、それぞれの保存期間で散らばっています。その状態では、横断して調べることができません。
「ログを取っている」と「ログを調べられる」は別のこと
各機器がログを吐いている状態は「取っている」です。しかし、機器ごとに時計がずれ、形式が違い、保存期間もばらばらで、しかも侵害を受けた機器のログは攻撃者に消される可能性があります。この状態では調べられません。SIEMが埋めているのは、この「取っている」と「調べられる」の間の溝です。
第1章 おわり — 次は第2章
数字で見る「ログはあるのに調べられない」
被害組織の実態が、統計に出ています
警察庁は、ランサムウェア被害に遭った企業・団体へのアンケートで「ログ保全状況」を調べています。その結果を実数で書き出すと、次のようになります。
| 2025年(令和7年)のログ保全状況 | 件数 | 割合の目安 |
|---|---|---|
| 全て保全(必要なログがそろっていた) | 25件 | 約4分の1 |
| 一部利用不可 | 64件 | 最も多い |
| 利用不可 | 8件 | — |
| ログ取得無(そもそも取っていなかった) | 5件 | — |
| 合計 | 102件 | — |
出典:警察庁『令和7年におけるサイバー空間をめぐる脅威の情勢等について』統計編137頁のグラフから実数を読み取り、割合は筆者が算出したもの。資料には「有効回答の数値が異なるため、各年の合計数値は異なる」と注記があります。
この表のいちばん重要な行は2行目です。最も多いのは「取っていなかった」でも「全部そろっていた」でもなく、「一部が使えなかった」——102件中64件です。
つまり、大半の組織はログを取っていました。取っていたのに、いざ調べようとしたら必要な部分が欠けていた。これがSIEMという製品カテゴリが向き合っている現実です。
「一部利用不可」はなぜ起きるのか
主な理由は3つ考えられます。①保存期間を過ぎて消えていた ②侵害された機器の上にあり、攻撃者に消された ③そもそもその機器ではログを出す設定になっていなかった。①と②は、ログを別の場所へ退避していれば防げます。SIEMの「集中的な」という部分が効くのは、まさにここです。
もう1つ、保存期間を考えるうえで欠かせない数字があります。Google Cloud / Mandiant の「M-Trends 2026」によれば、侵入から発覚までの日数の中央値は14日(前年は11日)でした。さらに、長期の諜報活動や北朝鮮のIT労働者が関わる事案では、中央値が122日(約4か月)に達したとされています。
| 調べたい期間 | 必要なログの保存期間 | 根拠 |
|---|---|---|
| 一般的な侵害の「侵入時点」まで | 最低でも2週間以上 | 滞留日数の中央値14日(M-Trends 2026) |
| 中央値より長引いた事案 | 数か月 | 中央値は「半分がそれより長い」という意味です |
| 諜報活動などの長期潜伏 | 4か月以上 | 該当事案の中央値122日(M-Trends 2026) |
必要な保存期間は組織の要件・法令・契約によって決まります。この表は考え方の目安であり、推奨値ではありません。
中央値が14日という数字を「2週間分あれば足りる」と読むのは誤りです。中央値とは、半分の事案はそれより長かったという意味です。発覚が遅れた事案ほど調査は難しくなり、そういう事案でこそログが必要になります。
第2章 おわり — 次は第3章
1台のログでは、なぜ意味を成さないのか
攻撃の痕跡は、機器をまたいで散らばります
SIEMが「集める」ことにこだわる理由を、攻撃の流れに沿って見てみます。次の表は、ランサムウェア攻撃の各段階で痕跡がどこに残るかを並べたものです。
| 段階 | 攻撃者がすること | 痕跡が残る場所 | その機器だけ見ると |
|---|---|---|---|
| 1 侵入 | VPN機器の脆弱性や盗んだ認証情報で入り込む | VPN機器・認証基盤 | 「ログイン成功」としか見えない |
| 2 権限の奪取 | 管理者権限を取る | ディレクトリサービス・端末 | 「アカウントが追加された」だけ |
| 3 横展開 | 他の端末へ移動する | 複数の端末・ファイルサーバー | 1台ずつ見ると単なるアクセス |
| 4 窃取 | データを外部へ送る | ファイアウォール・プロキシ | 「外向き通信」だけ |
| 5 暗号化 | ランサムウェアを起動する | 端末・EDR | ここで初めて明確な異常 |
| 6 撤収 | ログとツールを消す | 侵害した機器のログを消す | 1〜5の痕跡が消える |
攻撃の流れは警察庁『令和7年におけるサイバー空間をめぐる脅威の情勢等について』の記述にもとづき、痕跡の所在は筆者が整理したものです。
4列目を縦に読むと、段階5まで、どの機器でも単体では「異常」と判定できないことが分かります。判定するには、1〜4を同じ時間軸で、同じアカウントを串刺しにして並べる必要があります。それが「集めて、つなげる」ということです。
そして6行目が決定的です。攻撃者は最後に、侵害した機器の上のログを消します。機器の中にしかログがない構成では、いちばん知りたい部分から順に消えていきます。SIEMのようにログを外部へ転送していれば、機器の上で消されても手元に残ります。
「集める」の本当の意味は、攻撃者の手の届かない場所に置くこと
SIEMの集約機能は、検索を速くするためだけのものではありません。ログを、侵害される可能性のある機器から引き剥がすという意味があります。第2章の「一部利用不可 64件」の中には、この対策があれば防げたものが含まれていると考えられます。
第3章 おわり — 次は第4章
よくある誤解と、似ている用語
「入れれば検知できる」が最大の落とし穴です
SIEMは、導入した日にはほとんど何も検知しません。ログが集まるだけです。「どういう組み合わせが危ないのか」という検知ルールは、自社の環境に合わせて作り込む必要があります。
しかも最初は誤検知だらけになります。夜間バッチが「深夜の大量アクセス」として引っかかり、管理者の正常な作業が「権限昇格」として上がる。これを1つずつ潰して精度を上げていく作業が、SIEM運用の本体です。
この作業を担う人がいないままSIEMを導入すると、「高価なログ置き場」になります。実際、そうなっている組織は少なくありません。
混同されやすい言葉を、目的と時間軸で整理します。
| 用語 | 主な目的 | 得意な時間軸 | SIEMとの違い |
|---|---|---|---|
| ログ管理 | ログを取得・保存する | 過去 | 集約や横断検索、検知までは含まないことが多い |
| SIEM | 集約・横断検索・長期保存・相関検知 | 過去〜いま | — |
| EDR | 端末の異常に気づく | いま | 見る範囲が端末に限られる。保存は調査目的では短め |
| XDR | 複数の場所をつないで気づく | いま | 検知が主目的。長期保存や監査対応は想定外のことが多い |
| SOAR | 検知後の対応を自動化する | いま | 気づくのではなく、気づいた後を担う |
| バックアップ | データを復旧する | 過去 | 目的がまったく違う。ログの代わりにはならない |
これらは製品カテゴリ・業界用語で、SIEM以外は公的な標準規格ではありません。製品ごとに範囲は異なります。
とくに最後の行に注意してください。「バックアップを取っているからログもある」という混同は実際に起こります。バックアップはデータを戻すためのもので、「誰がいつ何をしたか」は記録していません。役割がまったく別です。
第4章 おわり — 次は第5章
個人に関係あるのか
SIEMは不要ですが、同じ考え方は使えます
SIEMは組織の仕組みで、個人が導入するものではありません。ただし「自分のログを確認する」という行為は、個人にもそのまま当てはまります。
個人にとってのログは、各サービスが用意している「アクティビティ履歴」です。多くの人が、その存在を知らないまま使っています。
| 個人が見られるログ | どこにあるか | 何が分かるか |
|---|---|---|
| ログイン履歴 | Google・Apple・Microsoft・SNS等のアカウント設定 | 見覚えのない端末・国からのログイン |
| 接続中の端末一覧 | 同上(「デバイス」「セッション」など) | 知らない端末がログインしたままになっていないか |
| 送信済みメール | メールサービス | 自分が送っていないメールが送られていないか |
| アプリの連携状況 | アカウントのセキュリティ設定 | 身に覚えのないアプリに権限を渡していないか |
項目名はサービスによって異なります。
年に1回でいいので、見る習慣を
個人の場合、乗っ取りは「気づかないまま続く」ことがあります。組織のログ保全と同じで、異常が起きてから探すのでは遅いのです。年に1回、上の4項目を見るだけでも、気づける確率がまったく変わります。
第5章 おわり — 次は第6章
SIEMを買う前にできること
費用ゼロで「一部利用不可」を減らせます
SIEMは高価で、運用にも人が要ります。中小企業がいきなり導入するのは現実的ではありません。ですが、第2章の「一部利用不可 64件」を減らすためにできることは、製品を買わなくてもあります。効果の大きい順に挙げます。
| 順 | やること | 費用 | 第2章のどれを防ぐか |
|---|---|---|---|
| 1 | いま何日分のログが残っているかを機器ごとに確認する(VPN機器・ファイアウォール・サーバー・クラウド) | 無料 | 「保存期間切れ」を把握する |
| 2 | クラウドサービスの監査ログを有効にする(既定で無効・短期のことがあります) | 無料のことが多い | 「ログ取得無」をなくす |
| 3 | 重要な機器のログだけでも、別の場所へ転送する | 低い | 「攻撃者に消される」を防ぐ |
| 4 | 機器の時刻をNTPで合わせる | 無料 | 時刻がずれていると突き合わせができない |
| 5 | 保存期間を延ばす(容量を追加する) | 低〜中 | 「保存期間切れ」を直接減らす |
| 6 | SIEMの導入とルールの作り込み | 高い(人も要る) | — |
費用感は筆者の評価です。環境によって異なります。
4行目の時刻合わせは、地味ですが決定的です。機器ごとに時計が数分ずれていると、複数のログを並べても順序が狂い、因果関係が読めなくなります。第3章の突き合わせが成立する前提が、正確な時刻です。
警察庁も、備えとして「侵害範囲特定に不可欠なログの取得」を挙げています。ログは、あれば調査ができ、なければ「何が漏れたか分かりません」という説明しかできなくなります。
日本企業のログ管理の実態を掘り下げる
警察庁の調査データから日本企業のログ管理の盲点を分析した記事が なぜ「ログは取っているのに守れない」のか? です。実際の調査手順は Windowsイベントログ・Sysmon・auditdの読み方、クラウド側は クラウド・フォレンジック完全ガイド、SIEM製品の実際の操作は Splunkの初期設定とデータの入れ方 で扱っています。
第6章 おわり — 次は第7章
調査が必要になったときの最初の10分
ログは、待っていると消えます
インシデントが疑われたとき、最初の10分でやるべきことの多くはログの保全です。理由は単純で、ログは時間とともに自動で消えるからです。原因究明も、復旧も、報告も、すべてログの上に成り立ちます。
| 順 | やること | やってはいけないこと | 理由 |
|---|---|---|---|
| 1 | 関係しそうな機器のログ保存期間を延長・停止させる(上書きを止める) | まず原因を調べ始める | 調べている間にも古いログから消えていきます |
| 2 | 疑わしい端末をネットワークから隔離する | 電源を切る | 電源を切るとメモリ上の痕跡が失われ、その後の調査が困難になります(警察庁も同旨の注意をしています) |
| 3 | VPN機器・認証基盤・プロキシなど境界側のログを先に確保する | 端末のログだけ集める | 侵入経路の6割以上がVPN機器です。入口の記録が最も重要になります |
| 4 | 機器の時刻設定を記録しておく(ずれている場合はその値も) | 時刻を直してから調べる | 後で突き合わせるとき、ずれ幅が分かっていれば補正できます。直してしまうと分からなくなります |
| 5 | 保全したログのコピーを読み取り専用で別途保管する | 元のログを直接いじりながら調べる | 調査の過程で証拠を壊さないためです |
電源に関する注意は警察庁『令和7年におけるサイバー空間をめぐる脅威の情勢等について』の「ランサムウェア被害後の対応策」にもとづきます。その他は一般的な実務上の整理です。
相談先(公的機関)
- 都道府県警察のサイバー犯罪相談窓口(緊急性が高い場合は110番)
- IPA 情報セキュリティ安心相談窓口
- JPCERT/CC(組織としてのインシデント報告)
- 個人データが関わる場合:個人情報保護委員会
ログの上書きが止まり、入口側の記録が確保され、時刻のずれも記録されている状態です。ここまでできていれば、後から「何が起きたか」を再現できます。第2章の統計で言えば「全て保全」の25件の側に立てた、ということです。
第7章 おわり — 次は第8章
関連用語と、次に読む記事
この語とセットで覚えると理解が早くなります
| こんな方に | 次に読む記事 |
|---|---|
| 端末側の検知から理解したい | EDRとは?ウイルス対策ソフトがあったのに、なぜ止まらなかったのか |
| 複数の場所をつなぐ話を知りたい | XDRとは?1件ずつ見れば無害なのに、つなぐと攻撃に見えるもの |
| 日本企業のログ管理の実態を知りたい | なぜ「ログは取っているのに守れない」のか? |
| 実際にログを読めるようになりたい | Windowsイベントログ・Sysmon・auditdの読み方 |
| SIEM製品を触ってみたい | Splunkの初期設定・データの入れ方 |
| いま被害に遭っている | やられたときの最初の30分(早見表) |
第8章 おわり — 最後にFAQ
SIEMについてよく聞かれること
検索でよく見かける疑問から
ログはどれくらいの期間、残すべきですか?
組織の要件・法令・契約によって決まるため一律の答えはありません。ただし考え方の目安として、侵入から発覚までの日数の中央値は14日、長期潜伏する事案では中央値122日という調査結果(M-Trends 2026)があります。中央値は「半分はそれより長い」という意味なので、2週間分では足りない事案が半分あることになります。まずはいま何日分残っているかを把握するところから始めてください。
SIEMは無料で始められますか?
無償版や無料枠を提供している製品はありますが、扱えるログ量に上限があることが一般的です。ただしSIEM製品を導入しなくても、監査ログの有効化、重要な機器のログの別場所への転送、時刻の同期といった対策は費用をほとんどかけずに実施でき、これだけでも調査できる範囲は大きく変わります。
EDRやXDRを入れていれば、SIEMは不要ですか?
目的が違います。EDR・XDRは「いま気づく」ための仕組みで、SIEMは「後から調べる」「長期間保存する」ための仕組みです。監査や法令対応でログの保存が求められる場合、その要件を満たすのはSIEM側の役割になります。どちらか一方で完結するものではありません。
小規模な組織は、何から手をつければいいですか?
順に、①主要な機器のログ保存期間を確認する ②クラウドサービスの監査ログを有効にする ③重要な機器のログを別の場所へ転送する ④機器の時刻をNTPで合わせる、の4つです。いずれも費用がほとんどかからず、被害時に「一部利用不可」になる確率を下げられます。SIEM製品の検討はその後で十分です。
出典・参考
- 警察庁サイバー警察局『令和7年におけるサイバー空間をめぐる脅威の情勢等について』(2026年3月公表)特集Ⅱおよび統計編137頁 https://www.npa.go.jp/publications/statistics/cybersecurity/data/R7/R07_cyber_jousei.pdf
- NIST Computer Security Resource Center 用語集「Security Information and Event Management (SIEM)」(出典:NIST SP 800-92) https://csrc.nist.gov/glossary/term/security_information_and_event_management
- Google Cloud / Mandiant「M-Trends 2026」(2026年3月公表) https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026/
最終更新:2026年8月16日/次回見直し予定:2027年4月(警察庁資料とM-Trendsの公表に合わせて)


コメント