最終更新: 2026-09-02

ポッドキャスト番組概要の文字数設計 - 各プラットフォームの制限と最適化

ポッドキャストの番組概要 (Show Description) とエピソード説明文 (Episode Notes) は、リスナーが番組を発見し、再生ボタンを押すかどうかを決める重要な接点です。しかし、Apple Podcasts、Spotify、YouTube Music、Amazon Music など主要プラットフォームごとに文字数制限が異なり、同じテキストがプラットフォームによって途中で切れてしまうことがあります。本記事では、各プラットフォームの制限を正確に把握し、すべてのリスナーに最適な情報を届けるための文字数設計を解説します。

プラットフォーム別の文字数制限一覧

ポッドキャストの文字数制限は、番組全体の概要 (Show Description) とエピソードごとの説明文 (Episode Description) で異なります。さらに、検索結果やカード表示での「折りたたみ表示」と、詳細ページでの「全文表示」でも表示文字数が変わります。

以下は 2026 年 8 月時点で、配信画面や各社のヘルプから確認できる実務上の目安です。文字数上限を公式ドキュメントに明記していないプラットフォームもあり、値は仕様変更で前後します。運用を始める前に、実際に使う配信先の入力欄で必ず確認してください。

設計上の要点は、上限がもっとも小さいプラットフォームに全体を合わせることです。Apple Podcasts 向けに 3,000 文字の概要を書いても、番組概要の枠が 1,000 文字台のプラットフォームでは後半が届きません。マルチプラットフォーム配信を前提とするなら、核心情報を冒頭 1,000 文字以内に収め、その先を補足に使う構成が安全です。

なお Google ポッドキャストは 2023 年 9 月に終了が発表され、2024 年 3 月にサービスを終了して YouTube Music に統合されました。過去の解説記事で配信先として挙げられていても、現在は YouTube Music 側の仕様を見れば足ります。

検索結果での表示 - 冒頭 2〜3 行が勝負

リスナーがポッドキャストを発見する経路の多くは、プラットフォーム内検索です。検索結果のカード表示では番組概要が数行で打ち切られますが、ここで何文字まで見えるかは固定値ではありません。アプリは「文字数」ではなく「行数」で折りたたむため、端末の画面幅・システムの文字サイズ設定・アプリのレイアウト更新のいずれが変わっても表示量が変わります。日本語なら 2〜3 行でおおむね 100 文字前後という見当がつく程度に考え、それを超える部分は「読まれたら得」の扱いにするのが安全です。この折りたたみ前提の設計は、メタディスクリプションの設計と同じ考え方で最適化できます。

検索結果で表示される冒頭部分に含めるべき情報は以下の通りです。

• 番組のジャンルとテーマ: 「テクノロジーとビジネスの交差点を探るポッドキャスト」のように、1 文で番組の位置づけを伝える
• 更新頻度: 「毎週月曜日配信」のように、リスナーが購読判断に使う情報を含める
• ターゲットリスナー: 「スタートアップ経営者やプロダクトマネージャー向け」のように、誰のための番組かを明示する
• 差別化ポイント: 「現役 CTO がゲストを招き、失敗談を赤裸々に語る」のように、他番組との違いを示す

冒頭に「この番組は...」「本ポッドキャストでは...」のような前置きを書くのは、見える範囲の何割かを情報量ゼロで埋めることになります。検索結果では限られた行数で勝負するため、主語を省略して核心から書き始めるのが効果的です。

エピソード説明文の構成テクニック

エピソード説明文 (ショーノート) は、番組概要とは異なる役割を持ちます。番組概要が「この番組を聴くべきか」の判断材料であるのに対し、エピソード説明文は「このエピソードを聴くべきか」と「聴いた後に参照する情報」の 2 つの役割を担います。

効果的なエピソード説明文は、以下の 3 層構造で設計します。

第 1 層のフックは、どのアプリでも折りたたまれずに見える冒頭 2〜3 行に収まるよう設計します。「今回は元 Google エンジニアの田中氏を迎え、大規模システムの障害対応で学んだ 3 つの教訓を語ります」のように、ゲスト名・テーマ・具体的な数字を先に置くと、開かずに判断されても内容が伝わります。逆に、この位置に挨拶やスポンサー告知を置くと、判断材料が一つも見えないまま次の番組へスクロールされます。

第 3 層のタイムスタンプは、長尺エピソード (30 分以上) では特に重要です。聴きたいセクションが分かっていても、頭から早送りで探す必要があるエピソードは後回しにされやすく、目次があるだけで「今すぐ聴ける」対象に変わります。アプリによっては「12:30 - トピック名」のような時刻表記を自動的に再生位置へのリンクとして扱うため、時刻は表記を崩さず正確に書いてください。

RSS フィードの description と content:encoded の使い分け

ポッドキャストの RSS フィードには、テキストを格納する 2 つの主要なフィールドがあります。<description> タグと <content:encoded> タグです。この 2 つの使い分けが、プラットフォーム間での表示差異に直結します。

どのフィールドをどの優先順で読むかはアプリごとに異なり、公式ドキュメントに明記されていない場合もあります。そのため「片方だけに情報を入れる」設計は、あるアプリでは説明文が空欄になるという事故につながります。実務上の推奨は、description にプレーンテキスト版 (1,000 文字以内)、content:encoded に HTML 版 (リンク・タイムスタンプ付き) を格納する二重管理です。プレーンテキスト版だけを見たリスナーにも判断材料が揃うように、リンクに依存しない書き方をしておきます。

itunes:summary は新規の RSS フィードで積極的に増やす理由はありません。既存のフィードに含まれている場合は、description と食い違わない内容を設定しておけば問題ありません。3 つのフィールドで内容が違うと、リスナーが見る説明文がアプリによって変わってしまいます。

SEO を意識したショーノートの書き方

ポッドキャストの SEO は、音声コンテンツ自体の検索最適化と、ショーノートのテキスト検索最適化の 2 軸で考える必要があります。Apple Podcasts と Spotify はそれぞれ独自の検索アルゴリズムを持っており、YouTube の説明文 SEO とは異なるアプローチが求められます。

各社は検索の仕組みを公開していませんが、アプリ内で番組名・エピソード名・説明文のテキストが検索に使われることは、実際に自分の番組を検索してみれば確認できます。逆に言えば、説明文に一度も出てこない語では見つけてもらえません。「そのエピソードを探す人が打ち込む語」が本文中に自然な形で入っているかを、公開前に一度声に出して確かめる価値があります。

順位を左右する要素として再生数や完聴率が語られることもありますが、これは各社が公表している仕様ではありません。確実に自分で制御できるのはテキスト側だけなので、まずショーノートを整えるほうが投資効率が高いと考えてください。

• キーワードの自然な配置: エピソードのテーマに関連するキーワードを、冒頭 200 文字以内に自然に含める
• ゲスト名のフルネーム記載: ゲストの名前で検索するリスナーが多いため、フルネームと肩書きを必ず含める
• 具体的なトピック名: 「クラウドについて語る」ではなく「オンプレミス回帰を検討した会社がコストを試算した結果」のように、検索する人の言葉で具体的に書く
• シリーズ名の統一: 連続企画の場合は「シリーズ名 #3」のように統一的な命名で、シリーズ検索に対応する

タイトルの文字数設計

エピソードタイトルは、ショーノート以上に文字数制限が厳しい要素です。動画タイトルの最適化と共通する部分も多いですが、ポッドキャスト特有の制約もあります。

タイトルの入力上限は、番組概要と同じく各社が数値を公表していない場合があります (2026 年 8 月時点)。以下は入力欄で確認できる目安ですが、実務で意味を持つのは上限そのものではなく「一覧画面で切られずに読める長さ」です。

推奨文字数が上限よりはるかに短いのは、一覧画面では 1 行から 2 行で打ち切られるためです。日本語なら 35〜50 文字あたりを超えた部分は「読まれない前提」で扱うのが安全です。エピソード番号を含める場合 (例: 「#127」で 4 文字)、実質的に使えるのは 30〜45 文字程度になります。

タイトルに番組名を繰り返し入れるのは避けてください。「テックトーク - テックトーク #127 生成モデルの未来」のようなタイトルは、番組ページやアプリの一覧では番組名がすでに別に表示されているため、限られた表示幅を既知の情報で埋めることになります。同じ幅をエピソード固有の内容に使えば、それだけ判断材料が増えます。

チャプターマーカーと文字数

チャプターマーカー (Chapters) は、エピソード内のセクションにタイトルや画像を付与する仕組みです。音声ファイル自体に埋め込む形式と、RSS フィードから外部の JSON ファイルを参照する Podcasting 2.0 系の形式があり、どちらに対応しているかはアプリごとに異なります。対応していないアプリではチャプターが単に表示されないため、タイムスタンプを説明文にも書いておく二重化が実務的です。

チャプタータイトルの推奨文字数は 20〜40 文字です。チャプターは横幅の狭いリストに並ぶ要素なので、説明文よりさらに早く省略されると考えてください。「導入」「まとめ」のような汎用的な名前ではなく、「なぜ Rust が組み込み開発で注目されるのか」のように具体的な内容を示す方が、聴きたい場所を探すリスナーの役に立ちます。

番組概要のテンプレートと実例

効果的な番組概要を効率的に作成するために、ジャンル別のテンプレートを紹介します。

インタビュー番組の場合 (推奨 800〜1,200 文字)

• 冒頭 100 文字: 番組のコンセプトとホストの紹介
• 100〜300 文字: どんなゲストが出演するか、過去の注目ゲスト名
• 300〜500 文字: リスナーが得られる価値 (学び、気づき、エンタメ)
• 500〜800 文字: 更新頻度、エピソードの長さ、SNS アカウント
• 800〜1,200 文字: スポンサー情報、お便り募集、関連リンク

ニュース解説番組の場合 (推奨 600〜1,000 文字)

• 冒頭 100 文字: 扱うニュースジャンルと解説の切り口
• 100〜300 文字: ホストの専門性や経歴 (信頼性の担保)
• 300〜600 文字: 番組の特徴 (速報性、深掘り、独自取材など)
• 600〜1,000 文字: 配信スケジュール、関連メディア、連絡先

いずれのテンプレートでも、番組概要の枠がもっとも狭いプラットフォーム (前掲の表では 1,000 文字台) を基準に、核心情報を前半に集中させることが重要です。1,000 文字を超える部分は「枠に余裕のあるアプリでだけ読まれるボーナス情報」と位置づけ、参考リンクやスポンサー情報を後ろに回します。この配置なら、どのアプリで見られても番組の判断材料は必ず届きます。

実質の上限はホスティング側で決まる

ここまでプラットフォーム側の上限を見てきましたが、実際に書ける文字数を決めているのはホスティングサービス (配信元) の入力欄です。各アプリはホスティングが生成した RSS フィードを読むだけなので、ホスティングの入力欄が短ければ、Apple Podcasts 側にどれだけ余裕があっても意味がありません。

ホスティングサービスの上限は各社が仕様として公開しているとは限らず、機能改定でも変わります。そのため、他社の解説記事に載っている数値を当てにするのではなく、自分が契約しているサービスの管理画面で確かめるのが唯一確実な方法です。確認の手順は次の 3 つです。

• 入力欄の挙動を見る: 番組概要とエピソード説明の欄に長いテキストを貼り付け、文字数カウンターが出るか、途中で入力が止まるかを確認する
• HTML の扱いを見る: リンクや改行を入れて保存し、公開ページで反映されるかを確認する (プレーンテキスト化されるサービスもある)
• 生成された RSS を直接見る: フィードの URL をブラウザで開き、description と content:encoded に何が入っているかを目で確かめる

特に注意したいのは、番組概要の欄がエピソード説明の欄よりずっと短いサービスがある点です。番組概要は一度書けば長く使う文章なので、上限が短い環境なら「更新頻度・対象リスナー・番組の切り口」の 3 点に絞り、残りはエピソード側で補う設計に切り替えます。

エピソード説明文の A/B テスト手法

エピソード説明文の最適な文字数は、番組のジャンルやリスナー層によって異なります。データに基づいて最適解を見つけるには、A/B テストが有効です。ポッドキャストの A/B テストは Web サイトほど簡単ではありませんが、以下の手法で間接的に効果を測定できます。

• 交互テスト: 偶数回のエピソードは短い説明文 (300 文字以内)、奇数回は長い説明文 (800 文字以上) で配信し、再生数と完聴率を比較する
• フック文の比較: 冒頭 100 文字のフック文を「質問形式」と「結論先出し形式」で交互に使い分け、再生開始率を比較する
• タイムスタンプの有無: タイムスタンプを含むエピソードと含まないエピソードで完聴率を比較する。効果の向きは番組の長さやジャンルで変わるため、他番組の結果を前提にせず自分の数字で確かめる
• CTA の位置: 「チャンネル登録」や「レビューのお願い」を説明文の冒頭に置く場合と末尾に置く場合で、フォロワー増加率を比較する

Apple Podcasts Connect と Spotify の配信者向けダッシュボード (2026 年 8 月時点の名称は Spotify for Creators) では、エピソードごとの再生数や完聴率、フォロワーの増減を確認できます。これらの指標を説明文の文字数・構成と照合することで、自分の番組に最適な文字数設計を見つけることができます。

音声文字起こし (Transcript) と SEO の関係

Apple Podcasts は 2024 年 3 月に配信された iOS / iPadOS 17.4 で、エピソード音声の書き起こし表示に対応しました。ここで押さえておきたいのは対応言語です。開始時点で利用できるのは英語・フランス語・ドイツ語・スペイン語で、日本語は含まれていません (2026 年 8 月時点)。

つまり日本語の番組では、「音声の中で話した内容が自動的にテキスト化されて検索に使われる」という前提が成り立ちません。日本語で配信している限り、アプリ側が検索に使えるテキストは番組名・エピソードタイトル・説明文だけです。海外の解説記事が「文字起こしがあるからショーノートの比重は下がった」と書いていても、そのままは当てはまらないと考えてください。

この非対称は運用上むしろ好都合です。SEO における文字数の考え方と同じく、自分で完全に制御できるテキストは書いた分だけ資産になります。書き起こしが将来日本語に対応したとしても、タイムスタンプ・参考リンク・ゲストの肩書きといった構造化された情報は音声から自動生成できないため、ショーノートを整える手間が無駄になることはありません。