AIにBlenderを操作させると、3回に1回は画面を見に行く

コードなら、AIは自分で正しさを確かめられる。テストを走らせればいいし、curl でステータスコードを見ればいい。出力がテキストなので、読んで判断できる。

3Dはそうはいかない。頂点座標が想定どおりでも、見たら破綻していることがある。この「見ないと分からない」性質が、AIの働き方にどう出るのかが気になっていた。

MCP経由でBlenderを操作した33日ぶんのログが手元にあったので、数えてみた。

コードを206回、画面を60回

内訳はこうなった。

AIがBlenderに対して実行した操作の内訳

execute_blender_code（Pythonコードを送って実行する）が206回。get_viewport_screenshot（ビューポートを撮って画像として受け取る）が60回。シーン情報の取得が13回、オブジェクト情報の取得が4回。

コードを3.4回実行するごとに、1回は画面を見に行っている計算になる。

この比率は、他の作業と比べるとかなり高い。同じ期間の他のプロジェクトでは、AIが結果を確認する手段はほぼコマンドの標準出力で、画像として受け取ることはまず無い。Blenderを触っているときだけ、AIは目で確かめている。

数値が合っていても、見ると破綻している

なぜ見に行かないと進めないのか。これは実例で説明したほうが早い。

別の作業で、写真から推定した姿勢を3Dモデルに反映する処理を作っていたとき、首の向きがおかしくなるバグが出た。デバッグのとき、私は関節の座標を実測データと突き合わせて「数値は一致している」と確認し、直ったと報告した。

実際には、モデルの頭が真上を向いていた。

数値の一致は「入力どおりに計算されている」ことしか保証しない。その計算の前提（どの軸を上とみなすか、親ボーンの回転をどう合成するか）が間違っていれば、数値は完璧に一致したまま姿勢だけが壊れる。しかもこの手のバグは、値を見ている限り異常に見えない。

同じ誤りを2回繰り返してから、運用ルールにこう書いた。

ポーズ／3D表示／サムネ等の見た目に関わる変更は、landmark等の数値一致だけで「OK」と判断・報告しない。該当部位を拡大レンダリングして実描画を目視確認してから結論を出すこと。

3.4回に1回という比率は、この方針が実際の作業に現れた結果でもある。

分類も、境界では目で見るしかない

もう1つ、モーションキャプチャのデータからポーズ素材を量産する作業でも同じことが起きた。

大量のクリップから「立ち」「座り」「寝そべり」といった分類を自動で付ける処理を書いた。腰の高さや接地している足の数といった幾何的な特徴量で判定するもので、大半は正しく分類される。

問題は境界だった。しゃがんでいるのか座っているのか、片膝をついているのか立っているのか。こういうものは、閾値をどこに置いても必ず取り違える。特徴量としては連続的に変化しているので、機械的な線引きに意味がない。

結局、生成した接地状態の可視化画像を1枚ずつ見て確認する工程を、手順に組み込むことにした。

out/contact.png を実描画で確認してから commit。幾何分類は境界で誤る。数値一致だけで OK としない。

自動化を諦めたわけではなくて、自動化した結果を人が見る工程まで含めて手順にした、という言い方が近い。

MCP経由でBlenderを触るときの実際

技術的な話も少し書いておく。BlenderをMCP経由で操作するとき、AIができるのは基本的に「Pythonコードを送って実行する」ことだ。Blender側にPython APIがあるので、原理的には手作業でできることはほぼ全部できる。

import bpy
obj = bpy.data.objects["Armature"]
bone = obj.pose.bones["Head"]
bone.rotation_mode = 'XYZ'
bone.rotation_euler = (0.1, 0.0, 0.0)
bpy.context.view_layer.update()

これを送って実行し、次にビューポートを撮って結果を見る。この往復が206回と60回の中身になる。

やってみて分かった注意点が3つある。

1回のコードを大きくしすぎない。 まとめて実行すると、失敗したときにどこで壊れたか分からなくなる。3Dの状態はコマンドの成否では判定できないので、小さく実行して都度見るほうが結局速い。

シーンの状態を毎回取り直す。 オブジェクト名やコレクションの構成は、前の操作で変わっていることがある。AIは前提を覚えているが、その前提が正しいとは限らない。get_scene_info が13回しか呼ばれていないのは、正直に言えば少なすぎたと思う。

画像で確認する角度を指定する。 既定のビューポートは、確かめたい部位が見えていないことが多い。首の向きを見たいのに全身が小さく映っているスクリーンショットには、ほとんど情報が無い。拡大して該当部位を映すところまで指定して、はじめて確認になる。

この数字の限界

いくつか断っておく。

283回というBlender関連の操作は、すべて1つのプロジェクトのものだ。作業内容にかなり依存する数字なので、モデリング主体なのかリギング主体なのかで比率は変わるはずだ。

また、get_viewport_screenshot が60回というのは「AIが撮った回数」であって、私が自分の目でBlenderの画面を見た回数は含まれていない。実際には、AIに撮らせるより自分で画面を見たほうが早い場面が多かった。ログに残る比率は、人間側の確認を数えていない。

そして、この作業でどれだけ手戻りが減ったのかは測れていない。目視確認を挟むルールを作る前と後で比較したいところだが、前の期間のログが十分に無い。

見えない作業ほど、確かめ方を先に決める

まとめると、AIに3Dソフトを操作させる作業で効いたのは、道具の使い方より確かめ方の設計だった。

テキストで結果が返る作業では、確かめ方は自然に決まる。テストがあり、終了コードがあり、標準出力がある。3Dにはそれが無いので、「何をもって正しいとするか」を先に決めておかないと、AIも人間も数値の一致で満足してしまう。

拡大してレンダリングする。可視化画像を1枚ずつ見る。手間のかかる方法だが、これを工程に入れてからは同じ誤報告が起きていない。3.4回に1回という比率は、その手間の実測値ということになる。