プロンプト・エンジニアリング・パターン

LLM のパフォーマンス、信頼性、制御性を最大化するための高度なプロンプト・エンジニアリング技法。

コア機能

1. Few-Shot Learning

ルールの説明の代わりに例を示して、モデルを学習させます。望ましい動作を示す 2～5 個の入力出力ペアを含めます。一貫したフォーマット、特定の推論パターン、またはエッジケースの処理が必要な場合に使用します。例を増やすと精度は向上しますが、トークンを消費します。タスクの複雑さに応じてバランスを取ってください。

例:

サポートチケットから主要情報を抽出:

Input: "My login doesn't work and I keep getting error 403"
Output: {"issue": "authentication", "error_code": "403", "priority": "high"}

Input: "Feature request: add dark mode to settings"
Output: {"issue": "feature_request", "error_code": null, "priority": "low"}

Now process: "Can't upload files larger than 10MB, getting timeout"

2. Chain-of-Thought Prompting

最終的な答えの前に段階的な推論を要求します。「ステップバイステップで考えましょう」と追加するか（ゼロショット）、推論のトレースの例を含めます（フューショット）。複数ステップのロジック、数学的推論、またはモデルの思考プロセスを検証する必要があるときに使用します。分析タスクの精度を 30～50% 向上させます。

例:

このバグレポートを分析し、根本原因を特定してください。

ステップバイステップで考えます:

1. 期待される動作は何か?
2. 実際の動作は何か?
3. これを引き起こす可能性のある最近の変更は何か?
4. どのコンポーネントが関係しているか?
5. 最も可能性の高い根本原因は何か?

Bug: "Users can't save drafts after the cache update deployed yesterday"

3. プロンプト最適化

テストと改良を通じてプロンプトを体系的に改善します。シンプルに始めて、パフォーマンス（精度、一貫性、トークン使用量）を測定し、反復します。エッジケースを含む多様な入力でテストします。A/B テストで変更を比較します。本番プロンプトで一貫性とコストが重要な場合は重要です。

例:

Version 1 (Simple): "Summarize this article"
→ Result: Inconsistent length, misses key points

Version 2 (Add constraints): "Summarize in 3 bullet points"
→ Result: Better structure, but still misses nuance

Version 3 (Add reasoning): "Identify the 3 main findings, then summarize each"
→ Result: Consistent, accurate, captures key information

4. テンプレート・システム

変数、条件付きセクション、モジュラーコンポーネントを持つ再利用可能なプロンプト構造を構築します。複数ターンの会話、ロールベースのインタラクション、または同じパターンが異なる入力に適用されるときに使用します。重複を削減し、類似タスク全体での一貫性を保証します。

例:

# 再利用可能なコードレビューテンプレート
template = """
Review this {language} code for {focus_area}.

Code:
{code_block}

Provide feedback on:
{checklist}
"""

# Usage
prompt = template.format(
    language="Python",
    focus_area="security vulnerabilities",
    code_block=user_code,
    checklist="1. SQL injection\n2. XSS risks\n3. Authentication"
)

5. システム・プロンプト設計

会話全体を通して存続するグローバルな動作と制約を設定します。モデルのロール、専門性レベル、出力フォーマット、安全ガイドラインを定義します。ターン間で変更すべきでない安定した指示にシステムプロンプトを使用し、可変コンテンツのためのユーザーメッセージトークンを解放します。

例:

System: You are a senior backend engineer specializing in API design.

Rules:

- Always consider scalability and performance
- Suggest RESTful patterns by default
- Flag security concerns immediately
- Provide code examples in Python
- Use early return pattern

Format responses as:

1. Analysis
2. Recommendation
3. Code example
4. Trade-offs

主要パターン

プログレッシブディスクロージャー

シンプルなプロンプトから始めて、必要な場合のみ複雑さを追加します:

1. Level 1: 直接的な指示

   • "Summarize this article"

2. Level 2: 制約を追加

   • "Summarize this article in 3 bullet points, focusing on key findings"

3. Level 3: 推論を追加

   • "Read this article, identify the main findings, then summarize in 3 bullet points"

4. Level 4: 例を追加

   • 入力出力ペアで 2～3 個のサマリー例を含める

指示の階層構造

[System Context] → [Task Instruction] → [Examples] → [Input Data] → [Output Format]

エラー復旧

障害を優雅に処理するプロンプトを構築します:

• フォールバック命令を含める
• 信頼度スコアをリクエスト
• 不確実な場合は代替解釈を要求
• 不足情報を示す方法を指定

ベストプラクティス

1. 具体的であること: 曖昧なプロンプトは一貫性のない結果を生み出します
2. 説明ではなく表示: 説明より例の方が効果的です
3. 広範なテスト: 多様で代表的な入力で評価します
4. 迅速な反復: 小さな変更が大きな影響を与える場合があります
5. パフォーマンス監視: 本番環境でメトリクスを追跡します
6. バージョン管理: プロンプトをコードとして適切なバージョン管理で扱います
7. 意図を文書化: プロンプトがなぜこのように構成されているかを説明します

よくある落とし穴

• 過度な設計: シンプルなものを試す前に複雑なプロンプトから始める
• 例の汚染: ターゲットタスクに合わない例を使用する
• コンテキストオーバーフロー: 過度な例でトークン制限を超える
• 曖昧な指示: 複数の解釈の余地を残す
• エッジケースの無視: 異常または境界入力でテストしない

使用する場合

このスキルは、概要で説明されるワークフローまたはアクションを実行するために適用可能です。

制限事項

• このスキルは、上記で説明されたスコープと明確に一致するタスクの場合のみ使用してください。
• 出力を環境固有の検証、テスト、または専門家レビューの代替と見なさないでください。
• 必要な入力、権限、安全境界、または成功基準が不足している場合は、停止して明確化を求めてください。