文字起こしをそのまま記事にできない理由と、編集の型

1. 3万字のテキストの前で止まる

取材が終わりました。文字起こしツールにかけたら、数分で全文が出てきます。ここまでは速い。

問題はその先です。

• 2時間の取材が3万字になっていて、まず読み返す気力が出ない
• 読み進めても、どこが使える発言でどこが前置きなのか判断がつかない
• 話が何度も戻るので、順番どおりに並べても記事にならない
• 言い直しと相槌を消しながら整えていたら、それだけで半日が消えた
• AIに「要約して」と頼んだら、一番おもしろかった話が消えた
• 「記事にして」と頼んだら、取材相手が言っていないことが混ざっていた
• 結局、自分で全部読み直して手で構成することになった

文字起こしまでは自動化できたのに、そこから先で詰まる。この段差が、音声から記事を作る作業でいちばん重い場所です。

原因は、作業が面倒だからではありません。話し言葉と記事とでは、情報の構造そのものが違うからです。

2. なぜ、そのままでは記事にならないのか

違い1：並び順の原理が違う

話し言葉は時系列で進みます。思い出した順、聞かれた順、話が飛んだ順。人は会話の中でその順番を自然に処理できます。

記事は違います。読者が理解しやすい順に並べ替える必要があります。結論を先に置くのか、経緯から入るのか。時系列とは無関係の論理順です。文字起こしをそのまま整えても読み物にならないのは、並べ替えという工程を飛ばしているからです。

違い2：重要度の情報が消えている

会話では、話者は声の強さ、間、繰り返しで重要度を伝えています。文字起こしになると、この情報は落ちます。一番大事な一言と、場をつなぐための相槌が、同じ文字として並びます。

AIに要約させると大事な話が消えるのは、この重みの情報が入力に含まれていないからです。文字数だけで見れば、10秒の核心より5分の前置きのほうが「量が多い話題」に見えます。

違い3：文字起こしの大半は記事に使わない

取材の内容がすべて記事になるわけではありません。関係構築の雑談、質問の言い直し、確認のやりとり、機材の話。実際に記事で使う発言は、文字起こし全体の1〜2割程度に収まることが多いはずです。

つまり、この作業の本質は「整える」ことではなく「選ぶ」ことです。8割を捨てる作業だと最初から分かっていれば、進め方は変わります。

違い4：話し言葉には省略がある

「あれ、けっこう効きましたね」という発言は、その場では通じます。文字にすると、あれが何かは分かりません。話者が省略した文脈を、書き手が補う必要があります。ここをAIに任せると、補われるのは「ありそうな文脈」であって、実際の文脈ではありません。取材相手が言っていないことが混ざる原因の多くは、この補完です。

---

3. 編集の型：5ステップ

ここからが実践編です。汎用LLMを使いながら、上の4つの違いを工程として処理していきます。プロンプトはそのまま使える形にしてあります。

ステップ0：素材の下ごしらえ

AIに渡す前に、人が5分だけ手を入れます。ここを飛ばすと後の全工程の精度が落ちます。

• 話者ラベルを統一する。 「Aさん」「山田」「話者1」が混在していたら1つに寄せる
• タイムスタンプを残す。 10分刻みで十分です。あとで原文に戻るために要ります
• 明らかな誤変換だけ直す。 固有名詞、数字、専門用語。言い回しは絶対に直さない
• 使わない範囲を物理的に削除する。 冒頭の挨拶、機材トラブル、オフレコ指定部分

言い回しを直さないのが要点です。「なんかこう、ぐっと来る感じ」のような言い方が、後で記事の一番おいしい引用になります。

ステップ1：発言インデックスを作る

いきなり要約させてはいけません。要約は情報を捨てる作業で、何を捨てたかが残らないからです。代わりに、発言を一覧にします。

あなたは編集者です。以下のインタビュー文字起こしから、記事に使える可能性がある発言を
すべて抽出し、表にしてください。要約はしないでください。

【出力形式】
| ID | 時刻 | 発言の要旨(40字以内) | 種別 | 具体度 | 補足が必要な省略 |

・種別：事実 / 数値 / 主張・意見 / 具体エピソード / 感情・本音 / 背景説明 / 対比・比較
・具体度：高（固有名詞・数値・時期が入っている）/ 中 / 低
・「補足が必要な省略」：「あれ」「そこ」など指示語で省略されていて、
  文字だけでは意味が確定しない箇所を書き出す。無ければ空欄

【厳守】
・話者の言葉を言い換えないでください。要旨は原文の語をなるべく使ってください
・文字起こしに書かれていない情報を推測で足さないでください
・判断に迷った発言は、捨てずに「具体度：低」で残してください

【文字起こし】
（ここに貼る）

30〜80行の表ができます。これがこの後の全工程の共通の土台になります。3万字のテキストを何度も読み返す必要がなくなるのが、この工程の一番の効き目です。

「補足が必要な省略」の列も見てください。ここに挙がった項目は、書き手が原文と記憶から埋めるか、取材相手に確認する箇所です。AIに埋めさせてはいけない場所を、最初に可視化しておきます。

ステップ2：この記事の主張を1本に決める

素材が揃った段階で、記事のゴールを先に決めます。ここを決めないまま書き始めると、話題を網羅した何も言っていない記事になります。

あなたは編集長です。先ほどの発言インデックスをもとに、この記事の企画を決めてください。

【前提】
・想定読者：（例：BtoBメーカーで初めてオウンドメディアを任された担当者）
・掲載媒体：（例：自社サイトの導入事例コーナー）
・読者が読み終えたときの状態：（例：自社でも試せそうだと感じている）
・記事の長さ：（例：4000字）

【出力】
1. この記事の主張を1文で（40字以内・断定形）
2. その主張を支える発言IDを5〜8個
3. 惜しいが今回は使わない発言IDを3つと、その理由
4. 主張を支えるには足りない情報と、追加で確認すべき質問（あれば）

【条件】
主張は「〜が重要だ」「〜が求められている」のような、この人でなくても言える形に
しないでください。この取材でしか出てこなかった内容にしてください。

3番目の「使わない理由」を必ず出させてください。判断の履歴が残るので、あとで「やっぱりあの話を入れたい」となったときに戻れます。

4番目で情報の穴が見つかったら、この段階で追加確認を投げるのが一番安く済みます。書き始めてから気づくと、構成ごとやり直しになります。

ステップ3：並べ替える（構成を作る）

時系列を捨てて、論理順に組み直す工程です。

決定した主張と、選んだ発言IDをもとに構成案を作ってください。

【出力形式】
■ リード文で書くこと（箇条書き3点）
■ 見出し構成
  H2（1）：
    - この見出しで読者に渡すこと：
    - 使う発言ID：
    - 想定文字数：
  （H2を4〜6本）
■ 締めで書くこと

【条件】
・見出しに「はじめに」「背景」「課題」「まとめ」「今後の展望」を使わない
・見出しは、それだけ読んで中身が想像できる具体的な文にする
・取材の順番ではなく、読者が理解しやすい順に並べ替える
・割り当てる発言IDが1つもない見出しを作らない
・想定文字数の合計が指定の長さに収まるようにし、重要な見出しに多く配分する

構成案を3パターン出してください。それぞれ「何を軸に並べたか」を一言で添えてください。
（例：時系列軸 / 課題→解決軸 / 読者の疑問順）

3パターン出させるのがおすすめです。1案だけだと、それが良いのか判断できません。並べ替えの軸が3つ並ぶと、この素材にどれが合うかが一目で分かります。

割り当てる発言IDのない見出しを禁止するのも重要です。この制約が無いと、話の流れをつなぐためにAIが一般論の見出しを発明します。取材相手が言っていないことが混ざる、二つ目の主要な入口です。

ステップ4：引用の整え方を決めてから書く

執筆前に、発言をどこまで整えてよいかのルールを決めます。ここが曖昧なまま書くと、原稿の信頼性がぶれます。整え方は3段階で考えると管理しやすくなります。

やってよい操作とだめな操作の線引きを明確にしておきます。

• やってよい：フィラー（えー、あの、まあ）の削除／言い直しの統合／助詞の補い／語順の入れ替え／方言や口癖の温存
• やってはいけない：意味の追加／断定度を上げる（「〜かもしれない」→「〜だ」）／複数箇所の発言をつなげて1つの発言のように見せる／話していない数値や固有名詞の補完

この線引きを決めたうえで、セクション単位で書かせます。

以下の1セクションだけを執筆してください。他のセクションは書かないでください。

【対象】H2（2）：（見出しをコピペ）
【使う発言】ID:12, 18, 23（該当発言の原文をここに貼る）
【文字数】700字前後

【引用ルール】
・引用は「」で囲み、地の文と明確に分ける
・整えてよいのは、フィラー削除・言い直しの統合・助詞の補い・語順の入れ替えまで
・意味を足す、断定度を上げる、離れた発言をつなげて1つの発言にする、は禁止
・貼った発言に含まれない事実・数値・固有名詞を書かない

【文章ルール】
・一文の長さを揃えない。短い文と長い文を混ぜる
・「〜ではないでしょうか」「〜と言えるでしょう」を使わない
・接続詞（また・さらに・加えて）はこのセクションで2回まで
・段落構成を「主張→理由→具体例→まとめ」の型で固定しない

一括で全文を書かせないでください。理由は2つあります。長い出力ほど後半で指示が守られなくなること。そして、1箇所直したいときに全体を再生成せずに済むことです。

ステップ5：原文と照らし合わせる

この工程を飛ばした原稿を取材相手に送るのは危険です。

【記事本文】と【発言原文】を照合してください。

本文を一文ずつ見て、次の表を出力してください。
| 本文の該当箇所 | 根拠となる発言ID | 判定 |

判定は3種類：
・一致：発言に基づいて書かれている
・拡張：発言から推測はできるが、話者はそこまで言っていない
・不明：対応する発言が見当たらない

【条件】
「拡張」と「不明」を必ず洗い出してください。
1件も検出されなかった場合は、確認が甘い可能性が高いので、
もう一度厳しい基準で見直して再出力してください。

「1件も無いなら見直せ」の一文を入れてください。これが無いと、ほぼ全部「一致」で返ってきます。

出てきた「拡張」「不明」は、人が原文に戻って確認します。タイムスタンプを残しておいたのは、このためです。ここは自動化しないほうが安全な工程だと考えてください。

仕上げ：捨てる量の目安と、本人確認

採用率を見る。 発言インデックスの行数に対して、記事で実際に引用した数を数えてみてください。全体の2〜3割を超えていたら、詰め込みすぎのサインです。読者にとっては情報が多いほど良いわけではありません。捨てた発言は、別記事やSNS投稿の素材として取っておけます。

本人確認のときに渡すもの。 完成原稿だけを送ると、相手は全文を読んで違和感を探す作業を強いられます。負担が大きく、結果として細かい確認が返ってきません。引用箇所の一覧（発言原文と、記事での表現の対比）を添えると、確認が速く正確になります。ステップ5の照合表が、ほぼそのまま使えます。

音声から記事にするまでの全体像を工程として俯瞰したい場合は、音声→記事自動生成の全工程に流れがまとまっています。

---

4. それでも残る限界

この型を回せば、汎用LLMだけでも取材相手に見せられる原稿になります。ただ、続けているうちに別の問題が出てきます。

工数がそれほど減りません。 手戻りは確実に減ります。けれど、5ステップそれぞれでプロンプトを貼り、出力を確認し、次に渡す。1本あたりのやりとりは20回を超えます。ステップ1のインデックス作成だけでも、確認と修正に30分はかかります。下書きまで半日、という感覚は大きくは変わりません。

長い素材が入りきりません。 2時間の取材は3万字前後です。工程が進むにつれてインデックス、企画、構成、本文が積み上がり、最初に渡した原文が実質的に参照されなくなります。分割すれば入りますが、分割した時点で全体を見た並べ替えの判断ができなくなります。長い取材ほど、この型の効きが落ちるという逆説があります。

照合が目視から抜けられません。 ステップ5は怪しい箇所を挙げさせるところまでです。最後に原文に戻るのは人の作業として残ります。

品質が毎回ぶれます。 同じプロンプトと同じ素材でも、出力は毎回変わります。良い日と、書き直す日があります。締切のある運用では、この揺れが効いてきます。

チームで再現できません。 うまく回している人の判断基準は、プロンプトの外側にあります。どの発言を捨てるか、どこまで整えてよいか、どの構成案を選ぶか。手順書を共有しても、この判断は移りません。担当者が変わると品質が変わり、結局その人しか回せなくなります。オウンドメディアの運用が特定の一人に依存して止まる、よくある形です。

制作を自社で回すか外に出すかという判断そのものについては、コンテンツ制作の内製 vs 外注で選択肢が整理されています。

限界の正体は、AIの能力ではありません。工程は分解できたのに、工程と工程の受け渡しが人の手作業のまま残っていることです。

---

5. 受け渡しごと仕組みにする

sonataは、この記事で分解した工程そのものを、プロダクトの構造にしたサービスです。音声をアップロードすると、事前のWeb調査、企画、文字起こし、構成、記事生成までが一連の流れとしてつながっていて、工程間の受け渡しが自動で進みます。この音声から記事化までの一連のワークフローについて特許を出願しています。

工程が分かれているので、企画だけ差し替える、構成だけ組み直すといった介入もできます。気に入らない箇所のために全部やり直す必要はありません。

無料プランがあります。手元にある取材音源を1本入れて、この記事の型を自分で回した結果と並べてみるのが、いちばん判断が早いと思います。

• sonataを無料で試す

まずは、いま手元にある文字起こしでステップ1のインデックスだけ作ってみてください。3万字が80行の表になった時点で、何を書く記事なのかが見えてくるはずです。