「16人日の開発が2時間で終わった」という話を聞いたとき、最初は「Claude Codeがすごい」という話だと思いました。でも、当事者が強調していたのは全然違うことでした。「AIがすごかったのではなく、設計書がAIに考えさせなかったから速かった」のだと。
その言葉がずっと引っかかっていました。個人でアプリを開発していると、「AI を使っているのになぜ遅いんだろう」という経験は珍しくありません。その理由を掘り下げていくと、ほぼ必ず「設計書の問題」にたどり着きます。
このプレミアム記事では、Claude Code で本当に速度を出すための設計書設計の実践的な考え方と、実際に使えるテンプレートをお伝えします。
なぜ設計書がAI駆動開発の速度上限を決めるのか
Claude Code に代表される AI コーディングエージェントは「実装」が得意で「判断」が苦手です。
判断とは、「このケースではどちらの設計にしますか？」「エラーハンドリングはどこまで実装しますか？」「この仕様変更は既存の設計とどう整合させますか？」といった問いです。これに答えるのは人間の仕事であり、AI はひとたび判断に迷うと立ち止まって質問してきます。
実際、曖昧な設計書でClaude Codeに開発を依頼すると、次のようなことが起きます。
AI: このAPIのエラーレスポンスの形式はどうしますか？
人間: { error: string } でお願い
AI: ネットワークエラーの場合も同じ形式ですか？
人間: はい
AI: 認証エラーの場合はステータスコードも一緒に返しますか？
人間: はい、401で
AI: では404の場合は？
（以下続く）
この質問と回答のラリーが開発速度を劇的に落とします。16人日が2時間になった事例では、設計書が3,500行・20セクションで事前に詳細な仕様が定義されていました。AIが「判断」するシーンがほとんどなかったため、「実装」だけに集中できたのです。
「AIに考えさせない」設計書の3つの条件
条件1：決定事項がすべて記録されている
設計書で最も重要なのは「なぜそう決めたか」の記録です。実装の詳細よりも、判断の根拠を書くことに力を入れるべきです。
良い例：
## 認証フロー
JWTを採用する（理由：サーバーレス環境でセッション管理が不要なため）
トークン有効期限は24時間（理由：モバイルアプリの利用パターンを考慮。
リフレッシュトークンは実装コストに対して効果が薄いと判断）悪い例：
## 認証フロー
JWTで認証を実装する前者であれば、AIはトークン期限の変更や例外処理を考える際に自分で判断できます。後者ではその都度質問が発生します。
条件2：エッジケースと除外仕様が明示されている
「実装しないこと」を書くのが設計書で最も見落とされがちな要素です。
## スコープ外（今フェーズでは実装しない）
- 多言語対応（MVP後に検討）
- ソーシャルログイン（優先度低）
- メール通知（プッシュ通知で代替）
- 管理画面（CSVエクスポートで対応）「実装しない」という決定が明示されていないと、AIは「もしかして実装すべきかもしれない」と余計なコードを生成したり、確認を取ろうとしたりします。
条件3：ファイル・コンポーネント・命名規則が事前定義されている
実装に入る前に、プロジェクトの構造をある程度固めておくことで、AIの生成するコードの一貫性が上がります。
## ディレクトリ構成
src/
components/ # Reactコンポーネント（PascalCase）
hooks/ # カスタムフック（use*プレフィックス必須）
api/ # API呼び出し関数（camelCase）
types/ # TypeScript型定義（PascalCase、.types.ts拡張子）
utils/ # ユーティリティ関数（camelCase）
## 命名規則
- コンポーネント: UserCard.tsx（機能+コンポーネント種別）
- フック: useUserData.ts（use+機能名）
- API関数: fetchUserById.ts（動詞+対象+条件）実践的な3ファイル体制：DESIGN.md・TASK.md・DECISION.md
Claude Code との協働で効果的だったのが、設計情報を3種類のファイルに分けて管理する方法です。
DESIGN.md：システム全体の設計書
プロダクトの「何を作るか」「どう作るか」を記述するメインドキュメントです。以下の構成を基本としています。
# プロジェクト名
## 概要
（プロダクトの目的と解決する課題を1-2段落で）
## ユーザーストーリー
- ユーザーAは〜できる
- ユーザーBは〜できる
## 技術スタック
（使用するフレームワーク・ライブラリと選定理由）
## データモデル
（主要なエンティティとその関係）
## API設計
（エンドポイント一覧とリクエスト/レスポンス形式）
## 状態管理方針
（どこに何の状態を持つか）
## エラーハンドリング方針
（エラーの分類と処理方針）
## スコープ外
（今回実装しないことの一覧）TASK.md：実装タスクの分解書
DESIGN.md を受けて、Claude Code に渡す実装タスクを細かく分解したドキュメントです。
重要なのは「完了条件」を各タスクに明示することです。
## タスク一覧
### Phase 1: 基盤構築
- [ ] プロジェクトセットアップ
- 完了条件: `npm run dev` が起動する、ESLint/Prettierが通る
- [ ] 認証API実装
- 完了条件: /api/auth/login が { token: string } を返す、テストが通る
- 依存: なし
### Phase 2: コア機能
- [ ] ユーザー一覧ページ
- 完了条件: /users でDBのユーザー一覧が表示される、エラー時にトーストが出る
- 依存: 認証API実装完了条件が明示されていると、AIは「この実装が終わったかどうか」を自律的に判断できます。
DECISION.md：設計判断ログ
開発中に生まれた設計上の判断を記録するドキュメントです。特にAIとの協働では、「なぜそう決めたか」が後から見失われやすいため、これを残す点が肝心です。
# 設計判断ログ
## 2026-04-15: 状態管理にZustandを選択
**背景**: グローバルな状態が必要になった
**選択肢**: Context API / Redux / Zustand
**決定**: Zustand
**理由**:
- プロジェクト規模に対してReduxはオーバーエンジニアリング
- Context APIはパフォーマンスに懸念
- Zustandはボイラープレートが少なくチーム学習コストが低い
**今後の判断**: 規模が拡大したらReduxへの移行を検討Claude Codeへの渡し方：コンテキストの優先順位
設計書が準備できたら、Claude Code へのプロンプトの渡し方にも工夫が必要です。
最も効果的だと感じるのは、セッション開始時に必ず設計書を読み込ませることです。
@DESIGN.md @TASK.md を読んでください。
今から「Phase 1: 基盤構築」の「認証API実装」を実装します。
完了条件を確認したら、実装を開始してください。
質問がある場合はすべて先にまとめて聞いてください（途中で止まらないように）。
「質問がある場合はすべて先にまとめて聞いてください」という指示が重要です。これを加えることで、実装途中に何度も中断されることが減ります。
設計書を書くのが遅い場合の対処法
「設計書を書く時間がかかって本末転倒では？」という声もあります。正直なところ、最初の設計書作成に数時間かかることはあります。
ただ、これには解決策があります。設計書自体を Claude Code に書かせることです。
私はアプリを開発したいと思っています。
[概要を1-2段落で記述]
これをベースに、DESIGN.md テンプレートを埋める形で設計書を作ってください。
不明な点は「TBD」にしておいてください。あとで私が埋めます。
AI が生成した設計書のドラフトを人間がレビューして「TBD」部分を埋める。このアプローチのほうが、ゼロから書くより3〜4倍速く済みます。
全体を振り返って：設計書は投資であり、省略できないもの
Claude Code を使っていても開発が遅い理由のほとんどは、設計書の不備か不在です。AIは実装マシンであり、判断マシンではありません。判断の負担を人間が事前に引き受けることで、AIは本来の能力を最大限に発揮できます。
次の実装から、まず DESIGN.md を書くことを試してみてください。最初は1〜2時間かかるかもしれませんが、その後の実装速度が別次元になります。