AWS FinOps Agentで何が自動化できるか — コスト異常の根本原因調査・最適化提案・経営レポートと、人間に残る判断
AWSがコストの質問に自然言語で答え、コスト異常をCloudTrailと相関して根本原因を調査し、最適化提案・定期レポート・Jira/Slack連携まで行うagentic AI「AWS FinOps Agent」がパブリックプレビューになりました。5つの機能、既存4ツール(Cost Explorer/Cost Anomaly Detection/Cost Optimization Hub/Compute Optimizer)を束ねる上位レイヤとしての位置づけ、us-east-1のみ・日本未提供などの制約を整理し、今使うべきかGAを待つかを判断できるようにします。料金やGA、基盤モデルは公式の最新情報もご確認ください。
- #FinOps
- #コスト最適化
- #AWS
- #生成AI
- #CloudTrail
- #Bedrock
AWSのコストについて「先月なぜ上がったのか」「どこを削れるのか」を調べ、経営や顧客向けに説明用のレポートまでまとめる——この一連の作業に手間を感じている方は多いと思います。私自身、コスト最適化の相談を受けるたびに、複数のツールを行き来しながら原因を突き止め、報告資料に落とし込む時間の長さを実感しています。
2026年6月9日、AWSはこの領域を対象にした「AWS FinOps Agent」をパブリックプレビュー(一般公開前の試用提供)で発表しました。コストの質問に自然言語で答え、コスト異常の根本原因を調査し、最適化提案や定期レポートまで行う agentic AI(自律的にタスクをこなす生成AIエージェント)です。この記事では、何が自動化できて何は人間の判断に残るのか、既存ツールとどう関係するのか、そして今プレビューで使うべきか/GAを待つべきかまでを整理してみましょう。煽らず、断定できないところは正直に「公式をご確認ください」と書きます。
背景:FinOpsとは、なぜ「コスト運用の自動化」がいま語られるか
まず FinOps を一言で。クラウドのコストを可視化し、最適化の意思決定を開発・運用・財務が横断で回していく実践のことです。「使った分だけ」のクラウドでは、誰がいつ何を立てたかでコストが動くため、技術と費用を結びつけて判断する役割が欠かせません。
これまでFinOpsの現場は、複数のツールを人が手作業でまたいできました。Cost Explorer で費用を眺め、Cost Anomaly Detection で異常を拾い、Cost Optimization Hub や Compute Optimizer で打ち手を探し、最後に人がそれを資料にまとめて経営に説明する——という流れです。それぞれは便利ですが、横断する手間と属人化が課題でした。今回の発表は、この問い合わせ対応・一次調査・経営報告を生成AIエージェントに任せる選択肢を増やすもの、と位置づけられます。
何が自動化できるか:5つの機能
FinOps Agentができることは、大きく次の5つです。比較しやすいよう表にまとめます。
| 機能 | 何を自動化するか | 主な出力先・形式 |
|---|---|---|
| 自然言語のコストクエリ | 「先月なぜ上がった?」等に自分のコスト&使用量データで回答 | チャット(対話) |
| コスト異常の根本原因調査 | コスト変動をCloudTrailと相関し、原因の変更を特定して調査サマリを生成 | 調査サマリ/Slack |
| 定期レポート | 日次・週次・月次のコストレポートを生成 | HTML / PDF / PPT |
| 最適化提案 | rightsizing・アイドルリソース・Savings Plans 推奨を集約し起票 | Jira チケット |
| 組織コンテキスト取込み | アカウントと担当者の対応、チーム定義、タグ規約、レビュー頻度を取り込む | エージェントの前提情報 |
用語を補っておきます。rightsizing はインスタンスの型を実際の使用状況に合わせて過不足なく選び直すこと、Savings Plans は一定の利用量を約束して割引を受ける購入方式です。Jira・Slack連携はいずれも任意で、利用するにはアカウント単位で事前に統合を入れておく必要があります。
ここで線を引いておきたいのは、エージェントが行うのは「回答・調査・提案・レポート・起票」までで、リソースを実際に変更する(=コストを削減する実行)のは人間だという点です。「AIが自動でコストを下げてくれる」わけではありません。最適化提案を採用するか、いつ適用するかの判断と実行は、これまで通り運用する側に残ります。
目玉:コスト異常の根本原因調査 — CloudTrail相関で「何が急増させたか」を特定
5機能のなかで実務に効きそうなのが、コスト異常の根本原因調査です。
仕組みはこうです。コストの急増や異常を起点に、同じ時期の操作ログである CloudTrail(誰がいつ何のAPIを呼んだかを記録するAWSの監査ログ)のイベントと相関させ、「急増を引き起こした変更」を絞り込んで調査サマリを自動生成します。金額のしきい値などでフィルタすることもできます。
従来、私たちは Cost Explorer で「いつ・どのサービスで上がったか」を見て、CloudTrail で「その時間に何が起きたか」を突き合わせる、という一次調査を手作業でやってきました。FinOps Agentはこの突き合わせを肩代わりしてくれる、という位置づけです。ただし、それが本当に問題のある異常なのか、対応するのか、どう是正するのかという最終判断は人間に残ります。エージェントは一次調査の相棒であって、意思決定者ではない、と捉えるのが正確です。
既存ツールとどう違うか:置き換えではなく「束ねる上位レイヤ」
「では既存のコストツールは要らなくなるのか」と気になるところですが、そうではありません。
公式は、FinOps Agentが Cost Explorer・Cost Anomaly Detection・Cost Optimization Hub・Compute Optimizer のデータを下敷きにすると説明しています。つまり既存ツールを置き換えるのではなく、それらを対話化・自動化する上位レイヤとして乗る、と整理するのが正確です。回答の根拠は中央のFinOpsチームが頼っているのと同じデータ、というわけです。
基盤となる生成AIについては、公式は「Amazon Bedrock の foundation model を使う」と述べています。ただし具体的なモデル名は公表されていません。本メディアで以前取り上げた Amazon Bedrock AgentCore は、Bedrockベースのエージェントを本番運用するための基盤で、FinOps Agentも「Bedrockベースの実務エージェントの一例」として地続きに読めます。ただし、FinOps Agentが AgentCore 上で動くと公式が明言しているわけではないため、両者の直接的な技術的結合は断定しません。なお、他社のFinOps SaaSとの優劣も公式には比較がないため、本記事では触れません。
使うための前提:プレビュー制約・リージョン・IAM・Jira/Slack連携
実際に試すうえで押さえておきたい前提を、チェックリスト的にまとめます。いずれも2026年6月17日時点の情報で、プレビュー仕様は変更されることが前提です。
- 提供形態:パブリックプレビュー(2026年6月9日発表)。エージェント本体は us-east-1(バージニア北部)のみで稼働し、東京・大阪を含む日本リージョンは未提供、GA(一般提供)の時期も記載されていません。
- 料金:プレビュー中は無料で使えますが、月次の利用上限があり、その具体値は公開されていません。また、エージェントが利用する他のAWSサービスには標準料金が別途かかります。
- 作成場所:us-east-1 のコンソールから FinOps Agent を作成し、専用のWebアプリを使います。組織横断のコストを扱うには、管理(支払い)アカウントで作成します。
- IAM権限:作成ウィザード(5ステップ)で設定します。管理者用の
FinOpsAgentSetupPolicy、エージェント用のFinOpsAgentAgentPolicy、オペレーター用のFinOpsAgentOperatorPolicyなどがあり、ロールはfinops-agent.amazonaws.comを信頼します。ウィザードの自動作成(推奨)に任せることもできます。 - Jira / Slack 連携:Jira は Space key(プロジェクトを識別する2〜10文字の大文字キー)、Slack は Channel ID(
Cで始まる9〜12文字程度のID)を指定します。いずれもアカウント単位で統合を事前に入れておく必要があります。 - データ源の前提:Cost Explorer・Cost Anomaly Detection・Cost Optimization Hub・Compute Optimizer が環境で利用可能であることが前提になります。
提供リージョン・料金・必要権限・連携仕様は変わり得ます。導入を検討する際は、必ず公式の最新情報をご確認ください。
今使うべきか、GAを待つか
最後に本題です。プレビューの今から使う価値があるか、それともGAを待つか。自動化できる範囲と、人間に残る判断を整理して考えてみましょう。
| 内容 | |
|---|---|
| 今プレビューで使う価値があるケース | us-east-1でコスト・使用量データが揃っている/問い合わせ対応や異常の一次調査、経営レポート作成の手間を減らしたい/Jira・Slack運用がある/早めに知見を貯めたい |
| GAを待つ・慎重に判断したいケース | 本番運用が日本リージョン前提/プレビュー仕様の変更を業務に組み込みづらい/基盤モデル非公表や月次上限非公開が要件に合わない/管理アカウントでの作成や必要IAMが組織方針に合わない |
そのうえで、人間に残る判断をはっきりさせておきます。異常への対応要否、最適化提案を採用するか・いつ実行するか、経営レポートをどう解釈して意思決定するか、そして組織コンテキスト(タグ規約や担当者マッピング)の整備——これらはエージェントには委ねられません。FinOps Agentは一次調査と素案づくりの相棒であって、意思決定者ではない、という距離感で付き合うのが現実的です。
まとめ
ポイントを3つに絞ります。
- AWS FinOps Agentは、コストの質問への回答・異常の根本原因調査・定期レポート・最適化提案の起票を行う agentic AI です。基盤は Amazon Bedrock の foundation model(モデル名は非公表)で、自動化されるのは調査・提案・報告まで、実行と採否は人間に残ります。
- 既存の4ツール(Cost Explorer / Cost Anomaly Detection / Cost Optimization Hub / Compute Optimizer)を置き換えるのではなく、データを下敷きに束ねる上位レイヤです。目玉は、CloudTrail相関によるコスト異常の根本原因調査です。
- 現状はプレビュー/us-east-1のみ/日本未提供/月次上限非公開/GA時期未定です。採否は自分の状況で判断し、料金・提供範囲・基盤モデルなどは公式の最新情報をご確認ください。
コスト運用は、可視化・調査・打ち手が地続きのテーマです。コストの可視化という観点では CloudWatchのOpenTelemetryメトリクス対応 が、具体的な最適化の打ち手としては EC2 Graviton4 や AWS Lambda SnapStart for Python もあわせて参考にしてみてください。コストの可視化から自動化、そして具体的な最適化までを一気通貫で語れると、FinOpsやコスト最適化に関わる実務でも評価されやすい領域だと感じています。