24時間ライブ配信を止めない実践ガイド
1年運用で見えた5つの落とし穴

実際に安定運用できるようになった転機は、配信プロセスをずっと見張っていて、落ちたら自動で再起動してくれる「監視役（Watchdog）」を配信の外側に置いたことでした。配信ソフト自身に「がんばって復旧してね」と期待するのではなく、常時起動している別プロセスが配信プロセスを直接の子プロセスとして所有し、生死を監視する構成です。

落ちてから再起動までの検出時間は15秒以内。ここが長いと視聴者が「配信終了」と表示された画面を見て離脱してしまうので、できるだけ短く設計する価値があります。

もう一つ大事なのが「短時間に連続で失敗したときの対応」です。何か根本的な問題（設定ミス・ストリームキーの失効など）が起きている場合、監視役が15秒おきに再起動を繰り返す無限ループに陥ることがあります。そこで、短時間に5回など一定回数連続で失敗したら数分間クールダウン（再起動を一旦見送る）を入れる設計にしたところ、この無限リトライ問題は解消しました。

何度か数値を変えながら検証した結果、たどり着いたのが 1000kbps という設定値でした。数字だけ見ると控えめですが、これが最も安定して高い評価を得られる、というのが1年運用してきた結論です。24時間×365日流し続けるという条件下では、瞬間的な画質の高さよりも「途切れない・評価が落ちない」ことの方が圧倒的に重要でした。

エンコードのプリセットも同様で、処理は軽いはずの ultrafast は不安定になりやすく、多少処理負荷はあっても veryfast の方が安定性重視の運用には向いていました。

ここを疎かにすると、配信そのものが不安定になったり、視聴側の再生開始が遅くなったりします。設定ファイル上では -g 60 -keyint_min 60 -sc_threshold 0 のように指定し、フレームレートを30fpsに固定した上でキーフレーム間隔を揃えるのがポイントです。

地味な設定項目ですが、ビットレートやプリセットと同じくらい、24時間止めずに配信し続けられるかどうかを左右する要素でした。

原因は単純で、「起動しているかどうかの確認を怠ったまま、もう一度起動コマンドを叩いてしまった」ことでした。以来、起動前には必ず既存プロセスを全停止してから、1つだけ起動するというルールを徹底しています。

さらに踏み込んで、監視役（Watchdog）自体が配信プロセスをシングルトン（1つだけ）で管理する構成にしたことで、そもそも二重起動が起こり得ない仕組みに変えました。ルールを「気をつける」で運用するより、仕組みで防ぐ方が結局トラブルが減ります。

「著作権フリー」というのはサイト側の利用規約上の話であって、YouTubeのContent ID登録の有無とは別問題だと痛感した出来事です。24時間流し続ける配信では同じ曲が繰り返し再生されるため、一度でもContent IDにヒットするとその後もずっとリスクを抱え続けることになります。

最終的にたどり着いた、最も安全な調達方法が「著作権が完全に切れている古い時代（1900〜1930年代）の録音を Internet Archive から入手する」というやり方です。著作権が法的に完全に切れているため、Content ID登録される心配がありません。1920年代のジャズなど、24時間配信のBGMとしても雰囲気が合うものが多く見つかります。