生成AIのランニングコスト管理。予算ガードと使用量台帳の実運用

生成AIのランニングコストとは、導入後に毎月かかり続ける利用料のことで、中心は使った分だけ請求が増える従量課金です。管理の要点は相場を調べることではなく、1日に使ってよい上限を先に置き、使った量を毎日1行記録すること。この2つで、使いすぎと暴走請求は構造的に防げます。

僕はAIVESTという会社を経営しながら、ブログ・X・広告といった複数のAI自動化を毎日走らせています。そして2026年7月、AIの並列実行が初日の朝に外部サービスの利用残高を使い切る事故を実際に踏みました。この記事では、その事故を機に置いた予算ガードの設計と、いま毎日書いている使用量台帳の実物を公開します。

生成AIのランニングコストとは。何にいくらかかるのか

生成AIの費用は、導入時に一度かかる初期費用よりも、回し続けるあいだ発生し続ける利用料、つまりランニングコストが本体です。まず、何にいくらかかるのかを3つに分けて整理します。

費用は3つの形で発生する

• 定額プラン: ChatGPTやClaudeなどの月額課金。人数分で増えますが、金額の上限が読めます

• APIの従量課金: 自動化やシステム連携で使う形。トークン量×単価で、使った分だけ後から請求されます

• 生成物単位の課金: 画像1枚・音声1分など、作った量に比例して増える形

トークンとは、AIが文章を読み書きする量を数える単位です。おおまかには文字数に比例すると考えて差し支えありません。長い文章を読ませて、長い回答を書かせるほど消費が増えます。

注意すべきは2つ目と3つ目です。定額プランは使い込んでも金額が変わりませんが、従量課金は自分で上限を置かない限り青天井です。そして業務の自動化で本当に効くのは、この従量課金の側なんですよね。

なぜ従量課金の請求は見えにくいのか

従量課金の単価は、1回の処理あたり数円から数十円の世界です。単価だけ見れば安い。ところが自動化は回数が桁で増えます。AIは人間と違って疲れないので、間違った処理も全力で繰り返します。

しかも請求は月末にまとまって届くか、チャージした残高が減って初めて気づく形です。単価の安さと総額の安さは、まったくの別物です。仮に1回5円の処理でも、1時間に100回走り続ければ1日で1万円を超えます。

月末の請求書ではもう遅い。従量課金が一晩で暴走した実話

月末の請求書は、管理ではなく結果の通知です。届いた時点で、打てる手はもう残っていません。僕がそれを身銭で学んだのが、2026年7月19日の朝の事故でした。

品質を上げるための改良が、残高を使い切った

当時、リサーチの品質を上げるために「同じ調査を複数のAIに並列で走らせ、一番良い結果だけを採用する」仕組みを導入しました。理屈の上では品質が上がるはずの、前向きな改良です。

初めて本番で走った朝、外部AIサービスの利用残高が枯渇しました。決済エラーが返り続け、処理の成功は20回中3回。幸い、失敗時に予備の経路へ自動で切り替わる設計にしていたため、その朝の業務自体は止まりませんでした。

AIが壊れたわけではないんです。消費量を見積もらず蛇口を全開にした、僕の設計ミスでした。AIは指示どおり全力で走っただけなんですよね。

暴走するのは、張り切って動く仕組み

この事故で理解したのは、コストの暴走は壊れた自動化からではなく、正しく、熱心に動く自動化から生まれるということです。処理が成功しても失敗しても、従量課金のメーターは回り続けます。

事故の顛末と、僕がほかに踏んだ失敗の記録は、別の記事に一次情報のまままとめています。

関連記事AI自動化の失敗例。AIVESTが捨てた自動化と設計原則AI自動化の失敗例を、AIVESTの実運用記録からそのまま公開します。カバー画像の二重表示、設定ずれの2日連続停止、並列実行の残高枯渇、自己採点ゲートの撤廃。共通する3つの原因と、失敗を検査項目に変える設計原則まで解説します。→

事故の前に置く金銭上限。予算ガード設計の3点セット

上限は事故の後ではなく、設計の日に置く。

残高枯渇の事故を機に、僕の運用規約に書き加えた原則です。以来、新しい自動化を動かす前に、3種類の上限を必ず置いています。

3点セットの中身

なぜ月次ではなく日次なのか

多くの会社のコスト管理は月次です。しかし月次の集計では、月の半ばで異常に気づいた時点で、すでに半月分が使われた後です。僕の事故が示すとおり、従量課金の暴走は1朝で完結します。

だから上限の粒度は「1朝の暴走で死なない」日次に置きます。日次で守られていれば月次は自動的に守られますが、逆は成り立ちません。

使用量台帳の付け方。1行で済む記帳の実物

上限とセットで運用しているのが使用量台帳です。大げさなものではなく、1日1行のログです。

実物はこの1行

僕のブログ自動化が毎日記帳している台帳の、実際の1行がこれです。

{"date":"2026-08-12","slug":"ai-adoption-first-2-weeks","images_generated":4}

日付・対象（どの記事の生成か）・画像の生成枚数。項目はこの3つだけです。運用開始からの34行（2026年8月12日時点）が、そのまま消費の全履歴になっています。途中で中断した回も「生成0枚」として1行残します。使わなかった事実も記録のうちだからです。

続けるコツは2つあります。第一に、項目を増やさないこと。感想や理由の長文を求める台帳は続きません。第二に、記帳を人にやらせないこと。僕の台帳は、生成の工程が終わるたびに仕組みが自分で1行追記します。人が手で書く台帳は、必ずどこかで途切れます。

金額ではなく量で記録しているのにも理由があります。単価は改定されますが、使った量は事実として変わりません。量さえ残っていれば、金額はその時々の単価を掛けて、いつでも計算し直せます。

上限と台帳をセットで運用する理由

上限と台帳は、セットで運用して初めて機能します。台帳のない上限は、守られているかを検証できません。上限のない台帳は、読む理由のないただの記録です。

僕は週1回、台帳と上限の距離を確認します。上限に近づいていれば原因を見る。大きく余り続けていれば、上限自体を下げる余地を考える。この往復が、コスト管理を「漠然とした不安」から「数字の運用」に変えます。

なお、この台帳を含む記事生成の自動化の全体像はブログ自動化の仕組みの記事で公開しています。

上限に当たったら止める・切り替える・知らせる

上限は置くだけでは半分です。上限に当たったときに何が起きるかまで決めて、はじめて完成します。僕は3つの動作で設計しています。

止める・切り替える・知らせるの3動作

• 止める: 1日の本数上限に達したら、その日の残りの生成は行いません。実際、この記事を書いた日は当日2本目の上限に達したため、この記事を最後にその日の生成は止まっています

• 切り替える: 有料の経路が失敗したり上限を超えたりしたら、予備の経路へ自動で切り替えます。残高枯渇の朝に業務が止まらなかったのは、この設計のおかげでした。失敗は理由付きで台帳に記帳します

• 知らせる: 処理の失敗率が3割を超えたら、警告が僕に通知されます。上限到達や異常を機械が黙って抱え込む状態が、いちばん危険だからです

止まっても翌日ふつうに再開できる設計にする

日次の上限は、日付が変われば自動でリセットされます。つまり「止まる」は障害ではなく、設計どおりの正常動作です。ここを分けて設計しておくと、止めることを恐れなくなります。

分けるのは2種類の停止です。事故を起こした機能を既定OFFへ落とす恒久の停止と、上限到達による今日だけの停止。前者は人が判断して戻し、後者は明日になれば勝手に再開します。

なお、金銭の上限はAI自動化のリスク設計の一部です。権限の線引きや、人間が確認する関門の置き場所まで含めた全体の設計は、AI業務自動化のリスク対策の記事にまとめています。

経営者が決めるのは3つの数字だけ

ここまでの仕組みの実装は、技術のわかる人やAIに任せられます。ただし数字を決めるのは経営者の仕事です。決めるべき数字は3つしかありません。

3つの数字と僕の現在値

この3つを数字で即答できるなら、生成AIのランニングコストはもう怖くありません。逆に、1つでも「決めていない」があるなら、そこが暴走の入口になります。金額の大小より、決まっているかどうかが分かれ目です。

プロバイダ既製の上限機能も併用する

主要なAIサービスの管理画面には、利用額の上限やアラートを設定する機能が用意されています。これは必ず設定してください。そのうえで、自前の日次ガードと二重にします。

役割分担は明確で、既製の上限機能は「最後の防波堤」、自前の日次ガードは「日々の蛇口」です。既製の設定は月単位が中心のことが多く、1朝の暴走には間に合わない場合があるからです。二重に置いておけば、どちらかの見落としをもう片方が拾います。

よくある質問