SIEMとは？仕組み・機能・費用と選び方、AI SOCとの違い

更新：2026年9月17日。調査に使うログの具体例、EDR・SOCとの違い、導入の判断方法、SCS評価制度の星4に向けたログ管理の確認事項を更新しました。

SIEMとは：ログをつなぎ、脅威の発見と調査に使う基盤

SIEMはSecurity Information and Event Managementの略で、「シーム」と読みます。端末、サーバー、ネットワーク機器、クラウドサービスなどのログやイベントを集め、複数の情報を関連付けてセキュリティ上の異常を見つける仕組みです。担当者は、アラートの確認、過去の操作の検索、インシデントの調査に利用します。NRIセキュアの用語解説でも、ログの一元管理と相関分析が中心的な役割として説明されています。

導入を考えるきっかけは「ログはあるが、製品ごとに分かれていて調べられない」「アラートの前後に何が起きたか分からない」という課題です。一方、SIEMを入れただけで監視・判断・対処を担う体制まで完成するわけではありません。収集対象と、検知後に誰が何をするかを一緒に決めます。

SIEMの仕組みと主な機能

1. ログの収集・正規化

API、エージェント、Syslogなどを使ってデータを取り込みます。製品ごとに異なる時刻・ユーザー名・IPアドレス・操作名を分析しやすい形にそろえる処理が正規化です。「接続できる」だけでなく、調査に必要な項目が欠けていないか、取得が止まったときに気づけるかまで確認します。

2. 相関分析・脅威検知

単独のログに加え、同じユーザーや端末、近い時刻に起きた複数のイベントを関連付けます。ルール、異常検知、脅威インテリジェンスなどの利用範囲は製品と設定によって異なります。アラートは調査の入口であり、それだけで攻撃が確定するとは限りません。

3. 検索・調査・レポート

担当者はログを検索し、操作の時系列や影響範囲を確認します。ダッシュボードやレポートは日々の状況把握や証跡の説明に役立ちます。保存期間、検索できる期間、元ログへのアクセス権も設計が必要です。

4. 通知・対応の連携

チケット起票や担当者への通知、SOARとの連携による対応の自動化などが考えられます。例えばMicrosoft Sentinelの公式ドキュメントは、データ収集から検知・調査・対応までの機能を説明しています。各SIEMで同じ対応操作ができるわけではないため、対象製品・権限・承認手順を確認します。

具体例：SIEMでどのログをつなぎ、何を確かめるのか

「深夜のサインイン」「管理権限の変更」「クラウドストレージからの大量取得」が続いたとします。これは説明用の架空例です。SIEMで確認したいのは、単に3件の記録が存在することではなく、同じ利用者による一連の操作なのか、正規の業務で説明できるのか、という点です。

これは収集設計の例であり、すべての製品が同じ項目を出力するわけではありません。Microsoft Entraのサインインログでも、利用者や接続元、端末情報を確認できますが、IPアドレスから推定した場所が端末の実際の所在地を示すとは限りません。VPNや携帯回線の影響もあるため、「海外のIPだから不正」と単独で決め付けず、他の記録と照合します。Microsoft Entraのサインインログの読み方

また、「クラウドのログを接続済み」でも、データの取得操作まで記録できるとは限りません。AWS CloudTrailでは、S3のGetObjectなどはデータイベントに該当し、証跡やイベントデータストアで既定では記録されません。必要な操作・対象を指定し、追加料金も確認して収集します。AWS CloudTrailのデータイベント

収集後は、時刻の基準をそろえ、サービスごとに異なるIDや端末名の対応を確認します。そのうえで承認済みの作業、バックアップや移行処理など、正常な理由でも同じ動きが起きるかを調べます。SIEMの相関分析は、この照合を支える仕組みです。関連付けられたという理由だけで攻撃が確定するわけではありません。Microsoft Sentinelの収集・分析機能

収集量より先に、必要なログが使えるかを確認する

接続の成否に加え、実際の操作が記録されること、検索で見つかること、ログが止まったときに気づけることを確認します。発生時刻とSIEMへの到着時刻を分けて見ると、取得の遅れも確認できます。アクセス権、改変・削除への保護、必要な期間の検索方法も収集設計に含めます。ASDなど各国機関の共同ガイダンスでも、時刻の整合性、集中管理、安全な保管、迅速な取り込みを重視しています。イベントログと脅威検知の共同ガイダンス

監視開始前の確認を具体的に進めるには、SIEMのログ連携を6段階で確かめる受入テストと担当分担を参照してください。記録の生成から、必要な項目の取得、検索、検知、担当者の受領までを整理しています。

SIEM・EDR・SOCの違い：記録、分析、対応の役割で比べる

SIEM、EDR、SOCは役割が異なり、組み合わせて使います。製品やサービスの名称だけで、どこまで調査・対処できるかは決まりません。

例えば不審なプログラムが端末で動いた場合、EDRはその端末のプロセスや通信などを調べる手掛かりになります。SIEMでは、関連するIDの操作やクラウド側のアクセスも組み合わせ、端末の外へ影響が広がったかを調べます。SOCの担当者は、その証拠と業務への影響を確認し、必要な対応を判断します。SOARを使う場合は、事前に定めた条件・権限に沿って通知や対応手順を実行します。MicrosoftのEDR機能解説、SOCの役割と利用するツール

EDR製品とログ管理の記録範囲も同一とは限りません。例えばMicrosoft Defender for Endpointは、端末のあらゆる操作を記録する監査・ログ管理ソリューションではないと説明しています。EDRを導入していることだけで、監査に必要な記録がすべて残るとは判断できません。Defender for Endpointの記録範囲

SOC運用を外部へ委託する場合も、アラートの通知、詳細調査、端末隔離、業務復旧のどこまで任せるかを分けて確認します。MDRなど検知・対応を提供するサービスも、対象製品と契約範囲を照合してください。

SIEMの費用は何で決まるか

製品名だけでは費用を比較できません。取り込むデータ量、保存期間、検索条件、運用範囲を同じにして見積もることが出発点です。価格体系は製品・契約によって異なるため、ここでは一律の相場や削減率を示さず、確認すべき内訳を整理します。

• ライセンス・利用料：データ量、イベント数、資産数、利用する機能など、課金単位と超過時の条件を確認します。

• 保管・検索：すぐ検索できる期間と、アーカイブから復元して調べる期間を分けます。復元や検索、データ転送に追加費用があるか確認します。

• 導入作業：ログの接続、形式の調整、初期ルール、通知先の設定、既存環境からの移行を含めます。

• 継続運用：アラート調査、ルールの改善、収集停止への対応、夜間休日の担当体制を含めます。

概算の取り込み量は「対象ごとの平均GB/日 × 日数」を合算し、繁忙日や障害時の増加も別に見ます。保存費用までこの式だけで算出できるわけではありません。例えばMicrosoft Sentinelの料金ページのような公式情報で、取り込み・保存・追加機能の条件を個別に確認してください。

製品ごとの課金・保存条件や、同じ条件で見積もる方法は、SIEMの比較・費用で詳しく整理しています。

SIEMの導入が必要かを判断する

最初に、現在の作業で何ができずに困っているかを整理します。次の表は、検討の出発点を決めるための例です。

複数の課題が重なる場合もあります。例えばログが不足した状態で調査だけを自動化しても、判断材料は増えません。一方、すでに必要な記録がそろっているなら、SIEMの入れ替えより調査手順の改善が先になる場合があります。

導入を決める前に、優先する調査を一つ選び、既存の環境でどこまで確認できるか試してください。その不足を埋める構成について、導入費用だけでなく、継続する設定調整・担当者の教育・調査作業を含めて比較します。ASDの導入ガイダンスも、自社運用と外部委託の判断、継続費用、責任分担の検討を挙げています。SIEM・SOAR導入の経営層向けガイダンス

選び方：導入前に確認する7項目

次の項目を製品比較とPoC（本導入前の検証）の共通条件にすると、デモ画面の印象だけに頼らず判断できます。

1. 検知したい事象：不審なサインイン、権限変更、端末の不審動作など、優先する調査対象を先に決める。

2. 必要なログ：どの製品から、どの項目を、どの頻度で取得するかを確認する。

3. データ品質：時刻のずれ、項目欠落、重複、取得の遅延・停止を見つけられるか検証する。

4. 調査のしやすさ：アラートから元ログ、関連ユーザー・端末、時系列にたどり着けるか実際に操作する。

5. 運用体制：一次確認、重大事象の判断、夜間休日の連絡、封じ込めの担当と権限を決める。

6. データの取り扱い：保存場所、アクセス制御、削除・持ち出し、AIに渡すデータの範囲を確認する。

7. 総費用と移行：通常時と増量時の費用、既存ログの移行、契約終了時の取り出しまで比較する。

PoCで残すと役立つ検証記録

同じログと同じシナリオで比較し、「期待した検知」「実際の検知」「判断に使えた証拠」「担当者が要した時間」「残った不明点」を記録します。検知時間はイベント発生から通知まで、調査時間は担当者の確認開始から判定まで、というように測定の起点と終点をそろえます。

攻撃を模したケースだけでなく、正規の管理作業やログが欠けたケースも含めます。誤検知が減っても、確認対象から外れた重要事象がないかは別に点検します。合格条件は自社の業務とリスクに合わせ、本導入前に決めておきます。

AI SIEMとAI SOCの役割

AI SIEMは、ログ検索、相関分析、検知、要約などにAIを使うSIEMを指して使われます。AI SOCは、監視・調査・判断支援などSOCの業務にAIを組み込む考え方です。呼び名だけでは機能や自動化範囲が分からないため、「どのデータを見て、何を判断し、どこまで実行するか」で比較します。

AIが付けば未知の攻撃を必ず検知できる、誤検知がなくなる、担当者が不要になるという意味ではありません。生成された説明を元ログで確認できること、証拠が不足した場合に人へ引き継げること、対応操作の権限と記録を管理できることが重要です。詳しくはAI SOCの仕組みと従来型SOCとの違いを参照してください。

SCS評価制度の星4に向けて、ログ管理をどう確認するか

SCS評価制度の★4では、要求事項4-4-3に対象機器・認証基盤のログ取得・保管などの基準があります。SIEMの導入自体を合格条件に置き換えず、対象ログ、必要項目、保存期間、閲覧時の保護、定期確認をそれぞれ照合します。原文と適用条件はIPAの★3・★4要求事項・評価基準で確認できます。

例えば「6カ月保存する設定になっている」「実際に過去の対象ログを取り出せる」「担当者が確認し、結果を記録している」は別の確認です。導入直後の設定画面だけで、過去の記録や継続運用がそろったことにはなりません。自社の取得状況をSCS対応準備チェックリストに沿って整理し、段階の選択は星3・星4の違いで確認してください。

対象ログと保存・確認の証跡を具体的に整理する際は、SCS評価制度の星4に向けたログ管理・監視の確認項目もご覧ください。

よくある質問

SIEMはログ管理ツールだけでは代替できませんか？

保存と検索が目的ならログ管理で足りる場合があります。複数製品をまたぐ検知や継続的なアラート調査が必要なら、SIEMの分析機能と運用方法を比較します。

EDRを導入済みでもSIEMは必要ですか？

端末以外のID・クラウド・ネットワークの記録を関連付けて調べたいかで判断します。EDRがあるという理由だけで、SIEMが必須とも不要とも決まりません。

小規模なチームでも運用できますか？

収集・検知する対象を絞り、担当者と連絡手順を決めて段階的に始める方法があります。調査まで社内で担えない場合は、運用支援やMDR、AIによる調査支援も比較対象になります。

AI SOCがあればSIEMはいらなくなりますか？

AIが調査するためのログやアラートは必要です。既存SIEMと連携する構成も、一体型の構成もあるため、必要なデータの収集・保存・検索を誰が担うか確認します。

自社のログと運用に合わせて検討する

ログの一元化・横断分析を検討する方はヤグラAI SIEM、既存EDR・SIEMからのアラート調査を効率化したい方はヤグラAI SOCのサービス説明をご覧ください。製品ごとの対応範囲は導入環境に合わせて確認します。

SIEM・AI SOCの導入相談では、利用中の製品、調べたい事象、ログ量と保存期間、現在の運用体制を整理しておくと、必要な構成を具体的に検討できます。