はじめに：私の宿敵は「提案書の1行目」でした
さて突然ですが、私には長年の宿敵がいます。提案書の1行目です。
資料づくり自体は嫌いじゃありません。むしろ好きな方です。なのに、新規案件の提案書を開いた瞬間だけは話が別で、真っ白なエディタとにらめっこしたまま、点滅するカーソルがそのうちモールス信号か何かに見えてきます。「よし、まずコーヒーを淹れ直そう」と席を立ち、戻ってきても状況は1ミリも進んでいない。この儀式を、私はもう数え切れないほど繰り返してきました。締切前夜にSlackで「例の提案書、進捗どうですか？」がそっと届いた日には、カーソルの点滅がもはや心拍数と同期しはじめます。
厄介なのは、これが決してサボっている時間ではないことです。頭の中では「現状分析を先に置くべきか、いや目的からか、集客の話はどこに差し込むか……」とちゃんとグルグル回っている。中身が浮かばないのではなく、並べる順番と粒度が決まらなくて手が止まる。要するに、この 0→1 だけが異様に遅いんですね。
で、ある日ふと思ったわけです。
この「章立てを並べるだけ」の作業、別に私がやらなくてもよくない…？
そこへちょうど「さくらのAI Engine」の記事投稿キャンペーンを見かけたので、渡りに船とばかりに検証してみることにしました。テーマはずばり、「提案書のたたき台を、AIはどこまで肩代わりできるのか」。しかも無償枠でどこまで戦えるのか、という財布に優しい観点も込みで、ストップウォッチ片手にガチで計測してきました。
先に結論だけ
普段Web制作の会社で、提案書やプレゼンの構成案をわりと頻繁に書いています。で、いつも一番しんどいのが「真っ白なテキストエディタに、最初の見出しを打ち込むまで」なんですよね。中身が決まっていないというより、順番と粒度が決まらなくて手が止まる。
その「0→1」の部分を、さくらのAI Engine（OpenAI互換のAPI基盤）の無償枠に丸ごと投げてみたら、同じ品質の構成案が約44分 → 約19分、半分以下の時間で完成しました。
ただし「じゃあ全部AIでいいのか」というと、そこは全然そんなことなくて。速くなったのは埋める作業だけで、"この案件ならでは"の勘所は結局ぜんぶ人間が足すという、まあ順当なところに落ち着きました。この記事はその計測ログです。
検証に使ったのは 基盤モデル無償プラン（Chat completions 月3,000リクエスト）。クレジットカードで勝手に課金される心配がないので、こういう「業務で使えるか試す」用途とめちゃくちゃ相性が良かったです。
なぜ「提案書のたたき台」で試したかったのか
生成AIの検証記事って「一問一答で賢さを見る」ものが多いんですが、実務でAIに一番期待しているのはそこじゃなくて、面倒な下ごしらえを肩代わりしてくれることなんですよね。
提案書の構成案は、まさにその代表格です。
- 章立てのパターンは、案件が変わってもだいたい似ている（＝AIが得意そう）
- でも中身は案件ごとに違う（＝人間の仕事が残りそう）
- しかも「速くなったかどうか」を時間で測りやすい
というわけで、"AIに任せられる範囲"と"人間に残る範囲"の境界線を、実際の業務っぽいタスクで一回ちゃんと引いてみよう、というのが今回の趣旨です。
お題は、守秘の都合で少しぼかしていますが、こんな架空案件にしました。
創業100年超の老舗和菓子店の、ECサイト・リニューアル提案書（構成案）
既存サイトはあるが古い。店舗は繁盛しているがオンラインは弱い。予算感は中規模。
検証環境：さくらのAI Engineの準備
やることは3ステップだけでした。
- さくらのクラウドで「さくらのAI Engine」の基盤モデル無償プランを申し込む
- コントロールパネルの左メニュー「アカウントトークン」からトークンを発行（最大20個作れます）
- あとはOpenAI互換のエンドポイントを叩くだけ
エンドポイントは https://api.ai.sakura.ad.jp/v1/chat/completions。完全にOpenAIのChat Completions形式なので、curlでも一発で通ります。
curl https://api.ai.sakura.ad.jp/v1/chat/completions \
-H "Content-Type: application/json" \
-H "Authorization: Bearer ${SAKURA_AI_TOKEN}" \
-d '{
"model": "gpt-oss-120b",
"messages": [{"role": "user", "content": "自己紹介して"}]
}'
OpenAI互換ということは、公式のPython SDKの base_url だけ差し替えれば動くということです。ここが個人的に一番ラクでした。既存の資産をほぼ書き換えずに向き先だけ変えられる。
import os
from openai import OpenAI
client = OpenAI(
base_url="https://api.ai.sakura.ad.jp/v1/", # ここだけ差し替え
api_key=os.environ["SAKURA_AI_TOKEN"],
)
def draft(system: str, user: str) -> str:
res = client.chat.completions.create(
model="gpt-oss-120b", # 無償枠で使える高性能モデル
messages=[
{"role": "system", "content": system},
{"role": "user", "content": user},
],
temperature=0.4, # 構成案なので発散させすぎない
max_tokens=1500,
)
return res.choices[0].message.content
モデルは gpt-oss-120b（コンテキスト128K）を使いました。コード寄りの重いタスクなら Qwen3-Coder-480B-A35B-Instruct-FP8 も無償枠で選べます。今回は文章生成なので前者で十分でした。
検証の設計
フェアに比べたいので、条件を先に固定しました。
| 項目 | 内容 |
|---|---|
| 成果物 | 提案書の「構成案」（章立て＋各章に入れる論点の箇条書き。本文は書かない） |
| 完成の定義 | そのまま社内レビューに出せる状態 |
| 計測 | スマホのストップウォッチで実測。中断時間は止める |
| 比較A | ゼロから自分で書く |
| 比較B | AIにたたき台を出させ、人間が手直しする |
同じお題を続けて2回やると2回目が速くなるズルができてしまうので、Bを別日の朝イチ（頭が同じくらいの状態）にやりました。地味だけど大事なポイントです。
全体の流れはこんな感じです。
実際にやってみた
パターンA：ゼロから自分で書く
いつも通りです。過去案件の構成を思い出しながら、見出しを並べて、順番を入れ替えて、粒度をそろえて……という作業。
結果は 44分。まあこんなもんです。特に「集客の話をどこに置くか」でいつも迷って、ここで5分くらい溶かしました。
パターンB：AIにたたき台を出させる
投げたプロンプトはこれです。役割・制約・出力形式をはっきり指定するのがコツでした。
system = "あなたはWeb制作会社の提案書作成を支援するプランナーです。"
user = """
以下の案件について、提案書の「構成案」を作ってください。
# 案件
- 創業100年超の老舗和菓子店のECサイト・リニューアル
- 実店舗は好調、オンライン販売は弱い
- 予算は中規模、公開まで約6か月
# 出力ルール
- 章立て（見出し）と、各章に盛り込む論点を箇条書きで
- 本文は書かない
- 論理の順番（現状→目的→施策→体制→費用）を意識する
"""
print(draft(system, user))
返ってきた構成案は、正直かなり良かったです。生成待ちは体感1分弱。全13項目の骨格が、抜けなく並んでいました。長いので折りたたんでおきます。
AIが出力した構成案（抜粋）
1. 現状分析と課題
- 既存サイトの流入・売上・離脱の課題
- 競合ECとの比較
2. 提案のゴール（KGI / KPI）
- オンライン売上比率、リピート率
3. ターゲットとペルソナ
4. ブランドの世界観をどう届けるか
5. 情報設計・サイトマップ
6. デザイン方針
7. 主要機能
- カート／決済／のし・ギフト対応／在庫連携
8. コンテンツ戦略（季節商品・物語性）
9. 集客・流入設計（SEO / SNS / 広告）
10. スマホ最適化・アクセシビリティ
11. 開発スコープと体制
12. スケジュール（6か月）
13. 概算費用と投資対効果
ここから人間の手直しです。ストップウォッチを回しながら、13項目を「ほぼそのまま採用」「少し直す」「使えない・足りない」に仕分けしていきました。
手直しにかかったのは 15分。プロンプトを2回調整したので、それを足しても合計 約19分 でした。
結果
まず時間。ひと目でわかると思います。
そして、AIが出した構成案の"中身"を仕分けした結果がこちら。
8割以上はそのまま、または軽い修正で使えた。ここは素直にすごい。一方で残りの15%、これが今回の一番おもしろいところでした。
わかったこと
速くなるのは「並べる」作業
AIが埋めてくれたのは、どの案件にも共通する"型"の部分です。章立て・順番・一般的な論点。ここは人間がやってもAIがやっても大差ない、けど地味に時間を食う。そこが一瞬で終わるのは、体感としてかなりデカいです。
AIが絶対に拾えなかった15%
逆に、AIの構成案から丸ごと抜け落ちていたのはこのあたりでした。
- 老舗ゆえのブランド毀損リスク（安売り感を出すと100年のブランドが傷つく、という緊張感）
- 既存の主要顧客が高齢で、そもそもECに来てくれるのか問題
- 公開後、誰が商品を登録・更新するのかという運用体制のリアル
つまり、この案件だからこそ効く一言"は全部人間が足したわけです。そしてクライアントの心を動かすのは、たいていこの15%の方だったりする。ここをAIに丸投げした提案書は、たぶん通らないと思います。
このへんを分かった上で使わないと、「網羅的だけど刺さらない、いかにもテンプレな提案書」が量産されるリスクがあります。AIは"抜け漏れチェッカー兼ペースメーカー"、決断は人間、くらいの距離感がちょうど良かったです。
無償枠3,000リクエストは、この用途なら余裕すぎる
気になる消費量ですが、1本の提案書でプロンプト調整を含めても 10〜20リクエスト程度。仮に月に提案書を10本書いても200リクエストで、3,000の無償枠にはまるで届きません。
超過しても勝手に課金されない仕様なので、「試したら請求が怖い」というあのプレッシャーがゼロなのは、業務検証では地味に効きます。むしろ枠が余りまくるので、次はEmbeddings（月10,000回）と組み合わせて、過去の提案書を検索させて"自社らしさ"を注入する方に回したいです。
ついでに： ハマったところ
同じことをやる人のために、つまずいた点を残しておきます。どれも大したことないですが、知らないと数分溶かします。
その1：temperature を上げると比較にならない。
最初 0.7 でやったら、実行のたびに章立てがそこそこ変わって、「毎回ちがう答えが出てきて何を評価してるのか分からん」状態になりました。構成案みたいに"型"がほしいタスクは、思い切って 0.3〜0.4 くらいまで下げた方が安定します。ここは1時間くらい遠回りしました。
その2：max_tokens を絞りすぎて途中で切れる。
13項目の構成案は意外と長く、最初 max_tokens=512 にしていたら「13. 概算費用」の手前でぶつっと切れました。出力が尻切れになったら、まずここを疑うといいです。今回は 1500 で余裕でした。
その3：トークンは環境変数に逃がす。
当たり前ですが、api_key を直書きしてスクショを撮ると事故ります。export SAKURA_AI_TOKEN=... で環境変数にしておくのが安全。トークンは管理画面から最大20個まで作れるので、用途ごとに分けて、漏れたら1個だけ捨てられるようにしておくと安心でした。
発行したアカウントトークンは他人に共有しないでください。GitHubにうっかり push すると、無償枠うんぬん以前に第三者に叩かれる可能性があります。
まとめ
- 提案書の構成案づくりは、たたき台をAIに任せると半分以下の時間になった（44分 → 19分）
- ただし速くなるのは"型を並べる"部分だけ。案件固有の勘所（今回は15%）は人間の仕事のまま
- さくらのAI EngineはOpenAI互換なので、
base_urlを差し替えるだけで既存コードがそのまま動く - 無償枠3,000リクエストは、提案書用途なら全然使い切れない。課金が勝手に走らないので検証が気楽
「AIが提案書を書いてくれる」ではなく、「AIがたたき台を出すから、人間は考えるべき15%に集中できる」。今回いちばん腑に落ちたのはこの感覚でした。0→1をAIに、1→100を人間に。役割分担がはっきりしたのが一番の収穫です。
※本記事は「さくらのAI Engine」記事投稿キャンペーンの参加記事です。案件内容は守秘のため一部を架空の設定に置き換えています。