プロキシのワークフローが停止しつつあります

編集者がカット前にトランスコードする必要が薄れてきている理由

ここに至るまでの経緯

プロキシワークフローが標準的な慣行となったのには、理にかなった理由があります。10年前、ほとんどの編集用ハードウェアは、4K以上の高解像度映像をリアルタイムで処理することができませんでした。コンシューマー向けやプロシューマー向けの標準的なマシンには、コマ落ちさせることなく、フル解像度で高密度のコーデックを快適に再生・検索するための処理能力、GPUアクセラレーション、ストレージのスループットが備わっていませんでした。この問題を解決する論理的でエレガントな方法が、「カメラオリジナルのデータを、元の解像度の数分の一に抑えた ProRes Proxy や DNxHR LB などの軽量な形式にトランスコードする」というものでした。そして、この軽量なコピーを使って編集を行います。カットが確定した段階で、カラーグレーディングや最終出力のために、フル解像度のオリジナルデータに再リンク（リリンク）するのです。

このワークフローは、HDから4Kへの移行期や、ミラーレスカメラによるH.264やHEVCといった圧縮収録コーデックの普及期において、業界に大きく貢献しました。編集者たちはこの仕組みを中心にシステム全体を構築しました。Premiere Pro、Final Cut Pro、DaVinci Resolveはすべて、専用のプロキシ管理ツールを開発しました。プロキシワークフローの設定に関するチュートリアルは、現在でもオンラインで最も視聴されている編集コンテンツの一つです。多くの編集者にとって、プロキシの作成は映像のバックアップを取ることと同じくらい、自動的で当たり前の作業になりました。

しかし、プロキシを不可欠にしていた前提条件は変化しつつあります。ハードウェアは追いつきました。ソフトウェアのデコード機能も向上しました。そして、映像が編集者の元に届く方法そのものが変化しているため、ローカルにプロキシファイルを持つという概念自体が時代遅れになりつつあるのです。

プロキシの本当のコスト

プロキシに取って代わる技術について検討する前に、プロキシ作成にどれほどのコストがかかっているかを具体的に整理しておく価値があります。最も目に見えやすいコストは「時間」の投資です。1日分の4K映像をトランスコードするのに、ソースコーデック、ターゲットフォーマット、ハードウェア、および素材の量によっては、1時間から6時間ほどかかります。1日に数百ギガバイトの素材を生成するドキュメンタリー撮影の場合、プロキシの作成は一晩中かかることもあります。その間は編集作業を開始できません。納期が迫っているプロジェクトにおいて、この数時間は極めて重要です。

2つ目のコストは「ストレージ」です。プロキシはオリジナルよりサイズが小さいとはいえ、容量を消費します。プロキシワークフローを採用すると、プロジェクトに関連するメディアファイルの数は単純に約2倍になります。もしすでにSSDの容量不足に悩まされているなら（ノートPCで作業する多くの編集者がそうです）、並行してプロキシファイル群を追加することはストレージへの大きな圧迫となります。

3つ目のコストは「複雑さ」です。プロキシからフル解像度のオリジナルへのリリンクは本来シームレスに行われるはずですが、経験豊富な編集者なら誰もが知っている通り、実際にはトラブルが頻発します。ファイル名の変更、フォルダの移動、タイムコードの不一致、あるいはプロキシとオリジナルの間でのわずかなフレーム数の違いなどが、すべてリリンクエラーの原因になります。疲労がたまり、締め切りが迫っているプロジェクトの最終段階でリリンクの問題をデバッグすることは、ポストプロダクションにおいて最もストレスのかかる作業の一つです。

さらに、管理上のオーバーヘッドもあります。同期を維持しなければならない2つの並行するメディア構造が存在することになります。プロジェクトの途中で新しい映像を追加するたびに、新しいプロキシを生成する必要があります。メディアを整理し直すたびに、プロキシのパスが正しく解決されているか確認しなければなりません。機能はしますが、これはメンテナンス作業であり、プロジェクトの規模が大きくなるにつれてその負担も増大します。

何が変わったのか

プロキシの必要性を薄れさせる3つの進化が同時に起こりました。

1つ目は「ハードウェア」です。Apple Siliconチップ（特にM1 Pro以降）の登場により、ノートPCのハードウェア上でもリアルタイムでの4K、さらには8Kの再生が可能になりました。これらのチップに搭載されているメディアエンジンは、CPUに負荷をかけることなく、ProResやH.265をネイティブにデコードします。WindowsやLinux環境でも、NVIDIAやAMDの最新のGPUが、最も一般的なコーデックに対してハードウェアアクセラレータによるデコードを提供しています。2024年以降に構築されたミドルレンジの編集用ワークステーションは、5年前ならハイエンドマシンをフリーズさせていたような重い映像でも軽々と処理できます。

2つ目は「ソフトウェア」です。ノンリニア編集（NLE）ソフトウェアの開発企業は、再生パフォーマンスに多大な投資を行ってきました。DaVinci Resolveの最適化されたメディアパイプライン、Premiere Proのハードウェアアクセラレーションによるデコード、Final Cut Proのバックグラウンドレンダリングなどは、いずれも編集者が快適に作業するために軽量なメディアを必要とする場面を減少させています。スマートレンダリングや部分デコード戦略により、マシンがフル解像度の映像をフルフレームレートで再生できない場合でも、ラフカット編集には十分スムーズなパフォーマンスを提供できるようになりました。

3つ目、そして編集ワークフローの進化において最も重要なのが、「クラウドネイティブなメディアプラットフォーム」の台頭です。映像がクラウド上に存在し、オンデマンドでストリーミングされるようになると、プロキシファイルという概念自体が構造的に不要になります。もはや「ドライブ上のフル解像度ファイル」と「ドライブ上のプロキシファイル」のどちらかを選ぶ必要はありません。接続環境やハードウェアが維持できる解像度で、必要な瞬間に必要な映像をストリーミングすればよいのです。トランスコードする対象が存在しないため、トランスコードの手順そのものが消滅します。ローカルドライブには、現在アクティブに使用しているデータだけが保持されます。

クラウドネイティブメディアとトランスコード不要の時代

Fabricのクラウドドライブはこの原則に基づいて構築されています。ビデオファイルはクラウドに保存され、オンデマンドでストリーミングされます。ローカルドライブにダウンロードすることなく、フル解像度で映像のブラウズ、スクラブ、プレビューが可能です。編集の準備ができたら、必要な特定のクリップだけを呼び出します。SSDは、キャッシュ、レンダリングデータ、アプリケーションデータ用として常に空けておくことができます。

これがプロキシの問題において重要なのは、プロキシが存在する最大の理由、すなわち「すべての映像をローカルに保存しなければならない」という前提を取り除くからです。1テラバイトの4Kメディアが512GBのSSDの空き容量を圧迫しなくなれば、その軽量なコピーを作成する動機は消え去ります。NLEがオリジナルファイルを直接ストリーミングできるのであれば、中間のフォーマットを挟む必要はありません。

Fabricは、エンタープライズ向けのポストプロダクションで数十年にわたり存在してきたツールカテゴリであるメディアアセットマネジメント（MAM）プラットフォームとして機能します。放送局や大規模なポストプロダクションは、共有ストレージ上の膨大な映像ライブラリを管理し、編集者が高速ネットワークを介してメディアにアクセスするために、長年MAMシステムを利用してきました。現在との違いは、クラウドインフラと一般的なインターネット速度の向上により、SANハードウェアや専門のITスタッフへの高額な投資なしに、個人の編集者や小規模スタジオでもこのモデルを実用化できるようになった点です。

依然としてプロキシが有効なケース

客観的に見て、プロキシワークフローが完全に消え去るわけではない（少なくとも現時点では）ということを認める必要があります。以下のような一般的なシナリオでは、依然としてプロキシが推奨されます。

多くのカメラアングルを同時に扱う「マルチカム制作」は、依然として高い負荷がかかります。8つ以上のカメラアングルを同期させ、同時に再生するライブイベントなどを編集する場合、強力なハードウェアであってもフル解像度のストリーム処理に苦戦することがあります。プロキシは、マルチカム編集の段階における負荷を処理可能なレベルに軽減し、アングルを選択してラフカットを構築した後にのみ、フル解像度へのリリンクを行います。

信頼できるインターネット接続がない場所での「オフライン編集」も、明確にプロキシが必要な事例です。辺境の現場で作業するドキュメンタリーの編集者、飛行機内の編集者、あるいはインターネット接続が不安定な環境にいる人は、プライマリワークフローをクラウドストリーミングに依存することはできません。ローカルのプロキシファイルは、接続が途切れたときの保険になります。Fabricは現在オフラインサポートを提供していないため、インターネットアクセスのない場所で定期的に作業する編集者は、それに応じた計画を立てる必要があります。

「極めて高解像度のフォーマット」を扱う場合も、3つ目のシナリオとなります。8KのREDやARRIの映像、またはVFX作業用の非圧縮イメージシーケンスを扱う編集者は、最新のハードウェアであっても負荷を軽減するための支援が必要になる場合があります。これらのフォーマットの純粋なデータレートは、現在のハードウェアがリアルタイムでデコードできる限界を超えることがあるため、軽量な編集用フォーマットを使用するのが実用的です。

「カラーが極めて重要なワークフロー」でも、プロキシが有益な場合があります。カラーリストによっては、カラーのメタデータを特定の形式で保持する、特定の中間フォーマットでの作業を好むことがあります。このような場合、プロキシはパフォーマンス向上のためというよりも、カラーパイプラインの管理のために使用されます。

すでにプロキシが不要なワークフロー

増加しつつある多くの編集者にとって、プロキシはもはやメリットのないオーバーヘッドでしかありません。企業の紹介ビデオ、ブランドコンテンツ、SNS向けの成果物などをカットするフリーランスのビデオエディターを考えてみましょう。ソース映像は通常、ミラーレスカメラで撮影された4KのH.264またはH.265です。現代のハードウェアは、これらのコーデックを効率的にデコードします。レイヤー数の観点から見ても、編集は比較的シンプルであることが多く、メインのアングル、いくつかのBロール、グラフィックス、およびタイトルのみで構成されます。マルチカムも、VFXも、イメージシーケンスもありません。

このような編集者の場合、カットを始める前にプロキシを生成することは、1〜3時間の待ち時間を増やし、ストレージ容量を2倍に増やすだけです。Fabricのようなクラウドネイティブなプラットフォームで作業している場合、ストレージの問題は完全に無視できます。映像がアップロードされたらすぐにカットを開始でき、アップロード自体は他の素材を確認したりプロジェクトを設定したりしている間にバックグラウンドで行うことができます。

ウェディングやイベントのビデオグラファーも、同様の状況にあります。映像のボリュームは大きいですが、通常、最初の素材選定の後は、複数アングルの同時再生を必要とする編集スタイルではありません。ミュージックビデオの編集者、ショートフォームのコンテンツクリエイター、ビデオ要素を含むポッドキャストの編集者などもすべてこのカテゴリに当てはまります。共通しているのは、扱う映像の量は非常に多いものの、再生にかかる負荷が、現在のハードウェアやクラウドストリーミングで処理できる限界を超えないワークフローであるという点です。

余分なファイルを作成しない整理・管理

プロキシを廃止することによる、あまり議論されないメリットの一つは、メディア管理の簡素化です。2つの並行する階層ではなく単一のファイルセットを使用するため、映像の検索や整理がはるかにシンプルになります。Fabricのスマート整理機能やセマンティック検索は、オリジナルのメディアに対して直接機能します。ファイル名を覚えていなくても、クリップの内容を説明するように「意味」で検索することができ、検索結果はプロキシの派生ファイルではなく、実際のオリジナルファイルを指し示します。

アノテーション機能により、ビデオやオーディオファイルにタイムスタンプ付きのコメントを追加でき、描画ツールを使用して個別のフレームにビジュアルなメモを残すことができます。これらのフィードバックはすべてオリジナルファイルとともに保存されます。プロキシワークフローでは、アノテーションやメモがオリジナルではなくプロキシに関連付けられてしまい、リリンク時に混乱を招くことがありました。単一ファイルのワークフローなら、このような問題は完全に回避できます。

レビューと納品

ポストプロダクションにおけるレビューサイクルにも、独自のプロキシ問題が存在します。編集者はクライアントやコラボレーター向けに圧縮したレビュー用コピーを頻繁に書き出しますが、これは実質的に別の形のプロキシ（特定の閲覧環境向けに作成された軽量バージョンの成果物）です。レビュー用の書き出しを行うたびにローカルのストレージが消費され、そこから得られるフィードバックは、タイムラインから切り離された別のツール上で管理されることがよくあります。

Fabricの公開機能は、プラットフォームから直接作品を共有できるようにし、クライアントがいつ映像を視聴したかを追跡するリンク分析機能を提供することで、この問題に対処します。レビュー担当者は、ファイルをダウンロードすることなく、アノテーションツールを介してタイムスタンプ付きのフィードバックを追加できます。レビューのステップにおいて、別の派生ファイルを生成する必要はもうありません。

より大きな変化の流れ

プロキシワークフローの衰退は、クリエイティブツールにおけるより大きなパターン、すなわち「ローカル優先」から「クラウドネイティブ」なアーキテクチャへの移行の一部です。写真編集者は、Lightroomがクラウド同期カタログモデルに移行した際に、この変化を経験しました。イラストレーターやデザイナーは、Figmaのブラウザベースのアプローチでそれを目にしました。音楽制作はまだそのプロセスの初期段階にありますが、同じ方向に向かっています。

ビデオファイルのサイズが大きく、リアルタイムのパフォーマンス要求がより厳しいため、映像分野におけるこの移行は比較的緩やかでした。しかし、インフラは、非常に多くのユースケースにおいてクラウドネイティブなビデオワークフローが実用的であるレベルに達しています。これらのワークフローを採用している編集者は、最先端の実験者というわけではありません。彼らは、トランスコードの手順が相応の価値をもたらすことなく、自分たちの時間を奪っていることに気づいた現実的なプロフェッショナルなのです。

Fabricは、クラウドドライブ、検索、整理、アノテーション、そして配信・納品を単一のプラットフォームに統合し、クラウド上でホストされたメディアをローカルファイルのバックアップではなく、主要なアセット（オリジナル）として扱います。作業内容がこのモデルに適している編集者にとって、プロキシワークフローは過去の制約が生んだ遺物となるでしょう。

よくある質問

動画編集におけるプロキシワークフローとは何ですか？

プロキシワークフローとは、オリジナルの高解像度映像を、編集用に低解像度の軽量なコピー（プロキシ）にトランスコードする作業を指します。プロキシを使ってカット編集を行い、カラーグレーディングや最終書き出しの段階でオリジナルファイルに再リンクします。これにより、編集段階におけるハードウェアへのパフォーマンス要求を軽減できます。

なぜ編集者はこれほど長い間プロキシワークフローを使用してきたのですか？

古いハードウェアやストレージシステムでは、高解像度（特に4K以上）の映像をリアルタイムで再生することができなかったためです。プロキシを使用することで、そのまま再生するとコマ落ちやカクつきが発生するようなマシンでも編集が可能になりました。このワークフローは、プロの現場や教育機関に深く根付いていました。

最新のコンピュータはプロキシなしで4K編集を処理できますか？

多くの最新マシンで処理可能です。M1 Proチップ以降を搭載したApple Silicon Macや、最新のNVIDIAまたはAMDのGPUを搭載したWindowsワークステーションは、最も一般的なコーデックに対してハードウェアアクセラレータによるデコードを提供しています。ビデオレイヤーが1つか2つの標準的な編集作業であれば、フル解像度での再生も十分にスムーズに行えます。

クラウドネイティブなメディアアセットマネジメント（MAM）プラットフォームとは何ですか？

MAMプラットフォームは、メディアファイル、メタデータ、およびワークフローを一元管理するシステムです。FabricのようなクラウドネイティブなMAMは、ローカルにコピーを必要とせず、メディアをクラウドに保存してオンデマンドでストリーミングします。これにより、大規模なローカルストレージアレイが不要になり、編集者と他のチームメンバーとのコラボレーションが簡素化されます。

Fabricはオフラインでも動作しますか？

Fabricは現在、オフラインサポートを提供していません。クラウドドライブからメディアをストリーミングしてアクセスするには、安定したインターネット接続が必要です。接続環境のない場所で定期的に作業する編集者は、それに合わせて計画を立て、該当するセッション用に重要な映像のローカルコピーを保持しておくことをお勧めします。

クラウドネイティブな動画編集には、どの程度のインターネット速度が必要ですか？

安定した50 Mbpsの回線があれば、ほとんどの4Kワークフローを快適に行うことができます。より高ビットレートのコーデックや、複数のストリームを同時に扱うタイムラインでは、さらに高速な回線が推奨されます。H.264のような圧縮フォーマットの場合、25 Mbpsでも通常はスムーズなスクラブや再生が可能です。

プロキシの使用をやめることで時間は節約できますか？

ほとんどのワークフローにおいて節約できます。プロキシの生成には、映像の量やコーデックに応じて通常1〜6時間かかります。そのステップを排除することで、より早く編集を開始できます。また、2つの並行するメディアファイルを管理したり、プロジェクトの最後に再リンクのトラブル対応をしたりする時間も節約できます。

クラウドネイティブのワークフローと併用してプロキシを使用することはできますか？

はい、可能です。プロジェクトの特性上必要な場合、Fabricがプロキシの使用を制限することはありません。マルチカム制作、オフライン環境、あるいは極めて高い解像度のフォーマットを扱う場合など、必要に応じてプロキシを生成して使用できます。重要なのは、多くの一般的なワークフローにおいて、プロキシの作成ステップがもはや必須ではなくなっているという点です。

Fabricはどのようなコーデックをサポートしていますか？

Fabricは、ProRes、DNxHR、H.264、H.265、RED R3D、Blackmagic RAWなどの標準的なプロフェッショナルビデオコーデックをサポートしています。一般的なイメージシーケンスやオーディオフォーマットもサポートされています。ファイルはトランスコードされることなく、ネイティブフォーマットのままストリーミングされます。

Fabricのセマンティック検索はどのように動画編集に役立ちますか？

セマンティック検索を使用すると、ファイル名を覚えていなくても、内容を説明することでクリップを検索できます。例えば、「屋外のドローン映像」や「白い背景での製品デモ」といった概念で検索すると、カメラでファイルがどのように命名されたかに関係なく、メディアライブラリ全体から関連する結果をFabricが検出して表示します。

関連ページ

• Fabric クラウドドライブ

• セマンティック検索

• スマート整理機能

• アノテーション

• 公開と共有

• 接続

• AIアシスタント

• ビデオエディター向けFabric

• ビデオグラファー向けFabric

• デジタルアセットマネジメント