AWS FinOps Agent（プレビュー）を触ってみた ― 作成から、自分のアカウントの棚卸しまで

こんにちは～　浮田です。

2026年6月10日（日本時間）AWS から AWS FinOps Agent がプレビューで公開されました。

コストに関する質問への回答、最適化機会の抽出、コスト異常の自動調査、そして定期的な FinOps ワークフローの自動実行までをこなす、AWS 純正のエージェントです。

（プレビュー期間中はエージェント自体の利用料金は無料で、裏で呼ばれる AWS API の標準料金のみ発生します。）

この記事では「とりあえず動かしてみる」を目標に、エージェントの作成から実際の利用までをハンズオン形式でたどります。

後半では実際に自分のアカウントを棚卸しして、どこまで使えるかを正直にレポートします。FinOps 担当者だけでなく、コストを気にするエンジニアにも役立つ内容を目指しました。

⚠️ FinOps Agent はプレビューリリースであり、仕様は変更される可能性があります。本記事の内容は2026年6月時点のものです。

■ FinOps Agent は何をしてくれるのか

まず全体像です。FinOps Agent は Amazon Bedrock 上に構築されており、主に次のことができます。

• 自然言語でのコスト照会 ― ワークロードのコストを普通の言葉で質問し、自分のコスト・使用状況データに基づいた回答を得る
• 定期コストレポート ― 日次・週次・月次などのスケジュールで、HTML / PDF / PPT 形式のレポートを自動生成
• 最適化機会の集約 ― Cost Optimization Hub と Compute Optimizer の推奨（ライトサイジング、アイドルリソース、Savings Plans）をまとめ、Jira チケット化
• イベント起動のコスト異常調査 ― Cost Anomaly Detection のイベントを受けて根本原因を調査し、結果を Jira や Slack に通知
• コンテキストファイルとメモリ ― 組織固有のファイルを読み込ませ、回答に反映。セッションをまたいで設定を記憶

裏側では Cost Explorer、Cost Anomaly Detection、Cost Optimization Hub、Compute Optimizer、CloudTrail と連携します。

CloudTrail は、異常調査の際に「いつどんなインフラ変更があったか」を特定するために使われるのがポイントです。

■ なぜ嬉しいのか ― FinOps Agent のメリット

● 異常調査が「待ち」から「届く」に変わる

従来、コスト異常アラートは「何かが変わった」ことしか教えてくれず、原因究明は人手のトリアージでした。FinOps Agent はアラートを起点に、コストの変化を CloudTrail のイベントと突き合わせて原因となった変更を特定し、想定される根本原因と担当者まで含めた調査概要を自動で作ります。あとは Jira や Slack に流すだけ。担当エンジニアは「跳ねた→これが原因→次はこうする」を、自分で掘らずに受け取れます。

● コストの答えが全エンジニアの手に渡る（民主化）

「先月コストが上がったのはなぜ？」を、エンジニアが自然言語で聞けば、変動・影響しているサービス・根本の使用要因まで返ってきます。アカウントと所有者のマッピング、チーム定義、タグ規約などのコンテキストファイルを入れておけば、組織に合った回答になります。結果として、FinOps チームは個別の問い合わせ対応から解放され、戦略的な仕事に時間を回せます。これが地味に大きい効果です。

● レポート作成の手間が消える

日次・週次・月次のコストレポートを HTML / PDF / PPT で自動生成。報告資料づくりの定常作業がそのまま自動化されます。

● 最適化の入口を一本化

Cost Optimization Hub と Compute Optimizer の推奨を一か所に集め、Jira チケットにまとめます。エンジニアは普段使っているツールの中で、そのまま改善作業に着手できます。

■ 準備するもの

ハンズオンを始める前に、以下を確認します。

• リージョン：プレビューは US East（バージニア北部 / us-east-1） で提供されます。ただしデータ自体は GovCloud（US）と中国（北京・寧夏）を除く全リージョンのコスト・使用状況をカバーします。

• 料金：プレビュー期間中は 追加料金なし。ただしエージェントが裏で呼ぶ AWS API（Cost Explorer など）の標準リクエスト料金はかかります。

• IAM 権限：エージェント作成には、管理者用の FinOpsAgentSetupPolicy 相当の権限が必要です。ロールを自動作成する場合は、エージェント用ロールとオペレーター用ロールを作るための権限も含まれます。

ロールは後述のウィザードが自動で作ってくれるので、初回は「自動作成」に任せるのが圧倒的に楽です。自前のロールを使う場合は、エージェント用に FinOpsAgentAgentPolicy、オペレーター用に FinOpsAgentOperatorPolicy を付与し、いずれも finops-agent.amazonaws.com を信頼するよう設定します。

■ ① エージェントを作成する

 AWS マネジメントコンソールで FinOps Agent を開き、Agents ページで Create を選ぶと5ステップのウィザードが始まります。  

● Step 1：名前を付ける

エージェント名（英数字・スペース・ハイフン、最大128文字）と任意の説明を入力します。

● Step 2：AWS リソースへのアクセス権を選ぶ

エージェントがコスト・運用データを読むために引き受ける IAM ロール（エージェントロール）を指定します。初回は 「新しいロールを自動作成（推奨）」 を選べば、FinOpsAgentAgentPolicy 付きのロールが自動で用意され、手動の IAM 設定は不要です。

● Step 3：Web アプリ用のアクセス権を選ぶ

会話・タスク・自動化・ドキュメント管理といった Web アプリ操作のためのロール（オペレーターロール）を指定します。こちらも自動作成が選べ、FinOpsAgentOperatorRole-... という名前のロールが作られます。Step 2 のエージェントロールとは役割が違うので、2つのロールが必要になる、という関係です。

自動生成されるロール名が FinOpsAgentOperatorRole-xxxxxxxx。

● Step 4：サードパーティ連携（任意）

Jira と Slack を接続できます。(今回は私はスキップしました。)

ただし、いずれもアカウントレベルで事前にインテグレーションを導入済みであることが前提です（画面に「Not integrated」と出ているうちはチェックしても繋げられません）。

未導入ならここはスキップし、後からエージェント詳細ページで追加できます。

サードパーティ製ツールを連携させることで、エージェントの機能を拡張できます。

• Jira：登録済みインテグレーションと、スペースキー（ENG など2〜10文字の大文字）を指定
• Slack：登録済みインテグレーションと、チャンネル ID（C04ABCDEF12 のような形式）を指定。事前にチャンネルへ FinOps Agent の Slack アプリを追加しておく必要があります
  

● Step 5：レビューして作成

内容を確認し Create agent を選択。エージェント本体の作成、ロールのプロビジョニング、連携の紐付け、Web アプリの生成までが行われます。

 作成に成功すると Agents 一覧に並ぶ。Open（または右上の Open agent）から Web アプリを開く。 

■ ② Web アプリで質問してみる

詳細ページの Open agent から Web アプリが別タブで開きます（認証は AWS コンソールのセッションを利用）。

Web アプリは左の サイドナビ、中央の チャット、右の ワークスペースパネル の3構成です。サイドナビには4つのワークスペース（Tasks / Automations / Artifacts / Context files）が並びます。

下部に「おすすめプロンプト」が並んでいます。

1メッセージは最大1,000文字。

日本語訳するとこんな感じです。

■ ③ 定期レポートを自動化する

サイドナビの Automations から、繰り返し実行する自動化を作成できます。「何を」「いつ」やるかを指示として登録するイメージです。

たとえば「毎週月曜の朝に前週のコストサマリを PDF で生成」や「毎月初にサービス別レポートを PPT で生成」といった自動化を組めます。

生成された成果物は Artifacts ワークスペースからダウンロードでき、HTML / PDF / PPT に対応しているので、そのまま社内共有や経営報告に回せます。

■ ④ コスト異常を自動で調査させる

FinOps Agent の目玉のひとつが、イベント起動のコスト異常調査です。Cost Anomaly Detection が異常を検知すると、エージェントがそれをトリガーに根本原因を調査し、調査レポートを Jira や Slack に届けます。

ポイントは、スケジュール／イベント起動の自動化に含まれる Jira 起票や Slack 通知には、毎回の承認が不要 なこと。自動化をセットアップする時点で、エージェントにその操作を事前承認する形になります。これにより、エンジニアは手動のトリアージなしに「コストが跳ねた → 原因はこれ」という通知を Slack で受け取れます。CloudTrail と連携しているため、異常発生前後のインフラ変更を突き合わせた調査が可能です。

■ 実際にやってみた ― 自分のアカウントを棚卸する  

ここからは、実際に FinOpsAgentを作り、自分のアカウントを棚卸ししてみた記録です。

手順どおりに進むだけでなく、つまずいた点もそのまま書きます。

● Web アプリを開く（503 に当たったら少し待つ）

作成直後に Web アプリを開こうとしたら、503 ERROR（CloudFront 経由の Lambda が応答しない）が出ました。が、これは一時的なもので、1〜2分おいて開き直したらあっさり入れました。作成直後はバックエンドの準備が伝播しきっていないことがあるようです。エラー文も "Try again later" なので、まずは待って再試行が正解でした。

● 日本語は通るのか？

UI もサンプルプロンプトもすべて英語で、ドキュメントのロケールも英語のみ。

公式に日本語対応とは明記されていませんが、日本語で聞いてみました。

-------------翻訳して結果-------------

主な所見：

• 5月の総支出額は非常に低く、最も支出額の高かったサービスでも約20ドルにとどまりました。これは4月と比べて大幅な減少で、4月の上位サービスにはAmazon VPC（82.08ドル）、Claude Sonnet 4.5（42.61ドル）、SageMaker（28.22ドル）、AWS Directory Service（57.66ドル）などが含まれていました。
• クロード・ソネット4.6はほぼ倍増（+93.9%）しており、5月にBedrockの利用が増加したことを示唆している。
• S3、VPC、SageMaker、ディレクトリサービス、WAFといった、4月に多額の支出があったリソースが、5月にはほぼゼロまたは0ドルにまで減少しており、これは劇的な変化です。これは、これらのリソースが解約されたか、5月の請求データがまだ不完全または確定していないことを示している可能性があります。

比較のために4月のトップ5全体を表示しましょうか、それとも特定のサービスについて詳しく見ていきましょうか？

-------------

結果、日本語の入力は問題なく通り、思考プロセス（4ステップ）つきで前月比の表が返ってきました。 日本語の理解は十分です。

ただしエージェントの回答自体は英語で返ってきます（日本語で読みたい場合はブラウザの翻訳機能を使う形）。

プロンプトは日本語でも問題なく解釈されますが、出力は英語、というのが実態でした。

日本語で出力してと言えば日本語で返ってきましたので、プロンプトで明文化してあげると良さそうです。

■ 棚卸し①：このアカウントは何にお金を使っているのか  

返ってきた上位5サービスは以下の通りでした。

コストのほぼ全部が Amazon Bedrock 経由の Claude で、特に Sonnet が5月に前月比+93.9%（ほぼ倍増）。これがこのアカウント最大の増加要因です。

3位以下は誤差レベルの金額で、S3 が-100%なのは4月の一時利用が5月に止まった動きに見えます。つまりこのアカウントのコスト管理は、実質「Sonnet の使用量をどう見るか」にほぼ集約される、という構図がひと目で分かりました。

■ 棚卸し②：無駄を探す → Cost Optimization Hub の壁

次に「今年の無駄な出費を教えて」と聞くと、ここで制約に当たりました。

アカウントが Cost Optimization Hub に未登録のため、自動推奨は取得できないという回答です。FinOps Agent の最適化機能は Cost Optimization Hub と Compute Optimizer に依存しているので、これらの有効化が前提になります。

なお気になる料金ですが、Cost Optimization Hub の有効化は無料です。Compute Optimizer も基本無料で、唯一の有料オプションは「拡張インフラメトリクス（長期分析）」のみ（リソース1つあたり月額約$0.25、自分で有効化しなければ発生しない）。安心して有効化できます。

■ 棚卸し③：有効化しても、すぐには出ない  

そこで Cost Optimization Hub を有効化して、もう一度同じ質問をしました。

結果は——推奨ゼロ。これは「すでに最適化済み」というより、理由が2つあります。

ひとつは有効化直後で集計が間に合っていないこと（推奨が出そろうまで数時間〜1日かかります）。

もうひとつは、このアカウントが EC2/RDS をほとんど持たない Bedrock 中心構成で、そもそも Hub や Compute Optimizer が得意とするインフラ系の最適化対象が乏しいことです。

 これは大事な学びでした。FinOps Agent の最適化機能は、EC2・RDS・NAT ゲートウェイのような従量インフラを抱えたアカウントで真価を発揮する。 サーバーレス/AI 中心の構成では、最適化推奨より「使用量モニタリング＋異常検知」のほうが効く、ということです。  

■ 棚卸し④：手持ちデータで無駄を炙り出す

推奨が出ないので、エージェントの提案に乗って「年初来のコストを月別に見て、止め忘れっぽいリソースを指摘して」と頼みました。

年初来の累計と1日あたり単価まで添えて、断続的に動いているリソースを名指ししてきます。

• AWS Directory Service（累計$88.89） ― 4月に登場 → 5月に消失 → 6月に復活。マネージド AD が断続稼働するのは「忘れられたリソース」の強い兆候。1日約$3。
• Amazon VPC / NAT Gateway（累計$107） ― 同じオン/オフパターン。NAT は時間課金＋データ転送課金の二重。開発/テストなら VPC エンドポイントやスケジュール停止が打ち手。
• Amazon SageMaker（累計$36.57＋3月に$65の急騰） ― Canvas セッションやトレーニングジョブの放置の疑い。
• Amazon WorkSpaces（4月$4.34、以降$0） ― 1か月だけ動いた仮想デスクトップ。テスト用の置き忘れか。

「4月→5月でゼロ化」よりも一歩進んで、「断続パターン＝止め忘れの兆候」という、より正確な読みに進化していたのが印象的でした。

ここでも一点だけ正直な注釈を。エージェントは「EC2-Other（6月$37.30）は NAT のデータ料金に関連すると思われる」と推測していましたが、これは確証のない仮説です（EC2-Other は NAT データ処理・EBS・データ転送など雑多な内訳を含むカテゴリで、原因を断定できない）。「監視してください」と締めている姿勢は正しいので、ここはコンソールで内訳を裏取りする領域です。

■ 棚卸し④：タスクとして本格レポートを作らせる

ここまではチャットでの即答でしたが、もう一段踏み込んで タスク（Tasks） として処理を投げてみました。チャットがその場の会話なら、タスクは時間のかかる処理や成果物生成をバックグラウンドに委任する仕組みです。

Tasks ワークスペースの Create task 画面では、指示文（Instructions）に加えて 「When to run」 を選びます。ここが「タスク＝単発か定期か」の答えそのもので、3択になっています。

• Run once ― 今すぐ1回だけ（＝単発タスク）
• Run on a schedule ― 毎週月曜8時など繰り返し（＝スケジュール自動化）
• Run when an event occurs ― コスト異常検知で自動起動（＝イベント自動化）
  

ちなみに Automations 側の作成画面（Create automation）も中身はこれと同根のフォームで、違いは初期値が「Run on a schedule」になっていることと、定期/イベントを選ぶと管理用の Name・スケジュール・トリガー条件の欄が増えること。

同じフォームで When to run を変えるだけで、Run once ならタスク、schedule/event なら自動化（＝走るたびにタスクを生む）になる、という関係です。

今回は動きと成果物を見たいので Run once で、こう指示しました。

----------------------------------------------------------------------------------------

今年（2026年）に入ってからのコストを月別に分析し、止め忘れの疑いがあるリソース
（Directory Service、NAT Gateway、SageMaker、WorkSpaces）を特定して、
それぞれの推定無駄コストと推奨アクションを、経営層向けの HTML レポート形式でまとめて
----------------------------------------------------------------------------------------

投げると、Task details 画面でステータスが Pending → In progress → Completed と遷移します。今回は 21:13 開始 → 21:16 完了で、約3分で終わりました。

 面白いのは「Activities」という実行ログです。最終的に 40 ステップに展開され、エージェントが裏で何をしているかが追えます。session-sql（コストデータをSQLで取得）→ cost-anomaly（異常検知を参照）→ execute_code（分析を実行）→ Loaded skill: generate-ui → export_html_artifact（HTML成果物を書き出し）→ Agent responded、という流れです。チャットだと畳まれて見えない「思考と道具の使い方」が、タスクでは記録として残る。AI エージェントの透明性という意味で、ここは見どころです。  

 そして生成されたレポートが、これまでの棚卸しを一段昇華させた完成度でした。「経営層向けHTMLレポート」という指示に対し、返ってきたのはそのまま報告に出せるビジュアルなダッシュボードです。  

生成されたHTMLファイルの一部抜粋

上段に KPI カードが4枚、その下に要約文と「4月が3月の27倍」という警告バナー、月次トレンドの折れ線グラフ（Jan→Apr急騰→May急落→Jun再上昇が一目で分かり、ホバーで各月の値も出る）、最後に「止め忘れ疑い5件・月約$311の無駄」という赤いアラートバナー、という構成でした。

月次トレンドは1月 $9.32 → 3月 $78.46 → 4月 $276.13（ピーク） → 5月 $20.45 → 6月（10日時点）$118.64。「Q1は最小、4月に複数サービスが同時起動して急増、5月にAI利用が止まって急落、6月に再加速」と物語まで言語化しています。

単にテキストを吐くのではなく、UIとグラフをコード生成して自己完結HTMLに仕上げている——前述の Activities にあった execute_code と Loaded skill: generate-ui が、この見た目に直結しているわけです。

止め忘れ疑いも、YTD $281.56 の無駄・月次約$311と数値化したうえでリスク格付きの表に整理されました。

推奨も 優先度順（URGENT / HIGH / MEDIUM / RECOMMENDED） で、EC2-Other急増の調査、Directory ServiceがPOCなら削除、未使用NATの削除とElastic IP解放、アイドルなSageMakerの停止、と具体的。

ここで効いたのは「タスクかどうか」よりも、こちらの問いの精度でした。

漠然と「無駄を教えて」と聞いたチャットでの即答は先走り、「年初来を月別に、対象サービスを挙げて」と絞ったタスクは時間軸で正確に捉え直しました。

レポートが前提（Hub 未登録）と限界（支出パターン頼み）まで明示していたのも好印象で、要はこちらの渡し方しだいで応答の質が決まる、という当たり前を再確認した形です。

じっくり40ステップ走らせるタスクのほうが、即答チャットより精度が上がるうえ、結論の前提まで示してくれました。

生成された成果物は Artifacts ワークスペースにあります。

今回は aws-cost-analysis-waste-report-2026-06-10.html（text/html・約2.2MB）が作成されていました。

ファイル名が日付つきで自動命名されるので、定期実行すれば日付違いで積み上がっていくのが分かります。容量がそこそこあるのは、スタイルやデータを埋め込んだ自己完結型のHTML（generate-ui スキルの出力）だから。ここからダウンロードして、そのまま社内共有や経営報告に回せます。

■精度を上げる鍵 ― Context files（コンテキストファイル）

ここまでの棚卸しで推論が一部先走ったのは、実はエージェントに前提情報を一切渡していなかったからです。それを補うのが4つ目のワークスペース Context files です。

イメージとしては、エージェントは「AWS のことは何でも知っているが、あなたの会社の事情は何も知らない、優秀な新入りメンバー」です。だから「Directory Service が断続的に動いている」という事実は読めても、「それが誰の担当で、意図的なのか放置なのか」までは分かりません。Context files は、その新メンバーに渡す引き継ぎ資料にあたります。

たとえば、こんなファイルをアップしておきます。

• タグ付けルール（例：env=dev は検証用、env=prod は本番）→ 「dev のリソースは止め忘れ候補、prod は除外」と判断できる
• アカウントと所有者の対応表 → 「このコストは誰に確認すべきか」まで踏み込める
• コストポリシーや前提メモ（例：「この構成は意図的なPOC」）→ 「ゼロ化＝無駄」のような早とちりを抑えられる

つまり Context files は、エージェントの回答を汎用的な推測から、自社の文脈に沿った判断へ寄せる仕組みです（組織固有の知識を回答に効かせる、いわゆる RAG 的な仕掛け。内部の実装方式は公開されていません）。

さらにメモリ機能と組み合わさり、一度教えた前提はセッションをまたいで効き続けます。

今回はコンテキストなしで棚卸ししたので推論が先走る場面がありましたが、ここを埋めれば精度は上がるはず——という改善の方向が、Context files 画面から見えてきます。

■ 使ってみてわかったこと

一通り棚卸しして得た学びを整理します。

● エージェントは「どこを見ればいいか」を高速で当てる。最終判断は人がコンソールで裏取りする。

Directory Service や NAT ゲートウェイの断続稼働を即座に拾う嗅覚は確かに鋭い。一方で「ゼロ化＝無駄」「EC2-Other は NAT 由来」のように、推論が一歩先走る場面もあります。鵜呑みにせず、仮説出しの相棒として使うのがよさそうです。

● 「即答」と「委任」を使い分ける。

チャットの即答は手軽で、軽い確認に向きます。一方タスクは、時間をかけて分析させ、レポートなどの成果物を残せるのが強み。今回 40 ステップかけた分析の質が高かったのは事実ですが、それは「タスクだから賢い」というより、問いを絞ってデータと時間を与えた結果でした。だから使い分けの軸は精度の優劣ではなく用途です。さっと確かめたいならチャット、報告に出す・根拠を残したいならタスク。特にタスクは Activities がそのまま実行ログになるので、後から「何を根拠にこの結論か」を追えるのが実務で効きます。

● ツールには向き不向きがある。

最適化機能はインフラ型アカウント向き。今回のような Bedrock 中心の構成では、Sonnet の使用量を異常検知＋Slack 通知で監視するほうが実効性が高い、という結論になりました。

■ 筆者の所感

正直なところ、期待以上でした。プレビューという但し書きを差し引いても、そのまま実務に投入したいと思える完成度です。特に「ええやん！」と思ったのは次の4点です。

• 日本語のまま棚卸しができた ― プロンプトを英語に直す手間なく、自然な日本語で会話できた。
• タスクの40ステップが見える ― エージェントが裏で何をしているかが実行ログとして残り、ブラックボックス感がない。
• 生成HTMLの完成度 ― 「経営層向けに」と頼んだら、本当にそのまま出せるダッシュボードが返ってきた。
• 本当に無駄を炙り出した ― 止め忘れの疑いがあるリソースを、累計コストと根拠つきで具体的に名指しできた。

一方で、手放しで信頼するのは早い、とも感じています。推論が一歩先走る場面があったように、結論をそのまま採用するのではなく、人がコンソールで裏取りする前提で使うのが現実的です。

とはいえこれはエージェント全般に言える話で、FinOps Agent 固有の弱点というより「AI と人の役割分担」の問題です。実際に触っていて、残念に感じた点は特にありませんでした。

■ まとめ

AWS FinOps Agent は、「コストを聞く」「最適化を拾う」「異常を調べる」「定期業務を回す」という FinOps の主要タスクを、AWS の中で一貫して自動化できるエージェントです。

自然言語での棚卸しは想像以上に実用的で、特に「断続的に動いている止め忘れリソース」を炙り出す嗅覚は頼りになりました。推論が先走る場面はあるものの、「仮説出しはエージェント、最終判断と裏取りは人」 という役割分担を意識すれば、十分に戦力になります。

何より、プレビューの段階でもう十分実用的だというのが正直な感想です。us-east-1 で試せるので、まずは自動作成ロールでエージェントを1つ立て、チャットで自分のコストを日本語で聞いてみるところから。

ぜひ一度、自分のアカウントを棚卸ししてみてください。