prompt-engineering

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

主な機能

1. 少数例学習

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

例：

Extract key information from support tickets:

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. 思考の連鎖を用いたプロンプティング

最終的な回答の前に、段階的に推論するよう求めます。「一歩ずつ考えてみましょう」（ゼロショット）を追加するか、推論の例を含めます（少数例）。複数段階の論理や数学的推論が必要な複雑な問題、またはモデルの思考プロセスを確認する必要がある場合に使用します。分析タスクの精度が30〜50％向上します。

例：

Analyze this bug report and determine root cause.

Think step by step:

1. What is the expected behavior?
2. What is the actual behavior?
3. What changed recently that could cause this?
4. What components are involved?
5. What is the most likely root cause?

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. テンプレートシステム

変数、条件付きセクション、モジュール式のコンポーネントを備えた再利用可能なプロンプト構造を構築します。複数ターンの会話、ロールベースのやり取り、または同じパターンを異なる入力に適用する場合に使用します。重複を減らし、類似したタスク間の一貫性を確保します。

例：

# Reusable code review template
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. レベル1：直接的な指示

   • 「この記事を要約してください」

2. レベル2：制約を追加

   • 「この記事を、主な調査結果に焦点を当てて3つの箇条書きで要約してください」

3. レベル3：推論を追加

   • 「この記事を読み、主な調査結果を特定してから、3つの箇条書きで要約してください」

4. レベル4：例を追加

   • 入出力ペアによる要約例を2〜3件含めます

指示の優先順位

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

エラーからの回復

失敗に適切に対処できるプロンプトを作成します。

• フォールバックの指示を含める
• 信頼度スコアを求める
• 不確かな場合は別の解釈を尋ねる
• 情報が不足している場合の示し方を指定する

ベストプラクティス

1. 具体的にする：曖昧なプロンプトは、一貫性のない結果を生みます
2. 説明より例を示す：例は説明より効果的です
3. 十分にテストする：多様で代表的な入力を使って評価します
4. 素早く反復する：小さな変更が大きな影響をもたらすことがあります
5. パフォーマンスを監視する：本番環境で指標を追跡します
6. バージョン管理する：適切にバージョン管理されたコードとしてプロンプトを扱います
7. 意図を記録する：プロンプトをそのように構成した理由を説明します

よくある落とし穴

• 過剰な設計：シンプルな方法を試す前に、複雑なプロンプトから始める
• 例のミスマッチ：対象のタスクに合わない例を使う
• コンテキストの超過：例を入れすぎてトークン上限を超える
• 曖昧な指示：複数の解釈ができる余地を残す
• エッジケースの軽視：特殊な入力や境界値の入力でテストしない

コンテンツとソーシャルメディアのプロンプト

コンテンツ生成用のプロンプトを設計する際は、次の点に注意します。

• マルチプラットフォームへの対応：記事、ソーシャルメディアの投稿、動画スクリプトに合わせて調整できるプロンプトを設計します
• ブランドの声：生成されるコンテンツの一貫性を保つため、トーンやスタイルの制約を含めます
• SEO とエンゲージメント：最適化のシグナルと、自然で魅力的な表現のバランスを取ります
• 構造化された出力：大量のコンテンツを扱うパイプラインには、JSON または Markdown のスキーマを使用します
• 検証基準：プロンプトに品質チェックと評価基準を含めます

タスクの例：

• 長文記事から Twitter のスレッドを生成するためのプロンプトテンプレートを設計する
• ブランドの一貫性を保った LinkedIn 投稿を生成するためのシステムプロンプトを作成する
• コンテンツを再利用するためのプロンプトパイプラインを構築する（記事 → ソーシャルメディア → メール）

使用するタイミング

ユーザーがプロンプトの改善、プロンプト戦略の学習、エージェントの動作のデバッグ、またはコンテンツ生成パイプラインの設計を希望する場合に有効にします。

既存のプロンプトを最適化する場合（/prompt コマンドの役割）：references/prompt-optimization.md に記載された体系的な 4-D ワークフロー（Deconstruct、Diagnose、Develop、Deliver）に従います。

制限事項

• タスクが上記の範囲に明確に該当する場合にのみ、このスキルを使用してください。
• 出力を、環境固有の検証、テスト、または専門家によるレビューの代わりとして扱わないでください。
• 必要な入力、権限、安全上の境界、または成功基準が不足している場合は、作業を中断して確認を求めてください。