本章では、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とMac miniのファイル管理システムにおいて、下の赤枠で囲んだ部分について紹介します。AppleシリコンのMac miniを常時稼働してサーバーのように使う人が、これからどんどん増えるように思えます。そうなってくると、今回紹介するミニシステムは、定番の一つになると想像します。

Xserverにあるデータをローカルへバックアップする(SFTP、SSH接続)

Xserverは、契約すれば無料で１週間分のバックアップがついてくるから、なんでわざわざローカルにバックアップなんか必要なの？

そのような疑問は確かに起こります。

Xserverの無料バックアップからの復元は、復元を申請したあとに心配がおきます。つまり、いつ処理が開始していつ頃終了するのか分からないので、ただ待つしかないのです。私の経験からは30分で済むこともあれば3時間かかることもあります。時間が読めないこと、それは結構ストレスです。またその時間を大幅に短縮したいです。出来れば10分以内。そのためには、前夜の状態のファイルがローカルにバックアップされていれば大丈夫でしょう。そのバックアップするフォルダは、WordPressのフォルダが対象なので、uploadsとthemesがあれば十分でしょう。

以前に、Transmit5のFTPを使ってXserverへアップロードする方法を紹介しましたが、今回は、Transmit5のSFTPすなわちSSH接続を使って、Xserverからダウンロードを行う方法、しかもそれを自動運転にする方法を紹介します。

なかなかMacを使ったSFTP、SSH接続の日本語での解説ブログやYouTubeは見当たりませんね。

５手順と長くなりますが、よろしくお付き合いください。

ポイント解説

手順１ 　XserverのSSH接続を開通させる

（１）　MacでSSHキーを作成
以下を行うと、id_rsa（秘密鍵）とid_rsa.pub（公開鍵）が作成されます。

（２）　公開鍵をXserverに登録

id_rsa.pubの内容をコピーして、Xserverの管理画面に登録します。

１）id_rsa.pubは、隠しファイルになっているので、Finderの右上の虫眼鏡にid_rsa.pubと入れて、見つけてください。それを、テキストエディット.appで開く→内容をコピー。

２）Xserverのサイトに入る→サーバーパネル→SSH設定をON

 初期設定の段階なので、とりあえず「ON[すべてのアクセスを許可] 」を選択します。
※2024/11/25現在、国内からのアクセスのみ許可に変更

（３）公開鍵登録・更新→（２）１）でコピーした公開鍵をペースト→確認画面へ進む→登録する。

（４）　接続の確認

ターミナルへ以下を入れて接続してください。

Xserverの場合、

となります。

接続が成功したら、一旦、ターミナルはexitを入れて終了してください。

手順２　Transmit5アプリを使って、SFTPにて、単独でバックアップできるようにする

赤く消してあるところは、ユーザ名が入ります。１（１）で作成した秘密鍵、id_rsa、を、パスワードまたはキーの右側のキーのアイコンをクリックして認証鍵を入れるボックスを開き、その中に登録します。登録は、このボックスの下にある＋のマークをクリックすると、親切に通常は非表示のフォルダも表示されてid_rsaが選択出来ます。登録されたらid_rsaの上をタップすると、キーに収まります。
XserverにおけるSSH設定の条件はここに記載されています。

上と同様に、SFTP_uploadsも作成します。

手順３　バックアップ用のアプリを作る

上で作った単独バックアップを起動させて動作した後に終了する流れを、Automatorで一つのアプリとして作成します。まず、SFTP_themesは以下です。

Automatorで新規作成→アプリケーションを選び、Transmit.appを選びます。接続先の選択肢にTransmit5にお気に入り登録したものが出てくるので、SFTP_themesを選びます。すると、サーバ、ユーザ名、パスワード、ポート、プロトコルは、引っ張ってきて入ります。それ以下の項目は設定します。

同期の方向：ダウンロード（今回の場合はダウンロードです。ここは要注意！！）

比較の方法：変更日

スキップ項目：なし

ローカルパス：これは、Finderで探して設定します。自分があとで扱いやすい場所。

オプション：同期先のみに存在する項目は削除する。（単純なバックアップ目的のダウンロードは、チェックを外します）

リモートパス：リモートサーバとの時差を自動で調整する。一応チェックを入れておきます。

処理が済んだら、Transmit5を終了→Automatorを終了します。

次に同様に、uploadsフォルダのダウンロードである　SFTP_uploadsも同様に設定します。このように小分けする理由ですが、ダウンロードは結構、エラーが起きやすく、あまり大きなフォルダですとやり直しに多大な時間が掛かります。ですので、例えば初期ダウンロードで１０分程度で済むサイズで区切るとか、小分けにした方がいいです。

手順４　複数の単独アプリを流れとして組む

Automatorで作成した単独アプリを流れとして組み込みます。なお、完了の通知としてメールを使います。夜中の自動処理を設定すると、本当に処理が行われているかどうか心配になります。メール一つあるだけで安心します。

AppleScriptを使います。まとめたアプリをSFTP_themes_and_uploads.appとします。

手順５　自動処理させるために、カレンダーに組み込む

Macのカレンダーには、「通知」の機能の中にあるカスタムに、「ファイルを開く」がありここでアプリを起動することができます。

カレンダーからは、アプリは起動するだけで、終了の動作は行いません。終了の動作は、取り付けるアプリの中に組み込まれている必要があります。

開始：日時

終了：日時　ここは、時刻は開始時刻と同じで構いません。

繰り返し：毎日

繰り返し終了：なし

移動時間：なし

通知：カスタム

ファイルを開く　SFTP_themes_and_uploads.app これはアプリケーションフォルダから選択、予定の開始時刻を選択

次に、

Macのシステム設定→プライバシーとセキュリティ→カレンダー→SFTP_themes_uploadsのオプションからフルアクセスにする→カレンダーを終了して再度立ち上げます。

その他、まとめ

SFTPによるダウンロードですが、禁止文字の使用など様々な理由でエラーで進まないこともあります。その場合、Xserver内で、zipファイルに圧縮してからrsyncでダウンロードすると、順調に行くことが多いです。

Xserver内に圧縮zipファイルを作成する→次にMacのrsyncでダウンロードする方法。

以上が、定期的自動的に、外部サーバーにあるデータを、ローカルにダウンロードする流れになります。こうした処理が自宅で簡単に行えるようになってきたのも、Macが、特にMac miniが省電力になり、常時稼働が可能になってきたことが大きいです。

以上

SynologyNASとM1 Mac miniによるファイル管理システムを動かすにあたり、前回は、Jump DesktopによるiPad iPhoneからM1 Mac miniのリモート操作を紹介しましたが、それは実は頻度は低く、実際は90%以上は、今回紹介する、画面共有によるM2 Mac miniからM1 Mac miniのリモート操作になると思います。

あと、いつもいつも、M2 Mac miniと書くのも面倒なこともあり、要は、「Mac」と一言で括れる共通事項については、面倒に感じた時はMacと書くようにします。小さい話です。

ただ、モニター、マウス、キーボードといった周辺機器が何もないのがMac miniですし、省電力になり常時稼働が平気になったのがM1以降ですので、M1 Mac miniが裸っぽの原点になります。M1以降ならMacbookなどラップトップも全てavailableなチキチキマシーンです。

それでは中身に入ります。

ポイント解説

MacからMacを操作する方法には、Appleが提供するものとしては2つあって、一つは今回の「画面共有」ですが、あと一つは「リモートマネジメント」があります。「リモートマネジメント」は本格的な方法で専用アプリが必要になります。「リモートマネジメント」は大規模な企業ネットワークでIT担当者が使用するような仕組みなので、ちょっと縁遠いです。自宅でDIYできる範囲が、私のテリトリーです。

１　STREAM DECKの利用

スクリプト要約：画面共有アプリを自動操作し、指定Mac（yyyyyyyy-macminim1）へ接続するAppleScript。アプリ起動後3秒待機し、メニューバーから最近接続先を選択。接続確立まで待ち、パスコード「<あなたのパスワード>」を自動入力してEnterを押す。その後、ウィンドウ表示を待ってフルスクリーン化する一連の手順をスクリプト化している。

STREAM DECKに画面共有を立ち上げるスクリプトを登録しています。その理由は、画面をスムーズに立ち上げるために、手順と細かいチューニングを決めておきたいからです。主なものは２点あります。

一つ目は、パスコードを入れる前の待ち時間のチューニングです。パスコードも自動で打ち込むようにしてあるのですが、タイミングが合わないと画面が止まってしまいます。例えて言うと、電車の出発が早すぎると、乗り遅れてホームに置き去りにされたままになってしまいます。そこで電車を遅らせます。一応delay５秒にしておきます。もちろんその、次の電車に乗ればいいわけで、つまり少々待って、もう一度自分でSTREAM DECKのボタンを押せば、大抵OKとは申せますが。

二つ目は、ウインドウをフルスクリーンに設定することです。その理由は、起動した最初は、ウインドウは画面上に浮いたような状態でして、これですとカーソルがウインドウの中と外を行き交うので少々脳細胞が混乱してストレスです。割り切ってウインドウをフルスクリーンにして固定した方がマウスの操作がラクです。画面共有を立ち上げると、画面共有という名のデスクトップが追加されるので他のアプリへの支障はありません。

細かい話になりますが、スクリプトの最後のステップに、ウインドウをフルスクリーンにするアクションがあります。その際、フルスクリーンボタンの番号は、表示場所とは必ずしも一致しない点は、記憶に留めておくと良いでしょう。現状、ウインドウのボタンは3つ並んでいます。そのうちで今回目的のフルスクリーンのボタンは右端にあります。3つあってそのうち右端なので、ふつうは、１または３だな、と思うじゃありませんか。ところが違うのですね。正解は２です。今のところ、そのような仕様になっています。試行錯誤で見つけ出すことになります。

２　そのまま相手を再起動できる

M1 Mac miniが重いような気がした時、再起動をしますよね。再起動ができるのです。M1 Mac mini画面の左上から再起動をしますと、なんと画面共有を維持した状態で、そのまま戻ってくれます。これが実に快適です。

３　フルスクリーンの分離はマウスで上端を押し上げる

作業性の関係で、この共有画面を分離して、一つのウインドウで表示したい場合があります。その場合に、ちょっとコツが要ります。まず、マウスで画面の上端を持ち上げるようにするとバーが出てきます。そのバーの左にある緑のボタンを押すと、フルスクリーンの解除ができます。

４　まとめ

MacからMacをコントロールするのが、やはり一番相性がいいですね。

以上

Jump Desktopというアプリを使って、iPadからMacの操作が出来ます。

App Storeで購入ができます。24年11月現在、円安のせいか2,200円(買い切り)と高めになっていますが、同じAppleIDなら複数台のiPad、iPhoneからアクセスできますので、それなりにお得感はあります。JumpDesktop以外にも、こうしたリモート操作のアプリはあると思いますが、安全を考えてApp Storeから購入するのがいいと思います。

iPad miniやiPhoneでは、たくさんの作業は疲れるでしょう。

こうしたリモートでの変更作業も、本当は、iPad miniやiPhoneで行えればいいのですが、ピンポイントの修正作業だけであればそれでいいのですが、修正数が多くなると小さくて疲れると思います。上の動画ではiPadPro12.9を使っていますが、これであれば、ピンチアウトを使いながら、まずまずサクサクと操作が出来ます。一瞬、マウスの右クリックの代替はどうする？！と迷いますが、2本指でタップすると代替になります。

以上

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

音楽制作や動画制作では、アプリのバグに振り回されて、結構、頻繁にフリーズして、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からの画面共有(スクリプト📒)の形にしています。共用のモニター、キーボード、マウスで操作しています。

以上

字幕の作成に関する問題ですが、それは、規格が統一されていないことに尽きる、と言っていいです。動画を作成する人は、それに振り回されています。

その字幕作成の悩みの一つが、スマホなどの小さな画面を使って、解説の動画を視聴してもらおうとすると、字幕が邪魔になることです。その解決策として、既に、字幕を動画枠の外に表示する方法は紹介してきましたが、この動画では、字幕の背景を透過させる設定方法を紹介しています。

なお、WordPressプレーヤーを使用する場合は、以下の方法で、デフォルトで透過率を設定することができます。

video::cue {
  background-color: rgba(0, 0, 0, 0.5); /* 背景を黒で透過率50% */
  color: white; /* 字幕の文字色を白に設定 */
  text-shadow: 1px 1px 2px rgba(0, 0, 0, 0.5); /* 文字に影を追加 */
}

上のコードを、WordPressのカスタマイズ->追加CSS、へ追記して、公開のボタンを押します。

以上

以前のブログでは、有線接続の有用性について解説しました。その中で、一つの完成形として、Mac、iPad、iPhone、Webカメラなど複数デバイスを有線接続した方法について、紹介しました。これは、その実施動画です。接続方法は以下の通りです。

OBS Studioは、配信に使う以外にも、こうした動画作成にも、非常に役に立ちます。

以上です。

25.6.25追記：
M2 Mac miniに、iPadを３つ目のディスプレイとして使う方法、を追記しました。

WiFiは、固まったり寸断することがあります。また、今回は家の中にあるMacとiPadの繋げ方の改善なので、直接は関係ないですが、一般にスピードが不安定です。さらに、微弱ではありますが電磁波の被曝も生じます。

100Mも離れているがゆえ不安定なのは仕方ないとしても、今回MacとiPadはすぐ隣りに至近距離で置いてあるわけです。サブディスプレイとして使おうとしています。すぐ隣にありながら、不安定、繋がらない、繋ぎ方が難しい、それはどこかで聞いた人間関係のようで、よくある話といえばそんなものでしょうか。いえいえ、これは物理の問題。ヘンテコリンなことと感じます。

よく考えてみてください。お月様まで電線を結べますか？

基本的な考え方は、「遠い」は無線、「近い」は有線です。

というか、まずは、有線接続が基本です。

さて、よく知られているアップルの魅力として、アップル製品同士はなにも用意しなくても無線でサクッと繋がることにありました。しかし今回大事な発想は、一度アップル製品であることを忘れて、MacとiPadをケーブルで繋げる。ただそれだけのことをやってみます。

2つの実現

それは１つ目は、Macの映像をiPadで映すこと。2つ目は、iPadの映像をMacで映すことです。

ポイント解説

１　[1]の方法〜Macの映像を、iPadに表示する。

第1は、iPad(iPadOS17.3)をMacの拡張ディスプレイにする方法です。（Macをミラーリングすることもできますが、Macの映像と同じものを小さいiPadの画面で見る意味は殆どありません。家の中では。）アップルがおすすめの方法はSideCarです。SideCarで有線接続に切り替えることもできますが、最初にWiFiで無線接続してからその後で有線に切り替えるやり方になります。これがなかなか厄介でして、SideCarは、Macを再起動した後に、そのまま有線接続が有効になってiPadの画面にMacが表示されるかというと、そうならない、
メニューバーの「画面ミラーリング」から接続する必要があります。ストレス！
設定を触っていると、BluetoothをONにしてくれ、WiFiをONにしてくれ、インターネットに接続してくれ、だのと、隣にあるものに対して、なんでそんなに色々必要なのかとイライラ、ストレス！

やっぱり、「ケーブルつなげてサクッ」といきたい。

以下の図をご覧ください。

今回、Macの「画面ミラーリング」は使わず、いきなりケーブルで接続します。

なお私はCamXアプリがシンプルでいいと選びましたがCamo Studioもいいと思います。

ただ残念ながら、このCamXアプリを使って、長時間、Macの拡張ディスプレイとして放置しておきますと、つまり常設すると、Macがだんだん重くなってきて、Macを再起動するということが時々あります。従って、この使い方は、一時的にiPadを代用する使い方になろうと感じます。

器具類やアプリなどを購入して時間を費して、あれこれ工夫するより、最近非常に安くなった単機能のモニターを購入して、直接、Macと接続するのもありだと考えます。iPadはiPad本来の使い方で活かす、ということでしょう。

２　[2]の方法〜iPadの映像をMacで表示する。

第2の方法、iPadをMacへ映すことですが、iPad miniやiPhoneの映像を拡大してみたい、さらにその映像を録画共有したい場合に使うことになります。これも有線接続なら無線接続より簡単です。Thunderboltケーブル(※1)を挿し込むだけです。あとはOBSやQuickTimePlayerからiPadを選択して表示します。

突然、接続解除のストレス

このThunderboltケーブル接続で、第1の拡張ディスプレイも兼用出来ないのか、つまりiPadの映像を→Macで表示、だけでなく逆方向のMacの映像を→iPadで表示、も使えないのか、ということですが、Mac設定の「画面ミラーリング」で「個別のディスプレイとして使用」を選択すれば、Macの映像を→iPadで表示、Macの拡張ディスプレイとして使えます。但し、iPadの映像を→Macで表示、Mac側からiPadの映像をキャプチャリングするアプリ(例えばOBSやQuickTimePlayerなど)を立ち上げると、「画面ミラーリング」の方法では、突然、接続解除になってしまいます。OBSの場合ですが、シーンの一つでiPadをキャプチャーするようにしてあって、ただしそのシーンを選択していない状態であっても、あるいはiPadを非表示にしても、接続解除されてしまいます。つまりOBSを何か別の使用目的で立ち上げても、そのOBSの設定のどこかにiPadキャプチャーが登録されていると、それに影響を受けて接続解除されるということですので、ストレスが大きいです。

日常は[1]の方法で使用するようにして、iPadの画面をMacの画面の中で録画したい、その時だけは[2]の接続に変える、そのように使用するしかありません。

※1 Thunderbolt3と4があります。

３　拡張ディスプレイは日常的に使える道具。

第１の方法について、詳しく見てみます。
下図をご覧ください。拡張ディスプレイ用ケーブルを挿し込む→CamXアプリ(無料)を起動する、ただそれだけで、下図の状態になります。

このままの状態でiPadとしても拡張ディスプレイとしても両方使える点が素晴らしいです。マウスでiPadアプリの操作、Mac間のアプリの移動が行えます。マウスは手元でMac,iPadが切り替えられるタイプが非常に便利です。

但し、iPadを拡張ディスプレイとして使った時の、解像度は、やはり純正の「画面ミラーリング」を使った方がクリアで見やすいです。

その感じに近づくように調整しましたが、2箇所あります。１つ目は、Mac側のシステム設定→ディスプレイ→拡張ディスプレイで、使用する解像度を1344×1008にすること。２つ目は、iPadのCamX→画像設定でズームを35程度にすることです。

４　単機能モニターとiPadの両方使うスタイル。

その１

単機能モニターの価格が安くなっており、16インチでも20,000円以下になっています。こうなってくるとアプリやケーブルに出費して設定に苦労するより、モニターを買ってしまった方が得策と感じます。実際、私の場合、単機能モニターとiPadを両方使うスタイルになっています。以下の方法ですと、iPadは通常は、独立して使用して、iPad,iPhoneの画面をMacに表示したいときは、Mac側でOBSやQuickTimePlayerを立ち上げて行います。

さらにこの方法ですと、Windows RemoteでWindowsPCをMacから開いて、Windowsを単機能モニターに表示して操作することも出来ます。

さらに、その後、改善したのが以下の状態です。

↓25.6.25追記

その２

上の2の[2]で、Thunderboltケーブル接続１本で、双方向、つまり「MacをiPadへ映す＆iPadをMacへ映す」を実現できれば嬉しい。と書きましたが、Macの場合、Ethernetをインターネット利用では優先させながら、WiFiネットワークを稼働させることを今更発見しました。　ネットワーク設定の中の、右下をクリックして、「サービスの順序」において、Ethernet類を上の位置、Wi-Fiを下の位置に、配置すれば、両方接続済みの場合でも、インターネット接続はEthernet接続が優先されます。

通常、M2 Mac miniは、外部ディスプレイは2台まで可能なのですが、iPadを使うことにより、外部のアプリを使わず、純正の「画面ミラーリング」機能だけで、３台のディスプレイを映すことができるようになりました。ただし欠点としては、Amazon Video、NHK+(他にもあるかも知れない)は、視聴できないこと、動画類は他のアプリのキー操作でカクつくこと、などがあります。

時々、「接続が切れました」となりますが、数秒でつながり元の画面に戻ります。

普段は、iPadはiPadモードで使うのがベターです。

↑25.6.25追記

　その他

下写真は、二種類のケーブルです。

ご参考にどうぞ。

以上