財布に穴が開くほど高くつくLLM
クラウド黎明期を覚えていますか。当時のFinOps最大の悩みの種は、タグの付いていないVMでした。開発者が大きなサーバーを立ち上げ、ラベル付けを忘れる。月末になると、正体不明の未割当コストがドカンと現れる。確かに厄介な問題でしたが、コストが膨らむのはたいてい数週間かけての話でした。
さて、ここからが本番です。AI時代のFinOpsが到来し、これまでとは比べものにならない衝撃が待っています。新たなコストのブラックホールは、隠れたサーバーではなく暴走するトークンです。
最適化されていないプロンプトが高価なLLMに毎秒100回叩き込まれれば、予算は漏れるどころか爆発します。数か月ではなく、数時間で予算を吹き飛ばすコストスパイクが起きるのです。
では、どうするか。インフラのタグ付けからアプリケーションレベルのテレメトリへと、視点を切り替える必要があります。すべてのトークンのコストをリアルタイムで追跡しなければなりません。
これはAIエージェントを扱う場面で特に重要になります。セッションごとに特定のユーザーへ簡単に紐づけられるチャットボットではなく、チーム全体のために自律的に動くエージェントを想定した話です。
AI時代のFinOps：クラウドのテレメトリだけでは足りない
クラウドプロバイダーの請求情報(Cost Explorer、Cost Managementなど)に頼る従来のコスト追跡では、AIのAPI利用に対しては遅すぎ、粒度も粗すぎます。
FinOps 1.0と、これから求められるAI時代のFinOpsを比較したのが次の表です。
| 項目 | 初期のクラウドFinOps | 現在のAI FinOps（API）
|------------------|--------------------------------|----------------------------------------
| コスト単位 | VM時間、ストレージGB | 入力トークン、出力トークン
-------------------|--------------------------------|-----------------------------------------
| コスト要因 | 遊休リソース、 | プロンプト効率、
| | ネットワーク下り通信 | モデル選択
-------------------|--------------------------------|-----------------------------------------
| コスト可視性 | 日次・時次の請求ログ | リアルタイムのトランザクション単位テレメトリ
-------------------|--------------------------------|-----------------------------------------
| 最適化手段 | サーバーの停止 | - プロンプト／コードの書き換え
| | | - リアルタイムのモデル選択
-------------------|--------------------------------|-----------------------------------------
AIアプリケーションのコストを本気で管理したいなら、請求書を待っている余裕はありません。アプリケーション層にFinOpsの仕組みを直接組み込み、送受信されるトークンを1つひとつレポートする必要があります。そこで救世主となるのがOpenTelemetry（OTel）です。
チュートリアル：OpenTelemetryでAIエージェントを計装する
OpenTelemetryは、可観測性データ(トレース、メトリクス、ログ)を収集するための統一標準を提供するオープンソースのフレームワークです。そのトレース機能を使ってLLM呼び出しをラップし、必要なFinOpsコンテキストを注入していきます。
以下の例では、OpenTelemetryとGoogle Agent Development Kit(ADK)を使って、AIエージェントにFinOpsのコスト配賦トラッキングを実装する方法を紹介します。
このコードこそ、FinOpsを縛りから解き放つ鍵です。AIエージェントが消費するすべてのトークンに、正しい予算オーナーが瞬時にタグ付けされます。もう犯人探しは不要です。
動作するコード一式はこちら： https://github.com/antweiss/finops-ai-otel
重要な注意：本番環境では使わないでください
本チュートリアルでは、生のトレースデータをターミナルに出力する目的でConsoleSpanExporterを使っています。本番環境では絶対にこのままにしないでください。
本番では、コンソールエクスポーターを専用のOTLP Exporterに置き換え、次のような堅牢なバックエンドへデータを送ります。
- Google Cloud Trace：Google Cloudユーザー向けのネイティブな選択肢。
- マネージド可観測性バックエンド：Jaeger、Datadog、New Relicなど。
- 専用のFinOps管理プラットフォーム(例：DoiT Cloud Intelligence)
これらのバックエンドであれば、データをクエリして集計し、たとえば「過去30日間でfinops.project_codeが‘BLOG-FINOPS-001’のトークン使用量の合計を表示」といったFinOpsレポートを実行できます。これこそ、トレースをコストレポートに変える方法です。
ステップ1＆2：実行の準備
いつもの手順です。リポジトリをクローンし、依存関係をインストールし、APIキーを設定します。
git clone https://github.com/antweiss/finops-ai-otel.git
cd finops-ai-otel
pip install -r requirements.txt
export GEMINI_API_KEY="YOUR_API_KEY_HERE"
ステップ3：コードを実行してトークンの動きを覗く
agent.pyを実行すると、run_finops_session関数の中でFinOpsの仕掛けが一気に起動します。
python agent.py
FinOpsタグはこうして埋め込まれる(コード解説)
狙いは、エージェントの活動全体を、予算情報を持たせたカスタムのOpenTelemetry Spanでラップすることです。
FinOps Spanの開始：
with tracer.start_as_current_span("adk-agent-session") as span:
この一行がすべての肝です。スパンを開始し、それを現在のアクティブなスパンとして宣言します。OTelで計装された後続のコード(Google ADK内部のLLM呼び出しなど)は、このアクティブな親スパンの子として、自動的に独自のスパンを生成します。
FinOpsメタデータ(タグ)の追加：
span.set_attribute("finops.team_id", team_id)
span.set_attribute("finops.project_code", project_code)
ここでコストセンターの情報を注入します。ADKの内部スパン(トークン数を含む)はこのスパンの子になるので、トレースバックエンドはすべてのトークン使用量をfinops.project_codeの直下に紐づけて見えるようになります。これで配賦の問題は解決です。
押さえておきたいFinOpsメトリクス
def setup_opentelemetry_tracer():
"""実行可能なデモ用にトレーサーをコンソール出力に設定します。"""
# 1. TracerProviderを作成
provider = TracerProvider()
# 2. トレースをコンソールへ出力するシンプルなプロセッサを追加
# 生のトレースデータと属性がそのまま見えます
provider.add_span_processor(SimpleSpanProcessor(ConsoleSpanExporter()))
# 3. グローバルプロバイダとして設定
trace.set_tracer_provider(provider)
return trace.get_tracer("finops.adk.agent")
ConsoleSpanExporterの出力が、そのままその場のコストレポートになります。ネストされたLLM呼び出しスパンを見れば、課金に関わる情報の全体像がつかめます(finops.*属性はサンプルコード側で設定し、llm.*属性とメトリクスはADKのLLMAgentから渡されます)。
応用編：マルチエージェント構成でのSpanの引き継ぎ
あるエージェントが別のエージェントへ作業を委譲する複雑なワークフローではどうなるのか。ここでこそOpenTelemetryの本領が発揮されます。
- OTelのモデルでは、エージェント(親)が別のエージェントやツール(子)を呼び出すと、親スパンのトレースコンテキストが呼び出しチェーンに沿って自動的に伝播します。
- エージェントとツールの一連の実行はすべて、最初に作成したFinOps Spanのコンテキスト内で行われます。
- つまり、最上位のFinOpsタグ1つで、複雑な多段階のエージェント連携全体をカバーでき、ワークフロー全体について統一された監査可能なコストレポートが得られるのです。この性質は、ADKが採用している標準のOTel計装から自然に受け継がれています。
関連リンク
このFinOpsソリューションを支える基盤について、さらに学びたい方はこちらをご覧ください。
ADKがOpenTelemetry計装をネイティブにサポートしていることが確認できます。
Getting Started with OpenTelemetry
Span、Context、Context Propagationといった基本原則を解説しています。
このトレース手法が活きるエージェントの種類(LlmAgent、SequentialAgent)について詳しく説明しています。
次回は、AIアプリケーションに実効性のあるコストガードレールを設ける方法を取り上げます。