大手YouTubeなどに依存せず、独自に配信を行うのであれば、小規模な配信所を複数確保し、さらにそれらを迅速に切り替えられる仕組みを整えることが重要です。
ここまでの章では、配信所には「トークンリンク方式」と「直リンク方式」があり、それぞれに特徴と注意点があることを説明してきました。

• トークンリンク方式は、大手クラウドが採用しており、セキュリティ重視。そのうちDropboxなど限られたサービスのみが配信向きです。
• 直リンク方式は、Webサーバーがインストールできれば、その中で容易に構築できますが、エンコード済みURLを管理する必要があり、リンク切れ対策が不可欠です。

この章では、特に「リンク切れを防ぐ仕組み作り」について具体的に説明していきます。

1. Dropboxへの依存リスク〜【脱Dropbox】は可能か〜

トークンリンク方式には大きな利点があります。
ファイルパスやファイル名を変更しても、共有リンクURL（トークンリンク）は基本的に変更されません。
これにより、配信側にとって運用が非常に安定します。

しかし、ストリーミング再生に対応したトークンリンク方式を許可しているクラウドサービスは非常に少なく、現状ではDropboxがほぼ唯一の選択肢となっています。
このため、Dropboxに頼ってしまう、配信インフラをDropboxのみに依存するリスクが懸念されます。
では、Dropboxの代替となるクラウドは存在するのでしょうか？ 次に、主要なクラウドストレージの状況をまとめてみます。

	トークンリンク方式のクラウド	ファイルパスから共有リンク取得	共有リンクからストリーミング表示可能か	コメント
	Dropbox	可能 ✅(API使用)	可能 ✅（raw=1 などで直再生可）	Mac Finderパスとクラウドパスが一致、取得容易。dl=0をraw=1に変換でストリーミング。
	Google Drive	工夫すれば可能 △	部分的に可能 △（制限あり）	API検索でファイルID取得可能。基本はビューアーページ誘導。ファイル種別・設定次第で挙動が変わる。
	OneDrive	工夫すれば可能 △	部分的に可能 △（制限あり）	API経由でパス整形可能。ストリーミング可否はファイル形式やブラウザに依存。
	iCloud Drive	ほぼ不可能 ❌	ほぼ不可能 ❌	API経由での共有リンク取得不可。共有リンクもストリーミングに適さない。

このように、複数のクラウドをトークンリンク方式で使い分けることは現実的ではなく、トークンリンク方式についてはDropboxに一本化するのが最も合理的な選択だと言えます。繰り返し言います。それゆえに、Dropboxに依存したくなるのですが、サービスが永続する保証など無く、そこにリスクがあるわけです。

2. 直リンク方式による配信とリンク切れ対策

一方、直リンク方式ならば、Dropboxに依存せずに複数の配信所を設けることが可能です。
具体的な候補は以下のようなものがあります。

• pCloud(パブリックフォルダ利用)
• WordPressサーバー(Xserverなど)
• 自宅Webサーバー
• レンタルWebサーバー（独自ドメイン）

※pCloudは今では特異な存在で、トークンリンク方式と直リンク方式の両方を提供しています。昔のDropboxに似ています。pCloudは使い勝手のいい仕組みを持っているのですが、サーバーが欧州と北米にしかないので、遅延が生じ易いです。日本にサーバーがあればかなり有用だと思います。

これらはいずれも、ドメイン名直下またはサブディレクトリにメディアフォルダをコピーするだけで、新たな配信拠点をすぐに追加できます。

ただし、ここで問題になるのが、ファイルパスやファイル名の変更に伴うリンク切れです。

これを防ぐために、次のような仕組みを用意します。

バックグラウンド処理(常時監視する)⬇️

ファイルパス、ファイル名の変更前と変更後を記録する。

• ファイルパス変更記録ファイルを保持する
  （Macで変更前ファイルパスと変更後ファイルパスを記録して、Spreadsheetを更新する）
• ライブラリ登録の時、これを照合して、配信用URL（例：https://imakat.com/rd.php?id=Abcd0123.png）に紐づくパスやファイル名を最新のものに置き換えたJSONファイルを生成する。

こうすることで、仮にファイル構成やファイル名が変わっても、配信URL自体は変更せずに運用を継続できるようになります。

３. メディアライブラリ更新のアルゴリズム

メディアライブラリの更新の判断は以下のようになっています。まず最初にファイルパスが変更されたかどうかが基軸になります。ファイルパスが同じで、Dropboxリンクが変更されている場合は、メディアライブラリに登録するDropboxリンクも変更されます。Dropboxリンクが同じでファイルパスが変更されている場合は、メディアライブラリに登録するファイルパスも変更されます。この仕組みにより、ファイルパスやフォルダ名が変更されても、配信用URLは不変で運用ができるようになっています。

４. まとめ

• トークンリンク方式は運用が安定していますが、Dropboxへの依存が避けられず、サービス継続性にリスクがあります。
• 直リンク方式は柔軟性が高く、複数の配信拠点を設けることが可能ですが、リンク切れ対策が不可欠です。
• リンク切れを防ぐ仕組みとして、ファイルの変更監視と配信用URLの動的更新が効果的です。

第５章〜終わりに、では、「動画パッケージの作り方」についてご紹介します。

➡ 第５章を読む

🔗 目次ページへ戻る

本章では、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つのサーバーに不具合が起きても、他のサーバーで代替再生が可能になります。

次回予告：

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

➡ 第４章を読む

🔗 目次ページへ戻る

マス・メディアや民間企業は、当初は、動画を、大手のメディアサーバー或いは自社サーバーから配信するのが主流でしたが、2006年にGoogleが、ミニコミ生まれのYouTubeを買収して以降は、いつの間にか、民間企業・官公庁問わず、そのホームページにはYouTubeの動画が貼り込まれて当たり前、となりました。

YouTubeは使いにくい。ブログを作ろうとする時、文章は自分で自由に創作できる、写真やデザインも自分のオリジナリティで創作、手直しができる、なのになぜ、動画のYouTubeは、広告が入ってくる、微細な手直しだけ出来て差し替えが出来ない、「再生数いいね」などブログとして無意味なのに入ってくる、などなど作者の自由にならないのか。おそらくそれは、まだ動画を配信するには多額な設備投資、特許などの使用料、運営費がかかる、そこへの応分の負担が伴う、という説明になるでしょう。

手作りメディア側にいる一人として言わせてもらうなら、それは、より高品質の動画配信を追求するから、それだけ投資資金が必要になるわけです。それを利用者全体に負担してもらおうと考えるから、小市民側の不自由が解消されないのでは、そのように感じます。

さて、それでは、
昔、個人商店にあったような、穏やかな自由さを、手繰り寄せて行きたいと思います。

ポイント解説

<1> Web配信のプラットフォームを使い分ける。

私は、WordPressの発信は、安定度を重視して外部業者のXserverから行っています。ただし、Xserverはディスクを増量した時の料金のアップが大きいため動画の収納には躊躇します。

比較自体が、乱暴かも知れませんが、

ということになるわけでして。

こうしたこともあって、自宅のSynologyNASへ、別にもう一つ、Webサーバーを立てて、そこから動画や画像を、XserverのWordPressへ、送り出すようにしています。しかしながら、自宅サーバーは非力です。動画や音楽を美しく配信/再生するのは無理です。

YouTubeやVimeoはオートトランスコードが備わっているので、ユーザーのインターネット環境が悪ければ低画質に落として情報量を少なくして送り出すことが出来ます。しかし私のような弱小自宅サーバーは、そこまでの資力能力がありません。

ですから、考え方としては、ふだんブログを作って発信するときは、動画は「個人商店」から発信、（商店と言っても無料ですが）、中に時々、一般向けと思われるものを、Vimeoで発信、という棲み分けです。

<2>ネックは、視聴側の4G回線の速度が、不安定なこと。発信側はまずまずの速度。

ZOOT NEXTを使って自宅サーバー及びガラポンTV、DIGAから外部へ発信していますが、その速度は60〜80Mbps程度です。遅いですね。サーバーとしては。これが自宅サーバーへアクセスする方に対するパイプの太さになります。

話は逸れますが、ガラポンTVはお見事です。頑張っています。ガラポンTVは、ファイルサイズが、1時間約150MB=0.04Mb/sと非常に小さいにも関わらず、iPadやスマホなら支障なく見られるわけです。この発想がナイスです。さすがにそこまで小さいと、MacやPCで再生すると見辛さを感じますが。

。。どのあたりで、適当に満足できるでしょうか。

半ば諦め気味の方も多いと思うことですが、スマホなどの4G回線で再生すると、なかなか動画か開始しないということが起きやすいです。例えば、OCNモバイルなどの格安MVNOの場合は、昼12時頃はアクセスが集中するせいか、動画の再生は止まりやすいです。

<3> 昼12時の4Gは最悪です。

ZOOT NEXTの配信速度　　ダウンロード46Mbps 　アップロード83Mbps
4G回線のダウンロード速度 ダウンロード780Kbps アップロード　3.4Mbps
480×270の視聴可否 　不可
ガラポンTVの視聴可否　　不可

4G回線で昼12時に観ることが出来る動画は、YouTubeなど一部だけです。多くは止まってしまい観ることが出来ず、ガラポンTVすら観れない状況になります。

OCNモバイルだけなのか分かりませんが、昼休みは、YouTubeなど特定の動画サービスを観たい人が集中するため、そちらへの配分を優先させて、午後１時以降は元に戻す、そんな扱いになっているような気がします。

<4> 動画のフレームサイズ480×270だと、いくつ同時配信ができそうか。

この際、昼12時の4Gの視聴は無理と、目を瞑ることにします。

480×270は、QuickTime480x270AAC 760.72MB/1h = 0.21Mb/s、となります。

ZOOT NEXTのアップロード配信速度の落ちた時を60Mbpsとして、その半分を、自宅サーバーが使うとすると、

30Mbps ÷ 0.21 = 143 個

となります。

Macのフォルダアクションにデフォルトで装備されている、動画のエンコーダーは、最小サイズで640×480となっています。そのため480x270AACを別の方法で作るのですが、私は、Apple純正のCompressorというアプリを使っています。

<5> SynologyNASのメモリーを増設しました。

SynologyNAS DS218+の購入時のメモリーは2GBでした。公式では6GBまで増設が可能となっていますが、tabi.comさんのブログを参考にして、8GB増設して合計10GBにしました。

<6>同時アクセス制限数を引き上げました。

SyNologyNASのメモリー増設は、日常的なNASの活用の安定化に寄与することは確かだと思いますし、自宅サーバーへのアクセス制限数も増加することが出来るようになります。

Web StationのPHP設定->詳細設定、に入ります。

まず最初に、FPMモードが静的モードの場合は、同時アクセス制限数＝FPM最大プロセス数、と読み替えられるようです。わかりやすい方がいいです。静的モードを選択します。

デフォルトでは、動的モード、FPM最大プロセス数20、です。

8GB増設したので、1プロセス100MB消費すると見積もり、80プロセスを追加して合計100個。

上の<4>は143個ですので、低い方をとって100個。

といっても現実問題として、そんなにアクセスがあるはずがなく、半分の50個にしました。

<7> セキュリティアドバイザーをチェックする。

SynologyNASのアプリのセキュリティアドバイザーをチェックするようにしています。毎日朝2:00にスキャンを実行しています。その結果、何らかの警告があれば、指示に従って、対応しています。

<8> 5Gになっても、画質を落とせるものは落として使うべし。

但し、近い将来、5Gが普及すれば、圧倒的にデータ送信スピードが上がりますので、昼12時でもスマホでスムーズになると期待します。しかし、冒頭の図に戻って、基本的な考え方として、美しく鑑賞する必要のない画像は、画質を落として視聴するのが賢明だと考えます。

TV番組も、同じで、美しく観賞したい番組は4Kを望むにせよ、解ればいいのであればワンセグで十分、ガラポンTVで十分、という使い分けが望まれます。

24.4.10追加：Dropboxに置いた動画を利用する場合は、圧縮なしでリンクしても何とか再生可能です。

以上。