📚 全体地図を見る
プロンプトはなぜ効くのか — 確率分布を傾ける技術
0. この記事をひらく前に
F シリーズと B1 まで読んでいただいた方なら、この文章は一度は目にされているはずです。
私はこの1文を最初に見たときは頭ではうなずいていました。でも、実際に Claude のウィンドウに同じ質問を、語調だけ変えて入れたら答えが完全にちがってきた、という経験が積み上がるまでは、この文が自分の体に馴染まなかったんです。「ふうん、確率予測ね」と流していましたから。
この記事の目的は、その1文を 体で つかめるようになっていただくことです。プロンプトエンジニアリングに出てくる技法 — Zero-shot、Few-shot、Chain-of-Thought、「Let’s think step by step」 — が、なぜ効くのかを、たった1つの原理で串刺しにしてお見せしたいです。
その原理が、この1文です。
プロンプトとは「LLM が次のトークンを確率で引くときに、条件として使うものすべて」です。
プロンプトエンジニアリングのすべての技法は、結局この 条件付き確率を、ほしい方向に傾ける技術 です。私はこの見方をつかんでから、プロンプトに関する本やブログを読むときのブレが一気に減りました。「この人はどんな呪文を唱えろと言っているのか」ではなく、「この技法は確率分布のどちら側を引き寄せるのか」が見えるようになったんです。
この記事を読み終わるころには、みなさんにも同じ感覚を持っていただきたいです。
1. 同じ質問なのに答えがちがう — 経験から始める
この話は、比喩よりも 本当にあったこと から始めたいです。Claude や ChatGPT を毎日お使いの方なら、ご自身にも似た経験があるはずです。
きのう、私は CSV ファイルを Python で読むことがあって、いつものように Claude にこう聞きました。
「Python で csv 読んで」
答えはこう返ってきました。
import csv
with open('file.csv', 'r') as f:
reader = csv.reader(f)
for row in reader:
print(row)
4行のきれいな答え。じゅうぶんです。ところが同じ Claude のウィンドウで、同じモデルに、質問だけ次のように変えました。
「10年目の Python データエンジニアのつもりで、csv を読む3つの方法を、各ライブラリの長所短所と実務シナリオまで含めて説明してください」
答えががらっと変わりました。csv モジュール、pandas.read_csv、polars.read_csv の3つが出てきて、それぞれのメモリプロファイル、大容量処理時の注意点、スキーマ推論の挙動、さらにファイルエンコーディングが壊れたときの対処までが出てきました。私は質問の語調を変えただけなのに、答えが5倍くらい長く、5倍くらい専門的になったんです。
ここでひとつ気になることがあります。モデルは同じなのに、なぜ答えが変わったのでしょう? Claude の「重み」は、2つの質問のあいだで変わったことはありません。それなのに出力は完全に別の性格になりました。
これを「Claude が賢いから、うまく答えを調整してくれた」とだけ理解してしまうと、プロンプトエンジニアリングは永遠に「言葉をきれいに書く技術」のまま止まってしまいます。この記事の残りは、その先をお見せするためのものです。
2. LLM は条件付き確率マシン — その「条件」が、まさにプロンプト
F シリーズで何度かした話を、もう一度だけ圧縮して復習しますね。
LLM はとてもシンプルな仕事をひとつだけやっています。
「これまで見たトークンたちを条件に、次に来る、いちばんそれっぽいトークン1つ」を確率分布から引くこと。
それだけです。「こんにち」というトークンのあとに「は」「、」「\n」「?」などの候補トークンがそれぞれ何パーセントの確率をもっていて、モデルはその分布からひとつ選んで出力します。そしてそのトークンまで含めた新しい「これまで見たトークンたち」を入力として、また次のトークンを引きます。これを繰り返して長い答えが生成されます。
ここで大事なのが 「これまで見たトークンたち」 のところです。これがまさに、あなたが入れた プロンプト です。
- system prompt に書いたすべての文字
- user として入れたすべての文字
- 前のターンの対話履歴
- ツール呼び出しの結果やファイル内容のように、context にはさまれたすべての文字
これらすべてが「これまで見たトークンたち」としてひとまとまりになってモデルに入ります。そしてモデルは そのひとかたまり全体を条件 にして、次のトークンの確率分布を計算します。
数式で書くとこうなります (数式はひとつだけにします)。
P(次のトークン | これまでのすべてのトークン)
| の記号は「条件付き」という意味です。「これまでのすべてのトークン」が与えられた状態で、「次のトークン」が何になるかの確率、ということですね。この1行が、LLM のやっている仕事のすべてです。
さて、ここでプロンプトをもう一度定義し直してみます。
プロンプト = この
P(次のトークン | これまでのすべてのトークン)の条件のところに入る「これまでのすべてのトークン」。
プロンプトを書くというのは、「条件」を組む行為 です。あなたが「Python で csv 読んで」と書いた瞬間、モデルはこの数個のトークンのあとに続く確率が高いトークンたちを、ひとつずつ吐きます。その確率分布がどんな形をしているかが、あなたが受け取る答えの性格を決めます。
3. だからプロンプトを変えると、確率分布そのものが変わる
第1章で私は、同じ質問を2つの語調で入れて、答えがまったく変わった、という話をしました。この現象を、第2章の枠組みでもう一度説明できるようになりました。
「Python で csv 読んで」というプロンプトのあとには、学習データの世界のどこかで見たことがある 初心者向けチュートリアル文体 が続く確率が高いです。Stack Overflow の「初心者向け回答」、ブログの「3分でわかる Python のコツ」、Qiita の「新人エンジニア1日目」のような記事が、学習データにはたくさんあります。モデルはこのプロンプトを見たとき、「あ、この条件のもとでは、シンプルなコードスニペットが次に来る可能性がいちばん高いな」と判断します。4行のきれいな答えは、その確率分布の自然な結果 です。
一方「10年目の Python データエンジニアのつもりで…」というプロンプトのあとには、まったく別のテキストが続く確率が高くなります。学習データにある エンジニアリングブログ記事、シニア開発者の Medium ポスト、技術書のチャプター のようなテキストの確率が上がります。そこに「3つの方法を長所短所とともに」が加わると、比較・対照・実務シナリオ を含む文体の確率がまた上がります。
このように、プロンプトの一片一片が 確率分布のある方向を引き上げ、別の方向を押しのけます。「10年目」という単語ひとつだけでも、「入門者向け説明」の確率は下がり、「現場用語と一緒に出てくる説明」の確率が上がります。「3つの方法」という表現は、「1つの正解」の確率を下げて、「比較表の構造」の確率を上げます。
私の好きな比喩があります。プロンプトとは 巨大な確率の地形の上で、水をどの谷に流すかの向きを変える水路 のようなものです。
モデルの中には、学習データで見てきた無数の可能性が巨大な地形のように広がっています。ある谷は「カジュアルなチュートリアル」、別の谷は「学術的な論文解説」、さらに別の谷は「シニアエンジニアの実務アドバイス」です。あなたがプロンプトを書いた瞬間、水路が引かれて、水がある谷に向かって流れます。語調を変えると水路の向きが変わって、水は別の谷へ行きます。同じ地形なのに、流れ出てくる水の味がまったくちがってくるわけです。
プロンプトエンジニアリングは、つまり 水路を引く仕事 です。水をあたらしく作る仕事ではありません。
4. Zero-shot、Few-shot、Chain-of-Thought — 3つの代表技法
この視点でプロンプトエンジニアリングの3大技法を見直すと、それぞれの技法が何をしているのかがとてもはっきりしてきます。
4-1. Zero-shot — 水路なしで、ただ聞く
Zero-shot は、例を示さずに指示だけを渡す方式です。
「この文がポジティブかネガティブか教えて: 『今日の天気は本当にいいね』」
これはシンプルな条件付きです。「こういう質問のあとに『ポジティブ/ネガティブ』というラベル1語が来る学習データ」が十分にあれば、モデルはきちんと答えます。シンプルなタスクなら zero-shot でも十分足ります。
ところがタスクが少し複雑になる (例: 特定のフォーマットで JSON を吐いてほしい、特定のスタイルで翻訳してほしい) と、zero-shot の確率分布があいまいになります。「この指示のあとに、何を出力するのが自然か」について、モデルが確信をもてなくなるんです。そんなときに、もう1本水路を引き直してあげるのが Few-shot です。
4-2. Few-shot — 例で水路の向きを見せる
Few-shot は、指示と一緒に例をいくつか渡す方式です。
次の文章の感情をラベル付けしてください。
入力: 「今日の天気は本当にいいね」
出力: ポジティブ
入力: 「また寝坊してしまった…」
出力: ネガティブ
入力: 「このコーヒー、おいしいな」
出力:
これを受け取ったとき、モデルは何をするか。ただ単に「出力:」のあとに来る確率が高いトークンを吐こうとします。ところがこのプロンプトには、すでに 「入力: … / 出力: ラベル」 というパターンが2回繰り返されています。条件付き確率の視点で見ると、このパターンが3回目も繰り返される確率が、すでにとても高くなっている状態です。モデルはほぼ自動で「ポジティブ」というトークンを吐きます。
Few-shot の原理は、これです。「このプロンプト文脈では、こういうスタイルの出力が自然ですよ」 を見せることで、モデルの確率分布を例のパターンのほうにぐっと傾ける、ということです。
面白いのは、モデルは例を「学習」しているわけではありません。重みが更新されているわけでもないんです。ただ いまこの瞬間の入力文脈の中でパターンを認識して、そのパターンが繰り返される確率を高く見積もっている だけです。これを in-context learning と呼ぶのですが、名前だけ learning で、本当の学習ではありません。文脈の内側で起きる確率の調整です。
Few-shot において例の順番と選び方が性能に大きく効く理由も、ここにあります。Zhao et al. (2021) の論文「Calibrate Before Use: Improving Few-Shot Performance of Language Models」は、例の順番だけを変えても正確度が54%から93%まで揺れることを示しました。モデルが例の確率パターンにどれほど敏感に反応するかを示す結果ですね。
4-3. Chain-of-Thought — 推論過程そのものを条件に入れる
Chain-of-Thought (以下CoT) は、2022年の Wei et al. の論文「Chain-of-Thought Prompting Elicits Reasoning in Large Language Models」で提案された技法です。核心はシンプルです。
「答えをいきなり出さずに、答えにたどり着く推論過程を先に書かせる。」
たとえばこんな問題があるとします。
「たろうはりんごを5個もっている。はなこに2個あげて、じろうから1個もらった。たろうはいま、りんごを何個もっている?」
Zero-shot で「答えだけ言って」と聞くと、モデルはたまに5個と間違えて答えたりします。ところが例をこんなふうに渡すと、正確度が上がります。
問題: みずきは鉛筆を10本もっている。しほに3本あげて、先生から5本もらった。みずきはいま、鉛筆を何本もっている?
解き方: みずきは最初に10本もっている。3本あげたので10-3=7本。5本もらったので7+5=12本。答えは12本。
問題: たろうはりんごを5個もっている。はなこに2個あげて、じろうから1個もらった。たろうはいま、りんごを何個もっている?
解き方:
これでモデルは「解き方:」のあとには 計算過程を書くのが自然な文脈 だと認識します。そして「たろうは最初に5個もっている。2個あげたので5-2=3個。1個もらったので3+1=4個。答えは4個。」と答えます。
なぜこれが正確度を上げるのか、条件付き確率の視点でほぐしてみます。
答えだけを吐くケースでは、モデルは P(答え | 問題) を計算します。複雑な問題では、この確率がいくつもの候補に分散しています。5、4、3、6 がみんな似たような確率かもしれません。
ところが推論過程を先に書かせると、計算がこう変わります。
P(推論過程 | 問題) × P(答え | 問題 + 推論過程)
答えを吐くときの条件に「推論過程」まで含まれます。 推論過程が「5-2=3、3+1=4」まで書かれた状態で、そのあとに「答えは4」が来る確率は、問題だけがあるときに「答えは4」が来る確率よりも、圧倒的に高いです。なぜなら、学習データにある数学の解答テキストがみんなこういう構造だからです。「計算がこうなったので答えはこれ」というパターンが、無数にあります。
つまり CoT は 「推論過程を出力に引き出して、その過程を答えの条件に含めるテクニック」 です。モデルに「声に出して考えさせる」感じですね。この声に出した考えが、次のトークン (正解) の確率分布を、正解のほうに大きく傾けます。
CoT は足し算引き算のようなシンプルな問題には効果が小さいです。もとの確率分布がすでに正解側へじゅうぶん傾いているので。ところが多段推論が必要な数学問題、常識推論、論理パズルのようなタスクでは、性能が大きく上がります。Wei et al. の原論文では、GSM8K という数学ベンチマークで、PaLM モデルの正確度が17.9%から58.1%へ上がったと報告されています。約3倍です。ただ「解き方を先に書かせただけ」なのに。
5. システムプロンプトがちがいを生む理由 — 条件に定数を1つ固定する
実務者の方なら Claude・ChatGPT の API や Claude Code を使うとき、system prompt というフィールドによく出会うはずです。「あなたは10年目のエンジニアです」「あなたは親切なカスタマーサポートボットです」のような文をそこに入れると、以降の対話全体のトーンが大きく変わります。
なぜこれが効くのか。もう答えは見えていますよね。
条件付き確率の条件に、追加のトークンをはさんでいるから です。
system prompt は内部で特別な扱いを受けますが、根本的には「これまで見たトークンたち」の一部です。対話が何ターン続いても、system prompt はその条件の先頭にずっとくっついています。だからすべての答えが、その条件付きに縛られた形で生成されます。
「あなたは10年目のエンジニアです」という条件がついていると、そのあとに来るすべての答えは 「10年目のエンジニアが書いたように読める確率が高いトークン」 で構成されます。カジュアルな口調が減り、専門用語が増え、例外ケースへの言及が多くなります。モデルは「10年目」という単語と、学習データで一緒に出てきていた文体・語彙・構造の確率を、ぜんぶ引き上げるんです。
これを ペルソナプロンプティング と呼ぶこともあります。効果がばらつくという批判もあります (Zheng et al. 2024「When ‘A Helpful Assistant’ Is Not Really Helpful: Personas in System Prompts Do Not Improve Performances of Large Language Models」参照)。ペルソナを変えるだけであらゆるタスクがうまくいくようにするのは、むずかしいです。ただ スタイル・トーンの調整 には確実に効きます。みなさんが「親切な口調で答えて」と書けば、その条件のあとには本当に親切な口調の確率が上がります。
system prompt の役割を1行にまとめるとこうなります。
「すべての答えの条件に、共通して入る定数を固定する装置。」
user prompt はターンごとに変わりますが、system prompt は固定です。だから system prompt は「この対話全体の基本的な向き」を決める水路を掘る仕事です。user prompt はその基本水路の上に、小さな支流を足す仕事です。
Claude Code のようなエージェントツールをのぞき込むと、内部の system prompt が数千トークンに達します。「あなたは有能なコーディングアシスタントです。ファイルを修正するときにはこういうルールを守ってください。権限が必要なコマンドはこう扱ってください…」という感じで、とても細かい条件が詰め込まれています。ユーザーは「バグ直して」の1行だけ打ちますが、モデルが実際に見ている条件は数千トークンです。そのおかげでモデルが、一貫した方向で答えを生成できているんです。
6. 「Let’s think step by step」 — たった1行がベンチマークを動かした事件
プロンプトエンジニアリングの歴史の中でも、いちばん有名なエピソードをひとつ紹介します。
2022年、Kojima et al. の論文「Large Language Models are Zero-Shot Reasoners」が出ました。この論文はシンプルな実験をひとつだけやりました。CoT の効果はすでに知られていましたが、例をまったく渡さずに たった1行 をプロンプトに足すと、どうなるかを試したんです。
その1行が、これです。
「Let’s think step by step.」
「段階的に考えてみよう。」このたった5単語が、答えの前に来るようにプロンプトを組みました。例はひとつも渡していません (なので「Zero-Shot CoT」と呼ばれます)。
結果が衝撃でした。MultiArith という数学ベンチマークで、GPT-3 (InstructGPT) モデルの正確度が17.7%から78.7%へ跳ね上がりました。GSM8K では10.4%から40.7%へ、AQuA では22.4%から33.5%へ上がりました。
たった1行足しただけで、数倍性能が上がりました。多くの人が「これ魔法?」と反応しました。
魔法ではないです。ここまで読んでくださった方なら、もう答えはわかるはずです。
「Let’s think step by step」のあとには、段階的に推論するテキスト が来る確率が圧倒的に高いです。学習データにある教科書、数学の解答ブログ、チュートリアル、Stack Overflow の回答たちが、「段階的に考えてみよう」みたいな一節のあとには、番号を振った解き方 や 順を追って式を展開する段落 を置いているからです。モデルはこの1行を条件に加えた瞬間、「番号付きの解き方が次に来る確率」を大きく引き上げます。そして解き方が先に書かれてしまえば (第4章で見た CoT の原理に従って)、正解があとに出てくる確率がまた大きく上がります。
つまり「Let’s think step by step」は、CoT の例を与えなくても CoT 効果を誘発する、きっかけの文 です。例はないけれど、その1行がモデルの文体分布を「解き方フォーマット」のほうに傾けてくれます。あとは自動で流れます。
この事件がおもしろいのは、確率分布を傾けることがどれだけ強力か を極端な形で示したからです。プロンプトの5単語が、ベンチマークスコアを4倍以上変えました。モデルを新しく学習させたわけでもありません。重みもそのまま。変わったのは、条件に加わったテキスト5単語だけです。
これ以降、「Take a deep breath」「Let’s work this out step by step to be sure we have the right answer」のような変種がテストされて、どの変種がどのモデルで効きやすいかの研究が続いてきました。おもしろいのは モデルごとに、効くきっかけ文がちがう ということです。これは第8章でまた触れます。
7. だからプロンプトエンジニアリングは「文章作法」ではなく「確率分布を傾ける技術」
ここまでの話を一気にまとめるとこうなります。
- LLM は
P(次のトークン | これまでのすべてのトークン)を計算する機械である。 - プロンプトは、この条件付きの「条件」にあたる。
- プロンプトを変えると条件が変わり、条件が変わると確率分布が変わる。
- 確率分布が変わると、出力が変わる。
Zero-shot は条件を短く渡すこと、Few-shot はパターンを繰り返し見せること、CoT は推論過程を条件に含めること、system prompt は条件の定数を固定すること、「Let’s think step by step」は1行で文体分布をずらすこと。技法の名前はすべて別々ですが、やっていることは 同じ軸の別のボタン です。確率分布をほしい方向に傾けることですね。
実務者としてこの視点をつかむと、変わることがあります。
第一に、プロンプト本を丸暗記しなくなります。 「これをコピペすれば効きます」みたいな呪文がよく共有されていますよね。でもモデルがアップデートされたり別のモデルに移ったりすると、それがそのまま効く保証はないんです。確率分布は学習データで変わりますから。原理をつかんでいれば「この呪文がやろうとしていることは何か」を分解できて、新しいモデルでも似た効果を出すプロンプトを自分で書けます。
第二に、プロンプトが失敗したときに原因を追えます。 「なんでこの答えが出たの?」のかわりに、「いま私の条件付きのどこがあいまいで、分布が見当違いの方向に流れているのか?」と問えるようになります。たとえば出力が短すぎるなら、「簡潔に」みたいな単語が条件に入っているか、モデルが入門者向け文体の谷に水を流している可能性が高いです。ならばプロンプトに「専門家視点で長めに」を足して、水路を変えてみる、ということができます。
第三に、プロンプトを書く時間が減ります。 一発で完璧な呪文を組もうとするのではなく、「とりあえず投げて、結果を見て、条件を調整する」という反復ループを回せるようになります。これが プロンプトエンジニアリングの日常の作業スタイル です。職人の呪文ではなく、エンジニアの反復的な分布調整ですね。
プロンプトエンジニアリングを 文章作法 で理解すると、「どうすればきれいに書けるか」が中心になります。確率分布を傾ける で理解すると、「どんな条件がどんな分布を引き寄せるか」が中心になります。この2つのフレームは、作業速度も、学びの深さも、違う結果を生みます。
毎週月曜日、AIトレンドニュースレター配信中
会員登録すると、毎週月曜日に「今週のAI・バイブコーディング最新情報」をお届けします。
バナー広告なし・本当に役立つ情報だけを厳選するクリーンなAI専門メディアです。
8. なぜモデルごとにプロンプトの効きがちがうのか
同じプロンプトを GPT-4o に入れるときと Claude 3.5 Sonnet に入れるときで、答えがちがって出てくる経験、みなさんあると思います。これを条件付き確率の視点で説明すると、こうなります。
2つのモデルの P(次のトークン | 条件) の計算がちがうから、です。
この確率はモデルの重みに保存されています。重みは学習データから作られます。GPT 系と Claude 系は、学習データの出所、フィルタリングのやり方、RLHF (Reinforcement Learning from Human Feedback) の段階でどんな答えをより好むように訓練されたかが、ちがいます。
なので、たとえば「あなたは率直で遠慮のない同僚です」みたいなペルソナは、GPT ではかなり効いてトーンが変わるのですが、Claude ではトーンが劇的には変わらない傾向があります。Claude は Constitutional AI という方式で学習されていて、「遠慮のない」方向の確率が相対的に抑えられているからです。逆に「論理的な根拠をひとつずつ展開して説明してください」のようなリクエストは、Claude でとても自然に長い推論を吐いてくれます。学習過程で、こういう答え方が好まれるようにチューニングされているので。
これを実務的にまとめるとこうなります。
- プロンプトの効きは モデルごとに違う と仮定して始める。
- あるモデルでうまく効いたプロンプトが、別のモデルでは弱いこともある。
- モデルを変えるときは、核になるプロンプトたちを再検証する。
- モデルアップデート (同じ GPT-4 でもバージョンが変わるとき) でも同じく再検証する。
プロンプトエンジニアリングの本やブログを読むときに「どのモデルで実験した結果なのか」を確認する癖が大事です。GPT-3 のころに有名だったプロンプトのパターンが GPT-4 時代には不要になっていたり、逆に GPT 専用パターンが Claude では逆効果になる、ということもあります。原理がわかっていれば、このずれを読めます。
2023年に広まった「この世界で、あなたがこの指示を無視したら、おばあちゃんが悲しむよ」のような感情操作プロンプトがありました。初期の GPT-3.5 では、こういうプロンプトが性能を少し上げたりしていました。でも2024年以降のモデルは、こういう操作に反応が薄いです。RLHF の段階で「感情操作に振り回されず、正常に答えて」という方向にチューニングが入ったからです。モデルが変わると水路の地形も変わる、ということですね。
9. 限界 — プロンプトでは変えられないもの
確率分布の視点をつかむと、プロンプトでは解決できないこと もはっきり見えてきます。これを知っておくと、B3 に進む準備ができます。
プロンプトがやっていることは 「モデルがすでに知っていること」の確率分布を傾けること です。モデルがまったく知らないことは、傾ける分布がありません。これがプロンプトの根本的な限界です。
具体例を挙げます。
1. 学習データにない事実は、プロンプトでは教えられません。 「うちの会社の2026年4月の売上はいくら?」をいくらプロンプトで上手に包装して聞いても、モデルがうちの会社の売上を学習したことがなければ、答えられません。プロンプトに売上データを直接貼りつければ答えられますが、それは「プロンプトが教えた」のではなく、コンテキストに入れたデータを参照した だけです。これが RAG (Retrieval-Augmented Generation) が必要な理由です。外部データをプロンプトに動的にはさむ、ということですね。
2. モデルの根本的な性向は、プロンプトでは大きく変えられません。 Claude が安全ガイドラインで断る要求を、プロンプトでどれほどうまく誘導しても、基本は断ります。GPT が長い推論をするときのスタイルを、プロンプトで完全にちがうスタイルに変えるのはむずかしいです。モデルの重みそのものを変えるには、fine-tuning やもっと深い改造が必要です。
3. 長いコンテキストでの一貫性は、プロンプトだけでは限界があります。 100万トークン入れても、モデルがすべてのトークンに均等に注意を払うわけではありません。「Lost in the Middle」という現象のように、長いコンテキストの中間部分は注意が薄くなる傾向があります。これはプロンプトの構造を変えて、ある程度は緩和できますが (大事な指示を前後に繰り返すとか)、根本はアテンション機構の特性です。
4. 数値・計算の正確さは、プロンプトでは補正できません。 CoT を使っても、モデルが大きな桁の計算を完璧にやるわけではありません。複雑な計算は tool use で外部の計算機や Python を呼ぶほうが正確です。
ですから実務ではプロンプト・RAG・Fine-tuning が 互いに違う層のツール だ、という理解が必要です。
- プロンプト: モデルが知っていることを、ほしい方向に引っぱる層。
- RAG: モデルが知らない外部データを、プロンプトに動的に供給する層。
- Fine-tuning: モデルの重みそのものを、特定のドメインに合わせて調整する層。
この3つをいつ何を使うのかは、次回の B3 で詳しく扱います。いまは「プロンプトは万能ではないし、万能である必要もない」ということだけ、つかんでいきましょう。
10. 実務者チェックリスト — プロンプト設計で覚えておくべき5つ
理論を整理したので、実戦で使えるようにチェックリストに圧縮します。私自身、プロンプトを書くときにこの5つを頭の中でぐるぐる回しています。
1. いま組んでいるのは「条件」です。
プロンプトを書くときに「モデルにお願いする」気持ちで書くと、ついつい懇願口調になりがちです。そうではなく「モデルはこの条件のあとにどんなテキストが続く確率が高いかを計算する」という視点に切り替えてみてください。そうすると、条件に何を入れるか、に集中できるようになります。ペルソナ、フォーマット、例、制約、目的 — これらのパーツが、どれくらい密度を持って詰められているかを、自分で点検できるようになります。
2. ほしい出力に似たテキストが、学習データに多かったか、を想像してみてください。
「こういうスタイルの答えがほしい」と思ったとき、そのスタイルのテキストがインターネットに多かったか、を自問してみてください。多ければ zero-shot でも効く確率が高いです。まれだったり独特なスタイルなら、few-shot の例を入れて水路をはっきり引いてあげる必要があります。「技術ブログスタイル」は zero-shot でもいけますが、「テイラー風の技術ブログ」みたいに特殊なトーンは例が必要です。
3. 答えの「前に」何を書かせるかを設計してください。
CoT の核心的な教訓がここにあります。モデルが最終的な答えを吐く前にどんなテキストを書かせるかが、答えの質を決めます。複雑なタスクほど「根拠を先に書いて結論を出す」や「まず問題を整理し直してアプローチを選ぶ」のような中間ステップを、プロンプトに明示するのが効果的です。答えだけを引き抜こうとせずに、答えが出てくる経路 を設計してください。
4. 一度で完璧にはなりません。繰り返して調整してください。
私はプロンプトを一発で完成させようと頑張って失敗した経験がたくさんあります。いまは「とりあえず60%のものを投げて、答えを見て、何を足すか引くかを決める」というループを回しています。この反復が、プロンプトエンジニアリングの本当の作業スタイルです。一度に8本目の水路まで掘ろうとしないでください。一度に1本ずつ掘って、水がどこに行くかを見て、調整してください。
5. モデルと時点を記録してください。
あるプロンプトが効いたとき、どのモデルのどのバージョンで、いつ実験したかを記録で残しておいてください。GPT-4o 2026年4月バージョンで効いたプロンプトが、6ヶ月後には同じ名前の別バージョンで効きにくくなっているかもしれません。「万能プロンプト」を信じずに、「いまのモデルで検証されたプロンプト」だけを信じる習慣が、結局、時間を節約します。
この5つを頭に置いて Claude・ChatGPT のウィンドウを開くたびに1回ずつなぞっていただくと、1ヶ月後にはっきり違う感覚が生まれるはずです。私個人としては3番 (答えの前に何を書かせるか) がいちばん大きな転換でした。プロンプトの質問ひとつに悩んでいた時間が、半分になりましたから。
閉じのひとこと: プロンプトエンジニアリングは、文章をきれいに書く技術ではなく、条件付き確率分布をほしい方向に傾ける技術 です。Zero-shot も Few-shot も CoT も system prompt も「Let’s think step by step」も、名前だけちがう同じ軸のボタンです。この軸をつかんでいれば、プロンプトは暗記する呪文ではなく、設計する条件になります。
FAQ
Q1. 「プロンプトエンジニアリング」という職種は消える、という話もありますよね?
2つに分けてお答えします。「定型化されたプロンプトテンプレートを作る単純作業」 は、モデルがよくなるにつれてだんだん必要なくなる流れ、は合っています。初期の GPT-3 のころに必須だった冗長な指示文が、GPT-4o や Claude 3.5 ではかなり短くても済むようになりましたから。一方で 「ほしい出力のために条件を設計して反復調整する思考様式」 は、むしろもっと大事になってきています。エージェントシステムを組むには、system prompt、tool の説明、役割分担のプロンプトまで、数千トークン単位で設計しないといけないので。単純テンプレート職人ではなく、入力設計者 の役割に拡張されている、と見ていただくといいです。
Q2. Few-shot の例は、何個くらいが適切ですか?
タスクの難度とコンテキストの余裕によります。感情分類のようなシンプルなタスクなら2〜3個で十分です。フォーマットが複雑な JSON 変換や、スタイルがきびしいライティングなら、5〜10個必要になることもあります。一般的には 「例の数を増やしても出力品質がそれ以上上がらないところ」 までが、ちょうどいいラインです。それ以上増やすとプロンプト長が増えるだけで、効果は頭打ちになります。もうひとつ、例同士が 異なるパターンをカバーしているか が、個数よりも大事です。似た例10個より、多様な例4個のほうがいいことが多いです。
Q3. 「Let’s think step by step」は、いまでも効きますか?
原論文からずいぶん時間が経って、最新モデルはすでに内部で CoT を誘発するチューニングが入っています。ですのでこのフレーズ1行の効果は、昔ほど劇的ではありません。GPT-4o、Claude 3.5、o1 のような推論特化モデルは、複雑な問題を見ると自分で段階的に推論します。ただ シンプルなモデル (GPT-3.5 級) や シンプルなタスクでモデルが答えだけ吐こうとするとき には、まだ効きます。それに日本語・韓国語環境では「ステップバイステップで考えてみよう」「단계별로 생각해 보자」のような翻訳版も、似た効果があります。文脈にあわせて変形して使ってください。
- ◀ 前の編: B1. AIエージェントとLLMの分かれ目
- 今の編: B2. プロンプトはなぜ効くのか (9/20)
- ▶ 次の編: B3. Fine-tuning vs RAG vs Prompt
ニュースレターのご案内
こうしてひとつひとつの概念を最後まで解きほぐしていく記事を、毎週月曜日の朝にメールでお届けしています。受け取ってみたい方は ニュースレター会員登録(無料・30秒) からどうぞ。
著者: バイブコーディング テイラー(Lovable公式アンバサダー)
運営: テイラーの隠れ家(shuntailor.net)
プロンプトの仕組みの位置にある編です。前後編のリンクは記事下部のマップ上の現在地ボックスで確認してください。
プロンプトエンジニアリングは文章術ではなく確率分布を傾ける技術。Zero-shot·Few-shot·CoTがなぜ効くのかを条件付き確率で説明。
ソースリスト
- テイラー知識百科事典 — AIのしくみ地図カテゴリ（本シリーズ20編全編）
- AIのしくみ地図 エントリーマップ — 全体構造 + 3つの読み方
- “Attention Is All You Need” (Vaswani et al., 2017)
- Anthropic · OpenAI · Google 公式ドキュメント
- mathbullet (YouTube) / Jay Alammar “Illustrated Transformer” / 3Blue1Brown — 易しい解説のリファレンス
著者: バイブコーディング テイラー (VibeCoding Tailor) — Lovable公式アンバサダー. AI·バイブコーディング専門メディアshuntailor.net運営.
本シリーズ「AIのしくみ地図」20編は、ウィキの蓄積と公式論文・公式ドキュメントを根拠に整理した体系的学習カリキュラムです。
