Claude Opus 5.5 を、演出・アニメーション・レンダリング・レビュー・納品までをこなすプロ仕様のモーション制作チームに変える方法。
多くの人は、AI で動画を作るとは「プロンプトを書いて結果を待つこと」だと思っています。
Opus 5.5 では、1 つのエージェントを中心に制作スタジオ全体を構築するという、より興味深い可能性が開かれます。
スタートアップが製品ローンチ動画を作る場合、通常何が起こるかを考えてみてください。誰かがクリエイティブブリーフを書きます。デザイナーがビジュアルディレクションを決めます。モーションデザイナーが UI を動かします。ビデオエディターがタイミングと音声を調整します。そして別の誰かが完成物を確認し、修正を依頼して、最終的な書き出しを準備します。
たった 20 秒の動画のために、これだけの制作パイプラインが必要なのです。
では、1 つの Claude エージェントに同じ責任を与え、各フェーズを処理する明確なプロセスを用意したところを想像してみてください。
エージェントはリファレンスを研究し、映像を計画し、アニメーションコードを書き、プレビューをレンダリングし、自分のミスを検証して、結果を修正します。あなたはすべてのシーンを手作業で作る代わりに、重要なクリエイティブ判断だけを承認します。
これこそが Motion Engineering の背後にあるチャンスです。
Claude Opus 5.5 は、コーディング、視覚的理解、長時間稼働するエージェントワークを組み合わせているため、このワークフローを魅力的なものにします。しかし最も重要なのはモデル単体ではありません。その周囲に構築する制作システムです。
https://x.com/claudeai/status/2102435511222890900
これが通常の AI 動画生成とどう違うのかを見ていきましょう。
Claude は最終的なピクセルを直接生成する必要はありません。ピクセルを生み出すソフトウェアを書くことができるのです。
モデルがアニメーションコードを書きます。レンダラーがそのコードをフレームに変換します。レビュープロセスで欠陥を見つけます。エージェントがソースを変更し、再レンダリングします。
つまり、最初の動画が次の動画の土台になるということです。
本ガイドでは、5 つの制作部門、再利用可能なコンポーネント、クリエイティブ承認ゲート、そして編集・検証可能な動画を生成するワークフローを備えた「ワンエージェント・モーションスタジオ」の構築方法を紹介します。
目的は、人間のクリエイティブ判断をすべて置き換えることではありません。適切に設定されたエージェントがすでに処理できることを、手作業で行うのをやめることです。
djn私は Substack で、AI エージェント、自動化、制作ワークフローの実践的な解説を発信しています。
パート 1. ワンボット・スタジオ
01. 1 つのエージェント、5 つの制作部門
従来のスタジオが専門家に作業を分担するのは、フェーズごとに異なる種類の判断が求められるからです。
監督はストーリーを考えます。アートディレクターは構図を考えます。アニメーターは動きを考えます。テクニカルアーティストはレンダリングを考えます。批評家は成果物がブリーフを満たしているかを判断します。
1 つの Opus 5.5 エージェントが、この 5 つの役割を順番に担うことができます。
ただし、これは責任範囲が分離されている場合にのみ機能します。
構造化されていない単一のステップで、演出・デザイン・アニメーション・レンダリング・評価のすべてを Claude に任せると、見た目は印象的でも中身を検証すると破綻するデモができあがります。
そうではなく、エージェントを 5 つの部門に分けて構成しましょう。
1部門 責任範囲 出力物2────────────────────────────────────────────────────────3監督（DIRECTOR） ストーリーと絵コンテ BRIEF.md4アートディレクター ビジュアルディレクション STYLE.md5アニメーター モーションとタイミング ソースコード6レンダーエンジニア レンダリングと書き出し MP4 + プレビュー7批評家（CRITIC） 画質管理 レビューレポート
これらは必ずしも 5 つの独立したエージェントである必要はありません。1 つの連携されたワークフロー内にある、それぞれ固有の指示・ファイル・合格基準を持つ 5 つのフェーズです。
アニメーターがコードに触れる前に、監督が映像で何を伝えるかを決めます。Claude が色やトランジションを勝手に発明し始める前に、アートディレクターがビジュアルルールを定義します。批評家は、アニメーターが「こう作った」という説明を鵜呑みにせず、レンダリング結果そのものを評価します。
プロセスは以下のようになります。
1 あなたのブリーフ2 |3 v4 CLAUDE OPUS 5.55 |6 v7 監督8 ストーリー＋脚本9 |10 v11 アートディレクター12 リファレンス＋デザイン13 |14 v15 アニメーター16 コード＋モーション17 |18 v19 レンダーエンジニア20 フレーム＋書き出し21 |22 v23 批評家24 レビュー＋修正25 |26 v27 完成映像
この順序が重要なのは、視覚的な失敗の多くがレンダリング前に始まるからです。
ストーリーが不明瞭なら、どんなに良い動きでも救えません。ビジュアルディレクションが凡庸なら、エフェクトを増やすほど凡庸さが際立ちます。絵コンテが間違っていれば、技術的に完璧なアニメーションでも何も伝わりません。
最初の仕事は、そうしたミスを防ぐプロセスを構築することです。
02. バズった一発撮り動画が魔法ではない理由
あなたもあの手の動画を見たことがあるでしょう。
プロのクリエイティブエージェンシーが作ったようなアニメーションを投稿し、「Claude にプロンプト 1 つで作らせた」と語る人たちがいます。
その成果物は本当に 1 回の長い自律実行から生まれたのかもしれません。しかし、それはプロセスが一文から始まったという意味ではありません。
Claude Code チームの Thariq は、バズったデモの 1 つについて語る中で、この違いを指摘しました。
https://x.com/trq212/status/2102870353781641416
ここが注目すべきポイントです。
優れたプロンプトには、完全なクリエイティブブリーフ、参考資料、ショットリスト、技術的制約、アセット要件、最終結果の確認ルールが含まれていることがあります。
また、コーディングエージェントは既存のプロジェクト、デザインシステム、コンポーネント、レンダリングパイプラインを引き継いでいることもあります。
一見すると一発撮りに見えるものは、実ははるかに大規模なセッティングの「目に見える末端」にすぎないことが多いのです。
そして、これは良いニュースです。
魔法のような形容詞の組み合わせを見つける必要はないということです。必要なのは、良い判断を再現できる制作環境です。
同じリクエストに対する 2 つのアプローチを考えてみましょう。
1 つ目は、Claude に「高級感のある製品ローンチアニメーションを作って」と頼む方法です。モデルは、製品が何をするのか、動画がどう見えるべきか、どのトランジションを使うか、視聴者はいつヘッドラインを読むべきか、何が成功なのかをすべて自分で決めなければなりません。
2 つ目は、実際の製品アセット、リファレンス映像、デザインルール、絵コンテ、タイムライン、レビュー基準を提供する方法です。
どちらも 1 つのエージェントと 1 回の主要な制作実行で行われるかもしれません。しかし、重要な判断を偶然に任せる割合が少ないため、2 つ目の方が使える成果物を生み出す確率ははるかに高くなります。
プロンプトは 1 本の動画を作ります。スタジオは、動画を作るための再現可能な方法を作ります。
パート 2. スタジオを構築する
03. 制作環境をインストールする
今回の構成では、エージェントとして Claude Code、動画フレームワークとして Remotion、メディアの検証・処理に FFmpeg を使用します。
Claude Code はクリエイティブおよびプログラミングタスクを担当します。Remotion は React コンポーネントとフレームベースのアニメーションを通じて映像を制御可能にします。FFmpeg はリファレンスの分析、出力の検証、補助アセットの準備に役立ちます。
開始前に Node.js、Claude Code、FFmpeg をインストールしてください。
クリーンな Remotion プロジェクトを作成します。
1npx create-video@latest --yes --blank motion-studio23cd motion-studio45npx remotion skills add67npm run dev
Remotion Skills インストーラーは、コーディングエージェントがフレームワークを扱う際に利用できる実装ガイドを提供します。
motion-studio ディレクトリ内で別のターミナルを開き、Claude Code を起動します。環境で利用可能であれば Opus 5.5 を選択してください。
次にワークスペースを整理します。
1motion-studio/2│3├── CLAUDE.md4├── BRIEF.md5├── STYLE.md6├── STORYBOARD.md7│8├── public/9│ ├── logos/10│ ├── screenshots/11│ ├── fonts/12│ └── audio/13│14├── src/15│ ├── compositions/16│ ├── components/17│ ├── animation/18│ └── Root.tsx19│20├── reviews/21│ ├── frames/22│ ├── contact-sheets/23│ └── findings.md24│25└── out/26 ├── previews/27 └── final/
これがスタジオのワークスペースです。
CLAUDE.md にはすべての制作に適用されるルールを記述します。BRIEF.md は現在の映像について説明します。STYLE.md はビジュアルディレクションを記録します。STORYBOARD.md はショットの順序と重要なイベントを定義します。
ソースコードと承認済みアセットは、レビュー用の成果物とは分けて管理します。
この分離は、プロジェクトが数時間続いたり、別のセッションで再開されたりするときに真価を発揮します。Claude はワークスペースを検証するだけで、何がすでに承認され、どのシーンが存在し、何がレビューで不合格になり、何がまだレンダリング待ちなのかを理解できる必要があります。
この構造がないと、重要な判断がチャットの中に埋もれてしまいます。
スタジオは、1 つの会話が完全に維持されることに依存するのではなく、ファイルから再開できなければなりません。
04. ボットに永続的な操作マニュアルを与える
多くの人は、動画を作るたびに Claude に新しい指示セットを与えています。
それでは一貫性が失われます。
あるプロジェクトでは引き締まったバネアニメーションを使い、次では過剰なバウンスを導入し、3 つ目ではフォント・色・トランジションをすべて変更してしまいます。モデルに永続的なビジュアルルールがないからです。
そうではなく、スタジオの制作基準を CLAUDE.md に保存しましょう。
プロンプト 1. スタジオマニュアルの作成
1私たちのモーションスタジオ用に CLAUDE.md を作成してください。23あなたは、コードで作られた映像の演出、デザイン、アニメーション、4レンダリング、レビューを担当する制作エージェントです。56運用ルール781. 絵コンテを作成する前に実装を始めないこと。9102. 承認済みの製品アセットのみを使用すること。11123. UI、指標、ユーザーの声、製品機能を捏造しないこと。13144. すべてのアニメーションはフレーム番号または決定論的な時間で駆動すること。15165. 映像全体で一貫した 1 つの主要なビジュアルディレクションを使用すること。17186. 明確な伝達目的のない要素をアニメーション化しないこと。19207. 本編を生成する前に、代表的なフレームをレンダリングすること。21228. ソースコードだけでなく、レンダリング結果をレビューすること。23249. 欠陥は可能な限り局所的に修正すること。252610. 編集可能なすべてのソースファイルを保持すること。2728クリエイティブ上の制約2930避けるべきもの：31- 凡庸なグラデーション背景32- 過剰なバウンス33- 光るパーティクル34- 読めないテキスト35- 架空の製品ダッシュボード36- 目的のないカメラワーク3738制作ルール3940MP4 が存在するからといって41映像が完成したわけではありません。4243承認されたブリーフと検証要件を44満たしたときに完成となります。
このファイルがスタジオのベースラインになります。
これは、すべての映像が同じ見た目にならなければならないという意味ではありません。繰り返しがちな制作ミスを、毎回ゼロから再発見する必要がなくなるという意味です。
Claude が同じ視覚的ミスを繰り返す場合は、操作マニュアルを改善しましょう。次の映像はその修正を引き継ぎます。
共有アニメーションコンポーネント、タイポグラフィトークン、セーフエリア寸法、推奨書き出し設定など、再利用可能な制作判断をプロジェクト内に保存することもできます。
スタジオが完成した作品から学ぶほど、次の案件で基本を再確認する時間が減っていきます。
05. 監督にブリーフを書かせる
具体的に作っていきましょう。
散らかったプロジェクトボードを整理されたスプリント計画に変換する SaaS 製品をローンチすると想像してください。
1 つの変化——雑然としたタスクボードが明確な優先順位リストになる様子——を見せる 20 秒の製品映像が必要です。
視聴者はナレーションなしで価値を理解できるべきです。
「かっこいい動画を作って」と Claude に頼むのではなく、監督に制作課題を与えましょう。
プロンプト 2. 監督への課題
1あなたは私たちのモーションスタジオの監督です。23プロジェクト45生産性アプリのローンチ映像。67メインメッセージ89散らかったプロジェクトボードを10明確なスプリント計画に変える。1112ターゲット層1314創業者、プロダクトチーム、開発者。1516尺171820 秒。1920フォーマット212216:9 マスター239:16 SNS 用縦型241:1 正方形版2526アセット2728public/ に提供されたスクリーンショット、ロゴ、フォントを使用すること。2930架空の製品画面を作成しないこと。3132あなたの仕事33341. 利用可能なすべてのアセットを検証する。352. 不足している情報を特定する。363. BRIEF.md を作成する。374. 中心的なビジュアルアイデアを定義する。385. 映像のストーリー構成を作成する。396. 各シーンが存在する理由を説明する。4041まだアニメーションコードは書かないでください。4243クリエイティブディレクションを提示し、44承認を待ってください。
監督は、ただ動きで映像を埋め尽くすのではなく、各段階で視聴者が何を理解する必要があるかを決めるべきです。
最初のシーンは雑然としたタスクボードを見せるかもしれません。次のシーンでそれを整理するアクションが登場します。最後のシーンは完成したスプリント計画を映し出します。
重要な視覚的関係は「ビフォーとアフター」です。
他のすべてはそれを支えるべきです。
ブリーフを承認する前に、製品に実際にその機能が存在するか、提供したスクリーンショットでそれが示されているか、提案されたストーリーが過剰な説明文なしで理解できるかを確認してください。
必須の製品画面が欠けている場合、エージェントは説得力のある偽物を描くのではなく、それを要求すべきです。
この 1 つのルールだけで、使い物にならない AI 生成製品映像の驚くほどの数を防げます。
06. リファレンスをビジュアルアイデンティティに変換する
AI 製動画がどれも似てしまう大きな理由は、モデルが曖昧な言葉からビジュアルディレクション全体を捏造してしまうことです。
「高級感、ミニマル、シネマティック、未来的」といった言葉では、モデルにほとんど伝わりません。
より良い方法は、2〜3 のリファレンスを提供し、それぞれに具体的な役割を与えることです。
1 つのリファレンスはタイポグラフィを定義し、別はトランジションを示し、もう 1 つはテンポや構図を示すことができます。
アートディレクターに、元のクリエイティブ作品をコピーせずに有用なデザイン原則を抽出させましょう。
プロンプト 3. アートディレクション
1アートディレクターとして行動してください。23references フォルダ内のリファレンス画像・動画を4検証してください。56以下を抽出してください：78タイポグラフィ910フォントの個性11ウェイトの階層12ヘッドラインのスケール1314構図1516マージン17余白18視覚的階層19焦点2021カラー2223背景24プライマリテキスト25アクセント26コントラストのルール2728モーション2930登場のタイミング31収束の挙動32カメラワーク33読み取りのための停止（リードタイム）3435テクスチャ3637グレイン38影39境界線40表面処理4142承認されたデザイン判断を STYLE.md に保存してください。4344正確な構図、アートワーク、ブランディングをコピーしないでください。4546私たちの製品のための独自のビジュアルディレクションを47作成してください。4849実装の前にスタイル案を提示してください。
ここでようやく、Claude は「高級感」の意味を推測するのをやめます。
アニメーターが作業を開始するとき、カードを光らせるべきか、ヘッドラインをバウンスさせるべきか、すべてのシーンに別のグラデーションが必要かなどを決める必要はありません。
それらの判断はすでに行われているからです。
強力なスタイルガイドは、映像がどう見えるべきかを説明するだけではありません。何を避けるべきかも定義します。
リファレンスが抑制されたタイポグラフィとゆっくりしたカメラワークを使っているなら、AI デモでよくあるという理由だけで回転する UI やパーティクル爆発を導入すべきではありません。
エージェントには、元の対象物をコピーするのではなく、デザイン言語を理解してほしいのです。
重要なトランジションについては、FFmpeg でリファレンスからフレームを抽出し、タイミングを検証して、その結果を STYLE.md に記録するよう Claude に依頼しましょう。
これは「Apple っぽくして」とモデルに指示するよりも、はるかに有用な結果をもたらします。
パート 3. アニメーターとレンダーエンジン
07. ストーリーを編集可能なタイムラインに変換する
ブリーフとスタイルが承認されたら、アニメーターにはショットリストが必要です。
今回の 20 秒の映像では、5 つのシーンを定義します。
1シーン 01：課題200:00 - 00:0334雑然としたタスクボードが登場する。5構図が情報過多を伝える。67シーン 02：アクション800:03 - 00:07910カーソルが整理機能を選択する。11UI が視覚的に反応する。1213シーン 03：変容1400:07 - 00:111516タスクが明確な優先順位へと再配置される。17連続した 1 つの視覚的関係。1819シーン 04：結果2000:11 - 00:162122整理されたスプリント計画が定着する。23理解できる十分な長さで止める。2425シーン 05：締め2600:16 - 00:202728製品名、ロゴ、コールトゥアクション。29力強い最終フレーム。
これでモデルは、既知の状態間のモーションを設計できるようになります。
アニメーションコードを書きながら、同時に映像の内容を発明する必要はありません。
有用な原則は、「シーンの最終状態が、次のシーンの始まり方をアニメーターに教えるべきだ」というものです。
タスクボードが 80% スケールで中央に配置されて終わるなら、次のショットはその位置を維持するか、意図的にそこから移行すべきです。
無関係な構図の間をランダムにジャンプすると、動画は AI 生成スライドの寄せ集めのように感じられます。
連続性があることで、演出されたように感じられるのです。
より技術的な制御が必要な場合は、タイムスタンプをフレーム番号に変換します。
1 秒 30 フレームの場合、20 秒の映像は 600 フレーム（0〜599）で構成されます。
これにより、エージェントは主要イベントの正確な位置を得ます。
カーソルはフレーム 180 でボタンに到達し、クリックはフレーム 195 で認識され、結果はフレーム 210 で表示される、といった具合です。
何かが早すぎる場合は、そのイベントフレームを変更します。
トランジションが速すぎる場合は、その尺を変更します。
タイミングが良くなることを期待して、まったく別の動画を再生成する必要はありません。
08. モデルは最終動画ではなくアニメーションコードを書く
これが、スタジオを可能にする技術的な違いです。
Remotion を使えば、Claude は現在のフレームに応じて外観が変わる React コンポーネントを書くことができます。
レンダラーがそれらのコンポーネントを時間軸に沿って評価し、実際の動画を生成します。
シンプルな登場アニメーションは次のようになります。
1import {2 useCurrentFrame,3 useVideoConfig,4 spring,5 interpolate,6} from "remotion";78export const ProductCard = () => {9 const frame = useCurrentFrame();10 const { fps } = useVideoConfig();1112 const progress = spring({13 frame,14 fps,15 config: {16 damping: 200,17 },18 });1920 const y = interpolate(21 progress,22 [0, 1],23 [60, 0]24 );2526 const scale = interpolate(27 progress,28 [0, 1],29 [0.94, 1]30 );3132 return (33 <div34 style={{35 transform:36 `translateY(${y}px) scale(${scale})`,37 }}38 >39 Product Interface40 </div>41 );42};
このコンポーネントには、一発生成の動画には自然には備わらないものがあります。制御可能なパラメータです。
移動距離、登場タイミング、イージングの挙動、スケールなどを、クリップ全体を新規にリクエストすることなく変更できます。
カードが遠くへ動きすぎるなら、距離を縮めます。
収束が遅すぎるなら、バネの設定を調整します。
ヘッドラインが早く出すぎるなら、タイムライン上で登場を遅らせます。
ソースは常に編集可能です。
これこそが、製品映像、UI アニメーション、解説動画、タイポグラフィ主導コンテンツにおいて、コードで作るモーションが持つ強みです。
写実的なシーン、複雑なキャラクター、有機的でシネマティックな動きに対して自動的に優れているわけではありません。それらには依然として実写映像、3D ツール、生成系動画が必要になる場合があります。
重要なのは、自分が実際に作ろうとしている作品に対して制御権を与えてくれる制作方法を選ぶことです。
そして製品映像においては、予測不能さよりも制御性の方が価値を持つことが多いのです。
09. レンダーエンジニアに正確な要件を与える
レンダリングは、デザインとは切り離された責任です。
アニメーターが映像を組み立て、レンダーエンジニアがその構図が要求される解像度とフレームレートで実際に書き出せるかを確認します。
最初のパスでは、600 フレームすべてを最終品質でレンダリングしないでください。
まず代表的な静止画をレンダリングします。
プロンプト 4. レンダリング課題
1レンダーエンジニアとして行動してください。23BRIEF.md、STYLE.md、STORYBOARD.md を読んでください。45既存のコンポジションを検証してください。67最終レンダリングの前に：891. コンポジションの解像度を確認する。102. フレームレートと尺を確認する。113. すべてのフォントが読み込まれるか確認する。124. すべての製品アセットが存在するか確認する。135. 代表的な静止フレームをレンダリングする。146. 低コストのモーションプレビューをレンダリングする。157. ランタイムエラーを報告する。1617クリエイティブディレクションを変更しないでください。1819プレビューがレビューを通過するまで、20最終納品物をレンダリングしないでください。
Remotion では、選択したフレームを直接レンダリングできます。
1mkdir -p out/previews23npx remotion still Launch \4 out/previews/opening.png --frame=3056npx remotion still Launch \7 out/previews/action.png --frame=15089npx remotion still Launch \10 out/previews/result.png --frame=3901112npx remotion still Launch \13 out/previews/closing.png --frame=570
ここで Launch はサンプルプロジェクトのコンポジション ID です。ご自身の Remotion プロジェクトで設定した ID に置き換えてください。
これらの 4 枚の静止画は、動きを検証する前であっても、主なストーリーを語れるはずです。
オープニングが凡庸だったり、製品が読めなかったり、エンディングの階層が貧弱だったりするなら、映像全体を書き出した後ではなく今すぐ修正する方が良いでしょう。
動きに絞ったプレビューが必要な場合は、インタラクション周辺の区間だけをレンダリングします。
1npx remotion render Launch \2 out/previews/interaction.mp4 \3 --frames=90-330 \4 --codec=h264
これでエージェントは、検証するための実際の動画成果物を得ます。
「こう作るつもりだった」という説明だけではありません。
この違いは重要です。ソースコードは正しく見えても、結果はひどい見た目になることがあるからです。
アニメーションを判断する唯一の信頼できる方法は、レンダラーが実際に生成したものを見ることです。
パート 4. 批評家がいるからこそスタジオになる
10. アニメーターに自分の仕事を承認させない
これは多くの人が忘れる部門です。
モデルがコードを書き、動画が正常にレンダリングされ、エージェントが「すべて完了した」と宣言します。
しかし、レンダリングが成功したことはファイルが存在することを証明するだけです。
動画が良いものであることの証明にはなりません。
カーソルがヘッドラインを隠しているかもしれません。カードの収束が遅すぎるかもしれません。スマホでは製品が読めないかもしれません。トランジションは技術的に機能しても安っぽく見えるかもしれません。
プロのスタジオは、ソフトウェアが MP4 を書き出したというだけで納品しません。
結果をレビューします。
Claude に独立した批評フェーズを与えましょう。理想的には、元のブリーフとレンダリング済みフレームを含む新しいコンテキストで行います。
これにより、レビューが制作中の判断を単に擁護するだけになる可能性が減ります。
プロンプト 5. 独立したモーション批評
1あなたは批評家です。23あなたはこの映像のデザインやアニメーションを行っていません。45提供されたコンタクトシート、静止フレーム、6動画プレビューをレビューしてください。781 から 10 で採点してください：910- 視覚的構図11- タイポグラフィ12- 製品の可読性13- モーションの品質14- タイミング15- 連続性16- ブランドの一貫性1718最も重要な問題点を 3 つ見つけてください。1920各問題について以下を提示してください：2122フレームまたはタイムスタンプ23どこで起きているか。2425観察26視覚的に何が間違っているか。2728なぜ重要か29それがどう映像を損なうか。3031最小限かつ有効な修正32何を変えるべきか。3334保持すべき点35何を変えずに残すべきか。3637アニメーターの説明に基づいて承認しないでください。3839レポートを reviews/findings.md として保存してください。
これでレビューは、アニメーターが実際に手を動かせるものを生み出します。
「もっとプロっぽくして」ではなく、批評家は次のように報告できます。
1DEFECT 0123FRAME:421056PROBLEM:7カーソルが結果ラベルを横切っている。89CAUSE:10カーソルの退場と結果の表示タイミングが重なっている。1112FIX:13ラベルが表示される前に14カーソルを移動させる。1516PRESERVE:17クリックのタイミング18カードの寸法19結果のアニメーション2021RECHECK:22フレーム 195、210、225、240
結果のアニメーション
RECHECK:
フレーム 195、210、225、240
これにより、主観的なフィードバックがエンジニアリング作業へと変わります。
Critic が問題を特定し、Animator が修正し、Render Engineer が該当するフレームを再度エクスポートします。
動画全体を再生成する必要はありません。
本格的な制作作業では、Critic は静止画フレームと動画プレビューの両方を検査すべきです。
静止画はレイアウトの欠陥を明らかにし、動画はテンポの悪さ、不自然なトランジション、動きの不自然さ、タイミングの問題を浮き彫りにします。
どちらか一方で他方を完全に代替することはできません。
11. いつ止めるべきかを理解した修正ループを構築する
最も実用的な制作ループはシンプルです。
1 ANIMATE2 |3 v4 RENDER PREVIEW5 |6 v7 CRITIC REVIEW8 |9 +--------+--------+10 | |11 PASS FAIL12 | |13 v v14 DELIVERY SPECIFIC FINDINGS15 |16 v17 LOCAL REPAIR18 |19 v20 RENDER AGAIN21 |22 +----> REVIEW
重要なのは「ローカル（局所的）」という言葉です。
フレーム 210 の欠陥が、根本的なクリエイティブコンセプト自体が破綻していない限り、ストーリーボード全体の書き直しを引き起こすべきではありません。
見出しが正しく折り返されていない場合は、幅やフォントサイズを調整します。
カーソルが結果に重なる場合は、カーソルの軌道を変更します。
シーンの終わりが唐突すぎる場合は、タイミングやトランジションを修正します。
エージェントは、承認済みの作業を保持したまま、失敗した部分だけを修復すべきです。
ループには制限を設けましょう。
プロンプト 6. 修復ポリシー
1レビューで不合格となった場合の修復プロセスを作成してください。23すべての欠陥について：451. Critic の証拠を読み取る。62. 最小限の関連変更を特定する。73. 承認済みの決定事項を保持する。84. 影響を受けたソースをパッチ修正する。95. 影響を受けたフレームをレンダリングする。106. 隣接するシーンの境界を検査する。117. 新しい証拠を返す。1213上限：14欠陥1件につき最大2回の修復ラウンド。15162回のラウンド後も同じ問題が17未解決の場合：1819停止する。20ブロック要因を説明する。21人間の指示を求める。2223レビューを通すためだけに24検証要件を削除してはならない。
ブロック要因を説明する。
人間の指示を求める。
検証要件を削除してはならない
レビューを通すためだけに。
これにより、エージェントは終わりなき修正サイクルに迷い込むことなく、自らの出力を改善できるようになります。
スタジオには反復する能力が必要です。
同時に、予算と停止ルールも必要です。
有用な自律性と制御不能な実験の違いは、システムが「成功とは何か」「どのような証拠が必要か」「いつ助けを求めるべきか」を理解しているかどうかにかかっています。
パート 5. 1本の動画から本物のスタジオへ
12. 1回のレンダリング ≠ 1つの成果物
スタートアップが 1 つの動画ファイルだけで済むことはほとんどありません。
同じ製品ローンチでも、ウェブサイト用のワイド版、X 用の正方形版、Reels や Shorts 用の縦型版が必要になるかもしれません。
元動画を単にクロップするだけでは、構図が崩れてしまいます。
横長のシーンでは製品と見出しが並んで表示されていても、縦長のシーンでは先に見出しを表示し、その後インターフェースで画面を満たす必要があるかもしれません。
ナラティブは同じでも、構図は変わります。
1 ONE FILM2 |3 +-------------+-------------+4 | | |5 v v v6 16:9 1:1 9:167 | | |8 v v v9 WEBSITE X / SOCIAL REELS10 YOUTUBE SQUARE POST SHORTS1112 Wider Balanced Vertical13 context composition hierarchy
同じソースアセットと承認済みのストーリーから、レスポンシブな別々のコンポジションや、フォーマット固有のシーンレイアウトを作成するようエージェントに依頼しましょう。
ワイド版のレンダリングが成功したからといって、縦型版も問題ないと決めつけてはいけません。
各フォーマットには、それぞれ専用の静止画とレビューが必要です。
洗練された納品パッケージには、3 つ以上の MP4 ファイルが含まれるべきです。最終動画、ポスターフレーム、編集可能なソース、承認済みアセット、そして残存する制約についての簡単なメモを含めましょう。
そうすることで、クライアントに 1 つのエクスポートファイルだけを残して修正手段を与えない状態を避け、実際のローンチで使える成果物となります。
13. スタジオを残し、プロジェクトを入れ替える
ここで、1 つの Bot が本格的な制作システムへと進化し始めます。
多くの人は動画を完成させるとチャットを閉じ、次回はゼロからやり直します。
しかしスタジオは、重要な部分を保持します。
スタイリングルール、再利用可能なコンポーネント、アニメーション手法、レビューチェックリスト、レンダリングコマンド、出力構造は残すべきです。
変更が必要なのは、プロジェクト固有の入力だけです。
1FIRST VIDEO23Brief A4 |5 v6Studio Pipeline7 |8 v9Film A1011SECOND VIDEO1213Brief B14 |15 v16SAME Studio Pipeline17 |18 v19Film B2021THIRD VIDEO2223Brief C24 |25 v26IMPROVED Studio Pipeline27 |28 v29Film C
たとえば、Critic が何度も同じ問題を指摘すると想像してみてください。「視聴者が読み終える前に見出しが消えてしまう」という問題です。
動画ごとに手動で修正することもできます。
あるいは、スタジオのルールを更新して明示的な読了待ち時間を必須とし、レビュー時にそれをテストすることもできます。
こうすれば、新しい動画はすべてその修正を受け継ぎます。
縦型エクスポートで読めなくなる製品スクリーンショット、重要な情報を隠してしまうトランジション、インターフェースのラベルと衝突するカーソルアニメーションについても同様です。
繰り返されるあらゆるミスは、ルール、再利用可能なコンポーネント、または新しいレビュー項目に変換できます。
これが、最終エクスポートだけでなく制作プロセス自体を保存することの利点です。
次の動画にもクリエイティブディレクションは必要ですが、スタジオ全体をゼロから再構築する必要はありません。
14. プロセスを再利用可能な Skill に変える
最初のプロジェクトがレビューを通過したら、スタジオの作業手順を Claude Code の Skill として保存します。
Skill には、特定のローンチにおける製品名、スクリーンショット、コピーを含めてはいけません。
含めるべきは制作方法の説明です。
プロンプト 7. スタジオ Skill の作成
1motion-studio という名前の再利用可能な Skill を作成してください。23目的45承認済みのクリエイティブブリーフを、6プロフェッショナルなコードレンダリング動画に変換する。78ワークフロー910DIRECTOR11リクエストを分析する。12ブリーフとストーリーボードを作成する。1314ART DIRECTOR15リファレンスを検査する。16一貫したビジュアルディレクションを定義する。1718ANIMATOR19編集可能でフレーム駆動のモーションを構築する。2021RENDER ENGINEER22静止画とプレビューをレンダリングする。23技術的な出力を検証する。2425CRITIC26実際のレンダリングを検査する。27証拠に基づいた修正を返す。2829DELIVERY30承認されたフォーマットをエクスポートする。31ソースと制作メモを提供する。3233ルール3435- 製品アセットを捏造しない。36- クリエイティブ承認ゲートをスキップしない。37- 未検査の出力を承認しない。38- 修正は局所的に行う。39- 修復の繰り返し回数を制限する。40- 重要なアーティファクトはすべて保存する。4142出力4344最終動画45ポスターフレーム46コンタクトシート47編集可能なソース48レビュースコア
これで、次の案件の規模はずっと小さくなります。
あなたは製品、ターゲット層、ビジュアルリファレンス、期待する結果を提供します。
Skill が手順を提供します。
エージェントは、チャット履歴から制作ワークフロー全体を再構築する必要がありません。
ここから、このプロセスの経済性も変わり始めます。
最初の動画には、かなりの準備と試行錯誤が必要かもしれません。
2 本目は、シーン構成、モーションコンポーネント、レンダリングコマンド、ビジュアル QA プロセスを再利用できます。
3 本目は、最初の 2 本で見つかった修正の恩恵を受けられます。
蓄積されているのは出力ファイルだけではありません。
制作能力そのものが蓄積されているのです。
パート 6. 初めてのワン Bot スタジオプロジェクト
15. マスタープロンプト
ワークスペース、ルール、制作ステージが整えば、Opus にはるかに大きなタスクを任せることができます。
一発勝負のプロンプトとの決定的な違いは、エージェントに従うべき明確なプロセスがあり、人間の承認が必要なポイントが定義されていることです。
以下は私が使うマスタープロンプトです。
マスタープロンプト. モーションスタジオの実行
1あなたは私のモーションデザインスタジオを運営しています。23あなたの目標は、プロフェッショナルな420秒の製品ローンチ動画を制作することです。56プロジェクト78製品：[名前]9ウェブサイト：[URL]10ターゲット層：[オーディエンス]11メインメッセージ：[1文]1213承認済みのスクリーンショット、ロゴ、14フォント、リファレンスを使用してください。1516STAGE 1: DIRECTOR1718アセットを検査する。19BRIEF.md を作成する。20ストーリーボードを作成する。21中心的なビジュアルストーリーを定義する。2223承認を求める。2425STAGE 2: ART DIRECTOR2627リファレンスを分析する。28STYLE.md を作成する。29タイポグラフィ、カラー、30構図、モーションを定義する。3132承認を求める。3334STAGE 3: ANIMATOR3536Remotion を使用して動画を構築する。37決定論的でフレーム駆動のアニメーションを使用する。38承認済みの製品詳細と39シーンの連続性を保持する。4041STAGE 4: RENDER ENGINEER4243代表的な静止画をレンダリングする。44ラフカットのプレビューをレンダリングする。4546確認項目：47- 寸法48- フレームレート49- フォント50- アセット51- ランタイムエラー5253STAGE 5: CRITIC5455実際にレンダリングされたフレームをレビューする。5657正確なフレーム番号とともに58最大の欠陥3つを特定する。5960局所的な修復を提案する。6162STAGE 6: CORRECTION6364影響の大きい欠陥を修正する。65承認済みの作業を保持する。66影響を受けたフレームを再度レンダリングする。6768修復ラウンドが2回失敗したら停止する。6970STAGE 7: DELIVERY7172エクスポート：73- 16:974- 1:175- 9:167677含めるもの：78- MP4 ファイル79- ポスターフレーム80- 編集可能なソース81- コンタクトシート82- QA レポート8384重要事項8586製品画面や主張を決して捏造しない。87レビュー段階を決してスキップしない。8889エクスポートの成功は、クリエイティブな品質を90証明するものではない。9192重要なクリエイティブ判断や公開の前に93必ず承認のため停止する。
それでも、質の高いインプットを提供する必要があります。
Bot には、実際の製品素材、明確な目的、ビジュアルディレクションを理解できる十分なリファレンスが必要です。
しかし今やあなたは、単一のアニメーションを依頼するのではなく、制作ワークフロー全体を委任しています。
これこそが、Opus 5.5 のはるかに興味深い活用法です。
1 つの Bot は本当にモーションスタジオを代替できるのか？
特定の種類の制作においては、小規模スタジオが手作業で行うであろう驚くほど多くの作業を引き継ぐことができます。
製品ローンチアニメーション、インターフェースデモンストレーション、タイポグラフィ動画、データビジュアライゼーション、短い解説動画は、制御可能なコードとして表現できるため特に適しています。
ただし、ワークフローを置き換えることと、クリエイティブな判断すべてを置き換えることは別問題です。
モデルは複数の方向性を生成できますが、どれがブランドを正しく表現しているかを決めるのは人間です。
フレームを検査して問題を見つけることはできますが、主観的な品質はテストに完全還元できるものではありません。
音楽やエフェクトを組み込むことはできますが、利用権、クライアントの期待、最終的な公開判断は依然として重要です。
真の価値は、作業のバランスを変えることにあります。
エディターで要素を動かすことに大半の時間を費やす代わりに、クリエイティブディレクションの定義、結果のレビュー、制作プロセスの改善により多くの時間を割けるようになります。
これは、機能リリースのたびに制作チームを再編成することなく強力な製品動画が必要なソロファウンダー、開発者、インディークリエイター、小規模チームにとって特に魅力的です。
そしてもう一つ、このアプローチが重要である理由があります。
従来の AI 生成動画は、細部を正確に修正するのが難しいことがよくあります。
あるカットは気に入っても、1 つのトランジションだけが気に入らないかもしれません。アニメーションの他の部分を変えずにスクリーンショットだけを差し替えたいかもしれません。まったく同じ動画を 3 つのフォーマットで用意する必要があるかもしれません。
コードレンダリングによる制作であれば、こうした変更はソースに対する制御された編集として表現できることが多いのです。
見出しが変わったからといって、別の動画を作る必要はありません。
ブランドカラーが変わっても、タイムライン全体を再構築する必要はありません。
タイミングの修正は、問題が発生しているフレーム単位で行えます。
これは単なる利便性の話ではありません。
アセットを「生成する」ことと、制作システムを「維持する」ことの違いなのです。
本当の変化
Opus 5.5 によるモーションデザインで最も興味深いのは、一夜にして作られるバズるアニメーションではありません。
その能力を再現可能なスタジオへと変えたときに何が起こるか、です。
1 つのエージェントが、クリエイティブブリーフの管理、ビジュアルシステムの確立、アニメーションの実装、プレビューのレンダリング、欠陥の批評、最終成果物の準備までをこなせます。
レンダラーが動画を再現可能にします。
ストーリーボードが物語を意図的なものにします。
レビューループがミスを可視化します。
保存されたコンポーネントと Skill が、次のプロジェクトをより簡単にします。
従来型の一発勝負プロセスはこうです。
プロンプトが動画を生成する。動画がエクスポートされる。次のプロジェクトはまたゼロから始まる。
ワン Bot スタジオは異なります。
完成したプロジェクトはすべて、より良いテンプレート、より優れたモーションコンポーネント、より強固なレビュー基準、より信頼性の高い納品手順を後に残すことができます。
最初の動画は、可能性を示すからこそ印象的です。
5 本目は、制作プロセスが再現可能になり始めるからこそ興味深いです。
20 本目になると、蓄積された Skill、コンポーネント、チェック、クリエイティブルールが、どの個別のプロンプトよりも価値を持つようになります。
本当の機会は、AI で 1 本の動画を作ることではありません。動画を作るたびに成長していくスタジオを構築することです。
そして適切な環境があれば、そのスタジオは 1 つの Bot から始められるのです。
ここまで読んでくれた方へ
AI 生成動画を、ますます複雑化するプロンプトで修正しようとして夜を過ごす前に、このガイドをブックマークしておいてください。
X でフォローしてください：x.com/0xjmori
Substack を購読してください：substack.com/@lunarresearcher
次に製品ローンチ動画が必要になったとき、ただ何かをアニメーション化してほしいと Claude に頼まないでください。
運営すべきスタジオを与えてあげてください。
参考資料
