Claude API の context-1m-2025-08-07 ベータヘッダが 2026-04-30 で Sonnet 4.5 / Sonnet 4 に対して無効化されました。事前告知通りのリタイアで、これらのモデルで 200K トークンを超えるリクエストはエラーで弾かれます。本記事では、影響範囲・移行先・具体的な書き換え手順を整理します。
何が変わったか
| モデル | 変更前 | 変更後(2026-04-30 以降) |
|---|---|---|
| Claude Sonnet 4.5 | context-1m-2025-08-07 ベータヘッダで 1M tokens | 標準 200K のみ。1M context 不可 |
| Claude Sonnet 4 | 同上 | 標準 200K のみ。1M context 不可 |
| Claude Sonnet 4.6 | 1M tokens(ヘッダ不要、GA) | 変更なし |
| Claude Opus 4.6 / 4.7 | 1M tokens(ヘッダ不要、GA) | 変更なし |
つまり、Sonnet 4.5 / 4 系で 1M context を使うルートが完全に閉じたということです。
影響を受ける典型ケース
- ベータヘッダ
context-1m-2025-08-07を含むリクエストを Sonnet 4.5 や Sonnet 4 に送っているコード - 200K を超える input(長いログ・大量ドキュメント・ベクトルストアの全件)を Sonnet 4.5 で扱っていた既存統合
- リファレンス実装をコピペで持ってきて、モデル ID だけ変えた古いサンプル
400 が返り始めて気付くケースが多いはずなので、本日以降にエラーが急増していたら最初に疑うのはここです。
移行先の選択
公式の推奨は Claude Sonnet 4.6 への切り替えです。1M context が GA(ベータヘッダ不要)、標準価格で利用できます。
| 候補 | context | 用途の目安 |
|---|---|---|
Claude Sonnet 4.6(claude-sonnet-4-6) | 1M tokens | 速度とコストを保ちつつ 1M を使いたい場合の第一選択 |
Claude Opus 4.7 / 4.6(claude-opus-4-7 / claude-opus-4-6) | 1M tokens | 知性最優先、エージェント的タスク |
Claude Sonnet 4.5(claude-sonnet-4-5) | 200K | 1M が不要な既存ワークロードならそのまま |
価格(2026-04 時点):
- Sonnet 4.6: $3 / $15 per 1M input/output tokens
- Sonnet 4.5: $3 / $15 per 1M input/output tokens(同じ)
つまり価格は据え置きで context だけ広がる形になるので、1M を実際に使っていたなら 4.6 への切り替えはそのまま得です。
書き換え手順
1. ベータヘッダを削除し、モデル ID を更新
// Before
const response = await client.messages.create({
model: "claude-sonnet-4-5",
// ↓ 4/30 から無効。送ると 1M リクエストはエラーで弾かれる
betas: ["context-1m-2025-08-07"],
max_tokens: 32_000,
messages: [...],
});
// After
const response = await client.messages.create({
model: "claude-sonnet-4-6", // ← GA、ヘッダ不要で 1M
max_tokens: 32_000,
messages: [...],
});betas を完全に外します。client.beta.messages.create ではなく client.messages.create を使う点に注意(他の beta 機能と併用していないなら)。Compaction や Task Budgets など他の beta が必要な場合は client.beta.messages.create を維持し、betas 配列から context-1m-2025-08-07 だけ取り除きます。
2. リクエスト調整 — 200K 超のときだけ 4.6 にルート
短いリクエストまで強制的に 4.6 に寄せる必要はありません。input 推定で分岐するハイブリッド構成が経済的です。
async function ask(messages: Anthropic.MessageParam[]) {
// input トークンの粗い見積もり (本番なら client.messages.countTokens を使う)
const approxInput = JSON.stringify(messages).length / 4;
const model =
approxInput > 180_000 ? "claude-sonnet-4-6" : "claude-sonnet-4-5";
return client.messages.create({
model,
max_tokens: 8_000,
messages,
});
}価格が同じであれば常時 4.6 でも構いません。ただし 4.6 はメモリ常駐の挙動が 4.5 と微妙に違うので、乗り換え後は eval を 1 回通すのが定石です。
3. プロンプトキャッシュへの影響
モデル ID が変わると プロンプトキャッシュは別エントリになります(キャッシュはモデル単位)。本ブログ #8「プロンプトキャッシュ」でも触れたとおり、4.5 と 4.6 を同じ会話内で混ぜるとキャッシュが割れるので、長尺セッションは全体を 4.6 に統一するか、サブエージェントだけ 4.5 のままにする等の設計にします。
確認チェックリスト
- コードベース全体で
context-1m-2025-08-07を grep。残っていれば削除 -
claude-sonnet-4-5(claude-sonnet-4-5-20250929)とclaude-sonnet-4(claude-sonnet-4-20250514)で 200K を超えるリクエストを送る分岐を洗い出し、Sonnet 4.6 へ振り替え - CI / fixture / テストにもベータヘッダが残っていないか
- ダッシュボードのエラーレートを 1〜2 日見る(リタイア後の 400 急増は今回ヘッダが原因の可能性大)
- Sonnet 4.6 ベースで一度プロンプトキャッシュ・eval を回し直す
落とし穴
- 「うちは 200K 超えてないから関係ない」と決めつける — 添付ドキュメントが大きい日(月次レポートを丸ごと食わせる等)にピンポイントで弾かれるケースがある。リトライ含めて 400 をログから定期確認
- Sonnet 4.5 と 4.6 を混在運用 — 同セッションで両モデルを呼び分けると、プロンプトキャッシュが割れて inputトークンが想定外に積み上がる
- モデル ID をエイリアスで書く運用が無い — 本番投入の SaaS では
MODEL_IDを環境変数化しておくと、今回のような切り替えがデプロイなしで済む - 1M context が要らないのに 4.6 に乗り換える — 切り替え自体は無害だが、4.6 の挙動と 4.5 の挙動の差で eval スコアが変わるケースがある。移行後の品質確認は短くてもやる
まとめ
今回の変更は「ベータの卒業」というより「ベータの撤去」で、4/30 以降に既存統合がエラーを返し始める可能性のある実利的なリリースです。context-1m-2025-08-07 ヘッダを削り、モデル ID を claude-sonnet-4-6 に書き換える——基本的にはこれだけで対応が済みます。release notes タグで Anthropic のリリース情報を継続フォローしていきます。