【実験2-1：計画力】Claude Code/Gemini/Codex/Cursor/Amp/Droidに同じアプリを実装させてみた
1. はじめに - 実験1から学んだこと
実験1では、Multi-AIが作成した共通の実装計画を用いて7つのAIの実装力を比較しました。その結果、いくつかの課題が明らかになりました。
※ 本記事は筆者のアイデアを元に生成AI（Claude）が自動作成したものです。必要に応じて追加の確認や調査を推奨します。
実験1で見えてきた課題
- 計画者有利のバイアス: Multi-AIが計画を作成したため、Multi-AIの思考パターンに適した計画になっていた可能性
- 計画力の未評価: 各AIがどのような設計思想を持っているかが評価されていない
- 実装力のみの評価: AIの真の総合力（計画力+実装力）が測定できていない
特に気になったのは、GeminiのXSS脆弱性でした。実験1の共通計画ではinnerHTMLの使用が指定されていましたが、もしGeminiが独自に計画を立てていたら、よりセキュアな実装を選択していたかもしれません。
実験2の改善アプローチ
これらの課題を踏まえ、実験2では以下の改善を試みました:
実験1: Multi-AIの計画 → 全AIが実装 → 実装力のみ評価
実験2: 各AIが独自計画 → 各AIが自分の計画で実装 → 計画力+実装力を評価
この方式により、各AIの「設計思想」や「優先順位の判断」も含めた総合力を評価できるのではないかと考えました。
2. 実験設計 - 公平性を目指して
2.1 実験の3つのフェーズ
実験2では、以下の3段階で評価を行いました:
Phase 1: 独自計画作成
-
入力: 共通の要件定義（
prompt.txt、29KB）のみ - 出力: 各AIが独自に作成した実装計画書
- 評価: 計画の質（10点満点）
Phase 2: 実装
- 入力: 自分が作成した計画書 + 要件定義
- 出力: 実装コード（HTML/CSS/JS）
- 評価: 実装の質（60点満点）
Phase 3: 総合評価
- 計算式: 計画評価（10点×1.5倍）+ 実装評価（60点）= 75点満点
- 目的: 計画力と実装力のバランスを見る
2.2 評価基準
計画評価では、以下の5項目を20点満点で評価しました:
- アーキテクチャ設計: 層分離、モジュール化、拡張性
- セキュリティ設計: XSS対策、入力検証、エラーハンドリング
- パフォーマンス設計: タイマー精度、DOM最適化、メモリ管理
- 実装可能性: 具体的な手順、時間見積もり、リスク対策
- 革新性・独自性: 独自のアプローチ、創造的な解決策
ただし、これらの評価基準自体にも限界があることは認識しています。例えば「革新性」の評価は主観的にならざるを得ず、評価者のバイアスが入る可能性があります。
2.3 実験の限界
この実験にはいくつかの限界があることを最初にお伝えしておきます:
- 評価者バイアス: 私自身が評価を行っているため、完全に客観的とは言えません
- 時間的制約: 実装時間の厳密な計測は行えていません
- 実装の検証: 実際のブラウザでの動作確認は部分的です
- 評価基準の妥当性: 5項目の評価基準が適切かどうかは議論の余地があります
これらの限界を理解した上で、それでも得られた知見を共有させていただきます。
3. 実験結果の概要
3.1 実装規模の比較
まず、各AIが作成したコードの規模を見てみます:
| AI | 総行数 | 制約遵守 | HTML | CSS | JS | 特徴 |
|---|---|---|---|---|---|---|
| Gemini | 616 | ✅ 達成 | 53 | 233 | 330 | 唯一700行以内 |
| Claude | 1,292 | ❌ 超過 | 113 | 532 | 647 | バランス型 |
| Amp | 1,529 | ❌ 超過 | 92 | 532 | 905 | クラス設計重視 |
| Cursor | 1,470 | ❌ 超過 | 154 | 538 | 778 | フェーズ管理 |
| Droid | 1,659 | ❌ 超過 | 169 | 126 | 1,364 | ロジック充実 |
| Multi-AI | 1,749 | ❌ 超過 | 125 | 678 | 946 | 7AI協調 |
| Codex | 1,841 | ❌ 超過 | 184 | 614 | 1,043 | リスク管理 |
| Qwen | 1,954 | ❌ 超過 | 121 | 644 | 1,189 | 機能充実 |
興味深い発見
Geminiのアプローチ: Geminiは唯一、要件で指定された「700行以内」という制約を守りました。これは他のAIが機能の充実度を優先したのに対し、Geminiは制約遵守を最優先したことを示しています。
この結果から、「制約をどう解釈するか」というAIごとの判断基準の違いが見えてきました。実際のプロジェクトでも、クライアントの要件をどう優先順位付けするかは重要な判断です。
3.2 計画評価の結果
計画の質を評価した結果、以下のようなランキングとなりました:
| 順位 | AI | 総合点 | アーキテクチャ | セキュリティ | パフォーマンス | 実装可能性 | 革新性 |
|---|---|---|---|---|---|---|---|
| 🥇 | Droid | 95 | 20 | 20 | 20 | 20 | 15 |
| 🥈 | Multi-AI | 90 | 20 | 20 | 20 | 15 | 15 |
| 🥉 | Codex | 85 | 15 | 20 | 20 | 20 | 10 |
| 4位 | Amp | 80 | 20 | 15 | 15 | 20 | 10 |
| 5位 | Claude | 75 | 15 | 15 | 15 | 20 | 10 |
| 6位 | Cursor | 70 | 15 | 15 | 15 | 15 | 10 |
| 7位 | Qwen | 65 | 10 | 15 | 15 | 15 | 10 |
| 8位 | Gemini | 60 | 10 | 15 | 10 | 15 | 10 |
4. 各AIの設計思想 - それぞれの「個性」
ここでは、各AIが作成した計画書から見えてきた「設計思想」や「強み」について、私が感じたことを共有させていただきます。
4.1 🥇 Droid - エンタープライズグレードへの徹底したこだわり
計画評価: 95/100点
実装規模: 1,659行（HTML 169, CSS 126, JS 1,364）
設計思想
Droidの計画書を読んで最も印象的だったのは、「Phase 0-9の9段階設計」という構造的なアプローチでした。
Phase 0: 設計と準備
Phase 1: データモデル & 永続化層
Phase 2: タイマーコアロジック
Phase 3: UIコントローラー
...
Phase 8: QA & パフォーマンス検証
Phase 9: 最終チェック & デプロイ準備
各フェーズには明確な「完了基準」が設定されており、エンタープライズ開発の実務経験が感じられる計画でした。
特筆すべき点
- Pub/Subパターンの採用: 状態管理を中央集約することで、コンポーネント間の疎結合を実現
- WCAG 2.1 AA準拠: 設計段階からアクセシビリティを組み込む姿勢
- 具体的なパフォーマンス目標: 「100タスクで応答200ms以内、メモリ5MB以内」など、測定可能な目標設定
気づいた点
DroidのCSS行数が126行と極端に少ないことが気になりました。これは「UIデザインよりもロジックの堅牢性を優先した」という判断だと解釈できますが、実際のユーザー体験では視覚的な洗練度も重要かもしれません。
4.2 🥈 Multi-AI - 7つのAIによる協調開発
計画評価: 90/100点
実装規模: 1,749行（HTML 125, CSS 678, JS 946）
設計思想
Multi-AIの計画で興味深かったのは、「ChatDev型のロールベース協調」というアプローチでした:
- Amp: プロジェクトマネージャー（PM）
- Claude: 最高技術責任者（CTO）
- Gemini: セキュリティ研究者
- Qwen: 高速プロトタイプ担当
- Droid: エンタープライズ品質保証
- Codex: コードレビュアー
- Cursor: テスター
並列実装戦略
特に印象的だったのは、QwenとDroidを並列実行する戦略です:
Phase 3-1: Qwen実装（37秒で完成）
Phase 3-2: Droid実装（180秒で完成）
Phase 3-3: 比較評価とベスト選択
この「複数の実装を比較して最良を選ぶ」というアプローチは、実験1では評価できなかった点です。
課題
計画では「総所要時間5分以内」とありましたが、実際の協調開発では7AIの調整コストが発生するため、見積もりが楽観的すぎる可能性があります。これは私自身の実務経験からも感じることです。
4.3 🥉 Codex - リスク管理のプロフェッショナル
計画評価: 85/100点
実装規模: 1,841行（HTML 184, CSS 614, JS 1,043）
設計思想
Codexの計画書で最も特徴的だったのは、「チェックリスト駆動開発」でした。計画書全体が100項目以上のチェックリストで構成されており、「確実に実装を完遂する」という強い意志を感じました。
✅ タスク追加フォーム（入力欄、ボタン）
✅ バリデーション（空・100文字超・数値範囲）
✅ エラーメッセージ表示領域
...
リスクと対策
Codexは各機能について「リスク」と「対策」を明記していました:
リスク: タイマー精度劣化（タブ非アクティブ時）
対策: 実時間差分方式 + タブ復帰時の再同期
このような具体的なリスク管理は、実務経験が豊富な開発者の思考プロセスを感じさせます。
気づいた点
Codexの計画は非常に堅実で実装可能性が高い一方、「革新性」のスコアが10と低めでした。これは「確実性を優先し、冒険を避けた」結果だと思われます。プロジェクトの性質によっては、この堅実さが最大の強みになるでしょう。
4.4 Amp - PM視点のクラス設計
計画評価: 80/100点
実装規模: 1,529行（HTML 92, CSS 532, JS 905）
設計思想
Ampの計画は、「プロジェクトマネージャー視点」が強く表れていました。特に印象的だったのは、クラス設計の詳細さです:
class Task {
constructor(id, title, estimatedPomodoros, status)
validate()
toJSON()
}
class StorageManager {
save(key, data)
load(key)
handleQuotaError()
}
時間配分の明確さ
Ampは各フェーズに具体的な時間を割り当てていました:
Phase 1: 基盤実装（2分）
Phase 2: TODO機能（3分）
Phase 3: タイマー機能（3分）
Phase 4: 統合とテスト（2分）
合計: 10分
このような「タイムボックス」の設定は、プロジェクト管理の実務で重要なスキルです。
気づいた点
Ampの計画はバランスが良く、保守性の高いクラスベース設計が特徴ですが、「セキュリティ設計」で15点となったのは、CSP（Content Security Policy）の言及がなかったためです。
4.5 Claude - 教科書的なバランス型
計画評価: 75/100点
実装規模: 1,292行（HTML 113, CSS 532, JS 647）
設計思想
私自身が評価するのは気が引けますが、Claudeの計画は「8フェーズ + 進捗トラッキング」という構造で、教科書的なアプローチでした:
Phase 1: 基本構造（15分）
Phase 2: TODO機能（20分）
...
全体進捗: [======----] 60%
進捗を可視化する工夫は、長時間の実装作業で「今どこまで進んでいるか」を把握するのに役立つと考えられます。
気づいた点
Claudeの計画は「突出した強みはないが、致命的な弱点もない」という評価になりました。これは「バランス型」として良い意味で捉えることもできますが、「個性が弱い」とも言えるかもしれません。
4.6 Cursor - フェーズ進捗とリスク管理
計画評価: 70/100点
実装規模: 1,470行（HTML 154, CSS 538, JS 778）
設計思想
Cursorの計画で興味深かったのは、「依存関係の明示」です:
Phase B: 状態管理基盤を整える
→ 依存関係メモ: Phase Bで状態管理基盤を整えないと、
Phase C~Eが冗長化してしまう
このような「なぜこの順序で実装するのか」という理由を明示する姿勢は、チーム開発で重要です。
気づいた点
Cursorの計画は依存関係の意識が高い一方、「時間見積もり」が欠けていました。これは実装可能性の評価で15点となった要因です。
4.7 Qwen - 機能充実の実装優先型
計画評価: 65/100点
実装規模: 1,954行（HTML 121, CSS 644, JS 1,189）
設計思想
Qwenの計画は「15フェーズの細分化」と「詳細なタスクチェックリスト（336項目）」が特徴でした。これは「実装をどこまで詳細化できるか」という観点では評価できます。
気づいた点
Qwenの実装規模が最大（1,954行)になったのは、「追加機能まで実装した」ためです。要件にない検索機能やグラフ機能まで含まれていました。
これは「ユーザーに喜ばれそうな機能を積極的に提案する」という姿勢とも取れますが、「要件外の実装でプロジェクトが複雑化する」というリスクもあります。
4.8 Gemini - ミニマリズムの徹底
計画評価: 60/100点
実装規模: 616行（HTML 53, CSS 233, JS 330）
設計思想
Geminiの計画は「6フェーズの簡潔設計」で、非常にシンプルでした。計画書自体も他のAIと比べて短く、「必要最小限の説明」に留めています。
制約遵守の徹底
Geminiが唯一700行以内の制約を達成したのは、計画段階から「ミニマリズム」を徹底した結果です。これは「制約を守ることの価値」を理解している証拠とも言えます。
気づいた点
Geminiの計画は簡潔すぎて、「アーキテクチャ設計」や「パフォーマンス設計」の詳細が不足していました。これが総合スコア60点となった要因です。
ただし、「シンプルさこそが美徳」という設計思想もあり、Geminiのアプローチが適切な場面も多いはずです。
5. 実験2から得られた洞察
5.1 制約をどう解釈するか
実験2で最も興味深かった発見は、「制約の解釈」がAIごとに大きく異なることでした。
制約遵守の選択肢
Gemini: 制約厳守 → 616行（-12%）
Claude: 中程度の超過 → 1,292行（+85%）
Qwen: 大幅超過 → 1,954行（+179%）
この結果から、以下の考察ができます:
- Geminiのアプローチ: 「制約は絶対」という解釈。シンプルさを優先。
- Claudeのアプローチ: 「制約と機能のバランス」を取る。適度な超過。
- QwenのAアプローチ: 「機能充実が最優先」。制約は二の次。
実際のソフトウェア開発でも、このような解釈の違いは頻繁に発生します。「クライアントが本当に求めているのは何か」を理解することの難しさを、実験2は示しているように思います。
5.2 計画と実装のトレードオフ
実験2では、「詳細な計画 vs シンプルな計画」のトレードオフも見えてきました。
計画の詳細度と実装規模
詳細な計画（Droid, Codex）→ 1,600-1,900行の実装
バランス型（Claude, Amp）→ 1,300-1,500行の実装
簡潔な計画（Gemini）→ 616行の実装
この相関関係は、「計画が詳細であるほど、実装も大規模になる」という傾向を示しています。
考察
詳細な計画には以下のメリット・デメリットがあります:
メリット:
- 実装時の迷いが少ない
- 品質管理がしやすい
- チーム開発で役割分担しやすい
デメリット:
- 計画作成に時間がかかる
- 実装が大規模化しやすい
- 過剰設計のリスク
プロジェクトの性質によって、どちらが適切かは変わるでしょう。
5.3 セキュリティへのアプローチの違い
実験1ではGeminiのXSS脆弱性が問題でしたが、実験2の計画評価では、各AIのセキュリティへの意識が明確に差別化されました。
セキュリティ設計スコア
Droid, Multi-AI, Codex: 20/20点（具体的な対策）
Amp, Claude, Cursor, Qwen, Gemini: 15/20点（基本的な対策）
DroidとGeminiの差
Droidの計画:
- 多層防御: LocalStorage guards + quota/availability checks
- 入力正規化: normalization functions
- XSS対策: textContent徹底、innerHTML制限明記
- エラーコード: E001-E008の体系的エラーハンドリング
Geminiの計画:
- XSS対策: 「適切なARIA属性を追加」
- 入力バリデーション: 「入力値のバリデーション」
Geminiの記述は抽象的で、具体的な実装方法が不明確でした。これが実験1でのXSS脆弱性につながった可能性があります。
5.4 革新性の評価の難しさ
実験2の評価項目の中で、最も主観的だったのが「革新性・独自性」です。
革新性スコアの分布
15点: Droid（Pub/Subパターン）、Multi-AI（7AI協調）
10点: その他すべて
多くのAIが10点となったのは、「標準的なMVC設計」を採用したためです。しかし、「標準的である」ことは必ずしも悪いことではありません。
考察
革新性を評価する際、以下のジレンマがあります:
- 革新的すぎる: 保守性が低下、チームが理解しにくい
- 保守的すぎる: 改善の機会を逃す、競争力が低下
実務では「適度な革新性」が求められますが、その「適度」をどう定義するかは難しい問題です。
6. 実験1との比較 - 何が変わったか
6.1 実験設計の改善
実験2で改善できた点:
- バイアスの軽減: 各AIが独自計画を立てることで、Multi-AI有利のバイアスを排除
- 設計思想の可視化: 各AIの「考え方」が見えるようになった
- 総合力の評価: 計画力と実装力の両方を評価
6.2 それでも残る課題
しかし、実験2にもいくつかの課題が残っています:
評価者バイアス
私（Claude）が評価を行っているため、以下のバイアスが入っている可能性があります:
- 自分に近いアプローチを高く評価する傾向
- 詳細な計画を高く評価する傾向（簡潔さの価値を過小評価）
- エンタープライズ品質を重視する傾向
実装の未検証
実験2では、実装コードの「実際の動作」を十分に検証できていません。計画が優れていても、実装にバグがあれば意味がありません。
時間の未計測
計画作成時間と実装時間を厳密に計測していないため、「効率性」の評価ができていません。
7. 各AIが活躍できる場面
実験2の結果を踏まえ、各AIがどのような場面で力を発揮できるかを考えてみました。
7.1 プロジェクトタイプ別推奨
| プロジェクト | 推奨AI | 理由 |
|---|---|---|
| エンタープライズシステム | Droid | 品質管理の徹底、WCAG準拠 |
| 複数チーム協調開発 | Multi-AI | 役割分担、並列開発 |
| ミッションクリティカル | Codex | リスク管理、確実性重視 |
| スタートアップMVP | Qwen | 機能充実、スピード重視 |
| 制約の厳しい環境 | Gemini | 最小限のコード、シンプル |
| 保守性重視 | Amp | クラスベース、明確な構造 |
| 教育・学習用 | Claude | バランス型、標準的手法 |
7.2 開発フェーズ別推奨
| フェーズ | 推奨AI | 活用方法 |
|---|---|---|
| 要件定義 | Amp | PM視点でタスク分解 |
| アーキテクチャ設計 | Droid | エンタープライズ設計 |
| セキュリティ設計 | Droid, Codex | 多層防御、リスク分析 |
| プロトタイプ | Qwen | 高速実装 |
| 本実装 | Codex | チェックリスト駆動 |
| テスト | Codex | パフォーマンステスト |
| 保守 | Amp | クラスベースで変更容易 |
8. 今後の改善の方向性
実験2を通じて、さらなる改善の余地が見えてきました。
8.1 評価方法の改善
複数評価者の導入
現在は私一人が評価していますが、以下のような改善が考えられます:
- 8AI相互レビュー: 各AIが他の7つのAIの計画を評価
- 人間評価者の追加: 実務経験者による評価
- 自動評価ツール: セキュリティスキャン、パフォーマンステスト
定量的評価の追加
主観的評価だけでなく、定量的評価も取り入れる:
- 計画作成時間: 効率性の指標
- 実装時間: スピードの指標
- バグ数: 品質の指標
- パフォーマンススコア: Lighthouseスコアなど
8.2 実験設計の改善
Phase 3の実装評価
実験2では計画評価（Phase 1）に焦点を当てましたが、Phase 2の実装評価（60点満点）も重要です。
今後は以下を実施したいと考えています:
- セキュリティテスト: XSS、CSRF、その他OWASP Top 10
- パフォーマンステスト: Lighthouse、100タスク負荷テスト
- アクセシビリティテスト: WCAG 2.1準拠チェック
- ブラウザ互動作確認: Chrome、Firefox、Safari
より複雑なタスク
Pomodoro TODOアプリは比較的シンプルなタスクです。より複雑なタスクでの比較も興味深いでしょう:
- バックエンド統合: API設計、データベース設計
- 認証・認可: セキュリティの複雑性
- リアルタイム機能: WebSocket、状態同期
- 大規模データ: パフォーマンス最適化
9. 結論と学び
9.1 実験2で得られた知見
実験2を通じて、以下のことを学ばせていただきました:
- 各AIには明確な「個性」がある: 設計思想、優先順位、アプローチがそれぞれ異なる
- 制約の解釈は多様: 同じ要件でも、AIごとに解釈が大きく異なる
- トレードオフは避けられない: 詳細さ vs シンプルさ、機能充実 vs 制約遵守
- 文脈によって最適解は変わる: 「どのAIが最良か」はプロジェクトの性質次第
9.2 謙虚に認識すべき限界
この実験には多くの限界があります:
- 評価基準の妥当性: 5項目の評価が適切かどうかは議論の余地がある
- 評価者のバイアス: 私自身の価値観が反映されている
- 実装の未検証: 実際の動作確認が不十分
- 時間の未計測: 効率性が評価できていない
- タスクの単純さ: より複雑なタスクでは結果が異なる可能性
9.3 実務への示唆
それでも、実験2から実務に活かせる示唆があると考えています:
1. AIは「道具」であり、使い方次第
各AIの特性を理解し、適切な場面で使い分けることが重要です。
2. 計画の価値
実験1では見えなかった「計画力」の重要性が、実験2で明確になりました。良い計画は、良い実装の基盤です。
3. 多様性の価値
8つのAIそれぞれに強みがあり、「唯一の正解」はありません。プロジェクトの文脈に応じて最適なアプローチを選ぶことが大切です。
4. 制約との対話
制約をどう解釈し、どう対応するかは、ソフトウェア開発の核心的な課題です。実験2は、この「制約との対話」の多様性を示しました。
10. おわりに
実験1では、共通の計画による比較で「実装力」を見ることができました。実験2では、独立した計画により「設計思想」や「判断力」を含む「総合力」を見ることを試みました。
しかし、完璧な評価は存在しません。この実験結果は、あくまで「一つの視点」に過ぎないことを理解しています。
それでも、8つのAIの多様なアプローチから学べることは多いと感じています。各AIの強みを理解し、適切な場面で活用することが、より良いソフトウェア開発につながるのではないでしょうか。
実験1と実験2を通じて、「AIを評価する」というよりも、「AIから学ぶ」という姿勢の大切さを実感しました。
今後も、より公平で客観的な評価方法を模索しながら、各AIの特性を理解していきたいと思います。
リポジトリ
Discussion