Claude Codeで進めるAI駆動開発。Opus 5.5とSonnet 5.5をどう使い分ける？
要件定義・設計はOpus、実装・ユニットテストはSonnet。実測結果からAI駆動開発の役割分担を考える。最後にGPT-6.1 Sol、Gemini 3.8 Flashを加えた4モデル比較も。
前回、Claude Opus 5.5、GPT-6.1 Sol、Gemini 3.8 Flashに、同じ仕様・ルール・ハーネスを渡して、同じWebアプリを作らせてみました。
そこで印象的だったのが、Claude Opus 5.5です。
3モデルの中では一番時間がかかりました。
その一方で、103件のテストを作り、ブラウザでも22項目を確認し、こちらから細かく指示していないエッジケースまで自分で探していました。
かなり慎重です。
そこで、もう一つ気になりました。
同じAnthropicのClaude Sonnet 5.5なら、同じ仕事をどう進めるんだろう？
Opusほど慎重なのか。
それとも、もっと速く進めるのか。
そして、システム開発でClaude Codeを使うなら、結局どちらを使うのが効率的なのか。
今回は、前回と同じ条件でClaude Sonnet 5.5にも同じアプリを作らせて比較してみました。
Claude Codeで、OpusとSonnetはどこまで違う？
今回比べるのは、
Claude Opus 5.5
Claude Sonnet 5.5
です。
どちらもAnthropicのClaude 5.5シリーズですが、公式の位置づけは少し違います。
AnthropicはSonnet 5.5を、Opus 5.5を補完する、より高速で低コストなモデルとして位置づけています。
特に、
日常的な開発
機能追加
バグ修正
コードレビュー
範囲の明確なタスク
に向いているとしています。
一方のOpus 5.5は、より複雑で慎重な判断が必要な仕事向けです。
大規模なコードベースでの長時間作業、デバッグ、リファクタリング、コードレビューなどで、変更前に原因を探し、作業しながら自己確認することを強みとしています。
つまり、最初から役割が少し違います。
今回の実験でも、その違いはかなりはっきり出ました。
今回も、まったく同じアプリ・同じ条件で比較した
今回も前回と同じ、問い合わせ管理アプリ「Inquiry Flow」を作らせています。
機能は、
問い合わせ一覧
登録
編集
削除
検索
絞り込み
ソート
ダッシュボード
変更履歴
入力チェック
エラー処理
更新競合への対応
など。
単純なTodoアプリよりは少し実務寄りです。
そして、モデル以外の条件はできるだけ揃えました。
同じ仕様書
同じ15のルール
同じハーネス
同じ8つのスキル
同じ開始プロンプト
同じ完了条件
を渡しています。
AIには単に、
「このアプリを作って」
とは頼んでいません。
仕様を確認して、環境を調査して、計画して、実装して、テストして、自分でレビューし、問題があれば直して、最後に結果を記録するところまで仕事として渡しています。
Opus 5.5は時間を使ってかなり深く確認した
まず前回のClaude Opus 5.5です。
完成まで約27分。
人間への質問は0回。
人間からの技術介入も0回でした。
そして特徴的だったのが、テストと確認の量です。
Opus 5.5は、
Unit Test 57件
API Test 33件
UI Test 13件
合計103件のテストを作りました。
さらにブラウザでも22項目を確認しています。
新規環境へGit管理ファイルだけをコピーして、本当に最初からセットアップできるかまで検証しました。
そして、その確認中に新しい問題まで見つけています。
さらに自己レビューでは、SQLiteとPrismaの部分一致検索で`%`や`_`がワイルドカードとして扱われる問題まで自分で見つけて修正しました。
こちらから、
「そこまで確認してください」
とは指示していません。
かなり慎重です。
Sonnet 5.5は、約11分で53テストまで進めた
ではSonnet 5.5はどうだったか。
結果はかなり面白いものでした。
Phase Aの初期実装は、
約11分。
ほぼGPT-6.1 Solと同じ速度です。
その間に、
一覧
登録
編集
削除
検索
絞り込み
ソート
変更履歴
ダッシュボード
Zodによる入力検証
更新競合
エラー処理
Seed
まで完成しました。
さらに、
npm install
Migration
Seed
lint
53テスト
build
本番ビルドでのAPI確認
まで完了しています。
そしてこちらも、
人間への質問0回。
人間からの技術介入0回。
でした。
速いだけではなく、テストの中身まで見直していた
Sonnet 5.5で印象的だったのが、自己レビューです。
一度テストが通ったあと、
「DB障害時は503になる」
という名前のテストを自分で見直しました。
すると、そのテストが実際には汎用Errorによる500しか確認しておらず、テスト名と検証内容が一致していないことに気づきました。
そこで、
PrismaClientInitializationError → 503
汎用Error → 500
としてテストを分離し直しています。
つまり、
テストがPASSしたから終わり
ではありません。
そのテスト、本当に確認したいものを確認している？
というところまで見直しています。
ここはClaudeらしさを感じました。
Sonnet 5.5は、安定して完走することを優先したように見えた
もう一つ面白かったのが、ライブラリの選び方です。
Sonnet 5.5は、
Next.js 15
Prisma 6
MUI 7
Zod 4
Vitest 3
ESLint 9
を選択しています。
最新版を無条件に選ぶのではなく、挙動を把握している安定版を意図的に使っています。
これは実務ではかなり合理的です。
新しいバージョンほど良いとは限りません。
特にAIエージェントに仕事を任せる場合、ライブラリの最新仕様に振り回されて試行錯誤が増えるより、安定した構成で短時間に完走した方が良いケースは多いです。
今回Sonnetが約11分で終えられた理由の一つは、こうした判断にもありそうです。
OpusとSonnetを並べると、役割の違いがかなり分かりやすい
今回の結果を並べると、こうなります。
かなり分かりやすいです。
Opus 5.5は、
時間を使って、確認範囲をどんどん広げる。
Sonnet 5.5は、
必要な品質を確保しながら、速く前へ進む。
という違いが見えました。
Anthropic公式の位置づけとも、今回の結果はかなり一致していた
ここが今回の比較で興味深いところです。
AnthropicはSonnet 5.5について、
well-scoped everyday tasks
つまり、範囲の明確な日常的な仕事を得意とすると説明しています。
コーディング用途でも、
機能開発
バグ修正
コードレビュー
コードベースを素早く理解する
変更範囲を絞る
といった用途を挙げています。
一方、Opus 5.5は、
複雑な仕事
慎重な判断
長時間のagentic coding
大規模コードベース
root causeの特定
継続的な自己確認
に向いています。
今回の実験結果は、この役割分担とかなりきれいに重なりました。
私は「考えるOpus、作るSonnet」で使っている
実際、私は普段のClaude Codeで、この2モデルを同じようには使っていません。
大きく分けると、
Opusで考える。
Sonnetで作る。
という使い方をしています。
要件定義・分析はOpus
要件定義では、
本当に必要なものは何か
要件同士に矛盾がないか
抜けている非機能要件はないか
将来変更で問題になりそうな部分はどこか
複数の選択肢のどれを採用するか
など、コードを書く前の判断が重要です。
ここはOpus 5.5を使います。
間違った要件を決めてしまえば、その後Sonnetがどれだけ速くコードを書いても全部やり直しになるからです。
アーキテクチャやDB、API設計もOpusに任せる
設計も同じです。
私は、
アーキテクチャ
DB設計
API設計
データ構造
境界の設計
例外処理
更新競合
Migration方針
などはOpus側でしっかり考えさせます。
ここでは「速くコードを書くこと」より、
あとで困らない判断をすること
の方が重要です。
Opusは今回の実験でも、時間を使ってかなり慎重に確認しました。
この性格は、上流工程ではむしろメリットです。
テストも「考える仕事」と「作る仕事」に分ける
私はテストについても、OpusとSonnetを分けて使います。
テストで一番難しいのは、テストコードを書くことではありません。
難しいのは、
何を壊しにいくのか
どこが境界値なのか
どんな異常系があり得るか
状態遷移のどこが危ないか
どの組み合わせが漏れやすいか
どんなテストデータが必要か
失敗した場合に何を保証すべきか
を考えることです。
これはOpus向きです。
なので、
テスト設計・テストデータ設計 → Opus 5.5
で考えます。
その設計をもとに、
Vitestを書く
Playwrightを書く
テストを実行する
失敗を修正する
回帰テストを回す
という処理はSonnet 5.5へ渡します。
ここは「考える」より「大量に作って回す」要素が強いからです。
設計が固まったら、実装はSonnetに任せる
要件や設計が固まった状態なら、
API実装
CRUD
UI実装
Unit Test
バグ修正
lint修正
buildエラー対応
通常のリファクタリング
はSonnetに任せることが多いです。
今回の実験でもSonnetは約11分で53テストまで作って完走しました。
つまり、
設計済みの仕事を高速に実行する
という使い方は、かなり相性が良いと感じています。
Sonnetで粘りすぎず、難しくなったらOpusへ戻す
ただし、すべてSonnetで押し切るわけではありません。
私はSonnetで作業していて、
同じエラー修正を何度も繰り返す
原因説明ができない
仕様と実装に矛盾が出てきた
DB変更の影響範囲が大きい
セキュリティに関わる
大規模な設計変更が必要
複数ドメインをまたぐ
既存テストは通るのに、挙動に違和感がある
といった状況になったら、Opusに戻します。
安いモデルで延々と試行錯誤するより、判断が難しいところだけOpusに戻した方が全体として安くなることがあります。
これは、AIモデルのコストを見るうえでも重要です。
Claude Codeなら「Opus → Sonnet → Opus」が効率的
今の私の使い方をかなり単純化すると、こうなります。
要件整理
分析
要件定義
設計
テスト設計
テストデータ設計
↓
Claude Opus 5.5
↓
設計書・仕様書を確定
↓
Claude Sonnet 5.5
↓
コード実装
Unit Test作成
テスト実行
バグ修正
lint / build
↓
必要に応じて
Claude Opus 5.5
↓
重要な最終レビュー
高リスク部分の確認つまり、
Opus → Sonnet → Opus
です。
ずっとOpusでもありません。
ずっとSonnetでもありません。
判断コストが高い工程はOpus。
実行量が多い工程はSonnet。
という分け方です。
現時点のAnthropicラインナップでは、かなり合理的な使い方だと感じています。
Opusを常に使えばいい、ではない
上位モデルを見ると、
「一番性能が高いなら、全部Opusでいいのでは？」
と思うかもしれません。
でも実務では、必ずしもそうではありません。
設計済みのCRUDを作るだけの仕事に、毎回Opusの慎重さが必要とは限りません。
逆に、要件定義で重要な判断を1つ間違えて、数時間分の実装をやり直すくらいなら、最初からOpusでしっかり考えた方が安い。
なので、
一番高性能なモデルを使うこと
ではなく、
高性能なモデルを使うべき工程を選ぶこと
の方が重要だと思っています。
4モデルを並べると、それぞれの役割がさらに見えてきた
前回の記事では、
GPT-6.1 Sol
Claude Opus 5.5
Gemini 3.8 Flash
を比較しました。
そこへ今回のSonnet 5.5を加えると、4モデルの違いがさらに分かりやすくなりました。
これは、モデルの「性能ランキング」というより、
どういう仕事に向いているか
の違いとして見た方が分かりやすいです。
4モデルを見ると、「最強モデル1つ」より役割分担の方が現実的
今のAI駆動開発では、
「どのモデルが一番強い？」
という質問自体が、少しずつ意味を失ってきているように感じます。
私なら、今回の結果からはこう使い分けます。
もちろん、これは今回の実験と私の実務での使い方をもとにした整理です。
万能の正解ではありません。
でも少なくとも、
「Opusが一番上位だから全部Opus」
という使い方より、
工程ごとにモデルを切り替える
方が、速度・品質・コストのバランスは取りやすいと思っています。
さらにHaikuを入れると、3層構成もできる
AnthropicにはHaikuという、さらに軽量なモデルもあります。
そう考えると、Anthropicだけでも、
Opus＝考える
Sonnet＝作る
Haiku＝大量に回す
という3層構成がかなり自然です。
たとえば、
Opusが設計を作り、
Sonnetが実装し、
Haikuが大量の分類、定型テスト、ログ確認などを処理する。
こうなると、AIを1モデルとして考えるより、
複数のAI社員に役割を割り当てる
ような感覚に近づいていきます。
まとめ：上位モデルを常に使うより、工程ごとにモデルを変える
今回、Opus 5.5とSonnet 5.5に同じ仕事を任せてみて、かなり役割の違いが見えました。
Opusは慎重です。
時間を使って、深く考えて、確認する。
Sonnetは速いです。
必要な品質を確保しつつ、どんどん前へ進む。
どちらが上か、という話ではないと思っています。
私が今のClaude Codeで一番しっくりきているのは、
考える仕事はOpus。
作る仕事はSonnet。
です。
要件を整理する。
分析する。
設計する。
複雑なテストを考える。
ここはOpus。
その設計をもとに、
コードを書く。
Unit Testを書く。
テストを回す。
バグを直す。
ここはSonnet。
そして重要なところだけ、最後にもう一度Opusで見る。
Opus → Sonnet → Opus。
今のAnthropicでAI駆動開発をするなら、かなり効率のいい流れだと感じています。
そして今回の4モデル比較を見ても、同じことを感じます。
もう、
「最強のAIを1つ選んで全部やらせる」
より、
「仕事ごとに、一番向いているAIへ割り当てる」
方が自然です。
モデルが増えるほど、AIを選ぶ能力そのものが、開発する側の新しいスキルになっていくのかもしれません。
