<?xml version="1.0" encoding="utf-8" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>cy520569のブログ</title>
<link>https://ameblo.jp/cy520569/</link>
<atom:link href="https://rssblog.ameba.jp/cy520569/rss20.xml" rel="self" type="application/rss+xml" />
<atom:link rel="hub" href="http://pubsubhubbub.appspot.com" />
<description>ブログの説明を入力します。</description>
<language>ja</language>
<item>
<title>短いAI動画は「何を動かすか」で変わる｜Minimax H3 Maxで考える動画づくり</title>
<description>
<![CDATA[ <p>AIで動画を作ろうとすると、つい最初から完成した一本を作りたくなります。</p><p>人物を動かして、カメラを移動させて、背景にも変化を入れて、音も付ける。ところが短い動画では、要素を増やすほど良くなるとは限りません。むしろ「この数秒で何を見せたいのか」を一つ決めたほうが、プロンプトも整理しやすくなります。</p><p>最近、短い動画を考えるときに気になったのが <a href="https://h3-max.com/">Minimax H3 Max</a> です。</p><p>今回は機能を並べるのではなく、短いAI動画を作るときにどう考えると試行錯誤しやすいか、という視点で整理してみます。</p><h2>まず一つの変化だけを書く</h2><p>例えば、机の上に置かれた腕時計の商品イメージを作るとします。</p><p>最初のプロンプトから、</p><ul><li><p>時計が回転する</p></li><li><p>カメラがズームする</p></li><li><p>背景の照明が変わる</p></li><li><p>水滴が落ちる</p></li><li><p>音楽が盛り上がる</p></li></ul><p>と全部入れると、どの指示が結果に影響したのか分かりにくくなります。</p><p>最初はもっと単純で構いません。</p><p>「暗い机の上に腕時計が置かれている。カメラがゆっくり近づく」</p><p>まずこの程度で映像の土台を確認します。</p><p>次の生成で光を変える。その次に被写体の動きを追加する。このように一度に変更する項目を少なくすると、失敗したときにも原因を探しやすくなります。</p><h2>静止画があるなら、説明し直さない</h2><p>Image-to-Videoを使う場合も考え方は似ています。</p><p>すでに画像の中に商品、背景、構図があるなら、プロンプトでその画像を最初から文章化し直す必要はありません。</p><p>それより、</p><p>「カメラをどう動かすか」</p><p>「被写体のどこを動かすか」</p><p>「最後にどんな状態にしたいか」</p><p>を中心に書いたほうが、指示の役割が分かりやすくなります。</p><p>これはAI動画に限らず、短い映像を設計するときに便利な考え方だと思います。</p><h2>音も別のレイヤーとして考える</h2><p>映像と音を同時に考えられる場合でも、プロンプトを書く段階では分けてメモしておくと整理しやすくなります。</p><p>たとえば、</p><p>映像：雨上がりの夜、店の前をカメラが横切る<br>動き：ゆっくり右方向へ移動<br>音：弱い雨音、遠くを走る車</p><p>という具合です。</p><p>こうすると、映像がおかしいのか、動きがおかしいのか、それとも音の指定を変えるべきなのかを判断しやすくなります。</p><h2>完成品より「確認用の一場面」として使う</h2><p>個人的には、AI動画生成は最初から完成品を求めるより、アイデアを確認するための短い試作として考えるほうが扱いやすいと思います。</p><p>商品をどの角度から見せるか。</p><p>静止画にどの程度の動きを加えるか。</p><p>カメラを寄せるのか、引くのか。</p><p>音を入れることで場面の印象がどう変わるのか。</p><p>こうした小さな判断を短いクリップで確認して、良かったものだけ次の編集工程に持っていく。</p><p>Minimax H3 Maxのような動画生成ツールを試す場合も、「一本のすごい動画を作る」というより、この小さな検証を繰り返す使い方から始めると、結果を比較しやすくなります。</p><p>生成結果はプロンプトや入力素材、設定によって変わります。公開用途で利用する場合は、使用する画像・音声などの権利や、利用しているサービスの最新ルールも確認しておく必要があります。</p><p>短い動画だからこそ、全部を動かす必要はありません。</p><p>一つの場面、一つの動き、一つの音。</p><p>まずそこから試してみるくらいが、ちょうどいいと思います。</p>
]]>
</description>
<link>https://ameblo.jp/cy520569/entry-12978890326.html</link>
<pubDate>Wed, 16 Sep 2026 15:42:41 +0900</pubDate>
</item>
<item>
<title>AI動画を何本も作って気づいた「完成動画より残しておきたいもの」</title>
<description>
<![CDATA[ <p>最近、AIで短い動画を作ることが増えました。</p><p>最初の頃は、とても単純でした。</p><p>うまくできた動画は残す。</p><p>失敗した動画は削除する。</p><p>それだけです。</p><p>PCのフォルダも「OK」と「NG」に分けていました。</p><p>でも、ある日NGフォルダを整理していたときに、少しもったいないことをしていたことに気づきました。</p><p>その動画自体は確かに失敗でした。</p><p>途中から商品の形が少し変わってしまい、そのまま使えるものではありません。</p><p>ただ、最初の3秒だけを見ると、カメラの動きがすごく自然だったんです。</p><p>「あれ、ここは残しておいたほうがいいかも」</p><p>と思いました。</p><p>それから、AI動画を見る基準が少し変わりました。</p><h2>「使える・使えない」だけで見なくなった</h2><p>以前は動画全体を見て判断していました。</p><p>完成動画として使えるなら保存。</p><p>使えないなら削除。</p><p>でも最近は、もう少し細かく見ています。</p><p>たとえば8秒の動画なら、</p><p>最初の3秒は商品の形が安定している。</p><p>4秒目から少し崩れる。</p><p>カメラの動きは最後までいい。</p><p>光の感じも好き。</p><p>こんなふうに見ると、「失敗した動画」というより、「使える部分が残っている動画」に見えてきます。</p><p>もちろん全部を保存していたら大変なので、本当に何か残したいものがあるときだけ取っておきます。</p><h2>ファイル名も少し変えました</h2><p>以前のフォルダを見ると、</p><p><code inline="">final.mp4</code></p><p><code inline="">final2.mp4</code></p><p><code inline="">final_new.mp4</code></p><p>みたいな名前がたくさんあります。</p><p>数日後に見ると、もう何が違うのかわかりません（笑）。</p><p>今は少しだけ理由を入れるようにしています。</p><p><code inline="">good_camera.mp4</code></p><p><code inline="">good_light.mp4</code></p><p><code inline="">stable_first3sec.mp4</code></p><p>こんな感じです。</p><p>きれいな管理方法ではないですが、自分にはこれくらいがちょうどいいです。</p><p>「前にいいカメラの動きがあったな」と思ったとき、探しやすくなりました。</p><h2>失敗した場所を見るのも面白い</h2><p>もうひとつ最近見るようになったのが、</p><p>「どこからおかしくなったのか」</p><p>です。</p><p>最初から崩れている動画もあります。</p><p>でも、最初の4秒は安定していて、そのあと急に形が変わる動画もあります。</p><p>そういうときは、</p><p>「もっと細かくプロンプトを書こう」</p><p>と考える前に、</p><p>「そもそも8秒必要だったかな？」</p><p>と考えるようになりました。</p><p>4秒で成立するなら、無理に長くする必要はないかもしれません。</p><p>これは実際に失敗した動画を残していなかったら、あまり考えなかったことでした。</p><h2>新しいモデルを試すときにも役立った</h2><p>最近は同じ見方でいくつかのAI動画モデルを試しています。</p><p>その中のひとつが <a href="https://wan30ai.com/">Wan 3.0</a> でした。</p><p>以前なら一番きれいにできた動画だけを見ていたと思います。</p><p>今は、うまくいかなかった動画も一度は見直します。</p><p>商品の形はどこまで安定していたか。</p><p>カメラはどう動いたか。</p><p>どのあたりから違和感が出たか。</p><p>そうやって見ると、完成した一本だけを比べるより、そのモデルの特徴が少しわかりやすくなります。</p><h2>最近はすぐに削除しなくなりました</h2><p>もちろん、何も残したいところがない動画は削除します。</p><p>全部保存していたら、今度はファイルを探すだけで大変になります。</p><p>なので今の基準はかなり簡単です。</p><p>「この動画を残す理由を一言で言えるか？」</p><p>それだけ。</p><p>カメラがいい。</p><p>光がいい。</p><p>最初の3秒が安定している。</p><p>どれかひとつでもあれば、少し残しておきます。</p><p>AI動画を作り始めた頃は、成功した動画を増やすことばかり考えていました。</p><p>最近は逆に、失敗した動画を一度だけちゃんと見る時間が増えました。</p><p>意外と、その中に次の動画で使いたいヒントが残っています。</p>
]]>
</description>
<link>https://ameblo.jp/cy520569/entry-12978414074.html</link>
<pubDate>Fri, 11 Sep 2026 15:22:34 +0900</pubDate>
</item>
<item>
<title>AI動画を作っていて「長いプロンプト＝良い結果」ではないと感じた話</title>
<description>
<![CDATA[ <h1>最近、AI動画をいろいろ試しています。</h1><p>最初の頃は、</p><p>「プロンプトは詳しく書いた方がいい！」</p><p>と思っていました。</p><p>なので、カメラ、光、背景、動き、雰囲気、色……思いついたものをどんどん追加。</p><p>気がつくと、かなり長いプロンプトになっていました（笑）</p><p>でも何本も作っているうちに、</p><p><strong>長く書けば思い通りになるわけではない</strong></p><p>という当たり前のことに気づきました。</p><h2>指示を増やしたら、逆に何が原因かわからなくなった</h2><p>例えば、机の上に置いた商品を撮影するような短い動画。</p><p>最初はこんな感じで考えていました。</p><pre><code>A product on a modern desk,cinematic lighting,slow camera movement,dramatic reflections,warm atmosphere,camera orbit,soft shadows,premium commercial style...</code></pre><p>さらに思いつくたびに言葉を追加。</p><p>でも生成してみると、</p><p>「カメラ、思っていた動きと違う……」</p><p>ということがあります。</p><p>そこで問題になるのが、</p><p><strong>どの指示が効いて、どの指示が邪魔をしたのかわからない</strong></p><p>ことでした。</p><p>全部書き直すと、次の結果はさらに別物になります。</p><h2>最近は最初のPromptをかなりシンプルにしています</h2><p>今はまず、</p><p><strong>何を映すのか</strong></p><p><strong>何が動くのか</strong></p><p><strong>カメラはどう動くのか</strong></p><p>この3つくらいから始めています。</p><p>例えば、</p><pre><code>A small desk lamp on a wooden table.The lamp remains stationary.The camera slowly moves closer.</code></pre><p>まずこれで生成。</p><p>背景や雰囲気が必要なら、そのあと追加します。</p><pre><code>Soft morning light enters from the left.</code></pre><p>さらに必要なら、</p><pre><code>Minimal home office background.</code></pre><p>という感じ。</p><p>一度に完成形を目指すというより、</p><p><strong>一つずつ足していく</strong></p><p>ようになりました。</p><h2>「動かさない」も意外と大事でした</h2><p>もう一つ最近よく書くようになったのが、</p><pre><code>The object remains stationary.</code></pre><p>のような指示。</p><p>AI動画なので、つい「どう動かすか」ばかり考えてしまいます。</p><p>でも実際の映像では、全部が動く必要はありません。</p><p>商品は止まっていて、カメラだけが動く。</p><p>背景はほぼ変わらず、髪や服だけ少し風で動く。</p><p>こういう「動くもの」と「動かないもの」を分けて考えた方が、個人的にはPromptを整理しやすくなりました。</p><h2>カメラの指示も最初は一つだけ</h2><p>以前は、</p><pre><code>push in → orbit → tilt up</code></pre><p>のように、一つの動画にいろいろ入れたくなっていました。</p><p>今は最初のテストなら、</p><pre><code>Slow push-in.</code></pre><p>だけ。</p><p>または、</p><pre><code>Slow clockwise orbit.</code></pre><p>だけ。</p><p>まず一つの動きを試します。</p><p>上手くいかなかったときも、</p><p>「少なくとも今回はこのcamera instructionを見直せばいい」</p><p>と考えられるので楽です。</p><h2>新しいモデルでも同じやり方で試しています</h2><p>最近チェックしているAI動画モデルの一つが <a href="https://www.jxp.com/ltx/ltx-2-5">LTX 2.5</a> です。</p><p>新しいモデルを見ると、つい機能を全部試したくなるのですが（笑）、最近は逆に同じようなシンプルなPromptから始めるようにしています。</p><p>そうすると、</p><p>「モデルが変わったから違うのか」</p><p>「自分がPromptを変えすぎたから違うのか」</p><p>が少し分かりやすくなります。</p><p>もちろんAI動画なので、同じPromptでも毎回まったく同じ結果になるわけではありません。</p><p>それでも最初の条件をシンプルにしておくと、次に何を試すか決めやすいです。</p><h2>最近の自分用ルール</h2><p>今のところ、最初のテストではこんな順番にしています。</p><p><strong>① Subject</strong></p><p>何を映す？</p><p><strong>② Action</strong></p><p>何が動く？</p><p><strong>③ Camera</strong></p><p>カメラはどう動く？</p><p>ここまでで一度生成。</p><p>必要なら、</p><p><strong>④ Lighting</strong></p><p><strong>⑤ Environment</strong></p><p><strong>⑥ Style</strong></p><p>を追加。</p><p>最初から⑥まで全部書かないようにしています。</p><h2>Promptを「完成させてから生成」しなくなった</h2><p>以前は、Generateボタンを押す前にPromptを完成させようとしていました。</p><p>今は、</p><p><strong>Promptそのものも生成しながら作っていく</strong></p><p>くらいに考えています。</p><p>短いPromptで一度確認。</p><p>一つ追加して確認。</p><p>必要なければ削除。</p><p>この方が少し遠回りに見えて、結果的には「なぜこうなった？」と悩む時間が減りました。</p><p>AI動画のモデルはこれからもどんどん変わると思います。</p><p>でもモデルが変わっても、</p><p><strong>最初はシンプルにして、一つずつ試す</strong></p><p>という方法はしばらく使えそうです。</p><p>最近AI動画を触っている方は、Promptを最初から細かく書く派でしょうか？</p><p>それとも短いPromptから少しずつ調整する派でしょうか？🙂</p>
]]>
</description>
<link>https://ameblo.jp/cy520569/entry-12978047157.html</link>
<pubDate>Mon, 07 Sep 2026 18:04:50 +0900</pubDate>
</item>
</channel>
</rss>
