「ログは取っているが活用できていない」を解消する SIEM導入前に整えるべきログ基盤の作り方SOC/SIEMを導入しても「ログがバラバラ」「形式が違う」では効果が出ない。SIEM導入前に整備すべきログ基盤の設計ポイント、収集すべきログの優先順位、AI活用によるアラート最適化まで解説

このような攻撃を「検知」するためにSIEM（Security Information and Event Management）を導入する企業が増えています。しかし、SIEMを入れただけでは検知できません。そもそも「ログがバラバラ」「形式が違う」「必要なログが取れていない」という状態では、SIEMは力を発揮できないのです。

本記事では、SIEM導入前に整備すべきログ基盤の設計ポイント、収集すべきログの優先順位、そしてAI活用によるアラート最適化まで解説します。読み終える頃には、「最優先で取るべきログ一覧」と「保存・正規化の設計観点」がそのまま社内の要件定義に使える状態になります。

1. SIEM導入で失敗する企業の共通点

「SIEMを入れれば安心」という誤解

SIEM（Security Information and Event Management）は、様々なシステムからログを収集し、相関分析を行い、セキュリティインシデントを検知するためのツールです。

近年、サイバー攻撃の高度化を受けて、SIEM導入を検討する企業が増えています。しかし、「SIEMを導入すれば、攻撃を検知できるようになる」という期待は、必ずしも正しくありません。

失敗パターン①：必要なログが取れていない

SIEMは、ログを分析するツールです。分析すべきログがなければ、何も検知できません。

よくあるのが、「ファイアウォールのログは取っているが、Active Directoryの認証ログは取っていない」というケースです。攻撃者がADを侵害しても、ログがなければ検知しようがありません。

失敗パターン②：ログ形式がバラバラ

各システムが出力するログの形式は様々です。Syslog形式、JSON形式、独自形式など、統一されていないことがほとんどです。

SIEMで相関分析を行うには、これらのログを**正規化（共通形式に変換）**する必要があります。この正規化が不十分だと、本来関連すべきイベント同士が紐づかず、検知ルールが機能しません。

失敗パターン③：アラートが多すぎて対応できない

SIEMを導入すると、大量のアラートが発生することがあります。1日に数千件のアラートが出ても、人間が対応できるのは精々数十件です。

「アラート疲れ」により、本当に重要なアラートが埋もれてしまい、結局インシデントを見逃す——これがSIEM導入の典型的な失敗パターンです。

【表】SIEM導入の失敗パターン

章末サマリー

• SIEMを入れただけでは攻撃は検知できない

• 「ログがない」「形式がバラバラ」「アラート過多」が失敗の3大原因

• SIEM導入前にログ基盤の整備が必要

2. ログ基盤とSIEMの関係を整理する

SIEMとログ基盤は、しばしば混同されます。両者の役割を整理しましょう。

ログ基盤の役割：集めて・揃えて・貯める

ログ基盤は、ログを「収集・正規化・保存」するためのインフラです。

ログ基盤の3つの機能：

SIEMの役割：分析して・検知する

SIEMは、ログを「分析・相関・検知」するためのツールです。

SIEMの3つの機能：

順番を間違えると投資が無駄に

SIEMは「ログを分析するツール」であり、分析すべきログがなければ機能しません。

┌─────────────────────────────────────────────────────────┐
│                                                         │
│  ログ基盤（土台）                                        │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐                 │
│  │  収集   │→│  正規化  │→│  保存   │                 │
│  └─────────┘  └─────────┘  └─────────┘                 │
│                     │                                   │
└─────────────────────┼───────────────────────────────────┘
                      │
                      ▼
┌─────────────────────────────────────────────────────────┐
│                                                         │
│  SIEM（分析・検知）                                      │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐                 │
│  │  分析   │→│  相関   │→│  検知   │                 │
│  └─────────┘  └─────────┘  └─────────┘                 │
│                                                         │
└─────────────────────────────────────────────────────────┘

SIEMを先に導入しても、ログ基盤が整備されていなければ、効果は限定的です。まずログ基盤を整え、その上にSIEMを構築する——この順番を守ることが成功の鍵です。

章末サマリー

• ログ基盤は「収集・正規化・保存」、SIEMは「分析・相関・検知」

• SIEMはログ基盤の上に成り立つ

• 順番を間違えると、SIEM投資が無駄になる

3. SIEM導入前に整備すべき3つのこと

SIEM導入を成功させるために、事前に整備すべき3つのポイントを解説します。

整備①：収集対象ログの優先順位付け

すべてのシステムからすべてのログを収集するのは、現実的ではありません。優先順位をつけて、重要なログから収集を始めます。

優先度の考え方：

まずは「認証ログ」「ファイアウォールログ」から始め、段階的に拡大するアプローチが現実的です。

整備②：ログ形式の統一（正規化）

各システムのログ形式は異なります。SIEMで相関分析を行うには、これらを共通形式に変換する必要があります。

正規化で統一すべき項目：

• タイムスタンプ： UTC統一、ISO 8601形式

• ソース情報： ホスト名、IPアドレス、サービス名

• イベントタイプ： ログイン成功/失敗、アクセス許可/拒否

• ユーザー情報： ユーザー名、メールアドレス、部門

正規化を行うことで、「Aシステムのログイン成功」と「Bシステムへのアクセス」を紐づけて分析できるようになります。

【実装のポイント】共通スキーマの活用

正規化を効率的に進めるには、既存の共通スキーマを活用するのが有効です。例えば、Elasticを利用する場合は**ECS（Elastic Common Schema）を前提にフィールド設計すると、相関ルールを組みやすくなります。Microsoft Sentinelを利用する場合はASIM（Advanced Security Information Model）**が標準です。これらのスキーマに合わせてログを正規化することで、検知ルールの作成・共有が容易になります。

整備③：保存期間・ストレージ設計

ログの保存期間とストレージ設計も重要です。

保存期間の目安：

ストレージ設計のポイント：

• ホットストレージ： 直近30日、高速検索用（Elasticsearch等）

• ウォームストレージ： 31〜90日、中速検索用

• コールドストレージ： 91日以降、アーカイブ用（S3 Glacier等）

保存期間が短いと、インシデント発覚時に「ログが消えていて調査できない」という事態になります。

章末サマリー

• 整備①：認証・ネットワーク境界から優先的にログ収集

• 整備②：タイムスタンプ・イベントタイプ等を正規化（ECS/ASIM等の共通スキーマ活用）

• 整備③：認証ログは1年以上保存、ストレージ階層化で効率運用

4. 収集すべきログの優先順位

具体的に、どのログを収集すべきかを整理します。

【チェックリスト】ログ収集状況の棚卸し

以下のチェックリストで、現状のログ収集状況を確認してください。

認証・アイデンティティ（最優先）

□ Active Directory / Azure AD のログイン成功/失敗ログ
□ VPN / リモートアクセスの認証ログ
□ 特権アカウント（管理者）の操作ログ
□ パスワード変更・リセットのログ
□ 多要素認証（MFA）のログ

ネットワーク境界（優先度高）

□ ファイアウォールの許可/拒否ログ
□ プロキシサーバーのアクセスログ
□ IDS/IPSのアラートログ
□ DNSクエリログ
□ Webアプリケーションファイアウォール（WAF）のログ

エンドポイント（優先度中）

□ EDR（Endpoint Detection and Response）のログ
□ アンチウイルス/アンチマルウェアのログ
□ Windows Event Log（セキュリティイベント）
□ macOS / Linux の認証ログ
□ USBデバイス接続ログ

クラウド環境（優先度中）

□ AWS CloudTrail
□ Azure Activity Log / Azure AD Sign-in Log
□ Google Cloud Audit Log
□ SaaSアプリケーションの監査ログ（Microsoft 365, Google Workspace等）

アプリケーション（優先度低〜中）

□ Webサーバーのアクセスログ（Apache, Nginx）
□ データベースのクエリログ
□ 業務アプリケーションの操作ログ
□ API呼び出しログ

【表】ログ収集の優先度マトリクス

※クラウド利用比率が高い企業では、CloudTrail / Activity Log / SaaS監査ログを「AD・FWと同等の最優先群」として扱うのが有効です。 オンプレミス中心の企業とは優先順位が変わる点に注意してください。

章末サマリー

• 認証・ネットワーク境界のログを最優先で収集

• AD認証、VPN、ファイアウォールは必須

• クラウド中心の企業はCloudTrail/Activity Logを最優先に引き上げる

5. 【応用編】AIを活用したアラート最適化

ログ基盤とSIEMを整備しても、「アラートが多すぎて対応できない」という課題は残ります。ここでは、AIを活用したアラート最適化について解説します。

アラート疲れ問題

SIEMは、設定したルールに基づいてアラートを発報します。しかし、ルールの設定が不適切だと、大量の誤検知（False Positive）が発生します。

典型的な状況：

• 1日に5,000件のアラートが発生

• セキュリティ担当者は2名

• 対応できるのは1日50件程度

• 残り4,950件は見られないまま放置

この状態では、本当に重要なアラートが埋もれてしまいます。

AIによる誤検知削減

AIを活用することで、アラートの優先順位付けと誤検知削減が可能になります。

AIが行うこと：

1. 異常スコアリング： 通常の行動パターンを学習し、逸脱度をスコア化

2. コンテキスト分析： ユーザー/資産の過去の行動と比較して異常度を判定

3. アラート統合： 関連するアラートをまとめて1つのインシデントとして表示

4. 推奨アクション提示： 対応すべきアクションを提案

これにより、ケースによっては「5,000件のアラート→50件の重要インシデント」まで絞り込めることがあります（環境・ルール設計・ログ品質により変動）。

【重要】AI活用の前提条件

AIの精度を出すには、以下の前提条件が必要です。

• 正規化されたログ： フィールドが統一されていないと、学習・分析が困難

• 資産・ユーザー属性（CMDB/ID情報）： コンテキスト分析に必須

• 一定期間の学習データ： 通常パターンを把握するため、最低2〜4週間のデータが必要

これらが整っていない状態でAI機能を有効にしても、期待した精度は出ません。まずログ基盤を整備し、その上でAI活用を検討するのが正しい順序です。

問い合わせ対応AIとの連携

さらに進んだ活用として、問い合わせ対応AI（チャットボット）との連携があります。

活用例：

• セキュリティアラートの初動対応をAIが自動化

• 「このアラートは対応済みですか？」の確認を自動化

• よくある問い合わせ（パスワードリセット等）を自動処理

• インシデント情報の自動収集・整理

これにより、セキュリティ担当者は本当に判断が必要な作業に集中できるようになります。

GXOの取り組み事例

GXO株式会社では、ログ基盤構築からSIEM導入、AI連携まで一貫して支援しています。

【事例】ログ基盤構築→SIEM導入→AI連携の一気通貫支援

ある中堅サービス業では、各システムのログがバラバラに管理されており、セキュリティインシデントの調査に数日かかっていました。また、SIEM導入を検討していましたが、「何から始めればいいかわからない」状態でした。

GXOでは、以下の支援を約16週間で実施しました。

1. Phase1（4週間）： ログ収集状況の棚卸し、優先順位付け、ログ基盤設計

2. Phase2（6週間）： ログ収集基盤構築（Fluentd + Elasticsearch）、ECSベースの正規化設定

3. Phase3（4週間）： SIEM導入（Elastic Security）、検知ルール設定

4. Phase4（2週間）： AI連携（異常スコアリング）、アラート最適化

結果として、インシデント調査時間が「数日→数時間」に短縮され、アラート対応も効率化されました。

※守秘義務のため、業種・規模・期間は一部変更しています。

章末サマリー

• SIEMのアラート過多は「アラート疲れ」を引き起こす

• AIによる優先順位付け・誤検知削減で対応可能件数に絞り込む

• AI活用には「正規化されたログ」「CMDB/ID情報」「学習データ」が前提

6. まとめ：ログ基盤はセキュリティ監視の土台

SIEMを導入しても、ログ基盤が整備されていなければ効果は限定的です。**「ログを取っているが活用できていない」**という状態は、多くの企業で見られます。

ログ基盤の整備は、SIEM導入の前提条件であり、セキュリティ監視の土台です。

本記事のポイント

1. SIEMを入れただけでは攻撃は検知できない
   ログ基盤（収集・正規化・保存）の整備が前提

2. 認証・ネットワーク境界のログから優先的に収集
   AD認証、VPN、ファイアウォールは必須（クラウド中心ならCloudTrailも最優先）

3. AIを活用してアラート疲れを解消
   優先順位付け・誤検知削減で対応可能件数に絞り込む（ただし前提条件あり）

SOC/SIEMを検討しているが、ログが散在していて「要件が決められない」企業は、まず「ログ基盤診断（2週間）」から始めるのが最短です。

GXO株式会社のご支援メニュー

GXO株式会社では、ログ基盤構築からSIEM導入、AI連携まで一貫して支援しています。

ご相談内容に応じた3つの入口

※「まずはどのログを取るべきか知りたい」といったご相談も歓迎です。

[📞 無料相談・ログ基盤診断のお申し込みはこちら →]

「最優先ログ一覧」と「次にやること」を1枚でお返しします。

FAQ

Q1. SIEM導入にはどのくらいの費用がかかりますか？

SIEM費用はログ量（EPS/GB/日）・保存期間・相関分析要件・運用体制（自社/外部SOC）で大きく変動します。クラウド型SIEMは多くの場合、データ取り込み量に応じた従量課金が中心です。まずは「最優先ログ（認証・境界）だけ」で小さく始め、運用を見ながら段階的に拡張するのが現実的です。費用を抑えるには、取り込み前のログフィルタリングや保存期間の階層化（ホット/ウォーム/コールド）が有効です。

Q2. 小規模な会社でもSIEMは必要ですか？

規模に関わらず、セキュリティ監視は必要です。ただし、小規模企業がいきなり高価なSIEMを導入するのは現実的ではありません。まずはログ基盤を整備し、クラウドサービスの監査ログ（AWS CloudTrail、Microsoft 365監査ログ等）を活用することから始めるのがおすすめです。

Q3. ログの保存期間はどのくらい必要ですか？

業界・規制によって異なりますが、一般的には認証ログは1年以上、ネットワークログは90日〜1年を推奨します。長期潜伏型の攻撃（APT）では、侵入から発覚まで数ヶ月〜1年以上かかることもあり、ログが残っていないと調査ができません。

Q4. SIEMとEDRの違いは何ですか？

EDR（Endpoint Detection and Response）は、PC・サーバー等のエンドポイントに特化した検知・対応ツールです。SIEMは、EDRを含む様々なシステムのログを統合し、全体を俯瞰して分析します。両者は補完関係にあり、EDRのログをSIEMに連携するのが一般的です。

Q5. ログ基盤だけ整備して、SIEMは入れないという選択もありますか？

はい、可能です。ログ基盤を整備するだけでも、インシデント発生時の調査能力は大幅に向上します。まずログ基盤を整備し、運用が安定してからSIEMを導入するという段階的アプローチは、特にリソースの限られた中堅企業では有効です。

参考資料

• NIST「SP 800-92: Guide to Computer Security Log Management」
  https://csrc.nist.gov/publications/detail/sp/800-92/final

• IPA「高度サイバー攻撃対処のためのリスク評価等のガイドライン」
  https://www.ipa.go.jp/security/guide/apt-guide.html

• 経済産業省「サイバーセキュリティ経営ガイドライン Ver 3.0」
  https://www.meti.go.jp/policy/netsecurity/mng_guide.html

• Elastic「Elastic Common Schema (ECS) Reference」
  https://www.elastic.co/guide/en/ecs/current/index.html

• Microsoft Learn「Advanced Security Information Model (ASIM) overview」
  https://learn.microsoft.com/en-us/azure/sentinel/normalization