プロ品質のプロンプトを自分で書く方法：実践ガイド

ChatGPT、Claude、Geminiを使っていて、モデルの性能は高いはずなのになぜか結果が平凡に感じる——その原因はたいていツールではなく、あなたが与えている指示にあります。「広告を書いて」といったリクエストは、モデルにオーディエンス、トーン、目的を推測させます。結果は文法的に正しくても、そのままでは使えません。このガイドでは、その結果を変えるスキル、つまり試行錯誤ではなく意図的に自分のプロンプトを書く方法を教えます。

学べる内容：「リクエスト」と「プロンプト」の違い、すべての良いプロンプトを支える4つの原則、3つの応用テクニック（Chain-of-Thought、Few-Shot、Output Schema）、よくある5つの間違いとその回避法、そしてプロンプトをテストして改善する方法。最後に7日間の実践プランを紹介します。

このガイドは、テンプレートをコピーするだけでなく、なぜそのプロンプトが機能するのかを理解したい人向けです。コピーしてすぐ使えるプロンプトをお探しなら、プロンプトライブラリまたはすぐに使えるAIプロンプトガイドから始めてください。しかし、自分のプロンプトを書き、自分が何をしているのかを理解したいなら、このガイドはあなたのためのものです。

プロンプトとは何か、なぜ重要なのか

プロンプトとは、AIモデルに回答を生成させるために与えるテキストのことです。しかしこの定義では不十分です。プロンプトとプロンプトの違いは長さではありません。モデルに対してどれだけのことを決めているかなのです。

「リクエスト」と「プロンプト」の違い

リクエストは、手早く何かが欲しいときに書くもので、意思決定をモデルに任せます。プロンプトは、その意思決定をモデルではなく自分がすべきだと分かっているときに書くものです。この区別は学問的なものではありません。完全な書き直しが必要な結果と、最初の試行でほぼ最終版に近い結果との違いなのです。意思決定をモデルに任せると、モデルは安全な道を選びます。つまり、ニュートラルなトーン、中程度の長さ、一般的な内容です。これらの選択は間違いではありませんが、あなたの選択ではありません。良いプロンプトは推測の余地を最小化し、モデルがあなたの決定に基づいて構築できるようにします。

実際の例：同じタスクを2つのプロンプトで

リクエスト： 私の製品の広告を書いて。

モデルが通常生成するもの：

「あなたの人生を変える新製品を発見してください！高品質で競争力のある価格。今すぐ注文して、チャンスを逃さないでください！」

このテキストは文法的に正しいですが、一般的です。どんな製品なのか、誰向けなのか、何が違うのか、誰にもわかりません。クライアントに送ったら、書き直しを求められるでしょう。

プロンプト：

あなたは小売業界のFacebook広告を専門とする広告コピーライターで、5年の経験があり、誇張のない直接的なトーンで書きます。

[製品の説明]について、PASフォーミュラを使った広告バリアントを3つ書いてください。ターゲットは[オーディエンス：年齢、興味、問題]です。

各バリアントには：

最初の行で注意を引く書き出し（感嘆符なし）

オーディエンスが経験する具体的な痛点

製品が提供する明確な解決策

1つの明確なcall-to-action

長さ：90〜120語

トーン：自信があり、マーケティング的な誇張はなし

結果はMarkdownテーブルで3行（バリアント1、2、3）、上記の各要素に1列ずつ出力してください。

モデルが生成するもの： 明確な構造に基づいた3つの広告バリアント。それぞれ直接A/Bテストに使えます。違いはモデルの「知能」ではなく、あなたがどれだけ決めたかにあります。

なぜ指定しないとモデルは推測するのか

モデルは心を読めません。役割を指定しなければ、一般的な役割を選びます。オーディエンスを指定しなければ、一般的なオーディエンスを選びます。長さを指定しなければ、中程度の長さを選びます。これらの選択は間違いではありませんが、あなたの選択ではありません。良いプロンプトは推測の余地を最小化します。

この同じ原則をPromptsaでも適用しています。各ツールは結果に実際に影響する詳細を尋ね、その周りにプロンプトを構築します。この原則は記事プロンプトジェネレーターや広告ジェネレーターで実際に確認できます。

すべての良いプロンプトの4つの原則

すべての良いプロンプトは、モデルやタスクに関係なく、4つの原則に基づいています。1つでも欠けると、結果の品質が下がります。これらの原則は抽象的な理論ではありません。モデルがあなたの意図を解釈するために使う枠組みなのです。1つ欠けると、その隙間はモデルの推測で埋められ、結果はあなたの目標ではなくその推測を反映します。

1. 役割：誰が話しているのか？

役割を指定すると、モデルが使うトーン、深さ、知識の範囲が設定されます。「あなたは専門家です」ではなく、具体的な専門性を指定します。「専門家」という言葉には実行可能な情報はありません。それは形容詞であり、形容詞はモデルを導きません。「飲食業界のコンテンツライターで、スペシャルティコーヒーのブログ向けに書き、温かみのあるトーンで、カフェコンテンツの編集経験5年」と指定すると、ドメイン（飲食）、オーディエンス（スペシャルティコーヒー愛好家）、トーン（温かみ）が明確になります。あなたが決めた3つの決定事項であり、モデルはもう推測する必要がありません。

あなたは専門家です。コーヒーについての記事を書いてください。

あなたは飲食業界を専門とするコンテンツライターで、スペシャルティコーヒー愛好家向けのブログに書き、温かく実践的なトーンで、カフェコンテンツの編集経験が5年あります。

2. コンテキスト：誰のために、なぜ？

モデルはあなたのオーディエンス、目標、または以前に書いたことを知りません。コンテキストはプロンプトにアンカーを与え、その上に構築できるようにします。コンテキストがなければ、モデルは「みんな」のために「一般的な情報提供」という目標で書きます。オーディエンスと目標を指定すると、すべてが変わります：語彙、例、トーン、そしてあえて言及しないことさえも。

私たちの製品についてのInstagram投稿を書いてください。

[製品の説明]についてのInstagram投稿を書いてください。ターゲットは25〜40歳のスキンケアに関心のある女性で、他の製品を試しても成功しなかった人たちです。目標：製品ページに誘導すること。直接購入させるのではなく。投稿のトーン：正直で誇張なし、友人が友人にアドバイスするように。

3. 制約：長さ、トーン、形式

制約は創造性の制限ではなく、出力の仕様です。制約がなければ、モデルは適切だと思うものを選び、それがあなたに合わないかもしれません。制約はまた、曖昧な形容詞を実行可能な指示に変える方法でもあります。「良いトーン」はモデルにとって何の意味もありません。「誇張した形容詞を使わない、感嘆符は1つまで」は具体的な意味を持ちます。制約を書くときは、自問してください：この制約を結果で検証できるか？答えが「いいえ」なら、その制約は曖昧で、言い換える必要があります。

製品の説明を書いてください。

以下の制約で製品の説明を書いてください：
- 長さ：80〜100語（それ以上は不可）
- トーン：実践的、誇張した形容詞なし（「最高」「最強」）
- 製品が解決する問題を説明する文から始める
- 具体的なメリットを3つ追加（一般的な約束は不可）
- 1つのcall-to-actionで終える
- 感嘆符は1つまで

4. 出力：正確に何を受け取りたいのか？

この原則が最も軽視されています。あなたが欲しいのは「テキスト」ではなく、具体的なものです：表、リスト、JSON、Markdown、メール、投稿。形式を正確に指定します。出力形式を指定すると、プレゼンテーションだけでなく思考の構造自体をコントロールできます。表を出力するよう求められたモデルは、書く前に列と行について考えます。これにより推測が減り、コンプライアンスが向上します。

コンテンツのアイデアをください。

[トピック]についてのブログ記事のアイデアを10個、以下の列を持つMarkdownテーブルでください：
| # | 記事タイトル | ターゲットキーワード | コンテンツタイプ（ガイド/分析/リスト） | ターゲットオーディエンス |

応用テクニック（でも実用的）

4つの原則に加えて、特定のタスクで結果を改善するために追加できる3つのテクニックがあります。魔法ではなく、すべてのプロンプトで必要なわけではありませんが、いつ使うべきかを知っていれば役立ちます。暗記するよりも重要なのは、いつ役立ち、いつ負担になるかを理解することです。どのテクニックにもコストがかかります：時間が長くなり、トークンが増え、時には不自然な結果になります。本当の知識とは、いつそのコストを払うべきかを知ることです。

Chain-of-Thought：いつ役立ち、いつ害になるか

Chain-of-Thoughtとは、最終回答の前にモデルに推論ステップを示させることです。これは推論を必要とするタスクに役立ちます：分析、比較、問題解決、意思決定。しかし最近の研究はより複雑な姿を示しています。推論用に設計されていないモデルでは、CoTはパフォーマンスをわずかに改善するかもしれませんが、回答のばらつきが増え、CoTなしでは正しく答えられた質問に誤りを導入することがあります。推論用に明示的に設計されたモデルでは、CoTは精度をあまり改善しませんが、はるかに多くの時間とトークンを消費します。言い換えれば、CoTは絶対的に「優れている」わけではありません。特定のタスクのためのツールであり、どこでも使うと利益なしにコストを支払うことになります。

役立つとき：

• 分析と比較のタスク（「比較して…」「分析して…」）
• 意思決定のタスク（「どのオプションが良く、なぜか？」）
• 数学的または論理的なタスク

害になるとき：

• 短い創造的タスク（広告、ツイート）— CoTは利益なしに結果を長くするかもしれない
• 直接的な回答が欲しいタスク（定義、翻訳）
• 推論用に設計されたモデル（o1や内部的に考えるモデルなど）— 明示的なCoTは改善なしにコストを追加するかもしれない

この広告バリアントを以下の基準で分析してください：
1. オーディエンスを明確に指定しているか？
2. 具体的な痛点に対処しているか？
3. call-to-actionは明確か？

最終評価を出す前に、各基準についての分析をステップごとに説明してください。

Few-Shot：例を選ぶ方法

Few-Shotとは、望む出力形式の例を1つか2つプロンプトに含めることです。モデルはパターンを発明するのではなく模倣します。これは、望むパターンが一般的でない場合や、トーンを正確にコントロールしたい場合に特に役立ちます。しかし例の品質が結果の品質を決めます。悪い例はモデルに悪いパターンを教えます。中心原則：多様（異なるケースをカバー）、形式が一貫、あなたのドメインに近い例を選びます。2〜3個の例で十分です。それ以上は利益なしにプロンプトを長くし、モデルの注意をそらします。

以下の2つの例と同じスタイルで、新製品の説明を書いてください：

例1：
「防水バックパック、20リットル。ミニマルデザインで内ポケット2つとパッド入りストラップ。日常使いや短い旅行に最適。」

例2：
「保温水筒、500ml。保温12時間、保冷24時間。漏れ防止キャップと吊り下げループ付き。」

新製品：[製品の説明]

Output Schema：JSON/Markdownの例

「テキスト」を求める代わりに、直接使える具体的な形式を求めてください。これは結果を別のシステムに移したいときに役立ちます。具体的な形式は推測を減らし、再フォーマットが必要な代わりに結果を使いやすくします。ただし注意：形式を指定してもモデルが常に従うとは限りません。小さい、または能力の低いモデルは出力の途中で制約を忘れることがあります。形式が重要な場合は、一部のモデルが提供する「Structured Output」機能を使うか、生成後に結果を検証してください。

結果を次のようなJSON形式でください：
{
"title": "...",
"metaDescription": "...",
"h2Sections": ["...", "..."],
"keywords": ["...", "..."]
}

プロンプト作成の5つのよくある間違い（とその回避法）

原則を理解した後でも、プロンプトを弱める繰り返しの間違いがあります。以下が最も一般的なものです。ほとんどの間違いは「機能しない」という意味の「エラー」ではなく、結果が可能なものより劣り、追加の編集ラウンドが必要になることを意味します。

間違い1：構造のない長いプロンプト

長さ自体は欠陥ではありませんが、構造のない長さはモデルに負担をかけ、コンプライアンスを弱めます。すべての指示を1つの段落に投げ込むと、モデルは何が最も重要か、何が制約か、何が出力かを把握するのに苦労します。構造（見出し、リスト、区切り）は装飾ではありません。プロンプトの読み方をモデルに伝える方法です。

スペシャルティコーヒーについての記事を書いてほしいです。記事は良くて整理されていて、序論と見出しと段落と結論があり、ブログに適していて、コーヒー愛好家を対象にしていて、適切な長さで、適切なトーンであるべきです…

以下の構造でスペシャルティコーヒーについての記事を書いてください：
- 序論：150語
- H2セクション3つ、各200〜250語
- 結論：100語
- 全体の長さ：800〜900語
- オーディエンス：スペシャルティコーヒー愛好家、技術的な背景なし
- トーン：温かく実践的

間違い2：モデルがコンテキストを知っていると仮定する

モデルはあなたのオーディエンス、製品、または以前に書いたことを知りません。コンテキストを含めなければ、モデルはそれをでっち上げます。これはモデルのミスではなく、その仕組みです。モデルは持っているものに基づいて構築し、何もなければ一般的なものに基づいて構築します。

このテキストを改善してください。

以下のテキストを、[分野]の初心者をターゲットにしたランディングページに適したものに改善してください。目標：無料コースの登録者を増やす。トーン：励みになる、誇張なし。

テキスト：
[元のテキスト]

間違い3：トーンを指定しない

モデルのデフォルトトーンは通常フォーマルまたはニュートラルです。別のトーンが欲しいなら、明示的に指定してください。コンテキストからフレンドリーなトーンが「わかる」と仮定しないでください。モデルは人間のように暗黙の意図を理解しません。書かないことは指示の一部ではありません。

私たちの製品についての投稿を書いてください。

私たちの製品についての投稿を[選択：フレンドリー／直接的／ユーモラス／フォーマル]なトーンで書いてください。マーケティング的な誇張はなく、友人のアドバイスのように。

間違い4：1つのプロンプトで複数のことを頼む

プロンプト内のタスクが増えるほど、それぞれへのコンプライアンスが低下します。モデルは（比喩的に）タスクに注意を分散させ、一部を他の犠牲にして完了するかもしれません。タスクを分けてください。記事、次にキーワード、次にメタディスクリプションが必要なら、段階的に行ってください。各段階で結果が良くなり、合計は「すべてを一度に」やろうとするより良くなります。

記事を書いて、キーワードを指定して、メタディスクリプションを書いて、ソーシャルメディア投稿を作成して、画像のアイデアをください。

タスク1：[トピック]についての記事を書いてください（800語、H2/H3構造）。
（完了後、タスク2に移ります。）

間違い5：結果をテストせず編集しない

最初のプロンプトが最良であることはまれです。テストし、何が欠けているかに気づき、編集し、再テストします。このループが「良い」プロンプトと「優れた」プロンプトを分けます。ここでの間違いはプロンプト自体ではなく、最初の試行後に止めることです。良いプロンプトは反復を通じて構築され、1回のセッションでは完成しません。

プロンプトをテストして改善する方法

プロンプト作成は単一のイベントではなく、ループです：書く、テストする、気づく、編集する、繰り返す。このループが平均的なプロンプトを優れたプロンプトに変えます。多くの場合、「機能する」プロンプトと「うまく機能する」プロンプトの違いは、2〜3ラウンドの集中的な編集です。

2つのバリアントでのA/Bテスト

プロンプト全体を編集して改善を期待する代わりに、一度に1つの変数を変更し、結果を比較します。これにより、どの変更が違いを生んだかを知ることができ、推測する必要がありません。

例：

• バリアントA：現在のプロンプト
• バリアントB：同じプロンプト＋「フレンドリーなトーンで」のみ
• 比較：結果は望むものに近いか？はいなら変更を保持。いいえなら別の変数を試す。

いつ書き直し、いつモデルを変えるか

すべての弱い結果がプロンプトによるものではありません。時には原因はモデル自体です。実践的なルール：プロンプトの改善を使い果たす前にモデルを変えない。ほとんどの問題はプロンプトで解決され、モデルでは解決されません。3〜4のプロンプト改善を試しても結果が改善しないなら、別のモデルを試す時期かもしれません。しかし体系的な改善を試していないなら、モデルを変えても問題は解決しません。

表：問題 → 考えられる原因 → 解決策

これは、満足のいかない結果のたびに戻ってこられるクイックリファレンス表です：

手動プロンプトからツールへ

プロンプトを自分で書くことを学んだ後、論理的な疑問が浮かびます：ではなぜツールを使うのか？ 答え：両者は異なる目的を果たし、どちらも他方を置き換えないからです。ツールはスキルの代替ではなく、そのアクセラレーターです。そしてスキルはツールの代替ではなく、それを意図的に使うための基盤です。

いつ自分のプロンプトを書くか

• タスクが非標準で、汎用ツールでは捉えられない特定のコンテキストが必要なとき
• すべての言葉を完全にコントロールしたいとき
• 学んでいるとき — 手動で書くことがモデルの仕組みを理解する最良の方法です
• タスクがデリケート（法的、医療、財務コンテンツ）で、すべての詳細を手動でレビューする必要があるとき

いつ既製のツールを使うか

• タスクが標準的（SEO記事、製品説明、広告）なとき — ツールが4つの原則を自動的に適用します
• 時間を節約したいとき — ツールが詳細を尋ね、プロンプトを構築し、試行錯誤のループを回避します
• 初心者のとき — ツールが良いプロンプトの構築方法を示し、学ぶべき参考になります
• 既存のプロンプトを検証する必要があるとき — プロンプトオプティマイザーがプロンプトを強化し、何が欠けているかを示します

両方から同時に利益を得る方法

最適なアプローチは組み合わせです：

1. 標準的なタスクにはツールから始める（記事、広告、製品説明）— 4つの原則に基づいて構築されたプロンプトが得られます。
2. 結果のプロンプトを読む — 原則がどのように適用され、制約がどのように表現されたかに気づきます。
3. 手動で編集する — 特定のコンテキストを追加し、トーンを変更し、ツールが含まなかった制約を追加します。
4. テストする — 編集前後の結果を比較します。
5. 学ぶ — 次回は自分でプロンプトを書き、ツールがパターンを教えてくれたことでしょう。

まとめ：プロンプト作成をマスターする7日間プラン

応用のない知識は蒸発します。これは実践的な7日間プランで、毎日小さな演習（15〜30分）、基礎から応用へと導きます。専門家になるのを待たずに始めてください。1つのプロンプトから始め、毎日1つの原則を適用します。

1日目：リクエストとプロンプトの違いを理解する

• よく知っているタスクのリクエスト（1行）を書きます。
• 同じタスクをプロンプト（役割＋コンテキスト＋制約＋出力）として書きます。
• 結果を比較します。何が変わったかに気づきます。

2日目：役割を適用する

• 1日目のプロンプトを取り、「専門家」ではなく具体的な専門性を持つ正確な役割を追加します。
• 再テストします。トーンと深さの違いに気づきます。

3日目：コンテキストを適用する

• 同じプロンプトを取り、コンテキスト（オーディエンス、目標、以前の問題）を追加します。
• 再テストします。結果がオーディエンスにどれだけ近づいたかに気づきます。

4日目：制約を適用する

• 制約（長さ、トーン、形式）を追加します。
• 再テストします。書き直しの必要性がどのように減ったかに気づきます。

5日目：Output Schemaを適用する

• モデルに結果を特定の形式（表、JSON、リスト）で出力するよう求めます。
• 再フォーマットが必要な代わりに、結果がどのように使いやすくなったかに気づきます。

6日目：応用テクニックを試す

• 分析タスクでChain-of-Thoughtを試します。
• フォーマットタスクでFew-Shotを試します。
• 前後の結果を比較します。

7日目：A/Bテスト

• 1つのプロンプトを取り、1つの異なる変数で2つのバリアント（AとB）を書きます。
• 同じタスクで両方をテストします。
• どの変数が違いを生んだかに気づきます。

7日後： 4つの原則、3つのテクニック、テストループを練習したことになります。完全な習得ではありませんが、その上に構築できる強固な基盤です。

結論

プロンプト作成はスキルであり、ボタンではありません。暗記ではなく応用で学びます。4つの原則（役割、コンテキスト、制約、出力）が基盤です。3つのテクニック（CoT、Few-Shot、Output Schema）がツールです。テストと編集のループが「プロンプト」を「優れたプロンプト」に変えるものです。

専門家になるのを待たずに始めてください。1つのプロンプトから始め、1つの原則を適用し、違いに気づき、別の原則を追加します。1週間後、応用せずに10のガイドを読んだよりも遠くまで来ているでしょう。

学習を加速したいなら、プロンプトジェネレーターから始めてください。ツールを試し、結果のプロンプトを読み、原則がどのように適用されたかに気づき、手動で編集します。またはより広い理解のためにプロンプトエンジニアリングガイドで深く掘り下げてください。コピーしてすぐ使えるプロンプトが欲しいなら、プロンプトライブラリとすぐに使えるプロンプトガイドが出発点として良いでしょう。

次のステップ： プロンプトジェネレーターを開き、最初のプロ品質プロンプトを自分で書いてください。またはツールを使ってから比較してください。気づいた違いが最高の教訓です。

関連記事

• すぐに使えるAIプロンプトガイド
• ChatGPT vs Claude vs Gemini：プロンプトの違い
• ChatGPTプロンプト最適化ガイド
• 最高の無料AIプロンプトジェネレーター
• 無料ChatGPTプロンプトジェネレーターの秘密
• AIインフォグラフィックプロンプトガイド
• AI SEOコンテンツガイド
• AI製品説明ガイド
• 広告とマーケティングプロンプト

関連ツール

• プロンプトジェネレーター
• プロンプトエンジニアリング
• プロンプトライブラリ
• プロンプトオプティマイザー
• プロンプト翻訳ツール
• 記事プロンプトジェネレーター
• 広告ジェネレーター
• SEOコンテンツジェネレーター
• 製品説明ジェネレーター
• レポートジェネレーター
• AIエージェントジェネレーター
• インフォグラフィックプロンプトジェネレーター