本章では、YouTubeやTikTokなどの大手拡散型プラットフォームを使用せず、自前の仕組みで動画やメディアを配信する方法について深掘りしていきます。つまり、クラウド時代の“ハンドメイド配信”を実現するための枠組みです。

1. 特定の大手に依存しないということの意味

YouTubeなどの大手は、確かに拡散力や安定性に優れていますが、同時にそのプラットフォームの規約や方針変更に大きく左右されます。広告挿入やアルゴリズムによる露出制限など、制作者の意思とは無関係な制限が突然加わる可能性も否定できません。それからYouTubeやTikTokなど大手の多くは、少し手を加えるだけで簡単に他人の動画を切り抜いて転用できる、AI自動生成物がその真偽を検証されることなく配信される、そうした緩さがあるため、どうしても信用性は低く、オモチャや娯楽の道具として一段低く扱われやすいことがあります。

私が目指すのは、小規模ながらも自由度が高く、そして制作者の意思で完結できる配信手段です。ただし、ここには大きな課題もあります。それは“小さな仕組みほど不安定で消えやすい。小さな会社ほど資金が乏しくすぐ倒産する。”という現実です。

この課題は、製造業におけるサプライチェーンの問題と非常によく似ています。特定の国や工場に依存しすぎると、何らかの外的要因で供給が止まるリスクがあります。そうでないにしても関税のように異常な高コストになるリスクがあります。同様に、配信インフラが一箇所に依存していると、そのサービスが終了した瞬間にすべての再生が止まってしまいます。

だからこそ必要なのが「複数の小規模の再生サーバーを柔軟に切り替える仕組み」です。

2. 再生URLの設計と意味

私が使っている再生URLの構造は以下の通りです：

• imakat.com は私の管理しているドメイン名です。
• rd.php は再生用の振り分けスクリプトです。
• Abcd0123.png の部分が、一意の識別子になっています。

この識別子にはランダムな8文字の大小英文字数字を使い、あえて拡張子（.png や .mp4 など）を付けた形式を採用しています。
これにより、URLだけを見てもおおよそのファイル種別が判断できるため、運用や整理の際にとても便利です。

よく見かける「拡張子なしのランダム識別子」も確かにセキュリティ的な利点はありますが、その一方でファイル内容の把握や管理は困難になります。

WordPressサーバー側で、phpスクリプトによって、選択された再生サーバー番号に合わせて、送り込んだJSONファイルとの照合を行ったりエンコード後のURLを生成するなどの作業を行っています。

直リンク方式の場合は、ファイルパスのエンコードが必要

直リンク方式(ファイルパス方式)の場合に、ファイルパスのエンコードが必要になりますが、ややこしい問題は、そのエンコードの方式が、サーバー会社によって異なる点です。各社が提供したエンコード後URLと、自分がファイルパスに基づく直リンクをエンコードしたURL、両者を比較して、それが一致するエンコード方式を使用することです。一致しないと、「ファイルが見つかりません」となり再生されません。

この問題を除けば、直リンク方式の方が、今回行っているような構築は、はるかに簡単に済みます。
ただし現実には、直リンク方式を提供するクラウドストレージの会社は非常に少なくなり、pCloudはそのうちの1社です。

WordPress(Xserver)内のURL再生が可能な状態にする(rd.php、再生用振り分けスクリプト)

結局、そのクラウドストレージがその内部にWebサーバーを建てること(Webホスティング)を許可しているかどうか、Webサーバーを建てることができれば、直リンク方式の開放ができる可能性が高いです。次章で深掘りしますが、残念ながら、例えば、Dropbox、Googleドライブ、iCloudドライブ、Oneドライブなど主要大手は、ストレージの中にWebサーバーを建てることができなくなっているわけです。その中で、Dropboxはraw=1により表示が可能、pCloudはパブリックフォルダにより表示が可能、と珍しい存在になっているわけです。

ただし、直リンク方式は、ファイルパスやファイル名を変更するとリンク切れを起こす、という致命的欠点があります。この欠点の克服方法を、別の章で紹介することにします。

3. リンク提供とストリーミング再生の違い

再生URLは、動画や音声などのストリーミング再生、画像再生を行うための仕組みですが、ファイルの直接ダウンロードリンクとしても応用可能です。たとえばExcelファイルの配布などにも対応できます。

ただし、再生URLをダウンロード専用の仕組みとして多用するのはおすすめしません。本来の目的はストリーミングにあるため、無理に使い方を広げすぎると運用が複雑になってしまいます。

4. 再生までの処理フロー

以下が再生までの処理フローです：

1. ユーザーがブラウザやメールクライアントなどから再生URLにアクセスする
2. rd.php が呼び出され、該当する識別子（例：Abcd0123.png）に紐づくサーバーを判定する
3. メディアライブラリアプリ(AppSheet)にて選ばれた再生サーバー（Dropbox、Xserver、pCloudなど）へ転送される
4. ストリーミング再生が開始される

これにより、複数の配信先を動的に切り替えられる柔軟な配信構造が実現します。たとえ1つのサーバーに不具合が起きても、他のサーバーで代替再生が可能になります。

次回予告：

第４章では、「リンク切れを防ぐ仕組みほか」についてご紹介します。

➡ 第４章を読む

🔗 目次ページへ戻る