要約

  • GitLab PremiumではGuestも課金対象。Ultimateでは条件を満たすGuestが除外され、Guestに追加する権限がread_codeだけのカスタム役割にも例外がある。
  • 「閲覧だけ」「外部協力者」という呼び名は料金を決めない。実際の役割と、同じ課金範囲にある別の所属まで確認する必要がある。
  • 権限追加で新たに課金対象となっても、購入済みの空席に収まれば直ちに追加請求が生じるわけではない。超過時は期間中の最大利用数が効くため、後日の降格で履歴は消えない。

招待するだけなら気軽だ。課題を読んでもらい、仕様について意見を求め、必要な人に必要な情報を渡す。その招待に「Guest」と書いてあれば、会議室の端に椅子を一脚足す程度の気分にもなる。

GitLabでは、その椅子に席料が付く条件が細かく決まっている。2026年10月30日に確認した席数管理の公式文書では、PremiumのGuestは課金対象で、UltimateのGuestには対象外となる扱いがある。同じ人を同じ名前で招待しても、契約プランが違えば分母が変わる。

ここにソフトウエア調達の盲点がある。値引き交渉で一席の価格を下げても、管理者が設定する役割によって有料席の人数が動く。単価を握る部門と人数を動かす部門が、別々の帳簿で仕事をしている。

コードを読む権利にも、別の入口がある

通常のGuestは、課題やエピックへの参加など、限られた仕事を担う。Guestの説明と権限一覧を読むと、非公開リポジトリのコードを普通に閲覧したり、変更をpushしたりするための役割ではないことが分かる。コードを読む必要がある人にReporterを与えると、その人は課金対象になる。書き込まない人も、無料とは限らない。

Ultimateには、もう一つ入口がある。カスタム役割の文書は、Guestを基礎にして、追加権限をread_codeだけにした場合、席を消費しないと明記している。コードを閲覧するという同じ作業でも、Reporterを与えるか、この狭い例外を使うかで料金上の扱いが分かれる。

この例外は、権限を自由に詰め込める無料の袋ではない。read_code以外の追加権限を付ければ、有料席を使う。カスタム役割は基礎となる役割の権限を減らす道具でもない。広い役割に「閲覧専用」という名札を付けても、基礎権限は狭くならない。

だから、利用者が社員か取引先か、常駐か月に一度の参加かといった人事上の分類では、この境界を説明できない。必要な操作を具体的に書き出す方が早い。課題に意見を出すのか。コードを読むのか。それ以上の操作も必要なのか。最後の一問が、料金の分母に触れる。

もちろん、その操作が仕事に必要なら権限を渡す。そのための有料席である。実態より狭い役割に閉じ込めて、別経路でコードを配ったり、アカウントを共有したりすれば、安く見えた帳簿の裏で管理が壊れる。買うべき仕事を決めてから、適した役割を選ぶ順番が肝心だ。

名札は一枚でも、所属は複数ある

一つのプロジェクトでGuestと表示されていることだけでは、例外の成立を確認できない。GitLab.comでは、対象となる契約の名前空間を見渡す必要がある。同じ範囲の別の場所に課金対象の高い役割があれば、目の前のGuestという表示だけを根拠に無料人数へ数えられない。

逆に、同じ契約の最上位グループ内で複数のプロジェクトやサブグループに所属しても、同じ人を所属の数だけ重複課金する仕組みではない。管理上の仕事は、メンバーシップの行を足すことではなく、その人が課金範囲内で持つ役割を確かめることになる。

Self-Managedでは確認範囲がインスタンス全体へ広がる。公式文書は、ユーザーがプロジェクトを作成するとMaintainerやOwnerとなり、有料席を消費し得る点にも触れている。GitLab.comの契約グループだけを見る手順を、そのまま自社運用環境へ持ち込むと境界を取り違える。画面の似た製品でも、席数の調査範囲は同じではない。

今日の空席と、昨日の満席

権限を増やして課金対象者が一人増えたところで、必ず一人分の追加請求が出るわけではない。購入済みの席に余裕があれば、まずその空席を使う。この区別を抜かすと、アクセス管理の話がすぐに架空の請求書になる。

問題が値札を伴うのは、課金対象者が購入数を超えるときだ。席数管理では請求期間中の最大数が重要になる。一度超過してから人を外しても、過去の最大数は消えない。現在のメンバー一覧がすっきりしていることと、精算に使う履歴がすっきりしていることは別の事実である。

同時に、過去に参加した全員の人数を延々と累積する制度でもない。購入数の範囲内で席を再利用できる。ピークを数える仕組みを、名簿の生涯通算人数と混同してはいけない。

超過分の精算は、適用条件によって四半期または年次で行われる。四半期精算はその四半期の最大数と残りの契約期間に応じた計算を使い、年次のtrue-upでは追加ユーザーに年間購読料が適用される。全社が同じ周期で、利用した日数だけを払うという前提では計算できない。契約管理の文書では、購入席数を減らす機会は更新時に置かれている。

権限を戻す操作は今日できる。契約数量を減らす時計は、更新日まで進まないことがある。アクセスを許可する瞬間と、調達担当者が数量を調整できる瞬間には、このずれがある。

上位プランは、無料の入口も売っている

公開価格では、Premiumは年間払いで一人月額29米ドル、Ultimateは個別見積もりとなっている。Ultimateの無料Guestだけを見て「高いプランへ移れば安くなる」と結論を出すのは早計だ。損得を出すには、実際のUltimate見積額と、必要な権限別の利用者分布が足りない。

ただし、売り方の構造は見える。上位プランは機能を増やすと同時に、ある種の参加者を有料人数から外す。利用者を広く招き入れ、必要な操作が増えたところで有料席との境界が現れる。買い手は、機能の束と、誰が分母に入るかという規則を一緒に購入している。

そこでは、権限設計が費用管理に役立つ。狭い権限で仕事が足りる人に、習慣で広い役割を与える理由はない。一方、人数の見栄えをよくするために仕事を止める理由もない。必要な機能、適した役割、既存の空席、精算条件を同じ判断に載せればいい。

招待状を送る人にも、席料を変える権限がある。購買部門が次の見積もりを待つ間に、管理画面ではすでに人数の交渉が進んでいる。