配布資料 43事例 #03: デプロイ乱発で CI 無料枠が枯渇し、自動化が全停止した

AI は速いです。速いぶんだけ、従量課金の枠も速く溶けます。 そんなことは分かっていたつもりでしたが、止まってから気づきました。

何が起きたか

• ある月の前半、master への push ごとに CI がフルビルドを自動実行していました。約80回です
• 追い打ちで、セキュリティ改修の逐次検証のために1日に10回の staging デプロイを実施しました
• 翌日、GitHub Actions の無料枠 2,000分/月を使い切り、CI 全体が停止しました。 デプロイビルドもシークレットスキャンも動きません

予算を追加して復旧しましたが、その日以降のデプロイと検査がすべて止まりました。

なぜ起きたのか

表面的には、例外条件に該当しない単独デプロイの乱発です。

構造は3つ重なっていました。 ①「デプロイを伴わないマージでも毎回フルビルドする」自動トリガーの設計 ②「イシューごとに逐次 staging 検証」という進め方自体が高コスト（1回およそ15分の CI + デプロイ）なのに、まとめて検証するキュー化の規律がなかったこと ③そして——AI は教えなければ、他サービスの従量課金・無料枠の概念を考慮しません

そこから生まれたルール

「staging デプロイはセッション原則1回。完了イシューは In Review キューに貯めて一括デプロイ・一括検証する」。バッチデプロイを既定の運用にしました。

「利用者の指示が逐次形でも、例外条件（DB マイグレーション・金銭変更・緊急修正）に該当しなければキュー化を先に提案する」

「セッション切り上げ時に当月の CI 消費を確認する」

どう機械に守らせたか

①push 時の自動フルビルドを撤去し、手動 dispatch のみにしました ②PreToolUse フックが staging デプロイ系のコマンドを検知し、前回デプロイから4時間未満ならブロックします。 時刻はマーカーファイルでセッションを跨いで共有します

例外時のみ明示トークンでバイパスでき、そのときは理由をイシューに記録します。

持ち帰るなら

AI に運用を任せるなら、コストが漏れる操作——CI・API 課金・クラウド資源——には時間ベースのレートリミットをフックで付けてください。

「注意して使う」は効きません。枠の消費を定期確認する動作も、ルーチンに組み込んでおくといいです。