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待受とコード実行も分けると判断しやすくなります。

外側の 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点を見ます。
- Auto Start が現在の設定で有効か
- Blenderの Online Access が有効か
- 同じ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を実行するため、接続を確認するだけなら有効にする必要はありません。書き込みでエラーが出ても、途中までの変更が自動で元に戻るとは限りません。 確認は機密データへアクセスできない環境で行い、テスト中に意図しない変更が見えたら保存せず閉じます。
最短の確認順
codex mcp listと/mcpでサーバーを確認blender-mcp --helpで起動コマンドを確認- BlenderのMCPアドオンで
Server is runningを確認 - アドオンと外側サーバーのHost / Portを一致させる
Test-NetConnectionでTCPブリッジを確認get_objects_summaryで現在のシーンを読み取る
外側のSTDIOサーバーとBlender内のTCPブリッジを分けて見れば、再設定すべき場所は一つに絞れます。
参照元
- Blender Lab: MCP Server
- Blender公式
blender_mcpリポジトリ - 公式リポジトリの構成説明
- 公式Wiki: Llama.cppでHTTP
9191を明示する例 - 公式コード: STDIO / HTTP transportの既定値
- 公式コード: bridgeの接続先と既定値
- 公式コード: add-onのAuto Startと状態表示
- 公式コード: bridgeのTCP待受
- 公式コード:
get_objects_summaryの読み取り専用注釈 - 公式コード:
execute_blender_codeの破壊的操作注釈 - 公式リリース: SDKの依存関係修正
- OpenAI公式: CodexのModel Context Protocol

コメント