あなたのCloudAMQPプランは月額$99と書いてあるのに、請求書には$82.33と記載され、翌月には$114.07になっている。しかも火曜日にインスタンスのサイズを変更した以外、何も変えていない。何もおかしくはない。CloudAMQPはメッセージを売っているのではない。インスタンス時間を秒単位で販売し、1か月後払いで請求し、あらゆるプラン変更をそれが発生した正確な秒まで日割り計算する。表示価格は制限速度であって、約束ではない。あなたの帳簿が請求書をサブスクリプションではなくメーターの読み取り値として扱うまで、インフラコストはぶれ続け、見越計上は外れ、粗利益率はその差を静かに吸収してしまう。
この記事では、CloudAMQPが実際にどのように計量・請求するのか、現実的な請求額はどのようなものか、なぜ本番ブローカーが売上原価に属するのか、そしてインスタンス時間の請求書を照合してすべてのドルを正しい勘定科目に着地させる方法を説明する。
CloudAMQPの計量方法：メッセージではなく時間
CloudAMQPは84codesが運営するマネージドRabbitMQおよびLavinMQホスティングだ。ブローカー、プラン、リージョンを選ぶと、インスタンスまたはクラスターが手に入る。課金モデルはインスタンスに従い、そこを流れるトラフィックには従わない。これはペイロードサイズが請求額を左右するリクエスト単位のメッセージングサービスとは正反対だ。ここで請求額を決める2つの問いは、どれだけ大きなインスタンスを、何秒間動かしたかである。
共有プランにはクォータがあり、専用プランにはキャパシティがある
メッセージ数が一切登場するのは、共有マルチテナントプランだけだ。Loyal Lemmingは無料で月間200万メッセージのクォータと40接続、Elegant Ermineは月額$19で2000万メッセージのクォータと200接続となる。これらは開発、プロトタイプ、ホビープロジェクトに適している。クォータは上限であってメーターではない。その範囲内ではメッセージごとの料金は発生しない。
専用プランではメッセージ数のカウントは完全に消える。独自のブローカー、またはそれらのマルチAZクラスターが手に入り、すべての専用プランは同じエンジンを同じ速度で動かす。どの層を選ぶかは、あなたのシステムがどれだけ保持するかで決まる。接続、キュー、保存メッセージだ。シングルノードのLavinMQの階層は、月額$49のPassionate Puffinから、$99のPlayful Penguin、$199のLively Lynx、$499のWild Wolverineへと続き、その上にはさらに大きな層がある。1、3、5ノードのクラスター構成は、可用性と引き換えに価格を変える。データ転送はフェアユースの許容範囲内で含まれており、料金ページでは、チームの月間支出の30パーセントに相当する転送が無料と定義されている。超過した場合は、後の請求書にトラフィック料金が現れ始める前に、30日間の解決期間が与えられる。
実務上の帰結として、インスタンスが接続、キュー、バックログを保持できる限り、メッセージ量が2倍になっても請求額は1セントも動かない。逆に、ある上限に引っかかったからと大きな層にアップグレードすると、その瞬間から毎秒が再価格設定される。トラフィックが横ばいであってもだ。この請求額を制御するスキルは、トラフィック予測ではなくキャパシティプランニングである。
すべての秒が数えられ、請求書は1か月遅れて届く
すべてのプランは秒単位で課金される。毎月末に、あなたの請求額は各インスタンスが利用可能だった正確な時間を反映する。したがって、月の途中で作成、削除、またはサイズ変更されたインスタンスは、満月分でもゼロでもなく、日割り計算された料金を生む。ダウンタイムなしでいつでもプランを切り替えられ、層間のオートスケーリングも同じ効果を持つ。月の各区間は、その秒の間に稼働していた層の価格で計算される。
支払いは提供の翌月に行われる。CloudAMQP自身のFAQはそれを明快に述べている。請求は日割り計算され、顧客はサービスが利用可能だった時間に対してのみ支払い、最初の請求書はサインアップ時ではなく翌月の初めに受け取る。この後払いのリズムが、あなたの帳簿にとって最も重要な事実だ。決算時に計上すべき料金は存在しない。つまり、毎月の締めには未請求のブローカー時間に対する見越計上が必要であり、すべての請求書には前月の見積もりに対する修正計上が必要だ。
さらに2つの課金の仕組みが重要だ。第一に、前払い。1か月から数か月分を前払いでき、前払いは有効期限が切れるまで1年間有効だ。月額$99のプランの顧客は12か月分を前払いして1年間の月次料金をスキップでき、クレジットはアカウントのすべてのプランをカバーするため、2つ目のインスタンスを追加するとより早く消費される。これは支払時点の費用ではなく、1年の導火線が付いた前払資産だ。第二に、年次請求は存在しない。顧客が頻繁にプランを変更するため、CloudAMQPは年間請求を提供していない。前払いクレジットがその代替だ。調達プロセスが年次請求書やサブスクリプションごとの個別発注書を要求する場合は、早めに計画を立てよう。個別のPOには個別のアカウントが必要でサブスクリプションが別々に請求され、請求条件はセルフサービスのカードフローではなく請求チームを通すことになる。
マーケットプレイスのインスタンスはCloudAMQPではなくプラットフォーム経由で請求される
HerokuアドオンやAWS、Azure、GCPのマーケットプレイス経由でプロビジョニングした場合、その支出はCloudAMQPの請求書には一切現れない。それはプラットフォームの請求書、Herokuの月次請求書やクラウドプロバイダーのコスト内訳に、そのプラットフォームの命名で載る。これはブローカーを2か所で運営するチームにとって最もよくある照合のギャップだ。直接請求書はきれいに照合できる一方、マーケットプレイスの双子はより大きなクラウド請求書の中に、しばしば汎用的なホスティングとして分類されて隠れる。各インスタンスがどこから請求されるかを一度決め、月末の取得がCloudAMQPコントロールパネルと、隠れうるすべてのマーケットプレイスの両方をカバーするようにしよう。
現実的な構成でのコスト
表示価格は秒を掛けて初めて意味を持つので、公開されているシングルノード価格から構築した3つの構成を示そう。
サイドプロジェクトでは、ステージングを無料のLemming層で、小さな本番サービスを$49のPuffinで動かす。ブローカーの行は月額$49で一定であり、唯一の照合タスクはインスタンスが月全体を稼働したことを確認することだ。
成長中のSaaSチームは、本番を$99のPenguinで、ステージングを$19のErmineで動かす。月の途中でキューの深さがアップグレードを強いる。Puffinレベルのステージングはそのままだが、本番は30日の月の10日目に$49のPuffinから$99のPenguinへ移る。本番の区間は、下位層で10日分、上位層で20日分として価格計算され、おおよそ$16.33と$66.00、つまり約$82.33となり、ステージングが$19を加える。請求書の合計は約$101.33となり、表示価格の合計が$118になる構成だ。翌月、Penguinが全期間稼働すれば、同じ構成は満額の$118で請求される。両月とも表示価格で計上する人は、最初の月を過大計上し、2か月目は何も過小計上しない。これこそが秒単位の課金が罰するぶれなのだ。
より大きなショップは、3ノードの本番クラスターにステージング、そして前払いクレジット残高を運営する。クラスターはシングルノード料率を掛け合わせ、インシデント対応中のプラン変更が日割り区間を追加し、前払いがカード請求なしに合計を吸収する。請求書は依然としてすべてのインスタンスとすべての区間を明細化し、計上すべき数字はクレジットの減少分であり、カード明細のゼロではない。
これらの構成はいずれもメッセージ数を伴わない。もしあなたの財務モデルが予想メッセージ数にメッセージ単価を掛けているなら、それは別のベンダーをモデル化している。インスタンス層に予想秒数を掛けてモデル化し、接続やキューの増加がサイズ変更を強いるたびに層の仮定を見直そう。
なぜ本番ブローカーは間接費ではなくCOGSなのか
本番で注文イベント、ジョブディスパッチ、顧客通知を運ぶメッセージブローカーは、製品提供の直接費だ。ビジネスとともに拡大し、何も売れなくなった瞬間に意味を失い、本番向けのコンピュート、データベース、ストレージ、帯域と並んで粗利益線の自然な上方に位置する。SaaSの粗利益率の実務では直接費テストを適用する。本番で顧客にサービスを提供するために存在する支出は売上原価であり、会社を構築、販売、管理する支出は営業費用だ。典型的なSaaSはこの基準で75〜85パーセントの粗利益率で運営され、インフラ集約型のビジネスはより低く、投資家はその帯域に対してあなたをベンチマークする。
テストはインスタンスごとに適用しよう。1つのCloudAMQPアカウントには通常複数が入るからだ。顧客ワークロードを運ぶ本番ブローカーは売上原価に入る。ステージング、負荷テスト、開発者サンドボックスのインスタンスは研究開発または一般間接費に落ちる。ステージング環境を動かす共有のErmineは、本番のPenguinと同じ請求書を共有しているというだけではCOGSではない。請求書はそれらを一つにまとめるので、コントロールパネルのインスタンス別内訳を使って毎月インスタンスごとに分割しよう。分割を省くチームは通常、都合の良い方向に誤り、インフラを間接費に埋めて、ユニットエコノミクスが擁護できない利益率を報告する。デューデリジェンスのレビューはそれを午後1回で再分類し、修正後の利益率がより高いものになることは決してない。
会計基準もこれを裏付ける。ASC 350-40の下では、ベンダーがソフトウェアを運用するマネージドホスティング契約はサービス契約であり、料金は使用期間にわたって発生時に費用化される。実装作業には独自の処理があり得るが、月次のインスタンス時間料金は期間費用であり、決して資本化される資産ではない。前払いはその鏡像だ。今日現金が出て、後で費用化されるため、前払いは前払資産として位置し、クレジットが消費されるにつれて費用に解放される。支払日に前払いを費用として計上すると、支払月を過大計上し、クレジットがカバーするすべての月を過小計上する。
実際に支払う純額を計上しよう。無料のLemming層は無料のキャパシティであり収益ではないので、総額計上するものはない。そのワークロードがそれなしでいくらかかるかを可視化したいなら、それを指標で追跡し、元帳は現金コストのままにしておこう。
請求書が照合できるように計上する方法
ブローカーに汎用的なクラウドやソフトウェア支出に混ぜるのではなく、独自の売上原価勘定を与えよう。メッセージブローカーのような専用勘定があれば、月の本番支出を月のインスタンス秒数で割り、キャパシティ単位あたりの真のコストを見ることができる。これは、サイズ変更が余裕を買ったのか、単に大きな請求書を買ったのかを教えてくれる数字だ。
請求が1か月後払いで行われるため、リズムは見越計上、そして決済、そして修正計上だ。締め時にインスタンス層と秒数からブローカー部分を見積もり、本番とステージングを分け、請求書が届いたらそれに合わせて修正する。月の途中のサイズ変更後に本番が$82.33、ステージングが$19.00を加えた月の完全なサイクルは次のとおりだ。
2026-01-01 open Assets:Cash:Operating USD
2026-01-01 open Assets:Prepaid:CloudAMQP USD
2026-01-01 open Expenses:CostOfSales:Message-Broker USD
2026-01-01 open Expenses:Research:Staging-Infra USD
2026-01-01 open Liabilities:Accrued:CloudAMQP USD
2026-01-31 * "CloudAMQP" "January estimate, prod Puffin-to-Penguin resize plus Ermine staging"
Expenses:CostOfSales:Message-Broker 82.33 USD
Expenses:Research:Staging-Infra 19.00 USD
Liabilities:Accrued:CloudAMQP -101.33 USD
2026-02-04 * "CloudAMQP" "January invoice settles, estimate was exact"
Liabilities:Accrued:CloudAMQP 101.33 USD
Assets:Cash:Operating -101.33 USD前払いがその月をカバーする場合、決済の仕訳は現金ではなく前払資産を取り崩す。前払いを支払ったときに資産として記録し、毎月の消費を解放しよう。
2026-01-05 * "CloudAMQP" "Prepay 12 months Big Bunny at 99 per month"
Assets:Prepaid:CloudAMQP 1188.00 USD
Assets:Cash:Operating -1188.00 USD
2026-01-31 * "CloudAMQP" "January consumption against prepayment, prod plus staging"
Expenses:CostOfSales:Message-Broker 82.33 USD
Expenses:Research:Staging-Infra 19.00 USD
Assets:Prepaid:CloudAMQP -101.33 USD前払いの1年の有効期限は、使わなければ失うあらゆるクレジットを追跡するのと同じように追跡しよう。失効する残高は実際の損失であり、来年の整理時に発見するのではなく、カレンダーのリマインダーに値する。帳簿をプレーンテキストで管理しているなら、ドキュメントのコスト追跡パターンはインスタンスごとのブローカー分割に自然に拡張できる。
1つの分類の罠。データ転送の超過割増金とより大きな層はどちらもブローカーのコストだが、意味は異なる。層の変更は計画されたキャパシティであり、超過はフェアユースの許容範囲を超えた計画外の消費だ。両方ともブローカー勘定に計上するが、超過は別途タグ付けまたはメモして、それが現れる月が新しい基準ではなく例外として読めるようにしよう。
インスタンス時間を誠実に保つ5つの統制
秒単位の課金は注意に報い、設定して忘れることを罰する。これら5つの統制がよくあるぶれを捉える。
1. 請求書ごとではなく、インスタンスごとに照合する
各請求書の行を、あなたが認識し、承認した層で、月をほぼカバーする秒数のインスタンスと突き合わせよう。誰も所有していないインスタンスの行は、通常、忘れられたステージングブローカーか、3スプリント前の負荷テストクラスターがまだ秒単位で課金されているものだ。容赦なく削除しよう。ここではアイドルキャパシティに報酬はない。
2. すべてのサイズ変更をタイムスタンプとともに記録する
各プラン変更は月を価格設定された区間に分割する。日付、インスタンス、旧層、新層を含む軽量な変更ログ、共有ノートでさえあれば十分だ、を保持し、請求書の区間をそれと照合しよう。ログがなければ、$82.33のような合成合計は検証不能な計算だ。ログがあれば、計算は1分で確認できる。
3. マーケットプレイスの支出を同じレビューに引き込む
いずれかのインスタンスがHerokuやクラウドマーケットプレイス経由で請求されるなら、それらの行を直接請求書と同じ月次レビューに加えよう。元帳の摘要にマーケットプレイスを明記して、来月のレビュー担当者が決して存在しないCloudAMQPの行を探し回らないようにしよう。ここは二重請求が隠れる場所でもある。マーケットプレイスから直接請求に移行したインスタンスが数日間二重に動くことがある。
4. フェアユースの転送許容量が課金される前に監視する
データ転送はチーム支出の30パーセントまで含まれ、超過後、割増金が後の請求書に現れる前に30日の解決期間がある。最初の超過通知を統制として扱い、割増金として扱わない。どのインスタンスのトラフィックが急増したかを確認し、それがリトライストームやおしゃべりなコンシューマーではなく正当な成長であることを確かめ、期間内に解決しよう。クラスター全体にファンアウトするリトライループは、どの層も変えずに静かな月を転送超過に変えうる。
5. 取得を自動化する
コントロールパネルはすべての請求書を一覧表示し、顧客APIはインスタンス管理と並んで請求操作を公開しているので、月末の取得は人間がコンソールをクリックする必要はない。ダウンロードをスクリプト化し、インスタンス別の行を解析し、変更ログと見越計上と比較しよう。見越計上の見積もり自体も同じデータから得られる。層の料率に経過秒数を掛けたもので、サイクルの途中でサイズ変更があったときは前月の合計から推測するより優れている。
ブローカーコストの月末チェックリスト
数字が信頼できるままでいるよう、毎月同じようにループを閉じよう。
- 直接請求とマーケットプレイス請求のすべてのインスタンスとクラスターを一覧にし、それぞれにまだ所有者と目的があることを確認する。
- 各請求書の行を、インスタンス、層、時間区間と照合し、合成合計にはサイズ変更ログを使う。
- 本番とステージング、サンドボックスの支出を分け、売上原価に入ったのが本番のみであることを確認する。
- 前月の見越計上を決済済みの請求書に修正計上し、差異を翌月の見積もりに繰り越す。
- 前払いを実際の消費で取り崩し、残高を1年の有効期限と照らし合わせる。
- 転送使用量がフェアユースの許容範囲内にとどまったことを確認し、超過通知があればその30日の期間内に解決する。
- 月の間に作成されたすべてのインスタンスが正しい環境タグを継承し、初日から正しい勘定に着地したことを確認する。
今月のCloudAMQPの請求書を取得し、各行を名前を挙げられるインスタンスと突き合わせよう。すべての行がきれいに対応すれば、あなたのブローカー会計は誠実だ。1つでも対応しなければ、忘れられたインスタンスがまだ秒単位で課金されているか、別の請求書に隠れたマーケットプレイスの双子を見つけたことになり、どちらの発見もレビューの費用を回収する。
