ChatGPTでインタビュー記事を書く手順｜プロンプトと、それでも残る限界

1. その原稿、たぶんこうなっています

取材が終わって、文字起こしができた。ChatGPTに全文を貼りつけて「これをインタビュー記事にしてください」と打ち込む。数十秒後、たしかに記事の形をしたテキストが返ってくる。

読んでみると、なんとも言えない気持ちになります。

• 話者が現場の言葉で語った部分が、なめらかな一般論に置き換わっている
• 数字や製品名、部署名といった固有の情報が、途中でごっそり抜けている
• 見出しが「はじめに」「背景」「課題」「今後の展望」「まとめ」に落ち着いている
• 一番おもしろかった脱線が、丸ごと消えている
• 逆に、取材で誰も言っていないことが、それらしい顔で書かれている
• 全体として、その人が話した記事ではなく、その業界の誰かが話した記事になっている

間違ってはいない。でも、取材相手に見せられない。結局ゼロから書き直すことになり、AIを使った意味がどこにもなかった、という結末になりがちです。

これはプロンプトの言い回しが下手だから起きているわけではありません。頼み方の構造そのものに原因があります。

2. なぜ「それっぽいだけ」になるのか

原因1：工程をひとつのプロンプトに畳んでいる

人がインタビュー記事を書くとき、実際には別々の作業を順番にこなしています。素材を読み込む、何を伝える記事にするか決める、順番を組み立てる、書く、発言と照らし合わせる、整える。少なくとも6つの独立した判断です。

「記事にして」という指示は、この6工程を1回のやりとりに畳み込んでいます。工程を畳むと、途中の判断が観測できません。どの発言を採用してどれを捨てたのか、なぜその順番にしたのかが、出力からは読み取れない。だから直しようがなく、丸ごと書き直しになります。

原因2：判断に必要な情報を渡していない

文字起こしだけでは、記事に必要な情報の半分も揃っていません。読者は誰か、どの媒体に載るのか、読み終えたあと何を持ち帰ってほしいのか、話者の肩書きや実績、社名の正式表記、公開してよい情報の範囲。これらが無い状態では、平均的で無難な選択しかできません。無難な選択の集積が、あの「どこかで読んだ感じ」の正体です。

原因3：良し悪しの基準を渡していない

評価軸がないと、出力は学習データの平均値に収束します。「良い記事」の定義を渡していないのに、良い記事が出てくることを期待している状態です。

原因4：素材の粒度が荒い

文字起こしは時系列の生データで、重要な発言と相槌が同じ重みで並んでいます。人間なら無意識に濾しているノイズが、そのまま入力されている。重みの情報が無いまま要約させれば、大事な一言が平然と落ちます。

---

3. 汎用LLMでここまでやれる：6工程に分けた実践手順

ここからが本題です。工程を分けて、それぞれに必要な情報と評価軸を渡せば、汎用LLMでもかなりのところまで書けます。以下はそのまま使える形にしてあります。

工程0：素材を整える（AIに渡す前の下ごしらえ）

先にやっておくと、後工程の精度が目に見えて変わります。

• 話者ラベルを統一する（「Aさん」「聞き手」など。表記ゆれは全部潰す）
• 10分おきくらいにタイムスタンプを残す（後で原文に戻るため）
• 明らかな誤変換だけ直す（固有名詞・数字・専門用語。言い回しは直さない）
• 雑談・機材トラブル・オフレコ指定部分は物理的に削除する

言い回しをこの段階で整えないのが要点です。話し言葉の癖は、後の工程で「その人らしさ」の材料になります。

工程1：発言の棚卸し（要約ではなく、インデックスを作る）

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

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

【出力形式】
| ID | 発言の要旨(40字以内) | 種別 | 具体度 | 記事での使いどころ |
|----|---------------------|------|--------|-------------------|

・種別は次から選ぶ：事実 / 数値 / 意見・主張 / 具体エピソード / 感情・本音 / 背景説明
・具体度は 高/中/低 の3段階。固有名詞・数字・時期が入っていれば「高」
・「使いどころ」は リード / 本論 / 補足 / 使わない のいずれか
・発言の内容を言い換えないでください。話者が使った言葉をなるべく残してください
・文字起こしに書かれていない情報を足さないでください

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

この一覧が、あとの全工程の共通の土台になります。30〜60行くらい出てくるはずです。ここで「具体度：高」の行が5行未満なら、記事の前に追加取材を考えたほうが早いです。

工程2：企画を決める（記事の主張を1文にする）

あなたは編集長です。先ほどの発言一覧をもとに、この記事の企画を立ててください。

【前提】
・想定読者：（例：従業員300名規模のBtoBメーカーで採用広報を兼務している人）
・掲載媒体：（例：自社オウンドメディア）
・読者にとってのゴール：（例：自社でも同じ仕組みを作れそうだと思える）
・記事の長さ：（例：4000字程度）

【出力】
1. この記事が読者に持ち帰らせる主張を、1文で書いてください（40字以内・断定形）
2. その主張を支える発言IDを、一覧から5〜8個選んでください
3. 選ばなかった発言のうち、惜しいものを3つ挙げ、なぜ落としたか一言添えてください
4. 主張を支えるには情報が足りない箇所があれば、追加で聞くべき質問を3つ提案してください

主張は「〜が重要だ」「〜が求められている」のような誰でも言える形にしないでください。
この話者でなければ言えない内容にしてください。

3番目の「落とした理由」が効きます。判断の履歴が残るので、あとから戻せます。4番目は、この段階で情報の穴を発見するための保険です。

工程3：構成を作る（見出しに発言IDを割り当てる）

先ほど決めた主張と、選んだ発言IDをもとに、記事の構成案を作ってください。

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

【制約】
・見出しに「はじめに」「背景」「課題」「まとめ」「今後の展望」を使わないでください
・見出しは、それだけ読んで内容が想像できる具体的な文にしてください
・時系列順ではなく、読者が理解しやすい順に並べ替えてください
・各見出しに割り当てる発言IDが1つもない見出しは作らないでください

最後の制約が重要です。素材の裏付けが無い見出しを禁止すると、AIが場を埋めるために一般論を発明する余地が消えます。

工程4：本文を書く（セクション単位で。全文一括にしない）

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

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

【執筆ルール】
・話者の発言を引用するときは、フィラー（えー、あの、まあ）と言い直しの削除、
  語順の入れ替えまでは可。意味を足す・要約して言い換えるのは不可
・引用は「」で囲み、地の文と明確に分ける
・貼った発言に含まれない事実・数値・固有名詞を書かないでください
・一文の長さを揃えないでください。短い文と長い文を混ぜてください
・「〜ではないでしょうか」「〜と言えるでしょう」を使わないでください
・接続詞（また、さらに、加えて）は1セクションに2回までにしてください

セクションごとに区切る理由は2つあります。ひとつは、長い出力ほど後半の品質が落ちること。もうひとつは、部分的にやり直せることです。全文一括だと、1箇所直すために全部再生成することになります。

工程5：発言と照らし合わせる（ここを飛ばすと事故ります）

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

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

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

「拡張」と「不明」を必ず洗い出してください。1件も無い場合は、確認が甘い可能性があるため
もう一度厳しく見直してください。

「1件も無いなら見直せ」と書いておくのがコツです。これを入れないと、全部「一致」と返ってきます。出てきた「拡張」「不明」は、人が原文に戻って確認します。ここは自動化しないほうが安全な工程です。

工程6：整える（文体と表記）

以下の記事を、意味を変えずに推敲してください。

【直す対象】
1. 隣り合う3文の長さがほぼ同じ箇所 → 長短のリズムをつける
2. 抽象語で終わっている文（最適化、効率化、活性化、重要です、必要です）
   → 具体的な動作や状態に書き換える
3. 主語が大きい文（企業は、多くの人は、現代においては）→ 主語を具体的にする
4. 同じ語尾が3回以上続く箇所
5. 一文に2つ以上の主張が入っている箇所 → 分割する

【触らない対象】
・「」で囲まれた発言引用
・固有名詞、数値、日付

変更した箇所を、変更前 → 変更後 の形で一覧にしてから、全文を出力してください。

仕上げに人がやること（3箇所だけ）

全部を人が読み直すのは現実的ではありません。効果が大きい順に3箇所だけ手を入れます。

1. 冒頭2文：ここだけは自分で書く。読み進めるかどうかが決まる場所です
2. 見出し：AIの見出しは正確でも退屈になりがちです。話者の言葉から引くと一気に変わります
3. 締めの段落：まとめの反復になっていたら、読者への呼びかけか、話者の一言に差し替える

一問一答にするか、ルポにするか

同じ素材でも仕立てで読後感が変わります。判断の目安は次の通りです。

迷ったら、発言一覧の「具体エピソード」と「感情・本音」の行数を見てください。多ければ一問一答が生きます。少なければルポ形式で構成の力に頼るほうが読めるものになります。

インタビュー記事そのものの設計思想や質問づくりについては、インタビュー記事の作り方完全ガイドに企画から公開までの流れがまとまっています。取材前の準備から見直したいときはそちらが早いはずです。

---

4. それでも残る限界

ここまでの手順を踏めば、汎用LLMでも読める記事にはなります。ただ、実務で回し始めると別の壁に当たります。

手順を毎回、人が回す必要がある。 6工程それぞれでプロンプトを貼り、出力を確認し、次の工程に渡す。1本あたりのやりとりは20回を超えます。時間としては、下書きまで2〜3時間かかることも珍しくありません。ゼロから書くよりは速い。けれど「AIで自動化した」と言える状態ではありません。

コンテキストの長さに縛られる。 1時間の取材は文字起こしで2〜3万字になります。工程が進むほど、一覧・企画・構成・本文が積み上がり、最初に渡した原文が実質的に参照されなくなっていきます。分割すれば入りますが、分割した瞬間に全体を見た構成判断ができなくなります。

照合が目視から抜けられない。 工程5は「怪しい箇所を挙げさせる」ところまでしか自動化できません。最終的に原文に戻って確認するのは人です。ここを省略した記事を公開するのは、取材相手に対して危険です。

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

属人化する。 うまく回している人のプロンプトと判断基準は、その人の頭の中にあります。チームで共有しようとすると、手順書がプロンプト集になり、更新されなくなり、結局その人しか回せなくなる。オウンドメディアの運用が止まる典型的な形です。

そもそも素材の質は解決しない。 文字起こしの精度、話者の切り分け、取材の質問設計。これらはプロンプトの外側の問題です。

限界の正体は、能力ではなく工程の受け渡しが人の手作業で残っていることにあります。

---

5. 工程をエージェントに持たせるという選択肢

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

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

無料プランがあるので、手元の音源1本で出力を比べてみるのがいちばん早いと思います。この記事の手順を自分で回した結果と、並べて見てみてください。

• sonataを無料で試す

音声から記事にする工程を、どこまで自動化できてどこから人が要るのかについては、音声→記事自動生成の全工程でも整理されています。仕組みとして考えたい場合はあわせてどうぞ。