【原理上の制約】なぜ openclaw_youtube は当面、B站のような「任意の動画コメントでトリガー」を実現できないのか

汎用
, ,
1

2026-03-18 時点で、この方向性については、公式 API で通れる道は概ね検証し終えました。先に結論を言うと：目標が B 站（Bilibili）のように、ボットが 任意の YouTube 動画 の下でトリガーコメントを検知し、自動で動画を要約し、字幕を組み合わせて、さらにコメントを投稿する——というものなら、YouTube 公式 Data API v3 だけでは基本的に実現できません。

YouTube がコメントできないとか、OAuth がダメという話ではなく、最大の肝であるこの一手：トリガーコメントの発見について、公式 API が使える能力を提供していないからです。

実現したい効果は何か

目標はかなり明確です：

  • アカウント A またはボットアカウントが、任意の YouTube 動画の下で動作できる
  • トリガーは @fixcolar でもよいし、「椰子 结合字幕总结本视频」のような固定の起動ワードでもよい
  • トリガーにヒットしたら、システムが動画・コメント・コンテキストを自動取得する
  • 字幕があれば、字幕を LLM に注入する
  • 最後にそのアカウントが自動で当該動画のコメント欄へ戻ってコメントを投稿する

B 站のプラグインが成立しているのは、「動画のコメント欄をスキャンしている」のではなく、アカウント自身の @ メッセージストリーム / 返信メッセージストリーム を読んでいるからです。全サイトの任意動画で誰かがあなたを @ すれば、B 站はそれをメッセージストリームに入れるので、プラグインは動画横断で動作できます。

YouTube の公式 API では、詰まるポイントがちょうどここです。

なぜ公式 API 方案が通らないのか

1. commentThreads.list は「コメント作者」で検索できず、全サイトの mention ストリームもない

公式ドキュメント：

commentThreads.list のフィルタ手段は、要点としてはこれらです：

  • videoId
  • allThreadsRelatedToChannelId
  • id

つまり、できることはせいぜい：

  • 特定動画のコメントスレッドを取得する
  • 特定チャンネル関連のコメントスレッドを取得する
  • 既知の thread id で取得する

しかし、できないことは：

  • 「あるアカウントが最近どの動画にコメントしたか」を探す
  • 「全サイトのどこで自分が @ されたか」を探す
  • 「全サイトのどこで起動ワードが出現したか」を探す

これはつまり、このエンドポイントだけでは固定チャンネルや固定動画を監視することしかできず、「任意動画でのトリガー」は実現できません。

2. comments.list も作者で履歴検索できない

公式ドキュメント：

comments.list がサポートする主要なフィルタは：

  • id
  • parentId

これは「commentId を既に知っているので、そのコメントや返信を取ってきて」という用途に近く、「この人が最近何をコメントしたか探して」ではありません。

したがって、これも「任意動画内のトリガーコメント発見」を解決できません。

3. activities.list?mine=true でも救えない

公式ドキュメント：

直感的には、アカウント自身の activity feed を取ればよさそうに見えます。

しかし公式は明確にこう書いています：

  • comment タイプは “not currently returned”
  • activities.list does not currently return resources for new comments

つまり、アカウント自身の activity feed から「自分が今さっきどの動画にコメントしたか」を安定して取ることはできません。

4. 公式 Push Notification もコメントイベントは押してこない

公式ドキュメント：

このプッシュ機構が押してくるのはチャンネル feed の変化で、本質的にチャンネルのコンテンツ更新を中心としたものであり、コメント/mention のイベントストリームではありません。

したがって、「全サイトコメント発見」の代替にはなりません。

5. Gmail のコメント通知は不安定で、迂回路扱いにしかならず、主経路には不向き

公式ヘルプ：

ヘルプには、わざわざ次の注意書きがあります：

consecutive comments on a video may not lead to notifications for each

つまり、連続コメントは必ずしも1件ごとに通知されません。メールを主トリガー経路にすると、構造的にイベント漏れが起きます。

これは何を意味するか

公式 API で依然として有用な部分

YouTube API は完全に無価値ではなく、後半には価値があります：

  • 動画が既知ならトップレベルコメントを投稿できる：commentThreads.insert
  • 親コメントが既知なら返信を投稿できる：comments.insert
  • 動画 metadata を取得できる
  • yt-dlp と組み合わせれば、公開動画の既存字幕も取得できる

つまり：

「コメント発見」は無理だが、「コメント送信」は可能。

本当に欠けているのは前半

欠けているのは：

  • アカウント A 自身が直近どの動画に書き込んだかを発見する
  • 全サイトのどこでボットが @ されたかを発見する
  • 任意動画で起動ワードコメントが出現したかを発見する

この一手がないと、「B 站みたいに全サイトでトリガー」の設計は成立しません。

では現状の API 版 openclaw_youtube の位置づけはどう理解すべきか

公式 API の道だけを見るなら、次のような狭いシナリオに向いています：

  • 自分のチャンネルに来たコメントを監視する
  • 固定チャンネル/固定動画下のコメントを監視する
  • commentId / videoId が既知の前提で自動返信する
  • ユーザーが明示的に「字幕を組み合わせて」と求めた場合に、公開字幕を注入する

しかし、次の目標には 向きません：

  • 任意動画で @fixcolar したらトリガー
  • 任意動画で自分が「椰子 结合字幕总结本视频」と書いたらトリガー

したがって、公式 Data API でパラメータを積み増しても意味は薄いです。工数の問題ではなく、そもそもインターフェースがこの種の発見能力を提供していないからです。

今後の「曲線救国」方案は何があるか

以下の方向性は机上の空論ではなく、現時点で実際にまだ着地の可能性があるルートです。

方案一：ユーザースクリプト（Tampermonkey）/ ブラウザ拡張で能動的にトリガー

これは現時点で最も有望だと思っている方案です。

やり方は：

  • 任意の YouTube 動画ページを開く
  • ユーザースクリプトや拡張がページから videoId を直接読む
  • ボタンを押す、またはスクリプトに固定 prompt（例：「字幕と組み合わせて本動画を要約」）を内蔵する
  • フロントエンドが videoId + prompt をローカルサービスへ送る
  • バックエンドが字幕取得・LLM 実行し、API でコメントを投稿する

このルートの利点：

  • 「自分がどこでコメントしたか」を発見する必要がない
  • YouTube が通知をくれるかに依存しない
  • ページ側はトリガーだけ担当し、実際の投稿は担当しない
  • 実際の投稿は引き続き公式 API を使えるので安定性が高い

将来的に「任意動画ページで1回クリックすれば自動で要約コメントを投稿」をやるなら、このルートが最も堅いです。

方案二：ログイン済みブラウザで YouTube Studio / 通知ページをポーリング

これは B 站のメッセージストリーム発想の代替に近いルートです。

やり方は：

  • ローカルでログイン済みの YouTube ブラウザ profile を維持する
  • 拡張やデーモンが定期的に YouTube Studio のコメントページ、通知ページ、mention ページを読む
  • 新しいコメント / メンション / 返信イベントを解析する
  • 発見したイベントを OpenClaw と公式 API に渡して返信させる

利点：

  • 「任意動画で @ すればトリガー」に近い体験まで寄せられる

欠点：

  • 本質的に Web 自動化で、保守コストが高い
  • ページ構造の改版で壊れ得る
  • ログイン状態、リスク制御、CAPTCHA などが公式 API より面倒

方案三：半自動の comment link / commentId 受け渡し

最も泥臭いですが、最も安定する方法です。

やり方は：

  • まず自分で任意動画にトリガーコメントを投稿する
  • そのコメントリンクまたは commentId を手動でボットに渡す
  • ボットはそれを受け取って、バックエンドの流れで返信/要約/字幕注入を行う

上品ではないですが、「コメント内容生成」の後半を最速で動かせます。

方案四：ハイブリッド構成

これは長期的に現実的な構成です：

  • 発見側はブラウザページ、ユーザースクリプト、拡張、Studio 通知ページなどの非公式経路を使う
  • 実行側は引き続き公式 API でトップレベルコメントや返信を投稿する

つまり：

  • 前半は Web コンテキストに頼る
  • 後半は正式 API に頼る

現状、工学的に最も擁護しやすいルートです。

現段階の結論

この結論は明確にしておくべきで、今後誤った方向に時間を燃やさないためにも重要です：

  • openclaw_youtube が「公式 Data API のみ」に固執するなら、固定チャンネル/固定動画のコメントボットにしかならない
  • 目標が「B 站のように任意動画でトリガー」なら、「純 API 発見」という仮定を捨てる必要がある
  • 実際に着地できるのは、ブラウザ側で発見 + API 側で返信 のハイブリッド方案

言い換えると：

YouTube のこれは「できない」のではなく、「公式コメント API だけではできない」。

これが現段階で最も重要な結論です。