最終更新: 2026/06/22 18:56
commontype: promptstatus: active
pageaudience: both

ADR Draft Canonical Template (起案者用)

Decision Pipeline (/drafts POST or scripts/draft_push.sh) に投入する起案テキスト (context フィールド) は本テンプレートの H2 セクション構造で書く。Pipeline body_generation がこの入力を canonical ADR 構造 (§1.1/§1.2/§2 決定/§3 判断基準…) に正規変換する。

⚠️ rendered ADR 構造で書かない — ### 1.1 背景 / ## 2. 決定 のように番号付き構造で起案テキストを書くと、(1) body_generation の正規化を浪費、(2) Cross-Validation のセクション構造比較が機能しない、(3) sub/main 間で起案フォーマットがズレる。下記の bullet 項目を そのまま H2 化 すること。

📦 payload の任意フィールド business / navGroup は draft.json 側に書く (起案本文 = context には書かない)。値と意味は operator_guide §4.1 を参照。

テンプレート本体 (下記をコピーして埋める)

## 何を解決するか

具体的な問題・目的を 2-3 段落で。**定量根拠** (実測値・件数・割合) を 1 つ以上含める。

## 採用したい方針

まず 1 文に圧縮する (Y-Statement)。埋まらない・Z に「かつ / および」が入るなら複数決定のサイン → 下の「粒度の目安」へ。

> **〔X 文脈〕** で **〔Y 課題〕** に直面し、**〔A 対抗案〕** ではなく **〔Z 選択〕** を選ぶ。**〔B 目的〕** のためであり、**〔C 代償〕** を受け入れる。

- **Z 採用**: 動詞ベースで 1 つだけ (「X を Y する」)
- **A 捨てた主要案**: 最低 1 つ
- **B 目的/価値**: 判断基準のドライバーと対応させる
- **C 代償・残るリスク**: 「特になし」と書きたくなったら検討が浅いサイン
- **語の注意**: ここでの「Y 課題」は直面している困りごと (構造正典 D-1 でいう問題・問題点)。早わかり箇条の「課題」(問題点ごとのやること) とは別語義

続けて 1 段落で要旨を展開する。Z→本節 / A→検討した代替案 / B→判断基準 / C→影響・撤退条件 に種として展開できる。

## 判断基準

(Standard 以上は必須 / ADR-0053) 評価軸を Q42 9 タグ (`#reliable` / `#flexible` / `#maintainable` / `#efficient` / `#usable` / `#operable` / `#suitable` / `#secure` / `#safe`) から 3-5 個選定 + 重要度 (Must/High/Medium) + K.O. 基準。粗くてよい。

## 検討した代替案

最低 2 つ、それぞれの不採用理由を 1-2 段落で。

## 影響

正の影響 / 負の影響 / リスク を箇条書きまたは表で。

## コスト試算

(Standard 以上は必須 / ADR-0088) 実装工数 (人日) + 運用コストを **粗くても数値 1 つ以上**。完璧でなく「数値で考えた痕跡」を残す。欠落は起案前ゲートで差し戻し対象。

## 撤退条件

(Standard 以上は必須 / ADR-0091) どうなったら戻すか。**数値 1 つ以上の閾値**を含める (例: 失敗率 20% 超で撤退)。

## Confirmation

(Standard/Critical は必須 / ADR-0036 / ADR-0091) 決定が実装で守られているかを継続的に検証する **3 要素**: 検証手段 / 実行頻度 / 違反時対応。観測可能 KPI (数値 1 つ以上) を含める。例: `adr-lint ルール XYZ` / `CI 毎` / `テスト失敗で merge block`。Light + 純ドキュメント ADR は N/A 許容 (理由必須)。

## 過去 ADR との関係

(推奨) 関連する既存 ADR を `ADR-NNNN: タイトル — 並立|補完|Supersede|Conflict` 形式で。

JSON 起案 (scripts/draft_push.sh 経由) の構造

{
  "author": "[email protected]",
  "title": "<人間可読タイトル>",
  "context": "<上記テンプレートを埋めた本文>",
  "options": "<検討した代替案 セクション抜粋 (任意、空文字でも可)>"
}

context は frontmatter なしで開始 (## 何を解決するか から)。Pipeline 側が ADR canonical frontmatter (Status: Proposed / Mode / Kruchten Type / Scope / Implementation Status / 起案者 / 起案日時) を自動付与する。

承認者メタ (ADR-0141): canonical frontmatter には承認者 4 欄も入る — approver_role (Scope 由来・ちょうど 1 つ・solo の既定は corporate = 代表取締役) / approver_who / driver (進行役 = 起案者) / consulted (相談先・拒否権なし・3 モデル調査等・任意) / informed (任意)。solo 運用では既定値で足り起案者の追加記入は不要 (役割と人の対応は 役割割当レジストリ を正とする)。

監査メモ (SoD 補償統制・ADR-0141): 1 人法人は Approver = Driver で職務分掌 (SoD) が成立しないため、Standard/Critical の起案では補償統制として DRP の独立 AI 審査 (起案者と異なる AI モデルを 1 つ以上含む 3 モデル調査・記録は docs/_internal/drp-reviews/) と Git の不変な承認履歴 を用いる。既存の 3 モデル調査がこれを兼ねる (追加作業なし)。

粒度の目安 (1 ドラフト = 1 論点 / RQ-097・強制ではない)

投入前に「これは 1 つの決定か」をセルフチェックする。まず上の Y-Statement で 1 文に圧縮できるか試す (1 文テスト)。次が 1 つでも当てはまれば分割を検討 (多論点は過剰審査ループ ADR-0109 を誘発):

  • 決定文に「かつ / および / また」「〜かもしれない」が入る
  • 独立して撤退できる決定が 2 つ以上 (決定変数 ≥ 2)
  • 判断基準 / 撤退条件 / KPI が別々に分かれる
  • Context が 1 ページ (〜800 語) を超える

ドライバー・撤退・supersede が完全一致するなら統合可。調査待ちは ADR でなく spike (下調べ) を先に。詳細: RQ-097 synthesis。目安であり機械強制はしない (2026-06-08)。

アンチパターン (rendered ADR 構造で書かない)

❌ 以下のように書かない:

### 1.1 背景
...
### 1.2 現状 (As-Is)
...
## 2. 決定
...
## 3. 判断基準 (Decision Drivers)
...

これは rendered ADR ファイル (docs/adr/NNNN-*.md) の構造であり、Pipeline body_generation の 出力 フォーマット。起案テキストは入力で、必ず上記の H2 bullet 形式で書く。

参照