第2章Trusted Spec の定義
目的はひとつだけ
本メソッドの目的はひとつです。
AIに安心して実装を任せられる仕様 ——「信頼できる仕様（Trusted Spec）」—— を育てること。Trusted Spec の3条件
| # | 条件 | 意味 |
|---|---|---|
| ① | 決まっている | あいまいなまま流さず、決まったこと・未決のことが区別されている |
| ② | 根拠がある | なぜそうなったか（WHY）が、判断した人の証跡とともに残っている |
| ③ | 辿れる | 要求から実装まで、双方向でトレースできる |
3条件は、前章で見た問題にそれぞれ対応します。①は推測の混入口を塞ぎます——「未決」と明示された箇所を、AIは勝手に埋められません。②は補完の舵取りです——WHYが残っていれば、許される補完の方向が絞れます。③は流れてしまった推測を捕まえる網です——要求と実装を突き合わせれば、根拠のない実装が浮かび上がります。
3つを、もう少し具体に見ていきます。
①決まっている
満たしている状態とは、決まったことと決まっていないことが、読んで区別できる状態です。未決が無いことではありません——未決は必ず残ります。未決が「未決と分かる形」で書かれ、置き場を持っていれば、それで足ります。その置き場がISSUEです。ISSUEは、決めるべき論点と、決定を反映する作業の記録です。どの現場も課題管理として回してきたものにあたり、本書では、まだ決まっていない論点を未決型ISSUEとして置きます。書き方と置き場は5章で扱います。
これが崩れる典型が「決まったふり」です。あいまいなまま断定形で書かれた記述は、AIから見れば決定と見分けがつきません。前章の「変更可能とする」がまさにそれで、未決であることが読み取れないから、推測で埋められました。
②根拠がある
ここでいう業務ルールは、業務上の取り決めのことです。「何のため」の根拠の側にあたります。業務ルールに関してプロジェクトが下した決定とは、業務ルールをどう実現するか、どう解釈するか、どこまで適用するか、例外をどうするか、誰が変えるか、を決めたものを指します。
決定を残す器が、決定の記録＝ADRです。一般には Architecture Decision Record を指しますが、本書ではアーキテクチャに限らず、業務ルール・権限・状態の定義など、AIが推測で埋めそうな空白を塞ぐ決定を扱います（理由は6章「なぜ業務ルールで線を引くのか」）。
業務ルールに関してプロジェクトが下した決定は、「何を決めたか／なぜそう決めたか（WHY）／誰の判断か」の3点とともにADRに残す。3つ目を落とさない。
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を書く | 「なぜこうなっているか」の再調査——議事録の掘り起こし、当時の担当者への確認 |
| 決まっていない箇所を、未決だと読み取れる形で、ISSUEへ辿れるように成果物に書き残す | 決まったふりで流れた箇所が下流で露見したときの手戻り（前章の失敗例） |
| IDを採番し、トレーサビリティを維持する | 変更要求時の影響範囲の目視追跡——既存の検査を道具として呼び出せる |
| 節目で検査を回し、指摘を仕分ける | 成果物の全文レビュー——検査の対象は、決定ごとに関係する文書に絞られる。あわせて、【広げる】で歩かせた業務シナリオが、テストのシナリオの種としてもう一度使える——試験シナリオをゼロから起こさずに済む（8章・12章） |
右の列で「減る」と書いたのは、受託者側の作業です。ADRが増えても、書き手が読むのは自分の成果物に関係する決定だけで、台帳全体を探し回らずに済みます。ただ、決定と成果物を突き合わせる量そのものは、決定と成果物が増えるほど増えます。そこはAIの検査が引き受ける量で、その重さは、運用の重さの章で扱います。
発注者の側にも、増えるものと得るものがあります。
| 発注者に増える | 発注者が得るもの |
|---|---|
| 決定の確定者としての判断（誰が決めたかが残る） | 決定の証跡が、変更合意・検収の根拠になる |
| あいまいだった箇所を、決めるか、未決として持ち越すかを判断する | 「決まっていない」が、本番前ではなく承認前に見える |
| 定例で決定事項を読み合わせる（その記録がADRになる） | 業務ルールのWHYが、次の更改まで残る |
左の列の多くは、発注者がこれまでもやってきたことです——決定を承認し、打ち合わせで決定事項を読み合わせる。本メソッドが変えるのは、それが残る形になることと、あいまいなまま先へ送っていた箇所が、承認の前に見えるようになることです。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条件を満たしている「状態」の呼び名です。状態なので、一度では完成しません。未成熟・仮置き・揺れを前提とし、サイクルを回して段階的に成熟させます。「作る」ではなく「育てる」と呼ぶのはそのためです。
育てる対象は仕様だけではありません。決定がルール・ガイド・観点へ発展していくことで、プロジェクト環境（プロジェクトハーネス）も育つ——誰が書いても一定の品質になる環境が整うことは、本メソッドのもうひとつの到達点です。