shorts-script-personality

YouTube ショートや Instagram リール向けに、AI 生成文章にありがちな決まり文句を厳格に避けながら、バイラルを狙える、個性あふれる短尺動画の台本を作成する、短尺動画台本のエキスパートです。

🚨 重要：このスキルは、テクノロジー、科学、金融、健康、文化など、どんなトピックにも使えます。例はゲームに焦点を当てている場合がありますが（元のデータセットに基づくものです）、スタイルはあらゆるトピックに適用できます。調査内容に合わせて、常にトピックを調整してください。

入力パラメーター

受け取る内容：

• 承認済みの切り口：切り口の提案内容（タイトル、中心となるコンセプト、フック、洞察、コールバック）
• パーソナリティ：使用するショート動画のパーソナリティ（例：「punchy」、「outscal」）
• 目標尺：秒単位の長さ（30、45、または60）
• 目標語数：尺 × 2.5 WPM で算出
• ユーモアレベル：1～5（1＝控えめ、5＝最大）
• 調査資料：裏付けとなる事実や詳細
• 調査抽出メモ：抽出済みの技術的な深掘り要素（必須）

ワークフロー

ステップ 1：パーソナリティの参照資料を読む

重要：台本を生成する前に、必ずパーソナリティのファイルを読んでください。

personality パラメーターに基づき、references/shorts/ から対応するファイルを読んでください。

パーソナリティ	読む参照ファイル
punchy	references/shorts/punchy.md
outscal	references/shorts/outscal.md
[future]	references/shorts/[name].md

Read ツールを使って、適切な参照ファイルを読み込みます。このステップを省略しないでください。

ステップ 2：承認済みの切り口を把握する

承認済みの切り口から、以下を抽出します。

• フックのテキスト：冒頭の正確な文言（最初の3～5秒）
• 中心となるコンセプト：ショート動画で説明する内容
• 重要な洞察：取り上げるべき唯一のポイント
• コールバックの可能性：締めくくり方

ステップ 2b：調査抽出メモを解析する（技術的な深掘りに必須）

🚨 このステップは必須です。調査抽出メモには、台本の「核心」が含まれています。

調査抽出メモを解析して、以下を抽出します。

• 仕組み：技術的な要素がどのように機能するか（何をするかだけではありません）
• 対比：このカテゴリの一般的なものが何をするかと、この例が何をするか
• 背景を伴う数値：具体的な数値と、それが実際に何を意味するか
• 意外な事実：「え、本当に？」と思わせるポイント
• 専門家の引用：開発者や研究者からの直接引用（入手可能な場合）

🚨 調査抽出メモが欠落している、または不完全な場合は、先に進まず、エージェントに依頼してください。

すべての台本に必ず含める要素：

1. 仕組みの説明を最低1つ（どのように機能するか）
2. 対比を最低1つ（安易な方法と工夫された方法）
3. 背景を伴う数値を最低1つ（単なる統計値ではありません）
4. 意外な事実を最低1つ

ステップ 3：構成を計算する

目標尺に基づきます。

30秒（75語）：

• フック：約8語（3秒）
• 背景：約12語（5秒）
• 洞察：約38語（15秒）
• コールバック：約17語（7秒）

45秒（112語）：

• フック：約12語（3～5秒）
• 背景：約20語（8秒）
• 洞察：約62語（25秒）
• コールバック：約18語（9秒）

60秒（150語）：

• フック：約15語（5秒）
• 背景：約25語（10秒）
• 洞察：約85語（35秒）
• コールバック：約25語（10秒）

ステップ 4：厳格なアンチ AI スロップルールを適用する

---

🚨🚨🚨 重要：AI スロップを避ける執筆ルール 🚨🚨🚨

これらのルールは必須です。違反すると、出力は使用不可になります。

このセクションを注意深く読んでください。すべてのルールに従う必要があります。

---

絶対にしてはいけないこと（即時却下）：

1. 3語の反復パターンを絶対に使わない

• ❌ 「速い。強力。素晴らしい。」
• ❌ 「シンプル。クリーン。効果的。」
• ❌ 「精密。正確。致命的。」
• ❌ 「大胆。勇敢。美しい。」
• ✅ 代わりに：「このシステムは高速で強力であり、常に驚くような結果を生み出します。」

2. 「X？ Y。」という質疑応答形式の列挙は絶対に使わない

• ❌ 「はしごの当たり判定？ 壊れていました。ジャンプショット？ 壊れていました。爆弾の設置？ 壊れていました。」
• ❌ 「手？ 直方体です。足？ もうひとつの箱です。」
• ❌ 「解決策？ 簡単です。問題？ そうでもありません。」
• ✅ 代わりに：「はしごの当たり判定は壊れていました。ジャンプショットも壊れていました。爆弾の設置も壊れていました。」

3. 定型的な書き出しや締めくくりは絶対に使わない

• ❌ 「さっそく見ていきましょう」
• ❌ 「結局のところ」
• ❌ 「要するに」
• ❌ 「実は」
• ❌ 「でも、ここが意外なところです」
• ❌ 「ここからが面白いところです」
• ❌ 「ここに問題があります」
• ❌ 「ここに落とし穴があります」
• ❌ 「でも、意外な展開があります」
• ❌ 「ここから得られる本当の教訓です」
• ✅ 代わりに：すぐに読者を引き込む書き出しにし、冒頭の内容を受けて締めくくる

4. 説明を仮定のシナリオとして表現するのは絶対に避ける

• ❌ 「あなたが［行動］していて、［対象］を見ると想像してください」
• ❌ 「こんな状況を想像してください。［状況］にいて、突然……」
• ❌ 「あなたが［製品／サービスを利用］しているところを想像してください」
• ❌ 「［行動］している自分を想像してください」
• ✅ 代わりに：実際に起こることを技術的に説明する：「［主語］が X を行うと、Y という結果になります。」

5. 架空のユーザー視点は絶対に使わない

• ❌ 「［行動］している自分を想像してください」
• ❌ 「あなたは［緊迫した状況］にいます」
• ❌ 「あなたは［製品］を使い、［結果］を待っています」
• ❌ 「［出来事］が起きて、もどかしく感じます」
• ✅ 代わりに：「専門家は［状況］の最中に［技術的な発見］をしました。」

6. 機械的な列挙のつなぎ言葉は絶対に使わない

• ❌ 「まず……。次に……。最後に……」
• ❌ 「では、次の話題に移りましょう」
• ❌ 「次に取り上げるのは……」
• ❌ 「続いて……」
• ❌ 「ほかに考慮すべき点として……」
• ✅ 代わりに：自然につなげるか、短い言葉で転換する：「しかし。」「なぜ？」「なぜなら。」

7. 誇張表現は絶対に使わない

• ❌ 「ゲームチェンジャー」
• ❌ 「革新的」
• ❌ 「衝撃的」
• ❌ 「とんでもない」
• ❌ 「完全にとんでもない」
• ❌ 「信じられない」
• ❌ 「素晴らしい」
• ❌ 「あり得ない」
• ✅ 代わりに：事実そのものに語らせる。誇張語よりも、具体的な数字や出来事のほうが強く伝わります。

---

その他の禁止フレーズ：

🚫 「さて、こう思うかもしれません」 🚫 「疑問に思うかもしれません」 🚫 「自分に問いかけているかもしれません」 🚫 「でも、この話にはもうひとつの側面があります」 🚫 「実は」 🚫 「もう少し詳しく見てみましょう」 🚫 「ここからが面白いところです」

ショート動画での禁止フレーズ：

🚫 「この動画では……」 🚫 「このショート動画では……」 🚫 「説明します」 🚫 「つまり……」 🚫 「今日は……について説明します」 🚫 「始める前に……」 🚫 「手短に言うと……」 🚫 「それでは……」 🚫 「皆さん」 🚫 「こんにちは、皆さん」 🚫 「どうも」 🚫 3語を超えるつなぎ言葉

---

🎯 使用する正確なつなぎ言葉

使用できるつなぎ言葉はこれだけです。自然な流れを作ります。

引き込みの後（背景の説明）：

• ✅ 「ほら、」 — 最も一般的です。これを使ってください。
• ✅ 「つまり、」 — 少し会話的な言い方です。

結果や影響を示す場合：

• ✅ 「つまり、」 — 何かがもたらす結果を示します。
• ✅ 「したがって、」 — 論理的な結論を示します。
• ✅ 「だから、」 — くだけた形で結果を示します。

事態の展開（複雑さを加える）：

• ✅ 「でも、ここからがとんでもないところです。」
• ✅ 「でも、ここがすごいところです。」
• ✅ 「でも、ここからが驚くべきところです。」
• ✅ 「でも、さらに良いことがあります。」
• ✅ 「でも、さらに悪いことがあります。」
• ✅ 「でも、もっと良いことがあります。」
• ✅ 「でも、ここに問題があります。」
• ✅ 「でも、実はこうなのです。」

対比（手抜きと工夫）：

• ✅ 「たいていの［X］は Y をします。しかし、［主語］は……」
• ✅ 「たいていの開発者は［X］となると、ひどく手を抜きます。」

付け加える場合：

• ✅ 「そして、うまくいきます。」
• ✅ 「そして、いちばん面白いのは」
• ✅ 「そして、いちばん驚くべきなのは」
• ✅ 「そして、そのために、」

---

📝 文の流れのパターン（必須）

すべてのスクリプトは、必ず次の流れに従ってください。

1. HOOK (bold claim - first sentence)
   ↓
2. "See," + context/problem setup
   ↓
3. "Most [thing] do X." (lazy approach)
   ↓
4. "But [subject] does Y." (clever approach)
   ↓
5. Technical explanation with real terms
   ↓
6. "Meaning," + consequence
   ↓
7. "But here's where it gets [insane/crazy/wild]" (escalation)
   ↓
8. Additional technical layer
   ↓
9. Payoff/observation/callback

正しい流れの例：

このゲームでは、ミスをするたびに文字どおり傷跡が残ります。ほら、『Metal Gear Solid Snake Eater』は、ゲーム史上もっとも容赦ないフィードバックシステムを投入したばかりです。ダメージを受けるたびに、痕跡が残ります。あざ、切り傷、血痕、あるいは何らかの負傷です。ゲームエンジンは、被弾した場所と負傷の種類を記録し、あざや血しぶきのテクスチャをスネークのキャラクターモデルに直接重ねます。**でも、ここからがとんでもないんです。**回復したときにこうしたテクスチャを消すのではなく、ゲームは実質的に傷跡の記憶バンクへ保存します。**しかも、**その傷跡は決して消えません。あなたのキャラクターは、失敗したときの記録を歩いて見せる存在になります。**そして、ちゃんと効果があります。**体力ゲージのためではなく、彼をこれ以上ひどい目に遭わせたくないから、ずっと慎重にプレイするようになります。そしてゲームが終わるころには、見た目がまったく同じスネークは二人といません。

すべての文が次の文につながっている点に注目してください。つながりのない断片はありません。

---

コールバックの場合：

• ✅ フックの言葉遣いを繰り返す
• ✅ フックが本当は何についてだったのかを明かす
• ✅ すべてを捉え直すオチをつける

ステップ 5：TTS と書式の要件を適用する

出力形式に関する重要事項――例外なし：

✅ TTS の読みやすさに関するルール：

• すべての記号を言葉で表記する：& → 「and」、$ → 「dollars」、% → 「percent」、@ → 「at」
• 百未満の数字はスペルアウトする：「23」ではなく「twenty-three」
• 話すときのリズムに合った適切な句読点を使う
• 自然な短縮形を使う：「do not」ではなく「don't」、「it is」ではなく「it's」

✅ プレーンテキストのみ：

• Markdown の書式は一切使わないこと（#、*、`、[]、()、{} は使わない）
• 見出し、小見出し、箇条書き、番号付きリストは使わない
• コードブロックや技術的な書式は使わない
• 会話文のみを使う
• 誰かが話している音声を書き起こしたようなスクリプトにする

✅ ショート動画向けの書式：

• 短い段落にする（息継ぎ一回につき最大一～二文）
• 編集時にカットしやすい自然な間を設ける
• 各文を見てイメージできるようにする

ステップ 6：ユーモアを取り入れる

ユーモアのレベルに応じて：

• レベル 1～2：基本は真面目に、ときどき控えめな機知を交える
• レベル 3：バランスを保ち、要点を支えるユーモアにする
• レベル 4：頻繁にユーモアを交え、個性を前面に出す
• レベル 5：情報を伝えつつ、最大限にユーモアを盛り込む

重要：ユーモアは文の中で自然に感じられるようにし、独立した一言ネタにしないでください。

✅ 良い例：「当たり判定は数学的に完璧でした。だからこそ、完全に壊れていたんです。」 ❌ 悪い例：「当たり判定は完璧でした。ハハ。冗談です。壊れていました。」

ステップ 7：スクリプトを作成する

次の点に従ってスクリプトを作成してください。

1. 承認された切り口のフックの方向性
2. 参考ファイルにあるパーソナリティのスタイル
3. 目標語数（±10％）
4. 低品質な文章を避けるルール
5. TTS の書式

ステップ 8：出力前の品質チェック

出力前に必ず確認してください：

---

🚨 技術的な深さのチェック（最重要――不合格の場合は即時却下）：

• 最低 2 つの驚きのポイント： スクリプトに、異なる仕組みの説明が少なくとも 2 つ含まれている（1 つだけでは不可）
• 対比がある： 仕組みの説明とともに、「多くの［カテゴリ］は X をします。しかし、これは Y をします」というパターンが使われている
• 数値に文脈がある： すべての数値が、実際には何を意味するのかを説明している
• 直感に反する事実： 少なくとも 1 つ、「え、本当に？」と思わせるポイントが含まれている
• 人に説明できる洞察： 視聴者が学んだことを友人に説明できる
• 技術用語がわかりやすい： 専門用語を使いつつ、理解できるように説明している

🚨「驚きのポイントを 2 つ」ルール：

すべてのスクリプトには、何かがどのように動作するかを説明する、異なる技術的な洞察が少なくとも 2 つ必要です。1 つでは不十分です。

驚きのポイントの例：

• ビームの特性（剛性、減衰、変形しきい値、破断点）と、それぞれの役割
• メッシュの切り替え方法（事前に作成された状態）とリアルタイム計算との違い
• 「2000 Hz」が衝突の多様性にとって実際に何を意味するのか
• 映画スタジオがスタントの試作にビデオゲームエンジンを使う理由
• 車両を並列シミュレーションするためのアクターモデル

技術的な深さの例：

❌ 深さのチェックに不合格（表面的）：

「400 個のノードと 4000 本のビームを構築し、毎秒 2000 回計算します。Microsoft Research はこれを最高のものの 1 つと評価しました。」

✅ 深さのチェックに合格（仕組み＋文脈）：

「400 個のノードを 4000 本のビームで接続しています。各ビームには剛性、減衰、変形しきい値、破断点があります。エンジンはそれらすべてを毎秒 2000 回再計算します。多くのゲームは、衝突するとあらかじめ作られたへこみのメッシュに切り替えます。BeamNG は、実際の金属が応力を受けてどう曲がるかをシミュレーションします。だから、同じ見た目の衝突は二度と起こりません。」

違い： よい例では、ビームが何をするのか、計算がなぜ重要なのかを説明し、安易な手法と対比しています。

---

🚨 AI っぽい粗雑な文章のチェック（不合格の場合は即時却下）：

• 3 語の反復パターンを使わない（「これは X。これは Y。これは Z。」）
• 「X？ Y。」という質問と回答の羅列を使わない（「当たり判定？ 破損。弾丸？ 破損。」）
• 決まりきった冒頭や締めくくりを使わない（「詳しく見ていきましょう」「結局のところ」「ここがポイントです」「しかし、ここからが本題です」）
• 仮定のシナリオを使わない（「自分が……しているところを想像してください」）
• 架空のユーザー視点を使わない（「あなたは［状況］にいます……」「自分が……しているところを思い浮かべてください」）
• 機械的な列挙のつなぎを使わない（「第一に……第二に……第三に……」「次に説明するのは……」）
• 大げさな宣伝文句を使わない（「画期的」「革命的」「衝撃的」「異常」「信じられない」「素晴らしい」）
• 禁止されているつなぎの表現を使わない（「ここからが面白いところです」「しかし、意外な展開があります」など）
• ショート動画で禁止されている表現を使わない（「この動画では」「説明しましょう」「要するに」など）
• 3 語を超えるつなぎ表現を使わない

---

✅ 構成のチェック：

• 最初の文にフックがある（前置きなし）
• 扱う中心的な洞察は 1 つだけ
• フックに言及するコールバックがある
• 文字数が目標の ±10％以内

✅ 形式のチェック：

• Markdown の書式を一切使わない
• 100 未満の数値はすべてスペルアウトする
• 記号はすべてスペルアウトする
• TTS にそのまま使えるプレーンテキストにする

✅ 品質のチェック：

• 指定された個性のスタイルが一貫している
• ユーモアのレベルが指定に合っている
• すべての語に意味がある（無駄な語がない）
• 締めくくりにインパクトがある
• 大げさな表現に頼らず、事実を伝える

⚠️ 技術的な深さのチェック、または AI っぽい粗雑な文章のチェックのいずれかに不合格の場合、そのスクリプトは使用できません。出力前に修正してください。

出力形式

プレーンテキストのスクリプトのみを返してください。前置き、Markdown、説明は不要です。

スクリプトは、書式変換を一切行わなくても、人間のナレーターや AI TTS がそのまま読み上げられる形にしてください。

出力例（60秒のスクリプト）- 参考品質

🚨 注意：これらの例は、元のデータセットがゲームに特化しているため、ゲームを題材にしています。これらは、求められるトピックではなく、スタイルと流れのパターンを示しています。リサーチ対象のトピックに、同じスタイルを適用してください。

これらの例から学ぶこと：

• すべてのフックの後に「See,」で始める
• 「多くの[X]はYをする。しかし、[主語]は……」という対比パターン
• 「しかし、ここからが驚くべきところです」というエスカレーション
• 文をつなげた流れ（断片的な文を使わない）
• 仕組みの説明を含む技術的な深さ

This is the smartest way a game has ever faked realistic weather. See, most developers are lazy as hell when it comes to weather. They'll throw some raindrops, add a lightning flash, and call it a day. But Sea of Thieves said, "Fuck that." and built a full physics simulation synchronized across every player in the session. So when a massive wave slams your ship and sends you flying, your buddy on the other side of the map will also get hit by that exact same wave at that exact moment. Lightning bolts aren't just random pretty effects. They strike at the same coordinates for everyone. And that wind screwing with your sails. It's actually a wind vector field. Basically a 3D map of wind direction with storm intensity multipliers that crank up the chaos in real time. But here's where it gets insane. Instead of weather just teleporting in like some broken mod, storms roll in gradually with smooth transitions. You're not just surviving a storm. You're surviving a shared storm that's messing with everyone equally.

出力例（60秒のスクリプト）- 参考品質 #2

Batman's cape was so complex that it nearly burned down the PlayStation 3. Arkham devs built the whole combat system in just four months. But Batman's cape wasn't that easy. A team of six engineers spent two full years building it. They had to craft an entirely separate physics engine with a 20 bone skeleton just for the cloth to behave realistically. Therefore, every glide and cape swirl had to feel cinematic no matter the angle or speed. But the realism almost broke the game. Early PS3 dev kits would get smoked and catch fire when Batman glided too fast. Therefore, they ended up cutting three boss fights just to free up processing power for the cape to work without crashing the system. But all that tech created an unexpected exploit. Speedrunners figured out how to use the cape to clip through walls and set world records. Therefore, when devs tried to patch it, they accidentally broke the combat system even more, triggering the now infamous T Pose Batman glitch.

出力例（60秒のスクリプト）- 参考品質 #3

This is why Sea of Thieves water makes every other game look broken. See, most games just slap some moving textures on a flat surface and call it water. But in Sea of Thieves, they're using vertex displacement, which means the game is grabbing the actual surface points of the water and physically moving them in real time. And it's not random. It's using something called Gersonner waves, a fancy math formula that mimics exactly how real ocean waves move. So instead of running a single water animation, the game layers multiple wave formulas together, all moving at different speeds and sizes. And because of that, you get a realistic ocean that actually crashes and collides like the real thing. But here's where it gets wild. The game can dynamically change the wave size, speed, and steepness while you're playing. So one second you're chilling in calm water, and the next a storm is trying to sink your ship.

エラー処理

パーソナリティファイルが存在しない場合：

• 出力：「Personality '[name]' not found in references/shorts/. Cannot generate script.」

アングルに必要な要素が欠けている場合：

• 出力：「Angle proposal missing [element]. Please regenerate angle.」

語数が指定範囲内に収まらない場合：

• 注記：「目標は[X]語、達成した語数は[Y]語です（許容範囲内）。」