プロンプトガイド
Claudeでプロジェクト提案書を書く方法
承認される提案書は具体的だ。無視される提案書は曖昧だ。
AnthropicのClaudeは、ざっくりとしたプロジェクトのアイデアを、問題提起、範囲、スケジュール、そして関係者が実際に「はい」と言う気にさせる具体的な詳細を備えた構成立てた提案書に変えるのが得意です。Claudeが知らないのは、あなたの予算、チームの実際のキャパシティ、組織内の事情であり、それらを伝えない限り、「Xのプロジェクト提案書を書いて」という一言はどの会社にも当てはまりそうな一般的な内容になりがちです。解決策は、気配りのあるプロジェクトマネージャーがどうせ使う本当の制約をClaudeに渡すことです。提案書が誰向けか、実際に使えるものは何か、そしてその人に求める決定は何かです。
Claudeにプロジェクト提案書を書いてもらうには、解決する問題、提案書が誰向けでその人に求める決定は何か、実際の制約（チーム規模、おおよそのスケジュール、予算の範囲）を伝え、問題提起、提案するアプローチ、範囲、スケジュール、成功指標として構成するよう指示します。既存の背景資料、過去の提案書、メモがあれば貼り付け、具体的な計画にするには曖昧すぎる部分をClaudeに指摘してもらいましょう。
公開日
無料レッスン · アカウント不要Claudeと出会うなぜClaudeなのか?6 分無料レッスンを始める要点まとめ
- 提案書が誰向けで、その人にどんな決定を求めているかを伝えましょう。自分のチームが計画に使う提案書と、役員に予算承認を求める提案書は読み方が異なります。
- チーム規模、おおよそのスケジュール、予算の範囲という実際の制約をClaudeに伝えましょう。架空の制約に基づく計画は、実際の数字を知る人が読んだ瞬間に書き直す必要が出てきます。
- 作業内容の説明だけでなく、成功指標を具体的に求めましょう。うまくいったかどうかをどう判断するか書かれていない提案書は承認されにくく、後で振り返るのも難しくなります。
- 既存の背景資料を貼り付けましょう：過去の提案書、会議メモ、荒い構成案など。Claudeは与えられたものを整理し鋭くすることはできますが、あなたの具体的なプロジェクトの背景を作り出すことはできません。
- 送る前に特に範囲のセクションを注意深く読みましょう。本来の意図より曖昧または広い範囲は、提案書が後で問題を引き起こす最も一般的な原因です。
コピーして使える
今日から使えるプロンプト
ざっくりしたアイデアから最初の完全な草案を作る
[プロジェクトのアイデアを1～2文で説明]を提案したいです。これは[提案書が誰向けで、その人に求める決定]のためです。実際に使えるものはこちらです：チーム規模[規模]、スケジュールはおおよそ[期間]、予算はおおよそ[範囲、または「未定」]。問題提起、提案するアプローチ、範囲（明確に範囲外とすることを含む）、おおよそのスケジュール、成功指標を含む提案書の草案を書いてください。詳細が足りず推測した部分は指摘してください。
予算のようにまだ分からないことは正直に伝える方が、空白を埋めるために数字を作るより有用な草案になります。
まとまりのないブレインストーミングを問題提起に変える
解決したい問題について書いた、まとまりのない荒いメモはこちらです：[メモを貼り付け]。これを、なぜ重要で誰が影響を受けるかを説明する、2～3文の簡潔な問題提起に変えてください。解決策はまだ記述しないでください。解決策を提案する前に問題を明確に枠付けしたいです。
問題提起は解決策と分けておきましょう。解決策にすぐ飛ぶ提案書は、まだ問題の存在に納得していない読者を失うことが多いです。
範囲外を含めて範囲を定義する
これが私の提案するプロジェクトです：[説明]。このプロジェクトが含むものと含まないものを明確に述べる範囲セクションを書いてください。明確に範囲外とする具体的な項目を少なくとも3つ含めてください。提案書が意図より広く解釈されることを避けたいです。
範囲外を明確にリストすることは、後の混乱を最も防ぐ提案書の部分であることが多いです。
送る前に提案書の耐久性を試す
この提案書の草案を、承認するかどうかを決める関係者として読んでください：[草案を貼り付け]。承認前にどんな質問をしますか？スケジュール、範囲、成功指標のどこが非現実的または不明確に見えますか？何が間違っているかだけでなく、何が欠けているかを具体的に指摘してください。
これは早い段階の草案作成ステップとしてよりも、送信直前の最終確認として使うのが最も効果的です。
提案書のトーンを別の対象者向けに調整する
これは自分のチーム向けに書いたプロジェクト提案書です：[草案を貼り付け]。予算を承認する必要がある役員向けに書き直してください：ビジネスケースとコストから始め、技術的な詳細は簡潔にし、実装の詳細は最後の付録セクションに移してください。
同じプロジェクトでも、誰が読み何を決定する必要があるかによって、2つの異なるバージョンが必要になることが多いです。
構成
提案書のプロンプトに必要な5つの要素
この5つの要素が、曖昧なアイデアを関係者が実際に行動できるものに変えます。
解決策の前に問題提起
解決策を説明する前に、問題とそれがなぜ重要かを述べてください。まだ問題の存在に納得していない読者は、それに対する提案された解決策を真剣に受け取りません。
明確に範囲外とすることを含む範囲
プロジェクトが何をするか、そして同じくらい重要な、何をしないかを述べてください。範囲が定義されていない提案書は、各読者の頭の中でその人が思い込んだ意味まで膨らんでいく傾向があります。
架空ではなく実際の制約
一部がまだ不確かでも、実際のチーム規模、おおよそのスケジュール、予算の範囲をClaudeに伝えてください。架空の数字に基づく計画は、実際の数字が出てきた瞬間に作り直す必要があります。
明確に述べられた成功指標
プロジェクトが成功したとどう分かるかを述べてください。成功指標のない提案書は承認されにくく、それでも承認された場合、6か月後に振り返る方法がなくなります。
読者を知る
同じプロジェクトでも対象者が違えば必要な提案書は変わる
自分のチームの計画用に書く提案書と、役員から予算承認を得るために書く提案書は、同じプロジェクトを説明していても異なる役割を果たします。チーム向けバージョンは、読者がすでに関心を持っているため、実装の詳細に深く入り込めます。役員向けバージョンは、それがその読者が実際に下す決定だからビジネスケースとコストから始める必要があり、不要な詳細は求めている決定を遅らせるだけです。
誰が読み、その人にどんな決定を求めているかをClaudeに明示的に伝えてください。「これは来期の計画のために私のチーム向け」と「これは技術的な詳細を知らない副社長から予算承認を得る必要がある」は、同じプロジェクトでもClaudeを2つの異なる草案に導き、対象者を先に名指しすることで、あるバージョンを書いてから実際の読者には違うと後で気づくことを避けられます。
両方のバージョンが本当に必要な場合、両方をゼロから書くより、まずチーム向けの詳細なバージョンを書いて、それを役員向けに調整するようClaudeに頼む方が速いことが多いです。基礎となる事実は変わりません。変わるのは何を強調し、何を付録に移すかだけです。
よくある間違い
提案書が承認されず止まってしまう原因
これらのギャップが、妥当なアイデアを回答のないまま放置される提案書に変えます。
本来の意図より広い範囲
範囲外を述べないと、読者は自分の思い込みでそのギャップを埋めます。それはあなたが提案したかった範囲より大きいことが多いです。このプロジェクトが含まないものを明確に述べてください。
読者が下すべき決定が明示されていない
あなたが実際に何を求めているか、承認、予算、人員、開始の許可を述べていない提案書は、読者にどんな回答が必要か分からないままにします。
実際の制約の代わりに架空の数字
あなたが提供しなかったためClaudeが推測したスケジュールや予算は、架空であっても自信に満ちて聞こえ、実際の数字を知る人は提案書が現実と一致しないことに気づきます。
後でうまくいったか確認する方法がない
成功指標のない提案書は自信を持って承認しにくく、それでも承認された場合、6か月後にプロジェクトが実現したかを確認する合意された方法がありません。
既にあるものを使う
ゼロから始めるのではなく背景資料を貼り付ける
似たような過去の提案書、問題についての荒い会議メモ、あるいは半分完成した構成案があれば、記憶からプロジェクトを新たに説明するのではなく、それを貼り付けてください。Claudeは一文の説明から具体的な文脈、歴史、制約を作り出すよりも、既にある資料を整理し鋭くする方がはるかに信頼できます。
これは特に問題提起に当てはまります。問題が会議で、顧客の不満から、または似たようなことの過去の失敗した試みから出てきたなら、その文脈はプロンプトに含めるべきです。問題についての現在の要約だけから作られた問題提起は、問題を実在し解決する価値があるものにした具体的な詳細を失うことが多いです。
制約についても同様です。組織に標準の提案書テンプレート、この種のプロジェクトの典型的な予算範囲、通常のスケジュールの慣例があれば、一般的な構成に頼らせるのではなく、Claudeに直接伝えてください。組織がこの種の文書に期待する形に既に合致した提案書は、どこか他所のテンプレートのように読める提案書より真剣に受け取られます。
自分の組織で承認された提案書を、正式でなくても構わないので、フォルダにまとめて保存しておく価値があります。可能なときは、成功した提案書を自分の草稿と並べて貼っておきましょう。Claudeは、通りやすい形式の特徴、たとえば特定のフォーマルさの度合い、長い段落より短い段落を好む傾向、リスク対策の話から始める習慣などのパターンを見つけ出し、それを汎用的な構成に頼る代わりに、今書いている草稿に同じパターンを当てはめることができます。
送信前に
提案書が読者に届く前に確認すべきこと
まず範囲セクションを読み、それが多すぎず少なすぎず、あなたが実際にやろうとしていることを正確に記述しているか自問してください。これは本来の意図より曖昧または広い場合、後で最も問題を引き起こしやすいセクションです。プロジェクトが進行すると、誰もがそこを指し示すようになるからです。
すべての数字を現実と照らし合わせてください：スケジュール、チーム規模、予算。推測した数字に基づく自信満々な計画は、「スケジュールはまだ確定していません」という正直な言葉より悪いです。前者は誰かが読んだ瞬間にコミットメントとして扱われるからです。
ここでの構成はすぐに強力な草案を作りますが、組織とあなたの読者がこの具体的な提案書に実際に必要としているものについての判断は、送信前に依然としてあなた自身のものです。
明確な提案書は読まれる。曖昧な提案書は無視される
この構成はこの先のすべての提案書で再利用できます。Nightschool AIの無料レッスンは、範囲と対象者に関する判断を含め、Claudeを使った実際の仕事の文章作成タスクを扱います。
よくある質問
Claudeが提案書を作成する前に伝えるべき最も重要なことは何ですか？
提案書が誰向けで、その人にどんな決定を求めているかです。自分のチームが計画に使う提案書と、役員に予算承認を求める提案書は、同じプロジェクトでも異なる枠付けが必要です。
まだ予算の数字がない場合、Claudeに何か数字を伝えるべきですか？
いいえ。Claudeに数字を推測させるのではなく、予算はまだ確定していないと伝えてください。自信に満ちて聞こえる架空の数字は、実際の数字を知る人がそれを見た瞬間にコミットメントとして扱われます。
なぜ提案書には範囲外を明示するセクションが必要ですか？
それがないと、読者はプロジェクトが含むものについて自分の思い込みでギャップを埋めます。それは実際の意図より広いことが多いです。除外されるものを明示することでそのずれを防げます。
自分のチームと役員の両方に効果的な提案書はどう書けばいいですか？
まずチーム向けの詳細なバージョンを書き、次にそれを役員向けの読者用に調整するようClaudeに頼んでください。ビジネスケースとコストから始め、技術的な詳細を減らし、実装の具体的な内容を付録に移します。
ゼロから始める代わりに過去の提案書や会議のメモを使えますか？
はい、そうすべきです。既にある背景資料を貼り付けてください。Claudeはゼロから具体的なプロジェクトの文脈を作り出すよりも、実際の資料を整理し鋭くする方がはるかに優れています。
なぜ提案書には成功指標が必要ですか？
成功を測る明示的な方法がないと、提案書は自信を持って承認しにくく、承認されたとしても、後でプロジェクトが本当に約束を実現したかを確認する合意された方法がありません。
関係者に送る前に草案をどう確認すべきですか？
Claudeにその関係者として読んでもらい、承認前に持つであろう質問を列挙してもらいましょう。その後、送信前に草案の各数字を実際の制約と別途照らし合わせてください。
組織に既に標準の提案書テンプレートがある場合はどうすればいいですか？
草案を一般的な構成に頼らせるのではなく、それを直接Claudeに伝えてください。組織が期待する形式に既に合致した提案書は、そうでない提案書より真剣に受け取られます。