Anthropic の CI ジョブは6か月で25倍になった。警告は、各対策が効かなくなるまでの速さに表れていた
By Surya Pratap
2026年9月16日
12 分で読めます
AI とテクノロジー
2026年9月16日
12 分で読めます
対策の半減期Hover to exploreAnthropic は継続的インテグレーションの数値を 2026年9月14日 に公開した。どのテストを実行するかを判断するサービスの作り直しについて、Sachin Malhotra が書いたエンジニアリング記事である。見出しの数字は速く広まったし、それだけの価値がある。だが、この記事で最も有用なのは、ほとんど誰も繰り返さなかった細部のほうだ。
内側から測った、エージェント型コーディングの6か月
顧客事例ではなく、Anthropic 自身のエンジニアリング組織
個別にではなく、まとめて読んでほしい。興味深いのは単一の倍率ではなく、8倍のコードが10倍のテストと 25倍 の CI ジョブを生んだという関係のほうだ。負荷はコードに比例して増えたのではない。コード × テスト × 「これはまだグリーンか」と誰かが確認する回数、に比例して増えた。
Malhotra の言い回しは、通常の要約より正確なので、そのまま引用する価値がある。
コードを書くことはもはや制約ではない。そして PR レビューが加速すると、今度は CI が圧力を感じ始める。
これはスローガンではなく、順序である。3つの工程が順番に並ぶ。書く、レビューする、検証する。エージェント型コーディングが最初の制約を取り除いた。レビューの高速化が2つ目を取り除いた。どちらも処理能力を生み出したわけではない — 列の次にあって余裕のないものへ、待ち行列を移しただけだ。
これこそ、記事中のどの数字よりも先に創業者に持ち帰ってほしい点である。ボトルネックを取り除いてもスループットは生まれない。生まれるのは、1つ下流にある新しいボトルネックだ。それは前のものより速く到来し、たいていは誰も2年間見ていないシステムに現れる。
たいていの小規模チームにとって、「コードを書く」の次に来る工程は、レビュー、CI、ステージング環境、プレビューデプロイ、そして最後に — 静かに、そして最も高くつく形で — 出荷されたものを理解しなければならない人間である。
Anthropic は test impact analysis サービスを作り直す前に、3回パッチを当てている。どのパッチも筋の通ったものだった。それぞれがもった期間は次のとおりだ。
70、29、1。
個々の判断に誤りはない。サービスが遅ければコアを増やすのは正しい。単一の worker が飽和すればシャーディングするのは正しい。遅延が溜まるサービスを再起動するのは、火曜日にごく普通にやることだ。どの対策も、目の前の症状に対して釣り合っていた。
失敗だったのは、対策と対策の間隔 をそれ自体のシグナルとして誰も測っていなかったことであり、その間隔は毎回およそ半分に縮んでいた。
真似すべき診断法
同じシステムへの対策が、回を追うごとに前回より短い時間しか稼げなくなっているなら、指数的な負荷に線形の処方を当てているということであり、残り滑走路は体感より短い。絶対値は今日がどれだけ悪いかを教える。その比率は、あとどれだけ時間があるかを教える。 70日もったパッチの次に29日もったパッチが来たなら、それは2件のインシデントではない。データ点が2つある1本のトレンドであり、3点目はすでに予測できる。
サービスは2つの半分からなっていた。すべての CI 実行の全テスト結果を記録する listener と、ある pull request に実際に必要なテストを判断する selector である。
制約は、listener が singleton だったことだ。単一の書き手がテストごとの累積履歴を維持する必要があり、水平方向にスケールできない。打てる手は、より大きなマシン、次にマシンの分割、次にマシンの再起動しかなかった。3回のパッチは想像力の欠如ではない。そのアーキテクチャが許す選択肢の全部だったのである。
再設計 — 3週間のプロジェクト — は、状態をプロセスの外に出すことで関心を分離した。
singleton を置き換えたもの
状態を抱えた worker ではなく、共有された状態の上に載るステートレスな worker
切り替え後、未処理のまま滞留する結果イベント数は 横ばい にとどまった。それ以前は週を追うごとに増えていた。この平らな線こそが本当の成果物である。速くなったのではなく — 積み上がらなくなった のであり、これは別の性質であり、次の25倍を生き延びる唯一の性質だ。
Malhotra の推奨は、初期システムを 想定規模の10〜20倍、予算が許す範囲で 設計し、AI 由来の負荷が2四半期で25倍に達しうると想定せよ、というものだ。
最後の条件節を真に受けてほしい — 予算が許す範囲で はこの文で実際に働いている。Anthropic が語っているのは、自社が売る当のモデルがコードを書いているフロンティアラボの、内部インフラである。シード段階のチームが「20倍で作れ」を字義どおりに真似れば、まだ欲しがる人が一人も見つかっていないプロダクトを過剰設計することになる。その失敗様式は、CI の遅延よりはるかに多くのスタートアップを殺してきた。
持ち帰れる版は、もっと狭く、もっと安い。
記事に挙がっている他の教訓はきれいに一般化でき、費用もかからない。クリティカルパスを singleton にしない、エージェントが自律的に調査できるようサービスを計測可能にする、そして待ち行列に入る量と出る量が一致することを確認する。最後のものは、人間が古さに気づくより先にシステムの遅れを検知する方法である。
Anthropic が公開したのはジョブ数である。そのジョブがいくらかかるかは公開していない。そして創業者にとって、この欠落こそが話の全部だ。なぜなら CI は従量課金だから である。
CI ジョブが25倍になるということは、ランナー料金に対する計算時間が25倍になるということであり、それを緩和するのはテスト選択がどれだけうまく働くかだけ — そしてそれこそ、倒れかけていた当のサービスである。チームがエージェント型コーディングを導入して他に何もしなければ、観測される流れはこうなる。速度が上がり、皆が喜び、約2か月後に誰かが、インフラ請求書の CI の行がいつのまにか最大級の項目になっているのはなぜかと尋ねる。
これはコンテキスト税と同じ算術を、1つ左のシステムへずらしたものだ。エージェント型開発のコストは、買う推論だけではない。生成されたコードが下流に生む 検証負荷 — 実行すべきテスト、立ち上げる環境、ビルドする成果物、開くべきレビュー — であり、その負荷はコードより速く増える。
今週ダッシュボードに載せるべき数字
CI 分ではない。マージされた pull request 1件あたりの CI 分 を、週次で追う。総分数が増えるのは想定どおりで問題ない — 出荷している証拠だ。マージあたり の分数が増えるなら、作業1単位の検証コストが上がっているということであり、それが請求書の何か月も前に現れる先行指標である。
対になる記事では、Anthropic が CI/CD の失敗に対する自動の一次対応役として Claude を配置している様子が描かれている。アラートを監視し、Grafana、ログストア、PagerDuty、GitHub、Kubernetes を横断して調査し、修正を提案する。報告された数字は、最初の分析までの 中央値14分、最速の事例で 4分 以内、推奨から検証まで 3分 で解決した例が1件。あるケースでは、feature flag の切り替えによって静かに実行されなくなっていた 44件のテスト を特定した。
正直な読み方は対称的だ。これは問題の運用側半分に対する本物の答えであり、同時に、エージェントが生んだ負荷を吸収するためにエージェントを投入しているということでもある。このループが必ずしも悪いわけではない。ほとんどの自動化は、それ以前の自動化が生んだ物量への対応である。ただ、名指ししておく価値はある。進む方向を決めるからだ。エージェント型コーディングのコストは、ますます システムを見張るシステム として支払われるようになり、そちらにも運用コストがある。
四半期ではなく、1週間の仕事
やるコストと、やらなかったコストの比で並べた
「Claude が当社のコードの80% を書く」は持ち運べる統計ではない。 これは、特異なツール、特異なコードベース、そしてその主張を実証する特異な動機を持つフロンティアラボの話である。天井が高いことの証拠として扱うべきで、自社チームが遅れている目標として扱うべきではない。
出荷コード8倍は、提供価値8倍ではない。 指標は四半期あたりのコード量だ。記事のどこにもプロダクト成果が8倍になったとは書かれていないし、コード量はエージェント型ツールがほぼ構造的に膨らませる尺度である。
Anthropic のタイムラインは分布の攻めの端にある。 2四半期で25倍というのは、企業が最重量級のユーザーであると同時に提供者でもある場合に起きることだ。あなたの曲線はおそらくもっと緩やかだろう。移せるのは形であって、傾きではない。
これは解決済みの問題であり、解法は古い。 共有ジャーナル上のステートレスな worker は新しいアーキテクチャではなく、急成長した社内ツールが飛ばしてしまった分散システムの標準的な作法である — 急成長した社内ツールはそうするものだ。ここに新しく習得すべき技法はない。必要だと感じるより早く適用すべき、ありふれた技法があるだけである。
Anthropic の CI 記事が良い資料なのは、まさに華がないからだ。社内サービスが設計を追い越し、有能な対策を3回打ってもだんだん時間を稼げなくなり、3週間の作り直しできちんと直した。そのどの部分も、速く成長したあらゆる企業で起きてきたことである。
エージェント型コーディングが変えたのは時計である。従来なら自分のアーキテクチャを追い越すまでに3年かかったシステムが、いまは2四半期でそうなる。警告の兆候はこれまでと同じ順序で現れる — ただし、「いまは応急処置で、来四半期にきちんと直す」といういつもの反射が、次の四半期を使い果たしてしまうところまで圧縮されている。
6か月前より多くのコードを出荷しているなら、制約はすでにあなたより下流へ移っている。問題は、それをダッシュボードで知るか、請求書で知るかだけだ。
出典：Anthropic「Agentic coding is straining CI. Here's how we scaled test impact analysis at Anthropic」 Sachin Malhotra 著、2026年9月14日公開 · Anthropic「How Claude Tag serves as Anthropic's first responder for CI/CD failures」 · Analytics India Magazine「Anthropic's CI Jobs Grew 25x in 6 Months as Claude Wrote 80% of Code」 · VentureBeat「Anthropic says 80% of its new production code is now authored by Claude」。8倍、80%、10倍、25倍の数値、3回のパッチの持続期間、再設計の記述、10〜20倍で設計せよという推奨は、エンジニアリング記事で報じられたとおり Anthropic 自身のものです。一次対応の所要時間は対になる記事によります。Anthropic は CI のコストを公開していません — 請求書に関する節はジョブ数からの推論であり、本文でもそう明示しています。パッチの半減期という枠組み、ボトルネックが解消ではなく移動するという読み、および推奨はすべて筆者のものです。同じ路線の1つ手前の工程については、コーダーより先にレビュアーを雇う を参照してください。
IdeaToMVP Academy
4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.
