コードを書くのが速くなると、ボトルネックは「執筆 → レビュー → CI」の順に移る。Anthropic では CI ジョブが半年で 25 倍になり、テスト選択サービスに当てた 3 回の応急処置は 70 日・29 日・1 日未満しか持たなかった。手法そのものより、「応急処置の寿命は縮み、全面再設計のコストも縮んだ」という非対称性を読み取る記事です。
エンジニア数はほぼ横ばいのまま、コードもテストも桁で増えた。記事の主張はシンプルで、コードを書くことはもう制約ではない。PR レビューも AI で加速すると、次に圧力がかかるのは CI である、という順番の話です。
背景として、AI がコードを書くと PR の「形」も変わります。Claude は小粒な PR を好むので PR 数が増える。エージェントは夜間・週末も push するので活動量の「床」が上がる。一方で人間が承認する分はバースト的なまま。CI にとっては総量が増え、かつ平準化されないという嫌な組み合わせです。
多くの組織では今も「全 PR で全テストを回す」運用です。これは規模が小さいうちは機能しますが、CI ゲートは長く・高く・信頼できなくなっていきます。TIA（テスト選択）は、変更ごとに「影響を受けそうなテストだけ」を選んで走らせる仕組みで、商用ベンダーも複数あるジャンルです。
記事で見落とせないのは、TIA を単なるコスト削減ではなくエージェントの生産性基盤として位置づけている点です。人間なら「この失敗は自分と無関係」と判断できますが、エージェントにはより多くの文脈と指示が要る。有効なテストの集合を明示的に渡してこそ、エージェントは自己検証と反復ができる——という論理です。
| 部品 | 役割 |
|---|---|
| Listener | すべての CI 実行のテスト結果を記録する |
| Selector | テスト結果の履歴を読み、開かれた各 PR でどのテストを走らせるか決める（過去の成績とパッケージの関連性に基づく） |
両者は「同期している」ことが前提です。ところが CI ジョブが毎秒複数走る規模になると、Listener が PR キューに遅れ始めます。記事の例では Listener の遅れ 20 分＝数万件のテスト更新が Selector に未反映。すると——
2025 年 10 月、サービスは既に悲鳴を上げ、2 日連続でページが飛びました。ここから再設計に至るまでの道のりが記事の本体です。
| # | 時期 | 何をしたか | 持った期間 |
|---|---|---|---|
| 1 | 2025-10 | 大きいマシン：コア数を倍増。効くのは一時的だと最初から分かっていた。所有権が曖昧で誰も新しいインフラを持ちたがらず、CI チームには他に優先事項があった。 | 70 日 |
| 2 | 2026-02 | シャーディング：「単一の書き手」はコードベース全体ではなくパッケージ単位で足りると気づき、パッケージごとにシャード＋ワーカーに分割。コードは Claude が生成。 | 29 日 |
| 3 | 2026-03 | 日次再起動：平日は午後にはメモリ上限に到達。バグは 4 件しか見つからず、アロケータ交換も効かず、負荷下の単一プロセスをプロファイルするのは危険。 | < 1 日 |
パッチ 3 では別の問題も見つかりました。再起動のたびに遅れが蓄積し、1 時間以上遅れた際には大量の結果が Listener に記録されなかった。著者は「未テストのコードが本番に出たわけではない」と明記したうえで、実害は Selector が古いデータで判断し、既に flaky／全面失敗中のテストを無駄に回していたことだと説明しています。
パッチ 2 の頃、著者は社内版の Claude Tag（Slack 上の Claude）でこのサービス監視専用の長期セッションを立てました。Listener の遅れが 50,000 ジョブを超えるたびに Claude が著者に通知し、前回までの文脈を保ったまま「次の一手」の会話を再開する。これを数ヶ月続けたそうです。
負荷が指数関数で増えるとき、「容量を k 倍にするパッチ」が持つ期間は ln(k) / ln(月あたりの成長率) ヶ月です。25 倍/6 ヶ月なら成長率は約 1.71 倍/月。コア倍増（k=2）がどれだけ持つか、動かして確かめてください。
最終的に Claude の助言どおり、テスト選択サービスにインメモリのデータストアを与えました。それまで単一プロセスがメモリ内で担っていた処理の大部分を、外部ストアに逃がしたわけです。
分散構成なので運用コストは上がりますが、不安定な単一プロセスよりスケールもメモリプロファイルも格段に楽になった。ジャーナルのサイズやワーカー数のチューニングは Claude がほぼ自律的に実施し、それまで週ごとに積み上がっていた未処理イベントのバックログはフラットになり、以降安定しているとのことです。
CI ジョブは「エンジニア 1 人あたりのエージェント数」と「PR 承認の自動化度」に応じて指数的に増える。build でも buy でも、2 四半期以内に 25 倍の負荷を前提にする。「過剰設計」という概念は薄れつつあり、少なくとも基準線は大きく上がった。予算が許すなら v0 で知覚スケールの 10〜20 倍を見込んでよい。
計測があれば Claude は漸進的に問題を hill-climb でき、人手より速く確実に直せる。特に「入ってくる CI ジョブ数＝出ていくジョブ数」を常に確認できるようにしておく。
計測とカナリア変更ができないなら、重要サービスを単一インスタンスで動かさない。CI の進化が速すぎて、それ以外のやり方では追いつかない。
手法は古典的、非対称性が新しい。大きいマシン・並列化・再起動・ジャーナル＋ロールアップは、どれも教科書的な手法で、記事自身が「そこは学びではない」と断っています。核は「応急処置の寿命は 1 年前の何分の一かに縮み、逆に全面再設計のコストも何分の一かに縮んだ」という非対称性。つまり「とりあえずパッチで凌ぐ」ことの相対的な合理性が下がった、という主張です。
TIA は「エージェントの自己検証の入力」である。コスト削減として読むと平凡ですが、「エージェントには有効なテスト集合を明示的に渡さないと自己検証できない」と位置づけ直すと、CI の設計がエージェント運用の設計の一部になります。
監視セッションの持続、という運用の型。閾値を超えたら Claude が人を呼び、文脈を持ち越したまま会話を再開する。これは特定の製品に依らず、cron＋メモリファイル＋通知の組み合わせで自作できる型です。
正直な記述を評価したい。「Claude は再設計を勧め続けたが人間が妥協した」「所有権が曖昧だった」「バグは 4 件しか見つからなかった」。技術ブログにしては珍しく、組織側の要因まで書いています。