約 4 分で読めます

CI負荷25倍時代のTest Impact Analysis設計

コードを書く速度はもうボトルネックではない——PRのレビューと統合を待つ列が、CIの前で詰まっている。Anthropic自身の開発チームでは、Claudeが本番コードの約8割を書くようになった結果、CIジョブが半年で25倍に増え、既存のテスト実行基盤が音を上げた。エージェント評価のCI/CD統合で品質ゲートを組んでも、ゲート自体が詰まれば意味がない。この記事ではAnthropicが公開したTest Impact Analysis(TIA)再設計の経緯を基に、AIコーディング時代のCI設計を整理する。

なぜAIコーディングはCIを圧迫するのか

Claudeが本番コードの約8割を書く体制で、Anthropicのテスト量は10倍、CIジョブは6か月で25倍に増加した。

コードを書く主体がエンジニアからエージェントに移ると、PRの生成速度は人間のレビュー速度を超える。Anthropicではエンジニア1人あたりの出荷コード量が2021〜2025年平均の8倍に達し、テストスイートの規模は10倍に膨らんだ。すべてのPRで全テストを実行する従来方式は、この成長速度の前では線形にすら間に合わない。コードを書く工程がボトルネックでなくなったことで、次の制約点がCI実行時間そのものに移ったという指摘は、オートスケーリング設計と同じく「成長を前提にアーキテクチャを選ぶ」必要性を示している。

Test Impact Analysisとは何か

Test Impact Analysisは変更差分と実行履歴からPRごとに必要なテストだけを選ぶ仕組みである。

TIAは「listener」と「selector」の2コンポーネントで構成される。listenerはCI実行のたびにテスト結果を記録し、テストごとの実行履歴を蓄積する。selectorはその履歴とパッケージ依存関係から、そのPRの変更に関連するテストだけを選び出す。全テストを毎回流すのではなく、変更の影響範囲に絞ることで、テスト量が増え続けても実行時間を線形に増やさずに済む。エージェントが自己検証のために狭く焦点を絞ったテスト結果を受け取れる点も、エージェントの完了判定設計にそのまま効いてくる。

なぜ一度の修正では収まらなかったのか

延命パッチを3段階重ねた末に状態保持の限界が露呈し、ステートレス設計への刷新に至った。

Anthropicは最初から再設計に踏み切ったわけではない。まずマシンのコア数を倍にする延命策を70日運用し、次にパッケージ単位でlistenerを並列化するシャーディングを29日続けた。それでも追いつかず、1日もたずにサービスを毎日再起動する運用に陥った段階で、アーキテクチャ自体に根本的な限界があると判断された。最終的な再設計では、listenerをステートレスなワーカー群にし、結果をジャーナルに追記するだけの役割に絞った。別のコンシューマーが数秒おきにジャーナルをテストごとの履歴へ集約することで、水平スケールが可能になった。この刷新はエンジニア1人・3週間で完了し、従来の四半期単位の対応より大幅に短縮された。

自社のCI設計にどう活かすか

設計時点で「2四半期以内に負荷25倍」を前提に置き、状態をクリティカルパスから排除すべきである。

Anthropicの教訓は「v0設計の段階で2四半期以内の25倍成長を見込め」という点に集約される。状態を持つプロセスをクリティカルパスに置かないこと、サービスの挙動をAIによる監視が読み取れる形で計装しておくことの2点は、AIエージェントのトレース計装の設計原則とも一致する。ゴールデンデータセットによる回帰テスト設計を既に運用しているチームは、その実行基盤がTIAのような差分ベースの選択に耐えられるかを早い段階で検証しておくとよい。

規模別の留意点(SMB / エンタープライズ)

SMBでは、テスト数が数百件規模のうちは全件実行で十分なことが多く、TIAのような専用基盤を自作する前に、まず/services/ai-ops/で現状のCI実行時間とボトルネックを可視化するところから始めるのが現実的だ。一方、複数チームでAIコーディングを本格運用し始めたエンタープライズでは、テスト量とCIジョブ数の成長曲線を四半期ごとに追跡し、Anthropicが経験した「延命パッチの繰り返し」に陥る前にステートレスな実行基盤へ移行する判断が要る。この規模の刷新はRDEが伴走領域としている。

参考

  • Anthropic「Agentic coding is straining CI. Here's how we scaled test impact analysis at Anthropic」 https://claude.com/blog/agentic-coding-is-straining-ci-heres-how-we-scaled-test-impact-analysis-at-anthropic
  • Anthropic「Demystifying evals for AI agents」 https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

まとめ

AIコーディングが本番コードの大半を書く体制に移行すると、ボトルネックはコード生成からCI実行そのものへ移る。Anthropicの事例が示すのは、延命パッチの積み重ねではなく、状態をクリティカルパスから排除したステートレス設計への刷新が最終的に最短距離だったという点だ。自社のCI基盤がこの成長曲線に耐えられるか診断したい場合は、AI Opsにお問い合わせいただきたい。

関連記事

インフラノイズを消すエージェント評価基盤設計エージェント評価のCI/CD統合——品質ゲートとパイプライン設計ゴールデンデータセットで始めるエージェント回帰テスト設計LLM-as-a-judgeでエージェント品質を自動採点する評価基盤設計