Jenkins

この用語をシェア

Jenkinsとは

Jenkins（ジェンキンス）は、オープンソースのCI/CD（継続的インテグレーション/継続的デリバリー）プラットフォームです。ソフトウェア開発プロセスにおけるビルド、テスト、デプロイメントの自動化を実現し、開発チームの生産性向上とソフトウェア品質の向上を支援します。

Jenkinsの前身は、Sun Microsystems（後にOracle）の社員だったKohsuke Kawaguchi氏が開発した「Hudson」です。Oracleとのライセンス・商標を巡る方針対立をきっかけに、2011年にコミュニティが「Jenkins」としてプロジェクトをフォークし、以後はEclipse Foundation傘下のオープンソースプロジェクトとして開発が続けられています。この経緯があるため、古い技術記事や資格試験の教材では今も「Hudson」という名称が引き合いに出されることがありますが、実務で新規に採用されるのはほぼJenkinsです。

Java（JVM）上で動作し、Windows・macOS・Linuxなど主要なOSで稼働するほか、公式のDockerイメージ（jenkins/jenkins）も提供されているため、コンテナ環境への導入も容易です。GitHub ActionsやCircleCIのような「クラウド上でホスティングされるCI/CDサービス」とは異なり、Jenkinsは自分たちのサーバー・クラウド環境にインストールして運用する「自己ホスト型（セルフホスト）」のツールである点が最大の特徴です。そのため設定の自由度が高い反面、サーバーの構築・保守・セキュリティ対応は利用者側の責任になります。

Jenkinsの仕組み・アーキテクチャ

コントローラーとエージェントによる分散アーキテクチャ

Jenkinsは、ジョブの管理・スケジューリングを担うコントローラー（旧称：マスター。近年のJenkins公式ドキュメントでは差別的表現の見直しにより「マスター」から「コントローラー」への呼称変更が進められています）と、実際にビルドやテストを実行するエージェント（旧称：スレーブ／ノード）が連携して動作します。コントローラーはWeb UIの提供・ジョブ設定の保存・ビルドのキュー管理を行い、実際のビルド処理はSSHやJNLP（Java Network Launch Protocol）経由で接続されたエージェント上で実行されます。この分離により、Windows・Linux・macOSなど異なる環境でのビルドを1つのJenkinsコントローラーから統括したり、ビルド負荷を複数台のマシンに分散させたりできます。

ジョブ実行のライフサイクル

典型的なジョブの実行は、おおむね次の流れで進みます。

1. トリガー：Gitリポジトリへのpush（Webhook）、定期実行（cron形式のスケジュール）、他ジョブからの呼び出し、手動実行のいずれかでビルドが開始される
2. ワークスペースの準備：エージェント上にソースコードをチェックアウトし、作業ディレクトリ（ワークスペース）を用意する
3. ステージの実行：Pipelineで定義されたstage（Build、Test、Deployなど）を順番に、あるいは並列に実行する
4. 成果物・レポートの保存：ビルド成果物（アーティファクト）、テスト結果、カバレッジレポートなどをコントローラー側に保存する
5. 通知：成功・失敗の結果をメール、Slack、Teamsなどに通知する

Freestyleジョブと Pipelineジョブの違い

Jenkinsには大きく分けて2つのジョブ形式があります。GUI上でビルドステップをフォーム入力していくFreestyleジョブは直感的に扱える反面、設定内容がJenkins内部のXMLとして保存されるため、バージョン管理や差分レビューが難しいという課題があります。一方、Pipelineジョブはビルド手順を「Jenkinsfile」というコードで記述するため、Gitでバージョン管理でき、レビューや再利用がしやすくなります。現在の実務では、新規に構築する場合はPipelineジョブを選ぶのが一般的です。

Jenkinsの主要機能

継続的インテグレーション（CI）

• 自動ビルド：コードの変更を検知して自動的にビルドを実行
• 自動テスト：単体テスト、統合テストの自動実行
• コード品質チェック：静的解析、カバレッジ測定の自動化
• 通知機能：ビルド結果のメール、Slack通知

継続的デリバリー（CD）

• 自動デプロイメント：テスト通過後の本番環境への自動展開
• 環境管理：開発、ステージング、本番環境の管理
• ロールバック：問題発生時の自動復旧機能
• リリース管理：バージョン管理とリリースノート生成

Jenkins Pipeline

Pipeline as Code

Jenkinsfileを用いて、ビルドプロセスをコードとして管理できます。Jenkinsfileはリポジトリのルートに置き、Gitでソースコードと一緒にバージョン管理するのが一般的です。これにより「どのブランチでどのビルド手順が使われたか」がコミット履歴から追跡でき、レビューやロールバックも容易になります。

pipeline {
    agent any
    environment {
        IMAGE_NAME = 'myapp'
    }
    stages {
        stage('Build') {
            steps {
                sh 'npm install'
                sh 'npm run build'
            }
        }
        stage('Test') {
            steps {
                sh 'npm test'
            }
        }
        stage('Deploy') {
            when {
                branch 'main'
            }
            steps {
                sh 'docker build -t ${IMAGE_NAME} .'
                sh 'docker push ${IMAGE_NAME}:latest'
            }
        }
    }
    post {
        failure {
            slackSend(message: "Build failed: ${env.JOB_NAME} #${env.BUILD_NUMBER}")
        }
    }
}

Declarative Pipeline と Scripted Pipeline

Jenkinsfileの書き方には2種類の記法があります。上記のようなpipeline { ... }ブロックで定義するDeclarative Pipelineは構文が定型化されており、初学者でも読み書きしやすく、現在推奨されている書き方です。一方、Groovyのスクリプトとして自由に処理を書けるScripted Pipelineは、条件分岐やループを多用する複雑な処理を柔軟に書ける反面、可読性やメンテナンス性が下がりやすい傾向があります。

node {
    stage('Build') {
        sh 'npm install && npm run build'
    }
    stage('Test') {
        try {
            sh 'npm test'
        } catch (err) {
            currentBuild.result = 'UNSTABLE'
        }
    }
}

実務では、まずDeclarative Pipelineで基本のフローを組み、どうしても複雑な分岐が必要な部分だけscript { ... }ブロックでGroovyコードを埋め込む、というハイブリッドな書き方が定石です。

よく使うPipeline構文

主要コンポーネント

Jenkinsマスター

• Webインターフェース：管理用のダッシュボード
• ジョブ管理：ビルドジョブの作成・設定・実行
• スケジューラー：ジョブの実行タイミング制御
• プラグイン管理：機能拡張のためのプラグイン管理

Jenkinsエージェント（ノード）

• 分散実行：複数のマシンでの並列ビルド
• 環境分離：異なるOS・環境でのテスト実行
• リソース最適化：ビルド負荷の分散
• 動的プロビジョニング：Kubernetesプラグインなどを使い、ビルド時だけコンテナとしてエージェントを起動し終了後に破棄する構成も一般的

Blue Ocean

Jenkinsの新しいUIエクスペリエンスを提供するプラグインです。従来の管理画面よりも視覚的にパイプラインの実行状況を把握しやすくすることを目的に開発されました。

• 直感的なUI：視覚的に分かりやすいパイプライン表示
• パイプライン編集：ドラッグ&ドロップでの設定
• ブランチ管理：Git フローとの統合
• リアルタイム表示：ビルド進行状況の可視化

なお、Blue Oceanは近年新機能の追加ペースが緩やかになっており、開発の重心はDeclarative Pipelineの標準UI（Stage View）やPipeline構文の可視化機能に移ってきているとされます。新規導入時は、Blue Oceanを前提にするのではなく、標準UIでの運用も想定しておくと安全です。

豊富なプラグインエコシステム

Jenkinsの大きな強みは、公式のプラグインセンター（Jenkins Plugin Index）で公開されている膨大な数のプラグインです。ソースコード管理、ビルドツール、通知、セキュリティ、UIなど多岐にわたる分野をカバーしており、必要な機能をプラグインの組み合わせで実現できます。

人気のプラグイン

一方でプラグイン依存の多さは、後述するデメリットの一つでもあります。導入時は「本当に必要な機能か」を精査し、使わなくなったプラグインは定期的に棚卸しすることが望まれます。

実際の運用例

Webアプリケーション開発の例

マルチブランチ・モノレポでの活用例

複数のフィーチャーブランチが並行して動くプロジェクトでは、「Multibranch Pipeline」というジョブ形式を使うことで、Jenkinsが対象リポジトリのブランチを自動検出し、ブランチごとにJenkinsfileに基づくパイプラインを自動生成できます。プルリクエストが作成されるたびに、そのブランチ用のビルド・テストを自動実行し、結果をGitHubやBitbucketのステータスチェックに反映する、という運用が一般的です。また、複数のサービスを1つのリポジトリで管理する「モノレポ」構成では、変更のあったディレクトリだけをビルド対象にする（changeset条件などで絞り込む）ことで、ビルド時間を抑える工夫もよく行われます。

メリットとデメリット

メリット

• 開発効率向上：手作業の削減と自動化による時間短縮
• 品質向上：自動テストによる早期バグ発見
• リスク軽減：一貫したビルド・デプロイプロセス
• コスト削減：オープンソースで追加費用なし（サーバー費用・運用工数は別途必要）
• 柔軟性：豊富なプラグインによる機能拡張、オンプレミス・クラウドを問わず構築可能
• 実績・情報量：長年使われてきたツールのため、トラブルシューティングの情報やナレッジがコミュニティに蓄積されている

デメリット・注意点

• 運用負荷：GitHub Actionsなどのマネージド型CIと異なり、サーバーの構築・OSアップデート・スケーリングを自前で行う必要がある
• プラグイン依存によるリスク：機能追加のたびにプラグインを入れがちで、プラグイン同士の互換性問題やアップデート時の不具合が発生しやすい
• UIの古さ：Blue Oceanなどの改善はあるものの、標準UIは他社の新しいCI/CDサービスと比べてデザインが古いと感じられることがある
• 初期学習コスト：Groovyベースのpipeline構文、認証・権限設計など、使いこなすまでの学習コストがある
• セキュリティ対応の責任：Jenkins本体やプラグインの脆弱性情報を継続的に追い、自分たちでパッチ適用する運用体制が必要

混同されやすい用語・類似技術との違い

Jenkinsは「CI/CDツール」の代名詞的な存在であるため、類似の概念やツールと混同されがちです。主な違いを整理します。

Jenkins と GitHub Actions・GitLab CI/CD・CircleCIの違い

大まかには、「サーバーを自分たちで持ち、設定の自由度を優先したいならJenkins」「サーバー管理をなくし、素早く始めたいならGitHub Actionsなどのマネージド型」という住み分けで語られることが多い技術です。

Jenkins と Jenkins X の違い

「Jenkins X」はJenkinsとは別のプロジェクトで、Kubernetesネイティブなクラウドアプリケーション向けにCI/CDを再設計したツールです。名前は似ていますが、内部の仕組みや設定方法は大きく異なり、既存のJenkinsfileや設定資産をそのまま流用できるわけではない点に注意が必要です。

Jenkins と Hudson の違い

前述の通り、HudsonはJenkinsの前身にあたるプロジェクトです。2011年のフォーク後、Hudson自体もEclipse Foundationで一時開発が続けられていましたが、現在主流のオープンソースCI/CDツールとして広く使われているのはJenkinsであり、新規導入でHudsonを選ぶケースはほぼありません。

CI/CDという概念とJenkinsという製品の違い

CI/CDは「継続的インテグレーション／継続的デリバリー（デプロイ）」という開発手法・概念を指す言葉であり、Jenkinsはその概念を実現するための具体的な製品（実装）の一つに過ぎません。CI/CDを実現するツールにはJenkins以外にもGitHub Actions、GitLab CI/CD、CircleCIなど多数存在するため、「JenkinsとCI/CDは同じもの」ではなく「JenkinsはCI/CDを実現するツールの一つ」という関係で理解するのが正確です。

学習・導入のポイント

導入の基本ステップ

実務でJenkinsを導入する際は、次のような手順で進めるのが定石です。

1. 環境構築：まずはDockerで手早く動作確認するのが定石です。docker run -p 8080:8080 jenkins/jenkins:lts のようにコンテナを起動し、ブラウザから初期セットアップを行います
2. 基本ジョブの作成：GitリポジトリをつないだPipelineジョブを1つ作り、簡単なビルド・テストを自動化してみる
3. プラグインの最小構成での導入：Git、Pipeline、必要なビルドツール（Docker、Maven、Gradleなど）関連のプラグインから始め、必要になった段階で追加していく
4. 認証・権限設計：Matrix Authorization Strategyなどのプラグインで、ジョブごとの実行権限やチームごとのアクセス範囲を設計する
5. Configuration as Code（JCasC）の活用：本体設定をYAMLでコード化し、Jenkinsサーバー自体を使い捨て・再構築しやすくする

基本的なコマンド・操作例

# Jenkins CLIツール（jenkins-cli.jar）をダウンロード
curl -O http://localhost:8080/jnlpJars/jenkins-cli.jar

# ジョブの一覧を表示
java -jar jenkins-cli.jar -s http://localhost:8080/ list-jobs

# 指定したジョブのビルドを手動実行
java -jar jenkins-cli.jar -s http://localhost:8080/ build my-job

# Jenkinsfileの構文チェック（linter）
curl -X POST -F "jenkinsfile=

実務ワークフローへの組み込み方

実務では、Jenkinsを単独で使うのではなく、Gitのブランチ戦略（例：GitHub Flow、GitFlow）と組み合わせて運用するのが一般的です。mainブランチへのマージをトリガーに本番デプロイのPipelineを走らせ、フィーチャーブランチへのpushではビルドとテストのみを行う、といった形でブランチごとに実行内容を出し分けます。また、テスト・静的解析・セキュリティスキャンなど複数のチェックをすべて1つのstageに詰め込まず、parallel構文で並列化することで、Pipeline全体の実行時間を短縮する工夫も定石とされています。

他の観点

• 基礎知識：CI/CDの概念理解が重要
• セキュリティ：認証・認可の適切な設定、クレデンシャルの安全な管理
• スケーラビリティ：負荷に応じたエージェント構成、動的プロビジョニングの検討
• 運用監視：ビルド履歴とパフォーマンス監視、ディスク容量・古いビルドのクリーンアップ設定

2025〜2026年の最新動向

Jenkinsは長年運用されてきた成熟したツールであるため、劇的な機能追加よりも「既存の運用をより安全・効率的にする」方向への改善が続いているとされます。具体的には、次のような傾向が挙げられます。

• Configuration as Code（JCasC）の定着：Jenkins本体の設定をYAMLでコード管理し、サーバー障害時やスケールアウト時に設定込みで素早く再構築する運用が一般化しつつあります
• コンテナ・Kubernetes連携の深化：Kubernetesプラグインを用いて、ビルドのたびに使い捨てのエージェントPodを起動する構成が、オンプレミス・クラウドを問わず一般的になってきています
• プラグインのセキュリティ対応強化：プラグイン数の多さがセキュリティリスクの温床になりやすいことを受け、Jenkinsプロジェクト側でも脆弱性情報の公開・修正対応のプロセス整備が続けられています。運用担当者側も、使っていないプラグインの棚卸しや定期的なアップデートの重要性が改めて指摘されています
• マネージド型CI/CDとの併用・使い分け：GitHub ActionsやGitLab CI/CDといったマネージド型サービスの普及により、新規プロジェクトではそちらを選ぶケースも増えていますが、既存の大規模なオンプレミス環境やレガシーシステムとの連携が必要な現場では、引き続きJenkinsが選ばれる傾向にあります
• LTS（長期サポート）版を中心とした運用：週次でリリースされる最新版ではなく、安定性を重視したLTS版を選んで運用するのが実務では一般的です

いずれも「Jenkinsが不要になる」という方向の変化ではなく、「既存のJenkins環境をどう安全・効率的に維持するか」「新規プロジェクトではマネージド型CI/CDとどう使い分けるか」という観点の議論が中心になっている点が特徴です。

この用語についてもっと詳しく

Jenkinsに関するご質問や、システム導入のご相談など、お気軽にお問い合わせください。

よくある質問（FAQ）

関連技術との連携・関連用語

• Git：ソースコード管理システム。JenkinsはGitリポジトリの変更を検知してビルドをトリガーする
• Docker：コンテナ化されたビルド環境。ビルドやデプロイ先のコンテナイメージ作成にも利用
• Kubernetes：コンテナオーケストレーション基盤。Jenkinsのビルドエージェントを動的に起動する用途で連携
• GitHub Actions：GitHub統合型のマネージドCI/CD。Jenkinsとしばしば比較検討される
• GitLab：GitLab CI/CDを内包するプラットフォーム。JenkinsからGitLab CI/CDへの移行が検討されることもある
• CircleCI：クラウド型のマネージドCI/CDサービス。導入の手軽さで比較されることが多い
• CI/CD：継続的インテグレーション・継続的デリバリーという開発手法そのものを指す概念。Jenkinsはこれを実現する製品の一つ
• プルリクエスト：Multibranch Pipelineと組み合わせ、プルリクエストごとに自動ビルド・テストを実行する運用と関連

外部リンク・参考資料

• Jenkins公式サイト：ダウンロード、最新情報、コミュニティ情報
• Jenkins公式ドキュメント：インストール手順からPipeline構文リファレンスまでの一次情報
• Pipeline構文リファレンス（公式）：Declarative／Scripted Pipelineの構文詳細
• Jenkins Plugin Index：公式プラグインの検索・一覧ページ