Claude Code v2.1.88 以降のトークン爆発事件 "Tokenocalypse" を振り返る — FinOps 観点で防衛する 4 本柱

この記事の対象読者と得られること

対象読者	この記事で得られること
Claude Code のコストが急に跳ねた方	2026/3 末の Tokenocalypse の全貌と原因
チームで AI コーディングを使う方	版固定・モデルルーティング等の防衛策
FinOps 観点でコスト管理したい方	PR 単位のトークン計測と月次レポーティング

はじめに — 「いつも通り使っていたのに請求が 10 倍」

ある朝、社内 Slack に 1 通の投稿が流れてきました。

「先週と同じ作業量のはずなのに、Claude Code のトークン消費が 8 倍になっています。何か設定変えた人いますか」

心当たりはなく、いつもどおり claude コマンドを叩き、いつもどおりリファクタを回していただけでした。ところが Anthropic のダッシュボードを開くと、日次トークン消費のグラフがあからさまな段差を作って跳ねていたのです。

この現象は筆者のチームだけでなく、2026 年 3 月末から 4 月上旬にかけて世界中で同時多発的に報告されました。コミュニティでは後に "Tokenocalypse"（トーケノカリプス、トークンの黙示録）と呼ばれるようになります。本記事ではこの事件の時系列と原因、そして私たちが再発防止のために採った FinOps 的な 4 本柱の防衛策を、自分たちの失敗も含めて整理します。

筆者も完全に原因を把握しているわけではなく、公開情報とチーム内観測から再構成した内容です。断定的な書き方を避けつつ、同じ痛みを経験した方のデバッグ材料になれば幸いです。

本記事の数値・挙動は 2026 年 4 月時点の公開情報と筆者チームの観測に基づきます。Anthropic の仕様は頻繁に変更されるため、最新の状況は公式リリースノートとご自身のダッシュボードで確認してください。

1. 背景 — なぜ「同じ価格で同じ出力」が崩れたのか

Tokenocalypse を理解するためには、事件が起きる前の数か月間に業界で何が進行していたかを押さえておく必要があります。ここでは LLM 業界全体の潮流と Claude Code 自身のバージョン変遷という 2 つの軸で背景を整理します。

1.1 なぜトークンが爆発したのか

2026 年第 1 四半期、AI 基盤を支える GPU 市場は再び逼迫期に入りました。Scrum.org のレポートなどでも触れられている通り、推論向け専有容量を奪い合う動きが再燃し、データセンタ事業者のスポット調達価格が先に跳ねた、というのが筆者の理解です。具体的な単価上昇率については報告元によってばらつきがあるため本記事では固有の数値は示しませんが、2025 年末までは供給が緩やかに改善していた印象が一転し、2026 年 Q1 に再び GPU 供給逼迫とインフラコスト上昇が観測された、というのが大枠の構図です。

こうした外部コスト圧の中で、LLM ベンダー各社は一斉に FinOps 文脈のシフトを進めました。粗く言えば「計算資源をどれだけ安く提供するか」から、「顧客セグメントごとに単価と体験を再設計する」方向への舵取りです。Anthropic もこの流れの例外ではなく、表面的な価格改定を最小限に抑えつつ、内部トークンの計測精度を上げることで実質的な単価を正常化する判断をしたと読み取れます。

もう 1 つの要因が、third-party harness の流行です。SuperClaude や Cline をはじめとした外部ハーネスは、Claude Code の API 呼び出しに独自のプランニング層や自己ループを被せ、「少ない操作で多くのタスクを自動的に回す」ことを売りにしてきました。ユーザー側の利便性は高い一方、プロバイダから見ると「公式のレート制限や意図した呼び出し回数を逸脱する流量」が観測され続けた形です。Anthropic 側がこれを放置すると、本来の API 単価では採算が取れない領域が拡大し、結局は全ユーザーに価格転嫁するしかなくなります。

そして同時期に投入されたのが "Mythos Preview" と呼ばれる長文脈向けの新機能です。公式から「planner」として明確に位置付けられているかは未確認ですが、筆者の観測範囲では複雑なタスクで事前分解や自己批評に類する中間推論が差し込まれる挙動が増え、最終的な出力の品質を底上げしているように見えます。品質面の効果は確かに感じられるものの、その分だけ長いシステムプロンプトや中間推論が走るため、見かけの課金トークンは素直に増加する方向に働きます。

これら「GPU 供給逼迫によるインフラコスト上昇」「FinOps シフト」「ハーネス対策」「Mythos Preview 機能の追加によるオーバーヘッド」の 4 つが同じタイミングで走ったことで、長らく続いた「同じ価格で同じアウトプット」という前提が崩れたと筆者は捉えています。Tokenocalypse はその崩壊が一般ユーザーの請求書に現れた瞬間、と言い換えてもよさそうです。

1.2 v2.1.85〜v2.1.90 のバージョン変遷

もう少し解像度を上げるため、Claude Code 側のバージョンごとの変化を時系列で並べてみます。日付と数字は筆者チームでの観測と公開情報から再構成したもので、環境によっては体感が異なる可能性がある点にはご留意ください。

バージョン	リリース	体感コスト	主な変化
v2.1.85	2026/3/15	基準（1 セッション $0.50 前後）	安定。ほぼ従来どおりの挙動
v2.1.86	2026/3/20	+10% 程度	内部計測の軽微な調整が含まれたと見られる
v2.1.87	2026/3/27	特定タスクで +50% 報告	大規模リファクタ時に段差を観測する例が出始める
v2.1.88	2026/3/31	広範囲で 3〜50 倍	Mythos Preview と harness 対策が本格投入。Max 20x 70 分枯渇の報告多数
v2.1.89	2026/4/5	依然 +30% 程度	一部緩和パッチ。特定シナリオで改善
v2.1.90	2026/4/12	現在のベース	追加緩和。落ち着きつつあるが v2.1.87 以前には戻っていない

事件の時系列を mermaid でもう一度眺めてみます。

こうして並べ直すと、v2.1.88 は単発の事故ではなく、数週間かけて段階的に進行してきた変化の「ピーク」だったと捉えるのが妥当に思えます。v2.1.86〜v2.1.87 の時点で段差に気付けたチームは比較的被害が小さく済んだ一方、毎週の請求を月末に確認していたチームは v2.1.88 で初めて異常に気付いた、という差も生まれました。

筆者のチームでは、この経験から「バージョンアップの翌営業日に日次消費グラフを必ず確認する」運用に切り替えました。後段で紹介する防衛策も、このような時系列の肌感覚があって初めて意味を持つものだと感じています。

2. 事件の時系列 — 70 分で Max 20x が枯渇した日

2.1 v2.1.88 リリースと最初の違和感

発端は 2026 年 3 月下旬にリリースされた Claude Code v2.1.88 でした。リリースノート上は「内部プランナーの改善」「third-party harness 対策」「トークン計測の精緻化」といった一見地味な項目が並んでいます。ところがアップデート直後から、従来と同じような使い方で 1 セッションあたりのトークンが 3〜5 倍に増える現象が観測され始めました。

筆者のチームでは、ある日のログを見ると tokens_in の急増が顕著で、同じ規模のリファクタリングで前週の 4.2 倍消費していました。最初は「たまたま重いタスクが続いたのだろう」と受け流していたのですが、それが数日続いたあたりで「これは個別事象ではない」と気づきます。

2.2 「70 分で Max 20x プランが枯渇」投稿の衝撃

事件が一気に可視化されたのは、開発者コミュニティに「Claude Code Max 20x プランを 70 分で使い切った」という投稿が流れたことです。Max 20x は Anthropic の上位プランで、従来は 1 日を通して余裕のあるクォータとして知られていました。それが約 1 時間強で尽きるとなれば、料金プラン選定の前提が崩れます。

続いて DevOps.com が「Claude Code quota limits and usage problems」でクォータ枯渇の相談の急増を伝え、Scrum.org のブログ「No More Cheap Claude: Four First Principles of Token Economics 2026」が経済学的な背景を整理しました。この頃から「Tokenocalypse」の呼び名がじわじわと広まっていきます。

2.3 事件の全体像（mermaid 図）

ここまでの流れを整理すると次のようになります。

この時期、Slack の AI 系コミュニティでは「とりあえず @anthropic-ai/claude-code のバージョンを戻した」という投稿が多く見られました。根本対処ではないにせよ、それだけ影響が大きかったということだと理解しています。

3. なぜ跳ねたのか — 3 つの複合要因

Tokenocalypse は単一の原因では説明できず、複数の変更が同時に重なった結果だと見るのが妥当です。ここでは公開情報と観測から推定される 3 つの要因を整理します。あくまで推定であり、Anthropic 公式のポストモーテムではない点にご留意ください。

3.1 GPU 供給逼迫とインフラコスト上昇への対応

Scrum.org の記事などでも、推論向け GPU の実質単価の上昇が指摘されています。具体的な上昇率は情報源によってばらつきがあり本記事では固有の数値を示しませんが、推論基盤のコスト構造が上方向に動いていること自体はおおむね共通認識と見てよさそうです。推論基盤のコスト構造が変われば、当然ながらトークン単価や 1 リクエストあたりの内部コストにも反映されます。

Anthropic はユーザー向け価格表を直接大幅に上げる代わりに、「同じタスクを処理する過程で発生する内部トークン」を精緻に計測し直す方向に舵を切ったように見えます。つまり、以前は計測されていなかった内部処理のトークンが、可視分に含まれるようになった可能性があります。

この推定が正しいとすれば、「体感コストが 3〜5 倍になった」現象の多くは、新しく露出したコストだったと説明できます。ユーザーから見ると値上げですが、プロバイダから見ると正直化です。どちらの見方にも一理あると感じます。

3.2 third-party harness 対策

v2.1.88 のリリースノートにある「third-party harness 対策」も大きい要因です。Claude Code はもともと CLI としてローカルで動きますが、その上に独自のプランナーやループを被せて自動運用する "harness" が各社から提供されていました。Anthropic は API 利用規約上これらを歓迎しておらず、検出と抑制の仕組みを段階的に強化してきた経緯があります。

v2.1.88 では、ある種のループパターンに対して追加のガードが入り、その結果として正規のユーザーのプランナー動作まで重くなったケースがあるようです。筆者のチームでも、以前は 1 回で終わっていた内部ループが 2〜3 回回るようになり、そのたびにトークンが加算される挙動を観測しています。

third-party harness を完全に否定するのは本記事の意図ではありません。ただ、harness 経由で動かしていたワークフローが急に高コスト化した場合、v2.1.88 以降の抑制の影響を受けている可能性が高いです。素の Claude Code に戻せるかを一度検討する価値があります。

3.3 Mythos Preview 機能によるオーバーヘッド

もう 1 つの要因が "Mythos Preview" と呼ばれる長文脈向けの新機能の部分投入です。公式から「planner」として明確に位置付けられているかは未確認ですが、複雑なタスクに対して事前にタスク分解や自己批評に類する中間推論が走るような挙動が観測されており、最終出力の品質を底上げしている可能性があります。

品質面のメリットは確かにあるのですが、この機能が実行時負荷を押し上げている可能性があり、比較的長いシステムプロンプトや中間推論が消費されるため、1 タスクあたりの総トークンが増える方向に働きます。短く終わるはずの作業にまで走ると、割に合わないほど消費が膨らむことがあります。

このあたりは「機能としては正しいが、課金との相性が悪い」という典型例です。OFF にする手段が公式に提供されるのが理想ですが、現時点では「セッションの切り方」や「指示の出し方」で副次的にコントロールする運用が中心になっています。

4. 裏で動いていた Codex 側の同時期の動き

Tokenocalypse を考える上で見逃せないのが、競合にあたる OpenAI Codex 側の同時期の動きです。

• $100 プランの登場: Codex は 2026 年春に月額 100 ドル前後の上位プランを投入し、長時間・大規模なコーディングユースケースを明確にターゲットしました
• $20 プランの劣化: これと対をなすように、従来の $20 プランでは 1 日に使えるレートや並列度が絞られ、「気軽に常時使う」用途には厳しくなったという声が増えました

Anthropic と OpenAI の両方が、ほぼ同じタイミングで「重いコーディング用途は上位プランへ」「安いプランは節度ある使い方へ」という方向に舵を切った形です。GPU 単価の上昇という共通の制約がある以上、ある程度は仕方ない流れだと感じます。

一方で、ユーザーから見れば「AI コーディング全体が高くなった」という体験になり、FinOps 側で対策しなければプロジェクト単位の採算が成り立ちません。ここから先は、具体的な防衛策の話に移ります。

5. 防衛策 4 本柱

筆者のチームが Tokenocalypse を受けて整備した防衛策は、大きく 4 本柱に整理できます。どれか 1 つだけで解決するというより、組み合わせて少しずつ効かせるイメージです。

5.1 柱 (1) npm package の版固定

まず最優先で取り組んだのが、@anthropic-ai/claude-code のバージョン固定です。

事件発生直後の対症療法として、多くのチームが v2.1.87 以前に戻して急場をしのぎました。これ自体は根本対処ではありませんが、次に似たことが起きたときにワンアクションで戻せる状態を作っておくことには大きな価値があります。

package.json での固定例は次の通りです。

{
  "devDependencies": {
    "@anthropic-ai/claude-code": "2.1.87"
  }
}

キャレット (^) やチルダ (~) を付けずに固定することで、意図せずマイナーアップデートを踏むことを防ぎます。加えて package-lock.json もコミットし、CI で npm ci するようにします。

「LLM ツールは semver のように振る舞わない」というのが、今回の最大の学びです。マイナーバージョン相当の更新で課金構造が大きく変わることがあります。本体の挙動とプライシングは独立して動くため、バージョン番号だけ見て判断するのは危険です。

更新時には、ステージング用のプロジェクトで 1 日程度試し、トークン消費に段差が出ないことを確認してから本番に展開する運用にしました。地味ですが、これで少なくとも「知らないうちに爆発していた」状況は避けられます。

5.2 柱 (2) 2 試行ルール — 2 回失敗で Plan に戻る

2 つ目は運用ルールです。Claude Code に限らず、エージェント系ツールで最もコストがかさむのは「同じところを何度も試行錯誤するループ」です。

チームでは「2 試行ルール」を敷きました。同じ課題で 2 回連続でエラーや期待外れの結果が続いたら、そのセッションでの試行をいったん止めて、人間が Plan モード（もしくは別のセッション）で計画を立て直す、というものです。

[エラー 1 回目] -> 原因の仮説を立ててもう 1 回だけ試す
[エラー 2 回目] -> ここで止まる。セッションを抜けて計画を見直す

3 回目以降の挑戦は、だいたい問題の切り分けができていないまま続けていることが多く、得られる情報に対してトークン消費が合わないと筆者は感じています。厳密な根拠があるわけではないのですが、実運用上この閾値が一番しっくりきました。

5.3 柱 (3) モデルルーティング — Haiku 4.5 を review 役に

3 つ目は、作業工程ごとにモデルを使い分ける「モデルルーティング」です。

筆者のチームでは次のような分担にしました。

工程	モデル	狙い
設計・難所のコーディング	Claude Sonnet 4.5 系	品質を優先したい中核タスク
広範なファイル読解	Claude Sonnet 4.5 系	文脈把握にトークンを使っても妥当
単純なレビュー・要約	Claude Haiku 4.5 系	軽いタスクは安価なモデルで十分
テスト実行結果の整形	Claude Haiku 4.5 系	機械的な作業にはミニマム構成で

一見当たり前の分担ですが、Claude Code を 1 つのデフォルトモデルで使い倒している環境は案外多く、ここを見直すだけで全体のトークン消費が体感 2〜3 割下がることもあります。もちろんワークロードによるので、まずはダッシュボードを 1 週間眺めて、どの工程が重いかを把握してから切り替えるのが安全です。

5.4 柱 (4) 1 セッション 1 トピック

最後は、セッションの切り方に関するルールです。

Mindwired AI の記事「2 Claude Code habits that are wasting your tokens and how to fix them」でも触れられている通り、長すぎる 1 本のセッションは毎ターンで文脈を運び直すコストがばかになりません。

筆者のチームでは「1 セッション 1 トピック」をルール化し、機能 A と機能 B を同じセッションで扱わないようにしました。作業の切り替え時には一度セッションを閉じ、新しいセッションで改めて必要最小限のコンテキスト（対象ファイルのパスや設計意図のサマリ）だけを渡します。

ただし「短いセッションを大量に立ち上げる」のもそれはそれでオーバーヘッドがあります。1 セッションの長さは、だいたい 30〜60 分で終わるタスク 1 件を 1 単位にする感覚が筆者のチームにはフィットしました。環境やタスクによるので、チームごとに調整してください。

6. 文化づくり — PR あたりトークン消費を「見える化」する

防衛策を個人のスキルに留めるとチームとしては弱いので、文化として定着させる仕組みも整えました。

6.1 PR ごとにトークン消費をコメントする運用

Pull Request を出すタイミングで、そのブランチ作業中に使った Claude Code のトークン消費サマリを PR コメントに貼る、という運用を始めました。完璧な計測は難しいのですが、セッション ID 単位のトークン合計を取り出し、PR 単位に雑に集約するだけでも「重い PR / 軽い PR」の傾向が見えてきます。

コメント例はこんなイメージです。

Claude Code token usage for this branch:
- Total input tokens: 182,430
- Total output tokens: 41,202
- Approximate cost (Sonnet 4.5): $1.94
- Sessions: 3
Notes:
- Large file read in session #2 dominated input tokens
- Consider splitting into review-only session next time

この運用を始めて気づいたのは、レビュアがコメントを見て「このくらいの変更なら半分くらいのコストで済みそうですね」とフィードバックをくれるようになったことです。コストをコードレビューの題材にできるようになったのは、想定外の副次効果でした。

6.2 月次トークンレポート

もう 1 つは月次レポートです。プロジェクトごとの Claude Code 消費を集計し、前月比と要因分析を A4 1 枚にまとめています。内容はざっくり以下の通りです。

1. 月次の総トークン数と概算コスト
2. プロジェクト別の消費トップ 5
3. 前月比で顕著に増減したプロジェクトの解説
4. モデル別（Sonnet / Haiku）消費比率
5. 次月の改善アクション 1〜2 件

このレポートを経営側と共有することで、「AI コーディングはコスト面でも説明可能」という安心感を作れています。数字の裏付けがあると、投資判断もしやすくなると感じています。

7. コスト監視コード例 — Anthropic Usage API を叩く

参考までに、筆者のチームで使っている簡易的なトークン使用量取得スクリプトを共有します。実際の運用では CI から日次で呼び出し、前日分のサマリを Slack に流しています。エンドポイントやパラメータは時期により変わる可能性があるため、必ず最新のドキュメントで確認してから使ってください。

7.1 Python 版（月次レポート用）

# anthropic==0.39.0 系を想定
import os
from datetime import date, timedelta

import httpx


API_KEY = os.environ["ANTHROPIC_ADMIN_KEY"]
BASE_URL = "https://api.anthropic.com/v1"


def fetch_daily_usage(target: date) -> dict:
    """指定日の Claude Code 利用量を取得する。"""
    start = target.isoformat()
    end = (target + timedelta(days=1)).isoformat()

    headers = {
        "x-api-key": API_KEY,
        "anthropic-version": "2026-04-01",
    }
    params = {
        "starting_at": start,
        "ending_at": end,
        "product": "claude_code",
    }
    resp = httpx.get(
        f"{BASE_URL}/organizations/usage_report",
        headers=headers,
        params=params,
        timeout=30.0,
    )
    resp.raise_for_status()
    return resp.json()


def summarize(report: dict) -> None:
    total_in = sum(item["input_tokens"] for item in report["data"])
    total_out = sum(item["output_tokens"] for item in report["data"])
    print(f"input:  {total_in:,}")
    print(f"output: {total_out:,}")


if __name__ == "__main__":
    yesterday = date.today() - timedelta(days=1)
    summarize(fetch_daily_usage(yesterday))

7.2 Bash 版（当日分の軽いチェック）

CI に組み込まない、手元での軽いチェック向けには Bash でも十分です。

#!/usr/bin/env bash
set -euo pipefail

today=$(date -u +%Y-%m-%d)
tomorrow=$(date -u -v+1d +%Y-%m-%d)

curl -sS \
  -H "x-api-key: ${ANTHROPIC_ADMIN_KEY}" \
  -H "anthropic-version: 2026-04-01" \
  "https://api.anthropic.com/v1/organizations/usage_report?starting_at=${today}&ending_at=${tomorrow}&product=claude_code" \
  | jq '{
      input:  ([.data[].input_tokens]  | add),
      output: ([.data[].output_tokens] | add)
    }'

ここで使うキーは通常の API キーではなく、組織の Admin 権限を持つキーです。取り扱いには十分に注意し、CI のシークレット機能などを使って安全に管理してください。本記事中のスクリプトやパス名はサンプル用に匿名化した例で、実環境の名称は含めていません。

8. 防衛策の比較 — pin / 最新追従 / Haiku ルーティング / 他ツール併用

ここまで 4 本柱と見える化の仕組みを紹介してきましたが、実際には「どの策にどれだけ比重を置くか」がチームごとに異なります。筆者の周囲で観測した典型的な 4 パターンを整理し、比較表と判断マトリクスの形でまとめます。あくまで一例で、正解は現場の制約によって変わる点を先に書き添えておきます。

8.1 防衛策 4 パターンの比較

軸	pin @2.1.87	最新追従	Haiku ルーティング	他ツール併用（Codex 等）
実コスト	基準	+3〜50 倍	-40% 前後	-30% 前後
新機能恩恵	×	○	○	限定的
保守負荷	低	中	中	高
切替耐性	弱（deprecation が来る）	強	強	弱
月額想定	$20 前後	$100+	$30 前後	$40 前後（両方 Pro）

数字は筆者のチームと周囲のチームの観測から丸めた目安で、ワークロードによって大きく変わります。特に「実コスト」はタスクの性質と 1 セッションあたりの文脈サイズで 2 倍以上ぶれるので、参考値として捉えてください。

pin は「v2.1.87 に固定して嵐をやり過ごす」方針です。一時的に請求を抑える効果が非常に強い一方、Anthropic 側の deprecation が来れば強制的に外される性質があります。最新追従は「新機能を取りにいく代わりに、課金もそのまま受け入れる」方針で、エンタープライズで自動化が高度に進んでいるチームでは選ばれやすい選択肢です。

Haiku ルーティングは 4 本柱の柱 (3) を中核に据えた戦略で、モデル選択を工程ごとに自動化できる運用力があるチームに向きます。他ツール併用は Codex など別ベンダーのコーディングツールと Claude Code を使い分ける方針で、ベンダー集中リスクを下げられる反面、2 本立ての学習・運用コストがのしかかります。

8.2 どの策を選ぶか

上記はあくまで軸ごとの比較で、実際の判断は「どのチームが」「何を守りたいか」で変わります。筆者が聞いた範囲で整理した簡易マトリクスを載せます。

• pin @2.1.87 が合う: 直近 1〜2 か月の請求が痛い、機能追随より安定運用を優先したい、コストを確実に元の水準に戻したい
• 最新追従が合う: 予算が確保されている、新機能を早く取り込んでプロダクト差別化につなげたい、CI と自動化が成熟していて消費が予測しやすい
• Haiku ルーティングが合う: モデル選択を自動化できるだけの運用基盤がある、レビュー系の軽タスクが多い、Sonnet と Haiku の品質差を許容できる
• 他ツール併用が合う: 特定ベンダーへの依存を下げたい、Codex などに知見があるメンバーがいる、リスク分散を経営レベルで要求されている

これらは排他ではなく、「pin しつつ Haiku ルーティングも入れる」「最新追従にしつつ他ツール併用で分散する」といった組み合わせも現実的です。筆者のチームでは、直近は pin と Haiku ルーティングを併用しつつ、ステージング環境だけ最新追従で挙動を追う形に落ち着いています。

8.3 時間稼ぎと根本解決

ここで注意したいのが、どの策も「完全な解決」にはならないということです。

pin は本質的には時間稼ぎです。v2.1.87 も永遠に使えるわけではなく、どこかのタイミングで deprecation が宣告されるはずです。その日が来る前に、最新系で運用できる体制に移行する準備を並行して進めておく必要があります。筆者のチームでは「pin は最大 3 か月」と期限を区切り、その間に Haiku ルーティングを整える方針で動いています。

Haiku ルーティングも万能ではありません。Haiku 系のレビュー品質は Sonnet 系に比べると一段落ちる場面があり、特に複雑な設計レビューや仕様の整合性チェックでは見落としが発生しやすいです。ルーティングを入れたら、スポットチェックとして Sonnet でも同じレビューを回して差分を確認する運用を併用したほうが安心だと感じています。

他ツール併用は、管理コストと学習コストの増加という副作用が無視できません。2 つのツールで同じタスクを回すと、ログの集約、PR コメントの書式、モデル選択のルールがそれぞれ分岐します。採算が合うのは、チームに十分な余裕があるか、ベンダー分散を経営要件として突きつけられている場合に限られると感じます。

そして、どの策を選んでも「完全に請求を元に戻す」選択肢は存在しないという点は腹をくくるしかありません。GPU 供給逼迫によるインフラコスト上昇が報告されている以上、ベンダー側のコスト構造も動いています。私たちができるのは「新しい価格構造の中でいかに無駄を削るか」に集中することで、それこそが FinOps 観点で本質的な取り組みだと捉えています。

9. まとめ — LLM バージョンは semver ではない

Tokenocalypse の経験から筆者が得た最大の学びは、「LLM を内包したツールにおいて、バージョン番号は semver のようには振る舞わない」という事実でした。v2.1.88 という、見た目はマイナーパッチのリリースが、実際には料金構造を動かすほどの変更を含んでいました。

だからといって Anthropic を一方的に責めるつもりはありません。GPU 単価の上昇、third-party harness の増加、品質面での要求の高度化など、プロバイダ側にも相応の事情があります。重要なのは、利用側である私たちが「マイナーアップデートで挙動と課金が変わり得る」という前提で運用を設計することだと感じています。

最後に、本記事の 4 本柱を改めて振り返ります。

1. npm package の版固定 — いつでもロールバックできる状態をコミットで固定する
2. 2 試行ルール — 無限ループに陥る前に人間が計画を立て直す
3. モデルルーティング — Haiku 4.5 をレビュー役に回して工程ごとに使い分ける
4. 1 セッション 1 トピック — 長すぎるセッションは文脈運搬コストが効いてくる

加えて、PR あたりのトークン消費コメントや月次レポートといった「見える化」を組み合わせることで、チーム全体で AI コーディングのコストを制御しやすくなります。

Tokenocalypse は一度きりの事件では終わらないかもしれません。次に似たことが起きたとき、請求書に殴られてから気付くのではなく、ダッシュボードの段差に気付いて数時間で対処できる体制を作っておく。それが FinOps 観点での、最も現実的な備えだと考えています。

参考リンク

• Claude Code quota limits and usage problems（DevOps.com）
• No More Cheap Claude: Four First Principles of Token Economics 2026（Scrum.org）
• 2 Claude Code habits that are wasting your tokens and how to fix them（Mindwired AI）
• Anthropic Pricing（公式プラン・価格表）
• Anthropic API: Usage Reporting（公式ドキュメント）
• NVIDIA H200 Tensor Core GPU 製品ページ
• OpenAI Codex CLI 公式リポジトリ
• SuperClaude Framework（third-party harness の例）
• Cline（third-party harness の例）