メインコンテンツへスキップ

7.5.2 Prompt 基礎

Prompt の改善前後比較カード

この節の位置づけ

多くの人は Prompt を初めて学ぶと、次のように捉えがちです。

  • きれいな言い回しが書けるか
  • 何か不思議な言い回しを使えるか

でも、本当に大事なのは次の問いです。

あなたはタスクをきちんと説明できているか。

Prompt エンジニアリングの基礎は、修辞ではなくタスクの伝え方です。

学習目標

  • Prompt が本当に制御しているものを理解する
  • なぜあいまいな Prompt でモデルの出力がぶれやすくなるのかを理解する
  • タスク目標、出力形式、制約条件の 3 層で、より安定した Prompt を書けるようになる
  • Prompt デバッグの最も基本的な直感を身につける

初学者はまず押さえる / 上級者はあとで理解する

もしあなたが初学者なら、この節ではまずこの一文をつかんでください。Prompt は「呪文」ではなく、タスクの説明書です。まず「何をするのか、どういう形で出力するのか、何をしてはいけないのか」の 3 つをはっきり書くことが、たくさんのテクニックを覚えるよりも大切です。

すでに経験があるなら、さらに次の点にも注目できます。Prompt はプログラムから安定して解析できるか、モデルの暴走を防げるか、構造化出力や Function Calling、RAG、Agent の実行パイプラインにつなげられるか、という視点です。


まずは地図を作る

すでに大規模言語モデルの全体像や事前学習の流れを学んでいるなら、この節は自然な続きになります。

  • これまでに、モデルの能力がどこから来るのかを学んだ
  • この節では、不変のままモデルのパラメータを変えずに、その能力をどうやってより安定して引き出すかを考える

つまり Prompt 基礎は「小技」ではなく、次の問いに答えるものです。

  • どうすれば、より明確なタスク表現によって、すでにあるモデル能力を安定して引き出せるのか

Prompt 基礎の理解で、初学者にいちばん向いている順番は「先にいくつかのテクニックを覚える」ことではありません。まず、次の構造をはっきり見てください。

この節が本当に解決したいのは、次の点です。

  • タスクは本当にきちんと伝わっているか
  • モデルは、最終的にどんな形で納品すべきか理解しているか
  • どの境界条件を先に固定しておくべきか

一、Prompt とはそもそも何か?

単なる「文字列の入力」ではない

表面的には、Prompt はもちろんモデルに入力するテキストです。
でも、エンジニアリングの視点から見ると、もっと次のようなものに近いです。

モデルに書くタスク説明書。

Prompt を通して、あなたがモデルに伝えているのは次の内容です。

  • 今回のタスクは何か
  • どんな形式で出力してほしいか
  • どんな境界を守る必要があるか

とても直感的なたとえ

Prompt は、新しく入った同僚に仕事を頼むときの指示に似ています。

  • 目的ははっきりしているか
  • 納品形式ははっきりしているか
  • やってはいけないことを伝えているか

これらがあいまいだと、結果は簡単にずれてしまいます。
モデルも同じです。

初学者により合う大きなたとえ

Prompt は次のようにも理解できます。

  • とても優秀だけれど、心を読めないインターンに仕事を頼む

このインターン自体の能力は悪くありません。
でも、もしあなたがただ

  • 「ちょっとこれ、お願い」

と言っただけなら、結果はかなりぶれやすくなります。
問題は相手が賢くないことではなく、
あなたが

  • 目的
  • 形式
  • 境界

をちゃんと伝えていないことにあります。

初めて Prompt を学ぶとき、まず何を押さえるべきか?

まず押さえるべきなのは、流行りの型ではありません。次の一文です。

Prompt の本質は、タスク仕様をモデルが実行できる説明に変換すること。

この一文がしっかりすると、あとで

  • few-shot
  • ロール設定
  • 構造化出力

を見たときも、まず次のように考えやすくなります。
それはタスク目標を補っているのか、出力形式を補っているのか、それとも行動の境界を補っているのか。


二、なぜ「曖昧な Prompt」は特に危ないのか?

典型的な悪い例

この内容をちょっと処理してください。

この文の問題は、丁寧さではありません。問題は次の点です。

  • 要約してほしいのか?
  • 言い換えてほしいのか?
  • 分類してほしいのか?
  • どれくらいの長さで出せばいいのか?

少しわかりやすい版

以下の内容を 3 つの日本語の要点に要約してください。各要点は 20 文字以内にしてください。

これで一気に明確になります。

  • 何をするか:要約
  • 出力形式:3 つの要点
  • 出力の長さ:各要点 20 文字以内

これが Prompt のいちばん基本的な価値です。

曖昧なタスクを、明確なタスクに変えること。

「悪い Prompt -> 良い Prompt」の最小比較表

Prompt問題または良い点
悪い版この内容をちょっと処理してください。タスク、形式、境界がどれも不明確
少し良い版この内容を要約してください。要約することはわかるが、形式がまだ不明確
より安定した版以下の内容を 3 つの日本語の要点に要約してください。各要点は 20 文字以内にし、原文にない情報は追加しないでください。タスク、形式、制約が明確

この表は初学者にとても向いています。なぜなら、次のことが見えるからです。

  • Prompt が安定するのは、不思議な言葉のおかげではない
  • 仕様がより明確になるから安定する

三、Prompt を書くときのいちばん基本的な 3 層構造

第 1 層:タスク目標

まず次に答えます。

  • モデルは何をすべきか?

たとえば。

  • 要約
  • 分類
  • 抽出
  • 言い換え

第 2 層:出力形式

次に答えます。

  • 出力はどんな形であるべきか?

たとえば。

  • 一文
  • 3 つの bullet
  • JSON

第 3 層:制約条件

最後に答えます。

  • どの境界を越えてはいけないか?

たとえば。

  • 事実を作らない
  • 説明文を出さない
  • 与えられた資料だけで答える

この 3 層が、Prompt エンジニアリングの最も基本的で、最も大切な骨組みです。

なぜこの 3 層構造を最初に覚える価値があるのか?

一見「よく書けている」Prompt でも、最後に安定しないことがあります。
その原因は、たいてい次のどれかです。

  • タスク目標があいまい
  • 出力形式が書かれていない
  • 制約条件が抜けている

だから初学者の最初の一歩は、テクニックを積むことではなく、この 3 層をまず書き切ることです。

初めて Prompt を書くときの、いちばん安定した順番

より安定しやすい順番は通常こうです。

  1. まず「何をするか」を書く
  2. 次に「どんな形で出すか」を書く
  3. その次に「何をしてはいけないか」を書く
  4. 最後に語気、スタイル、ロールを調整する

こうすると、最初から

  • あなたはベテランの専門家です...

のようなロール設定を書くよりも安定しやすいです。
なぜなら、いちばん土台になるタスク仕様が先に固まるからです。

Prompt 三層タスクブリーフ漫画

図の読み方

この図は、小さな職場の物語として読むと分かりやすいです。あいまいな依頼ではモデルが推測してしまいますが、明確なタスクブリーフなら、目標、納品形式、境界を渡せます。よい Prompt は魔法の言葉ではなく、明確なタスクカードに近いものです。


四、最小の Prompt 仕様例

prompt_spec = {
"task": "summary",
"output_format": "3 つの日本語の要点",
"constraints": ["各要点は 20 文字以内", "原文にない情報は追加しない"]
}

print(prompt_spec)

期待される出力:

{'task': 'summary', 'output_format': '3 つの日本語の要点', 'constraints': ['各要点は 20 文字以内', '原文にない情報は追加しない']}

この例は何を教えているのか?

この例が伝えているのは次のことです。

見た目には自然な Prompt でも、その裏には、もっと明確なタスク仕様がある。

つまり Prompt は、ひらめきだけで書くものではありません。
むしろ、タスク仕様をモデルが理解できる言葉に変換する作業です。

最小の「Prompt チェックリスト」の例

prompt_checklist = {
"task_defined": True,
"output_format_defined": True,
"constraints_defined": False,
}


def next_fix(checklist):
if not checklist["task_defined"]:
return "まずタスク目標をはっきり書いてください。"
if not checklist["output_format_defined"]:
return "まず出力形式をはっきり書いてください。"
if not checklist["constraints_defined"]:
return "まず境界と制約条件を追加してください。"
return "基本的な Prompt 仕様はかなり整っています。"


print(next_fix(prompt_checklist))

期待される出力:

まず境界と制約条件を追加してください。

この例は初学者に向いています。Prompt を「一文を書くこと」ではなく、次のようなものとして捉え直しているからです。

  • チェック可能なタスク仕様

Prompt 三層タスク仕様図

図の見方

この図では Prompt を 3 層に分けています。タスク目標、出力形式、制約境界です。初学者は、まずロール設定や高度なテクニックを足す前に、この 3 つがちゃんと書かれているかを確認してください。安定しない出力の多くは、実はタスク仕様のどこか 1 層が抜けているだけです。


五、違いが本当に見える例

あいまい版

以下の文章を分析してください。

明確版

以下の文章を読み、感情分類を行ってください。
positive または negative だけを出力し、それ以外の説明は出さないでください。

なぜ後者のほうが安定するのか?

それは、次の点が同時に明確だからです。

  • タスク目標:感情分類
  • 出力集合:positive / negative
  • 出力の制約:余分な説明をしない

だから Prompt の本当の基礎は「それっぽく言うこと」ではなく、次のことです。

正確に言うこと。


六、Prompt 基礎はなぜ後のすべての章に効くのか?

このあと学ぶ内容には、たとえば次のようなものがあります。

  • 構造化出力
  • Function Calling
  • Agent
  • RAG

これらはより複雑ですが、どれも共通して同じ前提を持っています。

  • タスクの境界が明確であること
  • 出力形式が明確であること
  • 行動の制約が明確であること

つまり Prompt 基礎は独立した章ではなく、後の多くのシステム能力の土台です。

このあと何度も出てくる用語

用語初学者向けの意味Prompt 基礎とのつながり
Promptモデルに渡す指示、文脈、例、制約モデルへのタスクブリーフなので、曖昧だと挙動も曖昧になる
構造化出力JSON、表、固定フィールドなど、予測しやすい形式で出すことプロダクトでは、きれいな文章だけでなく、解析できるデータが必要になる
Function Callingモデルがツールや関数を選び、引数を埋める仕組みモデルはタスク境界と必要なパラメータを理解している必要がある
RAGRetrieval-Augmented Generation。外部資料を検索し、その資料に基づいて回答する方法Prompt が、検索結果の使い方と根拠のない主張を避けるルールを伝える
Agentモデルが計画し、ツールを呼び、結果を観察しながら実行を続けるシステム各ステップに明確な目標、許可された行動、停止条件が必要になる

七、初学者がよくやる誤解

Prompt は言い回しの改善だけだと思う

実際には、もっと大切なのはタスク構造です。

タスクだけ書いて、出力形式を書かない

これだとモデルの出力が不安定になりやすく、後処理も大変になります。

制約を書かない

モデルには自由度があると、自由にしてはいけない場面で自由にしてしまいやすいです。

これをプロジェクトやノートにするなら、何を見せるとよいか

いちばん見せる価値があるのは、次のようなものです。

  • 「Prompt が書けます」ではなく
    1. 悪い Prompt
    1. 改良した Prompt
    1. どの仕様を補ったか
    1. なぜその結果、出力が安定したのか

こうすると、見る人はより理解しやすくなります。

  • あなたが理解しているのはタスクの伝え方だ
  • ただ Prompt のテクニック名を覚えただけではない

八、初めて Prompt を書くときの、いちばん安定した順番

そのまま次の順で書けば大丈夫です。

  1. まずタスク目標を書く
  2. 次に出力形式を書く
  3. 次に制限条件を書く
  4. 最後に言い回しやスタイルを整える

こうすると、最初からロール設定やテクニックを盛るより、ずっと安定しやすくなります。

九、重要なポイント

  • Prompt の本質は修辞ではなく、タスクの伝え方
  • 基礎 Prompt では、「何をするか、どう納品するか、何をしてはいけないか」をはっきりさせる
  • その先にある高度な Prompt、構造化出力、Agent も、すべてこの土台の上に成り立っている

十、とても実用的な Prompt の書き方の習慣

毎回 Prompt を書く前に、心の中で次の 3 つを自問してください。

  1. 自分は本当にモデルに何をさせたいのか?
  2. どんな形で出力してほしいのか?
  3. どんなズレがいちばん困るのか?

この 3 つに答えられれば、Prompt はたいてい、思いつきで書いたものよりずっと安定します。


この節の学習の確認

この節を学び終えたら、次の表で自分をチェックできます。

できるようになっていること
直感なぜ Prompt は「魔法の呪文」ではなく、タスク説明書に近いのかを説明できる
書き方あいまいな依頼を、タスク目標・出力形式・制約条件に分解できる
デバッグ出力が不安定なとき、それが目標のあいまいさなのか、形式の不足なのか、境界の抜けなのかを判断できる
次への接続Prompt がなぜ構造化出力、Function Calling、RAG、Agent に影響するのかを説明できる

まとめ

この節でいちばん大事なのは、「Prompt」という言葉を覚えることではなく、次を理解することです。

Prompt の本質は、タスク目標、出力形式、境界条件をはっきり表現すること。

これが、後に続くすべての Prompt エンジニアリング能力の最初の土台です。


練習

  1. 「この内容をちょっと処理してください」を、もっと明確な Prompt に書き換えてください。
  2. 自分のタスクを 1 つ考え、タスク目標、出力形式、制約条件をそれぞれ書いてください。
  3. 自分の言葉で説明してください。なぜ Prompt は「タスク説明書」に近いと言えるのですか?
  4. なぜ、Prompt に目標だけを書いて出力形式を書かないと、システムは不安定になりやすいのでしょうか?