※今回の記事はかなり備忘録気味ですが、参考になりそうな方が多いかもと思い共有します。
こんにちは、白々さじきです。
月の途中でトークンが足りなくなりました。原因はわかっていて、何も考えずに毎回 Opus を選んでいたからです。
この記事は、その反省をもとに Claude の各モデルの違いと使い分けを整理したものです。なお、この記事自体を Claude に質問しながら情報を集めて、Claude に下書きを作ってもらっています。「モデルの使い分けを Claude に聞いて、Claude に記事にさせる」という若干メタな構造になっているのですが、それはそれで面白いかなと思っています。
内容は公式ドキュメントや benchmark を参照していますが、情報の鮮度は保証できないのでその点はご了承ください。
現行ラインナップ（2026年5月時点）
| モデル | API単価 (in/out per MTok) | コンテキスト窓 |
|---|---|---|
| Opus 4.7 | $5.00 / $25.00 | 1M トークン |
| Sonnet 4.6 | $3.00 / $15.00 | 1M トークン |
| Haiku 4.5 | $1.00 / $5.00 | 200K トークン |
API 単価ベースで見ると、Opus は Sonnet の約5倍のコストになります。さらに Opus 4.7 は新しいトークナイザーを採用していて、同じ入力テキストでも最大 1.35 倍のトークンを消費することがあります。つまり体感的なコストはカタログ値よりさらに上がります。
Claude.ai のクォータ消費もこれと比例します。なんとなく Opus を使い続けていると、それだけ早く上限に達してしまいます。
各モデルの特性
Opus 4.7（最上位）
Anthropic の現行フラッグシップです。特に強みが出るのはこういった場面です。
- 横断リファクタや複数ファイルをまたぐ設計変更
- 曖昧な要件から骨子を組み立てるような作業
- 長い専門文書（契約書・提案書・法令）の正確な読解
- 込み入ったバグで根本原因が絞り込めないとき
コーディング benchmark（SWE-bench Verified）のスコアは Opus 4.6 で約 80.8%（4.7 はさらに向上）です。また Opus 4.7 からは高解像度画像（長辺 2,576px、従来比 3 倍超）に対応しているので、複雑なスクリーンショットや設計図の読み取り精度も上がっています。
「Opus は対話してる感がある」という印象を持っている人は多いと思うのですが、これは実際に根拠があります。Sonnet が反論や確認質問をほぼ返さず従順に進む傾向があるのに対して、Opus は「この前提は本当に正しいですか」と立ち止まることが多いのです。曖昧なタスクや反復修正が多い場面では、この差がはっきり出ます。
Sonnet 4.6（バランス型・デフォルト推奨）
業務の 8 割はこれで足ります。
SWE-bench Verified は 79.6% で、Opus 4.6 との差は 1.2pt しかありません。コンピュータ操作の自動化 benchmark（OSWorld-Verified）では Sonnet 4.6 が 72.5%、Opus 4.6 が 72.7% で、事実上の同率です。
Claude Code 内での head-to-head 比較では、開発者の 59% が旧フラッグシップの Opus 4.5 より Sonnet 4.6 を好んだというデータもあります。一世代前の Opus と比べてもほぼ遜色ない、というのが現状の Sonnet 4.6 の立ち位置です。
ただし、固有の弱点もあります。
- 批判や拒否に対して「おっしゃる通りです」とすぐ同意して次の提案を出してくる
- 自分の提案の中の矛盾に気付かないことがある
- 何度拒否しても「何が問題なのか」を確認しに来ない
これはコードの品質の問題ではなく、対話の問題です。”反射的服従” とでも呼ぶべき傾向で、曖昧なタスクや UI の反復修正でハマりやすいです。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 なので意識しないと使わないのですが、機械的な作業を任せる場面では積極的に活用する価値があります。
Extended Thinking（拡張思考）はいつ使うか
ON にすると出力トークンが膨らみ、体感で 5〜10 倍のクォータを消費します。
判断軸はシンプルで、「答えが一意に決まらず、複数の制約を組み合わせて初めて結論が出るか」だけを見れば大丈夫です。文章生成や情報整理はどれだけ深く考えても出力が大きく変わらないので、Thinking ON にする意味がありません。「深く考えることで初めて答えが変わる」タスクだけに絞るのが正解です。
なお、Opus 4.7 では Thinking の仕様が変わっていて、従来のような固定 budget 指定が廃止されました。現在は adaptive thinking（Claude が必要量を自動で決める）のみ対応していて、ユーザーは ON/OFF を選ぶだけになっています。
使い分けまとめ
| タスク | Opus 4.7 | Sonnet 4.6 | 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 4.6 は一世代前の Opus に匹敵する性能を持っていて、ほとんどの作業はこれで足ります。まず Sonnet を試して、詰まったときだけ Opus に切り替える——この順序を意識するだけで、消費量はかなり改善するはずです。
教訓：「とりあえず Opus」がトークン枯渇の一番の原因。Sonnet をデフォルトにして、詰まったときだけ Opus に切り替える。
2026年5月時点の情報をもとに作成。モデルのラインナップや料金は変更される可能性があります。
サポートのお願い
下記リンクからお買い物いただけると、ブログ運営のための費用が増え、有料サービスを利用した記事作成が可能になります。ご協力よろしくお願いします！
コメント