意思決定システム — 決定が記録され検証される方法

組織のアーキテクチャは決定の集積だ。だが決定が議事録や記憶の中にだけ生きていると、三か月後には「なぜこうしたのか?」が繰り返される。この文書は、ワークスペースが決定を一級資産として扱う装置 — Decision Record、スペックレジストリ、ガバナンスバックログ、反映検証 — を扱う。

出典: ai-workspace-standards ADR-0061 Decision Record Standard · ADR-0055 Spec Registry Enforcement · ADR-0059 Governance Reflection Validators · docs/designs/2026-08-16-governance-backlog-design.md · scripts/validate-decisions.ts · scripts/ticket.ts

概要 — 決定も資産である

コードはレビューされテストを通るが、決定はそうでないことが多い。「このスキルは実験的関係のままにする」「このvariantは昇格を保留する」といった判断が会話と記憶の中にしかなければ、組織は同じ議論を繰り返す。ワークスペースの答えは、決定を ファイルとして書き、チェーンで根拠を束ね、機械で検証する ことだ。参照Cのグラフが決定記録をノードとして取り込むのもこのためだ — 関係と根拠が一枚の地図に載って初めて探索できる。

Decision Recordの構造

Decision Recordは docs/decisions/DEC-YYYYMMDD-NN.md ファイルで、Agent → Skill → Knowledge → Evidence → Rule → Decision のチェーンを閉じる文書だ。必須フロントマターは id、date、agent、decision、alternatives、status で、任意配列として evidence_refs、knowledge_refs、rules_applied、skills_used がある。

• 証拠台帳 — docs/evidence/ledger.md。(主張、出典、URL/参照、検証方法、状態)の行を持ち、行IDは EV-YYYYMMDD-NN 形式。決定記録の evidence_refs はこの台帳の行IDのみを指せる
• ゲート時点の記録 — PMエージェントは、ゲート時点の決定(スペシャリスト選定、設計承認など)について、ディスパッチが続行する 前に 記録を残さなければならない
• supersession-only 変更モデル — 決定記録は削除しない。覆された決定は、新しい記録が古い記録を継承(supersede)する。「決定の歴史」は上書きではなく接続される

validate-decisions.ts の7検査

scripts/validate-decisions.ts はすべての DEC-*.md に対して以下を検査する。

1. フロントマターの存在
2. 六つの必須フィールドの完備
3. id とファイル名の接尾の一致
4. status 語彙 (proposed | accepted | superseded)
5. evidence_refs が台帳行IDの部分集合か
6. knowledge_refs が実在ファイルに解決されるか
7. rules_applied 形式(<PREFIX>-R<N>)と skills_used の実在スキル解決

この検証は fail-closed だ — errorレベルの問題が一つでもあれば exit 1。「警告だけ出るソフト検査」とは違い、壊れた決定記録のまま同期は進まない。

なお2026年9月から、governed等級のvariantテンプレートには判断ゲート(decisions/gates.yaml)が導入されている。ゲートは「どの地点でどの判定を通過すべきか」というルール宣言であり、判断記録は実際に下された判定の記録だ — ゲートで出た判定はrecord_kind: DECとして判断記録に残る。詳細は第15章・Domain Operating Modelを参照。

スペックレジストリとE1–E5免除

決定の前段には設計(spec)がある。ADR-0055の スペックレジストリ(docs/specs/registry.json)は設計文書を id・タイトル・ファイル・状態(proposed | approved | implemented)・最終更新日で追跡する。

核心は スペック関連性ゲート だ。コード変更があるのに、その変更に関連するスペック活動(レジストリへの触及り、7日以内に更新された approved/implemented スペック)がないと、監査が失敗する。「コードは変えたのに設計記録は凍ったまま」という状態を構造的に捉える装置だ。

もちろん、すべての変更に設計文書を要求すれば過剰だ。だから免除コードは五つだけに限定される。

場当たり的な免除は禁止で、存在しない免除コードを使うこと自体がハード失敗だ。免除の濫用はガバナンス違反だ。

ガバナンスバックログ

すべての決定が今下されるべきではない。「いつか判断する必要があるもの」は ガバナンスバックログ チケットとして先送りされる。サービスチケット(第9章)が一回限りの作業依頼なら、ガバナンスバックログチケットは gitで追跡される未来の決定 だ。

• scripts/ticket.ts で管理され、tickets/governance/ にgit追跡ファイルとして保存
• kind: manual チケットに not_before 日付を付けると、その日が来るまで list --ready --kind manual に現れない — 熟成(soak)予約
• 状態機械は backlog → waiting → review → done
• セッション開始や週次点検で準備完了チケットが表面化すると、PMは純粋な判断は自ら review→done とし、実装が必要なものは正規のPMゲートウェイへディスパッチする

「今は決定しない」ということ自体を記録として残す装置だ。忘却ではなく予約だ。

ガバナンス反映検証

ADR-0059が生まれたきっかけは具体的な事故だった — あるADRがガバナンス文書のどこにも参照されないまま承認され、実際には誰も従わなくなった。scripts/verify-adr-governance.ts は二つのことを検出する。

• リンクのないADR — 基準日(2026-08-23)以降に承認されたのに、CONSTITUTION・docs/constitution/・docs/governance/ のどこにも言及がないADR。「承認済みだが未反映」状態だ
• マーカーハッシュのドリフト — 憲法原文から複製された文書セクション(マーカーで束ねられた intentional duplicate)のハッシュが原文と食い違う場合。原文が変わったのに写しが追いついていないシグナル

--strict ではこの二つは /sync を止める。マーカードリフトの治癒手順は決まっている — 複製セクションをレビュー・更新し、--update-marker-hashes でハッシュを再投入してから再同期。

決定の寿命

決定に関する時間ルールは二つある。混同しやすいので範囲を正確に整理しよう。

• 7日soak(ADR-0055) — スペックレジストリ強制がburn-in期間中は警告レベルのみで動くようにした導入猶予。過去7日以内に更新されたスペックは「活動中」と認められる
• 90日ルール(ADR-0060) — スキルグラフのオーバーライドにおける実験的関係専用。フロントマターへ昇格しないまま90日が経つと陳腐化の警告が出る(参照C)

実務 — 一つの決定の旅

1. 設計 — 変更が些細でなければ設計文書を書き、レジストリに登録する(proposed → approved)。
2. 実装+記録 — 実装とともに、ゲート時点の判断をDecision Recordとして残す。証拠は先に台帳に書き、EV- IDで参照する。
3. 検証 — /sync がaudit(スペック関連性)・validate-decisions.ts・ガバナンス反映検証を通す。一つでもFailなら進行不可。
4. 反映 — 承認されたADRはガバナンス文書に接続されなければならない。リンクしないまま放置するとADR-0059検証が捉える。
5. 先送り — 今判断する根拠が足りなければ、バックログチケットとして not_before 付きで予約する。責任を持つのは記憶ではなくチケットだ。