それで、さあいよいよ、Adobeキャラとおさらばしようとして、ちょっと触ってみて、あれ〜〜意外。まだ、使えるじゃん。と気づいたのです。

Adobeのソフトは、どうしても「毎月の課金が必要」というイメージがありませんか？

でも実は、無料の会員状態でも「Adobe Character Animator」でキャラクターを動かすことができるのですね。

今回は、私が実際に検証してみた様子を動画とともにお届けします。

🎬 まずは検証動画をご覧ください！

💡 検証：有料プランなしでも本当に動くの？

現在、私のAdobeアカウントは有料プランを解約済みです。

アカウント管理画面を確認しても、はっきりと「有料プランがありません」と表示されています。

「じゃあ、ソフトは開けないよね？」と思いきや……

Creative Cloudのアプリ一覧から「Character Animator」を開いてみると、なんと普通に起動できてしまいました！

🛠️ 無料状態でどこまでできる？

実際にソフトを触ってみたところ、ただ起動するだけではなく、以下のような操作も問題なく行えました。

• パペットの操作: 今回は「Dr. AppleSmith」というキャラクター（パペット）を使用。ちゃんと動きます！
• 録音・録画: 普通に録音・録画機能が使えます。
• クロマキー処理: フィルターからクロマキーを入れて、グリーンバックを透過する設定も可能。四隅の角を取って調整する作業もできました。

動画内で私がやっているように、無料会員であっても、基本的なアニメーション制作の環境は整っているようです。

🧐 なぜ無料で使えるの？

実は、画面の右上をよく見ると「スターター」という文字が表示されています。

Adobe Character Animatorには、誰でも無料で基本的な機能を使える「スターターモード」が用意されているんです。（※Adobeアカウントの無料登録自体は必要です）

これなら、「ちょっとキャラを動かしてみたい」「VTuberみたいなことをお試しでやってみたい」という人でも気軽に始められますね！スターターモードといっても、Adobeはセンスがいいから、どれも使い物になりますよ。

⚠️ 使う上での注意点

現時点では無料で快適に使えていますが、いくつか気をつけておきたい点もあります。

1. いつ仕様が変わるか分からない: Adobe側のアップデートや仕様変更により、突然使えなくなる機能が出てくる可能性はゼロではありません。
2. ウォーターマーク（透かし）の可能性: 今後の書き出し時に、無料版特有のロゴやウォーターマークが入るようになる可能性も考えられます。

📝 まとめ

結論：無料のAdobe会員状態でも、Character Animator（Starterモード）は使えます！

いつまでこの状態で使えるかは分かりませんが、気になっている方は無料で使える今のうちにぜひ試してみてください！
とはいうものの、私は、自作パペットに舵を切っていきます。

コードと要約(クリック)

要約：本システムは、AppSheetとPythonスクリプトが連携し、Googleスプレッドシート上のメタデータに基づき動画・音楽ファイルをBunny CDNへ自動アップロード・管理する。 AppSheet側では、動画ファイル（mp4等）で「bn低画質動画単独生成=TRUE」かつ「bnステータス=処理待ち」の条件を満たすと、「Bunnyファイル生成更新」アクションが起動する。 MacのLaunchAgent (`com.XXXXXX.bunny_factory.plist`) により60秒ごとに実行されるPythonスクリプト`f1_bunny_factory.py`は、スプレッドシートを監視。システム設定のマスターSWが「ON」の場合に、「処理待ち」のレコードを検出する。 検出されたファイルは拡張子に応じ処理される。動画ファイルはBunny Streamへアップロードされ、動画IDとストリーミングURL（高画質・低画質）を生成。音楽ファイルはBunny Storageへアップロードされ、エンコードされたファイル名と直接アクセスURLを生成する。 アップロード後、スプレッドシートは新しいURLなどで更新され、「処理待ち」ステータスが「完了」となる。同時に、スプレッドシートに残る古い動画IDやファイル名が存在すれば、Bunny CDNからそれらを削除し、ログに記録する。これにより、Bunny CDN上のコンテンツが自動で最新に保たれる。

公開スクリプトに関するお問い合わせは以下へ↓

動画は、Bunny CDNを使っています。プレーヤーはWordPress備え付けをカスタマイズしています。

はじめに

今回は、少しマニアックな動画配信の裏側の話題です。 長年愛用してきたVimeoですが、3月頃に「Plusプランが廃止の方向」という記事を目にしました。それに伴い、現在月額750円程度の料金が、1,200円程度に値上がりする方向だそうです。私の動画配信の利用レベルからすると、これは明らかな無駄遣いになってしまいます。 「いよいよVimeoの代替を探す時が来た」と決断し、日頃から頼りにしているGeminiなどのAIと相談しながら、今回の移行作業を進めてきました。

１　コスパ最強のCDN選び：Bunny vs Cloudflare

移行先を検討する上で、最終的な候補に残ったのは「Bunny CDN（Bunny Stream）」と「Cloudflare Stream」の2つでした。両者のコストパフォーマンスを比較した結果、私はBunny CDNを選択しました。

Bunny CDNの最大の魅力は、月額の最低料金がたったの1ドル（約150円）であることです。 支払いの仕組みは「デポジット制」を採用しており、自動チャージと手動チャージが選べます。感覚としては交通系ICカードのSuicaと同じです。私は手動チャージにしてあります。デポジット残高が少なくなると通知が来るはずです。 これによって、Vimeoをこのまま放置していれば月額1,200円かかるところを、Bunny CDNなら月額150〜300円程度にまで節約できそうです。小規模な個人運営にとって、このコスト差は圧倒的です。

２　料金だけじゃない！「自動トランスコード」と「直リンク」の解放

Bunny CDNを選んだ理由は、単に安いからだけではありません。 Vimeoの大きなメリットであった「視聴者の環境に合わせて画質を調整する自動トランスコード機能」を、Bunny CDNもしっかりと備えています。

さらに決定的な違いが、ストリーミング配信用（.m3u8）の「直リンクURL（ダイレクトURL）」がそのまま使える点です。 Vimeoのような大手サービスでは、専用のプレーヤーを通すことが強制され、カスタマイズが困難でした（例えば、字幕一覧から特定のシーンへジャンプするなど）。しかし、直リンクが解放されているBunny CDNなら、自作のテンプレート（dr52.phpなど）を使って、オリジナルの自由な配信の仕組みを完全にコントロールすることができます。

３　英語の壁は「AIのサポート」で乗り越える

Bunny CDNを導入する上での唯一の難点は、サービス画面やマニュアルがすべて「英語」であることです。 しかし、今の時代、GeminiやChatGPTといった生成AIにサポートしてもらえば、英語はまったくハンデになりません。設定で分からないことがあればAIに聞き、PythonやAppSheetのシステム構築もAIと二人三脚で進めることができます。この強力なサポートがあれば、高齢者であっても最先端のインフラを構築することは十分に可能です。

４　複数の配信所を切り替える「マイライブラリ」の完成

今回の移行以前からですが、私が構築した「マイライブラリ」システムは、状況に応じて複数の配信サーバーを瞬時に切り替えられるようになっています。

それぞれのサーバーには特徴的な役割があります。

• Dropbox(1)：動画の製造工場からの「産直（ダイレクト配信）」。
• Bunny(2)：今回追加、自動トランスコード付きの配信所。
• Xserver(3)：安全で安定したWordPressの「メインのホスティングサーバー」であり、配信を振り分けるルーティングの中枢。
• pCloud(4)：買い切りプランを活かした「保存倉庫」。

もし配信にトラブルが起きても、Xserver、pCloud、Dropboxへ速やかに切り替えることができます。 ここに、強力なCDN配信所として「Bunny CDN」が加わった形になります。このような柔軟で自立したエコシステムが完成した今、私がVimeoなどの大手プラットフォームに依存し続けるメリットは殆どなくなりました。

５　もし再生数が多過ぎたら、その動画をYouTubeへ隔離。など自由自在。

そんなことはないとは思いますが、もし動画に過度に人気や関心が集まり再生数が増大してしまい、Bunnyの料金負担が重いと感じるようになってしまったとします。具体的には月2$(300円)を超えるような場合です。その場合は、その動画を特定して、残念ながら広告が入るかも知れませんが、その動画をYouTubeへ隔離するようにしたいと思います。私にとっては例外的な出来事になりますが、さりとて、その動画は、公共の道具であるインターネットを通じて公開してきているわけですので、観たい聴きたいというニーズに対しては、応えていく必要はあると思います。

また、BunnyのStreamとして保存したGB数の上限を自分で決めて、それを超えた場合は、古いものについては、Bunnyから除去して、ファイル選択もBunnyを外して、標準の拡張子別の再生に切り替えるようにすることも考えています。

このようにマイライブラリを使うことにより、出費をコントロールしながら、自由自在に、動画の配信所の選択ができるわけです。

おわりに：世界情勢が物語る「脱・依存」の重要性

特定のプラットフォームにすべてを預けてしまうと、規約変更や大幅な値上げ、あるいはサービス終了の際に、自分のメディアが人質に取られたような状態になってしまいます。最近の世界情勢が物語っているように、何か一つの場所やサービスに過度に依存しないことは、情報発信においても非常に重要です。

Vimeoからの卒業は、まさに自分の資産を自分自身でコントロールする自由を手に入れるための、最良の決断でした。これからも色々工夫して、このブログの、無料かつ非営利の配信を堅持していきます。

今回は、Webカメラとマイクを使って、自分の顔の動きや声に合わせて画面上の動作人形（パペット）を動かせる「自作パペットシステム」をご紹介します。
「自分専用のオリジナルアバターを、もっと手軽に動かしてみたい！」という思いからPythonで開発を進めていたシステムですが、前回の記事の内容に改良を加え、やっと誰でも簡単に使えるパッケージになりました。
この辺で、Adobeのパペットにバイバイして、Adobeのサブスクをキャンセルすることにします。

今回はサンプルパペット付きのアプリ（ZIPファイル）を無料公開します。プログラミングが分からない方でもすぐに使えるように工夫したので、ぜひダウンロードして試してみてください。

✨ 自作パペットシステムの3つの特徴

1. Webカメラとマイクだけでスルスル動く

高価なトラッキング機材は不要です。Macの内蔵カメラ（またはWebカメラ）が自分の顔の傾きを認識し、マイクが声の大きさを拾って、パペットがリアルタイムに連動します。

「あいうえお」の口の形にも対応しており、まばたきや視線の移動も自動で行います。

2. 専用の設定画面（UI）でカンタン調整

以前はプログラムのコードを直接書き換える必要がありましたが、専用の「司令塔」となる設定画面を用意しました。

「マイクの感度」「パペットの大きさ」「顔の傾き具合」などを、数値で直感的に微調整できます。自分好みのセッティングを見つけたら、キャラクターごとに保存しておくことが可能です。

3. スペースキーでいつでも正面をリセット！

使っている途中で「ちょっと顔の向きがズレてきたな…」と思ったら、スペースキーをポンッと押すだけ。その瞬間の自分の顔の位置を「真正面」として再設定（キャリブレーション）します。

📥 ダウンロードと使い方

以下のリンクから、一式がまとまったZIPファイルをダウンロードしてください。

👉ダウンロード(Macのみ)(無料・許諾不要)

使い方の手順（※Mac専用です）

使うためには、お使いのMacに「Python」が入っている必要があります。（入っていない方は公式サイトからインストールしてください）

1. ダウンロードしたZIPを解凍し、フォルダを開きます。
2. 初回のみ、フォルダ内の『はじめにお読みください.txt』の手順に従って、必要なAIパーツ（MediaPipeなど）をインストールします。（※ターミナルにドラッグ＆ドロップするだけです！）
3. 準備ができたら、**「自作パペット起動.command」**をダブルクリック！
4. 設定画面が開くので、キャラクターに「サンプル」を選んで「起動」ボタンを押せば完了です。

※初回起動時はMacのセキュリティで弾かれることがあります。その場合はファイルを「右クリック」→「開く」を選択してください。カメラのアクセス、マイクのアクセスの許可を求められたら「許可」を選択してください。

🎨 応用編：オリジナルのパペットを自作しよう！

今回お配りしたフォルダの中には、run_assets/サンプル という場所に、パペットのデザインの元になった 「サンプル.pxd」 というファイルが入っています。

Macの画像編集ソフト「Pixelmator Pro」をお持ちの方は、このファイルを開いて自分の好きな絵に描き換えるだけで、完全オリジナルの自作パペットを作ることができます！

さらに、Pixelmator Proから画像を書き出してパペットを起動するまでを「ワンクリック」で全自動化する裏技（AppleScriptとAutomatorの連携）も開発しました。私は、サブスク版ではない、以前からある単発アプリを使っています。もしサブスク版で「パペット書き出し起動.app」がうまく動かなくなった場合は、Automatorで作成したAppleScript内の tell application “Pixelmator Pro” という1行を、新しいサブスク版の正確なアプリ名に書き換えるだけで解決します。

コードや詳しい仕組みに興味がある方は、こちらのページにスクリプトを公開していますので、ぜひ覗いてみてください。

コードと要約(クリック)

要約：このシステムは、顔認識と音声入力を利用してリアルタイムで動作するデスクトップパペットを実現します。 run_ui.pyは、パペットの各種設定を行うGUIアプリケーションです。キャラクターの新規作成、複製、選択、そしてボリューム閾値、グローバルスケール、顔の傾き制限、目の感度、カメラ/マイクIDといったパラメータ調整機能を提供します。これらの設定はキャラクターごとにJSONファイルとして保存されます。 run_puppet.pyは、UIで選択・設定されたキャラクターとパラメータに基づき、実際のパペット動作を制御するスクリプトです。OpenCVとMediaPipe Face Meshを用いてカメラ映像から顔の傾き、目の動き、口の形を検出し、マイクからの音声ボリュームと連携させてアバターの頭の回転、視線、口の動きをリアルタイムで再現します。キャリブレーションデータもキャラクターごとに保存されます。 Automatorスクリプトは、これらのPythonスクリプトの実行を補助します。「自作パペット起動.app」は設定UIを立ち上げ、「パペット書き出し起動.app」はPixelmator Proで開いているドキュメントの各レイヤーをPNG画像として書き出し、キャラクターごとの設定JSONを自動生成した後、該当するパペットを起動する一連の処理を行います。これにより、Pixelmator Proでの画像編集からパペット起動までがスムーズに連携されます。

公開スクリプトに関するお問い合わせは以下へ↓

PixelmatorProによるパーツの変更をパペット起動アプリに即座に反映している動画を以下に掲載します。

💡 OBSでリアルタイム配信に使いたい方へ

このパペットシステムは、OBS Studioを使ってリアルタイム配信などの画面に合成することも可能です。

ウィンドウキャプチャでパペットの画面を取り込み、背景（グリーンバック等）を透過させればOKです。

【ワンポイントアドバイス：音ズレの直し方】

映像の処理には少し時間がかかるため、OBS上で「声（マイク）」に対して「パペットの口の動き（映像）」がわずかに遅れて見えることがあります。

その場合は、OBSの「オーディオの詳細プロパティ」から、マイクの「同期オフセット」を「200ms〜500ms」ほどプラスに設定して、声をわざと遅らせて映像に合わせると自然になります。私は今500msに設定しています。

おわりに

自分が描いたイラストが、自分の動きに合わせて滑らかに動く体験は、何度やっても感動します。それではご自由に利用ください。

最近、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形式で送信し、更新処理を実行する。
⬇️＜マイライブラリ生成更新処理＞ この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章を読む

🔗 目次ページへ戻る

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になります。

以上です。