Opus 5.5で60秒の解説動画を作る：資料・絵コンテ・MP4の検証手順

Opus 5.5に解説動画の編集を依頼するときは、編集可能なプロジェクトと、内容を検証できる動画を成果物にします。まず扱う問いを一つに絞り、事実を述べる文に根拠を付け、それぞれをシーンへ割り当てます。その後、書き出したMP4を説明内容と照合します。滑らかな動きでも、分母の間違いは補えません。

今回は架空の問い合わせチケット10件を使い、適合率と再現率の違いを60秒で説明します。英語の参考動画、編集可能なコード、ナレーション、時間指定済みの字幕を用意しました。参考動画は本記事の教材として作成し、実際にローカルでレンダリングしたものです。Opus 5.5を呼び出して生成した動画ではありません。以下のプロンプトは自分の編集セッションで使う依頼文であり、モデル性能の証明や一度で完成する保証ではありません。

編集可能なプロジェクトをダウンロードするか、60秒の参考MP4を見ることから始めてください。すべてのカードを数えられる小さな例で手順を確かめてから、複雑な題材へ応用します。

1. 視聴後に何ができればよいかを決める

想定する視聴者は、分類スコアを見たことはあっても、その分母が分からないサポート業務の担当者です。同じ予測結果で適合率が3/5、再現率が3/4になる理由を説明できることが目標です。モデルの構造、しきい値の選び方、他の評価指標までは、この1分間に含めません。

正解ラベルを固定します。チケット1、2、3、4は緊急で、残り6件は通常です。架空の分類器が検出したのは1、2、3、5、6。その結果、真陽性3件、偽陽性2件、偽陰性1件、真陰性4件になります。これは説明用に作ったラベルであり、顧客データでもモデルの実測値でもありません。

定義の出典はGoogleの分類指標の教材です。適合率は陽性と予測した全件のうち実際に陽性だった割合、再現率は実際に陽性である全件のうち検出できた割合を表します。ID、配色、シーンの長さ、説明文は本教材独自の設計です。この区別を残し、説明用の例をベンチマークへ書き換えないでください。

「AI評価を理解する」では目標が広すぎます。「適合率の分母に入る5枚を指せる」なら確認できます。脚本、アニメーション、レビューの担当者が同じ基準を使えるため、最後の数秒に別の授業を詰め込まずに済みます。

2. 出典・説明文・シーンを対応させる

アニメーションを依頼する前に、主張の一覧を作ります。外部の定義、手元の計算、編集上の選択を分けて記録します。外部出典が必要なのは定義で、数値例は10件のラベルから再計算できる必要があります。

変えてはいけないのは各チケットの同一性です。切り替えの途中で4番が5番に入れ替わってはいけません。色は正解ラベル、枠線は今説明している集合を表します。カテゴリー名も文字で示し、色の識別だけに頼らない設計にします。

絵コンテを決めた後で「統計を適当に探して」と依頼するのは避けます。出典不明の魅力的な文が増えるおそれがあります。先に出典URLと定義を渡し、追加された文に出典や明示的な計算が対応しなければ削除するか、未確認の提案として保留します。

3. Opusに編集範囲を明示する

ダウンロードしたプロジェクトを展開し、ファイルを読んでレンダラーを実行できる環境で次の依頼文を使います。アカウントで利用できるモデル選択機能からOpus 5.5を選んでください。特定のAPIエンドポイントや有料リクエストを前提にはしていません。全体の流れはOpusの動画用プロンプトとMP4制作ガイドも参照できます。

この60秒の解説動画プロジェクトを修正してください。
視聴者：統計の前提知識がないサポート担当者。
目標：適合率=3/5、再現率=3/4となる理由を説明できること。
編集前にrender.pyとREADME.mdを読むこと。
実際の緊急={1,2,3,4}、緊急と予測={1,2,3,5,6}。
定義の出典：
https://developers.google.com/machine-learning/crash-course/classification/accuracy-precision-recall

10件すべてのIDと、各10秒・計6シーンの構成を維持する。
オレンジは実際の緊急を表し、カテゴリー名の文字も残す。
青枠はそのシーンで説明する集合だけに使う。
理解しやすくなる場合だけ、ナレーション・余白・切り替えを修正する。
研究結果、APIテスト、Opusの品質に関する主張を捏造しない。
有料サービスの導入、APIキーの要求、データ変更をしない。

コード差分、60秒のMP4、字幕、抽出フレーム、ffprobe結果を提出する。
サンプルの検査を実行する。実行したコマンド、失敗、足りないツールを報告する。
プレビューをMP4と呼ばない。出典の解釈が不確かなら、その主張を保留し理由を説明する。

大幅なコード変更を受け入れる前に、絵コンテと変更予定の一覧を出してもらいます。形式を守りながら説明内容を変えてしまう場合があるため、中間成果物も自分で確認してください。良い修正説明は、なぜその集合を強調するのか、どの行を変えたのかを示します。「見栄えを良くした」だけでは授業の内容が保たれたか分かりません。

Remotionのコーディングエージェント向けガイドも、プロジェクトを使う動画制作の選択肢です。今回の参照実装は各要素を調べやすいPillowとFFmpegを使います。Remotionへ移行しても意味内容の検証は必要ですが、プロジェクト構成を変えずに両者のコマンドを混ぜないでください。

4. 参考動画をローカルでレンダリングする

音声付きで再現するにはPython 3.10以上、Pillow、ffprobeを含むFFmpeg、macOSのsayと英語音声が必要です。確認した参考動画はSamanthaを使っています。通常のパッケージ管理手段で導入し、PATHから実行できることを確認します。モデルキーは不要ですが、レンダリングには自分のPCの計算資源を使います。別途Opusへ編集を依頼する際は、自分のアカウントの利用条件が適用されます。

cd opus-explainer-20261008
python3 -m venv .venv
source .venv/bin/activate
python3 -m pip install -r requirements.txt
ffmpeg -version
ffprobe -version
say -v '?'
python3 render.py --voice Samantha

スクリプトは1280×720、24fpsで1,440フレームを描きます。各シーンは10秒です。ナレーションを個別に合成し、9.7秒を超えた区間はエラーにします。短い音声はシーンの境界まで無音で補い、6区間を連結します。最終MP4にはH.264動画、AAC音声、選択可能な英語字幕トラックが入ります。同じナレーションを画面にも描くため、字幕トラックを非表示にしても説明文は読めます。

LinuxやWindowsではpython3 render.py --silentで映像を作れます。出力はoutput/silent.mp4で、音声付き版と同じではありません。音声を付けるには利用権のある6区間の録音を用意し、10秒単位の構成に合わせて音声結合処理を変更します。音声ツールがないからといって無音トラックを加え、ナレーションの検証済みとはしないでください。

主な出力はoutput/explainer.mp4、output/captions.srt、6枚のPNG、output/narration-durations.jsonです。一般的なmacOS・Linuxのフォントパスを探す実装なので、見つからなければFONT_PATHにTrueTypeフォントを指定します。フォントを替えると折り返しが変わるため、フレームを見直します。

画面はローカルでレンダリングした英語の参考動画であり、Opusの生成セッションではありません。ナレーション全体、切り替え、終わり方はMP4で確認してください。

5. 説明とファイルを別々に検証する

まずサンプルを独立に数え直します。実際の緊急と検出の共通部分は{1,2,3}、誤検出は{5,6}、見逃しは{4}、正しく除外したのは{7,8,9,10}です。動画の25秒、35秒、45秒でIDを照合します。60%と表示されていても、別のカードを囲んでいる可能性があるので、割合だけの確認では足りません。

次に、タイムライン上の設定値ではなく、書き出したファイルを検査します。

python3 test_project.py
ffprobe -v error -show_entries \
  format=duration:stream=codec_type,codec_name,width,height,r_frame_rate \
  -of json output/explainer.mp4
ffmpeg -v error -i output/explainer.mp4 -f null -

60秒のコンテナ、1280×720・24fpsのH.264動画、AAC音声、字幕ストリームが期待結果です。デコード成功はFFmpegがファイルを読めることを示すだけで、発音や説明の分かりやすさを保証しません。映像を見ずに一度聞き、次に音を消して見ます。どちらでも核心が伝わるかを確かめます。

字幕と10秒ごとのシーンも照合します。この短い例では1つの字幕がシーン全体を覆います。会話調のナレーションへ変更したら、文ごとの時間調整が必要になる場合があります。ナレーションと字幕の同期手順を参照し、表示だけ短くして音声が次のシーンへはみ出す状態を避けてください。

小さい画面でも試します。長い字幕や小さいIDは別レイアウトが必要かもしれません。横長画面をそのまま縦長キャンバスへ縮小しても読みやすくはなりません。モバイル版は横動画を縦動画に作り直す手順で別途設計します。

6. 次の修正も確認できる形にする

最初のレンダリングを基準として保存し、教え方を一つずつ変えます。例えば45秒で停止し、同僚に再現率の分母を指してもらい、説明する前に回答を記録します。前のシーンにあった5つの青枠を数えるなら、集合が変わったことを切り替えや短い音声で明確にします。これは提案する理解度確認であり、本記事のために実施したユーザー調査ではありません。

文書検索の例へ置き換えるなら、名前、正解、ナレーション、主張一覧、テストの期待値をまとめて変えます。新しいサンプルが同じ比率にならないのに60%と75%を流用してはいけません。公開する権限のない顧客データも教材へ入れないでください。

今回の成果物は英語の横長参考動画です。多言語音声パック、縦型広告、モデル比較は別の成果物としてレビューします。再利用できるのは、根拠と説明をそろえる手順です。Opusに修正を任せても、主張と実ファイルを受け入れる責任は公開者に残ります。

7. 確認済みの内容を保ちながら失敗点を直す

修正依頼は「45秒ではID1～4を選択する。音声、尺、データを変えず、その集合だけ戻す。再出力し、45秒のフレームを示す」のように具体化します。全体を良くしてほしいという依頼より、確認済みのシーンを守りながら変更を点検できます。

受け入れる修正ごとに元のプロジェクトとMP4を保存し、出典の版、変更した主張、レンダリングコマンド、出力ハッシュを記録します。別題材ではサンプルと主張一覧を先に替え、音声と映像を同時に直します。ローカルで出力できたことだけで完了にせず、出典・説明・画面・ファイルが一致するところまで確認してください。