テキストから3Dシーンへ：一つの説明がロケーション全体になるまで

テキストから3Dを作るツールに「赤いスポーツカー」と入力すれば、赤いスポーツカーが出てきます。「夕暮れの小さな海辺の町、港と丘へ登る道つき」と入力すると、たいていのツールは建物らしきものをぼんやり示すだけの塊を返してきます。この二つの結果の差はモデルの品質の問題ではありません。まったく別の問題なのです。

同じ名前で呼ばれる二つの問題

オブジェクト生成は再構成のタスクです。モデルは膨大な数の椅子や車を見てきていて、あらゆる角度からの見え方について強い事前知識を持っています。その仕事は、テクスチャをまとった一貫した形を一つ出すこと。数秒のGPU時間、メッシュ一つ、これで終わりです。

シーン生成は構成のタスクです。町は一つの形ではなく、特定の配置に置かれた数百の形であり、さらにその配置を町として読ませる規則が要ります。道路は互いを貫通せず交差点で出会うこと。建物が通りを向いていること。歩道が縁石に沿うこと。街灯がもっともらしい間隔で並ぶこと。空と太陽の角度が影と一致していること。このほとんどはジオメトリではありません。ジオメトリについての判断です。

これを一つの生成モデルに一度でやらせるのは、相互に依存する数百の判断を一回の順伝播で抱えろと言っているのと同じです。出力が溶けたように見えるのはそのためです。

シーンに必要で、オブジェクトには不要なもの

ジオメトリより先に配置計画

説得力のある環境はどれもメッシュではなく計画から始まります。幹線道路はどこを通るのか。それは地面をどんな街区に切り分けるのか。そのうちどれが住宅でどれが商業なのか。先に配置を決めてからジオメトリを流し込むツールは、歩ける場所を作ります。先にジオメトリを生成して配置が現れるのを期待するツールは、作りません。

数百のパーツにわたる一貫性

オブジェクトが四百個になると、一貫性は「あると良いもの」ではなくなります。すべての建物が同じ階高の約束に従っていなければ、屋根のラインが酔っ払って見えます。すべての縁石が同じ断面でなければ、通りは壊れて読めます。すべてのマテリアルが同じ小さなパレットから来ていなければ、町はサンプル集のように見えます。人間はキットとスタイルガイドでこれを守ります。ソフトウェアは制約で守るしかありません。

エンジンへのインポートに耐えるスケール

生成されたオブジェクトはどんなサイズでも構いません。読み込むときに拡大縮小すれば済みます。生成されたロケーションはそうはいきません。扉が1.6mで歩道が幅8mなら、キャラクターコントローラーの感触は間違ったままで、どれだけスケールしても直りません。誤差は単位ではなく比率にあるからです。シーンは最初から実寸のメートルで組む必要があります。

テキストからシーンを作る三つの方法

シーン全体を一つのメッシュに

いちばん単純な方法は、ロケーションを一つの巨大なオブジェクトとして扱い、オブジェクト生成器に渡すことです。速いし、遠目のデモ映えもします。しかし中に入った瞬間に破綻します。分離できるオブジェクトがなく、再利用できるマテリアルもなく、まともなコリジョンもなく、三角形の予算は見えないものに費やされています。背景としては使えます。レベルとしては使えません。

検索と配置

ライブラリからアセットを引いてきて、プロシージャルに配置する方法です。多くの「AI都市ジェネレーター」がこれをやっていて、実際その範囲ではよくできています。個々のパーツは人が作ったものなので綺麗ですし、配置ルールが全体の破綻を防ぎます。限界はライブラリです。ライブラリにないものを頼めば最も近いものが返ってくる。地中海の漁村がアメリカ郊外の住宅で組み上がるのはこのためです。

本物のエディタを動かすエージェント

三つ目の方法は、レベルデザイナーが使うのと同じ道具をAIエージェントに渡します。道路網を引く、街区を分割する、指定した寸法とファサードの建物を置く、ポリゴンの内側に木を散らす、太陽をこの角度にする。そして段階を踏んで作業させます。各ステップのあとにシーンを読み返して自分を修正する。ビューポートと計画図を行き来する人間とまったく同じやり方です。

一度きりの生成より時間はかかりますし、下にウェブフォームではなく本物のエディタが必要です。その代わり、できあがるものはすべて選択・移動・削除・書き出しができる実体のあるオブジェクトで、推論はあなたが見ていられて、いつでも止められる場所で起こります。Cuberta はこの考え方を土台にしています。エディタはロケーション単位の道具を Model Context Protocol で公開していて、Claude Code をはじめ、どのMCPクライアントからでも操作できます。

シーン向けツールに確認すべきこと

一つだけ選択できますか。出力が単一のメッシュなら、それはロケーションではなく絵です。
単位はメートルですか。4mの扉を頼んで、測ってみてください。
道路は本当につながっていますか。交差点はジェネレーターが最初に破綻する場所です。スカイラインより先に見てください。
途中で方向を変えられますか。一つの指示を受け取って一つの結果を返すだけの道具はスロットマシンです。
最後に何が出てきますか。テクスチャ込みのGLBかFBXか、それとも独自形式とサブスクリプションか。

実際に効くプロンプト

どのツールを使うにせよ、シーンのプロンプトはオブジェクトのプロンプトとは振る舞いが違います。オブジェクトは形容詞に応えます。シーンは構造に応えます。雰囲気を積み上げるより、都市計画をする人のように場所を書いてください。

建物およそ60棟の海辺の町。幹線道路が一本、海岸沿いに走る。もう一本が丘を登り、T字路で幹線と出会う。海岸道路沿いは瓦屋根の二階建て石造住宅、丘の上はより大きな戸建て。北端に石造の桟橋を持つ港。幹線道路の両側に歩道、街灯は25mおき。午後遅い日射し、西から低く。

数量、素材、道路のトポロジー、光の向き。どの一文も検証できます。つまり何かが違って出てきたとき、プロンプト全体を書き直して運を天に任せる代わりに、無視された一文を指させるということです。

この先どうなるか

この一年で本当に興味深かった変化は、モデルがメッシュを上手く作れるようになったことではありません。それは着実に、しかし平凡に進みました。変化は、生成が一発勝負でなくなったことです。自分が組んだものを見て、二本の道がつながっていないと気づき、その道を直しに戻れるエージェントは、単発の生成器には構造的にできないことをしています。「テキストから3Dシーン」を宝くじから対話に変える。そして対話なら舵を取れます。

同時にそれが正直な限界でもあります。数秒ではなく数分かかります。手元のマシンで本物のエディタを開いておく必要があります。そして「この丘は急すぎる」と言える、趣味のいい誰かが依然として要ります。レベルデザイナーと働いたことがあるなら、そこはまさに残しておきたかった部分のはずです。