GitHubとGitLabの違い｜ActionsとGitLab CIの対応表・料金・セルフホスト比較

GitHubとGitLabは、どちらもGitリポジトリをホスティングし、レビュー・課題管理・CI/CDまでを1つのサービスで扱えるプラットフォームです。機能の一覧はほぼ横並びで、選定を分けるのは料金の刻み方、無料プランの人数制限、自社サーバーに置けるかどうかです。移行や併用の作業量は、CI設定の書き換えに加え、課題・レビュー履歴、権限、シークレット、外部連携をどこまで引き継ぐかで変わります。

本記事は、2026年10月25日時点の両社の料金ページと公式ドキュメントで差が出る点だけを比較します。同じ処理をするCI設定ファイル、キーワードと変数の対応表、ミラーで併用する構成、移行ツールのコマンドに加え、GitHub CopilotとGitLab Duoの課金とオンプレミスでの扱いも並べました。

まとめ：GitHub ActionsとGitLab CI/CDを含む両サービスの違いと選び方

• 料金：有料プランの最安はGitHub Teamが1ユーザー月4ドル、GitLab Premiumが月29ドル（年払い）。10人なら月40ドルと月290ドルで、7倍強の差があります。
• 無料プラン：GitLab.comのFreeは、非公開のトップレベルグループに入れるのが5ユーザーまで。6人以上の非公開チームは有料プランが前提です。GitHubのFreeには同種の人数上限がありません。
• CI/CD：両者とも標準で内蔵しています（GitHub Actions／GitLab CI/CD）。無料で使える実行時間はGitHub Freeが月2,000分、GitLab Freeが月400分です。
• 書き換え：runs-onはtags、stepsはscript、strategy.matrixはparallel:matrixに対応します。GitLab CIからGitHub Actionsへの変換にはGitHub公式のActions Importerがあり、逆方向は手で書き直します。
• 併用：GitLabのリポジトリをFreeのプッシュミラーでGitHubへ複製すれば、GitHub Actionsで動かせます。GitHubのリポジトリをGitLab CI/CDで動かす連携はPremium以上です。
• セルフホスト：GitLabはMITライセンス部分を無償で自社サーバーに置けます。GitHubを自社サーバーに置くには有償のGitHub Enterprise Serverが必要です。
• AI機能：GitHub Copilot Businessは1シート月19ドルで、ライセンスはGitHub Enterprise Server（GHES）上では付与できません。GHES 3.22以降のCopilot CLI閉域網連携は技術プレビューです。GitLab Duo Agent PlatformはGitLab Creditsの従量課金で、Self-Managedでは自前のモデルにつないでオフラインでも動かせます。
• 選び方：OSS公開・外部との協業・小規模で安く始めたいならGitHub。オンプレミス必須、あるいはグループ階層で数百人規模の権限を組みたいならGitLabが合います。

GitとGitHub・GitLabの関係と両サービスの成り立ち・提供形態の整理

Gitは、ローカル環境でファイルの変更履歴を管理するバージョン管理ツールです。GitHubとGitLabは、そのGitリポジトリをサーバーに置き、チームで共有するためのサービスです。Gitだけでもリモートリポジトリは作れますが、プルリクエスト（マージリクエスト）によるレビュー、課題管理、CI/CDといったチーム開発の機能は、GitHubやGitLabの側が提供しています。GitLabでIssue・マージリクエスト・CI/CDを実際に操作する手順はGitLabの使い方：プロジェクト作成からIssue・MR・CI/CDまでの手順で扱っています。リポジトリそのものの仕組みはリポジトリとは？Gitでソースコードを管理する仕組みで解説しています。

GitHubの成り立ちとMicrosoft買収後もOSS協業の中心である理由

GitHubは2008年に公開されたサービスで、2018年にMicrosoftが買収を発表しました。OSSの公開先として最も広く使われており、外部の開発者がforkしてプルリクエストを送る、という協業の流れがサービスの中心にあります。

GitLabの読み方とSaaS・Self-Managed・Dedicatedの3形態

GitLabは「ギットラボ」と読みます。2011年にオープンソースとして開発が始まり、現在はGitLab Inc.が開発しています。毎月新しいマイナー版が出ており、2026年10月25日時点の最新マイナー版は2026年10月15日公開の19.5です（GitLab 19.5のリリースノート）。10月21日にはセキュリティ修正を含む19.5.1も出ています。18.10系から19系への上げ方はGitLab 18.10の新機能とパッチ18.10.8までの修正｜保守終了後の19.4への移行経路にまとめました。提供形態は、GitLab社がホストするGitLab.com（SaaS）、自社サーバーに入れるGitLab Self-Managed、専有環境のGitLab Dedicatedの3つです。

GitHubとGitLabの比較表で見る料金・CI実行時間・セルフホストの差

2026年10月時点のGitHubの料金ページとGitLabの料金ページ、各社ドキュメントの値です。価格はドル建てで、GitLab Premiumは年払いの月額換算です。

料金とFreeプランの制限の違い：人数上限とCI実行時間の刻み方

GitHubのプラン：Free・Team・Enterpriseの価格とActions枠

GitHubのFreeは、公開・非公開ともリポジトリ数が無制限です。プライベートリポジトリで使えるGitHub Actionsの実行時間は月2,000分、GitHub PackagesのストレージはActionsのアーティファクトと共有で500MBです。公開パッケージと公開リポジトリの標準GitHubホステッドランナーは無料で使えます。有料のTeamは1ユーザー月4ドルで、Actionsの枠が月3,000分、Packagesが2GBに増え、保護ブランチやコードオーナーを非公開リポジトリでも使えるようになります。Enterpriseは21ドルからで、Actionsは月50,000分、Packagesは50GBです。2026年10月25日時点の料金ページでは、TeamとEnterpriseの両方の価格に「for the first 12 months *」（最初の12か月）という注記が付いています。2年目以降の単価はページ上で読み取れないため、複数年の予算は契約前の見積もりで確かめてください。

Actionsの分単価や2026年1月の価格改定はGitHub Actionsの料金｜2026年改定後の分単価・無料枠とコスト削減の判断基準に詳しくまとめています。

GitLabのプラン構成：Free・Premium・Ultimateの価格と5人上限

GitLabのPremiumは1ユーザー月29ドル（年払い）です。GitLab.comではトップレベル名前空間ごとに月10,000 compute minutes（CI/CDの実行時間）が含まれ、GitリポジトリとLFSの合計上限は1プロジェクト500GiB。Ultimateは料金ページに価格が載っておらず、個別見積もりです。実行時間は月50,000分で、DASTや依存関係スキャンなどのセキュリティ機能が加わります。

注意が要るのはFreeです。GitLab.com Freeの非公開トップレベル名前空間は5ユーザーまでです。2022年12月28日より前に作られた名前空間にも、2023年6月13日からこの制限が適用されています。上限を超えると名前空間は読み取り専用になり（GitLab Docs：Free tier user and group limits）、リポジトリへのpushやCI/CDの実行ができなくなります。公開グループや個人の名前空間は対象外です。さらに2026年1月27日より後に作られたFreeアカウントは、トップレベルグループを3つまでしか作れません。

10人チームの月額：GitHub Teamは40ドル、Premiumは290ドル

非公開リポジトリで10人が開発する場合、GitHub Teamなら10×4ドルで月40ドル、GitLab Premiumなら10×29ドルで月290ドルです。GitLab Freeは5人の上限に当たるため選べません。GitHub Freeでも10人で非公開開発はできますが、保護ブランチなどレビューの強制ができないため、業務ならTeamを前提に見積もるのが現実的です。

月250ドルの差額は、CI実行枠の差や、承認ルール・エピックなどの機能が自社の運用に合うかで評価します。GitHub Teamにも必須レビュー機能があるため、承認機能の有無だけでは差額を説明できません。CI分数だけで差額は埋まりません。GitHub TeamのActions枠（月3,000分）を7,000分超えても、Linux 2コアの標準ランナー（1分0.006ドル）なら追加は約42ドルです。差額に見合うかは、承認ルールや計画機能を別のツールで買わずに済むかで決まります。

GitHub ActionsとGitLab CI/CDの違いを同じ処理の設定ファイルで比較

「GitLabはCI/CDを統合、GitHubは外部ツール頼み」という比較は、2019年にGitHub Actionsが正式提供される前の話です。現在はどちらもリポジトリ内のYAMLファイルでパイプラインを定義します。違いは、書き方、ランナーの選び方、再利用の仕組みの3点。パイプラインという考え方自体はCI/CDとは：仕組み・パイプライン構成と導入判断の基準で整理しています。

Node.jsのテストを両方で書いた設定ファイルと書き方の癖の比較

Node.jsのテストを、mainブランチへのpushとプルリクエスト／マージリクエストの作成・更新時に実行する設定です。ただし、GitHub例はPRの仮マージ結果を、GitLab例はMRのソースブランチをテストするため、検証対象のコミットは異なります。リポジトリにはpackage.json、整合するpackage-lock.json、testスクリプトを用意します。まずGitHub Actionsの .github/workflows/test.yml です。

name: test
on:
  push:
    branches: [main]
  pull_request:
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npm test

対応するGitLab CI/CDの .gitlab-ci.yml は次のとおりです。ここではDocker executorなど、image指定に対応し、タグなしジョブを受け付けるLinux Runnerを使います。

stages:
  - test

test:
  stage: test
  image: node:24
  cache:
    key:
      files:
        - package-lock.json
    paths:
      - .npm/
  script:
    - npm ci --cache .npm --prefer-offline
    - npm test
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: '$CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH == "main"'

GitHub版はactionlint 1.7.12、GitLab版はGitLab公式のCI設定用JSONスキーマによる静的検査で、いずれもエラー0件でした。これはランナー上でのnpm ciやnpm testの成功を保証するものではありません。actions/checkout はv7.0.1、actions/setup-node はv7.1.0が、2026年10月14日時点の各リポジトリのReleasesで最新です。メジャー番号の指定ではなくコミットSHAで固定したい場合はSHA Pinningとは？GitHub ActionsをコミットSHAで固定する方法を参照してください。

読み比べると、書き方の癖の違いは明らかです。GitHubは on: でイベントを選び、uses: で既製のアクション（チェックアウトやNode.jsの導入）を呼び出します。GitLabはリポジトリのチェックアウトが自動で、image: に指定したコンテナの中で script: のコマンドを順に実行します。実行条件の置き場所は rules: です。GitHub Actions側でビルドから自動テストまでを組む手順はGitHub Actionsでビルド・自動テストを設定する方法で順を追って説明しています。

ランナーの選び方と無料の実行時間：月2,000分と月400分の差

ジョブを実行するマシンは、GitHubではランナー、GitLabではRunnerと呼びます。GitHubは runs-on: ubuntu-latest のようにOSのラベルで選び、GitLabは tags: で登録済みのRunnerを選ぶ方式です。GitHubの標準ホステッドランナーは公開リポジトリなら無料で、非公開ではFreeの月2,000分を超えた利用が分単位の課金対象になります。有効な支払い方法が未登録の場合は、無料枠を使い切ると実行が停止します。GitLab.comのFreeはトップレベル名前空間ごとに月400分なので、コスト係数1のRunnerで、1回につき合計5分のジョブを実行するなら、月80回で使い切る計算です。足りない分は1,000分10ドルで買い足せます。

自前のマシンをランナーとして登録すれば、どちらも実行時間の枠を消費しません。GitHub側の手順はGitHubセルフホストランナーとは？導入手順とhosted版の違いで解説しています。

再利用の仕組み：MarketplaceとCI/CDコンポーネントの違い

GitHubにはGitHub Marketplaceがあり、クラウドへのデプロイや通知などのアクションを1行で呼び出せます。数が多い反面、GitLabの移行ガイドが指摘するとおり、サードパーティ製のアクションは提供元が別で、保守や追加ライセンスの確認が必要なものがあります。ジョブ群を丸ごと共有したいときの手段は、別リポジトリのワークフローを uses: で呼ぶ再利用可能なワークフローです。

GitLabは include で別ファイルの設定を取り込み、入力値を受け取れるCI/CDコンポーネントで設定を部品化します。AIレビューのような外部ツールをGitLabのパイプラインへ組み込む例はGitLabでPR-AgentのAIコードレビューを導入する手順で扱いました。どちらを選ぶ場合も、採用前に必要な連携先の部品があるか、保守状況と対応バージョンまで確認してください。アクションの基本はGitHub Actionsとは？できること・使い方とCI/CD自動化、他のCIサービスとの比較はCI/CDツール比較｜主要11製品の無料枠・料金と選び方を参照してください。

GitHub ActionsとGitLab CI/CDのキーワード・変数の対応表

移行や併用で手を動かすときに必要なのは、機能の比較より「どのキーを何に置き換えるか」です。GitLabの移行ガイド（Migrate from GitHub Actions）とGitHubの移行ガイド（Migrating from GitLab CI/CD）に載っている対応を、作業の順に並べ直しました。

runs-on・steps・uses・if・matrixなど構文キーワードの対応一覧

両社のガイドが示す対応に、GitHubのワークフロー構文とGitLabのCI/CD YAML構文リファレンスで確認したキーを加えた一覧です。

ジョブの順序は、両者で考え方が違う部分です。GitLabは stages の並び順で段階的に実行し、GitHubは何も書かなければジョブを並列に走らせ、順序は needs で明示します。GitLabにも needs があり、ステージを待たずに依存先の完了だけで開始できます。GitHubの if とGitLabの rules は、両社のガイドとも完全には一致しないと注記しているため、条件式は1本ずつ読み替えてください。

secrets・github.shaなど変数とコンテキストを置き換える方法

スクリプトの中で参照する値も名前が変わります。GitHubは ${{ github.sha }} のようなコンテキストで、GitLabは $CI_COMMIT_SHA のような定義済みCI/CD変数で受け取ります。よく使うものの対応は次のとおりです。

github.ref_name はプルリクエストで起動すると 番号/merge の形になり、ブランチ名とは一致しません。GitLabでマージリクエストのブランチ名を取るには CI_MERGE_REQUEST_SOURCE_BRANCH_NAME を使います。秘密情報はGitHubの secrets にあたる専用構文がなく、プロジェクトやグループの設定画面でCI/CD変数を作り、ログへの表示を抑えるマスクと、利用できるブランチやタグを制限する保護を設定する方式です。保護を有効にした変数は、通常の未保護ブランチでは使えず、MRパイプラインでの利用にも条件があります。GitLabの移行ガイドも、秘密情報を .gitlab-ci.yml に直接書かないよう求めています。

matrixをparallel:matrixへ書き換えるNode.js複数版テストの例

Node.jsの22系と24系で同じテストを回す部分例です。次のGitHub Actions例は、先のtest.ymlのjobsブロックを置き換えて使い、nameとonは残してください。GitHub Actionsは strategy.matrix で値の組を宣言し、${{ matrix.node }} で参照します。

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node: [22, 24]
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: ${{ matrix.node }}
          cache: npm
      - run: npm ci
      - run: npm test

GitLab CI/CDでは parallel:matrix の値がジョブのCI/CD変数になります。image はCI/CD変数を受け付けるので、版番号をそのまま埋め込めます。

test:
  stage: test
  image: node:$NODE_VERSION
  parallel:
    matrix:
      - NODE_VERSION: ["22", "24"]
  script:
    - npm ci
    - npm test

GitLabの構文リファレンスでは、1つの parallel:matrix から作れる組み合わせは200個までです。生成されるジョブは test: [22] のように値付きの名前になるため、後続ジョブから特定の組だけを待つときは needs:parallel:matrix で値を指定します。

GitHub ActionsとGitLab CI/CDを併用するミラー連携の構成

全面移行せずに併用する方法もあります。リポジトリをどちらに置き、CIをどちらで回すかで構成と必要なプランが変わります。

GitLabのプッシュミラーでGitHubへ複製しActionsを起動するFree構成

GitLabを正本にしたままGitHub Actionsを使うなら、プッシュミラーでGitHubへ複製し、GitHub側のpushイベントでワークフローを起動します。プッシュミラーはFree・Premium・Ultimateのすべてで利用可能です。GitHub側ではfine-grained personal access tokenを作り、Repository contentsの読み書き権限を付けます。複製先に .github/workflows がある場合はWorkflowsの読み書き権限も必要です。

GitLabの設定画面では、リポジトリURLに https://github.com/GROUP/PROJECT.git の形式、ユーザー名にトークンの所有者、パスワードにトークンを入れます。反映は通常5分以内で、保護ブランチだけをミラーする設定なら1分以内です。1プロジェクトに設定できるプッシュミラーは10個までです。この構成ではマージリクエストがGitHubへ渡らないため、ミラー更新から直接起動するのはpushイベントのワークフローです。GitHub側で別途設定すれば、手動実行や定期実行も利用できます。

GitHubのリポジトリをGitLab CI/CDで動かす外部リポジトリ連携

逆にGitHubを正本にしてGitLab CI/CDで動かすのが、外部リポジトリ向けCI/CD（GitHub連携）です。PremiumとUltimateの機能で、GitLab.com・Self-Managed・Dedicatedのいずれでも使えます。GitHub.comのリポジトリなら、repo と admin:repo_hook スコープのトークンを入れるだけで、GitLabがプロジェクトの作成、プルミラー、GitHub連携、Webhookの作成までを自動で行います。

パイプラインの結果はGitHubのコミットステータスとして返るため、GitHubのプルリクエスト画面からGitLabのCI結果を確認できます。トークンで接続する方法はGitHub.comのリポジトリ限定で、接続するGitHubユーザーにownerロールが必要です。GitHub Enterpriseの場合はリポジトリURLから手動で接続し、Webhookを自分で作ります。なお、GitLabからGitHubへのプッシュミラーはFreeで使えますが、この外部リポジトリ連携とプルミラーはPremium以上が前提です。

用語と組織構造の違い：Pull RequestとMerge Requestの対応

同じ機能でも呼び名が違うため、両方を使う現場では会話がかみ合わないことがあります。主な対応は次のとおりです。

GitLabのグループとサブグループで組織図を権限設計に写す方法

GitLabのプロジェクトは、リポジトリに課題・Merge Request・CI/CDの設定が付いた単位で、GitHubのリポジトリに当たります。グループは複数のプロジェクトとメンバーをまとめる入れ物です。GitHubのOrganizationとの違いは、グループの中にサブグループを入れ子で作れる点です。公式ドキュメントでは最大20階層まで作れるとしたうえで、性能の問題を避けるため5階層以内を推奨しています。

サブグループごとに公開範囲を変えられ、親グループのメンバーとその権限は配下のサブグループすべてに継承されます。上位には全体を見る人、下位にはそのチームだけの人を置く形で、「事業部＞部署＞チーム」のような組織図をそのまま権限設計に写せます。親グループに登録したRunnerを配下のプロジェクトで共有できるのも、大規模組織で効く点です。GitHubではOrganization内のTeamを入れ子にし、親Teamのリポジトリアクセス権限を子Teamへ継承できます。Organization自体の入れ子とは異なります。

セルフホスト（オンプレミス）の違い：無償のGitLab CEと有償のGHES

ソースコードを社外のクラウドに置けない場合は、ここが最大の差です。GitLabのソースコードは、ee/ ディレクトリ（有償機能）などを除く部分がMIT Expatライセンスで公開されており、このCommunity Editionは無償で自社サーバーに導入できます。Enterprise Editionをライセンスなしで入れた場合もFreeの機能だけが有効になり、サブスクリプションを購入してアクティベーションコードを入れればPremiumやUltimateの機能が使えるようになります。

GitHubを自社サーバーやプライベートクラウドに置く手段はGitHub Enterprise Serverで、Enterpriseプランの契約が前提です。無償で使えるオンプレミス版はありません。製品の詳細はGitHub Enterprise Serverとは？オンプレGitHubの要件・料金・サポート期限で解説しています。

GitLabが重いと言われる理由とSelf-Managedに必要なサーバー資源

GitLab Self-Managedを小さなサーバーで動かす場合は、複数のプロセスが使うメモリとCPUの不足が性能低下の原因になります。GitLabはWebアプリ（Puma）、バックグラウンド処理（Sidekiq）、Gitの保存（Gitaly）、PostgreSQL、Redisを1台にまとめて動かします。GitLabのインストール要件は、1台構成の基準を8 vCPU・メモリ16GBとし、メモリが限られる環境では8GBでの稼働にも触れています。同じ要件ページは、スワップを使うと負荷時に性能が大きく落ちるため、できれば無効にするよう求めています。これより小さい構成は、省メモリ環境向けの設定ガイドの範囲です。開発者5人まで・各リポジトリ100MB以下という条件で、RAM 2GBとスワップ1GBから動かす設定が載っていますが、このガイド自身が通常運用でスワップを使う前提と書いています。チームで日常的に使うなら16GBの基準から始めてください。

GitHub Enterprise Serverも軽くはありません。AWSへの導入手順では、試用や10人程度の軽い利用で4 vCPU・メモリ32GB、1,000人までで8 vCPU・48GBを最小構成としています。どちらも、メモリ4GBの小さな仮想マシンで動かす前提で比べると判断を誤ります。サーバーの用意と保守を避けたいなら、GitLab.comかGitHub.comを選び、利用人数に応じた契約料とCI実行費用を見積もります。

軽量なセルフホスト：GitBucketとGitea

もっと軽いセルフホストを探しているなら、JVM上でWARファイル1つから起動するGitBucketや、Go製のGiteaも候補になります。Giteaの場合、CIとして組み込みのGitea Actionsが付属。軽量なセルフホストを選ぶ際は、必要なCI/CDとセキュリティ機能を標準機能・外部連携・運用負担に分けて比較します。GitBucketの構築手順はGitBucketをDockerで構築する手順とJenkins連携の落とし穴にまとめています。

セキュリティ機能の提供範囲の違い：SAST・シークレット検出の無償範囲

GitLabは、SAST（静的解析）・シークレット検出・コンテナスキャンをFreeを含む全プランで提供しています。ただしFreeとPremiumでは、結果はジョブが出力するJSONレポートで確認する形になり、Merge Request上への表示や脆弱性レポートでの一元管理はUltimate限定です。DAST（動的解析）と依存関係スキャンもUltimateでしか使えません。

GitHubは2025年4月1日に、Advanced Securityを2つの製品に分けて販売し始めました。シークレットの漏えい防止を担うGitHub Secret Protectionが1アクティブコミッターあたり月19ドル、コードの脆弱性検出（CodeQLとCopilot Autofix）を担うGitHub Code Securityが月30ドルで、このときからTeamプランでも購入できるようになりました。公開リポジトリではプッシュ保護やコードスキャンを無料で使えます。また、依存関係の脆弱性を知らせるDependabot alertsは非公開リポジトリでも利用できます。

非公開リポジトリでGitLab標準の静的解析やシークレット検出を使いたいならFreeかPremiumが候補です。GitHubでも無料の解析ツールをActionsで実行でき、いずれもCIの実行費用は別に考えます。CodeQLの検出精度やCopilot Autofixによる修正案まで求めるなら、GitHubにCode Securityを追加します。

AI機能の違い：GitHub CopilotとGitLab Duo Agent Platformの課金と設置場所

AI機能の費用は、リポジトリの契約に含まれる利用枠と、別途購入するシート・クレジットに分かれます。Copilotには無料プランもあり、GitLab PremiumとUltimateには期間限定の付属クレジットがあります。比べるべきは機能の数ではなく、課金の単位と、自社サーバーの中で動かせるかの2点です。

GitHub Copilot：シート単価にAIクレジットが付く課金

GitHubのCopilotプラン一覧では、Copilot Businessが付与したシート1つあたり月19ドルで1人月1,900 AIクレジット、Copilot Enterpriseが月39ドルで3,900 AIクレジットです。チャットやエージェントはモデルごとのトークン料金をAIクレジットに換算して消費し、付属分を超えた分は1クレジット0.01ドルで請求されます。コード補完と次の編集候補はクレジットを消費しません。エージェントを多用するチームでは、シート単価だけの見積もりは実額より低く出ます。

同じページには「Copilot is not currently available for GitHub Enterprise Server.」とあります。ただし、これはGHES上でCopilotのライセンスを付与できないという意味で、GHESのコードでCopilotを使えないという意味ではありません。GHES版のCopilotの説明によると、GHESの契約に付くGitHub.com側のエンタープライズアカウントでライセンスを付与すれば、Copilot CLIなどのローカルクライアントから手元のコードに対して使えます。GitHubのクラウドにつながない閉域網向けには、GHES 3.22以降でCopilotライセンス不要のCLI連携が技術プレビューとして用意されています。社内のモデルにつなぐ構成とデータの扱いはGitHub Copilotはオンプレミスで使える？GHES非対応の代替構成とデータの扱い・料金で整理しています。

GitLab Duo Agent Platform：GitLab Creditsの使用量課金とセルフホスト

GitLab側は、エージェントやフローの実行ごとにGitLab Creditsを消費する方式です。GitLab Creditsのドキュメントでは定価が1クレジット1ドルで、PremiumとUltimateには期間限定のプロモーションとして1人月12クレジットと24クレジットが付きます。この付属分は個人に割り当てられ、他のユーザーと共有できず、翌月にも繰り越せません。

オンプレミスで差が出ます。GitLab Duo Self-HostedはPremiumとUltimateのSelf-Managedで使え、自社で動かすAIゲートウェイを経由して、社内やプライベートクラウドに置いたLLMへ要求を送ります。インターネットにつながらないオフラインライセンスの環境では、GitLab Duo Agent Platform Self-Hostedのアドオン契約が前提です。ソースコードもAIへの要求も社外に出せない組織では、GitLab Duo Self-Hostedと、GHES 3.22以降のCopilot CLI閉域網連携を比較します。後者は技術プレビューのため、本番採用では提供段階も判断条件に含めます。機能の一覧とクレジットの消費量はGitLab Duo Agent Platformとは？GA後の機能とGitLab Creditsの実費を解説にまとめました。

GitHubとGitLab間の移行手順とActions Importerの使い分け

リポジトリ本体の移行と、CI設定の移行は別の作業です。リポジトリはどちらの方向でも公式の取り込み機能がありますが、CI設定を自動で変換する公式ツールはGitLab CIからGitHub Actionsへの方向にしかありません。

GitHubからGitLabへ移すとき取り込まれるものと取り込まれないもの

GitLabにはGitHubインポーターがあり、リポジトリ本体、全ブランチ、課題、プルリクエストとそのレビューコメント、ラベル、マイルストーン、Wiki、リリースノート、保護ブランチのルール、Git LFSのオブジェクトなどを取り込めます。公式ドキュメントには、kubernetes／kubernetes（プルリクエスト8万件・課題4万5千件・コメント約150万件）の取り込みに76時間かかったという計測も載っています。

取り込まれないものもあります。インポートはリポジトリ単位で、GitHubのOrganizationそのものは移りません。外部コラボレーター、「マージ前にステータスチェックの成功を必須にする」ルールも対象外です。GitHub ActionsのワークフローファイルはGitリポジトリの一部として移りますが、GitLab CI/CD用には自動変換されないため、先に示した対応表を見ながら .gitlab-ci.yml へ手で書き直す必要があります。コメントや説明文の添付ファイルは既定では取り込まれず、インポート時に追加項目として選ぶ必要があります。ただしGitHub Enterprise Serverからの移行では、GitLab 18.4以降も画像と動画だけが対象です。GitHub側の添付を消すとリンクが切れるので、移行後もしばらく元のリポジトリを残してください。

費用面では、GitLabがGitHubとの比較ページで移行者向けの特典を出しています。3年契約を条件に、GitLab Ultimateの最初の12か月を無料にするというものです。最低人数や残り2年の単価はページに載っていないため、営業見積もりで確かめてから比較に入れてください。

GitLab CIからActionsへ移すActions Importerのコマンド

逆方向は、GitHub公式のGitHub Actions Importerで .gitlab-ci.yml をワークフローへ変換できます。GitLabからの移行手順によると、前提はDockerが動く環境、GitHub CLI、read_api スコープのGitLabトークン、workflow スコープのGitHubトークン（classic）です。GitHub CLIの拡張として入れます。次のauditは組織アカウント向けで、個人アカウントの場合はdry-runから進めてください。名前空間・プロジェクト名・移行先URLは実際の値に置き換えます。

gh extension install github/gh-actions-importer
gh actions-importer configure
gh actions-importer update

# 名前空間全体の変換可否を集計（audit_summary.md が出力される）
gh actions-importer audit gitlab --output-dir tmp/audit --namespace my-gitlab-namespace

# 1プロジェクトを変換してファイルだけ確認（プルリクエストは作らない）
gh actions-importer dry-run gitlab --output-dir tmp/dry-run --namespace my-gitlab-namespace --project my-gitlab-project

# 変換結果をGitHubリポジトリへのプルリクエストとして作成
gh actions-importer migrate gitlab --target-url https://github.com/:owner/:repo --output-dir tmp/migrate --namespace my-gitlab-namespace --project my-gitlab-project

変換できるのは script・before_script・after_script（stepsへ）、tags（runs-onへ）、image（containerへ）、variables（envへ）、needs、スケジュールやpushのトリガーなどです。rules・only・except は if に変換されますが完全には一致せず、environment・parallel・services も部分対応です。マスクした変数の値、シークレット、セルフホストランナーのラベル、アーティファクトレポートは手作業で移します。dry-runの出力を、前の章の対応表と突き合わせてから migrate に進むと手戻りが減ります。

書き換えたワークフローをactでローカル実行して確認する手順

書き換えたワークフローをpushする前に手元で動かすなら、actが使えます。Docker上で .github/workflows のジョブをコンテナとして実行するツールです。

# pull_request イベントで動くワークフローを一覧表示
act -l pull_request

# pull_request イベントとして実行
act pull_request

# ジョブ名を指定して実行
act -j test

ただしactが使うコンテナはGitHubホステッドランナーと同じイメージではないため、actによるローカル実行は予備検証として扱い、最終確認は実際のランナーで行ってください。秘密情報は -s 名前 で対話入力にすると、シェルの履歴に値が残りません。

GitHubとGitLabの選び方：CI/CD・人数・設置場所の3条件で決める基準

GitHubを選ぶべき場面：OSS公開・小規模チーム・Marketplace連携

OSSとして公開し、GitHub上の開発者からプルリクエストを受け付けることを優先するなら、GitHubを第一候補にします。開発者の多くがすでにアカウントを持っており、forkからプルリクエストまでの流れにも慣れているためです。非公開の業務開発でも、5〜20人程度でコストを抑えたいならTeamの月4ドルが効きます。Marketplaceのアクションで外部サービスとの連携を短く書きたい場合もGitHubが向いています。

GitLabを選ぶべき場面：閉域網での開発・大規模組織の権限と監査

ソースコードを自社のサーバーから出せない、あるいは閉域網で開発する必要がある場合は、無償でセルフホストできるGitLabが第一候補です。部署ごとに公開範囲と権限を分けたい大規模組織や、課題管理からCI/CD、セキュリティスキャンまでを1製品で監査したい組織にも合います。AIのコード支援まで閉域網の中で完結させたい場合も、Self-Managedで自前のモデルにつなげるGitLabが候補に残ります。

GitLab.com Freeの人数上限で起きる選定失敗とCIだけ移す判断

「GitLab.comは無料で機能が多い」という理由で、6人以上の非公開チームをFreeで始めるのは避けてください。5人の上限を超えた時点で名前空間が読み取り専用になり、pushもCIも止まります。人数が増える見込みがあるなら、最初からPremiumの費用を見積もるか、GitHubを選ぶ方が手戻りがありません。

CIの実行時間だけが不満なら、リポジトリごと移す必要はありません。GitLabを正本にしたまま、プッシュミラーでGitHubへ複製してActionsで回す構成なら、GitHub Freeの月2,000分の枠を使えます。ただし、掲載したmainへのpush限定の設定では、GitLabのMR作成・更新時のテストを代替できません。マージ前にも検証する場合は、対象ブランチのpushで起動する設定と、GitLab側で結果を確認する運用が必要です。反対に、CI設定が数十本を超え、rules や include を多用しているなら書き換えの工数が先に立つため、移行はいったん見送り、Runnerの設備費・保守費と追加実行時間の購入費を比較して、実行環境を決めます。

移行か併用かの判断、パイプラインの書き換え、ランナーの自前化をまとめて任せたい場合は、一創のDevOps・CI/CD導入支援で、既存の設定ファイルの棚卸しから対応できます。開発と運用のつなぎ方の全体像はDevOpsとは？アジャイル・CI/CDとの違いとDORA 5指標での成果の測り方も参考にしてください。

よくある質問

GitHubとGitLab、GitHub ActionsとGitLab CI/CDについて、比較の際によく出る質問に答えます。

GitLabの読み方は？

「ギットラボ」と読みます。GitHubは「ギットハブ」です。GitLabは2011年にオープンソースとして始まったプロジェクトで、現在はGitLab Inc.が毎月新しい版を出しています。2026年10月25日時点の最新マイナー版は19.5で、最新パッチ版は10月21日公開の19.5.1です。

GitLabでGitHub Actionsのワークフローは動きますか？

そのままでは動きません。GitLabは .gitlab-ci.yml で動くので、runs-on を tags、steps を script に置き換えるなど、ワークフローを書き直す必要があります。GitHubのリポジトリはそのままにしてGitLabのCI/CDだけを使う方法もありますが、Premium以上が必要です。

GitLabが重いのはなぜですか？

Self-Managedでは、WebアプリやGitの保存、データベースなど複数のプロセスを1台で動かすためです。公式の一般的な導入基準は1台構成で8 vCPU・メモリ16GBです。小規模用途には、機能や負荷を制限して8GB未満で動かす公式の省メモリ構成もあります。ただしこの省メモリ構成はスワップを常用する前提で、開発者5人まで・各リポジトリ100MB以下が条件です。基準を下回るサーバーで普通のチームが使うと遅くなります。GitLab.comを使えばサーバー側の資源を気にする必要はありません。

GitHubとGitLabは併用できますか？

はい、併用は可能です。GitLabのプッシュミラーを設定すると、GitLabへのpushが自動でGitHubへ複製され、GitHub側でActionsを動かせます。この方法はFreeでも利用可能です。逆にGitHubのリポジトリをGitLabのCI/CDで動かす外部リポジトリ連携は、PremiumかUltimateで使えます。

個人開発ならどちらが向いていますか？

個人の名前空間はGitLabでも人数制限の対象外なので、どちらでも無料で使えます。CIの無料枠はGitHubの月2,000分の方が大きく、公開リポジトリで標準GitHubホステッドランナーを使う場合、実行時間は無料です。CIを多く回すならGitHubが有利です。

関連記事

• GitHub Actionsとは？できること・使い方とCI/CD自動化
• GitHub Actionsの料金｜2026年改定後の分単価・無料枠とコスト削減の判断基準
• CI/CDツール比較｜主要11製品の無料枠・料金と選び方
• GitHub Enterprise Serverとは？オンプレGitHubの要件・料金・サポート期限とCloudとの違い
• GitLab Duo Agent Platformとは？GA後の機能とGitLab Creditsの実費を解説