ある日、Googleから約70万円の請求が来ました。

正確には、Google Places APIを使った営業自動化バッチが約11日間止まらずに動き続けていました。エラーで落ちたのではありません。むしろ正常に動いていた。正常に動き続けた結果、APIリクエストが積み上がり、請求額が一気に膨らみました。

この記事は、AI自動化やAIエージェントを事業に入れるなら必ず考えるべき「終了条件」「予算上限」「監視」の話です。技術的に難しい事故ではありません。だからこそ怖い事故でした。

何を自動化しようとしていたのか

やろうとしていたのは、店舗向け営業の前工程です。

Googleマップ上の店舗情報を取得し、業種とエリアの組み合わせから見込み客リストを作る。その後、問い合わせフォームを探し、案内文を送る。人間がやると時間がかかる作業なので、Google Places APIとブラウザ自動操作を使って自動化しようとしていました。

対象は、30業種 × 62エリア。合計すると約1,860パターンです。

この組み合わせから店舗リストを作り、フォーム営業につなげる。発想としては自然でした。小規模事業では、人を増やす前に仕組みで営業の母数を増やしたくなります。AIと自動化ツールを使えば、かなりの部分は実装できます。

問題は、自動化したことではありません。

止め方を設計していなかったことです。

原因は while true とリード自動補充

バッチの構造は、平たく書くとこうでした。

while true
  リードを送信する
  残件数がゼロなら bulk-search を実行する
  Google Places APIでリードを補充する
  送信を再開する
done

送るリードがなくなったら、自動でリードを補充する。これは一見、親切な設計です。夜中にリストが枯渇しても、翌朝また動いている。営業の前工程が止まらない。

でも、この設計には終了条件がありませんでした。

  • 今日は何件まで
  • 今月は何円まで
  • 何回補充したら止める
  • 新規リードが一定数以下なら止める
  • API使用量が異常なら止める

こうしたブレーキがないまま、「足りなくなったら補充する」を組み込んでいました。

さらに同種のバッチが2並列で動いていました。1本でも危ないループが、2本同時に走っていたわけです。約11日間、誰も止めませんでした。

失敗の本質は「エラーが出なかったこと」

この事故で怖かったのは、システムが壊れていなかったことです。

APIは正常にレスポンスを返す。バッチも落ちない。ログ上は処理が進んでいる。こうなると、人間は「ちゃんと動いている」と判断しがちです。

でも、コストの観点では異常でした。

AI自動化では、エラーよりも「正常に動き続ける異常」のほうが危険なことがあります。特に従量課金APIを含む処理では、失敗時だけではなく成功時にもコストが積み上がります。

APIリクエスト、LLMのトークン、画像生成、動画生成、ブラウザ自動化、メール送信、ストレージ転送。どれも、仕組みが大きくなるほど「動けば動くほど課金される」領域です。

「動いているから大丈夫」ではありません。

「どこまで動いたら止まるか」が設計されているかが大事です。

すぐに止めたこと

請求に気づいてから、最初にやったのは新しい改善ではなく停止です。

まず、対象バッチを止めました。次に、二重起動していたプロセスと自動起動設定を確認しました。APIキーの利用状況を見て、どの処理がリクエストを生んでいるのかを切り分けました。

そのうえで、再起動しても同じことが起きないように、運用側の前提を変えました。

  • 自動起動を一度止める
  • APIキーの用途を分ける
  • バッチごとの実行上限を入れる
  • 補充処理の回数上限を入れる
  • コスト異常を人間が見られる状態にする
  • 「残件数ゼロなら補充」だけでなく「補充しても新規が少なければ終了」を入れる

特に重要なのは、AIにコードを書かせる場合でも、予算と終了条件は人間が先に決めることです。AIは「動くコード」を速く作れます。ただし、そのコードが事業上どこまで動いていいかは、AIではなく事業側が決める必要があります。

再発防止チェックリスト

従量課金APIを含むAI自動化を作るなら、最低限これだけは確認したほうがいいです。

1. ループの終了条件があるか

while true を使うなら、抜ける条件を別で持つ必要があります。

  • 最大実行時間
  • 最大処理件数
  • 最大リクエスト数
  • 最大補充回数
  • 連続失敗回数
  • 新規成果が出ない場合の停止条件

「いつか自然に終わるはず」は終了条件ではありません。

2. 1回の実行コストを見積もったか

1リクエストあたりの金額だけを見ると小さく見えます。でも、組み合わせ数、並列数、再試行回数、ループ回数を掛けると一気に膨らみます。

今回で言えば、30業種 × 62エリアという時点で、1回の補充バッチに約1,860回の検索が含まれていました。ここにループと並列起動が乗ると、想定を超える速度でコストが増えます。

3. APIキーの用途を分けているか

検証用、本番用、高コスト処理用を同じキーにすると、どの処理が原因かわかりにくくなります。小規模でも、用途ごとにキーやプロジェクトを分けるだけで、事故時の切り分けが速くなります。

4. 予算アラートを設定しているか

クラウドやAPIの管理画面で、月額予算とアラートを設定しておくべきです。最新の設定方法や名称はサービス側で変わるため、運用前に必ず管理画面で確認します。

大事なのは、「請求が来てから気づく」状態を避けることです。

5. 人間が見るログになっているか

ログは残すだけでは不十分です。

何件処理したか、いくら相当のAPIを使ったか、前回から増えすぎていないか。人間が見て判断できる粒度で出しておく必要があります。

自動化は、人間が見なくていい仕組みではありません。人間が見るべき場所を減らし、見るべき数字を絞る仕組みです。

AI自動化は「止まる設計」まで含めて実装

今回の失敗で学んだのは、AI自動化は速く作れるほど危ないということです。

Claude CodeやCodexのような開発支援AIを使うと、以前なら数日かかっていたバッチが数時間で組めます。エラーが出ても、貼り付ければ修正案が返ってくる。実装スピードは明らかに上がります。

ただ、そのぶん「自分が隅々まで読んでいないコード」が本番で動く可能性も上がります。

だから、AI時代の実装では、機能要件だけでは足りません。

  • 何をするか
  • いつ止まるか
  • いくらまで使っていいか
  • 誰が見るか
  • 異常時にどこを切るか

ここまで決めて、初めて事業で使える自動化になります。

PROST AI実装ログとして公開する理由

この話は、格好いい成功事例ではありません。むしろ、かなり痛い失敗です。

でも、AI活用を事業に入れるなら、こういう実装上の失敗こそ共有したほうがいいと思っています。「AIで自動化できます」「AIエージェントで営業できます」という話は増えました。ただ、その裏側で発生するコスト、暴走、品質、権限管理まで話されることはまだ少ない。

PROSTでは、AIを使ってSNS運用、動画制作、営業、経理、サイト制作の仕組みを作っています。その中でうまくいったことも、今回のように失敗したことも、実装ログとして残していきます。

AI自動化で大事なのは、魔法のツールを探すことではありません。

小さく作る。動かす。止め方を決める。数字を見る。直す。

このループを、事業の中にどう入れるかです。

PROSTでは、AI自動化・AIエージェント・SNS運用・制作パイプラインを、実際の業務フローに合わせて小さく設計します。「自分の事業でもAIを入れたいが、コストや暴走が怖い」という方は、AI活用相談で現在の業務と導入順を一緒に整理できます。