プロンプトエンジニアリングの手法

01

プロンプトの構成要素

プロンプトとは、AIに送る文章のことです。質問でも、お願いでも、指示でもかまいません。入力欄に打ち込むものは、すべてプロンプトです。

いまのチャットAIの多くは、大規模言語モデル（LLM）で動いています。LLMは、答えを一度にまとめて書くわけではありません。それまでの文章を見て、次に来る小さな単位（トークンといいます）を1つ選んで付け足し、これをくり返します。スマートフォンのキーボードが次の言葉を予測してくれる機能を、ずっと大きくしたものと考えるとイメージしやすいでしょう。モデルはすでに書かれた文章の上に積み上げていくので、プロンプトの言葉が、次に選ばれる言葉を左右します。プロンプトエンジニアリングは、これを意図して使う技術です。欲しい答えがいちばん出やすくなるように、プロンプトを書きます。

良いプロンプトを分解してみると、たいてい次の要素が見つかります。毎回すべてが必要なわけではありません。タスクに合わせて選びましょう。

話を具体的にするため、このガイドでは最初から最後まで1つの例を使います。ショップのレビューをAIに読ませて、お客さんが満足しているのか、不満なのか、その両方なのかを判定させる例です。まずは1行の依頼から始めます。答えがいまひとつなら、そのたびに原因を考えて、それを直す手法を足していきます。表の右の列は、各要素がこの例ではどうなるかを示しています。

各章には、この例を使った3Dの図があります。左に積み上がったブロックが送る内容（プロンプト）、真ん中の球体がAIモデル、右の棒がモデルの答えの候補です。棒が高いほど、その答えが出やすいことを表します。棒の高さは傾向を見せるための例示の値で、実際に測った数値ではありません。

最初の図では、要素を1つずつ足してみてください。指示とレビューだけのときは、棒の高さがばらばらです。要素を足していくと、狙っている答え「JSON形式の mixed」の棒が伸びていきます。

基本のコツ

AIサービスを提供している企業のプロンプト作成ガイドには、だいたい同じアドバイスが書かれています。

• 欲しいことを、短く、はっきり、もれなく伝える。
• 質問や指示は、それが参照する資料のあと、最後に置く。
• 引用符やタグなどの区切り文字（デリミタ）で指示とデータを分け、答えの形式もはっきり書く。
• わからないときにどうするかを伝える。たとえば「わからない場合は『わかりません』と答えてください」。
• 練習用のデータでプロンプトを調整し、最後に取っておいたデータで一度だけテストする。

どの要素を入れるかで、手法の名前が決まります。指示と入力だけならゼロショット。例を足せばフューショット。考える過程を書かせれば思考の連鎖です。まずは、いちばんシンプルなゼロショットから見ていきましょう。

02

例なしで頼む（ゼロショット）

ゼロショットプロンプティングは、例を1つも付けずにタスクを説明するやり方です。「ゼロ」は例の数のことです。AIのチャット欄に打ち込む文章のほとんどは、実はゼロショットです。たとえば、こんな形です。

レビューの感情を分類してください。
レビュー：配送は遅かったけど、商品はすばらしいです

モデルは膨大な量の文章からすでに学習しているので、例がなくてもこうした依頼を理解できます。要約や翻訳、よくある種類の分類など、モデルがもともと得意なことなら、ゼロショットで十分なことも多いです。準備するものがなく、プロンプトも短いので、いちばん安上がりな方法でもあります。

弱点は答えの「形」です。このプロンプトには、どんな形式で答えるのか、ほめ言葉と不満が混ざったレビューをどう扱うのかが書かれていません。そこでモデルは、そのときどきでもっともらしい答え方をします。あるときは「ポジティブ」、次は長い説明文、その次はJSON、という具合です。人が読むならどれでも困りませんが、答えをプログラムで処理する場合、このばらつきは大きな問題になります。

答えがぶれるのは、どんな答えが欲しいのか、モデルにわからないからです。形式やルールを細かく説明することもできますが、たいていは実際に見せてしまうほうが早いです。

03

欲しい答えを見せる（ワンショット、フューショット）

フューショットプロンプティングは、プロンプトにいくつかの例を入れて、どんな答えが欲しいのかをモデルに見せるやり方です。例は、入力と、それに対して欲しい答えのペアです。例が1つならワンショット、2つ以上ならフューショットと呼びます。試験によっては、ワンショットを「シングルショット」と呼ぶこともあります。

レビューの感情を分類してください。

レビュー：梱包がていねい
答え：{"label":"positive"}

レビュー：味はいいけど量が少ない
答え：{"label":"mixed"}

レビュー：配送は遅かったけど、商品はすばらしいです
答え：

なぜモデルは例をまねるのか

1章で見たように、モデルは前の文章を見て、次に来るものを選びます。上のプロンプトでは「レビューのあとにJSONが1行」というパターンが2回出てきます。だから3つめのレビューのあとに書くものとしては、同じ形のJSONがいちばん自然です。モデルが何かを新しく覚えたわけではありません。目の前のパターンを続けているだけです。これをインコンテキスト学習（文脈内学習）と呼びます。

ここが引っかかりやすいところです。「学習」という名前がついていますが、ふつうの意味では何も学習していません。モデル自体は変わらないのです。次のリクエストで例を外せば、モデルは例のことをまったく覚えていません。つまり例は毎回送る必要があり、プロンプトが長くなるぶん、毎回少しずつコストがかかります。

下の図で、例の数を0から5まで増やしてみてください。JSONの形式は、例が1つか2つあればすぐにそろいます。でも「ほめ言葉と不満が混ざっていたら mixed」というルールが身につくのは、そういうレビューの例を3つめに入れたときです。大事なのは例の数よりも、例が何を見せているかです。

良い例の選び方

• 実際に届くレビューに近い例を選ぶ。
• 判断が難しいケースも入れる。簡単な例ばかりだと、難しいレビューが来たときにまたぶれます。
• 答えをばらけさせる。例がすべて positive だと、モデルも positive に寄ります。
• すべての例をまったく同じ形式でそろえる。例がばらばらだと、答えもばらばらになります。

例を使えば、答えの形も判断のルールも決められます。でも、何段階も考えないと解けない問題では、例だけでは足りません。例が最終的な答えしか見せていないと、モデルは途中を飛ばして、それらしく見える数字にいきなり飛びつきがちです。