はじめに
前回の記事では、LM StudioとBlender MCPを接続して、ローカルLLMからBlenderを操作できる環境を作りました。
今回はその続きです。
せっかくBlenderをAIから操作できるようになったので、実際に3Dモデルを作らせてみることにしました。今回使うLLMは、Google Gemma 4 12B QATです。
指示する内容はシンプル。
「Blenderで雪だるまを作って」
果たして、ローカルLLMだけでどこまで3Dモデルを作れるのでしょうか。今回は実際の操作の様子と、途中で発生したエラーや問題点も含めて紹介します。
今回の環境
前回と同じ環境を使用します。
| 項目 | 環境 |
|---|---|
| LLM | Google Gemma 4 12B QAT |
| LLMクライアント | LM Studio |
| 3Dソフト | Blender 5.1 |
| MCP | Blender MCP |
まずは簡単な操作から
いきなり複雑なモデルを作らせる前に、Blenderを操作できるか簡単なテストをしてみました。最初のBlenderには、
- Cube
- Camera
- Light
が配置されています。そこで、
Cubeを削除して、代わりに円柱を1個追加してください。追加した円柱の名前を「TestCylinder」にしてください。
と指示してみます。するとGemma 4 12BはBlender MCPのexecute_blender_codeを呼び出し、Blenderを操作し始めました。
途中でBlender 5.1のAPIに関するエラーが何度か発生しましたが、エラー内容を確認しながらコードを修正。
最終的には、
まで成功しました。この時点で、かなり期待できます。
雪だるまを作らせてみる
いよいよ本番です。今度は、
Blenderで雪だるまの3Dモデルを作ってください。
と指示してみました。するとGemma 4 12BがBlender MCPを使って、複数のオブジェクトを作り始めました。
最終的には、以下のような構成になりました。
体
大きなSphereを使って、
Snowman_Body
を作成。
胴体
中くらいのSphereを使って、
Snowman_Middle
を作成。
頭
小さなSphereを使って、
Snowman_Head
を作成。
目
左右に2つのオブジェクトを配置。
Snowman_Eye_LSnowman_Eye_R
鼻
さらに、
Snowman_Nose
を追加。
これだけ見ると、かなり順調です。実際、Blenderの画面を見るとちゃんと雪だるまになっています。こんな感じ。
「ローカルLLMでも、ここまで自動で作れるのか」
というのが正直な感想でした。
オブジェクト名まで設定できる
今回ちょっと便利だと思ったのが、単純に形を作るだけではなく、オブジェクトに名前を付けてくれたことです。
例えば、
Snowman_Body
Snowman_Middle
Snowman_Head
Snowman_Eye_L
Snowman_Eye_R
Snowman_Noseというように、それぞれの役割が分かる名前になっています。後からBlenderで編集するときにも、この名前なら何のパーツなのか分かりやすいです。
次はマテリアルと色を設定してみる
ここまでできたので、次は雪だるまらしく色を付けてみます。指示したのは、
というシンプルなものです。Gemma 4 12Bはマテリアルを作成し、各オブジェクトに割り当てるところまでは進めることができました。
ところが、ここから少し様子がおかしくなります。
マテリアルの色が変わらない？
チャット上では、
各マテリアルのBase Colorを指定した色に設定しました！
という報告が返ってきます。ところが、Blenderを確認してみると……
色がほとんど変わっていません。
マテリアル自体は存在しています。しかし、Blender上では雪だるまのパーツがほぼ白いままです。
そこで、AIに現在のマテリアルの状態を詳しく調べてもらいました。
原因はノードの重複だった
調べてみると、少し妙な状態になっていました。例えばSnow_Materialには、
- プリンシプルBSDF
- マテリアル出力
- プリンシプルBSDF.001
- プリンシプルBSDF.002
という複数のPrincipled BSDFノードが存在していました。しかも、それぞれのBase Colorが違います。
例えば、
プリンシプルBSDF
Base Color: 0.8 / 0.8 / 0.8
プリンシプルBSDF.001
Base Color: 0.8 / 0.8 / 0.8
プリンシプルBSDF.002
Base Color: 0.8 / 0.9 / 1.0
という状態です。
つまり、AIが新しいPrincipled BSDFを追加して色を変更していたものの、実際に表示に使われているノードとの関係を正しく把握できていない可能性がありました。
「成功しました」と言っているのに、実際には違う
ここが今回かなり面白かったところです。Gemma 4 12Bにコードを実行させると、
Target: (0.8, 0.9, 1.0, 1.0)
Current: (0.800, 0.900, 1.000, 1.000)
という結果が返ってきます。チャット上でも、
「各マテリアルのBase Colorを、指定した通りの正確な値に更新しました！」
と報告されます。しかし、実際のBlenderのノードを確認すると、別のPrincipled BSDFには、
Base Color: 0.8 / 0.8 / 0.8 / 1.0
が残っています。つまり、
コード自体は指定したノードの値を正しく変更している。
でも、
そのノードが実際の表示に使われているとは限らない。
という状態でした。これはAIにBlenderを操作させる上で、かなり重要なポイントだと思います。
Material Outputとの接続も問題に
さらに調べてみると、
Material Output
Surface connected: False
という結果も出てきました。
つまり、Principled BSDFが存在しているだけではなく、Material OutputのSurfaceに正しく接続されている必要があるわけです。
ところがGemma 4 12Bは、このノード構造の扱いで何度かエラーを起こしました。例えば、
NoneType object has no attribute 'inputs'
といったエラーです。AIとしては、
Principled BSDFを探す
↓
見つける
↓
Base Colorを変更する
という処理をしようとしています。
しかしBlenderのノード構造は、単純に「Principled BSDFという名前のノードを探せばOK」というわけではありません。
エラーを見ながら修正していく
ここからはGemma 4 12Bの面白いところでもあります。エラーが出ると、その内容を見てコードを書き換えます。
例えば、
ノードが見つからない
となると別の検索方法を試します。また、
NoneType object has no attribute…
となれば、Noneチェックを追加します。このように何度か試行錯誤しながら、最終的にはマテリアルの色を実際に変更するところまで到達しました。
つまり、一発で完璧に作るというより、Blenderから返ってくる情報を見ながらLLM自身が修正していくという使い方になります。
重複オブジェクトも発生した
もう一つ問題になったのが、同じような名前のオブジェクトが増えてしまったことです。例えば、
Snowman_Body
Snowman_Body.001
Snowman_Body.002
や、
Snowman_Eye_L
Snowman_Eye_L.001
などです。Blenderでは同じ名前のオブジェクトを作ると、自動的に.001などが付きます。
そのため、
「AIが何度も同じパーツを作り直した結果、重複したオブジェクトが増えている」
という状態になりました。これもAIに調査させると、位置や回転、スケール、頂点数などを比較して重複候補を探すことができました。
ただし、ここで安易に削除するのは危険です。
実際、今回もオブジェクトを整理した際に、マテリアルの状態が変わってしまうなど、思わぬ影響が出ました。AIにBlenderの整理を任せる場合は、
まず調査 → 削除候補を表示 → 人間が確認 → 削除
という手順にしたほうが安全そうです。
Gemma 4 12BはBlender操作に使えるのか？
今回実際に使ってみた感想としては、
かなり使えます。
少なくとも、今回試したローカルLLMの中ではBlender MCPとの組み合わせでかなり使いやすいモデルでした。特に、
- Blender MCPのツールを呼び出す
- シーンの状態を確認する
- Pythonコードを生成する
- エラー内容を確認する
- コードを修正する
- 再度実行する
という一連の流れをある程度こなせました。一方で、苦手な部分もあります。
複雑になると急に難しくなる
今回の実験で感じた一番大きな問題がこれです。単純な、
Cubeを削除してCylinderを追加
くらいなら比較的うまくいきました。雪だるまのように、
Sphereを複数作る
配置する
名前を付ける
という処理も成功しました。ところが、
マテリアルを作る
ノードを確認する
Principled BSDFを探す
Material Outputとの接続を確認する
正しいノードのBase Colorを変更する
となると、かなり難易度が上がります。AIが「成功しました」と言っても、必ずBlenderの画面を確認したほうがいいということが分かりました。
今回の実験で分かったこと
今回の実験を通して、いくつか分かったことがあります。
1. ローカルLLMでもBlenderを操作できる
これは普通に面白いです。クラウドAIを使わなくても、
LM Studio＋Gemma 4 12B＋Blender MCP
という構成で、実際にBlenderを操作できました。
2. MCPによって「AIにコードを書かせる」から一歩進める
単純にChatGPTなどに、
Blender Pythonを書いて
とお願いするだけではありません。LLMがBlender MCPのツールを呼び出し、その結果を確認しながら次の処理を考えられます。
3. エラーからの自己修正もできる
BlenderのAPIに関するエラーが発生しても、エラー内容を確認してコードを修正することができました。
4. 複雑なBlender操作にはまだ限界がある
特にノードやマテリアルなど、Blender内部の構造が複雑になると難しくなります。
5. AIの「成功しました」を鵜呑みにしない
これが今回一番重要だったかもしれません。AIが、
「成功しました！」
と言っていても、実際のBlenderを見ると、
「いや、変わってないじゃん……」
ということがあります。AIの報告だけではなく、実際のBlenderの状態を確認することが重要です。
まとめ
今回はLM Studio＋Blender MCP＋Gemma 4 12Bという環境で、実際に雪だるまの3Dモデルを作らせてみました。
結果として、
という結果になりました。雪だるまそのものは、ローカルLLMだけでもちゃんと作ることができました。一方で、販売できるレベルの3Dモデルを完全にAI任せで作れるかというと、まだ難しそうです。
ただ、
「ローカルLLMにBlenderを操作させる」
という実験としては、かなり面白い結果になりました。今後、モデル側の性能が上がったり、Blender MCP側のツールが充実したりすれば、さらに複雑な3D制作もできるようになるかもしれません。
今回作った雪だるまについては、このまま販売用モデルとして使うのではなく、今回はあくまでAIによる3Dモデル制作の実験として一区切りにしたいと思います。
次は、もう少し複雑なモデルや、AIに3Dモデル制作を手伝わせる別の方法も試してみたいところです。
今回の副業活動時間
ブログ記事執筆：20分
合計：20分
今までの合計：655分
コメント