本論文は、バイブコーディング のような AI 支援の実践から、自律的なエージェントに目標レベルのタスクを委任するエージェント型ソフトウェアエンジニアリングへの移行は、技術的な出来事というよりも主としてチームの社会技術的な再編成であり、仕様駆動開発 こそがその移行をチーム規模で機能させる規律であると論じる。その動機となっているのは、著者らが産業界から報告された生産性のパラドックスと呼ぶ現象である。AI の導入によって個人の成果は増える一方で、チームレベルのスループット、レビュー能力、安定性は低下する。著者らはこれを、ソフトウェアライフサイクルに適用されたアムダールの法則として読み解く。つまり、レビュー、検証、統合が従来の能力のままであれば、コード生成を加速してもシステム全体は加速しないということである。
著者らの評価では、チームレベルの SDD も、チームのガバナンス構成概念としてのハーネスも、まだ学術的に扱われていなかった。そのため本研究は、学術的な情報源に加えてグレーリテラチャー（実務者による報告、講演、ブログ記事、オープンソースのツール）に意図的に依拠する多声的文献レビューであり、統計的ではなく解釈的に統合されている。本研究の貢献は次のとおりである。仕様が人間とエージェントの間の契約基盤となる SDD の社会技術モデル。エージェントを取り囲む技術的ハーネスとチームを取り囲む 方法論的ハーネス に分けたハーネスの操作的特徴づけ（架空の返金機能を題材とした具体例で説明される）。そして、人間の役割を再定義する 5 つの人間–エージェント間インタラクションパターンの類型である。
著者らはこのフレームワーク全体を、検証済みの理論としてではなく、学術界と産業界の合意に向けた第一歩であり、反証可能な仮説の集合であると明示的に位置づけ、その実証的検証のための研究課題で締めくくっている。
要点
- 本論文は、アジャイルと DevOps、生成 AI で拡張された SE、バイブコーディング、SDD を伴うエージェント型 SE という 4 つのパラダイムを、5 つの社会技術的次元（作業単位、主要成果物、認知の所在、説明責任、チームトポロジー）に沿って比較する。そして、バイブコーディングへの移行は説明責任、検証、オンボーディングの面で後退であるのに対し、SDD のもとでのエージェント型 SE はそれらを形を変えて回復すると論じる。
- バイブコーディングをチームの実践としてスケールさせにくくしている 5 つの限界として、再現不能性、監査不能性、移転不能性、レビューの飽和、ノイズのスケーリングを挙げ、これらを実務者の失敗ではなく方法論の失敗として位置づける。
- SDD を 4 つのコミットメントによって操作的に定義する。自明でない計画的変更はすべて、その契約として扱われる書かれた仕様から始まること。仕様はコードとともにバージョン管理されること。成果物は明示的な来歴を伴って仕様から導出されること。そして仕様と成果物が食い違う場合は仕様が信頼できる唯一の情報源であり、その食い違いは成果物の再導出または仕様の修正によって解消され、黙って編集することでは決して解消されないこと。
- システム仕様（永続的なアーキテクチャ、規約、規範的ルールで、
AGENTS.mdやCLAUDE.mdなどのエージェントのルールファイルとして具体化される）と機能仕様（特定の変更を扱い、タスクごとに作成され、納品後にアーカイブされる）を区別し、さらにその両者をスキルと区別する。スキルは手続き的で必要に応じて読み込まれるものであり、規範的で常に有効なものではない。 - SDD に関する 2 つの誤解（「ドキュメントを増やすこと」であるという誤解と、ウォーターフォール型のプロセスであるという誤解）を退け、SDD はまず仕様について、次にコードについて反復するものだと説明する。
- 技術的ハーネス（オーケストレーションループ、ツール、コンテキスト管理、メモリ、ガードレール、検証ループ）と、チームが所有する 8 つの仕組みからなる方法論的ハーネスを区別する。前者は一時的でモデルの改善とともに価値が減じるのに対し、後者は時間とともに価値が増すと論じる。実践上の結論は、チームは永続的なハーネスに優先的に投資し、ツールの選定は二次的なものとして扱うべきだというものである。
- 永続的な共有知識（エージェントの各セッションの開始時に読み込まれ、終了時に書き込まれる、意思決定とその根拠のストア）を、ステートレスなセッションの集合をチームとして振る舞わせる仕組みとして特定する。
- それぞれが仕様に対する操作である 5 つの人間–エージェント間インタラクションパターン（ブリーフィング、相談、レビュー、規範のエンコード、オーケストレーション）を提案し、人間の主な仕事がコードを生み出すことから、エージェントがコードを生み出す条件を統制することへと移ると述べる。
- 4 つの利点（一貫性、レビュー負荷の吸収、移転可能性、共有コンテキストの複利的な蓄積）と 5 つのリスク（人材の二極化、文化的な分断、コストの暴騰、仕様のドリフト、プラットフォームロックイン）を予測し、利点は検証済みの知見ではなく予測であることを強調する。
補足
本論文は SDD を、モデル駆動エンジニアリング、振る舞い駆動開発、ドメイン駆動設計といった従来の仕様中心のアプローチと対比して位置づけ、新しいのは仕様の利用そのものではなく、確率的なエージェントを実行メカニズムとし、人間をオーケストレーターおよび検証者として位置づけ直す点にあると論じる。その仕組みのいくつかは、エージェント型ソフトウェアエンジニアリング：基盤となる柱と研究ロードマップ で提案された成果物、すなわち Consultation Request Pack（CRP） や Merge-Readiness Pack（MRP） のマージ準備基準を明示的に採用し、それらを仕様に基づいて位置づけ直している。相談は解決できない条項を引用し、受け入れのエビデンスの各項目は元になった仕様の条項を満たすものとなる。
著者らは、具体例は自らが作成した例示的な構成物であって特定の産業システムの報告ではないこと、中心的な用語は新しく議論の余地があるため、彼らの定義に基づく結果が他に移転できない可能性があること、動機となったエビデンスが Web、SaaS、プラットフォームエンジニアリングに偏っていること、そして SDD は普遍的な処方箋ではなくガバナンスの規律として読むべきであり、要件が本当に未知である探索的な作業にはより軽い規律のほうが適切な場合があることを述べている。