ADR-0037: 受信箱ラベルはレーンを指し、ロールとの写像は案件が定める
採用(2026-08-13)
コンテキスト
Section titled “コンテキスト”案件 P-001 で、G-3(技術設計判断)へ引き渡すラベルが無いと判明しました(#225)。
G-3 の判定者は技術判断者です(第4章)。標準が定める8ゲートの1つでありながら、その判定者へ仕事を渡す経路がLabel Mailbox の語彙にありません。
案件では技術判断者と価値責任者を同一人物が兼務しているため state:needs-po で実務上は届いていました。兼務していない体制では、G-3 の引き渡しをラベルで表現できません。
ロールとレーンの数が合っていない
Section titled “ロールとレーンの数が合っていない”第3章 3.5.1 が示す物理分割は5レーン(PO / Dev / QM / Audit / Platform)です。一方、第3章 3.2 が定めるロールはこれより多く、対応は次のようになっていました。
| ロール | 対応するレーン |
|---|---|
| 価値責任者 | PO |
| 開発者(検証者) | Dev |
| 独立レビュア | QM |
| QA(出荷判定者) | QM |
| 監査担当 | Audit |
| AI維持管理者 | Platform |
| 技術判断者 | 無い |
独立レビュアと出荷判定者は、既に QM レーンへ圧縮されています。圧縮それ自体は設計であり、誤りではありません。誤っていたのは、圧縮の規則を標準が書いていなかったことです。案件は写像を自分で決めるほかなく、技術判断者については決めようがありませんでした。
語彙を増やさない原則との関係
Section titled “語彙を増やさない原則との関係”第5章 4.2 原則5 は「語彙を必要最小限に抑える」と定めますが、同じ原則が例外を自ら規定しています。
ただし、伝える経路そのものが存在しない「伝達の欠落」がある場合は、速やかに公式語彙を追加する。
#217 でラベルの追加を却下したのは、経路が既に存在していたためです。今回は経路がありません。原則5 の後段に該当します。
state:needs-owner の定義が本文内で食い違っていた
Section titled “state:needs-owner の定義が本文内で食い違っていた”4.3 は state:needs-owner を「不可逆4操作に該当する判断・承認を要する状態」と定義しています。しかし 4.5.2 は、第7章 7.6 の段階2・段階3 のエスカレーションにも同じラベルを割り当てています。定義が実際の用法より狭くなっていました。
1. ラベルはレーンを指す。ロールではない
Section titled “1. ラベルはレーンを指す。ロールではない”受信箱ラベルが指すのは実行主体のレーン(作業領域・セッション・認証情報の組)であり、ロールそのものではありません。1つのレーンが複数のロールを担うことがあります。
ロールとレーンの写像は、案件が D-0 体制図で定め、構成(process.config.json の roles[])へ出力します。標準は既定の写像と、写像が満たすべき条件を定めます。
2. 技術判断者を指すラベル state:needs-tech を追加する
Section titled “2. 技術判断者を指すラベル state:needs-tech を追加する”標準の語彙を9種とします。追加は一種に限ります。
ラベルを増やすことと、物理レーンを6つにすることは別の判断です。技術判断者が独立したレーンを持つか Dev レーンを共有するかは、案件が第3章 3.5 の兼務表に従って決めます。ラベルは、レーンが分かれている体制で経路が表現できることを保証するためのものです。
3. 技術判断者を価値責任者のレーンへ既定で割り当てない
Section titled “3. 技術判断者を価値責任者のレーンへ既定で割り当てない”第3章 3.5 は「価値責任者 × 技術判断者」を△(避けたい)としています。ラベルの設計が、標準が避けたい兼務を強制してはなりません。
既定の写像では、技術判断者は Dev レーンとの共有を許容します(3.5 が「技術判断者 × 開発者 = ○」としているため)。ただし共有する場合は、3.5.3 の文脈の分離が成立しないため、セッションを分けます。
4. state:needs-owner の定義を用法へ合わせる
Section titled “4. state:needs-owner の定義を用法へ合わせる”「不可逆4操作」限定の定義を改め、事業決裁者の決裁・追認を要する状態全般とします。含まれる事項は、不可逆4操作・7.6 の段階2および段階3・第3章 3.9 の決裁マトリクスが事業決裁者を指す事項です。
案件がテーラリングで追認事項を追加した場合も、同じラベルを使います。ラベルは階層も事項の種類も表しません(4.5.2)。
検討した選択肢
Section titled “検討した選択肢”| 案 | 却下の理由 |
|---|---|
| 技術判断者を PO レーンへ割り当てる | 3.5 が避けたいとする兼務を、ラベルの設計で強制することになる |
| 技術判断者を Dev レーンへ割り当て、ラベルを追加しない | レーンを分けた体制で経路が表現できない。案件ごとの選択肢を標準が先に潰す |
| ロールの数だけラベルを用意する | 文脈オーナー・AI運用担当者・移行支援担当まで語彙が増える。いずれも引き渡しの経路を必要としていない |
| ラベルは維持し、写像だけを規定する | 写像の宛先が存在しない。技術判断者に割り当てられるラベルが無いという事実は変わらない |
state:needs-owner の定義を維持し、追認事項用のラベルを別に設ける |
4.5.2 が定めた「ラベルは階層を表さない」を崩す。段階の数だけ語彙が増える |
- 標準のラベル語彙は8種から9種になる
- 案件は D-0 でロールとレーンの写像を明示する。空欄にできない
- 準拠テンプレートは
state:needs-techをラベル定義へ加える - 既存案件は、技術判断者を含む写像を D-0 へ追記するまで、G-3 の引き渡しを
state:needs-poで代替してよい。代替である事実を D-0 へ記録する