コンテンツにスキップ

Blender × Claude Connector — 自然言語による3D制作入門

Updated: 2026-05*

1. はじめに

本教材は、Anthropicが2026年4月に公開したBlender Connectorを用い、Claudeとの会話のみでBlenderのモデリング・マテリアル設定・アニメーション・シーン整理を行う方法を解説する。前教材(Blender × Claude — Pythonスクリプティング入門)が、生成されたPythonコードを手動でBlenderに貼り付ける運用であったのに対し、本教材ではClaudeとBlenderが直接通信し、人間が指示を出すだけで3D操作が完了する構成を扱う。

1.1 参考サイト

1.2 本教材の目的

本教材の到達目標は次の3点である。

第一に、Claude DesktopとBlenderにConnectorを導入し、両者を通信可能な状態に設定できるようになることである。第二に、Pythonコードを書かずに、自然言語でモデリング・配置・マテリアル付与・アニメーション設定を行えるようになることである。第三に、Claudeを「シーンの整理者」「複雑な構造の解説者」「最適化のアドバイザー」として活用する3層の使い方を習得することである。

1.3 Pythonスクリプティングとの違い

前教材で扱ったPython運用と、本教材のConnector運用の違いは下表の通り整理できる。

  • Python運用(手動)
    • 通信方式:Claudeでコード生成 → 人間がコピー → BlenderのText Editorにペースト → Run Script
    • 文脈:Claudeはシーンの状態を知らないため、人間が状態を言葉で伝える必要がある
    • エラー処理:エラーログを人間がコピー&ペーストでClaudeに渡す
    • 環境要件:ブラウザ版Claude(claude.ai)で可能
  • Connector運用(自動)
    • 通信方式:Claudeから直接BlenderのPython APIを呼び出し、結果も自動で受け取る
    • 文脈:Claudeが開いているシーンを読み取り、現在の状態を把握したうえで応答する
    • エラー処理:Claudeが自分でエラーを検知し、自動で修正を試みる
    • 環境要件:Claude Desktop(ローカルアプリ)が必須、ブラウザ版は非対応

※ Connector運用は便利だが、Pythonの基礎を理解していると生成された処理を検証・改造できるため、両方学んでおくのが望ましい。

1.4 想定する読者

メディアアート・デザイン領域の学生を主たる対象とする。Blenderの基本操作(オブジェクトの追加・選択・移動・レンダリング)が一通り経験済みであることを前提とするが、Pythonの知識は不要である。前教材を未履修でも本教材は単独で進められる。

2. 仕組みの理解

ClaudeとBlenderがどのようにつながっているかを把握しておくと、トラブル時の切り分けがしやすくなる。

2.1 MCP(Model Context Protocol)

MCPはAnthropicが策定したオープン規格で、AIモデルと外部ツールを安全に接続するための共通プロトコルである。USB-Cが多様なデバイスを一つの規格で繋ぐように、MCPは多様なソフトウェアをAIに繋ぐ標準として設計されている。Blender ConnectorはこのMCP上で動作するため、Claude以外のMCP対応AIクライアント(Claude Code、Cursor、VS Code等)からも同じBlender環境にアクセスできる。

2.2 接続構造

下図のように、3つの要素が連携する。

  • Claude Desktop(クライアント)
    • 役割:ユーザーからの自然言語指示を受け取り、必要なBlender操作をMCP経由で送信
  • Blender MCP Server(中継)
    • 役割:Blender内部で動作し、Claudeからの指示をPython APIの呼び出しに変換
  • Blender本体
    • 役割:Python APIで受け取った命令でシーンを実際に変更

通信はローカルマシン内で完結する。インターネット経由でシーン内容が外部に送信されることはなく、Claudeへ送られるのは「現在のシーンの構造情報」と「Claudeが生成して実行を要求するコード」に限られる。

2.3 公式コネクタと非公式コネクタ

Blender Connectorには大別して2系統が存在する。

  • Blender公式(推奨)
    • 提供:Blender Foundation配下のBlender Lab
    • 配布:Blender MCP Server 公式ページ
    • 動作要件:Blender 4.2以降(Blender 5.1以降を要求する記述もあり、利用時に確認)
  • 非公式(ahujasid/blender-mcp)
    • 提供:個人開発者Siddharth Ahuja氏
    • 配布:GitHub: ahujasid/blender-mcp
    • 特徴:2025年初頭から存在し、Polyhaven・Hyper3D・Sketchfab等の外部アセット連携が豊富

本教材では公式版を前提に解説する。非公式版はPolyhavenからのHDRI自動ダウンロード等の独自機能があり、必要に応じて併用するとよい。

3. 環境構築

Claude DesktopとBlenderの両方に設定が必要である。一度設定すれば、以降は両アプリを起動するだけで連携が動作する。

3.1 前提条件の確認

  • Claude Desktop
  • Blender
    • バージョン:4.2 LTS以降(公式案内では5.1以降を要求する場合あり)
    • ダウンロード:blender.org/download

※ ブラウザ版のclaude.aiではConnectorは動作しない。必ずデスクトップアプリ版を使用する。

3.2 Claude Desktop側の設定

Claude Desktopを起動し、Connectorを追加する。

第一に、チャット入力欄の左にある「+」ボタンを押下する。第二に、メニューから「コネクタ」→「コネクタを追加」を選択する。第三に、検索窓にBlenderと入力し、表示されたBlenderアイコンを選択する。第四に、「Install」ボタンを押下する。

これでClaude Desktop側は完了である。

3.3 Blender側のアドオン導入

Blender MCP ServerをBlenderにインストールする。

第一に、ブラウザでBlender MCP Serverのページを開く。第二に、ページ内の「インストールリンク」をドラッグし、起動中のBlenderウィンドウへドロップする。第三に、「新規エクステンションリポジトリを追加するか」と問われるので、「Add Repository」→「作成」の順にクリックする。第四に、同じリンクをもう一度Blenderにドラッグし、「エクステンションのインストール」プロンプトで「OK」を押下する。

Blender Preferences → System内の「Allow Online Access」にチェックを入れる必要がある場合もある。

3.4 オンラインアクセスの許可

Blender 4.2以降では、外部通信を行う機能を明示的に許可する必要がある。

  • Edit → Preferences → System
    • Allow Online Access:チェックを入れる

※ Blenderはセキュリティ上の理由から、初期状態では外部アクセスが無効化されている。Connectorは内部通信のみだが、この設定がOFFだと動作しないことがある。

3.5 接続確認

両アプリを起動した状態で、Claude Desktopの新規チャットに次のように入力する。

Blenderに接続して、現在開いているシーンに何があるか教えてほしい。

Claudeが現在のBlenderシーン内のオブジェクト一覧を返してくれば、接続成功である。デフォルト起動シーンであればCubeCameraLightの3つが報告される。

接続できない場合は、Claude Desktopとblenderの両方を一度終了し、再起動してみる。設定変更後の初回起動でうまくいかないことがある。

4. 基本的な使い方

Connectorが動作する状態で、Claudeに対する指示の出し方を整理する。

4.1 指示の基本原則

Pythonコードを書かせる場合と異なり、Connector経由では「結果」を自然言語で伝えるだけでよい。ただし次の3点を含めると精度が上がる。

第一に、対象範囲を明示する(シーン全体か、特定のコレクションか、選択中のオブジェクトか)。第二に、数値で表現できる部分は具体的に伝える(「10個」「半径5」「Z軸方向に2倍」など)。第三に、複数操作を一度に依頼する場合、順序を箇条書きで示す。

参考)良い指示の例

シーンを一度きれいにしてから、半径10の円周上に等間隔で12個のSphereを配置してほしい。
各Sphereの半径は0.5、シェードはスムーズに。

参考)曖昧な指示の例(Claudeが追加確認を求めることがある)

丸いやつをいい感じに並べてほしい。

4.2 シーン状態の把握

Claudeはシーン全体を読み取れるため、現状確認の依頼から始められる。

参考)プロンプト例

今のシーンにあるオブジェクトを、コレクションごとに整理して一覧で教えてほしい。
各オブジェクトの種類(Mesh、Light、Camera等)も併記する。

これはConnector運用の最大の利点である。Python運用ではシーンの状態をユーザーが言語化して伝える必要があったが、Connector経由ではClaudeが直接読み取ってくれる。

4.3 操作の実行

操作系の指示はそのまま自然言語で渡す。Claudeは内部でPythonコードを生成して実行し、結果を報告する。

参考)プロンプト例

シーン内のすべてのCubeを選択して、Z軸方向にランダムに -3 〜 3 の範囲で移動させてほしい。
seed値は42に固定する。

実行後、Claudeから「12個のCubeを移動しました」のような完了報告が返ってくる。Blenderビューポートに切り替えて結果を確認する。

4.4 コードを見せてもらう

Claudeが何をしたかを学びたい場合、実行前にコードを見せるよう指示できる。

参考)プロンプト例

今後のすべての操作について、実行前に使うPythonコードを表示してから実行してほしい。

これでConnectorを使いながらPython APIを学べる、教育用途に適した運用になる。

5. 実践1 — シーンの整理と命名規則

Connectorの実用面で最も効果が高いのが、既存ファイルの整理である。本節は公式チュートリアルでも筆頭に紹介されている用途である。

5.1 オブジェクト名の自動整理

過去に作ったファイルや、他人から受け取った.blendファイルはCube.001Sphere.014のような自動命名のオブジェクトで埋まっていることが多い。Connectorはこれらを内容に応じて改名できる。

参考)プロンプト例

開いているシーンを確認し、オブジェクト・コレクション・マテリアル・データブロックの名前を
内容がわかりやすい名前に変更してほしい。
また、名前と内容が一致していないものや、誤解を招きそうな名前があれば、
変更せずに一覧で報告してほしい。

Claudeはシーン全体を読み取り、椅子のメッシュならChair_Wood_01、床のテクスチャならMat_Floor_Concreteのような命名規則で整理する。

5.2 命名規則を指定する(任意)

命名規則をプロジェクトで統一したい場合、ルールを先に伝える。

参考)プロンプト例

命名規則を以下の通りとし、それに従って改名してほしい。
- Mesh Object: SM_カテゴリ_名前_番号(例: SM_Furniture_Chair_01)
- Material: M_カテゴリ_名前(例: M_Wood_Oak)
- Light: L_用途_番号(例: L_Key_01、L_Fill_01)
- Camera: C_用途(例: C_Main、C_Detail)

ゲーム開発のUnreal Engine命名規則など、業界標準を採用する場合にも同様に指示できる。

5.3 未使用データの削除(任意)

Blenderは削除したオブジェクトのデータブロック(Mesh・Material・Texture等)がファイル内に残り続けることがあり、ファイルサイズの肥大化につながる。

参考)プロンプト例

シーン内で使用されていないデータブロック(Mesh、Material、Texture、NodeGroup等)を
洗い出してほしい。
削除しても安全なものと、念のため残したほうがよいものを分けて報告する。
確認後、削除指示を出したら一括で削除する。

このように、破壊的な操作は「確認→実行」の2段階に分けて依頼するのが安全である。

6. 実践2 — 複雑な構造の理解

ネット上で配布される.blendファイルや、共同制作で受け取ったファイルには、Geometry NodesやShader Nodeで複雑な仕組みが組まれていることがある。これらの構造解析はConnectorの得意分野である。

6.1 Geometry Nodesの解説依頼

参考)プロンプト例

アクティブなオブジェクトに設定されているGeometry Nodes Modifierを順に確認してほしい。
各ノードグループが、データの流れに沿ってどのような処理をしているのか説明する。
入力ソケットと出力ソケットの意味も含めて記述する。

Claudeはノードツリーを読み取り、「最初にDistribute Points on Facesでポイント生成、次にInstance on Pointsでオブジェクトを配置、最後にRotate Instancesでランダム回転」のように、人間が読める手順として説明する。

6.2 ノードエディタへの注釈追加(おまけ)

説明文を頭の中に置くだけでなく、Blender内のNode Editorに直接フレームラベルとして書き込ませることもできる。

参考)プロンプト例

先ほどの説明を、ノードエディタ内のフレームラベルとして各ノードグループに追加してほしい。
日本語で簡潔に。完了したらファイルを保存する。

これによりファイル自体がドキュメント化され、後日開いたときに自分の理解を再構築する手間が省ける。

6.3 Shader Nodeの解析

マテリアルのノード構造も同様に解析できる。

参考)プロンプト例

Cube_01 に割り当てられているマテリアル"M_Wood_Oak"のシェーダーノード構成を解析してほしい。
Principled BSDFの主要パラメータ値、テクスチャの使用状況、特殊なノード接続があれば、
それらを箇条書きで報告する。

7. 実践3 — 依存関係の調査

ファイル内のオブジェクトやマテリアルを変更・削除する前に、それが他のどこから参照されているかを把握しておく必要がある。Connectorはこの調査を自動化できる。

7.1 マテリアルの参照箇所調査

参考)プロンプト例

このファイル内で"M_Glass_Tinted"マテリアルを使用している箇所をすべて調べてほしい。
オブジェクト、ノードグループ、Geometry Nodesの設定など、
参照されている可能性のある場所を含めて一覧化する。
このマテリアルを削除した場合に影響を受ける箇所や、壊れる可能性がある部分も教えてほしい。

Claudeはシーン全体をスキャンし、「Object_A、Object_B、Object_Cが直接使用」「NodeGroup"WindowGlass"の内部でも参照されている」のように一覧で報告する。

7.2 オブジェクトの参照調査

Modifier、Constraint、Driver、Particle Systemなどから他オブジェクトを参照している場合がある。これらも同様に調査できる。

参考)プロンプト例

"Empty_Controller_Main"を参照しているオブジェクトや設定をすべて調べてほしい。
Driver、Constraint、Modifier、Geometry Nodesの入力など、
参照される可能性のある場所を網羅する。

7.3 削除前の安全確認パターン

破壊的な操作(削除、Apply、Joinなど)は、参照調査と組み合わせると安全に進められる。

参考)プロンプト例(推奨パターン)

これからシーンの整理を行う。次の手順で進めてほしい。
1. 不要そうなオブジェクトの候補を洗い出す
2. 各候補が他から参照されていないかを調べる
3. 安全に削除できるものと、削除すると問題が起きるものを分けて報告する
4. 私が承認したものだけを削除する

8. 実践4 — レンダリング最適化

レンダリング時間が長い場合、ポリゴン数の偏りやテクスチャ解像度の過剰が原因のことが多い。Connectorはシーン全体を俯瞰してボトルネックを特定できる。

8.1 重いオブジェクトの特定

参考)プロンプト例

シーン内の各メッシュについて、ポリゴン数・オブジェクト名・所属コレクション・
カメラから見た画面上での大きさを調べてほしい。
そのうえで、ポリゴン数が多いにもかかわらず画面上で小さくしか表示されていない
オブジェクトを優先的にリストアップする。
最適化すべき候補として、理由とあわせて提案する。

「画面に占める割合が1%以下なのにポリゴン数が10万を超えているもの」のようなコストパフォーマンスの悪い箇所が一覧で得られる。

8.2 自動LOD適用(任意)

特定されたオブジェクトに対し、Decimate Modifierを一括適用することもできる。

参考)プロンプト例

先ほど提示された最適化候補のうち、画面占有率5%未満のものに対し、
Decimate Modifierをratio=0.3で追加してほしい。
追加前のポリゴン数と追加後の見込み数を報告してから実行する。

8.3 テクスチャ解像度の点検(おまけ)

参考)プロンプト例

シーンで使われているすべてのImage Textureについて、
解像度・ファイルサイズ・割り当てられているマテリアル・カメラから見た画面占有率を
一覧化してほしい。
画面占有率に対して解像度が過剰なものを最適化候補として提案する。

9. 実践5 — モデリングとアニメーション

ここまでは既存シーンへの解析・整理が中心だったが、ゼロからの制作にも当然使える。

9.1 オブジェクトの配置

参考)プロンプト例

シーンを空にしてから、次の構成でCubeを配置してほしい。
- 10×10のグリッド配置
- 各Cubeの間隔は2.0
- 各CubeのZ高さは sin(x * 0.5) + cos(y * 0.5) で決定
- すべてのCubeにスムーズシェードを適用

Pythonコードを書かなくても、結果として欲しい状態を記述するだけで配置が完了する。

9.2 マテリアルの一括付与

参考)プロンプト例

シーン内のすべてのMesh Objectに対し、ランダムな色のPrincipled BSDFマテリアルを
割り当ててほしい。
- Base Color: HSV空間で Hue=ランダム、Saturation=0.8、Value=0.9
- Roughness: 0.3
- seed値: 42
マテリアルの命名は"M_Random_番号"とする。

9.3 アニメーションの設定

参考)プロンプト例

シーン内のすべてのCubeに対し、フレーム1〜240の間で
Z高さを sin(frame * 0.1 + (x + y) * 0.3) で変化させるキーフレームを打ってほしい。
xとyは各CubeのワールドX,Y座標を使う。
補間モードはLINEARに設定する。

実行後、Blenderのタイムラインで再生(Space)すると波打つアニメーションが確認できる。

9.4 カメラとライトの自動配置(おまけ)

参考)プロンプト例

今のシーン全体を俯瞰する位置に Camera を1つ配置し、
Three-Point Lighting(Key、Fill、Rim)を組んでほしい。
各ライトはAreaタイプを使い、Sizeと強度はシーンの規模に合わせて自動調整する。
レンダラーはCyclesに設定し、Samplesは128とする。

これにより、ライティング設計の経験が浅くても「とりあえず見栄えのするレンダリング」が即座に得られる。

10. Claudeとの協働パターン

Connector運用で効果的なワークフローを整理する。

10.1 「読む→提案→実行」の3段階で進める

破壊的な操作(削除・Apply・Join)や、大規模な変更は、必ず3段階に分けて依頼する。

第一段階:Claudeに現状を読み取らせ、状況を報告させる。第二段階:Claudeに変更案を提案させ、人間が承認する。第三段階:承認した内容のみを実行させる。

このパターンを意識すると、想定外の変更による事故が大幅に減る。

10.2 シーンを「会話の共有資源」として使う

ConnectorはClaudeに対し、人間と同じ「目の前のシーン」を見せる仕組みである。これにより指示の言語化コストが激減する。

例として、「あの右奥にあるオブジェクト、もう少し赤くして」という指示でも、Claudeはシーンを見て「Cube_007のことですね」と特定できる。Pythonコード生成時には不可能だった、文脈共有型の会話が成立する。

10.3 Pythonコードの学習教材として使う

「実行前にコードを見せてほしい」と指示することで、Connectorは強力なPython学習支援ツールにもなる。やりたい操作を自然言語で伝え、生成されたコードを読み、自分でも書けるようにする、というサイクルが回せる。

10.4 限界の理解

Connectorは万能ではない。特に次の領域は2026年5月時点で苦手とされる。

  • 複雑なGeometry Nodesの新規構築(数ノードまでは可能、それ以上はエラー率が上がる)
  • リギング(Armatureの作成は可能だが、IK・ウェイトペイント込みの完全なキャラクターリグは現実的でない)
  • 美的判断(「ライティングが何となく違和感」「構図のバランスが悪い」といった主観的な調整)
  • バージョン依存のAPI変更(Blender 4.0以降のGeometry Nodes interface APIなど、訓練データの古さに起因する誤りが残る)

Connectorは「技術的な作業の自動化」には強いが、「何を作るべきか」「どう作るのが美しいか」の判断は人間側に残る。これは現時点で人間が引き受けるべき価値の高い部分でもある。

11. おわりに

本教材では、Blender Connectorによる自然言語でのBlender操作を扱った。前教材のPythonスクリプティングと比較すると、コードを書かない分だけ思考の流れと制作の流れが直結し、特に「シーンの整理」「既存資産の解析」「最適化」といった非クリエイティブだが時間を食う作業で大きな効果がある。

ただし、Connectorは魔法ではない。生成AIがBlenderを操作している以上、内部ではPythonコードが書かれて実行されている。この事実を理解しておくと、トラブル時の対処や、より高度な使いこなしへの移行がスムーズになる。前教材と本教材を両輪として習得することを推奨する。