ポッドキャストはRSSだけで全配信されない、公開後に見る6項目

一つのRSSフィードを作っただけでは、Apple Podcasts、Spotify、YouTube、Amazon Musicへの配信は完了しない。各サービスで初回登録、所有確認、必要な審査や公開操作を終えて初めて、その後の新エピソードを同じフィードから継続的に届けられる。

確認するのは、フィード検証、初回登録、所有確認と公開、掲載URLの保存、更新確認、移転対応の6項目だ。RSSが共通化するのは番組情報とエピソードの受け渡しであり、配信先ごとのアカウント、公開状態、番組ページ、分析まで一括管理するものではない。

1．申請前にRSSフィードを検証する

まず、登録に使うURLが番組紹介ページではなく、XMLを返すRSSフィードであることを確認する。ログインやパスワードを要求せず外部から取得できる状態にし、番組名、説明、言語、カテゴリー、カバーアート、連絡先、公開済みエピソードが意図どおり出力されているかを見る。

各エピソードでは、タイトル、説明、公開日時、再生可能な音声ファイルを確認する。GUIDはエピソードを識別する値なので、公開後に題名や音声ファイルの場所を変更しても不用意に書き換えない。構文や必須項目に問題があれば、配信先ごとに申請を試す前にホスティング側で直す。

連絡先メールは、所有確認コードの受信に使われる場合がある。担当者が受信できる番組用アドレスを設定し、申請時には迷惑メールフォルダーも確認できるようにしておく。

2．同じRSS URLを主要4サービスへ初回登録する

検証後は、同じRSS URLをApple Podcasts Connect、Spotify for Creators、YouTube Studio、Amazon Musicのポッドキャスター向け管理画面へ登録する。ホスティングサービスに送信機能があっても対象範囲は一律ではないため、自動送信された先と手作業が必要な先を区別する。

WordPress.comの配信手順 でも、Apple Podcasts、Spotify、YouTube、Amazon MusicにはRSS URLを渡し、それぞれのアカウントで登録や確認を進めている。基本の流れは次のとおりだ。

1. Apple Podcasts Connectで「RSSフィードを使用する番組」を追加し、取得された番組情報と配信地域などを確認して公開する。
2. Spotify for Creatorsで外部ホストの既存番組を選び、RSS URLを入力して番組を確認する。
3. YouTube Studioで対象チャンネルを選び、ポッドキャストとしてRSSフィードを接続する。
4. Amazonの管理画面へログインし、番組のRSS URLを送信する。

申請日、利用した管理アカウント、担当者を一つの台帳に残す。すでに検索結果に番組がある場合は、重複して新規登録せず、既存番組を管理アカウントへ紐づけるための取得手順を選ぶ。

3．所有確認と公開状態をサービスごとに終える

RSSが読めても、確認コードの入力、利用条件への同意、公開操作が残っていれば番組は公開済みとはいえない。管理画面とメールを確認し、「下書き」「非公開」「審査中」などの状態を公開完了と取り違えないことが重要だ。

YouTubeではRSSの動作が一般的な音声ディレクトリと異なる。YouTubeのRSS配信仕様 では、選択した音声エピソードから静止画付き動画を作り、新しいエピソードも接続後に自動アップロードすると説明している。ただし初回に選んだエピソードは非公開動画として取り込まれるため、処理後にポッドキャストを公開する必要がある。

YouTubeの所有確認コードはRSS内のメールアドレスへ送られる。さらに、RSSで変更した番組情報や公開済み動画の音声ファイルは自動更新されないため、必要に応じてYouTube Studio側で編集または再取り込みを行う。すでに同じエピソードを手動投稿しているなら、取り込み開始位置を指定して重複を避ける。

4．承認後に掲載URLを保存する

配信先から承認通知を受け取るだけでなく、リスナーが実際に開ける番組ページまで確認する。Apple Podcasts、Spotify、YouTube、Amazon Musicにはそれぞれ固有の掲載URLがあるため、RSS URLとは別に保存する。

台帳には、サービス名、番組ページのURL、公開確認日、管理アカウント、担当者を記録する。番組名で検索した結果だけに頼ると同名番組や古いページを取り違える可能性があるので、管理画面から発行または案内されたURLを基準にする。

5．次の通常エピソードで更新を確認する

初回公開後は、確認専用の短い音源を増やすのではなく、次の通常エピソードで同期を確かめる。各番組ページを開き、タイトル、説明、公開日、音声が一致し、再生できるかを確認する。

一つの配信先だけ更新されない場合は、まずホスティング側でエピソードが公開済みか、次にRSS内へ当該エピソードが出力されているかを調べる。そこまで正常なら、該当サービスの管理画面で取得エラーや公開設定を確認する。番組名やカバーアートの変更はエピソード追加と同じタイミングで反映されるとは限らないため、公開ページそのものを見る。

分析値もRSSによって一つに統合されるわけではない。ホスティング側のダウンロードと、Apple Podcasts Connect、Spotify for Creators、YouTube Studioなどの利用状況は測定対象や指標名が異なるため、比較するときは期間と指標の定義をそろえる。

6．RSS URLの変更は移転として扱う

ホスティングの変更などでRSS URLが変わるときは、新しいURLを作るだけでは不十分だ。移転前に旧フィード、新フィード、各サービスの掲載URL、既存エピソードのGUIDを控え、旧URLを追跡している配信先と購読者を新URLへ移す。

Apple PodcastsのRSS移転手順 は、自分でフィードを管理する場合、旧URLから新URLへのHTTP 301リダイレクトと、新しいフィードを示す<itunes:new-feed-url>タグを少なくとも4週間維持するよう案内している。元のGUIDを変更すると、エピソードの重複、分析データの不整合、番組状態への影響が生じる可能性がある。

ホスティング事業者がリダイレクトを処理する場合は、その移転機能を利用する。転送を設定できない場合は、各配信先でRSS URLを変更できるかを確認し、必要ならサポートへの依頼や再登録を行う。旧ホストの停止は、新しい通常エピソードが主要な掲載ページへ届き、既存ページが維持されていることを確認してからにする。

公開作業の完了条件は、単にRSSを発行したことではない。6項目について担当者と確認結果が残り、各配信先の公開ページで新エピソードを再生できる状態になった時点で、初回登録から継続配信までを管理できたと判断する。