GitHub Copilot のようなコーディングエージェントを CI/CD（継続的インテグレーション・継続的デリバリー）に組み込んでいるチームに向けて、見落とされがちなキャパシティ設計の話をまとめます。AI エージェントが自動でプルリクエストを作る時代は、人間がコードを書いていた頃とは違う負荷パターンを生みます。SRE（サイト信頼性エンジニアリング）の立場で、何を確認すべきか整理しました。
2026年に公開された GitHub の年次レポート「Octoverse」によると、GitHub Actions のジョブ実行数は1秒あたり1440件、1日あたり約1億2400万件に達しています。前年の3倍以上の規模です。マージされたプルリクエストも1日あたり約350万件、年間では13億件にのぼります。これはエージェントによる自動化が実行基盤に与える負荷が、すでに無視できない水準にあることを示す数字です。
何が起きるか：ジョブ急増がパイプラインを詰まらせる
コーディングエージェントは、人間よりずっと速くコミットとプルリクエストを生成します。GitHub Universe 2026（GitHub の年次カンファレンス）で紹介された Copilot の自動化機能「Copilot Automations」は、本番環境のシグナルに反応して自動でコード変更を起こす仕組みです。これが有効になると、CI のトリガー回数自体が跳ね上がります。
影響は主に3か所に現れます。ひとつは CI ランナー（ビルドやテストを実行する計算資源）のキュー待ち時間です。もうひとつは外部 API やパッケージレジストリへのレート制限超過です。最後に、Dependabot のような依存関係更新ボットとエージェントのプルリクエストが重なり、レビューキューが飽和する現象です。Octoverse のレポートでは Dependabot によるマージ済みプルリクエストが3000万件超と、前年の約2倍に伸びています。人間のレビュワーが処理しきれないほどプルリクエストが積み上がれば、デプロイ頻度という SLO（サービスレベル目標）の指標そのものが崩れます。
なぜ起きるか：キャパシティ設計が「人間の執筆速度」前提のまま
根本原因は、多くの CI/CD 設計が「人間がコードを書く速度」を前提に組まれている点にあります。段階的に分解すると、3つの思い込みが重なっています。
1つ目は、ランナー数の見積もりです。従来は開発者数やチーム規模からランナー台数を逆算していました。エージェントが1人で何十ものプルリクエストを並行生成すると、この計算式は成立しません。
2つ目は、レート制限の設計です。Terraform や Pulumi のような IaC（Infrastructure as Code、インフラをコードで管理する仕組み）で GitHub Actions のランナーやシークレットを定義している場合でも、API コール頻度の上限設定までは IaC に含めていないケースが多いです。エージェントの自動実行は、この上限に静かに触れます。
3つ目は、コスト監視の粒度です。GitHub Copilot には AI クレジットという利用枠があり、モデルごとに消費量が異なります。CI のジョブ数だけ見ていても、どのモデル呼び出しがコストを押し上げているかは見えません。
自分のプロジェクトが該当するか確認する方法
該当するかどうかは、いくつかの数値を見れば判断できます。
# リポジトリの Actions 利用状況を確認（GitHub CLI）
gh api /repos/{owner}/{repo}/actions/cache/usage
# 直近のワークフロー実行一覧とステータスを確認
gh run list --limit 50 --json status,conclusion,createdAtこの出力で queued や in_progress の状態が長時間続くジョブが増えていれば、ランナーのキャパシティ不足を疑う段階です。
組織の設定画面では、Settings の Actions > General からセルフホストランナーの台数上限と、同時実行数の上限を確認できます。GitHub Enterprise を使っている場合は、Billing の画面で Actions の分あたり消費量の推移を直近3か月分さかのぼって見ておくと、エージェント導入前後の変化が把握しやすくなります。
依存関係更新ボットとの衝突を確認するには、.github/dependabot.yml の schedule 設定と、コーディングエージェントのトリガー条件（on.push や on.schedule）が重なっていないかを見ます。両方が同じブランチに対して短い間隔で動いていれば、レビューキューの飽和リスクは高いと判断できます。
対策の手順
キャパシティと SLO の両面から、以下の順で手を入れることを勧めます。
- ランナーの動的スケーリング: セルフホストランナーを使っている場合、Kubernetes 上で動くオートスケーラー（例: actions-runner-controller）を導入し、キュー長に応じてランナー数を自動調整する
- レート制限の IaC 化: GitHub App のレート制限や API トークンのスコープを Terraform の
githubプロバイダーで明示的に管理し、変更履歴を残す - プルリクエストのバッチ化: エージェントが生成するプルリクエストに
scheduleでまとめて発行するルールを設け、レビューの波を平準化する - コストダッシュボードの分離: Actions の分あたり消費とモデルのクレジット消費を別々のダッシュボードで可視化し、どちらが先に閾値へ近づいているか追えるようにする
- 障害対応の仕組み化: エージェントが生成した変更が原因の障害は、ロールバック手順を Runbook（障害対応手順書）に明文化し、人間のレビューを経ずに自動マージされた変更も対象に含める
オブザーバビリティ（システムの内部状態を外部から観測できるようにする仕組み）の観点では、ジョブのキュー待ち時間をメトリクスとして常時収集し、SLO の一部に組み込むのが現実的です。たとえば「プルリクエスト作成からマージまでの所要時間が95パーセンタイルで30分以内」といった指標を設定し、エージェント導入前後で比較できるようにしておくと、キャパシティ不足の兆候を数値で捉えられます。
まとめ
GitHub Actions のジョブ実行数が前年の3倍以上に伸びているという事実は、コーディングエージェントの普及が CI/CD 基盤に実際の負荷をかけていることを示しています。
対策の第一歩として、gh run list でキュー滞留時間を確認し、Actions の Billing 画面で消費量の推移を見ておくことをおすすめします。あわせて .github/dependabot.yml のスケジュールとエージェントのトリガー条件が重なっていないかも点検してください。
ランナーの動的スケーリング、レート制限の IaC 管理、プルリクエストのバッチ化、コストダッシュボードの分離、そして障害対応の Runbook 整備。この5つを順に見直すことで、エージェント時代の負荷増に耐えられる CI/CD 基盤に近づけます。