そろそろ届く頃かなとは思っていたところですが。

Dropboxの年額更新案内が届きました。もともと課題意識があったので準備を進めてきたことではありますが、クラウドストレージの運用体制を見直し、Googleドライブ（Google AI Proプラン）への全面移行を進めることにしました。

長年使い込んできたDropboxからの脱却にあたり、課題となった「ローカルパスの互換性」と「自作アプリ（AppSheet / WordPress連携）への影響」をどのようにクリアしたかについて記録しておきます。

１　乗り換えを決意した理由〜ドル建て料金は重過ぎる〜

これまでDropbox Plus（2TB）を利用していましたが、ドル建て決済（131.87 USD/年）のため近年の円安傾向も相まって年間2万円超（月換算で1,700円〜2,000円近く）の負担となっていました。

特に個人の場合、ふつうは貿易はしてないので、支払いに充てる外貨資金があるわけでもなく、やっぱりDropboxは企業重視だなと感じます。

そこへ、新たに登場したGoogle AI Proプランは、月額2,900円ですが、生成AIの結構幅広い機能に加えて、Dropboxの2.5倍の5TBの大容量ストレージがパッケージされています。ストレージ単価や今後の拡張性を考慮すると、Googleドライブへ集約する方が圧倒的にメリットが大きいと判断しました。

（後日、記事を書こうと思いますが、GoogleAIPro2,900円とGoogleAIPlus725円の相互乗り換えが、Gドライブの使用量を400GB以内に管理することにより可能になることと期待します。）

２　ローカルフォルダ構造とパスの維持工夫

M1 Mac mini環境において、各種スクリプトや自作アプリが既存の「Dropbox」フォルダパスに深く依存しています。すべてのフォルダパスを書き換えるのは膨大な作業となるため、以下の形でミラーリング同期を設定しました。

• ローカル側：既存のフォルダ構造（…/Dropbox）をそのまま維持
• クラウド側：Googleドライブ上の パソコン ＞ マイ Mac mini ＞ mybox_1 フォルダに対してミラーリング同期を実施

この設計により、ローカル上のスクリプトやファイルパスを変更することなく、同期先クラウドだけをDropboxからGoogleドライブへ安全に切り替えることが可能になります。

３　自作アプリ（AppSheet・配信システム）の影響調査と改善

最も懸念していたのが、自作のメディア管理アプリ（マイライブラリ）および配信システムへの影響です。

これまではGoogleスプレッドシート（F1_マイライブラリ）のA列に「Dropbox共有リンク」を記録し、WordPress等のエンコードURLや各配信サーバーへと連携する仕組みを構築していました。Dropboxを解約するとこれらの共有リンクが無効化されてしまうため、以下の改修を行いました。

改善ポイント

①Dropboxリンク依存の脱却

• 今後の新規登録（テスト登録.png 等）では、Dropboxリンク欄を空欄に設定。

②ユニークID（wpidex）による配信URL生成

• 外部共有リンクに頼らず、システム内部のユニークID（wpidex）をベースにWordPress経由の再生URLを直接生成・配信するロジックへ変更。

実証実験を行い、Dropboxリンクが空欄の状態でも正しくデータが表示され、動画・画像配信に一切支障がないことを確認できました。

結局、今回の改善手順のポイントは、
Dropboxを解除したあとは、普通のローカルフォルダだけで運用が出来るようにすること。
次に
そのローカルフォルダをGoogleDriveなど別の場所にミラーリング同期すること。

ということになります。

４　まとめと今後の運用

ビデオの中では、フォルダ名にDropbox dropbox_1を残したまま、昭和歌謡の「昔の名前で出ています(小林旭)」として、使い続けることを決心していたのですが、気が変わりまして、できるなら、ローカルフォルダ名も、mybox mybox_1に改名したいと強く思うようになり、主にPythonアプリを７本程度、手直ししました。その結果、現在は、昔の名前は名乗らず、今の名前で出ています。

余談：
Macには、M2 MacminiとM1 Macminiがありますが、M2の意味は、現在はAppleシリコンM2のM2ではありますが意味としてはMeister2のM2、と意味付けします。将来、AppleシリコンM6 Mac miniをこのNO2_Macの位置に入れ替えたとしても、imakatシステムでは、 M2 Mac mini、と命名し続けます。M1も同様です。と言うのは、Macの機器更新の時、設定を変えることなく、前の機器の内容をそっくり移行できるからです。

自作システムの改修とデータ移行の検証が完了したため、これで懸念事項はすべて解消されました。実際、8月30日に解約を行いました。

長年依存してきた環境からの移行ですので心配しましたが、構造をシンプルに整理し直す良い機会となりました。同様の構成でストレージ移行を検討されている方の参考になれば幸いです。

以上

最近、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つのサーバーに不具合が起きても、AppSheetから、拡張子別あるいはファイル別に再生サーバーを切り替えることが可能になっています。

次回予告：

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

➡ 第４章を読む

🔗 目次ページへ戻る

ポイント解説：

作成するスクリプトは、結構、分量があります。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形式で送信し、更新処理を実行する。
⬇️＜マイライブラリ生成更新処理＞ このGoogle Apps Scriptは、WordPressと連携するメディアライブラリの自動管理システムです。Webhook (`doPost`) を介して新しいメディア情報の追加や既存パスの変更通知を受け取ります。 主要機能は以下の通りです。 1. **メディア情報の一元管理**: Googleスプレッドシート（F1シート）を主データソースとし、Dropboxリンク、ファイルパス、WordPress用のURL（正規化・エンコード済み）、ユニークID（wpidex）などを自動生成・更新します。 2. **パス変更履歴の適用**: ファイルパス変更履歴シート（F3シート）を利用し、F1シートの旧パスを新パスへ自動更新します。 3. **JSONファイルの生成と同期**: F1シートのデータからWordPress連携用のJSONファイル (`dropbox_wp_library.json`) をGoogle Driveに生成・上書き保存します。 4. **動画埋め込みJSONの更新**: 別シートの動画埋め込みデータをJSON化し、外部サーバー（Xserver）へ送信して`videoembed.json`を更新します。 5. **シートの整理と重複除去**: F1シートの不要行削除、K列フラグのリセット、重複行の整理（新しい方を優先し、一部データを引き継ぐ）、更新日時順での並べ替えを行います。 6. **pCloudID連携**: F1シートの情報に基づき、pCloudID同期用シートの内容を更新し、変更があった場合は更新フラグを立てます。 `processWorkingRecord`関数が中心的な役割を担い、モードに応じた一連の処理とデータ同期を安全に実行します。多岐にわたるユーティリティ関数が処理を支援します。
⬇️＜メディアおよび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 起動時に自動実行される構成となっている。

<dropboxリンクの定期的自動修復> このシステムはmacOS上でDropbox共有リンクの自動巡回・修復、およびリンクの有効性チェックを行うものです。`fix_dropbox_links.py`はスプレッドシートのローカルパスを基に、共有リンクをダウンロード可能な形式(raw=1)に変換し、Mac特有の濁点問題を修正してAPI経由で最新リンクを取得します。差分があればスプレッドシートを更新しフラグを立てます。この処理は`com.XXXXXX.fix_dropbox_links.plist`により1時間ごとに自動実行されます。さらに今回追加された`check_dropbox_link.py`は、任意のDropbox共有リンクが有効か（リンク切れしていないか）をAPIを用いて直接確認し、結果をログに出力します。これらのスクリプト群により、Dropbox共有リンクの継続的な整合性維持と異常検知を自動化、手動介入を減らした堅牢な運用を実現しています。

上の処理は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のプレーヤーを直接に呼び出す場合ですが、AppleのSafariと同じく、字幕は直接に翻訳されます(動画無音)。

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

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

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

ポイント解説

１　その他

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

以上