女性向けエンジニアスクール
3秒でわかる
生成 AI への指示文を設計し、狙った出力を安定して得るための技術。前提と形式と例を渡す設計作業で、思い付きの言い換えとは別物です。
30秒図解
もう少し詳しく
どういうものか
大規模言語モデルに渡す指示文を設計し、必要な出力が安定して返る状態を作る技術です。うまい言い回しを探す作業に見えますが、実際にやっていることは、モデルが持っていない前提を渡し、出力の形式を決め、判断がぶれる境界を例で示す、という設計に近い作業です。
モデルは相手の状況を知りません。想定読者、使う場面、避けたい表現、出力の長さといった情報は、書かなければ存在しないものとして扱われます。曖昧な指示に対して曖昧な答えが返るのは、モデルの能力ではなく入力の不足によることがほとんどです。
なぜ必要か
同じモデルでも、指示の作り方で結果の質は大きく変わります。「この文章を要約して」と投げた場合、長さも観点も相手の指定に委ねることになり、毎回違う粒度の答えが返ってきます。業務で使うなら、同じ入力に対して同じ形の出力が返ることが前提になるため、出力の形を先に固定する必要があります。
さらに、アプリケーションに組み込む場合は指示文がそのままコードの一部になります。後から挙動を直す作業は、プログラムのデバッグと同じ性格を持ちます。
具体例
役割、前提、制約、出力形式、悪い例の 5 つを分けて書くと再現性が上がります。
あなたは新人研修の講師です。
# 前提
- 読み手はプログラミング歴 1 か月の社会人
- 業務で Python を使い始めたところ
# タスク
以下の<a href="/glossary/error-message" class="text-primary font-medium underline underline-offset-2 hover:text-primary-dark">エラーメッセージ</a>が出た原因を説明する
# 制約
- 400 文字以内
- 専門用語を使う場合は初出時に言い換えを添える
- 修正コードは提示しない。原因の説明だけ
# 出力形式
1. 何が起きているか
2. なぜ起きたか
3. 確認すべき箇所
# 入力
TypeError: unsupported operand type(s) for +: 'int' and 'str'つまずきやすいところ
否定形の指示だけを並べても効きが弱くなります。「箇条書きにしないで」より「200 文字の段落 1 つで」と書いたほうが、望む形に近づきます。禁止だけを伝えると、許される範囲が広すぎて解釈が定まりません。
長い指示文を書くほど良いと考えるのも誤りです。関係の薄い情報を大量に混ぜると、本当に守ってほしい制約が埋もれます。効いていない行を削る作業も設計の一部です。
そして、モデルは事実を作り出すことがあります。指示の工夫だけでは防ぎきれないため、正確さが必要な用途では根拠となる文書を一緒に渡す構成に切り替えます。
似た用語との違い
ファインチューニングはモデルの重み自体を追加学習で作り変える手法で、費用も準備するデータ量も桁が違います。指示文の設計は重みを触らず、入力側だけで挙動を変えます。まず指示の設計で届く範囲を確かめ、それでも足りない場合に学習を検討する、という順序が現実的です。
