---
title: E2EをCIで回してGitHub Actionsの無料枠を月初3日で使い切った話 〜「並列で速い」は「安い」ではなかった〜
tags:  #ai駆動開発 #github actions #ci/cd #e2e #テスト自動化  
author: [星影](https://docswell.com/user/unsoluble_sugar)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/D7Y4YYQMEM.jpg?width=480
description: Zennで書いた記事のダイジェスト版です。  ▼E2EをCIで回してGitHub Actionsの無料枠を月初の3日で使い切った話 https://zenn.dev/unsoluble_sugar/articles/github-actions-e2e-free-tier
published: September 30, 26
canonical: https://docswell.com/s/unsoluble_sugar/ZPR3R2-2026-09-30-github-actions-e2e-free-tier
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/D7Y4YYQMEM.jpg)

T E C H TA L K
E2EをCIで回して
GitHub Actionsの無料枠を
月初3日で使い切った話
〜「並列で速い」は「安い」ではなかった〜
2026/09/30
@unsoluble_sugar


# Page. 2

![Page Image](https://bcdn.docswell.com/page/VENYPPK3J8.jpg)

今日話すこと
1
何が起きたか
2
料金がどう決まるか
3
使った時間を計測する
4
対策と、その後の考え方
2


# Page. 3

![Page Image](https://bcdn.docswell.com/page/Y79P33VPE3.jpg)

注目ポイント3つ
CI: コードを直すたびに、自動でテストを走らせてくれる仕組み
E2Eテスト: 実際にブラウザを動かして、画面の操作が壊れていないか確かめるテスト
ジョブ: CIの中で動く作業のひとかたまり。料金はこのジョブごとに数えられる
今日の話を一言で: このジョブの数え方を知らずにCIを組んだら、無料枠が3日で消えた
3


# Page. 4

![Page Image](https://bcdn.docswell.com/page/G78DMMPX7D.jpg)

CHAPTER 01
何が起きたか


# Page. 5

![Page Image](https://bcdn.docswell.com/page/L7LM331NJR.jpg)

月初3日間の実績
139 回
2,777 分
93 %
CIが動いた回数
料金として数えられた時間
無料枠3,000分に対する割合
個人で作っているブラウザゲーム集。3日間で514個のジョブが動いた
金額に直すと$16.66ぶん。上限を設定していたので実際の請求は$0だった
5


# Page. 6

![Page Image](https://bcdn.docswell.com/page/4EMYDDWQEW.jpg)

気づいたきっかけは90%アラートメール
9月4日、GitHubから「無料枠の90%を
使った」という通知が届く
使用量を見ると 2,703 / 3,000分
設定ファイルを眺めても、どこで使って
いるのか分からない
使用量が90%に達したBilling画面
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/PER944YKJ9.jpg)

使用量の詳細はアカウント設定から確認できる
Settings → Billing and licensing →
Overview → Metered usage → Actions
リポジトリごとの使用量も出てくる
リポジトリごとの内訳まで確認できる
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/P7XQ22G5EX.jpg)

日ごとの減り方
日
使った分数
金額換算
9/2
471
$2.83
9/3
1,299
$7.79
9/4
1,007
$6.04
合計
2,777
$16.66
このペースが続くと: 月およそ27,800分。
上限を外していたら月 約$149 の請求
8


# Page. 9

![Page Image](https://bcdn.docswell.com/page/37K9MM4R7D.jpg)

CHAPTER 02
作っていたものと
CIの組み方


# Page. 10

![Page Image](https://bcdn.docswell.com/page/LJ3WYYLGJ5.jpg)

作っていたアプリ
ブラウザで遊ぶミニゲーム集。作ったも
のを置くだけの素朴な作り
Firebase Hostingで公開。スマホにアプ
リとして入れることもできる（PWA）
音や保存など共通の仕組みを1つにまと
め、ゲームのルールは切り離してある
開発中のゲームたち
10


# Page. 11

![Page Image](https://bcdn.docswell.com/page/8JDK55NNEG.jpg)

用意していたテスト
種類
中身
かかる時間
ユニットテスト
小さな単位で動作を確認 392件
数十秒
E2Eテスト
実際にブラウザを操作して確認 433件（PC＋スマホ）
約3分
コードのルール確認
書き方が決めたルールに沿っているか
数秒
11


# Page. 12

![Page Image](https://bcdn.docswell.com/page/VEPKGG5N78.jpg)

問題が起きたときのCIの組み方
変更を提出するたび、本番に取り込むたびに、毎回すべてのテストを実行
E2Eは待ち時間を縮めるため、6つに分けて同時に走らせていた
取り込み時には、さらにSafari系とFirefoxでの確認も追加
目標は「待ち時間5分前後」。速さだけを見て組んだ構成だった
12


# Page. 13

![Page Image](https://bcdn.docswell.com/page/27VV66PY7Q.jpg)

CHAPTER 03
料金がどう決まるか


# Page. 14

![Page Image](https://bcdn.docswell.com/page/5JGLNNPW7L.jpg)

料金は「ジョブごとに1分単位」で数える
公開リポジトリは無料。非公開は月3,000分の無料枠から減っていく
動かすOSで倍率が変わる。Linuxは1分＝1分、Windowsは2倍、macOSは10倍
1つのジョブが1分10秒で終わっても2分として数え、それを全ジョブぶん足す
分けて同時に走らせるほど、切り上げのムダと毎回の準備時間がジョブの数だけ増える
ここが罠: 「待ち時間が短いこと」と「料金が安いこと」はまったく別の話
14


# Page. 15

![Page Image](https://bcdn.docswell.com/page/47QYQQ2QEP.jpg)

CHAPTER 04
使った時間を
計測する


# Page. 16

![Page Image](https://bcdn.docswell.com/page/KE4WNNLYJ1.jpg)

実際の実行時間をAPIで集計する
月以降の実行を列挙
# 9
gh api --paginate "repos/<owner>/<repo>/actions/runs?created=>=2026-09-01" \
-q '.workflow_runs[] | "\(.id)\t\(.event)"'
#
実行ごとのジョブ時間（秒）
gh api "repos/<owner>/<repo>/actions/runs/<id>/jobs" \
-q '.jobs[] | "\(.name)\t\((.completed_at|fromdateiso8601) - (.started_at|fromdateiso8601))"'
ポイント: 設定ファイルを読むだけでは分からない。実際に何分動いたかを1件ずつ計測す
る
16


# Page. 17

![Page Image](https://bcdn.docswell.com/page/L71Y55LNJG.jpg)

何にいちばん使っていたか
ジョブの種類
使った分数
割合
E2Eテスト（6分割 × PC・スマホ）
1,467
58%
事前チェック（コードのルール確認・ユニットテスト）
858
34%
Safari系・Firefoxでの確認
174
7%
17


# Page. 18

![Page Image](https://bcdn.docswell.com/page/G7WG55QME2.jpg)

変更1回あたりの内訳（実測）
ジョブ
時間
中身
事前チェック
3.0分
コード取得 → 準備 → コードのルール確認 → ユニットテスト
E2E 1〜6
4.9〜10.3分
6つとも、コード取得とブラウザ準備（約1.5分）からやり直す
合計
約45分
画面で見える待ち時間は10分ほど
本番に取り込むときはさらにSafari系・Firefoxの確認が加わり、1回55〜65分
18


# Page. 19

![Page Image](https://bcdn.docswell.com/page/4JZLNNWME3.jpg)

原因は5つの掛け算だった
倍率
中身
×2
提出時と取り込み時の2回実行（手元も含めると実質3回）
×6
6つに分割。準備1.5分と切り上げのムダがジョブの数だけ増える
×2
PC版とスマホ版で2回。半分は同じ内容の確認
×139回
AIエージェントが自動で進めるので1日46回。人の手なら数回
+174分
月に数回で足りるSafari系・Firefoxの確認を毎回実行
19


# Page. 20

![Page Image](https://bcdn.docswell.com/page/YE6W88G5EV.jpg)

「並列で速い」は
「安い」ではない
待ち時間を16分→5分に縮めた代わりに、料金は10分→45分に増えていた
20


# Page. 21

![Page Image](https://bcdn.docswell.com/page/GE5M99VGE4.jpg)

CHAPTER 05
対策


# Page. 22

![Page Image](https://bcdn.docswell.com/page/9729223DJR.jpg)

手をつける順番
効果:大
動かす場面を減らす
→
効果:中
分け方を数え方に合わせる
→
効果:小〜中
速くするのは最後
順番が大事: 高速化から手をつけても、料金が膨らむ構造はそのまま残る
22


# Page. 23

![Page Image](https://bcdn.docswell.com/page/DJY4YY1M7M.jpg)

1
そもそも動かす場面を減らす
E2EをCIから外して手元に移した。CIはコードのルール確認とユニットテストだけ
E2Eは1つのコマンドにまとめ、手元から送る直前に自動で走るようにした
急いでいるときは環境変数を付けて飛ばせる逃げ道も用意
Gitの標準機能だけで実現しているので、追加のパッケージはいらない
23


# Page. 24

![Page Image](https://bcdn.docswell.com/page/V7NYPP23E8.jpg)

設定ファイルで起動条件を絞る
1
on:
pull_request:
paths-ignore: ["**/*.md", "docs/**", ".claude/**"]
push:
branches: [main]
paths-ignore: ["**/*.md", "docs/**", ".claude/**"]
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
効果: 文章だけの変更ではCIを動かさない。続けて送ったときは前の実行を自動で打ち切る
24


# Page. 25

![Page Image](https://bcdn.docswell.com/page/YJ9P331P73.jpg)

2
分け方を料金の数え方に合わせる
E2Eは、必要なときだけ手動で動かす形に変更
6分割をやめ、分けるのは本当に必要な場面だけに限定
Safari系・Firefoxの確認も手動実行にまとめた
準備1.5分×6と、切り上げのムダ×6がまるごと消える
25


# Page. 26

![Page Image](https://bcdn.docswell.com/page/GJ8DMM4XJD.jpg)

3
速くするのは最後
変更内容を見て、E2Eの対象を絞り込むスクリプトを用意した
ゲーム1本だけ直したとき → そのゲームのテストだけ（1〜2分）
文章やユニットテストだけ直したとき → E2Eは0分
共通部分やデザインを直したとき → 全部実行（約3分）
判断がつかないときは、安全側に倒して全部実行
26


# Page. 27

![Page Image](https://bcdn.docswell.com/page/LJLM336NER.jpg)

対策前と対策後
場面
変更前
変更後
変更を提出・更新
事前チェック＋E2E6分割 = 34〜51分
事前チェックのみ = 2〜6分
本番に取り込む
＋Safari系・Firefox = 55〜65分
事前チェックのみ = 2〜6分
文章だけの変更
同上
CIを動かさない = 0分
E2E
CIで毎回すべて
手元で変更部分だけ（0〜2分）
1回の取り込みが約100分 → 4〜12分。残り223分でこなせる回数は約2回→18〜55回
27


# Page. 28

![Page Image](https://bcdn.docswell.com/page/47MYDD5Q7W.jpg)

対策後のCI実行結果
28


# Page. 29

![Page Image](https://bcdn.docswell.com/page/P7R9443KE9.jpg)

見送った案と理由
分割を6個から2個に減らす
自前のマシンで動かす
→ それでも1回60分ほど残り、足りない
→ 無料だが、管理の手間が個人開発には重い
リポジトリを公開する
翌月のリセットを待つ
→ 効果は最大だが、非公開の方針を優先
→ 26日間もCIなしで進めるのは無理がある
29


# Page. 30

![Page Image](https://bcdn.docswell.com/page/PJXQ22457X.jpg)

同じことを繰り返さないために
実行ごとの分数を、いつでも集計できる状態にしておく
設定ファイルの冒頭に方針をコメントで残す（料金はジョブの合計、E2Eは手元で）
AIエージェント向けのルールにも、同じ方針を書いておく
1回の取り込みは4〜12分が目安。10分を超えたら構成を疑う
30


# Page. 31

![Page Image](https://bcdn.docswell.com/page/3JK9MMZRJD.jpg)

つまずきポイント
「並列で速い」＝「安い」ではない
自分の集計と請求がズレる
→ 待ち時間と料金は別の指標として見る
→ ジョブごとの切り上げで2,518分が2,777分に
CIでだけ失敗する
途中で止めても料金はかかる
→ 環境の違いで「CIで確認」の往復が増える
→ 走った分は課金される。まとめて送るのが先
31


# Page. 32

![Page Image](https://bcdn.docswell.com/page/LE3WYYDGE5.jpg)

まとめ
料金はジョブごとに切り上げて合計。分
1
けて同時に走らせるほど増える
2
原因は倍率の掛け算。実行時間を計測し
て初めて見えた
AIエージェント時代は「1日何回動くか」
3
でCIを設計する
4
動かす場面を減らすのが最優先。結果、1
回約100分が4〜12分に
32


# Page. 33

![Page Image](https://bcdn.docswell.com/page/8EDK55PN7G.jpg)

参考
元記事: E2EをCIで回してGitHub Actionsの無料枠を月初の3日
で使い切った話
zenn.dev/unsoluble_sugar/articles/github-actions-e2e-free-tier
GitHub Actions の課金について（GitHub Docs）
docs.github.com/ja/billing/.../about-billing-for-github-actions
33