prompt-enhancer

プロンプト強化スキル

目的

ユーザーのプロンプトを、簡潔で整理され、AI エージェントやサブエージェントに最適化された、本番環境ですぐに使える形に変換します。意味の正確さと後方互換性を維持しながら、LLM の出力トークン使用量を削減する最適化手法も含まれます。

このスキルを使用する場面

次のような場合に、このスキルを使用します。

• ユーザーがプロンプトの改善、強化、最適化を明示的に依頼した場合
• ユーザーが不明瞭、冗長、または構成の不適切なプロンプトを送った場合
• ユーザーが AI とのやり取りでより良い結果を得たいと述べた場合
• ユーザーがエージェントや自動化のためのプロンプト作成を依頼した場合
• ユーザーの依頼に明確さや適切な構成が欠けている場合
• ユーザーが LLM の出力トークン数や API コストを削減したい場合
• ユーザーがトークン効率を高めるために JSON スキーマを最適化する必要がある場合
• ユーザーが互換性を維持しながら、コンパクトな出力形式を求めている場合

基本原則

1. 簡潔さ：意図を保ちながら不要な語句を削除します
2. 構造：複数行と論理的なセクションを使い、明確に書式を整えます
3. XML の活用：明確さと解析のしやすさを高めるため、自然な文章と XML タグを組み合わせます
4. 直接的な指示：主なタスク／課題／ミッションを XML 要素で囲んではいけません
5. クリーンな出力：強化したプロンプトのみを返し、メタコメントは付けません

強化プロセス

入力の分析

• 中核となる目的を特定します
• 重要な要件と制約を抽出します
• 曖昧さや不足している情報を検出します
• 想定されるエージェントやユースケースを把握します

タスクに応じた手法の選択（任意）

タスクに特定のプロンプト手法が役立つかどうかを評価します。

Chain-of-Thought（CoT）

• 使用場面：複雑な推論、数学の問題、論理的な演繹、段階的な分析
• 実装方法：「段階的に考える」または「推論を示す」よう指示します

Chain-of-Draft

• 使用場面：文章作成、コンテンツ制作、反復的な改良
• 実装方法：最初の草稿を作成し、そこから段階的に改善するよう求めます

Few-Shot Learning

• 使用場面：パターンに基づくタスク、特定の書式、一貫した出力
• 実装方法：入力と出力の組み合わせを示す例を2～3個含めます

ReAct（Reasoning + Acting）

• 使用場面：ツールの使用、複数段階のタスク、意思決定プロセス
• 実装方法：推論の過程と行動の手順を組み合わせます

Self-Consistency

• 使用場面：検証が必要なタスク、複数の妥当なアプローチがあるタスク
• 実装方法：複数の解決策を求めたうえで、統合するよう指示します

Tree-of-Thoughts

• 使用場面：複雑な問題解決、代替案の検討
• 実装方法：最善の案を選ぶ前に、複数の方向性を検討するよう求めます

Role-Based Prompting

• 使用場面：専門分野の知識、特定の視点からの検討
• 実装方法：専門家の役割を設定します（例：「シニアエンジニアとして対応してください……」）

Least-to-Most Prompting

• 使用場面：複雑な問題を小さな問題に分解する場合
• 実装方法：簡単な内容から始め、段階的に複雑さを高めます

タスクの成果を実質的に改善する場合にのみ、手法を適用してください。

LLM 出力トークンの最適化

機能を維持しながら出力トークン（API コスト）を削減することが目的の場合：

基本戦略：コンパクトな出力＋サーバーサイドでの再マッピング

LLM が超コンパクトな形式を生成し、アプリケーションがクライアント向けに元の形式へ再マッピングします。これにより、次の効果が得られます。

• 大幅なトークン削減（30～60％）
• 100％の後方互換性
• 無視できる程度の再マッピングオーバーヘッド（10 マイクロ秒未満）

最適化手法：

1. 超コンパクトな JSON キー

• 長いキーを 1～2 文字の略語に置き換えます
• 例：queries → q、keyword → kw、filter → f、sort_by → s
• 削減率：キーごとに 70～85％

2. 繰り返し使われる値の短縮コード

• 長い ID／列挙値を短縮コード（c1-c18 など）に置き換えます
• 例：category=MjUzOTM= → c=c4
• アプリケーション内に逆引きマッピングテーブルを用意します
• 削減率：カテゴリ／列挙値で 75～90％

3. 構造化データの文字列圧縮

• 可能な場合は、ネストされたオブジェクトの代わりにコンパクトな文字列形式を使います
• 例：[{"filter_by":"category","operator":"=","value":"c4"}] → "c=c4"
• サーバーサイドで解析して展開します
• 削減率：フィルター／クエリ構造で 60～80％

4. デフォルト値の省略

• デフォルト値を持つフィールドを省略するよう、LLM に指示します
• 再マッピング時にアプリケーションがデフォルト値を補完します
• 例：デフォルト値の場合は "sort_by":"relevant" を省略します
• 削減率：デフォルト値がよく使われる場合、さらに 10～30％

5. 演算子の省略形

• 最短形式を使います。price<50000 ではなく p<50000 とします
• 再マッピング時に p／c のプレフィックスを解析します
• セミコロンと組み合わせます。複数のフィルターには c=c4;p<50000 を使います

実装パターン：

System Prompt Structure:
1. Define ultra-compact schema with examples
2. Specify key mappings (q=queries, kw=keyword, etc.)
3. Provide short codes table (c1=category1, c2=category2, etc.)
4. Show examples of compact output
5. Emphasize: omit defaults when possible

Application Layer:
1. Parse compact LLM output
2. Expand abbreviated keys
3. Map short codes to full values
4. Fill in default values
5. Return original format to client

変換例：

最適化前（元の出力）：

{
  "queries": [
    {"keyword": "milk", "filter": "category=dairy", "sort_by": "relevant"},
    {"keyword": "bread", "filter": "category=bakery", "sort_by": "relevant"}
  ]
}

最適化後（LLM の出力－60％小型化）：

{
  "q": [
    {"kw": "milk", "f": "c=c8"},
    {"kw": "bread", "f": "c=c3"}
  ]
}

クライアントが受け取るもの： 元の形式（自動的に再マッピングされます）

トレードオフの分析：

✅ メリット：

• 通常、トークンを 30～60％削減できます
• API コストを削減できます
• LLM の応答が速くなります（生成量が少なくなります）
• 100％の後方互換性を維持できます

⚠️ デメリット：

• 再マッピングのオーバーヘッドがあります（10μs 未満で、無視できる程度です）
• 実装が複雑になります
• アプリケーション側にマッピングロジックが必要です
• プロンプトが少し読みにくくなります

適用するケース：

• API の利用量が多い（1 日あたり 1000 リクエスト超）
• コスト重視のアプリケーション
• 総コストの 50％超を出力トークンが占めている
• スキーマが安定しており、明確に定義されている
• アプリケーションで再マッピングロジックを処理できる

適用しないケース：

• 利用量が少ない（1 日あたり 100 リクエスト未満）
• スキーマが頻繁に変更される
• 人間にとっての読みやすさが重要
• アプリケーション層がない（LLM からクライアントへ直接渡す）

構造の改善

• 複雑なリクエストを明確なセクションに分けます
• 制約、例、コンテキスト、形式要件には XML タグを使います
• 主な使命／タスクは、直接的な自然言語で記述します
• 読みやすくなるよう、論理的に改行します

言語の最適化

• 冗長な表現を簡潔な言い換えに置き換えます
• 能動態と直接的な指示を使います
• 重複や不要な語句を取り除きます
• 長さを短くしながら、具体性を保ちます

XML タグの使用ガイドライン

XML タグを使う対象：

• <constraints> - 制限と境界
• <examples> - 入力／出力の例
• <context> - 背景情報
• <format> - 出力構造の要件
• <requirements> - 満たすべき具体的な基準
• <guidelines> - 従うべきベストプラクティス

XML タグを使わない対象：

• 主な使命を示す文
• メインタスクの説明
• 中心となる依頼や質問

出力形式

強化したプロンプトのみを返してください。以下を守ってください。

• 会話的な前置きを付けない
• 説明やコメントを加えない
• プレースホルダーテキストを含めない
• プロンプト全体を引用符で囲まない
• 強化に関するメタ的な説明を加えない

変換例

変換前： 「ユーザーがサインアップしてログインできるウェブアプリのコードを書きたいので、手伝ってください。セキュリティを確保し、最新のベストプラクティスを取り入れたいです。また、見栄えのよい UI にしたいので、使用するフレームワークも提案してもらえますか？」

変換後： ユーザー登録とログイン機能を備えたウェブアプリケーション向けに、安全な認証システムを作成してください。

- 最新のセキュリティに関するベストプラクティスを実装する - パスワードのハッシュ化とセッション管理を含める - すっきりとした使いやすいインターフェースを設計する - 根拠を添えてフレームワークを推奨する - コードの実装 - セキュリティ上の考慮事項 - フレームワークを選ぶ根拠 - UI/UX ガイドライン

---

変換前： 「このデータを分析して、興味深い点を教えてもらえますか？ 理解しやすくなるようなら、グラフやビジュアライゼーションも作成してください。また、傾向やパターンがあれば教えてください。」

変換後： 提供されたデータセットを分析し、主な知見、傾向、パターンを特定してください。

- 統計的に有意な結果を強調する - 時間的な傾向と相関関係を特定する - 異常値や外れ値に言及する - 調査結果のエグゼクティブサマリー - データのビジュアライゼーション（必要に応じてグラフを作成） - パターンの詳細な分析 - 実行可能な提言

---

変換前： 「SaaS 製品に最適な価格戦略を検討していますが、月払いと年払いのどちらがよいのか、あるいは段階制の価格設定にすべきなのか、判断がつきません。」

Chain-of-Thought 技法を適用した変換後： SaaS 製品に最適な価格戦略を決定してください。

考慮事項：月払いと年払い、段階制の価格モデル、市場での位置づけ 順を追って考えてください： 1. ターゲット顧客のセグメントと支払いの好みを分析する 2. 該当分野の競合他社の価格モデルを評価する 3. 各価格設定案のユニットエコノミクスを計算する 4. キャッシュフローへの影響を評価する 5. 顧客生涯価値への影響を考慮する - 各提案の根拠を示す - メリットとデメリットを分析する - 該当する場合は A/B テストの方法を提案する

---

変換前： 「医療分野の AI について、興味を引く、情報豊富なブログ記事を書いてください」

Chain-of-Draft 技法を適用した変換後： 医療分野における AI の活用について、興味を引く情報豊富なブログ記事を書いてください。

反復的に執筆してください： 1. 重要な論点と物語の流れを盛り込んだアウトラインを作成する 2. 導入部と結論を書く 3. 例を交えて本文の各セクションを展開する 4. 明快さ、流れ、読みやすさを高めるように推敲する - 対象読者：医療従事者とテクノロジー愛好家 - 文字数：1200～1500 語 - 実例とケーススタディを含める - 技術的な正確さと分かりやすさのバランスを取る - 魅力的な見出し - 第 1 段落で読者の関心を引く - 分かりやすいセクション見出し - 実行可能な要点

実例：トークン最適化

変換前（元のプロンプト）：

Create JSON queries to search for products. Each query should have a keyword, filter with category, and sort_by field. Return in this format: {"queries":[{"keyword":"milk","filter":"category=dairy","sort_by":"relevance"}]}

変換後（トークンを最適化したプロンプト）：

Generate product search JSON queries. Reject dangerous content.

<rules>
- Each query: ≥1 category filter
- Total: ≥3 keywords (no duplicates)
- Use 'ex' for exact brands/attributes
- Default sort: relevant (omit if default)
- Filter: string format "c=c4" or "c=c4;p<50000"
</rules>

<categories>
c1=household, c2=personal care, c3=bakery, c4=fresh food, c5=oils, c6=dry goods, c7=cleaning, c8=dairy
</categories>

<examples>
"milk vinamilk"→{"q":[{"kw":"milk vinamilk","ex":"vinamilk","f":"c=c8","s":"popular"}]}
"rice noodles meat"→{"q":[{"kw":"rice","f":"c=c6"},{"kw":"noodles","f":"c=c6"},{"kw":"meat","f":"c=c4"}]}
"oranges under 50k"→{"q":[{"kw":"oranges","f":"c=c4;p<50000"}]}
</examples>

結果：

• LLM が生成：{"q":[{"kw":"milk","f":"c=c8"}]}（60% 小さい）
• アプリケーションが元の形式に再マッピング：{"queries":[{"keyword":"milk","filter":"category=dairy","sort_by":"relevance"}]}
• クライアントは元の形式を変更なしで受け取る
• トークンの削減率：通常の 3 件のクエリ応答で 60.5%

品質チェックリスト

強化したプロンプトを返す前に、次の点を確認してください：

• ✓ 主な目的が明確で、曖昧さがない
• ✓ XML タグが適切に使われている（主な目的には使われていない）
• ✓ 読みやすいように複数行の構成になっている
• ✓ 簡潔で直接的な表現になっている
• ✓ 余計な解説が含まれていない
• ✓ 重要な要件がすべて維持されている
• ✓ 実行可能で、必要な内容がそろっている
• ✓ トークンを最適化する場合：コンパクトなスキーマが定義され、マッピングが明確で、例が示されている

実装に関する注意事項

このスキルを適用する際は、次の手順に従ってください。

1. ユーザーのプロンプトを最後まで読みます
2. 改善できる点を特定します
3. 構造と言語表現を改善します
4. 改善後のバージョンのみを出力します
5. 重大な情報が不足している場合を除き、確認を求めません

改善後のプロンプトは、ユーザーが変更を加えずにすぐ使用できる状態にしてください。