Content last updated 2026-04-02

ライセンスと更新

ライセンスと更新（L&R）は、顧客が GitLab のサブスクリプションを購入または更新する際に直面する問題を解決するための活動全般を指します。

概要

L&R サポートエンジニアは、顧客が GitLab サブスクリプションを購入または更新する過程で 遭遇する問題の解決を支援します。

L&R 業務は、一般的に顧客や他の GitLab チーム（主にセールスとフルフィルメント）と連携することに加え、 GitLab 内部のシステムを確認したりデータの妥当性検証を行ったりすることを含みます。例:

  • サブスクリプションの購入や管理に関するユーザーからの一般的な問い合わせへの回答
  • ライセンスアップロードエラーやサブスクリプションの紐付けに関する Issue のトラブルシューティング
  • セールスチームメンバーからの L&R に関する依頼の支援

沿革

2020 年 7 月、L&R 業務は当面の間サポートが扱うべきという決定がなされました。 当時、ビジネスクリティカルな優先事項 により、Fulfillment 製品セクション は L&R 関連の主要な Issue に対処・解決するための十分なキャパシティを確保できませんでした。 この業務のために完全に新しいチームを作るのは難しかったのに対し、 サポートはすでに関与しており、顧客ニーズに応えるべく短期間で規模を拡大できる状況にありました。

連絡先

サポート管理側の連絡先

  • 各リージョン DRI: Ryan Farber, John Lyttle, Ket Slaats

Support Stable Counterparts

現在の Support Stable Counterparts については、Product Handbook の Fulfillment セクションの説明 を参照してください。 L&R SSC への参加に興味がある場合は、ご自身のマネージャーまたは Regional DRI のいずれかにご相談ください。

方向性

セールス、フルフィルメント、その他のチームと協力して、サブスクリプション管理に関連する顧客体験の 改善を目指します。私たちはこれを以下によって達成します:

  • プロセスの自動化
  • プロセス改善の提案
  • バグの報告と修正
  • 外部および内部顧客に対する Service Level Objective の達成

リージョン別 L&R チーム

  • AMER チーム ページ
  • APAC チームページ
  • EMEA チームページ

L&R を担当するサポートエンジニア向けの情報

L&R チケットの作業を始める前に、必ず L&R / Subscriptions トレーニングモジュール を完了してください。

中核となる概念

L&R エンジニアとして、私たちが日々関わる用語、表現、機能の中核となる概念を理解しておきましょう。 次のいくつかの段落でこれらの概念を説明します。 用語表 も参照できます。

Subscription（サブスクリプション） は、ある期間にわたり特定のティアの機能を購入することを表す用語です。 サブスクリプションを構成する 2 つの要素があります:

  • SaaS または Self-Managed。これはサブスクリプションがどこに「適用」されるかを定義します。 GitLab Dedicated は、適用方法の観点では Self-Managed として扱われます。
  • Tier（ティア）。これは異なる機能へのアクセスを提供します。Premium または Ultimate が含まれます。

License（ライセンス） は、Self-Managed インスタンスでサブスクリプションを有効化するために以前必要とされていた レガシー ファイルです。GitLab 14.1 以降、有効化はほぼ常に クラウド有効化コード で扱われるようになりましたが、いくつかの例外があります:

  • Offline cloud licensing は、オフライン環境でクラウドライセンスを利用できるようにします。顧客は手動で利用データをダウンロードし、定期的にメールで送信する必要があります。最低でも GitLab 15.0 が必要です。
  • GitLab 14.1 より前のバージョンを使用しているインスタンスについては、顧客はセールス購入または更新プロセスの一環として、GitLab 担当者と協力して例外を申請する必要があります。
    • GitLab の サポート方針 に記載されている通り、サポートチームは（ほぼすべての状況で）GitLab 14.x より前を実行している顧客を支援できないので、これは顧客にアップグレードを促す追加の動機づけとなります。
  • Cloud Licensing のための販売後例外 は稀で、社内リクエストとセールス VP の承認を必要とします。
  • ライセンスファイルは、Self-Managed の トライアル ではいまだに使用されています。

Namespace（名前空間） は、ユーザーがサブグループとプロジェクト内で協働できるトップレベルのグループであり、他の名前空間とは別個のエンティティとして扱われます。SaaS 顧客は名前空間に対してサブスクリプションを購入します。これは、その名前空間が購入したティアの機能（Premium や Ultimate など）にアクセスできることを意味します。例として、"Example Corporation" 社が gitlab.com/example-co にある名前空間を持っているとします:

  • このパスの下に作成されたすべてのサブグループ（gitlab.com/example-co/marketing）とプロジェクト （gitlab.com/example-co/development/webapp）は、サブスクリプションの有料機能にアクセスできます。
  • 同じ会社が使用している別の名前空間 gitlab.com/example-net は、サブスクリプションに含まれず、有料機能にアクセスできません。

Web Direct 顧客は、GitLab.com および／または customers.gitlab.com を経由して 直接的に サブスクリプションまたは製品を購入した顧客です。Sales-assisted 顧客は、サブスクリプションまたは製品を購入する際に Salesforce を経由してセールスから支援を受けた顧客で、契約が関わるエンタープライズ組織でよく見られます。

Cloud Licensing （Cloud Activation、Cloud License とも呼ばれます）は、Self-Managed インスタンスでサブスクリプションを有効化するための、現在のデフォルトかつ推奨される方法です。Cloud License は顧客が Self-Managed インスタンスに適用する 24 桁の英数字コードです。Cloud License のメリットの一例:

  • ライセンスファイルを毎年再適用する必要がない
  • Quarterly Subscription Reconciliation (QSR) を使って Users over Subscription を調整できる

Quarterly Subscription Reconciliation (QSR) は、Users over Subscription（サブスクリプションを超過したユーザー）が発生した場合など、サブスクリプション契約を超える追加の利用を調整する方法です。有効化されている場合、QSR は四半期ごと（3 か月ごと）に実行され、シート利用が現在の上限を超えていればインボイスを生成します。

アドオン

L&R チームは多くの異なる種類の購入を扱い、また単発もしくは継続的な アドオン のトラブルシューティングも支援します。GitLab Self-Managed では主にサブスクリプション購入のみが行われますが、GitLab.com では Compute Minutes や Storage and Transfer など、さまざまな種類のアドオンを購入できます。

Compute Minutes

以前は「CI/CD Minutes」または「Compute Credits」として知られていた Compute Minutes は、GitLab.com（SaaS）上で GitLab マネージドの Runner（Shared Runners）を利用するためのものです。各ティアにはサブスクリプションの一部としてユニットが付与され、毎月リフレッシュされます:

  • Free（サブスクリプションなし）: 400
  • Premium: 10,000
  • Ultimate: 50,000

ユニットは 分数と 1:1 で対応していません。パイプラインで 使用される Runner の種類 を含む コスト係数 が適用されます。顧客は いつでも追加ユニットを購入 できます。

Storage and Transfer

GitLab.com（SaaS）では、プロジェクトのストレージ上限が適用されます。デフォルトのストレージ上限は プロジェクトあたり 10 GB です。プロジェクトがストレージ上限に達すると、超過ストレージ使用 として扱われ、追加ストレージが購入されるまで読み取り専用状態に入る可能性があります。追加ストレージは いつでも購入できます。

ストレージとトランスファー上限の扱いを ネームスペースレベル で考慮するための変更が計画されていますが、現時点では適用されていません。詳細は ストレージ管理改善 Issue および Pricing FAQ を参照してください。

担当する業務

  • Zendesk の L&R キュー内のチケット。このキューには、顧客からのチケットだけでなく、GitLab チームメンバー（セールス、CSM など）からのチケットも含まれます。チームメンバーからのチケットは「内部リクエスト」と呼ばれ、それに関する情報は 内部リクエスト対応ワークフローページ で確認できます。
  • サブスクリプション、ライセンス、更新関連トピックに関する マーケティングページ、 製品ドキュメント、GitLab ハンドブック、ワークフロー の作成および／または更新。
  • 顧客、サポート、またはその両方にとって重要な製品 Issue の特定、および L&R サポートチーム全体および Fulfillment プロダクトマネジメントチームと連携してエンジニアリングに対する優先順位付けの調整。
  • 一部のチームメンバーは、Customers Portal の変更について Fulfillment エンジニアと密接に協力してレビューと共同作業を行います。参加し関連する MR で通知を受け取りたい場合は、レビュアーグループの直接メンバーとして自身を追加してください: https://gitlab.com/groups/gitlab-com/support/licensing-subscription/reviewers。

アクセスが必要なシステム

この業務を効果的に行うためには、他のサポート問題タイプの業務では普通触れないシステムやツールへのアクセスが必要です。このリストはサポートエンジニアの職種における基本的な権限に追加されるものです。

CustomersDot

CustomersDot は、GitLab が構築したウェブアプリケーションの通称で、https://customers.gitlab.com にあります。すべてのライセンスとサブスクリプションの管理はこのサイト上で行われます。顧客のライセンスやサブスクリプション情報を生成、転送、変更するためにアクセス権が必要です。CustomersDot の アクセスリクエスト (AR) を提出する際には、次の情報を使用してください:

  • System name:

    CustomersDot - admin

  • Justification for this access:

    L&R Support Engineers need CustomersDot admin access to work on customer licensing and subscriptions issues and to debug issues on the application itself.

Salesforce

Salesforce.com (SFDC) アカウントがあると、Chatter メッセージで自分がタグ付けされた際に通知を受け取れる（セールスとの協働ワークフロー を参照）ため、セールスチームメンバーとの連携がより効率的になります。

個別／一括アクセスリクエスト を作成する際には、以下の情報を使用してください:

  • System name:
    • If you are a US citizen:

      SalesForce, Role: Executive - No View All, Profile: Read Only GitLab, with US public sector record visibility

    • If you are not a US citizen:

      SalesForce, Role: Executive - No View All, Profile: Read Only GitLab

  • Justification for this access:

    L&R Support Engineers need their own Salesforce accounts to better collaborate with Sales team members as they work on customer licensing issues.

Slack

ライセンスと更新のチケットや顧客 Issue に関する議論は、Slack の #support_licensing-subscription チャンネルで行われます。これにより以下が確保されます:

  • L&R team members will have one channel in which to collaborate
  • Increased visibility in queries and shared knowledge
  • Increased cohesion in the L&R team regardless of region

APAC リージョンのサポート時間の開始時（23:00 UTC）に、 Support Daily Slackbot が L&R チケットに何らかの責任を持つ APAC のサポートエンジニア全員にタグ付けする投稿を行います。このスレッドはチームに今週は誰が休暇かを通知し、チームメンバーがキューにいつ取り組んでいるかをお互いに更新できるようにします。これにより、APAC リージョンのサポート時間にわたって L&R チケットのカバー範囲の信頼性を確保するのに役立ちます。

Zuora

Zuora は、製品 SKU、サブスクリプション、インボイスなど、サブスクリプションや更新に関連する多くの項目について single source of truth または system of record と見なされています。詳細は Transition to Zuora as the SSOT issue を参照してください。

Zuora にアクセスできると、顧客の CustomersDot と Salesforce のレコードが矛盾していたり混乱していたりする状況でのトラブルシューティングに役立ちます。

個別／一括アクセスリクエスト を作成する際には、以下の情報を使用してください:

  • System name:

    Zuora READ-ONLY access

  • Justification for this access:

    L&R Support Engineers need read-only Zuora access to troubleshoot Licensing and Renewal customer issues and support requests.

ワークフロー

便利なツール

連携するチーム

Product

キューや Issue に取り組む中で、Fulfillment バックログ に、顧客やサポートのために改善できる項目が見つかったら、Support Interest::Categorize ラベルを付けてください。詳しくは サポートの Fulfillment 用 Issue リスト を参照してください。

Fulfillment ステージ

Fulfillment ステージは、購入とプロビジョニング、CustomersDot の利用、サブスクリプション管理を扱います。これらのチームは、私たちが普段キューで目にするリクエストの種類に対応する責務を持っています。

Slack の #s_fulfillment チャンネル

Growth ステージ

製品の Growth ステージを見ると、このチームが私たちが普段キューで目にするリクエストの種類に対応する責務、特に Conversion グループの責務を持っていることがわかります。

サポートにおける L&R 業務の 対象範囲外

このキューは以下の用途では使用しないでください:

便利なリンク

製品ドキュメント

マーケティングページ

ハンドブックページ

Issue トラッカー

Issue トラッカー用途
GitLab Issue Trackerself-managed や GitLab.com の機能やバックエンド処理に関連する Issue
CustomersDotCustomersDot 内の何かによって特に引き起こされた Issue、または self-managed のライセンス生成や生成済みライセンスに影響する Issue
ライセンスと更新の用語集
ライセンスと更新ワークフローで使用される用語のリスト
AMER ライセンスと更新チーム
AMER リージョンのライセンスと更新サポートチームに固有の情報
ライセンスと更新のワークフロー
最終更新 June 14, 2026: Merge pull request #403 from kyama0/claude/cool-turing-ls6eck (bfd74782)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License