プロンプトエンジニアリング
プロンプトエンジニアリングとは
プロンプトエンジニアリングは、[[生成AI・LLM]] への指示文を設計・改善して望む出力を安定して得る技術です。同じモデルでも指示の書き方ひとつで出力の質が大きく変わるため、「AIをうまく使える人」と「使えない人」の差はほぼここで生まれます。
LLMを用途に寄せる手段は、手軽な順に プロンプト → 検索して渡す → 追加学習する の3段階です([[RAG(検索拡張生成)]]、[[ファインチューニング]])。プロンプトだけは基盤も学習データも要らず、書き直せばその場で結果が変わります。まず試し、限界を見極めてから次の段へ進むのが定石です。
プロンプトの部品
一枚の文章に見えるプロンプトも、役割の違う部品でできています。名前を分けると「どこを直すか」が決まります。アプリに組み込むときは部品ごとに別の変数として持ちます。
| 部品 | 役割 |
|---|---|
| システムプロンプト | 役割・口調・禁止事項など、会話全体に効き続ける前提 |
| ユーザープロンプト | その回に実行してほしい依頼 |
| コンテキスト | 判断材料として渡す資料や履歴。上限は [[コンテキストウィンドウ]] |
| 出力仕様 | 形式・長さ・条件。JSON などに固定することが多い |
定番パターン
| パターン | 内容 | 例 |
|---|---|---|
| 役割設定 | 立場・専門性を与える | 「あなたは経験豊富なレビュアーです」 |
| 形式指定 | 出力の型を決める | 「表形式で」「JSON で」「3行以内で」 |
| 例示 | 見本を見せる | 「例: 入力A → 出力B。では入力C は?」 |
| 段階的思考 | 手順を踏ませる | 「ステップごとに考えてから結論を出して」 |
| 制約の明示 | してほしくないことを書く | 「推測で答えず、不明なら不明と言って」 |
例示を数個見せる方法は few-shot、見せない方法は zero-shot、手順を書かせてから答えさせる指示は Chain of Thought と呼ばれます。
上達のコツ
- 曖昧語を消す: 「いい感じに」「適切に」はモデルの解釈任せになる。具体的な条件・数値・形式に置き換える
- 入力と指示を分ける: 対象データと指示文の境界を明確にする(区切り記号や「以下の文章を〜」)
- 一度に1つずつ: 大きな依頼は分割する。要約→翻訳→整形を1プロンプトに詰めない
- 反復改善: 出力を見て指示を直すループを回す。1回で完璧を狙わない
開発での位置づけ
アプリに LLM を組み込むとき、プロンプトはコードの一部になります。
- プロンプトをテンプレート化し、コードと同じように [[Git]] でバージョン管理する
- 出力形式を JSON などに固定してパースし、崩れたときの再試行も設計する(生成は確率的 — [[推論パラメータと出力のばらつき]])
- 関数と引数まで構造化して出させるなら [[Function Calling]]、ループで回すのが [AIエージェント]
プロンプトでは解けないこと
指示を磨いても届かない領域があります。見誤ると書き換えループに時間を溶かします。
- モデルが知らない情報 — 社内文書や最新の出来事は工夫では出てこない。渡す構成が [[RAG(検索拡張生成)]]
- 文体や振る舞いの定着 — 毎回の指示で足りなくなったら [[ファインチューニング]] の領域
- 事実の正しさ — 「推測しない」と書いても [[ハルシネーション]] は消えない。検証の工程で受ける
- 完全に同じ出力 — 文面は必ず揺れる([[推論パラメータと出力のばらつき]])。一致が要る計算はコードへ寄せる
- 悪意ある入力 — 資料に紛れた指示に従う [[プロンプトインジェクション]] は書き方では防げない
関連技術とのつながり
- [[生成AI・LLM]] — プロンプトが入力される先。トークンやハルシネーションの性質を踏まえて書く
- [[トークンとトークナイザ]] — 指示も資料もこの単位で数え、料金と長さの上限に効く
- [[LLMアプリの評価とテスト]] — 直したプロンプトが改悪になっていないかを確かめる手段
- [[AIコーディング支援]] — 開発作業に適用したときの効き方と落とし穴
- [[Human-in-the-Loop]] — 指示で担保しきれない部分を人の確認で受ける運用設計
Q: few-shot プロンプトとはどんな手法?
- [ ] 短い指示だけで済ませる手法
- [x] 入力と出力の例をいくつか見せてから本番の入力を渡す手法
- [ ] 複数のモデルに同じ質問をする手法
解説: 見本(shot)を数個示すことで、モデルが出力の形式や基準を真似できるようになります。
Q: プロンプト改善として適切なのはどれ?
- [ ] 「いい感じにまとめて」と依頼する
- [x] 「3行以内で、専門用語を使わずにまとめて」と条件を具体化する
- [ ] 同じ指示を2回繰り返して書く
解説: 曖昧語を具体的な条件・数値・形式に置き換えるのが改善の基本です。
Q: アプリにLLMを組み込むときのプロンプトの扱いとして適切なのはどれ?
- [x] テンプレート化してコードと同様にバージョン管理する
- [ ] 毎回その場で手書きする
- [ ] 一度書いたら二度と変更しない
解説: プロンプトは挙動を決めるコードの一部なので、管理・改善・テストの対象にします。
Q: 社内の最新資料に基づいて答えさせたいとき、本文が指示の工夫より適切としている手段はどれ?
- [ ] few-shot の例示を10件まで増やす
- [x] 文書を検索して入力として渡すRAGの構成にする
- [ ] 出力形式をJSONに固定する
解説: モデルが知らない情報は指示では補えません。手軽な順にプロンプト→RAG→ファインチューニングと進めるのが定石です。