リバースドキュメンテーションエンジニアリングとは、AI コーディングエージェントが拠って立つ契約を持てるように、レガシーソフトウェアから運用仕様を復元する実践である。これは 仕様駆動開発 を逆向きに実行する。人間の意図を、エージェントを新しいコードへと導く成果物に変えるのではなく、既存のコードを、システムがすでに行っていることを記述する成果物に変えるのである。プロンプトからプロセスへ：AI ソフトウェア開発エージェントを支援するフレームワークのプロセス分類法と比較評価 は、これをグリーンフィールドにおける仕様駆動の作業と相補的な対極として提示し、そのサンプルの中でこれを実装しているフレームワークとして Reversa を挙げている。
用法
このアプローチはリバースエンジニアリングや設計復元（design recovery）という確立された伝統に連なるものだが、生成するドキュメントの主な利用者を入れ替えている。それはもはや人間の読み手ではなく、システムを保守し、移行し、進化させる必要のあるエージェントである。レガシーコードは証拠の源として扱われ、この実践が生み出す成果物は、その証拠へのトレーサビリティを、明示的な確信度ラベルおよびギャップラベルとともに備えている。
中心的な役割を担うのはこれらのラベルである。エージェントは欠けている部分をもっともらしい推論で埋めがちであるため、コードから復元された仕様が限定なしに提示されると、その証拠が裏付ける以上に信頼できるものとして読まれかねない。この研究は、このフレームワークが不確実性にラベルを付けることによって、生成された仕様が実際以上に信頼できるように見えることを防ごうとしていると説明している。また同研究は、このアプローチを検証の面では部分的にしか評価しておらず、確信度ラベルとギャップラベルをそれが提供する検証として記録し、それと並ぶテストやゲートを挙げていない。
適用される場面
これが適用されるのは、ブラウンフィールドやレガシーファーストの環境——同研究によれば、現実の環境の多くがそうである——であり、そこでの中心的な問題は、アイデアからコードを生成することではなく、運用上の知識が別途書き留められているのではなくコードの中に埋め込まれているシステムを、エージェントに変更させる前に、その運用上の契約を復元することである。グリーンフィールドの仕様フレームワークが捉えるべき意図が存在することを前提とするのに対し、こちらは代わりに、知識はすでにコードの中に埋め込まれた形で存在しており、それを抽出できることを前提とする。
同研究が特徴づけるその弱点は、スコープの狭さと証拠の薄さである。実装されたこの実践は仕様とコンテキストには強く対応しているが、同研究はそれをロールと実行の面で狭いものとして記録している——唯一の実装をその両方で 0 と採点している——ため、実現されたこのアプローチは、契約は復元するものの、その後に続く作業を組織化することはしない。その一般性が確立されるまでには、複数のシステム、言語、ドメイン、そして既存ドキュメントの整備度合いのさまざまなレベルにわたって、評価をさらに広げていく必要がある。
どの程度確立されたものと見なせるかは、誰が問うかに大きく左右される。同研究はこのアプローチを、長い歴史を持つものとして扱うリバースエンジニアリングと設計復元という確立された伝統の中に位置づけている。その出力を人間ではなくエージェントに向ける点が新しい部分であり、それはここでは単一のフレームワークと 1 本のプレプリントに依拠している。しかもそのプレプリントの著者は、それを評価する研究の著者でもある——この利益相反は同研究自身が申告している。
関連用語
- Reversa — この実践を実装しているフレームワーク
- 仕様駆動開発 — この実践が逆転させている方向
- プロンプトからプロセスへ：AI ソフトウェア開発エージェントを支援するフレームワークのプロセス分類法と比較評価 — 両者を互いに対比して位置づけている比較研究
- 6 次元プロセス分類法 — このアプローチのロールと実行に関する狭い対応範囲が記録されている評価手段