前付けはじめに

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

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

誰に向けて書いたか

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

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

扱う工程

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

AIについての前提

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

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

読み方の前提

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

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

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

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

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