はじめに

特定の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 でケアする

参照リンク（公式ドキュメント）