ほかの部分を変えずに、AI動画の一場面を修正するには

依頼は小さく聞こえます。最後の一文を変えるだけです。ところが次のレンダリングでは、背景が新しくなり、切り替えが速くなり、冒頭も少し変わっている。明らかな故障はなくても、全員が承認した版ではなくなっています。AI動画編集で困る失敗の一つは、局所的な修正が、作品全体の新しい解釈に変わってしまうことです。

「ほかは絶対に変えないで」と強調するだけでは解決しません。明確な修正範囲、保存した基準版、依頼外の変化を見つけられる比較が必要です。また、エージェントは記憶から似た動画を再制作するのではなく、既存のプロジェクトで作業する必要があります。

役立つ修正指示は、変える要素、求める結果、安定させるべき関係を一緒に説明します。その後、前後の場面も含めてレンダリング結果を確認します。この記事では、記録された小さなOpenDesignの例で手順を説明し、その先の難しい依頼の扱い方も見ていきます。

実際に修正する版を残す

編集前に、現在のプロジェクトと、承認を受けた正確な動画を特定します。両方を保存します。ソースは構成の作り方を示し、レンダリング済みファイルはレビュアーが見たものを示します。どちらかがなければ、後の比較が不確かになります。

基準版と新しい出力には別の名前を付けます。複雑な番号体系は不要ですが、記憶に頼らず版を区別できなければなりません。修正版のレビュー中も元動画を残します。唯一のコピーを上書きすると、依頼した変更が不具合を持ち込んだか判断しにくくなります。

ソースが基準のレンダリングと対応するか確認します。 プロジェクトに、まだ書き出していない未完の編集が入っているかもしれません。その上に新しい変更を依頼すると、プロンプトには一つしか書いていなくても、次の動画には両方が入ります。進める前に該当場面を開き、見える文言、時間配分、素材を受け入れ済みの出力と比較します。

「最新版」のような曖昧な参照も、ここで解消します。更新日時が新しいファイルではなく、どのファイルがレビューされたかを確認します。ダウンロードしたコピー、レビューリンク、プロジェクトの現在の出力は、すべて異なる版かもしれません。

修正を、範囲のある判断として記述する

「結末を強くする」では、文字、サイズ、タイミング、色、音楽、最後の切り替えまで選択肢が開きます。探索中には適切でも、一文の差し替えだけが承認されている場合には向きません。

場面を内容で特定し、必要なら時間帯も示します。元の文と置換後の文を正確に書きます。次に、ほかの場面、総尺、レイアウト、書体、色、音など、意味のある固定条件を並べます。すべてのピクセルを列挙する必要はありませんが、新しい解釈が崩しうる関係は守る必要があります。

例えば最後の一文を変えるなら、改行してよいかも指定します。長い置換文では、フォントと位置を固定していてもレイアウトの判断が必要です。1行を守るなら縮小が必要かもしれません。サイズを守るなら、もっと場所が必要かもしれません。これは指示違反ではなく、トレードオフです。

制約が衝突するなら、依頼前に何を最優先するか決めます。2倍の長さの文が、同じ幅、サイズ、静止時間に収まるとは限りません。三つすべてを要求すると、意図的な選択より偶発的な妥協を招きます。

実際の小さな変更：Focusの結末

OpenDesign Motionガイドには、10秒のFocusプロジェクトと、最後のメッセージを「Make room for what matters.」から「Focus on what matters.」へ変更する追加依頼が載っています。ほかの場面、尺、色、音を維持し、別の修正版MP4を求める依頼です。

保存された例のファイルは、比較の問いが絞られている点で役立ちます。冒頭でFocusを紹介し、中盤でCollectとDoneを見せ、変更は最後に置かれます。全体を漠然と「もっとよく」した第二版を求めるより、有意義な修正の練習になります。

製品上の大切な違いは、ソースを編集しても既存動画がさかのぼって変わらないことです。新しい文は、新しくレンダリングした出力に入れる必要があります。変更済みのソースプレビューと古いMP4は、同じプロジェクト内に共存できます。見えているプレビューが納品を証明すると考えず、新ファイルを明示的にレビューします。

最後の文の編集は、文字ブロック、改行、登場と退場という比較的狭い依存関係を持ちます。場面の交換は、画像の読み込みやタイミングも変えうるため、その大きな変更に合う範囲でレビューします。

変わらないはずの部分も比較する

修正レビューは、依頼した違いだけでなく、守るべき部分の比較も含めると強くなります。下の二つのFocusフレームは、元ファイルと修正版の4秒時点から取ったものです。同じ時点の同じ収集場面が見えます。最後の画面の比較とは役割が異なり、依頼で触れないはずだった部分を確認します。

編集の依存関係に応じて、保護する時点を選びます。最後のカードの文言変更なら、冒頭、中盤の状態、最後への切り替えを抽出します。スクリーンショット交換なら、直前の場面、画像が完全に読み込まれた最初のフレーム、その次の切り替えを見ます。音の編集なら、カット前後のつながりと最後のフェードが重要なので、静止画だけでは足りません。

守るべき時点が変わっていたら、全体の再修正を頼む前にソースを調べます。フォント変更は全場面に影響し、共有する尺の値は後の流れをずらすかもしれません。その依存関係に絞って直し、再レンダリングします。求めた結末が正しく、無関係な場面も意図どおり動く、という両方に新ファイルが通るまで、基準版を残します。

境界を抽出し、その後で通して再生する

保存された二つのFocus出力は、1秒、4秒、6秒の対応フレームが一致し、9.4秒で異なります。これらの保護する時点を、音声も含む全体再生と合わせて確認します。

最後の場面へのつながりも、静止フレームと一緒に見ます。前のタイトルが6秒で正しく終わっていても、退場が新しい文に重なるかもしれません。その境界を再生し、最後のフェードを聞きます。正しい静止画で、唐突な終わりを隠さないようにします。

変更前に種類を見分ける

比較的閉じた変更もあります。似た長さの文への置換なら、文字レイヤーだけに影響するかもしれません。画像の変更は切り抜きと注釈に影響します。場面を延ばすと、切り替え、音の合図、字幕、それ以降すべての開始時刻が変わることがあります。

内容、レイアウト、タイミング、共有スタイルという分類が役立ちます。分類から、どの隣接要素をレビューすべきか予測します。一つの変更が複数に属してもかまいません。短い見出しを長くするのは、レイアウトへの影響を伴う内容変更です。

局所的な見た目の依頼に対し、エージェントが共有コンポーネントの書き換えを提案したら、ほかの利用箇所を確認します。再利用は有益ですが、共有変更は1フレームの見た目以上に広い影響を持ちます。局所的な例外が適切かもしれませんし、全体変更が正しいかもしれません。どちらでも範囲を明示します。

時間の変更は、広めに比較する

場面は前後とつながっています。前の場面が完全に消える前に登場が始まるかもしれません。効果音が次まで続くかもしれません。そのため一つの境界を動かすと、内部の内容は同じでも、二つの場面の感じが変わりえます。

Remotionの時間に関する文書は、その理由を示しています。シーケンスには開始と尺の関係があり、入れ子の内容はローカルな時間を使えます。実装はプロジェクトによって違いますが、実務上の意味は単純です。局所的な尺は、常に独立した数字とは限りません。

静止を延ばすなら、総尺も延ばすのか、別の場面から時間を取るのか指定します。結末を2秒延ばし、総尺を固定するなら、何かを縮める必要があります。依頼に隠さず、意図する交換条件を名付けます。

編集場面への切り替え、場面全体、そこからの切り替えを見ます。最後の場面なら、実際の最終フレームと音の終わりを見ます。途中で文が見えていても、書き出しの終わりでは早く消えることがあります。

意味のある修正を一つずつ行う

修正の一括依頼に独立した要望を複数含めることはできますが、診断は難しくなります。文、音楽、切り抜き、テンポを同時に変えると、どの調整が改善や悪化を生んだか判断しにくくなります。

慎重な修正では、問題を解く最小のまとまりにします。「スクリーンショットを交換し、その注目表示の対象を合わせ直す」は結びついた一つの作業です。「スクリーンショットを交換し、タイトルを再設計し、新しい音楽を試す」は、別々にレビューしやすい独立した判断です。

目的が共通する変更をまとめます。短い締めの文と長い静止時間は、一つの読みやすさの修正として見られます。新しい音楽は別の部分を変えるので、分けたほうが評価しやすくなります。

却下した代案は、受け入れた流れの外に置きます。魅力的な実験場面が現行コンポジションに残っているだけで、後の書き出しに戻ることがあります。現在意図する版を、プロジェクト内で曖昧にしないことです。

記憶ではなく出力を比べる

可能なら、基準版と修正版を横に並べて見ます。 まず依頼箇所を比べ、次に保護する部分を確認します。見るのは、結果が正しいかと、周囲が合意した範囲に収まったかという二つの違う点です。

Frame.ioの比較ビューアーは、横並び表示や連動再生を含む、プロ向けの具体的な版比較の例です。重ね合わせとピクセル差分モードは静止素材向けに説明されています。別のツールでも動画にその機能があると考えてはいけません。

専用ソフトがなくても、単純な比較には価値があります。両ファイルを開き、同じ時点を合わせ、同じ対象を見ます。表示サイズもそろえます。プレーヤーが大きいと文字が明瞭に見え、動きの印象も変わるため、実際の修正から注意がそれることがあります。

特定のフレームが変わらないはずの変更なら、対応する抽出フレームを比較します。タイトルのずれや背景の変化を見つけられます。ただし間の動きすべてが同じだとは証明できないので、全体の再生レビューも残します。

観察できる結果を示すフィードバックをする

タイムコード付きの指摘は、全体的な感想より対応しやすいものです。「最後の場面の冒頭で、文がロゴの後ろに折り返される」なら、目に見える失敗を特定しています。「最後が変」は第一印象として有益でも、編集指示にする前に具体的な観察が必要です。

AdobeのFrame.ioを使うレビュー手順は、タイムラインのコメントと修正レビュー版の関係を示します。転用できるのは、指摘を時点と特定の版に結びつける習慣であり、OpenDesignにも同じ連携があると考えることではありません。

観察と解決策を分けます。文が読みにくいという指摘は正しくても、文字を大きくする提案は新しい衝突を生むかもしれません。根本の問題を記録し、構成全体に合う修正を選びます。承認済みの短い文、長い静止、静かな背景が合う場合もあります。

複数人がレビューするなら、エージェントに送る前に矛盾をまとめます。「結末を短く」と「締めの文を読む時間を増やす」には、優先順位の決定が必要です。チームで合意していない事業上の判断を、エージェントは推測できません。

プロジェクトを離れた後の版を確認する

引き渡す場所から実際の書き出しファイルを開きます。依頼した変更があるか、想定した尺か、音が再生されるかを確認します。正しいプレビューを承認した後、古いダウンロードを共有するという、よくある運用ミスを防ぎます。

ファイル名とレビューメモを一緒に確認します。短い引き継ぎで、変更点と、どの版を置き換えるかを伝えられます。「上のものを使って」といったチャットだけに頼らないようにします。受け手は、その会話の外でファイルに出会うかもしれません。

出力に問題があれば、違いを理解できるまで失敗ファイルと基準版を残します。原因はソース編集、レンダリング設定、単に別のファイルを開いたことかもしれません。全体の再制作を求める前に、別々の可能性として扱います。

局所的な修正は、納品動画で依頼結果が見え、保護した部分も許容できるときに完了します。ソースの編集はそこへの一歩であり、結果そのものではありません。

局所的な編集が新しい方向性に変わった時を見分ける

修正により、元の案がもう成立しないとわかる場合もあります。新しい製品の話には、別の冒頭、新しい根拠、異なる尺が必要かもしれません。それを「小さな変更」と呼び続けると、非現実的な期待を生み、必要な調整すべてが逸脱に見えてしまいます。

範囲の変化を明示します。旧版を保存し、該当部分の新しいブリーフを書き、以前の承認のどれが引き続き有効か決めます。文字組みと配色は保ち、絵コンテを開き直すかもしれません。中盤の作業を残し、冒頭の約束を替えるかもしれません。何でも維持せよという要求より、明確な境界が役立ちます。

逆に、小さな文言編集を動画全体の再設計の機会にしないようにします。必要なのは、どの種類の作業かを見分ける規律です。探索には方向を探す自由が必要です。修正には、よい方向を保つための十分な制約と比較が必要です。

最もよい依頼は、最も長いものではありません。変更と限界が理解でき、正しい開始プロジェクトを渡し、確認できる具体的な結果が残るものです。そうすれば、運に頼らず、小さな編集を小さなまま終えられます。

レビューでは二つの問いを分けます。 依頼した変更は実現したか、保護する部分は維持されたか。新しい文が正しいだけでは、前者にしか答えていません。

次のレビュアーに、使える比較を残す

他の人に修正版を渡す際は、二つの正確な出力ファイル名と変更場所を添えます。「動画を更新しました」では、ファイルも違いも探させることになります。「focus-v2.mp4の最後の文を変更し、元はfocus.mp4として残しています」なら、結論を押しつけず、確認の出発点を渡せます。

依頼した変更と、レビューで見つかった付随的な違いを分けます。修正版で切り替えまで変わったなら、新しい文がよいからと黙って受け入れず、第二の問題として記録します。次の修正で基準がますます不確かになるのを防げます。意図した変更と、維持した文脈の両方を確認できるとき、小さな修正は信頼できるものになります。