要約

  • GitLab.com の対象ジョブは、実行したプロジェクトが属する最上位の名前空間の利用枠を消費する。プロジェクトやサブグループの管理を分けても、計算資源の予算が分かれるとは限らない。
  • 購入した追加のコンピュート分は未使用分を繰り越せるが、グループ間では移転できない。有効期間は購入から十二カ月とされ、現在は失効処理を実施していないものの、その後の有効性は保証されない。
  • 利用枠の残量、実行環境の空き、安全に実行できる権限は別の条件である。追加購入を、能力や権限まで確保する手段と考えると判断を誤る。

自治できる範囲と、共同で支払う範囲

開発チームを分ける目的の一つは、日々の判断を現場に近づけることだ。別のチームが承認するのを待たず、必要なテストを実行し、修正を確かめられる。しかし、判断の単位と資源を消費する単位が一致するかどうかは、別途確かめなければならない。

GitLab.com はその違いをはっきり示す。例えば、顧客向け製品を開発するプロジェクトと、社内用の道具を整備するプロジェクトが、同じ最上位グループにあるとする。これは仕組みを説明するための仮定であり、実在の顧客事例ではない。両者がコードも発売日も共有していなくても、対象となるホスト型ジョブを動かせば同じ利用枠を減らす。

コンピュート分の説明によれば、使用量の帰属先はジョブを実行するプロジェクトの最上位の名前空間である。他人のプロジェクトで実行を開始したからといって、開始した個人の名前空間に付け替わるわけではない。誰が操作したかより、仕事をどこで実行したかが重要になる。

名前空間の仕様では、グループの下にサブグループを設け、一部の設定を個別に持たせることもできる。その管理上の区分を、最上位の利用枠が別々にあることと読み替えてはいけない。画面上で分かれて見えることと、共通の残量に依存しないことは同義ではない。

共同の枠が不利とは限らない。チームの繁忙期がずれていれば、あるプロジェクトが使わない分を別のプロジェクトが活用できる。余裕を個別に買い込む必要が減り、管理も簡素になる。問題は共有そのものより、共有している事実が意思決定の中に入っているかどうかだ。

速く終わった仕事が、少なく消費したとは限らない

コンピュート分は、開発者が画面の前で待った時間ではない。ジョブの実行秒数を六十で割り、コスト係数を掛ける。作成済みや待機中の時間は、この計算には含まれない。パイプライン全体では、動いた各ジョブの消費量を足し合わせる。

係数を一とし、それぞれ十分間かかるジョブを三つ並行して実行する簡単な例を考えよう。追加の作業や時間を含めないなら、実行が重なる区間は十分間でも、合計は三十分のコンピュート分になる。これは単位の違いを示す算数であって、実測性能や顧客の総費用を推計するモデルではない。

早く結果を得られることには価値がある。その価値を買うために並列性を増やす判断もあり得る。一方、重複する作業を取り除けば、時間と消費量の両方が改善する場合もある。パイプラインの効率化に関する資料は、処理の依存関係、クリティカルパス、実行環境の準備、機械の資源などを分けて扱っている。

したがって、あるチームの完了時間が短くなっただけでは、共同予算に余裕を生んだとは判断できない。逆に消費量が下がっただけでも、必要な検証を残したまま効率が上がったとはいえない。測定単位を取り違えると、丁寧に検証するチームが非効率に見え、検証を減らしたチームが優秀に見えてしまう。

残量ゼロは、一つの瞬間だけではない

利用枠の適用ルールは、残りが二十五パーセント未満、五パーセント未満、ゼロになった時点での通知を定めている。名前空間の所有者にメールが届き、アプリ内にも表示される。各プロジェクトが次にどれだけ動かすかを、この通知が予測してくれるわけではない。

対象となる利用枠を使い切ると、インスタンスランナーは新しいジョブを処理しなくなる。すでに始まったパイプラインでも、それらのランナーを必要とする待機中や再試行のジョブは取り消される。実行中のジョブには条件付きの猶予があり、名前空間全体の使用量が利用枠を千コンピュート分超えるまでは続けられるが、その境界を超えると残る実行中ジョブも取り消される。

千という数字は、一つのジョブや一つのプロジェクトに与えられた予備費ではない。複数の実行が同じ名前空間の超過分を増やしている可能性がある。始めてしまえば最後まで動くという保証でも、毎月自由に足せる新しい割当でもない。この特定の利用枠の対象外であるプロジェクトランナーとグループランナーは、処理を続ける。

ここで起きる停止は、サービス障害とは区別する必要がある。提供側が仕様通りに動いているのに、利用側では必要な仕事が進まないことがあるからだ。障害の復旧を待つべき場面と、権限のある人が追加購入や作業計画を判断すべき場面では、対応の責任者が違う。

同じ会社の残量でも融通できない

共同財布の外側には、もう一つの境界がある。追加購入の資料は、購入済みコンピュート分をグループ間で移転できないと明記している。同じ会社が複数のグループを使っていても、一方の余剰を帳簿上合算するだけで他方の実行に充てることはできない。

購入した追加分は、月次の付与分を使った後で消費される。未使用分は後の月へ持ち越せるが、毎月同量が復活する契約ではない。購入時点で一度追加される枠と、定期的な割当は区別しなければならない。サブスクリプションのプランを変更しても購入分は利用でき、Free へ変更する場合も含まれる。

時間の制約もある。有効期間は購入から十二カ月と記載されている。現在は失効を実施していないという説明がある一方、期限後の有効性は保証されない。この二つを合わせて読む必要がある。古い残量が表示されているから永久に確保した権利だ、という読み方も、十二カ月経過した分はすべて削除済みだ、という読み方も正確ではない。

調達記録に必要なのは、金額と総残量だけではなく、購入先のグループと購入時期だ。購入できるのはグループの Owner または請求アカウントの管理者で、請求アカウントと当該グループのサブスクリプションの連携も必要になる。急いでテストを動かしたい人と、その条件を満たす人が同じとは限らない。

以上は、特定企業に使えない購入分が発生したという報告ではない。また、残量のためにプロジェクトを移すべきだという提案でもない。本稿の資料は、移行が他の権限や依存関係に及ぼすすべての影響を明らかにしていない。確認できるのは、将来の購入先を決める際に、グループの境界を無視できないという点である。

買えることと、動かせること

利用枠を増やせば、必ず次のジョブが動くのだろうか。ランナーの説明を見ると、実行には範囲やタグ、状態、能力、空き容量などの適合が必要だと分かる。ランナーを誰が管理するかという区分と、どのプロジェクトで利用できるかという区分も別である。追加購入で不適合や権限の問題まで解消するわけではない。

ホスト型ランナーの利点は、通常の GitLab.com のジョブに新しい仮想マシンを用意し、実行後に削除する運用を提供側が担う点にある。コミュニティー貢献向けの特別な基盤は性質が異なるので、あらゆる実行を一律に説明することはできない。

同資料には、九割のジョブを百二十秒以内に開始するというサービス水準目標もある。これは目標であり、本稿が測定した達成率ではない。購入した次のジョブに対する予約でもない。残量を持つことと、必要な時に適合する機械が使えることは、別々に確かめるべき条件である。

さらに、安全に実行してよいかという条件が残る。マージリクエストの実行仕様では、フォークからの作業は通常そのフォーク側の資源で動く。一方、権限を持つメンバーが親プロジェクトで実行を始める場合には、外部ブランチの設定を親側の実行文脈や資源と組み合わせる。このため、資料は信頼できないコードの確認を求めている。保護された変数やランナーには別の制限があり、親で動かせばあらゆる秘密に触れられるという意味ではない。

自前のランナーを使う選択にも、別の責任が伴う。セキュリティー資料が扱うように、ホスト、ネットワーク、実行方式、ジョブ間の分離を管理しなければならない。再利用する環境を複数のプロジェクトで共有すれば、その分離を検討する必要がある。特定の利用枠から外れることは、計算資源の費用や運用が消えることではない。

CI/CD の分析機能は、パイプラインの時間や成否を観察するために役立つ。一方、名前空間のメーターは共通予算の消費を示す。片方だけで購買判断を完結させないことが重要だ。何分持っているかだけでなく、どの仕事がその分数を使え、誰が足りなくなる前に判断できるかまでが、実際の調達条件なのである。

資料と適用範囲

本稿は二〇二六年九月三日に確認した GitLab の公開資料に基づく。計量と契約の説明は、コンピュート分、利用枠の適用、追加購入、名前空間を参照した。

運用上の区別には、効率化、ランナー、ホスト型環境、マージリクエスト、安全性、分析機能を用いた。顧客の請求書、非公開の実測値、個別契約は調べていない。利用枠に関する記述は GitLab.com が対象であり、Self-Managed や Dedicated のすべてに同じ商業条件を当てはめるものではない。