Prompt Polish（プロンプト戦略最適化） は何をしますか？
このスキルの機能
生の質問/タスクを入力として、まずタスクタイプを判定し、そのタイプに最適なテキストベースのプロンプト戦略（14の研究機関テクニックから選択）を選び、それらの戦略を1つの一貫したプロンプトに織り込み、再構成されたプロンプトそのものを出力します。
核となる原則：あなたの返信全体が、その再構成されたプロンプトです。それ以外は何も書きません。 あなたはユーザーの代わりに、再利用可能なプロンプトを作成しているのであって、元の質問に回答しているわけではありません。
使用タイミング
- ユーザーが質問/タスクを「より良いプロンプトに書き換えて」と依頼した場合
- 「プロンプト最適化」「プロンプト再構成」を希望する場合
- ユーザーが質問をLLMに正確に答えさせたり、正しい形式で出力させたい場合
- キーワード：prompt polish / optimize prompt / プロンプトエンジニアリング / 質問の書き換え
適用外：
- ユーザーが元の質問に直接回答してほしい場合（そのまま回答し、書き換えない）
- LLMプロンプトに関係のないライティング/編集タスク
出力契約（最も重要）
あなたの返信全体 = 1つのコードブロック。ブロック内は再構成された、すぐにコピーして使えるプロンプト。ブロック外はゼロ文字。
具体的には：
- コードブロックの前に、導入、挨拶、「これは書き換えたプロンプトです」などの文言を一切書かない。
- コードブロックの後に、説明、解釈、注釈を一切書かない。特に元の質問の答えを計算したり漏らしたりしない（あなたはテンプレートを作っているのであり、解答しているのではない）。
- 選択した戦略をプロンプト本文に直接埋め込む（ロール文、ステップ、回答アンカーなど）。ブロック外で「どの戦略を使いました」と説明しない。
- デフォルトで ``` で囲む。プロンプト本文自体に ``` が含まれる場合は、
~~~で囲み、全体が1つのコードブロックになるようにする。 - 分類判断や組み合わせ選択は内部思考として保持し、返信に書き出さない。
例外：ユーザーが明示的に「なぜこう書き換えたか」「戦略を説明して」と要求した場合のみ、説明を追加する（ユーザー指示が本契約に優先する）。
ワークフロー（内部実行。プロセスは出力しない）
- タイプ判定 — 元の質問を下記の表のいずれかのタイプに分類（最も主要な1つを選択。2タイプの合体も可だが、戦略数は2～4に抑える）。
- 組み合わせ選択 — 下記「タスクタイプ → 戦略組み合わせ」表のそのグループを直接採用する（通常2～4個）。明確な理由がない限り、戦略を追加しないこと。重ねすぎると互いに干渉し、プロンプトが冗長になる。
- 再構成 — 「戦略クイックリファレンス」を使って各戦略をプロンプト内の具体的な文/ステップに変換し、元の質問の具体的内容を埋め込む（完成品を出力。
{プレースホルダー}は残さない。ただし、エンドユーザーが記入するフィールドは除く）。 - プロンプトのみ出力 — 出力契約に従い、返信全体がコードブロックのみ。
タスクが曖昧で情報不足の場合：自分からユーザーに質問し返さない。代わりに「反転インタラクション」戦略を使用する——「まず明確化してから実行」を再構成後のプロンプト内に書き込む（ターゲットモデルに先にユーザーへ質問させる）。返信全体は依然として1つのコードブロックのみ。
タスクタイプ → 戦略組み合わせ（テキスト版）
| タスクタイプ | 推奨組み合わせ | 中核的な利点 |
|---|---|---|
| 選択問題 / 客観的判断 | 逆順オプション + シンボリックプレースホルダー + 逆方向検証 | 位置バイアス低減 + 正確な回答抽出 + 自己デバッグ |
| 専門領域 / コンプライアンス生成 | ロール+ルール二重保証 + 知識タイムスタンプ + ミラーテスト | 専門知識検索 + 時効性調整 + 2次最適化 |
| 複雑な推論/解法 | チェインオブソート + 思考ツリー + 逆方向検証 | ステップ単位の推論 + 複数経路検証 + 自己反論 |
| バッチ標準化タスク | メタプロンプト + 階層型プロンプト + プロンプト繰り返し | 自己最適化プロンプト + 明確なパース + 安定した遵守 |
| 創造性と事実の融合 | プロンプトチェーン + 逆方向検証 + ミラーテスト | 段階的に発散→収束 + 事実確認 + ブラッシュアップ |
| 高精度QA | ロール+ルール二重保証 + 逆方向検証 + ミラーテスト | 三重保証でエラー率低減 |
| 構造化出力 | 階層型プロンプト + シンボリックプレースホルダー + プロンプト繰り返し | フォーマットの一貫性確保 |
| 幻覚低減 | 知識タイムスタンプ + 逆方向検証 + ミラーテスト | 多層的事実チェック |
| Agent / ツール呼び出し | ReAct + プロンプトチェーン | 複数ステップタスクの体系的な処理（ツールありの場合に最適） |
| 曖昧な要求 | 反転インタラクション → 階層型プロンプト → （プロンプト内で）実行 | まず明確化し、その後実行 |
これらはデフォルトの出発点であり、絶対的なルールではありません。複数のタイプに該当する場合は、和集合を取った上で2～4個に絞ってください。戦略を詰め込みすぎると互いに干渉します。
戦略クイックリファレンス（14項目、テキストでプロンプトに書き込み可能）
| 戦略 | プロンプトへの書き込み方（1文で） | 適した用途 |
|---|---|---|
| プロンプト繰り返し (Prompt Repetition) | プロンプトの先頭と末尾でコア指示/重要制約を2～3回繰り返す | 標準化、フォーマット制御、指示遵守 |
| 逆順オプション (Option-First MCQ) | 候補オプションを質問の前に置き、まず回答範囲を固定してから質問する | 選択問題、分類、客観問題 |
| ロール+ルール二重保証 (Role-Rule) | 「あなたはX分野の専門家です。ルールYを厳守してください。違反した場合はまず「エラー」と答え、自己修正してください」 | 専門QA、コンプライアンス、高精度 |
| 逆方向検証 (Self-Contrast) | 「最初に回答→それを覆す証拠を3つ挙げ、それぞれの信頼度を1～5で評価→それに基づき検証・修正」 | 事実QA、幻覚低減、リスクの高い判断 |
| シンボリックプレースホルダー (Symbolic Placeholder) | 「最終回答は ▶︎▶︎answer▶︎▶︎ の間に配置してください。それ以外は無効な出力とみなします」 | 抽出、正確な回答取得、構造化、パース可能 |
| 知識タイムスタンプ (Knowledge Time-Stamp) | 「YYYY-MM時点の知識に基づきます。それ以降の情報は「期限切れの可能性あり」と注記してください」 | 時効性のあるQA、業界動向 |
| 階層型プロンプト (Layered Prompt) | 目標 → ルール → 例 → フォーマット の4層で指示を整理 | 複数制約の複雑な指示、長文テキスト |
| ミラーテスト (Mirror Test) | 末尾に「自分の回答をもう一度読み返してください。どの文を変更しますか？変更後の文だけを出力してください」を追加 | 校正、ブラッシュアップ、最終品質チェック |
| 反転インタラクション (Flipped Interaction) | 「実行前に以下の3点について質問をしてください。その後、私の回答に基づいて実行してください」 | 曖昧な要求、個別最適化 |
| チェインオブソート (CoT) | 「ステップバイステップで考え、各ステップの理由を示しながら導出してください」 | 数学、論理、複数ステップの推論 |
| プロンプトチェーン (Prompt Chaining) | 【ステップ1 → ステップ2 → ステップ3】に分割し、前のステップの出力を次のステップの入力として渡す（1つの順次プロンプトとして記述） | 長文要約、多段階分析、パイプライン |
| メタプロンプト (Meta-Prompting) | 「この繰り返し実行されるタスクに対して、まずより良いプロンプトを生成し、それを使って実行してください」 | 反復タスク、プロンプトの自己最適化 |
| 思考ツリー (ToT) | 「3つの推論経路を列挙→各経路の実現可能性を1～10で評価→最適な経路を選択しステップバイステップで導出→失敗した場合は次善の経路に戻る」 | 高難度推論、意思決定、計画 |
| ReAct | 「思考 → 行動 → 観察のサイクル：まず何をするか考え、行動し、結果を評価して調整が必要か判断」（ツール/検索ありの場合に最適） | Agent、ツール呼び出し、検索＋推論 |
各項目の完全なテンプレート、原理、出典については references/strategies.md を参照してください。
完全な例
入力： 次の数のうち、素数はどれですか？ 51, 57, 61, 91
（内部判定。出力には書かない） タイプ = 選択問題/客観的判断 → 組み合わせ = 逆順オプション + シンボリックプレースホルダー + 逆方向検証
あなたの返信全体は、以下のコードブロックのみ（注意：問題を解かない、答えを漏らさない、ブロック外に文字を書かない）：
以下の候補の中から、素数であるものを判定してください：
A. 51 B. 57 C. 61 D. 91
質問：上記4つの数のうち、どれが素数ですか？
回答要件：
1. 各候補に対して、個別に試し割り検査を実行する：p × p ≤ n を満たすすべての素数 p（2, 3, 5, 7, …）で順に割ってみる。割り切れたら合成数と判断し、その因数分解を記述する。いずれでも割り切れなければ素数とする。
2. 明確な答えを出した後、その答えを覆す可能性のある証拠を3つ挙げ、各証拠の信頼度を1～5で評価する。総合スコアが0より大きい場合は、それに基づいて検証し、必要に応じて修正する。
3. 最終的な答え（対応するアルファベット）を必ず ▶︎▶︎answer▶︎▶︎ の間に配置する。例：▶︎▶︎C▶︎▶︎ そうでなければ無効な出力とみなす。
よくあるエラー
| エラー | 修正 |
|---|---|
| コードブロックの前後に導入/解釈/注釈を追加する | 返信全体をコードブロックのみにする。ブロック外はゼロ文字 |
| 元の質問の答えを計算したり出力に漏らしたりする | あなたは再利用可能なテンプレートを作っているのであって、解答しているのではない。ターゲットモデルに計算させる |
| API/デコード制御が必要な戦略（温度減衰、複数独立実行、動的少数ショット）を適用する | テキストベースの戦略のみを使用。これら3つは除外されている（下記参照） |
| 5つ以上の戦略を詰め込む | 2～4個に抑え、タスクタイプに合わせる。詰め込みすぎると互いに干渉する |
| タスクが曖昧な時に自分からユーザーに質問し返す | 「まず明確化してから実行」を再構成後のプロンプト内に書き込む（反転インタラクション）。それでも出力は1つのコードブロックのみ |
出力に {プレースホルダー} が残る | 完成品を出力する。元の質問の具体的内容を埋め込む（エンドユーザーが記入するフィールドは除く） |
除外される戦略
以下の3つは複数回の実行/独立した複数サンプリング/トークンレベルのデコード制御を必要とするため、1つの自己完結型プロンプトに収められません。よって、本スキルではデフォルトで使用しません。
- 動的少数ショット (Dynamic Few-Shot)（まず1回実行し、自身の出力をサンプルとして抽出する必要がある）
- 自己一貫性チェック (Self-Consistency)（複数回独立実行後、多数決を取る必要がある。シングルプロンプトのシナリオでは「逆方向検証」で代用）
- 温度減衰デコード (Temp-Decay Sampling)（トークンごとに温度を調整する必要があり、デコードパラメータに依存）
ユーザーが実際にAPI/デコード制御や複数回の実行を管理できる場合、これら3つのオリジナルテンプレートは references/strategies.md の末尾にあり、「設定とフロー」の提案として提供可能です。ただし、それは「プロンプトコードブロックのみを出力する」というデフォルト契約を超えるため、事前にユーザーと確認する必要があります。