AI ファンスクリプト生成のしくみ
AutoScript Sync は、完全に PC 上で動く AI の動画モーショントラッキングで動画から動きを読み取ります。フレームをサンプリングし、オプティカルフローで動きを測定し、オプションの姿勢モデルと深度モデルを加え、それらの信号を 1 本の位置の軌跡に統合し、方向が変わるたびにスクリプトの点を置きます。結果は標準的な .funscript として動画の隣に保存されます。特定のデバイスへの調整はその後で、そのデバイスに送るコピーに対してだけ行われます。
2026 年 9 月 21 日にアプリのコードと照合済み。特に記載がない限り、リリース済みのアプリ 2.121.1 について説明しています。
動画ファイルからデバイスまでのパイプライン
各段階を一段落で解説
デコードとサンプリング
動画は OpenCV の FFmpeg バックエンドでデコードされます。アプリはまずハードウェアデコードを要求し、コーデック、ビルド、ドライバーが対応していなければソフトウェアデコードに切り替えます。ワーカースレッドが最大 64 フレームのバッファーへ先読みしてデコードするので、デコードと AI の推論が交互ではなく並行して進みます。
Accuracy 設定で、解析するフレームの数が決まります。Fast は 4 フレームごと、Balanced（既定）は 3 フレームごと、High は 2 フレームごとに 1 枚を使います。30 fps の動画では毎秒 7.5、10、15 サンプルで、60 fps の動画ではその倍になります。サンプリングしたフレームは、元の解像度に関係なく、解析の前に幅 320 px に縮小されます。VR 映像は、まず片目分の通常の透視投影の映像に補正されます。
動いている領域を見つける
Set Motion Region… や Live Track で自分で枠を描かない限り、エンジンは動きのヒートマップを作り、最も動きの大きい連続した領域を選んで 15% 広げます。オプティカルフローと深度はその領域の中で測定されます。
動きの測定
オプティカルフローは常に動く唯一の信号で、DIS 密オプティカルフローがサンプリングしたフレーム間で領域がどう動くかを測定します。YOLOv8 の姿勢推定は 1 人あたり 17 か所の身体キーポイントを加え、MiDaS の深度推定は平面の映像では見えないカメラに近づく・遠ざかる方向の軸を加えます。どちらのモデルもオプションで、ない場合エンジンはフローだけで動作し、その旨を表示します。アプリはバックグラウンドのスレッドで、コーデック自体の動きベクトルと 50 Hz の音量エンベロープも読み取ります。その処理時間の上限は動画の長さに応じて変わります。
統合
フローから得られるのは速度で、時間とともに積算すると誤差がたまってずれていきます。そこでエンジンは、領域の中心、姿勢、深度から動画ごとにアンカーを選定し、Kalman/RTS スムーザーが積算したフローとそのアンカーを 1 本の位置の軌跡に統合します。既定では、アンカーは読み取れるすべてのチャンネルをサンプルごとにブレンドしたもので、選定された単一のアンカーと同等以上のスコアのときだけ採用されます。トラッキングが途切れた部分は、前後のストロークから続くリズミカルな動きで補完され、実測ではなく補完した割合がスクリプトのメタデータに書き込まれます。
動きの種類ごとのウィンドウ
タイムラインは 2 秒ごとのウィンドウに区切られます。小さな分類器が 6 つの動きの特徴から各ウィンドウに動きの種類のラベルを付け、スムージング処理でウィンドウ間のラベルのちらつきを抑えます。ラベルによって、そのウィンドウの動きの形が決まります。自分で設定したラベルがウィンドウの半分以上をカバーしていれば、そのウィンドウでは分類器より優先されます。
点と保存されるファイル
スクリプトの点は動きが反転するたびに置かれます。前の点から 120 ms 未満の間隔になることはなく、少なくとも 4 秒ごとに置かれ、そのあと点のリストが簡略化されます。アプリは既存のスクリプトを .funscript.bak にコピーしてから、標準的な .funscript の JSON を動画の隣に同じ名前で書き出します。中身についてはファンスクリプト形式をご覧ください。
デバイスへの調整
デバイスに合わせて調整されるのは、そのデバイスに送るコピーで、保存したファイルではありません。デバイスが区別できないほど近い点は統合され、速度上限より速い区間はタイミングを保ったまま振幅が小さくなり、点の密度には上限が設けられます。Autoblow AI Ultra では、さらに反転点が 16 fps のグリッドに揃えられます。リリース済みのアプリでは、この調整は Autoblow へのアップロードに適用され、Intiface のデバイスへの適用は次回のアップデートで行われます。その後デバイスが動画とどうタイミングを合わせ続けるかは、ドリフト補正と同期のタイミングで説明しています。
各部分が動く場所
解析はすべてあなたの PC 上で行われます。解析モジュールにはネットワーク関連のコードがなく、動画がアップロードされることはありません。Hardware 設定には Auto（既定）、GPU (CUDA)、CPU があります。
| 段階 | 実行場所 |
|---|---|
| 動画のデコード | 利用できればメーカーを問わずハードウェアデコーダー、なければ CPU |
| 姿勢モデルと深度モデル | CUDA を通じた NVIDIA GPU（ONNX Runtime または PyTorch）。CUDA GPU が使えない場合は CPU |
| オプティカルフロー | すべてのマシンで CPU（OpenCV） |
AI モデルには AMD や Intel 向けの高速化はなく、TensorRT も使っていません。CUDA GPU を指定しても使えない場合、姿勢と深度は CPU に切り替わり、アプリは実際に使われているプロバイダーを表示します。どれが使われているかは Check GPU ボタンでわかります。CPU でも動作しますが、かなり遅くなります。RTX 5080 のテスト用 PC で書かれたコードのコメントには、小さい深度モデルが GPU では 1 回あたり約 25.8 ms、CPU では 234 ms と記録されています。
開発者自身の GPU 以外の GPU や、CPU のみの PC では、動画全体の処理速度を測定していません。そのため、このページでは速度について何も約束しません。何を、どの環境で測定したか、何を測定していないかはベンチマークのページにまとめています。
まだ解決していないこと
以下は、既定値の調整に使った 5 本の動画から開発者が手作業でスクリプトを作った 28 本の短いクリップに対し、2.121.1 の次のビルド（ビルド済み、未リリース）を開発者自身が採点した結果です。スクリプト作成者は 1 人で、サンプルも少ないので、ベンチマークではなく既知の弱点として読んでください。
- 方向転換の取りこぼし。人間が毎秒 2.29 回方向を変えたのに対し、エンジンは 1.80 回で、約 21% 少なくなりました。エンジンの折り返しには余分なものやタイミングのずれたものもあったため、150 ms 以内で一致した人間の折り返しはおよそ半分にとどまりました。ストロークの折り返しの一致度は、動画によって 0.33 から 0.71（F1、150 ms 以内）でした。
- 速いストロークが小さくなる。ストロークが最も速い 2 本の動画では、エンジンのストロークは人間のものの 4 分の 1 と 2 分の 1 の大きさでした。現時点での説明は、Balanced の毎秒 10 サンプル（30 fps の動画の場合）では速い動きがならされて消えてしまう、というものです。
- アクションが止まっても止まらない。人間がアクションなしと指定した区間でも、エンジンは毎分約 85 回の方向転換を出力しました。ただし、実際の動きを示すサンプルが 5% 未満の場合は、スクリプトの作成自体を拒否します。
- 動きの種類のラベルは実証されていない。開発者自身のラベルで動画単位のホールドアウト評価をしたところ、動きの分類器は単独では常に同じ答えを返す推測を下回り、既定のアプリについて公表に値する精度の数値はありません。自分で設定したラベルは分類器より優先されます。
現時点での実用的な対処法は、タイムラインエディター、選択した区間のフルフレームレートでの Re-analyze、そしてファンスクリプトのトラブルシューティングです。
次に読む
- オプティカルフロー：フレーム間の動きを読み取るすべてのスクリプトの土台となる信号と、それがずれないようにするしくみ。
- YOLOv8 による姿勢推定Accuracy の各段階が使うモデルと、キーポイントが加えるもの。
- MiDaS による深度推定カメラに向かう方向の軸と、動画ごとに 1 つの深度スケール。
- デバイスがタイミングを保つしくみAutoblow、Intiface のデバイス、DeoVR の同期ルール。
- ベンチマークと測定値何を、どのマシンで測定したか、何を測定していないか。
- AI ファンスクリプトジェネレーターAI の各部分の役割と、あなたの編集から学習するしくみ。