アンチパターン⑨「計画なしの開発」

「まず作ってみよう」の罠

vibe codingでよく見られるパターンがあります。

「何を作るか明確にする前に、とりあえずAIに頼む」

このアプローチは、短期的には速く見えますが、長期的には破綻を招きます。

計画なし開発の典型パターン

計画なしの開発がどのように進むか見てみましょう。

典型的な流れ:

Day 1: 「アプリを作って」
       → なんか動くものができた

Day 3: 「ユーザー機能も追加して」
       → 認証が追加された（セッション方式）

Day 5: 「あ、決済も必要」
       → 決済機能が追加された（認証と整合性なし）

Day 7: 「管理画面も欲しい」
       → 管理画面ができた（セキュリティ考慮なし）

Day 10: 「なんか全体的におかしい...」
        → アーキテクチャが崩壊

Day 15: 「やり直しだ...」

なぜ計画が必要か

計画なしの開発が失敗する理由があります。

理由1: AIは「全体」を見ない

AIは依頼された「その機能」しか考えない
他の機能との整合性を考慮しない
システム全体の設計を意識しない

理由2: 矛盾が蓄積する

各セッションで異なる決定がされる
認証方式の混在
命名規則の不一致
データモデルの矛盾

理由3: 後からの修正が困難

基礎が不安定だと、上物を直しても崩れる
「修正」が「さらなる矛盾」を生む
最終的に「書き直し」しかなくなる

James Goslingの警告

Java創造者のJames Goslingは、vibe codingについて警告しています。

“As soon as your [vibe coding] project gets even slightly complicated, they pretty much always blow their brains out.” 「プロジェクトがちょっと複雑になると、ほぼ必ず破綻する」

計画なしで「複雑」に立ち向かうことはできません。

実践的な解決策：計画ファースト

計画なし開発を防ぐための解決策があります。

実践的な解決策1: 要件定義を先に

AIに依頼する前に、以下を明確にする:

# プロジェクト要件

## 目的
- 何を解決するのか
- 誰が使うのか

## 実装すべき機能要件
1. ユーザー登録・ログイン
2. 商品一覧表示
3. カート機能
4. 決済処理

## 非機能要件
- 同時ユーザー数: 1000人
- レスポンス時間: 200ms以下
- セキュリティ: OWASP準拠

実践的な解決策2: アーキテクチャを先に設計

# システムアーキテクチャ

## 推奨される技術スタックと構成
- フロントエンド: Next.js + TypeScript
- バックエンド: Node.js + Express
- データベース: PostgreSQL
- 認証: JWT

## ディレクトリ構造
src/
  components/  # UIコンポーネント
  pages/       # ページ
  api/         # APIエンドポイント
  lib/         # ユーティリティ
  db/          # データベース関連

## 命名規則
- 関数: camelCase
- コンポーネント: PascalCase
- ファイル: kebab-case

実践的な解決策3: 小さな単位で反復

Step 1: ユーザーモデルとDB接続
        → レビュー → 確認

Step 2: 認証エンドポイント（JWT）
        → レビュー → 確認

Step 3: 商品モデルとAPI
        → レビュー → 確認

Step 4: カート機能
        → レビュー → 確認
...

各ステップで「確認」を入れることで、矛盾を早期発見できます。

実践的な解決策4: CONTEXT.mdの維持

# CONTEXT.md

## 決定事項
- 認証: JWT（セッションは使わない）
- データベース: PostgreSQL（Prisma使用）
- APIスタイル: REST（GraphQLは使わない）

## AI開発で避けるべき禁止事項
- any型の使用禁止
- console.logの本番使用禁止
- インラインスタイル禁止

## 既存パターン
- エラーハンドリング: AppErrorクラス
- バリデーション: zodスキーマ
- 認証: authMiddleware

計画と柔軟性のバランス

計画は重要ですが、過度な計画 も問題です。

バランスのとり方:

大まかな計画は必須
- 全体アーキテクチャ
- 主要な技術決定
- 命名規則
詳細は柔軟に
- 実装の詳細は作りながら決める
- 学びながら調整
- 完璧を求めすぎない
反復を前提に
- 最初から完璧を目指さない
- 小さく作って、改善
- リファクタリングを計画に含める

この事例から学ぶべき教訓と実践ポイント

「計画なしの開発」から学ぶべきことは以下の通りです。

AIは全体を見ない
- その機能しか考えない
矛盾が蓄積する
- 認証方式、命名規則、データモデル
後からの修正は困難
- 基礎が不安定だと崩れる
解決策: 計画ファースト
- 要件定義、アーキテクチャ、小さな反復
CONTEXT.mdで決定事項を維持
- AIに毎回伝える

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

「まず作ってみよう」は 破綻への道
AIは 全体を見ない 、矛盾が蓄積
計画なしでは 複雑に対処できない （Goslingの警告）
解決策：要件定義 → アーキテクチャ設計 → 小さな反復
CONTEXT.md で決定事項を維持
教訓：計画なしに作るな、設計してから頼め

計画なしAI開発の失敗パターンと対策