# CI/CDパイプライン面接質問 2026年版：GitHub Actions・GitLab CI・Jenkins徹底解説

> 2026年のDevOps面接で頻出するCI/CDパイプラインの質問と回答を解説。GitHub Actions、GitLab CI、Jenkinsの実践的なコード例とセキュリティ対策を網羅。

- Published: 2026-05-18
- Updated: 2026-05-18
- Author: SharpSkill
- Tags: devops, ci-cd, github-actions, gitlab-ci, jenkins, interview
- Reading time: 12 min

---

2026年、CI/CDパイプラインは現代のソフトウェア開発において不可欠な基盤技術となっています。GitHub Actionsはリポジトリとのシームレスな統合により急速に普及し、GitLab CIはプラットフォーム全体と密接に連携した統合ソリューションとして確固たる地位を築いています。そしてJenkinsは豊富なプラグインエコシステムを持つオープンソースツールとして、エンタープライズ環境で依然として重要な役割を果たしています。DevOpsエンジニアの技術面接では、これら3つのプラットフォームに関する実践的な知識が求められます。理論的な概念だけでなく、具体的な実装パターン、セキュリティのベストプラクティス、パフォーマンス最適化の手法まで、幅広い理解が必要です。本記事では、2026年の面接で実際に出題されている質問と回答を体系的に整理し、効果的な準備方法を提示します。

> **2026年の面接対策ポイント**
>
> 現在の採用市場では、単一のCI/CDツールに精通しているだけでは不十分です。GitHub Actions、GitLab CI、Jenkinsのアーキテクチャ上の違いを説明でき、特定のシナリオに最適なツールを根拠を持って提案できることが求められています。少なくとも2つのプラットフォームでの実務経験があると、選考において大きなアドバンテージになります。

## GitHub Actions：ワークフロー設計とMatrix Builds

GitHub Actionsは、イベント駆動型のワークフローモデルを採用しています。Git操作、スケジュール、外部Webhookなど多様なトリガーに応じてワークフローが実行されます。各ジョブは独立したVM上またはコンテナ内で動作し、複数のステップで構成されます。面接では、ジョブ間の依存関係制御、マトリクスビルド、環境保護の仕組みについて深い理解が問われます。

```yaml
# .github/workflows/ci.yml
name: CI Pipeline

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run lint

  test:
    needs: lint              # waits for lint to pass
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node: [20, 22]       # runs tests on both versions
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
          cache: npm
      - run: npm ci
      - run: npm test

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: production  # requires approval
    steps:
      - uses: actions/checkout@v4
      - run: ./deploy.sh
```

この構成における重要なポイントは複数あります。`needs`キーワードはジョブ間の実行順序を制御し、`lint`ジョブが成功した後にのみ`test`ジョブが実行されます。`strategy.matrix`は異なるNode.jsバージョンでの並列テストを可能にし、互換性の検証を自動化します。`environment: production`の設定により、デプロイ前に手動承認プロセスを要求できます。

面接でよく聞かれる質問の一つに、`if: github.ref == 'refs/heads/main'`と`if: github.ref == 'main'`の違いがあります。`github.ref`は完全なブランチパスを返すため、`refs/heads/`プレフィックスを含む完全な形式で記述する必要があります。この点を見落とすと、条件分岐が意図通りに機能しません。

Reusable Workflowsも頻出トピックです。組織全体で共有するワークフローテンプレートを定義し、複数のリポジトリから参照できます。セキュリティスキャンやデプロイメントゲートを一元管理することで、コードの重複を削減し、コンプライアンス要件への対応を効率化できます。`actions/setup-node`の`cache`パラメータによるキャッシュ機能は、`node_modules`をワークフロー実行間で再利用し、ビルド時間を大幅に短縮します。

実行コンテキスト（`github`、`env`、`secrets`、`steps`）にはワークフロー実行時のメタデータが格納されています。Expression構文`${{ }}`により、動的な値の計算や条件ロジックの記述が可能です。

## GitLab CI：ステージベースのパイプラインとArtifact管理

GitLab CIはステージベースのパイプラインモデルを採用しており、同一ステージ内のジョブは並列実行されますが、ステージ間は順次実行されます。これはGitHub Actionsの「デフォルトで並列、`needs`で制御」というモデルとは根本的に異なるアプローチです。

```yaml
# .gitlab-ci.yml
stages:
  - validate
  - test
  - deploy

variables:
  NODE_VERSION: "22"

lint:
  stage: validate
  image: node:${NODE_VERSION}
  cache:
    key: ${CI_COMMIT_REF_SLUG}
    paths:
      - node_modules/
  script:
    - npm ci
    - npm run lint

unit-tests:
  stage: test
  image: node:${NODE_VERSION}
  parallel:
    matrix:
      - NODE_VERSION: ["20", "22"]
  script:
    - npm ci
    - npm test
  artifacts:
    reports:
      junit: coverage/junit.xml
    expire_in: 7 days

deploy-production:
  stage: deploy
  image: alpine:latest
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual                   # manual gate
  environment:
    name: production
    url: https://app.example.com
  script:
    - ./deploy.sh
```

`rules`キーワードは、GitLab CI 14以降で従来の`only/except`モデルに代わる推奨構文です。ブランチ名、タグ、マージリクエストのステータス、カスタム変数に基づいて、ジョブの実行を細かく制御できます。`when: manual`と`rules`の組み合わせにより、本番デプロイに対する承認ゲートを実装できます。

ArtifactとCacheの違いは面接で特に注目される論点です。Cacheは`node_modules`などの依存関係を再利用してリビルド時間を最適化するための仕組みです。一方、Artifactはステージ間でデータを受け渡すための明示的な仕組みです。`reports`ブロックを使用すると、テストカバレッジやSASTスキャンの結果をGitLab UIに直接統合できます。`expire_in`ディレクティブは、大規模コードベースにおけるArtifactストレージの無制限な増大を防止します。

キャッシュキーにはブランチ固有の値（`${CI_COMMIT_REF_SLUG}`）を使用することが推奨されます。異なるブランチで並行実行されるパイプライン間でのレースコンディションを回避するためです。GitLab CI バージョン16以降では、`needs`キーワードによるDAG（有向非巡回グラフ）パイプラインがサポートされており、直接の依存関係が満たされていれば、前のステージ全体の完了を待たずにジョブを実行できます。この機能により、ステージベースパイプラインの見通しの良さと、的を絞った並列化によるパフォーマンス最適化を両立できます。

## Jenkins：Declarative PipelineとPluginエコシステム

2026年においても、Jenkinsは特に複雑なオンプレミス要件を持つエンタープライズ環境で広く使用されています。Declarative Pipeline構文は、Scripted Pipelineよりも構造的で保守しやすいため、現在のベストプラクティスとして定着しています。

```groovy
// Jenkinsfile
pipeline {
    agent any

    tools {
        nodejs 'node-22'       // configured in Jenkins Global Tool
    }

    environment {
        CI = 'true'
        DEPLOY_ENV = credentials('deploy-env-secret')
    }

    stages {
        stage('Install') {
            steps {
                sh 'npm ci'
            }
        }

        stage('Lint & Test') {
            parallel {             // parallel execution
                stage('Lint') {
                    steps {
                        sh 'npm run lint'
                    }
                }
                stage('Test') {
                    steps {
                        sh 'npm test'
                    }
                    post {
                        always {
                            junit 'coverage/junit.xml'
                        }
                    }
                }
            }
        }

        stage('Deploy') {
            when {
                branch 'main'
            }
            input {
                message 'Deploy to production?'
            }
            steps {
                sh './deploy.sh'
            }
        }
    }

    post {
        failure {
            mail to: 'team@example.com',
                 subject: "Build failed: ${env.JOB_NAME}",
                 body: "Check ${env.BUILD_URL}"
        }
    }
}
```

`agent`ディレクティブは、パイプラインの実行環境を定義します。`agent any`は利用可能な任意のエージェントを使用し、`agent { label 'linux' }`は特定のラベルを持つエージェントに限定します。コンテナベースのビルドには`agent { docker 'node:22' }`が適しており、Jenkinsサーバーへの恒久的なツールインストールなしに隔離された環境を提供します。

`tools`ブロックはJenkinsに登録されたツールインストールを参照します。これによりパイプライン定義が具体的なパスから切り離され、Node.js、Maven、JDKなどのバージョンを一元管理できます。`environment`ブロック内の`credentials`キーワードは、JenkinsのCredentialsをJenkinsfileにシークレットを公開することなく環境変数としてバインドします。

並列実行はステージ内の`parallel`ブロックで実現されます。GitHub ActionsやGitLab CIのMatrix Buildsとは異なり、各並列ブランチに対して明示的なステージ定義が必要です。`post`ディレクティブは、ビルドの結果に関わらず実行されるクリーンアップや通知のロジックを定義します。`always`、`success`、`failure`、`unstable`、`changed`の各条件を指定できます。

1,800以上のプラグインを擁するJenkinsのエコシステムは、DevOps領域のほぼすべてのツールとの連携を可能にします。Blue Ocean（モダンUI）、Pipeline Stage View（パイプライン可視化）、Configuration as Code（JCasC、宣言的Jenkins設定）は面接で頻繁に取り上げられるプラグインです。ただし、プラグインの管理には継続的なメンテナンスが必要であり、古いプラグインや互換性のないプラグインは障害の原因となります。

## セキュリティ対策：シークレット管理とサプライチェーン攻撃

2026年のCI/CD面接において、セキュリティに関する質問は最も重視されるテーマの一つです。SolarWindsやCodeCovの事例以降、ビルドパイプラインのサプライチェーン攻撃への対策は最優先事項となっています。

```yaml
# .github/workflows/secure.yml
steps:
  # Vulnerable: tag can be moved to malicious commit
  - uses: actions/checkout@v4

  # Secure: pinned to exact commit SHA
  - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
```

GitHub WorkflowsにおけるActionのSHAピンニングは、タグ名が悪意のあるコードにリダイレクトされるリスクを防止します。Dependabotがセキュリティ修正を含む新バージョンのPull Requestを自動作成するため、SHAピンニングと自動更新の組み合わせにより、セキュリティと保守性のバランスが取れます。

シークレット管理はプラットフォームごとに異なる戦略が必要です。GitHub Actionsは、リポジトリ、Organization、Environmentの3つのスコープレベルでSecretsを管理します。Environment Secretsは承認ワークフローとブランチ制限を追加で設定できます。GitLab CIは通常の変数とProtected Variablesを区別し、後者はProtected Branchでのみ利用可能です。JenkinsはCredentials Pluginを通じて、Username/Password、Secret Text、SSHキー、証明書など多様なタイプのCredentialを管理します。

OIDC（OpenID Connect）は、クラウドデプロイメントにおけるベストプラクティスとして確立されています。静的なアクセスキーの代わりに、パイプラインが短命なトークンを使用してクラウドプロバイダーに直接認証します。GitHub ActionsはAWS、Azure、GCPへのOIDCをネイティブサポートしています。GitLab CIは`$CI_JOB_JWT`を通じてIDトークンを提供します。Jenkinsの場合はOIDC統合に専用プラグインが必要です。

## パフォーマンス最適化：キャッシュ戦略とMatrix効率化

パフォーマンスに関する質問は、パイプラインのコスト意識と最適化能力を評価するものです。1日に10回実行される20分のパイプラインは、膨大なランナー時間を消費し、開発者のフィードバックループを阻害します。

キャッシュは最も効果的な最適化手法です。GitHub Actionsの`actions/cache`は実行間で依存関係を保存します。キャッシュキーには依存関係ファイルのハッシュ（`hashFiles('package-lock.json')`）を含め、依存関係が変更された際に自動的に無効化されるようにします。`restore-keys`パラメータは、完全一致するキーが存在しない場合のフォールバックを可能にします。

GitLab CIのキャッシュは`key: files: ['package-lock.json']`で同様のロジックを実装できます。`policy: pull-push`（デフォルト）と`policy: pull`の使い分けは、複数のジョブが同じキャッシュを使用する際のレースコンディション防止に重要です。キャッシュを更新するジョブは1つだけにし、他のジョブは読み取り専用にすることが推奨されます。

Jenkinsは順次実行のステージに対してワークスペースの再利用をデフォルトで行います。並列ジョブやマルチブランチパイプラインでは、`Stash/Unstash`機能がエージェント間でのArtifact転送に有効です。大規模コードベースでは、Job Cacher PluginやArtifact Manager on S3 Pluginによる外部キャッシュの方がスケーラブルです。

Matrix Buildsは並列化を促進しますが、コストも増加させます。5つのNodeバージョン × 3つのOS = 15の並列ジョブとなります。面接では、マトリクスの次元を合理的に制限できるかが評価されます。GitHub Actionsの`strategy.matrix.exclude`と`include`により、選択的な組み合わせが可能です。

## プラットフォーム比較：GitHub Actions vs GitLab CI vs Jenkins

面接では、組織の要件に基づいた根拠ある推薦が求められます。以下の表は技術的な違いを整理したものです。

| 項目 | GitHub Actions | GitLab CI | Jenkins |
|---|---|---|---|
| 設定ファイル | `.github/workflows/*.yml` | `.gitlab-ci.yml` | `Jenkinsfile` |
| 実行モデル | ジョブベース（デフォルトで並列） | ステージベース（ステージ間は順次） | ステージベース（柔軟） |
| ランナー | GitHub-hosted + Self-hosted | GitLab.com Shared + Self-hosted | Self-hostedのみ |
| シークレット管理 | Repository/Org/Environment Secrets | CI/CD変数（保護付き） | Credentials Plugin |
| Matrix Builds | `strategy.matrix` | `parallel:matrix` | `matrix`（Plugin） |
| 手動ゲート | `environment` + Required Reviewers | `when: manual` | `input`ディレクティブ |
| マーケットプレイス | 20,000+ Actions | CI/CD Components Catalog | 1,800+ Plugins |
| AI機能 | Copilot for Actions（Preview） | Duo CI Expert Agent（Beta） | Community Plugins |
| 料金体系 | 公開リポジトリは無料、プライベートは分課金 | 400分/月無料、段階的課金 | 無料（OSS）、自己管理 |

GitHub Actionsは、オープンソースプロジェクトやGitHubをコードホスティングとして既に利用しているチームに最適です。GitLab CIは、リポジトリ、CI/CD、コンテナレジストリ、セキュリティスキャン、インシデント管理を統合したオールインワンプラットフォームとして強みを発揮します。Jenkinsは、レガシーシステム、厳格なコンプライアンス要件、クラウド接続のない複雑なオンプレミスインフラストラクチャを持つ組織で依然として有力な選択肢です。

ハイブリッドアプローチも実務では一般的です。Pull Requestの高速フィードバックにGitHub Actions、複雑なコンプライアンス要件を伴うデプロイメントにJenkinsを組み合わせるパターンが典型例です。面接では、一つのプラットフォームに固執するのではなく、このような実用的なアーキテクチャを議論できることが重要です。

## モニタリングとオブザーバビリティ：パイプラインメトリクスとインシデント対応

本番運用に耐えるCI/CDには、モニタリングとアラートが不可欠です。Build Success RateとMean Time to Recovery（MTTR）は主要な指標です。GitHub ActionsのWorkflow Insightsは成功率と平均実行時間を提供します。GitLab CI Analyticsは、Deployment Frequency、Lead Time、Change Failure Rateなど、DORA Metricsの4指標を表示します。JenkinsはPrometheus Metrics Pluginを通じてビルド統計をGrafanaダッシュボードにエクスポートできます。

Flaky Test（不安定なテスト）はパイプラインを不安定にする要因です。GitHub Actionsは失敗したジョブのみの再実行が可能で、ワークフロー全体を再実行する必要はありません。GitLab CIの`retry: 2`は失敗したジョブを自動的に再試行します。JenkinsにはFlaky Test Handler Pluginがあり、間欠的な失敗の統計的分析を行います。ただし、自動リトライは症状の緩和であり、根本原因の分析が依然として不可欠であることを説明できることが面接では重要です。

通知戦略はVisibilityとAlert Fatigueのバランスを取る必要があります。本番デプロイ時のGitHub Actions `workflow_run` WebhookからSlackへの通知は有効ですが、テスト失敗のたびに通知すると、チャンネルが過負荷になります。GitLab CIのPipeline Schedulesとステータス変更時のみのメール通知はノイズを軽減します。JenkinsのEmail-ext PluginとGroovyテンプレートにより、コンテキストに応じたメッセージのカスタマイズが可能です。

監査ログは、パイプラインのトリガー、シークレットの変更、本番デプロイの承認を記録します。GitHub Audit Log APIはセキュリティ分析とコンプライアンスレポートを可能にし、GitLab Audit Eventsはすべてのセキュリティ関連の変更を追跡します。Jenkins Audit Trail Pluginはタイムスタンプとユーザー情報付きで設定変更をログに記録します。

CI/CD面接の準備として、[CI/CDの基礎](/technologies/devops/interview-questions/ci-cd-fundamentals)、[GitHub Actions](/technologies/devops/interview-questions/github-actions)、[GitLab CI](/technologies/devops/interview-questions/gitlab-ci)、[Jenkins](/technologies/devops/interview-questions/jenkins)の各プラットフォーム別モジュールでの実践的な学習が効果的です。CI/CD以外のDevOps領域については、[DevOps面接質問総合ガイド](/blog/devops/essential-devops-interview-questions)を参照してください。

## まとめ

- GitHub ActionsはGitHubとの統合、充実したMarketplace、Parallel Stepsなどの新機能により、オープンソースエコシステムをリードしているが、サプライチェーンリスクに対するSHAピンニングの徹底が必要である
- GitLab CIはCI/CDとセキュリティスキャンの緊密な統合を提供し、バージョン18.3以降ではSLSA認証やきめ細かなジョブトークン権限管理が実装されている
- Jenkinsは完全なインフラ制御を必要とする組織にとって最も柔軟な選択肢であるが、2026年1月以降はJava 21が必須となり、運用コストが高い点に留意が必要である
- シークレット管理は3つのプラットフォームすべてにおいて最頻出のセキュリティトピックであり、スコープ付きシークレット、保護変数、Credentialローテーション戦略の知識が不可欠である
- キャッシュ、並列化、条件付き実行によるパイプライン最適化は普遍的なスキルであり、実務経験の証として面接官に評価される
- 面接準備として、各プラットフォームについて少なくとも1つの実用的なパイプライン設定を用意し、簡易的なサンプルではなく実践的なパターンに焦点を当てることが推奨される

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/ja/blog/devops/ci-cd-pipeline-interview-questions-github-actions-gitlab-ci-jenkins