スマホ動画1本をBlenderに投げ込めば、Mixamoリグの3Dキャラが勝手に動き出す。GitHubで公開2日148スターを集めた「mixamo-llm-mocap」は、GVHMRによる姿勢推定、仕様書ドリブンのリターゲット、そしてMCP経由でBlenderをAIエージェントが直接叩くという構成で、モーションキャプチャの前提を静かに書き換えている。

何が起きたか

GitHubで公開されたリポジトリ「squall01337/mixamo-llm-mocap」が、公開2日で148スターを集めた。機能はシンプルで、人が動いている動画を1本渡すと、Blender上で動くMixamoリグのキャラアニメを自動生成する。パイプラインの内訳は、GVHMRによる単眼動画からの3D姿勢推定、仕様(spec)ドリブンでのMixamoリグへのリターゲット、そしてMCP(Model Context Protocol)経由でBlenderをFK適用まで自動操作する、という3段構え。従来なら光学式モーキャプスタジオか、Rokoko等のスーツ、あるいはUnreal Engineの実験的機能に頼っていた工程を、コンシューマー端末とローカルツールだけで完結させに来ている。ナレーションでは「数百万円のモーキャプ機材が不要になる」と言い切られたが、少なくとも「1カット試す」段階でのハードルは、ほぼゼロに落ちた。

なぜこのニュースが重要か

注目すべきは148という数字そのものではなく、構成要素の組み合わせ方だ。GVHMRは単眼動画から世界座標系での人体姿勢を推定する研究成果で、Ahrefs上の検索ボリュームは月20と、まだアカデミア寄りのニッチ技術である。それを「Mixamoという既存の3Dキャラ資産流通プラットフォーム」と「Blenderという月間検索76,000のデファクトDCCツール」に接続した瞬間、研究の成果物が制作現場のワークフローに落ちてくる。研究→プロダクト→現場という距離が、MCPというプロトコルで一気に圧縮されたのが本質だ。個人開発者が単眼姿勢推定モデルをUEやMayaに繋ぐのはハードルが高いが、Blender+Python+MCPなら、AIエージェントがスクリプトを吐いて実行するだけで済む。オープンソースのDCCがAI時代のハブとして選ばれた、という文脈の傍証でもある。

技術的な深掘り

コードと仕様書の観点で興味深いのは、「spec-driven retarget」という設計思想だ。GVHMRが出力する骨格と、Mixamoのリグは、ボーン数もローカル軸の向きも一致しない。ここを手続き型スクリプトでベタ書きすると、キャラごとに壊れる。仕様書(spec)を中間層に挟むことで、LLMが「このボーンをあのボーンへ、この回転オフセットで」と宣言的に扱える。LLMは自然言語よりもJSON/YAMLスキーマの方が安定して吐けるので、これは正解の設計だ。もう一点はMCPの使い方。BlenderのPython APIは強力だが、AIエージェントが試行錯誤するとシーンが壊れる。MCPで操作を関数境界に閉じ込め、FK(Forward Kinematics)適用まで手順を固定化しているのは、「エージェントに自由を与えつつ、破壊的操作を防ぐ」実務的な妥協点だ。逆に言えば、IKソルバやフィジックスまで踏み込むのは次の課題として残る。足の接地滑り(foot sliding)問題は単眼推定の宿痾で、ここをどう仕様に落とすかが本プロジェクトの真価を決める。

経営者として次に取るべき動き

第一に、社内の3D/映像制作パイプラインで「モーキャプ外注費」と「アニメーター単価×工数」を棚卸しすること。仮に1カット5万円の外注を月20カット出しているなら、年1,200万円の変動費だ。ここが即座に検証対象になる。第二に、Blender+MCPを触れるTA(テクニカルアーティスト)を1名アサインし、2週間で自社IPキャラでの精度検証を回す。148スター段階のOSSは仕様変更が激しいため、フォーク前提で内部評価すべきだ。第三に、AIエージェントに「PC操作そのもの」を任せる設計の社内標準を作る。今回のMCP+Blenderはその最小事例で、同じパターンはFigma、Excel、CADにも波及する。エージェント運用の権限設計とロールバック手順を、今のうちに整備しておくのが最も効くレバレッジだ。