7.5.2 Prompt 基礎

Prompt の改善前後比較カード

学習目標

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

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

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

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

まずは地図を作る

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

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

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

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

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

flowchart LR
    A["タスク目標"] --> B["出力形式"]
    B --> C["制約条件"]
    C --> D["より安定したモデル出力"]

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

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

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

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

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

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

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

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

とても直感的なたとえ

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

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

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

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

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

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

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

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

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

目的
形式
境界

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

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

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

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

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

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

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

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

典型的な悪い例

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

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

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

少しわかりやすい版

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

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

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

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

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

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

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

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

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

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

第 1 層：タスク目標

まず次に答えます。

モデルは何をすべきか？

たとえば。

要約
分類
抽出
言い換え

第 2 層：出力形式

次に答えます。

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

たとえば。

一文
3 つの bullet
JSON
表

第 3 層：制約条件

最後に答えます。

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

たとえば。

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

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

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

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

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

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

初めて 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 三層タスク仕様図

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

あいまい版

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

明確版

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

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

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

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

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

正確に言うこと。

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

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

構造化出力
関数呼び出し（関数呼び出し）
エージェント（Agent）
RAG

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

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

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

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

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

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

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

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

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

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

制約を書かない

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

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

いちばん見せる価値があるのは、「Prompt が書けます」という一言ではなく、次のような具体的な変化です。

悪い Prompt
改良した Prompt
どの仕様を補ったか
なぜその結果、出力が安定したのか

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

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

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

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

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

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

九、重要なポイント

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

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

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

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

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

この節の学習の確認

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

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

残す証拠

このページを終えたら、この証拠カードを残します。

タスク: 1 つの明確な指示
文脈: モデルに与える関連情報
制約: 対象、長さ、文体、禁止事項
出力形式: 箇条書き、JSON、表、または回答スキーマ
比較: 不明確な Prompt と改善後 Prompt の出力を保存したもの

まとめ

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

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

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

練習

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

解法と解説

例：「次の customer message を 3 つの bullet に要約し、user intent を判定し、返信案を 1 つ出してください。原文にない事実は作らないでください。」
完全な答えでは、goal、output format、constraint を分けます。例：goal は feedback classification、output は JSON、constraint は固定 label のみで余分な text を出さないことです。
Prompt は task brief に近いです。model に何をするか、どんな結果を出すか、どんな boundary を守るかを伝えるからです。
output format がないと、model は prose、bullet、JSON-like text、混合形式で答える可能性があります。downstream use と evaluation が不安定になります。