「自動化すれば、もっと楽になる」
そう思っていた。
私は現在、AIを使いながらブラウザゲームを個人制作している。コードを変更したらGitHubに保存し、GitHub Actionsが動き、サーバーへ公開する。スクリーンショットも自動で撮影する。そこまで自動化できれば制作以外の仕事をかなり減らせると思っていた。
ところが利用状況を確認して驚いた。自動化した作業が、想像以上の速さで利用枠を消費していた。
GitHub Actionsは「無制限無料」ではない
GitHub Actionsは、テスト、デプロイ、定期処理、ブラウザ操作などをGitHub側の実行環境で自動化できる仕組みだ。
便利だが、実行環境や利用時間によってコストが変わる。
LinuxとmacOSでは料金が大きく違う
2026年10月時点のGitHub公式料金表では、標準ランナーの超過利用料金はLinux（2コア）0.006ドル/分、Windows（2コア）0.010ドル/分、macOS（3〜4コア）0.062ドル/分。
macOSはLinuxの約10.3倍。
無料枠の残量表示と実際の請求額は別なので、古い換算情報ではなく最新のBilling画面を見るのが確実だ。
スクリーンショット1枚のために何分も動いていた
私はSNS用のゲーム画面を自動撮影していた。ブラウザを起動し、ゲームを開き、必要な場面まで進み、撮影する。
1回8〜9分かかることもあり、再実行や別画面の撮影を重ねると実行時間はすぐ積み上がる。
自動処理は、人間が働かない代わりに計算機が働いている。
本番公開の自動化にも落とし穴があった
小さな修正のたびに本番デプロイが自動実行されると、セリフ1行や表示位置の変更でも毎回サーバー接続や確認が走る。
コードの変更量と、自動処理の実行時間は比例しない。
そこで私は自動化を減らした
SNS用の自動スクリーンショットを停止し、本番公開もpushのたびではなく、複数修正をまとめて必要なときだけ手動実行する方式に変えた。
GitHub Actionsの workflow_dispatch を使えば、Actions画面の「Run workflow」から必要な時だけ実行できる。
GitHub Actionsをやめたのではない。動くタイミングを変えた。
ただし、安全確認まで削ってはいけない
節約のために、必要ファイルの確認、失敗時の復旧、公開前の安全確認まで消すのは危険だ。
以前、PCでは動くのに一部スマホで壊れる問題も経験した。詳しくは「自分のPCでは動くのに、他人のスマホではゲームが壊れる。原因を追って分かったWeb公開の罠」に書いた。
削るべきなのは安全性ではなく、必要のない回数と必要のない処理だ。
GitHub Actionsの利用枠を節約するために見る場所
runs-on でランナーを確認する。push、schedule、workflow_dispatch など起動条件を確認する。Actions履歴で実行回数と時間を見る。Billingで実際の利用状況を見る。
macOS固有機能が不要ならLinuxに変えられないか検討する。さらに予算と通知を設定して、想定外の消費に早く気づけるようにする。
「全部自動化する」は本当に効率的なのか
自動化にも設定、保守、失敗調査、実行コストがある。そして一番厄介なのは、その自動化が今も必要かを考えなくなることだ。
AIで自動化が簡単になったからこそ、やめる判断が重要
今はAIに頼めば複雑なワークフローも短時間で作れる。しかし簡単に作れることと、維持する価値があることは別だ。
作るコストだけでなく、動かし続けるコストまで考える必要がある。
私が本当に作りたかったのは、自動化システムではない
私はゲームを作りたい。面白いキャラクターや、続きを遊びたくなる物語を作りたい。
GitHub Actionsを完璧に使いこなすこと自体が目的ではない。
自動化は、多ければ多いほどよいわけではない。
必要なときに必要な処理を動かし、不要な処理は止め、安全に関わる確認は残す。それで十分だ。
私は今、その考え方でブラウザゲーム「ORA Quest Sin」の制作を続けている。
コメント