【夏休みの自由研究リレー】Claude Codeの指示ごとにトークン消費量を計測してみた
こんにちは、クラウド事業統括本部 プロフェッショナルサービス本部の荒平(@eiraces)です。
当記事はクラスメソッドの有志による 『夏休みの自由研究リレー』 第1回のエントリです。
このブログリレーの企画は、普段からクラウドやAIを追いかけているメンバーによって、「やってみた」だけではなく「作ってみた」や「調査/研究してみた」もアウトプットしてみようという企画です。
新たな知見になることは勿論、アイデアを自社やコミュニティの発展に寄与できればと考えておりますので、お付き合い頂けますと幸いです。
では、さっそくいってみましょう。今回の記事は『Claude Codeの指示ごとにトークン消費量を計測してみた』です。
Claude EnterpriseやClaude APIの導入を検討しているお客様から、「Claude Codeで作業をしたらどれくらいコストがかかるの？」という質問をよくいただきます。
「英語の翻訳を頼んだら？」「コードレビューをさせたら？」など、具体的な操作ごとのコストが分からないと、稟議も通しづらいですよね。
そこで今回は、Claude Codeへの様々な指示を実際に投げて、操作の種類ごとにトークン消費量とコストを計測しました。導入判断の参考になれば幸いです。
検証環境
今回はClaude Enterprise、auto mode有効の環境で検証を行いました。
バニラ状態での計測
Claude Codeは通常、~/.claude/CLAUDE.md や rules/、memory/ ファイルを自動で読み込み、システムプロンプトに追加します。これらがあると比較が難しくなるため、設定ファイルをほぼない状態（バニラ環境） で計測を行います。
# 設定ファイルを一時的に退避
mv ~/.claude/CLAUDE.md ~/.claude/CLAUDE.md.bak
mv ~/.claude/rules ~/.claude/rules.bak
/plugin や /skills から、最近使ってないスキル群を削除・無効化しました。
/context で、その時点（セッション起動）で読み込まれているコンテキスト量が確認できます。
❯ /context
⎿ Context Usage
⛁ ⛁ ⛁ ⛁ ⛀ ⛀ ⛀ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ Opus 4.8
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ claude-opus-4-8
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ 24.8k/1m tokens (2%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ Estimated usage by category
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ System prompt: 4.1k tokens (0.4%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ System tools: 18.4k tokens (1.8%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ Skills: 2.3k tokens (0.2%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ Messages: 36 tokens (0.0%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ Free space: 975.2k (97.5%)
MCP tools · /mcp (loaded on-demand)
└ 65 tools · 0 tokens
Skills · /skills
└ 19 skills · 2.3k tokens
整理前は大体100.0kほどあったのですが、24.8kまで減らせました。これ以上の削減は難しそうだったので、この状態で進めていきます。
思考予算（Effort）
思考予算は執筆時点で Low, Medium, High, xHigh, Max から選べます。
本エントリでは、特筆のない限り High で進めます。
Effortについては以下のブログが分かりやすいです。
モデル・料金
Anthropicモデルの最新の料金表は以下で確認できます。
計測に使用したモデルと料金（2026年7月20日時点）
| モデル | input ($/MTok) | output ($/MTok) | 5min cache作成 ($/MTok) | 1hour cache作成 ($/MTok) | cache読み取り ($/MTok) |
|---|---|---|---|---|---|
| Claude Fable 5 | $10.00 | $50.00 | $12.50 | $20.00 | $1.00 |
| Claude Opus 4.8 | $5.00 | $25.00 | $6.25 | $10.00 | $0.50 |
| Claude Sonnet 5 (~2026/8/31の料金) |
$2.00 | $10.00 | $2.50 | $4.00 | $0.20 |
| Claude Sonnet 5 (2026/9/1~の料金) |
$3.00 | $15.00 | $3.75 | $6.00 | $0.30 |
トークン消費の確認
プロンプトキャッシングの無効化
本エントリでは特筆のない限り、プロンプトキャッシングを無効化しています。（検証時間の長さのバラツキを結果に影響させないため）
フォルダを切り、そのフォルダ上でのみ .claude/settings.local.json に以下の設定を入れました。
{
"env": {
"DISABLE_PROMPT_CACHING": "1"
}
}
JSONLログからトークン数を確認する
トークン数を確認する手段はいくつかあり、OpenTelemetry や /usage コマンドがよく使われていると思います。
今回はできるだけ早く、確実性の高い方法で確認したかったので、セッションログからトークン数を拾うことにしました。
Claude Codeのセッションログは ~/.claude/projects/<プロジェクト>/<セッションID>.jsonl にJSONL形式で保存されています。各メッセージに usage フィールドが含まれており、ここからトークン数を取り出せます。
手集計でもできるのですが、量が多くなりそうだったので今回はスクリプトを作りました。同じような計測をする方は参考にしてください！↓
コスト計算式
なお、上記ログでは4つのトークン種別すべてを足し込まないと正確なコストになりません。特に cache作成（cache_creation_input_tokens）を忘れがちなので注意が必要です。
計算例
def cost_usd(usage, price):
return (
usage.get("input_tokens", 0) * price["input"]
+ usage.get("output_tokens", 0) * price["output"]
+ usage.get("cache_creation_input_tokens", 0) * price["cache_write"]
+ usage.get("cache_read_input_tokens", 0) * price["cache_read"]
) / 1_000_000
# Opus 4.8
OPUS_48 = {"input": 5.0, "output": 25.0, "cache_write": 6.25, "cache_read": 0.5}
計測結果
各モデルでの計測結果を記載します。利用したプロンプトは記載しますが、得られた回答については脇道に逸れそうなため記載しておりません…！
Claudeがインタラクティブな回答を求めてきた場合には、全てClaude推奨の選択肢を取っています。
1. シンプルな質問
Pythonのリスト内包表記とmapの違いを教えてください
| input | output | コスト | |
|---|---|---|---|
| Sonnet 5.0 | 43,144 | 1,145 | 0.0977 |
| Opus 4.8 | 30,466 | 974 | 0.1767 |
インターネットアクセスはなく、各モデルの知識で回答してくれています。
2. コード生成（小）
Pythonで、CSVファイルを読み込んで特定の列の平均値を返す関数を書いてください
| input | output | コスト | |
|---|---|---|---|
| Sonnet 5.0 | 43,139 | 978 | 0.0961 |
| Opus 4.8 | 30,613 | 917 | 0.1760 |
思ったよりコスト差が出ていませんが、やはりSonnetは安価ですね。ちょっとコード生成はSonnetで十分だと思います。
3. コード生成（大）
S3へのファイルアップロード、ダウンロード、一覧取得、削除ができるPythonクラスを書いてください。エラーハンドリングとログ出力も含めてください
| input | output | コスト | |
|---|---|---|---|
| Sonnet 5.0 | 132,059 | 2,501 | 0.2891 |
| Opus 4.8 | 63,482 | 2,848 | 0.3886 |
| Opus 4.8 (※) | 63,603 | 2,827 | 0.3887 |
※ 後の工程で複数ファイル必要だったため、2回実行
4. ファイル読み込み + 分析
@s3_client.py このコードの問題点を洗い出して、改善提案をしてください
（対象ファイル: 3で作成した約150行のPythonスクリプト）
| input | output | コスト | |
|---|---|---|---|
| Sonnet 5.0 | 45,671 | 4,207 | 0.1334 |
| Opus 4.8 | 33,135 | 1,958 | 0.2146 |
5. GitHubアクセス+コードレビュー
以下のリポジトリ内のコードをレビューしてください。バグ・セキュリティ・可読性の観点でフィードバックをお願いします
https://github.com/hepts/arap-claude-token-usage-script
| input | output | コスト | |
|---|---|---|---|
| Sonnet 5.0 | 607,153 | 13,012 | 1.3444 |
| Opus 4.8 | 268,963 | 10,404 | 1.6049 |
| Fable 5.0 | 885,797 | 12,675 | 9.4917 |
SonnetとOpusの間で、コスト差がかなり小さい結果(1.19倍)となりました。リザルトを確認すると、システムメッセージの数がOpus:7に比べてSonnet:11と増えていたようで、Opusはある程度決め打ったコードレビュー、Sonnetは手探り感を感じるメッセージでした。
なお、気になったのでFableにもやってもらいましたが、今回のコードベースでは5〜7倍のコストを掛けてレビューしてもらうほどの指摘事項は出ませんでした。（適材適所という話で、Fableが悪いわけではない）
6. 翻訳（短文）
以下の英文を日本語に翻訳してください：
"Amazon S3 now supports automatic deletion of incomplete multipart uploads."
| input | output | コスト | |
|---|---|---|---|
| Sonnet 5.0 | 43,146 | 34 | 0.0866 |
| Opus 4.8 | 30,621 | 279 | 0.1601 |
| Haiku 4.5 | 31,878 | 439 | 0.0341 |
Sonnetは訳文のみ、Opusは以下のように補足情報も付けてくれたため、Outputは多くなりました。
"Amazon S3 が、未完了のマルチパートアップロードの自動削除に対応しました。"
補足として、少しニュアンスを変えた訳も挙げておきます。
- 直訳寄り:「Amazon S3 は、未完了のマルチパートアップロードの自動削除をサポートするようになりました。」
- 自然な表現:「Amazon S3 で、未完了のマルチパートアップロードを自動削除できるようになりました。」
用語の補足: "incomplete multipart uploads" は、マルチパートアップロードの途中で中断・失敗し、完了（complete）されずに残っているアップロードのことを指します。これらは放置するとストレージ料金が発生するため、自動削除機能はコスト最適化に役立ちます。
✻ Cooked for 10s
Haiku 4.5もついでに試してみましたが、4.7以前はトークナイザーの仕様が変わっているため、トークン量は参考にならなそうです。ただ、このくらいの英文であれば、Haikuで十分と感じました。
7. 要約＆翻訳（長文ドキュメント）
以下のAWS公式ドキュメント（英語、約4000語）を要約し、日本語に翻訳してください
https://docs.aws.amazon.com/aws-backup/latest/devguide/lag-vault-primary-backup.html
| input | output | コスト | |
|---|---|---|---|
| Sonnet 5.0 | 143,583 | 3,860 | 0.3258 |
| Opus 4.8 | 105,220 | 13,066 | 0.8528 |
カタログスペックと同様くらいのコスト差(2.6倍)がつきました。
私は普段調査系のタスクをSonnetに依頼していますが、Opusはやはりコストパフォーマンスのみで比較すると分が悪いかもしれません。
8. 画像読み込み + 説明
[スクリーンショットを添付]
このAWSアーキテクチャ図を説明してください
以前書いた記事から構成図を持ってきました。
（画像サイズ: 約70kB、2000x1114px）
| input | output | コスト | |
|---|---|---|---|
| Sonnet 5.0 | 46,049 | 1,317 | 0.1053 |
| Opus 4.8 | 33,525 | 1,199 | 0.1976 |
なお、画像はトークンに変換されるため、解像度が高いほどトークン消費が増加する傾向にあります。Opus 4.7以降は高解像度入力に対応し、1枚あたり最大 ~4,784トークン（長辺2576pxまで）まで使うことがあります。
高精細な画像で処理する必要がない場合は、送る前に縮小するとコストを抑えられます。
9. CSV 分析
[CSVファイルを添付]
添付のAWS利用費（CSV、100行）を分析して、傾向と気になる点をまとめてください
| input | output | コスト | |
|---|---|---|---|
| Sonnet 5.0 | 337,513 | 10,157 | 0.7766 |
| Opus 4.8 | 112,826 | 4,775 | 0.6835 |
ついに掛かるコストが逆転しました。が、体感は回答の品質的にはSonnet 5の答えが好みでした。
Opusは「追加でこれも調べましょうか？」と聞いてきてくれているのですが、Sonnetはその部分も先回りで調べてきてくれたので好印象です。（あくまで個人の印象ですが…）
10. スライド構成案
新規Claude Enterprise導入の経営提案資料（10枚）のスライド構成案をmarpで作成してください。対象：製造業の情シス部門
| input | output | コスト | |
|---|---|---|---|
| Sonnet 5.0 | 90,049 | 3,971 | 0.2198 |
| Opus 4.8 | 64,754 | 4,271 | 0.4305 |
Sonnetのスライドはかなりあっさりで内容は薄め、Opusのスライドは人間側で肉付けすれば使えそうなものがありました。
11. メール文案作成
取引先へのシステム障害のお詫びメールを書いてください。障害時間：2時間、影響：一部ファイルのダウンロード不可
| input | output | コスト | |
|---|---|---|---|
| Sonnet 5.0 | 87,814 | 1,214 | 0.1878 |
| Opus 4.8 | 30,621 | 882 | 0.1752 |
コスト・回答品質共に差はありませんでした。回答速度はどちらも20秒程度で、テンプレのメール文案ならモデルの選択は不要なのかもしれません。
12. Web検索 (Deep Research)
2026年下期の百貨店業界のIT課題をリサーチしてまとめてください
ファイル名：20260721-retail-1.md
| input | output | コスト | |
|---|---|---|---|
| Sonnet 5.0 | 15,808,371 | 26,504 | $31.88 |
| Opus 4.8 | 8,970,723 | 13,760 | $45.20 |
双方のモデルでDynamic Workflowを利用してDeep Researchが走りました。
それぞれのタスクがトークンを消費するので、これまでの検証とは比較にならないトークン量です。
（クレジットがあるとはいえ、正直こんなに掛かると思ってなかったので、これを見たマネージャー、ごめんなさい）
考察1. Effort設定によるコスト差
Claude Codeには effort（推論の深さ）の設定があり、高いほど思考トークン（Thinking）が増えて、コストも上がります。値は low / medium / high / xhigh / max の5段階です。
設定方法は以下のように複数あります。
# セッション起動時のフラグ
claude --effort high
# 環境変数
export CLAUDE_CODE_EFFORT_LEVEL=high
# セッション中に切り替え
/effort high
settings.json の effortLevel キーでも永続化できます（low / medium / high / xhigh を指定可能）
思考の深さが影響しそうな「10. スライド構成案」を例に、Sonnetで思考を調整して、トークン量がどれくらいか確認してみます。
新規Claude Enterprise導入の経営提案資料（10枚）のスライド構成案をmarpで作成してください。対象：製造業の情シス部門
| effort | input | output | 体感品質 | コスト |
|---|---|---|---|---|
| low | 212,441 | 3,686 | 超あっさり、早い | 0.4617 |
| medium | 153,585 | 2,880 | あっさり、早め | 0.3360 |
| high | 90,049 | 3,971 | あっさり | 0.2198 |
| xhigh | 790,243 | 12,075 | かなり良い提案、遅め | 1.7012 |
| max | 3,596,002 | 14,146 | かなり良い提案、遅い | 7.3335 |
mediumとhighの間は表を使っているかどうかくらいで、中身の質はあまり違わないように見えました。
xhigh, maxはユーザーの指示がなくともWeb Searchツールで最新情報を確認しており、「しっかり考えて動いてるなぁ」という印象を与えました。（思考予算を増やしているからしっかり考えるのは当たり前なのですが…）
今回の検証ではmaxの威力は分かりづらかったのですが、xhighよりも表現がリッチになっているように思えました。
考察2. AI回答の非決定性
「同一タスクをセッションリセットし、回答させた場合にトークン量は同一となるのか」は誰しも一度は考えるかもしれませんが、これは指示の曖昧さによって回答が全然変わってくるケースがあるため、同一ではない が答えになりそうです。
（今回は複数セッションで同じ指示をしていたため、やたらファイル名が被ったりしてやり直しを複数回しましたが・・・）
なお、「3. コード生成（大）」の結果表で示した通り、答えがある程度収束するような場合はトークン消費量（コスト）はセッションごとで大きく変わらないものと思います。
考察3. ロール別ユースケース・月額試算
個人によってかなりは変わる部分ですが、実際の業務をシミュレーションし、1日あたりの想定コストをサンプルとして算出してみました。
（単位はUSドル）
エンジニア
- コード生成・レビュー: 20回/日
- ドキュメント生成: 5回/日
- デバッグ支援: 10回/日
- Web検索・調査: 5回/日
| 1回あたり(平均) | 1日あたり | 1ヶ月(20営業日) | |
|---|---|---|---|
| Sonnet 5.0 | 0.16 | 6.36 | 127.14 |
| Opus 4.8 | 0.31 | 12.47 | 249.37 |
営業
- メール文案・翻訳: 30回/日
- 提案書・スライド構成: 3回/日
- 競合・市場調査: 5回/日
- 議事録要約: 5回/日
| 1回あたり(平均) | 1日あたり | 1ヶ月(20営業日) | |
|---|---|---|---|
| Sonnet 5.0 | 0.19 | 8.03 | 160.67 |
| Opus 4.8 | 0.35 | 14.85 | 296.98 |
バックオフィス（経理・人事・法務など）
- 書類確認・チェック: 10回/日
- 翻訳: 5回/日
- CSV集計・分析: 5回/日
- 社内FAQ対応: 10回/日
| 1回あたり(平均) | 1日あたり | 1ヶ月(20営業日) | |
|---|---|---|---|
| Sonnet 5.0 | 0.22 | 6.63 | 132.54 |
| Opus 4.8 | 0.27 | 8.13 | 162.62 |
まとめ
シンプルな質問・翻訳はSonnetに軍配が上がると感じました。1回数十円以下に収まるケースが多く、品質が問題になることは少ないと思います。
また、コストを押し上げるのはinputより圧倒的にoutputであり、長い回答を生成させるほど、コストは跳ね上がります（output単価はinputの5倍）
始めからリッチな画面付きファイルを生成するのではなく、markdownを中継して必要なもののみhtml化するなど、工夫できるポイントはありそうです。
Claude Enterpriseの導入では、まずSonnet 5でPoC、トークン計測をして、 品質が不十分な箇所だけFableやOpus に切り替える のが費用対効果の良いアプローチだと感じました。
モデルの性能が響いてくる利用方法（コードレビュー・設計・複雑な分析）では、最初からFable/Opusでも問題ないと思います。ここの判断が難しいんですけどね。
このエントリが誰かの助けになれば幸いです。
以上、『夏休みの自由研究リレー』の第1回のエントリ『Claude Codeの指示ごとにトークン消費量を計測してみた』でした。
次回はべこみんさんの「Claudeを使ったAWS WAF運用をやってみてる話」の予定です。お楽しみに！！
それでは、クラウド事業統括本部 プロフェッショナルサービス本部の荒平がお送りしました！
参考
