Cost runaway ─ alert ではなく kill switch

ch3 の Drift は静かに進む。Cost runaway は爆発的に進む。出社して気づいた時には $47,000 が焼かれている、というのが運用工学の最大の悪夢だ。本章では、コストを「alert ではなく enforcement で止める」設計を扱う。

2 つの暴走事例

事例 1：$47,000 multi-agent 11 日ループ（2025-11、market research pipeline）

4 エージェント構成（LangChain + A2A）のうち、**Analyzer と Verifier の 2 体が「お互いの出力待ち」**のハンドシェイク無限ループに陥った。11 日間（264 時間）、人間に気づかれずにloop を続け、$47,000 のトークンを焼いた。budget ceiling が無く、alert は出ていたが kill switch がなかった（Tech Startups 2025-11-14）。

何が起きたか：

• Agent A が Agent B の出力を待つ
• Agent B が Agent A の出力を待つ
• 各 agent は「相手が応答するまで」polling し続ける
• alert は鳴っていたが、メールに埋もれて見逃された
• 「異常」と認定する基準も、止める権限もなかった

事例 2：retry ループでの数百ドル級事故（業界で複数報告）

document summarize agent が深夜に retry loop に入り、朝まで同じツールを数千回呼び続けた。1 日で数百ドル分のトークンを焼く類似事例は、業界の複数 blog で報告されている [要検証 個別の「$437」を含む特定事例の一次ソースは再特定できなかった]。

何が起きるか（典型シナリオ）：

• MCP server が一時的にダウンした
• agent は retry policy に従って再試行
• ダウンが回復しなかったため、retry が指数バックオフで続いた
• 数時間 × 数千回 = 数万〜数十万トークン × 高単価モデル

これらの共通点：alert はあったが enforcement がなかった。$47,000 暴走は実在事例（Tech Startups 報道、2025-11）、$437 級は業界横断で類似報告が複数あるが個別事例の一次出典は要確認。

原則 1：Hard cap from Day 1

ch2 で示した原則を再掲する。エージェント運用では、Day 1 から hard cap（強制停止）を入れる。

Hard cap	役割	推奨初期値
Per-task cost cap	1 タスク $X を超えたら kill	$1〜$5（タスク性質次第）
Step counter cap	N step を超えたら停止	30〜100 step
Token budget cap	セッション K tokens で停止	100K〜500K
Round-trip count cap	同じ tool を K 回連続呼んだら停止	5 回
Wall-clock cap	T 時間を超えたら停止	タスク性質次第（30 分〜数時間）

これらの cap はコードで強制する。alert ではない。

# ✅ 良い例：per-task cost を hard cap として実装
class CostGuard:
    def __init__(self, task_id, max_cost_usd):
        self.task_id = task_id
        self.max_cost_usd = max_cost_usd
        self.accumulated_cost = 0.0

    def record_call(self, input_tokens, output_tokens, model):
        cost = compute_cost(input_tokens, output_tokens, model)
        self.accumulated_cost += cost
        if self.accumulated_cost > self.max_cost_usd:
            # ⛔ 即時停止
            raise CostBudgetExceeded(
                f"Task {self.task_id} exceeded ${self.max_cost_usd}"
            )

# 使い方
with CostGuard(task_id="t-123", max_cost_usd=5.0) as guard:
    while not done:
        response = client.messages.create(...)
        guard.record_call(...)  # 超過したら raise

**Portal26 Agentic Token Controls（2026-04 ローンチ）**は、この発想をプラットフォームレベルで提供する：cap に達したら throttle、突破したら kill。

原則 2：85/10/5 split のモデルルーティング

「budget / balanced / frontier」三段階の tiered router は、2026 のコスト運用の標準パターン。

graph TB
    Q[Query]
    R[Router]
    B[Budget tier<br/>85% of queries<br/>Haiku / GPT-4o-mini]
    M[Balanced tier<br/>10% of queries<br/>Sonnet / GPT-5]
    F[Frontier tier<br/>5% of queries<br/>Opus / GPT-5.5]

    Q --> R
    R -->|simple| B
    R -->|complex| M
    R -->|critical| F

実装の選択肢

製品	特徴
vLLM Semantic Router（v0.2 Athena, 2026-03）	Envoy External Processor、BERT-based / decoder-only LoRA classification + prompt guard + semantic caching
Bifrost（OSS, maximhq）	5,000 RPS で per request 11μs overhead。20+ providers を OpenAI 互換 API
OpenRouter	SaaS、複数プロバイダの統合
Helicone gateway	OSS + SaaS、metadata 付き観測

ベンチマーク値：RouteLLM 論文（ICLR 2025, arXiv:2406.18665）で MT-Bench 85% / MMLU 45% / GSM8K 35% コスト削減、95% GPT-4 品質維持。production だと 30-60% 削減が現実的レンジ（85% はベンチ値）。

「85/10/5 split で 92% 削減」は出典が再特定できず[要検証]、Vantage 公開コンテンツに該当数字なし。RouteLLM の 85% を出典として使い、92% は孫引きの可能性が高いため使用を避けるのが安全。

原則 3：Prompt cache を最大限活用する

第1部 ch9 でも触れたが、cache の運用詳細を本章で深掘りする。

Anthropic prompt cache（2026-05 仕様）

項目	5 分 TTL	1 時間 TTL
Cache write 価格	base × 1.25	base × 2.0
Cache read 価格	base × 0.1	base × 0.1
Opus 4.7 / 4.6 例	$5 → $6.25 (write), $0.50 (read)	$5 → $10 (write), $0.50 (read)

• 対応モデル：Opus 4.7, 4.6, 4.5, 4.1, 4 / Sonnet 4.6, 4.5, 4 / Haiku 4.5, 3.5
• breakpoint：1 リクエスト当たり最大 4 個
• 最小キャッシュ可能トークン：Opus 4.7/4.6 は 4,096、Sonnet 4.6 は 2,048
• 2026/02/05 から workspace 単位の isolation（従来は org 単位）

2026/03 の silent regression を踏まえた運用

✅ 1 時間 TTL を使うなら、必ず明示
─────────
client.messages.create(
    ...,
    system=[
        {
            "type": "text",
            "text": static_system_prompt,
            "cache_control": {"type": "ephemeral", "ttl": "1h"}  # ← 明示
        }
    ]
)

長セッションで 1 時間 TTL を使わないと、25.9% のコスト増を直撃する（GitHub issue #46829 の解析）。

Cache hit 率を上げる prompt 設計

1. 静的コンテンツ（system / tools / context）を先頭に
2. 多 turn 会話は automatic caching に任せる
3. 変動する block（timestamp 等）に cache_control を打たない
4. minimum threshold を超える長さに揃える
5. Pre-warming（max_tokens=0）で開店前にキャッシュを温める

OpenAI / Gemini の prompt cache

• OpenAI：1024 tokens 以上で自動有効、cached input は 50% 引き、Mini/Nano では 90% 引き。デフォルト 5-10 分（最大 1 時間）、Extended Cache Retention で最大 24 時間
• Gemini：2.5 系で 90% 引き、2.0 系で 75% 引き。Pro モデルは $4.50 / 1M tokens / hour、Flash で $1.00

原則 4：Batch API で 50% 引き

リアルタイム性が要らないバッチ処理は Batch API で 50% 引きになる。

プロバイダ	仕様
Anthropic Message Batches API	50% off、24h SLA、100K requests / 256MB / batch、結果 29 日保持
OpenAI Batch API	50% off、24h ターンアラウンド、50K requests / 200MB

Anthropic Opus 4.6 / Sonnet 4.6 では output-300k-2026-03-24 ベータヘッダで 300K output tokens / request が解禁され、長尺出力に刺さる。

運用パターン：夜間バッチ + 日中リアルタイム

graph TB
    subgraph Night["夜間 (Batch API, 50% 引き)"]
        B1[ドキュメント要約]
        B2[埋め込み生成]
        B3[週次レポート]
    end

    subgraph Day["日中 (Cached + Real-time)"]
        D1[ユーザー対話]
        D2[即応 Q&A]
    end

    Night -->|事前計算結果| Day

「夜間バッチで埋め込み・要約・データ enrichment、日中はキャッシュ前提のリアルタイム agent」が production パターン。

原則 5：長コンテキスト課金の罠

第1部 ch5 でも触れたが、コスト運用の観点で再整理。

プロバイダ	閾値	罠
Claude Opus / Sonnet 4.6	1M context が flat rate（Opus $5/$25, Sonnet $3/$15 per M tokens）	罠なし
GPT-5.4	272K で価格 tier 切替	input $2.50 → $5.00（2×）、output $15 → $22.50（1.5×）、閾値超過時はセッション全体に新レート適用
Gemini 3.1 Pro	200K 超で長コンテキストレート	input $4 / output $18（202K 以上）

注意：GPT-5.4 で「272K を一度でも超えたら、その後のセッション全体が高額レート」になる。これが silent な cost runaway の典型例。

RAG vs 長コンテキストの判断基準

判断基準：
  corpus が静的 & 100 docs 未満 & 100K tokens 未満 & 30-60s 待てる → 長コンテキスト
  それ以外 → RAG / hybrid

数字：
  1M context は RAG 比 約 1,250 倍コスト・30-60 倍 latency
  Gemini 1.5 Pro の haystack recall 99.7% は単一 fact、multi-fact では 60% に落ちる
  Claude 1M で 90% retrieval 精度（1/10 が外れる）

「長コンテキスト万能」と思い込むと、コストが破裂する。

原則 6：観測は per-feature attribution

第1部 ch9 で触れた 「tokens per feature」 は、運用フェーズで真価を発揮する。

✅ Cost observability の設定
─────────
- Helicone：custom metadata で feature・environment・user 単位で aggregate
- Langfuse：trace 単位で user_id / session_id / tags
- Datadog LLM Obs + CCM：organization → project → model → 個別 LLM call の granularity

✅ 週次レビュー
─────────
- 機能別コスト推移（先週比、先月比）
- 異常値（前週比 +50% など）の調査
- Drift / runaway の早期警告

6 原則を統合した kill switch

これらを統合すると、5 段の防衛線になる。

graph TB
    Q[Task Start]
    L1[Layer 1: Routing<br/>85/10/5 split]
    L2[Layer 2: Cache<br/>1h TTL 明示]
    L3[Layer 3: Step counter cap]
    L4[Layer 4: Per-task cost cap]
    L5[Layer 5: Wall-clock cap]
    Done[Task Complete or Killed]

    Q --> L1 --> L2 --> L3 --> L4 --> L5 --> Done
    L3 -.超過.-> Kill[Kill agent]
    L4 -.超過.-> Kill
    L5 -.超過.-> Kill

5 つすべてを通過してタスクが完了する設計なら、$47,000 暴走は起きない。

❌ アンチパターン：alert はあるが kill switch がない

症状
─────────
- alert は鳴っているが、人が見ていない / メールに埋もれる
- 出社したら $X,000 焼けていた
- 「異常」と認定する基準が曖昧で、止める権限が誰にもない

根本原因
─────────
- Hard cap が実装されていない（コードレベルで kill されない）
- alert を止めるアクションが「人間の判断」に依存
- on-call ローテーションが組まれていない

脱出法
─────────
1. Per-task / token / step / wall-clock の hard cap を Day 1 で実装
2. cap 超過は raise → プロセス終了の自動化
3. on-call へのアラートを多重化（Slack + PagerDuty + SMS）
4. Portal26 のような専用ツールで cap を強制

業務投入の観点で重要な 3 点

1. alert ではなく enforcement：$47,000 / $437 事件は alert はあったが kill switch がなかった。Hard cap from Day 1 が原則
2. 85/10/5 split + cache + batch の組み合わせで 30-60% 削減が現実値：「85% / 92% 削減」はベンチ値、production はもっと控えめに見積もる
3. 「default TTL は 5 分」前提で設計せよ：Anthropic の 2026-03 silent regression を踏まえ、1 時間使うなら必ず ttl: "1h" を明示

次章への接続

ch5 では、長期メモリを持つエージェント特有の Memory poisoningを扱う。Microsoft が観測した 50 件のキャンペーン、Manus の sibling task 漏れ、AutoDream / FadeMem の 3 戦略（温存・浄化・隔離）を実装の解像度で扱う。

---

この章のまとめ

• $47,000 / $437 暴走は alert ではなく enforcement で防ぐ：Hard cap from Day 1
• 6 原則：Hard cap / 85-10-5 split / Cache 運用 / Batch API / 長コンテキスト罠 / per-feature attribution
• 5 つの hard cap：per-task cost / step counter / token budget / round-trip count / wall-clock
• 85% は benchmark、production は 30-60%：「92% 削減」のような数字は二次ソース要検証
• Cache TTL は明示指定：default に依存しない（2026-03 の silent regression が教訓）

＋ － ⟳ ✕