ローカルPCのリアルタイム顔交換：GPU、FPS、カメラ、プライバシー

結論: リアルタイム顔交換は、検出・交換・合成という一連の処理をウェブカメラの全フレームに対して、自分の端末上で実行します。フレームレートは最も遅い工程で決まり、実用性を左右するのはハードウェアアクセラレーション、そして最も FPS を消費する設定はたいてい顔補正です。

動画の書き出しは、必要なだけ時間をかけて構いません。ライブプレビューはそうはいきません。30 FPS なら1フレームあたり約33ミリ秒で、取得・顔検出・交換・必要なら補正・表示まで終える必要があります。以降の内容はすべて、この制約から導かれます。

1. ウェブカメラの各フレームに起きていること

ライブの経路はループであり、各工程にコストがあります。

• 取得。指定した解像度とフレームレートでカメラから1フレームを取り込みます。
• 検出と解析。そのフレーム内の顔を特定し、誰が誰かを判断するための埋め込み表現を含めて記述します。
• 割り当て。検出された各顔をソース顔に対応づけます。全員共通の既定ソースか、割り当て済み人物の中で最も近い候補です。
• 交換。ソースとターゲットのペアごとに交換モデルを実行し、結果をフレームへ合成します。
• 任意の補正。顔補正が有効で、かつ実行環境がライブでの補正に対応していれば、顔ごとに復元処理が走ります。
• 表示。完成したフレームをエンコードし、ローカルのループバック接続でアプリのウィンドウへ送ります。

ここから2点が導かれます。第一に、この処理はフレーム単位ではなく顔単位です。2人が映れば交換と補正の負荷はおおむね倍になります。第二に、見えているフレームレートは最も遅い工程で決まります。補正がボトルネックなら、より高速なカメラを探しても解決しません。

2. カメラ取得：要求した値と実際に返る値

Deep Face Cam は 960×540・60 FPS・MJPG を指定してカメラを開き、そのうえで実際にデバイスが返した値を読み戻します。この指定は意図的なものです。540p はライブの作業解像度として妥当であり、オープン時に MJPG を要求することは Windows で特に重要になります。非圧縮のままだと帯域の制約で毎秒数フレームまで落ち込むことがあるためです。

Windows ではまず DirectShow、次に Media Foundation、最後に汎用のフォールバックを試します。これらのバックエンドはカメラの列挙順が異なり、すべてのデバイスがどれでも同じように動くわけではないからです。macOS では AVFoundation と汎用フォールバックを使用します。

また、実際のフレームレートはドライバーの申告値ではなく実測で求めています。DirectShow では申告値が信頼できず、60 FPS を出しているカメラが 30 と報告することが珍しくないためです。実測値を確認したい場合は、オプションパネルで Show FPS を有効にしてください。

3. Execution provider：他のすべてを左右する設定

推論は ONNX Runtime を経由し、選択される execution provider がライブ性能を決める最大の単一要因になります。バックエンドは起動時に利用可能なものを検出し、次の順に優先します。

プロバイダー	プラットフォーム	備考
CUDA	Windows、NVIDIA GPU	NVIDIA では最高性能。ただしドライバー、CUDA、cuDNN のバージョン整合に敏感です。
ROCm	AMD のコンピュートスタック	利用可能な場合、CoreML や DirectML より優先されます。
CoreML	macOS、Apple シリコン	PyTorch MPS ではなくこちらを使用。モデルの分割によりCPU・GPU・Neural Engine にまたがる場合があります。
DirectML	Windows	NVIDIA・AMD・Intel と幅広い GPU に対応します。
CPU	すべて	互換性は最大、速度は最低。書き出しには使えますが、ライブでは最も厳しい選択です。

Windows は CPU・DirectML・CUDA が別々の依存関係セットから個別のビルドとして提供されます。つまり適切なインストーラーを選ぶこと自体がこの判断の一部であり、あとから切り替えられる設定ではありません。Apple シリコンでは、生成された CoreML のキャッシュファイルがユーザーのモデルディレクトリに書き出されるため、あるモデルの初回実行は2回目以降より遅くなることがあります。

あわせて重要な点として、ライブ中の顔補正が有効になるのは実行環境が CUDA または DirectML の場合です。それ以外ではライブのパイプラインは交換のみを実行し、画像と動画の書き出しではどの補正モデルも引き続き使用できます。詳細はGFPGAN と GPEN の比較をご覧ください。

4. FPS はどこへ消えているのか

ライブプレビューが遅いときは、この順に確認してください。かかる時間の大きさと、変更のしやすさを踏まえた順序です。

要因	影響	まず試すこと
顔補正	最大。顔ごと・フレームごとに復元処理が1回分。	オフにするか、256 のモデルへ下げる。
顔の数	大。交換も補正も顔ごとに実行される。	必要な顔だけが映るように構図を調整する。
Execution provider	大。CPU のみのライブが最も厳しい。	GPU に合ったビルドをインストールする。
取得解像度	中。検出と合成のコストに影響する。	ライブの解像度は控えめに保つ。書き出しとは別物。
カメラのフォーマット	中。かつ気づきにくい。非圧縮だとデバイス自体が頭打ちになる。	Show FPS で実測の取得レートを確認する。
他の GPU 負荷	変動。ゲーム、エンコーダー、ブラウザーが同じデバイスを奪い合う。	ライブ中は GPU を使う他アプリを閉じる。
熱の制約	時間差で発生。ノートPCは数分後にクロックを落とす。	開始30秒ではなく、持続時のFPSで判断する。

フレームレートと遅延は分けて考えてください。快適なフレームレートでも、各フレームが複数工程とバッファを通るため、遅れて感じることがあります。気になるのが遅延なら、解像度だけでなくフレームあたりの処理量を減らしてください。

フレーム予算・取得解像度・記録すべき項目

ライブはチューニングより先に算数です。1フレームの予算は目標フレームレートで決まり、取得・検出・割り当て・交換・任意の補正・表示のすべてがその中に収まる必要があります。

目標フレームレート	1フレームの時間	検出・交換・補正に使える時間
15 FPS	66.7 ms	≈ 61 ms
24 FPS	41.7 ms	≈ 37 ms
30 FPS	33.3 ms	≈ 28 ms
60 FPS	16.7 ms	≈ 12 ms

3列目は取得と表示に約5ミリ秒を見込んだ場合の値です。これは仮定であり、お使いの環境での実測値ではありません。仕様ではなく問題の形として扱ってください。

取得解像度	1フレームの画素数	既定の 960 × 540 比
640 × 360	230,400	0.44×
960 × 540	518,400	1.00×
1280 × 720	921,600	1.78×
1920 × 1080	2,073,600	4.00×

検出と合成はフレームの画素数に、交換と補正は顔の数に比例します。取得解像度を上げることと、もう1人増えることは、性質の違うコストです。

計測時に記録する項目

項目	重要な理由
OS とビルドの種類	Windows では CPU・DirectML・CUDA が別ビルド、macOS はアーキテクチャで異なります。
Execution provider	最大の単一要因であり、ライブ補正が使えるかどうかも決めます。
GPU とドライバーのバージョン	CUDA 性能はドライバー・CUDA・cuDNN の整合に敏感です。
取得解像度	1フレームあたりの検出・合成コストを決めます。
申告 FPS と実測 FPS	DirectShow では 60 FPS のカメラが 30 と報告することがよくあります。
フレーム内の顔数	交換と補正は顔単位なので、そのまま作業量が倍増します。
補正の設定	Off / GPEN-256 / GPEN-512 / GFPGAN は設計上、顔あたりコストが異なります。
5分後の持続 FPS	ノートPCは発熱で低下します。最初の30秒は実際の数値ではありません。

5. 実用に耐えるライブ結果を得るには

ライブはファイルのレンダリングより融通が利きません。悪いフレームを後から直せないためです。品質の大部分は、開始前に決まる要素で決まります。

• ソース写真。鮮明、均一な光、正面に近いこと。動画と同じ基準ですが、ライブではより重要です。
• 照明。背後の明るい窓より、正面からの均一な光が有利です。逆光は、ライブの顔交換が崩れ続ける最も一般的な原因です。
• 距離と構図。顔が小さすぎると、検出に使える情報が減ります。
• 動き。速い首振りや顔を横切る手が、失敗しやすいフレームです。本番で頼る前に意図的に試してください。
• ミラー表示。プレビューは左右反転できます。自分の動作の自然さには影響しますが、出力のジオメトリには影響しません。

カメラに複数人が映る場合、ライブの割り当ては事前解析したマッピングではなく連続的な類似度判定になるため、マップ済みの動画より本質的に不安定です。違いは複数人ガイドで説明しています。

6. ローカルプレビューでできること、できないこと

ここははっきり書いておきます。ライブ顔交換ツールに関して最も多い誤解だからです。Deep Face Cam はライブ結果を自身のプレビューウィンドウに表示します。システムレベルの仮想ウェブカメラデバイスとしては登録されないため、Zoom、Discord、OBS、ブラウザーのカメラ一覧には表示されません。

他のアプリケーション内で出力を使いたい場合、その受け渡しは別途の画面キャプチャーやウィンドウキャプチャーのソフトウェアに頼ることになり、画質・遅延・プラットフォーム上の制約がそのまま付いてきます。その経路を自分で検証するまでは、動く前提で計画しないでください。あわせて、加工したカメラ映像を会議や本人確認の場で実際の自分の姿として提示する行為は、責任ある利用のポリシーが明確に禁じている用途です。

7. プライバシー：端末に残るものと、そうでないもの

「ローカル」と「オフライン」は同じ主張ではありません。そしてその違いは、ライブのカメラ映像で最も重要になります。

• 主要な処理は端末上。カメラのフレーム、交換、プレビューは、自分のマシンで動作するバックエンドが扱います。
• プレビューはループバック経由。同梱のバックエンドは処理済みフレームを 127.0.0.1 のローカル接続でアプリのウィンドウへ配信します。コンピューター内部の経路であり、アップロードではありません。
• モデルは確認のうえ一度だけ取得。大きなモデルファイルはリポジトリに含まれません。確認後にユーザー領域へダウンロードされ、公開チェックサムで検証されます。
• ネットワーク利用は残ります。インストーラー、モデルのダウンロード、ドキュメントのリンク、更新確認は通信を使います。
• 生成物はディスクに残ります。モデル、出力、一時ファイル、設定はユーザーごとのアプリデータ領域に置かれます。セッション後の整理で把握しておく価値があります。

同種の主張をするどのツールにも当てはまる、正直な勧め方は同じです。実際に使うビルドをそのまま試し、初回のモデルダウンロードまで済ませ、挙動を確認してから機微な素材に向けてください。設計上の説明はプライバシーに関する説明にあります。

ライブのトラブルシューティング

症状	考えられる原因	確認すること
カメラが開かない	他のアプリがデバイスを占有、またはバックエンドの相性。	他のカメラアプリを閉じる。Windows では DirectShow → Media Foundation → 汎用の順にフォールバックします。
取得レートが極端に低い	カメラが非圧縮フォーマットで接続された。	Show FPS を有効にし、カメラの公称フレームレートと比較する。
ライブで補正が選べない	実行環境が CUDA でも DirectML でもない。	プロバイダーを確認する。画像と動画の書き出しでは補正を使えます。
首を振ると顔が外れる	正面から大きく外れた顔を検出できていない。	照明と構図を改善し、本番前に可動範囲を試す。
別人に顔が乗る	ライブの割り当てはフレームごとの類似度判定。	映る人数を減らすか、ファイル処理を使う。
数分後に FPS が落ちる	熱によるクロック低下。	開始直後ではなく、持続時のフレームレートで測る。
初回だけ極端に遅い	モデルの読み込みと、Apple シリコンでは CoreML キャッシュの生成。	一度ウォームアップしてから計測する。

よくある質問

リアルタイム顔交換に GPU は必要ですか？

CPU でもパイプラインは動きますが、1フレームの時間予算が固定されているライブこそアクセラレーションが最も効く場面です。Windows に CPU・DirectML・CUDA の個別ビルドがあるのはこのためで、Apple シリコンでは CoreML プロバイダーを使用します。

Zoom や Discord、OBS のカメラとして使えますか？

直接は使えません。結果は本アプリのプレビューウィンドウに表示され、システムの仮想カメラデバイスとしては登録されないため、他のアプリのカメラ入力一覧には現れません。

ライブの FPS がカメラの公称値より低いのはなぜですか？

取得は最初の工程にすぎないためです。検出、割り当て、交換、任意の補正、表示までが同じフレーム予算に収まる必要があり、最も遅い工程が全体の速度を決めます。

ライブでは解像度をどれくらいにすべきですか？

書き出しより低めです。既定では 960×540 を目標に取得しており、プレビューの作業点としては妥当です。リアルタイム処理に 4K を流し込む利点はありません。

ライブ顔交換はカメラ映像を送信しますか？

主要な処理は自分のマシンで実行され、プレビューはローカルのループバック接続を通ります。確認済みモデルのダウンロードやリンクには通信を使うため、実際にインストールするビルドの挙動を確認してください。

2人で同時にライブ顔交換を使えますか？

使えますが、事前解析したマップではなくフレームごとの類似度で割り当てるため、マップ済み動画のレンダリングより不安定です。プレビューとして扱ってください。

関連ガイド

• GFPGAN と GPEN：どの顔補正を使うべきか
• 動画で複数人の顔交換を行う方法
• PC・Macで動画の顔交換をローカルで行う方法
• PC・Mac向けローカル顔交換ソフト
• GIFの顔交換をアップロードせずローカルで行う方法
• Deep Face Cam ソースリポジトリ
• プライバシーに関する説明