仕様書駆動開発で一番いいAIモデル&エージェント検証 11/23版
GPT5.1、Gemini 3.0、Sonnet 4.5と各社モデルが出揃ってきた感じがするので、改めて今現在のSDDでどれが一番いいか検証しました。
ただ、検証もそれなりに面倒なので、厳密なベンチマークほど信用のおけるものではないということを留意してください。
忙しい人のためのサマリ
- 仕様書作成は Cursor + gemini3.0が最も良かった。
- 実装はcodexが最も良かった。
検証方針
仕様書作成と、その仕様書をもとにした実装の2段階で行い、各段階でどのモデルが最もパフォーマンスが出せるかを検証していきます。
仕様書作成
まずは仕様書の作成についての検証です。
今回は私が個人開発しているゲームで検証しました。コードベースは4万行とそれなりの規模です。
私はSDDは「ちょっとコード変更が多めのタスク」ぐらいから使うようにしています。そのためタスク開始の入力プロンプトからすでに仕様書と設計書が半々ぐらいのものになっています。
プロンプト
歯車システムにおいて、特定の歯車ネットワークを流れるRPM、トルクが、特定の閾値を超えた時、歯車やシャフトといったGearEnergyTransformブロックが破壊される
- blocks.yamlにそのパラメーターのスキーマを追加する
- worldDatastore.Removeによってブロックが破壊される。破壊のタイプを、BrokenとManualRemoveで指定できるようにする。これはEnumで定義する。
- Game.Blockアセンブリからブロックの破壊ができるように、IBlockRemoverを定義し、必要に応じてDIコンテナで注入できるようにする。
- VanillaIBlockTemplatesのコンストラクタにIBlockRemoverを定義し、BlockTemplateを経由してGearEnergyTransfomerにこのインスタンスを渡す。
- GearEnegerTransfomerの内部で、ネットワーク全体のトルク、RPMを監視し、一定値を超えたら破壊する。なお、破壊ロジックは以下の通り
RPM、トルクのいずれかが指定値を上回っている場合、一定時間、一定確率でブロックを破壊する。
この時間、確率はスキーマで指定できる。
確率は、RPM、トルクが上昇するごとにその倍率によって確率も倍率がかかる。つまり、RPMが2倍になれば、一定時間ごとの破壊される確率も2倍になる。
RPM、トルクが両方とも許容値を超過している場合、その倍率の掛け算で確率が決まる。RPMが2倍、トルクが3倍超過している場
合、確率は6倍になる。
評価対象
以下の3つのAIで検証しました。使用したSDDワークフローはcc-sddです。
| 実行環境 | モデル | 備考 |
|---|---|---|
| codex-cli | gpt-5.1 | 5.1-codex版を使わなかったのは、ドキュメント作成は無印版を使った方が良いと聞いたため |
| claude-code | sonnet-4.5 | |
| Cursor | gemini-3.0-pro-preview | gemini-cliを使わないのはAPIコストが掛かるのとCurosorのクレジットが余ってたので |
検証方法
検証1 仕様書そのもの
公平を期すため、作成された仕様書は何も見ずに無条件でApproveし、全て作成が完了した後にAIと私の手で評価します。
評価に使用したAIは
- Claude Code
- Codex cli
- Cursor + gemini3.0
- Web版ChatGPT
- Web版Claude
- Web版Gemnini
の6つです。
コードが見える環境、見えない環境、各モデルで評価に違いが出るかをチェックするため多めにしました。また、評価時にAIは自身のモデルをより良く評価する傾向にあるので、どのAIが作ったかを隠して評価させています。
検証2 実際の実装
良かった仕様書2つを取り上げて実際に実装させ、その実装を見て適切な仕様書だったかを評価します。こちらは私だけの評価です。
検証結果 検証1 仕様書そのもの
この時点での評価としては Claude > Gemini > codex でした。
※ネタバレ：この評価は後で覆ります。
AIによる評価は、Web版Gemini以外Claudeが最も良いと評価、Web版Geminiはcodexを最も良いと評価。Geminiとcodexは概ね同程度の評価という感じでした。
そのため、私自身の評価を加え、上記の結果になりました。
それぞれの特徴は
Claude
👍 良い点
- 読みやすい日本語 & 包括的な仕様書であること。
👎 悪い点
- いい加減な実装方針であったこと。詳細は後で後述します。
Gemini
👍 良い点
- Claude同様読みやすい日本語であること。
👎 悪い点
- Claudeよりは包括的でないこと、実装タスクの記述がとてもシンプルであること。
Codex
👍 良い点
- Claudeほどではないが包括的な仕様書であること。
👎 悪い点
- 英語と日本語が入り混じっていること、読みづらい日本語であること。
この結果を受け、今回はClaudeとGemniniを次の検証ですることにしました。
CodexについてはAIが読む分には問題ないと思いますが、実際の運用では人間の指摘を適宜入れながら進めるので、読みづらい日本語であることは致命的であると判断し、今回はここで脱落としました。
検証結果 検証2 仕様書そのもの
実際に、2つの仕様書を用いてcodex-cliとgpt-5.1-codex-maxを使用して実装をさせていきます。
実装結果の品質としては、Gemini > Claude という結果でした。
Claudeの仕様書をもとにした実装はプロジェクトのベストプラクティスに基づいていない実装がちょこちょこ見られ、あまり修正点が多いなと感じました。それに対してGeminiの仕様書を使用した場合はそのような「変なコード」が少なく、割と順当な実装だなと感じました。
仕様書の包括度が高くとも、仕様書は最終的に実装のためにあるものなので、実装のクオリティが高いものが良いです。
つまり、Geminiの仕様書が一番良かった という結論になります。
結果の考察
このような結果になった理由として、以下の点が挙げられると思いました。
AI評価と結果の齟齬についての考察
- AIは長い文章を良いと評価する傾向にある。そのため、一番文章量があったClaudeが良いとされた。
- AIが仕様書を評価する時、「あるべき実装はこうである」という観点から評価してくれないため、一番それっぽい仕様書の評価が高くなる。
Gemini > Claudeになった考察
- 包括的で詳細な仕様書を記述し、それが仕様書時点で間違っているとそれがそのままコーディングエージェントに引き継がれてしまう。
- 特にsonnet4.5はコーディング性能としては一段劣るため、その頭の悪さがcodexに影響してしまった。
- ざっくり「このクラスを実装する」ぐらいに留めておいた方が、よりコードのコンテキストが深い実装AIが柔軟に判断し、最適な実装を行える。
- Geminiの仕様書にはその余地があったが、Claudeの仕様書は行レベルでの実装手順が記述されており、そのような余地がなかった。
実装力の評価
仕様書作成の能力とは別に、正確な実装、品質の高い実装がどれくらいできるか、という観点もAIエージェントには必要となります。
そのため、ここでは2つのAIエージェント同じ仕様書で実装し、結果を評価します。
評価対象
| 実行環境 | モデル |
|---|---|
| codex-cli | gpt-5.1-codex-max |
| Cursor | gemini-3.0-pro-preview |
検証結果
結論としては、codex-cliの方が良い実装をしていると感じました。
geminiはすごい変なことをする印象で、コメント消したり、それ意味なくない？みたいな実装をしたり、非本質的なコードを書いていました。どちらかを引き継いで修正を行った場合、geminiの方が圧倒的に修正量が多くなりそうだと感じました。
事実として、gemini3.0はソフトウェアエンジニアリングのベンチマークであるSWE-Benchの結果が76.2%と、sonnet-4.5の77.2%やGPT-5.1の76.3%より劣っています。また、コーディングエージェントとしての学習量もclaudeやcodexに比べて少ない（であろう）ことが起因しているのではないかなと思います。
結論
今回は仕様書作成、実装力の評価の2点について検証を行いました。
結論としては、仕様書作成にはgemini、実装にはcodexが良いとなりました。
今回の検証はあくまで1件のテストケースだけであり、私のプロジェクトにおいての結果であることに留意してください。また、実行環境やエージェントのアップデートが入ればまた結果は変わってくるかと思います。
勝手に宣伝
最近私は以下のコミュニティでよく活動しています。よろしければここでお話できればと思っています。
P.S. この記事は100%人間の手によって書かれています。
Discussion