本論文は、仕様駆動開発を多段階のエージェント型コーディングの脆さに対する有望な対応策と捉えたうえで、ワークフローを構造化するだけでは十分ではないと論じる。著者らは残る失敗モードを コンテキスト盲目 と名付けている。エージェントの中間成果物は内部的には一貫していても、実際に存在するリポジトリとは整合しないことがあり、その症状には存在しない API への参照、存在しないファイルパスの提案、ローカルなアーキテクチャ上またはスタイル上の規約への違反などが含まれる。これらのエラーは実装やテスト実行の段階になって遅れて表面化するため、エージェントは後戻りして以前の成果物を修正することになり、問題が段階をまたいで増幅していく。
これに対して提案されたシステムである Spec Kit Agents は、段階的な Specify → Plan → Tasks → Implement のワークフローを、著者らがコンテキスト・グラウンディング層と呼ぶもので拡張する。この層は、トレースを監査可能に保ち、ツールへのアクセスを選択的に付与できるよう、あえてコアとなるエージェントのプロンプトの外側に配置されている。探索フック（discovery hook）は各フェーズの前に読み取り専用のプローバーとして実行され、リポジトリ検査ツールを用いてコードベースに関するエビデンスを収集し、プロジェクト固有の規約、既存の API、関連するモジュールを明らかにする。検証フック（validation hook）は各フェーズの後に実行される。前段の成果物に対しては、計画で参照されたファイルパスが存在するか、必要なライブラリが存在するかといった構造的・参照的な制約をチェックし、実装後にはユニットテストやリンターなどのリポジトリのチェックを実行する。パイプラインは 2 つのロールを対象とするステートマシンとしてオーケストレーションされる。要件の明確化と優先順位付けを担い、リポジトリの分析とバージョン管理の検査に制限されたプロダクトマネージャーエージェントと、ファイルの編集とリポジトリのコマンド実行が許可された開発者エージェントである。
評価では、5 つのオープンソースリポジトリにわたる 32 の機能タスクについて計 128 回の実行を行い、各タスクを 4 つの構成で実行している。直接実装に進む Baseline、その直接のフローにフックを追加した Augmented、段階的ワークフロー全体を実行する Full、Full にフックを追加した Full-Augmented である。生成と評価は分離されている。エージェントは MiniMax-M2.5 をバックエンドとする Anthropic 互換エンドポイントにルーティングされた Claude Code CLI を通じて実行され、Claude Opus 4.6 が独立した審査者として、完全性、正確性、スタイル、保守性にわたって出力を 1〜5 のスケールで採点する。また、同じ評価基準を用いた小規模な盲検の人間によるレビューが一部のサブセットで実施されている。
要点
- コンテキスト盲目を、段階的な仕様駆動ワークフローを採用しても残る失敗モードとして位置づけ、グラウンディングと検証を、生成エージェントの軌跡内の振る舞いとしてではなく、明示的なワークフロー操作にすることで対処すべきだと論じる。著者らは、軌跡内の振る舞いとして扱うとグラウンディングがプロンプト設計やコンテキストウィンドウのノイズに左右されやすくなると考えている。
- より長い予算枠のワークフロー群では Full-Augmented が最も高い品質を達成し、評価の総合スコアを 3.51 から 3.66 に改善したと報告している。著者らはこの差を、完了したタスクの対応のあるサブセットに対する Wilcoxon 符号順位検定において p < 0.05 で統計的に有意だと報告している。
- リポジトリレベルのテスト互換性はすべての構成で 99.7〜100% を維持したと報告しており、著者らはこれを、品質の向上が既存のプロジェクトの振る舞いを壊す代償として得られたものではないことを示すと解釈している。
- 部分的な 2 つのバリアントがいずれも Full を上回った（検証のみで 3.57、探索のみで 3.53）一方、両者を組み合わせた設計が 3.66 で最も高かったというアブレーションを報告しており、著者らはこれを 2 つのコンポーネントが補完的であることのエビデンスと捉えている。
- フックを有効にした場合の SWE-bench Lite での Pass@1 が 58.2% で、フックなしの同じフレームワークの 56.5% を上回ったと報告している。また、すべての実験でベースモデルとして MiniMax-M2.5 を使用したものの、オーケストレーションフレームワーク自体はモデルに依存しないと述べている。
- その利点を、平均スコアの劇的な向上ではなく、増幅していくコンテキストエラーの早期検出と防止として特徴づけている。また、フックによるオーバーヘッドは短い予算枠の群ではわずかだが、長い予算枠の群ではより大きなコストになると報告しており、このアプローチはリスクや複雑性の高いタスクに最も適しているとしている。
補足
著者らは、自らの貢献を 2 つの軸で先行研究と比較している。ツール拡張によるグラウンディングに対しては、探索フックをベストエフォートの検索ではなくフェーズ単位のエビデンス収集と位置づけ、それによってグラウンディングがより再現可能かつ検査可能になり、メインエージェントの生成との結合も弱まると論じる。検証に関する研究に対しては、検証のタイミングと対象の両方で異なると述べている。すなわち、実装後に検証を集中させるのではなくコード生成の前に中間成果物をチェックし、一方で実装後の実行可能なチェックは最終ゲートとして維持する。
本論文は、拡張による改善が SWE-bench Lite のリポジトリ群全体で一様ではないと報告している。著者らは、失敗がユニットテストの対象となっているテスト近傍のコードパスと密接に結びついている場合には改善が大きく、失敗がローカルなユニットテストでは弱くしか露見しない、より深いアプリケーションやライブラリのロジックに起因するリポジトリでは改善の信頼性が低いことを観察している。そして、利用可能なテストがエッジケースの条件を十分に規定していない場合、フックが不完全なシグナルに依拠してしまう可能性があると指摘している。著者らはこれを、テストが根本的な欠陥を直接実行する場合に拡張が最も役立つとまとめている。
本論文には妥当性への脅威（threats to validity）の節がなく、セットアップの限界のいくつかは本文中で付随的に述べられているにとどまる。人間向けの計画レビューのチェックポイントは自動承認されており、時間予算を超えた実行は打ち切られて失敗として扱われ、レイテンシは予算枠の群をまたいでではなく各群の中でのみ比較されている。