コーディングボットの規約を書き足すほど守られなくなり、書き足すのをやめた

あらまし

個人会社で開発しているサービスで、役割別に分けた 5 種の自律コーディングボットに変更提案 (PR) を約 4 ヶ月出させてはっきりしたのは、守らせたい規約へ禁止事項を書き足すほど、ボットがかえって規約を守らなくなる、ということでした。この記事は、ボットが起こす違反を規約の文書で縛るのか機械の検査で止めるのか、という守らせ方の設計を、その失敗からたどり直した話です。人間側が監視や自動検査で違反と品質の劣化を検知する仕組みを作り、ボットは検知された問題を直す変更の PR を出す役だけを担う、という分業です。

違反が出るたびに規約の文書へ禁止事項を書き足す対処では、再発が止まりませんでした。この書き足しの対処が効きにくい構造的な要因は、二つ特定できました。違反した PR を閉じても、閉じた理由が次に PR を作るボットへ届かないこと。そして、利用しているボットの公式の仕様では、起票の前に自動で読まれるのはリポジトリルートの規約ファイル一つだけで、細かく分けた役割別のメモは読み込みが保証されないことです。

ただ、この二つを踏まえて禁止事項を必ず読まれる場所へ直書きし、規約を読んだ旨の宣言を必須へ上げても、再発は続きました。規約は数ヶ月で禁止事項が 20 を超え、起票前にボットへ求める自己点検も 20 項目を超えて膨らみました。書き足すほど文書は長くなるのに、違反は減りませんでした。

そこで最後は、起票の時点で文脈を読まずに一意に判定できる違反だけを、機械が検知するゲートへ移しました。機械が指摘するのは 4 種だけです。規約を読んだ旨の宣言が PR の説明に無いこと、PR の差分に規約ファイル自体への変更が混じること、規約ファイルのすでにある行を消してしまうこと、そしてリポジトリ内の文書へ日付だけの見出しを追記することです。

任せた範囲の逸脱や重複した PR、セキュリティ修正の深刻度を実際より重く申告するといった、文脈に依る違反は機械化せず、人間のレビューに残しました。ゲートは自動では PR を閉じず、指摘のコメントと分類の印を付けるにとどめ、閉じる判断は人間に残しています。同じボット群は、マージされて役に立った PR も出し続けました。

購読で読める本文は、失敗した順にたどる作りです。はじめに、約 4 ヶ月の運用のあらすじと、人間側が検知の仕組みを作りボットは直す PR だけを出すという分業の形を示します。続いて、範囲を決めずに依頼して品質チェックが全面的に失敗した最初の事故と、そこから任せる範囲を三つに切り分けた話をたどります。

次に、禁止事項を書き足しても同じ違反が繰り返された経緯と、文書が届かない二つの構造的な要因、それを踏まえた直書きでも再発が続いた話をたどります。そのうえで、起票の時点で指摘する機械ゲートの設計と、機械に任せる違反と人間に残す違反の切り分け、実際に閉じた事例をテストの入力にした実装の進め方を書きます。最後に、数ヶ月ボットと並走して落ち着いた運用と、機械で守る範囲を広げるべきか規約そのものを短く削るべきか、というまだ確かめられていない分岐を残して締めています。

対象読者と持ち帰れるもの

複数の自律コーディングボットに継続して PR を書かせている、あるいはこれから任せようとしている開発者に向けた記事です。

持ち帰れるのは三つです。一つ目は、文書の規約で守らせる対処がどこで限界に達するのかという実測です。二つ目は、その限界を生む構造的な原因です。三つ目は、文脈を読まずに判定できる違反だけを起票の時点で機械が指摘し、文脈に依る判断は人間に残す、という切り分け方です。

この運用でいちばんはっきりしたのは、守らせる規則を積み増すほど、かえって守られにくくなったことでした。だから最後は規則を積み増すのをやめ、守れていない箇所を確実に表に出す方へ設計を寄せています。ここに書くのは一般論ではなく、個人会社で開発しているサービスを約 4 ヶ月動かした運用の一次記録に基づく考察です。