はじめに
Model Context Protocol (MCP)流行っていますね（2回目）。
前回記事から1年以上が経過しました。AIモデルの進化は天井知らずです。ではMCPは？
前回は capoom 氏のリポジトリを試しましたが、界隈の進化と熱量はすさまじく、すぐに別の強力なMCPサーバーが台頭してきました。
それが今回紹介する healkeiser/fxhoudinimcp です。
現在多くのスターを獲得しており、機能数はなんと179種類。前回の「お片付けが出来ない雰囲気駆動の刹那的Houdini Engine」からどれくらい進化したのでしょうか？
https://github.com/healkeiser/fxhoudinimcp
超簡単な説明
前回のMCPが、とりあえずSOPにノードを出せるレベルだったのに対し、今回の fxhoudinimcp はかなり高機能です。SOPはもちろん、LOP、TOP、さらにはAPEXやDOPまで、実務環境を強く意識した多機能なところが特徴です。
公式ドキュメントの検索機能を内包しており、AIが自分でヘルプを読んでからノードを組むという、以前誰しも考えたRAGでヘルプを用意して学習させたらいい感じになるんじゃない？と思っていた機能がすでに搭載されていて嬉しい仕様になっています。
筆者の環境
- macOS 26.3
- Houdini Indie 21.0.729
- Python 3.11.5
- Anthropicのアカウント（Claude利用：Proffesionalプラン） または Claude Code
前回のツールとは異なり、ローカルでのFastMCPによる直接起動が推奨されているため、環境構築はかなりシンプルになっています。
Houdini MCPプラグインのインストール
今回は uv ではなく標準の pip でも簡単にインストールできますが、設定ファイルが必要になるためリポジトリごとクローンするのが確実です。
１： Macのターミナルを開き、GitHubからクローンしてインストール
git clone https://github.com/healkeiser/fxhoudinimcp.git
cd fxhoudinimcp
pip install fxhoudinimcp
2： Houdiniの packages フォルダに設定ファイルをコピーします。存在しないので、packagesフォルダを作成
-
Mac:
~/Library/Preferences/houdini/21.0/packages/ -
Windows:
%USERPROFILE%/Documents/houdiniXX.X/packages/ -
Linux:
~/houdiniXX.X/packages/
※先ほどクローンしたフォルダの中にある houdini/fxhoudinimcp.json をコピーして配置します。
例えば私のパスだと
以下の場所に配置します。
/Users/jyouryuusui/Library/Preferences/houdini/21.0/packages/fxhoudinimcp.json
Houdiniにプラグインを認識させるためのファイルです。
3： コピーした fxhoudinimcp.json をエディタで開き、FXHOUDINIMCP のパスを、先ほどCloneしたリポジトリ内の houdini フォルダへの絶対パスに書き換えます。
※デフォルトの valueは以下の設定なので変更が必要です
{
"env": [
{
"FXHOUDINIMCP": {
"value": "$HOUDINI_USER_PREF_DIR/fxhoudinimcp/houdini",
"method": "default"
}
}
],
"path": "$FXHOUDINIMCP"
}
$HOUDINI_USER_PREF_DIR はHython（houの通ったPythonShell）で確認できます
>>> pref_dir = hou.getenv("HOUDINI_USER_PREF_DIR")
>>> print(pref_dir)
/Users/jyouryuusui/Library/Preferences/houdini/21.0
これだとHoudiniディレクトリ内を指してしまうので、変更します
{
"env": [
{
"FXHOUDINIMCP": "/Users/ユーザー名/パス/fxhoudinimcp/houdini"
}
],
"path": "$FXHOUDINIMCP"
}
ここは、先ほどCloneした場所のパスなので、私の環境だと以下のようにセットします。Cloneした場所が異なる場合はそこをセットします。
{
"env": [
{
"FXHOUDINIMCP": "/Users/jyouryuusui/fxhoudinimcp/houdini"
}
],
"path": "$FXHOUDINIMCP"
}
これだけでHoudini側の準備は完了です。Houdiniを起動すると、自動的にバックグラウンドでMCPサーバーとの接続待機状態になります。シェルフツールを自作して再起動を繰り返す必要はありません。
Claudeの手順
Claude Desktopでの設定も非常にシンプルです。もし日頃からCLIで開発しているなら、Claude Codeと連携させるのも最高に相性が良いです。
Claude デスクトップアプリの設定
前回同様、claude_desktop_config.json を開いて以下を追記します。
Claudeアプリを開き、以下の手順でMCP設定を行います：
- 「Claude」 > 「設定」
- 「開発者」タブで > 「設定を編集」の順に選択
- すると、
claude_desktop_config.jsonがFinderで開きます、使い易いエディタで開きます
すでにMCPサーバー設定がある場合は、fxhoudiniのオブジェクト部分を追加します。
Mac
{
"mcpServers": {
"fxhoudini": {
"command": "python",
"args": [
"-m",
"fxhoudinimcp"
],
"env": {
"HOUDINI_HOST": "localhost",
"HOUDINI_PORT": "8100"
}
}
}
}
※ command の python は、必要に応じて仮想環境やシステムのPython絶対パスに置き換えてください。
問題なければRunning状態となっています
Claude Codeの場合（おまけ）
ターミナルから一発で設定できます。
claude mcp add --scope user fxhoudini -- python -m fxhoudinimcp
HoudiniMCPを使おう
Claudeを起動すると、機能が追加されていることが確認できます。
前回まではツールアイコン（ハンマーマーク）が表示されていましたが、基本的には気にする事なくチャットで命令すれば問題ありません。
公式のGitの概要では、接続が完了すると、AIアシスタントは以下のことができるようになります。との記載があります。
- "Create a procedural rock generator with mountain displacement"（Mountainディスプレイスメントを用いたプロシージャルな岩ジェネレーターを作成する）
- "Set up a Pyro simulation with a sphere source"（球体をソースとしたPyroシミュレーションをセットアップする）
- "Build a USD scene with a camera, dome light, and ground plane"（カメラ、ドームライト、グラウンドプレーンを含むUSDシーンを構築する）
- "Create an HDA from the selected subnet"（選択したサブネットからHDAを作成する）
- "Debug why my scene has cooking errors"（シーンでクックエラーが発生している原因をデバッグする）
試してみます。
これは前回同様、機能ごとに許諾が必要です。「常に許可」で実行します
ちなみに、この時点でHoudiniが起動されていないとうまく動作はしません。
加えて、複雑な動作をしたい場合はチャットよりもCoworkの方がオススメですと推奨されます。
なので途中でCoworkに切り替えて再度同じ命令で実行しました。
ガンガン進めていくと右側の「進行状況」も進んでいます。昨年よりも段違いに推論力が上がっています。
結果
All validated. Building for real:Network built with 23K points. Now adding spare parameters to CTRL and wiring up expressions:Now wire `subdivide1` depth and all three mountain nodes to CTRL:Need to use expressions for float params. Setting them individually for all three mountain nodes:All expressions wired. Now verify and screenshot:Zero errors. Taking a screenshot:The rock generator is built and looking great — you can see the layered displacement giving it a natural, craggy boulder shape with visible surface detail.
Here's what's in `/obj/rock_generator`:
**Network (sphere → subdivide → 3× mountain → normal → OUT)**
- **sphere1** — polymesh base
- **subdivide1** — 3 subdivision passes → 23K dense polygons for smooth displacement
- **mountain_macro** — simplex/fBm, large element size (1.5) — breaks the sphere into an irregular boulder silhouette
- **mountain_primary** — sparse/terrain fractal — adds the rocky ridge and crevice detail
- **mountain_detail** — alligator/hybrid fractal — fine surface roughness
- **normal1** — vertex normals recomputed at the end for correct shading
- **OUT** — display node
**All controls are on the CTRL null** (select it and check the "Rock Generator" parameter folder):
- **Random Seed** — scrub this to generate completely different rocks
- **Subdivisions** — polygon density (1–5)
- **Macro Shape Height/Size** — controls the overall boulder silhouette
- **Primary Displacement Height/Size** — the main rocky ridge detail
- **Surface Detail Height/Size** — micro surface roughness
- **Overall Roughness** — shared roughness across all three noise layers
普通にすごい
機能テスト１（公式ドキュメントを読ませてみる）
このMCPの最大の特徴である「ドキュメント検索機能」から試してみます。
普通に聞くと、Claudeなどの最新モデルはWeb上の公式ページヘルプを見に行ってしまうので（それはそれでいいだろという）、今回はWeb検索せずにという注釈で命令しています
APEXのキャラクターリギングについて、Houdiniの公式ドキュメントをWeb検索を利用せず、HoudiniMCP経由で検索して、基本的なコンポーネント構成を教えてください。
結果。
search_help ツールが発火し、ローカルのHoudiniマニュアルを検索し始めました。
以下はClaudeからの返答です。
Houdiniのドキュメントから得た情報を整理してお伝えします。
HoudiniのAPEXキャラクターリギング — 基本コンポーネント構成
APEXとは
APEX（All-Purpose EXecution） はHoudini 20から導入されたグラフ評価フレームワークで、KineFXリギングの核となるエンジンです。キャラクターリグのロジックをAPEXグラフ（SOP上のジオメトリとして表現）で組み立て、評価を後回しにする「遅延評価（Delayed Evaluation）」によって、リグロジックと評価を分離し、パフォーマンスを大幅に向上させています。
キャラクターを構成する3つの要素
スケルトン（.skel） スケルトンはSOP上の「点（ジョイント）＋ポリゴンライン」で表現されます。リギング前に ガイドスケルトン を作り、タグ（ラベル）やプロパティを付与して、下流のリグコンポーネントが拾える状態にします。
スキン＆キャプチャウェイト（.shp） スキンジオメトリにキャプチャウェイトを設定し、ジョイントが動いたときにジオメトリが変形するようにします。
リグ（.rig） APEX グラフとして表現されたリグロジックです。FK階層・IK・ボーンデフォームなどの動作がすべてここに入ります。
これら3つは Packed Character Folder Structure にパックされ、APEX Scene Animate SOP のアニメートステートに渡されます。
APEXグラフの基本構造
APEXグラフは以下の要素で構成されます。
- グラフノード — APEX関数 / SOPバーブ / サブグラフ / サブネットのいずれか。ビューポート上では「点」に対応。
- ポート＆ワイヤー — ノード間の接続。バリアディックポート（複数接続可）とIn-placeポート（コピー不要な更新）の2種類がある。
- インプット／アウトプットパラメーター — グラフ全体の入出力を定義。
リグコンポーネントの主要な種類
APEX Autorig Component SOP から呼び出せるプリビルドコンポーネントが現代のリギングの中心です。
| コンポーネント | 役割 |
|---|---|
| FK Transform | スケルトンの各ジョイントをAPEXのTransformObjectノードにマッピングしてFK階層を構築 |
| Bone Deform | ジョイントの動きに応じてスキンジオメトリを変形 |
| Transform Driver | Root・COGなどの親コントロールを追加 |
| Spline | スプラインベースのスパイン（背骨）セットアップ |
| Multi IK | 腕・脚などのIKチェーン（複数セグメント同時対応） |
| Twist | アッパーアーム・フォアアームのツイスト分散 |
| IK/FK Blend | IKとFKをブレンドするアブストラクトコントロール |
| Reverse Foot | ヒール・つま先・ティルト付きのリバースフットセットアップ |
| Limb（H21） | 3ノードIKチェーン＋ツイスト・クラビクル・IK/FKブレンド統合版 |
| Hand（H21） | FK/IK指セットアップ |
| Foot（H21） | ヒール・つま先・タイルト＋FK/IK toe 統合版 |
リグを組み立てる4つのアプローチ
①APEX Network ViewでノードをGUI操作 — ドラッグ＆ドロップでグラフを手動構築。低レベルな制御が必要な場合向き。
②APEX Script — PythonライクなDSLでAPEXグラフをコードで生成。APEX Script SOPやAPEX Autorig Component SOPのコードエリアに記述。
③Autorig Builder — APEX Autorig Builder SOPでビューポートインタラクティブにコンポーネントを配置し、完全なリグを素早く組み上げる最も直感的な方法。
④プリビルドコンポーネントをSOPネットワークで積み重ねる — 上記コンポーネント一覧のSOPをチェーンでつなぎ、段階的にリグを構築。チュートリアル的なアプローチとして公式ドキュメントでも推奨。
ネットワークの典型的な流れ
Electra SOP
└─ Attribute Delete (タグ除去)
└─ Attribute Adjust Tags (ガイドタグ付与)
└─ APEX Pack Character SOP (.shp / .skel をパック)
└─ APEX Autorig Component: FK Transform (.rig 追加)
└─ APEX Autorig Component: Bone Deform
└─ APEX Autorig Component: Transform Driver (Root/COG)
└─ APEX Autorig Component: Spline (Spine)
└─ APEX Autorig Component: Multi IK (Arms/Legs)
└─ APEX Autorig Component: Twist
└─ APEX Autorig Component: IK/FK Blend
└─ APEX Autorig Component: Reverse Foot
└─ APEX Scene Animate SOP ← アニメートステートで操作
リグロジックの追加（各Autorig Component SOP）と実際の評価（Scene Animate SOP）が分離しているのがAPEXの設計上の特徴です。
めちゃくちゃ正確な仕様に基づいた回答が返ってきました。適当なハルシネーションで適当なコードを書く前に、自分でリファレンスを引く。これぞ求めていたMCPの姿です。えらい！
機能テスト２（Solaris/USDでのシーン構築）
前回はSOPの初歩的なテストで苦戦しましたが、今回はより高度なLOP（Solaris）のノード構築に挑戦させます。
Houdiniのstage (LOP) に、Sublayer、Reference、Transform、Karma Render Settingsノードを作成し、それらを直列に繋いでください。SOPからは先ほど作成した岩のノードを持ってきて下さい
結果。
岩のノードは `/obj/rock_generator/OUT` ですね。LOP用のノードカードを確認します。`/stage` が存在します。dry_run で構成を検証してからビルドします。検証OK。本番ビルドします。`/stage` に5ノードを直列で構築しました。
- **SOP Import** (`rock_import`) → `/obj/rock_generator/OUT` から岩を読み込み
- **SubLayer** (`sublayer1`) → SOP Importのレイヤーをサブレイヤーとして合成
- **Reference** (`reference1`) → シーングラフへの参照
- **Transform** (`transform1`) → USDプリムのトランスフォーム編集
- **Karma Render Settings** (`karma_render_settings`) → レンダー設定（display/renderフラグ有効）
警告が2つあります。`rock_import` はセーブパス未設定（実運用時は `$HIP` パスを設定推奨）、`karma_render_settings` はカメラ `/cameras/camera1` が未存在なので、カメラLOPを追加するか既存のカメラパスを指定してください。
複数回のツール呼び出しが走り、見事にLOPネットワークが構築されました！
エラーも出ていますが、それはこちらがカメラを作れと言っていないからで、きちんと返信コメントではカメラが未存在ですと報告してくれます。その後、カメラと照明を３つ接続して下さいと命令すると。。
カメラのノード位置はいいのですが、照明はKarmaの下に配置されてしまいました。加えて、座標がカメラ・照明とも原点にセットされています。美しい配置にしてほしいという気持ちはありますが、ここはまだ伸び代がありそうです。プロンプトでもっと具体的に指示すれば改善可能な範囲かと思います。
機能テスト３（ダイナミクス）
前回全然ダメだったDOPはどうでしょう
SOPでの作業。ダイナミクスシーンを作成します。
岩を10個にコピーし、岩10個を上空の位置でバラバラに配置。重力で地面に落下させるDOPネットワークを作成して下さい
行けるか・・・！？
別タスクで実行したからか。rock_generatorは無視されました（笑）
けど前回のような過ちは繰り返していません。
※そして、地味に日本語コメントが全てのノードに付与されています。これは人間を超えてます
DOPもきちんとコンテキストを理解しています
できた！！！岩が落下しました！！！
すごすぎる。
他にも試したいことは色々ありますが、時間がいくらあっても足りないのでこの記事に載せる作例は３例で止めておきます。
まとめ
今回試した healkeiser/fxhoudinimcp は、現時点でかなり高品質なHoudini MCPです。
まさにこれが欲しかった！すごい！
SOPの単純作業だけでなく、SolarisのUSDパイプラインや、APEX、VEXコードの生成、Cook時間のプロファイリングまで、Houdiniの複雑さをAIに理解させるためのコンテキストツールがかなり詰め込まれています。
特にエラーが起きたら自分でノードの状態を取得して修正する。というループが回りやすくなっている点は、前回のツールからの決定的な進化と言えます。まだまだAI側のコンテキストウィンドウやプロンプトの工夫に依存する部分はありますが、数年後には、プロンプト一発でベースセットアップ完了という未来が到来すると思わせてくれるポテンシャルがあります。
Houdini MCPはHoudini22のKeyNoteのAPEXのMCPとしても登場しており、今後も更なるMCP接続でのオーケストレーションが期待できます。
導入も非常に簡単になっているので、Houdiniユーザーはぜひ一度お試しを！