プロンプト最適化スキル

概要

EARS (Easy Approach to Requirements Syntax) を使用して、曖昧なプロンプトを正確で実行可能な仕様に最適化します。自然言語を構造化された、テスト可能な要件に変換するための Rolls-Royce 級の方法論です。

方法論の参考元： このスキルが 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. ユビキタス: システムは <アクション> する
2. イベント駆動: <トリガー> のとき、システムは <アクション> する
3. 状態駆動: <状態> の間、システムは <アクション> する
4. 条件付き: <条件> の場合、システムは <アクション> する
5. 不要な動作: <条件> の場合、システムは <不要なアクション> を防止する

簡単な例：

変換前: 「タスク管理機能を備えたリマインダーアプリを作成する」

変換後 (EARS):
1. ユーザーがタスクを作成したとき、システムは実行可能なサブタスクへの分解をガイドする
2. タスク期限が30分以内 かつ ユーザーがまだ開始していないとき、システムは音声アラート付きで通知を送信する
3. ユーザーがサブタスクを完了したとき、システムは進捗を更新し、ポジティブなフィードバックを提供する

変換チェックリスト：

• 暗黙的な条件を特定して明示的にする
• トリガーイベントまたは状態を指定する
• 正確なアクション動詞を使用する（shall、must、should）
• 測定可能な基準を追加する（「30分以内」「最低8文字」）
• 複合要件を原子的なステートメントに分割する
• 曖昧な言語を削除する（「ユーザーフレンドリー」「高速」）

ステップ 3: ドメイン理論を特定

確立されたフレームワークに要件をマッピングします。完全なカタログについては references/domain_theories.md を参照してください。

一般的なドメインマッピング：

• 生産性 → GTD、ポモドーロ・テクニック、アイゼンハワー・マトリクス
• 行動変容 → BJ Fogg モデル (B=MAT)、アトミック・ハビット
• UX デザイン → ヒックの法則、フィッツの法則、ゲシュタルト原理
• セキュリティ → ゼロトラスト、Defense in Depth、Privacy by Design

選択プロセス：

1. 要件キーワードからプライマリドメインを特定
2. 2～4つの補完的な理論にマッピング
3. 理論原則を特定機能に適用
4. 信頼性のため強化プロンプトで理論を引用

ステップ 4: 具体的な例を抽出

実データを含む具体的な例を生成：

• ユーザーシナリオ：「ユーザーがモバイルデバイスでログインしたとき...」
• データ例：「製品：『ノートパソコン』、価格：$999、在庫：15」
• ワークフロー例：「タスク：レポートを作成 → サブタスク：リサーチ (2時間)、ドラフト (3時間)、編集 (1時間)」

例は リアルな、具体的な、多様な（成功/エラー/エッジケース）、テスト可能な ものである必要があります。

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

標準的なフレームワークを使用して構造化：

# Role
[ドメイン専門知識を持つ特定のエキスパートロール]

## Skills
- [コア機能 1]
- [コア機能 2]
[ドメイン理論と連携した5～8のスキルをリスト]

## Workflows
1. [フェーズ 1] - [主要活動]
2. [フェーズ 2] - [主要活動]
[完全なステップバイステップのプロセス]

## Examples
[実データを含む具体的な例、プレースホルダーではなく]

## Formats
[正確な出力仕様：
- ファイルタイプ、構造要件
- デザイン/スタイリング期待値
- 技術的制約
- 納品物チェックリスト]

品質基準：

• Role 特異性: 「時間管理アプリ専門のプロダクトデザイナー」 > 「デザイナー」
• 理論グラウンディング: フレームワークを明示的に参照
• 実行可能なワークフロー: 明確なインプット/アウトプットと決定ポイント
• 具体的な例: 実データ、「例1」「例2」ではなく
• 測定可能なフォーマット: 具体的な要件、「良いデザイン」ではなく

ステップ 6: 最適化結果を提示

構造化フォーマットで出力：

## 元の要件
[ユーザーの曖昧な要件]

**特定された問題：**
- [問題 1：例えば「具体的なトリガー条件が不足」]
- [問題 2：例えば「測定可能な成功基準がない」]

## EARS 変換
[番号付きの EARS フォーマット要件リスト]

## ドメイン & 理論
**プライマリドメイン：** [例：認証セキュリティ]

**適用可能な理論：**
- **[理論 1]** - [簡潔な関連性]
- **[理論 2]** - [簡潔な関連性]

## 強化されたプロンプト
[完全な Role/Skills/Workflows/Examples/Formats プロンプト]

---

**使用方法：**
[プロンプト適用に関する簡潔なガイダンス]

高度な技術

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

• マルチスタッホルダー要件 - 各ユーザータイプの EARS ステートメント
• 非機能要件 - 定量的なしきい値を持つパフォーマンス、セキュリティ、スケーラビリティ
• 複雑な条件付きロジック - ブール演算子を使用したネストされた条件

クイックリファレンス

すべき事： ✅ 複合要件を分割（1つの 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