Web制作会社の提案書とヒアリングシートをClaude Codeで半分の時間に

金曜の夕方、来週の月曜にコンペがある。要件はSlackに断片的に残っているだけ。営業がヒアリングしたメモはGoogleドキュメントに3ファイル、しかも箇条書きの途中で切れている。

僕はこの状態から、ひとり残業で提案書を組み立てていました。表紙、課題整理、サイトマップ案、スケジュール、見積りの前提条件。深夜2時、ようやく出来上がった提案書を見返すと、ヒアリングで聞いたはずの「採用強化が今期の最優先」という一言がどこにも反映されていない。聞いたのに、拾えていない。

Web制作会社のディレクターなら、この「聞いたのに落とす」感覚に覚えがあるはずです。提案書とヒアリングシートは、作る数が多いわりに、毎回ゼロから書き起こしている人が多い。ここを生成AIに任せると、空いた時間を「提案の中身を磨く」ほうに回せます。今日はその具体的なやり方を、コピペできるプロンプトと検証スクリプトつきで書きます。

この記事の要点

• 提案書とヒアリングシートは「型が決まっている書類」なので、Claude Codeのような生成AIと相性がいい。下書きの7割は任せられる。
• 任せるのは「散らかった情報の整理」と「型に流し込む下書き」。提案の戦略や見積り金額の最終判断は人がやる。ここを混ぜると事故る。
• ヒアリングメモを渡して提案書の骨子を起こすと、僕の手元では1件あたり90分が40分前後に縮んだ。
• クライアントの社名・個人情報を学習に使わせない設定と、情報の渡し方には注意がいる。後半でチェックリストにした。
• コピペで使えるプロンプト雛形、ヒアリングシートのMarkdownテンプレ、提案書の抜け漏れを機械チェックする検証スクリプトを載せた。

読者像：どんなWeb制作会社のディレクターに効くか

想定しているのは、こんな立場の人です。社員5〜30人くらいの制作会社で、ディレクターが営業も兼ねている。月に2〜5件の提案を出していて、コンペや相見積もりも多い。デザイナーやエンジニアは別にいるが、ヒアリングと提案書づくりはディレクターひとりに集中している。

この立場の悩みは、だいたい共通しています。提案の中身で勝負したいのに、書類を整える作業に時間を吸われる。ヒアリングは盛り上がったのに、メモが断片的で後から再現できない。テンプレはあるが、案件ごとに微妙に違うので結局手で直している。

生成AIが効くのは、まさにこの「整える作業」の部分です。提案の発想そのものをAIに丸投げするわけではありません。

Web制作会社の業務フローと、どこに時間が溶けるか

提案までの流れを並べると、時間の溶けどころが見えてきます。

1. 問い合わせ受付・一次返信
2. ヒアリング（対面・オンライン）でメモを取る
3. メモを整理して要件をまとめる
4. サイトマップ・ワイヤーの方向性を決める
5. スケジュールと概算見積りを組む
6. 提案書（スライドまたはドキュメント）に落とす
7. 社内レビューして提出

このうち、3と6が一番のボトルネックです。ヒアリングメモは生のままだと使えないので、整理に時間がかかる。提案書は毎回似た構成なのに、案件ごとの情報を手で流し込むので手戻りが多い。

僕の感覚だと、1案件あたり提案書作成だけで90〜120分。月3件なら、それだけで5〜6時間が「書類整形」に消えていました。

よくある手戻りと困りごと

実際にやらかしたものを正直に並べます。

• ヒアリングの聞き漏らし。予算感と公開希望日を聞き忘れ、提案書を出したあとに「予算オーバーです」と言われて作り直し。
• メモの解釈ズレ。「スマホ対応したい」が、レスポンシブ対応なのか専用アプリなのか曖昧なまま提案して、見積りが2倍ずれた。
• テンプレの使い回しミス。前の案件の社名が表紙に残ったまま提出しかけた。これは本当に冷や汗が出ます。
• 提案書の抜け。保守費用の記載を忘れ、受注後に「月額は聞いていない」とトラブルになった。

これらの大半は、「決まった項目を毎回もれなく埋める」だけで防げます。人間が毎回手でやると抜ける。だから機械に守らせる。

導入前と導入後で何が変わったか

ビフォーアフターを表にします。

項目	導入前	導入後
ヒアリングメモの整理	手で30分かけて清書	AIが5分で構造化、人が確認
提案書の骨子作成	白紙から60分	テンプレに流し込み20分
聞き漏らしチェック	記憶頼み	検証スクリプトで自動チェック
表紙の社名ミス	たまに発生	テンプレ変数化でほぼゼロ
1件あたり合計	90〜120分	40〜60分

戦略を考える時間は減りません。減るのは「整形と確認」の時間だけです。そここそ自動化したかった部分なので、僕にとっては狙いどおりでした。

Use case 1：ヒアリングメモから提案書の骨子を起こす

一番効くのがこれです。ヒアリング直後の生メモを渡し、提案書の章立てに沿った下書きを起こさせます。

Claude Codeなら、ヒアリングメモのテキストファイルをプロジェクトに置いて、そのまま読ませられます。コピペでも動きますが、ファイルを直接読ませるほうが転記ミスが減ります。

下のプロンプトを雛形として使ってください。

あなたはWeb制作会社のディレクターの補助役です。
添付のヒアリングメモを読み、以下の章立てで提案書の下書きを作ってください。

# 章立て
1. お客様の現状の課題（メモから読み取れる範囲で。推測は「推測」と明記）
2. 本プロジェクトのゴール
3. 想定サイトマップ（主要ページのみ）
4. 進め方とおおまかなスケジュール
5. 概算の前提条件（金額は書かず、見積りに必要な前提だけ箇条書き）

# 守ること
- メモに書いていないことは創作しない。不足は「要確認」として末尾にまとめる
- 専門用語はクライアントが読む前提でやさしく言い換える
- 断定しすぎず、提案のたたき台として書く

ポイントは「メモにないことは創作させない」と縛ることです。AIは空欄を埋めたがるので、放っておくと存在しない要件を勝手に作ります。「要確認」に追い出させると、聞き漏らしがそのまま見える化されます。

Use case 2：ヒアリングシート自体を案件ごとに最適化する

ヒアリングシートは固定の質問票を使い回しがちですが、業種や案件規模で聞くべきことは変わります。採用サイトと通販サイトでは、聞く順番も内容も違う。

そこで、案件の概要を渡して質問票を組み替えさせます。

次の案件向けに、初回ヒアリングの質問リストを作ってください。

# 案件概要
- 業種: 歯科クリニック
- 目的: 新規患者の予約増加
- 規模: 10ページ程度のコーポレート＋予約導線

# 出力形式
- 「必ず聞く質問」「できれば聞く質問」に分ける
- 各質問に、なぜ聞くのか（提案・見積りのどこに効くか）を一言添える
- 予算・公開希望日・既存サイトの有無・写真素材の用意は必ず含める

「なぜ聞くのか」を添えさせると、ヒアリング当日にディレクター本人の理解も深まります。新人ディレクターの教育にも使えました。

Use case 3：複数メモの統合と、提案書の体裁チェック

営業・ディレクター・先方からのメールと、情報が複数に散らばっているとき、これを1枚に統合させます。下のチェックリストを提案書の最終確認に使ってください。

• 表紙の社名・案件名が今回のものになっているか
• 予算感、または見積りの前提が書かれているか
• 公開希望日とスケジュールに矛盾がないか
• 保守・運用費用の扱いが明記されているか
• サイトマップと見積りページ数が一致しているか
• ヒアリングで出た最優先要望が反映されているか
• 「要確認」項目が未解決のまま提出されていないか

このチェックは人の目でもできますが、後半で機械チェックする方法を載せます。目視は必ず漏れます。

AIに任せる範囲と、人が必ず判断する範囲

ここを曖昧にすると事故ります。線引きを表にしました。

作業	AIに任せる	人が判断する
メモの整理・構造化	◯	最終確認
章立てに沿った下書き	◯	文脈の補正
質問票の組み替え	◯	当日の深掘り
提案の戦略・差別化の方向性	△たたき台のみ	◎最終決定
見積り金額の確定	×	◎
クライアントへの提出可否	×	◎

金額と提出の最終判断は、絶対に人がやる。AIが出した概算をそのまま客に出すのは、新人に見積りを丸投げして黙って提出させるのと同じです。たたき台までが守備範囲だと割り切ると、安心して使えます。

提案書の抜け漏れを自動でチェックする検証スクリプト

目視チェックは疲れていると漏れます。そこで、提案書のMarkdownを読んで「必須項目が入っているか」を機械的に確かめる小さなスクリプトを置いておきます。Node.jsがあれば動きます。

提案書をMarkdownで書いている前提です。スライドでも、テキスト書き出しを通せば使えます。

import { readFile } from "node:fs/promises";

// 提案書に必ず入れたい項目と、それを示すキーワード
const checks = [
  { label: "課題整理", keywords: ["課題", "現状"] },
  { label: "ゴール", keywords: ["ゴール", "目的", "KGI", "KPI"] },
  { label: "サイトマップ", keywords: ["サイトマップ", "ページ構成"] },
  { label: "スケジュール", keywords: ["スケジュール", "工程", "公開"] },
  { label: "見積り前提", keywords: ["前提", "概算", "見積"] },
  { label: "保守運用", keywords: ["保守", "運用", "月額"] },
];

const file = process.argv[2] || "proposal.md";
const text = await readFile(file, "utf8");

let missing = 0;
for (const c of checks) {
  const hit = c.keywords.some((k) => text.includes(k));
  if (hit) {
    console.log(`OK  ${c.label}`);
  } else {
    console.log(`NG  ${c.label}  ← この項目が見当たりません`);
    missing++;
  }
}

// 前の案件の社名が残っていないかの簡易チェック
const ghost = ["株式会社サンプル", "○○株式会社", "前案件"];
for (const g of ghost) {
  if (text.includes(g)) {
    console.log(`NG  プレースホルダー「${g}」が残っています`);
    missing++;
  }
}

if (missing === 0) {
  console.log("\n全項目クリア。提出前の最終目視へどうぞ。");
} else {
  console.log(`\n${missing}件の抜けがあります。直してから提出を。`);
  process.exitCode = 1;
}

使い方はこれだけです。

node check-proposal.mjs proposal.md

たった数十行ですが、保守費用の書き忘れと、表紙の社名残りという「いつもやらかす2大ミス」をこれで止められます。キーワードは自社の提案書の言い回しに合わせて足してください。完璧な判定ではなく、人の目の前に置く「最後の門番」として使うのがちょうどいい使い方です。

なお、Claude Codeにこのスクリプトを実行させて、結果を見て提案書を直すところまで任せる流れも作れます。やり方の基礎はClaude Codeの始め方ガイドにまとめてあります。

セキュリティと個人情報の注意点

クライアントの情報を扱うので、ここは雑にできません。最低限これだけは守ってください。

• 学習利用をオフにする。仕事で使うなら、入力内容が学習に使われないプラン・設定を選ぶ。Anthropicの利用規約・プライバシー方針で扱いを確認しておく。
• 渡す情報は最小限に。提案の骨子作りに、先方の担当者の個人携帯や見積り原価まで渡す必要はない。必要な範囲だけ渡す。
• 匿名化してから渡す。社名や個人名を「A社」「担当者X」に置換してから処理させ、最後に人が実名へ戻す。これだけで漏れたときのダメージが下がる。
• 生成物は必ず人が確認。AIが書いた文章をそのまま客に出さない。誤りや、言い過ぎた表現が混ざることがある。

クライアントとの契約に「再委託や外部ツール利用の制限」がある場合は、生成AIに通す前に必ず確認してください。ここを飛ばすと、効率化どころか信用問題になります。

簡単なROIの目安

ざっくり計算します。提案書1件あたり90分が50分に縮むとして、40分の短縮。月3件なら2時間。ディレクターの時給を仮に4,000円とすると、月8,000円分の時間が浮く計算です。

金額より大きいのは、その2時間を「提案の中身を練る」「競合を調べる」に回せること。書類整形に使っていた時間を、受注率に効く作業へ振り替えられます。これは数字より効きます。

プロンプトの精度を上げると、もっと縮みます。書き方のコツは提案を通すプロンプトの上級テクニックや作業を速くするコツ集が参考になります。

よくある質問

Q. AIが作った提案書をそのまま客に出していい？ 出さないでください。たたき台です。戦略の妥当性、金額、表現は人が必ず直す。出すのは、人が確認して責任を持てる状態になってからです。

Q. ヒアリングメモが手書きで汚いんだけど使える？ 写真をテキスト化してから渡せば使えます。ただし誤読が混ざるので、固有名詞と数字（予算・日付）は人が見直してください。

Q. うちのテンプレに合わせられる？ 合わせられます。自社の章立てをプロンプトに貼り付ければ、その型で書いてくれます。1度作ったプロンプトはチームで共有して使い回すといいです。

Q. デザインのことを聞いても役に立つ？ 方向性のたたき台にはなりますが、デザインの最終判断はデザイナーに任せてください。AIは「言葉で整理する」のは得意ですが、ビジュアルの良し悪しの最終判断は人の領分です。

Q. 専門知識がなくても運用できる？ できます。プロンプトを貼って結果を確認するだけなら、コードは要りません。チーム展開の考え方は非エンジニアのClaude Code活用にまとめています。

実際に試した結果

僕は手元にある過去のヒアリングメモ5件分で、この流れを試しました。確かめたのは3つです。

ひとつ目は時間。骨子作りは平均で60分から20分前後に縮みました。完成までの合計でも、90分が40〜50分に収まった件が多かったです。劇的に速くなるというより、「いつも詰まる整形の段差」が消えた感覚でした。

ふたつ目は聞き漏らしです。「メモにないことは創作させない」と縛った効果が大きく、過去メモで予算や公開日が抜けていた案件は、ちゃんと「要確認」に並びました。記憶頼みのときより、確実に拾えています。

みっつ目は検証スクリプトです。わざと保守費用を消した提案書と、前案件の社名を残した提案書を流したら、どちらも NG で止まりました。提出直前の最後の砦としては十分使えます。

結論として、提案の発想はこれまでどおり人がやる。でも、その手前の「散らかった情報を整える」「型に流す」「抜けを確認する」は、もう手でやらなくていい。空いた時間を提案の中身に回す——この使い方が、Web制作会社のディレクターには一番効くと感じています。

チームで仕組みとして回したい、研修として導入したいという場合は、研修・相談の窓口から声をかけてください。