Sonnet 5のeffortは何が変わった？1M CTX無料化と検証結果

正直に言います。新しいモデルが出るたびに「今度こそ本当にすごいらしい」という声が流れてきて、もう何度目だろうと少し疲れている自分がいます。

とはいえ、今回はダウンロードフォルダに公式発表のページをそのまま保存して読み込むところから始めました。Anthropicの公式発表（2026-06-30付）を自分の目で確認してからでないと、記事は書かない主義です。本記事は2026-07-01時点で確認できる公式情報・公開日ベースの情報をもとに構成しています。

TL;DR: 先に結論を言うと、Claude Sonnet 5は2026-06-30に発表され、Opus 4.8に迫る性能を大幅な低価格で実現しています。effortはデフォルトがhighで、最難関のコーディング/エージェント作業だけxhighに上げるのが公式の推奨。Opus 4.8を設計役（advisor）に、Sonnet 5を実行役にする組み合わせも公式ドキュメントが後押ししています。そして個人的に一番効いたのは、1M CTX（コンテキストウィンドウ）がSonnet 5からUsage Credits不要の標準搭載になったことです（トークン課金自体がなくなるわけではなく、あくまで追加の課金ハードルが消えたという意味です）。

• Claude Sonnet 5とは何か——Opus 4.8に迫る性能、低い価格
• effortレベルの公式推奨：タスク別にどう選ぶか
• Opus 4.8を「advisor」にしてSonnet 5を動かす設計
• 1M CTXが無料開放された——Sonnet 4.6時代のUsage Credits地獄との対比
• ベンチマークで見る立ち位置
• ネットの反応——歓迎と懐疑
• 注意点・制約
• よくある質問
• まとめ
• この記事を書いた人

公式発表によれば、Sonnet 5はこれまでのSonnetシリーズの中で最も自律的なモデルとして設計されています。計画立て・ブラウザやターミナルのツール使用など、これまでOpusクラスでしかできなかった水準の自律動作を、Sonnetの価格でこなすという触れ込みです。

価格を見ると、この触れ込みには根拠があります。導入価格（2026-08-31まで）は入力$2/出力$10（100万トークンあたり）、その後は入力$3/出力$15の標準価格に移行します。Opus 4.8は入力$5/出力$25。単純計算でも、Sonnet 5は標準価格でもOpusの6割で動きます。

Sonnet 5を触っていて気づいたのは、性能が上がった分だけ「じゃあ、どのくらい思考させればいいのか」という新しい悩みが増えたことです。effortという設定項目自体はGPT-5.5のBlog「effortは高いほど良い」は間違い。GPT-5.5の5段階を実務で使い分ける判断基準GPT-5.5のreasoning.effortパラメータ（none〜xhigh）の選び方を実務翻訳。Responses APIとChat Completions APIの書き方の違い、思考過多トラップの回避、タスク別の判断フローを整理します。→と考え方は同じで、他社モデルでもすでにお馴染みの概念になりつつあります。ただ、Sonnet 5にはSonnet 5固有の推奨値があり、そこを押さえないと「なんとなく重い設定にして、遅くてコストが高いだけ」で終わります。

公式ドキュメントには、Sonnet 5専用の推奨表がはっきり書かれています。整理するとこうなります。

ここで一番刺さったのはmediumの説明でした。公式は「medium effortはSonnet 4.6のhigh effort相当」と明言しています。つまり、コストを一段落としても、前世代の最高設定と同じ水準が出るということです。これは「effortを上げれば上げるほど得」という直感を静かに裏切る話で、GPT-5.5の記事で書いた「Blog「effortは高いほど良い」は間違い。GPT-5.5の5段階を実務で使い分ける判断基準GPT-5.5のreasoning.effortパラメータ（none〜xhigh）の選び方を実務翻訳。Responses APIとChat Completions APIの書き方の違い、思考過多トラップの回避、タスク別の判断フローを整理します。→」と同じ構図がここにもありました。

タスク別に落とし込むなら、判断はシンプルです。

• 日常のチャット・簡単な変換・非コーディング → low
• 普段のコーディング・エージェントタスク → high（何もしなければこれ）
• 30分を超えるような長時間の自律タスク、最難関のコーディング → xhigh
• コストを絞りたいだけなら → medium（体感はSonnet 4.6のhighと同等）

「じゃあ、いつもxhighにしておけばいいのでは」と思うところですが、そこは次の話とつながってきます。

公式ドキュメントは、Opus 4.7/4.8について「コーディング・エージェント用途はxhighから始めよ」と明言しています。ここで面白いのは、Opusのxhighとの組み合わせ方です。長時間のエージェントタスクでは、「Opusをxhighで設計に使い、実行はSonnetの低めのeffortに任せる」という役割分担が、業界の解説記事（MarkTechPost）でも紹介されています。

これ、実はうちのサイトで以前検証した話とほぼ同じ形です。以前、BlogClaude 7構成にLPを作らせて比較：軍師（設計）が参謀（レビュー）に半額で勝ったClaudeの高モデルは完成物レビューより事前設計に回した方が安く強い。7構成で同一LPを比較し、実コストと使用感から判断材料を整理しました。→を7構成で比較したところ、「完成物のレビューに高いモデルを使う（参謀）」より「作る前の設計だけを高いモデルにやらせる（軍師）」ほうが、コストが半額以下で同等以上の結果になりました。今回の公式ガイドが言っている「Opusで設計、Sonnetで実行」は、まさにこの軍師パターンです。うちの実験結果が公式ガイドと同じ方向を向いていたのは、素直に嬉しい発見でした。

さらに、Blog格安モデルでも Rank S：Haiku 4.5 × 24問テスト実測（+Advisor で97.5%）Haiku 4.5を24問で実測。単体93%でも十分強く、Advisor（Opus）の2パスで97.5%まで改善。ただし自信満々に間違える盲点も見えました。→という過去の検証もあります。あちらは「実行を安いモデルに任せて、Opusにチェックさせる」というレビュー寄りの構成でしたが、今回の話と合わせると見えてくるのは、Opusを重い実行そのものに使うのは基本的に割高という一貫した傾向です。設計かレビューか、軽い関与のさせ方をすればコストは跳ね上がらない。

つまり、実務での型はこうなります。

1. 難しい設計判断・アーキテクチャの骨組み → Opus 4.8のxhigh
2. 実際のコーディング・ツール実行 → Sonnet 5のhigh（重い長期タスクだけxhigh）
3. 日常の雑務・チャット → Sonnet 5のlow

Claude Codeを使っている人なら、これは普段の「Plan Mode（設計フェーズだけ重いモデルに切り替える）」の感覚とほぼ同じです。名前が違うだけで、考え方は同じところに収束している。

ここが、今回自分にとって一番恩恵を感じた部分です。

公式サポート記事を確認すると、Sonnet 5は全paidプランで1M CTX（100万トークンのコンテキストウィンドウ）がUsage Credits不要の標準搭載になっています。公式のコンテキストウィンドウのドキュメントでも「1MがAPIのデフォルトで、追加のベータヘッダーは不要、標準料金で使える」とはっきり書かれています。

これがどれだけ嬉しい変化かは、Sonnet 4.6時代の状況を知っていると余計に染みます。同じ公式サポート記事では、Opusモデルは今も「Pro ユーザーはUsage Creditsを有効化しないと1M CTXにアクセスできない」とあります。そしてSonnet 4.6の時代は、Sonnetでもこの制約がありました。GitHub Issue #62314を見ると、Claude Desktopで「Sonnet 4.6へのリクエストが勝手にlong-contextの課金ティアに回され、Usage credits required for long context requestsという429エラーで使い物にならなくなった」という実際のトラブル報告があります。関連するIssue #62199でも、Proユーザーが「デフォルトモデルが事前通知なしに1M CTX前提のモデルへ切り替わり、ワークフローが一晩で壊れた」と報告していました。

これ、正直、ただ運が悪かっただけの話ではないと思います。無料枠の中で「重いコンテキストを使うと突然エラーで止まる」という体験は、地味に信頼を削ります。それがSonnet 5では、少なくとも「1M CTXを使うこと自体」ではもう起きない設計になった。

4.6 Sonnetの頃、1M CTXは自分にとって「使いたいけど、いつUsage Creditsの壁にぶつかるか分からない機能」でした。それが今は、素で1Mトークンぶんの会話履歴を持ち運べる。長い設計相談や、複数ファイルにまたがるコード調査を一気に投げられるようになったのは、effortの使い分けよりも実は日常への影響が大きいと感じています。

数字も見ておきます。公式発表に掲載されている比較表を確認すると、以下の数値になっています。

Terminal-Bench 2.1の伸び（67.0%→80.4%）は率直に大きいです。HLE（ツールあり）でも57.4% vs Opusの57.9%と、ほぼ差がなくなっています。GDPval-AA v2に至っては、Sonnet 5（1618）がOpus 4.8（1615）をわずかに上回っている。「Sonnetクラスなのに、知識労働のスコアだけ見るとOpusを超える場面がある」というのは、正直、数字を見るまで半信半疑でした。

公式発表には、この数字を裏付けるグラフも2枚掲載されています（BrowseCompでのエージェント検索評価、OSWorld-Verifiedでのコンピュータ操作評価。いずれもeffortレベル別のコスト対性能曲線）。公式の説明をそのまま借りると、「Sonnet 5（オレンジ）はSonnet 4.6（グレー）を大幅に上回る性能向上を実現しており、Opus 4.8（黄色）よりもはるかに幅広いコストパフォーマンスオプションを提供している。中程度の作業量ではコスト効率が大幅に向上し、高作業量では一部のタスクでOpus 4.8と同等のパフォーマンスを発揮する」とのことです。グラフの目盛りを1点ずつ読み取って再現するのは精度的に危ういので数値化はしませんが、この「効率が良い上に、上を詰められる」という形自体が、上の表の傾向とちゃんと一致しています。

発表直後からSNSでも話題になりました。歓迎の声はシンプルで、X上のClaudeDevsは、1M CTXがSonnet 5の新デフォルトになったこと自体を好意的に取り上げています。

一方で、Hacker Newsのスレッドを見ると、賛否は割れています。「コストパフォーマンスをタスク単位で見ると、結局Opusの方が有利な場面がある」という指摘や、「日常タスクにしては高く、最難関タスクにしてはフロンティアモデルというほどでもない」というポジショニングへの戸惑いの声がありました。effortレベルの選び方についても「結局よく分からず、とりあえずmaxに倒している」というユーザーの声が紹介されています。

ここは私見ですが、この「よく分からず最大設定に倒す」現象は、今回この記事を書くきっかけそのものだったように思います。選択肢が増えるのは良いことですが、選択の基準が曖昧なままだと、結局みんな安全側（最大設定）に倒れて、コスト削減という恩恵を誰も受け取れない。この記事が、その空白を少しでも埋められればと思っています。

• 本記事のベンチマーク数値は、Anthropic公式発表内の比較表を直接確認して転記したものです。ただし、コスト対性能曲線（BrowseComp/OSWorld-Verified）はグラフの目盛りからの目視読み取りになるため、数値化はせず公式の説明文をそのまま引用するに留めています。「Opus 4.8で設計・Sonnet 5で実行」という役割分担が全タスクで最適という部分は、うちの過去の別実験（軍師/参謀比較）からの推測であり、Sonnet 5そのものでの追実測ではありません。
• Sonnet 5は新しいトークナイザーを採用しており、同じ入力でも旧モデルより1.0〜1.35倍程度トークン数が増える場合があります。導入価格はこの移行がコスト中立になるよう設定されているとのことです。
• Sonnet 5はサイバーセキュリティ関連タスクの実行能力がOpus 4.8より大幅に低い設計です。危険なサイバースキルを要する評価ではOpus/Mythos系のほうが高いスコアを示しており、Sonnet 5にはデフォルトでサイバー保護機能が有効化されています。
• Hacker Newsの懐疑的な意見は、あくまで一部のコメントの紹介です。コミュニティの総意ではありません。

Q. effortはとりあえずxhighにしておけば安心ですか？

A. 公式ガイドは「xhighは最難関のコーディング・エージェントタスク限定」としています。日常的なコーディングやエージェントタスクにはデフォルトのhighで十分というのが公式の立場です。コストを絞りたいならmedium（Sonnet 4.6のhigh相当）から試すのが理にかなっています。

Q. Opus 4.8とSonnet 5、結局どちらを使えばいいですか？

A. 設計・アーキテクチャの骨組みなど「間違えると手戻りが大きい判断」はOpus 4.8のxhigh、実際のコーディングや日常のエージェントタスクはSonnet 5、という役割分担が公式ガイドとも、うちの過去の検証とも一致しています。

Q. 1M CTXは無料ということですか？

A. 「Usage Creditsを別途有効化する必要がなくなった」という意味で、標準料金の範囲に含まれています。ただし大量のトークンを消費すれば、その分の入出力トークン課金自体は当然発生します。「無料」というより「追加の課金ハードルが消えた」という理解が正確です。

Sonnet 5は、単に「性能が上がった」だけの話ではありませんでした。effortの使い分け、Opusとの役割分担、そして1M CTXの扱い——このあたりの設計判断が、地味だけれど実務に効いてくるところだと感じています。

正直なところ、モデルの発表が出るたびに全部を追いかけるのは、もう体力的にきついです。それでも、1M CTXの制約が静かに消えていたことには、少し得した気分になりました。当たり前になっていくものほど、後から振り返って初めて「そういえば前は不便だったな」と気づく。今回もそういう類の話だったのかもしれません。

HW系エンジニアとして20年以上、10,000件を超える顧客訪問と2,000件を超える単独ソリューション実績。AIツールを使った個人開発やIoT農園など、Raspberry Piを使ったオートメーション化なども実践中です。エンジニア専門結婚相談所も運営中、ClaudeCodeで解決できない心の課題も、現場目線でお手伝いします。