GitHub Actions再実行上限制約で見直すCI運用設計

GitHub Actionsの再実行上限は、一見すると小さな仕様変更です。しかし実務では、CI品質を改善するための強いトリガーになります。これまで「とりあえずrerun」で吸収していた不安定さが、明確に可視化されるからです。

再実行依存が生む3つの損失

• マージ遅延による開発待ち時間
• CI実行コストの増加
• 障害原因の恒常的な先送り

失敗分類を標準化する

1. コード起因の確定失敗
2. flaky test
3. 一時的な基盤障害
4. 設定/権限/ポリシー不整合

ジョブ別リトライ契約

• Unit test: 原則再実行なし
• Integration test: 回数限定+バックオフ
• デプロイ系: 人手承認後のみ
• セキュリティスキャン: 再実行で回避不可

CI観測指標の再定義

初回成功率、原因特定時間、flaky比率、1マージあたりCIコスト、再実行要求件数を継続計測します。

ガバナンス連携

保護ブランチ必須チェック、重要リポジトリのテンプレート固定、OIDC中心の認証、高権限ジョブ承認必須を組み合わせます。

90日ロードマップ

0-30日: 現状計測とflaky棚卸し
31-60日: ジョブ別再試行契約の適用
61-90日: コスト最適化と自動隔離運用

参考:
https://github.blog/changelog/month/04-2026/