フォークの罠から脱出せよ：Metaが50以上のユースケースでWebRTCを現代的に刷新した方法

はじめに：フォークの罠

大規模なオープンソースプロジェクトを内部フォークで管理していると、時間の経過とともにアップストリームとの乖離が大きくなり、最終的には「孤立」状態に陥りがちです。Metaも例外ではありませんでした。世界中の数十億ユーザーにリアルタイム音声/ビデオ通信（RTC）を提供するためにWebRTCを深くカスタマイズしていましたが、内部フォークは次第にアップストリームから切り離され、コミュニティのアップデートを受け入れにくい状況になっていました。

この記事では、Metaがどのように「フォークの罠（Forking Trap）」から脱出し、50以上のユースケースを最新のアップストリームベースのモジュラーアーキテクチャへと移行したのか、その戦略と技術的教訓を共有します。

核心的課題：モノレポとスタティックリンカの衝突

Metaの最大の悩みは2つありました。

1. A/Bテストの必要性: 数十億ユーザーにサービスを提供する環境で、一度のアップグレードですべてを変更するリスクは計り知れません。従来のレガシーバージョンと新しいアップストリームバージョンを同時に実行し、安全に比較・検証できる構造が必要でした。
2. モノレポの制約: Metaはモノレポ（Monorepo）を採用しており、機能ブランチを広範にサポートしていませんでした。パッチを追跡し、アップストリームに継続的にリベースする方法を見つける必要がありました。

C++リンカの「One Definition Rule」違反

最も厄介な技術的難関は、C++の**One Definition Rule（ODR）**違反でした。1つのバイナリに同じライブラリの2つのバージョンを静的にリンクすると、数千ものシンボル衝突が発生します。Metaはこの問題を解決するために、**デュアルスタックアーキテクチャ（Dual-Stack Architecture）とシムレイヤー（Shim Layer）**を導入しました。

ソリューション1：シムレイヤーとデュアルスタックアーキテクチャ

シムレイヤーの設計

アプリケーションとWebRTCの間にプロキシとして機能するシムレイヤーを配置しました。アプリはWebRTCを直接呼び出すのではなく、シムAPIを介して呼び出します。シムは単一化されたバージョン非依存のAPIを公開し、内部で「flavor」設定に基づいて実行時にレガシーまたは最新のWebRTC実装へディスパッチします。

// シムレイヤーの例（簡略化された概念）
namespace webrtc_shim {

enum class Flavor {
  LEGACY,
  LATEST
};

class VideoEncoder {
 public:
  virtual bool Encode(const VideoFrame& frame) = 0;
};

// Flavorに応じて実際の実装を生成するファクトリ
std::unique_ptr<VideoEncoder> CreateVideoEncoder(Flavor flavor) {
  if (flavor == Flavor::LATEST) {
    return std::make_unique<webrtc_latest::VideoEncoder>(/*...*/);
  } else {
    return std::make_unique<webrtc_legacy::VideoEncoder>(/*...*/);
  }
}

}  // namespace webrtc_shim

このアプローチにより、バイナリサイズの増加を約38MBから5MBへ、87%も削減できました。

シンボル衝突の解決：自動リネームスペーシング

ODR問題を解決するため、Metaは**自動リネームスペーシング（Automatic Renamespacing）**スクリプトを開発しました。すべてのC++名前空間をスクリプトで一括変更し、webrtc::をwebrtc_latest::とwebrtc_legacy::に分離しました。名前空間の外部にあるグローバルC関数やクラスは、別の識別子で処理しました。

# リネームスペーシングスクリプト（概念）
import re

def rename_namespace(source_code: str, old_ns: str, new_ns: str) -> str:
    # 名前空間宣言の変更
    source_code = re.sub(fr'namespace {old_ns}', f'namespace {new_ns}', source_code)
    # using宣言の変更
    source_code = re.sub(fr'using namespace {old_ns}', f'using namespace {new_ns}', source_code)
    # その他のシンボル参照の変更（簡略化）
    source_code = re.sub(fr'{old_ns}::', f'{new_ns}::', source_code)
    return source_code

下位互換性の維持

リネームスペーシングだけでは既存コードが壊れます。MetaはC++のusing宣言を活用し、新しい名前空間を既存のwebrtc::にインポートする手法を用いました。これは純粋なコンパイラ指示文であるため、バイナリサイズに影響を与えません。

// 下位互換性のためのusing宣言（ヘッダファイル）
namespace webrtc {
  using webrtc_latest::VideoEncoder;
  using webrtc_latest::AudioDecoder;
  // ... 必要なシンボルのみインポート
}

コード生成の自動化

シムレイヤーのアダプタとコンバータを手動で作成するのは膨大な作業でした。MetaはAST（Abstract Syntax Tree）解析に基づくコード生成システムを構築し、生産性を1日1個から3〜4個へと3〜4倍に向上させ、ヒューマンエラーも削減しました。

ソリューション2：機能ブランチ戦略

モノレポ環境でパッチを追跡するために、Metaは別のGitリポジトリで**機能ブランチ（Feature Branches）**を管理する方法を選択しました。

• 各Chromiumリリース（例：M143）に対してbase/7499ブランチを作成します。
• 各パッチ（例：debug-tools）に対してdebug-tools/7499ブランチをbase/7499上に作成します。
• アップグレード時には、すべての機能ブランチを順次マージフォワード（Merge Forward）して、r7559のようなリリース候補ブランチを作成します。

この方式は並列処理が可能で、Git履歴を保持し、将来のLLMによるコンフリクト自動解決にも適しています。

結果：継続的アップグレード体制の確立

このアーキテクチャにより、MetaはWebRTC M120から始めて、現在M145まで継続的にアップグレードしています。主な成果は以下の通りです。

このプロジェクトは、完全なリライトなしでも技術的負債を現代的に刷新できることを証明しました。

日本市場での適用コンテキスト

Metaのアプローチは、日本の大規模サービスやSIer環境において特に有用な教訓を与えてくれます。

• レガシーフォークの管理: 多くの日本企業がオープンソースライブラリを内部フォークで管理し、アップデートに苦労しています。シムレイヤーとデュアルスタックのアプローチは、安全に移行するための青写真を提供します。
• モノレポ環境: 日本でもモノレポの導入が進んでいます。機能ブランチ戦略は、モノレポでも効果的にパッチを管理する方法を示しています。
• A/Bテストの重要性: 日本のサービスもユーザー体験に敏感です。A/Bテスト可能なアップグレードパイプラインは必須です。

この技術の限界または注意点

• 複雑性: シムレイヤーとデュアルスタックはアーキテクチャの複雑度を大幅に高めます。小規模プロジェクトには過剰なエンジニアリングとなる可能性があります。
• メンテナンスコスト: コード生成ツールと自動化パイプラインを継続的にメンテナンスする必要があります。
• チームのスキル: C++テンプレートメタプログラミング、AST解析などの高度な技術が必要です。

次のステップとしての学習方向

1. C++シンボル可視性とODR: C++のリンキングとODRに関する深い理解が必要です。関連書籍やCppConの発表を参照してください。
2. デュアルスタックパターン: このパターンはWebRTC以外にも、OpenSSLやFFmpegなど他のライブラリの安全なアップグレードに適用可能です。
3. AIによるコンフリクト解決: Metaが言及したLLMベースのマージコンフリクト自動解決は、今後さらに注目される技術です。関連する論文やオープンソースプロジェクトを調査してみてください。

結論：フォークの罠から抜け出す方法

Metaの事例は、「フォークの罠」が単なる技術的問題ではなく、組織の長期的な技術的負債管理戦略の一部であることを示しています。完全なリライトなしでも、シムレイヤー、デュアルスタック、自動化されたパッチ管理という3つの軸を通じて、現代的刷新を達成できました。

このアプローチはWebRTCに限定されません。どのオープンソースライブラリでも、内部フォークがアップストリームから乖離し始めているなら、今こそ「脱出」を計画する時です。

「最も危険なフォークは、誰もアップデートしないフォークである。」

併せて読みたい記事：

• Spotifyアプリリリースの舞台裏：ダッシュボード設計と自動化の教訓
• Colab MCPサーバ公開！AIエージェントがGoogle Colabを直接制御する時代へ

本記事は、Meta Engineeringブログの内容に基づいて作成されました。