• Status: Accepted
  • Mode: Standard
  • Kruchten Type: Property/Executive
  • Scope: platform
  • Implementation Status: Not Started
  • 起案者: [email protected]
  • 起案日時 (JST): 2026-05-30 00:58
  • 承認日時 (JST): 2026-05-30 01:10 (Pipeline 通常 flow Standard 49/50 通過 + Consistency INFO、PR #1159 マージ。require-quant との 0091 採番衝突を 0092 にリネームし解消)
  • Deciders: [email protected] (単独)

1. コンテキスト

1.1 背景

Gate4 採点は単一審査系列(同一プロンプト・同一モデルを N 回 self-consistency サンプリング → 多数決)で合否を決めている。scoringStdDev は系列内のばらつきしか測れず、独立した審査員/プロンプトを変えたら同じ判定になるか(系列間の分散)は未検証で、「あるスコアが ADR の実力なのか審査系列固有のクセ(過学習)なのか」を区別できない。

1.2 現状 (As-Is)

2026-05-29 実測で、本セッションの 4 起案がいずれもちょうど 39/50(閾値 40 の直下)で差し戻し。scoringStdDev は 0〜0.5 で系列内は安定。「39 の壁」が ADR 品質起因か審査系列起因か不明で、盲点でも「採点者の個人差・基準変動が真因かも」「n=4 過剰適合」が繰り返し指摘された。

1.3 課題

境界帯(閾値直下)での誤判定は再投入 churn(~6.7 分 + Opus/回)を直接生む。系列間分散を測る指標がないため、39 帯を「ブレ」として救うべきか「実力」として受け入れるべきかの判断材料がない。

1.4 制約・要件

  • 全件 K-fold は LLM コスト爆発(+$20〜40/月相当)を招くため、境界帯限定でコスト抑制すること(review-tiering 整合)
  • fold は系列内サンプリングと独立した「真の fold」(別モデル or 別プロンプト variant)であること
  • 不一致時は自動合否確定せず人間レビューに回すこと(誤確定回避)
  • 個人開発のため LLM コスト増は月 +$10 以内に収めること
  • 電帳法 (2022 改正) 第 7 条準拠の意思決定証跡を確保すること

1.5 目標 (To-Be)

境界帯起案に独立 fold を K=2 (割れたら K=3) で適用し、合意で判定確定 / 不一致で人間レビューへ。系列間分散を crossFoldVariance として可視化。Non-Goals: 明確合格/不合格の起案への適用、ルーブリック自体の改訂(別 ADR 領分)。

2. 決定

Gate4 採点に独立審査系列の交差検証 (K-fold)境界スコア (閾値 ±3 点) の ADR に限定して導入する。

  1. 境界限定トリガー: 1 系列目スコアが閾値 ±3 点の境界帯に入った起案のみ追加 fold を実行。明確合格 (≥43) / 不合格 (≤36) は単一系列で確定。
  2. 独立 fold: 別モデル (例: 1 系列目 Opus / 2 系列目 Sonnet or Gemini) または別プロンプト variant。K=2 を基本、割れたら K=3。
  3. 合意ベース判定: 全 fold 一致 → 確定。割れた → judgmentUnstable フラグ + 人間レビュー経路。
  4. 可視化: crossFoldVariance(系列間スコア範囲・合否一致度・採点項目別スコア分散)を telemetry に記録。

実装着手前にバックテスト (39 帯 4 件を独立 fold で再採点) をハードゲートとし、結果は事前固定の数値基準で判定する(個人開発・代表取締役=代表取締役のため人的第三者は不在。数値基準の事前固定+24h 時間差での自己再評価で確証バイアスを抑える)。

3. 判断基準 (Decision Drivers)

3.1 評価軸

#重要度 (係数)案件特有の解釈
1#reliableMust (×2.0)境界帯の誤判定を減らし判定安定性を可視化できるか
2#efficientMust (×2.0)LLM コスト増を月 +$10 以内に抑え churn 削減と釣り合うか
3#operableHigh (×1.0)人間レビュー経路・feature flag・telemetry が日常運用に耐えるか
4#maintainableHigh (×1.0)fold モデル設定・境界帯幅を KV 外出しし陳腐化に追従できるか
5#suitableMedium (×0.5)個人開発の規模・起案頻度に対し過剰設計でないか

K.O. criterion: Must 軸 (#reliable / #efficient) の score < 3 は不採用。

3.2 評価軸 × 案スコア表

各案 0-5 で評価。満点 = 5 × Σ係数 = 5 × 6.5 = 32.5。

係数採択案 (境界限定K-fold)案 A (全件K-fold)案 B (現状維持)
#reliable×2.0451
#efficient×2.0415
#operable×1.0325
#maintainable×1.0334
#suitable×0.5424
加重和 (正規化)0.7380.5540.708
K.O. 通過 (Must ≥3)❌ (#efficient=1)❌ (#reliable=1)

4. 検討した代替案 (Alternatives Considered)

  • 案 A (全件 K-fold): 全採点に独立 fold を適用 — #efficient K.O. 不通過 (月 +$20〜40 で撤退条件超過)。明確合格/不合格にコストを払う必然性がない。
  • 案 B (現状維持・単一系列): 現行の self-consistency のみ — #reliable K.O. 不通過。39 帯のブレ/実力判別不能で churn が継続。
  • 案 C (同一モデル・別プロンプト variant のみ): モデル差を排しプロンプト差で独立性を確保 — fold 独立性が弱いが、盲点 #3 のモデル系統差バイアス回避策として採択案のバックテストでバイアス ±2 点超が確認された場合のフォールバック案として保持。

5. 影響 (Consequences)

5.1 正の影響 (Good)

  • 「39 はブレか実力か」を独立 fold で判定でき、境界の誤判定→無駄な再投入 (~6.7 分 + Opus/回) を抑制
  • 判定不安定を人間レビューへ回し自動誤確定を防ぐ
  • crossFoldVariance + 採点項目別スコア分散で採点の信頼性とルーブリック構造的欠陥の兆候を可視化 (盲点 #1 対応)
  • 電帳法対応として人間レビュー記録 (reviewerId / reviewedAt / decision / rationale / escalatedFrom) を構造化保存

5.2 負の影響 (Bad)

  • 境界帯で LLM コスト +$2〜4/月 (最悪ケース感度分析で +$9.6/月、撤退条件上限接近 — 盲点 #4)
  • scoring 経路の分岐増 (保守対象増)
  • 人間レビュー経路の運用負荷 (不一致時のみ)
  • 代表取締役 1 名がレビュー単一障害点になりキュー凍結リスク (盲点 #2)

5.3 中立・トレードオフ (Neutral / Trade-offs)

  • モデル系統差バイアス (盲点 #3): fold 間モデル (Opus/Sonnet/Gemini) は RLHF 訓練データ重複により「疑似独立性」リスクあり。バックテスト前に同一ルーブリックで既存 ADR 20 件以上を両モデルで採点しスコア差分布 (平均・標準偏差) を計測。±2 点以上のバイアスは z-score 正規化 or 案 C (同一モデル・別プロンプト) へ切替。
  • 構成概念妥当性 (盲点 #1): 交差検証はスコア統計的安定性は測るがルーブリック construct validity は測れない。両 fold が同欠陥基準で 39 一致した場合 AC「割れない→実力」が誤発動する。採点項目別スコア内訳を telemetry に追加し、全 fold で同項目が低いパターンを検出してルーブリック改訂入力とする。
  • 境界帯幅 ±3 の静的固定 (盲点 #5): スコア分布ドリフトに非追従。境界帯ヒット率を週次集計しベースライン ±15% 乖離で再校正アラート、四半期で直近 30 件分布から最適幅を提案する仕組みを長期影響で扱う。
  • feature flag OFF 時の telemetry 盲目化 (盲点 #6): flag OFF 時も「シャドウモード」(非同期・非ブロッキング独立採点) で telemetry のみ継続収集し、再有効化判断データを確保。

6. 撤退条件 (Rollback Plan)

6.1 前提確定ゲート (Acceptance Criteria・マージ前提)

実装着手前のバックテストをハード条件とする:

  • 本セッションの 39 帯 ADR (section-structure / consolidate-rq / progressive-gates / require-quant 初回) を独立 fold (別モデル) で再採点し、系列間で合否が割れるかを実測。
  • 判定基準を事前固定 (盲点 #7): 4 件中 2 件以上で系列間不一致 → 続行 / 1 件以下 → 撤回
  • 判定基準を事前に数値固定し(下記)、24h 時間差での自己再評価で判定する。個人開発(代表取締役=代表取締役)のため人的第三者・複数評価者は前提にしない(会社方針準拠)。実装着手の明示ゲートとしてカレンダー登録し、判定結果を Slack に書面記録(自己説明責任の証跡)。
  • 同時にモデル間バイアス計測 (既存 ADR 20 件以上で fold モデル比較) を実施。±2 点以上バイアス検出時は z-score 正規化または案 C へ切替。

6.2 運用後撤退条件 (定量)

  • 導入後 4 週で境界帯の系列間不一致率が 5% 未満 (=ほぼ常に一致) → 交差検証の価値なしと判定し境界限定 fold を無効化 (単一系列へ)。
  • LLM コスト増が月 +$10 超 → 境界帯幅を ±3→±2 に狭める or K を 2 固定。
  • 人間レビュー経路の滞留 (不一致案件の未処理が 5 件超 or 7 日超放置) → 境界帯を狭め発生頻度を下げる。SLA 超過時は系列 1 判定を暫定採用しつつ judgmentUnstable フラグを残すフォールバック経路を実装 (盲点 #2)。
  • 境界帯ヒット率がベースラインから ±15% 以上乖離 → 境界帯幅再校正アラート (盲点 #5)。

6.3 手順

機能は feature flag GATE4_CROSS_FOLD で OFF=既存単一系列へ即時復帰。flag OFF 後もシャドウモードで telemetry 継続記録 (盲点 #6)。判定担当: 代表取締役(代表取締役=本人、個人開発のため単独)。人間レビュー滞留時は §6.2 の SLA フォールバック(系列 1 暫定採用 + unstable フラグ保持)を自動経路とし、属人停止を回避。telemetry 自動集計 + 4 週/8 週 Slack 通知。

6.4 完了条件 (観測可能 KPI)

  • 境界帯起案の系列間合否一致率を計測・記録 (ベースライン確定)。
  • 判定不安定 → 人間レビューに回った率と、最終的に単一系列判定と異なった率 (交差検証が誤判定を救った件数)。
  • 39 帯 (閾値直下) の再投入回数が導入前比で低下。
  • LLM コスト増が想定 (+$2〜4/月、最悪 +$9.6/月) 内。
  • 採点項目別スコア分散で全 fold 共通の低スコア項目検出 (ルーブリック改訂入力)。
  • 検証: telemetry crossFoldVariance / judgmentUnstable / humanReviewRecord 集計 / 4 週・8 週レビューで再投入回数前後比較。

Confirmation (Fitness Function)

  • 検証手段: (1) telemetry 自動集計スクリプト (crossFoldVariance / judgmentUnstable / humanReviewRecord / 境界帯ヒット率 / LLM コスト) (2) 月次 Slack ダッシュボード通知 (3) adr-lint で feature flag GATE4_CROSS_FOLD 設定整合性チェック (4) Gate 2 で fold モデル設定の KV 外出し確認。
  • 実行頻度: telemetry=リアルタイム / Slack 集計=週次 (境界帯ヒット率乖離検知) / レビュー=4 週・8 週・四半期 / バックテスト=実装着手前 1 回。
  • 違反時対応: 撤退条件 §6.2 に該当 → 代表取締役判断で feature flag OFF (シャドウモード継続)。バックテスト判定基準未達 → 本 ADR 撤回し require-quant 等の起案品質側 ADR に転換。電帳法証跡欠落検知 → 即時 audit/persistence.ts hotfix。

6.6 長期影響 / Review After

  • Review After: 2026-07-24 (8 週) / 2026-08-29 (3 ヶ月) / 2026-11-30 (四半期境界帯幅再校正)
  • 負債化シナリオ:
    • fold モデルの陳腐化/価格変動: Opus/Sonnet/Gemini の世代交代・価格改定で fold 独立性やコスト前提が崩れる → fold モデル指定を KV 外出し (ADR-0084 同様) し、半年ごとに見直し。
    • 人間レビュー経路の形骸化: 不一致案件を代表取締役が捌けず放置 → 滞留を撤退条件の監視対象に。チーム拡大 (Jr) 時にレビュー担当を分散。人間レビュー判定根拠を構造化テンプレート (どのルーブリック次元が決め手か) で記録し四半期パターン分析→プロンプト改善ループ (盲点 #2)。
    • 境界帯の固定化: 採点分布変化で ±3 妥当性が変わる → crossFoldVariance 分布を四半期で再校正、直近 30 件分布から最適幅を自動提案 (盲点 #5)。
    • ルーブリック構造欠陥の検出: 採点項目別スコア分散で全 fold 共通の低スコア項目を四半期分析しルーブリック改訂入力に (盲点 #1)。

7. 参照 (References)

  • 関連 ADR:
    • ADR-0056 (LLM temperature/sampling 戦略): 系列内 self-consistency N と本 ADR の系列間 fold は別レイヤで両立。
    • ADR-0076 (Cross-Validation ゲート=盲点×Must 整合): 名前は近いが別物 (0076=論理整合 / 本 ADR=採点統計的安定性)、相補的。
    • ADR-0084 (Gate4 閾値 KV 外部化): 閾値を境界帯計算に流用、fold 設定も同様に KV 管理。
    • review-tiering ADR (差し戻し済): 「審査を重くしない」方針と本 ADR の fold 追加は境界帯限定により両立。
    • follow-up: 全 mode 適用可否は 4 週レビューで判断 (初期は Standard/Critical のみ)。
  • 関連 PR/Issue: -
  • 外部資料: 電子帳簿保存法 (2022 年改正) 第 7 条 / 中小企業会計指針 / Suhr 1999 CBA (WSM 準拠) / Kruchten ADR 3 分類。

影響範囲(変更対象・関係者)

対象変更内容
drp/src/nodes/scoring.ts1 系列目が境界帯なら追加 fold を独立モデル/プロンプトで実行、合意ベース判定 + 不一致時 unstable フラグ
prompts/production/gate4-scoring/prompt.meta.yaml (or KV)fold 数 K・境界帯幅 (±3)・fold 別モデル指定の設定
drp/src/audit/{types.ts,persistence.ts}crossFoldVariance (系列間スコア範囲・合否一致度・採点項目別スコア分散)・judgmentUnstablehumanReviewRecord (reviewerId / reviewedAt / decision / rationale / escalatedFrom、改ざん防止タイムスタンプ付与) を記録
drp/src/do/pipeline_session.ts + chat UI「判定不安定 → 人間レビュー」経路の状態・表示、SLA 超過時フォールバック (系列 1 暫定採用 + unstable フラグ保持)
関係者起案者=代表取締役 / レビュー=代表取締役 / 利用者=全起案者

コスト試算(感度分析込み)

作業工数 (人日)工数 (h)領分
scoring.ts K-fold + 合意判定 + unstable ルーティング1.06main
telemetry crossFoldVariance / judgmentUnstable / humanReviewRecord 記録0.53main
人間レビュー経路 (DO 状態 + chat UI + SLA フォールバック)0.53main
バックテスト (直近 ADR を独立 fold で再採点・モデル間バイアス計測 20 件)0.53main
テスト (境界判定・不一致ルーティング・シャドウモード)0.53main
合計約 3.0 人日~18 h

LLM コスト感度分析 (盲点 #4 対応):

シナリオ境界帯率K 平均単価仮定月コスト増
楽観40%1.5$0.15/採点+$2.7/月
中位60%1.7$0.2/採点+$6.1/月
悲観80%2.0$0.3/採点 (長文 ADR + Gemini 単価)+$14.4/月

撤退条件月 +$10 上限は中位シナリオ基準。悲観シナリオ突入時は境界帯幅 ±3→±2 縮小で +$10 内に収める。

11. 参照: Pipeline 審査履歴 (2026-05-30 実行時, 通常 flow)

Decision Pipeline で本草案を通常 flow (retroactive=false) で審査した結果。Gate4 49/50(本セッション最高点)+ Consistency INFO。なお numbering ノードが require-quant と同じ 0091 を並行採番したため、後発の本 ADR を 0092 にリネームして衝突解消(ADR-0086/0087 と同じ対応)。

📋 Pipeline 審査履歴 全 Gate 結果 (合格 Score 49 / 50) — クリックで展開

Gate 0-4 結果

  • Gate 0 Triage: needsAdr=true / triageMode=Standard
  • Gate 1 Socratic: 盲点 8 件検出 (情報提供型、§5.3・§6 撤退条件に反映)
  • Gate 2 Consistency: INFO (ADR-0056/0076/0084/review-tiering と相補的、矛盾なし)
  • Gate 3 Parallel Review: 3 vendor (Gemini/Claude/o3) の指摘を §5.3・§6 へ反映
  • Policy Alignment: 複数評価者前提(第三者判定・代表取締役独立)が 1 人運用に不適合との指摘 → 本 PR で「代表取締役=代表取締役・数値基準事前固定+時間差自己再評価」に修正
  • Gate 4 Scoring: 49 / 50 (scoringMean 48.6, stdDev 0.8)
#採点項目点数
1問題定義5
2代替案5
3判断基準5
4過去 ADR 整合性4
5影響範囲5
6運用上の罠5
7ロールバック5
8コスト試算5
9完了条件5
10長期影響5

合計: 49 / 50

Status 遷移

  • 本 PR で Status: Proposed → Accepted。同時に整備:
    • 0091 → 0092 リネーム(require-quant との採番衝突解消)。
    • ## Confirmation を H2 に昇格(adr-lint confirmation-section 解消)。
    • Policy Alignment 指摘の「複数評価者前提」を 1 人運用向け(代表取締役=代表取締役・数値基準事前固定・24h 時間差自己再評価・SLA フォールバック)に修正。
    • 残改善余地(§4 参照 ADR の Supersede/Conflict 明示)は follow-up。