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

こんにちは。7月に入り、梅雨明けが待ち遠しい頃になりましたね。新しいモデルが出るたびに「今度こそすごいらしい」という声が流れてきて、正直、もう何度目だろうと少し疲れている自分もいます。

それでも先に結論を書きます。Claude Sonnet 5は2026-06-30に発表され、上位のOpus 4.8に迫る性能を、ずっと安い価格で出してきました。effort（AIにどれだけ考えさせるかの設定）は既定のhighのままでほとんど足り、最難関のコーディングやエージェント作業（AIが自分で手順を組んで道具を使う仕事）だけxhighに上げる、というのが公式の推奨です。Opus 4.8を設計役（advisor）に、Sonnet 5を実行役にする組み合わせも、公式ドキュメントが後押ししています。そして個人的にいちばん効いたのは、1M CTX（一度に読ませられる文章量の上限＝コンテキストウィンドウが100万トークン）が、Sonnet 5からUsage Credits（追加の利用枠）不要の標準搭載になったことです。トークン課金そのものが消えるわけではなく、追加の課金ハードルが消えたという意味です。

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

• 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まで）は100万トークンあたり入力$2・出力$10で、その後は入力$3・出力$15の標準価格に移ります。Opus 4.8は入力$5・出力$25なので、標準価格に戻ってもSonnet 5はOpusの6割で動く計算です。

性能が上がった分、Sonnet 5を触っていて「じゃあ、どのくらい考えさせればいいのか」という新しい悩みが増えたのも事実です。effortという設定自体は、GPT-5.5のreasoning.effortと同じ考え方で、他社モデルでもお馴染みになりつつあります。ただ、Sonnet 5にはSonnet 5ならではの推奨値があって、そこを押さえないと「なんとなく重い設定にして、遅くて高いだけ」で終わってしまいます。

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

いちばん刺さったのはmediumの説明でした。公式は「medium effortはSonnet 4.6のhigh effort相当」と言い切っています。一段落として費用を抑えても、前の世代の最高設定と同じ水準が出るということです。「effortは上げるほど得」という直感を静かに裏切る話で、GPT-5.5の記事で書いた「思考過多トラップ」と同じ構図がここにもありました。

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

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

「それなら、いつもxhighにしておけば安心では」と思うところですが、そこは次の話につながります。

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

これ、うちのサイトで以前検証した話とほぼ同じ形です。高いモデルは『設計（軍師）』で使うべきか、『レビュー（参謀）』で使うべきかを7構成で比べたとき、「完成物のレビューに高いモデルを使う（参謀）」より「作る前の設計だけを高いモデルにやらせる（軍師）」ほうが、コストは半額以下で同等以上の結果になりました。公式ガイドの「Opusで設計、Sonnetで実行」は、まさにこの軍師パターンです。自分の実験が公式と同じ方向を向いていたのは、素直に嬉しい発見でした。

もう一つ、安いモデル＋Opusのadvisorで97.5%まで伸びた実測という過去の検証もあります。あちらは「実行は安いモデルに任せて、Opusにチェックさせる」というレビュー寄りの構成でした。二つを合わせて見えてくるのは、Opusを重い実行そのものに使うのは基本的に割高という一貫した傾向です。設計かレビューか、軽い関わらせ方にしておけば、コストは跳ね上がりません。

実務での型にすると、こうなります。

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

Claude Codeを使っている人なら、普段の「Plan Mode（設計の段階だけ重いモデルに切り替える）」の感覚とほぼ同じだと思います。呼び名が違うだけで、考え方は同じところに落ち着いている。

今回、自分にとっていちばん恩恵が大きかったのはここです。

公式サポート記事を見ると、Sonnet 5はすべての有料プランで1M CTXが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を使うこと自体」でそれが起きない作りになりました。

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

数字も見ておきます。公式発表の比較表を確かめると、こうなっています。

Terminal-Bench 2.1の伸び（67.0%→80.4%）は率直に大きいです。HLE（ツールあり）でも57.4%対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の懐疑的な意見は、一部のコメントの紹介です。コミュニティの総意ではありません。

最後に、迷いやすい3点を短く答えておきます。

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で解決できない心の課題も解決いたします！