Claude Codeはどれくらい速い? 秒間トークン数を20,000ターンで実測
Claude Codeは出力速度を一切表示しませんが、各セッションのトランスクリプトには、それを計算するための材料がそろっています。40行のスクリプトを自分たちの319セッション、20,408ターン、1,200万出力トークンに走らせた結果、中央値でOpus 5は毎秒63トークン、Opus 5.5は95、Sonnet 5は77、そして短い回答は長い回答より必ず遅くなりました。方法、スクリプト、数値、そして高速モードで何が変わるのかをまとめます。
Claude Codeはトークンについて多くのことを教えてくれます。/usageはセッションと週のうちどれだけ使ったかを表示し、AgentsRoomのセッションモニターは入力、出力、キャッシュ読み取り、キャッシュ書き込みをターンごとに数え、ステータスラインは使用中のコンテキストウィンドウの割合を表示できます。けれども、みんなが探し続けている数値はどこにも出てきません。待っている間にモデルが実際に毎秒何トークンを生成しているか、です。
この数値は隠されているわけではなく、単に計算されていないだけです。すべてのセッションのすべてのメッセージは~/.claude/projects/配下のJSONLトランスクリプトに書き込まれ、アシスタントの各メッセージにはタイムスタンプとトークン使用量が記録されています。そこで、自分たちのマシンで、直近4週間分を計算してみました。その方法、スクリプト、そして結果を紹介します。
Opus 5.5の秒間トークン数:2026年10月19日の更新
直近の丸4週間、2026年9月21日から10月18日まで(UTC)を対象に計測をやり直しました。デフォルトのトランスクリプトディレクトリに加えて、AgentsRoomが使う追加のClaudeプロファイルも対象に含め、ファイルをまたいで各リクエストを1回だけ数えました。
| Opus 5.5、標準速度 | 計測値 |
|---|---|
| ユニークなリクエスト数 | 30,119 |
| 出力速度の中央値 | 89.4 tok/s |
| 加重出力速度(トークン総数 / 秒数の合計) | 97.5 tok/s |
| ターンあたりの推定固定時間 | 1.29秒 |
| 出力トークンに占める思考の割合 | 42.1% |
固定時間とは、経過秒数を出力トークン数に対して最小二乗法で当てはめたときの切片です。ターンごとのオーバーヘッドの推定値であって、価格ではなく、最初のトークンまでの時間を直接計測したものでもありません。思考は両方の速度に含まれています。
今回の更新ではタイマーも修正しました。直接の親が、deferred_tools_recordをはじめとする技術的なattachmentであることがあり、これは回答がすでに届き始めている間に書き込まれます。あるリクエストでは、旧方式が562トークンを0.046秒で割り、12,000 tok/sを超える値を出していました。親のチェーンをたどって、きっかけとなったユーザーメッセージやツール結果まで戻ると、約7秒の経過時間が取り戻せます。この修正とリクエストの重複排除により、この期間のOpus 5.5のリクエストで400 tok/sを超えるものはなくなりました。高い速度を除外するフィルタリングはしていません。
以下の9月の表は当初の計測のままです。そこにある中央値94.9 tok/sと加重値109.3 tok/sは旧タイマーと別のサンプルに基づくものなので、この差はOpus 5.5が遅くなった証拠ではありません。これらの数値が表しているのは私たちの作業内容、ネットワーク、トランスクリプトのタイムスタンプであり、モデル単体のベンチマークではありません。
データはどこから来るのか
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は直前のイベントを指しますが、それは応答中に書き込まれた技術的なattachmentであることがあります。attachment、system、progressのイベントを飛ばしてチェーンをたどり、きっかけとなったユーザーメッセージやツール結果まで戻ります。そのタイムスタンプが、ターン開始時刻の近似値になります。requestIdは1回のAPI呼び出しのブロックをまとめます。テキストを書いてからツールを呼ぶターンは、同じrequestIdと同じusageを持つアシスタント行を2つ生成するので、トークンは行ごとではなくリクエストごとに1回だけ数える必要があります。usage.output_tokensはリクエストの出力合計で、思考も含みます。output_tokens_details.thinking_tokensはそのうち思考がどれだけかを示します。
ファイルのどこにも、最初のトークンまでの時間はありません。計測できるのはターン全体、つまりリクエストがマシンを離れてから最後のトークンが届くまでです。待っている間に体感するのもこの数値だけなので、これを採用しました。
方法
requestIdごとに、それを持つ最初と最後のアシスタント行を取り出し、最初の行からusageを読み、その親のチェーンをたどってきっかけとなったユーザーメッセージやツール結果まで戻り、最後のアシスタント行までの経過秒数で出力トークンを割ります。リクエストはファイルをまたいで1回だけ数え、モデルと速度設定ごとに分けて報告します。これらのタイムスタンプにはローカルのオーバーヘッドが含まれており、APIの生成時間だけを切り出したものではありません。
出力トークンのないターン、きっかけが見つからないターン、所要時間がゼロ以下のターン、15分を超えるターンは除外します。以下のスクリプトは日付を明記した今回の更新の期間を使い、UTCで開始日を含み、終了日を含みません。別の期間を計測するにはSTARTとENDを変更してください。
更新したスクリプトにはPython 3.10以降が必要で、追加の依存関係はありません。どこから実行しても、デフォルトのプロジェクトとローカルにある追加のClaudeプロファイルを読み込み、その内容をアップロードすることはありません。
import json, glob, os, statistics as st
from datetime import datetime
from collections import defaultdict
START, END = "2026-09-21", "2026-10-19" # UTC, end exclusive
PATTERNS = ("~/.claude/projects/*/*.jsonl",
"~/.agentsroom/claude-profiles/*/projects/*/*.jsonl")
def ts(s): return datetime.fromisoformat(s.replace("Z", "+00:00")).timestamp()
def read_session(path):
by_uuid, groups = {}, defaultdict(list)
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"):
groups[o.get("requestId") or o["uuid"]].append(o)
return by_uuid, groups
def trigger(first, by_uuid):
parent, visited = by_uuid.get(first.get("parentUuid")), set()
while parent and parent.get("type") in ("attachment", "system", "progress"):
uid = parent.get("uuid")
if uid in visited: return None
visited.add(uid)
parent = by_uuid.get(parent.get("parentUuid"))
return parent if parent and parent.get("type") == "user" else None
by_model, seen = defaultdict(list), set()
for pattern in PATTERNS:
for path in glob.glob(os.path.expanduser(pattern)):
by_uuid, groups = read_session(path)
for rid, blocks in groups.items():
first, last = blocks[0], blocks[-1]
if rid in seen or not START <= first["timestamp"] < END: continue
usage = first["message"]["usage"]
out, parent = usage.get("output_tokens", 0), trigger(first, by_uuid)
if not parent or not parent.get("timestamp") or out <= 0: continue
dur = ts(last["timestamp"]) - ts(parent["timestamp"])
if not 0 < dur <= 900: continue
seen.add(rid)
thinking = (usage.get("output_tokens_details") or {}).get("thinking_tokens", 0)
key = first["message"].get("model"), usage.get("speed", "unknown")
by_model[key].append((out, dur, thinking))
for (model, speed), rows in sorted(by_model.items(), key=lambda kv: -len(kv[1])):
outputs, durations, thinking = zip(*rows)
median = st.median(o / d for o, d, _ in rows)
weighted = sum(outputs) / sum(durations)
overhead = st.linear_regression(outputs, durations).intercept if len(set(outputs)) > 1 else float("nan")
print(f"{model} {speed}: turns={len(rows)} median={median:.1f} "
f"weighted={weighted:.1f} tok/s overhead={overhead:.2f}s "
f"thinking={100 * sum(thinking) / sum(outputs):.1f}%")
weighted列はトークン総数を秒数の合計で割ったものです。長い自律実行が体感するのはこちらで、中央値は対話的な1ターンが体感する値です。
数値
フランスにあるMac 1台、319件のトランスクリプト、2026年8月27日から9月25日までの20,408ターン、45時間の生成で出力された1,200万トークン。すべてのターンが標準速度です(高速モードについては後述)。トランスクリプトには、Claude Codeが書き込む名前で5つのモデルが登場します。
| モデル | ターン数 | 中央値 tok/s | 25〜75パーセンタイル | 加重 tok/s |
|---|---|---|---|---|
| Opus 5 | 16,708 | 62.7 | 51.5〜71.8 | 69.8 |
| Opus 5.5 | 1,102 | 94.9 | 80.9〜109.0 | 109.3 |
| Sonnet 5 | 426 | 77.0 | 62.6〜91.5 | 87.0 |
| Fable 5.1 | 2,070 | 75.1 | 66.1〜82.9 | 80.0 |
| Opus 4.8 | 102 | 60.9 | 49.1〜66.5 | 64.2 |
まず読み取れることが2つあります。1つ目に、Opus 5.5はOpus 5より少し速いのではありません。中央値で1.5倍、加重値で57%速く、しかも長いターンの割合がずっと高いのです。2つ目に、同じモデル内のばらつきはモデル間の差より大きいことです。Opus 5の25パーセンタイルのターンは毎秒51トークン、75パーセンタイルのターンは72でストリーミングします。理由はターンの大きさで、これは独立した節で扱う価値があります。
短い回答は必ず遅い
もう一度Opus 5を、ターン内の出力トークン数で分けて見てみます。
| ターン内の出力トークン数 | ターン数 | 中央値 tok/s | 所要時間の中央値 |
|---|---|---|---|
| 1〜99 | 1,854 | 42.1 | 1.9秒 |
| 100〜499 | 10,743 | 60.6 | 3.4秒 |
| 500〜1,999 | 3,512 | 72.8 | 11.1秒 |
| 2,000以上 | 599 | 78.4 | 38.8秒 |
同じモデル、同じ月、同じマシンなのに、1行の回答と長い回答とで速度は2倍違います。長いターンでモデルのストリーミングが速くなるわけではありません。どのターンも、最初のトークンが現れる前に固定コストを払います。リクエストが送られ、プロンプトが処理され、ストリームが始まります。80トークンのターンではこのコストが経過時間の3分の1を占め、3,000トークンのターンではノイズに埋もれます。
所要時間を出力トークン数に対して最小二乗法で当てはめると、この2つを分離できます。傾きがストリーミング速度、切片が固定コストです。
| モデル | ターンあたりの固定コスト | ストリーミング速度 |
|---|---|---|
| Opus 5 | 1.03秒 | 81.6 tok/s |
| Opus 5.5 | 1.10秒 | 148.9 tok/s |
| Sonnet 5 | 0.45秒 | 94.9 tok/s |
| Fable 5.1 | 0.99秒 | 84.8 tok/s |
| Opus 4.8 | 1.40秒 | 69.9 tok/s |
つまり、ツール呼び出しの多いセッションが遅く感じるとき、原因がモデルのスループットであることはまれです。原因はターンの数です。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 Opus 5.5は1秒あたり何トークンを生成しますか?
2026年10月19日に更新した計測では、Claude Opus 5.5は9月21日から10月18日までの30,119件のユニークなリクエストで、出力トークンの中央値が毎秒89.4でした。すべて標準速度です。出力トークンの総数を経過秒数の合計で割ると97.5 tok/sになります。思考は出力トークンの42.1%を占めます。これは自分たちのセッションのトランスクリプトから得たエンドツーエンドの計測値であり、普遍的なストリーミング速度のベンチマークではありません。
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)、実測値はありません。この記事の数値はすべて標準速度のものです。
AgentsRoomをダウンロード
すべてのAIエージェントを、すべてのプロジェクトで、ひとつのウィンドウから実行。
コンパニオンアプリ:外出先でもエージェントを確認
Claude、Codex、Antigravity CLI、またはその他の AI プロバイダーを使用します。
バグや要望を公開バックログに直接送信できます。
続きを読む
Claude Code のモッドとは何か、そして全エージェントに組み込んでいるモッド
モッドとは、JavaScript が Claude Code の中で動くプラグインです。できること、3 つのファイル、読み込み方とテスト方法、そして私たちが全エージェントに組み込んでいるモッドを紹介します。
記事を読むMCP のトークン消費を減らす:ツール定義を 60% 削った方法
エージェントが呼び出せる MCP ツールは、どれもモデルがリクエストのたびに読む可能性のある JSON の塊です。私たちのツールは約 95,000 トークンありました。自分のツールを 2 分で測る方法、ツールを 1 つも削除せずに削ったもの、そして再び膨らむのを防ぐ予算チェックを紹介します。
記事を読むAntigravity の Remote Control:スマホからできること、できないこと
Google は 2026 年 8 月 21 日、Antigravity 2.0 と Antigravity CLI 向けに Remote Control を出しました。その名前での検索の多さを見ると、みんなそれが実際に何なのかを知りたがっています。9 月 22 日時点のドキュメントと照らし合わせて、できることをまとめます。設定のスイッチと agy remote-control コマンド、Google アカウントでログインするウェブのダッシュボード、プッシュ通知を受け取れるホーム画面へのインストール、1 つのスイッチャーに並ぶ複数のマシン、そして大事な 3 つの制限(Antigravity 専用、デーモンはマシンごとに 1 つ、設定は CLI 側に残る)。そのうえで、AgentsRoom のモバイルのリモコンが残り 15 の CLI をどうカバーするのか、2 つがどう組み合わさるのかを解説します。
記事を読む
