SIEMとは｜XDR・SOARの違いとログ管理・製品比較・運用の確認点

SIEMは、複数のシステムからセキュリティに関係する記録を集め、関連づけて分析し、検知・調査・対応を支援する仕組みです。導入では、製品の機能に加えて、必要なログが届くか、誰がアラートを調べるか、どこまでの操作を自動化するかを確認します。2026年10月24日に確認した公式資料をもとに、XDR・SOARとの違い、ログ管理、主要製品の費用条件と運用の確認点を整理します。

SIEMとは：XDR・SOARとの違いと重なる機能を確認する

SIEMはSecurity Information and Event Managementの略です。認証、端末、ネットワーク、サーバー、クラウド、アプリケーション等の記録を収集し、形式をそろえて関連を分析することで、調査に必要な情報を集めやすくします。IBMのSIEM解説も、ログ管理、イベント相関、監視・アラート、報告を主な機能として説明しています。対象のログと連携設定があって初めて利用できるため、SIEMを置けば自社の全資産・全通信を自動的に把握できると考えないことが大切です。

XDRはExtended Detection and Response、SOARはSecurity Orchestration, Automation and Responseの略です。XDRは端末、メール、ID、クラウド等の検知情報を関連づけて調査・対応へつなぐ機能、SOARは複数ツールの操作や対応手順を連携・自動化する機能として整理できます。SIEMは広い範囲の記録を集約・検索・分析する役割に注目しますが、これらは排他的な製品分類ではありません。SIEMにも自動対応があり、XDRの機能や連携先も製品によって異なります。検知方式をSIEMはルール、XDRはAIと一律に分ける比較も適切ではありません。

整理する役割	主に確認する対象	製品選定で確かめること
SIEM：記録の集約・分析	複数システムのログ、検索・相関、検知と調査の記録	対象ソース、形式、取り込み・検索条件、保持、アラートと調査機能
XDR：検知情報を横断した調査・対応	端末、ID、メール等のシグナルと関連する事象	統合対象、取得できる情報、操作権限、既存製品との連携
SOAR：対応手順と操作の連携	調査補助、通知、承認、隔離等の手順	実行できる操作、承認と失敗時の処理、実行後の確認

例えば、MicrosoftのSIEM・XDR統合の説明は、Microsoft SentinelをSIEMとSOARの機能を持つサービスとして説明し、Defender XDRとの連携を示しています。これは同社の製品構成の例で、すべてのSIEMが同じ機能やライセンスを持つことを意味しません。「次世代SIEM」という名称も、統一された機能保証として扱わず、対象の製品・版・契約で検証します。記録の収集、検知、調査、対応のうち何が不足しているかを先に整理し、製品名や市場予測だけから統合製品の導入を決めないようにします。

ログ管理の設計：収集できたことと、検知できる状態を分ける

ログの設計は、想定する被害と調べたい事象から始めます。認証の失敗、権限の変更、管理操作、外部接続、重要なデータへのアクセス等について、どのシステムが何を記録するかを整理します。記録元、対象のアカウント・端末・業務、取得方法、必要な項目、保管先、担当者を一覧にし、取得できない範囲も残します。ログを大量に集めることと、必要な疑問に答えられることは別です。検知や調査に不要な情報まで増やすと、費用と確認負担、機密情報の複製も増えるため、用途と取得範囲を対応させます。

接続が一度成功しただけで、継続して収集できているとは判断しません。認証情報の期限、APIの制限、エージェント停止、ネットワーク、形式の変更、遅延や重複などを確認します。Microsoftのデータコネクタ正常性の説明は、接続や性能、取り込み状態の監視と、対応するコネクタの範囲を示しています。同資料のSentinelHealthもすべてのコネクタを対象とするわけではありません。製品の正常表示だけでなく、最後に受け取った時刻、件数の変化、欠落の可能性、監視対象外を確認する設計が必要です。

収集後は、元の記録が検索に使う項目へ正しく変換されているかを確かめます。発生時刻と取り込み時刻、時刻帯、利用者・端末・資産の識別子、イベント名、成功・失敗、操作対象等をそろえます。同じ人物や端末を別のIDで扱う場合や、時計がずれている場合は、誤った関連づけや調査の遅れにつながり得ます。変換ルールや製品の更新後は、元の記録と取り込み結果を照合します。ログが来ていない状態と、正常に収集した範囲で該当事象がない状態を区別し、欠測を「問題なし」のゼロにしないことが大切です。

保持期間、検索できる期間、検索に必要な時間、アーカイブから戻す手順、削除や改変への対策、閲覧・出力の権限も確認します。必要な記録と期間は、対象業務に適用する規範、契約、調査目的、費用から整理し、すべての企業に同じ年数や特定製品が必要だと判断しません。一般のログ保管と、必要な検索・監視・証跡を満たすことを分けます。海外企業の製品説明に法令名があっても、日本の自社に同じ要件がそのまま適用されるとは限りません。

AIアプリケーションの記録も調査対象にする場合は、モデルの利用、認証、費用、ツール操作のどの情報が必要かを決めます。LLMゲートウェイの管理範囲とログの条件では、経由する通信と、別経路の操作、ログの保存・転送を分けています。ゲートウェイやSIEMの記録だけで全工程が追えるとは考えず、関連づけに使う識別情報と、本文を保存する必要性、閲覧権限を確認します。

ネットワークやリモート接続の記録を集める場合は、SASE・SD-WANの接続・権限と運用の確認点も参照できます。利用者・端末、接続先と適用したポリシーを対応させ、通信の許可・拒否、ログの欠落、実際の業務への影響を分けて調べます。分析や設定案を出せることと、本番の変更が承認・実行されて結果まで確認できたことも区別します。

主要SIEM製品と料金：同じログ・保持・検索条件で比較する

製品の比較では、対応ソースや検知・調査・自動化の機能、配置、権限、運用体制をそろえます。下表は公式資料で確認した構成・料金条件の一部で、価格の順位や企業規模別の推奨ではありません。現在の契約、利用する版、地域、追加機能によって条件が変わるため、必要な機能と見積もりの対象を対応させます。紹介ページに機能名があることだけで、自社の契約にすべて含まれるとは判断しません。

製品と公式資料	確認した構成・機能	費用の確認点
Splunk Enterprise Security	クラウド、自社管理・オンプレミスの選択肢。版によってSIEM、SOAR、UEBA等の提供範囲が異なる	取り込み量、ワークロード、アクティビティ等の料金方式と、対象製品・版・保存条件
Microsoft Sentinel	クラウドのSIEM。SOAR機能やDefender XDRとの連携を確認する	分析層の従量・コミットメント、データレイクの取り込み・処理・保存・検索、追加の自動化等
Google Security Operations	SIEMの利用を含むパッケージと、単独製品の契約範囲を区別する	サブスクリプションと取り込み量の計量、契約クレジット、超過・追加保持、地域と更新条件

Splunkの公式料金ページは、Cloud PlatformとEnterprise、Enterprise Securityの構成や料金方式を分け、Enterprise Securityでも版による機能差を示しています。Microsoftの課金説明は、Sentinelだけでなく関連するAzureリソース等の費用も発生する点を説明しています。Googleの課金説明では、購入した取り込み量に相当するクレジットを実際の使用量で消費し、条件によって超過や追加保持の料金が発生します。データ量と無関係な固定料金、あるいは取り込み料金だけで全費用が決まると一括りにしません。

見積もりでは、平均とピークのログ量、対象ソース、除外・変換、保存と検索の期間、調査時の検索負荷、必要な連携・自動化、監視担当を確認します。ライセンスに加えて、収集基盤、移行、ルール設計、調整、教育、運用・保守の費用も整理します。無料試用の対象範囲があっても、追加機能や関連リソースまで無料とは限りません。ログを削って費用を下げる案は、その記録を使う検知や調査への影響と合わせて判断します。

製品の評価は、正常にログを取り込めるかだけでなく、自社で調べたい事象を検索できるか、対象の条件で検知できるか、担当者が必要な操作を行えるかまで確認します。検証対象、権限、データ、期待する結果を合意し、得られた結果と未評価の条件を記録します。既存の認証・アプリケーションの弱点を調べる検査と、運用中のログを集める仕組みは役割が異なるため、セキュリティ診断・脆弱性診断の種類と選び方も参照し、必要な作業範囲を整理してください。

運用設計：アラートの調査・対応と確認担当をつなげる

アラートが出ることと、必要な対応が完了することは別です。対象の重要度、権限、関連する記録を確認して調査し、何を根拠に問題と判断したか、誰が次の対応を決めるかを記録します。誤検知を減らす調整も、通知件数だけを下げると必要な事象を見逃す場合があります。条件変更の理由、確認した例、検知できる範囲と未検証の範囲を残し、ルールや接続元の変更後に再確認します。AIによる要約・分類を使う場合も、根拠のログへ戻れるようにし、推定と確認済みの事実を分けます。

自動対応では、情報の追加取得や通知と、端末隔離、アカウントの停止、設定変更などを分けます。操作できる対象と権限、事前条件、人の承認が必要な範囲、失敗・部分成功・結果不明時の処理を決めます。実行要求を受け付けたことだけで成功とせず、接続先の状態まで確認します。業務停止への影響がある操作は、戻す方法と再開の判断者も用意します。AIアプリやエージェントの権限を含めて検討する場合は、AIセキュリティの脅威・対策とガバナンスと合わせて整理できます。

運用の指標には、検知・対応の所要時間、調査待ち、対応未完了、誤検知、取得の欠落、必要な記録を検索できるか等を候補にします。MTTDやMTTRを使う場合は、発生・検知・調査開始・封じ込め・復旧のどの時点を始点と終点にするかを明記します。対象期間、案件の重要度、分母、未完了の扱いをそろえ、平均値だけでなく長く止まっている案件も確認します。調査しなかったアラートを解決済みに変えるだけの改善や、定義の違う他社指標との単純比較を避けます。

自社SOCと外部委託は、企業規模だけで決めず、必要な対応時間、担当者の技能、連絡・承認、実行権限、費用で比較します。外部監視を使う場合も、対象ソース、監視時間、通知の条件、調査・封じ込め・復旧の担当と契約範囲を明確にします。通知を受けた自社の担当が不在なら、その後の判断が止まるため、代理と連絡経路も確認します。セキュリティ人材の技能と実務評価も参照し、製品の導入と、日々の判断・改善を担う体制を結びつけます。

ログから認証・権限や外部接続の問題が見つかり、コードや構成まで確認したい場合は、renueのAI脆弱性診断支援サービスへ相談できます。現在のシステム、接続先、扱うデータ、調べたい問題を整理し、コード分析や合意した環境での検証範囲を決めます。診断で見えた弱点への対策やシステム刷新は、診断と分けて範囲を合意します。SIEMのアラートを調べる運用から、認証・権限や処理の流れそのものを改善する作業へつなげるための相談先です。