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

以上

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

🔗 目次ページへ戻る

WordPressのテーマに無料のCocoonを使用していますが、使い続けさせていただき感謝を申し上げる次第ですが、とても分かりやすくできているので初めての人でもすぐに馴染めます。子テーマへは、自分なりのカスタマイズも行えるようになっており中級者にも満足いけるものと思います。

ページのデザインには、たくさんの着替えが選べるようになっています。

ブログで一番目立つ場所は、やはりヘッダーだろうと思います。このヘッダーには、ロゴやキャッチフレーズが自由に差し替えられます。ヘッダーの背景画像も差し替えが出来ます。

そこで思ったのは、このヘッダーの背景画像が自動的に差し替えが出来たらいい、というか、手元の、Macやパソコンの画像ファイルを書き換えたら、そのままWordPressの更新がされたらラク、そう考えました。ちなみに、キャッチフレーズも日替わりはどうかと考えてみましたが、SEOに悪影響がありそうなのと、そもそもあまり面白味がないので、やめました。

3つの更新方法

以上ですが、No１はオーソドックスな方法で、間違いは少ないです。No２は、自宅サーバーがある場合は、Macのフォルダに画像ファイルを更新するだけで、Web配信まで連動していくのでシンプルです。No３はMacのDropboxフォルダにある画像ファイルを更新するだけで、Web配信まで連動していくので、一見、シンプルですがしかし画像のURLは複雑なトークンリンクになっています。

No３のデメリット

No３のデメリットを言います。No１とNo２は、URLからフォルダ階層が明示されるので迷子にならないですが、No３はURLは暗号化された文字列でありフォルダ階層も分かりません。従って、URLとファイルパスをコンビにしてどこかに記録しておかないと迷子になります。上書きは結構、頻繁に行うことになると思います。もし、上書きに失敗して新規にリンク取得となると、また、head-insert.phpを書き換える必要が生じます。これは起こり得ることだと思います。

当面は、No２を利用

No３を別の寸評をすると「壊れやすい華奢」。No１とNo２は「少々乱暴でも壊れない」。

私としては、ブログは、読みこみ許可、書き込み禁止で公開するのを基本と考えていまして、ファイルの所在位置が分かってしまうことは問題ではありません。それゆえ２を選択することにします。

具体的な設定

URLで共有できるメディアサーバーがあれば、その中にxxxxx_header_imageフォルダを設定します。パーミッションを、管理者以外は読み込みのみ、URLを知っている人全員可、に設定します。

日本時間での曜日の変更になります。

画像は、pngでもjpgでも問題ありません。画像のサイズは、ヘッダーのデザインによりますが、0.5MB程度に調整するのがいいと思います。

header-insert.phpへの記述

Cocoonの場合は、テーマCocoon child→tmp-user→head-insert.phpになります。

Cocoonの場合は、テーマCocoon child→tmp-user→head-insert.phpになります。

以上です。

改めて、災害時の損失を抑え復旧を速やかに行うことが大切と感じています。自宅サーバーを今すぐ撤去するつもりはありませんが、自宅サーバーに依存しない方向、自宅サーバーは選択肢の一つにする方向、そちらへ舵を切りたいと思います。動画再生方法のいくつかの選択肢をテストする中で、その選択肢を更に使いやすくする方法を作ってみます。なお、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は表示可能となっています。

＜分散通知の仕組みを作る　STEP5: ブログ(Blogger)への投稿＞
別ページで表示

ブログは、時系列の掲示板であり、その中には、今回取り上げている緊急通知も含めていいと考えています。記事の性格は、楽しい思い出づくりとは異なりますが、緊急かつ重要な情報は、どこにでも飛び込んでいいものと考えます。

今回、無料のブログの選択には、多少悩みました。この種のサービスは打ち切りになることが多いからです。その中から、Googleと相性がいいもの、シンプルなもの、であるBloggerを選択しました。Bloggerは他のサービスへの移動、例えばWordPressへの移動などについても、説明が数多くあることも安心です。

ポイント解説

＜1＞ GoogleSSへの取り込み

流れとしては、通知文GoogleSS→Blogger送信用GoogleSS→Blogger、です。APIは使いません。Bloggerにはメール投稿機能が備わっており、それを利用します。

Blogger送信用GoogleSSの画面は以下です。

この画面には、Googleフォームへ入力した通知文GoogleSSが取り込まれるため、内容を確認するだけです。問題がなければ、「Blogger投稿」ボタンを押します。

通知文の読み込み：

IMPORTRANGE関数を使います。
読み込みたいGoogleSSのURLが、下記のようになっていたとして、

https://docs.google.com/spreadsheets/d/【この部分】/edit#gid=0

【この部分】を以下の場所に当てはめてください。sheet1は実際のシート名、A10,A12のところも実際のセル位置を当てはめてください。

Bloggerでは、タイトル、本文と関係リンク、の２データを、通知文GoogleSS から読み込んで、このBlogger用GoogleSSへ取り込みます。

=IMPORTRANGE("【この部分】","sheet1!A10")
=IMPORTRANGE("【この部分】","sheet1!A12")

＜2＞GAS記述

GASの記述：

このままコピペください。赤字は、例示です。

STEP2の電子メールと、考え方は同じです。

・nihonnofujisan001は、google個人アカウントです。
・投稿用のメールアドレスが、Bloggerから与えられます。その時【任意の文字列】を設定します。

function sendMail(){
  const ss = SpreadsheetApp.getActiveSpreadsheet();
  const sheet = ss.getActiveSheet();
  const from = 'nihonnofujisan001@gmail.com';
  const to = 'nihonnofujisan001.【任意の文字列】@blogger.com';
  const subject = sheet.getRange(3,1).getValue();
  const body = sheet.getRange(5,2).getValue();
GmailApp.sendEmail(to, subject, body);
}

＜３＞なぜ30分以内？：

ブログ（ネット掲示板）をユーザーが見るのを30分以内、としているのは、ブログには、Push7からRSS連携：

赤字は、例示です。

https://nihonnofujisan001.blogspot.com/feeds/posts/default

を貼り付けています。こうしたRSSフィードは、様々なサービスがあるので、もっと短い巡回時間のものもあると思います。一応、Push7の巡回は30分以内となっています。30分以内は標準的かと思います。

ちなみに私は、Push7を、ブログ更新とは切り離した緊急通知用と、ブログ更新とリンクした一般通知用の２箇所に貼り付けています。

＜４＞全体のまとめ

１）配信数の制約に注意。緊急通知だけなら、会員700人以下なら無料で運用できそう。

現在、私は、全世帯が、3つから１つだけ選んで登録するとして、600〜700世帯を想定しています。トータルとしては、この３つのサービスで、お金をかけずに続けそうですが、自由に選んでもらうとLINEに集中するのでは。LINEの無料のワクは非常に小さいです。後でPush7やメールへ変更を促すことになるのでしょうかね。いずれにしても、緊急通知は一方通行、仮に事態が集中したとしても週２〜３回に収まるのではないでしょうか。

緊急通知の配信基準を設けておく必要があるでしょう。

例として、

・水害・土砂災害における避難警戒レベル３以上の発令に伴い、自治体から、当該地域あてに発出された情報。

・地域の災害対策組織の長（自治会長や町内会長など）が決定した配信情報。例えば、道路の陥没、建物の倒壊、断層など上部自治体の危険箇所情報からこぼれ落ちた地域住民向けの情報。

・事件事故の発生に伴い、警察消防から発出された、地域住民への警戒情報。

・その他、自治体から要請があり当該長が了承した緊急通知。例えば、同報無線の能力不足、故障時の支援も含む。

など。何がどう重なるか分かりませんが、不幸が重なったとしても週２〜３回で収まると、私は想像します。

しかし世帯数が1,000世帯を超えるようだと、レンタルサーバーを使うなど、有料にならざるを得ないのでは。

理想的には、500〜600世帯ごとに、このような仕組みが運営できれば、機動的でしょう。

２）異なったサービスだが、操作方法は統一する。その上で、一つ一つ、送信成功を確かめながら送るのがいい。

今回の、分散通知ですが、使用頻度が非常に低いです。防災などの緊急通知が主目的。そんな災害は頻繁にはないです。ですから、わかりやすく言えば、この仕組みの使い方を忘れた頃、突然、使うことになるのだと想像します。従って、覚える操作方法は一つだけにすること。そしてそれを、それぞれのサービスに適用して、送信出来るようにしておくのが重要だと考えます。

3) GoogleSSをアプリ毎に別ファイルにした理由

アプリ側はそれぞれ異なる会社のサーバーになります。全体が一箇所のトラブルに巻き込まれないように、GoogleSSは、シート別ではなく、ファイル別に用意しました。

4）目標：緊急通知を、スマホから、１３分以内で、７００人へ送る仕組みを、タダで作る。

今回、この目標を達成できたような気もしていますが、実用上、どうなるかはわかりません。

今回、私のブログを読んで下さった方は、私同様、開発費もタダにすることができると思います。これからも工夫改善は続きます。

STEP1へ戻る

以上

＜分散通知の仕組みを作る　STEP4: Push7のプッシュ通知＞
別ページで表示

LINEや電子メールは双方向の会話の機能があるので、「りんごちゃん」などニックネームで構わないが何らかのID情報が配信側に伝わります。しかし、利用者側には、それすら知られたくない人もいます。

Push7は、ニックネームすら入力不要、です。敷居が低いです。

Push7に似た仕組みは、既にネット上に溢れています。ふだんサイトを見ていると、ヒョコッと顔を出して、「登録しませんか」と誘いかけられ、即座に、×、拒否、NO、不要を返事する、それが条件反射になっているあれです（ブラウザの設定でポップアップを禁止に出来ると思いますが）。

今私は、緊急通知を準備しているので、ポップアップ禁止設定にしたおかげで目にも触れない、というのでは困ります。そこで、サイトの文面の中で、説明を加えて、ボタンを押してもらって申し込んでもらう手順にしています。このPush7のサイトへの設置方法の説明は、長くなるので、この記事では、割愛します。

このSTEP4における配信作業の流れでは、Push7のアプリは何も触りません。

Push7のアプリをスマホから触りたくない理由ですが、プッシュ通知を打ち込むまでの画面の操作が非常に扱いにくい点があります。アプ通知文がSTEP1で作成済みならば、STEP2、STEP3とやることはほぼ同じです。ChromeからGoogleSSを立ち上げる->PC版サイトを選ぶ->iphoneを横向きにする->閉じるをクリック->内容を一応点検したら「Push7投稿」ボタンをクリック。という手順。

Push7のいい点は、管理する側における、利用者の登録や削除については、作業は何もないです。

実に簡単です。

ポイント解説

＜1＞ GoogleSSへの取り込み

Push7で送信する内容のうち、毎回変更されるのは、タイトル、関係リンク、本文の３個です。

この画面には、Googleフォームへ入力した通知文が取り込まれるため、内容を確認するだけです。問題がなければ、「Push7投稿」ボタンを押します。

通知文の読み込み：

IMPORTRANGE関数を使います。
読み込みたいGoogleSSのURLが、下記のようになっていたとして、

https://docs.google.com/spreadsheets/d/【この部分】/edit#gid=0

【この部分】を以下の場所に当てはめてください。sheet1は実際のシート名、A10,A12,A14のところも実際のセル位置を当てはめてください。

Push7では、タイトル、関係リンク、本文の３データを、通知文GoogleSS から読み込んで、このPush7用GoogleSSへ取り込みます。

=IMPORTRANGE("【この部分】","sheet1!A10")
=IMPORTRANGE("【この部分】","sheet1!A12")
=IMPORTRANGE("【この部分】","sheet1!A14")

＜2＞APIの取得とGAS記述

APIの取得：

Push7は、親切に、API設置方法などが解説されています。

Push7 APIの利用　←この中の「Webプッシュ通知を送信するAPI」の項目が参考になります。

Push7は、メールアドレスとパスワードで登録できます。次に、プロジェクトを例えば「ABC会_通知」などとつけて設置すると、そのプロジェクトごとに、下記のように、App NumberとAPI Keyが発行されます。

GASの記述：

このままコピペください。赤字は、例示です。

・iconは、ここに指定した画像が選択されて通知に表示されます。
・urlは、表示された通知画面をクリックすると移動するサイトです。
・disappear_instantlyは、falseにすると画面の表示にタッチされるまでは表示が残ります。trueにすると数秒後には消えます。

const notifyPush7 = () => {
  const ss = SpreadsheetApp.getActiveSpreadsheet();
  const sheet = ss.getActiveSheet();
  const apikey = "【上画像のAPI Key】"
  const appno = '【上画像のApp Number】'
  const url = 'https://api.push7.jp/api/v1/【上画像のApp Number】/send';
  const headers = {
    'Content-Type' : 'application/json; charset=UTF-8',
    'Authorization' : 'Bearer ' + apikey,
 };
const data = {
'title': sheet.getRange(3,1).getValue(),
'body' : sheet.getRange(7,1).getValue(),
'icon' : "https://***.com/****.jpeg",
'url' :  sheet.getRange(5,1).getValue(),
'apikey' : "【上画像のAPI Key】",
'disappear_instantly' : false,
//'transmission_time": "2021/10/10 10:10"
//'query' : true,
}
const options = {
  'method' : 'post',
  'headers': headers,
  'payload': JSON.stringify(data)
};
UrlFetchApp.fetch(url,options);
}

具体的には、以下の、アプリによる送信画面を見て、対応関係を確認ください。

この「タイトル」「URL」「内容」の部分を、STEP1で作った通知文GoogleSSから、自動的に取り込むプログラムになっています。

次回のSTEP5は、Googleが提供するブログであるBloggerへ、同じ通知文を投稿する方法を説明します。割と簡単です。

STEP5

以上