文字起こしの修正時間を大幅削減しながら、記事の品質を高めるしくみ

取材後の文字起こしクレンジングは、長年ずっと地味にしんどい工程でした。

音源を聴きながらテキストを見て、間違っている箇所を直す。外来語、固有名詞、専門用語。同音異義語。「あのー」「えー」などのフィラー。これを1本のインタビューで何十箇所も繰り返す。

Claude Codeのワークフローに移してから、この工程の修正時間が体感で9割減りました。

英語と日本語で、まったく違う問題がある

まず前提として、英語と日本語の文字起こしでは課題が異なります。

英語音声認識AIについては、2021年ごろからAmazon Transcribeを使っていますが、精度が最初から高かったです。アメリカ英語はもちろん、フランス訛り、インド訛り、さまざまなアクセントでもきれいに書き起こしてくれる。海外スタートアップのファウンダーに英語でインタビューしても、ほぼそのまま使えるクオリティでした。

一方、日本語の文字起こしで問題になるのは主に3つです。

同音異義語:「きかく」が「企画」なのか「規格」なのか「機械」なのか、文脈がないと判断できない。

外来語・専門用語:IT系の取材だと「クラウドネイティブ」「Kubernetes(クーバネティス)」「MITRE ATT&CK(マイターアタック)」のような用語が頻出し、新しい言葉も次々と現れます。音声認識AIにとっては結構な難敵です。

フィラー:「あのー」「えー」「そのー」という話し言葉特有の言い淀み。記事にそのまま残すと読みにくくなります。これは英語でも「uh,」や「you know,」などがあります。

AmiVoiceのAPI導入でフィラー問題は解決

日本語の文字起こしにはAmiVoiceのAPIを採用しています。暗号化通信・AI学習不可というセキュアな仕様で、弊社のAWS環境と連携しています。

AmiVoiceのAPIには、フィラー除去機能があります。「あのー」「えー」を自動で消してくれる。これは非常に助かる機能で、記者が読みやすいテキストをほぼ自動で出してくれる。

ただし、完璧ではない。IT系の取材では「AI」という単語が頻出するが、日本語で「エーアイ」と発音したとき、最初の「エー」をフィラーと誤認識して削除してしまうことが稀にあります。「AI活用を推進します」が「I活用を推進します」になるようなケースです。頻度は低いが、こういうケースがあることは把握しておく必要があります。

フィラー除去後も、同音異義語・外来語・専門用語の問題は残る。ここが長年の手作業ゾーンでした。

Claude Codeで何が変わったか

Claude Codeのワークフローに移行して、最も変化が大きかった工程の一つがこのクレンジングです。

以前は、文字起こしテキストだけを見ながら音源を聴いて、一箇所ずつ手動で修正していた。専門用語が出てくるたびに止めて、調べて、直す。これが積み重なると1本のインタビューで相当な時間がかかっていました。

Claude Codeでは、取材資料のPDFと文字起こしファイルを一緒に渡せるんです。チャットUIからは容量制限や情報開示制限などの影響から資料をそのまま利用できないこともあるでしょう。

事前にクライアントから受け取ったサービス資料、製品説明書、質問票——これらをPDFのままClaude Codeに渡すことで、AIが「このインタビューで登場する固有名詞・専門用語・外来語」を事前に把握した状態でクレンジング処理ができます。

さらに、Claudeが判断できなかった箇所は疑問点として一覧で挙げてくれるという処理もつけました。

> 「以下の箇所は音源確認が必要です:○分○秒『〜』→『〜』で合っているか不明」

すでにインタビューしたてで内容が頭に入っている状況であれば、疑問点リストだけの確認をして、執筆工程に進んでもいいでしょう。修正のために何度も音源を止めて書き直していた時間が、疑問点の確認だけに絞ることができるのです。

修正時間が体感で9割減ったというのは、この仕組みによるものです。

Claude Codeと一緒にパイプライン自体を作った

この記事で紹介したワークフローは、Claude Codeとのペアプログラミングで作り直したものです。

2021年に作った社内ツール「Mojio」を、2026年3月にPythonスクリプトとして再実装しました。コマンドライン一本で動く`interview.py`です。やりたいことは明確で、音声ファイルと参照PDFを渡したら、クレンジング済みのテキストファイルが出力される仕組みです。

実装の大半はClaude Codeに指示しながら進みました。「AmiVoiceの非同期APIで話者分離を使いたい」と伝えると、ドキュメントを参照しながらコードを書いてくれます。エラーが出たらスタックトレースを見せれば原因を特定してくれる。APIのレスポンス構造が想定と違えば、実際のレスポンスを渡してパース処理を修正してくれる。

つまずいた箇所はいくつかありました。AmiVoiceのトークン情報がネストされたデータ構造に入っていて最初は取得できなかったこと。音声が長くなると出力が途中で切れてしまい、ストリーミング出力への切り替えが必要だったこと。「ます。」という短い文節が話者分離で前後の発言と切り離されてしまうエッジケース。一つ一つの問題を、Claude Codeとの会話で潰していきました。

「何が起きているか」を言葉で説明して、コードを直してもらい、動作確認して、また説明する——この繰り返しがツールを完成させるプロセスそのものでした。AIの力を借りるためのフローを、AIと一緒に作っているということになります。

通訳ありインタビューにも対応する

もう一つ、今回の再実装で解決した課題があります。英語と日本語が混在するインタビューへの対応です。

海外企業へのインタビューに通訳が入る場合、音源の中には英語の発言と日本語の訳が交互に入ってきます。AmiVoiceは日本語専用、Amazon Transcribeは英語専用のため、以前は2本のファイルを別々に出力して手動で突き合わせていました。

今回の再実装で`–lang mixed`オプションを追加しました。AmiVoiceで日本語を、Amazon Transcribeで英語を同時に処理し、タイムコードで突き合わせて一本にマージした上でClaudeがクレンジングします。誰がいつ話したかは`speakers.txt`で事前に定義しておくと、クレンジング後のテキストに話者名が入ります。

通訳を介した約60分のインタビューを処理した際、マージからクレンジング完了まで15分程度でした。コストはAPIの合計で200円〜300円程度です。

それでも人が確認する工程は残る

誤解してほしくないのは、「文字起こしを読まなくていい」という話ではない。

クレンジング済みのテキストは必ず通して読みます。Claudeが疑問点を挙げてくれた箇所は音源で確認します。発言者のニュアンスや温度感は、テキストだけでは伝わらないことがあります。

変わったのは「修正のたびに止めて書き直す」という繰り返し作業の時間です。全体を読む時間は残るし、残すべきだと思っています。

KIJI Baseのワークフローでも、この「人が確認する工程は省かない」という原則は変わらない。

CLAUDE.mdへの反映

この文字起こしクレンジングのプロセスは、AI編集部OSに定義しており、無料でご利用いただけます。

https://github.com/h-mori-andg/ai-editorial-os

取材資料と文字起こしを渡す順番、疑問点の出力フォーマット、フィラー除去のルール——一度設定しておけば、毎回同じ品質で処理してくれます。使い方がわからない場合は、いつでもお問い合わせください。