Simon WillisonはBlenderをCodexで操作したが、レンダリングは物語の半分にすぎない
Simon Willisonは、アプリケーションの視覚インターフェースを一度も操作することなく、1つのプロンプトから2分39秒で編集可能なBlenderシーンを作り上げた。彼のコーディングエージェントはPythonを生成し、macOS上でBlenderを起動し、自転車に乗るペリカンを構築して、結果をネイティブの.blendファイルとして保存した。
この違いは重要だ。編集が難しい平坦な画像を生成する、また別のテキスト画像生成システムではない。エージェントはプログラム可能なクリエイティブアプリケーションを操作し、人が確認、編集、再レンダリング、アニメーション化できるソースコードと構造化された3Dオブジェクトを残した。
この実験は、コーディングエージェントをめぐる本当の競争も浮き彫りにした。重要な境界線は、もはやコードを書くこととビジュアルメディアを作ることの間にはない。信頼できるプログラム可能な操作手段を公開するソフトウェアと、手作業によるインターフェース操作に閉じ込められたままのソフトウェアの間にある。
Willisonの例は、簡潔で遊び心があり、1人のユーザーの経験に基づくものだ。統制されたベンチマークではない。しかし、あらゆるアプリケーション開発者による専用統合を待たずに、エージェントがコードリポジトリの外へ活動範囲を広げられる可能性を示す有用な先触れとなっている。
Simon WillisonはBlenderをコーディングエージェントの対象にした
注目すべき出来事はペリカンの画像ではない。Codexが、インストール済みのデスクトップアプリケーションを実行可能な開発ツールとして扱ったことだ。
9月5日の投稿で、Simon WillisonはMac上のChatGPT Codexを使ってBlenderを操作したと説明した。最初の依頼は直接的だった。インストール済みのBlenderアプリケーションを使い、自転車に乗るペリカンをレンダリングするというものだ。
エージェントは、Blenderのコマンドライン実行ファイルとPythonインターフェースを通じた経路を見つけた。Willisonは後に、通常のインターフェースを開かずにBlenderを起動してスクリプトを実行する、より明示的なコマンド/Applications/Blender.app/Contents/MacOS/Blender --background --python scene.pyを提示した。
バックグラウンドモードでは、Blenderはグラフィカルワークスペースを開かずに動作する。そのため、自動レンダリング、サーバージョブ、テストパイプライン、エージェント制御タスクに適している。
Willisonによれば、最初のプロンプトは2分39秒後に.blendプロジェクトとPythonスクリプトを生成した。その後、「背景とたっぷりの華やかさ」を加えるよう依頼し、3分51秒後に別バージョンを受け取った。
作品を「もっとずっと良くする」最終依頼には5分59秒かかった。完成した海岸パレードのシーンには、遊歩道、海、夕日、ビーチキャビン、ヤシの木、花、そしてより精細なペリカンが含まれていた。
一連の流れ、プロンプト、出力ファイル、所要時間はWillisonのBlender experimentに掲載されている。この公開記録により、この例は制作履歴なしに投稿された洗練された画像よりも多くの情報を提供する。
生成されたファイルは、エージェントが実際に何をしたのかも示している。隠れた画像生成器を呼び出して、その結果をBlenderに貼り付けたわけではない。オブジェクト、マテリアル、カメラ、ライト、ジオメトリ、レンダリング設定、プロジェクトデータにアクセスするBlenderのPythonモジュールbpyを通じて、シーン構築の指示を書いたのだ。
Willisonは最終スクリプトを公開しており、最終改訂版は128行で構成されている。scene sourceは、自転車、鳥、遊歩道の板、雲、ビーチキャビン、ヨット、編みかごといった個々の要素を作成・変更している。
この証拠は主張の範囲を限定する。この実験が示すのは、1つのコーディングエージェント、1つのモデル構成、1つのローカルBlenderインストール環境が、特定の様式化されたシーンを完成させたことだ。任意の3D作業における一般的な信頼性を立証するものではない。
それでも、このワークフローは重要な境界を越えた。対話的な指示がコードになり、そのコードが成熟したデスクトップアプリケーションを制御し、アプリケーションが編集可能なプロジェクトと最終レンダリングの両方を生み出した。
macOS上のBlenderがこの瞬間を迎える準備ができていた理由
Blenderはすでに自動化の基盤を備えており、コーディングエージェントは翻訳、反復、実行を担った。
コーディングエージェントは、システムを調査し、小さなプログラムを書き、それを実行し、観測可能な結果を評価できる場合に最も力を発揮する。Blenderは、特別なエージェントプラグインを必要とせずに、このループの各要素を支えている。
BlenderのPython APIは、シーンオブジェクトをプログラム可能なデータとして公開している。スクリプトにより、メッシュの作成、座標の調整、マテリアルの割り当て、カメラの配置、ライトの設定、プロジェクトファイルの保存、レンダリングの開始が可能になる。
このアプリケーションはmacOS上でコマンドライン引数も受け付ける。完全なデスクトップアプリケーションがインストールされると、その内部実行ファイルはターミナルから実行できる。したがって、コーディングエージェントにとってBlenderは、ローカルマシン上で利用可能なもう1つのツールとして扱われる。
これは統合の問題を変える。開発者は、限られた自然言語コマンドをインターフェース操作へ変換する専用の「Blender connector」を待つ必要がない。その代わり、エージェントはテクニカルアーティストがすでに利用しているスクリプト機構とコマンドライン機構を使える。
このアプローチは、ローカル環境でCodexが機能する仕組みに合致している。Codex documentationによれば、エージェントはユーザーから付与された権限の範囲内で、ファイルの調査、ターミナルの利用、コード編集、コマンド実行を行える。
Blenderはアプリケーション層で決定論的な実行を担う。言語モデルは、意図をPythonへ変換する不完全ながら柔軟なプランナーを担う。どちらのコンポーネントも、単独ではワークフロー全体を提供しない。
現在のコーディングエージェントは、単純なオートコンプリートシステムよりも長い一連の処理を維持できるため、このタイミングは重要だ。スクリプトを作成し、実行し、エラーに気付き、ファイルを修正し、プロジェクトの状態を保持しながらそのプロセスを繰り返せる。
従来のチャットボットなら、ユーザーがコピー、デバッグ、手動実行しなければならないBlender Pythonのサンプルを出力するかもしれない。エージェントは、同じ作業セッション内でそれらの手順を処理することで、この実行上の隔たりを埋められる。
視覚的な出力は、エージェントとユーザーに具体的な確認地点も与える。レンダリングは、生成されたスクリプト内のすべての座標を読むよりも速く、フレーミングの誤り、欠落したジオメトリ、不十分な照明、過密な構図を明らかにできる。
ただし、視覚的なフィードバックが視覚的な判断を保証するわけではない。エージェントはレンダリングには成功しても、不自然な解剖学、一貫しないスケール、オブジェクトの交差、弱い構図を含む画像を作る可能性がある。実行の成功と芸術的な成功は、依然として別の基準だ。
だからこそローカルアプリケーションが重要になる。Blenderは、初期生成後も編集可能なジオメトリとマテリアルを保持する。人間のアーティストは、モデルに不透明な画像をゼロから再生成させるのではなく、欠陥を直接修正できる。
多くのクリエイティブタスクでは、印象的な最初の結果よりも編集可能性の方が価値がある。チームは承認済みの要素を残し、誤りを切り分け、作業が必要な部分だけを変更できる。
本当の競争はAPI対インターフェース自動化にある
Willisonの実験は、クリックの模倣に依存するワークフローよりも、スクリプト可能な内部モデルを持つアプリケーションに有利だ。
コンピュータ操作エージェントは通常、スクリーンショットを解釈し、マウスやキーボードを制御してソフトウェアを操作する。この経路は、ほぼすべてのデスクトップアプリケーションにインターフェースがあるため、幅広い互換性を提供する。
一方で、不確実性も持ち込む。ボタンは移動し、ダイアログが手順を中断し、ウィンドウのフォーカスは変化する。そしてエージェントは、ピクセルから状態を推測しなければならない。クリックを1回逃すだけで、ワークフロー全体が静かに別の方向へ進む可能性がある。
BlenderのPython APIは、その曖昧さの多くを回避する。エージェントは、名前付きの操作を通じてオブジェクト、カメラ、マテリアル、レンダリング設定に直接アクセスできる。結果として得られるスクリプトは、その行動を検証可能な形で記録する。
これは完全な決定論ではない。生成されたコードには無効な呼び出し、不適切なパラメータ、論理エラーが含まれうる。BlenderのバージョンによってAPIの挙動が変わることもある。
それでも、コードの失敗は通常、インターフェース操作の失敗よりも優れた証拠を残す。ユーザーはスクリプトを保持し、例外を調べ、改訂版を比較し、同じコマンドを再実行できる。
.blendファイルは、もう1層の検証可能性を加える。最終ピクセルだけでなく、構造化されたシーンそのものを含むからだ。ユーザーはプロジェクトを開き、エージェントが作成したものを調べられる。
Willisonの最終スクリプトは、その構造を例示している。遊歩道の板をプログラムで配置し、ヤシの葉を構築し、泡のラインを生成し、個別のかごの要素を追加している。これらは単一の結合された画像ではなく、個別に操作可能なコンポーネントだ。
これは、反復的なプロンプトに実用上の利点をもたらす。「背景を追加して」と言えば、自転車とペリカンを捨てずに既存のシーンを変更できる。「もっと良くして」と言えば、以前の作業を保持しながら選択したコンポーネントを洗練できる。
弱点は、曖昧な言葉が依然としてモデルに暗黙のデザイン選択を強いることだ。「良くする」は、より多くのディテール、より明確な構図、より高いリアリズム、あるいは単に装飾的なオブジェクトの追加を意味するかもしれない。
Willisonの結果は、洗練された玩具のような海岸イラストへと傾いた。別のユーザーなら、物理的なリアリズムや簡潔なエディトリアルスタイルを求めたかもしれない。エージェントは、明示されていないすべての好みを確実に推測することはできない。
これは、クリエイティブソフトウェアベンダーに新たな責任を生む。文書化されたスクリプト機能、安定したファイル形式、ヘッドレス実行を備える製品は、エージェントにとって操作しやすく、ユーザーにとっても監査しやすい。
視覚的なコントロールしか公開していないアプリケーションでは、エージェントは人間の操作を脆弱な形で模倣することになる。構造化されたコマンドを公開するアプリケーションでは、エージェントはプログラムの基底状態により近いところで作業できる。
Blenderは、ビジュアル編集、Python自動化、レンダリング、アニメーション、ネイティブプロジェクトファイルを組み合わせているため、特に有利な位置にある。この組み合わせにより、Blenderは制作ツールであると同時に実行環境にもなる。
同じ原則は3Dグラフィックスの外にも及ぶ。ビデオエディター、デザインアプリケーション、データツール、デジタルオーディオワークステーションは、コードを通じてプロジェクトを作成・変更できるようになるほど、より優れたエージェントの対象となる。
これはグラフィカルインターフェースを時代遅れにするものではない。その役割を変える。エージェントが反復的な構築を担い、インターフェースは人が結果をレビューし、修正し、アートディレクションを行う場所であり続ける。
ペリカンのレンダリングが証明していないこと
成功したデモンストレーションが示すのはワークフローの実現可能性であり、信頼できるクリエイティブ制作ではない。
Willisonが示したのは、ベンチマークではなく個人的な実験だった。反復試行、独立した評価者、統制されたプロンプト、モデルやBlenderバージョン間の比較は行われていない。
報告された所要時間は有用な観察結果だが、一般化された性能値にすべきではない。レンダリング時間は、Mac、シーンの複雑さ、レンダーエンジン、解像度、エージェントの試行回数に左右される。
この例は、寛容な題材であることからも恩恵を受けている。自転車に乗る様式化されたペリカンは、誇張された解剖学や遊び心のある比率にも耐えられる。建築ビジュアライゼーション、製品デザイン、医療アニメーション、エンジニアリング作業では、はるかに厳しい精度要件が課される。
シーンは説得力のある見た目でも、技術的には不十分な場合がある。メッシュトポロジーは編集しにくいかもしれない。マテリアルは異なる照明下で一貫して振る舞わない可能性がある。選択したカメラアングルの外では、オブジェクトが交差していることもありうる。
また、このエージェントがアニメーション、リアルタイムレンダリング、下流のエクスポートに向けてジオメトリを最適化した証拠もここにはない。静止画は、1つの視点と1つの瞬間からしかシーンを検証しない。
最終スクリプトでは、多数の視覚要素を手続き的に構築している。これによりユーザーは追跡可能な成果物を得られるが、生成された手続きコードは、明確に整理されていなければ保守が難しくなり得る。
プロンプトを重ねることで、この問題はさらに深刻になる。エージェントは不安定な基盤を再設計する代わりに、新たな操作を継ぎ足していくかもしれない。プロジェクトは見た目こそ改善しても、内部構造はより脆くなる可能性がある。
セキュリティにも同等の注意が必要だ。Blenderを実行できるコーディングエージェントは、その環境で利用可能な権限を使って、生成されたPythonも実行できる。ユーザーは未知のスクリプトを確認し、機密ファイルへのアクセスを制限すべきである。
リスクはBlenderの実行ファイルそのものではない。何を読み込み、書き込み、ダウンロードし、起動するのかを理解しないまま、生成コードに広範なアクセス権を与えることがリスクとなる。
ローカルエージェントは、ホスト型の画像生成ツールよりも複雑な信頼境界を生み出す。プロジェクトディレクトリ、参照画像、スクリプト、レンダリング出力、同じコンピューター上の他のリソースにアクセスできる場合がある。
チームには、エージェントが利用できるディレクトリと、承認を必要とするコマンドについて明示的なルールが必要だ。クリエイティブプロジェクトに未公開デザインや顧客資料が含まれる場合、こうした制御はさらに重要になる。
ライセンスは別の懸念をもたらす。BlenderはGNU General Public Licenseの下で配布されている一方、芸術的な出力物は通常、制作者の所有物として残る。Blender licenseは、生成コード、学習データ、第三者アセット、模倣されたスタイルに関わる権利問題を解決するものではない。
ユーザーは引き続き、テクスチャ、モデル、参照画像、その他の入力の来歴を追跡しなければならない。編集可能な出力はフラット化された画像よりも検証しやすいが、編集可能であることがクリーンな来歴を保証するわけではない。
したがって、品質管理は依然として人間の仕事である。経験豊富なアーティストなら、一般的なコーディングエージェントが見落とし得る解剖学、構図、照明、制作上の欠陥を見抜ける。
最も妥当な解釈は控えめなものだ。このテストは、コーディングエージェントが実際のクリエイティブアプリケーションを統括し、有用な出発点を生み出せることを示している。クリエイティブディレクションが自動化されたことを示すものではない。
コーディングエージェントが得るのは画像生成以上のもの
より大きな変化は、単一のビジュアルアセットではなく、再利用可能な制作システムを生み出せる点にある。
Willisonは実験の最後に、インストール済みのBlenderアプリケーションの使い方を説明するスキルをCodexに作成するよう依頼した。スキルとは、エージェントが専門的なワークフローを繰り返す際に役立つ、運用上の指示のまとまりである。
この最後の手順により、成功したセッションは再利用可能な知識へと変わった。今後のリクエストでは、実行ファイルのパス、バックグラウンドモードのコマンド、シーンスクリプト作成の基本的なアプローチを、毎回あらためて見つける必要がなくなる。
これは重要だ。なぜなら、エージェントの生産性はしばしば保持された手順に左右されるからである。モデルが毎回解決策を見つけ出せたとしても、繰り返される探索は時間を浪費し、ばらつきを生む。
保存されたスキルには、Blenderを起動するコマンド、想定されるファイル配置、レンダリング規約、検証手順を記録できる。また、エージェントが中間の.blendファイルを保存すべきタイミングも定義できる。
その根底にある教訓は、エンジニアリングチームにはなじみ深いものだ。一度きりの成果は、そのプロセスが記録・レビュー・再利用されることで、より価値を持つようになる。
チームは同じパターンを、ブランド用レンダリング、製品モックアップ、絵コンテ用シーン、定期的なデータビジュアライゼーションに適用できる。エージェントはプロジェクトごとに即興で作業するのではなく、文書化されたパイプラインの中で構築する。
優れた再利用可能ワークフローでは、生成されたソースファイルとレンダリング出力を分離する。プロンプト履歴を保持し、シーンオブジェクトに一貫した名前を付け、大きな改訂の前にチェックポイントを保存する。
こうした実践は、エージェントの作業をレビューしやすくする。また、曖昧なフォローアップリクエストによって変更範囲が広がりすぎた場合の損害も抑えられる。
Willisonの公開リポジトリには、その履歴の一部が記録されている。連続する.blendファイル、Pythonスクリプト、エクスポートされたトランスクリプトが含まれており、読者は最初の依頼から最終レンダリングまでの経路を確認できる。
この記録は、最終画像だけよりも価値が高い。エージェントがどこでコードを使い、シーンがどのように拡張され、どの成果物が編集可能なまま残ったのかを示している。
同様のワークフローを検討する組織は、プロンプト、スクリプト、プロジェクトファイル、レビュー記録を相互に関連する技術知識として扱うべきだ。検索可能なengineering knowledge baseは、単にファイルの保存場所だけでなく、ワークフローが成功した理由を残せる。
このアプローチは、価格比較を必要とせずに、小規模なクリエイティブ実験の経済性も変える。開発者は、専門家を詳細な制作に関与させる前に、ビジュアルコンセプトを試せる。
これは3Dアーティストを置き換えるものとして捉えるべきではない。出発点を変えるものだ。アーティストは段落ではなく、粗いながらも構造化されたシーンを受け取れる一方、開発者はこれまでプロトタイプ化の前に止まっていたアイデアを探究できる。
生成されたオブジェクトに明確な名前が付けられ、適切にグループ化されている場合、引き継ぎは特に有用になる。専門家はシーン全体を作り直すことなく、不十分なジオメトリを置き換え、マテリアルを調整し、リグを再構築できる。
コーディングエージェントは、Blenderを周辺ツールとも接続できる。入力データの準備、シーンスクリプトの生成、レンダリングの整理、出力処理のためのメディアユーティリティの呼び出しが可能だ。
Willisonは、エージェントが画像シーケンスをレンダリングし、FFmpegで結合できると指摘した。彼のペリカンの例はレンダリングされたシーンに焦点を当てていたが、これによりパターンは静止画から自動化されたアニメーションパイプラインへと広がる。
より広い価値はオーケストレーションにある。エージェントが最高のモデラー、レンダラー、動画エンコーダーになる必要はない。人間が検査できる成果物を保持しながら、専門ツールを連携させればよい。
Simon WillisonのBlenderテスト後に注目すべきこと
このパターンが印象的な個人デモを超えて広がるかどうかは、3つのシグナルによって決まる。
最初のシグナルは、モデル、マシン、Blenderのリリースをまたいだ再現性だ。他のユーザーも同程度のプロンプトを与え、有効なスクリプト、編集可能なプロジェクトファイル、成功したレンダリングを得られるべきである。
繰り返しテストでは、画像が表示されたかどうか以上を追跡すべきだ。エラー率、再試行、シーン構成、レンダリングの一貫性、後の編集に対するプロジェクトの耐性を検証する必要がある。
異なる環境でもこうした結果が安定していれば、Blender向けコーディングエージェントの有効性はより強まる。成功が一つのモデル構成と慎重な救済プロンプトに依存するなら、そのワークフローは依然として実験的なままだ。
2つ目のシグナルは、クリエイティブの専門家がエージェント生成シーンを実用的な出発アセットとして採用するかどうかだ。トポロジー、マテリアル、照明、命名、構図、後工程との互換性を評価できるため、彼らの判断は重要である。
プロフェッショナルなワークフローは改訂に耐えなければならない。シーンは複数のプロンプトを経ても理解可能で、人から人へきれいに引き継げ、元のカメラ視点を超えた変更にも対応できるべきだ。
アーティストが生成された.blendファイルを洗練させる証拠があれば、エージェントが制作に参加できるという主張は強まる。魅力的だが使い捨てのレンダリングが並ぶだけなら、その主張は弱まる。
3つ目のシグナルは、クリエイティブソフトウェアメーカーがプログラム可能なアクセスをどのように改善するかだ。Blenderはすでに成熟したPythonインターフェースとヘッドレス実行を提供している。他のアプリケーションも、より優れたスクリプティング、構造化されたプロジェクトAPI、エージェント向けドキュメント、より安全な権限モデルで対応する可能性がある。
ベンダーがこうした接点に投資すれば、競争は生のインターフェース操作から離れていく。エージェントは明示的なコマンドと検査可能な状態を通じて、ますますアプリケーションを操作するようになる。
ベンダーが閉じたインターフェースを優先する場合、エージェントはスクリーンショットの解釈と模擬クリックに頼り続けることになる。その手法はより多くのソフトウェアを扱えるが、再現と監査は依然として難しい。
Simon Willisonの例は、開発者に今日から実施できる実践的なテストを示している。範囲を限定したシーンを選び、すべてのスクリプトとプロジェクト改訂を保存し、最終レンダリングだけでなく編集可能な結果を評価することだ。
エージェントが他者にも理解できるファイルを作ったかを問う。次のプロンプトが以前の作業を損なわずにシーンを改善できるかを確認する。より広いアクセスを与える前に、生成されたPythonをレビューする。
最も重要なのは、引き継ぎの品質でワークフローを判断することだ。魅力的なペリカン画像は注目を集めるが、編集可能なシーン、読みやすいスクリプト、繰り返し可能な手順こそが、持続的な価値を生む。
この実験が浮き彫りにするのは、その対立である。コーディングエージェントはいまやソースリポジトリを大きく超えて到達できるが、アクセス可能な操作手段を備えたソフトウェアだけが、信頼できる経路を提供する。
次に決定的となる例は、最も視覚的に派手なものではない。人間がプロジェクトを開き、エージェントの選択を理解し、誤りを修正し、自信を持って作業を続けられるものだ。
