ブログ記事をYouTubeショートに変換する装置、7枚の縦型スライドで動かした

ブログを書いた後、同じ内容を短い動画として見せたい。しかし毎回、台本、スライド、音声、公開後の確認まで手でつなぐと、記事の執筆とは別にもう一本の制作工程が生まれます。

某所ラボでは、公開済み記事を原材料にしてYouTubeショートへ変換する装置を組みました。公開前の動作では、1080×1920の縦型スライドを7枚出力し、音声付きの17.22秒動画を約15秒で合成できました。重要なのは速さだけではありません。記事にない数字や事実を台本へ混ぜないための機械ゲートと、公開後の動画を見張る工程まで、一本の流れに入れています。

これは、工作を見せるお試しシーズンの3本目です。シリーズの始まりは工作室を開けた回にあります。前回の記事の図解をAIへ預ける仕組みでは、仕様を書く側と描画を担う側を分けました。今回はその線引きを、動画まで延ばしました。

記事から動画までを、1日1本の一本道にした

変換の順序は、台本を書く、機械ゲートで検査する、スライドを描画する、音声と映像を合成する、YouTubeへ出す、です。出荷上限は最初から1日1本に定めています。速く増やすためではなく、公開物を後から追える量に抑えるためです。

図1: 構成図: 記事からショート動画までの変換経路と1日1本の出荷上限

入力	公開済みブログ記事
変換	担当AIが台本化 → 機械ゲート → 縦型スライド描画 → 音声・映像合成
出力	YouTubeショート（公開は1日1本まで）
公開後	毎日の点検 → 週次の振り返り → 次の台本への反映

図1で見るべき点は、動画合成の後にも工程があることです。公開は終点ではなく、点検と振り返りの入力になります。

この仕組みは2026年7月30日に、旧環境で動いていた合計約1,288行規模の構成を新環境へ移設して復元しました。移設によって判定ロジックそのものは変えていません。現行シーズンの全7話も、ショート化対象として復元済みです。

公開を動かすには、どの記事を対象にするかの配線、公開許可、初回実行が成功したことの確認、という3点がそろう必要があります。7月30日には、所長の明示的な許可を受けて公開を有効化しました。対象外の記事を誤って出荷しないよう、対象外なら出荷側で拒否する経路も置いています。

実測では、数字が違う台本を不合格にできた

公開前に、アップロードを伴わない動作確認を行いました。結果は次の通りです。

図2: 実画面相当の検証結果: 7枚の1080×1920スライドと17.22秒動画を出力

工程	確認したこと	結果
スライド描画	縦型1080×1920の画像を7枚出力	目視確認済み
機械ゲート	数字が一致しない台本を検査	不合格を返した
出荷側	対象外の記事を投入	対象外として拒否した
音声・映像合成	音声付きのテスト動画を生成	17.22秒、処理約15秒、品質チェック通過

図2で変化しない側も重要です。数字が不一致の台本は通らず、ショート化対象でない記事も出荷されません。生成できることだけを確かめるのではなく、止まるべきところで止まることも確認しました。

一方で、7月30日時点で実測できていなかった工程が一つあります。担当AIが実際の記事を受け取り、台本を書く段の初回実運転です。スライド描画と合成はテスト素材で確認できましたが、台本生成は実記事が流れる時点で確認する計画でした。生成装置は、通った工程と、まだ同じ条件で実測していない工程を分けて扱う必要があります。

手作業の編集と比べると、守る場所が違う

この装置は、動画を必ず増やすための道具ではありません。記事の内容を短く再利用したい運用者が、どこを自動化し、どこを見張るかを決めるための構成です。

選択肢	向く状況	気をつける場所
毎回手作業で短尺動画を作る	記事ごとに見せ方を大きく変えたい	台本の事実確認と公開後確認が作業者に集中する
記事→動画の変換装置を使う	同じ公開物を一定の形式で継続的に再利用したい	対象記事の配線、機械ゲート、公開後監査を一緒に維持する
まだ動画化しない	動画の目的や継続頻度が定まっていない	記事そのものの品質と更新を優先できる

手作業を捨てる必要はありません。形式を変える価値がまだ定まっていないなら、記事を増やすほうが穏当です。反対に、公開済み記事を同じ型で短尺化し続けたいなら、台本だけ、合成だけ、と部分的に自動化するより、公開後まで含めて一本の経路にしたほうが管理しやすくなります。

公開後は、直近30本を毎日少しずつ見る

動画を出す仕組みには、出した動画が説明不足のまま残る問題があります。8月1日、タグが設定されていない動画があるという所長の指摘をきっかけに、公開後の見張りを新設しました。

直近30本の公開動画を毎日1本ずつ読み、タグ、説明欄のハッシュタグ、出典表記、AI利用の開示、公開48時間後にアクセスがあったかを点検します。異常がある時だけ通知されるため、毎日すべてを人が開く運用にはしていません。

図3: 構成図: 公開後の毎日点検と月曜の週次フィードバック

毎日	直近30本から1本を点検し、異常だけを通知する
毎週（月曜）	再生数と視聴維持率の傾向を成績表として振り返る
次の制作	伸びた動画の傾向を、次の台本作りの指針へ戻す
保留条件	比較できる動画が4本未満なら、傾向の蒸留を行わない

図3の保留条件は、動かないための設計です。比較対象が4本に満たない間は、少数の結果から勝ち筋を決めつけません。蒸留がうまくいかなければ、それまでの指針を残します。新しい説明を無理に上書きしないほうが、次の判断を誤りにくいためです。

見えるハッシュタグと検索用タグは、同じ欄ではない

動かしてみて分かった小さなクセもありました。説明欄のハッシュタグと、裏側の検索用タグは、役割も規則も別です。

説明欄のハッシュタグは視聴者に見え、先頭3個はタイトルの上に表示されます。1語だけを使い、最大5個までにしています。最初の一つには動画を言い当てる固有名詞を置き、2番目と3番目には固定の一般語を置く運用です。

一方、視聴者に見えない検索用タグは最大12個、合計400字までです。2語の検索フレーズはこの欄に置きます。ハッシュタグの途中に空白を入れると、その位置でリンクが切れ、残りが説明欄に生の文字として残る事例も確認しました。また、ハッシュタグは15個を超えるとすべて無視されます。短尺動画の細部は、公開してから初めて見えることがあります。

小さく始めるなら、記事一本だけを対象にする

同じ構成を試すなら、最初から全記事をつなぐ必要はありません。公開済みの記事を一本だけ選び、台本、数値・固有名詞の検査、縦型スライド、音声付き動画、公開後の説明欄点検、の順で通してみると、どの工程を自分で持ちたいかが見えます。

このラボの変換装置は、記事が公開されるたびに動き、ショート動画を出し続けています。次に見たいのは、比較できる動画が4本以上そろった後、週次のフィードバックがどんな勝ち筋を拾うのかです。ハッシュタグの一番目に置く固有名詞も、もう少し試せます。

7枚のスライドとの対応

台本 JSON は、記事の結論、条件、手順、失敗、確認、注意、出典の7枠へ対応させます。生成成功はファイル生成の確認であり、視聴者画面の readback は公開後に別に確認します。公開 URL は運営記録で管理し、本文で未確認の視聴結果を主張しません。