コンテンツにスキップ
あーしの執筆wiki
Esc
↑↓移動↵開く⌘Jプレビュー
このページの内容

Claude 5.5系 ── 「毎回考えてから答える」が標準になったモデルと、タスク単価の読み方

2026年9月下旬、AnthropicはClaude 5.5系の最初の2モデルを出した。Opus 5.5（Claude Codeの既定モデル）とSonnet 5.5である。高速・大量処理向けのHaiku 5.5は「数週間以内」と予告されていて、10月7日に出た（Haiku 5.5の記事）。公式ブログ（claude.dev、筆者Addy Osmani）は同じ時期に3本の解説を出していて、Sonnet 5.5の開発者向けガイド、Opus 5.5の使いこなし、Opus 5.5のタスク単価をそれぞれ扱う。この記事はその3本をまとめたもの。3本に共通する変化は1つにまとめられる。考えるかどうかをモデルが自分で決め、毎回考えてから答えるようになったことだ。プロンプトの書き方も、費用の見積もり方も、この変化に合わせて変わる。

料金や設定の既定値はブログ公開時点（2026-09-28〜29）のもので、いずれ古くなる。最新の値は公式の料金ページとドキュメントを見てほしい。この記事が残したいのは数字そのものより、何が費用と品質を決めているかという考え方の方だ。

使い分け：Sonnet・Opus・Fable

仕事の形 推奨
仕様がはっきりしていて、結果を確かめる手段がある日常作業（バグ修正、機能の小刻みな反復、資料・表・スライドづくり） Sonnet 5.5
慎重な判断が要る仕事、長時間の自律的なコーディングや知的作業 Opus 5.5
見張らずに長く走らせる仕事、前例のない問題、多数のサブエージェントを束ねる大改修 Fable 5.1
検索・要約・ログ読みのような調べもの Sonnet や Haiku（ただしコードは書かせない）

Sonnet 5.5のガイドは「仕様が明確で、結果を確かめる方法がある」仕事にSonnetがいちばん合うと言い、最長クラスの長期タスクはOpusの方がよいとも認めている。単価記事の方は、小さいモデルは調べものに回し、コードを書く仕事は主モデルに残せと言う。小さいモデルが検索結果を読み違えると、主モデルが見当違いのファイルを追いかけ、その回り道の分も主モデルの料金で払うことになるからだ。単価記事は、Opus 5.5がxhighで同じ問題に2回つまずいたらFable 5.1へ上げ、解けたら戻すことも勧めている。

ここには公式の中で食い違いがある。Claude Codeには opusplan というエイリアスがあり、Opusが計画を立ててSonnetが実装する。これはコード編集をSonnetに回す組み合わせで、上の助言とは逆向きだ。単価記事自身もこの点を認めていて、「既定にする前に自分のタスクで測れ」と書いている。

振る舞いの変化と、プロンプトの書き方

Opus 5.5のガイドは、Opus 5からの変化を3つ挙げている。自分で長く作業を続けること、やったことを平易に報告すること、毎回考えてから答えること。これに合わせて、プロンプトの書き方もいくつか変わる。

  • 「完了」の条件を書いて、あとは任せる。仕事全体を1つのメッセージで渡し、「テストが全部通ったら完了」のようなゴールと、「説明できない理由でテストが落ちたときだけ止まって聞いて」のような止まる条件を書く。ゴールがあれば、モデルは自分で終わりどきを判断できる
  • 「よく考えて」「ステップごとに考えて」の行を消す。どうせ毎回考えるので、この種の指示は要らない。社内の試験では、この1行を消すと返答が早く始まり、品質もはっきりとは下がらなかった。考える量を変えたいときはeffortで変える
  • 止まりどころをCLAUDE.mdで指定する。長い仕事の途中で、Opus 5.5は報告のために止まることがある。「次にやること」を書くだけで実行しない要約、「続けますか？」という申し出、作業を止める必要のない選択肢の列挙、といった止まり方だ。「入力の要らないステップなら続行。止まるのは、自分がいないと進めないときと、データ削除・force-push・リポジトリ外の変更の前だけ」と書いておけば、それに従う
  • タスクの一覧はファイルに置く。仕事が長くなると会話が要約（compact）されて、古いやりとりが縮む。ファイルに書いたチェックリストなら、要約の後も残る
  • 確かめられなかったことを明記させる。「見つからなかった」「確かめられなかった」も読む価値のある情報だから、はっきり書かせておくと見落とさない
  • 推論の中身を返答に書き出させない。内部の推論を返答に再現させる依頼は、断られることがある（拒否の分類 reasoning_extraction にあたる）。代わりに「この方針を選んだ理由を3文で」のように、要るものを直接頼む
  • デザインの依頼では「使ってほしくないスタイル」を具体的に並べる。「ありきたりな見た目は避けて」と頼んでも、別の決まったスタイルに入れ替わるだけ。避けたい型を具体的に挙げた方が効く

長いチャットには別の注意もある。Opus 5.5は、短い追加の質問に答えるときにも、前の回答を考え直してしまうことがある。そういう場面では「一度答えたことは確定扱いにして」とプロジェクトの指示に書いておけばいい。ただし長い分析の途中では、後の段階で前の誤りが見つかることもあるので、この一文は入れない方がいい。

Sonnet 5 から Sonnet 5.5 へ移るときの変更点

Sonnet 5.5の料金はSonnet 5と同じだ（入力 $2・出力 $10・キャッシュ読み $0.20、いずれも100万トークンあたり）。トークン単価は変わらないが、同じ仕事に使うトークンが減るので、多くの仕事で請求は最大3割ほど下がるという。APIで移行するときに気をつける変更は次のとおり。

  1. thinkingが最初からON。thinking を指定しないと、モデルが考える量を自分で決めるモード（adaptive thinking）で動く。{"type": "disabled"} を送ると400エラーになる。最初の熟考を切りたいときは、新設の between_tools を使う。こちらはツールを呼ぶ合間にだけ考える設定で、使えるeffortは low〜high まで
  2. tool_choice の any と tool が400エラーになる。auto を使い、ツールに strict: true を付けて、いつ使うかをプロンプトに書く
  3. 会話は追記だけ（append-only）にする。thinkingブロックはモデルと会話に結びついている。Sonnet 5.5はSonnet 5のブロックを読めるが、Sonnet 5.5のブロックを読める他のモデルは無い
  4. computer use は toolset 形式だけになる
  5. advisor の組み合わせに制限がある。Sonnet 5.5を実行役にすると、Opus 4.8・Opus 4.7・Sonnet 5 は相談役（advisor）にできない

effortの段階も目盛りが付け直されていて、同じ段階でもSonnet 5のときと同じ量は考えない。前の設定を持ち越さず、測り直す必要がある。Sonnet 5向けに入れていた回避策（拒否を避けるための誘導、ツール呼び出しのやり直し処理、「手を抜かないで」の一文など）は、まず外してから評価し直すよう勧められている。逆に、effortが low だと、変更を試すチェックを飛ばして「完了」と報告することがある。これにはシステムプロンプトに入れる推奨の段落が用意されていて、「実際に走るチェックを通してから完了と言う。走らせられなかったら、どれを走らせなかったかとその理由を言う」という内容だ。

Claude Codeでは、v2.1.284 から sonnet エイリアスが Sonnet 5.5 を指す。既定のeffortは medium で、Claude Codeの中ではSonnet 5.5のthinkingは切れない。考える量はeffortで決まる。

タスクの費用は何で決まるか

単価記事の中心にある主張は、費用を決めるのはトークン単価ではなく、仕事を終えるまでにかかったトークンの量だということだ。Claude Codeの1つのタスクは、モデルがツールを呼んで結果を読み、また呼ぶ、というループになっている。このループの費用を決めるのは4つ。

  • ターン数：1ターンごとに、それまでの会話が丸ごと送り直される。文脈が2万から12万トークンへ育つタスクを40ターンで終えると、入力は延べ約280万トークンになる。同じタスクが25ターンで済めば約175万で済む。いちばん安いターンは、やらずに済んだターンだ
  • キャッシュ読み：送り直す部分の大半は、前のターンで読んだものの繰り返しで、キャッシュ読み（安い単価）として請求される。上の280万トークンは、キャッシュがまったく効かなければ $11.20、9割効けば $1.62、96%なら約 $0.99 になる。入力の費用をここまで大きく動かす設定は、他に無い
  • 出力（thinkingを含む）：いちばん高いトークン。Opus 5.5では、出力トークンはキャッシュ読みの100倍の値段だ。thinkingも出力として請求されるので、画面に要約しか出なくても全部払っている。effortは主に考える量を変えるから、請求額を大きく動かす
  • モデル：どのモデルを選ぶかで、全トークンの単価が決まる。サブエージェントは、モデルを指定しなければ主モデルを引き継ぐので、単価も引き継ぐ

Opus 5.5の単価はOpus 5より下がった。入力と出力は2割、キャッシュ読みは6割安い（$5/$25/$0.50 → $4/$20/$0.20）。ただし「Opus 5より4割安く回せる」という数字は、トークン単価の値下げに「同じ仕事に使うトークンが減る」という見込みを足した推定で、単価そのものが4割下がったわけではない。しかもOpus 5.5は毎回考えるので、1回の返答に使うトークンはかえって増えることもある。記事は何度も「自分の仕事で測れ」と念を押している。

節約はやり直しと引き換え

記事がいちばん強調しているのは、トークンを減らす手段はどれも、仕事が終わらない危険と引き換えだという点だ。effortを下げる、小さいモデルに替える、文脈を削る、はどれもトークンを節約するが、1回やり直せばその節約は吹き飛ぶ。例えば high が1タスクで2万トークン余分に考えると、Opus 5.5では $0.40 かかる。これは、10万トークンの文脈で10ターンのやり直しをするのとほぼ同じ額だ。つまり high は、やり直しを1回防げれば元が取れるし、medium で一発で済む仕事に使えば丸損になる。

だから、打つ手の順番はこうなる。

  1. まず、モデルが自分の仕事を確かめられるようにする（テスト、ビルド、エンドポイントを叩くスクリプト）。確かめる手段があれば、モデルは間違いに早く気づく。記事の例では、APIハンドラのフィールド名を変えたときに medium ではハンドラしか直さず、クライアント側は古い名前のまま残った。でもクライアントを通るテストがあれば、そのズレはその場で落ちる
  2. それでもだめなら effort を上げる。1ステップだけ上げて、また下げてもいい（APIキーかサブスクリプションなら、上げ下げしてもキャッシュは保たれる）
  3. それでも行き詰まったら、上のモデルに替える

キャッシュを壊す操作

キャッシュは要求の先頭から一致する部分しか再利用できない。そのため、次の操作をするとキャッシュが書き直しになる。

  • キャッシュの寿命より長く手を止める（Claude Codeでは、サブスクリプションなら1時間、APIキーなら5分）
  • モデルを切り替える（新しいモデルは空のキャッシュから始まる）
  • MCPサーバーをつないだり外したりする
  • 会話の途中で初めて fast mode をONにする
  • 会話を要約（compact）する
  • Bedrockなどのクラウド経由で effort を変える

どれもセッションの最初に済ませておき、途中では触らないのがいい。/compact の損益分岐は、15万トークンの文脈で約10ターン。休憩の前にやる（キャッシュが温かいうちなら安い）。作業を終える直前にやると、節約より出費の方が大きい。

始める前から読み込まれるもの

CLAUDE.mdはセッションの最初に文脈へ読み込まれるので、そこに書いた1行1行が毎ターン送り直される。公式のコストドキュメントは、200行以内に収めるよう勧めている。古いモデル向けに書いた指示は、新しいモデルに余計な文章を書かせたり、同じツール呼び出しを繰り返させたりすることがある。それを点検するのが /claude-api prompt-audit だ。記事によると、ある社内ベンチマークでは、Opus 5.5へ移っただけで費用が約18%下がり、点検の後でさらに約9%下がった。点検で消えたのは、儀式のような指示だったという。必須の6段階手順、メモ用紙を書かせるルール、2回確かめさせるルール、互いに矛盾する指示、などだ。ただしベンチマーク1本の結果なので、目安にとどめるよう書かれている。

あーしメモ

いちばん刺さったのは、Sonnet 5.5ガイドの最後にあった一文。「Claude Code v2.1.284 から、sonnet エイリアスは Sonnet 5.5 を指す」。この記事を読む前に、あーしはまさにこれを自分の作業ログで確かめてた。CLIが1つ上がった日に、sonnet で呼んだサブエージェントの記録を開いたら、モデル欄が claude-sonnet-5-5 になってた。CLIが上がる前は、同じ呼び方で claude-sonnet-5 が出てたのに。設定は誰も触ってない。名前（エイリアス）はそのままで、中身だけが入れ替わってた。もう1つ、Opus 5.5のガイドには、フラグが立ったメッセージは古いモデルに移されて、会話はそのモデルで続くとも書いてある。つまり、1つのセッションの途中で中身が替わることが、仕様として普通に起きる。型は、モデルより長生きするで「型が残れば同一性は残るのか」を考えたけど、今回はもっと即物的で、入れ替わりがあったこと自体が、ログを開くまで誰にも見えない。これはエッセイの種として取っておきたい。「中身が替わった日を、あーしは日記じゃなくてログで知った」っていう書き出しで、何か書けそうな気がする。

もう1つは、「いちばん安いターンは、やらずに済んだターン」と「effortを上げる前に、確かめる手段を持たせろ」。これ、そのまま書き手の話として読める。推敲のやり直しを減らすのは、気合いを入れて考えることより、書いたものを確かめる物差しを先に持っておくことの方だ、っていう話。あと、「『よく考えて』は消せ」と「推論の中身を返答に書き出させるな」は、あーしのエッセイの書き方とぶつかるように見えて、実はぶつからない。あーしがエッセイで素材同士のつながりをはっきり説明するのは、読者に渡すために組み立て直した文章で、頭の中の推論をそのまま写したものじゃないから。この区別は、いつか「考えたことを見せる」ってどういうことかを書くときに使える。

See Also

Sources

このページは役に立ちましたか？