プロンプト改善提案

提案の全文

全体傾向

動画チェックで見つかった問題の大半は「画面が長時間ずっと止まって見える」「ナレーション音声が映像より先に終わる」「テキストが画面下端で切れる」の3種類に集中している。また、ルールを無視して独自のレイアウトコードを書いてしまうケースも複数あり、その修正に担当者の手間がかかっている。今後これら4点を重点的に対処すると、手直し回数と動画NG件数をまとめて減らせる見込みがある。

⚠️ 今回データがある本数は 13 本中、実際にシーン情報が記録されている動画は 4 本のみです。残りはシーン情報なし（未記録または空振り）のためサンプルが少なく、以下の提案は「方向性はほぼ確実だが、件数の根拠は限定的」として読んでください。

具体的なプロンプト追加・修正案

1. [優先度: 高] 長いシーンでは要素を時間差でアニメーションさせ「止まって見える」を防ぐ

• 何が起きてた？：進撃バトル動画（5/25版）では、画面解説シーン（3つ）が合計10〜13秒間も映像がまったく動かないと指摘された。「さあああ」と名付けられた別の動画でも、情報まとめや画面解説など計7つのシーンで同様の指摘があり、なかには「52秒間ずっと止まって見える」という深刻なケースも出ている。これは現在のプロンプトにある「シーン開始から要素を0.2〜0.4秒ずつずらして出す」というアニメのルールが、5秒以上続くシーンでは足りないことが原因。過去4本中3本で発生している。

• 追加文案：

  # 長尺シーンの動き出しルール（5秒以上のシーンに必須）
  
  data-duration が 5秒以上のシーンでは、シーン後半にも必ず動きを入れること。
  具体的には「最後の要素の入りアニメが シーン開始秒 + 1.5秒 以内に終わらないようにする」か、
  または「中盤（シーン開始 + duration × 0.5 秒あたり）でいずれかの要素に強調アニメ（scale: 1→1.05→1 を 0.4秒 で tl.to）を追加する」。
  例：8秒シーン（data-start=10）なら、tl.to("#強調したいid", { scale: 1.05, duration: 0.2, yoyo: true, repeat: 1, ease: "power1.inOut" }, 14) などを必ず入れる。
  これを守らないと映像が長時間静止してTikTokで離脱される。
  

• 採用するとどうなる？：「画面が止まって見えてNG」という動画チェックの指摘が大幅に減り、シーンごとに手動でアニメを追加し直す手間がなくなります。

• 副作用の懸念：強調アニメが毎シーンに増えると、全体のテンポが賑やかすぎる印象になる可能性がある。落ち着いたシーンでは scale の幅を小さめ（1→1.03程度）にするよう一言補足するとよい。

2. [優先度: 高] ナレーション文字数とシーン秒数の上限をより厳しく明示する

• 何が起きてた？：進撃バトル動画（5/25版）の 5 シーン目（コツリスト）でナレーション音声が 0:57 に終わったのに映像が1:29まで続き、32秒間も無音になった。同じ動画の「さあああ」版でも 7 シーン目（リスナーへの声かけ例）で50秒間の無音が発生している。どちらもナレーション文字数がシーンの秒数に対して少なすぎることが原因だった（「さあああ」版7シーン目はナレーション23文字なのにシーンが長大になっていた可能性）。過去4本中2本で「音ズレ」エラーが発生している。

• 追加文案：

  # ナレーション文字数とシーン秒数の対応（再掲・強化）
  
  data-narration の文字数と data-duration の関係を必ず守ること：
  - 最低ライン：文字数 ≥ duration × 4（短すぎると無音区間が生まれる）
  - 最大ライン：文字数 ≤ duration × 6.5（長すぎるとTTSがカットされる）
  - 例：8秒シーン → 32〜52文字が適正範囲
  
  文字数が少なくなりそうなら duration を短くするか、narration に説明を足すこと。
  duration を長く取りたいなら narration もそれに合わせて伸ばすこと。
  

• 採用するとどうなる？：「ナレーションが終わったのに画面だけ続く」という見ていて不自然な無音区間がなくなり、動画チェックで最もダメージが大きい「音ズレエラー」を防げます。

• 副作用の懸念：最低文字数を設けることで、情報が少ないシーン（締めくくりなど）でもナレーションを無理に長くしなければならない場面が出るかもしれない。締めくくりシーンは例外として「20文字以上あればOK」と補足してもよい。

3. [優先度: 高] HyperframesのCSSクラス構造を使わず独自コードを書いてしまうケースをより強く禁止する

• 何が起きてた？：「テスト」と名付けられた2本の動画で、Hyperframesが用意しているレイアウト用のクラスをまったく使わず、座標や色を自分で書いた完全独自のHTMLを出力していた。担当者が手動で修正するとき、position:absolute;top:703px; のような座標指定をすべて書き直す必要があり、2回とも大規模な全文差し替えが発生している。過去4本中2本で発生。

• 追加文案：

  # 独自CSSの出力は絶対禁止（最重要）
  
  position:absolute / top / left / right / width / height / background-color / font-size などを
  style属性に自分で書くことは禁止。どんな理由があっても独自の .card / .pill / .bg-xxx などのクラスを
  自作してはいけない。必ず「利用可能なクラス」セクションに記載のクラスだけを使うこと。
  
  もし既存クラスで表現できない場合は、表現を諦めてシンプルにするか、
  「font-size の微調整（1要素のみ）」または「margin の微調整」だけを inline style で行うこと。
  それ以外の style 記述は出力前のチェックリストで必ず削除すること。
  

• 採用するとどうなる？：独自コードによる大規模な書き直しが発生しなくなり、担当者の手動修正作業が大幅に減ります。また、Hyperframesのデザインルールを守った統一感のある動画が安定して出力されるようになります。

• 副作用の懸念：禁止をより強調することで、AI がレイアウトの自由度に詰まって必要な微調整もしなくなる可能性がある。「1要素の font-size 微調整は OK」という現行の例外規定は残すこと。

4. [優先度: 中] テキストが画面の下端で切れないよう、1シーンの情報量に上限を設ける

• 何が起きてた？：進撃バトル動画（5/25版）の 2 シーン目（情報まとめ）では「Top100」「6月PK王覇戦」という文字が画面下端で切れており読めなかった。同じく 6 シーン目（情報まとめ）でも「新規視聴者を巻き込む日」が切れていた。これはシーン1つに情報を詰め込みすぎて、テキストが縦に溢れたことが原因。過去4本中1本で発生しているが、内容が多いイベント解説系の動画では再発リスクが高い。

• 追加文案：

  # 1シーンの情報量の上限（テキスト切れ防止）
  
  hf-stage-inner 直下の要素数は最大4個まで（既存ルールを再確認）。
  特に hf-card を使うシーンでは、カードの本文（hf-card__body）は2行以内に収めること。
  3行以上になりそうな場合はカードを分割するか、別シーンに移すこと。
  hf-body や hf-note に長い文章を入れる場合も、全角で30文字以内を目安にすること。
  「1画面1メッセージ」の原則を最優先する。
  

• 採用するとどうなる？：テキストが画面の下で切れて読めない、という動画チェックのエラーが出なくなります。1つの画面に伝えることが絞られるので、視聴者にとっても内容が伝わりやすくなります。

• 副作用の懸念：情報量を制限するとシーン数が増え、合計秒数が目安の100秒を超えてしまうことがある。「シーン数が増えそうなら、内容の優先度を付けて削る」という一言を添えるとよい。

5. [優先度: 中] 画面解説シーン（スクリーンショット1枚見せ）には必ず途中でアニメーションを入れる

• 何が起きてた？：進撃バトル動画（5/25版）では画面解説シーンが3つあり、いずれも「シーン全体で映像が完全に静止している」と指摘された（それぞれ 8.1秒・12.9秒・12.3秒間の静止）。画像1枚を大きく表示するシーンは動きを入れにくく、現在のプロンプトではその対策が書かれていない。過去4本中1本で集中発生。

• 追加文案：

  # 画面解説シーン（スクリーンショット1枚表示）の必須アニメーション
  
  hf-img--tall を使う画面解説シーンで duration が 6秒以上の場合、以下を必ず行うこと：
  1. 画像の入り：tl.from で opacity: 0 + scale: 0.94 のフェードインを入れる（既存ルールで OK）
  2. シーン中盤（開始秒 + 2〜3秒後）：画像に対して tl.to で scale: 1 → 1.03 の軽いズームを入れる
     例：tl.to("#imgId", { scale: 1.03, duration: 2.5, ease: "power1.inOut" }, data-start + 2)
  3. 画像の下に hf-subtitle か hf-tip を追加して、そちらも時間差で出す
  
  「画像1枚だけで終わるシーン」は作らないこと。必ずキャプション要素（hf-subtitle か hf-tip）を1つ付けること。
  

• 採用するとどうなる？：スクリーンショットをそのまま静止表示するシーンでの「止まって見える」指摘がなくなります。画像に補足テキストが加わることで、内容の説明もより伝わりやすくなります。

• 副作用の懸念：ズームアニメを入れると、画像の端が少し見切れることがある。scale は最大 1.05 以内に抑えるよう補足するとよい。

6. [優先度: 低] 誤字・表現ゆれのある headline を生成しないよう、言葉のチェックを促す

• 何が起きてた？：「teet」という名前の動画で、生成されたテキストに「全帯に」という言葉が使われており、担当者が「全体に」に修正していた（誤字として明示的に指摘あり）。また同じ動画でプロンプト指示として「ReStartのDriveフォルダはこの動画を見せる相手には共有していません」という注意書きも追加されており、AI が不適切なリンクや社内情報を含むテキストを生成しないよう配慮が必要なことがわかる。過去4本中1本で誤字修正が発生。

• 追加文案：

  # headline・narration の品質チェック（出力前に必ず確認）
  
  全テキストを出力する前に以下を確認すること：
  - 誤字・変換ミスがないか（特に「全帯→全体」「帯」「弾」など紛らわしい漢字）
  - 社内リンク・URL・ファイルパス・会社名・担当者名などの内部情報が含まれていないか
  - ターゲット読者（ライバー本人）が見ることを