mcpField
P
podcast-production

podcast-production

github.com/calesthioクリエイティブ・メディア221100 回インストール15 週間前に更新
リポジトリ

podcast-production について

合成音声を使う番組も対象とする、公開可能なトークポッドキャスト制作のベンダー中立スキルです。番組形式、脚本、音声演出、編集、権利、納品要件、開示、品質確認を扱います。

主な機能

  1. 01番組形式と対象者の計画
  2. 02耳で聞くための脚本作成
  3. 03キャスティングと声の一貫性
  4. 04エピソード構成と音声編集
  5. 05権利・開示・納品の確認
  6. 06通し聴きによる品質確認

活用シーン

  1. 01ポッドキャストの番組形式設計
  2. 02合成ナレーション用の脚本作成
  3. 03一貫した複数話者の回を制作
  4. 04公開前のエピソード確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/calesthio/generative-media-skills --skill podcast-production

インストール後、Claude Code で/podcast-productionを入力して読み込まれたか確認します。

同梱ファイルEVAL.md

詳細

生成ツールを使ったポッドキャスト制作

このスキルでは、音声の一部またはすべてが機械生成された、完成済みで公開可能なポッドキャストエピソードの制作を扱います。特定のプロバイダーに依存せず、TTS エンジン、音楽ライブラリ、ホスティングサービスは選択肢の例として挙げるだけで、制作方法を限定するものではありません。制作の要点である、フォーマット設計、耳で聴くことを意識した執筆、音声の演出、構成、権利、ラウドネス、納品、開示、品質保証は、どのツールで音声を生成する場合も同じです。

エピソードが完成といえるのは、（1）明確に定められた番組と視聴者に応える、（2）意図が感じられ、一貫した音になっている、（3）配信する権利のある音声のみを使用している、（4）配信先プラットフォームのラウドネスとファイル仕様を満たしている、（5）正確な RSS メタデータと文字起こしを添えて配信される、（6）法律またはプラットフォームが求める AI 開示を記載している、（7）通しで聴く品質確認に合格している、という条件を満たす場合です。これらのいずれかを省くのは、近道ではなく不備です。

1. 対象範囲と適用

トピック解説番組、インタビューシリーズ、日刊／週刊ニュースブリーフ、ナラティブ／ドキュメンタリーエピソード、2人のホストによる対話形式の番組、社内向けブリーフィング配信、またはこれらの番組企画書／フォーマット設計など、タスクが音声コンテンツの場合にこのスキルを使用します。

次の用途には使用しないでください。

  • 音楽制作 — 納品物が楽曲、BGM、または短いジングルの場合（これは音楽／音声生成の領域です）。このスキルでは音楽を素材として使用し、権利とラウドネスの問題として扱います。
  • 単一の TTS 音声 — IVR のプロンプト、通知音声、番組の文脈を伴わない単独のナレーションクリップ。
  • 映像が主となる動画 — 納品物が動画で、音声がその下に流れるトラックである場合は、動画のワークフローがテンポと納品を担います。音声そのものが製品である場合にこのスキルを適用します。

依頼が曖昧な場合（「この記事を音声化してください」など）は、出力が単発のナレーションなのか、番組のエピソードなのかを確認してください。この2つでは、必要な構成とメタデータが異なります。

2. フォーマット設計（執筆を始める前に行う）

初期段階で最も重要な決定事項はフォーマットです。フォーマットによって、台本のスタイル、声の数、構成、長さが決まるためです。一般的なポッドキャストのフォーマットと、それぞれに求められるもの（Sources を参照した、標準的なポッドキャスト制作の慣例に基づく制作上の目安）を以下に示します。

フォーマット標準的な長さ声の数台本のスタイル適している内容
2人のホストによる対話形式20～60分2人（相性が重要）概要のみを作成し、全文は書かない視聴者との継続的な関係づくり、意見／解説
インタビュー25～75分ホスト＋ゲスト（複数可）ホストの質問は台本化し、回答は生で収録専門知識、ゲスト、長期的に聴けるバックカタログ
ソロ／モノローグ5～30分1人全文または大部分を台本化教育、エッセイ、焦点を絞った解説
ナラティブ／ドキュメンタリー20～45分ナレーター＋録音音声／登場人物全文を台本化し、各幕に分けて構成ストーリーテリング、高い制作価値
ニュースブリーフ／日刊番組3～10分1～2人簡潔に台本化し、情報量を多くする定期配信、時事性、習慣化を促す内容

完全合成の番組（すべての声が TTS）の場合、インタビュー形式と2人のホストによる対話形式は、会話のやり取りの自然さと相性に依存するため、説得力を持たせるのが最も困難です。ソロ形式、ナレーターによるナラティブ形式、ニュースブリーフ形式は、最も無理なく制作できます。合成音声の番組のフォーマットを提案する際は、この点を考慮してください。

エピソードの設計に入る前に、短い番組企画書を作成して番組全体を一度設計します。

  • 番組の概要と対象視聴者 — 誰に向けた番組で、各エピソードで何を届けるのかを1文で記載します。
  • 配信頻度と長さ — フォーマットに合った長さの範囲と、現実的な配信スケジュールを決めます。
  • 声のアイデンティティ — 使用する声、名前／キャラクター設定、そして第N話も第1話と同じように聞こえる固定の音声設定を決めます（§4 を参照）。
  • 定番要素 — オープニングの台詞、エンディング／行動喚起、テーマ音楽、定期的なコーナーを決めます。これらは番組の「音のブランディング」であり、毎回同じ形で使用する必要があります。
  • 開示方針 — 台本とメタデータに影響するため、事前に決めます（§6 を参照）。

3. 耳で聞くための文章を書く

音声用の台本は、読み上げるための文書ではありません。耳にはスクロールバーがなく、聞き直すこともできず、複雑な節は記憶に残りません。文章を話し言葉に書き換えましょう（ポッドキャストの台本作成で広く教えられている制作上のヒューリスティックです。情報源を参照してください）。

  • 短い文で、一文に一つの考えを入れます。 重文は分けましょう。聞き手が記憶にとどめられるのは、直前に聞いた節だけです。
  • 短縮形と話し言葉の表現を使います。 「It's / you'll / here's」を使い、「it is / you will / here is」は避けましょう。有能なホストが実際に話すように書きます。
  • 要点を先に伝えます。 結論を述べてから、根拠を示しましょう。長い従属節の後ろに結論を隠してはいけません。
  • 話し言葉で展開を示します。 「ポイントは三つです。まず……／ただし、注意点があります……／では、これはどういう意味でしょう？」などです。これは音声における見出しに相当します。
  • 発音しにくいものはなくします。 頭字語、記号、URL、数字は、つづりを明記するか、言い換えましょう。「-16 LUFS」ではなく「twenty-sixteen L-U-F-S」、「/join」ではなく「dot com slash join」とします。
  • 声に出して読みます。 人が読むとつまずく箇所は、合成音声もつまずき、聞き手を退屈させます。合成音声の番組では、収録後に即興で修正できないため、音読によるテストが特に重要です。

台本にどこまで書き込むかは、形式によって異なります。 形式にかかわらず、リスクの高い場面は完全に台本化しましょう。冒頭のフックやコールドオープン、セグメント間のつなぎ、スポンサー読み、締めくくりが該当します。会話形式やインタビュー形式の番組では、中盤はアウトラインにして、自然な会話を保ちましょう。ソロ、ナラティブ、合成音声の番組では、すべてを台本化します。合成音声は渡された内容をそのまま読み上げるため、台本がそのまま演技になります。

台本が演技そのものになる場合（完全合成音声の場合）は、演技指示も台本に書き込みましょう。段落ごとに意図する間、強調、感情のトーンを示します。それらは§4でTTSへの指示になります。

4. 複数の声のキャスティングとTTSの指示

説得力のある合成音声のエピソードと、明らかにロボットのようなエピソードを分けるのが、この技術です。目標は、それぞれの声が互いにはっきりと異なり、エピソードをまたいで一貫性があり、正しく発音し、対話では互いに自然に反応することです。

4.1 キャスティングと一貫性
  • ペルソナごとに音声設定を固定します。 正確な音声識別子と、すべての生成パラメーター（安定性／一貫性、類似性、スタイル／表現力、速度）を、ペルソナの「音声ロック」として保存します。すべてのエピソードで再利用しましょう。音声のぶれ、つまり同じ名目上の音声がエピソード間、あるいは長い音声ファイルの中でさえ違って聞こえることは、合成音声番組における最大の継続性の問題です（実務者の観察であり、TTSベンダーのガイダンス全般でも裏付けられています。情報源を参照してください）。
  • 対照的な声を選びます。 2人の声で進行する番組では、声の高さ、話す速さ、音色が異なる声を選び、名前を呼ばなくても誰が話しているか聞き分けられるようにしましょう。似た声を2つ使うのは、声を1つだけ使うよりもよくありません。
  • 長い台本は話者／役割ごとに分割し、 各話者のセリフを、その話者に固定した設定で生成してから組み立てます。1回の呼び出しで主音声を1つしか使えないエンジンでは、リクエストの途中で声を切り替えるよりも、この方法のほうが一貫性を保てます。
  • 安定性／一貫性の設定を高くすると、ぶれと表現力の両方が抑えられます。 30分間同じ声に聞こえる必要があるナレーターでは、安定性を優先しましょう。幅広い表現が必要なキャラクターでは、ある程度の変化を許容し、一貫性が得られるまでテイクを再生成します（ヒューリスティック）。
4.2 発音の制御
  • 名前、専門用語、外国語は明示的に調整します。 モデルが正しく推測することを期待してはいけません。エンジンの発音機能を使います。音素マークアップ（SSML の <phoneme> による IPA または CMU Arpabet）、カスタムの発音辞書／辞書ファイル、または最終手段として、テキスト中の発音を示す表記（「Cairo」を「KAI-roh」と表記するなど）を使います。確認済みの事実として、主要なエンジンでは SSML の <phoneme> が IPA と CMU Arpabet に対応しています。一部の新しい表現力豊かなモデルは辞書や発音表記には対応していても、完全な SSML には対応していません。エンジンごとに確認してください（2026-07-10 に ElevenLabs、Google Cloud TTS、Azure Speech のドキュメントを照合して確認済み）。
  • 番組用の発音用語集を番組バイブルに作成します（繰り返し登場する名前、番組タイトル、スポンサー名など）。毎回のエピソードで適用し、「ホストの名前」の発音が変わらないようにします。
  • 数字、日付、単位、記号は読み方にばらつきが出ます。台本内で表記を統一してください（「July tenth, twenty-twenty-six」など）。人にとってもわかりやすくなります。
4.3 感情に合わせたペース配分と演技
  • 句読点は、ペース配分の主な手段です。 ピリオドは完全な間、コンマは短い息継ぎ、省略記号は余韻のある間、疑問符は文末のピッチを上げます。文の長さがリズムを決めます。短い文はテンポを速め、長い文は遅くします。1分あたり約140～160語が、自然で熱意のある話し方に聞こえます（制作上の目安。Sources を参照）。
  • 感情は単語ごとではなく、段落／セクション単位で適用します。 一節全体のトーンを設定し、単語ごとの強調は控えめに使います。感情表現の指示を重ねすぎたり、文ごとに切り替えたりすると、トーンが不自然に急変します（TTS のベストプラクティスに関するドキュメントで裏付けられた、実務上の目安。Sources を参照）。
  • エンジンの表現力を高める制御機能は、意図を持って使います。 SSML の <prosody>（速度／ピッチ／音量）、間を設けるための <break time="…">、<emphasis>、またはエンジンの音声／感情タグなどです。SSML ではなくプロンプトで制御するエンジンでは、エンジンが読み取る演技指示に指示を記載します。執筆前に、選んだエンジンがどのマークアップに実際に対応しているか確認してください。対応状況にはばらつきがあります（2026-07-10 に確認済み）。
  • 複数のテイクを生成し、その中から選びます。 合成音声の演技は確率的で、最初のテイクが最良であることはほとんどありません。再生成のための時間を確保してください。
4.4 生成された対話におけるホスト同士の相性

合成ホスト同士の相性は、声が別々に生成され、実際には互いに反応しないため、意図的に作り込む必要があります。手法（経験則）：

  • 反応を台本に書き込みます。 会話への割り込み（「――待って、もう一度言って」）、相づち（「うん」「そうだね」）、先ほどのセリフへの言及などです。台本にないものは、音声にもありません。
  • 発話の長さに変化をつけます。 実際の会話にはむらがあります。長い意見の後に、二語だけの返事が続くこともあります。発話の長さが均等な台本は、不自然さが目立ちます。
  • 編集時に継ぎ目を調整します。 発話の交代を自然に聞かせるには、間が重要です。話者ごとのクリップのつなぎ目を詰めるか重ねて、返答が一週間後に別の部屋で録音されたように聞こえないようにします。両方の声の下に一貫したルームトーンを敷くと、同じ場所にいるような印象が生まれます。
  • 生のリモート収録を偽装しないでください。 リアルさを演出するために、偽の「電話越し」フィルターを加えると、欺瞞につながりかねません。あくまで制作された番組だとわかるようにしてください。

5. エピソードの構成と編集

5.1 構成

一般的なエピソードの流れ（制作上の目安。形式に応じて調整してください）：

  1. コールドオープン（任意、10～30秒） — ブランディングを入れる前に、最も印象的な場面やフックをひとつ提示します。 聴き続けてもらうための導入です。ストーリー仕立ての番組や、ソーシャルクリップを重視する番組に効果的です。
  2. イントロ／テーマ（5～20秒） — テーマ音楽に乗せて、番組名、ホスト、番組の魅力を一文で伝えます。短くし、毎回同一の内容にします（音によるブランディング）。
  3. エピソードの予告 — このエピソードでどんな内容を届けるか、1～2文で伝えます。
  4. 本編／セグメント — 内容を、明確な区切りのあるセグメントに分けます。セグメントが変わるたびに、音声で移行を示し、必要に応じて短い音楽のジングルを入れます。
  5. 広告枠 — §5.3を参照してください。挿入・削除や動的配信ができるよう、構成上で明示します。
  6. アウトロ（15～30秒） — 内容の振り返り、行動喚起（登録／共有／リンク）、締めの挨拶、テーマ音楽で締めくくります。

ストーリー仕立ての番組では、平坦なセグメント構成ではなく、本編に起承転結（導入 → 展開・転換 → 解決、または未解決の問い）を設けます。

5.2 組み立てと編集
  • まず会話音声の音量を整えてから、その下に音楽や効果音を配置します。音楽よりも、常に話し声の聞き取りやすさを優先してください。
  • 話し声の下で音楽をダッキングします（サイドチェーンまたは手動オートメーション）。会話中は音楽を声よりおよそ12～18 dB低くし、間では音量を上げます（あくまで目安です。耳で調整してください）。
  • 合成音声の不自然な箇所を編集します — TTSでは、語頭が切れた単語、不自然な息継ぎ、音節の欠落がよく見られます。問題のある箇所をカットするか、該当するセリフを再生成してください。
  • クリップ間のルームトーン／無音を一定に保ちます。 編集したTTSクリップの間にデジタル無音があると不自然に聞こえます。一定の低いノイズフロアを保つと、ひと続きの録音のように聞こえます。
  • 最終的なラウドネス調整（§7）を行う前に、イントロ、本編、広告の音量が大きくばらつかないよう、セグメント間の音量を揃えます。
5.3 広告枠
  • 音声に組み込み済みか、動的挿入か。 組み込み済みの広告はファイルに永久に含まれます。動的に挿入する広告は、リクエスト時にホストがつなぎ合わせるため、更新や削除が可能です。長期的に広告を掲載する予定なら、広告を動的に挿入できるよう、タイムラインに無音の挿入ポイントを適切に設けてください。
  • 広告にも開示義務が及びます。 合成音声による広告の読み上げやAI生成の推薦コメントには、番組と同じ開示・同意義務（§6を参照）に加えて、推薦コメントに関する広告法規が適用される場合があります。権利を得ずに、実在の人物が何かを推薦しているように合成することは、決してしないでください。

6. 完全合成かハイブリッドか、そして開示義務

6.1 制作方針の決定
  • 完全合成 — すべての音声にTTSを使用します。制作コストが最も低く、試行錯誤も最速です。ソロ、ナレーターによるストーリー仕立て、ニュースの短い解説に最適ですが、即興性や本物のインタビューならではのやりとりには最も弱い方式です。
  • ハイブリッド — 録音した人間の声と合成音声のセグメントを組み合わせます（例：実在のホストと合成音声の共同ホスト、録音済みインタビュー音声を取り囲む合成ナレーション、入手できない音声の合成による再現）。両方式の利点を活かせますが、権利と開示の対象範囲は大幅に広がります。録音した人物全員から使用許諾を得る必要があり、合成音声のそれぞれについて、ライセンスを受けた、または同意を得た音声ソースが必要です。

実在する人間の権威や即興性、実際のゲストが必要な番組ではハイブリッドを選び、規模、一貫性、コストを優先し、形式上も許容できる場合は完全合成を選びます。

6.2 開示と同意に関する義務

これらはスタイル上の選択ではなく、要件として扱ってください。合成ポッドキャストで最もリスクの高い部分です。

  • 音声の複製には、音声の所有者から文書化された同意を得る必要があります。 許可なく実在の人物の声を複製または再現すると、パブリシティ権や音声に関する権利を侵害する責任を問われるおそれがあります。2026年時点で、米国の複数の州が肖像権とは別個の権利として音声を保護しています。テネシー州のELVIS Act（2024年施行）は、AIによる音声の複製を明示的に対象とした初の法律です。また、カリフォルニア州、イリノイ州、ニューヨーク州などにも関連法があります。連邦法のTAKE IT DOWN Act（2025年5月署名）は、同意のない合成描写を対象としています（2026-07-10に確認された記録済みの事実。「情報提供のみであり、法的助言ではありません」— Sources を参照。管轄地域や用途に応じて、現行法を確認してください）。同意は用途を特定したうえで、書面により文書化する必要があります。口頭での「はい」では不十分です。 署名済みの許諾書で用途が明確に定められていない限り、著名人、ゲスト、共同ホストの声を複製しないでください。
  • プラットフォームのAI開示ポリシーは、合成音声にも適用されます（2026-07-10に確認された記録済みの事実）。
    • YouTubeでは、クリエイターはアップロード時に、現実的な改変コンテンツまたは合成コンテンツを開示する必要があります。これには、実在の人物が話したと視聴者に誤解させるおそれのある合成音声や、AIによる吹き替え音声も明示的に含まれます。「このコンテンツの制作方法」というラベルが表示される場合があります。2025年の収益化ポリシー更新により、大量生産された手間のかかっていないAIコンテンツは、収益化を停止されるおそれがあります。
    • Spotifyは、AIを活用したコンテンツ自体の順位を下げることはありませんが、無許可の音声複製を禁止し、スパムや低品質で大量生産された音声を積極的に削除しています。また、アプリ内で表示されるDDEXベースのAI開示基準を導入中です。「Verified」プログラムでは、主にAIペルソナを表すプロフィールは対象外となります。
    • Apple Podcastsは現在、基本のRSS仕様において合成音声に「これはAIです」という一般的なラベルを付けることを義務付けていませんが、コンテンツポリシーでは引き続きなりすましを禁じ、すべての音声の権利を保有していることを求めています。（公開時に現行ポリシーを確認してください。プラットフォームのポリシーは変更される可能性があります。）
  • 迷ったら開示してください。 短く正直な注記（番組の説明欄への記載や、音声での告知など、「このエピソードの音声はAIによって生成されています」）は手軽な予防策であり、ますます期待されるようになっています。規制の流れ（たとえば、2025～2026年に生まれた透明性に関する法律）は、開示義務を減らすのではなく、増やす方向です。
  • 人間と合成音声を組み合わせる番組では、合成された部分を明記してください。 実在の人物の発言についてリスナーが誤解する可能性がある場合は、たとえば、合成により再構成された引用を再現として明示し、真正な録音として提示してはなりません。

7. ラウドネスと納品基準

ここでは数値が厳密に決まっています。基準を誤ると、プラットフォームによって番組の音量を上げ下げされたり、配信を拒否されたりします。

7.1 目標

確認済みの事実（2026-07-10 検証）：

  • Apple Podcasts は、ITU-R BS.1770 に基づく測定で、全体のラウドネスを 約 -16 dB LKFS （= LUFS）、許容差 ±1 dB、トゥルーピークを ≤ -1 dB FS にするよう、事前に調整することを推奨しています。 （LKFS と LUFS は同じ単位です。）
  • 一般によく引用されるクリエイター向けの目標値は、ステレオファイルで -16 LUFS、モノラル ファイルで -19 LUFS です。 モノラルの数値が低いのは意図的です。ステレオプレーヤーで再生されるモノラルファイルは、 知覚上、約 3 LU 小さく聞こえるため、モノラルファイルを約 -19 LUFS にマスタリングすると、-16 LUFS のステレオファイルと同じように 聞こえます。（2 つの数値を整合させるための制作上の目安です。知覚上の約 2～3 LU の 差は AES TD1008 に記載されています。「出典」を参照してください。）
  • Spotify はポッドキャストの再生時にラウドネスを -14 LUFS に正規化し、上限を -1 dBTP に設定します。YouTube も同様に、約 -14 LUFS を目標に正規化します。これらのプラットフォームは、ファイルを再エンコードするのではなく、再生時にゲインを適用します。
  • AES TD1008（2021年、TD1004に代わるもの） — ストリーミングのラウドネスに関する推奨規格 — は、 配信時の目標値を、音声／「各種コンテンツ」で -18 LUFS と定め、統合ラウドネスを -20 LUFS より大きく保つよう推奨しています。また、同じ測定ラウドネスでも、音声は音楽より約 2～3 LU 大きく知覚されると記載しています。これはクリエイターのマスターファイルではなく、配信者による正規化に関する指針です。

実用上の結論（目安）： 汎用的なデフォルトとして、ステレオファイル 1 本を 統合ラウドネス -16 LUFS、トゥルーピーク ≤ -1.0 dBTP にマスタリングします。これは Apple の許容範囲内で、Spotify／YouTube による調整もごくわずかです。モノラルで納品する場合は、同等の知覚ラウドネスを得るため、目標値を -19 LUFS にします。 Spotify の -14 を目指してダイナミクスを過度に圧縮することは避けてください。プラットフォームは音量の小さいコンテンツを 大きくしますが、 大音量で過度にリミッティングされたコンテンツは、きれいに音量を下げられず、聴き疲れする音になります。会話のダイナミックレンジを保ちましょう。 トーク番組を、マスタリング済みの楽曲と同じ音量にする必要はありません。

7.2 ファイルとエンコードの仕様

確認済みの事実 — Apple Podcasts（2026-07-10 検証）：

  • RSS で配信するエピソード音声： MP3 または AAC。モノラルは 64～128 kbps、ステレオは 128～256 kbps、サンプルレートは 44.1／48 kHz です。
  • トークコンテンツは、多くの場合 モノラルで十分です。ファイルサイズが小さく、ほとんどのリスニングは単一の スピーカーまたはイヤホンで行われます。音楽や効果音の定位に意味がある番組では、ステレオを使用してください。
  • ラウドネスはエンコードの前に設定します。非可逆圧縮によって測定ラウドネスは変わらないため、まず事前に調整してからエンコードします。
  • （Apple の高解像度 WAV／FLAC 仕様は、Podcasts Connect にアップロードする購読者向け音声に適用されるものであり、公開 RSS のエンクロージャには適用されません。）

各エピソードにつき 1 ファイルを、RSS アイテム内の <enclosure> で配信します（URL、バイト長、MIME タイプの 3 つすべてが必須です）。

8. メタデータ、チャプター、トランスクリプト、RSS

ポッドキャストはRSSフィードそのものです。音声はフィードに添付されているだけです。フィードを正しく整えることは、音声と同じくらい納品物の重要な一部です（仕様に関する事実を文書で確認済み、2026-07-10 —「Sources」を参照）。

  • フィードレベルの必須要素： タイトル、説明、言語、少なくとも1つの <itunes:category>、<itunes:explicit>、アートワーク（Appleでは通常、1400×1400～3000×3000 px、RGBのJPEG/PNGのカバーアートが必要です）、オーナー／連絡先が必要です。<itunes:explicit> または <itunes:category> がないフィードは、Appleに拒否されます。
  • エピソードレベルの必須要素： タイトル、<enclosure>（URL、バイト単位の長さ、MIMEタイプ）、変更されることのない世界で一意の <guid>、公開日が必要です。GUIDを変更すると、購読者にはそのエピソードが重複して表示されます。
  • チャプター — 方法は2つあります。（a）ファイルに埋め込む（MP3のID3v2 CHAP フレーム、M4AのMP4 chpl アトム）、または（b）外部のJSONチャプターファイルを指すPodcasting 2.0の <podcast:chapters> タグを使ってフィードからリンクする方法です。チャプターはナビゲーションを改善し、複数のクライアントで表示されます。
  • トランスクリプト — Podcasting 2.0の <podcast:transcript> 要素を使って、RSSアイテムからトランスクリプトファイルにリンクできます。WebVTT（.vtt）が推奨形式です。キュー識別子による話者ラベル、タイミング、簡単なスタイル指定に対応しており、最も多くのクライアントでサポートされています。SRTも使用できますが、機能はよりシンプルです。主要なクライアント（Apple、および2025年後半時点のSpotify）では、フィードにリンクされたトランスクリプトが表示されます。合成音声の番組では、トランスクリプトは実質的にすでにあります。つまり、台本そのものです。そのため、公開する手間はほとんどかからず、公開しない理由もありません。
  • 名前空間： これらのタグを使うには、フィードで itunes と podcast（Podcasting 2.0）の名前空間を宣言します。公開前にフィードを検証してください。

9. アクセシビリティ

  • 各エピソードのトランスクリプトを公開します。 これはポッドキャストのアクセシビリティにおける中核的な機能です。ろう者や難聴者のリスナーに役立ち、見つけやすさやSEOを向上させます。また、合成音声の番組では台本を使えるため、作成コストもほとんどかかりません。<podcast:transcript> を使ってリンクします（§8）。
  • 話者ラベル付きのトランスクリプト（WebVTTのキュー識別子）は、複数の声が登場する番組で、誰が何を言ったのかを読者が追えるようにするために重要です。
  • 要約、重要なタイムスタンプ／チャプター、文脈がなくても意味の分かるリンクテキストを含む、分かりやすい番組ノートを用意します。
  • トランスクリプトで伝えられない、音声だけの情報は避けます。 笑い声、声の調子、効果音が意味を理解するうえで重要な場合は、トランスクリプトに記載してください（「[笑い声]」「[電話の呼び出し音]」など）。

10. 権利と安全性のチェックリスト

すべての音声要素は、オリジナル、この用途での使用が許諾されているもの、またはパブリックドメイン／適切なクレジット表記を行ったクリエイティブ・コモンズ・ライセンスのいずれかでなければなりません。

  • 音楽。 楽曲と特定の録音（マスター）の両方について権利が必要です。楽曲を購入したり、個人向けストリーミングサービスに加入したりしても、ポッドキャストや映像作品での同期利用権は得られません。ポッドキャストを明示的に対象とするロイヤリティフリー／制作音楽ライブラリのライセンス、権利者から直接取得する同期利用ライセンス、または権利関係が明確な音楽を使用してください。「ロイヤリティフリー」とは、料金が一度きりという意味であり、無料という意味でも、ライセンス条件がないという意味でもありません。ライセンスの適用範囲（対象となるエピソード、広告付きでの利用、期間）を確認してください（文書で確認済みの事実 — Sources を参照）。
  • 効果音 — 同じ原則が適用されます。商用ポッドキャスト配信を対象とするライセンスを持つ効果音ライブラリを使用してください。
  • 音声 — 録音された人間の声については、すべての話者から許諾を得る必要があります。クローン音声／合成音声については、ライセンスを取得した、または同意を得た音源を使用し、TTS プロバイダーの商用利用条件を守る必要があります（一部の音声／プランは非商用利用のみです）。生成した音声を商用配信する権利がプロバイダーから付与されていることを、改めて確認してください。
  • 第三者の音声／クリップ — 会話の録音、楽曲、または別の番組の引用には、許可または有効なフェアユース／フェアディーリングの根拠が必要です。短いクリップなら自動的に問題ないと思い込まないでください。
  • 合成音声やクローン音声についての開示／同意 — §6 を参照してください。これは単なる削除要請にとどまらず、法的リスクを生じさせる項目です。

11. 公開前の品質チェック（省略しないでください）

リリースのたびに、公開前に実施してください。特に合成音声を使った番組では、生成時の誤りは実際に聴くまで気づけないため、人間（または注意深いエージェント）が通して聴く必要があります。

  1. 最初から最後まで、イヤホンを使い、通常の音量で全編を聴きます。発音ミス、声の変化、語尾の欠け、不自然なつなぎ、ぎこちないテンポ、音量差を確認します。
  2. 発音チェック — 番組の用語集と照合し、すべての名前、番組タイトル、スポンサー名を確認します。
  3. 構成チェック — オープニング／エンディングがあり、過去のエピソードと同じであること、セグメント間のつながり、広告枠の位置、コールドオープンの効果を確認します。
  4. ラウドネス／ピークの検証 — メーターを使い、統合 LUFS が目標値（約 -16 LUFS ステレオ／約 -19 LUFS モノラル）であること、トゥルーピークが ≤ -1 dBTP であること、クリッピングがないことを確認します（§7）。
  5. エンコード／形式 — コーデック、ビットレート、チャンネル数、サンプルレートが正しいこと、およびファイルがスマートフォンで再生できることを確認します。
  6. メタデータ — タイトル、変更されていない一意の GUID、説明、チャプター、バイト単位での正しいエンクロージャーの長さ、アートワーク、カテゴリ、露骨な内容を示すフラグを確認します（§8）。
  7. トランスクリプト — 添付されており、正確で、話者が明記されていることを確認します（§9）。
  8. 権利 — 音楽／効果音／音声の要素すべてについて、使用許諾が得られていることを確認します（§10）。
  9. 開示 — 法律またはプラットフォームで必要な場合、AI／合成音声についての開示が含まれていること、またクローン音声についての同意記録があることを確認します（§6）。
  10. フィードの検証 — フィードをバリデーターにかけ、公開前に正しく解析されることを確認します。

12. 作成例

以下は参考例であり、必須のテンプレートではありません。実際の依頼内容において、上記の判断がどのように組み合わさるかを示しています。具体的な内容は必要に応じて調整してください。

例 A — 完全合成による毎日の5分ニュースブリーフ

目的： ある業界のニュースを要約する、平日の定期配信「3分くらい」のブリーフです。ホストは合成音声1人のみで、Apple／Spotify／YouTubeで公開します。

形式と番組設定： 合成音声に適したニュースブリーフ形式です。ホストのペルソナは「Ava」1人で、中音域の落ち着いた声を安定性高めに固定します（ニュースが毎日同じ声に聞こえるようにします）。頻出する会社名と人名の用語集を、発音記号付きで用意します。音楽のイントロは8秒、アウトロは「チャンネル登録」を促すCTA付きで6秒に固定します。開示方針：番組の説明文とアウトロで1回、「これはAI生成のブリーフィングです」と明示します。

台本（耳で聞くことを意識した執筆）、短縮版：

[COLD OPEN — no music]
Three things moved the market today, and the third one nobody saw coming.

[THEME 8s, duck under]
This is The Daily Brief for Tuesday, July eighth. I'm Ava. Here's what matters.

[BODY]
First. [company], read "ACK-mee", reported earnings after the bell...
(short sentences. One idea each. A pause... before the turn.)

[OUTRO, theme up]
That's your brief. Follow the show so tomorrow's finds you automatically.
This is an AI-generated briefing from [publisher]. See you tomorrow.

TTS の指示： 本文全体をAvaの固定設定で生成します。段落ごとの感情表現は、本文では中立的かつ権威ある調子、アウトロのCTAでは少し明るい調子にします。数字と日付は台本で綴り字にします。1日につき2テイクを作成し、より自然な方を選びます。ラウドネス： モノラルで-19 LUFS、TP ≤ -1 dBTPにマスタリングし、MP3、モノラル、96 kbps、44.1 kHzでエンコードします。納品： 日ごとに一意のGUIDを付与します。台本から<podcast:transcript>のVTTを作成します。この長さではチャプターは不要です。開示： 説明文と音声付きアウトロで開示します（YouTubeでの合成音声に関する開示と、一般的な透明性の両方に対応します）。

想定される失敗モード： 声の固定設定を再利用しない場合に声がぶれること、音素の項目がないため「ACK-mee」が綴り字どおりの発音に戻ること、Spotifyの-14を追ってリミッターをかけすぎ、耳障りな音になること。

例 B — 2人のホストによるハイブリッド形式の対話型テック番組

目的： 毎週配信する35分番組です。実在する人間のホスト1人（録音）と、合成音声の共同ホストのペルソナ1人で構成します。これは難しいケースです。掛け合いと開示の両方が重要になります。

判断： ハイブリッド形式を採用します。人間のホストが自発性と信頼感をもたらし、合成音声の共同ホストは、一貫した「解説役」として低コストで補完します。同意／権利： 合成音声の共同ホストには、プロデューサーが商用利用を許諾された声を使います（記録を残し、プロバイダーの利用規約も確認済みです）。実在する人物をモデルにする場合は、署名済みの使用許諾が必須ですが、今回は該当しません。完全に合成されたペルソナです。開示： エピソード1と毎回の番組説明文で、合成音声の共同ホストをAI共同ホストとして正直に紹介します。合成音声が使われているため、YouTubeへのアップロード時に「このコンテンツの制作方法」の開示を有効にします。

掛け合いの設計： 人間のホストのパートは、台本の骨子に沿って生で録音します。合成音声の共同ホストの台詞は、割り込みや相づち（「そうですね、そうですね」）、人間のホストが直前に話した内容への呼応など、相手に「反応する」ように書きます。その後、共同ホストの声の固定設定で生成し、同じ場所で一緒に話しているように聞こえるよう、部屋鳴りを合わせて会話の隙間に編集します。発話の長さは意図的に不均等にします。

組み立てとラウドネス： 両方の声の音量をそろえ、会話中はBGMを12～15 dB下げ、ステレオで-16 LUFSにマスタリングします。TP ≤ -1 dBTPとし、AAC、ステレオ、128 kbpsでエンコードします。納品： セグメント構成に合わせてチャプター（<podcast:chapters>経由のJSON）を付けます。人間のホストとAI共同ホストを区別する、話者ラベル付きのWebVTTトランスクリプトを用意します。ダイナミック広告挿入用に、無音の広告挿入ポイントを設けます。

想定される失敗モード： 合成音声の返答が「別の場所で録音された」ように聞こえること（部屋鳴りを調整し、つなぎ目を目立たなくします）、発話の長さが均等で同じだと作り物っぽく聞こえること、プラットフォームのAI開示設定を忘れること、広告読み上げに必要な追加の配慮をせず、合成音声の共同ホストにスポンサー推薦を読ませてしまうこと。

例C — 再構成音声を含む物語形式のドキュメンタリーエピソード

意図： 入手できない歴史的な引用を合成音声で読み上げる、30分の物語です。

重要なルール： 合成音声で再構成した声や引用は、再現であることを必ず開示してください。本物のアーカイブ音声として提示してはいけません。ナレーション（「この後に続くのは、手紙に書かれた言葉をAIで再現したものであり、録音ではありません」）とトランスクリプトの両方で明示してください。実在する特定の人物の声を複製する場合は、さらにその人物の遺族から権利の許諾・同意を得る必要があります。中立的な「朗読者」の声を使えばその問題を避けられるため、権利を確保していない場合は、こちらのほうが安全です。それ以外は、物語のアクト構成（§5.1）、完全な脚本（§3）、および標準的な権利確認、ラウドネス（ステレオで-16 LUFS）、トランスクリプト、QAの各工程に従ってください。

出典

変動する情報（プラットフォームの仕様、ポリシー、法律）は、2026-07-10 時点で確認済みです。規格や制作上の目安には、本文中でその旨を記載しています。法律に関する注記は法的助言として扱わず、公開時に最新の法律とポリシーを確認してください。

規格とラウドネス

RSS／メタデータ／文字起こし／チャプター

プラットフォームの AI コンテンツポリシー

音声の権利と開示に関する法律（法的助言ではありません）

TTS の指針（ベストプラクティス文書、プロバイダーに依存しない音声合成）

音楽／効果音の権利（実務者向け参考資料）

形式、構成、台本作成（実務者向け参考資料）

コメント

Markdown 対応