Jenkinsからの移行は、Jenkinsfileの文法をYAMLに置き換えるだけでは終わりません。手間がかかるのは、プラグインが裏で担っていた通知や承認、認証情報の受け渡し、共有ライブラリにまとめた処理を移行先の仕組みで組み直す部分です。この記事では、脱Jenkinsを進める実装者向けに、GitHub Actions Importerでの棚卸しから、GitHub ActionsとGitLab CIへの書き換え例、自動変換で落ちる箇所の直し方、並行稼働と切り替えの手順までを順に説明します。Jenkinsそのものの仕組みはJenkinsとは？料金・無料の範囲とインストールから使い方までで扱っています。
まとめ：Jenkins移行は棚卸し・書き換え・並行稼働の3段で進める
最初にやるのは、全ジョブの棚卸しです。GitHub Actionsへ移すなら、公式のGitHub Actions Importerのauditで変換できる割合と手で直す箇所を数え、工数の見積もりをそこから出します。移行先はリポジトリの置き場所で決まります。GitHubにあればGitHub Actions、GitLabにあればGitLab CIで、ツールの機能差で迷う場面は多くありません。
書き換えで詰まるのは、post・input・credentials・共有ライブラリ・stashの5つです。特にinputによる承認は、GitHubのFree・Pro・Teamではプライベートリポジトリで同じ形を作れません。社内の専用機に依存するジョブは、Jenkinsに残す選択肢も含めて先に扱いを決めます。
脱Jenkinsの前に棚卸しするジョブ・プラグイン・認証情報の範囲
見積もりがずれる原因の多くは、Jenkinsfileに書かれていない処理です。画面で設定したFreestyleジョブや認証情報、エージェントに直接入れたツールは、リポジトリを見ても出てきません。
移行工数を決めるのはJenkinsfileより共有ライブラリとプラグインの数
宣言的パイプラインのstagesやstepsは、移行先のYAMLにほぼ1対1で写せます。工数を押し上げるのは次の4つです。上から順に重く、1つ目と2つ目で見積もりの大半が決まります。
- 共有ライブラリ（
@Libraryで読み込むGroovyの関数群）：Extending with Shared Librariesの仕組みは移行先に無く、処理を分解して作り直す - プラグイン固有のステップ（
slackSendや各種デプロイ用ステップなど）：移行先のアクションやコマンドで置き換える - Scripted Pipeline（
node { }で始まるGroovyスクリプト）：条件分岐やループをYAMLで表せる形に書き直す - エージェントに入れたツールと社内ネットワークへの到達性：ランナーのイメージか、セルフホストランナーで用意する
GitLabのMigrate from Jenkinsも、移行計画の段階で使用中のプラグイン、エージェントに入っているもの、共有ライブラリの有無、認証方式を確かめるよう求めています。この4点を一覧にした表を、移行作業の台帳にします。
GitHub Actions Importerのauditによる全ジョブの変換可否調査
GitHubへ移す場合は、GitHub Actions Importer を使用した Jenkins からの移行の手順で棚卸しを自動化できます。前提はGitHub CLIとDockerが動く環境、Jenkinsの個人APIトークン、workflowスコープ付きのGitHub個人アクセストークン（classic）です。Importerを動かす端末は、Jenkinsサーバーと別のマシンで構いません。
# GitHub CLI 拡張を入れ、変換エンジン（コンテナイメージ）を取得する
gh extension install github/gh-actions-importer
gh actions-importer update
# Jenkins の URL・ユーザー名・APIトークンと GitHub のトークンを対話形式で登録する
gh actions-importer configure
# 全ジョブを変換してみて、変換できた割合と手で直す箇所をレポートにする
gh actions-importer audit jenkins --output-dir tmp/audit
# 過去の実行履歴から、移行後に必要なランナーの実行時間と同時実行数を見積もる
gh actions-importer forecast jenkins --output-dir tmp/forecastauditは全プロジェクトの変換を試み、パイプラインごとの成否と未対応の項目をまとめます。この結果で、自動変換に任せるジョブと手で書くジョブを仕分けます。なお、gh-actions-importerのCLI拡張は、2026年11月13日時点でGitHub上の最新リリースが2023年10月公開のv1.3.6です。変換の本体はコンテナイメージとして配布され、updateで取得し直す形になっています。
Jenkinsfileの移行先別キーワード対応表とビルドの書き換え例
宣言的パイプラインの主なディレクティブは、どちらの移行先にも対応するキーワードがあります。移行先はGitHub ActionsとGitLab CIです。先にagent・stages・when・environmentなど主要ディレクティブ9項目の対応表で全体を押さえ、同じJenkinsfileをGitHub ActionsのワークフローとGitLab CIの.gitlab-ci.ymlへ書き換えた例で差を確かめます。
Jenkinsの主要ディレクティブ9項目と移行先別キーワードの対応表
GitHub側はJenkins から GitHub Actions への移行、GitLab側は前出のMigrate from Jenkinsの対応表をもとに整理しました。
| Jenkins | GitHub Actions | GitLab CI |
|---|---|---|
| agent | runs-on・container | image・runnerのtags |
| stages・stage | jobs・jobs.<job_id> | stages・ジョブのstage |
| steps | steps（run・uses） | script |
| environment | env | variables |
| when | if | rules |
| triggers（cron） | on.schedule | パイプラインスケジュール |
| options（timeout） | timeout-minutes | timeout |
| post | if: failure() など | after_script等（失敗時条件） |
| input | environmentの承認 | when: manual |
下3行は文法の置き換えでは済まず、次の章で組み直し方を扱います。GitLab CIのスケジュールはYAMLでなくプロジェクトの画面で設定するため、書き換えで漏れやすい箇所です。
MavenビルドのGitHub Actionsへの移行例と承認・通知の設定
次のJenkinsfileを例にします。ビルドして成果物を受け渡し、mainブランチのときだけ承認を待ってデプロイし、失敗したらSlackへ通知する、よくある構成です。
pipeline {
agent { label 'linux' }
options { timeout(time: 30, unit: 'MINUTES') }
environment { MAVEN_OPTS = '-Xmx1g' }
triggers { cron('H 2 * * 1-5') }
stages {
stage('Build') {
steps {
sh 'mvn -B package'
stash name: 'jar', includes: 'target/*.jar'
}
}
stage('Deploy') {
when { branch 'main' }
input { message 'Deploy to production?' }
steps {
unstash 'jar'
withCredentials([string(credentialsId: 'deploy-token', variable: 'TOKEN')]) {
sh './deploy.sh'
}
}
}
}
post {
failure { slackSend channel: '#ci', message: "Failed: ${env.JOB_NAME}" }
}
}GitHub Actionsでは、ステージをジョブに分け、needsで順番をつなぎます。GitHub Actions のワークフロー構文では、on.scheduleは既定でUTC、timezoneキーでIANA形式のタイムゾーンを指定できると定められています。Jenkinsのcronはサーバーのタイムゾーンで動くので、時刻のずれを防ぐにはタイムゾーンの明示が必要です。
name: build-deploy
on:
push:
branches: [main]
pull_request:
schedule:
- cron: '0 2 * * 1-5'
timezone: "Asia/Tokyo"
env:
MAVEN_OPTS: -Xmx1g
jobs:
build:
runs-on: ubuntu-latest
timeout-minutes: 30
steps:
- uses: actions/checkout@v7
- uses: actions/setup-java@v6
with:
distribution: temurin
java-version: '21'
cache: maven
- run: mvn -B package
- uses: actions/upload-artifact@v7
with:
name: jar
path: target/*.jar
deploy:
needs: build
if: github.ref == 'refs/heads/main' && github.event_name == 'push'
runs-on: ubuntu-latest
environment: production
steps:
- uses: actions/checkout@v7
- uses: actions/download-artifact@v8
with:
name: jar
path: target
- run: ./deploy.sh
env:
TOKEN: ${{ secrets.DEPLOY_TOKEN }}
notify:
needs: [build, deploy]
if: failure()
runs-on: ubuntu-latest
steps:
- run: |
curl -sS -X POST -H 'Content-type: application/json' \
--data "{\"text\":\"Failed: ${GITHUB_WORKFLOW}\"}" "$SLACK_WEBHOOK_URL"
env:
SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}アクションの版は2026年11月13日時点の各リポジトリの最新リリース（checkout v7.0.1、setup-java v6.2.0、upload-artifact v7.0.2、download-artifact v8.0.2）に合わせています。書き換えたファイルは、push前にactionlintによるGitHub Actionsワークフローの静的解析にかけると、needsの参照ミスや式の書き間違いをその場で拾えます。ビルド部分の書き方の詳細を確認したい場合はGitHub Actionsでビルド・自動テストを設定する方法を参照してください。
同じJenkinsfileのGitLab CIへの移行例と手動承認の設定
GitLab CIでは、ジョブの実行環境をコンテナイメージで指定し、成果物はartifactsで後続のステージへ自動で渡ります。承認待ちはControl how jobs runにあるwhen: manualの手動ジョブで表します。
stages: [build, deploy]
variables:
MAVEN_OPTS: "-Xmx1g"
default:
image: maven:3.9-eclipse-temurin-21
timeout: 30 minutes
build:
stage: build
script:
- mvn -B package
artifacts:
paths:
- target/*.jar
deploy:
stage: deploy
rules:
- if: $CI_COMMIT_BRANCH == "main"
when: manual
environment: production
script:
- ./deploy.sh # TOKEN は CI/CD 変数（masked・protected）で渡す
notify_failure:
stage: .post
when: on_failure
script:
- >
curl -sS -X POST -H 'Content-type: application/json'
--data "{\"text\":\"Failed: ${CI_PROJECT_PATH}\"}" "$SLACK_WEBHOOK_URL".postは全ステージの後に置かれる特別なステージで、when: on_failureを付けると失敗時だけ動きます。rules内でwhen: manualを指定したジョブは実行されるまでパイプラインを止めるため、inputに近い動きです。キーワードの全体はCI/CD YAML syntax referenceで確認できます。
Jenkinsの自動変換で落ちる5項目と通知・承認・認証・部品の再設計
Importerの公式ドキュメントは、必須のビルドツール、Scripted Pipeline、シークレット、セルフホストランナー、未知のプラグインを手動移行の対象として挙げています。Jenkinsfileの構文表でも、input・matrix・options・parametersは未対応です。実務で手が止まるのは、次の5項目にほぼ集約されます。
postのfailure・alwaysに対応する移行先別の後処理と通知設定
GitHub Actionsにはpostに当たるブロックがありません。ワークフロー内とアクション内で式を評価するにある状態チェック関数を、ステップやジョブのifに書いて表します。failureはif: failure()、alwaysはif: always()、successは条件を書かない通常のステップです。
注意したいのは範囲の違いです。Jenkinsのpostはパイプライン全体の結果を見ますが、ステップのif: failure()は同じジョブ内の失敗しか見ません。前掲の例のように、全ジョブの失敗を拾う通知はneedsで全ジョブに依存させた独立ジョブにします。GitLab CIでは、ジョブ単位の後処理をafter_script、パイプライン単位の通知を.postステージとwhen: on_failureで分けて書きます。
inputの承認をEnvironmentsの必須レビュー担当者へ置き換える条件
本番デプロイ前の承認は、GitHubでは環境（Environments）の保護ルール「必須のレビュー担当者」で表します。デプロイメントと環境によると、指定できるのは最大6人（またはチーム）で、そのうち1人が承認すればジョブが進みます。
ここが移行で最も見落とされやすい制限です。同じページには、GitHub Free・Pro・Teamでは必須のレビュー担当者をパブリックリポジトリでしか使えないと書かれています。環境シークレットも、Freeではパブリックリポジトリに限られます。社内システムのプライベートリポジトリをTeamプランで運用している組織がinput付きのJenkinsfileを移すと、承認ステップを同じ形では作れません。代わりに、デプロイ用ワークフローをworkflow_dispatchの手動起動にし、ブランチ保護で起動できる人を絞る形にするか、Enterpriseへの切り替えを検討します。GitLab CIでも、承認者を制限するProtected environmentsはPremium以上の機能です。手動ジョブ自体はFreeで使えます。
credentials()・withCredentialsの移行順とOIDCの選択
credentials()とwithCredentialsの移行では、Secretsへの登録とOIDCへの切り替えを分けて考えます。Importerは認証情報の値を移しません。登録し直す前に、クラウドへのデプロイに使う長期キーから見直します。GitHub ActionsはOpenID Connectで、AWSやGoogle Cloudから実行のたびに短期の認証情報を受け取れます。アクセスキーをSecretsに貼り直すより、移行を機にOIDCへ切り替えるほうが、キーのローテーションまで一度で片付くため効率的です。
OIDCに対応しない外部サービスのトークンだけを、リポジトリ・環境・組織のいずれかのSecretsに登録します。置き場所の決め方と漏えい経路はGitHub ActionsのSecrets管理と置き場所の選定で詳しく確認してください。GitLab CIでは、CI/CD変数にmaskedとprotectedを付け、保護ブランチのパイプラインでだけ値が渡るようにします。
共有ライブラリの移行手順とジョブ・ステップ単位の共通部品への分割
共有ライブラリのvars/に置いたGroovy関数は、移行先では「パイプラインの部品」と「ステップの部品」に分けて作り直します。GitHub Actionsでは、ジョブを丸ごと共通化するならReusable Workflows、数ステップの手順をまとめるならComposite Actionです。違いはComposite ActionとReusable Workflowの違いで比べています。
# GitHub Actions：共通ビルドを別リポジトリの再利用ワークフローとして呼ぶ
jobs:
build:
uses: example-org/ci-templates/.github/workflows/maven-build.yml@v1
with:
java-version: '21'
secrets: inherit
# GitLab CI：同じ役割をCI/CDコンポーネントで読み込む
include:
- component: $CI_SERVER_FQDN/example-org/ci-components/[email protected]
inputs:
java_version: "21"呼び出される側のworkflow_callの書き方と上限はReusable Workflowsの使い方にあります。GitLabのCI/CD componentsはGitLab 17.0で正式提供になり、Freeでも利用可能です。版を@1.0.0のように固定して読み込めるため、Jenkinsで@Library('lib@v1')と版を指定していた運用をそのまま引き継げます。
stashとunstashをartifactの受け渡しに置き換えるときのジョブ分割
Jenkinsのstashは、同じビルドの中でファイルを一時的に預けるPipeline: Basic Stepsのステップです。GitHub Actionsではジョブごとに別のランナーで動くため、ジョブをまたぐファイルはupload-artifactとdownload-artifactで受け渡します。GitLab CIはartifactsを書けば後続ステージへ自動で渡ります。
ステージをそのままジョブに写すと、ジョブごとにチェックアウトと依存関係の取得が繰り返されます。ジョブに分けるのは、並列で動かしたい場合と別の実行環境が要る場合の2つに絞ります。
並行稼働から切り替えまでの移行手順と実行時間・同時実行の上限
全ジョブを一度に切り替えず、パイプライン単位で新旧を並べて動かし、結果が一致したものから切り替えます。
dry-runとmigrateで1パイプラインずつPRを作り並行稼働で比較する
GitHub Actions Importerでは、1パイプラインごとに次の2つのコマンドを使います。
# 変換結果のYAMLを手元に出す（リポジトリには触れない）
gh actions-importer dry-run jenkins \
--source-url https://jenkins.example.com/job/app-build --output-dir tmp/dry-run
# 対象リポジトリに変換結果のプルリクエストを作る
gh actions-importer migrate jenkins \
--source-url https://jenkins.example.com/job/app-build \
--target-url https://github.com/example-org/app --output-dir tmp/migrate切り替えまでは次の順で進めます。
dry-runの出力で、手動移行が必要と示された箇所を直すmigrateでプルリクエストを作り、直した内容をそこへ反映する- デプロイを伴わないビルドとテストのジョブから先にマージし、1〜2週間はJenkinsと両方で動かして成否とテスト件数を突き合わせる
- 結果が一致したら、Jenkins側のジョブのトリガーを外して無効化する（削除は、履歴を参照しなくなってから）
- デプロイのジョブは最後に移し、切り替え当日はJenkins側を無効化した状態で1回目のデプロイを確認する
3で並行稼働させるのはビルドとテストだけです。デプロイ系のジョブを両方で動かすと、同じ環境へ二重にデプロイされます。
6時間のジョブ上限とセルフホストランナーが要るビルドの見分け方
GitHubのアクションの制限では、GitHubホステッドランナーのジョブは最大6時間、セルフホステッドランナーは最大5日です。ワークフロー全体の上限は35日、マトリックスで生成できるジョブはワークフロー実行あたり256個、Freeプランの標準ランナーの同時実行は20ジョブまでとされています。timeout-minutesを書かないジョブの既定値は360分です。
Jenkinsで6時間近くかかるビルド、社内ネットワークの検証環境やライセンスサーバーに接続するジョブ、GPUや特定のOS版が必要なジョブは、セルフホストランナーに載せる前提で見積もります。forecastの結果で必要な実行時間を見積もり、課金の目安はGitHub Actionsの料金と分単価で確認してください。
Jenkinsの継続判断とGitHub Actions・GitLab CIの選定基準
脱Jenkinsは、すべてのチームにとっての正解ではありません。移す場合と残す場合の条件を、ここで言い切っておきます。
移行先はリポジトリの置き場所で決まりGitLab CIを選ぶのは2条件のとき
コードがGitHubにあるなら、移行先はGitHub Actionsにします。プルリクエストとチェックの連動、Secretsの管理、Importerによる変換がすべて同じ場所で済むからです。GitLab CIを選ぶのは、すでにGitLabでコードを管理している場合と、オンプレミスにセルフマネージドのGitLabを置いてCIもその中で閉じたい場合の2つです。両者の機能と料金の差はGitHubとGitLabの違い（ActionsとGitLab CIの対応表）、他のツールを含めた比較はCI/CDツール比較を参照してください。
Jenkinsを残すべきなのはオンプレ専用機や長時間ビルドへの依存が深い場合
Jenkinsを残すのが妥当なのは、ビルドやテストの大半がオンプレミスの専用機や社内ネットワーク内の環境に依存し、結局すべてをセルフホストランナーで動かす場合です。移行してもサーバーの保守は残り、書き換えの工数だけが増えます。数千行規模の共有ライブラリを分解し直す工数を確保できない場合も、無理に移しません。残す場合にコンテナへ載せ替える手順はJenkins Dockerの構築手順：公式イメージ・Compose・Docker agentの設定で解説しています。
逆に、ジョブの大半がクラウドのビルドとテストで、Jenkinsサーバーのプラグイン更新やJavaの版上げに毎年工数を取られているなら、移行を先送りする理由はありません。どちらに当たるか判断がつかない、または棚卸しから切り替えまでを外部の手で進めたい場合は、一創のDevOps・CI/CD導入支援で、既存ジョブの調査から移行計画と並行稼働まで対応しています。
よくある質問
Jenkinsからの移行を検討する際によく出る質問をまとめました。
JenkinsfileをGitHub Actionsへ自動で変換できますか？
宣言的パイプラインとFreestyleジョブは、GitHub公式のGitHub Actions Importerで変換できます。stageやdockerの指定は対応済みで、agent・environment・whenなどは一部対応です。input・matrix・options・parametersは未対応で、Scripted Pipeline、シークレット、セルフホストランナー、未知のプラグインも手で移します。まずauditで全ジョブの変換可否を確かめ、手作業の量を見積もってから進めるのが確実です。
Jenkinsは時代遅れなので移行すべきですか？
古いかどうかより、判断の基準にするのは運用コストと依存先です。LTS Changelogでは2026年10月28日にもLTS 2.580.2が公開されており、開発は続いています。一方、2.555.1以降はJava 21か25が必須で、サーバーとプラグインの更新を自社で担う必要があります。ジョブの大半がクラウド上のビルドとテストなら移行の効果は大きく、オンプレミスの専用機への依存が深いなら残すほうが合理的です。Jenkinsの特徴はJenkinsとはで整理しています。
Jenkinsの認証情報をGitHubへ一括で移せますか？
移せません。GitHub Actions Importerはシークレットを手動移行の対象としており、値は移行先で登録し直します。登録先は、使うリポジトリが1つならリポジトリ、本番デプロイ用なら環境、複数リポジトリで共有するなら組織が選択先です。クラウドへのデプロイ用キーはOIDCへ切り替えると、登録自体が不要になります。
Jenkinsの移行にはどのくらいの期間がかかりますか？
期間を左右するのはジョブ数より、共有ライブラリとプラグイン依存の量です。宣言的パイプライン中心で共有ライブラリが無ければ、1本あたり数日で並行稼働に入れる場合もあるため、まずは依存の有無を確認してください。共有ライブラリを持つ組織や、Freestyleジョブが数百本ある組織では、棚卸しと部品の作り直しだけで数か月かかる場合があります。auditのレポートで変換できない項目を数え、1〜2本を試験的に移した実績から全体を見積もると外れにくくなります。
移行中にJenkinsとGitHub Actionsを併用しても問題ありませんか？
併用は推奨される進め方です。ビルドとテストのジョブを両方で動かし、成否やテスト件数を比べてから切り替えると、書き換えの漏れを本番前に見つけられます。ただしデプロイ系のジョブは、両方を有効にすると同じ環境へ二重にデプロイされるため、並行稼働の間もどちらか一方だけで動かします。
関連記事
- Jenkinsとは？料金・無料の範囲とインストールから使い方まで【LTS 2.580対応】：移行元のJenkinsの仕組みと、残す場合の版上げの注意点です
- CI/CDツール比較｜主要11製品の無料枠・料金と選び方【2026年10月】：移行先の候補を料金と実行環境で比べるときに使えます
- CircleCIとは？使い方・config.ymlの書き方と料金（無料枠30,000クレジット）【2026年10月】：GitHub ActionsとGitLab CI以外の移行先を検討する場合の候補です
- Reusable Workflows（GitHub Actions）の使い方：workflow_callの定義と呼び出し、secrets・outputs・上限：共有ライブラリを作り直すときの呼び出される側の書き方です
- GitHub ActionsのSecrets管理｜置き場所の選定と漏えい経路・OIDC移行の判断：認証情報を移すときの置き場所の決め方です
