プロンプトエンジニアリングの基本：良いプロンプトの書き方

プロンプトの書き方が大切な理由

言語モデルは、あなたの状況を知りません。見えているのは、送ったテキストだけです。プロンプトがあいまいだと、モデルは空白を最もありがちな答えで埋めます。たいていは一般的で、長すぎたり、読み手を外していたりします。プロンプトエンジニアリングは、ほとんどが推測を減らす作業です。

役立つテストがあります。あなたに会ったことのない賢い新人が、メッセージだけでそのタスクをうまくこなせるでしょうか。先に3つ質問が必要なら、モデルにもその答えが必要です。OpenAI、Anthropic、Googleの公式ガイドは、言葉は違っても中心的な助言は同じです。明確で具体的に書く、背景を伝える、例を示す、ほしい形式を伝える、というものです。

良いプロンプトの6つの要素

6つすべてが必要なプロンプトばかりではありませんが、このリストを確認するだけで、弱いプロンプトの大半は直ります。

長い入力素材は、XML風のタグや三重引用符などの明確な目印で囲みましょう。そうすれば、モデルが自分への指示と、処理すべきテキストを区別できます。貼り付けたWebページなど、入力の中に隠れた指示に誤って従ってしまうリスクも下がります。

書き換えのビフォーアフター

典型的な弱いプロンプトの例です。

Summarize this article.

モデルは要約を作りますが、どのくらいの長さで、誰向けで、どんな形でしょうか。同じ依頼の空白を埋めると、次のようになります。

You are helping a busy product manager decide whether to read a research article.

Summarize the article below for that reader.
- Start with one sentence: the main finding.
- Then 3 bullet points: method, key number, main limitation.
- Use plain English. Explain any technical term in a few words.
- Under 100 words in total.
- If the article does not state a limitation, write "No limitation stated".

<article>
{paste the article here}
</article>

各部分の働きは次のとおりです。

• 最初の行で、読み手と目的を設定します。要約が何のためにあるかがわかるので、モデルは何を残すかを選べます。
• 箇条書きの構成が形式を固定するので、どの要約も同じ見た目になり、比べやすくなります。
• 語数の制限が、モデルの水増しを防ぎます。
• 制限が書かれていない場合のルールが、境界のケースでの動き方を示し、モデルが勝手に作ることを防ぎます。
• タグが、記事と指示を分けます。

言葉で足りないときは例を見せる

声のトーン、ラベル付けの方式、特定の出力スタイルなど、言葉で説明するのは難しくても、見せるのは簡単な要件があります。いくつかの実例を加える方法を、フューショットプロンプティングと呼びます。例が1つ（ワンショット）でも大きく役立つことがよくあります。バリエーションのある2〜5個の例があれば、主なケースは通常カバーできます。

Classify each support message as BILLING, SHIPPING, PRODUCT or OTHER.
Reply with the label only.

Message: I was charged twice for order 5521.
Label: BILLING

Message: The handle on my mug cracked after one week.
Label: PRODUCT

Message: Do you have a shop in Osaka?
Label: OTHER

Message: {new message}
Label:

例は、互いに違うものにしましょう。すべてが短く丁寧な例だと、長くて怒っているメッセージをモデルがうまく扱えないかもしれません。例がルールと合っているかも確認してください。モデルは、書かれた指示よりも例を強くまねします。

特定の場面で役立つテクニック

• 答えの前に手順を書かせる。数学、論理、複数の要素がある判断では、最終回答の前に問題を順に考えさせると精度が上がります。これはチェーン・オブ・ソート（思考の連鎖）プロンプティングと呼ばれます。現在の多くのモデルは内部でこれを行う（推論モードや思考モードと呼ばれます）ので、丁寧な回答を求めるだけで十分なこともあります。
• 大きなタスクを分ける。「調査、アウトライン作成、レポート執筆」を1つのプロンプトで頼む代わりに、3つのプロンプトに分けて、それぞれの出力を確認します。これはプロンプトチェーンと呼ばれます。
• 役割は、情報が増えるときだけ与える。「あなたはベトナムの税理士です」は、言葉の選び方と前提を変えます。「あなたは世界最高の天才です」では何も加わりません。
• 避けることだけでなく、すべきことを伝える。「くどくしないで」より「短い文で書いて」のほうがうまくいきます。
• 「わからない」を許す。情報が足りないと答えてよいと、モデルに伝えます。でっち上げの事実が減りますが、なくなりはしません。
• コードが出力を読むときは、機械可読な形式を求める。たとえば、名前付きフィールドのJSONです。ほとんどのAPIは、JSONスキーマを直接強制することもできます。

プロンプトをコードのようにテストする

1つの例でうまくいったプロンプトも、次の例では失敗することがあります。繰り返し使う場合や、他の人が使う場合は、テストしましょう。

1. 良い出力がどんなものかを書き出す。長さ、形式、正しくなければならない事実。
2. 実際の入力を10〜20件集める。短すぎるもの、長すぎるもの、話題が違うもの、別の言語など、難しいものも含めます。
3. すべてでプロンプトを実行し、出力をすべて読む。
4. 一度に1つだけ変更して、全件をもう一度実行する。どの変更が効いたのかがわかります。
5. 最終的なプロンプトとテストセットを一緒に保管する。モデルを切り替えたときや、モデルが更新されたときは、もう一度セットを実行します。

最後のステップが大事なのは、同じプロンプトでも、モデルが違えば、また同じモデルの新しいバージョンでも、動作が変わりうるからです。モデル提供元のプロンプトエンジニアリングのガイダンスが時間とともに変わるのも、そのためです。

よくある間違い

• 1つのプロンプトに目的を詰め込みすぎる。同じ重みのルールが10個あると、一部は無視されます。最も重要なルールを先頭に置き、リストは短くします。
• 矛盾する指示。たとえば「詳しく」と「50語以内」です。モデルは片方を満たし、もう片方を破ります。
• 明確な理由ではなく、大文字や脅し（「絶対に守れ」）に頼る。ルールがある理由を短く説明するほうが、たいていはうまくいきます。
• 入力と指示を分けず、文書の一部をモデルが命令として扱ってしまう。
• 出力の事実を信じる。うまく書いたプロンプトでも、自信ありげな間違いは出ます。名前、数字、引用、リンクを確認してください。