提案資料も要件定義も、Claude Codeに”生成”させる｜上流工程をどこまで任せられるか（実践編②）

AIの業務活用というと、記事を書く、要約する、といった”下流”の話に寄りがちです。ですが、Claude Codeを本気で業務に組み込んでみて、いちばん効き目が大きかったのは案件の”上流”——ヒアリング、要件定義、設計、提案づくりのほうでした。ここは手戻りが多く、担当者の力量で質がぶれやすく、その出来が、プロジェクト全体の成否をほぼ決めてしまう領域です。

この記事では、上流の成果物を“どこまでClaude Codeに生成させられるか”を、実際の手順に沿って見せます。役割の置き方はシンプルで、Claude Codeが生成し、人はディレクション——何を作るかの方向づけと、最後の事実確認・判断——に回る。登場する会社名・数値・やり取りは、すべて匿名化した架空の合成データです。持ち帰ってほしいのは、個別の事例ではなく、その下にある型と手順のほうです。

先に、この記事を貫く見方をひとつだけ置いておきます。上流の成果物の質を決めるのは、AIがどれだけ賢いかではありません。こちらがどんな”型”を渡すか、です。生成はAIの仕事ですが、質のほうは、渡す側が設計する。以降の手順は、その「型」をどう仕込むかの話です。

なぜ上流こそ”使いこなし”が効くのか

下流の作業——たとえば記事を1本速く書く——は、確かに時短になります。ですが、効き目はその1本で閉じます。一方、上流の曖昧さは下流のすべてに波及します。要件の1行が抜けていれば、設計・実装・テスト・検収の全工程がその抜けを引きずり、しかも発覚するのはたいてい後工程です。プロジェクトが炎上する原因の多くは、実装の巧拙ではなく、上流で決めきれなかった曖昧さ——要件の抜け漏れ、認識のズレ、提案時点での論点不足——にあります。

裏を返せば、上流をClaude Codeで一気に形にできると、レバーがとても大きい。抜けを早い段階で炙り出し、認識を文書で揃え、叩き台を数十秒で出す。手が動く前に「何を作るか」がくっきりし、後工程の手戻りが目に見えて減ります。下流を10分速くするより、上流の抜けを1個つぶすほうが、案件全体では効くのです。

もうひとつのコツは、上から下まで同じ文脈を共有したまま一本で回すことです。顧客の状況、過去の提案、自社の型——これらをClaude Codeが把握した状態を保てば、議事録から要件、設計、提案までが地続きになり、途中で文脈が切れて言い直す無駄が消えます。人が握るのは「何を作るか」の方向づけと、最後の事実確認・判断だけ。手を動かして書く役割から、方向を決めて確かめる役割へ、立ち位置が移ります。

実践①：議事録やSlackを”渡すだけ”で、要件に構造化させる

いちばん手前の工程から始めます。商談の議事録や、Slackで交わしたヒアリングのやり取りは、たいてい時系列の”生ログ”のまま放置されます。話題は行ったり来たりし、決まったことと未確定が同じ画面に混ざり、読み返すのが億劫な状態です。ここを片づけるのは、Claude Codeにいちばん向いた仕事のひとつです。

やり方そのものは拍子抜けするほど単純で、整形しないまま丸ごと貼るのがコツです。「発言者A：〜」「発言者B：〜」の生ログでかまいません。むしろ、人が先に要約してしまうと、そこで捨てた情報は二度と戻ってきません。言い淀みも脱線も含めて全部渡し、構造化のほうをClaude Codeに任せる。ただし、任せ方に一手だけ工夫が要ります。「まとめて」と自由記述で頼むのではなく、出力の”型”を先に指定する——受け皿の枠を決めてから注ぐ、という順番です。

なぜ、わざわざ枠を先に決めるのか。狙いは、抜けを「空欄」として目に見えるようにすることにあります。5つの枠を用意しておけば、たとえば非機能要件が一つも埋まらなかったとき、その空欄自体が「性能や運用の話を、ヒアリングでまだ詰めていない」という発見になる。逆に、枠を決めず「まとめて」と頼むと、この空欄は現れません。Claude Codeは手元の情報でそれらしく整った要約を返し、こちらは埋まった部分の見栄えに満足して、そもそも聞けていない領域を見落とします。——同じAIでも、渡す型ひとつで、返ってくるものの質が変わる。効いているのは賢さではなく、型のほうです。

そのうえで、もう一問だけ加えます。「いま構造化した内容のうち、互いに矛盾する点と、まだ確定していない点だけを、別枠で挙げてください。次回の打ち合わせで潰すべき論点として」。この一問が、地味に効きます。生ログには、前半で「予算は抑えたい」と言い、後半で「機能は全部ほしい」と言う、といった噛み合わない要望がよく紛れています。人が読むと、文脈で自然に辻褄を合わせて読み飛ばしてしまう矛盾を、Claude Codeは律儀に拾い上げる。ここまで、文字どおり”渡すだけ”で数分。人はまだ一文字も書いていないのに、次に詰めるべき論点の一覧が、もう手元にあります。

ただし、落とし穴もあります。構造化は、あくまで”貼ったログの中身”しか映しません。ヒアリングで聞けていないことは、当然、空欄か「未決事項」に落ちる。つまりこの工程は、ヒアリングの穴を埋める魔法ではなく、穴がどこにあるかを教えてくれる装置です。空欄を見て「ここは次回聞こう」と動くのは、あくまで人の仕事。ここを取り違えて、空欄までAIに埋めさせてしまうと、この後で出てくる”綺麗な嘘”が生まれます。

実践②：要件定義書を”書かせる”――抜け漏れも自分で埋めさせる

構造化した論点がそろったら、次はClaude Codeに要件定義書そのものを生成させます。考え方は①と同じで、いきなり「要件定義書を書いて」とは丸投げしません。構成の型と、”自己補完”の指示をセットで渡す——質を決めるのは、この二枚の型のほうです。

この指示には、効き目のちがう型が二つ埋め込まれています。ひとつは機能要件にIDを振らせること。FR-012といった採番をしておくと、後工程——設計・見積もり・テスト——で「FR-012の画面」と一意に指し示せて、話が噛み合います。人手だと面倒で飛ばしがちな作業ですが、機械はいやがりません。もうひとつは「経験豊富なPMの視点でセルフレビューさせる」こと。同じClaude Codeでも、「書く」モードと「PMとして抜けを探す」モードでは、出てくるものが変わります。前者のままだと初稿は抜けがちですが、後者に切り替えた瞬間、自分が書いたばかりの文書に足りない観点を、自分で足してくる。

どんな観点が補われるのか。架空の在庫システムを例に、初稿で抜けやすい典型を並べておきます。

出てくるのが、これです。非機能要件やスコープの境界まで埋まった要件定義書が立ち上がります。——ここが分かれ目です。埋まっていることと、正しいことは、まったく別物です。セルフレビューが減らせるのは「観点の抜け」であって、「その数値が、この顧客の実態に合っているか」までは保証しません。同時アクセス数の「50」も、応答時間の「2秒以内」も、Claude Codeが場を埋めるために置いた仮の値にすぎません。

だから、ここからは人がレビュアーであり、ディレクターです。生成された数値と前提のひとつずつに「これは仮」の印をつけ、顧客に当てて確かめる。見るべきは体裁ではなく中身で、押さえどころは三つに絞れます。この要件で顧客の課題に本当に答えているか。仮置きの数値は、実態に合っているか。そして「今回やらないこと」が、はっきり書いてあるか。この三つだけは、どれだけ型を仕込んでも、AIには委ねきれません。型が連れて行くのは”抜けのない初稿”まで。実態に合っているかの一線は、人が引くしかありません。

実践③：要件から、画面モックとシーケンス図まで出させる

要件がある程度固まったら、設計の叩き台もClaude Codeに出させます。狙いははっきりしていて、認識のズレを、いちばん安い場所で表面化させるためです。文章の要件は、顧客には存外に読みにくい。絵にした瞬間、「思っていた画面と違う」が一気に噴き出します。手戻りのコストは、工程が下がるほど跳ね上がる。だから、ズレはできるだけ手前で、絵にして釣り上げるわけです。

まずは認識合わせ用の画面モック、ワイヤーフレームから。要件のうち画面に関わる部分を指して、簡単なHTMLのモックを出させます。

ワイヤーフレームは、作り込まないことがむしろ利点です。色や余白まで整えると、顧客はとたんに見た目の議論を始めてしまう。項目の過不足と画面遷移を確かめたい段階では、白黒の箱で十分——というより、そのほうがいい。「入庫登録の画面に、ロット番号の欄は要るのか要らないのか」。この段階で交わしたいのは、まさにそういう会話です。凝ったデザインは、要件が固まってからで遅くありません。

続いて、主要な動線のシーケンス図。ここは、テキストで図を記述できる記法を使って出させます。テキストなら、後から「この矢印を1本足して」といった修正も差分で回せて、版管理とも相性がいい。画像で受け取ってしまうと、この差分の効きが消えます。

たとえば「入庫登録の流れをシーケンスにして」と頼めば、要件から設計の叩き台が数十秒で出ます。利用者・画面・サーバー・在庫データベースのあいだで、何が、どの順にやり取りされるか。人はそれを見て「この動線でいい／ここはちがう」を判断する。ゼロから描くより圧倒的に速いうえに、図にすると要件の穴が見えます。「登録が失敗したときの戻り先が描かれていない」——文章では気づけなかった例外系の抜けが、矢印の途切れとして目に飛び込んでくる。文章は読み飛ばせても、途切れた矢印は読み飛ばせません。

レビューの観点は、二つに絞ると速く回ります。ひとつは動線の正しさ——この順序で、実際の業務が回るか。もうひとつは網羅性——正常系だけでなく、失敗・キャンセル・重複といった分岐まで描けているか。前者は顧客に当てないと分かりませんが、後者は自分たちで潰せる。この分担を決めておくと、レビューが迷わず進みます。

実践④：提案の骨子・スライド・見積もりまで

提案も、“構成の型”を先に決めておけば、要件を流し込むだけで骨子とスライドの叩き台が出ます。型とは、たとえば「現状の課題→あるべき姿→打ち手→スコープ→体制→スケジュール→費用→期待効果」といった、自社の提案の背骨のことです。これを設定ファイル（CLAUDE.md）に一度書いておけば、案件ごとに構成をゼロから考え直さずに済む。効いているのは、AIの発想力ではなく、固定した型のほうです。

骨子が出たら、スライド1枚ずつの見出しと要点まで展開させます。ここで人が見るのは体裁ではなく、ストーリーが通っているか——「この順番で、相手は本当に納得するか」です。個々のスライドの見栄えは型が担保してくれるので、人は論の運びだけを見ればいい。順序を入れ替える、1枚足す、1枚削る——この判断は、相手の関心や決裁の力学を知っている人にしかできません。

費用の見積もりも、同じ要領です。要件のスコープに沿って作業項目を分解し、単価×工数で積み上げさせます。

粒度は、「作業項目 × 想定工数（人日）× 単価」まで割るのが目安です。粗すぎる”一式”の見積もりは、後で必ず「これは含まれているのか」でもめます。かといって細かすぎても、読む側が疲れるだけ。ちょうどいいのは、実践②で機能要件に振ったIDに、作業項目を紐づける粒度です。こうしておくと「どの要件に、いくらかかるのか」が追え、スコープが増減したときの金額の説明も一気に楽になる。②でIDを振らせた一手が、ここで回収されるわけです。

ただし——工数の数字そのものは、Claude Codeの出した値を鵜呑みにはしません。「この規模なら10人日」といった見積もりは、しょせん一般論の当てずっぽうです。自社の実績と生産性で、必ず上書きする。型が担保するのは”抜けのない項目立て”であって、”正しい工数”ではないからです。そして工数の次に人が握るべきが、提案でいちばん危ない数字——効果試算です。ここは章を改めます。

数字は”盛らせない”――ここだけは人が握る

ここまで上流をずいぶん任せてきましたが、唯一、任せきりにしてはいけないものがあります。効果試算の数字です。Claude Codeは、頼めば景気のいい数字を、実にもっともらしい顔で出してきます。「導入で作業時間◯％削減」「年間◯百万円のコスト圧縮」——それらしい根拠まで添えて。ところが、その根拠をたどっていくと、たいていどこにも出典がありません。AIは、数字そのものより、数字の”雰囲気”を作るのが、とびきり上手なのです。

どこで盛られるのか、が分かっていれば防げます。典型は三つ。まず、削減率を都合よく置く——「手作業が9割減る」の9割に、根拠がない。次に、単価や件数を大きめに仮定する——時給や月間処理件数を高めに置いて、効果を膨らませる。そして、一度きりの効果を、毎年繰り返す前提にする——初年度だけの削減を、そのまま5年分に掛けてしまう。どれも、前提をひとつ甘くするだけで、試算はいくらでも大きくできる。しかも文章としては自然に流れるので、読み飛ばすと気づけません。

だから、指示の段階で先に釘を刺します。「前提は必ず数字の横に明記して。削減率や単価は、保守・標準の2シナリオで幅を持たせて。出典のない数字は”仮”と明記して」。前提を数字に貼りつけさせるだけで、盛りは驚くほど減ります。そのうえで——

——出てきた試算は、人がひとつずつ検算します。やることは三つだけです。まず前提を疑う——この削減率・単価・件数は、この顧客で本当に成り立つのか。次に出典を確かめる——根拠が「一般にそう言われる」なら、それは根拠ではありません。最後に掛け算を追う——前提が正しくても、積の途中で桁が飛んでいないか。この三点を通らない数字は、提案に載せない。単純ですが、ここを省くと、後で必ず痛い目を見ます。

なぜ、ここだけこれほど厳格にするのか。誇張した提案は、受注した瞬間に、自分たちの首を絞めるからです。「◯％削減します」と約束して受注すれば、その数字はそのまま検収の基準に化けます。だから、生成はAI、数字の分別は人——ここははっきり分ける。速く出すことと、確かめずに出すことは、まったく別の話です。

使いこなしのコツ――”渡すだけ”でここまで出るのは「型」があるから

ここまで「議事録を渡すだけ」「要件を入れるだけ」と繰り返してきました。種を明かすと、“渡すだけ”で望む形が出るのは、事前に「型」を仕込んであるからです。型がなければ、同じ指示でも、出力は毎回ばらつきます。料理でたとえるなら、AIの賢さは料理人の腕、型はレシピと仕込みです。腕がよくても、分量も段取りも決まっていない厨房では味は日によってぶれ、逆にレシピと仕込みが揃っていれば、誰が立っても一定の水準に届く。効いてくるのは腕（賢さ）ではなく、仕込み（型）のほう。ここが、使いこなせる人とそうでない人の分かれ目です。

型の中心は、設定ファイル（CLAUDE.md）です。提案の構成、要件定義の観点（機能・非機能・制約・前提・未決）、ブランドのトーン、そして「数字は盛らない」「顧客名は必ず匿名化する」といった方針までを、ここに一元化します。案件ごとに指示し直すのではなく、どの案件でも同じ前提から立ち上がる土台をつくる。地味な作業ですが、これがいちばん効きます。

次に、過去の良い成果物を、リファレンスとして一緒に渡すこと。よくできた要件定義書や提案書を1〜2本、お手本として添えるだけで、トーンと構成がそれに揃います。「型」を言葉で説明し尽くすより、良い実物を1つ見せるほうが速い。担当が代わっても、成果物の水準がぶれにくくなります。このあたりは、実践編の別記事（スキルの部品化）でも詳しく触れています。

さらに一歩進めれば、渡す手間そのものを減らせます。ヒアリングのデータ源をMCPでつないでチャットやドキュメントを直接参照させる、競合・市場の下調べはサブエージェントに並列で当たらせる、毎回繰り返す工程はスキルとして部品化する——といった具合です。ただし、これらはすべて”型が固まってから”の話です。型のないまま自動化すると、ばらついた出力を、ただ高速に量産するだけになる。順番は、型が先、自動化が後。ここを逆にしないのが、遠回りに見えていちばんの近道です。

落とし穴――”綺麗な嘘”と、前提のブレと、鵜呑み

最後に、この回し方で実際にハマる所を三つ、正直に共有します。

ひとつめは、ヒアリング不足のまま生成した”綺麗な嘘”。Claude Codeは、情報が足りなくても、それらしい要件定義書を最後まで書き上げてしまいます。空欄を残すより、仮の値で埋めるほうが、文章としては自然になるからです。結果、体裁は完璧なのに、中身は聞けていない推測という文書ができあがる。全問を埋めた答案は、たとえ間違っていても、空欄だらけの答案より誤りを見つけにくい——これがいちばん危ない。対策は、実践①に戻ります。「未決事項」を必ず別枠で出させ、仮置きの数字には「仮」の印を残させる。綺麗に埋まった文書ほど、どこが”聞けた事実”で、どこが”仮”なのかを、疑ってかかる。

ふたつめは、前提を固定しないことによるブレ。同じ案件でも、指示のたびに前提が揺れると、要件・設計・見積もりが少しずつ食い違っていきます。「さっきは同時50ユーザー前提だったのに、見積もりでは100になっている」といった具合に。口頭で回した前提は、伝言ゲームのように、工程を渡るたびに少しずつ形を変える。防ぐ手は単純で、前提を1か所に固定しておくことです。設定ファイルや案件ごとの前提メモに「確定した前提」を書き、以降はそれを参照させる。前提は口頭ではなく、文書で握る。この記事でいう「型」とは、煎じ詰めれば、この「固定した前提」のことです。

みっつめは、生成物を鵜呑みにすること。叩き台が数十秒で出てくる快感は、そのまま「確かめずに出してしまう」誘惑に変わります。ですが、Claude Codeが出すのは“型の整った初稿”であって、”検証済みの最終稿”ではありません。数字は仮、要件は推測混じり、動線には例外の抜け。これらを人が一つずつ潰して、はじめて提案として世に出せます。速く出ることと、確かめずに出すことを混同しない——これが、上流をAIで回すときの、最後の砦です。

まとめ：人は”ディレクター”、Claude Codeが”生成”する

上流までClaude Codeに生成させると、手戻りが減り、案件全体の回り方が変わります。鍵は、最初から一貫した役割分担です。Claude Codeが議事録から要件定義書・設計・見積もりまで生成し、人は「何を作るか」の方向づけと、最後のチェック——事実・数字・判断——に集中する。そしてその成否を分けるのは、AIの賢さではなく、こちらが渡す型のほうです。

始め方は、拍子抜けするほど簡単です。まず、いつもの議事録を1本、Claude Codeに渡して「機能・非機能・制約・前提・未決の型で構造化して」と頼む。空欄が見えたら、それが次に聞くべきことです。その一歩さえ踏み出せば、任せる範囲は驚くほど自然に広がります。

関連ガイド（実践編シリーズ）

• 実践編①：Claude Codeで自社のマーケ分析を回した全記録
• 1人マーケ運用：業務をスキルに部品化しGitHubで共有
• AI認証・データ連携のセキュリティレビュー

よくある質問（提案・要件定義のAI活用）