Qiitaに投稿された「16人日の開発が2時間で終わった」という記事が話題になりました。最初は「すごいAIの話」だと思って読み始めたのですが、筆者が一番伝えたかったのは全然違うことでした。
「AIがすごかったのではありません。設計書がAIに考えさせなかったから速かったのだ」
この一言が刺さりました。個人でアプリを開発している身として、「AIを使っているのになんで遅いんだろう」と感じる原因がここに凝縮されていると思ったからです。
AIは「実装」が得意で「判断」が苦手
AIコーディングエージェントは、書くべきことが明確なら速い。でも「どうすべきか」を自分で考えなければならない場面で詰まります。
アプリ開発でいうと、こういう質問が飛んできます。
AI: エラーが起きたときの画面はどうしますか？
AI: このデータはローカルに保存しますか？サーバーに送りますか？
AI: ログインが必要なページとそうでないページを教えてください
これに一つひとつ答えながら進めるのは、作業時間の大半を「AI への説明」に使っている状態です。これが設計書なしのAI駆動開発の実態です。
設計書があると何が変わるか
前述の事例では、設計書が3,500行・20セクションで書かれていたそうです。そこには次のような情報が含まれていました。
- 全画面のUI仕様とデータフロー
- APIのエンドポイントと入出力形式
- エラーハンドリングの方針（エラー種別ごとの処理）
- 今フェーズでは実装しないことの一覧
「今フェーズでは実装しないこと」を明示することが特に重要です。これがないと、AIは「これも実装すべきかもしれない」と余計な判断をしたり確認を取ったりします。
アプリ開発向けの最小設計書テンプレート
Rork や他のAIアプリ開発ツールで試してよかった最小テンプレートを紹介します。完璧な設計書である必要はなく、AIに「考えさせない」ための情報が揃っていれば十分です。
# [アプリ名] 設計書
## 概要
- 目的: （一文で）
- ターゲットユーザー: （具体的に）
## 画面一覧
1. ホーム画面: （何が表示されるか・何ができるか）
2. 詳細画面: 〜
3. 設定画面: 〜
## データ設計
- [エンティティ名]: フィールド一覧と型
- 保存先: ローカル / Firebase / Supabase
## 認証
- 必要: Yes / No
- 方法: メール / SNS / 匿名
## 画面遷移
- ホーム → 詳細: （トリガーとなるアクション）
- 詳細 → 設定: 〜
## エラーハンドリング
- 通信エラー: トーストで表示・リトライボタン
- データなし: 空状態の画面を表示
## スコープ外（今回は実装しない）
- プッシュ通知
- 多言語対応
- 分析機能このテンプレートを埋めるだけで、AIへの質問がほぼなくなります。
Rork でのアプリ開発に当てはめると
Rork で「自然言語でアプリを作る」という場合も、同じ原則が当てはまります。
「カロリー管理アプリを作って」という指示より、「食事の記録・1日の合計カロリー表示・Firebase への保存が必要で、SNS連携は今回なし」という指示のほうが、意図通りのアプリに近いものが出てきます。
Rork への指示も「設計書」の一形態です。詳細に書けば書くほど、修正ループが減ります。
設計書を書くハードルを下げる方法
「設計書を書く時間がない」という声もわかります。私自身、以前は設計書を書くこと自体が億劫でした。
最近実践しているのは、設計書の叩き台もAIに作らせることです。
[作りたいアプリの概要を2-3行で説明]
上記のアプリの設計書を以下のテンプレートで作ってください。
不明な点は TBD で埋めてください。
[テンプレートを貼り付け]
AIが出力した設計書を自分でレビューして TBD 部分を埋める。これだけで30〜60分で最小設計書が完成します。ゼロから書くよりはるかに速いです。
全体を振り返って
AIを使ったアプリ開発が期待より遅い場合、多くはAIが「どうすべきか」を何度も考えさせられていることが原因です。設計書は制約ではなく、AIが最速で動くための地図です。
次のアプリを作るとき、まず10分でいいので設計書のドラフトを作ってからAIに渡してみてください。その違いはすぐに体感できます。
12年の個人開発で見えてきたこと
リリース直後にチェックしているもの
- クラッシュレポートの上位エラーを24時間ごとに確認しているか
- AdMob/StoreKit の収益ダッシュボードに異常検知が出ていないか
- ユーザーレビューに技術的な指摘が含まれていないか