# Camera Motion Lab：147 本の動画が教えてくれたカメラの動かし方 > 147 本の AI 動画で 64 種類のカメラの動きをテストし、映画の専門用語が、動画モデルに最もよく伝わる言葉ではないことがわかりました。うまくいく方法を紹介します。 Source: https://nodaro.ai/ja/docs/research/camera-motion-lab 64 種類のカメラの動きをテストした結果、映画の専門用語が、動画モデルに最もよく伝わる言葉だとは限らないことがわかりました。最初は、単純な問題に見えました。 Nodaro には[**カメラモーション**（Camera Motion）](https://nodaro.ai/docs/nodes/creative-controls/camera-motion)ピッカーがあります。ユーザーがオービット、トラック、ドリー・イン、ウィップパンなどの動きを選ぶと、私たちはその動きの短い説明を、動画のプロンプトの末尾に追加します。まずは、最もシンプルなプロの指示から始めました。 ``` camera trucks to the left ``` 撮影監督や映画監督なら、誰でもすぐに理解できる指示です。**モデルは、ほとんど動きませんでした**。次に、オービットを試しました。 ``` camera orbits around the subject to the left in a circular path ``` 今回も、結果は安定しませんでした。正しい方向に動いたのは、およそ半分だけでした。説明を増やしてもみました。方向を表す別の表現、角度、より強い言い回し、除外の指示、異なるクリップの長さを試しました。結果が良くなることもありました。悪くなることもありました。そして、モデルがまったく別のことをする場合もありました。そこで、動きの名前をモデルに伝えるのをやめました。代わりに、カメラが物理的に何をするのかを説明し始めました。**これで、ほぼすべてが変わりました**。 ## 研究の流れを変えた 2 つの発見実験を終えるまでに、私たちは 2 つの核となる発見にたどり着きました。記述するのは、何が動くか、何が一定に保たれるか、手前と奥の要素が互いにどう動くか、そしてカメラがどこで終わるべきかです。元の画像がすでにモデルを別の方向へ引っ張っていると、妥当なモーションプロンプトでも、間違った動きになることがあります。 ## 実際にテストした内容研究期間は 25 日間でした。147 本の動画と 13 枚のベース画像を生成し、合計 72,118 クレジットを使いました。研究期間中に公開されていたクレジットの購入価格で、およそ 200〜220 ドルに相当します。 98 本は 480p の [Seedance 2.5](https://nodaro.ai/docs/models/video/seedance-2-5) で、47 本は [Seedance 2 Fast](https://nodaro.ai/docs/models/video/seedance-2-fast) で生成しました。残りの 2 本は、初期にプロバイダーを比較した際に、VEO 3.1 で生成したものです。最終的に、対象としたカメラモーションの 64 個のオプションが、すべて承認されました。内訳は、Seedance 2.5 で 61 個、Seedance 2 Fast で 3 個です。 **範囲：統計的なベンチマークではなく、製品開発のための研究:** 普遍的な成功確率を推定するために、すべてのプロンプトを何百回も実行したわけではありません。目的は、ピッカーのすべてのオプションについて、本番で使えるだけの安定性を持つ汎用的な指示を見つけることでした。テストは主に Seedance 2.5 と Seedance 2 Fast で、画像から動画（image-to-video）、480p の解像度、英語のプロンプトを使って行いました。この記事で何かが「うまくいった」「失敗した」と書く場合、それはこの一連の実験で起きたことを指します。すべての動画モデルが、常に同じように振る舞うという意味ではありません。この区別が特に重要になったのは、実際には存在しなかったバイアスを、危うくモデルのせいにしかけたときでした。 ## 存在しなかった「左へのバイアス」研究の初期に、同じ動きを逆方向でテストしました。画像も、プロンプトの構成も、長さも同じです。左は 3 回中 3 回成功しました。右は 3 回中 1 回しか成功しませんでした。この傾向は、4 種類の言い回しで試した右方向の 12 回の試行を通じて、変わりませんでした。結論は明らかに思えました。モデルには左へのバイアスがある、というものです。そのために、追加で 240 クレジットの予算まで組みました。**私たちは間違っていました**。問題は、方向の書き方にありました。方向を、被写体に対してどちら側かではなく、カメラが移動する向きとして表すようにすると、この傾向は消えました。それ以降、この書き方でテストした右方向の動きは、1 テイク目で合格しました。これは、このプロジェクトで最も重要な教訓の 1 つになりました。一貫した失敗のパターンは、必ずしもモデルの性質を示しているわけではありません。ときには、あなたの表現の問題を示しています。 ## 突破口：動きは幾何学転機になったのは、アーク・ライトでした。モデルに動きの名前だけを渡すのではなく、次の 5 つを記述しました。 1. カメラが物理的に何をするか。 2. 何が一定に保たれるか。 3. 手前と奥の要素が、互いにどう動くべきか。 4. 最後の視点が、どう見えるべきか。 5. どの不要な動きが、起きてはならないか。承認されたプロンプトは、次のとおりです。5 つの項目それぞれに、1 文ずつ対応しています。 | 項目 | 承認されたアーク・ライトのプロンプトの文 | | --- | --- | | **1. 動き** | `The camera slowly moves sideways to the right while curving around the subject, continuously turning toward the subject to keep the same centered framing.` | | **2. 一定に保つもの** | `The camera maintains constant distance from the subject.` | | **3. 奥行き** | `As the viewpoint changes, strong natural parallax is visible: nearby environmental elements shift right noticeably while distant background elements shift right more slowly.` | | **4. 終了状態** | `The shot ends from a slightly different three-quarter viewing angle.` | | **5. ガードレール** | `No zoom, no push-in, no pull-out.` | `parallax`（視差）という語がそのまま残っているのは、これが実際にテストしたプロンプトだからです。考え方はシンプルです。カメラが空間の中を物理的に移動すると、手前の物体と奥の物体は、同じ速さではフレームを横切りません。このプロンプトの重要な違いは、長さではありません。私たちが `Arc` で何を意味しているかを、モデルが理解してくれることに頼らなくなった点です。このプロンプトは、動きそのものを記述しています。カメラは被写体の周りを弧を描きながら横に移動し、構図を保つために被写体の方を向き続け、距離を保ち、手前の要素が奥の要素より大きくずれて見え、少し違う視点で終わります。この変更の前は、アーク・ライトに 12 テイクを費やしても、弱い結果しか得られませんでした。幾何学的な記述にすると、3 回中 3 回成功しました。 Comparison: 同じベース画像から作った、アーク・ライトの変更前と変更後。 - Before: [古い表現によるアーク・ライト：カメラが逆方向に弧を描く. 動きの名前に頼った表現、12 テイク中の 1 テイク目。右への弧を指示したのに、左へ動きました。](https://nodaro.ai/docs-media/research/camera-motion-lab/arc-before.mp4) - After: [幾何学的な表現によるアーク・ライト：右へきれいに弧を描く. 幾何学的な表現、1 テイク目。](https://nodaro.ai/docs-media/research/camera-motion-lab/arc-after.mp4) ## カメラが本当に動いたかを見分けるには？手前の物体と奥の物体の動きの違いは、最も役に立つ診断ツールの 1 つになりました。カメラが空間の中を物理的に移動すると、奥行きのレイヤー同士の関係が変わります。カメラに近い物体は、たいてい遠くの物体より速くフレームを横切ります。カメラがその場で回転するだけなら、フレームは動いても、奥行きの変化は同じようには起きません。そして純粋なズームであれば、カメラはまったく動かず、遠近感もほとんど変わりません。ここから、役に立つ分類が得られました。 | 動き | カメラの動作 | 見えるはずのもの | | --- | --- | --- | | **オービット、ドリー、トラック、ペデスタル、クレーン** | 空間の中を移動する | 手前と奥の要素の関係が、はっきり変わる | | **パン、ティルト、ロール** | その場で回転する | フレームは動くが、同じような奥行きの変化はない | | **ズーム** | 移動しない | 同じ画像を拡大・縮小したように、遠近感が変わらない | | **ドリーズーム** | 移動しながら、同時に焦点距離が変わる | ごまかしにくい、別のテスト（下記参照） | ドリーズームでプロンプトに書き込んだテストは、次のとおりです。 ``` THE SUBJECT NEVER CHANGES SIZE. ``` 大文字は、承認されたプロンプトに書かれていたとおりです。 ## 5 回失敗した 360 度被写体の周りを 1 周する動きは、研究の初期に最も難しかったケースの 1 つです。元の表現では、1 周に遠く及びませんでした。 `180 degrees` を試すと、1 周に近い動きにはなりましたが、方向が逆でした。次に、これを試しました。 ``` all the way around ... returning to where it started ``` 結果はさらに悪く、カメラは開始位置から少し離れただけで、また戻ってきました。ある時点では、動画のリファレンスなしで確実な 360 度は無理かもしれない、とメモに書いてさえいました。**私たちは、また間違っていました**。解決策は、「360」と頼むのをやめ、代わりに経路を状態の連なりとして記述することでした。被写体の片側、被写体の後ろ、反対側、そして開始位置へ戻る、という順番です。さらに、ごまかしにくいテストも加えました。 ``` every part of the surroundings passes behind the subject in turn ``` カメラが本当に被写体の周りを回っていなければ、この条件をもっともらしく満たすのは困難です。最後に、次の指示を加えました。 ``` no reversal of direction ``` 新しい表現は、最初のテイクで合格しました。 Comparison: 失敗した 360 度の試行と、承認された 360 度。 - Before: [元のカタログの表現による 360 度オービット：1 周には遠く及ばない. 元のカタログの表現。1 周には遠く及びません。](https://nodaro.ai/docs-media/research/camera-motion-lab/orbit360-before.mp4) - After: [経路を状態の連なりとして記述した 360 度オービット：完全に 1 周する. 経路を状態の連なりとして記述し、ごまかしにくいテストを追加。1 テイク目。](https://nodaro.ai/docs-media/research/camera-motion-lab/orbit360-after.mp4) ## 「もっと」を求めると、かえって少なくなることも別の場面では、次のフレーズで経路を延ばそうとしました。 ``` travelling a long way around ``` 結果は、予想とは逆でした。被写体の周りに時計の文字盤を想像すると、カメラは 6 時の位置から動き始めました。このフレーズがあると 5 時あたりまでしか進まず、ないと 4 時あたりまで進みました。つまり、より長い経路を求めたことで、動きが短くなったのです。数値も、期待したほどの精度をもたらしませんでした。たとえば `180 degrees` と書いても、確実に 180 度動くわけではありませんでした。数値が常に間違っている、というのが私たちの結論ではありません。プロンプトの中で数値として指定した角度や移動量は、この目的には十分な信頼性がなかった、ということです。ただし、別のある数値が非常に重要だとわかりました。クリップの長さです。 ## クリップの長さも動きの一部同じプロンプトで、5 秒ではおよそ円の 6 分の 1、15 秒では約 150 度を移動しました。ただし、限界もありました。15 秒で試したある回では、カメラが終点に達した後、残りの時間を埋めるために逆方向へ動き始めました。正しい動きが終わった後に逆戻りし始める場合は、まず、クリップを短くすべきかを確認します。すぐにプロンプトを書き直さないでください。ただし、重要な例外があります。ブリージングとプッシュプルです。どちらの動きも、寄ったり引いたりを繰り返すこと自体が動きです。この 2 つでは、繰り返しがきちんと伝わる時間を確保するため、クリップを 10 秒に延ばしました。 ## 速さは、どう見えるかで指示する「fast」や「slow」のような言葉だけでは、やはり十分に制御できませんでした。うまくいったのは、速さの結果として目に見えるものを記述することです。たとえばウィップパンでは、次の表現を使いました。 ``` the whole frame smears into heavy horizontal motion blur ``` クリープインでは、ほぼ逆のことをしました。 ``` the picture stays completely sharp with no motion blur at all ``` 適切な長さと組み合わせると、違いがはるかに明確になりました。ドリーのカテゴリでは、これが事実上、速さの段階を作り出しました。根底にある幾何学的な記述の大部分は、ほぼ同じままでかまいません。そのため、どれだけ速く動くかをモデルに伝えるだけでなく、その速さが画面上でどう見えるべきかを記述したほうが、効果的な場合があります。 ## 否定の指示はガードレールであり、エンジンではない当初、私たちは否定の指示はまったく効かないと考えていました。しかし、その結論は言い過ぎでした。次の指示で、3 テイクを実行しました。 ``` no zoom, no push-in ``` それでも、カメラは前に寄っていきました。うまくいったのは、まず望む動作を肯定形で定義することでした。 ``` The camera maintains constant distance from the subject. ``` そして、その後で初めて、次の文を加えます。 ``` No zoom, no push-in, no pull-out. ``` 承認されたプロンプトについて、除外の行がある場合とない場合を比べる対照実験は行っていません。そのため、成功のうちどれだけがその行によるものかは測れません。より慎重な結論は、肯定形の指示が主なエンジンであり、除外の指示は私たちのワークフローにおける追加のガードレールとして働く、というものです。スクリーンタップとフォンフリップも、同じパターンを裏付けています。うまくいった修正では、起きるべきことの肯定的な記述と、現れてはならないものの明示的な除外を組み合わせていました。 ## 言葉が映像に漏れ出す研究の後半では、問題が物理ではない場合もあることがわかりました。原因は、たった 1 つの単語でした。動画モデルは、感覚を表すためだけに選んだ単語を、文字どおりの視覚的な動作に変えてしまうことがあります。 - **ペデスタル・アップ**：`rock strata ... descend into view` と書きました。モデルは視点を変えるだけでなく、岩そのものを落下させ、クリップの終わりには積み上げてしまいました。この文はシーン内の特定の物体を名指しし、下向きの動作を、カメラではなくその物体に結び付けていました。 - **ドリーズーム**：`bend` や `dizzying` といった単語を使いました。すると、奥行きが引き伸ばされる代わりに、フレームがおよそ 90 度ロールしました。感覚を表すために選んだ単語が、ロールの指示として読み取られたのです。 - **スクリーンタップ**：`finger tap` というフレーズによって、モデルはシーンの中に本物の指を描き、クリック音まで付けました。 - **フォンフリップ**：`rotates` という単語は、1 回のすばやい反転ではなく、カルーセルのようになめらかに回り続ける回転になりました。実際に求める動きに属する語彙だけを使い、変わってはならない軸を明示的に守ります。たとえばドリーズームでは、次のように書きます。 ``` The frame stays perfectly upright and level throughout. ``` Comparison: およそ 90 度ロールしたドリーズームと、承認された結果。 - Before: [ドリーズームの 1 テイク目：フレームが横に回転する. 1 テイク目。「bend」と「dizzying」を使用。フレームがおよそ 90 度ロールしました。](https://nodaro.ai/docs-media/research/camera-motion-lab/dollyzoom-before.mp4) - After: [ドリーズームの 2 テイク目：フレームは水平のまま、奥行きが伸びる. 2 テイク目。奥行きだけを記述し、フレームを水平に保つ表現。](https://nodaro.ai/docs-media/research/camera-motion-lab/dollyzoom-after.mp4) ## 中の世界ではなく、フレームを記述するカメラモーションの指示は、ユーザーが動かす可能性のあるあらゆるものに対して機能しなければなりません。船、車、室内、街路、人物、水中のシーンなどです。そのため、シーンに空、床、山、壁、特定のランプがあることを前提にはできません。研究の初期に、`the turquoise lamp post` に言及する表現を不採用にしました。シーン固有の記述は、テスト画像では実際に効果があるため、この落とし穴にはまりやすいのです。しかし、画像にターコイズ色の街灯があるからこそ機能するプロンプトなら、それは汎用的なカメラの動きではありません。1 枚の画像専用のプロンプトを作ったにすぎません。一方で、抽象化しすぎるのも逆効果になることがあります。トラックでは、`new elements keep entering from the left edge` を、より抽象的な言い回しに置き換えてみました。これは失敗しました。`elements` という語はシーン内の特定の内容を指していないため、元の表現に戻しました。要素や奥行きのレイヤーの振る舞いは、記述してかまいません。次のシーンに存在しないかもしれない物体は、名指ししないでください。 ## 撮影機材さえ映り込む撮影機材が、物理的な制約を記述するのに役立つこともありました。三脚は、回転はできてもカメラの移動はできません。垂直の支柱なら、回転せずに上昇する動きを表せます。ジブなら、上下の動きと角度の変化の組み合わせを表せます。しかし、そこには別の落とし穴がありました。私たちは、こう書きました。 ``` a wheeled dolly running along a track ``` モデルは、そのままショットの中にレールを描いてしまいました。 Comparison: ショットの中に描かれたドリーのレールと、承認されたドリー・イン。 - Before: [機材を名指ししたドリー・イン：ドリーとレールがショットに映り込む. プロンプトで機材を名指し。レールがショットの中に描かれました。](https://nodaro.ai/docs-media/research/camera-motion-lab/track-before.mp4) - After: [機材を名指ししない、承認されたドリー・イン. 機材を名指ししないドリー・イン。](https://nodaro.ai/docs-media/research/camera-motion-lab/track-after.mp4) プロンプトで機材を物理的な基準として使う場合は、本来カメラの後ろにあって、フレームの中には映らないはずの機材を挙げます。 ## 2 つ目の発見：開始フレームもプロンプト研究の後半に、新しいパターンが見え始めました。表現は正しく見えました。修正しました。もう一度修正しました。それでも、同じ失敗が残りました。こうしたケースでは、私たちは間違ったところを直していたのです。**問題は、開始画像にありました**。画像から動画では、最初のフレームは単なる素材ではありません。カメラがどこにあり、どちらを向いていて、どんな続きが視覚的に自然かを、すでにモデルに伝えています。その指示が、テキストより強いこともあります。 ### POV になれなかった POV 森の中を歩く人物が写った画像で POV ウォークをテストし、カメラがその人物の主観視点になるよう指示しました。人物は、フレームの中に残ったままでした。振り返れば、これは当然のことです。最初の画像が、カメラは人物の外側にあって人物を見ている、ということをすでに確定させています。モデルはそのフレームから続きを作る必要があり、突然メインの被写体を消して、その人物の目の内側から視点を組み立て直すわけにはいきません。人物も体の一部も写っていない、氷のトンネルの新しいベース画像を作ると、同じ基本的な指示がすぐに合格しました。スノリカムからは、逆の教訓を得ました。スノリカムでは、カメラに対して固定された被写体が実際に見えていて、その周りで世界が動いていく必要があります。歩く人物が写ったベース画像では、1 テイク目で合格しました。開始画像の同じ性質が、ある動きにとっては不具合になり、別の動きにとっては必須条件になるのです。 ### どうしても降下するフライオーバーフライオーバーは最初、カメラがすでに外側かつ下方を向いている、都市の空撮画像でテストしました。一定の高度で前進するよう指示しました。カメラは降下しました。表現を強めました。また降下しました。同じころ、同じベース画像で試した空撮（Aerial）の 3 回の試行も、すべて、カメラがきれいに垂直降下するのではなく、下向きに傾きました。指示をさらに増やす代わりに、巡航高度の新しいベース画像を作りました。水平で前を向いた視点、広い空、そしてカメラとほぼ同じ高さにある山々の頂です。このベース画像では、フライオーバーは 1 テイク目で合格しました。 Comparison: 旧ベース画像と新ベース画像での、フライオーバーの比較。 - 旧ベース画像: [都市のベース画像でのフライオーバー：カメラが屋根に向かって沈んでいく. 外側かつ下方を向いた都市のベース画像と、強めた表現。それでも沈みました。](https://nodaro.ai/docs-media/research/camera-motion-lab/flyover-before.mp4) - 新ベース画像: [巡航高度のベース画像でのフライオーバー：安定した水平飛行. 巡航高度の水平なベース画像。1 テイク目。](https://nodaro.ai/docs-media/research/camera-motion-lab/flyover-after.mp4) プロンプトを 2 回修正しても同じ失敗が残る場合は、さらに書き直す前に、開始画像がモデルに何を促しているかを確認します。 ### 測定器になったベース画像最終的に、13 枚のベース画像を作りました。見た目の美しさを第一に選んだわけではありません。カメラの動きが正しいかどうかが、はっきりと表れるように設計しました。良いベース画像は、正しい動きを見えるようにするだけではありません。**間違った動きが、どこにも隠れられないように設計されているのです**。 ## オーバー・ザ・ショルダー：1 テイクに 3 つの失敗カタログの最後を締めくくったオプションは、ひと目で見栄えがするからといってクリップを承認すべきではない理由を示す、良い例です。オーバー・ザ・ショルダーの最初のテイクには、3 つの別々の問題がありました。 - 誰も頼んでいない外国語の会話を、モデルが作り出しました。 - カメラが遠すぎる位置から始まり、最初から正しい構図になっているのではなく、プッシュインしました。 - 2 人目の人物が、自然に会話しているように見えるのではなく、カメラに向かってほほえみました。それぞれの問題を、個別に修正しました。会話中の身振りがより自然に見えるベース画像を作り、構図を固定する指示とプッシュインしない指示を明示的に加え、会話のない無音を指定したうえで、生成そのものでもサウンドをオフにしました。見た目が良いクリップでも、互いに独立した複数の点で、同時に失敗していることがあります。 ## すべてのオプションがカメラの動きとは限らないこの研究では、分類の問題も明らかになりました。マッチカット・ズーム、ベロシティエディット、スクリーンタップ、フォンフリップは、従来の意味でのカメラの動きではありません。編集効果やトランジション効果に近いものです。たとえばスクリーンタップでは、効果のきっかけとなる物理的な動作を記述したとたん、モデルがその動作を描きました。うまくいった表現は、代わりに、トランジションの結果としてフレームに何が起きるかを記述していました。このことから、これら 4 つのオプションは、カメラの動きではなくトランジションに分類すべきかもしれません。[**トランジション**（Transition）](https://nodaro.ai/docs/nodes/creative-controls/transition)ピッカーを参照してください。 Comparison: 指が映り込んだスクリーンタップと、承認されたバージョン。 - Before: [古い表現によるスクリーンタップ：本物の指がショットに入ってくる. 「finger tap」を含む表現。本物の指が現れました。ミュートを解除すると、クリック音が聞こえます。](https://nodaro.ai/docs-media/research/camera-motion-lab/screentap-before.mp4) - After: [フレームだけを記述した表現によるスクリーンタップ：すっきりとしたスナップカット. フレームだけを記述した表現。人物のいないベース画像を使用。](https://nodaro.ai/docs-media/research/camera-motion-lab/screentap-after.mp4) ## 手法が見つかってから変わったこと最も多くの授業料を払ったのは、オービットとアークのカテゴリでした。147 本の動画のうち 51 本は、このカテゴリのわずか 5 つのオプションのために生成したもので、1 オプションあたり平均 10 テイクを超えます。プロの用語だけでは十分に信頼できないことを学び、ありもしない「左へのバイアス」を危うく作り上げかけ、幾何学的なテンプレートが生まれたのも、このカテゴリでした。残りの 59 個のオプションにかかったのは、合計 91 テイクで、1 オプションあたり約 1.5 テイクです。トラックとティルトも比較的早い時期にテストしたため、この区分は厳密に時系列どおりではありません。それでも、学びの多くが最初のカテゴリに集中していたことがわかります。すべてを書き直す必要があったわけではありません。14 個のオプションは、元のカタログの表現のままで合格しました。そのころには、もう 1 つのプロセスルールを採用していました。何かを書き直す前に、既存の汎用的な表現を、そのまま適切なベース画像でテストします。教訓は「長いプロンプトほど良い」ではありません。動きを確実に定義するのに必要なことだけを書く、というのが教訓です。 ## 私たちが残した 13 のルール 1. モーションプロンプトの中では、角度、移動量、速さを数値で表しません。クリップの長さは、別のパラメーターです。 2. カメラの移動方向は、明確な 1 方向にします。同じ経路上の複数の通過点を記述するのはかまいませんが、互いに競合する方向の指示は出しません。 3. 被写体は、幾何学的な基準点として使えます。距離、被写体の大きさ、構図は有効な基準ですが、モーションプロンプトで被写体の動作や振る舞いを指示してはいけません。 4. シーンの具体的な内容を名指ししません。画像が変わっても使える指示にします。 5. 意図する動きに属する語彙を使い、変わってはならない軸を明示的に守ります。 6. まず、カメラが何をすべきかを肯定形で定義します。否定形の除外指示は追加のガードレールであり、望む動きの記述の代わりにはなりません。 7. ある奥行きのレイヤーを「ほとんど動かない」とは記述しません。奥行きを伝えるには、手前と奥の要素の間で、動きが段階的に異なることを記述します。 8. 手持ち、ステディカム、Vlog、ドリフトでは、カメラがその場にとどまるかどうかを明記する必要があります。そうしないと、揺れやふらつきが、望まない移動に変わることがあります。 9. 正しい動きが終わった後に逆戻りする場合は、まずクリップの長さを確認します。例外は、ブリージングやプッシュプルのように、戻る動き自体が動きの一部になっているものです。 10. 2 つのオプションが同じ幾何学を共有する場合は、動きの性格か、ごまかしにくい視覚的なテストで区別します。 11. 編集効果では、効果のきっかけとなる物理的な動作ではなく、フレームに何が起きるかを記述します。 12. 必ず、まず既存の表現をテストします。書き直しが必要な場合も、テスト画像の内容に合わせ込むのではなく、汎用的な表現を保ちます。 13. プロンプトを 2 回修正しても同じ失敗が残る場合は、書き直すのをやめて、開始フレームを確認します。 ## すべてのテイクで使うチェックリスト結果をレビューするとき、見た目が良いかどうかだけを問うのではありません。次の項目を、1 つずつ別々に確認します。 - 方向は正しいですか？ - カメラは実際に移動していますか、それともその場で回転しているだけですか？ - 被写体までの距離は、その動きが求めるとおりに変化していますか？ - モデルが余計なカメラの動きを作り出したり、ショットの中に撮影機材を描いたりしていませんか？ - 何かが落ちる、突然現れるなど、シーンの中に出来事を作り出していませんか？ - 被写体は世界の一部のままですか、それともカメラに取り付けられたかのように動いていますか？ - そしてもう 1 つ。動きが早く終わり、そうすべきでないのに逆戻りし始めていませんか？これらの確認を別々に行うことが重要です。オーバー・ザ・ショルダーでは、1 つのテイクが同時に 3 つの点で失敗しうることがわかりました。 ## 製品で変わったこと現在、[カメラモーション](https://nodaro.ai/docs/nodes/creative-controls/camera-motion)ピッカーでテストした 64 個のオプションはすべて、このラボで承認された表現を使っています。そのうち 14 個は、すでにうまく機能していたため、元の表現のままです。また、承認された表現が誤って変更されないよう、回帰テストを設けています。一方で、この研究では、いくつかの課題も残りました。 - 空撮は、垂直の降下と、視点を下へ傾ける動きを、まだ完全には区別できていません。 - ブーム・アップとブーム・ダウンは、ペデスタルやクレーンと大きく重なっています。 - 編集タイプの 4 つのオプションは、トランジションに分類したほうが合うかもしれません。 - クリップの長さは動きの重要な一部だとわかりましたが、ピッカーはまだ、動きの種類ごとに長さを提案していません。 ## わかったこと当初、私たちはモデルに、映画撮影の言葉をもっとよく理解させようとしていました。最後には、それが問題の本質ではなかったことに気づきました。ドリー、オービット、クレーンといった用語は、一連の物理的なルールを 1 つの単語に圧縮するために、人間が使う略語です。モデルは、その単語を必ずしも私たちと同じように解きほぐすわけではありません。名前に頼るのを減らし、物理をより明確に記述するほど、結果は予測しやすくなりました。何が動き、何が一定に保たれ、奥行きがどう変わり、手前と奥の要素が互いにどう動き、カメラがどこで終わるべきかを記述したのです。そして、2 つ目の発見がありました。画像から動画では、プロンプトだけが指示ではありません。最初のフレームも指示であり、ときにはそちらのほうが強いのです。そのため今では、カメラの動きが失敗したとき、「言葉のどこが悪いのか？」とだけ問うことはしません。こうも問います。**「言葉が始まる前に、画像はすでにモデルに何を伝えていたのか？」** 物理を的確に記述できるほど、映画の用語に頼る必要はなくなっていきました。 *Camera Motion Lab 研究ノート、2026 年 9 月。このページのクリップはすべて、研究で実際に生成したテイクです。480p の画像から動画で生成したもので、それを置き換えたテイクと並べて表示しています。* ## Frequently asked questions ### AI 動画モデルに、思いどおりにカメラを動かしてもらうにはどうすればよいですか？動きの名前を挙げるのではなく、幾何学として記述します。カメラが物理的に何をするか、何が一定に保たれるか、手前と奥の要素が互いにどうずれるか、ショットがどこで終わるか、どの不要な動きを起こしてはならないかを書きます。 ### AI 動画のカメラが、違う方向に動いてしまうのはなぜですか？多くの場合、原因はモデルではなく表現にあります。方向は、被写体に対してどちら側かではなく、カメラが移動する向きとして書いてください。2 回書き直しても同じ失敗が残る場合は、開始画像がカメラを別の方向へ引っ張っていないかを確認します。 ### カメラモーションのプロンプトで、「180 degrees」のような数値は効きますか？確実には効きません。私たちのテストでは、数値で指定した角度や移動量どおりの動きにはなりませんでした。別に設定するクリップの長さのほうが、カメラの移動距離にはるかに大きく影響しました。 ### ネガティブプロンプトで、不要なカメラの動きを止められますか？ガードレールとしてのみ役立ちます。「No zoom, no push-in」だけでは、プッシュインを止められませんでした。まず「the camera maintains constant distance from the subject」のように望む動きを定義し、その後に除外の指示を加えるほうが、うまくいきました。 ### 画像から動画を作る場合、開始画像はカメラの動きに影響しますか？はい、強く影響します。最初のフレームは、カメラがどこにあり、どんな続きが自然かを、すでにモデルに伝えています。歩いている人物が写った画像では主観視点の動きが失敗し、人物が写っていない画像ではすぐに合格しました。