commit ac60a05af6aab0cae3b7396c3dd45b55faea4326 Author: snc Date: Fri Jul 17 14:57:26 2026 +0900 initial commit Co-authored-by: Cursor diff --git a/README.md b/README.md new file mode 100644 index 0000000..6f285be --- /dev/null +++ b/README.md @@ -0,0 +1,69 @@ +# Writing Presentations + +通したい企画や発表を、会議・プレゼンといった「尺のある場」で通すための読み上げ原稿を、AIとの対話で作るスキルです。 + +AIが1問ずつインタビューして、あなたの中にしかない具体（実際に見た場面・心の声・正直な気持ち・そもそもなぜやりたいのか）を引き出し、聞き手の心が動くプレゼン原稿に仕上げます。 + +## 何ができるか + +- AIが「実際に見た場面は？」「その時どう思った？」「なぜやりたいの？」と1問ずつ聞いてくれる +- 固定の質問リストではなく、あなたの回答を踏まえて次の質問が変わる +- 引き出した具体を、結論ファーストを保ったまま「問いを開いて、絵で閉じる」構成の原稿に組んでくれる +- 完成した原稿はMarkdownファイルとして保存される + +AIに丸投げして心が動くプレゼンは作れません。心を動かす具体はあなたの中にしかないからです。このスキルは、AIが作れないものをAIに引き出させる道具です。 + +## 提案スキル（writing-proposals）との関係 + +第9回講義で配布された提案スキル（writing-proposals）と組み合わせて使うことを前提としています。 + +- **提案スキル**：外を掘る（相手は誰か・相手の問いは何か・根拠は何か）→ 頭でわかる提案文書を作る +- **プレゼンスキル**：自分を掘る（見た場面・感じたこと・弱さ・原体験）→ 心が動くプレゼン原稿に磨く + +提案を通すプレゼンなら、先に提案スキルで提案文書を作ってから、このスキルに渡してください。 + +## 使い方 + +Cursorのチャット欄で、こう依頼するだけです。 + +``` +この提案を、会議で発表するプレゼンにしたい +``` + +または + +``` +プレゼンを作って +``` + +``` +発表原稿を書いて +``` + +AIが1問ずつ質問してくるので、答えていけばプレゼン原稿ができあがります。提案文書などの元原稿があれば、最初に渡してください。 + +## こんなときに使う + +- 会議やプレゼンで、自分の企画を発表して通したいとき +- 提案文書はできたが、発表すると「正しいのに、心が動かない」となりそうなとき +- 卒業制作など、自分の作ったものの価値を発表で伝えたいとき +- 話に自分のエピソードを入れたいが、何を話せばいいか自分でも言葉にできていないとき + +## フォルダの中身 + +``` +writing-presentations/ +├── README.md ← この説明書 +├── SKILL.md ← スキル本体（AIへの指示書） +└── references/ + ├── examples.md ← 対話と原稿の模範例 + └── output-quality.md ← 出力品質チェックリスト +``` + +`SKILL.md` がスキル本体（AIへの指示書）で、`references/` の模範例・品質チェックリストを参照します。 + +`SKILL.md` の下部には「チューニング欄」があります。自分の話し方・職場でよくあるプレゼンの場面・使わない表現・過去に話した内容を書き足すほど、あなた専用の型に育っていきます。 + +## 困ったとき + +何が起きても、まずはチャット欄でAIに状況を伝えてください。AIがエラーの内容を読み取り、次にやるべきことを教えてくれます。 diff --git a/SKILL.md b/SKILL.md new file mode 100644 index 0000000..263089b --- /dev/null +++ b/SKILL.md @@ -0,0 +1,135 @@ +--- +name: writing-presentations +description: 通したい企画や発表を、会議・プレゼンなど「尺のある場」で通す読み上げ原稿を作るスキル。対話で本人の中にある具体（実際に見た場面・心の声・弱さ・原体験）を1問ずつ引き出し、結論ファーストを保ったまま「問いを開いて、絵で閉じる」構成に仕上げる。「プレゼンを作って」「発表原稿を書いて」「プレゼンの原稿を作りたい」「発表の準備をしたい」「writing-presentations」と依頼された際に使用する。 +--- + +# Writing Presentations + +結論と中身が固まった元原稿（提案文書など）を、聞き手の心が動くプレゼンの読み上げ原稿に仕上げる。AIが説明を書くのではなく、**ユーザーの中にしかない具体を対話で引き出し、それを原稿に組む**ことに専念する。 + +## 大原則：説明するな、体験させろ + +人を動かすのは説明ではなく、聞き手の頭に浮かぶ「絵」。 + +- 説明「定例会議は非効率で、時間が無駄になっています」→ 頭には届くが、心は動かない +- 絵「先週の定例、30分のうち25分が、資料の読み上げでした。7人いて、口を開いたのは、2人だけだったんです」→ 場面が浮かび、聞き手が自分で「それは問題だ」と頷く + +AIは世界中の文章の平均から書くため、放っておくと誰にでも当てはまる「説明」に寄る。心を動かす具体はユーザーの中にしかない。だからこのスキルは、書く前にユーザーを掘る。 + +## 前提：結論と中身が先、心を動かすのは後 + +このスキルは、ビジネスライティングとして成立した元原稿（結論・根拠・数字）に、心を動かす要素を足すためのもの。 + +- 提案を通すプレゼンで元原稿がない場合 → 先に提案スキル（writing-proposals）で提案文書を作るよう案内する +- 提案以外（卒業制作の発表・報告など）の場合 → 「何を言い切るか（結論）」と「根拠」を最初の対話で固めてから進む + +## 基本ルール + +- **1問ずつ聞く。** まとめて質問攻めにしない +- **固定の質問リストを上から埋めない。** ユーザーの回答を踏まえて、次に掘る場所を変える。回答に場面の気配があれば場面を深掘りし、抽象語（非効率・重要・課題・改善）が出たら、その裏の具体的な場面に戻す +- **答えに詰まる質問には呼び水を添える。** 大きな質問を「それは何曜日の、何時ごろですか？」のような思い出しやすい小さな質問に割る +- **選択肢が役立つ質問は選べる質問ツールで聞く**（場・TPO・たとえの案の選択など）。エピソードを掘る質問は自由に語ってもらう +- **ユーザーは最初にまとめて渡してよい。** 元原稿や材料から分かることは聞かず、足りない分だけ掘る +- **エピソードを創作しない。** 原稿に使う具体は、ユーザーが語った本当にあったことだけ。AIが場面・数字・感情をでっちあげない。盛らない（賭け金と回収の粒度を合わせる） +- **ユーザーを否定せず、肯定的な言葉で伴走する** +- **手で直させない。** 材料が揃ってから一度に出力し、修正は具体を足して出し直す +- **出し直しのたびに、渡された具体が生きているか見張る。** AIは放っておくと、ユーザーの具体を平均的な説明に均してしまう。ユーザーの言葉・場面が消えかけていたら戻す + +## 引き出す材料（インタビューの中心） + +元原稿から流用できるもの（結論・根拠・数字）は聞き直さない。足りないものだけを掘る。 + +絵を浮かばせる材料には強さの順番がある：**①自分が実際に見た場面（最強・AIには作れない）→ ②聞き手に身近なたとえ → ③数字・データ（土台として必須だが、それだけでは絵にならない）**。まず①を探し、なければ②で補い、③で支える。 + +| # | 聞くこと | 役割 | +|---|---|---| +| ① | 誰に、どんな場で、何分話すか | 波の設計・TPO判断 | +| ② | まだ言葉にできていない、実際に見た場面 | 最強の絵。スローモーションで具体化 | +| ③ | その時の心の声（自分や周りは、どう思ったか） | 絵に感情を入れる | +| ④ | 身近なたとえ | 体験がない部分の補完。AIが案を出し、ユーザーが選ぶ | +| ⑤ | 弱さ・つまずいた瞬間・半信半疑だった正直な気持ち | 共感の入口（任意。堅い場では無理に出さない。ひと言でいい） | +| ⑥ | そもそも、なぜこれをやりたいのか（Why・原体験） | 「どうなる」と締めを動かす | +| ⑦ | 聞き手の頭に浮かぶ懸念点と、その答え | 気づかれる前に先出しして回収する材料 | + +### 場面の掘り方（絵にする3つのコツ） + +1. **超具体的にする**：場面をスローモーションで見る。「いつ・どこで」「周りに誰がいて、どんな顔だったか」を細かく +2. **心の声を入れる**：「その時、心の中で何と言っていましたか？」 +3. **たとえる**：聞き手が知らないことは、知っていることに乗せる + +たとえはAIが出してよい。ユーザーの体験の創作は禁止だが、みんなが知っている場面へのたとえはAIの得意技。「この困りを、誰でも知っている場面にたとえると？」の案を複数出し、聞き手にいちばん近いものをユーザーに選んでもらう。 + +## 進め方 + +1. **受け取る**：元原稿を読み、6ステップ構成（下記）に仮マッピングする。結論・根拠・数字は元原稿から流用し、足りないもの（絵・弱さ・フック・懸念点）を特定する +2. **掘る**：足りない材料を1問ずつ引き出す（「引き出す材料」参照） +3. **出力する**：6ステップの読み上げ原稿を生成し、Markdownファイルとして保存する +4. **品質チェック**：チェックリストで確認してから渡す（「品質チェック」参照） + +ユーザーが「もう十分」と言えば、その時点で出力に進む。 + +## 原稿の構成（6ステップ） + +引き出した具体を、この弧に流して読み上げ原稿にする。 + +``` +① フック 絵か問いで、つかむ（15〜30秒） +② 結論 何を提案するか、一言で +③ なぜ 今の困りを、絵で見せる ＋ 放置すると何を失うか（賭け金） +④ どうやって やり方を、短く +⑤ どうなる 変わった未来を、絵で見せる（原体験・Whyをここか締めで回収） +⑥ お願い 承認してほしいことを、はっきり +``` + +構成の判断基準： + +- **興味 ＝ 知りたい − いま知っている。** この差には「悪い差」（何の話かわからない不安 → 離脱）と「良い差」（続きが気になる → 前のめり）がある +- **結論は隠さない。** 隠すと悪い差になる。結論を先に渡すと悪い差が閉じ、「本当に効く？どれだけ変わる？」という良い差が開く。引っ張るのは結論の先だけ +- **良い差を開く道具は3つ**：問いかける（乱用注意）／チラ見せする（結論は渡した上で、中身の答えを焦らす）／賭け金を上げる（放置すると何を失うかを具体化。定位置は③なぜ） +- **開いた差は、絵で閉じる** +- **絵は結論の代わりではなく、根拠。** 絵だけ並べると「で、何が言いたいの」の作文になる。どちらかを残すなら結論 +- **波は短く刻む。** 問いを開いたら数十秒〜長くて1、2分で絵で回収する。仕事のプレゼンは、体は帰れないが心は一瞬で離れる場。映画型（最後まで伏せる）にしない +- **山場の絵は1つに絞る。** 全部を山にすると、全部が平らになる +- **懸念点は先出しする。** 聞き手の頭に浮かぶ懸念・突っ込みどころを、気づかれる前にこちらから伝えて答える +- **引っ張りは、注意の前借り。** 見合う絵で返せない引っ張りは「釣り」になり、次から話を聞いてもらえなくなる + +## 出力フォーマット + +- 話し言葉の読み上げ原稿として書く。書き言葉や体言止めの連続にせず、ユーザーの話し方・語彙に寄せる（チューニング欄参照） +- 尺に合わせて分量を設計する（目安：話し言葉で1分あたり300字前後） +- Markdownファイルとして保存する（例：`プレゼン原稿_定例会議.md`）。構成ラベルは見出し、読み上げ本文は地の文で書く。ファイルを保存できない環境では、コードブロックで出力する +- 模範例 → [references/examples.md](references/examples.md) + +## 品質チェック + +出力する前に、原稿がチェックリストを満たすか確認する。満たさない項目は直してから出力する。 + +→ [references/output-quality.md](references/output-quality.md) + +## やらないこと + +- エピソード・体験談の創作（本人の中にあるものだけを使う） +- スライド資料（ビジュアル）の生成。作るのは原稿＝話の中身まで +- 提案文書そのものの作成（提案スキルの責任範囲） +- 元原稿のビジネスライティングとしての品質担保（入力時点で成立している前提） +- 出力後にサブエージェントレビューを自動実行したり、先回りして案内したりすること（ユーザーが自分で頼む体験として残す） + +## チューニング欄（あなた専用に育てる） + +このスキルは完璧ではない。使いながら以下を書き足して、自分専用の型に育てる。 + +### 自分の話し方 + +（例：「〜なんです」で柔らかく話す／短い文でテンポよく） + +### 職場でよくあるプレゼンの場面 + +（例：月曜朝の部会で10分／役員への四半期報告で15分） + +### 使わない表現 + +（例：カタカナのビジネス用語／過度な煽り文句） + +### 過去に話した内容 + +（結果が良かったプレゼンやスピーチの原稿・メモを貼る。出来栄えではなく、相手が動いたかで選ぶ） diff --git a/references/examples.md b/references/examples.md new file mode 100644 index 0000000..431d8e9 --- /dev/null +++ b/references/examples.md @@ -0,0 +1,98 @@ +# プレゼン原稿の模範例 + +「定例会議を減らす」を題材に、対話で具体を引き出し、心が動く原稿に変わるまでの一周。会議の議題の1つとして話す、約2分の短いプレゼンの例（数十秒でも、自分の意見を伝えて通す場面はプレゼンに含む）。 + +## 目次 + +- 元原稿（説明だけの発表） +- 対話の流れ（例） +- 完成した原稿（具体を渡した後） +- 何が変わったか（Before / After の対応表） +- たとえをAIが出す（体験がない場合の例） + +--- + +## 元原稿（説明だけの発表） + +提案スキルで作った、ビジネスライティングとしては十分な発表原稿。結論も先、数字の根拠もある。だが心は動かない。 + +``` +定例会議の進め方について、提案があります。 +結論から言います。報告中心の定例3本を、隔週の開催に、変えたいです。 +いまの定例は週7本、あわせて週12時間。 +うち、報告だけの3本が、週3時間を占めています。 +隔週にすれば、月に6時間、年で約70時間が空きます。 +報告は、前日に資料を共有すれば、読み上げなくても回ります。 +まず、この3本から、隔週に。ご承認いただけないでしょうか。 +``` + +全部正しい。だが全部「説明」で、どこの会社にも貼れる＝誰のプレゼンでもない。ここに足りないのは、絵・賭け金・弱さ・原体験。 + +## 対話の流れ（例） + +元原稿から結論・数字は流用できるので聞き直さない。足りない具体だけを1問ずつ掘る。 + +> AI：この提案、誰に、どんな場で、何分くらい話しますか？ 定例の見直しなら、週次の全体会議で、議題の1つとして話す形が多いですが、どうでしょう？ +> ユーザー：そうです。会議のみんなの前で、議題の1つとして。2分くらいです +> AI：2分ですね。問いを開いて絵で閉じる波は1〜2回、山場の絵は1つに絞ります。今の困りで、実際に見た場面はありますか？ 直近の定例を、スローモーションで思い出してみてください +> ユーザー：先週の定例。30分のうち、25分が資料の読み上げ。7人いて、口を開いたのは、2人だけでした +> AI：その場面、強い絵になります。このまま何もしなければ、何を失いますか？ +> ユーザー：報告を聞くだけの時間が、年150時間。1ヶ月分です +> AI：あなた自身の、正直な気持ちはどうでしたか？ 半信半疑だったこと、当たり前だと思っていたことがあれば +> ユーザー：私も長いこと、この会議を当たり前だと思って、疑うことすらなかった。先週、ふと周りを見たら、全員が同じ顔をしていて +> AI：そもそも、なぜ変えたいと思ったんですか？ +> ユーザー：その時間で、本当はやりたい仕事が、あったからです +> AI：材料が揃いました。原稿を作ります + +## 完成した原稿（具体を渡した後） + +``` +先週の定例会議。30分のうち、25分が、資料の読み上げでした。 +7人いて、口を開いたのは、2人。 +──報告だけの定例3本を、隔週にしませんか。 +あの読み上げを聞くだけの時間が、1年で150時間。 +まるまる1ヶ月分が、毎年、消えています。 +正直に言うと、私も長い間、この会議を当たり前だと思って、 +疑うことすら、ありませんでした。でも先週、ふと周りを見て、 +全員が同じ顔をしているのに、気づいたんです。 +やり方は、シンプルです。報告の3本を隔週にして、 +資料は前日に共有する。それだけ。 +それだけで、年に70時間ちかく──消えた時間の半分が、戻ります。 +ずっと後回しにしてきた、やりたかった仕事に、手がつけられます。 +まず、報告の3本だけ。1ヶ月、試させてもらえませんか。 +``` + +## 何が変わったか（Before / After の対応表） + +企画の中身は同じ（定例3本を隔週に）。変わったのは、渡した具体だけ。 + +| 6ステップ | 元原稿 | 完成した原稿 | +|---|---|---| +| ① フック | なし（いきなり本題） | 沈黙の場面の絵（7人中2人） | +| ② 結論 | 先にある | 先にある（維持） | +| ③ なぜ | 数字のみ | 絵 ＋ 賭け金（年150時間＝1ヶ月分が消え続ける） | +| ④ どうやって | ある | 短く維持 | +| ⑤ どうなる | 数字のみ（年70時間） | 数字 ＋ 原体験（やりたかった仕事に手がつく） | +| ⑥ お願い | ある | 小さく・試しやすく（まず3本だけ、1ヶ月） | +| 弱さ | なし | 「私も当たり前だと思っていた」（ひと言・穏やかに） | + +注意点： + +- 原稿に出てくる絵は、すべてユーザーがインタビューで渡したもの。AIが場面を足していない +- 賭け金は150時間、回収は「半分＝70時間」と正直に。盛っていない +- 弱さは「内職していました」のような告白ではなく、堅い場でも出せる穏やかな自己開示にしている +- 分量は約400字＝渡された尺（2分）に収まる。尺が5分、10分と長い場合も6ステップは同じで、「問いを開いて、絵で閉じる」波の数を増やして分量を設計する。山場の絵は1つのまま増やさない + +## たとえをAIが出す（体験がない場合の例） + +自分が実際に見た場面がないときは、聞き手に身近なたとえで補う。たとえの案出しはAIの得意技。 + +> ユーザー：その現場には行ったことがなくて、見た場面がないんです +> AI：では、身近なたとえで絵にしましょう。「会議の資料の読み上げを聞いている時間」を、誰でも知っている場面にたとえると、こんな案があります。 +> ・朝礼で、長い校長先生の話を聞いている時間 +> ・機内で、毎回同じ安全ビデオを見せられる時間 +> ・説明書を音読されるのを、隣で聞いている時間 +> 聞き手にいちばん近いのは、どれですか？ +> ユーザー：校長先生の話が、いちばん伝わりそう + +選ぶのは必ずユーザー。聞き手を知っているのはユーザーだけ。 diff --git a/references/output-quality.md b/references/output-quality.md new file mode 100644 index 0000000..64b0c54 --- /dev/null +++ b/references/output-quality.md @@ -0,0 +1,34 @@ +# 出力品質チェックリスト + +プレゼン原稿を出力する前に、以下を満たすか確認する。満たさない項目があれば直してから出力する。 + +## 結論と構成 + +- [ ] 結論（何を提案・主張するか）が冒頭近くにあり、隠されていない +- [ ] フックが絵か問いで始まっている（一般論・自己紹介・前置きで始まっていない） +- [ ] 「なぜ」に絵と賭け金（放置すると何を失うか）が入っている +- [ ] 「どうなる」に変わった未来の絵が入っている +- [ ] 最後のお願いが具体的で、聞き手が Yes / No を判断できる +- [ ] 聞き手の懸念点を、気づかれる前に先出しして答えている + +## 絵と具体 + +- [ ] 原稿の中の場面・数字・感情は、すべてユーザーが渡したもの（AIが創作した体験がない） +- [ ] 抽象語（非効率・重要・課題・改善など）だけで押している箇所がない。裏の具体的な場面に戻している +- [ ] 山場の絵が1つに絞られている（全部を山にしていない） +- [ ] 絵が結論の根拠として置かれている（絵だけが並ぶ作文になっていない） +- [ ] 弱さを入れる場合、ひと言で、場のTPOに合っている（堅い場で長々と失敗談を話していない） + +## 興味の波 + +- [ ] 開いた問いが、すべて絵か答えで閉じられている（開きっぱなしの問いがない） +- [ ] 1つの引っ張りが数十秒〜1、2分以内で回収されている（最後まで伏せる映画型になっていない） +- [ ] 煽りすぎ・引っ張りすぎになっていない（引っ張りに見合う中身が返っている） +- [ ] 賭け金と回収の粒度が合っている（実際より大きく見せて盛っていない） + +## 話し言葉 + +- [ ] 声に出して読める話し言葉になっている（書き言葉・体言止めの連続になっていない） +- [ ] ユーザーの話し方・語彙に寄っている（チューニング欄・過去に話した内容を反映） +- [ ] 指定された尺に収まる分量になっている +- [ ] 上から目線・偉そうな表現がない