SIEMによるフィッシング攻撃分析｜ログ相関とインシデント検知の自動化

SIEM導入によるフィッシング検知の全体像

従来の検知手法の限界

SIEM導入前の典型的なセキュリティ監視体制では、以下の構造的課題が存在します。

ログの分散と可視性の欠如

メールゲートウェイ、ファイアウォール、認証サーバー、Webプロキシがそれぞれ独立してログを記録し、管理コンソールも別々です。セキュリティアナリストが攻撃の全体像を把握するには、5-10個の異なるシステムにログインし、手動で情報を収集・突合する必要があります。この作業だけで1インシデントあたり2-4時間を要します。

手動相関分析の限界

人間が複数ログを目視で相関分析するには限界があります。例えば「従業員Aがフィッシングメールを開封→30分後に不審なURLをクリック→1時間後に異常な認証試行→2時間後に大量データダウンロード」という一連の攻撃チェーンを、手動で発見することは実質不可能です。日次数万件のイベントから、関連する5-10件を抽出する作業は、人手では対応できません。

検知の大幅な遅れ

多くの組織では、フィッシング攻撃の検知が事後対応になります。被害者からの問い合わせ（「パスワードが使えなくなった」）や、銀行からの不正送金通知で初めて攻撃に気づくケースが大半です。この時点で攻撃者は既に目的を達成しており、平均48-72時間が経過しています。**標的型攻撃（APT）**では、数ヶ月間潜伏されることもあります。

アラート疲労とリスクの見逃し

各セキュリティ製品が独立してアラートを発するため、SOCには1日数千件の通知が届きます。その99%は誤検知や低リスクイベントであり、アナリストは重要なアラートを見逃します。Verizonのデータ侵害調査報告書によると、検知システムがアラートを出していたにも関わらず対応されなかった事例が全体の68%を占めます。

SIEM導入による検知能力の飛躍的向上

SIEMは、これらの課題を根本的に解決し、フィッシング攻撃の検知・対応能力を劇的に向上させます。

指標	SIEM導入前	SIEM導入後	改善率
平均検知時間	48時間	15分	99.5%短縮
インシデント調査時間	4時間/件	30分/件	87.5%短縮
誤検知率	90%以上	20-30%	60-70pt改善
見逃し率	40-50%	5-10%	30-45pt改善
アナリスト対応可能件数	5-10件/日	30-50件/日	3-5倍向上
ログ保存期間	7-30日	1-3年	長期的分析可能

SIEMが解決する3つの核心的課題

1. ログの一元管理と統合可視化

SIEMは、組織内の全セキュリティデバイスとシステムからログを収集し、単一のデータベースに正規化して保存します。

統合前の状態:
- メールゲートウェイ: 独自フォーマットのログ、保存期間30日
- ファイアウォール: syslog形式、保存期間14日
- Active Directory: Windowsイベントログ、保存期間7日
- Webプロキシ: Apache形式、保存期間30日
→ フォーマットも保存場所も期間もバラバラ

統合後の状態:
- 全ログをSIEMに送信
- 共通データモデル（CIM）に正規化
- 統一インターフェースで検索
- 1-3年の長期保存
→ 単一クエリで横断検索が可能

この統合により、「先週、ドメインexample-phishing.comにアクセスした全従業員」を3秒で検索できます。従来は各システムに個別にログインして検索し、Excelで統合する作業に1時間以上かかっていました。

2. 自動相関分析とリアルタイム検知

SIEMの相関エンジンは、事前定義されたルールに基づき、複数のログイベントを自動的に関連付けます。

相関ルールの例:
IF (メールゲートウェイ: スパムスコア > 8 のメール受信)
AND (同じユーザーが30分以内にメール内URLをクリック)
AND (Webプロキシ: 未知ドメインへのアクセス)
AND (認証ログ: 15分以内に他の従業員がそのドメインにアクセス)
THEN アラート「組織内フィッシング拡散の可能性」
	 優先度: Critical
	 自動アクション: URLブロック、SOC通知

この相関分析は、毎秒数千件のイベントに対してリアルタイムで実行されます。人間が同じ分析を行うには、1日分のログで丸1日かかりますが、SIEMは即座に検知します。

3. インシデントレスポンスの高速化

SIEMは、検知だけでなくインシデント対応も支援します。

コンテキスト情報の自動収集

アラート発生時に、関連する全ての情報（ユーザープロファイル、過去のアクティビティ、資産情報、脅威インテリジェンス）を自動的に集約します。アナリストが手動で情報収集する時間を90%削減できます。

エスカレーションとチケット管理

重要度に応じて、適切な担当者に自動エスカレーションし、ServiceNowやJIRAに自動でチケットを作成します。対応漏れや優先順位の誤りを防ぎます。

対応履歴の一元管理

誰が、いつ、何を実施したかを全て記録します。コンプライアンス要件（SOX法、GDPR等）への対応や、事後分析（Post-Incident Review）が容易になります。

実装の前提条件

本ガイドでSIEMを効果的に運用するには、以下の準備が必要です。

項目	要件
対象規模	従業員500名以上（小規模はオープンソースSIEM推奨）
前提知識	ログ分析、SQLまたはクエリ言語、ネットワーク基礎
必要人員	専任1-2名、または兼任3-4名
初期構築期間	2週間（基本設定・重要ルール導入まで）
予算（年間）	Splunk: $50万-200万、Elastic: $20万-80万、Azure Sentinel: $10万-100万
ログ容量	従業員1,000名で1日50-100GB（圧縮前）

ランサムウェア対策やマルウェア感染検知にも同じSIEM基盤を活用できるため、フィッシング検知専用ではなく、統合セキュリティ監視基盤として投資対効果を評価すべきです。

---

フィッシング検知に必要なログソース

SIEMの検知精度は、取り込むログの種類と品質に直接依存します。予算と運用負荷を考慮し、優先度に応じて段階的に統合します。

必須ログソース（Priority A）

これらのログがなければ、フィッシング攻撃の基本的な検知すら困難です。SIEM導入の初日から統合すべきです。

1. メールゲートウェイログ（最重要）

フィッシング詐欺の大半はメール経由で侵入するため、メールログは最優先です。

必須フィールド

- 送信元: IPアドレス、ドメイン、メールアドレス
- 受信者: メールアドレス、部署、役職
- メール情報: 件名、本文（テキスト抽出）、添付ファイル名、サイズ
- セキュリティ判定: SPF/DKIM/DMARC結果、スパムスコア、マルウェアスキャン結果
- タイムスタンプ: 受信日時、配信日時

主要製品の連携方法

- Proofpoint: syslog、API
- Mimecast: API、ログファイル転送
- Microsoft Defender for Office 365: Graph API
- Barracuda: syslog、SNMP

検知可能な攻撃

メールフィッシング、スピアフィッシング、ホエーリング、BEC、添付ファイルによるマルウェア配布

2. Webプロキシログ（高優先）

フィッシングメールのリンククリック後の動作を追跡するために必須です。

重要フィールド:
- アクセスURL: 完全なURL、ドメイン、パス
- カテゴリ判定: 既知フィッシング、マルウェア配布サイト、未分類
- ユーザー情報: 認証されたユーザー名、IPアドレス
- HTTP情報: メソッド（GET/POST）、ステータスコード、User-Agent
- データ転送量: リクエストサイズ、レスポンスサイズ
- SSL/TLS検査: 証明書情報、暗号化プロトコル

主要製品: Zscaler、Cisco Umbrella、Forcepoint、Squid

検知可能な攻撃: URLベースフィッシング、ドライブバイダウンロード、C2通信（マルウェア感染後の遠隔操作）

3. 認証ログ（Active Directory、LDAP、SSO）

フィッシングで窃取された認証情報の不正使用を検知します。

Windows Active Directoryの重要イベントID

- 4624: ログイン成功
- 4625: ログイン失敗
- 4740: アカウントロックアウト
- 4768/4769: Kerberosチケット要求
- 4720: ユーザーアカウント作成

検知ポイント

- 通常と異なる時間帯のログイン（深夜、休日）
- 通常と異なる地理的位置（VPN: 東京→5分後にVPN: ロンドン）
- 短時間での大量ログイン失敗→成功（パスワードスプレー攻撃）
- 長期間未使用だったアカウントの突然のアクティブ化

SSOログ: Okta、Azure AD、OneLogin、Duo Securityのログも同様に重要です。クラウドサービスへの不正アクセスは、オンプレミスADよりも検知が困難なため、優先度を上げます。

4. WAF/IPS/IDSログ

フィッシングサイトへのアクセスや、攻撃者によるWebアプリケーション侵害を検知します。

検知シグネチャ例:
- SQLインジェクション試行
- XSS（クロスサイトスクリプティング）試行
- パストラバーサル攻撃
- 異常なHTTPヘッダー
- ボット判定（User-Agent、リクエスト頻度）

主要製品: Cloudflare WAF、AWS WAF、F5 BIG-IP ASM、Imperva、Palo Alto Networks

検知可能な攻撃: Webアプリケーション脆弱性を狙った攻撃、自動化されたクレデンシャルスタッフィング

5. エンドポイントログ（EDR: Endpoint Detection and Response）

フィッシングメール経由でマルウェアがダウンロードされた後の挙動を監視します。

EDRが提供する情報

- プロセス実行履歴: 実行ファイル名、コマンドライン引数、親プロセス
- ファイル操作: 作成、変更、削除、暗号化（ランサムウェアの兆候）
- ネットワーク通信: 外部IPへの接続、ポート番号、データ量
- レジストリ変更: 永続化メカニズムの検知
- メモリ分析: プロセスインジェクション、コードインジェクション

主要製品

CrowdStrike Falcon、Microsoft Defender for Endpoint、SentinelOne、Carbon Black、Trend Micro Apex One

この5つのログソースがあれば、フィッシング攻撃の検知・初動対応が可能です。

推奨ログソース（Priority B）

予算と運用体制が整い次第、以下を追加することで検知精度が向上します。

6. DNSクエリログ

フィッシングサイトへのアクセスや、DGA（Domain Generation Algorithm）を使用するマルウェアのC2通信を検知します。

検知パターン:
- 短時間での同一ドメインへの大量クエリ（DDoS準備、情報窃取）
- ランダム文字列ドメイン（DGA: asjdfklj234.com）
- 最近登録されたドメイン（登録から24時間以内）へのアクセス
- 通常と異なるDNSサーバーの使用（DNS tunneling）

実装: Windows DNS Server、BIND、Cisco Umbrella、Infoblox

7. VPNログ

リモートワーク環境では、VPN経由の不正アクセスが増加しています。

監視ポイント:
- VPN接続元国の変化（通常は日本→突然ロシアから接続）
- 同一アカウントの同時接続（物理的に不可能な距離）
- VPN接続後の異常な通信量（データ窃取の可能性）

8. クラウドサービスログ

Microsoft 365、Google Workspace、AWS、Azureのログは、クラウド時代の必須要素です。

サービス	重要ログ	検知対象
Microsoft 365	Azure AD Sign-in、Exchange Online、SharePoint	不正ログイン、メール転送ルール作成、大量ダウンロード
Google Workspace	Admin logs、Drive logs、Gmail logs	管理者権限変更、ファイル共有設定変更、外部転送
AWS	CloudTrail、VPC Flow Logs、GuardDuty	不正なAPI呼び出し、セキュリティグループ変更、異常なトラフィック
Azure	Activity Log、NSG Flow Logs、Azure AD	リソース削除、ネットワーク設定変更、認証

9. ファイアウォールログ

ネットワーク境界での通信を監視します。

検知例:
- 通常と異なる宛先国への通信（業務上必要のない国）
- 非標準ポートでの通信（8080、3389、4444等）
- 大量の外向き通信（データ窃取、ボットネット）

10. データベース監査ログ

フィッシング経由で侵入した攻撃者による、データベースへの不正アクセスを検知します。

監視対象:
- 大量のSELECTクエリ（データ窃取）
- 管理者権限での異常なアクティビティ
- 通常と異なる時間帯のアクセス
- 失敗したログイン試行の増加

ログ統合の優先順位付け

限られた予算と時間で最大の効果を得るため、以下の順序で統合を進めます。

フェーズ1（初日-1週目）:
1. メールゲートウェイ
2. Webプロキシ
3. Active Directory / SSO

フェーズ2（2週目-1ヶ月）:
4. WAF/IPS
5. EDR

フェーズ3（2ヶ月目-3ヶ月目）:
6. DNS
7. VPN
8. クラウドサービス（Microsoft 365/Google Workspace）

フェーズ4（4ヶ月目以降）:
9. ファイアウォール
10. データベース監査

---

主要SIEM製品の比較と選定

市場には20以上のSIEM製品が存在しますが、ここでは実績と導入事例が豊富な4製品を比較します。

詳細比較表

項目	Splunk Enterprise	Elastic Security	IBM QRadar	Azure Sentinel
価格（年間）	高（$1,800/GB/年）	中（$95/GB/月、OSSは無料）	高（$2,000-5,000/月）	中（$2/GB、従量課金）
学習曲線	急（1-2ヶ月）	中（2-4週間）	急（1-3ヶ月）	緩（1-2週間、KQL既知なら）
検索言語	SPL（独自言語）	KQL、Lucene	AQL（独自言語）	KQL（Azure共通）
ログ取り込み	Universal Forwarder（軽量）	Beats、Logstash	QRadar コレクタ	Log Analytics Agent
相関エンジン	優秀（リアルタイム）	良好（やや遅延あり）	優秀（最も高度）	良好（Cloud-native）
機械学習	Splunk ML Toolkit	Elastic ML（統合）	QRadar Advisor with Watson	Azure ML統合
SOAR統合	Phantom（同一ベンダー）	Elastic Security（一部機能）	Resilient（同一ベンダー）	Logic Apps、Sentinel Playbooks
推奨規模	大企業（1,000名以上）	中〜大企業（500-5,000名）	大企業、金融機関	Microsoft環境の全規模
主な強み	柔軟性最高、可視化優秀	コスト効率、検索速度	コンプライアンス、金融向け	Azure統合、導入速度
主な弱み	コスト高、ライセンス複雑	サポート（OSSは自己責任）	コスト高、柔軟性低	Microsoft依存、カスタマイズ制限

製品別の詳細解説

Splunk Enterprise：業界標準の包括的SIEM

Splunkは、SIEM市場で最大のシェアを持ち、大企業や政府機関で広く採用されています。

利点:

• SPL（Search Processing Language）の強力さ: 複雑な相関分析を柔軟に記述可能
• ダッシュボード作成が直感的で、経営層へのレポートも容易
• サードパーティアプリ（Splunkbase）が5,000以上あり、ほぼ全てのログソースに対応
• 技術者コミュニティが大きく、情報が豊富

欠点:

• ライセンスコストが高額（1日100GB取り込みで年間$6.5万-18万）
• データ量に応じた課金のため、予算管理が困難
• ライセンス違反（インジェスト量超過）のリスク

推奨ユースケース:

• 予算に余裕がある大企業
• 複雑な相関ルールを多数運用する必要がある組織
• 既存のSplunk環境がある場合

Elastic Security：コスト効率と拡張性のバランス

Elasticsearchベースのオープンソース由来のSIEMです。

利点:

• オープンソース版は無料（商用サポート・機能はサブスクリプション）
• 検索速度が非常に高速（分散検索アーキテクチャ）
• ログ量での課金ではなく、ノード数での課金が明確
• Kibanaによる可視化が優れている

欠点:

• OSSは自己サポート必須（技術力が必要）
• 相関ルールのリアルタイム性がSplunkよりやや劣る
• ドキュメントが分散しており、学習コストがやや高い

推奨ユースケース:

• 中規模企業（500-2,000名）
• コスト削減を重視
• 技術力のあるセキュリティチームがいる

IBM QRadar：金融・コンプライアンス重視

エンタープライズグレードで、金融機関や規制産業で高いシェアを持ちます。

利点:

• コンプライアンスレポート機能が充実（PCI DSS、GDPR、SOX等）
• 相関エンジンが最も高度（QRadar Offenses）
• Watson AI統合で、脅威の自動分析
• オンプレミス・クラウド両対応

欠点:

• 導入・運用コストが最も高額
• インターフェースが古く、使いにくい
• カスタマイズには専門知識が必要

推奨ユースケース:

• 金融機関、医療機関
• 厳格なコンプライアンス要件がある組織
• 既存IBMセキュリティ製品を使用している場合

Azure Sentinel：クラウドネイティブSIEM

Microsoftのクラウド型SIEMで、Azure環境との統合が最大の特徴です。

利点:

• インフラ構築不要（SaaS）、数日で開始可能
• Microsoft 365、Azure AD、Azure環境との深い統合
• KQL（Kusto Query Language）はAzure全体で共通
• 従量課金で、小規模から開始しやすい

欠点:

• Microsoft製品以外との連携がやや弱い
• カスタマイズの自由度がオンプレミスSIEMより低い
• データがAzureに保存されるため、規制対応の検討が必要

推奨ユースケース:

• Microsoft 365/Azure中心の環境
• クラウド移行を進めている組織
• 迅速な導入を重視

中小企業向けSIEM選択肢

従業員500名未満や、予算月額10万円以下の場合は、以下を検討します。

Wazuh（オープンソース）

OSSEC後継の無料SIEM。ログ収集、ルールベース検知、ファイル整合性監視（FIM）、脆弱性検知を統合。技術力があれば月額0円で運用可能。サポート契約は$5,000/年程度。

Sumo Logic

クラウド型SIEMで、無料プランは1日500MBまで。小規模スタートアップに適しています。有料プランは$90/月から。

LogRhythm Cloud

中小企業向けに最適化されたクラウドSIEM。月額$1,500程度から。導入支援が充実しており、初心者でも運用しやすい。

ManageEngine Log360

低価格な統合ログ管理ツール。SIEM専用ではないが、基本的なログ相関とアラート機能を提供。年間$5,000程度。

---

フィッシング検知の相関ルール設計

SIEMの検知精度を決定する最も重要な要素が、相関ルールの設計です。ここでは優先度別に代表的なルールを解説します。

ルール設計の基本原則

効果的な相関ルールは、以下の4要素をバランスさせます。

1. 検知率（True Positive Rate）: 実際の攻撃を検知する割合
2. 誤検知率（False Positive Rate）: 正常な行動を攻撃と誤判定する割合
3. レスポンスタイム: イベント発生から検知までの時間
4. 運用負荷: ルールのメンテナンスと調整にかかる時間

初期は検知率を重視し、運用しながら誤検知を削減していくアプローチが推奨されます。

緊急度：Critical（即座対応必要）

これらのルールが発火した場合、攻撃が進行中または直前の可能性が高く、15分以内の対応が必要です。

Rule 1: 認証失敗→成功→大量データダウンロード

攻撃シナリオ

攻撃者がフィッシングで窃取したパスワードでログインを試みますが、パスワード変更やMFAで一部失敗します。最終的に成功すると、内部データを迅速に窃取します。

検知条件（疑似ルール）

- 同一ユーザーアカウントで5回以上の認証失敗（15分以内）
- その後、認証成功
- 成功から10分以内に100MB以上のファイルダウンロード（SharePoint、ファイルサーバー等）

自動アクション

1. アカウントを即座にロック
2. SOC Critical アラート（Slack、PagerDuty）
3. CISO/CSOにエスカレーション
4. ダウンロードされたファイルのリストを取得
5. 同一IPからの他のアクセスをブロック

調整ポイント

開発者やデータアナリストは大量ファイル操作が正常業務のため、部署別に閾値を調整します（開発部: 500MB、営業部: 50MB等）。

Rule 2: 組織内での未知ドメインへの同時多発アクセス

攻撃シナリオ

**ビジネスメール詐欺（BEC）**や組織内フィッシングで、多数の従業員が同じフィッシングメールを受信し、短時間でリンクをクリックします。

検知条件

- 過去24時間以内に登録されたドメイン
- 15分以内に組織内50台以上のPCがアクセス
- ドメインカテゴリが「未分類」または「新規登録」

自動アクション

1. プロキシ/WAFで即座にURLブロック
2. アクセスした全PCでEDR詳細スキャン開始
3. 組織内全従業員に注意喚起メール配信
4. 脅威インテリジェンスにドメインを報告

Rule 3: 役員アカウントの異常地域ログイン

攻撃シナリオ

**ホエーリング攻撃**（経営層を標的としたフィッシング）で窃取された認証情報を使用し、攻撃者が海外から役員アカウントにログインします。

検知条件

- C-level（CEO、CFO、CTO等）またはVP以上のアカウント
- 過去30日間ログイン実績のない国からのアクセス
- または、物理的に不可能な距離を短時間で移動（東京→5分後→ニューヨーク）

自動アクション

1. ログインセッションを即座に終了
2. MFA再認証を強制要求
3. 本人に電話で確認（自動音声またはSOC担当者）
4. 確認取れるまでアカウント一時停止

誤検知対策

出張時のVPN使用、正規のリモートアクセスを事前登録する「旅行通知」機能を実装します。

Rule 4: メール転送ルールの自動作成

攻撃シナリオ

フィッシング経由でメールアカウントを侵害した攻撃者は、「全てのメールを外部アドレスに転送」するルールを作成し、継続的に情報を窃取します。

検知条件

- Microsoft 365またはGoogle Workspaceで新規メール転送ルール作成
- 転送先が外部ドメイン（組織ドメイン以外）
- ルール作成から5分以内に検知

自動アクション

1. 転送ルールを即座に削除
2. アカウントをロック
3. 過去24時間に転送されたメールを特定
4. ユーザーに通知（「あなたのアカウントが侵害された可能性」）

Rule 5: 管理者権限での異常なアクティビティ

攻撃シナリオ

**標的型攻撃（APT）**では、攻撃者は一般ユーザーアカウント侵害後、管理者権限への昇格を試みます。

検知条件

- Domain Admin、Enterprise Adminグループへのユーザー追加
- 通常の管理業務時間外（平日18時-翌朝8時、土日祝）
- 追加実行者が通常の管理者以外

自動アクション

1. 変更を即座にロールバック（可能な場合）
2. 全管理者にCritical通知
3. 変更実行PCのネットワーク隔離
4. フォレンジック調査開始

緊急度：High（24時間以内対応）

これらは攻撃の兆候であり、24時間以内の調査と対応が必要です。

Rule 6: フィッシングメール開封後の連鎖的行動

検知フロー:
1. スパムスコア8以上のメールを受信
2. 30分以内に同じユーザーがメール内URLをクリック（Webプロキシログ）
3. アクセス先ドメインが過去7日以内に登録
4. ページに入力フォームが存在（HTML解析）
5. ユーザーがフォームに情報を入力（POST リクエスト）

アクション:
- ユーザーに即座に警告通知
- パスワード変更を強制
- セキュリティ部門に調査依頼

Rule 7: 同一IPからの複数アカウントへのログイン試行

検知条件:
- 同一ソースIPから10個以上の異なるアカウントにログイン試行
- 15分以内
- パスワードスプレー攻撃の典型パターン

アクション:
- 送信元IPをファイアウォールでブロック
- 試行されたアカウントのパスワード強制変更
- 脅威インテリジェンスでIP評価

Rule 8: 通常と異なるファイル共有設定

検知条件:
- SharePoint、OneDrive、Google Driveで
- ファイル/フォルダを「組織外の誰でもアクセス可能」に変更
- 変更者の過去の行動パターンと不一致

アクション:
- 共有設定を自動で「組織内のみ」に戻す
- 変更者に確認
- 共有リンクが外部に流出していないか調査

緊急度：Medium（監視・傾向分析）

即座の対応は不要ですが、攻撃の前兆や傾向を把握するために重要です。

Rule 9: 短縮URL使用の急増

検知条件:
- bit.ly、tinyurl.com等の短縮URLクリック数
- 週次比較で200%以上増加

アクション:
- トレンドレポートを作成
- 従業員への注意喚起を検討
- 異常なドメインがないか詳細調査

Rule 10: 新規登録ドメインへのアクセス傾向

検知条件:
- 過去30日以内に登録されたドメインへのアクセス
- 日次でカウント、週次レポート

アクション:
- トップ10ドメインをレビュー
- 正当なサービス（新しいSaaS等）か確認
- 不審なものは予防的にブロック

ルールのライフサイクル管理

効果的なSIEM運用には、ルールの継続的な改善が不可欠です。

月次レビュー内容:
1. 各ルールの発火回数と誤検知率を集計
2. 発火0回のルールを特定→閾値調整または無効化
3. 誤検知率30%以上のルールを特定→チューニング
4. 新たな攻撃手口に対応するルール追加
5. 運用負荷の高いルールの自動化強化

ランサムウェアやデータ漏洩検知のルールも同様の手法で設計・管理します。

---

Splunkでのフィッシング検知実装

Splunkは最も広く使用されているSIEMであり、SPL（Search Processing Language）の柔軟性が特徴です。

SPL基礎と検索クエリ構造

SPLは、Unixのパイプ構文に似た直感的な構造です。

基本構造（概念レベル）:
index=<データソース> sourcetype=<ログタイプ>
| search <条件1> <条件2>
| stats <集計関数> by <グループ化フィールド>
| where <集計結果の条件>
| sort <並び替え>
| head <表示件数>

フィッシングメール検知の例（構造のみ）

# 高スパムスコアメールの受信者ランキング
index=email sourcetype=mailgateway
| where spam_score > 7
| stats count by recipient, sender_domain
| where count > 5
| sort -count
| head 20

# 説明:
# 1. メールゲートウェイログから
# 2. スパムスコア7以上のメールを抽出
# 3. 受信者と送信元ドメインで集計
# 4. 5件以上受信している組み合わせのみ
# 5. 件数の多い順に並び替え
# 6. 上位20件を表示

相関検索の実装

複数のログソースを結合（join）して相関分析を行います。

相関検索の構造（疑似コード）:
# フィッシングメール開封後のWeb アクセス相関

[サブサーチ1: フィッシングメール受信者リスト]
index=email spam_score>7
| fields recipient, email_timestamp

[サブサーチ2: その受信者のWebアクセス]
index=proxy
| join recipient
| where web_timestamp > email_timestamp
| where web_timestamp < email_timestamp + 30分

[結果]
| table recipient, email_subject, clicked_url, risk_score

ダッシュボードの設計

SOCアナリストが一目で状況を把握できるダッシュボードを構築します。

推奨パネル構成（6パネル）

1. リアルタイムフィッシング検知数（過去1時間）

- 棒グラフ: 10分ごとの検知件数
- 閾値表示: 正常範囲（緑）、注意（黄）、危険（赤）
- ドリルダウン: クリックで詳細ログ表示

2. 地理的分布マップ

- 世界地図: 送信元IPの位置をプロット
- サイズ: 送信件数に比例
- 色: リスクレベル
- 異常な国からの大量送信を視覚的に把握

3. 送信元ドメインランキング（Top 10）

- 表形式: ドメイン、件数、ブロック率、レピュテーションスコア
- ソート: 件数降順
- 新規ドメインをハイライト

4. 標的部署ランキング

- 円グラフ: 受信者の部署別割合
- 経営層、人事、経理が標的になりやすい
- 部署別のセキュリティ教育強化に活用

5. 検知ルール別アラート数

- 棒グラフ: 各相関ルールの発火回数
- 誤検知率も併記
- ルールチューニングの優先順位付けに使用

6. 対応ステータスサマリー

- カウンター: 未対応、調査中、対応完了、誤検知
- SLA達成率: 15分以内対応率
- 担当者別の対応件数

アラート設定とエスカレーション

Splunkのアラート機能で、自動通知とエスカレーションを設定します。

アラート疲労を避ける設計

アラート設定の原則:
1. Critical: 即座通知（PagerDuty、電話、Slack）、1日5件未満目標
2. High: 15分以内通知（Slack、メール）、1日20件未満目標
3. Medium: 1時間ごとにサマリー通知、1日100件未満目標
4. Low: 日次レポートのみ

抑制ルール（Throttling）:
- 同じルールが5分以内に3回発火→1件にまとめる
- 同一ユーザーの同種アラート→最初の1件のみ通知
- 計画メンテナンス中→全アラート抑制

優先度別の通知先

優先度	通知先	期待対応時間	エスカレーション
Critical	PagerDuty、Slack（@channel）、SOC担当者の携帯	15分以内	30分未対応→CISO通知
High	Slack、メール（SOC全員）	1時間以内	4時間未対応→マネージャー通知
Medium	メール（担当者）	8時間以内	24時間未対応→リマインダー
Low	日次レポート	1週間以内	なし

JIRA/ServiceNowへの自動チケット作成

チケット自動作成フロー:
1. Splunkアラート発火
2. WebhookでJIRA APIを呼び出し
3. チケット内容:
   - タイトル: アラート名、検知時刻
   - 説明: 影響を受けたユーザー、URL、ログの抜粋
   - 優先度: Splunkの優先度をマッピング
   - 担当者: ラウンドロビンで自動割り当て
4. チケット番号をSplunkに記録（相互参照）

---

Elastic Securityでの実装

Elastic Security（旧Elastic SIEM）は、ElasticsearchとKibanaをベースとした、コスト効率の高いSIEMです。

KQL（Kibana Query Language）の基本

KQLは、Splunkより簡潔で学習が容易な検索言語です。

基本構文（概念レベル）:
event.category: "authentication" and event.outcome: "failure"
| 認証失敗イベントを検索

source.ip: "192.168.1.0/24" and destination.port: 443
| 特定ネットワークからHTTPS通信を検索

@timestamp: [now-1h TO now] and process.name: "powershell.exe"
| 過去1時間のPowerShell実行を検索

Detection Rulesの作成

Elastic Securityは、事前定義された300以上の検知ルールを提供しますが、カスタムルールの作成も容易です。

ルールタイプの選択

Query（クエリベース）

KQLクエリで条件を定義します。最もシンプルで、大半のルールに使用します。「過去5分間に認証失敗が5回以上」等。

Threshold（閾値ベース）

特定イベントの発生回数が閾値を超えた場合に検知します。「同一IPから100回以上のログイン試行」等。

Event Correlation（イベント相関）

複数の異なるイベントタイプを時系列で相関分析します。「メール受信→URL クリック→認証試行」の連鎖等。

Machine Learning（機械学習）

Elastic MLで異常検知を行います。正常なベースラインから逸脱した行動を検知。「通常と異なる時間帯のログイン」「通常と異なるデータ転送量」等。

Elastic Common Schema（ECS）の活用

ECSは、異なるログソースを統一フォーマットに正規化するスキーマです。

ECS主要フィールド:
- user.name: ユーザー名（全ログソースで共通）
- source.ip: 送信元IP
- destination.ip: 宛先IP
- event.category: イベントカテゴリ（authentication、network、file等）
- event.action: 具体的なアクション（login、download、delete等）
- event.outcome: 成否（success、failure）

利点:
- クエリが単純化（ログソース毎に異なるフィールド名を覚える必要なし）
- 相関分析が容易（user.nameで全ログを横断検索）
- 可視化の再利用性（同じダッシュボードで異なる環境でも動作）

Machine Learning Jobsによる異常検知

Elastic MLは、教師なし学習で正常なパターンを学習し、異常を検知します。

推奨ML Job

Rare Process Execution（稀なプロセス実行）

組織内で稀にしか実行されないプロセスを検知します。フィッシング経由でダウンロードされたマルウェアの初回実行等を検知できます。

Unusual Login Time（異常なログイン時刻）

各ユーザーの通常ログイン時間を学習し、深夜や休日等の異常な時刻のログインを検知します。アカウント乗っ取りの兆候です。

High Data Transfer（大量データ転送）

各ユーザーの通常のデータ転送量を学習し、異常に多い転送を検知します。**データ漏洩**の可能性があります。

Anomalous URL Access（異常URLアクセス）

組織内で通常アクセスされないURLカテゴリへのアクセスを検知します。フィッシングサイト、マルウェア配布サイト等。

ML Jobの設定には2-4週間の学習期間が必要です。この間は誤検知が多いため、閾値を調整しながら運用します。

Elastic Agentによるエンドポイント監視

Elastic Agent（旧Endpoint Security）をPCに導入すると、EDR機能を提供します。

監視内容:
- プロセス実行履歴とコマンドライン
- ファイル作成・変更・削除
- レジストリ変更
- ネットワーク接続
- DLLロード

ランサムウェア検知例:
- 短時間で大量のファイル暗号化（拡張子変更）
- 身代金要求メッセージファイルの作成（README.txt等）
- ボリュームシャドウコピーの削除
→ 自動でプロセス停止、ネットワーク隔離

---

SOARによるインシデント対応自動化

SOAR（Security Orchestration, Automation and Response）は、SIEMで検知したインシデントへの対応を自動化します。

SOAR導入の効果

手動対応と自動対応の比較:

タスク	手動対応時間	SOAR自動化後	削減率
フィッシングメール全受信者検索	15分	30秒	97%
類似メールの削除	30分	2分	93%
URLのサンドボックス解析	10分	3分	70%
送信元IPのレピュテーション確認	5分	10秒	97%
全従業員への注意喚起メール	20分	1分	95%
合計	80分	6.5分	92%

SOCアナリストの負荷が10分の1になり、1日の対応可能インシデント数が5件から50件に増加します。

フィッシング対応プレイブックの設計

プレイブック（Playbook）は、インシデント対応の手順を自動化したワークフローです。

標準フィッシングプレイブック

トリガー: SIEMでフィッシングメール検知アラート

自動アクション（人間の介入なし）:
1. メール情報の取得
   - 送信者、件名、本文、添付ファイル、受信者リスト
2. 脅威インテリジェンス検索
   - VirusTotal、AlienVault OTX、MISP等で既知の脅威か確認
3. 類似メールの組織内検索
   - 同じ送信者または類似件名のメールを全受信トレイから検索
4. URLとファイルのサンドボックス解析
   - Any.run、Joe Sandbox等で自動解析
   - 悪意確認（C2通信、ファイル暗号化等）
5. 送信元IPのレピュテーション確認
   - AbuseIPDB、Spamhaus等で評価

人間判断ポイント:
→ 悪意確定 or 誤検知

悪意確定の場合の自動アクション:
6. 組織内全メール削除（Microsoft Graph API、Gmail API）
7. URLブロック
   - Webプロキシ（Zscaler、Cisco Umbrella）
   - WAF（Cloudflare、AWS WAF）
   - ファイアウォール
8. 送信元ドメイン/IPをブロックリストに追加
9. ドメインレピュテーション報告
   - PhishTank、APWG、Google Safe Browsingに報告
10. 従業員への注意喚起メール配信
	- テンプレートを使用、影響範囲（受信者数、開封数）を記載
11. インシデントチケット作成（JIRA/ServiceNow）
12. 事後レポート生成
	- 検知時刻、対応時刻、影響範囲、実施アクション

誤検知の場合:
- ホワイトリストに追加
- 検知ルールをチューニング

所要時間: 約5-10分（従来は1-2時間）

高度なプレイブック：BEC対応

ビジネスメール詐欺（BEC）は、経営層を装ったメールで送金を指示する攻撃です。

BEC検知トリガー:
- 役員（CEO、CFO等）を詐称したメール
- 「至急」「緊急」「秘密」等のキーワード
- 送金、振込、支払い等のキーワード
- 送信元ドメインが微妙に異なる（ceo@examp1e.com）

自動アクション:
1. メールを受信者の受信トレイから即座に隔離（未読の場合）
2. 本物の役員に確認（自動メールまたは電話）
3. 財務部門に警告
4. 類似メールの全組織検索
5. 過去のBECパターンと比較
6. 疑わしい送金取引がないか確認（銀行API連携）

人間判断:
- 本物の役員が「送信していない」と確認
→ メール削除、従業員教育、警察通報

- 本物の役員が「送信した」と確認
→ 誤検知、ホワイトリスト追加

主要SOAR製品の比較

製品名	価格帯	統合数	学習難易度	推奨SIEM
Splunk SOAR (Phantom)	高（$40万/年〜）	350+	中	Splunk
Palo Alto Cortex XSOAR (Demisto)	中-高（$30万/年〜）	500+	中	任意
IBM Resilient	高（$50万/年〜）	200+	高	QRadar
Swimlane	中（$20万/年〜）	200+	低	任意
Azure Logic Apps + Sentinel	低（従量課金、$5万/年〜）	400+	低	Azure Sentinel

中小企業には、Azure Logic AppsまたはSwimlaneが導入しやすく、コスト効率も優れています。

---

運用とチューニングのベストプラクティス

SIEMは導入がゴールではなく、継続的な運用と改善が成功の鍵です。

PDCAサイクルの実践

Plan（計画）

月次:
- 前月のKPI達成状況レビュー
- 新たな脅威トレンドの調査（JPCERT/CC、IPA等）
- 検知ルールの追加・変更計画
- アナリスト教育計画

四半期:
- SIEM導入効果の測定（ROI計算）
- ログソース追加の検討
- 予算見直し

Do（実行）

日次:
- アラート対応（優先度順）
- ダッシュボード確認
- 未対応チケットの進捗確認

週次:
- 誤検知率の高いルールの調整
- 新規ルールのテスト
- 脅威ハンティング（後述）

Check（評価）

主要KPI:
1. 平均検知時間（MTTD: Mean Time To Detect）
   目標: 15分以内、世界平均: 287日（IBM調査）
2. 平均対応時間（MTTR: Mean Time To Respond）
   目標: 1時間以内、世界平均: 80日
3. 誤検知率
   目標: 20%以下、初期は50-80%が一般的
4. 見逃し率（事後発覚したインシデント）
   目標: 5%以下、測定は困難だがペネトレーションテストで評価
5. SOCアナリスト1人あたり対応件数
   目標: 30-50件/日、SOAR導入前は5-10件/日

Act（改善）

改善アクション:
- 誤検知30%以上のルール→閾値見直しまたは無効化
- 発火0回のルール→実効性を再評価
- アナリストの負荷が高い→自動化強化（SOAR）
- 特定攻撃の見逃し→新規ルール追加

検知ルールの継続的改善

月次ルールレビュー

レビュー項目:
1. 各ルールの発火回数ランキング
2. 各ルールの誤検知率
3. 各ルールの重要度（実際の被害に繋がったか）
4. ルール間の重複（統合可能性）

意思決定:
- 発火0回 → 無効化または閾値緩和
- 誤検知50%以上 → 閾値厳格化または条件追加
- 重要度低 → 優先度ダウングレード
- 重複3件以上 → 統合ルール作成

脅威ハンティング（Threat Hunting）

受動的な検知だけでなく、能動的に過去ログから未検知の攻撃を探索します。

週次ハンティングテーマ例:
- 週1: 異常な認証パターン（時間帯、失敗回数）
- 週2: 疑わしいプロセス実行（powershell、wscript等）
- 週3: 大量データ転送（内部→外部）
- 週4: DNS異常クエリ（DGA、DNS tunneling）

手法:
1. 仮説を立てる（「攻撃者は○○の方法で侵入しているのでは」）
2. クエリを作成してログを検索
3. 異常パターンを発見
4. 誤検知か実攻撃か精査
5. 実攻撃なら緊急対応、誤検知なら知見として記録
6. 新たな検知ルールを作成

週4時間のハンティングで、月に1-2件の未検知攻撃を発見できれば、大きな成果です。

ログ保存とコンプライアンス

保存期間の設計

推奨保存期間:
- リアルタイム検索用（ホットストレージ）: 7-30日
  - SSD、高速検索、コスト高
- 調査用（ウォームストレージ）: 3-6ヶ月
  - HDD、検索やや遅い、コスト中
- コンプライアンス用（コールドストレージ）: 1-3年
  - クラウドアーカイブ（AWS Glacier、Azure Archive）、コスト低

法的要件:
- 金融機関（金融商品取引法）: 5年
- 医療機関（個人情報保護法）: 3年
- 一般企業（サイバーセキュリティ経営ガイドライン）: 1年以上推奨

圧縮とコスト最適化

コスト削減手法:
1. ログの選別（不要ログは取り込まない）
   - Debugレベルのログ→除外
   - 正常なhttpアクセスログ→サンプリング（10%のみ保存）
2. 圧縮（gzip、lz4）
   - 圧縮率: 5-10倍、検索速度への影響最小
3. フィールド削除
   - 使用しないフィールドを削除（User-Agent、Cookie等）
4. ティアリング
   - 30日経過後、自動でウォームストレージに移動
   - 180日経過後、自動でコールドストレージに移動

効果:
- ストレージコスト: 50-70%削減
- 検索速度: ほぼ変化なし（ホットストレージ内）

SOC要員のスキル向上

アナリスト教育プログラム

新人アナリスト（0-6ヶ月）:
- SIEM基礎トレーニング（Splunk、Elastic公式コース）
- ログ分析の基礎（TCP/IP、HTTP、DNS）
- 検知ルールの読み方
- インシデント対応手順書の理解

中堅アナリスト（6ヶ月-2年）:
- 高度なクエリ作成
- 検知ルールのチューニング
- 脅威ハンティング手法
- マルウェア解析基礎

シニアアナリスト（2年以上）:
- 新規ルール設計
- SOAR プレイブック作成
- ペネトレーションテスト対応
- チームリーダーシップ

外部資格:
- CompTIA Security+（入門）
- GIAC GCIA（侵入検知）
- GIAC GCIH（インシデントハンドリング）
- Certified SOC Analyst（CSA）

Purple Team演習

攻撃チーム（Red Team）と防御チーム（Blue Team）が協力して、検知能力を向上させます。

演習シナリオ例:
1. Red Teamがフィッシングメール送信
2. Blue TeamのSIEMで検知できるか確認
3. 検知できた→対応時間を測定
4. 検知できなかった→新規ルール作成
5. ルール追加後、再度攻撃実施
6. 検知成功→次のシナリオへ

頻度: 四半期に1回、1日間
効果: 実戦的なスキル向上、ルール品質向上

外部脅威インテリジェンスの活用

情報源:
- JPCERT/CC（日本）: インシデント報告、注意喚起
- IPA（情報処理推進機構）: 脅威動向レポート
- US-CERT（米国）: 脆弱性情報
- MITRE ATT&CK: 攻撃手法の体系的分類
- AlienVault OTX: コミュニティ脅威インテリジェンス

活用方法:
1. 新たなIoC（Indicators of Compromise）を取得
   - 悪意あるIP、ドメイン、ファイルハッシュ
2. SIEMに自動インポート
3. 過去ログから該当するアクセスがないか検索
4. 発見された場合、緊急対応

---

よくある質問

Q: 従業員1,000人規模の組織で、必要なログ容量と年間費用はどれくらいですか?

A: 1日あたり50-100GBが目安です。主な内訳は、メールゲートウェイ10GB、Webプロキシ20GB、Active Directory 5GB、エンドポイント15GB、その他10GBです。年間では18-36TBになります。Splunkの場合、1GBあたり$1,800/年なので、年間$90万-180万（圧縮前）です。ログ圧縮と不要ログの除外で50%削減可能なため、実質$45万-90万程度です。Elasticの場合、月額$9,000-18,000（年間$11万-22万）と、Splunkの約1/4のコストです。初期は重要ログのみ取り込み、段階的に拡大することでコストを抑えられます。クラウドSIEM（Azure Sentinel）なら従量課金で、月$5,000-10,000から開始できます。

Q: アラートが多すぎて対応しきれません。どう対処すべきですか?

A: 典型的な「アラート疲労」の問題です。初期導入時は誤検知率70-90%が一般的で、1日数千件のアラートが発生することもあります。解決策は4つあります。(1) ルールの厳格化: 閾値を引き上げて発火条件を厳しくします。「5回の失敗」を「10回の失敗」に変更する等。(2) 相関ルールによる統合: 関連する複数のアラートを1つにまとめます。「認証失敗」「認証成功」「大量ダウンロード」の3つのアラートを「アカウント侵害の疑い」1つに統合。(3) 重要度フィルタリング: CriticalとHighのみSOCに通知し、Medium以下は日次レポートにします。(4) SOAR自動対応: 明確に悪意と判定できるものは、SOARで自動対応し、アナリストは判断が必要なもののみ対応します。目標は1日100アラート以下、うち人間が対応するのは20-30件です。月次でルールレビューを実施し、継続的に誤検知率を下げることが重要です。

Q: SIEM専任担当者は必要ですか? 兼任では難しいでしょうか?

A: 理想は専任2-3名（シフト体制）ですが、中小企業では現実的ではありません。初期は兼任（情報システム部門のメンバーが1日2-3時間をSIEM運用に充てる）で開始し、アラート数と対応負荷に応じて増員が現実的です。外部SOCサービス（MSS: Managed Security Service）の利用も有力な選択肢です。月額30万-100万円で、24時間監視・初動対応を委託できます。社内は重要なインシデントの最終判断と対応のみ実施します。24時間監視が必要な場合、最低4名のシフト体制（3交代+予備1名）が必要で、人件費は年間3,000万円以上になります。これと比較すると、外部委託（年間360万-1,200万円）は経済的です。ハイブリッドモデル（平日日中は社内SOC、夜間休日は外部MSS）も効果的です。

Q: クラウドサービス（Microsoft 365、Google Workspace等）のログも取り込むべきですか?

A: はい、必須です。リモートワークの普及により、クラウドサービスが業務の中心になっています。特に以下のログは優先的に統合してください。(1) Microsoft 365: Azure AD Sign-in（認証）、Exchange Online（メール）、SharePoint（ファイル共有）、Teams（コミュニケーション）。(2) Google Workspace: Admin logs（管理操作）、Drive logs（ファイル操作）、Gmail logs（メール）。(3) AWS/Azure: CloudTrail/Activity Log（API呼び出し）、VPC Flow Logs（ネットワーク通信）、GuardDuty/Defender（脅威検知）。これらのログは、APIまたはSyslog転送で比較的容易に取り込めます。クラウドサービス経由のフィッシング攻撃、不正なファイル共有、アカウント乗っ取りは増加しており、オンプレミスのログだけでは不十分です。Microsoft 365 E5、Google Workspace Enterpriseには、ログ保存期間が長い（180日-1年）ため、早期に統合することを推奨します。

Q: 過去ログから未検知の攻撃を発見できますか? どのように実施しますか?

A: 可能です。これを「脅威ハンティング（Threat Hunting）」と呼びます。新たな検知ルールや攻撃手法の知見を得た際に、過去ログを遡及分析して、以前は見逃していた攻撃を発見します。実際、過去6ヶ月分のログ分析で、未検知のAPT攻撃（数ヶ月間潜伏）が発見される事例が多数あります。手順は以下の通りです。(1) 新たな攻撃手法の情報収集（MITRE ATT&CK、脅威インテリジェンス）。(2) 該当する攻撃の痕跡（IoC: Indicators of Compromise）を特定（特定のプロセス実行、レジストリ変更、通信先IP等）。(3) 過去ログ（通常30-180日分）をクエリで検索。(4) ヒットした場合、誤検知か実攻撃か詳細調査。(5) 実攻撃なら緊急対応（影響範囲特定、封じ込め、根絶）。(6) 新規検知ルールを作成し、今後は自動検知。週次で過去30日分のハンティングを推奨します。所要時間は週4時間程度で、月に1-2件の未検知攻撃を発見できれば大きな成果です。

Q: SIEMとEDR（Endpoint Detection and Response）の違いは何ですか? 両方必要ですか?

A: SIEMは「組織全体のログを統合分析」するシステムで、EDRは「エンドポイント（PC、サーバー）の詳細監視」に特化したシステムです。SIEMは広く浅く、EDRは狭く深く監視します。両方の導入が理想ですが、予算制約がある場合の優先順位は、組織規模と脅威モデルに依存します。従業員500名以上、または標的型攻撃のリスクが高い組織（金融、防衛、重要インフラ）は、両方必要です。従業員500名未満、一般的な脅威のみの組織は、まずEDRから導入し、将来SIEMに拡張することも可能です。最近のEDR（CrowdStrike、SentinelOne）は、SIEM機能を一部持つため、小規模組織にはEDRのみでも実用的です。しかし、メール、Webプロキシ、クラウドサービスのログは統合できないため、包括的な監視にはSIEMが必要です。理想的な構成は、SIEMで全体監視、EDRでエンドポイント詳細監視、SOARで自動対応です。

Q: SIEMの導入効果（ROI）はどのように測定すればよいですか?

A: ROIは「導入コストに対して、どれだけ被害を削減できたか」で測定します。計算式は以下の通りです。ROI = (削減できた被害額 - 導入・運用コスト) / 導入・運用コスト × 100%。具体例: 導入・運用コスト（3年間）: 初期構築300万円 + 年間運用120万円 × 3年 = 660万円。削減できた被害（推定）: フィッシング被害1件の平均被害額は280万円（警察庁統計）。SIEMで年間5件の攻撃を早期検知・阻止 → 280万円 × 5件 × 3年 = 4,200万円。ROI = (4,200万円 - 660万円) / 660万円 × 100% = 536%。ただし、「阻止できた攻撃」は仮定に基づくため、保守的に見積もることが重要です。他の測定方法として、(1) 平均検知時間の短縮（48時間→15分）、(2) インシデント対応時間の短縮（4時間→30分）、(3) SOCアナリストの生産性向上（5件/日→30件/日）を指標にすることも有効です。経営層への報告には、金額換算よりも、「検知できた攻撃の件数」「対応時間の短縮」を示す方が理解を得やすい場合もあります。

---

【重要なお知らせ】

• 本記事は一般的な情報提供を目的としており、個別の状況に対する助言ではありません
• SIEM構築・運用には専門的な知識と継続的なメンテナンスが必要です
• 実際にシステムを構築される場合は、セキュリティ専門家やSIEMベンダーにご相談ください
• 記載内容は作成時点（2025年11月）の情報であり、製品や価格は変更される可能性があります
• 本記事で言及した価格は一般的な目安であり、実際の契約条件により異なります
• クエリ例は構造の説明を目的としており、そのまま本番環境で使用しないでください

---