Google CloudとAWSを駆使してYouTube Liveの配信スケジュール作成自動化をやってみた

2026年5月1日 00:01

　基本的にコードは書けないインフラ専門エンジニアのあたしが、Google Cloud（YouTube API）とAWS（Lambda）を連携させて、面倒な配信予約作業を「完全放置」に変えた記録をまとめます。

1. 導入：なぜ自動化が必要だったのか

　こちらが我が家のシステム構成図です。

物騒なご時世柄、我が家には防犯カメラを何台か置いています。カメラに挿入しているmicroSDカードでも2週間分ほどのデータは残せますが、モーション検出した部分しか記録できません。本来、長時間の録画データをそのまま残したいのであれば、iSPYやHiP2P Clientといった専用ソフトウェアを使ってNASなどに保存するのが定石です。

でも、Disk容量がばかにならないんです。

そこで、ストリーミングのデータをYouTubeにライブ配信するのと、NASにモーション検出部分を保存するという運用を思いついて実装しました。

理想的なはずだった「YouTubeストレージ」活用

　メインの録画データはYouTubeのアーカイブ機能に任せる。これならDisk容量を気にせず、無料で半永久的にデータを残せます。
ところが、ここで大きな壁にぶち当たりました。

YouTube Liveには「アーカイブとして保存される動画は12時間まで」という仕様上の制限があるんです。
24時間の記録をすべてアーカイブとして残すためには、1日を2つの枠（11時間58分ずつ）に分割して配信しなければなりません。つまり、毎月「1日2回 × 31日＝計62個」もの配信枠を、事前にYouTube Studioで作っておかなければならないということ。

結局、最後は「筋肉（手動）」なのか？

　YouTube Studioには「以前の設定を再利用」という機能があるので、実は1枠あたりの作業はたった5クリック程度で済みます。

「なんだ、5回クリックするだけなら簡単じゃん」

あたしも最初はそう思っていました。でも、相手は1ヶ月分で計62枠です。 5クリック × 62回＝ 310クリック。

これを毎月、ポチ、ポチ、ポチとやるだけであたしの貴重な時間が溶けていきます。これは不毛、なにより単純に面倒くさい！！。

このオレンジ色の枠で囲った「事前配信スケジュール」の作成。ここをAPIで自動化して楽をしよう！ということでGeminiさんの力を借りながら、あたしの自動化への挑戦が始まりました。

2. システム構成：オンプレミスとクラウドの役割分担

　自動化の話に入る前に、オンプレミス側の構成をもう少し詳しくお話しします。

このシステム、実は最初からこうだったわけではありません。何度もあった録画失敗のたびに、その原因を潰すための対策を積み重ねてきた、結構「泥臭い」運用で支えられています。

Windowsタスクスケジューラという名の司令塔

　サーバ（Windows）側では、いくつかの自作バッチファイルが連携して動いています。

0:00 / 12:00（OBS起動バッチ）
定刻になったらOBS Studioを叩き起こして配信をスタートさせます。
0:02（ディレクトリ作成バッチ）
カメラ側の「フォルダ作成機能」がたまに機嫌を損ねてコケるので、サーバー側からSMB経由で先に「yyyyMMdd」フォルダを強制作成しておきます。
30分毎（死活監視バッチ）
これが大事。バッチでOBSのプロセスが生きているかを定期的にチェック。もし不慮の事故で落ちていたら、即座にRerun（再起動）して配信の空白を最小限に抑えます。

配信は「11時間58分」で強制kill

　YouTubeの12時間アーカイブ制限を回避するため、配信は11時間58分で一度バッチ側から強制終了しています。
そして数分後の0:00や12:00に、また次のバッチが起動する……。この「1日2サイクル」を完璧に回すには、YouTube側に空の配信枠があらかじめようしされていなければなりません。

この「配信枠」を自動生成するために、いよいよGoogle CloudとAWSの出番です。

こちらはシステム構成図のオレンジの部分をシステム化したクラウドの構成図です。
次章以降で詳細や設定手順について解説していきます！

3. YouTube APIの基礎知識：Google Cloudという「窓口」を理解する

なぜ Google Cloud Console（GCC）が必要なの？

　YouTubeはGoogleのサービスなので、プログラム（今回はAWS Lambda）からYouTubeを操作するためには、Google側の「窓口」で許可をもらう必要があります。

その窓口の管理画面が Google Cloud Console（GCC） です。ここで「あたしの作ったプログラムが、あたしのYouTubeチャンネルにアクセスしますよ」という登録を行い、通行証（認証情報）を発行してもらうわけです。

YouTube Data API v3 は何をするもの？

　「API」は、プログラムがサービスとやり取りするための専用の入り口です。 YouTube Data API v3 を使うと、ブラウザで YouTube Studio を開かなくても、以下のようなことがプログラムからできるようになります。

ライブ配信の予約枠（Broadcast）を作る（← 今回のメイン！）
作った枠を再生リスト（Playlist）に追加する
動画のタイトルや説明文を更新する

つまり、あたしが毎月310クリックしていた作業を、「このタイトルとこの時間で枠を作って！」と1行の命令（APIリクエスト）で済ませるための魔法の杖、それがこのAPIなんです。

APIは無料なの？

　「APIを叩く」と聞くと、従量課金が怖い……と思うかもしれませんが、ご安心を。 YouTube Data API v3には1日あたり10,000ユニットの「クォータ（無料枠）」が設定されています。配信枠を1つ作るのに消費されるのは約50ユニット。1日2枠、1ヶ月分（62枠）をまとめて作ったとしても合計3,100ユニット程度です。つまり、個人利用の範囲内であれば、余裕で無料枠の中に収まります。 お財布に優しいのも、この自動化のいいところですね。

4. 構築開始！Google Cloud設定からリフレッシュトークン取得まで

■ YouTube Data API v3を有効にする

　まずはGoogle Cloud Consoleでプロジェクトを作成し、ライブラリから「YouTube Data API v3」を探し出して有効化します。

これを使わないことには始まりません。青いボタンを思い切ってポチります。

■ OAuth 同意画面の設定（アプリの器を作る）

　APIを有効にしたら、次は「誰がこのAPIを使うのか」を設定するためにサイドメニューから「OAuth 同意画面」に移動します。

設定を開始すると、アプリ情報の入力を求められます。

ここで入力する「アプリ名」などは、自分が後で見てわかればOKです。あたしは「YouTubeLiveAutomation」と名付けました。

ユーザーの種類は、自分専用なので「外部」を選択しておけば大丈夫です。

連絡先情報も自分自身のメールアドレスを入れて進みます。

最後にポリシーへの同意チェック。ここを乗り越えれば設定完了まであと一息！

■ クライアントID（秘密の鍵）の発行

　同意画面の設定が終わったら、いよいよプログラムが使うための「クライアントID」を発行します。
サイドメニューの「クライアント」から、「クライアントを作成」をクリックします。

ここで「アプリケーションの種類」を聞かれます。今回はAWS Lambdaから実行しますが、認証の仕組み上、一旦「デスクトップアプリ」を選択すればOKです。名前は「YouTube-AWS-Connection」など、用途がわかるものにして「作成」をポチります。

これで無事に、AWSからYouTubeを操作するための「鍵」が生成されました。

最後に、今作ったクライアント情報をJSON形式でダウンロードしておきます。

このファイル、後でPythonコードの中で読み込ませる超重要書類です。「デスクトップに置いたまま忘れてた」なんてことにならないよう、安全な場所に保管しましょう。

クライアントIDを発行してJSONをダウンロードしたら、そのままPythonのインストールへ……といきたいところですが、ここで絶対にやっておくべき「エラー回避の儀式」があります。

今のままだと、作成したアプリ「YouTubeLiveAutomation」は「テスト中」というステータスになっています。この状態でリフレッシュトークン（後述する「合鍵」のようなもの）を作ろうとすると、高確率で下記のエラーに遭遇してしまいます。

「エラー 403: access_denied」
あなた、テストユーザーに登録されてませんよね？アクセスさせませんよ。
と、しっかりハマった件

特にブランドアカウントで配信している場合、Googleアカウントのメールアドレスと厳密に一致しないと判断され、この鉄壁のガードに弾かれてしまいます。あたしもここでしっかりハマりました（笑）

これを回避するために、Google Auth Platformのメニューから「対象」に進みます。

「アプリのステータス」が「テスト中」になっているので、その下にある [アプリを公開] ボタンをクリックしましょう。
「本番環境に push しますか？」という確認画面が出るので、迷わず「確認」を押します。

これでステータスが「本番環境」に変わりました。

「本番環境」といっても、Googleの審査を通していない未審査状態ですが、これでようやく自作アプリ特有の「詳細」リンクから強制的に認証を進めることが可能になります。

■ Pythonのインストールとライブラリの導入

　ここからローカルPCでの作業です。Pythonが必要なので環境がない場合は構築します。

まずは自分のPCにPythonがインストールされているか確認します。コマンドプロンプトやPowerShellで、以下の呪文を打ってみてください。

python --version

ここでバージョン番号が出ればOK。エラーになった場合は、インストールされていないか、環境変数のパスが通っていません。

環境がない場合は、公式サイトから最新の安定版（2026年4月時点では 3.14）をダウンロードしてインストールします。

インストール中、いくつか選択肢が出てきますが、基本的には「y（Yes）」で進めて大丈夫です。 ただし、一点だけ絶対に見逃してはいけないのがこれ。

Add Python to PATH に必ずチェックを入れる（yを入れる）

これを忘れると、後で「pythonコマンドが効かない！」と泣くことになります。

Pythonが無事にインストールできたら、YouTube APIとの橋渡しをしてくれるライブラリをインストールします。

pip install google-auth-oauthlib

これで、Google Cloud Consoleで発行した「鍵」をコードから扱えるようになります。

■ リフレッシュトークンの作成(Google Cloud側の作業終わり)

　デスクトップなどの適当な場所に、get_token.py という名前で以下のコードを保存します。 CLIENT_ID や CLIENT_SECRET は、先ほどダウンロードしたJSONファイルか、Google Cloud Console（GCC）の画面で確認した値をコピペしてください。

from google_auth_oauthlib.flow import InstalledAppFlow

# Google Cloud Console (Google Auth Platform) で取得した値をコピペ
CLIENT_ID = "あなたのクライアントID.apps.googleusercontent.com"
CLIENT_SECRET = "あなたのクライアントシークレット"

# YouTubeを操作するための権限設定
SCOPES = ['https://www.googleapis.com/auth/youtube.force-ssl']

def get_refresh_token():
    flow = InstalledAppFlow.from_client_config(
        {
            "installed": {
                "client_id": CLIENT_ID,
                "client_secret": CLIENT_SECRET,
                "auth_uri": "https://accounts.google.com/o/oauth2/auth",
                "token_uri": "https://oauth2.googleapis.com/token",
            }
        },
        SCOPES
    )
    
    # ローカルサーバーを立ち上げて認証
    # ブラウザが自動で開き、ログインを求められます
    creds = flow.run_local_server(port=0)
    
    print("\n" + "="*50)
    print("【AWSの環境変数に設定する値】")
    print(f"REFRESH_TOKEN: {creds.refresh_token}")
    print("="*50)
    print("\n※このリフレッシュトークンは大切に保管してください。")

if __name__ == "__main__":
    get_refresh_token()

ターミナルやPowerShellを（念のため管理者権限で）開き、スクリプトを保存した場所へ移動して実行します。

python get_token.py

実行するとブラウザが自動的に起動し、Googleのアカウント選択画面が表示されます。
ここで YouTubeにライブ配信を行っているアカウント（ブランドアカウント） を間違えずに選択してください。

権限を「許可」して進んでいくと、ブラウザに「認証が完了しました」と表示され、ターミナルの方には……

REFRESH_TOKEN: 1//...

という、非常に長い文字列が表示されているはずです！これこそが、あたしたちが求めていた「合鍵」です。この文字列は後でAWS Lambdaの設定に使うので、メモ帳などに大切に保管しておいてください。

これでGoogle側の設定は正真正銘、すべて完了です！お疲れ様でした！

5. クラウド連携の完成：AWS LambdaからYouTube APIを叩く

　「認証にGoogle Cloudを使うなら、そのままGoogle Cloud Functionsを使えばいいじゃん！」という声が聞こえてきそうですが、そこはあえてのマルチプラットフォーム構成です。

お仕事柄、普段から触れ合っていて（多少の）知識と経験があるのはAWS。自分の手に馴染んだインフラで制御したいというエンジニアとしてのこだわり、そして「Google Cloud × AWS」という異なるクラウドを連携させるワクワク感から、今回の構成に落ち着きました。

■ AWS Lambdaという「実行部隊」を整える

　まずはAWSコンソールにログインし、Lambda関数を作成します。

「関数の作成」をポチッと押して、基本情報を入力していきます。
「その他の設定」は特に考慮しなくてもいいです。

「関数の作成」を実行すると、コードエディタが配置された関数のメイン画面に切り替わります。

デフォルトの3秒設定では、複数件の配信予約リクエストを順次処理する場合、デフォルトの3秒では確実にタイムアウトしてしまうため、「設定」タブの一般設定→編集からタイムアウト値を変更します。

タイムアウトを2分に設定。これで大量の配信予約リクエストにも耐えられるタフな設計に。

タイムアウト設定に続いて、同じ「設定」タブの流れで環境変数もセットしてしまいましょう。
Google Cloudで苦労して手に入れた「合鍵」たちを、安全にLambdaへ持たせる重要なステップです。コードへの直書き（ハードコーディング）を避け、セキュリティを担保するお作法。

「環境変数の追加」をポチポチと押して、以下の3つのキーを作成します。値の欄には、Google Cloudから取得したそれぞれの値を正確に貼り付けます。

CLIENT_ID
CLIENT_SECRET
REFRESH_TOKEN

CLIENT_ID、CLIENT_SECRET、REFRESH_TOKENの3点セットを登録。

これで、プログラム（Python）からいつでも安全にYouTube APIを叩きにいける準備が整いました。

■ 疎通テスト用コードの作成とライブラリの準備

　次は、YouTube APIを動かすための「心臓部」を作ります。今回はテストとして、プログラム（Lambda）からYouTube APIを叩き、「2026年大晦日の配信枠を、非公開で1つ作る」という動作を目指します。

ここで、今回はあえて汎用ライブラリ（Layerなど）に頼らず、ローカル環境でビルドした自前のライブラリ一式をデプロイする手法をとります。理由はシンプル。「自分の手でビルドしたものが、一番確実だから」です。

まずは、ローカルの作業フォルダに lambda_function.py というファイルを作成し、以下のコードを貼り付けておきましょう。

import os
import json
from google.oauth2.credentials import Credentials
from googleapiclient.discovery import build

def lambda_handler(event, context):
    # 1. AWSの環境変数から「3つの神器」を読み込む
    # 設定タブで登録した名前と一致させてください
    client_id = os.environ.get('CLIENT_ID')
    client_secret = os.environ.get('CLIENT_SECRET')
    refresh_token = os.environ.get('REFRESH_TOKEN')

    # 2. Google API用の認証情報オブジェクトを作成
    creds = Credentials(
        None,
        refresh_token=refresh_token,
        token_uri="https://oauth2.googleapis.com/token",
        client_id=client_id,
        client_secret=client_secret
    )

    # 3. YouTube APIサービスを構築
    youtube = build('youtube', 'v3', credentials=creds)

    try:
        # 4. ライブ配信枠（Broadcast）の作成
        # ここではテストとして2026年の大晦日に非公開枠を作ります
        request = youtube.liveBroadcasts().insert(
            part="snippet,status",
            body={
                "snippet": {
                    "title": "AWS Lambda 疎通テスト",
                    "scheduledStartTime": "2026-12-31T00:00:00Z",
                    "description": "AWS Lambdaからの自動作成テストです"
                },
                "status": {
                    "privacyStatus": "private" # テストなので非公開
                }
            }
        )
        response = request.execute()
        
        print(f"Success! Broadcast ID: {response['id']}")
        
        return {
            'statusCode': 200,
            'body': json.dumps({
                "message": "成功しました！YouTubeに枠が作られました。",
                "broadcast_id": response['id']
            }, ensure_ascii=False)
        }

    except Exception as e:
        print(f"Error: {str(e)}")
        return {
            'statusCode': 500,
            'body': json.dumps({
                "message": "エラーが発生しました",
                "error": str(e)
            }, ensure_ascii=False)
        }

コードの準備ができたら、次はこのコードが依存している「ライブラリ（google-api-python-clientなど）」を揃えます。

ここで、Windows環境でそのまま pip install してしまうと、LinuxベースのLambdaでは動かない「Windows版」がダウンロードされてしまう罠があります。そこで、manylinuxオプションをつけて、Lambda（Linux）と互換性のあるライブラリを強制的に作成していきます。

Windows環境のターミナル（管理者）を開き、作業フォルダへ移動したら、以下のコマンドを実行してください。

mkdir my-lambda-layer
cd my-lambda-layer
pip install --platform manylinux2014_x86_64 --target . --implementation cp --python-version 3.14 --only-binary=:all: --upgrade google-api-python-client google-auth-oauthlib

このコマンドが実行されると、今いるフォルダの中にgoogleapiclientやgoogleといったフォルダがドバっと展開されます。

これで、「Linux環境（Lambda）で動く、Python 3.14用の、YouTube APIライブラリ一式」が手元に揃いました。あとは、先ほど作成した lambda_function.py と一緒にZIPで固めてアップロードするだけです。
ここで注意点ですが、フォルダそのものをZIPにするのではなく、中身のファイル群を直接選択してZIPにするのがコツです。そうしないと、Lambda側で「ファイルが見つかりません」というエラーになります。

ZIPができたら、AWS Lambdaのコンソールからアップロードします。

「コード」タブの右側にある「アップロード元」から「.zipファイル」を選択します。

■ 運命の疎通テスト：YouTube Studioに枠は現れるか？

アップロードが完了したら、いよいよ実行です。

「テスト」タブを開き、テストイベントを作成します。名前は何でもOK、JSONも今回は使わないので、デフォルトのままで大丈夫です。
画面右上の「テスト」ボタンを、祈りを込めてクリック！

実行結果を確認します。
実行結果に「statusCode: 200」と、作成されたBroadcast IDが表示されれば、AWS側の仕事は完璧です！

「成功」の文字とともに、ステータスコード200が返ってきました！
Broadcast IDもしっかり発行されています。

AWS側で「成功」が出たら、すぐにYouTube Studioの管理画面（ライブ配信一覧）をリロードしてみます。

ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!

画面に非公開の配信枠が正しく現れた瞬間の達成感。これこそが、Google CloudとAWSという2つの巨人が、あたしの書いたコードで繋がった証拠です。

6. 運用開始：EventBridgeで自動化のサイクルを回す

　テストで動作が確認できたら、あとは「いつ実行するか」をAWSに教え込むだけです。今回は「毎月1日の午前9時（JST）」に自動で配信枠を作る設定にしてみます。

■ トリガーの追加

　　Lambda関数のトップ画面にある「関数の概要」から設定を始めます。
「＋トリガーを追加」をクリックして、自動実行の仕組みを組み込みます。

■ EventBridgeの設定

　トリガーの設定に「EventBridge (CloudWatch Events)」を選択。

■ スケジュール式の入力（cron）

　「スケジュール式」はcronで設定します。
ルール名「MonthlyYouTubeSchedule」を作成。
スケジュール式には cron(0 0 1 * ? *)（UTC基準で毎月1日午前0時＝日本時間午前9時）と入力します。

ここで一つ注意。AWSのスケジュール式はUTC（協定世界時）基準です。日本時間の午前9時に動かしたい場合は、9時間を引いた「午前0時」を指定する必要があります。昔メインフレームのIPLでJSTとGMT(UTCと同じ)を間違えて起動した人のミラクルなお話を聞いたのを思い出します（汗）

■ 自動化、完了！

　最後に「追加」ボタンを押すと、関数の概要図にEventBridgeが連結されます。これで「毎月1日になると勝手にYouTubeの枠ができる」魔法の仕組みが完成しました！

後は、大みそかに配信スケジュールを作成するテスト仕様から本番仕様にコードを一部書き換えてデプロイ。これで準備は万端、初回起動の5/1が楽しみです！

最後に最も重要なこと。コードを本番用に書き換えたら、必ず『Deploy』ボタンを押して反映させましょう。これを忘れると、せっかくの苦労が『最新の状態』として保存されません！

7. おわりに：2.5時間の「遊び」が、未来の「数千クリック」を救う

　今回のシステム構築にかかった時間は、スクリーンショットのタイムスタンプを振り返ってみると約2時間半。

その大半はGeminiさんとの相談タイムでしたが（笑）、このわずかな時間で、これから毎月発生するはずだった「300回のクリック」という苦行から完全に解放されました。

これこそが、あたしたちエンジニアが目指すべき「等身大のDX」じゃないかな、なんて思っています。

最初は「Google CloudとAWSを繋ぐなんて面倒そう……」と腰が重くなるかもしれません。でも、一つ一つのドットを線で結んでいけば、必ず思い通りの形になります。異なるクラウドの「いいとこ取り」ができるのは、マルチプラットフォームを使いこなす現代のエンジニアだけの特権です。

……さて、無事に自動化は完了しましたが、エンジニアのサガというか、お仕事と同じで「完成した瞬間、次の課題が生まれる」んですよね。

「このLambda、ちゃんと動いてるかDatadogでコスト監視しなきゃな」とか、「オンプレのダッシュボードに統合したいな」とか……。

やりたいことが次から次へと溢れてくる。お仕事と同じで終わりがない！（憤怒）

でも、そんな「次」を考えられるのも、一つ仕組みを完成させて「余裕」を作れたからこそ。

あたしの「楽をしたい」探求と、情シスとしての奮闘記はまだまだ続きます。

なんか記録をつけていたら1万字を超えているウルトラ長文になってしまっているんですが、最後まで読んでいただき、ありがとうございました！

追記：コケましたｗ

　うまくいきませんね。続きはこちら。