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

7.5.5 Prompt 工学の実践

この節の位置づけ

前のいくつかの節では、すでに次の内容を学びました。

  • Prompt の基礎
  • 高度なテクニック
  • 構造化出力

この節では新しい用語を増やすのではなく、もっと大事なことをします。

Prompt を工学的な対象として練習する。

つまり、「この 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つだけ変えます。たとえば：

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

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

Prompt デバッグループ漫画

図の読み方

Prompt デバッグは、勘で直す作業ではなく、工学的な調整として考えます。テストケースを用意し、一度に一層だけ変え、同じケースで再実行し、合否を比較し、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 が安定しているとは限りません。

まとめ​

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

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

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

練習​

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