blender-mcp を導入前に読む: ソケット経由でLLMにBlenderを操作させる設計と制約

誰のためのツールか: モデリングRather than手作業の自動化

READMEは「Prompt-assisted 3D modeling, scene creation, and manipulation」と説明しており、ゼロから作品を作るためのツールではなく、既存のBlender作業をプロンプトで呼び出すためのものだと読める。対象は、Blenderの操作自体は理解しているが、オブジェクトの量産、マテリアルの一括変更、シーン情報の書き出しといった反復作業を減らしたい人だ。

もう一つの層として、LLMクライアント側の設定を自分で書ける人という条件がある。MCPサーバーの登録はJSON設定かCLIコマンドで行うため、Claude Desktopの設定ファイルやCursorのMCP設定に触ったことがないと、最初の接続で止まる可能性が高い。逆に、Blenderをまったく触ったことがなく、プロンプトだけで3Dモデルを得たいという用途は想定されていない。アドオンを有効化し、ビューポートのNパネルからサーバーを起動する操作が手順に含まれているためだ。

二段構成の仕組み: addon.py と server.py の役割分担

リポジトリの説明では、コンポーネントは2つに分かれている。Blenderアドオン（addon.py）がBlender内部にソケットサーバーを立ててコマンドを受け取り実行する側、MCPサーバー（src/blender_mcp/server.py）がModel Context Protocolを実装してアドオンに接続する側である。

データの流れはこうなる。LLMクライアントがMCPツールを呼ぶ。MCPサーバーがその呼び出しをソケット経由でBlender内のアドオンに転送する。アドオンがBlenderのPython環境で処理を実行し、結果を返す。つまりMCPサーバー自身はBlenderのAPIを直接叩いておらず、Blenderのプロセス内で動くアドオンが実行者である。この分離のおかげで、MCPサーバーはBlenderのインストールパスを知らなくてもよく、接続先はソケットのエンドポイントだけになる。

READMEが挙げる機能は、オブジェクトの作成・変更・削除、マテリアルと色の適用、シーン情報の取得、任意Pythonコードの実行、そしてPoly Haven、Sketchfab、Poly Pizza、Hyper3D Rodin、Hunyuan3D経由のアセット生成だ。最後のグループは外部サービスへの依存を含むため、APIキーや認証の扱いが別途必要になる。READMEにはPersistent API Credentialsという節があり、認証情報を永続化する仕組みが用意されていることが分かる。

導入手順: uvx が前提になっている理由

READMEのQuickstartは3ステップで、uvのインストール、MCPクライアントへのサーバー登録、Blenderアドオンのインストールという順序になっている。uvの導入はプラットフォーム別にコマンドが示されている。macOSは brew install uv、Linuxは curl -LsSf https://astral.sh/uv/install.sh | sh、Windowsは powershell -c "irm https://astral.sh/uv/install.ps1 | iex" である。READMEは警告として、pip install uv を使わないよう明記している。uvxコマンドが作られなかったり、クライアントから見えない環境にuvが隠れたりするためだと説明されている。

クライアント登録はClaude Desktopの場合、Settings → Developer → Edit Config で以下のJSONを書く。

{"mcpServers": {"blender": {"command": "uvx", "args": ["blender-mcp"]}}}

Claude Codeは claude mcp add blender uvx blender-mcp、Codexは codex mcp add blender -- uvx blender-mcp というコマンドが示されている。Cursor、VS Code、OpenCode、AntigravityはMCP Client Setupの節に個別手順とワンクリックインストールボタンがあるとされている。

アドオンは uvx blender-mcp install-addon でインストールし、Blenderの Edit → Preferences → Add-ons で Interface: MCP for Blender を有効化する。接続はビューポートでNキーを押し、MCP for BlenderタブのStart MCP Serverをクリックする。READMEは、MCPサーバーのインスタンスを1つだけ動かすよう注意している。CursorとClaude Desktopの両方を同時に動かすなという指示である。

GUI起動クライアントが uvx を見つけられない問題

READMEで最も実務的な記述はこの部分だ。Dockやスタートメニューから起動したClaude Desktop、Cursor、VS CodeはターミナルのPATHを継承しないため、"command": "uvx" とだけ書くとターミナルでは動くのに spawn uvx ENOENT で失敗する。対処として which uvx（macOS/Linux）または where uvx（Windows）で絶対パスを調べ、/opt/homebrew/bin/uvx のような形でcommandに指定する。Windowsでは $env:USERPROFILE\.local\bin をユーザーPATHに追加するPowerShellの例が示されている。

この問題はインストール手順の不備ではなく、MCPクライアントがGUIアプリとして起動される場合の環境変数の継承範囲に起因する。同じ設定ファイルでも、ターミナルから起動したクライアントでは再現しないことがある。トラブルシューティングの節が用意されているのは、この手の失敗が想定内だからだと読める。

READMEには他の逃げ道も列挙されている。Make your client find uvx、Pin the Python version、Install without uv、Run with Docker、Environment Variables の各節である。uvを避けたい場合やPythonのバージョンを固定したい場合の手順が別途用意されている点は、uvx前提の手順が万人向けではないことの裏返しでもある。

任意Python実行という設計が持ち込むもの

機能表に「Code execution: Run arbitrary Python code in Blender from Claude」とある。これは利便性の説明であると同時に、このツールの性質を決めている。アドオンはBlenderのプロセス内でPythonを評価するため、プロンプト経由で渡されたコードはBlenderの権限でそのまま動く。ファイルシステムにも、Blenderが読み込んでいる外部データにも触れられる。

READMEは Limitations & Security Considerations という節を設けており、テレメトリの制御についても Telemetry Control という独立した節がある。テレメトリが存在すること自体はREADMEの見出しから確認できるが、何を送信するかの詳細はこの抜粋には含まれていない。導入前に該当節を直接読むべき箇所である。

実務上の判断としては、信頼できないプロンプトや外部由来のテキストをそのままこのツールに渡す運用は避けるべきだ。逆に、自分のローカル環境で自分が書いたプロンプトだけを使う分には、BlenderのPythonコンソールに貼り付けるのと同等の権限でしかない。危険度はツール固有ではなく、実行主体の権限と入力の出所で決まる。

Blender純正のPython APIと何が違うのか

比較対象として最も自然なのは、Blenderに標準で備わっているPython API（bpy）を直接スクリプトで書く方法である。違いは呼び出しの経路にある。bpyを直接使う場合、操作はスクリプトファイルに固定され、同じ入力に対して同じ結果が再現される。blender-mcpの場合、操作の内容はLLMが生成する。同じプロンプトでも毎回同じコードが出るとは限らず、生成されたコードが実行される前に人間が読むとは限らない。

もう一つの違いは実行の粒度だ。bpyスクリプトはバッチとして一度に走らせ、失敗したら例外で止まる。blender-mcpは対話的にツール呼び出しを繰り返すため、シーンの状態を確認しながら次の操作を決められる。試行錯誤が速い代わりに、途中の状態がどこにも記録されないまま進む。バージョン管理下に置けるのは最終的な.blendファイルだけで、そこに至る操作列は残らない。

どちらが優れているという話ではない。決まった変換を大量に回すならbpyスクリプト、何を作るか自体を対話しながら詰めるならblender-mcpという住み分けになる。READMEの機能表が「Object manipulation」「Material control」「Scene inspection」を並べているのは、いずれもbpyで書ける操作であり、blender-mcpはそれをプロンプトから呼べるようにしたものだと理解できる。

向かない場面と、導入前に確認する3点

このツールが向かないのは、出力の再現性が要求される場面だ。クライアントへの納品物として同じシーンを何度も再生成する必要がある場合、LLMが生成するコードの非決定性はそのままリスクになる。また、複数人で同じシーンを編集する制作フローでは、誰がどの操作をプロンプトで行ったかが残らないため、変更履歴の追跡が難しい。

前提条件はREADMEに明記されている。Blender 3.0以降、Python 3.10以降、uvパッケージマネージャーの3つである。バージョンが満たない場合、アドオンのインストールやサーバー起動の段階で失敗する。

導入前に確認すべきは3点に絞られる。第一に、GUIから起動したクライアントがuvxの絶対パスを解決できるか。which uvx の結果をそのまま設定に書けば済む。第二に、Blender側でStart MCP Serverを押した後、接続するクライアントを1つに限定できているか。READMEは複数インスタンスの同時起動を禁じている。第三に、Limitations & Security ConsiderationsとTelemetry Controlの各節を読み、任意Python実行とテレメトリの扱いを自分の環境のポリシーに照らして判断できるか。この3点がクリアなら、uvx blender-mcp install-addon から始めて問題ない。

ライセンスと保守の見通し

ライセンスはMITである。リポジトリのLICENSEファイルにその旨が示されており、改変と再配布が許される条件が定められている。ただし、このツールは外部サービス（Poly Haven、Sketchfab、Poly Pizza、Hyper3D Rodin、Hunyuan3D）と連携する機能を含むため、それら各サービスの利用条件はMITライセンスの範囲外であり、別途確認が必要になる。ここでは法的助言はできない。

保守の面では、READMEにUpgrading (existing users) という節があり、既存ユーザー向けの更新手順が用意されている。リリースは取得できておらず、バージョン番号に基づく互換性の判断はこの材料からはできない。MCPサーバーはuvx経由で都度取得されるため、クライアント設定にバージョンを固定していなければ、実行のたびに最新版が使われる点は把握しておきたい。固定したい場合はPin the Python versionの節と合わせて設定を見直す必要がある。

アドオン側はBlenderの設定ディレクトリにインストールされるため、Blender本体のアップグレード時にアドオンを再有効化する手順が発生しうる。READMEの手順はEdit → Preferences → Add-onsから有効化する形なので、更新後は同じ場所を確認するのが確実である。

編集部の結論

すでにBlenderのPython APIを触った経験があり、Claude DesktopやCursorから定型作業を呼び出したい人に向く。逆に、再現性が求められる制作パイプラインや、成果物をバージョン管理下で厳密に扱う現場には向かない。導入前に確認すべきは3点。Blenderが3.0以降でPythonが3.10以降か、GUI起動のクライアントがuvxの絶対パスを解決できるか、そしてBlender側のNパネルでStart MCP Serverを押した後に対象クライアントを1つだけに絞れているか。この3つが揃わない限り、最初のプロンプトは失敗する。

公式情報源

1. ahujasid/blender-mcp on GitHub
2. Issues
3. License: MIT
4. Project website
5. README