Prompt Engineeringとは — 指示を評価可能な形で改善する

Prompt Engineeringは、モデルへ渡すInstruction、例、制約、出力条件を設計し、実際の結果を評価しながら改善する工程です。対象タスクの成功条件を決め、複数の入力で試し、失敗を分類し、変更前後を比較します。

一度うまく答えたPromptを見つけると、完成したように感じます。ただ、一件の成功だけでは、本番の入力に耐えられるか分かりません。

Promptを書く前に成功条件を決める

AnthropicのPrompt Engineering Overviewは、Prompt Engineeringを始める前提として、明確な成功基準、経験的に試す方法、改善対象となる初稿を挙げています。

要約機能なら「読みやすい」だけでは比較できません。

固有名詞と数値を保てたか
指定した文字数に収まったか
根拠にない主張を追加していないか
禁止した情報を出力していないか
JSON Schemaに適合したか
レイテンシとToken使用量が許容範囲か

何を成功とするかで、Promptの改善方向は変わります。基準がないまま文言を足すと、良くなったのか、別の入力を壊したのか判断できません。ここを曖昧なまま始めると、調整がだいぶ長引きます。

一件の成功ではなく評価セットで比べる

MermaidPrompt改善のEvaluation loop評価結果から限定的なPrompt修正へ戻る反復工程

Prompt改善はSuccess criteriaを起点にDraftとEvaluation setを作り、失敗を観察して1つの変更だけを加える反復です。変更後は同じEvaluation setへ戻すため、改善と退行を比較できます。

Success criteriaを定めてDraft promptとEvaluation setを用意します。
Evaluation結果からFailureを分析します。
1回に1つの範囲へ限定して修正し、同じEvaluation setで再評価します。

評価セットには、通常入力だけでなく、空値、長文、曖昧な依頼、矛盾した条件、攻撃的な入力も含めます。実際の利用ログから見つかった失敗を、匿名化したうえで回帰ケースへ戻します。

一度に複数箇所を変えると、どの変更が効いたか分かりません。Instruction、Examples、Context、Model、Sampling設定を変更単位として分けます。

代表的な改善手段

AnthropicのPrompting Best PracticesやOpenAIのPrompting Fundamentalsでは、明確な指示、Context、出力形式、具体例などが基本として示されています。

目的と完了条件を書く

モデルに役割だけを与えるのではなく、何を作り、何を満たせば完了かを書きます。順序が意味を持つ処理は手順を分けます。

正例を絞って渡す

Few-shot exampleは、抽象的な説明だけでは伝わりにくい形式や判断を示せます。似た例を大量に並べるより、境界が分かる代表例を選びます。

出力契約を明示する

見出し、項目、最大長、許容値を明示します。機械処理する場合は、自然言語のお願いだけでなくStructured Outputを使います。

指示と入力データを区切る

処理対象の文書や利用者入力が、Instructionとして解釈されないように構造を分けます。ただし、区切り文字だけでPrompt Injectionを防げるわけではありません。

Prompt Engineeringで直せない問題を分ける

すべての失敗をPromptへ押し込むと、Promptが長くなり、互いに矛盾する規則が増えます。

問題	主な改善先
最新データがない	Retrieval、Tool、データ更新
権限外の操作を選ぶ	Authorization、Policy、Tool境界
JSONが壊れる	Structured Output、Schema validation
レイテンシが高い	Model、入力Token、Architecture
同じ失敗を検知できない	Evaluation、Observability
長時間処理で目的を失う	Context Engineering、Harness、Loop

Promptの変更で改善できるのは、モデルへ与えるInstructionや例が不足・曖昧な場合です。モデルの能力、外部データ、実行権限、システム構成の問題は別の層で直します。

Versionと再現条件を残す

Promptだけを保存しても、結果を再現できない場合があります。

Prompt Version
Model IDと提供者
APIやSDKのVersion
生成設定
Tool定義
評価セットのVersion
実行日時
評価結果と失敗分類

モデル提供者の更新で、同じPromptの振る舞いが変わることがあります。改善履歴と切り戻し先を残します。

よくある誤解

正解Promptを一つ作れば終わる

入力分布、モデル、業務ルールは変わります。PromptはVersion管理し、変更時に回帰評価します。

Promptは長いほど高品質になる

必要な条件は書きますが、重複、矛盾、使われない例が増えると重要な情報が埋もれます。最小文字数ではなく、必要十分な情報量を探します。

Prompt Engineeringで安全性を保証できる

危険な操作の拒否や秘密情報の保護は、Promptだけでは保証できません。Authorization、Validation、Approval、Sandboxを組み合わせます。

EastBraver Labsの判断基準

EastBraver Labsでは、Promptの改善を文章の好みではなく、評価結果の差分として扱います。

変更は一つずつ入れ、同じ評価セットで比較する。改善しなかった規則は残しません。

モデル更新時には古いPromptを前提にせず、現在のモデルで必要なScaffoldingを再確認します。

Promptへ規則を足し続ける前に、問題がContext、Tool、Schema、Policy、Modelのどこにあるかを切り分けます。この順番にしておくと、将来の自分やチームが原因をだいぶ追いやすくなると思います。