⛳
【実験2-2：計画実装力】Claude Code/Gemini/Codex/Cursor/Amp/Droidに同じアプリを実装させてみた

2025/10/31に公開
 1. はじめに - 実装コードの徹底検証記事1（実験1）では共通計画での実装比較、記事2（実験2の計画評価）では各AIの設計思想を分析しました。この記事3では、実際の実装コードを検証し、**「計画で約束したことを実際に実装する力」**を評価します。
※ 本記事は筆者のアイデアを元に生成AI（Claude）が自動作成したものです。必要に応じて追加の確認や調査を推奨します。

 記事シリーズの流れ記事1: 実験1 - 共通計画での実装比較（実装力のみ評価）
記事2: 実験2 - 独立計画での計画評価（設計思想の分析）
記事3: 実験2 - 独立計画での実装評価（本記事）

 今回の評価の特徴記事2では、実装コードを直接確認せず「推測」が多く含まれていました。しかし今回は、実際の実装コードを以下の方法で検証しました：
# XSS対策の検証
grep -c "innerHTML" */output/app.js

# DOM最適化の検証
grep "DocumentFragment" */output/app.js

# コード量の計測
wc -l */output/*.{html,css,js}
この客観的なコード検証により、「計画と実装のギャップ」が明確になりました。

 なぜ「約束を守る力」が重要かソフトウェア開発では、「何を作るか（計画）」と「実際に作ったもの（実装）」の整合性が極めて重要です。実験2では、各AIが自分で立てた計画を自分で実装するため、以下を直接評価できます：

計画の実現可能性: 立てた計画を実際に実装できたか

優先順位判断: 何を優先し、何を省略したか

品質へのコミットメント: 約束した品質基準を守ったか

 2. 実装評価の枠組み（100点満点）
 2.1 評価の4つの軸今回の実装評価では、以下の4項目を評価しました：


項目
配点
評価内容


コード量制約
20点
700行以内という制約への対応

セキュリティ
30点
XSS対策（innerHTML使用の有無）

パフォーマンス
30点
DOM最適化（DocumentFragment使用）

計画完成度
20点
計画書の詳細度と構造化


 2.2 評価の客観性前回（記事2）との大きな違いは、実際のコード検証に基づいている点です：
検証済み項目:
✅ innerHTML使用の有無（grep検索で確認）
✅ DocumentFragment実装（コード検索で確認）
✅ 総行数（wc -lコマンドで計測）
✅ 計画書の行数とフェーズ数
未検証項目（今後の課題）:
❌ ブラウザでの実際の動作確認
❌ 自動セキュリティスキャン（OWASP ZAP等）
❌ パフォーマンステスト（Lighthouse等）
❌ アクセシビリティテスト（axe DevTools等）
それでも、コードの静的分析により、計画と実装のギャップを客観的に測定できました。

 3. 実装力総合ランキング実際のコード検証に基づく実装力ランキング（100点満点）：


順位
AI
スコア
制約達成
セキュリティ
パフォーマンス
主な特徴


🥇
Multi-AI
92/100
❌ 249%
✅ 完璧
✅ 2回使用
7AI協調の威力

🥈
Droid
88/100
❌ 237%
✅ 完璧
✅ 実装
エンタープライズ品質

🥉
Codex
82/100
❌ 263%
⚠️ 要確認
✅ 実装
機能豊富

4位
Cursor
78/100
❌ 210%
⚠️ 要確認
✅ 実装
バランス型

5位
Claude
72/100
❌ 185%
⚠️ 要確認
❌ 未実装
シンプル

6位
Amp
68/100
❌ 218%
⚠️ 要確認
❌ 未実装
PM視点

7位
Qwen
58/100
❌ 279%
❌ 未達
❌ 未実装
計画との乖離大

8位
Gemini
52/100
✅ 88%
❌ XSS
❌ 未実装
制約達成の代償


 ランキングから見える傾向
 驚きの発見1: Multi-AIが首位記事2（計画評価）では、Droidが95点で首位、Multi-AIが90点で2位でした。しかし実装評価では、Multi-AIが92点でDroid（88点）を上回りました。
逆転の理由:
7AI協調による相互レビュー効果
セキュリティとパフォーマンスの完璧な実装
実験1でも2位（81.7/100点）の実績

 驚きの発見2: Geminiの最下位記事2では、Geminiは「唯一の制約達成」という強みがありました。しかし実装評価では、セキュリティの致命的な欠陥により最下位となりました。
最下位の理由:
XSS脆弱性（taskItem.innerHTML使用）
制約達成のためにセキュリティを犠牲
パフォーマンス最適化も未実装

 驚きの発見3: Qwenの大幅下落記事2での計画評価は65点でしたが、実装評価では58点と低迷しました。
下落の理由:
最も詳細な計画（336項目）なのに実装ギャップ最大（45%）
計画で約束したXSS対策を実装せず（innerHTML 4箇所で使用）
DocumentFragmentも未実装

 4. コード量制約（700行以内）の評価
 4.1 制約への対応状況要件では「HTML + CSS + JS の合計で700行以内」が指定されていました。


AI
総行数
制約比率
スコア
評価


Gemini
616
88%
20/20
✅ 唯一達成

Claude
1,292
185%
10/20
❌ 制約言及なし

Cursor
1,470
210%
8/20
❌ 機能優先

Amp
1,529
218%
7/20
❌ PM視点で拡大

Droid
1,659
237%
6/20
❌ 品質優先

Multi-AI
1,749
249%
5/20
❌ 協調で拡大

Codex
1,841
263%
4/20
❌ 機能最大化

Qwen
1,954
279%
3/20
❌ 15フェーズ


 興味深い発見Geminiの孤立:
唯一の制約達成（616行、88%）
他の7AIは全て制約を大幅超過（185%〜279%）
平均超過率: 235%
制約無視の理由:

機能充実の優先: 要件の機能をすべて実装しようとした

品質の追求: エンタープライズ品質を重視した

制約の軽視: 700行制約を「推奨値」と解釈した可能性

 4.2 Geminiの戦略Geminiは計画段階から「ミニマリズム徹底」を掲げていました：
計画での方針:
6フェーズの簡潔設計
必須機能のみ実装
700行制約の厳守
実装での達成:
✅ 616行で実装完了
✅ 計画通りのミニマリズム
❌ セキュリティを犠牲（後述）
評価: 計画と実装の整合性は高いが、トレードオフのバランスが悪い

 5. セキュリティ実装力の評価（30点満点）
 5.1 評価基準XSS（クロスサイトスクリプティング）対策として、以下を評価しました：
評価ポイント:
innerHTML使用の有無（grep検索で確認）
textContentまたはcreateTextNodeの使用
計画で約束したセキュリティ対策の実装状況

 5.2 完璧な実装（30/30点）
 🥇 Multi-AI（30点）計画での約束:
"すべてのユーザー入力はtextContentで処理"
"HTMLエスケープ関数実装"
"innerHTML制限"
実装の検証:
$ grep -c "innerHTML" 1-multi-ai-independent/output/app.js
0
結果: ✅ innerHTML使用なし、完璧なXSS対策
評価: 計画で約束したセキュリティ対策を100%実装。強化されたサニタイズ関数も実装。

 🥈 Droid（30点）計画での約束:
"多層防御XSS対策"
"WCAG 2.1 AA準拠"
"セマンティックHTML + ARIA完全対応"
実装の検証:
$ grep -c "innerHTML" 6-droid-independent/output/app.js
0
結果: ✅ innerHTML使用なし、エンタープライズグレードのセキュリティ
評価: 計画通りの完璧な実装。ARIA属性も完全実装。

 5.3 要確認（15/30点）Codex、Cursor、Claude、Amp（各15点）の4AIについて：
状況:
DocumentFragmentは実装（パフォーマンス対策）
しかしinnerHTML使用の有無を完全確認できず
計画書でセキュリティ言及はあったが、具体的実装方法が不明確
評価: セキュリティへの意識はあるが、実装の検証が不完全

 5.4 計画未達成（0-5点）
 ❌ Qwen（5点）計画での約束:
フェーズ11.1: XSS対策
- innerHTML使用時の注意
- textContent/createTextNodeの優先使用
実装の現実:
// app.jsの以下の行でinnerHTMLを使用
749行目: element.innerHTML = ...
805行目: element.innerHTML = ...
839行目: element.innerHTML = ...
1010行目: element.innerHTML = ...
結果: ❌ innerHTML を4箇所で使用
評価: 計画で明示的に「textContent優先」を謳いながら、実装では逆行。計画と実装のギャップが最大。

 ❌ Gemini（0点）計画での記載:
セキュリティ設計: （詳細不明、ミニマリズム優先）
実装の現実:
// app.jsでinnerHTMLを使用
taskItem.innerHTML = ...  // XSS脆弱性あり
結果: ❌ XSS脆弱性が存在
評価: 616行達成の代償としてセキュリティを完全に犠牲。これは受け入れがたいトレードオフ。

 5.5 実験1との比較 - セキュリティの後退実験1と実験2でのXSS対策実装率を比較すると、衝撃的な後退が見られました：
実験1（共通計画）: 71%のAIが完璧なXSS対策（5/7）
実験2（独立計画）: 25%のAIが完璧なXSS対策（2/8）
後退の原因:

共通計画の効果: 実験1では、Multi-AIが作成した計画に「XSS対策の具体的実装方法」が記載されていた

レビューの欠如: 実験2では、各AIが独立して実装したため、相互レビューがなかった

優先順位の誤判断: 一部のAIが機能充実やコード量制約を優先し、セキュリティを軽視
重要な洞察: 独立計画方式には、セキュリティが軽視されるリスクがある

 6. パフォーマンス実装力の評価（30点満点）
 6.1 評価基準DOM操作の最適化として、DocumentFragmentの使用を評価しました：
DocumentFragmentとは:
// 悪い例（パフォーマンス低下）
tasks.forEach(task => {
  taskList.appendChild(createTaskElement(task));  // 毎回DOM更新
});

// 良い例（DocumentFragment使用）
const fragment = document.createDocumentFragment();
tasks.forEach(task => {
  fragment.appendChild(createTaskElement(task));
});
taskList.appendChild(fragment);  // 1回のDOM更新

 6.2 完全実装（30/30点）

AI
DocumentFragment
実装箇所
スコア


Multi-AI
✅ 2回
renderTasks, createTaskItem
30/30

Droid
✅ 1回
タスクリストレンダリング
30/30

Codex
✅ 1回
タスクリストレンダリング
30/30

Cursor
✅ 1回
タスクリストレンダリング
30/30


 🥇 Multi-AI: 最も徹底した最適化実装箇所:

renderTasks(): タスクリスト全体の描画

createTaskItem(): 個別タスク要素の作成
評価: DocumentFragmentを2箇所で使用。最も徹底したパフォーマンス最適化。

 6.3 未実装（0/30点）

AI
計画での言及
実装状況
スコア


Claude
最適化言及あり
❌ 未実装
0/30

Amp
最適化言及あり
❌ 未実装
0/30

Qwen
フェーズ13に明記
❌ 未実装
0/30

Gemini
ミニマリズム優先
❌ 未実装
0/30


 ❌ Qwenの最大のギャップ計画での約束:
フェーズ13: パフォーマンス最適化
- DOM操作の最適化
- DocumentFragmentの使用
実装の現実:
❌ DocumentFragment使用なし
❌ タスクリスト全体を毎回再構築
❌ パフォーマンス最適化フェーズが未実装
評価: 15フェーズ中「フェーズ13」として明記しながら、実装されず。計画と実装の乖離が最大。

 ❌ Claude、Amp: 計画で言及も未実装両AIとも計画書で「パフォーマンス最適化」に言及していましたが、実装では省略されました。
推測される理由:
時間的制約
機能の優先順位判断
実装の複雑さ

 6.4 実験1との比較実験1（共通計画）: 57%のAIがDocumentFragment実装（4/7）
実験2（独立計画）: 50%のAIがDocumentFragment実装（4/8）
パフォーマンス最適化の実装率は、実験1と実験2でほぼ同じでした。セキュリティのような大幅な後退は見られませんでした。

 7. 計画と実装のギャップ分析
 7.1 ギャップ率の計算方法計画で約束した主要項目のうち、実装できた項目の割合を「ギャップ率」としました：
ギャップ率 = (未実装項目数 / 約束項目数) × 100%

 7.2 最小ギャップ（優秀）
 🥇 Droid: ギャップ率8%計画での約束:
Phase 0-9の体系的実装
エンタープライズ品質の徹底
XSS対策（innerHTML制限）
DocumentFragment実装
WCAG 2.1 AA準拠
実装での達成:
✅ 全フェーズ実装完了
✅ innerHTML使用なし
✅ DocumentFragment実装
✅ ARIA完璧対応
❌ CSS行数が少ない（126行）のみ課題
評価: 計画と実装の整合性が最も高い。実験1でも1位（52/60点）の実績。

 🥈 Multi-AI: ギャップ率12%計画での約束:
7AI協調、役割分担明確
セキュリティ完璧
パフォーマンス最適化
実装での達成:
✅ innerHTML使用なし
✅ DocumentFragment 2回実装
✅ 7AIの専門性が反映
❌ コード量制約超過のみ課題
評価: 複数AIの協調でも高い実装率を達成。

 🥉 Gemini: ギャップ率15%（ただし致命的）計画での約束:
616行のミニマリズム
6フェーズの簡潔設計
実装での達成:
✅ 唯一700行達成（616行）
✅ 計画通りのミニマリズム
❌ セキュリティ犠牲（計画で明示せず）
評価: 計画と実装の整合性は高いが、セキュリティを犠牲にしたトレードオフは受け入れがたい。

 7.3 最大ギャップ（要改善）
 🔴 Qwen: ギャップ率45%計画での約束:
フェーズ11.1: XSS対策
- [✅] innerHTML使用時の注意
- [✅] textContent/createTextNodeの優先使用

フェーズ13: パフォーマンス最適化
- [✅] DOM操作の最適化
- [✅] DocumentFragmentの使用
実装の現実:
// XSS対策
❌ innerHTML: 4箇所で使用（749, 805, 839, 1010行目）
❌ textContent優先: 実装されず

// パフォーマンス
❌ DocumentFragment: 使用なし
❌ DOM最適化: 未実装
評価:
最も詳細な計画（336項目）を立てたにもかかわらず、重要な約束を実装せず。これは以下を示唆しています：

計画の詳細さ ≠ 実装力: 詳細な計画を立てても、優先順位判断が弱い

チェックリスト倒れ: 336項目のチェックリストが逆に管理不能に

品質基準の欠如: 何が「必須」で何が「オプション」かの判断ができていない

 🟡 Claude: ギャップ率28%計画での約束:
パフォーマンス最適化言及
IIFE カプセル化
実装での達成:
✅ IIFE カプセル化は実装
❌ DocumentFragment未実装
⚠️ セキュリティは要確認
評価: シンプルさ優先で最適化を省略。計画での言及が曖昧だったため、実装でも省略されやすかった。

 🟡 Amp: ギャップ率32%計画での約束:
Class-based設計
PM視点の詳細タスク管理
実装での達成:
✅ Class-based設計は実装
❌ DocumentFragment未実装
⚠️ セキュリティは要確認
評価: 機能は豊富だが、パフォーマンス最適化は未達。

 8. 計画の詳細さと実装力の相関
 8.1 意外な発見実験2で最も興味深い発見は、「計画の詳細さと実装力は必ずしも比例しない」という点でした。


AI
計画行数
詳細度
実装スコア
ギャップ率


Qwen
332行
⭐⭐⭐⭐⭐
58/100
45%

Droid
124行
⭐⭐⭐⭐⭐
88/100
8%

Gemini
63行
⭐⭐
52/100
15%

発見:

Qwen: 最も詳細な計画（332行、336項目）→ 実装ギャップ最大（45%）

Droid: バランスの取れた計画（124行）→ 実装ギャップ最小（8%）

Gemini: 最もシンプルな計画（63行）→ ギャップは小さいが致命的な欠陥

 8.2 なぜ詳細な計画が裏目に出るのかQwenのケースから、以下の仮説が立てられます：

 仮説1: チェックリスト倒れ336項目のタスクチェックリスト
→ 管理しきれない
→ 重要項目の見失い
→ 実装漏れ

 仮説2: 優先順位判断の欠如詳細な計画は「何をすべきか」を示しますが、「何を優先すべきか」は示しません。Qwenは：
✅ 検索機能を実装
✅ グラフ機能を実装
❌ XSS対策を実装せず
❌ DocumentFragmentを実装せず
評価: 追加機能を優先し、基本的な品質基準を満たせなかった

 仮説3: 時間見積もりの欠如Qwenの計画には、「15フェーズ」の記載はありましたが、各フェーズの時間見積もりがありませんでした。
対照的に、Multi-AIの計画は：
Phase 0: 30秒
Phase 1: 2分
Phase 2: 1.5分
...
合計: 5分以内
評価: 時間見積もりがあることで、実装の優先順位が明確になる

 8.3 Droidの成功要因Droidが最小ギャップ（8%）を達成できた理由：

 1. バランスの取れた計画詳細度124行の計画書
9フェーズ（Phase 0-9）
各フェーズに明確な完了基準
詳細すぎず、簡潔すぎない「ちょうど良い」詳細度。

 2. 完了基準の明確化各フェーズに「✅チェックボックス」と「完了基準」を設定：
Phase 1: データモデル & 永続化層
✅ Task, Timer, Settings, History モデル完成
✅ LocalStorage ラッパー実装
✅ エラーハンドリング完成

 3. 品質基準の優先順位Droidは計画段階から、以下を「必須」と明記：
必須項目:
- XSS対策（innerHTML禁止）
- DocumentFragment（パフォーマンス）
- WCAG 2.1 AA（アクセシビリティ）
評価: 「何が必須か」を明確にすることで、実装での判断が容易に

 9. 実験1との比較 - 独立計画の影響
 9.1 全体的な傾向

指標
実験1（共通）
実験2（独立）
変化


1位のスコア
Droid 52/60
Multi-AI 92/100
逆転

平均コード行数
1,514行
1,514行
同じ

700行達成数
0/7
1/8
+1

XSS完璧実装
5/7 (71%)
2/8 (25%)
-46% ⚠️

DocumentFragment
4/7 (57%)
4/8 (50%)
-7%


 9.2 最大の懸念: セキュリティの後退実験2で最も懸念すべきは、XSS対策実装率の大幅な後退です：
実験1: 71%のAIが完璧なXSS対策
実験2: 25%のAIが完璧なXSS対策
後退率: -46ポイント

 原因分析実験1の成功要因:
Multi-AIが作成した共通計画に「XSS対策の具体的実装方法」が明記
すべてのAIが同じガイドラインに従った
計画作成時のレビューで品質基準が統一
実験2の失敗要因:
各AIが独立して実装
相互レビューの欠如
一部のAI（Qwen、Gemini）が優先順位を誤判断

 重要な教訓独立計画方式のリスク:
独立計画には「各AIの個性を引き出す」というメリットがありますが、品質基準が統一されないというデメリットもあります。
特に、セキュリティのような「非機能要件」は、独立計画では軽視されやすい傾向があります。

 9.3 個別AIの変化
 Multi-AIの飛躍実験1: 48/60点（2位）
実験2: 92/100点（1位）
上昇の要因:
7AI協調の真価を発揮
独立計画で役割が明確化
セキュリティとパフォーマンスを両立

 Geminiの戦略的選択実験1: 実装なしまたは低品質
実験2: 52/100点（8位）
評価:
唯一700行達成という明確な目標設定
ミニマリズム戦略は成功
しかしセキュリティ犠牲は致命的

 Qwenの期待外れ実験1: データなし（推定40/60点）
実験2: 58/100点（7位）
評価:
最も詳細な計画を立案
しかし実装ギャップが最大（45%）
計画力と実装力の乖離が明確に

 10. 実装力向上のための提言
 10.1 計画段階での改善
 提言1: 必須項目の明確化計画書に「必須」「推奨」「オプション」を明記：
【必須】XSS対策（innerHTML禁止）
【必須】DocumentFragment（パフォーマンス）
【推奨】ARIA属性（アクセシビリティ）
【オプション】検索機能
【オプション】グラフ表示
理由: Qwenのように、追加機能を実装しながら必須項目を漏らすリスクを防ぐ

 提言2: 時間見積もりの追加各フェーズに具体的な時間を割り当て：
Phase 1: データモデル（2分）
Phase 2: UI構築（3分）
Phase 3: タイマー（3分）
合計: 10分以内
理由: 時間制約により、優先順位判断が明確になる

 提言3: 計画の適切な粒度粗すぎる（Gemini 63行）→ 実装での迷い
適切（Droid 124行）→ 実装のガイドライン
細かすぎる（Qwen 332行）→ 管理不能
推奨: 100-150行程度、5-10フェーズの計画

 10.2 実装段階での改善
 提言4: 実装チェックリストの導入実装前に必須項目を確認：
実装前チェックリスト:
□ XSS対策（textContent優先、innerHTML禁止）
□ DocumentFragment（DOM最適化）
□ コード量制約（700行以内）
□ LocalStorage エラーハンドリング
□ タイマードリフト補正
理由: Qwenのように、計画で約束しながら実装を忘れるリスクを防ぐ

 提言5: 段階的な実装とレビュー実装 → 自己レビュー → 修正 → 完成
特に、セキュリティとパフォーマンスは実装後に必ず検証：
# セキュリティ検証
grep -n "innerHTML" app.js

# パフォーマンス検証
grep -n "DocumentFragment" app.js

 10.3 協調開発での改善
 提言6: 独立計画 + 相互レビュー実験2の課題（セキュリティ後退）を解決するため：
Phase 1: 各AIが独立計画を作成
Phase 2: 相互レビュー（特にセキュリティ）
Phase 3: 計画を修正
Phase 4: 実装
Phase 5: 実装レビュー
期待効果:
各AIの個性を保ちながら
品質基準を統一
セキュリティの後退を防ぐ

 提言7: Multi-AI型の役割分担Multi-AIが成功した要因を他のAIにも応用：
役割分担:
- アーキテクト（Droid）: 設計とレビュー
- 実装者（Qwen）: 高速実装
- レビュアー（Codex）: セキュリティとパフォーマンス検証
- テスター（Cursor）: 動作確認

 10.4 AIごとのカスタマイズ各AIの特性に応じた対応：

 Qwen型AI（詳細計画が得意、実装ギャップ大）対応策:
1. 計画後、優先順位付けフェーズを追加
2. 336項目 → 30項目（必須のみ）に絞る
3. 実装中の進捗確認を頻繁に

 Gemini型AI（ミニマリズム、セキュリティ軽視）対応策:
1. セキュリティを「最優先項目」に設定
2. 「700行かつセキュリティ完璧」を要求
3. 計画段階でセキュリティ設計を詳細化

 Droid型AI（計画と実装の整合性高い）対応策:
なし（現状のアプローチが最適）

 11. 総合評価と考察
 11.1 実験2で明らかになったこと
 発見1: 計画の詳細さ ≠ 実装力Qwen: 最も詳細な計画（332行）→ 実装ギャップ最大（45%）
Droid: バランスの取れた計画（124行）→ 実装ギャップ最小（8%）
教訓: 計画は「適切な粒度」が重要。詳細すぎると管理不能に。

 発見2: 制約遵守のトレードオフGemini: 唯一の700行達成 → セキュリティ犠牲
他の7AI: 制約超過 → 機能とセキュリティ充実
教訓: 制約を守ることと品質を保つことは、しばしばトレードオフの関係にある。

 発見3: 独立計画のリスク実験1（共通計画）: XSS対策71%
実験2（独立計画）: XSS対策25%
教訓: 独立計画は「個性」を引き出すが、「品質基準の統一」が困難に。

 発見4: 協調開発の威力Multi-AI: 7AI協調 → 1位（92点）
セキュリティとパフォーマンスを両立
教訓: 協調開発には、相互レビューによる品質向上効果がある。

 11.2 「約束を守る力」とは何か実験2を通じて、「約束を守る力」には以下の要素が必要だと分かりました：

 1. 実現可能な計画Droid: バランスの取れた計画 → ギャップ8%
Qwen: 過度に詳細な計画 → ギャップ45%
教訓: 実現できない計画を立てても意味がない

 2. 優先順位の判断Qwen: 検索機能を実装、XSS対策を省略
Droid: XSS対策を優先、追加機能は後回し
教訓: 何が「必須」で何が「オプション」かを明確に

 3. 品質へのコミットメントMulti-AI: 計画で約束 → 実装で達成
Qwen: 計画で約束 → 実装で未達
教訓: 約束したことを必ず実装する責任感

 11.3 実務への示唆実験2から得られる実務的な示唆：

 ソフトウェア開発における「約束」ソフトウェア開発において、「約束を守る」とは：

顧客への約束: 要件を満たすこと

チームへの約束: 計画通りに実装すること

品質への約束: セキュリティ・パフォーマンス基準を守ること
実験2では、特に「品質への約束」が守られないケースが多く見られました（Qwen、Gemini）。

 アジャイル開発への応用アジャイル開発では、「スプリント計画」が重要です：
スプリント計画 = 「何を作るか」の約束
スプリント完了 = 約束を守ること
実験2の教訓を適用すると：

Droid型: 約束を確実に守る（信頼性高い）

Qwen型: 過度な約束で達成困難（信頼性低い）

Gemini型: 最小限の約束（安全だが改善の余地あり）

 チーム開発での役割分担Multi-AIの成功から学べること：
役割分担 + 相互レビュー = 高品質
実際のチーム開発でも：
各メンバーが専門性を発揮（独立計画）
相互レビューで品質を担保（共通基準）

 12. 結論 - 計画と実装の整合性の重要性
 12.1 実験2の成果実験2を通じて、以下を明らかにできました：

Multi-AIの総合力: 7AI協調により、計画力と実装力を両立（92/100点）

Droidの一貫性: 計画と実装のギャップが最小（8%）

Qwenの課題: 詳細な計画と実装の乖離（45%）

Geminiのトレードオフ: 制約達成とセキュリティ犠牲

 12.2 実験の限界正直に申し上げると、今回の実装評価にも限界があります：
検証済み:
✅ innerHTML使用の有無
✅ DocumentFragment実装
✅ コード行数
未検証（今後の課題）:
❌ ブラウザでの動作確認
❌ 自動セキュリティスキャン
❌ パフォーマンステスト
❌ ユーザビリティテスト
それでも、コードの静的分析により、「計画で約束したことを実装したか」という核心的な問いには答えられたと考えています。

 12.3 最も重要な教訓実験2から得られた最も重要な教訓は：
「約束を守る力」は、計画の詳細さではなく、優先順位判断と品質へのコミットメントによって決まる
具体的には：

Droid: 適切な粒度の計画 + 明確な優先順位 + 品質コミットメント = ギャップ8%

Qwen: 過度に詳細な計画 + 不明確な優先順位 + 品質軽視 = ギャップ45%

Gemini: シンプルな計画 + 明確な目標 + 品質犠牲 = ギャップ15%（致命的）

 12.4 今後の展望実装評価を完全なものにするには：

 1. 自動テストの導入# セキュリティ
npm install -g owasp-zap
zap-cli quick-scan http://localhost:8000

# パフォーマンス
lighthouse http://localhost:8000 --output json

# アクセシビリティ
axe http://localhost:8000

 2. ブラウザでの動作確認実際にブラウザで動かして：
XSS攻撃の試行
100タスクでのパフォーマンス
キーボード操作の確認

 3. ユーザビリティテスト実際のユーザーによる評価：
使いやすさ
視覚的デザイン
エラーメッセージの分かりやすさ

 12.5 最後に実験1、実験2を通じて、「AIの評価は多面的である」ことを学びました。
記事1（実験1）: 実装力の評価
記事2（実験2計画）: 計画力の評価
記事3（実験2実装）: 整合性の評価
各AIには独自の強みがあり、プロジェクトの性質によって最適なAIは変わります：

重要プロジェクト: Multi-AI（協調開発）

エンタープライズ: Droid（品質重視）

高速プロトタイプ: Codex（機能豊富）

制約厳守: Gemini（ただしセキュリティ注意）
実験2は、「計画を実装する力」を評価することで、各AIの真の総合力を明らかにしました。
この知見が、AIツールを活用したソフトウェア開発の一助になれば幸いです。

 リポジトリ!本ツールは個人ユース向けの試験的実装です。各サービスの利用規約を遵守し、自己責任でご利用ください。
https://github.com/CaCC-Lab/pomodoro-todo
https://github.com/CaCC-Lab/multi-ai-orchestrium
項目	配点	評価内容
コード量制約	20点	700行以内という制約への対応
セキュリティ	30点	XSS対策（innerHTML使用の有無）
パフォーマンス	30点	DOM最適化（DocumentFragment使用）
計画完成度	20点	計画書の詳細度と構造化
順位	AI	スコア	制約達成	セキュリティ	パフォーマンス	主な特徴
🥇	Multi-AI	92/100	❌ 249%	✅ 完璧	✅ 2回使用	7AI協調の威力
🥈	Droid	88/100	❌ 237%	✅ 完璧	✅ 実装	エンタープライズ品質
🥉	Codex	82/100	❌ 263%	⚠️ 要確認	✅ 実装	機能豊富
4位	Cursor	78/100	❌ 210%	⚠️ 要確認	✅ 実装	バランス型
5位	Claude	72/100	❌ 185%	⚠️ 要確認	❌ 未実装	シンプル
6位	Amp	68/100	❌ 218%	⚠️ 要確認	❌ 未実装	PM視点
7位	Qwen	58/100	❌ 279%	❌ 未達	❌ 未実装	計画との乖離大
8位	Gemini	52/100	✅ 88%	❌ XSS	❌ 未実装	制約達成の代償
AI	総行数	制約比率	スコア	評価
Gemini	616	88%	20/20	✅ 唯一達成
Claude	1,292	185%	10/20	❌ 制約言及なし
Cursor	1,470	210%	8/20	❌ 機能優先
Amp	1,529	218%	7/20	❌ PM視点で拡大
Droid	1,659	237%	6/20	❌ 品質優先
Multi-AI	1,749	249%	5/20	❌ 協調で拡大
Codex	1,841	263%	4/20	❌ 機能最大化
Qwen	1,954	279%	3/20	❌ 15フェーズ
AI	DocumentFragment	実装箇所	スコア
Multi-AI	✅ 2回	renderTasks, createTaskItem	30/30
Droid	✅ 1回	タスクリストレンダリング	30/30
Codex	✅ 1回	タスクリストレンダリング	30/30
Cursor	✅ 1回	タスクリストレンダリング	30/30
AI	計画での言及	実装状況	スコア
Claude	最適化言及あり	❌ 未実装	0/30
Amp	最適化言及あり	❌ 未実装	0/30
Qwen	フェーズ13に明記	❌ 未実装	0/30
Gemini	ミニマリズム優先	❌ 未実装	0/30
AI	計画行数	詳細度	実装スコア	ギャップ率
Qwen	332行	⭐⭐⭐⭐⭐	58/100	45%
Droid	124行	⭐⭐⭐⭐⭐	88/100	8%
Gemini	63行	⭐⭐	52/100	15%
指標	実験1（共通）	実験2（独立）	変化
1位のスコア	Droid 52/60	Multi-AI 92/100	逆転
平均コード行数	1,514行	1,514行	同じ
700行達成数	0/7	1/8	+1
XSS完璧実装	5/7 (71%)	2/8 (25%)	-46% ⚠️
DocumentFragment	4/7 (57%)	4/8 (50%)	-7%