Claude Sonnet 5.5とは？料金・Opusとの違い・業務での使い方

Claude Sonnet 5.5は、Anthropicが2026年9月28日に公開したAIモデルです。速度と能力の両立を重視し、コード修正や文書作成などの仕事を想定しています。標準API料金は100万トークンあたり入力2ドル、出力10ドル。この記事では、Sonnet 5からの変更点、Opus 5.5との選び方、料金、業務での依頼例、API移行で確認することを説明します。

情報確認日：2026年10月4日。製品の事実は公式資料を参照し、仕事への当てはめ方はMakeAIの提案として示します。以下の業務例は、独立した性能試験や顧客の導入実績ではありません。

Claude Sonnet 5.5とは？どんな仕事の候補になる？

Sonnet 5.5は、毎日繰り返す資料作成や、条件の決まった開発作業で比較したいモデルです。単純に短い回答だけを返す使い方ではなく、資料を読み、修正を受けながら成果物を作る仕事も対象にします。最初は、一件ごとの完成条件を説明できる作業を選んでください。

Anthropicは、コード修正、長い知識業務、画面操作などでSonnet 5から改善したと発表しています。特定の評価でOpus 5.5に近い結果という説明もありますが、どの仕事でも同じ品質という意味ではありません。評価に使われた条件と、自社の資料や接続先は違います。Claude Sonnet 5.5の公式発表

モデル選びでは、最も難しい仕事の性能だけでなく、通常の仕事で必要な品質を満たすかを見ます。確認しながら使う文書の下書きと、複数システムを操作する業務では、求める条件も違います。Sonnet 5.5を試す仕事を具体的に決め、費用と人の修正時間を合わせて比較してください。

Sonnet 5から何が変わった？

公式発表では、品質と効率の改善が案内されています。一方で、APIの使い方には互換性のない変更もあります。性能の紹介だけを見てモデル名を替えると、現在の仕組みがエラーになったり、途中のメッセージが表示されなくなったりする場合があります。

確認する項目	Sonnet 5.5での扱い	導入担当者が確認すること
モデルID	claude-sonnet-5-5	実行しているモデルを記録する
標準API単価	入力2ドル、出力10ドル	使用量と再試行も含めて費用を見る
思考の設定	既定はadaptive、effortはhigh	従来の設定をそのまま流用しない
既存連携	強制ツール指定などに変更	エラーと画面表示を移行前に試す

コンテキストは100万トークン、最大出力は12万8千トークンです。長い入力を扱えることは、無関係な資料をすべて渡す理由にはなりません。資料の版、用途、優先順位を指定すると、回答の根拠を確認しやすくなります。Sonnet 5.5の公式仕様

使える場所と最初の操作

Claudeの画面やClaude Codeでは、利用中のモデル表示を確認し、Sonnet 5.5を選べる状態か確かめます。組織の設定で選択肢が制限されている場合は、管理者へ利用条件を確認してください。APIはClaude APIのほか、公式仕様に案内されたAWS、Google Cloud、Microsoft Foundryなどでの提供があります。基盤ごとの設定や請求を区別して確認します。

選択後は、機密情報を含まない短い資料で、見出しと要点を整理する依頼から始めます。画面上の名前と、実際に選んだモデルを記録します。前の会話で別のモデルを使っていた場合は、新しい会話で試す方法もあります。手元で動作を確かめてから、本来の業務資料を社内ルールに従って扱ってください。

料金と、会社で見積もる際の考え方

標準API単価は100万トークンあたり入力2ドル、出力10ドルです。キャッシュ読み取りは0.20ドル、五分間の書き込みは2.50ドル、一時間の書き込みは4ドル。Batch APIは入力と出力が50％割引と案内されています。Claudeの月額プランとAPIの従量課金は区別して確認します。

一回に入力1万トークン、出力2千トークンを使うと仮定すると、入力0.02ドル、出力0.02ドルで合計0.04ドルです。同じ条件で月千回なら40ドルになります。標準処理、キャッシュなし、追加ツールなしの計算例で、税や外部サービスなどは含みません。

Opus 5.5の標準単価で同じ量を使うと、一回0.08ドル、千回80ドルです。ただし、Sonnet側で追加修正が必要なら差は変わります。料金表ではSonnetが低くても、確認担当者の作業時間が増える場合があります。実際の比較では、使える成果物になるまでの総額を記録してください。

費用を管理する際は、業務ごとに回数と使用量を分けます。短い返信、長い資料の照合、開発作業を一つの平均にすると、何が費用を増やしているか分かりにくくなります。毎回同じ資料を使う処理はキャッシュを、急がない処理はBatchを検討する、というように条件ごとに判断します。

活用例1：社内手順書を更新する

最初に試す仕事として、変更された運用を手順書へ反映する作業があります。現行手順書、変更メモ、問い合わせ記録を用意し、どの項目を直す必要があるか調べます。古い手順を全部書き直すより、今回変わった条件と関係する箇所を先に表にすると確認しやすくなります。

たとえば申請の締め切りと確認担当者が変わったなら、申請手順だけでなく、通知文、問い合わせ先、よくある質問にも影響があります。資料のどこに変更が書かれているかを示し、判断できない条件は質問として残してもらいます。

現行手順書と変更メモを確認し、更新案を作ってください。
先に「変更が必要な見出し／変更理由／根拠の資料／未確認事項」の表を出す。
変更メモにない締め切りや担当者を追加しない。
本文は、新しく担当する人が作業できる説明にする。
操作、確認、問い合わせ先を分け、前提条件も残す。
最後に、更新で影響する通知文とFAQの項目を挙げる。

確認担当者は、実際の操作と説明が一致するかを見ます。「保存を押す」と書かれていても、画面では「送信」かもしれません。画面の名称、担当者、期限を照合し、新しい人が迷う箇所を直します。AIが読みやすくした文章でも、必要な例外条件まで省いていないか確認してください。

更新後は、変更した箇所と確認した資料を記録します。手順書だけ新しくなって通知文が古いままだと、利用者に異なる案内が届きます。最終成果物を一つの文書だけにせず、影響する資料の一覧まで残す方法が実務で役立ちます。

活用例2：短い開発作業を繰り返す

開発では、条件の決まった修正を試す候補にできます。たとえば社内管理画面の表に並び替えを追加する仕事です。対象列、初期の順序、空欄の扱い、既存機能への影響を指定します。見た目だけ変えるのか、データ取得の処理も変えるのかを先に確認してください。

作業用の管理画面で、更新日による並び替えを追加する案を出してください。
対象は一覧表。初期表示は更新日の新しい順。
同じ日付の行、日付が空欄の行、ページ送りの扱いも説明する。
既存の検索条件と権限は変更しない。
承認後に必要な箇所だけ修正し、変更差分と実行した確認を報告する。
実行できなかったテストは、成功とせず未確認として残す。

修正したら、通常のデータだけでなく、空欄や同じ日付を含むデータで確認します。並び順が変わることでページ送りが不安定になっていないか、検索条件が消えていないかも見ます。テストの結果だけでなく、変更した範囲が依頼と一致するかを確認してください。

SonnetとOpusを比べるなら、同じ修正をそれぞれ作業用の環境で行います。初回の完成度、必要な追加指示、人の確認時間を記録します。上位モデルが常に必要か、通常の修正はSonnetで足りるかを、この比較から判断します。

活用例3：打ち合わせメモから提案の骨子を作る

営業や企画では、メモにある事実と、提案する対応を分ける下書き作成を試せます。相手の要望、現状の困りごと、予算や期限、まだ決まっていない条件を整理します。メモにない導入効果や実績を足さず、次の打ち合わせで確認する質問まで作ります。

依頼の完成条件は「提案書を作る」だけでなく、「担当者が説明できる骨子を作る」とします。出力を課題、対応案、試行範囲、必要資料、確認事項に分けると、文章だけが先に立派になることを避けやすくなります。見積もりが必要な項目も、確定した金額にせず別に残します。

確認は、事実、提案、約束の順に行います。事実がメモと一致するか、提案が提供可能な内容か、期限や費用が確定しているかを見ます。仕上げの文章調整はその後です。担当者が説明できない効果や事例が入っている場合は、削除または確認事項へ戻してください。

Opus 5.5・Fable 5.1との使い分け

モデルの比較では、入力の整理状況と判断の難しさを分けます。条件が決まった文書更新や小さな修正はSonnetから試す方法があります。複数の資料に矛盾があり、調査と判断を何段階も行う仕事は、OpusやFableも含めて同じ条件で比較します。

確認するのは、最初の回答の印象ではなく、完成条件を満たした件数と修正にかかった時間です。モデルごとに詳しさの違う指示を与えると、能力の比較になりません。入力資料、依頼文、作業範囲、確認表をそろえてください。

Opusの変更点と仕事への使い方はClaude Opus 5.5の記事、Fableの位置付けはClaude Fable 5.1の記事で説明しています。必要な業務と利用する環境を整理してから、候補モデルを比べてください。

API移行で注意する変更点

Sonnet 5.5では、思考を無効にする従来のdisabled指定ではなく、between_toolsを使う案内があります。この設定はhigh以下のeffortで対応します。強制的なツール指定のanyやtoolもエラーになります。既存の処理にこれらが含まれる場合、モデルIDだけを変えてはいけません。Sonnet 5.5の変更・移行案内

思考ブロックはモデルと会話に結び付くため、保存した会話の再利用や途中でのモデル切り替えも確認します。過去の会話やツール定義を編集する仕組みがあるなら、その条件でエラーにならないかを試します。文章生成だけで動作していても、会話履歴を使う処理は別に確認が必要です。

ツール間の文章が思考ブロックとして返る変更にも注意します。画面に途中経過を表示する仕組みでは、処理は進んでいるのに利用者には止まったように見える可能性があります。最終回答が返ることだけでなく、開始、途中、完了、失敗の表示を確認してください。

computer useでは、Claude APIとGoogle Cloudで旧ツールが受け付けられない変更があります。利用する基盤によって条件が異なるため、現在の環境と公式の互換性案内を照合します。接続先、ツール、会話履歴の扱いを一緒に確認し、必要なら小さな範囲から移行します。

品質を確かめるための確認表

試行では、普通の業務例に加えて、資料が足りない例、説明が矛盾する例、例外がある入力を含めます。成功した一件だけで日常の仕事に使えると判断しないことが大切です。各件の入力と期待する結果を保存し、モデルや設定を変えても比較できるようにします。

項目	確認方法
根拠	資料の位置と回答が対応しているか
条件	禁止した変更や未確定の約束がないか
完成物	形式、内容、動作の合格条件を満たすか
費用	再試行を含む使用量を記録する
人の負担	確認と修正にかかった時間を比べる
例外	判断できないときに人へ引き継げるか

採用する条件は、業務の責任者と先に決めます。下書きなら担当者が確認できること、自動登録なら必要項目が正しくそろうことなど、用途で基準が変わります。共通の正解率だけを使わず、実務で困る誤りが残っていないかを見てください。

よくある質問

Sonnet 5.5はOpus 5.5と同じ能力ですか？

一部の評価で近い結果という発表はありますが、すべての仕事で同じとはいえません。条件が決まった仕事と、調査や判断の多い仕事を分け、自社の資料で確認してください。標準単価の差も、総費用の差とは限りません。

Sonnet 5から設定をそのまま移せますか？

その前提にはできません。思考設定、強制ツール指定、会話履歴、computer useなどに変更があります。公式移行案内と現在のコードを照合し、正常な入力だけでなく失敗と再開も試します。

モデルが速いなら確認を省いてよいですか？

速度と内容の正しさは別です。数字、条件、根拠、変更範囲を確認する工程は残します。速く処理できたとしても、人が判断する必要のある契約条件や外部への約束を自動で確定させないようにしてください。

社内で最初に試す仕事をどう選びますか？

入力資料と完成物がはっきりしていて、作業用のコピーで試せる仕事を選びます。担当者が正誤を判断できない仕事は、最初の試行にしないほうが評価しやすくなります。依頼文は業務プロンプトの書き方も参考にできます。

Claudeの業務利用を相談したい方へ

MakeAIでは、対象業務、入力資料、成果物、確認項目を整理して、モデルを比較する試行を設計します。生成AIの導入・運用相談では、現在の仕事を止めずに試す範囲から相談できます。