Claude Opus 5.5 と 1M context の使いどころ — 大きい=正解ではない

Claude Opus 5.5 は 1M トークンのコンテキストを持ち、Claude Code を Anthropic API で使えば Pro を含む全プランでそのまま 1M で動く。ただ、大きいほど正解というわけではない。1M の使いどころは、分割したら答えが変わる作業かで決まる。Opus 5 からの変更点も扱う。

Opus 5.5 のスペック

| 項目 | 値 | |---|---| | モデル ID | `claude-opus-5-5` | | 公開日 | 2026 年 9 月 22 日 | | コンテキスト | 1M トークン | | 最大出力 | 128K トークン | | 料金 | 入力 $4 / 出力 $20 per MTok | | 信頼できる知識カットオフ | 2026 年 6 月 |

1M は「オプションで広げるもの」ではない。Claude Code を Anthropic API に直接つないで使う場合（Bedrock などを経由しない構成）、Opus 4.7 以降の Opus は Pro を含むすべてのプランで 1M のまま動き、`[1m]` 付きのバリアントを選ぶ必要も、使用クレジットを有効にする必要もない。Amazon Bedrock などサードパーティのプロバイダでは、どのモデルが 1M で動くかが別に定められているので、公式の設定ページで確認する。Claude Code 側は v2.1.280 以降が必要だ。

知識カットオフの 2026 年 6 月は Fable 5.1 や Sonnet 5.5 と同じだ。前世代の Opus 5 も引き続き選べるが、公式の一覧では旧モデル（Legacy）扱いになった。

Opus 5 から変わった点

まず思考の扱い。**Opus 5.5 は adaptive thinking が常時オンで、切ることができない**。Opus 5 は effort が `high` 以下なら思考をオフにできたので、そこに依存していた処理はそのままでは移せない。Claude Code でも、セッションの思考トグルや `alwaysThinkingEnabled: false`、`MAX_THINKING_TOKENS=0` は Opus 5.5 には効かない。API で思考なしを前提に `max_tokens` を切り詰めていたワークロードは、移すと応答が途中で切れるおそれがあるので、思考のぶんの余裕を見ておく。

次に effort の既定値。Opus 5 は `high` だったが、Opus 5.5 は Claude API でも Claude Code でも `medium` から始まる。一方で、同じ effort でも Opus 5.5 は Opus 5 より 1 ターンあたりの思考が多めになる傾向があると公式は説明している。Claude Code の公式ドキュメントも、Opus 5 で使っていた effort を持ち込まず `medium` から試すよう勧めている。

価格も下がった。入力 $4 / 出力 $20 で、Opus 5（$5 / $25）より安い。プロンプトキャッシュの読み出しは基本入力料金の 5%（$0.20 per MTok）で、多くのモデルの 10% より割安になっている。キャッシュできる最小長は Opus 5 と同じ 512 トークン。

Claude Code では、安全分類器が生物系やサイバーセキュリティの内容と判定したリクエストは、別のモデルで実行し直される。Opus 5.5 の場合、生物系は Opus 5、サイバーセキュリティ系は Opus 4.8 に回る。

API から直接使っている場合は、ほかにも互換性のない変更がある。ツールの強制指定がエラーになること、thinking ブロックが生成したモデルと会話に結びつくようになったこと、Claude API と Google Cloud では旧版のコンピュータ使用ツール（`computer_20251124`）を受け付けないこと。いずれも主に API を直接呼ぶ側に響く話なので、自前のアプリを Opus 5 から切り替えるなら公式の移行ガイドに目を通しておきたい。エラーにはならないが、ツール呼び出しの合間のテキストが thinking ブロックで返るようになった点も、進捗を表示しているアプリには影響する。

1M context が効く場面

その作業は、分割したら答えが変わるだろうか。1M が本当に効くのは、そこに「変わる」と答えられる作業だ。

• モノレポ全体の調査 — 複数パッケージを一度に読ませてアーキテクチャの地図を作る
• 長大なログやトレースの分析 — 大量のログを一括で読ませて異常を見つける
• 既存資料を全部前提にした執筆 — 仕様書・議事録・既存ドキュメントを丸ごと入れる

公式の目安では、1M トークンは現行のトークナイザで約 250 万 Unicode 文字にあたる。いずれも、分割すると文脈が切れて答えが劣化しやすい作業だ。逆に言えば、分割しても答えが変わらない作業で、コンテキストを 1M 近くまで膨らませる理由はない。

Opus 5.5 と 1M を持ち出すまでもない場面

コンテキストは埋まるほど良くなるわけではない。1M ウィンドウは 200K を超えても割増のない通常料金だが、課金は入力トークンの量に比例し、公式も実際のレイテンシはプロンプトの長さに左右されるとしている。API の従量課金で計算すると、約 967K トークンをキャッシュなしで送れば入力だけで 1 リクエスト約 $3.87、キャッシュ読み出しなら約 $0.19 になる。

• 単機能の実装や修正 — Sonnet 5.5 から試す手がある。入出力の基本単価は Opus 5.5 の半分だ
• 短い会話の反復 — 話題が変わったら `/clear` で空のコンテキストから始め直す
• バッチ的な単純変換 — Haiku 4.5 なら入出力の基本単価は Opus 5.5 の 1/4 で済む

コンテキストが逼迫してから慌てるより、中身を見て先に畳んでおく手がある。Anthropic API で 1M のまま動くモデルでは、既定でウィンドウが埋まる前、約 967K トークンの時点で自動コンパクトが走る。

```text # いま何がコンテキストを占めているかを見る /context

# 残したい観点を指定して畳む /compact keep the test output and the migration plan ```