Claude 5.5: 失敗したタスクへの支払いをやめよう

本当に重要なのは Sonnet と Opus の構成——effort、キャッシュ、検証、そしてタスク完了あたりのコスト

最も安いモデルとは、トークン単価が最も低いモデルのことではない。

仕事を最後までやり遂げ、チェックを通過し、同じコンテキストに 5 回も料金を払わせずに済むモデルのことだ。

Sonnet 5.5 と Opus 5.5 では、この違いが異例なほど重要になる。一方は処理量（ボリューム）向けに価格設定され、もう一方はより難しい作業向けに価格設定されている。どちらも新しい effort の挙動を持ち、適切にキャッシュされたエージェントループの中では驚くほど低コストで動かせる。

古い設定をそのままどちらかのモデルにコピーしても、遅くなるか、高くなるか、400 エラーが出るだけだ。

代わりに、私が組むならこうする。

1タスク → SONNET 5.5 → チェック → 必要なら OPUS 5.5 → 検証済み結果
2             ↘ effort ↗         ↘ キャッシュ + 利用量台帳 ↗

Substack では、AI エージェント、ワークフロー、本番システムの実践的な解説を発信しています

ニュースレターに登録する

スタックを決めるべき「たった一つの指標」

モデル比較の多くは「100 万トークンあたり何ドル」から始まる。

しかし、あなたのエージェントが納品するのはトークンではなく、完了したタスクだ。

https://x.com/claudeai/status/2102435511222890900

繰り返すが、これは彼らのテスト結果だ。あなたのアーキテクチャには、あなた自身の数字が必要になる。

つまり、印象的な回答を 1 つ読んで「まあ良さそう」と曖昧に承認するようなチェックではダメだということだ。コーディングなら、マージをブロックするはずのテストを使う。抽出なら、必須フィールドをラベル付きデータセットと突き合わせる。調査なら、引用元が各主張を実際に裏付けているかを記録する。デモ用の都合の良い事例だけでなく、決して合格しないタスクのコストも含めて計算すること。

そして、ハードテール（難易度の高い末端部分）は分けて分析しよう。最安の設定でリクエストの 90% を処理できても、残り 10% で予算の半分を溶かしているなら、平均値は「別のモデルが必要なワークフローの部分」を隠してしまう。

5.5 の料金表が実際に示していること

2026 年 10 月 3 日時点の標準 Claude API 料金（100 万トークンあたり）は以下の通りだ。

1SONNET 5.5
2新規入力  $2       出力  $10
3キャッシュ読み込み   $0.20    キャッシュ書き込み  $2.50 / 5分, $4 / 1時間
4
5OPUS 5.5
6新規入力  $4       出力  $20
7キャッシュ読み込み   $0.20    キャッシュ書き込み  $5 / 5分, $8 / 1時間

両モデルとも 1M トークンのコンテキストウィンドウと、最大 128K トークンの出力に対応している。これらは上限であり、埋めるべき目標ではない。

モデル仕様と料金

注目すべきはキャッシュ読み込みの行だ。

Opus は新規入力と出力で 2 倍の料金がかかるが、キャッシュされたプレフィックスは両モデルとも同じ 100 万あたり $0.20 だ。だからといって Opus の実行が同等に安くなるわけではない。新規入力、出力、キャッシュ書き込みにはやはり多く支払うことになる。ただし、読み込み中心のセッションではモデル間の価格差が縮まり得るということだ。

見落とされがちな 2 つ目の違いもある。Anthropic が掲げる「Opus 5 より 40% 安い」というのは、典型的な\実行コスト\の推定値だ。Opus 5.5 の新規トークン価格は 20% 下がり、キャッシュ読み込み価格は 60% 下がった。これらは関連しているが、互換性のある数字ではない。

Effort はルーティングの判断であり、品質のスライダーではない

Sonnet 5.5 は low、medium、high、xhigh、max に対応している。API ではデフォルトが high だが、Claude アプリでは Anthropic によると medium がデフォルトだ。Opus 5.5 は API で medium がデフォルトとなる。これらのレベルは、以前のモデルで同じ単語が意味していたものと完全に一致するように調整されているわけではない。

私の出発点となるマッピングはこうだ。

• Sonnet low 安価なチェックで済む、範囲が狭くレイテンシが重要なリクエスト向け
• Sonnet medium 仕様が明確なコーディングや、定型のマルチステップ作業向け
• Sonnet high medium の実行が実際のチェックで失敗した場合や、タスクの複雑さのパターンが判明している場合
• Opus medium 曖昧で複数ファイルにまたがる長期的な作業で、Sonnet が何度も同じ問題を周回してしまう場合
• Xhigh/max 評価（eval）によって、追加の時間とトークンをかける価値があると証明された場合のみ

これはあくまで初期仮説であり、普遍的な序列ではない。Anthropic が報告した Sonnet 5.5 の FrontierCode 結果では、xhigh が max を上回った。effort を上げることが、より良い結果の証明にはならないのだ。

Anthropic の脚注がこの直感に反する結果を説明している。max では、モデルが余分なコードレビュー作業を開始する頻度が高くなった。調査対象となった 2 つのケースでは、それがタイムアウトやタスク範囲外の編集につながっていた。

失敗モードは「モデルの思考が足りなかった」のではない。間違った場所に effort を費やしてしまったのだ。エージェントがすでにチェックを通過しているなら、余計なレビューターンはコスト増と新たなミスの原因になり得る。

https://x.com/edwinarbus/status/2104675431853248816

また、max_tokens を低く設定して最適化と呼ぶのもやめよう。この制限は思考と可視出力の両方をカバーする。タスクの途中で打ち切れば、節約どころか中途半端な回答と 2 回目の実行を買う羽目になる。

https://x.com/claudeai/status/2104633115620823187

魅力的なローンチ時の謳い文句ではある。しかし、本番環境の設定はそれでもあなた自身のベースラインを上回る必要がある。

モデルルーターを作る前に、小規模なスイープを実行する

あなたが本当に気にしているタスクを 10〜30 個用意する。簡単なもの、曖昧なもの、ログに残っている厄介な失敗例を含めること。各タスクに検証器（verifier）を用意する。テスト、構造化された比較、既知の正解、あるいは実行前に記録した人間の評価基準などだ。

以下は最小限かつ有用な API プローブだ。必要な usage フィールドをログ出力する。これを各モデル・各 effort レベルで同じタスクに対して実行し、独自の合格/不合格チェックを追加する。完全なエージェントベンチマークではない。

1import anthropic
2
3client = anthropic.Anthropic()
4response = client.messages.create(
5    model="claude-sonnet-5-5",  # claude-opus-5-5 でも繰り返す
6    max_tokens=8192,
7    output_config={"effort": "medium"},  # high でも繰り返す
8    messages=[{"role": "user", "content": "Replace this with a real task."}],
9)
10
11answer = "".join(b.text for b in response.content if b.type == "text")
12usage = response.usage
13print(answer)
14print("fresh", usage.input_tokens, "output", usage.output_tokens)
15print("cache read", usage.cache_read_input_tokens)
16print("cache write", usage.cache_creation_input_tokens)

これは公式の Anthropic Python パッケージと、環境変数 ANTHROPIC_API_KEY を前提としている。キャッシュを有効にしていない単発の呼び出しなので、キャッシュの読み書きはゼロになるのが正常だ。次のセクションで、それを変える方法を説明する。

実際のエージェントでは、リトライやツール呼び出しを含め、1 つのタスク ID に紐づくすべての API 呼び出しの usage を合計する。検証器が「完了」と判定した場合のみ合格としてカウントすること。

デフォルトを選ぶ前に、合格 1 件あたりの総コスト（ドル）を比較しよう。

テストは公正に保つこと。

• 設定を比較する前に、タスク群と検証器を固定する
• すべての候補で、同じツール、権限、コンテキスト、出力要件を使用する
• 合格率、総支出、合格あたりのコスト、レイテンシ、そして最も長く/高くついた失敗を記録する
• stop_reason: "max_tokens" は「安価な成功」ではなく「未完了の試行」としてカウントする

上記の短いコードサンプルは、シングルターンのプローブ用に 8K の出力上限を使っている。この上限を長時間稼働するコーディングエージェントにそのまま流用してはいけない。

Anthropic はエージェント的な作業にはずっと大きな余裕を推奨している。非表示の思考（hidden thinking）も同じ制限に加算されるからだ。

作業に合わせて上限を設定し、その上で effort、キャッシュ、タスク予算を使って支出をコントロールしよう。途中で無理やり回答を止めさせるべきではない。

ジョブの安定した部分をキャッシュする

エージェントは同じシステム指示、ツール定義、リポジトリマップ、過去の会話を何度も送信する。そのプレフィックスが安定しているなら、プロンプトの微修正よりもプロンプトキャッシュの方が経済性を大きく変える。

例えば、200K トークンのキャッシュを 50 回読み込めば、10M キャッシュ読み込みトークンになる。100 万あたり $0.20 なので、どちらの 5.5 モデルでも読み込みコストは $2 だ。

Opus 5.5 で同じ 10M トークンを新規入力として送ると $40 かかる。200K トークンの最初の 5 分間キャッシュ書き込みでさらに $1 だ。

これはプレフィックス料金のみの例示である。新規入力、出力、その他の書き込み、TTL 切れ、実際のキャッシュミスが請求額に加算されることを忘れないでほしい。

実践的なルール：

• Claude API では、トップレベルの cache_control={"type": "ephemeral"} または明示的なキャッシュブレークポイントでプロンプトキャッシュをオプトインする。上記のプローブはどちらも使っていないため、通常キャッシュカウンターはゼロのままになる
• 安定した指示やツールは、変化するユーザーリクエストの前に配置する
• ターン間で共有プレフィックスを同一に保ち、実際の cache_read_input_tokens を確認する
• モデルの切り替えは無料の続きではなく、新しい会話予算として扱う。キャッシュはモデルごとだ。Opus のリクエストが Sonnet がキャッシュしたばかりのプレフィックスを読み込むことはできない
• ターンごとにトップレベルの effort を変更するのは避ける。レンダリングされるプロンプトが変わり、キャッシュされたプレフィックスが無効になる

対応モデルでは、メッセージごとの effort 変更が以前のキャッシュを保持できる場合があるが、これには Anthropic のベータヘッダーが必要であり、トップレベルの output_config を変更するのと同じではない。

Sonnet 5.5 には between_tools という注意点もある。このモードでは会話の途中で effort を変更できない。

プロンプトキャッシュのドキュメント

レスポンスが速いからといってキャッシュヒットだと推測してはいけない。usage オブジェクトを読むこと。新規入力、キャッシュ作成、キャッシュ読み込みが分離されている。

どちらの 5.5 モデルも、キャッシュ可能なプレフィックスに最低 512 トークンが必要だ。極端に短いシステムプロンプトでは、上記のような節約効果は得られない。デフォルトのキャッシュ寿命は 5 分間で、高速なツールのループに適している。

1 時間の書き込みはコストが高く、実際のセッションが 5 分の枠を外れるほど長く停止することが多い場合にのみ意味がある。長い TTL に課金する前に、そうした空白時間を測定しよう。

不安ではなく証拠に基づいてエスカレーションする

多くのチームはルーターを逆方向に作ってしまう。タスクを「難しい」と分類し、高価なモデルに送り、安いルートでも合格できたかどうかを永遠に学ばない。

検証器をルーティングのシグナルとして使うこと。

11  Sonnet 5.5 ・ 選択した effort  → タスクを実行
22  検証器                    → 合格なら採用
33  Opus 5.5 ・ medium           → 失敗の証拠がある場合のみリトライ
44  検証器                    → 採用するか、証拠とともに引き継ぐ

チェックはテストスイート、スキーマ検証、既知の正解、レビュアーなどでよい。重要なのは何が失敗したかを説明できることだ。

「回答が弱く感じる」はエスカレーションのシグナルとして貧弱だが、「変更したエンドポイントが 2 つの統合テストで失敗する」は有用だ。

同じプロンプトを盲目的に繰り返さないこと。次の試行には、失敗したチェック内容、関連する成果物、ギャップを修正するための具体的な指示を与える。エージェントが人間の判断を要するタスクを直そうとして予算を燃やし尽くさないよう、段階に上限を設けること。

オフラインのスイープで Sonnet high でのリトライをテストできる。検証済みタスクあたりのコストを下げる場合にのみ、ライブのルートに残そう。すべての失敗に Opus へ行く前に Sonnet 2 回分の料金を払わせる理由はない。

モデルの切り替え自体がキャッシュされたプレフィックスを壊すことがある。救出ルートと Opus ファーストルートを比較する際は、それを考慮に入れること。

損益分岐点は見落としやすい。Sonnet の試行に $0.06 かかり、タスクの 80% に合格するとしよう。

失敗したタスクを Opus で仕上げるのに毎回 $0.20 かかるなら、例示的な平均は完了タスクあたり $0.10 になる。$0.06 に加え、5 回に 1 回の $0.20 の救出コストだ。これは全タスクで Opus に $0.20 を払うより安い。しかし、Sonnet が $0.14 で合格率が半分しかない場合、同じ段階を踏んでもモデル切り替えの代償を除いて $0.24 になる。このワークロードでは、Opus ファーストの方が安くて速い。

これらの数字は例であり、実測された Claude の結果ではない。目的は、ルーティングルールを検証可能にすることだ。節約できた Opus の呼び出しが、失敗した Sonnet の試行、キャッシュミス、追加レイテンシを上回る場合にのみ、この段階的アプローチは存在意義を持つ。

中間的な道もある。Anthropic のベータ版 advisor tool だ。Sonnet がタスクを実行し続け、難しい判断だけを Opus に尋ねることができる。仕事全体を Opus に渡す必要はない。

これが自動的に安くなるわけではない。Sonnet が実際にどの程度 advisor に相談するか、その呼び出しにいくらかかるか、最終的な合格率が向上するかをログに記録すること。実行側がほとんど質問しないなら、advisor は使われない機能で終わる。

これらの 5.5 モデルでは、アドバイス自体が暗号化されてクライアントに返される。そのため、プライベートなアドバイスのテキストを検証できるふりをするのではなく、結果として生じた成果物を評価すること。

モデル選び以前に請求額を押し上げる 4 つの「漏れ」

すべてのコスト問題が新しいルーターを必要とするわけではない。

まずこれらを確認しよう：

• 膨張し続ける出力 どちらの 5.5 モデルでも、出力トークンは新規入力トークンの 5 倍のコストがかかる。会話の中で、長い回答は後のターンでコンテキストとして返ってくることもある。各ステップのナレーション付きトランスクリプトではなく、成果物と短い完了メモを求めること。非表示の思考（hidden thinking）も出力として課金されるため、簡潔な最終回答だけでは effort の問題は解決しない。ただし、結果を検証するために必要な証拠まで削ってはいけない
• タスクが必要とする以上のサイズの画像 Sonnet 5.5 は旧世代の Sonnet より高解像度の画像を処理できるため、画像トークン数が増える可能性がある。エージェントがボタンのラベルや 1 つの段落しか必要としないなら、先にクロップまたはリサイズすること。密集したグラフや小さな UI の詳細が必要な場合は、解像度を維持し、盲目的に縮小するのではなくコストを測定すること
• 誰も使わないコンテキスト ツール定義、古いログ、過去の検索結果、肥大化した CLAUDE.md が、あらゆるリクエストについて回ることがある。永続的なルールは短く安定したプレフィックスに入れ、一時的な証拠はそれを必要とするタスクの近くに置くこと。コンテキストの削減は、モデルが正しく完了するためにまだ必要な事実を消してはいけない
• 誰も待っていない作業へのインタラクティブ料金 Message Batches API は、両モデルの入力と出力を 50% 割引する。オフライン評価、ドキュメントの後追い補充、その他の非同期ジョブに有用だ。しかし、今すぐ次のステップが必要な人がいるライブのツールループの代替にはならない

4 つすべてに共通するパターンは同じだ。より高い知能を買ったり、品質が崩れるまで effort を下げたりする前に、タスクが不要としている作業を取り除くこと。

節約を 400 エラーに変えてしまう移行の罠

古いリクエストボディは、5.5 ファミリーの出発点として不適切だ。

特に注意すべき点：

• Opus 5.5 の thinking は常にオン thinking: {"type": "disabled"} や古い固定の budget_tokens 設定は削除し、深さは output_config.effort で制御する
• 強制的なツール指定は両方の 5.5 モデルで失敗する

tool_choice の値 any と tool は 400 を返す。auto を使い、ツールを使用すべきタイミングを指定し、ツール結果は自分のコードで検証すること

• Thinking ブロックはテキストブロックではない コンテンツは content [0] ではなく type で読むこと。ツールループでは、thinking ブロックを変更せずにアシスタントのターンとして返す
• UI が無反応に見えることがある Opus 5.5 では、ツール間の進行状況が thinking ブロックで届くことがあるが、デフォルトの表示設定では空になる。以前それらのノートをユーザーに表示していた場合は、サポートされている thinking 表示モードを要求し、タイプごとにブロックをレンダリングすること。さもなければ、インターフェースがフリーズしているように見える中でエージェントが動き続けることになる
• 古い computer-use ツールのバージョンは失敗する可能性がある ブラウザ/コンピューターエージェントを移行する前に、現在のツールバージョンを確認すること
• max_tokens の上限を小さくしすぎると作業が途切れる

テキストが非表示でも思考は含まれる

これらはプロンプト作成のテクニックではなく、API の挙動変更だ。

Opus 移行ガイド および Sonnet 移行ガイド

契約は頭の中ではなく Claude Code に書く

API はすべての usage フィールドを測定できる場所だ。一方、Claude Code は多くの人が最初にモデルの変更を実感する場所になる。原則は同じだ。エージェントに境界の明確な完了定義を与え、証拠を示させること。

Claude Code では、**/model がモデルを選択し、/effort がサポートされている effort レベルを選択する。セッションを比較する前に、アクティブな設定を確認すること。Sonnet API のデフォルトは、現在あなたの Claude アプリや Claude Code セッションが使っているものを正確に表していない。

以下は、完成度が高く再利用可能な CLAUDE.md の出発点となるブロックだ。コマンドはプロジェクトに合わせて変更すること。

1# Working contract
2
3Make only the requested change. Preserve unrelated work.
4Run the relevant tests after editing. Report any check you cannot run.
5Stop when the requested work passes. Do not add extra features or review loops.
6End with: Changed / Verified / Remaining risk.
7Ask before destructive actions, publishing, or changes outside this repository.

このブロックがあれば魔法のようにすべての実行が安くなるわけではない。成功と失敗が見えるようになるのだ。そこから、同じタスクに対して Sonnet ファーストのワークフローと Opus ファーストのワークフローを比較できるようになる。

タスクのメッセージは具体的でなければならない。「決済コードを直して」と、エージェントが実際に完了できるジョブの違いはこうだ。

1Change: migrate the payment endpoint to the new client
2Done: old client removed, endpoint tests pass, diff limited to this path
3Stop: ask before deleting data or changing anything outside the repo
4Report: changed files, exact checks run, remaining risk

この小さな契約は、検証器に検査すべき具体的な対象を与える。同時に、モデルに「止まる理由」も与える。「完璧になるまでレビューして」という終わりなき指示は、合格するはずの変更を有料のループに変えてしまう。

長期のプロジェクトでは、圧縮（compaction）後も生き残るファイルにチェックリストを残すこと。サブエージェントを使う場合は、リードエージェントに報告を受け入れる前に証拠を検査させること。そしてアイデアだけを求めたのなら、Claude に構築を始めないよう伝えること。これらは「もっと賢くなれ」というプロンプトではなく、ワークフローの境界線だ。

私が最初に本番投入する構成

• 10〜30 個の実際のタスクを選び、それぞれにチェックを定義する
• Sonnet 5.5 を medium と high で、次に Opus 5.5 を medium でスイープする
• タスクごとに新規入力、出力、キャッシュ書き込み、キャッシュ読み込み、レイテンシ、リトライ、合格/不合格をログに記録する
• 安定したプレフィックスをキャッシュ可能に保ち、usage でヒットを確認する
• 失敗したものだけを、証拠を添えて上位にルーティングする
• ワークロードが変わったら段階を見直す。保存されたベンチマークは永遠の真実ではない

難しい 10% が常に「Sonnet の失敗」から「Opus の成功」へ直行するなら、その認識可能なタスククラスは最初から Opus にルーティングすることを検討しよう。もし Sonnet high がより安く同じケースに合格するなら、そこに留めること。ルーターとは測定に基づくポリシーであり、どのモデルが賢いかについての永久的な意見ではない。

5.5 へのアップグレードは、単に「安い作業は Sonnet、難しい作業は Opus」という話ではない。

モデルに値段をつけるのをやめ、完了した仕事に値段をつけ始めるチャンスなのだ。

ここまで読んでくれたなら

-> 私の Substack を購読する

-> 私の Telegram に参加する

-> この記事をブックマークする

-> @0xwhrrari をフォローする