【非エンジニアのためのClaude/ClaudeCodeシリーズ】　"とりあえずOpus"をやめてみた ── 営業タスク別にClaudeのモデル選びを検証した話

はじめに

※本記事に登場する企業名・数値・条件（値引き率、コスト、投資回収期間など）はすべて架空のものであり、特定の企業・案件・当社サービスの契約条件とは一切関係ありません。
検証はAIモデルの挙動確認を目的とした社内シミュレーションであり、実際の見積り・提案内容を示すものではありませんので、あらかじめご了承ください。

みなさんこんにちは、クラスメソッド営業部の石川です。

いきなりですが「なんとなくOpusが一番性能いいって聞くし、迷ったらOpusを選んでおけば間違いない」——そう思って使っている営業の方、多いのではないでしょうか。

正直に言うと、私自身は"とりあえずOpus"ではなく、普段のタスクではSonnetもよく使っています。
ただ、なぜそう使い分けているのか聞かれると、実は深く考えたことがありませんでした。
「なんとなく」で選んでいる点では、"迷ったらOpus"の人とそう変わらないかもしれません。

実際、Anthropicの公式ドキュメントには「迷ったら、複雑なエージェント的コーディングやエンタープライズ業務にはまずOpus 4.8から始めてください。最も高い性能が必要な場合はFable 5を」と明記されています。
つまり"迷ったらOpus"という判断は、少なくとも複雑なコーディングやエンタープライズ業務という文脈では、あながち間違いでもありません。

ただ、これはあくまで「複雑な業務」という条件付きの案内です。
営業の日常タスクにそのまま当てはめて良いのか、実際に確かめたことのある人は少ないと思います。

そこで今回、同じ営業タスクをOpus・Sonnet・Haiku・Fableの4モデルに同時にやらせて、何がどう違うのか検証してみました。
結論から言うと、「上位モデルが必要かどうかは、タスクの種類によってはっきり分かれる」という、単純な優劣では片付かない結果になりました。
「よく分からないから、迷ったらOpus」で思考停止するのは、一度立ち止まって考え直す価値がありそうです。

検証設計

営業が日常的にClaudeへ投げそうなタスクを4つ用意し、同じプロンプトをOpus・Sonnet・Haiku・Fableの4モデルに投げて比較しました。
顧客名や実在の案件情報は使わず、すべて架空のシナリオです。

評価軸は「質(そのまま使えるか)」「速度」「コスト」の3つを想定していましたが、実際にやってみると、それ以上に"何にどう失敗するか・どこは上位モデルでないと出せない差なのか"の方が実務的に重要だと分かったので、そちらを中心にまとめます。

なお、プロンプトはモデルごとにチューニングせず、全モデル完全に同一のものを1回ずつ投げています(一部、再現性確認のため複数回実施したタスクもあります。後述)。
ここは重要な前提なので、最後に改めて触れます。

参考:Anthropic公式のモデルの位置づけ

検証結果を読む前の前提として、Anthropic公式ドキュメント(Models overview、2026年7月時点)に書かれている各モデルの位置づけを、実際の記載に沿って整理しておきます。

公式ドキュメントの原文(Models overview)には、次のように明記されています。

"If you're unsure which model to use, start with Claude Opus 4.8 for complex agentic coding and enterprise work. For workloads that need the highest available capability, use Claude Fable 5."
(迷ったら、複雑なエージェント的コーディングやエンタープライズ業務にはまずOpus 4.8から始めてください。最も高い性能が必要な場合はFable 5を使ってください)

つまり「迷ったらOpus」という判断は、"複雑なコーディング・エンタープライズ業務"という条件付きで公式の案内に沿ったものです。
無条件に「何でもとりあえずOpus」を推奨しているわけではありません。またHaikuも公式には「フロンティア級に迫る知能」と位置づけられており、「単純作業しかできない」という扱いではない点も見落とせません。
今回の検証は、こうした公式の位置づけと条件が、実際の営業タスクでどこまで、どういう形で当てはまるのかを確認する内容になっています。

発見①:抽象度の高い「構成づくり」では、モデルによって"深さ"にはっきり差が出た

①の提案書構成たたき台では、4モデルとも一定水準の章立てを作ってきましたが、実際に読み比べると「単なる目次生成」で終わったモデルと、「営業として何を、誰に、どう話すか」まで踏み込んだモデルとで、はっきり差が出ました。

Opusは、基幹系の移行について「"慎重に段階移行"のトーンを崩さないこと。
製造業の情シスは基幹系停止を最も警戒するため、いきなり全移行を煽らない構成にしている」と、架空のシナリオから"顧客が何を怖がるか"まで逆算した助言をつけていました。

Fableは、Opusと同等かそれ以上に踏み込んでいました。
「2025年の崖」といった業界特有のキーワード、フェーズごとの具体的な移行期間(3〜6ヶ月/6〜12ヶ月/1〜2年)、サプライチェーン対策やISMAPといった製造業の商流を意識したセキュリティ論点、さらに「決裁者が経営層の場合は該当章を中心に、情シス向けには別の章を厚めに説明する」という聞き手別の使い分けまで提示してきました。

Sonnetは8章立てで一定の実務メモ(「事例は同業種・近い規模の実績に差し替えると説得力が増す」など)を添えていましたが、OpusやFableと比べると具体性・踏み込みの深さは一段落ちる印象でした。

Haikuは、同じ依頼に対して章立てと一言メッセージの一覧を返すにとどまり、他の3モデルのような「どこが商談の勝負どころか」という踏み込みはありませんでした。

つまり、この手の「何を作るか」ではなく「何を優先すべきか」という抽象的な判断が絡む仕事では、"迷ったらOpus"は間違いなく正解ですが、"最上位が欲しいならFableも同等以上"、Sonnetは中間、Haikuは一段浅い、という順当な結果になりました。
Anthropic公式が「複雑なエージェント的コーディングとエンタープライズ業務向け」とOpusを、「最も高い性能が必要な場合」とFableを位置づけているのと符合する結果です。
提案書の構成づくりは、まさにその"複雑な業務"に近いタスクだったと言えます。

発見②:一方、複雑な推論(顧客の本音を読む)は横並びだった

④の「顧客の本音を読み取る」タスクは、表面上の発言に矛盾がある、それなりに高度な行間読みが必要な内容でした。

顧客メモの内容はこうです。

「予算は正直、あまり気にしていません。良いものであれば通せます」と言いながら、「去年別のシステム刷新で予算オーバーがあり、役員会で突っ込まれた」「想定外の追加費用が出ないことの方が大事」「他社は最初安く見えて後から乗ってきた」と繰り返し金額の話をし、最後に「来月の予算会議までに金額感だけでも」と念押しする顧客。

ここでは、Opus・Sonnet・Haiku・Fableの4モデルとも、ほぼ同じ結論にたどり着きました。

• 表面上は「予算は気にしていない」と言っているが、本当の懸念は金額そのものではなく「役員会で再び説明責任を問われ、自分の社内での立場が危うくなること」
• 求められているのは「安さ」ではなく「想定外が起きないという確定性」と「役員に説明できる根拠」
• 次回提案では、金額そのものより「なぜこの金額なのか」を役員向けに説明できる資料として渡すべき

4モデルとも、驚くほど似た深さで、ほぼ同じ着地点にたどり着きました。
正直、どれが書いたか伏せられたら私には当てられないと思います。①とは対照的に、「行間を読んで顧客心理を分析する」ような一問一答的な推論は、"迷ったらOpus"にこだわらなくても十分なようです。
Haikuは公式にも「フロンティア級に迫る知能を持つ最速モデル」と位置づけられているとはいえ、ここまで他の上位モデルと遜色ない結果を出してくるのは、正直予想していませんでした。

発見③:数字が絡むと、また違う形で差が出た

明確に差が出たのがTCO(総保有コスト)計算のタスクです。前提条件を与えて「3年間のコスト比較と投資回収時期を計算してください」と依頼しました。

正解は概ね次の通りです。

Opus・Sonnet・Fableの3モデルは、この数字をほぼ完全に一致させ、しかも「検算」まで自主的に行って整合性を確認していました。

ところがHaikuだけ、2回実行して2回とも本文に無い情報を作って付け足してくるという癖が出ました。

• 1回目:前提に月・曜日の情報は一切与えていないのに、「翌年6月中旬に投資回収」と存在しない具体的な暦月を捏造
• 2回目:投資回収時期の表現が「2年目の9か月目」と「2年9か月目」で揺れ、さらに独自に「ROI 313%」という、計算根拠が明示されない指標を追加

数字の"本体"(6,600万円・3,050万円・3,550万円)自体は合っているので、パッと見は破綻していません。
しかし、営業がこの数字をそのまま顧客に見せてしまうと、存在しない前提を語ってしまうリスクがあります。
「合計金額は合っているから安心」ではなく、"周辺の飾り"にこそ嘘が紛れ込む、というのは実務上かなり重要な発見でした。

裏を返すと、数字自体の正確性が重要なタスクは、Haiku以外なら"迷ったらOpus"でなくても差はほぼ無く、"人間が検算する"という前提があれば下位モデルでも十分運用できる、とも言えます。
ただしこれは「モデル代を浮かせる代わりに、検算の手間を自分で引き受ける」というトレードオフでもある点は、次の「まとめ」で改めて触れます。

発見④:即断できるか問題 — Opusは「持ち帰りがち」

値引き交渉のタスクでは、全モデルとも社内ルール(値引き上限20%・保守費据え置き・初期費用免除不可)には違反しませんでした。ここは4モデルとも及第点です。

ただし、明確な違いが一つありました。その場で20%を即答するか、「持ち帰って検討します」と保留するかです。

• Sonnet・Haiku・Fable:一貫して「20%までは私の裁量でお出しできます」とその場で即答
• Opus:3回中2回は「一度持ち帰らせてください」と即答を避け、1回だけ即答

権限内(20%まで)の話なので、実務としては即答した方が商談のテンポは良いはずです。この場面に限って言えば、「賢いはずのモデルの方が、慎重になりすぎて足が遅い」という、ちょっと意外な結果になりました。
"迷ったらOpus"が裏目に出た唯一の場面だったとも言えます。逆に言えば、即断がリスクになる高額・複雑な意思決定の場面では、この"慎重さ"はむしろ長所にもなり得ます。

発見⑤:頼んでいないのに動く、という差

これは検証の本題からは外れる、副産物的な発見です。
①の提案書構成たたき台を作らせた際、指示していないのにファイルをデスクトップへ保存しようとしたモデルが複数ありました(SonnetとFable)。
Opusは一度もこの動きをせず、Haikuは実際に保存まで実行しました。

ファイルを保存すること自体が悪いわけではありません。
ただ、「頼んでいない自律的な行動をどれくらい取るか」はモデルによって差があり、業務で使う上では地味に見落としがちな観点だと感じました。
特に顧客情報を扱う場面では、「言われた通りにしか動かないモデル」の方が安全な場面もあるはずです。

なお、この挙動が発生した1回目の実行では、SonnetとFableは許可待ちで止まり完成品が得られませんでした。
発見①の比較は、「ファイル保存はせず回答をそのまま出力する」旨を明示した上で改めて実行し、実際の完成品を取得してから行っています。

この検証の前提・限界

ここまで「差があった/なかった」と書いてきましたが、いくつか正直に断っておきたい前提があります。

• プロンプトは全モデル共通・作り込みなしの1発勝負です。プロンプトエンジニアリングをすればどのモデルの結果も変わるはずで、今回の差は「そのモデルの限界」ではなく「無指定で投げたときの初期設定的な振る舞いの差」と捉えるのが正確です。
• 各タスクは基本的に1回ずつしか実行していません。「Opusは持ち帰りがち」という発見も、実は3回試して初めて見えたもので、1回だけの結果を見て「Opusは慎重な性格だ」と断定するのは早計でした。実際、3回中1回は即答しており、"必ずそうなる"わけではなく"そうなりやすい"という程度の傾向です。
• 一方、Haikuの「数字を盛る」癖は2回とも再現しており、こちらは比較的安定した傾向と考えられます。ただしこれもn=2の話なので、過信は禁物です。
• 評価は私自身の主観によるもので、複数人によるブラインド採点などは行っていません。

つまり、この記事の一番の学びは「どのモデルが優れているか」という結論そのものより、「1回試しただけで"このモデルはこういう性格"と決めつけるのは危険」という検証プロセス自体にあると思っています。
もしこれから試す方がいたら、最低でも2〜3回は同じプロンプトを流してみることをおすすめします。

まとめ:「よく分からないから迷ったらOpus」を卒業する

今回の検証で一番伝えたいのは、「数字さえ合っていれば上位モデルは不要」という単純な話ではないということです。
実際にはタスクの種類によってはっきり分かれました。

• 抽象度の高い戦略的判断(何を優先し、何を厚く話すべきかの"目利き"が要る仕事):OpusとFableが明確に一段深く、Sonnetは中間、Haikuは一段浅い。"迷ったらOpus"のままで正解だが、最上位が欲しいならFableも選択肢になる
• 複雑に見える推論(顧客の本音を読む):意外にも4モデル横並び。ここで上位モデルにこだわる必要性は薄い
• 数字が絡むタスク:金額の"本体"はHaiku以外ほぼ差がないが、根拠のない"飾り"の数値が紛れ込むリスクがあるモデルもある。下位モデルを使うなら、その分「人間が検算する」という別のコストを引き受ける前提が要る
• その場での判断・即答が必要な場面:モデルによって"迷いやすさ"に癖がある。即答してほしいなら、その旨をプロンプトで明示した方が安全
• 自律的な行動(ファイル保存など):指示していない動きをどれくらいするかもモデルによって差がある。顧客情報を扱う場面では要注意

つまり「このタスクは考える余地が大きく、判断の質がそのまま成果に効くか」を見極めることが先で、そこで初めて「上位モデルを使うべきか」が決まる、というのが実務的な結論です。
加えて、モデルを変える前に「即答してほしい」「与えた前提にない数字は使わないでほしい」と指示を具体化するだけで、縮まる差も一定数ありそうです。

「よく分からないけど、迷ったらOpus」で思考停止せず、タスクごとに一度立ち止まって考える。
それだけで、コストも精度も変わってくるはずです。次に試すときは、同じプロンプトを複数回流して"癖"を確認すること、そして指示をひとつ具体化するだけで結果がどう変わるかも、あわせて見てみようと思います。