更新日 2026年10月10日

KickのクリップとVOD: リンクがダウンローダーに伝えること

Kickは貼り付けたリンクに応じて3つの異なる問いに答えます。クリップ、過去の配信、あるいはたまたま今ライブ中のチャンネルです。ダウンローダーはまずURLを読み取り、正しいほうを選びます。

Kick自身のアドレス構造が、手にしているものの最も分かりやすい地図です。クリップは短い編集済みの一場面。VODは完全な過去の配信です。チャンネルページはどちらでもなく、そのとき配信者がライブ中ならダウンロードするものはありません。ライブ配信には終わりがないので、ファイルもないのです。

3つのリンクと、それぞれが何になるか

クリップIDには決まった形があります。clip_の後にULID風のコードが続く形なので、リゾルバはネットワーク呼び出しなしでそれと分かります。IDだけでは不十分です。KickのAPIはパスにチャンネルを求めるため、IDだけを貼り付けると、もっと情報を求めて返ってきます。

画質はどこから来るか

VODの場合、KickはHLSのマスタープレイリストを公開します。すべてのレンディションを列挙した小さなテキストファイルで、それぞれが独自の解像度、帯域幅、フレームレートを持ちます。リゾルバはそのマスターだけを読み、それ以外は読みません。フラグメントはダウンロードせず、統合済みファイルをKickに求めることもありません。Kickが提供していないからです。

• 各レンディションはその解像度で利用できる最良のビットレートを保つため、一覧に同じ解像度の項目が2つ表示されることはありません。
• バリアントは帯域幅の高い順に並びます。最上段がソースです。
• 50 fps以上のレンディションはフレームレート付きで表示されます（例: 1080p60）。それ未満では高さだけがラベルになります。
• マスターを解析できない場合、リゾルバはプレイリスト自体を指す単一のsource項目にフォールバックします。

クリップはもっと単純です。たいていはクリップが切り出された画質のファイルを1つだけ持つため、クリップのダウンロードで何かを選ばされることはほとんどありません。

ライブ配信が拒否される理由

ライブ配信はファイルではなく、流れ続けるウィンドウです。Kickはライブ中のチャンネルを3か所でライブと報告します。VODオブジェクト、チャンネルの動画一覧、そしてチャンネルページ自体です。リゾルバはその3つすべてを同じ答えliveに変えます。代わりにクリップかVODをお試しください。

エラーに見えてそうでない状態が2つあります。processingは、配信が数分前に終わり、KickがまだVODの切り出しを終えていないことを意味します。no_sourceは、VODが削除されたか期限切れになったことを意味します。どちらもKick側の状態であり、ダウンロードの失敗ではありません。

何も保存されない

KickのCDNはaccess-control-allow-origin: *を送るため、ブラウザはファイルを直接読めます。ダウンロードはページ内で、Kickのエッジからディスクへ直接実行されます。リゾルバが扱うのはメタデータだけです。再エンコードも透かし入れも保持もされません。

実用的な注意がひとつ。長いVODは、ファイルがディスクへ直接ストリーミングされるデスクトップブラウザで保存するのが最適です。スマートフォンでは、数時間の配信はダウンロード中メモリに保持され、ファイルが終わる前にブラウザが諦めることがあります。

要点

• クリップのリンクはクリップを返し、VODのリンクはレンディションの一覧を返し、チャンネルのリンクは最近のVODを一覧にします。
• ライブ配信は拒否されます。配信中は保存できるファイルがありません。
• 画質の行はKick自身のHLSマスタープレイリストから来ており、解像度ごとに最良のビットレートです。
• バイト列はKickのCDNからお使いのブラウザへ移動します。リゾルバは何も保持しません。