「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 自動対応）は別記事の本編で扱っています。本記事はその一段上——「AWS セキュリティサービスの地図」をどう描き、どこに何を置くかに集中します。題材として、私がマルチアカウント AWS 上のサーバーレス決済プラットフォームで 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つの帰結を先に置きます。
- 動詞が違うものは競合しない。 「検知（GuardDuty）」と「脆弱性評価（Inspector）」は、同じ脅威に対して別の角度から働きます。片方が片方を代替することはありません。
- Security Hub だけ毛色が違う。 Security Hub は新しい脅威を「検知」しません。他の4つ（＋パートナー）が出した finding を集める集約レイヤーであり、加えて AWS の標準に照らす posture チェッカーです。「検知エンジン」と並べて優劣を語るのが、そもそもの誤解の源です。
- 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 や IAM の仕事。
- 特筆：Extended Threat Detection が追加費用ゼロで自動オンになり、弱いシグナルを相関させて多段攻撃を1つの「攻撃シーケンス（必ず Critical）」finding に束ねる。詳細は攻撃シーケンス finding の記事へ。
GuardDuty を入口として、残り4つが「検知の前・後・横」を埋めます。GuardDuty 本体の組織一括有効化・保護プラン選定・EventBridge 自動対応の実装は、本編ガイドに 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つ：
- 集約（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（一枚のガラス窓）」を作る。
- 標準チェック（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 アーキテクチャ（テキスト図）
┌──────────────────────────────────────────────┐
[ 侵害の前 ] │ 検知 / 評価 / 分類のレイヤー │
│ │
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つ：
- Security Hub が「机」：GuardDuty・Inspector・Macie・パートナーの finding がすべてここに集まり、ASFF で正規化されて並ぶ。AWS Config が標準チェックの土台を供給する。
- EventBridge が「行動」：finding の発生を near-real-time で受け、通知・隔離・チケット化などの自動対応へ流す。GuardDuty・Inspector・Macie はいずれも EventBridge に finding を発行できる。
- 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…）と重大度で振り分けるのが定石。破壊的な封じ込めは「型の許可リスト × 高重大度」に絞り、冪等・取り消し可能な操作から始める——この自動対応の実装パターンは自動修復・インシデント対応の記事に 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つから始める：
- GuardDuty（基盤検知＋無償の Extended Threat Detection）——有効化＝即オン、追加費用なしで攻撃シーケンスまで相関。
- 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：委任管理者＋自動有効化で全アカウント・全リージョンを統制（本編ガイド参照）。資産に応じて保護プラン（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（L7 のフィルタ・OWASP 対策）。検知ではなくブロック。
- 最小権限の IAM → 漏洩した認証情報の悪用可能範囲を最初から狭める。きめ細かいアクセス制御。
- 脆弱性を塞ぐ運用 → Inspector が見つけた CVE を実際にパッチするプロセス（発見と修正は別物）。
- データ層の保護 → 暗号化・VPC エンドポイント・きめ細かいアクセス制御。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 を出すから同じに見える」——でも動詞（検知/集約/調査/評価/分類）で割ると、一切重なりません。
私はマルチアカウントのサーバーレス決済プラットフォームで、実際の金銭・カーボンクレジット・地域通貨を扱う基盤の IAM・可観測性・DR を横断実装し、「正しさ」を運用の注意深さではなくコードの構造と仕組みで担保してきました。セキュリティスタックの設計も同じ思想です——①どの動詞（検知/集約/調査/評価/分類）が要るかを資産から決め、②組織一括有効化で取りこぼしを構造的に消し、③finding を Security Hub と EventBridge で1本の対応パイプラインに束ねる。「とりあえず GuardDuty」で止めず、役割の地図と連携の配管まで作り切ります。
「自社の AWS に、どのセキュリティサービスを・どの順で・どう連携させて入れるべきか」——役割分担の整理から Security Hub/EventBridge の連携設計、組織一括統制、コスト最適化まで、一人 ×生成AI（Claude Code）で速く・安全に伴走できます。 「GuardDuty は入れたが、その先が分からない」という段階からでも、お気軽にご相談ください。
参考（公式ドキュメント）
- What is Amazon GuardDuty? — threat detection service の定義・基盤データソース・Extended Threat Detection・Security Hub/Detective/EventBridge 連携
- What is AWS Security Hub CSPM? — finding の集約（ASFF）・標準チェック（FSBP/CIS/PCI DSS/NIST）・AWS Config 依存・GuardDuty/Inspector/Macie 統合
- What is Amazon Detective? — 根本原因の調査・ML/統計/グラフ理論・行動グラフ・最大1年の履歴・GuardDuty finding 取り込み
- What is Amazon Inspector? — vulnerability management service・EC2/ECR/Lambda の CVE と露出・CVSS リスクスコア・EventBridge/Security Hub 発行
- What is Amazon Macie? — data security service・ML＋パターンマッチで S3 の機密データを分類・policy finding・EventBridge/Security Hub 発行