Amazon Detectiveとは？behavior graphの仕組み・料金とGuardDutyとの使い分けを実装者目線で解説

Amazon Detectiveは、CloudTrailのAPI操作履歴とVPCのフローログとGuardDutyの検出結果を1つのグラフに繋ぎ、「このIAMロールがいつどこから何をしたのか」を時間軸で辿れるようにするマネージドサービスです。アラートを鳴らす側ではなく、鳴った後に原因まで降りていく側を担います。

この記事では、behavior graphというデータ構造とfinding groupsの束ね方、取り込まれるログの死角、取り込みGB単価の4階層と1日あたり15TBで取り込みが止まるクォータを実装の解像度で整理します。最後に、受託開発でDetectiveを採用すべき条件と見送ってよい場面を条件付きで示します。

まとめ：Amazon Detectiveの調査範囲と料金構造・採用判断の結論

先に結論を置きます。Detectiveは「調査時間を短縮するための専用データベース」であり、検出そのものを増やすサービスではありません。

• 役割はGuardDutyの後工程：脅威を見つけるのがGuardDuty、見つかった後に影響範囲と根本原因を辿るのがDetectiveです。両者は競合せず直列に並びます。
• ログを自分で有効化する必要はない：CloudTrailとVPCフローログは独立したストリームで取り込まれ、既存の設定にも費用にも触りません。
• 取り込みには死角がある：VPCフローログはEC2インスタンス由来のみで、NATゲートウェイ・RDS・Fargateの通信は入りません。
• 費用は取り込みGBだけで決まる：最初の1,000GBが2.00USD／GBで、階層が上がるほど単価は下がります。1日15TBを超えると取り込み自体が止まります。

Amazon Detectiveの定義｜GuardDutyの検出結果を深掘りする基盤

まず、Detectiveがどの工程を代替するサービスなのかを揃えます。ここを外すとGuardDutyやSecurity Hubとの機能比較で議論が空転します。

Amazon Detectiveの定義｜ログを繋いで根本原因まで辿る仕組み

Detectiveは、AWSリソースのログデータを自動で収集し、機械学習・統計分析・グラフ理論を組み合わせて可視化を生成します。生成されるのは事前集計されたサマリーとコンテキストで、調査担当者は「このIPアドレスからのAPI呼び出しは普段と比べて異常か」という問いに、クエリを書かずに答えられます。

参照できる履歴は最大1年分です。選択した時間窓における活動の種類と量の変化が可視化として並び、その変化がGuardDutyの検出結果と紐づきます。

GuardDutyとの役割分担｜検出は脅威検知・調査はDetectiveが担う

GuardDutyは、脅威インテリジェンスのフィードと機械学習で不審な挙動を検出し、findingを上げます。Detectiveはそのfindingを起点に、関与したエンティティの前後の行動を並べる調査サービスです。前提となる検出側の仕組みはAmazon GuardDutyとは？AWS環境の脅威検出サービスの基本的な概要と特徴を初心者向けに解説で確認できます。

実務上の接点は、GuardDutyまたはSecurity Hub CSPMのfindingから「Detectiveで調査」へピボットする経路です。管理者アカウントを3サービスで揃えておくと、この遷移が途切れません。統合先の全体像はAWS Security Hubとは？CSPMとの違い・料金と導入判断を実装者目線で解説にまとめています。

なお前提条件は変わっています。以前はGuardDutyを有効化してから48時間待たないとDetectiveを有効化できませんでしたが、2024年2月2日付の更新でこの依存は撤廃されました。現在はGuardDutyを使わなくてもDetective自体は動きますが、findingを取り込むのは登録済みアカウントのみで、単独運用では調査の起点が減ります。

Detectiveが取り込むデータソースと死角｜EC2以外のフローログは入らない

料金も調査精度も、どのログがどこまで入るかで決まります。

コアの3ソース｜CloudTrailとフローログはDetectiveが独自に取得

コアパッケージ（DETECTIVE_CORE）に含まれるのは、AWS CloudTrailログ、Amazon VPCフローログ、GuardDutyの検出結果の3つです。GuardDutyのfindingについては、GuardDutyに登録しているアカウントの分だけが取り込まれます。

実装上ありがたいのは、CloudTrailとVPCフローログを既存設定とは独立した重複ストリームで消費する点です。追跡用の証跡を新設したり、フローログをS3へ出す設定を足したりする作業は要りません。既存のCloudTrail・VPCフローログの設定にも性能にも影響せず、それらの費用も増えません。監査ログ側の仕組みはAWS CloudTrailとは？監査とセキュリティを強化する仕組みで押さえておくと切り分けが楽になります。

オプションのソースパッケージ｜EKS監査ログとSecurity Hub連携

コアの3つに加えて、2種類のオプションパッケージを任意で開始できます。EKS監査ログ（EKS_AUDIT）と、Security Hub CSPMのfindingsを取り込むAWSセキュリティ検出結果（ASFF_SECURITYHUB_FINDING）です。APIで指定する有効値は次の3つに限られます。

aws detective update-datasource-packages --graph-arn "$GRAPH_ARN" --datasource-packages DETECTIVE_CORE EKS_AUDIT ASFF_SECURITYHUB_FINDING

EKS監査ログを入れると、クラスター上のユーザー操作をCloudTrail管理イベントと、通信をVPCフローログと相関させられます。監査ログを手動で有効化する必要はありません。対象はEC2上のEKSで、FargateとEKS Anywhereは含まれません。クラスターの提供形態はAmazon EKSとは？仕組み・ノード提供形態と料金モデル・ECSとの使い分けを実装者目線で解説で整理しています。

切り替え時の落とし穴が1つあります。オプションパッケージは任意のタイミングで開始・停止できますが、停止して再開しても停止期間のデータは遡って取り込まれません。エンティティのプロファイル上に空白期間として残り続けます。

ログ取得の死角｜NATゲートウェイとFargateの通信は入らない

VPCフローログの取り込みには明確な線引きがあります。誤読すると「通信の痕跡が無いので問題なし」という逆の結論に至ります。

影響が大きいのは生成元の制約です。Fargateで動くタスクの外向き通信や、NATゲートウェイを経由した集約後のトラフィックはbehavior graphに現れません。フロー監視そのものを厚くしたい場合は、AWSでNetFlow相当のフロー監視を実現する方法｜Network Flow MonitorとVPC Flow Logsの使い分けで扱った別系統の仕組みを併走させる設計になります。

behavior graphとfinding groups｜48時間で作られる調査の単位

Detectiveの体験を決めているのは、裏側のデータ構造とグルーピングのロジックです。

behavior graphの構造｜エンティティと関係を1年分保持する

behavior graphは、管理者アカウントとメンバーアカウントのソースデータから抽出・分析された連結データの集合です。アカウントがDetectiveを有効化した時点で、そのアカウントがbehavior graphの管理者になります。メンバーアカウントを招待すると、そのアカウントのデータもグラフへ合流します。

AWS Organizations統合では、組織管理アカウントがDetective管理者アカウントを指定し、管理者が組織アカウントをメンバーとして有効化します。ここで注意すべきはリージョン単位という点。Detectiveはリージョンごとに有効化し、behavior graphもリージョンごとに別物です。管理者アカウントは全リージョンで同一にしておく運用が前提になります。

保持期間は、各データソースパッケージから受け取ったデータについて最大1年です。ノードとしてAWSアカウント・IAMロール・EC2インスタンス・IPアドレス・ユーザーエージェントなどが並び、その間の関係が辺として繋がります。AWS外のIPアドレスやユーザーエージェントもエンティティとして扱われるため、攻撃元側からの追跡もできます。権限の主体側の整理はAWS IAMとは？仕組み・ユーザー/ロール/ポリシーの違いと権限設計のベストプラクティスを実装者目線で解説を参照してください。

finding groupsの生成条件｜時間近接と共通エンティティとTTP

攻撃者は一連の行動を取るため、複数のfindingと異常挙動が時間とエンティティをまたいで散らばり、単独で見ると意味を読み違えます。finding groupsは、グラフ分析でfindingとエンティティの関係を推論して束ねる機能です。

束ねる基準は4つ。近い時間帯に発生したか（時間的近接）、同じIPアドレス・ユーザー・リソースが関与しているか（共通エンティティ）、攻撃の型や不審な挙動が似ているか（パターンと挙動）、MITRE ATT&CKのようなフレームワークで記述されるTTPを共有しているか、です。同じIAMロールセッションが取った操作や、同一IPアドレス発の操作は、同じ活動の一部である可能性が高いという前提で結び付けられます。

タイミングも押さえておきます。関連するGuardDuty findingが最初に発生してから、関連する全findingと関与エンティティを含むfinding groupが作られるまで48時間です。検知の直後にコンソールを開いてもグループが揃っていない場合があり、初動の一次切り分けはGuardDuty側のfinding単体で進めることになります。調査を運用フローへ載せる手順はインシデント管理とは？ITIL準拠のプロセスと監視・オンコールの実装を運用目線で解説【2026年版】で整理しています。

Detective Investigationの自動調査とSecurity Lake連携

可視化を人が読む使い方に加えて、機械側が先に当たりを付ける機能と、生ログまで降りる機能があります。

Detective InvestigationでIAMの侵害指標を洗い出す流れ

Detective Investigationは、IAMユーザーとIAMロールを対象に、IOC（indicator of compromise＝侵害の痕跡）を使って調査します。IOCは、悪意ある活動やインシデントを高い確度で示すアーティファクトを指します。

機械学習モデルと脅威インテリジェンスで、重大かつ疑わしい事象だけを浮かび上がらせる設計です。コンソールから実行するほか、Detective APIのStartInvestigationやAWS CLIのstart-investigationでプログラムからも起動できます。棚卸し的に主要ロールへ定期実行し、結果をチケット化する運用が組めます。

Security Lake連携で生ログを引く｜追加費用が乗る前提の設計

Detectiveは、Amazon Security Lakeが保管する生ログの照会・取得にも対応します。対象はAWS CloudTrail管理イベントのバージョン1.0以降、Amazon VPCフローログのバージョン1.0以降、Amazon EKS監査ログのバージョン2.0です。連携後、Detectiveは対象範囲の生ログをSecurity Lakeから引いてきます。

集約された可視化では判断できず、原文のイベントまで確認したい場面で効きます。ただし課金の勘定は別です。Security Lake連携とDetective Investigationは、組み合わせて使う他のAWSサービス分の追加費用が発生し得ると明記されています。Detectiveの取り込みGB単価だけで見積もりを閉じないでください。

横断的なログ相関という観点では、SIEM製品と機能が重なります。境界の引き方はSIEMとは？仕組み・機能とEDR/XDR/SOARの違い・製品選定を実装視点で解説【2026年時点】で扱った選定軸に沿って判断するのが早道です。

Amazon Detectiveの料金体系とデータ量クォータ｜15TBで取り込み停止

Detectiveの請求は単純です。跳ねる条件も、止まる条件も数値で決まっています。

取り込みGB単価の4階層｜1,000GBまでは2USDで始まる構造

課金はアカウント・リージョン・月あたりの取り込みGBに対して発生し、ソースの種類による単価差はありません。us-east-1の公開価格（2026年7月時点）は次の4階層です。

ログソースの有効化やデータ保存に追加料金はかかりません。契約や最低利用額もなく、初回有効化時はリージョンごとに30日間の無料トライアルが付きます。トライアルはコアとオプションの全パッケージが対象で、期間中はコンソールとAPIから各アカウントの推定コストと残り日数を確認できます。単価はリージョンで変わるため、東京リージョンでの実額は料金ページと料金計算ツールで確認してください。

データ量クォータ｜9TBで警告・15TBで取り込みが止まる境界

Detectiveはbehavior graphごとに1日あたりのデータ量へ厳しいクォータを課します。管理者がDetectiveを有効化する時点と、メンバーアカウントが招待を受諾する時点で判定が入ります。

• 1日9TB超：上限に近づいた旨の警告がコンソールに出ます。メンバーアカウントの削減を検討する段階です。
• 1日10TB超：管理者アカウントはDetectiveを有効化できず、既存グラフへ新しいメンバーアカウントも追加できません。
• 1日15TB超：behavior graphへの取り込みが停止します。既存データは削除されないため過去分の調査は継続できますが、再開にはSupportの対応が必要です。

メンバーアカウント数の上限は1,200です。大規模組織ではアカウント数よりログ量が先に効く構造だと理解しておくと設計を誤りません。CloudTrailのデータイベントを大量に出している環境では、有効化前に日次のログ生成量を実測してください。

受託開発でAmazon Detectiveを採用する条件と見送る場面の判断基準

論点はDetectiveを使うかどうかではなく、調査工程に誰がどれだけ時間を割ける体制なのかにあります。

Amazon Detectiveを採用する3つの条件｜調査時間とマルチアカウント

次のいずれかに当てはまるなら、導入価値があります。

• GuardDutyのfindingを人が捌いている：findingが上がるたびにCloudTrailをAthenaで掘っている運用なら、置き換え効果が最も大きく出ます。
• Organizationsで複数アカウントを運用している：アカウントを跨いだ横移動の追跡は、ログを個別に見ている限り繋がりません。behavior graphが1つのビューへ集約する構造は、この状況で効きます。
• 過去1年分を遡る調査要件がある：侵害の初期到達点まで戻る調査では、履歴の長さが結論を左右します。調査手法そのものの整理はデジタルフォレンジックとは？種類・調査の流れと企業が平時に備えること｜株式会社一創を参照してください。

採用を見送ってよい場面｜単一アカウントとGuardDuty未導入時

逆に、見送りが妥当な状況もはっきりしています。1つはGuardDutyを導入していないケース。Detective単体でも動きますが、findingという調査の起点が無く、可視化を眺めるだけの状態になります。この場合はGuardDutyの有効化を先に済ませ、findingが実際に上がる頻度を見てからDetectiveを判断する順序が正しくなります。

もう1つは、単一アカウント・小規模構成でCloudTrailのログ量が少ない場合です。Athenaのクエリを数本用意すれば足りる規模なら、取り込みGB課金を払う理由が薄くなります。Fargate中心の構成も慎重に判断すべき対象で、通信面の材料が入らない前提だと期待した調査ができません。

体制側の条件も見ておきます。Detectiveは調査担当者が使う道具であり、findingを読む人がいなければ価値が出ません。監視運用の内製とアウトソースの線引きはSOCとは？SIEM・SOARとの違いと監視運用の仕組み・内製とアウトソースの判断を実装者向けに解説【2026年時点】で整理した観点で決めてください。

セキュリティ調査基盤の構築を外部委託する際に確認する要件と成果物

Detectiveの有効化そのものは数分で終わります。工数が乗るのは、Organizations配下での委任管理者の設計、リージョンごとの有効化方針、オプションパッケージの取捨とコスト試算、GuardDutyからのピボット導線の整備、そして調査手順書の作成です。

外部へ委託するなら、対象リージョンとアカウント範囲、有効化するデータソースパッケージの一覧と月次の想定取り込み量、findingからDetectiveへ辿る運用手順、調査記録の保管先の4点を要件として明示しておくと、引き渡し後に運用が止まりません。一創ではAWS上の設計・構築を受託し、GuardDuty・Security Hub・DetectiveまでをIaCのコードとして納品しています。インフラ構築（AWS・Google Cloud・Azure）では、既存環境の棚卸しから移行まで相談いただけます。

よくある質問

導入検討でよく出る5つの質問に答えます。

Amazon DetectiveとGuardDutyはどう使い分けますか？

工程が違います。GuardDutyは脅威インテリジェンスと機械学習で不審な挙動を検出してfindingを上げる側、Detectiveはそのfindingを起点に関与エンティティの前後の行動を並べて根本原因を辿る側です。「攻撃されているか」を見るのがGuardDuty、「どこから入られてどこまで及んだか」を見るのがDetectiveだと整理してください。

DetectiveのためにCloudTrailやVPCフローログを有効化する必要はありますか？

不要です。Detectiveは既存設定とは独立した重複ストリームでCloudTrailとVPCフローログのイベントを消費します。証跡の新設やフローログの出力設定は要らず、既存のCloudTrail・VPCフローログの設定や性能に影響せず、それらの費用も増えません。ただしDetective側の取り込みGBには当然計上されます。

DetectiveはFargateやRDSの通信も追跡できますか？

できません。VPCフローログの取り込み対象は、VPC内のEC2インスタンスが生成した分だけです。NATゲートウェイ・RDSインスタンス・Fargateクラスターなど他リソースのフローログは使われません。コンテナをFargateで動かしている構成では、通信面の調査材料が薄くなる前提で設計してください。CloudTrail側のAPI操作履歴とGuardDutyのfindingは通常どおり取り込まれます。

SIEMを既に導入している場合、Detectiveは不要ですか？

用途が重なる部分と重ならない部分があります。SIEMは多様なログソースを横断して相関ルールを回す基盤で、オンプレミスや他クラウドも含められます。DetectiveはAWSの3ソースに限定される代わりに、グラフ構造とfinding groupsによる関連付けが最初から用意されており、ルールを書く作業が発生しません。AWS環境の調査時間を縮めたいならDetective、監視対象全体を1か所へ集めたいならSIEMという分担が現実的です。

無料トライアルの30日を過ぎると自動で課金されますか？

はい、トライアル終了後は取り込みGBに応じた課金へ移行します。トライアル中はコンソールとAPIから推定コストと残り日数を確認できるため、この期間に実際の取り込み量を測ってください。費用が想定を超えるなら、オプションパッケージを停止するか、Detective自体を無効化する判断ができます。

関連記事

• Amazon GuardDutyとは？AWS環境の脅威検出サービスの基本的な概要と特徴を初心者向けに解説：Detectiveの調査起点となる検出側の仕組み。
• AWS Security Hubとは？CSPMとの違い・料金と導入判断を実装者目線で解説：findingsの集約とDetectiveへのピボット導線。
• Amazon Inspectorとは？対応スキャンと料金・Classic終了後の導入判断：脆弱性側の検出を担う同クラスタのサービス。
• Amazon Macieとは？S3の機密データ検出の仕組み・料金と日本語データの限界を実装者目線で解説：保管データの所在を押さえるデータ保護の担当。
• クラウドセキュリティとは？リスクと責任共有モデルから見た企業の守り方：責任共有モデルにおける検出と調査の位置。