Streamlinkは、ライブ配信のページURLからストリームを解決し、プレイヤーへ流す・ファイルへ録画するためのPython製CLIだ。動画ファイル取得の定番であるyt-dlpと混同されやすいが、扱う時間軸が違う。本記事はv8.5.0を実際にインストールし、同梱プラグイン数・日本のサービスの対応状況・--jsonの実出力を確認したうえで書いている。
--plugins を数えた結果この記事はライブ配信録画CLI「Streamlink」を解説します。自動化ツール全体の地図はAI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方をご覧ください。
30秒でわかる Streamlink
・進行中のライブ配信が対象。完成済みの動画ファイルはyt-dlpの担当
・実測で同梱プラグイン135件（v8.5.0）。うち日本のサービスが7件（ABEMA・ニコ生・OPENREC・radiko・ツイキャス・SHOWROOM・PIA ULIZA）
・本質は「ダウンローダー」ではなくストリーム解決器。出力先をプレイヤー・--record・--stdoutから選ぶ
・--retry-streamsで配信開始を待てる。cronと組み合わせれば自動録画になる
・--jsonで plugin・metadata・streams が機械可読に返るので、スクリプトから扱いやすい
法令遵守の前提：本記事は技術解説です。ライブ配信の録画可否は各サービスの利用規約と著作権法に従います。日本では2021年施行の改正著作権法により、違法配信と知りながら著作物をダウンロードする行為は刑事罰の対象です。私的複製の範囲を超える保存・再配布は行わないでください。
この記事のポイント
- 実測（v8.5.0）で同梱プラグインは135件、うち日本のサービスが7件。追加インストールは不要
- yt-dlpとの違いは対応数ではなく終端が確定しているかどうか。ライブは終わるまで走り続ける
--retry-streamsで配信開始を待って録画でき、--jsonで解決結果を機械可読に取り出せる
Streamlinkとは：「録画」と「ダウンロード」は時間軸が違う
Streamlinkの公式説明は「様々な配信サービスからビデオ・オーディオをメディアプレーヤーへパイプするCLIユーティリティ」だ。「ダウンローダー」と名乗っていないところに設計思想が出ている。
yt-dlpとの違いを「対応サイトの数」で比べても本質に届かない。決定的なのは、扱う対象の終端が確定しているかどうかである。
| 観点 | Streamlink | yt-dlp |
|---|---|---|
| 主対象 | 進行中のライブ配信 | 完成済みの動画・音声 |
| 終端 | 未定（配信が終わるまで走る） | 確定（尺が既知） |
| 進捗表示 | 経過時間・取得バイト数 | パーセンテージ |
| 標準の出力 | プレイヤーへパイプ／.tsへ録画 |
ファイル保存 |
| 開始待ち | --retry-streamsで待てる |
待つ機構は持たない |
| 実測の対応規模 | 135プラグイン（v8.5.0） | 1,400+サイト（公式表記） |
| ライセンス | BSD-2-Clause | Unlicense |
「対応数はyt-dlpのほうが1桁多いのだから、Streamlinkは要らないのでは」と考えたくなるが、この2つの数字は同じものを数えていない。yt-dlpの1,400+はアーカイブ済みコンテンツを含む総サイト数で、Streamlinkの135は「ライブ配信を解決できるプラグイン」の数だ。ライブに限れば後者のほうが手厚い領域が多い。
同梱プラグインを実測で数える——日本のサービスは7件
--pluginsでプラグイン一覧が出る。カンマ区切りの1行なので、そのまま数えると1件になってしまう。分解して数える。
# 同梱プラグインの件数を数える
streamlink --plugins \
| sed 's/^Available plugins: //' \
| tr ',' '\n' | sed 's/ //g' | grep -c .
v8.5.0での結果は135だった。このうち日本のサービスに対応するものを抜き出すと7件になる。
| プラグイン名 | サービス | 種別 |
|---|---|---|
abematv |
ABEMA | 動画配信 |
nicolive |
ニコニコ生放送 | ライブ配信 |
openrectv |
OPENREC.tv | ゲーム配信 |
radiko |
radiko | ラジオ |
twitcasting |
ツイキャス | ライブ配信 |
showroom |
SHOWROOM | ライブ配信 |
piaulizaportal |
PIA ULIZA | 配信基盤 |
海外向けではtwitch・youtube・kick・chzzk（韓国）・bilibili・douyin・soopなどが並ぶ。汎用のhls・dash・httpプラグインもあり、プラグインが無いサイトでもストリームURLを直接渡せば処理できる。この汎用プラグインの存在が、135という数字以上の守備範囲を生んでいる。
インストールと基本の使い方
Pythonのパッケージとして配布されている。pipで入るのが一番手軽だ。
# インストールとバージョン確認
python -m pip install -U streamlink
streamlink --version
# 利用可能な画質を一覧する（ダウンロードはしない）
streamlink "https://www.youtube.com/watch?v=XXXXXXXXXXX"
# 画質を指定してプレイヤーで再生する
streamlink "配信URL" best
# ファイルへ録画する
streamlink --record "output.ts" "配信URL" best
引数を1つだけ渡すと画質の一覧が表示されて終わる。これがStreamlinkの標準的な使い方で、best / worst / 1080p / 720pのような画質名を第2引数で指定して初めて処理が走る。yt-dlpの-fに相当するが、こちらは位置引数である点が違う。
処理の流れを図にすると次のようになる。
自動マッチ"] B --> C["ストリームを列挙
best / 1080p / worst …"] C --> D{"出力先"} D --> E["プレイヤーへパイプ
（既定）"] D --> F["--record file.ts
録画"] D --> G["--stdout
ffmpeg等へパイプ"] C --> H["--json
plugin/metadata/streams"]
--jsonで機械可読に扱う
Streamlinkがスクリプトに組み込みやすいのは、--jsonが用意されているからだ。実際にYouTubeの公開動画へ投げた出力（URLは長大なので省略）は次の構造だった。
{
"plugin": "youtube",
"metadata": {
"id": "jNQXAC9IVRw",
"author": "jawed",
"category": "Film & Animation",
"title": "Me at the zoo"
},
"streams": {
"240p": { "type": "http", "method": "GET", "url": "...", "headers": { "User-Agent": "..." } },
"worst": { "type": "http", "method": "GET", "url": "...", "headers": { "User-Agent": "..." } }
}
}
得られる情報は3層に分かれている。
・plugin — どのプラグインがマッチしたか。対応外URLの判定に使える
・metadata — id / author / category / title。録画ファイル名の材料になる
・streams — 画質ごとのtype / url / headers。実体のストリームURLとリクエストヘッダー
--jsonの出力を安易に貼らない：streams[].urlには配信基盤が発行した署名つきURLが入り、アクセス元のIPアドレスがクエリパラメータに含まれることがある。実際に手元で試した際も、YouTubeのvideoplayback URLに接続元IPv6アドレスが埋め込まれていた。issueやブログに貼るときは必ず削るか、pluginとmetadataだけを引用する。
自動録画：--retry-streamsと出力テンプレート
「配信が始まったら録る」を実現するのがStreamlinkの本領だ。素朴にcronで叩くと、配信前はエラー終了してしまう。--retry-streamsを使う。
# 30秒ごとに再試行して配信開始を待ち、始まったら録画する
streamlink \
--retry-streams 30 \
--retry-max 120 \
--record "~/rec/{author}/{id}-{time:%Y%m%d%H%M%S}.ts" \
"配信URL" best
--recordはテンプレート変数を受け付ける。公式ヘルプが例示している形式が{author} / {category} / {id} / {time:%Y%m%d%H%M%S}で、これは--jsonのmetadataと対応している。取得したメタデータがそのままファイル名になるので、後から探しやすい階層を最初に設計しておくとよい。
覚えておきたいオプションを整理する。
| オプション | 効果 |
|---|---|
--retry-streams DELAY |
DELAY秒ごとに再試行して配信開始を待つ |
--retry-max N |
再試行の上限回数。0だと無制限 |
--record FILE |
再生しつつファイルへ録画する |
--stdout |
標準出力へ流す。ffmpegへパイプする用途 |
--force |
既存ファイルがあっても上書きする |
--json |
解決結果をJSONで返す（録画はしない） |
--record-and-pipeは非推奨になっており、公式ヘルプが--stdout --record=FILENAMEへの置き換えを案内している。古い記事のコマンドをそのまま使うと将来動かなくなるので、ここは新しい書き方に寄せておきたい。
なお.tsのまま溜め続けるとファイルサイズが大きくなりやすい。配布や編集に回すなら、録画後にコンテナだけ差し替えるのが定石だ。
# 再エンコードせずコンテナだけmp4へ変換する
ffmpeg -i input.ts -c copy output.mp4
どれを選ぶか：静止画・動画・ライブ配信の分担
ダウンローダー系ツールは「どれが最強か」ではなく、対象の性質で分担するのが正しい。
| 対象 | 使うツール | 理由 |
|---|---|---|
| 進行中のライブ配信 | Streamlink | 終端未定のストリームに追従・開始待ちができる |
| 完成済みの動画・音声 | yt-dlp | フォーマット選択・字幕・後処理が充実 |
| 静止画ギャラリー | gallery-dl | 投稿者・タグ単位の集合を展開できる |
| チームで共有したい | MeTube | yt-dlpをWeb UI化してセルフホストできる |
補足として、アーカイブ済みの配信はyt-dlpのほうが素直なことが多い。Streamlinkが必要なのは「いま流れているもの」を掴む場面であり、終わったあとに取りに行くならyt-dlpで足りる。この線引きを持っておくと、ツール選定で迷わなくなる。
まとめ
・Streamlinkはストリーム解決器であって単純なダウンローダーではない。出力先をプレイヤー・録画・stdoutから選ぶ
・v8.5.0の実測で同梱プラグイン135件、うち日本のサービス7件（ABEMA・ニコ生・OPENREC・radiko・ツイキャス・SHOWROOM・PIA ULIZA）
・汎用のhls / dash / httpプラグインがあるため、専用プラグインが無いサイトも扱える余地がある
・--retry-streams＋--recordのテンプレートで自動録画が組める。--record-and-pipeは非推奨
・--jsonは機械可読で便利だが、署名つきURLに接続元IPが混ざることがあるので公開時は削る
参照ソース
- streamlink/streamlink — GitHub リポジトリ（★11,696 / BSD-2-Clause / 2026-08-19時点）
- Streamlink 公式ドキュメント
- Streamlink 8.5.0 リリース（2026-08-01公開）
- 実測環境：streamlink 8.5.0 / Python 3.14.4 / macOS 14.5 arm64（
--plugins・--json・--helpの出力）
