要約

  • CoWorkからCortex Agentを呼び出した場合、その利用はCoWorkに帰属する。Agentだけを対象にした資源別予算では、この経路のクレジットを計上しない。
  • CoWorkを予算に含めれば対象経路は広がるが、元のAgentだけでなく、対象のCoWorkオブジェクトに帰属する利用を扱うことになる。
  • 資源別予算の定期処理とユーザー別配額の組み込み制限は、対象も時間軸も異なる。個人ごとの上限は、部門全体の共同予算ではない。
  • Snowflakeは代替手段と制約を公開している。問題は制御の有無よりも、帰属、停止権限、復旧条件が実際の予算責任と一致しているかにある。

AIの利用額が上限を超えた。その瞬間に、次の処理も止まるのか。

Snowflakeの公開資料を読むと、答えはどの制御を設定したかによって変わる。資源別予算には定期評価と設定済みのアクションがあり、ユーザー別の配額には、支出イベントから数分以内に評価する組み込みの利用制限がある。「予算を設定した」という一文だけでは、どちらを指すのかも、何が止まるのかも分からない。

ただし、時間差を調べる前に確認すべきことがある。その費用は、そもそも監視している予算に入っているのか。

SnowflakeのCortex Agent向け資源別予算ガイドには、CoWorkから開始してAgentを呼び出すリクエストの利用はCoWorkに帰属すると明記されている。Cortex Agentsとしてタグ付けした資源だけを対象にする予算では、その経路で消費したクレジットを捉えない。対応策はCoWorkの資源を対象に加えるか、CoWork向けの予算を別に設けることだ。

同じAgentが処理していても、入口が変われば予算上の帰属先が変わる。これは請求ミスや権限回避を示す話ではない。公開された集計範囲の違いである。しかし、利用部門が「このAgentには予算が付いている」と考えるだけでは、費用管理の前提を満たせないことを意味する。

入口を広げると、止める範囲も問い直される

Agentの資源別予算は、オブジェクトへのタグ、月間クレジット上限、しきい値に応じた処理を組み合わせる。特定の資源を軸に利用をまとめる仕組みであり、その資源に到達するすべての経路を自動的に同じ枠へ取り込むという約束ではない。

CoWork向けのガイドは、アカウント内のCoWork利用をサービスのオブジェクト単位でまとめる。Agentの予算にCoWorkを加えると、問題の経路を含められる一方、対象は当初のAgentへの呼び出しだけではなくなる。対象のCoWorkオブジェクトに帰属する利用全体が関係する。

そこで問われるのは、単に上限をいくらにするかではない。警告を送るなら誰が受け取り、何を判断するのか。アクセスを取り消すなら、どの役割を通じた利用が失われるのか。広く使われる入口に対する処置は、当初の予算を設けた業務以外にも影響しうる。ただし、その影響は設定したアクションと権限設計による。しきい値を超えれば必ずサービス全体が自動停止する、という説明は正確ではない。

画面を共通化すると、利用者は一つの場所から多くの機能に触れられる。財務上は、別々の部門が持つ予算責任まで一つになったわけではない。技術的な入口の統合と、支出の承認単位の統合を同一視すると、設定は存在していても責任の境界が曖昧になる。

Snowflakeには、その境界を細かく分ける共有資源向け予算もある。選択したAI資源とユーザーに付けたタグを組み合わせ、共通サービスの利用を部門などの集団ごとに追える。資源だけでなく、誰の利用を含めるかが対象範囲になる。

タグ条件のいずれかを満たす人を含めるのか、すべてを満たす人に限るのかでも集団は変わる。部門名のラベルを付けたことと、その部門の利用が正しく集計されることは別である。必要なのは名称の確認ではなく、選択した資源とユーザー集合の照合だ。

「数時間」と「数分」を混ぜてはいけない

資源別予算では、利用が上限を超えてからアクションまで、通常の方式で最大8時間、低遅延のオプションで最大2時間かかりうると説明されている。これは資料上の動作条件であって、本稿が本番環境で測定した値ではない。毎回必ず8時間待つという意味でもない。

アクションは顧客側が設定する。通知だけなら、その後に判断と操作が残る。アクセスを取り消す処理なら、別の役割でアクセスできる状態が残っていないかを確認する必要がある。カスタム処理による取り消しでは、次の予算期間に適切な開始時アクションで利用を戻す設計も欠かせない。

これに対し、ユーザー別配額の組み込み制限は、支出イベントから数分以内に評価する。こちらを8時間の仕組みと扱ってはいけない。ただし、リクエストを受け付ける瞬間に、その処理の全費用を予約する方式でもない。資料は、制限が効く前に上限を超過しうること、とりわけ大きな一件のリクエストが影響しうることを説明している。

上限から実際の停止までにどれだけ費用が積み上がるかは、処理の大きさ、同時実行、計測、設定した対応に左右される。公開資料から一定の超過額を算出することはできない。クレジット数をそのままドルに置き換えることも、契約や価格条件なしにはできない。

制限の対象にも境界がある。組み込みのAI制限はAI Functions、Cortex Agents、CoWork、CoCoに適用されるが、ウェアハウスの支出を停止するものではない。AI用とウェアハウス用のクレジット単位は一つの配額に混在させられず、後者には別の配額が必要になる。AIの一部を止めたことを、請求全体に上限を付けたことと読み替えてはならない。

停止後の業務継続も別の問題だ。資料によれば、新たな要求には配額に関するエラーが返り、制限が有効になると実行中のAI Functionsは終了する。すべてのツール動作が取り消される、完了済みの仕事まで巻き戻される、とまでは確認できない。追加の消費を止めることと、業務を整合した状態へ戻すことは同じではない。

日付が変われば、別の枠になる

ユーザー別配額の日次・月次上限は、対象ユーザーごとに独立して評価される。部門全員で分け合う一つの財布ではない。全員が個人上限を守っていても、利用者が増えれば合計消費は増えうる。

これは個人制限が無意味だという話ではない。一部の大口利用者だけを止め、他の人の利用を続けられるという利点がある。共同予算が答える「この部門全体にいくら割り当てるか」と、個人配額が答える「この人にどれだけ使わせるか」が違うのである。一つの配額では対象者に同じ個人上限を適用するため、異なる配分が必要ならユーザー群を区別する設定が要る。

時刻の基準も社内の直感と一致するとは限らない。日次の枠はUTCの午前0時、月次はUTCで毎月1日にリセットされる。各拠点の営業日でも、直近24時間の移動窓でもない。境界の前後で連続して使えば、二つの期間の割り当てを順番に使うことがありうる。それは規則に沿った動作であり、ただちに抜け道と呼ぶべきではない。

上限や対象の変更にも約5〜10分の反映時間がある。複数の配額から制限を受けている人は、一つを解除しても残りの制限が消えるわけではない。組み込み制限の期間リセットと、独自の権限取り消し処理の復旧も区別する必要がある。予算表が新しい数字になった時刻と、現場が再び使える時刻は、必ずしも一致しない。

モデルの効率は、予算責任を決めない

こうした管理の境界は、共有AI機能が広がるほど重要になる。Snowflakeの9月2日発表の決算資料では、7月31日終了四半期の製品売上高は丸めた数字で14億9,000万ドル、前年同期比37%増だった。CoCoは9,100超、CoWorkは5,800のアカウントで利用されたとする。

ただし、これは四半期の最後の4週間における週平均利用を、同社の内部区分に基づくキャパシティ契約と従量利用のアカウントで測ったものだ。固有の有料利用者数ではなく、二つの集団が重ならないともいえない。予算機能の利用数や、モデルルーターの導入数にも置き換えられない。

その後の8月18日の動的ルーティング発表は、能力と費用の均衡を意識したモデル選択を説明している。注記ではプライベートプレビューを近く開始する予定とされていた。社内試験の効率向上は、顧客の請求削減を独立に検証した結果ではない。7月に終わった四半期の成長を、8月発表の機能の効果とすることもできない。

一件あたりの処理に必要な資源が減っても、その仕事をどの部門の予算に入れるかは決まらない。使いやすく安くなれば、利用回数が増える可能性もある。単位効率の改善と支出総額の増加は両立する。それは成長予測ではなく、二つの指標が異なるということだ。

AI費用管理のガイドは、AI利用にクエリ費用、ウェアハウス稼働、その他の料金が伴いうる点も示す。集計ビューには補足的なものや重複するものがあり、見える数字をすべて足せばよいわけではない。

Snowflakeは、これらの制約と代替手段を公開している。監視、ユーザー選択、制限履歴、低遅延の評価などを使える以上、「止める手段がない」と結論づけるのは不公平だ。また、Cortex Agentの資源別予算ガイドは、この機能が中華人民共和国では利用できないと明記する。世界市場の議論だからといって、個別機能の提供地域まで一律にはならない。

本稿は公開資料に基づく分析であり、顧客アカウントでの制御試験、実請求の検証、特定企業の損失の報告ではない。確認できるのは、入口、対象、時間という三つの設定が別々に存在することだ。信頼できる予算管理には、その三つを一つの数字で済ませない姿勢が必要になる。