要約

  • 最高数量課金が適用される月額アプリでは、途中でユーザーを減らしても当期の課金数量は下がらない。支払い済みの空席は同じ期間内に再配分できる。
  • 公式例の月18ドルと残り25日を使うと、三人を先に追加する順番には45ドルの追加費用が生じる。先に三人を削除する順番なら、当初の十席を超えない。

経費の説明に使う月末名簿が、肝心の場面を見ていないことがある。十人から七人を経て十人に戻ったのか。十人から十三人を経て十人に戻ったのか。最後の一枚だけなら同じだが、Atlassianの月額課金は途中の十三人を覚えている。

これは実際の顧客請求を再現した場面ではなく、公開ルールに基づく比較である。同じ人数の交代でも、権限を渡す作業の順番が購入量を変える。その差は値引き交渉よりずっと小さな場所、二つの管理作業の間にある。

消した名前より、買った席が長く残る

最高数量課金の説明では、すでに課金される数量を超えてユーザーを追加すると、その数量が増える。増員分は当期の残り期間に応じて日割り計算され、次の請求に加わる。途中でユーザーを削除しても当期の費用は減らず、その席を別の人に割り当てられる。

対象となる有料月額アプリを十人で開始したとする。五日目に三人のアクセスを終了し、別の三人に新しく付与する。削除を先にすれば七人になり、追加して十人。購入済みの枠内で済む。追加が先なら十三人になり、その後十人へ戻しても当期の課金数量は十三人にとどまる。

公式の例示単価は一人月18ドルだ。現在のJiraの販売単価ではない。30日間の仮定で残り25日と置けば、後者の追加費用は3 × 18 × 25 ÷ 30、45ドルとなる。前者の入れ替えによる追加席の費用はゼロ。この45ドルはルールから導いた条件付きの試算であり、全員分を一か月遡って課金する計算でもない。

公式のMelissaの例に出る279ドルには、別の内訳がある。三人追加したまま十三人で月を終え、翌月分の基本額234ドルに当期の追加分45ドルを足した数字だ。今回の二つの経路は、どちらも十人で終わる。279ドルと180ドルを直接比べれば、翌月の人数差まで順番の効果に混ざってしまう。

最初のログインを料金は待たない

ユーザー管理の説明によれば、アプリに追加されたユーザーは、招待を受諾していなくても、一度もログインしていなくても、月額のユーザー数に入る。権限があれば、利用開始の前に席は成立する。

従って最終ログイン日は請求数量の代理にならない。作業が行われた記録と、作業できる権利を渡した記録は別物だ。ログインしていない人の仕事ぶりを推測する必要はない。費用の確認には、そのアプリに本当にアクセスが付与されたか、すでに支払い済みの席がいくつあるかを調べる必要がある。

単に何らかの招待メールを送ったという情報だけでも足りない。製品への追加と権限付与が、課金対象のアプリでどう記録されているかが重要だ。「招待中」の表示だけを眺めると、入口を開けた時刻と本人が使い始めた時刻を取り違える。

会社が数える人員と、売り手が売る余白

Atlassianは2025年の発表で、この方式を予測可能性や追跡の簡素化と結び付けた。現在の説明はCompass、Confluence、Atlassian Guard、Jira、Jira Product Discovery、Jira Service Management、Loom、Marketplaceアプリの対象月額契約を挙げている。2026年の新しい値上げ発表として扱う話ではない。購入・ライセンスFAQでは年額Cloud契約のユーザー階層と区別されている。

売り手にとっては、一度提供したアクセスの余力を当期の購入量として残す仕組みだ。買い手の予算は人員数で組まれていても、追加の権限は別の担当者が、別のタイミングで作る。増員決裁がなくても、一時的な重複は容量購入になる。請求書だけがこの部門間の時差を正確に引き取る。

ただし、最高人数が永久に続くわけではない。期間最終日のユーザー数が、翌月開始時の課金数量になる。公式のArmandoの例では十人から三人を削除しても当期の十席は残り、三席を再利用できる一方、翌月は七人から始まる。

実際の差額には製品・プランの単価体系、期間の日付、既存の課金数量と権限変更履歴が要る。それでも、同じ人数で終わることが同じ請求を保証しない点は明確だ。業務の引き継ぎに必要な重複には対価がある。管理依頼の順番だけが生んだ重複にも、同じ値札が付く。違いを知っているのが請求書だけ、という状態を終わらせたい。