新しいAIモデルが出るたびに、ベンチマークの数字が飛び交います。
でも、数字だけではわからないことも多いんですよね。
先日、Redditのr/ClaudeAIで興味深い検証が話題になりました。
同じプロンプトをOpus 5とFable 5に与えて、結果を比較するという内容です。
この投稿は500以上のアップボートを集めました。
そして、コメント欄でも活発な議論が展開されています。
本記事では、この投稿と議論の内容を整理して紹介します。
検証の内容
投稿者が行った検証はシンプルです。
自作の2Dシミュレーターを、3D版に変換するよう両モデルに依頼しました。
このシミュレーターでは、車が決められたルートを走ります。
そして、目的地に到達するための燃料を管理するという仕組みです。
プロンプトの趣旨は次のとおりでした。
このプロジェクトを見栄えの良い3D版に変換してほしい。 堅牢で面白くするための変更は自由に加えてよい。 今すぐノンストップで作業を始めてかまわない
両モデルとも思考モードは最大設定です。
また、ワンショット、つまり一発勝負の依頼でした。
細かい指示は一切ありません。
あえて曖昧なプロンプトを投げて、モデルがどう振る舞うかを見る検証と言えます。
結果：見た目のOpus、忠実さのFable
投稿者自身は、Opus 5の結果に感銘を受けたと述べています。
高層ビル、ライティング、車、マップ。
ワンショットとは思えない完成度だったようです。
ところが、コメント欄の評価は違いました。
最も支持を集めたコメントは、Fable 5版のほうが実用的だと指摘しています。
理由は明快です。
車の動きがちゃんと見えるからです。
一方、Opus 5版の見た目は素晴らしいものでした。
しかし、「本来の目的を見失っている」という評価だったのです。
このシミュレーターの本質は、車の移動と燃料管理の可視化にあります。
Opus 5は美しい3D都市を作り上げました。
その代わりに、肝心の車が見えにくくなってしまったのです。
対するFable 5は、マップとして機能するという元のコンセプトを守り抜きました。
「見た目はOpusが上。でも課題を理解したのはFable」
これがコミュニティのおおよその総意でした。
議論から生まれた活用アイデア
面白いのはここからです。
コメント欄では、この結果を踏まえた実践的なワークフローが提案されました。
Fableで設計し、Opusで実装する
Fable 5は課題の意図を正確に汲み取ります。
だから、設計や計画を任せる。
Opus 5は実装力と表現力に優れています。
だから、構築を任せる。
つまり、それぞれの強みを組み合わせる発想です。
複数のコメントがこの役割分担を支持していました。
また、別の視点も示されています。
あるコメントによると、両モデルの違いは次のように整理できます。
- Opus 5は、明確で詳細な指示があれば非常に強力。ただし、指示が曖昧だと手抜きで隙間を埋めてしまう
- Fable 5は、指示が少なくても意図を推測する。そして、適切に隙間を補完してくれる
つまり、こういうことですね。
ざっくりした構想しかない段階では、Fable 5が向いています。
逆に、やるべきことが固まっているなら、Opus 5に任せたほうが速いわけです。
さらに、両者の良いとこ取りを狙う提案もありました。
Opus 5の美しい3D画面に、上空からの平面ビューを小窓で追加すればいいのでは、というアイデアです。
確かに、それなら見た目と実用性を両立できそうです。
この検証への批判的な視点
一方で、検証方法そのものへの指摘も複数ありました。
最も本質的な批判は、サンプル数の問題です。
ワンショットの1回勝負では、判断材料が足りません。
結果がたまたまなのか、それともモデルの傾向なのか。
これを区別できないからです。
同じプロンプトを各モデルで5回ずつ実行してみる。
そうすれば、解の分布に一貫性があるのか、ランダムなのかが見えてきます。
これはもっともな指摘でしょう。
LLMの出力には揺らぎがあります。
だから、1回の比較で「どちらが優秀か」を結論づけるのは早計です。
また、「そもそも曖昧なプロンプトを投げること自体が問題では」という意見もありました。
これに対して、投稿者側は反論しています。
同じ入力に対する両モデルの振る舞いの違いを見る検証だ、と。
さらに、評価基準が明確でない以上、厳密なテストとは呼べないという再反論もありました。
結局、議論は平行線だったようです。
どちらの言い分にも一理あります。
厳密な比較実験ではありません。
それでも、モデルの「性格」を感じ取る材料としては十分に面白い。
私はそう受け止めました。
コストと運用面の議論
コメント欄では、コスト面の懸念も語られていました。
Opus 5は「Fable並みの性能を半額で」と紹介されています。
ただし、それはAPI単価の話です。
実際のトークン消費量が多ければ、トータルコストは高くつく可能性があります。
過去のモデルでも、似たケースがあったようです。
単価は安いのに大量のトークンを消費する。
その結果、かえって高額になったという話でした。
また、Claude Codeでのモデル運用に関する実践的な報告もありました。
サブエージェントに特定のモデルと思考レベルを指定したとします。
ところが、意図と異なるモデルが起動されることがあるという内容です。
この報告者は、対策としてフックの設定を紹介していました。
指定外のモデルや思考レベルをブロックする仕組みです。
コストを抑えたいなら、モデルの指定が実際に守られているか確認する仕組みが必要になりそうです。
まとめ
Redditで話題になった、Opus 5とFable 5の比較検証を紹介しました。
要点を振り返ります。
曖昧なプロンプトに対して、Opus 5は創造性を発揮しました。
そして、見栄えの良い成果物を作り上げています。
一方、Fable 5は元の目的に忠実な成果物を返しました。
どちらが優れているかではなく、性格が違うという話です。
ここから得られる実践的な教訓は2つあります。
1つ目は役割分担です。
構想段階や設計はFable 5に任せる。
明確な仕様に基づく実装はOpus 5に任せる。
この組み合わせが、コミュニティで支持されていました。
2つ目はプロンプトとの相性です。
指示を細かく書けるなら、Opus 5が力を発揮します。
逆に、ふわっとした依頼から意図を汲んでほしいなら、Fable 5です。
ただし、忘れないでください。
これはワンショット1回の比較にすぎません。
再現性は検証されていないのです。
だから、あくまで参考情報として捉えるべきでしょう。
とはいえ、ベンチマークの数字を眺めるより、こうした具体例のほうがモデルの個性は伝わってきます。
あなたも自分のプロジェクトで、同じプロンプトを複数モデルに投げてみてはいかがでしょうか。
意外な発見があるかもしれませんよ。
