FinOps × Kagent で踏み込む 「なぜ」に答えるコスト分析エージェント

AWSのコスト異常検知やMCPで「何が変更されたか」は分かっても「なぜ変更したか」は分からない。原因確定には結局、担当者への人的ヒアリングが必要でした。そこでBackstageの担当者情報をKagentに連携し、コスト分析エージェントが「誰に聞けばファクトチェックできるか」まで案内できるようにする改善提案です。

Transcript

1. FinOps FinOps × Kagent で踏み込む 「なぜ」に答えるコスト分析エージェント 変更履歴の“事実”から一歩踏み込む ― Backstage 連携による社内コンテキストの活用 2026
2. アジェンダ 2026
3. A G E N D A 目次 01 自己紹介 02 発表者のバックグラウンドと本日のテーマ 03 現状の課題 いま自動化している調査の仕組み 04 MCP / API が返すのは「変更の事実」だけ 05 解決アプローチ 担当者リストを社内コンテキスト化（Backstage 連携） FinOps と Kagent でのコスト分析 抜けている「なぜ」の視点 事実だけでは変更の是非を判断できない 06 あるべき姿・まとめ 「誰に聞けばよいか」まで答えるエージェントへ
4. 自己紹介 発表者のバックグラウンドと本日のテーマ T.REX 自社開発部署の SRE ／ X：@ukrock1996 主な業務 自動化ツールの開発 AI エージェントの設計・開発 FinOps の技術文化醸成
5. FinOps と Kagent でのコスト分析 2026
6. FinOps とは クラウドの価値を最大化する、財務・技術・ビジネスの協働文化とプラクティス Financial Operations クラウド利用費を各チームが共通言語で可視化し、「ビジネス価値に見合う投資か」を継続的に判断・改善する運用モデル 3 つのフェーズ（FOCUS） 1 2 3 Inform（可視化） Optimize（最適化） Operate（運用・継続改善） コストとリソースの利用状況を見える化し 、関係者へ共有する リソースの適正化・割引購入・無駄の削減 を実施する ガバナンス・自動化・異常検知を継続的プ ロセスに組み込む
7. Kagent によるコスト分析 コストアラートをトリガーに、AI エージェントが調査ステップを自律実行する Kubernetes / クラウド運用向けの OSS AI エージェント基盤。LLM と各種ツール（CLI・API）を組み合わせ、自然 言語の指示から調査・診断タスクを自律実行できる 自動調査フロー › › › コストアラート エージェント起動 MCP / API を自律操作 調査レポート生成 Cost Anomaly Detection が異常を検 知 アラート内容を入力に調査を自動 実行 Cost Explorer・CloudWatch・ CloudTrail 等を順に確認 推定原因・根拠・推奨対応をまと めて出力
8. Kagent アーキテクチャ 自然言語の指示から、エージェントが MCP と LLM を使い分けて自律的に調査する構成 Kagent ／ Kubernetes namespace SKILL.md User UI / CLI Controller コスト分析 エージェント MCP Server 群 運用担当者 自然言語で指示を入力 Pod を管理・制御 SKILL.md を基に MCP 呼び 出しを自律判断 AWS API を呼び出す 推論 LLM 推論経路 エージェントの推論リクエストを VPC 経由で Bedrock へ転送する LiteLLM プロキシ VPC Endpoint Amazon Bedrock
9. デモ：Kagent UI から自然言語で問い合わせ 分析用エージェントを選び、チャット欄に日本語で聞くだけ ― SQL の知識は不要 自然言語で聞くだけ 分析用エージェントを選択 BigQuery 分析用の google-cloud-agent（ Gemini）を選ぶ 日本語で質問を入力 チャット欄に聞きたいことを書いて送信す るだけ 利用ツールが右に表示 エージェントの役割と利用可能ツール（ BigQuery MCP）を確認できる 「thelook_ecommerce の 2024 年 月別売上を教えて」 出典：T.REX「KagentをGKE上で動かしてみた ― BigQuery MCP 連携まで」Zenn https://zenn.dev/ukrocksre/articles/kagent-on-gke
10. デモ：エージェントの回答（表＋考察を自動生成） BigQuery MCP が SQL を自動実行し、集計結果と考察を自然言語で返す SQL を書かずに、集計から考察まで SQL を自動実行 質問を送ると BigQuery MCP 経由で SQL が自動生成・実行される 結果を表で提示 月別の売上額・注文数を集計し、そのまま表として回答 考察まで自然言語で生成 「年間で右肩上がり」「年末商戦で 12 月が最大」などの示唆を付与 対話でそのまま深掘り 商品カテゴリ別・ユーザー属性別など、追加分析も会話で継続できる ポイント：SQL の知識がなくても、担当者が自分でデータを分析できる 出典：T.REX「KagentをGKE上で動かしてみた ― BigQuery MCP 連携まで」Zenn https://zenn.dev/ukrocksre/articles/kagent-on-gke
11. 現状の課題 2026
12. MCP / API が返すのは「変更の事実」だけ 自然言語で調査可能になっても、それは変更履歴の再確認にすぎない CloudWatch MCP CloudTrail MCP Athena / CUR MCP いつ・何が起きたか 誰が・何をしたか どのコストが増えたか メトリクスの急変からコスト急増と一致 するリソースの異常を特定 API 操作ログからリソースの作成・変更・ 削除を時系列で抽出 サービス・リージョン別にコスト変化を 分解して定量化 得られるのは “変更の事実” 得られるのは “変更の事実” 得られるのは “変更の事実” 3 つの MCP が返すのは、すべて「いつ・誰が・何を変更したか」という変更履歴の事実 自然言語で問い合わせられるようになっても、事実の再確認にとどまり、本質的な問い ―「その変更は必要だったのか」― に は答えられない
13. 抜けているのは「なぜ」の視点 事実（What / Who / When）が揃っても、Why が無ければ変更の是非は判断できない エージェントが答えられること 答えられないこと ＝ 変更の事実 ＝ なぜ、その変更をしたのか いつ増えたか コスト急増の時刻・期間 誰が変更したか 操作した IAM ユーザー・ロール ？ 変更の意図・背景がわからない そのため、コスト増が 「事業上必要な変更」なのか 「削減すべき無駄」なのかを 判断できない 何を変更したか 対象リソース・設定の変更内容 事実の自動収集だけでは、本質的な解決に繋がらない
14. 解決アプローチ 2026
15. 気づき：要因は「人」に聞くしかない エージェントの調査結果を基に、システム担当者へ「なぜ変更したか」を確認して初めて要因が確定する › › › Kagent の調査結果 担当者へヒアリング 「なぜ」が判明 要因を確定 変更の事実（いつ・誰が・何を） を提示 「なぜこの変更をしたのか」を確 認 変更の意図・背景が明らかになる コスト増の是非を判断できる ヒアリングの例 調査担当 「なぜこのインスタンスをスケールアップしたのか?」 システム担当 「キャンペーン対応で一時的に増強。想定内の変更 」
16. 不足していたもの ＝ システムごとの担当者リスト 「誰に聞けばよいか」を、コスト分析エージェントが知らなかった 担当者リスト（イメージ） アプリケーション担当 インフラ担当 デプロイ・機能変更・スケール 設定など、アプリ由来のコスト 変動を把握 ネットワーク・ストレージ・基 盤リソースなど、インフラ由来 の変動を把握 システム アプリ担当 インフラ担当 決済 API 佐藤 田中 レコメンド基盤 鈴木 高橋 データ分析 山本 中村 この「システム × 担当者」という社内特有のコンテキストが、エージェントには無かった 担当者情報が無いと、要因を確定するための「誰に聞くか」の特定に、結局また人手の探索が必要になる。 ＝ ここを埋めれば、エージェントの回答は「事実」から「次のアクション」へと踏み込める
17. 解決アプローチ：担当者リストの一元管理 属人的な Excel 管理から、Backstage による Software Catalog 管理へ Before：Excel 管理 After：Backstage 管理 ✕ 担当者が変わっても更新が滞りやすい ✓ Software Catalog で担当者を一元管理 ✕ 所在が散在し、最新版がどれか分からない ✓ システムのメタデータとして常に最新化 ✕ API で参照できず、エージェントが取得不可 ✓ Backstage API 経由でエージェントが取得可能 一元管理 常に最新 API 連携 担当者情報を単一の情報源に集約 システム定義とともに更新される エージェントが自動で参照できる
18. あるべき姿：社内コンテキストを参照するエージェント 変更の事実 ＋ 担当者リスト（社内コンテキスト）で「誰に聞けばよいか」まで回答する › › › コストアラート Kagent が調査 Backstage API で 担当者を取得 誰に聞くかまで回答 Cost Anomaly Detection が検知 変更の事実を MCP で収集 システム × 担当者の社内コンテキス トを参照 ファクトチェックの相手を明示 エージェントの回答（あるべき姿） 「決済 API のコストが前日比 +38% 増加。CloudTrail 上、EC2 インスタンスのスケールアップが要因です。確認は 決済 API のインフラ担当・田中さん（Backstage 参照） へ。“なぜ増強したか”をヒアリングすればファクトチェックでき ます」
19. Backstage 連携のアーキテクチャ Kagent が Backstage Catalog API を呼び出し、システムの担当者（アプリ／インフラ）を解決する Backstage（開発者ポータル） ① 照会リクエスト（Bearer） Catalog REST API Kagent エージェント ② 担当者（アプリ／インフラ）を取得 /api/catalog/entities … Software Catalog Component → owner（Group） ＋ 担当者アノテーション 担当者を Backstage に照会 Auth：Bearer Token（Secret） API 連携の流れ 1 コスト異常のリソースタグからシステム名を特定（例 system=paymentapi） 2 Backstage Catalog API を Bearer Token 付きで呼び出す 3 Component の owner（Group）と担当者アノテーションを解決 4 アプリ担当・インフラ担当を回答に組み込み「誰に聞くか」を提示 REST 呼び出しと解決結果（例） GET /api/catalog/entities/by-name/ component/default/payment-apiAuthorization: Bearer $TOKEN─────────────────────────spec.owner: group:default/paymentteamannotations: finops/app-owner: 佐藤 finops/infra-owner: 田中
20. まとめ 2026
21. まとめ・今後の展望 社内コンテキストの連携で、コスト分析エージェントを「次の一手」まで踏み込ませる 1 2 3 事実だけでは不十分 社内コンテキストを連携 次のアクションまで回答 MCP / API が返す変更履歴の“事実”だけでは 「なぜ」に答えられず、本質的な解決に繋 がらない システムごとの担当者リストを Backstage で一元管理し、API 経由でエージェントに 供給する 「誰に聞けばファクトチェックできるか」 まで示し、要因確定の初動を高速化する 今後の展望 担当者リストに加え、システム構成・SLO・オンコール情報など他の社内コンテキストも Backstage 経由で統合。エージェント の調査精度と自律性を高め、組織全体の FinOps 成熟度向上へ