「Claude Codeを使い始めたけど、新しいモデルが出るたびに何が変わったのかよくわからない」「Sonnet 4.6って結局アップデートする価値あるの？」——そんな疑問を持っている方に向けて、この記事を書きました。
2026年2月17日にリリースされたClaude Sonnet 4.6は、正直に言って「マイナーアップデート」だと思っていた僕の認識を完全にひっくり返してくれました。Opus級のベンチマーク性能がSonnet価格で手に入り、100万トークンのコンテキストウィンドウやCompaction APIによる無限会話まで実現しています。
僕はMac mini M4 Proで24時間AIエージェントシステムを運用しながら、日常的にClaude Codeで開発をしている福祉事業のCTOです。この記事では、実際にSonnet 4.6を使い込んだ体験をベースに、数字の裏にある「本当に変わったこと」と「今日から使える実践テクニック」をお伝えします。
Claude Sonnet 4.6の全貌 — 数字で見る「Opus級Sonnet」の衝撃
まず、Sonnet 4.6のベンチマークを見てください。正直、最初に数字を見たときは二度見しました。
主要ベンチマーク比較:
- SWE-bench Verified（コード修正能力）: Sonnet 4.6 = 79.6% / Opus 4.6 = 80.8% / GPT-5.2 ≈ 78%
- OSWorld-Verified（PC操作能力）: Sonnet 4.6 = 72.5% / Opus 4.6 = 72.7%
- ARC-AGI-2（推論能力）: Sonnet 4.6 = 60.4%（Sonnet 4.5は約13.6%）
- Math（数学）: Sonnet 4.6 = 89%（Sonnet 4.5は62%、+27ポイント）
注目してほしいのは、SWE-benchでOpus 4.6との差がわずか1.2ポイントしかないことです。つまり、コードの修正能力に関しては、Sonnetクラスなのにほぼ最上位モデルと同等の実力を持っています。
しかも価格は入力$3/出力$15（100万トークンあたり）で据え置き。Opus 4.6は入力$5/出力$25ですから、約60%のコストで95%以上の性能が手に入る計算です。
もうひとつ面白いデータがあります。Anthropicの調査では、開発者の70%がSonnet 4.5よりSonnet 4.6を選好し、さらに59%がOpus 4.5よりもSonnet 4.6を選んだそうです。前世代の最上位モデルより、新世代の中位モデルのほうが好まれるって、すごい時代ですよね。
GitHubのVPであるJoe Binder氏も「複雑なコード修正に優れ、大規模コードベース検索で強い一貫性を発揮する」と評価しており、GitHubのFree/ProプランではデフォルトモデルがSonnet 4.6に即日変更されました。
エージェント的タスクでの判断力も大幅向上
ベンチマークだけだと「テストが上手なだけでは？」と思うかもしれませんが、Vending-Bench Arenaという長期的な計画能力を測るテストでも面白い結果が出ています。Sonnet 4.6は$5,700の利益を出した一方、Sonnet 4.5は$2,100。約3倍の差です。
イメージとしては、「言われたことをやるだけ」から「先を読んで最適な判断ができる」ように進化した感じです。これはClaude Codeでの開発体験にもダイレクトに影響していて、タスクの分解や優先順位付けが明らかに賢くなっています。
100万トークンコンテキストで変わるClaude Code開発体験
個人的に一番インパクトが大きいのは、100万トークンのコンテキストウィンドウ（ベータ）です。
100万トークンって具体的にどのくらいかというと、約75万語・1,500ページ・30,000行のコードを一度に読み込めます。これまでのSonnetクラスは200Kトークンが標準だったので、5倍に拡大したことになります。
モノレポ全体をコンテキストに入れられる世界
僕が運用しているAIエージェントシステムはnpm workspacesのモノレポ構成で、agent-core、MCPサーバー、Discord Bot、ダッシュボードAPI/UIなど複数パッケージがあります。これまでは「このパッケージのこのファイルだけ見て」と範囲を絞る必要がありましたが、Sonnet 4.6ならモノレポ全体をコンテキストに入れて横断的に分析してもらうことが現実的になりました。
たとえば「MCPサーバーのツール定義とDiscord Botのツール呼び出し部分の整合性をチェックして」というリクエスト。以前はファイルを個別に読み込ませて、何往復もする必要がありました。今は関連ファイルをまとめて渡せるので、一発で矛盾やバグを見つけてくれます。
注意点: 200Kトークン超はプレミアム価格
ただし、100万トークンはベータ機能で、200Kトークンを超える部分にはプレミアム価格が自動適用されます。Claude MAXのサブスクリプション範囲で使う分にはあまり気にならないかもしれませんが、API経由で使う場合はコストに注意してください。
また、最大出力トークンもSonnet 4.6では64K（従来の2倍）に増えています。大規模なコード生成やリファクタリングの指示が途中で切れにくくなったのは、地味に助かるポイントです。
Compaction APIで「無限会話」— 長時間セッションの実践テクニック
Claude Codeを長時間使っていると、必ずぶつかる壁があります。コンテキストウィンドウの上限です。
たとえば、機能設計→実装→テスト→デバッグを一つのセッションでやろうとすると、途中で「コンテキストが足りなくなりました」と言われて、それまでの文脈がリセットされてしまう。僕自身、「計画と実装は別セッションに分ける」というルールを運用してきましたが、それでも面倒でした。
この問題を根本的に解決するのが、Sonnet 4.6と同時に導入されたCompaction API（ベータ）です。
Compaction APIの仕組み
仕組みはシンプルです。会話がコンテキスト上限に近づくと、サーバーサイドで自動的に会話内容を要約してくれます。重要な情報は保持しつつ、冗長な部分を圧縮することで、事実上無限に会話を続けられるようになります。
APIでの実装はこんな感じです:
// Compaction APIの基本設定
const response = await client.messages.create({
model: 'claude-sonnet-4-6-20260217',
context_management: {
edits: [{
type: 'compact_20260112',
trigger: {
type: 'input_tokens',
value: 100000 // 10万トークンでCompaction発動
}
}]
},
messages: conversationHistory
});
デフォルトのトリガー閾値は150,000トークンで、最小50,000トークンまで下げられます。Claude Codeのauto-compact機能はv2.0.64以降で対応しており、設定すれば瞬時に動作します。
実践的なトークン予算管理
長時間セッションではトークンのコスト管理も大事です。Compactionが何回発生したかをカウントして、累計消費量を推定するパターンが使えます:
// トークン予算の管理例
const totalConsumed = nCompactions * TRIGGER_THRESHOLD;
if (totalConsumed > TOTAL_TOKEN_BUDGET) {
// セッションのまとめに入る
console.log('予算上限に近づいています。作業をまとめましょう');
}
また、System PromptにPrompt Cachingを設定しておくと、Compactionが発生してもシステムプロンプトのキャッシュは維持されるので、コストを抑えつつ一貫した指示を保てます。
Adaptive ThinkingとEffortパラメータでコストを最適化する
Sonnet 4.6では、Adaptive Thinkingが推奨モードに変更されました。これまではbudget_tokensで「思考にどれだけトークンを使わせるか」を手動で指定していましたが、その方法は非推奨になっています。
新しい呼び出し方
// Adaptive Thinking（推奨）
const response = await client.messages.create({
model: 'claude-sonnet-4-6-20260217',
thinking: { type: 'adaptive' }, // AIが自動で思考量を調整
output_config: { effort: 'medium' }, // コスト・品質のバランス
messages: [{ role: 'user', content: 'このコードをリファクタリングして' }]
});
effortパラメータはmax/high/medium/lowの4段階です。イメージとしては:
- max: 「じっくり考えて最善の回答を出して」（複雑なアーキテクチャ設計向き）
- high: 「しっかり考えてほしいけど、時間もほどほどに」（通常の開発タスク）
- medium: 「バランス重視で」（日常のコーディング）
- low: 「簡単なことだからサクッと答えて」（定型作業・テンプレ生成）
これの何が嬉しいかというと、タスクの難易度に応じてコストを自動調整できる点です。簡単な質問に対してまで延々と思考トークンを消費する、ということがなくなります。
output_configへの移行
ちなみに、従来のoutput_formatパラメータもoutput_config.formatに移行しています。既存のコードを使っている方は、このタイミングで書き換えておくのがおすすめです。小さな変更ですが、放置しておくと将来のバージョンで動かなくなる可能性があります。
移行時の注意点 — Prefill廃止・Breaking Changeへの対応
新機能の話ばかりしてきましたが、Sonnet 4.6への移行で注意すべきBreaking Changeもあります。特に重要なのがPrefillの廃止です。
Prefill（事前入力）が使えなくなった
Prefillとは、アシスタントメッセージの冒頭を事前に入力しておくことで、出力フォーマットを制御するテクニックでした。たとえば：
// 以前のPrefillパターン（Opus 4.6では非サポート）
messages: [
{ role: 'user', content: 'JSONで返して' },
{ role: 'assistant', content: '{' } // これがPrefill
]
このパターンはOpus 4.6で非サポートになりました。Sonnet 4.6でも将来的に廃止される可能性があるので、今のうちに代替手段に切り替えておくのがおすすめです。
代替方法としては：
- Structured Outputs: JSONスキーマを指定して、出力形式を強制する
- System Prompt: 出力フォーマットをシステムプロンプトで明確に指示する
Structured Outputsのほうが確実ですが、System Promptでの指示でもSonnet 4.6なら十分正確に従ってくれます。
その他の変更点まとめ
- 知識カットオフ: Sonnet 4.6は2025年8月、Opus 4.6は2025年5月
- Web Search + Code Executionの無料化: Dynamic Filteringで検索結果をコード実行でフィルタリングできるようになり、コンテキスト消費を削減
- output_format → output_config.format: 非推奨パラメータの移行が必要
この情報を知らないまま開発を続けるリスク
Sonnet 4.6の新機能を知らないまま旧モデルで開発を続けていると、いくつかの「もったいないこと」が起きます。
まず、コンテキスト上限のせいでセッションを何度も分割する手間が続きます。Compaction APIを使えば解消できる問題に、毎日30分以上のロスが発生しているかもしれません。また、Adaptive Thinkingを知らないと、簡単なタスクにも高コストの思考トークンを消費し続けることになります。
AIコーディングツールは日進月歩で、「先週のベストプラクティスが今週は非推奨」ということが普通に起きます。Prefillの廃止のように、知らずに使い続けて突然動かなくなるリスクもあります。情報をキャッチアップする習慣が、開発効率に直結する時代です。
この記事を書いている理由
僕自身、Mac mini M4 Proで24時間AIエージェントシステムを動かしながら、毎日Claude Codeと向き合っています。モノレポでMCPサーバー、Discord Bot、ダッシュボードを構築してきた中で、コンテキスト上限の壁には何度もぶつかりました。
「計画と実装を同じセッションでやると中途半端になる」——これは実際に痛い目を見て学んだ教訓です。だからこそ、Compaction APIや100万トークンコンテキストの登場は、僕にとって「やっときた！」という感覚でした。
550名以上のキャリア面談をしてきた経験から、「情報を知ってるか知らないかで全然変わる」ということを強く実感しています。AIコーディングツールの進化スピードが速いからこそ、実際に使い込んだ人間の声が大事だと思って、この記事を書いています。
まとめ — 次のアクション
Claude Sonnet 4.6は、Opus級の性能をSonnet価格で手に入れられる、現時点でのコスパ最強モデルです。特に100万トークンコンテキストとCompaction APIの組み合わせは、Claude Codeでの開発体験を根本から変えてくれます。
まずは今日から試してほしいことが3つあります:
- Claude Codeのモデルをsonnet-4-6に切り替える（設定一つで変更可能）
- auto-compactを有効にする（v2.0.64以降で対応）
- effortパラメータを意識する（APIを使っている場合）
この記事が参考になったら、X（旧Twitter）でのシェアやコメントをいただけると嬉しいです。Claude Codeの活用Tipsは今後も発信していくので、ぜひフォローしてください。
