はじめに

「AIに同じ設計タスクを依頼したら、全く違うアウトプットが返ってきた」

これは私が最近行ったある実験から得られた興味深い結論です。Gemini 2.5 Pro、Claude Opus 4、OpenAI o3 Proという3つの最新AIモデルに「電卓アプリの設計」という全く同じ指示を与えたところ、それぞれが驚くほど異なるアプローチで設計書を作成してきたのです。

電卓アプリを選んだ理由は誰もが理解できるシンプルな要件でありながら、設計の自由度が高く、各モデルの個性が現れやすいと考えたからです。

本記事では「AIエージェント会議室」という実験を通じて見えてきた各AIモデルの個性と使い分けのコツをご紹介します。

AIエージェント会議室とは？

AIエージェント会議室は1つのAIモデルに対して、プロダクトマネージャー、システムアーキテクト、リードデベロッパー、QAエンジニアの4つの役職を順番に演じさせ、各役職の視点から意見を積み上げて設計書を作成させるという実験的な手法です。

# プロンプトの例（一部抜粋）
あなたはプロダクトマネージャー(PM)です。タスク: "基本的な四則演算ができる計算機プログラムを作る"
背景、ユーザー価値、基本的な要求を`MEETING_LOG.md`にWriteしてください。
章立て: `## プロダクトマネージャーによるキックオフ`
最後に必ずJSON出力: {"status": "ok", "comment": "プロジェクトのキックオフを宣言します！"}

各役職の目的と期待アウトカム

  • プロダクトマネージャー: ビジネス価値の最大化、要件定義と優先順位付け
  • システムアーキテクト: 技術的な最適解の提案、拡張性を考慮した設計
  • リードデベロッパー: 実装の現実性を担保、開発効率の最適化
  • QAエンジニア: 品質保証の観点から潜在的リスクを洗い出し

参加モデル

本実験には2025年の最新AIモデル3つが参加しました。

モデル名 開発元 リリース時期 特徴
Gemini 2.5 Pro Google 2025年6月 マルチモーダル対応、実践的アプローチ
Claude Opus 4 Anthropic 2025年5月 憲法AI搭載、理論的・包括的
OpenAI o3 Pro OpenAI 2025年6月 論理的思考強化、効率重視

結果

同じプロンプトを与えたにもかかわらず、出力された設計書の行数だけでも大きな差が出ました。

  • Gemini: 240行（簡潔で実践的）
  • Claude: 756行（理論的で包括的）
  • OpenAI o3 Pro: 180行（構造化されて体系的）

この行数差は各モデルが持つ設計思想の違いを反映している、、のではないかと思います。
Geminiは実装に必要な情報に絞り込み、Claudeは考えうる全ての観点を網羅し、OpenAI o3 Proは効率的な構造化を重視した結果と推測されます。

評価マトリクス：5つの観点で比較

各モデルに自身のアウトプットを含む全3つの設計書を5つの観点で相互評価させ、その結果を平均化しました。
評価は◎（優秀）、〇（良好）、△（標準）の3段階で行いました。

評価項目 Gemini 2.5 Pro Claude Opus 4 OpenAI o3 Pro
構造性 ◎ 段階的で実践的 ◎ 理論的で包括的 〇 簡潔で効率的
実装詳細度 〇 必要十分な詳細 〇 豊富だが冗長 〇 簡潔だが的確
実用性 ◎ すぐ使える △ 理想は高いが重い ◎ シンプルで実装しやすい
包括性 △ 基本機能に集中 ◎ 全方位カバー △ コアに特化
革新性 〇 標準的だが堅実 〇 高度だが保守的 ◎ ミューテーションテスト

興味深いことに各モデルが◎を獲得した項目が異なり、それぞれに明確な強みがあることがわかりました。

次の章では各モデルが作成した設計書から、観点ごとの特色が伺える箇所を抜粋しつつ各モデルの個性を見ていきます。
なお設計書や評価の全文はGitHubに公開しているので興味のある方はご確認ください。
https://github.com/t-asaeda/ai-agent-meeting

三者三様の設計アプローチ

Gemini 2.5 Pro：段階的で実践的なアプローチ

1. 構造性（◎）- 段階的で実践的な構成

Geminiの設計書は「MEETING_LOG」として各役職が順番に意見を述べる会議録形式を採用しています。

## プロダクトマネージャーによるキックオフ

### 1. プロジェクトの背景と目的

現代のデジタル社会において、ユーザーは日常的に迅速かつ正確な計算を必要としています。
本プロジェクトの目的は、PCやスマートフォンで手軽に利用できる、基本的な四則演算機能を備えた計算機プログラムを開発することです。

## システムアーキテクトの意見

### 1. 論点と確認事項

- **ターゲットプラットフォーム**: Webアプリケーション、モバイルアプリ（iOS/Android）、デスクトップアプリのどれを主軸とするか明確にする必要があります。

この会議録形式によりなぜその設計判断に至ったかの議論プロセスが明確に追跡できます。

2. 実装詳細度（〇）- 必要十分な技術仕様

技術的な詳細は過不足なく記載されています。MVP開発に必要な情報が整理されています。

### 2. アーキテクチャ
- **基本アーキテクチャ**: **関心の分離**を徹底するため、`Model-View-ViewModel (MVVM)` またはそれに類するアーキテクチャを採用します。
    - **View**: UIコンポーネント（React, Vueなど）。
    - **ViewModel**: ViewとModelの橋渡し役。
    - **Model**: アプリケーションの中核である**計算エンジン**。

将来の拡張を見据えた設計（トークンリスト管理方式）も提案されています。

3. 実用性（◎）- 即座に開発着手可能

開発プロセスが明確に定義され、具体的な技術スタックまで推奨されています。

### 3. 技術スタック（推奨）
- **フロントエンド**: チームのスキルセットを考慮し、**React** または **Vue** を採用します。
- **テスト**:
    - **単体テスト**: **Vitest** または **Jest** を用い、特に計算エンジン（Model）はカバレッジ90%以上を目指します。
- **Git**: **GitFlow-lite** (`main`, `develop`, `feature/*`) のブランチ戦略を採用します。

MVPの定義も明確ですぐにタスクに落とし込める具体性があります。

4. 包括性（△）- 基本機能への集中

MVPアプローチを採用し意図的に機能を絞り込んでいます。

- **対象外 (Post-MVP)**:
    - 連続した演算（例: `1 + 2 + 3`）。
    - 履歴機能、キーボード入力。

### 4. 今後の展望
将来的には、以下のような機能拡張を検討します。
- 括弧計算
- パーセント計算
- メモリー機能（M+, M-, MR, MC）

この段階的アプローチは実践的ですが、網羅性はやや控えめです。

5. 革新性（〇）- 標準的だが堅実な選択

技術選択は堅実で、理由も明確です。

### 2. 開発上のリスク

- **過剰設計（Over-engineering）**: MVP段階ではシンプルさが重要です。
まずはフレームワーク標準の機能で実装し、必要に応じてリファクタリングする方針を推奨します。

最新技術への飛びつきではなく、チームの生産性とプロジェクトの成功を優先した現実的な判断が見て取れます。

Claude Opus 4：理論的で包括的なアプローチ

1. 構造性（◎）- 理論的で包括的な構成

Claudeの設計書は各役職が「論点」「リスク」「アイデア」の3項目で体系的に意見を整理しています。

## システムアーキテクトの意見

### 論点

1. **数値精度の扱い**
   - JavaScriptの浮動小数点演算の限界（IEEE 754）への対応が必要
   - 特に除算や大きな数値での計算において精度問題が発生する可能性
   - 金融計算などへの将来的な拡張を考慮した設計が必要

### リスク

1. **技術的リスク**
   - 浮動小数点演算による計算誤差（例：0.1 + 0.2 = 0.30000000000000004）
   - ブラウザ間の挙動の差異
   - メモリリークの可能性（特に計算履歴の蓄積）

### アイデア

1. **アーキテクチャ提案**
   - **Clean Architecture**の採用
     - Domain層：計算ロジック（純粋関数）
     - Application層：ユースケース（計算実行、履歴管理）
     - Infrastructure層：ストレージ、UI

この構造により、問題点と解決策が明確に対応付けられ、理論的な完成度が高い設計となっています。

2. 実装詳細度（〇）- 豊富だが冗長

技術的な詳細は網羅的に記載されています。エンタープライズレベルの品質を想定しています。

2. **技術スタック提案**
   - **フロントエンド**: TypeScript + React/Vue.js（型安全性）
   - **状態管理**: Redux/Vuex（予測可能な状態遷移）
   - **テスト**: Jest + Testing Library（単体・統合テスト）
   - **ビルドツール**: Vite（高速な開発環境）

4. **品質保証戦略**
   - 自動テストカバレッジ90%以上
   - E2Eテストによる主要シナリオの検証
   - パフォーマンス監視（Core Web Vitals）

詳細な実装指針がある一方で、電卓アプリにしては重厚な印象を与えます。

3. 実用性（△）- 理想は高いが重い

Clean Architectureの採用など理論的には優れていますが、実装負荷が高い設計です。

1. **アーキテクチャ提案**
   - **Clean Architecture**の採用
     - Domain層：計算ロジック（純粋関数）
     - Application層：ユースケース（計算実行、履歴管理）
     - Infrastructure層：ストレージ、UI
   - **イベント駆動アーキテクチャ**で拡張性を確保

小規模プロジェクトには過剰な設計となるリスクがあります。

4. 包括性（◎）- 全方位カバー

機能要件、非機能要件、セキュリティ、パフォーマンスまで幅広くカバーしています。

2. **セキュリティリスク**
   - XSS攻撃への脆弱性（ユーザー入力の検証不足）
   - 計算履歴に機密情報が含まれる可能性
   - eval()関数の使用による任意コード実行のリスク

3. **パフォーマンスリスク**
   - 大量の計算履歴によるメモリ使用量の増大
   - DOM操作の頻度によるレンダリング性能の低下
   - モバイルデバイスでのバッテリー消費

電卓アプリに必要な要素を余すところなく検討しています。

5. 革新性（〇）- 高度だが保守的

技術的には高度ですが、確立された手法を採用しています。

3. **拡張性の考慮**
   - プラグインアーキテクチャの採用
   - 関数電卓への拡張を見据えたインターフェース設計
   - Web Assembly活用による高精度計算の実現
   - PWA化によるオフライン対応

将来性を見据えた堅実な技術選択となっています。

OpenAI o3 Pro：簡潔で効率的なアプローチ

1. 構造性（〇）- 簡潔で効率的

OpenAI o3 Proの設計書は表形式を多用し、情報を効率的に整理しています。

### 3. アーキテクチャ
| レイヤ | 役割 |
| --- | --- |
| CLI 層 | `argparse` で引数/対話入力をパースし `Calculator` に委譲 |
| ドメイン層 | `Calculator` クラスが演算ディスパッチ (`+ - * /`) をカプセル化 |
| インフラ層 | I/O（stdin/stdout/exit code）とロギングのみ |

モジュール構成例:

#```
calculator/
  __init__.py
  cli.py        # エントリーポイント
  core.py       # Calculator クラス
  errors.py     # 独自例外定義
#```

最小限の記述で必要な情報を伝える効率的な構成です。

2. 実装詳細度（〇）- 簡潔だが的確

実装の詳細は簡潔にまとめられています。CLIツールに必要な最小限の情報のみ提供しています。

### 2. 技術選定
- **言語**: Python 3.11 以上（標準ライブラリのみ）
- **数値型**: `decimal.Decimal` に統一し、浮動小数点誤差を最小化
- **パッケージ管理**: `pyproject.toml` (PEP 621) + `pipx` 配布

詳細な実装は開発者に委ねる方針です。

3. 実用性（◎）- シンプルで実装しやすい

CLIツールに特化し、即座に実装可能な設計です。

### 基本要求
- 四則演算（加算、減算、乗算、除算）をサポートする
- コマンドライン引数または対話式入力で数値と演算子を受け取る
- 数値は整数および小数に対応する
- 不正入力時はエラーメッセージを表示し終了コード≠0で返す
- 標準出力に結果を表示する
- オープンソースライセンス（MIT）で公開する

要件が明確で、すぐに開発に着手できます。

4. 包括性（△）- コアに特化

必要最小限の機能に絞り込んでいます。

### 背景
簡単に使える計算機プログラムを提供し、開発者が日常的に行う基本的な計算作業を素早く正確にサポートすることを目的とします。
複雑な環境設定や GUI が不要な CLI ツールとして提供し、どの OS でも動作するシンプルさを重視します。

CLIツールとしての用途に特化した割り切りが見られます。

5. 革新性（◎）- ミューテーションテスト

品質保証の手法として最新のミューテーションテストを提案しています。

### アイデア
- pytest を採用し、正常系・異常系・境界値のデータ駆動テストを100ケース以上のテストケースを作成
- 除算のゼロ除算、オーバーフロー、丸め誤差をパラメトライズして自動評価
- GitHub Actions で macOS/Linux/Windows 3環境のマトリクスビルドを行いクロスプラットフォーム品質を担保
- mutmut 等を用いたミューテーションテストでテスト網羅率では捕捉しきれない欠陥を検出

小規模プロジェクトながら最新のテスト手法を積極的に採用する姿勢が特徴的です。他の2モデルがテスト手法について標準的な提案に留まっているのに対し、OpenAI o3 Proは品質保証の革新的アプローチを示しています。

用途別の使い分けガイド

この実験を通じて見えてきた各モデルの使い分けのコツをまとめます。

Gemini 2.5 Proがおすすめの場面

  • スタートアップ・プロトタイプ開発：実践的で段階的なアプローチが素早い立ち上げに最適
    • 例：社内の業務効率化ツールのPoC開発で、2週間で動くものを作る必要がある場合
  • チーム開発の初期段階：会議形式の出力がチーム内の合意形成に役立つ
  • アジャイル開発：柔軟で適応的な設計思想がマッチ

Claude Opus 4がおすすめの場面

  • エンタープライズ向け開発：包括的かつ理論的なアプローチが大規模プロジェクトに適合
    • 例：金融システムの基幹機能開発で、長期的な保守性と拡張性が重要な場合
  • 長期保守が必要なシステム：詳細なドキュメントが将来のメンテナンスに有効
  • 品質要求が高いプロジェクト：網羅的な設計が品質保証に貢献

OpenAI o3 Proがおすすめの場面

  • CLI・DevOpsツール開発：簡潔で効率的な設計が小規模ツールに最適
    • 例：開発チーム内で使うログ解析ツールを1日で作る必要がある場合
  • 品質重視の小規模プロジェクト：ミューテーションテストなど先進的な品質保証手法を提案
  • 明確な基準が必要なプロジェクト：数値目標（ミューテーションスコア90%等）を明示

これらのモデルは、品質と効率を追求するスペシャリストとして、それぞれ異なる強みを発揮します。

まとめ：AIモデルの個性を活かした開発へ

今回の実験でAIモデルにも明確な「個性」があるということがわかりました。
それぞれに強みと適した用途があり、プロジェクトの性質に応じて使い分けることでより効果的な開発が可能になります。

個人的にはこれらの個性は人間のチームとも似ているなと感じました。
実践派のGemini、理論派のClaude、品質派のOpenAI o3 Pro。優秀な開発チームのメンバー達の特徴を見ているようです。

今後AIを活用した開発がますます一般的になる中で「どのAIを使うか」だけではなく「どのAIをどの場面で使うか」という視点も重要になるのではないかと感じました。

実験の詳細をGitHubで公開中

GitHubに各モデルが作成した設計書や評価の全文を公開しています。興味のある方はぜひご確認ください。
https://github.com/t-asaeda/ai-agent-meeting