ブログ

YouTube APIの1日1万ユニットでやりくりする

2026年10月30日16分で読めます

要約

• 新しい動画はYouTubeチャンネルのRSSで取得します。クォータはかかりません。YouTube APIは、RSSが教えてくれないこと（動画の長さ、ライブの状態、チャンネルアイコン、コメント）を埋めるためと、RSSを取得できなかったときに代替取得するために使います。
• APIで取得したものはチャンネルごとにサーバーにキャッシュし、すべてのユーザーで共有します。そのため、フィードを更新するコストはユーザー数ではなく、異なるチャンネルの数と新しい動画の数に比例します。
• 直近7日間に実際に使った量は701ユニット、1日約100ユニット（上限の1%）でした。まだ正式リリース前なのでユーザーは私一人、チャンネルは40個です。そして、いちばん多く使っていた場所は予想外でした。

2026-10-30 修正：公開後に変わったことがあるので書いておきます。1人が追加できるチャンネルは30です（記事の「40チャンネル」はサーバーのキャッシュにあったチャンネル数です）。未取得のチャンネルも、今はRSSが失敗すると、存在するチャンネルかを先に確認してから代替取得します（11月3日の記事で詳しく）。サーバーのキャッシュにあるYouTubeの情報は、ポリシーの30日より1日早い29日以内に削除します。

2026-11 修正：1人が追加できるチャンネルを100チャンネルに増やしました。アプリは今も30チャンネルずつサーバーに問い合わせます。11月7日にCloudflareの有料プラン（月5ドル）に移行し、1日の予算も増やしました。この記事の「無料プラン」と予算の数字は10月時点のものです。

Plainfeedは、選んだYouTubeチャンネルの新しい動画だけを、おすすめやショートなしで投稿された順に表示するウェブサイトです。サーバーはCloudflareの無料プラン1つで動かしています。

こういうものを作ると最初にぶつかる壁が、YouTube Data APIのクォータです。1プロジェクトにつき1日1万ユニットで、お金を払って増やす方法はありません。増やすには監査を受ける必要があります。この記事は、その1万ユニットの中で登録チャンネルのフィードを回すために下した決定と、その決定が実際にどれだけ持ちこたえているかを数字でまとめた記録です。

先に用語を3つだけ。

• ユニット：YouTube APIを呼ぶたびに減る点数です。プロジェクトごとに1日1万点で、太平洋時間の午前0時にリセットされます。
• RSS：チャンネルごとに公開されている新しい動画の一覧ファイルです。取得してもユニットはかかりません。
• WebSub：新しい動画が投稿されると、Googleがサーバーに知らせてくれる仕組みです。

クォータはこうなっています

まず守るべき条件を整理しました。2026年10月に公式ドキュメントを読み直して確かめた内容です。

ポリシーも2つかかります。APIで取得したデータは30日以内に取得し直すか削除しなければならず（開発者ポリシー III.E.4）、1つのAPIクライアントにはAPIプロジェクトをちょうど1つだけ作らなければなりません（III.D.1.c）。プロジェクトを複数作ってクォータを分け合う道は、最初からないわけです。

Plainfeed側の条件はこうです。1人が追加できるチャンネルは最初は30チャンネルで（アプリはサーバーに30チャンネルずつ問い合わせます）、新しい動画はふつう投稿から30分以内には表示されなければなりません。

素直にAPIで作ると何ユニットか

まず思いつく方法で計算するとこうなります。

実はPlainfeedの初日のバージョンは、1つ目の方法を使っていました。当時はYouTubeのカテゴリ別に最新の動画を集めて表示するサイトで、カテゴリごとに3〜8時間おきにsearch.listを呼んでいました。そのとき書いた設計メモには「1回100ユニット」とあります。1日に数回回すだけでクォータの大部分が消える作りだったので、その日のうちにチャンネルのRSSに切り替えました。コンソールの直近30日の記録に残っているsearch.list 31回がその名残です。

ところが、この記事を書くために公式ドキュメントを読み直したところ、そのメモは書いた日から間違っていました。Plainfeedの最初のコミットより4か月以上前の2026年6月から、search.listは1万ユニットとは別の、1日100回の別枠を使っています。100ユニットだろうと1日100回だろうと、登録チャンネルのフィードをsearchで作れないという結論は同じです。

決定1：新しい動画はRSSで（0ユニット）

結論：新しい動画の一覧は無料のRSSで取得します。クォータはかかりません。

YouTubeにはチャンネルごとに公開のRSSフィードがあります。

https://www.youtube.com/feeds/videos.xml?channel_id=UC...

APIキーもクォータも要りません。公式ドキュメントで説明されているフィードではないので、以下は2026年10月に自分で取得して確かめた内容です。最新の動画15本のタイトル、投稿時刻、再生回数、リンクが入っています。リンクに/shorts/が含まれていればショートなので、長さがわからなくても除けます。今サーバーに取得してある動画590本のうち153本（26%）が、こうして無料で除けました。

ただし、RSSではわからないこともあります。

• 動画の長さ：/shorts/のリンクではない短い動画もあるので、ショートをすべて除くには長さが必要です。
• ライブの状態：今配信中か、予定か、終わった配信か、いつ始まるか。
• 15本より古い動画：1日にたくさん投稿するチャンネルは、古い動画から押し出されます。

それに、ブラウザはYouTubeのRSSを直接読めないので（CORS）、同じサイトのサーバー関数（Cloudflare Pages Functions）がブラウザの代わりに取得します。APIキーもブラウザに置けないので、どのみちサーバーは必要でした。

決定2：APIはRSSでわからないことだけに使う

結論：動画の長さ、ライブの状態、チャンネルアイコン、コメントのようにRSSにないものだけをAPIに聞き、50件ずつまとめて1回1ユニットで済ませます。

videos.listは動画IDを一度に50件まで受け付けるので（リファレンスに数値の記載はありませんが、実際の上限です）、新しい動画50本を1ユニットで確認できます。長さが3分（180秒）以下ならショートとみなして除きます（ライブのアーカイブは短くても残します）。RSSのリンクで除けなかった短い動画が、こうしてさらに73本除けました。

// 取得済みの情報が古くなった動画だけ、50件ずつ聞く（1回1ユニット）。簡略化したコード
for (let i = 0; i < ids.length; i += 50) {
  const body = await api("videos", {
    part: "contentDetails,liveStreamingDetails,snippet,statistics",
    id: ids.slice(i, i + 50).join(","),
  });
  for (const v of body.items) {
    out[v.id] = {
      duration: parseDuration(v.contentDetails.duration),   // 180秒以下ならショート
      state: v.snippet.liveBroadcastContent,                 // live, upcoming, none
      start: v.liveStreamingDetails?.actualStartTime,       // ライブは投稿時刻の代わりに開始時刻を入れる
    };
  }
}

あえてしなかったこともあります。このサイトからすぐにチャンネル登録するボタンは作りませんでした。チャンネル登録の追加（subscriptions.insert）は1回50ユニットで、アカウントへの書き込み権限まで必要になるので、登録はYouTubeでしてもらいます。

決定3：チャンネルごとにキャッシュし、全員で共有する

結論：取得した結果はチャンネル単位で保存し、すべてのユーザーで共有します。ユーザーが増えてもコストはほとんど増えません。

取得した結果はCloudflare D1（SQLite）にチャンネルごとに1行で置きます。その1行の中に、RSSの結果と動画ごとの長さ・ライブの状態、チャンネルアイコンが、取得した時刻と一緒に入っています。

ポイントは、このキャッシュをユーザー同士で共有することです。フィードのリクエストにはチャンネルIDしか入っておらず、キャッシュはチャンネル単位なので、誰がリクエストしたかに関係なく同じ結果を返します。同じチャンネルを登録している人が1人でも1,000人でも、そのチャンネルの動画情報は1回しか取得しません。そのため、クォータはユーザー数ではなく、異なるチャンネルの数と、そのチャンネルが投稿する新しい動画の数に比例します。

APIで取得した情報は、30日のポリシーがあるので長く持っていられません。1日1回動くクリーンアップ処理が、30日以上取得し直せなかった行を削除し、次のリクエストのときにまた取得します。

決定4：新しい動画の通知（WebSub）で待たない

結論：30分ごとに確認する代わりに、新しい動画が投稿されたらGoogleが知らせてくれるようにしました。これも0ユニットです。

RSSを30分ごとに取得し直す方式だと、誰もサイトを開いていない間、サーバーは新しい動画を知りません。そこで、YouTube公式の新しい動画の通知であるWebSub（PubSubHubbub）を付けました。Googleのハブにチャンネルを購読登録しておくと、新しい動画が投稿されたときや、動画のタイトル・説明が変わったときにサーバーへ通知が届き、サーバーはそのチャンネルのRSSだけをすぐに取得し直します。これもクォータはかかりません。

通知は誰でも送れるURLに届くので、内容は信用しません。チャンネルごとに違う秘密の値で署名を確かめ、合っていればRSSを取得し直すだけです。通知が遅れたり抜けたりしたときのために、30分のキャッシュはそのまま残しています。

決定5：第三者が使える量に1日の上限

結論：ログインなしで呼べる機能ごとに、1日の使用量の上限をかけました。

ここまでは普通に使ったときの話です。ところがPlainfeedはログインなしで使えるので、フィード・チャンネル追加・コメントのAPIは誰でも呼べます。自分で点検してみると、チャンネルのURLやコメントの次ページのトークンを変えながら呼べば、数時間でクォータを使い切れる道がありました。

そこで、コストのかかる処理ごとに1日の予算をかけました。

「リクエスト元」はIPをそのまま保存せず、日ごとに変わる秘密のハッシュでだけ区別しています。

全部足すと、コメントとチャンネル検索だけでも運の悪い日には1日4,500〜6,000ユニットまで使われる可能性があります。1万には収まりますが余裕が大きいわけではないので、ユーザーが増えたらまずこの数字から見直すつもりです。

クォータのほかにも、絞らなければならないものが2つありました。

• RSSが失敗したらアップロード一覧（playlistItems.list、1ユニット）で代替取得しますが、以前取得したことのあるチャンネルだけ、1リクエストにつき6チャンネルまでにしています。存在しないチャンネルIDを大量に送られてもクォータを消費させないためです。不正なリクエストでも1ユニットはかかります。
• Cloudflareの無料プランは1リクエストにつき外部呼び出しが50回までなので、アプリは30チャンネルずつに分けて問い合わせます。

try {
  feed = await fetchRss(id);                 // 0ユニット
} catch (e) {
  // 代替取得は以前取得したチャンネルだけ、1リクエストにつき6チャンネルまで、
  // 代替取得まで失敗したチャンネルは1時間休む。簡略化したコード
  if (!known || fallbacks >= 6 || now - failedAt < 3600) throw e;
  fallbacks++;
  feed = await fetchUploads(id);             // playlistItems.list：1ユニット
}

予想と違ったこと

1. クォータをいちばん使っていたのは「代替取得」でした。 直近7日間に使った701ユニットのうち309ユニット（44%）が、RSSが失敗してアップロード一覧で代替取得した分です。RSSは無料なので失敗もめったにないと思っていましたが、違いました。不思議なのは、この記事を書きながら同じ40チャンネルのRSSを自分のパソコンで取得すると、40チャンネルすべてすぐに取得できることです。クラウドのサーバーから呼んだときだけときどき弾かれるようですが、まだ確かめていない推測です。

2. なくなったチャンネルが、リクエストのたびに1ユニットずつ使っていました。 RSSが失敗し、代替取得も失敗し、次のリクエストでまた試す。チャンネルが削除されたり非公開になったりすると、これを延々と繰り返します。代替取得まで失敗したらその時刻を記録しておき、1時間はもう試さないように直しました（上のコードのfailedAt）。

3. 「50件で1ユニット」は最良のケースの話でした。 40チャンネルの新しい動画は1日25本ほどで、7日ごとに確認し直す動画（ショートのリンクではない約440本）を足しても、50件ずつ満杯にすれば1日2回で済みます。ところが、7日間でvideos.listは270回（1日約39回）呼ばれていました。新しい動画はふつう1〜2本ずつ現れ、配信中のライブ（5分）や配信予定を確認し直す処理まで混ざるので、実際にはほとんどの呼び出しにIDが数件しか入りません。呼び出しごとの理由は数えていないので、これも推測です。

4. 自分の設計メモが初日から間違っていました。 前に書いたsearch.listの話です。ルールは私がメモを書く数か月前にすでに変わっていました。数字の入った記事は、公開の直前にドキュメントを読み直すべきだと学びました。

実際に使った量

Google CloudコンソールのYouTube Data APIの指標から、2026年10月29日までの7日間のメソッド別リクエスト数を書き写しました。ここに出てくるメソッドはどれも1回1ユニットなので、リクエスト数がそのままユニットです。

登録チャンネルの読み込みはユーザーのGoogleトークンでブラウザから呼んでいるのに、クォータはPlainfeedのプロジェクトから引かれることも、今回確かめました。

数字を読むときには条件があります。まだ正式リリース前なので実際のユーザーは私一人で、チャンネルは40、開発中に私が直接呼んだ分も混ざっています。人が増えれば数字も増えます。ただ、増える方向は決まっています。同じチャンネルを見る人が増えるのはほとんど無料で、新しいチャンネルとそのチャンネルの新しい動画が増えるときにコストがかかります。

同じ40チャンネルを基準に比べるとこうなります。

しなかったこと、次にすること

• クォータの増加申請はまだしていません。 監査を受ける必要があるので、実際に上限に近づいたら申請するつもりです。
• プロジェクトは分けません。 前に書いたとおり、ポリシー上1つのAPIクライアントに1つのプロジェクトです。
• 代替取得にも別に1日の上限を設けるつもりです。 今は1リクエストにつき6チャンネルと「取得し直し」の予算だけで縛っているので、RSSが大きく止まる日には代替取得がクォータを多く使いかねません。この記事を書きながら見つけた穴です。
• 動画の長さをvideos.batchGetStatsに移す予定です。 2026年6月に新しくできたメソッドで、1万ユニットとは別の1日1万ユニットの枠を使い、動画の長さを返します。ライブの状態は返さないので、配信は引き続きvideos.listで見る必要があります。この記事の事実確認をしていて知りました。
• 古い動画の検索は、アップロード一覧を50件ずつ（1ユニット）取得して30日キャッシュする方式で、必要になったら付ける予定です。search.listはこれからも使いません。

おわりに

クォータを節約するコツは、APIを呼ぶ回数を減らす小技よりも、APIに聞く必要のない作りにありました。新しい動画はRSSと通知で知り、APIはRSSが教えてくれないことを埋め、その結果は全員で共有する。計画どおりにいかなかったところ（RSSの代替取得）が、次に手を入れる場所です。

次の技術記事では、同じサーバーをCloudflareの無料プラン1つで運営しながら、D1の1日の読み書きの上限を他人に使い切られないようにした話を書くつもりです。