Anthropicが2026年6月30日にClaude Sonnet 5を発表しました。Claude CodeやAPIでClaudeを使っているエンジニアにとって、今回の更新は「性能が上がったらしい」で済ませるよりも、移行時の挙動変更とコスト感を先に押さえたほうがよさそうです。
特に気になったのは、Claude Sonnet 5がClaude Sonnet 4.6の「差し替え候補」として位置づけられている一方で、APIの使い方にはいくつか注意点があることです。モデルIDを変えるだけで動くケースもありますが、temperatureなどのサンプリング指定、手動のextended thinking、トークン数の見積もりをそのまま持ち越すと、想定外のエラーやコスト増につながる可能性があります。
この記事では、2026年7月1日時点で公式ドキュメントと報道から確認できること、不明確なこと、Claude Sonnet 4.6・Opus 4.8・Haiku 4.5・Fable 5との比較、そしてSE実務やClaude Code運用でまず試したいことを整理します。
先に結論：Sonnet 5は「日常的な実務エージェント向け」の本命候補
現時点の結論として、Claude Sonnet 5は、最上位の研究用・高自律エージェント向けモデルというより、日常的な開発・調査・コード修正・長文処理を任せるための実用モデルとして見るのが自然です。
Anthropicのモデル概要では、Claude Sonnet 5は「速度と知能の組み合わせが最もよいモデル」と説明されています。Claude Opus 4.8はより複雑な推論や長期のエージェント作業向け、Claude Haiku 4.5は低コスト・低遅延向け、Claude Fable 5は広く公開されている中では最も高性能なモデルという位置づけです。つまり、Sonnet 5は「毎日の開発作業に使いやすい中核モデル」として出てきたと考えると理解しやすいです。
ただし、今回の発表で一番大事なのは、性能比較の数字だけではありません。Claude Sonnet 5では、adaptive thinkingがデフォルトで有効になり、手動extended thinkingが削除され、temperature・top_p・top_kの非デフォルト指定が受け付けられなくなりました。加えて、新しいトークナイザーによって、同じ文章でもClaude Sonnet 4.6より約30%多くトークン化される可能性があります。
このため、Claude Codeや自作スクリプト、業務フローの自動化でClaude APIを使っている場合は、「モデルIDだけ変えて終わり」ではなく、プロンプト設計・出力上限・料金見積もり・エラーハンドリングを一度見直したほうがよいです。
Claude Sonnet 5で分かっていること
まず、公式情報から確認できる点を整理します。
APIモデルIDは claude-sonnet-5
Claude Sonnet 5のAPIモデルIDは claude-sonnet-5 です。Anthropicの移行ガイドでは、Claude Sonnet 4.6からの置き換え例として、claude-sonnet-4-6 から claude-sonnet-5 へ変更する形が示されています。
Claude Sonnet 4.6から見た場合、AnthropicはSonnet 5をdrop-in upgrade、つまり差し替えアップグレードとして扱っています。ただし、これは「完全に同じ挙動」という意味ではありません。後述する3つの挙動変更があるため、APIパラメータを細かく指定しているプロジェクトほど確認が必要です。
1Mトークンのコンテキストウィンドウが標準
Claude Sonnet 5は、1Mトークンのコンテキストウィンドウを標準でサポートします。公式ドキュメントでは、1Mトークンがデフォルトであり最大値でもあり、小さいコンテキスト版はないと説明されています。最大出力は128kトークンです。
これは、ソースコード一式、長い仕様書、過去の議事録、業務運用ログのような長文コンテキストを扱ううえで大きな意味があります。たとえば、Claude Codeで大きめのリポジトリを読ませてリファクタリング方針を作る、
一方で、1Mトークンだから何でも詰め込めばよい、とは考えないほうがよいです。新しいトークナイザーの影響で、同じテキストでもSonnet 4.6より多くトークン化される可能性があります。実務では、コンテキストを増やせることよりも、必要な情報をどこまで絞るかの設計が引き続き重要になります。
adaptive thinkingがデフォルトで有効
Claude Sonnet 5では、adaptive thinkingがデフォルトで有効になります。Claude Sonnet 4.6では、thinkingフィールドを指定しないリクエストはthinkingなしで動いていましたが、Sonnet 5では同じリクエストでもadaptive thinkingが使われます。
これは、複雑なタスクではありがたい変更です。コードの原因調査、複数ファイルにまたがる修正、エラー再現、仕様の読み解き、ブログ記事の構成整理のような作業では、モデルが必要に応じて考える量を調整してくれるほうが安定しやすい可能性があります。
ただし、max_tokensはthinkingと最終出力を含む合計の上限として効きます。Sonnet 4.6でthinkingなしを前提にしていた処理をそのまま移すと、最終出力が短くなったり、途中で切れたりする可能性があります。Claude APIを使った長文ドキュメント生成やコードレビュー支援では、出力上限を再調整する必要が出そうです。
サンプリングパラメータの非デフォルト指定は400エラー
Claude Sonnet 5では、temperature、top_p、top_kを非デフォルト値にすると400エラーになります。これはAPI利用者にとってかなり実務的な変更です。
従来、記事作成なら少し柔らかめに、コード修正なら低temperatureで、というようにサンプリングパラメータを分けていた人も多いはずです。しかしSonnet 5では、その方向の制御は基本的にシステムプロンプトや指示文で行う必要があります。
パラメータで雑に制御するのではなく、「どの作業では、何を優先して、何を避けるのか」をプロンプトとワークフロー側に明示する必要があります。
手動extended thinkingは削除
Claude Sonnet 5では、手動extended thinking、つまり thinking: {type: "enabled", budget_tokens: N} のような指定が削除されました。Sonnet 4.6では非推奨でしたが、Sonnet 5では400エラーになります。代わりにadaptive thinkingとeffortパラメータを使う流れです。
Claude CodeやAPIラッパーでthinking budgetを明示していた場合は、ここが移行時の引っかかりどころです。単純なモデルID変更だけでは動かない可能性があります。とくに、社内ツールや個人の自動化スクリプトで「長考モード」を固定している場合は、早めに設定を確認したほうがよいです。
新しいトークナイザーで同じ文章が約30%多くトークン化される
Anthropicは、Claude Sonnet 5では新しいトークナイザーを使い、同じ入力テキストがClaude Sonnet 4.6より約30%多くトークン化されると説明しています。これは見逃しやすいですが、料金とコンテキスト設計にかなり効きます。
たとえば、入力単価が同じでも、同じ文章がより多くのトークンに分割されれば、同等リクエストの費用は変わります。また、1Mトークンのコンテキストがあっても、1トークンあたりに入る文字量が変わるため、「テキスト量としてどれくらい入るか」はSonnet 4.6と同じではありません。
Claude Free/Proのデフォルトモデルになったとの報道
Axiosは、Claude Sonnet 5がClaude FreeとProユーザーのデフォルトモデルになり、Max、Team、Enterpriseでも利用できると報じています。また、AnthropicがSonnet 5を日常業務向けのagentic AIモデルとして位置づけていること、OpusやMythosより危険なサイバー能力のリスクが低いと説明していることも報じています。
ただし、この記事では公式ドキュメントで確認できるAPI仕様を軸に扱います。利用プランごとの表示やデフォルト設定は、Claudeアプリ側で変わる可能性があるため、実際に使う画面や契約プランで確認するのが安全です。
まだ不明確なこと
発表直後なので、分かっていることと同じくらい、不明確なことを分けておく必要があります。
実務リポジトリでの体感差
公式ドキュメントでは、Claude Sonnet 5はSonnet 4.6より能力が向上し、特にcodingとagentic tasksで大きな改善があると説明されています。ただし、実際の業務リポジトリでどれくらい差が出るかは、まだ自分の手元で検証できていません。
コード生成ベンチマークで良くても、実務では「既存設計に合わせる」「テストを壊さない」「ユーザーの意図しない修正を避ける」「長い運用ルールを守る」といった別の能力が必要になります。Claude Codeで使う場合は、単発の実装力だけでなく、差分の小ささ、確認手順の丁寧さ、危ない操作を避けるか、という観点で見るべきです。
日本語長文でのトークン増加率
公式には「同じテキストが約30%多くトークン化される」と説明されていますが、日本語ブログ記事、Markdown、HTML、コード、ログファイルでどの程度増えるかは、実データで測る必要があります。
Claude Codeでのデフォルト挙動の細部
Anthropicのモデル概要では、Claude Sonnet 5のeffortはClaude APIとClaude Codeでデフォルトがhighとされています。これは、複雑な作業には有利に働く可能性があります。一方で、短い修正や軽い相談でも常にhigh相当で動くなら、待ち時間やコスト感がどうなるかは実測したいです。
Claude Codeでのモデル選択、途中のツール使用、ファイル編集の慎重さ、テスト実行の提案の仕方がSonnet 4.6とどう変わるかは、実際に触らないと分かりません。ここは今後、同じタスクをSonnet 4.6とSonnet 5に投げて比較する価値があります。
他社モデルとの直接比較
GPT系、Gemini系、Grok系など他社モデルとの比較も気になるところですが、現時点では公式の同一条件ベンチマークだけで単純に優劣を決めるのは難しいです。
Claude Sonnet 5と他のClaudeモデルの比較
公式ドキュメントをもとに、主要モデルを実務目線で整理すると次のようになります。
| モデル | 位置づけ | 入力/出力単価 | コンテキスト | 最大出力 | 向いていそうな用途 |
|---|---|---|---|---|---|
| Claude Sonnet 5 | 速度と知能のバランス型 | $3 / $15 per MTok（2026年8月31日までは$2 / $10） | 1M tokens | 128k tokens | Claude Code、日常的な開発、長文調査、業務運用自動化 |
| Claude Opus 4.8 | 複雑な推論・長期エージェント作業向け | $5 / $25 per MTok | 1M tokens | 128k tokens | 難しい設計判断、大規模リファクタリング、高自律タスク |
| Claude Haiku 4.5 | 低遅延・低コスト型 | $1 / $5 per MTok | 200k tokens | 64k tokens | 軽い分類、要約、問い合わせ対応、並列サブエージェント |
| Claude Fable 5 | 広く公開されている中で最も高性能 | $10 / $50 per MTok | 1M tokens | 128k tokens | 最も難しい推論、長期エージェント、高価でも精度を優先する作業 |
この表から見ると、Claude Sonnet 5は「Opusほど高くないが、Haikuより強い」場所を狙ったモデルです。Claude Codeで毎日使うなら、まずSonnet 5を標準にして、難しい設計判断や詰まった不具合だけOpus 4.8やFable 5に上げる、という使い分けが現実的だと思います。
Claude Sonnet 4.6から見ると、Sonnet 5は価格体系が基本的に同じで、導入初期は2026年8月31日まで割引価格が設定されています。ただし、新トークナイザーでトークン数が増える可能性があるため、単純に「同じ価格だから同じコスト」とは言えません。ここは記事作成やコードレビューなど、自分の代表的なプロンプトで実測したほうがよいです。
SE実務で気をつけたい移行ポイント
Claude Sonnet 5を実務に入れるなら、まず以下の4点を確認したいです。
1. APIラッパーからサンプリング指定を外す
自作のAPIラッパーや既存ツールで、temperature、top_p、top_kを指定している場合は、Sonnet 5で400エラーになる可能性があります。モデルIDを切り替える前に、リクエスト生成部分を確認しておくべきです。
業務運用スクリプトの場合、記事本文、SNS文案、要約、タグ生成でパラメータを変えていることがあります。Sonnet 5に移すなら、パラメータ分岐ではなく、システムメッセージやタスク別プロンプトで文体や制約を分ける設計に寄せる必要があります。
2. thinking budget指定をadaptive thinkingへ寄せる
手動extended thinkingを使っていた場合は、Sonnet 5ではそのまま動きません。thinking: {type: "adaptive"}やeffortの使い方を確認し、タスクごとにどの程度の思考量が必要かを再設計する必要があります。
Claude Codeの場合も、短い修正と長い調査を同じ設定で走らせると、待ち時間や出力量が合わない可能性があります。軽いタスク、通常の実装、重い調査の3段階くらいで運用を分けるとよさそうです。
3. max_tokensを再調整する
Sonnet 5ではadaptive thinkingがデフォルトで入り、さらに新トークナイザーで同じテキストのトークン数が増えます。Sonnet 4.6でギリギリに設定していたmax_tokensは、Sonnet 5では不足するかもしれません。
最初は余裕を持った上限にし、実測値をログに残しながら詰めるほうが安全です。
4. セーフティ拒否の扱いをエラーと分ける
Claude Sonnet 5にはリアルタイムのサイバーセキュリティ保護が入っており、禁止または高リスクなサイバー関連リクエストは拒否される場合があります。この拒否はHTTP 200で返り、stop_reason: "refusal"になると説明されています。
これは開発者にとって重要です。APIエラーではないため、単にHTTPステータスだけ見て「成功」と扱うと、実際には必要な出力が得られていないケースを見落とします。コードレビュー支援やセキュリティ診断補助に使う場合は、stop_reasonや本文の拒否内容を見て、人間に確認を促す処理が必要です。
Claude Codeで試したい実験
今回のSonnet 5は、Claude Codeとの相性を実際に試してみたいモデルです。試すなら、公開操作や外部送信ではなく、レビューしやすい代表タスクから始めるのが現実的です。
実験1：同じバグ修正をSonnet 4.6とSonnet 5で比較する
小さめのバグ修正タスクを用意して、Sonnet 4.6とSonnet 5で同じ依頼を投げます。見るべきポイントは、修正の正しさだけではありません。
- 関係ないファイルを触らないか
- 既存の設計に合わせているか
- テスト実行や確認手順を提案するか
- 不明点を勝手に決めずに確認するか
- 差分が読みやすいか
AIコーディングエージェントの実務価値は、単にコードを書けることではなく、レビューしやすく、戻しやすく、運用ルールを壊さないことにあります。
実験2：長いプロジェクトルールを読み込ませたドキュメント更新
AGENTS.md、コーディング規約、レビュー方針、リリース手順、セキュリティ注意事項がある環境では、長いコンテキストを正しく守れるかが重要です。
Sonnet 5の1Mコンテキストを使い、ルール一式を読ませたうえで、README更新、PR説明文、テスト観点、リリース前チェックリストを作らせる実験は相性がよさそうです。確認ポイントは、本番反映禁止、秘密情報の扱い、外部送信の停止線、医療・税金のような高リスク表現の断定回避などのルールを守れるかです。
実験3：トークン数とコストの実測
同じ日本語ドキュメント、同じコード差分、同じ仕様メモをSonnet 4.6とSonnet 5でtoken countingし、どれくらい差が出るかを測ります。公式には約30%増えるとされていますが、自分の文章で測らないと運用コストは見えません。
業務フローの自動化では、毎回のコストは小さく見えても、毎日積み上げると無視できません。Sonnet 5に移行するなら、長文をそのまま投げる設計から、要約キャッシュや作業ブリーフを使う設計へ寄せる価値があります。
収益化導線を入れるならどこが自然か
この記事では、無理に商品紹介へ寄せる必要はありません。自然に入れるなら、Claude CodeやAIコーディングエージェントを使うための開発環境、API検証用のクラウド、開発環境や検証環境に必要なクラウドサービス、エンジニア向け案件サービスあたりです。
ただし、発表直後の記事で「このモデルを使えば稼げる」といった表現は避けるべきです。現実的には、AIモデルの更新は収益化の近道というより、作業時間の使い方を変える要素です。コードレビューの下準備、ブログ下書き、仕様メモの整理を任せられる範囲が広がれば、空いた時間を検証や営業、記事品質の改善に回せる可能性があります。
現時点での見方：すぐ全面移行ではなく、代表タスクで検証する
Claude Sonnet 5はかなり魅力的な更新ですが、実務ではいきなり全面移行するより、代表タスクで検証するほうが安全です。
まずは、Claude Codeで小さめの修正、APIで長文要約、長文ドキュメントの構成作成、レビュー用HTML生成のようなタスクを選び、Sonnet 4.6とSonnet 5で比較します。そのうえで、エラー率、出力品質、トークン数、レビュー時間を見ます。
特に自動化スクリプトでは、400エラーになるパラメータ、max_tokens不足、stop_reason: "refusal"の扱いを先に潰しておくべきです。AIモデルのアップデートは便利ですが、運用側のガードレールが弱いと、便利さより手戻りが増えることがあります。
小さな開発チームとしては、Sonnet 5を「最新モデルすごい」で終わらせず、Claude Codeでの実装タスク、長文ドキュメント作成、プロジェクトルールを含むコンテキスト運用の3つで検証していきたいです。特に、1Mコンテキストと新トークナイザーの実コストは、個人業務運用でもかなり実践的なテーマになります。
まとめ
Claude Sonnet 5について、2026年7月1日時点で分かっていることを整理すると、次のようになります。
- APIモデルIDは
claude-sonnet-5 - Claude Sonnet 4.6からの差し替え候補として位置づけられている
- 1Mトークンのコンテキストウィンドウと128k最大出力をサポート
- adaptive thinkingがデフォルトで有効
- 手動extended thinkingは削除され、指定すると400エラー
temperature、top_p、top_kの非デフォルト指定も400エラー- 新トークナイザーにより、同じテキストがSonnet 4.6より約30%多くトークン化される可能性がある
- 通常価格は入力$3/出力$15 per MTokだが、2026年8月31日までは入力$2/出力$10 per MTokの導入価格
- codingとagentic tasksでSonnet 4.6からの改善が大きいと説明されている
不明確な点としては、実務リポジトリでの体感差、日本語長文でのトークン増加率、Claude Codeでのデフォルト挙動、他社モデルとの同条件比較があります。ここは発表記事を読むだけでは分かりません。
個人的には、Claude Sonnet 5は「毎日使うClaude Codeの標準候補」としてかなり気になります。ただし、API制約とトークン数の変化があるため、まずは小さな検証から始めるのがよさそうです。次に試すなら、同じコード修正タスクをSonnet 4.6とSonnet 5に投げ、差分の小ささ、確認の丁寧さ、コストを比較します。
