ChatGPTでブログ記事を書くプロンプト|設計書→下書き→校閲→修正の分け方【2026年版】

結論:プロンプトは「1回で書かせる」より「工程を分ける」

3行の答え

ブログ記事を生成AIで作るときは、設計書・下書き・校閲・修正の工程に分けて依頼すると失敗が減ります。

校閲は書いた本人とは別のAIや別のチャットで行い、事実確認は公開前に人が実施します。

この工程の分け方は、無料で使えるAIモデルを使った実際の作業で確認された方法です。

なぜ工程を分けるのか

一度の依頼で全文を書かせると、見出し構成が崩れたり、事実と異なる内容が混ざったり、文字数が大きく外れたりしやすくなります。

設計書の段階で「事実として書いてよいこと」と「書かないこと」を明確に線引きし、下書きでは見出しごとの文字数を指定し、校閲では別のAIに客観的な視点で指摘させ、修正では指摘を1つずつ確実に反映させる。この順序で進めると、各段階で何が起きたかを後から確認でき、手戻りも最小限で済みます。

実際の作業でも、最初の下書きは約4,500字で目安より短い節がありましたが、「足りない見出しだけを指名して書き足させる」と依頼すると、約5,200字で概ね設計書通りの分量になりました。

工程の流れ

以下の表は、記事作成の工程を整理したものです。

設計書で「事実として書いてよいこと」を自社の一次情報に限定し、人の確認を入れることで、他サイトと重複しない独自の記事になります。

工程1 設計書をつくるプロンプト

渡す情報:読者・目的・見出し・字数・文体

設計書は、AIに「この記事をどう書いてほしいか」を伝えるための指示書です。

役割、読者像、記事の目的、H2/H3の見出し構成、各見出しの目安文字数、文体(です/ます等)、出力形式(HTMLやMarkdown等)を網羅的に記述します。

これらをまとめて渡すことで、AIの出力が意図からズレるリスクを下げられます。

「事実として書いてよいこと」「書かないこと」を先に決める

設計書の中で特に重要なのが、書いてよい事実と書かないことの線引きです。

「書いてよいこと」には、公式情報に基づく説明、一般的な知識として確認できる事項、一次情報として持っているデータなどを列挙します。

「書かないこと」には、根拠のない数字や体験談の創作、「稼げる」といった断定的な収益表現、未確認のモデル名や料金、他社の実績やプロンプトの引用などを明記します。

この区別を設計書に入れておくと、下書き工程で「作り話」が混入するのを防げます。

プロンプト例

以下は、設計書を作成するためのプロンプト例です。コピペして内容を書き換えてお使いください。

役割: あなたはSEO記事の設計書を作る専門家です。

読者: ブログで集客したい個人事業主・アフィリエイター初心者。ChatGPTを使って記事を書こうとしているが、プロンプトの書き方が分からない。

目的: 「工程を分けて依頼する」という具体的な手順と、各工程で使えるプロンプト例を提供し、読者がすぐに試せるようにする。

以下の情報をもとに、記事の設計書を作成してください。

【見出し構成と目安文字数】
H2: 結論(450字) / H2: 工程1 設計書(800字) / H2: 工程2 下書き(650字) / H2: 工程3 校閲(800字) / H2: 工程4 修正・事実確認(800字) / H2: 実際の作業で分かったこと(700字) / H2: Googleの考え方(550字) / H2: FAQ(550字)

【文体】
- 文末は「です/ます」統一
- 「なのです/のです」とダッシュ記号(── ― — –)は使わない
- 1文ごとに改行(pタグ相当)

【事実として書いてよいこと】
- 公式ドキュメントや一次情報に基づく説明
- 「設計書を先に作る」「別のAIで校閲する」といった作業手順

【書かないこと】
- AIで書いた記事が上位になる/ならないという断定
- 収益の具体的な数字や「月〇万円」などの実績
- ChatGPTのモデル名・料金・無料枠などの仕様(公式で確認できていないため)
- 実際に使ったツール名(「無料で使えるAIモデル」と書く)
- 他社記事のプロンプト引用、法令の細かい解釈

【出力形式】HTMLの見出しタグと段落タグのみ。余計な説明は不要。タグは<h2><h3><p>を適切に使う。テーブルはHTMLで出力。---

このプロンプトを入力すると、記事作成の設計書がH2/H3構造で出力されます。

実際の作業では、この設計書を一度人間が確認し、見出しの順序や抜けがないかを見てから下書き工程に進めました。

確認のポイントは主に3つです。1つ目は、H2の並びが読者の知りたい順序になっているかです。検索意図に合わせて「結論→具体的な手順(工程1〜4)→実績・気づき→Googleの考え方→FAQ」という流れになっているか、論理的に納得できる順序かを見ます。2つ目は、各H2の下に必要なH3が揃っているかです。例えば「工程1」なら「渡す情報」と「事実の線引き」の2つ、「工程2」なら「見出しごとの字数指定」「数字や体験談を作らない」「長い記事の分割」の3つがそれぞれ入っているかを確認します。3つ目は、設計書内の「事実として書いてよいこと」「書かないこと」のリストが、今回の記事テーマに合わせて具体的になっているかです。汎用的な文言のままになっていないか、自社の一次情報や公式出典に限定できているかをチェックします。

この確認を省くと、下書き工程で見出しの順序がおかしくなったり、必要なH3が抜けたり、「書かないこと」が機能しなかったりして、後工程での手戻りが大きくなります。設計書は「書き始める前の最後の関門」として、ここでしっかり整えておくことが全体の工数を減らす鍵になります。

工程2 下書きを書かせるプロンプト

見出しごとに字数を指定する

設計書が出来たら、それをそのままAIに渡して下書きを書かせます。

このとき「全体で5,000字」という指示だけでは、AIが文字数を守れないことがあります。

実際の作業でも、全体の文字数だけを指定した最初の下書きは約4,500字で、2つの節が目安より短いという結果でした。

「H2ごとに目安文字数を守る」「足りないH3だけを指名して書き足させる」と明記すると、意図した分量になりやすくなります。

数字や体験談を作らせない

下書きプロンプトには、設計書の「書かないこと」をそのままコピペして「以下を絶対に書かない」と指示します。

特に「数字を勝手に足さない」「体験談や口コミを作らない」「『稼ぐ』などの断定をしない」の3点は、ハルシネーション(もっともらしい嘘)を減らすために必須です。

「公式で確認できていない情報は『確認されていません』と書く」と指示しておくと、後から事実確認する際の目印になります。

長い記事は分けて頼む

記事が長い場合、一度の応答で全文を出力させると途中で切れたり質が落ちたりします。

「H2を2つずつに分けて出力する」「前半・後半でチャットを分ける」など、出力の分割を設計段階で決めておくと安定します。

無料で使えるAIモデルの中には、長文出力の途中で止まるものや、文脈を保ったまま続きを書くのが苦手なものがあります。

分割して依頼すれば、各パーツの質を確認しながら進められます。

プロンプト例(下書き用):

役割: SEOライター。設計書に従い、記事の下書きを書く。

入力: 設計書(前工程の出力全文)

指示:
1. 見出しごとの目安文字数を守ること。全体の文字数だけでなく、各H2/H3の分量を意識すること。
2. 「書かないこと」リストを厳守すること。数字・体験談・収益断定・未確認モデル名・他社プロンプト引用を出さないこと。未確認なら「公式で確認されていません」と書くこと。
3. 出力はHTMLの<h2><h3><p>タグのみ。テーブルは<table>で。装飾クラスは付けない(後工程で整える)。
4. 出力が長い場合は「H2:○○まで」と区切りを指定して続きを依頼すること。---

このプロンプトで最初の下書きが出たら、文字数を確認し、足りない見出しだけを指名して「H3:○○をあと300字書き足して」と依頼します。

文字数の確認は、AI自身に数えさせるとタグや空白の扱いで数値がブレて迷走するため、人間側で行うのが確実です。実際の作業では、HTMLタグを除いたテキスト文字数をスクリプトで計測し、設計書の目安と比較しました。全体の文字数だけでなく、各H2/H3ごとの分量が目安から大きく外れていないかをチェックします。不足している見出しがあれば、その見出しだけを具体的に指名して「H3:○○をあと300字書き足して」「H2:○○の2段落目を150字程度追加して」という形で追加を依頼し、再計測して完了とします。

長い記事の場合、一度の応答で全文を出力させると途中で切れたり、後半の質が落ちたりすることがあります。無料で使えるAIモデルの中には、長文出力の途中で止まるものや、文脈を保ったまま続きを書くのが苦手なものがあるためです。設計段階で「H2を2つずつに分けて出力する」「前半・後半でチャットを分ける」といった分割ルールを決めておくと、各パーツの質を確認しながら安定して進められます。分割して依頼する場合も、各パートごとに文字数を確認し、設計書の目安と照らし合わせながら調整します。

下書きが完成したら、そのまま校閲工程に進まず、一度人間がざっと目を通して「明らかな事実誤認」「設計書の『書かないこと』に抵触する記述」「文体ルール違反」がないかを確認しておくと、校閲役のAIへの負荷が下がり、指摘の精度も上がります。この「人の事前チェック」はわずか数分で済みますが、後工程の手戻りを大きく減らせます。

工程3 別のAIで校閲するプロンプト

書いた本人とは別のモデルか別のチャットで見る理由

下書きが出来たら、それを書いたAI自身に「これでいいか」と聞くのは避けたほうが無難です。

同じモデル・同じチャットだと、自分が書いた文章を肯定しやすく、指摘が出にくい傾向があります。

実際の作業でも、最初に校閲役としたモデルは応答に長い時間がかかり、指摘が出ませんでした。

別のモデルに替えると約3分で終了し、的確な指摘が3件出ました。

「速いモデルでも、何往復もする作業では極端に遅くなることがある」ため、役割を固定せず実際の作業で試すのが確実です。

校閲の依頼文例:根拠のない解釈・設計書にない記述・言い切りすぎをさがす

校閲役のAIには、設計書と下書きの両方を渡し、以下の観点で指摘させます。

プロンプト例(校閲用):

役割: 編集者兼ファクトチェッカー。以下の設計書と下書きを比較し、問題点を指摘する。

【設計書】(ここに設計書全文を貼る)
【下書き】(ここに下書き全文を貼る)

以下の3点を中心に、修正が必要な箇所を具体的に指摘してください。指摘は「場所(見出し)・問題・修正案」の形式で出力すること。
1. 根拠のない解釈・数字・固有名詞・日付が含まれていないか(ハルシネーション)
2. 設計書の「書かないこと」に該当する記述がないか(体験談の創作、断定、未確認情報の記載)
3. 法令・公式見解の説明で「言い切りすぎ」になっていないか(「違法です」「問題ありません」等の断定)
4. 文体ルール違反(「です/ます」以外、ダッシュ記号の使用)
5. 文字数が見出しごとの目安から大きく外れていないか

出力は箇条書きのみ。良かった点の評価は不要。---

この依頼文を使った実際の作業では、次の3つの指摘が出ました。

実際の校閲で出た指摘の種類(3件)

1つ目は、本文に数字の試算がないのに、免責文に「数値や試算は仮の例」と書いてあったことです。本文に該当する数値や試算が存在しないにもかかわらず、免責だけが記載されていました。

2つ目は、設計書にない独自の解釈(報酬の未払いについての説明)が足されていたことです。設計書で指定されていない内容が、記事中に独自の解釈として書き込まれていました。

3つ目は、免責の文が、設計書で決めた場所と違う節に置かれていたことです。免責事項を記載すべき指定の節ではなく、別の節に配置されていました。

これらの指摘はすべて設計書のルールに照らせば明確な違反であり、修正工程で反映されました。

校閲役のAIによっては「全体的に良くできています」という総評しか出ないことがあるため、指示を厳しく「指摘がゼロなら『指摘なし』と出力せよ」と付け足すと実用的です。

工程4 修正と、人が行う事実確認

指摘を1つずつ直させる

校閲で出た指摘は、まとめて「全部直して」と依頼せず、一つずつ指定して修正させます。

「指摘1のH2:○○の2段落目を、修正案の通りに書き換えて」という形で個別に依頼すると、他の部分を壊さずに直せます。

まとめて依頼すると、直っていない指摘が残ったり、無関係な部分まで書き換わったりするためです。

実際の作業では、3件の指摘を順番に依頼し、それぞれ修正後の文章を確認して次に進みました。

人が確かめること:数字・法律・固有名詞・公式の出典

AIの修正が終わっても、公開前の最終確認は人が行います。

特に以下の項目は、AIの判断だけで公開しないようにしてください。

数字: 報告書や統計の引用元があるか、計算が合っているか、単位に誤りがないか。

法律: 法令名・条文・施行日が正確か、解釈に公式見解(ガイドライン等)があるか。

固有名詞: モデル名・サービス名・企業名・URL・料金が最新かつ正確か。

公式の出典: 「Googleは〜と考えている」という記述の出典が検索セントラル等の公式ドキュメントか。

実際の作業では、AIが「公式で確認されていません」と書いた部分を中心に、人間が公式サイトを開いて裏取りをしました。

文字数は人かスクリプトで数える

AI自身に文字数を数えさせると、タグや空白の扱いで数値がブレて迷走しました。

実際の作業では、HTMLタグを除いたテキスト文字数をスクリプトで計測し、設計書の目安と比較しました。

不足している見出しがあれば、その見出しだけを指名して「あと○○字書き足す」と依頼し、再計測して完了としました。

メタ情報(title、meta description、og:imageのalt等)も記事本文と同じ基準で、設計書のルール(文体、ダッシュ不使用、数字の確認等)に沿っているかを確認します。

実際にやって分かったこと

作業記録の概要

このサイトで実際に行った作業は、2026年11月14日に無料で使えるAIモデルを用いてSEO記事を作成したものです。

ChatGPTで作業を行ったわけではありませんが、「工程を分ける」「設計書を使う」「別のAIで校閲する」といった考え方はChatGPTにも適用できます。

作業工程は、設計(ライバル調査と法令の公式確認は人が実施)→下書き→校閲→修正→推敲→校閲やり直し→修正→最終確認の順でした。

工程ごとの所要時間と出力

下書き工程では、最初の出力で本文約4,500字が約4分で生成されました。

設計書の目安より2つの節が短かったため、書き足しを依頼し、約5,200字になりました。

校閲工程では、最初に指名したモデルは応答に時間がかかり指摘が出ませんでした。

別のモデルに切り替えると約3分で完了し、的確な指摘が3件(本文にない試算の免責、設計書にない独自解釈、免責の位置違い)出ました。

修正工程では、3件の指摘すべてが反映されました。

気づき:速さより「何往復しても止まらないか」を試す

「応答が速いモデルを校閲役にする」と決めつけると、長い文章を何度もやり取りする工程で極端に遅くなることがあります。

実際に設計書・下書き・校閲・修正のサイクルを回してみて、安定して応答が返ってくるモデルを役割ごとに選ぶのが確実です。

文字数カウントはAIに任せると迷走しました。見出しごとに字数を指定し、足りない節だけを具体的に指示して、カウントは人間側(またはスクリプト)で行うと正確です。

各工程のあとに本文の写しを残すと、「どの工程で何が変わったか」を後から比較でき、ノウハウとして蓄積できます。

無料で使えるAIモデルでも、工程を分けて役割を固定すれば、実用的な記事を作れることが分かりました。

Googleの考え方とAIで書くときの注意

AIの利用そのものは問題とされていない

Google検索セントラルの「生成AIコンテンツに関するガイダンス」では、生成AIの利用自体は問題とされていません(確認日: 2026年11月14日。文書は更新が続いています)。

リサーチや構成づくり、原稿作成の補助としてAIを活用することは、有用な手段の一つとして認められています。

したがって、「AIを使ったから順位が下がる」といった懸念は、Googleの公式な位置付けとは異なります。

価値のないページの大量生成は避ける

問題とされるのは、「付加価値のないページを大量に生成すること」です。これはスパムポリシーにおける「大規模なコンテンツの乱用」に抵触するおそれがあるとされています。

工程を分けて人の確認を入れ、読者にとって新しい情報や独自の整理がある記事を作ることは、このポリシーへの対策になります。

大量生成を目的とせず、一本一本を人の目で確かめて公開する運用であれば、AI活用自体はマイナス要因になりません。

公開前の人の確認、メタ情報も同じ基準で

生成AIは事実を調べているのではなく、学習したデータに基づいて単語の並びを予測するため、誤りを含むことがあります。

公開前に人がファクトチェックとレビューを行うことが重要とされています。

タイトル、メタディスクリプション、画像の代替テキストなどのメタ情報も、記事本文と同じ基準で確認する必要があります。

作り方の開示(「この記事はAIを使用して作成しました」等)は「検討する」ことが推奨されていますが、義務としては書かれていません。

この記事では、AIで生成した原案を人が設計・確認・修正したことを前提としていますが、記事内では工程の説明として位置づけています。

Googleの考え方は、Google検索セントラル「生成AIコンテンツに関するガイダンス」に基づき、2026年11月14日時点での確認内容を要約したものです。順位への影響については断定していません。

よくある質問と次の一歩

無料版のChatGPTでも使えますか？

無料で使えるAIモデルでも、工程を分けて役割を固定すれば設計書から下書き・校閲まで一通りの作業が可能です(実際の作業で確認済み)。

ただし、モデルごとに得意・不得意があるため、校閲役は実際に試して安定するものを選んでください。

ChatGPTの無料枠やモデル仕様については、OpenAIの公式ページで最新情報をご確認ください。

AIくさい文章を直すコツは？

「です/ます」統一、「なのです/のです」とダッシュ記号の禁止、一文ごとの改行といった文体ルールを設計書に入れておくと、かなり自然になります。

校閲工程で「文体ルール違反」をチェック項目に入れ、AIに指摘させると効率的です。

どうしても気になる場合は、最終工程で人間が声に出して読み、違和感のある語尾や接続を整えてください。

機密情報や個人情報は入れていいですか？

生成AIの利用規約やプライバシーポリシーにより異なりますが、一般的な注意として「入力した情報が学習データに使われる可能性があるため、機密情報や個人情報は入れない」という方針で運用することをおすすめします。

記事に必要な情報は、一般公開されているデータや自身のノウハウを整理したものにとどめ、入力前に確認してください。

記事を書いたあとは何をすればいいですか？

記事を公開したら、読者をリスト(メールやLINE)に登録してもらう導線を用意します。

本サイトでは、リストマーケティングの全体像を学べる「AIブログ記事作成」の無料講座を用意しています。興味がある方はこちらの記事から概要をご覧いただけます。

コンテンツ販売やローンチの流れを学びたい方は、コンテンツ販売・ローンチの始め方も参照してください。

リードマグネットの作り方については、リードマグネットの作り方をご覧ください。

コピーライティングの基礎を固めたい方は、コピーライティングの基本も参考になります。

AIで書いた記事がコピーコンテンツ扱いされませんか？

設計書で「事実として書いてよいこと」を自社の一次情報に限定し、人の確認を入れることで、他サイトと重複しない独自の記事になります。工程を分けて人の目で確かめるプロセス自体が、独自性を担保する仕組みになっています。

無料講座のご案内

インフォマーケティング研究所では、リストマーケティングやAIを活用した情報発信の基礎を体系的に学べる無料講座を提供しています。

まずは基本から学びたい方は、下のボタンからご登録ください。