第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が仕様を推測で使わずに済むのは、読みにいける仕様があるときだけです。
仕様に書いていないことは、規約で埋まる
実装のコンテキストには、コーディングの規約がたくさん入っています。そして、仕様と規約のどちらを優先するかが、次のように決められています。
| 決まり | 中身 |
|---|---|
| 仕様が先 | 作るものの中身は、仕様書に従う。仕様書に書いてあることは、規約より優先する |
| 規約は補い | 規約を使うのは、仕様書に書いていないことについてだけ |
| 当てすぎない | 規約は最低限の守りで、目標ではない。仕様に書いていないことについて、規約から要求を足さない |
これは、実装する側から見た、仕様の重みの宣言です。裏を返すと、仕様に書いていないことは、規約の既定で埋まるということです。画面の入力欄の文字数の上限、エラーコードの付け方、アクセシビリティの厳しさ。規約はよくできた既定ですが、業務の意図は知りません。既定で埋まった結果は技術的には正しく、レビューでも指摘されにくいものです。最初の章で見た、送料無料の閾値と同じ形です。
規約をいくら厚くしても、業務の意図は埋まりません。業務の意図は、仕様で決めるしかありません。
上流の仕様に求められること
ここまでを、上流の仕様への要求としてまとめます。
上流の仕様は、実装側に次の3点で応える——①実装から要求まで、IDで遡れること ②やってよい範囲・いけない範囲が、推測ではなく参照で解決できる形で書かれていること ③未決が未決と分かること（実装AIが「埋めてよい空白」と区別できること）。
- ①IDで遡れる：実装するAIが、「この処理の根拠はどの要求か」を辿れます。その要求に影響する決定も、ADRの制約節の影響範囲から引けます。
- ②参照で解決できる：とくに、権限・状態の移り変わり・業務ルールです。ADRの制約節が、その出どころになります。実装は本書の工程の外にあるので、実装のコンテキストには、成果物と一緒にADRも渡せます。ADRを渡すときに、仮決定か承認済みかを添えておけば、実装するAIは、決定がどこまで固まっているかを知った上で使えます。
- ③未決が分かる：成果物の未決の印から、決まっていない箇所を機械的に見分けられます。人の注意力に頼らず、書き方で分かるようにしておきます。
上流の仕様は、どう実装に渡るか
上流の仕様が実装に渡るには、大きく2つのパターンがあります。
- 外部設計書を作ってから渡す。要件定義、外部設計と書き上げ、その外部設計書を実装のコンテキストに読ませて実装します。
- 実装のコンテキストの中で、対話しながら決める。要件定義のあとは、実装のコンテキストの中でAIと対話し、画面や項目などを決めながら、そのまま実装します。
本書は、前者の、外部設計書を作ってから渡すスタイルを取っています。SIでは、外部設計書が発注者の承認や検収の対象になることが多いからです。ただし、どちらのパターンでも構いません。後者で進めるなら、対話の中で決めたことも、決定として残してください。たとえば対話で「在庫がないときは、受注を予約受付にする」と決めたなら、それは業務ルールに関する決定なので、ADRに残します。決まらなかったことは、未決型ISSUEに残します。そうしないと、決まっている・根拠がある・辿れる、の3つが、実装の手前で切れてしまいます。
大規模SIでは、外部設計書だけでは、AIが実装するのに足りません。外部設計にどこまで書くかはプロジェクトによって幅があり、実装に要る細部（処理の手順、データの細かな扱い、例外の細部）までは書かれないのが普通だからです。そこで、外部設計書をもとに、実装のコンテキストを使ってAIに実装用の仕様書を書かせ、それに従って実装させます。
このとき、外部設計書と一緒に渡したいものがあります。項目や指標の意味です。
構造だけでなく、意味も渡す
上流から実装へ渡すとき、構造は渡せても、意味が渡せていないことがあります。ER図やテーブル定義は、どんな項目があり、何と何がつながるかは書きますが、「この項目は業務上どういう意味か」「この数値はどう計算するか」「どの細かさで集計するか」までは書きません。画面の項目定義も、項目の名前と型は書いても、その値が業務で何を指すかは書かないことが多いものです。人は文脈で補えますが、AIは補えず、推測で埋めてしまいます。
そこで、こうした成果物に加えて、項目や指標の意味を、人にもAIにも読める形（JSON・YAML など）で書いておき、外部設計書と一緒に実装のコンテキストに渡します。効くのは実装だけではありません。
- 実装：実装用の仕様書を書くAIも、実装するAIも、項目の意味を推測せずに参照できる。
- テスト：項目が取りうる値と意味が書いてあれば、境界の値や異常な値の試験観点を立てやすい。
- データ分析：運用が始まってからの集計で、同じ指標が部署ごとに違う定義で計算されるのを防げる。
ここまでをまとめると、上流の仕様は、次の流れで実装に渡ります。
- 外部設計書と、項目や指標の意味を書いたものを、実装のコンテキストに渡す。
- 実装のコンテキスト（仕様書の書き方のガイドや規約）を使って、AIに実装用の仕様書（詳細設計にあたるもの）を書かせる。どこまでを仕様書に落とすかは、外部設計の書き込みに合わせて決める。
- 人が仕様書を確かめる。仕様書を書く中で業務ルールに関わることを決めていたら、ADRに残す。
- 仕様書に従って、AIに実装させる。
意味を渡す器の標準化
項目や指標の意味を、製品によらない形で受け渡すための標準化の動きとして、Apache Ossie（旧称 Open Semantic Interchange）があります。データセット・項目・関連・指標の意味を、JSON や YAML で交換することを狙うものです。2026年7月に Apache のインキュベータに入ったばかりで、仕様をそのまま実装した製品は、まだ見当たりません（付録_出典）。
2つの条件は、どう満たされるか
最初の章で、SI文書は ①業務部門が承認できる ②AIが実装できる、の2つを同時に満たす必要があると述べました。Trusted Spec の3条件は、この両方に効きます。「決まっている」「根拠がある」は、業務部門が承認する（検収する）ことを支え、「辿れる」は、AIが実装することを支えます。
業務の言葉で承認された決定が、理由と一緒に、実装まで流れていく。これが、本メソッドの目指すところです。