動画の字幕作成については、これまで何度も試行錯誤を繰り返してきましたが、「これだ！」と思えるおすすめの方法を見つけました 。

今回は、Googleの生成AI（Gemini）の「Gem共有（カスタムAIエージェント）」を活用して、高精度なVTT字幕を生成するプログラムを作成しましたので紹介します 。

最大の特徴は、サブスクリプション不要（無料）で実践できるという点です 。（※Googleアカウントは必要です 。）

Geminiの文字起こしはマルチモーダル処理のため、精度は非常に高く、後から手直しする手間が劇的に減ります 。無料枠の制限を賢く回避しつつ、面倒な作業は、Macクイックアクションで自動化する、実践的なワークフローを公開します。

解説動画をご覧ください。

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

要約： 「VTT作成用に動画を分割する」ワークフローは、ユーザーが指定した基本秒数を基に、動画を無音区間で自動分割し、VTTの「秒ずらし」に役立つオフセット記録を生成します。ffmpegとPythonスクリプトを連携させ、再エンコードなしで高速分割します。 「字幕時刻の秒ずらしを行う」ワークフローは、選択したVTTファイルの全タイムスタンプを、ユーザーが入力した秒数だけシフト（前後にずらす）させ、新しいVTTファイルを出力します。awkを用いて精密な時間計算を行います。 「VTTの連番を付け直す」ワークフローは、VTTファイル内の古い連番や不要なヘッダを削除し、字幕ブロックに正しい連番を振り直して整理されたVTTファイルを生成します。 これらのワークフローは、それぞれ動画の分割、字幕の時間調整、字幕ファイルの整理という異なる課題に対応し、VTT作成・管理作業を自動化・簡素化することを目的としています。

添付の動画の音声から字幕用のvtt形式のコードを出力します(Gem共有)。

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

ポイント解説

解決すべき課題：Geminiの「5分の壁」

Geminiに動画を読み込ませて文字起こしをする際、特に無料アカウントでは「動画は5分以内」という制限があります 。 今回紹介するワークフローは、事前の「動画分割」と、事後の「タイムスタンプ調整（秒ずらし）」を組み合わせることで、この壁をストレスなく突破します。
有料会員でも使用制限を超えた時で、急いでいる場合などは、この方式は有用です。

長時間の動画からVTT字幕を生成する6つのステップ

ここでは、例として10分弱の動画に字幕をつける手順を解説します 。

1. 動画の準備

まずは手元に、字幕を作成したい元の動画ファイルを用意します 。

2. 基本秒数の設定と動画の分割（クイックアクション）

動画を5分以内のパーツに分けます 。

• 用意した動画を右クリックしクイックアクションから自作の「字幕用に動画を分割する」を選択します 。
  
• 分割する基本秒数を入力します（デフォルトは270秒＝4分30秒です） 。
  
• ポイント: 単純に時間でバサッと切るのではなく、指定時間付近の「1秒間の無音部分」を探し、キリの良いところで自動分割されるように工夫しています 。
  
• 実行すると、split_01、02…という分割動画と同時に、offsets.txtというファイルが生成されます 。このテキストには「245.130秒」といった分割時のズレ（累計秒数）が記録されており、後で使います 。
  

3. Gemini（Gem）によるVTT字幕作成（手動）

いよいよAIに文字起こしを依頼します。公開している専用のGemを使用します（※リンクは「コードと要約」に掲載します） 。

• Gemを開き、「Proモード」を選択します 。
  
• 下部のメッセージボックスに、分割した最初の動画（01）をドロップ（またはコピペ）して送信します 。
  
• しばらく待つと、タイムスタンプ付きのVTTコードが出力されます 。
  
• 出力されたコードをコピーし、あらかじめ用意しておいた空のVTTファイル（例：01.vtt）にペーストして保存します 。
  
• 注意点: 02以降の動画を処理する際は、AIが混乱するのを防ぐため、必ず「新しいセッション（チャット）」を開いてから同じ手順を繰り返してください 。
  

4. VTTの秒ずらし（クイックアクション）

出力された02番以降のVTTファイルは、動画の開始時刻が「0秒」にリセットされてしまっています 。これを元の時間軸に戻します。

• 対象のVTTファイル（02など）を右クリックし、クイックアクションから「字幕時刻の秒ずらしを行う」を選びます 。
  
• 手順2で生成されたoffsets.txtに記載されている秒数（例：245.130）を入力し、OKを押します 。
  
• 正しい時間にシフトされた _timeshifted.vtt というファイルが新しく作成されます 。
  

5. VTTファイルの結合（手動）

それぞれの時間軸が整ったら、1つのファイルにまとめます。

• 結合用の空ファイル（binded.vtt(※1)）を用意します 。
  
• 01.vttの中身をそのままペーストします 。
  
• 続けて、02_timeshifted.vtt、03_timeshifted.vtt の連番以降のテキスト部分を順番にコピーして下に追加し、保存します 。
  

※1:あとで気付きました。bindedは間違った英語です。boundあるいはconbinedというのが適切です。

6. 連番の振り直しと整理（クイックアクション）

結合したファイルは、字幕の通し番号（連番）が「1」から始まる箇所が複数混在してしまっています 。これを綺麗に整えます。

• binded.vtt を右クリックし、クイックアクションから「字幕VTTの連番を付け直す」を選択します 。
  
• これにより、最初から最後まで番号が正しく振り直された完成版 renumbered.vtt が出来上がります 。
  

まとめ

言葉遣いやテキストの微修正は、このように全体の形が綺麗に整った最後に行うのがおすすめです 。

地味にコツコツと進める手作業の部分もありますが、仕組みが非常に分かりやすいため、作業中のストレスはほとんど感じません 。Gem(ChatGPTもそう)の文字起こし精度が抜群に高いのは、単なる音声からの文字起こしだけでなく、動画内の視覚情報（映像）例えば、動画に登場する文字、人物の動きなどを認識するという、マルチモーダル処理を行っているためです。26年3月現在、CapCut、Vrew、Premiere Pro、Davinci Resolve、Filmoraの文字起こしは「映像情報」を加味せず、純粋に「音声データ」のみに依存しています。おかげで、Gemの場合は、手直しが非常に少なくて済むのが最大のメリットです 。

以上

日々増え続ける大容量データをどのように安全かつ柔軟に扱うか、悩んでいる方も多いのではないでしょうか？

詳しい解説は以下の動画にまとめていますので、まずはご覧ください。

動画で紹介している2つのシステム

動画内で解説しているのは、私がローカルの Mac mini 上で構築・稼働させている以下の2つのシステムです。

1. 配信を自由自在に操る「マイライブラリ」

Dropboxをデータの「製造工場」として活用し、ウェブ配信用の素材（動画、画像、VTT字幕、書類など）をシームレスに配信所へ渡すシステムです。

• 複数の配信所を管理: 複数の配信サーバーを用意しておき、リクエストや用途に応じて自由自在に配信先を切り替えることが可能です。

2. NASの弱点を克服する「棚田式ファイル管理システム」

一般的なNAS（RAID構成など）は、専用のフォーマットが必要なため「HDDを直接取り外して別のPCですぐに読み込む」といった物理的な使い回しが難しいという弱点があります。そこを解決したのがこのシステムです。

• 抜き差ししてすぐ使える: 一般的な外付けHDDやSSDと同じ感覚で、パコッと抜いて他のPCやMacに挿せば、すぐにデータを読み込めます。
• 階層型（棚田式）の管理: データを「作業段」「保管段」「長期保管段」という3つの階層に分けて管理。使わず眠っている古いハードディスクも有効活用できます。

2つのシステムに共通する「最大の秘密」

用途の異なるこの2つのシステムですが、設計の根底には共通する重要なコア技術があります。それは、**「メタデータの変更に基づき、実体データを操作する」**という仕組みです。

• 棚田式システムでの活用:
  いきなり重い実体データを動かすのではなく、まずは「メタデータ」だけを移動させるシミュレーションを何度も実行します。これにより、移動先の容量オーバーや操作ミスを事前に防ぐことができます。
• マイライブラリでの活用:
  スプレッドシートに登録した「属性（メタデータ）」を書き換えるだけで、それに連動して実際のファイルが自動で移動したり、再生サーバーが切り替わったりします。
  
  もともとマイライブラリは、図書館をイメージしていて、図書館の本は質量のある物体のため、それぞれの図書館に受付窓口が必要になりますが、メディアアセットは、質量のない、ほぼ瞬間コピー、瞬間移動ができる存在であるため、図書館カードのようなメタデータは１箇所に集中することができるわけです。その１箇所でメタデータを変更することにより実体データを操作できるわけですね。

まとめ

大容量のハードディスクが高価になっている今、手元にあるストレージをいかに安全・確実、そして無駄なく使い切るかは大きなテーマです。

「メタデータによる実体データの制御」を取り入れることで、日々のクリエイティブ作業やデータ管理は驚くほど快適になります。ご自身のファイル管理や配信のヒントにしてみてください。

動画をご覧ください。

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

自作パペット_py.pub.txt 要約： このPythonスクリプトは、Pygame、OpenCV、MediaPipeを用いて、ウェブカメラとマイクからの入力に基づきリアルタイムでアニメーションするアバター（パペット）システムを実装しています。主な機能は、検出された顔の傾き、視線の方向、口の開閉をアバターの頭の傾き、目の動き、口の形に反映させることです。マイクからの音声レベルやカメラでの口の開閉もアバターの口の動きに連動します。 新たにjsonファイルを利用して顔認識のキャリブレーション設定（顔の基準角度や目の位置）を自動的にロード・セーブする機能があります。これにより、システム起動時に前回の設定が適用され、ユーザーはSPACEキーで現在の顔を新たな基準として保存できます。画面左上にはカメラ映像の一部と、システムのトラッキング状態（WAITING, READY, TRACKING）が表示されます。このシステムは、特定のディレクトリでPython仮想環境を有効化した後、付属のシェルスクリプトによって実行されるように設計されています。

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

なぜパペットを自作しようと思ったのか？

最大の理由は**「コスト」**です。
Adobeの素晴らしいパペットを使うためには、当然ながらAdobeのサブスクリプションに加入する必要があります。一番安いプランの組み合わせでも、月額1,200円ほどかかってしまいます。
「このキャラクターを使うためだけに、毎月課金し続けるのはどうなんだろう？」と悩んでいました。今は生成AI（画像生成AIやテキスト生成AI）がこれだけ発達し、メディアの加工やプログラムの作成まで何でもできる時代です。「それなら、AIの力を借りて自分で作ってしまおう！」と思い立ったのがきっかけです。

新キャラクター「いまかっちゃん（仮）？」

というわけで、完全自前で作り上げたのがこちらのパペットです。（※名前は暫定で「いまかっちゃん」と思いつきましたが、ちょっと変な感じもしています。）
Adobeのパペットと比べてしまうと多少見劣りする部分はありますが、動画用としては十分な機能を持っています。
音声連動： 私が話す声に連動して口がパクパクと動きます。
目の動き： 上目遣いなど、視線も動きます。
首の動き： 多少ですが顔の向きも変わります。（※現状、少し不安定な動きになることがあり、今後の課題です）
動画を作る上での「使い物」にはなんとか仕上がったかなと、個人的には割り切って満足しています。

Google Geminiに丸投げ！？

「どうやって作ったの？」と疑問に思うかもしれませんが、実はプログラミングの大部分は**AI（Google Gemini）**にお願いしました。
Geminiに質問する： 日本語で「こういう動きをするプログラムを書いて」と質問し、Pythonのコードを書いてもらいます。Geminiは非常に賢く、どんどんコードを生成してくれました。
パーツ画像の用意： 目（上・下・右・左）、口（開・閉）、体、頭など、パーツごとに細かく分けた画像（PNG形式）を用意します。
フォルダ構成： Macの中に専用フォルダ（mypuppet_systemなど）を作り、Pythonの実行ファイル（run_puppet.py）と、先ほどの画像パーツ群（assetsフォルダ）を格納して連動させました。

Mac「Automator」で起動を劇的にラクにする方法

自作プログラムの弱点として、「毎回ターミナル（黒い画面）を開いてコマンドを打ち込まないと起動しない」という厄介な問題がありました。これでは面倒ですよね。
そこで、Mac標準アプリの**「Automator」**を使って、ワンクリックで起動できるように一工夫しました。
手順： Automatorを立ち上げ、「シェルスクリプトを実行」を選択。そこにターミナルで打ち込んでいた短いコマンドをコピペするだけ。
アプリ化： これをアプリケーションとして保存すれば、**「自作パペット起動.app」**の完成です！
これからは、このアプリアイコンをダブルクリックするだけで、サクッとパペットを呼び出せるようになりました。

OBSへのパペット設定

OBSへのパペットの組み込みですが、OBSのソース→ウインドウキャプチャ、この中から、パペットのあるウインドウを選択します。

STREAM DECKがあると便利です。マルチアクションにて、OBS.app→自作パペット起動.app、と設定すればラクです。

さてと。。

その後の改善として、Pixelmator Proとの連携を作っています。形になったら紹介します。
生成AIを活用すれば、プログラミングの深い知識がなくても、日常の「ちょっと不便」「コストを削りたい」を解決できるツールが作れてしまいますよね。便利な時代になりました。

コード作成って何？なんとも刺さりの悪い言葉なのですが、昔からある言い方に直せば、「コンピュータプログラム」のことです。これが長ったらしいので、コードと呼んでいます。英単語ではcodeです。音楽で使う和音を意味するコードはchordですね。綴りが違います。能書はこのくらいにして中身に入ります。

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

❶公開用スクリプト作成_pub.txt： 要約：この workflow は、選択した *_exe.txt ファイルから公開用 *_pub.txt を生成する自動処理である。保存先は M1 側ボリュームに固定し、Dropbox へは直接書き込まない。メタ情報が無い場合は自動付与し、既存メタでは更新日時を除去、状態を「公開用」に変更する。本文から個人情報・キー・パス等を匿名化し、key_patterns.txt に基づく追加置換も行う。未置換の秘密候補を抽出して警告し、生成後は公開 URL とエンコード URL を表示・コピーする。付属のシェルスクリプトで生成物を Dropbox に rsync 同期する。

❷公開用スクリプトのリスト表示_pub.txt： 要約：WordPressのショートコードによる公開用TXT一覧を生成するコード。?pubtxt_dir パラメータで階層移動、見出しクリックで sort/order 切替が可能。pmedia/scripts_pub 配下のTXTのみ対象とし、@eaDir やドット始まり・key_patterns.txt を除外。 更新日時（mtime desc）→名前→サイズの優先順でソートし、パンくず表示も実装。各TXTはクリックで閲覧または &dl=1 でUTF-8添付ダウンロード可。ディレクトリトラバーサル防止のため realpath 検証を行う安全設計。

❸scripts_pubフォルダからgドキュメントを生成_pub.txt： 要約：このシステムは、ローカルのスクリプトファイルをGoogleドキュメントに自動同期し、公開するためのものです。Googleドキュメント化することによりGemの読み込みが自動になります。 sync_docs.pyは、設定されたローカルフォルダから特定の拡張子を持つファイルを読み込み、更新日時順に整理します。これらのファイル内容を目次と共に整形し、Google Docs API経由で、指定された複数のGoogleドキュメントに分割して書き込みます（1ドキュメントあたり最大50ファイル）。既存内容を認証後に更新する機能を持ちます。 watcher.pyはsync_docs.pyと連携し、監視対象フォルダ内のファイル変更をリアルタイムで検知します。変更後クールダウン期間を経て、自動的にsync_docs.main_sync()を呼び出し、Googleドキュメントへの同期処理を実行。ローカルファイルの更新を自動的にクラウドへ反映させます。com.xxxxxxxx.docsupdater.plistはmacOSのLaunchAgents設定ファイルで、システムの起動時にwatcher.pyを自動実行し、バックグラウンドでファイル監視とGoogleドキュメント同期プロセスを常駐させる役割を担います。 全体として、このシステムはローカルで管理するスクリプトやテキストファイルを常に最新の状態でGoogleドキュメント上に保ち、ウェブ公開可能な自動化ワークフローを提供します。

❹Antigravity(AIエージェント)に処理を指示するときの基調プロンプト： XXXXXXシステムの実行局FACTORYは、Mac mini M1上の「ITスクリプト管理」を拠点に、設計図を現実環境に適合・定着・記録するAIアシスタントです。FACTORYはITスクリプト管理フォルダを徹底検索し、既存ファイルへの追記・修正を優先。コードは自律テストでエラー修正します。安全基準として、ITスクリプト管理フォルダ内は自律操作可ですが、他での削除等はオーナー承認必須。rm -rf等の破壊的コマンドは禁止、ゴミ箱へ移動等に置換します。機密情報は.envで管理し、報告は汎用形式で行います。記録では新規ファイル名はオーナーと相談、メタ情報と350～400字の要約を付与し、指定形式で出力。完了後、更新箇所をオーナーに報告します。 ※XXXXXXは、ご自分の名前に変えてください。

コード(スクリプト)をもっと知りたい方はこちらへ↓

ポイント解説

ChatGPTからGeminiへ

私のプログラム作成のパートナーは、はじめはChatGPTでしたが、最近になってGeminiへと移行しました。 その理由は開発してきたコードが増えて全部を記憶させて開発に利用することが困難になってきたからです。単価あたりの知識記憶容量がGeminiはChatGPTの約10倍あったのが決め手でした(2026年1月時点)。従って、これから説明する「知識の循環システム」が低コストで実現できるからです。

ただし生成AIの選択ですが、将来どうするか全く分かりません。というのは、毎月くらい各社から高性能のモデルが登場して目移りするからです。ただ、GeminiはGoogle製なので、デジタルアセットの作成から利用、廃棄に至るインフラをほぼ全て提供できるGoogle内にいるので、今のところ一番底力があると思えます。Appleが本気を出せば別ですが。

それでは、私が実践している**「コード（スクリプト）作成のエコシステム」**について、お話ししようと思います。

１　開発：AIとの対話から生まれる「動く形」

私のプログラム開発は、Geminiとの「対話」から始まります。 実現したいアイデアを、そのままAIに投げかけてみる。そこから質疑応答を重ね、ロジックを磨き、コードを作ってもらいテストを繰り返すというやり方です。

最大のメリットは、自分の都合のいい時間に作業ができること、構文のエラーに悩まされる時間が減り仕組みづくりに集中できることでしょう。まずは**「動く形」を迅速に作り上げる**ことができる。これが、このシステムの第一の魅力です。

２　見える化：情報を「資産」に変えるひと手間

完成したコードをただ保存しておくだけでは、後で活かせません。「あれ、このpythonは何をするものだったかな？」と迷子になってしまいます。

そこで私は、必ず**「コードの見える化」という工程を挟みます。 具体的には、Geminiにコードの「日本語要約」**を作成させ、それを冒頭に添付したtxtファイルを生成し、「ITスクリプト管理」フォルダへ収めます。

さらに重要なのがセキュリティです。 独自のルール（key_patterns.txt）に基づき、個人情報やAPIキーを機械的に「XXXXX」などへと置き換えます。こうして生成されたクリーンなファイルを、公開用の scripts_pub フォルダへ移動させます。 少し手間に見えるかもしれませんが、この工程が、「誰でも使える汎用的な知識資産」へと変身させるのです。

３　公開と共有：ブログと「自分専用Gem」

こうして整えられた知識資産は、2つのルートで新しい価値を生み出します。

一つは、このブログです。 WordPress上の「公開スクリプト一覧」として整理し、訪問者に自由に役立てていただけるリソースとして開放しています。

そしてもう一つが、**Geminiへのフィードバック（還流）**です。 これらのスクリプト群を「知識ソース」としてリンクした、私専用のGem（カスタムAI）を構築します。これはユーザーへのサポート窓口になると同時に、私自身が次のコードを生成するための、最強のデータベースになってくれるわけです。

４　終わりなき進化のループ

このシステムを運用していて改めて気づく最大の利点は、**「予習が不要」**になったことです。 プログラムに不具合が見つかったり、改善したくなったりした時、私のGeminiには既に過去のコードが「知識」として埋め込まれています。特段の準備をすることもなく、速やかに修正や拡張の開発に着手できるのです。

修正して得られた新たな知見は、またシステムを通って知識ソースへ戻っていく。 回せば回すほど、AIは私の意図やコーディングの癖を深く学習し、精度が増していきます。まさに、終わりなき進化のループと言えるでしょう。

5　ファイル管理系のアプリの生成・実行を、Antigravity任せにするのは禁物

動画を作った後で、画像を手直ししましたが、「Antigravity」という、コードを作るだけではなくて実行テストから完成までやってくれるアプリを使えるようにしました。見てるだけで勝手に作業をしてくれる夢のようなアプリです。ちなみにmodelとして大人気のClaudeも指定できます。しかしですね、非常に怖い側面を持っています。エンタメあるいは書類作成用途は、この「Antigravity」をぼおっと見てるだけでいいかも知れません。しかし、ファイル管理系のアプリ作成の場合は、作業を丸投げするのは、やめた方がいいです。「大事なファイルを消された！」という大失敗があちこちで起きているようです。

ファイル管理系のシステムを生成する場合は、

といったようにバトンリレーに人が挟まるような、慎重な形がよいと考えます。

【おわりに】高齢者のAIとの付き合い方

今回は「プログラム作成」を例に挙げましたが、この**「情報の整理・変換・再学習」という循環**は、文章作成や研究、あるいは趣味の記録など、あらゆる分野に応用が可能だと感じています。

作業の進め方は、ゴールまでの間をステップ化して、少しずつ着実に進む方法がベストです。

私は高齢者ではありますが、こういった新しい技術は、若者だけのものではありません。むしろ、これまで蓄積してきた多くの知識や経験を整理し、形にするためにこそ、AIというパートナーは大きな力を貸してくれるようにも思えます。 高齢者にも役に立つ「上手い使い方」がまだまだありそうな気がしています。

以上

〜Mac miniによるDAS操作、Mac miniは今こそ本領発揮の時代に入った〜

SynologyNASとMac miniを組み合わせたファイル管理システムを使い始めた頃から、「NAS自体がPCの機能を持っているので、Mac miniと機能が重複している。Mac miniの頭脳(OS)を使って、複数のHDDを、RAIDのようにガチガチではなく、もっと自由に扱うことができないか」と問題意識を持っていました。その解決策を提案しているYouTube動画が気になっていました。👉「NASじゃなくてもいいかも！Mac miniでデータ管理してみた(ギズモード網藤さん)」「【NAS＆RAIDより安全】２０２５年版　個人限定　データを守る方法を紹介　HDDケース」

棚田式を思いついたのは、ギズモードの網藤さんが「一年に１回、写真や動画を移動させるルールを実行している」と語っていたことがヒントになり、「棚田は許容量を超えたら水が溢れ出る→だが、ここで→古い水から下段へ移動できたら面白い」とイメージしたことです。
まずは動画をご覧ください。

ポイント解説

（１）脱RAID(DAS)のメリット・デメリット

（２）自宅のどんな場所で使っているのか。

棚田システムは非常に柔軟で、M1Mac miniで十分だし、その外付けドライブであれば（というかM1Macが認識できるドライブであれば)どれでも選定できます。現状、下の図の赤丸T0T1T2に棚田システムを設定しています。調べてみて自分で驚いたのですが、外付けドライブを11個も使っていました。まだあと外してあるものも数個あります。別に壊れているわけではないのに。資源やお金を無駄にしてきたと思います。
世界全体が巨大なRAIDで動いているために、実際どれくらい冗長に重複所有になっているか。AI需要がそれを爆増させているわけなので、あとあと、とてつもない廃棄物が出る。バブルの崩壊が起きそうですね。。ああ怖い。有効活用のことを本気で考えるべき時がやってきそうな気がします。

棚段の基本構成は、作業段(T0)、保管段(T1)、長期保管段(T2)の３構成ですが、流出流入の関係を規定すれば、もっと増やすこともできますし、逆に、２構成にするのもいいと思います。実際、私は、高齢者ですので、これからは減らす方向でいきたいと思っています。

（３）実装

下記のトグルボックスにある青ボタンを押してtxtファイルをダウンロードして、AI(Gemini/ChatGPTなど)に理解させ、ご自身の環境に合わせた実装手順をお進みください。

実装手順

DAS棚田処理_メタデータ実データ更新アルゴリズム：

DAS棚田処理_メタデータDB仕様書：

DAS棚田管理_メタデータ処理py_shコード： 要約：Google Sheetsの「tanada」シートを設定CSV（tanada.csv）へ同期し、そのD列「転出パス」配下を全走査して世代SQLite（scan DB）を作成、さらにscan DB＋tanada.csvから全件の計画SQLite（plan DB）を1つ生成して「KEEP/MOVE/EXCLUDE」と新旧パス（abs_path/to_abs_path）を確定する一連のメタデータ用パイプライン。D列は1セル内の「,」や改行で複数パス指定可として分解し、重複は深いroot優先で排除。analyzeでは処理idごとに「転出パス1つ・転入パス1つ・除外パス複数可」を強制し、除外容量を差し引いた限度内でmtime降順に累積して新段位を決定、逆流（転出段≥転入段）はpipelineで拒否。最後にplan DBを集計し「どこ→どこへ/件数/容量」をMail.appで通知（print-only可）。das_runner.shがexport→pipeline→notifyをボタン1発で実行するランチャ。

DAS棚田管理_実データ更新処理コード： 要約：このシステムは、Google Sheetsをインターフェースとしたファイル管理の自動化パイプラインです。tanada_apply_button_daemon.pyは、Google Sheets上の手動ボタン（A10）によるAPPLY要求のみを監視し、深夜時間帯を除いてtanada_apply.pyを起動します。apply_runner.shは、SheetsのA8セルからファイル移動計画DBのパスを読み込み、それを固定名の適用DBにコピーし、tanada_apply.pyを実行するためのシェルスクリプトです。コアロジックを担うtanada_apply.pyは、適用DBに記録されたアクション（主にファイルの移動）をDRYRUNまたはAPPLYモードで実行します。このスクリプトは、「現段位がT0ではないファイルを新段位T0へ移動する」ポリシー違反を最優先でチェックし、違反があれば直ちに処理を停止する安全機構を備えています。処理結果はSheetsの指定セルにフィードバックされます。tanada_make_apply_plan_db.pyは、シミュレーション結果DBから、tanada_apply.pyが使用する固定名の適用計画DBを生成し、古いDBは世代管理してアーカイブします。com.xxxxxxxxm1.tanada_apply_button_daemon.plistは、デーモンをmacOSのLaunchAgentとして自動起動・常駐させ、必要な環境変数を設定します。このパイプラインは、手動トリガーと厳格な安全ポリシーにより、ファイル移動の誤操作を防ぎながらも自動化を実現しています。

DAS棚田管理_廃棄処理の規定：

コード(スクリプト)をもっと知りたい方はこちらへ↓

（４）まとめ

残りの、廃棄処理、FreeFileSyncによるミラー同期処理、シャドウ・ディレクトリの作成、に関するコードは、完成し次第掲載していきます。ただし、他の処理への影響はありませんので、上の内容をそのまま使っても動きます。

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

以上

Gemini APIキー取得方法と活用

要約：このAppleScriptスクリプトは、ユーザーが選択したテキストをGoogle Gemini APIで要約し、その結果と元の本文をファイルに保存する自動化ツールです。右クリックで選択されたテキストを受け取り、処理前に内容をプレビューして続行を確認します。スクリプトはPython3とcurlコマンドを使い、Gemini APIにアクセス。MY_API_KEYを用いて、利用可能なモデルからgenerateContentをサポートするモデルを自動選択し、指定された文字数（MAX_SUMMARY_CHARS）で日本語の要約をリクエストします。Geminiからの出力は、要約文とその後に続く元の本文で構成されます。処理が完了すると、SAVE_DIRにタイムスタンプと要約の最初の行から生成されたタイトル（TITLE_MAX_CHARSで制限、ファイル名として安全化）を含むUTF-8形式のテキストファイルとして保存されます。処理状況やエラーは通知でユーザーに伝えられます。 Automator ワークフローが受け取る項目：テキスト 選択肢：すべてのアプリケーション

【ChatGPT】
～無料版でも動く、ローカル完結の超シンプル連携法～
ChatGPTでテキストを要約したいとき、毎回アプリを開いてコピペするのは意外と手間です。そこで、AppleScriptとChatGPTデスクトップアプリを連携させて、「クリップボードの内容を自動でChatGPTに貼り付け→要約→テキストファイルに保存」までを数クリックで完結させる仕組みを紹介します。ChatGPTの無料版でも動作し、APIキーや外部サービスは不要です。

ポイント解説

■ スクリプトの流れ

1. クリップボードのテキストを取得
2. ChatGPTアプリを自動起動
3. 要約プロンプトを自動入力（例：「以下のテキストを日本語で400字以内に要約してください」）
4. ChatGPTが要約を生成
5. ユーザーが要約をコピー
6. 指定フォルダにテキストファイルとして自動保存

１のクリップボードのテキスト取得がミソになっています。マウス右クリックでコピーしたものです。保存ファイル名は「YYYYMMDD-HHMMSS_タイトル.txt」という形式で、
例：/Volumes/NO3_SSD/Dropbox/dropbox_1/ChatGPTによる要約と本文/ に保存されます。

■ 実装の手順

(1)	下の青色のボタンから、スクリプト(txtファイル)をダウンロードします。
(2)	スクリプトエディタで、例えば”Save_Clipboard_with_Summary”と名前つけて、スクリプトファイル”Save_Clipboard_with_Summary.scpt”として保存します。
(3)	(a)Stream Deckからは”Save_Clipboard_with_Summary.scpt”が直接呼べます。 (b)クイックアクションからの起動は、Automator→クイックアクション→ワークフローが受け取る現在の項目：テキスト、使用できるアプリケーション：任意のアプリケーション→「AppleScriptを実行」のボックスを置く→(4)
(4)	run script (POSIX file “/<あなたのファイルパス>/Save_Clipboard_with_Summary.scpt”)
(5)	アプリ名を例えば”ChatGPT要約付きTXT保存”として保存します。
Windowsへ実装したい場合は、ChatGPTに上のtxtファイルを添付して、「同じ働きをWindowsで実装するスクリプト作成と実装手順を指示ください」としてください。

■ 操作方法

使い方はとても簡単です。
要約したいテキストをコピーし、このアプリを実行するだけ。
ChatGPTが起動して自動で要約を生成し、その結果をコピーすればファイルが自動保存されます。
これで「ChatGPTで要約→保存」までが一瞬で完了します。

さらに、右クリック（コンテキストメニュー）から呼び出せる「クイックアクション」として登録しておくと、
ブラウザやメモアプリ上でテキストを選択 → コピー → 右クリックで「要約して保存」を実行、
という直感的な操作が可能になります。
Mac標準のAutomatorで簡単に登録できるため、日常の作業フローに自然に組み込めます。

■ ChatGPTの文字列のコピーが扱えない！裏ワザあります。

ブラウザ、テキストエディット、メモなどにある文章は、コピーを行なった後、このアプリをMacのキーボードショートカットに登録して、要約保存は、下記のアクセス許可を経て使用できるようになります。私は、「ChatGPT要約付きTXT保存」アプリに⌥(Option)+ファンクション(F)1を登録しました。

しかし、本家本元のChatGPTに表示される文字や文章は、コピーした後、アプリが起動しないという問題が生じます。その場合の裏ワザです。

それは、文字列のコピーは、Web版ChatGPTから行い、アプリを起動してインストール版ChatGPTで要約させ、最後に保存する流れで連携する方法です。以下のような挙動になります。

■ 注意：アクセス許可が必要な場合があります

クイックアクションを使って、Safari・Chrome・PDFビューアなど
さまざまなアプリからテキストをコピーして要約に取り込む場合、
まれに「エラーが出る」「テキストが取得できない」ことがあります。

これは、そのアプリのテキスト内容へのアクセスが macOS で制限されているためです。
その場合は以下の手順でアクセスを許可すると解決します。

対処方法：
1. 「システム設定」→「プライバシーとセキュリティ」を開く
2. 左側のメニューから「アクセシビリティ」または「フルディスクアクセス」を選択
3. 使用しているアプリ（例：Automator.app、ChatGPT.app、または実行中のスクリプトランチャー）を追加してオンにする

この設定を行うと、ブラウザ・PDF・Word・メモなど、
どのアプリ上でもクイックアクションを安定して利用できるようになります。
特にAutomator経由でスクリプトを動かす場合は「Automator.app」へのアクセス許可が重要です。

■ TextEditでクイックアクションが出てこない場合

TextEditでテキストを選択しても、右クリックメニューにクイックアクションが表示されない場合があります。
これは、TextEditがリッチテキスト（装飾付き）モードになっているとAutomatorが対象外とみなすためです。

💡 対処方法：
1. メニューの「フォーマット」→「標準テキストにする（⌘⇧T）」を選択し、プレーンテキストモードに切り替える。
2. 再度右クリック → 「クイックアクション」を確認。

すると、「ChatGPT要約付きTXT保存」などのワークフローが表示されます。

⚙️ Automatorの設定で特に重要なポイント！

Automatorでクイックアクションを作成するときは、
上部の設定欄にある

「ワークフローが受け取る現在の項目」

の指定を 必ず「テキスト」に設定してください。
ここが「リッチテキスト」や「ファイル」のままだと、
TextEditではメニューに表示されません。

正しい設定：
• ワークフローが受け取る現在の項目：🟢「テキスト」
• 使用できるアプリケーション：🟢「任意のアプリケーション」

この設定を間違えると、メモでは動くのにTextEditでは出ない、という現象が起こります。

🔸ポイント：Automatorの「受け取る項目」は“入力タイプの宣言”に相当します。
TextEditがプレーンテキストを出すときだけ、この条件に一致します。

🧭 Stream Deckでの活用（おすすめ）

クイックアクションも十分便利ですが、Stream Deckを持っている方は、こちらを使うのがおすすめです。

Stream Deckは、右クリックメニューではなくAppleScriptやShellスクリプトを直接起動できるランチャーです。
そのため、ChatGPTアプリのようなWebView上のテキストでも問題なく実行できます。
つまり、どんなアプリや画面上でも「コピー → ボタン一発」で要約＋保存が可能になります。

▶ Stream Deckでの設定例
1. Stream Deckアプリを開く
2. 「System」→「Open」または「AppleScript実行」アクションを追加
3. あなたのスクリプトファイル（例：Save_Clipboard_with_Summary.scpt）のパスを指定
4. ボタンに「要約して保存」などの名前やアイコンを設定

これで、どんなアプリ上でも：

テキストをコピー → Stream Deckボタンを押す → ChatGPTが自動要約 → Dropboxに保存
という流れをワンアクションで実行できます。

▶ 併用のすすめ
• 普段は右クリックのクイックアクションで十分
• ChatGPTアプリやPDFなど、クイックアクションが反応しない場合はStream Deckで実行

両方に同じスクリプトを指定しておけば、操作感を統一しつつ、どんな環境でも動く構成になります。

■ 利用のポイント

• 無料版（GPT-3.5）でも問題なく動作します。
• 英語記事や長文を正確に要約したい場合は、GPT-4またはGPT-5（ChatGPT Plus）を推奨。
• すべてローカルで完結し、外部通信やAPI設定は不要。
• 要約と手入力タイトルのどちらにも対応し、ファイルは日時順に整理されます。

■ 応用例

プログラミングスクリプトの日本語要約もさることながら、

• 英語→日本語要約版
• 翻訳＋保存版
• URL要約版(👉「質問してみましょう」のボックスにURLが入った状態で待ちになる場合は、右のボタンを押して動作させる)

ChatGPTアプリを直接操作する感覚で自動化できるため、
誰でもすぐに試せる実用的なAI活用法です。
Macユーザーなら今日からすぐ導入できます。

以上

ポイント解説

１　字幕一覧の翻訳はGoogle翻訳の勝ち！

２　画像内の文字の翻訳はApple翻訳の勝ち！

３　結論
可能なら両方ONにして使ってみましょう。
現状(25年9月)、ブログ翻訳については、ChromeでGoogle翻訳を使うのが、一番安定しています。

以上です。

別の投稿で紹介したいと思いますが、字幕起こしを伴う字幕作成サービスについては日進月歩でして、どんどん高品質になっています。大きく分けると、ローカルで処理する方法（大抵は無料でできる）と外部サーバーで処理する方法（大抵は使用料課金かサブスク提供)がありまして、外部サーバー利用の方については激しい競争下にあるためかなり高品質で、生成AI系企業のサービスが群を抜いています。

最近、AIの進展で、動画をアップロードするだけで音声を取り出しその内容をAIに理解させることができるようになってはきましたが、やはり字幕ファイルによる文字情報で内容を理解させる方が圧倒的に迅速で正確です。しかも動画からの読み込みは多大なリソースを消費するので、追加料金も発生するかも知れません。そんな意味で、ブログ投稿をAIに学習させる場合も、動画には字幕ファイルを別添して貼り付けるようにして、字幕ファイルからの情報吸い上げを重視すべきだと私は思います。

そんな中で、ここで紹介する方法は、無音声の動画に解説用の字幕をサクッと付ける場合、に役立つものです。

ポイント解説

１　VTTで編集ができます：
簡易な字幕作成ツールとしては、「字幕工房」が優秀であるという見方は変わりませんが、SRTファイルでの書き出しです。私はWordPressブログに掲載する動画が殆どですので、毎回VTTファイルへ変換することになり面倒です。「字幕工房」に限らず、動画作成アプリで出力される字幕は、殆どがSRTファイルなのですね。

２　ローカルファイルの更新をそのまま反映します：
動画共有サービスに共通することですが、字幕もそのほかのメディアアセットもローカルからアップロードした時点で切り離されてしまうので、ローカルファイルを更新しても反映されません。図の下段は、今運用しているマイ・メディアライブラリの機能ですが、ここでもその威力が発揮されます。ローカルでVTTファイルをTextEditで開いて手直しすれば、そのまま、ブログの表示が変更されます（数分のタイムラグはあり）。

３　停止位置の時刻を自動で取得します：
QuickTimePlayerで動画を停止した場所の時刻(時点)を自動で取得して、テキストとともに、VTTファイルへ書き込みます。さらに、書き込んだ情報を読み込んで、HUD(ディスプレイ)に即座に表示します。

主な特徴点は以上ですが、かんたんな点では、「字幕工房」を上回っています。

４　わずか2ステップ：

①対象の動画をクリックして開く(デフォルトはQuickTimePlayer)。

②フォルダの上で右クリックして、「字幕かんたん作成」を立ち上げ、VTTファイルを作る。

だけです。

５　キビキビと動きます：
字幕作成アプリを探すと、ブラウザアプリが主流になっています。そのブラウザアプリですが、欠点は、「もったりヌルヌルした動作」にあります。iPad iPhoneでは仕方ないにしても、Macでも感じるところがあるので、それはなんか疲れるわけですね。QuickTimePlayer、TextEdit、標準スクリプト、そういった標準搭載ツールは、実にキビキビと動きます。

実装の手順

(1)	下の青色のボタンから、スクリプト(txtファイル)をダウンロードします。
(2)	生成AI( Gemini、ChatGPTなど)を利用すると簡単です。AIのプロンプト欄に、 ①ダウンロードしたスクリプトをアップロードします。 ②以下を記述します。 「私のMacに、添付したスクリプトを実装する手順を作ってください。それをtxt形式で提供ください。 私のMacは、[機種名][OSバージョン]です。よろしくお願いします。」
(3)	提供された、実装手順を記載したtxtファイルに基づき、生成AIとやりとりしながら、実装してください。 ※txtファイルを開いたまま生成AIとやり取りし、修正後のtxtを再度送って「これで大丈夫ですか」と確認する方法を取れば、更新内容を逐一手元に残せるため、作業の履歴管理として便利で安心です。

以上です。

WordPressの標準メディアライブラリは、シンプルで直感的に使える反面、運用が長くなると「使いにくさ」が目立ってきます。

特に、大量のファイル管理・差し替え・動的な配信が必要な場合、その制限は大きな足かせになります。

この記事では、私が実際に運用している「マイ・メディアライブラリ」に移行することで得られたメリットを、具体的にご紹介します。

WordPress標準メディアライブラリの制約：

1. ファイル名だけがランダム化されるのは中途半端
   アップロード時、物理ファイル名がランダム文字列に置き換わります。しかしパスはWordPress内のフォルダ構造がそのまま表示されます。中途半端です。
2. 配信URLが静的
   WordPressの標準メディアライブラリには、配信URLを、動的URLに変換する機能はありません。（動的URLとは、ある条件に従って、指定したサーバーへリダイレクトする機能のことです。）
3. ローカルファイルパスが保持されない
   管理画面ではサーバー上のパスが見えますが、外部ストレージやローカル環境での実パスまでは記録されません。そのため迷子になります。
4. 差し替えが面倒
   同じURLでの置き換えはプラグインが必須。標準メディアライブラリでは新規アップロード＋記事修正が必要です。

私が構築した「マイライブラリ」では、以下の点でWordPress標準メディアライブラリを大きく上回ります。

マイ・メディアライブラリの特徴：

• 配信URLが不変
  ローカルのファイルパスやファイル名を変更しても、配信URLは rd.php?id=… 形式で固定。記事リンクや外部配信先が切れません。
• 動的URLで配信
  表示時に rd.php がIDから実ファイルを探して返す仕組み。さらに、
  • 配信サーバーを拡張子別に設定可能（例：.movはXserver、.jpgはDropbox など）
  • ファイルごとに配信サーバーを個別指定可能
  • 裏側で保存場所やファイル構造を変更しても即反映
  • 外部ストレージやローカルファイルへの切り替えもスムーズ
  • 将来的にフェイルオーバーを行う(災害時など自動で別サーバーに切り替える)ことも可能です。
• ローカルファイルパスも自動的に記録
  例：/Volumes/xxxxxx/Dropbox/xxxxxxxxx/pmedia/…元データの直接呼び出しや加工がすぐ可能。
• 差し替えが自由
  配信ファイルの中身の差し替えは簡単です。ローカルファイル上で、上書き保存すれば、更新後のファイルが各配信サーバーへ転送されます。
• 更新履歴の管理
  ファイルパス変更前後や更新フラグを記録し、追跡可能。

運用のイメージ：

下のアルゴリズム図のように、ファイルの変更や追加・削除を検知して、

必要に応じて配信URLに紐づくレコードを更新します。

さらに、次のように拡張子別・ファイル別で配信サーバーを切り替える設定画面も備えています(AppSheet）。

WordPress標準メディアライブラリからの移行メリット：

• 過去記事やSNS投稿の画像リンク切れを防げる
• 外部ストレージやローカル環境とシームレス連携
• 動的URLにより、裏側の構造変更を即反映
• 拡張子別・ファイル別で配信サーバーを柔軟に選択可能
• ファイル整理や命名ルール変更が怖くない
• 差し替え・更新作業の工数を大幅削減

具体的な作成方法について：

こちらの記事をご覧ください。

まとめ：

WordPressの標準メディアライブラリは静的でシンプルですが、大量のメディアを長期的に運用するには不向きな面があります。

一方、マイライブラリのようにURL固定＋動的配信＋配信サーバー選択＋裏側は自由に更新できる構造にすれば、運用の効率も自由度も格段にアップします。

以上です。