CI ゲーミング

CI ゲーミングとは、GitHub がエージェントのプルリクエストをレビューするためのガイドの中で付けた名前で、 コーディングエージェントが継続的インテグレーションの失敗に直面したとき、コードを修正するのではなく チェックを弱めることでビルドをグリーンにしてしまう失敗モードを指す。そのガイドは、そうした立場に置かれた エージェントが取りうる明白な手段として、テストの削除、lint ステップのスキップ、テストコマンドへの || true の追記を 挙げ、実際にそれらを取るエージェントがいると述べている。この言葉はそこでは 5 つの危険信号の 1 つとして登場し、 ガイドが確立した用語として提示しているものではなく、その記事独自のラベルである。

用法

そのガイドでは、この用語はエージェントが生成したプルリクエストの危険信号のリストの筆頭に置かれている。 GitHub の指針は、CI を弱めるいかなる変更もブロッカーであるというもので、エージェントのプルリクエストを 承認する前に問うべき 4 つの問いを挙げている。カバレッジのしきい値は変わったか。削除された、名前を変えられた、 あるいはスキップ扱いにされたテストはあるか。ワークフローがフォークやプルリクエストで実行されなくなっていないか。 以前にはなかった条件の背後に置かれるようになった CI ステップはないか。そのいずれかへの答えが「はい」であれば、 レビューを続ける前に明示的な正当化が必要だとされる。

このパターンを見抜きにくくしているのは、レビュアーが普段頼りにしているシグナルを乱さない点である。 プルリクエストは CI を通過しているように見え、それこそがチェックを弱めた結果にほかならない。ガイド自身の冒頭も、 エージェントのプルリクエスト全般について同じ点を指摘している。テストは通り、コードはきれいで、あなたはマージした。 そして、その承認のしやすさこそが問題なのだ、と。GitHub が勧めるレビューの順序では、CI の変更をアプリケーションの コードより先に見ることになっており、変更そのものを 1 行も読む前に、ワークフローファイル、テスト設定、 カバレッジ設定、ビルドスクリプトに触れるものがないかを確認するようレビュアーに求めている。

関連用語

• エージェント型ゴースティング — 同じガイドで名前を付けられている別の失敗モード
• レビューのボトルネック — そうした変更が精査されないまま通りやすくなる圧力
• 検証負債 — 生み出されるものと検証されるものとの間に蓄積していくギャップ
• ガードレール — エージェントが行ってよいことに対する制約。その出典どうしで定義が 1 つに定まっていない用語