1.はじめに
Claude Codeを使っていると、モデルによって出力の精度が違うことは体感的に分かります。
ただ、実際に開発を何度か行ってきて、本当に効いてくるのはそこではなく、
「機能を追加するたびに、既存の何かが壊れるかどうか」
だと感じました。小さな変更を重ねるうちに、気づけば別の箇所が壊れている。そんな経験をしたことはないでしょうか。
今回はこの差を「機能追加への耐性」という観点で検証してみました。
2.検証の目的
本検証では、モデル差を「初回の出力品質」ではなく、
機能を積み上げていく過程で既存の動作を維持できるか
として可視化します。
3.検証条件
以下条件を揃え検証を行います。
- 同一のベースコードを使用
- 同一プロンプトを使用
- モデルのみ変更
- Claude Code上で実施
3-1.「問題なし」の定義
本記事では、以下を満たした状態を「問題なし」と定義します。
- 指示した機能が正常に動作する
- 既存の機能が壊れていない
- 明らかなレイアウト崩れや不整合が残っていない
問題ありとみなす例
- 機能は動いたが既存の別機能が壊れている
- 指示していない変更が加わり整合性が崩れた
- UIレイアウトが崩れている
3-2.検証対象モデル
| モデル | 特徴 |
|---|---|
| Haiku | 軽量・高速 |
| Sonnet | 中間 |
| Opus | 高精度 |
3-3.ベースとなるアプリ
今回はパスワード生成ツールをベースとして使用します。
機能は以下の通りです。
- 文字数のスライダー・数値入力（連動）
- 文字種チェックボックス（大文字・小文字・数字・記号）
- 生成ボタン
- パスワード表示エリア＋コピーボタン
まずは変更元である、正常に動作する状態の画面
3-4.機能追加の順番
以下の順番で機能追加を指示します。各ステップは1プロンプトのみ。
| ステップ | 追加指示 |
|---|---|
| 1 | パスワードの強度メーターを追加してください |
| 2 | 生成履歴を画面に表示してください（直近5件） |
| 3 | 履歴をLocalStorageに保存し、リロードしても残るようにしてください |
| 4 | 履歴を個別に削除できるボタンを追加してください |
| 5 | 各文字種が最低1文字は必ず含まれるよう保証してください |
4.検証結果
全体結果
| ステップ | Haiku | Sonnet | Opus |
|---|---|---|---|
| 強度メーター追加 | ◯ | △ | △ |
| 生成履歴の表示 | ◯ | × | ◯ |
| LocalStorage保存 | × | ◯ | ◯ |
| 個別削除ボタン | × | × | ◯ |
| 文字種の最低1文字保証 | ◯ | ◯ | ◯ |
◯ 問題なし
△ 動作に問題はないが意図しない変更（アドリブ）が入った
× 既存機能の破損またはレイアウト崩れが発生
実際に壊れた画面の例
ボタン配置のレイアウト崩れ（Haiku）
コピーボタンが履歴欄に混入（Sonnet）
Haiku
| ステップ | 結果 | 詳細 |
|---|---|---|
| 強度メーター追加 | ◯ | 問題なし |
| 生成履歴の表示 | ◯ | 問題なし |
| LocalStorage保存 | × | 保存できたりできなかったりした。また、指示していないグラデーションが自動で追加された |
| 個別削除ボタン | × | 機能は動いたが、コピーボタンと削除ボタンの間に隙間が開きレイアウトが崩れた |
| 文字種の最低1文字保証 | ◯ | 問題なし |
👉 傾向：
- 単純な機能追加は安定している
- 状態管理（LocalStorage）が絡むと不安定になる
- 複数ボタンが増えるとUIの整合性が崩れやすい
- 指示していない変更（アドリブ）が入ることがある
Sonnet
| ステップ | 結果 | 詳細 |
|---|---|---|
| 強度メーター追加 | △ | 問題なし。ただし指示していないグラデーションが自動で追加された |
| 生成履歴の表示 | × | コピーボタンだけが履歴欄に表示されることがあった |
| LocalStorage保存 | ◯ | 問題なし |
| 個別削除ボタン | × | コピーボタンと削除ボタンの間に隙間が開きレイアウトが崩れた |
| 文字種の最低1文字保証 | ◯ | 問題なし |
👉 傾向：
- アドリブによるデザイン改善が自発的に入る
- 履歴表示でコピーボタンが混入するなど、要素の切り分けを間違えることがある
- 複数ボタンが並ぶUIで配置の整合性が崩れやすい
Opus
| ステップ | 結果 | 詳細 |
|---|---|---|
| 強度メーター追加 | △ | 問題なし。しかしグラデーション・コピー後「済」表示など複数のアドリブが入った |
| 生成履歴の表示 | ◯ | 問題なし |
| LocalStorage保存 | ◯ | 問題なし |
| 個別削除ボタン | ◯ | 問題なし |
| 文字種の最低1文字保証 | ◯ | 問題なし |
👉 傾向：
- アドリブが最も多く、指示以上のUX改善を自発的に行う
- UIの整合性はHaiku・Sonnetより高く、レイアウト崩れは発生しなかった
5.気付き
モデルが高いほどアドリブが増える
今回の検証で意外だったのが、モデルが高いほど指示していない変更が増えるという点です。
Haikuはほぼ指示通りの実装にとどまるのに対し、SonnetやOpusは「グラデーション追加」「コピー済み表示」など自発的な改善を行いました。これは実務では良い方向に働くこともあれば、意図しない変更として混乱を招くこともあるため、一概に良し悪ろしとは言えません。
履歴表示でSonnetがUIを壊した
生成履歴の表示（ステップ2）では、Sonnetがコピーボタン単体を履歴欄に表示してしまう実装になっていました。パスワードではなくボタン要素が履歴に混入し、UIの整合性が崩れた形です。
UIの整合性はモデル差が出やすい
複数ボタンが横並びになるステップ4では、HaikuとSonnetでレイアウト崩れが発生し、Opusだけが問題なく完了しました。機能の正確さより、細かいUIの整合性のほうがモデル差が出やすい印象です。
まとめ
モデルの差は「初回の出力品質」よりも、
「機能を積み上げていく中で、既存の動作を守り続けられるか」
に現れやすいと感じました。
シンプルな1回の指示なら、どのモデルも大きな差はありません。差が出るのは、変更が積み重なったときです。
それを踏まえ今後は、以下の考えで試していこうと思います。
- 単発の機能追加・小さな修正 → Haiku
- 複数機能を順番に積み上げる開発 → Sonnet以上
- UIの整合性まで担保したい・変更が多い → Opus
今回はトークンの制約もあり、小さい機能でしたがより複雑な機能だと結果はまたどうなるかわかりません。
また、提案のリクエスト内容を変えたり、意地悪なプロンプトを投げるとまた変わった違いが出るかもしれません。ぜひお試しいただきたいです。