Claude Code料金は異常に安い｜値上げ前にトークンを測る

Q: チームで備えるなら、何から手を付けるべきですか

まずメンバー全員の cli と sdk-cli の比率を集めてください。組織の総使用量ではなく、この比率が意思決定に必要な数字です。次に、CI やバッチで走らせている自動化を洗い出して、1回あたりのトークン量を記録します。座席課金の値上げは人数で頭打ちになりますが、自動化側の従量課金には人数の上限がありません。備えるべき優先度は後者のほうが高いと考えています。

2026年6月15日、Anthropic は Claude のサブスクリプションの使用枠を2つに分ける変更を予定していました。そしてその施行当日に、変更を止めました。撤回ではなく一時停止で、2026年8月2日現在も止まったままです。

この話はニュースとしてはもう一巡しました。ただ、私が気になっているのはその先です。「いつ来るのか」を当てにいっても仕方がない。もっと実務的な問いは、来たときに自分の使用のどれだけが有料側に落ちるのか、という話ではないでしょうか。

そして、この問いには今すぐ答えが出せそうな気がしてきました。Claude Code は自分のログに、どちら側の使い方をしたのかをずっと記録しているからです。実際に自分のログを全部走査してみたところ、entrypoint というフィールドに cli と sdk-cli の2値が入っていて、これが Anthropic の分けようとした境界とそのまま対応していました。日本語でも英語でも、この点に触れている記事を私は見つけられていません。

この記事では、その測り方をコピペで動く形で出します。あわせて、私が10ヶ月ぶん取り続けた実測データ（累計 $19,657 相当、2026年7月の単月で $12,998 相当を月 $200 のプランで使用）を材料に、その倍率をどこが作っているのかを単価表から分解します。最後に、値上げ幅と人数と利用強度から3年後を試算する式を置きます。

先に結論の一部を言ってしまうと、座席あたりの値上げでは人件費には届きません。私の試算では23倍必要でした。本当に効いてくるのはそこではなく、人数という上限を持たない自動化側の従量課金のほうです。

6月15日に何が起きたのか、そして問いを立て直す
分け目は「何をしたか」ではなく「どう呼び出したか」
自分の使用を切り分ける手順
0で,998を使えた10ヶ月の実測
倍率を作っているのはキャッシュです
3年後を試算する
逃げ道を用意しておく
今週やる5つのこと
よくある質問
調査手法について

6月15日に何が起きたのか、そして問いを立て直す

先に事実関係を短く押さえます。2026年5月に告知された Agent SDK のクレジット分離は、6月15日の施行当日に一時停止となり、2026年8月2日現在も再開されていません。Anthropic は撤回とは言っておらず、時期も明示していません。

なお Agent SDK（Agent Software Development Kit）というのは、Claude を自分のプログラムから呼び出して自動で動かすための開発キットのことです。人が画面に向かって対話するのではなく、プログラムが勝手に Claude を働かせる。この記事では何度も出てくるので、ここだけ覚えておいてください。

Anthropic は2026年5月、6月15日から Claude Agent SDK 経由の使用をサブスクの枠から切り離し、別建ての月額クレジットにすると告知しました。ところが施行当日、購読者にメールを出して停止を伝えます。公式ヘルプも書き換えられ、いまも冒頭にこう書かれています（Anthropic ヘルプセンター）。

6月15日更新: 以下で説明する Claude Agent SDK の使用方法の変更を一時停止しています。現在のところ、何も変わっていません。

同じ告知は、再開の意思もはっきり残しています。「Claude サブスクリプションでのユーザーの構築方法をより適切にサポートするようにプランを更新するために取り組んでいます」と書かれていて、時期の明言はありません。撤回ではなく保留、というのが正確な読み方です。

背景も一貫しています。Claude Code の責任者である Boris Cherny は、4月にサードパーティツールへの制限を発表した際、サブスクリプションは「こうしたサードパーティツールの利用パターンを想定して作られていない」と述べていました（The New Stack）。定額制と、際限なく走るエージェントの相性が悪いことを、作っている側が認めた発言です。

同じ6月、GitHub は Copilot の定額プレミアムリクエスト方式を廃止してトークン課金へ移りました。トークンというのは、AIが文章を読み書きするときの最小単位で、水道でいうリットルにあたるものです。定額の使い放題をやめて、使った量で測る方式に変えた、ということですね。こちらは苦情が出ながらも予定通り実行されています。

さらに同じ週、Max プランの実際のレート制限が広告水準を大きく下回るとして、集団訴訟も提起されました（CNET）。使い放題に見える売り方そのものが、法的にも問われ始めています。

ここまでが事実です。ここから先の「だから業界の方向は一貫している」という論は、正直もう十分に語られたと思います。私が続けたいのは別の話です。

方向が一貫しているなら、当てにいくべきは時期ではありません。仮に明日その変更が入ったとして、自分の請求書のどこが動くのでしょうか。動くのが3%なら様子見でいいし、60%ならいま設計を変えたほうがいい。判断が変わるのはそこです。そして幸いなことに、この数字は予測ではなく計測で出ます。

分け目は「何をしたか」ではなく「どう呼び出したか」

止まった変更の中身を、設計として見ておきます。ここが分かると、測るべきものがはっきりします。

おさいふが2つになる想定でした。片方はこれまで通りのサブスク枠、もう片方は Agent SDK 専用の月額クレジットです。

おさいふ	何が入るか	課金のされ方
おさいふ1（対話）	ターミナルやIDEでの Claude Code、Web・デスクトップ・モバイルの Claude、Claude Cowork	従来のサブスク使用枠
おさいふ2（Agent SDK）	自分のプロジェクトで使う Agent SDK、`claude -p`（非対話モード）、Claude Code の GitHub Actions 統合、Agent SDK 経由で認証するサードパーティアプリ	月額クレジット。使い切ると標準API料金へ

月額クレジットの額は、Pro が $20、Max 5x が $100、Max 20x が $200、Team の標準シートが $20、プレミアムシートが $100、Enterprise のシートベースのプレミアムシートが $200 と決まっていました。繰越はなく、毎月リセットされます。ユーザーごとの割り当てなので、チーム内でプールすることもできません。

ここで注目したいのは、分類の基準です。

やっている作業の中身では分かれていません。同じリポジトリで同じリファクタリングをしても、ターミナルで対話しながらやればおさいふ1、claude -p で流せばおさいふ2です。The New Stack はこの点を、Zed の事例で端的に書いていました。Zed の中でも、Agent SDK 経由ではなく Claude の公式CLIをターミナルで直接動かしていたユーザーは、これまでのサブスク枠のままだったそうです。同じツールなのに、呼び出し方で課金先が変わる、と結ばれています。

これは実務にとってかなり重要です。「うちは自動化なんてやってない」と思っていても、GitHub Actions で Claude Code を回していればおさいふ2側です。逆に「毎日ものすごい量を使っている」人でも、全部ターミナルで対話していればおさいふ1のままです。使用量の多さと、変更の直撃度は、別の軸なんですね。

Anthropic 自身も、チーム運用については踏み込んで書いています。月額クレジットは「個別の実験と自動化のためにサイズ設定されて」いて、共有の本番自動化を回すチームは「予測可能な従量課金制の請求のために Claude Platform と API キーを使用する必要があります」と書かれています。つまり、組織の共有パイプラインは最初からサブスクの外に置け、という設計思想です。

ちなみにこの構造は、OpenAI 側ではすでに標準です。Codex の料金ページには API Key という選択肢があり、その説明は「CIのような共有環境での自動化に適しています」で、トークン従量課金と明記されています（OpenAI Codex Pricing）。CI（Continuous Integration：継続的インテグレーション）は、コードを変更するたびにテストやレビューを自動で走らせる仕組みのことです。人ではなくサーバーが動かすので、これが「共有環境での自動化」にあたります。Anthropic が6月にやろうとしたのは、この形に寄せる動きだったと読めます。

自分の使用を切り分ける手順

では測ります。3段階でいきます。ccusage で総額を出し、ローカルログの entrypoint で対話とAgent SDKに切り分け、/status で残り枠を見る。この3つが揃うと、自分の請求書のどこが動くのかが数字で言えるようになります。

段階1: 総額を知る

まず ccusage で全体像を出します。Claude Code、Codex、Gemini CLI、OpenCode など16のツールのローカルログを読んで、API直課金だったらいくらだったかを再計算してくれるツールです（GitHub: ccusage/ccusage）。

npx ccusage@latest monthly

これで月次の推移が出ます。ツール別に分けたいときはこうです。

npx ccusage@latest daily --by-agent
npx ccusage@latest claude monthly
npx ccusage@latest codex monthly

Claude Code の5時間ウィンドウごとの消費を見たいときは npx ccusage@latest blocks が使えます。

ひとつ注意点があります。ccusage が出す金額は請求額ではありません。ローカルログに金額のフィールドは入っていないので（私が実際にログを全走査して確認しました）、ccusage は自前の単価表からトークン数を積み上げて再計算しています。つまりこれは「もし API に直接払っていたらいくらだったか」の推定値です。サブスクで使っている限り、実際に払うのは月額そのものです。

段階2: おさいふ1とおさいふ2に切り分ける

ここが本題です。ccusage はツール別には分けてくれますが、同じ Claude Code の中を対話とAgent SDKに分ける機能は持っていません。

そこでログを直接見ます。Claude Code は ~/.claude/projects/ の下に JSONL 形式でセッションログを書いていて、その各行に entrypoint というフィールドがあります。私の環境（JSONLファイル3,675個）を全部走査したところ、値は2種類しかありませんでした。

entrypoint の値	出現数	対応するおさいふ
`cli`	283,243	おさいふ1（ターミナル・IDEでの対話）
`sdk-cli`	9,924	おさいふ2（Agent SDK / `claude -p`）

きれいに2つです。Anthropic が分けようとした境界が、そのままログに記録されていたわけですね。これに気づいたときは、正直ちょっと嬉しくなりました。予測しなくていい、数えればいいので。

次のスクリプトを wallet_split.py として保存して python3 wallet_split.py で動かすと、月ごとの内訳が出ます。追加のインストールは要りません。

import json, glob, os, collections

rows = collections.defaultdict(collections.Counter)
seen = set()

for path in glob.glob(os.path.expanduser("~/.claude/projects/**/*.jsonl"), recursive=True):
    with open(path, encoding="utf-8", errors="ignore") as fh:
        for line in fh:
            if '"usage"' not in line:
                continue
            try:
                rec = json.loads(line)
            except ValueError:
                continue
            msg = rec.get("message") or {}
            usage = msg.get("usage") if isinstance(msg, dict) else None
            if not isinstance(usage, dict):
                continue
            key = (msg.get("id"), rec.get("requestId"))
            if all(key):
                if key in seen:
                    continue
                seen.add(key)
            month = (rec.get("timestamp") or "")[:7]
            bucket = rows[(month, rec.get("entrypoint", "unknown"))]
            for field in ("input_tokens", "output_tokens",
                          "cache_creation_input_tokens", "cache_read_input_tokens"):
                bucket["tokens"] += usage.get(field, 0) or 0

print(f"{'月':<9}{'対話 cli':>18}{'Agent SDK':>16}{'SDK側の割合':>12}")
for month in sorted({m for m, _ in rows}):
    cli = rows[(month, "cli")]["tokens"]
    sdk = rows[(month, "sdk-cli")]["tokens"]
    total = cli + sdk
    share = f"{sdk / total * 100:.2f}%" if total else "-"
    print(f"{month:<9}{cli:>18,}{sdk:>16,}{share:>12}")

途中の seen は重複を落とすための処理です。セッションを再開したり圧縮したりすると、同じ応答が複数のファイルに書かれることがあります。私の環境では、これを入れないと80,293行ぶん二重に数えていました。ここを飛ばすと数字が3割ほど膨らむので、入れておいてください。

私の環境での実行結果です。3,675ファイルで8秒ほどでした。

月	対話 (cli)	Agent SDK	SDK側の割合
2026-06	515,343,620	0	0.00%
2026-07	25,099,243,672	92,656,209	0.37%
2026-08（2日時点）	891,346,379	0	0.00%

これは自分でも意外な結果でした。私は Claude Code をかなり重く使っている側だと思っていますが、その99.6%以上が対話です。6月の変更がそのまま施行されていても、私はほぼ直撃しませんでした。$200のクレジット枠に対して、落ちる側は月$150相当だったからです。

同時に、これは私が対話中心の使い方をしているというだけの話でもあります。CIで自動レビューを回している人、claude -p でバッチを流している人は、同じ総量でもまったく違う数字が出るはずです。だから平均値ではなく、自分の環境で測る意味があります。

なお、ログが残っている期間には限りがあります。私の環境では2026年6月以降しか残っていませんでした。長期で追いたいなら、月初に一度実行して結果を残しておくのがおすすめです。

段階3: 残り枠を見る習慣をつける

計測は過去の話なので、進行中の残量も見られるようにしておきます。

Claude Code では /status で残りの割当が確認できます（Anthropic ヘルプセンター）。ここで大事なのは、Claude Code と Web・デスクトップの Claude、そしてIDE拡張がすべて同じ枠を共有しているという点です。「コーディングしか使ってないのに枠が減る」という感覚があるなら、チャット側で使っている分も乗っています。

Codex 側は、CLIセッション中の /status と、使用量ダッシュボードの2つです。OpenAI の料金ページは「1〜2週間ごとにダッシュボードを確認して、自分のペースと残量を把握してください」と勧めています。

0で,998を使えた10ヶ月の実測

ここからは、私が2025年10月から2026年7月まで、業務で実際に取り続けたログの話です。担当している複数のプロジェクトを横断した ccusage の実測値で、Claude / Codex / Gemini CLI / Hermes / OpenCode の5種類を併用しています。

月	総トークン	API換算コスト
2025-10	277.5M	$79.94
2025-11	1,223M	$283.32
2025-12	365.4M	$128.27
2026-01	909.1M	$304.91
2026-02	7.5M	$5.43
2026-03	979.4M	$454.68
2026-04	3,697.5M	$2,028.73
2026-05	1,488.6M	$1,098.40
2026-06	3,188.4M	$2,274.62
2026-07	19,049M	$12,998
合計	31,186M	$19,657

2026年7月は単月で $12,998 相当、そのうち Claude 分が $12,957 でした。これを Max 20x の $200 で使っています。割ると約65倍です。

ただ、この表で私がいちばん見てほしいのは倍率ではありません。ブレの幅です。

2026年2月は $5.43 でした。4月は $2,028、7月は $12,998 です。最小と最大で2,400倍近い開きがあります。累計 $19,657 のうち、直近3ヶ月だけで $16,371、全体の83%が集中しています。

面白いのは、この10ヶ月の中央値は $380 しかない、というところです。半分の月は $500 にも届いていません。平均で見ても $1,966 で、これはピークの1ヶ月に引きずられた数字です。どの代表値を取るかで、10倍以上ちがう景色が見えることになります。

一般に流通している「ヘビーユーザーで月$1,500くらい」という数字も、たぶん似た事情を抱えています。嘘ではないけれど、その1つの数字で予算を組むと事故ります。組むべきなのはピークのほうです。

これは自分の使い方が荒くなったという話ではなく、道具の性質が変わった結果だと感じています。2026年前半にかけて、エージェントが自律的に長く走るようになりました。同じ1つの指示から出ていくトークン量が、明らかに桁で変わっています。7月に私が混ぜていたモデルは、単月で Fable 5、Opus 4.6 / 4.7 / 4.8、Sonnet 5、Haiku 4.5 の6種類でした。1つのモデルを使い続ける時代ではなくなっている、というのも実感としてあります。

企業の平均値と比べてみると、位置づけがはっきりします。DX がまとめた Anthropic のエンタープライズ導入データでは、平均が開発者1人あたり1稼働日 $13、月あたり $150〜250 で、90%のユーザーは1稼働日 $30 未満です（DX）。同じ資料は、同等のトークンをAPIで使うと月 $600〜1,500 になるとも書いています。私の7月はここから大きく外れた側の事例で、平均的な組織の姿ではありません。だからこそ、自分で測ってくださいという話につながります。

倍率を作っているのはキャッシュです

65倍という数字を見ると、Anthropic が気前よく損を出しているように見えます。でも中身を分解すると、そこまで不思議な話ではありませんでした。

私の7月の対話ぶんのトークンを内訳で見ると、総トークンの97.3%がキャッシュ読込です。新しく読ませた入力でも、新しく書かせた出力でもなく、前のターンから引き継いだ文脈の読み直しが圧倒的多数を占めています。

そしてキャッシュ読込の単価は、Anthropic の公表料金表でどのモデルでもちょうど基本入力の10分の1です（Claude API 料金）。

モデル	基本入力	キャッシュ書込（5分）	キャッシュ読込	出力
Claude Fable 5	$10 / 100万トークン	$12.50	$1	$50
Claude Opus 5 / 4.8 / 4.7 / 4.6	$5	$6.25	$0.50	$25
Claude Sonnet 5（8月31日まで）	$2	$2.50	$0.20	$10
Claude Haiku 4.5	$1	$1.25	$0.10	$5

この単価表で私の7月ぶんを機械的に積み直すと、こんな構成になりました。

内訳	金額	比率
入力	$43	0.3%
キャッシュ書込	$3,253	21.2%
キャッシュ読込	$10,879	70.9%
出力	$1,162	7.6%

コストの7割がキャッシュ読込です。トークン量では97%を占めるのに、金額では71%に収まっている。これは単価が10分の1だからです。仮にこの部分が基本入力の単価で課金されていたら、金額はおよそ10倍に膨らむ計算になります。

つまり65倍という数字の正体は、気前のいい安売りではなく、キャッシュが効いた使い方の結果なんですよね。ここが分かると備え方も変わります。倍率が高い人ほどキャッシュに支えられているので、キャッシュの効かない使い方に移った瞬間、同じ作業量でも請求が跳ねます。

ここからが面白いところで、この構造は Anthropic だけのものではありません。OpenAI の Codex のクレジット単価表でも、キャッシュ済み入力は入力のちょうど10分の1です。GPT-5.6 Sol なら入力125クレジット、キャッシュ済み入力は12.5クレジットになります。

Microsoft Foundry の Kimi K3 も同じでした。入力 $3.30 に対してキャッシュ済み入力 $0.33 で、やはり10分の1です（Microsoft Foundry ブログ）。

3社が揃って同じ倍率を置いているのは、たぶん偶然ではないだろうなと思います。文脈の読み直しは計算資源をあまり食わない、という物理がそのまま値段になっている。そう考えると腑に落ちます。

なお、キャッシュはタダではありません。私の内訳でも、キャッシュ書込が $3,253 と全体の21%を占めています。書込の単価は基本入力の1.25倍なので、頻繁に文脈を作り直すと、読込で浮いたぶんを書込で吐き出すことになります。長いセッションを維持したほうが有利で、こまめに作り直すと損をする。この感覚は覚えておいて損がないと思います。

トークン消費そのものを減らす設計については、姉妹記事のReturn on Tokenで見直すClaude運用｜サブエージェントで消費半減の3層構成で、サブエージェントへの移譲を軸に実装レベルで書いています。あちらが個人の手元の話だとすると、この記事は組織の予算と調達の話です。

3年後を試算する

ここからは予測ではなく、自分の数字を入れる枠です。式はシンプルにします。

月次コスト = 値上げ後の1人あたり単価 × 人数

利用強度は本来ここに掛かってきますが、座席課金である限り、実は掛からないというのが答えです。ここが後で効いてきます。

現在の $200 を基準に、2.5倍（$500）と5倍（$1,000）を置いてみます。為替は1ドル150円で換算しています。自社の数字に置き換えてください。

チーム規模	現在 $200/人	2.5倍 $500/人	5倍 $1,000/人
10人	月 $2,000（約30万円）	月 $5,000（約75万円）	月 $10,000（約150万円）
50人	月 $10,000（約150万円）	月 $25,000（約375万円）	月 $50,000（約750万円）
100人	月 $20,000（約300万円）	月 $50,000（約750万円）	月 $100,000（約1,500万円）

100人で5倍になると年間1億8,000万円です。数字だけ見ると重い。ただ、人件費と並べるとどうでしょうか。

開発者1人の人件費を月70万円と置きます（自社の数字に差し替えてください）。$200 は約3万円ですから、人件費の4.3%です。5倍になっても月15万円で、21%にしかなりません。1人ぶんの人件費に並ぶには、$200 が月70万円になる必要があります。23倍です。

私はこれを計算してみて、少し考えが変わりました。「AIが社員より高くなる」という言い方をよく見かけますし、私も漠然とそう思っていたのですが、座席課金の値上げでそこに到達する筋道は見えません。仮に5倍という、かなり厳しい値上げが来ても、開発者1人の人件費の2割です。生産性の改善で十分に説明がつく範囲だと思います。DX の集計では、AIコーディングツール導入によるPRスループットの改善は中央値で7.76%、多くの組織で5〜15%とされています。人件費の2割を払って1割の改善なら微妙ですが、そもそも5倍の値上げが来る前提での話です。

では何が危ないのでしょうか。式に戻ります。

座席課金には人数という上限があります。100人なら100人分です。ところが従量課金の自動化には、その上限がありません。

自動化側のコスト = 1日あたりの実行回数 × 1回あたりのトークン量 × 単価

ここに人数の項がないのが分かるでしょうか。CIでPRごとにレビューを走らせるパイプラインは、人が増えなくてもPRが増えれば伸びます。夜間バッチを増やせば、誰も残業しなくても請求は伸びます。私の7月の対話ぶんは250億トークンで、これを標準API料金に置くと1人で1万5,000ドル規模です。これが「1人ぶん」ではなくジョブ数で決まる世界に移ると、天井が消えます。

そして、止まった変更が触ろうとしていたのは、ちょうどこちら側でした。おさいふ2に入る対象を思い出してください。Agent SDK、claude -p、GitHub Actions。全部、人数ではなく実行回数でスケールするものです。

だから備え方としては、座席の値上げに怯えるより、自動化のトークン量を実行回数あたりで把握しておくほうが実効性があります。1回のCI実行が何トークン使っているかを知っていれば、単価が変わった日に電卓を叩くだけで済みます。

逃げ道を用意しておく

もうひとつ、単価が動いたときに他へ逃がせるかどうかで、交渉力も落ち着き方も変わります。

ここは実際に選択肢が増えました。Moonshot AI の Kimi K3 は、2026年7月28日から Fireworks AI 経由で Microsoft Foundry にデプロイできるようになっています。2.8兆パラメータのオープンウェイトモデルで、100万トークンのコンテキストを持ちます。Foundry 経由の価格は入力が100万トークンあたり $3.30、出力 $16.50、キャッシュ済み入力 $0.33 です。

大事なのは価格そのものより、これが個人の実験ではなくエンタープライズの調達ラインに載ったという点だと思います。Microsoft が自社のカタログに入れて、データゾーン単位のデプロイができる状態になっている。「単価が上がったら他へ逃げる」が、稟議を通せる話として成立するようになったということです。

Kimi K3 自体の触り方と使い分けはKimi K3完全ガイド｜触り方と使い分けを実務目線でに詳しく書いたので、そちらを見てください。Moonshot の公式ドキュメントには Claude Code や Codex との統合ページもあります（Kimi K3 Quickstart）。

複数サービスを同時に持つ運用そのものについては、Claude Code×Codex連携の実装｜二重建て構成でPRコストを45%削るガイドで実装手順を書いています。どのモデルをどの作業に当てるかの判断はFable・Codex・Sonnet・Opusの使い分け早見表｜変数量で切る2026年のAIモデル選びが参考になるはずです。

私自身の10ヶ月のログを見ても、実態としてはすでに5種類のツールが混ざっていました。意識して分散させたというより、得意なものに寄せていったら勝手にそうなった、という感覚です。結果として、どれか1つの価格が動いても全部が止まることはない状態になっていました。防衛策として構えるより、普段の使い分けの副産物として持てるものだと思います。

今週やる5つのこと

長くなったので、手を動かす部分だけまとめます。

1つめ、npx ccusage@latest monthly を実行して、月次の推移をスクリーンショットか CSV で残します。ログは無限には残らないので、記録を取り始めるのが早いほど後で効きます。

2つめ、この記事のスクリプトで cli と sdk-cli の比率を出します。ここが1桁%なら、いま慌てて設計を変える理由はありません。2桁%なら、その部分を API キー運用に移すことを検討する価値があります。Anthropic 自身も、共有の本番自動化は Claude Platform と API キーを使うよう案内しています。

3つめ、キャッシュ書込の比率を見ます。私の場合は21%でした。ここが極端に高いなら、セッションを細切れにしすぎている可能性があります。長いセッションを維持するだけで下がることがあります。

4つめ、CI や夜間バッチで走らせている自動化について、1回あたりのトークン量を控えておきます。人数ではなく実行回数で伸びるのがこちら側なので、単価が変わったときの試算はこの数字がないとできません。

5つめ、逃がし先を1つだけ動かしてみます。実際に切り替える必要はなくて、動くことを確認しておくだけで十分です。選択肢が実在すると分かっているかどうかで、値上げ発表の日の落ち着き方が変わります。

最後に、私がこの記事を書きながらいちばん腑に落ちたことを書いておきます。私はずっと「値上げが来たらどうしよう」と漠然と身構えていました。でも自分のログを数えてみたら、直撃する部分は0.37%でした。怖がっていた対象が、実は自分の使い方の中にほとんど存在していなかったわけです。逆に、もし私がCI中心の運用をしていたら、同じ総量でまったく違う結論になっていたはずです。

漠然とした不安は、数えると具体的な数字になります。そして数字になると、やるべきことが3つくらいに減ります。皆さんの環境ではどんな比率が出るでしょうか。よければ動かしてみてください。

最後に道具の話をひとつ。私たち Deskrex が開発しているSnorbeは、ナレッジグラフ型のリサーチAIエージェントです。この記事でやったような、公式ドキュメントの原文にあたって数字を突き合わせ、自分の環境の実測と接続するところまでを引き受けます。

この記事の裏側でも、料金表の照合から10ヶ月ぶんのログ集計までを複数モデルの使い分けとキャッシュ前提の設計で回しました。ここまで読んでいただいた Return on Token の考え方を、リサーチ業務そのものに適用した形です。市場調査や技術調査を、出典まで辿れる根拠付きで手元に置きたい方は、一度触ってみてください。

よくある質問

Q1. 結局、値上げや課金分離は来るのでしょうか

時期は誰にも分かりませんが、方向は読めます。Anthropic の告知は「一時停止」であって撤回ではなく、プランを更新するために取り組んでいると明記されています。GitHub は同じ6月に Copilot の定額方式を廃止してトークン課金へ移り、こちらは予定通り実行されました。OpenAI は最初から、共有環境の自動化は API キーで従量課金という設計になっています。ただ、この記事で提案したいのは時期を当てにいくことではなく、来たときに自分のどこが動くかを先に数えておくことです。

Q2. 自分が直撃する側かどうかは、どう見分ければいいですか

使用量の多さでは分かりません。判定基準は「どう呼び出しているか」です。ターミナルやIDEで対話しながら使っているぶんは、変更が入っても従来のサブスク枠のままでした。Agent SDK、claude -p、GitHub Actions 統合、Agent SDK 経由で認証するサードパーティアプリを使っているぶんが、クレジット側に落ちます。記事中のスクリプトを動かすと、この比率が月ごとに出ます。

Q3. ccusage が出す金額は、実際に請求される額ですか

違います。ローカルログに金額のフィールドは入っていないので、ccusage はトークン数と自前の単価表から再計算しています。「もし API に直接払っていたらいくらだったか」の推定値です。サブスクで使っている限り、実際の支払いは月額そのものです。この数字が意味を持つのは、サブスクをやめて API 課金に移った場合や、課金モデルが変わった場合にいくらになるかを見積もるときです。

Q4. キャッシュを意識すると、実際にコストは下がりますか

サブスクを使っている間は支払額が変わらないので、直接の効果はありません。効いてくるのは、使用枠に当たるまでの余裕と、課金モデルが変わったときの請求額です。私の実測では総トークンの97%がキャッシュ読込で、その単価は基本入力の10分の1でした。逆に言えば、セッションを細かく作り直してキャッシュを捨てる使い方をすると、同じ作業でも消費が跳ねます。長いセッションを維持するほうが有利です。

Q5. チームで備えるなら、何から手を付けるべきですか

まずメンバー全員の cli と sdk-cli の比率を集めてください。組織の総使用量ではなく、この比率が意思決定に必要な数字です。次に、CI やバッチで走らせている自動化を洗い出して、1回あたりのトークン量を記録します。座席課金の値上げは人数で頭打ちになりますが、自動化側の従量課金には人数の上限がありません。備えるべき優先度は後者のほうが高いと考えています。