なぜこう書くのか
スライドに書かれた文字をそのまま読み上げるだけのプレゼンは、聞き手の心に何も残りません。発表原稿のプロンプトを探す人の多くも、資料はできたものの「実際にどう話せばいいか」が決まらずに悩んでいます。しかし、ここで原稿と想定質問を同時に出力させようとすると、どちらの内容も薄くなってしまいます。そのため、このプロンプトではステップを2段階に分け、まずは原稿のみを作成し、想定質問はバリエーション側で個別に生成する構成にしています。
第1段落で役割を「スピーチコーチ」に設定したのは、単なる原稿ライターとコーチでは視点が異なるためです。ライターは文章をきれいに整えようとしますが、コーチは聴衆がどこで集中力を切らすかを見抜きます。第2段落の聴衆と発表時間は、同じ内容をどれほどの深さで話すべきかを決定づけます。役員向けの5分とチーム内の30分では、求められるスクリプトがまったく別物になります。
課題の指示で「冒頭の一言・本論・つなぎの一言」に分解させたのは、プレゼンが崩れやすい最大のポイントがスライドの「切り替え時」にあるからです。スライドは進んでいるのに話が途切れると、聞き手は準備不足を感じてしまいます。形式にある所要時間の秒数表記は、原稿が時間内に収まるかを事前に可視化します。スライドごとに秒数がわかれば削るべき箇所が一目でわかり、リハーサル前でもある程度の分量感覚がつかめます。
制約の段落は、このプロンプトで最も実用的な部分です。スライドの丸読みを禁止しないと、モデルは無難な選択として箇条書きをそのまま読み上げがちです。また、勝手な数値の捏造を防ぎブラケット表記にさせることで、本番で質問された際に答えられない数字が紛れ込むリスクを事前に排除できます。
用語が分からなければAha AIで: role-prompting, chain-of-thought
悪い例との比較
このスライドの発表原稿を書いてください
（スライド内容を貼り付け）
聴衆や時間の指定がないため、モデルは当たり障りのない長さの説明文を出力してしまいます。結果として資料を文章化しただけの「朗読」になり、10分の持ち時間に対して20分相当の分量が出てくることもあります。また、根拠のない数字が自然に混ざっていても作り話だと判別がつかず、本番直前に元データと突き合わせて確認する羽目になります。
バリエーション
原稿作成後 — 想定質問の準備
先ほど作成した原稿をベースに、{{参加の聴衆}}が発表後にしてきそうな質問を8個挙げてください。質問ごとに ①なぜその質問が出るのか ②現在の資料だけで回答可能か ③回答できない場合に追加で何を準備すべきか を記載してください。回答文を丸ごと書くのではなく、回答の骨子のみを1行ずつ添えてください。
""" {{スライドの概要}} """
想定質問の作成を原稿作成から切り離し、2つ目の指示として実行します。すでに原稿の内容を把握した状態で尋ねることで、質問の精度が格段に上がります。
発表時間が急遽短縮された場合
以下のスライド概要をもとに作成した発表を、{{発表時間}}以内に終わらせる必要があります。「必ず話すべきスライド」「1文に要約するスライド」「完全にスキップするスライド」に分類し、その理由を1行ずつ記載してください。その上で、残したスライドのみを使って原稿を再作成してください。
""" {{スライドの概要}} """
まず「削る判断」を行わせてから原稿を書かせる構成です。いきなり短縮を指示すると、すべてのスライドを少しずつ削ってしまい、要点がぼやけてしまいます。
モデル別の注意
分量を時間換算する際の計算精度はモデルによってばらつきがあります。原稿を受け取った後、「1分あたり300〜350文字を目安に、スライドごとの文字数をカウントして表形式で出力して」と追加で依頼することをおすすめします。
話すスピードには個人差があります。秒数計算はあくまで目安として活用し、実際に一度声に出して読んだ上で「3枚目のスライドを20秒短くして」のように再調整を依頼すると正確です。
関連プロンプト
最終更新 2026-09-02 · 誤りがありますか？ 知らせる