はじめに
特定のYouTubeチャンネルの「配信予定」「ライブ実績」「Shorts」「動画投稿」を監視する際、search.list を使用することがあります。
YouTube Data API v3の公式計算ツールを確認すると分かりますが、search.list は 1リクエストあたり100クォータ を消費します。無料枠（1日10,000クォータ）では1日に100回しか実行できず、頻繁な更新チェックには不向きです。
qiitaを含め日本語の記事を探しても、自動生成プレイリストを利用するか、クォーター制限の解除申請が主だった手段として上げられています。
私の環境で自動生成プレイリストを使った実装を試してみましたが上手くい来ませんでした。
本記事では、2026年02月07日現在の公式ドキュメントの仕様に基づき、activities.list と videos.list を組み合わせてコストを抑える手法をメモとして残しておきます。
手法
2ステップで実装します。
-
activities.listでチャンネルの最新アクティビティを取得する - 取得したIDをもとに
videos.listで詳細情報を一括取得する
クォータ消費の比較
| メソッド | 消費クォータ | 備考 |
|---|---|---|
| search.list | 100 | 検索条件を指定可能だが極めて高コスト |
| activities.list | 1 | チャンネルの更新フィードを取得 |
| ideos.list | 1 | 最大50件の動画詳細を一括取得可能 |
この手法なら、1回のリクエストセット（1+nクォータ）ですみます。search.list と比較して 90%のコスト削減 が可能です。
メリットと技術的根拠
-
videos.listによる高効率な詳細取得videos.listは、id パラメータに複数の動画IDをカンマ区切りで指定することで、最大50件の情報を一度に取得できます。これにより、複数の配信予定や投稿動画の詳細をわずか 1クォータ で網羅できます - 正確な配信ステータスの判定
videos.listのレスポンスに含まれるliveStreamingDetailsを参照することで、以下の状態を厳密に区別できます
- 配信予定:
scheduledStartTimeがあり、actualStartTimeが未設定。 - ライブ配信中:
actualStartTimeがあり、actualEndTimeが未設定。 - アーカイブ/動画:
actualEndTimeが設定されている、またはliveStreamingDetails自体が存在しない。
リスクと対策：50件の壁
activities.list の maxResults は最大 50 です。
そのため、以下のリスクに注意が必要です。
⚠️ 取得漏れのリスク前回の取得から今回の取得までの間に、対象チャンネルで「動画投稿」「いいね」「プレイリスト追加」などのアクティビティが 50件以上 発生した場合、古い更新情報（配信予定など）がレスポンスの1ページ目から押し出され、取得漏れが発生する可能性があります。
ここはクォーター消費とのトレードオフです。
回避策：ページネーションの利用公式の Pagination ガイド に従い、レスポンスに含まれる nextPageToken を使用して次のページを取得することで、51件目以降のアクティビティも遡って確認することが可能です。ただし、activities.list で検知したいのは主に snippet.type が upload のものです。配信者が短時間に大量の「いいね（like）」を公開設定で行うとフィードが埋まるため、定期的な実行と適切なページ取得が推奨されます。
nextPagetokenを使用した場合、1ページにつき1クォーターを消費します。
10分に1回、2ページずつ取得したとしても、1日あたり432クォータの消費です。理論上は1つのAPIで20のチャンネル監視が可能と考えれば悪くは無いのかなと。
（activities.list *2 + videos.list = 3クォーター/1回 *6回/時間 * 24時間/日）
まとめ
- search.list を避けるだけでクォータ寿命が 10〜50倍 に伸びる
- activities.list で更新を検知し、videos.list で詳細を叩くのが無難そう
- 大量更新による取りこぼしは nextPageToken でケアする