AWSは2026年6月9日、AWS FinOps Agentのpublic previewを発表しました。Cost Explorerのグラフを読む補助ではなく、Cost Anomaly Detectionの異常、CloudTrail Event History、Cost Optimization Hub、Compute Optimizer、Jira、Slackをつなぎ、コスト調査を運用タスクとして回すためのエージェントです。
3行まとめ
このテーマをもう少し広げて見るなら、Amazon QuickのMCP向けVPC接続とは：社内ツールをAIアシスタントにつなぐ前に確認すべきこと と 次世代AWS Resilience Hub一般提供とは：AI障害モード評価とサービス単位課金で導入前に確認すべきこと も合わせて確認してください。AIエージェントに社内ツールやプライベート接続を持たせる前の権限、ネットワーク、監査の論点が近いため。
コスト質問への回答、異常コストの原因調査、最適化推奨の整理、定期レポート、Jiraチケット作成、Slack投稿を扱うpreviewサービスです。
2026年6月11日時点では、利用開始はUS East (N. Virginia)、us-east-1が前提です。
preview中はFinOps Agent自体に追加料金なしとされていますが、monthly usage limitと関連サービスの通常料金は別に確認します。
サービス実行リージョンと分析対象のcost and usage dataは分けて判断します。
- AWS FinOps Agentは、コスト質問への回答、異常コストの原因調査、最適化推奨の整理、定期レポート、Jiraチケット作成やSlack投稿を扱うpreviewサービスです。
- 2026年6月11日時点では、利用開始はUS East (N. Virginia)、つまりus-east-1が前提です。AWS GovCloud (US) RegionsとAWS China Regionsを除くAWS Regionsのcost and usage dataを対象にできるとされていますが、日本リージョンでFinOps Agent自体を作れるとは確認していません。
- preview中はAWS FinOps Agent自体に追加料金なしとされています。ただしmonthly usage limitがあり、関連するAWSサービスやエージェントが呼び出すAWS APIの通常料金は別に確認する必要があります。
AWS FinOps Agentプレビューで何が変わったか
- 1public preview
AWS FinOps Agentは、コスト質問、最適化機会、異常コスト調査、定期的なFinOpsワークフローを扱うpreviewとして発表されています。
- 2原因調査
Cost Anomaly DetectionやCloudTrail Event Historyなどから、コスト変化のきっかけを探る流れが読みどころです。
- 3作業場所へ渡す
JiraやSlackのような既存の作業場所に、調査結果や推奨事項を届ける点が強調されています。
- 4導入判断
自社が試すべきか、どの権限で作るか、どこまで自動化するかを分けて確認します。
単なるコスト説明ではなく、担当チームへ渡す運用タスクまで含めて評価します。
AWS FinOps Agentは、FinOps担当者だけがコスト画面を読み解く状態から、エンジニアや運用チームが自分の担当範囲のコスト質問、異常調査、最適化タスクを直接受け取れる状態へ寄せるサービスです。公式製品ページでは、JiraやSlackのような既存の作業場所に合わせて、コスト異常の調査結果や推奨事項を届けることが強調されています。
発表の要点は、単に「AIがコストを説明する」ではありません。Cost Anomaly Detectionで異常を検知し、CloudTrail Event Historyなどから変化のきっかけを探り、担当チームへチケットや通知として渡すところまでが読みどころです。月次レビューの説明補助に近いCost ExplorerのAmazon Qコスト説明とは、使う場面が少し違います。
発表されたこと
根拠
AWSのWhat's Newと公式ブログはいずれも、AWS FinOps Agentをpublic previewとして扱っています。主な用途は、コスト質問への回答、最適化機会の提示、異常コスト調査、定期的なFinOpsワークフローです。
この時点で読み落としたくないのは、提供リージョンです。AWS FinOps Agentを試すにはus-east-1へ切り替えて、AWS FinOps Agent Consoleからエージェントを作成する流れになります。東京や大阪のAWS利用コストを分析したい場合でも、FinOps Agent自体の作成リージョンと、参照するcost and usage dataの対象範囲は分けて読む必要があります。
この記事で判断すること
確認項目
導入判断では、次の3点を最初に分けると迷いにくくなります。
1つ目は、自然言語でコストを聞きたいだけなのか、異常検知からチケット作成まで業務フローを変えたいのか。2つ目は、エージェントにどのアカウント、タグ、担当者情報、最適化推奨を読ませるのか。3つ目は、エージェントの出力を誰が確認し、どこまで自動でJiraやSlackへ渡すのかです。
previewサービスなので、GA後の料金、SLA、リージョン展開、上限変更は断定できません。この記事では、2026年6月11日に確認できた公式情報だけを軸に、試す前の確認表として整理します。
Cost Explorer Amazon Qとの読み分け
評価基準
Cost ExplorerのAmazon Q説明機能は、Cost Explorerで開いているレポートの傾向や変化を理解する入口です。特定の期間、サービス、アカウント、フィルターを前提に、いま見ている画面を読みやすくする役割が中心になります。
AWS FinOps Agentは、そこから一段進んで、検知済みの異常、定期レポート、最適化推奨、Jiraチケット、Slack投稿を含む運用タスクを扱います。通常の月次レビューはCost Explorer、異常対応や担当チームへの受け渡しはFinOps Agent、という分け方から始めると重複しません。
FinOps Agentでできることを業務フローで見る
- 1コスト質問
自然言語でコスト質問を受け、cost and usage dataに基づいて回答します。
- 2レポート生成
サービス、アカウント、Region、タグによる内訳やトレンドを含むレポート作成に進めます。
- 3異常コスト調査
コスト異常の初期調査を行い、増加の背景や確認すべき材料を整理します。
- 4最適化推奨
Cost Optimization HubやCompute Optimizerの推奨を、担当者が扱いやすい形に整理します。
- 5JiraとSlack
調査結果や推奨事項を、チケットや投稿として既存の運用先へ渡します。
価値の差は、中央のFinOpsチームだけで調べるか、エージェントが初期調査と受け渡し資料を作るかに出ます。
公式User Guideによると、AWS FinOps Agentの主な対話場所はWebアプリケーションのチャット領域です。そこから、コスト質問、異常調査、最適化推奨、レポート生成、JiraやSlackへの出力へ進みます。
ここで大切なのは、機能一覧を眺めることではなく、どの作業が誰から誰へ移るのかを見ることです。中央のFinOpsチームが毎回Cost Explorer、CloudTrail、タグ、オーナー表を突き合わせるのか。あるいは、エージェントが初期調査と受け渡し資料を作り、担当エンジニアが最終判断するのか。価値の差はそこに出ます。
コスト質問とレポート作成
根拠
AWS FinOps Agentは、自然言語でコスト質問を受け、cost and usage dataに基づいて回答します。たとえば、先月の上位コストドライバー、サービス別やRegion別の増減、特定タグの費用傾向の確認といった使い方が想定されます。
レポート生成では、HTML、PDF、PPTのレポートを作成できます。内容としては、サービス、アカウント、Region、タグによる内訳、トレンド、前月比、予測などが挙げられています。形式を指定しない場合はHTMLが既定です。
ただし、レポートの質はAWS側のAIだけで決まりません。タグが粗い、Cost Categoriesが古い、アカウント名と担当者の対応表が未整備、例外ルールが人の頭の中にある、という状態では、回答にも手戻りが残ります。最初に作るべきものは、エージェントそのものより、account-to-owner mappingや優先順位、既知の例外をまとめたcontext filesかもしれません。
異常コストの調査
注意点
FinOps Agentの目立つ用途は、Cost Anomaly Detectionイベントを起点にした異常コスト調査です。公式ブログでは、Cost Anomaly Detectionのアラートが「何か変わった」ことを示し、FinOps Agentがその次の調査を進める、という位置づけで紹介されています。
調査では、コスト変化とCloudTrailイベントを照合し、どの変更が増加のきっかけになった可能性があるかを探ります。これにより、単に「EC2が増えた」ではなく、誰が、いつ、どのような変更をした結果なのかを追いやすくなります。
ここで注意したいのは、異常検知そのものの設計です。Cost Anomaly Detectionのモニター、しきい値、通知先、対象アカウント、誤検知時の扱いが曖昧だと、エージェントが調査しても、業務としては受け止めにくくなります。FinOps Agentを試す前に、まず検知ルールの責任者を決めておく方が現実的です。
最適化推奨の整理
評価基準
AWS FinOps Agentは、Cost Optimization HubやCompute Optimizerの推奨事項も扱います。公式製品ページでは、推奨事項をまとめ、エンジニアリングチームが使うJiraチケットへ落とし込む流れが紹介されています。
ただし、最適化推奨はそのまま実行すればよい指示ではありません。性能要件、予約やSavings Plans、ピーク時の余力、障害時の切り戻し、担当チームの承認が絡みます。エージェントが作ったチケットは、実行命令ではなく、調査を始めるための材料として扱うのが安全です。
Cost ExplorerのAmazon Q説明機能とはどこが違うか
どちらが上位というより、画面内の説明か、運用タスク化かで使い分けます。
FinOps Agentを理解するとき、直近で追加されたCost ExplorerのAmazon Q説明機能と混同しやすくなります。どちらもAWS Cost Managementに近い領域で、自然言語や生成AIを使うからです。
違いは、起点と終点にあります。Cost Explorerは、人が画面で見ているコストレポートを説明する起点です。FinOps Agentは、異常、レポート、推奨、通知、チケット化を含むタスクの起点になり得ます。
Cost Explorerは画面内の説明に向く
条件
Cost Explorer側のAmazon Q説明は、Cost Explorerで開いているレポートを読ませるときに向きます。対象期間、グループ化、フィルター、予測か実績かを整えたうえで、なぜこのサービスが増えたのか、どのアカウントが効いているのかを確認する使い方です。
月次レビュー、請求速報の読み合わせ、予算超過の初期確認では、この画面内の説明が役立ちます。JiraやSlack、定期タスク、異常イベントの自動調査まで広げる前に、人が見ているレポートを理解したい場合はCost Explorerから始めるのが自然です。
FinOps Agentは運用タスク化に向く
確認項目
FinOps Agentは、定期実行、イベント駆動、チケット化、Slack投稿を含む運用に向きます。たとえば、一定額以上の異常を調査し、原因候補と担当者をまとめ、Jiraに起票し、Slackの所定チャンネルへ知らせる、という流れです。
このとき確認したいのは、エージェントが何を見たかだけではありません。誰がトリガーを管理するのか、誰が結果を承認するのか、どのチームに渡すのか、誤ったチケットが出たときに誰が閉じるのか。FinOps Agentは、機能検証より先に運用設計が必要なタイプのサービスです。
併用するならどの順番か
評価基準
併用するなら、月次レビューや通常のコスト説明はCost Explorer、検知済み異常や定期報告はFinOps Agentと分けるのがわかりやすいでしょう。Cost Explorerで見つけた疑問をFinOps Agentに持ち込むのではなく、異常や定期タスクをあらかじめ設計しておき、発生時にエージェントが動く状態を作る発想です。
タグやCost Categories、アカウントオーナー表が整っている組織では、エージェントの回答やチケットが実務に乗りやすくなります。反対に、その前提が弱い組織では、AIの精度よりも文脈不足が問題になります。
リージョン、対象データ、preview条件で最初に確認すること
preview中はGA後の料金、SLA、上限、リージョン展開を断定せず、確認日を添えて読む必要があります。
日本の読者にとって紛らわしいのは、FinOps Agentの提供リージョンと、分析対象のAWS利用リージョンが別の話だという点です。
2026年6月11日時点で、AWS FinOps Agentを試す入口はUS East (N. Virginia)、us-east-1です。一方で、What's Newでは、AWS GovCloud (US) RegionsとAWS China Regionsを除くAWS Regionsのcost and usage dataを含むとされています。
提供リージョンはus-east-1
根拠
Getting startedの公式ドキュメントでは、AWS Management Consoleにサインインし、us-east-1へ切り替えて、AWS FinOps Agent Consoleを開く流れが示されています。creation wizardは、エージェントに必要なIAM rolesを作成し、必要なポリシーを付与できます。
このため、東京リージョンのEC2やS3のコストを見たい場合でも、FinOps Agent自体を東京リージョンで作成できるとは読まない方が安全です。東京や大阪を含むAWS利用のcost and usage dataを扱う話と、FinOps Agentのサービス提供リージョンの話は分けて確認してください。
cost and usage dataの対象範囲
条件
What's Newの記述では、AWS GovCloud (US) RegionsとAWS China Regionsを除くAWS Regionsのcost and usage dataが対象です。Organizationsの管理アカウントで設定する場合、複数アカウントや複数Regionのコストを横断して扱える可能性があります。
ただし、見えるデータはアカウント構成、請求データ、タグ、Cost Categories、各サービス側の設定に左右されます。検証では、管理アカウント、メンバーアカウント、検証用アカウントを分け、どの粒度でコストが見えるかを記録しておくと後で判断しやすくなります。
日本語UIや日本語レポートは未確認として扱う
注意点
今回確認した一次情報では、日本語UI、日本語レポート、日本語質問への個別対応条件は確認していません。英語の公式ドキュメントを前提にすれば、まずは英語UIや英語出力で検証するつもりで設計する方が安全です。
社内で日本語レポートが必要な場合は、FinOps Agentの出力をそのまま経理報告に使うのではなく、人が確認し、日本語化し、社内の費用配賦ルールに合わせて調整するプロセスを残すべきです。
異常コスト調査をエージェント化するときの運用設計
- 1異常を検知
Cost Anomaly Detectionのイベントを調査の起点にします。
- 2優先度を分ける
金額、増加率、対象アカウント、サービス、タグ、営業時間外かどうかで扱いを分けます。
- 3自動調査を起動
EventBridge rule、Lambda function、FinOps Agent automationを組み合わせる流れが示されています。
- 4根拠を確認
CloudTrail Event History、タグ、アカウント情報、既知の例外を確認し、説明できる形にまとめます。
- 5JiraとSlackへ共有
チケット化や通知に進める前に、担当者と承認線を決めておきます。
すべての異常を同じ重さで扱うと通知疲れが起きるため、優先度と承認線を先に設計します。
FinOps Agentを入れるときに一番大きい変化は、Cost Anomaly Detectionのアラートを見てから人が調べる流れを、イベント駆動のタスクに変えられる可能性があることです。
公式ドキュメントには、Cost Anomaly Detectionイベントをトリガーにし、EventBridge rule、Lambda function、FinOps Agent automationを組み合わせる流れが示されています。ここまで来ると、単なるチャット機能ではなく、運用自動化の設計対象です。
トリガーは何にするか
確認項目
最初に決めるべきなのは、何を異常として調査するかです。すべての異常を同じ重さで扱うと、通知疲れが起きます。金額、増加率、対象アカウント、サービス、タグ、営業時間外かどうかで優先度を分ける必要があります。
検証時には、通知しきい値、対象アカウント、除外する既知イベント、対応時間、エスカレーション先を表にします。FinOps Agentの出力を読む前に、そもそもどの異常なら自動調査する価値があるのかを決めておくのです。
調査で見るべき材料
根拠
FinOps Agentが読む材料には、Cost Explorer、Cost Anomaly Detection、Cost Optimization Hub、Compute Optimizer、CloudTrail Event Historyなどがあります。Cost Inquiryの公式ドキュメントでは、これらのデータソースがどのような情報を提供するかが整理されています。
調査では、コスト増のサービス名だけでなく、関連する使用量、アカウント、タグ、予約やSavings Plansの状態、最適化推奨、直近の変更イベントを見ます。CloudTrail側の見える期間やイベント種類は別途確認が必要なので、エージェントの回答を唯一の監査証跡にしない方がよいでしょう。
JiraとSlackに渡す前の承認線
注意点
公式情報では、AWS FinOps AgentはJiraチケットの作成やSlackチャンネルへの投稿を扱えます。便利な一方で、コスト情報や担当者情報がチケットやチャンネルに流れるため、投稿先の権限設計が重要です。
最初は、直接担当チームへ自動投稿するより、FinOpsチームの確認用チャンネルや検証用Jiraプロジェクトへ出す方が安全です。自動投稿してよい内容、チケット作成だけに留める内容、人間レビューを挟む内容を分けてから、本番の通知先へ広げます。
Slackについては、公式FAQでpreview中のSlack連携はdelivery-onlyとされています。つまり、Slack内ですべての対話が完結するFinOps botのように期待するのではなく、調査結果やレポートの配信先としてまず確認するのが現実的です。
権限設計：agent role、IAM、アカウント分離で見ること
コストを読むだけに見えても、組織情報、担当者情報、外部連携まで含めた権限設計が必要です。
FinOps Agentはコストを読むだけに見えても、Organizations、Cost Management、CloudTrail、Jira、Slack、context filesをまたぎます。最初に管理アカウントで広く作るほど便利ですが、そのぶんエージェントが触れる情報も広がります。
公式のGetting startedでは、creation wizardが必要なIAM rolesを作成し、必要ポリシーを付与できるとされています。これは試しやすい一方で、導入判断では、どの権限がどのデータに届くのかを後から必ず確認する必要があります。
agentごとに分離されるもの
根拠
Creating an agentの公式ドキュメントでは、各FinOps agentが独立して動作し、それぞれ独自のIAM permissions、context files、memory、task queue、third-party integrationsを持つとされています。Data protectionページでは、context files、memory files、artifactsがAWS-managed infrastructureに保存され、AWS KMSで暗号化されることも確認できます。
この分離は、部署別、環境別、本番・検証別にエージェントを分ける判断材料になります。全社横断の1エージェントは便利ですが、context filesやmemoryに入る情報の範囲が広くなります。最初は検証対象を狭くして、どの情報が残るのかを確認する方が扱いやすいはずです。
どのアカウントで作るか
条件
複数アカウントのコストを扱うなら、Organizationsの管理アカウントで設定する選択肢があります。公式ブログでは、管理アカウントに設定するとAWS Regionsやaccountsをまたいでコストを管理できるとされています。
ただし、管理アカウントは影響範囲が大きい場所です。検証用の単一アカウントで始めるのか、管理アカウントで読み取り中心にするのか、担当部署ごとに分けるのかを決めてください。少なくとも、エージェント作成者、運用者、結果閲覧者、Jira/Slack接続管理者は同じ人にしない方がレビューしやすくなります。
IAM actionと監査ログの確認
評価基準
Service Authorization Referenceでは、AWS FinOps Agentのservice prefixはfinops-agentです。記事公開時点で、service-specific context keysはないとされています。
本文では具体的なIAMポリシー例を断定しません。実務では、公式のService Authorization Reference、IAM setup guide、CloudTrail、AWS OrganizationsのSCPを合わせて確認してください。誰がエージェントを作成、更新、削除できるのか。誰が会話やタスクを実行できるのか。誰がJiraやSlack連携を変更できるのか。この3つを分けてレビューするのが出発点です。
料金、monthly usage limit、クォータで詰まりやすい点
無料で試せるかだけでなく、どの頻度で何アカウントを対象にするかまで検証設計に反映します。
preview中に見落としやすいのが、「FinOps Agent自体は追加料金なし」と「周辺サービスやAPIの料金が発生し得る」は同時に成り立つ、という点です。
What's Newでは、AWS FinOps Agentはpreview中に追加料金なしと案内されています。公式ブログやFAQでは、monthly usage limitがあること、関連して使うAWSサービスには標準料金が適用されることも示されています。User Guideにも、エージェントがAWS APIを代理で呼び出すため、標準のper-request料金が発生する場合があるとされています。
preview中の料金の読み方
注意点
preview中の検証では、エージェント自体の料金だけで判断しないでください。どのデータソースを読ませるのか、どの頻度でレポートを作るのか、何件の異常を自動調査するのか、何アカウントを対象にするのかで、関連サービス側の確認が変わります。
特にCost Explorer系のAPIやレポート生成頻度は、検証ログとして残す価値があります。あとから「無料のはずだった」という話にならないよう、FinOps Agentの実行回数、対象アカウント数、レポート数、起票数を控えておきます。
関連サービスの費用確認
確認項目
公式User Guideでは、Cost Anomaly Detection、Cost Optimization Hub、Compute Optimizer、CloudTrail Event Historyは追加料金なしで参照できるものとして挙げられています。ただし、これはFinOps Agentの周辺全体が無制限に無料という意味ではありません。
AWS Cost Managementの料金ページ、Cost Explorer API、CloudTrail、通知先やチケット管理側のプランを、自社環境で確認してください。FinOps Agentはコストを下げるための道具ですが、検証そのものの実行回数が読めていないと、費用管理の話としては片手落ちになります。
quotaを検証設計に反映する
条件
Quotasページでは、Agents per account per Regionは既定で1、調整可能とされています。Artifact storage per agentは100 MBで調整可能、Context file size per uploadは10 MBで調整不可、Context file storage per agentは100 MBで調整可能です。
また、Jira integrations per accountとSlack integrations per accountはそれぞれ1、Jira connections per agentとSlack connections per agentはそれぞれ2とされています。複数部署で同時に検証したい場合、1つのエージェントを共有するのか、quota increaseをAWS Supportへ依頼するのか、先に決めておく必要があります。
データ保護とcontext files：何をアップロードしてよいか
アカウントと担当者の対応、組織固有の例外、優先順位、レビュー頻度などを入れることが想定されます。
context files、memory files、artifactsはAWS-managed infrastructureに保存され、AWS KMSで暗号化されるとされています。
セッション開始時にファイルがランタイム環境へ読み込まれ、その環境はセッションごとに一時的で分離されています。
未承認の個人情報、契約条件、社外秘の例外ルールなどは、社内のデータ分類に沿って扱います。
agent削除時や検証終了時に、context files、memory、artifacts、conversations、tasksの扱いを確認します。
費用データは経理情報であり組織構造の情報でもあるため、技術部門だけでアップロード可否を決めない方が安全です。
FinOps Agentは、コスト、アカウント、タグ、担当者、社内ルールを扱う可能性があります。費用の話は、経理情報であり、組織構造の情報でもあります。だから、context filesに何を入れるかは技術だけで決めない方がよい領域です。
Data protectionページでは、context files、memory files、artifactsがAWS-managed infrastructureに保存され、AWS KMSで暗号化されるとされています。セッション開始時には、これらのファイルがエージェントのランタイム環境に読み込まれ、そのランタイム環境はセッションごとに一時的で分離されています。
context filesとmemoryの扱い
根拠
context filesには、アカウントと担当者の対応、組織固有の例外、優先順位、レビュー頻度などを入れることが想定されます。これにより、エージェントは単なる費用グラフではなく、社内の担当関係に沿って回答しやすくなります。
一方で、conversation historyやtask recordsには、エージェントのreasoning traces、tool calls、resultsが含まれるとData protectionページで説明されています。コスト構造、担当者名、内部ルール、調査結果が残る前提で、誰が閲覧できるかを確認してください。
入れてよい情報、入れない情報
確認項目
入れてよい情報の候補は、コスト配賦ルール、サービスオーナー一覧、タグ命名規則、Jiraプロジェクト、Slack通知先、除外すべき既知イベントです。これらはエージェントの回答やチケット作成を現実の組織に寄せるために役立ちます。
入れる前に承認が必要な情報は、顧客名、契約条件、個人名を含む担当者表、非公開プロジェクト名、経営レベルの予算情報、障害やセキュリティに関わる内部メモです。FinOpsの文脈では便利でも、情報分類ルールでは別の扱いになることがあります。
agent削除と運用終了時の確認
注意点
preview検証が終わったら、作ったエージェント、context files、artifacts、Jira/Slack接続、タスク、会話履歴を棚卸しします。検証用に入れたオーナー表や例外ルールが残ったままになっていないか、運用終了時の手順に入れてください。
削除や保持の細かい扱いは公式Data protectionページの更新に左右されます。公開時点の説明だけで永続的な保証を読み込まず、検証前と検証後の2回、最新ドキュメントを確認する方が安全です。
導入前チェックリスト：今すぐ試せるケースと待つケース
us-east-1で検証でき、AWS Organizationsやタグ設計がある程度整っており、FinOps担当と基盤担当が一緒に確認できる組織です。
最初は1つのOU、少数のアカウント、特定サービスに絞り、根拠、チケット、通知の役立ち方を確認します。
タグ、アカウント名、サービスオーナー、Jiraプロジェクト、Slack通知先が未整理なら、context filesの元になる表を先に作ります。
日本リージョン単独提供、日本語UI、日本語レポート、GA後の料金やSLAが導入条件なら、previewの確認情報だけで本番判断しない方がよいでしょう。
previewは本番移行の約束ではなく、運用設計の不足を見つける検証材料として扱います。
AWS FinOps Agentは、すべての組織が同じ速度で入れるサービスではありません。コストデータ、タグ、アカウント設計、通知先、承認フローが整っているほど、previewでも学びを得やすくなります。
今すぐ試しやすいケース
条件
us-east-1で検証でき、AWS Organizationsやタグ設計がある程度整っており、FinOps担当と基盤担当が一緒に確認できる組織は試しやすいでしょう。Cost Anomaly DetectionやCompute Optimizerをすでに見ているが、調査とチケット化が手作業になっている場合は、今回のpreviewがちょうどよい検証材料になります。
最初の検証では、対象を1つのOU、少数のアカウント、特定サービスに絞ります。FinOps Agentが何を根拠にし、どんなチケットを作り、どの通知が役に立ったかを確認するだけでも、運用設計の不足が見えます。
先に整えるべきケース
下振れ
タグ、アカウント名、サービスオーナー、Jiraプロジェクト、Slack通知先が未整理なら、AIの回答より先に文脈不足が問題になります。FinOps Agentに期待する前に、まずcontext filesの元になる表を作る方が効果的です。
また、コスト異常の責任分界が曖昧な組織では、チケットが届いても誰も処理できません。基盤チーム、プロダクトチーム、経理、セキュリティ、SREのどこがどの判断をするかを、簡単なRACI表にしておくと検証が進みます。
まだ待った方がよいケース
注意点
日本リージョン単独提供、日本語UI、日本語レポート、GA後の料金、厳格な削除要件、SLAが導入条件になっている場合は、public previewのまま本番運用に近づけるのは早いかもしれません。
また、FinOps Agentの出力を経理報告や監査報告の唯一の根拠にするのは避けるべきです。エージェントの調査結果は、Cost Explorer、CloudTrail、請求データ、各チームの変更履歴へ戻って確認する入口として扱ってください。
次に読むなら
参照した主な情報源
- AWS What's New: AWS FinOps Agent is now available in preview
https://aws.amazon.com/about-aws/whats-new/2026/06/aws-finops-agent-preview/
- AWS Cloud Financial Management Blog: Announcing the public preview of AWS FinOps Agent
https://aws.amazon.com/blogs/aws-cloud-financial-management/aws-finops-agent-is-now-public-preview/
- AWS FinOps Agent product page
https://aws.amazon.com/finops-agent/
- AWS FinOps Agent features
https://aws.amazon.com/finops-agent/features/
- AWS FinOps Agent FAQs
https://aws.amazon.com/finops-agent/faqs/
- AWS FinOps Agent User Guide: What is AWS FinOps Agent (preview)?
https://docs.aws.amazon.com/finops-agent/latest/userguide/what-is.html
- AWS FinOps Agent User Guide: Getting started
https://docs.aws.amazon.com/finops-agent/latest/userguide/getting-started.html
- AWS FinOps Agent User Guide: AWS FinOps Agent use cases
https://docs.aws.amazon.com/finops-agent/latest/userguide/chatting-with-finops-agent.html
- AWS FinOps Agent User Guide: Quotas
https://docs.aws.amazon.com/finops-agent/latest/userguide/quotas.html
- AWS FinOps Agent User Guide: Data protection
https://docs.aws.amazon.com/finops-agent/latest/userguide/data-protection.html
- Service Authorization Reference: Actions, resources, and condition keys for AWS FinOps Agent
https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsfinopsagent.html