Claude Opus 5 は 1M トークンのコンテキストウィンドウを既定かつ最大として持つ。ただし「常に Opus 5 で常に 1M」は最適解ではない。1M が効く場面と効かない場面、Opus 5 で変わったキャッシュ最小長や思考の既定値、そしてモデルとコンテキストをどう組み合わせるかを実務目線で整理する。
Opus 5 のスペック
| 項目 | 値 | |---|---| | モデル ID | `claude-opus-5` | | コンテキスト | 1M トークン（既定かつ最大） | | 最大出力 | 128K トークン | | 料金 | 入力 $5 / 出力 $25 per MTok | | 信頼できる知識カットオフ | 2026 年 5 月 |
1M は「オプションで広げるもの」ではなく既定値になっている。Anthropic API と Max / Team / Enterprise プランではそのまま 1M で動く。Amazon Bedrock と Google Cloud の Agent Platform では 1M のモデルバリアントを選ぶ必要がある。
知識カットオフが 2026 年 5 月というのは、現行世代では最も新しい。Fable 5 と Sonnet 5 はいずれも 2026 年 1 月なので、直近の情報を前提にした作業では差が出る場面がある。
Opus 5 で変わった 2 点
まず思考の既定値。**Opus 5 は `thinking` を指定しないと adaptive thinking が走る**。Opus 4.8 や 4.7 では未指定＝思考なしだったので、ここは挙動が反転している。`max_tokens` は思考とレスポンス本文の合計に掛かる上限なので、思考なし前提で `max_tokens` を切り詰めていたワークロードは、そのまま移すと応答が途中で切れる。
もうひとつはプロンプトキャッシュの最小長。Opus 4.8 の 1,024 トークンから 512 トークンに下がった。短すぎてキャッシュできないと諦めていたプロンプトが、コードを変えずに対象になっている可能性がある。
なお effort の既定値は Claude API でも Claude Code でも `high`。別のレベルを使いたいなら明示的に指定する。
1M context が効く場面
- モノレポ全体の調査 — 複数パッケージを一度に読ませてアーキテクチャの地図を作る
- 長大なログやトレースの分析 — 数十万行を一括で読ませて異常を見つける
- 既存資料を全部前提にした執筆 — 仕様書・議事録・既存ドキュメントを丸ごと入れる
いずれも「分割すると文脈が切れて答えが劣化する」タイプの作業だ。逆に言えば、分割しても答えが変わらない作業に 1M を使う理由はない。
1M context を使うべきでない場面
コンテキストは埋まるほど良くなるわけではない。長くなれば探索コストが上がり、コストと時間も比例して増える。
- 単機能の実装や修正 — Sonnet 5 で足りる。Opus 5 を回すのは無駄が大きい
- 短い会話の反復 — 区切って始め直した方が速い
- バッチ的な単純変換 — Haiku 4.5 なら 1/5 の単価で済む
Claude Code 側の実務としては、コンテキストが逼迫してから慌てるより、能動的に見て畳む方が結果が安定する。
```bash # いま何がコンテキストを占めているかを見る /context
# 残したい観点を指定して畳む /compact keep the test output and the migration plan ```
無料でアカウント作成
CCHub は Claude Code 開発者のための日本語コミュニティです。