GitHub Actionsを減らしたら、品質が落ちると思っていた。実際には逆だった。

GitHub Actionsを減らす話が出たとき、私は少し怖かった。

CIは多いほど安全だと思っていたからです。

lint、typecheck、全テスト、ブラウザテスト、データベース検査、セキュリティ確認、本番ビルド。変更のたびに全部走らせれば、見落としは減る。少なくとも、そう考えていました。

ところが、Claude CodeやCodexを使って開発速度を上げると、別の問題が起きました。

AIは人間より短い間隔でcommitし、pushし、Pull Requestを更新します。一つの修正に対して、途中経過のcommit、レビュー修正、テスト修正、再レビューが次々に入り、そのたびにGitHub Actionsが起動します。

気づけば、コードより先にCIが詰まっていました。

それでも最初は、品質のための待ち時間だから仕方がないと思っていました。

しかし調べると、実際には同じ検査を重複して走らせ、古いSHAの結果を量産し、必要な失敗を見つけにくくしていました。

検査を増やしたことで、品質が上がるどころか、証拠が濁っていた。

そこでGitHub Actionsを減らしました。

正確には、検査そのものを捨てたのではありません。

必要のないタイミング、必要のない変更、同じ目的の重複実行を止めた。

結果として、docs-onlyの実PRでは9分31秒かかっていた通常CIが2分09秒になりました。77.4%の短縮です。

そして重要だったのは、品質ゲートを薄くしたのではなく、何を確認したのかが以前より明確になったことでした。

CIが多いほど安心するという思い込み

CIがGREENになると安心します。

ただ、GREENという色だけを見るようになると危険です。

見るべきなのは、何を検査したのか、どのSHAを検査したのか、本番と同じ条件なのか、失敗しても握りつぶされる経路がないか、そして現在の変更と関係のある検査なのかです。

私たちの環境では、AIエージェントはGitHub Actionsを使いすぎる状態になっていました。

通常CIとexact-head検証が同じ重いsuiteを走らせ、docs-onlyでもPostgresが起動し、browserが不要でもChromiumを導入していました。さらに、変更内容を分類する頃にはnpm ciまで終わっていました。

これは安全というより、全員を毎回同じ検査場へ通している状態でした。

AIが速くなると、CIの前提が壊れる

人間が数時間に一度pushする開発では、毎回広い検査をしても実行回数は限られます。

AIエージェントは違います。

Builder A → commit → push
Builder B → commit → push
Builder C → commit → push
レビュー修正 → commit → push
テスト修正 → commit → push

実装能力が増えれば、CIへ流れ込むイベントも増えます。

ここで、一回のテストを20%速くするだけでは足りません。発火回数が二倍、三倍になれば、内部を高速化しても全体は詰まります。

先に問うべきなのは、テストコードの速度ではありませんでした。

この検査は、いま本当に走るべきか。

ここを設計しないままAIエージェントだけ増やしたため、GitHub Actionsが新しいボトルネックになりました。

9分31秒から2分09秒へ

Path-aware CIを入れたあと、docsだけを変更する実際のPull Requestでcanaryを行いました。

分類結果は次でした。

needs_code=false
needs_browser=false
needs_database=false

ただし、何も確認しなかったわけではありません。

公開情報や契約表現の整合、workflow safety、deploy policy、CI coverage、Agent運用ルール、静的なRLS coverageなど、Markdown変更でも壊れうる検査は残しました。

つまり、docs-onlyだから雑に通したのではなく、その変更が影響しない実行基盤だけを起動しなかったということです。

最初にDraftのrunnerを止めた

作業中のDraft PRへ毎回full CIを投入しても、その結果は次のpushで古くなります。

従来はこうでした。

Draft PR
  ↓
push #1 → CI
  ↓
push #2 → CI
  ↓
push #3 → CI
  ↓
Ready → CI

変更後はこうです。

Draft PR
  ↓
push #1 → runnerなし
  ↓
push #2 → runnerなし
  ↓
push #3 → runnerなし
  ↓
Ready → CI

作業中の検査自体を捨てたわけではありません。ローカルや専用環境で変更範囲に応じた検査を行い、GitHub-hosted runnerはReady時の統合証拠へ寄せました。

「全部走らせる」を「変更を分類する」に変えた

CIの最初に、変更pathだけを見る軽量なclassify jobを置きました。

判定するのは三つです。

needs_code
needs_browser
needs_database

重要なのは、この判定をnpm ciより前に行うことです。

以前も後半のテストをskipする仕組みはありました。しかしskipを判断する頃にはrunnerが起動し、Postgresが立ち上がり、依存関係の導入まで終わっていました。

「走らせなかった」のに、費用と待ち時間の大半はもう使っていたわけです。

変更分類を入口へ移したことで、必要な実行基盤だけを起動できるようになりました。

分類器をPR側から実行しない

path-aware CIには重要な攻撃面があります。

PRが分類器自身を書き換えられると、自分を安全と判定して重い検査を消せます。

そのため分類器はPR headではなく、PR base SHA側の信頼済み版を実行します。

CIや分類器そのものを変更するPull Requestは自己免除できないようfull pathへ倒します。

さらに、未知のpath、変更一覧取得失敗、分類不能、package.jsonやlockfile、Playwright設定なども安全側へ倒します。

SAFEと証明できる → skip可能
分からない        → run

速くするために、安全側のデフォルトを反転させないことが重要です。

exact-head検証をfull CIのコピーにしない

Pull Requestの現在HEADと、検証対象SHAが同じであることは重要です。

しかし同一性を確認するために、通常CIと同じfull suiteをもう一度走らせる必要はありません。

以前は同じHEADへ二つの重い検査が入っていました。

同じPR head
├─ 通常CI：lint / typecheck / 全テスト / Chromium
└─ exact-head CI：lint / typecheck / 全テスト / Chromium

役割を分けました。

Ready PR
├─ integration CI
└─ exact-head identity

Final Candidate
└─ exact-SHA full gate

同じ証拠を二重に作らない。必要な段階で、一度だけ強い検査を行う。この方が、どの結果を最終判断に使うのかも明確になります。

skipはPASSではない

この設計で、技術的な最適化と同じくらい重要だったのが証拠の意味です。

browser suiteをskipしたPRについて、browser: PASSとは記録しません。実行していないからです。

正しくはNOT_RUNです。なぜ省略できたのかを別の証拠として記録します。

同様に、Postgresを起動しなかったPRについて、DB検査が成功したとは言えません。

実行量の削減と、証拠の強度は別に管理する。

Final Candidateでは別のfull exact-SHA gateを持ち、必要な証拠を同じSHAへ揃えます。

検査を減らしたことで、欠陥が見えやすくなった

CIが多すぎると、失敗が情報ではなく騒音になります。

無関係なflaky testが落ちる。古いrunがキャンセルされる。同じSHAへ複数workflowが走る。どの赤が今回の変更に由来するのか、切り分ける仕事が増えます。

その結果、本当に見るべき欠陥より、CIをGREENに戻す作業へ時間を使います。

逆に、変更内容に近い検査を狭く確実に走らせると、失敗の意味が強くなります。

例えば、Next.jsのroute moduleへ余分なexportを置くと本番ビルドだけが落ちる問題がありました。毎Pull Requestで重い本番ビルドを追加する代わりに、同じ型の欠陥だけを数秒で検出する静的Gateを作りました。

重要なのは、検査時間の長さではありません。

過去に実際に起きた欠陥を、次に確実に止められるか。

ここを基準にすると、広く重い検査を毎回走らせるより、壊れ方に対応した小さなGateの方が強い場合があります。

起動しても状態を変えられないrunnerも止める

PR側のCIを軽くしても、周辺workflowが同じイベントへ反応すれば固定消費は残ります。

私たちのAgent Integration Controllerは、複数のAIエージェントが作ったPull Requestを評価し、統合可能なものをmainへ送るsingle-writerです。

以前はReady PRへpushした直後にもControllerが起動していました。しかしその時点ではCIが実行中なので、正常に動いてもmergeできません。

そこで通常の統合判断を、成功したCIの完了イベントへ寄せました。

Ready PR push
  ↓
CI
  ↓
CI success
  ↓
Controller 1回

Draft PRのCIがskipされたとき、CIがfailureやcancelledで終わったとき、Ready PRの新しいheadでまだCIが完了していないときはController runnerを起動しません。

Draft側で通常CIのrunnerを止めても、そのskip通知を受けて別のControllerが起動していたら固定消費は消えません。イベント連鎖全体を見る必要があります。

10分cronはrecovery fallbackへ落とした

Controllerにはイベント取りこぼしや一時障害から状態を再評価するscheduleもありました。

従来は10分ごとでした。

144回 / 日
4,320回 / 30日

通常の統合はPRイベントとCI完了イベントで即時に起動できます。scheduleは通常処理ではなく、イベントを取りこぼしたときの回復経路です。

そこで1時間ごとへ落としました。

24回 / 日
720回 / 30日

定期起動回数は83.3%削減です。

通常のPR統合待ち時間は増やさず、イベント駆動を通常経路として残し、cronは最大約1時間で再評価するrecovery fallbackへ役割を限定しました。

ここで得た原則は単純です。

このjobは必要か、だけでなく、いま起動してこのjobは状態を変えられるかを見る。

merge後のpost-merge checkにも同じ固定燃焼が残る

PR側を軽くしても、mainへmergeされるたびに別のpost-merge workflowが重い準備を無条件で始めれば、最適化は途中で終わります。

main postmerge checkも、変更分類を依存導入より前へ移しました。

docs-only / README-onlyでは、npm ci、事実整合チェック、lint / typecheck cacheのrestore、lint、typecheckを省略します。

一方、conflict marker検査は依存不要なので常時維持します。未知path、差分取得不能、分類不能はfail-closedでコード変更側へ倒します。

ここでも新しいdocs専用classifierを作らず、PR CIと同じ分類器を正本にしました。分類ロジックをworkflowごとに増やすと、片方だけ安全判定が緩むからです。

Draft → Ready → merge → Controller → post-mergeまで、ライフサイクル全体で「必要になる前に高価な準備を始めない」ようにする。

AIエージェント開発でActionsを削るときは、PR workflowだけでなく、merge後に連鎖するworkflowまで同じ発火予算で監査する必要があります。

品質は何分使ったかでは測れない

GitHub Actionsの利用時間が多いと、よく検査しているように見えます。

しかし品質を守るのはrunner minutesではありません。

見るべきなのは、どの欠陥を止める検査か、現在のSHAを検査しているか、必要な環境で実行したか、失敗が必ずGateへ届くか、そして省略した理由を説明できるかです。

この基準で見ると、重複実行を減らすことは品質低下ではありませんでした。

証拠の鮮度と意味を上げる改善でした。

減らしたのは品質ではなく、儀式だった

CIを減らすとき、一番危険なのは、速くしたいから検査を消すことです。それは手抜きになります。

必要なのは、各検査について次を説明できることです。

1. どの欠陥を止めるのか
2. どの変更で必要になるのか
3. どの段階で証拠が必要か
4. 省略したとき、別のGateで守られるか
5. 判定に失敗した場合は安全側へ倒れるか

この説明ができないworkflowは、残っていても安心の儀式になりやすい。

私は以前、CIを多く走らせることを品質管理だと思っていました。

今は、品質管理とは、必要な欠陥を、必要な場所で、現在の変更に対して止めることだと考えています。

GitHub Actionsを減らしたら、検査が薄くなったのではありません。

何を確認しているのかが以前よりはっきりしました。

速いCIより、走らないCIを設計する

今回の改善で変えたのは、テストの品質ではなく、検査を発火させる条件です。

• DraftではGitHub-hosted runnerを起動しない
• Readyで変更pathをnpm ciより前に分類する
• code、browser、databaseを別軸にする
• exact-headはidentity確認とfull validationを分離する
• 未知の変更とCI自己変更はfull pathへ倒す
• 分類失敗をrequired checkのFAILへ変える
• skipをPASSとして扱わない
• Final Candidateで必要なexact-SHA証拠を揃える
• 状態を変えられないタイミングではController runnerも起動しない
• cronを通常経路にせず、イベント駆動のrecovery fallbackへ限定する
• post-mergeも依存導入前に分類する

この結果、docs-onlyの実PRでは通常CIを9分31秒から2分09秒へ短縮できました。

これからのCIで最初に問うべきは、どう速く走らせるかではなく、「この検査は、いま本当に走るべきか」です。

必要な証拠は、必要な瞬間にだけ完全に揃える。

AIエージェントの速度をrunner待ちと請求額へ変えず、事業の速度へ変えるには、ここまでを設計対象にする必要があります。