YouTube Transcripts in n8n: HTTP Request Workflow Guide

以下をn8nのImport from Fileオプションで直接インポートするか（あるいはImport from URLに貼り付けてください）:

ダッシュボードからキーを取得し（100無料クレジット、カード登録不要）、お使いのn8nインスタンスで利用できる環境変数として設定してください:

GETYOUTUBETRANSCRIPT_API_KEY=sk_live_...

Blog.Posts.n8nYoutubeTranscriptWorkflow.step2.body2

HTTP Requestノードは、動画IDをクエリパラメータとして文字起こしエンドポイントを呼び出します:

GET https://getyoutubetranscript.com/api/v1/transcript?v={{ $json.videoId }}
Authorization: Bearer {{ $env.GETYOUTUBETRANSCRIPT_API_KEY }}

動画IDをワークフローの入力（または前のノードの出力）に渡すと、ノードは文字起こし、タイトル、投稿者、サムネイルを$json.data.transcriptにJSONとして返します。

動画IDのリストをそのままHTTP Requestノードに流すと、n8nが可能な限り高速にすべて発火させます - 5本の動画であれば問題ありませんが、無料プランの毎分60リクエストの制限に対して500本では危険です。n8nにはこれをペース調整する組み込みの方法が2つあります:

• HTTP Requestノード → Add Option → Batching。Items per Batch（一度に発火するリクエスト数）とBatch Interval (ms)（バッチ間の遅延）を設定します。無料プランの毎分60リクエストの場合、バッチサイズ5、間隔5,000msに設定すれば十分に余裕を持って予算内に収まります。
• Split In Batches + Waitノード。Split In Batchesノードは動画リストをチャンクに分割し、Waitノードが各チャンクの間で一時停止してからループが次のチャンクへ進みます。これは厳密に逐次的（並列バーストが一切ない）であり、制限に近い場合や、下流でチェーンしているAPI（例: LLM要約ツール）自体にもスループットの上限がある場合には、より安全な選択です。

また、ノードのリトライ設定にあるWait Between Tries (ms)を、1リクエストあたりの予算より高めに設定してください - 毎分60リクエストのプランではおおよそ1秒あたり1リクエストが平均値になるため、1,000ms以上の間隔を空ければ、429で同じ制限に即座に再びぶつかることを避けられます。

多数の動画を処理していると、一部は失敗します（非公開動画、字幕なし、一時的な429など）。HTTP RequestノードでContinue On Failを有効にすれば、1件の失敗でワークフロー全体が止まることはありません。その後、下流にIFノードを追加してレスポンスで分岐させ、成功は要約ツールへ、失敗はログまたはリトライキューへ振り分け、1つの不正な動画IDのためにバッチ全体を失わないようにしてください。

Blog.Posts.n8nYoutubeTranscriptWorkflow.step6.body