GPT-5 miniは計画屋、Grokは実装屋：フルスタック開発で学んだAI使い分けの現実

ポッドキャスト

📌 1分で分かる記事要約

• GPT-5 miniは「計画屋」：要件書からアーキテクチャ、タスク定義書まで30分で完璧に生成できるが、複雑なフルスタック統合では実行時エラーが多発する
• Grokは「実装屋」：実装コード生成と実行時エラー修正に強く、質問なしで一気実装が可能で生産性が高い
• 「美しい設計書≠動作保証」：FastAPI+React+SQLiteの完璧な計画も、CORS・DB権限・ポート競合などの統合エラーで起動失敗する典型パターン
• TDD（テスト駆動開発）が解決策：RED→GREEN→REFACTORサイクルでテストファーストに進めることで、実行時エラーを事前に排除できる
• Next.js+TDD移行で成功確率90%超へ：単一パッケージ統合とテスト駆動により、CORS・DB権限問題が解消され、一発起動が実現する

📝 結論

AI開発ツールに「万能」は存在しない。タスク特性で使い分けることが重要だ。計画立案はGPT-5 miniで徹底的に詰め、実装はGrokで一気実行し、テスト駆動開発で品質を保証する——このハイブリッドアプローチが、フルスタック開発の現実的なベストプラクティスである。

メモ帳アプリ開発で直面した「計画と実行のギャップ」

フルスタックメモ帳アプリを構築する企画をスタートさせた。要件定義書から実装まで、複数のAIツールを試した結果、驚くべき現実が浮かび上がった。

最初の選択肢はGPT-5 miniだった。軽量で高速、低コストという触れ込みが魅力的だった。実際に試してみると、AIツールの得意・不得意が明確に分かれることになる。

GPT-5 miniの強み：完璧な「計画屋」

GPT-5 miniに最初に与えた指示は、シンプルだった。

「メモ帳作る。まずは要件書作成から」

結果は驚くほど詳細で実用的だった。わずか30分で、3段階の成果物が完成した：

1. 要件定義書：MVPスコープ、ユーザーストーリー、機能要件、非機能要件、技術スタック、DBスキーマ、APIエンドポイント、UI画面設計、工数見積まで網羅
2. 技術選定とアーキテクチャ設計：FastAPI+React+SQLite+Tailwindの採用理由、ディレクトリ構成、開発ワークフロー、セキュリティ対策まで明記
3. タスク一覧：要件定義書作成からデプロイまで10のハイレベルタスクを体系化

このドキュメント群は、本当に優秀だった。フレームワークの選定理由が明確で、拡張性が高く、リスク分析も網羅されていた。

ここまでの段階では、miniは完璧な「計画屋」として機能していた。

実装フェーズで露呈した致命的な弱点

しかし問題は、実装フェーズで顕在化した。

タスク一覧に従い、FastAPI+React+SQLiteのプロジェクト雛形をminiに生成させ、テスト実装まで進めた。30分でタスク実行とテスト実装まで到達した——一見、素晴らしい進捗に見えた。

だが、いざアプリケーションを起動しようとすると、起動に失敗した。

エラーの原因は複雑だった。複数レイヤーの依存関係が絡み合っていた：

• CORSエラー：フロントエンド（localhost:3000）からバックエンド（localhost:8000）へのAPIリクエストがブロックされた
• SQLite権限問題：OperationalError: unable to open database fileでDB初期化に失敗
• ポート競合：既存プロセスが占有していた
• Dockerボリューム設定：DBファイルが永続化されない

これらの問題は、すべて「実装段階の統合エラー」だった。ドキュメントには対策が書かれていたが、実装コードには反映されていなかったのだ。

なぜ「完璧な計画」が「動かないコード」を生むのか

ここで重要な洞察が得られた。

miniは高速応答と定型タスク処理に最適化されている。複雑なフルスタック統合では、複数の依存関係を同時に管理する能力に限界がある。

具体的には：

• 複雑な推論が必要な統合テストに弱い
• 実行時エラーの早期検知が不足している
• エラー修正の反復サイクルで時間を消費する
• 質問を繰り返す設計がユーザーの時間を奪う

miniは「次に何をすべきか」を聞く傾向がある。これは計画段階では有効だが、実装段階では時間浪費になってしまう。

Grokへの転換：「質問なし一気実装」の威力

ここで方針を転換した。Grokを試してみた。

Grokの特徴は、miniと正反対だった。

• 質問なし一気実装：「このコードを生成してくれ」という指示に対し、すぐに動作コードを返す
• 実行時エラー修正に強い：統合エラーを検知し、修正提案を含める
• 生産性重視：時間制約下での開発に最適

ユーザーの結論は明確だった：「Grokの勝ち」。

失敗パターンの本質：テスト駆動開発の欠落

しかし、ここで別の気づきが生まれた。

miniの失敗の根本原因は、テスト駆動開発（TDD）の欠落だった。

miniが生成したコードは、テストなしで実装されていた。つまり：

• 実装前にテストを書かない（RED フェーズなし）
• 実装後のテストが形骸化している
• 統合テストで初めてエラーが浮かぶ

これは、典型的なウォーターフォール開発の失敗パターンだ。

TDD導入による転機：Next.js + vitest + Playwright

そこで、要件を大幅に修正した。

Next.js + TDD + E2Eテストの組み合わせで、再度プロジェクトを立ち上げることにした。

TDDのサイクルは、以下の通りだ：

1. RED：テストコードを先に書き、意図的に失敗させる
2. GREEN：最小限の実装でテストを通す
3. REFACTOR：クリーンコード化し、重複を排除

このサイクルをすべてのタスクで繰り返す。

具体的には、以下のようなタスク分解になった：

タスク1：メモCRUD（TDD）

• RED：test('メモ追加で配列長+1')を書く→失敗
• GREEN：useStateでメモ配列を管理→成功
• RED：test('メモ削除で配列長-1')を書く→失敗
• GREEN：deleteNote()実装→成功

タスク2：Markdownエディタ（TDD）

• RED：test('#見出し → <h1>レンダリング')を書く→失敗
• GREEN：react-markdownを統合→成功

タスク3：永続化（TDD）

• RED：test('リロード後メモ保持')を書く→失敗
• GREEN：localStorageを実装→成功

タスク4：E2Eテスト（Playwright）

• 一覧→作成→編集→削除の全フロー検証

なぜTDDが「起動失敗ゼロ」を実現するのか

TDDを導入することで、何が変わったのか。

テストが「品質保証」から「設計ツール」へ昇華したのだ。

従来のアプローチ：実装→テスト（後付け）→エラー発見→修正

TDDアプローチ：テスト（先行）→実装（最小限）→リファクタ→統合テスト

TDDの利点は：

1. エラーの早期発見：実装前に失敗ケースを定義するため、エラーが実装段階で浮かぶ
2. 実装の明確化：テストが「何をすべきか」を定義するため、ぶれない実装になる
3. 統合エラーの削減：各ユニットがテストで保証されているため、統合時のエラーが激減
4. リファクタの安全性：テストが「品質の番人」として機能するため、大胆なリファクタが可能

結果として、docker-compose upで一発起動が実現するのだ。

Next.js選択による統合の簡潔化

同時に、フレームワークをFastAPI+ReactからNext.jsへ移行した。

これも重要なポイントだ。

FastAPI+Reactの構成では：

• バックエンド（Python）とフロント（Node.js）が別プロセス
• CORS設定が必要
• ポート管理が複雑
• Docker-composeで複数サービスを管理

Next.jsでは：

• 単一のNode.jsプロセスでバック・フロントを統合
• CORS問題が発生しない
• ポート管理が単純（3000のみ）
• npm run devで即起動

単一パッケージ統合により、統合エラーのリスクが激減した。

プロンプト精度の重要性：曖昧さがエラーを招く

ここで、もう一つの重要な学習が得られた。

AIの出力品質は、プロンプト品質に直結する。

最初のプロンプト：「メモ帳作る。まずは要件書作成から」

これは曖昧だった。miniは「完璧な要件書」を生成したが、実装段階では「何をすべきか」が不明確になった。

改善されたプロンプト：

「Next.js 15 + TDD(vitest) + E2E(Playwright) + drizzle(SQLite) + Tailwindのメモ帳アプリを生成。
1. vitestでメモCRUDテストを先に記述
2. テスト通してから実装コード生成
3. docker-compose upで即起動確認
4. Markdownエディタ+FTS検索+タグ管理+JSONエクスポート完備
5. エラーログ出力機能必須」

具体性が増すと、AIの出力精度が劇的に向上する。

時間効率の問題：質問ループの落とし穴

開発を進める中で、別の問題に直面した。

miniは「関連質問」を繰り返す傾向がある：

• 「この要件で追加したい機能はありますか？」
• 「過去にこのフレームワークを使った経験があれば、どんなTipsがありますか？」

これらの質問は、ユーザーの時間を消費する。

時間制約がある開発環境では、質問なしで一気実装することが重要だ。

Grokは「質問なし一気実装」を実現する。これが、Grokが実装フェーズで優位に立つ理由だ。

ハイブリッド活用のベストプラクティス

ここまでの経験から、AIツール選定の最適戦略が見えてきた。

フェーズ1：計画立案（GPT-5 mini推奨）

• 要件定義書の作成
• アーキテクチャ設計
• タスク分解

miniの「完璧な計画屋」としての能力を最大限活用する。ここで徹底的に詰めることで、後続フェーズのエラーを削減できる。

フェーズ2：実装・テスト（Grok推奨）

• TDD（RED→GREEN→REFACTOR）の厳密な実行
• 一気実装で生産性向上
• 実行時エラーの即座の修正

Grokの「質問なし一気実装」能力が活躍する。テスト駆動開発により、品質も保証される。

フェーズ3：統合・デプロイ

• E2Eテストによる全フロー検証
• Docker一発起動の確認
• ドキュメント整備

ここでもテストが「品質の番人」として機能する。

他プロジェクトへの転用ガイド

この経験は、他のプロジェクトにも応用できる。

新しいプロジェクトを開始するときのチェックリスト：

1. 計画フェーズ

   • 要件定義書をminiで生成
   • アーキテクチャ設計を徹底的に詰める
   • TDD対応のタスク分解を作成

2. 実装フェーズ

   • テストコード優先（RED）
   • Grokで一気実装（GREEN）
   • リファクタで品質向上（REFACTOR）

3. 統合フェーズ

   • E2Eテスト（Playwright）で全フロー検証
   • Docker一発起動の確認
   • エラーログ出力機能の実装

4. 品質保証

   • 単体テスト100%通過
   • E2Eテスト100%通過
   • パフォーマンステスト実施

実装例：TDD的なタスク定義書の正しい形

参考までに、TDD対応のタスク定義書の正しい形を示す：

# TDDメモ帳アプリ - 全タスク一気実行（90分完了）

## 1. TDD: メモCRUD（25分）
- RED: test('メモ追加で配列長+1')を書く → 失敗
- GREEN: useState<Note[]>([]) + addNote()実装 → 成功
- REFACTOR: useCallback化でパフォーマンス最適化

- RED: test('メモ削除で配列長-1')を書く → 失敗
- GREEN: deleteNote(id)実装 → 成功
- REFACTOR: 複合フィルタ対応

## 2. TDD: Markdownエディタ（15分）
- RED: test('#見出し → <h1>レンダリング')を書く → 失敗
- GREEN: react-markdown統合 → 成功
- REFACTOR: 左右分割 + ライブプレビュー

## 3. E2E統合テスト（10分）
- Playwrightで一覧→作成→編集→削除フロー検証

重要なポイント：

• 各タスクで「RED→GREEN→REFACTOR」を明示
• テストが「何をすべきか」を定義
• 実装は「テスト通すための最小限」に限定

まとめ：AIツール選定の現実的な結論

この開発経験から、以下の結論が導き出される：

AIツールに「万能」は存在しない。タスク特性で使い分けることが重要だ。

• GPT-5 miniは「計画屋」：ドキュメント生成、アーキテクチャ設計で優秀。計画フェーズで徹底的に活用すべき。
• Grokは「実装屋」：一気実装、エラー修正で優秀。実装フェーズで活用すべき。
• TDDが「品質保証」：テスト駆動開発により、統合エラーを事前に排除。起動失敗ゼロを実現。
• Next.jsが「統合簡潔化」：単一パッケージ統合により、CORS・DB権限問題が解消。一発起動を実現。

このハイブリッドアプローチが、フルスタック開発の現実的なベストプラクティスである。

次のステップ

この知見を活かして、次のプロジェクトに取り組む際は：

1. 計画フェーズはminiで徹底的に詰める
2. 実装フェーズはGrokで一気実装
3. TDDで品質を保証する
4. Next.jsで統合を簡潔にする

このフローで、高品質で実装効率の高いフルスタック開発が実現する。