Blender MCP でできること、限界が来る場所
AIエージェントでBlenderを動かす話を公平に。Blender MCPが圧勝する仕事、抽象度が効いてくる場面、そして作業の分け方まで。
アドオンを入れ、Start MCP Server を押し、椅子を頼む。数秒で椅子が出てきます。プロポーションもまともで、マテリアルも付いています。ところが「歩道つきの家が十二軒並ぶ通り」を頼むと、セッションの性格が変わります。エージェントは長いPythonスクリプトを書き、実行し、シーンを読み返し、壊れたところを繕い、また次のスクリプトを書きはじめます。たいていは最後までたどり着きます。ただし椅子のときより一桁多いターンを消費しますし、十二軒目が一軒目と揃っていることはめったにありません。
この差が本稿の主題です。Blender MCP は本当によくできていて、本当に無料で、ある広い範囲の仕事では他に並ぶものがありません。高くつく場所は具体的で、曖昧に流さず正確に名指しする価値があります。
Blender MCP とは実際のところ何か
多くの人が指しているのは Siddharth Ahuja 氏の blender-mcp(MITライセンス)で、ソケット越しに話す二つの部品でできています。アドオンが Blender の内部で動いて小さなTCPサーバーを開き、別プロセスのPythonサーバーがあなたのクライアントと Model Context Protocol で会話して、JSONコマンドをそのソケットへ流します。導入はパッケージマネージャの用意、コマンド一つ、プリファレンスでアドオンを有効化、そしてビューポートのサイドバーで Start MCP Server を押すところまで。README は自らの立場についても率直で、これはサードパーティの統合であり Blender 製ではない、と書かれています。
ツール一覧の形が、この先の話のすべてを決めます。だから丁寧に読む価値があります。三つのグループです。
- シーンを読む。
get_scene_info、get_object_info、get_viewport_screenshot。作ったものを推測ではなく実際に見に行けます。 - 実際に手を動かす一つ。
execute_blender_code。起動中の Blender の中で任意のPythonを実行し、bpy、bmesh、mathutilsがスコープに入っています。README は先に保存しておけと警告しますが、それは正しい警告です。 - アセット。ライブラリ全体がCC0の Poly Haven、それに Sketchfab と Poly Pizza からの検索とダウンロード。さらに Hyper3D Rodin と Hunyuan3D によるテキストからの3D生成があり、結果は開いているシーンへそのまま読み込まれます。
ここで、一覧に「ない」ものに注目してください。create_object はありません。modify_object も set_transform もありません。初期のバージョンにはこの種のツールがいくつかありましたが、現行のサーバーからは外されています。エージェントが作るジオメトリは、すべてPythonを書いて作られます。
公式版もあります
2026年4月からは Blender Lab による公式のMCPサーバーもあり、Blender の開発者自身が書いた Blender コネクタが Claude 側に用意されました。同じ時期に Anthropic が Blender のコーポレートパトロンとなり、資金は Python API を含むコア開発に向けられています。公式サーバーの位置づけは、シーンの解析とデバッグ、多数のオブジェクトへの一括変更、そして Python API を使って Blender 自身のUIにツールを足すこと。出自も力点も違いますが、根本のインターフェースは同じです。エージェントのてこは bpy です。
単純にこれが最適解である仕事
批判の前置きの社交辞令ではありません。他を選ぶほうが間違いになる仕事は、長いリストになります。
- オブジェクト一つ。小道具、家具、モジュール壁の一区画。エージェントが三十行書き、あなたが見て「脚が細い」と言えば脚を直す。始めから終わりまで二分です。
- マテリアルとシェーディング。ノードグラフはデータですから、Pythonが書けるエージェントは組むことも繋ぎ替えることもできます。Poly Haven の8KのCC0テクスチャを、費用もクレジット義務もなしに引いてこられます。
- 一括編集。全オブジェクトをコレクション名で改名する。ガラス系マテリアルのラフネスを一律0.05にする。非均一スケールの四十個を見つけて直す。ここでは汎用のスクリプトインターフェースは妥協ではなく、まさに正解の道具です。
- 本来なら検索していたこと。正しいコンテキストオーバーライドの書き方、モディファイアの引数の順序、書き出しが百倍の大きさになった理由。API知識そのものが商品です。
- Blender をまるごと相続できること。モディファイア、ジオメトリノード、Cycles、UVツール、スカルプト、リギング、物理、コンポジター。エージェントが付いた他のどれも、この面積には及びません。しかも大差です。
天井の高さもリストと同じくらい重要です。execute_blender_code という汎用の抜け道がある以上、Blender MCP の天井は Blender の天井であり、それはこの話題のなかで飛び抜けて高い天井です。Blender でできることなら、このアドオンを持つエージェントはいずれできる。強い主張ですが、成り立っています。
高くつくのは抽象度であって、ソフトではありません
一つの交差点、二通りの言い方
二本の道路を交わらせるとします。Blender 経由だと、エージェントはまず交差点とは何かを自分で決め、それから作らなければなりません。両方の道路面を押し出し断面として作り、重なる領域を見つけ、交差ポリゴンを切り、面がZファイティングしないよう内側を消し、四隅の隅切りを付け、縁石を別の掃引断面として作って各隅で止め、反対側から拾い直し、道路テクスチャが横断方向ではなく各枝に沿って流れるようUVを向け、最後に横断歩道の面を数ミリ浮かせて上に描かれるようにする。bmesh で書けば数十行と十以上の前提です。次の交差点が四叉ではなく三叉で、片方の道路が広ければ、また別の数十行になります。
もともとロケーション単位で考える道具なら、交差点は一つの操作です。二本の道路は中心線と幅を持つオブジェクトで、「ここで繋ぐ」が一回の呼び出し。交差面も縁石の回り込みも歩道の隅も路面標示も一緒に出てきます。交差点がその道具の持つ概念だからです。エージェントはそのターンを「交差点をどこに置くか」の判断に使えます。あなたがエージェントに求めていたのは、そちらの判断のはずです。
これは Blender の欠点ではありません。Blender は交差点が何かを知りませんし、知る必要もありません。汎用のモデラーであり、その汎用性こそが前節のリストをあれだけ長くしています。噛み合っていないのは、ロケーションが数十個の反復する概念——車道、縁石、歩道、街区、区画、ファサード、階、開口——でできているのに対し、モデラーが差し出すのは頂点だ、という点です。
四十回の繰り返しの代価
通りとは同じ操作の反復であり、生成されたコードは漂流します。三軒目の階高が2.8mなのは、エージェントが棟の高さから割り出したから。三十一軒目が2.9mなのは、そのころには窓の上端から割り出しているから。エラーは出ず、ログにも残らず、あなたが気づくのは通りに立って軒のラインが揃っていないのを眺めるときです。スクリプト方式のパイプラインでは、一貫性は毎ターン建て直す必要があります。道具がエージェントの代わりに約束事を保持してくれないので、約束事が住んでいる唯一の場所は会話であり、その会話は伸びるにつれて圧縮されていきます。
コンテキストを埋めるのは計画ではなくAPI
シーンの読み取りはすべてテキストで返ってきます。スクリプトは上りのトークンであり、しばしばトレースバックが下ってきます。Python APIの細部が、あなたの依頼文と同じウィンドウを占めます。オブジェクトが二百個に達するころ、「地中海風、二階建て、瓦屋根、歩道は両側」というエージェントの記憶は、二十分前に必要だった bpy.ops のシグネチャと、席を奪い合っています。長い作業が漂流するのは、モデルの品質に由来する理由と少なくとも同じくらい、この構造的な理由によります。
実務に当てて生き残る目安。結果が「一つのもの」なら、Blender MCP が最短経路です。結果に配置がある場合は、どの道具を使うにせよ配置がその道具の一級のオブジェクトである必要があります。そうでなければ、エージェントは毎ターン頂点から配置を組み直すことになります。
項目ごとに並べる
MCPアドオンを入れた Blender と、ロケーション専用のエディタ(ここでは Cuberta)を並べます。
| 観点 | Blender にMCPアドオン | ロケーション専用のエディタ |
|---|---|---|
| 最初から与えられるもの | Blender のすべて。モディファイア、ジオメトリノード、Cycles、UVツール、リギング、物理、加えてCC0やマーケットのアセット検索 | ロケーション単位の操作。交差点と歩道を含む道路網、ファサード付きの街区、家具の入った内装、地形、植生、照明、時刻 |
| エージェントが自分で発明するもの | プリミティブより上のジオメトリすべてを、Pythonで、毎回 | 配置。つまり、そもそもエージェントに任せたかった部分 |
| 結果までのターン数 | スクリプトを書く、走らせる、シーンを読み返す、直す。交差点一つがスクリプト一本、通りなら何本も | ロケーションの概念ごとに一回の呼び出し。セッションはコードレビューではなく配置の相談になる |
| 編集しやすさ | 完全。できたものはすべて Blender ネイティブのデータで、フルセットの道具で手で直せる | 選択・移動・削除できる実体のあるオブジェクト。どの手順も取り消せて、建てる場所と建てない場所を指定できる |
| 書き出し | ほぼ何でも。glTFとGLB、FBX、USD、OBJ、Alembicなどが標準で入っている | テクスチャ込みのGLBまたはFBX |
両方使う、しかもこの順番で
本当の間違いは、これを二者択一として扱うことです。二つのやり方は反対方向に壊れます。それはまさに、好みよりパイプラインが勝つ条件です。
環境制作でうまくいく順番はこうです。まず場所が安く作れる場所で場所を作る。道路網、交差点、街区の分割、建物のマス、内装、植生、照明、時刻まで。次にテクスチャ込みでGLBかFBXに書き出し、Blender で開く。そこから Blender の強みを、割に合うところへ注ぎます。カメラが目線の高さで通る主役の建物をリトポし、レベル開始時に見える一列にアンビエントオクルージョンをベイクし、ファサードのばらつきをジオメトリノードで作り、開く扉にリグを入れる。これが Blender MCP のいちばん良い状態です。エージェントが一度に一つのオブジェクトを相手にする状態、つまり得意な問題サイズに戻っているからです。
逆方向も同じくらい有効です。主役の小道具をエージェントと Blender で作り、書き出し、ロケーションへドラッグする。受け渡しの形式を選ぶなら、両者は交換可能ではありません。GLBとFBXはマテリアル、スケール、アニメーションの扱いが分かれますので、アセットごとに悩むより一度きちんと決めておくほうが得です。
Cuberta は、この分担の前半のために作られたエディタの一つです。無料のデスクトップアプリで、自前のMCPサーバーを持っています。Copy connect command を押してターミナルに貼れば、すでに使っているエージェントがビューポートを動かし、道路網、街区、内装、地形、照明をロケーション単位の操作として組み立てます。あなたはそれを見ていて、気に入らない手順を取り消せます。書き出しはテクスチャ込みのGLBかFBXで、これが上に書いた受け渡しにそのまま乗ります。モデラーではありませんし、そのふりもしません。リトポやシェーダーの作業は Blender の担当のままです。ひとつのセッションで二つ三つのサーバーを併用するのは普通のやり方なので、決め打ちする前に3Dとゲーム開発まわりのMCPサーバー全般を眺めておく価値はあります。
一回で決めるための目安
- オブジェクト一つ、マテリアル一つ、一括編集一回、スクリプト一本。Blender MCP です。代替候補のインストールが終わる前に、こちらは終わっています。
- レンダリングが成果物。迷わず Blender です。Cycles は置き換えの利くものではありません。
- 配置があるもの全般——交わる道路、通りを向いた建物、つながる部屋。その道具で配置が一級のオブジェクトかどうかを確かめてください。違うなら、その分をPythonで払うことになります。
- 月曜にレベルデザイナーが開くFBXかGLB。場所が安いところで場所を作り、アセットは Blender で仕上げ、書き出しは一度だけ。
- アニメーターが変形させるトポロジー。どちらのやり方も製品水準のエッジフローはくれません。自分でモデリングし、UVとマテリアルをエージェントに任せてください。
正直な境界線
Blender MCP の天井は Blender の天井で、その床は Python です。この組み合わせはオブジェクト一つでは無敵で、百個になると高くつきます。そして文の前半も後半も、同じ一つの設計判断から来ています。汎用のモデラーをエージェントに渡し、コードを書かせる、という判断です。ロケーション専用のエディタは逆の取引をします。天井をずっと低くし——スカルプトもCyclesもリギングもなし——その代わりに、交差点が五十行ではなく一回の呼び出しで済む床を手に入れる。
ですから問いは、どちらが勝つかではありません。その問いを立てたとき、自分の仕事のどちら半分を見ているか、です。