BA は日々 AI を使用しています。ドキュメント要約、受け入れ基準案作成、要件レビュー、テストケース作成。しかし、プロンプトが注意深く作成されないと、AI 出力は汎用的、文脈不適切、または必要な形式がありません。
このガイドは AI エンジニアリングを教えるものではありません。これは BA に日常業務に十分なプロンプトを作成する方法を教えます。
1. RPCF フレームワーク
効果的なプロンプトの 4 つの要素：
| 要素 | 意味 | 例 |
|---|---|---|
| Role | AI は何の役割を果たすか？ | 「あなたは 10 年間の金融科学技術経験を持つシニア BA です」 |
| Purpose | プロンプトの具体的な目標 | 「次の受け入れ基準をレビューしてください」 |
| Context | 必要な背景 | 「プロジェクトは小売顧客向けの銀行モバイルアプリです」 |
| Format | 望ましい出力形式 | 「箇条書きで返す、最大 10 ポイント」 |
RPCFなしのプロンプト：
「受け入れ基準をレビューしてください。」
RPCF付きプロンプト：
「あなたはアジャイル経験を持つシニア BA です。銀行モバイルアプリ内の送金機能の以下の受け入れ基準をレビューしてください。目標：不足しているエッジケースとロジック矛盾を見つけることです。返す形式：(1) 不足しているエッジケース、(2) ロジック矛盾、(3) 提案 — 各セクション最大 5 ポイント。 [PASTE AC]」
2. 一般的な BA プロンプトパターン
パターン 1：レビューと批評
あなたは [役割] です。[ドキュメント/成果物] を [具体的な基準] に対してレビューしてください。
コンテキスト：[プロジェクト/ドメイン説明]。
戻す形式：[出力形式]。
---
[PASTE CONTENT]
パターン 2：最初のドラフト生成
[ドキュメントタイプ] を [対象者] 向けに [条件/制約] で作成してください。
コンテキスト：[プロジェクトコンテキスト]。
形式：[アイテム数、見出しレベル、言語]。
追加：[特別な要素があれば、例：「AI 機能のエッジケース」]。
パターン 3：形式を変換
[入力形式] を以下の [出力形式] に変換します。
変更しない：[何を変更しないか]。
追加：[不足しているものを追加する]。
---
[PASTE CONTENT]
パターン 4：質問回答・明確化シミュレーション
あなたは [ステークホルダー役：PM/CTO/エンドユーザー/コンプライアンス] です。
要件を提示します。この要件について [この役割] が最も難しく求めるであろう 5 つの質問をしてください。
---
[PASTE REQUIREMENTS]
3. BA 日常業務用プロンプト
長いドキュメント要約
以下のドキュメントを BA の視点から要約します。要件を作成するために必要なもの：
- 主要なビジネス目標
- ステークホルダーと役割
- 重要な制約条件（時間、予算、コンプライアンス）
- 明確化が必要な曖昧な点
最大 300 語。
---
[PASTE DOCUMENT]
インタビュー質問作成
[ステークホルダー役] に [プロジェクト説明] についてインタビューしようとしています。
次の構造で 10 のディスカバリー質問を作成します：
- 現在のプロセスについて 3 つ
- 問題点について 3 つ
- 期待/成功基準について 2 つ
- 制約条件について 2 つ
はい/いいえ質問を避けてください。オープンエンドの質問を優先します。
BRD / SRS をレビュー
以下の BRD をレビューして、評価します：
1. 曖昧またはメジャーできない要件はどれですか？
2. 非機能要件が不足していますか？
3. 要件間に矛盾がありますか？
4. 明確に述べられていない仮定がありますか？
テーブルで返す：| 要件 ID | 問題 | 提案される修正 |
---
[PASTE BRD SECTION]
AC からテストシナリオを作成
以下の受け入れ基準から、Given/When/Then 形式でテストシナリオを作成します：
- 3 つのハッピーパスシナリオ
- 3 つのエラー/エッジケースシナリオ
- 2 つのパフォーマンス/ロードシナリオ
コンテキスト：[機能説明と環境]
---
[PASTE ACCEPTANCE CRITERIA]
4. 高度なテクニック：チェーンプロンプティング
複雑なタスクの場合、すべてを 1 つのプロンプトに無理矢理に入れないでください。複数のステップにチェーンします：
例：インタビュートランスクリプト → ユーザーストーリー
ステップ 1：「トランスクリプトを優先順位付けされた問題ポイントのリストに要約する」
ステップ 2：「これらの問題ポイントからビジネスドメイン別にエピックを作成」
ステップ 3：「エピック [X] を INVEST に従う 3～5 ユーザーストーリーに展開」
ステップ 4：「ストーリー [Y] について、Given/When/Then 形式で受け入れ基準を作成」
利点：BA は次のステップに渡す前に各ステップの出力をレビューします。複合エラーを削減します。
5. 製品内の AI 機能用プロンプト
BA が AI 機能を仕様化する場合、製品のシステムプロンプトを定義します：
システムプロンプトテンプレート
## システムプロンプトテンプレート [機能名]
**役割割り当て：**
あなたは [AI の製品内での役割、例：「銀行アプリ用カスタマーサービスアシスタント」] です。
**スコープ：**
[特定のドメイン] に関する質問にのみ答えてください。
[スコープ外のトピック] については答えないでください。
**トーンと形式：**
- 言語：英語、丁寧、専門的
- レスポンス長：最大 [X] 文
- 形式：[プレーンテキスト / マークダウン / 箇条書き]
**エスカレーション：**
質問が [トリガーキーワードリスト] に関与する場合、以下を言ってください：
「スペシャリストに接続する必要があります。お待たせします。」
**決してしない：**
- [機密トピック] についてアドバイスを与える
- チャット経由でアカウント情報を確認する
- ポリシー外の約束をする
6. プロンプト品質を評価
良いプロンプトは以下を生成します：
- 一貫した出力（同じ入力 → 同じ一般的な出力）
- 文脈的に正確な回答
- リクエストされた形式の出力
- 最小限の幻覚
本番環境で使用する前にプロンプトをテストします：
- 同じプロンプト、異なる入力 → 一貫したスタイル？
- 出力がビジネスコンテキストと一致？
- 形式が常に正しいですか？
- 明らかな幻覚はありますか？
まとめ
プロンプト設計は BA スキルです。AI エンジニアリングではありませんが、AI との専門的なコミュニケーションです。RPCF をマスターし、体系的にテストし、繰り返します。十分に設計されたプロンプトは何時間も再作業を節約します。曖昧なプロンプトは再作業に時間を浪費します。
次から始めます：役割 + 目的 + コンテキスト + フォーマットを定義します。テストします。繰り返します。最高のプロンプトを会社のテンプレートとして保持して再利用します。