「無料の IPTV プレイリスト(M3U)が GitHub にあるらしい」と聞き、検索してみると 12 万を超えるスターを集めた iptv-org/iptv というリポジトリにたどり着いた。そんな方は多いのではないでしょうか。動画アプリの検証用にライブストリームのサンプル源が欲しい、ホームラボで世界のテレビを試したい、といった用途で「これは使えそうだ」と感じる一方、いざ採用しようとすると不安が残ります。
「自分の用途に本当に合うのか」「Free-TV/IPTV など似たリポジトリと何が違うのか」「そもそも無料の IPTV プレイリストは合法なのか」「リンク切れだらけで放置されていないか」——こうした疑問に、VLC への貼り付け手順を説明するだけの記事は答えてくれません。エンジニアが採用を判断するには、リポジトリの内部構造・運用の仕組み・合法性の線引きまで踏み込んだ情報が必要です。
本記事では、iptv-org/iptv がどういう設計の OSS なのかを、公式の README・PLAYLISTS.md・CONTRIBUTING.md・FAQ.md などのドキュメントをもとに整理します。M3U プレイリストの分類構造、GitHub Actions による自動検証・更新の仕組み、Unlicense と合法性の考え方、そして Free-TV/IPTV や IPTV プレイヤー系 OSS との違いを比較し、「自分はこれを採用すべきか」を判断するための軸を提示します。
なお本記事は、実際にプレイリストを再生したり環境を構築したりせず、公開ドキュメントの記述にもとづいて解説します。動作の確実性そのものを保証するものではない点はあらかじめご了承ください。
iptv-org/iptvとは|無料で世界のIPTVチャンネルを集めるOSS
iptv-org/iptv は、世界中の公開済み IPTV(Internet Protocol television=インターネット回線を通じて配信されるテレビ)チャンネルのリンクを集約した OSS です。公式の説明では「Collection of publicly available IPTV channels from all over the world(世界中の公開済み IPTV チャンネルのコレクション)」と表現されています(iptv-org/iptv 公式リポジトリ)。
ここで重要なのは、このリポジトリが動画ファイルそのものを保存していないという点です。リポジトリが管理しているのは、ユーザーから投稿された「公開ストリーム URL へのリンク」だけであり、その実体(映像データ)は各放送局など外部のサーバー側にあります。この設計思想は後述する合法性の議論に直結する、プロジェクトの核となる考え方です。
使い方の基本は非常にシンプルで、プレイリスト(M3U 形式)の URL を、ライブストリーミングに対応した動画プレイヤー(VLC など)に貼り付けて開くだけです。メインのプレイリスト URL は次のとおり公開されています。
https://iptv-org.github.io/iptv/index.m3u
出典: iptv-org/iptv 公式リポジトリ(README)
数値で見る規模感
執筆時点(リポジトリメタデータ取得値)での基本情報を整理すると、このプロジェクトの規模と性質が見えてきます。
項目 | 値 |
|---|---|
スター数 | 125,910 |
フォーク数 | 6,879 |
主要言語 | TypeScript |
ライセンス | Unlicense(パブリックドメイン相当) |
公開状態 | public |
スター数が 12 万を超え、フォーク数も 6,800 以上という数字は、このカテゴリの OSS としては突出した規模です。主要言語が TypeScript なのは、プレイリストの生成・検証・整形を担う運用スクリプトが TypeScript で書かれているためで、プレイリスト自体は M3U というテキスト形式で配布されます。
このリポジトリはアーカイブされておらず(archived=false)、他リポジトリのフォークでもありません(fork=false)。本家としてアクティブに運用されている点は、採用を検討するうえで安心材料になります。リポジトリは無効化(disabled)もされておらず、最終更新(pushed_at)は日次で発生しています。
M3Uプレイリストの仕組みと提供形態(国・言語・カテゴリ別)
採用を判断するうえで最初に確認したいのが、「自分の用途に必要な粒度でチャンネルを取得できるか」という点です。iptv-org/iptv は、単一の巨大なプレイリストを配るだけでなく、複数の軸で分割されたサブプレイリストを提供しています。
そもそも M3U とは、再生対象のメディア URL を順番に並べたプレーンテキストのプレイリスト形式です。ライブ配信では中身が HLS(HTTP Live Streaming)などのストリームを指すことが多く、VLC をはじめとする多くのプレイヤーが標準で読み込めます。iptv-org/iptv のプレイリストもこの M3U 形式で配布されているため、対応プレイヤーがあれば追加のライブラリなしに開けます。
3つの分類軸とURLの使い分け
プレイリストは大きく 3 つの軸で分類され、それぞれにマスターのプレイリストと細分化されたサブプレイリストが用意されています(PLAYLISTS.md)。
分類軸 | 概要 | 規模の例 |
|---|---|---|
カテゴリ別 | Animation・Sports・News・Entertainment など 30 種類以上のジャンル | 最大は General(約 2,496ch)、次いで Entertainment(約 676ch) |
言語別 | ISO 639-3 コードに基づく 200 言語以上 | 最大は英語(約 2,471ch)。少数言語は 1 桁台 |
放送エリア別 | 国・地域(subdivision)・都市の階層構造 | countries / subdivisions / cities |
URL の構造は規則的で、iptv-org.github.io/iptv/ 上に次のような形でホストされています。
- マスター:
index.category.m3u/index.language.m3u/index.country.m3u - カテゴリ:
categories/[name].m3u(例:categories/animation.m3u) - 言語:
languages/[code].m3u(ISO 639-3 コード) - 地理:
countries/[code].m3u/subdivisions/[code].m3u/cities/[code].m3u
この規則性は、開発で利用する際に効いてきます。たとえば「日本のニュースだけ」「英語圏のアニメだけ」といった絞り込みをしたい場合、巨大なマスタープレイリストを取得してフィルタするのではなく、目的に合ったサブプレイリストの URL を直接指定できます。用途に応じて取得する粒度を選べる設計は、検証環境やアプリへの組み込みでデータ量を抑えたいケースで扱いやすい点です。
なお、2024 年 1 月に NSFW(職場閲覧非推奨)コンテンツの配信は終了しています(出典: PLAYLISTS.md)。
M3Uエントリの読み方(tvg-id/画質/ラベル)
プレイリストの中身を理解しておくと、再生時のトラブル切り分けや、アプリへ組み込む際のパースがやりやすくなります。iptv-org/iptv では、各チャンネルのストリームを streams/ ディレクトリ配下に国別の .m3u ファイルとして管理しており、1 エントリは次の形式で記述されます。
#EXTINF:-1 tvg-id="CHANNEL_ID",Title (QUALITY) [LABEL]
STREAM_URL
出典: CONTRIBUTING.md
各要素の意味は次のとおりです。
tvg-id: チャンネルの識別子。任意ですが推奨されており、後述の番組表(EPG)と突き合わせる際のキーになります。QUALITY: 解像度(例: 1080p / 720p)。任意。LABEL:Geo-blocked(地域制限)やNot 24/7(24 時間配信ではない)といった制約を示すラベル。任意。
加えて、ストリームによっては再生に特定の HTTP ヘッダ(User-Agent や Referrer)が必要な場合があり、それらは #EXTVLCOPT 行で指定できます。チャンネルの名称・ロゴ・カテゴリといったメタデータ自体はこのリポジトリには持たず、後述する iptv-org/database のチャンネル ID にひも付く形で管理されています。エントリに tvg-id が振られているのは、このデータベースと連携するためです。
どう使うか|プレイヤーへの読み込みと開発での活用
iptv-org/iptv の使い方は、用途によって大きく 2 段階に分けて考えられます。「とにかく再生したい」レベルと、「アプリやインフラに組み込みたい」レベルです。
最も基本的な使い方は、前述のとおりプレイリスト URL(例: https://iptv-org.github.io/iptv/index.m3u)を VLC などの対応プレイヤーに貼り付けて開くことです。特定のカテゴリや国だけを見たい場合は、マスターではなくサブプレイリストの URL を指定すれば絞り込めます。
一方、エンジニアが評価したいのはおそらく「再生だけでなく、開発に使えるか」でしょう。この観点では、iptv-org/iptv は単体のプレイリスト供給源にとどまらず、同じ org が管理する周辺リポジトリと組み合わせて使えるエコシステムを形成している点が特徴です。
リポジトリ | 役割 |
|---|---|
iptv-org/iptv(本体) | プレイリスト(M3U)の集約・公開 |
iptv-org/database | チャンネルのマスターデータ(名称・ロゴ・国・カテゴリ等)。データの誤り報告はここへ |
番組表(Electronic Program Guide)を取得するユーティリティ | |
iptv-org/api | プログラムからアクセスするための API ドキュメント・データ |
iptv-org/awesome-iptv | IPTV 関連リソース(対応アプリ等)のキュレーション |
たとえば「動画アプリのライブストリーム源として組み込む」場合、本体の M3U をそのまま読み込むだけでなく、番組表を表示したいなら iptv-org/epg を、チャンネルのロゴやカテゴリといった構造化データをプログラムから扱いたいなら iptv-org/api を併用する、という設計が成り立ちます。サブプレイリストでの絞り込みと組み合わせれば、「特定言語のニュースチャンネルだけを、番組表付きで表示するアプリ」のような構成も、自前でチャンネルを集めることなく実現できます。
このように、用途が「再生」で完結するのか「組み込み・自動化」まで広がるのかによって、評価すべき範囲が変わってきます。本体だけを見て「ただのプレイリスト」と判断すると、エコシステム全体が持つ価値を見落とすことになります。
自動更新と品質管理の仕組み(GitHub Actionsによる検証)
エンジニアが無料のプレイリストを採用する際、最大の懸念は「リンク切れが放置されていないか」「データ品質は担保されるのか」という点でしょう。手作業でメンテナンスされる種類のプレイリストは、時間とともにデッドリンクが増え、実用に耐えなくなりがちです。iptv-org/iptv がこの問題にどう対処しているかは、採用判断の中心になります。
このリポジトリのデータフローは、iptv-org/database をマスターとし、運用スクリプトと GitHub Actions のワークフローによって自動化されています。CONTRIBUTING.md には、主要な npm スクリプトとして次のものが挙げられています(出典: CONTRIBUTING.md)。
api:load: iptv-org/api から最新のチャンネル・ストリームデータをダウンロードするplaylist:format: URL の正規化・重複除去・無効 ID の除去・チャンネル名/品質/ラベル順のソートを行うplaylist:validate: 内部プレイリストの ID とリンクのエラーをチェックするplaylist:test: ストリームの到達性をテストするplaylist:generate: 公開用プレイリストを生成するplaylist:lint: 構文をチェックする
これらのスクリプトは、2 種類のワークフローによって運用に組み込まれています。
- check ワークフロー: 新規のプルリクエストが発生したタイミングで
api:loadや検証スクリプトを実行し、エラーが検出された場合はマージをブロックします。つまり、品質基準を満たさない変更がそもそも取り込まれない仕組みです。 - update ワークフロー: 毎日実行され、format(整形)・validation(検証)・generation(生成)・export(エクスポート)を自動で行います。
この「PR 時のゲートチェック」と「日次の自動更新」の二段構えが、iptv-org/iptv の品質を支える根拠です。リポジトリの最終更新が日次で発生しているのは、この update ワークフローが毎日プレイリストを再生成・検証しているためと考えられます。完全に手作業に依存するプレイリストと比べて、リンク切れが放置されにくい構造になっている点は、エンジニアにとって大きな評価ポイントになります。
ただし、自動テストが到達性を確認していても、個々のストリームが常に再生できることまで保証されるわけではありません。地域制限(Geo-blocked)や 24 時間配信ではない(Not 24/7)チャンネルが存在することは前述のとおりで、これらはラベルで明示されています。仕組みとして品質を担保しようとしている一方で、ストリーム側の都合による不確実性は残る、という前提で評価するのが適切です。
類似OSSとの違いと選び方(Free-TV/IPTV・プレイヤー系との比較)
「無料の IPTV プレイリストはどれを使えばいいのか」という問いに答えるには、似たプロジェクトとの違いを軸で整理する必要があります。ここでは代表的な 2 つのタイプと比較します。
iptv-org/iptvとFree-TV/IPTVの違い
最も比較されやすいのが Free-TV/IPTV です。こちらも無料テレビチャンネルの M3U プレイリストを提供する OSS ですが、設計思想が対照的です。
観点 | iptv-org/iptv | Free-TV/IPTV |
|---|---|---|
提供形態 | 国・言語・カテゴリの 3 軸で分割された多数のサブプレイリスト | 単一プレイリストが中心 |
重視する価値 | 世界網羅性・多軸分類・エコシステム連携 | 動作確実性・HD 画質優先 |
チャンネル選定 | 公開ストリームを幅広く収集 | 「ちゃんと動く」チャンネルを重視し、SD より HD を優先 |
規模 | スター 125,910・フォーク 6,879 と大規模 | iptv-org より小規模 |
Free-TV/IPTV は、プレイヤーに https://raw.githubusercontent.com/Free-TV/IPTV/master/playlist.m3u8 を指定して使う単一プレイリスト型で、「全チャンネルがきちんと動くこと」と「HD 画質」を優先しています(出典: Free-TV/IPTV)。網羅性よりも確実性に振った設計といえます。
つまり両者は「網羅性 vs 確実性」というトレードオフの両端に位置します。世界中の多様なチャンネルを多軸で扱いたい・エコシステムと連携したいなら iptv-org/iptv、まず確実に動く HD チャンネルを手軽に再生したいなら Free-TV/IPTV、という棲み分けで考えると選びやすくなります。
供給源とプレイヤーの役割分担
もう一つ混同しやすいのが、IPTVnator(4gray/iptvnator)のような IPTV プレイヤーアプリとの関係です。IPTVnator はオープンソースかつクロスプラットフォームの IPTV プレイヤーで、m3u / m3u8 の読み込み、お気に入り、TV アーカイブ(catchup)などに対応しています(出典: WebSearch による各プロジェクト情報)。
ここで押さえたいのは、iptv-org/iptv は「プレイリスト=コンテンツの供給源」であり、IPTVnator は「プレイリストを再生する側のプレイヤー」だという役割の違いです。両者はレイヤーが異なるため競合ではなく補完関係にあり、「iptv-org/iptv の M3U を IPTVnator で開く」という組み合わせが自然に成立します。
なお、対応するプレイヤーやツールを探したい場合は、同じ org が管理する iptv-org/awesome-iptv が IPTV 関連リソースのキュレーションリストとして参照先になります。VLC・Jellyfin・Kodi・TiviMate なども M3U を読み込める代表的なプレイヤーです。
このように、自分が探しているのが「コンテンツの供給源」なのか「再生環境」なのかを切り分けると、iptv-org/iptv が自分の用途のどの位置を埋めるものなのかがはっきりします。
ライセンスと合法性・利用時の注意点
無料の IPTV プレイリストを採用する際、エンジニアにとって最大のブロッカーになりがちなのが「これは合法なのか」という不安です。ここは曖昧な注意喚起ではなく、公式ドキュメントの記述にもとづいて線引きを整理します。
まずライセンスについて。iptv-org/iptv は Unlicense(パブリックドメイン相当)を採用しています。Unlicense は著作権を実質的に放棄し、誰でも自由に利用・改変・再配布できることを意図したライセンスで、リポジトリ内のコードやデータの利用に制約はほとんどありません。
次に合法性の核心です。前述のとおり、このリポジトリは動画ファイルを一切保存していません。管理しているのは、すでに公開されているストリーム URL へのリンク集です。公式の Legal セクションでは、収録されているのは「コピーライトホルダーによって意図的に公開されたと我々が認識している、公開ストリーム URL へのユーザー投稿リンク」であり、リンク先の実体はメンテナーの管理下にないと説明されています(出典: iptv-org/iptv 公式リポジトリ(README / Legal セクション))。著作権を侵害するリンクが見つかった場合は issue で削除を依頼できますが、リンク先の実体そのものは GitHub 側では削除できない、という線引きも明示されています。
ここから導かれる実務的な注意点は次のとおりです。
- 「無料 IPTV =即違法」というわけではありません。リポジトリ自体は公開リンクの集約であり、リンクという行為自体は複製を伴わないという立場が示されています。
- ただし、リンク先のコンテンツの権利関係や地域制限は利用者側で確認する必要があります。
Geo-blockedラベルが付いたチャンネルは地域制限があり、配信元の許諾範囲は個々のストリームごとに異なります。 - FAQ では、技術仕様面の制約も明示されています。Xtream Codes 形式のストリームは不安定なため非対応、VOD(ビデオオンデマンド)は対象外、映像付きラジオは映像と音声を同時に含む場合のみ受け入れ、といった条件です(出典: FAQ.md)。
業務システムや公開プロダクトに組み込む場合は、リンク先の各放送局の利用規約・地域制限を個別に確認することが前提になります。「リポジトリのライセンスが自由(Unlicense)であること」と「リンク先コンテンツを自由に使えること」は別問題である、という区別が重要です。
まとめ|iptv-org/iptvが向いているケース
iptv-org/iptv は、世界中の公開 IPTV チャンネルを M3U プレイリストとして集約し、国・言語・カテゴリの 3 軸で取得粒度を選べる OSS です。GitHub Actions による PR 時のゲートチェックと日次の自動更新によって、無料プレイリストにありがちな「リンク切れの放置」を仕組みで抑えようとしている点が、技術的な差別化の中心でした。
採用判断の軸を整理すると、次のように考えられます。
iptv-org/iptvが向くケース: 世界網羅性・多軸分類が必要、番組表(epg)や API(api)と連携してアプリに組み込みたい、自動検証されたメンテナンス性を重視する場合。- Free-TV/IPTV も候補になるケース: 網羅性より「まず確実に動く HD チャンネル」を手軽に再生したい場合。単一プレイリストの確実性に価値を感じるなら有力です。
- そもそもレイヤーが違うもの: IPTVnator などのプレイヤー系は再生側であり、
iptv-org/iptv(供給源)と組み合わせて使うものです。
加えて、ライセンスは Unlicense でリポジトリ自体の利用は自由ですが、リンク先コンテンツの権利関係・地域制限は利用者側の確認が必要、という線引きを押さえておくことが、業務利用での前提になります。
本体の iptv-org/iptv を起点に、database・epg・api・awesome-iptv といったエコシステムへ広げていけるのが、このプロジェクトの強みです。自分の用途が「再生で完結するのか」「組み込み・自動化まで広がるのか」を見極めたうえで、まずは公式リポジトリのドキュメントとプレイリスト URL の構造を確認することから始めるとよいでしょう。詳細はiptv-org/iptv 公式リポジトリを参照してください。



