Claude Sonnet 4.6 — 1Mトークンが「据え置き価格」でGAになった意味

Anthropicが静かに、しかし確実に主力モデルの重心を動かした。Claude Sonnet 4.6の1Mトークンコンテキストが正式にGA（一般提供）になり、しかも価格は$3/$15のまま据え置き。200Kを超えた部分に「long-context premium」を上乗せする従来の料金体系が、Sonnet 4.6とOpus 4.6では消えた。

地味に見えるが、この変更は「1Mコンテキストを試験的に使うもの」から「普通に使うもの」への転換点だ。

何が変わったか

まず事実関係を整理しておく。Sonnet 4.6はAnthropic公式が「最も有能なSonnet」と位置づける新モデルで、コーディング、コンピュータ操作、長文推論、エージェント計画、デザイン系タスクまで全面的に底上げされている。

項目	Sonnet 4.6	Opus 4.6
入力	$3 / 1Mトークン	$15 / 1Mトークン
出力	$15 / 1Mトークン	$75 / 1Mトークン
最大出力	64K	128K
コンテキスト	1M（GA、標準料金）	1M（GA、標準料金）
Adaptive Thinking	対応	対応

ポイントは2つ。1Mトークン全域で追加料金がかからないこと、そしてSonnetとOpusの価格差がそのまま「5倍」の選択肢として残っていることだ。Opus 4.6のほうが当然強いが、Sonnet 4.6は1/5のコストで同じコンテキスト窓を持つ。

「標準料金で1M」がなぜ効くのか

筆者が2ヶ月ほどOpus 4.6の1Mコンテキストを業務で使ってきた体感として、200Kの壁はかなりしんどい心理的ハードルだった。200Kを超えるとプレミアム料金（だいたい2倍）になるため、「このファイルも入れたいけどコストが跳ねるから削る」という判断が常につきまとう。結果、Claudeに本来の強みを発揮させる前にこちらが勝手にコンテキストを削ってしまう。

今回の変更で、Sonnet 4.6では「入れたいものを全部入れる」が現実的になった。たとえば、

• 50〜80ファイルのコードベース全体を一度に渡してリファクタリング計画を立てる
• 100〜200本の論文やリサーチノートを束ねて横断サマリを作る
• 長時間のミーティング文字起こしを数週間分まとめて分析する

こうしたタスクで「コンテキストを削らない判断」が素直にできるようになる。$3/$15という価格を考えると、これはもう「試験的に使う」レベルの話ではない。

Adaptive Thinkingが推奨モードに

もうひとつ実務で効く変更がadaptive thinkingだ。これまでthinking: {type: "enabled", budget_tokens: N}で思考予算を明示的に指定していた方式は、Sonnet 4.6では公式に非推奨となった。代わりにthinking: {type: "adaptive"}が推奨で、Claudeが問題の難易度に応じて「どこまで考えるか」を自動で判断する。

さらにeffortパラメータが正式GAになり、minimal / low / medium / high / maxの5段階でコスト-品質のバランスを制御できる。Sonnet 4.6ではmediumが無難なデフォルトで、複雑なタスクだけhighに上げる運用が想定されている。

個人的には、これは歓迎できる方向だ。budget_tokensで手動調整していた頃は、「50000トークンの思考予算って何トークン使うの？」と毎回確認する手間があった。adaptiveにしておけば、簡単なクエリには即答し、難しい問題には勝手に深く考えてくれる。思考深度の管理を人間が肩代わりする必要がなくなった。

Opus 4.6とどう使い分けるか

ここが今回最大の実務的問い。筆者の現時点の使い分けは次の通り。

Sonnet 4.6で十分な場面

• 中規模（数千〜数万行）のコード生成・リファクタ
• 長文の要約・分析
• UI実装・フロントエンド系タスク
• 日常的な調査・まとめ作業

Opus 4.6を呼び出す場面

• SWE-bench上位が意味を持つような難解なバグ調査
• 複数サービス横断のアーキテクチャ設計
• 長時間の自律エージェント稼働（エージェントチーム連携）
• 100K超の出力が必要な大規模ドキュメント生成

実務では8割以上の作業がSonnet 4.6で済む感覚がある。1/5の価格で「Opusの8〜9割」の品質が出るなら、デフォルトをSonnetにしてOpusは指名買いするのが正解だろう。ちなみにclaude.aiとClaude CoworkではFreeプラン・Proプランの既定モデルがすでにSonnet 4.6に切り替わっている。

1Mコンテキストが開く3つの「それもできるのか」

ここからは、1Mコンテキストが標準料金になったことで新たに現実的になるユースケースを3つだけ挙げておきたい。

1. 「プロジェクト全部読んで」が成立する

中規模のGitHubリポジトリ（数百ファイル・総行数で数万行クラス）なら、.gitやnode_modulesを除外したソース一式を丸ごと渡せる。筆者はこれを「プロジェクト総括モード」と呼んでいて、新しいコードベースを引き継いだ時の最初の一歩が激変する。「このプロジェクトで一番リスクの高いファイルはどれか」「このAPIのテストカバレッジの穴はどこか」といった質問に、実際のコード全体を見た上で答えてくれる。

2. 長期プロジェクトの「記憶係」になる

過去半年分のPR説明、議事録、Slackログ、設計ドキュメントを1つのコンテキストに詰め込んで「この機能の経緯を教えて」と聞ける。これは検索や要約ではなく、推論が効く「長期記憶係」だ。チームの文脈を人間の記憶に頼らなくてよくなる。

3. リサーチ論文のメタ分析が家庭用コストになる

論文100〜200本をまとめて投入して「この分野の主要な対立軸を3つ挙げて」と聞けるようになる。これまではRAGを組むかOpusにプレミアム料金を払うかだったが、$3/$15なら個人研究者でも普通に回せる水準だ。

微妙な点・懸念

良いことばかり書いたので、正直な気になる点も並べる。

まず、1Mをフルに使うと当然遅い。 入力100万トークンを処理するのはどれだけ高速なインフラでも数分かかる。インタラクティブな用途では現実的ではなく、バッチ的な使い方になる。

出力64Kの制約はSonnetならでは。 Opusの128Kと比べると、生成系タスク（長文ドキュメント作成、大規模コード生成）ではSonnetが先に上限にぶつかる。この点はOpusを指名する理由のひとつになる。

そして、1Mに何でも突っ込めばいいわけではない。 コンテキストが長くなるほど、モデルが本当に必要な情報に注目しづらくなる「lost in the middle」問題は、完全には解消されていない。1Mはあくまで「必要なら入れられる」であって、「毎回全部入れる」ではない。コンテキストエンジニアリングの感覚は依然として必要だ。

manual extended thinkingの非推奨化は、既存コードのマイグレーションが必要になる。 budget_tokensベースの実装を持っている人は、adaptiveへの書き換えが発生する。そこまで大変な作業ではないが、本番コードでは動作確認が必要になる。

まとめ

Sonnet 4.6そのものの性能アップよりも、「1Mコンテキストが標準料金でGA」という料金モデルの変更のほうが実務的には大きい。これまでOpusでしか現実的でなかった長コンテキスト運用が、Sonnet価格で回せるようになった。

Claudeを使っている開発チームは、まずデフォルトモデルをSonnet 4.6に切り替え、effort: medium + adaptive thinkingで運用を始めるのがおすすめだ。Opusはここぞの時に指名する「エース」に置いておけばいい。Opus 4.6を使い込んできた立場からも、今回のSonnet 4.6は「Opusの廉価版」ではなく「日常使いの主力」として十分な完成度に達している。

合わせて読みたい: Claude Opus 4.6を1ヶ月使った所感 — 100万トークンとエージェントチームの実力

Claude公式サイト