Blender MCPがつながらないときの確認順|Codexとブリッジを切り分ける

Blender MCPの接続をCodex、外側サーバー、TCPブリッジ、シーンの4層で確認する図 開発環境

CodexにBlender MCPのツールは出ている。それなのに実行すると、Blenderへの接続を拒否される。あるいは、昨日は動いたのにBlenderを再起動したら動かない。

実機で確認したときも、外側のMCPサーバーは応答している一方で、Blender側のTCPブリッジだけが停止している状態がありました。両方をひとまとめに「MCP」と呼ぶと、動いている側を何度も再設定することになります。

ツール一覧が見えることと、Blenderまで届いていることは別です。

対象はWindowsのCodex CLIとBlender Lab公式MCPです。接続の検証にはBlender 5.1.2と公式MCP v1.0.0を使い、2026年11月14日に公式リリースを再確認しました。初回の設定がまだなら、CodexからBlender公式MCPに接続する手順から始めてください。

Blender MCPは4層に分けて見る

公式リポジトリが示す基本経路は、MCPクライアント、別プロセスの blender-mcp、Blenderアドオンの3要素です。トラブルを探すときは、アドオン内部のTCP待受とコード実行も分けると判断しやすくなります。

CodexからBlenderシーンまでを、MCPクライアント、blender-mcp、TCPブリッジ、bpyの4層に分けた図
上から成功条件を確認し、応答が止まった区間を特定します。

外側の blender-mcp は、CodexがSTDIOで起動するローカルプロセスです。Codexとのやり取りは標準入出力を使うため、通常はここに待受ポートがありません。

一方、Blender側ではアドオン内のブリッジがTCPソケットを開きます。2026年8月26日時点の公式コードで、既定値は localhost:9876 です。ただし、アドオンのHost / Portと、外側サーバーの環境変数 BLENDER_MCP_HOST / BLENDER_MCP_PORT で変更できます。

9876 は公式の既定値であって、変更できない固定値ではありません。

9191 を使う公式の手順は、別のクライアントからHTTPで blender-mcp に接続する例です。この記事のSTDIO構成で確認するTCPポートは、Blender側の 9876 です。

症状から最初に見る場所を決める

症状 最初に確認する場所 ここで分かること
Codex側でサーバーが見えない CodexのMCP設定と起動コマンド STDIOサーバーを起動できているか
ツールは出るが接続を拒否される BlenderアドオンとTCPブリッジ blender-mcp からBlenderへ届くか
Blender再起動後だけ失敗する ブリッジのAuto Start 新しいBlenderプロセスで待受が始まったか
応答するが違うシーンが返る 読み取り結果とOutliner 別のBlenderや別のシーンにつないでいないか

同時に全部を直そうとせず、表の入口から内側へ進みます。

Codex側でMCPサーバーが見えない

Blenderを開く前に、Codexが外側のサーバーを認識しているか確認します。

codex mcp list

対象サーバーが一覧にない場合は、~/.codex/config.toml、または信頼済みプロジェクトの .codex/config.toml を確認します。OpenAI公式資料では、STDIOサーバーの設定に起動コマンドが必須です。

[mcp_servers.blender]
command = "blender-mcp"

仮想環境へ入れた場合は、Codexを起動した環境からそのコマンドを解決できる必要があります。いきなりサーバーを常駐起動するのではなく、まず同じターミナルで次を実行します。

blender-mcp --help

usage が出れば、そのターミナルからサーバーを起動できるところまで確認できました。導入記事のように uvx を使っている場合は、設定の cwd へ移動し、uvx --from . blender-mcp --help を実行します。コマンドが見つからなければ、PATH、command、args、cwd を見直します。

旧版の起動時に No module named 'mcp.server.fastmcp' が出る場合は、ポートではなくPython SDKの組み合わせを確認します。v1.0.2以降にはSDKを2未満に固定する公式修正が入っています。 導入記事に旧版を維持する場合の回避策も載せています。

CodexのTUIでは /mcp も確認します。codex mcp list に登録があっても、初期化に失敗していれば利用可能なツールとして出ません。設定を変えたあとはCodexまたはIDE拡張を再起動し、同じ2か所を見直します。

この段階の成功条件は、Codexにサーバー名とツールが表示されることです。 Blenderの接続確認はまだ終わっていません。

MCPプロセスは起動するがBlenderへ接続を拒否される

公式サーバーはブリッジへ接続できないと、次の趣旨のエラーを返します。

Cannot connect to Blender at localhost:9876.
Ensure Blender is running with the MCP addon enabled and the server started.

このエラーまで来たなら、CodexとSTDIOサーバーの間は通っています。次に見るのはBlenderです。

Blenderの 編集 → プリファレンス → アドオン → MCP を開き、アドオンが有効か、Server is running と表示されているかを確認します。停止中なら Start MCP Bridge Server を実行します。

検証した公式アドオンでは、Blenderの Online Access が無効だとブリッジが開始せず、設定画面にエラーが出ます。localhostだけを使う場合も、まずアドオン画面に出ているエラーを読みます。

続いて、アドオン側と blender-mcp 側のHost / Portを照らし合わせます。既定値のままなら、PowerShellでは次のように確認できます。

Test-NetConnection -ComputerName localhost -Port 9876

TcpTestSucceeded : True なら、少なくともそのアドレスでTCP待受があります。False なら、ブリッジが停止している、別ポートへ変えた、または開始時にエラーが出た可能性があります。

ポートを変更した場合は、確認コマンドだけを変更しても接続できません。外側サーバーにも同じ値を渡します。

[mcp_servers.blender]
command = "blender-mcp"
env = { BLENDER_MCP_HOST = "localhost", BLENDER_MCP_PORT = "9876" }

アドオン設定、Codexから起動するサーバーの環境変数、疎通確認の3つを同じHost / Portにそろえます。

Blenderを再起動した後だけ失敗する

アドオンがインストール済みでも、TCPブリッジはBlenderプロセスの中で動くランタイムです。Blenderを終了すればブリッジも終了します。外側のMCPサーバーが再び起動できても、新しいBlender側でブリッジが開始していなければ接続は拒否されます。

2026年8月時点の公式アドオンには Auto Start があり、コード上の初期値は有効です。開始は既定で1秒遅らせる作りなので、Blender起動直後は少し待ってから Server is running を確認します。

それでも停止しているときは、次の3点を見ます。

  1. Auto Start が現在の設定で有効か
  2. Blenderの Online Access が有効か
  3. 同じHost / Portを古いBlenderプロセスや別アプリが使用していないか

複数のBlenderを開く場合、同じ localhost:9876 を同時に待ち受けることはできません。片方で address already in use が出たなら、どのBlenderを操作対象にするか決めてから、必要に応じて別ポートを割り当てます。

Blender再起動後の失敗では、Codexを先に入れ直すより、アドオン画面のブリッジ状態を見るほうが早いです。

接続できても別のシーンが返る

ツール一覧が表示されていても、その一覧はSTDIOサーバーが公開しているものです。現在開いているBlenderへ届いている証明にはなりません。

書き込みの前に、公式ツール get_objects_summary を実行します。このツールは公式コードで読み取り専用として宣言されており、シーンのコレクション階層とオブジェクト名を返します。

画面に見えているオブジェクト名と、返ってきた一覧が一致するかを確認します。

  • 接続拒否になる: ブリッジまで届いていない
  • 別のオブジェクト一覧が返る: 別のBlenderインスタンスまたは別シーンを見ている
  • 期待した一覧が返る: 読み取り経路はBlenderまで通っている

期待した一覧が返るなら、接続の切り分けは完了です。その先でオブジェクトが見えない場合は、まずOutlinerにその名前があるかを確認します。Outlinerにあるなら、接続の設定を触る前に、コレクションの表示や3Dビューポートのフィルターを見ます。

公式の execute_blender_code は任意のPythonを実行するため、接続を確認するだけなら有効にする必要はありません。書き込みでエラーが出ても、途中までの変更が自動で元に戻るとは限りません。 確認は機密データへアクセスできない環境で行い、テスト中に意図しない変更が見えたら保存せず閉じます。

最短の確認順

  1. codex mcp list と /mcp でサーバーを確認
  2. blender-mcp --help で起動コマンドを確認
  3. BlenderのMCPアドオンで Server is running を確認
  4. アドオンと外側サーバーのHost / Portを一致させる
  5. Test-NetConnection でTCPブリッジを確認
  6. get_objects_summary で現在のシーンを読み取る

外側のSTDIOサーバーとBlender内のTCPブリッジを分けて見れば、再設定すべき場所は一つに絞れます。

参照元

コメント

タイトルとURLをコピーしました