要約

  • Vercelは10月23日、既存のチーム予算をCLIで確認・設定・削除できる機能を発表した。停止を選べば、予算到達時にチーム内の全プロジェクトの本番デプロイが止まる。
  • 予算を増やしても自動では再開しない。個別の復帰作業に加え、保存資源の料金や続けて使う一部サービスの費用が残る。

予算を増やした。これで営業再開、とはいかない。Vercelの支出管理は、チームに属するすべてのプロジェクトの本番デプロイをまとめて停止できる。ところが再開はプロジェクトごとだ。止める権限は束になり、戻す仕事はばらばらに残る。

10月23日の発表で、この予算がCLIから扱えるようになった。vercel budgetsで当期の支出と設定額を調べ、予算を変更したり削除したりできる。ダッシュボードのOn-Demand Budgetと同じものを操作するため、ターミナルだけの練習用の数字ではない。必要な権限を持つ人やスクリプト、エージェントが本番運用に影響する設定に触れられる。

停止機能そのものは以前からある。2024年3月の公式告知にも登場している。今回の新しさは、その既存の判断をコマンドラインの作業に組み込みやすくした点だ。画面を開く手間が減る一方で、何を誰のために止めるのかという判断まで短くなるわけではない。

合算請求の向こうに合算停止がある

設定額だけでは利用は止まらない。本番デプロイの停止オプション、CLIなら--pauseを選ぶことで、予算到達と停止が結びつく。その対象は選択したチーム内の全プロジェクトだ。CLIの仕様は予算の適用単位であるチームと、操作先チームを選ぶ--scopeを区別している。チームを選ぶ指定は、個別プロジェクトの予算指定ではない。

複数顧客のサイトを同じチームで運用する事業者にとって、これは売上の問題になる。あるサイトの利用が増えてチーム予算を使い切れば、一斉停止を有効にしたチームでは別の顧客のサイトも止まる。多く使った顧客と、停止の影響を受ける顧客の範囲は一致しなくてよい。請求をまとめる単位が、同時に休業する単位にもなる。

管理をまとめる利点はある。だが顧客が買っているのは請求処理の簡単さではなく、自分のサービスの提供だ。共有予算が持つこの範囲は、営業が引き受ける約束と照らして選ぶ必要がある。会計上の整理を、そのままサービスの運命共同体にしてよいか。チーム設計はその問いへの答えになる。

上限には時計も口径も付いている

現在の支出管理文書によれば、Vercelは数分ごとに使用量を確認する。予算を超えた後、通知、ウェブフック、停止処理の発動まで数分かかることがある。その間もリクエストは処理され、利用料が増え得る。100%という表示を、超過を一切許さない瞬間遮断と読むと計算が狂う。

期中に設定額を下げる時も、すでに発生した支出は引き継がれる。現在額より低い予算に変えれば、設定済みの動作は次の確認で発動する。将来の節約を書き込むつもりの変更が、次の確認で本番を止める変更になることがある。予算を上書きしても、過去の利用までは書き換わらない。

何が予算に算入されるかもプランで異なる。Proでは月額クレジットを超える従量利用、Enterprise Flexible Commitmentでは前払い残高を消費する従量利用が対象だ。座席、Marketplaceなどの連携、別料金の追加商品は含まれない。両プラン向けの支出管理機能自体は追加料金なしで提供されるが、設定額が請求全体を支配するわけではない。

金額、対象、作動までの時間。この三つをそろえて初めて、予算は事業上の制御になる。数字だけを自動化すれば、単に安心する速度が上がる。

閉店しても倉庫代は来る

本番停止中の訪問者には503 DEPLOYMENT_PAUSEDが返る。サイト、API、関数は利用できなくなる。一方、保存済みの資源は消えない。デプロイの出力や関数のパッケージ、Vercel Blob、コンテナレジストリのイメージには、それぞれ保存の料金が続く。

AI GatewayのAPIキーによる利用やチームに請求されるv0の利用も、本番デプロイの停止では止まらない。それらが使われ続ければ支出に加算される。表の店が閉まったからといって、裏のすべてのメーターまで止まる仕組みではない。保存と別経路の利用を残すことには用途があり、費用もある。

節約を測るなら、止めて避けた利用料、残った費用、顧客に提供できなかったサービスを一緒に見るべきだ。実際の損益を出すには、各サービスの通信量、契約上の約束、当時の設定と停止・復帰時刻が必要になる。予算の額だけではサービス事業の損失限度額は決まらない。

再開ボタンの先までが商売

プロジェクトはダッシュボードかREST APIから一つずつ再開する。プロジェクト管理文書では、再デプロイは不要で、本番サービスは数分で戻るとされる。設定を上げる、再開を指示する、顧客のリクエストが成功する。この三段階を一枚の「対応済み」で閉じてしまうと、誰かの仕事がまだ残る。

権限も同じ表には載っていない。予算を扱うのはOwnerかBilling。プロジェクトのダッシュボードで手動再開できるのはOwner、Member、そのプロジェクトのProject Administratorだ。実際の担当者と付与権限を確認しておく必要がある。請求責任者に電話がつながることと、各プロジェクトを戻せることは別の能力である。

CLIで見られる予算アラート履歴にも読み方がある。actions configuredは、その時点で閾値に設定されていた動作を示す。各動作が実行された証明ではない。設定の履歴は説明に役立つが、動作の確認とサービスの復帰確認までは肩代わりしない。

一緒に止まってよいサービスをまとめるなら、この予算は理解しやすい。一緒に止められない約束を束ねるなら、通知中心の運用やチームの分け方、再開体制を選び直す余地がある。分ければ権限や請求、チーム管理の手間は増える。その取引条件を引き受けるのが経営だ。

CLIは予算変更の作業を短くした。売っているサービスの責任まで圧縮してはくれない。全体を止める一つの判断に、個別に戻す人と時間を付けておく。その費用を含めたものが、顧客に売れる節約である。