最近、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に引き上がりました。使いやすくなっています。仕方ないことですが、字幕一覧から、シーンへ飛ぶことはできません。

以上です。

大手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章を読む

🔗 目次ページへ戻る

今回は、以前に後回しにしたテーマでして、SynologyNASを利用してDropboxのデータをGoogleドライブへ同期する方法についての解説になります。

簡単な気がしますが、意外にややこしい、奥が深いのが以下のような話。

それが、Macの中のDropboxにあるAフォルダと同じ内容をGoogleドライブにあるBフォルダへ作ることです。いえ。データをコピー＆ペーストするだけなら簡単なことですが、大量にあるいは自動的にコピーさせようとすると、さてはデータを移動させてから解約を考えてるんじゃないか、勝手にさせないぞ、と囲い込みが働き、難しくなります。それもそのはず、クラウドストレージを二つも三つも好きで持っている人などいません。一つで済むのに越したことは無いのです。何度も書いてきているように、Dropbox、Googleドライブそれぞれ欠点があるからやむを得ず、両方持っているわけで、状況次第でいつ解約されてもおかしくないサービスです。

Dropbox内に作ったフォルダのエイリアスをGoogleドライブのフォルダに持ってくるようにすると、デバイスから削除するだの、利用できなくなるだの、Dropbox外に移動するだの、恐ろしい警告が表示されます。

何が起こるのかよくわかりませんが、やってはいけないことをやろうとしているのだろう、そう釘を刺されていると感じます。さすがビジネスに強いDropbox、トラブル時の責任範囲を明確にするということでしょう。上の場面では、キャンセルしました。しかし私は過去、こうした時に、先に進んでしまい、Dropbox全体ごとダウンロードをやり直した、そんな経験もあったような気がします。

有料なら、サービスはあります

クラウドストレージ間のデータ移動や同期ですが、MultiCloudという別のクラウドサービスを使うと実現できます。しかし、無料で使えるのは、月間5GBのデータトラフィックまでです。これは少な過ぎ！有料になると年間1200GBのトラフィックまでで約7,000円年となっていますが、容量ではなくてデータトラフィックと言われても実感が沸かないわけです。私の場合すでに有料会員としてDropboxは2TB、Googleドライブは0.2TBを利用していますので、またNASも持っていますので、クラウドストレージは、今のところ増やしたくありません。

まわりくどいが確実な方法を選んでみる

Mac内で、クラウドストレージ間でフォルダをコピーしたり同期しようとすると、何かと意地悪をされそうなので、迂回させることにします。SynologyNAS内で同期させます。１〜２分かかりますが、確実な方法です。

❶　MacのDropboxフォルダを変更するとDropboxクラウドが更新される(双方向同期)。

❷　SynologyNASのDropboxフォルダを更新する(CloudSyncによる。双方向同期)。

❸　SynologyNASのDropboxフォルダからSynologyNASのGoogleドライブフォルダを更新する(rsyncによる。一方向同期)。

❹　Googleドライブクラウドが更新される(CloudSyncによる。双方向同期)。

❺　MacのGoogleドライブフォルダが更新される(双方向同期)。

❸の存在を知らない人には、何が起こっているか分からない。

今回私は、確実にデータを移動させかつ便利に使うための仕組みを作っているわけです。しかし、「確実」「便利」という言葉の背後には、「確実、便利に悪巧みをする方法」ということもあり得るわけですね。そもそも❸は自由自在にデザインできるわけです。例えば、「元データの中に金額があったら２０％水増しして新たに書き出せ」とか、AIに解読させて、どちらかに有利に変えさせるとか、様々な悪巧みができるわけですね。見方を変えれば、「データ転がし」ですから。データ隠し、マネーロンダリング、不正改ざん、など。ここで重要なのは、そうした危険性があるということを知っておくことでしょう。

ポイント解説

１　rsyncの設定手順

シェルスクリプトファイルの作成と格納

dropbox_google_sync.sh

SynologyNASにはrsyncは最初から入っているので、シェルスクリプトのファイル.shを、Macのテキストエディットなどで作成(例えばdropbox_google_sync.sh)→SynologyNASの共有フォルダに例えばbinフォルダを作る→binフォルダの中にdropbox_google_sync.shを入れる。

タスクスケジューラの設定

SynologyNASのコントロールパネル→タスクスケジューラー
「全般」「スケジュール」「タスク設定」を以下のように設定します。

ここでは、毎分更新にしています。

２　Macから共有リンクが取得できる

今回のように、送り出し側のフォルダ名を”sync_to_google”、受け取り側のフォルダ名を”sync_from_dropbox”とわかりやすくするのが賢明です。”send_”、”receive_”と頭につけるのもわかりやすいです。そうせずに、Aフォルダ、Bフォルダなど無意味な名前ですと、迷子になりそうです。

関係を逆にして、送り出し側をGoogleドライブに設定して、受け取り側をDropboxに設定することも、もちろん可能です。

３　その他　まとめ

私が便利に感じているフローは、各種メディアデータの加工はDropboxで行う→メタデータはGoogleドライブへ登録する、実データ(メディアコンテンツ)は配信サーバーへ送り出す→GoogleドライブでAppSheet、GASを使いメタデータを加工する→Xserverなどの外部サーバーへ送り出す。という形です。今回はそのフローの一部でもあります。

以上です。

制作用のパソコンは、フリーズが多くなってしまう。再起動がつきもの。

音楽制作や動画制作では、アプリのバグに振り回されて、結構、頻繁にフリーズして、Macを再起動することが起きます。その作業の最中に、並行して、HazelやAppleScriptなどのファイル更新の自動処理を行っているときに、そちらも、中断させられてしまいます。その逆もあります。いずれも、やり直しになります。

ファイルの更新処理は切り離したい。

やはり、制作類の作業を行うMacと、ファイル更新処理を行うMacなどのコンピュータは独立させた方が、全体としての安定性が向上します。

但し、クイックアクションなどの、いわゆる生産性を上げるための操作は、制作作業Mac側で行い、ファイル更新処理Macの様子を別ウインドウで表示して横目で監視するようなやり方でも、問題なく使えるでしょう(例：上の写真)。

ファイルサーバーとしても活用

M1以降のMacはほとんど発熱もなく消費電力も小さいので、少なくともファイル更新処理Macは常時稼働で問題なく、いわばファイルサーバーのようにSynologyNASの頭脳のような位置付けで使用するのが相性が良さそうです。

Mac miniもそうだが、Macは進歩はすれど安心して継承できる。

つい先日、M4 Mac miniが発表され、どんどんコンパクトに強力になっていくことに驚いていますが、方向は、そうなるのだろうなと想像はしていました。

つまりMacminiは、サーバーだと思えば、電源スイッチを底面にしたのもガッテンです。NASの電源スイッチなど１年に1回触るかどうかです。

しかしよくよく考えて、最新鋭のM4 Mac miniをサーバー的に使うのは勿体無いわけで、もしM4 Mac miniを制作系の作業で使うなら、アプリ側の更新の遅れで頻繁なフリーズに悩まされて、何度も電源スイッチの入り切りを行うことになるわけですから、いっそのことスイッチ付きテーブルタップを、自分の一番使いやすい位置に取り付ける、そういう結論になるのだと思います。まあ小さい話です。

先入先出の作業方法をApple Intelligenceに考えてもらいたい。

OSは今回、１世代前のSonomaにアップしました。それは１年遅れで信頼性を確保したいからです。次のOSの更新を焦るつもりはありません。ハードに依存します。ハードは、いずれは、M4 Macminiなどがメイン機になり、今あるM2 Macminiがサブになる、古いものから順に引退する、つまり先入先出になるわけです。課題は、特に音楽制作は、Mac本体内のディスク容量を食うのでM2 Macminiは1TBとしてきました。どういうことかと言うと、音楽制作のDAWは、多種多様な音源をロードして使います。そのロードに時間がかかるのです。その音源のうち音源データ部分は外部SSDなどへ逃すにしても、アプリケーション部分は本体内に残すようにしないと、ロード時間を短くできないのです。前述したように、そのDAW、音源アプリさらにはOSとハードとの間で、バグや相性不具合が生じて強制的な起動が頻発するわけです。どうにかならないかとストレスを抱えます。しかし、M4 Macmini1TBともなると、また高価格になっていくので、なかなか、ついていけませんね。  次は何とかメイン機のディスク容量を512GBで抑制できないか、そのように改善したいです。その診断と解決策をApple Intelligenceに考えてもらえたら助かりますね。

ポイント解説

１　DropboxとGoogleDriveの間のデータの更新方法について

クラウドストレージとクラウドストレージの同期を行うのにはどうするか(※1)。それまた別のクラウドストレージによるサービスもあるのですが、両方ともデータはローカルにあり、SSDの中あるいはNASの中にあるので、ローカルで更新を行う方法を選択します。rsyncを使う方法が一般的です。これはNASの中でもMacのSSDの中でも使用できます。NASの中で行う方法について、別の投稿で、説明するつもりです。

更新の方向ですが、Dropboxが更新されたらGoogleDriveが更新される、from Dropbox to GoogleDriveにします。つまり、基本的なローカルでのファイル作成作業はDropboxで行うこととします。

※１：SynologyNASのアプリにCloudSyncがありますが、これは、ローカルのフォルダやファイルに対しては、一つだけのクラウドストレージしか指定できません。

２　GoogleDriveも使う理由

それならDropboxだけでいいではないか、と思われるところですが、それは早計でして、GoogleDriveを使う理由は、AppSheetを使いたい、GASを使いたい、スプレッドシートを使いたい、それらのためにGoogleDriveが必要になるからです。
いえそれなら、GoogleDriveだけでいいではないか。と思われるでしょうが、これまた勇み足でして、字幕の扱いがうまくいかないため動画をリンクで使うのが困難。ならDropboxの方がマシということが大きいです(解説🎥)。

３　Dropboxデスクトップアプリによるファイル操作がラク

Dropboxにある写真や動画をWordPressへリンクするためにDropboxリンクを取得しようとするとき、Dropbox.comのサイトから入るのはちょっと手間がかかり過ぎです。Dropboxのローカルファイルから右クリックで取得できれば簡単です。SynologyNASは、そのフォルダをDropboxと同期することはできますがしかし、SynologyNASのDropboxのフォルダからは、それを右クリックしてもDropboxリンクの取得はできません。Dropboxデスクトップアプリが提供されていないためです。この辺りが、SynologyNASをパソコン的に使えないと感じる部分です。

その点、MacやWindowsでは、デスクトップアプリが提供されているため、以下のように、MacのFinderからでも、Dropboxリンクが取得できます。GoogleDriveでも同様に、リンク取得が可能です。

M1 Mac miniは、M2 Mac miniからの画面共有(スクリプト📒)の形にしています。共用のモニター、キーボード、マウスで操作しています。

以上

現状では、世界のどこかの人が何かのデバイスで、このブログを見て、その中の動画を視聴した時に、言葉がわからないという問題にぶつかります。ですから、そのブログの中に、言葉をわかるようにする「手掛かり」を配置しておきたいと思います。

ただその「手掛かり」と言っても、なかなか簡単ではありません。
条件が複雑過ぎるからです。

現在、条件がどうマチマチであるか眺めてみます。まず、デバイスとしてポピュラーなものをピックアップすると、WindowsPC,Mac,iPhone,iPad,Android携帯、Androidタブレット、以上になるでしょうし、OSでポピュラーなものは、Windows,Mac,iPad/iPhone,Androidになるでしょうし、ブラウザでポピュラーなものは、Chrome,Edge,Safariになるでしょうし、さらに動画の配信側は、YouTube,Vimeo,WordPress,Dropboxなどクラウドサービス、自宅サーバーなど。。
こんな複雑な条件の中で、今、こうしたブログさらにその中の動画などが配信されているわけですね。ですから、全てのユーザーに、「言葉がわかるようにする」のは無理と言っていいでしょう。

結論が遅れました。

それほど、手の込んだ工夫ではありません。

動画の下に、タイムコードあるいは番号が付いた「字幕一覧」を配置すべし。
具体的には以下です。

このような折りたたみの字幕一覧を用意しておくと、ブログの翻訳をすれば、この部分も翻訳されます。(1)(2)などの番号でもいいですが、動画の中の位置が分かりません。タイムコードなら動画のバーを近くに持っていけます。YouTubeなどで字幕の自動翻訳もありますが、速く進み過ぎて目が追いつけません。だから、自分のペースで追いたいです。逆に、急いでいるので動画の要点をサラッと知りたいということもあります。いわば「本屋の立ち読み」です。音声の早送りより、はるかに生産性は高いです。10分の動画でも字幕一覧をみれば30秒で概略がわかります。

AIの解読力ですが、動画を理解することもできるようになってきてはいます。しかし多大なリソース消費の問題もあり正確性も今一歩のところがあります。Geminiに質問してみましたが、動画に字幕ファイルが別添されている形が、AIとすると一番ありがたい形式、と言う返答でした。

いずれにせよ字幕一覧形式は非常に優れています。翻訳した字幕一覧を自分のメモに貼り付けることも出来ます。字幕が邪魔なら、動画の字幕を非表示にして、この字幕一覧を折り畳めばいいです。

ちなみに、上の折りたたみ字幕一覧を、左上のGoogle翻訳で試してみてください。翻訳の途中から改行がされない現象が生ずる場合があります。これはChromeからChromeの翻訳機能を使っても同じ現象になるでしょう。
次に、AppleやWindowsの翻訳を試してみてください。ブラウザから利用できると思います。それを使うと、正しく改行されるはずです。

Macで使う場合、Vimeoの動画に表示される字幕の翻訳は、Google翻訳では翻訳不可ですが、Apple翻訳ではVimeoの動画に表示される字幕を翻訳してくれます(動画無音)。iPad,iPhoneではそれが難しいのでWordPress固定ページに字幕一覧を読み込んで工夫することにします(動画有音)。

Apple翻訳で気づいた欠点の一つは、WordPress動画プレーヤーで表示される字幕について翻訳しようとする時パカパカと点滅状態になるため(動画無音)字幕は非表示にせざるを得ない点があります（2024.2月現在)。

なお、WindowsのEdgeにより、vimeoのプレーヤーを直接に呼び出す、つまりhttps://player.vimeo.com/video/xxxxxxxxxを入力する場合ですが、AppleのSafariと同じく、字幕は直接に翻訳されます(動画無音)。

総じて、各社の字幕や翻訳の対応は、まだまだバラバラな状況と言っていいです。そこへ群がるように、各社がAI生成画像、音楽などのサービスをくっつけてきているというのが現状です。

そこで、振り回されないように、字幕一覧を配置して、Apple/Windows翻訳とGoogle翻訳の両方を使い分けるようにしよう。というのが、この投稿の主張です。

＜字幕作成に関するオリジナルスクリプト一覧表＞

ポイント解説

１　その他

WindowsPCでのこのブログにリンクした動画の再生についてです。Dropboxの動画についてですが、Dropboxの動画は、ブログに貼り付けた場合は、そのまま素直にストリーミング再生されます。しかし、URLをリンクで再生しようとした場合、ダウンロードしてからの再生を求められます。それはとても面倒なこと。その点も勘案して、Google翻訳アイコン、動画、字幕一覧の各場所をテンプレートにして、動画については、Vimeo、Dropbox、WordPressサーバー、YouTubeなどを貼り付けられるようにして、WordPressの固定ページで動画ライブラリーとしてひとまとめにするように改善中です。

以上

改めて、災害時の損失を抑え復旧を速やかに行うことが大切と感じています。自宅サーバーを今すぐ撤去するつもりはありませんが、自宅サーバーに依存しない方向、自宅サーバーは選択肢の一つにする方向、そちらへ舵を切りたいと思います。動画再生方法のいくつかの選択肢をテストする中で、その選択肢を更に使いやすくする方法を作ってみます。なお、Google単独は、GoogleドライブからWordPressプレーヤーへ動画と字幕を同期させて引き込む方法は、基本的には困難なようですので、対象から除きました。

No1　Vimeo単独

VimeoはYouTubeと同様にトランスコードされてストリーミング再生されるので、停滞が非常に少ないです。Vimeoは、動画の、まるごと差し替えがOK、何回でも上書きアップロードができます。

注：動画の中で、書き換え方法を、dl=0→raw=1としていますが、www.dropbox.com→dl.dropbox.com dl=0→raw＝1へ変更しています。

動画を別ページで表示します(ここをクリック)。

No2　Dropbox単独

Dropboxは、ブログを補足するための短い簡潔なビデオが適しています。ニッチに役立つことが目的なので、集中アクセスは殆どないと想定しますが、一般向けの内容の場合はVimeoを使います。Dropboxの再生のスムーズさは、WiFi環境であれば、少々待ち時間はありますが、問題なく視聴できると思います。但しスマホで4Gセルラーでの視聴は、時間帯によっては困難かも知れません。特に昼休み。仕事場でWiFiや有線LANでパソコンを使っていた人が、昼休みになると一斉にスマホを使い出すので、昼休みは困難かも知れません。この動画は476MBと大きいサイズです。更新方法は、MacにあるDropboxにリンクしたローカルファイルを上書き保存するだけです。

注：動画の中で、書き換え方法を、dl=0→raw=1としていますが、www.dropbox.com→dl.dropbox.com dl=0→raw＝1へ変更しています。

No3　自宅単独

Dropboxより非力です。過去の投稿で紹介してきた通り、一般には、476MBという大きい動画を扱うのは無理クリですが、あえて掲載しました。WiFi環境で、高速度なら、視聴できるかも知れません。場合によってはDropboxよりサクサク動くこともあります。更新方法は、MacにあるDropboxにリンクしたローカルファイル(実はWordPressフォルダとも同期させている)を上書き保存するだけです。

注：動画の中で、書き換え方法を、dl=0→raw=1としていますが、www.dropbox.com→dl.dropbox.com dl=0→raw＝1へ変更しています。

No1~No3と比較してきましたが、現在、安定度に優れるのはNo1のVimeoが第１位、No2のDropbox単独が第2位です。扱い易さは、圧倒的にNo3の自宅単独です。実はこの3つ以外にも、Dropbox(動画、字幕) と自宅(初期画面)、Dropbox(動画、字幕) とGoogleフォト(初期画面)、Dropbox(動画、字幕) と外部(初期画面)についてテストをしましたが、今一つ不安定なことと操作が複雑になることから割愛しました。
しかし、今回、改めて考察するキッカケになった災害リスク。これを考えると、自宅のWebサーバーに比重を置くのは問題といえるでしょう。

従って、今回、「No2 Dropbox単独を採用していきます。10分未満の簡単編集でマニアックなものはDropbox、ファイルが重そうな10分以上あるいは一般向け配信のものはVimeoという使い分けをイメージしています。さあどうかな。

ポイント解説

１　動画の中に登場するAppleScriptの紹介

（１）Dropboxの共有リンクをWordPress貼り付け用に変換するクイックアクションのAppleScriptは、以下です。

コード変換の方法は、

URLの記述の中の

“www.dropbox.com” を”dl.dropbox.com”へ置き換える。

“dl=0” を”raw=1″へ置き換える。

を使っています。なお、拡張子に関係なく扱えています。

DropboxのURLを変換するAppleスクリプト

「AppleScriptを実行」を挿入

-- DropboxのURLを変換するスクリプト

-- ３−１　ベースとなるDropboxの共有URLを一時的に保管する。
set baseURL to the clipboard
set tempURL to ""

-- 共有URLが存在するか確認
if baseURL is not equal to "" then
	
	-- ３−1　クリップボードの結果をtempURLへ置き換える。
	set tempURL to baseURL
	
	-- ３−２　URLの記述の中の "www.dropbox.com" を "dl.dropbox.com" へ置き換える。
	-- set tempURL to replaceText("www.dropbox.com", "dl.dropbox.com", baseURL)
	
	-- ３−３　URLの記述の中の "dl=0" を"raw=1"へ置き換える。
	set tempURL to replaceText("dl=0", "raw=1", tempURL)
	
	-- ３−４　クリップボードに保管する。「クリップボードにWordPress貼り付け用URLをコピーしました。」と表示する。
	set the clipboard to tempURL
	display dialog "クリップボードにWordPress貼り付け用URLをコピーしました。"
else
	display dialog "共有URLが見つかりません。"
end if

-- 文字列中の指定されたテキストを置き換える関数
on replaceText(find, replace, sourceText)
	set text item delimiters to find
	set sourceText to text items of sourceText
	set text item delimiters to replace
	set sourceText to sourceText as text
	set text item delimiters to ""
	return sourceText
end replaceText

（２）WordPress動画貼り付けコード生成用アプリのAppleScriptは以下です。

-- スクリプトのテンプレート
set scriptTemplate to "<figure class=\"wp-block-video aligncenter\">
<video controls
poster=\"%poster%\"
src=\"%video%\" 
playsinline=\"\">
<track default=\"\" 
src=\"%subtitles%\" 
label=\"日本語\" srclang=\"ja\" kind=\"subtitles\">
</video>
<figcaption>%videoDescription%
</figcaption>
</figure>
[dynamic_external_html url=\"%subtitle_list%\"]"

-- ダイアログでユーザーに入力を求める
set posterURL to text returned of (display dialog "<WordPress動画貼り付けコードを生成> 開始画面の画像のURLを入力してください(省略可)。" default answer "")
set videoURL to text returned of (display dialog "<WordPress動画貼り付けコードを生成> 動画本体のURLを入力してください(省略可)。" default answer "")
set subtitlesURL to text returned of (display dialog "<WordPress動画貼り付けコードを生成> 字幕ファイルのURLを入力してください(省略可)。" default answer "")
set videoDescription to text returned of (display dialog "<WordPress動画貼り付けコードを生成> 動画の説明を記入ください(省略可)。※先頭の文字に小文字の< >は不可。" default answer "")
set subtitleListURL to text returned of (display dialog "<WordPress動画貼り付けコードを生成> 字幕一覧のURLを入力してください(省略可)。" default answer "")

-- スクリプトのテンプレートをユーザーの入力で置き換える
set customHTML to scriptTemplate
set customHTML to my replaceText(customHTML, "%poster%", posterURL)
set customHTML to my replaceText(customHTML, "%video%", videoURL)
set customHTML to my replaceText(customHTML, "%subtitles%", subtitlesURL)
set customHTML to my replaceText(customHTML, "%videoDescription%", videoDescription)
set customHTML to my replaceText(customHTML, "%subtitle_list%", subtitleListURL)

-- 置換用の関数
on replaceText(originalText, searchString, replacementString)
	set AppleScript's text item delimiters to searchString
	set textItems to text items of originalText
	set AppleScript's text item delimiters to replacementString
	set replacedText to textItems as text
	set AppleScript's text item delimiters to ""
	return replacedText
end replaceText

-- 結果を表示
display dialog customHTML

-- 結果をクリップボードにコピー
set the clipboard to customHTML
display dialog "この内容をクリップボードにコピーしました。"

なお、後日、字幕一覧のデータの投稿内引き込みを追加しました。WordPressのfunction.phpへ以下を追加ください。

<?php
// 外部テキストを取得する関数
function fetch_dynamic_external_html_content($atts) {
    // ショートコードの引数を定義
    $attributes = shortcode_atts(array(
        'url' => '' // URLを指定する
    ), $atts);

    $url = $attributes['url'];
    
    // URLが指定されていない場合の処理
    if (empty($url)) {
        return 'URLが指定されていません。';
    }

    // 外部URLからデータを取得
    $response = wp_remote_get($url);

    // エラーチェック
    if (is_wp_error($response)) {
        return 'テキストの読み込みに失敗しました。';
    }

    // 取得したデータの処理
    $body = wp_remote_retrieve_body($response);
    return $body; // HTMLとしてそのまま返す
}

// ショートコードを作成
function display_dynamic_external_html($atts) {
    return fetch_dynamic_external_html_content($atts);
}
add_shortcode('dynamic_external_html', 'display_dynamic_external_html');

?>

上の２つのAppleScriptは、汎用性があります。

例えば、自宅サーバー用のWordPressのカスタムhtml記述については、URLはランダムな文字列を埋め込むことなく、素直なディレクトリの記述になっているので、（２）だけ使います。

２　ChatGPTの活用

上のAppleScriptですが、実は、ChatGPT（無料版の利用）の力を借りています。私は、「指示書を書いて、結果を検証して、間違いを指摘して訂正を求める」だけです。ChatGPTは、プログラミングは得意な分野だと思います。私は、特に活用法をどこかで学んだことはありませんが、質疑応答を、「解決して欲しい問題を書く、何を使って、どのような手順で（手順１　手順２　、、）、プログラミング記述して欲しいかを書く」という流れで繰り返すことができます。但し、即座に正しい解法になることはまずありません。出てきたエラーをそのまま伝えて、訂正を依頼する、それを、５〜６回繰り返して、辿り着く感じです。隘路に入ったためスタートに戻ることも、ままあります。

３　マウスの左を３回クリック

動画の中で登場する、マウスの左３回クリック、トリプルクリックは、このブログをご覧の方はご存知のことと思いますが、紹介します。

４　2023年12月にDropboxリンクの構造が変更。個々のコンテンツ単位で制限管理ができる仕組みへ移行。

DropboxリンクのURLですが、以前は”https://……..？”まででした。2023年12月にrlkey=以降が追加になっています。トラッキング追跡のためか何らかの異常回避、情報収集のためでしょうか。ファイル単位でアクセス制限ができるようになるのかも知れません。いずれにしても、何らかの安全対策だと思います。　自宅サーバーは、サーバー単位か、そこまで細かく出来ていないので、Dropboxは一歩も二歩も進んでいます。

Dropboxヘルプセンターにrlkeyを導入すること及び利用方法(レンダリングの強制 )の説明があります。この中で、ブラウザで直接画像を表示するには、つまりWordPressなどでリンク表示する場合は、raw=1を使ってリダイレクトをさせて使用するように指示が書かれています。まだ移行が完了したとはしていないので、今後とも何らかの仕様の変更があるかも知れません。ウオッチする必要があります。

５　Dropboxリンクを使うならファイル名は英数字で作るのが基本。

Dropboxリンクは、ファイル名を変えても、フォルダを移動しても、変わりません。”https://ランダムな文字列/ファイル名?rlkey=ランダムな文字列“となっています。このファイル名のところですが、日本語の部分が削除されます。ですから、ファイル名は、英数字だけでユニークな文字列をまず書いて、私は年月日プラス連番がいいと思いますが、そこに少しだけ短く日本語を加える書き方がよさそうです。

６　ダウンロードを要求される問題。

Dropboxリンクの末尾をraw=1に置き換えたURLを、WordPressの投稿中の文字列にリンクして再生しようとすると、ダウンロードを要求される場合があります。Dropboxはクラウドストレージが本業であって、データを受け渡すのが本業。だから、動画や画像も、ビジネス上のファイルのやり取りと同様に、利用者が一度自分のフォルダへダウンロードして、その後で、そのファイルを再生する。それが基本だろうと思います。しかしながら私のように、個人のWeb配信に使う場合は、ダウンロードを要求されるなら、それは不便過ぎて利用できないです。そこで、そのような個人的な小規模の発信者に対して、ランダム生成した非常に長いURLアドレスへリダイレクトするなら利用を可能にする、アクセスが集中するようなら視聴制限を加える、そうした条件の下で利用を許可しているということになります。

ともかく、間違いないのは、Dropbox動画ごとに、それを貼り付けた独立ページ（固定ページ）を自分で作ることです。そしてその独立ページをWordPressの文字列にリンク。そうすればWindows/Macほかでもダウンロードを要求されないでしょう。

７　動的トグル

小さな工夫の紹介ですが、上のスクリプトのところで、「字幕一覧のデータの投稿内引き込みを追加した….」と記述しましたが、これの具体例が、以下のトグルです。

上の3つの動画の下部に挿入した字幕一覧のトグルと同じものです。このtxtファイルは、Dropboxの中にあります。上に掲載のfunction.phpをコピペしたあと、

[dynamic_external_html url=""]

上をカスタムhtmlに記述して、url=””のところに当記事で説明した方法で変更したDropboxリンクを挿入します。Dropboxにあるこのtxtファイルを変更すると、全てのこの字幕一覧の表示が変更されます。当たり前といえばそうなのですが、なかなか便利です。動的トグルと呼んでおきます。

８　直接リンクには3つのサーバーがあるが、不安定であり、モニタリング要。

Dropboxから画像を直接リンクする方法は、正直、不安定です。以下に、同じ画像を、DropboxのURLをwww.dropbox.com（変更なし)の場合、dl.dropbox.comの場合、dl.dropboxusercontent.comの場合、を並べます。数日様子を見ていますが、www.dropbox.com(変更なし)がほぼ常に表示されています。これの特徴は、別のトークンURLに書き換えられて表示されるという２段階になっています。状況をウオッチしていきます。
2024.5.5時点で、www.dropbox.com raw=1は表示不可、dl.dropbox.com raw=1は表示可能となっています。