Spec Growth Engine は、Spec Growth Engine：AI 支援ソフトウェア開発のためのスペックアンカード・コード結合・ドリフト強制型アーキテクチャ で提案された AI 支援ソフトウェア開発のフレームワークである。著者はこれを次の三つの性質で特徴づけている。スペックアンカード（spec-anchored）であること、つまりすべてのアーキテクチャ上のノードが仕様を持ち、その仕様が生成後に捨てられるのではなく生きた成果物として保たれること。コード結合（code-coupled）であること、つまりコードと仕様が同じコミットで変更されること。そしてドリフト強制（drift-enforced）であること、つまり両者の乖離が規律の問題ではなく、マージをブロックするエラーとなることである。これは新しいパラダイムではなく、確立されたソフトウェアエンジニアリングの原則を統合したものとして示されており、その際立った特徴は機械による強制にある。古典的なアプローチが規律に委ねていた性質が、ブロッキングゲートと決定論的な導出として符号化されている。
用法
このフレームワークは、相互に噛み合う五つの構成要素 — 仕様グラフ、コンテキストアセンブラ、ドリフトバリデータ、ガバナンスゲート、ケイパビリティレジストリ — を中心に組織され、異なる権限を持つ四つのアクターによって運用される。以下に述べる垂直スライス成長プロトコルはグラフがどのように成長するかを統制するものであり、論文の結びの要約では、レジストリの代わりにこれがエンジンの仕組みの一つに数えられている。
仕様グラフ は、すべてのアーキテクチャ上のエンティティをノードとし、各ノードはちょうど一つの仕様ファイルとして具体化され、そのファイルの kind フィールドがレベルを宣言する。ノードはシステムからコードまでの四つのズームレベルで組織される。各ノードは直交する二つのビューを持つ。一つは外向きの契約で、隣接ノードが読むことができ、公開インターフェース、不変条件、型、エラー時の振る舞い、受け入れ基準を保持する。もう一つは内向きの設計で、そのノードの実装者と親だけが見ることができ、内部のアプローチとコードの所有を保持する。エッジは二種類に区別される。所有エッジは木を形成し、親の契約は子の契約の総和となる。依存エッジは有向非巡回グラフを形成し、あるノードは別のノードの契約を使うことはできるが、その設計やコードを使うことは決してできない。
Spine は、グラフのルートから現在作業中のノードまでの所有パスであり、エージェントのコンテキストを限定するのはこれである。エージェントのために組み立てられるバンドルは、ルートの不変条件、そのパスに沿った契約、ノード自身の完全な仕様とコード、そして宣言された依存先の契約（1 ホップのみ）からなる。兄弟コンポーネント、依存先の設計、依存先のコード、推移的な依存、その場しのぎの検索結果は含まれない。アセンブラは検索ではなく、グラフ上の決定論的な関数である。バンドルが不十分な場合、自由な検索に頼るのではなく、構造化された診断 — 契約の欠落、宣言されていない依存、受け入れ基準の欠落 — を報告し、定められた修復はコンテキストを広げることではなくグラフを直すことである。本来ならすべてのノードに複製しなければならない横断的な不変条件は、代わりに木を横断する位置にある単一のアーキテクチャ文書に置かれ、すべてのバンドルの先頭に付加される。
垂直スライス成長プロトコル は、二層のルールのもとでシステムがどのように成長するかを統制する。第 1 層は、ルートの不変条件と主要なコンテナの境界を、意図的かつ前もって固定する。第 2 層は、機能を、最も難しいものから順に、それぞれが薄いエンドツーエンドの増分である垂直スライスとして成長させる。六つの成長ルールが各変更を分類し — 振る舞い、分解、依存、境界、内部設計、そしてより高いズームレベルへの昇格 — 更新すべき成果物の最小限の結合した集合を定める。そこから二つの性質が導かれる。子の契約の総和が親の契約になるため、分解は契約を保存する。そして、内部だけの変更は隣接ノードの仕様に波及しない。
ドリフトバリデータ は、二つのグラフを導出して比較する。仕様ファイルからの意図グラフと、コードの静的解析からの証拠グラフであり、後者はインポートとエクスポート、ルートとイベント、そしてテストを対象とする。一部の乖離は無条件にマージをブロックする。コード上の証拠のない宣言された依存や、テストの証拠のない契約上の振る舞いといった弱いシグナルは、警告として報告される。
ガバナンスゲート は、レビューを変更の影響範囲（blast radius）と可逆性に結びつけ、三つのゲートレベルを設ける。マージ前の人間による承認、エージェントが進めて人間が非同期にレビューするもの、そしてエンジンのポリシーのみによるものである。四つのアクターが権限を分離してエンジンを運用する。境界と公開契約について決定権を持つ人間のアーキテクト、分解を提案するプランナーエージェント、自分のバンドルの範囲内で実装するコーディングエージェント、そしてエンジン自体であり、エンジンは決定論的で、意図を生み出すことはない。
ケイパビリティレジストリ は、このフレームワークの水平方向の再利用の軸である。ケイパビリティは安定した識別子を持ち、それを提供するノードはちょうど一つである。あるケイパビリティを実装しようとするエージェントはまずレジストリに問い合わせるため、同じケイパビリティを提供する二つのノードは重複として検出される。著者はこのチェックを、アーキテクチャレベルでの DRY と表現している。
適用される場面
このフレームワークは、著者が AI 支援開発において特定する二つの失敗モード — 範囲の限定されないエージェントのコンテキストと、気づかれないまま蓄積する仕様のドリフト — に対処するものであり、その適用範囲は、プロジェクトの規模や年数についての明示された閾値からではなく、それらの失敗モードから導かれる。著者はこれを、生成後に仕様を捨てるか後回しにするスペックファーストのアプローチと、仕様からコードを生成し、著者の主張によれば非決定性という代償を払って同期を得ているスペック・アズ・ソースのアプローチとのあいだに位置づけている。
このフレームワークは、ソースファイルから静的な依存グラフ — インポート、ルート、イベント — を導出できることを前提としており、著者はこれを限界として挙げている。実行時の依存性注入やプラグインアーキテクチャを用いるような高度に動的なシステムでは、遅延束縛される依存を明示的に注記する必要がある。ガバナンスのオーバーヘッドは動きの速いチームにとって現実のものであると認められており、中間のゲートレベルによって軽減されるが解消はされない。明示されている成果物のコストは、コンポーネントレベル以上のアーキテクチャ上のノードごとに一つの仕様ファイル、そしてシステムごとに一つのアーキテクチャ文書であり、著者は、これが従来のアーキテクチャドキュメントよりも大幅に少なく、範囲を限定したバンドルによるコンテキストの節約で部分的に相殺されると主張している。
どの程度確立されたものかについて、出典が決着をつけているのは一方の側だけである。組み合わされている仕組みは長年のソフトウェアエンジニアリングの成果から引かれているが、エンジンそのものは単著者による設計提案であり、実験、ベンチマーク、ユーザー調査は報告されておらず、その作業例は仕組みを例示するものであって測定するものではない。著者は、これが社内の設計文書群として保守されており、公開リリースが予定されていると述べている。
関連用語
- Spec Growth Engine：AI 支援ソフトウェア開発のためのスペックアンカード・コード結合・ドリフト強制型アーキテクチャ — このフレームワークを提案する論文
- 仕様駆動開発 — このフレームワークがその一変種である、より広い実践
- コンテキスト盲目 — 別の出典が名づけた密接に関連する失敗モードで、エージェントの成果物が内部では一貫しているがリポジトリとは整合しないもの
- コンテキストロット — 入力長に伴う劣化であり、Spine による範囲の限定の動機となるもの