📋

【個人開発】Claude Codeに83%のコードを書かせる「ドキュメント駆動開発」の全貌【Flutter向けCLAUDE.md公開】

に公開

こんにちは、MLエンジニアのふるです。最近ネイティブアプリにハマったので、ネイティブアプリの記事をたくさん書いていこうと思います。noteで書いた記事における技術解説版です。

AIサマリー

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はコンテキストを以下の優先順位で探索します。

  1. 会話履歴
  2. CLAUDE.md(プロジェクト指針)
  3. 明示的に参照されたファイル
  4. 関連しそうなファイル(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