仕様ガバナンス参照モデル（SGRM）は、AI ネイティブなエンタープライズ・ソフトウェアエンジニアリングの基盤としての仕様駆動開発 が設計した成果物であり、仕様駆動開発 を形式的かつツール非依存にまとめ上げたものである。同論文が統制されない対話的生成に帰する失敗モードに対して、狙いを定めた処方として意図されている。その中心となる発想は、観察による受け入れを、明示的で永続的な契約に照らした検証による受け入れに置き換えることにある。モデルは、仕様・生成器・検証器・仕様ガバナンスの形式的定義、プロセス不変条件としての 3 つの厳密さの段階の形式化、トレーサビリティの背骨が貫く 4 層アーキテクチャ、閉ループの再生成アルゴリズム、そして 6 つの反証可能な設計命題から構成される。
用法
このモデルにおける仕様とは、4 つの構成要素からなる機械可読なタプルである。すなわち、機能的義務（契約による設計の意味での事前条件・事後条件・不変条件を伴うインターフェースシグネチャ、受け入れシナリオ、振る舞いの例）、品質制約（レイテンシ予算、可用性目標、複雑度の上限など、ISO/IEC 25010 の品質特性に対する測定可能なしきい値）、憲法的制約（交渉の余地のないセキュリティ・プライバシー・規制上のルールで、たとえば CWE の弱点クラスから導かれる禁止事項）、そしてアーキテクチャ構造（モジュール境界、境界づけられたコンテキスト、インターフェース契約、依存関係のルール）である。生成器は、仕様とコンテキストを与えられると実装成果物をサンプリングする確率的な関数であり、論文はその非決定性を本質的なものとして扱う。検証器は決定論的かつ決定可能な手続きであり、4 つの連言項——憲法的チェックを伴う静的解析、仕様から導出したテストスイートの実行、インターフェース契約と証明義務、アーキテクチャ適合性チェック——に分解される。検証器が受け入れる成果物の集まりが、その仕様の受け入れ集合をなす。開発プロセスが仕様によって統制されていると言えるのは、システムに統合されるすべての成果物が現在の仕様の受け入れ集合に属し、かつシステムの振る舞いに対する意図的な変更がすべて、実装を直接書き換えることによってではなく仕様の変更によって開始される場合に限られる。
モデルが形式化する 3 つの厳密さの段階は、段階的に強くなるプロセス不変条件として述べられている。スペックファーストでは、仕様は実装より前に作成されるが、検証が成り立つのは統合時点のみである。そのため実装はその後独立して変化しうるし、両者の結びつきは劣化しうる。スペックアンカードでは、検証が継続的に維持され、どちらの成果物を編集しても検証が再実行されるため、乖離は即座に検出され、仕様とコードは共に進化する。スペック・アズ・ソースでは、人間が編集する成果物は仕様だけであり、実装は受け入れ集合にとどまるよう再生成される。保守は仕様の変更と再生成の問題になる。論文はこれを序列ではなくコストを伴う設計空間として示しており、右へ一段進むごとに、より高い作成コストとツールコストと引き換えにより強い保証が得られるとしている。
アーキテクチャは、バージョン管理された唯一の信頼できる情報源としての仕様層、モデルやツールに対して意図的に中立でインターフェースにおいてのみ制約される確率的生成器からなる生成層、確率的な中核を取り囲む決定論的な境界である検証層、そして人間が仕様レビュー・統合ゲート・監査証跡・エスカレーションを通じて説明責任を保持するガバナンス層から成る。垂直のトレーサビリティの背骨が、仕様の各要素をそれを実現する成果物に結びつける。論文は、これが事後的な再構成ではなく、プロセスの副産物として得られると論じている。運用上の中核は棄却サンプリングのループである。候補が生成器からサンプリングされ、検証器がそれを受け入れるか棄却し、棄却の診断情報が修正のための入力としてコンテキストに追加される。予算を使い果たした場合は、基準を黙って引き下げるのではなくガバナンス層へエスカレーションされる。論文はこのループの 3 つの性質を強調している。生成を駆動する仕様そのものがオラクルも生成するため自己修正的であること、検証器に関して単調であるため、検証器のいずれかの構成要素を強化すれば生成器に手を触れずに受け入れられるすべての成果物の保証が引き締まること、そして安全に劣化することである。
適用される場面
論文はモデルの適用可能性を条件付きで述べ、表にまとめている。アイデア出し、プロトタイピング、学習、創造的な探索、MVP の組み立てといった、速度・手軽さ・形式張らなさが優先される場面では、対話的生成が推奨される実践である。軽量な仕様と一回限りの検証によるスペックファーストは、単体のユーティリティ、社内スクリプト、短命なツールに適する。継続的な検証を伴うスペックアンカードは、再現性と保守性が優先される、長期にわたって進化し続ける複数開発者のプロダクトに適する。憲法的制約を伴うスペックアンカードからスペック・アズ・ソースまでは、セキュリティ・コンプライアンス・監査可能性・長寿命性が優先される、エンタープライズ、規制対象、あるいはセーフティクリティカルなシステムに推奨される。
このモデルは、人間が作成でき、機械で検証でき、かつ LLM が読み取れるという条件を同時に満たす仕様を前提としている。論文は、そのような言語の設計を——それが課す作成コストの測定とあわせて——プログラム合成における表現力と扱いやすさのトレードオフに由来する未解決問題として挙げている。検証器自体の内部でも、あるサブチェックは条件付きで述べられている。契約の連言項はインターフェース契約をチェックし、機能的義務が形式的意味論を持ちうる場合には証明義務を呼び出す。
このモデルの位置づけは、実験的にではなく分析的に評価された提案である。論文は、公表済みの結果のみを用いて ISO/IEC 25010 に照らした根拠ある議論によってモデルを評価しており、新たな実験データは収集していない。また自らの証拠を成熟度によって重み付けし、仕様を支持する最も目を引く定量的結果を、再現されていない事例証拠の段階に置いたうえで、論証の重みはそこには置いていないと述べている。6 つの設計命題は、後の証拠がそれに関わりうるよう、あえて反証可能なコミットメントとして述べられている。