ガバナンス変換とは、AI コーディングエージェントが繰り返し生み出す失敗を、後続のエージェント作業を制約する明示的かつ永続的なガバナンスへと変えていくプロセスである。この用語は Davis らが 安価なコード、高価な判断：統制可能なエージェント型ソフトウェアエンジニアリングに関する事例研究 で提唱したもので、同論文が示す中範囲理論の候補の中心的メカニズムを指す。エージェントによる開発速度（agentic velocity）が構造的な失敗クラスを露わにし、人間がそれを孤立した欠陥ではなく構造的な問題として解釈し、その解釈がエンジニアリング環境に組み込まれる。その結果、後続のエージェントはより狭く、より明示的な行動空間を引き継ぐことになる。論文はこのループを「失敗 → ガバナンス」と略記し、終わりのないものとして描いている。速度が上がるにつれ、それまでのガバナンスが扱っていなかった失敗クラスが次々と表面化し続けるからである。
用法
論文はこの用語を、既存のガバナンス中心の議論に帰せられる*事前的（ex-ante）ガバナンスと対置している。事前的ガバナンスとは、実行時のガードレールに落とし込まれた規制のように、すでに分かっている義務から前もって演繹される統制である。ガバナンス変換はそれを補完する事後的（ex-post）*な軸、つまりエージェント作業の中で発見された失敗から統制を帰納する軸として提示されている。著者らは、事前的な統制は必要ではあるが十分ではなく、両方が必要であることが分かったと明言している。
著者らは 5 段階のプロセスを説明している。速度が失敗を露わにする。アーキテクトが局所的な欠陥と、繰り返し現れる構造的な失敗クラスとを見分ける。ガバナンスが、確率的に（エージェントハーネスとして）または決定論的に（型システムとして）組み込まれる。後続のエージェント作業がそれによって制約される。そしてガバナビリティが複利的に高まり、変換が繰り返されるほど、将来のエージェント作業を受け止める環境の能力が増していく。事例からは 2 つの具体例が示されている。1 つ目では、コードベースの成長に伴ってエージェントによるアーキテクチャ監査がスケールしなくなり、その対応はアーキテクチャ的なものだった。監査ゾーンを型付きのコンポーネントカタログとして具体化し、エージェントを介した監査を決定論的な強制へと変換したのである。2 つ目では、エージェントが知らされていなかった制約を繰り返し破り、その対応は統制だった。ディスパッチ時の制約スライシングによって、変更対象のファイルに適用されるルールを、エージェントがコードを編集する前にそのブリーフへ注入したのである。
適用される場面
このプロセスは、失敗が繰り返し起こり、まとまって現れるほど速くエージェントが変更を生み出していることを前提としている。論文は、エージェントによる開発速度のために、従来であれば時間的に大きく離れて現れたはずの関連する失敗が立て続けに表面化したこと、そしてこの近接性こそがアーキテクトにアーキテクチャ上の欠落を認識させたことを観察している。また、人間が行動を起こせる立場にあることも前提としている。論文は権限を調整変数として挙げ、権限がチーム、オーナー、レビュー委員会、デプロイプロセスに分散している場合、同じ失敗シグナルが共有されたガバナンスではなく局所的なパッチしか生まないことがあると論じている。2 つ目の調整変数である*能力適合（capability-fit）*は、結果がエージェントの能力と人間の判断との適合度に左右されるとするものである。
典型的な失敗は、失敗を、欠けている抽象化や仕様が不十分なインターフェースの証拠としてではなく、局所的な欠陥として読み取ってパッチを当ててしまうことである。論文は、決定的な判断とは、エージェントが生み出した変更が受け入れ可能かどうかだけではなく、その失敗がガバナンスの欠落を示しているかどうかであると位置づけている。そしてある 1 つのインシデントから導かれたエンジニアリング上の心構えとして、エンジニアは「自分こそが問題だと想定せよ」と述べ、困難の所在をモデルの能力から、自分自身が問題を枠づけ、分解し、制約する能力へと移している。
この用語は確立した、あるいは広く合意されたものではない。2026 年の単一の論文で、12 週間・1 人の単一事例研究を根拠として提唱されたものであり、著者らはこれを理論検証ではなく理論構築として明示的に位置づけ、普及度を主張するのではなく、他者が検証するための反証可能な命題を提示している。
関連用語
統制されたエンジニアリング環境, エージェント型ソフトウェアエンジニアリングのプロセスモデル, ガードレール, ハーネスエンジニアリング