メディアライブラリを作ろう
本章では、YouTubeやTikTokなどの大手拡散型プラットフォームを使用せず、自前の仕組みで動画やメディアを配信する方法について深掘りしていきます。つまり、クラウド時代の“ハンドメイド配信”を実現するための枠組みです。
1. 大手に依存しないということの意味
YouTubeなどの大手は、確かに拡散力や安定性に優れていますが、同時にそのプラットフォームの規約や方針変更に大きく左右されます。広告挿入やアルゴリズムによる露出制限など、制作者の意思とは無関係な制限が突然加わる可能性も否定できません。
私が目指すのは、小規模ながらも自由度が高く、そして制作者の意思で完結できる配信手段です。ただし、ここには大きな課題もあります。それは“小さな仕組みほど不安定で消えやすい”という現実です。
この課題は、製造業におけるサプライチェーンの問題と非常によく似ています。特定の国や工場に依存しすぎると、何らかの外的要因で供給が止まるリスクがあります。同様に、配信インフラが一箇所に依存していると、そのサービスが終了した瞬間にすべての再生が止まってしまいます。
だからこそ必要なのが「複数の再生サーバーを柔軟に切り替える仕組み」、つまりIF-THEN-ELSEの考え方です。
2. 再生URLの設計と意味
私が使っている再生URLの構造は以下の通りです：
| https://imakat.com/rd.php?id=Abcd0123.png |
- imakat.com は私の管理しているドメイン名です。
- rd.php は再生用の振り分けスクリプトです。
- id=Abcd0123.png の部分が、一意の識別子になっています。
この識別子にはランダムな8文字の英数字を使い、あえて拡張子（.png や .mp4 など）を付けた形式を採用しています。
これにより、URLだけを見てもおおよそのファイル種別が判断できるため、運用や整理の際にとても便利です。
よく見かける「拡張子なしのランダム識別子」も確かにセキュリティ的な利点はありますが、その一方でファイル内容の把握や管理は困難になります。
WordPressサーバー側で、phpスクリプトによって、選択された再生サーバー番号に合わせて、送り込んだJSONファイルとの照合を行ったりエンコード後のURLを生成するなどの作業を行っています。
ややこしい問題は、エンコードの方式が、サーバー会社によって異なる点です。各社が提供したエンコード後URLと、自分がファイルパスに基づく直リンクをエンコードしたURL、両者を比較して、それが一致するエンコード方式を使用することです。一致しないと、「ファイルが見つかりません」となり再生されません。
| WordPress(Xserver)内のURL再生が可能な状態にする(rd.php、再生用振り分けスクリプト) | php |
3. リンク提供とストリーミング再生の違い
この再生URLは、動画や音声などのストリーミング再生、画像再生を行うための仕組みですが、ファイルの直接ダウンロードリンクとしても応用可能です。たとえばExcelファイルの配布などにも対応できます。
ただし、再生URLをダウンロード専用の仕組みとして多用するのはおすすめしません。本来の目的はストリーミングにあるため、無理に使い方を広げすぎると運用が複雑になってしまいます。
4. 仕組みの流れ
以下が再生までの処理フローです：
- ユーザーがブラウザやメールクライアントなどから再生URLにアクセスする
- rd.php が呼び出され、該当する識別子（例：Abcd0123.png）に紐づくサーバーを判定する
- メディアライブラリアプリ(AppSheet)にて選ばれた再生サーバー（Dropbox、Xserver、pCloudなど）へ転送される
- ストリーミング再生が開始される
これにより、複数の配信先を動的に切り替えられる柔軟な配信構造が実現します。たとえ1つのサーバーに不具合が起きても、他のサーバーで代替再生が可能になります。
次回予告：
第４章では、「」についてご紹介します。
➡ 第４章を読む
