| AI補完 | WHYのない仕様の空白を、AIが推測で埋めること（悪気なく、それらしく、速く）。禁止ではなく舵取りの対象 | 1章 |
| シフトレフト | 品質活動をV字の左へ寄せること。決め切れないことを前提に、未決を安全に持ち越す装置を置く | 1章 |
| Trusted Spec | AIに安心して実装を任せられる「信頼できる仕様」。本メソッドの唯一の目的。文書群が3条件を満たしている状態の呼び名 | 2章 |
| 3条件 | Trusted Specの条件：決まっている／根拠がある／辿れる | 2章 |
| Level 1（ContextAwareness） | 本メソッドが狙う成熟度。AIが正しい文脈を持って生成できること。Level 2・Level 3 は射程外——約束できないことを約束しない | 2章 |
| SSoT | Single Source of Truth（信頼できる唯一の情報源）。大規模SIでは要件定義書と外部設計書の両方が含まれる | 2章 |
| たたく・深める・広げる・確かめる | 成果物を育てる4ステップのサイクル | 3章 |
| 立ち止まる機会 | 順調でも必ず立ち止まって俯瞰するタイミングを意図的に作る仕組み。【広げる】がこれを担い、節目に回す | 3章 |
| 成果物を経由して伝える | 成果物は直前工程の成果物を参照し、他工程のADRを直接参照しない（決定は成果物を経由して次工程へ伝播する）。後の工程で出た決定の制約節が前の工程の成果物を名指した場合は弾かず、品質シグナルとして観測する | 3章・7章 |
| 規範／プラクティス／歯止め／定義／コラム／未決 | 規範＝行為を課すか状態を求め、守られているかを判定でき、破ると本書の機構が成り立たなくなるもの／プラクティス＝参考になるやり方（採否はプロジェクトが決める）／歯止め＝検査で何を問わないかの線／定義＝語や機構の意味を固定する文／コラム＝本文の筋から外れた補足。読み飛ばしてよい／未決＝まだ決まっていないこと。枠の種類で分ける。規範一覧に載るのは規範（と別表の歯止め）だけ | はじめに |
| 検査の手掛かりになる要素 | 検査が手掛かりにする成果物側の要素（IDとIDでの参照／業務の流れのタスクごとの開始条件・事後条件／タスクごとの主体と主体の一覧／事後条件（判定基準）と状態の定義／業務ルールと、そこへのつながり／例外の一覧／成果物の種別）。成果物の体系は定めないが、この足場だけは定める——揃っていない要素に対応する検査は空振りする | 4章 |
| 主体／情報 | タスクを担う人・役割・組織・システム（「アクター」）／業務が扱うデータのまとまり（「エンティティ」）。本書はこの表記で通し、プロジェクトの標準が別の名前を使うなら読み替えてよい | 4章 |
| タスク | 業務の流れを構成する一つひとつの作業単位。開始条件と事後条件を持つ | 4章 |
| 開始条件・事後条件 | そのタスクを始めてよい状態と、終わったときに成立している状態。テスト工程では事前条件・事後条件と呼ぶ（同じものを指す） | 4章・9章・12章 |
| 確かめるが見つける3つ | 成果物の記載が決定と食い違っている（記載を引いて指摘する）／判断できない（決めつけずに人に返す）／書かれているべきことがどこにも書かれていない（その範囲の成果物をまとめて見る。成果物がまだ1本もない場合も同じく指摘する）。AIの出力はこの3つの指摘だけ | 10章 |
| 制約節テスト | 業務ルールに関する決定以外について、ADRを書く閾値として本書が推奨する線。「制約を1つでも書けるならADRにする」。目安。境界の事例は人が判断する。どこまでADRにするかの線は、開始時に決めておく | 6章 |
| 未決 | まだ決まっていないこと。未決型ISSUEとして記録し、成果物側にも明示する（条件①の生命線）。明示は敗北ではない。決めてあるが、まだ十分に確かめられていないものは、「閉じていないこと」と呼ぶ（本書の現在地） | 5章 |
| 閉じていないこと／目盛りが無いこと | 本書自身の現在地を分ける2つの語。閉じていないこと＝決めてあるが、まだ十分に確かめられていないこと。目盛りが無いこと＝規模や体制で変わるので、閾値や頻度、件数の目安がまだ決められないこと | 本書の現在地 |
| 歯止め | レンズとセットで書く「何を問わないか」。歯止めがないと、指摘がきりなく増える | 9章 |
| 参照の照合 | 成果物どうしの参照が途切れていないか（参照先の実在・逆向きの繋がり・同じものが同じ名前）を確かめること。書き手が保つ状態で、節目にAIなどで全体を照合する。ADRと成果物のあいだのつながりは、成果物との整合として節目に確かめる。シミュレーションは参照が揃う前でも回せる | 4章・7章 |
| 広げるの4つのレンズ | 業務との整合／境界・責任範囲／検証可能性／正常系偏重。独立の照合リストではなく、シナリオを歩かせるときの「見る目」。外部設計では機能成立性／トランザクション境界／機能例外に置き換わる | 9章 |
| レンズ | 【広げる】が歩かせながら見る目。4つのレンズ（要件定義）と3つのレンズ（外部設計）がある。当てて終わりにするチェックリストではない | 9章 |
| つなぎ目 | あるタスクの事後条件が、次のタスクの開始条件を必ずしも満たさない接点。境界・責任範囲（開始条件が手前で満たされるか）と正常系偏重（満たされない場合が検討されているか）が集中して見る場所であり、正常系偏重の量を絞る線でもある | 9章 |
| 意味のペア照合 | 【広げる】で、参照で照らす相手が決まっているものどうし（あるタスクの事後条件と次のタスクの開始条件、業務ルールとそれを実現するユースケースなど）の中身が噛み合っているかを見ること。照らす相手が決まらないものは、シナリオを歩かせて見る | 8章 |
| シミュレーション | 【広げる】がすること。AIが創作した業務シナリオを成果物群に歩かせ、見つかった空白を気づきとして人に渡す。創作してよいのはシナリオ（＝問い）だけ | 8章 |
| シナリオの種 | シミュレーションのシナリオを作るときの着眼。時間経過が主軸（成果物が描けるのは1本の線の中の時間だけ、という前提を突く）。プラクティスであり網羅リストではない | 8章 |
| 検算 | 【確かめる】の性格づけ。決めたことが成果物で守られているか、決定に合っているかだけを見る照合 | 10章 |
| 業務ルール | 業務上の取り決め。「何のため」の根拠の側。業務ルールに関してプロジェクトが下した決定（どう実現するか・どう解釈するか・どこまで適用するか・例外・誰が変えるか）は、ADRに必ず残す。既にある業務ルールそのものは対象外 | 2章・5章 |
| ADR | 「AIが推測で埋めそうな空白を塞ぐ決定」の記録（本書ではアーキテクチャに限らず、業務ルール・権限・状態の定義も対象）。変更不可で、置換されることでしか終わらない。本書は "Any Decision Record" に近いが、無制限ではない——業務ルールに関してプロジェクトが下した決定を必ず残し、それ以外の決定は制約節テストで「制約が書けるか」により絞る（主流は「重要か」で絞る） | 6章・7章 |
| 制約節 | ADRの必須の要素「この決定から生じる制約」。1行に「影響範囲：満たすべき状態」を1組ずつ書き、検査の相手を絞る正本。成果物がまだない範囲でも、【確かめる】が「どこにも書かれていない」と指摘できる | 6章 |
| 影響範囲 | 制約節の各行が当たる相手。決定を受け止める成果物を、できるだけ名指しで書く。名指しできないときは、業務プロセスやサブシステムのような範囲で書く。プロジェクト全体に及ぶときは「横断」と書く。書けるのは、そのADRを決めた工程の成果物だけ（工程をまたがない） | 6章 |
| 発生箇所 | ADRの属性。その決定がどこで生まれたか（どの業務・サブシステムで決めたか）。発生工程と対になる。当たる相手は制約節の影響範囲に書く | 7章・3章 |
| 横断 | 影響範囲に書く値。影響範囲を1つに決められない、プロジェクト全体に及ぶときに使う。空欄にしない（書き忘れと区別がつかないため）。どの書き手にも届く。記述を求める項目には使わない。「横断」は本書の例での呼び名で、表記は開始時に決めておく | 6章 |
| ステータス（状態） | ADRが今どこにいるかを表す語。本書が定めるのは4つだけ（次項）。却下・保留・取り下げは状態に持たず、未決型ISSUEの側が担う | 7章 |
| 仮決定／承認済み／発展済み／廃止 | ADRの4状態。仮決定＝決定済みの記録磨き（承認＝記録が決定を正しく写していることの確認）。承認済みになったら書き換えない | 7章 |
| 置換 | ADRを終わらせる唯一の道。新ADRを起票し、旧ADRを「廃止（新ADRにより置換）」にする（双方向リンク）。全置換のみで、元のADRに追記する形は持たない | 7章・11章 |
| 属性 | ADRが状態とは別に、台帳を保つために持つ情報。発生工程・発生箇所・確定者・置換リンク・前提とする決定。ヘッダ（フロントマター）に持つのはプラクティスで、同じ属性を2か所に書かない | 7章 |
| 発生工程／確定者 | ADRの属性。発生工程は制約節の書ける範囲を決め、品質シグナルの観測にも使う。確定者＝誰が確定したか | 7章 |
| 前提とする決定 | ADRの属性。その決定が前提として置いている別のADR（置換リンクと同じ扱いで、新しいリンクの種類ではない）。前提のADRが置換されたら、それを前提としていたADRを成果物との整合の照合が列挙する——置換するか維持するかを1件ずつ判断するのは人であり、一括で自動置換はしない | 7章・11章 |
| 発展 | ADRに残した決定を、共通の業務ルール・【広げる】の観点・テスト・ルールや執筆ガイドに一般化して育てる道筋。成立するのは、一般化したものが守られていることを確かめる仕組みに入ったとき。ADRは消さず、発展済みにする | 14章 |
| 影響範囲の索引 | 「影響範囲 → 影響するADR」の索引。ADRが増えて探すのが重くなったら、ヘッダと制約節から作る（AIなどに作らせてよい。プラクティス）。書き手と【確かめる】が引くのは、自分の成果物が含まれる影響範囲と「横断」のADRだけ（引く量に上限がある） | 7章 |
| 注記 | ADRを知らない人が善意で書き換えうる記述の脇に置く、ADRのID。付けるかは任意（プラクティス）。制約が書けない決定の理由を成果物に残すのは書き添えであり、注記とは呼ばない（6章） | 4章 |
| 未決の印 | 成果物の未決の箇所に付ける印。該当する未決型ISSUEのIDを添え、成果物とISSUEを双方向に辿れるようにする。読む側にとって唯一の手掛かりなので、漏らせない。実装するAIは、この印で「埋めてはいけない空白」を見分ける | 5章 |
| 書き添え | 制約がまだ書けないが理由を残したい決定を、成果物の本文に理由を書いて残すこと。索引に載らず、検査にも掛からない | 6章 |
| ISSUE | 可変の台帳。未決型（決めるべき論点。節目の棚卸しで仕分ける）と反映型（決定を反映する作業。【確かめる】で指摘が出なくなったら、人が閉じる）の2種。ADRの前後を繋ぐ | 5章 |
| 棚卸し | オープンな未決型ISSUEを節目で一覧し、次工程へ持ち込むか・今決めるか・不要かを人が仕分けること。行われていることが規範 | 5章 |
| 制約を記憶や推測で使わない | 成果物を書くときは、自分の成果物が含まれる影響範囲と「横断」のADR、つながっている上流の成果物を読み、それらと食い違わないように書く。上流の規律（実装側の「APIを記憶や推測で使わない」の対） | 4章・13章 |
| 観点カバレッジ | 試験観点×試験シナリオのマトリクスで、テストの網羅を示すこと。試験観点と試験シナリオを考えるのは人 | 12章 |
| DDP | Defect Detection Percentage（欠陥検出率）。ある工程で見つけるべきバグを、その工程でどれだけ見つけられたかの割合。単独で合否を語らず、定性判断を併せる | 12章 |
| 実装のコンテキスト | 実装するAIが参照するひとそろい（コーディングの規約、作業の手順、APIの型定義、生成に使う道具）。中身をSEが詳細まで知る必要はないが、仕様に書いていないことがここの既定で埋まる仕組みは知っておく。プロジェクトハーネス（上流の側のプロジェクト環境）とは別のもの | 13章 |
| プロジェクトハーネス | 発展で育ったものも、それ以外から生まれたものも含めた、プロジェクト環境の総体（ルール＋執筆ガイド＋検査の観点＋索引＋それらを実行する道具）。厚くなるほど、誰が書いても一定の品質になる。業界でハーネスと言うときは、モデルを取り巻く実行の仕組み（使ってよいツール、hook、読ませる文脈のファイルなど）を指す。それより広く、検査と執筆の環境の全体を指す。中身は強制するもの（参照の照合・【確かめる】・実行条件の固定）と助言するもの（執筆ガイド・レンズ・観点）の2種類 | 14章 |