2024.10.25 自動化

Jenkinsとは？できること・無料の範囲とインストールから使い方まで【2026年版】

Q: WindowsサーバーにJenkinsを導入できますか？

MSIインストーラーが配布されており、Windowsサービスとして常駐させられます。既定のインストール先は C:\Program Files\Jenkins で、初回のロック解除に使うパスワードはそのsecretsフォルダに置かれます。

Jenkinsとは？できること・無料の範囲とインストールから使い方まで【2026年版】

Jenkinsは、ビルドやテスト、デプロイといった開発の反復作業をサーバーに任せるためのオープンソースの自動化サーバーです。ただし2026年のJenkinsは「入れればとりあえず動く」ソフトではなくなりました。LTS 2.555.1でJava 17のサポートが打ち切られ、Java 21または25が必須になったためです。この記事では、Jenkinsが引き受ける仕事の範囲と無料になる線引きを整理したうえで、Ubuntu・Windows・Dockerそれぞれのインストール手順、初回起動後のセットアップ、最初のパイプラインを動かすところまでを、公式ドキュメントの記述に沿って解説します。

まとめ

Jenkins本体はMITライセンスのOSSで、無償で商用利用できます。公開プラグイン2,091件（2026年8月4日時点）もすべてオープンソースライセンスで配布され、追加料金はかかりません。
2026年8月時点の最新LTSは2.568.1（2026年7月8日公開）。動作にはJava 21または25が必要で、Java 17環境ではLTS 2.555.1以降が起動しません。
インストールはUbuntu・Debianならapt、WindowsはMSIインストーラー、試すだけならDockerが最短です。
初回起動は8080番ポート。ロック解除にはサーバー上のinitialAdminPasswordファイルを読み出します。
更新を継続的に見る担当者を置けないならJenkinsは向きません。サーバーの維持と破壊的変更への追随を事業者側が持つSaaS型CIのほうが破綻しにくくなります。

以下では、Jenkinsの役割の整理から始めて、費用・動作要件・OS別の導入手順・最初のジョブ作成までを順に見ていきます。

JenkinsがCI/CDで担う役割

JenkinsはJavaで書かれた自動化サーバーです。リポジトリへのpushや指定時刻をきっかけに、コンパイル・テスト・静的解析・成果物の配布といった一連の処理を、決められた順序で実行します。人がその都度コマンドを叩く代わりに、常駐したJenkinsが同じ手順を同じ条件で繰り返す。これが継続的インテグレーション（CI）の実体です。

Jenkinsが自動化する処理の範囲

Jenkins本体が持つのは「いつ・何を・どの順で実行し、結果をどう扱うか」を管理する仕組みだけです。実際のビルドやテストは、外部のコマンドやツールを呼び出して行います。テスト結果の集計、SonarQubeでできることと対応言語を踏まえた静的解析との連携、成果物の配布先といった個別の機能は、プラグインを追加して補う設計です。公式のプラグイン配布サイトには2026年8月4日時点で2,091件が公開されており、この拡張性の広さがJenkinsを長く生き残らせてきました。パイプラインという考え方そのものの整理はCI/CDの仕組みと導入判断で扱っています。

DockerやGitHub Actionsとの役割の違い

検索でよく並ぶ「JenkinsとDockerの違い」は、実は比較の対象がずれています。Dockerは実行環境をコンテナとして固めて動かす基盤であり、処理の順番を管理する仕組みではありません。JenkinsをDockerコンテナとして起動することも、Jenkinsのジョブからdockerコマンドを呼ぶこともあり、両者は置き換えではなく併用の関係にあります。

本当の比較対象はGitHub ActionsやCircleCIのようなSaaS型CIです。これらはサーバーの構築も更新も事業者側が持ちますが、実行時間には枠があります。GitHub ActionsのFreeプランならプライベートリポジトリで月2,000分までが無料枠で、超過分は従量課金です（パブリックリポジトリは標準ランナーが無料）。Jenkinsは逆に実行時間の上限を持たず、自分でサーバーを立てて維持する負担と引き換えに、社内ネットワークの奥にある資産や特殊なハードウェアにも到達できます。SaaS型との具体的な設定の違いはCircleCIのconfig.ymlと料金体系の解説と読み比べると輪郭がはっきりします。

ライセンスと費用の内訳

Jenkins本体はMITライセンスで公開されています（jenkinsci/jenkinsリポジトリのLICENSE）。商用プロダクトの開発に使っても料金は発生せず、ユーザー数やビルド回数による課金もありません。前述の2,091件のプラグインも無償で入手できます。ただしプラグインのライセンスは本体と同一ではなく、公式配布の条件がOSI承認のオープンソースライセンスであること（MITは推奨の位置づけ）とされているため、Apache License 2.0などが混在します。再配布を伴う使い方をするなら、個々のプラグインの表記を確認してください。「Jenkinsは無料か」という問いへの答えは、利用するだけならイエスです。

ただし、無料なのはソフトウェアだけです。実際に発生する費用は、常時起動しておくサーバーの利用料、JDKとプラグインを更新し続ける運用工数、そしてビルドが重くなったときに追加するエージェント機の台数に移ります。とくに運用工数は見落とされがちで、後述するJava 17の打ち切りのような破壊的変更が来ると、その対応時間が丸ごとコストになります。

商用サポートを求める場合はCloudBees CIという商用製品が存在しますが、価格は公開されておらず、問い合わせと無料トライアルの導線しかありません。予算を組む段階で見積もりを取る必要があります。

動作要件とリリースラインの選択基準

2026年8月時点の最新版は、LTSが2.568.1（2026年7月8日公開）、週次リリースが2.575（2026年7月28日公開）です。導入前に必ず確認すべきなのはJavaのバージョンで、公式のLTSチェンジログには「Java 21 or Java 25 are required to run Jenkins 2.568.1. Java 17 is not supported with Jenkins 2.568.1 and later.」と記載されています。この打ち切りが始まった境界はLTS 2.555.1です。Java 17で運用中の既存環境は、Jenkinsを上げる前にJDKを入れ替えないとサービスが起動しません。JDKの入手元とサポート期限の考え方はOpenJDKの商用利用とライセンスの整理にまとめています。

リリースライン	最新版（2026年8月時点）	更新の間隔	入る変更	向く用途
LTS（安定版）	2.568.1	12週ごと	修正のみ	業務のビルド基盤
weekly（週次）	2.575	毎週	新機能と修正	新機能検証・プラグイン開発

LTSのベースラインは12週ごとにコミュニティの合意で選ばれ、その後は機能追加を止めて修正だけを受け取ります。業務で使うサーバーならLTS一択で、weeklyを選ぶ理由は「まだLTSに入っていない機能を前提にプラグインを開発・検証する」場合に限られます。

OS別のインストール手順

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

公式リポジトリを登録してaptで入れる方法が標準です。JavaはJenkins本体には同梱されないため、先に導入します。

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に読み替えます。1行目のmkdirは、鍵の置き場所である/etc/apt/keyringsを持たないディストリビューションでも手順が止まらないようにするためのものです。インストールが終わるとJenkinsはsystemdのサービスとして登録され、8080番ポートで待ち受けます。

WindowsへのMSIインストール

Windowsは公式ダウンロードページのMSIインストーラーを使います。ウィザードで指定するのは、インストール先（既定はC:\Program Files\Jenkins）、Jenkinsサービスを動かすアカウント、待ち受けポート、Javaのインストール先の4点です。

サービス実行アカウントはLocalSystemか任意のドメインユーザーを選べます。ドメインユーザーを指定した場合は「Test Credentials」ボタンで資格情報が通るか確認できます。
ポートは「Test Port」ボタンで空きを判定できるため、8080が他のアプリケーションと衝突している環境ではここで別番号に変えておくのが安全です。
Javaのディレクトリはインストーラーが自動検出して初期値を埋めます。Java 17しか入っていないマシンでは、この時点で条件を満たさないため先にJDKを更新します。

完了するとJenkinsはWindowsサービスとして常駐し、サーバーの再起動後も自動で立ち上がります。

Dockerコンテナでの起動

評価や検証が目的なら、コンテナで動かすのが後片付けまで含めて最短です。公式ドキュメントはjenkins/jenkins:2.568.1-jdk21をベースイメージとして案内しています。

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

8080がWeb画面、50000がエージェントからの接続を受ける口です。設定とジョブ履歴はすべて/var/jenkins_home配下に保存されるため、ここをボリュームにしておかないとコンテナを作り直した瞬間に消えます。--restart=on-failureを付けておくと、ホストを再起動してもコンテナが復帰します。なお公式手順はこれに加えて、Jenkinsのジョブからdockerコマンドを実行できるようdocker:dindのサイドカーを同じDockerネットワーク上で併走させる構成を案内しています。コンテナをビルドするパイプラインを組むなら、そちらに合わせてください。

初回起動後のセットアップウィザード

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

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

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

1行目がaptで入れた場合、2行目がDockerで起動した場合です。コンテナ内のパスはホストからは直接読めないため、docker execを通します。Windowsで既定の場所に入れた場合はC:\Program Files\Jenkins\secrets配下の同名ファイルにあります。ファイルが見当たらないときは、Jenkinsホームディレクトリのjenkins.err.logにも同じ文字列が出力されています。

解除後に出るのがプラグインの選択画面で、「Install suggested plugins」と「Select plugins to install」の2択です。最初の構築なら前者で問題ありません。Git連携やパイプライン実行など、後続の手順で必要になるものが一括で入ります。個別選択は、入れるプラグインを社内で統制している場合の選択肢です。

最後に管理者ユーザーを作成して保存すると、初期パスワードは無効になり、以降は作成したアカウントでログインします。

プラグインの追加と更新で気をつける点

ウィザードを抜けた後にプラグインを足すときは、管理画面の「Manage Jenkins（Jenkinsの管理）」から「Plugins」を開きます。Availableタブで名前を検索してチェックを入れ、「Install without restart」を押せば、多くのプラグインは再起動なしでそのまま使えます。導入済みの一覧と無効化はInstalledタブ、更新はUpdatesタブで扱います。

注意が要るのは更新のほうです。Updatesタブからの適用は「Download now and install after restart」となり、反映にJenkinsの再起動を伴います。さらにプラグインは互いに依存関係を持ち、更新センターから依存先も自動で引き込まれるため、一括更新でジョブの挙動が変わることがあります。実行前にJENKINS_HOME（aptなら/var/lib/jenkins、Dockerなら/var/jenkins_home）をバックアップしておけば、切り戻しが数分で済みます。

なお、アンインストールについては他のプラグインの依存先になっていないものだけをJenkinsが判別するため、依存関係を壊す削除は画面上でブロックされます。

最初のジョブ作成とJenkinsfileでのパイプライン化

Jenkinsのジョブには、画面上のフォームで設定を完結させるFreestyleと、処理内容をコードとして書くPipelineの2種類があります。動作を確かめるだけならFreestyleが早いものの、実運用ではPipelineを選んでください。設定がリポジトリ内のJenkinsfileに残るため、変更履歴が追え、サーバーを作り直しても同じジョブを復元できます。

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

この宣言的（Declarative）記法はGroovyを土台にしており、条件分岐や共通処理の切り出しではGroovyの文法がそのまま効いてきます。postブロックのjunitはテスト結果のXMLを取り込む指定です。

ジョブを保存して実行すると、画面左のビルド履歴に実行が1件ずつ積まれ、成功と失敗が色で区別されます。原因を追うときはそこから各ビルドを開き、コンソール出力でシェルコマンドの標準出力とエラーを確認します。上のようにjunitを書いておくとテスト結果のページが増え、どのテストがいつから落ち始めたかを履歴で追えるようになります。

リポジトリ側との接続でつまずきやすいのはWebhookとクレデンシャルの扱いで、自前のGitサーバーと組み合わせる場合の具体例はGitBucketとJenkinsを連携させる手順で確認できます。

Jenkinsを選ぶべきでない場面

Jenkinsは万能ではありません。次のどれかに当てはまるなら、導入しないほうが結果的にうまくいきます。

サーバーの更新を継続的に見る担当者を置けない：Jenkinsはプラグインの更新が止まると脆弱性が残り、今回のJava 17打ち切りのような破壊的変更にも自力で追随する必要があります。放置されたJenkinsは、CIサーバーではなく攻撃対象です。
ビルド対象がクラウド上のコンテナだけで完結する：オンプレの資産や特殊なデバイスに触る要件がないなら、サーバー維持費と工数を負担する理由がありません。GitHub ActionsやCircleCIのほうが立ち上がりも速く済みます。
Kubernetes前提でパイプラインを組みたい：Jenkinsをコンテナ環境に載せることはできますが、はじめからKubernetesのリソースとして動くよう設計されたTektonのようなフレームワークのほうが素直に噛み合います。

逆に、社内ネットワークからしか到達できない機器やライセンスサーバーを使うビルドがあるなら、セルフホストできるJenkinsが今も最も確実な選択肢です。組織としてどこまで自動化を持つかという判断軸はDevOpsの実践と導入判断と合わせて考えると整理しやすくなります。

導入直後につまずきやすい設定

初期構築でつまずきやすいのは、次の3点です。

8080番の衝突：既存のアプリケーションサーバーと重なると起動に失敗します。Windowsのインストーラーであれば導入時に「Test Port」で空きを確認できるので、その場で別番号に変えておきます。
Javaのバージョン不一致：Java 17の環境にLTS 2.555.1以降を入れると、公式が明示しているとおりJenkinsは起動しません。ログを読む前に、Jenkinsが参照しているJDKのバージョンを確認してください。
Jenkins URLの未設定：リバースプロキシの配下に置くと、システム設定のJenkins URLを直さない限り通知メールやWebhookに載るリンクがlocalhostのまま送られます。

よくある質問

Jenkinsは無料で使えますか？

Jenkins本体はMITライセンスのオープンソースで、無償です。ユーザー数やビルド回数による課金もありません。公式配布のプラグインもすべてオープンソースライセンスで提供され、追加料金はかかりません。費用が発生するのはサーバーの利用料と運用工数で、商用サポート付きのCloudBees CIは別製品として提供されており、価格は問い合わせが必要です。