Cloud SIEMは画面から有効化ボタンを押せば動きます。詰まるのはその手前と後ろです。どのログを解析対象に載せるか、専用インデックスをどこに置くか、鳴ったシグナルを誰がどう閉じるか。ここを決めずに全ログを解析へ回すと、翌月の請求とトリアージ待ちの列が同時に膨らむ。この記事では、Datadog公式ドキュメント（2026年8月16日時点）の記述に沿って、取り込み対象の絞り込み、AWSからの送信経路、3タイプ7方式の検出ルールの選び分け、シグナルのトリアージと抑制、そして既存の監視基盤に相乗りする構成と専用SIEMへ切り替える分岐点を整理します。
まとめ：Cloud SIEM導入で先に決めるログ範囲と検出ルールの型
決めるのは3点だけです。第一に解析へ回すログの範囲。Datadogの導入手引きは、クラウドの監査ログ、IDプロバイダーのログ、SaaS・ワークスペースのログを起点に挙げています。アプリケーションのデバッグログを混ぜても検知は増えず、解析量だけが増える。
第二に、検出ルールを自作しない方針を先に立てること。Content Packsはセキュリティ向けにキュレーションされたインテグレーション群で、検出ルール・ダッシュボード・パーサー・SOARワークフローが一式で入ります。自作ルールは、既製ルールを一巡させて空白が見えた箇所に限る。
第三に、シグナルを閉じる担当と手順。ステータスはOpen・Under Review・Archivedの3つで、ケースを作れば自動的にUnder Reviewへ移ります。閉じ方を決めないまま鳴らし始めた現場では、2週間でOpenが数百件たまり、以後は誰も開かなくなる。検知の質より運用導線を先に敷いてください。
Cloud SIEMがログ管理の上に載る二層構造と専用インデックスの位置
Cloud SIEMは独立したログ基盤ではありません。Datadogのログ管理へ届いたログを解析する層として上に載ります。製品全体の位置づけはDatadogとは何かで扱うため、ここでは費用とインデックスの構造に絞ります。
ログ管理の取り込みと解析課金が別枠になるCloud SIEMの費用構造
費用は二段で積み上がります。下段がログ管理側の取り込みとインデックス、上段がCloud SIEMの解析量。同じ1GBのログでも、取り込んだだけの状態と、解析対象に載せた状態では請求の行が別になります。
この構造から導ける設計判断は1つです。解析へ回す対象を絞れば上段と下段が同時に下がる。逆に「とりあえず全部入れて後で絞る」は、両方の課金を走らせたまま数か月を過ごすことになります。取り込み経路そのものと送信前フィルタの書き方はDatadogログ収集の3経路とパイプライン設計で詳述しているため、Cloud SIEMを入れる前にそちらで到達量を先に削っておくと、上段の見積もりが安定します。なお公表単価は改定されるため、契約前に製品ページで時点を確認してください。
cloud-siem専用インデックスを一覧の先頭に置く理由と評価順の罠
Cloud SIEMを有効化すると、cloud-siem で始まる専用インデックスが作られます。公式の導入手引きは、このインデックスを一覧の先頭に置くよう明示しています。理由は評価順です。
Datadogのインデックスフィルタは、上から順に評価して最初に一致した1本で行き先が確定する仕組みです。既存のアプリログ用インデックスが上にあると、監査ログがそちらへ吸い込まれ、Cloud SIEM側には何も届かない。ルールを組んだのにシグナルが1件も出ない、という初期トラブルの多くはこれです。有効化直後にインデックス一覧の並びを目視し、cloud-siem が最上段にあることを確認してから検出ルールの検証に進んでください。
Cloud SIEMへ流すログソースの選定とAWS側の送信経路の組み立て
取り込み設計は「全部送る」の反対側から始めます。Datadogは1,000を超えるインテグレーションのパイプラインを用意していますが、有効にする順番を間違えると、解析量ばかり増えて検知が増えない状態になります。
クラウド監査ログとIdPログを最優先に置く取り込み対象の絞り込み
先に入れるのは、誰が何をしたかが1行で分かるログです。公式の導入手引きが起点として挙げるのは次の3系統になります。
- クラウドの監査ログ（AWS CloudTrail、Google Cloud監査ログ、Azureアクティビティログ）
- IDプロバイダーのログ（Okta、Microsoft Entra ID、Google Workspaceの認証イベント）
- SaaS・ワークスペースのログ（GitHub、Slackなどの管理操作と権限変更）
この3系統だけで、権限昇格・不審なログイン・鍵の持ち出しといった初動で効く検知の大半が成立します。アプリケーションのアクセスログやデバッグログは後回しで構いません。実務ではまずこの3系統を入れ、既製の検出ルールを2週間回してから追加対象を決める順序が失敗しにくい。
CloudTrailをS3経由でForwarder Lambdaから送る構成の勘所
AWSからの送信は、公式のAWS構成ガイドが示す経路をそのまま踏むのが早道です。ガイドはCloudTrailを主対象に、次の順で組み立てます。
- CloudTrailの証跡を作成し、ログの出力先S3バケットを指定する
- Datadog Forwarder Lambdaをデプロイし、APIキーを設定する
- 対象S3バケットのイベントをトリガーとしてForwarder Lambdaに紐づける
- Datadog側でログが到着し、パイプラインで属性が展開されることを確認する
GuardDutyやVPCフローログなど他のAWSサービスは、ガイド本体では手順が展開されず、Lambda経由でAWSサービスのログを送る別ドキュメントへ委ねられています。つまり経路は共通で、増やすのはトリガー設定だけ。ここでAgentを新たに置く必要はないため、Datadog Agent導入の3方式とdatadog.yaml設定で組んだホスト監視の構成には手を入れず、マネージドサービス側の経路だけを足す形になります。
検出ルール3タイプと7種の検出方法から選ぶ実装レベルの判断基準
検出ルールは「タイプ」と「検出方法」の2軸で決まります。この2軸を混同したまま画面を触ると、リアルタイムに評価してほしい条件をスケジュール実行に載せてしまい、検知が数十分遅れる。
リアルタイム・スケジュール・履歴ジョブの3タイプを使い分ける軸
公式ドキュメントが定義するタイプは3つです。Real-time ruleは届いたログを継続的に監視・解析する。Scheduled ruleはあらかじめ決めた間隔で実行してログを解析する。Historical jobは過去のログに対して検出を走らせ、バックテストする用途になります。
使い分けの軸は「検知の鮮度が価値を持つか」です。ログイン失敗の連続や権限の付け替えは、鳴るのが30分後では意味が薄い。ここはReal-time一択。一方、月次で棚卸ししたい「未使用のIAMロールに動きがあったか」のような集計型はScheduledで足ります。新しいルールを本番投入する前にHistorical jobで過去1〜2か月へ当て、何件鳴るかを見てからOnにする。この一手間を挟むだけで、初日のノイズ流入をかなり抑えられます。
しきい値と新規値、異常検知、不可能な移動を選び分ける実装上の条件
検出方法は7種です。Threshold（しきい値）、New value（新規値）、Anomaly（異常検知）、Content anomaly、Impossible travel（不可能な移動）、Third party、Signal correlation（シグナル相関）。各ルールはMITRE ATT&CKの戦術と技術にマッピングされるため、カバレッジの穴もその軸で見えます。
| 検出方法 | 向く検知対象 | 設計時の注意 |
|---|---|---|
| しきい値（Threshold） | 失敗ログインの連続発生 | 母数の少ない環境で空振り |
| 新規値（New value） | 初出のIAMロール操作 | 学習期間中は誤検知が出る |
| 異常検知（Anomaly） | 平常比で跳ねたAPI呼出 | 季節変動の大きい系は不向き |
| 不可能な移動 | 短時間の遠隔地ログイン | VPN利用者を抑制対象に |
| 相関（Signal correlation） | 単体では弱い兆候の連鎖 | 元シグナルの精度が前提 |
実装で効くのは、New valueとImpossible travelを最初に入れないという判断です。どちらも「普段の姿」を前提に鳴るため、取り込みを始めた直後は正常な操作まで拾います。まずThresholdとThird partyで足場を作り、2週間分の平常値がたまってから学習型を足す。この順序を守るだけで、初期のトリアージ負荷は目に見えて下がります。
Content Packsの既製ルールを土台にして自作を最小化する進め方
Content Packsは、セキュリティチーム向けにキュレーションされたインテグレーションのまとまりです。中身は検出ルール、ダッシュボード、パーサー、SOARワークフローの一式。対象のログソースを有効にすると、対応する既製ルールがそのまま適用されます。
自作ルールは、既製ルールを一巡させたうえで「自社固有の資産名・命名規約に依存する条件」に限定してください。たとえば本番環境だけに付けたタグを条件に含める、といった形です。逆に「一般的な攻撃パターンを自分で書き起こす」のは、公式が継続的に追加している既製ルールと重複し、保守だけが残る。タグの命名規約を先に固めておくと自作ルールの条件式が短くなるため、Datadog運用のベストプラクティスのタグ設計を先に通しておくと後戻りが減ります。
セキュリティシグナルの調査動線と抑制ルールによるノイズ削減の設計
検知が動き始めると、次の争点は「鳴った後」に移ります。SIEM導入が形骸化する典型は、検知精度ではなくトリアージ導線の未整備から起きる。運用体制そのものの内製と外注の判断はSOCとは何かで整理しているため、ここでは製品機能に沿った動線設計に絞ります。なお、アプリケーション側のエラーを同じ発想で集約し、トレースやログの実データへ降ろす導線はDatadog Error Tracking実装手順にまとめました。
Open・Under Review・Archivedの3状態で回すトリアージ運用
シグナルのステータスは3種類です。未対応のOpen、調査中のUnder Review、解決済みのArchived。アーカイブ時には理由と説明を残せます。Signals Explorer側では重大度・検出ルール・MITRE ATT&CKでグループ化でき、可視化はRules List、Timeseries、Top List、Table、Pie Chartから選べる。
運用に落とすなら、@workflow.triage.state ファセットでOpenだけを絞り込んだ保存ビューを1つ作り、当番がそこだけを見る形にします。ケースを作成するとステータスが自動でUnder Reviewへ変わるため、担当のアサインとケース作成を同じ操作にまとめれば、状態遷移の記入漏れが構造的に起きません。Case ManagementとIncident Managementに統合されているので、重大な検知はそのままインシデント対応へ引き継げます。
抑制ルールとケース管理でシグナルの再燃と取りこぼしを封じる設計
誤検知は、ルールを止めるのではなく抑制ルールで削ります。Signals Explorerのファンネルアイコンから新規の抑制ルールを作成でき、既存のものはSuppressionsタブで一覧・編集できる。ルール自体を無効化すると、その検知観点が丸ごと消えます。
抑制の条件は、対象を特定できる属性に限定してください。脆弱性診断用の踏み台ホスト、CIの実行ロール、社用VPNの出口IP。この3つは実務でほぼ必ず抑制対象になります。逆に「重大度Mediumを全部抑制」のような粗い条件は、本物を落とすので採りません。通知はSlack、Jira、メール、Webhookへ接続でき、週次の脅威ダイジェストも購読できます。通知先の分け方そのものはDatadogモニターのタイプ選定と閾値設計の考え方をそのまま流用できます。
既存の監視基盤に相乗りする構成と専用SIEMへ切り替える損益分岐
Cloud SIEMの本質的な利点は、検知精度そのものより「ログの置き場が1つで済む」ことにあります。SIEMの一般的な仕組みとEDR・XDR・SOARとの機能差はSIEMとは何かで扱っているため、ここでは相乗り構成を選ぶ条件だけを言い切ります。
既存の監視基盤に相乗りする構成が有利になるチーム規模とログ量の目安
すでにDatadogでインフラとアプリを監視している組織なら、相乗りが有利です。判断条件は次の2つが同時に成り立つときと考えてください。専任のセキュリティ担当が2名以下で、インフラ運用チームが検知の一次受けを兼ねること。そして解析対象にしたいログが、すでにDatadogへ届いているクラウド監査ログとIdPログの範囲に収まること。
この条件下では、別基盤を立てる工数と学習コストが検知精度の差を上回ります。転送設定・パーサー整備・アカウント管理・アラート連携をもう一式作る手間は、初年度で数人月規模になる。同じ画面でメトリクスとトレースを横断できる利点も大きく、調査の初動が短くなります。
専用SIEMへ切り替える判断を分けるコンプライアンス要件と保管期間
専用SIEMを選ぶべき場面は明確です。第一に、監査要件でログの改ざん防止や長期保管の証跡が契約レベルで求められる場合。第二に、オンプレミスのネットワーク機器やIDS/IPSなど、Datadogのインテグレーションが薄い領域が検知対象の中心にある場合。第三に、SOCベンダーへ監視を委託しており、そのベンダーが特定製品での運用を前提にしている場合です。
この3つのいずれにも当たらないなら、専用SIEMは過剰投資になります。逆に1つでも当たるなら、Cloud SIEMは「クラウド側の検知」に限定し、残りは専用製品に任せる分業が現実的。なお保管の階層はStandard indexing、Flex Logs、Log Archivesの3つが用意されており、長期保管は安価な階層へ寄せて検索性を落とす前提で設計します。自社の要件がどちらに寄るか判断がつかない場合は、現状のログ資産と検知要件の棚卸しから入るのが安全で、脆弱性診断・セキュリティ診断のような外部評価を先に一度通すと、必要な検知範囲が具体的な資産名で確定します。
Cloud SIEMを採用しない判断が正解になる3つの条件と失敗パターン
導入を止めるべき状況を条件付きで示します。ここを曖昧にしたまま契約すると、鳴らないSIEMか、誰も見ないSIEMのどちらかになる。
ログをDatadogに集約していない環境で先にやるべき取り込み整備
Cloud SIEMは、届いていないログを検知できません。監査ログがS3に置かれたまま、IdPのログがベンダー画面にしかない状態で有効化しても、解析対象はほぼ空です。この場合に先にやるのは取り込み整備であって、SIEMの契約ではない。
順序としては、CloudTrailとIdPのログをDatadogへ届け、パイプラインで属性が展開されることを確認し、1週間分たまってからCloud SIEMを有効化します。この順で進めれば、有効化直後から既製ルールが実データで鳴るため、判断材料がその場で得られる。逆順で進めた現場は、契約から実データが揃うまでの1〜2か月を空回りで消費します。
検知後に動く人がいない体制でCloud SIEMを入れない判断の根拠
もう1つの見送り条件は、シグナルを閉じる担当が決まっていないことです。検知は自動化できますが、Under Reviewへ動かして原因を確認し、抑制するか対処するかを決める工程は人が担います。ここが空席なら、Openが積み上がるだけで検知は資産になりません。
週に1時間もトリアージへ割けない体制なら、Cloud SIEMより先に手を付けるべきものがあります。多要素認証の徹底、権限の棚卸し、公開資産の脆弱性診断。いずれも検知ではなく発生確率そのものを下げる施策で、人手を継続的に必要としません。SIEMは「検知したら動く」体制が先にあって初めて投資に見合う。この順序を飛ばした導入は、契約更新時にほぼ例外なく解約候補へ回ります。
よくある質問
Datadog Cloud SIEMの導入検討でよく挙がる論点を、公式ドキュメントの記述に沿って整理します。
Datadog Cloud SIEMは既存のログ管理契約だけで使えますか？
使えません。ログ管理はログを取り込んで保管する層、Cloud SIEMはその上でログを解析して検出ルールを適用する層で、課金も別枠になります。ログ管理の契約があれば取り込み経路の整備は済んでいる状態なので、追加で必要になるのはCloud SIEMの有効化と解析対象の指定です。逆に言えば、解析へ回すログを絞れば上乗せ分は制御できます。
Cloud SIEMを有効化してもシグナルが出ないのはなぜですか？
最も多いのはインデックスの並び順です。有効化時に作られる cloud-siem 専用インデックスは、公式手引きで一覧の先頭に置くよう指示されています。既存のインデックスが上にあると、インデックスフィルタが先に一致してログがそちらへ入り、解析対象に載りません。次に多いのが、そもそも監査ログやIdPログを送っていないケースです。
検出ルールは自分で書く必要がありますか？
初期段階では不要です。Content Packsに検出ルール・ダッシュボード・パーサー・SOARワークフローが一式で含まれ、対象のインテグレーションを有効にすれば既製ルールが適用される仕組みです。自作が要るのは、自社独自のタグや資産命名に依存する条件を足す場面に限られます。一般的な攻撃パターンの検知は既製ルール側で継続的に追加されるため、書き起こすと保守が二重になります。
誤検知が多いときはルールを無効化すべきですか？
無効化ではなく抑制ルールで対応します。ルール自体を止めると、その検知観点が丸ごと失われるためです。Signals Explorerのファンネルアイコンから抑制ルールを作成し、Suppressionsタブで管理します。抑制の条件は、診断用の踏み台ホスト、CI実行ロール、社用VPNの出口IPのように対象を特定できる属性へ限定し、重大度でまとめて落とす粗い条件は避けてください。
Cloud SIEMと専用SIEM製品はどちらを選ぶべきですか？
すでにDatadogで監視しており、検知対象がクラウド監査ログとIdPログの範囲に収まり、専任のセキュリティ担当が2名以下なら相乗りが有利です。一方、契約上の長期保管や改ざん防止の証跡が求められる場合、検知対象がオンプレミスのネットワーク機器中心の場合、SOCベンダーが特定製品前提の場合は専用SIEMを選びます。両方に当たる場合は、クラウド側だけをCloud SIEMに任せる分業が現実的です。
関連記事
- SIEMとは？仕組み・機能とEDR/XDR/SOARの違い：製品非依存でSIEMの仕組みと他カテゴリとの違いを押さえたいとき
- SOCとは？SIEM・SOARとの違いと監視運用の仕組み：検知後に動く監視体制を内製するか外注するかの判断に
- Datadogログ収集の3経路とパイプライン設計：解析へ回す前段の取り込みとインデックス制御を詰めるとき
- Datadogモニターのタイプ選定と閾値設計：シグナル通知と既存アラートの棲み分けを設計するとき
- Datadogとは何か？機能やメリット、導入の背景：製品全体の中でCloud SIEMの位置づけを確認したいとき
