Klingが値上げした日 ― 外部AIモデルに依存したパイプラインの維持（Veo / Seedance移行記）

2026年8月4日の夕方、私はYouTubeチャンネル「歴史の雨音」の制作パイプライン（全体像はこちら）で使っていたKling AIの料金ページを開いて、目を疑いました。それまで使っていたトライアルのリソースパッケージ——直近は1,500ユニット・3ヶ月で150.15ドル（税込）——の系譜が、なくなっている。残っているのは、最低700ドルのプランだけでした。

雨音は収益のないチャンネルです。しかも当時の請求書と管理画面を突き合わせると、初回の1ヶ月パッケージ（1,000ユニット・98ドル）は40.5%、この3ヶ月パッケージにいたっては期限までに20%しか消化できていませんでした。もともと使い切れない量を買っていたところに最低700ドルとなると、気軽に制作を続けられる金額ではありません。その日のうちにGoogle Veo 3.1への移行調査を始め、同日中に移行を完了し、しかし2日後には別の問題でSeedanceを評価し始め、4日間で動画エンジンを2回乗り換えることになりました。

この記事はその移行記です。ただ、書きたいのは「どのモデルが良いか」ではありません。移行のたびに思い知らされた、もっと一般的な事実——プロンプトは仕様書ではなく、特定のモデルの癖に対するキャリブレーションであり、モデルを替えると全く適合しなくなる——という話です。

移行①：Kling → Veo（所要1日）

Veoの料金体系を調べてみると、調査の結果はむしろ朗報でした。

	Kling	Veo 3.1 Lite
実効単価	$0.112/秒（v3-omni pro 1080p）	$0.08/秒
生成時間	6〜15分	91秒
出力解像度	1076×1924（なぜか半端）	きっかり1080×1920

Veoを使うにあたって私が一番心配していたのは価格ではなく、カメラの動きでした。このチャンネルの動画は「固定視点で、ほとんど何も動かない」ことが生命線で、Klingにカメラを止めさせるために数ヶ月分の試行錯誤をプロンプトに焼き込んであったからです（ズームするな、パンするな、スライドするな、ドリフトするな……という悪魔祓いのような否定の列挙。それでも「カメラは止まったが、今度は軒先が溶け始めた」というような日々でした）。

Veoには last_frame というAPIパラメータがありました。クリップの最終フレームを開始画像と同じ静止画にピン留めする。数ヶ月分の呪文が、1個の関数引数になった。 同じ静止画・同じプロンプトで計測したカメラドリフトは192フレームで0.00ピクセル。カメラは動いていません。

移行はその日のうちに完了しました。これで一件落着、と行けばよかったのですが。。

数時間後に発覚した、予想しなかった劣化

移行当日のうちに、生成された動画を見て気づきました。シーンの中の鍋から立つ湯気が、止まっている。Klingは頼まなくても湯気や炎や蝋燭の揺らぎを自然にアニメーションしてくれていたのに、Veoは雨と猫にしかアニメーションを付けず、湯気を完全に無視しました。

調べて分かったのは、この2つのモデルの根本的な性格の違いでした。

Veoはプロンプトに列挙されたものだけを動かす。 Klingはもっともらしい環境の動き（湯気・炎・揺らぎ）を自分で推測して付ける。

そしてここに罠がありました。私のプロンプトには Nothing else moves.（それ以外は何も動かない）という一文が入っています。これはKling時代に「勝手な動きを発明するな」という意味で書いた安全装置です。ところがVeoの下では、同じ一文が**「湯気や炎があっても凍結しろ」という意味で解釈されていました**。

プロンプトは1文字も変わっていないのに、意味が変わったのです。 湯気を明示的に列挙すると、その領域の動きは4.1倍になりました。以降、プロンプトには「動くべきものの列挙表」（湯気・煙・炎・霧はそれぞれ名指しする）と、「風で動いてしまいそうなもの（暖簾・洗濯物）は名指しで静止させる」というルールが必要になりました。Klingでは何も言わなければよしなにやってくれ、Veoでは動くものと止まるものを全部言わなければならない。体感的にこのような違いがわかりました。

そしてVeoの雨が破綻した

8月6日、長尺パイプラインもVeoに移して30分動画を作ったところで、より深刻な問題が出ました。雨の線が、落ちてこない。 静止画に描かれた雨の線の一部がアニメーションされず、ガラスに雨が張り付いているように見える現象が起きてしまいました。上がり框（かまち）の向こうがびっちりガラスに覆われているような動画が生成されました。プロンプトをどうチューニングしてもこの“停止した雨の線”の問題は解決できませんでした。

雨が全製品のチャンネルで、雨が描けないとなるとこれは致命傷です。

移行②：Seedance ― 拒否からの逆転

次の候補はByteDanceのSeedanceでした。ここで私が最初に調べたのは品質ではなく、利用規約です。生成物の権利がどこに帰属するか、問題が起きたときの補償条項がどうなっているかは、単価より先に確認すべき項目だと考えているからです。

このとき学んだことがひとつあります。私たちのパイプラインは画像生成と動画生成で別々のモデルを使う2段構成ですが、片方の段にしか掛かっていない補償は、成果物には掛かっていない。成果物は1個の派生物なのだから。補償条項を読むときは「工程単位」ではなく「成果物単位」で考える必要がある——これは複数モデルを組み合わせるすべてのパイプラインに重要となる規約の読み方だと思います。

規約を確認した上で、10ドルだけチャージして試した最初の生成結果を見て、私は当時プロンプトの記述を依頼していたAI エージェントにこう書いています。

道の下から水が噴水のように湧き上がるアニメーションが入っていたので、実際これではつかえません。

その「噴水」の実物がこちらです。鍛冶場の前の道から、水が爆裂して噴き出す。ぼーっと見ていたこちらも吹き出してしまいました。

落胆、、から2時間後

内容は完璧です。seedanceを規定エンジンにしたいです。

プロンプトを直していくこと2時間、突然生成の品質が桁違いに良くなりました。プロンプトを変えながら試すうちに、SeedanceはKlingと同じプロンプトを渡しても、その受け取り方の概念が全く違うらしいということが分かってきました。 そこで、Klingの癖に合わせて埋め込んできた記述をSeedance向けに大幅に組み替えて再生成したところ、道から水が湧き上がることはなくなっていました。 一度は「無理だな、、」を却下しかけたモデルを、2時間後には既定エンジンにしていました。 50ドルのリソースパッケージを追加して、両パイプラインをSeedanceに切り替えました。

水との戦い

Seedanceの残る問題はひとつでした。動画生成モデルが、あらゆる水平面を水だと信じている。

8月7日の夕方から夜にかけての私とAIエージェントのやり取りのログを並べると、

17:35 路上に不自然な強い水しぶきがあたっています。炎はいいのですが、

17:57 Cは炎はいいのですが、道路に水面のような波紋がひろがってしまいます。道路を水面だと勘違いしたようなアニメーションです。

19:29 猫の動きは本当に仄かな呼吸の動きでリアルです。Veoより良いです。ただ、外の石畳の通りが水面であるかのような大きな波紋が1つ立っていて、これが問題です。

19:36 石畳のあたりは改善されました…ただ、なぜか猫のすぐ手前の床に水の流れが追加されてしまいました。

波紋を小さく、少なく、別の場所に——と4ラウンド制約を書き換えても、水は消えませんでした。そして19:42、私はようやく正しい問いにたどり着きます。

もうここまでいくとRippleをそもそも指定しないほうがいいのでしょうか

その通りでした。6分後のログはこうです。

19:48 ものすごく自然になりました。完璧なアニメーションです。正直、レベルの高さに驚いています。これは大きな発見ですね。

その19:48のシーンがこれです。19:29に「猫のすぐ手前の床」、19:36に「石畳のあたり」と言っていた、まさにその床とその石畳から、水は消えました。

現象を抑制するために名指しすることが、その現象を召喚する。 「濡れた石畳にかすかな波紋」という文は、モデルにとっては波紋のリクエストです。形容詞の影響はほとんどなく、名詞のほうがずっと重く受け止められているのがわかりました。波紋を出さない唯一の確実な方法は、その単語を書かないことでした。

面白いのは、これがカメラ制御のルールと正反対だということです。

• カメラの動き：禁止したい動きを全部列挙する（no zoom, no push-in, no pan…）。否定は効く。
• 水：絶対に言及しない。否定は召喚する。

なぜかは誰にも分かりません。どちらも経験則で、どちらも今、プロンプト生成スキルに焼き込まれて本番を支えています。生成AIの実務の最前線というのは、正直に書けばこういう状態です。

ひとつ後日談を。この週に「Seedanceには短く書け」という教訓を抽出したのですが、これは正しいデータから引いた間違った一般化でした。数日後、最小限のプロンプトで作ったシーンが「波紋と水しぶきのオンパレード」になりました。本当のルールのシュガースポットはもっと狭くて、「水を名指しするな」だけでした。極端に短くしたプロンプトは水を抑制せずモデルに水を発明する自由を与えてしまいました。1軒の茶室の雨に5テイクをかけて、それが分かりました。

この話の意味 ― パイプラインは「完成」しない

まとめると、この4日間で起きたことはこうです。

1. 外部要因（料金プラン変更）でエンジン移行を強制された
2. 移行先で、プロンプトの意味が変わった（Nothing else moves. が安全装置からバグになった）
3. 品質問題で再移行し、また別のキャリブレーション（水の禁句）を発見し直した

生成AIモデルをパイプラインに組み込むということは、動き続ける床の上に建物を建てるということです。モデルの価格は変わり、ティアは消え、挙動はバージョンごとに変わっていきます。そして自分のプロンプト資産は、特定モデルの癖への補正の集積なので、モデルと一緒に無効になってしまいます。

それでもこのパイプラインは、値上げの発覚から4日で2回の移行を乗り切り、翌週には何事もなかったかのように生産を再開していました。それができたのは、パイプラインの各段が疎結合で、プロンプトが「スキル」として一箇所に集約されていて、そして変化を検知して対処する人間とAIエージェントのループが回っていたからです。

この種のシステムは、作って納品して終わり、にはなりません。外部モデルの変化に合わせて維持し続けるものです。だからこそ、AIエージェントや生成AIをプロダクトに組み込むときは、AIエージェントに精通したエンジニアと長期的にプロジェクトを進めることが重要だと、自分たちの実体験から考えています。お気軽にご相談ください。