ベストプラクティス：明確な記述、チェックポイントの活用、スコープ制御と反復開発のテクニック
本コースでできること
本コースを修了すると、以下のスキルを習得できます：
- AI に自分のアイデアを理解させるための高品質なプロダクト記述の記述方法
- チェックポイントメカニズムを活用して各段階の出力品質を制御する方法
- 非目標を明確にしてスコープ境界を定義し、プロジェクトの肥大化を防ぐ方法
- 段階的なイテレーションを通じてアイデアを迅速に検証し、継続的に最適化する方法
今直面している課題
以下のような状況に遭遇していませんか：
- 「ちゃんと言ったはずなのに、生成されたのは望み通りのものではない」
- 「一箇所が気に入らないと、その後すべて間違っていて、修正がとても大変」
- 「やっているうちに機能がどんどん増えて、まったくまとまらない」
- 「すべての機能を一気に作ろうとして、結局何も作れなかった」
いつこのテクニックを使うべきか
AI App Factory を初めて使う場合でも、すでに数回経験がある場合でも、これらのベストプラクティスは以下の点で役立ちます：
- 出力品質の向上：生成されるアプリが期待通りになるようにする
- 修正時間の節約：エラーの蓄積を防ぎ、早期に問題を発見する
- プロジェクト規模の制御：MVP に焦点を当て、迅速にデリバリーする
- 開発コストの削減：段階的に検証し、無駄な投資を回避する
🎒 開始前の準備
前提条件
- クイックスタート を読み、AI App Factory の基本概念を理解している
- 7 段階パイプラインの概要 を読み、完全なプロセスを理解している
- 少なくとも 1 回の完全なパイプライン実行を完了している（各段階の出力を直感的に理解できるように）
コアコンセプト
AI App Factory のベストプラクティスは、4 つのコア原則に基づいています：
- 入力品質が出力品質を決定する：明確で詳細なプロダクト記述は成功の第一歩
- チェックポイントは品質の防波堤：各段階完了後に注意深く確認し、エラーの蓄積を防ぐ
- MVP に集中する：非目標を明確にしてスコープを制御し、コア機能を迅速にデリバリーする
- 継続的に反復する：最初にコアアイデアを検証し、その後段階的に機能を拡張する
これらの原則はソースコードと実戦経験の要約から得られており、それらに従うことで開発効率が数倍向上します。
手順通りにやってみよう
テクニック 1：明確なプロダクト記述を提供する
なぜ必要か
AI があなたのアイデアを理解する際、提供されたテキスト情報にしか依存できません。記述が明確であればあるほど、生成されたプロダクトは期待に近づきます。
どうやるか
良いプロダクト記述には以下の要素が含まれます：
- ターゲットユーザー：誰がこの製品を使うのか？
- コア課題：ユーザーはどんな困難に直面しているのか？
- 解決策：製品はどのようにその困難を解決するのか？
- 主要機能：どの機能を必ず含める必要があるのか？
- 使用シーン：ユーザーはどんな状況で使うのか？
- 制約条件：どんな制限や特別な要件があるのか？
比較例
| ❌ 悪い記述 | ✅ 良い記述 |
|---|---|
| フィットネスアプリを作る | フィットネス初心者がトレーニングを記録できるアプリ。運動タイプ、時間、消費カロリーの記録をサポートし、今週のトレーニング統計を確認できる。ターゲットユーザーはフィットネスを始めたばかりの若者で、コア機能は素早い記録と進捗確認。ソーシャル共有や有料機能は含まない |
| 家計簿アプリを作る | 若者が日常支出を素早く記録できるモバイル家計簿アプリ。主な機能は金額の記録、分類の選択（食事、交通、エンタメ、その他）、今月の総支出と分類統計の確認。オフライン使用をサポートし、データはローカルにのみ保存される |
| タスク管理ツールを作る | 小規模チームがタスクを管理するシンプルなツール。タスク作成、メンバー割り当て、期限設定、タスクリスト表示をサポート。チームメンバー間でタスクステータスを共有できる。複雑なワークフローや権限管理は不要 |
チェックポイント ✅
- [ ] 記述にターゲットユーザーが明確に示されている
- [ ] 記述にユーザーが直面するコア課題が説明されている
- [ ] 記述に主要機能が列挙されている（5 個以内）
- [ ] 記述に制約条件や非目標が含まれている
テクニック 2：チェックポイントで注意深く確認する
なぜ必要か
パイプラインの各段階完了後にチェックポイントで一時停止し、あなたの確認を待ちます。これは品質の防波堤であり、早期に問題を発見してエラーが後続の段階に伝播するのを防ぐことができます。
この段階で問題を発見できれば、現在の段階を再実行するだけです。最後まで気づかなければ、複数の段階をロールバックする必要があり、大量の時間と Token を浪費することになります。
どうやるか
各チェックポイント確認時に、以下の内容を確認します：
Bootstrap 段階のチェックポイント：
- [ ]
input/idea.mdの問題定義が正確 - [ ] ターゲットユーザーペルソナが明確で具体的
- [ ] コアバリュープロポジションが明確
- [ ] 仮定条件が合理的
PRD 段階のチェックポイント：
- [ ] ユーザーストーリーが明確で、受諾条件を含んでいる
- [ ] 機能リストが 7 個以内（MVP 原則）
- [ ] 非目標が明確に列挙されている
- [ ] 技術的詳細（React、API、データベースなど）が含まれていない
UI 段階のチェックポイント：
- [ ] ページ構造が合理的で、3 ページ以内
- [ ] ブラウザでプロトタイプをプレビューできる
- [ ] インタラクションフローが明確
- [ ] 美的スタイルが際立っている（一般的な AI スタイルを避ける）
Tech 段階のチェックポイント：
- [ ] 技術スタックの選択が合理的で、MVP 原則に合致している
- [ ] データモデル設計がシンプルで、テーブル数が 10 個以内
- [ ] API エンドポイントリストが完全
- [ ] マイクロサービス、キャッシュなどの過度な設計が導入されていない
Code 段階のチェックポイント：
- [ ] フロントエンドとバックエンドのコード構造が完全
- [ ] テストケースが含まれている
- [ ] 明らかな
any型がない - [ ] 実行方法を説明する README.md が含まれている
Validation 段階のチェックポイント：
- [ ] 検証レポートに深刻なセキュリティ問題がない
- [ ] テストカバレッジ > 60%
- [ ] 依存関係のインストールで競合がない
- [ ] TypeScript の型チェックが通る
Preview 段階のチェックポイント：
- [ ] README.md に完全な実行説明が含まれている
- [ ] Docker 設定で正常にビルドできる
- [ ] ローカルでフロントエンドとバックエンドサービスを起動できる
- [ ] 環境変数設定の説明が含まれている
チェックポイント確認フロー
各チェックポイントで、システムは以下のオプションを提供します：
- 続行：出力が期待通りであれば、次の段階に進む
- 再試行：出力に問題があれば、修正意見を提供して現在の段階を再実行する
- 一時停止：追加情報が必要な場合やアイデアを調整したい場合、パイプラインを一時停止する
意思決定原則：
- ✅ 続行：すべてのチェック項目が要件を満たしている
- ⚠️ 再試行：小さな問題（フォーマット、漏れ、詳細）で、直ちに修正できる
- 🛑 一時停止：重大な問題（方向が間違っている、スコープが制御不能、修正不可能）で、再計画が必要
落とし穴への注意
よくある間違い
「急いで終わらせるためにチェックポイント確認をスキップしないでください！」
パイプラインは「各段階で一時停止して確認する」ように設計されています。これは、問題を早期に発見するためです。習慣的に「続行」をクリックして、最後まで問題に気づかなければ、以下のことになるかもしれません：
- 複数の段階をロールバックする
- 大量の作業を再実行する
- 大量の Token を浪費する
覚えておいてください：チェックポイント確認の時間投入は、ロールバックと再実行の時間コストよりはるかに小さいです。
テクニック 3：非目標を活用してスコープを制御する
なぜ必要か
**非目標（Non-Goals）は MVP 開発の中核武器です。「何をしないか」を明確に列挙することで、スコープの肥大化を効果的に防ぐことができます。
多くのプロジェクトの失敗の根源は、機能が少なすぎることではなく、機能が多すぎることです。各新機能は複雑さ、開発時間、保守コストを増加させます。境界を明確にし、コアバリューに焦点を当てることで、迅速にデリバリーできます。
どうやるか
Bootstrap 段階で、非目標を明確に列挙します：
## 非目標（本バージョンで行わない機能）
1. 複数人のコラボレーションはサポートしない
2. リアルタイム同期はサポートしない
3. サードパーティサービス統合（決済、地図など）はサポートしない
4. データ分析やレポート機能は提供しない
5. ソーシャル共有機能は含まない
6. ユーザー認証やログイン機能は不要PRD 段階で、非目標を独立した章にします：
## 非目標（本バージョンで明確に行わない）
以下の機能は価値がありますが、今回の MVP の範囲外です：
| 機能 | 理由 | 今後の計画 |
| --- | --- | --- |
| 複数人コラボレーション | 個人ユーザーに集中 | v2.0 で検討 |
| リアルタイム同期 | 技術的複雑さを増やす | ユーザーフィードバックが強い場合に検討 |
| 決済統合 | コアバリューではない | v1.5 で検討 |
| データ分析 | MVP には不要 | v2.0 で検討 |非目標の判断基準
非目標にすべきかどうかを判断する方法：
- ❌ この機能はコアアイデアの検証には不可欠ではない → 非目標にする
- ❌ この機能は技術的複雑さを大幅に増加させる → 非目標にする
- ❌ この機能は手動で代替できる → 非目標にする
- ✅ この機能は製品が存在する理由である → 必ず含める
落とし穴への注意
スコープの肥大化の罠
よくあるスコープの肥大化の兆候：
- 「どうせ簡単だから、ついでに一つ追加しよう...」
- 「競合はみんなこの機能を持っているから、私たちも...」
- 「ユーザーが必要かもしれないから、先に作っておこう...」
- 「この機能は面白くて、製品の目玉になる...」
こういうアイデアが出たとき、自分に 3 つの質問をしてください：
- この機能はコアアイデアの検証に役立つか？
- この機能をしなくても、製品は使えるか？
- この機能を追加すると、デリバリー時間が遅れるか？
答えが「不要」「使える」「遅れる」なら、躊躇なく非目標にしてください。
テクニック 4：段階的に反復し、迅速に検証する
なぜ必要か
**MVP（最小実行可能プロダクト）のコアコンセプトは、アイデアを迅速に検証することであり、一気に完璧に作ることではありません。
反復的開発を通じて、以下のことができます：
- 早期にユーザーフィードバックを得る
- 方向を適時に調整する
- 沈没コストを下げる
- 開発のモチベーションを維持する
どうやるか
反復的開発のステップ：
第 1 ラウンド：コア機能の検証
- AI App Factory を使用して第 1 版のアプリを生成
- 最もコアな 3-5 個の機能のみを含める
- 迅速に実行してテスト
- 本物のユーザーにプロトタイプを提示し、フィードバックを収集
第 2 ラウンド：フィードバックに基づいて最適化
- ユーザーフィードバックに基づいて、優先度が最も高い改善点を決定
input/idea.mdまたはartifacts/prd/prd.mdを修正factory run <stage>を使用して、対応する段階から再実行- 新しいバージョンを生成してテスト
第 3 ラウンド：機能の拡張
- コア目標に達したかどうかを評価
- 2-3 個の高価値機能を選択
- パイプラインを通して生成して統合
- 継続的に反復し、段階的に改善
反復開発の実践例
シナリオ：タスク管理アプリを作りたい
第 1 ラウンドの MVP：
- コア機能：タスク作成、リスト表示、完了マーク
- 非目標：メンバー管理、権限制御、リマインダー通知
- デリバリー時間：1 日
第 2 ラウンドの最適化（フィードバックに基づく）：
- ユーザーフィードバック：タスクにタグを追加したい
- PRD を修正し、「タグ分類」機能を追加
- UI 段階からパイプラインを再実行
- デリバリー時間：半日
第 3 ラウンドの拡張（検証成功後）：
- メンバー管理機能を追加
- 期限リマインダーを追加
- タスクコメント機能を追加
- デリバリー時間：2 日
チェックポイント ✅
各反復の前に、確認してください：
- [ ] 新機能がコア目標と一致している
- [ ] 新機能にユーザーニーズの裏付けがある
- [ ] 新機能が複雑さを大幅に増加させない
- [ ] 明確な受諾基準がある
上級テクニック
テクニック 5：セッション分割で Token を節約する
なぜ必要か
長時間パイプラインを実行するとコンテキストが蓄積し、大量の Token を消費します。セッション分割実行により、各段階がクリーンなコンテキストを独占できるようにし、使用コストを大幅に削減できます。
どうやるか
各チェックポイントで「新しいセッションで続行」を選択します：
# 新しいコマンドラインウィンドウで実行
factory continueシステムは自動的に以下を行います：
.factory/state.jsonを読み込んで状態を復元- 新しい Claude Code ウィンドウを起動
- 次の実行待ち段階から続行
- その段階に必要な入力ファイルのみをロード
比較：
| 方式 | 長所 | 短所 |
|---|---|---|
| 同一セッションで続行 | シンプルで、ウィンドウを切り替える必要がない | コンテキストが蓄積し、Token 消費が大きい |
| 新しいセッションで続行 | 各段階がクリーンなコンテキストを独占でき、Token を節約できる | ウィンドウを切り替える必要がある |
テクニック 6：失敗と再試行を処理する
なぜ必要か
パイプライン実行中に失敗に遭遇する可能性があります（入力不足、権限問題、コードエラーなど）。失敗の処理方法を理解することで、より迅速に進捗を回復できます。
どうやるか
失敗処理のベストプラクティス（failure.policy.md:267-274 を参照）：
- 早期に失敗する：早期に問題を発見し、後続段階での時間の浪費を防ぐ
- 詳細なログ：問題のトラブルシューティングに十分なコンテキスト情報を記録する
- アトミック操作：各段階の出力はアトミックであるべきで、ロールバックしやすくする
- 証拠を保持する：失敗したプロダクトをアーカイブしてから再試行し、比較分析を容易にする
- 段階的な再試行：再試行時に具体的なガイダンスを提供し、単純な繰り返しを避ける
よくある失敗シナリオ：
| 失敗タイプ | 症状 | 処理方法 |
|---|---|---|
| 出力が欠落 | input/idea.md が存在しない | 再試行、書き込みパスを確認 |
| スコープの肥大化 | 機能数 > 7 個 | 再試行、MVP に絞り込むよう要求 |
| 技術エラー | TypeScript コンパイル失敗 | 型定義を確認して再試行 |
| 権限問題 | Agent が未承認ディレクトリに書き込み | 権限境界行列を確認 |
失敗回復チェックリスト：
- [ ] 失敗原因が明確になっている
- [ ] 修正方法が実装されている
- [ ] 関連設定が更新されている
- [ ] 失敗した段階から再開している
失敗は正常です
失敗を恐れないでください！ AI App Factory は完全な失敗処理メカニズムを設計しています：
- 各段階で自動的に 1 回の再試行を許可
- 失敗したプロダクトを自動的に
artifacts/_failed/にアーカイブ - 最近の成功したチェックポイントにロールバック可能
失敗に遭遇した場合、冷静に原因を分析し、失敗戦略に従って処理してください。
本コースのまとめ
本コースでは、AI App Factory の 6 つのベストプラクティスを紹介しました：
- 明確なプロダクト記述：ターゲットユーザー、コア課題、主要機能、制約条件を詳細に記述
- チェックポイントで注意深く確認：各段階完了後に出力品質を確認し、エラーの蓄積を防ぐ
- 非目標を活用してスコープを制御：行わない機能を明確に列挙し、スコープの肥大化を防ぐ
- 段階的に反復：最初にコアアイデアを検証し、その後ユーザーフィードバックに基づいて段階的に拡張
- セッション分割で Token を節約：各チェックポイントで新しいセッションを作成し、使用コストを削減
- 失敗を正しく処理：失敗処理メカニズムを活用し、迅速に進捗を回復
これらのベストプラクティスに従うことで、AI App Factory の使用体験がよりスムーズになり、生成されるアプリの品質が高まり、開発効率が数倍向上します。
次回の予告
次回のレッスンでは CLI コマンドリファレンス を学びます。
以下の内容を学びます：
- factory init コマンドのすべてのパラメータとオプション
- factory run コマンドで指定段階から開始する方法
- factory continue コマンドで新しいセッションから続行する方法
- factory status と factory list でプロジェクト情報を確認する方法
- factory reset でプロジェクト状態をリセットする方法
付録：ソースコード参照
クリックしてソースコードの場所を表示
更新日時：2026-01-29
| 機能 | ファイルパス | 行番号 |
|---|---|---|
| プロダクト記述のテクニック | README.md | 186-210 |
| チェックポイントメカニズム | agents/orchestrator.checkpoint.md | 98-112 |
| 非目標制御 | README.md | 199-203 |
| 失敗処理戦略 | policies/failure.policy.md | 267-274 |
| コンテキスト分離 | policies/context-isolation.md | 10-42 |
| コード規約 | policies/code-standards.md | 全文 |
重要な定数：
MAX_RETRY_COUNT = 1：各段階でデフォルトで自動的に 1 回の再試行を許可
重要なルール：
- Must Have 機能数 ≤ 7 個（MVP 原則）
- ページ数 ≤ 3 ページ（UI 段階）
- データモデル数 ≤ 10 個（Tech 段階）
- テストカバレッジ > 60%（Validation 段階）