ChatGPTで記事を書くと「それっぽいだけ」になる理由と、工程を分ける書き方

1. 書き上がっているのに、公開できない

オウンドメディアの更新が止まりかけている。人手は増えない。ChatGPTに「〇〇について3000字の記事を書いて」と打ち込むと、数十秒で記事の形をしたテキストが返ってきます。

そこで手が止まります。

• 日本語として整っている。誤字もない。なのに読み終えて何も残らない
• どこも間違っていないのに、自社が出す理由のない記事になっている
• 見出しが「はじめに」「メリット」「デメリット」「導入のポイント」「まとめ」で埋まっている
• 具体例が「A社では」「ある企業では」ばかりで、実在の情報がひとつもない
• 上司にレビューを回すと「悪くないけど、これ他社サイトにも書いてあるよね」と返ってくる
• 直そうとしても、どの段落を直せばいいのか特定できず、結局書き直しになる

さらに厄介なのが、うまく書けた回があっても再現できないことです。担当者ごとに頼み方が違い、同じメディアなのに記事によって水準が変わる。誰かのやり方がうまくいっても、その人の頭の中にしかないので共有されません。

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

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

原因1：複数の判断を1回のプロンプトに畳んでいる

記事を1本書くとき、人は順番に別々の判断をしています。誰に向けるかを決める、何を持ち帰らせるかを決める、材料を集める、主張を1つに絞る、並び順を組む、書く、事実を確かめる、整える。少なくとも8つの独立した判断です。

「記事を書いて」という指示は、この8つを1回のやりとりに畳み込んでいます。畳むと、途中の判断が見えません。なぜその構成なのか、なぜその例なのかが出力から読み取れないので、部分的に直せない。だから毎回ゼロからやり直しになります。

原因2：材料が「検索結果の平均」しかない

材料を渡していない場合、参照されるのは学習データと、あっても検索で拾える公開情報だけです。競合他社も同じ情報源から書いています。結果として、上位記事の平均を再構成したものが返ってきます。

自社にしかない材料は、たいてい社外に公開されていません。営業が現場で受けている質問、導入企業の運用実態、サポートに届く問い合わせ、社内の失敗事例。これらを渡していない限り、独自性はどこからも湧いてきません。

原因3：読者が決まっていない

「〇〇について書いて」の〇〇はテーマです。テーマだけでは、どの前提知識を省いてよいかが決まりません。前提が決まらないと、全員に通じる書き方、つまり最大公約数の説明になります。読み手が誰でも成立する記事は、誰にも刺さりません。

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

評価軸がないと、出力は学習データの平均に収束します。「良い記事」の定義を渡さずに、良い記事が出てくることを期待している状態です。しかもこの基準は、社内でも言語化されていないことがほとんどです。レビューで「なんか違う」としか言えないのは、基準が言葉になっていないからです。

原因5：1つの会話に全部を積み上げている

同じチャットで企画から推敲まで進めると、前半で出した指示と後半で出した指示が混ざります。会話が長くなるほど、最初に渡した前提が薄れていく。後半で急に文体が崩れるのは、たいていこれです。

---

3. 汎用LLMでここまでやれる：8工程に分ける

ここからが本題です。工程を分け、それぞれに必要な材料と基準を渡せば、汎用LLMでも十分に読める記事になります。以下はそのまま使える形にしてあります。

工程0：会話の分け方を先に決める

作業に入る前に、運用のルールを決めておきます。これだけで出力が安定します。

• チャットを工程ごとに分ける。 企画用、構成用、執筆用、点検用。1本の記事で4本前後のチャットになります
• 各工程の出力をテキストとして保存する。 会話の履歴に頼らず、次の工程には保存した成果物を貼り直す
• 執筆はセクション単位にする。 全文を一括で書かせない
• 前提情報は毎回貼り直す。 「さっき伝えた読者像で」は通じないと考える

面倒に見えますが、やり直しの回数が減るので合計時間はむしろ短くなります。

工程1：読者を1人に絞る

これから記事を1本作ります。まず読者定義だけを行ってください。記事はまだ書かないでください。

【テーマ】（例：BtoBサイトの問い合わせが増えない原因）
【想定している読者層】（例：従業員200〜500名のBtoB企業で、Webサイトを1人で管理している担当者）
【この記事を置く場所】（例：自社オウンドメディア）

以下を出力してください。
1. 読者カード
   - 役職と担当範囲
   - 記事を読む直前に何をしていたか（どんな状況で検索したか）
   - すでに知っていること（説明不要な前提）を5つ
   - 知らない可能性が高いこと（説明が必要なこと）を5つ
   - 読んだあとに取る行動の候補を3つ
2. この読者が読み飛ばす見出しの特徴を3つ
3. この読者にとって、書いてあると価値が下がる内容を3つ

読者像を広げないでください。「幅広い担当者」のような表現は使わず、1人に絞ってください。

3番目の「書いてあると価値が下がる内容」が効きます。分かりきった定義説明や一般論を、この段階で禁止リストにできます。

工程2：検索意図を分解する

次に、読者がこのキーワードで検索したときに知りたいことを分解してください。

【キーワード】（例：btob 問い合わせ 増やす）
【読者カード】（工程1の出力を貼る）

以下を出力してください。
1. この検索の背後にある「解決したい状況」を3つ、具体的な場面として書く
2. 読者が知りたい問いを、優先度順に7つ（疑問文の形で）
3. そのうち、検索結果の上位に載っていそうな一般的な問いはどれか
4. 逆に、多くの記事が答えていないが読者は知りたい問いはどれか
5. この記事で答える問いを3つに絞り、答えない問いは「答えない」と明記する

答える問いを増やさないでください。7つ全部に答えると焦点のない記事になります。

4番と5番が記事の差別化を決めます。網羅すると平均に戻るので、答えない問いを先に決めるのが要点です。

工程3：社内の材料を棚卸しする

ここが独自性の分かれ目です。手元にある非公開の材料を、記事の素材に変換します。

以下は自社の内部資料です。この中から、記事で使える情報を抽出してください。
要約はせず、一覧にしてください。

【資料】
（営業の商談メモ、サポートへの問い合わせ一覧、導入企業へのヒアリング記録、
  社内勉強会の議事録、過去の失敗事例メモなどを貼る）

【出力形式】
| ID | 使える情報(50字以内) | 種別 | 具体度 | 公開可否の要確認点 |

・種別：数値 / 事実 / 現場の言葉 / 失敗例 / 手順 / 判断基準 / 顧客の疑問
・具体度：高（固有名詞・数値・時期が入る）/ 中 / 低
・「公開可否の要確認点」：社名・個人名・契約情報など、そのまま出せない箇所を必ず指摘する

【厳守】
・資料に書かれていない情報を推測で足さないでください
・言い換えず、資料の言葉をなるべく残してください

社外に出せない情報は、数字を丸める、業種だけ残す、といった加工で使えることが多いです。「公開可否の要確認点」を最初に出させておくと、この判断が後回しになりません。

工程4：主張を1文に決める

あなたは編集長です。この記事の主張を決めてください。

【読者カード】（貼る）
【答える問い3つ】（貼る）
【使える情報の一覧】（工程3の出力を貼る）

【出力】
1. この記事が読者に持ち帰らせる主張を1文で（40字以内・断定形）
2. その主張を支える情報IDを5〜8個
3. 主張に反する、または弱める情報が一覧の中にあれば指摘してください
4. 主張を支えるには足りない情報と、社内の誰に聞けば埋まるかの想定

【条件】
主張は「〜が重要だ」「〜が求められている」のような、どの会社でも言える形に
しないでください。自社の材料がなければ書けない内容にしてください。

3番目を必ず出させてください。都合の悪い情報を無視した記事は、詳しい読者にすぐ見抜かれます。

工程5：構成を3案出す

決定した主張と情報IDをもとに、構成案を3パターン作ってください。

【出力形式（各案）】
■ 並べ替えの軸（一言で。例：読者の疑問順 / 課題→打ち手順 / 反論を先に潰す順）
■ リード文で書くこと（箇条書き3点）
■ 見出し構成
  H2（1）：
    - この見出しで読者に渡すこと：
    - 使う情報ID：
    - 想定文字数：
  （H2を4〜6本）
■ 締めで書くこと

【条件】
・見出しに「はじめに」「背景」「メリット」「デメリット」「まとめ」「今後の展望」を使わない
・見出しは、それだけ読んで中身が想像できる具体的な文にする
・割り当てる情報IDが1つもない見出しを作らない
・想定文字数の合計を指定の長さに収め、重要な見出しに多く配分する

情報IDのない見出しを禁止するのが最大の効果です。この制約がないと、話をつなぐためにAIが一般論の見出しを発明します。中身のない段落が生まれる主要な入口はここです。

見出しの立て方そのものを整理したい場合は、AI時代の記事構成と執筆技術に考え方がまとまっています。

工程6：セクション単位で書く

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

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

【執筆ルール】
・貼った情報に含まれない事実・数値・固有名詞を書かない
・具体例を作る場合は「例：」と明示し、実在の事例のように書かない
・一文の長さを揃えない。短い文と長い文を混ぜる
・「〜ではないでしょうか」「〜と言えるでしょう」「〜が挙げられます」を使わない
・接続詞（また・さらに・加えて）はこのセクションで2回まで
・段落構成を「主張→理由→具体例→まとめ」で固定しない
・抽象語（効率化・最適化・活性化・強化）で文を終えない

一括で全文を書かせないでください。長い出力ほど後半で指示が守られなくなります。加えて、1箇所直すために全体を再生成する事態を避けられます。

工程7：事実を点検する

以下の記事本文について、事実の確認が必要な箇所を洗い出してください。

【出力形式】
| 該当箇所 | 記述の種類 | 出典の有無 | 確認方法 |

・記述の種類：数値 / 固有名詞 / 制度・法令 / 他社事例 / 一般に流通する通説 / 推論
・出典の有無：渡した資料にある / 資料にない / 不明
・確認方法：誰に聞くか、どこを見れば確認できるかを具体的に

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

最後の一文がないと、ほぼ全部「問題なし」で返ってきます。出てきた項目は人が確認します。ここは自動化しないほうが安全な工程です。

工程8：推敲とタイトル

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

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

【触らない対象】固有名詞、数値、日付、引用

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

そのうえで、タイトル案を5つ出してください。
・読者カードの人が検索窓に打ち込む語を含める
・「〜のポイント」「〜とは」「徹底解説」を使わない
・記事で実際に答えている内容だけをタイトルにする（本文にない約束をしない）

仕上げに人が触る3箇所

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

1. 冒頭2文。 読み進めるかどうかが決まる場所で、同時にAIが最も平均に寄る場所です
2. 見出し。 正確でも退屈になりがちです。工程3で拾った現場の言葉を混ぜると変わります
3. 締めの段落。 まとめの反復になっていたら、読者への具体的な提案に替えます

工程表を1枚にしておく

ここまでの8工程を、テンプレートとしてスプレッドシートに固定しておくと、担当者が変わっても手順が残ります。列は「工程名／入力／プロンプト／出力の保存先／人が判断する点／所要目安」の6つで足ります。属人化を防ぐ最低限の装置です。

---

4. それでも残る限界

この手順を踏めば、汎用LLMでも公開できる水準の記事になります。ただ、チームで継続的に回し始めると別の壁に当たります。

毎回、人が工程をつなぐ必要があります。 8工程それぞれでプロンプトを貼り、出力を確認し、保存し、次に貼り直す。1本あたりのやりとりは30回を超えます。書き上がるまで半日という感覚は、大きくは変わりません。

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

チームで揃いません。 工程表を共有しても、移るのは手順だけです。どの構成案を選ぶか、どこまで具体化するか、どの情報を落とすか。判断そのものは共有されません。結果として、記事ごとに水準が変わります。

担当者が変わると水準が落ちます。 うまく回している人のコツは、プロンプトの外側にあります。異動や退職で、そのメディアの品質が一段下がる。オウンドメディアが止まる典型的な形です。

材料集めは自動化できません。 工程3の社内資料の収集は、人が動いて集めるしかありません。ここが薄いと、後の工程をどれだけ丁寧にやっても一般論に戻ります。

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

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

---

5. 受け渡しを仕組みとして持つ

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

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

そして、同じ工程を全員が通ります。担当者が変わっても、出力の水準が個人の慣れに左右されにくくなります。工程表を配って守ってもらうのではなく、工程のほうを仕組みにするという考え方です。

無料で試せます。社内のヒアリング音源や商談の録音を1本入れて、この記事の手順を自分で回した結果と並べてみるのが、いちばん判断が早いと思います。

• sonataを無料で試す

まずは工程1の読者カードだけ作ってみてください。いま止まっている記事が、誰に向けたものだったのかがはっきりするはずです。