RumiCarのトップページで動いている「動画ダイジェストの小窓」の仕組みを、VideoLoop という名前のオープンソースソフトウェアとして公開しました。先日公開したPhotoStripの姉妹プロジェクトで、活動を動画で紹介したいコミュニティ・サークル・学校・団体はもちろん、企業サイトへの組み込みなど営利目的を含めて、どなたでも・どんな用途にも自由にお使いいただけます(MITライセンス)。
GitHub: RumiCar-group/RumiCar-VideoLoop(解説は日英両方あります)
解決したかった問題
私たちは活動のたびに動画を撮り、YouTubeチャンネルに約100本を公開してきました。トップページには代表動画を1本、再生ボタン付きで埋め込んでいましたが、再生ボタンはほとんど押されません。100本の活動記録が、実質誰にも見えていませんでした。
では自動再生のプレーヤーを埋め込めばよいかというと、今度はページを開いている間じゅう、見ていようがいまいが訪問者のデータ通信でストリーミングが続きます。PhotoStripで「訪問者が払う通信量は、見ることを選んだ時間のぶんだけ」という原則を作ったばかりで、それを動画で破りたくありませんでした。
どう解決したか
発想は「第一印象を事前レンダリングする」です。各動画から8秒・無音・小画面用のティーザークリップ(1本約230KB=写真2枚分)を自動生成して自サイトに置き、小さな固定サイズの窓で次々に、訪問のたびに違うランダム順で再生します。クリックするとYouTubeの本編へ飛ぶので、再生数は本来の場所で数えられます。
通信量は徹底して「見ている間だけ」です。小窓が画面に入るまでは1バイトも取得せず、スクロールで画面外に出るか、タブを切り替えると停止します。実測では、画面内で20秒眺めた場合の転送量は約700KB。OSの「視差効果を減らす」設定や省データモードの方には自動再生せず、ポスター画像と開始ボタンだけをお見せします。
新しい動画をチャンネルに公開すると、毎晩の自動処理が翌朝までにティーザーを追加します。逆に動画を非公開にすると、ティーザーも自動で消えます——非公開にしたはずの動画がサイトで流れ続けてはいけないからです。
失敗も含めて、READMEに全部書きました
今回もREADMEは仕様の羅列ではなく開発の思考過程を残しています。検討した4つの選択肢と捨てた理由、YouTube規約に関する正直な注意、そして実際に踏んだ罠——「エラーなら次へ」という一見正しい設計が、動画削除とキャッシュの組み合わせで404リクエストの無限連射になった話。タイムアウト1本で毎晩同じ場所がクラッシュし続ける話。CSSの詳細度でテーマに負けて「余白を詰めたつもり」が2度も嘘になった話。公開前に実施した3回の敵対的レビューが何を見つけたかは、RETROSPECTIVE(ふりかえり)として独立した文書にまとめました。
依存ライブラリはゼロ。JSとCSSを1つずつ読み込み、ティーザー生成ツール(Python)を動かすだけです。生成ツールは手元の動画ファイルからも、自分のYouTubeチャンネルからも作れます。環境別のレシピ(静的HTML/PHP/WordPress)も同梱しました。実際に動いている様子はこのサイトのトップページの紹介動画の下でご覧いただけます。
この開発はAI(Claude)が人間の監督・承認のもとで行いました。質問・提案はGitHubのIssueで日本語・英語どちらでも歓迎です。