メインコンテンツまでスキップ

Claude Sonnet 5：Claude Code の新しいデフォルト Agent モデル

· 約11分
Claude Dev
Claude Dev
Claude Dev

Anthropic は 2026 年 6 月 30 日に Claude Sonnet 5 を公開し、これまでで最も agentic な Sonnet モデル、そして Claude Free/Pro ユーザーの新しいデフォルトモデルとして位置づけました。

狙いは明確です。Sonnet 5 は、最近まで Opus-class モデルが必要だった多くの agentic work を、より安く、速く、広く使える層に持ち込みます。計画を立て、ブラウザやターミナルを使い、長い coding tasks を処理し、adaptive thinking をデフォルトで実行できます。

Claude Code ユーザーにとって、Sonnet 5 は通常のモデル更新以上に重要です。多くのチームにとって、デフォルトの実行レイヤーになる可能性があります。Anthropic の最強モデルではありませんが、開発者が最も頻繁に使うモデルになるでしょう。

ただしアップグレードに摩擦はあります。Sonnet 5 には新しい tokenizer があり、thinking と sampling parameters の API 挙動が変わり、real-time cyber safeguards があり、Opus より token 単価は安くても task 単位では常に安いとは限りません。

Anthropic が発表したもの​

Anthropic のローンチ記事は、Sonnet 5 を Sonnet 4.6 からの大きなアップグレードとして説明しています。reasoning、tool use、coding、knowledge work が向上し、Opus 4.8 との差を低価格で縮めるという位置づけです。

運用上の詳細が重要です。

  • Model ID：claude-sonnet-5
  • 利用可能範囲：Free/Pro のデフォルト、Max、Team、Enterprise、Claude Code、Claude Platform で利用可能
  • Context window：デフォルトかつ最大で 1M tokens
  • Max output：同期 Messages API では 128k tokens
  • 価格：2026 年 8 月 31 日まで launch pricing として input 100 万 tokens あたり 2 ドル、output 100 万 tokens あたり 10 ドル。その後は 3/15 ドル
  • Adaptive thinking：Claude Code と API でデフォルト有効
  • Cyber safeguards：real-time cybersecurity safeguards がデフォルト有効。Sonnet-tier では初

実務上の位置づけは、Sonnet 5 は Fable や Mythos を置き換えるものではなく、agentic work を日常化するためのモデルだということです。

良い反応：より多くの仕事を終わらせる​

公式パートナーのコメントと初期メディアテストに共通する強いポジティブな反応は、Sonnet 5 が prompt に答えるだけでなく、多段階の仕事を完了するのが上手いという点です。

Anthropic の early access partners は、sustained coding、debugging、conventions の遵守、brownfield code、tested pull-request completion での改善を述べています。有用なパターンは「より良い文章を書く」ではなく、「作業を続け、自分で確認し、少ない nudges で完成結果に到達する」です。

TechRadar の hands-on testing も coding 以外で似た結論に達しています。普通の chat では、Sonnet 5 は競合 assistant と劇的に違うわけではありません。しかし旅行計画や household budget tracker のように仕事を完了させる依頼では、Claude はより完了志向で整理されていました。

これは Claude Code にとって重要です。Sonnet 5 の最適な使いどころは one-turn snippets ではなく、次のような workflows です。

  • bug を調査し、reproducing test を書き、修正して検証する。
  • project conventions を保ったまま module を migrate する。
  • messy codebase を調査し、staged plan を作る。
  • terminal と browser tools を使って evidence を集める。
  • artifact を作り、修正し、output の一貫性を保つ。

ここで Sonnet 5 は日常の developer work において Sonnet 4.6 を上回るはずです。

Benchmarks：強くなったが、まだ Opus ではない​

公開報道は 2 つの有用な benchmark signal を繰り返しています。

TechRadar は、Anthropic の Terminal-bench 2.1 agentic coding score が Sonnet 5 で 80.5%、Sonnet 4.6 で **67%**だと報じています。ITPro は、SWE-bench Pro で Sonnet 5 が 63.2%、Sonnet 4.6 が 58.1%、Opus 4.8 が **69.2%**だと報じています。

形は明確です。

  • Sonnet 5 は Sonnet 4.6 からの実質的なアップグレード。
  • 最も難しい coding tasks では Opus 4.8 がまだ強い。
  • 高 effort では、一部 tasks で Sonnet 5 が Opus 4.8 に近づく、または匹敵する可能性がある。
  • 主な価値は absolute frontier quality ではなく cost-performance flexibility。

Anthropic の docs も、BrowseComp と OSWorld-Verified における effort levels ごとの cost-performance curves を強調しています。重要なのは単一の leaderboard number ではありません。チームが Opus に直行せず、Sonnet-class model で effort と cost を調整できるようになったことです。

隠れた移行コスト：Tokens が変わった​

最大の実装上の注意点は新しい tokenizer です。

Anthropic によると、同じ input text は Sonnet 5 では Sonnet 4.6 より約 30% 多く tokens を生成します。正確な増加は内容によります。API shape は変わりませんが、budgets は変わります。

影響するもの：

  • logs の token counts
  • prompt cache economics
  • max output limits
  • context-window planning
  • 等価 prompts の cost estimates
  • Sonnet 4.6 との eval comparisons

つまり launch pricing だけではコストを判断できません。標準の per-token pricing が 3/15 ドルのままでも、同じ workload がより多くの tokens を使う可能性があります。チームは cost-neutral だと仮定する前に、Sonnet 5 で prompts を再計測すべきです。

開発者が見落としてはいけない API 挙動​

Sonnet 5 は、deprecated または unsupported settings を使っていない場合に限り、drop-in replacement です。

docs は 3 つの変更を挙げています。

  1. Adaptive thinking がデフォルトで有効。Sonnet 4.6 では thinking field なしで thinking なし実行だった requests が、Sonnet 5 では adaptive thinking で実行されます。無効化するには thinking: {type: "disabled"} を渡します。
  2. Manual extended thinking は削除。thinking: {type: "enabled", budget_tokens: N} は 400 error を返します。代わりに adaptive thinking と effort parameter を使います。
  3. Sampling parameters は受け付けない。非デフォルトの temperature、top_p、top_k は 400 error を返します。system prompt instructions で挙動を誘導します。

Claude Code ユーザーにとって、model ID を切り替える前に古い wrappers や custom agent harnesses を監査すべきということです。client が stale parameters を送っていると、model upgrade は production bug になります。

Safety 反応：Sonnet 4.6 より良いが Opus ほどではない​

Anthropic は、Sonnet 5 は Sonnet 4.6 より hallucination と sycophancy が低く、agentic safety も向上したと述べています。malicious requests を拒否しやすく、prompt-injection-style hijacking にも強くなっています。

一方で同社は、automated behavioral audit において Sonnet 5 の misaligned behavior は Opus 4.8 や Claude Mythos Preview より高いとも述べています。

Cyber の話も具体的です。Sonnet 5 は cybersecurity work 向けに意図的に訓練されたわけではありません。routine で non-harmful な cyber tasks は可能ですが、dangerous cyber evaluations では Opus 4.8 や Mythos 5 よりかなり弱い。それでも Sonnet 4.6 より強いため、Anthropic は real-time cyber safeguards をデフォルトで有効にしてリリースしました。

Security teams への実務的な読み方：

  • 通常の engineering と routine defensive work には Sonnet 5 を使う。
  • prohibited または high-risk cyber prompts では refusals を想定する。
  • reduced guardrails が必要な cybersecurity work には、適切な access 付きの Opus 4.8 を使う。
  • refusals は HTTP 200 success として返ることがあるため、stop_reason: "refusal" を log する。

初期外部反応：デフォルトモデルこそが本題​

Axios は Sonnet 5 を、Opus、Fable、Mythos より低い risk profile を保ちつつ agentic AI を everyday work に持ち込む動きとして捉えました。これは正しい読み方です。

Sonnet 5 が重要なのは default を変えるからです。Free/Pro users、Claude Code users、platform developers がより agentic な Sonnet model を使えるなら、agent workflows は premium edge case ではなく通常の Claude experience になります。

リスクは、ユーザーが autonomy を過大評価することです。TechRadar の hands-on review は前向きでしたが、意思決定、確認、予約、upload、最終実行には人間の監督が必要だとも述べています。Sonnet 5 は finished work に近づきますが、review の代わりではありません。

このサイトでの有用な framing はシンプルです。

Sonnet 5 は everyday Claude Code automation で最初に試すべきモデルだが、盲目的に信頼すべきモデルではない。

Claude Code 採用チェックリスト​

1. Model ID を更新する​

テスト workloads を次から：

claude-sonnet-4-6

次へ移す：

claude-sonnet-5

まず branch または staging environment で行います。evals を replay せずに production default を切り替えてはいけません。

2. 古い API parameters を削除する​

codebase で検索します。

  • temperature
  • top_p
  • top_k
  • thinking: {type: "enabled"}
  • budget_tokens

非デフォルト sampling parameters を削除し、manual thinking controls を adaptive thinking + effort に移行します。

3. Tokens を再計算する​

Sonnet 4.6 の token budgets を再利用してはいけません。largest prompts、cached prefixes、typical Claude Code sessions を Sonnet 5 で再計測します。

特に注意するもの：

  • large repo summaries
  • generated plans
  • prompt に貼り付けた logs
  • long tool results
  • expected output length に近い max output settings

4. Effort を明示的に設定する​

最も安全な方針は、effort を task-level decision にすることです。

  • routine edits と explanations には medium
  • correctness が重要な通常の Claude Code tasks には high
  • hard debugging、migrations、long agent runs には xhigh

high effort を無料の品質向上と考えてはいけません。latency と token use が変わります。

5. Opus を routing mix に残す​

Sonnet 5 は多くの workflow の default になるべきですが、すべてではありません。

Opus 4.8 を残す場面：

  • high-risk refactors
  • security-sensitive reviews
  • ambiguous architecture decisions
  • missed edge case が高くつく tasks
  • large Sonnet-generated changes の final review

実務パターンは、Sonnet for execution、Opus for escalation です。

結論​

Claude Sonnet 5 は一見以上に大きなリリースです。より強い agentic behavior を、ほとんどのチームが毎日使うモデル層に移したからです。

新しい最上位 Claude model ではありません。新しい default workhorse です。

Claude Code ユーザーにとって正しい動きは、意図的な採用です。

  • 実際の tasks で Sonnet 4.6 と benchmark する。
  • 新 tokenizer に合わせて token budgets を再調整する。
  • unsupported API parameters を削除する。
  • effort-level cost を測る。
  • escalations 用に Opus 4.8 を残す。
  • logs で cyber-safeguard refusals を監視する。

Sonnet 4.6 が以前の practical baseline で、Opus 4.8 が power tool だったなら、Sonnet 5 はその power の一部を everyday workflow に戻す試みです。だからこそ、blind default switch ではなく careful migration が必要です。

参照した情報源​