文章作成で使えるAIプロンプトの作り方｜条件と出力形式を伝える

文章作成のPromptは、長い指示を書くことより「何を完成とするか」を先に決めることが大切です。読者、目的、参照できる事実、必須項目、出力形式、確認方法を渡し、まず構成案を作ってから本文へ進めます。事実を含む記事や案内文なら、AIに執筆と事実確認を同時に任せず、原稿と未確認点を分けて受け取ると修正しやすくなります。

最初に埋めるBriefは7項目

Task：作るものを具体的な名詞で示します。「文章を書く」ではなく「既存ユーザー向けに、機能変更を知らせるメールの初稿を作る」とします。

Audience：誰が読み、何をすでに知っているかを書きます。初心者、既存顧客、社内法務など、前提知識の違いが語彙や説明量に影響します。

Purpose：読後に何を理解・判断・実行してほしいかを一つに絞ります。「興味を持ってもらう」だけでなく、「変更日までに設定を確認してもらう」のように行動で表します。

Context / sources：使ってよい資料を列挙し、優先順位を付けます。更新日、対象プラン、適用地域、社内用語集などがあれば一緒に渡します。

Must include：必ず含める事実、手順、注意点、連絡先などを記します。内容が重要なら、見出しや順序も指定します。

Tone / format：敬体・常体、専門度、長さ、見出し、箇条書き、表、Markdownなどを指定します。「自然に」だけでは判断が分かれるので、「一文を短くし、煽り表現を避ける」のように文章上の特徴へ置き換えます。

Constraints / review：推測禁止、引用の扱い、個人情報を含めない、数字はSourceと照合する、未確認事項を別欄へ出すなど、作業の境界と確認項目を決めます。

そのまま使える依頼文

次の枠を埋めて、まず構成案だけを依頼します。

作成物：[種類・用途]

読者：[立場、前提知識]

目的：[読後にしてほしいこと]

使ってよい情報：[資料名、URL、更新日]

必須項目：[抜けてはいけない事実や論点]

文体・形式：[敬体など、長さ、見出し、表の有無]

制約：[推測禁止、掲載不可情報、用語]

確認方法：[Source照合、文字数、抜け漏れ]

最初に見出し案と、各見出しで答える質問を出してください。資料にない事実は補わず、「要確認」として分けてください。

構成案を受け取ったら、本文をすぐ生成する前に3点を見ます。目的の行動に必要な見出しがあるか、同じ説明を別の見出しで繰り返していないか、Sourceのない事実を要求していないかです。足りない場合は構成を直し、順番が決まってから本文を作ります。OpenAIのChatGPT向け案内も、明確で具体的な依頼と、回答を見て追加文脈や表現を調整する反復を勧めています。最初の出力を完成品と扱う必要はありません。

例：機能変更を知らせる顧客メール

入力資料に「新しい共有設定は11月1日から有効」「既存共有リンクはその日から無効」「問い合わせ窓口はサポートフォーム」とだけ書かれているとします。依頼では「11月1日以前にリンクを保存している顧客が、何をいつ確認するか分かるメール」と目的を設定します。構成案は、変更日、影響する利用者、必要な操作、問い合わせ先、の順が自然です。初稿では、資料にない「自動移行されます」「データは消えません」などの説明を追加しないよう明示します。モデルが不足情報を埋めてしまったら、その文を採用せず、担当部署に確認する質問として分離します。

記事や解説文を作るときは、見出しごとに読者の疑問を対応させます。例えば「無料プランでできること」を説明するなら、現在の料金表や利用条件をSourceとして渡し、価格・上限・更新日を本文と照合します。AIに検索させた場合も、検索結果の要約だけで確定せず、公式ページを開いて該当条件を確認してください。事実の根拠がない場合に、文体が滑らかでも掲載可能とは限りません。

一度に本文全体を仕上げるより、次の段階に分けるとレビュー点が明確になります。

1. Briefから構成案を出す。抜けた論点、順序、読者が次に行うことを確認する。

2. 必要なSourceを見出し単位で整理する。各主張に根拠があるか、対象や日付が一致するかを記録する。

3. 初稿を作る。構成案に沿って書き、Sourceにない内容や計算を「要確認」に分ける。

4. 内容確認を行う。数字、固有名詞、引用、対象期間、条件文をSourceと突き合わせる。

5. 編集する。重複、抽象語、長い一文、読者に不要な説明を削り、目的に必要な例を残す。

6. 最終確認を行う。見出しだけ読んでも流れが分かるか、読者が行動へ移れるかを確かめる。

出力を「もっとよくして」とだけ頼むと、元の意図が動くことがあります。改稿時には、変更してよい範囲と守る要素を明示します。例えば「意味、数値、引用元は変更しない。重複を削り、短い文にする。変更箇所の理由を箇条書きで示す」と指定すれば、内容変更と表現調整を分けて確認できます。固有名詞や法務表現のように変更リスクが高い部分は、変更不可の範囲として別に示します。

失敗の見分け方

出力が一般論に寄ったら、読者、場面、使える資料、目的のいずれが曖昧かを見直します。分量が足りない場合も「長くして」だけではなく、欠けている判断材料や例を具体的に追加します。文章が長くなっただけなら、不要な背景説明を削ります。

事実が混ざった場合は、出力をそのまま採用せず、どの文章がどのSourceに支えられているかを表にします。Sourceの文面を読み違えた、古い情報を使った、条件を落とした、のどれかを特定し、該当箇所だけ直します。

語調が不自然なら「人間らしく」ではなく、読者に合う語彙、避ける表現、文の長さ、敬語の距離感を指定します。既存記事やブランドガイドを渡す場合も、文章を丸写しするのではなく、言葉遣いと説明の密度を参考にする範囲を示します。

指示が増えて矛盾したときは、目的と制約を優先順位付きで並べます。「短くする」と「例をすべて残す」が両立しない場合、どちらを優先するかを先に決めます。優先順位が決められないなら、AIに選ばせず、2案と違いを出させて人が決めます。

タスク別に変えるポイント

告知文は、変更点・対象者・期限・次の操作を短く並べると、読者が必要事項を見つけやすくなります。ブログ記事なら、検索者の疑問を見出しへ対応させ、説明の順序を先に固めます。商品説明では、仕様と訴求を分け、根拠のない効果や保証を追加しないよう制約します。社内文書なら、決定事項、未決事項、担当者、期限を混ぜずに出力させます。

どの用途でも、共通Promptをそのまま使う必要はありません。定型メールのように条件が安定した仕事はBriefを短くできます。一方、料金、規約、健康、安全、契約に関わる文章では、根拠、対象条件、確認者を省かないようにします。Gemsなどのカスタム指示を使う場合も、毎回変わる依頼と固定した文体ルールを分けて管理します。Googleの案内では、役割や目的、出力形式、必要な背景を具体的な指示へ含め、作成した指示は保存前に確認する流れが紹介されています。

完成稿のQAチェック

・タイトルと冒頭で、読者の疑問への答えが分かる。

・読者、目的、対象条件が本文全体で一貫している。

・必須項目がすべてあり、重複説明が整理されている。

・数字、日付、製品仕様、引用元を一次資料で確認した。

・資料にない事実を断定していない。未確認点は本文へ混ぜず、担当者へ返した。

・一つの具体例か、読者が自分の状況へ当てはめられる手順がある。

・出力形式と語調が用途に合い、読み手の次の行動が明確である。

・人が最終確認し、AIが作った文章を無条件で公開しない。

短い定型文なら、Task・Audience・Context・Format・Constraintだけで足りる場合があります。複数の事実を説明する記事なら、目的、Source、必須論点、確認方法まで分けて渡します。工程を増やすことが正解ではなく、読者へ出すリスクに合わせて確認の深さを変えるのが実務的です。

AIものさし編集部の判断

文章作成Promptの中心は、モデルに文章を任せることではなく、依頼者が目的と判断基準を言葉にすることです。Brief、構成案、初稿、事実確認、編集という順に分ければ、どこで誤りや意図のずれが起きたかを見つけやすくなります。

まず短いBriefを作り、構成案だけを出させてください。必要な論点が揃ったら初稿へ進み、事実は資料と照合し、表現は読者に合わせて直します。出力が不足したら条件を追加し、満たしたら止める。毎回同じ長いPromptを使うより、完成条件を決めて必要な指示だけ渡す方が再利用しやすくなります。

Promptを用途に合わせる小さな例

同じBriefでも、出力を使う場面で確認項目は変わります。

・ブログ記事：誰のどの疑問に答えるか、見出し案、必要な根拠、最後に提示する次の行動を指定します。

・顧客メール：対象者、変更日、影響する人、期限、問い合わせ先を必須項目にします。未確定の補償や予定を断定しない制約を加えます。

・社内議事録：決定事項、未決事項、担当者、期限を区分し、発言者が不明なら推測で割り当てないようにします。

・商品説明：公開済み仕様と、説明したい利点を別欄にします。利点は仕様から確認できる範囲に限り、数値や比較表現には根拠を求めます。

・FAQ：質問文を読者の言葉に近づけ、回答を短くします。ただし例外条件や問い合わせ先を落とさないようにします。

このように「文章の種類」ではなく、完成物の用途と読者の行動が違えば、入力する条件も変わります。

少ない資料から出す場合の安全な往復

例えば新機能の社内メモしかないなら、最初の依頼は「告知文を書いて」ではなく「このメモだけで確定できる事実、曖昧な点、読者へ知らせるために不足している情報を分けてください」とします。返答の未確定リストを担当者が埋めた後、初めて告知文を作らせます。

入力：共有機能を更新。11月1日開始。旧リンクは利用不可。問い合わせはサポート窓口。

出力すべき確認点：対象サービス名、利用者が取る操作、保存済みリンクへの影響、開始時刻とタイムゾーン、問い合わせURL。

この段階でリンクの再発行方法が分からないなら、AIに一般的な手順を書かせず、確認事項のまま止めます。情報を追加できたら、「見出し案→メール本文→事実チェック表」の順に作成し、各段階でレビューします。これなら根拠のない説明が完成稿に紛れにくくなります。

一度のPromptで作らせるか、段階を分けるか

定型的で影響の小さい文章なら、Brief、本文、チェックを一回の依頼でまとめても構いません。契約変更の告知、医療・金融に関する説明、利用規約の要約、公開記事など、間違いが読者や組織に影響する文章は分けます。作成者と確認者を分け、AIの文章生成を人間の最終承認に置き換えないことも必要です。

出力に「確認済み」「正確」と書かれていても、それだけで検証済みにはなりません。公式Sourceを人が開いて、本文の主張と条件を照合します。AIには差分候補を抽出させられますが、出典の存在、対象、日付、引用の正確さは別に確認します。