Opus5.5で開発環境をチューニングしてみた

Claude Opus 5.5 が出たので、個人開発で使っている Claude Code のマルチエージェント運用を見直しました。「たぶん安くなるはず」で済ませず、手元に残っていた約2か月分の Claude Code のログを集計して、実際どれくらい変わるのかを数字で確かめた記録です。

先に結論です。

• Opus 5.5 の単価に置き換えるだけで、過去2か月分の支出はAPI単価換算で約37%減になる計算でした
• 私の使い方では、支出の98%はプロンプトキャッシュ（読取62%・書込36%）で、出力トークンは3%しかありませんでした。Opus 5.5 のいちばん大きな値下げ（キャッシュ読取 6割引き）がちょうど効く形です
• 逆に、effort（思考の深さ）を下げても費用はほとんど変わりません。effort は費用ではなく、品質と速さのつまみでした
• 「サブエージェントは Sonnet が基本」と決めていたのに、実際には費用の53%を Opus のサブエージェントが使っていました。ルールを書くだけでは守られていませんでした

前提：どんな環境か

Spring Boot + Nuxt の Web アプリを、Claude Code で開発しています。役割を戦国風に分けたマルチエージェント運用をしていて、仲間内で「大名システム」と呼んでいます。

役職	実体	仕事
マスター	人間（私）	方針と最終承認
殿	メインの Claude Code セッション	指示と取りまとめ。自分ではコードを書かない
家老	Explore / Plan サブエージェント	調査・設計・タスク分解
足軽	Agent(isolation: "worktree") のサブエージェント	実装とテスト

モデルの振り分けは次のルールで運用していました。

• 殿は Opus
• 足軽と家老は Sonnet が基本。Opus は「Sonnet で実際に詰まったとき」の格上げ先
• 雑務は Haiku
• Agent を起動するときは model を毎回明示する（省略すると親の Opus を継承してしまうため）

Opus 5.5 で何が変わったか

公式発表と解説記事から、運用に関係するところだけを抜き出しました。

項目	Opus 5	Opus 5.5
入力 / 出力（$/100万トークン）	$5 / $25	$4 / $20（2割安）
キャッシュ読取	$0.50	$0.20（6割安）
effort の既定値（API）	high	medium
Fast mode	$10 / $50	$8 / $40（通常の2倍・usage credits から別課金）
thinking の無効化	条件付きで可	不可（effort だけで調整する）

ほかのモデルとの関係はこうなります。

• Sonnet 5（$2 / $10）との単価差は2倍まで縮みました
• Fable 5.1（$10 / $50）は単価が2.5倍です。公式は「ほとんどの作業で Opus 5.5 は Fable 5.1 と同等の成績を、4割安く出す」と説明しています
• 公式によれば、Opus 5.5 は medium のままで、他社の最上位モデルを最高 effort で動かしたときと同等の成績を約2割のコストで出します
• 顧客の声として「同じ effort で出力トークンが20〜25%減った」という報告も紹介されています

自分のログを集計してみた

集計方法

Claude Code は、会話の記録を ~/.claude/projects/<プロジェクト>/ に JSONL 形式で保存しています。サブエージェントの記録は <セッションID>/subagents/agent-*.jsonl にあります。assistant の各メッセージには message.model と message.usage（入力・出力・キャッシュ読取・キャッシュ書込のトークン数）が入っているので、これを全部足し上げました。

注意点が2つあります。

• ストリーミングの都合で、同じメッセージが複数行に分かれて記録されます。message.id で重複を除きます
• キャッシュ書込は保持時間で単価が違います（5分なら入力単価の1.25倍、1時間なら2倍）。usage.cache_creation の内訳で分けて計算しました

import json, glob, os

ROOT = os.path.expanduser("~/.claude/projects/<プロジェクト>")
files = glob.glob(f"{ROOT}/*.jsonl") + glob.glob(f"{ROOT}/*/subagents/*.jsonl")

for path in files:
    role = "sub" if "subagents" in path else "main"
    seen = set()
    for line in open(path, encoding="utf-8", errors="replace"):
        if '"usage"' not in line:
            continue
        d = json.loads(line)
        msg = d.get("message") or {}
        if d.get("type") != "assistant" or not msg.get("usage"):
            continue
        if msg.get("id") in seen:   # ストリーミングの重複行を除く
            continue
        seen.add(msg["id"])
        u = msg["usage"]
        # u["input_tokens"], u["output_tokens"],
        # u["cache_read_input_tokens"], u["cache_creation"]["ephemeral_1h_input_tokens"] …
        # これを (role, モデル) ごとに足し上げ、モデル別の単価を掛ける

対象データ

• 期間：2026-07-28 〜 2026-09-25（約2か月。これより古いログは残っていませんでした）
• ファイル数：1,238（メインセッションとサブエージェントの合計）
• リクエスト数：約17万3千
• 金額はすべて API 単価で換算した値です。サブスクリプションで使っている場合は、請求額ではなく「利用上限にどれだけ余裕が出るか」と読み替えてください

結果1：支出の98%はキャッシュだった

内訳	API換算	割合
キャッシュ読取	$16,696	62%
キャッシュ書込	$9,701	36%
出力	$733	3%
入力（キャッシュ外）	$4	0%
合計	$27,134

出力はわずか3%でした。エージェントは1往復ごとにそれまでの会話をまるごと読み直します。そのため、費用を決めるのは「どれだけ書いたか」ではなく「どれだけの文脈を何回読み直したか」です。

実際、1リクエストあたりの文脈の長さはかなり大きくなっていました。

誰が	モデル	1リクエストあたりの文脈	1リクエストあたりの出力
殿（メイン）	Opus 5	約33万トークン	683
足軽（サブ）	Opus 5	約26万トークン	125
足軽（サブ）	Sonnet 5	約22万トークン	87

サブエージェントでさえ、毎回20万トークン超を読み直しています。

結果2：Sonnet が基本のはずが、Opus の足軽が支出の半分を使っていた

誰が × モデル	リクエスト数	API換算	割合
足軽 × Opus 5	81,035	$14,444	53%
殿 × Opus 5	22,958	$6,813	25%
足軽 × Sonnet 5	66,519	$4,876	18%
その他（Fable / Haiku / Opus 5.5 など）	—	$1,001	4%

足軽1体あたりの消費量（中央値）は、Sonnet が約350万トークン、Opus が約890万トークンでした。担当した仕事の重さが違うので単純には比べられません。それでも、Opus で起動した足軽が467体もいたこと自体が、ルールが守られていなかった証拠です。

原因は、model を省略して親の Opus を継承させた起動や、「重要な仕事だから」と予防的に Opus を選んだ起動だと考えています。ログからは起動時の指定までは追えないため、ここは推測です。

やったチューニング

集計結果と Opus 5.5 の性質を踏まえて、運用ルール（Claude Code のカスタムスラッシュコマンドと CLAUDE.md）を次のように改めました。

項目	変更前	変更後	ねらい
難所・テスト設計・敵対的レビューの effort	opus / high	opus / medium（詰まったら high）	Opus 5.5 は medium で旧 high 相当の質が出る
effort max	規定なし	使用禁止	思考だけで出力上限（128K）を使い切り、成果物が出ない危険がある
effort xhigh	規定なし	理由を書いたときだけ	同上
殿のモデル切替	対話の途中で /model sonnet に切り替える	途中では切り替えない。Sonnet で足りる仕事は最初から Sonnet のセッションで始める	切り替えるとキャッシュが作り直しになる
設計担当（家老）	opus / high	sonnet / medium（重い設計判断だけ opus）	調査・列挙は Sonnet で足りた実績がある
Fable 5.1	殿の特別枠	常用しない	Opus 5.5 がほぼ同等でずっと安い
Fast mode	—	使わない	単価2倍で別課金
足軽の既定	Sonnet（据え置き）	Sonnet（据え置き）	単価差は縮んだが、Opus 足軽の重さは変わらない

どれくらい節約できそうか

過去2か月分の実績を、条件を変えて計算し直しました。

シナリオ	API換算	削減率
実績（Opus 5 時代）	$27,134	—
① Opus 系の利用を、そのまま Opus 5.5 の単価に置き換える	$17,137	−36.8%
② ①に加えて、Opus の出力が20%減る（公式の顧客事例の値）	$17,029	−37.2%
③ ②に加えて、Opus 足軽の50%を Sonnet に回す	$16,062	−40.8%
④ ②に加えて、Opus 足軽の70%を Sonnet に回す	$15,675	−42.2%

• ①の −36.8% は、解説記事にあった「キャッシュが効く場面では36%減」とほぼ同じ値でした。キャッシュ中心の使い方なら、この数字はそのまま当てはまりそうです
• ②は、出力が3%しかないので、ほとんど効きません
• ③④は、Sonnet に回した仕事も同じトークン量を使うと仮定した、控えめな見積りです
• 殿のモデルを途中で切り替えていた回数は2か月で51回でした。そのたびに作り直したキャッシュは約2,410万トークン、Opus 5.5 の単価で約 $188（全体の0.7%）です。ルールとしては正しいものの、効果は小さめでした

まとめると、モデルの更新だけで約37%、ルールがきちんと守られれば40%台前半という見込みです。

わかったこと

1. effort は「費用のつまみ」ではなかった

出力が3%しかないので、effort を下げて思考トークンを減らしても、直接の節約はわずかです。effort を medium にした価値は、費用よりも「考えすぎて時間を使わない」「max で出力上限を食い潰す事故を防ぐ」ことにあります。

2. 本当に効くのは「文脈の長さ × 往復回数」

費用の98%がキャッシュなので、文脈を短く保つことがいちばん効くはずです。そこで、1リクエストあたりの文脈の長さと費用の関係も測りました（Opus 5.5 / Sonnet 5 の単価で換算）。

文脈の長さ	殿：リクエスト数の割合	殿：費用の割合	足軽：リクエスト数の割合	足軽：費用の割合
〜15万	22%	9%	32%	15%
15万〜30万	33%	21%	41%	37%
30万〜50万	26%	29%	20%	29%
50万〜	20%	42%	7%	19%

殿の費用の約7割、足軽の約5割は、文脈が30万トークンを超えたリクエストから出ていました。1M コンテキストが使えるぶん、区切らずに長く続けてしまっていたわけです。一方、足軽の最初のリクエストの文脈は中央値で約5万3千トークンでした。システムプロンプト・ツール定義・CLAUDE.md・指示書を合わせた、足軽1体の「固定費」にあたります。

この結果を受けて、次のルールも追加しました。

• 殿は文脈30万トークンを目安に区切る。タスクの切れ目で /compact するか、引継書を作って新しいセッションに移る
• 足軽は1体1タスク。別の仕事を既存の足軽に続けて頼まない（前の仕事の文脈を毎回読み直すことになるため）
• 足軽の報告は要点だけ。結果・変更ファイル・未解決事項を短く返させ、コードやログの全文を貼らせない
• 大きなファイルやログは丸ごと読まない。Grep で場所を絞り、Read は範囲を指定する。ビルドの出力は失敗箇所だけ見る
• 指示書に規約の全文を貼らない。パスと節番号で示す。ただし禁止事項や判定基準は削らない（品質は指示書の精度で担保してきたため）

こちらの効果は、しばらく運用してから同じ集計で測るつもりです。

3. ルールは書くだけでは守られない

「Sonnet が基本」と CLAUDE.md とスラッシュコマンドに何度も書いていたのに、支出の半分は Opus の足軽でした。ログを集計して初めて、ルールと実態のずれが見えました。今後は、この集計を定期的に回してずれを確認するつもりです。

4. Sonnet 5.5 / Haiku 5.5 が出たら、もう一度見直す

公式は、Sonnet 5.5 と Haiku 5.5 を「数週間以内」に出すと発表しています。出たら同じ集計でもう一度比べてみます。

おわりに

新しいモデルが出ると「賢くなった」「安くなった」で終わりがちです。ですが、自分のログを見ると、どこにお金が掛かっているか（私の場合はキャッシュ）によって、効く値下げと効かない値下げがはっきり分かれました。Claude Code を使っているなら、~/.claude/projects/ の JSONL を一度集計してみるのがおすすめです。

参考

• Claude Opus 5.5（Anthropic 公式）
• Claude Code での Opus 5.5 活用ガイド（Qualiteg ブログ）