更新日:2026年9月18日

9分で読めます

AIクレジットを誰がどれだけ使ったのか、ユーザー単位で把握する

GitLab 19.4では、設定ページからユーザー単位でGitLabクレジットの上限を設定できます。使用量が急増した原因のセッションをエクスポートし、チームごとのAI消費量をそれぞれのチームに示すことも可能になりました。

組織全体でAIを広げていくには、予算がどこに流れ、誰が使っているのかを把握する必要があります。サブスクリプションの上限は総額を予算内に抑えてくれますが、チームごとにどれだけAIが使われたのかは分かりません。しかもチームが増えるほど、事業の動きを先読みした予算計画はいっそう難しくなる一方。ユーザー単位のデータがなければ、AI支出に公平な上限を設けることも、使用量が急増した理由を説明することも、部署ごとの消費量を示すこともできません。

GitLab 19.4では、GitLabクレジットをユーザー単位で管理できるようになりました。個人ごとに予算を設定し、支出を確認し、請求内容を裏付ける詳細なレポートをエクスポートできます。チームごとに独自の予算を割り当て、デベロッパー一人ひとりに自分の消費状況を見せることも可能。特定のヘビーユーザーがチーム共有のクレジットを使い切ってしまいそうなときは、使用量を制限し、直近の急増の裏にあったセッションデータを正確に取り出せます。消費の状況が変われば上限を調整すればよいので、誰の作業を優先するかを交渉し直すためにチームが足を止める必要はありません。

AI支出の管理は、もはや後回しにできない課題です。GitLabの調査レポート「AI Accountability Report」では、回答者の98%がAIガバナンスに予算を割り当てている、または割り当てる見込みだと回答。部門をまたいでAI予算を確約するのであれば、明確で、説明でき、レポートにできる使用状況データが欠かせません。

GitLab Transcendが10月に再び開催

コーディングエージェントによって開発のスピードは上がっていますが、レビュー、セキュリティポリシー、リリースサイクルもそれに追いつく必要があります。10月6日のTranscendでは、GitLabがチームのギャップをどう埋めているのか、そしてエージェント型AIのスピードをソフトウェアライフサイクル全体に広げるには何が必要なのかをご紹介します。

今すぐライブ配信にご登録ください

使用量をきめ細かく特定し、可視化する

GitLabクレジットは1件ごとに、ユーザー、ネームスペース、プロジェクト(該当する場合)とタイムスタンプを紐づけて記録されます。ユーザーが上限に達したかどうかを判定しているレコードは、どのチームがどの操作でいつ、どれだけのクレジットを消費したのかに答えるレコードと同じもの。エージェントのセッションを実行したプラットフォーム自身がクレジットを記録しているため、この記録を作るために2つのシステムを突き合わせる必要はありません。

まず各チームに使用量を示し、チャージバックはその後で判断する

ショーバック(showback)とは、各チームの消費量をその部署に報告する運用です。何をどれだけ使ったのかを見せ、すでに支払っている分を使い切れているかどうかは部署自身に判断してもらいます。消費量を目にすれば、多くのチームは自ら使い方を調整するもの。記録は将来のチャージバック(費用の実負担)に向けてそのまま残ります。

予測にはチーム単位の基準値が必要

エージェント型のフローがCIパイプラインを流れ始める前に、200人規模のデベロッパーチームが通常の1か月でどれだけ消費するのかを知っておく必要があります。また、2つのチームの使用量を比べるには、その前段として、使用モデルに応じたクレジット消費コストをユーザー単位のデータから把握しておかなければなりません。

スピードには制御が伴う

プラットフォームエンジニアリングのチームはこの10年、自律性と、目に見えて実効性のある境界線を組み合わせることで、デリバリーチームがCI/CDとセキュリティの領域で安全に独立して動ける状態を作ってきました。エージェント型の自動化も、規模の広げ方は同じ。チームに専用の予算を渡し、その支出を確認し、コストが見えている状態で次のフロー群を承認していく、という進め方です。

組織のあらゆる階層に効く予算ガードレール

サブスクリプションの上限に達すると、クレジットを消費する機能は全ユーザーで停止し、次の請求期間になるか管理者が上限を引き上げるまで使えません。一方、個人の上限に達した場合、影響を受けるのはその本人だけです。

警告は明確です。GitLabクレジットダッシュボードは、クレジット使用量が**50%、80%、100%**に達した時点と、サブスクリプションの上限に達した時点で、管理者にメールで通知。ただし注意点が1つあります。使用量の同期はリアルタイムではなく定期的に行われるため、すでに進行中の支出が、上限の適用が追いつく前に上限を超えてしまうことがあります。

制御レイヤーをもう1つ追加するのがGitLab Flexです。共有の予約枠に対して、各機能をRestricted(制限)、Usage cap(使用量上限)、Unlimited(無制限)のいずれかに指定する仕組み。これにより、ある機能の使いすぎが、他のすべての機能に必要な分を食いつぶすことがなくなります。

設定ページで完結するユーザー単位の上限と例外

Credit capsページでは、ユーザー単位の2つのコントロールが1つの画面にまとまっています。全員に適用されるデフォルト値を決めたうえで、個人ごとに引き上げたり引き下げたりできます。

  • 一律のユーザー上限:各ユーザーが1請求期間に消費できるGitLabクレジット数を入力し、適用をオンにします。オーバーライドを設定しない限り、サブスクリプション上の全ユーザーがこの上限を継承します。
  • ユーザー単位のオーバーライド:Add overrideを選択し、ピッカーで1人または複数のユーザーを検索して上限を設定し、保存します。オーバーライドは一律の上限より高くも低くも設定できるため、スタッフエンジニアの引き上げと業務委託メンバーの引き下げを同じページで行えます。
  • 元に戻せる例外設定:オーバーライドにはそれぞれ有効化トグルが付いています。トグルをオフにして保存すれば、そのユーザーは一律の上限に戻ります。例外を解除しても何も削除されないため、また必要になった月まで数値はテーブルに残ったまま。

一律の上限のトグルはマスタースイッチの役割を持ちます。オフにすれば、オーバーライドの適用も止まります。

クレジット上限の設定画面

請求対象イベント単位まで掘れる使用状況エクスポート

エクスポートはバックグラウンドで実行され、安全なダウンロードリンクとしてメールで届きます。1回のエクスポートの対象期間は最大31日間で、含まれるファイルは3つ。これまで使ってきた日次サマリー、新たに加わったイベント単位のファイル、そしてmanifestです。

  • イベントID、タイムスタンプ、イベントタイプ
  • プロダクトとフロータイプ
  • セッション識別子
  • ユーザーID
  • ネームスペースID
  • プロジェクトID
  • 消費クレジット数、数量、単位
  • LLM呼び出し回数、トークン合計、使用モデル
  • Flexの機能とサブスクリプション名

グループで「Display GitLab Credits user data」をオフにしている場合、ユーザー関連の列もその設定に従います。

ネームスペースIDでグループ化すれば、部署ごとの1行が得られます。これがショーバックの土台。ユーザーIDと日付で絞り込めば、先週火曜日の急増の裏にあったセッションが浮かび上がります。ネームスペースが会計上のコストセンターと直接一致することはまれなので、一度マッピングを作っておけば、以降の月次エクスポートは自社のコスト構造をそのまま反映します。

クレジット使用量のマッピング

デベロッパーに見えるもの

トップレベルグループのメンバーは誰でも、ユーザー設定から自分用のGitLabクレジット画面を開き、日単位の消費チャートを確認できます。グループのダッシュボードと同じプロダクトフィルターと期間指定を備え、表示範囲は自分自身のイベントに限定されます。

クレジット使用状況レポート

付与済みのプロモーションクレジットを評価用クレジットより先に消費

月ごとに付与されるプロモーションクレジットは、共有の評価用クレジットが使われる前に、ユーザー単位で適用されるようになりました。各ユーザーはまず、すでに権利として持っている分を消費します。付与されるクレジットはPremiumシート1つあたり月12、Ultimateシート1つあたり月24。評価用のプールはサブスクリプション全体で共有されます。請求書の内容は変わらず、Monthly Commitment Pool、One-Time Charge、On-Demandクレジットの順序もこれまでどおりです。

全員に予算を開放せずに特定チームの重い使用量をまかないたい場合は、一律の上限を低く設定し、エージェント型の作業に取り組む人だけをオーバーライドします。上限が適用されるのは付与クレジットを使い切った後なので、一律の上限のままの人も毎月の付与クレジットは満額そのまま。共有プールが負担するのは例外の分だけで、全員分ではありません。

始め方

GitLabクレジットの使用状況の可視化は、PremiumおよびUltimateのサブスクリプションに含まれており、すでにご利用いただけます。

  • OwnerまたはAdministratorの権限があれば、GitLab.comとSelf-ManagedでCredit capsページを開けます。
  • 請求先アカウントを管理している場合は、GitLab.com、Self-Managed、Dedicatedでイベント単位のエクスポートを取得できます。
  • デベロッパーであれば、GitLab.comで自分の使用状況画面を確認できます。

1. サブスクリプション全体の上限を決める 請求先アカウントの管理者は、GitLabカスタマーポータルのGitLab Credits dashboard > Spend controlsから設定します。全員分のOn-Demandクレジットに上限をかける設定です。

2. ユーザー単位の上限を設定する グループのOwnerは、トップレベルグループの設定 > GitLab Credits > Credit capsを開きます。GitLab Self-Managedの管理者は管理者エリア > GitLab Credits > Credit capsへ。手順の詳細はCredit capsページをご覧ください。全員共通のデフォルト値1つに、必要な分だけオーバーライドを加える形です。

3. 何が起きたのかをエクスポートする GitLabクレジットダッシュボードまたはGitLab Flexの月次概要から、Export usage dataを選択します。請求対象イベント1件につき1行、最大31日分がメールで届きます。

ユーザー単位のデータをレポートするには、GitLab.comまたはSelf-ManagedインスタンスのトップレベルグループでDisplay GitLab Credits user dataがオンになっていることをご確認ください。この設定はデフォルトでオンのため、ほとんどのグループで変更は不要です。

すでに設定済みの内容が変わることはありません。サブスクリプションの上限はこれまでどおり動作し、適用の挙動も変わらず、GraphQL APIが書き込む先も設定ページが読み取るレコードと同じなので、既存の自動化はそのまま動き続けます。クレジット種別ごとの消費順序の全体像は使用順序のドキュメントに記載。

次のステップ

まずはサブスクリプションの上限を設定し、先月の使用状況をエクスポートして分析してみてください。

GitLab Duo Agent Platformをまだお使いでない方は、無料トライアルから。すでにPremiumまたはUltimateをご利用中の方は、Duo Agent Platformを有効化して、サブスクリプションに含まれるクレジットをご活用ください。

ご意見をお寄せください

このブログ記事を楽しんでいただけましたか?ご質問やフィードバックがあればお知らせください。GitLabコミュニティフォーラムで新しいトピックを作成してあなたの声を届けましょう。

フィードバックを共有する

今すぐ開発をスピードアップ

DevSecOpsに特化したインテリジェントオーケストレーションプラットフォームで実現できることをご確認ください。