prompt-lab

プロンプトラボ

試行錯誤によるプロンプトエンジニアリングを、構造化された方法論に置き換えます。目的の定義、現在のプロンプトの分析、バリアントの作成（指示の明確化、例の活用方法、出力形式の指定）、評価ルーブリックの設計、テストケースの作成、失敗モードの特定を行います。

参考ファイル

ファイル	内容	読み込むタイミング
references/prompt-patterns.md	プロンプト構造のカタログ：ゼロショット、フューショット、CoT、ペルソナ、構造化出力	常に
references/evaluation-metrics.md	品質指標（正確性、形式への準拠、完全性）、ルーブリックの設計	評価が必要な場合
references/failure-modes.md	よくあるプロンプトの失敗の分類、検出方法、緩和策	失敗分析を依頼された場合
references/output-constraints.md	LLM の出力形式を制約する手法、JSON モード、スキーマの適用	形式の制御が必要な場合

前提条件

• 明確な目的：プロンプトで何を達成する必要がありますか？
• 対象モデル（GPT-4、Claude、オープンソース）— プロンプト手法はモデルによって異なります
• 現在のプロンプト（改善する場合）、またはタスクの説明（新規作成の場合）

ワークフロー

フェーズ 1：目的の定義

1. タスクの仕様 — LLM に何を生成させますか？具体的に指定します。「サポートチケットに対応する」ではなく、「カスタマーサポートのチケットを 5 つのカテゴリに分類する」と指定します。
2. 成功基準 — 出力が正しいかどうかを、どのように判断しますか？プロンプトを書く前に、測定可能な基準を定義します。
3. 失敗モード — 悪い出力とはどのようなものですか？情報の欠落ですか？形式の誤りですか？内容の幻覚ですか？回答の拒否ですか？

フェーズ 2：現在のプロンプトの分析

既存のプロンプトが提供されている場合：

1. 構造の評価 — 指示は明確ですか？例は提示されていますか？出力形式は指定されていますか？
2. 曖昧さの検出 — モデルが指示を誤解する可能性があるのはどこですか？
3. 不足している要素 — 指定すべきなのに、指定されていないものは何ですか？（出力形式、トーン、長さの制約、エッジケースへの対応）
4. 失敗モードの対応付け — 既知の失敗パターン（references/failure-modes.mdを参照）のうち、このプロンプトに当てはまるものはどれですか？

フェーズ 3：バリアントの作成

それぞれ異なる仮説を検証するプロンプトのバリアントを 2～4 個作成します。

バリアントの種類	仮説	使用する場面
直接的な指示	明確な指示だけで十分	単純なタスク、高性能なモデル
フューショット	例によって出力の一貫性が向上する	パターンに従うタスク
思考の連鎖	推論によって正確性が向上する	複数段階の論理、数学、分析
ペルソナ／役割	役割の設定によってトーンや専門性が向上する	特定の分野のタスク
構造化出力	形式の指定によってエラーを防げる	JSON、CSV、特定のテンプレート

各バリアントについて：

• 仮説を述べます（このバリアントが有効かもしれない理由）
• リスクを特定します（うまくいかない可能性がある点）
• プロンプト全文を提示します

フェーズ 4：設計評価

1. 評価基準 — 重み付けした基準を定義します。

   基準	測定内容	一般的な重み
   正確性	出力が期待される回答と一致するか	30-50%
   形式への準拠	指定された構造に従っているか	15-25%
   完全性	必要な要素がすべて含まれているか	15-25%
   簡潔さ	不要な内容がないか	5-15%
   トーン／スタイル	指定された文体に合っているか	5-10%

2. テストケース — 次の内容を網羅するケースを最低 5 件用意します。

   • 正常系（標準的な入力）
   • エッジケース（通常とは異なるが有効な入力）
   • 敵対的ケース（混乱を招くように設計された入力）
   • 境界ケース（最小／最大の入力）

フェーズ 5：出力

バリアント、評価基準、テストケースを、すぐに実行できる構造化形式で提示します。

出力形式

## Prompt Lab: {Task Name}

### Objective
{What the prompt should achieve — specific and measurable}

### Success Criteria
- [ ] {Criterion 1 — measurable}
- [ ] {Criterion 2 — measurable}

### Current Prompt Analysis
{If existing prompt provided}
- **Strengths:** {what works}
- **Weaknesses:** {what fails or is ambiguous}
- **Missing:** {what's not specified}

### Variants

#### Variant A: {Strategy Name}

{完全なプロンプトテキスト}

**Hypothesis:** {Why this approach might work}
**Risk:** {What could go wrong}

#### Variant B: {Strategy Name}

{完全なプロンプトテキスト}

**Hypothesis:** {Why this approach might work}
**Risk:** {What could go wrong}

#### Variant C: {Strategy Name}

{完全なプロンプトテキスト}

**Hypothesis:** {Why this approach might work}
**Risk:** {What could go wrong}

### Evaluation Rubric

| Criterion | Weight | Scoring |
|-----------|--------|---------|
| {criterion} | {%} | {how to score: 0-3 scale or pass/fail} |

### Test Cases

| # | Input | Expected Output | Tests Criteria |
|---|-------|-----------------|---------------|
| 1 | {standard input} | {expected} | Correctness, Format |
| 2 | {edge case} | {expected} | Completeness |
| 3 | {adversarial} | {expected} | Robustness |

### Failure Modes to Monitor
- {Failure mode 1}: {detection method}
- {Failure mode 2}: {detection method}

### Recommended Next Steps
1. Run all variants against the test suite
2. Score using the rubric
3. Select the highest-scoring variant
4. Iterate on the winner with targeted improvements

キャリブレーションルール

1. バリアントごとに変更する変数は 1 つだけにします。 各バリアントでは、ベースラインから変更する点を 1 つにします。 指示のスタイル、例、形式を同時に変更すると、結果を解釈できなくなります。
2. 成功と判断する前にテストします。 3 件の例でうまくいくプロンプトでも、4 件目では失敗する可能性があります。バリアントが機能すると結論づける前に、多様なテストケースを最低 5 件試します。
3. 成功よりも失敗モードのほうが価値があります。 プロンプトが失敗する理由を理解するほうが、機能することを確認するよりも改善の指針になります。
4. モデルに応じて最適化します。 GPT-4 向けに最適化されたプロンプトが、Claude や Llama でも機能するとは限りません。対象モデルを必ず記録してください。
5. 効果のある最もシンプルなプロンプトを選びます。 ゼロショットプロンプトがフューショットプロンプトと同程度のスコアなら、ゼロショットを使います。トークン数が少ないほど、コストとレイテンシーが下がります。

エラー処理

問題	解決策
明確な目標がない	「良い出力」とはどのようなものか、2～3 件の例を挙げて定義するようユーザーに尋ねます。
LLM が苦手とするタスク（数学、数え上げ）のプロンプト	制限事項を伝えます。ツールを併用する方法や、前処理／後処理を提案します。
テストする変数が多すぎる	まず最も影響の大きい変数に焦点を当てます。反復的な改善は、組み合わせテストよりも効果的です。
分析する既存のプロンプトがない	可能な限りシンプルなプロンプトから始めます。最初のバリアントがベースラインになります。
出力形式の要件が厳格	プロンプトだけで制約するのではなく、構造化出力モード（JSON モード、関数呼び出し）を使います。

使用しない場合

次の場合は、別の方法を検討するよう提案してください。

• タスクに LLM が不要な場合（決定論的なルール、正規表現、SQL） — 適切なツールを使ってください
• ユーザーが求めているのがプロンプトの設計ではなく実行である場合 — このスキルはプロンプトを設計・評価しますが、実行はしません
• プロンプトが人によるレビューなしで安全性が極めて重要な判断に使われる場合 — LLM の出力だけを判断材料にしてはいけません