提案書AIを作ったら、作っているものが変わった｜Web制作会社の自社DXの記録

提案書をAIで作る、という話をこれからします。ただ、いちばん面白いところから始めさせてください。このツールは、提案書を作るツールとして企画されていません。

Web制作会社であるGrowGroup株式会社には、ProBoost（プロブースト）という自社開発のWebアプリケーションがあります。プロデューサーが提案業務で使う、Gemini（生成AI）を搭載したツールです。いまの主役機能は提案書（PPTX）の生成。ところが、開発着手時点の要件定義書には「提案書」という機能が一行も存在しません。当時の名前は「Wireframe Generator」。目的はワイヤーフレーム作成の高速化とコスト削減でした。

そして現在、主役だったはずのワイヤーフレームは、提案書のなかの「1プレースホルダー（穴埋め項目）」に格下げされています。開発当初にPhase 2の目玉として掲げていたデザインツール連携も、共有・コメント機能も、ドキュメントから跡形もなく消えました。

作っているうちに、作っているものが変わった。この記事は、その記録です。「提案書 AI」という切り口で検索されている方には、たぶん機能一覧より役に立ちます。というのも、AIで業務を変えようとしたとき本当に起きるのは「想定していた課題より、もっと上流の課題が見つかる」ことだからです。ProBoostは社内専用のツールで販売していませんが、業務をどう分解し、何を機械に渡し、何を人が握り続けたのかという設計判断は、そのまま持ち帰っていただけます。

背景：発端は「提案書」ではなく「ワイヤーフレームのコスト」だった

開発の発端は、拍子抜けするほど即物的な理由です。外部の生成AIサービスを使ってワイヤーフレームを作っていたが、その利用クレジットの消費が大きく、コストが課題になっていた——要件定義書に書かれた「現状」は、この一点でした。目的も明快で、「ワイヤーフレーム作成を高速化・コスト削減・品質向上させる」。数値目標として外部サービス比で月間コストを50%以上削減するとまで書いてあります。

それ以前の提案業務がどうだったかというと、過去の提案スライドを人手で探して切り貼りし、ワイヤーフレームはデザインツールと外部AIサービスで起こし、サイトマップの知見はスプレッドシートに散らばっている、という状態でした（※これは残された資料の構成からの読み取りで、当時の状況を明言した文書は残っていません）。

弊社が最初に置いた要求は、シンプルなものでした。Webサイトを受注したあとのワークフローで、ワイヤーフレームをプロデューサー自身が簡単に作れるようにしたい。そしてもうひとつ、非エンジニアがGUIだけで完結できること。ターミナルを開かせる道具にはしない、という条件です。作るのはプロデューサーであって、エンジニアではないのだから、と。

ここまでは、素直に「ワイヤーフレームを速く安く作る道具」の話です。ところが、要求はここで唐突に方向を変えます。付け足しのように、こういう条件が入りました。ワイヤーフレームでモックアップを作る前に必ず、プロジェクトの背景と課題、サイトリニューアルの目的や目標を、一度わかりやすい形にする。

思いつきのような、一行の追加です。しかし振り返ると、ProBoostが提案書ツールへ変わっていく分岐点は、おそらくここにあります。

言っているのは、「画面を描く前に、背景と課題を言語化させろ」ということです。ワイヤーフレームは、提案の結論の絵にすぎません。その絵を出す前に、なぜこのプロジェクトをやるのか・何が課題なのか・何を目標とするのかが言語化されていなければ、絵は速く出ても意味がない。速く作る道具を作ろうとしていたのに、「作る前に考えることのほうが本体だ」と自分で言ってしまったわけです。ツールの重心が提案書側へ滑り出したのは、この瞬間からだと考えるのが自然です。

その後も、ツールの説明は長らくワイヤーフレーム中心のままでした。2025年末時点の社内マニュアルでも、ProBoostは「提案時における現状サイトマップの把握、提案サイトマップの作成、ワイヤーフレーム生成ができるWebアプリケーション」と説明されています。この時点ではまだ「ワイヤーフレーム生成」が説明の中心にいます。提案書生成が主軸へ出てくるのは、この後の話です。ちなみにドキュメント上の名称は、実態が提案書ツールへ移ったあともしばらく「Wireframe Generator」のままでした。実物が先に変わり、名前と説明が何ヶ月も遅れて追いかけた——という、あまり格好のよくない順序です。

課題：開発前の課題と、運用してから初めて見えた課題

ProBoostが向き合った課題は、時間差で二層に分かれています。ここが、この事例のいちばん実用的なところかもしれません。作る前に見えていた課題と、動かしてから見つかった課題は、まったく別物だったのです。

第一層：作る前に見えていた課題

• 外部AIサービスのクレジット消費。ワイヤーフレーム生成は量が出る作業で、コストが素直に効いてくる
• 生成量が単純に多い。新規プロジェクトは月におよそ20件、1プロジェクトあたり12〜30画面。パターン違いまで含めると月間およそ2,000パターンの生成が想定されていた
• 自社のスタイルが反映されない。汎用のAIサービスは、汎用の画面しか出さない
• AIの提案に根拠がない。「なぜこの構成なのか」に答えられない。要件定義には、「52件中87%で使用されています」のように根拠を提示したいという要望が具体例つきで書かれています

この4つ目が、いま読み返すと重要です。速さでも安さでもなく、「AIの出力に根拠を持たせたい」という要求が最初から入っていた。これが後の設計——過去の実提案書をテンプレートにする、という判断——に直結していきます。

第二層：動かしてから見つかった課題

こちらは、要件定義書には一行もありません。すべて運用のなかで発覚したものです。

並べてみると、性質が違うことが分かります。作る前に見えていたのは「コストと品質」。動かしてから出てきたのは「信頼性と運用」です。とくに「添付資料の内容がAIに反映されず、不正確なデータが生成されていた」は、提案ツールとして致命的な種類の問題でした。クライアントから預かったアクセス解析のPDFを添えているのに、AIがその中身を読まずに提案文を書いていた、ということですから。速いことより、まず嘘をつかないことが要る。この気づきは、机の上では絶対に出てきません。

正直に書いておくと、「提案書の作成にプロデューサーが何時間かけていたか」という定量的な課題記述は、社内ドキュメントに一切ありません。後述する「10時間→1時間」も、開発ドキュメントに裏付けのある計測値ではなく、現場の実感値です。困りごとの定量化をしないまま作り始めていた——これも記録として残しておきます。

目的：AIに任せなかったことのほうが、設計を語っている

要件定義書に掲げられた目的は5つです。①コスト削減（外部サービス比50%減）②品質向上 ③スピード向上（初稿作成時間を80%削減）④ナレッジ蓄積 ⑤柔軟性。加えて、設計方針として「エンジニアでなくても使える」「AIの提案根拠を明示する」が置かれています。

ただ、目的の並びより雄弁なのは優先順位です。要件定義で優先度1位に置かれているのは「編集の自由度」でした。生成速度より上。独自スタイルの反映より上。コスト削減より上。コスト課題から始まったプロジェクトなのに、いちばん大事なものは「あとから人が自由に直せること」だと宣言している。ここが、このツールの背骨です。

人が握り続けているもの

「編集の自由度が最優先」は、スローガンではなく実装の形になっています。ProBoostでAIに委ねていない＝人が決めるのは、次のものです。

• どのセクションを提案書に載せるか（人が選ぶ。プリセットも人が定義）
• どのバリエーションを使うか
• スライドの並び順（ドラッグ&ドロップで人が調整）
• スケジュール（開始日とフェーズ週数を人が入力し、そこから自動計算）
• 生成後の本文（HTML提案書は左右分割のリアルタイム編集で直接手を入れる）
• 提案書のテンプレートそのもの（PowerPointで人が作り、アップロードする。必須）
• AIに与えるプロンプトそのもの（管理画面から人が編集する）

最後の2つが効いています。提案書のガワは、AIではなくPowerPointを開いた人間が作る。そしてAIへの指示文すら、コードの中ではなく管理画面に置いて人が書き換えられるようにした。「AIが提案書を作る」のではなく、「人が作った器に、AIが下書きを流し込む」という構図です。

ただし、AIが埋める範囲は広い（ここは正直に書きます）

「AIは穴埋めしかしていません」と書くと聞こえはいいのですが、それは不正確です。ProBoostのAIプレースホルダーは153件あり、埋める対象は課題・解決策・目標・ペルソナ・カスタマージャーニー・SEO方針・デザイン方針にまで及びます。提案書の中身のかなりの部分は、初稿の段階ではAIが書いています。

ですから正確な言い方はこうです。「AIが提案書を作るのではない。人が選んだ構成に、AIが下書きを流し込む。最終的な文言・構成・判断は人が握る」。AIが書く量は多い。けれど、何を書かせるか・どの順で並べるか・そのまま出すかを決めるのは人。この線引きが、ProBoostの設計思想そのものです。

どう解いたか①：提案の型は、過去の提案書204枚が持っていた

「AIの提案に根拠がない」という課題への回答が、ProBoost最大の構造的な特徴です。

提案書テンプレートの正体は、過去に実際にクライアントへ提出した提案書のスライド204枚です。課題を語るスライドが15枚、デザイン方針が12枚、機能説明が14枚——といった具合に、全部で25のセクションタイプに分類されています。AIは、この人間が積み上げた型のなかの穴を埋めているにすぎません。

つまり、提案の型はAIが発明したものではなく、これまで提案し、通し、あるいは落ちた実績そのものです。生成AIに「良い提案書の構成を考えて」と頼んだ結果ではありません。ここが、汎用の生成AIサービスに提案書を書かせるのとの決定的な差です。出てくる提案書は、その会社が過去にやってきたことの形をしている。

そして面白いのは、この204枚のうち75枚は自動分類できず、手動分類に回されたことです。3枚に1枚以上は、機械が「これは何のスライドか」を判定できなかった。提案書という文書がいかに文脈依存かを、この数字が示しています。ナレッジ資産化と言えば聞こえはいいのですが、実態は「人が一枚ずつ仕分けした」のです。AI活用の事例には、たいていこういう地味な工程が挟まっています。

どう解いたか②：トレードオフの記録 ── 何を捨てて何を取ったか

実装の細部は本題ではないので、目的に直接ひもづく判断だけを書きます。ProBoostの改善記録には、天秤にかけて片方を捨てた跡が3つ、はっきり残っています。

品質 > 速度

PPTX生成の成功率は当初70〜80%でした。5回に1回は失敗する提案書ツールは、業務では使えません。対応として、AIへの並列リクエスト数を絞り、失敗時に3回まで再試行する仕組みを入れました。結果、1回あたり15〜25秒遅くなることを受け入れて、成功率を引き上げています。

さらに徹底しているのは、速度改善そのものにも条件が付いていることです。改善記録には速度改善は「品質への影響ゼロ・コスト増加ゼロ」を保証条件とすると明記されています。速くするために品質を落とす選択肢が、最初から禁じ手にされている。コスト削減から始まったプロジェクトが、最後は「品質を落とさないこと」を制約条件に据えた——これも、ツールの重心が移った証拠のひとつです。

一貫性 > コスト

提案書には、同じ内容を指すプレースホルダーが複数のスライドに登場します。素直に作れば、スライドごとにAIが生成することになります。ProBoostは同一のプレースホルダーはキャッシュして1回だけ生成する設計を採りました。

目的はコスト削減——ではありません。記録に書かれている効能は「スライド間での矛盾がない」です。3ページ目と12ページ目で課題認識が食い違う提案書は、それだけで信用を失います。AI生成物のいちばん怖いところは、間違うことより「一貫していないこと」だと理解した上での設計です。コストが下がるのは副産物にすぎません。

人が見られること > 技術的な正しさ

個人的にいちばん好きな判断がこれです。ProBoostのマスターデータは、データベースではなくスプレッドシートに置かれています。データベース側はキャッシュという位置づけです。

理由はドキュメントに一行で書かれています。「スプレッドシート＝マスターデータ：誰でも確認・編集可能」。エンジニアの設計としては、データベースをマスターにするのが素直です。それでもスプレッドシートを正としたのは、「エンジニアでなくても使える」という目的から逆算したから。プロデューサーが中身を見たいとき、開発者に頼まないと確認できないなら、そのツールは業務に馴染みません。技術的な美しさを、非エンジニアが自分で触れることに譲ったわけです。

同じ思想は、プロンプトを管理画面に出したことにも表れています。AIの言うことがおかしいとき、コードを直してデプロイするのではなく、使っている人がその場で指示文を書き換えられる。プロンプト変更にコード修正とデプロイが不要になったことは、ドキュメント上も明確な改善成果として記録されています。

どう解いたか③：提案書の前と後ろまで、飲み込んでいった

ProBoostが「ワイヤーフレーム生成ツール」でなくなったのは、機能が増えたからではありません。提案という業務の前後まで手を伸ばしたからです。現在の守備範囲は、こうなっています。

1. 案件の流入と振り分け：問い合わせ受信を1分ごとに拾い、AIが内容を判定してフィルタし、プロジェクト管理ツールへ転送する
2. プロデューサーの自動アサイン：誰が担当するかを機械的に割り当てる
3. 現状分析：既存サイトのURLから非同期でスクレイピングし、サイト構造を取得する
4. 資料の読み込み：添付PDFから内容を抽出し、AIが提案時に参照する（＝「不正確なデータが生成されていた」課題への対応）
5. 制作実績の自動マッチング：業種一致100点・紹介文一致50点・プロジェクト情報一致50点でスコアリングし、提案に載せる実績を機械が推薦する
6. 提案書の生成：テンプレート解析→プレースホルダー検出→重複除去→バッチAI生成→キャッシュ→置換→出力
7. 人による編集と提出判断

1番と2番に注目してください。ワイヤーフレームの高速化を目指したツールが、いつのまにか「問い合わせが来たら誰が担当するかを決める」ところまで来ています。これは機能追加ではなく、課題の在り処が上流にあったと気づいた結果です。提案の初稿を1時間速く作っても、案件が担当者に届くまでに1日寝ていたら意味がない、という話でもあります。

5番の実績マッチングも、思想が同じです。「近い実績を探す」のは、経験のあるプロデューサーの頭の中にしかない作業でした。それを業種一致100点・紹介文一致50点・プロジェクト情報一致50点という、人が読めるスコアリングに落としている。AIに「いい感じの実績を選んで」と丸投げしていません。ここでも根拠を明示するという当初の要求が生きています。

「作っているうちに、作っているものが変わった」

旧Wireframe Generatorと現在のProBoostを、同じ観点で並べます。

変化の本質は、一行で言えます。「AIで画面のたたき台を作る道具」が、「プロデューサーの提案業務そのものを、前後工程ごと支える道具」に変わった。名前が変わったのは、この実態変化の追認だと読むのが自然です。

ただし正直に書くと、改名の経緯・時期・命名意図を記した文書は存在しません。いつ誰がどう決めたのかは残っていない。だから本記事の「追認だと読める」も、ドキュメントの差分からの推測です。ついでに言えば、ワイヤーフレームを主役から降ろした判断も、デザインツール連携と共有機能を捨てた判断も、経緯を書いた文書がありません。機能は静かに消えていました。

これは、自社DXの記録としてはよくある光景です。作ったものの記録は残るが、やめたものの記録は残らない。実際には「やめた判断」のほうに知見が詰まっているのですが。

成果：測れたもの、測っていないもの

ここは、書ける数字と書けない数字を分けます。

業務の成果：提案準備 10時間 → 1時間

提案1件あたりの準備時間は、従来おおよそ10時間、現在はおおよそ1時間です。提案は全プロデューサー合計で月20件超。

ただし、この数字の出どころを明示しておきます。これは提案業務にあたっている現場の実感値であり、開発ドキュメントに計測の裏付けはありません。ストップウォッチで測ったものでもありません。「1件9時間×月20件＝月180時間」という計算も、この前提の上に乗った試算です。数字を大きく見せるより、前提を開示するほうが役に立つと考えるので、そのまま書いておきます。

技術の成果：ドキュメントに残っている数字

測っていないもの（＝書けないもの）

ここが、この記事でいちばん誠実であるべき部分です。

• 要件定義に置いたKPIは、すべて未達のまま記録がありません。「初稿作成時間80%削減」「編集時間の平均30分以内」「クライアント提案での採用率70%以上」「外部サービス比コスト50%削減」——チェックボックスは未チェックのままです。達成したとも、しなかったとも書けない。測定そのものが走っていないのです
• 受注率や提案採用率への影響は、根拠がないので書きません
• 実際に何人が日常的に使っているかも、集計していません
• プロデューサー自身の声も、記録として残っていません

KPIを掲げたのに測っていない。これは、自社DXでかなりの確率で起きることだと思います。動き始めたツールは日々の業務に溶けてしまい、誰も振り返って測らない。皮肉なのは、そのあいだにツール自体はワイヤーフレームツールから提案業務プラットフォームへと別物に変わっていたことです。当初のKPIは、測る前に測る意味を失っていたとも言えます。

もしいまProBoostのKPIを引き直すなら、「ワイヤーフレームの生成コスト」ではなく「提案が担当者に渡るまでの時間」や「初稿から提出までの手戻り回数」になるはずです。KPIは、作るものが変わったら引き直さなければならない。当たり前のようでいて、走っている最中には誰も言い出しませんでした。

御社の業務に移せる、5つの学び

ProBoostは弊社の社内ツールなので、そのまま使っていただくことはできません。ただ、設計判断は業種を問わず移せます。提案書に限らず、見積書・報告書・マニュアル・審査資料など「毎回似ているが毎回違う書類」を作っている業務なら、そのまま当てはまるはずです。

1. 「型」は買うのではなく、自社の過去の実物から作る。ProBoostの提案テンプレートは、過去の実提案書204枚です。汎用AIに構成を考えさせるより、自社が実際に出してきた書類のほうが、はるかに強い資産です。まず社内の書類を集めて分類するところから始まります（そして3枚に1枚は手作業になります）
2. 最優先は「速さ」ではなく「あとから人が直せること」。ProBoostの優先度1位は編集の自由度でした。直せないAI出力は、結局チェックのコストで元が取れません
3. マスターデータは、人が見られる場所に置く。スプレッドシートをマスターにし、データベースをキャッシュにする。「誰でも確認・編集可能」を、技術的な美しさより優先する。非エンジニアが自分で確認できないツールは、業務に定着しません
4. AIへの指示文を、コードの外に出す。プロンプトを管理画面に置いておけば、出力がおかしいときに現場が自分で直せます。開発者への依頼待ちが消えるだけで、運用の速度は変わります
5. 一貫性を、コストより上に置く。同じ項目は一度だけ生成してキャッシュし、全ページで同じ内容を使う。AI生成物の信頼を壊すのは、間違いより矛盾です

そして、いちばん大きな学びは「最初に立てた課題は、たいてい本当の課題ではない」ということです。ProBoostはワイヤーフレームのコストから始まって、提案業務そのものにたどり着きました。もし最初の要件定義を忠実に守っていたら、いまも「安いワイヤーフレーム生成ツール」だったはずです。AI活用は、完璧な要件定義から始めるものではなく、動かして課題を発見しに行くもの——弊社の実感です。

よくある質問

Q. 結局、AIが提案書を自動生成しているのですか？

A. 「自動生成」と呼ぶと不正確です。正確には、人が選んだ構成に、AIが下書きを流し込んでいます。テンプレートは人がPowerPointで作り、載せるセクションと並び順は人が決め、AIへの指示文も人が書きます。一方でAIが埋める範囲は広く、153件のプレースホルダー——課題・解決策・ペルソナ・カスタマージャーニー・SEO方針・デザイン方針まで及びます。下書きの量は多いが、決定権は人にある、というのが実態です。

Q. 「提案書 AI」で汎用のサービスを使うのとは、何が違うのですか？

A. 参照している型が、自社の過去の実提案書であることです。汎用の生成AIに提案書を書かせると、汎用の提案書が出てきます。ProBoostが出すのは、これまで自社が実際に提出してきた提案書の形をしたものです。開発当初から「AIの提案に根拠がない」ことが課題として挙がっており、根拠を提示できることが要件でした。

Q. なぜ名前が変わったのですか？

A. 改名の経緯を記した文書は残っていません。分かっているのは、当初「Wireframe Generator」という名前で、目的が「ワイヤーフレーム作成の高速化・コスト削減」だったこと。そして現在は提案書生成が主軸で、ワイヤーフレームは提案書内の1プレースホルダーになっていることです。実態が先に変わり、名前が後から追いついたと読むのが自然ですが、これは記録からの推測です。

Q. 「10時間→1時間」は本当に測った数字ですか？

A. いいえ。現場の実感値です。開発ドキュメントに計測の裏付けはなく、時間を記録して集計したものでもありません。むしろ要件定義に置いた「初稿作成時間80%削減」「提案採用率70%以上」といったKPIは、すべて未達のまま測定記録がないのが実情です。数字より、前提の開示と設計判断のほうを持ち帰っていただければと思います。

Q. AIが書いた提案書を、そのままクライアントに出すのですか？

A. 出しません。AIが埋めるのは初稿で、その後に人が直接編集します。要件定義の優先度1位が「編集の自由度」であることからも分かるとおり、そもそも「人が直す」前提で設計されたツールです。運用初期には添付資料の内容が反映されず不正確なデータが生成されるという問題も実際に起きています（現在は添付PDFの内容をAIが参照するよう改修済み）。AI出力をノーチェックで外に出す運用は、そもそも想定していません。

Q. ProBoostは購入できますか？

A. 販売していません。弊社の業務に合わせて内製した社内専用ツールです。ただ、同じ発想で御社の業務を設計し直すお手伝いは承っています。「毎回似ているが毎回違う書類」を人が手作業で組み立てている業務は、たいてい同じ構造をしています。

Q. 何から始めればいいですか？

A. ProBoostの経験から言えば、ツール選定より先に、その業務で「作る前に決めていること」を洗い出すことです。弊社の場合、「画面を描く前に、背景と課題と目的を言語化する」という一言が出発点になり、そこからツールの重心が動きました。いまの業務の、どの判断を人が握り、どの作業を機械に渡せるのか——ここが決まれば、実装は後からついてきます。

まとめ：AIに任せる前に、業務の形が見えているか

ProBoostの話を、もう一度短くまとめます。

• 提案書ツールとして企画されていない。発端は外部AIサービスのクレジット消費というコスト課題で、当初の名前はWireframe Generator、目的はワイヤーフレーム作成の高速化だった
• 提案書機能は要件定義に一行もない、完全な後付け。いま主役のはずだったワイヤーフレームは、提案書内の1プレースホルダーに格下げされている
• 提案の型はAIが発明していない。過去の実提案書204枚が原資で、うち75枚は人が手で仕分けた
• 優先度1位は「編集の自由度」。速さでもコストでもない。人が直せることが最優先だった
• 捨てた側に思想が出る。品質のために速度を、一貫性のためにコストを、技術的な美しさのために「誰でも見られること」を——それぞれ天秤にかけて選んでいる
• KPIは測っていない。掲げた目標はすべて未達のまま記録がない。作るものが変わったとき、KPIも引き直すべきだった

「AIで業務を効率化する」と言うとき、多くの場合はいまの作業を速くすることが想像されます。ProBoostで実際に起きたのは、そうではありませんでした。作業を機械に渡そうとした瞬間に、その業務を自分たちが分解できていないことが露わになった。そして分解していった先に、当初の課題より上流に本当の課題があった。効率化ツールを作ったつもりが、業務の形そのものを言語化する作業になっていたのです。

これは、弊社が特別だったからではありません。どの会社の業務にも、「毎回似ているが毎回違う」書類仕事が必ずあります。そして、そこには必ず調べれば分かることと人が決めるべきことが混ざっています。その2つを分ける作業こそが、AI活用の本体です。ツールは、分けたあとの話でしかありません。

同じ発想で、御社の業務もDXできます

GrowGroupはWeb制作会社ですが、ここまで書いてきたものは全部、自分たちの業務のために自分たちで作ったものです。だからこそ、業務の分解から、人とAIの線引き、現場が自分で運用できる形への落とし込みまで、実際にやった手触りでご一緒できます。

「AIを入れたいが、何から手をつけるべきか分からない」「作ってみたが現場に定着しない」——そのあたりの相談が、いちばん得意です。まずは、いまの業務のどこに時間が溶けているかを一緒に見るところから。無理にツールを作る結論にはなりません（弊社も、当初作ろうとしたものとは違うものを作りました）。

無料ダウンロード資料

GrowGroup株式会社の制作事例・料金がわかる資料を配布中

会社概要・制作実績・料金の目安をまとめた資料です ／ PDF

資料をダウンロード