JenkinsとBlue Oceanの導入・設定完全ガイド（2025/2026年版）

前提条件と環境設定

本章では、Jenkins と Blue Ocean を本番環境で安定運用するために最低限必要なソフトウェアバージョン、ハードウェアスペック、および推奨される OS／コンテナイメージをまとめます。「必須」か「推奨」かの違いを明確にし、根拠となる公式ドキュメントへのリンクも添付しています。

Jenkins 本体・Java のバージョン要件（2025‑2026 年）

Jenkins LTS 2.462 は 2025 年 10 月にリリースされましたが、Java 17 が必須になるのは LTS 2.464 以降の将来リリースが対象であることが公式に示されています（※2026‑07‑05 時点）。したがって、現行の 2.462 でも Java 11／Java 17 のいずれかで動作しますが、長期的な保守性を考慮して Java 17 LTS を採用することを推奨します。

※1：CPU・メモリは Jenkins 本体＋プラグイン群（特に Blue Ocean）が要求する 一般的な 推奨値です。実際の負荷はジョブ数やビルド時間に依存しますので、本番環境ではロードテストを実施してください。

Docker での推奨起動例

以下は公式 jenkins/jenkins:lts-jdk17 イメージを利用した最小構成です。Java 17 が組み込まれているため、別途 JDK をインストールする手間が省けます。

ポイント：JAVA_OPTS でヒープ上限を設定し、メモリ不足による OOM の予防策としています。

Blue Ocean プラグインの導入と基本設定

Blue Ocean は Jenkins の UI を刷新し、パイプラインの可視化・操作性を向上させます。本章では 公式プラグインマネージャー と CLI の両方から安全にインストールする手順、および運用時に推奨される設定項目をご紹介します。

インストール手順（GUI と CLI）

まずは「Blue Ocean」系統プラグインの最新版を取得し、依存関係と再起動タイミングを自動で処理させます。以下のステップはそれぞれ 導入前に必ず Jenkins が稼働中であること を確認してください。

1. Web UI（管理画面）からインストール
2. 「Manage Jenkins → Manage Plugins」へ移動。
3. 「Available」タブで Blue Ocean と検索し、チェックを入れる。

4. 依存プラグイン（例：pipeline-model-definition、workflow-aggregator）が自動的に選択されるので 「Download now and install after restart」 をクリック。

5. CLI からのインストール（スクリプト化推奨）
   bash
# Jenkins が起動中であることを前提に実行
java -jar jenkins-cli.jar -s http://localhost:8080/ install-plugin blueocean
java -jar jenkins-cli.jar -s http://localhost:8080/ safe-restart

6. install-plugin はプラグインの依存関係も自動解決します。
7. safe-restart により、実行中ジョブが完了したあとで安全に再起動します。

注意：Jenkins のバージョンとプラグイン互換性は公式「Plugin Compatibility Matrix」(https://plugins.jenkins.io/blueocean) を必ず確認してください。

推奨設定項目（UI テーマ・ログ保持など）

Blue Ocean の UI カスタマイズとビルド履歴の保存期間は、可視性と保守性のバランスを取る上で重要な要素です。以下は実務で広く採用されている設定例です。

設定は 「Manage Jenkins → Configure System」 から行い、変更後は 「Apply」 を忘れずにクリックしてください。

認証情報とソースコード管理サービス連携

Blue Ocean がリポジトリを自動検出しパイプラインを生成するには、GitHub・GitLab などの SCM と認証情報が正しく設定されている必要があります。ここでは 最新の OAuth フロー（GitHub）と PAT（GitLab） の具体的な手順に加え、将来的な変更への備えとして公式ドキュメントへのリンクを掲載します。

GitHub OAuth 連携（2026 年時点）

GitHub が推奨する認証方式は OAuth App です。スコープやリダイレクト URL の設定ミスは「認証失敗」の典型的原因になるため、以下の手順を正確に実施してください。

1. GitHub にログインし、Settings → Developer settings → OAuth Apps → New OAuth App を開く。
2. 必須項目を入力（※全て英字で統一）
3. Application name：Jenkins Blue Ocean（任意）
4. Homepage URL：http://your-jenkins/
5. Authorization callback URL：http://your-jenkins/blue/oauth2/callback（必ず正確に）
6. 作成後に表示される Client ID と Client Secret をメモ。
7. Jenkins の 「Credentials → System → Global credentials (unrestricted)」 で、種別 Secret text に Client Secret を保存し、ID は github-oauth-secret など分かりやすく命名。
8. Blue Ocean の設定画面（左上メニューの Blue Ocean → GitHub）で、先ほど作成した Credential ID を選択する。

公式ドキュメント：https://docs.github.com/en/developers/apps/building-oauth-apps/authorizing-oauth-apps
将来的にスコープが追加・変更される可能性があるため、導入時点で最新の GitHub Docs を必ず確認してください。

GitLab アクセストークン（PAT）登録

GitLab では Personal Access Token が最もシンプルかつ安定した認証手段です。OAuth がサポートされているエディションでも、CI 用に PAT を利用することが推奨されています。

1. GitLab にログインし、User Settings → Access Tokens へ移動。
2. トークン名（例：jenkins-blue-ocean）と有効期限を設定し、スコープは api と read_repository を必ず選択。
3. 「Create personal access token」ボタンでトークン文字列が表示されるのでコピー。※画面遷移後は再取得不可です。
4. Jenkins の 「Credentials → System → Global credentials」 で Secret text として保存し、ID は gitlab-pat に設定。
5. Blue Ocean の SCM 設定で GitLab アカウントを追加し、先ほどの Credential ID を指定。

公式ドキュメント：https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html
スコープや有効期限はセキュリティポリシーに合わせて定期的に見直してください。

パイプライン作成：GUI ウィザード と Jenkinsfile の比較

Blue Ocean は 「New Pipeline」ウィザード によって UI だけで Declarative Jenkinsfile を自動生成できます。一方、コードベースとしての Jenkinsfile はバージョン管理と高度なカスタマイズに不可欠です。本章では両者の作成フローを比較し、実務で使い分けるポイントを示します。

GUI ウィザードによるパイプライン生成

このウィザードは 「SCM が認証済み」 という前提条件が整っていれば数クリックで完了します。以下の手順は初心者向けの標準フローです。

1. Jenkins にログイン後、左上メニューの Blue Ocean をクリック。
2. 「Create a new pipeline」ボタンを選択し、接続済み SCM（GitHub／GitLab）から対象リポジトリを選ぶ。
3. 表示されたブランチ一覧から main（または master）を指定。
4. 「Jenkinsfile not found」 が表示されると、ウィザードが自動的に Declarative テンプレート を生成し、プレビュー画面で内容を確認できる。
5. 必要に応じてステージ名や環境変数を UI 上で追加・編集し、「Create pipeline」をクリック。

生成されたパイプラインは即座に Blue Ocean のタイムライン上に表示され、最初のビルドが自動的に走ります。

Declarative Jenkinsfile の構造と GUI エディタでの編集

ウィザードで作成した Jenkinsfile は pipeline {} ブロックを中心とした Declarative 形式です。このコードは Git リポジトリ内に保存し、CI/CD の「コードとしてのパイプライン」を実現します。

GUI エディタでの編集手順

1. パイプライン実行画面右上の 「Edit Pipeline」 アイコン（鉛筆）をクリック。
2. テキストエリアが開くので、上記サンプルをベースにステージや環境変数を追加・修正。
3. 編集後は Save → Run を選択すると、変更内容が即座にビルドへ反映されます。

マルチブランチ / Pull Request ビューの有効化

• 「Branch Sources」設定で Discover pull requests from origin をオンにすると、PR が自動的に Blue Ocean の Pull Requests タブに表示されます。
• 各 PR に対して独立した Jenkinsfile が存在すれば、マージ前にビルド結果をレビューできます。

ビルド実行・トラブルシューティング・ベストプラクティス

Blue Ocean の UI だけで リアルタイムログの閲覧 と 失敗ステージの再実行 が可能です。本章ではその操作方法と、運用時に頻出するエラー例、およびパイプラインを安全に管理するベストプラクティスをまとめます。

リアルタイムログ表示とステージ単位の再実行

Blue Ocean のタイムラインは WebSocket により Jenkins のコンソール出力と同期しています。以下の操作でビルド結果を効率的に確認できます。

• リアルタイム表示：パイプライン一覧から対象ビルドをクリックすると、ステージごとのタイムラインが左側に展開され、右側にログが流れます。エラー行は自動で赤字ハイライト。
• ステージ再実行：失敗したステージの右上にある 「▶︎」（再実行）アイコンをクリックすると、そのステップだけが再度走ります。環境変数やワークスペースは前回と同じものが利用されます。

この機能は長時間走るテストやデプロイ作業の一部だけをリトライしたいシナリオで特に有用です。

よくあるエラー例と対処法

各エラーの詳細は Jenkins の System Log（Manage Jenkins → System Log）で確認できます。ログレベルを FINE に上げると、プラグインロード時の依存関係情報も取得可能です。

パイプライン更新・バージョン管理のベストプラクティス

1. Git で Jenkinsfile を単体管理

2. 推奨リポジトリ構成例

   / (root)
├─ .jenkins/
│ └─ Jenkinsfile ← Declarative 定義
└─ src/ …

3. Pull Request ベースのレビュー

4. 変更は必ず PR とし、Jenkinsfile の差分を CI（例：pipeline-linter-action）で自動検証。

5. タグ付けとリリース管理

6. 大幅なパイプラインロジックの更新時は pipeline-vX.Y.Z タグを作成し、マルチブランチジョブでもタグブランチをビルド対象に含める。

7. バックアップ戦略

8. Jenkins ホームディレクトリ（/var/jenkins_home）は 定期スナップショット を取得し、認証情報・プラグインリストの復元を保証する。

9. Credential の暗号化キーは別途安全に保管（例：HashiCorp Vault）。

10. 変更履歴の可視化

11. Blue Ocean の “Pipeline Activity” タブでジョブごとの実行履歴とコミットハッシュを紐付け、リリースノート作成時に活用する。

まとめ

上記ポイントを踏まえて環境構築・運用すれば、Blue Ocean を活用した可視性の高い CI/CD パイプラインが安定的に提供できるはずです。導入前後は必ず公式リリースノートと外部サービス（GitHub/GitLab）の最新ドキュメントを参照し、バージョンアップやスコープ変更に備えてください。

参考リンク

本稿は 2026‑07‑05 に最終更新しました。最新情報は各公式サイトをご確認ください。