【個人開発】Claude Codeに83%のコードを書かせる「ドキュメント駆動開発」の全貌【Flutter向けCLAUDE.md公開】
こんにちは、MLエンジニアのふるです。最近ネイティブアプリにハマったので、ネイティブアプリの記事をたくさん書いていこうと思います。noteで書いた記事における技術解説版です。
AIサマリー

今回作ったアプリについて
トークマネ - AIが能動的に声をかけてくれる予定管理アプリ
毎朝「今日の予定、決めましょうか?」とAIが話しかけてくる。音声で会話するだけで予定が自動登録。
「ひとりじゃないから、続く」
以下この個人開発アプリの解説記事になります。

はじめに
「AIにアプリを作らせようとしたが、仕様を勝手に変えられた」
「文脈を忘れてバグを埋め込まれた」
そんな経験はありませんか?
私も最初はそうでした。しかし、「コードを書くのをやめ、ドキュメントを書くことに集中」した結果、開発体験が一変しました。
3週間で776コミットを積み上げ、FlutterアプリをApp Storeにリリースした際のデータがこちらです。
| 項目 | 数値 |
|---|---|
| 総コミット数 | 776 |
| Claudeが書いたコミット | 648(83.5%) |
| 人間が書いたコミット | 128(16.5%) |
| PR数 | 71 |
| ドキュメント関連コミット | 116 |
83%のコードをAIに任せることができた最大の要因。それは、開発初手の3日間で24種類のドキュメントを徹底的に整備したことにあります。
本記事では、その具体的な「ドキュメント構成」と、Claude Codeを制御するための「CLAUDE.md」の中身をすべて公開します。
なぜ「ドキュメント駆動」なのか
AI開発の勝敗は「コンテキスト」で決まる
Claude CodeなどのAIコーディングツールに、口頭のような指示を与えてはいけません。
これでは、AIは「どのAPIを使う?」「DB設計は?」「UIライブラリは?」と推測で穴埋めを始めます。これが手戻りの元凶です。
参照すべき「正解」を渡すことで、AIの推測を排除し、一発で精度の高いコードを引き出せます。
戦略1:解像度を上げる「確認フロー」の構築
プロンプトの一言がAIのIQを変える
私が開発中、徹底してプロンプトに含めていた魔法の一文があります。
「〇〇を進めて。ただし、曖昧な事項は必ず質問すること」
この指示と、詳細なドキュメントが組み合わさると、Claude Codeは以下のように振る舞います。
実例:「次進めるべき実装をまとめて、決めるべきこと曖昧なことをまとめてください。」
実際に「次進めるべき実装をまとめて、決めるべきこと曖昧なことをまとめてください。」と指示したClaude Code Webの画面がこちらです。

実際に「次進めるべき実装をまとめて、決めるべきこと曖昧なことをまとめてください。」と指示した際、Claude Codeは実装に入る前に確認事項をリストアップしてきました。

ドキュメントという「判断材料」があったからこそ、Claudeは 「何がわかっていて、何がわからないか」 を正確に区別した上で、進める上で不明な点を明示できたわけです。
これに対して「なぜ?なぜ?」を徹底的に繰り返していくことで、設計の解像度が上がるだけでなく、技術的知見も向上していきます。

戦略2:SSOT(信頼できる唯一の情報源)の定義
Claude Codeはコンテキストを以下の優先順位で探索します。
- 会話履歴
- CLAUDE.md(プロジェクト指針)
- 明示的に参照されたファイル
- 関連しそうなファイル(AIの推測)
ドキュメントが増えると、必然的に情報の重複や矛盾(古い仕様など)が発生します。そこで、CLAUDE.md に以下のルールを明記し、AIの迷いを断ち切りました。
戦略3:CLAUDE.md 全文公開
プロジェクトルートに配置し、AIの挙動を制御する CLAUDE.md の実物がこちらです。コピペして使ってください。
CLAUDE.md(クリックで展開)
# Claude Code Instructions
## Flutter/Dart Setup
This project requires Flutter 3.38.5 with Dart 3.10.4.
### Install Flutter SDK
./scripts/setup_flutter.sh
export PATH="/home/user/flutter/bin:$PATH"
## Before Commit/Push
Always run these commands before committing:
# Format code
dart format .
# Analyze code (must pass with no issues)
flutter analyze
# Run tests (if applicable)
flutter test
### Commit Checklist
1. `dart format .` - Ensure 0 files changed (already formatted)
2. `flutter analyze` - No issues found
3. Commit with clear message
4. Push to feature branch
## Project Structure
- `lib/` - Main application code
- `test/` - Unit and widget tests
- `scripts/` - Build and utility scripts
- `docs/` - Documentation
## Conflict Resolution
If specific logic contradicts general guidelines:
1. Trust the codebase first (if implemented).
2. Ask the user for clarification.
ポイント:CLAUDE.mdには「詳細」を書かない
このファイルは毎回読み込まれるため、 ポインタ(参照先) としての役割に徹します。詳細は各ドキュメントに委譲し、トークン消費を抑えつつ情報の鮮度を保ちます。
| 問題 | 説明 |
|---|---|
| 更新漏れ | CLAUDE.mdと実際のコードが乖離 |
| コンテキスト肥大化 | 毎回読み込まれるため、トークン消費が増加 |
| 矛盾の温床 | 同じ情報が複数箇所に存在 |
良い例
「詳細は docs/30_technical/voice-session.md を参照」
悪い例
「音声セッションはGemini Live APIを使用し、WebSocketで接続して...(100行続く)」
戦略4:ドキュメント構造の最適化
最終的に、42ファイルあったドキュメントを16ファイルに統合・整理しました。特にこだわったのが 「番号付きフォルダ」 による文脈制御です。
📂 ディレクトリ構成
docs/
├── 10_product/ # WHY: なぜ作るか(要件、ロードマップ)
├── 20_design/ # WHAT: 何を作るか(UI、体験設計)
├── 30_technical/ # HOW: どう作るか(アーキテクチャ、API)
├── 40_operations/ # RUN: どう運用するか(課金、リリース)
└── 50_android/ # PF: プラットフォーム固有
なぜ番号をつけるのか?
Claude Codeがファイル一覧をスキャンした際、10 → 20 → 30 の順に認識されます。これにより、 「プロダクトの意図(WHY)を理解してから、技術仕様(HOW)を読む」 という自然な思考順序をAIに強制できます。
| 理由 | 説明 |
|---|---|
| 依存関係の明示 | 10→20→30の順に依存。30_technicalは20_designを前提とする |
| 探索順序の制御 | Claude Codeがls/findでファイル一覧を取得したとき、番号順に並ぶ |
| 人間にも分かりやすい | WHY→WHAT→HOWの流れが番号で直感的に理解できる |
| 拡張性 | 15_marketingなど、後から間に追加可能 |
戦略5:MECE思考でAIの「分類」を助ける
AIに機能追加を指示した際、「どこにコードを書くべきか」で迷わせないことが重要です。ここで役立つのがコンサルティング用語の MECE(漏れなくダブりなく) です。
MECE(ミーシー) とは:
- Mutually Exclusive(相互排他):各カテゴリが重複しない
- Collectively Exhaustive(完全網羅):全ての要素がいずれかのカテゴリに属する
実践:notification-design.md
例えば「通知システム」の設計では、以下のように定義しました。
| カテゴリ | 説明 | トリガー |
|---|---|---|
| onboarding | オンボーディング | 登録後1〜7日目 |
| pre_session | セッション前 | 設定時刻の朝 |
| post_check | 振り返り | 設定時刻の夜 |
| rescue | 救済 | 未実施時の22時 |
| streak | ストリーク | 記録更新時 |
「新しい通知タイプを追加する際は、必ずいずれかのカテゴリに属させること」と指示しておくことで、AIは既存の構造に従って自律的にコードを配置できます。
戦略6:コードを読む前の「地図」を配置する
docs/ だけでなく、ソースコードのルートである lib/ にも README.md を配置しました。これにより、AIはコードを解析する前にアーキテクチャ全体を把握できます。
lib/README.md の記述例
## レイヤー概要
| レイヤー | 責務 |
|---------|------|
| core | 共通部品、定数、テーマ |
| data | データモデル、ローカルDB |
| services | 外部API連携 |
| presentation | UI、状態管理 |
戦略7:AI時代のGit運用とコミット粒度
AI開発では、人間が書く場合よりも コミットを細かく刻む(Conventional Commits) ことが重要です。理由は単純で、AIがバグを埋め込んだ際にロールバックしやすくするためです。
| 理由 | 説明 |
|---|---|
| ロールバックしやすい | AIが生成したコードに問題があった場合、細かいコミットなら戻しやすい |
| デバッグの追跡 | どの変更でバグが入ったか特定しやすい |
| レビューしやすい | 大きな差分より、小さな差分の方が人間がレビューしやすい |
| AIの学習材料 | コミット履歴がプロジェクトの文脈として機能する |
理想的なデバッグサイクル
実際の開発ログを見ると、以下のようなサイクルが回っています。
debug: add logging to trace chat session reset issue
↓
fix: prevent chat session reset when calendar changes
↓
chore: remove debug logs from chat session flow
AIには「一気に直して」ではなく、「まずログを入れて」「原因を特定して」「修正して」「ログを消して」と段階的に指示することで、解決率が格段に上がります。また、エラーが回帰した際にも詳細なコミットは振り返るときに助かります。
注意点:ドキュメントの粒度
❌ 粗すぎ
「音声機能を作る」
→ 何をどう作るか不明
→ Claude Codeが推測で動く
❌ 細かすぎ
「ボタンは16pxの角丸で、#3B82F6の青色で...」
→ 実装と乖離したとき、矛盾が発生
→ ドキュメントが負債化する
→ メンテナンスコストが爆発
✅ 適切
「Gemini Live API → Function Calling → Supabase保存」
→ 技術選定と大まかな流れが明確
→ 細部はClaude Codeが判断
→ 実装と乖離しにくい
| 問題 | 説明 |
|---|---|
| 矛盾の発生 | ドキュメントに「16px」と書いてあるのにコードは「12px」→ どっちが正しい? |
| 更新コスト | UIを少し変えるたびにドキュメントも更新が必要 |
| Claude Codeの混乱 | 「ドキュメントとコードが違う」状態でAIが迷う |
コードが真実。ドキュメントは「なぜそうしたか」を残す場所。
投資対効果:最初の3日間で勝負は決まる
「ドキュメントを書く時間がない」と感じるかもしれません。しかし、本プロジェクトのデータを見れば、それが最も効率的な投資であることがわかります。
ドキュメント作成の時系列(実際のGit logより)
以下は、実際の git log --oneline -- docs/ の抜粋です。
# ============================================
# Day 2-3(開発開始直後)- 設計ドキュメント爆速整備
# ============================================
12/30 docs: Update roadmap to reflect Phase A (Firebase) completion
12/31 docs: Update Phase C/F plan - prioritize voice UI
12/31 docs: Update implementation-roadmap to v3.1.0
12/31 docs: Simplify AGENT.md and standardize document headers
12/31 docs: Add README.md for each lib layer # ← lib/配下にREADME
12/31 docs: Restructure 20_design/ by aspect # ← 番号付きフォルダ導入
12/31 docs: Add implementation status summary document
12/31 docs: Add recurring schedule feature documentation
12/31 docs: Add release guide and documentation index
# Day 4-5 - 課金設計 & オンボーディング
01/01 docs: Reorganize documentation structure into clean hierarchy
01/01 docs: Add ASO texts for App Store Connect submission
01/01 docs: Major update to onboarding and notification flow v1.1.0
01/01 docs: Add 迷子型 persona and test scenarios # ← ペルソナ設計
01/01 docs: Add billing model design and multiple goal PoC
01/01 docs: Update billing model to v2.0 with pool system
# Day 6 - 課金モデル確定 & ドキュメント統合
01/02 docs: Update billing model - free notifications, trial 60min
01/02 docs: Add Apple fee (15%) to revenue simulation
01/02 docs: Finalize billing v2.0 decisions with rollover pool
01/02 docs: Update design specs to v2.0 with frosted glass
01/02 docs: Consolidate and update documentation for MVP completion
01/02 docs: Reorganize documentation structure and unify headers
# ============================================
# Day 14〜(実装が進んだ後)- 運用ドキュメント追加
# ============================================
01/10 docs: add auth architecture documentation
01/10 docs: add comprehensive system architecture diagram
01/10 docs: fix CI/CD architecture (Codemagic for TestFlight)
01/10 docs: improve architecture diagram with Supabase components
# Day 15 - Apple審査対応 & カレンダー設計
01/11 docs: add App Review Notes template for Apple review
01/11 docs: clarify consumable IAP details in support FAQ
01/11 docs: add future work for calendar sync features
01/11 docs: update architecture diagram with Cloud Build
# Day 16 - リリースノート
01/12 docs: add v1.0.3 release notes and Apple review response
# Day 18 - ドキュメント構造の大規模リファクタ
01/14 docs: reorganize documentation structure
01/14 docs: update requirements.md to v2.0 with pool system
01/14 docs: consolidate duplicate docs (notification-strategy)
01/14 docs: add API versioning design document
01/14 docs(billing): add manual operations guide
# Day 19 - v1.1要件定義
01/15 docs: add v1.1 release requirements
01/15 docs: archive completed phases
# Day 21 - 法務文書 & タイムゾーン
01/17 docs: add tokushoho (特定商取引法) legal disclosure
01/17 docs: add timezone handling guidelines
# Day 23 - MECE通知設計
01/19 docs: add MECE notification system design
01/19 docs: add server notifications guide (RTDN vs App Store)
01/19 docs: add detailed Extension UI design
# Day 24 - v1.2計画
01/20 docs: add v1.2.0 release review and growth feature designs
01/20 docs: mark In-App Review and SNS sharing as completed
# Day 25 - ドキュメント統合(42→16ファイル)
01/21 docs: consolidate documentation from 42 to 14 files
01/21 docs: add Google Sign-In SHA-1 design and operations guide
01/22 docs: sync documentation with codebase implementation
ドキュメントコミット数の推移
| フェーズ | 期間 | docs commits | 特徴 |
|---|---|---|---|
| 初期設計 | Day 1-3 | 24 | 要件・設計・アーキテクチャを一気に整備 |
| 実装期 | Day 4-13 | 8 | 実装に集中。ドキュメントは最小限の更新 |
| 運用整備 | Day 14-20 | 32 | 審査対応・法務・通知設計を追加 |
| 統合 | Day 21-25 | 12 | 42→16ファイルへリファクタリング |
最初の3日間で主要なドキュメント(計24種類)を整備した結果、その後の18日間は 「ドキュメントを参照して実装するだけ」 の状態になり、開発速度が爆発的に向上しました。
まとめ
83%のコードをAIに任せるために必要なのは、高度なプロンプトエンジニアリングではありません。「AIが迷わないための地図(ドキュメント)」を用意することです。
| 戦略 | 内容 |
|---|---|
| SSOTの定義 | 矛盾時のルールを決める(コード優先 or 確認) |
| 構造化 |
10_ 20_ でコンテキストの優先度を示す |
| MECE | カテゴリを明確にし、AIの迷いを消す |
| 確認の強制 | 「曖昧な点は質問せよ」と指示する |
| ポインタ優先 | CLAUDE.mdは参照先を示すだけ。詳細は書かない |
ドキュメント駆動開発は、AI時代における最強のレバレッジ手段です。
ぜひ、あなたの個人開発にも取り入れてみてください。

Discussion