Anthropic、CI ジョブが半年で25倍になった経緯を公開 — エージェントコーディングの次のボトルネックは CI

要約

Anthropic は 2026-09-14、社内のテスト選択サービス（test impact analysis）を作り直した経緯を公開しました。著者は Sachin Malhotra。製品リリースではなく、エンジニアリング実践の公開です。

前提として示された数字が重いので、先に並べます。

• Anthropic のエンジニアは、2021〜2025 年比で四半期あたり8倍のコードを出荷している
• そのコードの80%を Claude が書いている。 PR のレビューと承認にも Claude が大きく関与する
• テスト総数は10倍に増えた（エンジニア数の増加は小幅）
• 結果、CI ジョブは半年で25倍になった

公式の言い方が的確です。「コードを書くことはもうボトルネックではない。PR レビューが速くなると、次に CI が圧迫される。」

ここが本記事の価値です。 エージェントコーディングの導入効果は普通「開発が速くなった」で語られますが、速くなった分の負荷がどこへ移動するかは、あまり語られません。 Anthropic の答えは CI です。しかも25倍という桁で来ます。

同社のテスト選択サービスは、**listener（全 CI 実行の結果を記録する）と selector（履歴とパッケージ関連性から、どの PR でどのテストを走らせるか決める）**の2つで構成されています。毎秒複数の CI ジョブが走る状況では listener が PR キューに追いつかなくなり、20分の遅延が数万件のテスト更新の未反映につながりました。

遅延が引き起こす具体的な壊れ方も書かれています。悪い変更がマージされると、他の全員でテストが落ちて無駄な調査が発生する。依存先が flaky になると、flaky な赤がマージを止める。テストが修正・追加されても listener が追いつくまで走らない（＝リグレッションを見逃す）。

何が変わったか

• 応急処置1: コア数を倍にする → 70日もった
• 応急処置2: パッケージ単位のシャーディング（テストごとではなくパッケージごとに単一 writer を置く） → 29日もった
• 応急処置3: 日次再起動 → 1日もたなかった。加えて、再起動のたびにサービスが徐々に遅れていき、1時間以上遅れると大量のジョブ結果が記録されなかった
• 再設計: listener をステートレス化し、in-memory データストアのジャーナルへ追記する形へ。別プロセスが数秒ごとにテスト単位の履歴へ畳み込み、selector はそこを引く。水平スケール可能になった（運用コストは上がる）
• 公式の結論: 「2四半期後に25倍の負荷が来ると仮定せよ」「初期設計では体感スケールの10〜20倍を見込め（予算が許す限り）」
• 応急処置の期間中、著者は社内版 Claude Tag で監視用の長時間セッションを走らせ、listener の遅延が5万ジョブを超えると通知を受ける運用にしていた

業務インパクト（一般企業向け）

この記事のいちばん実務的な指摘は、スケーリング手法の話ではありません。非対称性の話です。

公式が明言しています。個々の手法（大きいマシン、並列化、再起動）は一般的なもので、そこが要点ではない。要点は、同じ手法で買える時間が1年前の数分の一になっている一方、サービス全体の作り直しに必要な時間も数分の一になっているということです。

この非対称性が、意思決定の基準を変えます。

従来、「作り直し」は最後の手段でした。工数が大きく、リスクも高いからです。だから応急処置を積む判断は合理的でした。AI がコードを書くようになると、作り直しのコストが下がります。同時に、負荷の増え方が速くなるので応急処置の寿命も短くなります。 結果、「とりあえず凌ぐ」の期待値が下がり、「作り直す」の期待値が上がります。

Anthropic は 70日 → 29日 → 1日未満という形で、この変化を身体で受けています。3回やって、3回とも寿命が縮んだ。 これは運が悪かったのではなく、指数関数の上で線形の手を打っていたからです。

自社で確認すべきことは3つあります。

1. CI ジョブ数の推移をグラフにする。 半年前と比べて何倍か。エージェント導入前後で傾きが変わっていないかを見てください。 変わっていれば、それは今後も続きます。
2. テスト選択をしているか。 全変更で全テストを走らせている組織は多いはずです。公式も「多くの同業はそうしている」と書いています。これはある規模までは正しく、超えると CI ゲートが長く・高く・信頼されないものになります。 信頼されない CI は無視されるようになり、そこからは品質ゲートとして機能しません。
3. 応急処置の寿命を記録する。 「前回の対処は何日もったか」を残しておくと、次に作り直しを決める判断が感覚論ではなくなります。 70日 → 29日 → 1日未満という並びは、それ自体が意思決定の材料でした。

もう1点、エージェント特有の論点が書かれています。 公式は **「人間はどのテスト失敗が自分に関係ないか判断できるが、エージェントにはより多くの文脈と指示が必要になる。妥当なテストの集合を渡されたとき、エージェントは自己検証と反復をうまくやれる」**と述べています。

つまり、テスト選択の精度は、人間相手より エージェント相手のほうが重要です。 無関係な赤を渡されたエージェントは、それを直そうとして時間を溶かします。**「CI の出力の質が、エージェントの生産性を直接決める」**という論点は、ハーネス設計の観点で押さえておく価値があります。

副業・個人活用視点

個人開発の規模では25倍のような話は起きません。それでも、この記事から持ち帰れるものが2つあります。

1つ目は、自分のリポジトリで同じ兆候が出ているかを見ることです。

Claude Code や Codex を日常的に使っていると、PR の数とテストの数が、自分が手で書いていた頃の感覚を超えて増えます。 個人でも、CI の待ち時間が長くなって「とりあえずローカルで確認して push する」に流れているなら、それは同じ現象の小さい版です。CI が信頼されなくなる入口はここです。

対処は組織と同じで、全テストを毎回走らせるのをやめることです。個人でも、変更したパッケージに関係するテストだけ走らせる仕組みは作れます。GitHub Actions のパス フィルタで十分な場合も多いので、大掛かりなサービスは要りません。

2つ目は、これが受託・コンサルの提案材料として使えることです。

「AI で開発を速くする」という提案の次に来る問いは、必ず「それで本当に速くなるのか」です。 ここで Anthropic の事例が効きます。コードを書く速度は上がる。ただし負荷は CI に移動する。だから CI の設計も一緒に見る必要がある。 この構造を示せると、提案が「ツール導入」から「プロセス設計」に格上げされます。単価が変わる話です。

加えて、公式が出している「体感スケールの10〜20倍を見込め」という数字は、そのまま設計レビューの基準に使えます。 根拠を自分で作らなくても、一次情報として引用できます。顧客に説明するとき、出典のある数字は強いです。

最後に、応急処置の記録を残す習慣は、個人でも効きます。 「この対処は何日もったか」を書いておくだけで、同じ場所を3回直していることに気づけます。 3回目で作り直しを決められるかどうかは、記録があるかどうかで決まります。Anthropic も、記録があったから決めています。