GitLab CIとは｜.gitlab-ci.ymlの書き方・料金・GitHub Actionsとの違いと案件動向

GitLab CI/CDとは

GitLab CI/CDとは、GitLab本体に組み込まれているCI/CDの仕組みです。 リポジトリ直下に.gitlab-ci.ymlを置くと、GitLab Runnerと呼ばれる実行エージェントがその内容に従ってビルド・テスト・デプロイを進めます。

独立したサーバーを立てるツールではなく、「GitLabの一機能」として最初から組み込まれている点が大きな違いです。公式のGitLab CI/CDドキュメントでも、ソース管理からデプロイまでを一つのプラットフォームで完結させる考え方が前面に出ています。

GitLab CI/CDの基本定義

ポイントは、ソース管理側がCI/CDを内包していることです。GitHub＋GitHub Actionsに近い発想ですが、GitLabはコンテナレジストリ・パッケージレジストリ・課題管理・Wiki・セキュリティスキャンまで一つの製品に同居させています。

GitLabとGitLab CIの関係

文脈によって用語が揺れやすいので整理しておきます。

• GitLab：DevOpsプラットフォーム全体の製品名

• GitLab CI/CD：GitLabの中でCI/CDを担う機能の正式な呼び名

• GitLab CI：CI/CD機能の通称。厳密には継続的デプロイまで含むためCI/CDが正式

実務では「GitLab CI」と書かれていても、本番デプロイまで含んでいるケースが多くあります。「CI止まり」と思い込んで読むと、範囲を見誤りやすい点に注意してください。

GitLab CI/CDの仕組み

GitLab CI/CDは、パイプライン・ステージ・ジョブ・Runnerの4つで動きます。

パイプライン・ステージ・ジョブの関係

パイプラインは、1回のCI/CD実行全体を指す単位です。パイプラインは複数のステージで構成され、ステージの中に複数のジョブが並びます。

同じステージ内のジョブは並列で実行され、前のステージがすべて成功したら次のステージに進みます。この直列＋並列の組み合わせが基本構造です。

GitLab Runnerが処理を担う

実際にコマンドを動かすのがGitLab Runnerです。Runnerは独立したプロセスで、GitLabからジョブを受け取り、自分のホストやコンテナの中で実行します。

• インスタンスRunner：GitLab.comでは共有Runnerとして提供。利用できる実行時間（compute minutes）はプランで異なる

• グループRunner：特定のグループ配下のプロジェクトで共有するRunner

• プロジェクトRunner：特定のリポジトリだけで使う専用Runner

Self-Managedで使う場合は、社内のVMやKubernetesクラスタに自前のRunnerを並べる構成が一般的です。詳しくはGitLab Runner公式ドキュメントで確認できます。

.gitlab-ci.ymlの基本構造

設定はリポジトリのルートに.gitlab-ci.ymlを置くだけで始まります。中身はおおむね次の要素で構成されます。

• stages：パイプラインで使うステージ名を上から順に並べる

• 各ジョブ：ステージ名・実行するスクリプト・実行イメージ・依存関係を書く

• variables：環境変数の定義

• rules：起動条件（ブランチ・マージリクエスト・タグなど）。古いonly/exceptより、現在はrulesで書くのが基本

• artifacts：後続のジョブやUIに渡すファイル

• cache：依存ライブラリなどの再利用領域

• include：別ファイルやCI/CDコンポーネントの読み込み

細かい書き方は時期によって推奨が変わるため、.gitlab-ci.yml公式リファレンスで最新の仕様を確認しながら書くのが確実です。

ミニFAQ：stageとjobの違いがピンと来ない

Q. stagesとjobs、どちらが上位ですか？

A. パイプライン＞ステージ＞ジョブの順です。stagesは「フェーズの並び順」を決める箱で、その中に並列実行されるジョブを入れる構造です。並び替えると直列・並列の切り分けが大きく変わるため、最初に設計する価値が高い部分です。

2026年時点で押さえたい3つの変化

GitLabは毎月リリースされ、数年前の解説記事の手順がそのまま使えないことがあります。とくに影響が大きい3点をまとめます。

1. 共通設定はCI/CDコンポーネントで再利用する

CI/CDコンポーネントは、再利用できるパイプライン設定の単位です。GitLab 17.0（2024年）で一般提供になり、Free・Premium・Ultimateの全プランで使えます。

従来のincludeによる読み込みと似ていますが、バージョンを指定して呼び出せる点と、CI/CD Catalogで公開・検索できる点が違います。社内でテンプレートを標準化する案件では、include＋extendsよりコンポーネントで設計する場面が増えています。詳細はCI/CDコンポーネントの公式ドキュメントで確認できます。

2. Runnerの登録は認証トークン（glrt-）方式へ

以前は、プロジェクトやグループの「登録トークン」でRunnerを登録するのが一般的でした。現在は、GitLabの画面（またはAPI）でRunnerを作成し、発行されるglrt-で始まる認証トークンで登録する方式が推奨です。

GitLab 17.0以降は、管理者が旧来の登録トークンを無効にでき、無効の状態で旧方式の登録を試すと失敗します。既存のRunnerはそのまま動きますが、新しく登録するときは新方式で手順を組みます。

3. 公式ドキュメントのURLが変わった

GitLabの公式ドキュメントは、URLから「/ee/」が外れた形に移っています（例：docs.gitlab.com/ci/）。古いURLは転送されますが、社内手順書やWikiのリンクを更新するときは新しいURLに置き換えておくと安心です。

GitLab CI/CDの主要機能と特徴

採用を判断するうえで知っておきたい主要機能を整理します。

Auto DevOps

Auto DevOpsは、.gitlab-ci.ymlを書かなくても、よく使うパイプラインを自動で組み立てる仕組みです。ビルド・テスト・SAST（静的アプリケーションセキュリティテスト）・Kubernetesへのデプロイなどを、テンプレートに沿って動かせます。

「とりあえずCI/CDを通したい」段階では便利ですが、本番運用ではカスタマイズが必要になることが多いです。実務ではAuto DevOps公式ドキュメントを読みつつ、必要な部分だけ自前のジョブで上書きする使い方が見られます。

Review Apps（動的環境）

マージリクエストごとに一時的なレビュー環境を自動で作る機能です。レビュー時に「実物を触って確認したい」という要望に応えやすく、QAやデザイナーとの確認の往復を減らせます。マージリクエストが閉じられると環境は自動で破棄されます。

needsによるDAGパイプライン

通常のパイプラインはステージ単位で進みますが、needsキーワードを使うとジョブ同士に直接の依存関係を引けます。「build-imageが終わったら、テストを待たずにステージング環境へのデプロイを先に流す」といった最適化ができ、ビルドが長いプロジェクトで効きます。

マルチプロジェクトパイプライン

複数のリポジトリにまたがるパイプラインをつなげる仕組みです。共通設定のコンポーネント化と組み合わせると、モノレポでない構成でも一貫したCI/CDを提供できます。

Container Registry／Package Registry

コンテナイメージや、npm・Maven・PyPIなどのパッケージを置けるレジストリが標準で付いています。CI/CDで作った成果物を外部に頼らずGitLab内に置けるため、社内ネットワークで完結する構成と相性が良いです。

環境（Environments）とデプロイ承認

staging・productionといった環境ごとにデプロイ履歴を追えます。本番デプロイには手動承認（when: manual）や保護環境を組み合わせ、誰がいつ何をデプロイしたかを画面で確認できるようにするのが定番の運用です。

GitLab.comの料金とCI実行時間

GitLab.comでは、共有Runnerを使える時間（compute minutes）がプランごとに決まっています。2026年10月時点のGitLab Pricing公式ページの表示は次のとおりです。

Freeプランは、非公開のトップレベルグループあたり5ユーザーまでという制限があります。実行時間が足りないときは、1,000分あたり$10で追加購入するか、自前のRunnerを登録して共有Runnerの分数を使わない構成にします。料金やAI機能（GitLab Duo）の扱いは改定されやすいため、契約前に公式ページで確認してください。

GitLab CI/CDとGitHub Actionsの違い

CI/CDの選定でよく比べられるのが、GitLab CI/CDとGitHub Actionsです。どちらもソース管理と一体の設計ですが、強みと前提が違います。

結論：3つの軸で性格が分かれる

「プラットフォームの広さ」と「オンプレ運用への寄り添い」がGitLab、「外部エコシステムの厚さ」がGitHub Actions、と整理するとイメージしやすくなります。

GitLab CI/CDが向くケース

• 社内のDevOps基盤をSelf-Managedで完結させたい（金融・公共・大企業など）

• ソース管理・CI/CD・コンテナレジストリ・課題管理を一つの製品でそろえたい

• マージリクエストごとのReview AppsでQAを回したい

• セキュリティスキャンやコンプライアンス管理を標準機能で押さえたい

GitHub Actionsが向くケース

• ソースコードをGitHubで管理している

• Marketplaceのアクションを組み合わせて手早くワークフローを組みたい

• OSSを公開し、外部のコントリビューターを巻き込みたい

• GitHubのIssue／Projectsを使った運用が回っている

詳しい比較はGitHub Actionsとは？CI/CDの仕組み・基本ワークフロー・案件単価をフリーランス視点で解説も参照してください。

ミニFAQ：結局どちらを選ぶべきか

Q. 新規プロジェクトならどちらが安全な選択ですか？

A. すでにGitHubでソース管理しているならGitHub Actions、社内でGitLabが標準ならGitLab CI/CDが素直な選択です。「ソース管理のプラットフォームに合わせる」のが、運用コストが最も小さくなりやすい選び方です。

GitLab CI/CDとJenkinsの違い

レガシー環境も含めて比べられることが多いのがJenkinsです。

JenkinsはCI/CDだけを独立して担う前提で作られ、GitLab CI/CDはGitLabのDevOps体験の一部として位置づけられています。詳しくはJenkinsとは？CI/CDの仕組み・GitHub Actionsとの違い・案件動向をフリーランス視点で解説も参考にしてください。

Jenkinsからの移行ニーズ

社内のソース管理がGitLabに統一されたタイミングで、「CI/CDもGitLabに寄せる」判断が走るケースがあります。移行では、Jenkinsfileの既存ジョブを.gitlab-ci.ymlとコンポーネントに置き換えます。プラグインに依存した処理は、Runnerのイメージに組み込むかDocker化で再現する設計判断が問われます。

GitLab CI/CDと他のCI/CDツールの比較

「ソース管理とCI/CDをそろえるか、切り離すか」が選定の入口です。GitLabならGitLab CI/CD、GitHubならActions、ソース管理に依存させたくないならJenkinsやCircleCI、というのが自然な分かれ方です。

GitLab CI/CDの導入と基本的な使い方

触り始めるときの最小構成を押さえておきます。

GitLab.comかSelf-Managedか

GitLab Runnerの登録（2026年時点の手順）

最初につまずきやすいのがRunnerの登録です。現在推奨されている流れは次のとおりです。

1. GitLabの画面（プロジェクト・グループ・インスタンスのRunner設定）で新しいRunnerを作成し、タグや実行条件を決める

2. 発行されたglrt-で始まる認証トークンを控える

3. 任意のホスト（VM・コンテナ・Kubernetes）にGitLab Runnerをインストールする

4. 認証トークンを使ってRunnerを登録し、executor（shell／docker／kubernetesなど）を選ぶ

executorをdockerやkubernetesにそろえると、ジョブごとに独立した実行環境を確保でき、依存関係の衝突を抑えられます。

.gitlab-ci.ymlの最小構成（イメージ）

実際の.gitlab-ci.ymlは、次のような構造で書きます。

• stagesでbuild・test・deployといったフェーズを上から並べる

• 各ジョブ名の下に、stage・script・imageなどを書く

• artifactsやcacheで後続ジョブとデータを受け渡す

• rulesで「mainブランチへのpush時だけdeployを実行」などの条件を書く

ステージごとの役割をはっきり分けて書くのがポイントです。後からRunner構成を変えても影響を局所化しやすく、ログも読みやすくなります。

最初に押さえたい運用ポイント

• シークレットはCI/CD Variablesで管理し、YAMLに直書きしない

• 共通設定はCI/CDコンポーネントかinclude＋extendsで切り出し、同じジョブ定義をコピーしない

• Runnerはdocker／kubernetesにそろえ、本番でshell executorは避ける

• Auto DevOpsは中身を読んでから採用を判断する

ミニFAQ：まず触ってみるならどこから？

Q. 学習用に最小限の環境を作るならどうすればよいですか？

A. GitLab.comで個人アカウントを作り、小さなリポジトリに.gitlab-ci.ymlを1枚置くのが最短です。共有Runnerでそのままパイプラインが動きます。慣れたら手元でgitlab-runnerを動かして自前のRunnerを登録すると、Self-Managed運用の感触がつかめます。

フリーランス案件におけるGitLab CI/CDの位置づけ

ここからは、フリコンの掲載データをもとに、GitLab CI/CD周辺の案件動向をまとめます。

フリコン掲載データで見る出現頻度

フリコンで募集中の案件23,010件（2026年10月9日時点）について、一覧に表示される案件名と概要文を照合しました。詳細ページの全文は対象外のため、実際に使われている件数より少なく出る点に注意してください。

ツール名が一覧に出てくる案件は、どれも全体の0.1%未満でした。GitLabは単独で募集されるより、インフラ構築やKubernetes基盤の案件の中で、要件の一つとして書かれることが多いと読めます。17件には「閉域環境でのGitLab CI/CD基盤構築」「通信会社向けのKubernetes／GitLab基盤構築」「生命保険の販売支援システムの構築」などがあり、後述する閉域・通信・金融の傾向と重なります。

17件の募集単価の上限の平均は68.5万円で、募集中の全案件（76.1万円）より低めでした。件数が少ないため参考値ですが、「GitLabが使えること」自体が単価を押し上げるわけではなく、次に見るように基盤側をどこまで担うかが単価を分けていると考えられます。

単価帯の傾向（隣接スキルのタグ別集計）

GitLab単体の集計区分はないため、CI/CDとセットで求められることが多い技術のタグで単価帯を比べました。フリコンに掲載中で募集中の案件（2026年10月9日時点）を、募集単価の上限で集計した参考値です。案件の職種構成がタグごとに違うため、単価の差はスキルの優劣を直接示すものではありません。掲載単価であって成約単価でもありません。

Kubernetesのタグが付いた案件は、上限100万円以上の割合がDockerやJenkinsの約2倍でした。CI/CDの設定だけでなく、コンテナ基盤へのデプロイ設計や運用まで担う案件が多いことが背景にあると考えられます。

作業範囲ごとの目安は次のように整理できます。

• .gitlab-ci.ymlの修正・ジョブ追加が中心：設計判断を求められにくく、相対的に低めの水準にとどまりやすい

• Docker／Kubernetesと組み合わせた運用設計：Runner構成・レジストリ運用・デプロイ設計まで担える人が対象で、中位〜上位の幅で募集されることがある

• Self-Managed GitLab全体の運用設計・CI/CD標準化のリード：複数プロジェクト横断のコンポーネント整備や権限・セキュリティ設計まで担える人が対象で、上位帯で募集されることがある

自分のスキルがどの単価帯に当たるかは、無料のフリーランスエンジニア単価診断で目安を確認できます。単価を上げる考え方は『フリーランスエンジニアの単価相場と単価の上げ方』で整理しています。案件はKubernetesの案件一覧やDockerの案件一覧から探せます。

どんな業界・案件で使われやすいか

今回確認した掲載案件や公開情報を見る限り、Self-Managed GitLabは次のような現場で使われることが多い傾向です。

• 金融（銀行・証券・保険）の社内ソース管理＋CI/CD基盤

• 公共・自治体・公的研究機関のシステム

• 通信キャリア・大手メーカーの内製DevOps基盤

• 大規模Webサービス事業者の社内開発基盤（Self-Managed GitLab）

• セキュリティ要件の厳しい医療・製薬関連のプロジェクト

案件の説明に「Self-Managed GitLab」「閉域」「Kubernetes」「GitLab Runner運用」といった言葉が見えたら、GitLab CI/CDの比重が大きい案件と考えてよいでしょう。

ミニFAQ：GitLab CI/CDだけの経験は転用が利く？

Q. GitLab CI/CDだけ触ってきた経験は他社で評価されますか？

A. 評価されるのは「GitLab CI/CDそのもの」より「CI/CD全体の設計・運用経験」です。マルチステージのパイプラインを設計してKubernetesにデプロイできていれば、GitHub ActionsやJenkinsへの転用もしやすい性質があります。

GitLab CI/CDエンジニアに求められるスキル

.gitlab-ci.ymlの書き方だけでは弱いのが実情です。周辺スキルとの組み合わせを意識して棚卸しすると、応募できる案件の幅が変わります。

必須レベルのスキル

• Linux：シェル操作・systemd・基本的なネットワーク（Linuxとは？仕組み・主要ディストリビューション・案件単価をフリーランスエンジニア視点で解説）

• Git：ブランチ戦略・マージリクエスト運用・タグ運用

• YAML：includeやextends、コンポーネントのinputsを使った構造化が読めること

• Docker：イメージのビルド・タグ運用・Container Registryとの連携（Dockerとは？コンテナ技術の仕組み・できること・フリーランス案件の単価への影響を解説）

単価帯を押し上げやすい組み合わせ

• Kubernetes：Runnerの運用とデプロイ先の両面で使う（Kubernetesとは？仕組み・Dockerとの違い・フリーランス案件の単価をエンジニア視点で解説）

• IaC：インフラごとコードで管理する（Terraformとは？IaCの仕組み・できること・フリーランス案件の単価をエンジニア視点で解説）

• クラウド：AWS・Google Cloud・Azureとの統合（クラウドエンジニアとは？仕事内容や必要なスキル、年収について解説）

• テスト自動化：ユニット・結合・E2Eテストを並列でジョブに組み込む設計

• SRE／DevOpsの実務経験：SREとは？・DevOpsエンジニアとは？

マネジメント・周辺領域のスキル

• 既存ジョブ資産の棚卸し（プロジェクト横断のCI/CD依存関係を描けること）

• 資格情報の管理・SAST／DAST・コンプライアンスなどのセキュリティ要件

• リリースフローや運用ドキュメントの整備、引き継ぎ資料の作成

「パイプラインが通る」だけでなく「運用が止まらず、引き継げる状態で残せる」ことが、フリーランスとしての評価につながりやすい領域です。インフラ全体の文脈はインフラエンジニアとは？仕事内容や年収、将来性について解説も参考になります。

GitLab CI/CDを学ぶロードマップ

次の順番で進めると詰まりにくくなります。

1. CI/CDの概念を整理する：CI（継続的インテグレーション）とCD（継続的デリバリー／デプロイ）の違いを言葉にする。今のリリース手順を1本書き出し、どこを自動化すると効くかを説明できるようにする

2. GitLab.comで素のパイプラインを動かす：個人アカウントの小さなリポジトリに.gitlab-ci.ymlを1枚置き、共有Runnerで動かす

3. stagesと依存関係を設計する：build・test・deployの複数ステージを書き、artifactsで成果物を渡す。needsでDAGを引いてみる

4. 自前のRunnerを登録する：手元にgitlab-runnerを入れ、認証トークン方式で登録してdocker executorで動かす

5. KubernetesとContainer Registryに広げる：レジストリにイメージをpushしてKubernetesにデプロイし、Review Apps・Environments・手動承認まで通す

6. コンポーネントで共通化する：共通処理をCI/CDコンポーネントに切り出し、バージョンを付けて複数プロジェクトから呼び出す

7. 移行案件を意識する：JenkinsfileやGitHub Actionsの記法も読めるようにしておくと、移行支援案件で選べる幅が広がる

公式ドキュメント・参考リンク

• GitLab CI/CD公式ドキュメント

• .gitlab-ci.yml構文リファレンス

• CI/CDコンポーネント

• GitLab Runner公式ドキュメント

• Auto DevOps公式ドキュメント

• GitLab Pricing公式ページ

GitLab CI/CD運用でよくある失敗と対策

現場で繰り返し見られる失敗を押さえておくと、参画初日から信頼を得やすくなります。

失敗1：stagesの設計を後回しにする

最初のジョブが動いた勢いで増築していくと、並列にしたいのに直列で詰まる状態に陥ります。運用に乗せる前に「build／test／deploy」などの骨格を決め、ジョブを足すときはどのステージに入るかを必ず意識します。

失敗2：共有Runnerだけに頼る

GitLab.comの共有Runnerだけに頼ると、無料プランの月400分をすぐ使い切ったり、機密情報を扱う案件の要件に合わなくなったりします。要件に応じて自前のRunnerを並べ、executorをdockerやkubernetesにそろえる構成が現実的です。

失敗3：機密情報をYAMLに直書きする

APIキーやDB接続情報を.gitlab-ci.ymlに書くと、リポジトリにそのまま残ります。CI/CD Variablesに登録して変数で参照します。プロジェクト・グループ・インスタンスの単位で管理できるので、社内のルールに合わせて設計します。

失敗4：.gitlab-ci.ymlが肥大化する

1ファイルが1,000行を超えるような状態になると、変更の影響範囲が読めなくなります。

• 共通処理はCI/CDコンポーネントに切り出し、バージョンを付けて呼び出す

• extends（または!referenceタグ）で共通ジョブを継承する

• プロジェクト横断の標準は、専用リポジトリのコンポーネントとしてCatalogに公開する

社内のCI/CD標準化は、「.gitlab-ci.ymlを薄く保つ仕組みづくり」が肝になります。

失敗5：古い手順書のままRunnerを登録しようとする

旧来の登録トークンを前提にした社内手順書のまま進めると、管理者が旧方式を無効にしている環境では登録が失敗します。手順書は認証トークン方式に更新しておきます。

失敗6：移行プロジェクトでJenkinsを一気に止める

Jenkinsfileの全機能を一気に書き直すと、ビルドの成功率が一時的に下がるリスクがあります。並走期間を設けてジョブ単位で切り替え、最後にJenkinsを止める段階的な移行を設計に組み込みます。

まとめ

GitLab CI/CDは、GitLabに同梱されたCI/CD機能で、.gitlab-ci.yml一枚でビルド・テスト・デプロイを通せる仕組みと、DevOpsプラットフォーム全体との統合が特徴です。フリーランスとしては、Kubernetesへのデプロイ設計やSelf-Managed運用まで担えるかどうかで、狙える単価帯が変わります。

• GitLab CI/CDはGitLab同梱の一体型CI/CD。GitLab.com／Self-Managedの両方で使え、閉域の要件に強い

• 基本構造はパイプライン＞ステージ＞ジョブを、Runnerが実行する形。stagesの設計が最初の山場

• GitLab.comの無料プランはCI実行時間が月400分。足りなければ自前のRunnerを並べる

• 2026年時点では、共通化はCI/CDコンポーネント、Runnerの登録は認証トークン方式が標準

• GitHub Actionsとは「統合度・提供形態・設定のスタイル」、Jenkinsとは「配布形態・設定言語」で性格が違う

• フリコン掲載データでは、Kubernetesタグの案件は上限100万円以上が22.5%で、DockerやJenkinsの約2倍

まずはGitLab.comの個人アカウントで小さなリポジトリを作り、build・test・deployの3ステージを持つ.gitlab-ci.ymlを1本動かしてみてください。手元で動かせる状態を作ると、案件選びの判断軸がはっきりします。CI/CD周辺のキャリアは、GitHub Actionsとは・Jenkinsとは・Kubernetesとは・DevOpsエンジニアとはもあわせて確認すると立体的に見えてきます。

参照元・一次情報リンク

• GitLab CI/CD公式ドキュメント

• .gitlab-ci.yml構文リファレンス

• CI/CDコンポーネント

• GitLab Runner公式ドキュメント

• Auto DevOps公式ドキュメント

• GitLab Pricing公式ページ