はじめに

※本記事は、筆者が確認できた運用ログと実測値を整理した個人の記録です。成果・収益の再現を保証するものではありません。

「AIを使えば、ショート動画をほぼ自動で量産できる」

副業に関する発信を見ていると、こんな言葉をよく目にします。

私も、YouTube Shorts、Instagram、TikTok向けの動画制作を効率化できないかと考え、Claude CodeやCodexを使って運用の仕組みを作ってきました。

最初に目指したのは、台本、背景動画、画像、音声、BGMを渡せば、AIが字幕や演出を組み、各媒体向けの動画を出力してくれる状態です。

しかし、実際に作ってみると、話はそれほど単純ではありませんでした。

字幕と音声が、後半になるほどずれていく
編集用の動画に音声が入っていない
3媒体のCTAを同じ作りにすると、導線が合わない
Discordの権限不足で分析結果が届かない
iCloud上のファイルを常駐Botが読めない
複数動画を同時生成すると、音声エンジンを取り合う
再生数だけで良し悪しを判断すると、改善方向を間違える

こうした問題を一つずつ直した結果、現在は「台本作成→素材準備→動画化→媒体別CTA→BGM→数値分析→次の企画」という流れの大部分をAIエージェントに任せられるようになりました。

ただし、2026年10月5日時点で、すべての処理が無人で安定稼働しているわけではありません。日次分析や企画生成は動いている一方、夜間ビルドの一部はエラーが続き、ブラウザ経由の数値補完もログイン状態によって失敗します。この「動いている部分と、壊れている部分が同居している状態」も含めて、実際の運用です。

この記事では、完成形だけではなく、途中で何に失敗し、何を人間の仕事として残したのかまで書きます。

なお、この記事は「自動化すれば簡単に稼げる」という収益自慢ではありません。確認できた2026年9月の実績は、LINE登録92件、成約46件、成果報酬23,000円です。一方、ツール代を含む最終的な利益はまだ確定できません。確認できた売上と、未確認の利益を分けて書きます。

これは、ショート動画副業の制作・分析基盤を実際に作り、運用して分かったことの記録です。

この記事を読むと、次のことが分かります。

ショート動画制作のどこまでをAIエージェントに任せられたか
自動化して初めて見つかった、字幕・音声・権限・同期の落とし穴
3媒体の数値を次の企画へどう戻したか
作業時間、LINE登録、成約、売上が実際にどう変化したか
「完全自動」より半自動の方が安定した理由
同じ仕組みを小さく始めるなら、どの順番で作るべきか

専門的なコードの解説ではなく、副業として継続運用するための設計と判断を中心にまとめます。

最初に結論：完全自動化より「人間が確認しやすい半自動化」が強かった

約3カ月試した結論は、次のとおりです。

AIに投稿まで全部任せるより、制作と分析を自動化し、公開前の判断だけを人間が行う方が安定する。

最終的に採用した役割分担は、こうなりました。

AIと人の承認フロー図.png 役割分担の要約

企画：AIが競合・自チャンネル分析と候補作成／人が採用案を決める
台本：AIが下書き／人が事実確認と表現を最終判断する
素材：AIが必要な画像・背景・音声を整理／人が権利と内容を確認する
編集：AIが字幕・画像切替・エフェクト・CTA・BGM・書き出し／人が見た目と音声を確認する
投稿：AIがキャプションと媒体別ファイルを準備し、承認後にアップロード／人が公開可否と失敗時の対応を担う
分析：AIが数値取得・比較・異常検知・改善案作成／人が採用可否を判断する

無条件の自動投稿を採用しなかったのは、技術的に不可能だったからではありません。

アカウントを守りながら運用するうえで、公開前の確認を残す方が合理的だったからです。実際には、Discordで人が承認した後にアップロード処理を走らせ、失敗した媒体だけ手動へ戻す構成まで進めました。

ここまでを時系列で整理すると

この仕組みは、最初から完成形を設計して一気に作ったものではありません。

2026年7月：まず1本を最後まで完成させる

最初は、台本と素材から1本の動画を作り、YouTube、Instagram、TikTok向けに書き出すところまでを通しました。

この段階で、AI完成版と手動編集版の分離、媒体別CTA、BGMの後付け、字幕と音声の時間軸統一が必要だと分かりました。

2026年7月後半〜8月：1本作れる状態を、繰り返せる仕組みに変える

Discordでの承認、夜間処理、実績台帳、ファイル同期、モデル切替などを追加しました。同時に、「動いているように見えるが、裏では次の企画へ学習結果が渡っていない」といった接続漏れを監査しました。

2026年8月〜9月：量産より改善ループを優先する

競合分析と自チャンネルの数値を組み合わせ、朝に分析し、タイトル候補を出し、人間が番号を選んで台本制作へ渡す流れに変えました。

最終的な流れは次の形です。

3媒体の実績取得
  ↓
過去投稿・競合との比較
  ↓
タイトル候補をDiscordへ提示
  ↓
人間が候補番号を選ぶ
  ↓
Claude Codeへ台本発注書を渡す
  ↓
素材確認・動画生成
  ↓
人間が完成動画を確認
  ↓
Discordで公開を承認
  ↓
対応媒体は自動アップロード、失敗時は手動投稿
  ↓
翌日以降の実績を再び分析

ポイントは、動画を作って終わりではなく、投稿結果が次の企画へ戻る輪を作ったことです。

ログと保存フォルダから数え直した運用実績

この記事を増補するにあたり、Claude Codeとの会話だけでなく、実際の動画保存フォルダ、投稿状態ファイル、日次インサイト台帳、常駐ジョブのログを照合しました。

ここで最初に困ったのが、「何本作ったか」を一つの数字で答えられないことです。

一つの企画から、確認用動画、字幕なし動画、媒体別動画、修正版、再ビルド版が生まれます。同じ企画をYouTube、Instagram、TikTokへ出せば、企画は1本でも投稿ファイルは3本です。さらに、フォルダがあるだけで公開されていない企画もあります。

そのため、今回は次の3種類を分けて数えました。

作業フォルダ数：一つの企画や再現テストとして保存された単位
媒体別完成セット数：YouTube、Instagram、TikTokなどの公開用ファイルが揃った単位
投稿状態・分析台帳の件数：実際のアップロード状態や投稿後の数値取得まで確認できた単位

1本あたりの作業時間は約60分から約20分へ

自動化前は、Vrewでの編集やClaudeとの壁打ちによる台本作成を含め、1本あたり約1時間かかっていました。現在、人間が直接手を動かす時間は約20分です。

単純計算では、1本あたり約40分、約67%の削減です。同じ1時間で扱える本数は、理論上1本から3本へ増えました。

ただし、この20分は「人間の作業時間」の目安です。パソコンが動画を書き出している待ち時間、APIの応答待ち、エラーが起きた日の復旧時間まで、毎回20分で終わるという意味ではありません。また、企画の事実確認や完成動画の修正量によっても変わります。

減ったのは、字幕やファイルの準備、媒体別の書き出し、数値の転記といった反復作業です。企画選定、事実確認、公開承認など、結果に責任を持つための時間は残しています。

保存フォルダで確認できたのは61件

2026年6月25日から10月3日までの保存先には、合計61個の作業フォルダが残っていました。保存フォルダの内訳

手相系：5作業フォルダ（標準化前のため完成セットは0）
星座系：14作業フォルダ／標準の媒体別完成セット10件
干支系：9作業フォルダ／標準の媒体別完成セット5件
神社系：33作業フォルダ／標準の媒体別完成セット32件
合計：61作業フォルダ／標準の媒体別完成セット47件

61件すべてに、少なくとも一つは「完成」と判断できる動画ファイルがありました。ただし、手相系の5件には再現練習が2件含まれ、星座系と干支系には同一テーマの修正版や重複候補もあります。したがって、61をそのまま「61企画を公開した」とは数えていません。

標準化後の47件では、YouTube、Instagram、TikTok向けのファイルが各47本、合計141本確認できました。星座系と干支系の15件にはThreads版もあり、標準の媒体別書き出しは合計156ファイルです。

この数字から分かったのは、自動化で増えたのは企画数だけではなく、「同じ本編を媒体ごとの仕様へ分岐させる処理」だったということです。人が毎回コピーしてCTAやファイル名を直すと、ここで取り違えが起きます。共通本編を一度作り、最後に媒体別へ分ける設計は、単なる時短ではなく事故防止にもなりました。

投稿状態ファイルで確認できた公開件数

保存フォルダとは別に、アップロード処理が持つ状態ファイルも確認しました。成功状態になっていたのは、YouTube 93件、Instagram 92件、Threads 82件、X 18件でした。

これは「異なる企画が285本ある」という意味ではありません。同じ企画を複数媒体へ公開した結果を、媒体ごとに1件として数えたものです。また、削除済み投稿や手動投稿は状態ファイルと一致しない可能性があります。

TikTokは同じ形式の投稿状態ファイルがなく、ここでは成功件数に加えていません。一方、日次インサイト台帳には、重複を除いた媒体別キーがYouTube 96件、Instagram 72件、TikTok 72件、合計240件残っていました。台帳は投稿後の分析対象を示す記録であり、現在公開されている本数と完全に同じではありません。

このように、保存フォルダ、アップロード状態、分析台帳で数字が一致しないのは異常とは限りません。役割が違うからです。副業の実績として本数を書くなら、「企画数」「媒体別ファイル数」「公開確認数」のどれを指すのかを明記しないと、簡単に数字が大きく見えてしまいます。

直近14日、16企画分の数値

2026年10月5日朝の日次ログでは、継続運用中の神社系アカウントについて、直近14日・16企画分の集計が残っていました。直近14日・16企画分の集計

YouTube：49,525再生／維持率中央値79.5%／登録者増161人（純増157人）
Instagram：225,903再生／保存1,984／シェア60
TikTok：158,153再生／シェア271

同じ16企画でも、媒体によって再生規模も反応の出方も大きく違います。ただし、Instagramはリーチ基準などの分母が異なり、TikTokのAPIでは維持率や保存を同じように取得できません。この表は媒体間の勝敗を決めるためではなく、「同じ内容でも評価される場所が違う」と確認するために使いました。

そして、この再生数自体は売上ではありません。再生やSNSの登録が増えても、LINE登録、成約、成果報酬までつながらなければ「副業としていくら稼げたか」は判断できません。

2026年9月のLINE登録・成約・売上

確認できた9月の実績は次のとおりです。2026年9月のLINE登録・成約・売上

LINE登録：92件
成約：46件（LINE登録後の成約率50%）
成果報酬：1成約あたり500円
売上（成果報酬）：23,000円
LINE登録1件あたりの売上：250円
CapCut Pro：月額2,180円
CapCut控除後の残額：20,820円

計算は、46件×500円＝23,000円です。

92件のLINE登録から46件が成約しているため、登録後の成約率は50%。売上をLINE登録数で割ると、登録1件あたり250円でした。

この数字は、動画の再生が最終的な成果へつながったことを示す一方、23,000円をそのまま最終利益とは書けません。

利用している有料サービスは、Claude Maxの月額100ドルプランと、CapCut Proの月額2,180円プランです。また、Claudeを他の仕事にも使っている場合、月額100ドルの全額をこの動画副業の経費にするか、利用割合で按分するかでも利益は変わります。

商品の仕入れ原価を考えない段階の粗い利益、つまりツール代を差し引く前の粗利は23,000円です。最終的な手残りは、次の式で確認します。

最終利益 ＝ 23,000円
          − CapCut Pro 2,180円
          − Claude Maxの実際の円建て請求額または動画副業への按分額
          − その他、この運用だけに使った費用

          ＝ 20,820円
          − Claude Maxの実際の円建て請求額または動画副業への按分額
          − その他費用

したがって、現時点で確定しているのは「売上23,000円」「ツール代控除前の粗利23,000円」「CapCut控除後20,820円」です。ClaudeとCapCutをもともと別用途でも契約しており、この副業を始めても追加費用が増えていないという考え方なら、増分ベースの利益を23,000円と見ることはできます。一方、動画副業単体の月次収支を示すなら、月額費用を差し引く必要があります。Claude費用を含む純利益は、実際の円建て請求額と按分方法を決めてから確定します。

2026年10月5日時点の稼働状況

常駐ジョブと最新ログを確認すると、状態は次のようになっていました。2026年10月5日時点の稼働状況

Discord受付Bot：稼働中。常駐プロセスとして起動し、10月5日も接続を継続
日次インサイト取得：稼働中。毎朝5時45分、10月5日の本体処理は完了
企画候補生成：稼働中。6時5分・6時10分のジョブは直近終了コード0
承認後の公開処理：稼働中。10月4日にInstagram、Threads、X、YouTubeへの公開成功を記録
TikTok投稿：一部でAPIエラーがあり、手動アップロードへ戻る回あり
ブラウザ数値補完：ログイン先や権限により一部取得が不安定
星座・干支の夜間ビルド：時刻どおり起動するが、素材パスやiCloud権限で終了コード1が継続
AIによる後追い考察：10月5日はClaudeの週次上限でスキップ。ただしAPI数値の収集自体は完了

特に重要なのは、「ジョブが登録されている」と「仕事を完了できている」を分けることです。

星座系と干支系の夜間ビルドは、毎晩22時30分、23時30分に起動する設定が残っていました。しかし最新ログでは、素材フォルダの参照やiCloud同期で失敗が続いていました。スケジュールどおりに起動していても、成果物を作れていなければ稼働中とは言えません。

逆に、10月5日の日次分析は、後段のClaudeによる考察が利用上限で止まっても、3媒体のAPI数値取得と台帳更新は完了していました。工程を分けていたため、AI部分が止まってもデータそのものは失われませんでした。

公開処理も同様です。10月4日のログでは、人が承認した後、Instagram、Threads、X、YouTubeは自動公開に成功しました。一方、TikTokは初期化エラーになり、手動対応へ戻っています。

この状態を私は「完全自動化に成功した」とは表現しません。

より正確に言えば、正常系の多くは自動化できたが、外部サービスの認証、利用上限、画面変更、クラウド権限が絡む箇所には、人が気づいて復旧する余地が残っている状態です。

ここから有料部分