Claude CodeとUnity/Blenderの連携で直面した壁 〜軸の違いとコンテキスト制限〜

はじめに

以前の記事でも少し触れましたが、Claude CodeにBlenderやUnityを操作させて、自動で3Dモデルを作ったりムービーを作成したりする試みをしています。

アイデアとしては非常に面白くて、実際にある程度は動いてくれるのですが…やってみると思った以上に「壁」が多かったです😅

今回はその中でも特にハマった2つのポイント、「BlenderとUnityの軸の違い」と「コンテキスト制限・5時間制限」について実体験をまとめます。同じことをやろうとしている方の参考になれば幸いです。

BlenderとUnityで「軸」の扱いが全然違う

最初にハマったのがこれです。BlenderとUnityでは、3D空間の「上方向」の定義が異なります。

Blenderで「上を向いて立っているキャラクター」を作っても、そのままUnityに持ち込むと横に倒れた状態になります。これはBlenderのZ軸がUnityではY軸に相当するためです。

Claude Codeに「BlenderでモデルをエクスポートしてUnityにインポートして」と依頼すると、最初はこの変換を考慮せずにそのまま配置してしまいます。結果、意図とは全く違う向きにオブジェクトが出現します😂

FBXエクスポート時の設定が鍵

対策として、BlenderからFBXエクスポートする際に軸の変換設定を明示的に指定する必要があります。

# Blender Python API でFBXエクスポートする場合の設定例
import bpy

bpy.ops.export_scene.fbx(
    filepath="/path/to/output.fbx",
    axis_forward='-Z',   # Blenderの-Z → Unityの前方向
    axis_up='Y',         # BlenderのY → UnityのUp方向
    apply_unit_scale=True,
    apply_scale_options='FBX_SCALE_ALL'
)

この axis_forward='-Z' と axis_up='Y' の指定が重要です。Claude Codeにスクリプトを書かせるときも、この設定を明示的に含めるよう指示しないと、正しいエクスポートができませんでした。

スケールの問題もある

軸だけでなく、スケールも問題になります。Blenderのデフォルト単位は「メートル」ですが、FBXの仕様上100倍されてUnityに入ってくることがあります。

// Unity側でスケールを補正する場合（C#）
// FBXインポート設定で Scale Factor を 0.01 に変更するか、
// スクリプトでTransformを調整する

transform.localScale = new Vector3(0.01f, 0.01f, 0.01f);
// ↑ これを毎回手動で直すのは大変なので、FBXインポート設定を変えるのが本来は正解

Claude Codeはこういった「ツール間の暗黙のルール」を最初から知っているわけではないので、細かく指示を出す必要があります。これが次の問題につながっていきます。

細かい修正を繰り返すとすぐにコンテキスト制限へ

軸の問題を修正してもらうために「少し左に傾いてる」「スケールが大きすぎる」「今度は回転がおかしい」と細かい修正依頼を繰り返していると、あっという間にコンテキスト（会話の記憶容量）が満杯になります。

Claude Codeには一度の会話で記憶できる量に上限があり、長い会話を続けていると「コンテキスト上限に近づいています」という警告が出始めます。そうなると新しい指示が古い情報を押し出してしまい、せっかく伝えた細かい設定を「忘れて」しまうことがあります。

5時間制限にも引っかかった

さらに追い打ちをかけるのが、Claude Codeの5時間あたりの使用制限です。

Proプランでは一定の時間帯に大量のリクエストを送ると、制限に到達して一時的に使えなくなります。3DCG系の作業はBlenderのPythonスクリプトを何度も試行錯誤するため、短時間でリクエスト数がかさんでしまいます。

うまく付き合うためのコツ

これらの壁を経験して、少しずつコツがわかってきました。

• 作業を細かく分割する：「Blenderでモデル作成」「FBXエクスポート」「Unityへのインポートと配置」を別々の会話セッションで依頼する
• 毎回の会話冒頭に前提条件をまとめて伝える：「Blender→UnityはZ-upをY-upに変換、スケールは0.01」など
• スクリプトを保存しておく：うまくいったBlender Pythonスクリプトはファイルに保存して、次回はそれをベースに修正依頼をする
• 制限に引っかかったら休憩：5時間制限は時間が経てばリセットされるので、無理に続けない

特に「作業を分割して、毎回前提を伝える」は効果的でした。コンテキスト容量の節約にもなりますし、Claude Codeも混乱しにくくなります。

【追記】軸の違いは、1枚の表にしてしまえば済む

本文で書いたとおり、BlenderとUnityでは軸の扱いが違います。作業のたびに考えると必ず間違えるので、変換の規則を1枚にまとめてしまうのがいちばん確実でした。

実際の変換は、位置なら (x, y, z) → (x, z, y) の入れ替えが基本です。ただし手系が違うため、これだけだと鏡像になります。どこか1軸の符号を反転させる必要があり、どの軸を反転させるかは書き出し設定によって変わります。

なお、この変換規則を最初に文字で渡しておくと、AIとのやり取りでも軸の話で往復しなくなります。毎回の会話で説明し直すのではなく、プロジェクトの中に規則をファイルとして置いておくほうが効きました。

【追記】いちばん効いたのは「会話でやらない」ことだった

本文ではコンテキスト制限に何度もぶつかった話を書きました。その後いろいろ試して、対策としていちばん効いたのは設定を細かく詰めることではなく、作業のかたちを変えることでした。

GUIを操作させると、会話がすぐ埋まる

「ここをクリックして」「この値を変えて」というやり取りは、1回あたりは短くても、画面の状態を毎回説明し直す必要があるため、往復のたびに文章が積み上がります。細かい修正を繰り返すとすぐ上限に届いたのは、これが理由でした。

スクリプトに落とすと、往復そのものが減る

同じ作業をコマンドラインから実行できるスクリプトにしておくと、やり取りが「スクリプトを直す」「走らせる」「結果の数字を見る」の3つになります。画面の状態を説明する必要がなくなるぶん、会話が短くなります。

実際、Blenderの作業をPythonスクリプトから段階的に組み立てる形に変えたところ、同じ内容を扱っていても会話の消費がはっきり減りました（Geometry Nodesの実践編ではこの形で進めています）。別の回では、計測用のプログラムをGUIから切り離してコマンド1つで走る形にしたことで、離れた場所からでも作業できるようになりました。

最後の行が、思っていた以上に効きました。あとから「あのときどう設定したか」を思い出す必要がなくなります。

【追記】いま実際にやっている進め方

本文の「コツ」を、その後の経験を踏まえて整理し直すとこうなります。

1. 危ないところを先に、小さく試す。うまくいくか分からない部分を最初に確かめると、あとで大きく作り直さずに済みます
2. 手で確かめる部分と、任せる部分を分ける。数値の変換規則のように「合っているかを1点で確認できる」ものは任せやすく、見た目の良し悪しは手元で判断したほうが速いです
3. 1つの会話に1つの目的。目的が変わったら会話を切り替えます。前半の文脈を引きずったまま別の話を始めると、消費が早いわりに精度が落ちます
4. 結果は必ず自分で走らせて確認する。画面上は成功していても、想定と違う経路で動いていることがあります

4番目については、別の回で実際に痛い目を見ました。ベンチマークが「動いた」ので結果を採用しかけたのですが、ログを確認したところ意図していた仕組みをまったく通っていなかったことが分かりました。「動いた」と「意図した経路で動いた」は別——これはAIに任せるかどうかに関係なく効く教訓でした。

まとめ

Claude CodeとUnity/Blenderの連携は、可能性は大きいものの、ツール間の仕様の違いやAIの制限を理解した上で進める必要があります。

特にBlenderとUnityの軸・スケールの違いは、最初に一度ちゃんと把握しておくと後がずっと楽になります。また、コンテキスト制限や5時間制限も現実として受け入れて、「無理に長い会話を続けない」という戦略をとるのが結局は近道だと感じています😊

引き続きこの連携の試みは続けていくので、うまくいったことや新たな発見があればまた記事にします！

それでは、今回はここまで。ありがとうございました😊