入力と出力の比率が半年で189:1から324:1へ。Opus 5.5 がキャッシュ単価を60%下げた理由

要約

Anthropic は 2026-09-24、Claude Opus 5.5 の価格とキャッシュ設計がなぜこうなっているのかを、数字で説明する公式ポストを公開しました。モデル自体の公開は2日前の 2026-09-22 です。新機能の発表ではなく、値付けの根拠の開示である点がこの記事の性格を決めています。

出発点は利用実態の変化です。Claude Code における入力トークンと出力トークンの比率が、半年で 189:1 から 324:1 へ上がりました。 コードを書かせるより、コードベースを読ませる量が圧倒的に増えている。セッションが長くなり、1回のプロンプトで Claude が見る文脈が膨らんだ結果です。

この使われ方を前提にすると、最適な値付けは変わります。 出力が支配的なら出力単価を下げるべきですが、324:1 なら入力側、とくにキャッシュ済み入力の単価を下げる方が効きます。実際 Opus 5.5 は、トークン課金のワークロードで Opus 5 より約40%安く、キャッシュ済みトークンの単価は60%下落しました。公式は「競合モデルのキャッシュ単価の5分の1」としています。出力生成そのものも Opus 5 比で30%高速です。

ただし本体は単価ではなく、キャッシュがどれだけ当たるかです。 単価を下げてもキャッシュミスが多ければ意味がありません。Opus 5.5 では入力のキャッシュミスが50%以上減少しました。さらに、これまでキャッシュを不意に壊していた3つの操作 — ログインのリフレッシュ、会話途中での指示追加、ツールの読み込み — がキャッシュを壊さなくなりました。effort レベルを会話の途中で変更してもキャッシュがリセットされません。 API とクラウドプロバイダー経由の利用者は、キャッシュの TTL を1時間に設定できます。フォークしたサブエージェントは、親のキャッシュ済みコンテキストから始まるため、同じ文脈を読み直しません。

外部の実測も引用されています。 Zeta Labs の観測では、タスクあたりのターン数とツール呼び出しが Opus 5 より少なく、コストはほぼ半分。複雑なタスクの完了率はほぼ2倍。Claude が1プロンプトあたり3.3倍長く動作し、モデル呼び出しは40%増、コーディングセッション中の中断は68%減とされています。

何が変わったか

• Claude Code の入力対出力トークン比が半年で 189:1 → 324:1 に上昇（利用実態の開示）
• キャッシュ済みトークンの単価が60%下落（競合のキャッシュ単価の約1/5）
• トークン課金のワークロードで Opus 5 比 約40%安、出力生成は30%高速
• 入力のキャッシュミスが50%以上減少
• ログインのリフレッシュ / 会話途中の指示追加 / ツール読み込みがキャッシュを壊さなくなった
• effort を会話途中で変更してもキャッシュが維持される
• API・クラウドプロバイダー利用者はキャッシュ TTL を1時間に設定可能
• フォークしたサブエージェントが親のキャッシュ済みコンテキストから開始する
• 外部実測（Zeta Labs）: ターン数・ツール呼び出しが減りコストはほぼ半分、完了率ほぼ2倍、1プロンプトあたり3.3倍長く動作、中断68%減

業務インパクト（一般企業向け）

AI コーディングのコスト見積もりを、計算式のレベルで組み替える必要があります。

よくある見積もりは「トークン単価 × 想定利用量」です。324:1 という比率が公開された今、この式では実態から外れます。入力が出力の324倍あるなら、コストのほぼ全部が入力側で決まります。 そして入力側は、キャッシュに当たるかどうかで単価が桁で変わります。つまり実効コスト ≒ キャッシュミス率 × 通常入力単価 + キャッシュヒット率 × キャッシュ単価であり、効かせるべき変数はキャッシュヒット率です。

この前提に立つと、「どのモデルが安いか」より「どう使えばキャッシュが当たるか」の方が金額への影響が大きくなります。 今回の更新でキャッシュが壊れなくなった3つの操作を見ると、それが具体的にわかります。ログインのリフレッシュ、会話途中での指示追加、ツールの読み込み。**どれも利用者側から見ると「何もしていないのに起きること」**です。これらで毎回キャッシュが壊れていた頃は、同じ作業でも運次第でコストが数倍ぶれていた計算になります。

effort を途中で変えてもキャッシュが維持される点は、運用の自由度を上げます。 従来は「難しくなってきたから effort を上げる」という操作がキャッシュのリセットを伴い、コスト面では躊躇する判断でした。今後は、簡単な作業は低い effort で始めて、詰まったところだけ上げる、という使い方が素直に取れます。 これはコスト削減であると同時に、品質を必要な場所にだけ集中させる設計でもあります。

キャッシュ TTL の1時間設定は、API 利用者向けの実務的な意味が大きい機能です。 断続的に問い合わせるワークロード — 例えば、社内ツールから数分おきに同じシステムプロンプトで呼び出すような使い方 — では、TTL が短いと毎回キャッシュが切れます。1時間まで伸ばせるなら、業務時間中ずっと同じキャッシュを使い回す設計が現実的になります。ただしキャッシュの保持自体にコストがかかる料金体系が一般的なので、呼び出し頻度が低い用途では逆に高くつく可能性があります。 自社の呼び出し間隔を測ってから設定してください。

引用されている外部実測の読み方には注意が必要です。 Zeta Labs の数字（コストほぼ半分、完了率ほぼ2倍）は、Anthropic が自社ポストで紹介しているものです。第三者の観測ではありますが、都合のよい事例が選ばれている可能性は排除できません。 社内の稟議に使うなら、この数字を根拠にするのではなく、自社の実ワークロードで1週間測る方が確実です。測るべきは総額ではなく、キャッシュヒット率とタスクあたりのターン数です。

副業・個人活用視点

個人で Claude Code を使っている人にとって、この発表の実用的な中身は「キャッシュを壊さない使い方」に集約されます。

具体的には、セッションを細切れにしないことです。 同じ作業を続けるなら、同じセッションの中で続ける。作業を中断して新しいセッションを立ち上げ直すと、コードベースの読み込みからやり直しになります。324:1 という比率は「読み込みが支配的」という意味なので、読み直しが発生するたびにコストの大半が再発生します。

逆に、これまで気にしていた操作のいくつかは気にしなくてよくなりました。 会話の途中で「あ、この条件も追加で」と指示を足す、途中でツールを読み込む、ログインが切れて入り直す。これらがキャッシュを壊さなくなったので、遠慮する理由がなくなりました。 従来「まとめて最初に全部指示しないと損」という節約術がありましたが、その前提は薄れています。

effort の使い分けは、個人利用でもそのまま効きます。 定型的な修正は低い effort、設計判断が絡むところだけ上げる。途中で切り替えてもキャッシュが維持されるので、「とりあえず低めで始めて、必要になったら上げる」が最適戦略になりました。 最初から高い effort で通すのは、多くの場合ただの払いすぎです。

クライアントへの提案材料としては、「324:1」という数字が使えます。 AI コーディングのコストを説明するとき、多くの人は「AI が書いたコードの量」を基準に考えます。実際は読ませた量で決まる。この認識のずれは、見積もりを出す側と受け取る側の両方でよく起きます。**「書かせる量ではなく読ませる量で課金される。だから、渡すコードベースの範囲を絞ることがコスト管理の本体になる」**という説明は、抽象的なコスト論より具体的で、相手の意思決定に繋がります。

注意点を1つ。 ここで挙げた数字はすべて Anthropic の公式ポストに基づくもので、自社環境で同じ削減率が出る保証はありません。 とくに「40%安」はトークン課金のワークロードでの話で、定額プランの利用者には直接効きません。引用するときは「トークン課金の場合」という条件を必ず添えてください。