最終更新: 2026/06/22 18:56
プロンプト設計パターン集（効いた型のプレイブック）
TL;DR（このページは何か・専門語ゼロ）: このリポで実際にうまく動いているプロンプトから、「中身の書き方の型」だけを抜き出した参考集。新しくプロンプトを書くときに、ゼロから考えず・過去の生プロンプトを漁らずに、ここの型を真似して使う。一般論やツールの話ではなく、自分たちの実プロンプトで効いている書き方に絞る。
1. 位置づけ（他ドキュメントとの境界）
本ページは「このリポの実プロンプトで効いた"中身の型"」に特化する。周辺ドキュメントと重複させない:
| ドキュメント | 扱うもの | 本ページとの違い |
|---|---|---|
| RQ-044_synthesis | プロンプト管理の外部ベストプラクティス | 外部知見。本ページは自リポ由来の型 |
| prompt_lifecycle_guide | 運用手順（追加 / 更新 / ロールバック） | 回し方。本ページは書き方 |
| prompt-lint_rules | prompt.meta.yaml の規約 | フロントマター規約 |
| prompt_catalog | 全プロンプトの索引 | どこに何があるか。本ページはどう書くか |
2. 全プロンプト共通の型（cross-cutting）
種別を問わず、このリポのプロンプトで繰り返し効いている共通則:
- 出力を機械可読に固定: 「**JSON のみを返す。前置き・解説・コードブロックの ``` も禁止**」を明示（
prompts/01_triage.md/02_scoring.md）。後段がパースする出力は必ずこれ。 - 文字数上限を必ず付ける:
reason（80 字以内）・suggested_title（30 字以内）・feedback_for_user（150 字以内）のように、自由記述フィールドには上限を書く。冗長化と verbosity bias〔冗長な回答を高評価する偏り〕を抑える。 - 減点語彙を明示する: 採点系では「書かれていない / 一般論 / 検証されていない は容赦なく減点」と、甘く採点しない方向の語を入れる（
02_scoring.md）。 - 引用は本文実在文字列のみ: レビュー系で「quote には ADR 本文中に実際に存在する文字列を正確に引用」と縛り、幻覚〔hallucination＝存在しない引用の捏造〕を防ぐ（
05_parallel_review.md）。 - 人間/PR にそのまま渡せる形で出す:
score_summary_mdのように「PR にそのまま貼れる Markdown 表」を出力に含める。 - 数値しきい値は calibrate 前提と明記: 35/40/45 等の閾値は「組織内ヒューリスティクスで絶対根拠なし」と注記し、検証ケースで弁別力を実証してから使う（
01_triage.md）。
3. 型カタログ（6 種）
3.1 審査・採点プロンプト（Judge 型）
- 用途: 生成物を点数・合否で評価する（Gate 4 Scoring）。
- 骨格:
[採点ルール]（N 項目 × 5 点 / 減点語彙）→[出力ルール]（JSON のみ）→ 観点テーブル →weakest_items+feedback_for_user。 - 効いている点: LLM-as-Judge〔LLM を評価者として使う手法〕のバイアス対策として、Self-Consistency〔同一プロンプトを複数回実行して多数決〕N=5（ADR-0056）と rubric〔採点基準表〕を併用。
- 実例:
docs/_internal/03_decisions/decision_pipeline/prompts/02_scoring.md
3.2 分類・判定プロンプト（Triage 型）
- 用途: 入力を enum〔列挙値〕に振り分ける（ADR 要否 / Mode 判定）。
- 骨格: JSON 出力 + 条件付き必須フィールド（
is_adr_worthy=trueのときだけmode・suggested_title必須）+ 判断基準テーブル（適用条件 + 学術的対応）。 - 効いている点: enum の各値が下流の何を制御するか（mode → 採点閾値）を明記し、判定のブレを減らす。
- 実例:
prompts/01_triage.md
3.3 多モデル並列レビュー（annotation 型）
- 用途: 1 つの成果物を複数モデルで多角レビューし、本文引用付きの注記を返す（Gate 3）。
- 骨格: 3 モデルの役割分担表 → 共通の
[レビュー観点]→annotations[]（quote+ コメント）。 - 効いている点:
Promise.allSettledによる fail-open〔一部モデルが落ちても残りで継続〕（ADR-0081）で単独障害に強い。判定はせず情報提供に徹する。 - 実例:
prompts/05_parallel_review.md
3.4 起案・操作プロンプト（operator / one-shot 型）
- 用途: 別セッションの Claude Code に一連の操作（KV 投入 → 起案 → 報告）を一括指示する使い捨てプロンプト。
- 骨格: frontmatter（
type/target_session/target_endpoint/status）→## あなたの役割→## 前提情報（API 仕様・スキーマ）→## 起案内容（ADR テンプレートに準拠: 何を解決 / 方針 / 代替案 / 影響 Good-Bad-Trade-off / 撤退条件 / Confirmation）→ 報告。 - 効いている点: 起案内容を ADR テンプレ構造に合わせることで、Pipeline の Gate を通りやすい下書きになる。実行後は
status: archived（ADR-0042 追補）。 - 実例:
decision_pipeline/adr_pipeline_temperature_strategy_kv_submission_prompt.md（archived）
3.5 調査メタプロンプト（RQ 型）
- 用途: Deep Research〔多段の深掘り調査〕用プロンプトを生成する meta-prompt〔プロンプトを生成するプロンプト〕。
- 骨格:
Research Question→Context（300-500 words）→Questions（3-5 個）→Output→ 生成後の Anti-pattern チェックリスト。_meta_prompt → _prompt → 各モデル _result → _synthesisの流れで運用。 - 効いている点: 調査の粒度・出力形式を型で固定し、3 モデルの結果を
_synthesisに蒸留して再利用。 - 実例:
scripts/deep_research_meta_prompt.md/research_prompts/RQ-044_*
3.6 案件展開メタプロンプト（テンプレート型）
- 用途: 案件 ID を入れると、案件固有のプロンプトを自動生成する（開発仕様書づくり）。
- 骨格: 汎用プロンプト本文 + それを案件向けに具体化する
## メタプロンプトの二段構え。 - 効いている点: 汎用を直接使うより、案件の設計要件・エッジケース・関連ファイルを事前分析した精度の高いプロンプトを生成できる。
- 実例:
docs/_internal/04_specs/dev_spec_prompt_template.md
4. 使い方
- 書きたいプロンプトの種別を §3 から選ぶ。
- その型の「骨格」をコピーし、§2 の共通則（JSON 固定・文字数上限・減点語彙・実在引用）を必ず織り込む。
- 既存の「実例」ファイルを下敷きにする（prompt_catalog で該当を探す）。
- 本番（Type 1）に載せるなら prompt_lifecycle_guide と prompt-lint_rules に従う。