インタビュー→ショートビデオ生成スキル は何をしますか？
Goal（目標）
実際のインタビューを、元の音声に忠実で視聴者が独立して理解できるショートビデオに編集し、内容のテーマごとにバッチ全体を整理します。選定箇所、テキスト確認、検収根拠をすべて保持します。まず代表的なサンプルを作成し、ユーザーの承認範囲に応じて拡大します。
Criteria（成功基準）
- 各クリップは完全な意味のまとまりを中心に構成し、必要な前提条件、限定条件、質疑応答の関係、自然な終わり方を保持します。カットポイントは内容によって決定します。
- バッチごとに自動的にテーマ、帰属理由、シリーズ順序を提案します。単一クリップ内のチャプターは内部の意味的転換を示し、バッチ全体のテーマとは別に管理します。
- 人物、字幕、タイトル、角位置情報は、現在の素材とユーザーの確認に従います。編集ドキュメントと対応するSRTがテキストコントロールの入り口となります。
- 最終MP4の可視テキスト、構図、チャプターの変化、テールオーディオを確認します。機械チェックと人間による判断はそれぞれ記録します。
入力とリソース
元のインタビューには独立した文字起こし機能が必要です。 まず別途インストールされたASRモデルまたは認可された文字起こしサービスに接続し、校正済みでタイムライン付きのSRTを取得します。本スキルは音声認識モデルを含まず、直接呼び出しもしません。既に信頼できるSRTがある場合は、モデルのインストールをスキップできます。合成デモはプリセットの字幕を使用しますが、ASRによる検証済みの証拠としては使用できません。
元の映像とその校正済み字幕、既存のプロジェクト資料、ユーザー承認済みのテンプレートとブランドカラーを優先的に再利用します。最小限の背景情報（人物/組織名と役割、インタビューの背景、対象視聴者、用途、キーターム、公開範囲）を収集します。詳細は プロジェクトコンテキスト を参照してください。背景情報は命名と判断に役立ちますが、元の音声に代わるものではなく、組織の立場を捏造するものでもありません。身元が不明な場合は「未確認」のままにします。
素材がない場合は、不足している入力を説明し、まずプロジェクト概要または候補計画を提出します。利用可能な文字起こし/レンダリング環境がない場合は、環境とASR に従って依存関係を確認し、継続可能な作業を保持します。ASRは上流の文字起こしステップであり、デフォルトで認可されたローカルQwen3パイプラインを使用します。モデルを自動ダウンロードしたり、素材をアップロードしたりしません。本スキルは自動化タスクを作成または復元しません。
現在のタスクに応じて対応する契約文書を読み込みます。実行スクリプトは通常、ソースコード全体をコンテキストに読み込む必要はありません：
| 現在の作業 | 読み込むものと使用するもの |
|---|---|
| 選定箇所、人物と構図、チャプター、プロモーション状態 | 編集計画契約；scripts/validate_editorial_plan.py |
| 途中のテキスト編集、字幕修正、ユーザー確認 | 文案編集；scripts/copy_sheet.py |
| テンプレート、字幕タイムマッピング、配色、テール処理 | 制作仕様とコマンド；scripts/render_interview.py、scripts/suggest_palette.py |
| テーマカタログ、プレビューページ、統一リスト | テーマ出力；scripts/export_review.py |
| 修正または納品チェック | 検収マトリックス |
必ず守るべき作業の境界線
途中でテキスト確認を待ちます。 初期の文字起こし、テーマ、候補が形成された後、テキスト合成・制作に入る前に 画面文字編訂.md をエクスポートし、クリック可能な絶対パスを積極的に提示し、修正箇所を説明します。表はタイトル、チャプター、角位置情報、字幕のフォントサイズを制御します。リンクされたSRTはワード単位の字幕内容とタイミングを制御します。ユーザーが編集を確認してから適用（apply）およびレンダリングを行います。ユーザーが初稿を明示的に受け入れ、直接制作を許可した場合のみ、--accept-default --approval で実際の権限を記録します。沈黙は同意とみなしません。待機中は、登録、文字起こし、候補分析を続行できます。ドキュメントまたはSRTが変更された場合は、影響を受ける内容を再確認し、適用（apply）し、MP4を再エクスポートする必要があります。すでにエクスポートされたMP4は自動的に更新されません。
内容で分類します。 編集アシスタントは完全な素材に基づいて themes を提案します。各レコードは theme_id、series_order、theme_basis を持ち、テキスト草案とともにユーザーのレビューに提出されます。グループ数は内容によって決まり、人物の割り当てに従ってクリップしません。単一テーマでも1グループとして登録します。サブタグは納品カウントを増やしません。エクスポーターは計画に従ってファイルを整理するだけで、意味的分類は実行しません。
元に戻って人物と画面を確認します。 複数人の素材では、まず確認済みのソースを持つ identity_map を確立します。画面に存在していても、その人が話しているとは限りません。ユーザーの訂正は、ASR、古いラベル、その他のプロジェクト経験よりも優先されます。選定箇所は対話関係を保持します。単独、2人、全景の構図を比較し、トリミングには現在の画面の証拠が必要であり、左右の位置を機械的に適用することはできません。詳細な証拠フィールドについては編集計画契約を参照してください。
テンプレートの制限と編集目標は分離します。 現在のレンダラーは連続フラグメント、1080×1920、1～3チャプターをサポートします。チャプターは0から始まり、ラベルと semantic_basis は実際の転換点に対応します。数を合わせるために内容を書き換えることはできません。テンプレートが適さない場合は、ギャップを説明し、ユーザーの範囲に応じて調整します。マルチウィンドウクリップには、クリーンな中間クリップと明示的なタイムマッピングが必要です。字幕と固定テキストにはそれぞれ所有者がおり、古い焼き付け文字と新しい文字が重ならないようにします。テール部分は元の映像の表情、呼吸、環境音を優先して保持し、既存のポーズは目標に含まれます。余分なテールを追加せず、テールオーディオ上でフェードアウトしません。
サンプルとバッチはそれぞれ検収します。 サンプル前はpreviewで編集計画を検証します。まずテキスト確認を完了し、それから代表クリップをレンダリングします。最終MP4の最初のフレーム、中間、チャプター転換点、最後のフレームをチェックし、クリップ全体を聴いて確認してから、バッチを拡大します。レンダラーは低レベルツールであり、完全な編集計画チェックを自動実行しません。バリデーターも実際の視聴・聴取に代わるものではありません。
Acceptance（検収基準）
ステータスは candidate → preview → formal → delivered です。machine_qc、human_review、copy_confirmation、delivery_status は別々に記録します。まだ実施していない聴取審査は pending のままにします。formal は、機械チェックと、身元、音声、意味、ビジュアルに関する人間による審査がすべて完了した場合にのみ昇格します。pending があるものは正式納品を宣言できません。構造検証に合格しても、実際のファイルとレビューバージョンを照合する必要があります。ファイルの存在やレンダリングログを検収の代わりとすることはできません。
納品時には、テーマカタログ、視聴ページ、統一マニフェストを提供し、ソースタイムウィンドウ、仕様、文案/SRTバージョン、機械と人間の記録を遡って確認できるようにします。候補数、正式数、納品済み数はそれぞれ報告します。preview は pending のままレビュー用に納品できます。delivered は実際のアクセス入口が統一リストと一致している必要があります。フィールド、コマンド、失敗条件は上記の契約に従ってチェックし、静的スコアやテスト合格によって自動的に昇格することはありません。