Invidiousとは｜広告なしYouTube代替の公開インスタンスまとめとDockerセルフホスト手順

YouTubeを「広告なし・トラッキングなしで見たい」という需要の代表格が Invidious（iv-org）だ。同じ動画に別の入口から入るためのWebアプリで、GitHubスターは20,666、ライセンスはAGPL-3.0、開発言語はCrystal（いずれも2026年7月25日時点・実測）。2018年2月に始まり、直近のリリース v2.20260723.0 は2026年7月23日に出ている現役のプロジェクトだ。

ただし2026年のInvidiousで最初に押さえるべきは機能一覧ではなく、「使わせてもらう」前提から「自分で建てる」前提に移ったという運用面の変化だ。公式のインスタンス一覧APIを叩いた数字から始めて、仕組み・セルフホスト手順・プライバシーの落とし穴までを、一次ソースで確認できる範囲だけで整理する。

この記事ではセルフホスト型のプライバシー系ツールとしてInvidiousを解説します。自動化・運用ツール全般のカバレッジは AI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方 をご覧ください。

Invidiousとは？広告なし・トラッキングなしのYouTube代替フロントエンド

Invidiousは、YouTubeそのものを置き換えるサービスではない。YouTubeにある動画へ、別の画面から入るための入口である。データはYouTube側から取得しつつ、UIを自前で持つ。

公式READMEが挙げる利用者側の特徴は次のとおり。

・広告なし・トラッキングなし：広告が無く、Google側の行動追跡スクリプトも読み込まない
・JavaScript不要：JavaScriptを切ったブラウザでも動く
・Googleアカウントから独立したチャンネル登録：購読情報はInvidious側（セルフホストなら自分のPostgreSQL）に保存され、全チャンネルの新着通知も受け取れる
・音声のみモード：モバイルでのバックグラウンド再生に対応する
・Redditコメントの表示：コメント欄の代わりに、その動画に言及したRedditスレッドを読める
・テーマ・ホーム画面のカスタマイズと多言語対応（Weblate上のコミュニティ翻訳）

YouTube・NewPipe・FreeTubeから購読リストをインポートでき、NewPipe/FreeTube向けにエクスポートもできる。視聴履歴もYouTubeとNewPipeから取り込める。特定のツールに囲い込まない設計が明示されている。

公式が明記している重要な一文が「YouTubeの公式APIは使っていない（Does not use official YouTube APIs）」だ。これは後で触れる法的な位置づけと、YouTube側の変更で壊れやすいという運用上の性質の両方に直結する。代替できるのはYouTubeの視聴用UIとアカウント機能で、動画のホスティングやアップロード、収益化は代替しない。

2026年7月の実態：公開インスタンスは12件しか残っていない（実測）

入門記事の多くは「公開インスタンスの一覧から好きなものを選んで開けばいい」と書き、公式READMEのQuick startもそう案内している。だがInvidiousはインスタンス一覧を機械可読なJSONで公開しているので、実測できる。2026年7月25日に取得した手順が次だ。

# 公式のインスタンス一覧APIを取得して内訳を数える
curl -s https://api.invidious.io/instances.json -o instances.json

python3 - <<'PY'
import json, collections
d = json.load(open("instances.json"))
print("登録インスタンス総数:", len(d))
print("種別:", collections.Counter(info.get("type") for _, info in d))
print("API有効:", sum(1 for _, info in d if info.get("api")))
for name, info in d:
    mon = info.get("monitor") or {}
    print(f"{name:40s} type={info.get('type')} api={info.get('api')} uptime={mon.get('uptime')}")
PY

結果は冒頭の図のとおり、登録12件・クリアネット6件・API有効1件。残りはTor（.onion）、I2P、Yggdrasil上のアドレスで、通常のブラウザからは開けない。uptimeが記録されている6件は99.79%〜92.78%で、稼働自体は安定している。問題は数だ。1つの公開インスタンスに人が集中すれば、そのIPからのアクセスは目立つ。

なぜ減ったのかは断定しない。運営者が閉じた理由は一覧APIに記録されていない。ただ、追随し続けなければ動かない性質はリリースノートから読み取れる。v2.20260723.0 には次の修正が並ぶ。

・YouTubeバックエンドのAPI変更による再生・メタデータの不具合への対応（#5818、#5819）
・YouTubeへのリクエストで使うUser-Agentヘッダの更新（#5794）
・YouTube側の変更で動画が誤って「配信予定（isUpcoming）」と表示される問題の修正（#5800）
・利用者間をまたいでプレイリストが削除できてしまう脆弱性の修正（#5790）

APIを開けているのが12件中1件という偏りは、プロジェクト側の動きと符合する。同じリリースに、運営者向けの「悪用されやすいAPIエンドポイントを無効化できる設定オプション」（#5630）が入った。APIは自動化された大量アクセスの入口にもなるので、運営者が閉じる方向へ動き、プロジェクトもそれを支援している。公開インスタンス前提で「API経由で自作ツールに組み込む」使い方は、2026年時点ではほぼ成り立たない。自分のインスタンスなら、APIを開けるかは自分で決められる。

Invidiousの仕組み — companion方式とAI_POLICY.md

現在の推奨構成では、本体とは別に invidious companion という外部プログラムが動く。公式リポジトリ iv-org/invidious-companion の説明は「動画ストリームの処理を担当する、youtube.js ベースのコンパニオン」。TypeScript製・AGPL-3.0・2024年9月作成、直近のpushは2026年7月23日（★198、2026年7月25日時点・実測）。

最もYouTube側の変更に晒される「動画ストリームを取ってくる」処理だけを別プロセスに切り出した構成だ。config/config.example.yml では、本体側が invidious_companion に private_url を書いてリクエストを委譲し、両者は invidious_companion_key という共有鍵で通信を守る。YouTubeが仕様を変えたとき、多くの場合は companionのイメージを更新するだけで復旧できる。公式のcompose定義でcompanionに cap_drop: ALL・read_only: true・no-new-privileges:true が付いているのも、外部と最も接触する部分を絞る発想だ。

もう一つの動きが AI_POLICY.md の新設だ（v2.20260723.0 のリリースノートに「AI寄稿に関するプロジェクトの姿勢を明確にするために作成」とあり、Issue/PRテンプレートにもAIポリシー遵守の項目が入った）。文書はプロジェクトの弱点を率直に説明している。Crystalは利用者が少なく、貢献の大半はメンテナ自身が行っている。InvidiousはCrystalで書かれた最大のソフトウェアで（Crystal本体より大きいとまで書いている）、使える外部ライブラリがほとんど無い。

そのうえでポリシーは、AIを禁止せず条件付きで許容する。使ったモデル名とツール名を正確に開示すること、コードもバグ報告も人間が手作業で検証すること、AIが部分的に書いたコードでも責任はその人間が負うこと、実機能に触れるコードは手動でテストすること、常に human-in-the-loop を適用すること。文書自体も冒頭で「人間が最初から全部書いた」と宣言し、方針が「選択ではなく必要から来た（This policy comes from a place of need not from a place of choice）」と述べる。人手の足りない小さな言語圏のプロジェクトが、開示義務と人間の最終責任をセットにした実例として参照する価値がある。

Dockerでセルフホストする手順（本番構成）

リポジトリ直下の docker-compose.yml は開発用（冒頭に “made for development purposes” と明記）で、ローカルのソースからビルドする。本番で使うのは公式ドキュメントにある、ビルド済みイメージを使う定義だ。PostgreSQLに初期化スクリプトとSQLディレクトリをマウントするため、cloneは要る。

git clone https://github.com/iv-org/invidious.git
cd invidious

# 秘密鍵を2つ生成する（本体用 HMAC_KEY と companion 用は必ず別の値にする）
pwgen 16 1   # 1つ目：Invidious 本体の hmac_key
pwgen 16 1   # 2つ目：invidious_companion_key

docker-compose.yml を本番用の3サービス（本体・companion・PostgreSQL）に置き換える。

services:
  invidious:
    image: quay.io/invidious/invidious:latest
    restart: unless-stopped
    # 外部IPから直接アクセスさせる場合は "127.0.0.1:" を外す
    ports:
      - "127.0.0.1:3000:3000"
    environment:
      INVIDIOUS_CONFIG: |
        db:
          dbname: invidious
          user: kemal
          password: kemal
          host: invidious-db
          port: 5432
        check_tables: true
        invidious_companion:
        - private_url: "http://companion:8282/companion"
        invidious_companion_key: "CHANGE_ME!!"   # 2つ目の鍵
        hmac_key: "CHANGE_ME!!"                  # 1つ目の鍵
    healthcheck:
      test: wget -nv --tries=1 --spider http://127.0.0.1:3000/api/v1/stats || exit 1
      interval: 30s
      timeout: 5s
      retries: 2
    depends_on:
      - invidious-db

  companion:
    image: quay.io/invidious/invidious-companion:latest
    environment:
      - SERVER_SECRET_KEY=CHANGE_ME!!   # invidious_companion_key と同じ値
    restart: unless-stopped
    cap_drop:
      - ALL
    read_only: true
    volumes:
      - companioncache:/var/tmp/youtubei.js:rw
    security_opt:
      - no-new-privileges:true

  invidious-db:
    image: docker.io/library/postgres:14
    restart: unless-stopped
    volumes:
      - postgresdata:/var/lib/postgresql/data
      - ./config/sql:/config/sql
      - ./docker/init-invidious-db.sh:/docker-entrypoint-initdb.d/init-invidious-db.sh
    environment:
      POSTGRES_DB: invidious
      POSTGRES_USER: kemal
      POSTGRES_PASSWORD: kemal
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U $$POSTGRES_USER -d $$POSTGRES_DB"]

volumes:
  postgresdata:
  companioncache:

起動して稼働を確かめる。

docker compose up -d

# 3コンテナが healthy になっているか
docker compose ps

# 本体が応答しているか（healthcheck と同じエンドポイント）
curl -s http://127.0.0.1:3000/api/v1/stats | head -c 400

落ちたときに気づける仕組みも用意しておきたい。Docker Composeで建てられる外形監視OSSは Checkmateとは：稼働監視OSSをDockerでセルフホスト｜Uptime Kuma比較と実測 で扱っている。複数のセルフホストサービスを載せる基盤なら Openshipとは：セルフホストできるOSSデプロイ基盤（PaaS）をコードと実機で検証【2026】 も参考になる。

プライバシーは自動では守られない — 自分で確認する

「Invidiousを使えばGoogleから見えなくなる」という理解は、既定の設定では正しくない。公式FAQによれば、動画ストリームは帯域を減らすため 既定ではGoogleのサーバー（googlevideo.com）から直接取得される。ページのHTMLはインスタンスから届くが、動画データはブラウザがGoogleへ取りに行くので、GoogleはあなたのIPアドレスとUser-Agentを見られる。

避けたいなら、設定画面（preferences）で 「Proxy videos」を有効にするか、URLに &local=1 を付ける。インスタンスが中継するので、Googleから見えるのはインスタンスのIPになる。代わりに全動画データがインスタンスを通り、帯域と負荷が跳ね上がる。公開インスタンスがこれを既定オフにしているのはそのためで、公式FAQはDASH（高解像度再生）にもプロキシが必須だと説明している。セルフホストなら、自分の帯域を自分のプライバシーに使う判断を自分で下せる。

自分の環境がどちらで動いているかは、ブラウザの開発者ツールでリクエスト先ドメインを見るのが確実だ。

# 1) ブラウザの開発者ツール → Network タブで動画を再生し、ドメインで絞り込む
#    googlevideo.com への大きなリクエストが並ぶ → 既定のまま（IPはGoogleに見えている）
#    自分のインスタンスのドメインだけが並ぶ → Proxy videos が効いている

# 2) セルフホストなら、中継が発生しているかはコンテナの通信量でも傍証が取れる
docker compose stats --no-stream

# 3) Proxy videos を使わない場合に、どこへ出ていくかを名前解決で確認する
dig +short googlevideo.com

Googleから隠れることは、インスタンス運営者から隠れることを意味しない。公開インスタンスでは購読リストも視聴履歴もそのデータベースに保存され、運営者が何を記録しているかを利用者は検証できない。信頼の預け先を移し替えているだけではないか、という論点はセルフホスト型のプライバシーツール全般に共通し、Plausible Analyticsとは：GA4代替のプライバシー重視OSS解析をセルフホストで自前運用 でも、自前で持つことが何を解決し何を解決しないかを扱っている。

NewPipe・FreeTubeとの比較｜Invidiousのライセンスと法的位置づけ

同じ「広告なしでYouTubeを見る」選択肢との決定的な違いは どこで動くかだ。

Invidiousの強みは、インストール不要で誰でも使えることと、購読・履歴をサーバー側に置いて複数端末で共有できることだ。家族や少人数のグループに1台立てて共有する使い方はInvidiousにしかできない。自分ひとりが自分の端末で見るだけなら、クライアント型のほうが構成は単純だ。yt-dlpは視聴用UIを持たないダウンロード用CLIで、役割が別物と考えたほうが正確だ。

ライセンスは本体・companionとも AGPL-3.0 で、ネットワーク越しにサービスとして提供する場合にもソース開示義務が及ぶ。改変して公開インスタンスを運用するなら、改変ソースを利用者が入手できるようにする必要がある。家庭内で改変せずに動かすぶんには実務上の負担はほぼ無い。公式READMEは CLA（Contributor License Agreement）を要求しないことも明記している。

法的な位置づけについて、当サイトは判断を下す立場にない。事実として言えるのは、公式APIを介さないアクセスであることをプロジェクト自身が明示していること、YouTube側の変更で壊れることが常態化してリリースノートに追随作業が繰り返し記録されていること、公開インスタンスを不特定多数向けに運用する行為と個人が自分のために動かす行為では論点が異なること、の3点だ。第三者に提供する運用を検討しているなら、自分の管轄地域の法令と規約を各自で確認してほしい。本記事は技術的な仕組みの解説であり、法的助言ではない。

導入を検討するなら、まず自分の環境で動画データがどこへ取りに行っているかを、開発者ツールで確かめるところから始めてほしい。

参照ソース

・iv-org/invidious（公式リポジトリ・README） — 機能一覧、AGPL-3.0、「公式APIを使わない」「CLA不要」の記述、スクリーンショット
・Invidious 公式ドキュメント — Installation — 本番用docker-compose定義、鍵生成手順、Quay配布の理由
・Invidious 公式ドキュメント — FAQ — 既定でgooglevideo.comから直接取得する挙動、Proxy videos / &local=1、DASHとプロキシの関係
・iv-org/invidious-companion — youtube.jsベース・TypeScript・AGPL-3.0・★198（2026-07-25実測）
・Release v2.20260723.0 — YouTube側変更への追随（#5794, #5800, #5818, #5819）、プレイリスト削除の脆弱性修正（#5790）、AI_POLICY.md新設
・AI_POLICY.md — AI寄稿の開示義務・人間による検証・human-in-the-loopの方針
・api.invidious.io/instances.json — 公開インスタンス一覧（2026-07-25取得：全12件／クリアネット6件／API有効1件）