Claude Code で Houdini のパイプラインツールをつくってみた。エージェント型コーディングの実際の感触

2026年7月6日15 分で読めますLiang

いまネットにはエージェント型コーディングの話題があふれています。Claude Code、Cursor、Replit Agent——開発者の数だけ体験談があります。その多くは同じ筋書きをたどります。「週末だけでスタートアップを vibe コーディングした」とか「AI がコードベースの 90% を書いた」とか。

私は違う話をしたいと思います。ほかの話が間違っているからではなく、私の話は、ほとんど誰も書いていない文脈から来ているからです。VFX パイプラインです。

パイプライン TD とは何か、そしてなぜここで重要なのか

VFX スタジオのテクニカルディレクター（TD）は、アートとインフラが交わる場所にいます。最終的なショットをつくるのではなく、アーティストが最終的なショットをつくるためのツール、スクリプト、システムをつくるのが仕事です。ライティングアーティストに「Houdini のセッションを 200 個立ち上げずに、200 パターンを一晩でバッチレンダリングできない？」と聞かれたら——それはあなたの仕事です。

この仕事は本質的に、自動化、信頼性、そして領域固有の制約がテーマです。Houdini には独自の Python API があります。アセットの解決はもろい。レンダーファームとの連携はスタジオごとに違う。DCC（Digital Content Creation）ツールには、どの LLM も深く学習していないクセがあります。

エージェント型コーディングを評価するうえで、この文脈は重要です。一般的な CRUD アプリなら、AI は何百万もの例を見ています。PDG フックを使った Houdini のノード走査ルーチンを書くとなると、学習データはすぐに薄くなります。

ツール：Enso Executer

Enso Executer は、繰り返し発生していた問題を解決するためにつくった Houdini のバッチ処理ツールです。アーティストは、決められた一連の Houdini 操作——ノードのクック、ファイルの書き出し、レンダリング——を複数の hip ファイルに対して、1 つずつ手作業で介入することなく実行する必要がありました。

最終的に採用したアーキテクチャ：

Python + Flask のバックエンド
コア処理ロジックにドメイン駆動設計（DDD）
持ち運びやすいデプロイのための Docker
ヘッドレス実行のための Houdini の hython インタプリタ

Houdini の文脈で DDD というと大げさに聞こえるかもしれません。でもそうではありません。このドメインは本当に複雑です。Job（何を実行するか）、Executor（どう実行するか）、Asset（何に対して操作するか）がある。これらの関心事を分けておけば、スタジオがレンダーエンジンやアセットの命名規則を変えても、ツールが崩壊しません。

Claude Code を投入した場所

AI エージェントにゼロから全体の骨組みをつくらせたわけではありません。それは失敗だったでしょう。領域固有のセットアップが多すぎて、一歩ごとに人の手による検証が必要だからです。

代わりに、特定のボトルネックで Claude Code を戦術的なペアプログラマーとして使いました。

ボトルネック 1：Executor の抽象化。 「何を実行するか」と「どう実行するか」の間にきれいなインターフェースが必要なのはわかっていました。問題を自然言語で説明し、関連するドメインエンティティを貼り付けて、クラス階層の叩き台を頼みました。Claude は 4 つの案を出してきました。2 つは私の制約に合わず（私がつくるつもりのないジョブキューを前提にしていた）、1 つは惜しく、1 つが正解でした。正解の案を採用して調整しました。このやり取りで、ホワイトボードの前で過ごす時間が 2 時間ほど浮いたと思います。

ボトルネック 2：hython のサブプロセスとの格闘。 Docker の中で hython を正しく動かす——環境パス、ライセンスの解決、stdout の取得——のは面倒で、ドキュメントも十分ではありません。半分動くスクリプトがあったので、Claude にデバッグを頼みました。PATH の順序の問題と、HOUDINI_PATH 環境変数の設定漏れを見つけてくれました。私が 40 分間見落としていたものです。ツールがやるべきことを、ツールがやってくれたわけです。

ボトルネック 3：テストフィクスチャ。 DDD のエンティティ用にフィクスチャのファクトリを書くのは退屈で、ミスも起きやすい作業です。エンティティの構造を一度説明して、フィクスチャのモジュールを生成してもらいました。一発で正しく出てきました。エッジケースのフィクスチャを 3 つ手で追加しました。所要時間は 1 時間ではなく 15 分でした。

エージェントが間違えたこと（そしてそれが重要な理由）

ここは、エージェント型コーディングの記事のほとんどが飛ばす部分です。

エージェントは hou.Node.cook() のシグネチャをハルシネーションしました。この関数自体は Houdini の Python API に存在しますが、Claude のバージョンはキーワード引数が間違っていました。おそらく古いバージョンの API や似た DCC ツールの学習データから補間したのでしょう。コードはもっともらしく見えました。ある条件では静かに失敗し、別の条件では派手に失敗するものです。正しいシグネチャを覚えていなかったら、バグを出荷していたでしょう。

教訓は「AI はダメだ」ではありません。教訓はこうです。領域の専門知識の価値は、エージェント型コーディングで消えるのではなく、移動する。 従来のワークフローでは、専門知識はコードを書くことに使われました。エージェント型のワークフローでは、専門知識はコードを検証することに使われます。何が正しいのかを知っている人は、依然として必要なのです。

これは「速さではなく、続けられること」で書いたことにそのままつながります。ボトルネックは生成ではなく、判断です。エージェント型コーディングは、テクニカルディレクターの必要性をなくしません。問題から下書きまでの時間を圧縮し、判断を前面に押し出すのです。

本当のワークフローの変化

このツールでしばらく開発してみて、変化をこう表現できます：

以前： 空のファイルから始めて、構造を考え、ボイラープレートを書き、それからようやく面白い問題にたどり着く。時間の 6 割ほどはセットアップと保守的なコードに費やしていました。

いま： 面白い問題をすぐに説明する。ボイラープレートと下書きはエージェントが処理する。私はレビュー、検証、アーキテクチャ——つまり本当に領域知識が必要な部分——により多くの時間を使う。

これは「AI が私のコードを書く」ということではありません。タスクの配分が変わったのです。パイプライン TD の仕事は、構文や足場づくりよりも、システム思考と正しさの検証が中心になっていきます。良い取引です。ただし、本当に正しさを判断できるならの話です。

パイプライン TD にとって具体的に意味すること

VFX やゲームのパイプラインで働いていて、まだこうしたツールを使い始めていないなら、今すぐ始めてください。ただし、意図を持って始めること。

実践的な提案を 3 つ：

まずは退屈な部分にエージェントを使う。 フィクスチャの生成、設定ファイルのパーサー、繰り返しの多いスキーマ定義。領域的に繊細なロジックを任せる前に、どこなら信頼できるのか感触をつかみましょう。
すべてのプロンプトに領域の文脈を書き込む。 「ジョブランナーを書いて」ではなく、「hython を使い、HOUDINI_PATH 環境変数を扱い、ライセンスサーバーにアクセスするため network-mode host で Docker 内で動くジョブランナーを書いて」と言うこと。あなたの技術スタックそのもので学習していないモデルから役立つ出力を得るには、具体性が鍵です。
エージェントの出力は、コードは書けるが Houdini を知らない新人の下書きとして扱う。 その前提でレビューすれば、API のハルシネーションを早く見つけられます。

これからについて

ツールは急速に進化しています。Claude Code のコンテキストウィンドウは、そこそこの規模の Python コードベースを収められるほど大きくなりました。ツールの利用やコードベースのインデックス化が進めば、「Houdini を知らない新人」問題は小さくなっていくでしょう。

しかし、根本的な力学がひっくり返ることはありません。クリエイティブパイプラインのツールは、ほぼ定義上、学習データの中で過小評価されている領域固有のレイヤーに存在します。この分野でコードを書き、検証し、アーキテクチャの判断ができるパイプライン TD の優位性は、消えるどころか、より集中していきます。

新しいリスクは、AI に仕事を奪われることではありません。エージェント型のワークフローに適応しない TD が、適応した TD に後れを取ることです。AI が仕事をしているからではなく、適応した TD のほうが早く出荷し、本当に大事な部分により多くの時間を使えるからです。

これが、Houdini パイプラインの内側から見た本当の話です。

Enso Executer はオープンソースです。似たようなパイプラインツールの課題に取り組んでいて情報交換したい方は、GitHub で声をかけてください。