公開更新 GitHub

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

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

GitHubとGitLabは、どちらもGitリポジトリをホスティングし、レビュー・課題管理・CI/CDまでを1つのサービスで扱えるプラットフォームです。機能の一覧を並べるとほぼ横並びに見えますが、選定を分けるのは料金の刻み方、無料プランの人数制限、自社サーバーに置けるかどうか、の3点です。CI/CDでは、GitHub ActionsとGitLab CI/CDの書き方の差が、移行や併用のときの作業量を左右します。

本記事では、2026年10月時点の両社の料金ページと公式ドキュメントをもとに、実際に差が出る点だけを比較します。GitHub ActionsとGitLab CI/CDは、同じ処理をする設定ファイルを並べ、キーワードと変数の対応表、両者を併用する構成、移行ツールのコマンドまで示しました。

まとめ：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が必要です。
  • 選び方：OSS公開・外部との協業・小規模で安く始めたいならGitHub。オンプレミス必須、あるいはグループ階層で数百人規模の権限を組みたいならGitLabが合います。

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

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

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

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

GitLabの読み方と19.4系時点のSaaS・Self-Managedなど3形態

GitLabは「ギットラボ」と読みます。2011年にオープンソースとして開発が始まり、現在はGitLab Inc.が開発しています。毎月リリースが出ており、2026年10月14日時点で公開済みの最新は19.4系です（GitLabのリリースノートでは19.5が公開予定として載っています）。18.10系から19.4系への上げ方はGitLab 18.10の新機能と保守終了後の19.4への移行経路にまとめました。提供形態は、GitLab社がホストするGitLab.com（SaaS）、自社サーバーに入れるGitLab Self-Managed、専有環境のGitLab Dedicatedの3つです。

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

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

項目 GitHub GitLab
有料プランの最安 Team 4ドル/ユーザー/月 Premium 29ドル/ユーザー/月
上位プラン Enterprise 21ドル〜 Ultimate（個別見積もり）
Freeの人数制限 なし 非公開トップレベルで5人
Freeの CI 実行時間 2,000分/月 400分/月
Freeの保存枠（対象別） Packages：500MB Git＋LFS：10GiB/プロジェクト
CI の設定ファイル .github/workflows/*.yml .gitlab-ci.yml
レビュー単位の呼び名 Pull Request Merge Request
組織の階層 Organization＋Team Group＋Subgroup
無償のセルフホスト なし あり（MIT部分）

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

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

GitHubのFreeは、公開・非公開ともリポジトリ数が無制限です。プライベートリポジトリで使えるGitHub Actionsの実行時間は月2,000分、GitHub Packagesのストレージは500MBで、公開パッケージと公開リポジトリの標準GitHubホステッドランナーは無料で使えます。有料のTeamは1ユーザー月4ドルで、Actionsの枠が月3,000分、Packagesが2GBに増え、保護ブランチやコードオーナーを非公開リポジトリでも使えるようになります。Enterpriseは21ドルからで、Actionsは月50,000分、Packagesは50GBです。2026年10月時点の料金ページには「最初の12か月」と添えた価格表記も並んでいるため、複数年の予算を組むときは契約前に見積もりで単価を確かめてください。

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を前提に見積もるのが現実的です。

GitLab Premiumの価格には、月10,000分のCI実行時間、Merge Requestの承認ルール、エピックなどの計画機能が含まれます。この差額をCI分数と計画機能で回収できるかが判断の分かれ目です。GitHubではActionsの無料枠を超える利用に追加料金がかかります。計画管理は標準のIssuesやProjectsでも行えるため、外部ツール代はそれらで要件を満たせない場合に見積もります。

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

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

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

Node.jsのテストを、mainブランチへのpushとプルリクエスト／マージリクエストの作成・更新時に実行する設定です。リポジトリには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構文リファレンスで確認したキーを加えた一覧です。

役割 GitHub Actions GitLab CI/CD
起動条件 on rules / workflow:rules
実行マシンの選択 runs-on tags
実行するコマンド steps / run script
既製部品の呼び出し uses include / component
実行コンテナ container image
追加のコンテナ services services
環境変数 env variables
実行条件の分岐 if rules:if
組み合わせ実行 strategy.matrix parallel:matrix
ジョブの順序 needs stages / needs
成果物の保存 upload-artifact artifacts
依存のキャッシュ actions/cache cache
手動実行 workflow_dispatch when: manual
定期実行 on.schedule パイプラインスケジュール

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

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

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

用途 GitHub Actions GitLab CI/CD
コミットのSHA github.sha CI_COMMIT_SHA
ブランチ名 github.ref_name CI_COMMIT_BRANCH
起動したイベント github.event_name CI_PIPELINE_SOURCE
作業ディレクトリ github.workspace CI_PROJECT_DIR
実行の識別子 github.run_id CI_PIPELINE_ID
秘密情報 secrets.名前 マスクしたCI/CD変数

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

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

Node.jsの22系と24系で同じテストを回す例です。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へ渡らないため、GitHub Actionsで動くのはpushを起点にしたワークフローに限られます。

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の対応

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

機能 GitHub GitLab
変更の取り込み依頼 Pull Request Merge Request
リポジトリの単位 Repository Project
組織の単位 Organization Group
コード断片の共有 Gist Snippet
CIの設定 Workflow Pipeline

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の機能・価格で解説しています。

もっと軽いセルフホストを探しているなら、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は組織向けのBusinessが1シート月19ドル、GitLabのGitLab Duo Agent Platformは使った分だけGitLab Creditsを消費する課金（1クレジット1ドル）です。GitLab側の料金体系は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のワークフローも移らないので、先に示した対応表を見ながら .gitlab-ci.yml へ手で書き直す必要があります。コメントや説明文の添付ファイルは既定では取り込まれず、インポート時に追加項目として選ぶ必要があります。ただしGitHub Enterprise Serverからの移行では、GitLab 18.4以降も画像と動画だけが対象です。GitHub側の添付を消すとリンクが切れるので、移行後もしばらく元のリポジトリを残してください。

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

逆方向は、GitHub公式のGitHub Actions Importerで .gitlab-ci.yml をワークフローへ変換できます。GitLabからの移行手順によると、前提はDockerが動く環境、GitHub CLI、read_api スコープのGitLabトークン、workflow スコープのGitHubトークン（classic）です。GitHub CLIの拡張として入れ、監査から順に進めます。

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製品で監査したい組織にも合います。

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

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

CIの実行時間だけが不満なら、リポジトリごと移す必要はありません。GitLabを正本にしたまま、プッシュミラーでGitHubへ複製してActionsで回す構成なら、Freeのまま月2,000分の枠を使えます。反対に、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月14日時点で公開済みの最新は19.4系です。

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

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

GitLab CIの設定をGitHub Actionsへ自動で変換できますか？

はい、変換は可能です。GitHub公式のGitHub Actions Importerを使うと、.gitlab-ci.yml をワークフローに変換し、プルリクエストとして作成できます。ただし rules の条件式や parallel は部分対応で、シークレットやマスクした変数の値は手作業で移します。まず dry-run で出力を確認してください。

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

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

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

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

関連記事

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

ほか 12 件の記事からもリンクされています。

この記事に関連するサービス

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.10.15　テックブログ リゾートトラスト不正アクセス：会員2.6万件・カハラ横浜3.6万件の対象確認と窓口
  2. 2026.10.16　テックブログ ソースネクスト不正アクセスで最大2,252万件流出｜ログインできない理由・パスワード再設定と会員APIの点検
  3. 2026.10.16　テックブログ バーガーキング不正アクセスで約1,118万件の情報漏洩｜対象確認・案内メールの真偽と運営側のログ点検
  4. 2026.10.15　テックブログ 銀のさら不正アクセス：最大650万件の対象確認と窓口、パスワード変更の手順
  5. 2026.10.16　テックブログ ワラウ不正アクセスで連携トークン流出｜Yahoo! JAPAN ID再連携と対象確認

RELATED POSTS 関連記事

一覧へ戻る

目次