# GuardDuty vs Security Hub vs Detective vs Inspector vs Macie：AWS セキュリティサービスの役割分担と技術選定

> GuardDuty(検知)・Security Hub(集約と標準チェック)・Detective(調査)・Inspector(脆弱性)・Macie(データ分類)は競合ではなく多層防御の補完レイヤーです。各サービスの役割・扱うデータ・ライフサイクル上の位置を公式ドキュメント(2026年6月)に基づき整理し、混同しやすい違い、技術選定フレーム、EventBridge/Security Hub での連携設計まで解説します。

- 公開日: 2026-06-27
- 著者: 友田 陽大
- タグ: セキュリティ, AWS, GuardDuty, Security Hub, 技術選定
- URL: https://tomodahinata.com/blog/aws-guardduty-vs-security-hub-detective-inspector-macie-comparison-guide
- カテゴリ: Amazon GuardDuty 本番運用
- 総合ガイド: https://tomodahinata.com/blog/aws-guardduty-threat-detection-multi-account-terraform-eventbridge-guide

## 要点

- 5つは競合しない。GuardDuty=脅威検知、Security Hub=集約と標準チェック、Detective=根本原因調査、Inspector=脆弱性スキャン、Macie=機密データ分類——役割が重ならない補完レイヤー
- 混同の核は『何のデータに・何をするか』。GuardDuty はログから振る舞いを検知、Inspector はソフトウェアの CVE をスキャン、Macie は S3 の中身を分類。同じ『セキュリティ』でも対象も動作も別物
- Security Hub は検知エンジンではなく集約レイヤー。GuardDuty・Inspector・Macie・パートナー製品の finding を ASFF に正規化して並べ、AWS の標準/ベストプラクティスに照らす(標準チェックは AWS Config が前提)
- つながり方は『各サービス→finding→Security Hub / EventBridge→自動対応』。GuardDuty の finding は Detective に渡して根本原因をグラフで追える。点の検知を線の対応に変えるのが設計の山場
- スタートアップは GuardDuty + Security Hub から。機密データを S3 に置くなら Macie、CVE 管理が要るなら Inspector、深掘り調査が増えたら Detective を足す——資産と運用フェーズに合わせて積む

---

「GuardDuty を入れたんですが、これがあれば Security Hub も Inspector も Macie もいらない、って考えで合ってますか？」——AWS のセキュリティ設計を相談される場で、最も繰り返し聞く質問の一つです。

答えは「いいえ、全部いります（正確には、全部が**別の仕事**をしています）」。この誤解はとても自然です。コンソールの「セキュリティ」カテゴリには似た名前のサービスが並び、どれも「finding（検出結果）を出す」ように見えるからです。けれど中身を一行で並べると、競合していないことがすぐ分かります——**GuardDuty は脅威を「検知」し、Security Hub はその結果を「集約・優先順位づけ」し、Detective は「根本原因を調査」し、Inspector は「脆弱性をスキャン」し、Macie は「機密データを分類」する**。同じ「セキュリティ」でも、**見ているデータも、やっていることも、ライフサイクル上の位置も違います**。

この記事は、**この5つ（＋隣接する AWS Config）の役割分担を、相談相手（やクライアント）が二度と混同しないレベルまで言語化する**ためのガイドです。各サービスの「一言の仕事 / 扱うデータ / ライフサイクル上の位置」を固定し、混同しやすいペア（GuardDuty ≠ Inspector、GuardDuty ≠ Macie、Security Hub ≠ GuardDuty）を解きほぐし、「もし X が必要なら Y を使え」という意思決定フレームと、**EventBridge ＋ Security Hub でどう束ねて1つの防御体系にするか**までを通します。

GuardDuty 単体の本番設計（保護プラン選定・組織一括有効化・EventBridge 自動対応）は[別記事の本編](/blog/aws-guardduty-threat-detection-multi-account-terraform-eventbridge-guide)で扱っています。本記事はその一段上——**「AWS セキュリティサービスの地図」をどう描き、どこに何を置くか**に集中します。題材として、私がマルチアカウント AWS 上の[サーバーレス決済プラットフォーム](/case-studies/payment-platform-reliability)で IAM・可観測性・DR を横断実装した経験——**実際の金銭・カーボンクレジット・地域通貨を扱うため、検知・調査・脆弱性・データ保護の各レイヤーを別々の道具で固める必要があった**——という視点も交えます。

> **この記事のルール**：各サービスの定義・対象データ・ライフサイクル上の役割は **AWS 公式ドキュメント（2026年6月時点）** に基づきます。対応リソース・finding 種別・連携先・料金は改定されるため、本番投入前に必ず公式の最新情報を確認してください。そして本記事の一貫した主張——**これらは「どれが最強か」を競う代替品ではなく、多層防御（defense-in-depth）の補完レイヤーである**。「1つで全部」を狙う設計は、必ずどこかに穴が空きます。各サービスの**スコープを公式の記述から1ミリも誇張しない**ことを、自分への縛りとします。

---

## 0. メンタルモデル：5つは「動詞」が違う

設計の前に、5つ（＋1）を**一枚のマトリクス**で固定します。覚えるべきは名前ではなく「**動詞**」です。

| サービス | 一言の仕事（動詞） | 扱うデータ | ライフサイクル上の位置 |
| --- | --- | --- | --- |
| **GuardDuty** | **検知する**（detect） | CloudTrail 管理イベント・VPC Flow Logs・DNS ログ（＋保護プランのログ） | **侵害の最中**——「いま悪いことが起きている」を見つける |
| **Security Hub CSPM** | **集約・標準チェックする**（aggregate / assess） | 各サービス・パートナー製品の **finding**＋AWS Config の構成 | **横断的な可視化**——全 finding を1画面に集め、標準に照らす |
| **Detective** | **調査する**（investigate） | CloudTrail・VPC Flow Logs・EKS 監査ログ・GuardDuty finding（行動グラフ） | **検知の後**——「なぜ・どこまで侵害されたか」の根本原因 |
| **Inspector** | **脆弱性を評価する**（assess vulns） | EC2・ECR コンテナイメージ・Lambda の**ソフトウェア構成**と公開経路 | **侵害の前**——「攻撃される穴（CVE・露出）」を塞ぐための発見 |
| **Macie** | **機密データを分類する**（classify data） | **S3 オブジェクトの中身**とバケットの公開/暗号化設定 | **データ層**——「どこに機密（PII 等）があり、危険か」を可視化 |
| （隣接）**AWS Config** | **構成を追跡する**（track config） | AWS リソースの設定・変更履歴 | **構成の真実源**——Security Hub の標準チェックの土台 |

この表が本記事の全てです。以降の章は、この一行ずつを**公式の言葉で裏取りし、混同を解き、つなげる**だけです。3つの帰結を先に置きます。

1. **動詞が違うものは競合しない。** 「検知（GuardDuty）」と「脆弱性評価（Inspector）」は、同じ脅威に対して**別の角度**から働きます。片方が片方を代替することはありません。
2. **Security Hub だけ毛色が違う。** Security Hub は新しい脅威を「検知」しません。**他の4つ（＋パートナー）が出した finding を集める集約レイヤー**であり、加えて AWS の標準に照らす posture チェッカーです。「検知エンジン」と並べて優劣を語るのが、そもそもの誤解の源です。
3. **5つは finding でつながる。** 各サービスが出す finding は、**Security Hub に集約**され、**EventBridge で自動対応に流れ**、**GuardDuty の finding は Detective で深掘り**できます。バラバラの道具ではなく、**1本のパイプライン**として設計します（7章）。

### 0.1 「detect / aggregate / investigate / assess / classify」マトリクス

もう一段だけ解像度を上げます。横軸を**セキュリティ運用の動作**、縦軸を**ライフサイクル**で切ると、5つ（＋Config）が**一切重ならず棲み分けている**のが見えます。これが「どれが最強か」という問いが成立しない理由です。

| 動作 ＼ ライフサイクル | 侵害の前（予防的） | 侵害の最中（ランタイム） | 侵害の後（対応） |
| --- | --- | --- | --- |
| **detect（検知）** | — | **GuardDuty**（ログの振る舞い） | — |
| **assess（評価）** | **Inspector**（CVE・露出） | — | — |
| **classify（分類）** | **Macie**（S3 の機密データ） | — | — |
| **aggregate（集約・標準）** | **Security Hub**（標準チェック＝予防的） | **Security Hub**（全 finding を集約） | **Security Hub**（対応の起点） |
| **investigate（調査）** | — | — | **Detective**（根本原因） |
| **track（構成追跡）** | **AWS Config**（構成の真実源） | — | — |

読み取り方：

- **縦に1列読むと**「そのフェーズで何を使うか」が分かる。例：侵害の最中は **GuardDuty で検知 → Security Hub で集約**。侵害の後は **Detective で調査**。
- **横に1行読むと**「その動作はどのサービスの専売か」が分かる。**検知は GuardDuty だけ、調査は Detective だけ、分類は Macie だけ**——役割が一意。
- **Security Hub だけが全フェーズに横たわる**。これが「Security Hub は他と毛色が違う（集約レイヤー）」ということの図解です。

---

## 1. GuardDuty：ログから「振る舞いの脅威」を検知する

> **一言**：GuardDuty は **threat detection service**。AWS のログ（CloudTrail 管理イベント・VPC Flow Logs・DNS ログ）を継続的に解析し、脅威インテリジェンスと ML で「悪意ある／異常な振る舞い」を検知して finding を出す、**エージェントレスの検知エンジン**。

公式は GuardDuty を *"a threat detection service that continuously monitors, analyzes, and processes AWS data sources and logs"* と定義します。検知できる代表シナリオは、**漏洩した AWS 認証情報の悪用・データ持ち出し・不正なクリプトマイニング・マルウェア・EKS/ECS/EC2 上の不審な OS/ネットワーク/ファイルイベント**など。

ここで決定的なのは **「ログの振る舞いを見る」** という点です。GuardDuty は「ソフトウェアに既知の脆弱性があるか」を調べません（それは Inspector）。「S3 の中に PII があるか」も調べません（それは Macie）。GuardDuty が答えるのは **「いま、悪意あるアクターが動いていないか？」** という**ランタイムの振る舞い**の問いです。

- **扱うデータ**：基盤データソース（CloudTrail 管理イベント・VPC Flow Logs・DNS ログ）を**独立した複製ストリーム**として消費。保護プラン（S3 データイベント・EKS 監査ログ・RDS ログイン・Runtime Monitoring・Lambda ネットワーク等）を足すと監視対象が広がる。
- **ライフサイクル上の位置**：**侵害の最中**。予防（prevention）ではなく検知（detection）。攻撃を止めるのは [WAF](/blog/waf-defense-in-depth-aws-waf-cloud-armor-owasp-guide) や IAM の仕事。
- **特筆**：**Extended Threat Detection** が追加費用ゼロで自動オンになり、弱いシグナルを相関させて多段攻撃を1つの「攻撃シーケンス（必ず Critical）」finding に束ねる。詳細は[攻撃シーケンス finding の記事](/blog/aws-guardduty-extended-threat-detection-attack-sequence-findings-guide)へ。

GuardDuty を**入口**として、残り4つが「検知の前・後・横」を埋めます。GuardDuty 本体の組織一括有効化・保護プラン選定・EventBridge 自動対応の実装は、[本編ガイド](/blog/aws-guardduty-threat-detection-multi-account-terraform-eventbridge-guide)に Terraform/Python の実コードで通してあります。

---

## 2. Security Hub CSPM：finding を集約し、標準に照らす（検知はしない）

> **一言**：Security Hub CSPM は **「セキュリティ状態の包括ビュー」**。GuardDuty・Inspector・Macie・パートナー製品の finding を **ASFF（AWS Security Finding Format）に正規化して集約・優先順位づけ**し、加えて環境を **AWS の標準/ベストプラクティスに照らしてチェック**する。**検知エンジンではない。**

ここが最も混同される一点です。Security Hub を「もう一つの検知サービス」と捉えると設計を誤ります。公式の定義は *"provides you with a comprehensive view of your security state in AWS and helps you assess your AWS environment against security industry standards and best practices"*。やっていることは大きく2つ：

1. **集約（aggregate）**：*"receives findings from other AWS services—such as Amazon GuardDuty, Amazon Inspector, and Amazon Macie—and supported third-party products"*。バラバラの形式の finding を **ASFF という単一フォーマットに正規化**し、プロバイダ横断で**相関・優先順位づけ**して「single pane of glass（一枚のガラス窓）」を作る。
2. **標準チェック（assess against standards）**：**FSBP（AWS 基礎セキュリティベストプラクティス）・CIS・PCI DSS・NIST** などの標準に対し、各コントロール（ベストプラクティス）の合否を**コントロール finding**として出し、**セキュリティスコア**を算出する。

そして見落としやすい前提——**標準チェックの大半は AWS Config に依存します**。公式は *"Security Hub CSPM uses service-linked rules from AWS Config to run security checks for most controls. ... You must enable AWS Config and record resources in AWS Config for Security Hub CSPM to generate most control findings"* と明記。つまり **Security Hub の posture チェックを動かすには AWS Config の有効化が事実上の前提**です（ここが「Config は隣接サービス」と本記事が言う理由）。

- **扱うデータ**：他サービス／パートナーの **finding**（ASFF）＋ AWS Config の構成記録。
- **ライフサイクル上の位置**：**横断レイヤー**。検知の「前後」ではなく、全レイヤーの結果を**集めて並べる**場所。
- **自動化**：自動化ルール（automation rules）で finding を更新/抑制でき、**EventBridge 連携で自動対応をトリガー**できる。

> **設計への含意**：GuardDuty と Security Hub は「どちらか」ではなく**両方**です。GuardDuty が「検知の手」なら、Security Hub は「全部の検知結果を載せる机」。**Inspector も Macie も、その findings は最終的にこの机（Security Hub）に集まる**ので、運用の中心ハブとして最初に据える価値があります。

---

## 3. Detective：検知の「後」、根本原因をグラフで調査する

> **一言**：Detective は **「分析・調査して根本原因を素早く特定する」** サービス。AWS のログを自動収集し、**ML・統計分析・グラフ理論**で行動グラフ（behavior graph）の可視化を作り、調査を速くする。**検知ではなく調査。**

GuardDuty が「赤いアラートを出す」ところで終わるなら、その先の **「で、結局どこまでやられたの？ きっかけは？」** に答えるのが Detective です。公式は *"helps you analyze, investigate, and quickly identify the root cause of security findings or suspicious activities"* と定義し、*"uses machine learning, statistical analysis, and graph theory to generate visualizations"* と続けます。

- **扱うデータ**：CloudTrail・VPC Flow Logs・EKS 監査ログを**自動抽出**し、**GuardDuty の finding を取り込んで**行動グラフを構築。**最大1年分の履歴**にアクセスでき、活動量の変化を時系列で追える。
- **ライフサイクル上の位置**：**検知の後（インシデントレスポンス）**。新しい脅威を見つける装置ではなく、**見つかった脅威の文脈・範囲・原因を解く**装置。
- **連携**：GuardDuty・Security Hub CSPM の統合により、**finding から Detective コンソールへ直接ピボット**できる。高重大度の GuardDuty finding は「finding groups」で根本原因を分析可能。

ここを混同しないこと——**GuardDuty「検知」と Detective「調査」は前後関係であって競合ではありません**。「GuardDuty があるから Detective は不要」ではなく、**「GuardDuty が点を打ち、Detective が線を描く」**。決済基盤のように「異常を検知したら、被害範囲を時間内に確定して報告する」必要がある環境では、Detective の有無が**インシデント対応の所要時間**を直接左右します。

> **コスト観点**：Detective は分析イベント量に対する従量課金で、新規有効化時に30日無料トライアルが付きます。**全社で常時フル稼働させる**より、**「GuardDuty の高重大度 finding が出たときに深掘りする道具」**として位置づけるのが費用対効果で勝ちやすい設計です。

---

## 4. Inspector：侵害の「前」、ソフトウェアの脆弱性をスキャンする

> **一言**：Inspector は **vulnerability management service**。**EC2・ECR コンテナイメージ・Lambda** を自動で発見し、**ソフトウェアの脆弱性（CVE）と意図しないネットワーク露出**を継続スキャンする。**振る舞いの検知ではなく、脆弱性の評価。**

ここが GuardDuty と最も混同されるペアです。両方「セキュリティの問題を finding で出す」ので同じに見えますが、**問いが正反対**です。

- **GuardDuty の問い**：「**いま**、悪いことが**起きているか**？」（ログ上の振る舞い）
- **Inspector の問い**：「**もし攻撃されたら**、悪用される**穴があるか**？」（ソフトウェアの構成）

公式は Inspector を *"a vulnerability management service that automatically discovers workloads and continually scans them for software vulnerabilities and unintended network exposure"* と定義。新しいパッケージのインストール・パッチ適用・**新しい CVE の公開**などの変化に応じて**自動で再スキャン**し、NVD/CVSS を環境に合わせて調整した**リスクスコア**を付けます。修正すれば finding を**自動でクローズ**します。

- **扱うデータ**：**ワークロードのソフトウェア構成**（インストール済みパッケージ／コンテナイメージの中身）と**ネットワーク到達経路**。ログの振る舞いは見ない。
- **ライフサイクル上の位置**：**侵害の前（予防的アセスメント）**。攻撃される前に穴を塞ぐための発見。
- **連携**：finding を **EventBridge に発行**。Security Hub CSPM を有効化していれば **Inspector の finding も Security Hub に集約**される。

> **混同の核**：**GuardDuty ≠ Inspector**。「ログ上の脅威検知」 vs 「ソフトウェアの脆弱性スキャン」。前者は**攻撃者の行動**を、後者は**攻撃者に渡しうる弱点**を見ます。Log4Shell のような CVE が出たとき、「自社のどのイメージ/インスタンスが該当するか」を答えるのは GuardDuty ではなく **Inspector** です。

---

## 5. Macie：データ層、S3 の「中身」を分類する

> **一言**：Macie は **data security service**。**ML とパターンマッチ**で S3 オブジェクトの中身から**機密データ（PII・金融情報・認証情報等）を発見・分類**し、加えて S3 バケットの公開/暗号化設定を評価する。**脅威検知ではなく、データ分類。**

Macie だけ、見ている場所が他と決定的に違います。GuardDuty/Inspector/Detective が「**ログ・構成・振る舞い**」を見るのに対し、**Macie は「S3 オブジェクトの中身そのもの」**を見ます。公式定義は *"a data security service that discovers sensitive data by using machine learning and pattern matching, provides visibility into data security risks, and enables automated protection against those risks"*。

- **扱うデータ**：**S3 オブジェクトの中身**（managed data identifiers／カスタム識別子で PII・金融情報・認証情報などを検出）＋ **S3 バケットの公開/暗号化/アクセス制御設定**。
- **ライフサイクル上の位置**：**データ層**。「どこに機密データがあり、それが危険な状態（公開バケット等）にないか」を可視化。
- **2種の finding**：機密データ finding（オブジェクトに機密が見つかった）と policy finding（バケットの公開等、設定上の問題）。
- **連携**：finding を **EventBridge と Security Hub CSPM に発行**。

> **混同の核**：**GuardDuty ≠ Macie**。「振る舞いの脅威検知」 vs 「データの分類」。GuardDuty は「**誰かが** S3 から大量持ち出しを試みている」という**行動**を見ます。Macie は「**そもそもその S3 に** クレジットカード番号が平文で入っている」という**中身**を見ます。**「持ち出されたら困るデータがどこにあるか」を知らないと、GuardDuty の S3 アラートの深刻度も判断できません**——両者は補完関係です。

---

## 6. 隣接：AWS Config は「構成の真実源」

5つの主役の外側に、**AWS Config** を一行で置きます。Config は finding を出す検知/調査サービスではなく、**AWS リソースの設定・変更履歴を継続的に記録する「構成の真実源」**です。本記事で重要なのは1点だけ——**Security Hub CSPM の標準チェック（コントロール）の大半は Config に依存します**（2章）。

つまり実運用では、「Security Hub を有効化したのにコントロール finding がほとんど出ない」とき、**真因は Config 未有効化**であることが多い。Security Hub を posture チェッカーとして使うなら、**Config の有効化とリソース記録を前提**に設計します。Config は本記事の主役5つの「動詞（検知/集約/調査/評価/分類）」とは別カテゴリの「track（追跡）」なので、**隣接コンテキスト**として扱います。

---

## 7. つなぎ方：finding → Security Hub / EventBridge → 自動対応

役割分担が分かったら、次は **「バラバラの5つを1本の防御パイプラインにする」** 配線です。鍵は2つ——**Security Hub（集約のハブ）**と **EventBridge（自動対応のバス）**。各サービスは独立して finding を出しますが、それを**1箇所に集めて行動に変える**ことで初めて運用に載ります。

### 7.1 アーキテクチャ（テキスト図）

```text
                          ┌──────────────────────────────────────────────┐
   [ 侵害の前 ]           │            検知 / 評価 / 分類のレイヤー         │
                          │                                              │
   Inspector ───CVE/露出──┤                                              │
   (EC2/ECR/Lambda)       │                                              │
                          │                                              │
   [ データ層 ]           │                                              │
   Macie ─────機密データ──┤   各サービスが finding を生成                  │
   (S3 の中身)            │            │                                 │
                          │            ▼                                 │
   [ 侵害の最中 ]         │   ┌─────────────────────┐                    │
   GuardDuty ──脅威検知───┼──▶│  EventBridge (バス)  │──▶ Lambda 自動対応 │
   (ログの振る舞い)       │   └─────────────────────┘   (隔離/通知/ticket)│
        │                 │            │                                 │
        │ finding         │            ▼                                 │
        │                 │   ┌─────────────────────┐                    │
        └─────────────────┼──▶│ Security Hub CSPM    │  ← Inspector       │
                          │   │ (集約・ASFF正規化・  │  ← Macie           │
   [ 構成の真実源 ]       │   │  標準/ベストプラクティス│  ← パートナー製品  │
   AWS Config ───構成─────┼──▶│  チェック・優先順位)  │                    │
                          │   └──────────┬──────────┘                    │
                          └──────────────┼───────────────────────────────┘
                                         │ 高重大度 finding をピボット
                                         ▼
   [ 侵害の後 ]                  ┌─────────────────┐
   Detective ◀───────────────────│  根本原因の調査  │ (行動グラフ・最大1年)
   (調査)                        └─────────────────┘
```

ポイントは3つ：

1. **Security Hub が「机」**：GuardDuty・Inspector・Macie・パートナーの finding が**すべて**ここに集まり、ASFF で正規化されて並ぶ。AWS Config が標準チェックの土台を供給する。
2. **EventBridge が「行動」**：finding の発生を near-real-time で受け、**通知・隔離・チケット化**などの自動対応へ流す。GuardDuty・Inspector・Macie はいずれも EventBridge に finding を発行できる。
3. **Detective が「深掘り」**：GuardDuty/Security Hub の高重大度 finding から**ピボット**して、根本原因をグラフで追う。

### 7.2 連携の整理表

| 出す側（finding 生成） | Security Hub に集約 | EventBridge に発行 | Detective で深掘り |
| --- | --- | --- | --- |
| **GuardDuty** | ○ | ○ | ○（finding を取り込み行動グラフ化） |
| **Inspector** | ○ | ○ | —（脆弱性は調査対象外） |
| **Macie** | ○ | ○ | —（データ分類は調査対象外） |
| **Security Hub 自身**（標準チェック） | （集約元） | ○（自動化・カスタムアクション） | — |
| **AWS Config** | （標準チェックの土台） | ○（構成変更イベント） | — |

> **設計の勘所**：自動対応のトリガーを「サービスごと」にバラバラに作ると配線が増えて壊れます。**EventBridge のイベントパターンで `source`（`aws.guardduty` / `aws.inspector2` / `aws.macie` …）と重大度で振り分ける**のが定石。破壊的な封じ込めは「型の許可リスト × 高重大度」に絞り、冪等・取り消し可能な操作から始める——この自動対応の実装パターンは[自動修復・インシデント対応の記事](/blog/aws-guardduty-eventbridge-automated-remediation-incident-response-guide)に Terraform/Python で通してあります。

---

## 8. 意思決定フレーム：「X が必要なら Y を使え」

ここまでの役割分担を、**「やりたいこと」起点の早見表**に畳みます。相談の場で最も効くのはこの形です。

| やりたいこと（必要 X） | 使うサービス（Y） | なぜ |
| --- | --- | --- |
| 認証情報の悪用・不正 API・クリプトマイニングなど**振る舞いの脅威を検知**したい | **GuardDuty** | ログ（CloudTrail/VPC Flow/DNS）の振る舞いを ML＋脅威インテルで検知 |
| 複数サービスの finding を**1画面に集約**し、標準（CIS/PCI DSS 等）への**準拠を測りたい** | **Security Hub CSPM**（＋ AWS Config） | ASFF 正規化・集約・優先順位づけ＋標準チェック |
| 検知された脅威の**根本原因・被害範囲を調査**したい | **Detective** | 行動グラフ（ML/統計/グラフ理論）で最大1年を可視化 |
| EC2/コンテナ/Lambda の**ソフトウェア脆弱性（CVE）・露出を発見**したい | **Inspector** | ワークロードを自動発見し継続スキャン、CVSS リスクスコア |
| S3 の中に **PII などの機密データがどこにあるか**を知りたい | **Macie** | ML＋パターンマッチでオブジェクトの中身を分類 |
| リソース**構成の変更履歴・準拠状態を追跡**したい | **AWS Config**（隣接） | 構成の真実源。Security Hub 標準チェックの前提 |

迷ったときの一言判定：

- **「いま攻撃されてる？」→ GuardDuty**（検知）
- **「全部の警告、どこで見るの？」→ Security Hub**（集約）
- **「どうやって・どこまでやられた？」→ Detective**（調査）
- **「攻撃される穴はどこ？」→ Inspector**（脆弱性）
- **「危ないデータはどこ？」→ Macie**（分類）

---

## 9. 推奨スタック：スタートアップ vs エンタープライズ

「全部入れる」は正解ではありません（コストも運用も破綻する）。**資産と運用フェーズに合わせて積む**のが鉄則です。

### 9.1 スタートアップ（少人数・PMF 検証フェーズ）

**土台2つから始める：**

1. **GuardDuty**（基盤検知＋無償の Extended Threat Detection）——有効化＝即オン、追加費用なしで攻撃シーケンスまで相関。
2. **Security Hub CSPM**（＋ AWS Config）——finding の集約ハブと、FSBP 標準による「設定の取りこぼし」検出。最初の posture の地図になる。

**資産が増えたら足す：**

- 機密データ（PII・カード番号等）を **S3 に置くなら → Macie**。
- コンテナ/サーバーの **CVE 管理が必要になったら → Inspector**（ECR にイメージを置く時点でほぼ必須）。
- インシデント調査の頻度が上がったら **→ Detective**。

> 少人数こそ「検知（GuardDuty）→集約（Security Hub）」の2点を先に固め、**EventBridge で Slack 通知まで**繋ぐのが費用対効果で勝ちます。Detective や Inspector は「必要になった瞬間」に足せば十分です。

### 9.2 エンタープライズ（マルチアカウント・規制対象）

**全レイヤーを組織横断で：**

- **GuardDuty**：委任管理者＋自動有効化で**全アカウント・全リージョン**を統制（[本編ガイド](/blog/aws-guardduty-threat-detection-multi-account-terraform-eventbridge-guide)参照）。資産に応じて保護プラン（S3/EKS/RDS/Runtime/Lambda）を段階導入。
- **Security Hub CSPM**：**集約リージョン**を設定し、PCI DSS/NIST など**規制に対応する標準**を有効化。AWS Config を全社で有効化。
- **Inspector**：組織一括有効化で EC2/ECR/Lambda の CVE を継続管理。
- **Macie**：機密データを扱うアカウントで有効化し、データ所在を可視化（規制対応・データ保護要件に直結）。
- **Detective**：高重大度 finding の根本原因調査の標準ツールとして常設。

決済基盤のように**本番/ステージング/監査でアカウントを分離**している環境では、**5つすべてを「組織の委任管理者から一括統制」**するのが運用負荷を最小化する設計です。「アカウント追加のたびに入れ忘れる」余地を構造的に消せます。

---

## 10. GuardDuty だけでは足りない——多層防御の再確認

最後に、最初のメンタルモデルへ戻ります。本記事の主役5つは**すべて「検知・集約・調査・評価・分類」**であって、**どれも「攻撃を止める（prevention）」ことはしません**。GuardDuty を入れても、Security Hub で集約しても、**それだけでは攻撃を防げません**。検知・評価・分類のレイヤーは、**予防のレイヤーと組み合わせて初めて多層防御になります**。

GuardDuty（と仲間4つ）に加えて、必ず必要なもの：

- **入口の防御** → **[WAF](/blog/waf-defense-in-depth-aws-waf-cloud-armor-owasp-guide)**（L7 のフィルタ・OWASP 対策）。検知ではなくブロック。
- **最小権限の IAM** → 漏洩した認証情報の**悪用可能範囲を最初から狭める**。[きめ細かいアクセス制御](/blog/dynamodb-security-iam-fine-grained-access-control-encryption-vpc-endpoint-guide)。
- **脆弱性を塞ぐ運用** → Inspector が見つけた **CVE を実際にパッチする**プロセス（発見と修正は別物）。
- **データ層の保護** → [暗号化・VPC エンドポイント・きめ細かいアクセス制御](/blog/dynamodb-security-iam-fine-grained-access-control-encryption-vpc-endpoint-guide)。Macie は「機密がどこにあるか」を教えるだけで、暗号化や遮断はしない。

> **役割の再確認**：5つのセキュリティサービスは、多層防御の中で **「予防層をすり抜けた／すり抜けうる問題を、早く見つけ・正しく束ね・深く調べ・先に塞ぎ・正確に分類する」** レイヤーを担います。**予防（WAF/IAM/暗号化）と検知系（この5つ）は、どちらかではなく両方**です。

---

## まとめ：AWS セキュリティサービス役割分担チートシート

迷ったときの早見表です。

- **5つは競合しない、動詞が違う**：GuardDuty=**検知** / Security Hub=**集約・標準チェック** / Detective=**調査** / Inspector=**脆弱性評価** / Macie=**データ分類**。＋ AWS Config=**構成追跡**（隣接）。
- **GuardDuty**：ログ（CloudTrail/VPC Flow/DNS）の**振る舞い**を ML＋脅威インテルで**検知**。予防ではない。Extended Threat Detection は無償で攻撃シーケンスを相関。
- **Security Hub CSPM**：**検知エンジンではない**。GuardDuty/Inspector/Macie/パートナーの finding を **ASFF に正規化して集約・優先順位づけ**＋ **CIS/PCI DSS/NIST/FSBP 標準チェック**。標準チェックは **AWS Config が前提**。
- **Detective**：検知の**後**。ML/統計/**グラフ理論**で**根本原因と被害範囲**を調査（最大1年）。GuardDuty finding からピボット。
- **Inspector**：侵害の**前**。EC2/ECR/Lambda の**ソフトウェア脆弱性（CVE）と露出**を継続スキャン。GuardDuty ≠ Inspector（**行動** vs **弱点**）。
- **Macie**：**データ層**。S3 **オブジェクトの中身**から PII 等を**分類**。GuardDuty ≠ Macie（**振る舞い** vs **中身**）。
- **つなぎ方**：各 finding → **Security Hub に集約 ＋ EventBridge で自動対応**、GuardDuty finding は **Detective で深掘り**。`source` ＋重大度でルーティング。
- **スタックの積み方**：スタートアップは **GuardDuty + Security Hub** から。S3 機密データ→Macie、CVE 管理→Inspector、調査増→Detective を**資産に合わせて**足す。
- **過信しない**：5つは全部**検知系**。**予防は別**——WAF・最小権限 IAM・暗号化・実際のパッチ運用と**組み合わせて**初めて多層防御。

AWS のセキュリティは「最強の1つを選ぶ」ゲームではなく、**「役割の違うレイヤーを、自社の資産とフェーズに合わせて正しく重ねる」**設計です。混同の正体は「全部 finding を出すから同じに見える」——でも**動詞（検知/集約/調査/評価/分類）で割ると、一切重なりません**。

私はマルチアカウントの[サーバーレス決済プラットフォーム](/case-studies/payment-platform-reliability)で、**実際の金銭・カーボンクレジット・地域通貨を扱う基盤の IAM・可観測性・DR を横断実装**し、「正しさ」を運用の注意深さではなく**コードの構造と仕組み**で担保してきました。セキュリティスタックの設計も同じ思想です——**①どの動詞（検知/集約/調査/評価/分類）が要るかを資産から決め、②組織一括有効化で取りこぼしを構造的に消し、③finding を Security Hub と EventBridge で1本の対応パイプラインに束ねる**。「とりあえず GuardDuty」で止めず、**役割の地図と連携の配管まで作り切ります**。

**「自社の AWS に、どのセキュリティサービスを・どの順で・どう連携させて入れるべきか」——役割分担の整理から Security Hub/EventBridge の連携設計、組織一括統制、コスト最適化まで、一人 ×生成AI（Claude Code）で速く・安全に伴走できます。** 「GuardDuty は入れたが、その先が分からない」という段階からでも、お気軽にご相談ください。

---

### 参考（公式ドキュメント）

- [What is Amazon GuardDuty?](https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html) — threat detection service の定義・基盤データソース・Extended Threat Detection・Security Hub/Detective/EventBridge 連携
- [What is AWS Security Hub CSPM?](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) — finding の集約（ASFF）・標準チェック（FSBP/CIS/PCI DSS/NIST）・AWS Config 依存・GuardDuty/Inspector/Macie 統合
- [What is Amazon Detective?](https://docs.aws.amazon.com/detective/latest/userguide/what-is-detective.html) — 根本原因の調査・ML/統計/グラフ理論・行動グラフ・最大1年の履歴・GuardDuty finding 取り込み
- [What is Amazon Inspector?](https://docs.aws.amazon.com/inspector/latest/user/what-is-inspector.html) — vulnerability management service・EC2/ECR/Lambda の CVE と露出・CVSS リスクスコア・EventBridge/Security Hub 発行
- [What is Amazon Macie?](https://docs.aws.amazon.com/macie/latest/user/what-is-macie.html) — data security service・ML＋パターンマッチで S3 の機密データを分類・policy finding・EventBridge/Security Hub 発行