7.5.5 Prompt 工学の実践

学習目標

1つの prompt がなぜ良くないのかを判断できるようになる
目的、制約、サンプル、出力形式の4つの方向から prompt を改善できるようになる
代表的なタスクで prompt がどう反復改善されるかを理解できるようになる
思いつきで書くのではなく、Prompt をデバッグする習慣を身につける

一、Prompt 工学で最もよくある誤解

誤解：prompt は「礼儀正しく書く」こと

実は、Prompt 工学が本当に気にするのは次の点です。

タスク定義が明確か
出力要件がはっきりしているか
制約が実行可能か
サンプルが十分に導けているか

礼儀正しいかどうかは、たいてい本質ではありません。

より正確な一言

Prompt は、モデルに渡すタスク用のインターフェース仕様書です。

もし仕様書があいまいなら、モデルの出力がぶれやすくなるのは当然です。

二、まずは「悪い prompt」を見てみよう

タスク：ユーザーコメントの感情分類

かなり良くない prompt は、たとえばこんな形です。

このコメントを分析してください。

どこが問題でしょうか？

何を分析するのか分からない
出力形式が分からない
ラベルの範囲が分からない
説明が必要か分からない

より明確なバージョンにする

以下のコメントの感情傾向を判定してください。positive または negative だけを出力し、それ以外は出力しないでください。

コメント：この授業はとても分かりやすく、例もたくさんあります。

このバージョンは一気に分かりやすくなります。なぜなら、次の点が明確だからです。

タスク：感情分類
出力集合：positive / negative
出力制約：余計な内容を出さない

三、Prompt デバッグの4つの重要な観点

タスクの目的は十分に明確か？

まず確認します。

モデルにやらせたいのは分類か、要約か、抽出か、書き換えか？

出力形式は十分に明確か？

次に確認します。

出力は1文か？
1つのラベルか？
JSON か？
表形式か？

制約は十分に明確か？

たとえば次のような制約です。

事実を捏造しない
余計な説明を出さない
与えられたテキストだけを根拠に答える

サンプルは十分に導いているか？

タスクによっては、説明だけでは不十分です。
その場合は few-shot のサンプルを足すとよいです。

この4つが、Prompt 実践の基本の流れです。

四、実行できる Prompt 練習器

以下の例は、実際の大規模モデルを呼び出すものではなく、「タスク仕様オブジェクト」を使って Prompt の要件を分解する練習です。

prompt_spec = {
    "task": "sentiment_classification",
    "allowed_labels": ["positive", "negative"],
    "output_format": "single_label",
    "constraints": ["説明を出さない", "ラベルだけを出力する"]
}

print(prompt_spec)

期待される出力：

{'task': 'sentiment_classification', 'allowed_labels': ['positive', 'negative'], 'output_format': 'single_label', 'constraints': ['説明を出さない', 'ラベルだけを出力する']}

この例はシンプルに見えますが、とても大事なことを教えてくれます。

良い prompt の背後には、たいていより明確なタスク仕様があります。

五、代表的なタスクでの Prompt 反復

タスク：テキスト要約

バージョン1：あいまい

この文章を要約してください。

問題点：

どのくらいの長さにするのか分からない
どんな文体にするのか分からない
要点を残すのか分からない

バージョン2：より具体的

以下のテキストを、日本語で3つの要点に要約してください。各要点は20字以内にしてください。

これでかなり良くなります。

バージョン3：境界も追加する

以下のテキストを、日本語で3つの要点に要約してください。各要点は20字以内にしてください。
本文にない情報は追加せず、事実だけを残してください。

この時点で prompt は、「答えられる」状態から「より安定して制御できる」状態へ進んでいます。

六、few-shot はいつ特に有効か？

言葉だけではタスク定義が十分に伝わらないとき

たとえば、ある文が次のどちらかを判定させたいとします。

fact
opinion

定義だけを与えると、モデルの理解が不安定になることがあります。
こういうとき few-shot のサンプルがとても役立ちます。

サンプル例

few_shot_examples = [
    {"input": "北京は中国の首都です。", "output": "fact"},
    {"input": "この授業はとても面白いです。", "output": "opinion"}
]

for ex in few_shot_examples:
    print(ex)

期待される出力：

{'input': '北京は中国の首都です。', 'output': 'fact'}
{'input': 'この授業はとても面白いです。', 'output': 'opinion'}

few-shot の役割は、単に「文章を増やすこと」ではありません。

モデルに「こう判断してほしい」という見本を示すことです。

七、構造化タスクの prompt はどう書くと安定する？

典型的な場面：情報抽出

ただ次のように書くだけだとします。

履歴書の情報を抽出してください。

この場合、モデルは次のような動きをしやすくなります。

抜けが出る
フィールド名がばらばらになる
説明を余計に付ける

より良いバージョン

以下の履歴書から情報を抽出し、JSON で出力してください。

フィールド：
- name: string
- school: string
- skills: list[string]

余計な説明は一切出力しないでください。

これで、タスク、構造、境界がすべて明確になります。

八、Prompt 実践での「最小実験」の習慣

一度にたくさん変えない

Prompt デバッグで最も避けたいのは、次のように全部まとめて変えることです。

タスク説明を変える
サンプルを変える
出力形式も変える

これでは、どの変更が効いたのか分からなくなります。

より良い進め方

1回に1つだけ変えます。たとえば：

まず出力制約だけを足す
次に few-shot を足す
その次に形式要求を変える

これは、モデルのハイパーパラメータ調整とよく似ています。

Prompt デバッグループ漫画

九、小さな Prompt 評価の例

まずテストサンプルを定義する

test_cases = [
    {"input": "この授業はとても分かりやすいです。", "expected": "positive"},
    {"input": "内容が少しごちゃごちゃしています。", "expected": "negative"}
]

for case in test_cases:
    print(case)

期待される出力：

{'input': 'この授業はとても分かりやすいです。', 'expected': 'positive'}
{'input': '内容が少しごちゃごちゃしています。', 'expected': 'negative'}

なぜこの手順が重要なのか？

Prompt 工学にも評価が必要だからです。
テストサンプルがなければ、「この prompt は良いのか」を感覚だけで判断することになります。

より成熟したやり方は次のとおりです。

入力集合を用意する
期待出力を用意する
prompt が安定して期待どおりか確認する

十、初学者がよくハマる落とし穴

出力を明確に定義せずに prompt を書く

これをやると、後処理がどんどん大変になります。

prompt の改善はひらめきだけでできると思う

実際は普通の工学的デバッグに近いです。小さな実験をして、結果を見て、少しずつ直していきます。

1つの成功例だけを見る

1例だけうまくいっても、その prompt が安定しているとは限りません。

残す証拠

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

ベースラインのプロンプト: 1 つ目の版とその失敗
変更変数: 一度に 1 つの Prompt 次元だけを変更
スコア: 簡単な合否またはルーブリック結果
失敗バケット: 指示、文脈、形式、または曖昧さ
次の反復: 試す具体的な修正を1つ

まとめ

この節で一番大事なのは、Prompt 技巧をたくさん覚えることではありません。
次のような習慣を身につけることです。

Prompt をタスクのインターフェースとして設計し、システムの部品としてデバッグする。

タスクの目的、形式、制約、サンプルに沿って改善を重ね、感覚で1文を書くのではなくなったとき、Prompt 工学は本当に成熟し始めます。

練習

自分がよく知っているタスクを1つ選び、「悪い prompt」をまず書き、そのあと少しずつ良いバージョンに直してみましょう。
「感情分類」タスクに few-shot 版を追加してみましょう。
「テキスト要約」タスクを、JSON などの構造化出力形式に変えてみましょう。
自分の言葉で説明してみましょう。なぜ Prompt 工学は「良い言い回しを書くこと」ではなく、「タスクのインターフェースを設計すること」なのでしょうか？

参考実装と解説

悪い prompt は「分析して」のように曖昧です。よい版では task、input、expected output、label、constraint、少なくとも 1 つの failure boundary を書きます。
few-shot 版には positive、negative、neutral の代表例を含め、新しい case も同じ label format で答えさせます。
structured summary は {"summary": "...", "key_points": ["..."], "risks": ["..."], "missing_info": ["..."]} のようにできます。
Prompt 工学は interface design です。model と surrounding system の間で、input、output、constraint、validation expectation、failure handling を定義するからです。