AIにブログ記事を書かせるとき、プロンプトは長いほど精度が上がるのでしょうか。
今回、生成AIで使うことを想定し、競合調査からWordPress・SWELLの入稿設計までを含むマスタープロンプトを作りました。最初は「記事作成に必要な指示を一つへ集めればよい」と考えていましたが、設計を進めるほど、重要なのは長さではなく途中で止まれる工程だと分かりました。
この記事で分かる3つの設計原則
- 情報が足りなければ、質問だけを返す
- 調査できなければ、断定原稿を出さない
- 完成本文と編集メモを分け、公開操作は別の許可で行う
この記事では、実際に作成した2つのプロンプトファイルと設計監査の記録から、AIへ文章ではなく編集工程を渡す方法を整理します。
なお、2026年8月20日時点では生成AI上の実行検証はまだ行っていません。この記事はプロンプトの設計記録であり、生成AIの出力品質や作業時間を評価するレビューではありません。
作成した2つのプロンプトと現在の検証範囲
今回作成したのは、媒体をまたぐ初版と、WordPress・SWELLへ絞ったブログ特化版です。
| ファイル | 規模 | 対象 |
|---|---|---|
| 独自性マスタープロンプト | 402行・約8,500文字 | WordPressとnote |
| ブログ特化マスタープロンプト | 149行・約5,300文字 | WordPress・SWELL |
文字数と行数は、2026年8月20日に手元のMarkdownファイルを数えた結果です。文字数は末尾改行の数え方で1文字前後変わるため、百文字単位へ丸めています。ブログ特化版は、note向けの分岐を外し、記事タイプ、装飾密度、サイト設定、最終出力をWordPress用へまとめ直したため短くなりました。
確認できたことと、まだ確認していないことは分けています。
| 確認済み | 未確認 |
|---|---|
| 2つのプロンプトファイルを作成した | 生成AIがすべての指示へ従うか |
| 競合調査、一次情報質問、停止条件を記述した | 生成AI上の文章品質 |
| SWELL装飾とSEO設定を本文から分けた | WordPress投稿まで一貫して実行できるか |
| 16項目の投稿パッケージを定義した | 所要時間や修正回数が減るか |
「作った」ことと「使って効果が出た」ことは同じではありません。未検証の部分は、今後の実行結果を追記する前提で残します。
なぜ「ブログ記事を書いて」だけでは足りないのか
記事作成プロンプトの競合調査では、検索競合ブログ5件と、noteなど読者競合3件の公開範囲を確認しました。
多かったのは、次の流れです。
- キーワードを決める
- 検索意図を調べる
- 見出し構成を作る
- 本文を書く
- SEO項目と装飾を整える
- WordPressへ投稿する
この流れは、作業を前へ進めるには便利です。一方で、筆者の経験が足りない場合、競合を確認できない場合、内部リンクのURLが不明な場合に「どこで止まるのか」は、公開範囲では詳しく扱われていない記事もありました。
SWELLへの装飾やWordPress入稿を扱う記事・サービスもあります。そのため、「SWELLに対応した」だけでは独自性になりません。
設計の中心は、完成まで進む手順より、進めてはいけない条件を先に決めることです。
プロンプトを6つの編集工程へ分けた
ブログ特化版では、次の状態遷移を最初に置いています。
入力診断 → 設定確認 → 一次情報の必要性判定 → 必要なら質問のみ → 競合・一次資料調査 → 独自角度決定 → 記事タイプ・構成自動選択 → 記事ブリーフ確定 → 執筆 → 反証・校閲 → SWELL装飾設計 → 投稿パッケージ
この12段階の状態遷移を、読者が追いやすい6つの役割へ集約して説明します。
1．入力診断
テーマ、読者、目的、筆者の経験、参考資料、WordPressの設定、公開権限を確認します。
入力欄が空いていても、すべてを質問するわけではありません。記事の中心主張が変わる情報、本人の経験として書く情報、公開可否に関わる情報だけを質問対象にします。
2．一次情報の質問
体験記事なのに使用状況や失敗が書かれていない場合、原稿は作りません。質問だけを一度に返し、回答を待ちます。
質問では、実際の手順、最初に困った点、修正した内容、期間、比較条件、公開してよい範囲を確認します。答えられない場合は、体験記事から一次資料を使う解説記事へ切り替えます。
3．競合と一次資料の調査
競合記事を要約して終わらず、共通している主張と、まだ答えられていない問いを分けます。
料金、仕様、制度、統計などは、企業の公式情報、官公庁、原論文へ戻ります。検索や資料確認を実行できなければ、「調査済み」とは表示しません。
4．独自角度の決定
独自性を、競合と反対の結論を出すこととは考えません。
結論が同じでも、対象読者、使った条件、失敗、判断基準、適用外の条件が違えば、記事へ追加できる価値があります。今回のプロンプトでは、競合が残した未回答の問いと、筆者が公開できる一次情報が重なる場所を探します。
5．執筆とSWELL装飾
本文を書いた後、装飾を別工程で設計します。
太字、マーカー、ボックスを先に増やすと、重要な箇所より「装飾しやすい箇所」が目立ちます。そこで、中心主張、手順、注意点、比較、CTAの意味を確認してから、必要なブロックだけを割り当てます。
6．SEO設定と公開権限
SEOタイトル、メタディスクリプション、スラッグ、カテゴリー、タグは本文と分けて出します。
内容が公開できる状態でも、操作権限が「出力のみ」ならWordPressを変更しません。下書き保存と公開も別の権限として扱います。
一次情報が足りないときは、原稿を書かず質問で止める
この設計で最も重視したのは、情報不足を自然な文章で埋めないことです。
例えば、レビュー記事で次の情報がないとします。
- 実際に使った機能
- 使用した端末や環境
- 最初に失敗した点
- 修正前後の違い
- 向かないと感じた条件
ここでAIが一般的な長所と短所を書けば、文章としては完成します。しかし、その中心部分は誰にでも書ける内容です。
プロンプトでは、独自性の核になる情報が不足している場合、タイトル案や原稿を同時に出さず、質問だけを返すようにしました。「何かを出す」より「今は書かない」を選べることが、体験の捏造を防ぐ設計になります。
独自性は「変わった結論」ではなく未回答の問いから作る
初期調査では、AIライティング、note運用、SEO記事作成に関する公開ページを確認しました。記事化にあたる追加調査では、ブログ5件とnoteなど3件の公開範囲を確認しています。
競合には、コピペ用プロンプト、SEOの工程、半自動化、WordPressへの自動投稿など、実用的な情報がすでにあります。
一方、追加調査で公開範囲を確認した8件では、次の3点を、停止条件まで含めて同時に扱う記事は確認できませんでした。検索結果全体に存在しないという意味ではなく、2026年8月20日の確認範囲での差分です。
- 一次情報が足りなければ、質問だけで停止する
- 公開本文と編集メモを明確に分ける
- サイト全体設定と記事単位の装飾を分ける
この未回答部分を、マスタープロンプトの中心にしました。
競合との差分を作る場合も、競合固有の文体、比喩、見出し、特徴的な構成は模倣しません。未回答の問い、根拠、対象読者、判断基準の違いで、この記事に追加できる価値を作ります。
設計監査で見つかった4つの問題
初版を作った後、別の役割を持つエージェントに設計と出力を監査させました。そこで、完成前には気づかなかった問題が見つかりました。
1．記事タイプの名前が一致していなかった
本文では6種類の記事タイプを定義していましたが、記事ブリーフの選択肢と一部の名称が一致していませんでした。選べないタイプと、定義されていないタイプが混ざっていたため、同じ6分類へ統一しました。
2．WordPressへ貼る範囲が曖昧だった
投稿パッケージには、本文、SEO設定、装飾指示、競合メモ、未確認事項が含まれます。境界が弱いと、編集メモまで本文へ貼り付ける可能性があります。
そこで「WordPress本文へ入稿するのは【完成本文】だけ」と明記し、公開用と編集メモの間に分離線を置きました。
3．SWELLの標準画面で設定できない値が混ざる可能性があった
見出しごとの文字サイズや細かな余白は、SWELLの標準画面だけでは変更経路を確認できない場合があります。
設定名を推測して手順を作らず、「標準画面では未確認」「カスタムCSSが必要な可能性」「別途許可待ち」と表示するルールへ変えました。
4．装飾ルール同士が矛盾した
ボックスは連続させないと決めた一方で、試作ではキャプション付きブロックを2つ続ける指定が入りました。
内容の分類と装飾の密度を別々に確認し、1つのボックスへまとめるか、通常の見出しとリストで表示するよう修正しました。
長いプロンプトでも、内部の規則が矛盾すれば安定しません。指示を増やすだけでなく、実際の出力例へ当てて監査する必要がありました。
SWELLではサイト全体設定と記事内装飾を分ける
記事ごとの装飾を考える作業と、サイト全体の文字サイズや色を変える作業は影響範囲が異なります。
ブログ特化版では、次の2つに分けました。
| 対象 | 扱う内容 |
|---|---|
| サイト基盤デザイン | 本文文字サイズ、行間、記事幅、基本色、リンク色、CTA色 |
| 記事内装飾 | 太字、マーカー、キャプション、ステップ、注意、表、CTAの配置 |
サイト基盤は既存値を優先し、未確認の値を勝手に変更しません。推奨値は提案にとどめ、カスタムCSSは別の許可がある場合だけ扱います。
記事内装飾は、1つの記事の意味を伝える範囲に限定します。SWELLの実装方法は、「SWELLで記事を読みやすくする方法」で実画面を確認しています。
公開本文と編集メモを分けた16項目
ブログ特化版は、最終出力を16項目に固定しました。
| 区分 | 出力するもの |
|---|---|
| 記事の核 | 記事ブリーフ、推奨タイトル、完成本文 |
| 入稿設定 | 装飾仕様、サイトデザイン、SEO、内部リンク、アイキャッチ、CTA、SNS告知 |
| 編集メモ | 一次資料、競合調査、独自性、未確認事項、内容判定、操作権限 |
WordPress本文へ入れるのは、3番目の【完成本文】だけです。
装飾やSEO設定はWordPressの対応欄へ入れ、競合調査や未確認事項は公開しません。公開前の確認手順は別記事のチェックリストへ分け、記事末のCTAから案内します。
マスタープロンプトを使う流れ
現時点で想定している使い方は次のとおりです。
WordPress・SWELL向けのブログ特化版を使います。
テーマ、読者、目的、経験、参考資料、WordPress設定を伝えます。
個人情報を除き、個人を識別しない経験の要約だけで回答します。
調査と執筆が完了したら、16項目に分かれた出力を確認します。
編集メモを混ぜず、【完成本文】だけをWordPress本文へ入れます。
装飾、SEO、内部リンク、プレビューを確認します。
運用上の安全ルール
自分や第三者の個人情報はAIへ入力しません。AIの出力も、出典、事実、権利関係を確認せずに公開しません。
これは設計上の想定手順です。生成AIへ約5,300文字のブログ特化版を入力した場合の挙動、質問状態の維持、長い投稿パッケージの出力はまだ確認していません。
記事構成だけを作りたい場合は、工程をここまで広げず、「ChatGPTでブログ記事構成を作る手順」の短いプロンプトから始める方が扱いやすいです。
次に検証する3つの条件
設計だけで終わらせず、次は同じ記事ブリーフを使って3つの状態を確認します。
1．一次情報が十分な場合
調査から投稿パッケージまで進み、16項目が分離されるかを確認します。
2．一次情報が不足する場合
原稿やタイトルを出さず、質問だけで停止できるかを確認します。
3．調査できない場合
URLや根拠を作らず、「調査不能・要確認」と表示できるかを確認します。
検証時は、使用モデル、実行日、入力した記事ブリーフ、無修正の出力、修正回数、各条件の合否を残します。結果が出た後に、この記事へ追記します。
まとめ｜プロンプトは文章ではなく編集工程を渡す
今回作ったブログ記事用プロンプトは、一度でうまい文章を出すための魔法の指示文ではありません。
入力を診断し、必要なら質問で止まり、競合と一次資料を調べ、独自角度を決め、本文とSWELL装飾を分け、最後に公開権限を確認する。プロンプトは文章ではなく、編集者が順番に行う判断を工程として渡す設計です。
2つのプロンプトファイルと16項目の出力形式は作成できました。しかし、生成AIでの再現性、文章品質、作業時間は未確認です。
次は、同じ条件で実行し、設計どおりに止まれるかから検証します。速く完成することより、書いてはいけない情報を勝手に補わないことを、最初の合格条件にします。
参考にしたSWELL公式資料
AIの利用について
この記事は、Codexを使って競合調査、構成、下書き、ファイル数値の確認、反証、文章監査を行いました。競合の有料部分・未閲覧部分は推測せず、実行未実施の結果は未確認として記載しています。公開前の事実確認と最終判断は運営者が行います。
最終確認：2026年8月20日
WordPress公開前の確認へ進む
コメント