付録規範一覧 ── 本書が定めたこと

この一覧の読み方

本書の規範は全部で43項目、歯止めは8項目である。

規範は各章の本文に散らばって置かれている。書かれた場所は、その規範が効く場所であって、数えるための場所ではない。ここでは、それを章順に一列に並べる。

ここに並ぶ規範は、次の3つを満たすものだけである。

誰かに行為を課すか、何かに状態を求めている（「〜する／しない」「〜であること／〜が行われていること」）
守られているかを判定できる
破ると、本書の機構（検査・台帳・辿り）が成立しなくなる

歯止め（検査で何を問わないかの線）は、義務ではあるが規範とは別の分類である。末尾の別表に並べる。
定義（語や機構の意味を固定する文）、本書の立場（宛先が本書自身の宣言）、プラクティス（参考になるやり方。採否はプロジェクトが決める）、まだ決まっていないことは載せていない。混ぜると「結局いくつ守ればよいのか」が分からなくなる。
AI依存の列に●が付いている規範は、AIの2026年時点の能力を前提にした規律である（はじめに）。AIが進歩すれば緩められる。印のない規範は、誰が責任を持つかの問題なので、AIがどれだけ賢くなっても残る。
宛先は、その規範を守る人である。書き手（成果物やADRを書くSE）／プロジェクト（開始時に決める側・運用を設計する側）／検査の実行（検査を回すAIに課す規律）の3つに分けた。
正本は本文である。この一覧は索引であって、定義ではない。一行に畳んだ書き方では、本文が付けている但し書き・実例が落ちる。実際に運用するときは、必ず「本文の位置」の節を読むこと。
開始時に決める設定項目は、ここには含まない。それぞれの章にある。

章ごとの内訳

章	規範	歯止め	何についての規範か
なぜ今このメソッドか	0	0	（規範はない。シフトレフトの扱いは本書の立場として本文にある）
Trusted Spec の定義	1	0	業務ルールに関する決定に残す3点
育て方サイクル総論	2	0	AIと人の線引き、辿る網の張り方
たたく ── 叩き台の執筆	6	0	流れと成果物のつながり、検査が手掛かりにする要素、関係する決定の読み方、AIの出力の扱い、参照が辿れる状態
深める ── 議論・決定・未決	4	0	議論と記録の順序、未決の残し方と書き方、棚卸し
ADRの扱い ── 決定を書く	7	0	起票の規律、ADRの要素、制約節の書き方（影響範囲と満たすべき状態）
ADRの扱い ── 台帳を守る	3	1	状態と属性、1決定1ADRと置換、成果物との整合
広げる ── シナリオを歩かせる	5	0	シミュレーションの規律、参照の照合と【広げる】を混ぜない
広げる ── レンズと歯止め	5	7	どのレンズにも共通する規律、【広げる】が見る範囲を足すときの書き方
確かめる ── ADR適合検査	2	0	当てる制約、AIの出力は3つの指摘だけ
変更管理 ── 変更要求が来たとき、サイクルをどう回すか	4	0	変更の1周（【深める】から入る）、全置換、前提が変わったとき、反映
テスト工程 ── 観点カバレッジとDDPモニタリング	1	0	試験観点と試験シナリオを考えるのは人
実装への接続 ── 「AIが実装できる仕様」を実装側から逆算する	1	0	上流の仕様が実装側に応えるべき3点
導入とプロジェクトハーネス ── 明日から小さく始める	2	0	発展の成立条件と、維持する責任者
ADR運用の重さ ── 何が大変で、どこに注意するか	0	0	（規範はない。運用の重さの見立てと、既に定めた規範の再掲）
合計	43	8

規範の重心は、ADRの扱い（2章分）・【広げる】（2章分）・【確かめる】・変更管理にある。全43項目のうち26項目がこの6つの章に集まっている。育て方サイクル総論で見たとおり、本書が厚く書くのは後半の2ステップと記録である。

なぜ今このメソッドか

規範はない。シフトレフトの扱いは本書の立場として本文にある。

Trusted Spec の定義

規範	宛先	AI依存	本文の位置
業務ルールに関してプロジェクトが下した決定は、「何を決めたか／なぜそう決めたか（WHY）／誰の判断か」の3点とともにADRに残す。3つ目を落とさない。	書き手		2章「②根拠がある」

育て方サイクル総論

規範	宛先	AI依存	本文の位置
決めるのは、常に人である。AIが出してよいのは、【たたく】では叩き台、【深める】では論点の整理、【広げる】と【確かめる】では問いと指摘までとする。決定・合否・修正案は、AIに出させない。	検査の実行	●	3章「1周のストーリー」
決定は、成果物を経由して次工程へ伝える。成果物は直前工程の成果物を参照し、他工程のADRを直接参照しない。	書き手		3章「工程をまたぐとき」

たたく ── 叩き台の執筆

規範	宛先	本文の位置
業務の理解（業務の定義）から、業務の流れ、システムの振る舞い（ユースケース・要求事項）、約束事（業務ルール・状態の定義）までが、成果物の上で一本の流れとしてつながっていること。	書き手	4章「何を書くのか」
成果物どうしがつながっていること。後ろの成果物から、何を受けて書いたのかを前の成果物へ辿れる。	書き手	4章「何を書くのか」
成果物は、検査の手掛かりになる要素を備える——IDとIDでの参照、業務の流れのタスクごとの主体・開始条件・事後条件、状態・業務ルール・例外の定義と、そこへのつながり、成果物の種別。欠けている要素があると、それを手掛かりにする検査は、そこだけ空振りする。	書き手	4章「検査のために、何を揃えておくか」
成果物は、自分が含まれる影響範囲と「横断」のADRの制約を満たし、つながっている上流の成果物と食い違わない。	書き手	4章「関係する決定を、どう読み、どう残すか」
AIの出力を、そのまま成果物にしない。	書き手	4章「AIに、どこまで書かせるか」
成果物どうしの参照が途切れていないこと。参照先が実在し、逆向きにも繋がっていて、同じものが同じ名前で呼ばれている。IDの体系（接頭辞・桁数・採番の区切り）は、プロジェクトの中で統一されている。	書き手	4章「参照が辿れる状態にしておく」

深める ── 議論・決定・未決

規範	宛先	本文の位置
順序は「議論 → 決定 → 記録」。記録は決定が下された後に書く。ADRには決定事項のみを記載し、確定前の論点は未決型ISSUEへ置く。	書き手	5章「決まったことを、どう残すか」
決まらなかったことは、未決型ISSUEとして残す。	書き手	5章「決まらなかったことを、どう残すか」
決まっていない箇所は、すべて次の2つを満たす形で書く——①未決だと読み取れること ②該当する未決型ISSUEへ辿れること。	書き手	5章「未決を、成果物にどう書くか」
工程・単位の節目で、未決型ISSUEの棚卸しが行われていること。棚卸しとは、開いている未決型ISSUEを一覧し、次へ持ち込むか・今決めるか・不要になったかを人が仕分けることである。	プロジェクト	5章「決まらなかったことを、持ち越す」

ADRの扱い ── 決定を書く

規範	宛先	本文の位置
ADRは、次の5つを持つ——何を決めたか／なぜそう決めたか／誰が確定したか／その結果（良い結果とトレードオフ）／この決定から生じる制約。	書き手	6章「ADRに何を書くか」
制約節は、1行に「影響範囲：満たすべき状態」を1組ずつ書く。	書き手	6章「制約節に何を書くか」
影響範囲は、決定を受け止める成果物（その決定を反映させる要件定義や外部設計の文書）の範囲を、プロジェクトの文書に実在する名前で書く。特定の範囲に絞れないときは「横断」と書き、空欄にしない。	書き手	6章「影響範囲をどう書くか」
影響範囲に書けるのは、そのADRを決めた工程の成果物だけである。工程をまたがない。	書き手	6章「影響範囲をどう書くか」
満たすべき状態は、その影響範囲の成果物を読めば、満たしているかどうかを人もAIも答えられる形で書く。	書き手	6章「満たすべき状態をどう書くか」
標準・ルールで既にカバーされている決定は、ADRに書かない。	書き手	6章「業務ルールのほかにも、残したい決定があるとき」
プロジェクト運営の決定（体制・スケジュール・会議体）を、ADRに混ぜない。次元が別であり、記録するとしても別台帳にする。	書き手	6章「業務ルールのほかにも、残したい決定があるとき」

ADRの扱い ── 台帳を守る

規範	宛先	本文の位置
台帳を保つために、ADRは次の状態と属性を持つ——状態・発生工程・発生箇所・確定者・置換リンク・前提とする決定。	書き手	7章「状態と属性を残す」
記録の単位は1決定1ADRとする。承認済みになったADRは書き換えない。変えるときは新ADRを起票して置き換え、元ADRのステータスを「廃止（新ADRにより置換）」にする。削除・追記もしない。番号は再利用しない。	書き手	7章「ADRの一生」
制約節に書いた影響範囲のうち、プロジェクトの文書に実在しないものは、すべて指摘する（「横断」は正しい値とする）。	検査の実行	7章「成果物との整合を保つ」

広げる ── シナリオを歩かせる

規範	宛先	AI依存	本文の位置
AIが創作してよいのはシナリオ（＝問い）だけである。答え・正解・修正案は書かない。	検査の実行	●	8章「AIにシナリオを創作させる」
創作したシナリオには「AIによる仮説」と明記し、成果物からの引用と区別する。	検査の実行	●	8章「AIにシナリオを創作させる」
ウォークスルーは実在の成果物を実際に読んで行い、参照した箇所を明示する。	検査の実行	●	8章「AIにシナリオを創作させる」
シナリオの前提がAIの一般常識によるもので、実際の業務と違っているかもしれないことを、常に明記する。	検査の実行	●	8章「AIにシナリオを創作させる」
参照の照合と、【広げる】（意味のペア照合・シミュレーション）を、一度にまとめて回さない。	検査の実行		8章「辿れる状態で回す」

広げる ── レンズと歯止め

規範	宛先	AI依存	本文の位置
AIは答え（理由／責務／基準／例外の中身）を生成しない。「考えた跡があるか」を問い、跡が見当たらない箇所を人に手渡すだけ。	検査の実行	●	9章「どのレンズでも、AIに守らせること」
「ない」と断定しない。言ってよいのは「確認した範囲では見当たらない」までとし、どの成果物を、どんな言葉で探したか（言い換え・略語・業務用語とシステム用語の対応を含む）を添える。	検査の実行	●	9章「どのレンズでも、AIに守らせること」
1根本論点1指摘。同一根本原因と判定してよいのは、次の3条件をすべて満たすときに限る——(1) 対象箇所または業務上のつなぎ目が同じ (2) 不足・矛盾・曖昧さの根本原因が同じ (3) 一方を解消すると他方も同時に解消される。	検査の実行		9章「どのレンズでも、AIに守らせること」
指摘の行き先（未決型ISSUEにして議論する／成果物をそのまま直す／採らない）は人が振り分ける。AIは指定しない。	検査の実行	●	9章「どのレンズでも、AIに守らせること」
【広げる】が見る範囲にプロジェクト固有・ドメイン固有のものを足すときも、「問い＋歯止め」を1組にする。	プロジェクト		9章「レンズは、育てて使う」

確かめる ── ADR適合検査

規範	宛先	AI依存	本文の位置
当てるのは、その成果物が含まれる影響範囲と「横断」を示す制約項目だけである。	検査の実行		10章「何を確かめるか」
AIの出力は、食い違っている／判断できない／どこにも書かれていない、の3つの指摘だけである。	検査の実行	●	10章「何を確かめるか」

変更管理 ── 変更要求が来たとき、サイクルをどう回すか

規範	宛先	本文の位置
変更要求は未決型ISSUEとして受け、影響分析 → 合意・決定（ADR）→ 反映（反映型ISSUE）の順に回す。決定の前に、成果物本体を書き換えない。影響を見るための試し書き（分析用の試作）は、成果物本体に混ぜない。	書き手	11章「変更要求が来たら」
置換は全置換だけとする。小さな追加決定は、元のADRに追記せず、新しいADRとして並立して起票する。	書き手	11章「決めて、ADRに残す」
複数の決定が共有している前提は、前提そのものをADRとして起票する。前提のADRが置換されたら、それを前提としていたADRを1件ずつ人が見て、置換するか維持するかを決める。一括で自動的に置換しない。	書き手	11章「前提が変わったとき」
反映の作業は反映型ISSUEとして起票し、【確かめる】で指摘が出なくなったら、人が閉じる。	書き手	11章「成果物に入れる」

テスト工程 ── 観点カバレッジとDDPモニタリング

規範	宛先	AI依存	本文の位置
試験観点と試験シナリオを考えるのは人である。AIに任せるのは、マトリクスの整備・突き合わせ・印のない交点の指摘といった作業の支援に限る。	検査の実行	●	12章「テストの網羅を、どう示すか」

実装への接続 ── 「AIが実装できる仕様」を実装側から逆算する

規範	宛先	AI依存	本文の位置
上流の仕様は、実装側に次の3点で応える——①実装から要求まで、IDで遡れること ②やってよい範囲・いけない範囲が、推測ではなく参照で解決できる形で書かれていること ③未決が未決と分かること（実装AIが「埋めてよい空白」と区別できること）。	書き手		13章「上流の仕様に求められること」

導入とプロジェクトハーネス ── 明日から小さく始める

規範	宛先	AI依存	本文の位置
発展は、一般化したルールや観点が、守られていることを確かめる仕組み（検査やテストなど）に入ったときに成立する。一般化して移す先が決まらない決定は、発展させない（個別のADRのまま残す）。	プロジェクト		14章「発展させるときに守ること」
発展したルール・観点が、その仕組みで守られ続けているよう維持する責任者を定義する。発展したルールを改めることは決定であり、元のADRを置き換える新しいADRを起票する。	プロジェクト		14章「発展させるときに守ること」

ADR運用の重さ ── 何が大変で、どこに注意するか

規範はない。運用の重さの見立てと、既に定めた規範の再掲。

同章の「発展させたら、守られていることを確かめる仕組みに入れる」は、14章の規範の再掲である。ほかの工夫は、重さがどこに出るかの見立てから導いたもので、規範ではない。

歯止め一覧

歯止めは、検査で何を問わないかの線である。問いだけを置けば、検査は際限なく広がる。どこで止めるかを決めておくことが、検査を回せる量に保つ。全8項目。

章	歯止め	本文の位置
ADRの扱い ── 台帳を守る	後の工程で出た決定の制約節が、前の工程の成果物を名指すことは、違反として弾かない。品質シグナルとして観測にとどめる。	7章「前の工程の成果物を名指す決定」
広げる ── レンズと歯止め	すべての要件には問わない。業務ルールに触れるものに限る。成果物やその要素がIDでつながっているかは問わない。問うのは、つながっているものどうしが、中身として噛み合っているかである。	9章「業務との整合」
広げる ── レンズと歯止め	誰が担うかの特定と、処理の中身は問わない。問うのは、事後条件が次の開始条件と噛み合うかである。知る手段や権限の中身は提案しない。受け渡しがうまくいかないと業務が止まるもの、後から取り返せないものから、先に問う（例：出荷の指示、支払いの確定）。同じ担当者が続けて行い、その場でやり直せるもの（例：入力して、そのまま確認する）は、基本問わない。	9章「境界・責任範囲」
広げる ── レンズと歯止め	判断や確認をするタスクに限る。その中でも、判断を誤ったと後で分かったときに取り返せないものから問う（例：後のタスクがその判断を前提に進む承認や確定、お金や在庫を動かす判定）。取り返せるもの（例：下書きの保存、一覧の並べ替え）は、基本問わない。取り返せない判断に限り、誰がいつ判断したかが、後から分かるかまで問う（例：与信の上限を超えた受注を、誰がいつ特別に承認したか）。どう残すか（形式・保存期間・手段）は問わない。状態の名前が業務の言葉か、IDが振られているかは問わない（書き手が書いた直後に整える）。	9章「検証可能性」
広げる ── レンズと歯止め	あらゆる失敗は問わない。つなぎ目に集中する。定型の分岐（在庫あり／なし）と、単純なシステムエラー・入力エラーは問わない。業務の流れへの関与が深い外部連携の失敗から厚く問い、流れから独立したものは基本問わない。例外の中身は書かない。検討の跡があるかを問う。例外の一覧とのリンクの有無は問わない（書き手が参照として保つ）。	9章「正常系偏重」
広げる ── レンズと歯止め	1つの伝票の中（見出しと明細など）の更新は問わない。問うのは、別々の業務の情報（例：入金と売掛金、受注と在庫）をまとめて更新する場合である。排他制御の実装手段（楽観排他・悲観排他）は問わない。後工程の領域である。	9章「トランザクション境界」
広げる ── レンズと歯止め	自機能の外で変わりうるデータに限る。確定・取り消せない操作の前提になるものから厚く問い、表示にだけ使うものは後にする。整合性を保つ実装手段と、要件そのものの妥当性は問わない。	9章「機能成立性」
広げる ── レンズと歯止め	跡が残る操作に限る（確定、外部への送信、他者に見える状態変化、金銭・在庫の増減）。自機能の中で閉じ、誰にも影響を残さない操作は問わない。業務判断としての例外、入力チェック、障害時の処理方式は問わない。リカバリ手順の中身は提案しない。	9章「機能例外」