BiBoost - 海外動画高速化 for bilibili

プロジェクト概要

主な貢献

• プロダクトの方向性を自ら判断し、わずか 2 日で開発から公開まで完了。有料広告は一切出稿せず、Bilibili 関連のフォーラム／コミュニティへの能動的な投稿によるオーガニック流入のみで、公開 9 日で週間アクティブユーザー（WAU）1,000 を突破

• 公開 83 日（3 か月未満）で週間アクティブユーザー 10,000 を突破（2026/10/18 時点で 10,706）。直近 4 週間は平均で週 28% 成長、1 日あたり約 240 人の純増。chrome-stats のストア全体の統計によると、公開 3 か月以内に 1 万ユーザーに達する拡張機能は0.1% 未満で、規模はすでに Chrome ウェブストアの拡張機能の 97% を上回る

• 累計 163 件の評価、平均 4.9★、98% が星 5（160 件）、うち 106 件に具体的なテキストフィードバックあり。Edge と Firefox の評価はすべて星 5。フォーラムやコミュニティでフィードバックを継続的に収集し、修正の優先順位付けと機能改善の方向性に反映することで、「宣伝 → フィードバック収集 → 改善」の好循環を構築

技術的なポイント

1. 01

   Vibe Coding の実践

   Claude Code をコーディング agent として全工程で活用し、技術アーキテクチャ、コード実装からストア掲載素材まで、わずか 1 回の週末で完成・公開

2. 02

   MAIN world へのインジェクションによる fetch/XHR と JSON プロパティのインターセプト

   Manifest V3 の content script をページの MAIN world に注入し、fetch / XMLHttpRequest および playinfo オブジェクトの setter をフック。playurl / DASH manifest 内の CDN host をリアルタイムに書き換え、ページ本来の挙動に影響を与えずにストリーミングノードの並べ替えを実現。Web 版プレーヤーの実測挙動に合わせて手法を調整し、playurl の書き換えだけでは再生中の動画に効かないため、セグメントリクエスト（.m4s）の host を直接書き換え

3. 03

   2 つの world をつなぐブリッジ構成とメッセージの信頼境界

   MAIN world からは chrome.storage / chrome.i18n などの拡張機能 API にアクセスできないため、ISOLATED world のブリッジスクリプトを設計し、postMessage / localStorage 経由で MAIN world と通信して設定と多言語の文言を同期。ページ上のどのスクリプトでも postMessage を偽装できるため、設定を書き込むメッセージ（自動速度測定の結果、ノード切り替え）は今回の測定対象リストまたはホワイトリスト内の CDN host のみを受け付け、サードパーティのスクリプトにユーザーのノードを恒久的に書き換えられることを防止

4. 04

   自動 Fallback によるフォールトトレランス

   セグメントリクエストの状態（403/404/5xx/タイムアウト）と再生の進行をリアルタイムに監視し、失敗や停止（8 秒間進行がなく、ネットワーク通信もない状態）を検知すると、まず Bilibili ネイティブのバックアップノードへ通知なしで切り替え、バックアップも機能しない場合にのみ通知を表示して、予備 URL への切り替えをユーザーの判断に委ねる

5. 05

   リアルタイムのノード速度測定ツール

   独立した速度測定ページで、「現在の動画・現在の画質」の実際のセグメントを使い、各 CDN ノードのダウンロード速度を 1 つずつ実測（8MB または 5 秒の早いほうで打ち切り）。ユーザーが現在使用中の CDN には影響しない。結果はスループットに応じて、そのノードで 8K／4K／1080P／720P が視聴できるか、カクつく可能性があるかを表示し、測定のしきい値は高速／標準／高精度の 3 つのプリセットからワンクリックで適用可能

6. 06

   ライブ配信のストリーミング経路選択

   パスに /live-bvc/ を含む FLV / m3u8 / fMP4 のストリームリクエストをインターセプトし、正規表現で ov|cn-gotcha<クラスタ番号> の host を解析して、ユーザーが選んだ経路（国際 / 中国 / それぞれの予備）に書き換えたうえで livePlayer.reload() を呼び出し、ページ全体を再読み込みせずにプレーヤー内でストリームを再取得。getRoomPlayInfo（ページの SSR で注入される roomInitRes を含む）をキャッシュして同じライブルームでは同じノードの組み合わせに固定し、経路が存在しない、失敗した、または停止した場合はその場で国際経路に戻す

7. 07

   ライブ配信の速度測定モデル

   FLV はビットレートに合わせてプッシュされるため、スループット≈ビットレートとなり余力を測れない。そこで 2 つの独立した指標を測る方式に変更。「チャンネル切り替え時のもたつき」（リクエストから最初の再生可能な音声・映像 tag／再生開始に必要なセグメントを受け取るまでの時間、N 回の平均）と「継続視聴時の遅れ秒数」で、後者は再生バッファモデルで max(0, 経過した実時間の秒数 − 受信済みの番組秒数) の最大値を算出（Skorokhod reflection）し、番組秒数は FLV では tag のタイムスタンプ、fMP4 では #EXTINF から計算。すべてネイティブの fetch を使って自身の hook を回避し、再生中の経路に干渉しない

8. 08

   地域に応じた自動経路選択と自動速度測定

   ノードリストを 67 の CDN プールにまたがる約 300 個に拡充し、Bilibili の zone API が返す国際電話の国番号から国を自動判定して、その国向けに CDN プールを分散させた推奨上位 10 ノードを適用。インストール後や国の切り替え時には、最初の動画でバックグラウンドの速度測定を 1 回自動実行して最速ノードに切り替え。オプションの「最速ノードへの自動切り替え」では、動画ごとにバックグラウンドで速度測定して最速ノードに切り替え、測定済みの動画を sessionStorage に記録し、世代カウンターによって手動測定が実行中の自動測定を途中で置き換えられるようにした

9. 09

   クラウドソーシング型の速度測定デスクトップツール CDNSpeedTest とデータ駆動のノード選定

   Python（tkinter + PyInstaller）で Windows 用 exe としてパッケージ化し、海外ユーザーが現地のネットワークで各ノードを実測できるようにした。「総帯域幅 × 0.5 ÷ Bilibili の 1 接続あたりの速度」で並列数を動的に決め、それをもとに所要時間を見積もる。システムの DNS が現地のものでない場合は Google DoH に切り替え、出口 IP の /24 を ECS として付与。ip-api / proxycheck、ローカルのデフォルトルートのネットワークアダプター、タイムゾーンのずれなど複数のシグナルで VPN を検出。Bilibili の QR コードログインの cookie はメモリ上にのみ保持。測定レポートは Google Apps Script 経由で Google Sheets と Neon（Postgres）に回収し、各国の ISP シェアで加重した「カバー率」をもとに、蓄積したレポートから国ごとのデフォルトノードと推奨リストを選定。さらに拡張機能内で国ごとに表示するお知らせ欄と、速度測定の協力者を募る抽選キャンペーンで、サンプルが不足している ISP を継続的に補完

10. 10

    プログラム間での安全なノードインポート

    ブラウザは外部プログラムから拡張機能の storage への書き込みを許可しないため、#cdnsw-import= という URL hash のディープリンクを設計。デスクトップツールが Chrome / Edge の Preferences と Firefox の extensions.json を読み取って拡張機能がインストールされているブラウザプロファイルを検出し、該当プロファイルでディープリンクを開くと、拡張機能自身が「カスタムノードリスト」に書き込む。background 側は組み込みのホワイトリストにあるノードのみを受け付け、任意のサイトがこの仕組みを悪用して動画を自分のドメインに誘導することを防止。推奨リストは同じ CDN プールから最大 2 個までとし、1 つのプールで障害が起きても他のプールに切り替えられるようにした

11. 11

    ワンクリック不具合報告と診断パイプライン

    拡張機能内の報告ダイアログで、バージョン、設定、直近 10 分間の診断イベント（ノード、速度、停止、自動切り替えの記録）を自動で添付。Cloudflare Worker（KV で IP ごとのレート制限）に送信したうえで、非公開の GitHub repo に完全なログを保存し、同時に公開 issue を作成してユーザーが対応状況を追えるようにし、Google Apps Script 経由で確認メールを送信。デバッグ用オーバーレイにはバッファ秒数、停止時間の計測、直近のイベントを同期表示

12. 12

    再現可能なビルド（Reproducible Build）

    純粋な Node.js スクリプト（jszip + sharp + puppeteer）で、同一のソースコードを Chrome / Edge / Firefox の 3 種類の manifest に合わせてそれぞれ zip にパッケージ化。ソースコードが変わらない限り、プラットフォームをまたいでも毎回出力される zip はバイト単位で完全に一致

13. 13

    ストア掲載素材の自動生成

    Puppeteer で実際の Bilibili 動画ページと拡張機能の画面を自動で開き、5 言語を順に切り替えて実際の素材を撮影したうえで、sharp で Chrome / Edge / Firefox、Mac、iPhone、iPad の 4 セットのストア用スクリーンショットと概要画像を合成

14. 14

    リリースフローの自動化

    5 言語の changelog.json で未公開（unreleased）の内容と各バージョンの内容を同時に管理し、パッケージ時には未公開の項目を自動で除外して機能の流出を防止。拡張機能の更新後、初めて設定メニューを開いたときに 1 回だけ「更新内容」を表示。changelog が更新されていない場合は git pre-push hook で push をブロック。Node.js スクリプトで Chrome / Edge / Firefox のストア API を通じてバージョンの下書きを自動アップロードし、Claude Code の skill でバージョン更新、release ブランチの作成、5 言語のストア文言の更新からメインラインへのマージまでの一連のフローをつなげた

15. 15

    Safari Web Extension（iOS + macOS）

    Xcode プロジェクトを作成し、同じ src/ の manifest、JS、HTML、言語ファイルをコピーせずに相対パスで直接参照。4 大ブラウザプラットフォームで単一のソースコードを共有し、Mac App Store に審査提出

16. 16

    フォーラムのフィードバックを軸にした改善と成長の追跡

    Bilibili 関連のフォーラムやコミュニティでのユーザーのフィードバックや議論を幅広く収集・追跡し、よくある課題を整理して修正の優先順位付けと機能改善の方向性に反映。3 つのストアの管理画面、GA、速度測定サンプルを自動集計して成長レポートを作成し、それをもとに次に注力する市場と補うべき ISP を決定

プロジェクト画像