ADR 間の型付き辺の意味監査手順

結論を先に: ADR どうしの型付き辺（ADR-0131）が「意味として正しい型か」を、四半期ごとに 22 件サンプリングで点検する手順。決定は ADR-0133。判定ルーブリック・低確信/判定割れの閾値・judge drift 検証の正典はこのページ。記録は ADR 間の型付き辺 監査記録 に残す。

1. 目的と位置づけ

• CI の整合 lint が保証するのは構文だけ。参照先の実在・双方向の対称・状態の一致・循環なしの 4 点。
• 辺の型が意味として正しいか — 例: depends_on と宣言した関係が本当に依存か — は lint では分からない。
• この意味の点検を四半期サンプリング監査で行う。「lint = 構文 / 監査 = 意味」の責務分担は ADR-0117 が Covers: 参照で確立したもので、ADR-0133 が ADR 間の辺へ拡張した。
• 監査のサイクル・運用主体・間引き規定は ADR-0117 の既存運用に相乗りする。上書きするのはサンプル数（22 件・c=0）と判定ロジック（§4〜§7）のみ。
• ADR-0131 初期移行の受け入れ検査（層別サンプリング・relates_to 以外の各型から最低 2 件）も、§4 と同じ判定ルーブリックを使う。

2. 開始条件

次の 3 つがすべて満たされた直後の四半期から開始する（ADR-0133 §決定）。

1. ADR-0131 の初期移行（既存 ADR 全数への辺ブロック追記 + 受け入れ検査 + lint error 昇格）が完了している。
2. ADR-0107 が受理済みで adr-index.json が存在する。
3. adr-index.json の辺フィールド完全性テストが CI で green。

3. Step 1 — サンプル抽出（無作為 22 件・seed 記録）

母集団 = adr-index.json にある ADR 間の型付き辺の全数。手作業のリストは作らない（ADR-0130 規律）。

node -e '
const idx = require("./docs/adr/adr-index.json"); // リポジトリのルートで実行する
// forward 7 種だけを数える。index には逆辺 (superseded_by 等) も入っており、
// 逆辺まで数えると同じ関係を 2 回数えてしまうため。7 種の正典 = scripts/lib/adr_edges.mjs の FORWARD_KEYS
const FORWARD = new Set(["supersedes", "amends", "refines", "depends_on", "relates_to", "conflicts_with", "follows_up_on"]);
const seed = Number(process.argv[1]) >>> 0;
let s = seed;
const rnd = () => ((s = (s * 1664525 + 1013904223) >>> 0) / 4294967296);
const edges = idx.adrs.flatMap(a => Object.entries(a.edges ?? {})
  .filter(([type]) => FORWARD.has(type))
  .flatMap(([type, ts]) => ts.map(to => ({ from: a.id, type, to }))));
for (let i = edges.length - 1; i > 0; i--) {
  const j = Math.floor(rnd() * (i + 1));
  [edges[i], edges[j]] = [edges[j], edges[i]];
}
console.log(JSON.stringify({ seed, total: edges.length, sample: edges.slice(0, 22) }, null, 2));
' 20260901  # seed は「実施年月日」等で決め、記録ページに残す（再現可能にするため）

• 小母集団補正: 総辺数 N に対し 22/N が 10% を大幅に超える場合（例: N=75 で 29%）、無限母集団近似が崩れて c=0 が過剰保守的になる。超幾何分布でサンプル数と棄却基準を再計算する（ADR-0133 §5.3・計算根拠は RQ-102 synthesis Q4）。
• 暫定抽出（保留）: adr-index.json 整備前に frontmatter を直接 grep する暫定手段は、ADR-0130 例外扱いの要否を確認してからこの節に追記する（ADR-0133 §5.2）。現時点では未追記。

4. Step 2 — 判定ルーブリック

判定対象 1 件 = 辺 {from, type, to}。判定者 = Claude Code エージェント。RQ-102 で確定した over-acceptance（誤った辺にも OK を出す失敗モード）対策 5 点をそのまま手順にする。

1. 内部知識の遮断: 両端 2 本の ADR 本文だけを読んで判定する。他の文書・モデルの事前知識による補完は禁止。
2. 型ごとの二値判定: 「宣言された型は両端本文から支持されるか」を yes/no で答える。1〜5 点の段階評価は使わない。
3. 逐語エビデンス引用の強制: 判定の根拠として両端本文からの逐語引用を必須にする。引用は空白正規化後の完全一致で原文と機械照合し、照合できない判定は無効として再実行する。
4. 次点型比較: 宣言型と最有力の対抗型（runner-up）の二択で再確認する。「宣言型より対抗型の方が本文に合う」なら mismatch。
5. self-consistency 多数決: 判定が割れたときだけ、独立 3 票の多数決を取る。

出力形式（1 辺につき 1 レコード）:

{
  "from": "ADR-0131",
  "type": "refines",
  "to": "ADR-0019",
  "verdict": "match",
  "confidence": "high",
  "evidence_from": "整合 lint は本体系に追加",
  "evidence_to": "lint 体系の追加は…",
  "runner_up_type": "relates_to"
}

型定義表（判定基準）

型の定義の正典は ADR-0131 §2。この表は監査用に「どんな逐語根拠があれば該当か」と「紛らわしい次点型との区別」を加えたもの。

5. 低確信・判定割れの閾値

• 低確信 = 出力レコードの confidence が low、判定割れ = 多数決 3 票が 2 対 1。
• 低確信と判定割れの辺は自動確定しない。人間レビューに送り、人間の判断を最終とする（RQ-102「能力ベースのタスク分割」— 高確信は自動・境界事例だけ人間）。
• 低確信・判定割れの辺は一覧にして記録する。judge drift 検証（§7）の抽出元になる。

6. Step 3 — 集計と判定（c=0）

• mismatch 0 件: 監査完了。記録して終了。
• mismatch 1 件以上: 全辺の棚卸しを前倒し実施する（c=0 基準）。
• 全数棚卸し 1 回が 4h を超えたら、ADR-0133 撤退条件 (b) の再設計レビューを起動する。概算は辺総数 N × 数分（N=100 で ~2h・N=300 で ~5〜6h・N=1000 で ~15〜20h）。
• 設計根拠: 22 件・c=0 は誤り率 10% を 90% 信頼で検出する。旧基準（10 件・不一致 2 件）の検出力は ~26% しかない。誤り率 5% まで検出するには n≈45 必要で、当面は 10% 基準で許容する（RQ-102）。

7. Step 4 — judge drift 検証

判定エージェント自体の劣化（drift）を毎監査で点検する。

• 毎監査、judge の判定 5 件を人間が検証し、不一致率を記録する。
• 5 件のうち最低 2 件は低確信または判定割れの辺（§5 の一覧）から取る。高確信の辺だけから取るのは禁止 — LLM は誤りケースほど高確信を示す傾向があり、系統的な誤判定を見逃すため（ADR-0133 盲点 #2・Kadavath et al. 2022）。
• 不一致率が 2 監査連続で 20% を超えたら判定ロジックを再設計する（ADR-0133 撤退条件 (c)）。

8. Step 5 — 記録

ADR 間の型付き辺 監査記録 に追記する。残す項目:

• 実施日・seed・総辺数 N・抽出 22 件の一覧
• 判定レコード全件（逐語引用込み = 透明な監査証跡）
• 不整合数・全数棚卸しの有無
• drift 検証 5 件の内訳と不一致率
• 担当・関連 PR

最初の 2 サイクルは追加で、実測誤り率と辺クラスタ別（型別・ADR 群別）の偏在を記録し、「22 件・c=0・層別なし無作為」の設計値の妥当性と層別抽出の要否を再評価する（ADR-0133 Confirmation 5）。

9. 不整合の修正経路

• 修正は両端 ADR の frontmatter の辺を直す commit のみで行う。
• ADR 本文は変えない（Accepted ADR の Immutable 原則・ADR-0031 のメタデータ後付け経路）。
• 状態の不整合（superseded と superseded_by の食い違い等）は lint の領分なので、検出したら adr-lint 側の課題として起票する。

10. 実行基盤の注記

• 現行の実行基盤 = Claude Code エージェントのセッション + 人間の PR レビュー。新規ランタイムの実装はない（ADR-0117 の維持運用と同一）。
• GAS の 6 分実行上限は非適用。将来 GAS 等の制約付きランタイムへ移す場合のみ、バッチ分割 + 継続トークン再開方式で全件の判定記録を連結する（ADR-0133 Confirmation 1）。

参照

• ADR-0133 — 本監査の決定（22 件・c=0・開始条件・撤退条件）
• ADR-0131 — 辺の型 7 種の定義の正典・初期移行と受け入れ検査
• RQ-102 synthesis — 検出力の計算・判定ロジック 5 点・drift 検知の設計根拠
• ADR 間の型付き辺 監査記録 — 実施記録の置き場