AIで企画書のたたき台を作る手順：根拠と仮説を分ける

この記事で分かること

白紙から企画書を作る前に固定する5つの条件
確認済み事実と未検証の仮説を混ぜない書き方
1ページ企画へ落とし込むテンプレート
反対意見と評価指標を使って企画を検証する方法

注意： AIが作った市場規模、顧客の声、競合情報、費用、効果予測は、根拠資料が示されない限り確認済み事実ではありません。企画書へ載せる場合は仮説として表示してください。

先に結論

AIにいきなり「魅力的な企画書を書いて」と頼むと、文章は整っていても、根拠のない課題や効果が混ざりやすくなります。先に目的、対象、課題、制約、評価指標を人が定義し、確認済み資料を渡します。

AIには、情報を [事実]、[仮説]、[未確認] に分けさせます。企画の完成度は文章の巧さではなく、仮説をどう検証し、何をもって継続・中止するかで判断します。

企画書を事実と仮説に分けて作る流れ 目的を定義し、確認済み事実を固定してから仮説と評価方法を作る順序を示している。

手順1：企画の前提を5項目で固定する

最初に次のシートを埋めます。

項目	書く内容	悪い例	良い例
目的	何を改善するか	売上を伸ばす	初回購入者の30日以内再購入を増やす
対象	誰の課題か	顧客	直近3か月の初回購入者
課題	観測済みの困り事	満足度が低い	再購入率が目標を下回っている
制約	変えられない条件	低予算	既存配信基盤を使い、個人情報を追加取得しない
評価指標	成否の測り方	評判を見る	再購入率、配信停止率、問い合わせ率

数値目標が未承認なら、仮の目標を事実のように書かず [仮説：目標値] とします。企画対象外も決めます。例えば「新規システム開発は行わない」「値引き施策は比較対象に含めない」と書けば、AIの提案が広がりすぎるのを防げます。

手順2：根拠資料を整理する

AIへ渡す前に、資料ごとに出所、期間、所有者、確認状態を記録します。

資料ID：S-01
資料名：2026年4〜6月 購買集計
作成部門：営業企画部
対象期間：2026-04-01〜2026-06-30
確認状態：部門責任者確認済み
この企画で使える事実：初回購入者の30日以内再購入率
利用上の注意：個票ではなく集計値のみ使用

古い資料、出所不明の数字、会議で出ただけの感想は、確認済み事実から外します。外部情報を使う場合も、公開日、調査対象、調査方法、自社への適用可能性を確認します。

手順3：事実・仮説・未確認をラベル付けする

次の基準を使います。

[事実]：正本または信頼できる一次資料で確認済み
[仮説]：事実から導いた説明や施策案だが、まだ検証していない
[未確認]：根拠が不足し、事実か仮説かも判断できない
[判断]：責任者が制約や優先順位を踏まえて選んだ方針

例えば、「再購入率が目標を下回った」は集計で確認できれば事実です。「購入後に使い方が分からないことが原因」は、調査していなければ仮説です。「フォローメールを送る」は施策案であり、効果はまだ事実ではありません。

AIが論理的につないだ文でも、根拠が増えたわけではありません。文と文の間に新しい因果関係が生まれていないか確認します。

手順4：たたき台プロンプトを入力する

あなたは企画書の構造化を支援する編集者です。以下の資料だけを使い、1ページ企画のたたき台を作ってください。

目的：[目的]
対象：[対象]
制約：[予算、期間、利用可能な手段、禁止事項]
確認済み資料：[資料IDと要点]

ルール：
- 各主張の先頭に[事実][仮説][未確認][判断案]のいずれかを付ける
- [事実]には根拠の資料IDを付ける
- 資料にない数値、顧客の声、競合情報、費用、効果を作らない
- 仮説ごとに検証方法と反証されたと判断する条件を書く
- 情報不足は空欄にせず「未確認事項」として一覧化する
- 施策は制約内で最大3案に絞る

出力項目：
1. 目的
2. 対象と課題
3. 根拠
4. 仮説
5. 提案施策
6. 検証方法
7. 成功指標と安全指標
8. リスク
9. 未確認事項
10. 意思決定が必要な点

成功の目安は、資料IDのない断定が [事実] として出ていないことです。AIが外部知識を補った場合は、削除するか [未確認] へ変更します。

手順5：1ページ企画へ整える

次のMarkdownテンプレートを使うと、文章量より判断材料を優先できます。

## 企画名
[一文で内容が分かる名前]

## 目的
- [改善したい結果]

## 対象と課題
- [事実][資料ID] 観測済みの状態
- [仮説] 状態が生じる理由

## 提案
- 実施内容：
- 対象範囲：
- 実施期間：
- 実施しないこと：

## 根拠と仮説
| ID | 種別 | 内容 | 根拠 | 検証方法 |
|---|---|---|---|---|
| F-01 | 事実 |  | S-01 | 確認済み |
| H-01 | 仮説 |  | F-01から推定 |  |

## 評価指標
| 種類 | 指標 | 現状値 | 目標・判定基準 | 確認時期 |
|---|---|---|---|---|
| 成果 |  |  |  |  |
| 安全 |  |  |  |  |

## リスクと対応
- 

## 今回求める意思決定
- 実施／追加調査／見送り

1ページに収まらない資料は、詳細を別紙へ移します。ただし、決定に必要な制約、主要リスク、判定基準は本文から外しません。

手順6：評価指標を3層に分ける

指標は、活動、成果、安全の3層で設計します。

活動指標：施策が予定どおり実行されたか。例は配信完了率
成果指標：目的とする結果が変わったか。例は30日以内再購入率
安全指標：副作用が増えていないか。例は配信停止率、苦情率

開封率が上がっても再購入が増えなければ、目的を達成したとは限りません。成果指標を活動指標で代用しないようにします。

判定基準には、比較対象、期間、対象者、最低必要件数を含めます。統計的な評価が必要なら、分析担当者へ検定方法やサンプルサイズを相談します。AIが出した目標値を、そのまま経営目標にしないでください。

手順7：反対意見を生成して弱点を探す

たたき台ができたら、別の依頼として反対意見を出させます。

次の企画に対し、承認者、現場担当、情報管理担当、対象顧客の4つの立場から反対意見を出してください。

各意見について、
- 反対の理由
- 企画内のどの記述が根拠か
- 追加確認すべき情報
- 修正すれば解消できるか
を表にしてください。

資料にない問題が起きると断定せず、可能性として表現してください。

反対意見の数を増やすことが目的ではありません。企画を中止すべき重大なリスク、追加調査で解消できる不確実性、好みの違いを分けます。

手順8：小さく検証する

本格導入の前に、期間、対象、予算を限定した検証を設計します。

誰を対象にするか
比較対象をどう置くか
何を記録するか
いつ評価するか
どの条件なら中止するか
誰が継続判断を行うか

施策が失敗した場合だけでなく、安全指標が悪化した場合の停止条件も決めます。検証後は、仮説IDごとに「支持された」「反証された」「判断不能」を記録します。

期待結果と確認方法

完成した企画書について、次を確認します。

[事実] のすべてに資料IDがある
[仮説] に検証方法がある
成功指標と安全指標が目的に対応している
制約外の施策が紛れ込んでいない
意思決定者が何を承認するのか一読で分かる
未確認事項が隠されていない

別の担当者に、事実だけを蛍光色、仮説だけを別の色で印付けしてもらう確認も有効です。ラベルなしの主張があれば、分類をやり直します。

失敗モードと対処

AIが市場規模や費用を作る

根拠資料がなければ削除し、必要な調査項目へ移します。概算が必要なら、計算式、入力値、出典、幅を示したシナリオとして扱います。

事実から因果関係へ飛ぶ

「解約が増えた」は事実でも、「価格改定が原因」は別の検証が必要です。原因候補を複数並べ、確認データを定めます。

反対意見に合わせて企画が膨らむ

すべての懸念を新機能で解消しようとせず、重大度と発生可能性で優先します。制約を超えた時点で、別企画として扱います。

指標が多すぎる

主要な成果指標を1〜2個、安全指標を必要最小限に絞ります。取得できない指標は採用しません。

採用しない条件

正本となる資料がない、企画目的が合意されていない、効果を測れない、重大リスクの責任者がいない場合は、AIによる企画書作成を先に進めません。まず調査計画または意思決定メモを作ります。

AI活用ナビの判断

AI活用ナビの判断： AIは、白紙を埋める道具としてより、材料を分類し、抜けを見つけ、反対意見を並べる道具として使う方が企画の品質を管理しやすくなります。採用判断は、根拠の量ではなく、重要な仮説を低コストで検証できるかを中心に行うことを推奨します。

確認日と公式情報

2026年7月29日に確認しました。

Anthropic「Prompting best practices」：明確で具体的な指示、出力形式と制約の指定、文脈の提供、複雑な入力の構造化などの原則を確認しました。本記事はAPIを使わない一般的な対話画面でも使える形へ整理しています。
Google「Prompt design strategies」：明確な指示、必要な文脈の追加、複雑な依頼を複数工程へ分ける方法、反復的に評価・改善する考え方を確認しました。

両ページには開発者向けの説明も含まれますが、本記事ではAPIキー、APIコード、モデル固有のパラメーターを使用していません。

PRIMARY SOURCES