Jenkinsとは？料金・無料の範囲とインストールから使い方まで【LTS 2.580対応】

Jenkinsは、ビルド・テスト・デプロイといった開発の反復作業をサーバーに任せるオープンソースの自動化サーバーです。ソフトウェア自体は無料で、費用はサーバー代と運用の手間に移ります。2026年はJava 17の打ち切りとLinuxリポジトリの署名鍵の切り替えが重なり、古い手順のままでは起動や更新が止まるようになりました。この記事では、無料になる範囲、最新LTS 2.580.2の動作要件、Ubuntu・Windows・Dockerへのインストール、最初のジョブとビルドの自動起動、更新で止まったときの直し方までを、公式ドキュメントの記述に沿って説明します。

まとめ

• Jenkins本体はMITライセンスのOSSで、ユーザー数やビルド回数による課金はありません。公開プラグイン2,129件（2026年11月2日時点）も無償ですが、ライセンスは本体と同じとは限りません。
• 最新LTSは2.580.2（2026年10月28日公開）。Java 21または25が必要で、Java 17ではLTS 2.555.1以降が動きません。
• インストールはUbuntu・Debianならapt、WindowsはMSI、試すだけならDockerが最短です。初回はinitialAdminPasswordでロックを解除します。
• ビルドの自動起動は、定期実行のcron、変更検知のpollSCM、GitHubからのWebhookが基本です。
• 2026年1月21日のLTS 2.541.1から署名鍵がjenkins.io-2026.keyに変わりました。aptでNO_PUBKEY 7198F4B714ABFC68が出たら鍵を入れ直します。
• 社内ネットワークの中でしか動かせないビルドがあるなら今も有力です。更新を見る担当者を置けないならSaaS型CIを選んでください。

Jenkinsの仕組みとできること

JenkinsはJavaで書かれたサーバーアプリケーションです。リポジトリへのpushや決めた時刻をきっかけに、コンパイル・テスト・静的解析・成果物の配布を決めた順に実行し、結果を記録します。人がその都度コマンドを叩く代わりに、常駐したJenkinsが同じ手順を同じ条件で繰り返す。これが継続的インテグレーション（CI）の実体で、CI/CD全体の考え方はCI/CDの仕組みとパイプライン構成で整理しています。

Jenkins本体とプラグインの分担

本体が持つのは「いつ・何を・どの順で実行し、結果をどう扱うか」を管理する仕組みだけです。ビルドやテストそのものは、外部のコマンドやツールを呼び出して行います。Git連携、テスト結果の集計、SonarQubeによる静的解析との接続、Slack通知といった個別の機能はプラグインで足す設計で、公式の配布サイトには2026年11月2日時点で2,129件が公開されています（plugins.jenkins.ioのAPIが返す件数）。

コントローラーとエージェントの分担

Jenkinsの画面と設定を持つサーバーをコントローラー、実際にビルドを走らせるマシンをエージェントと呼びます。初期状態ではコントローラー自身（built-in node）でもビルドが動きますが、公式のセキュリティ文書は「built-in nodeではビルドを実行しないことを強く推奨する」と書いています（Controller Isolation）。ビルドのスクリプトがコントローラーの設定ファイルや秘密情報に触れられてしまうためです。検証用でも、信頼できないコードや実際の認証情報を扱う場合は分離が必要です。継続利用する環境では、エージェントを1台以上つないでからbuilt-in nodeのexecutor数を0にします。

Hudsonから改名した経緯

JenkinsはもともとHudsonという名前で、川口耕介氏が開発を始めました。Hudsonの商標をめぐってOracleとコミュニティが対立し、コミュニティは2011年1月の投票でJenkinsへの改名を決めています。Oracle側のHudsonはその後Eclipse Foundationへ寄贈され、開発が続いているのはJenkinsの側です。現在のJenkinsはLinux Foundation傘下のCD Foundationのプロジェクトとして運営されています。

Jenkinsの料金と無料で使える範囲

Jenkins本体はMITライセンスで公開されています。商用の開発に使っても料金は発生せず、ユーザー数・ジョブ数・ビルド回数による上限もありません。プラグインも無償で入手できます。ただし、プラグインのライセンスは本体と同じではありません。公式配布の条件は「OSI承認のオープンソースライセンスまたはパブリックドメイン相当であること（MITを推奨）」で（プラグイン公開の準備）、Apache License 2.0などが混在します。再配布を伴う使い方をするなら、個々のプラグインの表記を確認してください。

無料なのはソフトウェアだけです。実際の費用は次の3つに移ります。

• サーバー代：公式の目安は、小規模チームでメモリ4GB以上・ディスク50GB以上です（最低要件はメモリ256MB・ディスク1GB）。ビルドが重くなればエージェント機の台数分が増えます。
• 運用の手間：本体とプラグインのセキュリティ修正は頻繁に出ます。2026年10月28日にもLTSとweeklyの両方でセキュリティ修正版が出ました。
• 商用サポート：サポート付きが要るならCloudBees CIという別の商用製品があります。価格は公開されておらず、見積もりが必要です。

SaaS型のCIと月額で比べたいときは、主要CI/CDツールの無料枠と料金の比較に11製品の枠と単価を並べています。

動作要件とLTS・weeklyの選び方

2026年11月2日時点の最新版は、LTSが2.580.2（2026年10月28日）、weeklyが2.588（同日）です。導入前に確認すべきなのはJavaのバージョンで、LTSのチェンジログには「Java 21 or Java 25 are required to run Jenkins 2.555.1. Java 17 is not supported with Jenkins 2.555.1 and later.」とあります（LTS Changelog）。2.580.2のテスト済み構成もLinux・WindowsとJDK 21・25です。JDKの選び方と21から25への差分はJava 21と25の違いと移行で止まる箇所にまとめています。

LTSは12週ごとにweeklyの中からベースラインを選び、その後は修正だけを取り込みます。業務で使うサーバーならLTSを選んでください。weeklyが必要になるのは、まだLTSに入っていない機能を前提にプラグインを開発・検証する場合くらいです。

Jenkinsのインストール手順

Ubuntu・Debianへのaptインストール

公式リポジトリを登録してaptで入れるのが標準です。JavaはJenkinsに同梱されないので先に入れます。手順はpkg.jenkins.io/debian-stableの記載どおりです。

sudo apt update
sudo apt install fontconfig openjdk-21-jre

sudo mkdir -p /etc/apt/keyrings
sudo wget -O /etc/apt/keyrings/jenkins-keyring.asc \
  https://pkg.jenkins.io/debian-stable/jenkins.io-2026.key
echo "deb [signed-by=/etc/apt/keyrings/jenkins-keyring.asc]" \
  https://pkg.jenkins.io/debian-stable binary/ | sudo tee \
  /etc/apt/sources.list.d/jenkins.list > /dev/null

sudo apt update
sudo apt install jenkins

debian-stableがLTSの配布先で、weeklyを入れるときだけdebianに読み替えます。鍵ファイルはjenkins.io-2026.keyです。古い記事にあるjenkins.io-2023.keyのまま進めると、最新のパッケージで署名の検証に失敗します。インストールが終わるとsystemdのサービスとして登録され、8080番ポートで待ち受けます。

WindowsへのMSIインストール

Windowsは公式ダウンロードページのMSIを使います（Windowsへのインストール）。ウィザードで決めるのは、インストール先（既定はC:\Program Files\Jenkins）、サービスを動かすアカウント、ポート（既定は8080）、Javaの場所の4つです。

• 実行アカウントは、公式がローカルユーザーかドメインユーザーを推奨しています。LocalSystemはWindowsのrootに近い権限を持つので、本番では避けます。指定したユーザーにはLogonAsService権限が必要で、「Test Credentials」で確認できます。
• ポートは「Test Port」で空きを判定できます。8080を他のアプリが使っているなら、ここで別の番号にします。
• Javaはレジストリから推奨版が自動で選ばれます。Java 17しか入っていないマシンでは先にJDK 21か25を入れてください。Windowsサービスとして動かすには.NET Framework 4.0以上も必要です。

同じ設定はmsiexecのプロパティ（INSTALLDIR・PORT・JAVA_HOMEなど）でも渡せるので、複数台に配る場合はサイレントインストールにできます。

Dockerコンテナでの起動とデータ保存

評価や検証が目的なら、後片付けまで含めてコンテナが最短です。公式ドキュメントはjenkins/jenkins:2.580.2-jdk21をベースイメージに使っています（Dockerでのインストール）。

docker run --name jenkins --detach --restart=on-failure \
  --publish 8080:8080 --publish 50000:50000 \
  --volume jenkins-data:/var/jenkins_home \
  jenkins/jenkins:2.580.2-jdk21

8080がWeb画面、50000がエージェントの接続口です。設定とジョブの履歴は/var/jenkins_homeに保存されるため、ここをボリュームにしないとコンテナを作り直した時点で消えます。版を固定したくなければlts-jdk21タグも使えます。パイプラインの中でdockerコマンドを使う場合、公式手順はdocker:dindのコンテナを同じDockerネットワークで並べて動かす構成を案内しています。公式ドキュメントのディスク要件は、コンテナで動かす場合に10GB以上です。

初回起動後のセットアップ

ブラウザでhttp://localhost:8080を開くと、ロック解除の画面が出ます。サーバーに入れる人だけが初期設定できるようにする確認で、サーバー上のファイルから初期パスワードを読み出します。

sudo cat /var/lib/jenkins/secrets/initialAdminPassword

docker exec jenkins cat /var/jenkins_home/secrets/initialAdminPassword

1行目がaptで入れた場合、2行目がDockerの場合です。Windowsはロック解除画面に表示されるパスを開いてください。公式文書の記載が分かれており、インストール手順はC:\Program Files\Jenkins\secrets、システム設定の文書はJENKINS_HOMEの既定をC:\ProgramData\Jenkins\.jenkinsとしています。

解除すると、「Install suggested plugins」と「Select plugins to install」の選択画面になります。最初の構築なら前者で十分で、GitやPipelineなど後の手順で使うプラグインがまとめて入ります。最後に管理者ユーザーを作り、Jenkins URL（外から見えるURL）を確認して終了です。リバースプロキシの裏に置くなら、ここをlocalhostのままにしないでください。通知メールやWebhookのリンクがlocalhost宛てになります。

最初のジョブの作成と動作確認

ジョブには、画面のフォームで設定するFreestyleと、処理をコードで書くPipelineがあります。動作確認はFreestyle、実運用はPipelineと使い分けます。

Freestyleジョブによる動作確認

ダッシュボードの「New Item」から名前を付けてFreestyle projectを選び、「Build Steps」に「Execute shell」（Windowsは「Execute Windows batch command」）を追加してecho "hello jenkins"のようなコマンドを書きます。保存して「Build Now」を押すとビルド履歴に1件増え、Console Outputにコマンドの出力が表示されます。ここまでで、Jenkinsが動いていること、ワークスペース（ジョブごとの作業ディレクトリ）にファイルが作られることを確かめられます。

Jenkinsfileによるビルドとテストの定義

実運用ではPipelineにして、処理の定義をリポジトリのJenkinsfileに置きます。以下は、Gradle Wrapperとテストを含む単一モジュールのJavaプロジェクトを、互換性のあるJDKとUnixシェルを備えたノードで実行する例です。Windowsノードではshをbatに、呼び出すスクリプトをgradlew.batに変更してください。処理定義の変更履歴が残り、サーバーを作り直す際にも再利用できます。ただし、ジョブのSCM設定、認証情報、プラグイン、エージェント設定は別途復元する必要があります。

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                sh './gradlew assemble'
            }
        }
        stage('Test') {
            steps {
                sh './gradlew test'
            }
            post {
                always {
                    junit 'build/test-results/test/*.xml'
                }
            }
        }
    }
}

この宣言的（Declarative）記法はGroovyが土台で、条件分岐や共通処理の切り出しではGroovyの文法を使えますが、Declarative Pipelineでは一般的な制御構文をscriptブロック内に記述します。複雑な共通処理はShared Librariesへ分離します。postのjunitはテスト結果のXMLを取り込む指定で、JUnitプラグインが要ります（セットアップの推奨プラグインに含まれます）。ジョブの種類は「Pipeline」を選び、「Pipeline script from SCM」でリポジトリのURLとJenkinsfileのパスを指定します。

ビルドを自動で起動する設定

「Build Now」を押す運用ではCIになりません。ここでは、時刻で起動する方法、変更を見に行く方法、リポジトリ側から呼ばれる方法を説明します。宣言的パイプラインではtriggersブロックに書きます（Pipeline Syntax）。

pipeline {
    agent any
    triggers {
        cron('H 2 * * 1-5')        // 平日の2時台に1回
        pollSCM('H/15 * * * *')    // 15分おきにリポジトリの変更を確認
    }
    stages {
        stage('Build') {
            steps { sh './gradlew build' }
        }
    }
}

cronのH記号による起動時刻の分散

書式は「分 時 日 月 曜日」の5項目で、Unixのcronとほぼ同じです。違いはH記号で、ジョブ名のハッシュから決まる値に置き換わります。十数個の日次ジョブを0 0 * * *で揃えると深夜0時に負荷が集中しますが、H H * * *にすると各ジョブが1日1回ずつ別の時刻に走ります。値は乱数ではないため、同じジョブなら毎日同じ時刻です。なお日の欄にH/3のような短い周期を書くと、月末で間隔が崩れると公式が注意しています。

GitHubのWebhookによるpush時の自動起動

pollSCMは変更が無くても定期的にリポジトリへ問い合わせます。pushの直後に走らせたいならWebhookにします。GitHubプラグインの場合、リポジトリのWebhook送信先に<JenkinsのURL>/github-webhook/を登録し、ジョブ側で「GitHub hook trigger for GITScm polling」にチェックを入れます（GitHub plugin）。GitHubからJenkinsへ通信が届く必要があるため、社内ネットワークの奥にあるJenkinsではpollSCMで代用するか、受け口を用意します。自前のGitサーバーと組み合わせる例はGitBucketとJenkinsの連携手順にあります。

プラグインの追加と更新

セットアップ後にプラグインを足すときは、「Manage Jenkins」の「Plugins」を開きます。Availableタブで検索してインストールし、導入済みの一覧と無効化はInstalled、更新はUpdatesで扱います。

気をつけるのは更新です。プラグインは互いに依存しており、依存先もまとめて更新されるため、一括更新でジョブの挙動が変わることがあります。更新の前にJENKINS_HOME（aptなら/var/lib/jenkins、Dockerなら/var/jenkins_home）をバックアップし、別環境で復元できることを確認してください。復旧時間はデータ量や保存先、プラグイン構成によって変わります。

既存環境の更新で止まる2026年の変更

新しく入れるだけなら上の手順で動きます。困るのは、数年前に構築したJenkinsを更新するときです。2026年のLTSには、何もしないと更新や起動が止まる変更が2つと、オフライン環境だけが影響を受ける変更が1つ入りました。

apt updateのNO_PUBKEYエラーと署名鍵の更新

Linuxのパッケージ署名鍵は3年で期限が切れる運用で、weeklyは2025年12月23日の2.543から、LTSは2026年1月21日の2.541.1から新しい鍵に変わりました（公式ブログの告知）。古い鍵のままのサーバーでは、apt updateが次のように止まります。

W: GPG error: https://pkg.jenkins.io/debian-stable binary/ Release:
    The following signatures couldn't be verified because the public key is not available:
        NO_PUBKEY 7198F4B714ABFC68
E: The repository 'https://pkg.jenkins.io/debian-stable binary/ Release' is not signed.

上のaptの手順の鍵取得行（wgetでjenkins.io-2026.keyをsigned-byで指定したパスへ上書き保存する行）だけを実行し直せば直ります。signed-byのパスが古い記事どおり/usr/share/keyrings/jenkins-keyring.ascなら、そのパスへ保存します。Red Hat系はsudo rpm --import https://pkg.jenkins.io/rpm-stable/jenkins.io-2026.keyです。WindowsとmacOSは影響を受けません。

Java 17環境の起動失敗と実行JVMの更新

2.555.1以降はJava 17で起動しません。公式のDockerイメージもJava 17版の提供をやめています。aptの更新でJenkinsだけが新しくなり、Javaが17のまま残ると、サービスが立ち上がらなくなります。更新前に、コントローラーと全エージェントのJenkinsプロセスが使うJavaを確認し、両方を21か25へ更新してください。端末のjava -versionだけでは、サービスに設定されたJavaの場所までは確認できません。

2.580.1の同梱プラグイン除外とオフライン環境

2.580.1では、bouncycastle API・JAXBなどのライブラリ系9個と、JUnit・Mailer・Matrix Authorization Strategy・Matrix Project・OWASP Markup Formatterの5個がjenkins.warに同梱されなくなりました（2.580のアップグレードガイド）。公式は「ほとんどの環境は影響を受けない」としています。更新センターに接続できれば、必要になった時点でネットワーク経由で自動的に入るためです。影響を受けるのは、更新センターに届かないオフライン環境と、1.577以前から直接更新する環境です。オフライン環境では、プラグインのファイルを更新センターから取得し、JENKINS_HOMEのpluginsディレクトリへ置いてから新しい版を起動します。1.577以前から上げる場合は、5個を起動前に入れておきます。

Jenkinsは時代遅れか：選ぶ場面と避ける場面

CIサーバーの保守担当者を置けない新規開発では、GitHub ActionsやCircleCIのようなSaaS型を先に検討してください。事業者提供の実行環境を使えばサーバー保守を任せられます。ただし、実行環境やアクションの変更に合わせたワークフローの修正は利用者側に残り、セルフホストランナーの保守も自社で担います。その意味で「最初の選択肢」ではなくなりました。ただ、CI基盤全体を自社管理したい条件では、Jenkinsが有力な候補になります。

• Jenkinsを選ぶ：社内ネットワークからしか届かない機器・ライセンスサーバー・検証端末を使うビルドがある。ソースコードや成果物を外部のSaaSに出せない。ビルドの分数課金が膨らむほど回数が多く、自前のマシンで回した方が安い。
• Jenkinsを避ける：更新を継続的に見る担当者を置けない。更新が止まったJenkinsは脆弱性を抱えたまま社内に残ります。ビルド対象がクラウド上のコンテナだけで完結するなら、GitHub ActionsのワークフローやCircleCIのconfig.ymlの方が立ち上がりも速く済みます。
• 別の道具を選ぶ：Kubernetes上でパイプラインを組むことが前提なら、Kubernetesのリソースとして動くよう設計されたTektonの方が噛み合います。

Jenkinsを入れるかどうかは、ツールの新しさではなく「誰が保守を持つか」で決まります。組織としてどこまで自動化を持つかはDevOpsの考え方とDORA指標と合わせて考えると判断しやすくなります。パイプライン設計から運用の引き継ぎまで社外の手を借りたい場合は、DevOps・CI/CD導入支援で相談を受け付けています。

よくある質問

Jenkinsは無料で使えますか？

本体はMITライセンスで無償です。ユーザー数やビルド回数による課金もありません。プラグインも無償で入手できますが、ライセンスはプラグインごとに異なります。費用はサーバー代と運用の手間で、商用サポート付きのCloudBees CIは別製品・価格非公開です。

Jenkinsのライセンス料はかかりますか？

かかりません。商用利用でも料金は発生せず、利用開始の申請も不要です。再配布する場合は、本体のMITライセンスの表記と各プラグインのライセンスを確認してください。

Java 17のままでもJenkinsは動きますか？

LTS 2.555.1以降は動きません。最新のLTS 2.580.2も、Java 21またはJava 25が必要です。Java 17で運用している場合は、Jenkinsを更新する前にJDKを入れ替えてください。

JenkinsとGitHub Actionsはどちらを選ぶべきですか？

コードがGitHubにあり、ビルドがクラウドで完結するならGitHub Actionsです。社内ネットワークの機器を使うビルドや、外部に出せない成果物があるならJenkinsが向きます。11製品の比較はCI/CDツール比較にまとめています。

LTSとweeklyのどちらを入れるべきですか？

業務のビルド基盤にはLTSを推奨します。同じベースライン内の更新は主に不具合・セキュリティ修正ですが、ベースラインの切り替えではJava要件などが変わるため、アップグレードガイドの確認が必要です。weeklyは新機能の検証やプラグイン開発向けです。

関連記事

• CI/CDとは：仕組み・パイプライン構成・GitHub Actionsの設定例と導入判断の基準を解説
• CI/CDツール比較｜主要11製品の無料枠・料金と選び方【2026年10月】
• GitHub Actionsとは？できること・使い方と最初のワークフロー、料金と上限【2026年10月】
• Tektonとは？Kubernetesネイティブに動くCI/CDフレームワークの仕組みと採用判断を実装者目線で解説【2026年版】
• Java 21と25の違い｜正式化した新機能・サポート期限・移行で止まる箇所を実機で比較