「あと10度だけ右から撮りたい」——生成AIの角度問題を3Dで解決した話
最近、動画制作でも生成AIを使う場面が本当に増えてきたなと感じています。クリエイターとしてはワクワク半分、悔しさ半分で、「使うかどうか」を結構長いこと迷っていました。でも、尻込みしていても何も発見がなさそうなので、HiggsField などの生成AIサイトに登録して実際に触ってみたんです。
そうしたら——「めちゃくちゃ使いにくくないですか？」
1シーン作るときのワークフロー
というのも、動画の1シーンを作るとき、僕がよく使うのが Kling 3.0 です。Kling 3.0 には、動画を生成するときに最初のフレームと最後のフレームを指定できる機能があって、生成結果が比較的想像しやすいのでよく使っています。そこはいいんです。
問題は、その「最初のフレーム」と「最後のフレーム」——この2枚を画像生成する部分なんです。
こんな感じで Start と End をインポートして生成すると、その中間を作ってくれます。もちろんテキストプロンプトも同時に使えます。
「あと少し角度を変えたいだけ」がうまくいかない
画像生成には、精度の面で気に入っている GPT Image 2 を使っています。でも、ある画像を生成したときに「どうしても角度が少しだけ違う。そこだけ直せれば完璧なのに……」という場面が連発するんです。
それで GPT に「中央の被写体を中心に、10度右にずらした視点から生成して」などとプロンプトするのですが、たいてい思っていたより大きくズレるか、逆にほとんど変わらない（ほぼ同じ）画像が返ってきます。そこからプロンプト改善 → 確認 → 改善 → 確認……を繰り返していると、気づけば1カットに2時間。こんなことが個人的にはザラにあります。
そもそも、空間操作を「言葉」でやるのが間違いなのでは
でも、よく考えれば当たり前の話かもしれません。画像生成モデルは、Nano Banana を皮切りに差分生成ができるようになったり、文字に強くなったりと進化が凄まじいです。ですが結局のところ、空間的な細かい操作を言葉でやろうとすること自体が間違いなんだと思います。
誰が見てもわかる変化や、写っているもの自体の操作なら、言葉で指示するのは間違いなくアリです。でも、「ほんの少しズレた視点」や「今の視点からまっすぐ15m進んだ視点」を生成させるのに言葉を使うのは、いい道具の使い方には見えません。ほんの少しの操作に対して、言語化すべき内容が指数関数的に増えていく。まさに「百聞は一見にしかず」のいい例だと思うんです。
思い出した技術——Apple SHARP
そんな疑問を持ちながら、思った視点がなかなか生成できずにいたとき、思い出したのが Apple SHARP という技術でした。半年ほど前に Apple から出たオープンソースモデルで、単一の画像から Gaussian Splatting で構成された3D空間を生成するモデルです。
iOS 26 から、普通の写真でも iPhone の写真アプリで空間写真にできたり、ロック画面が端末の角度に応じて3D的に変化したりする機能が追加されたと思うのですが、あれに使われている技術です。
すごいのは、予測精度と、CUDA なしでも（推論に関しては）動作するところ。僕の端末は MacBook なので、CUDA 前提のモデルはそもそも動かないか、膨大な推論時間をかけるかのどちらかになります。これは使えそうだとわかったので、すぐに Claude Code に実装してもらいました。
実装は0からではなく、すでに軽く GUI が作られている以下のリポジトリを参考にしています。(参考にしたリポジトリー)
つぶ感と暗点をどう埋めるか → 拡散モデル！
SHARP で Gaussian にしたものをスクショして使うこともできるにはできるのですが、それだとどうしても「つぶ感」が出てしまって、個人的なレベルにはマッチしませんでした。さらに角度を変えると、Gaussian が存在しない暗点が出ることがある。この部分をうまく埋めながらレンダリングできないかと悩んでいて——拡散モデルの考え方が、このレンダリングにめちゃくちゃマッチするのでは、という結論に至りました。
拡散モデルは、簡単に言えば「ノイズだらけの画像から綺麗な画像を生成する過程」を学習したモデルです。今回もまさに同じですよね。部分的に暗点（ノイズ）が含まれた画像を、より綺麗な画像へ修正するモデルなわけです。
ちなみに、GPT Image 2 で修正しようとも思ったのですが、純粋な拡散モデルだけに収まらなくなっている（性能が上がりすぎ、あるいは一般ユーザー向けに改良されすぎている？）せいか、まったくうまくいきませんでした。
レンダリングの清書に Difix を採用
このアイデアを Claude に相談すると、Difix というモデルが今回の用途に合うことがわかり、レンダリングの「清書」として Difix を採用しました。（もちろん Mac で動きます）
以上の実装計画を Claude Code に伝えて、お昼ごはんを食べること約1時間。アプリケーションが完成しました。
実際に動かしてみた
例えばこの画像。僕の部屋なのですが——
この画像をインプットとし、Sharpを実行。
おお！！結構よくできていませんか？？
さすがに上の画像の角度でレンダリングすると破綻が大きすぎるので、少しの変化を加えた画像をレンダリングしてみました。↓こんな感じです。
画像の端の部分は破綻がありますが、中央部分は、素晴らしい出来です！
自分で撮った画像と、生成した画像をHiggsFieldに入れれば、、、
完璧、、とは言いずらいですが、修正は簡単そうです。
まとめと、これから
こんなふうに、言語でひたすらトライアンドエラーを繰り返すより、言葉で表現できないものについては3Dを生成して、調節して、画像にするのが一番だと思います。
今後は、大きな視点変化も言葉で伝えるのが難しい場面があるので、そこにも対応させようと考えています。具体的には、いまは2D画像の修正に使っている Difix を、3Dの修正に使います。以下の研究を見てもらえればと思います。（ちなみに Claude Code で少し実装してみたのですが、Mac のメモリ16GBがまったく足りず、現状は断念しています）
研究を見る
このような開発を行っていると、いやでもVRAMをたくさん積んだデスクトップが欲しくなりますね。メモリ、、高い、、、、
