Claude Sonnet 5とは何か：カスタマーサポートにとっての意味

Claude Sonnet 5とは実際どういうモデルか

私は本業で統合やAPIを構築しているので、新しいモデルが出たときはローンチスレッドより先にドキュメントを読みます。以下はAnthropicの公式ドキュメントがClaude Sonnet 5について述べている内容から、マーケティング的な装飾を取り除いたものです。

Anthropicは2026年6月末にSonnet 5を発表し、「これまでで最もエージェント性能に優れたSonnet」と位置づけ、無料版およびPro版のClaudeユーザーに向けて発表当日からデフォルトモデルとしました。これはClaude 5ファミリーのバランス型ティアです。1Mトークンのコンテキストウィンドウを持ち、出力は最大128Kトークンまで対応します。これはOpusティアと同じ上限です。売りは、コーディングとエージェントタスク、つまりサポートエージェントが行うような多段階でツールを使う作業において、Opusに近い品質に到達しながら、はるかに低コストで運用できる点です。Anthropicの大まかな位置づけでは、Sonnet 5のmediumエフォートは前世代のSonnet 4.6のhighエフォートに匹敵し、Sonnet 5のhighエフォートは4.6のmaxエフォートに匹敵するとされています。つまり、同じ設定でより多くの性能が得られるということです。

このモデルがファミリーの中でどこに位置するかが、本当に注目すべき点です。Anthropicは現在4つの公開ティアを展開しており、Sonnet 5は実際に多くのチームが本番環境に導入するモデルになるでしょう。

内部にはいくつかの新機能があり、バージョン番号が示すよりも重要な意味を持ちます。

• アダプティブシンキングがデフォルトで有効です。 固定のトークン数で「思考予算」を設定する必要はもうありません。モデルがリクエストごとにどれだけ推論するかを自ら判断し、代わりにeffortダイヤルで調整します。
• xhighエフォートがSonnetティアに登場しました。 Sonnet 5はxhigh設定を持つ最初のバランス型Claudeモデルで、Anthropicは最も難易度の高いコーディングやエージェント作業にこの設定を推奨しています。Claude Codeが活用しているのと同じダイヤルです。
• 高解像度ビジョン。 Sonnet 5は長辺2576pxまでの画像を読み取れます。サポート業務でスクリーンショットやレシートを扱う場合に役立ちます。
• 新しいトークナイザー。 これについては後述しますが、実は請求額にひそかに影響します。

Claude Sonnet 5の料金

ここが皆さんが本当に知りたい部分でしょう。Sonnet 5のAPI料金は入力100万トークンあたり3ドル、出力100万トークンあたり15ドルで、2026年8月31日まで2ドル/10ドルの導入価格が適用されます。コンシューマー向けでは、SonnetはClaudeサブスクリプション内の「バランス型」ティアです。

兄弟モデルと並べると、コストパフォーマンスの優位性は明らかです。

つまりSonnet 5は入力・出力ともにOpus 4.8よりおよそ40%安価でありながら、サポートエージェントが行うようなタスクにおいてはその能力の大部分を維持していると謳っています。月間数百万トークンを処理するキューにとって、この差は急速に積み上がります。

しかし、価格表には表れない落とし穴があります。Sonnet 5は新しいトークナイザーを採用しており、同じテキストに対してSonnet 4.6よりおよそ30%多くトークンを数えます。トークンあたりの単価は下がっていますが、各会話の実際のトークン数は増えているため、実際にチケット1件を解決するコストは、簡易的な見積もりが示すものとは異なる結果になる可能性があります。

これは既にSonnet 5について進行中の論争になっています。支持派はこれを「Sonnetの価格でOpusレベルの仕事ができる」と評しますが、Xの鋭い指摘によれば、導入価格の割引が終了し、高いエフォートで実行した場合、独立系のインデックスではタスクあたりのコストがOpus 4.8を上回る可能性があるとされています。両方とも真実である可能性があります。表示価格は低いがトークン数は多く、そしてエフォート設定によって合計はどちらにも振れる、ということです。

実際の反応も同じ方向を示しています。r/ClaudeAIの早期インプレッションスレッド（ローンチから数時間で90件超のコメント）で、あるデベロッパーはまさにこの記事のテーマとなっているトレードオフについて次のように投稿しています。

「Sonnet 5を[xhigh]エフォートで30分ほど使ってみたが、主にOpus 4.8に任せていたようなタスクだった……」

早期インプレッションスレッドより、r/ClaudeAI

これは注目すべきシグナルです。人々が以前ならOpusに任せていた作業に対してSonnet 5を使うようになっているということです。これがあなたのチケットでも成り立つかどうかは、ベンチマークでは答えられない問いであり、それこそが次のセクションの主題です。

実践的な進め方としては、古いモデルで得ていた数値を再利用するのではなく、claude-sonnet-5に対して自分たちのチケットで実際のトークン使用量を測定することです。サポート業務における総保有コストをモデル化しようとしているなら、AIサポートエージェントのコストの内訳の方が、単純なトークン単価の計算よりも良い出発点になります。というのも、サポートエージェントのコストのほとんどはモデルそのものではないからです。

Sonnet 4.6からの変更点

新規に始めるのではなく既存の統合をアップグレードするのであれば、モデル文字列を切り替える前に知っておくべきことが4つあります。

1. 思考の仕組みが変わりました。 Sonnet 5では、従来の固定budget_tokens設定は廃止されました。thinking設定を省略すると、以前はthinkingがオフで動作していたのに対し、今は自動的にアダプティブシンキングが動作します。これまで一度も設定を触っていなかった場合、リクエストは知らないうちにより多く推論するようになり（そして出力予算をより多く消費するようになり）ますので、max_tokensには少し余裕を持たせてください。
2. エフォートが主要な調整ダイヤルです。 デフォルトはhighのままにし、最も難しいエージェント作業にはxhighを使ってください。チケットのタグ付けや意図分類のような、安価でレイテンシに敏感なタスクではmediumやlowに下げましょう。
3. トークナイザーの変更は本物です。 前述の通り、トークン数のベースラインを再確認してください。これは移行時に財務チームを驚かせる最も一般的な原因です。
4. ビジョンがより鮮明になりました。 高解像度の画像入力は自動的に有効になります。チケットのトリアージをスクリーンショットとして受け取る場合に便利です。

すでにClaude APIで運用している場合、これはさほど大きな変化ではありません。書き直しではなく、モデル文字列の置き換えと再調整で済みます。Claudeデベロッパープラットフォームは、Opus 4.xファミリーの頃と同じリクエスト形式を維持しています。

サポートチームを運営する場合、Sonnet 5は何を意味するのか

ここからが、より安く、より賢いモデルが本当に興味深く、そして本当に誤解を招きやすいポイントです。

強力なモデルがローンチされるたびに、多くのチームが同じことを考えます。*このモデルはこんなに優秀でこんなに安いのだから、自社でAPIを使ってサポートボットを構築し、ベンダーを使わずに済ませればいいのではないか。*その気持ちはよく分かります。こうしたコードを実際に書く立場として、サポートの質問に答えるSonnet 5の呼び出しを組み上げるのは、満足感のある半日仕事です。

その落とし穴は、モデルの呼び出しは簡単な20%にすぎないということです。AIを実際の顧客に安全に向けるために必要なものはすべて水面下にあり、その一切がAPIレスポンスには含まれていません。

これは推測ではありません。私は顧客がClaude APIを直接使って自社構築に走るのを見てきましたが、そのパターンは一貫しています。デモは1週間で動くようになり、その後は検索、ハルシネーション対策、ルーティング、エスカレーションといった長い課題の連続が、次の半年を食い尽くします。購入ではなく構築を選ばなかったあるエンジニアリングリーダーは、次のように率直に語っています。

「独自のLLMアプリケーションを書くこともできましたが、そこに時間を投じたくありませんでした。メンテナンスの必要がないものを求めていたのです。」

GENERAL BYTESのエンジニアリングリーダー、Karel氏

最も怖い失敗パターンは、生のモデルが間違った答えを返すことではありません。それが自信満々な間違った答えを返すことです。3年以上にわたって実際のサポートキューにAIを導入してきた経験の中で、私が見てきた最悪のパターンは、自信たっぷりに聞こえるボットが、静かに顧客に虚偽の情報を伝えたり、実際には行っていない作業をあたかも行ったかのように語ったりすることです。だからこそ、本格的な導入は必ずまず過去のチケットに対してシミュレーションすべきです。そうすれば、実際の顧客が目にする前に、精度とカバレッジの数値を確認できます。モデルのベンチマークはエンジンが速いことを教えてくれますが、あなたの特定のボットがあなたの特定のチケットでどう振る舞うかについては何も教えてくれません。

したがって、サポート業務にとってのSonnet 5に対する正直な評価はこうです。エンジンを安く、より優れたものにするという点では素晴らしいですが、難しい80%についてはほとんど何も変えません。構築するにせよ購入するにせよ、APIが提供しない部分、つまりルーティング、ガードレール、人間へのエスカレーション、そしてテストのために時間を確保してください。顧客の信頼は実際にはそこで勝ち取られるか失われるかが決まるのです。

eeselを試す

正直な結論が「Sonnet 5クラスの品質を自分たちのチケットで使いたいが、残りの80%は構築したくない」というものであれば、それはまさにeeselが満たすギャップです。eeselは、Zendesk、Freshdesk、Gorgias、Help Scout、Intercomに数分で接続でき、すでにあなたのヘルプセンターと過去のチケットを把握している新しいサポート担当者のように機能します。

これまで述べてきたことを踏まえると最も重要なのは、eeselが本番稼働前に数千件の実際の過去チケットに対してシミュレーションできるという点です。これにより、実際の顧客に対応する前に解決率とカバレッジの数値を確認できます。確信度に基づくルーティングは、AIが対応できるチケットに限定して処理し、それ以外は人間に引き渡します。これこそが、賢いモデルを信頼できるチームメイトに変えるガードレールです。これはeeselが追いかけているだけのベンチマークではなく、Gridwiseのようなチームが導入初月でティア1リクエストの73%を解決できた理由でもあります。

料金は使用量ベースで、対応したチケット1件あたり約0.40ドル、シート単位の料金や最低利用額はなく、eeselを無料で試すこともできます。裏側で動くモデルが今日のSonnet 5であれ、来年登場する後継モデルであれ、実際にチケットを解決するのはその周りの仕組みです。