livestream-event-production

ライブ配信イベント制作

ユーザーが、ライブまたはハイブリッドのライブ配信イベントの計画、進行、リハーサル、運営、トラブル対応、引き継ぎを AI エージェントに依頼する場合に、このスキルを使用します。イベントには、ウェビナー、カンファレンスのセッション、タウンホール、ローンチ、パネルディスカッション、授業、募金活動、礼拝、パフォーマンス、クリエイターの番組、記者会見、複数会場で行うハイブリッドイベントなどがあります。

このスキルは、特定のプロバイダーに依存しない制作スキルです。単一プラットフォームの連携手順ではなく、実用的な制作計画を作成してください。

以下にはこのスキルを使用しないでください。

• 収録済みのライブ配信を、事後に再編集、パッケージ化、編集する場合。
• 特定のプロバイダーの API 連携、アカウント設定、またはダッシュボード固有のクリック手順を扱う場合。
• ライブスイッチング、ライブゲスト、インジェスト、モニタリング、インシデント計画を伴わない、純粋に映画的な事前収録動画を制作する場合。
• 出力がライブイベント計画でない限り、一般的な SNS 向けショート動画、ポッドキャスト、またはトーキングヘッド動画の再編集を行う場合。

根拠ラベル

主張を述べる際は、次のカテゴリを明確に区別してください。

• 文書で裏付けられた事実： 規格、公式ドキュメント、規制当局のページ、または正式な技術レポートで裏付けられた主張です。
• 変動するプラットフォーム固有の事実： プラットフォーム固有の設定、コーデック表、ビットレートの推奨値、インジェスト上限、機能の提供状況、ダッシュボードの動作などです。確認日を記載してください。
• 制作上のヒューリスティック： 規格ではない、現場で検証された運用上の指針です。普遍的な要件ではなく、判断の手がかりとして示してください。

運用モデル

ライブ配信は、ライブ番組であると同時に、ライブネットワークサービスでもあります。両方の側面を考慮してください。

エージェントは、次の資料を作成するか、ユーザーに提示を求めてください。

• イベント概要：対象者、目的、配信先、プライバシーレベル、権利、言語、アクセシビリティ、所要時間、成功指標。
• 進行表：各セグメント、時間、キュー、ソース、登壇者、スライド、グラフィック、ローワーサード、動画、投票、Q&A、スポンサー紹介、休憩、予備コンテンツの詳細。
• クルー計画：プロデューサー、テクニカルディレクター／スイッチャー、音声エンジニア、グラフィックオペレーター、配信エンジニア、ステージマネージャー、モデレーター、字幕担当、ゲスト対応担当、収録／メディア管理担当、インシデント対応責任者。
• 信号計画：カメラ、画面共有、リモートゲスト、再生、音声バス、グラフィック、プログラム、クリーンフィード、信頼性確認用モニター、連絡手段、収録、プラットフォームへのインジェスト。
• ネットワークと伝送の計画：コントリビューション、インジェスト、配信、レイテンシプロファイル、プライマリ／バックアップ経路、帯域幅の余裕、モニタリングポイント。
• リハーサルと実施可否の判断計画。
• インシデント計画と引き継ぎ資料一式。

初回確認事項

制作リスクに影響する不明点のみを確認してください。ユーザーから概要の一部しか提示されていない場合は、前提を明記して計画を進めてください。

重要な質問：

• イベントはライブ配信のみ、ハイブリッド、またはライブでのやり取りを含むライブ収録のどれですか？
• 想定視聴者数、配信先一覧、プライバシーの要件、アーカイブ配信の要件は何ですか？
• チャット、Q&A、投票、視聴者からの質問、オークション、寄付の呼びかけ、ライブ通訳、登壇者の舞台裏での交代など、どのやり取りにライブ感が必要ですか？
• それらのやり取りで許容できるレイテンシはどの程度ですか？
• 誰が、どこから、どのようなネットワーク／制御条件でカメラに登場しますか？
• 字幕、手話、音声解説、翻訳、またはコンプライアンス上の要件はありますか？
• 障害時にどこまで対応できますか。番組の一時停止、静止画への切り替え、音声のみへの切り替え、録画の再生は可能ですか。それとも中断なく続行する必要がありますか？
• 何を収録する必要がありますか。プログラム映像、クリーンフィード、カメラ個別の映像、ゲスト個別の映像、マルチトラック音声、字幕、チャット／Q&A、スライド、テレメトリーは必要ですか？

進行表

進行表は運営の管理文書です。時刻を定め、キューを出せるようにし、緊張する場面でも役立つ内容にしてください。

次の項目を含めます。

• イベントの絶対時刻と番組内の相対時刻；
• セグメントのタイトルと担当者；
• 本番中のソース、プレビュー中の次のソース、音声ソース、グラフィックの状態、字幕／通訳の状態；
• ホスト、プロデューサー、TD、音声、グラフィック、モデレーター、ステージマネージャー、リモートゲスト向けの正確なキュー文言；
• 想定所要時間、終了時刻、延長時の対応計画；
• インタラクションのトリガーと遅延への影響；
• ソースが利用できない場合のフォールバック。

制作上の経験則：人が画面外の依存関係を覚えている必要があるセグメントは、進行表に行を設けてください。スライド、動画、登壇者の入場、スポンサー読み、投票、字幕担当者の引き継ぎ、言語チャンネルの切り替え、モデレーションの移行はすべて、雰囲気ではなく行として記載します。

クルーと連絡

複数の役割を一人で担う場合でも、責任の所在に基づいて役割を割り当ててください。

• プロデューサー： 番組の意図、時間管理、実施可否の判断、クライアント／関係者との連絡窓口、インシデントのエスカレーションを担当します。
• テクニカルディレクター／スイッチャー： 本番映像の切り替え、プレビュー、マクロ、カメラ／ソースの準備、スレート、緊急時の映像フォールバックを担当します。
• 配信エンジニア： エンコーダー、インジェスト、ネットワーク、冗長化、プラットフォームの状態、配信テレメトリー、フェイルオーバーを担当します。
• 音声エンジニア： ミックスマイナス、ゲインステージング、ラウドネスの一貫性、エコー防止、音楽／再生音のルーティング、トークバックの分離、バックアップ音声を担当します。
• グラフィックオペレーター： ローワーサード、バグ、タイトル、タイマー、待機用スレート、該当する場合は字幕表示のルーティング、スポンサー／法務関連のグラフィックを担当します。
• ステージマネージャー／ゲスト対応担当： 登壇者の受付、控室、カウントダウン、ミュートの徹底、カメラの構図、同意、リモート登壇者のバックアップを担当します。
• モデレーター／コミュニティリード： チャットのルール、Q&Aの振り分け、エスカレーション、禁止語句、リンク方針、削除、安全に関する対応を担当します。
• 字幕／アクセシビリティ担当： ライブ字幕、該当する場合は通訳ウィンドウ、字幕プラットフォームへの経路、文字起こしの引き継ぎ、アクセシビリティの確認を担当します。
• 録画／メディア管理担当： 本番録画、ISO、ファイル名、ストレージ、バックアップ、字幕／文字起こし、イベント後の納品パッケージを担当します。

次の用途には、それぞれ別のチャンネルを使用します。

• 番組進行の指示：プロデューサー、TD、音声、グラフィック、配信エンジニア、ステージマネージャー；
• 登壇者用控室：ホスト、ゲスト、ゲスト対応担当；
• 関係者／クライアント向けの連絡事項：プロデューサーのみ、またはプロデューサーとクライアント担当者；
• インシデントのエスカレーション：意思決定権を持つ少人数の指名メンバー。

制作上の経験則：訓練を受けたオペレーターでない限り、登壇者を技術チャンネルに入れないでください。多くの配信中のミスは、適切でないカウントダウンを大勢が聞いていることで、さらに悪化します。

収録、切り替え、音声、グラフィック

カメラとソース

映像ソースごとに、次の項目を記録します。

• ソース名と担当者；
• 実際の場所またはリモートの場所；
• 解像度、フレームレート、判明している場合は色空間、アスペクト比；
• 想定するショットの種類または画面の内容；
• プライマリ経路とバックアップ経路；
• 音声、スライド、字幕、または別のカメラとの同期が必要かどうか。

制作上の経験則：

• 重要なスライドや動画には、その場しのぎの画面共有ではなく、安定した名前付きのソースを優先してください。
• ハイブリッド会場では、会場の観客とオンラインの観客を別々の観客として扱います。オンライン視聴者には、より近い構図、聞き取りやすい会場からの質問、明確な視覚的文脈が必要です。
• リハーサルの前に、待機用スレート、イベントタイトルカード、休憩用ループ、技術的な問題を知らせるスレート、エンドカードを読み込んでおいてください。

音声

音声の障害は、通常、映像の障害よりも大きな影響があります。

計画する項目：

• マイクの一覧、担当者、バッテリー／電源の計画；
• 番組ミックスと、クリーンフィード／ミックスマイナスフィードの有無；
• リモートゲストへの返し音声；
• 再生音と音楽の音量；
• エコーキャンセルの適用範囲；
• ハイブリッドイベントでの会場PAとの連携；
• 電話ブリッジ、予備のUSBマイク、会場の環境音マイク、セカンダリーインターフェースなどのバックアップ音声経路。

制作上の経験則：

• リモートパネルでは、エコーキャンセルを実際に使用するプラットフォームとルーティングでテストしていない限り、すべてのゲストにヘッドホンを使ってもらいます。
• 参加者本人の遅延した番組音声を返し音声として送ってはいけません。
• ミュート／ミュート解除の担当者を確認します。ゲストが自分でミュートできる場合、ステージマネージャーは迅速に復旧する方法を把握しておく必要があります。
• 障害時の計画では、ホストの音声を最優先のソースにします。画面が真っ黒でもホストの音声が明瞭なら乗り切れますが、音声が聞き取れなければ乗り切れません。

グラフィック

グラフィックは、ライブ配信中に運用できる状態として作成します：

• ローワーサードと名前の発音メモ；
• タイトルカード、アジェンダカード、休憩スレート、待機スレート、技術的な問題を知らせるスレート；
• タイマー、カウントダウン、スポンサー／法務用バグ、QRコード／リンク用グラフィック；
• 投票／Q&Aの結果；
• 字幕／手話通訳者のレイアウトへの配慮。

グラフィックで、字幕、手話通訳者、法的に必要な開示事項、スライドの重要な内容を隠してはいけません。

エンコード、インジェスト、伝送、配信

コントリビューション、インジェスト、視聴者への配信は分けて考えます。これらを混同すると、計画に不備が生じます。

• コントリビューション： カメラ、会場、エンコーダー、またはリモートゲストが、制作システムにフィードを送信します。
• インジェスト： 制作用エンコーダーが、完成したストリームまたは中間ストリームをプラットフォーム、CDN、クラウドスイッチャー、パッケージャー、またはリレーに送信します。
• 配信： 視聴者が再生コンテンツを受信します。通常はHTTPアダプティブストリーミング、プラットフォームプレーヤー、アプリ、またはインタラクティブなリアルタイムサービスを通じて配信されます。

RTMPとRTMPS

運用上のガイダンス：RTMPは、ストリーミングプラットフォームやエンコーダーへのライブコントリビューション／インジェスト経路として、今も広く使われています。RTMPSはTLSで暗号化されたRTMPであり、宛先が暗号化インジェストに対応している場合はこちらが推奨されます。RTMP(S)は主にコントリビューション／インジェスト用のプロトコルとして扱い、ブラウザーでの視聴者向け再生に使う最新のレイヤーとは区別してください。

2026-07-11に確認した、変わりやすいプラットフォーム情報：YouTubeのライブエンコーダー向けドキュメントには、RTMPおよびRTMPSインジェストが記載されています。また、Googleのサーバーへの送信時とサーバー内でストリームが暗号化されるためRTMPSを推奨し、ライブ配信前のテストとストリームの健全性の監視も推奨しています。同じページには、プラットフォーム固有のコーデック、キーフレーム、ビットレート、音声に関するガイダンスも記載されており、制作前に再確認する必要があります。出典：https://support.google.com/youtube/answer/2853702

制作上の経験則：

• ストリームキーは非公開にし、広く共有する進行表には記載しないでください。
• 宛先が対応している場合は、バックアップ用のインジェストURL／キーを用意します。
• 公衆インターネット経由でRTMPを使用する場合は、ネットワークの安定性とエンコーダーの健全性を優先します。再送の動作やプラットフォーム側のバッファリングは、実装によって異なるためです。

SRT

確認済みの事実：SRT インターネットドラフト「The SRT Protocol」では、SRT は、低遅延のライブ動画配信に最適化された、信頼性と安全性の高い伝送を実現する UDP 上のユーザーレベルプロトコルとして説明されています。また、発信側・待受側とランデブーの接続構成、ハンドシェイク時にピアが提案する最大遅延としてネゴシエートされる SRT バッファー遅延、ライブストリーム向けの遅すぎるパケットの破棄を伴う ARQ／NAK ベースのパケット再送、鍵素材の交換を用いた AES-CTR ペイロード暗号化についても説明されています。このドラフトは 2021 年に失効しているため、プロトコルの説明として扱い、最新の実装ドキュメントと併せて参照してください。出典確認日：2026-07-11：https://datatracker.ietf.org/doc/html/draft-sharabayko-srt-00

確認済みの事実：Haivision の公開 SRT API ドキュメントでは、バインド／待受／受け入れ、srt_connect による発信側の接続、SRTO_RENDEZVOUS または srt_rendezvous によるランデブーのセットアップ、ライブ伝送のデフォルト、SRTO_RCVLATENCY、SRTO_PEERLATENCY、SRTO_TLPKTDROP、SRTO_NAKREPORT、SRTO_PASSPHRASE、SRTO_PBKEYLEN などのソケットオプション、および鍵素材の状態オプションについて説明されています。出典確認日：2026-07-11：https://github.com/Haivision/srt/blob/master/docs/API/API.md および https://github.com/Haivision/srt/blob/master/docs/API/API-socket-options.md

運用上の指針：SRT は、低遅延、パケット回復、暗号化オプション、発信側／待受側／ランデブーの接続モードが重要となる、不安定なネットワークを介した素材伝送でよく使用されます。正確な動作は実装によって異なります。エンコーダー／デコーダーのビルド、公開されているソケットオプション、ファイアウォール／NAT の動作、クラウド受信側のポリシー、バージョンのサポート状況によって、設定および監視できる内容が決まります。

SRT を使用する場面：

• 会場やリモートカメラから、公衆インターネット経由で制作コントロールルームに映像を送る必要がある場合。
• ネットワークの状態にばらつきがあるものの、設定した遅延バッファーを許容できる場合。
• チームが送信側と受信側の両方の設定を管理している場合。
• ファイアウォール／NAT の役割を事前にテストできる場合。

本番運用のヒューリスティクス：

• SRT の遅延は、本番運用上のトレードオフとして設定してください。値を小さくすると反応は速くなりますが、回復に使える時間が短くなります。値を大きくすると耐障害性は向上しますが、遅延も増加します。
• 可能であれば、同じネットワーク経路と時間帯でリハーサルを行ってください。
• 本番当日までに、暗号化、パスフレーズのポリシー、ポートの方向、発信側／待受側／ランデブーの役割、およびフォールバックを確認してください。

HLS

確認済みの事実：HTTP ライブストリーミング（HLS）は、プレイリストとメディアセグメントを使用します。RFC 8216 では、メディアプレイリスト、マスタープレイリスト、メディアセグメント、バリアントストリーム、レンディション、ターゲット時間、シーケンス／不連続性の動作、および WebVTT 字幕の格納が定義されています。出典：RFC 8216、https://www.rfc-editor.org/rfc/rfc8216

サブ秒単位のやり取りよりも、配信規模、デバイスのサポート、CDN 配信、アダプティブビットレート再生が重要な場合、幅広い視聴者への配信に HLS を使用してください。

計画時の留意事項：

• HLS の配信遅延は、エンコーダーの設定、セグメント時間、プレイリストの動作、パッケージャー／オリジンの動作、CDN、プレーヤーのバッファー、およびプレーヤーのライブエッジポリシーの影響を受けます。
• マスタープレイリストを使用すると、プレーヤーはバリアント／レンディションを選択できます。シームレスに切り替えるには、それらのバリアントでコンテンツを同期させる必要があります。
• HLS ワークフローでは WebVTT を字幕／キャプションに使用できますが、プラットフォーム固有のキャプション取り込みおよび表示の動作を確認する必要があります。

本番運用のヒューリスティクス：チャットや質疑応答が視聴者の正確なタイミングに依存する場合、すべての HLS 視聴者に同じ瞬間が表示されると想定しないでください。バッファーを考慮して、やり取りの時間枠を設計してください。

WebRTC

文書に記載された事実：W3C WebRTC 1.0 では、ピア接続、メディアトラック、データチャネル、ICE、DTLS トランスポート、RTP メディア、統計情報の取得機能など、ブラウザー間のリアルタイム通信が規定されています。出典：W3C 勧告、2025 年 3 月 13 日、https://www.w3.org/TR/webrtc/

文書に記載された事実：RFC 8835 では、UDP/TCP に関する前提、NAT やファイアウォールを通過するための ICE/STUN/TURN、メディアの鍵設定に使用する DTLS-SRTP、データチャネル向けの ICE 上の DTLS 上の SCTP、QoS と優先順位付けに関する考慮事項など、WebRTC のトランスポートプロトコルが説明されています。出典：RFC 8835、https://www.rfc-editor.org/rfc/rfc8835

文書に記載された事実：RFC 8834 では、RTP/RTCP、SRTP/SRTCP、輻輳制御の要件、RTCP フィードバック、パケット損失やジッターの統計によるパフォーマンス監視など、WebRTC のメディアトランスポートと RTP の使用方法が説明されています。出典：RFC 8834、https://www.rfc-editor.org/rfc/rfc8834

次の場合は WebRTC を使用します。

• リモートのゲストと自然に会話する必要がある場合
• 視聴者とのやり取りで極めて低いレイテンシが必要な場合
• ブラウザーからの参加、データチャネル、または会議形式のトポロジーがワークフローに必要な場合
• 想定される視聴者数とアーキテクチャが対応できる場合

計画上の留意点：

• WebRTC は、自動的に大規模配信向けのシステムになるわけではありません。大規模な視聴者への配信には通常、SFU、リレー、ブリッジ、または HTTP 配信形式への変換が必要です。
• TURN の処理能力が、リモートゲストや双方向で参加する視聴者にとって、見えにくいボトルネックになることがあります。
• 実装で取得できる場合は、ICE の状態、選択された候補ペア、往復時間、ジッター、パケット損失数、フレームのドロップ数、品質制限の理由、送信可能なビットレート、音声レベル、フリーズを監視してください。W3C WebRTC Statistics API では、これらの識別子の多くが定義されていますが、Candidate Recommendation Draft のため、各フィールドが利用可能かどうかは今後変更される可能性があります。出典：https://www.w3.org/TR/webrtc-stats/

レイテンシと双方向性

一般的に速くしたいという理由ではなく、視聴者とのやり取りに応じてレイテンシのプロファイルを選んでください。

必要性	推奨プロファイル	備考
一方向の基調講演、大規模な視聴者、リプレイ優先	標準／通常レイテンシの HTTP 配信	より安定します。チャットは非同期でも対応できます。
ホストがチャットから質問を選ぶライブ Q&A	対応している場合は低レイテンシの HTTP／プラットフォームモード	モデレーションの遅延を加え、時間の余裕を見込んで質問してください。
双方向のパネル、リモートからの参加者、オークション、ライブ授業	WebRTC／会議経路、または専用の低レイテンシサービス	ゲストの制御強化、TURN／ネットワークの計画、モデレーションが必要です。
信頼性が最優先される配信、コンプライアンス、字幕、複数の CDN	安定性を優先したレイテンシ	リハーサル済みのフェイルオーバーを用意し、テストしていない低レイテンシモードは避けてください。

変動するプラットフォーム情報（2026-07-11 に確認）：YouTube のエンコーダ設定ページによると、4K／2160 コンテンツは低レイテンシ配信では利用できず、通常レイテンシでの品質を重視して最適化されています。プラットフォームの機能は変更されるため、この情報を前提とする場合は事前に再確認してください。出典：https://support.google.com/youtube/answer/2853702

制作上の目安：レイテンシを下げると、信頼性の余裕が減ります。番組形式に見合う場合に限り、レイテンシを下げてください。

帯域幅と冗長性

エンコーダーのビットレートだけでなく、経路全体から帯域幅を算出してください。

以下を含めます。

• 番組のビットレートに音声とプロトコルのオーバーヘッドを加えたもの。
• 同時配信する場合はバックアップストリーム。
• リターンフィード、連絡用音声、モニタリング、字幕、リモートゲストのフィード、クラウドでのスイッチング、ファイル転送。
• 会場のほかの通信と Wi-Fi の混雑。
• アップロード、ダウンロード、パケット損失、ジッター、持続可能なスループット。

制作上の目安：

• 管理下のネットワークでは、計画しているアウトバウンド配信負荷の合計の少なくとも 2 倍の持続的な上り容量を確保してください。共有、無線、セルラー、または不明な経路では、さらに余裕を持たせてください。
• 同じラストマイルの障害要因、電源、ルーター、スイッチ、SIM キャリア、またはアカウントのデータ容量制限を共有するバックアップ経路は、冗長性があるものとして数えないでください。
• ボンディングやセルラー経路は役立ちますが、万能ではありません。混雑、データ容量制限、熱による影響、アンテナの設置場所、負荷時のフェイルオーバーをテストしてください。
• オフライン用のフォールバック素材を読み込んでおいてください。技術情報のスレート、ホストの電話参加用スクリプト、緊急用の事前収録オープニング、または音声のみのブリッジなどが該当します。

冗長性のレベル：

• レベル 0： エンコーダー 1 台、ネットワーク 1 つ、配信先 1 つです。重要度の低い配信にのみ使用してください。
• レベル 1： プライマリに、同じネットワーク上のバックアップエンコーダープロファイルまたはバックアップインジェストを加えます。一部のソフトウェアや設定の障害から保護します。
• レベル 2： 別のエンコーダーまたは別のマシンに、別のネットワーク経路を組み合わせます。より多くのローカル障害から保護します。
• レベル 3： 並行制作またはクラウドフェイルオーバーに、別系統の電源とネットワーク、バックアップオペレーター、配信先のフェイルオーバー、またはマルチ CDN を組み合わせます。重要度の高い公開イベントに必要です。

リハーサルと実施可否の判断

少なくとも次の 3 種類のチェックを実施してください。

• 技術ラインチェック： すべてのソース、マイク、グラフィック、再生素材、字幕経路、リモートゲスト経路、録画経路、配信先のインジェストを確認します。
• キューからキューまでのリハーサル： トランジション、オープニング、休憩、登壇者の交代、視聴者とのやり取り、ローワーサード、動画の再生、緊急用スレートを確認します。
• 総合リハーサル： 実際の進行時間、オペレーター、ネットワーク、配信先または非公開のテスト配信先、字幕・モデレーションのワークフローを使って実施します。

実施可否の判断には、次の項目を含めてください。

• プライマリとバックアップのインジェストが稼働中、または準備完了であること。
• 番組音声が明瞭で、メーターが安定していること。
• 必要な場合、字幕経路が検証済みであること。
• 録画経路が有効で、ストレージを確認済みであること。
• 連絡用音声が安定していること。
• ゲストの名前、発音、ローワーサードが確認済みであること。
• 権利、同意、許諾が確認済みであること。
• モデレーションルールが有効であること。
• インシデント対応リードが指名されていること。
• 最終的な開始について関係者の承認を得ていること。

制作上の目安：誰かが障害への対処を実際に練習するまでは、リハーサル完了としないでください。ゲストの切断、マイクの不具合、スライドソースの停止、エンコーダーの警告、プラットフォームの状態に関する警告、または緊急用スレートへの切り替えなどを練習します。

字幕、アクセシビリティ、インクルージョン

確認済みの事実：WCAG 2.x の達成基準 1.2.4 では、レベル AA において、同期メディアのライブ音声コンテンツに字幕を付けることが求められています。W3C WAI によると、ライブ字幕は通常、専門のリアルタイム字幕作成者／CART ライターが提供し、自動字幕は完全に正確であることが確認されない限り十分ではありません。出典確認日 2026-07-11：https://www.w3.org/WAI/media/av/captions/ および https://www.w3.org/WAI/media/av/planning/

確認済みの事実：FCC は、47 CFR Part 79 の参照を含む、テレビ番組のクローズドキャプションに関する米国の規則と品質・責任に関する資料を提供しています。管轄区域と適用可能性は、配信状況ごとに確認する必要があります。出典確認日 2026-07-11、ページ更新日 2026年4月8日：https://www.fcc.gov/general/closed-captioning-video-programming-television

確認済みの事実：47 CFR § 79.4 は、インターネットプロトコルを使用して配信される映像番組のクローズドキャプションを規定しています。同規則では、IP 配信映像番組の役割と要件を定めており、対象となる映像番組の所有者には、同じ番組のテレビ字幕と少なくとも同等の品質で必要な字幕を送信する義務があり、対象となる配信事業者／プロバイダーには、エンドユーザーが必要な字幕を表示できるようにするか、字幕をそのまま通過させる義務があります。適用可能性は、その番組が同規則の対象となる非免除の映像番組に該当するかどうかによって異なります。出典確認日 2026-07-11（eCFR、Title 47 の表示は 2026-07-09 時点で最新）：https://www.ecfr.gov/current/title-47/chapter-I/subchapter-C/part-79/section-79.4

以下を計画してください。

• ライブ字幕の提供者、または正確性が確認された自動字幕；
• 字幕のソースと、プラットフォーム／プレーヤー／録画への経路；
• グラフィックで覆われない字幕表示領域；
• イベント後のトランスクリプトの引き渡し；
• 必要に応じて、言語通訳、手話通訳者の映像配置、または音声解説；
• 読みやすい文字とコントラストを備え、視覚情報のみのコンテンツを言葉で説明するアクセシブルなスライド；
• 配信中にアクセシビリティに関する要望があった場合のモデレーター向け手順。

制作上の指針：

• 字幕が必要な場合、字幕の喪失は見た目の問題ではなく、番組進行上のインシデントとして扱ってください。
• 字幕作成者には事前準備が必要です。名前、専門用語、頭字語、議題、登壇者リスト、URL、スポンサー名、技術用語を共有してください。
• 手話通訳者のウィンドウには、安定した映像、レイアウト上の優先表示、テロップで隠されないための配慮が必要です。

モデレーション、同意、権利、安全性

配信開始前に、以下を計画してください。

• カメラに映る可能性のある人と、同意を記録するかどうか；
• 視聴者のチャット／Q&A が公開、非公開、遅延表示、またはモデレーション対象のいずれであるか；
• 禁止用語、リンクの方針、スパムへの対処、エスカレーション、削除の権限；
• 登壇者の出演許諾、音楽の権利、ストック素材／メディアの権利、スポンサー／法務関連の文言、再配信の権利；
• 未成年者、患者、学生、従業員、機密情報、または制限付きイベントに関するプライバシーの取り扱い；
• 緊急停止の基準と、配信の停止、ゲストのミュート、チャットの非表示、または発言者の削除を実行できる担当者。

制作上の指針：モデレーションの対応経路は、インシデントよりも速くなければなりません。有害なメッセージ、個人情報、または安全でない発言者が現れた場合、モデレーターが5人に許可を求めなくても対応できるようにしてください。

監視とインシデント対応

複数のポイントで監視します。

• エンコード前のローカルプログラム出力；
• エンコーダーの健全性：CPU/GPU、ドロップフレーム、出力ビットレート、キーフレーム間隔、音声サンプルレート、再接続；
• ネットワーク：上りスループット、パケット損失、ジッター、経路変更、インターフェイスのフェイルオーバー、携帯電話の電波強度；
• インジェストの健全性：プラットフォーム／サーバーでの受信、バックアップインジェストの状態、ストリームのステータスメッセージ；
• 視聴者の再生状況：本番環境とは異なるネットワーク上の独立した視聴者、字幕、音声同期、チャット／Q&A；
• 録画：プログラム録画、クリーンフィード、ISO、音声マルチトラック、字幕／文字起こし。

インシデント対応のワークフロー：

1. 症状を明確にします。何が変化したのか、誰がそれを確認しているのか、いつ始まったのか、どの監視ポイントで検知したのかを記録します。
2. 視聴者への影響を抑えます。スレート画面を表示する、ホストがつなぐ、問題のあるソースをミュートする、バックアップに切り替える、ネットワークを切り替える、ビットレートを下げる、インタラクションを一時停止する、または音声のみへ移行します。
3. 証拠を保全します。タイムスタンプ、スクリーンショット／ログ、プラットフォームの健全性メッセージ、エンコーダーの統計情報、オペレーターのメモを残します。
4. 方針を決めます。続行、品質を落として続行、フェイルオーバー、一時停止、再起動、中止のいずれかを選びます。
5. 情報を共有します。ホスト、関係者、チャット／モデレーターに向けた、プロデューサー承認済みのメッセージを1つ用意し、イベント後のメモにも記録します。

制作上のヒューリスティクス：

• 番組出力上でライブデバッグをしないでください。まず安定したソースに切り替えます。
• 音声と映像にずれが生じた場合、視聴者が監視役になってしまう前に、修正、切り替え、または簡素化のどれを行うか決めます。
• インシデントについては、事実に基づき、落ち着いた言葉で伝えます。「リモートゲストのフィードを復旧しています」は、「すべてが壊れています」より適切です。

録画、ISO、引き継ぎ

イベント前に、記録するものを決めておきます。

• 視聴者に見えるグラフィックと字幕を含むプログラム；
• グラフィックなしのクリーンフィード；
• カメラ映像の個別フィード；
• リモートゲストの個別フィード；
• マルチトラック音声またはステム；
• スライド、再生用ファイル、グラフィックパッケージ、字幕ファイル、文字起こし、チャット／Q&Aのエクスポート；
• テレメトリ、インシデントログ、実際の時刻を記載したラン・オブ・ショー。

引き継ぎパッケージには、次の内容を含めます。

• 必要に応じて、最終録画の保存場所とチェックサム；
• ファイルの命名規則とストレージの管理者；
• 既知の問題とタイムスタンプ；
• 権利／使用上の制限；
• 字幕／文字起こしの状況；
• リプレイの公開手順；
• 事後検証のメモと推奨される修正。

制作上のヒューリスティクス：プラットフォーム側で録画する場合でも、可能であればローカルで録画してください。プラットフォーム側の録画は、開始が遅れたり、クリーンフィードが含まれなかったり、ISOを取りこぼしたり、音声がダウンミックスされたり、字幕／チャットが含まれなかったりする場合があります。

例：75 分間のハイブリッドパネルの計画

これは一例であり、必須の定型ではありません。

概要：

• 視聴者：オンライン 800 人、会場内 120 人。
• 形式：ハイブリッド形式の基調講演、パネル、進行役付き Q&A。
• 要件：字幕、リプレイ、スポンサーのローワーサード、チャットでの質問。
• 遅延：Q&A には十分低くする必要がありますが、視聴者との双方向ビデオは不要です。
• 障害許容度：配信をホスト画面またはスレートに切り替えることはできますが、停止はできません。

推奨プラン：

• 配信：配信先が対応している場合は、低遅延モードでプラットフォーム／CDN の HTTP 配信を使用します。インタラクティブ性が必要なのは Q&A のテキストだけなので、WebRTC による視聴者向け配信は避けます。
• 入力：会場のカメラ／スイッチャーはローカルで運用します。リモートのパネリストは、テスト済みの会議／WebRTC 入力を通じて制作に参加し、接続が切れた場合に備えて電話音声も用意します。
• 音声：会場のラベリアマイクと質問用マイクを使用します。リモートパネリストにはミックスマイナスを設定し、ホストのマイクを優先します。ステージには予備のハンドマイクを用意します。
• グラフィック：タイトル、議題、ローワーサード、スポンサーのロゴ表示、Q&A の案内、休憩／技術的な問題を知らせるスレート。
• クルー：プロデューサー、TD、音声担当、配信エンジニア、ステージマネージャー、モデレーター、字幕担当、グラフィック担当、録画管理担当。
• 冗長化：主回線の有線インターネットに加え、別系統のセルラー／ボンディング回線をバックアップにします。バックアップのエンコーダープロファイルからバックアップの取り込み先へ接続します。番組をローカルとプラットフォームの両方で録画します。リモートパネリストが接続できなくなった場合に備えて、予備のスライド／動画を用意します。
• リハーサル：前日に回線チェックを行います。リモートパネリストの 30 分間の技術チェックを実施し、ホストとモデレーターを交えたキュー・トゥ・キューを行います。リモートパネリストとの接続が切れた場合の障害訓練も実施します。

進行表の行の例：

時間	セグメント	番組内容	音声	グラフィック	キュー	代替策
-00:10	待機	アニメーションスレート	小さめの音量で音楽	イベントタイトル＋字幕に関する案内	配信エンジニアが取り込みを確認	エンコーダーから静止スレートを送出
00:00	開始	カメラ 1 のホスト	ホストのラベリアマイク	ホストのローワーサード	プロデューサー：「ホスト、5 秒後にライブです」	スレートを維持し、ホストの音声のみ送出
00:08	リモートパネリスト紹介	ホスト／ゲストの 2 分割画面	ホスト＋ゲストのミックスマイナス	ゲストのローワーサード	ステージマネージャーがゲストの準備完了を確認	ホストがゲストの要点をまとめる
00:45	Q&A	ホストのカメラ、質問カード	ホスト＋会場のマイク	Q&A のローワーサード	モデレーターが承認済みの質問を伝える	用意しておいた予備の質問
01:10	終了	カメラ 1 のホスト	ホストのラベリアマイク	お礼／終了カード	プロデューサー：「2 分後に必ず終了です」	終了カードと音楽

例：インシデント対応の判断ツリー

これは一例であり、必須の定型ではありません。

症状：プラットフォームが配信の不安定さを報告し、視聴者モニターではバッファリングが発生しています。

1. 配信エンジニアが、エンコーダーのドロップフレーム、出力ビットレート、CPU／GPU、ネットワークのアップロード状況を確認します。
2. エンコーダーに過負荷がかかっている場合：出力プロファイルを下げるか、予備のエンコーダーのシーン／プロファイルに切り替えます。
3. アップロード経路が不安定な場合：バックアップネットワークまたはボンディング回線に切り替え、安定するまでビットレートを控えめに保ちます。
4. ローカルとネットワークが安定しているのにプラットフォームの取り込みに問題がある場合：準備済みであれば、バックアップの取り込み先／配信先に切り替えます。
5. 視聴者の再生だけに影響している場合：番組を中断する前に、独立した視聴者モニター、プラットフォームのステータス、CDN／プレーヤーの報告、チャットの投稿数を確認します。
6. ホストが状況に触れるか、モデレーターがステータスを投稿するか、または何も伝えずに番組を続行するかを、プロデューサーが判断します。
7. 録画管理担当がインシデントの発生時刻を記録し、ローカル録画に問題がないことを確認します。

例：伝送方式の選択の概要

これは一例であり、必須の公式ではありません。

シナリオ	選択肢の例	理由
エンコーダーから一般的なプラットフォームへの取り込み	対応している場合はRTMPS、そうでなければプラットフォームが承認するRTMP/SRT経路	一般的なプラットフォーム取り込み方式です。利用可能な場合は取り込みを暗号化します。
会場のカメラからリモートのコントロールルームへの伝送	SRTまたはマネージド寄与伝送サービス	遅延と復旧を調整でき、エンドポイントを制御できます。
大規模な一般視聴者向けの再生	HLSまたはプラットフォーム/CDNによるアダプティブ配信	幅広いデバイスとCDNの規模に対応し、アダプティブビットレートを利用できます。
リモートゲストとの自然な会話	WebRTC／会議／SFU経路	低遅延の双方向メディアとデータ／制御インターフェースに対応します。
基調講演中に視聴者がテキストで質問する	HLS／プラットフォーム配信とモデレーション付きチャット／Q&A	モデレーションの時間枠を適切に設計すれば、テキストは配信の遅延を許容できます。
ライブで電話の参加者を番組に招く	WebRTC／会議からスイッチング済み番組への寄与伝送	モデレーション、同意、IFB／返し音声、および迅速な退出手段が必要です。

2026-07-11に確認した出典メモ

• HLSの文書化された事実：RFC 8216「HTTP Live Streaming」、2017年8月、https://www.rfc-editor.org/rfc/rfc8216
• WebRTC APIの文書化された事実：W3C勧告「WebRTC: Real-Time Communication in Browsers」、2025年3月13日、https://www.w3.org/TR/webrtc/
• WebRTCトランスポートの文書化された事実：RFC 8835「Transports for WebRTC」、2021年1月、https://www.rfc-editor.org/rfc/rfc8835
• WebRTC RTP／メディアの文書化された事実：RFC 8834「Media Transport and Use of RTP in WebRTC」、2021年1月、https://www.rfc-editor.org/rfc/rfc8834
• 変動性に関する注記付きのWebRTC統計情報の文書化された事実：W3C勧告候補ドラフト「Identifiers for WebRTC's Statistics API」、取得した最新版の日付は2025年9月25日、https://www.w3.org/TR/webrtc-stats/
• アクセシビリティ／キャプションの文書化された事実：W3C WAIのキャプションおよび計画に関するページ、2024年9月17日更新、https://www.w3.org/WAI/media/av/captions/ および https://www.w3.org/WAI/media/av/planning/
• 米国のキャプションに関する規制の参考資料：FCC「Closed Captioning of Video Programming on Television」、2026年4月8日更新、https://www.fcc.gov/general/closed-captioning-video-programming-television
• IP配信動画のキャプションに関する米国の規制の参考資料：eCFR、47 CFR § 79.4「Closed captioning of video programming delivered using Internet protocol」、2026-07-11に取得、Title 47は2026-07-09時点の現行版として表示、https://www.ecfr.gov/current/title-47/chapter-I/subchapter-C/part-79/section-79.4
• SRTプロトコル／出典メモ：インターネットドラフト「The SRT Protocol」、draft-sharabayko-srt-00、2021年9月9日に失効、https://datatracker.ietf.org/doc/html/draft-sharabayko-srt-00；Haivision SRT APIおよびSRT API Socket Options、2026-07-11に取得、https://github.com/Haivision/srt/blob/master/docs/API/API.md および https://github.com/Haivision/srt/blob/master/docs/API/API-socket-options.md
• 変動するプラットフォーム情報：YouTubeヘルプ「Choose live encoder settings, bitrates, and resolutions」、2026-07-11に取得、https://support.google.com/youtube/answer/2853702