営業提案書をClaude Codeで作る全工程｜4〜5時間を30〜45分にした工程設計
目次
「明日の商談の提案書が、まだ白紙です」。
営業の現場でいちばん削られている時間は、たいてい商談そのものではありません。1社ごとの提案書とスライドを作る時間です。相手のことを調べ、課題の仮説を立て、構成を組み、スライドに落とし、話す順番を決める——真面目にやれば1本で半日が消えます。だから多くの会社は、社名だけ差し替えた汎用資料を持って商談に行くことになります。
当社は、この工程をClaude Codeで組み直しました。提案書1本あたりの実測目安は4〜5時間から30〜45分（Claude Code導入支援に掲載している当社の実測目安です）。ただし「AIに丸投げしたら提案書が出てきた」わけではありません。うまくいったのは、1本の提案書を6つの工程に割り、それぞれに別の指示と検証を置いたからです。
この記事では、その工程設計を当社の運用そのままで公開します。うまくいった部分だけでなく、実際に壊れた4つの落とし穴と、AIに渡してはいけない工程も書きます。
この記事の要点
- 提案書づくりで時間を食っているのは執筆ではなく、リサーチと構成の意思決定。ここを分解しないと自動化は効かない
- 当社は1本を6工程に割っている。特にリサーチは3方向に分けて並列で走らせると、深さが目に見えて変わる
- 提案書の順序は固定する。商品説明を「原因」より前に出すと、商談は値引き交渉になる
- スライドは感性で作らない。1枚1メッセージ・105文字以内・24pt以上のように、機械的に決められる制約へ翻訳する
- 実測目安は提案書4〜5時間→30〜45分。ただしキーメッセージと課題の芯は人が決める工程として残している
提案書づくりで時間を食っているのは「書く」工程ではない
まず前提の整理です。1社向けの提案書を作る作業を工程に分解すると、こうなります。
| # | 工程 | 実際にかかる時間の感覚 | 自動化の相性 |
|---|---|---|---|
| 1 | 相手企業・業界・競合のリサーチ | 1〜2時間。ここが最も重い | 良い。ただし出典の確認は人が要る |
| 2 | 課題の仮説づくり（何を刺すか） | 30分〜。ここで提案の勝負が決まる | 補助まで。採否は人の判断 |
| 3 | 提案書の構成を組む | 30分。毎回悩むが、実は型がある | 型を固定すれば自動化できる |
| 4 | 本文・スライドの文章を書く | 1時間 | 相性が良い |
| 5 | スライドのデザイン・体裁 | 1時間。地味に長い | 制約を数値化すれば自動化できる |
| 6 | 話す順番・時間配分を決める | 30分。前日に慌てる部分 | 文字数で機械的に検証できる |
多くの人は「4を自動化したい」と考えます。しかし表を見ればわかるとおり、時間を食っているのは1と2、そして地味に5です。文章を書く時間はもともと全体の2割程度しかありません。
だから「提案書をAIに書かせる」という発想だと、体感の削減は思ったほど出ません。効くのは、1〜6を別々の作業として扱い、それぞれに違う指示を与えることです。この「工程に割る」考え方は、当社がnote運用を自動化したときにも同じ形で効きました。
当社の工程分解｜1本の提案書を6ブロックに割る
結論から言えば、当社は会社名を入力すると6つの工程が順に走る形にしています。1つの巨大な指示で「提案書を作って」とやらないことが、品質が安定した最大の理由です。
| # | 工程 | 出力物 | 人の関与 |
|---|---|---|---|
| 1 | 商談の前提を決める | 初回か2回目か／参加者／論点の仮説 | 人が決める |
| 2 | リサーチ（3方向・並列） | 企業・業界・競合の調査メモ（出典URL付き） | 出典の確認 |
| 3 | 課題の芯を1つに絞る | 仮説3本（重要性×緊急性つき） | 採否を人が決める |
| 4 | 提案レポート | 提案書本体（Markdown＋Word） | キーメッセージの承認 |
| 5 | トーク台本 | 話す順番と時間配分（7分以内） | 読み合わせ |
| 6 | スライド化 | PPTX（構成と1対1対応） | 目視QA |
工程を分けたことの実利は3つありました。
1. 途中で失敗しても全部やり直しにならない。 リサーチが薄ければ1だけ、話す順番が悪ければ4だけ差し替えられます。1本の長い指示だと、気に入らない箇所が1つあるだけで最初から作り直しになります。
2. 工程ごとに検証を置ける。 「出典URLが付いているか」「台本が1,800〜2,000字に収まっているか」のように、工程ごとの合格条件は具体的に決められます。全体を眺めて「なんとなく良い」と判断するより、はるかに再現性が出ます。
3. 人が入る場所が固定される。 どこを見ればいいかが決まっているので、確認が5分で終わります。
リサーチは「3方向・並列」に分けると深さが変わる
提案の質を決めるのは、ほぼここです。当社はリサーチを1本の調査として投げず、3方向に分けて同時に走らせています。
| 方向 | 調べる対象 | この方向がないと起きること |
|---|---|---|
| A. 相手企業そのもの | 事業・規模・組織・直近のニュース・AI活用の現況・商談相手の経歴 | 会社概要の引き写しで終わる |
| B. 相手のお客様と競合 | 相手の顧客が抱える課題、競合3〜5社の動向、業界の人手不足の統計 | 「御社の課題は人手不足ですね」で止まる |
| C. 自社側と市場環境 | 自社が提供できること・できないこと、他の選択肢との住み分け、1〜3年後の環境 | 比較検討で負ける／価格勝負になる |
分けて走らせる理由は単純です。ひとまとめに「この会社を調べて」と頼むと、出力の大半がAの会社概要で埋まります。Bがないと提案が一般論になり、Cがないと「他社と何が違うのか」に答えられません。
そして、この工程で守っているルールが2つあります。
- 出典URLのない情報は使わない。 確度が低いものは「〜と推察されます」と明示し、断定しない
- 調査の合格ラインは「そこまで調べてくれたのか」と相手に言われる深さ。断片情報の羅列ではなく、相手が前のめりになる洞察を1つ用意する
2つ目は数値化できない基準ですが、これがあると出力の粒度が変わります。「調べる」ではなく「驚かせる」を目的として書くだけで、AIは表面情報の列挙をやめます。
提案書の順序は固定する｜商品説明を先に出すと値引き交渉になる
構成を毎回考えるのをやめました。当社は9ブロックの順序を固定し、そこに中身を流し込む方式にしています。
| # | ブロック | 役割 |
|---|---|---|
| 1 | 表紙・テーマ | キーメッセージを一文で宣言する |
| 2 | 目的・理想 | 相手が目指す姿を、こちらから言語化する |
| 3 | 現状・問題 | 理想とのギャップ。ここでは解決策を出さない |
| 4 | 原因 | ギャップが生まれる構造的な理由 |
| 5 | 解決策 | ここで初めて自社を出す。特長は3つに絞る |
| 6 | 実現性の証明 | 事例・シミュレーション |
| 7 | 競争優位点 | 機能列挙ではなく「相手の課題に合う点」だけ |
| 8 | 見積・料金・条件 | 条件を明確に |
| 9 | まとめ・クロージング | 2の「目指す姿」に戻る。次の一歩を置く |
この順序で最も重要なのは、5（解決策）を4（原因）より前に出さないという点です。原因の共有がないまま商品説明を始めると、相手の関心は「それはいくらか」に移り、商談は値引き交渉になります。逆に4で「なぜこうなっているのか」が共有できていれば、5は解決策として聞かれます。
もう1つ、キーメッセージは3段階で磨きます。
| 段階 | 例 |
|---|---|
| 汎用（弱い） | AI導入支援のご提案 |
| 具体（まだ弱い） | 提案業務の工数を削減するAI導入のご提案 |
| ビジョン（採用） | 「提案の速さ」で、勝てる商談を取りこぼさない会社へ |
表紙とレポートで同じキーメッセージに統一するところまでを1つの工程にしています。ここはAIに候補を出させ、選ぶのは人にしています。
スライドは感性で作らない｜制約を数値に翻訳する
スライド生成が安定しなかった時期の原因は、指示が「見やすく作って」だったことでした。デザインの良し悪しをAIに判断させると、毎回違うものが出てきます。 そこで、守ってほしいことをすべて数値と禁止事項に翻訳しました。
| 項目 | 決めた制約 |
|---|---|
| 1枚の情報量 | 1スライド1メッセージ・105文字以内 |
| フォントサイズ | 24pt以上（補足のみ14〜16pt） |
| 色 | ブランド3色のみ（アクセント／ダーク背景／CTA） |
| アイコン | 1枚に3つ以内。矢印は5つ未満 |
| 余白 | スライド端から0.8インチ以上 |
| 図表 | ネイティブ図形で描く（後述） |
| 目次スライド | 作らない |
| 構成ラベル | 「課題提起」「Step1」等の内部ラベルは表示しない |
数値にした効果は明確でした。「105文字以内」と決めると、AIは自動的に文章を削ってスライドらしい密度にします。「24pt以上」と決めると、詰め込みが物理的に不可能になります。体裁の判断を人が毎回やらなくて済むのが、実は最大の時短でした。
そして台本は文字数で管理します。実質の読み上げ1,800〜2,000字が7分（約320字/分＋質疑）という基準を置き、生成後に文字数を数えて検証します。「短めに」という指示は効きませんが、「1,900字」は効きます。
実際につまずいた4つの落とし穴
きれいに動くまでに壊れた箇所です。同じ順番で踏むはずなので、先に書いておきます。
1. 軽量モデルに長文の日本語を任せると、字が壊れる。
コストを下げようと軽いモデルに長文の流し込みをさせたところ、簡体字が混ざる・誤変換が出るという壊れ方をしました。提案書は誤字1つで信用を失う書類です。当社は長文の日本語生成は上位モデル、短文や機械的な操作は軽いモデルと用途で分けています。ここを節約してはいけません。
2. 図をSVGで描くと日本語がボケる。
スライド内の図をSVG画像として貼ると、日本語のテキストが滲みます。解決策は、図をスライドのネイティブ図形として描かせることでした。四角と線と文字で組めば、拡大しても崩れません。
3. 生成しただけでは崩れに気づかない。
ファイルが出力されると「できた」と思ってしまいますが、実際には文字がはみ出していたり、要素が重なっていたりします。当社はPPTXをPDF経由で画像に変換し、目視で確認する工程を最後に固定しました。作る工程と検証する工程は分けるべきです。
4. 台本とスライドの枚数がずれる。
別々に作ると、台本は9つの話題、スライドは12枚のような状態になります。「台本の各ブロックとスライドを1対1で対応させる」と明示し、枚数を数えて検証する形にしました。
何をAIに渡し、何を人が決めるか
仕組みを回してきたなかで、人の工程として残しているものがあります。手放さないほうが結果が良かった部分です。
- 誰に何を売るか、キーメッセージをどれにするか。 候補はAIが出しますが、選ぶのは人です。ここを譲ると提案が平均的になります
- 課題の芯（インサイト）の採否。 仮説は3本出させますが、「これは違う」と落とす判断は人がやります
- 数字の扱い。 成果は「目安」と書き、保証はしない。断定的な数値保証は書かないというルールを工程に埋め込んでいます
- 出典のない情報を落とす。 相手企業についての推測を事実として書かない
逆に、迷わず渡してよかったものは、リサーチの一次収集、決めた順序への流し込み、体裁の適用、文字数の検証、ファイル形式の変換です。要するに「判断のない作業」は全部渡していい。判断が残る工程だけ人が見る、という切り分けが結論でした。
実測｜提案書は4〜5時間から30〜45分に
当社が営業・マーケ業務で実測している目安です（Claude Code導入支援に掲載しているものと同じ数字です）。
| 業務 | 従来 | 現在 |
|---|---|---|
| 提案書の作成 | 4〜5時間 | 30〜45分 |
| 月次のデータ集計 | 3.2時間 | 14分 |
| リード・企業リサーチ | 1社30分 | 数分 |
| 商談後の議事録→お礼メール | 30分 | ほぼ0分 |
ただし、正直に書いておくべき限界が2つあります。
1つ目は、型がない会社ではこの数字は出ないこと。 30〜45分で終わるのは、提案書の順序・スライドの制約・台本の長さがすべて決まっているからです。型を決める作業のほうが本番で、そこには手作業で何本か作った経験が必要です。工程を割ろうにも、割る対象の型がなければ割れません。
2つ目は、提案の質は工程では決まらないこと。 深いリサーチと固い構成があっても、刺す課題を間違えれば商談は進みません。時間が空いた分をどこに使うか——当社の場合は、それは商談前の仮説を練る時間になりました。自動化の成果は「浮いた時間の使い道」で決まるというのが、運用してきての実感です。
よくある質問
Q. 提案書の作成は完全に自動化できますか？
作業としてはできます。ただし当社は完全自動にしていません。キーメッセージの選択と、刺す課題の採否は人の工程として残しています。おすすめの順序は、まず手作業で5〜10本作って自分の型を言語化し、それを工程に落とすことです。型のないまま自動化すると、平均的な提案書が速く出てくるだけになります。
Q. エンジニアでなくても同じ仕組みは作れますか？
作れます。当社の仕組みも営業・マーケ側の人間が組んだものです。必要なのはプログラミングの知識ではなく、自分の仕事を工程に分解して、各工程の合格条件を言葉にする力です。むしろ普段その業務をやっている人でないと、合格条件が書けません。
Q. パワポ（PPTX）まで生成できますか？
できます。当社はスライド生成を独立した工程にして、台本の各ブロックと1枚ずつ対応させています。重要なのは生成そのものより、出力後に画像化して目視確認する工程を必ず置くことです。文字のはみ出しや要素の重なりは、ファイルを開くまで気づけません。
Q. AIが作った提案書だと相手に伝わりませんか？
伝わるかどうかを決めるのは、生成手段ではなく中身の深さです。実際に効いたのは、相手の顧客と競合まで調べる工程を分けて置いたことでした。逆に、社名だけ差し替えた汎用資料は手作りでも伝わりません。「そこまで調べてくれたのか」と言われる深さが合格ラインです。
Q. 情報漏洩が心配です。相手企業の情報を入力して大丈夫ですか？
入力してよい情報の線引きを、仕組みを作る前に決めるべきです。当社の導入支援でも、対象業務の設計と同時に利用ポリシー（何を入れない・どのプランを使う）を整えるところから着手しています。順序を逆にすると、後から使用禁止になって全部作り直しになります。
Q. どの業務から手をつけるのが効果的ですか？
時間を奪われていて、かつ判断が少ない定型業務からです。提案書・商談準備・企業リサーチ・議事録からのフォロー・レポートあたりが典型です。判断が多い業務から始めると、確認の手間が削減分を食い潰します。費用感や支援タイプの違いはClaude Code導入支援の費用相場と選び方にまとめています。
---
執筆・監修：佐々木 優希（AIリモートワーカー代表／上場企業 営業統括 兼 AI責任者）。本記事の工程設計・落とし穴・削減の目安は、すべて当社の自社運用記録および公開している実測目安に基づきます（2026年8月時点）。