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

> Prompt Engineeringを、文言の工夫ではなく、成功基準・評価セット・Version管理を使ってLLMの入力を改善する工程として整理します。

Canonical URL: https://labs.eastbraver.com/guides/prompt-engineering
Published: 2026-07-01
Updated: 2026-07-24
Category: field-guide
Tags: llm-inference, software-engineering, evaluation

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

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

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

[AnthropicのPrompt Engineering Overview](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/overview)は、Prompt Engineeringを始める前提として、明確な成功基準、経験的に試す方法、改善対象となる初稿を挙げています。

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

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

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

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

### Prompt改善のEvaluation loop

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

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

*評価結果から限定的なPrompt修正へ戻る反復工程*

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

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

## 代表的な改善手段

[AnthropicのPrompting Best Practices](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices)や[OpenAIのPrompting Fundamentals](https://openai.com/academy/prompting/)では、明確な指示、Context、出力形式、具体例などが基本として示されています。

### 目的と完了条件を書く

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

### 正例を絞って渡す

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

### 出力契約を明示する

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

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

処理対象の文書や利用者入力が、Instructionとして解釈されないように構造を分けます。ただし、区切り文字だけで[Prompt Injection](/guides/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を組み合わせます。

### 最新モデルならPrompt Engineeringは不要になる

モデルが強くなると細かな誘導は減らせる場合があります。それでも、目的、入力、出力契約、成功条件はシステム側で定義します。

## EastBraver Labsの判断基準

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

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

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

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

## 関連記事

- [AI Agent 時代に、エンジニアは何を設計する人になるのか](/blog/ai-development-20260706)
- [評価基盤の外部依存を見直す日](/digest/ai-digest-20260706)
- [AI運用コストと基盤制約を点検](/digest/ai-digest-20260713)

## 検証範囲

- 一次情報: 公式ドキュメント / 設計面からの分析
- ローカル検証: 手元で再現しています
- 実運用: 本番運用の実績については、このGuideでは触れていません

## 変更履歴

- 2026-07-24: Mermaid図にテキスト等価物を追加
- 2026-07-15: 検証範囲と根拠区分を明示
- 2026-07-01: 初版公開