LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

Jenkinsの画面に更新の警告が並んでいるが、上げてよいのか分からない。作った担当者はすでに異動していて、どのジョブが何をしているのか誰も説明できない——。社内で長く使ってきたCIの仕組み（コードを変えるたびにビルドやテストを自動で回す仕組み）では、こうした状態が起こりがちです。Jenkins（ジェンキンス）は、ビルド・テスト・デプロイを自動で実行するためのオープンソースの自動化サーバーです。

自社のサーバーに置いて自由に作り込める一方、更新を止めると脆弱性の修正を受けられなくなります。GitHub Actionsへの移し替えが候補に挙がることもありますが、ただし万能ではなく、移せば保守がなくなるわけでもありません。本記事では、古いJenkinsを任された情報システムの担当者に向けて、JenkinsとGitHub Actionsの違い、古いJenkinsの保守で見る点、移行の判断と進め方、そして外部に頼むときに確認したい点を整理します。

Jenkinsとは

Jenkinsは、ソースコードの変更をきっかけに、ビルドやテストといった決まった作業を自動で流すための仕組みです。中心になるサーバー（コントローラー）が段取りを決め、実際の処理は「エージェント」と呼ぶ別のマシンに振り分けます。作り込みの自由度が高いぶん、保守の手間も自社で持つ道具です。

• ライセンスはMITライセンス（商用でも無料で使え、改変もできる緩やかなライセンス）です^*6
• 機能はプラグインで足します。公式の配布元（Update Center）から、1,000を超えるプラグインを入れられます^*3
• 版の系統は2つあります。毎週出る版と、12週ごとに基準の版を選び、4週ごとに不具合と脆弱性の修正だけを入れる安定版（LTS）です^*1
• LTSでは、データの持ち方の都合で新しい版へは上げられても、古い版へは戻せません

変化を抑えたい業務用途には、LTSが向いています。1つのLTSの系統は修正版を3回出すと役目を終え、次の基準の版に引き継がれます。^*1古い系統のまま止まると、新しい脆弱性の修正を受けられません。戻せない仕組みなので、更新の前にはバックアップを取ります。

JenkinsとGitHub Actionsの違い

GitHub Actionsは、GitHubに組み込まれたCIの仕組みです。GitHubの公式ドキュメントは、どちらもビルド・テスト・公開・デプロイを自動で行うワークフローを作れる点で共通していると説明しています。^*7 違いが出るのは、どこで動かすか、誰が保守するかという点です。

見落としやすいのは、GitHub Actionsでも自社のマシンで動かす場合は、OSやソフトの更新が利用者の責任になる点です。^*10 移せば保守がなくなるのではなく、保守する対象がワークフローと実行環境に移ると考えると判断しやすくなります。実行時間の費用の抑え方はCI/CD実行コストを削減する進め方で扱っています。

古いJenkinsの保守で見る点

長く更新していないJenkinsで最初に見るのは、本体の版、動かしているJavaの版、入っているプラグインの3つです。互いに対応する版が決まっているので、1つだけ上げると残りと合わなくなることがあります。

• LTSの更新：何版も飛ばして上げるときは、間の版の注意点もすべて読むよう、公式のアップグレードガイドが勧めています^*5
• Javaの対応：対応していないJavaの版ではJenkinsが起動しません。Java 17で動く最後のLTSは2026年3月の2.541.3で、Java 21のサポートは2027年9月に終わる予定です^*2
• ビルドに使うJava：Jenkins本体を動かすJavaと、アプリのビルドに使うJavaは別に選べます。本体のJavaを上げても、アプリ側は一部のプラグインを除いて合わせなくて済みます
• プラグインの整理：使っていないプラグインを外すと、メモリの消費や、将来の更新での衝突を減らせます^*3
• 保守の続き具合：プラグインの管理画面には「Health Score」という目安があり、保守が続いているかを見比べられます

もう1つ注意したいのが、プラグインの脆弱性です。プラグインは作者ごとに保守されているため、修正されないまま脆弱性が公表されることがあり、その場合の対処は使うのをやめることしかありません。重いものは配布そのものが止まります。^*4 どのジョブがどのプラグインに頼っているかの一覧は、保守を続けるときも移行するときも出発点になります。

移行の判断と進め方

Jenkinsを使い続けるか、GitHub Actionsへ移すかは、道具の優劣ではなく自社の事情で決まります。次のような目安で考えると、話が進めやすくなります。

• 移行を考えやすい場合：ソースコードがすでにGitHubにある、ジョブが少なく単純、Jenkinsのサーバーと更新を受け持つ人がいない
• 残すことも考えたい場合：社内ネットワークの機器や古いツールと深くつながっている、Scripted Pipeline（Groovyという言語で自由に書いた手順）が多い、自社向けのプラグインに頼っている

移すと決めたら、いきなり全部を切り替えず、次の4つの段階で進めます。

• ステップ1：棚卸し。GitHubの移行ツール（GitHub Actions Importer）の監査機能は、Jenkinsのジョブを一通り変換し、どこまで自動で移せるかの報告を出します^*8
• ステップ2：手作業の部分を洗い出す。Scripted Pipeline、パスワードなどの秘密情報、セルフホストランナー、ツールが知らないプラグインは手作業で移します^*8
• ステップ3：小さなジョブから試しに移し、Jenkinsと並べて動かして同じ結果になるかを確かめる
• ステップ4：切り替えてJenkinsを止める。設定とビルドの履歴はバックアップとして残す

費用の見積もりも忘れずに行います。非公開のリポジトリでGitHubが用意する実行環境を使う場合、プランの無料枠を超えた分は課金されます。^*9 ビルドの回数が多い会社は、移行ツールの見積もり機能や今のビルド時間から、移した後の費用を試算しておきます。

外部に頼むときに確認しておきたい点

古いJenkinsの更新や移行を外部に頼むときは、作業の中身より先に、何をどこまで任せるかを決めておくと見積もりがぶれにくくなります。次の点を、依頼の前に確かめておきます。

• 範囲：本体とJavaの更新だけか、プラグインの整理まで含むか、GitHub Actionsへの移行まで頼むか
• 棚卸しの成果物：ジョブ・プラグイン・認証情報の一覧を誰が作り、どの形で受け取るか
• 検証のしかた：更新や移行の前後で、同じソースコードのビルドとテストの結果をどう照らし合わせるか
• 戻し方：古い版へは戻せないため、バックアップの取り方と、失敗したときの戻し手順を決めているか
• 運用後の見直し：LTSの更新を誰がいつ続けるか。移した場合は、ワークフローと実行環境の更新を誰が受け持つか

最後の点は宙に浮きやすいところです。LTSは4週ごとに修正版が出るので、更新の担当を決めないまま引き渡しを受けると、数年後に今と同じ状態へ戻ってしまいます。自動化の仕組みづくり全体を外部に頼む場合はCI/CD構築支援の外注にまとめています。

まとめ：Jenkinsで確かめておきたい3つの点

古いJenkinsを保守するか移すかを決めるうえで、確かめておきたい点は3つに整理できます。第一に、本体の版・Javaの版・プラグインの3つを一緒に棚卸しすること。第二に、GitHub Actionsへ移しても保守はなくならず、ワークフローと実行環境の更新が残ると理解しておくこと。第三に、LTSの更新を誰がいつ続けるかを、作業の前に決めておくことです。この3点を踏まえておけば、「更新したらジョブが動かなくなった」「移したのに結局また放置された」という事態を避けやすくなります。保守と移行のどちらを選ぶかに迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：Jenkins「LTS Release Line」（https://www.jenkins.io/download/lts/）。出典：12週ごとの基準の版の選定、4週ごとの修正版、1つの系統の修正版が3回であること、新しい版へは上げられても古い版へは戻せないことの記述を参照（2026年10月確認）
2. *2　参考：Jenkins「Java Support Policy」（https://www.jenkins.io/doc/book/platform-information/support-policy-java/）。出典：対応Javaの一覧（Java 17の最終LTS 2.541.3・2026年3月、Java 21のサポート終了予定 2027年9月）、対応外のJavaでは起動しないこと、ビルドに使うJavaは別に選べることの記述を参照（2026年10月22日確認）（2026年10月確認）
3. *3　参考：Jenkins「Managing Plugins」（https://www.jenkins.io/doc/book/managing/plugins/）。出典：Update Centerと1,000を超えるプラグイン、使っていないプラグインを外す利点、Health Scoreの記述を参照（2026年10月確認）
4. *4　参考：Jenkins「Handling Vulnerabilities in Plugins」（https://www.jenkins.io/security/plugins/）。出典：未修正の脆弱性の公表、使用中止以外に対処が無い場合があること、配布停止の記述を参照（2026年10月確認）
5. *5　参考：Jenkins「Jenkins LTS Upgrade Guide」（https://www.jenkins.io/doc/upgrade-guide/）。出典：LTSを飛ばして上げる場合は間の版の節をすべて読むよう勧める記述を参照（2026年10月確認）
6. *6　参考：jenkinsci/jenkins（GitHub）（https://github.com/jenkinsci/jenkins）。出典：リポジトリの説明（Jenkins automation server）とライセンス（MIT License）を参照（2026年10月確認）
7. *7　参考：GitHub Docs「Migrating from Jenkins to GitHub Actions」（https://docs.github.com/en/actions/tutorials/migrate-to-github-actions/manual-migrations/migrate-from-jenkins）。出典：両者の共通点、Jenkinsは自社で動かすのが一般的であること、GitHubの実行環境とセルフホストランナー、Declarative/Scripted PipelineとYAML、ステージとジョブの対応の記述を参照（2026年10月確認）
8. *8　参考：GitHub Docs「Migrating from Jenkins with GitHub Actions Importer」（https://docs.github.com/en/actions/tutorials/migrate-to-github-actions/automated-migrations/jenkins-migration）。出典：監査（audit）機能の内容、手作業で移す必要がある項目、使用量の見積もり（forecast）機能の記述を参照（2026年10月確認）
9. *9　参考：GitHub Docs「GitHub Actions billing」（https://docs.github.com/en/billing/concepts/product-billing/github-actions）。出典：非公開リポジトリの無料枠と超過分の課金、セルフホストランナーは無料であることの記述を参照（2026年10月確認）
10. *10　参考：GitHub Docs「Self-hosted runners」（https://docs.github.com/en/actions/concepts/runners/self-hosted-runners）。出典：OSとソフトの更新は利用者の責任であること、マシンの維持費用は利用者が持つことの記述を参照（2026年10月確認）

Tweet