記事

Metaが50以上のユースケースで社内WebRTCフォークを脱却——デュアルスタックとシム層で最新版への一本化に成功

Metaは2026年4月9日、Engineering at Metaブログで社内フォークしていたWebRTCを最新版へ移行した事例を公開しました。50を超える利用箇所に対し、シム層とデュアルスタック構成でA/Bテストを行いながら段階的に切り替え、CPU最大10%削減・クラッシュ率3%改善などの成果を得たとしています。

ライト_トップ画像_q90.webp ## 長年積み上がった社内フォークを脱却する

Metaは2026年4月9日、公式エンジニアリングブログEngineering at Metaで「Escaping the Fork: How Meta Modernized WebRTC Across 50+ Use Cases」と題した記事を公開しました。著者はBoris Tsirkin氏とJoachim Reiersen氏で、長期間にわたり社内フォークとして保守してきたWebRTCを、最新のアップストリームへ段階的に戻した取り組みをまとめています。

同社はMessengerやInstagram、WhatsAppなどのリアルタイム通信基盤として、50を超えるユースケースでWebRTCを使っていました。しかし独自の最適化を重ねた結果、アップストリームから大きく乖離したコードベースが固定化し、セキュリティ更新や新機能追加のコストが年々膨らんでいたとのことです。Metaはこの「フォークの罠」から抜け出すこと自体を今回のプロジェクトの主題に据えています。

フォークしたコードを統合するイメージ

画像引用元: Engineering at Meta

シム層とデュアルスタック構成でA/Bテスト

記事によると、Metaはまず旧版と最新版のWebRTCを「同一アプリケーションの中で共存させる」ためのシム層を開発しました。これは呼び出しを実行時に旧実装・新実装のどちらかへ振り分けるプロキシライブラリで、既存コードへの侵襲を最小限に抑えつつ、機能単位で切り替えを試せる作りになっています。

シンボル衝突を避けるための工夫として、C++の名前空間を自動でリネームする仕組みを用意したと紹介されています。具体的にはwebrtc::をwebrtc_legacy::とwebrtc_latest::に分離し、数千件規模のシンボル衝突を機械的に解消しました。さらに、シム層のベースコードはコード生成ツールで自動作成することで、人手による重複作業を大幅に削減しています。

パッチファイルではなくフィーチャーブランチで保守

もうひとつの要点が、社内独自パッチの管理方法を刷新した点です。これまでのような大量のパッチファイル群ではなく、専用Gitリポジトリでフィーチャーブランチを使って追跡する方式に切り替えました。アップストリームのリリースごとにベースブランチを作り、その上に機能別ブランチを積む構成で、パラレルな開発と継続的なアップストリーム追従の両立を狙っています。

Metaはこの方式のメリットとして、「社内改変をそのままアップストリームへコントリビュートしやすくなる」ことを挙げています。パッチファイル中心の運用では上流へ還元しづらかった改修が、ブランチ単位で切り出せる形になり、コミュニティ貢献のハードルが下がるという意図です。結果として、社内フォークと上流の距離が長期にわたって近い位置に保たれる構造になります。

CPU最大10%削減・クラッシュ率3%改善

移行の成果として、Engineering at Metaは数字でも結果を示しています。CPU使用率は最大10%削減、クラッシュ率は3%改善、バイナリサイズは圧縮状態で100〜200KBの削減を実現したとのことです。また、長年放置されていた非推奨ライブラリや既知の脆弱性を取り除けたことも、セキュリティ面での大きな成果だと述べています。

結果としてMetaのWebRTCスタックは、Chromiumの最新リリースと歩調を合わせて継続的にアップグレードできる状態に戻りました。Metaは今回のプロジェクトを「全面書き換えに頼らず、設計上の工夫でフォークから脱出できる」実例として位置付けており、似たような長期フォーク問題を抱える他組織にとっても、デュアルスタック＋フィーチャーブランチという組み合わせは参考になる選択肢となりそうです。