概要
Invidious（iv-org/invidious）は YouTube のプライバシー重視フロントエンド。AGPL-3.0、star 23,597（2026年9月時点）でリポジトリはアーカイブされておらず、本体の開発は生きている。
広告なし・ログイン不要・Google の追跡なし、モバイルでのバックグラウンド再生、Google アカウントなしでのチャンネル購読と YouTube 購読リストのインポート、といった機能は公式ドキュメントで実在を確認できる。
問題は機能ではなく到達性にある。
公開インスタンスの減少
公式が インスタンス一覧を JSON で公開している。Wayback Machine のスナップショットと比較すると、HTTPS インスタンスは 2023年12月の32件から7件に減少。公開 REST API を有効にしているインスタンスは1件も残っていない。
稼働率100%でも到達できない — 二層のゲート
監視サイトの稼働率は 97〜100% と表示されるのに、素の HTTP クライアントで到達できたのは 5件中0件だった。内訳は次のとおり。
| 事象 | 件数 |
|---|---|
| HTTP 200 で本文に「503」と書かれたページ | 1 |
| Anubis のボットゲート | 3 |
| Cloudflare のボットゲート | 1 |
到達を阻むゲートは独立した二層で、可用性はその積で決まる。
- ゲート①は運営者が置く — Anubis や Cloudflare。スクレイパーの負荷から自分のサーバを守るためで、Google とは無関係の運営コスト側の問題
- ゲート②は Google が置く — 判定材料は送信元 IP の出自。公式ドキュメントは「It is known that YouTube block datacenter and VPN IP addresses.」と明記している
RSS フィードは通ることがある
/feed/ をゲートから除外している運営者もおり、RSS は5件中2件で今も生きている。動画視聴が塞がれていても購読フィードだけは使える構成がありうる。
セルフホストの前提
「完全な制御が欲しいなら自分でホストできる」は条件付きで正しい。
- インストール手順は docker-compose 推奨で素直（
docker compose up -d） - 「自己ホストの方がずっと良い」は家庭回線の IP から出る場合に限る。 データセンター IP は公式ドキュメントがブロック対象と明記しており、VPS に立てるとゲート②に当たる
invidious-companionが必須。旧来のinv_sig_helperはアーカイブ済み- この領域は1年で陳腐化するため、手順は必ず公式ドキュメントで確認する
教訓 — 稼働率の読み方
一番持ち帰る価値があるのはここ。稼働率 97〜100% と到達5件中0件が同時に成り立つのは、監視が「200 が返ること」を測っていて「目的を果たせること」を測っていないからである。
監視の対象が実際のユースケースから一段ずれていると、ダッシュボードは緑のまま壊れる。 稼働率 100.0% のインスタンスが HTTP 200 で「503」と書かれたページを返していた例が象徴的で、HTTP 200 は生存の証明にならない。