テック×CSの共通言語を作る
プロンプトレビュー会の進め方とテンプレ
実装者（テック）と現場（CS）の間で、プロンプトを「評価できる会議」に変えるための設計図です。目的は、属人的な改善を減らし、品質を再現可能にすること。レビュー会は、合意形成の場であり、学習の場でもあります。
なぜ「レビュー会」が必要か
チャットボットの品質は、モデル精度だけで決まりません。プロンプトには、判断基準・トーン・優先順位・安全配慮が埋め込まれています。つまり、良いプロンプトは「文章」ではなく「仕様」です。
レビュー会を通して仕様を言語化すると、次の効果が出ます。(1) 期待値のズレが減る。(2) 改善の効果を比較できる。(3) 部門をまたいだ学習が蓄積される。
会のゴール（最初に固定する）
- 1 プロンプトの「意図」と「制約」を、参加者全員が同じ言葉で説明できる状態にする。
- 2 代表シナリオ（問い合わせタイプ）ごとの合否基準を決め、改善前後を比較できる形にする。
- 3 次アクション（誰が、いつまでに、何を試すか）を必ず残す。
レビュー会の進行（60分テンプレ）
0〜10分：共有
- 対象（プロンプト/機能/シナリオ）を明確化
- 現状の課題を「症状」ではなく「失敗の型」で説明
- 前回の決定事項と差分の確認
10〜30分：評価
- 評価観点（意図・制約・出力形式・安全配慮）で読む
- 代表シナリオで「合う/合わない」を切る
- 改善案をその場で複数出す（断定しない）
30〜45分：合意
- 優先順位をつける（致命/重要/改善）
- 修正方針を文章化（なぜ直すかを残す）
- 検証方法（ログ/採点/再現性）を決める
45〜60分：決める
- 次回までの宿題を担当と期限で固定
- 改善案の採用/非採用の理由を残す
- 必要ならデータ収集の手当てを決める
テンプレ：プロンプトレビューシート（コピペ用）
以下をそのまま会議の前に配り、当日は空欄を埋めるだけにします。
対象
機能名：＿＿＿＿＿＿＿＿ / プロンプト名：＿＿＿＿＿＿＿＿ / 対象チャネル：＿＿＿＿＿＿＿＿
目的（意図）
ユーザーの問い合わせを、次の観点で正しく分類・回答する。＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
制約（してはいけない）
- 曖昧な情報は断定しない
- 推測が必要なら確認質問を挟む
- 社内ルール（禁止表現/免責/参照先）がある場合は従う
代表シナリオ（合否基準つき）
シナリオA：＿＿＿＿＿＿＿＿ → 合格条件：＿＿＿＿＿＿＿＿ / 不合格条件：＿＿＿＿＿＿＿＿
シナリオB：＿＿＿＿＿＿＿＿ → 合格条件：＿＿＿＿＿＿＿＿ / 不合格条件：＿＿＿＿＿＿＿＿
シナリオC：＿＿＿＿＿＿＿＿ → 合格条件：＿＿＿＿＿＿＿＿ / 不合格条件：＿＿＿＿＿＿＿＿
現状の失敗の型（どれかに分類）
- 誤分類：意図は合っているが別カテゴリに誘導される
- 不足：必要な確認が抜ける
- 逸脱：制約に反して断定/禁止表現が混ざる
- 形式崩れ：出力フォーマットが崩れ、CSで再加工が必要になる
改善案（複数出してから絞る）
案1：＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿（期待効果：＿＿＿＿＿＿＿＿）
案2：＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿（期待効果：＿＿＿＿＿＿＿＿）
案3：＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿（期待効果：＿＿＿＿＿＿＿＿）
採用/非採用の理由
採用：＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ / 非採用：＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
次アクション
担当：＿＿＿＿ / 期限：＿＿＿＿ / 検証方法：＿＿＿＿ / 次回持ち寄り：ログ/サンプル＿＿＿＿
会議で揉めやすいポイントと、決め方
- 「良い回答」の定義は先に合否基準に落とします。感想ベースではなく、シナリオ単位で採点できる形にする。
- トーンの調整は、誰がいつ使うか（一次対応/エスカレーション前）で方針を分岐させます。全体最適にしない。
- ログを見る時間は、レビュー会の一部として固定し、宿題ではなく会議内で判断できる量に切ります。
次の一手：レビュー会を「運用」にする
初回はテンプレどおりに回せるだけでも十分です。2回目で「失敗の型」の分類精度を上げ、3回目で採点とログ運用を定着させます。小さく始め、合否基準を更新していく。これが、テック×CSの共通言語を作る最短ルートになります。
関連テーマ
レビュー会の改善を次に繋げるため、他の記事も併せて確認してください。