方法論的ハーネスとは、エージェント型ソフトウェアエンジニアリングのための仕様駆動開発：人間–エージェントのチームワークをハーネスする で提唱された 構成概念であり、ソフトウェアチームがコーディングエージェントの振る舞いを統制するための、チームが所有する実践と 成果物の集合を指す。同論文はこれを技術的ハーネス——1 つのセッションで 1 つのエージェントを統制する、モデルを取り巻く ソフトウェア（オーケストレーションループ、ツール、コンテキスト管理、メモリ、ガードレール、検証ループ）——と区別し、 技術的ハーネスだけでは提供できないチームレベルの性質、すなわち再現性、監査可能性、移転可能性、レビュー能力、 協調には、仕様を中心的な成果物とする第二のハーネスが必要だと論じている。
用法
同論文は方法論的ハーネスを、知識・生産・ガバナンスという 3 つの機能のもとにまとめられた 8 つのメカニズムとして 整理し、それぞれについてチームが引き受けるコミットメントを示している。
- コンテキストエンジニアリング: エージェントが作業する情報環境を、開発者ごとの私的な設定としてではなく、 共有されバージョン管理されるチームの資産として構築・維持する。
- 永続的な共有知識: 決定事項、その根拠、セッションの要約、発見事項を蓄えるストアを、すべてのエージェント セッションの開始時に読み、終了時に書き込む。生のトランスクリプトではなく要約と決定を保持し、選択的に取り出し、 どのエージェントやツールが読むかに対して中立である。
- 実行可能な仕様: 仕様はエージェントが消費し、自動チェックで検証できるように書かれる——テスト可能な受け入れ基準、 チェック可能な制約、明示的な決定である。
- N バージョン思考と並列エージェント: 1 つの仕様を複数のエージェントに割り当てて候補を比較することを通常の 作業形態として扱い、各エージェントは Git ワークツリー による専用の作業ツリーで隔離される。
- 規範的な仕様: チームの恒常的な規約や禁止事項を暗黙のままにせず、常に読み込まれるシステム仕様に書き込み、 レビューを経たプルリクエストによって追加する。
- 構造化された相談: エージェントは自ら解決できない、あるいは解決すべきでない決定に直面すると作業を中断し、 問題となっている仕様の条項を引用した範囲限定の依頼を上げ、その回答はその仕様に紐づけて記録される。
- 証拠に裏付けられた受け入れ: 完了の単位は、マージされたプルリクエストではなく、仕様への適合を示す 証拠のバンドルである。
- 段階的な自律性: エージェントに与える自律性は、タスクの種類ごとに、明示的でバージョン管理され見直し可能な チームの決定として調整される。
同論文はこれらを互いに独立したものではなく相互に補強し合うものとして示しており、永続的な共有知識を、他の メカニズムの産物を次のセッション、エージェント、チームメイトへと持ち越させることでループを閉じるメカニズムと 位置づけている。また、エージェントがすべてのセッションの開始時に読み込むルールファイルという 1 つの成果物が、 システム仕様として、エージェントへのフィードフォワードの指針として、そしてチームの規範の担い手として、同時に 機能すると論じている。
適用される場面
この構成概念が重要になるのは、エージェントにチーム規模でゴールレベルの作業が委任されるようになり、個人レベルの 効率向上がレビュー・検証・協調のボトルネックに突き当たる段階だと論じられている。各メカニズムは仕様を基準に定義 されているため、チームが仕様を人間とエージェントの間の正式な契約とすることにコミットしていることが前提となる。 その中心的な主張は耐久性の非対称性にある。技術的ハーネスは一時的なもので、モデルの改善や機能のモデルへの ネイティブ化に伴って価値が減じていくのに対し、方法論的ハーネスはチームの意図、規範、蓄積された決定を符号化する ため時間とともに価値を増すとされ、著者らはここから、チームは方法論的ハーネスに優先的に投資し、ツールの選定は 二次的なものとして扱うべきだと結論づけている。同論文は、例えば規範を符号化したり決定を永続化したりせずに機能仕様 だけを書くといった断片的な採用では、規律のコストの大半を払いながら便益の一部しか得られないと警告しており、 リスクとして仕様のドリフトとコストの増大を挙げている。
これは 1 つの研究グループによる提案であり、主にグレー文献に依拠した多声的文献レビュー（multivocal literature review）から導かれたものである。著者らは、個々のメカニズムのいくつかは実務家の文章の中ですでに個別に現れて おり、自分たちの貢献はそれらを仕様を軸に整理した点にあると述べている。彼らはこのフレームワークを検証済みの モデルではなく反証可能な仮説として位置づけており、予測される便益は未検証だとしている。
関連用語
エージェントハーネス、ハーネスエンジニアリング、仕様駆動開発、 コンテキストエンジニアリング、Consultation Request Pack（CRP）、 Merge-Readiness Pack（MRP）