prompt-optimizer

プロンプトオプティマイザー

概要

EARS（Easy Approach to Requirements Syntax）を使用して、曖昧なプロンプトを正確で実行可能な仕様に最適化します。EARS は、自然言語を構造化されたテスト可能な要件に変換する、ロールス・ロイスの方法論です。

方法論の着想元： EARS とドメイン理論に基づく手法を組み合わせるこのスキルのアプローチは、プロンプトを強化するための EARS の実践的な活用例を示した 阿星AI工作室 (A-Xing AI Studio) に着想を得ています。

4 層の強化プロセス：

1. EARS 構文への変換 - 説明的な表現を規範的な仕様に変換します
2. ドメイン理論に基づく構成 - 関連する業界のフレームワーク（GTD、BJ Fogg、ゲシュタルトなど）を適用します
3. 例の抽出 - 実際のデータを使った具体的なユースケースを明らかにします
4. 構造化プロンプトの生成 - Role/Skills/Workflows/Examples/Formats のフレームワークを使用して形式を整えます

使用するタイミング

次の場合に適用します：

• ユーザーが曖昧な機能リクエストを提示した場合（「ダッシュボードを作る」「リマインダーアプリを作る」）
• 要件に具体的な条件、トリガー、または測定可能な成果が欠けている場合
• 自然言語による説明を、テスト可能な仕様に変換する必要がある場合
• ユーザーがプロンプトの最適化や要件の改善を明示的に依頼した場合

6 ステップの最適化ワークフロー

ステップ 1：元の要件を分析する

弱点を特定します：

• 範囲が広すぎる - 「ユーザー認証を追加する」→ パスワード要件やセッション管理が不足しています
• トリガーが不足している - 「通知を送信する」→ 通知を送信するタイミングや理由が不足しています
• アクションが曖昧 - 「使いやすくする」→ 測定可能なユーザビリティ基準がありません
• 制約がない - 「支払いを処理する」→ セキュリティ要件やコンプライアンス要件が不足しています

ステップ 2：EARS 変換を適用する

要件を EARS パターンに変換します。構文規則の詳細については、references/ears_syntax.md を参照してください。

5 つの基本パターン：

1. 普遍的：The system shall <action>
2. イベント駆動型：When <trigger>, the system shall <action>
3. 状態駆動型：While <state>, the system shall <action>
4. 条件付き：If <condition>, the system shall <action>
5. 望ましくない動作：If <condition>, the system shall prevent <unwanted action>

簡単な例：

Before: "Create a reminder app with task management"

After (EARS):
1. When user creates a task, the system shall guide decomposition into executable sub-tasks
2. When task deadline is within 30 minutes AND user has not started, the system shall send notification with sound alert
3. When user completes a sub-task, the system shall update progress and provide positive feedback

変換チェックリスト：

• 暗黙の条件を特定し、明示します
• トリガーとなるイベントや状態を指定します
• 正確な動作を示す動詞（shall、must、should）を使用します
• 測定可能な基準を追加します（「30 分以内」「8 文字以上」）
• 複合要件を個別の要件に分割します
• 曖昧な表現（「使いやすい」「速い」）を削除します

ステップ 3：ドメイン理論を特定する

要件を確立されたフレームワークに対応付けます。全カタログについては、references/domain_theories.md を参照してください。

一般的なドメインの対応関係：

• 生産性 → GTD、ポモドーロ、アイゼンハワーマトリックス
• 行動変容 → BJ Fogg モデル（B=MAT）、アトミック・ハビッツ
• UX デザイン → ヒックの法則、フィッツの法則、ゲシュタルトの原則
• セキュリティ → ゼロトラスト、多層防御、プライバシー・バイ・デザイン

選定プロセス：

1. 要件のキーワードから主要なドメインを特定します
2. 相互に補完する理論を 2～4 個選びます
3. 理論の原則を具体的な機能に適用します
4. 信頼性を高めるため、強化後のプロンプトで理論を引用します

ステップ 4：具体的な例を抽出する

実際のデータを使った具体例を生成します：

• ユーザーシナリオ：「ユーザーがモバイル端末でログインしたとき……」
• データ例：「商品：『Laptop』、価格：999 ドル、在庫数：15」
• ワークフローの例：「タスク：レポートを書く → サブタスク：調査（2 時間）、下書き（3 時間）、編集（1 時間）」

例は、現実的で、具体的かつ多様（成功ケース／エラーケース／境界ケース）であり、テスト可能でなければなりません。

ステップ 5：強化されたプロンプトを生成する

標準的なフレームワークを使って構成します：

# Role
[Specific expert role with domain expertise]

## Skills
- [Core capability 1]
- [Core capability 2]
[List 5-8 skills aligned with domain theories]

## Workflows
1. [Phase 1] - [Key activities]
2. [Phase 2] - [Key activities]
[Complete step-by-step process]

## Examples
[Concrete examples with real data, not placeholders]

## Formats
[Precise output specifications:
- File types, structure requirements
- Design/styling expectations
- Technical constraints
- Deliverable checklist]

品質基準：

• 役割の具体性：「時間管理アプリを専門とするプロダクトデザイナー」＞「デザイナー」
• 理論的な根拠：フレームワークを明示的に参照します
• 実行可能なワークフロー：入力／出力と判断ポイントを明確にします
• 具体例：「例 1」「例 2」ではなく実際のデータを使います
• 測定可能な形式：「優れたデザイン」ではなく具体的な要件を示します

ステップ 6：最適化の結果を提示する

構造化された形式で出力します：

## Original Requirement
[User's vague requirement]

**Identified Issues:**
- [Issue 1: e.g., "Lacks specific trigger conditions"]
- [Issue 2: e.g., "No measurable success criteria"]

## EARS Transformation
[Numbered list of EARS-formatted requirements]

## Domain & Theories
**Primary Domain:** [e.g., Authentication Security]

**Applicable Theories:**
- **[Theory 1]** - [Brief relevance]
- **[Theory 2]** - [Brief relevance]

## Enhanced Prompt
[Complete Role/Skills/Workflows/Examples/Formats prompt]

---

**How to use:**
[Brief guidance on applying the prompt]

高度なテクニック

複雑なシナリオについては、references/advanced_techniques.mdを参照してください：

• 複数のステークホルダーの要件 - ユーザータイプごとの EARS 文
• 非機能要件 - 定量化されたしきい値を含むパフォーマンス、セキュリティ、スケーラビリティ
• 複雑な条件ロジック - ブール演算子を使った入れ子の条件

クイックリファレンス

推奨事項： ✅ 複合要件を分解する（要件ごとに EARS 文を 1 つ） ✅ 測定可能な基準を指定する（数値、期間、割合） ✅ エラーケースや境界ケースを含める ✅ 確立された理論に基づかせる ✅ 実際のデータを使った具体例を用いる

避けること： ❌ 曖昧な表現（「高速」「使いやすい」）を避ける ❌ 暗黙の知識を前提としない ❌ 1 つの文に複数のアクションを混在させない ❌ 例にプレースホルダーを使わない

リソース

必要に応じて、以下のリファレンスファイルを読み込みます：

• references/ears_syntax.md - EARS 構文の完全なルール、5 つすべてのパターン、変換ガイドライン、メリット
• references/domain_theories.md - 10 のドメイン（生産性、UX、ゲーミフィケーション、学習、E コマース、セキュリティなど）に分類された 40 以上の理論
• references/examples.md - 変換例 4 件（先延ばし対策アプリ、E コマースの商品ページ、学習ダッシュボード、パスワードリセットのセキュリティ）の完全な例。変換前後の比較と再利用可能なテンプレートを含みます
• references/advanced_techniques.md - 複数のステークホルダーの要件、非機能仕様、複雑な条件ロジックのパターン

リファレンスを読み込むタイミング：

• EARS 構文の説明が必要な場合 → ears_syntax.md
• ドメイン理論の選定に幅広い選択肢が必要な場合 → domain_theories.md
• ユーザーが複数の最適化例を求めている場合 → examples.md
• 複数のステークホルダーや非機能仕様を伴う複雑な要件の場合 → advanced_techniques.md