📌

【実験5：役割分担レビュー】Claude Code/Gemini/Codex/Cursor/Amp/Droidに同じアプリを実装させてみた

に公開
AI
Jest
Test
品質保証
比較実験
tech

1. はじめに - 実験４から生まれた新しい問い

実験４では、各AIが自分の実装コードを自己レビューする能力を測定しました。その結果、興味深い傾向が見えてきました。

実験４の結果の振り返り

自己レビューの発見数:

  • Cursor: 7件（最多）
  • Gemini, Droid, Qwen: 2件
  • Multi-AI: 1件
  • Claude, Codex, Amp: 0件

客観評価の結果:

  • 全AI: CodeRabbitとSecurityレビューで0件（全て合格）

実験４の総合ランキング:

  1. Cursor: 94点 ← 自己レビュー7件が高評価
  2. Gemini, Droid, Qwen: 84点
  3. Multi-AI: 82点
  4. Claude, Codex, Amp: 80点 ← 自己レビュー0件

実験４の評価方式の特徴

実験４では「自己レビューで多くの問題を発見するほど高スコア」という評価方式でした。これは「自己認識能力」を測定する目的で設計されました。

しかし、この結果には重要な疑問が残りました：

  1. Cursorの7件は何を意味するのか？

    • 優れた自己認識なのか？
    • 実装品質が低いだけなのか？
    • 他のAIも同じ問題を発見するのか？

  2. Claude/Codex/Ampの0件は何を意味するのか？

    • 実装が本当に完璧なのか？
    • 自己評価が甘いだけなのか？
    • 他のAIがレビューしたら問題が見つかるのか？

実験５の根本的な発想転換

実験４への疑問を考える中で、もっと根本的な問いに気づきました：

「そもそも、1人のレビュアーに全てを期待するのが間違っているのでは？」

人間のチーム開発を考えると：

  • セキュリティエンジニア → セキュリティレビュー
  • パフォーマンスエンジニア → パフォーマンスレビュー
  • PMレビュアー → ドキュメント・完成度レビュー
  • アーキテクト → アーキテクチャレビュー

誰も「1人の完璧なレビュアー」を探さない。それぞれの専門家が、それぞれの視点でレビューする。

実験５の新しいアプローチ

実験５では、この「専門家による役割分担レビュー」をAIで再現することにしました：

実験４: 各AIが自分のコードを包括的に自己レビュー
       → 自己認識能力を測定

実験５: 各AIが専門領域に特化してCursorのコードをレビュー
       → 専門性の深さと役割分担の有効性を測定

重要な実験設計の意図:

実験５では、各AIに「全てをレビューしてください」とは言っていません。むしろ、意図的に専門領域を割り当てました。

これにより、以下を検証できると考えました：

  1. 各AIは専門領域で深い分析ができるか
  2. 専門家による役割分担は有効か
  3. 包括的レビュー vs 専門特化レビューの違い

※ 本記事は筆者のアイデアを元に生成AI（Claude）が自動作成したものです。必要に応じて追加の確認や調査を推奨します。

2. 実験設計 - 専門家チームとしてのレビュー

2.1 実験の対象コード

レビュー対象: Cursor実装のPomodoroTODOアプリ

Cursorを選んだ理由：

  • 実験４で7件の自己問題を報告
  • 他の専門家（AI）の見解を確認しやすい
  • 独立した実装のため、他のAIへのバイアスがない

対象ファイル:

  • app.js: アプリケーションロジック
  • index.html: UI構造
  • style.css: スタイリング

2.2 専門家チームの構成（意図的な役割分担）

実験５の核心は、各AIに異なる専門領域を割り当てたことです：

レビューAI 依頼した専門領域 レビュー範囲
Amp ドキュメント & PM ドキュメント品質、完成度、ステークホルダー視点
Gemini セキュリティ & アーキテクチャ OWASP Top 10、脆弱性、設計パターン
Qwen コード品質 & パターン 可読性、保守性、デザインパターン
Droid エンタープライズ基準 スケーラビリティ、信頼性、本番品質
Codex 問題解決 & 最適化 バグ、エラー、アルゴリズム効率
Claude 包括的レビュー 全観点での総合評価（唯一の包括的レビュー）
Multi-AI 統合レビュー セキュリティ + 品質 + エンタープライズの3種統合

2.3 実験設計の重要な意図

この役割分担は偶然ではありません。意図的な実験設計です。

意図1: 専門性の深さを測定

各AIに専門領域を割り当てることで：

  • その領域でどれだけ深く分析できるか
  • 専門家としての能力を測定できる

意図2: 役割分担の有効性を検証

人間のチーム開発と同じように：

  • 1人の完璧なレビュアーより、専門家チームの方が効果的か
  • 異なる視点を組み合わせることで、見逃しを減らせるか

意図3: 包括的 vs 専門特化の比較

Claudeだけが包括的レビューを依頼されました。これにより：

  • 包括的レビューのメリット・デメリット
  • 専門特化レビューのメリット・デメリット
  • を比較できる

2.4 実験の実施方法

実行環境:

  • 各AIに同じコードを独立してレビューさせる
  • タイムアウト設定: 1,800秒（30分）/レビュー
  • レビュー結果はJSONフォーマットで自動収集

レビュー指示の独立性:

  • 各AIには専門領域のみを指示
  • 他のAIのレビュー結果は見せない
  • 同時並行実行により相互影響を排除

2.5 実験の限界

この実験にも限界があることを最初にお伝えしておきます：

限界1: 専門領域の割り当て

  • 専門領域の割り当ては、これまでの実験（1〜4）の観察に基づく
  • 各AIの「真の専門性」とは異なる可能性がある
  • より多くの実験で検証が必要

限界2: 比較の公平性

  • 専門領域が異なるため、直接比較は難しい
  • 「誰が最も優れたレビュアーか」を判定することが目的ではない
  • むしろ「役割分担の有効性」を評価する実験

限界3: サンプルサイズ

  • レビュー対象はCursorの1実装のみ
  • 他の実装でも同様の結果になるかは不明

これらの限界を理解した上で、それでも得られた興味深い知見を共有させていただきます。

3. 実験結果 - 各専門家の発見

3.1 実行結果サマリー

全7つのAIによるレビューは無事に完了しました：

AI ステータス 実行時間 発見数 評価判定
Amp SUCCESS 120秒 12件 -
Claude SUCCESS 110秒 8件 ✅ correct（DO NOT MERGE）
Codex SUCCESS 90秒 12件 ✅ correct
Droid SUCCESS 180秒 4件 ❌ incorrect
Gemini SUCCESS 60秒 3件 ❌ incorrect
Multi-AI SUCCESS 320秒 3件 ✅ correct
Qwen SUCCESS 120秒 約10件 -

総実行時間: 337秒（約5.6分）
成功率: 7/7（100%）

3.2 各専門家の発見（専門領域別）

実験５の重要なポイントは、各AIが依頼された専門領域で何を発見したかです。

専門家A: Amp（ドキュメント & PM専門）

依頼した専門領域: ドキュメント品質、完成度、ステークホルダー視点

発見した問題（12件）:

  1. README完全欠如 ← Ampにしか依頼していない
  2. ドキュメント不在 ← Ampの専門領域
  3. Pomodoroタイマー未実装（完成度の観点）
  4. 設定ダイアログ非機能
  5. 統計表示なし
  6. その他、PM視点での完成度問題

評価:

  • Ampは依頼通り、ドキュメントと完成度に注目した
  • PM視点での「ステークホルダーが期待する機能」の欠落を指摘
  • 発見数12件は、完成度評価の詳細さを示す

専門家B: Gemini（セキュリティ & アーキテクチャ専門）

依頼した専門領域: OWASP Top 10、脆弱性、設計パターン

発見した問題（3件）:

  1. Prototype Pollution脆弱性 ← Geminiのみが発見
  2. CSP（Content Security Policy）欠如
  3. Task ID衝突リスク

評価:

  • Geminiは依頼通り、セキュリティに深く特化した
  • Prototype Pollution脆弱性は他の6AIが見逃した高度な問題
  • 発見数は少ないが、質が高い（専門性の深さ）

専門家C: Qwen（コード品質 & パターン専門）

依頼した専門領域: 可読性、保守性、デザインパターン

発見した問題（約10件）:

  1. ファイル長の過剰（798行のapp.js） ← Qwenの専門領域
  2. Pomodoroタイマー未実装（機能完全性の観点）
  3. コード構造の問題
  4. その他、保守性に関する問題

評価:

  • Qwenは依頼通り、コード品質と保守性に注目
  • アーキテクチャを評価しつつ、実装不足も指摘
  • バランスの取れた品質レビュー

専門家D: Droid（エンタープライズ基準専門）

依頼した専門領域: スケーラビリティ、信頼性、本番品質

発見した問題（4件）:

  1. Pomodoroタイマー未実装（本番リリース不可）
  2. 設定ダイアログ非機能（エンタープライズ品質欠如）
  3. 統計更新なし
  4. オーディオアセット404エラー

評価: ❌ incorrect（最も厳格な判定）

  • Droidは依頼通り、エンタープライズ基準で評価
  • 発見数は4件だが、全てCritical（本番環境で許容不可）
  • 最も厳しい"patch is incorrect"判定

専門家E: Codex（問題解決 & 最適化専門）

依頼した専門領域: バグ、エラー、アルゴリズム効率

発見した問題（12件）:

  • 実験スクリプト自体をレビュー（メタレビュー）
  • タイムアウト設定の不整合を発見
  • システム全体の視点での問題指摘

評価:

  • Codexは対象を広く解釈（意図とは異なる）
  • ただし、システム全体の視点は貴重
  • 問題解決の専門家として、プロセスレベルの改善提案

専門家F: Claude（包括的レビュー専門）

依頼した専門領域: 全観点での総合評価

発見した問題（8件）:

  1. Pomodoroタイマー未実装
  2. 設定ダイアログ非機能
  3. 統計更新なし
  4. メモリリーク可能性（subscribers未解除） ← Claudeのみが発見
  5. オーディオアセット404エラー
  6. README不在
  7. テスト皆無
  8. その他、包括的な問題

評価: ✅ correct（DO NOT MERGE推奨）

  • Claudeは唯一、全観点でのレビューを実施
  • 8カテゴリーでの評価（最も包括的）
  • 工数見積もりまで提供

専門家G: Multi-AI（統合レビュー）

依頼した専門領域: セキュリティ + 品質 + エンタープライズの3種統合

発見した問題（3件）:

  1. セキュリティ問題（XSS、CSP）
  2. 品質問題
  3. エンタープライズ基準の問題

評価: ✅ correct

  • 3つの専門レビューを並列実行
  • 統合的な視点でのレビュー
  • 今回はセキュリティレビューのみ成功

3.3 専門領域ごとの発見の比較

重要: 以下の比較は「優劣」ではなく「専門性の違い」を示しています。

発見内容 発見したAI 理由
README不在 Amp, Claude Ampに依頼、Claudeは包括的レビュー
Prototype Pollution Gemini セキュリティ専門家として深掘り
CSP欠如 Gemini, Multi-AI セキュリティ特化AI
ファイル長過剰 Qwen コード品質専門家の視点
メモリリーク可能性 Claude 包括的レビューで技術的詳細も
Pomodoroタイマー未実装 Amp, Droid, Qwen, Claude 全ての専門家が指摘（4/7）

3.4 最も重要な発見：全専門家の合意

驚くべき結果: 専門領域が異なるにも関わらず、4つのAI（57%）が同じ重大問題を指摘しました：

Pomodoroタイマー未実装

  • Amp（PM視点）: 「コア機能が欠落、完成度40-60%」
  • Droid（エンタープライズ視点）: 「本番リリース不可」
  • Qwen（品質視点）: 「機能完全性の欠如」
  • Claude（包括的視点）: 「推定工数4-6時間で実装可能」

この合意の意味:

異なる専門領域からレビューしても、本当に重大な問題は全員が気づくということです。これは：

  • 専門家による役割分担の有効性を示す
  • 重要な問題は見逃されにくいことを示す
  • 異なる視点の組み合わせが強力であることを示す

4. 詳細分析 - 専門性の深さと役割分担の効果

4.1 専門性の深さの評価

各AIは、依頼された専門領域でどれだけ深く分析できたか？

深い専門性を示したAI

1. Gemini（セキュリティ専門）

  • Prototype Pollution脆弱性を唯一発見
  • 他の6AIは誰も見つけられなかった高度な問題
  • セキュリティ専門家としての深い知識を発揮

評価: ⭐⭐⭐⭐⭐（5/5）
専門領域での深さは抜群。発見数は少ないが、質が非常に高い。

2. Amp（ドキュメント & PM専門）

  • README、ドキュメント、セットアップ手順の欠如を詳細に指摘
  • PM視点での完成度評価（40-60%）を明確に提示
  • ステークホルダー視点での問題を12件発見

評価: ⭐⭐⭐⭐⭐（5/5）
ドキュメント評価を依頼したのはAmpだけ。その領域で圧倒的な詳細さ。

3. Droid（エンタープライズ専門）

  • 本番環境で許容できない問題を4件発見（全てCritical）
  • 最も厳しい"patch is incorrect"判定
  • エンタープライズ基準での妥協のない評価

評価: ⭐⭐⭐⭐⭐（5/5）
発見数は少ないが、厳格さと実用性の観点で最高レベル。

バランスの取れた専門性を示したAI

4. Claude（包括的レビュー）

  • 8カテゴリーでの詳細評価
  • 工数見積もり（4-6時間）まで提供
  • メモリリーク可能性など、技術的詳細も指摘

評価: ⭐⭐⭐⭐（4/5）
包括的だが、各領域の深さは専門特化AIに劣る部分もある。

5. Qwen（コード品質専門）

  • コード品質と保守性に注目（約10件発見）
  • ファイル長過剰など、品質専門家ならではの指摘
  • アーキテクチャと実装のバランス評価

評価: ⭐⭐⭐⭐（4/5）
品質評価として適切だが、特筆すべき深い発見は少ない。

特殊な専門性を示したAI

6. Codex（問題解決専門）

  • 実験スクリプト自体をレビュー（メタレビュー）
  • タイムアウト設定の不整合を発見
  • システム全体の視点

評価: ⭐⭐⭐（3/5）
意図とは異なる対象をレビューしたが、その視点は貴重。

7. Multi-AI（統合レビュー）

  • 3つの専門レビューを並列実行
  • 今回はセキュリティレビューのみ成功
  • 統合の難しさも露呈

評価: ⭐⭐⭐（3/5）
統合レビューの可能性を示したが、今回は部分的な成功。

4.2 専門特化 vs 包括的レビューの比較

実験５の重要な比較は、Claudeの包括的レビュー vs 他のAIの専門特化レビューです。

包括的レビュー（Claude）の特徴

メリット:

  • 全観点を1人でカバー（効率的）
  • 観点間のバランスを考慮できる
  • 1つのレポートで全体像が把握できる

デメリット:

  • 各領域の深さは専門家に劣る
  • Prototype Pollutionのような高度な問題を見逃す可能性
  • 1人の知識の限界

Claudeの発見:

  • 8件（広く浅い）
  • メモリリーク可能性など、技術的詳細も一部あり
  • 工数見積もりなど、実用的な情報も提供

専門特化レビュー（Gemini, Amp, Droid等）の特徴

メリット:

  • 各領域で非常に深い分析
  • 他のAIが見逃す高度な問題を発見
  • 専門知識を最大限に活用

デメリット:

  • 複数のレビュアーが必要（コスト増）
  • 統合の手間がかかる
  • 観点間のバランスを取るのが難しい

専門家たちの発見:

  • Gemini: 3件（狭く深い）- Prototype Pollution発見
  • Amp: 12件（ドキュメント特化）- README不在を詳細指摘
  • Droid: 4件（厳格な品質基準）- 本番リリース不可判定

4.3 役割分担の有効性

実験５の最も重要な発見は、役割分担レビューの有効性です。

発見1: 重大問題は見逃されない

異なる専門領域からレビューしても、Pomodoroタイマー未実装というコア機能の欠落は、4つのAI（57%）が指摘しました。

示唆: 本当に重大な問題は、どの専門家も気づく。役割分担しても、重要な問題は見逃されにくい。

発見2: 専門家は独自の価値を提供

各専門家が、他のAIが見逃した問題を発見：

  • Gemini → Prototype Pollution（他の6AIが見逃し）
  • Amp → README不在の詳細分析（他のAIはさらっと指摘）
  • Claude → メモリリーク可能性（他のAIは言及なし）

示唆: 専門家による役割分担は、それぞれが独自の価値を提供する。包括的レビュー1つより、専門家チームの方が見逃しが少ない可能性。

発見3: 評価の厳格さは専門領域に依存

評価の厳格さは、単なる「AIの性格」ではなく、依頼された専門領域に依存する可能性：

  • Droid（エンタープライズ基準）: "patch is incorrect"（最も厳格）
  • Gemini（セキュリティ基準）: "patch is incorrect"（セキュリティ観点で不合格）
  • Claude（包括的基準）: "DO NOT MERGE"（バランス型の判断）

示唆: AIの「厳格さ」は固定的な性質ではなく、評価基準（専門領域）によって変わる。

5. Cursor実装の総合評価 - 専門家たちの合意

5.1 全専門家が一致して評価した強み

7つのAIが独立してレビューした結果、Cursorの強みについて驚くべき合意が形成されました：

1. 優れたアーキテクチャ設計 ⭐⭐⭐⭐⭐（5/5）

評価したAI: Claude（包括的）, Qwen（品質）, Droid（エンタープライズ）

共通評価:

  • 明確な責任分離（Models, Storage, State, View）
  • Pub/Subパターンの適切な実装
  • 拡張性の高い設計

注目点: 異なる専門領域（包括的、品質、エンタープライズ）から評価しても、アーキテクチャの優秀さは全員が認めた。

2. セキュリティのベストプラクティス ⭐⭐⭐⭐⭐（5/5）

評価したAI: Gemini（セキュリティ）, Multi-AI（統合）, Claude（包括的）

共通評価:

  • textContent使用によるXSS防止
  • 入力検証の徹底
  • セキュアなDOM操作

注目点: Geminiのようなセキュリティ専門家も、基本的なセキュリティ対策は高く評価。ただし、高度な問題（Prototype Pollution）は指摘。

3. アクセシビリティ対応 ⭐⭐⭐⭐⭐（5/5）

評価したAI: Claude（包括的）

  • ARIA属性の包括的実装
  • キーボードナビゲーション完備
  • スクリーンリーダー対応

注目点: Claudeの包括的レビューだからこそ発見できた強み。専門特化AIはアクセシビリティに言及せず。

4. コードスタイルの一貫性 ⭐⭐⭐⭐⭐（5/5）

評価したAI: Qwen（品質）, Claude（包括的）

共通評価:

  • 可読性と保守性が高い
  • 一貫した命名規則
  • 適切なコメント

5.2 全専門家が一致して指摘した弱み

一方で、致命的な問題についても合意が形成されました：

1. 完成度の致命的不足 ❌（40-60%のみ完成）

指摘したAI: Amp（PM）, Droid（エンタープライズ）, Qwen（品質）, Claude（包括的）

各専門家の視点:

  • Amp（PM視点）: 「コア機能が欠落、ステークホルダーの期待に応えられない」
  • Droid（エンタープライズ視点）: 「本番リリース不可、Critical問題」
  • Qwen（品質視点）: 「機能完全性の欠如、アーキテクチャは良いが実装不足」
  • Claude（包括的視点）: 「推定工数4-6時間で実装可能」

具体的な問題:

  • Pomodoroタイマー: 0%実装（4AI指摘）
  • 設定ダイアログ: UI存在するも配線なし（2AI指摘）
  • 統計表示: 永久に"0"表示（2AI指摘）
  • オーディオアセット: 404エラー（3AI指摘）

2. ドキュメント完全欠如 ❌（0/5）

指摘したAI: Amp（ドキュメント専門）, Claude（包括的）

Ampの詳細指摘（ドキュメント専門家として）:

  • README不在
  • セットアップ手順なし
  • API仕様書なし
  • コメント/説明不足

Claudeの補足:

  • 推定工数1時間でREADME作成可能

注目点: ドキュメントレビューを依頼したのはAmpだけ。だからこそ、詳細な分析ができた。

3. テスト皆無 ❌（1/5）

指摘したAI: Claude（包括的）

  • テストインターフェース存在するもテストファイル0
  • テストカバレッジ0%

注目点: テストレビューを明示的に依頼したAIはなし。Claudeが包括的レビューの一環として指摘。

4. 潜在的セキュリティリスク ⚠️

指摘したAI: Gemini（セキュリティ専門）, Multi-AI（統合）, Claude（包括的）

各専門家の視点:

  • Gemini（セキュリティ専門）: 「Prototype Pollution脆弱性（高度）」← 唯一の発見
  • Gemini + Multi-AI: 「CSP欠如（防御層の追加が必要）」
  • Gemini + Claude: 「Task ID衝突リスク」

注目点: Geminiの専門性の深さが際立つ。他のAIは高度なセキュリティ問題を見逃した。

5.3 専門家たちの統合判定

7つのAIの独立したレビュー結果を統合すると、以下の結論に至りました：

結論: Cursor実装は優れた設計だが、コア機能が0%実装
完成度: 40-60%
推奨: DO NOT MERGE / patch is incorrect

推奨改善事項（優先度順）:

優先度 項目 推定工数 指摘した専門家
P0 (Critical) Pomodoroタイマーの完全実装 4-6時間 Amp, Droid, Qwen, Claude
P0 (Critical) 設定ダイアログの配線 1-2時間 Droid, Claude
P0 (Critical) 統計表示の実装 1時間 Droid, Claude
P0 (Critical) README作成 1時間 Amp, Claude
P1 (High) Prototype Pollution対策 - Gemini
P1 (High) テスト実装 3-4時間 Claude
P2 (Medium) CSP追加 - Gemini, Multi-AI

総合推定工数: 13-19時間で100%完成

6. 最も重要な発見 - 役割分担レビューの有効性

6.1 実験５の核心的な問い

実験５の最も重要な目的は、専門家による役割分担レビューの有効性を検証することでした：

問い1: 専門領域に特化したレビューは、深い分析ができるか？
問い2: 異なる専門家の組み合わせは、包括的レビュー1つより優れているか？
問い3: 人間のチーム開発の考え方は、AIレビューにも適用できるか？

6.2 検証結果：専門性の深さ

結論: ✅ 専門領域に特化したレビューは、非常に深い分析ができる

証拠:

  1. Geminiの発見（セキュリティ専門）

    • Prototype Pollution脆弱性を唯一発見
    • 他の6AI（包括的レビューのClaudeを含む）は見逃した
    • 専門家としての深い知識を発揮

  2. Ampの発見（ドキュメント専門）

    • README、セットアップ、API仕様書の欠如を詳細に指摘
    • 12件の詳細な問題リスト
    • 他のAIは「ドキュメント不足」とさらっと指摘するのみ

  3. Droidの発見（エンタープライズ専門）

    • 本番環境で許容できない4件の問題（全てCritical）
    • 最も厳しい"patch is incorrect"判定
    • エンタープライズ基準での妥協のない評価

示唆: 専門領域を絞ることで、その領域での分析の深さが増す。

6.3 検証結果：役割分担の有効性

結論: ✅ 専門家チームは、包括的レビュー1つより見逃しが少ない

証拠:

包括的レビュー（Claude）が見逃した問題:

  • Prototype Pollution脆弱性（Geminiが発見）
  • ドキュメントの詳細な問題（Ampが12件指摘、Claudeは簡潔に1件）

専門特化レビューが見逃した問題:

  • メモリリーク可能性（Claudeのみが指摘）
  • アクセシビリティ対応（Claudeのみが評価）
  • テスト皆無（Claudeのみが指摘）

統合的な理解:

包括的レビュー1つ:
├─ メリット: 全観点をカバー、バランスが良い
└─ デメリット: 各領域の深さに限界

専門家チーム:
├─ メリット: 各領域で非常に深い分析、見逃しが少ない
└─ デメリット: 統合の手間、コスト増

最適解: 両方を組み合わせる
├─ 専門特化レビュー（Gemini, Amp, Droid等）で深掘り
└─ 包括的レビュー（Claude）で全体統合

6.4 検証結果：人間チーム開発との類似性

結論: ✅ 人間のチーム開発の考え方は、AIレビューにも適用できる

人間のチーム開発:

セキュリティエンジニア → セキュリティレビュー
品質エンジニア → コード品質レビュー
PMレビュアー → ドキュメント・完成度レビュー
アーキテクト → アーキテクチャレビュー

実験５のAIチーム:

Gemini → セキュリティレビュー（Prototype Pollution発見）
Qwen → コード品質レビュー（保守性評価）
Amp → ドキュメント・完成度レビュー（12件の詳細指摘）
Droid → エンタープライズ基準レビュー（厳格な評価）

示唆: AIレビューも、人間チーム開発と同じ原則が適用できる。「1人の完璧なレビュアー」を探すのではなく、「専門家チームを編成する」のが正解。

7. 実務への応用 - どう役割分担すべきか

7.1 推奨レビュー戦略（実験５検証済み）

実験５の結果に基づいた、実務で使える役割分担戦略を提案します：

戦略1: 高速チェック（5-10分）

推奨構成: Qwen（品質専門）単体

  • コード品質と保守性の迅速評価
  • 実行時間: 約120秒
  • 用途: プルリクエストの初期レビュー
  • メリット: 低コスト、高速
  • デメリット: セキュリティや完成度は評価されない

戦略2: 標準開発レビュー（15-20分）

推奨構成: Claude（包括的）+ Amp（PM）

  • Claude: 包括的フィードバック（8カテゴリー評価）
  • Amp: PM視点での完成度評価
  • 合計実行時間: 約230秒
  • 用途: 通常の開発サイクルでの品質確保
  • メリット: バランスが良い、実用的
  • デメリット: 高度なセキュリティ問題は見逃す可能性

戦略3: 本番リリース前（30-40分）

推奨構成: Droid（エンタープライズ）+ Gemini（セキュリティ）

  • Droid: エンタープライズ基準での厳格評価
  • Gemini: セキュリティ脆弱性の深掘り
  • 合計実行時間: 約240秒
  • 用途: プロダクション環境へのデプロイ前
  • メリット: 高度な問題も発見、厳格
  • デメリット: コスト高、時間がかかる

戦略4: 最大品質保証（60分+）

推奨構成: 全7AI並列実行

  • 多角的な完全レビュー
  • 総実行時間: 約337秒（5.6分）
  • 用途: クリティカルなシステム、大規模リリース
  • メリット: 見逃しが最小限、全観点カバー
  • デメリット: 最もコスト高、統合の手間

7.2 AIの役割分担最適化（実験５実証済み）

実験５の結果から、各AIの最適な役割が明確になりました：

AI 推奨役割 理由（実験５で実証）
Gemini セキュリティ専門レビュアー Prototype Pollution発見。高度な問題を見逃さない
Amp ドキュメント & PM専門レビュアー README等の欠如を詳細指摘（12件）。完成度評価に優れる
Droid 最終関門（エンタープライズ基準） 最も厳格な"patch is incorrect"判定。本番品質の守護者
Qwen 初期品質レビュアー コード品質の迅速評価。保守性の観点が優れる
Claude 統合レビュアー（包括的） 8カテゴリー評価、工数見積もり。全体統合に最適
Codex 問題解決 & システムレビュアー メタレビュー実施。プロセス改善の視点
Multi-AI 並列統合レビュー 3種のレビューを統合。時間短縮と多角的評価

7.3 プロジェクトタイプ別の推奨構成

実験５のデータを基に、プロジェクトタイプ別の推奨構成を提案：

スタートアップMVP（速度重視）

推奨構成: Qwen（品質）+ Claude（包括的）

  • 理由: 高速レビュー、バランスが良い
  • 省略: セキュリティ詳細レビュー（初期MVPでは優先度低）
  • コスト: 約230秒（低コスト）

エンタープライズシステム（品質重視）

推奨構成: Droid（エンタープライズ）+ Gemini（セキュリティ）+ Amp（ドキュメント）+ Claude（統合）

  • 理由: 最高品質、見逃しが最小限
  • 省略: なし（全観点カバー）
  • コスト: 約530秒（高コスト）

セキュリティクリティカル（セキュリティ重視）

推奨構成: Gemini（セキュリティ）+ Droid（エンタープライズ）+ Multi-AI（統合）

  • 理由: セキュリティの深掘り、厳格な品質基準
  • 省略: ドキュメントレビュー（セキュリティ優先）
  • コスト: 約560秒（高コスト）

8. 実験の洞察と今後の課題

8.1 実験５で確認できたこと

確認できた事実:

  1. 専門性の深さ: 専門領域に特化すると、非常に深い分析ができる
  2. 役割分担の有効性: 専門家チームは、包括的レビュー1つより見逃しが少ない
  3. 重大問題の合意: 異なる専門領域でも、重大問題（Pomodoroタイマー未実装）は全員が指摘
  4. 包括的レビューの価値: Claudeの包括的レビューは、全体統合に必須
  5. 人間チームとの類似性: AIレビューも、人間チーム開発の原則が適用できる

実証された価値:

  • 専門家による役割分担レビューの有効性（実験５で実証）
  • 各AIの専門性の深さ（Geminiのセキュリティ、Ampのドキュメント）
  • 適材適所の重要性（プロジェクトタイプ別の推奨構成）

8.2 実験の限界と今後の課題

限界1: 専門領域の割り当て

今回の専門領域の割り当ては、実験１〜４の観察に基づく主観的な判断です：

  • Geminiが「本当に」セキュリティ専門なのか？
  • Ampが「本当に」ドキュメント専門なのか？
  • より多くの実験で検証が必要

限界2: サンプルサイズ不足

レビュー対象はCursorの1実装のみ：

  • 他の実装（Claude, Gemini, Qwen等）でも同じ結果になるか？
  • より多様なコードベースでの検証が必要
  • 異なるドメイン（Web API、CLI等）での実験が必要

限界3: 最適な役割組み合わせの未検証

今回は「各AIに1つの専門領域」を割り当てましたが：

  • 最適な組み合わせは何か？（例: Droid + Gemini + Claude）
  • 組み合わせによる相乗効果はあるか？
  • プロジェクトタイプごとの最適解は？

これらは実験７（役割分担最適化実験）で検証すべき課題です。

8.3 次のステップ

実験５を踏まえた、今後の実験計画：

Phase 3A: 他の実装に対する同様の実験

  • Claude/Gemini/Qwen等の実装を専門家チームでレビュー
  • サンプルサイズを増やして結論の信頼性を向上

Phase 3B: 実験７（役割分担最適化実験）

  • 異なる役割組み合わせで同じタスクを実施
  • パターンA: Droid設計 → Qwen実装 → Geminiレビュー
  • パターンB: Claude設計 → Cursor実装 → Droidレビュー
  • 最適な組み合わせを特定

Phase 3C: 専門領域の再定義

  • より多くの専門タスク（実験６）で各AIの真の専門性を特定
  • 主観的な割り当てではなく、データに基づく専門領域の定義

9. 正直な感想と反省

9.1 実験設計について

実験５の設計で、最も重要だったのは専門領域を明確に割り当てたことです。

うまくいった点:

  • 各AIに異なる専門領域を依頼
  • Claudeだけに包括的レビューを依頼（比較対象）
  • 独立した並列実行で相互影響を排除

まだ改善の余地がある点:

  • 専門領域の割り当てが主観的
  • 最適な組み合わせの検証が未完了
  • より多くのサンプルでの検証が必要

9.2 発見の解釈について

実験５で最も驚いたのは、Geminiの専門性の深さでした：

「Prototype Pollution脆弱性を唯一発見」

これは、専門領域に特化することで、AIの能力が最大限に発揮されることを示しています。

一方で、重要な学びもありました：

「Ampがドキュメント不足を指摘したのは、Ampに依頼したから」

これは当たり前のことですが、最初の分析では見落としていました。ユーザーの指摘により、実験設計の本質を正しく理解できました。

9.3 人間チーム開発との類似性

実験５を通じて、最も重要な気づきは：

「AIレビューも、人間チーム開発と同じ原則が適用できる」

人間の世界では、誰も「1人の完璧なレビュアー」を探しません。それぞれの専門家が、それぞれの視点でレビューします。

AIの世界も同じであるべきです。「最強のレビューAI」を探すのではなく、「専門家チームを編成する」のが正解なのだと思います。

9.4 謙虚な姿勢を忘れずに

実験５でも、完璧な結論は得られていません：

  • 専門領域の割り当ては主観的
  • サンプルサイズが小さい
  • 最適な組み合わせは未検証

しかし、不完全ながらも正直に共有することで、誰かの役に立てればと考えています。

特に、ユーザーの鋭い指摘により、実験設計の本質を見直すことができました。このようなフィードバックが、実験の質を向上させると信じています。

10. まとめ - 実験５から学んだこと

主要な発見

実験設計の本質:

  • 各AIに意図的に専門領域を割り当てた
  • 「自然な評価基準の違い」ではなく「役割分担の検証」が目的

専門性の深さ:

  • Gemini: Prototype Pollution発見（セキュリティ専門家として）
  • Amp: ドキュメント問題を12件詳細指摘（ドキュメント専門家として）
  • Droid: 最も厳格な"patch is incorrect"判定（エンタープライズ専門家として）

役割分担の有効性:

  • 専門家チームは、包括的レビュー1つより見逃しが少ない
  • 重大問題（Pomodoroタイマー）は、どの専門家も指摘（57%が一致）
  • 人間チーム開発の原則が、AIレビューにも適用できる

実務への応用

検証済みの推奨戦略:

  • 高速チェック: Qwen単体（5-10分）
  • 標準レビュー: Claude + Amp（15-20分）
  • 本番前チェック: Droid + Gemini（30-40分）
  • 最大品質保証: 全7AI並列（60分+）

役割分担の最適化（実験５実証済み）:

  • Gemini: セキュリティ専門レビュアー（高度な問題を発見）
  • Amp: ドキュメント & PM専門レビュアー（完成度評価に優れる）
  • Droid: 最終関門（エンタープライズ基準、最も厳格）
  • Claude: 統合レビュアー（包括的、全体統合に最適）

今後の展望

  1. サンプルサイズの拡大: より多くの実装での専門家レビュー
  2. 役割分担の最適化: 実験７での組み合わせ検証
  3. 専門領域の再定義: 実験６での真の専門性の特定
  4. 統合ダッシュボード: 全実験結果の可視化

正直な感想

実験５では、これまでの実験で見えなかった「専門家による役割分担の有効性」が実証されました。

特に重要だったのは、ユーザーの指摘により、実験設計の本質を見直せたことです：

「各AIに専門領域を割り当てたのは、意図的な実験設計」

この理解により、正しい解釈ができました。

不完全ながらも、正直に共有することで、コミュニティ全体の知見を深められればと思います。

リポジトリ

https://github.com/CaCC-Lab/pomodoro-todo

https://github.com/CaCC-Lab/multi-ai-orchestrium

Discussion