アンチパターン③「一括依頼」

「全部作って」の誘惑

vibe codingの最も魅力的な点は、大きなものを一度に作れる ように見えることです。

「ログイン機能、ダッシュボード、設定画面、プロフィール編集、すべて作って」

このような「一括依頼」は、時間を節約できるように見えます。しかし、実際には 最も効率が悪い アプローチです。

一括依頼の問題

なぜ、一括依頼は問題なのでしょうか。

問題1: コンテキストの限界

AIのコンテキストウィンドウには限界があります。大きなリクエストは、コンテキストを圧迫し、後半の品質が低下します。

問題2: エラーの特定困難

大量のコードが一度に生成されると、問題が発生したときにどこが原因か特定困難です。

問題3: フィードバックループの欠如

一括で作ると、途中で方向修正ができません。最後まで作ってから「違った」となると、全部やり直しです。

問題4: 品質の不均一

AIは最初の部分に集中し、後半は手薄になりがちです。一括依頼するほど、品質のばらつきが大きくなります。

AI開発の「分割統治」の原則

ソフトウェア工学には、「分割統治（Divide and Conquer）」という原則があります。

原則:

大きな問題を小さな問題に分割し、個別に解決する

これはAIコーディングにも当てはまります。

悪い例:

「ECサイトを作って」

良い例:

1.「商品一覧ページのUIを作って」
2.「商品詳細ページのUIを作って」
3.「カート機能を追加して」
4.「決済処理を実装して」
...

小さな単位で依頼し、確認し、次に進む。これが正しいアプローチです。

適切な粒度

では、どの程度の粒度が適切でしょうか。

粒度の目安:

粒度	適切さ	理由
1行	△	効率が悪すぎる
1関数	◎	レビュー可能、テスト可能
1ファイル	○	状況による
1機能	△	大きすぎる場合が多い
複数機能	✕	一括依頼の罠

目安:

生成されるコードが 100行以下 になるような単位
一目で 全体を把握できる 単位
独立してテストできる 単位

AI開発の反復的アプローチ

一括依頼ではなく、反復的アプローチ を取りましょう。

反復的アプローチ:

Step 1: 小さな単位を依頼
Step 2: 生成されたコードをレビュー
Step 3: 動作を確認
Step 4: 問題があれば修正を依頼
Step 5: 次の小さな単位を依頼
(繰り返し)

このアプローチには、以下のメリットがあります。

メリット:

早期の問題発見
- 各ステップで問題を発見できる
方向修正が容易
- 途中で要件が変わっても対応可能
学習の機会
- 各ステップでAIの出力を理解
品質の均一化
- すべての部分に同等の注意を払える

一括依頼が許される場面

一括依頼が許される場面もあります。

許される場面:

プロトタイプ
- どうせ捨てる前提
- アイデアの検証が目的
ボイラープレート
- 定型的なコード
- セキュリティリスクが低い
独立したユーティリティ
- 他のコードと依存関係がない
- 単独でテスト可能

許されない場面:

本番コード
セキュリティ関連
他のコードと密結合
ビジネスロジック

AI開発プロンプトの分割方法

大きなタスクを小さなプロンプトに分割する方法を紹介します。

方法1: 機能別分割

全体: 「ユーザー管理機能を作って」
↓
分割:
1. 「ユーザーモデルを定義して」
2. 「ユーザー登録APIを作って」
3. 「ログインAPIを作って」
4. 「プロフィール更新APIを作って」

方法2: レイヤー別分割

全体: 「商品詳細ページを作って」
↓
分割:
1. 「商品詳細のデータモデルを定義して」
2. 「商品取得のAPIを作って」
3. 「商品詳細のUIコンポーネントを作って」
4. 「UIとAPIを接続して」

方法3: 段階的詳細化

全体: 「決済機能を実装して」
↓
分割:
1. 「決済フローの概要を説明して」（理解）
2. 「決済開始APIのスケルトンを作って」（構造）
3. 「決済処理のロジックを実装して」（詳細）
4. 「エラーハンドリングを追加して」（堅牢化）

一括依頼を避ける習慣

一括依頼を避けるための習慣を身につけましょう。

習慣1: 5分ルール

プロンプトを書く前に、「このタスクは5分で確認できるか」を考える。できなければ分割。

習慣2: 確認ポイントの設定

大きなタスクを始める前に、「どこで確認するか」を決める。

習慣3: TODOリストの作成

全体のタスクをTODOリストに分解してから、一つずつ依頼。

習慣4: コミット単位で考える

「1コミットで説明できる単位」を意識する。

この事例から学ぶべき教訓

「一括依頼」から学ぶべきことは以下の通りです。

一括依頼は最も効率が悪い
- コンテキスト限界、エラー特定困難、品質不均一
分割統治を適用せよ
- 大きな問題を小さな問題に分割
適切な粒度は「100行以下」
- 一目で把握でき、独立してテストできる単位
反復的アプローチを取れ
- 依頼→レビュー→確認→修正→次へ
一括依頼が許されるのはプロトタイプのみ
- 本番コードでは避ける

まとめ：重要ポイントの振り返り

「全部作って」は 最も効率が悪い アプローチ
一括依頼の問題：コンテキスト限界、エラー特定困難、品質不均一
分割統治 の原則を適用：大きな問題を小さな問題に
適切な粒度は 100行以下 、一目で把握できる単位
反復的アプローチ ：依頼→レビュー→確認→次へ
教訓：大きく頼まず、小さく頼め

一括依頼の罠：AIに全部任せると何が起きるか