ADR-0008: テーラリング規則は宣言的データとして管理し根拠を必須にする

ステータス

採用(2026-07-23)

コンテキスト

プロセス提案ツール(M7)は、入力(チームの条件)から調整済みプロセスを導出する。調整ロジックの持ち方には、コードに埋め込む方法とデータとして外部化する方法がある。フェーズ4のテーラリングガイドは調整を人が読める表として定義しており、これを機械可読にする必要がある。また、根拠のない推薦は組織を動かせないことが要件定義で確認されている。

決定

規則はコードでなくデータで持つ。質問(入力)・規則(調整)・プラクティス語彙・制約(禁止事項)を src/data/tailoring/ の YAML として管理し、Zod スキーマ(Content Collections)で検証する。ADR-0007 のプロセスデータと同じ管理系に載せる
規則は参照モデルからの逸脱だけを記述する(差分方式)。標準どおりの組み合わせに規則は書かない。参照モデル(integrated.yaml)が唯一のベースであり、規則はそれへの上書き
すべての調整に説明を必須にする。調整(adjustment)の note、規則の reason と source(根拠ページ)をスキーマ上の必須項目とし、根拠なしの規則を型レベルで書けなくする
禁止事項は規則と別の型(constraint)で持つ。入力に関係なく常に適用され、ユーザーの上書きが触れたら警告と逸脱記録の対象になる

検討した選択肢

提案ロジックをコンポーネント内に実装 — 最速だが、規則の追加・修正にプログラミングが必要になり、コミュニティが知識ベースを鍛える構想(テーラリングガイドの運用方針)と矛盾する
汎用ルールエンジン(json-rules-engine 等)の導入 — 条件式の表現力は高いが、規則の記述が実装寄りになり「人が読んで検証できる知識ベース」から遠ざかる。条件は「質問→回答」の等値照合だけで足りるため過剰
表(Markdown)のまま人が読む用途に限定 — ツール化を諦める選択。最終ゴールに反する

影響

規則の追加・修正は YAML 編集だけで完結し、npm run check でスキーマ検証される(ドキュメントと同じ品質ゲート)
提案結果の全項目が知識ベース上の規則へ遡れるため、ツールの出力「調整の根拠」が実装でなくデータから直接導出できる
条件語彙を等値照合に限定したため、数値範囲や複雑な論理条件が必要になった場合はスキーマの版上げ(schemaVersion)が必要
規則の適用順序・競合解決(priority の意味論)は提案ロジック設計で定義する