Claude Sonnet 5.5の選び方｜案件の合格条件と利益計算

2026年9月28日の公式発信からSonnet 5.5とOpus 5.5の役割を実務で読む

2026年9月28日、Anthropicの開発者向け公式アカウント @ClaudeDevs が、Claude Sonnet 5.5の提供開始と、Sonnet 5.5とOpus 5.5の選び分け、Sonnet 5からの移行、労力設定を扱う案内を公開しました。事実の入口は、Claude Sonnet 5.5の提供開始案内です。

同日には、評価設計を組み立て、試して、結果を見ながら改善する考え方を扱う評価設計と反復改善の案内も公開されています。今回の記事では、公式発信から確認できる範囲と、読者が自分の案件で追加確認する範囲を分け、モデルの感想を受注判断へ直結させないようにします。

発表で確認できる事実と、案件でまだ確かめる数字を分ける

公式発信から確認できるのは、提供開始と選び分け、移行、労力設定に関する案内が公開されたことです。これは新しいモデルを調べる理由にはなりますが、読者の入力資料を使った納品品質や、作業時間の短縮を保証するものではありません。まず事実を記録し、その後に自分の試験結果を重ねます。

性能順位、料金、全利用者への提供条件、特定案件で何時間短くなるかは、発表文だけで決めません。利用する窓口の案内、対象プラン、契約条件、実際の入力と成果物を確認し、確認日も残します。公式の情報が更新された場合は、前回の試験結果と同じ条件で再確認する必要があります。

Sonnet 5.5とOpus 5.5の違いをモデル名でなく仕事の重さで読む

選び分けの起点は、どちらの名前が上かではなく、仕事にどの種類の判断が含まれるかです。入力と出力の形が安定し、間違いを確認しやすく、同じ作業を何度も行う案件なら、まずSonnet 5.5を試す設計ができます。一方、要件が曖昧で判断のやり直しが高くつく仕事は、Opus 5.5を比較対象に残します。

この分け方は一般的な性能順位を断定するものではありません。Sonnet 5とSonnet 5.5の初期比較も含め、公開された比較は評価条件を読んで使います。自分の顧客が求める正確さ、説明の深さ、確認者の時間を一枚に書いてから、試験するモデルを決めることが重要です。

モデル名ではなく開発案件の合格条件と確認範囲を先に固定して比べる

モデルを先に決めると、出力を見てから合格条件を動かしたくなります。これでは、良い結果だけを取り上げたり、確認にかかった時間を隠したりしやすくなります。案件の開始時点で、何を渡し、何が返れば納品とするかを固定すると、Sonnet 5.5とOpus 5.5を同じ土俵で比べられます。

入力資料と納品形式を一枚の合格条件にまとめる

最初の確認表には、次の順番で記入します。項目を増やしすぎず、顧客が受け取る成果物を判定できる範囲に絞ることがポイントです。

1. 入力資料を決めます。参照してよい文書、対象期間、欠けている資料、推測してはいけない前提を記録します。
2. 成果物の形式を決めます。文章、表、修正案、調査報告のどれを納品するのか、分量とファイル形式まで書きます。
3. 重大な見落としを決めます。金額、日付、固有名詞、仕様、個人情報など、ひとつでも間違えると差し戻す項目を並べます。
4. 確認者と納期を決めます。誰が最終確認をし、何営業日以内に受け渡すか、追加確認の上限も記載します。
5. 合否の境界を決めます。合格、条件付き合格、不合格を、印象ではなく確認できる状態で表します。

この表があると、「自然な文章だった」「説明が詳しかった」という感想を、納品条件と別に扱えます。文章の読みやすさを評価する場合も、見出しの有無、必須項目の欠落数、読み手が判断できるかなど、後から同じ基準で確認できる形へ変えます。

サイト修正・データ整理・調査報告を同じ表で比べない

たとえばサイト修正なら、指定ページの変更が反映され、別のページを壊していないことが合格条件になります。データ整理なら、行数、重複、空欄、分類の一貫性が中心です。調査報告なら、資料の出典、比較軸、未確認事項、読者が取る行動が重要になります。

三つを「正しさ」という一語でまとめると、確認者が見る箇所が曖昧になります。案件ごとに重大な失敗を三つから五つに絞り、確認時間も別欄に置きます。見栄えがよくても必須列が欠けた表は不合格、短くても判断に必要な根拠が揃った報告は合格というように、見た目と納品可能性を分けておくと判断がぶれません。

公式の評価設計を案件で再利用できる試験表へ落とし初回合格率を記録する

公式の評価設計を読むときは、順位を写すのではなく、課題、条件、合格基準、結果、改善点が繰り返し追える形へ置き換えます。案件の試験表には同じ入力を使った結果だけでなく、確認者の時間と手直しの内容も記録します。そうすれば、出力の印象ではなく納品までの負担を比べられます。

同じ課題を複数条件で試し、初回と最終の合格を分ける

試験表は、次の順番で作ると次の案件にも持ち込めます。試験回数を増やすこと自体が目的ではなく、どの条件で結果が変わったかを残すことが目的です。

1. 代表課題を選びます。実際の案件で頻出し、顧客に渡す成果物へ近い課題を三つから五つ用意します。
2. 条件を固定します。入力資料、指示文、労力設定、許可する参照範囲、出力形式を試験ごとに記録します。
3. 初回結果を判定します。人が手直しする前の状態で、合格、条件付き合格、不合格を決め、確認にかかった分数も残します。
4. 手直し後に再判定します。直した箇所、直すのに要した時間、同じ失敗が残ったかを記録し、最終合格率を計算します。
5. 失敗を分類します。事実誤り、指示漏れ、形式違反、確認負担、納期遅れなど、次の判断に使える名前を付けます。

初回合格率が高くても、確認に長時間かかる、手直しが難しい、重大な失敗が残るなら、利益にはつながりません。逆に初回で完全でなくても、確認箇所が明確で短時間に直せるなら、限定された作業へ使える場合があります。初回と最終を分けることで、モデルが出した結果と、人が納品へ整えた結果を混同しません。

反応数や視聴数と成果物の合否を混ぜない

動画や投稿への反応は、読者がどの話題に関心を持ったかを見る補助材料です。たとえばClaudeでカルーセルを無料作成する動画や、ChatGPTとClaudeのプログラミング比較動画は、関心の方向を考える材料にはなりますが、読者の案件で納品できる証拠ではありません。

評価表には、反応数を記入する欄と、成果物の合否を記入する欄を置きません。前者はテーマ選定の参考、後者は請求や受け渡しの判断に使う数字だからです。人気のある説明をそのまま採用せず、入力、出力、確認者、手直しの四点が揃った自社の記録を優先します。

Sonnet 5.5からOpus 5.5へ切り替える境界を品質と利益で判断する

切り替えの境界は、モデルごとの印象ではなく、案件の損失が増える地点に置きます。反復が多く合格条件が明確な作業はSonnet 5.5から試し、設計判断が重く、失敗後の再納品や顧客説明に時間がかかる作業はOpus 5.5も同じ試験表で比べます。

反復が多く合格条件が明確な作業はSonnet 5.5から試す

Sonnet 5.5から試しやすい作業には、入力の型が安定している、出力形式が決まっている、誤りを人が短時間で発見できる、失敗時に対象を限定してやり直せる、という特徴があります。定型的なデータ整理、既存ページの小さな修正案、資料から決められた項目を抜き出す作業などが候補です。

ただし、候補だからといって無確認で納品してはいけません。最初の数件は確認時間を多めに見積もり、重大な見落としがないことを確認します。入力の揺れが大きい、顧客の意図を読み違えると取り返せない、外部の判断が必要になる、といった条件が見えたら、同じ作業でもOpus 5.5との比較へ戻します。

難所への切り替えは最低品質と手直し原価で判定する

切り替えの基準は、案件開始前に仮置きします。たとえば「初回合格率80%以上」「重大な見落とし0件」「確認は一件20分以内」と決め、両モデルの結果を同じ条件で比べます。数値は市場の標準ではなく、その顧客が許容できる納期と損失から決める案件固有の基準です。

利益は、請求額 − 利用費 − 確認時間×時間単価 − 手直し時間×時間単価で計算します。仮に請求額18万円、利用費1万5,000円、確認12時間、手直し8時間、時間単価4,000円なら、基準上の利益は9万8,000円です。これは相場ではなく、モデルを変えたときに何が変わるかを見るための計算例です。

評価結果を見積もり・提案・継続支援へつなぐ利益の説明方法を作る

評価結果を社内メモで終わらせると、次の見積もりで同じ試験をやり直します。入力、合格条件、試験結果、確認時間、手直し費用を残し、顧客が受け取れる成果物に分けると、モデル選びそのものではなく判断材料を提供できます。速く作れた時間をすぐ値下げへ回さず、確認と説明の品質へ使うことも大切です。

評価表を診断・導入確認・継続支援の三つの納品物へ分ける

案件の大きさに応じて、評価表を次の三つへ分けます。ひとつの資料へ全部詰め込まず、顧客がその時点で必要な判断を選べるようにします。

1. 診断資料では、現在の作業、入力資料、重大な失敗、確認時間、モデル比較の必要性を整理します。まだ導入を決めない顧客にも渡せる範囲にします。
2. 導入確認資料では、代表課題、合格条件、試験結果、初回と最終の差、残る制限をまとめます。どの作業へ任せ、どこを人が確認するかを明示します。
3. 継続支援資料では、月ごとの再試験、条件の変更、失敗の増減、改善案、次に確認する範囲を記録します。結果が悪化したときの見直し条件も書きます。

この分け方なら、顧客は「モデルを買う」のではなく、「自社の作業をどの条件で任せられるかを判断する」ために費用を払うと理解できます。受け渡す資料が変われば料金も変わるため、診断だけ、導入確認まで、継続支援までという提案を比較しやすくなります。

7日間の小さな確認で再現した数字だけを次の提案に使う

大きな案件の前に、ひとつの代表作業で7日間の確認を行います。日数は目安であり、顧客の資料量と確認者の予定に合わせて調整します。

1. 1日目に代表作業をひとつ選び、入力、成果物の形式、重大な失敗、合格率の基準を決めます。
2. 2日目に匿名化した資料と確認表をそろえ、同じ条件で比べられる状態にします。
3. 3日目と4日目にSonnet 5.5とOpus 5.5を試し、初回結果、確認時間、手直し内容を別々に記録します。
4. 5日目に確認者が成果物を判定し、見逃しやすい項目、再確認が必要な項目を洗い出します。
5. 6日目に利用費、確認時間、手直し時間、再納品の可能性を計算し、モデルごとの利益を比べます。
6. 7日目に継続する範囲、上位モデルへ切り替える範囲、人が必ず確認する範囲を一枚にまとめます。

この7日間で同じ結果を再現できた数字だけを、次の見積もりや提案の根拠にします。一度だけ成功した例や、確認者が変わると合否が変わる例は、実績ではなく追加試験が必要な候補です。顧客へは「何％よくなった」と先に言うのではなく、「この入力と条件なら、何分でどこまで確認できた」と説明します。

評価結果を使うときの主役はモデル名ではありません。案件ごとの合格条件、最終的な確認時間、手直しの原価、顧客へ渡す証拠です。Sonnet 5.5を広い範囲で試し、Opus 5.5を難所へ残す判断も、数字を同じ表に置けば、納期と利益を守るための説明になります。

出典と検証範囲を分け、公式事実と実務提案を読者が確認する方法を残す

本記事の時事部分は、2026年9月28日に公式アカウントからSonnet 5.5の提供開始、モデルの選び分け、Sonnet 5からの移行、労力設定に関する案内が公開された事実に限定しています。案件の合格率、確認時間、利益の計算例、7日間の確認方法は、読者が自分の業務へ置き換えるための実務提案です。公式発信が読者の結果を保証するという意味ではありません。

動画の公開状況や比較への関心は補助資料として扱います。新型Claude Opus 5を扱う動画、Anthropicの新AIモデルOpus 5を扱う動画、CodexとClaude Codeの連携を扱う動画も話題の方向を知る手がかりですが、案件の合否や利益を裏づける資料ではありません。

出典URL

• @ClaudeDevs「Claude Sonnet 5.5 is out」
• @ClaudeDevs「評価設計と反復改善の案内」
• @claudeai「Sonnet 5とSonnet 5.5の初期比較」
• YouTube「Claudeでカルーセルを無料作成」
• YouTube「ChatGPT対Claude、プログラミング最強は？」
• YouTube「新型Claude Opus 5、低価格でFable 5に匹敵」
• YouTube「Anthropic、新AIモデルOpus 5を公開」
• YouTube「CodexとClaude Codeが公式連携、開発力向上」