最近、Black Fridayなどで目にすることが増えたpCloud。スイスにあるクラウドストレージを提供する会社で、「買い切りプランも選べる、プライバシー重視のオンライン倉庫」です。ここで紹介しますが、何も営業的な意図はありません。

～Dropboxが廃止したパブリックフォルダを、pCloudでは使える～

昔からのDropboxユーザーなら記憶にあることですが、以前はパブリックフォルダがあり、ここからWeb配信が可能でした。Dropboxは企業やビジネス用途が多くて漏洩厳禁なところ、フォルダを間違えて公開するようなうっかりミスが多発することも問題だったようです。Dropboxのパブリックフォルダは「便利すぎて危険」「無料すぎて悪用される」「事業の軸と合わない」として廃止したわけです。pCloudは、パブリックフォルダは、もともと公開利用を前提に設計されていて、それを売りにしていることもあるので、一応大丈夫だとは思います。ただ、いずれにしても、クラウドストレージをメディア配信用に使うときには、２つの心得があります。それは、一つは、配信サーバーが提供する共有リンクをそのまま公開しないこと、もう一つは、一ヶ所の配信サーバーに依存しないことです。
それでは、解説ビデオをご覧ください。

ポイント解説

１　スクリプト

新規追加または変更があると、wpidexをキー項目とした、Dropboxリンク、直リンク、ファイルパスを中心に成り立つF1_メディアライブラリファイルのsheet1(シート)が最初に更新され、次に以下のpcloudid(シート)が更新されます。

このスクリプトは、Googleスプレッドシートの「pcloudid」と「sheet1」を基に、pCloud上のファイル情報を自動更新し、filedn形式の直接URLを生成・管理するGASです。sheet1(シート)に新規追加された未登録のwpidexをpcloudid(シート)へ自動追加し、needs_updateがTRUEの行のみを対象に、filepathやfileidからpCloud APIを用いてメタ情報とパスを解決します。生成したdirect_urlや更新日時を反映し、最終的に全データをlast_update順に整列したうえで、pcloud_library.jsonをGoogle Drive上の固定IDファイルへ上書き出力します。

コード(スクリプト)をもっと知りたい方はこちらへ↓

２　fileidの取得とダイレクトリンクの生成

３　＜豆知識＞　ファイル名を変更することにより、キャッシュ更新を早める

※：CDN方式
ファイルパスやファイル名の変更は、一般には、好まれませんが、ファイル名の変更はファイルの更新履歴を新しくするので、新たなファイルとして読み込みが起きます。これは、更新処理のスクリプトが安定していることが必須です。

以上

下に、動画を４箇所(米国２　大阪　欧州)から配信しています。遅延など、再生の質の違いが確認できます（このページがあると自分にとっても便利)。WiFiではあまり差はないかも知れませんが、スマホの4G回線などでは、低画質動画の有用性を感じられると思います。4G回線などでは制限超えや通信料金に注意ください。

Dropbox(配信所：米国)

Dropboxの良い点は、トークンリンク式URLを使ってWeb公開ができる点です。Dropboxはあらゆる業種で利用されているデータストレージで、マルチメディアの制作に関わるメディアアセットももちろんOKで、素材から加工品へ、さらに完成品と安全に保存ができます。それを一つの製造会社と見立てるなら、Dropboxはその完成品の直販、産直ができるという利点があります。Google,Microsoft,Appleなどのクラウドストレージを提供する大手がありますが、彼らは、直販は嫌っていて、メディア配信会社(YouTube,TikTok,Vimeoほか）へ移し、そこから配信、Web公開という形態になります。

自宅サーバー(配信所：浜松)

動画はまだ準備中です。

下記にあるvimeoの活用も加わっており、いよいよ自宅サーバーからのメディア配信は、予備としても、そこまで準備しておく必要はない段階になりました。停止を検討しています。
自宅サーバーの良い点は、手元でいつでも自由自在にメディアの加工ができること、低コストであること、ファイルパスを使った直リンクを使えること、などがあります。欠点は、家庭用の回線(光1G)から配信するので非力で、高画質(大容量)の動画再生は苦手であること、災害に弱いこと、なんでも自分でやらなければならないこと、などがあります。ただ、低画質の動画を選択出来るようにしたので一定の使用価値はあるでしょう。私は、余ったSynologyNASを活用して自宅サーバーを構築していますが、発熱の少ないパソコンなら利用可能です。
災害に弱い欠点はありますが（これを言ったら家にある全ての機器がそうですが)、災害がなければ低コストの扱いやすい道具です。蛇足ですが、SynologyNASには監視カメラ機能がついていますので、これを応用してライブ配信も可能です。

Xserver(配信所：大阪)

Xserverの良い点は、というかWordPressのホスティングサーバーとしてXserverを使っていますので、この、ホスティングサーバーへアップロードして使う方法は、まさに教科書通りの使い方です。
配信用メディアの完成品はDropboxにありますので、これを自動的にXserverへ更新する仕組みにしてあります。良い点は、WordPressの指示通りに動き、安全に安定しているということに尽きます。欠点は、ストレージの利用単価が高い、ということです。単純比較すると、Dropboxは2TBで月約1000円、Xserverは0.5TBで月約1000円ですから４倍になります。しかし果たしている機能が違いますし、Xserver は無料の増量サービスもあるので、単純に損得比較はできません。

pCloud(配信所：欧州(ルクセンブルグ))

pCloudの良い点は、ファイルパスを使った直リンクが使えること、買い切りプランがあること、この２つがあります。私は、0.5TBで約２万円の買い切りにしました。今後、一切費用負担はないとのこと。ファイルパスを使った直リンクは、以前はDropboxは利用できましたが廃止されたため、クラウドストレージを提供する会社では、貴重な存在と言えます。pCloudの保存先には、米国と欧州がありますが、両者を比較すると、日本からの視聴は欧州の方がやや速い、アジアからの視聴は欧州の方が速い、アメリカからの視聴はやや遅い、欧州からの視聴は速い、プライバシー保護は欧州が優れている、といった評価になり、総合的な判断として、欧州を選択しました。

Vimeo(配信所：米国およびCDN)

動画はまだ準備中です。

Vimeoの良い点は、オートトランスコードであること、いいね、再生数、広告などを除くことができる、差し替えができる、などです。Vimeoのコンパネからの投稿には一手間の面倒さがありますが、私は最近、ローカルからVimeoへの直アップロードの仕組みを作ったので、Vimeoのコンパネを触ることなく、差し替えができるようになりました。但し、VimeoPLusは最安ランクなので、新規の投稿の時に、細部の設定はコンパネから行う必要があります。25年11月頃から、保存量が2TBに引き上がりました。使いやすくなっています。仕方ないことですが、字幕一覧から、シーンへ飛ぶことはできません。

以上です。

24年3月「動的サイトを作ってみた」、同12月「動画ショートコード」を作成し、動画配信のためのデータ作成方法を解説してきました。

その後、少し手直しを行ったため、改めて「動画パッケージの作り方」の解説をします。

なお「動画パッケージ」は、自作のメディアライブラリの中の一つのメニューです。

1　スクリプトの変更点

ファイルパス入力を不要に：

当初は、各URLファイルを入力した後、そのファイルパスを別途手で入力していました。これは手間なので、事前にメディアライブラリの中にメディアアセットとして登録済みの場合は、再生URLを登録するだけで、spreadsheetに対して、存在するファイルパスが自動的に呼び出されるよう改良しました。

２　アプリ運用変更点　

個別指定による再生サーバーの優先：

第3章で説明したように、再生URLに対しては個別に指定された再生サーバーが優先されます。個別指定がなければ、拡張子別の選択番号が適用されます。

メディアアセットごとにこの再生選択番号が設定され、例えば、以下のようになります。

拡張子別サーバー選択：

現状、下のように、３：Xserver(WordPress)、４：pCloud、を選択しています。

所在場所に「dynamic」を追加：

次に、動画パッケージの設定に入ります。以前にも説明した通り、動画はいくつかのメディアアセットを集めて作ります。このライブラリでは、初期画像ファイルURL、高画質動画ファイルURL、低画質動画ファイルURL、字幕ファイルURL、字幕一覧ファイルURL、説明ファイルURLの6種類です。基本的には、これらの再生URLを登録します。

動画パッケージの設定では、各URLを登録すると同時に再生サーバーも自動決定されます。例えば、初期画像はpCloudから表示、動画はDropboxから表示、字幕はXserverから表示、字幕一覧はpCloudから表示、説明はXserverから表示といったように、自由に設定が出来ます。動的に自由に場所が変更可能なので、呼び名をdynamicとしました。
ただし、字幕vttファイルについては、WordPressサーバーの中に置くようにします(そうしないと、Windowsの場合は字幕が表示されません)。

なお、再生URLを入力せずに、サーバー別のURLを直接入力することもできます。その場合は、個別選択、拡張子別選択の影響は受けずに、再生されます。

基礎情報として、いくつかに分類してありますが、この意図は、埋め込みコードの形式の違いをはっきりさせるためです。dynamic、wordpressサーバー、は、いずれもWordPressサーバーのHTML5動画プレーヤーを使用しますので、どれを選んでも同じ結果になります。Vimeo、YouTubeはそれぞれの動画プレーヤーを使うのでhtmlスクリプトも異なります。

３　ショートコードの生成

WordPressの投稿には、

• カスタムHTMLブロックに埋め込む方法
• ショートコードブロックに記載する方法
  

の二つがあり、表示される内容は同じです。

phpスクリプト

動画ショートコードの生成(WordPressサーバー内)

指定された videoid に基づいて videoembed.json を取得し、対応するレコードの embedCode を実行して動画を埋め込む。videoid が指定されていない、JSONが取得できない、または該当レコードが見つからない場合は「動画はまだ準備中です。」と表示する。

４　動画を使う目的に応じて選択する

動画のグルーピングは、広く公開したいときは、Vimeo、YouTubeを選択する、ブログの記事用については、ブログは文章や画像で説明を済ませたいところですが、実際の作業や動きを見せて補強した方がいい時は多々あります。その時はdynamicを使う、といった使い分けになります。大事なのは、視聴者の立場で考えること。例えば、ブログ記事の補強で動画を使う場合、大抵は、数分〜10分程度におさまると思いますが、内容が数分程度のものを見てもらうのに、その前に広告を長々と見てもらうというのは、それはむごいこと、ある意味失礼なことだと、私は、感じます。だから、そうした動画はdynamic、長くなった場合はVimeoを選びます。
YouTubeは、やむを得ない場合使う、という順位に考えています。

5　マイライブラリを２ページ並べる

動画パッケージを作成する手順は、最初に、メディアアセットをマイライブラリに登録することから始めます。次に、その登録されたアセットの再生URL(rd.phpの文字列のある)を、動画パッケージに登録します。この作業は、画面を２分割して、左側に「メディアアセット情報」、右側に「動画パッケージ」を配置すると便利です。それをクリックで表示するAppleScriptを紹介します。

SafariでAppSheetの2つのURLを左右に並べて表示するAppleScript。メインディスプレイのサイズを取得し、画面を左右に分割して各URLをそれぞれの位置に開く。Safariを起動後、左側に1つ目のURLを新規ウインドウで開き、続いて右側に2つ目のURLを開く。もし新規ウインドウが作成されずタブ化された場合は、システムイベント経由で新規ウインドウを強制的に生成し、右側に配置する。

終わりに

ここまで、メディアライブラリの作成から活用までの流れを説明してきました。

基本の考え方は「ひとつの場所に依存しない」です。脱YouTube、脱Dropboxです。

どうしても、人は、「この指とまれ」「このボール、あなたなら奪えるよ」と誘われると、群がる習性があります。そこを狙ったが如く、突然、天災、人災は起こり、その集まりを破壊します。あるいは、物事は、新しく生み出されてしばらくすると、それが普及して大衆化します。大衆化した次は飽和して衰退します。万物同じ原理で動いています。YouTubeは今は儲かっているでしょうが類似のサービスは間違いなく拡大します。YouTubeが未来ずっと存在することは難しいでしょう。

➡ 第１章へ戻る

🔗 目次ページへ戻る

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

次回予告：

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

➡ 第４章を読む

🔗 目次ページへ戻る

動画はまだ準備中です。

ポイント解説：

作成するスクリプトは、結構、分量があります。ChatGPTを使い、ゆっくり進めるのがいいです。以下のスクリプトをChatGPTへコピペして、（１）「このスクリプトの解説をしてください」と、まず解説をしてもらう（２）その解説の中で、自分向けに修正する箇所を指摘して、スクリプトの記述を指示する、そのようなやり方が効率的です。表の右欄に、スクリプトをリンクします。

パイプライン処理(画面入力をトリガーに、一品料理で一連の処理を行う)
⬇️＜マイライブラリ画面入力＞ Finderで選択したファイルを処理し、対応するDropbox共有リンクを自動取得して送信スクリプトに渡すAppleScript。ファイルのパスや拡張子を取得し、日本語などを除去してDropbox形式のファイル名に整形。Python仮想環境のget_dropbox_link.pyでリンクを生成し、ファイル名の整合性を確認後、send_request.pyでリンク情報を送信。
⬇️＜マイライブラリDropboxAPI認証リンク取得GAS通信＞ DropboxのOAuth認証設定、リンク自動取得、GASとの通信を行う3本のPythonスクリプト群。 ①dropbox_auth_setup.pyはローカルHTTPサーバで認証コードを受け取り、Dropboxのアクセストークンとリフレッシュトークンを取得する。 ②get_dropbox_link.pyはリフレッシュトークンを用いてDropbox APIに接続し、指定ローカルファイルの共有リンクを取得または生成し、dl=0をraw=1に変換して出力する。 ③send_request.pyはAppleScriptから受け取ったDropboxリンクやファイル情報をGASのエンドポイントへJSON形式で送信し、更新処理を実行する。
⬇️＜マイライブラリ生成更新処理＞ mediaLibrary.gsは、Dropbox等のメディアファイル情報をF1シートで一元管理し、その変更を自動反映するGASです。ファイル名・パスから一意なwpidexを生成し、sb付き一時ファイル名や?v=付きURL、NFC差、連続スラッシュなどを正規化して突合します。doPostはmodeにより、ライブラリのフル再構築やvideoembed.jsonのみ更新、通常の作業行追加＋処理を切り替えます。processWorkingRecordはF3のパス変更履歴を反映しつつ、K=ADD行をADD2に更新し、JSON生成とライブラリ整理、pcloudidシートへの同期を行います。cleanMediaLibraryはDEL行や重複を除去し、更新日時で並べ替え、フラグをFALSEに戻します。videoembed関連は「動画パッケージ」シートから埋め込みHTMLを集約し、XserverのPHPにJSONをPOST送信します。
⬇️＜メディアおよびJSONをXserverへ更新＞ Dropbox → Xserver 同期用のメインスクリプトは、pmedia・mmedia・meta_gd_wp_data を Homebrew 版 rsync で転送し、SSH鍵を自動ロードして毎分同期するよう LaunchAgent から実行される。ログは /tmp と $HOME/scripts/logs に記録される。 しかし rsync が残留してフリーズすることがあるため、毎日 3:30 に自動復旧スクリプトが動作し、pmedia/mmedia 関連の rsync プロセスを検出して kill し、メインの LaunchAgent（com.xxxxxxxxm1.sync_dropbox_xserver_m1）を unload/load し直して正常状態へ戻す仕組みとなっている。
⬇️＜配信サーバー切り替えリダイレクト処理＞ rd.phpは、指定されたidに対応するメディア情報をJSONから取得し、該当URLへ転送または中継出力するPHPスクリプト。txt・vtt・srtなど文字ファイルの場合は、文字化け防止のためサーバー側でUTF-8へ変換して直接配信する。Dropbox・Xserver・pCloudなど複数サーバーのURLを動的に切り替え、キャッシュ防止や診断表示（?diag=1）にも対応する。

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

＜ファイルパス変更処理＞ mmedia・pmedia フォルダを常時監視し、ファイルやフォルダの移動・リネーム（MOVED）を検出して記録する Python スクリプト。検出時には変更前・変更後パス、JST の更新時刻、更新フラグ TRUE を Google スプレッドシート（sheet1）へ追記し、その後シート全体を読み込んで (A,B) が同じ重複記録は「最も古いものだけ残す」形に正規化し、更新日時の降順で再整列して書き戻す。scripts_pub や .dropbox など特定パスは無視するフィルタを搭載。watchdog によりディレクトリを監視し続け、ログは ~/Library/Logs に記録。LaunchAgent（com.xxxxxxxx.filewatcher.plist）を用いて macOS 起動時に自動実行される構成となっている。

上の処理はMacを使った処理ですが、ChatGPTの分析では、Windowsへの移植には、以下が変更点になります。Mac、Windowsで共通して使えるGAS、AppSheetを中心に据える作り方がベターと言えます。

次回予告：

第3章では、「YouTube（大手）に依存しないで配信する」についてご紹介します。

➡ 第3章を読む

🔗 目次ページへ戻る

動画はまだ準備中です。

はじめに：

いまの時代、動画はたくさん出回っています。
でも、その動画を作るために使った素材――たとえば写真や音声、字幕や説明文など――は、紐づいて保存されているでしょうか。

最近の動画編集ツールは、ブラウザから手軽に使えるものが多くなっています。
素材をいくつかアップして、簡単な操作で動画が完成する。便利で楽しい仕組みになっています。
そして完成した動画は、そのままYouTube、TikTokなどの配信サイトにアップされ、世界中に届けられます。

プロセスは、隠された箱の中

時代は生成AIですね。

でも、その一方で、完成した動画は、「どうやって作られたのか」、「どんな素材で作られたか」は、作成者は全く分からない、原型を留めないほどに、変形させられるものも多々あります。こうなった時、それが私の作品、所有者は私、と言われても、すっと腑に落ちません。

出発点は「整理整頓」：

さて、これからの時代、動画などのメディアコンテンツの作り方は、どんな考え方に傾いていくでしょうか。

適当なものを放り込んで、ボタンを押したらヒョッコリ出来ただけ

ひとつは、「完成した動画があれば、素材がなにだったか、原型がどうだったかは、気にしない。レシピはアプリ会社が用意したものから選ぶだけでいい。」という考え方。早い安い美味い、インスタント即決重視。

もうひとつは、「動画の元になった素材や、その作り方の記録も残っていて、所有権は私のものであり再加工も私はできる」という考え方。音楽制作や文芸で著作権の大切さを感じた人にある感覚でしょうか。

前者は、何が原因でどういう条件でこの結果となったかが分からないので、何を大事に残したらいいかが分からない。素材軽視、意外性重視、偶然好み、結果だけあればいい。完成物だけ持って飛び出していく人。やりっぱなしで、でも元ネタはここにあるはず、となると捨てられず、家はゴミ屋敷。

いいえ全員そうだとは言いませんが、概してそう。

小さい頃から言われ続けてきた整理整頓は、やはり重要です。

完成した動画だけでなく、それを作るまでに使った素材や字幕、説明なども、あとから見返せるようにしたい。
再利用や別の作品への展開にも役立ちます。

「フォルダ整理」の次に「ライブラリ」生成へ：

このシリーズでは、**「メディアライブラリ」**を、メディアコンテンツを作成保存するDropbox（私の場合)を出発点にして、身近な道具を活用しながら、どう作っていくか、これまで数回に渡り掲載してきたライブラリ生成のまとめとして、ご紹介していきます。

メディアライブラリとは、図書館がサービスとして本を貸し出してくれるように、そのメディアコンテンツを配信してくれるところです。しかし図書館といえど世の中のすべての書物を扱えるわけではありません。日本の図書館には、ほとんどが日本語の書物です。同じように、ここでいうメディアライブラリは、「自分が所有している配信可能なコンテンツのうち、配信する予定のあるものを、配信できる状態にスタンバイさせたもの」となります。

ここから先は、メディアコンテンツを流通させる手法を取り扱っていくので、メディアの中身そのものというより、メディアの属性やメタ情報に焦点を当てていきます。そしてメディアの総体をメディアアセットと呼んでいくことにします。

(※アセットとは、一般的には「資産」の意味です。「情報」に対して「情報資産」と呼ぶと、まあ意味は何となく分かりますが、しかしこの「情報資産」は、質量を持たず、瞬時に無限に複製移動出来る不思議な存在です。)

ですから、包含関係で言うと、「自分の所有するメディアアセット⊇配信可能なアセット⊇配信する予定のあるアセット⊇配信できる状態にスタンバイしたアセット」となります。

具体的に私の例で言うと、

(A)自分の所有するメディアアセット(様々なデバイス):
iPhoneやiPadに保存した画像やイラスト、動画、音声など、FinalCutPro、Cubase、図形描画、ドキュメントなどで加工中あるいは完成したものなど。

(B)配信可能なアセット(私の場合はDropbox):
(A)の内で、他者にわたることを前提とした、合法なコンテンツ

(C)配信する予定のあるアセット(私の場合は、Dropbox、Xserver、自宅サーバー、pCloud、Vimeo、YouTube):
(B)の内で、配信にマッチするように調整を済ませたコンテンツ

(D)配信できる状態にスタンバイしたアセット(私の場合は、Dropbox、Xserver、自宅サーバー、pCloud、Vimeo、YouTube):
(C)の内で、共有URLを持って、ランチャー（発射台）にセットされたアセット

※(C)と(D)の違いは、ステータス（公開、非公開）の違い。

以上のようになります。
このうち、(B)について、Dropboxの中にフォルダ(mmedia pmedia)を設定しています。このフォルダの整理以降が、今シリーズの対象になります。

メディアライブラリは商社の本社機能のようなもの：

図書館とメディアライブラリの違いを考えてみます。
一言でいって、サービス部門の設置場所が、違ってきます。図書館は書籍を受け渡しするためサービス部門は各図書館内に必要です。書籍は質量がありますから。
それに対して、メディアライブラリは、動画、画像、テキストといった、質量がなく即座に複製移動できる、情報アセットを受け渡しするサービス部門です。従って、メディアライブラリは、アセットが複数の場所に存在していても、「何がどこにあるか」というメタ情報(台帳のようなもの)があればいいだけです。それは一ヶ所あれば十分です。

メディアライブラリはGoogleドライブを使っています。Googleドライブには、動画、画像、テキストといったアセット自体は置きません。置くのは、そのアセットの特性や特徴を記録したアセット情報(台帳)だけです。メタデータだけです。
またGoogleドライブには、GASやAppSheetなどの指示命令機能がそなわっています。いわば、商社の本社機能と言っていいです。

このシリーズで目指すもの：

このシリーズでは、DropboxやWordPressサーバーなど、すでに持っている道具、標準装備されているものをうまく使って、

誰でもできる「メディアライブラリのかたち」を提案していきます。

こんな方におすすめ：

この連載は、私自身が実際にメディアライブラリを作ってきた経験をもとに、
できるだけわかりやすく紹介していくことを目指しています。

パソコンは Mac を使用しており、
そのために AppleScript や Automator など、Mac特有の言語やアプリを使う場面も出てきます。

でも、どれも難しいプログラミングではなく、
「ちょっとした工夫で整理がしやすくなる」という発想に近い内容です。

• 動画配信やメディア配信を、YouTubeに類するような大手配信サービスに依存したくない方、ひと所に依存したくない方
• 動画や画像を頻繁に手直ししたい方
• 共有URLの提供を、自分として一本化したい方
• メディアコンテンツの作成からメディアアセットの管理を、一貫して行いたい方
• そうしたメディアアセット管理システム(MAM)を、あまりお金を掛けないで、ハンドメイドで小規模に実現したい方

そんな方にとって、きっとヒントになるシリーズになると思います。

次回からは、実際の構造や工夫について、図や例をまじえながらお伝えしていきます。

準備するもの：

Mac、Dropbox、Googleドライブ、AppSheet、AppleScript、Python、GAS、ShellScript
です。DropboxおよびGoogleドライブは最下位の有料版で十分。

次回予告：

第2章では、「メディアライブラリへの登録〜パイプライン処理〜」についてご紹介します。

➡ 第2章を読む

🔗 目次ページへ戻る

自宅webサーバーの作り方については、以前の投稿でも説明しました。その中でも触れたように、自宅サーバーは、かつてブームになったものの衰退した歴史があるわけで、その衰退の理由に、主に、コストメリットが低いこと、災害に弱いことが挙げられます。しかし、そうしたデメリットを取り除いてみれば、DIYで産直配信を行うことの楽しさは相変わらずあるわけです。

よくメリット、デメリットを比較してデメリットが大きいので、やめてしまうことがあります。費用対効果、効果より費用が大きいのでやめてしまうことがあります。しかし、今後費用は下がる、今後デメリットは減ることが見通せるならどうでしょう。あるいは費用には労働力も入るわけですが、自分が頭や手足を使うことで出費が減らせる、あるいは、そうした作業が趣味や楽しみに転換できるなら、一挙両得という話になります。

2020年頃からそこへ、AppleシリコンMacMiniという、低電力高性能、常時稼働向きの、周辺機器なしの見た目サーバーのコンピュータが登場しました。しかも非常に小さくなってきました。コンビを組むNASも大容量のSSDが挿せるようになりどんどん小型化してきています。注目する技術→📄

明るい光を感じますね。

クラウドにするだけでなくポータブルにする

それで将来イメージを見通すと。。キャンピングカー、移動販売車のようになるだろうと。

MacMiniがもっと小さくなる。NASがもっと小さくなる。一緒に持ち運べるようになる。

そう。NASとMacMiniへwebサーバーとファイル管理を積み込むのは、今はまだ自宅に固定された大袈裟なサーバーです。だからクラウドストレージの方が優れていると直ぐに思ってしまいます。しかし、バッテリー駆動のポケットサイズ、ポータブルにできれば、災害にも強いです。問題は解決します。技術的にそれほど難しくはないでしょう。

ですから、自宅サーバーの構造思想は廃れるものではない、そう思えてくるのです。

さて、そんな枠組みの中で、今回の小さなテーマは、「短縮URL」作りです。

再生用URL 4種類

(A)

Dropboxリンク型　

(B)

自宅サーバーパス記述型  日本語を直接解読できないのでエラーになる。

(C)

日本語エンコード型　

(D)

「画像ライブラリー作成」を行なって、外部サーバー短縮型URLを作る

(E)

マッピング更新を行って、自宅サーバー短縮型URLを作る。

以上4種類がありますが、(B)は表示が不可能になりやすいので除くと3種類になります。

この中で、WordPress投稿内で使用するのに適しているのは、どれか。

それは、(D)です。

この3種類の中で、動的URLは(D)だけです。カートリッジ型です。

それで(D)を採用しました。

なお、配信サーバーの切り替えについては、別の投稿で説明します。

ランダム文字列の扱い

ところで、この8桁のランダム文字列ですが、1234e678などの数字とeで構成されていると、数字と解釈されてしまいます。openssl rand -hex4と記述すると、1234e678のような科学表記になる可能性があります。cat /dev/urandom | tr -dc ‘a-zA-Z0-9’ | fold -w 8 | head -n 1を使って、英数字混合にすることで純粋な文字列として扱うことにしました。

以上です。

動画画像ライブラリー第３弾です。

Dropboxリンクは目立たないようにしたい。

これまで画像のURLリンクもDropboxを使えばいいと考えていて、Finderで右クリックして「Dropboxリンクをコピー」で得られたリンクを、そのリンクの末尾のdl=0をraw=1に置き換えて使えば、それだけでいい。そのように思ってきました。

Dropboxリンクの例は、下のようになります。

(A)

このDropboxリンクが安全性に優れている点は、クリックしてから実際に再生する時は更にワンタイムトークンリンクに変換されてからブラウザで再生されます。(B)のように形を変えます。ブラウザへURLをコピペするとこうなります。しかもこのURLは一定の時間が経過すると無効になります。

(B)

WordPressの画像ブロック→URLから挿入→(A)を挿入→HTMLとして編集を選ぶと、以下のコードが記述されています。

(C)

これで構わないとすれば、それまでのことですが、ブラウザからページのソースを読めば、上のコードは丸見えになります。Dropboxとすれば、(A)の情報が知れ渡るのは、あまり嬉しくないでしょう。「頭隠して尻隠さず」状態ということですからね。

そこで、以下のように、AppSheetで、動的な画像サイトを作ることにしました。

(D)

これを、画像ブロック→「URLから挿入」に入れます。こうすると、(A)の部分は、WordPressに表示されなくなります。(C)から分かるように、メディアはDropboxから読み込んでいるのですが、読者からは、どこから読み込まれているのか分かりません（そのようにしたいわけです)。

簡単に代替URLへ移行したい。

画像ライブラリ(D)を作るもう一つの目的が、 メディアのソースを、DropboxリンクからXserver、pCloudなど他のサーバーへ、簡単に、切り替えられるようにすることです。

なぜって？やはりDropboxにもトラブルは起こりうるからです。

こうした移行は、一般的には、プラグインを使って、WordPressのソースに書き込まれているURLを、直接に、置き換える方法が取られると思います。

しかし、ソースにDropboxリンクを使っている場合はそうはいきません。Dropboxリンクはファイル名やローカルパスが外から分からないようにランダム文字列に置き換えられていますので、ローカルパスだけをサクッと置き換えることは出来ないのです。

1点1点、Dropboxリンクと自宅サーバーURLを対応させた、マッピングファイルを作成する必要があります。丁寧にいうと、DropboxリンクとローカルパスとXserverサーバーURLの3つをマッピングさせたレコードを作成する、それをファイル上で右クリックしてあといくつかのクリック操作だけで済むようにしているところが、ポイント解説にて紹介するAppleScriptの特徴です。

そしてこのマッピングファイル(Google spreadsheet)をJSONファイルとして、WordPressに送り込むようにします。マッピングファイルの更新は1日一回夜中に行います。

link_mapping.csvの重複レコードの整理について📄

ここまで書いてきて、私が、動的サイトの使いやすさにこだわる理由が分かっていただけたでしょうか。

それでは次は、ポイント解説です。

ポイント解説

すみません。説明で使う素材を2024-11-28_15.50.35.pngに変更します。

1 画像ライブラリ作成AppleScript

画像ライブラリ作成 AppleScript📄

Dropboxリンクをコピーした後に、クイックアクションの中から「画像ライブラリー作成」を選びます。

ポイントは、必ず「Dropboxリンクのコピー」を行った後で、クイックアクションに入り、「画像ライブラリ作成」を選ぶことです。いきなりクイックアクションに入ると、その段階では、古いクリップボードが残ったままになっています。

そこで、一応、ポカよけとして、以下をメッセージ表示します。

ここはひとまずOKを押して終了します。

改めて、Dropboxリンクのコピーを実行した後で、クイックアクションの「画像ライブラリ作成」を選ぶと、

と表示されます。

ここでOKを押せば行追加が実行されます。

日本語のファイル名の時の注意喚起

ファイル名に日本が混じる時、Dropboxリンクは日本語は削除されます。リンクはランダム文字列で作られますので、日本語が削除されてもユニークなリンクにはなりますが、日本語だけで出来たファイル名ですと、リンクを見ても、どのファイルか、想像すら出来ません。特に、複数の日本語だけのファイルが続きますと、どこまで処理したか、分からなくなります。そこで、日本語だけのファイル名を扱う時は、必ず、Dropboxリンクの取得が済んでいるか注意喚起をします。

日本語のファイル名の時の注意喚起📷

ただ、出来れば日本語だけのファイル名は避けるのがいいです。

AppleScriptの中では、wp_photo_library.csvへ行を追加しています。更に、link_mapping.csvにも行を追加します。

2 追加したデータをWordPressで扱えるようにする

importAndBackupCSV GAS📄

createPhotoJson GAS📄

im.php JSONから画像を表示　php📄

画像ライブラリ用のデータは、クイックアクションでwp_photo_library.csvに追記されます。このデータを動画画像idのシート3に書き込みます。ファイルURLおよび画像idはユニークです。シート3へ書き込んだ後、wp_photo_library.csvにあったデータは、backup_wp_photo_library.csvへ追記した後、wp_photo_library.csvはクリアします。新たに作った画像サイトは、今作業中のブログにすぐに使いたいので、１分おきの更新にします。

少し待ちますが、新たに登録された場合は、AppSheetの動画画像ライブラリの画像メンテの先頭に、情報が表示されます。この中から、再生URLを取得して、WordPressの画像ブロック→URLから挿入するなど、利用します。

3 まとめ

このシリーズは、３回までで動画および画像を外部から読み込んで表示する方法、動的サイトの構築について説明してきました。次のシリーズでは、Dropboxリンクから複数のサーバーへ切り替える方法について、紹介します。

以上です。

しかしもっと簡単に考えて、まず、”38″の部分は自分で自由に設定できる動画idです。その動画idにどのサーバーにあるメディアをくっつけるかを決めます。ただし、VimeoやYouTubeの場合は、VimeoやYouTube側でidを発行するので、私がそれと別のidをさらに付けるのも管理を複雑にするだけなので、やめます。その結果、例えば、”38″はDropbox、”alt_38″は自宅サーバー、”885196700”はVimeo、”SRpWDu7gFC4″はYouTubeと動画idを決めることができます。重要なのは、動画idはユニークなキーであることです。

以下のようにショートコードブロックに、ショートコードを埋め込むようにして、””のvideoid(動画id)=の部分を書き換えれば、動画がサクッと置き換わるようになります。

以下が実際のショートコード貼り付けによる動画です。

[videoembed videoid="40"]

動画はまだ準備中です。

自分が作成した動画、YouTubeから探し出した動画などにidをつけて、動画ライブラリに登録しておけば、あとは利用が簡単です。

ポイント解説

それでは、この動画ショートコードの作成について、手順を説明します。下に全体図を掲載します。全部で４ステップになります。

❶　サーバーごとに埋め込みコードテンプレートを作成する。

現在、用意しているのは、Dropbox、Vimeo、YouTube、自宅サーバーの４つになりますが、埋め込みコードの書き方は、それぞれ違いがあります。Dropboxと自宅サーバーは、WordPress動画プレーヤーの使用方法に従って記述し、Vimeo、YouTubeはサイトで提供される貼り付け、埋め込みコードを参考にして記述して、それらのテンプレートを作成します。

Dropbox 埋め込みテンプレートの生成📄
Vimeo 埋め込みテンプレートの生成📄
YouTube 埋め込みテンプレートの生成📄
自宅サーバー 埋め込みテンプレートの生成📄

❷　動画idごとに埋め込みコードを生成する。

動画idファイル(spreadsheet)のS列(19列)に埋め込みコードを追記します。この埋め込みコードは、そのままWordPressのカスタムhtmlブロックへコピペすれば使えます。まず、その状態を作ります。

動画idごとに埋め込みコードを生成GAS📄

❸　埋め込みコードをJSONに書き込み、WordPressサーバーへ送る。

埋め込みコードをコピペするだけでも便利ではありますが、欠点もあります。ソースコードは見る人が見れば外から丸わかりなのでURLをコピーできます。巡回ロボットを使えばもっと簡単です。それを拡散できるわけですが、やたら拡散されてしまうことは非常に迷惑なことですので避けたいです。「漠然とした拡散は迷惑である」とするこの感覚が、SNSとの決定的な違いになります。

その意味で、「動的サイト」や「動画ショートコード」には、動画のURLまでは表記しませんので、やや、安全になります。埋め込みコードの欠点のあと一つは、複数箇所に書き込んでいて、もし動画他のURLを差し替えようとした時、複数箇所の修正をする必要があること、当たり前のことではありますが、これが結構ストレスになります。この点、元となる動画webサイトをメンテナンスすれば全部変更されます。

埋め込みコードJSON生成GAS📄

videoembed.jsonファイルは、gd_wp_dataに書き出されます。gd_wp_dataフォルダはHazelによって監視されており変化した場合はTransmit5のFTPにより数分以内にXserverにあるWordPressサーバーへ更新されます。

❹　動画ショートコードphpを作成する。

WordPressサーバー側では、投稿で記述されたショートコードとマッチするvideoembed.jsonファイル内の埋め込みコードに基づき、動画を再生します。

その処理を行うphpを、Cocoon childのfunctions.phpに追記します。

動画ショートコード起動php📄

まとめ

まとめになりますが、この動画ショートコードは、以前に投稿した、動的サイトの運用とセットになります。ぜひ、そちらもご一読ください→「動画用の動的サイトを作ってみた」。

以上です。