プログラミングエージェントがCIをボトルネックにした；ビルドパイプラインの高速化だけでは不十分

プログラミングエージェントの利用拡大に伴い、継続的インテグレーション（CI）が新たなボトルネックになっている。この結論は、単一のツールによる発表ではなく、9月にAnthropic、Linear、Depotのエンジニアリングチームが紹介した経験に基づいている。Anthropicでは6か月間でCIジョブの量が25倍に増加し、一方で同社のエンジニアは、2021年から2025年の間に出荷していた量の約8倍のコードを、四半期ごとに出荷するようになった。Linearでは、テストスイートの規模が1月時点のほぼ4倍に近づき、現在ではエージェントがテストの大半を記述している。

Anthropicは、変更によって影響を受ける可能性が高いテストだけを実行するためにテスト影響分析を導入し、Linearはパイプラインをほぼ全面的に再設計した。これらの対策は待ち時間を短縮するが、問題の一つの層、つまりリポジトリ検査の速度だけに対処している。

なぜCIの速度だけでは不十分になったのか？

CIは歴史的に人間の作業パターンに合わせて設計されてきた。開発者は週に限られた数のマージリクエストを作成し、その後、別の作業に移りながらパイプラインの結果を待つ。しかしエージェントはコード、テスト、マージリクエストを並行して作成できるため、CI処理の数が乗算的に増加する。本稿は、CIランナーを販売する企業Blacksmithが、実行するジョブ数について週5%から10%の成長を観測したと指摘している。

2つ目の問題は、検証の位置である。エージェントは変更を記述し、マージリクエストを作成した後で結果を待つ。結果が20分後に届くと、その時点でタスクのコンテキストを失っている可能性があり、問題が1つ発生するたびに新たな待機サイクルが生じる。

リポジトリはシステムではない

独立したアプリケーションでは、リポジトリのテストがシステムの挙動に近い像を示すことがある。しかしクラウドネイティブ環境では、リポジトリは数十のサービスを含む可能性があるシステム全体の一つのサービスにすぎず、システムの残りの部分は通常、モックインターフェースやテストデータによって表現される。

そのため、ある変更が単体テストに成功し、CIを通過し、分離された環境内で動作した後、サービス境界を越える最初の実際のリクエストで失敗する可能性がある。例としては、別のサービスが依存するフィールド名の変更、連鎖的な再試行を引き起こすタイムアウトの短縮、テスト環境でテーブルのロックを引き起こすスキーマ変更、または実際に利用するサービスから呼び出された場合に異なる動作をするエンドポイントなどがある。

本稿は、DevOps Research and Assessment（DORA）のデータを引用している。同データは、AIの導入拡大がソフトウェアデリバリーの頻度の上昇と、デリバリーの不安定化の両方に結び付いているとしている。つまり、コードをより速く生成することは、より良い検証を保証しない。

実際には何が変わるのか？

提案されている解決策は、CIを廃止したりエージェントを遅くしたりすることではなく、エージェントの作業ループ内のより早い段階に検証の一部を移し、リポジトリのコピーだけでなく実際のシステムに対して変更をテストすることである。Cursorなどのツールは分離されたクラウド環境を利用しており、Cursorがマージするマージリクエストの30%以上は、この方法で動作するエージェントから来ている。GitHub Copilot cloud agent、Codex、Devin、Greptileなど、他のツールも一時的な環境内でコードを実行するさまざまな形態を提供している。

しかし、これらの環境には通常、ブランチとその設定、そして初期化スクリプトでインストールできるものは含まれるが、他のサービス、実際のメッセージの一覧、本番データに似たデータベースは含まれない。そのため本稿は、ループは閉じられているものの、間違った対象の周囲で閉じられている可能性があると見ている。

共有環境と統制された検証

本稿は、Kubernetesクラスター内でサービスの安定した共有コピーを稼働させ、変更されたサービスだけをデプロイする軽量なテスト環境を作成することを提案している。タグ付けされたリクエストはこのサービスにルーティングされ、残りの経路は安定した共有コピーに接続する。これにより、エージェントごとにシステム全体を複製する代わりに、多数のエージェントが環境を共有できる。本稿は、環境のコストが単一のコンテナのコストに近づく可能性があり、起動にかかる時間は数秒だと見積もっているが、原文は、これらの見積もりをすべての環境で裏付ける独立した測定値を提示していない。

環境だけでは不十分である。プラットフォームチームは、送信するリクエスト、収集するログ、証明すべき契約を定める承認済みの手順を必要とする。また、テストが触れたサービスとその結果を記録し、監査ツールやマージゲートから記録を読み取れるようにすべきである。筆者は、共有クラスター内でエージェントが安全でない操作を実行するのを防ぐために、ガバナンスが不可欠だと強調している。

certi.newsの観点では、実際の変化はCIを単に高速化することではなく、検証の「成功」が何を意味すべきかを再定義することである。エージェントがより速いペースで生成する分散システムにおいて、リポジトリのテストは依然として重要だが、それだけでは不十分である。コスト、分離、データセキュリティ、検証精度の測定に関する問題は未解決のままであり、また本稿は確立された標準や特定の製品ではなく、分析的な主張を提示するものである。