■ はじめに
弊社でも Claude Code の活用を進めています。
この記事では、実際に業務の中で Claude Code の Opus と Sonnet を1週間ずつ使い比べた結果を元に、
- どんな違いがあるか
- 分かったこと
- なぜその差が発生しているのか考えたこと
についてお話しします。
■ わたしがやりました
(Generated by Gemini 2.5)
8月中旬に社内の Claude Code が Rate Limit を迎えました。
原因は、私が気が付かず Opus を常用していた事 でした...🙇
気がついたタイミングから Opus → Sonnet へと切り替えたため、せっかくなのでどんな違いがあったか共有しようと生まれたのが LT/この記事となります。
■ 本記事のざっくり結論
□ Opus/Sonnet を使い比べたファーストインプレッション
- Opus を使った感想：「もう Claude Code だけでいいな」「とにかくストレスフリー」
- Sonnet を使った感想：「
Opusが恋しい・・・」「だいぶ良いけどもう少しだな・・・」
Opus の方が3倍賢く、10倍のおもんぱかり力を感じる。
そして1000倍ストレスフリー。
個人的には Opus と「同じ利用の仕方」をしようとすると、Sonnet は 500倍位ストレスを感じてしまう状態です。
□ なら Sonnet ではダメか？
そんな事はなさそうです。
あくまでも 上記の感想は Sonnet を何もカスタムしていない状態 のもの。
適宜 megathink するだけでアウトプットが良化する（コストも上がる）ので、プロンプト含め工夫の余地は非常に大いです。
小さな課題に分割したり、答えが見えているコードや設計は人間が書くなど運用面でも工夫のしがいがあります。
ただし 感覚的に Opus レベルのストレスフリーを目指すのであれば、かなりのカスタマイズや工夫が必要そうな印象 があります。
□ これら Sonnet と Opus の違いはどこから来るのか？
Opus と Sonnet には解決したいゴールへのアプローチに違いがある ように感じます。
実際に使い比べた所、
- きちんと課題に対して思考して解決・回避しながらゴールを目指す Opus
- コスト重視でとにかくゴールに向けて最短距離を走ろうとする Sonnet
という印象を受けました。
Sonnet で発生しがちな種々の問題（後述）は、この特性に根ざしている可能性があります。
結果として Sonnet と上手く付き合うには、今までの LLM 同様、その特性をよく踏まえた工夫が求められそうです。
■ 本記事の前提
□ Claude Code のバージョン
Claude Code CLI のバージョンは最新版を利用しており、
2025年8月中旬ごろという時期的に Ver.1.0.80 ～ 1.0.9x となります。
□ 現状の Claude Code の大まかな使い方
基本的に完全自動にはしないで都度人間が確認する。
Opus を使っているときはコーディング部分は一定量自動化していました。
Sonnet の場合は驚くような修正をしてくる事があるためあまり自動化していません。
開発手順は以下の通り。
- Issue またはリポジトリの Markdown に詳細な要件・仕様を書く or コンソールに手で打ち込む
- Issue/Markdown の場合は gh コマンドで読み込む
- Plan mode で設計
- 会話しながら設計をブラッシュアップ
- 質問をぶつけたり、こっちの方が良くない？こんなアイデアはどうかな？ と相談したり。
- 適宜 Mermaid でクラス図を出してもらったり。
- 実装が出来そうなレベルに到達したら実装を依頼
- 適宜、指摘・提案・設計依頼を繰り返しながら完走を目指す。
- Sonnet を使う場合、明確な答えが分かっている部分などは人間がコードを書きます。
- テストを書いてもらう
- コミットしてもらう
- PR を作って貰う
□ 現状のトライしている Issue のイメージ
- 簡単なもの
- 画面幅によって画面上のラベルやコンポーネントが見切れてしまう Issue
- 難しいもの
- 認可システムに新たな機能を追加する Issue
■ やってしまったからこそ見えてきた Opus と Sonnet の違い
▷ Opus と Sonnet を使っての感想と差分の具体例
事故？ で Opus を使ってしまった訳ですが、どちらもそれなりに使ってみての感想は、
- Opus：「もう Claude Code だけでいいな」「とにかくストレスフリー」
- Sonnet：「
Opusが恋しい・・・」「だいぶ良いけどもう少しだな・・・」
でした。
まずは、具体的に使ってみてどんな所が違ったのかをざっくり紹介します。
□ 具体的に Opus と Sonnet でどんな事が違ったか
-
Sonnet はちょいミスの指示やちょっとアバウトな指示をするとすぐ間違える。
その上で試行錯誤を繰り返し、結局失敗する。- Opus は良い感じに解釈してやってくれる他、あまり勝手にやらない。
- Sonnet は「確かにその方法でもできるが、もっと簡単かつ安全な方法があるよね？」といった回答を出しがち。
-
gh コマンドつかってこのファイル読んでね！ がスムーズにいかない
- Opus は一発ないし、ミスをしても軽い指摘で良い感じにこなしてくれる。
- Sonnet はなかなかうまくいかず、試行錯誤して結局人間がコマンドを提供することに。
-
こういう方針で実装します。別ブランチにサンプル実装があるから読んで考えてね！ がスムーズにいかない
- Opus は1発でコマンドで別ブランチのファイルを直接参照する。
- Sonnet はブランチを切り替えようとしてしまう。
-
enum の選択肢を一部取り逃がす
- Opus は enum の値3種を全てクラスコメントに漏らさずに書く。
- Sonnet は2個のみをコメントに書いた。
- 一部だけ間違っている状態は、不足や明らかな誤りと比べて人間が気が付きづらい。
-
Sonnet だと修正が細切れになってしまう。
- Opus は関係箇所を同時に修正してくれる。
- Sonnet は変更点が細切れに出てきがち。
- 作業が小分けになるため、特に人間が複数の作業を抱えている場合に確認しづらい。
- ちょいミスやちょっと違うな～ というコードが回答として含まれがちなため、人間がチェックを入れないと予期せぬ方向への暴走に直面しがち。
-
Sonnet が勝手に存在しない Controller の RequestSpec を作り始める。
- 曰く、実装のガイドになるから！
- TDD かな...？ もう実装終わってるんだけど...？
- routes がないからほぼ全部 404 になる = エラーになるんだけど・・？
- （とても面白い発想ではあり、しばらく上手く使えないかチャレンジしたがお蔵入りしました）
- 曰く、実装のガイドになるから！
-
Sonnet が
git add .で関係ないファイルも追加しようとするので CLAUDE.md で禁止したら、1ファイルずつ小分けに add しようとしてくる- 確かに
.は禁止したけど、そうなんだけど... わたし5回実行していいか聞かれるの・・・？
- 確かに
-
Sonnet ちゃん！！ 通らないからってテスト消そうとしないで！！！
-
Sonnet ちゃん！！ 全然テスト直せないからって前提を変えないで！！！！
・・と、ちょっと惜しいものから宇宙猫みたいな顔になるものまで様々。
特に Sonnet は エンジニアとして絶対に選択してはいけない禁忌肢 を気軽に採用してしまうのがネックです。
これらは、恐らく Sonnet に直接渡すには複雑すぎる難易度・サイズ感の物が含まれていたことも原因のひとつでしょう。
▷ Opus と Sonnet の間違い方はベクトルが全く違う
実例を上げたように、Sonnet は驚くような間違いや提案をする数が多い印象です。
Opus と Sonnet の回答を改めて比較すると...
-
Opus の間違えは「いけるがちょっと方向性が違う」 というイメージ。
-
Sonnet の間違えは「そもそもやり方が異なる」 や 「許してはいけないことを平然とやる」 というイメージ。
- なんで！？ みたいな修正をしようとするのも Sonnet に多い。
- 同じことを繰り返して間違い続けるのも Sonnet に多い。
- これらを人間が常に毎回補助するとストレス & 手間がかかりすぎるので、カスタマイズして抑える事になるが簡単ではない。
-
エンジニアとしてやって良いことと悪いことの判断、つまり「エンジニア倫理」が Opus の方が圧倒的に高く感じる。
- Opus は今まで LLM に感じていたイラッと感・もにょっと感の質・量がともに少ない。
- 目先の解法に飛びついて解決しましょう/しました！ の発生頻度が圧倒的に少ない。
- 仮に良くない回答を返してきたとしても、それなりに筋が通っているので納得したうえで「ならどうする」に繋げやすい。
▷ なにより、人間の介入の数・質だけでなく「感情」に差が出る事が一番大きな違い。
LLM のクオリティ向上で人間の介入の数や質に差が出るのは当然とても嬉しいです。
しかし忘れてはいけないのが 人間の感情面 です。
期待通りに動作する、期待通りでなくとも納得できる動作をする というのはとても大事です。
不要な感情の上下動は判断ミスにも繋がるし、なければないに越したことはないですよね。
その点 Opus は LLM の延長線から少し外れた部分にいる 感覚で、エンジニア倫理から外れない 「エンジニアの当たり前」 に該当する答えを出しやすい印象です。
したがって答えが合っていても間違っていても悪い意味での驚きが少なく、一緒に働くパートナーとしてとても魅力的です。
一方 Sonnet は良くも悪くも今までの LLM の延長線上にいる ように見えます。
したがって Sonnet と上手く付き合うには、いかにレールを引くか、ガードレールを与えるか、道から外れたら戻せるか、戻せなかったらリセットするか。コンテキストを与えるか、あるいは小さく分割して渡すか・・・ という今までと変わらない工夫がより必要となります。
では、ここからは なぜ Opus と Sonnet に違いが出るのか、使ってみた感じた傾向から考えてみます。
▷ Opus と Sonnet の課題解決の方針の違い（イメージ）
上記のように事故（？）で Opus を使って、その後 Sonnet を使って・・とそれなりにガッツリ使った印象だと、
- きちんと課題に対して思考して解決・回避しながらゴールを目指す Opus
- コスト重視でとにかくゴールに向けて最短距離を走ろうとする Sonnet
という差があるように感じました。
Sonnet は目的さえ達成出来れば過程なぞどうでも良いよ という感じの挙動をするので、エンジニアにとっては問題に感じる回答をするのではないかなと考えています。
絵に起こすと以下のような形です。
□ 解きたい課題に対するゴールがあるとして...
□ 通常はこんな感じで課題が間に色々あって直通ではゴールに行けない。
□ Opus は課題をきちんと解消したり回避したりする方法を考える = 回り道を許容する
□ Sonnet は全てを無視してゴールへ最短距離で進もうとする（コスト重視？）
□ Sonnet はなぜエンジニア倫理が無く見えるのか？
以上のように、Sonnet はとにかく最短距離を走ろうとするのでエンジニア倫理が無く見えるのでは？ と予想しています。
その結果、
- Sonnet ちゃん、勝手に作業やめないで！！！
- Sonnet ちゃん、勝手に仕様変えないで！！！
- Sonnet ちゃん、勝手に（）
が発生したり、テストやクラスを消して強引に解決に行こうとする のではないかなと考えています。
あくまでも個人的な予想になりますが。
「テストを通す」という目的ならば、テストを消せば当然テストは落ちなくなります。
もちろんエンジニアとしてそれを許すことは通常ないのですが、とても合理的かつ最短の解決方法ではあります。
Sonnet は最終的なゴールを目指すさなかの1ステップのゴールを決めてそれを解決する際に、
善悪や倫理に関係なくこうした目先の手段に囚われてしまう傾向があるように思います。
この傾向から「最短距離を走ろうとするのでエンジニア倫理が無く見える」のではないか、と考えています。
一方、「エンジニア倫理がないから最短距離を走ろうとする」という仮説も立ちます。
個人的には Opus だとコストが高すぎるので意図的に Sonnet は最短を目指すようにカスタマイズされている説を推しています（GPT-5 も同じような印象です）。
最短距離を走る説を補強する仮説としては、Sonnet で megathink/ultrathink するとそれなりの成果物が出てくるように見える 点があります。
コストを掛けてもいいからじっくり考えさせるといい成果物が出てくるので、それなりに仮説としては当たらずとも遠からずなのではないかな・・・？🤔
■ まとめ
□ Opus と Sonnet を使い比べるてどちらが良いか？
個人的にはコストさえ考えないのであれば常に Opus。
コスト以外に迷う理由がないレベルの差を感じました。
最短距離を走ろうとする Sonnet と異なり、
Opus は中間ゴールに対してもきちんとしたアプローチをしてくれるため、
エンジニア倫理を守ってくれるように見え、人間の感情面に優しいのが特に好印象です。
□ Opus と Sonnet の差はどこから来るか？
解決したいゴールへのアプローチの違い が挙動の差に出ているのではないかと考えます。
- しっかり考えてゴールに自走する Opus
- ゴールまでを最短距離で走ろうとする Sonnet
という特性の差から、
Sonnet で発生しがちな種々の問題が発生している可能性があります。
結果として Sonnet と上手く付き合うには、今までの LLM 同様、その特性をよく踏まえた工夫が求められそうです。
ぜひ皆さんの考えや経験談をお聞かせいただけると嬉しいです！
□ 最後に
「みんなの想いを集め、社会を良くするお金の流れをつくる」READYFORのエンジニアブログです。技術情報を中心に様々なテーマで発信していきます。 ( Zenn: zenn.dev/p/readyfor_blog / Hatena: tech.readyfor.jp/ )
Discussion