常時稼働AIエージェントを24時間回し続けること自体は、成果ではありません。従量課金のモデル呼び出しと、予約したまま休むGPUが同時に膨らみます。
📑目次
1件のタスクと予約GPUでは、以下の2つのコストが同時に発生します。
- 検証とやり直しで、コパイロット1回分ではなく50〜100回のモデル呼び出しになりえる
- 常時予約したGPUは、duty cycleが低ければ大半がアイドル課金
この記事では常時稼働、イベント駆動、モデル振り分けを数字で比べ、起動条件・停止条件・上限・観測を先に決める手順を整理します。対象は、エージェントを overnight や本番キューに載せようとしている開発者、SRE、FinOpsです。起動条件、停止条件、上限、観測を1枚に書き、イベント駆動と振り分けの案を見積もってから常時稼働のGPUを予約してください。技術を選ぶより先に、いつ起動し、いつ止めるかを書いてください。
常時稼働は従量課金とどこで食い違うのか
呼び出し回数が増える理由
シート課金の延長で「常時オン」を選ぶと、エージェント型のコストモデルと噛み合いません。コパイロットは1プロンプト1応答で終わりやすい一方、エージェントは分岐、ツール呼び出し、リトライで呼び出し回数が増えます。呼び出し回数が増える前提なら、技術を増やす前に、起動条件、停止条件、上限、観測を1枚に書いてください。次に、イベント駆動と振り分けの案を同じ上限で見積もってから、常時稼働のGPUを予約するか判断します。
常時稼働のGPUを予約する前に、開発者・SRE・FinOpsで次の5項目を同じ1枚に書いてください。書けない項目があるなら、その時点では予約しない判断です。
- 起動条件: キュー、タイマー、Webhookなど、何が来たらエージェントを起こすか
- 停止条件: 失敗した tool call、滞留、人間介入など、何が起きたらループを止めるか
- 上限: 1タスクの呼び出し回数、トークン、最大実行時間、支出の上限
- 観測: 時間あたりトークン、失敗 tool call、滞留キュー、GPU duty cycle
- 予約GPU: 誰が何枚を常時確保するか。duty cycle が見えないなら予約しない
CIO Japanが示す非線形コスト
CIO Japan（2026年8月18日）は、エージェント型AIのコストが利用量ベースで非線形に増加すると指摘しています。
- 出典: CIO Japan
- 見積もり: リトライと再計画で、1タスクが50〜100回のモデル呼び出しになりうる
同じ記事でGraingerのPavan Madduri氏は、コストの大部分はオーケストレーションとランタイムループで決まると述べています。アーキテクチャに組み込むべき制御は次の通りです。
- トークン上限
- リトライ上限
- 最大実行時間
- 暴走消費の制御
失敗経路を先に決める
パイロット時のハッピーパス見積もりは、本番環境の失敗経路を含んでいません。失敗を前提にリトライ回数と人間介入点を先に決めてください。常時稼働AIエージェントを「席を確保したチャット」と同じ感覚で運用すると、ループが請求を支配します。技術を選ぶ前に、1タスクあたりの呼び出し上限を具体的な数字で決めてください。
トークン量は成果ではない
週次トークンとキャッシュ再実行
トークン量が増えたことと、実際に得られる成果が増えたことは、別の指標です。
Memeburn（2026年8月25日、a16z / OpenRouter の図表を引用）によると、数字は次のとおりです。
- エージェントの週次トークンは約7.3T
- 人間は約1.5T
- 2026年2月以降、エージェント側は約14倍
- 85%超がキャッシュ済みプロンプトの再実行
生トークン数は生産性というより、「同じ文脈を何度も繰り返した量」に近い指標と読むことができます。
常時稼働と4時間スプリント
同じ記事は、24時間クラウド常時稼働はトークンを出し続け、4時間のコーディングスプリントは稼働時間だけを消費すると対比しています。この5倍差の一部は仕事量ではなくアーキテクチャに起因します。チャット中心で再帰が多く、常時オンである設計がトークン量を押し上げています。
無人リトライと停止条件
HackerNoon（2026年8月21日）は、10分の監視デモと無人24/7運用を全く別のシステムとして扱うべきだと指摘しています。
- 出典: HackerNoon
- 失敗した tool call を黙ってリトライすると、観測層が気づくまでトークンが燃える
- 一晩放置したループは、翌朝までに API 予算を静かに消費しえる
- 足りないのは稼働時間ではなく、観測と停止条件
- ループの止め方は、エージェントLoopを安全に回すハーネス設計で扱った指示・ガード・検証の分離と同じ層
制限もあります。OpenRouter の分類はツール、多ターン、自動間隔などの行動マーカーであり、全プロバイダの実コストではありません。自社の請求書にそのまま当てはめないでください。
アイドルGPUとCPUベースHPAの盲点
ScaleOpsのGKE実測
エージェント本体のトークンより、常時予約した推論GPUのアイドルが請求を支配しやすいです。ScaleOps（2026年8月21日）は、GKE で T4 を3枚、24時間予約した計測を公開しています。公開値は次です。
- 月額は約1,576ドル
- GPU duty cycle は 23.5%
- 約1,200ドルがアイドル
CPU目標のHPAが落とすレプリカ
バースト時に GPU が 100% でも、CPU は 25% に止まることがあります。CPU 目標 50% の HPA はアイドルと誤認し、レプリカを落とします。推論が忙しいのに replica が減る、という逆向きの動きです。
scale-to-zeroとKEDA
scale-to-zeroは可能ですが、同計測ではコールドスタートが約3.2分かかります。次の分割が必要です。
- スケール信号を出すエージェント層は残す
- 推論層だけゼロにする
- ゼロにした層が信号まで消すと、戻って来られない
CIO記事のMadduri氏は、KEDAを使って需要低下時にGPUノードをゼロまでスケールダウンし、実際にトークンを処理している時間だけを支払うことを勧めています。
23.5% は単一テナントの実測です。共有推論層では duty cycle が上がります。ベンダー計測なので、自クラスタでは再計測が必要です。常時3GPUを予約する案は、このアイドル税を先に見積もってからにしてください。
イベント駆動とモデル振り分けで回さない
既存ワークフローへ1ステップ足す
タスク到着時だけ起動し、必要なときだけ高いモデルを使うのが、常時オンの対案です。Microsoft Azure FunctionsのServerless Agents（2026年8月12日）は、成功しやすい形を全面書き換えではなく、既存の決定的ワークフローに非決定的な1ステップだけAIを加えることだと書いています。
Flex Consumptionの課金体系は次の通りです。
- メッセージ間で scale to zero する
- 実行に対して課金し、アイドルには課金しない
- キュー到着ごとにエージェントを1回起動する
実行時ルーターでモデルを分ける
NVIDIA NeMo Switchyard（2026年8月11日）は、全リクエストを最大性能のモデルに送るとコストと遅延がともに増大すると明記しています。
- 出典: NVIDIA NeMo Switchyard
- 実行時ルーターが要件、制約、ポリシーで振り分ける
- CIO 記事の表現では、「あらゆる処理を毎回フロンティアモデルに任せるのはアーキテクチャ設計上の怠慢」
合格基準がないまま回すと、振り分けもリトライも止まりません。評価の置き方は MLOpsの継続的学習とエージェント評価、社内手順の切り出しは 社内AIエージェントのSkillsとEval設計 が隣接します。
プレビュー範囲と誤振り分け
制限もあります。
- Serverless Agents の runtime はプレビューです
- コネクタ名や対応範囲は GA 前に変わりえます
- ルーティングは誤振り分けで品質が落ちます
- 安いモデルで常時回す案も、呼び出し回数と失敗リトライが残れば従量課金は膨らみます
導入前に確認する起動・停止チェックリスト
常時稼働を選ぶ前に、起動条件・停止条件・上限・観測を先に明確にしてください。比較は次の3列でまとめています。
3列で見る課金とリスク
| 観点 | 常時稼働 | イベント駆動 | モデル振り分け |
|---|---|---|---|
| 課金の主因 | 予約GPU＋連続トークン | 到着した仕事の実行時間 | 高いモデルを使う割合 |
| 典型リスク | アイドルGPU、無人リトライ | コールドスタート | 誤ルーティング |
| 向く仕事 | 低遅延必須の常駐推論 | キュー・タイマー・Webhook | 難易度が混在するエージェント |
| 先に決める上限 | 最大実行時間、GPU予約数 | 同時実行数、poison queue | フロンティアへ送る条件 |
比較表の出典
表の数字と区分は次の出典に基づきます（2026年8月時点）。
比較表のプラットフォーム文書
起動・停止の5項目
チェックリスト:
- 1タスクあたりの想定モデル呼び出し数（成功経路と失敗経路）
- リトライ上限、最大実行時間、トークン／支出上限、人間介入点
- GPUを誰が予約するか（エージェント本体か推論層か）
- スケール信号の出所（ゼロにした層が信号を消さないか）
- 観測: 時間あたりトークン、失敗 tool call、滞留キュー、duty cycle
次にやるべきことは、起動条件・停止条件・上限・観測を1枚に書き、イベント駆動と振り分けの案を見積もってから常時稼働のGPUを予約することです。数字が揃わないなら常時予約は保留してください。テクノロジーの比較表を増やすより、この5項目を1枚に落とすことを優先してください。
よくある質問（FAQ）
Q1. 常時稼働はいつ残してよいか
コールドスタート約3.2分がSLOを割る推論層や、低遅延必須の共有エンドポイントです。エージェントの思考ループ自体を常時回す理由にはなりません。
Q2. 安いモデルで常時回せばよいか
呼び出し回数が増えると同じく従量課金が膨らみます。失敗前提のリトライ上限がないと、安価モデルでも一晩で予算を消費しえます。
Q3. トークンが増えたら成果も増えたと考えてよいか
いいえ。OpenRouter上のエージェントトークンの85%超はキャッシュ再実行です。常時稼働はスプリントよりトークンが出やすい設計です。
Q4. CPUのHPAだけでエージェント推論を守れるか
守れないことが多いです。GPU 100%でもCPU 25%になり、HPAがレプリカを落とす実測があります。
Q5. 全部を最強モデルに任せれば設計は簡単か
運用の判断は減りますが、コストは上がります。公式のモデルルーティング文書は、全リクエストを最大モデルへ送るとコストと遅延が増えると明記しています。
関連記事:
まとめ
常時稼働は「回した量」を成果に見せやすい一方、従量課金とアイドルGPUの両方で高くつきやすいです。判断材料は次です。
- 1タスク50〜100回の呼び出し
- 週次7.3T対1.5T
- duty cycle 23.5%／約1,200ドルのアイドル
- scale-to-zero
- 既存ワークフローへ1ステップだけAIを足す
次にやることは、起動条件、停止条件、上限、観測を1枚に書き、イベント駆動と振り分けの案を見積もってから常時稼働のGPUを予約することです。未確定なのは次です。
- 自環境の duty cycle
- プレビューランタイムのGA範囲
- OpenRouter数字の自社適用
数字は出典時点の報告なので、自クラスタで測り直してください。
著者
krona23
IT業界20年以上の実務経験を持ち、日本国内有数のPVを誇る大規模Webサービスで事業部長・CTOを複数社で歴任。Windows/iOS/Android/Webと技術の変遷を経験し、現在はAIネイティブへの変革に注力。DevGENTでは、AIコードエディタ・自動化ツール・LLMの実践的な使い方を日英西3言語で発信中。
コメントを残す