読者です 読者をやめる 読者になる 読者になる

21世紀の文字起こし

editing transcript

気づき

少し前にこのようなことに気がついた。

「いずれそうなるだろう」とは思っていたが「まだしばらく先のことだろう」とも思っていた現実が、想像していたよりずっと間近に迫っていた、ということに驚いた。

さらに言えば、このときはiPhoneに向かって喋ったらみるみるテキスト化されていくので「なんだこれ……!」と衝撃を受けたのだったが、実際にはその後に起こったことのほうがすごくて、Googleドキュメントの音声入力機能と、SoundflowerというMacのアプリケーションを組み合わせたところ、もはやわざわざ喋らなくてもMacで再生した音声ファイルがそのままGoogleドキュメント上でテキスト化されてしまい、ひっくり返った。

https://dl.dropboxusercontent.com/u/7779513/transcript/talk3.gif

これは今年の初めに吉祥寺.pmで発表したときの録音を、後述の方法で読み込ませているところ。

日本語だとちょっともっさりした感じだが、英語だとこうなる。

https://dl.dropboxusercontent.com/u/7779513/transcript/reading.gif

むちゃくちゃ速い。よく見ると、ところどころで誤認識をしているのだけど、手で打ちこんだ場合との違いを考えれば充分許容ではないかと感じる。

また日本語にしても、丁寧かつ明瞭に発声した音声ファイルであれば、上に示した日本語版の動画より速く、よどみなくテキスト化されていく。

そもそも文字起こしとは

さてしかし、ではそれがどれだけ実用的なのかというと、まだ業務の現場を劇的に変革するほどではないとも感じる。

冒頭のツイートをしたときには「未来はすでに来ていた! 今この瞬間から、文字起こしのやり方を変えなければ!」ぐらいに思ったが、それは半分正しく半分期待しすぎだった。

どういうことかと言うと、まずそもそも文字起こしという作業は、以下のような工程で構成されている。(あくまでぼく個人の場合)

  1. 音声を聴きながら、抜け漏れやタイプミス込みでよいので、一旦最後まで音を止めずに起こしていく。
  2. 2周め以降は一時停止や巻き戻しの回数を増やしながら、ひとまずすべての音声をテキスト化する。
  3. 2の仕上がりには不要な語句や倒置が多いので、文章として読みやすくなるよう修正していく。

文章を仕上げるためには、さらに

4. 全体の構成を工夫して読み物として仕上げる。

という工程が必須になるが、それはもう「文字起こし」ではなく「編集」である。*1
よって、ぼくの考える「文字起こし」は上記の3まで。

※ちなみに、3と4の違いがわかりづらいかもしれないが、3の目的は「人間が読みやすい状態にすること」で、4の目的はそれを「良いもの」にすることである。

その1〜3のうち、機械が担当できる作業は人間の判断が不要な1と2までだが、今回話題にしている音声入力技術にできることは、「1の精度をちょっと良くしたもの」であり、2はできない。

なぜ2が「できない」のかというと、2をやるためにはすでにテキスト化された部分のうちどこが抜け漏れなのか、あるいは間違っているのか、という判定や検討が必要で、しかしここで対象としている機械にはその機能がないからである。

好意的に、期待を込めて言い換えれば、「1」の精度が高くなれば「2」は不要になる。つまり現状の先にあるのは「1+2」を機械が終わらせてくれることだが、現時点ではせいぜい「1プラスアルファ」しかできない、ということ。

加えて、その「1プラスアルファ」を機械にさせるために必要な準備もけっして少なくはない。
よって、その導入コストを許容範囲内の投資と捉えるか、「そこまで面倒なら今は手を出さないよ」と捉えるかによって対応は異なるだろう。

ではその「「1プラスアルファ」をさせるために必要なこと」とは何かというと、以下のようなことである。

  1. 素材の音声を聞きながら、明瞭な調子で新たな録音を行う。
  2. それをGoogleドキュメントに読ませる間、読み込みが途中で止まってしまったら(数秒〜数十秒に一度止まる)すぐに再起動させられるよう、つきっきりで世話をする。

これをやれば、通常の文字起こしによる上記工程の1と同等か、それよりちょっとマシ、というぐらいのものができる。

また、導入を検討する際の主な要素には、そうした「精度」の他に、「かかる時間」や「労力」もある。

かかる時間に関しては、たとえば60分の音声ファイルを扱う場合、通常の工程であれば60分強で済むことになるが(あくまで1の作業のみ)、音声入力の工程だと「再録音」と「音声を読み込ませる」工程が必要なため、少なくとも素材音声の倍、あるいは2.5倍〜3倍程度の時間がかかるかもしれない。

一方、「労力」に関して言うと、音声入力の工程における「再録音」は「音を聴きながら音を発声する」という音声同士の変換行為であり、これはその次の「つきっきりで再読み込みさせる」という作業にも言えることだが、頭や体への負荷が少ない単純作業である。

これが通常の文字起こしだと、「音を聞きながら文字を書いていく」という「音(聴覚)→文字(視覚)」の変換作業を行うため、そうした「異なる次元の感覚を駆動する」ことが独特の疲労につながる。

たとえてみると、音声入力における各工程は「一つのことを上手くやる」というUNIX的な行為であり、通常の文字起こしはオーケストラの指揮者がやるような、様々な種類の異なる作業を並行して進めるマルチタスク的行為である。

さらに言えば、音声入力ではタイピングが不要である。よって、体への負担という意味では比較の余地もなく音声入力のほうがラクである。

そもそも文字起こしとは(2)

ではそのようなメリット・デメリットを踏まえ、現時点でぼくはどう結論を出しているかというと、可能なかぎり機械の力を借りるべきだと考えている。

もしかすると、トータルのスピードはまだ、すべて人力でやったほうが速いかもしれない。しかし、上述のとおり人力による文字起こしは非常に疲れるため、それをやれば他のことができなくなるか、同等のなんらかの影響が生じることになる。

そしてそもそも、というかこれが一番大事なことなのだが、文字起こしは人間がやるような仕事ではない。
人間がやるべきことはその後の文章構成、つまり元々の話された内容を、テキスト上でどのように再構成するか検討・判断する作業であって、その前の段階まではさほど重要なものではない。*2 *3

そしてそのように、「さほど重要ではない」にもかかわらず、現在通常の工程として行われる文字起こしという作業はなかなか過酷で、見返りも少ない。

朝9時からスタートして、その日の18時までやればそれなりの進捗は出る。2時間程度の素材なら、その調子で3日もやれば充分終わるだろう。
しかし、その代償は大きい。やったことのある人にはわかるだろうが、非常に多くのものを捧げて、それはようやく仕上がる。

だからぼくとしては、もうそういうことはなるべく人間がせずに済むようになってほしいと考えている。
現時点では、音声入力のメリットはまだわずかなもので、むしろ後述するような導入コストを考慮すれば、人によってはデメリットのほうが大きくすらあるかもしれないが、いずれは比べるまでもないほどメリットのほうが大きくなるだろう。

音声入力による文字起こしの実践法(Mac

以下、今回試みた具体的な音声入力の作業工程を示しておく。

先に概要を示すと、次のような工程をたどる。

  • 1. 素材音声の再録音
    • 大元の音声ファイルを読み込ませても精度が低いため、読み取り用に同じ内容を自分で喋り、それを録音する。
  • 2. Soundflowerの準備
    • Soundflowerというソフトウェアを使うと、事前に録音しておいた音声ファイルをテキスト化させることができる。その導入手順。
  • 3. Mac内部で再生+聞き取り
    • 音声入力をするまで。
  • 4. 音声ファイルが終わるまで再読み込みなどのケア
    • 数秒〜数十秒ごとに音声入力が止まってしまうので、その対応について。

なお、この手順はすべてぼく個人の環境に依存しているので、同様のことができない人はそれぞれの環境に置き換え・読み替えてほしい。

1. 素材音声の再録音

まずはGoogleドキュメントに読み込ませるための音声ファイルを作成(再録音)する。

「機械の力を借りるべき」などと言うわりにずいぶんアナログな工程だと自分でも思うが、食洗機に入れる前に軽く油汚れなどを落としておくようなものだと思えばよい。
マシンをより効率的に活用するためのハックとも言える。

後述のように、とくに専用ソフトなどは使わずに行うことも可能だが、ぼくの場合はMacのExpress Scribeという文字起こし用のソフトで、通常の80%程度に遅く設定した上で元の音声ファイルを再生し、それをイヤホンで聴きながら、手に持ったICレコーダーへ発声して録音していく。

通常の再生速度であればこの作業自体が早く終わるという利点があるが、聞き取れずに後戻りしなければならなくなる可能性も高まること、また逆に、遅くしすぎると作業自体がなかなか終わらなくなるので、総合的に見て80%程度が最適かと思っている。

と同時に、環境によってはわざわざ再生速度を調整しなくてもよいとは思う。
たとえば、iPhoneからイヤホンで対象の音源を聴きながら、手元のICレコーダーに喋って録音していくような方法であれば、コンピューターに縛られず作業できるのでそれなりのメリットもあるし、実際そのように試したがけっこう快適だった。

聞き落としによる後戻りの可能性などを考慮しない場合には、それもありだと思う。

2. Soundflowerの準備

Googleドキュメントに音声ファイルを読み込ませるために、Soundflower というソフトウェアを使う。

このソフトは本来、Macから流れる音声をそのまま(スピーカーを通さずにマシン内で)録音するためのものだが、今回の用途にも適している。

導入方法を検索すると、新旧様々な紹介記事が出てくるのでかえってわかりづらいのだけど、最近のヴァージョンを扱った記事としては以下のまとめが詳しかった。多謝。

インストールが完了したら、Macの環境設定/サウンドか、Optionを押しながらメニューバーのスピーカーマークを押して、以下のように設定する。

f:id:note103:20160710040842p:plain

入出力ともにSoundflowerにするのがポイント。なお、2chと64chの違いは理解していないが、2chでとくに問題ないのでそのようにしている。

3. Mac内部で再生+聞き取り

Googleドキュメントで、記録するための新規ファイルを作成する。

※この際、ブラウザはGoogle Chromeを使用する。Firefoxでも試したのだけど、下記の「ツール/音声入力」という項目名が、確認はできるものの選択できない状態になっていた。その他のブラウザは未確認。

f:id:note103:20160710125926p:plain

ドキュメントを作成したら、ファイル内のメニューバーから、ツール/音声入力の順で選択。

f:id:note103:20160710125940p:plain

マイクのボタンが出てくる。

f:id:note103:20160710125948p:plain

ボタンをクリックすると、赤くなって入力待機状態になる。

f:id:note103:20160710125958p:plain

このとき、すでに音声が流れていれば、自動的に入力が始まる。

f:id:note103:20160710130014p:plain

同じボタンを押すか、一定時間無音が続くと、自動的に録音は止まる。

なお、録音中に別のアプリケーションへ移っても、録音は止まってしまう。
よって、録音を開始してから音声を再生したい場合は、アプリケーションを切り替えなくてもキーボードから再生できるように準備しておくとよい。

また、上記2の設定が済んでいれば、再生しても音が外には出てこない。

音が聞こえないので、再生されているのか少し不安になるが、プレイヤーの表示を見れば秒数が増えていくのを認識できるので、それも目に入るようウィンドウを並べておくとよいだろう。(というか、ぼくはそうしているということ)

4. 音声ファイルが終わるまで再読み込みなどのケア

前述のように、入力は音声ファイルが止まるまで続くわけではなく、途中で止まる。いわばフリーズしたような状態になる。
調子が良ければ1分以上入力され続けることもあるが、平均的には40秒程度かもしれない。

困るのは、入力がフリーズしてもそれが視覚的にわからないことだ。
マイクは赤く待機状態を示したままなので、しばらくすれば入力が再開されるのかな、と思うが、止まったままのこともあればやっぱり動き出す、ということもある。

よって2秒程度入力が止まったら、もうフリーズしたとみなして再起動する。
具体的には、マイクボタンを押して一度入力機能をストップし、もう一度押して再開させる。すると、また入力が始まる。

※上のスクリーンショットでも確認できるが、再読み込みは「コマンド+シフト+S」のショートカットキーでも可能である。というかぼくはそれを使っている。

そしてこの再読み込み作業をファイルが終わるまでくり返す。

ちなみに、音声ファイルの音質が粗かったり、喋るスピードが速かったりすると頻繁にフリーズするという印象がある。

その意味でも、音質を最大限改善するために録音し直しておくことは有効だと考えているし、逆に言うと、この聞き取り能力が向上すれば、再録音の必要はなくなるかもしれない。

また、同じくフリーズの頻度を下げる目的で、再録音の際に使用したExpress Scribeをここでも使い、再生速度を少し遅くした上で読み込ませている。

まとめ 〜そしてtextlint編へ〜

音声入力による文字起こしの工程は以上。

ちなみに、ここまでの話ではとくに触れなかったが、冒頭の動画で示したように英語の音声は再録音をしなくても*4かなりのスピードでテキスト化されていくので、音質さえよければその工程は省略できるだろう。

しかし日本語で語られた音声ファイルの場合は、その再録音や最後の再読み込み作業は避けがたい工程かなと思っている。(いずれは機能の向上にしたがって不要になるかもしれないし、それを期待するけれど)

ところで、じつはこの話題はここで終わりではなくて、前半で挙げた文字起こしの3工程のうち、

  1. 音声を聴きながら、抜け漏れやタイプミス込みでよいので、一旦最後まで音を止めずに起こしていく。
  2. 2周め以降は一時停止や巻き戻しの回数を増やしながら、ひとまずすべての音声をテキスト化する。
  3. 2の仕上がりには不要な語句や倒置が多いので、文章として読みやすくなるよう修正していく。

ここまでに紹介した音声入力が担うのは1だが、続く2と3の作業を軽減・サポートする技術として、このブログでも何度か取り上げた「textlint」がある。

ぼくにとっての未来の文字起こしは、そのtextlintを音声入力と組み合わせることによって成立するのだけど、すでにだいぶ長くなったので、この記事では音声入力についてまでとする。

textlintを効率的な文字起こしに際してどう使うか、という話はまた機会ができたときに。

*1:あくまで便宜的な腑分けだが。

*2:と言いつつ、実際にはそうした構成作業にしてもいずれは機械がやってくれるかもしれないとは思っているのだけど。人間に残されるのは、そうして出来たものをユーザーとして「楽しむ」ことだけになるかもしれないし、それならそれで、まあ構わない。

*3:さらに注釈を重ねると、じつはぼくとしても重要な原稿は文字起こしから自分で担当してしまったほうがいいと考えている。作業としてはヘビーだが、それによって元の内容を理解しやすくなるし、何より結局その後の編集作業を自分でやるのであれば、初めから自分の方針に沿って作られた文字起こしを元にしたほうが余計な修正が生じずラクだからである。

*4:むしろ自分で再録音したら発音が不正確で精度が落ちそうだ。というか落ちるだろう。