claudeで粗い企画書を要件定義に変える
AIでコードを書くのが、当たり前になりました。
実装のスピードは、もう別次元です。
じゃあ、開発の「詰まりどころ」はどこへ行ったのか？
答えは、上流です。
つまり、企画と要件定義。
この記事では、粗い企画書を「そのまま実装できる要件定義」に変えるやり方を紹介します。
この記事でわかること
なぜAI時代に、上流がボトルネックになるのか
粗い企画書を要件定義に変える「5つのステップ」
今日から使える、AIの精度を上げる企画書テンプレート
1. 実装は速くなった。で、ボトルネックはどこへ？
こんな場面、見覚えありませんか。
企画会議で、こんな声があがります。
「しばらく使ってないユーザーに、リマインドを送りたいね」。
いいアイディアです。
でも、開発に持っていくと、こう返ってくる。
「いつ送りますか？ 誰に？ 何回まで？」
「……それだけじゃ、作れません」。
アイディアはある。
なのに、検証もできないし、形にもできない。
このすれ違いが、いまいちばんの詰まりどころです。
実装が速くなったぶん、「何を作るか」を決める工程の遅さが、余計に目立つようになりました。
どれだけAIが速くても、要求が曖昧なままだと、その速さは空回りするんです。
2. なぜ上流は、AIに丸投げできないのか
AIには、はっきりした得意・不得意があります。
AIが得意なこと
ゴールが明確な作業
お題を与えられた調査・要約
機能要件・定型実装
AIが苦手なこと
ゴールが決まっていない作業
漠然とした議論
正解のない意思決定・非機能要件
そして上流でやることは、ほとんどが「苦手なほう」に集中しています。
粗い企画書って、たいてい背景・課題・目的までは書けています。
問題はその先です。
実装する人が本当に困るのは、
境界ケース・計算ロジック・状態遷移・権限・請求の単位。
ここが、まるごと抜けている。
じゃあ、この状態でAIに「いい感じに要件定義して」と頼むと、どうなるか？
AIは、抜けている部分をもっともらしく推測で埋めます。
その結果、一見それっぽいのに、肝心なところが的外れな要件定義書ができる。
これがいちばんマズいパターンです。
だから、目指すのは「AIに全部決めさせる」ことじゃありません。
決めないと先に進めない論点を洗い出して、人間に返す。
判断は、人がやる。
ここが、いちばん大事な考え方です。
3. 解決の型：AIが草案、人が意思決定
やり方はシンプルです。
AIが草案を出す → 人が判断する → AIが作業する → 人が結果を見る。
AIが高速でたたき台を出す。
人は、そのつど「ここはこう」と決める。
このループを回すだけです。
ポイントは、役割をきっぱり分けること。
手を動かして選択肢を並べるのはAI。
どれを選ぶかを決めるのは人。
この線引きがあいまいだと、AIの速さも人の判断も、どっちも活きません。
では、その中身を具体例で見ていきましょう。
4. 一行の企画を要件定義に変える5ステップ
架空のSaaSで考えます。
企画書には、こう書いてあるとします。
14日間の無料トライアル終了後、自動で有料プランに切り替わる。
たった一行。
ここから要件定義に落としていきます。
Step 1｜理解・構造化
まず、決まっていることとまだ決まっていないことを分けます。
ここで勝手に埋めないのがコツ。
決まっている：トライアルは14日間／終わったら有料化する
決まっていない：課金はいつ始まる？ カード未登録ならどうする？ 事前に通知する？
Step 2｜論点抽出（ここが肝）
チェックリストを当てて、「書いてない・曖昧」なところを拾います。
このチェックリストは、たとえばこんな観点を集めたものです。
💰 お金：請求の単位、課金がいつ発生するか、上限・超過、期中の変更、解約・返金
🔑 権限と可視性：誰が何を見られる・操作できるか。機微な情報の扱い
📦 データと境界：上限に達したとき、リセットの起点、タイムゾーン、重複の可否
🔔 通知：いつ・誰に・何を・どの手段で送るか
🔁 移行：すでに使っている人を、どう巻き取るか
🧭 業務フロー：既存の流れのどこに割り込むか。失敗したときの巻き戻し
🛡 非機能：性能・可用性・セキュリティ・拡張性
とくに💰お金と🔑権限は、後で変えると作り直しになりがち。まっさきに疑います。
そして3段階に分ける。
🔴 決めないと作り直しになる
🟡 挙動に影響するけど、後戻りは軽い
⚪ あとで詰められる
しかも、ただ聞くんじゃありません。
「選択肢＋おすすめ案」をセットで出す。
「どうします？」の丸投げはしません。
今回の例だと、こんな論点が出てきます。
🔴 カード未登録のまま期限が来たら？ →移行を止める／猶予期間／機能制限
🔴 課金はいつ始まる？ →最終日の24時？ 翌日0時？ タイムゾーンは？ 日割りは？
🟡 移行前の通知？ →何日前に、誰に、メール？ アプリ内？
🟡 もう試用中の人はどう扱う？
ここで、いったん止まります。
人に決めてもらうためです。
Step 3｜意思決定の反映
決まった🔴を、仕様に反映します。
その場で決まらなかったものは、無理に決めません。
「選択肢＋おすすめ案」のまま「未決事項」として残す。
あとで誰かが判断できる状態にしておきます。
Step 4｜仕様化
決まった内容を、曖昧さゼロの仕様にします。
たとえば、こんな感じ。
状態の移り変わり：`トライアル →〔期限到達〕→ 課金保留 / 有効 / 停止`
計算ロジック：課金開始日を、境界値まで含めた式で
二重処理の防止：同じ移行が2回走らないように
権限：誰が移行を止められるか
Step 5｜成果物化
要件定義書と技術仕様にまとめます。
必要なら、影響範囲の一覧も。
ビフォー → アフター
このワークフローの価値は、ここに全部つまっています。
Before（企画書）
トライアル終了後、自動で有料プランに切り替わる。
After（要件定義の一片）
カード未登録で期限到達 → 移行を保留して「PaymentPending」へ。
7日間は閲覧だけOK、新規作成は不可。7日過ぎたら「Suspended」。
課金開始は、カード登録が終わった翌0時（JST）。
一行の願望が、実装者が迷わない仕様に変わりました。
やらないこと
詳細設計・タスク分解・コードの読み込みは、しません。
出力は要件定義〜基本設計まで。その先の判断材料を残すのが役割です。
5. 精度を上げる“入力テンプレート”
AIの出力の質は、入力の質で決まります。
最初の企画書の粒度が、そのまま結果を左右する。
逆に、背景や目的があいまいなままだと、いくら良いやり方でも精度は落ちます。
なので、そのまま貼って使えるテンプレートを置いておきます。
## 1. 背景
なぜ今これをやるか。きっかけを3〜5行で。
## 2. 課題
何が問題か。誰が困っているか。数字があれば添える。
## 3. 目的・成功指標
達成したいこと。できれば数字で（〇〇を N% 削減 など）。
## 4. 提供内容の概要
どんな機能・プランか。骨格を5〜10行で。
## 5. 未定・要検討事項（任意）
まだ決めきれない項目を、そのまま書く。
## 6. 関連ドキュメント（任意）
見てほしい既存資料のリンク。コツは、ひとつだけ。
埋められないところは「未定」と書く。
AIに勝手に推測されるより、「ここは未定」と書いてあるほうが、ずっと良い出力になります。
とくに、お金・請求の単位・データの見える範囲・境界ケース（上限に達したとき、期中で変えたとき、同時に使われたとき）。
ここは、未定でも“未定と書く”だけで、論点抽出の精度がぐっと上がります。
テンプレを埋める。
それ自体が、AIに正しいコンテキストを渡す第一歩です。
6. 舞台裏：このワークフロー自体、どう作った？
じつはこのワークフローも、一発で書いたわけじゃありません。
最初は、既存スキルの流用でいけると思っていました。
結果は、ダメ。
どれを試しても、上流は速くならない。
気づいたのは、こういうこと。
ツールは「速く作る」を助ける。
でも「何を作るか」は、前提（コンテキスト）と手順がないと始まらない。
だから、遠回りに見えても、自分たちで一から整えることにしました。
やったのは、「上流でAIを活かす」のとまったく同じ手順です。
① AIに渡すコンテキストを整える
実装コードから、API仕様・DBスキーマ・用語集・業務フローを、AIが読めるドキュメントで揃えました。
② サンプルの企画書を用意する
現場にありがちな“粗い企画書”をいくつか集めて、ワークフローを試すテストケースにしました。
③ 論点の炙り出し方を、言葉にする
熟練者が無意識にやっている「お金・権限・境界ケースの疑い方」を、誰でも使えるチェックリストに落としました。
④ スキルとして固定する
手順もチェックリストもテンプレートも、ひとつにパッケージ化。誰が使っても、同じ品質で回るようにしました。
ここまで、だいたい1週間。
意外と、あっという間に動くようになりました。
そこからは、ひたすら磨き込みです。
高品質なAIモデル「Fable」でレビューを繰り返し、AIの精度を上げたり、渡すコンテキストを圧縮したり。
少しずつ、実用のレベルまで引き上げていきました。
教訓は、シンプルです。
「AIに任せる」の前には、必ず人が“コンテキストと手順”を整える作業がある。
そして、この整える作業こそが、AI時代の上流工程の中身になっていきます。
7. 役割は、こう変わる
企画・ディレクションへ
完璧な企画書を、書かなくて大丈夫です。
むしろ、決めきる前の“粗いまま”でいい。
大事なのは、迷っている部分を隠さないこと。
そこから先の詰めは、AIと一緒にやればいいんです。
エンジニアへ
これからは、仕様が固まった“後”ではなく、固まる“前”に呼ばれる立場になります。
出来上がった要件を受け取るのではなく、論点を一緒に潰す側へ。
上流と下流の境界は、これから少しずつ溶けていきます。
8. まとめ
AIは、上流の“意思決定”そのものを代わってはくれません。
でも、論点を高速に洗い出して、抜けを見えるようにして、実装できる要件定義に落とす。
ここを分担できれば、人間は「判断」に集中できます。
それが、AI時代の上流の変わり方だと思っています。
まずは「背景・課題・目的・概要」の4項目で、手元の企画をひとつ書いてみてください。
そのままAIに渡して、「論点を🔴🟡⚪で出して」と頼むだけ。
抜けの多さに、たぶん驚きます。
AI時代に価値が上がるのは、コードを書く力ではなく、“何を作るかを決める力”です。
