記事作成プロンプト集｜そのまま使える12本と、プロンプトでは解けない問題

1. プロンプトを配ったのに、記事の質が揃わない

うまく書けたときのプロンプトをドキュメントにまとめて、チームに共有した。それでも、こういう状態になっていないでしょうか。

• 同じプロンプトを使っているのに、担当者によって出てくる記事の水準が違う
• ドキュメントが更新されず、半年前のプロンプトが残ったままになっている
• 使う人が「どの場面でどれを使うか」を判断できず、結局いつも同じ1本しか使われない
• 変数の部分が埋められないまま実行されていて、読者像が空欄のまま記事が出ている
• レビューで指摘した内容が、次の記事に反映されない
• 新しく入った担当者に説明しようとすると、口頭の補足が10分必要になる

プロンプト集そのものが悪いわけではありません。プロンプトは工程の手順書であって、判断の基準ではない。この差が埋まらない限り、共有しても品質は揃いません。

とはいえ、手順が言葉になっていないと議論のしようもありません。まず、そのまま使える12本を全部出します。そのうえで、プロンプトでは解けない部分を最後に整理します。

2. なぜプロンプトだけでは足りないのか

手順は移るが、判断は移らない

「構成案を3つ出す」プロンプトを共有すれば、誰でも3案を出せます。ただ、3案からどれを選ぶかは共有されません。選ぶ基準はレビュー担当の頭の中にあり、本人も言語化していないことが多い。品質のばらつきは、ほぼここから生まれます。

変数が埋まらない

多くのプロンプトには、読者像、媒体、記事の目的、文字数といった変数があります。埋めるのが面倒なので、空欄のまま、あるいは「BtoB企業の担当者」のような広い記述で実行される。広い変数を入れれば、広い記事が返ってきます。

順番が決まっていない

12本あっても、どの順で使うかが決まっていないと、人によって使う本数も順序も変わります。企画を飛ばして執筆から入る人がいれば、全部を1本のチャットで済ませる人もいる。同じ道具を使っていても、通る工程が違えば結果は揃いません。

更新の担当がいない

プロンプトは記事を出すたびに改善点が見つかります。ただ、更新する担当が決まっていないと誰も直しません。使われないドキュメントになり、各自が自分の手元で改造したものを使い始めます。

---

3. そのまま使える12本

使い方の前提

12本は工程順に並んでいます。頭から順に使う前提で、各プロンプトの先頭に共通変数ブロックを貼り付けて実行してください。共通変数はこの形で1度作れば、記事ごとに使い回せます。

【共通変数】
・想定読者：（役職／担当範囲／会社規模まで書く。例：従業員300名のBtoBメーカーで
  採用広報を1人で担当している人）
・読者の状況：（何に困って検索したか）
・媒体：（例：自社オウンドメディア／採用サイト）
・記事の目的：（読み終えた読者にどうなってほしいか）
・文字数：（例：4000字）
・使ってはいけない表現：（自社のNGワード。例：業界No.1、絶対に、確実に）
・文体：（例：です・ます調、一人称なし、断定を避けすぎない）

【企画】1. 社内の材料から記事ネタを出す

【共通変数】（貼る）

以下は自社の内部資料です。ここから記事ネタを20本出してください。

【資料】（商談メモ／問い合わせ一覧／サポートのFAQ／社内勉強会の議事録などを貼る）

【出力形式】
| No | 記事案タイトル | 元になった資料の箇所 | 読者の問い | 自社でしか書けない度(高/中/低) |

【条件】
・資料に書かれていないネタを創作しないでください
・「自社でしか書けない度」が「低」のものは、なぜ低いか一言添えてください
・20本のうち、資料の同じ箇所から作ったものは3本までにしてください

【企画】2. 上位記事との差分を設計する

【共通変数】（貼る）
【キーワード】（例：採用広報 始め方）

このキーワードで検索する読者について、以下を出力してください。

1. 一般的な解説記事が必ず書いている内容を7つ
2. そのうち、読者がすでに知っている可能性が高いものはどれか
3. 一般的な記事が触れていないが、読者が実務で必ずぶつかる論点を5つ
4. 3のうち、自社の資料で裏付けが取れるものはどれか
5. この記事で扱わないと決める論点（あえて捨てるもの）を3つ

【条件】
1で挙げた内容を全部書く構成にしないでください。網羅すると差分が消えます。

【企画】3. 読者の反論を先に洗い出す

【共通変数】（貼る）
【この記事の主張】（1文で貼る）

この主張に対して、想定読者が抱く反論・疑い・言い訳を10個挙げてください。

【出力形式】
| No | 反論の内容 | 反論が出る理由 | 記事内で答えるか(答える/触れない) | 答えるなら必要な材料 |

【条件】
・「そんなことはない」で終わる弱い反論ではなく、実務上もっともな反論を優先してください
・自社に不利な反論を省かないでください
・「答えない」と判断したものには、その理由を一言添えてください

反論を先に潰しておくと、記事の説得力が変わります。答えない反論を明示するのも重要で、これがあると記事が長くなりすぎません。

【設計】4. 作った構成の穴を指摘させる

構成を生成させるより、自分で作った構成をレビューさせるほうが精度が出ます。

【共通変数】（貼る）
【構成案】（見出しと各見出しの要旨を貼る）

この構成をレビューしてください。書き直しはしないでください。

1. 読者が読み飛ばす可能性が高い見出しと、その理由
2. 論理が飛んでいる箇所（前の見出しから次の見出しへの接続が不自然な場所）
3. 中身が重複している見出しの組み合わせ
4. 見出しだけ読んで内容が想像できない見出し
5. 材料がなくても書けてしまう見出し（＝一般論で埋まるリスクがある見出し）
6. この構成で答えていない、読者が当然抱く疑問

最後に、削るとしたらどの見出しかを1つ挙げ、理由を書いてください。

5番が効きます。材料なしで書ける見出しは、そのまま放置すると必ず一般論の段落になります。

【設計】5. 見出しを具体的な文に直す

【共通変数】（貼る）
【現在の見出し一覧】（貼る）

各見出しを、より具体的な文に書き換えてください。

【ルール】
・「〜とは」「〜のポイント」「〜の重要性」「〜のメリット」「まとめ」を使わない
・見出しだけ読んで、その節で何が分かるかが伝わる文にする
・本文にない内容を見出しで約束しない
・体言止めと文の混在は可。全部を同じ形に揃えない

【出力形式】
| 変更前 | 変更後 | 変更の意図 |

各見出しについて、書き換え案を2つずつ出してください。

【設計】6. リード文を方向性違いで3案出す

【共通変数】（貼る）
【構成】（貼る）

リード文を3案書いてください。各案300字前後。

案1：読者が直面している具体的な場面の描写から入る
案2：多くの人が前提にしていることを一度否定するところから入る
案3：この記事で答える問いを提示するところから入る

【条件】
・「近年」「昨今」「〜が注目されています」で始めない
・記事で答えていないことを約束しない
・3案それぞれについて、どんな読者に効きやすいかを一言添えてください

【執筆】7. 1セクションを書き出し違いで書かせる

【共通変数】（貼る）

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

【対象見出し】（貼る）
【使う材料】（該当する事実・数値・発言の原文を貼る）
【文字数】700字前後

書き出しのパターンを変えて2案書いてください。
案A：具体的な事実や数値から入る
案B：読者がやりがちな行動の描写から入る

【執筆ルール】
・貼った材料に含まれない事実・数値・固有名詞を書かない
・一文の長さを揃えない。短い文と長い文を混ぜる
・「〜ではないでしょうか」「〜と言えるでしょう」「〜が挙げられます」を使わない
・接続詞（また・さらに・加えて）はこのセクションで2回まで
・抽象語（効率化・最適化・活性化・強化）で文を終えない

【執筆】8. 抽象的な文を具体に書き換える

【対象の文章】（貼る）

抽象的で映像が浮かばない文を特定し、書き換えてください。

【対象になる文】
・「効率化」「最適化」「活性化」「強化」「向上」で終わる文
・主語が大きい文（企業は／多くの担当者は／現代では）
・「しっかり」「きちんと」「適切に」が入っている文

【書き換えのルール】
「誰が」「何を」「どうなるか」の3点が入った記述にしてください。

【最重要】
具体化のために、元の文章にない数字や事実を創作しないでください。
情報が足りず具体化できない箇所は、書き換えずに
「【要情報】具体化に必要な情報が不足」と注記してください。

最後の指定を必ず入れてください。これがないと、具体化のために数値を発明します。実務ではこれが最も危険な挙動です。

【執筆】9. たとえと図解案を出す

【対象のセクション】（貼る）

このセクションの理解を助ける補助表現を出してください。

1. たとえ話を3案（各2文以内）
   ・専門知識がない人にも通じるものにする
   ・比喩が事実だと誤読される表現は避ける
2. 図解にするなら何を図にするかを3案
   ・図のタイトルと、含める要素だけを出す（作図はしない）
3. 表にできる箇所があれば、表の列構成を提案する

【条件】
たとえ話が本文の主張を超えないようにしてください。
比喩で説明を盛らないでください。

【検証】10. 事実の危険度を分類する

【記事本文】（貼る）
【渡した材料】（貼る）

本文の記述を検証し、事実確認が必要な箇所を分類してください。

【出力形式】
| 該当箇所 | 種類 | 材料での裏付け | 危険度 | 確認方法 |

・種類：数値 / 固有名詞 / 制度・法令 / 他社事例 / 通説 / 推論 / 断定表現
・裏付け：材料にある / 材料にない / 不明
・危険度：高（誤っていると信用を損なう）/ 中 / 低
・確認方法：誰に聞くか、どの資料を見れば確認できるかを具体的に

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

【検証】11. 既存記事の文体に揃える

【文体サンプル】（自社の既存記事を2〜3本、合計3000字ぶん貼る）

まず、このサンプルから次の特徴を抽出して箇条書きで出力してください。
記事の書き換えはまだしないでください。

・一文の平均的な長さと、長短のばらつき方
・段落の長さ
・漢字とひらがなの使い分け（例：出来る/できる、事/こと、様々/さまざま）
・語尾のバリエーションと混ぜ方
・読者への距離感（断定するか、余白を残すか）
・サンプルに一度も出てこない語（＝使わない語）

抽出結果を確認したうえで、対象の記事を書き換えてもらいます。

抽出した特徴リストは保存して使い回せます。毎回サンプル全文を貼らなくても、リストを渡すだけで近い結果になります。文体をチームで揃える考え方は、AIコンテンツのトーン統一術に整理されています。

【検証】12. 公開前セルフレビュー

【共通変数】（貼る）
【記事本文】（貼る）

この記事を10項目で採点してください。各項目5点満点、根拠を必ず添えてください。

1. 想定読者が最初の3行で「自分向けだ」と分かるか
2. 記事の主張が1文で言えるか（言えるなら書き出す）
3. 主張を支える具体的な材料（数値・事実・現場の言葉）が3つ以上あるか
4. 一般論だけで構成されている段落がないか
5. 見出しだけ読んで記事の流れが分かるか
6. 読者の当然の反論に答えているか
7. 事実確認が必要な記述に未確認のものが残っていないか
8. 本文にない内容をタイトルやリードで約束していないか
9. 抽象語で終わる文が全体の1割を超えていないか
10. 読み終えた読者が次に取れる行動が書かれているか

最後に、公開前に必ず直すべき箇所を3つだけ挙げてください。
「全体的に」ではなく、行を特定して指摘してください。

プロンプトを組織の資産にする3つの操作

12本を配るだけでは、冒頭の状態は変わりません。次の3つをセットにしてください。

変数を先頭に固定する。 すべてのプロンプトの冒頭に共通変数ブロックを置き、記事ごとにそこだけ埋める運用にします。変数が空欄のプロンプトは実行しない、をルールにするだけで出力の幅が狭まります。

台帳を作る。 スプレッドシートに、工程／プロンプト名／入力／出力の保存先／人が判断する点／最終更新日／更新担当、の7列で並べます。更新担当が空欄の行は、いずれ使われなくなります。

基準をプロンプトの外に置く。 「どの構成案を選ぶか」「どこまで具体化すれば合格か」は、プロンプトではなく判断基準シートに書きます。合格例と不合格例を実際の記事から2本ずつ貼るのが、いちばん早く伝わります。

プロンプト設計そのものの考え方を体系的に押さえたい場合は、コンテンツ制作のプロンプトエンジニアリングもあわせてどうぞ。

---

4. プロンプトでは解けない問題

12本を運用に載せると、記事は確実に安定します。それでも残るものがあります。

選ぶ判断が移りません。 構成案が3つ出ても、選ぶのは人です。選択の基準を文書にしても、実際の記事に当てはめる感覚までは移らない。ここがレビュー担当に集中し続けます。

工程をつなぐ手間は減りません。 12本を順に使うと、貼り付けと保存だけで1本あたり30回前後のやりとりになります。プロンプトが増えるほど、つなぐ作業も増えます。

出力が毎回ぶれます。 同じプロンプト、同じ変数でも結果は変わります。良い日と、作り直す日がある。締切のある運用では、この揺れがそのまま工数の揺れになります。

台帳が古びます。 モデルが更新されると、効いていた指定が効かなくなることがあります。12本の保守は、記事を作る作業とは別に発生し続けます。

材料の質は解決しません。 プロンプト1で社内資料から20本出しても、資料が薄ければ薄いネタしか出ません。材料集めはプロンプトの外側の作業です。

要するに、プロンプト集は工程の手順を配れても、工程そのものを組織に定着させることはできないということです。

---

5. 手順ではなく、工程を仕組みにする

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

プロンプトを配って各自に守ってもらうのではなく、工程のほうが固定されている状態になります。誰が使っても同じ順番を通るので、担当者が変わっても記事の水準が個人の慣れに左右されにくくなります。

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

無料で試せます。手元の商談録音や社内ヒアリングの音源を1本入れて、この12本を自分で回した結果と並べてみてください。

• sonataを無料で試す

まずはプロンプト12番のセルフレビューを、直近に公開した自社記事にかけてみるのが早いと思います。10項目のうちどこが落ちるかで、いま補うべき工程が見えてきます。