提案ロジック設計(ルールエンジン)

知識ベースの規則を、実際の回答へどう適用するかの設計です。エンジンは依存なしの純粋関数として実装済みで(src/lib/tailoring-engine.mjs)、要件定義の3ペルソナと限界ケースのシナリオ検証が npm run check に組み込まれています。

処理の流れ

graph LR
  A["回答<br>(質問id→選択肢id)"] --> B["1. 非表示質問の<br>回答を除外"]
  B --> C["2. 条件成立の規則を<br>優先度昇順に整列"]
  C --> D["3. 調整を順に適用<br>(後勝ち+衝突記録)"]
  D --> E["4. プロファイルへ集約"]
  E --> O1["調整済みプロセス<br>(参照モデル+差分)"]
  D --> O2["トレース<br>(調整の根拠)"]
  D --> O3["警告<br>(規則の衝突)"]

1. 非表示質問の除外: 条件付き質問(例: 作成を指示した本人以外の確認者の有無は、1〜2名のときだけ表示)が非表示のとき、その回答は残っていても無視する。画面の状態と提案の根拠を常に一致させるため
2. 整列: 条件が成立した規則を priority の昇順に安定ソートする(同順位はデータの記載順)
3. 適用: 調整を順に適用する。後から適用されたもの(=優先度の高いもの)が勝つ「後勝ち」
4. 集約: 対象(ゲート・ロール・プラクティス)ごとの最終状態にまとめ、描画層が参照モデルへ重ねられる形にする

優先度の設計

priority	規則群	意図
50	軸E: 安全重要度	危害の深刻度に基づく要求。人員・期日の制約で外れない
40	限界ケース(補助)	前提が崩れる組み合わせの代替。実態に合わせる
30	軸C: 品質・規制	安全とコンプライアンスの要求。事業フェーズの省略指示に勝つ
20	軸D: 開発形態	契約構造の制約
10	軸A: 規模 / 軸B: 事業フェーズ / その他	基本の調整

たとえば「PoC だから出荷判定を省略(10)」と「高品質だから出荷判定を厳格化(30)」が同時に成立した場合、厳格化が勝ちます。速度の都合が安全の要求を黙って消さない、が優先度設計の原則です。

軸Eを最上位に置くのは、同じ原則を体制の制約へも適用するためです。人員が確保できないことは、危害の深刻度を下げません。

競合解決の規則

同一対象への調整がぶつかったときの解決は3つの規則で決まります。

状況	解決
構造操作同士(省略・簡略化・厳格化・統合)	優先度の高い方が生き残る。負けた方は「上書きされた」としてトレースに残る
set(パラメータ設定)同士(同一 param)	同上
低優先度の省略 × 高優先度の set	対象を復活させる。省略が取り消され、設定要求が生きる(例: PoC の独立レビュー省略は、規制業のレビュア2名要求で取り消される)

重要なのは、すべての衝突が警告としてユーザーに見えることです。エンジンは黙って解決しません。たとえば「2名・規制業・確認者なし」という成立しない組み合わせでは、独立レビューを適用しない状態(限界ケース)が最終状態になりつつ、規制要求との衝突が警告に残ります。

この状態は省略ではなく未達です(ADR-0028)。エンジンの操作語彙は omit の1つですが、確認者を置けない体制の独立レビューは、未達として表示し続けます。規制業と安全重要度 CL1 以上では、1〜2名の構成そのものを認めません。ユーザーが選べるのは、体制の確保です。安全重要度が理由の場合は、設計を変えて危害の帰結を下げる選択と、当該の機能を実施しない選択もあります(第8章 軸E)。「逸脱として記録して進める」という選択肢はありません。

トレース(調整の根拠)

要件定義の出力2「調整の根拠」は、エンジンのトレースをそのまま表示したものです。調整1件ごとに次を記録します。

• どの規則が(ruleId)、何を(target)、どうしたか(action)
• 画面向けの説明(note)、理由(reason)、根拠ページ(source)
• 適用結果(applied / overridden。上書きされた場合は上書きした規則の id つき)

規則スキーマで note・reason・source を必須にしているため(ADR-0008)、トレースに説明のない行は構造上存在しません。

決定性

• 同じ回答からは常に同じ提案が出る(乱数・時刻・外部状態を使わない)
• 同順位の規則はデータファイル名+記載順で順序が決まる(曖昧さを残さない)
• エンジンは依存ゼロの純粋関数で、ブラウザ(Astro アイランド)でも Node でも同じ結果になる

検証

npm run test:engine(check に統合済み)が次を検証します。

• 参照整合性: 全規則の条件が questions.yaml に、対象 id が integrated.yaml / practices.yaml に実在すること
• 3ペルソナ: 要件定義の利用シナリオ(2名PoC / 8名グロース高品質 / 15名・規制業・受注側)の期待どおりの提案
• 衝突2種: PoC×高品質の後勝ち、規制業×確認者なしの警告可視化
• 境界: 非表示質問の残骸回答の無視、AI利用不可時のループ無効化
• 安全重要度: CL3×確認者なしで安全側の優先と警告の両立、CL2 による CL1 要求の包含、CL0 での無加算
• 禁止事項の件数: constraints.yaml が第8章の禁止事項と同数(9件)であること

後続の実装との接続

• UI プロトタイプ: evaluate() の profile を参照モデルに重ねて描画し、trace を根拠一覧として表示する
• 修正・採択ワークフロー: ユーザーの上書きは profile への追加差分として扱い、constraints.yaml との照合と警告表示を行う