アップロード不要・ローカル完結で動くブラウザ動画編集の仕組み｜WebCodecs / OPFS / OffscreenCanvas

なぜ「クライアント完結」で設計したのか

VideoBuff は、動画ファイルを一度もサーバーに送らずブラウザ内で完結する動画エディターです。編集対象の動画は端末から外に出ず、デコード・合成・書き出しまですべてユーザーのマシン上の GPU と CPU で処理されます。クラウドストレージも、サーバー側の FFmpeg パイプラインも、アカウント登録も使いません。

この設計を選んだ理由は単純で、クライアント完結でないと開発者向けの使い方が成り立たないからです。具体的には次の 3 点:

1. アップロード待ちをゼロに: 1GB の素材を編集するたびに S3 に投げるワークフローは、単純に遅く、egress コストと API レート制限に常に縛られる。ローカル GPU で処理するなら、ファイルサイズは体感的には関係なくなる。
2. プライバシー境界をクリアに: 未公開の素材・社内映像・個人撮影をクラウドに置きたくないユースケースは多い。ブラウザのサンドボックスにファイルが留まるなら、「何が外に出ているか」の議論が発生しない (唯一の例外は匿名利用統計で、これも明示的にオフにできます)。
3. Claude Code / Claude Desktop からの MCP 連携が自然に成立する: 編集状態がブラウザタブ内の JavaScript オブジェクトとして完全にローカルに存在するため、MCP サーバーは WebSocket でタブと話す薄いローカルブリッジで済みます。クラウド API を介さないので、認証・API キー管理・リージョン・レイテンシといったクラウド連携の面倒がそっくり不要になります。詳細は Claude 連携ガイドを参照。

以下、この設計を実現している 4 つの Web API — WebCodecs / OffscreenCanvas / Web Audio API / OPFS（+ localStorage によるプロジェクト構造保存）— と、それぞれがどこで効いているかを解説します。

WebCodecs API — サーバー側 FFmpeg の代わりにクライアント GPU を使う

WebCodecs API は、ブラウザ内で H.264 / H.265 / VP9 / AV1 などのコーデックを GPU / 専用ハードウェアでデコード・エンコードするための低レベル API です。VideoDecoder がソースファイルからフレームを抽出し、VideoEncoder が編集済みフレームを任意のコーデックで圧縮します。WASM ビルドの FFmpeg とは違い、OS が持つハードウェアデコーダにそのまま接続するため、JavaScript / WASM ベースの実装と比べて桁違いに速く、電力効率も良いです。

開発者視点での意味は「動画エンコードのためにクラウドの GPU インスタンスを立てる必要がなくなった」こと。従来は S3 にアップロード → EC2 or Lambda で FFmpeg → 結果を DL、という数十秒〜数分のパイプラインを組んでいた部分が、ユーザーの手元の M1 / M2 / 内蔵 GPU で 1 段で終わります。サーバーコストも egress も発生しません。

VideoBuff ではプレビュー時は VideoDecoder + CSS フィルターで軽量に再生し、書き出し時は VideoEncoder + OffscreenCanvas で最終合成するという二段構えにしています。プレビュー中は即応性重視、書き出し時は精度重視、という切り替えです。

OffscreenCanvas

OffscreenCanvasはメインUIスレッドをブロックすることなく、バックグラウンドでフレームレンダリングを行うためのAPIです。VideoBuffでは2Dコンテキストを使用して、ビデオフレーム・テキストオーバーレイ・画像レイヤーを合成しています。

この処理はWeb Workerで実行できるため、UIの応答性を維持しながら重いレンダリング処理を並行して行えます。カラーグレーディング、ブレンドモード、トランジションなどのエフェクトもすべてOffscreenCanvas上で処理されます。

プレビュー時にはCSSフィルターによる軽量なリアルタイム表示を行い、書き出し時にはOffscreenCanvasで高精度なレンダリングを実行するという二段構えのアーキテクチャを採用しています。

Web Audio API

Web Audio APIはブラウザ内でリアルタイムの音声処理グラフを構築するためのAPIです。VideoBuffではBiquadFilterNodeを使用した3バンドEQ、DynamicsCompressorNodeを使用したコンプレッサー、GainNodeを使用した音量ミキシングを実装しています。

これらのノードを直列に接続してオーディオプロセッシングチェーンを構成し、各クリップの音声をリアルタイムで処理します。オフラインレンダリングモード（OfflineAudioContext）を使用することで、書き出し時にも同一のエフェクトチェーンを適用したPCMデータを高速に生成できます。

ピッチ保持やスピード変更もWeb Audio APIの機能で実現しています。

OPFS と localStorage — 「ファイルは端末から出ない」の技術的担保

Origin Private File System (OPFS) は、ブラウザに組み込まれたサンドボックス型のファイルシステムです。VideoBuff ではインポートされた動画・音声・画像ファイルの実体を OPFS に保存しています。OPFS はオリジン (ドメイン) ごとに完全に隔離されており、他のサイトからアクセスされることはなく、ブラウザ開発ツール以外から直接読み出すこともできません。タブを閉じても、リロードしても、マシンを再起動してもファイルは残ります。

プロジェクトの構造データ (タイムラインの構成、クリップ配置、エフェクトのパラメータ、テキスト内容) は localStorage に JSON シリアライズして保存されています。約 1 秒のデバウンスで自動保存し、ブラウザクラッシュ時もほぼ直前の状態から復帰できます。localStorage の容量上限 (オリジンあたり約 5 MB) に近づいた場合は、サムネイルや波形などの再生成可能な派生データを除いた軽量版に自動フォールバックします。OPFS のアセットマニフェスト (assetId → ファイル名のマッピング) も同じ localStorage 名前空間で管理されています。

この 2 つが "アップロード不要" の技術的担保です。素材の生データは OPFS に、編集の構造は localStorage に、どちらもブラウザのサンドボックス内にローカル保存される。どこにも同期せず、ネットワーク越しに送られる経路が実装上そもそも存在しません。「本当にアップロードされていないのか」を疑うなら、DevTools の Network タブを開いて編集作業をすれば素材の送信リクエストが 1 本も出ないことが確認できます。

副次的な利点として、この構造ゆえに MCP 連携がサーバーレスで成立します。編集状態がブラウザタブ内の JS オブジェクト + OPFS + localStorage に完全に閉じているので、MCP サーバーはローカル WebSocket でタブと話すだけでよく、クラウド上に状態を持つ必要がありません。「Claude に状態を公開するために、まずサーバーに状態を持たせる」という迂回が不要になっています。

(技術メモ: 過去の設計議論では IndexedDB が候補にあがっており、現在のプロジェクト規模であれば localStorage で十分機能していますが、容量や差分書き込みが必要になった段階で IndexedDB への移行余地は残しています。)

なぜ Claude Code / MCP から駆動できるのか

VideoBuff の設計思想を理解すると、「なぜ Claude Code や Claude Desktop からブラウザアプリを駆動できるのか」が自然に腑に落ちるはずです。答えは「編集状態がブラウザタブ内に完全に閉じているから」です。

具体的な構成はこうなっています。ユーザーが .mcpb をインストールすると、ローカルマシン上で stdio MCP サーバー (Node.js プロセス) が起動します。このサーバーは Claude Desktop / Claude Code との stdio と、VideoBuff タブとの WebSocket (localhost) の 2 本を中継するだけの薄いブリッジです。Claude が add_clip のようなツールを呼ぶと、MCP サーバーはコマンドをタブに転送し、タブ側の編集ストアがそれを実行して結果を返します。クラウドサービスは経路のどこにも登場しません。

このアーキテクチャが成り立つのは、編集状態が タブ内の JS オブジェクト + OPFS + localStorage に完全に局在化しているからです。もし素材が S3 にあって編集状態が RDS にあったら、MCP サーバーは AWS SDK を呼び出して認証・権限・リージョンを処理する必要があったはずです。クライアント完結設計だからこそ、MCP サーバーは認証も API キーも持たない薄いブリッジで済みます。

CLI 側の体験としては、claude code を起動したターミナルから「インポート済みの画像を全部タイムラインに並べて、各 3 秒」のような指示を投げると、数秒後にはブラウザタブ上でそれが反映されている、という流れです。ターミナルから git や ffmpeg を叩くのと同じ感覚で、ブラウザ動画エディターを駆動できます。詳しくは Claude 連携ガイドを参照してください。

ブラウザの互換性

WebCodecs APIはChrome 94以降およびEdge 94以降でサポートされており、VideoBuffはこれらのブラウザを推奨しています。SafariやFirefoxは現時点ではWebCodecs APIの完全なサポートがないため、一部の機能が制限されます。

VideoBuffはアプリ起動時にブラウザの機能を検出し、サポートされていない機能がある場合は適切に通知します。コーデックのサポート状況もランタイムで確認されるため、お使いのブラウザでH.265が利用できない場合はH.264のみが選択肢として表示されます。

ブラウザAPIは急速に進化しており、より多くのブラウザでの対応が今後も拡大していくことが期待されます。

今後の展望：ブラウザ + AI エージェント時代の動画編集

ブラウザの動画処理能力は急速に進化しています。WebCodecs の AV1 エンコード対応は一部ブラウザで始まり、WebGPU の普及により GPU 直接利用の高度な映像処理やリアルタイムエフェクトが現実的になりつつあります。SharedArrayBuffer / Atomics によるマルチスレッド処理、WebTransport による高効率通信も進展中です。

VideoBuff はこの技術トレンドを「AI エージェントから駆動可能な動画編集」という方向に寄せて開発しています。デスクトップアプリと同等の処理性能をクライアント完結で得たうえで、その状態に Claude Code や Claude Desktop から自然言語でアクセスできる、という二階建て構造です。

ローカル GPU × 自然言語操作の組み合わせは、「大量の素材を手作業で整形する」編集作業を本質的に別のフェーズに進めます。Premiere Pro の時代に 30 分かかっていた反復処理が、プロンプト 1 本で終わる。センスは人間が、実装は AI が、処理はローカル GPU が担う — この未来は、今この瞬間のブラウザ上で既に動いています。