FinOps × AIエージェントで実現する コストインシデントの自動調査

クラウド利用の拡大に伴い、コストの異常増加（スパイク）を検知してから原因を特定するまでのリードタイムが、FinOps運用上の大きな課題になっています。本セッションでは、コストインシデント発生時の調査プロセスをAIエージェントによって自動化する取り組みを紹介します。具体的には、コスト異常検知をトリガーに、AIエージェントが課金データ、デプロイ履歴、インフラ変更ログ、メトリクスなど複数のデータソースを横断的に調査し、原因の仮説立案から検証までを自動で行う仕組みについて、アーキテクチャと実装上の工夫を解説します。あわせて、人間のレビューをどこに組み込むか、誤検知や誤った原因特定をどう防ぐかといった、AIエージェントを実運用に乗せる上での設計上の論点にも触れます

Transcript

1. FinOps FinOps × AIエージェントで実現する コストインシデントの自動調査 AWS Cost Anomaly Detection × OSS「Kagent」によるコストアラート自動調査の仕組みと効果 2026
2. アジェンダ 2026
3. A g e n d a 目次 01 自己紹介 発表者のバックグラウンドと本日のテーマ 02 FinOpsとは クラウドコスト最適化の考え方と3つのフェーズ 03 AWS Cost Anomaly Detectionとは 機械学習ベースのコスト異常検知の仕組み 04 現状の課題 検知はできても原因特定に時間がかかる問題 05 解決アプローチとは Kagent × AIエージェントによる自動調査 06 今後の展望 自動化のさらなる拡張とFinOps成熟度向上
4. 自己紹介 2026
5. 自己紹介 2 3 • 名前：野田 悠人（T.REX） • 会社：Sky株式会社 • 部署：自社開発部署のSRE • 業務 • 自動化ツールの開発 • AIエージェントの設計・開発 • FinOpsの技術文化醸成 • X：@ukrock1996
6. FinOpsとは 2026
7. FinOpsとは クラウドの価値を最大化するための、財務・技術・ビジネスの協働文化とプラクティス Financial Operations クラウド利用費(コスト)を、エンジニアリング・財務・ビジネスの各チームが共通言語で可視化し、 「ビジネス価値に対して適切な投資をしているか」を継続的に判断・改善していく運用モデル 3つのフェーズ（FOCUS） 1 Inform（可視化） コストとリソースの利用状況を見える化し、関係者へ共有 2 Optimize（最適化） リソースの適正化・割引購入・無駄の削減を実施 3 Operate（運用・継続改善） ガバナンス・自動化・異常検知を継続的プロセスに組込み
8. なぜ今FinOpsが重要か コストインシデント対応の起点としてのFinOps クラウド利用の拡大に伴い、コストは事後的に確認するだけでは制御が難しくなっている サービス障害（性能劣化・スケール暴走・設定ミス等）が、コスト急増という形で最初に現れること が多い
9. AWS Cost Anomaly Detectionとは 2026
10. AWS Cost Anomaly Detectionとは 機械学習によりAWS利用料金の異常な増加を自動検知し、通知してくれるAWS Cost Management の機能 機械学習ベースのコスト異常検知 • 過去の利用料金パターンから、サービス・メンバーアカウント・コスト配分タグなど単位ごとに支出のベー スラインを機械学習で自動算出 • 実際の支出がベースラインから大きく外れた場合に「異常（Anomaly）」として検知し、Eメール・SNS・ Slack・EventBridge等で通知 • 検知結果には影響範囲（サービス・リージョン・使用タイプ等）が付与され、Cost Explorerで詳細を確認で きる
11. AWS Cost Anomaly Detectionの利用の流れ コストモニター作成からアラート受信、原因分析の起点までの3ステップ 1 コストモニターを作成（サービス別・アカウント別・タグ別など監視単位を選択） 2 アラートサブスクリプション（通知先・しきい値）を設定 3 異常検知時に通知を受け取り、Cost Explorer上で根本原因分析の起点とする 本資料での位置づけ： 「コストが増えた」ことの検知までは自動化されているが、「なぜ増えたか」の原因調査は依 然として人手による確認が必要
12. 現状の課題 2026
13. 現状の課題：コストアノマリー対応のフロー AWS Cost Anomaly Detection はコスト増加を検知できるが、原因特定（障害特定）は手動調査が必要で時間がかかる ①アラート発生 AWS Cost Anomaly Detection が コスト異常を検知 ②原因調査 担当者が手動で Cost Explorer・各種 ログ・メトリクスを確認 ③要因特定 リソース増減・ 設定変更・障害等の 要因を突き止める ④対応・報告 原因に応じた対応を 実施し、関係者へ 結果を共有 課題①：「②原因調査」のボトルネック 担当者ごとに調査の切り口やノウハウが異なり、原因特定までに数十分〜数時間を要し障害対応全体の初動が遅れる 課題②：検知はできても原因特定は人手に依存 Cost Anomaly Detectionで「コストが増えた」ことは検知できるが、「なぜ増えたか」の特定は依然として人手による確認が必要 。この工数削減がFinOpsの「Operate（運用）」フェーズにおける重要な課題
14. コストインシデントの多角的分析 コストの異常を「インシデント」として捉え、いつ・誰が・どのような状況で発生させたかを3つの視点から解析する コストインシデント 予期しないコスト急増を障害と同等に扱い、根本原因まで追跡する いつ？ コスト急増が始まった時刻・期間 変更やデプロイのタイミングとの相 関 誰が？ 操作を実行したIAMユーザー・ロール 意図的か・誤操作か・自動化処理か どのような状況で？ 対象リソース・サービス・リージョ ン スケール暴走・設定ミス・リソース 作成漏れ 多角的分析のアプローチ 単一のログや指標だけでは「なぜ増えたか」を特定できない。CloudWatch（何が起きたか）・CloudTrail（誰が操作したか）・CUR（ どのコストが増えたか）の3つを組み合わせて初めてインシデントの全体像が把握できる。
15. 3つのMCPによる詳細分析 CloudWatch・CloudTrail・CURの各MCPが連携し、コストインシデントの根本原因を自動的に特定する CloudWatch MCP いつ・何が起きたか メトリクス（CPU・ネットワーク・ API呼出数等）の急変を検出 コスト急増と時刻が一致するリソー スの異常を特定 アラーム履歴からインシデント発生 タイムラインを構築 → コスト急増の「発生時刻」と「影響リソー ス」を特定 CloudTrail MCP 誰が・何をしたか API操作ログからIAMユーザー・ロー ルの操作履歴を抽出 リソース作成・変更・削除のイベン トを時系列で解析 意図的な操作か自動化処理かを判別 し責任範囲を明確化 → インシデントの「操作者」と「トリガーと なった操作」を特定 Ahtena MCP どのコストがいくら増えたか Cost and Usage Report（CUR）を解析 しコスト増加の内訳を把握 サービス・リージョン・使用タイプ 別にコスト変化を分解 通常のコストベースラインとの差分 から異常値を定量化 → インシデントの「コスト規模」と「発生箇 所」を定量的に特定 3つのMCPの連携により「いつ・誰が・どのような状況でコストインシデントを発生させたか」を自動で多角的に解明し、担当者への一次報告レ ポートを生成する
16. 解決アプローチ 2026
17. 解決アプローチ：OSS「Kagent」によるAIエージェント自動調査 コストアラートをトリガーに、Kagent上のAIエージェントが調査ステップを自律的に実行し、原因の一次仮説までを自動生成 Kagent（OSS AIエージェントフレームワーク） Kubernetes/クラウド運用向けのオープンソースAIエージェント基盤。LLMとツール（CLI・API）を組み合わせ、自然言語の指示 から調査・診断タスクを自律実行できる 出典：https://jp.linkedin.com/pulse/truly-reactive-cloud-native-ai-agents-kagent-khook-anton-weiss-dt5ef?tl=ja 自動調査フロー コストアラート Cost Anomaly Detection が検知 Kagentエージェント起動 アラート内容を入力に 調査タスクを自動実行 各種API/CLIを自律操作 Cost Explorer・CloudWatch・ CloudTrail等を順に確認 調査レポート自動生成 推定原因・根拠・ 推奨対応をまとめて出力
18. Kagent アーキテクチャ Kubernetes上で動作するコンポーネント構成と通信フロー User → Kagent UI → Controller → エージェント → MCP Server群 → LiteLLM → Amazon Bedrock Kagent UI / CLI ユーザーが自然言語でエージェントへ指示を出すWeb UIとCLI。操作 の入口。 Kagent Controller Kubernetes CRDを管理するGoコントローラー。エージェントPodの作 成・ライフサイクルを制御。kmcpmanager・Tool podもここで管理。 コスト分析エージェント 会話ループを実行するコアエンジン（App/Engine）。SKILL.mdを System Promptとして読み込み、どのMCPツールをどの順序で呼ぶか 自律判断する。 MCP Server群 Model Context Protocol に基づくツール群。エージェントがCost Explorer・CloudWatch・CloudTrailなどAWS APIを呼び出すインターフ ェイス。 LiteLLM → Amazon Bedrock LiteLLMはLLMプロバイダーを統一的に扱うプロキシ。エージェント が推論リクエストを投げ、VPC Endpoint経由でAmazon Bedrockに転送 される。
19. エージェント内部の仕組み SKILL.md（System Message）→ 会話ループ → MCPツール呼出 → LiteLLM という繰り返しで自律的にコスト原因を調査する
21. 導入効果：調査工数の削減 AIエージェントによる一次調査の自動化により、初動対応の所要時間と担当者の負荷を大幅に削減 Before：手動調査 約60〜120分 / 件 • 担当者がCost Explorer・各サービスのコンソールを横断的に確認 • 原因の切り口は経験・スキルに依存し、対応にばらつき • 他業務を中断して対応するため、コンテキストスイッチのコス トも発生 After：Kagent自動調査 約5〜10分 / 件 • アラート発生と同時にエージェントが調査を自動開始 • 確認項目・調査手順が標準化され、属人性を排除 • 担当者は生成済みレポートをもとに最終判断・対応に集中でき る 約80% 一次調査の工数削減 自動調査 アラート発生時に即時着手 標準化 調査手順・観点の統一によるばらつき抑制
22. まとめ 2026
23. 今後の展望 AIエージェントによる自動調査をさらに拡張し、FinOpsの「Operate」フェーズを高度化する インシデント駆動で自動調査 インシデント駆動で自動でAIエージェン トが動く マルチクラウド対応 AWSに加え、他クラウドのコストアノマ リーにも同様のエージェント調査フロー を展開 ナレッジの蓄積・共有 エージェントの調査結果をナレッジ化し 、組織全体のFinOps成熟度向上に活用