やっほー、ナオ・ヴェルデだよ。ボクは音楽と開発技術担当です。今回は、CVPR 2026でOral発表されたマーカーレス・モーションキャプチャ研究「MAMMA: Markerless Accurate Multi-person Motion Acquisition」を、論文の数式や精度比較ではなく、公開リポジトリの中身から掘ってみた。
タイトルだけ見ると「マーカーレス高精度複数人モーションキャプチャ」しかも詳細を読むと「iPhone 4台で本格モーキャプ!?」という夢のある話に見える。実際、MAMMAのREADMEには4カメラのクイックデモがあり、キャリブレーション例にもiPhone屋外撮影らしき設定が登場する。プロジェクトページでも、iPhone 4台による屋内・屋外の復元例が紹介されている。
ただし、ここで大事なのは、「iPhoneで撮れる」ことと、「iPhoneだけで処理まで完結する」ことは別だという点だ。リポジトリを読むと、MAMMAはスマホアプリ的なお手軽ツールではなく、複数カメラ映像を入力し、GPU搭載Linux環境で本格的に人体モデルへフィッティングする研究・制作向けパイプラインとして構築されていることが見えてくる。
ただし、ここで大事な注意点がある。「iPhoneで撮れる」ことと、「iPhoneやMacだけで全部処理できる」ことは別の話だ。MAMMAはかなり本格的なGPU処理を前提にした研究コードであり、実用検証するなら、撮影環境だけでなく処理環境まで含めて考える必要がある。今回は、技術紹介だけでなく、実際に試すならどうするかまで掘ってみたよ！
リポジトリ全体は「5段階のパイプライン」として組まれている
MAMMAのREADMEを読むと、パイプラインはかなり明確に分かれている。
ma_cap → ma_masks → ma_2d → ma_3d → ma_vis
最初の ma_cap はマルチビューキャプチャの読み込み。次の ma_masks は人物ごとのセグメンテーション。ここではSAMやYOLOが使われる。続く ma_2d はMammaNetによる2Dランドマーク検出で、ma_3d では複数ビューからSMPL-Xの3D人体モデルを最適化する。最後の ma_vis は、カメラごとのオーバーレイやインタラクティブなシーン表示を担当する。
この構成が良いのは、研究コードにありがちな「巨大な推論スクリプト一発勝負」ではなく、処理が工程ごとに分解されているところだ。撮影データの読み込み、マスク生成、2D検出、3D最適化、可視化が分かれているので、どこで失敗したかを追いやすい。制作現場では、ここがかなり重要になる。
モーションキャプチャの検証では、失敗したときに「撮影が悪いのか」「セグメンテーションが崩れたのか」「2Dランドマークが外れたのか」「3D最適化が破綻したのか」を切り分けられないと、全部が黒い箱になってしまう。MAMMAの構成は、その黒箱をいくつかの引き出しに分けてくれている。
クイックデモはある。けれど本番導入の前に“火がつくか”を見るためのもの
READMEには、約56MBの4カメラサンプルをダウンロードして、quick.yaml で走らせるクイックデモが用意されている。これはかなりありがたい。
ただし、このデモは「これで制作に即投入できます」という意味ではなく、まず環境が正しく構築できているかを確かめるための入口と見るのがよさそうだ。MAMMAには python -m inference doctor という環境確認コマンドも用意されている。重みファイルや環境変数が正しく見えているかを確認するためのものだ。
実際に試すなら、最初は自分のiPhone映像を入れる前に、必ず公式デモを通した方がいい。公式デモで失敗するなら、撮影データ以前に環境ができていない。公式デモが通ってから、初めて自前素材の品質やカメラ配置を疑う段階に進める。
GUIは“制作現場向けの操作盤”としてかなり重要
リポジトリを見て面白いのが、MAMMAにはブラウザGUIが用意されていることだ。GUI READMEによると、このUIはローカル単一マシン上でMAMMAのパイプラインを実行・監視するためのもの。中身はFlaskバックエンド、React + TypeScript + Tailwindのフロントエンド、SQLiteのDBという構成になっている。
ここで大事なのは、GUIが別物の簡易版ではなく、CLIと同じ inference ランナーを呼び出す上に、UIとジョブ管理を載せている点だ。つまり、技術担当がCLIで実行する処理と、制作担当がブラウザから投げる処理が、同じパイプラインに乗っている。
これはスタジオ運用を考えるとかなり大きい。技術担当だけがコマンドを叩ける状態では、制作の現場には広がりにくい。ディレクターやアニメーターが、どのタスクが走っているのか、どこで失敗したのか、どの出力を見るべきなのかを確認できる必要がある。
MAMMA GUIには、Captures、Tasks、Results、Databaseといった画面が用意されていて、キャプチャ設定、タスク投入、進捗確認、ログ確認、出力ファイルのブラウズ、過去実行のDB管理ができる。これは単なるデモ画面というより、ローカル処理サーバー用のミニ管理コンソールに近い。
ただし、GUIはデフォルトで認証なし、単一ユーザー向け、127.0.0.1 バインドのローカルツールとして設計されている。ファイルAPIが強い権限を持つので、スタジオLANにそのまま公開するのは危ない。使うなら、SSHトンネルやVPN、必要に応じてnginxやBasic認証を前段に置くのが現実的だ。
便利な操縦席ほど、鍵をかける。これはGPUサーバー界の戸締まり作法である。
実行エンジンはconda、Docker、Apptainerをステップごとに選べる
GUI READMEで特に実用的だと感じたのは、各パイプラインステップの実行エンジンとして conda、docker、apptainer を選べることだ。これは、MAMMAが研究室やクラスタ、制作サーバーでの運用を想定していることを示している。
デフォルトは conda。ホスト側の mamma 環境でそのままPythonスクリプトを動かす方式だ。一方、Dockerを選ぶと、ステップごとにビルドしたDockerイメージを使って docker run --gpus all で実行する構成になる。Apptainerは、HPCや研究機関のクラスタでよく使われる .sif ファイル向けだ。
この設計はかなり現実的だ。全部を1つの環境に詰め込むと、SAM、YOLO、MammaNet、SMPL-X最適化、可視化、GUIが同じ鍋の中で煮えたぎる。依存関係がぶつかると、どの具材が焦げたのか分からなくなる。そこで、重い工程や依存が強い工程をコンテナ化できるようにしている。
特に segmentation/Dockerfile を見ると、ma_masks、つまりSAM2/SAM3によるセグメンテーション工程だけを切り出すDockerfileが用意されている。ベースイメージはNVIDIA CUDA 12.6.2 + cuDNNのUbuntu 22.04で、Python 3.12環境をmicromambaで作り、PyTorchのCUDA 12.6 wheelを入れ、SAM2やYOLOなどの依存を入れる構成になっている。
これはかなり示唆的だ。MAMMA本体のINSTALLではPython 3.11とCUDA 12.4がターゲットとされている一方、セグメンテーション工程は別コンテナでCUDA 12.6系として構築されている。つまり、MAMMAは「全部同じ環境で一枚岩に動かす」だけでなく、工程ごとに実行環境を分ける設計も持っている。
制作現場で運用するなら、この分離は助かる。人物マスク生成はDocker、メインパイプラインはconda、クラスタ環境ではApptainer、という混在も考えられる。小さなロボットたちが、それぞれ得意な作業場で働く感じだ。
ハードとして何を用意する必要があるのか
ここからが、実際に試したい人にとっていちばん大事な部分だ。
まず、MacBook単体で完結するものとして考えない方がいい。Apple Silicon Macは撮影データ整理、SSH接続、GUI操作、結果確認、記事執筆にはとても向いている。でもMAMMA本体の推論や最適化を回す主役にはなりにくい。MAMMAのINSTALLはPython 3.11とCUDA 12.4をターゲットにしており、detectron2 や pytorch_sdf のCUDAカーネルをビルドするためにCUDA toolkitが必要になる。
現実的には、NVIDIA GPUを搭載したLinuxマシンが必要だ。最初の検証なら、クラウドGPUを借りるのが速い。RunPod、Lambda、Vast.ai、GCP、AWS、Azureなど、CUDA環境を自分で管理できるGPU VMが候補になる。Google Colabでも短いクイックデモの挑戦はできるかもしれないが、DockerやCUDA toolkitの固定、重みファイル管理、セッション切断を考えると、継続的な制作検証の足場としては少し不安定だ。
スタジオや研究室で継続的に試すなら、Ubuntuを入れたGPUワークステーションがいちばん素直だ。RTX 4090やRTX 6000系のようなNVIDIA GPU、大容量NVMe、十分なRAM、そして撮影素材を置く共有ストレージがあると扱いやすい。最初からProxmoxで組むこともできるが、初回検証ではベアメタルUbuntuの方がトラブルは少ない。
では、VRAMはどれくらい必要なのか。ここはREADMEに明確な推奨値がないので、断定は避けたい。ただ、構成を見る限り、8GB級GPUで気軽に回すタイプではなさそうだ。MAMMAはSAM/YOLOで人物マスクを作り、MammaNetで2Dランドマークを推定し、さらにSMPL-X最適化まで行う。公式のクイックデモは30フレームに制限されており、1 GPUで約5分のスモークテストとされている。つまり、短いデモなら12GB級GPUでも挑戦できる可能性はあるが、自前のiPhone 4台素材をまともに検証するなら、RTX 3090/4090のような24GB VRAM級を現実的な目安にしたい。スタジオで複数シーケンスを回すなら、48GB級GPUがあるとかなり安心だ。入口はiPhoneでも、台所にはそれなりに大きな窯がいる。
撮影側のハードは軽くできる。でもルールは必要
iPhone 4台で試すなら、必要なのはiPhoneだけではない。三脚、十分なストレージ、同期用のクラップやLED、安定した照明、キャリブレーション用の手順が必要になる。
カメラ配置は、被写体を囲むようにするのが基本だ。真正面、左右、背面のように置いてもいいし、斜め方向を混ぜてもいい。重要なのは、身体の片側が全カメラで隠れ続けないこと。2人の接触を撮るなら、腕や足が交差するので、なおさら死角を減らす必要がある。
撮影時には、フレームレートを揃え、露出やホワイトバランスをなるべく固定し、足元を切らない。最初にクラップやLED点滅など、全カメラで見える同期イベントを入れる。カメラは撮影中に動かさない。できれば三脚や固定治具を使う。
特に足元は重要だ。足が床を滑ると、一気にCGっぽく見える。キャラクターのリアリティは顔に宿ると思われがちだけど、実は床との約束を守っているかどうかでかなり決まる。
最初の実験は“短い素材”から始めるべき
MAMMAを試すなら、最初から3分のダンスを処理しない方がいい。最初は5秒から10秒で十分だ。
立つ、歩く、振り向く、しゃがむ、軽く手を振る。2人なら、近づく、手をつなぐ、肩に手を置く、軽く押す、支える。このくらいの短い動作で、マスクが崩れないか、ランドマークが飛ばないか、足元が破綻しないか、接触がそれらしく出るかを見る。
短い素材なら、失敗してもすぐ撮り直せる。長尺で失敗すると、原因の切り分けが湿った毛糸玉になる。技術検証は、最初から大作映画を撮らない。まずは箸でつまめるサイズの素材で、どこまで食べられるかを見るのがいい。
出力は完成品ではなく、モーション素材として見る
MAMMAがうまく動いたとしても、出力をそのまま最終映像に使えるとは限らない。SMPL-Xから自社キャラクターリグへのリターゲット、足元や手指の補正、視線や表情の追加、衣装や髪の処理、演出上の誇張は別工程として必要になる。
ここは期待値を正しく持ちたい。AI MoCapは完成品を吐き出す箱というより、モーション制作の下地を高速に作る装置だ。手付けゼロを目指すより、手付けの開始地点をぐっと先へ進める技術として見た方が、制作現場では使いやすい。
特にキャラクター表現では、現実の動きがそのまま正解とは限らない。ナオ・ヴェルデなら、少し跳ねる。少し溜める。音に合わせて、ちょっと余韻を残す。そういう演出の調味料は、最後に人間が振るのがいい。
ライセンスは必ず確認する
ここまでリポジトリを掘ってしまったのだけど、最後に避けて通れないのがライセンスだ。MAMMAのREADMEでは、ライセンスは非商用の科学研究目的とされている。つまり、商用MV、販売ゲーム、広告案件、収益化配信、企業プロダクトにそのまま使えるとは限らないんだ！
また、SMPL-X、SAM、YOLO、各種学習済み重み、データセットにも、それぞれ別の利用条件がある。MAMMA本体が動いたとしても、商用利用の判断は別問題だ。記事としては、ここを正直に書きたい。MAMMAは研究・検証・プロトタイピングにはかなり面白い。ただし、商用制作で使うなら、MAMMA本体、SMPL-X、使用モデル、データセット、出力物の扱いまでライセンス確認が必要だ。技術の扉を開ける鍵は、だいたいREADMEの下の方に小さく置いてある。
Nao Verdeの「もし試してみるなら」
ボクが実際にMAMMAを試すなら、まずクラウドGPUかベアメタルUbuntuマシンを用意する。MacBookは操作端末として使い、処理はNVIDIA GPUでVRAMを24GB以上を積んだLinux側に任せる。最初は公式クイックデモを通し、doctor コマンドで重みや環境変数を確認する。GUIも立ち上げて、ジョブ投入、ログ確認、出力ブラウズまでひと通り見る。
そのあと、自前のiPhone 4台素材を5秒から10秒だけ撮る。カメラは三脚固定、最初にクラップ、足元が見えるようにし、カメラ名とファイル名を丁寧に対応させる。キャリブレーションファイルも撮影セットごとに保存する。
結果を見るときは、まずマスク、次に2Dランドマーク、最後に3Dの接地と接触を見る。いきなりキャラクターにリターゲットしない。まずMAMMAの各段階がどこまで安定しているかを見る。ここで手応えがあれば、Blender、Unity、Unreal、DCCツールへの流し込みを考える。
スタジオで運用するなら、構成は「撮影はiPhoneや複数カメラ、処理はUbuntu GPUサーバー、確認はMacやWindowsのブラウザ」が現実的だ。Proxmoxを使うなら、Ubuntu VMにNVIDIA GPUをPCI passthroughして、その中でMAMMAを動かす。GUIは便利だけれど、認証なしのローカルツールなので、公開はSSHトンネルやVPN越しにする。
MAMMAは「スマホだけで完結するモーキャプアプリ」ではない。けれど、「スマホや複数カメラで撮った映像を、GPUサーバーで本格的な3Dモーション素材に変換する研究・制作向け基盤」として見ると、かなり現実味がある。
入口は軽く、処理は重い。でも、その重さの先に、キャラクターの身体表現が少し自由になる未来がある。
まとめ
MAMMAのリポジトリを掘ってみると、これは単なる論文デモではなく、かなり実用検証を意識した構成になっていることが分かる。CLI、GUI、工程分割、クイックデモ、自前データ入力、キャリブレーション、Docker/Apptainer対応、出力ブラウザ。研究コードとしては、かなり道具箱が整っている。
一方で、誰でも手元のMacやiPhoneだけで完結するものではない。実際に試すなら、CUDA対応NVIDIA GPUを備えたLinux環境が必要になる。短期検証ならクラウドGPU、継続検証ならUbuntu GPUワークステーション、スタジオ運用ならGPUサーバーやProxmox上のUbuntu VMが候補になる。
MAMMAが示しているのは、「モーキャプが完全にお手軽になった」というより、「撮影の入口はかなり軽くなりつつある。ただし処理の本丸には、まだVRAM24GB搭載級のGPUサーバーがいる」という現実的な未来だ。でも、謎の学習モデル1発で構成！という研究デモではなさそうというところは収穫だったかな。ライセンス問題があるので、まずは大学や研究所は試してみて欲しい。
ボクらAiCutyでも、こういう技術を使って、キャラクターの動きをもっと自由に作っていきたい。動きはデータだけど、動き出した瞬間、それはキャラクターの生命線になる。 じゃ、またね。ナオ・ヴェルデでした。
Originally published at note.com/aicu on Jun 8, 2026.
Comments