Claude Codeはどれくらい速い？ 秒間トークン数を20,000ターンで実測

Claude Codeはトークンについて多くのことを教えてくれます。/usageはセッションと週のうちどれだけ使ったかを表示し、AgentsRoomのセッションモニターは入力、出力、キャッシュ読み取り、キャッシュ書き込みをターンごとに数え、ステータスラインは使用中のコンテキストウィンドウの割合を表示できます。けれども、みんなが探し続けている数値はどこにも出てきません。待っている間にモデルが実際に毎秒何トークンを生成しているか、です。

この数値は隠されているわけではなく、単に計算されていないだけです。すべてのセッションのすべてのメッセージは~/.claude/projects/配下のJSONLトランスクリプトに書き込まれ、アシスタントの各メッセージにはタイムスタンプとトークン使用量が記録されています。そこで、自分たちのマシンで、直近4週間分を計算してみました。その方法、スクリプト、そして結果を紹介します。

データはどこから来るのか

Claude Codeはセッションごとに1つのファイルを~/.claude/projects/<project slug>/<session id>.jsonlに書き込みます。1イベントにつき1行です。ここで重要なのはアシスタントのメッセージで、必要なフィールドだけを残すとそれぞれ次のようになります。

{
  "type": "assistant",
  "uuid": "24d13076-…",
  "parentUuid": "d4447285-…",
  "requestId": "req_011CepWq…",
  "timestamp": "2026-09-07T18:00:08.412Z",
  "message": {
    "model": "claude-opus-5",
    "usage": {
      "input_tokens": 2,
      "cache_read_input_tokens": 0,
      "cache_creation_input_tokens": 51591,
      "output_tokens": 200,
      "output_tokens_details": { "thinking_tokens": 0 },
      "speed": "standard"
    }
  }
}

計測を可能にしているのは次の4点です。

• timestampはコンテンツブロックが追記された時点で書き込まれるので、ターンの最後のブロックにはストリーム終了時刻が入ります。
• parentUuidは直前の行、つまりモデルが応答していたユーザーメッセージやツール結果を指します。そのタイムスタンプがリクエストの送信時刻です。
• requestIdは1回のAPI呼び出しのブロックをまとめます。テキストを書いてからツールを呼ぶターンは、同じrequestIdと同じusageを持つアシスタント行を2つ生成するので、トークンは行ごとではなくリクエストごとに1回だけ数える必要があります。
• usage.output_tokensはリクエストの出力合計で、思考も含みます。output_tokens_details.thinking_tokensはそのうち思考がどれだけかを示します。

ファイルのどこにも、最初のトークンまでの時間はありません。計測できるのはターン全体、つまりリクエストがマシンを離れてから最後のトークンが届くまでです。待っている間に体感するのもこの数値だけなので、これを採用しました。

方法

requestIdごとに、それを持つ最初と最後のアシスタント行を取り出し、最初の行からusageを読み、最初の行の親を見つけ、親のタイムスタンプと最後の行のタイムスタンプの間の秒数で出力トークンを割ります。そのうえでモデルごとの分布を見ます。単一の平均値は見ません。40秒のターンと2秒のターンは別物だからです。

出力トークンのないターン、所要時間がゼロ以下のターン（再開したセッションでは親の日時が子より後になることがあります）、15分を超えるターンは除外しました。15分超は長い回答ではなく中断されたセッションです。それ以外は何もフィルタリングしていません。

スクリプトは依存関係なしのPython 40行です。どこから実行しても、マシン上のすべてのプロジェクトを読み込みます。

import json, glob, os, statistics as st
from datetime import datetime
from collections import defaultdict

def ts(s): return datetime.fromisoformat(s.replace("Z", "+00:00")).timestamp()

turns = []
for path in glob.glob(os.path.expanduser("~/.claude/projects/*/*.jsonl")):
    by_uuid, groups, order = {}, {}, []
    with open(path) as fh:
        for line in fh:
            try: o = json.loads(line)
            except ValueError: continue
            if "uuid" in o: by_uuid[o["uuid"]] = o
            msg = o.get("message") or {}
            if o.get("type") == "assistant" and msg.get("usage") and o.get("timestamp"):
                rid = o.get("requestId") or o["uuid"]
                if rid not in groups: groups[rid] = []; order.append(rid)
                groups[rid].append(o)
    for rid in order:
        first, last = groups[rid][0], groups[rid][-1]
        out = first["message"]["usage"].get("output_tokens", 0)
        parent = by_uuid.get(first.get("parentUuid"))
        if not parent or not parent.get("timestamp") or out <= 0: continue
        dur = ts(last["timestamp"]) - ts(parent["timestamp"])
        if 0 < dur <= 900:
            turns.append((first["message"].get("model"), out, dur))

by_model = defaultdict(list)
for model, out, dur in turns: by_model[model].append((out, dur))
for model, rows in sorted(by_model.items(), key=lambda kv: -len(kv[1])):
    rates = [o / d for o, d in rows]
    print(f"{model:18s} turns={len(rows):6d} median={st.median(rates):5.1f} tok/s "
          f"weighted={sum(o for o, _ in rows) / sum(d for _, d in rows):5.1f} tok/s")

weighted列はトークン総数を秒数の合計で割ったものです。長い自律実行が体感するのはこちらで、中央値は対話的な1ターンが体感する値です。

数値

フランスにあるMac 1台、319件のトランスクリプト、2026年8月27日から9月25日までの20,408ターン、45時間の生成で出力された1,200万トークン。すべてのターンが標準速度です（高速モードについては後述）。トランスクリプトには、Claude Codeが書き込む名前で5つのモデルが登場します。

まず読み取れることが2つあります。1つ目に、Opus 5.5はOpus 5より少し速いのではありません。中央値で1.5倍、加重値で57%速く、しかも長いターンの割合がずっと高いのです。2つ目に、同じモデル内のばらつきはモデル間の差より大きいことです。Opus 5の25パーセンタイルのターンは毎秒51トークン、75パーセンタイルのターンは72でストリーミングします。理由はターンの大きさで、これは独立した節で扱う価値があります。

短い回答は必ず遅い

もう一度Opus 5を、ターン内の出力トークン数で分けて見てみます。

同じモデル、同じ月、同じマシンなのに、1行の回答と長い回答とで速度は2倍違います。長いターンでモデルのストリーミングが速くなるわけではありません。どのターンも、最初のトークンが現れる前に固定コストを払います。リクエストが送られ、プロンプトが処理され、ストリームが始まります。80トークンのターンではこのコストが経過時間の3分の1を占め、3,000トークンのターンではノイズに埋もれます。

所要時間を出力トークン数に対して最小二乗法で当てはめると、この2つを分離できます。傾きがストリーミング速度、切片が固定コストです。

つまり、ツール呼び出しの多いセッションが遅く感じるとき、原因がモデルのスループットであることはまれです。原因はターンの数です。12個のファイルを1つずつ読むエージェントは固定コストを12回払い、同じエージェントがまとめて1回の呼び出しで読めば1回で済みます。これはトークンコストの削減と同じ教訓です。速いモデルではなく、少なく大きなターンにすることです。

コーパス中で最も長いターンは、Opus 5で236秒に21,332出力トークンでした。最初から最後までで毎秒90トークンです。固定コストが償却されれば、これが標準速度でこのモデルに観測された上限です。

思考トークンは出力トークン

output_tokensには回答前にモデルが行う思考が含まれ、output_tokens_details.thinking_tokensがその量を示します。私たちのコーパスでは、思考はOpus 5が生成した全体の30%、Opus 5.5では18%、Fable 5.1では36%、Sonnet 5では54%を占めました。Sonnet 5はレビュー作業で主に高い推論の強度で動かしていました。

これは遅いターンを読み解くうえで重要です。8秒考えて2行を出力するターンは、モデルが遅いのではなく、目にしない600トークンを生成したターンです。思考ありのターンは、トークンあたりでは思考なしのターンよりわずかに速く、Opus 5で毎秒67対57トークンでした。ターンが長く、固定コストをうまく償却できるからです。セッションが重く感じて推論が不要なら、調整すべきはモデルではなく推論の強度です。

キャッシュ読み取りで変わるのは請求額で、速度ではない

Claude Codeのほぼすべてのターンはプロンプトキャッシュにヒットします。Opus 5の16,680ターンのうちcache_read_input_tokensがゼロだったのは130だけで、それらはセッションの最初のターンです。出力100〜500トークンのターンでは、キャッシュありが中央値で毎秒60.6トークン、3.4秒、キャッシュなしが58.0、3.7秒でした。差は実在しますが小さく、ストリーミング速度ではなく固定コストに現れます。キャッシュが関わるのは抱えているコンテキストの価格であり、だからこそAgentsRoomのターミナルのトークンカウンターはキャッシュ読み取りとキャッシュ書き込みを別々の数値として表示しています。

1か月を通して安定

累積の数値はドリフトを隠すことがあるので、最も多い100〜500トークンのターンについて、Opus 5の週ごとの中央値も確認しました。週を追って毎秒63.6、64.1、60.9、61.7、56.9トークン、途中までの最終週は68.7でした。57から69の間で、傾向はありません。ある日の午後にセッションが遅く感じたら、モデルを疑う前に、その日だけを対象にスクリプトを実行してみる価値があります。

高速モードで何が変わるのか、そして計測できなかったこと

どのusageブロックにもspeedフィールドがあり、私たちの20,408件はすべてstandardです。AnthropicはClaude Opus向けの高速モードを案内しており、CLIの/fastまたはユーザー設定の"fastMode": trueで切り替えます。モデルは最大2.5倍速くなりますが、トークン単価は高く、Opus 5.5では入力100万トークンあたり8ドル、出力100万トークンあたり40ドル、Opus 5とOpus 4.8では10ドルと50ドルです。ProプランとMaxプランでは、サブスクリプションのウィンドウとは別に利用クレジットに課金されます。SonnetとHaikuは対応しておらず、有効にするとOpusに切り替わります。プロンプトの横の稲妻アイコンが有効であることを示します。

私たちはこれに課金していないので、公称の2.5倍と並べられる実測値はありません。もし使っているなら、同じスクリプトで結果がわかります。ターンをusage["speed"] == "fast"で絞り込み、中央値を比べてください。そして数値を送ってください。

エージェントの動かし方で何が変わるか

3つあり、どれも速いモデルを選ぶ話ではありません。

1つ目は見積もりです。7つのエージェントによる夜間実行が200万出力トークンを生成するなら、並行して動くエージェント全体で、毎秒70トークンで8時間分の生成になります。速度がわかってはじめて、スケジュールしたタスクが次のタスクの開始前に終わるかどうかを判断できます。

2つ目はターンです。ターンごとの固定の1秒は、30トークンの確認でも3,000トークンの差分でも同じです。小さなステップのたびに確認を求めたり、ファイルを1つずつ読んだりするエージェントは、その1秒に時間を費やしています。だから私たちは、無人で動くエージェントのプロンプトに「独立した読み込みはまとめて行う」と書いています。

3つ目はカウンターが何を表示すべきかです。AgentsRoomのセッションモニターはトークンとキャッシュを表示し、セッションが重くなると赤くなります。速度は表示しませんし、今回の計測を経て、表示すべきかどうか確信が持てなくなりました。速度はモデルとターンの大きさの性質であって、セッションの性質ではなく、開発者に必要な数値は上の表にあるものです。だからこれはウィジェットではなく記事なのです。

よくある質問

Claude Codeは1秒あたり何トークンを生成しますか？

2026年8月27日から9月25日までに記録した20,408ターンでは、出力トークンの中央値はOpus 5が毎秒63（全トークンを全秒数で割ると69）、Opus 5.5が95（109）、Sonnet 5が77（87）、Fable 5.1が75（80）、Opus 4.8が61（64）でした。これらの数値はターン全体、つまりリクエストがマシンを離れた瞬間から最後のトークンがストリーミングされるまでを数えているので、実際に待っている時間そのものです。

/usageや/costで秒間トークン数は表示されますか？

いいえ。/usageが表示するのはプランのクォータ、5時間ウィンドウと週次ウィンドウ、そして使用中のコンテキストウィンドウの割合です。/costは/usageのエイリアスです。どちらも速度は表示しません。速度が存在する唯一の場所は~/.claude/projects/配下のセッショントランスクリプトで、アシスタントの各メッセージにタイムスタンプと出力トークン数が記録されています。この記事のスクリプトが読んでいるのはそこです。

短い回答が長い回答より遅く感じるのはなぜですか？

どのターンも、最初のトークンが届く前に固定コストを払うからです。リクエストの送信、プロンプトの処理、ストリームの開始です。私たちのデータでは、このオーバーヘッドはOpus 5とOpus 5.5で約1秒、Sonnet 5で0.5秒でした。80トークンの回答では1秒がターンの3分の1を占めるため、計測される速度は毎秒40トークンまで落ちます。3,000トークンの回答では同じ1秒が埋もれ、速度は80以上に上がります。ストリーミング速度そのものは一定です。

思考トークンは速度に含まれますか？

はい。各メッセージのusageブロックはoutput_tokensとその内訳のoutput_tokens_details.thinking_tokensを報告しており、思考トークンはoutput_tokensに含まれます。私たちのコーパスでは、思考トークンはOpus 5が生成した全体の30%、Opus 5.5では18%、主に高い推論の強度で動かしたSonnet 5では54%でした。長く考えるターンは遅いのではなく、目に見えないトークンを生成しているのです。

プロンプトキャッシュでClaude Codeは速くなりますか？

出力速度は変わりません。100〜500トークンのターンで、Opus 5はリクエストがプロンプトキャッシュにヒットしたとき中央値で毎秒60.6トークン、ヒットしなかったとき58.0でストリーミングし、ターン全体では3.4秒対3.7秒でした。キャッシュが左右するのはコンテキストに払う料金であって、回答が出てくる速さではありません。

Claude Codeの高速モードとは何で、どれくらい速くなりますか？

Claude Opusの設定の一つで、Anthropicは最大2.5倍速いと説明しています。その代わりトークン単価は高く、Opus 5.5では入力100万トークンあたり8ドル、出力100万トークンあたり40ドル、Opus 5とOpus 4.8では10ドルと50ドルで、サブスクリプションのウィンドウではなく利用クレジットに課金されます。/fastで切り替えると、プロンプトの横に小さな稲妻アイコンが表示されます。私たちが計測した20,408ターンに高速モードで動いたものは一つもなく（どのトランスクリプトもspeed: standard）、実測値はありません。この記事の数値はすべて標準速度のものです。