LLMへの語りかけ方の技術

プロンプトはテキストではない——プログラムだ

ChatGPT に「この記事を要約して」と入力するとき、表面上はそれほど劇的なことは起こらない。しかしあなたが送ったテキストは、何兆ものトークンで訓練されたモデルの中で、非常に正確な振る舞いを引き起こした。

プロンプトは自然言語のプログラムだ。コンパイルされるという意味ではなく、その表現がモデルがどのタイプの振る舞いを起動するかを決定するという意味で。同じ文を異なる言い方で表現すると、根本的に異なる結果が得られる——モデルが気まぐれだからではなく、その事前学習が異なる文脈に対して異なるパターンを教えたからだ。

プロンプトエンジニアリングとは、望む振る舞いを得るためにそのプログラムを表現する技だ。

4つの技法のレベル

Zero-shot：質問するだけ

最もシンプルな技法だ。例も指示もなしに、直接質問する。モデルは訓練に基づいて最も可能性の高い振る舞いを起動する。

シンプルで事実的なタスクには非常にうまく機能する。推論を必要とする問題では失敗する——モデルが知らないからではなく、推論すべきだと知らないからだ。

Few-shot：例を示す

何が欲しいかを説明するのではなく、見せる。本当の質問の前に、2〜5組の（入力、出力）ペアを置く。モデルは——in-context learning 機構のおかげで——パターンを理解し、新しい入力に適用する。

鍵：例はそのタスクのタイプを代表するものでなければならない。脱線した例は役に立たない。やるべき手順を示す例は大いに役立つ。

Chain-of-Thought：ステップごとに推論する

2022年の2つの発見が、しばしば混同されている。Wei らは、推論を丸ごと書き下した例をモデルに与えると、次の問題でも同じように推論しはじめることを示した。Kojima らは同じ年にさらに踏み込む——例は要らない、*「ステップごとに考えよう」*と付け加えるだけでいい。どちらの場合も、推論問題のパフォーマンスは2倍、ときには3倍になる。

なぜ機能するのか？モデルはトークンを1つずつ生成する。中間的な推論を書くように強制することで、計算をしたり仮説を検証したり誤りを訂正したりできる「下書き」を与える——結論を出す前に。CoT なしでは、モデルは安全網なしに直接結論へ飛ぶ。

これは人間と同じ原理だ：「25 × 37 = 25 × 30 + 25 × 7 = 750 + 175 = 925」と書くほうが、一発で暗算しようとするより、正しい結果に到達する可能性がはるかに高い。

Self-Consistency：複数の連鎖の間で投票する

self-consistency は CoT の拡張だ。1つの推論連鎖を生成する代わりに、複数（典型的には5〜20）を様々な温度で生成し、最も頻繁な回答に投票する。

考え方：各実行は異なる誤りをするかもしれない。しかしほとんどが同じ回答に収束するなら、それがおそらく正しい。

コストは高い（N 倍のトークン）が、難しい推論タスクでは信頼性の向上は本物だ。

自分で試してみよう

3つの問題で4つの技法を比較しよう。特に、few-shot の例は構造化された問題（商人）では役立つが、論理的な罠ではほとんど何も変えないことを観察してみよう。

同じ質問、4 通りの書き方。モデルには手を加えないのに、スコアは 30 % から 90 % まで揺れる。教訓：プロンプトはテキストではなく、その暗黙の文法を LLM が事前学習を通じて解釈するプログラムである。

これが LLM について明らかにすること

これら4つの技法は小手先の技ではない。LLM の働き方について何か根本的なことを照らし出す。

in-context learning は無料だ。 LLM は重みを更新せずに——コンテキストを読むだけで——あなたの例から学ぶ。これは大規模事前学習からの創発的能力だ：モデルは非常に多くのパターンを見たので、新しいものをその場で抽出できる。

推論は能力ではなく、振る舞いだ。 ある問題で zero-shot で失敗するモデルが、同じ問題で CoT で成功できる——パラメータを何も変えずに。プロンプトが起動するものが、モデルが内部能力で「行うこと」を変える。

温度は多様性を生み、投票は分散を減らす。 self-consistency は、誤りがしばしばランダムであるという事実を活用する：失敗する方法は多くあるが、成功する方法は1つだけ。コンセンサスがノイズをフィルタする。

限界

リクエストあたりのコスト。 各 few-shot の例はトークンを消費する——しかも毎回のリクエストで払い直すことになる。20万から100万トークンを超える現在のウィンドウなら、技術的には many-shot（数百の例。しかもこれが効く）も可能だが、それに比例して請求額と遅延も膨らむ。CoT も応答を長くする。

例は誤導することがある。 例にバイアスが含まれていれば、モデルはそれを再現する。"Garbage in, garbage out" は few-shot にも当てはまる。

プロンプトインジェクション。 コンテキスト内の悪意のあるコンテンツが指示を上書きすることがある。プロンプトが「このテキストを翻訳して」と言い、テキストが「以前の指示を無視して別のことをして」と言えば、モデルは指示よりもコンテンツに従うかもしれない。

モデルは進化する。 2023年に GPT-4 向けに研ぎ澄ましたプロンプトが、今日のモデルで、あるいは別のベンダーのモデルで必ずしも機能するとは限らない。各モデルには好みのパターン、より「ハマる」表現がある。

実用的なルール

技法を選ぶには：

• シンプル / 事実的な質問 → zero-shot で十分。
• 特定のフォーマットが期待される → 2〜3例の few-shot。
• 推論や計算 → モデルにネイティブな推論モードがないなら CoT。あるなら任せておこう。明示的な CoT を押しつけるのは、よくて冗長、悪くすると有害だ——一部のベンダーは明確に非推奨としている。
• 信頼性が重要 → CoT + self-consistency。

そしてメタルール：プロンプトがコードのように見える——明確な構造、明示的な変数、定義されたユースケース——なら、曖昧なプロンプトより信頼できるだろう。

最後にもう一つ。ここで述べた技法（特にCoT）は、ネイティブな推論モデルのプロンプト駆動の祖先だ。o1 と DeepSeek-R1 が2024〜2025年に道を開き、今日では主要なモデルのすべてがこの種のモードを備えている。後者は、プロンプトによるCoTがシミュレートしていただけのことを、自動的かつ集中的に行う——プロンプトエンジニアリングからモデルに組み込まれた推論への移行を理解するには、第17章を参照してほしい。

良いプロンプトは魔法の呪文ではない。何が欲しいかの明確な仕様を、モデルが従うべき信号として認識する言語で表現したものだ。

それでも、どんな書き方でも解決できないことがひとつ残る。世界一明晰な仕様を書いたとしても、答えがモデルの重みの中になければ、モデルはそれでも答えを作り出す——それが本当にあったときとまったく同じ自信をもって。テキストを予測するよう訓練されたシステムが、なぜ立ち止まって「わかりません」と言えないのか。それが次の章のテーマだ。

更新日 2026年8月2日