CIジョブ25倍｜AIにコードを書かせた先に来るCI費用と対策

「できました！」ってドカンと書類の山積んでくる

ryo氏（出典: Zenn - AIエージェント時代、正直しんどい話、2025年12月31日）

AIエージェントと働く日々を、こう書いていた記事がある。仕様書が200行、タスク一覧が100行、変更されたファイルが5つ。それが一気に目の前に置かれる。

個人がこれを感じているのなら、会社全体でやったらどうなるか。その答えが2026年9月14日に出た。Anthropicが自社のCIがどう詰まったかを、数字つきで公開したのだ。

CIジョブは6ヶ月で25倍になった。

CIとは、コードを変更するたびに自動でテストやビルドを走らせる仕組みのことだ。GitHub ActionsやJenkinsといったツールがこれを担う。押さえておきたいのは、この実行がクラウド上のマシンで行われ、使った時間に応じて課金される点になる。コードの変更回数が増えれば、テストの実行回数が増え、その分だけ待ち時間と請求が伸びる。

まず数字を押さえる：CIジョブ25倍・テスト10倍の内訳

Anthropicが公開したのは、AI-native な開発体制が自社インフラに何をしたかの記録だ（出典: Anthropic - Agentic coding is straining CI. Here’s how we scaled test impact analysis at Anthropic、2026年9月14日）。

指標	変化	期間・条件
CIジョブ数	25倍	6ヶ月
コードベースのテスト数	10倍	同期間
エンジニア1人あたりの四半期コード量	8倍	2021〜2025年との比較
新規プロダクションコードのうちClaudeが書いた割合	約80%	2026年時点・同社公表値
エンジニアの人数	わずかに増加	同期間

注目すべきは最後の行だ。人数がほぼ変わっていないのに、システムへの負荷だけが25倍になっている。従来のキャパシティプランニングは「人が増えるからサーバーも増やす」という比例関係を前提にしてきた。その前提が切れている。

もっとも、「AIで開発が速くなる」という前提そのものを疑う研究もある。経験豊富な開発者がAIツール利用時にむしろ19%遅くなったとするMETRの結果は、AIツールで経験豊富な開発者が19%遅くなるで扱った。Anthropicの数字は、その議論に対する一企業の反例として読むのが正確だと思う。

VentureBeatの報道では、Anthropicの自動コードレビュアーが、claude.ai で過去に発生した障害の原因となった本番バグの約3分の1を検出していること（このマルチエージェント型レビューの仕組みはClaude Code Review完全ガイドで詳述している）、2026年4月には自律的に動くClaudeがAPIエラーの修正を800件以上出荷したことも紹介されている。人手なら4年相当という試算だ（出典: VentureBeat - Anthropic says 80% of its new production code is now authored by Claude、Carl Franzen、2026年6月4日）。

コードを書くことも、レビューすることも、加速した。残ったのは検証の工程だ。

壊れたのは「テストを選ぶ係」：テスト影響分析が詰まった理由

Anthropicのテスト影響分析、つまり変更したコードに関係するテストだけを選んで実行する仕組みは、同じ入力なら必ず同じ結果を返す2つの単純な部品でできていた（決定的／deterministic な設計だ）。

リスナーは、CI実行のたびにテスト結果を記録する。どのテストが、どの変更で、どう転んだか。

セレクタは、その履歴とパッケージの関連度から、あるPRで走らせるべきテストを決める。

考え方自体は堅い。問題は、リスナーがシングルトン、つまり単一の書き手として設計されていたことだ。テストごとの履歴を1つのプロセスが持ち続ける以上、横に並べて増やすことができない。

CIジョブが毎秒複数走るようになると、リスナーはPRキューに対して遅れ始める。この遅れが厄介なのは、遅れた分だけセレクタの判断材料が古くなる点だ。Anthropicの記述によれば、リスナーが20分遅れると、数万件規模のテスト結果更新がセレクタに反映されないまま残る。つまり、走らせるべきテストを選び損ねる。

応急処置が効かなくなっていく過程

ここからの記録が生々しい。

時期	対処	効いた期間
2025年10月	マシンのコア数を倍増	約70日
2026年2月	シャーディング（パッケージ単位のワーカーに分割し、状態を個別管理）	約29日
2026年3月	日次再起動を追加	1日未満

70日、29日、1日未満。効果の持続時間が桁で縮んでいく。

これは負荷が緩やかに増えているときには起こりにくい挙動だ。負荷の伸びがなだらかなら、対処の効果もなだらかにしか減らない。効果の持続時間が桁単位で縮むのは、負荷の伸び方そのものが加速しているサインと読める。Anthropicはこの3回目で、パッチではなく設計を変える判断をした。

再設計で捨てたもの：テスト影響分析はどう作り直されたか

新しい設計の中心にあるのは、リスナーから状態を剥がすという一点だ。

• テストの状態をリスナーの外（インメモリのデータストア）に出す。ワーカーは状態を持たなくなり、どの結果でも独立に処理できるようになる
• 書き込みはジャーナル（起きたことを時系列に追記していくだけの記録）に積み、別のプロセスが数秒ごとにテストごとの履歴へまとめ直す。セレクタはその履歴を直接参照する

書き手が1つだから横に増やせない、という制約を、書き込み先を分けることで解いている。PMとしての理解の範囲で言えば、これは「処理を速くする」改善ではなく「並べられる形に分解する」改善だ。同じ速度のプロセスでも、並べられれば台数分だけ伸びる。

実装にかかったのはエンジニア1人・3週間。Anthropicは、1年前なら四半期近くかかっただろうと書いている。CIを逼迫させた当のエージェントが、CIを直す作業も加速させている構図になる。この再帰的な加速そのものについては、Claudeが社内コードの80%を書く体制とAIへのブレーキ論で別途整理している。

そして教訓として書かれているのが、常に指数関数的な伸びを前提に計画せよ、という趣旨の指針だ（前掲Anthropicブログの教訓セクションを筆者が要約したもの。正確な文言は原典を参照）。

具体的な指針も添えられている。アーキテクチャは2四半期以内に25倍の負荷を受けると想定すること。v0の設計時点でも、見積もったスケールの10〜20倍を織り込んでおくこと。サービスは自律的に監視できるよう計測を仕込むこと。プロセスは状態を持たせないこと。計測できない単一インスタンスの重要サービスを作らないこと。

同じことが個人開発でも起きている：AIエージェントとCI費用の実例

25倍という数字は自社インフラを持つ企業の話に見える。だが構造は個人にも降りてくる。

dev.toのmaweis1981氏は、Next.js + PostgreSQLの本番プロジェクトでClaude CodeとCursorを3ヶ月運用した結果をこう書いている。CI請求が、同種の非AIプロジェクトの6倍。1日あたりのコミットは80件で、その多くが「wip」や「asdf」といったタイトルだった（出典: dev.to - My AI agent’s CI bill was 6× higher than my last project’s、2026年6月6日）。

同氏の分析が的確だった。

Git、GitHub、マネージドデータベースの経済性は、人間の開発者が1日に数コミットする前提で設計されている。1日50回動くエージェントを差し込んでも、Gitは壊れない。壊れるのは請求書のほうだ（出典: 同上。日本語は筆者訳）

金額だけの話でもない。同氏は、エージェントが流したマイグレーションがプール接続経由で部分的にしか適用されず、3週間で4回の障害になったとも書いている。実行回数が増えるということは、運が悪い実行を引く回数も増えるということだ。

もうひとつ。Speedscale CEOのKen Ahrens氏は、Claude Code、Gemini CLI、Cursor、GPT-5 Codexを18日間試して約900ドルを使った経験を公開している。うち300ドルは、同氏の説明によれば、ループ状態に陥った単一のGemini CLIセッションで消費されたという（出典: dev.to - How to tame your AI agents: from $900 in 18 days to coding smarter、Ken Ahrens、2025年8月12日）。

請求が伸びる経路は、モデル利用料だけではない。GitHub Copilotは2026年6月1日から従量課金へ移行しており（年額契約者は契約満了まで従来課金）、ヘビーユーザーの請求が10倍から50倍に跳ねたという報告が出た。Redditに投稿された個人ユーザーの試算では、月29ドルから約750ドルへ、別のユーザーは50ドルから約3,000ドルへという数字も挙がっている（出典: TechTimes - GitHub Copilot Pricing Change Drives Backlash、2026年6月1日。同記事はGitHub・Microsoftがこれらの試算を検証していない旨も注記している）。しかもCopilotによるコードレビューはGitHub Actions上で動くため、1回のレビューでAIクレジットとActions分数の両方を消費する。この価格改定の経緯はCopilotのトークン課金への反発で詳しく扱っている。

GitHub Actionsの料金・無料枠で試算するとどうなるか

GitHub Actionsの料金は2026年1月1日に最大39%引き下げられ、Linux 2コア（x64）が1分あたり0.006ドル、1コアが0.002ドル、2コアarm64が0.005ドルになっている。無料枠はプライベートリポジトリでGitHub Freeが月2,000分、Pro / Teamが3,000分、Enterprise Cloudが50,000分（出典: GitHub Docs - About billing for GitHub Actions、およびGitHub Changelog、2025年12月16日）。パブリックリポジトリは無料だ。

なお本記事の金額はいずれも各社が公表する米ドル建て・税別の値であり、日本から利用する場合は別途税が課される。円建ての負担額は為替により変動し、料金体系も予告なく変更されうる。

仮に1日80プッシュ（人間の開発者の一般的なペースは1日数回なので、その20〜30倍にあたる）、1回のCIが5分だとすると1日400分、月20営業日で8,000分。Freeの2,000分を引いた6,000分に0.006ドルを掛けて月36ドルになる。金額としては大きくないが、これがエージェント1体・1プロジェクトあたりの数字である点は押さえておきたい。並列で走らせる本数だけ素直に倍になる。

この試算は筆者が公開料金から計算したもので、実測値ではない。GitHub Actionsはジョブ単位で分を切り上げて課金するため、短いジョブが多い構成では実消費が試算を上回りやすい点も付け加えておく。

自分の現在地を知るほうが早い。GitHub CLIが入っているなら、次のコマンドで今月の消費分数（total_minutes_used）と課金対象分数（total_paid_minutes_used）が取れる。

gh api /users/{username}/settings/billing/actions

今日から打てる手：GitHub ActionsのCI費用を下げる4つの設定

小さい順に並べる。GitHub Actions以外を使っている場合も、考え方は同じだ。GitLab CIなら interruptible: true と auto_cancel_pending_pipelines、Jenkinsなら Pipeline の disableConcurrentBuilds(abortPrevious: true)、Azure Pipelines なら「Automatically cancel in-progress runs」が対応する。「同じブランチで新しい実行が来たら古い実行を止める」という考え方は、どのCIツールにも用意されている。

1. concurrency と cancel-in-progress を入れる

同じブランチで新しいプッシュが来たら、走っている古い実行を打ち切る設定だ。エージェントが10分間に20回プッシュしても、走り切るのは最後の1回だけになる。手前の19回は起動直後に打ち切られるので、消費分数がフルではなく数十秒で済む。

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  # main では取り消さない（デプロイ中断・CI履歴の欠損を防ぐ）
  cancel-in-progress: ${{ github.ref != 'refs/heads/main' }}

適用先は選ぶ必要がある。デプロイやリリースを行うワークフローにそのまま入れると、処理の途中でキャンセルされて不完全な状態が残る。必須ステータスチェックがキャンセル扱いになるとマージがブロックされることもあるため、まずはテスト・Lint系のワークフローから適用するのが無難だ。

前述のmaweis1981氏は、この1設定だけでCI請求が約70%下がったと報告している。着手コストの小ささに対して、効果が大きい部類に入る。

2. paths-ignore でドキュメントのみの変更を外す

READMEの修正でテストスイート全体を走らせる必要はない。paths-ignore に **.md や docs/** を指定しておく。

ただし、そのワークフローをブランチ保護の必須チェックに指定している場合は注意がいる。paths-ignore でスキップされたジョブは実行されない扱いになり、必須チェックが未完了のままPRをマージできなくなることがある。必須チェックにしているワークフローでは、dorny/paths-filter などでジョブ内部から条件分岐させ、ジョブ自体は成功で終わらせる形にする。

3. エージェントの自動コミット・自動プッシュを切る

そもそもプッシュ回数を減らす。maweis1981氏はこれに加えて、「wip」のような曖昧なコミットメッセージを弾く検証を入れている。

4. テスト選択の仕組みを入れる

Anthropicがやったことの縮小版だ。JS / TSのモノレポ（複数のプロジェクトを1つのリポジトリでまとめて管理する構成）なら、Nx の affected コマンドや Turborepo のフィルタが、依存グラフをもとに影響範囲のプロジェクトだけを対象にしてくれる。Bazelはターゲットグラフで同じことをする。より細かい、テスト単位のカバレッジに基づく選択が必要なら Datadog の Test Impact Analysis や Launchable（現CloudBees）といったサービスがある。

規模の小さいうちは4番まで必要ないことが多い。ただ、テストが10倍に増える未来を前提にするなら、モノレポツールの選定時点で affected 相当の機能があるかどうかは見ておいたほうがいい。

組織で導入を検討しているなら

社内でAIコーディングの導入を進めている立場なら、この記事から取るべき論点は3つある。

1つ目。導入効果の試算に、CIやテスト基盤の増加コストが入っているか。コーディング速度の向上だけを見た試算は、下流の費用を見落とす。

2つ目。パイロット導入の時点から、CI実行回数と実行分数をKPIとして計測しているか。Anthropicが異変に気づけたのは、数字を持っていたからだ。

3つ目。テスト基盤に「1台のサーバーで動く単一プロセス」が残っていないか。Anthropicが詰まったのは、まさにこの一点だった。

鵜呑みにしないほうがいい部分：専門家の反論と数字の性質

テスト自動化の専門家であるZhimin Zhan氏は、公開の2日後にこの記事への論評を出している（出典: Reflections on Anthropic’s New Article: “Agentic coding is straining CI.”、Zhimin Zhan、2026年9月16日）。

同氏の立場は明快だ。Anthropicの信頼性は認めつつ、成熟したプロとして公開コンテンツの主張をすべて額面どおりに受け取るべきではない、とする（前掲Substack記事。日本語は筆者訳）。そのうえで、このデータが示しているのは可能性の広がりではなく制約のほうだと読む。

指摘は2点ある。

ひとつは、AIリソースが潤沢なAnthropicですら、完全な自動化には至っていないという点。完全にエージェントだけで開発が回ることを期待する企業は、その期待を捨てるべきだ、というのが同氏の要約だ。

もうひとつは、テストの10倍という数字を、AI時代における自動テストの必要性の裏づけとして読む立場。同氏の見方では、エージェント型コーディングの普及を実際に律速するのはコード生成能力ではなく、テスト基盤のほうにある。

この読みには同意できる部分がある。あわせて、Zhan氏がテスト自動化を専門とする実務家であるという前提は、読み手として知っておいてよい情報だと思う。専門家の論評はその領域の知見が厚い一方、読者の側で他の立場の見解と突き合わせる余地も残しておきたい。

もうひとつ、数字の性質についての注意もいる。25倍も10倍も、Anthropicが自社について公表した値であり、第三者による検証はされていない。これらは同社のAI製品の有効性を示す性質のデータでもある。方向性としての信頼は置けても、倍率をそのまま自分の環境の予測に使うのは無理がある。

自分ならこうする

自分（電脳狐影）はPMで、このブログの記事ビルドとデプロイをClaude Codeで毎日回している。テスト数が10倍になるような規模ではない。このブログのビルド自体はVercel側で走るため、GitHub Actionsの分数がボトルネックになる構成でもない。それでも、この記事から持ち帰るものは3つある。

1つ目。ボトルネックの移動を、コストの移動として見る。

「コードを書く速度が上がった」という話は、たいてい嬉しい話として語られる。だが速度が上がるということは、その下流に流れ込む量が増えるということだ。Anthropicの場合、その下流がCIだった。個人プロジェクトなら、レビューする自分自身がそこに当たる。冒頭のryo氏の「できました！」ってドカンと書類の山積んでくる、という一節は、25倍のCIジョブと同じ現象の人間側の見え方だと思う。

同氏はさらに厳しいことを書いていた。「分からんけど動く」が一番キツい、と。検証工程が詰まるというのは、待ち時間の問題であると同時に、理解が追いつかないまま本番に乗るという問題でもある。この構造はエージェント時代の開発者像という話と地続きだ。

2つ目。cancel-in-progress は今日入れる。

70%という数字が正しいかは環境次第だが、設定の追加行数は3行で済む。適用先をテスト系のワークフローに絞れば、副作用も小さい。エージェントを回している人は、この記事を読み終わったら自分のワークフローを見に行ったほうがいい。自分のリポジトリにも入っていない箇所があった。

3つ目。「指数関数を前提に計画せよ」は、そのまま採用しない。

Anthropicの指針は正しいが、それは同社の増加率が実際に指数的だったからだ。四半期で8倍のコードを出す組織と、1人で記事を書いているブログとでは、想定すべきカーブが違う。個人が25倍を前提に設計すると、来ない負荷のために可搬性を犠牲にすることになる。

代わりに採用するのは、Anthropicが3回のパッチから学んだ「効果の持続時間を記録する」という部分のほうだ。70日、29日、1日未満。この数列を持っていたから、4回目にパッチではなく設計変更を選べた。同じ場所を2回直しているなら、3回目は直し方を変える。これは規模を問わず使える判断基準になる。

なお、テスト影響分析の内部設計に関する記述は、公開されたブログの範囲をPMとして読んだ理解であり、実装を検証したものではない。

---

よくある質問

AIにコードを書かせるとCIの負荷はどれくらい増えますか？

Anthropicの事例では、CIで実行されたジョブの本数が6ヶ月で25倍になりました。背景として、同社のエンジニア1人あたりの四半期コード量が2021〜2025年比で8倍になり、新規プロダクションコードの約80%をClaudeが書いている状況があります。コードベース全体のテスト数も10倍に増える一方、エンジニアの人数はわずかしか増えていません。いずれも同社の公表値です。

テスト影響分析（Test Impact Analysis）とは何ですか？

変更されたコードに関係するテストだけを選んで実行する仕組みです。全テストを毎回流すのではなく、過去の実行履歴やパッケージ間の依存関係から「この変更ならこのテストを走らせれば十分」と判断します。CIの実行時間と費用を削る目的で使われ、Bazel、Nx、Turborepoなどのモノレポツールや、Datadogのようなサービスにも同種の機能があります。

GitHub Actionsの料金を下げるにはどうすればいいですか？

ワークフローに concurrency と cancel-in-progress を設定して、同じブランチの古い実行を自動でキャンセルする方法が、着手のしやすさという点で有力な選択肢です。ある個人開発者の報告では、この1設定だけでCI請求が約70%下がったとされています。ただしデプロイ系のワークフローに入れると処理が途中で打ち切られるため、適用先はテスト・Lint系に絞ってください。あわせて paths-ignore でドキュメントのみの変更を除外する、エージェント側の自動プッシュを切る、といった対策も併用できます。

GitHub Actionsの無料枠は月何分ですか？

プライベートリポジトリの場合、GitHub Freeが月2,000分、Pro / Teamが3,000分、Enterprise Cloudが50,000分です。パブリックリポジトリは無料で利用できます。超過分はLinux 2コア（x64）で1分あたり0.006ドル（2026年1月の改定後、米ドル建て・税別）です。料金は変更される場合があるため、最新の値は公式ドキュメントを確認してください。

個人開発や小規模チームでも同じ問題は起きますか？

規模は違いますが、構造は同じです。エージェントに自動コミット・自動プッシュをさせると、1日あたりのプッシュ回数が人間の数十倍になり、その回数だけCIが走ります。dev.toに投稿されたある個人開発者の報告では、AIエージェントを3ヶ月運用した結果、CI請求が同種の非AIプロジェクトの6倍になったとされています。1事例の報告であり一般的な数値ではありませんが、まずはGitHub Actionsのconcurrency設定を見直すのが着手しやすい対策です。

Nx、Turborepo、Bazelのどれでテスト選択をすればいいですか？

JavaScript / TypeScriptのモノレポであれば、Nxの affected コマンドかTurborepoのフィルタが導入しやすい選択肢です。どちらも依存グラフをもとに、変更の影響を受けるプロジェクトだけを対象にします。多言語のモノレポではBazelがターゲットグラフで同じ役割を果たします。テスト単位のより細かいカバレッジベースの選択が必要な場合は、DatadogのTest Impact AnalysisやLaunchable（現CloudBees）といったサービスが候補になります。

テストが10倍に増えたのは良いことではないのですか？

テストの本数が増えること自体は品質にとって前向きな変化です。ただしテストは書いた瞬間から、実行時間・実行費用・メンテナンス対象という3つのコストを毎回発生させ続けます。AIがテストも書くようになると、この3つが人手の増加とは無関係に伸びていきます。増やすことよりも、増えたテストのうちどれを毎回走らせるかを機械的に決める仕組みのほうが重要になります。

この話はClaude Codeを使っていない人にも関係しますか？

関係します。ボトルネックがコードを書く工程から、検証する工程へ移るという構造の話だからです。CursorでもGitHub Copilotでも、エージェントにコードを書かせる比率が上がれば同じ場所が詰まります。GitHub Copilotは2026年6月1日から従量課金へ移行しており、コードレビュー1回でAIクレジットとActions分数の両方を消費する構造になっています。

---

関連記事

• Ultracodeで170万トークンが消えた: Claude Code最新機能の実際のリスク
• コードを書くな、任せろ：2026年AIエージェント時代の開発者像
• GitHub Copilot従量課金移行：月$39が2時間で消えた開発者の怒りと代替ツール選び
• AIツールで経験豊富な開発者が19%遅くなる｜METR研究の衝撃と2026年の真実
• Anthropic「Claudeが社内コード80%を書いている」AIにブレーキを求めた論考の中身
• Claude Code Review完全ガイド｜マルチエージェントが人間の見逃すバグを自動検出

---

免責事項

• 本記事の情報は2026年9月17日時点のものです。
• 本記事は情報提供を目的とした解説であり、特定のツール・サービスの導入を推奨するものではありません。紹介した設定変更は一般的な情報であり、個別環境での動作を保証するものではありません。適用による障害・損失について筆者は責任を負いません。導入前に検証環境での確認をおすすめします。
• Anthropicが公表した25倍・10倍・8倍・80%という数値は、いずれも同社が自社について公開した値であり、第三者による検証を経たものではありません。これらは同社のAI製品の有効性を示す性質のデータでもあります。
• 引用した英語の記事・ブログ・ドキュメントは原文からの筆者による翻訳であり、意訳を含みます。Anthropicの教訓に関する記述は逐語訳ではなく趣旨の要約です。正確な文言は各原典を参照してください。
• dev.to、Zenn、Reddit等で紹介されている費用や体験は、個々のユーザーの環境における1事例の報告であり、筆者が再現検証したものではありません。同じ設定で同じ結果になることを保証するものではありません。
• GitHub Actions分数の試算は、公開されている料金表からの筆者による計算であり、実測値ではありません。ジョブ構成・キャッシュ・ランナー種別・分単位の切り上げにより、実際の消費分数と費用は大きく変動します。
• 記載の金額は米ドル建て・税別の公表値です。日本から利用する場合は別途税が課されます。為替により円建ての負担額は変動し、価格・プラン・無料枠は予告なく変更される場合があります。最新の料金は各社の公式ページを確認してください。
• GitHub Copilotの従量課金移行について、年額契約のPro / Pro+は契約満了まで従来の課金体系が適用されます。
• テスト影響分析サービスの設計に関する記述は、公開されたブログ記事の範囲に基づく筆者の理解であり、実装を検証したものではありません。
• Nx、Turborepo、Bazel、Datadog Test Impact Analysis、Launchable（現CloudBees）に言及していますが、筆者はいずれの提供元とも提携関係にありません。導入可否は各自の環境と公式ドキュメントを確認のうえ判断してください。
• 本記事はAnthropic社の公開情報を筆者が第三者の立場で解説したものです。Anthropic社、GitHub社およびその関連会社との提携・提供関係はなく、内容は筆者独自の見解です。本記事にアフィリエイトリンクは含まれません。

※ Claude、Claude Code は Anthropic PBC の、GitHub、GitHub Actions、GitHub Copilot は GitHub, Inc. の商標または登録商標です。その他記載の会社名・製品名は各社の商標または登録商標です。