YouTube動画の要約を作り、内容を検証する方法

文字起こしツールの機能と制約を理解する

Actorは、ホスティング環境で動作するデータ収集プログラムです。Taskは、入力設定を保存したプリセットです。保存済みプリセットはYouTube Transcripts for LLM Analysis、メインツールはYouTube Transcript Scraperで確認できます。既定のtext+llmプリセットには、各セグメントの時間を示す証拠が含まれません。セグメントの時間情報を保持するには、jsonを追加する必要があります。

元データのフィールド名には、videoId、videoUrl、transcriptLanguageCode、isAutoGenerated、segments、text、llmText、status、scrapedAtがあります。各セグメントには、startSeconds、endSeconds、durationSeconds、textが含まれます。重複を除いた各動画の取得に成功すると、1行のデータが作成されます。要約が1件作成されるわけではありません。

このツールは、既知の公開動画のURLまたはIDを直接指定する場合にのみ対応しています。音声の文字起こし、動画検索、チャンネル単位の収集、翻訳、映像分析、モデルの呼び出しには対応していません。まずは動画を1本だけ指定してください。preferredLanguagesを空にすると、利用可能な字幕トラックが選ばれます。指定した言語が利用できない場合は、翻訳を返すのではなく処理に失敗します。字幕の提供元がない場合、自動字幕に誤りがある場合、映像の詳細を取得できない場合には、回答できる範囲が限られます。transcriptSpanSecondsとvideoCoverageRatioは、意味の忠実さを測るフィールドではありません。メモを作成したりモデルに入力したりする前に、元の行データを保存してください。

内容を検証した要約を作る全手順

1. 目的を書く：要約の目的と想定読者を書きます。読んだ後に何を知っていてほしいかを決めてください。学習用のメモと経営判断用のメモでは、残すべき詳細が異なる場合があります。ただし、どちらも結論を作り上げてはいけません。
2. 文字起こしを取得する：読みやすい文字起こしと、JSON形式の時間情報を取得します。元の動画が正しいか、言語は何か、失敗状態になっていないかを確認してください。冒頭、中盤、末尾に目を通し、明らかな字幕の不備がないかを調べます。不明瞭な語は、黙って修正せず、印を付けてください。
3. 要点を整理する：文字起こし全体を1度読みます。主張、元の時間範囲、必要な条件、例、必要な映像確認を記した要点整理表を作成してください。繰り返される主張はまとめられますが、意味と条件は残す必要があります。互いにつながっていない2つの時間範囲は分けて記載し、連続した裏付け区間を作り上げないでください。
4. 要約の下書きを作る：自分で要約を書くか、選んだ言語モデルに、指定した元の箇所だけを使って要約するよう依頼します。これは、読者が別途行う手順です。プロンプトでは、要点、条件、元の時間範囲を含め、必要な記述がない場合は「裏付けなし」とするよう指示できます。ただし、正確さを保証することはできません。個人情報や機密情報を含む元データを、その受領が認められていないツールに入力しないでください。
5. 各文を照合する：要約のすべての文を元の内容と照合します。「裏付けあり」「意味が変わっている」「条件が欠けている」「裏付けなし」のいずれかを記してください。数値、否定表現、不確実性、誰の主張かを確認します。1人の話者による提案を、実証済みの一般的事実に変えてはいけません。
6. 要点を確認する：要約の各文を文字起こしと照合するだけでなく、元の各要点が要約に含まれているかも確認します。文の裏付けを調べると、作り上げられた主張を見つけられます。要点の網羅性を調べると、重要な抜けを見つけられます。両方の確認が必要です。字幕が映像の場面を指している場合は、元の動画のその場面も確認してください。
7. 要約を修正する：誤った文を修正し、抜けていた中心的な要点を追加します。最終的なメモを元の内容より短くするのは、それでも目的を果たせる場合に限ります。長くするために、根拠のない細かい数値や一般的な背景説明を加えないでください。
8. 最終版のメモを保存する：最終的な要約と、元の内容による裏付けを示す簡潔な表を保存します。確認できない点は、不確実なまま示すか、除外してください。最後に仕上げるのは、元の該当箇所への参照が付いた検証済みのメモです。モデルが約束する正確さの割合ではありません。

キャッシュとは、再利用のために保存しておくデータです。古くなった値とは、元データが変更される前に保存された値です。有効期限とは、その規則に従って保存済みデータの再利用を停止しなければならない時点です。キャッシュヒットとは、保存済みデータを使ってリクエストに応答することです。

架空の具体例で手順を確認する

この方法の進め方を示すため、完全に架空の5分間の解説動画を使います。発話内容、動画の識別情報、時間、要約のスコアは、すべて架空のものです。

• パート1、00:20–00:45：「古いデータを許容できる場合は、繰り返し行う読み取りにローカルキャッシュを使ってください。」
• パート2、01:10–01:35：「有効期限を設定してください。適切な期限は、元データの変更速度によって異なります。」
• パート3、02:00–02:20：「更新を確認した後は、キャッシュに保存した値を削除してください。この場合、有効期限が切れるのを待つだけでは対応が遅すぎることがあります。」
• パート4、03:00–03:25：「キャッシュヒットと、古いデータによる応答を分けて記録してください。ヒット数が増えても、応答が正しいことの証明にはなりません。」
• パート5、04:10–04:30：「今回の小規模なデモでは10分に設定します。これは一例であり、すべてのシステムに当てはまる規則ではありません。」

読者の目的は、この方法を安全に使える条件を理解することです。要点整理表には、判断に必要な4つの点を残します。古いデータを許容できるという条件（パート1）、有効期限は元データの変更に依存すること（パート2と5）、更新確認後の削除（パート3）、ヒットと古いデータによる応答の区別（パート4）です。パート2と5には、別々の2つの時間範囲（01:10–01:35と04:10–04:30）を使います。01:10–04:30という連続した区間を裏付けとして扱うことはありません。

架空の不適切な下書きとして、次のようなものが考えられます。「すべての読み取りにキャッシュを使います。有効期限は10分に設定します。ヒット率が高ければ、キャッシュが正しく機能していると証明できます。」これは、条件を落としてパート1の意味を変え、デモの設定時間を普遍的な規則に変え、パート3を省き、パート4と矛盾しています。文章は自然でも、示した目的には適していません。元の内容と同じ語を使っているだけで、3文すべてに裏付けがあると報告しないでください。

修正を終えた要約は、次のようになります。「古いデータを許容できる場合は、ローカルキャッシュを使い、繰り返し行う読み取りでデータを再利用できます。有効期限は元データの変更速度に応じて決めます。10分という設定は、デモで選んだ値にすぎません。有効期限が切れるのを待つだけでは対応が遅すぎる場合は、更新を確認した後にキャッシュの値を削除します。ヒット数が増えても応答の正しさは証明できないため、ヒット数と古いデータによる応答を分けて記録します。」

裏付け確認表では、この4つの主張に対し、順にパート1、パート2と5、パート3、パート4への参照を付けます。

架空の確認表

網羅性の0/4と4/4という比較は、この架空のチェックリストだけに基づくものです。モデルの正確さを示すスコアでも、実際のベンチマークでも、5分間の動画全体を検証した証拠でもありません。修正後に各文の裏付けを確認すると、この検証用テストケースでは4件中4件に裏付けがあります。映像に基づく主張は0件です。ここから、外部での効果、速度に関する主張、測定された顧客の成果を導くことはできません。最終版のメモには、修正した4つの記述と、分けて記した元の時間範囲を使います。別の読者も確認できるよう、要点整理表を保存してください。