前付けはじめに

大規模SIで、AIに安心して実装を任せられる仕様——Trusted Spec（信頼できる仕様）——を育て、維持する。本書が定めるのは、そのためのメソッドです。

目新しい主張はひとつもありません。決定の理由を残す。要求から実装まで辿れるようにする。決めたことが守られているか確認する——いずれもSIの現場が長年「やったほうがいい」と言い続けてきたことです。やれなかった理由もはっきりしています。人手では割に合わなかった。変わったのは理想の中身ではなく、その作業コストのほうです。

誰に向けて書いたか

主に読んでほしいのは、受託側で要件定義・外部設計を担うSE・PLです。本書の記述は、叩き台を書き、発注者と議論して決め、記録を残し、検査を回す——その仕事の側から書かれています。

副読者が2つあります。ひとつは発注者・業務部門——決定を確定し、【確かめる】の出力を成果物とともに読む立場です。もうひとつは経営層——導入の判断材料として読む立場です。どちらも通読する必要はありません。どこを読めば足りるかは、次のどこから読むかに置きました。

扱う工程

本書が定めるのは、要件定義と外部設計——上流の育て方です。「AIに実装を任せられる仕様」を掲げますが、実装自体は出口であって、本書が定める工程ではありません。実装側の規律から上流に何が求められるかを逆算し（13章）、育てた仕様がテストでどう回収されるかを考え方として置きます（12章）。しかし、実装そのものの進め方は扱いません。

AIについての前提

本書はAIの2026年時点の能力を前提に書いています。とくに検査の規律——AIに合否を判定させない、網羅性を保証しない、判断できないものを決めつけさせない——は、今のAIが問い返さず埋め、判定が揺れることへの対処であって、原理ではありません。AIが進歩すれば緩められますし、そうなるべきです。

一方、決定の理由を残す、決まったことと決まっていないことを分ける、業務の言葉で承認できる形で書く——これらはAIの能力ではなく、誰が責任を持つかの問題なので、AIがどれだけ賢くなっても残ります。本書はこの2つを分けて読めるように書いてあります（AIの能力に依存する規範には、規範一覧で印を付けています）。

読み方の前提

本書は、定めたこととプロジェクトが決めることとまだ決まっていないことを、文面上で区別して書いています。

• 規範——本書が定めること。誰かに行為を課すか状態を求め、守られているかを判定でき、破ると本書の機構が成り立たなくなるものだけを規範と呼びます。枠で囲ってあり、文体も本文とは分けて、言い切りで書いてあります。
• プラクティス——参考になるやり方。採否はプロジェクトが決めます。
• 歯止め——何を問わないか。観点とセットでなければ、検査は爆発します。
• 定義——語や機構の意味を固定する文。守る・破るの対象ではなく、読み違えないための足場です。
• 未決——まだ決まっていないこと。解けていないことは、解けていないと書いてあります。
• コラム——本文の筋から外れた補足。読み飛ばしてかまいません。

どれでもない、本書自身についての宣言（射程、機構を増やさないこと など）は、枠を付けずに本文で述べています。

本書が示すのは、メソッドの定義です。手順と規範と、その理由までを書きました。回すための道具立てと、回した結果の記録は、まだ本書には入っていません。メソッド自身も育てるものだと14章で述べますが、本書はその途中にあります。閉じていないことと目盛りが無いことは、本書の現在地にまとめました。

約束できないことを約束しない、というのが本書の流儀です。

前付けどこから読むか

本書は、全15章と付録6本でできています。全部読む必要はありません。目的に合わせて、次のどれかから入ってください。

最初に読む ── 初めて読む人へ

ここまでで、本書が何を言っているかはつかめます。

成果物とADRを書く ── 要件定義・外部設計を担うSE

4章（叩き台を書く）→ 5章（議論して、決めたことと決まらなかったことを残す）→ 6章（ADRを書く）→ 7章（ADRの束を守る）。書いたものにどんな検査がかかるかは、8章・10章で見られます。

検査を回す ── 検査を運用する人

8章（シナリオを歩かせる）→ 9章（レンズと歯止め）→ 10章（【確かめる】）→ 14章（導入と発展）。

歯止め（何を問わないか）も、あわせて読んでください。歯止めがないと、指摘がきりなく増えます。

ADRの運用を設計する ── PL・アーキテクト

7章（ADRの束を守る）→ 14章（導入と発展）→ 15章（ADR運用の重さ）。補いに、6章（ADRの形式と制約節）と11章（変更が来たときの動き）。

重さの章も、あわせて読んでください。仕組みだけを入れて、どこに重さが出るかを知らずに始めると、続かなくなります。

経営・発注者に説明する

1章（何が問題か）→ 2章（目指す状態と、増える作業・減る作業）→ 12章（上流で育てた仕様が、テストでどう回収されるか）。付録 サイクルを1本通すを添えると伝わります。

読む前に射程を確かめたいなら本書が解くもの、解かないものを、まだ閉じていないことと目盛りが無いことは本書の現在地を見てください。

前付け本書が解くもの、解かないもの

本書の射程を、先に示します。本書が定めること、プロジェクトに委ねること、本書の仕組みでは解けないことの3つに分けました。

解くもの（本書が定めること）

解かないもの（プロジェクトに委ねること）

固定すると現場に合わないので、本書が空けてある場所です。

解けないこと（本書の仕組みが持つ限界）

本書の検査は、書かれたものどうし、書かれたものと決定を突き合わせます。だから、書かれなかったものは見つけられません。突き合わせる相手がないからです。これは、決めれば書けるものでも、回せば目盛りが出るものでもない、本書の仕組みそのものの限界です。知ったうえで使ってもらえるよう、ここに挙げておきます。

現れ方は4つで、それぞれに補う手立てがあります。

限界は消えませんが、補う手立てはあります。まだ十分に確かめられていないものは、次の本書の現在地にまとめています。

前付け本書の現在地

本書は初版です。規範は、この版の基準として扱ってください。効き目は、自分の現場で試して確かめるものとして読んでください。

まだ閉じていないことと、目盛りが無いことは、このページにまとめてあります。

閉じていないこと、目盛りが無いこと

閉じていないこと

本書の仕組みのうち、まだ十分に確かめられていないものです。従来の実務と同じところは、並べていません。

目盛りが無いこと

規模や体制で変わるので、閾値や頻度、件数の目安がまだ決められないものです。

第1章なぜ今このメソッドか

実装は速くなった。なのに不安が消えない

AIコーディングの普及で、実装のスピードは目に見えて上がりました。それなのに、大規模SIの現場では品質への不安が消えません。レビューは減らせません。むしろ「AIが書いたコード」を人が全量確認する分、負荷が上がったという声すらあります。なぜでしょうか。

問題は実装側ではなく、仕様側にあります。

SIはWHYを残してこなかった

SIの文書体系を振り返ると、要件定義書はWHAT（何を作るか）を、設計書はHOW（どう作るか）を書いてきました。しかしWHY（なぜそう決めたか）は、会議室の記憶と担当者の頭の中に置き去りにされてきました。人間のチームなら、それでもなんとかなりました。分からなければ隣の席に聞けたからです。

「あの人に聞けば分かる」——これが属人化であり、「仕様有識者」という言葉で整理されてきた問題の正体です。

WHYのない仕様をそのまま渡されたAIは、空白を自分の推測で埋めます——悪気なく、それらしく、速く。これを本メソッドではAI補完と呼びます。そして、それらしく埋められた推測は、気づかれないまま下流工程に流れていきます。

失敗はこう起きる

例1：WHYが書かれていなかった

仕様書に「送料無料の閾値は、変更可能とする」とだけ書かれていたとします。AIは「変更可能」を素直に解釈し、定数ファイルに値を切り出して実装します。技術的には正しい実装です。

しかし発注側が考えていたのは、別のことでした。キャンペーンによって送料を無料にするケースがある——期間を区切って閾値を下げる、対象商品を絞って無料にする。そうした売り方を、業務部門がその都度打ちたかったのです。つまり要るのは、業務部門が自分で切り替えられる仕組みでした。管理画面も、誰が切り替えてよいかの権限も、いつ・誰が・何を変えたかの履歴も要ります。定数ファイルの書き換えは、そのどれでもありません——キャンペーンのたびにリリースを伴い、開発側の手が必要になります。この食い違いが発覚したのは本番2週間前でした。

AIは間違えていません。仕様が「変更可能」のWHY（誰が・何のために変更するのか）を持っていなかったことが問題です。逆に言えば——「変更可能とする」と書いた時点で、その理由を書こうとしていれば、手が止まったはずです。誰が変えるのか。何のために変えるのか。そして、何をもって「変更可能になった」と言えるのか——定数を外に出せば済むのか、業務部門が自分で切り替えられて初めてそう言えるのか。書けません。その、書けなかった箇所が、本番2週間前に発覚した箇所です。

例2：責任の範囲が書かれていなかった

もう1本、別の形の失敗を見てみます。外部設計書に「受注登録画面は、受注データを登録し、在庫引当を行う」と書かれていました。AIは素直に実装します——在庫があれば引き当て、なければ受注を「予約受付」状態に変えるコードです。

レビューで指摘が入ります。「在庫がないときに予約受付へ回すかどうかは業務ルールの話です。画面が判断してよいことではありません」。書いた側の言い分も筋は通っています——「在庫引当を行う」と書いてあったから、在庫がないときの処理も書いた、というわけです。

ここでもAIは、書かれていないことを埋めただけです。この設計書には受注登録画面がどこまでの責任を持つか——可否の判断をしてよいのか、詳細なロジックは誰が持つのか、例外時の業務判断は誰の責務か——が書かれていませんでした。例1がWHYの欠落なら、こちらは責任の範囲の欠落です。この2つと、例1がもうひとつ開けていた「何をもって実現されたと言えるのか」の空白は、後で見る【広げる】の4つのレンズの「業務との整合」「境界・責任範囲」「検証可能性」に、そのまま対応しています（9章）。

なお、例2が外部設計で表に出たこと自体も、ひとつの信号です。在庫がないときにどうするかは業務ルールであり、本来は要件定義の側で、主体の責務として決まっているはずのものでした。後の工程で上流の決定が動くことは、それ自体が観測の材料になります（7章）。

どちらの例も、分かりやすくするために単純にしてあります。実際の食い違いはもっと小さく、いくつもの記述に散らばって現れます。そのほうが、かえって見逃されます。

問題は「やり直し」ではなく、「発覚の遅れ」である

どちらの例でも、書かれていない箇所は同じ道をたどります。

やり直すこと自体が悪いのではありません。叩き台の段階で「それは違う」と出れば、直すのは記述の書き換えで済みます。設計レビューで出ても、まだ間に合います。問題は、同じ食い違いが遅く出ることのほうです。遅れるほど、やり直す範囲は設計から実装・テストへ広がります。それでも納期は動きません。例1が痛いのは、管理画面を作り足したからではなく、それが本番2週間前に分かったからです。

では、なぜ本番間際まで気づかれないのか。理由はAIの側ではなく、人の側にあります。

もっともらしい仕様は、疑われずに通る

AI補完が下流まで流れてしまうのは、書き手やレビュアーが不注意だからではありません。AIの出力には、人の判断を鈍らせる性質があります。

• 自信のある口調は、正しさと読み違えられる（権威バイアス）。AIは根拠の薄い箇所も同じ調子で書きます。断定の強さと確からしさは比例しません。
• 見たいものだけが目に入る（確証バイアス）。「この業務はシンプルだ」という先入観があると、正常系だけを確認して例外・差戻し・取消を見落とします。【広げる】の4つのレンズに「正常系偏重」が要るのは、このためです。
• 自動で出てきたものは、検証を省きたくなる（自動化バイアス）。AIが「問題なし」と言った成果物を、人が読まずに次へ送ってしまいます。

一般的な仕様は、たいていもっともらしく見えます。そこにこの3つが重なると、「書かれていなかった箇所」は疑問として立ち上がらないまま次工程へ渡ります。作業はAIによって速くなりますが、人の認知の速度は上がりません。この差が、発覚を遅らせます。

「要件定義が甘かっただけだ」と読まないでほしい

同じあいまいさを人間の開発者に渡したら、たいていは手が止まります——「変更可能って、誰が変えるんですか」。あいまいさが、質問という形で表面化するわけです。AIも問い返すことはあります。しかし問い返さずに埋めてしまう場合がある——そして埋めた結果は整合的に見えます。定数ファイルへの切り出しはコードとして正しく、レビューでも指摘されにくいのです。

つまりAIが変えたのは、あいまいさの発生量ではありません。あいまいさが表面化する確度とタイミングです。人間なら着手時に出たはずの問いが、本番2週間前まで出てこないことがあります。上流で問いを立て切ることの価値が跳ね上がったのは、このためです。

禁止ではなく、舵取り

ではAIに推測を禁止すればよいのでしょうか。それは不可能です。仕様のすべてを書き切ることはできず、AI補完はゼロにできません。本メソッドの立場は、禁止ではなく舵取りです——決定の理由（WHY）を残すこと。この記録は一般に ADR（Architecture Decision Record）と呼ばれます（本メソッドでの語義はアーキテクチャに限りません。規律の詳細は6章）。

その効きは二段になっています。一次の効きは、検出です。 WHYを残す作業は、残した記録がAIに効くより先に、書く側に効きます。決定の理由を書こうとすると、書けない箇所が出てきます——それが空白の在処です。埋まれば仕様に穴は残らず、埋まらなければ「未決」として明示されます。どちらにせよ、AIが推測で埋める場面は来ません。記録は、空白の検出装置でもあります。

二次の効きが、舵取りです。それでも書き切れなかった空白に対しては、残されたWHYが、許される補完の方向を絞り込みます。決定理由の記録が「AIの暴走を防ぐ手綱」と呼べるのはこの段のことであり、手綱が要るのは、穴を塞ぎ切れなかったところだけです。

ただ、記録を残すだけでは足りません。AIは速く進み、出てきたものは、うまくいっているように見えます。だからこそ、意図的に立ち止まる機会を作ることが大切です。その置き方は3章で扱います。

シフトレフト——ただし理想論ではなく

品質活動はV字の左へ寄せます（シフトレフト）。上流で決まっていることが多いほど、AI補完の余地は減ります。ただし本メソッドは「上流で全部決まる」とは考えません。あいまいさは段階的に解消される——これは従来のSIと同じ前提です。だからこそ「決まったこと」と「まだ決まっていないこと」の区別が生命線になります（2章）。

ここで、本書の立場をひとつ明らかにしておきます。

シフトレフトを理由に、上流で要件を全部出すことを発注者に迫りません。「シフトレフトだから要件を全部出してください」は拡大解釈です。上流で決め切れないのは発注者の怠慢ではなく、業務そのものが持つ性質です——動かしてみないと分からないことは、必ず残ります。

日本のSIの現実：文書は2つの条件を同時に満たす必要がある

世に出ている仕様駆動開発（SDD）の解説の多くは、仕様を段階的に精緻化し、反復のたびに調整していく前提で書かれています。その前提の背後には契約の形がある——出来高払いの契約なら、仕様が固まり切っていなくても次の反復で調整できるからです。

一方、日本の大規模SIには、固定価格・納期固定で進む従来型のプロジェクトが、いまも多く残っています。本書は、どの契約の形が望ましいかを論じません。ただ、従来型のプロジェクトである限り、「要件定義書に書かれた機能が動くこと」が完成の定義になり、仕様を変えるには契約の変更が要ります——つまり仕様の境界が契約に直結しています。この条件のもとでは要件定義・外部設計という工程を省略できませんし、そこで作る文書は業務部門・経営層が承認する公式文書＝検収の対象になります。

したがってSI文書は、次の2つを同時に満たさなければなりません。

• ① 業務部門が承認できる——業務の言葉で書かれ、システムに詳しくない人が「これで間違いない」と判断できる
• ② AIが実装できる——推測の余地が残らない精度で書かれている

この2つは、放っておくとぶつかります。分かりやすく書けば精度が落ち、精度を上げれば業務部門が読めなくなります。本メソッドはこれを、文書の文体で解こうとはしません。決定と、その理由と、辿れる網を文書に添えることで、同じ文書が2つの読者に応えられる状態を作ります。②を担うのはこの後に並べる機構そのものであり、①を誰が担うかも含めて、その状態を次章で定義します。

なお、この前提は永久ではありません。アジャイル開発のように、開発全体を準委任で進める形へ寄せていく動きもあり、そのためのモデル契約も公開されています（付録_出典）。契約の形が変われば、本書が引き受けている制約の一部は不要になります。そのときは、変化を前提にした方法へ移ればよいのです。本メソッドは、いまの現実に向けて設計された道具です。メソッド自身も育てるものであることは、14章の最後で述べます。

第2章Trusted Spec の定義

目的はひとつだけ

本メソッドの目的はひとつです。

AIに安心して実装を任せられる仕様 ——「信頼できる仕様（Trusted Spec）」—— を育てること。

Trusted Spec の3条件

3条件は、前章で見た問題にそれぞれ対応します。①は推測の混入口を塞ぎます——「未決」と明示された箇所を、AIは勝手に埋められません。②は補完の舵取りです——WHYが残っていれば、許される補完の方向が絞れます。③は流れてしまった推測を捕まえる網です——要求と実装を突き合わせれば、根拠のない実装が浮かび上がります。

3つを、もう少し具体に見ていきます。

①決まっている

満たしている状態とは、決まったことと決まっていないことが、読んで区別できる状態です。未決が無いことではありません——未決は必ず残ります。未決が「未決と分かる形」で書かれ、置き場を持っていれば、それで足ります。その置き場がISSUEです。ISSUEは、決めるべき論点と、決定を反映する作業の記録です。どの現場も課題管理として回してきたものにあたり、本書では、まだ決まっていない論点を未決型ISSUEとして置きます。書き方と置き場は5章で扱います。

これが崩れる典型が「決まったふり」です。あいまいなまま断定形で書かれた記述は、AIから見れば決定と見分けがつきません。前章の「変更可能とする」がまさにそれで、未決であることが読み取れないから、推測で埋められました。

②根拠がある

ここでいう業務ルールは、業務上の取り決めのことです。「何のため」の根拠の側にあたります。業務ルールに関してプロジェクトが下した決定とは、業務ルールをどう実現するか、どう解釈するか、どこまで適用するか、例外をどうするか、誰が変えるか、を決めたものを指します。

決定を残す器が、決定の記録＝ADRです。一般には Architecture Decision Record を指しますが、本書ではアーキテクチャに限らず、業務ルール・権限・状態の定義など、AIが推測で埋めそうな空白を塞ぐ決定を扱います（理由は6章「なぜ業務ルールで線を引くのか」）。

3つ目が効くのは、後から「その前提はもう変わりました」と言える相手が特定できるからです（11章）。

すべての決定に3点を求めるのではありません。範囲を業務ルールに関する決定に絞るのは、そこが、AIに黙って埋められたときの害が大きく、発注者への説明責任が生じるところだからです。前章の失敗例——閾値を誰が変えるのか、画面が業務判断をしてよいのか——は、どちらも業務ルールに関する決定でした。そして、【広げる】の業務との整合が業務ルールに照らして問うのも、同じ範囲です（9章）。書く側と問う側が、同じ対象を見ています。

ISSUEとの線引きは、ひとつだけ覚えておけば足ります。ADRは変更不可で、置換されることでしか終わりません。ISSUEは可変で、クローズします。形式と運用は、ADRを扱う後の章が定めます。

③辿れる

双方向であることに意味があります。要求から実装へ辿れれば「決めたことが実装されたか」が見え、実装から要求へ辿れれば「この実装には根拠があるか」が見えます。前者は変更が来たときの影響範囲の特定に効き、後者は障害時の原因追跡と、根拠のない実装の発見に効きます。影響範囲の調べ方は変更管理の章、実装からの辿り方は13章にあります。

現実の重さ：SSoTの維持コスト

大規模SIでは、要件定義書と外部設計書の両方をSSoT（Single Source of Truth：信頼できる唯一の情報源）に含めざるを得ません。要件定義書だけでは実装に足りず、外部設計書だけでは業務の承認が取れないからです（前章のSI文書の2条件）。そして、SSoTの維持は重い。仕様変更のたびに両方を追従させる作業は、正直に言って負担です。

本メソッドが目指しているのは、ここです。Trusted Spec を育て、維持する重さを、払える範囲まで下げること。理想の完全文書を求めるのではなく、検査をAIに担わせ、検査の相手を絞る仕組み（10章）で、維持をできるだけ軽くします。

諦めていた「在るべき姿」に、手が届くようになった

ここまで書いてきたことに、目新しい主張はひとつもありません。決定の理由を残す。要求から実装まで辿れるようにする。決めたことが守られているか確認する——いずれもSIの現場が長年「やったほうがいい」と言い続けてきたことです。

決定理由を残す試みには、半世紀の蓄積があります。設計根拠（Design Rationale）と呼ばれる研究分野で、決定・代替案・理由を記録する形式が繰り返し提案されてきました（付録_出典）。その最大の教訓は、書くコストが読む便益を上回ると続かない、というものです。本書がコストの回収されない場合を先に書き（後述）、運用の重さに15章の1章を割いているのは、この教訓を受けています。

やれなかった理由もはっきりしています。整合性を保つ作業コストです。文書間を突き合わせ、変更のたびに全体を追従させ、決めたことが崩れていないか読み直す——人手でやれば膨大で、納期に追われれば真っ先に削られます。在るべき姿は分かっていました。割に合わなかっただけです。

変わったのは、理想の中身ではありません。その作業コストのほうです。読んで突き合わせる、抜けを探す、決めたことと照らす——AIが担えるのは、まさにこの種の作業です。前章ではAIを、仕様の空白を推測で埋めてしまう側として書きました。しかし同じAIが、整合性を保つ側の働き手でもあります。本メソッドが提案しているのは新しい理想ではなく、諦めていた在るべき姿に、もう一度手を伸ばすことです。

コストはどう動くか——増える作業と、減る作業

とはいえ、人の作業がゼロになるわけではありません。何が増えて何が減るのかを、対照で示します。

右の列で「減る」と書いたのは、受託者側の作業です。ADRが増えても、書き手が読むのは自分の成果物に関係する決定だけで、台帳全体を探し回らずに済みます。ただ、決定と成果物を突き合わせる量そのものは、決定と成果物が増えるほど増えます。そこはAIの検査が引き受ける量で、その重さは、運用の重さの章で扱います。

発注者の側にも、増えるものと得るものがあります。

左の列の多くは、発注者がこれまでもやってきたことです——決定を承認し、打ち合わせで決定事項を読み合わせる。本メソッドが変えるのは、それが残る形になることと、あいまいなまま先へ送っていた箇所が、承認の前に見えるようになることです。SI文書の条件①（業務部門が承認できる）は、こうして発注者が読むところで担われます。

ただ、増える作業のもとが取れるとは限りません。一度きりの小規模開発、変更がまず来ないシステム、担当者が入れ替わらないチームでは、回収されない場合もあります。本メソッドが効くのは、長く生きて、変更が来て、人が入れ替わるシステムです。大規模SIの多くはそこに当てはまりますが、当てはまらないものに無理に適用する必要はありません。

そして、そのボーダーラインを定義するのは、難しいところです。ここまでの増減はあくまで構造としての説明であり、「この規模から先は回収できる」と数字で言い切れるものではありません。だから、このメソッドのうち適用できそうなところから適用してください。自分の組織の実態、プロジェクトの実態と傾向に照らしながら、どこまでが自分たちに合うのかを導き出してください（14章）。

射程の宣言：Level 1

本メソッドが狙うのは、AI-Native開発の成熟度モデルの Level 1（AI-Generated） です。AIが開発実務を担い、要件とハイレベルな設計は人が確定し、品質は人がレビューで作り込む段階で、移行の鍵はコンテキスト認識（ContextAwareness）——AIが正しい文脈を持って生成できること——にあります。Trusted Spec とはまさに、AIに与える「正しい文脈」の器です。

図は、段階が上がるにつれて、AIが担う範囲が広がっていく様子を示しています。

• ベースライン（AI-Assisted）：AIは補助の道具。作るのも、品質も、すべて人が担う。
• Level 1（AI-Generated）：AIが動くものを作り、人が品質を作り込む。
• Level 2（AI-Verified）：AIが品質を作り込み、人がプロセスの透明性を担う。
• Level 3（AI-Explainable）：AIが透明性まで担い、人が説明する。

どの段階でも、最終的な責任（アカウンタビリティ）は人に残ります。

本書の射程は Level 1（ContextAwareness） に留めます。Level 2・Level 3 は約束しません。

なお前章で使った「シフトレフト」は、品質活動を工程の左へ寄せるという一般的な用法です。このモデルでは、Shift-Left は Level 2 の特徴を表す語として使われていますが、本書の用法はそれとは別のもので、射程を先取りするものではありません。約束できないことを約束しないのも、「決まっている／決まっていない」の区別の実践です。

この流儀は、本書全体の書き方の規律でもあります。各章は、定めたこと（規範）と、プロジェクトが選ぶこと（プラクティス）と、まだ決まっていないことを、文面上で区別して書く。解けていないことは、解けていないと書く。

「育てる」という動詞

Trusted Spec は、特定の文書の名前ではありません。プロジェクトの文書群が3条件を満たしている「状態」の呼び名です。状態なので、一度では完成しません。未成熟・仮置き・揺れを前提とし、サイクルを回して段階的に成熟させます。「作る」ではなく「育てる」と呼ぶのはそのためです。

育てる対象は仕様だけではありません。決定がルール・ガイド・観点へ発展していくことで、プロジェクト環境（プロジェクトハーネス）も育つ——誰が書いても一定の品質になる環境が整うことは、本メソッドのもうひとつの到達点です。

第3章育て方サイクル総論

1周のストーリー

成果物は一度で完成しません。だから、育てるための決まった手順——4ステップのサイクル——を回します。

そしてこのサイクルを、本メソッドは人だけで回すとは考えていません。AIとともに成果物を育てる——4ステップのそれぞれに、人の隣で働くAIがいます。何をしてもらうかは、ステップごとに違います。

まず叩き台を書く（【たたく】）。叩き台には必ず未決と論点が残るため、SE・発注者と議論して決め、決めた理由をADRに残す（【深める】）。個々の論点を潰しても俯瞰したときの抜けは残るため、視点を引いて検査する（【広げる】）。そして、決めたことがその後も守られているかを検算する（【確かめる】）。この1周で成果物はひとつ成熟し、次の周でさらに育ちます。

後ろの2つは、どちらも検査です。【広げる】は成果物と運用場面を突き合わせます。一方【確かめる】は成果物と決定を突き合わせます。特に、【広げる】は、順調に進んでいるように見えるときこそ、意図的に立ち止まる機会を作る目的があります。

一つの文書の書き方（体裁・命名）は、どちらの検査でも問いません。書き手が書いた直後に整えるものです（4章）。

4ステップを貫いて、決定の記録＝ADRがあります。【深める】で生まれ、【確かめる】で検算の基準になります。

AIに何をさせ、何をさせないかの線引きは、この規範に尽きます。検査側の共通規律としての明細は9章、任せ方の勘所は【たたく】の章に置きました。なお、ここでいうAIは特定の製品を指しません——プロジェクトの文書群を材料として渡したAIが担える形で、本書は書いています。

本書が厚く書くのは、後半の2ステップである

先に断っておきます。【たたく】と【深める】を、本書は深くは説明しません。叩き台を書くこと、関係者と議論して決めること——これは読者のみなさんがこれまで培ってきたものそのものであり、本書が教え直すようなものではないからです。本書がそこに足すのは、決めたことと、決めた理由を記録に残すという一点だけです（5章）。

本書が厚く書くのは、【広げる】と【確かめる】のほうです（8章・10章）。俯瞰して抜けを探す、決めたことが守られているかを全体と突き合わせる——やったほうがよいと分かっていながら、人手では割に合わなかった作業です。AIが担えるようになって、ようやく現実的になりました。

小さく回して、視野を広げる

全体を一度に相手にすると、叩き台は薄くなり、シミュレーションのシナリオは一般論になり、論点は散ります。だから業務フロー1本のような小さい単位で回します。単位の切り方と段数はプロジェクトが決めます（例：業務フロー→業務ドメイン→全体。導入の進め方は14章）。

小さく回すと、単位ごとに決めたことがばらばらにならないかが気になります。けれども、単位をまたぐための引き継ぎの作業は、新しく作りません。今ある仕組みが、そのまま受け渡しを担います。

• 決まったことは、ADRとして台帳に残ります。上の単位の書き手が引くのは、自分の成果物に当たるADRと「横断」のADRです。下の単位だけに当たるADRまでは引きません（4章）。
• 決まらなかったことは、節目の棚卸しが拾います。
• 単位どうしの食い違いは、広い単位で【広げる】を回すと見つかります。歩かせるシナリオが、複数の単位の成果物をまたぐからです。見つかったら上の単位の【深める】で決め、下の単位の決定を置き換えます。下の単位だけの例外なら、下に残して構いません。

工程をまたぐとき

変わるのは、【広げる】のレンズだけです。

工程をまたぐときも、仕組みは増えません。要件定義の決定は現役のまま残ります。外部設計でADRを起こすのは、設計の側で新しい決定が出たときだけです。要件定義で決めきれずに持ち越したものは、工程の節目の未決型ISSUEの棚卸しが拾います（5章）。

この形にしておくと、方針が成果物に反映されていなければ外部設計に届きようがありません。反映漏れが、構造として見えるようになります。ADRどうしのリンク（置換など）と、同じ工程の中の単位どうしは、この決まりの対象外です。

変更が来たときも、同じサイクル

ここまでの1周は、新規作成を前提に描きました。しかし仕様は変わります——変更要求が来たときも、同じ4ステップを別の入り方で回します。入口は【深める】であり、新しい台帳も新しい検査も増やしません。変更の受け付け・影響範囲の特定・既存の決定の置換・反映の追い切りは、11章で扱います。

第4章たたく ── 叩き台の執筆

この章で語ることは、多くありません。叩き台を書くことは、これまで培ってきた仕事そのものだからです。本メソッドは、そこに新しい手順を足しません。

何を書くのか

あなたが書くものは、これまでの要件定義・外部設計で作ってきたものと変わりません。一般的には、要件定義なら業務の定義、業務の流れ、業務イベントと例外、ユースケース、要求事項、主体（アクター）の一覧、情報（エンティティ）の一覧、権限と情報の取扱い、外部インタフェース、用語集——といった成果物が並びます。外部設計なら、ユースケースの設計、状態の定義と遷移、画面、データの入出力、権限（外部設計版）といったものになります。

成果物の数・名前・分け方は、プロジェクトの標準に合わせてください。本書が求めるのは、次の2点です。

こう書いた業務の流れは、後の【広げる】で業務のシナリオを歩かせるときの道になります。タスクとタスクの受け渡し、タスクの終わり、タスクのつなぎ目が、そこで検査されるようになります。

たとえば、ユースケースは業務の流れのどのタスクを実現するのか、要求事項はどのユースケースから出てきたのか、画面はどのユースケースのためのものか。書いた人の頭の中にあるこのつながりを、成果物の上に書いておきます。これが、Trusted Spec の条件③（辿れる）の中身です。

このつながりが表すのは、何を根拠に書いたかです。どちらを先に書いたかは問いません。

検査のために、何を揃えておくか

書いたものは、この後【広げる】と【確かめる】にかけられます。どちらも、書かれたものを読み直す作業です。読み直すときの手掛かりは、書くときにしか置けません。そこで、書き方の様式はプロジェクトの標準のままにして、検査が手掛かりにする要素だけを、ここで挙げておきます。

実際の成果物のどこにどう現れるかは、付録に例があります。

表の語は、次の意味で使っています。プロジェクトの標準が別の名前を使っているなら、そちらで読み替えてください。

• 主体：タスクを担う人・役割・組織・システム（「アクター」と呼ばれることが多い）。
• 開始条件・事後条件：そのタスクを始めてよい状態と、終わったときに成り立っている状態。テスト工程では事前条件・事後条件と呼びます。
• 業務ルール：業務上の取り決め。「何のため」の根拠の側にあたります。
• 状態の定義：情報がとりうる業務上の段階と、その意味。

関係する決定を、どう読み、どう残すか

叩き台を書くとき、すでに決まっていることがあります。前の工程で決めたこと、この工程の前の周で決めたことです。業務ルールに関する決定は、理由と一緒にADRという記録に残っています（2章）。最初の1周では、ADRはまだほとんどありません。周を重ねるほど増えていきます。

ADRには、その決定を受けて後の成果物が満たすべき状態（制約）と、それがどの成果物に当たるか（影響範囲）が書いてあります。特定の成果物に絞れない決定には、「横断」と書いてあります。

そのために、書く前に、それらのADRと上流の成果物を読みます。制約を記憶や推測で使わない、ということです。

たとえば販売業務のユースケースを書くなら、「販売業務のユースケース」に当たるADRと、「横断」のADRを読みます。あわせて、そのユースケースのもとになった要求事項を読みます。ADRが増えてきたら、影響範囲ごとにADRを引ける一覧（索引）を作っておくと、引くのが楽になります（7章）。

読んだ決定のうち、理由があって書かれた一文を、ADRを知らない人が善意で書き換えてしまうことがあります。そういう記述には、脇にADRのIDを書いておくと防げます。

注記は、付けるところを絞って構いません。付けていなくても、決定が守られているかの検査は届きます。検査は、決定の側から、当たる成果物を引くからです。ADRが後で置き換わっても、注記は書き換えずに済みます。元のADRから、新しいADRへ辿れます。

AIに、どこまで書かせるか

叩き台は、AIに書かせることができます。ただし、出てきたものは人が判断するための「たたき」です。

出力をそのまま成果物にすれば、1章で見たAI補完を、誰も確かめないまま通すことになります。人が読み、直し、決まっていないことを「未決」として残す——ここからサイクルが始まります。

線引きの理由は、ひとつです。AIは流暢に書きますが、その内容が正しいとは限りません。根拠のない補完や、一般論での埋め合わせが混ざっていても、見栄えは良い。だから、判断は人がします。

AIに、どう任せるか

どれも、任せ方しだいで効き目が変わります。

• いきなり清書させない。先に観点を出させ、人が選ぶ。最初から文章にさせると、採らなかった選択肢が文面から消え、後から「なぜこう書いたのか」を問えなくなります。候補を並べさせ、人が採否を決めてから書かせます。
• 書かせる前に、文脈を渡す。書き方の約束事、用語集、これまでの成果物、それに自分の成果物に当たるADR。制約を記憶や推測で使わないのは、書き手が人でもAIでも同じです。
• 埋めたところを、埋めたと言わせる。AIは、根拠が見つからない箇所も黙って埋めます。だから最初に「根拠が見当たらなかった箇所を挙げよ」と指示しておきます。挙がったものは、未決の候補として【深める】へ渡ります。
• 業務の正誤を含まない照合は、素直に任せる。用語の不統一や、成果物間の記述のずれは、量が多く、人が最も取りこぼします。ここはAIのほうが確実に速い。

書いたあと、何を見直すか

参照が辿れる状態にしておく

成果物どうしのつながりは、IDでの参照として書かれます。この参照は、書いたときには繋がっていても、直しているうちに切れていきます。消した要求事項を、ユースケースがまだ指している。同じ主体が、成果物によって別の名前で呼ばれている。そうなると、【広げる】でシナリオを歩かせても、途中で道が切れてしまいます。

自分の書いた文書を見るだけでは、どこからも参照されていない要素は見つかりません。全体は、節目にAIに照合させます。

第5章深める ── 議論・決定・未決

議論は、どう進めればよいか

叩き台を挟んで、SE と発注者が議論します。論点を出し、確認し、合意する——この進め方そのものは、これまで培ってきたものです。本書は、新しい会議体も、新しい議論の手順も持ち込みません。動くものを見せたほうが違和感が言葉になりやすい、といった現場の知恵も、そのまま使ってください。

本メソッドが足すのは一点だけです。議論の出口を、記録として残すこと。出口は2つしかありません——決まったか、決まらなかったかです。

この議論にも、AIのサポートは効きます。させるのは、散らばった論点を並べ、決めるべきことを人の前に揃えることです。論点の候補を並べる、同じことを指している論点をまとめる、決まっていない箇所を指し示す——ただし、ここまでです。どれを論点として立てるか、どう決めるか、どこに残すかは人が決めます。論点に答えを出すのも人で、とりわけ業務の判断は、発注者側の責任者が負います。

AIに、どう任せるか

論点の整理は、議論の前と後の両方で効きます。

• 議論の前に、論点を立てさせておきます。叩き台を読ませ、決まっていない箇所・複数の読み方ができる箇所を一覧にさせます。議論の時間を、論点を探すことではなく、決めることに使えるようになります。前の章の「埋めたところを、埋めたと言わせる」が、そのまま議題の素になります。
• 同じことを指している論点を、先にまとめさせます。大規模では、同じ論点が別の言葉で何度も出てきます。束ねるのは機械的な作業で、人が読む論点の数が減ります。ただし、束ね方が妥当かは人が見ます——別々の論点を一つに潰していることがあります。
• 議論の後は、決まったことと決まらなかったことに仕分けさせます。決まったものは「何を決めたか／なぜ／誰の判断か」の形へ、決まらなかったものは未決型ISSUEの形へ整えさせます。整えるまではAIでよく、確定は人です。記録するのは、決定が下された後です（次の節）。
• 結論を言わせない。「どちらが良いか」を聞いた瞬間、流暢な結論が人の判断に入り込みます。出させるのは、選択肢と、それぞれが何を前提にしているかまでです。

すでに試されているかもしれませんが、ぜひ一度、AIと対話して、バイアスのかかり具合を体感しておいてください。自信に満ちた流暢な説明が、どれだけ抵抗なく自分の判断に入り込んでくるか——1章で挙げた権威バイアス・確証バイアス・自動化バイアスは、知識としてよりも体感として持っておくほうが効きます。議論の場でAIの出力を「たたき」として扱い続けられるかは、そこにかかっています。

決まったことを、どう残すか

議論の結果「決まったこと」を、あなたはなぜそう決めたか（WHY）と、判断した人の証跡とともにADRに記録します。ここが、Trusted Spec の条件②「根拠がある」が作られる瞬間です。

記録されない決定は、次の会議までに揮発し、AIにとっては存在しないのと同じになります。

ADRの書き方と、台帳としての扱いは、この後の2つの章で見ます。ここでは、議論の場で何を残すかだけを見ます。

何をADRにするか

すべての決定をADRにはしません。ただし、必ず残すものがあります——業務ルールに関してプロジェクトが下した決定です（2章）。業務ルールをどう実現するか、どう解釈するか、どこまで適用するか、例外をどうするか、誰が変えるか——これを決めたものが、それに入ります。外部設計で出る決定の多くも、ここに入ります。たとえば、与信の上限を超えた受注を、入力の時点で止めるか、登録の後で保留にするか——これは与信の業務ルールをどう実現するかの決定です。法令や社内規程のような、既にある業務ルールそのものは入りません。プロジェクトが決めたものではないので、業務ルールを書く文書に書けば足ります。

決まらなかったことを、どう残すか

議論しても、その場で決まらない論点はあります。判断材料が足りない、決める人がその場にいない、別の論点が先に決まらないと決められない——1章で見たとおり、あいまいさは段階的に解消されていくものなので、これは普通のことです。

大事なのは、決まらなかったことを「決まらなかった」と分かる形で残すことです。未決と書いてある箇所は、AIが勝手に埋められません。そして未決の一覧が、そのまま次の議論の議題になります。決まったことと未決のことが区別されている——Trusted Spec の条件①は、この場面で作られます。

ISSUEには2種類あって、決定の前と後をつなぎます。決める前の論点が未決型ISSUE、決めた後の反映作業が反映型ISSUEです。

図は、分かりやすいように主な流れだけを描いています。未決型ISSUEが決まると、多くはADRになり、反映型ISSUEで成果物に入ります。ADRにするほどではない決定なら、そのまま成果物に反映して閉じることもあります。

成果物の側では、未決の箇所に、そのISSUEのIDを添えた未決の印を付けます。これで成果物からISSUEへ、ISSUEから成果物へ、双方向に辿れます。実装するAIは未決の印を見て「ここは埋めてはいけない場所だ」と判別できます。

そうしないと、AIが未決を量産して、議題が議題でなくなります。

未決を、成果物にどう書くか

あなたは、決まらなかった箇所を成果物の中に書き残します。

①は、「検討中」「要確認」といった言葉が本文に埋もれているだけでは足りない、ということです。そこが決まっていないと、読み手が見落とさずに分かる形になっていること。②で辿った先のISSUEに、なぜ決まっていないのか、いつ・誰が決めるのかが書いてあります。書いた形の例は、付録のサンプルにあります（【未決：ISSUE-0012】）。

ADRの注記は付けるところを絞ってよいのですが、未決の印は書き漏らせません。成果物を読む側——とりわけ実装するAI——は、ISSUEの一覧を見ないからです。印のない空白は、「埋めてよい空白」に見えます。

決まらなかったことを、持ち越す

未決型ISSUEは、放っておくと溜まります。反映型ISSUEは、【確かめる】で指摘が出なくなれば閉じられますが、未決型ISSUEには、閉じさせる力が働きません。だから節目で見直します。

単位を広げる節目も、この規範の対象です。業務フロー1本から広い範囲へ移るときに、開いている未決型ISSUEを一覧して仕分けます。単位をまたぐときに引き継ぎの作業が要らないのは、未決の側をこの棚卸しが拾うからです。

第6章ADRの扱い ── 決定を書く

ADRに何を書くか

ADRに必ず残すのは、業務ルールに関してプロジェクトが下した決定です（2章）。

この5つには、Trusted Spec の定義の章で挙げた3点（何を決めたか／なぜそう決めたか／誰の判断か）が含まれています。

例をひとつ示します。題材は、最初の章の例1、送料無料の閾値です。この章と次章では、このADRを最後まで使います。

# ADR-0231：送料無料の閾値は、業務部門が自分で切り替える

## ステータス
- 状態：仮決定
- 発生工程：要件定義
- 確定者：発注者側の販売業務責任者
- 発生箇所：販売業務
- 置換：なし
- 前提とする決定：なし

## 背景
閾値の変更は、恒久的な料金改定ではなく、期間を区切ったキャンペーンの
実施手段である。売り方を決めるのは業務部門であり、実施の判断から
反映までの間に開発側の作業が挟まると、打ちたいときに打てない。
履歴を残すのは、過去の受注がどの条件で成立したかを後から説明する
必要があるためである。

## 決定
送料無料の閾値は、業務部門が自分で切り替えられる形で提供する。
開発側のリリースを伴う変更手段は採らない。変更の履歴を残す。

## 結果
### 良い結果
キャンペーンの実施が、開発側の作業計画から切り離される。
### トレードオフ（悪い結果）
変更の手段・権限・履歴の分だけ、作るものが増える。

### この決定から生じる制約（後続成果物が満たすべき状態）
- 販売業務の要求事項：閾値は業務部門が変更し、変更に開発側のリリースを
  必要としないことが記述されている。
- 販売業務の要求事項：閾値の変更履歴（変更日時・変更者・変更前後の値）を
  保持することが記述されている。
- 販売業務の業務の定義：閾値の変更が、開発側のリリースを伴う作業として
  記述されていない。
- 販売業務のユースケース：業務部門の担当者が閾値を変更する手順（システムの
  ふるまいを含む）が記述されている。

（番号も題材も架空です。ステータス節の項目〈状態・発生工程など〉は、次の章で扱います。）

確定者は、Trusted Spec の定義の章でいう「誰の判断か」にあたります。

本メソッドで大切にしているのは、制約節です。この決定を受けて、後の成果物に何が書かれていればよいかを書く節です。

書く人にとっては、決定を詰める道具になります。どの成果物に何が書かれていればよいかを書こうとすると、決定のあいまいなところが見えてきます。そして後で成果物を書く人は、自分の成果物に当たる制約を読んで、何を書けばよいかを知ります（【たたく】の章で見たとおりです）。

検査にとっては、決定が効く先の目印になります。制約節がないと、この決定がどこに効くのかが推測できず、検査の範囲が広がりすぎてしまいます（10章）。

制約節に何を書くか

影響範囲をどう書くか

文書を名指しで書けるなら、そのほうが良い書き方です。反映漏れを見つけやすくなるからです。ADR-0231 では、販売業務の要求事項・業務の定義・ユースケースを名指しています。できるだけ名指しを目指しますが、名指しできないときは、業務プロセスやサブシステムのような範囲で書くこともできます。もっと広く、プロジェクト全体に及ぶときは「横断」と書きます。「横断」の表記は、開始時に決めておきます。空欄にしないのは、空欄では、横断と書き忘れの区別がつかないからです。

その工程で決めたことは、その工程の成果物に反映されて、次の工程へ流れます。

満たすべき状態をどう書くか

制約節の各行は、その影響範囲の成果物を人やAIが確かめるときのチェック項目になります。

多くの項目は「〜が記述されているか」になります。何の記述かを具体的に書きます。ADR-0231 のユースケースの行なら、「業務部門の担当者が閾値を変更する手順」です。機能として「できてはいけないこと」も、「〜ができないことが記述されている」と書きます。この形の項目は、どこに書かれているべきかが決まっていないと確かめられないので、影響範囲を「横断」にしません。

ほかにも、たとえば次のような項目が書けます。

• 決定と食い違う記述が残っていないか。決定より前に書かれた文書に効きます。ADR-0231 の業務の定義の行がそれです。名指した文書を1件ずつ読めば答えが出るので、最も判定しやすい項目です。
• 書かれている内容が、決定どおりの条件になっているか。たとえば、閾値を変更できる主体が、包括的な役割名ではなく業務部門の役割として書かれているか、です。

答えが出ない項目は書きません。「配慮されているか」「適切か」は、読む人によって答えが変わります。

検査が崩れる書き方と、直し方

ADR-0231 を書く途中で起こりうる崩れ方を、わざと作った例です。

制約が書けないとき

業務ルールに関する決定なのに、制約が1つも書けないことがあります。どの成果物に何が書かれていればよいのかが言えない、ということです。それは、決まり切っていない疑いの合図です。ADRにするか、未決型ISSUEにするかは、人が判断します。どちらに残しても、漏らしてはいません。

制約はまだ書けないが、理由だけは残しておきたい決定もあります。そういうときは、成果物の本文に理由を書き添えて残して構いません。ただし書き添えは索引に載らず、検査にも掛かりません。増えれば、後で「これは決定だったのか」を人が読み返して拾い直すことになるので、迷うなら、制約の形に書けないかを先に試してください。

業務ルールのほかにも、残したい決定があるとき

決定の中には、業務ルールではないけれど、後で「なぜこうなっているのか」と聞かれそうなものもあります。どこまでADRにするかは、開始時に線を決めておきます。

この目安で書いたADRは、書いた瞬間から【確かめる】に使えます。目安なので、境界の事例は残ります。迷ったら人が判断します。

どの線を使っても、ADRに書かないものが2つあります。

なぜ業務ルールで線を引くのか（読み飛ばしてよい）

主流のADRは、アーキテクチャ上重要な決定に絞ります。代表的な様式は一度 "Any Decision Record" を名乗りましたが、2024年の改訂で "Architectural" に戻りました。絞る理由は、陳腐化と維持コストです（付録_出典）。

本書がそれに従わないのは、SIでAIが埋めてしまう空白が、アーキテクチャの外にあるからです。最初の章の失敗例——閾値を誰が変えるのか、画面が業務判断をしてよいのか——は、どちらも業務ルールの決定です。アーキテクチャで絞れば、拾うべき決定が対象から外れます。

ただし、本書は実のところ、完全な "Any" ではありません。業務ルールに関する決定は必ず残します。それ以外の決定は、制約が書けるかで絞ることを勧めます（前の節）。主流が「重要か」で残すものを絞るのに対し、本書は「業務ルールに関する決定か」で必ず残すものを決めます。維持コストのほうは本書も引き受けており、その勘定は15章にあります。

第7章ADRの扱い ── 台帳を守る

台帳を守る

ADRは、プロジェクトが進むにつれて何十、何百と溜まっていきます。1本ずつ書いただけでは、やがて次のことが分からなくなります。

• 自分がいま書いている成果物に、どのADRが影響するのか。
• 同じことを決めたADRが2本あるとき、どちらが今も生きているのか。
• 成果物が指しているADRや、ADRが指している成果物が、まだ実在するのか。

ADRの束を、こうしたことに答えられる状態に保つ必要があります。

状態と属性を残す

台帳として並べ、探し、つなぐには、決定の中身とは別に、ADRについての情報が要ります。

それぞれ、次のことを表します。

• 状態：いまどの段階にあるか（仮決定／承認済み／発展済み／廃止）。
• 発生工程：その決定がどの工程で生まれたか（要件定義・外部設計など）。
• 発生箇所：その決定がどこで生まれたか（どの業務・サブシステムで決めたか）。
• 確定者：誰が確定したか。
• 置換リンク：置き換えた元のADR、置き換えた先のADR。
• 前提とする決定：その決定が前提として置いている、別のADR。前提のADRが置き換わったときに、影響を受けるADRを拾うために使います。

発生箇所と影響範囲は、別のものです。X業務で生まれた決定が、Y業務の成果物にも影響することはあります。影響する相手は、制約節の影響範囲に書きます。

たとえば ADR-0231 なら、ステータス節に書く代わりに、ファイルの先頭に次のように持ちます。

---
id: ADR-0231
状態: 仮決定
発生工程: 要件定義
発生箇所: 販売業務
確定者: 発注者側の販売業務責任者
置換元: なし
置換先: なし
前提とする決定: なし
---
# ADR-0231：送料無料の閾値は、業務部門が自分で切り替える

影響範囲はヘッダに写しません。制約節の各行（「販売業務の要求事項：…」）から読みます。

ヘッダに整理しておくと、次のような索引が作りやすくなります。

影響範囲                      影響するADR
横断                          ADR-0007
販売業務の要求事項            ADR-0231
販売業務の業務の定義          ADR-0231, ADR-0205
販売業務のユースケース        ADR-0231

ADRの一生

ADRに書くのは、決まったことだけです。まだ決まっていないことは、未決型ISSUEに置きます。

書いたばかりのADRは、仮決定です。「仮」とありますが、決定そのものはもう済んでいます。仮なのは記録のほうで、決定を正しく書き写せているか、制約節が検査に使える形になっているかを、まだ磨いている段階です。記録が決定を正しく写していると確かめられたら、承認済みになります。

仮決定でも、決定そのものは済んでいます。だから、承認を待つあいだに検査の空白を作らずに済みます。状態を添えておけば、指摘を受けた人は、根拠の決定がどこまで固まっているかを知ったうえで直せます。

決定そのものが、プロジェクトのルールや標準の方針として取り込まれることもあります。たとえば、「マスタを改定しても、確定済みの伝票は改定前の値のまま表示する」という決定が、受注で決めた後、請求・発注・出荷など伝票を持つ業務に広がり、プロジェクト共通のルールに書き込まれる、といった場合です。このときADRは消さずに、発展済みにします。

決定した内容を変更するときは、ADRを書き換えずに置き換えます。

複数の決定を1つのADRにまとめると、成果物との整合が取りづらくなるので、1決定1ADRを原則とします。追記を認めると、1つのADRの中に古い内容と新しい内容が混ざり、どの時点の内容で成果物を確かめればよいのかが分からなくなります。だから追記はせず、置き換えます。

成果物との整合を保つ

ADRの制約節は、影響範囲で成果物を示しています。ADRどうしも、置き換えや前提でつながっています。ADRが置き換わったり、成果物が消えたり名前が変わったりすると、指した先がなくなることがあります。そこで節目に、AIなどを使って、つながりが切れていないかを確かめます。見るのは次の3つです。

• 制約節に書いた影響範囲が、プロジェクトの文書に実在するか。「横断」は正しい値として扱います。
• 成果物の未決の印にあるISSUEのIDが実在し、開いているか。閉じたISSUEの印が残っていたら、成果物への反映が済んでいない合図です。
• ADRの前提とする決定が、廃止になっていないか。廃止になっていたら、そのADRを置き換えるか、そのまま残すかを人が決めます。

成果物に注記を付けているなら、注記のADRのIDが実在するか、別の工程のADRを指していないかも、あわせて見ます。

このうち、影響範囲の実在だけは、漏らさずに見ます。

影響範囲だけを厳しく見るのは、ADRと成果物のつながりの正本が、制約節の影響範囲だからです。ここが切れていると、【確かめる】はその決定を当てる相手を見失います。

前の工程の成果物を名指す決定

前の工程の成果物を名指すのは、ADRの章の規範（影響範囲に書けるのは、決めた工程の成果物だけ）から外れた書き方です。ただ、外れたこと自体が、前の工程で決めるべきことが決まっていなかったという合図になります。書き直させて消してしまうと、その合図も消えます。そこで弾かずに残し、名指された前の工程の成果物を直すときは、変更として扱います（変更管理の章）。

ADRの発生工程と、制約節が名指す成果物の工程を突き合わせれば、こうした決定はAIなどで拾えます。台帳が、シフトレフトの効き具合を映します。

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

【広げる】とは、何をする検査か——シナリオを歩かせる

成果物がひととおり揃ってきたら、俯瞰した視点から「足りているか」を確かめます。それが【広げる】です。

シナリオが歩く道は、業務の流れです。タスクごとに担う主体・開始条件・事後条件を持った業務の流れがあって、はじめてシナリオは歩けます。

トレーサビリティを確認するような検査は、書かれているものどうしのつながりの切れ目や食い違いは見つけられても、そもそも書かれていないものには届きません。シナリオを歩かせると、書かれていないところで止まります。この技法そのものは要件工学で確立されたもので（付録_出典）、本書が変えたのは、シナリオを作って歩かせる役をAIに担わせた点です。

【広げる】は、節目に立ち止まって回します。意味を問う検査なので、同じ成果物を二度検査しても、同じ指摘が返るとは限りません。指摘を採るかどうか、どこに記録するかは、人が決めます。

歩かせると、何が見えるか

たとえば、次のような空白です。

• どの成果物にも持ち主のいない属性。 閾値の切り替えを予約する前提になっているはずの「キャンペーン期間」が、業務の定義にも情報の一覧にもユースケースにも、どこにも定義されていません。
• 設計が置いた単位の、外側にある実務。 「注文ごと」を前提に送料を設計したが、同じ顧客が同じ日に分けて注文した場合の扱いに、どの成果物も触れていません。
• 権限が一方向にしか設計されていません。 閾値を変更する操作は与えられているが、誤って切り替えたときに、すぐ元へ戻す手段がありません。

いずれも、記述どうしの食い違いではなく、そもそも書かれていないことに特徴があります。

シミュレーションを、どう回すか

AIにシナリオを創作させる

AIに業務シナリオを創作させること（担当者の異動と引き継ぎ、キャンペーン期間中に受注が締め日をまたぐ、急ぎの値下げで承認を省きたくなる、等）は、「AIは答えを生成しない」という共通の規律からの、意図した例外です。例外はシナリオという一点だけで、範囲を次のように固定します。

成果物どうしの参照がきれいに繋がっていても、書かれていないものは残ります。だから、シナリオを歩かせて疑います。

AIに、どう任せるか

この検査は、AIにサポートさせて回します。効くかどうかは、任せ方で決まります。

• 答えではなく、問いを出させる。 「ここは○○とすべき」まで書かせると、人はその案の当否を考えはじめ、空白そのものを見なくなります。出させるのは「歩かせたらここで止まった」「読み取れなかった」までです。
• 思いついた順に作らせず、種を渡して狙いを持たせる。 シナリオの当たり外れは、種（次節）を渡すかどうかで大きく変わります。
• 実際に読ませ、読んだ箇所を言わせる。 記憶と一般常識で歩かせると、検査しているのは成果物ではなく、AIの常識になります。

シナリオの種

成果物は必ず暗黙の前提の上に書かれていて、その前提のうち最も支配的なのは時間です。成果物が描けるのは、1本の線の中の時間だけです。業務の流れは1回のプロセス実行を、ユースケースは1回の相互作用を、状態遷移は1つの対象の一生を描きます。実務で流れているのは、その線の外側の時間です。多数の案件（受注や申請のような、1件ずつの業務）が違う速度で並行し、その間に対象者は入れ替わり、担当者は異動し、期限のほうが先に来ます。シミュレーションが歩かせるのは、この外側の時間です。

この6つを全部回せば網羅できる、というものではありません。プロジェクトに合わせて、足したり削ったりしてください。自分で種を増やすときは、「この成果物が置いている時間の前提は何か」を問います。いつ時点の写しか、どれだけの長さを想定しているか、何本が同時に走っている想定か、です。

種はシナリオを作るときに使い、レンズは歩かせたシナリオを見るときに使います。種を見る目として使うと、レンズがひと通り当てて終わる照合リストに戻ってしまいます。

どれだけ回すか——軽く始めて、増やす

件数と深さは、プロジェクトの規模や成果物の状態に合わせて、検査のたびに調整します。

深くすれば論点は増えますが、人が捌く量も増えます。検査の大きさを決めるのは、AIの出力量ではなく、人が判断しきれる量です。

出てきた論点は、人が振り分けて初めて未決型ISSUEになります。AIが未決を量産することはありません。

歩かせたシナリオは、その後どうなるか

シミュレーションの成果は、その場の指摘で終わりません。登場人物・時系列・前提が具体化されたシナリオは、すでに試験シナリオに転用できる状態になっているはずです。また、書かれていなかったイベントや例外が見つかれば例外の一覧が充実し、そこから例外系の試験シナリオが立ちます（12章）。シミュレーションのコストは、テスト設計の前倒しとして回収されます。AIに渡すものと返ってくるものの実際の形は、付録の通し例にあります。

手元にあるなら、試してみてほしい

シミュレーションは、大がかりな準備をしなくても試せます。たとえば intra-mart の業務フロー（BPM）のエクスポートファイルは、そのままAIが読み取れます。これと各タスクのユースケースさえあれば、シナリオを歩かせることはできます。手元にあるなら、ぜひ一度試してみてください。

試すと、もうひとつのことが分かります。AIに渡す材料（成果物）が揃っていないと、思惑どおりにはならない、ということです。レーンを歩かせれば、その主体が何者かを説明する主体の一覧が欲しくなります。業務ルールと業務の流れ・ユースケースが整合しているかを見ようとすれば、突き合わせる業務ルールそのものが要ります。何が足りないかは、歩かせてみると分かります。

辿れる状態で回す

【広げる】は、成果物どうしの参照が辿れる状態（トレーサビリティがある状態）で回すと効きます。参照は書き手が保ち、節目にAIなどで全体を確かめます（【たたく】の章とADRの台帳の章で見たとおりです）。参照が途切れたままだと、返ってくるのは「読み取れない」の山になります。ただし、参照が揃う前でもシミュレーションは回せます。導入の初期は、ここから始められます。

参照が辿れれば、歩かせる前に、参照に沿って意味が噛み合っているかも見られます。「このタスクの事後条件と、次のタスクの開始条件」「この業務ルールと、それを実現するはずのユースケース」のように、照らす相手が参照で決まっている問いです（意味のペア照合）。問いと歯止めは、次の章のレンズのものをそのまま使います。照らす相手が決まらないもの、つまり書かれていないものには、シナリオを歩かせないと届きません。

混ぜると、照合の機械的な気づきばかりが積み上がり、シミュレーションの気づきが埋もれます。

第9章広げる ── レンズと歯止め

要件定義の4つのレンズ

要件定義では、シナリオを歩かせながら、次の4つのレンズで見ます。

レンズごとに、何を問い、何を問わないか（歯止め）を示します。歯止めを決めておかないと、指摘がきりなく増える可能性があります。

業務との整合

業務のゴールと、それを実現するはずのユースケースの目的が、意味として噛み合っているかを見ます。ゴールに要るのに、存在しない・繋がっていないユースケースはないか。業務ルールに繋がらない要件（要件の孤立）と、要件に反映されていない業務ルール（業務ルールの孤立）を、両方向から見ます。業務ルールが、「〜する」「〜を対象外とする」と事実だけを述べ、理由を欠いたまま書かれていないかも見ます。

実例

• 単価をマスタで管理しながら、受注明細で単価を上書きできる設計になっています。この裏に「客先ごとの個別値引き」という業務ルールが隠れていないか。
• ユースケースの目的が「在庫を引き当てるため」とユースケース名の言い換えになっていて、理由が空になっていないか。

境界・責任範囲

仕事の受け渡しを見ます。業務の流れでは、タスクからタスクへ仕事が渡っていきます。渡すときに、次の担当者が仕事を始められる状態が用意されているかを見ます。

たとえば、販売企画担当が送料無料の閾値を切り替えるタスクには、「キャンペーン計画に閾値が記録されている」という開始条件があります。では、この計画はどのタスクが作るのでしょうか。業務の流れのどこにも作るタスクがなければ、切り替えのタスクは始められません。

見るときは、各タスクの開始条件から手前へさかのぼります。タスクは分岐・合流するので、手前から順に追うより、「このタスクの開始条件を、どこが満たすのか」から見るほうが、抜けを拾えます。状態が用意されても、次の担当者がそれを知る手段がなければ、仕事は始まりません。知る手段が検討されているかも見ます。

もう1つ、どの担当者がどのデータにどこまで触れてよいか（権限）の線引きに、業務上の理由があるかも、このレンズで見ます。

実例

• 「在庫を引き当てる」の完了は、「出荷できる状態」を意味するか。
• 「申請者／業務申請データ／参照可・更新可／自身が作成した申請のみ、提出後は更新不可」——この線引きに業務理由があるか。

このレンズの背後には、「仕様の全域をAIと一致させることは不可能だが、責任の境界を一致させることは可能」という考え方があります。SIとは、責任の境界を合意・設計・検証する仕事だからです。

検証可能性

何をもって終わったと言えるかを見ます。業務の流れのタスクごとに、終わったとき何ができていればよいかが、読んで分かるかです。

たとえば「閾値の変更を確認する」というタスク。「確認した」とだけ書いてあると、後から、本当に終わったのかを確かめられません。「新しい閾値が、指定した日から有効になっている」と、終わったときに成り立っている状態（事後条件）で書かれていれば、確かめられます。「適切に」「必要に応じて」のように、判断を読む人に任せる言葉があるときも、確かめられません。

状態（「申請中」「承認済み」など）を並べた成果物があるなら、事後条件がその状態の名前で書けているかも見ます。状態の細かさがばらばら（「承認待ち」と「部長承認待ち」が並んでいる）だと、どこまで進んだのかが確かめられません。

終わった状態を書き直そうとすると、隠れていた業務ルールが出てくることがよくあります。「出荷を手配する」を書き直そうとすると、「在庫がある品は、受注日から3営業日以内に出荷する」という約束が出てくる、といった具合です。

実例：「希望納期を守れるか判定する」。何をもって守れると判断するのか。後で、果たされたかを確かめられる具体さになっているか。

正常系偏重

うまくいかなかった場合を見ます。あるタスクの終了が、次のタスクの開始条件を必ずしも満たさないつなぎ目で、うまくいかない場合が検討され、例外の一覧に整理されているか。例外の一覧にある例外が、業務の流れやユースケースに反映されているかも、逆向きに見ます。処理が完了・中止・失敗した後の受け取り手、後始末、並行する別のプロセスへの影響も見ます。

実例

• 欠品で在庫を引き当てられないケースは検討されたか。
• 類似の別処理では「対象0件」が例外として検討されているのに、この処理では検討されていない——この食い違いそのものを拾う。

外部設計の3つのレンズ

3つは、時間の上に並びます。

要件定義のレンズとは、正常系偏重と機能例外、境界・責任範囲とトランザクション境界が対応します。

トランザクション境界

複数の更新が、業務として同時に成立しなければならない範囲が、明確になっているかを見ます。たとえば、入金の登録と売掛金の消し込みは、片方だけが成立すると帳簿が合わなくなります。こうした範囲がどこまでか、途中で失敗したら何が巻き戻るのかが、はっきり書かれているか、です。

ここが書かれていないと、実装する側（AIでも人でも）は、更新をひとまとめにする範囲を自分で決めてしまいます。どちらも一見正しく動くので、片方だけが成立する不具合は、本番で帳簿が合わなくなるまで気づかれません。

実例：「承認と在庫引当は同時に成立する必要がある」。コミット後に非同期で走る連携は、失敗しても元の確定を巻き戻さない——その線引きが書かれているか。

機能成立性

この設計で、要件の機能が時間の中でも成立するかを見ます。自機能が参照するデータは、自機能の外で変わります。一覧に出した時点、操作する時点、確定する時点で、前提が同じとは限りません。シナリオの種の「並行して走る」「対象集合の鮮度」が、外部設計に降りてきた姿です。

実例

• 一覧に表示した対象が、確定しようとした時点では対象外になっている（他者が先に処理した、状態が進んだ、削除された）。
• マスタが改定された後に過去の伝票を再表示したとき、改定前の値を保持するのか、現在値を引くのか。

機能例外

うまくいかなかったことが、設計として明言されているか。中心にあるのは、戻せるのか、戻せないのかです。取り消し・訂正ができる設計なら、その手順と権限が書かれているか。できない設計なら、できないことが設計判断として書かれ、合意されているか。それでも戻したい場面に、運用としてどうするか（打ち消しの伝票、管理者による是正、再申請の導線）が設計に含まれているか。

戻せないこと自体は悪くありません。黙って戻せないことが問題です。書かれなかった箇所が、運用開始後に発覚します（1章）。

実例

• 確定した伝票を誤って確定した。取消機能はあるか。ないなら、打ち消しで対応するのか、管理者が直すのか、運用として諦めるのか——どれかが書かれているか。
• 外部システムへ送信済みのデータを取り消すとき、送信先との整合はどう取るのか。

どのレンズでも、AIに守らせること

AIが「ない」と言い切ると、人はそれを事実として受け取りやすくなります（「なぜ今このメソッドか」の章で見た、自信のある口調や自動で出てきたものを疑わなくなるバイアスです）。けれども実際には、別の成果物に、別の言葉で書かれていることがあります。どこを、どんな言葉で探したかが添えてあれば、人が確かめ直せます。

同じ根本原因が複数箇所に現れているなら、対象箇所を列挙する形で1つの指摘にまとめます。逆に1つの指摘文に独立した論点が混在しているなら分割します。

レンズは、育てて使う

この章のレンズと歯止めは、ベースラインです。回した結果を見て、プロジェクトや組織で育ててください（育て方は14章）。プロジェクトの業界や業務に固有の見るものを足すこともできます。

第10章確かめる ── ADR適合検査

【確かめる】とは、何をする検査か

決めたことが、その後も成果物で守られているかを確かめます。ADRの制約節と成果物を突き合わせ、決定に合っているかだけを見る、検算です。

いつ回すか

【確かめる】は、何かが変わったときに回します。きっかけは3つです。

• 決定が増えたとき。新しいADRが生まれたら、先に書かれた成果物がその決定と食い違っていないかを見ます。上流で全部決まるとは考えないので、決定が成果物より後に来るのは普通のことです。
• 変更要求が来たとき。変更後の成果物群が、既存の決定を守れているかを見ます。変更の影響を調べるときにも、この検査を使います。
• 成果物が書かれた・直されたとき。決定より後に書かれた成果物も、その決定を守れているかを見ます。

具体的に回す細かさは、プロジェクトの規模などに合わせて調整してください。工程の区切りなどの節目には、回しておくのがよいでしょう。

何を確かめるか

【確かめる】が見つけるのは、次の3つです。

• 成果物の記載が、決定と食い違っている。食い違っている記載をそのまま引いて指摘します。理由のない指摘は、人が確かめ直せないからです。
• 合っているか食い違っているか、判断できない。どちらかに決めつけず、判断できないとして人に返します。無理に決めさせると、AIが判断を代わってしまうからです。
• 書かれているべきことが、どこにも書かれていない。その範囲の成果物をまとめて見て、どこにもなければ指摘します。成果物がまだ1本もない場合も、同じように指摘します。1件ずつ見ると、どの成果物も「自分には関係ない」と答えて、書かれていないことが見えないからです。食い違いは成果物を1件ずつ見ますが、書かれているかどうかは、このようにまとめて見ます。

ADRの制約節には、その決定が影響する成果物（影響範囲）が書かれています。そのため、成果物ごとに、影響するADRの制約だけを当てれば済み、全部のADRと全部の成果物を突き合わせる必要はありません。指摘は、制約節の1行ごとに出します。1本のADRに制約が3行あれば、3行それぞれについて見ます。

ADRの側に不備があるとき（制約節に影響範囲が書き漏れているなど）は、検査の側で補わず、ADRを直します。指摘を受けた後は、成果物を直すなら反映型ISSUEに、決定を見直すなら置き換えに載せます。成果物が業務の実態に合っているかどうかは、この検査の外で、発注者が読んで確かめます。入力と出力の実際の形は、付録の通し例にあります。

見落としに、どう備えるか

AIの検査で、すべての食い違いが見つかるとは限りません。指摘が出なかったことは、検査した範囲で食い違いが見つからなかったというだけで、見落としは残ります。見落としを運用で補う選択肢を挙げます。プロジェクトの規模や、成果物の重さに合わせて組み合わせてください。

• 抜き取りの人手確認：検査済みの箇所から抜き取って、人が見直す。
• 実行条件の固定：同じ入力・同じ条件で同じ結果が出るようにし、揺れを見えるようにする。
• 複数回実行の突き合わせ：揺れの差分から、不安定な判定を洗い出す。
• 検出実績の記録：何を見落としたかを残し、制約節の書き方やレンズへ返す。
• 節目の総ざらい：工程の区切りに、取りこぼしを拾う側に寄せた設定で全体を一度見る。

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

変更要求が来たら

発注者から「送料無料の対象を、一部の商品に絞りたい」と言われたとします。すぐに成果物を開いて直したくなりますが、まだ直しません。変更要求も、ほかの論点と同じように【深める】で議論し、決めてから成果物に入れます。順番は次のとおりです。

1. 変更要求を、未決型ISSUEとして受ける。
2. 影響を調べる。
3. 決めて、ADRに残す。
4. 成果物に入れる（反映型ISSUE）。

直す前に決めるのは、変更がどこまで響くかを見てからでないと、変えるかどうかを決められないからです。変更の決定は業務に触れることが多いので、決めるのは発注者側の人になることが多いでしょう。

変更は、外から来るとは限りません。工程の途中で決めたことが、前に書いた成果物に及ぶこともあります。そのときも、同じ順番で回します。

影響を調べる

まず、変更がどこに響くかを調べます。使う道具は、これまでに出てきたものです。

影響を見るために、変更後の姿を試しに書いてみてもかまいません。これが分析用の試作です。試作に【広げる】でシナリオを歩かせると、既存の成果物のどこに触るのかが見えてきます。ただし、試作は成果物本体と分けておきます。本体に紛れ込むと、まだ決まっていないことが、決まったこととして読まれてしまいます。

こうして出てくるのは、影響の候補です。本当に影響があるかどうかは、人が1件ずつ決めます。影響を調べる範囲は広いので、候補もたくさん出ます。

影響が1本の業務フローに収まらず、もっと広い範囲へ及ぶこともあります。そのときは、その論点を上の単位の【深める】へ持ち込んで決めます。そこから先は、単位を広げるときの受け渡し（育て方サイクル総論で見たもの）と同じです。

決めて、ADRに残す

決まったら、ADRに残します。元のADRとの関係で、書き方が2通りあります。

• 元の決定を覆すとき：新しいADRを起票し、元のADRを置き換えます。
• 元の決定は生かしたまま、条件を足すとき：たとえば「送料無料の閾値は業務部門が切り替える」はそのままで、「対象商品を絞れる」を足す場合です。元のADRに追記せず、新しいADRを並べて起票します。新しいADRの「前提とする決定」に元のADRを書いておけば、2本の関係が辿れます。

元のADRに追記する形を認めると、いま有効な決定を知るのに、元の部分と追記した部分を読み合わせることになります。1つの決定は、1本のADRで読めるようにしておきます。

前提が変わったとき

決定の中身はどれも正しいのに、共通の前提が変わったせいで、何本ものADRが一度に古くなることがあります。たとえば「送料は注文単位で計算する」を前提にしたADRが何本もあるところへ、送料を明細単位で計算することになった場合です。

こういうときも、まとめて置き換える書き方は作りません。それを許すと、1つの決定を1本のADRで読むという単位が崩れ、置き換えの意味が2つになるからです。代わりに、前提そのものをADRにしておきます。

どのADRがどの前提に立っているかは、属性の「前提とする決定」に書きます。リンクの種類を新しく増やすわけではありません。前提のADRが置き換わると、それを前提にしていたADRは、成果物との整合の照合でAIなどが拾います。どれを置き換え、どれをそのまま残すかは、1件ずつ人が決めます。前提が変わっても正しいままの決定があるからです。

成果物に入れる

ADRができても、成果物はまだ古いままです。反映する作業を、反映型ISSUEに積みます。

決定がADRに残っていても、反映の作業を追っていなければ、決定は成果物に届きません。先行事例には、ADRに書いてあった負荷の問題が忘れられ、リリースの9か月後に障害として表に出た例があります。

いつ反映するか

反映は、決定の後ならいつでも構いません。節目でまとめて反映し、前の版は書き換えずに次の版で作り直すやり方もあります。

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

この章が扱うこと

本書が扱うのは要件定義と外部設計なので、この章が対象にするのは、それぞれに対応する総合テストと結合テストです。単体テストは、実装の側の話です。

この章が示すのは考え方までで、運用の手順（マトリクスの作り方、DDPの集計の実務、帳票の様式、合否の閾値）には踏み込みません。テストの運用は、契約の形・体制・道具・発注者の検収の求めによって、プロジェクトごとに大きく違うからです。

テストの網羅を、どう示すか

テストの段になると、網羅をどう示すかを問われます。

行に観点（何を確かめるべきか）、列にシナリオ（どういう筋書きで動かすか）を置き、そのシナリオでその観点を確かめるなら、交点に印を付けます。送料無料の閾値の例なら、総合テストでは次のようになります。

すべての交点を○で埋める必要はありません。そのシナリオで確かめなくてよい観点もあるからです。見るのは、観点ごとに、確かめるべきシナリオで確かめられているかです。その判断は、人がしっかり行います。

マトリクスが示せるのは、並べた観点とシナリオの中での網羅だけです。観点やシナリオそのものが抜けていれば、表はきれいに埋まっていても、その抜けは表からは見つかりません。だから、試験観点と試験シナリオは、人がしっかり考えます。

この業務で何を確かめないと困るのか（送料無料なら、閾値のちょうど境目の受注や、キャンペーンが切り替わる瞬間の受注）を挙げるには、業務の意図を知っている人の知識が欠かせません。

試験シナリオの種は、要件定義で整理した業務イベントと例外、そして【広げる】で歩かせたシナリオの2つです。表の S3・S4 は、【広げる】のシナリオから採ったものです。シミュレーションのシナリオはテストで使える形に近いものですが、どれを試験シナリオとして採るかは、人が決めます。

一方、次の節で見る試験手順は、AIに大いに任せて構いません。観点とシナリオは人が考える比重を重く、手順はAIに頼る、という分け方です。

AIに試験手順を書かせる

試験手順の作成は、AIに担わせます。もとになるのは、要件定義や外部設計の成果物です。タスクごとに、始めてよい状態と終わったときに成り立っている状態が書かれ、例外が整理されていれば、そこから手順が素直に導けます。

これには、副次的な効き目もあります。AIが手順を書きあぐねる箇所は、仕様に穴がある箇所です。「確認する」「正しく表示される」としか書けないなら、事後条件が決まっていません。もっともらしいが確かめようのない手順が出てきたときも、同じです。【広げる】の検証可能性のレンズで上流で見たことが、ここで答え合わせされます。

手順が書けたことは、仕様が確かめられる形をしていたことを示すだけで、その仕様が業務として正しいかどうかは示しません。

品質を、何で追うか——DDP

テストの品質は、DDP（Defect Detection Percentage：欠陥検出率）で追います。DDPは、ある工程で見つけるべきバグを、その工程でどれだけ見つけられたかの割合です。

たとえば、結合テストで40件のバグを見つけ、そのあと総合テスト以降で、結合テストで見つけるべきだったバグが10件見つかったとします。結合テストは、見つけるべき50件のうち40件を見つけたので、DDPは80%です。工程ごとに、この値の推移を追います。

DDPを使う狙いは、バグ密度・テスト密度のような、コードの規模で割る指標から降りることにあります。AIがコードを書く時代に、コード行数あたりのバグ件数やテスト件数で品質を語るのは無理があります。同じ機能が半分の行数で書かれれば密度は倍になりますが、品質は何も変わっていません。

AI-Native開発では、DDPを読み違えやすい

AI-Native開発では、テストに持ち込まれるバグの数そのものが減ります。AIにコードを書かせると、書き間違いや書き漏らしのような単純なバグが少なくなるからです。上流の仕様を育てていれば、仕様の穴から来るバグも減ります。そのぶん、DDPには次の2つの読み違えが起きやすくなります。

①バグが減ると、DDPは見かけ上、悪くなります。難しいバグほど見つけにくく、すり抜けやすい。単純なバグが先に消えると、テストに残るのは難しいバグの割合が高くなり、各工程で見つけられる割合が下がるからです。

案件Bは、バグの総数も（25件と100件）、すり抜けた数も（5件と10件）、案件Aより少ないのに、DDPだけを見ると案件Aより悪く見えます。数字を機械的に読むと、AI-Native開発に切り替えたプロジェクトほど「品質が下がった」と誤読されます。

②バグが少ないほど、1件で大きく振れます。DDPは割合なので、母数が小さいほど不安定です。見つけるべきバグが100件ある工程では、1件の見逃しは1ポイントしか動きませんが、10件しかない工程では10ポイント動きます。バグが減るほど母数は小さくなるので、この不安定さは避けられません。この手法を提案した側の適用事例でも、バグが少ない案件では参考程度の活用にとどめたと報告されています。

①と②は、同じ方向を向いています。バグが減るほど、DDPは読みにくくなります。

何がすり抜けたのか、なぜ捕まえられなかったのか、それは工程の設計の問題か観点の問題かを、1件ずつ見ます。DDPは傾向を読むための物差しで、閾値で合否を出すための装置ではありません。

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

実装する側から見る

Trusted Spec は、最後にAIが実装に使えなければ意味がありません。では、AIが実装に使える仕様とは、どういうものか。上流の側から考えるより、仕様を受け取って実装する側を見るほうが確かです。

AIに実装させるとき、AIは仕様だけを読んで書いているわけではありません。コーディングの規約、作業の手順、APIの型定義、生成に使う道具。こうしたものをまとめて与え、それを参照しながら書かせます。この、実装するAIが参照するひとそろいを、ここでは実装のコンテキストと呼びます。

実装のコンテキストの中身は、SEが詳細まで知っている必要はありません。ただ、その仕組みを知っておくことは大切です。実装するAIが何を頼りに書き、仕様が何も言っていないときに何で埋めるのかが分かると、上流で何を書いておくべきかが見えてくるからです。

この章では、intra-mart Accel Platform でAIにスクリプト（JSSP）を書かせるための、実装のコンテキストを例にします。1つの例なので、どこにでも当てはまるとは限りませんが、机の上で考えた要求よりは確かです。

実装する側が守っていること

この実装のコンテキストは、AIに次のようなことを守らせています。

• 書いたコードは、必ず検証にかける。ページの検証はエラーが0になるまで直し、コードレビューとセキュリティチェックも、スキルがあれば必ず実行します。作業が多い、時間がかかる、といった理由で省くことは認められていません。
• APIは、記憶や推測で使わない。APIの型定義ファイル（d.ts）で、引数や戻り値を確かめてから書きます。
• 作る順番を守る。テーブルの定義とSQLを先に作り、画面・API・バッチ・ワークフローはその後に並行して作り、最後に設定と検証をします。前で作ったもの（テーブル名、SQLのファイルの場所など）は、後ろの作業へ明示的に渡します。

目を留めたいのは2つ目です。推測で書かず、根拠を確かめてから書く。これが決まりとして書かれているだけでなく、コードレビューの観点にも「d.tsで定義されたとおりにAPIを呼んでいるか（推測で使っていないか）」という項目があります。決まりを書くだけでなく、守られているかを確かめる仕組みまで用意されています。

本書にも、この決まりの上流版があります。【たたく】の章で見た、「制約を記憶や推測で使わない」です。成果物を書く人は、自分の成果物に影響するADRと上流の成果物を読んでから書きます。実装するAIが仕様を推測で使わずに済むのは、読みにいける仕様があるときだけです。

仕様に書いていないことは、規約で埋まる

実装のコンテキストには、コーディングの規約がたくさん入っています。そして、仕様と規約のどちらを優先するかが、次のように決められています。

これは、実装する側から見た、仕様の重みの宣言です。裏を返すと、仕様に書いていないことは、規約の既定で埋まるということです。画面の入力欄の文字数の上限、エラーコードの付け方、アクセシビリティの厳しさ。規約はよくできた既定ですが、業務の意図は知りません。既定で埋まった結果は技術的には正しく、レビューでも指摘されにくいものです。最初の章で見た、送料無料の閾値と同じ形です。

規約をいくら厚くしても、業務の意図は埋まりません。業務の意図は、仕様で決めるしかありません。

上流の仕様に求められること

ここまでを、上流の仕様への要求としてまとめます。

• ①IDで遡れる：実装するAIが、「この処理の根拠はどの要求か」を辿れます。その要求に影響する決定も、ADRの制約節の影響範囲から引けます。
• ②参照で解決できる：とくに、権限・状態の移り変わり・業務ルールです。ADRの制約節が、その出どころになります。実装は本書の工程の外にあるので、実装のコンテキストには、成果物と一緒にADRも渡せます。ADRを渡すときに、仮決定か承認済みかを添えておけば、実装するAIは、決定がどこまで固まっているかを知った上で使えます。
• ③未決が分かる：成果物の未決の印から、決まっていない箇所を機械的に見分けられます。人の注意力に頼らず、書き方で分かるようにしておきます。

上流の仕様は、どう実装に渡るか

上流の仕様が実装に渡るには、大きく2つのパターンがあります。

• 外部設計書を作ってから渡す。要件定義、外部設計と書き上げ、その外部設計書を実装のコンテキストに読ませて実装します。
• 実装のコンテキストの中で、対話しながら決める。要件定義のあとは、実装のコンテキストの中でAIと対話し、画面や項目などを決めながら、そのまま実装します。

本書は、前者の、外部設計書を作ってから渡すスタイルを取っています。SIでは、外部設計書が発注者の承認や検収の対象になることが多いからです。ただし、どちらのパターンでも構いません。後者で進めるなら、対話の中で決めたことも、決定として残してください。たとえば対話で「在庫がないときは、受注を予約受付にする」と決めたなら、それは業務ルールに関する決定なので、ADRに残します。決まらなかったことは、未決型ISSUEに残します。そうしないと、決まっている・根拠がある・辿れる、の3つが、実装の手前で切れてしまいます。

大規模SIでは、外部設計書だけでは、AIが実装するのに足りません。外部設計にどこまで書くかはプロジェクトによって幅があり、実装に要る細部（処理の手順、データの細かな扱い、例外の細部）までは書かれないのが普通だからです。そこで、外部設計書をもとに、実装のコンテキストを使ってAIに実装用の仕様書を書かせ、それに従って実装させます。

このとき、外部設計書と一緒に渡したいものがあります。項目や指標の意味です。

構造だけでなく、意味も渡す

上流から実装へ渡すとき、構造は渡せても、意味が渡せていないことがあります。ER図やテーブル定義は、どんな項目があり、何と何がつながるかは書きますが、「この項目は業務上どういう意味か」「この数値はどう計算するか」「どの細かさで集計するか」までは書きません。画面の項目定義も、項目の名前と型は書いても、その値が業務で何を指すかは書かないことが多いものです。人は文脈で補えますが、AIは補えず、推測で埋めてしまいます。

そこで、こうした成果物に加えて、項目や指標の意味を、人にもAIにも読める形（JSON・YAML など）で書いておき、外部設計書と一緒に実装のコンテキストに渡します。効くのは実装だけではありません。

• 実装：実装用の仕様書を書くAIも、実装するAIも、項目の意味を推測せずに参照できる。
• テスト：項目が取りうる値と意味が書いてあれば、境界の値や異常な値の試験観点を立てやすい。
• データ分析：運用が始まってからの集計で、同じ指標が部署ごとに違う定義で計算されるのを防げる。

ここまでをまとめると、上流の仕様は、次の流れで実装に渡ります。

2つの条件は、どう満たされるか

最初の章で、SI文書は ①業務部門が承認できる ②AIが実装できる、の2つを同時に満たす必要があると述べました。Trusted Spec の3条件は、この両方に効きます。「決まっている」「根拠がある」は、業務部門が承認する（検収する）ことを支え、「辿れる」は、AIが実装することを支えます。

業務の言葉で承認された決定が、理由と一緒に、実装まで流れていく。これが、本メソッドの目指すところです。

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

どこから始めるか

導入は、小さく始めます。まず業務フローを1本選び、【たたく】【深める】【広げる】【確かめる】を1周回してみてください。ADRの書き方、検査の掛け方、未決の残し方の勘所は、この1周でつかめます。そこから、関連する業務のまとまりへ、さらにシステム全体へと、視野を広げていきます。サイクルは、小さく回すほど早く学べます。

始めたばかりのころは、成果物どうしの参照がまだ揃っていません。それでも、シミュレーションは回せます。シナリオを歩かせるのに、参照は要らないからです。最初の1周は、シミュレーションから始めてもかまいません。

レンズと観点を、どう鍛えるか

【広げる】のレンズと観点も、回しながら育てます。何を拾えて、何を見落としたかを、定義に戻していきます。

実物があります。改訂した観点の定義の末尾に、前の版で起きた失敗と、それへの手当てが表で残っています。

注目したいのは、表に載らなかったものです。前の版で見つかった問題のうち、想像の混入、引用の精度、判断できないときの扱いは、観点の定義で直すものではないとして、検査の手順と、出力前のセルフレビューの側へ回されました。失敗を数えるだけでなく、それをどこで直すかを振り分ける。観点を鍛えるとは、そういうことです。

【確かめる】には、鍛える観点がありません。検算の問いは、ADRの制約節に書かれているからです。【確かめる】で鍛えるのは、制約節の書き方のほうです。

決定を、環境へ育てる

プロジェクトのルールや執筆ガイド、検査の観点は、いろいろなところから生まれます。組織の標準から持ち込むものもあれば、検査を回した結果や、起きた事故の振り返りから生まれるものもあります。

そのうち、ADRに残した決定から育てる道筋を、本書では発展と呼びます。同じような決定が繰り返されるなら、1件ずつADRに書いて検査し続けるより、一般化してプロジェクトの環境に組み込んだほうが、守りやすくなります。

発展とは

発展しても、ADRは消えません。状態が発展済みになり、そこから育ったルールや観点が、プロジェクトに根づきます。以後、そのルールで足りる決定は、ADRに書かなくて済みます。

ADRに残す決定の多くは、業務ルールに関する決定です。業務ルールの決定は、繰り返され方によって、育つ先が変わります。

実装で機械的に守れるものは、実行可能なテストにも育てられます。業務ルール以外の決定（成果物の書き方など）は、プロジェクトのルールや執筆ガイドへ育てます。どう守らせるかは、開始時に決めておきます。

「横断」のADRが増えてきたときも、発展の候補です。発展させるかどうかは、人が決めます。

発展させるときに守ること

ルールや観点として書いただけでは、発展したことになりません。書いただけで守られる仕組みに入っていないと、1件ずつの検査からは外れるのに、守らせるものがない状態になるからです。

発展したルールや観点は、書き換えられる文書です。決定がそこに取り込まれたあと、編集で中身が少しずつずれても、元のADRは何も言いません。だから、改めるときはADRを起票します。

また、発展させるかを判断する人は、発展させるほど自分の検査の手間が減る立場にいます。だから、判断する人の裁量に任せず、守られる仕組みに入ったかどうかで決めます。

プロジェクトハーネス

こうしてプロジェクトに整っていく環境（ルール、執筆ガイド、検査の観点、索引、それらを実行する道具）を、発展で育ったものも、それ以外から生まれたものも含めて、本書ではプロジェクトハーネスと呼びます。プロジェクトハーネスが厚くなるほど、誰が書いても一定の品質になります。育てるのは、仕様とプロジェクトハーネスの両方です。

業界でハーネスと言うときは、モデルを取り巻く実行の仕組み（使ってよいツール、hook、読ませる文脈のファイルなど）を指します（付録_出典）。プロジェクトハーネスは、それより広く、検査と執筆の環境の全体を指します。

プロジェクトハーネスの中身には、2つの種類があります。

• 強制するもの：参照の照合、【確かめる】の検算、実行の条件の固定。通らなければ、先へ進めません。
• 助言するもの：執筆ガイド、レンズ、検査の観点。読まれなければ、効きません。

業界でも、この2つをはっきり分けておくことが大事だと言われています。

1つの決定が、共通のルールになるまで

ADRの台帳の章で見た例で、発展の一巡をたどってみます。

受注の業務で、「マスタを改定しても、確定済みの伝票は改定前の値のまま表示する」と決め、ADRに残しました。しばらくして、請求の業務でも同じ問題が出ました。請求書を出したあとに単価マスタが変わったら、請求書の金額はどう見えるべきか。決めてみると、答えは受注と同じでした。発注でも出荷でも、同じ議論が起きそうです。

業務ごとにADRを書き続けることもできます。けれども、それでは同じ判断を業務の数だけ繰り返すことになり、どこかで書き忘れれば、その業務だけ違う動きになります。そこで、この決定を「伝票を持つ業務では、確定済みの伝票は、確定したときのマスタの値で表示する」という、プロジェクト共通の業務ルールにまとめました。

まとめただけでは、守られるとは限りません。そこで、【広げる】の観点に「伝票を持つ業務で、マスタの改定が確定済みの伝票に及ばないか」を足し、新しい業務の成果物を書くたびに確かめられるようにしました。ここまで来て、発展が成り立ちます。元のADRは発展済みになり、以後、伝票を持つ業務では、この点を1件ずつADRに書かなくて済みます。

1つの決定が繰り返され、共通のルールにまとまり、守られる仕組みに入る。これが発展の一巡です。

発展を、誰が回し続けるか

発展したルールや観点は、放っておくと古くなります。維持する責任者の置き方には、たとえば次の3つがあります。

メソッド自身は、どう育つか

ここまでは、1つのプロジェクトの中で決定が育つ話でした。発展には、その先にもう一段あります。

上の段へ渡すのは、下の段の発展の記録です。複数のプロジェクトで同じルールが発展していたら、それは組織の標準にする候補です。前の節の共通の業務ルールも、ほかのプロジェクトで同じように育っていれば、組織の標準にする候補になります。本書は、この上の段の受け皿です。

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

ADR運用の重さは、上流の品質を保ち続ける重さ

ADRの運用は、重いものです。決めるたびに書き、書いたものを引き、突き合わせ、揃え続けなければなりません。では、この重さは何のための重さなのでしょうか。

SIでは、上流の品質が、後の工程を左右するとよく言われます。上流で決めたことが抜けていたり、決めた理由が分からなくなっていたりすると、後の工程で調べ直しや手戻りが起きます。ADRは、上流で決めたことを、決めた理由と一緒に、辿れる形で残すための手段の一つです。

だから、ADR運用の重さは、上流で決めたことを、決まった状態のまま保ち続ける重さだと言えます。この重さは、プロジェクトのあいだずっとかかります。けれども、後の工程で起きる手戻りは、直すのに使える時間が短いことがほとんどです。ADR運用の重さは、その手戻りそのものを減らすための重さです。

そして、この重さの多くは、AIに寄せられます。人に残るのは、判断の重さです。

AIに寄せられる重さ

量の重さは、AIに寄せられます。影響範囲でADRを引いて成果物と突き合わせる、新しいADRができたら前に書いた成果物へ遡って検算する、採番・形式・つながり・索引を揃える（台帳係の仕事）、発展の候補を洗い出す、といった作業です。

この量は、ADRと成果物が増えるほど、掛け算で増えます。1つの成果物が引くADRの数は影響範囲で限られますが、1つのADRが突き合わせる成果物の数には、上限がありません。「横断」のADRなら、すべての成果物が相手です。それでも、この重さはAIの利用コストとして払えます。その分、人は、決めることと判断することに時間を使えます。

気をつけたいのは、2つです。

• 渡す材料を、作業に要る分に絞る。AIは、材料が膨らむと精度が落ちます。成果物を書かせるだけなら、当たるADRの制約で足ります。決めた理由まで要る作業なら、そのADRの全文を渡します。
• AIが拾える形で書いておく。ADRのID、影響範囲の名前、未決の印が揃っていないと、AIは引くことも突き合わせることもできません。

人に残る重さ

判断の重さは、人に残ります。何を決めてADRにするか。AIが返してきた指摘を、直すか、持ち越すか、採らないか。発展させるか。いつADRを置き換えるか。そして、決めたことを発注者と読み合わせることです。

軽くしたいのは、この重さです。いま分かっている工夫は、次の3つです。

• 迷ったら書く。書きすぎたADRは、AIが影響範囲で引く量が限られるので困りません。書かなかった決定は、台帳に跡が残らず、どの検査でも見つけられません。
• その場では、何を決めたか、なぜか、制約だけを書く。似たADRがあるか、発展の候補になるかは、棚卸しでまとめて見ます。
• 発展させたら、守られていることを確かめる仕組みに入れる。執筆ガイドに書いただけでは、1件ずつの検査からは外れるのに、守らせるものがありません。食い違いが見つからなくなっただけで、重さが減ったように見えます。これがいちばん悪い形です。

ADRを残すことの裏返し

ADRに書いた決定を、AIは守ろうとします。これは狙いどおりです。決めたことを、AIが勝手に変えなくなります。

ただ、裏返しもあります。あとで、もっとよい方針のアイデアが出ても、AIはADRに書かれた今の方針で進めます。ADRが効いているほど、方針は動きにくくなります。どちらかだけを取ることはできない、トレードオフです。

方針を変えたいときは、ADRを置き換えます。その場でAIに別の方針を伝えても、ADRが残っている限り、AIはそちらへ引き戻されます。AIがADRを理由に提案を退けたときは、その決定を見直す時期かどうかを、人が考える合図にもなります。

まだ解けていないこと

正直に言うと、本書は、ADR運用の重さについて、次のことをまだ解けていません。

実践するプロジェクトが増え、AIが進化していけば、これらは解けていくはずです。

付録全体図 ── 4ステップ・記録・2つの検査

本書の機構は、章を追って一つずつ積み上げてあります。積み上がったものを一度に見ると、どこに何が付いているかが分かりやすくなります。ここに2枚置きます。

• 全体：4ステップのサイクルと、2つの検査がどこに掛かるか。
• 記録の流れ：ADRとISSUEがどう生まれて終わるか、制約節と索引がどこで効くか。

どちらも本文の索引です。図に収まるのは骨格だけで、歯止めや但し書きは本文の側にあります。

全体 ── 4ステップと、2つの検査

読み方

• 同じ手順を、要件定義でも外部設計でも回します。START と GOAL が入れ替わるだけで、4ステップは変わりません。変わるのは【広げる】のレンズだけです（外部設計では、機能成立性／トランザクション境界／機能例外に置き換わります）。
• 1周では終わりません。サイクルは小さい単位から回し始め、小さく回したものを、より広い単位で見直していきます。矢印が縦一列に見えますが、実際には同じ列を何周もします。単位を広げても、決めたことを引き継ぐ作業は増えません。決めたことはADRに残っているので、広い単位で書く人は、自分の成果物に当たるADRを引けば足ります（3章）。
• 2つの検査は、掛かる場所も、回るきっかけも違います。【広げる】は時間で回ります（節目の巡回）。【確かめる】はきっかけで回ります（決定が増えたとき・変更が来たとき・成果物が書かれた・直されたとき）。2つをひとまとめに「レビュー」と呼ばず、はっきり分けて扱います。
• 立ち止まる機会にあたるのは、【広げる】と【確かめる】の2つです。
• 変更要求は、【たたく】ではなく【深める】から入ります。決定が先、反映は後です。影響分析のときは、この図の検査を道具として呼び出します。新しい検査は作りません。
• どの検査も、AIが出すのは気づきと指摘までです。合否は判定しません。採るかどうか、どこに記録するかは人が決めます。

記録の流れ ── ADR・ISSUEと、制約節・索引

読み方

• 決めたことはADRに、決めるべき論点と反映する作業はISSUEに残します。ADRは変更不可、ISSUEは可変です。未決も、変更要求も、反映漏れも、すべてこの2つで受けます。
• ISSUEはADRの前後を繋ぎます。未決型ISSUE →（決定）→ ADR →（反映）→ 反映型ISSUE。左は「決めるべきこと」の一覧、右は「やるべきこと」の一覧であり、混ぜません。
• 制約節が、検査の相手を絞ります。膨大なADRと膨大な成果物を総当たりしないための、中心になる仕掛けです。だから、制約節が空のADRは、記録としては残っても検査には使えません。【確かめる】の精度の上限も、検査側ではなく制約節の書き方で決まります。
• 書き手が引くのは、自分の成果物が含まれる影響範囲と「横断」のADRだけです。どの影響範囲に含まれるかは、成果物どうしの辿りで決まります。ADRが増えたら、「影響範囲 → 当たるADR」の索引を機械で作ってもかまいません（プラクティス）。
• ADR-IDの注記は、付けるところを絞ってかまいません。未決の印は漏らせません。

付録サイクルを1本通す ── 「変更可能とする」の一文が育つまで

仕様書に書かれた一文が、【たたく】→【深める】→【広げる】→【確かめる】の4ステップを1周すると何が起きるのか。それを、1件の記述で最後まで追います。

題材は、「なぜ今このメソッドか」の章で挙げた失敗です。

仕様書に「送料無料の閾値は、変更可能とする」とだけ書かれていた。AIは「変更可能」を素直に解釈し、定数ファイルに値を切り出した。技術的には正しい。しかし発注側が考えていたのは別のことだった——キャンペーンによって送料を無料にするケースがある。期間を区切って閾値を下げる、対象商品を絞って無料にする。それを業務部門が自分で切り替えたい。管理画面も、誰が切り替えてよいかの権限も、いつ・誰が・何を変えたかの履歴も要る。食い違いが発覚したのは本番2週間前だった。

以下はすべて架空の例です。例の決定が生まれる業務（発生箇所）は「販売業務」、成果物の名前は一般的なものを使います。

【たたく】── 叩き台に、その一文が書かれた

叩き台は、AIに執筆をサポートさせて書き、人が直します。書かれた要求事項はこうです。

送料無料の閾値は、変更可能とする。

要求事項を書き終えたら、書き手が自分で見直します。身だしなみ（体裁・命名・記載漏れ）を整え、IDと参照が張れているかを確かめます。

この見直しでは、この一文に問題は見つかりません。表記は揺れておらず、IDも振られ、記載欄も埋まっています。「変更可能とする」があいまいだと気づくには、誰が変えるのか（主体の一覧）や、何のために変えるのか（業務ルール）と比べる必要があります。どちらも、この要求事項の外にあります。1つの文書を見直すだけでは、複数の成果物にまたがる抜けは見えないので、【たたく】では拾えません。

ひとつだけ、ここで効きうる手立てがあります。AIに叩き台を書かせるとき、最初に「根拠が見当たらなかった箇所を挙げよ」と指示を立てておきます。AIは根拠のない箇所も黙って埋めるので、埋めたところを埋めたと言わせるのです。「変更可能とする」がそこに挙がれば、この一文は次のステップの議題になります。ただし、挙がる保証はありません。この段階で頼りになるのは、検査ではなく、次のステップで人が理由を書こうとすることのほうです。

【深める】── 議論で、何が決まり、何が決まらないか

議論のしかたは、これまでのままでかまいません。本メソッドが足すのは、議論の出口を記録として残すことだけです。出口は2つしかありません。決まったか、決まらなかったかです。

AIに議論をサポートさせてできるのは、論点の候補を並べ、同じことを指している論点をまとめ、決まっていない箇所を指し示すところまでです。どれを論点に立てるか、どう決めるかは人が決めます。業務の判断は発注者側の責任者が負います。この一文からは、3つの論点が立ちます。

1. 誰が変えるのか。 開発側か、業務部門か。
2. 何のために変えるのか。 恒久的な料金条件の見直しか、期間を区切った売り方か。
3. 何をもって「変更可能になった」と言えるのか。 定数を外に出せば済むのか、業務部門が自分で切り替えられて初めてそう言えるのか。

議論の結果、決まったことと決まらなかったことに割れます。

決まったこと：閾値の変更はキャンペーンの実施手段であり、業務部門が自分で切り替える。開発側のリリースを伴う形にはしない。変更の履歴は残す。

決まらなかったこと：誰に変更を許すか（役割の細かさ）。期間を指定して予約できる必要があるか、即時切り替えでよいか。対象商品を絞る要否。

決まったことは、ADRへ

決定は、なぜそう決めたか（WHY）と、判断した人の証跡とともに記録します。ADRの記述形式は、本書が一案として推奨する形で書きます。Nygard 形式に「この決定から生じる制約」節を足したもので、ADRの扱いの章で見たものです。制約節は「影響範囲 × 満たすべき状態」の2項で書き、決定を受け止める成果物に着地させます。ここが、後で検算の問いそのものになります。

順序は議論 → 決定 → 記録です。記録するのは決定が下された後であって、記録しながら決めるのではありません。

# ADR-0231：送料無料の閾値は、業務部門が自分で切り替える

## ステータス
- 状態：仮決定
- 発生工程：要件定義
- 確定者：発注者側の販売業務責任者
- 発生箇所：販売業務
- 置換：なし
- 前提とする決定：なし

## 背景
閾値の変更は、恒久的な料金改定ではなく、期間を区切ったキャンペーンの
実施手段である。売り方を決めるのは業務部門であり、実施の判断から
反映までの間に開発側の作業が挟まると、打ちたいときに打てない。
履歴を残すのは、過去の受注がどの条件で成立したかを後から説明する
必要があるためである。

## 決定
送料無料の閾値は、業務部門が自分で切り替えられる形で提供する。
開発側のリリースを伴う変更手段は採らない。変更の履歴を残す。

## 結果
### 良い結果
キャンペーンの実施が、開発側の作業計画から切り離される。
### トレードオフ（悪い結果）
変更の手段・権限・履歴の分だけ、作るものが増える。

### この決定から生じる制約（後続成果物が満たすべき状態）
- 販売業務の要求事項：閾値は業務部門が変更し、変更に開発側のリリースを
  必要としないことが記述されている。
- 販売業務の要求事項：閾値の変更履歴（変更日時・変更者・変更前後の値）を
  保持することが記述されている。
- 販売業務の業務の定義：閾値の変更が、開発側のリリースを伴う作業として
  記述されていない。
- 販売業務のユースケース：業務部門の担当者が閾値を変更する手順（システムの
  ふるまいを含む）が記述されている。

制約節の各行は「〜が記述されている」「〜として記述されていない」という、成果物が満たしている状態の形で書いてあります。満たしているかどうかを、人もAIも判断できる形です。影響範囲は、この決定を受け止める成果物（要求事項・業務の定義・ユースケース）であり、できるだけ名指しで書いてあります。権限や業務イベントへの反映は、要求事項から成果物どうしの辿りで広がり、【広げる】がそれを見ます。影響範囲は成果物の種別と業務のまとまりの名前で書いており、成果物のID（UC-0012 など）では書いていません。だから、起票後に生まれる成果物も、生まれた瞬間に同じ制約の下に入ります。

名指しているのは、いずれもこの決定が生まれた工程（要件定義）の成果物です。外部設計はこの要件定義の成果物を読んで書くので、この決定は成果物に乗って次の工程へ届きます。

決まらなかったことは、未決型ISSUEへ

決まらなかった3つは、未決型ISSUEとして台帳に残します。未決の明示は敗北ではありません。未決と書かれた箇所を、AIは勝手に補完できないからです。

• 閾値を変更してよい主体の細かさ（対象成果物：権限と情報取扱いルール）
• 期間を指定した予約切り替えの要否（対象成果物：要求事項）
• 対象商品を絞る要否（対象成果物：要求事項）

そして、成果物の側にも、未決であることとISSUEのIDを書きます。台帳に書いただけでは足りません。成果物を読む側、とりわけ実装するAIは台帳を見ないので、成果物に書かれていない空白は「埋めてよい空白」に見えるからです。

制約節が「業務部門が変更する」と言い、どの役割まで許すかが未決になっているのは矛盾ではありません。書き方は決まっており、中身が決まっていないのです。

決まったことは、この時点ではまだ成果物に入っていない

決定が下されたことと、成果物がそれに合わせて書き直されていることは、別です。反映は反映型ISSUEの作業として行われ、この例では節目でまとめて行います。

【広げる】── シナリオを歩かせると、何が立つか

【広げる】は、俯瞰して「足りているか」を見る低頻度の巡回です。やることはシミュレーションです。AIが業務シナリオを創作し、成果物群に照らして時系列に歩かせ、空白を4つのレンズ（業務との整合／境界・責任範囲／検証可能性／正常系偏重）で見ます。

シナリオの種は、「長さと期限の衝突」（想定より長引いたら／先に期限が来たら）と「人・役割の入れ替わり」（担当者が替わったとき、その人に紐づいていた権限はどうなるか）を渡すとよいでしょう。たとえば、期間限定のキャンペーンを開始し、途中で担当者が異動し、期間終了をまたいで受注が残る、という時間の流れを歩かせます。

立つのは2つのレンズです。

正常系偏重も、つなぎ目にひとつ立ちます。キャンペーン期間が終わった後、期間中に受け付けた受注をどう扱うのかが、どの成果物にも見当たりません。

歯止めにより、問わないこと

レンズには、それぞれ何を問わないかの歯止めがあります。この例では、次のことは問いません。

• 業務との整合：要求事項と業務ルールが、IDでつながっているかは問いません。問うのは、閾値を変えられるという要件と、キャンペーンという業務ルールの中身が、噛み合っているかです。
• 境界・責任範囲：誰が閾値を変えるべきかは問いません。閾値が変わったことを後続の担当者が知る手段や、変更の権限の中身も提案しません。問うのは、閾値を変えるタスクの開始条件が、手前のタスクで満たされるかです。
• 正常系偏重：閾値以上か未満かの分岐は、定型の分岐なので問いません。キャンペーンが終わった後の受注をどう扱うべきかも書きません。問うのは、その扱いを検討した跡があるかです。

どのレンズでも、指摘への対応のしかた（管理画面を作るのか、業務部門が扱えるファイルにするのか）は、AIが書きません。「ない」とも言い切らず、「確認した範囲では見当たらない」とし、どの成果物をどんな言葉で探したかを添えます。出た指摘を、未決型ISSUEにするのか、成果物をそのまま直すのか、採らないのかは、人が振り分けます。

【広げる】でも、拾えるとは限らない

シナリオを思いついた順に作らせると、この一文の周りを1本も歩かないことがあります。種を渡すかどうかで、当たり外れが大きく変わります。拾えたとしても、返ってくるのは「読み取れない」までで、空白の在処は分かっても、埋め方は分かりません。

【確かめる】── 後から出た決定が、先に書かれた成果物に当たる

【確かめる】は、ADRの制約節と成果物を突き合わせ、決定に合っているかを見る検算です。この例は、回すきっかけのうち「決定が増えたとき」にあたります。「変更可能とする」と書かれた要求事項も、業務の定義も、ADR-0231 より先に書かれていました。

ADR-0231 の制約節は、販売業務の要求事項・業務の定義・ユースケースを影響範囲にしています。そこで、この3つの成果物に、ADR-0231 の制約を1行ずつ当てます。返ってくるのは、たとえば次の指摘です。

• 業務の定義のうち、閾値に触れていない節（受注の締めなど）には、何も返りません。
• 「判断できない」は、誰が変えるのかが要求事項から読み取れないために出ています。【深める】で立てた未決型ISSUE（変更してよい主体の細かさ）と、同じ場所を指しています。
• 「どこにも書かれていない」は、影響範囲の成果物をまとめて見て、どこにもないときに出ます。1件ずつ見ると、どの要求事項も「自分には関係ない」と答えて、何も返りません。ユースケースがまだないときにも出るので、この制約が書かれるのを待っていることが分かります。
• 制約節に書かれなかった要求（たとえば、切り替えた閾値をいつから効かせるか）は、問いが立たないので出てきません。

ここでは、成果物を直すと決め、反映型ISSUEを起こします。直してから、もう一度【確かめる】を回し、指摘が出なくなったら、人が反映型ISSUEを閉じます。

この検算に使ったADRは、まだ仮決定です。この例は、仮決定から検査に載せ、根拠にしたADRの状態を指摘に添えるプラクティス（7章）に従っています。

本番2週間前に発覚するはずだったものは、どこで拾われたか

「なぜ今このメソッドか」の章の問題提起に戻ります。あの一文が開けていた空白は、1周のどこで表に出たでしょうか。

最も効いたのは検査ではありません。ADRの背景を書こうとして、手が止まったことです。決定の理由を書こうとすると、書けない箇所が出ます。それが空白の在処であり、埋まれば仕様に穴は残らず、埋まらなければ未決として明示されます。どちらにせよ、AIが推測で埋める場面は来ません。検査は、その網をすり抜けたものを拾います。

そして、1周では終わりません。役割の細かさも、予約切り替えの要否も、対象商品を絞るかも、未決型ISSUEのまま残っています。それでかまいません。上流で全部決まるとは考えません。決まらなかったものが未決と分かる形で残り、次の議論の議題として自動的に揃っていること自体が、この1周の成果です。

本番2週間前との違いは、誰も気づかないまま流れたか、気づいた上で持ち越したかの違いです。

2周目 ── 未決がひとつ決まると、何が動くか

1周目で残った未決型ISSUEのうち、「対象商品を絞る要否」が決まる、という筋で、もう一度だけ通します。道筋は変更管理の章と同じなので、違うところだけを見ます。

議題は、もう揃っている

変更が外から来たなら、まず未決型ISSUEを起こします。今回は、起こす必要がありません。1周目の【深める】で、すでに未決として台帳に載っているからです。することは、その未決を、決める場の議題に載せることだけです。議題が揃っていたのは、1周目が、空白を空白のまま書き残したからです。

影響を調べるところは、変更管理の章と同じです。参照の照合と影響範囲で、閾値に触れている成果物とADRを洗い出し、【確かめる】と【広げる】で、絞った後の姿が既存の決定と食い違わないかを見ます。

覆らないので、新しいADRを並べて起こす

議論の結果、対象商品は絞ると決まりました。確定するのは、発注者側の責任者です。ここで、1周目のADRを直すのか、新しく起こすのかで、手が止まります。

1周目の決定は、覆っていません。業務部門が自分で切り替える、という決定は、そのまま生きています。覆っていないものは、置き換えません。かといって、1周目のADRに「対象商品も絞れる」を書き足すこともしません。書き足すと、いま有効な決定を読むのに、本体と書き足しの両方を突き合わせることになるからです。小さな追加の決定は、新しいADRとして並べて起こします。

# ADR-0248：送料無料の対象は、商品の範囲を絞って指定できる

## ステータス
- 状態：仮決定
- 発生工程：要件定義
- 確定者：発注者側の販売業務責任者
- 発生箇所：販売業務
- 置換：なし
- 前提とする決定：ADR-0231

## 背景
キャンペーンは特定の商品群を押し出すために打つものであり、全商品を対象に
すると原資が合わない。先の議論で決めきれなかったのは、絞る単位（商品の分類
か、個々の商品か）が業務部門の側でも定まっていなかったためである。今回、
分類の単位で足りることを確認した上で決めた。

## 決定
送料無料を適用する対象は、扱う商品の全体ではなく、指定した範囲に絞れる形と
する。範囲の指定は、閾値を切り替えるのと同じ主体が行う。

## 結果
### 良い結果
キャンペーンの原資を、押し出したい商品に寄せられる。
### トレードオフ（悪い結果）
対象商品の外の商品が同じ受注に混ざったときの送料の扱いを、別に決める必要が出る。

### この決定から生じる制約（後続成果物が満たすべき状態）
- 販売業務の要求事項：送料無料の適用条件が、金額の閾値だけで判定する
  ものとして記述されていない。
- 販売業務の業務の定義：送料の扱いが、対象商品の内と外を区別せずに
  記述されていない。
- 販売業務の要求事項：対象商品の範囲の変更履歴（変更日時・変更者・
  変更前後の値）を保持することが記述されている。

範囲を指定するのは「閾値を切り替えるのと同じ主体」なので、このADRは ADR-0231 を前提にしています。ADR-0231 が置き換わったら、このADRも見直す対象に挙がります。

反映して、閉じる

1周目のADRは、そのまま現役です。2件は並んで立ち、どちらも販売業務の要求事項に当たります。反映の作業は、影響を受ける成果物ごとに反映型ISSUEとして起こし、次の節目で反映します。反映したら、もう一度【確かめる】を回します。指摘が出なくなったら、人が反映型ISSUEを閉じます。

2周目でも、片付かないもの

• 範囲の外の商品が混ざった受注の扱いは、決まっていません。トレードオフとして書かれただけです。そこから未決型ISSUEを起こすかどうかも、人が決めます。
• 残りの未決2件（変更してよい主体の細かさ／期間を指定した予約切り替えの要否）は、手つかずのままです。未決は、まとめては片付きません。

付録成果物のサンプル ── 検査の手掛かりを備えた書き方の例

4章で、成果物に書いておく要素を挙げました。この付録は、それが実際の成果物のどこに、どう現れるかを見せるための切り出しです。

• 題材は、サイクルを1本通すと同じ「送料無料の閾値」です。1周目で決まった ADR-0231（閾値は業務部門が自分で切り替える）を反映した後の姿を、成果物ごとに数行ずつ切り出しました。
• 様式（表にするか、文章にするか、何という名前の成果物にするか）は、一例です。プロジェクトの標準の様式に、同じ要素を置けば足ります。
• IDの接頭辞（T・A・BR・ST・EX・UC・REQ・ISSUE）で、成果物の種別が分かるようにしてあります。
• 【未決：ISSUE-xxxx】は、未決の印の一例です。[ADR-0231] は注記の一例で、ADRを知らない人が書き換えうる記述にだけ置いてあります。

業務の流れ：送料無料キャンペーンを実施する

• タスクごとに、主体・開始条件・事後条件を持たせます。事後条件は、処理の言い換え（「閾値を変更する」）ではなく、終わったときに成り立っている状態で書きます。
• T-0102 の開始条件の一部は決まっていないので、未決の印を付けてあります。

主体の一覧

業務ルール

状態の定義

例外の一覧

ユースケース

UC-0003　送料無料の閾値を変更する　　　　　　　　　　　　[ADR-0231]

主体　　　　　：A-0001 販売企画担当
実現するタスク：T-0102
事前条件　　　：キャンペーン計画に閾値が記録されている
　　　　　　　　担当者が閾値を変更できる役割を持っている【未決：ISSUE-0012】
基本の流れ　　：1. 担当者が、新しい閾値を入力する
　　　　　　　　2. システムが、入力された値を検証する（EX-0003）
　　　　　　　　3. システムが、閾値設定を「キャンペーン中」に切り替え、
　　　　　　　　   変更の履歴（変更日時・変更者・変更前後の値）を記録する
事後条件　　　：閾値設定が ST-0002 になり、以後の受注は新しい閾値で送料が計算される

要求事項

サンプルと、検査の手掛かりになる要素の表の対応

この切り出しには、未決が3つ残っています（ISSUE-0012・0013・0015）。通し例の1周目で残った未決とは一部違います。切り出しの中で起きる未決を選んだためです。未決が残っていても、未決と分かる形で書かれ、ISSUEへ辿れれば、成果物としてはそれで足ります。

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

この一覧の読み方

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

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

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

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

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

章ごとの内訳

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

なぜ今このメソッドか

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

Trusted Spec の定義

育て方サイクル総論

たたく ── 叩き台の執筆

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

ADRの扱い ── 決定を書く

ADRの扱い ── 台帳を守る

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

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

確かめる ── ADR適合検査

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

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

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

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

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

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

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

歯止め一覧

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

付録用語集 ── 本書固有の用語

付録出典

本書が外部の資料に依拠して書いた箇所の出典を、章ごとにまとめたものである。読者が自分で一次情報に当たれるようにするために置いている。

読むときに、ひとつ断っておきたいことがある。

ここに並んでいるのは、本書の外に根拠がある事柄だけである。成熟度モデルの段階名、先行する制度が採ってきた運用、他社が公表した品質指標、製品や標準の仕様——こうした「本書が引いてきたもの」には出典がある。

一方で、本書の設計判断そのものには外部の出典がない。制約節で決定の当たる先を決めること、影響範囲で当たるADRを引くこと、【広げる】の4つのレンズという括り方、歯止めを問いと必ず一組にすること——これらは本書が決めたことであり、根拠は本文にある。外部の権威を借りて正当化できる性質のものではないし、そう見せかけてもいけない。この付録に載っていない規範は、本書が自分で立てたものだと読んでよい。

URLは執筆時点（2026年9月）に実在を確認したものだけを載せている。確認できなかったものは、そう書いてある。

なぜ今このメソッドか

• ADR（Architecture Decision Record）という記録形式
  出典：Michael Nygard「Documenting Architecture Decisions」（2011年11月15日）／https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions
  本書での使い方：決定の理由（WHY）を残す実践が、一般にこの名前で呼ばれていることを示すために引いた。本書のADRがアーキテクチャに限らず、業務ルールに関する決定を必ず残すこと（6章）は、原典との差分である。

• AIは曖昧さを認識しても、問い返さずに埋めることが多い
  出典：Su & Cardie "Knowing but Not Showing: LLMs Recognize Ambiguity but Rarely Ask Clarifying Questions"（arXiv:2605.25284, 2026）／ClarifyCodeBench（arXiv:2607.00711）／単一ターンの選好学習が問い返しを抑えるという説明は ICLR 2025 "Modeling Future Conversation Turns"。
  本書での使い方：「人なら手が止まる。AIも問い返すことはあるが、問い返さずに埋めてしまう場合がある」という本書の出発点は、一次研究で実証されている。本文には研究名を出していない。

• 人の判断を鈍らせる3つのバイアス
  出典：automation bias（医療の臨床意思決定支援研究、JAMA 2023）／confirmation bias（CHI 2025 の病理診断実験）。
  本書での使い方：本書は権威・確証・自動化の3つを挙げたが、研究界の定番は automation／confirmation／anchoring である。本書の「権威バイアス」は automation bias と重なる部分が大きい。anchoring（最初に出た案に引きずられる）も同系の論点だが、本文では扱っていない。

• 開発全体を準委任で進めるモデル契約
  出典：IPA「情報システム・モデル取引・契約書〈アジャイル開発版〉」（2020年3月31日公開）／https://www.ipa.go.jp/digital/model/agile20200331.html 。あわせて IPA「情報システム・モデル取引・契約書（第二版）」（2020年12月22日公開）／https://www.ipa.go.jp/digital/model/model20201222.html
  本書での使い方：「この前提は永久ではない」の裏づけ。要件定義を準委任で行う多段階契約はモデル契約が以前から示しており、いまでは一般的である。ただし要件定義の後の開発が、固定価格・納期固定で進む従来型のプロジェクトなら、要件定義書が完成の定義になるという本書の前提は変わらない。前提の有効範囲を狭めるのは、開発全体を準委任で進める形のほうであり、アジャイル開発版はそれを「準委任契約を前提としています」と明記している。

• SDDの主流は、新しい成果物体系を導入する
  出典：GitHub Spec Kit／AWS Kiro／OpenSpec／BMAD の設計思想。over-specification への批判は "Spec-Driven Development: From Code to Contract"（arXiv:2602.00180）。
  本書での使い方：1章で「SDDの解説の多くは、反復のたびに調整していく前提で書かれている」と書いた箇所の出典。本書も、AIが一貫して参照できる構造を求める点では主流と同じである。違いは、主流が成果物の組を用意するのに対し、本書は文書の組を決めず、文書が満たすべき状態を決めることにある。既存の要件定義・外部設計の文書のまま、決定・理由・辿れる網を添え、同じ文書で業務部門とAIの両方に応える。軽量・既存資産志向という点では OpenSpec が近い。over-specification 批判は、本書が「すべての要件には問わない。業務ルールに触れるものに限る」と歯止めを置いていることと同じ線にある。

Trusted Spec の定義

• AI-Native開発の成熟度モデル（ベースライン＝AI-Assisted → Level 1: AI-Generated → Level 2: AI-Verified → Level 3: AI-Explainable。Level 1 の鍵が ContextAwareness）
  出典：NTTデータグループ「アカウンタビリティを軸としたAI-Native開発のデザイン戦略」（2026年3月26日公開、全36ページ）／https://www.nttdata.com/jp/ja/-/media/nttdatajapan/files/services/adm/ai-native.pdf
  （公開の告知：https://www.nttdata.com/global/ja/news/topics/2026/032603/ ／ 解説記事「AI時代のシステム開発に必要な説明責任」2026年4月23日：https://www.nttdata.com/jp/ja/trends/data-insight/2026/0423/ ）
  本書での使い方：射程を Level 1 に宣言する根拠として用いた。段階の名称・番号・ContextAwareness の語は、この資料の用語体系をそのまま採っている（本書が作った語ではない）。13章の実装への接続も、この段階のうち Level 1 の話として書いている。図3（10ページ）をもとに、Trusted Spec の定義の章の図を作成した。抜き出したのは中核要素の4行と移行の鍵で、組織構造・環境の行は省いた。

• 設計根拠（Design Rationale）研究の半世紀
  出典：Kunz & Rittel の IBIS（1970）／MacLean et al. の QOC／Lee の DRL／Buckingham Shum & Hammond "Argumentation-based design rationale: what use at what cost?"（1994）。
  本書での使い方：ADRは設計根拠の軽量な実装である。この分野の最大の教訓は「書くコストが読む便益を上回ると続かない」であり、本書が運用の重さに章を割いているのは、独自の慎重さではなくこの教訓の帰結である。

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

• intra-mart の業務フロー（BPM）機能とそのエクスポート
  出典：intra-mart 公式サイト（株式会社NTTデータ イントラマート）／https://www.intra-mart.jp/
  本書での使い方：シミュレーションを「大がかりな準備なしに試せる」と言うときの具体例として挙げた。特定製品を前提にする趣旨ではなく、手元にBPMの機械が読める出力があるなら今日から試せることを示す例示である。

• シナリオベースの要件検証
  出典：Sutcliffe "Scenario-Based Requirement Analysis"（CREWS-98-07）／Sutcliffe et al. "A co-operative scenario based approach to acquisition and validation of system requirements: How exceptions can help!"（1998）。
  本書での使い方：シナリオを歩かせて要件の穴を探す技法は、要件工学で確立されている。非正常系の探索も例外の分類も先行研究にある。本書が変えたのは、シナリオの創作と歩行をAIが担う点だけである。

ADRの扱い

• Nygard形式（ステータス／背景／決定／結果）——本書はADRの記述形式の一案として推奨し、規範にするのは必須の要素まで
  出典：Michael Nygard「Documenting Architecture Decisions」（2011年11月15日）／https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions
  本書での使い方：ADRの記述形式の一案として推奨した（プラクティス）。記述形式としては「この決定から生じる制約」節を足した。必須の要素には確定者も含む。原典が「決定を覆しても古い記録は残し、superseded と印を付ける」「番号は再利用しない」と書いている点も、本書の置換の規律と同じ向きである。

• 台帳係という役割（採番・形式・つながり・索引だけに責任を持ち、内容に判断を下さない編集者）
  出典：PEP 1「PEP Purpose and Guidelines」（Python Enhancement Proposal の制度定義）／https://peps.python.org/pep-0001/
  本書での使い方：15章で、台帳係の仕事（採番・形式・つながり・索引）をAIに寄せられる量の重さとして挙げた、その先行事例として引いた。原典には "PEP editors don't pass judgment on PEPs. They merely do the administrative and editorial part" と明記されている。

• 状態語彙を絞る判断（本書は4状態。先行事例には9語を持つ制度がある）
  出典：PEP 1 の Status フィールド（Draft／Active／Accepted／Provisional／Deferred／Rejected／Withdrawn／Final／Superseded の9語）／https://peps.python.org/pep-0001/
  本書での使い方：本書が状態を4つに抑え（7章）、却下・取り下げ・保留をISSUE側へ逃がしたことの比較対象として使った。なお Accepted（決定した）と Final（実装まで完了した）を別ステータスで表す設計は、本書のADR／ISSUEの二層と同じ問題への別解である。

• 決定の台帳（不変）と作業の台帳（可変）を分ける二層構造
  出典：Rust RFC（https://github.com/rust-lang/rfcs ）／PEP 1（https://peps.python.org/pep-0001/ ）／IETF RFC（https://www.rfc-editor.org/series/rfc/ ）
  本書での使い方：決定の台帳と作業の台帳を分ける設計（5章）を、3制度がいずれも同型で数十年運用していることの根拠。Rust は "Every accepted RFC has an associated issue tracking its implementation in the Rust repository" と定め、RFC本文（不変）と追跡用の課題（可変）を分けている。受理は実装を保証しない（"Being 'active' is not a rubber stamp"）という明記も、成果物への反映の完了は反映型ISSUEが担い、【確かめる】で指摘が出なくなったら人が閉じる（11章）という本書の線引きと同じである。

• 索引は人手で二重管理せず、ヘッダと制約節から作る（プラクティス）
  出典：PEP 1（ヘッダのプリアンブルとステータス管理）／https://peps.python.org/pep-0001/ ／IETF RFC のメタデータ（Obsoletes／Updates 等）／https://www.rfc-editor.org/series/rfc/
  本書での使い方：索引をどう作るかのプラクティス（7章）で、「人手で二重管理しない」を推した根拠。

• 書く閾値の選別主義（可逆性が低い・複数チームに波及する決定に限る）
  出典：AWS Prescriptive Guidance「Architectural decision record process」／https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/adr-process.html ——"every architecturally significant decision" を対象とし、構造・非機能要件・依存・インタフェース・構築技術の5類型を挙げている。あわせて ADR コミュニティのハブ／https://adr.github.io/
  本書での使い方：6章で「主流が絞る理由は陳腐化と維持コスト」と書いた、その先行事例。本書は業務ルールに関する決定で線を引き、維持コストは15章で扱う。

• 共通原則（旧決定は削除しない／置換は双方向リンク／番号は再利用しない）
  出典：Nygard（https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions ）／MADR（https://adr.github.io/madr/ ）／PEP 1 の Replaces・Superseded-By ヘッダ（https://peps.python.org/pep-0001/ ）／IETF RFC の Obsoletes・Obsoleted By（https://www.rfc-editor.org/series/rfc/ ）
  本書での使い方：7章の規範（削除しない・置換する・番号を再利用しない）が、先行事例の全流派で一致している点であることの根拠。本書が独自に決めたことではなく、既に収束している慣行をそのまま採った箇所であることを示すために挙げている。

• 主流は "Any" から "Architectural" へ揺り戻している
  出典：Nygard 原典（2011）／MADR 4.0.0 のリリースノート（https://adr.github.io/madr/ 、2024-09-17。3.0-beta で採った "Any" を "Architectural" に戻し、「any decision にも使えるが焦点はアーキテクチャ決定」と明記）／"ADRs are not Any Decision Records"（TechWorld with Milan）／ThoughtWorks Technology Radar "Lightweight ADRs"。
  本書での使い方：本書が「重要か」ではなく「業務ルールに関する決定か」で線を引くことは、主流に対する分岐である。主流が絞る根拠（陳腐化と維持コスト）は本書も同じ重さとして引き受けており、その勘定は 15章 にある。

• Nygard 原典は追記を許す
  出典：Nygard「Documenting Architecture Decisions」の "An ADR can have new information added to it" の箇所。
  本書での使い方：本書が追記を許さず置換のみとするのは、原典より厳格な独自の厳格化である。理由は、【確かめる】が当てる制約節の版を一意にするため。

• 決定をテストとして書き、機械的に守らせる
  出典：Ford, Parsons, Kua "Building Evolutionary Architectures"（fitness functions）／ArchUnit／dependency-cruiser／"The Reason Most ADRs Get Written and Never Read Is Architectural"（2026）。
  本書での使い方：実装で機械的に守れるものは、実行可能なテストにも育てられる（14章）。「ADRは書かれても読まれない、決定は強制力を持つ成果物に結びつけよ」という議論は、本書が先行事例の失敗で言っていることと同じ向きである。

• 手作業で維持するトレースは劣化する
  出典：トレーサビリティ維持の劣化に関する報告（arXiv:2607.17686 ほか）。
  本書での使い方：注記に完全性を要求せず、決定がどこに当たるかは制約節の影響範囲で引くことにした根拠。

確かめる

• AIの判定は揺れる。ただし較正して使う道がある
  出典："Rating Roulette: Self-Inconsistency in LLM-As-A-Judge"（arXiv:2510.27106, EMNLP 2025）／"Reliability without Validity"（arXiv:2606.19544）／Guerdan et al. の rating indeterminacy（NeurIPS）。
  本書での使い方：判断できない項目を決めつけずに人に返す設計と、見落としへの備えの「複数回実行の突き合わせ」の根拠。あわせて、判定の揺れと、同じ結果が出るかを測る枠組みが外部に既にあることの提示でもある——測っていないのは本書であって、測りようがないわけではない。なお研究の主流は「判定を使わない」ではなく「較正して使う」方向であり、本書が判定を手前に留めるのは、検収文書に対する判定の責任を人が負うという契約の前提による。

変更管理

• 記録した帰結が忘れられて障害化した事例
  出典：Michael Keeling・Joe Runde（IBM）「Share the Load: Distribute Design Authority with Architecture Decision Records」（Agile Alliance Experience Report、Agile2018）／https://agilealliance.org/resources/experience-reports/distribute-design-authority-with-architecture-decision-records/
  本書での使い方：11章で「反映の作業を追っていなければ、決定は成果物に届きません」と書き、その先行事例として挙げた事例。原文では、リリース9か月後に学習系のシステムが負荷で傾き（"Nine months after launch, our training systems started to buckle from too much load."）、その性能問題はADRに書かれていたが忘れられていた（"This was in the ADR but we forgot about it."）と述べられている。決定の台帳（不変）と作業の台帳（可変）を分け、後者のクローズ条件を検査に結びつける——という本書の答えは、この失敗への応答である。

テスト工程

• 観点カバレッジとDDPモニタリング
  出典：町田欣史（NTTデータ）「バグ密度・テスト密度に依存しない品質保証への挑戦」DATA INSIGHT（初出2021年2月4日、2024年1月にアジャイル開発への適用例を加筆）／https://www.nttdata.com/jp/ja/trends/data-insight/2021/0204/
  本書での使い方：12章が渡す考え方そのものの出どころである。観点カバレッジ（網羅状況をマトリクスで可視化する）とDDPモニタリング（すり抜けの割合の推移を追う）は、本書が考案したものではなく、この資料の手法を採っている。密度に依存しない品質保証という狙いも同じである。出典の観点カバレッジは試験対象×試験観点のマトリクスだが、本書は結合テスト・総合テストを対象にし、【広げる】のシナリオを試験シナリオの種にするので、対象の代わりにシナリオを置いた（試験観点×試験シナリオ）。
  関連：同じ筋の続編として「生成AIを使って開発したソフトウェアの品質保証」（2025年10月16日）／https://www.nttdata.com/jp/ja/trends/data-insight/2025/1016/ ——コード量ベースの指標が使えない生成AI開発でこそ有効だ、と論じている。本書12章が「コードの規模で割る指標から降りる」と書いている部分と同じ文脈接続である。

• バグが少ない案件では参考程度の活用にとどめた、という適用事例
  出典：岩崎慎司・町田欣史・龍真子（NTTデータ）「システムの特徴に応じた品質保証 ～開発技術を組み合わせたテスト事例と効果～」DATA INSIGHT（2024年1月22日）／https://www.nttdata.com/jp/ja/trends/data-insight/2024/0122/
  本書での使い方：12章の読み違えの②「バグが少ないほど1件で大きく振れる」を、手法の提案者自身が実適用で認めていることの根拠として引いた。原文の表現は「バグが少ないと1件のバグによりDDPが大きく動きすぎるため参考程度の活用にとどめました」である。バグが減るほど母数が小さくなるので、AI-Native開発では、この不安定さは避けられない——だからDDPを単独で合否の指標にしない、という本書の立場につながる。

実装への接続

• intra-mart Accel Platform（本章が逆算の材料にしている実装環境）
  出典：intra-mart 公式サイト（株式会社NTTデータ イントラマート）／https://www.intra-mart.jp/
  本書での使い方：13章は、実装するAIが参照するひとそろい（実装のコンテキスト）の例から、上流の仕様に何が求められるかを逆算する章であり、例にした実装のコンテキストの実装環境がこの製品である。ただし本書は特定製品を前提にしない——逆算して取り出しているのは「推測で書くな、根拠を参照しろ」という規律の形であって、製品固有の作法ではない。

• 意味を渡す器の標準化
  出典：Apache Ossie（旧称 Open Semantic Interchange）／https://ossie.apache.org/ ／Apache Incubator 入りの告知（2026年7月10日）／https://ossie.apache.org/updates/ossie-enters-apache-incubator/ ／Apache Incubator のポッドリング一覧／https://incubator.apache.org/clutch/ossie.html
  本書での使い方：項目や指標の意味も実装のコンテキストに渡す、という本文の話の補足として、実在する標準化の動きとして挙げた。データセット・項目・関連・指標の意味をベンダ中立な形式（JSON／YAML）で交換することを狙う仕様である。本文の筋から外れた補足として、コラムに置いた（規範でもプラクティスでもない）。本書の執筆時点でインキュベーション段階にあり、仕様は動く。

• Apache Ossie の成熟度
  出典：ossie.apache.org／Apache Incubator 入りの告知（2026年）。
  本書での使い方：標準としてまだ未成熟であることの裏づけ。2026年9月時点で、この仕様をそのまま実装して出荷した製品は確認できず、動く経路は変換ツールの参照実装にとどまる。コラムの「仕様をそのまま実装した製品は、まだ見当たりません」の裏づけ。

導入とプロジェクトハーネス

• 業界の agent harness は、モデルを取り巻く実行の仕組みを指す
  出典：Addy Osmani "Agent Harness Engineering"／Mitchell Hashimoto の論考／"Harness Engineering Is Not Context Engineering"（advise と enforce の区別）。
  本書での使い方：本書の「プロジェクトハーネス」は業界用法より広いことの裏づけ。業界の重要な教訓は「助言するもの（文脈ファイル）と強制するもの（hook・CI）を厳密に区別せよ」である。

ADR運用の重さ

この章には外部の出典を持たない記述がある。

• 本書が実際に運用してみて分かったこと。ADRがあると、AIは今の方針で進める——本書の執筆にADRを使う中で、よりよい方針の案が出ても、AIはADRに書かれた方針で進めた（15章）。これは本書の執筆で起きたことの記録であって、外部に出典はない。

本文の例について

本文と付録の例（ADR-0231、送料無料の閾値）は、「なぜ今このメソッドか」の章の例に合わせて創作したものであり、実プロジェクトのADRではない。番号・題材・制約節の文言のいずれも架空である。

この付録に載せていないもの

最後に、確認したうえであえて載せなかったものを挙げておく。読者が「なぜこれが無いのか」と迷わないためである。

後付け変更履歴

履歴