FinOpsで実現するコスト分析エージェントの信頼性構築 OSSベースのガードレール戦略

KubertebesネイティブのOSSツールのクラウドコスト最適化の取り組みにおいて、
AIエージェントによる自動分析は強力な手段となりつつある。
しかし「エージェントが出した答えをそのまま信じてよいのか」という信頼性の問題は、本番運用における大きな障壁となっている。本発表では、FinOpsの文脈でコスト分析エージェントを実運用に乗せるために必要なガードレール戦略を、KubernetesネイティブのOSSツールを活用した監査ログの観点から解説する。

Transcript

1. FinOpsで実現するコスト分析エージェントの 信頼性構築：OSSベースのガードレール戦略
2. はじめに 1 / 33
3. アジェンダ 01 FinOps とは — 概要・課題・フレームワーク 02 Kagent の紹介 — アーキテクチャと標準ログの限界 03 ガードレール戦略 — 監査ログとは・収集設計 04 収集パイプライン — OSSスタック全体構成 05 まとめ 2 / 33
4. 自己紹介 3 / 33
5. 自己紹介 4 / 33 • 名前：T.REX • 会社：Sky株式会社 • 部署：自社システム開発部門のSREチーム • 業務： • 自動化ツールの開発 • AIエージェントの設計・開発 • FinOpsの技術文化醸成の推進 • X：@ukrock1996
6. FinOpsとは •「クラウド財務管理」の新概念。 コスト管理とビジネス価値の最大化を目的とした運用モデル •クラウド黎明期は「リフト&シフト」が目的。 現在は「クラウドをいかに賢く使いこなし、事業成果に結びつけるか」と いうフェーズへ •SP/RI の割引にとどまらず、 組織として技術的にクラウドのコストを最適化する文化を醸成する活動 5 / 33
7. FinOps フレームワーク — 3フェーズサイクル 01 Inform 可視化・把握 コスト配分・タグ管理・使用率レポート・予算アラート設定 02 Optimize 最適化・削減 Rightsizing・リザーブド/スポット活用・未使用リソース削除 03 Operate 運用・定着化 FinOps文化の醸成・KPI設定・自動化・部門間コスト責任化 出典: FinOps Foundation 6 / 33
8. フレームワーク クラウドコストを可視化‧最適化するためのプラクティス フェーズ 内容 Inform コストの可視化‧タグ付け Optimize 無駄の排除‧最適化 Operate ROI測定‧継続的改善 OptimizeとOperateフェーズで AIを用いて分析する為にAIエージェントの導入を検討 7 / 33
9. Kagentの紹介 8 / 33
10. KagentとはKubernetesネイティブなAIエージェント Solo.ioが開発しCNCFへの貢献を発表したOSSフレームワーク 特徴 KubernetesのCRDでエージェントを宣言的に定義 MCPと連携してToolを呼び出せる クラウドコストAPIやアラートシステムと連携しやすい FinOpsとの相性 コスト分析‧最適化提案をエージェントに委譲できる kubectl操作‧Prometheus参照も標準でサポート 9 / 33 https://zenn.dev/ukrocksre/articles/kagent-intro
11. 課題：AIエージェントは怖い エージェントが何を考え何を実⾏したか⾒えない コストAPIを勝手に操作するかもしれない どのToolを呼び出したか追跡できない エラー時に原因を遡れない ブラックボックスのまま本番投入はリスクがある 可視性のなさが、エージェント活⽤の最⼤の壁 10 / 33
12. 監査ログとは システムが「いつ」「誰が」「何を」「どのように」操作したかを記録したログ。 不正・障害・コンプライアンス対応の証拠として活用される。 何を記録するか 操作内容・入力・出力・判断結果 誰が操作したか エージェントID・ユーザー・サービス いつ実行されたか タイムスタンプ・実行時刻・所要時間 結果はどうだったか 成功・失敗・エラー内容・レスポンス FinOps文脈では：コスト操作・リソース変更の全履歴が監査対象。 エージェントの判断も例外なく記録が必要。 11 / 33
13. しかしKagentの標準ログ（ stdout ）には限界がある 標準で出力されるのはヘルスチェックのログのみ エージェントの判断‧思考プロセスが記録されない Tool呼び出しの入出力が追跡できない 誰が‧いつ‧何を実⾏したか分からない PostgreSQLのイベントテーブルに監査ログが存在する ただし標準ではイベントテーブルログでは外部基盤に連携されていない 12 / 33
14. PostgreSQL: イベントテーブルの中身 Kagentはエージェントの全操作をagent_eventsテーブルに記録する SELECT * FROM events LIMIT 1; -- 結果例 id | evt-0001 agent_id | finops-cost-agent event_type | tool_call tool_name | get_cloud_cost_summary input_payload | {"service":"ec2","region":"ap-northeast-1"} output_payload| {"total_usd":12480.5,"period":"2025-04"} status | success created_at | 2025-04-33 09:12:34.001+09 13 / 33
15. 標準ログ vs 監査ログの差 Kagentの標準ログはヘルスチェックのみ — エージェントの操作は何も見えない 標準ログ（ヘルスチェッ クのみ） $ kubectl logs kagent-pod time="2025-04-30T09:12:30Z" level=info msg="health check ok" time="2025-04-30T09:12:31Z" level=info msg="health check ok" # ← 操作ログは何もない PostgreSQLの監査ログ SELECT agent_id, tool_name, status, created_at FROM agent_events ORDER BY created_at DESC; finops-cost-agent | get_cloud_cost | success finops-cost-agent | send_alert | success 標準のkubectl logsでは操作履歴は何も残らない。 PostgreSQLのagent_eventsテーブルを読み出すことが監査の起点となる。 14 / 33
16. ガードレール戦略 15 / 33
17. ガードレールの3層構造 エージェントへのガードレールは3層で考える 層 内容 今⽇フォーカスするのは検知層 何が起きたかを記録することが信頼性の基盤になる 16 / 33 種類 1層 予防 予防 権限制限 2層 検知 監査ログの収集 3層 対応 対応アラート
18. 何を記録すべきか 今回のスコープはエージェントの操作ログに絞る 記録対象 エージェントが受け取った指⽰‧⼊⼒内容 エージェントが選択したToolと呼び出しパラメータ Toolの実⾏結果‧レスポンス内容 エージェントの最終的な判断‧出⼒ なぜ操作ログか 「何を実⾏したか」が監査の核⼼だから 17 / 33
19. どこで収集するか エージェントの操作はPostgreSQLのイベントテーブルに集約 Kagentの操作履歴はDBのイベントテーブルに記録される Tool呼び出しの入出力もイベントとして蓄積される エージェントの判断フローも同テーブルから取得可能 1箇所を見ればエージェントの全操作をトレースできる まずここを外部基盤に連携することが第一歩 18 / 33
20. 収集パイプラインの実装 19 / 33
22. 収集スタックの全体構成 コンポーネント 役割 PostgreSQL エージェント操作イベントを保持 Logstash JDBCでポーリング‧OTLP変換 OTelCollector OTLP形式で収集‧転送 Grafana Loki 操作ログの蓄積‧検索‧可視化 ベンダーロックインなしで全OSSで完結する構成 21 / 33
23. KagentからOpenTelemetryCollectorにログを転送する 公式ドキュメントによるとプロンプトの監査ログを転送出来そう 22 / 33 https://kagent.dev/docs/kagent/observability/audit-prompts
25. 問題：HTTP/gRPC プロトコル切替が効かない Helm インストール時のデフォルト動作と既知のバグ（Issue #1682） 問題の概要（GitHub Issue #1682） Helm インストール後、OTLP エクスポーターのプロトコルがデフォルト http/protobuf になる ConfigMap で OTEL_EXPORTER_OTLP_PROTOCOL=gRPCを設定しても Kagent Controller がデフォルトに戻す 結果：HTTP のみ対応バックエンド（Langfuse 等）への転送が失敗する 解決策：CRD の環境変数で gRPC を指定する Agent CRD の spec.env に環境変数を直接設定することで Controller の上書きを回避 OTEL_EXPORTER_OTLP_ENDPOINT を OTel Collector の gRPC ポート（:4317）に向ける # Agent CRD の spec.env に環境変数を設定 spec: env: - name: OTEL_EXPORTER_OTLP_ENDPOINT value: "http://opentelemetry-collector.telemetry.svc.cluster.local:4317" - name: OTEL_EXPORTER_OTLP_PROTOCOL value: "grpc" 24 / 33
26. KagentからOpenTelemetry Collectorにログを転送する OTEL_EXPORTER_OTLP_TRACES_PROTOCOL/環境 OTEL_EXPORTER_OTLP_PROTOCOL変数は読み込む事が出来ない 25 / 33 https://github.com/kagent-dev/kagent/issues/1682
27. 問題の再現：ConfigMap が Controller に上書きされる仕組み Kubernetes Cluster / namespace: kagent Kagent Controller Pod Agent CRD を監視する Reconcile ループが常時稼働 ➜ デフォルト値で Agent Pod の env を上書き ➜ ConfigMap の変更を無効化してしまう env を強制上書き（gRPC） Agent Pod ( finops-cost-agent ) # Controller 上書き後 OTLP_PROTOCOL: http/protobuf ⇐ 強制的に上書き OTLP_ENDPOINT: :4317 ⇐ 反映されない（Issue #1682） ConfigMap（http/protobuf 設定） OTLP_PROTOCOL: gRPC# 設定した値 Controller に http/protobuf で上書きされ無効 解決策：CRD の spec.env に直接記述 Agent CRD（kagent.yaml）の spec.env spec: env: - name: OTEL_EXPORTER_OTLP_PROTOCOL value: "grpc" # CRD で明示 - name: OTEL_EXPORTER_OTLP_ENDPOINT value: "http://otel-collector .telemetry.svc:4317" Agent Pod（CRD 適用後） OTLP_PROTOCOL: grpc ✓ OTLP_ENDPOINT: :4317 ✓ ➜ OTel Collector へ gRPC 転送成功 26 / 33
28. OTEL 監査ログ転送：サンプルコード全体 Agent CRD + Helm values.yaml の設定例（gRPC プロトコルで OTel Collector に転送） ① Agent CRD（kagent.yaml） apiVersion: kagent.dev/v1alpha1 kind: Agent metadata: name: finops-cost-agent spec: description: "FinOps cost agent" modelConfig: openai-gpt4o # Issue #1682 対策: CRD 側で gRPC を明示 env: - name: OTEL_EXPORTER_OTLP_ENDPOINT value: "http://otel-collector .telemetry.svc:4317" - name: OTEL_EXPORTER_OTLP_PROTOCOL value: "grpc" - name: OTEL_LOGS_EXPORTER value: "otlp" ② Helm values.yaml（kagent OTel 設定） # values.yaml (helm upgrade kagent) providers: default: openAI otel: tracing: enabled: true exporter: otlp: endpoint: "http://otel-collector .telemetry.svc:4317" insecure: true logging: enabled: true exporter: otlp: endpoint: "http://otel-collector .telemetry.svc:4317" insecure: true 27 / 33
29. 監査ログ転送の確認：OTel Collector ログ出力例 gRPC 経由で OTel Collector に到達したプロンプト監査ログの実際の出力 確認コマンド $ kubectl -n telemetry logs -l app.kubernetes.io/name=opentelemetry-collector 出力例：プロンプト監査ログが gRPC 経由で転送されていることを確認 LogRecord #115 ObservedTimestamp: 2026-01-12 16:02:13.278 UTC SeverityNumber: Info(9) Body: Map({"content":"EC2 ap-northeast-1 コスト分析結果: ... Attributes: -> gen_ai.system: Str(openai) -> event.name: Str(gen_ai.user.message) -> agent.id: Str(finops-cost-agent) 結果：CRD 側で gRPC プロトコルを明示することで、Kagent のプロンプト監査ログを OTel Collector 経由で Grafana Loki に転送することに成功 28 / 33
30. KagentからOTel Collectorへ転送 標準OTLPパイプラインでGrafana Lokiに集約する Lokiに集約する事でGrafanaでの監査ログでの可視化も可能になる 29 / 33
31. まとめ 33 / 33
32. まとめ FinOpsへのAIエージェント活要ニーズは急増しているが 必ずガードレールを適用することが必要 ガードレールは予防‧検知‧対応の3層で設計する 31 / 32 コスト最適化という課題に対して システムを導入して技術的負債を解決する点に非常に魅力的
33. 参考文献 FinOps for AIとは（i3design）: https://www.i3design.jp/in-pocket/finops-for-ai FinOps 3.0とAIエージェント（JTP）: https://solution.jtp.co.jp/blog/reinvent2025_005 Kagent MCP Tools Getting Started: https://kagent.dev/docs/kagent/getting-started/first-mcp-tool Bringing Agentic AI to Kubernetes / CNCF: https://www.solo.io/blog/bringing-agentic-ai-to-kubernetes- contributing-kagent-to-cncf Trace-Aware PostgreSQL Logging with OpenTelemetry: https://www.dash0.com/guides/postgresql-logs-tracing- opentelemetry logstash-output-opentelemetry plugin: https://github.com/paulgrav/logstash-output-opentelemetry 33 / 33