エージェント型AIにおけるトークン爆発：CI/CDでのLLMコストの特定、予算化、制御

‍現代のエンジニアリング組織において、CI/CDは静かにLLMコストの最大の要因の一つとなっています。すべてのプルリクエストで起動する単一のセキュリティレビューエージェントは、エンジニアリングチーム全体の顧客向けAIワークロードの3倍もの費用を消費する可能性があります。プロバイダーの請求書には合計金額が記載されていますが、どのパイプライン、どのリポジトリ、どのエージェントステップが原因であるかは示されません。そのような帰属情報がなければ、唯一可能な対応は全面的な禁止であり、生産性の損失は当初の超過分を上回ってしまいます。

TrueFoundryのAIゲートウェイは、すべてのリクエストに対する必須のメタデータタグ付け、ソフト、制約付き、ハードのしきい値を持つ階層的なコストセンターごとの予算、そして請求書に記載される前に超過分を明らかにするローリングP95予測という3つの基本機能でそのギャップを埋めます。この投稿の設定は、実際の、コピー＆ペースト可能なものであり、TrueFoundryの公式の 予算制限 と レート制限 スキーマに基づいています。

なぜCI/CDが経済性を変えるのか

本番環境のLLMアプリケーションはユーザーのトラフィックで動作し、そのトラフィックはユーザー数とリクエスト頻度によって制限されます。一方、CI/CDパイプラインはマシンのトラフィック、つまり自動エージェント、スケジュールされたジョブ、定期的な回帰テスト、すべてのPRレビューなどで動作します。そのため、コストの形態は根本的に異なります。例えば、50人のエンジニアがそれぞれ週に15件のプルリクエストを開くと、ユーザー向け機能に誰も触れる前に、週に750件のPR駆動型LLM呼び出しが発生します。各呼び出しは4つまたは5つのエージェントステップを連鎖させ、各ステップは数千トークンのコンテキストを持つ複数のモデル呼び出しを行う可能性があります。ユーザー向けAIとCI/CD AIの間のスループット乗数は、通常10倍から100倍にもなります。

エンジニアリングリーダーシップが最初に気づくのは、財務部門が誰も想定していなかった金額の請求書を転送してきたときです。オブザーバビリティなしにエージェント型CI/CDを導入するすべての組織で、同じ話が繰り返されます。10月は少額の請求、11月は中程度の請求、そして12月は役員会議を招集する月となります。このパターンは十分に一貫しているため、プラットフォームチームはこれを驚きではなく、運用上の期待値として扱うべきです。

プロバイダーの請求における盲点

プロバイダー（Anthropic、OpenAI、Bedrockなど）の請求書は、モデルとトークンの種類ごとに項目を記載します。しかし、プロバイダーはあなたのエンジニアリング組織内でそれらの概念が何を意味するのかを知らないため、リポジトリ、パイプライン、またはエージェントステップごとに項目を記載することはできません。その情報は、プロバイダーが決して見ることのないあなたのリクエストメタデータに存在します。プロバイダーの視点から見ると、先月の8億4700万のSonnet入力トークンはすべて同じに見えますが、あなたの視点から見ると、その80%は、もし知っていれば最初の週に抑制していたであろう暴走した1つのパイプラインから発生したものです。

財務部門が受け取る情報と、エンジニアリング部門がデバッグに必要とする情報の間の不一致が、コストガバナンスプロジェクトが停滞する構造的な理由です。財務部門は請求書を受け取り、エンジニアリング部門も同じ請求書を受け取りますが、内訳はありません。ワークロードごとの台帳がなければ、対応は「原因がわかるまで2週間AIへの支出を停止する」というものに陥り、それはAIが生み出していた生産性向上を台無しにします。

同じ8,400ドルの2つの見方

チームに帰属情報があるかどうかによって、同じ金額が正反対の対応を生み出します。帰属情報がなければ、対応は構造的なものになります。支出を禁止し、リーダーシップにエスカレートし、全員にとって不快な会議をスケジュールすることになります。帰属情報があれば、対応は一人のエンジニアがコスト台帳を読み、特定のパイプラインのステップ2がすべてのプロンプトに50,000トークンのポリシーマニュアルを挿入していることを特定し、ステップ2をセマンティックキャッシュ経由でルーティングするための一行の構成変更を記述するというものになります。同じ請求書でも、結果は異なります。

ゲートウェイレベルのメタデータタグ付け

コスト帰属の基盤は、ゲートウェイでの必須タグ付けです。CI/CDパイプラインは、すべてのリクエストにIDを注入する必要があります。これにより、チーム、リポジトリ、パイプライン、エージェントステップ、および責任のあるコストセンターを特定します。TrueFoundryの リクエストヘッダーのドキュメント、そのIDは単一のヘッダーで伝達されます — x-tfy-metadata — その値は、文字列のキーと文字列の値を持つ文字列化されたJSONオブジェクトで、各値は128文字に制限されます。JSON内のフィールドはプラットフォームチームによって定められた慣例であり、それ自体はHTTPヘッダーではありません。

CI/CDパイプラインからの正しく形成されたリクエストは、ネットワーク上では次のようになります。

POST /api/llm/api/inference/openai/chat/completions HTTP/1.1
Host: gateway.truefoundry.ai
Authorization: Bearer {TFY_API_KEY}
Content-Type: application/json
x-tfy-metadata: {"team":"payments-platform","repo":"transaction-service","pipeline":"pr-security-audit","agent_step":"step-2-policy-check","cost_center":"eng-backend","run_id":"gh-run-882134"}

ゲートウェイのドキュメントには、正確に9つの受け入れられるカスタムリクエストヘッダーが列挙されています。 Authorization、 x-tfy-metadata、 x-tfy-provider-name、 x-tfy-strict-openai、 x-tfy-retry-config、 x-tfy-request-timeout、 x-tfy-ttft-timeout-ms、 x-tfy-logging-config、および x-tfy-mcp-headers。カスタムID（チーム、リポジトリ、パイプライン、コストセンター、実行ID、その他プラットフォームチームが定義するもの）は、厳密に x-tfy-metadataのJSON値の中にのみ存在し、個別のヘッダーとしては存在しません。これがゲートウェイが認識する唯一の契約です。追加の x-tfy-* ヘッダーを考案するチームは、それらが黙って無視されることに気づくでしょう。メタデータはコスト追跡層やポリシー層に到達せず、ダッシュボードは属性を失い、監査ログにはベアラートークンのみが含まれます。ヘッダーは1つ、その中にJSON、これがルールです。

コストセンターごとの予算とサーキットブレーカー

実施を伴わない可視化は、誰も行動を起こさないダッシュボードに過ぎません。ゲートウェイは、タグ付けによって生成されるすべてのコストセンターに対し、階層的で数学的に強制される予算を割り当てます。例えば、決済プラットフォームチームはCI/CDエージェントワークフローに週500ドルを受け取ります。その予算は、ゲートウェイの要求パス上で、異なる応答をトリガーする3つのしきい値によって強制されます。

上限の75% — ソフトアラート。 ウェブフックがチームのSlackチャンネルに投稿します。「今週のAI予算の4分の3を使い切りました。」トラフィックの中断はありません。ワークロードの担当者は、通常の勤務時間中にアラートを確認し、エージェントの動作を調整するか、クォータの増加を要求するか、または支出が正当であるため何もしないかを決定できます。

90% — 制限モード。 プレミアムモデル（Sonnet 4.6、Opus 4.7、GPT-4o）はブロックされます。ゲートウェイは、仮想モデルフォールバック設定を通じて、より安価なフォールバック（Haiku 4.5、GPT-4o-mini）にリクエストを透過的にルーティングするため、コストを抑えつつパイプラインは稼働し続けます。フォールバックチェーンは別のルーティング設定で定義されます。予算設定が制約をトリガーし、ルーティング設定が切り替えを実行します。アプリケーションは、実際にリクエストを処理したモデルを示すヘッダーを確認でき、特定のワークロードでは品質が異なる場合があります。

100% — ハードキャップ。 ゲートウェイはHTTP 429でそれ以降のリクエストを拒否します。以下は、プラットフォームチームがエラーボディのために通常設計する形式です。ゲートウェイのデフォルト応答は簡潔であり、チームはラッピング層を介してコストセンターのコンテキスト、ダッシュボードへのポインタ、およびクォータリクエストフローでそれを補強します。

{
  "error": "Budget Exceeded",
  "detail": "Cost center 'eng-backend' has exhausted its weekly $500 AI budget.",
  "context": {
    "spent_to_date": "$501.23",
    "cap": "$500.00",
    "resets_at": "2026-05-19T00:00:00Z",
    "top_consumer": "pipeline=pr-security-audit · 87% of spend"
  },
  "mitigation": "Review pipeline logs for runaway loops, or request a quota increase at /governance/quota."
}

エラーボディは設計の一部です。予算に達したパイプラインは、開発者がプラットフォームチームに状況を問い合わせることなく、次に何をすべきか（ログの確認、クォータリクエストの提出など）を知るべきです。CIランナーは429を標準的なバックオフシグナルとして解釈します。ビルドは混乱するような方法でクラッシュするのではなく、実行可能なメッセージとともにきれいに失敗します。同じ429パターンは、レート制限層および暴走検出層と連携し、複数の制御を超過するワークロードが、無関係なエラーの連鎖ではなく、一貫した失敗パスを受け取るようにします。

コスト帰属ダッシュボードの構築

Grafanaに流れるタグ付けされたデータにより、プラットフォームチームは、集計ノイズを増やすのではなく、所有権に関する疑問に答えるダッシュボードを構築できます。スパイクをじっと見て「誰がこれをやったのか？」と尋ねる代わりに、ダッシュボードはすでに、UTC 02:00にフロントエンドチームが新しいエージェントを Reactモノレポ 存在しない依存関係を誤って認識し、400ステップの解決ループに陥ったものです。メタデータフィールドはPrometheusのラベルとして表示され、標準的なPromQLクエリによりチーム別、リポジトリ別、パイプライン別の内訳が生成され、標準的なGrafanaダッシュボードでそれらが可視化されます。

このような運用上のコンテキストは、コストを財務上の問題からエンジニアリング上の問題へと転換させます。チームが、最初のコード要約ステップをSonnet 4.6からHaiku 4.5に切り替えることで、PRレビューの品質に影響を与えることなくそのステップのコストを80%削減できると分かれば、彼らはその変更を行います。予算上限に関する議論は運営委員会で行う必要はありません。データが議論の根拠となり、変更がその対応となるのです。

有用なダッシュボードには3つのビューがあります。時間経過に伴うコストセンターごとの総コスト、パイプラインとステップごとのドリルダウン、そしてコストの異常値を自動的に検出する異常ビューです。最初の2つは運用ビューであり、3つ目は予算超過が発生する前に暴走を検出する早期警告ビューです。ゲートウェイから出力されるOpenTelemetryトレースには、モデル、トークン数、メタデータフィールド、呼び出しごとのドル金額が含まれており、Grafanaの既存ツールが残りを処理します。

請求書が届く前の月間支出予測

集約されたタグ付けデータは、予測を容易にもします。エージェントワークロードはバースト性があり、定期的な重いCIジョブが請求の大部分を占めるため、単純な移動平均では支出を体系的に過小評価してしまいます。3週間で1日あたり40ドル、ある水曜日のリリーストレイン実行で400ドルを平均したチームの移動平均は1日あたり51ドルですが、もし彼らがさらに2つのリリーストレインを出荷した場合、実際の月末支出は2,000ドルを超えます。

ゲートウェイは、リポジトリごと、コストセンターごとに7日間のP95ローリング予測を実行します。P95は、平均が平滑化してしまうバーストリスクを捉え、財務部門が驚く前に、予算を調整したり、クォータを引き上げたり、問題のあるパイプラインを停止したりするのに十分なリードタイムを持って月末支出を予測します。「驚き」がキーワードです。これは、驚きを生み出さないように設計された予測なのです。予測がチームの月間予算を30%超過する見込みであると示した場合、チームには厳格な上限が発動するまでに2〜3週間の猶予があります。

予測はリアルタイムの支出と同じGrafanaダッシュボードに表示され、予測は履歴曲線と並んで描画されます。毎週予測をレビューするプラットフォームチームは、次四半期の予算危機を引き起こすパターンを把握します。予測をレビューしないチームは、これまでと同じように財務部門から問題を知ることになります。

具体例：8,400ドルの請求書から1行の修正へ

以下に示すのは、このチームが実際の顧客導入で見てきたパターンから作成された例示的な複合ケースです。数字は仕組みを明確にするために様式化されていますが、障害モードと修正の両方は一般的です。

50人のエンジニアを擁する組織が、すべてのプルリクエストで実行される3ステップのClaudeコードレビューエージェントを構築しました。(1)差分を要約する、(2)MCPドキュメントサーバーを介してセキュリティポリシーに対して差分をレビューする、(3)コード変更を提案する、というものです。合理的なアーキテクチャ、有用なワークフローであり、明らかな危険信号はありませんでした。このエージェントは9月上旬に本番稼働しました。

エンジニア1人あたり週に約15件のPRがあり、リトライと、プロンプトにファイル全体を挿入する際のコンテキストウィンドウコストを考慮すると、エージェントはPRあたり約40万入力トークンを平均しました。CI/CD自動化の初月請求額は8,400ドルでした。請求書は10月5日に届き、財務部門からのSlackメッセージは10月6日に届きました。この投稿につながる会話は10月7日に始まりました。

チームがコストダッシュボードにログインしてから数分以内に、アトリビューションが実際の原因を明らかにしました。ステップ2では、差分が実際にポリシー関連のコードに触れているかどうかにかかわらず、すべてのPRのすべてのプロンプトに50,000トークンのセキュリティマニュアルを挿入していたのです。モデルは、それを適用すべきかどうかを評価するためにマニュアル全体を読んでいましたが、80%の確率で「いいえ、これはCSSの変更です」という回答でした。しかし、コストは毎回支払われていました。ステップ2をゲートウェイの セマンティックキャッシュ （差分のファイル拡張子とコンテンツシグネチャに基づいてキー付けされたもの）を介してルーティングすることで、トークンのオーバーヘッドを92%削減しました。同じカバレッジ、同じ提案で、月額請求額は800ドル未満になりました。

アトリビューションがなければ、対応はCIワークフローでのSonnetの一括禁止だったでしょう。エンジニアリングは生産性の低下を受け入れ、財務部門は政治的な勝利を得たでしょうが、誰も実際の原因を知ることはなかったでしょう。アトリビューションがあれば、対応は1行の設定変更でした。それがデータがもたらす違いです。

これらをまとめる設定

2つのTrueFoundryポリシー設定が、このパターン全体の重みを担っています。監査モードとアラート付きでドル上限を強制する予算設定と、トークンとリクエストのクォータを強制するレート制限設定です。どちらも実際のスキーマであり、これらをAI Gatewayの ポリシー タブに直接コピーしてください。スキーマのリファレンスは、公式ドキュメントの 予算制限 と レート制限。これらをデプロイする前に、以下の2つの重要な点を理解しておいてください。

まず、 ルール順序と階層型トラッキングに関してです。TrueFoundryの予算に関するドキュメントによれば、リクエストが複数のルールに一致した場合、そのコストは すべて の一致するルールに対して追跡されますが、 最初 に一致するルールのみが許可/ブロックの決定を制御します。YAMLにおけるルールの順序が優先順位を決定し、個別の優先順位フィールドは存在しません。以下の設定例では、決済プラットフォームからのリクエストは、特定の payments-platform-weekly ルール（最初に一致し、ブロックの決定を制御）と、より広範な per-user-daily-default ルール（コストも追跡され、開発者ごとの利用状況を把握するのに役立ちます）の両方に一致します。これは意図的な設計であり、ダッシュボードでは、同じリクエストに対してコストセンターレベルとユーザーレベルの両方の使用状況が表示されます。

次に、 プロバイダーアカウントの命名に関してです。モデル識別子、例えば anthropic-main/claude-opus-4-7 は、次の形式に従います <provider-account-name>/<model-id>。ここで、プロバイダーアカウント名は、ワークスペース管理者がAnthropicアカウントを AI Gateway → Modelsで命名したものです。model-idの部分はAnthropicによって固定されています。コピー＆ペーストする前に、お使いのTrueFoundryインスタンスでプロバイダーアカウント名を確認してください。

予算設定 — コストセンターごとのドル建て強制適用、安全な展開のための監査モード付き：

name: cicd-budget-config
type: gateway-budget-config
rules:
  # Priority 1 (first in list = first match): payments-platform — higher cap
  - id: 'payments-platform-weekly'
    when:
      metadata:
        cost_center: 'eng-backend-payments'
    limit_to: 800
    unit: cost_per_week
    audit_mode: false        # enforce: block on exceed
    alerts:
      thresholds: [75, 90, 100]
      notification_target:
        - type: slack-bot
          notification_channel: 'eng-alerts-channel'
          channels: ['#eng-backend-ai']

  # Priority 2: data team — lighter cap, longer period
  - id: 'data-team-monthly'
    when:
      metadata:
        cost_center: 'eng-data'
    limit_to: 2000
    unit: cost_per_month
    audit_mode: false
    alerts:
      thresholds: [75, 90, 100]
      notification_target:
        - type: email
          notification_channel: 'data-alerts'
          to_emails: ['data-platform-lead@example.com']

  # Priority 3: intern sandbox — hard cap, no exceptions
  - id: 'intern-sandbox-weekly'
    when:
      metadata:
        cost_center: 'intern-sandbox'
    limit_to: 50
    unit: cost_per_week
    audit_mode: false
    alerts:
      thresholds: [100]
      notification_target:
        - type: slack-bot
          notification_channel: 'platform-alerts'
          channels: ['#platform-budgets']

  # Default per-user safety net — $20/day per individual developer.
  # Tracks against every request (layered), controls block only for requests
  # that don't match a higher-priority rule above.
  - id: 'per-user-daily-default'
    when: {}
    limit_to: 20
    unit: cost_per_day
    budget_applies_per: ['user']
    audit_mode: true         # audit-only during initial rollout
    alerts:
      thresholds: [90, 100]
      notification_target:
        - type: slack-bot
          notification_channel: 'platform-alerts'
          channels: ['#platform-budgets']

レート制限設定 — リクエストとトークンのクォータ、第二の防衛線：

name: cicd-ratelimiting-config
type: gateway-rate-limiting-config
rules:
  # Per-pipeline token ceiling: prevents runaway agents.
  # metadata.pipeline accesses the 'pipeline' field inside x-tfy-metadata JSON.
  - id: 'pipeline-hourly-token-cap'
    when: {}
    limit_to: 500000
    unit: tokens_per_hour
    rate_limit_applies_per: ['metadata.pipeline']

  # Per-user request floor: stops developer mistakes from going viral
  - id: 'per-user-daily-requests'
    when: {}
    limit_to: 5000
    unit: requests_per_day
    rate_limit_applies_per: ['user']

  # Premium-model brake: caps Opus consumption per cost center.
  # Replace 'anthropic-main' below with your workspace's Anthropic
  # provider-account name (see AI Gateway → Models in the dashboard).
  - id: 'opus-per-cost-center-daily'
    when:
      models: ['anthropic-main/claude-opus-4-7']
    limit_to: 200000
    unit: tokens_per_day
    rate_limit_applies_per: ['metadata.cost_center']

どちらの設定もバージョン管理されており、プルリクエストでレビューされ、プラットフォームチームがゲートウェイの他の部分で使用しているのと同じGitOpsフローを通じて適用されます。上記のスキーマは公式ドキュメントと完全に一致しており、すべてのフィールド、すべての値、すべての rate_limit_applies_per エントリは文書化され、サポートされています。ワークロードチームは、プルリクエストを通じて自身のコストセンターエントリへの変更を提案し、プラットフォームチームが承認すると、ゲートウェイは次回の調整ループでその変更を適用します。

デフォルトのユーザーごとのルールにおける audit_mode: true 設定は、特筆すべき安全機能です。展開中、監査モードにより、ルールは実際の支出を追跡し、トラフィックをブロックすることなくアラートを発することができます。1〜2週間の監視後、チームは audit_mode を false に変更して強制適用します。これは、本番環境レベルの予算強制適用システムへの最もリスクの低い経路です。まず監視し、次に強制適用し、実際のトラフィックが生成するのを見たことがない数値を強制適用することはありません。

マルチテナントのコスト帰属 — B2B SaaSの事例

すべてのコストセンターが1つの企業に属する単一組織のケースは簡単です。多くの本番AIデプロイメントはマルチテナントです。B2B SaaS製品は自社の顧客にAI機能を提供し、企業がどの顧客が収益性が高く、どの顧客が補助金を受けているかを知る前に、AIの請求をテナントごとに割り当てる必要があります。この問いに答えられるようにするのが、コスト帰属レイヤーです。

機能するパターンは、 tenant_id メタデータエンベロープの別のフィールドとして扱われます。予算編成のためのバケットキーは、 tenant_id とワークロードの組み合わせになります。ダッシュボードは、テナントごとのビューとコストセンターごとのビューをサポートし、FinOpsレポートはゲートウェイデータを会社の請求システムと結合し、テナントごとの粗利益を算出します。AI消費量がプランティアを超過したテナントは、カスタマーサクセスが対応に追われる前にダッシュボードに表示されます。

ティアに応じた予算上限が2番目のパターンです。フリーティアのテナントは、エンタープライズティアのテナントよりも厳しい上限が設定されます。上限はハードコードされるのではなく、テナントのプランから導き出されます。テナントがアップグレードすると、コード変更なしで上限が更新されます。プランはテナントIDのメタデータであり、上限はプランの関数だからです。上限をハードコードするチームは、料金が変更されるたびに書き換えが必要になりますが、テナントデータから上限を導き出すチームは、適切な動作を自動的に継承します。

3番目のパターンは、ティアごとの「機能は低下するが動作する」モードです。エンタープライズティアのテナントの制限モードでは、より厳格なレート制限のあるフロンティアモデルに留まる可能性があります。フリーティアのテナントの制限モードでは、セルフホストの小規模モデルにルーティングされる可能性があります。同じゲートウェイでも、異なるダウングレードチェーンが設定として表現されます。B2B SaaS企業の料金体系は、ゲートウェイ設定に直接反映されます。これこそが、そのあるべき場所です。

コスト配分におけるアンチパターン

コスト配分を初めて試みるチームでは、4つの設定ミスが頻繁に見られます。それぞれが異なる、知っておくべき障害モードを引き起こします。

オプションのタグ付け。 チームは、タグ付けされていないリクエストをログに記録するものの、後で強制適用するつもりで通過させるようにゲートウェイを設定します。しかし、「後で」は訪れず、ダッシュボードには「不明」バケットが月を追うごとに蓄積されていきます。強制適用が有効になる頃には、トラフィックの半分が「不明」バケットに入っており、それを修正することは政治的に高くつきます。解決策は、目に見えるトラフィックがまだ少ない2週目から拒否を強制することです。

余分なヘッダーの考案。 チームは、チーム、リポジトリ、コストセンターなど、複数のヘッダーにIDを分散させようとすることがあります。ゲートウェイは、この投稿で先に挙げた9つのカスタムヘッダーのみを正確に認識し、残りは黙って無視します。すべてのカスタムIDは、 x-tfy-metadataのJSON値内に含める必要があります。ヘッダーは1つ。その中にJSON。契約は文書化されており、ゲートウェイがそれを強制します。

複数のチームにまたがるコストセンター。 shared-infraのようなコストセンターは、 shared-infra は、クリーンな抽象化のように見えますが、予算を超過してもエンジニアリング上の責任の所在が不明確になります。つまり、連絡すべきチームが存在しません。コストセンターは、チームの責任範囲にマッピングされるべきです。共有作業は、曖昧な共有バケットではなく、プラットフォームチームが所有する「プラットフォーム」コストセンターに属するべきです。

詳細なエラーメッセージがないハードキャップ。 ボディが〜の429エラー {"error": "rate_limited"} 開発者にとって何の役にも立たない情報です。コストセンター、上限、主要なコンシューマー、およびクォータリクエストフローへのリンクを含む429エラーであれば、開発者は何をすべきか正確に理解できます。エラーボディのスキーマは、成熟したデプロイメントにおいて最も調整される設定の一部です。

パイプラインを中断させずにこれを展開する方法

コスト配分は、AIプラットフォーム分野において比較的安全な展開の一つです。なぜなら、「予算の誤設定」という失敗モードは限定的（一部のパイプラインが予期せず制限モードになる）であるのに対し、「配分なし」という失敗モードは壊滅的（制御不能な請求額）だからです。正しい手順は、まず観察し、次に強制することです。

1週目 — 監査モードでのタグ付け。 CIテンプレートを更新して、 x-tfy-metadata をすべてのリクエストに挿入します。ゲートウェイを設定し、タグ付けされていないリクエストを警告としてログに記録しつつ、それらを通過させます。週末のダッシュボードは、チームに支出の実態を伝えます。どのパイプラインが支配的か、どのコストセンターがヘビーユーザーか、ワークロードが実際にどのモデルを好むかなどです。これが予算調整の基礎となるデータです。

2週目 — タグ付けされていないリクエストを拒否。 ゲートウェイを切り替えて、タグ付けされていないリクエストに対して400を返すようにします。1週目に更新されたCIテンプレートのみが正当なクライアントであるため、400応答は、テンプレートが更新されていないか、対処が必要な帯域外の呼び出し元であることを示します。2週目の終わりまでに、本番環境のすべてのリクエストがタグ付けされます。

3〜4週目 — 監査モードでの予算設定。 予算設定を audit_mode: true をすべてのルールに適用して展開します。正当な支出の観測されたP95にマージンを加えた値に対して、ソフトなしきい値（75%）を設定します。アラートはチームのSlackチャンネルに発報されますが、まだ強制アクションはトリガーされません。チームはどのしきい値が妥当で、どれが調整を必要とするかを観察します。一部のワークロードは暴走しているように見えるでしょうが、実際に暴走しているのは1つか2つであり、チームは強制が始まる前に介入できます。

5週目 — 強制を有効化。 を audit_mode に false 予算ルールについて。90%ダウングレードチェーン（ペア仮想モデルフォールバック設定）と100%ハードキャップを有効にします。ダウングレードチェーンは、ワークロードオーナーにとってより議論の的となる変更点です。一部のチームは、パイプラインにおいて「機能低下しても動作する」よりも「即時失敗」を強く好みます。各チームが好みの動作を選択できるよう、このチェーンを最初からコストセンターごとに設定可能にします。

6週目以降 — 予測とレビューの頻度。 7日間のP95予測を有効にします。予算に対する予測の週次プラットフォームチームレビューを設定します。新しいコストセンターは、初期の使用状況に基づいて合理的な初期上限値がデフォルトで設定され、クォータの変更は設定に対するプルリクエストを通じて行われます。このシステムはプロジェクトとしてではなく、インフラとして稼働します。

コスト帰属に関する運用モデル

コスト帰属レイヤーは、生成されるデータが複数のステークホルダーに同時に影響するため、明確な所有権の境界が必要です。適切な役割分担は、プラットフォームチームがレイヤーを所有し、ワークロードチームが自身の予算を所有し、財務部門が戦略的視点を所有し、エンジニアリングリーダーシップがポリシーを所有することです。

プラットフォームチームは、ゲートウェイ、タグ付けの規律、予算エンジン、および予測を運用します。彼らはクォータ要求をレビューし承認し、ワークロードオーナーからの品質フィードバックに基づいてダウングレードチェーンを調整し、営業時間外に発生するアラートをトリアージします。彼らの仕事はシステムを稼働させることであり、各ワークロードにどれだけのコストがかかるべきかを決定することではありません。

ワークロードチームは、設定内の自身のコストセンターエントリを所有します。彼らはプルリクエストを通じて予算変更を提案し、ソフトアラートに達した際にパイプラインを調整し、ハードキャップ応答として「機能低下しても動作する」か「即時失敗」のいずれかの動作を選択します。プラットフォームチームが承認し、ワークロードチームが実行します。

財務部門とエンジニアリングリーダーシップは、集計ビューを利用します。月次決算会議では、集計された数値ではなく、特定のコストセンターと特定のパイプラインが引用されます。四半期計画では、予測を使用してAIインフラストラクチャの支出を予測し、予算サイクルは反応的ではなく予測可能になります。これにより、AI支出は繰り返し発生する予期せぬ出費ではなく、予算項目となります。

これはそうではないもの

強制的なタグ付けは、プロンプトエンジニアリングの代わりにはなりません。すべてのプロンプトに50,000トークンのマニュアルを挿入するワークロードは、どのワークロードが高価であるかをタグが正確に示してくれるでしょうが、それを修正する方法は教えてくれません。修正策（より小さなマニュアル、キャッシュ、より焦点を絞った検索、タスクにより適したモデルなど）は、帰属の後に続くエンジニアリング作業です。ダッシュボードは診断であり、修正は治療です。

階層型予算は、コスト管理を保証するものではありません。上限に達するたびに予算が増額されるチームは、最終的に「上限は存在しない」という結論に至ります。規律は技術的なメカニズムではなく、予算レビューの頻度にあります。すべてのクォータ要求を承認するプラットフォームチームは、予算が提供するはずだった影響力を失います。

そして、ゲートウェイでのコスト帰属は、すべての組織にとって適切な解決策ではありません。AI支出の総額が小さすぎて、エンジニアリング投資が節約額を上回るチームは、まず別の問題を解決すべきです。既存のFinOpsツールがクラウドプロバイダーデータからワークロードごとの帰属をすでに生成しているチームは、ゲートウェイに並行システムを必要としません。このパターンは、AI支出がその可視性よりも速く増加している組織に適しています。これは通常、プロバイダー支出が月額5,000ドルを超える場合で、1回の暴走インシデントのコストがレイヤー構築のコストを上回るような状況です。そのしきい値を下回る場合、TrueFoundryのような既製のゲートウェイであっても、その計算は常に成り立つとは限りません。そのようなチームは、支出を1つか2つの十分に監視されたアプリケーションに留め、成長によって必要性が生じたときにレイヤーを適用する方が良いでしょう。

よくある質問

予算はドル建てにすべきか、それともトークン建てにすべきか？

両方、同時に。ドルは財務および運用計画と整合します。トークンは、チームがプロンプトの効率をデバッグできるエンジニアリング指標です。トークン消費量が2倍になってもドルコストが横ばい（モデルが安くなったため）のワークロードは、財務部門が気づかなくてもエンジニアリングの観点から調査する価値があります。ゲートウェイは両方を追跡し、財務部門はドル建てダッシュボードを、エンジニアリング部門はトークン建てダッシュボードを所有し、ゲートウェイは両方にとっての信頼できる情報源となります。

パイプラインの途中でハードキャップに達した場合、どうなりますか？

パイプラインは、上記に示された説明的なエラー本文と予算ダッシュボードへのリンクを含む429エラーを受け取ります。CIランナーは429を標準的なバックオフシグナルとして解釈し、ビルドは混乱するようなクラッシュではなく、実行可能なメッセージとともにきれいに失敗します。クォータの増額は、エラー本文内のリンクを通じてプラットフォームチームに対する標準チケットとして提出されます。パイプラインの最後の成功したステップは保持され、クォータ増額後に再開しても、すでに支払われた作業がやり直されることはありません。

強制的なタグ付けはロールアウトを遅らせますか？

実際には、いいえ。TrueFoundryは、CIランナーがすでに設定している環境変数からメタデータエンベロープを自動的に挿入するSDKラッパーを提供しているため、個々の開発者がヘッダーを編集することはありません。一度限りのコストは、チームのパイプラインテンプレートを更新することであり、継続的なコストはゼロです。継続的なメリットは、それに続くすべてのダッシュボードです。

複数のリクエストにまたがる長時間実行ワークフローについてはどうですか？

安定した workflow_id フィールドを、 x-tfy-metadata JSON内で使用します。同じ論理ワークフローに属するすべてのリクエストに対して、同じ値を使用してください。ゲートウェイはリクエストを workflow_id ワークフローごとの予算適用のため、グループ化します。5ドルの上限があるワークフローは、数百のリクエストに及ぶことがあります。ゲートウェイは、個々のリクエストではなく、ワークフローの識別子に対して実行中の合計を追跡します。

ゲートウェイでの費用配分の精度はどの程度ですか？

入力および出力トークンコストについては、プロバイダーの請求書とほぼ1%以内で一致します。このわずかな差異は、丸め処理や、ゲートウェイがリクエスト時に把握できないプロバイダー側の追加料金（ボリュームディスカウント、地域差など）に起因します。ほとんどの計画目的において、ゲートウェイの数値は十分に正確です。会計レベルの照合には、プロバイダーの請求書が唯一の信頼できる情報源であり、ゲートウェイはワークロードごとの内訳を提供します。TrueFoundryの 費用追跡ドキュメント では、パブリック料金（プロバイダーが公開する料金）とプライベート料金（カスタム契約）の両方のモードについて説明しています。

あるチームの暴走が別のチームの予算に影響を与えるケースは、どのように対処しますか？

予算はコストセンターごとに設定されます。あるチームの暴走は、そのチーム自身の予算のみを消費します。ハードキャップにより、暴走が他のチームに影響を与える前に停止されます。レート制限設定におけるモデルレベルの上限ルール（ opus-per-cost-center-daily の例）は、複数のチームが同時に不正な動作をする場合や、配分自体が誤っている場合の最終手段です。これはコストセンターごとのレイヤーよりも上位で機能します。

1つのコストセンターにきれいに収まらないワークロードについてはどうですか？

チーム横断的な作業は一般的ではありませんが、実際に存在します。最もクリーンなパターンは、プラットフォームチームが所有する「共有イニシアチブ」コストセンターを定義し、ゲートウェイのREADMEに明示的なチャージバックルールを文書化することです。タグ付けは単一値のままであり、リクエストは実行時に正確に1つのコストセンターに属しますが、プラットフォームチームは、各請求期間の終わりに、 費用追跡ドキュメントに記載されているエクスポートされた費用データを通じて、参加チームに支出を記録することができます。

‍