【概要のみ紹介】AWS Cost Anomaly Detection に Amazon Q による「AI コスト調査」が追加されました

はじめに
何がうれしいのか
仕組み（How it works）
前提条件（Prerequisites）
料金
使い方
クロスアカウント調査について
制限事項（Limitations）
まとめ
- 参考リンク
余談

アプリケーションサービス部エデュケーショナルサービス課の山本です。
中途社員のトレーナー業務をしています。

はじめに

2026 年 6 月 8 日、AWS Cost Anomaly Detection（コスト異常検出）に 「AI-powered cost investigation（AI コスト調査）」 が追加されました。Amazon Q を使って、コスト異常の根本原因を分析する機能です。

これまで、急にコストが上がった原因を突き止めるのは大変でした。Cost Explorer のコストデータ、CloudTrail のイベント、実際のリソースの稼働状況を一つずつ突き合わせる必要があったためです。数時間がかりになることも珍しくありません。今回の機能は、この調査を Amazon Q が肩代わりします。わかりやすい言葉での説明を、数分で返してくれます。アラートを受け取ってから対処に動くまでの時間を短くする、というのが狙いです。

出典: AWS now provides AI-powered cost investigations for cost anomalies（What's New / 2026-06-08）

この記事では、まず機能の概要を整理します。そのうえで、AWS マネジメントコンソールからの使い方を紹介します。

📝 本記事では、実際の検証（実環境での実行結果やスクリーンショット）は行っていません。手元に都合よく調査できるコスト異常がなかったためです。良いことではありますが。公式情報をもとにした 概要と使い方の紹介 が中心の内容です。実際に異常が発生したら、検証結果を別途追記する予定です。

何がうれしいのか

ざっくり言うと、コスト異常が出たときに 「何が・いつ・どこで・誰によって・なぜ起きたのか」を Amazon Q が代わりに調査してくれる 機能です。公式アナウンスでも、その価値はこう説明されています。

（前略）わかりやすい言葉による説明を数分で得られる（後略）

— 出典: AWS で、コスト異常を調査する AI を活用したコスト調査機能が提供されるようになりました（What's New / 2026-06-08）

従来の手作業と比べたときのポイントは、以下のとおりです。

数時間かかっていた原因調査が数分で終わる
コスト変動が 使用量起因（usage-driven）か、単価起因（rate-driven）か を自動で判定してくれる
使用量起因の場合は、CloudTrail と突き合わせて、特定の API コールや IAM プリンシパルまで 特定してくれる
組織（Organizations）の CloudTrail トレイルがあれば、メンバーアカウントをまたいだ調査 も自動で実施される
結果に対して フォローアップの質問 を続け、深掘りできる
コスト異常検出（Cost Anomaly Detection）のコンソール / AWS FinOps Agent / Amazon Q の会話 という 3 つの入口から、同じ調査機能を呼び出せる（FinOps Agent は、異常検出時に自動で調査をトリガーし、結果を投稿する自動ワークフローにも対応）
追加料金なし（ただし後述の注意あり）

仕組み（How it works）

調査をリクエストすると、Amazon Q は次のような分析を行います。

何が変わったかを特定 — コスト異常を、最も寄与している次元（サービス / アカウント / リージョン / 使用タイプ）に分解する
使用量起因か単価起因かを判定 — コスト変動の原因が「量」なのか「単価」なのかを見分ける
使用量起因の場合は CloudTrail と相関 — コスト変動を、特定の API コールと、それを実行した IAM プリンシパルにひもづける
単価起因の場合はコスト構成を説明 — 料金や適用された割引で何が変わったかを特定する

なかでも「使用量起因か単価起因か」の判定が、調査の肝になります。両者は原因も対処法もまったく異なるからです。具体的には、次のような違いです。

使用量起因（usage-driven） は、単価は変わらず、使った量が増えたケースです。ひとことで言うと「たくさん使ったから高くなった」状態です。たとえば、オートスケールで EC2 の台数が増えた、Lambda の呼び出し回数が急増した、S3 へのデータ転送量が跳ね上がった、といったケースです。この場合は「誰が・何を増やしたのか」を CloudTrail で追えます。

単価起因（rate-driven） は、使った量はほぼ同じで、1 単位あたりの料金が変わったケースです。ひとことで言うと「使用量は同じなのに単価が上がったから高くなった」状態です。たとえば、Savings Plans やリザーブドインスタンスの割引が切れた（または別のリソースに再配分された）、月初にボリューム割引の段階（ティア）がリセットされた、といったケースです。この場合は、使った量ではなく、割引や料金プランの設定を見直すことになります。

つまり、同じ「コストが上がった」でも、使用量起因なら「使い方・操作」を、単価起因なら「割引・料金プラン」を見にいく、という具合に調べる先が変わります。Amazon Q がここを自動で切り分けてくれるので、最初の当たりをつけやすくなります。

出力は、異常の内容に応じて変わります。原因が 1 つの単純な異常なら、簡潔なサマリが返ります。複数の独立した原因が絡む複雑な異常なら、原因ごとの内訳と総括が返ります。

根本原因が一つに特定できない場合もあります。料金だけの変動や、需要によるスケールなど、対応する CloudTrail イベントが存在しないケースです。このようなときは、わかった範囲の情報だけを示し、推測で原因をでっち上げることはしません。ドキュメントにもそう明記されています。安心して使えるポイントです。

It does not fabricate an explanation.（根拠が揃わないときに、もっともらしい原因をでっち上げることはしない）

— 出典: Investigating anomaly root causes with Amazon Q Developer（ユーザーガイド）

前提条件（Prerequisites）

使い始める前にそろえておくものは、以下のとおりです。

Amazon Q Developer へのアクセス権限
- q:StartConversation、q:SendMessage、q:PassRequest が必要
- 手早く付与するなら AmazonQFullAccess マネージドポリシー
（推奨）組織全体の CloudTrail トレイル
- 管理イベントのロギングが有効で、CloudWatch Logs への配信が設定されていること
- クロスアカウント調査では、この組織トレイルを自動的に検出し、CloudWatch Logs Insights をクエリする
- 組織トレイルがない場合でも、調査自体は実行される。ただし、アカウントをまたいだ追跡はできない。この場合は、使えるデータの範囲で結果を返したうえで、クロスアカウントでの原因特定に何が必要か（組織トレイルと CloudWatch Logs への配信）を案内してくれる

料金

AI コスト調査そのものは、全商用 AWS リージョンで追加料金なし で利用できる
ただし、クロスアカウント調査 では料金が発生する場合がある。組織全体の CloudTrail トレイルを CloudWatch Logs に配信して調べるケースで、スキャンしたデータ量に応じた 標準の CloudWatch Logs Insights 料金 がかかる

補足: 単一アカウントでの調査なら、基本的に無料です。組織をまたいで CloudTrail を掘りにいくときだけ、Logs Insights の料金がかかり得る、という整理になります。

使い方

AWS マネジメントコンソールからの操作手順は、次のとおりです。

手順 1: コスト管理コンソールを開く

AWS Billing and Cost Management コンソールを開きます。

手順 2: Cost Anomaly Detection を開く

ナビゲーションペインから Cost Anomaly Detection を選択します。

手順 3: 検出された異常を選ぶ

Detected anomalies（検出された異常） タブを開き、調査したい異常を 1 つ選択して詳細を表示します。

💡 リソースレベルのコストデータは直近 14 日まで、異常データは 90 日でアーカイブされる、という制限があります。そのため、できるだけ新しい異常を選んだほうが、得られる情報が多くなります（制限の詳細は後述）。

手順 4: Investigate with Amazon Q を実行する

異常の詳細画面で Investigate with Amazon Q ボタンを選択します。Amazon Q が開き、自動的に調査を開始します。結果は、通常数分で表示されます。

📝 ユーザーガイドでは、この機能を「Investigate with Amazon Q Developer」と表記しています。コンソールのボタン表記とドキュメントの表記が異なる点に注意してください。

なお、調査は以下の 3 つの入口から呼び出せます。どの経路でも同じ調査機能が動くため、結果は一貫します。

コスト異常検出（Cost Anomaly Detection）コンソールの「Investigate with Amazon Q」ボタン（本手順）
AWS FinOps Agent への自然言語の質問（異常検出時に自動でトリガーし、結果を投稿する自動ワークフローにも対応）
Amazon Q の会話 — AWS コストについて質問したとき、調査が適していると判断されれば、会話の流れの中で自動的に呼び出される

手順 5: 調査結果を読む

調査結果には、データの揃い具合に応じて、以下のような次元が含まれます。

What changed（何が）: 寄与しているサービス / アカウント / リージョン / 使用タイプ
When（いつ）: コスト変動が始まった日と、その前のデプロイや設定変更などのタイムライン
Where（どこで）: 関係するアカウントとリージョン（複数アカウントなら発生元アカウントを特定）
Who（誰が）: API コールをトリガーした IAM プリンシパル（ユーザー / ロール / 自動プロセス）
Why（なぜ）: 上記を結びつけた平易な説明

ドキュメントには、出力例も載っています（以下は公式の例文を要約したものです）。

たとえば「アカウント 111122223333 の Lambda 関数が、5/15 に IAM ロール deploy-prod によるデプロイ後に呼び出しレートを増やし、us-east-1 でコスト増加を引き起こした」といった説明です。英語で記載されているので、日本語訳が必要です。

以下の画像は右の AWSニュース記事より引用しました。：AWS で、コスト異常を調査する AI を活用したコスト調査機能が提供されるようになりました - AWS.

手順 6: フォローアップ質問で深掘りする

初回の分析のあと、同じ会話の中で追加の質問ができます。たとえば、次のような質問です。

「コスト増加をサービスとリージョン別に分解して」
「コストは単一アカウントに集中している? それとも組織全体に分散している?」
「この異常は、このアカウントでの最近のコスト変動と比べてどう?」

Amazon Q は会話のコンテキストを保持します。そのため、フォローアップは前の分析を踏まえて積み上がっていきます。

クロスアカウント調査について

管理（支払い）アカウントで作成したモニターは、組織全体の支出から異常を検出します。一方、根本原因はメンバーアカウント側にあることが多いです。Cost Explorer の課金データは、支払いアカウント単位で集約されます。これに対して、CloudTrail のイベントは、その API コールが実際に行われたアカウントごとに記録されます。支払いアカウントには集約されません。ここにギャップが生まれます。

このギャップを埋めるため、調査機能は 組織全体の CloudTrail トレイルを自動的に検出 します。そして、そのトレイルのイベントが保存されている CloudWatch Logs に対してクエリを実行します。Cost Anomaly Detection 側でも調査機能側でも、追加の設定は要りません。トレイルが存在すれば、自動的に発見して利用します。

組織トレイル（と CloudWatch Logs への配信）がない場合は、支払いアカウントで使えるデータの範囲で調査が完了します。あわせて、クロスアカウントでの原因特定に何を有効化すればよいかを案内してくれます。

⚠️ 組織トレイルを CloudWatch Logs に配信して調査する場合、CloudWatch Logs Insights の標準料金が発生します。料金は、スキャンしたデータ量に応じて決まります。

制限事項（Limitations）

使う前に押さえておきたい制限は、以下のとおりです。

設定変更系の操作は「誰が」を特定できるが、データ操作系は特定できない
- 特定できる例: EC2 インスタンス起動、Lambda デプロイ、S3 バケット作成などの設定変更
- 特定できない例: S3 の GetObject、DynamoDB の GetItem などのデータ操作（CloudTrail がデフォルトでは記録しないため）
CloudTrail イベントの可用性は、トレイルの保持設定に依存する — 古い異常は、イベントが期限切れだと帰属情報が限定的、またはゼロになる
Cost Explorer のリソースレベルのコストデータは直近 14 日まで — それより古い異常は、サービスレベル / アカウントレベルのデータで分析される
異常データは 90 日でアーカイブされる — アーカイブ済み異常の調査は、使えるデータが限られる