要点
まず文字起こしをして、タイムスタンプを入れる。それを公開するものとしてではなく、素材として扱う。タイムスタンプはチャプターの位置になる。テキストからは引用したい一節が見つかるが、公開する前に必ず音声と照らし合わせて確認する。要約は「聴くかどうか迷っている人」のために書き、ショーノートは「すでに聴いた人」のために書く。文字起こしをそのままノートとして公開しても、どちらの読者にも役立たない。話し言葉には、聴いているときは気にならなかった繰り返しや言い直しがたくさん含まれているからだ。
録音が終わり、編集も終わった。そこで誰も教えてくれなかった二番目の仕事が待っている。ノート作り、チャプターの区切り、フィード用の要約、SNS用の投稿を二つか三つ。多くのポッドキャスターはこれを記憶とシークバー頼りでやっている。70分の音声を行き来しながら、ゲストがいいことを言った箇所を探すのだ。編集と同じくらい時間がかかり、結果もあいまいになる。半分しか覚えていないエピソードについて説明しているのだから当然だ。
文字起こしがあれば、この「探す」問題は解決する。ただ、ノートを書いてくれるわけではない。文字起こしがしてくれるのは、これらの作業すべてを「検索する作業」から「編集する作業」に変えることだ。編集は検索よりずっと速い。どのツールを使うかより、どの順番で作業するかのほうが重要になる。
文字起こしから始める、ノートからではない
うまくいく順序はこうだ。タイムスタンプ付きの文字起こし → チャプター → 引用したい一節 → 要約 → ショーノート → SNS投稿。それぞれの工程は、前の工程が生み出したものを使う。先にノートを書いてしまうと、結局チャプターの位置を探すために音声を巻き戻し、さらに引用のためにもう一度巻き戻すことになる。
タイムスタンプは省略されがちで、後で必ず後悔する部分だ。文字だけがずらっと並んでいても、何が話されたかは分かる。しかしタイムスタンプは「どこで」話されたかを教えてくれる。そして後続のすべての作業が必要としているのは、まさにこの「どこで」だ。チャプターの区切りは位置であり、引用一節を確認するにも位置が必要で、「価格の話はどこでしていた?」と聞くリスナーが欲しいのも位置だ。タイムスタンプのない文字起こしは問題の半分しか解決せず、残り半分はやはりシークバー頼りになる。
文字起こしを手に入れる方法はいくつもある。配信ホスティング側が公開時に自動生成してくれる場合もあれば、編集ソフトからセッションデータとして書き出せる場合もあるし、専用ツールを使う手もある。実際に違いが出るのは、話者ラベル、タイムスタンプの細かさ、そして聞き取りにくい単語の扱いだ。ポッドキャストの文字起こしはもう十分にこなれた分野なので、どれを選ぶかより、書きながら別ウィンドウで文字起こしを開いておくこと自体のほうが重要になる。
普段使っているマシンで作業を済ませたいなら、SozAIはiOS、Android、macOS向けの文字起こしアプリで、音声ファイルや動画ファイル、あるいはYouTubeのリンクを渡すと、話者ラベル付きのテキストと要約を返してくれる。これはいくつかある選択肢の一つにすぎない。配信ホスティング側がすでに使えるタイムスタンプ付き文字起こしを出してくれるなら、それを使ってこの追加の手順は省いてよい。
正直に言うと、エピソードが短く、話題が一つで、二行程度の説明とリンクだけを載せているなら、このワークフローは過剰だ。文字起こしが割に合うのは、いくつもの話題が入り混じった長めの対話形式のエピソードであり、それはほとんどのインタビュー系番組に当てはまる。
チャプターの区切りはタイムスタンプから生まれる、テキストからではない
チャプターとは音声上の位置のことだ。当たり前に聞こえるかもしれないが、要約からチャプターを作ろうとしてみると、要約には位置という情報がまるごと存在しないことに気づく。要約は「このエピソードでは採用、価格、燃え尽きについて話した」とは教えてくれる。しかし「価格の話は14分過ぎから始まった」とは教えてくれない。その情報はそもそも要約の文章の中に入っていないからだ。
そこで文字起こしを二段階で使う。まず一度通しでざっと読み、話題が実際に切り替わる場所に印をつける。次に、新しい話題の最初の行のタイムスタンプを取る。前の話題の最後の行ではない。そうすれば、チャプターに飛んだリスナーが、前の話題の余韻ではなく、その話題の始まりに着地できる。
どこで話題が切り替わったかを判断するのは、あくまで人間の判断であり、それは変わらない。会話は綺麗に話題を切り替えるわけではなく、揺れ動き、元に戻り、そのあとで誰かが語ったエピソードが実はそのセグメントの本題だったりする。そのエピソードを独立したチャプターにするか、周りの話題の一部として扱うかは自分で決めるしかない。自動生成された要約はこの判断を代わりにやってくれない。判断はリスナーが飛びたくなる場所がどこかという予想に基づいているからだ。
- 言及されたすべての話題ではなく、リスナーが実際に飛びたくなりそうな箇所をチャプターにする。
- 構成ではなく内容で名前をつける。「無料プランをやめた理由」は「第3部」より優れている。
- オープニングと広告読みは短い専用のチャプターにして、聞き飛ばせるようにする。
- 最後のチャプターがアウトロの最中ではなく、その前から始まっているか確認する。
フォーマットはプラットフォームによって異なる。時・分・秒を求めるものもあれば、分と秒だけでいいものもあり、特定の区切り記号を求めるものもある。プレイヤーに拒否されるチャプターファイルは、チャプターがない状態より悪い。フォーマット間で変換が必要なときは、ブラウザで使えるタイムコード変換ツールを使えば、深夜に電卓片手に計算する必要がなくなる。
引用一節と、それでも確認が必要な理由
文字起こしを流し読みして引用したい行を探すのは、音声を聴きながら探すよりずっと速く、話されたことを忘れていた部分も見つかる。前置きなしで一文だけで成立している行を探そう。会話の中でこうした行は思っているより少ない。良い瞬間の多くは、その前の質問があってこそ成り立っているからで、三文分の文脈が必要な一節は引用一節とは呼べない。
そして、画像や投稿に使う前に、必ず音声と照らし合わせて確認する。これは省略できない工程で、理由は少し気まずい。自動文字起こしのミスは、まさに人が引用したくなるような印象的な一節に集中して発生する。珍しい言葉選び、独自の造語、力の入った言い方、興奮して早口になっている箇所――こうした条件はテキストの信頼性が最も低くなる条件であり、同時に、48ポイントの大きな文字で載せたくなるような文章を生む条件でもある。
タイムスタンプがあれば確認はほとんど手間にならない。その位置に飛び、15秒ほど聴き、言葉を確かめる。これを4つの引用について行っても数分しかかからない。ゲストの発言を誤って引用して公開してしまうコストは、それよりはるかに大きい。
軽い整えは問題ない。「あの」を削る、言い直しを省く、削った部分を三点リーダーで示す、といった編集は妥当だ。しかし、相手が言ったことを、明らかにそういう意味だったからといって、より整った文章に書き換えてしまうのは別の話だ。
要約とショーノートは、それぞれ別の読者のために書く
要約を読むのは、まだ聴いていない人で、聴くかどうかを決めようとしている人だ。要約はそれ単体で成立する文章でなければならない。そのエピソードが何についてのものか、誰が出ているか、どんな主張があるか、なぜ1時間かける価値があるかもしれないか。要約は内容を予告するのではなく、要点そのものを見せるべきだ。要点を隠す要約は予告編のように読まれ、人は予告編を飛ばすものだから。
ショーノートを読むのは、すでに聴いた人、あるいはノートを開きながらまさに聴いている最中の人だ。この読者が欲しいのは、音声からは取り出せない具体的な情報――話題に出た本、ゲストのアカウント名、議論になった調査、名前の表記がややこしいツール、前のエピソードへのリンクなど。チャプターもここに置く。この読者に何かを売り込む必要はない。
よくある失敗は、一つの段落で両方の役目を済ませようとすることだ。その結果、要約としてはあいまいすぎて役に立たず、参照資料としては情報が少なすぎるものが出来上がる。分けて書くこと。どちらも短くて構わない。
動画版も公開しているなら、動画プラットフォームの説明欄はまた別の三番目の読者向けだ。多くは検索やおすすめから来た人たちになる。YouTubeのリンクから使える要約ツールにエピソードを通せば、その欄用の下書きが得られる。ただし、他の工程と同じように編集は必要になる。
名前だけは絶対に間違えてはいけない
文字起こしがあれば過去のエピソードを検索できるようになる。これは、あるトピックについて話した回をリスナーが見つけられるか、2回試して諦めるかの分かれ目になる。音声は検索できない。テキストはできる。文字起こしのアーカイブがあれば、30時間分の会話の中身を実際に覗けるようになる。
問題は、間違って文字起こしされやすい言葉が、まさに人が検索する言葉だということだ。ゲストの名前、会社名、製品名――一般的な固有名詞全般、特に一般的な単語ではないものほどそうなる。珍しい言葉だからこそ文字起こしが苦手とし、固有の言葉だからこそ誰かが検索欄に打ち込む言葉になる。
他の何を書く前に、まずこれを直す。文字起こしを開き、出てくると分かっている名前をそれぞれ検索し、一度の作業ですべての箇所を修正する。数分で終わり、あとに波及する。正しい表記はチャプタータイトル、引用、要約、ノートへと自動的に流れ込み、四か所別々に気づく必要がなくなる。同じ名前が二つ三つの違う間違った表記で出てくることもあるので注意する。一回の検索置換では一つしか直らない。
文字起こしがやってくれないこと
文字起こしはショーノートにはならない。文字起こしをそのままノート欄に貼り付けるのは、この工程全体の中で最もよくある間違いで、聞こえのとおりにひどい仕上がりになる。話し言葉には繰り返し、言い直し、途中で放棄された文、聴いているときはまったく気にならない脱線が満ちている。リスナーはゲストが「つまり」を9回言ったことに気づいていない。読者はすぐに気づく。
それに、特定の誰の役にも立たない。聴くかどうか決めたい人は1万1千語も読みたくない。すでに聴いた人が欲しいのはリンクや参照情報であって、たった今聴いたことを劣化させて再現したものではない。それは水増しにしか見えず、検索エンジンは水増しされたページを長いあいだ見てきている。
文字起こしを、それとわかる形で専用ページに公開するのは、これとは別の話であり、妥当なやり方だ。アクセシビリティと検索のためのものであり、そのページを開いた読者は自分が何を読んでいるのか分かっている。
文字起こしを読み物としての記事に仕立て直すことは可能で、それはれっきとした書く仕事だ。構成を組み替え、削り、声が伝えていた文脈をページのために書き足す。そのための時間をきちんと確保するか、やらないかのどちらかにする。文字起こしはシークバーの手間を省いてくれる。書く手間は省いてくれない。それ以外を約束するワークフローは、誰も読まないショーノートについて語っているだけだ。
