シニアプロンプトエンジニア
概要
大規模言語モデル向けのプロンプトを設計、テスト、最適化します。このスキルでは、少数例の設計、思考の連鎖による推論、システムプロンプトの構成、構造化出力の指定、パラメーターの調整、評価方法、A/B テスト、プロンプトのバージョン管理など、体系的なプロンプトエンジニアリングを扱います。
開始時に宣言：「プロンプトの設計と最適化にシニアプロンプトエンジニアのスキルを使用します。」
フェーズ 1：要件
目標： プロンプトを書く前に、タスクの目的、品質基準、制約を定義します。
実施項目
- タスクの目的を明確に定義する
- 入力／出力形式の要件を特定する
- 品質基準（正確性、トーン、形式）を決定する
- エッジケースと失敗モードを評価する
- モデルとパラメーターの制約を選択する
停止 — 次の条件を満たすまでフェーズ 2 に進まないでください：
フェーズ 2：プロンプトの設計
目標： 適切な構成、例、制約を備えたプロンプトを作成します。
実施項目
- 役割、制約、形式を含むシステムプロンプトを作成する
- 少数例の例示を設計する（代表的なケースを 3～5 件）
- 推論が必要な場合は、思考の連鎖を促す足場を追加する
- 出力構造を指定する（JSON、markdown など）
- エラー処理の指示を追加する
プロンプト構成のレイヤー
| レイヤー | 目的 | 例 |
|---|
| 1. アイデンティティ | モデルが何者か | "あなたは感情分類器です..." |
| 2. コンテキスト | モデルが知っていること／アクセスできる情報 | "製品レビューにアクセスできます..." |
| 3. タスク | 実行する内容 | "各レビューをポジティブ／ネガティブ／ニュートラルに分類してください" |
| 4. 制約 | 実行してはいけないこと | "出力に個人を特定できる情報を含めないでください" |
| 5. 形式 | 出力の構成方法 | "JSON で回答してください：{classification, confidence}" |
| 6. 例 | 実演 | 代表的な入力／出力のペアを 3～5 件 |
| 7. メタ認知 | 不確実性への対処 | "判断に迷う場合はニュートラルに分類し、説明してください" |
システムプロンプトのテンプレート
[Role] You are a [specific role] that [specific capability].
[Context] You have access to [tools/knowledge]. The user will provide [input type].
[Instructions]
1. First, [step 1]
2. Then, [step 2]
3. Finally, [step 3]
[Constraints]
- Always [requirement]
- Never [prohibition]
- If uncertain, [fallback behavior]
[Output Format]
Respond in the following format:
[format specification]
[Examples]
<example>
Input: [sample input]
Output: [sample output]
</example>
停止 — 次の条件を満たすまでフェーズ 3 に進まないでください：
フェーズ 3：評価と反復
目標： プロンプトの品質を測定し、目標に向けて反復します。
実施項目
- 評価データセットを作成する（最低 50 件）
- スコアリング基準を定義する（自動評価と人による評価の指標）
- ベースライン評価を実行する
- 目標を絞った改善を行いながらプロンプトを反復する
- 有望なバリエーションを A/B テストする
- 最終版のプロンプトにバージョンを付け、記録する
停止 — 次の条件を満たしたら評価完了：
少数例の設計
選定基準の判断表
| 基準 | 説明 | 例 |
|---|
| 代表性 | 最も一般的な入力タイプを網羅する | エッジケースだけでなく、一般的なメールも含める |
| 多様性 | エッジケースと境界例を含める | 短文＋長文、肯定的＋否定的 |
| 順序 | 単純なものから複雑なものへ進める | 明白なケースを最初に、曖昧なケースを最後にする |
| バランス | 各カテゴリを均等に扱う | 肯定的な例 4 件、否定的な例 1 件にしない |
例の数の目安
| タスクの複雑さ | 必要な例の数 |
|---|
| 単純な分類 | 2～3 |
| 中程度の生成 | 3～5 |
| 複雑な推論 | 5～8 |
| 形式重視 | 3～5（形式の一貫性を重視） |
例の形式
<example>
<input>
[Representative input]
</input>
<reasoning>
[Optional: show the thinking process]
</reasoning>
<output>
[Expected output in exact target format]
</output>
</example>
思考の連鎖のパターン
CoT パターンの選択表
| パターン | 使用する場面 | 例 |
|---|
| 標準 CoT | 複数ステップの推論 | 「段階的に考えてください：1. 特定する… 2. 分析する…」 |
| 構造化 CoT | 解析可能な推論が必要な場合 | XML タグ：<analysis>...</analysis> の後に <answer>...</answer> |
| 自己一貫性 | 重大な結果を伴う意思決定 | 3 つの解決策を生成し、最も多いものを選択する |
| CoT なし | 簡単な事実の検索、形式変換 | 推論にかかるオーバーヘッドを省く |
CoT を使用する場面
| タスクの種類 | CoT を使用するか | 根拠 |
|---|
| 数学的推論 | はい | 段階を追うことでエラーを防げます |
| 複数ステップの論理 | はい | 推論が明確になります |
| 根拠を伴う分類 | はい | 精度と説明可能性が向上します |
| 簡単な事実の検索 | いいえ | 精度を向上させずにレイテンシーが増加します |
| 直接的な形式変換 | いいえ | 推論は不要です |
| 非常に短い回答 | いいえ | CoT のオーバーヘッドがメリットを上回ります |
構造化出力
出力形式の選択表
| 形式 | 使用する場面 | 解析方法 |
|---|
| JSON | 機械処理される出力 | JSON.parse() |
| Markdown | 人が読みやすい構造化テキスト | 正規表現または Markdown パーサー |
| XML タグ | セクションの明確な区切りが必要な場合 | XML パーサーまたは正規表現 |
| YAML | 設定ファイルのような出力 | YAML パーサー |
| プレーンテキスト | シンプルで構造化されていない回答 | 解析不要 |
JSON 出力の例
Respond with a JSON object matching this schema:
{
"classification": "positive" | "negative" | "neutral",
"confidence": number between 0 and 1,
"reasoning": "brief explanation",
"key_phrases": ["array", "of", "phrases"]
}
Do not include any text outside the JSON object.
Temperature と Top-P の調整
| 用途 | Temperature | Top-P | 根拠 |
|---|
| コード生成 | 0.0-0.2 | 0.9 | 決定論的で、正確です |
| 分類 | 0.0 | 1.0 | 一貫した結果が得られます |
| 創作 | 0.7-1.0 | 0.95 | 多様で興味深い出力になります |
| 要約 | 0.2-0.4 | 0.9 | 原文に忠実でありながら流暢です |
| ブレインストーミング | 0.8-1.2 | 0.95 | 多様性を最大化します |
| データ抽出 | 0.0 | 0.9 | 正確で信頼性があります |
ルール
- 一貫性と正確性が求められるタスクでは Temperature を 0 にします
- 創造的なタスクでは Temperature を高くします
- Top-P は調整が必要になることはほとんどありません（0.9-1.0 に保ちます）
- 高い Temperature と低い Top-P を同時に使用しないでください（矛盾する設定です）
評価指標
自動評価指標
| 指標 | 測定対象 | 用途 |
|---|
| 完全一致 | 出力が期待値と一致するか | 分類、抽出 |
| F1 スコア | 適合率と再現率のバランス | マルチラベルタスク |
| BLEU/ROUGE | N-gram の重複度 | 要約、翻訳 |
| JSON の有効性 | 構造化出力を解析できるか | 構造化生成 |
| 正規表現の一致 | 出力がパターンに一致するか | 形式への準拠 |
人間による評価の観点
| 観点 | 尺度 | 説明 |
|---|
| 正確性 | 1-5 | 事実として正しいか |
| 関連性 | 1-5 | 実際の質問に答えているか |
| 一貫性 | 1-5 | 論理的な流れと構成 |
| 完全性 | 1-5 | 必要なすべての側面を網羅しているか |
| トーン | 1-5 | 望ましい語調に合っているか |
| 簡潔さ | 1-5 | 不要な内容がないか |
評価データセットの要件
- 統計的有意性を確保するため、最低 50 件の例を含めます
- すべての入力カテゴリを比例的に網羅します
- エッジケースを含めます（データセットの 10～20%）
- 正解ラベルを 2 名以上の評価者が確認します
- プロンプトとともにバージョン管理します
A/B テストの手順
- 仮説を定義します：「プロンプト B は［指標］を［量］だけ改善する」
- プロンプトの変更以外のすべての変数を一定に保ちます
- 同じ評価セットで両方のバリエーションを実行します
- 信頼区間を用いて指標の差を計算します
- 採用する前に統計的有意性（p < 0.05）を確認します
A/B テストの対象
| 変数 | 予想される影響 |
|---|
| 指示の表現（命令形と説明形） | 中程度 |
| 少数例の数 | 中程度 |
| 例の順序 | 低～中程度 |
| CoT の有無 | 推論タスクでは高い |
| 出力形式の指定 | 構造化出力では高い |
| 制約を置く位置（冒頭と末尾） | 低い |
プロンプトのバージョン管理
バージョンファイル形式
id: classify-sentiment
version: 2.1
model: claude-sonnet-4-20250514
temperature: 0.0
created: 2025-03-01
author: team
changelog: "Added edge case examples for sarcasm detection"
metrics:
accuracy: 0.94
f1: 0.92
eval_dataset: sentiment-eval-v3
system_prompt: |
You are a sentiment classifier...
examples:
- input: "..."
output: "..."
バージョニングルール
- セマンティックバージョニング：major.minor（major ＝ 挙動の変更、minor ＝ 改善）
- すべてのバージョンに評価指標を含めます
- 評価データセットのバージョンへのリンクを記載します
- 変更内容とその理由を記録します
- ロールバックできるよう、以前のバージョンを保持します
アンチパターン／よくある間違い
| アンチパターン | 問題点 | 正しい方法 |
|---|
| 曖昧な指示（「役に立つように」） | 出力の信頼性と一貫性がありません | 例を含む具体的な指示を記述します |
| 矛盾する制約 | モデルは両方を満たせません | 一貫性を確認します |
| タスクに合わない例 | モデルを混乱させます | 実際の使用状況を反映した例を使います |
| 単純なタスクの過剰な設計 | トークンを浪費し、処理が遅くなります | プロンプトの複雑さをタスクの複雑さに合わせます |
| 評価フレームワークがない | 品質を推測することになります | 反復する前に指標を定義します |
| 単一の例に向けた最適化 | 1つのケースに過学習します | データの分布全体に向けて最適化します |
| モデル間の移植性を想定する | モデルごとに必要なプロンプトが異なります | 対象モデルでテストします |
| バージョン管理を省略する | ロールバックや比較ができません | すべてのプロンプトを指標とともにバージョン管理します |
統合ポイント
| スキル | 関係 |
|---|
llm-as-judge | LLM-as-judge がプロンプト出力の品質を評価します |
acceptance-testing | プロンプト評価データセットを受け入れテストとして使用します |
testing-strategy | プロンプトのテストでは評価方法に従います |
senior-data-scientist | 統計的テストで A/B テストの結果を検証します |
code-review | プロンプトの変更をコードの変更と同様にレビューします |
clean-code | プロンプトの読みやすさは、クリーンコードの命名原則に従います |
スキルの種類
FLEXIBLE — 特定のモデル、タスク、品質要件に合わせてプロンプト技術を調整します。評価とバージョニングの実践は強く推奨されますが、プロジェクトの規模に応じて調整できます。本番環境のプロンプトは必ずバージョン管理してください。
