CIが遅すぎて誰も見なくなった話｜実行時間を短縮する7つの対策

「CIが終わるまで待てない」「どうせ通るだろう」——CI実行時間が長すぎることで生まれる「誰も待たない・誰も見ない」文化と、実行時間を短縮する7つの具体策を解説します。pytest-xdist並列化・Stage分割・キャッシュ設計・モック化など、実務で即使えるCI高速化の方法を紹介します。

CIは「壊れたとき」より「遅すぎるとき」の方が、じわじわとチームを壊します。「30分待って赤いCI」と「3分で赤いCI」では、同じ失敗でもチームへの影響が全く違います。

「CI終わった？」「あ、まだ走ってる。とりあえずマージしとくか」——この会話が一度でも起きたなら、CIの速度問題は既に文化問題になっています。

Flakyテストと違い、CI速度の問題は「テストが落ちる」わけではありません。静かに、じわじわと、「CIを確認する文化」を侵食していきます。この記事では、CI遅延が引き起こす崩壊プロセスと、具体的な高速化策を解説します。

CI速度の問題が「誰も見なくなる」につながるプロセスとは？

CIが遅くなる原因とは？7つの分類

「なんとなく遅い」ままにしておくと永遠に改善されません。まずどの原因で遅いかを特定することが高速化の第一歩です。

対策①：pytest-xdistで並列実行する

最も即効性が高い対策です。pytest-xdistを使うと、テストを複数のCPUコアで並列実行できます。テスト数が多いほど効果が大きく、100件以上のテストスイートでは実行時間が2〜4倍短縮されることが多いです。

# インストール
# pip install pytest-xdist

# ローカル：CPUコア数を自動検出して並列実行
pytest tests/ -n auto

# GitHub Actions：ワーカー数を明示的に指定
pytest tests/ -n 4

# pytest.ini で常時有効化（CI環境向け）
# [pytest]
# addopts = -n auto
#
# ⚠️ ローカルでの注意：-n auto を addopts に常時設定すると
# VSCode Test Explorer・デバッグ実行・coverage計測・Flaky調査
# と相性問題が出ることがあります。
# CI限定で有効化する場合は pytest.ini ではなく GitHub Actions の
# run: pytest tests/ -n auto として設定する方が安全です。

対策②：CIをStageに分割して早期フィードバックを得る

「全テストが終わらないと何も分からない」設計では、どんなに速くしても限界があります。単体テスト→結合テスト→E2Eテストの順にStageを分けると、バグを早い段階で検出できます。

# GitHub Actions の Stage分割例（.github/workflows/test.yml）
name: CI Pipeline

on: [push, pull_request]

jobs:
  # Stage 1：単体テスト（目標：1分以内）
  unit-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.11"
      - name: Install dependencies
        run: pip install -r requirements.txt
      - name: Run unit tests
        run: pytest tests/unit/ -n auto --tb=short

  # Stage 2：結合テスト（目標：3分以内）
  # 単体テストが通過した場合のみ実行
  integration-tests:
    needs: unit-tests
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.11"
      - name: Install dependencies
        run: pip install -r requirements.txt
      - name: Run integration tests
        run: pytest tests/integration/ -n auto

  # Stage 3：E2Eテスト（目標：5分以内）
  # 結合テストが通過した場合のみ実行
  e2e-tests:
    needs: integration-tests
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.11"
      - name: Install dependencies
        run: pip install -r requirements.txt
      - name: Install Playwright browsers
        run: playwright install chromium --with-deps
      - name: Run E2E tests
        run: pytest tests/e2e/ -n 2

対策③：依存関係キャッシュで毎回のインストールを省略する

毎回 pip install を実行していると、それだけで2〜5分かかることがあります。依存関係が変わっていない場合はキャッシュを利用することで、インストール時間をほぼゼロにできます。

# GitHub Actions でのキャッシュ設定例

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # ✅ Python依存関係のキャッシュ
      - name: Cache pip packages
        uses: actions/cache@v4
        with:
          path: ~/.cache/pip
          # requirements.txtが変わったときだけキャッシュを更新
          key: ${{ runner.os }}-pip-${{ hashFiles('requirements.txt') }}
          restore-keys: |
            ${{ runner.os }}-pip-

      - name: Install dependencies
        run: pip install -r requirements.txt

      # ✅ Playwrightのブラウザバイナリキャッシュ
      - name: Cache Playwright browsers
        uses: actions/cache@v4
        with:
          path: ~/.cache/ms-playwright
          key: playwright-${{ hashFiles('requirements.txt') }}

      - name: Install Playwright browsers (キャッシュがない場合のみ)
        run: playwright install chromium --with-deps

- uses: actions/setup-python@v5
  with:
    python-version: "3.11"
    cache: "pip"  # これだけでpipキャッシュが有効になる

対策④：外部I/OをモックしてCI環境の待機時間を削減する

実際のDB・外部API・メール送信などを使うテストは、ネットワーク遅延・外部サービスの応答時間がCIのボトルネックになることがあります。

from unittest.mock import patch, MagicMock
import requests
import pytest

from sqlalchemy import create_engine
from sqlalchemy.orm import Session, declarative_base

# Base の定義例（実際のプロジェクトではモデルファイルで宣言済みの想定）
# from sqlalchemy.orm import declarative_base
# Base = declarative_base()
Base = declarative_base()

# ❌ 遅い：実際の外部APIを毎回呼び出す
def test_send_notification():
    result = requests.post(
        "https://api.slack.com/api/chat.postMessage",
        json={"channel": "#test", "text": "テスト完了"}
    )
    assert result.status_code == 200
    # ネットワーク往復で 200〜500ms かかる

# ✅ 速い：外部APIをモックして即座に返す
@patch("requests.post")
def test_send_notification_fast(mock_post):
    mock_post.return_value = MagicMock(status_code=200)
    result = requests.post(
        "https://api.slack.com/api/chat.postMessage",
        json={"channel": "#test", "text": "テスト完了"}
    )
    assert result.status_code == 200
    # モックなので 1ms 以下で完了

# ✅ DBもフィクスチャでインメモリを使う
@pytest.fixture
def db_session():
    """SQLiteのインメモリDBを使った高速なDBフィクスチャ"""
    engine = create_engine("sqlite:///:memory:")
    Base.metadata.create_all(engine)
    with Session(engine) as session:
        yield session
    # withブロックを抜けると自動でclose・rollback

対策⑤：time.sleepを排除して明示的待機に置き換える

100件のテストに time.sleep(2) が1つずつあると、それだけで3分超の固定ロスになります。sleepはFlakyの原因でもあり、CI高速化の観点からも真っ先に排除すべき対象です。

# time.sleep の使用箇所を一括検索（asyncio.sleep等との混同を避けるため明示的に指定）
# grep -R "time.sleep(" ./tests

# ❌ 遅い：固定待機
import time
time.sleep(3)
driver.find_element(By.ID, "result").click()

# ✅ 速い：条件が満たされたら即座に次へ
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

wait = WebDriverWait(driver, 10)
element = wait.until(EC.element_to_be_clickable((By.ID, "result")))
element.click()
# 要素がクリック可能になった瞬間に実行（平均0.3秒、sleepより大幅短縮）

対策⑥：実行時間の長いテストを可視化して棚卸しする

「なんとなく全部必要」で追加し続けたテストが、CIを圧迫していることがあります。実行時間のプロファイリングで「遅いテスト上位10件」を可視化するだけで、改善の優先順位が明確になります。

# pytest 標準機能で実行時間の長いテストを表示（追加プラグイン不要）
pytest tests/ --durations=20

# 実務推奨：1秒以上かかるテストだけを表示（短いテストのノイズを除去）
pytest tests/ --durations=20 --durations-min=1.0

# 出力例：
# 15.23s call     tests/e2e/test_checkout.py::test_full_purchase_flow
#  8.91s call     tests/e2e/test_login.py::test_login_with_mfa
#  6.44s call     tests/integration/test_report.py::test_generate_pdf_report
#  3.12s call     tests/unit/test_user.py::test_create_user  ← 単体テストで3秒は要調査

# ❌ 問題のあるパターン：
# - 単体テストが3秒以上かかっている → 外部I/Oが混入している可能性
# - E2Eテストが20秒以上かかっている → テストのスコープが広すぎる可能性
# - 「同じシナリオを微妙に変えただけ」のテストが多数ある → parametrizeで統合を検討

対策⑦：テストピラミッドを見直してE2E偏重を是正する

CIが根本的に遅い場合、原因はしばしば「テストピラミッドの逆転」にあります。E2Eテストばかり増えて、単体・結合テストが少ない状態がこれです。

「誰も見なくなる前に」対処する予兆チェックリストとは？

以下のチェックリストで現状を確認してください。3つ以上あてはまったら、今すぐ改善を始めるサインです。

FAQ

CIは「正しいコードを守るためのもの」ですが、遅すぎると「誰も見ないもの」になります。技術的な問題のはずなのに、放置すると文化的な問題に変わっていきます。今日の実行時間を計測して、まず1つだけ改善してみてください。「5分のCIを待てるチーム」と「30分のCIを諦めたチーム」では、1年後の品質に大きな差が生まれます。