AWS Detective入門｜GuardDutyアラートを深掘り調査してセキュリティインシデント対応を効率化する実践ガイド

2026年6月28日2026年7月2日

GuardDutyが「不審なAPIコールがあった」と警告を出してきた。でも、それだけではどこまで調べればいいかわからない。どのユーザーが、いつ、どのリソースにアクセスしていたのか——そういった文脈を手動で掘り起こすのは想像以上に時間がかかる。

オンプレ時代のセキュリティ運用では、SIEMにログを集めてアナリストが相関分析するのが一般的だった。クラウドになってもその手法は使えるが、AWS API CallやVPC Flow Logsを適切にパースして相関付けるには設計コストがかかる。

AWS Detectiveは、こうした「GuardDutyアラートの文脈調査」を半自動化するサービスだ。この記事では、AWS Detectiveの仕組みと有効化手順、GuardDutyアラートからの調査フロー、料金の考え方について現場視点でまとめる。

なぜAWS Detectiveが必要なのか？GuardDutyとの役割分担

GuardDutyは「脅威の検出」に特化したサービスだ。VPC Flow Logs・CloudTrail・DNSクエリログを機械学習で解析し、異常なAPIコールやマルウェア感染の兆候をアラートとして上げてくれる。

ただし、GuardDutyのアラートはあくまで「起点」にすぎない。「この外部IPからGetObjectが大量に叩かれた」という検知が来ても、そのIPが過去にも出現していたのか、同じユーザーが他にどんな操作をしていたのかは、別途調べる必要がある。

AWS Detectiveはその「深掘り調査」を担う。GuardDutyが「どうやら怪しい」と判定したものを受け取り、行動グラフ（Behavior Graph）という形でアカウント・IAMユーザー・EC2インスタンス・IPアドレスの関係を可視化する。

オンプレで言えば、GuardDutyがIDSのアラートだとしたら、DetectiveはSIEMのログ相関画面に近い位置づけだ。ただしSIEMと違い、ログの取り込みやパーサー設定を自分でしなくていい。AWS内のデータソースが自動で連携される点が大きな違いだ。

・GuardDuty: 脅威を検出してアラートを発報する（IDSに相当）
・Amazon Detective: アラートの文脈を可視化して調査を支援する（SIEMの相関画面に相当）
・AWS Security Hub: 複数セキュリティサービスのアラートを一元集約する

DetectiveはGuardDutyが有効化されていることが前提条件だ。GuardDutyなしでDetectiveだけを立ち上げても、調査の起点となるFindingが存在しないため意味をなさない。

AWS Detectiveの基本的な使い方

1. AWS Detectiveを有効化する

まずマスターアカウント（または調査を主導するアカウント）でDetectiveを有効化する。マルチアカウント構成の場合は、AWS Organizations連携またはメンバー招待のどちらかで複数アカウントをまとめられる。

コンソールであれば「Amazon Detective」サービスを開いて「Detective を有効にする」ボタンを押すだけだ。AWS CLIから操作する場合は以下の通りだ。

# AWS CLI — Amazon Detective グラフを有効化する aws detective create-graph \ --tags '{"Project": "SecurityOps"}' \ --region ap-northeast-1 # 作成されたグラフ ARN を確認する aws detective list-graphs --region ap-northeast-1 # 出力例 # { # "GraphList": [ # { # "Arn": "arn:aws:detective:ap-northeast-1:123456789012:graph:XXXXXXXX", # "CreatedTime": "2026-06-01T10:00:00Z" # } # ] # }

有効化直後は過去ログが蓄積されていないため、行動グラフの精度が上がるまで数日から1週間程度かかる。GuardDutyを有効化したのと同じタイミングでDetectiveも有効化しておくのが理想だ。

2. GuardDutyアラートから調査を開始する

GuardDutyのコンソールで検出結果（Finding）を開くと、両サービスが有効な場合は「Detectiveで調査する」というボタンが表示される。このボタンを押すとDetectiveのコンソールに遷移し、そのアラートに関係するエンティティ（IPアドレス・IAMユーザー・EC2インスタンス）の関係図が表示される。

Detective単体でも調査は開始できる。コンソールの検索バーにIPアドレスやユーザーARNを入力すると、そのエンティティのサマリーページに飛ぶ。

調査時の重要な確認ポイントは次の3点だ。

・New behavior（新規の行動）: このIPやユーザーがアカウント内で初めて見られた行動かどうか
・Volume（件数）: 過去の平均と比べて突出して多い操作がないか
・Geolocated IP（地理情報）: 普段とは異なる国・地域からのアクセスか

3. 行動グラフで不審な動作を特定する

DetectiveのEntity Profile（エンティティプロファイル）を使うと、対象のIAMユーザーや外部IPが過去48時間（または選択した期間）にどのAPIコールを行ったか、どのリソースにアクセスしたかをタイムライン形式で確認できる。

たとえば「IAMユーザーAがコンソールフェデレーションでログインした後にEC2インスタンスを3台起動し、その後S3バケット内のファイルを大量ダウンロードした」という一連の流れが1画面で把握できる。

オンプレのSIEMでこれと同等のことをやろうとすると、Active Directory・EDR・NWログを横断して相関クエリを書く必要があった。Detectiveはその作業を大幅に省力化してくれる。

ただし注意点がある。DetectiveはAWSリソース上の操作ログのみを可視化する。EC2インスタンス内部のOSレベルのログやアプリケーションログは対象外だ。インスタンス内部の調査には、CloudWatch Logsや別途のEDRツールとの組み合わせが必要になる。

料金の仕組み（2026年6月時点）

AWS Detectiveの料金は「取り込んだデータ量（GB）」に対して従量課金される。データソースは主に以下の3種類だ。

データソース	用途	コスト傾向
CloudTrail 管理イベント	AWS APIコールの相関分析	APIコール数に比例して増大しやすい
VPC Flow Logs	ネットワーク通信の可視化	インスタンス数・トラフィック量に比例
GuardDuty findings	アラートの文脈補完	比較的少量

2026年6月時点での東京リージョン（ap-northeast-1）の料金は、データ種別ごとに異なる。CloudTrailデータが1GBあたり$2.00前後、VPC Flow Logsが1GBあたり$1.00前後が目安だ（執筆時点の参考値。最新料金はAWS公式料金ページで必ず確認してほしい）。

30日間の無料トライアルが用意されているため、まず試してから本格導入を判断できる。

コスト上のの落とし穴として、大量のトラフィックやAPIコールが発生しているアカウントではVPC Flow Logsのデータ量が予想以上に膨らむ。有効化後すぐにAWS Cost ExplorerでAmazon Detectiveのコストをモニタリングする設定を入れておくことを推奨する。

インシデント対応での実務Tips

マルチアカウントはOrganizations連携で一元管理する
本番・開発・ステージングとアカウントが分かれている環境では、Detectiveを個別に有効化するより、AWS Organizationsのマスターアカウントから委任管理者を設定してまとめて管理した方が効率的だ。各アカウントのログが一つの行動グラフに集約されるため、アカウント横断の侵害調査が容易になる。

GuardDuty + Security Hub + Detectiveの三段構成が現場標準
GuardDutyでアラートを検出し、Security Hubで集約・優先順位付けし、優先度が高いものをDetectiveで深掘り調査する——この流れが現場での標準的な組み合わせだ。Security HubのワークフローステータスをDetectiveのリンクから更新できる機能も整備されており、調査から対応完了まで一気通貫に管理しやすくなっている。

定期パトロールより「アラートドリブン」の使い方が実態に合っている
Detectiveは「毎朝見るダッシュボード」よりも、「疑わしいGuardDutyアラートが来たときに開くツール」として使うのが実態に合っている。常時モニタリング用途にはCloudWatchダッシュボードやSecurity Hubが向いている。

Linuxインスタンス内部のログはCloudWatch Logsと組み合わせる
Detectiveが可視化するのはAWSコントロールプレーン上の操作だ。EC2内部でのファイル操作やプロセス実行は対象外になる。インスタンス上で動くサーバーの基礎知識については、姉妹サイトLinuxMaster.JPで詳しく解説している。

よくあるトラブルと対処法

Q. Detectiveを有効化したが行動グラフにデータが表示されない
有効化直後は過去データの蓄積がないためグラフが空白になる。通常24時間～72時間でデータが流入してくる。合わせてGuardDutyが同一リージョンで有効になっているかも確認したい。

Q. GuardDutyコンソールに「Detectiveで調査する」ボタンが表示されない
同一リージョンでDetectiveが有効化されていない場合、ボタンが表示されない。DetectiveはGuardDutyと同じリージョンで有効化する必要がある。マルチリージョン運用の場合は各リージョンで個別に有効化する。

Q. コストが予想より高くなった
VPC Flow Logsの取り込みデータ量が多い場合に起きやすい。対処策として、VPC Flow Logsのサンプリングレートを下げるか、Detectiveに取り込むデータソースを絞る設定を検討する。ただしサンプリングを下げると調査精度も落ちるため、本番環境では慎重に判断したい。

Q. 東京リージョンでDetectiveは使えるか
東京リージョン（ap-northeast-1）はAmazon Detective対応済みだ。すべてのリージョンでサポートされているわけではないため、他のリージョンで使う場合はAWS公式ドキュメントのサポートリージョン一覧を確認してほしい。

本記事のまとめ

AWS Detectiveは「GuardDutyが検知した後、何が起きていたのか」を掘り下げるための調査ツールだ。オンプレのSIEM相関分析に相当する作業を、AWSの各種ログソースに対して自動的に実施してくれる。

・GuardDutyは検出専門——DetectiveはそのアラートのWho・What・Whenを可視化する調査担当
・行動グラフ（Behavior Graph）でIPアドレス・IAMユーザー・EC2インスタンスの関係が一目でわかる
・料金はデータ量の従量課金——30日間無料トライアルで実際のコスト感を把握してから本導入を判断
・GuardDuty + Security Hub + Detectiveの三段構成がクラウドセキュリティ運用の現場標準

セキュリティインシデントが起きた後に「あの時のログが追えない」と困るのを防ぐために、GuardDutyと同時にDetectiveも有効化しておくことを強く推奨する。