## 最初は「全部移せば安くなる」と思っていた
自宅の Mac 1 台を CI サーバーに仕立てて、いくつかのリポジトリのテストやビルドをそこで回すようにしました。クラウドの CI に払っていた料金が浮くはずだ——最初の動機は、わりと単純なコスト削減でした。
うまく回り始めると、欲が出ます。テストもビルドも自前で動くなら、リリースも、デプロイも、設定同期のジョブも、全部こっちに寄せてしまえばいい。そう考えて、5 つ目のリポジトリで「リリース系のワークフローも自前に移そう」と手を動かしかけました。
そこで一度立ち止まって、移す前に実測の数字を取ってみたのです。結果、考えが変わりました。今日はその話を、判断のフレームとして残しておきたいと思います。
## 「安い」と言うなら、いくら安いのかを数字で出す
CI の課金は、ざっくり言えば「実行頻度 × 1 回あたりの時間」で決まる従量制です。クラウドの CI（ここでは GitHub Actions を例にします）は、Linux 環境で 1 分あたり数円という単価で、しかもプランによっては月に 2,000〜3,000 分の無料枠が付いてきます。
つまり、移管によって本当に浮くお金を知りたければ、見るべき数字は 3 つだけです。
- そのワークフローは月に何回走っているか（実行頻度）
- 1 回あたり何分かかっているか（平均時間）
- 上記をかけ合わせた「課金対象の分数（billable minutes）」が、無料枠を食いつぶしているのか
実測は難しくありません。`gh run list` のようなコマンドで直近 30 日の実行履歴を引けば、回数も所要時間もすぐ出ます。
```bash
gh run list --workflow=release.yml --created ">=2026-04-28"
```
これで取った数字を、単価と無料枠に当てるだけ。勘で「重そうだから移そう」と判断していたものが、いきなり金額になって目の前に並びます。
## 移管推奨度は、月コストで 3 つに分かれる
実際に複数のリポジトリで測ってみて、判断はおおむね 3 区分に落ち着きました。
- **月 5 ドルを超える**ようなワークフロー → 積極的に自前へ移す価値あり
- **月 1〜5 ドル**くらい → リポジトリの重要度しだい。頻繁に走るテスト系なら移す、本番に直結するものは慎重に
- **月 1 ドル未満** → 移管のメリットは薄い。とくに本番影響があるものは、わざわざ移さない方がいい
この線引きが、後で効いてきます。
## 実測の結果、リリース系は「月 30 円」だった
問題のリリース系ワークフローを測ってみたら、こうなりました。
- リリースのジョブ：月 9 回 × 約 60 秒
- 設定同期のジョブ：月 15 回 × 約 70 秒
- 合わせて、**月およそ 0.21 ドル。日本円で 30 円ほど**
正直、拍子抜けしました。「全部移せば安くなる」と思っていた当のリリース系が、移したところで月 30 円しか浮かない。しかも無料枠の内側に収まっていれば、実質ゼロ円です。
一方で、PR のたびに走るテストや E2E は頻度が桁違いなので、まとめれば月 1 ドル超になり、こちらは無料枠を圧迫する側でした。
## 同じ「移管」でも、答えが非対称になる
ここで効いてきたのが、コスト以外の軸です。リリースやデプロイのワークフローは、走らせると **GitHub のタグを切り、顧客の環境が自動更新され、本番の API が同期される**——つまり本番影響が大きい。
その本番リリースを、自宅の Mac 1 台に依存させるとどうなるか。Mac が落ちれば、停電すれば、トンネルが切れれば、リリースができなくなる。いわゆる単一障害点（SPOF）です。
月 30 円の節約のために、本番リリースの命綱を Mac 1 台に握らせる。これは、どう転んでも割に合いません。
そこで判断はこう分かれました。
- **テスト・E2E** → 頻発するし、落ちても困るのは自分だけ → **自前に移す**
- **リリース・デプロイ** → コストはほぼゼロ、でも本番影響が大きい → **クラウド（GitHub Actions）に据え置く**
同じ「自前 CI への移管」という話なのに、ワークフローの性質によって結論が真逆になる。この**非対称さ**こそが、実測しないと見えてこなかったものでした。
## 「自前=安い」という通説への、ささやかな反証
自前インフラは安い、というのは半分本当で半分嘘です。頻繁に走る重いジョブを大量に抱えているなら、たしかに自前は効きます。けれど、たまにしか走らないジョブを「安くなるはず」という思い込みだけで寄せると、**浮くのは数十円、引き受けるのは可用性リスクと運用負担**という、まったく割に合わない取引になります。
CI の移管は、料金表だけを見て決める話ではありません。コストに、可用性と運用負担を足した総合点で判断する。そして総合点は、ワークフローごとに違う。だから「全部移す」も「全部残す」も、たいてい間違いなのだと思います。
## 現役実装者の視点
正直に書くと、私も最初は「全部こっちに寄せる」つもりで手を動かしていました。自宅の Mac を CI ステーションに仕立てた時点で気分が乗ってしまって、テストが動いた勢いのまま、リリースも設定同期も移す前提でワークフローを書き換え始めていたのです。止めたのは、移管作業の途中で「そういえばこれ、いくら浮くんだっけ」と一瞬手が止まったからでした。後付けの正論ではなく、本当にたまたまでした。そこで `gh run list` を叩いて出てきたのが「月 30 円」で、書きかけの YAML を閉じました。
考えが変わった決め手は、コストの数字そのものより、**コストが小さいと分かった瞬間に、別の軸が前に出てきた**ことです。月 30 円しか浮かないと判明した途端、頭の中の天秤に乗っていた重りが入れ替わって、「では自宅の Mac が落ちたときにリリースが止まる件は？」という、それまで見て見ぬふりをしていた問いが急に大きく見えました。実際この Mac は、私が OS をアップデートした夜や、自宅のルーターを再起動したタイミングでトンネルが切れたことが何度かあります。テストが落ちる分には翌朝直せばいいのですが、本番リリースの命綱がそこにぶら下がっているのは、たとえ無料だとしても引き受けたくない性質のリスクでした。可用性と運用負担は、金額に換算されないぶん、実測しないと天秤に乗ってこないのだと痛感しました。
もし今、顧問先に同じ相談をされたら、私はおそらく「移す/残すを決める前に、対象ワークフローの billable minutes を 30 日ぶん出してください」とだけ先に返すと思います。金額が出てしまえば、議論の半分は自動的に終わるからです。そのうえで、月数ドルを超える頻発ジョブは自前に寄せて、本番に触るジョブはコストが小さくてもクラウドに残す——この線引きを、3 区分のフレームと一緒に文書で渡します。私自身、この判断を残しておかなかったら、半年後にまた「全部移そう」と同じ作業をやり直していたはずです。意思決定は、再現できる形にして初めて次に効く、というのが今回いちばん身に染みたところでした。
最初は「全部移せば安くなる」と思っていた
自宅の Mac 1 台を CI サーバーに仕立てて、いくつかのリポジトリのテストやビルドをそこで回すようにしました。クラウドの CI に払っていた料金が浮くはずだ——最初の動機は、わりと単純なコスト削減でした。
うまく回り始めると、欲が出ます。テストもビルドも自前で動くなら、リリースも、デプロイも、設定同期のジョブも、全部こっちに寄せてしまえばいい。そう考えて、5 つ目のリポジトリで「リリース系のワークフローも自前に移そう」と手を動かしかけました。
そこで一度立ち止まって、移す前に実測の数字を取ってみたのです。結果、考えが変わりました。今日はその話を、判断のフレームとして残しておきたいと思います。
「安い」と言うなら、いくら安いのかを数字で出す
CI の課金は、ざっくり言えば「実行頻度 × 1 回あたりの時間」で決まる従量制です。クラウドの CI（ここでは GitHub Actions を例にします）は、Linux 環境で 1 分あたり数円という単価で、しかもプランによっては月に 2,000〜3,000 分の無料枠が付いてきます。
つまり、移管によって本当に浮くお金を知りたければ、見るべき数字は 3 つだけです。
- そのワークフローは月に何回走っているか（実行頻度）
- 1 回あたり何分かかっているか（平均時間）
- 上記をかけ合わせた「課金対象の分数（billable minutes）」が、無料枠を食いつぶしているのか
実測は難しくありません。gh run list のようなコマンドで直近 30 日の実行履歴を引けば、回数も所要時間もすぐ出ます。
gh run list --workflow=release.yml --created ">=2026-04-28"
これで取った数字を、単価と無料枠に当てるだけ。勘で「重そうだから移そう」と判断していたものが、いきなり金額になって目の前に並びます。
移管推奨度は、月コストで 3 つに分かれる
実際に複数のリポジトリで測ってみて、判断はおおむね 3 区分に落ち着きました。
- 月 5 ドルを超えるようなワークフロー → 積極的に自前へ移す価値あり
- 月 1〜5 ドルくらい → リポジトリの重要度しだい。頻繁に走るテスト系なら移す、本番に直結するものは慎重に
- 月 1 ドル未満 → 移管のメリットは薄い。とくに本番影響があるものは、わざわざ移さない方がいい
この線引きが、後で効いてきます。
実測の結果、リリース系は「月 30 円」だった
問題のリリース系ワークフローを測ってみたら、こうなりました。
- リリースのジョブ：月 9 回 × 約 60 秒
- 設定同期のジョブ：月 15 回 × 約 70 秒
- 合わせて、月およそ 0.21 ドル。日本円で 30 円ほど
正直、拍子抜けしました。「全部移せば安くなる」と思っていた当のリリース系が、移したところで月 30 円しか浮かない。しかも無料枠の内側に収まっていれば、実質ゼロ円です。
一方で、PR のたびに走るテストや E2E は頻度が桁違いなので、まとめれば月 1 ドル超になり、こちらは無料枠を圧迫する側でした。
同じ「移管」でも、答えが非対称になる
ここで効いてきたのが、コスト以外の軸です。リリースやデプロイのワークフローは、走らせると GitHub のタグを切り、顧客の環境が自動更新され、本番の API が同期される——つまり本番影響が大きい。
その本番リリースを、自宅の Mac 1 台に依存させるとどうなるか。Mac が落ちれば、停電すれば、トンネルが切れれば、リリースができなくなる。いわゆる単一障害点（SPOF）です。
月 30 円の節約のために、本番リリースの命綱を Mac 1 台に握らせる。これは、どう転んでも割に合いません。
そこで判断はこう分かれました。
- テスト・E2E → 頻発するし、落ちても困るのは自分だけ → 自前に移す
- リリース・デプロイ → コストはほぼゼロ、でも本番影響が大きい → クラウド（GitHub Actions）に据え置く
同じ「自前 CI への移管」という話なのに、ワークフローの性質によって結論が真逆になる。この非対称さこそが、実測しないと見えてこなかったものでした。
「自前=安い」という通説への、ささやかな反証
自前インフラは安い、というのは半分本当で半分嘘です。頻繁に走る重いジョブを大量に抱えているなら、たしかに自前は効きます。けれど、たまにしか走らないジョブを「安くなるはず」という思い込みだけで寄せると、浮くのは数十円、引き受けるのは可用性リスクと運用負担という、まったく割に合わない取引になります。
CI の移管は、料金表だけを見て決める話ではありません。コストに、可用性と運用負担を足した総合点で判断する。そして総合点は、ワークフローごとに違う。だから「全部移す」も「全部残す」も、たいてい間違いなのだと思います。
現役実装者の視点
正直に書くと、私も最初は「全部こっちに寄せる」つもりで手を動かしていました。自宅の Mac を CI ステーションに仕立てた時点で気分が乗ってしまって、テストが動いた勢いのまま、リリースも設定同期も移す前提でワークフローを書き換え始めていたのです。止めたのは、移管作業の途中で「そういえばこれ、いくら浮くんだっけ」と一瞬手が止まったからでした。後付けの正論ではなく、本当にたまたまでした。そこで gh run list を叩いて出てきたのが「月 30 円」で、書きかけの YAML を閉じました。
考えが変わった決め手は、コストの数字そのものより、コストが小さいと分かった瞬間に、別の軸が前に出てきたことです。月 30 円しか浮かないと判明した途端、頭の中の天秤に乗っていた重りが入れ替わって、「では自宅の Mac が落ちたときにリリースが止まる件は？」という、それまで見て見ぬふりをしていた問いが急に大きく見えました。実際この Mac は、私が OS をアップデートした夜や、自宅のルーターを再起動したタイミングでトンネルが切れたことが何度かあります。テストが落ちる分には翌朝直せばいいのですが、本番リリースの命綱がそこにぶら下がっているのは、たとえ無料だとしても引き受けたくない性質のリスクでした。可用性と運用負担は、金額に換算されないぶん、実測しないと天秤に乗ってこないのだと痛感しました。
もし今、顧問先に同じ相談をされたら、私はおそらく「移す/残すを決める前に、対象ワークフローの billable minutes を 30 日ぶん出してください」とだけ先に返すと思います。金額が出てしまえば、議論の半分は自動的に終わるからです。そのうえで、月数ドルを超える頻発ジョブは自前に寄せて、本番に触るジョブはコストが小さくてもクラウドに残す——この線引きを、3 区分のフレームと一緒に文書で渡します。私自身、この判断を残しておかなかったら、半年後にまた「全部移そう」と同じ作業をやり直していたはずです。意思決定は、再現できる形にして初めて次に効く、というのが今回いちばん身に染みたところでした。
