YouTubeを「広告なし・トラッキングなしで見たい」という需要は根強く、その代表格が Invidious（iv-org）だ。YouTubeの代替フロントエンド、つまり同じ動画に別の入口から入るためのWebアプリで、GitHubスターは20,666、ライセンスはAGPL-3.0、開発言語はCrystal（いずれも2026年7月25日時点・実測）。2018年2月に始まり、直近のリリース v2.20260723.0 は本記事執筆の2日前にあたる2026年7月23日に出ている。現役のプロジェクトだ。
ただし、2026年のInvidiousを語るうえで最初に押さえるべきは機能一覧ではない。「使わせてもらう」前提が崩れて、「自分で建てる」前提に移ったという運用面の変化のほうだ。この記事では公式のインスタンス一覧APIを実際に叩いた数字から始めて、仕組み・セルフホスト手順・そして見落とされがちなプライバシーの落とし穴までを、一次ソースで確認できる範囲だけで整理する。
- ・正体：YouTubeの代替フロントエンド。広告なし・トラッキングなし・JavaScript不要で、Googleアカウント抜きにチャンネル登録を管理できる。Crystal製・AGPL-3.0・★20,666。
- ・何ができる：広告の無い再生、音声のみモード（モバイルのバックグラウンド再生）、YouTube/NewPipe/FreeTubeとの購読データ相互インポート、埋め込み再生、開発者向けAPI。
- ・2026年の実態：公式インスタンス一覧APIを本日取得したところ登録は全12件、うちクリアネット（https）は6件、APIを開けているのは1件だけ。公開インスタンス頼みの使い方は細っている。
- ・だから何をするか：実用の重心はDocker Composeでのセルフホストへ移った。本体・companion・PostgreSQLの3コンテナ構成。
- ・最大の注意：既定では匿名にならない。公式FAQが明記するとおり、動画ストリームは既定でGoogle（googlevideo.com）から直接取得され、IPとUser-Agentは見られる。「Proxy videos」を自分で有効にして初めて中継される。
この記事ではセルフホスト型のプライバシー系ツールとしてInvidiousを解説します。自動化・運用ツール全般のカバレッジは AI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方 をご覧ください。
Invidiousとは？広告なし・トラッキングなしのYouTube代替フロントエンド
Invidiousは、YouTubeそのものを置き換えるサービスではない。YouTubeにある動画へ、別の画面から入るための入口である。動画やチャンネルのデータはYouTube側から取得しつつ、表示するUIを完全に自前で持つ。この構造上の違いが、そのまま機能の違いになる。
公式READMEが挙げる利用者側の特徴を整理すると、次のようになる。
・広告なし・トラッキングなし：再生前後や途中の広告が無く、Google側の行動追跡スクリプトも読み込まない
・軽量・JavaScript不要：JavaScriptを切ったブラウザでも動作する。古い端末やテキストブラウザ寄りの環境でも扱いやすい
・Googleアカウントから独立したチャンネル登録：購読情報はInvidious側（セルフホストなら自分のPostgreSQL）に保存される。Googleアカウントを作らずに購読管理ができる
・購読チャンネルの通知：登録した全チャンネルの新着を受け取れる
・音声のみモード：モバイルでのバックグラウンド再生に対応する。動画を閉じても音声だけ流し続けられる
・ライト/ダークテーマとホーム画面のカスタマイズ：表示する要素を自分で選べる
・Redditコメントの表示：YouTubeのコメント欄の代わりに、その動画に言及したRedditスレッドを読める
・多言語対応：Weblate上のコミュニティ翻訳で多数の言語に対応する
データの持ち出し・持ち込みにも力が入っている。YouTube・NewPipe・FreeTubeから購読リストをインポートでき、NewPipe/FreeTube向けにエクスポートもできる。視聴履歴もYouTubeとNewPipeから取り込める。特定のツールに囲い込まない設計が明示されているのは、この種のプロジェクトとしては重要な性質だ。
技術面では、埋め込み再生への対応と開発者向けAPIの提供が挙げられている。そして公式が明記している重要な一文が「YouTubeの公式APIは使っていない（Does not use official YouTube APIs）」だ。これはあとで触れる法的な位置づけと、YouTube側の変更で壊れやすいという運用上の性質、その両方に直結する。
① 何ができる：YouTubeの動画を、広告・追跡スクリプト・Googleアカウント無しで視聴し、購読を自分の手元で管理できる。
② 何を解決する：「見たいのは動画だけなのに、広告とレコメンドと行動追跡が付いてくる」という状態を切り離す。
③ 何を代替できる：YouTubeの視聴用UIとアカウント機能を代替する。動画のホスティングやアップロード、収益化は代替しない。あくまで既存のYouTube上の動画を見るための入口である。
2026年7月の実態：公開インスタンスは12件しか残っていない（実測）
Invidiousの入門記事の多くは「公開インスタンスの一覧から好きなものを選んで開けばいい」と書く。公式READMEのQuick startも実際そう案内している。だが2026年現在、その選択肢は驚くほど細っている。
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件・クリアネット（https）6件・APIを開けているのは1件だけだった。残りはTor（.onion）、I2P、Yggdrasilといったオーバーレイネットワーク上のアドレスで、通常のブラウザからは直接開けない。
uptimeが記録されている6件は99.79%〜92.78%と、稼働しているもの自体は概ね安定している。問題は数であり、選択肢の薄さだ。1つの公開インスタンスに人が集中すれば、そのIPからのアクセスは当然目立つ。
ここで気をつけたいのは、なぜ減ったのかを断定しないことである。個々のインスタンス運営者が閉じた理由は一覧APIには記録されていない。ただし、Invidiousが「YouTube側の仕様変更に追随し続けなければ動かない」性質であることは、公式のリリースノートから客観的に読み取れる。最新の v2.20260723.0（2026年7月23日）には、次の修正が並んでいる。
・YouTubeバックエンドのAPI変更によって発生した再生・メタデータの不具合への対応（#5818、#5819）
・YouTubeへのリクエストで使うUser-Agentヘッダの更新（互換性維持のため・#5794）
・YouTube側の変更で動画が誤って「配信予定（isUpcoming）」と表示される問題の修正（#5800）
・利用者間をまたいでプレイリストが削除できてしまう脆弱性の修正（#5790）
2日前のリリースにこれだけYouTube追随の項目が入るという事実が、このプロジェクトが置かれた状況を何より雄弁に語っている。運営を続けるには追い続ける必要がある。個人運営者がそこから降りていったとしても不思議はない、という程度の推測は成り立つが、それは推測であって実測ではない。
実測値の中でもう一つ目を引くのが、APIを開けているインスタンスが12件中1件しかないという偏りだ。これは偶然ではなく、プロジェクト側の動きと符合している。同じ v2.20260723.0 のリリースノートには、インスタンス運営者向けの新機能として「悪用されやすいAPIエンドポイントを無効化できる設定オプションを追加した（#5630）」が挙げられている。APIは開発者が外部からInvidiousのデータを扱うための入口だが、同時に自動化された大量アクセスの入口にもなる。運営者が閉じる方向へ動き、プロジェクトもそれを設定で支援する——という流れが、数字にそのまま表れている。
つまり「YouTube 代替のフロントエンドをAPI経由で自作ツールに組み込む」という使い方は、公開インスタンス前提では2026年時点でほぼ成り立たない。ここでもセルフホストが現実的な答えになる。自分のインスタンスなら、APIを開けるかどうかは自分の判断で決められる。
Invidiousの仕組み — companion方式とYouTubeとのいたちごっこ
では、YouTubeの公式APIを使わずにどうやって動画を再生しているのか。ここが2024年以降のInvidiousで最も大きく変わった部分だ。
companion方式 — 壊れやすい部分を切り離す
現在の推奨構成では、Invidious本体とは別に 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 という共有鍵で通信を守る、という設計だ。
Crystal / Kemal"] I <-->|"購読・設定・履歴"| DB[("PostgreSQL")] I -->|"共有鍵で委譲"| C["invidious companion
TypeScript / youtube.js"] C -->|"メタデータ・ストリームURL取得"| Y["YouTube"] C -->|"再生情報を返す"| I I -->|"HTML を返す"| U U -.->|"既定：動画データは直接取得
（IPがGoogleに見える）"| G["googlevideo.com"] U -.->|"Proxy videos 有効時のみ
インスタンスが中継"| I
この分離には運用上のはっきりした利点がある。YouTubeが仕様を変えたとき、多くの場合は companion側のイメージを更新するだけで復旧できる。本体のCrystalコードを触らずに済むぶん、追随が速くなる。公式のcompose定義でcompanionコンテナに cap_drop: ALL・read_only: true・no-new-privileges:true が指定されているのも、外部と最も接触する部分を絞り込むという同じ発想だ。
Crystal製ゆえの構造的な弱さと、AI_POLICY.md という回答
もう一つ、2026年のInvidiousを語るうえで外せない動きがある。プロジェクトが AI_POLICY.md という文書を新設したことだ（v2.20260723.0 のリリースノートに「AI寄稿に関するプロジェクトの姿勢を明確にするために作成」と記載され、Issue/PRテンプレートにもAIポリシー遵守の項目が追加された）。
この文書が興味深いのは、AIへの賛否ではなく プロジェクトが自分の弱点を率直に説明している点にある。要約すると、こうだ。
・Invidiousは Crystal という利用者の少ない言語で書かれている
・そのためCrystalを書ける人が少なく、貢献者も少ない。実際、貢献の大半はメンテナ自身が行っている
・InvidiousはCrystalで書かれた最大のソフトウェアであり（文書は Crystal 本体より大きいとまで書いている）、使える外部ライブラリがほとんど無いため、必要なものはたいてい自作するしかない
・結果として、他の多くのOSSより開発が難しくなっている
そのうえでポリシーは「AIの利用を禁止はしないが、条件を付けて許容する」という立場を取る。使ったモデル名とツール名を正確に開示すること、コードもバグ報告もAI任せにせず人間が手作業で検証すること、AIが部分的に書いたコードでも責任はその人間が負うこと、Invidiousの実機能に触れるコードは人間が手動でテストすること、そして常に human-in-the-loop を適用すること——が並ぶ。文書自体が冒頭で「これは人間が最初から全部書いた」と宣言しているのも徹底している。
AI生成コードの受け入れ方針を明文化するOSSは増えているが、Invidiousのそれは「選択ではなく必要から来た（This policy comes from a place of *need* not from a place of *choice*）」と自ら述べている点で異色だ。人手が足りない小さな言語圏のプロジェクトにとって、AI寄稿は歓迎すべき戦力なのか、レビュー負荷を増やす重荷なのか。この問いに対する実地の回答例として、開示義務と人間の最終責任をセットにした本ポリシーは参照する価値がある。文書は同時に「この方針に腹を立ててフォークして人手をさらに割らないでほしい」とも書いており、少人数プロジェクトの切実さがそのまま出ている。
Dockerでセルフホストする手順（本番構成）
公開インスタンスが12件という状況を踏まえると、Invidiousを安定して使いたいなら自分で建てるのが筋が通る。公式ドキュメントの本番向け手順は次のとおりだ。
なお、リポジトリ直下にある docker-compose.yml は開発用（ファイル冒頭に “made for development purposes” と明記されている）で、ローカルのソースからイメージをビルドする。本番で使うのは公式ドキュメントに載っている、ビルド済みイメージを使う定義のほうだ。
まずリポジトリを取得して、鍵を2つ生成する。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
① 鍵を使い回さない：公式コメントが明示的に警告している。`hmac_key` と `invidious_companion_key` は別々に生成する。companion側の `SERVER_SECRET_KEY` は `invidious_companion_key` と同じ値にする（ここだけ一致が必要）。
② この構成はリバースプロキシ前提：`127.0.0.1:3000:3000` は外部に開いていない。直接アクセスさせたい場合は `3000:3000` に変える。公開運用するならドメインとTLSの設定（`external_port` / `domain` / `https_only`）も併せて行う。
③ Docker Hubにイメージは無い：公式イメージはQuay（quay.io）でのみ配布されている。Quayの方がFOSSである、という理由が公式に説明されている。
セルフホストしたら、落ちたときに気づける仕組みも併せて用意しておきたい。同じくDocker Composeで建てられる外形監視OSSについては Checkmateとは：稼働監視OSSをDockerでセルフホスト｜Uptime Kuma比較と実測 で扱っている。複数のセルフホストサービスをまとめて載せる基盤を検討しているなら Openshipとは：セルフホストできるOSSデプロイ基盤（PaaS）をコードと実機で検証【2026】 も参考になる。
プライバシーは自動では守られない — 自分で確認する
ここが本記事で最も強調したい部分だ。「Invidiousを使えばYouTube（Google）から見えなくなる」という理解は、既定の設定では正しくない。
公式FAQは明確にこう書いている。動画ストリームは、Invidiousが必要とする帯域を減らすために 既定ではGoogleのサーバー（googlevideo.com）から直接取得される。つまり、ページのHTMLはInvidiousインスタンスから届くが、動画データそのものはあなたのブラウザがGoogleへ取りに行く。その結果、GoogleはあなたのIPアドレスと、User-Agentのようなブラウザが通常送る情報を見ることができる。
これを避けたい場合は、設定画面（preferences）で 「Proxy videos」を有効にする。有効にすると、インスタンスがあなたとGoogleの間の中継（プロキシ）として動作するため、Googleから見えるのはインスタンスのIPになる。URLに &local=1 を付けても同じ効果が得られる。
自分の環境が実際にどちらで動いているかは、推測せず確認できる。ブラウザの開発者ツールでNetworkタブを開いて動画を再生し、リクエスト先ドメインを見るのが最も確実だ。
# 1) ブラウザの開発者ツール → Network タブで動画を再生し、ドメインで絞り込む
# googlevideo.com への大きなリクエストが並ぶ → 既定のまま（IPはGoogleに見えている）
# 自分のインスタンスのドメインだけが並ぶ → Proxy videos が効いている
# 2) セルフホストなら、中継が発生しているかはコンテナの通信量でも傍証が取れる
docker compose stats --no-stream
# 3) Proxy videos を使わない場合に、どこへ出ていくかを名前解決で確認する
dig +short googlevideo.com
「Proxy videos」は無料の魔法ではない。有効にすると全ての動画データがインスタンスを通過するため、帯域とサーバー負荷が跳ね上がる。公開インスタンスが軒並みこれを既定オフにしているのは、そうしないと運営が成り立たないからだ。逆に言えば、セルフホストなら「自分の帯域を自分のプライバシーに使う」という判断を自分で下せる。これがセルフホストの実利のひとつである。
なお公式FAQは、DASH（高解像度再生）についても「正しく動作させるにはプロキシが必須で、インスタンスの帯域を大きく使う」と説明しており、既定で無効な理由として挙げている。
もう一点、公開インスタンスを使う場合の信頼の所在も整理しておきたい。Googleから隠れることは、インスタンス運営者からも隠れることを意味しない。購読リストも視聴履歴もそのインスタンスのデータベースに保存される。運営者が誰で、何を記録しているかを利用者は原理的に検証できない。この「信頼の預け先を移し替えているだけではないか」という論点は、セルフホスト型のプライバシーツール全般に共通する。同じ構図はアクセス解析でも起きており、Plausible Analyticsとは：GA4代替のプライバシー重視OSS解析をセルフホストで自前運用 でも、自前で持つことが何を解決し何を解決しないかを扱っている。
NewPipe・FreeTubeとの比較｜ライセンスと法的位置づけ
Invidiousと同じ「広告なしでYouTubeを見る」目的の選択肢は他にもある。決定的な違いは どこで動くかだ。
| Invidious | NewPipe | FreeTube | yt-dlp | |
|---|---|---|---|---|
| 形態 | サーバー側Webアプリ | Androidアプリ | デスクトップアプリ | CLIツール |
| 動く場所 | サーバー（自分 or 他人） | 自分のAndroid端末 | 自分のPC | 自分のPC |
| インストール | 不要（URLを開くだけ） | 必要 | 必要 | 必要 |
| 主目的 | 視聴 | 視聴 | 視聴 | ダウンロード |
| 購読データの置き場 | サーバー側DB | 端末内 | 端末内 | なし |
| 複数端末で共有 | できる | 端末ごと | 端末ごと | — |
| 直接のIP露出 | 既定はGoogleに露出（Proxy videosで回避可） | 自分の回線から直接 | 自分の回線から直接 | 自分の回線から直接 |
| ライセンス | AGPL-3.0 | GPL-3.0 | AGPL-3.0 | Unlicense |
Invidiousの固有の強みは、インストール不要で誰でも使えることと、購読・履歴をサーバー側に置いて複数端末から同じ状態で使えることにある。家族や少人数のグループに1台立てて共有する、といった使い方はInvidiousにしかできない。逆に、自分ひとりが自分の端末で見るだけならクライアント型のほうが構成は単純だ。
動画のダウンロードが主目的なら、そもそも用途が違う。yt-dlpは視聴用のUIを持たないCLIツールであり、Invidiousと競合するというより役割が別物だと考えたほうが正確だ。
ライセンス — AGPL-3.0 が意味すること
Invidiousのライセンスは AGPL-3.0（GNU Affero General Public License v3.0）で、companion側も同じくAGPL-3.0だ。GPLとの最大の違いは、ネットワーク越しにサービスとして提供する場合にもソース開示義務が及ぶ点にある。改変したInvidiousを公開インスタンスとして運用するなら、その改変ソースを利用者が入手できるようにする必要がある。個人が家庭内で改変せずに動かすぶんには実務上の負担はほぼ無いが、改変して公開運用する場合は事前に条文を確認しておきたい。この設計はInvidiousの思想と整合していて、「フォークして閉じたサービスにする」ことを難しくしている。
なお公式READMEは CLA（Contributor License Agreement）を要求しないことも明記している。貢献者に著作権の譲渡や特別な許諾を求めない方針だ。
法的な位置づけ — グレーであることを正直に書く
Invidiousは公式READMEが明言するとおり YouTubeの公式APIを使わずに YouTubeのデータを取得している。この方式がYouTubeの利用規約と整合するかについて、当サイトは法的判断を下す立場にない。事実として言えるのは次の点だ。
・公式APIを介さないアクセスであることをプロジェクト自身が明示している
・そのため、YouTube側の仕様変更で動作が壊れることが常態化しており、リリースノートに追随作業が繰り返し記録されている
・公開インスタンスを不特定多数向けに運用する行為と、個人が自分のために動かす行為とでは、想定される論点が異なる
公開インスタンスとして第三者に提供する運用を検討している場合は、自分の管轄地域の法令と規約を各自で確認してほしい。本記事は技術的な仕組みの解説であり、法的助言ではない。
まとめ：Invidiousは誰に向くか
2026年7月時点のInvidiousを、事実に基づいて位置づけると次のようになる。
向いている人
・広告とトラッキングを排したYouTube視聴環境を、自分の管理下で持ちたい人
・Googleアカウントに紐づかない購読管理を、複数端末で共有したい人
・Docker Composeを扱え、YouTube側の変更に追随して更新を続ける運用を引き受けられる人
・古い端末やJavaScriptを切った環境など、軽量なフロントエンドが必要な人
向いていない人
・「URLを開くだけで恒久的に安定して使えるサービス」を求める人。公開インスタンスは12件まで減っており、依存先としては細い
・設定を変えずに完全な匿名性が得られると期待する人。既定ではGoogleにIPが見える
・動画のダウンロードが主目的の人。それはyt-dlpなど別ツールの領域
・メンテナンスを継続できない人。建てて終わりにはならない
そして最も実務的に重要なのは、既定では匿名にならないという一点である。Proxy videosを有効にするか否かは帯域とプライバシーのトレードオフであり、その判断を自分で下せることこそがセルフホストの本当の価値だ。導入を検討するなら、まず自分の環境で動画データがどこへ取りに行っているかを開発者ツールで確認するところから始めてほしい。
参照ソース
・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件）
