「引き継いだ前のベンダーが残したAWSの請求書を見ても、毎月この金額が出ていく理由が誰にも説明できない」——受託で保守を引き受けたクライアントから、最近いちばん多く聞く相談です。月の請求はそれなりに大きい。けれど、どのサービスの、どの使い方が効いているのか。先月より上がった原因は何か。これに即答できる人が社内にいない。Cost Explorerを開いても、サービス別の棒グラフが並ぶだけで「で、何をどうすれば下がるのか」までは教えてくれません。
結局、コスト分析は「AWSの料金体系に詳しい一部の人」に属人化します。その人が時間を取れないと月次のコストレビューは飛び、請求は高止まりしたまま放置される。引き継ぎ案件ほど、設計の意図が分からないリソースが残っていて、これが効いてきます。
こうした「コストの原因を説明できない」問題に正面から効きそうな道具が出てきました。AWSが2026年6月18日にパブリックプレビューを開始した AWS FinOps Agent です。本記事では、このエージェントが受託保守のコスト管理をどう変えうるか、そして実際に受託の現場へ組み込むときの設計と落とし穴を、システム運用の実務目線で整理します。
「なぜ先月上がったのか」に自然言語で答えるエージェント
FinOps Agent は Amazon Bedrock 上に構築された、コスト管理に特化したAIエージェントです。いちばんの特徴は、エンジニアが自然言語でコストを質問でき、実際のコスト・使用状況データに基づいて回答が返ってくる点にあります。
たとえば「なぜ先月AWSコストが上がったのか？」と尋ねると、コストの変化を検出し、要因となったサービスを特定し、さらにその背後にある使用量の要因まで掘り下げて答える、という流れです。従来であれば、料金に詳しい担当者がCost Explorerでサービスを切り替え、期間を比較し、使用量メトリクスと突き合わせて……と手作業で追っていた調査を、質問一つで代替しにいく設計になっています。
機能はコスト質問への回答だけではありません。AWSの発表によると、主に次のことができます。
| 機能 | 内容 |
|---|---|
| コスト質問への回答 | 自然言語の問いに、コスト変化・要因サービス・使用量要因を特定して回答 |
| 最適化機会の提示 | Cost Optimization Hub と Compute Optimizer から推奨を取得して提示 |
| コスト異常の自動調査 | 想定外のコスト増を検知し、原因を自動で調査 |
| 定期FinOpsワークフロー | 日次／週次／月次のコストレポートをスケジュール実行 |
レポートは HTML / PDF / PPT 形式で生成・ダウンロードでき、最適化の推奨は Jira チケットにまとめて、エンジニアリングチームが普段のツールのまま対応できるようにする、とされています。料金はプレビュー期間中、エージェント自体の利用料は無料で、裏側で呼ばれるAWS APIの標準料金だけが発生します。
ただし現時点では限界もはっきりしています。提供リージョンはプレビューでは米国東部（バージニア北部）のみ。あくまでパブリックプレビューであり、対象範囲や回答精度は本番品質として保証されたものではありません。受託で使うなら、ここは正直にクライアントへ伝える前提のものです。
本当の価値は「コスト分析の属人化を解く」こと
FinOps Agent を「AIがコストを下げてくれるツール」と捉えると、たぶん期待を外します。私が受託保守の文脈で見ている価値は別のところにあって、それはコスト分析の属人化を解くことです。
冒頭の「説明できない」問題の正体は、AWSが高いことそのものではなく、コストの原因を追える人が限られていて、その調査が手作業で重いことにあります。だから月次のコストレビューが続かない。ここで、自然言語で原因まで掘れるエージェントが入ると、「料金体系に詳しい特定の人」でなくても、保守担当のエンジニアが「先月この案件のコストが上がった理由」を質問一つで追えるようになります。
つまり、これまで属人的で重かったから飛ばされていた月次コストレビューを、受託の標準作業として回せるようになる、というのが効きどころです。レポートを定期生成してクライアントに渡すところまで仕組みにできれば、「請求が高止まりしているのに説明できない」状態そのものが構造的に解消に向かいます。コスト調査を善意と気合いに頼るのをやめ、仕組み側に持たせる——という発想は、AIのコストと人件費を突き合わせて投資判断する考え方とも地続きです。
ここで一つ整理しておきたいのが、これはAWSインフラのコストの話だということです。LLMのAPI利用料が予算を食い破るのを防ぐ「AI予算ガバナンス」とは別レイヤの問題で、両者を混同すると打ち手を間違えます。LLM側の支出に上限をかけて暴走を止める設計については Cloudflare AI GatewayでAIコストの予算ガバナンスを敷く受託（GH Media） で扱っているので、レイヤの違いを押さえるうえで併せて読んでもらえればと思います。FinOps Agent が見るのはEC2やRDS、データ転送といったインフラ側の請求であって、両方を別々に管理する前提で設計するのが安全です。
受託保守にどう組み込むか
弊社の受託保守では、新しいAWS系の道具を入れるときに「動かして終わり」にせず、権限・運用・判断の3点を必ず設計します。FinOps Agent も例外ではありません。
権限は最小権限で、読み取り中心に設計する
最初に詰めるのは、エージェントに渡す権限です。FinOps Agent はコストと使用状況のデータを読み、推奨を取得します。ここで権限を広く渡しすぎると、コスト分析のために入れた道具が、かえって環境のリスク面になります。コストデータと最適化推奨の参照に必要な範囲に絞り、構成変更や課金設定の書き込みは持たせない、という線引きを最初に引きます。
特に引き継ぎ案件では、前任ベンダー時代のIAMが整理されておらず、誰が何にアクセスできるか自体が曖昧なケースが少なくありません。エージェントへの権限付与を機に、最小権限の原則で全体を見直すくらいでちょうどいい。AIエージェントにAWSリソースへのアクセスを与えるときのIAMガバナンスの考え方は AWS MCPサーバーのIAMガバナンス付きエージェントアクセス（GH Media） で具体的に整理しているので、権限設計の実装はそちらを土台にすると早いです。
レポートを定期化し、クライアントに渡す運用に載せる
次に、日次・週次・月次のレポート生成をスケジュールに組み込み、月次レビューの素材として使えるようにします。受託の価値は単発の調査ではなく、毎月のコスト状況をクライアントに分かる形で渡し続けるところにあります。PDFやPPTで出せるので、技術に詳しくない情シスや経営側にも「今月はこのサービスがこう動いた」を説明できる。属人的な調査を、再現性のある月次の運用フローに変える——ここを設計しないと、エージェントを入れても元の「飛ばされる月次レビュー」に戻ります。
最適化提案は鵜呑みにせず、業務要件と突き合わせる
そして最も注意が要るのが、最適化提案の扱いです。FinOps Agent は Cost Optimization Hub や Compute Optimizer から「このインスタンスはダウンサイズできる」「リザーブドインスタンスを買えば下がる」といった推奨を持ってきます。ここで「AIが言うから」とそのまま適用するのは危険です。
たとえばある製造業向けの業務システムの保守案件（社名は伏せます）では、推奨どおりにあるインスタンスをダウンサイズすれば月のコストは確かに下がる、と提示されました。けれど、その環境は月初の数日だけ負荷が跳ねるバッチ処理を抱えていて、平常時の使用率だけを見たダウンサイズは、月初に処理が詰まる可能性がありました。最適化提案は平均的な使用状況をもとに出てくるため、こうした業務固有のピークやSLAは織り込まれていないことがあります。推奨は候補として受け取り、業務要件・可用性要件と突き合わせて取捨選択する。この判断は人間が持ち、なぜ採用した／しなかったかの根拠を残します。
リザーブドインスタンスやSavings Plansのような購入コミットも同様で、案件の継続期間や構成変更の予定と突き合わせないと、安くするつもりが縛りになって逆に損をします。AWS受託でのDBコストと性能のトレードオフを具体的に検討した事例は Aurora Serverless v4で受託DBをモダナイズする（GH Media） でも扱っていて、コストと可用性のバランスを取る感覚の参考になります。
ハマりやすい落とし穴
第一に、最適化提案をそのまま適用して可用性を落とすこと。前述のとおり、コスト削減の推奨は使用状況の統計から出てくるので、業務固有のピークや冗長構成の意図を見落とします。「下がる」だけを見て適用すると、障害という形でコストよりはるかに高い代償を払うことになります。
第二に、権限を広く渡しすぎること。コスト可視化のために入れた道具が、最小権限を破る穴になっては本末転倒です。読み取り中心で、必要十分に絞る。
第三に、異常検知のノイズに振り回されること。コスト異常の自動調査は便利ですが、想定内の季節変動やキャンペーン由来の増加まで「異常」として上がってくると、対応が形骸化します。最初の数か月は、何を異常と扱うかのチューニングと、無視してよい変動の切り分けに手間をかける前提でいるべきです。
そして全体として、プレビュー段階であることを忘れないこと。提供リージョンは限定的で、回答精度も発展途上です。受託で導入するなら「これで全部解決します」ではなく、「コスト分析の属人化を解く第一歩として、限界も含めて使う」という伝え方が誠実だと考えています。
まずどこから着手するか
引き継いだAWS環境のコストが説明できない、という状態は、放っておくと毎月静かにお金が漏れ続けます。FinOps Agent はその漏れの原因を、特定の人に頼らず追えるようにする道具です。ただし、効果を出すかどうかは権限設計とレポート運用、そして提案の取捨選択という、人間側の作り込みで決まります。
着手するなら、まずは現在の月次コストの中で「説明できないまま放置されている支出」がどこにあるかを一度棚卸しすることをお勧めします。そのうえで、読み取り権限の設計とレポート定期化の運用を組めば、次の月次レビューから「なぜこの金額なのか」を説明できる状態に近づきます。
引き継いだAWS環境のコストが見えない、月次のコストレビューを受託の標準運用として回せる形にしたい、というご相談は お問い合わせフォーム からどうぞ。現行のAWS構成と請求を拝見したうえで、コスト可視化と最適化の運用設計をご一緒に組み立てます。
