ブログ記事を60秒リールにするまでの4ステップ｜Claude Codeに渡している手順書を公開します

今日、ShiftB講師のあおやぎさんが書いた振り返りブログを1本、Instagramのリールにして投稿しました。僕がやったのは、記事のURLをコピーして1行貼ったことだけです。台本もナレーションもスライドもテロップもサムネイルもキャプションも、全部AIが作っています。

できあがったのがこれです。

5月に1本目を出してから、今日で18本目になりました。この記事では、その裏で動いている手順書をほぼそのまま公開します。

司令塔は Claude Code というAIエージェントです。ただ、Claude Codeに「いい感じにリールにしといて」と頼んでいるわけではありません。渡しているのは「この順番で、こう作る」という手順書で、判断のルールは全部こちらが先に決めてあります。AIに任せているのは判断ではなく作業。18本回してみて、毎回同じ品質で出せるかどうかはここで決まると感じています。

叩いているのは、この1行

/make-and-post-reel https://shiftb.vibely.site/blog/xxxxxxxx

Claude Codeの「スラッシュコマンド」（よく使う手順書を登録しておく機能）に、リール作りの全工程を登録してあります。記事のURLを付けて実行すると、4つのコマンドが順番に走ります。かかる時間はトータルで15〜25分。そのほとんどは、画像の生成と動画の書き出しを待っている時間です。

4つのコマンドに割っている理由

分けている理由は単純で、失敗した工程だけをやり直せるからです。

ひとつの長い指示にまとめてしまうと、途中に気に入らない部分が出たときに全部が作り直しになります。4つに割っておけば、声を録り直したくなったらSTEP 2から、画像の構図が違えばSTEP 3だけ、投稿がエラーになったらSTEP 4だけを叩き直せます。

そのかわり、順番だけは動かせません。台本がなければ音声は作れないし、音声がなければテロップのタイミングも決まらないからです。

① 台本｜記事を60秒ぶんに削る

最初の工程は、記事を読んで約60秒・330〜350字の台本にすること。文章を理解して削る作業なので、ここは外部サービスを使わずClaude Code自身がやります。

手順書にルールとして書いてあるのは、このあたりです。

• 記事全体を要約しない。一番濃いポイントを1つだけ選んで、そこに60秒を全部使う

• 構成は「フック → 記事の引用 → 深掘り → 背中押し」の型に固定する

• 引用は原文のまま使う。読みやすく直さない

• 1フレーズは5〜18字で切る（テロップ1枚ぶんの長さ）

「要約するな、一点突破しろ」と先に書いておくのが地味に効いています。何も言わないとAIは記事の全体像をまんべんなく紹介しようとして、60秒に詰め込みすぎた薄い台本ができあがります。

この工程ではもうひとつ、読み上げ専用のテキストも作らせています。句読点をすべて消して、AI を エーアイ、Next.js を ネクストジェイエス のように、日本語の音声合成が素直に読めない語をカナに開いたものです。次の工程の事故を減らすための下ごしらえです。

② ナレーション｜読み間違いを機械に見つけさせる

台本を音声にします。使っているのはGoogle Geminiの音声合成（TTS）で、声は記事のトーンに合わせて毎回選んでいます。

やっかいなのは、TTSが漢字や専門用語をそこそこ読み間違えることです。気づかずに動画にすると、テロップと声が食い違った気持ち悪い60秒ができあがります。かといって毎回人間が聞いて確認するなら、自動化する意味がありません。

そこでこの工程では、作った音声をWhisper（OpenAIの文字起こしAI）でもう一度テキストに戻し、元の台本と一致しているかを機械に照合させています。ズレた語だけをカナ表記に直して音声を作り直す。これを一致するまで、最大5回繰り返します。

実際に引っかかって直した例がこれです。

台本の表記	読み上げられ方	直した表記
短絡的	たんがくてき	タンラクテキ
担う	たんう	になう
仮説	かもうせつ	カセツ
Prisma	ぷりすま	プリズマ
Github	じすふぶ	ギットハブ

照合の判定はゆるめにしてあります。「エーアイ」と「AI」、「全部」と「ぜんぶ」のような表記の揺れまで不一致として扱うと、いつまでも収束しないからです。意味が変わる誤読と、フレーズの抜けだけを拾うようにしています。

最後に再生速度を1.1倍にして、リールの上限である60秒に収めます。今日投稿した回は59.4秒でした。

③ 編集｜スクショと生成画像のスライドショーにする

ここが一番手の込んだ工程です。そして7月に一度、作り方をまるごと変えました。

15本目まではShiftBの黒猫キャラの1枚絵をKling AIに渡して、声に合わせて口が動くアバター動画を作っていました。キャラは立つのですが、60秒ずっと同じ猫が正面でしゃべっているだけの画になります。紹介したいのは記事なのに、画面に記事が出てこない。 それで16本目からは、記事のスクリーンショットとAIで生成したイラストを繋ぐスライドショー形式に切り替えました。

9カット前後で構成して、1カットは3〜8秒。全カットにゆっくりしたズームやパン（Ken Burns効果）をかけて、静止画が並んでいるだけに見えないようにしています。カットごとにズームの方向を交互にするところまで手順書に書いてあります。同じ動きが続くと単調に見えるからです。

生成画像のルールでひとつ気に入っているのが、画像を作る前に、記事を書いた人のプロフィールを必ず読ませていることです。記事ページから著者のメンバーページを辿って、経歴や趣味やトーンを掴んでから、人物像（年齢感・服装・持ち物・雰囲気）をプロンプトに反映させる。茶道が好きな人ならデスクに湯呑みを置く、くらいの粒度です。誰の記事でも同じ絵が出てくる状態を避けたくて入れました。

テロップは音声に従属させています。②で作った最終音声をもう一度Whisperにかけてタイミングを取り、発音の2フレーム前にテロップが出るように並べる。ここで大事なのは、音声を差し替えたら必ずこの計測からやり直すことです。前の音声のタイミング表を使い回すと、動画の後半に向かってじわじわズレていきます。

組み立てには Remotion を使っています。Reactのコードで動画を書ける仕組みで、テロップの位置もスライドの切り替えも全部コードなので、AIが直接いじれるのが都合いいです。1080×1920・30fpsのmp4と、投稿用のサムネイルを書き出して、この工程は終わりです。

④ 投稿｜ここだけは人間が一度見る

最後にInstagramへ投稿します。使うのはInstagram Graph API（Meta公式のAPI）です。

ひとつクセがあって、このAPIは手元のmp4ファイルを直接受け取ってくれません。インターネット上の公開URLしか受け付けないので、いったんAmazon S3に動画とサムネを上げて公開URLを作り、そのURLをInstagramに渡しています。

キャプションも台本をもとに自動生成します。ハッシュタグは付けません。フィード全体のトーンを揃えたいからです。

18本作ってわかった、崩れやすいところ

• テロップと声が少しずつズレる。 音声を差し替えたのに、タイミングの計測をやり直していないときに起きます。③の頭から作り直す

• 生成画像の1枚だけ絵柄が浮く。 まとめて生成してそのまま信用したときに起きます。1枚ずつ目で見て、違えばその1枚だけ作り直す

• 「Media is too long」で投稿できない。 リールの上限は60秒。②の段階で60秒未満に収めておく

• 動画URLが無効と言われる。 Instagram APIは公開HTTPS URLが必須。S3などに上げてから渡す

一番よくやるのは1つ目です。声だけ差し替えて「テロップはそのままでいけるだろう」と進めると、後半で必ず破綻します。

まとめ

やっていることを一言にすると、AIに「うまいことやっといて」と頼むのをやめて、「この順番で、こう作る」を文章にして渡しただけです。

分解してしまえば、台本 → 音声 → 動画 → 投稿の4工程しかありません。それぞれを得意な道具（Gemini、Whisper、Remotion、Instagram API）に任せて、そのつなぎ目と品質チェックをAIにやらせる。手順書を一度書いてしまえば、次からは記事のURLを1本渡すだけで動きます。

この考え方はリール作りに限りません。毎回同じ手順でやっている作業があるなら、まずその手順を自分の言葉で書き出してみるところからだと思います。書けた時点で、半分は自動化が終わっています。🐾

今回リールにした元記事はこちらです。曖昧さを無くせ。全部うまくいく。【2026年上半期振り返りと下半期の目標】｜あおやぎ