自宅のPCを常時起動せずに、スマホからAIでYouTube動画制作を進めたい。この記事では、ChatGPTで台本を作り、Codex CloudにRemotionのコードを書かせ、GitHub Actionsで動画をレンダリングするという構成を、実際に組み立てながら検討した内容をまとめます。
先にお断りしておくと、この記事は「完成した仕組みを紹介する」ものではなく、まだ作っている途中の設計・検討編です。動画投稿を止めずに、少しずつ自動化を進めたい個人開発者向けに、「自分ならこう組む」という現時点の設計図を共有する記事だと思ってください。
こんな人に向けて書いています。
- AIを使ってYouTube動画を作りたい人
- Remotionで動画を生成している人
- 自宅PCをつけっぱなしにしたくない人
- スマホから動画制作を進めたい人
- 副業や個人開発で、確保できる作業時間が限られている人
- Codex CloudやClaude Codeを動画制作に活用したい人
最終的に目指すのは、「スマホでChatGPTに相談 → 指示を出す → クラウド側で動画が組み上がる → スマホで最終確認して公開」という流れです。まずは全体像から見ていきます。
用語だけ先に軽く補足します。RemotionはReact（Webのコードを書く仕組み）で動画を作れるライブラリ、Codex Cloudはクラウド上でGitHubリポジトリのコードを編集してくれるAIエージェント、GitHub ActionsはGitHub上でコマンドを自動実行してくれる仕組みです。それぞれ本文の中でもう少し説明します。
1. 動画を作りながら自動化も進めたい
YouTubeの解説動画を作っていると、まず制作そのものに時間がかかります。テーマを決めて、調べて、台本を書いて、動画にして、確認して……という工程が一通りあって、これだけで1本分の時間はけっこう埋まるんですよね。
そこに「自動化の仕組みづくり」を乗せようとすると、ひとつ困ったことが起きます。自動化を作り込んでいる間、肝心の動画投稿が止まりがちなんです。仕組みを整えるのは大事だけど、そのために投稿ペースが落ちてしまうと本末転倒だなと思っています。
僕の場合、平日に確保できる作業時間は1日おおよそ1時間30分くらい。しかもYouTube以外にブログやアプリ開発もやっているので、動画だけに全部を注ぎ込むわけにもいきません。会社のPCで個人の副業作業はしたくないし、かといって自宅のMacBook Airを一日中つけっぱなしにするのも避けたい。レンダリングのために夜通しMacを回す、みたいなのはやりたくないな、って感じです。
だから方針としては、こう決めました。
- 完全自動化を一気に作ろうとしない
- 動画投稿は止めない
- PCを常時起動する方式は採用しない
- クラウド側で処理が回る形を、段階的に作っていく
要するに、「投稿を続けながら、毎週ちょっとずつ自動化する」という進め方です。この前提が、これから説明する構成の土台になっています。
2. 考えた動画制作フロー
まず、頭の中で組み立てた全体の流れを図にするとこうなります。
スマホでChatGPTに質問
↓
自分がテーマを理解する
↓
「これを動画化して」と指示
↓
動画制作指示書を作成
↓
Codex CloudがRemotionコードを作成
↓
GitHub Actionsで動画をレンダリング
↓
YouTubeへ非公開または限定公開でアップロード
↓
スマホで確認して公開ポイントは、AIの役割を2つに分けているところです。
- ChatGPT：内容の理解、構成の整理、台本作成を担当する（＝人間側の思考を助ける係）
- Codex Cloud：GitHubリポジトリ上のコードやファイルの作成を担当する（＝手を動かす係）
僕は動画を作るとき、まずテーマについてChatGPTに質問して、自分自身がちゃんと理解してから動画化したいタイプです。理解しないまま台本だけAIに書かせても、後で説明が浅くなるのが分かっているので。だからこの工程だけは、スマホからChatGPTと納得いくまでやり取りする、という時間を残しています。
自分が納得したら、「これを動画化して」という形で動画制作指示書に落とし込みます。ここから先、実際のコードを書く部分はCodex Cloudの担当。人間が考える部分とAIが手を動かす部分を、意識的に分けているのがこのフローの肝かなと思っています。
3. Codex Cloudに任せる部分
Codex Cloudには、GitHub上のRemotionプロジェクトのコード作業を任せる想定です。具体的にはこのあたりを考えています。
- GitHub上のRemotionプロジェクトを読み取る
- 台本やシーン構成をもとに、動画のコードを作る
- 字幕や素材の配置を行う
- 横動画版とショート動画版の構成を追加する
- 変更をPull Request、またはコミットとしてGitHubへ反映する
ここで大事にしたいのは、Codexに動画のテーマそのものを考えさせないということです。「面白い動画のネタ出して」みたいな使い方はしません。テーマや構成、伝えたいことは、あくまでChatGPTと自分で詰めておく。Codexにはその決定済みの制作仕様を、Remotionのコードとして実装させる、という役割分担にしています。
誤解のないように書いておくと、Codex Cloudは「動画を丸ごと生成してくれる魔法のサービス」ではありません。あくまでGitHubリポジトリ上のコードを書く担当です。動画そのものを吐き出すというより、「動画を作るためのコードを書き換えてコミットしてくれるエンジニア」に近いイメージで捉えると、期待値がズレにくいと思います。
4. 最後のレンダリングはGitHub Actionsで行う
Codex Cloudが動画のコードを書いてくれても、それだけでは動画ファイル（MP4）にはなりません。コードを実際に実行してレンダリングする工程が別に必要です。ここを担当するのがGitHub Actionsです。
役割を整理するとこうなります。
- Codex Cloud：動画コードを作る担当
- GitHub Actions：完成したコードを実行して、動画に変換する担当
GitHub Actionsは、GitHub側が用意する一時的なUbuntu（Linux）環境の上でコマンドを動かしてくれます。そこでRemotionのレンダリングを実行すれば、自分のMacBook Airを起動しておく必要がありません。処理はクラウド側で完結するので、Macを閉じていても動画が組み上がる、という状態を目指せます。これがこの構成でいちばんやりたかったことです。
あと地味に嬉しいのが、実行結果やログがGitHub上に残るのであとから確認しやすいこと。失敗したときも、同じworkflowをボタンひとつで再実行しやすい。手元でやり直すより気楽なんですよね。
GitHub Actionsのサンプル（説明用）
イメージをつかむために、ごく簡単なサンプルを載せておきます。あくまで構成を説明するためのもので、このままどのプロジェクトにも貼れば動く、というものではありません。実際にはプロジェクト構成やRemotion側のコマンドに合わせた調整が必要です。
# 動画をレンダリングするGitHub Actionsのサンプル（説明用）
name: render-video
on:
workflow_dispatch: # 手動で実行できるようにする
jobs:
render:
runs-on: ubuntu-latest # GitHubが用意する一時的なUbuntu環境
steps:
# 1. リポジトリのコードを取得する
- uses: actions/checkout@v4
# 2. Node.js（Remotionを動かすための実行環境）をセットアップ
- uses: actions/setup-node@v4
with:
node-version: 20
# 3. 必要なパッケージをインストール
- run: npm ci
# 4. Remotionで動画をレンダリング（コマンドはプロジェクトに合わせる）
- run: npx remotion render MyVideo out/video.mp4
# 5. 完成したMP4をArtifact（成果物）として保存
- uses: actions/upload-artifact@v4
with:
name: rendered-video
path: out/video.mp4やっていることは、上のコメントの通りです。「コードを取ってくる → 実行環境を整える → 必要なものを入れる → 動画にする → 成果物を保存する」という素直な流れになっています。Remotionのレンダリングコマンドやアクションのバージョンは変わる可能性があるので、実際に組むときは公式ドキュメントを確認してください。
5. GitHubリポジトリに動画ファイルは保存しない
構成を考えるうえで、ひとつ大事な線引きがあります。それは、GitHubには完成した動画ファイルを置かないということです。
GitHubに保存するのは、こういう「動画を作るための材料」だけにします。
- Remotionのコード
- 台本
- 字幕データ
- シーン構成
- 設定ファイル
- 制作ルール
- 小さな画像素材
逆に、これらはGitHubにコミットしません。
- 完成したMP4
- レンダリング途中の動画
- 大量の音声ファイル
- 一時生成ファイル
- 大容量の動画素材
理由はシンプルで、GitHubはもともと大きなバイナリファイル（動画や音声のような、テキストじゃないファイル）を溜め込む場所として向いていないからです。動画をコミットし続けると、リポジトリがどんどん重くなって扱いにくくなります。
じゃあ完成した動画はどこに置くのか。方針としては、次のいずれかを考えています。
- GitHub ActionsのArtifactに、短期間だけ保存する
- YouTubeへ非公開または限定公開でアップロードする
- 必要に応じて外部ストレージを利用する
言い換えると、GitHubは完成動画の保管場所ではなく、「動画工場の設計図」を置く場所、というイメージです。設計図（コードや台本）はGitHubに、出来上がった製品（動画）は別の場所に。この切り分けを最初に決めておくと、後で構成が破綻しにくいかなと思っています。
6. YouTube APIでアップロードする際の注意点
将来的には、レンダリングした動画をYouTube APIで自動アップロードするところまで考えています。ただ、ここは注意点が多いので、現時点で調べて分かったことを整理しておきます。
まず認証まわり。ここは混同しやすいポイントです。
- 動画情報の取得（再生数を見る、など）に使うAPIキーだけでは、動画をアップロードできません
- アップロードにはOAuth 2.0認証が必要です
- 読み取り専用の権限では、当然ながらアップロードできません
- YouTubeへアップロードするための権限（
youtube.uploadのようなスコープ）を設定する必要があります
次にセキュリティ。
- クライアントシークレットやリフレッシュトークンを、GitHubへ直接コミットしてはいけません
- こうした秘密情報は、GitHub Actions Secretsなどの仕組みで管理します
運用面では、いきなり本番でやらないこと。
- まずは短いテスト動画で、アップロードが通るかを確認する
- 自動で「公開」まで進めず、非公開または限定公開までにとどめる
そして、これは特に押さえておきたい点なのですが、未監査（未確認）のAPIプロジェクトからアップロードした動画は、非公開に制限されるという仕様があります。Googleの公式ドキュメントによると、2020年7月28日以降に作成された未確認のAPIプロジェクトから videos.insert でアップロードされた動画は、非公開（private）モードに制限され、この制限を解除するにはプロジェクトの監査（audit）を受ける必要がある、とされています（YouTube Data API: Videos: insert）。
つまり、監査を通していない個人プロジェクトでは、APIでアップロードした動画はそもそも非公開になる可能性が高い、ということです。これは今回の「非公開または限定公開までにとどめる」という方針とも噛み合っているので、僕としてはむしろ都合がいいなと捉えています。
ただし、この手の仕様は変わる可能性があります。公開前には必ずYouTube Data APIの公式ドキュメントやGoogle/YouTubeの公式資料を確認して、最新の仕様に合わせてください。この記事の内容も、あくまで2026年7月時点で確認できた範囲のものです。
7. CodexとClaude Codeを切り替えられる構成にする
もうひとつ考えているのが、AIエージェントを切り替えられるようにしておくという保険です。
Codex Cloudには利用制限があるので、上限に達したときに作業が止まってしまうと困ります。そこで、Codexが使えないときはClaude Codeに切り替えて作業を続けられるように、GitHubを共通の作業場所にしておく、という考え方です。
そのために、リポジトリにこういうファイルを置いておくイメージです。
AGENTS.md … AIエージェント共通の前提・ルール
CLAUDE.md … Claude Code向けの補足指示
docs/AI_RULES.md … 制作全体で守るルール
docs/VIDEO_WORKFLOW.md … 動画制作フローの説明
episodes/対象動画/HANDOFF.md … その動画の引き継ぎメモポイントは、会話履歴を引き継ごうとしないことです。「さっきまでChatGPTと話していた内容」をそのままCodexやClaudeに渡すのは現実的じゃありません。そうではなく、GitHub上の仕様書・コミット履歴・HANDOFF.mdを「引き継ぎ資料」として使う。どのAIが作業に入っても、そのリポジトリを読めば「今どういう状態で、次に何をすればいいか」が分かる、という状態を目指します。
この記事の主題はあくまでCodex Cloudを使った動画制作なので、Claude Codeの話はここまでにしておきます。要は「作業場所をGitHubに固定しておけば、道具は差し替えられる」という発想です。
8. 一気に完全自動化しない
ここまで書いてきた構成を、最初から全部作ろうとは思っていません。作っている間に投稿が止まるのを避けたいので、段階的に進めます。今考えている計画はこんな感じです。
第1段階
- GitHubとCodex Cloudを接続する
- Codexが既存のRemotionプロジェクトを読める状態にする
- 動画コードの作成まで任せる
- レンダリングは、これまで通り手動でもよい
第2段階
- GitHub Actionsで、ショート動画1本だけをレンダリングしてみる
- 出来上がったMP4を、Artifactとして確認する
第3段階
- 横動画1本とショート3本の構成に対応する
- 音声生成もクラウド処理へ移す
第4段階
- YouTube APIで、非公開または限定公開のアップロードを試す
- スマホのYouTube Studioで確認して、最終的な公開は手動で行う
方針としては、動画投稿を止めず、毎週1工程ずつ自動化するくらいのペースを想定しています。1週間で1個の工程がクラウドに移れば十分、という気持ちでいれば、投稿を続けながらでも着実に進められるかなと思っています。
9. 現時点での構成
というわけで、現時点でまず目指しているのは、次のような役割分担です。
- ChatGPT：テーマの理解、調査、台本、制作指示書
- Codex Cloud：Remotionコード、字幕、シーン構成の作成
- GitHub：コード、台本、制作ルールの管理
- GitHub Actions：音声生成、動画レンダリング
- YouTube：完成動画の非公開または限定公開での保存
- スマホ：指示、進捗確認、最終公開
人間（＝自分）がやるのは、ChatGPTと一緒にテーマを理解して指示を出すところと、最後にスマホで確認して公開するところ。その間の「手を動かす作業」を、少しずつクラウド側に寄せていく、という構図です。
繰り返しになりますが、これはまだ全部が動いている状態ではありません。あくまで「この形を目指す」という現時点の設計です。
10. まとめ
長くなったので、考えてきたことをまとめます。
- 最初から完全自動化を目指さない
- 動画投稿を継続しながら、少しずつ自動化していく
- Macを常時起動しなくても、クラウド構成は作れる
- GitHubには完成動画ではなく、コードや設計データを保存する
- まずはCodex Cloudが既存プロジェクトを読み、動画コードを作れるところから始める
こうやって書き出してみると、いきなり「全自動の動画製造マシン」を作るんじゃなくて、設計図をGitHubに置いて、手を動かす部分を1つずつクラウドに移す、という進め方が自分には合っているなと感じました。作業時間が1日1時間30分しかないからこそ、一気に作るより、止めずに少しずつ、が現実的かなって思います。
コメント