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ツールを活用したソフトウェア開発の一助になれば幸いです。

リポジトリ

Discussion