※今回の記事はかなり備忘録気味ですが、参考になりそうな方が多いかもと思い共有します。
こんにちは、白々さじきです。
現在私は、Claude Proを契約しています。
ただ、何も気にせずに、色々作業をやっていると、セッション期間の途中で何度かトークンが足りなくなりました。原因はわかっていて、何も考えずに質問に対して毎回 Opus を選んでいたからです。
この記事は、その反省をもとに Claude の各モデルの違いと使い分けを整理したものです。なお、この記事自体を Claude に質問しながら情報を集めて、Claude に下書きを作ってもらっています。「モデルの使い分けを Claude に聞いて、Claude に記事にさせる」という若干メタな構造になっているのですが、それはそれで面白いかなと思っています。
モデルの世代交代が速いので、この記事は 2026年7月時点の情報で書いています。内容は公式ドキュメントや benchmark を参照していますが、情報の鮮度は保証できないのでその点はご了承ください。
なお、Opus のさらに上に Fable 5（Mythos 級）という最上位ティアがありますが、この記事では対象外にしています。プラン内での提供は期間限定で、その後は従量課金（usage credits）になるため、日常的に使い分ける対象としては外して考えたほうがシンプルだからです。ここで扱うのは Opus・Sonnet・Haiku の3つです。
現行ラインナップ（2026年7月時点）
| モデル | API単価 (in/out per MTok) | コンテキスト窓 |
|---|---|---|
| Opus 4.8 | $5.00 / $25.00 | 1M トークン |
| Sonnet 5 | $2.00 / $10.00（〜8/31）→ $3.00 / $15.00 | 1M トークン |
| Haiku 4.5 | $1.00 / $5.00 | 200K トークン |
Sonnet 5 は 2026年8月31日まで導入価格（$2/$10）で、それ以降は標準価格（$3/$15、旧 Sonnet 4.6 と同額）になります。
API 単価ベースで見ると、標準価格でも Opus は Sonnet の約1.7倍、導入価格の期間中は約2.5倍のコストになります。Claude.ai のクォータ消費もこれと比例します。なんとなく Opus を使い続けていると、それだけ早く上限に達してしまいます。
各モデルの特性
Opus 4.8（Fable 5 を除けば実質の最上位）
Fable 5 を使い分けの対象から外すと、これが実質のフラッグシップです。特に強みが出るのはこういった場面です。
- 横断リファクタや複数ファイルをまたぐ設計変更
- 曖昧な要件から骨子を組み立てるような作業
- 長い専門文書（契約書・提案書・法令）の正確な読解
- 込み入ったバグで根本原因が絞り込めないとき
Opus 4.8 は 2026年5月28日にリリースされ、価格は 4.7 から据え置き（$5/$25）です。コーディング benchmark（SWE-bench Pro）は 69.2%（4.7 の 64.3% から向上）です。
このバージョンで一番大きい変更は「正直さ」で、Anthropic によると 自分が書いたコードの欠陥を指摘せずに通してしまう確率が、4.7 より約4分の1に減ったとのことです。さらに 2.5倍速で動く fast mode が従来比で約3分の1の価格になりました。
「Opus は対話してる感がある」という印象を持っている人は多いと思うのですが、これは実際に根拠があります。Sonnet が反論や確認質問をほぼ返さず従順に進む傾向があるのに対して、Opus は「この前提は本当に正しいですか」と立ち止まることが多いのです。曖昧なタスクや反復修正が多い場面では、この差がはっきり出ます。
Sonnet 5（バランス型・デフォルト推奨）
業務の 8 割はこれで足ります。
Sonnet 5 は 2026年6月30日にリリースされ、同日に Sonnet 4.6 を置き換えて Free / Pro プランのデフォルトモデルになりました。位置づけは「Opus に近い性能を、より安いコストで出す」というもので、agentic coding のベンチマーク（SWE-bench Pro）では Sonnet 5 が 63.2%、Opus 4.8 が 69.2%、旧 Sonnet 4.6 が 58.1% でした。知識労働系のベンチマークでは Opus 4.8 をわずかに上回る場面もあります。
数字だけ見ると Opus にかなり肉薄していて、「まず Sonnet」の判断はより正しくなっています。
ただし一点、コードの実力については注意が必要です。7月頭の時点で「タスクによっては旧 Sonnet 4.6 のほうがコードは強い」という声も聞いていて、ここは自分でもまだ検証しきれていません。ベンチマークの数字と実際の使い勝手が一致しないことはよくあるので、コード中心の用途では一度自分のタスクで試してから判断するのが安全です。
もうひとつ、旧 Sonnet 4.6 には固有の弱点がありました。
- 批判や拒否に対して「おっしゃる通りです」とすぐ同意して次の提案を出してくる
- 自分の提案の中の矛盾に気付かないことがある
- 何度拒否しても「何が問題なのか」を確認しに来ない
これはコードの品質の問題ではなく、対話の問題です。”反射的服従” とでも呼ぶべき傾向で、曖昧なタスクや UI の反復修正でハマりやすいものでした。ただし、これは Sonnet 4.6 で観察した傾向で、Sonnet 5 でも同じかどうかはまだ検証できていません。傾向が残っているかは追って確かめたいところです。いずれにせよ、Sonnet で 2〜3 往復しても収束しないと感じたときが、Opus に切り替えるサインだと思っています。
Haiku 4.5（軽量・高速）
SWE-bench Verified は 73.3% で、かつての Sonnet 4（旧世代）とほぼ同等の実力があります。
向いているのはこういった作業です。
- ログやエラーメッセージの分類・要約
- リネーム・定型コメント追加・boilerplate 生成
- 正規表現の意味解説、簡単な SQL 組み立て
- チケットの一行要約・日本語→英語のタイトル変換
1 往復で完結する定型タスクに使うと、コストをかなり抑えられます。
Claude Code では /model haiku で切り替えられます。起動時は claude --model haiku でも指定できます。デフォルトが Sonnet 5 なので意識しないと使わないのですが、機械的な作業を任せる場面では積極的に活用する価値があります。
Extended Thinking（拡張思考）はいつ使うか
ON にすると出力トークンが膨らみ、体感で 5〜10 倍のクォータを消費します。
判断軸はシンプルで、「答えが一意に決まらず、複数の制約を組み合わせて初めて結論が出るか」だけを見れば大丈夫です。文章生成や情報整理はどれだけ深く考えても出力が大きく変わらないので、Thinking ON にする意味がありません。「深く考えることで初めて答えが変わる」タスクだけに絞るのが正解です。
なお、最近の Opus では Thinking の仕様が変わっていて、従来のような固定 budget 指定が廃止されました。現在は adaptive thinking（Claude が必要量を自動で決める）が基本で、ユーザーは ON/OFF を選ぶだけになっています。
加えて Opus 4.8 のリリースと合わせて、claude.ai 上でも effort control（タスクにどれだけ努力量をかけるかをユーザー側で調整できる機能）が入りました。細かく制御したい場合はこちらも使えます。
使い分けまとめ
| タスク | Opus 4.8 | Sonnet 5 | Haiku 4.5 | 拡張思考 |
|---|---|---|---|---|
| ログ・エラーメッセージの分類/要約 | — | — | ✅ | OFF |
| リネーム・定型コメント・boilerplate 生成 | — | — | ✅ | OFF |
| 正規表現の解説・簡単な SQL 組み立て | — | — | ✅ | OFF |
| チケット一行要約・タイトル変換 | — | — | ✅ | OFF |
| コード実装（機能追加・既知バグ修正） | — | ✅ | — | OFF |
| テスト追加・リファクタ | — | ✅ | — | OFF |
| 文章生成（ブログ・メール・議事録） | — | ✅ | — | OFF |
| 比較検討・情報整理 | — | ✅ | — | OFF |
| スキーマ設計・クエリレビュー | — | ✅ | — | OFF |
| 数学・論理・最適化問題 | — | ✅ | — | ON |
| バグ原因解析（Sonnet で収束しない） | ✅ | — | — | ON |
| 横断リファクタ・複数ファイルをまたぐ設計変更 | ✅ | — | — | ON |
| アーキテクチャ判断・要件定義の骨子作成 | ✅ | — | — | ON |
| 長い専門文書（契約書・提案書）の正確な読解 | ✅ | — | — | ON |
| 高解像度スクショ・設計図からの情報抽出 | ✅ | — | — | OFF |
| 長文ドキュメントの矛盾チェック | ✅ | — | — | ON |
✅ = 推奨 / — = そのモデルで使わない
Sonnet で 2〜3 往復しても収束しないと感じた時点で Opus に切り替えるのが実務的な判断ラインです。逆に言うと、それ以外で Opus を使う理由はほぼありません。
「Opus で計画、Sonnet で実行」パターン
Anthropic 公式のドキュメントでも推奨されている使い方で、Claude Code には /model opusplan というコマンドがあります。
- 最初の設計・方針決定フェーズだけ Opus を使う
- 実装・修正フェーズは Sonnet に切り替える
- モデルを切り替えてもコンテキスト（会話履歴）はそのまま引き継がれる
Opus の価値は「深く考えること」にあります。計画が固まった後の実行フェーズはほぼ機械的な作業なので、Sonnet で十分です。Claude.ai の Web 版でも手動でモデルを切り替えることで同じパターンを使えます。
まとめ
トークンが足りなくなった原因を振り返ると、「なんとなく Opus を使い続けていたこと」と「不要なタスクで Thinking を ON にしていたこと」の2つでした。
Sonnet 5 は Opus 4.8 にかなり近い性能を持っていて、ほとんどの作業はこれで足ります（ただしコード中心の用途は自分のタスクで一度試すのがおすすめです）。まず Sonnet を試して、詰まったときだけ Opus に切り替える——この順序を意識するだけで、消費量はかなり改善するはずです。
教訓：「とりあえず Opus」がトークン枯渇の一番の原因。Sonnet をデフォルトにして、詰まったときだけ Opus に切り替える。
2026年7月時点の情報をもとに作成。モデルのラインナップや料金は変更される可能性があります。
サポートのお願い
下記リンクからお買い物いただけると、ブログ運営のための費用が増え、有料サービスを利用した記事作成が可能になります。ご協力よろしくお願いします！
コメント