YouTubeの字幕から出典を確認できるAnkiカードを作る方法

1. 学習目標を1つ決める

公開レッスンを1本と、自分で内容を確認できる言語を1つ選びます。字幕の行を選ぶ前に、学習目標を書きます。たとえば、レッスン内の2つのテーブルを結び付けるフィールドを特定することが目標になります。

その目標に答える短い箇所を選びます。字幕のすべての行をカードにする必要はありません。字幕の区切りは、文字を表示するタイミングを示します。必ずしも意味のまとまりを示すものではありません。

小さなデッキについて、次の3つを成功の条件にします。

1. 各解答が、確認済みの箇所に基づいている。
2. 各ノートに、再確認に必要な出典情報が残っている。
3. 再インポートで、不要なノートを作らずに目的の解答を変更できる。

不確かな箇所は、学習用デッキに入れないでください。後で確認できます。もっともらしい解答でも、確認済みの解答とは限りません。

2. 既存の字幕を元資料のコピーとして使う

字幕トラックは、動画に付属する時刻情報付きのテキストです。キューは、そのテキストを時刻で区切った単位です。利用できる字幕と元動画のプレーヤーを使えば、少数のカードを手作業で作れます。すでに時刻情報付きの字幕がある場合は、対象箇所の確認に進んでください。

字幕が見つからない場合は、別のガイド「YouTubeの文字起こしを取得して確認する方法」を参照してください。この手順で元テキストを用意できます。ただし、カードに何を入れるかは別に決める必要があります。

YouTube Transcript Scraperは、既存の公開字幕トラックを収集できます。Actorは、ホスト環境で動作するプログラムです。Taskは、そのプログラム用に保存した入力設定です。時刻情報付き文字起こしJSONのTaskは、時刻情報付きテキストを取得するための、文書化された出発点です。

JSONは、名前付きの値やリストを保存するテキスト形式です。キューの時刻を保持できるため、ここではJSONを使います。プレーンテキストだけでは、キューの終了位置を特定できません。このActorは、音声認識による文字起こしの作成や、音声・動画のダウンロードを行いません。Actorが提供するのは元資料です。カードの設計と確認は自分で行います。

次の小さな入力例は、提供された公開入力ルールに沿っています。

{
  "includeFailedInputDetails": true,
  "outputFormats": ["json"],
  "preferredLanguages": [],
  "startUrls": ["https://www.youtube.com/watch?v=dQw4w9WgXcQ"]
}

実行する前に、`startUrls`内のサンプル項目全体を、対象とする公開レッスンのURLに置き換えてください。サンプルURLは入力例です。適切なレッスンであることや、実行に成功したことを示すものではありません。

`preferredLanguages`を空のリストにすると、利用可能な字幕トラックから最適なものを選べます。英語を指定する設定ではありません。学習目標に英語が必要なら、このフィールドを`["en"]`に設定します。言語の指定は順番に試されます。どれにも一致しない場合、Actorは別の言語を返さず、指定言語を利用できないという失敗を報告します。

このActorには、動画を直接指定するURLまたは動画IDを1〜1,000件入力できます。同じ動画IDが繰り返されても、処理は1回だけです。チャンネル、再生リスト、検索の入力は受け付けません。この方法では、動画1本から始めてください。これらは文書化された機能であり、このガイドのために実行して得た結果ではありません。

3. 元資料の記録とカードを分けて保存する

フィールドは、レコード内の名前付きの値です。カードを書く前に、取得できた次のフィールドを保存します。

元のキューは変更せずに残します。修正は別の記録に保存します。こうすれば、受け取ったテキストと、後で自分が書いた解答を区別できます。

各セグメントには、`text`、`startSeconds`、`endSeconds`、`durationSeconds`が含まれます。返された値をそのまま保存してください。長さの値が欠けている場合、その長さは不明です。0秒という意味ではありません。一方、再生開始位置の0秒は、動画の冒頭を意味します。

返された動画レコードと、OUTPUTという名前の実行概要の両方を確認します。処理に成功した重複のない動画は、それぞれ個別の結果レコードであるデータセットの行を生成します。失敗した入力は、そのような成功した文字起こしの行を生成しません。失敗した入力の詳細はOUTPUTで確認してください。結果が空というだけでは、字幕がないと判断できません。

字幕の言語、生成元のフラグ、セグメント数、対象範囲は、返されたトラックの情報です。単語の正確さを証明するものではありません。セグメント数から、有用なカードを何枚作れるかが分かるわけでもありません。これらの制約は、Actorの公開仕様に記載されています。

4. 解答を書く前に対象箇所を確認する

選んだ箇所を動画で開きます。その前後の文も再生します。説明を理解するために文脈がさらに必要なら、再生範囲を広げます。文脈とは、解答を理解するために必要な前後の言葉や画像のことです。

次の順番で確認します。

1. 解答の根拠となる言葉を聞き取ります。
2. 名前、数値、単位、条件、「〜ではない」などの否定表現を確認します。
3. 「それ」「これ」などの言葉が何を指すかを特定します。
4. 表、図、コード例に必要な情報がある場合は、画面を確認します。
5. 文脈を短くメモし、字幕の修正があれば記録します。
6. 必要な単語や意味が不確かなままなら、その箇所は保留にします。

聞き取れない単語を、予想した解答で補わないでください。知っている用語だからといって、説明されていない定義を推測しないでください。考えた解答の根拠がレッスンにない場合は、別の質問や別の箇所を選びます。

正確な表現が必要なカードには、別の手順「YouTubeの引用を確認する方法」を使ってください。多くのカードでは、自分の言葉で短く言い換えられます。ただし、条件を含め、元の意味を保つ必要があります。

録音が明瞭でも、内容に事実の誤りがある場合があります。レッスンで何を述べているかの確認と、その主張が正しいかの確認は別です。主張を疑う理由がある場合は、解決するまでカードを保留にしてください。

5. 質問と解答を1つずつ書く

解答を短くする前に、質問を書きます。有用な質問は、学習者が何を思い出すべきかを明示します。動画を見ていない状態でも意味が通じる質問にしてください。

「これは何をするものですか」のような質問は避けます。「これ」が何を指すかは、見えない文脈に依存するためです。対象や操作の名前を明記してください。レッスン内の特定の例について尋ねる場合は、そのことを示します。

各質問で扱う主な事実は1つにします。関係のない2つの事実を尋ねる質問は分けます。ある事実が成立するための条件は、その事実と一緒に残します。解答を短くするためだけに条件を削らないでください。

各下書きを次の項目で確認します。

解答は短くても明確にできます。後から確認できるように、解答の根拠となる文脈を残してください。カードの表面に解答が分かる情報を出さないようにします。

6. 後で編集しても使い続けられるフィールドを設定する

独自のノートタイプを使います。ノートタイプは、フィールドとカードのレイアウトを定義するものです。表面に質問を1つ、裏面にその解答を表示するように設定します。再確認できるよう、解答と一緒に出典リンクとキューを表示します。

次の6つのフィールドを、この順番で使います。

`SourceKey`を先頭に置きます。Ankiで同じノートを再度取り込むときの処理は、ノートタイプと最初のフィールドによって変わります。インポートのたびに既存のノートが更新されると思い込まず、目的の動作をテストしてください。Ankiのテキストインポートマニュアルには、フィールドの区切り、対応付け、重複の処理が説明されています。

出典キーには、動画の識別子、キューの時刻、カード番号を組み合わせる方法があります。一度割り当てたキーは固定します。質問を書き直したり解答を修正したりしても、そのキーを維持してください。後でキューの時刻を調整しても、新しい時刻からキーを自動的に作り直さないでください。キーを変えると、修正したノートが新しいノートとして扱われる可能性があります。

確認状態には、`needs_review`や`reviewed`などの簡単なラベルを使います。これらは自分で付けるラベルです。Actorの結果でも、独立した確認を受けた証拠でもありません。

修正記録を別に保存します。出典キー、元のキューのテキスト、修正後の表現、理由、確認した区間、確認日を記録してください。ノートファイル、確認の判断、Ankiのインポート設定は、所有者が管理する記録です。公開Taskページから、それらの記録を参照したり検証したりすることはできません。

7. ファイルを保存し、2件のノートでテストする

6つのフィールドをUTF-8のタブ区切りテキストとして保存します。UTF-8は、多くの言語の文字を扱える文字エンコーディングです。タブ区切りとは、タブ文字で各フィールドを区切ることです。この小規模なテストでは、1行に1件のレコードを入れます。

最初のファイルは単純な構成にします。各フィールドは1行に収め、値の中にタブ文字を入れないでください。フィールド内にタブや改行が必要な場合は、Ankiの文書にある引用符の規則に従い、プレビューを確認します。意味が変わるような一括置換はしないでください。

次の手順で進めます。

1. 独自のノートタイプを使う、一時的なテスト用デッキを作ります。
2. 異なる出典キーを持つ、確認済みのノートを2件用意します。
3. インポートのプレビューを開き、区切り文字としてタブを選びます。
4. ファイルの各列を、対応するフィールドに割り当てます。
5. 最初の列が`SourceKey`に対応していることを確認します。
6. ファイルをインポートし、両方のカードを確認します。
7. ファイル内の解答を1つだけ変更します。出典キーは維持します。
8. 目的の更新設定と同じノートタイプを使って、再度インポートします。
9. 解答が変更され、不要なノートが増えていないことを確認します。

表示された質問、解答、キュー、出典リンクを確認します。実際の出典リンクをそれぞれ開き、記載した時刻をプレーヤーで確認してください。URLが表示されているだけでは、目的のレッスンが開く証拠にはなりません。

標準の2フィールドのノートタイプを使う場合は、別の対応付けを明示する必要があります。各値の保存先を決めずに、この6フィールドのファイルを取り込まないでください。更新テストに失敗した場合は作業を止めます。対応付け、キー、ノートタイプ、重複設定の問題を解決してから、ノートを増やしてください。

具体例：独自に作った架空の例

この例は、説明のために独自に作った架空の例です。Actorの結果でも、実在するレッスンでも、完了したAnkiテストでもありません。以下のインポート手順は提案であり、実行していません。

架空のレッスンの02:14の箇所では、2つのサンプルテーブルが、変更しないIDでレコードを結び付けると説明しています。IDは識別子のことです。ここでは、サンプルを識別する値を指します。後の架空の箇所では、サンプルのラベルを変えてもIDを変えてはいけないと説明しています。

最初の箇所は、2分14秒から始まります。

`2 × 60 seconds + 14 seconds = 134 seconds`

この架空の例では、終了位置は142秒です。区間の長さは次のとおりです。

`142 seconds − 134 seconds = 8 seconds`

架空の2番目の箇所は、142秒から148秒までです。

`148 seconds − 142 seconds = 6 seconds`

これらの区間は、説明のために作った値です。動画で測定した結果ではありません。キー`demo-video:134:01`は、最初の架空のカードを識別します。末尾の`01`はカード番号であり、正確さの評価ではありません。

次の架空のノートを2件用意します。

この例では出典URLが存在しないため、空欄にしています。代わりにサンプル動画のURLを入れることはしません。実際の出典を確認できないため、このノートは実際の学習用デッキには入れません。

最初の質問は、「どのフィールドで2つのテーブルを結合しますか」という問いの対象を、レッスンのサンプルテーブルに限定しています。すべてのテーブルで同じ結合フィールドを使うべきだと教えるものではありません。

重複処理のテスト案では、最初の解答を「変更しないサンプルIDです。」に変えます。`demo-video:134:01`は変更しません。正しく設定して更新した場合、期待される結果は、ノート数が2件のままで、最初の解答だけが修正されることです。3件目のノートができた場合、そのインポートでは目的の更新が行われなかったことを示します。これらはテストで期待する結果であり、実施済みテストの結果ではありません。

実際のレッスンを使うときは、架空の内容を確認済みの元資料に置き換えます。実際の再生時刻、開ける出典リンク、自分の確認記録を保存してください。

デッキを増やす前に問題を解決する

実際に起きた失敗に応じて、次の対応を選びます。すべての問題を字幕がないせいにしないでください。

2件のノートが正しく表示されれば、そのノートが小規模な確認に合格したことは分かります。ただし、今後のすべてのインポートが成功することや、今後のすべての解答が正しいことを示すものではありません。追加する箇所を毎回確認してください。ファイル構造やノートタイプを変えたときは、インポートのテストを繰り返します。