Anthropic社内では、エンジニア1人あたりのコード出荷量が8倍になり、CIジョブは6か月で25倍に膨らんだ。壊れたのはAIではなく、その後ろにある「どのテストを走らせるか選ぶ仕組み」だった。3回の応急処置と最後の再設計を追い、個人開発者が自分の環境で「次に詰まる場所」を先読みする方法を整理する。
Anthropicの事例の要点（応急処置は70日→29日→1日未満と、効く期間が縮んでいった）と、そこから取り出せる2つの教訓。さらに、自分のパイプラインで「単独で全部を抱えている場所」を洗い出す4つの問い。
Claude公式ブログによると、Anthropic社内ではエンジニア1人あたりの四半期の出荷コード量が、2021〜2025年と比べて8倍になった。そのコードの約80%はClaudeが書いている。テストの総数は10倍に増え、結果としてCIジョブは6か月で25倍になった。
ここで詰まったのは、変更に関係するテストだけを選んで走らせる「test impact analysis」の基盤だった。テスト結果を受け取って履歴を更新するリスナーが、1つのプロセスにすべての状態を持つ作りだったのだ。コードを書く速度が上がれば、テストの結果が流れ込む量も同じ勢いで増える。書く側の自動化は、検証する側の負荷を一緒に押し上げる。
日付は元記事の記載（10月・2月・3月）による。
サービスを動かすコアを2倍にした。時間稼ぎだと分かった上での処置で、約70日もった。
結果を正しい順に処理するのに必要なのは、全体で1人の書き手ではなく、パッケージごとに1人の書き手だった、という気づきによる分割。これは約29日。
メモリ上限に午後に達するため、サービスを毎日再起動した。得られた猶予は1日未満。ここで、足し算の対処は限界だと確定した。
1つ目は「資源を足す」、2つ目は「分ける」、3つ目は「リセットする」。どれも設計は変えていない。設計を変えない限り、負荷が伸びる速度のほうが対処の効く期間より速くなる。
最終形は3つの部品に分かれた。
元記事は、この作業を1人のエンジニアが3週間で終えたとしている。1年前なら四半期かかる規模の仕事だったという。AIは負荷を25倍にした側であると同時に、再設計のコストを大きく下げた側でもある、という二面性が読み取れる。
教訓は2つ。最初の設計の時点でAIによる10〜20倍の負荷増を見込むこと。そして、単独のプロセスに状態を抱えさせないこと。元記事は「2四半期以内に25倍の負荷になる前提で設計せよ」とまとめている。
個人開発でCIジョブが25倍になることはまずない。しかし「AIに作業を任せた結果、想定より1桁早く、自分の検品や配信の仕組みのほうが詰まる」という構造は同じだ。制作が速くなるほど、確認・公開・集計といった後ろ側が相対的にボトルネックになる。自分のパイプラインを次の4つで点検してみる。
とくに「在庫の数え方」のような小さな集計でも、数える仕組みが1か所の古い記録に依存していると、量が増えた途端に過大・過少のカウントが起きる。どの集計が「1つの書き手」に頼っているかを洗い出す価値はある。
AIツールの信頼境界については別の角度でも書いている。GitHub CopilotをMitMプロキシ越しに覗いたら、.envの秘密が漏れていたや、Atlassian Rovoのデータ持ち出し実例とあわせて読むと、「AIで速くなった後ろ側で何が壊れるか」という視点が揃う。
出典: Claude Blog「Agentic coding is straining CI: here's how we scaled test impact analysis at Anthropic」（claude.com）。数値と時期は元記事の記載による。第4章は筆者の考察。