prompt-optimizer

概要

プロンプト最適化とは、意図を機械が実行可能な指示へと落とし込む技術です。このスキルでは、4-D 方法論（分解、診断、開発、提供）を適用し、プロンプトが明確で構造化され、特定のモデルアーキテクチャ（例：Claude の XML タグ形式と OpenAI が好む Markdown 形式）に合わせて最適化されていることを確認します。

鉄則

4-D 監査を実行せずにプロンプトをリリースしてはなりません

プロンプトを監査しないと、「ドリフト」が発生し、曖昧さや構造上の弱点により、AI の出力がユーザーの意図から徐々に逸脱します。

状態遷移図

digraph prompt_optimization_flow {
    "Rough Input" [shape=doublecircle];
    "Deconstruct: Intent & Context" [shape=box];
    "Diagnose: Ambiguity Audit" [shape=box];
    "Develop: Apply Frameworks" [shape=box];
    "Deliver: Final Construction" [shape=box];
    "Validation: Test Run" [shape=diamond];
    "Optimized Prompt" [shape=doublecircle];

    "Rough Input" -> "Deconstruct: Intent & Context";
    "Deconstruct: Intent & Context" -> "Diagnose: Ambiguity Audit";
    "Diagnose: Ambiguity Audit" -> "Develop: Apply Frameworks";
    "Develop: Apply Frameworks" -> "Deliver: Final Construction";
    "Deliver: Final Construction" -> "Validation: Test Run";
    "Validation: Test Run" -> "Optimized Prompt" [label="pass"];
    "Validation: Test Run" -> "Diagnose: Ambiguity Audit" [label="fail"];
}

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

• AI が「幻覚」による回答や無関係な回答を返す場合。
• 新しいシステムプロンプトや「SKILL.md」ファイルを作成する場合。
• 複雑なタスクをモデル向けに分解する必要がある場合。
• モデルに特定の出力形式（JSON、XML、Markdown）を強制する必要がある場合。

このスキルを使用しない場面

• 高い精度が必要ない、シンプルな会話形式の問い合わせの場合。
• ボトルネックが指示セットではなく、モデルの知識のカットオフである場合。

コアプロセス

ステップ 1：分解（中核となる意図の抽出）

プロンプトを最小単位に分解します。以下を特定します。

• 役割： AI はどのような存在として振る舞うべきですか？（出典：Anthropic）。
• 目標： 具体的で測定可能な成果は何ですか？
• 制約： 絶対に起きてはならないことは何ですか？（出典：OpenAI）。

ステップ 2：診断（「漏れ」の監査）

構造上の弱点を探します。

• 曖昧さ： 「より良く」「速く」「創造的に」といった言葉の定義が曖昧なままになっていませんか？
• 認知負荷： プロンプトで一度に多くのことをしようとしていませんか？
• 形式の不足： 希望する出力構造は明確に定義されていますか？（出典：Anthropic）。

ステップ 3：開発（最適化フレームワークの適用）

タスクの複雑さに応じて、適切な手法を選択します。

• Chain of Thought（CoT）： 回答する前に、<thinking> タグ内でモデルに「思考」させます（出典：Anthropic）。
• Few-Shot Learning： 入力と出力のペアを、高品質な例として 2～3 件提示します。
• XML による構造化： タグ（例：<context>、<task>、<example>）を使って、指示とデータを分けます（出典：Anthropic）。
• 参照テキスト： 幻覚を最小限に抑えるため、モデルが使用すべき正確なテキストを提示します（出典：OpenAI）。

ステップ 4：提供（最終的な構成）

「ボトムアップ」方式で、最適化されたプロンプトを組み立てます。

1. 役割の定義。
2. コンテキスト／背景。
3. タスク／指示（手順に分割）。
4. 出力形式の仕様。
5. 例（該当する場合）。

他のスキルの呼び出し

• 必須のサブスキル：writing-skills — プロンプトが TDD の原則（テスト可能な成果）に従っていることを確認します。
• 推奨するサブスキル：non-fiction-precision — 指示の表現を明確かつ簡潔にします。

合理化の表

考え	実際
「簡単な依頼だから、タグは必要ない。」	簡単な依頼こそ、モデルが「手抜きの回答」をしがちです。
「モデルは十分賢いから、意図を理解してくれる。」	知性は、意図を明確に設計することの代わりにはなりません。
「もっと言葉を足せば、明確になるだろう。」	冗長な表現は、モデルの注意を散漫にすることがよくあります。代わりに構造を使いましょう。
「4-D 監査をする時間がない。」	悪いプロンプトの修正にかかる時間は、監査にかかる時間を上回ります。

危険信号

• 「モデルが指示を聞いていない」 → 制約が矛盾しているか、役割の定義が弱い可能性があります。
• 「出力が一般的すぎる」 → 具体的な制約や「Few-Shot」の例が不足しています。
• 「テキストの壁」 → モデルが意図を解析しやすくする区切り（Markdown または XML）を使用していません。

診断チェックリスト

• プロンプトで具体的な役割を定義していますか？
• 指示とデータをXML タグまたは区切り記号で分けていますか？
• Chain of Thought の指示（例：「段階的に考えてください」）がありますか？
• 出力形式の要件（例：JSON、長さ、トーン）を明示していますか？
• プロンプトに、少なくとも 1 つの否定的制約（避けるべきこと）が含まれていますか？

参考資料

• OpenAI、『Prompt Engineering Guide』（タスク分解の戦略）。
• Anthropic、『Prompt Engineering Documentation』（XML タグとロールプロンプティングの使用）。
• Anthropic、『Prompt Engineering Documentation』（4-D 方法論）。