YouTube台本の作り方｜伝える順番・話す言葉・根拠を撮影前に整える

※本記事にはPRを含む場合があります。

こんにちは。『脱会社員』脱サラを応援し続けるブログ、運営者の『なかびー』です。

YouTubeの台本は、最初から気の利いた言い回しを探すより、誰の、どの疑問に、どんな根拠で答えるかを決めると書き進めやすくなります。伝える内容を並べ、声に出せる文へ直し、読み合わせで説明の抜けを見つける。この順番なら、撮影の直前に「結局、何の話だったのか」と原稿を作り直す負担を抑えられます。

この記事では、大人に向けた非フィクションの説明動画を想定し、一本分の「話す言葉の原稿」を完成させる作り方を紹介します。題材は、架空のチームが作業用ファイルの名前をそろえる説明です。目的票、根拠の照合表、章の並び、口語への書き換え、読み合わせの修正票、公開後の改善仮説まで、同じ題材を使ってつなげていきます。

例に登場するチーム、ファイル、原稿、修正場面は、手順を説明するために作った架空のものです。実際の投稿結果や視聴者データ、筆者の制作実績を示すものではありません。ファイル名の形式も、この例の中で使う運用案です。どの機器や保存サービスでも同じように使える技術仕様としては扱いません。

見終えた人が答えられる問いを一つ決める

台本の空白を埋めようとして、まず長い挨拶や自己紹介を書き始めることがあります。しかし、話の中心が決まる前に導入を整えると、本文に合わなくなって書き直す場合があります。最初は文章のうまさを気にせず、視聴者が抱いている問いを一つだけ置きます。今回の問いは「チームで使う作業用ファイルの名前を、どうそろえればよいか」です。

「初心者向け」を、見始める前の状態まで具体化する

見る人を「パソコン初心者」とだけ決めても、どこまで説明するかは定まりません。ファイルを保存する操作はできるけれど、名前に日付を入れる意味が分からない人と、保存場所そのものが分からない人では、必要な前提が違います。今回は、同じフォルダーで書類を共有した経験があり、名前の付け方が人によって違うことに困っている成人のメンバーを想定します。

見終えた後の状態は「便利さが分かる」ではなく、「名前に入れる三つの項目を挙げ、例の名前を一つ作れる」とします。できたかどうかを原稿から確認しやすい形にするためです。「三つ」は覚えやすさを保証する魔法の数ではありません。この架空の課題では、文書の種類、対象日、作業状態を区別する必要があるため、三項目を選んでいます。

ここで、動画を見る前に知っていてほしいことと、動画の中で初めて教えることを分けます。「フォルダー」「ファイル名」は前提として使い、「対象日」は本文で説明する語にします。対象日とは、文書が扱っている日付です。会議メモなら会議が行われる日という意味に限定します。この前提の置き方を決めないと、同じ単語でも説明者と視聴者の理解がずれてしまいます。

※表は横にスクロールできます。

題材を絞るときは、困りごとと解決範囲をつなげる

この例で「ファイル管理を完全に解説します」と言ってしまうと、名前の付け方だけでは約束を果たせません。「新しい作業用ファイルに、同じ順番で名前を付ける方法を考えます」と範囲を限定すれば、台本の終わりで確認する内容も明確になります。見せ場を作るために大きな言葉を使うより、最後まで説明できる約束を選びます。

一つの問いから、保存場所、検索、承認、バックアップまで話が広がる場合は、各話題について「これが分からないと、今回の名前を作れないか」と尋ねます。必要な前提なら短く補い、便利ではあっても今回の理解に不可欠でなければ、別の動画の候補に残します。削った話題を捨てる必要はありません。一本に入れないと決めるだけで、今回の台本を進められます。

また、視聴者が今すぐ実行するべき内容か、判断のために知っておく内容かも分けます。架空例では、いきなり実ファイルを変更させず、紙やメモに名前の案を作ってもらいます。実際の共有環境では既存の取り決めがあるかもしれません。「動画どおりに一括変更してください」と飛躍させず、試す対象と合意の必要性を言葉に含めます。

タイトル、冒頭、終わりを同じ約束にそろえる

仮タイトルは「作業用ファイルの名前をそろえる三つの項目」、冒頭の約束は「種類・対象日・状態の順に、名前の案を一つ作ります」、終わりの確認は「三つの項目を自分の言葉で説明できますか」と置けます。タイトルだけ具体的で本文が抽象論に終わる、あるいは本文にない成果をタイトルで示す、といったずれをここで点検します。

YouTubeのスパムに関するポリシーは、謳った内容とは異なる動画へ視聴者を誘う悪質なクリックベイトを禁止しています。台本づくりでは、タイトルや説明欄で約束する内容を本文で扱えているかを確認しましょう。細部の省略をすべて違反と決めつけるのではなく、視聴者を誤認させる約束になっていないかを見ることが大切です。

話す内容を事実・提案・例示に分けて調べる

構成を作る前に、話したい内容を短い文で書き出します。この時点では、文章を美しくつなげる必要はありません。その代わり、一つずつ「確かめられる事実」「自分からの提案」「説明用の例示」に分けます。分類が混ざったままだと、自分が決めたルールを公式仕様のように紹介したり、架空の例から実際の効果を断言したりしやすくなります。

一文に含まれる主張を小さく分ける

例えば「日付を先頭にすれば、どのサービスでも自動で正しい順に並び、誰でも迷わなくなります」という文には、名前の形式、並び替え機能、利用者への効果という別々の主張が入っています。何を根拠に確認したのかも一つには決まりません。今回の原稿では、その文を採用せず、「この例では、対象日を名前の二番目に入れます」と、自作の提案が分かる形に直します。

続けて「会議が十月七日なら、対象日の欄にその日付を書きます」と例を示せます。ただし、「こうすれば探す時間が半分になる」といった成果は、測定していなければ書けません。「どの日の会議メモかを名前から確認したいので、日付を入れる案にします」と目的を説明すれば、効果を作り上げずに判断の理由を伝えられます。

事実を調べるときは、話したい主張と資料の該当部分を対応させます。公式ページを一つ見つけたというだけでは、原稿のすべての文を支える根拠にはなりません。使う機能、対象のサービス、利用条件、確認した日を記録し、資料に書かれている範囲を越えていないかを見ます。出典が見つからない文は、確認済みの一覧へ紛れ込ませず、未確認として残します。

※表は横にスクロールできます。

調べた記録には「使える文」と「使えない断定」を残す

資料を読んでいる間は、見つかった情報を全部盛り込みたくなります。そこで、調査メモには原稿に使う一文と、そこからは言えないことを並べます。例えば、あるサービスの説明を確認した場合、「そのサービスの、その条件での挙動」は話せても、他社サービスや別の端末の動作まで保証することはできません。話せる範囲を先に決めると、後の口語化で条件を落としにくくなります。

確認日の扱いにも注意します。「二〇二六年十月五日に確認した」は自分が読んだ日であり、資料の更新日とは限りません。ページに更新日が見当たらなければ、分からないままにします。古い資料を参考にしたときも、公開年を伏せて新機能の案内のようには書きません。時間がたっても使える制作上の考え方と、変化する機能や規約は、別々に点検します。

本記事では、Wistiaの制作担当者による二〇一九年の台本づくりの記事を、視聴者と要点を先に整理し、話し言葉に整え、声に出して読むという制作実務の参考にしています。以下の目的票やファイル名の原稿は本稿の自作例です。同社の文章例の転用や、同社製品の機能をYouTubeの機能として説明することはしていません。

未確認の情報は、仮の言葉で本文へ埋め込まない

調査が途中なら、「たぶん使える」「おそらく問題ない」と本文へ残して撮影に進むより、確認待ちの欄へ分けます。その情報がなくても目的を達成できるなら、いったん外して原稿を完成させます。結論に不可欠なら、確認するまで該当部分の確定を待ちます。「あとで調べる」と書いた注記が、そのまま話す言葉として読まれない形にすることも必要です。

他の動画を参考にするときは、疑問の拾い方や説明の粒度を観察します。他人の経験談の主語だけを変え、自分の体験として使うことは避けます。現場の事例が必要で、利用できる実例を持っていない場合は、今回のように架空と明示して自分で作ります。架空例は説明の理解を助けるために使い、成功の証明には使いません。

生成AIに構成案や言い換えを出してもらった場合も、根拠を確かめる工程は残ります。読みやすい文であっても、その中に勝手な数値、存在しない機能、実施していない体験が入っていないかを一文ずつ確認します。社内資料を扱う場合は、使用するサービスへ入力してよい内容かも先に確かめ、不要な個人情報や秘密の情報を原稿づくりへ持ち込まないようにします。

結論までの順番を視聴者の疑問から組む

調べた項目をそのまま順番に読み上げても、説明の流れになるとは限りません。話し手には内容の全体像が見えていますが、視聴者には次の話題が分かりません。そこで各章に、「ここで視聴者が知りたいこと」「この章の答え」「次へ移るための一文」を置きます。見出しだけの一覧から、聞いて理解できる道筋へ変える作業です。

知識の分類順と、理解する順番を分けて考える

書き始めの構成が「命名規則とは」「日付表記の種類」「状態の種類」「便利な機能」「まとめ」だったとします。分類としては整理されていますが、これだけでは、何をすれば今回の困りごとが解けるのかが後回しになります。視聴者が欲しい答えは用語の一覧より、自分が作る次のファイルにどんな名前を付けるかです。

そこで、最初に完成形を短く示し、その名前を一項目ずつ読み解き、最後に迷いやすい場合を説明する順番へ変えます。すべてを先に説明してから例を出す方法もありますが、今回の題材では例を見ながら各項目の役割を理解する構成を選べます。完成形を出しただけで理解したと考えず、どの部分が何を意味するのかを後の章で戻って説明します。

※表は横にスクロールできます。

章のつなぎを書くと、説明の飛躍を見つけられる

「次に日付です」だけでも話題の変更は伝わります。しかし、なぜ日付の説明へ移るのかは伝わりません。「種類だけでは、どの日の会議メモか分かりません。そこで二つ目に対象日を入れます」とつなげると、前の答えから次の問いが生まれます。つなぎを書けない場合は、順番が不自然か、前提が一つ抜けている可能性があります。

同じように、作業状態へは「同じ会議のメモでも、書いた直後と確認が済んだものを分けたいので、最後に状態を入れます」と進めます。ただし、動画で扱うのは名前の付け方の案です。「確認済み」と書けば確認が行われた証拠になる、といった意味にしないよう、実際の確認手続きと表示の役割を混同しない一文を添えます。

※表は横にスクロールできます。

結論を先に出すかは、理解に必要な前提で決める

結論、理由、具体例、結論という順番は、主張を短く説明するときの選択肢です。ただし、その型をすべての動画に当てはめる必要はありません。結論の中に初めて聞く専門語が多ければ、短い定義を先に置く方が理解しやすい場合もあります。手順を扱うなら、操作の前提、手順、結果の確認という並びが合うこともあります。

今回の動画では、「種類・対象日・状態の順にそろえます」という短い答えなら冒頭に置けます。一方、「対象日」という言葉を説明せずに例外の扱いを先に話すと、視聴者は何の例外か分かりません。先に出す結論は入口として短くし、実際に使うための条件や語の意味は必要な場所で補います。結論を早く言うことと、条件を省略することは分けて考えます。

章を減らすときも、文章の長さだけで決めないようにします。種類と日付の説明は一つにまとめられても、作業状態の意味まで一文へ押し込むと、聞いた人がそれぞれを区別しにくくなります。短い動画にするほど、「視聴者が一度に判断することは何か」を意識します。語句を削るより、扱う判断の数を絞る方が、説明を保ったまま整理できることがあります。

構成ができたら、本文を書かずに問いと答えの列だけを読みます。最初の問いに最後で答えているか、途中で新しい目的にすり替わっていないか、例外が基本の説明を遮っていないかを見ます。この段階なら段落を大きく移動しても負担が小さく、言い回しを磨いた後に全体を組み直す作業を減らせます。

書き言葉を声で伝わる短い文へ直す

構成が固まったら、各章の答えを話す文へ広げます。ここで大切なのは、文章を幼くすることでも、丁寧な言葉をすべて崩すことでもありません。聞いている途中で主語を探し直したり、前の文を読み返したりしなくても、意味を追える形に整えます。話し手が自然に言える語尾を選びながら、内容の精度を保ちましょう。

一文に詰まった役割を分ける

元の文を「共同利用時に識別しやすくすることを目的として、文書の種別、対象となる日付および作業の進捗状態を一定の順序にて記載します」とすると、読めば理解できても、耳では途中の要素を覚えておく必要があります。「名前には三つの項目を入れます。文書の種類、対象日、作業の状態です。この順番を、チームでそろえます」と分ければ、説明の役割がはっきりします。

ただし、一文を短く切るだけでは不十分です。「日付です。そろえます。便利です」と並べても、関係が分かりません。何をそろえるのか、何のためなのかが伝わる接続は残します。一文ごとの文字数を厳密な合格基準にするより、その文が「説明」「理由」「注意」「例」のどれを担当しているかを見て、役割が重なりすぎた場所を分けます。

※表は横にスクロールできます。

指示語、修飾語、数字は別々に点検する

「これ」「それ」「このように」が続く場所では、何を指しているかを原稿だけで答えられるか確認します。画面がなければ分からないなら、「画面に出した名前の、中央の日付」のように対象を具体化します。すべての指示語を消す必要はありませんが、二つ以上の候補がある場面では、短くても名詞を繰り返す方が意味を保ちやすくなります。

修飾語については、「昨日作った会議で使うメモ」のように、どこへかかるかが曖昧な文を探します。昨日作ったのがメモなのか、昨日の会議のメモなのかで意味が違います。今回なら「十月七日の会議メモです。作成した日とは分けて考えます」と言い直せます。説明者には明らかな関係でも、初めて聞く人に同じように届くとは限りません。

数字は、画面での表記と口での読みを分けて決めます。名前の例にある「20261007」は、本文では「二〇二六年十月七日」と読みます。日付の意味を説明した後に、表示では年、月、日の順で数字を続けていると補えば、数字の列を何度も読み上げずに済みます。名前を正確に写す必要がある部分では、表示を確認する間も原稿へ入れます。

区切りの記号も同様です。例の「_」は、最初に「下線の形の記号、アンダースコア」と紹介し、その後は「区切り」と呼ぶ方法があります。視聴者が記号を知らないことを責める言い方にせず、今回の説明で必要な呼び名だけをそろえます。記号の入力操作まで説明するかどうかは目的票へ戻って判断し、不要なら別の操作説明へ広げません。

全文台本と要点メモは、話す内容の精度で選ぶ

初めて説明する内容や、条件を落とせない箇所では、全文台本があると確認しやすくなります。一方、自分の言葉で説明できる部分は、問いと要点だけを書いたメモの方が話しやすい場合もあります。どちらか一方に統一せず、冒頭の約束、用語の定義、注意事項は全文にし、具体例を見ながら補う部分は要点メモにする方法も考えられます。

要点メモへ変える前には、一度は全文で意味を確かめます。「日付を説明」とだけ書いたメモでは、撮影時に更新日と対象日を混同しても気づきにくくなります。「対象日＝会議が行われる日。作成日とは分ける」と残せば、語句が多少変わっても中心の意味を保てます。自由に話す範囲と、意味を変えずに伝える範囲を分けることが大切です。

※表は横にスクロールできます。

画面に全部書く前提で、口頭の説明を省きすぎることも避けます。視聴者が細かい文字を読めない環境で聞いている可能性もあるため、今回の結論や重要な条件は話す本文に残します。その一方で、長いURLや一字ずつ確認する表記は、画面資料や説明欄へ分けると扱いやすくなります。どこに何を置くかを決め、本文と注記で内容が食い違わないかを確認します。

声に出して、説明の抜けと撮影用原稿を整える

黙読で整った原稿も、声に出すと息が続かない箇所や、言い直したくなる箇所が見つかります。読み合わせでは、話し手のつまずきと、聞き手の理解のつまずきを分けて記録します。読めなかった単語を直すだけで終わらず、「その説明を聞いた人は次に何をすればよいか」まで確認すると、撮影前の修正が具体的になります。

予定尺は設計の目安、実測は読んだ条件つきの記録にする

文字数を一定の読み上げ速度で割った値は、原稿の大きさを見積もる参考にはなります。しかし、固有名詞、数字、間、表示の確認、実演の待ち時間によって長さは変わります。計算した時間を「必ず収まる尺」と扱わず、まず本人が普段の速さで読みます。今回掲載する原稿例は実録していないため、実測の所要時間は示しません。

時間を測るときは、文章を読む時間と、画面を見てもらう間を含んだ時間を混同しないようにします。予定より長ければ、最初に同じ説明の繰り返し、今回の問いに不要な寄り道、例の多すぎる箇所を探します。すべてを早口にして入れ込むと、数字を確認する間や、条件を理解する間まで失いやすくなります。

削る候補と残す条件を分けると判断しやすくなります。「同じファイル名を別の言い方で三度説明している」は削る候補です。「この例では」「まだ確認していない場合」「実運用の前に既存ルールを確かめる」は意味を支える条件です。尺に収まらないなら、条件を削るより例を一つに絞る、関連する話題を次の動画へ移すといった変更を考えます。

※表は横にスクロールできます。

話す原稿の完成例を、一つの流れとして読む

次は、ここまでの設計をつないだ自作の読み原稿です。説明用の架空チームを想定した例で、実施済みの研修や投稿の記録ではありません。角括弧の行は、話さずに使う注記です。画面やカットの設計とは分けて、言葉の意味と読みやすさを確かめるために使います。

聞いた人には感想より、理解した内容を尋ねる

読み合わせの相手に「分かりやすかったですか」とだけ尋ねると、どこを直すべきかが見えないことがあります。「対象日は何の日でしたか」「初稿は確認前と確認後のどちらですか」「この説明を聞いたあと、最初に何をしますか」と質問すれば、原稿の目的に沿った確認になります。相手が間違えたときは、まず説明の順番や言葉を点検し、理解力のせいにしないようにします。

一人で作る場合は、少し時間を空けて録音を聞き直す方法もあります。原稿を見ずに聞くと、指示語の対象や数字の意味が抜けている場所に気づくことがあります。ただし、自分は答えを知っているため、第三者と同じ状態にはなれません。重要な説明ほど、対象者に近い人へ確認してもらえるなら、その機会を使うとよいでしょう。

撮影へ渡す原稿に、確定した範囲を示す

最終版には、題名、版、確認した日、話す本文、読まない注記、未確定事項を区別して残します。「最終」「最終修正」「本当の最終」のように名称だけが増える状態を避け、撮影で使う版を一つに決めます。後から文を変えた場合は、変えた場所と、それによって根拠や表示の修正が必要かを確認してから渡します。

YouTubeの撮影に関するヒントでも、概要や脚本などの論点のコピーを用意することが案内されています。言葉の原稿が整った後、画面や音、カットの対応も設計したい場合は、絵コンテの書き方をまとめた記事を別工程として確認できます。

公開後の反応を次の台本の仮説に変える

公開後は、再生回数だけで台本の良し悪しを決めず、どの説明を次に見直すかを考えます。視聴者の反応、コメントでの質問、動画内の該当する言葉を並べると、具体的な修正候補にしやすくなります。ただし、動画の反応には題材、タイトル、画面、音、視聴者の状態なども関わります。一つの数字の変化から、台本だけが原因だと断定しないようにしましょう。

維持率の山や谷は、原稿を読み返す手がかりにする

YouTube公式の視聴者維持率の説明では、山には繰り返し視聴や共有が関わり、内容が不明確で見直された可能性も示されています。谷には、視聴の中止とスキップが含まれます。グラフだけで好評・不評や原因を決めず、該当部分を見直す手がかりにします。

同じ公式資料のイントロ指標は、最初の三十秒を過ぎても見続けた視聴者の割合です。三十秒の挨拶を必ず置くという制作ルールではありません。また、重要なシーンのハイライトは常に出るわけではなく、検出や動画の長さ六十秒以上、視聴回数百回以上という条件があります。これはすべての分析機能の利用条件を示すものではありません。処理時間の通常一〜二日という案内も、反映時刻の保証ではありません。

例えば、日付の説明の周辺に山が見つかったとします。その部分が役立ち、見直された可能性もあれば、対象日と作成日の違いが分からず、聞き直された可能性もあります。原稿を開き、定義が先にあるか、同じ語を途中から違う意味で使っていないか、表示と話す文が合っているかを確認します。山があるから説明を削る、あるいは必ず増やす、と即断しないことが大切です。

観察したことと、考えた理由を別の欄に書く

改善メモの「観察」には、実際に確認できた反応だけを書きます。「対象日について質問が届いた」と「視聴者は全員、対象日が分からない」は別の内容です。後者まで言える根拠がなければ、質問の内容と対象の箇所を残すにとどめます。反応が少ない段階では、大きな結論より、次に確かめたい一点へ落とし込む方が原稿の修正に使えます。

※表は横にスクロールできます。

この表は効果測定の結果ではありません。実際に使うときは、観察した日時、該当する動画と箇所、確認できた反応の範囲を自分の記録へ置き換えます。「次の原稿で変える点」と「期待する効果」を同じ欄にしてしまうと、変更しただけで改善した気分になりがちです。実施した変更と、その後に確認できたことは別々に残しましょう。

一度に直す範囲を絞り、結果を言い切りすぎない

タイトル、冒頭、説明の順番、画面、長さを同時に変えれば、見直した動画は作れても、何が反応へ影響したかは判断しにくくなります。実制作では複数の変更が必要になることもありますが、その場合は変更点を全部記録します。「今回は定義を前に出したことを主に確かめたい」と目的を置き、他の違いも残すと、都合のよい説明だけを採用しにくくなります。

次の動画で反応が変わっても、それだけで因果関係が証明されたとは言えません。視聴者や題材が変わっているかもしれないからです。「定義を前に出した原稿では、この質問が見られなかった」という観察と、「定義を前に出せば誰でも理解する」という一般化を分けます。台本の改善は、万能な正解を一度で探すより、説明しやすい形と確認方法を蓄積する作業として続けます。

反対に、意味の誤りや前提の欠落に気づいたときは、反応が増えるまで待つ必要はありません。事実確認の表へ戻り、何が誤りで、どこへ影響するかを確かめます。公開済みの内容への対応と、次回の台本の改善は、必要に応じてそれぞれ判断します。単に数値が低いから直すのか、説明に誤りがあるから直すのかを混同しないことが重要です。

次の一本へ持ち越すのは、書式と確認の問いにする

次回に再利用するのは、今回の文章を少し置き換えた完成原稿より、目的票、根拠の欄、章ごとの問い、読み合わせの修正票です。対象者も題材も変われば、必要な例や順番は変わります。書式を使いながら、その動画で初めて見る人に何を理解してほしいかを改めて決めると、型だけが同じで中身が薄い説明になることを避けやすくなります。

最初の一本では、まず中心の問いを書き、その答えに必要な事実と例を集めます。次に、視聴者の疑問が生まれる順で並べ、声で伝わる文へ直します。読み合わせで条件と抜けを確かめ、使う版を一つに決めたら、撮影へ渡せる原稿になります。公開後は反応を確かめ、次にどの言葉を直すかという小さな仮説へつなげましょう。

公式資料の確認日：二〇二六年十月五日（UTC）。機能やポリシーの案内は変更される場合があるため、制作・公開時には本文中の公式リンクで対象条件を確認してください。