GeminiDesktop GeminiDesktop
ガイド

YouTube チャンネル AI 自動要約 2026：購読＋Atom feed＋Gemini で知識の流し台

公開日 · 著者： GeminiDesktop Team

YouTube チャンネル AI 自動要約 2026：購読＋Atom feed＋Gemini で知識の流し台

結論から： AI 系 YouTube を 20 チャンネル購読している、というのは控えめな見積もりです。でも実際に全部見られる確率はゼロ。頑張って追うのではなく、流し台を一本作って AI に代わりに見てもらいましょう —— 購読リスト → Atom feed ポーリング → Gemini ネイティブ YouTube 理解 → タイムスタンプ付き Markdown → Obsidian vault。YouTube Data API も yt-dlp もいりません。Mac のバックグラウンドプロセス一つで回ります。

一言で： YouTube の公開 Atom feed + Gemini の fileData.fileUri による YouTube ネイティブ理解 = クォータ 0・字幕スクレイピング 0 の AI 要約パイプライン。

AI チャンネルを 20 個購読しているのに、見きれない

ご自身の購読リストを思い浮かべてみてください。Lex Fridman、Two Minute Papers、Yannic Kilcher、bycloud、AI Explained、Matthew Berman、MLST…… すぐに 20 を超えるはずです。毎週合算すると 30〜50 本、1 本あたり 30〜90 分のコンテンツ量です。

事実を直視すると、あなたは「全部見たい」わけではなく、「どの動画で何が語られているかを知って、深掘りするべき 2〜3 本を選びたい」だけ なのです。典型的な「要約 → スクリーニング → 深読」のじょうごで、最初の 2 段階は AI に任せて、本当の注意力は最後にだけ使えば十分です。

だからこそ Gemini Desktop を常駐プロセスとして走らせるのをおすすめします。設定したチャンネルリストを継続監視し、新しい動画が上がってから数分以内に構造化要約を生成、指定したローカルフォルダに書き込みます。朝の一杯のコーヒーの間に昨晩の動画が全部まとまって読めるので、YouTube の再生リストを順にクリックするより圧倒的に効率的です。

なぜ YouTube Data API を使わないのか

YouTube 自動化の初心者はまず YouTube Data API v3 に手を伸ばしますが、実装してみるとすぐ痛みを知ります。

項目 YouTube Data API v3 YouTube Atom Feed
認証 Google Cloud プロジェクト + OAuth 同意画面 不要、公開 HTTPS GET のみ
クォータ 1 日 10,000 units、search.list で 100 units/回 実質制限なし（常識的な間隔で）
購読リスト取得 ユーザー OAuth scope が必要 自分で channel ID リストを組むだけ
安定性 クォータ超過でプロジェクト全体停止 Google 公開サービス、安定性高
向いているケース 書き込み操作（投稿・いいね・コメント） 読み取り専用の新着監視

Atom feed の URL はシンプルそのもの —— https://www.youtube.com/feeds/videos.xml?channel_id=UCxxxxxxxxxxxxxxxxxxxxxx —— 返ってくるのは標準的な Atom 2.0 文書で、最新 15 本の <entry> が含まれます。各 entry には videoId、title、published、author、media:description があり、「新しい動画はあるか」を判断するのに必要な情報が全部揃っています。

Go なら github.com/mmcdole/gofeed で 1 行、Node なら fast-xml-parser か 20 行の正規表現で充分。feed のサイズはたいてい 50KB 以下で、4 時間ごとのポーリングは先方サーバーにも自分の帯域にも優しい負荷です。

Gemini fileData.fileUri は YouTube をネイティブに読む

2024 年以前、「AI で YouTube を要約」の定番スタックは、yt-dlp で字幕を抜く → 整形 → GPT に投げる → 要約、でした。慢性的な問題が 2 つ:

  1. 字幕がない動画は処理できない。 教材・インタビュー系は字幕を公開していないものが多く、自動字幕の精度も不安定
  2. 運用コストが高い。 yt-dlp は YouTube のスクレイピング対策更新に追随する必要があり、依存関係を毎月数回は更新する羽目に

2025 年に Gemini が fileData.fileUri を公開して状況が一変しました。この API は YouTube URL を直接入力として受け付け、デコード・ASR・視覚理解をサーバー側で丸ごと処理してくれます。渡すのは URL 文字列 1 本だけ。

エンジニアリング的な直接的メリットは 2 つ:

  • 字幕スクレイピング不要。 Gemini 自身の ASR は YouTube 自動字幕より精度が高く、特に英語のテックポッドキャストで差が出ます
  • 視覚コンテンツも要約に入る。 画面上のコード、ホワイトボード、スライドを Gemini が実際に見て引用できるため、字幕だけでは落ちていた重要情報が拾えます

最小限のリクエストはこんな形:

{
  "contents": [{
    "parts": [
      { "fileData": { "fileUri": "https://www.youtube.com/watch?v=XXXXXXXXX" } },
      { "text": "タイムスタンプ付きの日本語要約。TL;DR・要点・引用を含める。" }
    ]
  }]
}

Gemini 2.5 Flash で 30 分動画の処理が 20〜40 秒、コストは Whisper 文字起こし + Claude 要約の旧スタックに比べて大幅に安価です。

設定：channel ID、出力フォルダ、ポーリング間隔

24 桁の UC から始まる channel ID の見つけ方

チャンネル ID は 24 桁・UC 始まりの固定文字列です（@ハンドルではありません）。3 つの取得方法:

  1. チャンネルトップのソースを表示し "externalId":"UC で検索
  2. YouTube Channel ID Finder のようなツールにチャンネル URL を貼り付けて逆引き
  3. チャンネルページで RSS リンクをコピー、URL 内に channel_id が含まれる

channel ID は YAML か JSON の配列にまとめて管理し、追加・削除だけでメンテナンスできる形にしておくのが正解。

出力フォルダの構成

要約を Obsidian vault のルートにそのままバラまくのは NG。推奨構成:

~/Documents/youtube-notes/
  ├── 2026-04-18-lex-fridman-dario-amodei.md
  ├── 2026-04-18-two-minute-papers-latest.md
  └── _archive/
      └── 2026-04/

日付 + チャンネル + スラッグ化したタイトルで命名すると、grep も時系列ブラウズも簡単。Obsidian に youtube-notes/ をポイントすれば、全文検索がそのまま効きます。

ポーリング 4 時間がスイートスポット

実測での最適解は 4 時間に 1 回 です:

  • 2 時間未満: ほぼ毎回空の feed が返ってきて無駄
  • 6 時間以上: 人気チャンネルでは最初の「黄金 3 時間トラフィック窓」を逃し、鮮度が落ちる

ニュース系など 1 日 1 本ペースのチャンネルだけ追っているなら、1 日 2 回（朝 8 時と夜 8 時）に落とすのもありです。

出力フォーマット：frontmatter + TL;DR + タイムスタンプ + 引用

出力フォーマットを揃えると、vault 横断の集計クエリが一気にできるようになります。推奨 YAML frontmatter:

---
title: "Why We're Betting on Rust for AI Infra"
channel: "Latent Space"
channel_id: "UCxxxxxxxxxxxxxxxxxxxxxx"
video_id: "AbCdEfGhIjK"
published: "2026-04-17T22:00:00Z"
summarized_at: "2026-04-18T02:14:32Z"
duration: "01:12:45"
tags: [rust, ai-infra, latent-space]
url: "https://www.youtube.com/watch?v=AbCdEfGhIjK"
---

本文構成のおすすめ:

## TL;DR
動画のコア主張を 2〜3 文で。

## ハイライト
- [00:03:12] Rust の所有権モデルが推論サーバー向きである理由
- [00:18:44] 移行中に遭遇した 3 つの tokio 落とし穴
- [00:42:08] Python asyncio とのベンチマーク比較

## 引用
> "The GIL is not the bottleneck anymore, serialization is."
> —— 00:51:20 のゲスト発言

## リンク
- 動画: https://www.youtube.com/watch?v=AbCdEfGhIjK
- 関連論文: …

タイムスタンプは必ずクリック可能にする（Obsidian なら [00:03:12](https://youtu.be/AbCdEfGhIjK?t=192) 形式）。でないと「重要シーンに 2 秒で戻る」という本来の価値が消えます。

コンボ：Obsidian vault + 日次ダイジェスト = 金曜自動ポッドキャスト

パイプラインを 1 週間回すと、youtube-notes/ フォルダには 80〜150 本の Markdown が溜まります。そこで第 2 のパイプラインとして 日次ダイジェスト集約 を足します。すべてのメモを Claude や Gemini に投げて、「今日のトップ 5」「今週のトレンド」を生成させるわけです。

関連記事: 毎日の AI ポッドキャスト：NotebookLM スタイルのノートパイプライン で、要約の集約を NotebookLM 風のダブルホスト対談にする方法を詳しく解説しています。

典型的な運用: 月〜木は 5 分のテキストダイジェスト、金曜夜に週次パイプラインを回して NotebookLM（または自前の Audio Overview）で 15〜20 分のダブルホストポッドキャストを生成。土曜の通勤で聴くと、1 チャンネル分のバックログを全部見るより 10 倍効率的です。

BibiGPT の AI 動画対話とスマート出典ビュー

応用：カスタム prompt template

デフォルトの「TL;DR + 要点 + 引用」はほとんどのチャンネルに使えますが、ジャンル別にテンプレを分けると精度が跳ねます。

チャンネル種別 推奨テンプレート 理由
論文解説（Two Minute Papers） 新規性 + 手法 + 限界 学術構造に対応、振り返りやすい
長尺インタビュー（Lex Fridman、Dwarkesh） 章別テーマ + 各章の引用 + ゲスト略歴 3h 超にはチャプター化が必須
プロダクト発表（Google、Apple keynote） 機能リスト + デモのタイムスタンプ + 価格表 事実確認指向
チュートリアル（freeCodeCamp） 手順リスト + コードスニペット + 主要概念 後からの再現が容易

Prompt template はプレースホルダ置換で運用します。{title}、{url}、{channel} を実行時に差し込む形式で、1 つの JSON 設定ファイルで数十チャンネルを別テンプレートで運用できます。

やらないこと：Shorts 一括・低リソース言語

なぜ Shorts の一括要約をやらないか:

  • Shorts はもともと 60 秒未満 —— 要約による「圧縮ゲイン」がマイナス
  • 品質シグナルが弱く、ほとんどがエンゲージメント目的。要約するとかえって判断を誤る

なぜ一部言語をスキップするか:

Gemini の YouTube ネイティブ理解は英語・中国語・日本語・韓国語では非常に強いですが、一部の低リソース言語（例：ベトナム語テックチャンネル）は ASR 精度がまだ不安定です。誤った要約を出すより、要約しない方がマシという方針です。

まとめ

購読も設定も一度だけ、要約は一生分。Atom feed がバックグラウンドで静かに走り、Gemini が新着動画ごとに構造化メモを吐き、あなたは朝のコーヒーの間に「本当に 30 分かけて見る 2〜3 本」を選ぶだけ。2026 年の AI 自動化が知的労働者にもたらす、最も直接的な複利です。