保守を委託しているシステムについて、委託先から費用見直しの相談が届く。内訳を見ると「CI/CD実行環境の費用増」という行があり、それなりの金額が入っている。担当者に聞くと、ビルドの回数と時間の話が返ってくる。言っていることは分かるが、その金額が妥当かどうかは判断できない。
この相談が増えています。そして多くの場合、委託先が過大請求しているわけではありません。実際に増えています。ただし、増えた理由の半分は仕組みの側にあり、残り半分は誰も見ていなかったことにあります。
誰も止めないから増える
CI（継続的インテグレーション）は、コードが変更されるたびに自動でビルドとテストを走らせる仕組みです。品質を保つうえで有効で、いまや保守契約に含まれているのが普通です。
問題はその課金の形にあります。実行した分だけ課金される従量制で、しかも実行の引き金を引くのは開発者の日常動作です。コードを1行直して保存するたびに、数分から数十分の処理が走る。1回あたりの単価は小さいので、誰も気にしません。
そして、この仕組みには止める人がいません。
- 開発者は「テストが走るのは良いこと」と考えるので減らす動機がない
- 委託先の管理者は、請求が来るまで総額を見ていない
- 発注側は、そもそもそういう費用が発生していることを知らない
結果として、使われていない古いブランチのビルドが毎日走り続ける、1回のプッシュで同じテストが3系統動く、といった状態が数年放置されます。費用が増えたのではなく、増えていたことに気づく機会が今まで無かったというのが実際に近い形です。
2026年に何が変わったか
この構造が表に出たきっかけが、GitHub Actions の料金改定です。2025年12月に発表され、2026年に順次適用されました（GitHub Actionsの価格改定について — GitHubブログ）。
変更点は方向が2つに分かれています。
GitHubが用意する実行環境（GitHubホストランナー）は値下げされました。 2026年1月1日から適用され、標準的な構成では25%の値下げとされています。ここだけ見れば費用は下がるはずです。
一方、自社で用意した実行環境（セルフホストランナー）の扱いが変わりました。 発表当初は接続料として1分あたり0.002ドルの課金が示され、コミュニティからの反発を受けて課金の導入自体はいったん保留・再検討となりました（GitHub、Actionsの料金体系変更を発表 — gihyo.jp）。ただし2026年3月1日からは、セルフホストランナーの実行も無料使用枠を消費する対象になっています。
つまり、「自前のサーバーで動かしているから無料」という前提が崩れたのがこの改定の実質です。これまで自前環境のコストは委託先が自社のサーバー費用として吸収していたものが、利用量として見えるようになりました。
見直しの相談が今年に集中しているのは、この可視化が理由であることが多いはずです。
発注側が確認する4つのこと
技術的な詳細に踏み込む必要はありません。次の4点を聞けば、妥当性の判断材料は揃います。
| 確認すること | 妥当な状態 | 見直しが要る状態 |
|---|---|---|
| 月あたりの実行回数と合計時間 | 数字で即答できる | 「調べます」で止まる |
| 何をきっかけに実行されるか | 本番に関わる変更に限定されている | すべてのブランチ・すべての保存で走る |
| 1回の実行時間 | 数分〜十数分 | 30分以上が常態化している |
| 直近1年で見直したか | 定期的に棚卸ししている | 構築時から触っていない |
いちばん重いのは1行目です。 数字が出てこないということは、これまで誰も見ていなかったということです。その状態で提示された増額は、根拠の説明を受けているのではなく、請求額をそのまま転記されている可能性があります。悪意の話ではなく、単に管理されていなかったというだけです。
4行目も同じ意味を持ちます。構築時に組んだまま数年動いているCIは、その間に増えたテストや追加された処理がすべて積み上がっています。 減らす作業を誰も担当していなければ、増える方向にしか動きません。
削減は3方向。ただし削る順番がある
費用を下げる手段は、大きく3つに分かれます。
実行回数を減らす。 すべての変更で全部を走らせるのをやめ、本番に反映される変更にだけ重い処理を走らせる。効果が大きく、品質への影響も小さい部分です。使われていない古いブランチの定期実行を止めるだけで下がることもあります。
実行時間を短くする。 処理結果を再利用する設定を入れる、並列で動かす、不要になった処理を外す。ここは技術的な作業になるので、委託先に工数が発生します。削減額と工数を比べて判断してください。
実行環境を変える。 提供元を変える、自前の環境に寄せる。効果は出ますが、移行の手間と運用の責任が動きます。CIが止まったときに誰が直すのかまで決めずに移すと、後で高くつきます。
手を付ける順序は、この並びのとおりです。 いちばん下から入る提案が来たら、上2つを先にやったのかを確認してください。実行回数の見直しをせずに環境だけ移すと、無駄な実行を安い場所で続けるだけになります。
依存パッケージの更新を数日待たせる設定が既定に入った話も、同じ「自動実行を無条件に走らせない」流れの中にあります（Dependabotが既定で3日待つ）。AI開発支援ツールの従量課金についても構造は同じで、トークン消費の可視化で扱いました。
増額を断るより、可視化を頼む
現実的な進め方として、増額の可否をその場で判断しようとしないことを勧めます。判断材料が無い状態で交渉しても、双方が消耗するだけです。
代わりに頼むのは、直近3か月分の実行回数・合計時間・費用を月別に出してもらうことです。この資料は作れるはずのもので、作れないなら管理されていなかったということが分かります。どちらの結果でも、次に何を決めるべきかがはっきりします。
そのうえで、実行回数の内訳を見てください。多くの場合、上位の数項目で全体の大半を占めます。 そこだけ見直せば済むのか、全体的に多いのかで、必要な作業量が変わります。ここまで揃えば、増額を受け入れるか、削減作業を先に発注するかを比べられます。
保守費用の内訳をどう読むかという全体の話は業務システムの保守費用に、発注段階で費用構造をどう握るかはシステム開発の外注で失敗しない発注ガイドにまとめています。
委託先から提示された保守費用の内訳が妥当か第三者の目で見てほしい、CI/CDを含めた運用コストを一度整理したい——そうしたご相談は、グリームハブの開発・AI・自動化のご相談で承っています。要件によって最適な構成は変わるため、個別にお見積りします。お問い合わせからご相談ください。
