Azure

GitHub Actions vs Azure Pipelines 完全比較|CI/CD 選定・Self-hosted Runner・OIDC 認証

2026-05-24
NicheeLab編集部

GitHub ActionsAzure Pipelines は、両方とも Microsoft が提供する CI/CD サービスで、機能的に競合関係にあります。 Microsoft 戦略では新規プロジェクト・OSS は GitHub Actions、既存 Azure DevOps 環境は Azure Pipelines という棲み分けで、GitHub Actions への投資が積極化しています。 本記事では、両者の機能比較・選定基準・OIDC 認証・DevSecOps 統合を網羅的に整理します。

2 サービスの全体比較

項目GitHub ActionsAzure Pipelines
所属GitHub (Microsoft 2018 買収)Azure DevOps Services
YAML ファイル.github/workflows/*.ymlazure-pipelines.yml
Marketplace25,000+ Actions (圧倒的)1,000+ Tasks
個人 / OSS 料金Public Repo 無制限Public 限定無料
Private Free2,000 分/月 (Free Tier)1,800 分/月 (Free Tier)
Environment対応 (2022 GA)成熟
Approval Gate対応成熟
Self-hosted RunnerRunner Scale Sets (AKS/VMSS)Agent Pool
OIDC 認証対応対応 (azure/login@v2)
用途新規・OSS・GitHub 中心既存 Azure DevOps

GitHub Actions の特徴

強み

  • GitHub Marketplace: 25,000+ の公式・サードパーティ Action (圧倒的なエコシステム)
  • Pull Request ベースの自然な統合
  • 個人開発で実質無料 (Public Repo 無制限・Private 2,000 分/月)
  • Workflow as Code が GitHub UI で見やすい
  • シンプルな YAML 構文
  • OSS コミュニティに最適

代表的な Workflow 構造

name: CI
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20.x'
      - run: npm install
      - run: npm test
      - run: npm run build

Azure Pipelines の特徴

強み

  • Environment 機能がエンタープライズ向けに成熟
  • Self-hosted Agent Pool 管理が高度
  • Azure Artifacts 統合 (nuget/npm/maven/python の Private レジストリ)
  • Service Connection 管理が集中化
  • Azure DevOps Boards・Repos・Test Plans との一体感
  • 大規模エンタープライズで長期実績

Self-hosted Runner / Agent

項目GitHub Actions Self-hosted RunnerAzure Pipelines Self-hosted Agent
分類個別 Runner / Runner Scale SetsAgent Pool
自動スケーリングAKS / VMSS ベースVMSS Agent Pool
用途機密処理・GPU・社内インフラ統合同左
運用負荷OS パッチ + スケーリング管理同左

新規 GitHub Actions プロジェクトでは Microsoft-hosted Runner で十分なケースが多く、Self-hosted は特殊要件のみ。

OIDC 認証 (Workload Identity Federation)

新規プロジェクトでは OIDC / WIF 一択が現代のベストプラクティスです。

項目PAT / Service Principal SecretOIDC / WIF
Secret 管理必要 (環境変数に保存)不要
ローテーション定期実施必要不要
漏洩リスクあり最小化
クラウド対応Azure / AWS / GCPAzure / AWS / GCP
推奨度 (2026 年)レガシー主流

GitHub Actions の OIDC 例

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
      - run: az group list

Matrix Build

複数の組み合わせ (OS × ランタイムバージョン × Configuration) を並列実行する機能。

GitHub Actions Matrix Build

jobs:
  test:
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest, macos-latest]
        node: [18, 20, 22]
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
      - run: npm test

上記で 3 OS × 3 Node バージョン = 9 並列ジョブ実行。CI 時間が劇的短縮 (順次なら 1 時間 → 並列 5 分) されます。

Composite Action と Reusable Workflow

機能用途定義方法
Composite Action複数 Step を 1 つの Action にバンドルaction.yml
Reusable WorkflowWorkflow 全体を別 Repository から呼び出しworkflow_call トリガー

標準パターン

  • 組織共通の『Build → Test → Scan → Deploy』ステップを Composite Action 化
  • リポジトリ横断の標準パイプラインを Reusable Workflow 化 (例: org/.github リポジトリに集中保管)
  • Marketplace 公開して OSS コミュニティ貢献

Azure Pipelines の対応機能はPipeline Templates (Stage / Job / Step Templates) で、同様の再利用性を提供。

DevSecOps 統合

GitHub Actions の DevSecOps

  • GitHub Advanced Security (GHAS): CodeQL (SAST)・Secret Scanning・Dependabot・Push Protection
  • Microsoft Defender for DevOps: Azure DevOps / GitHub の集中セキュリティ管理
  • Container Image Scanning (Trivy・Microsoft Defender for Containers)
  • IaC スキャン (Checkov・tfsec)
  • SBOM 生成 (Anchore・SPDX)

Azure Pipelines の DevSecOps

  • Microsoft Defender for DevOps + Azure Pipelines Tasks
  • CodeQL Task
  • OWASP Dependency Check
  • SonarCloud

両者とも DevSecOps のShift Left (CI/CD パイプライン早期での脆弱性検知) を強力サポート。本番プロジェクトでは必須レベル。

選定フローチャート

  1. 新規プロジェクト? → GitHub Actions 推奨
  2. OSS / 個人開発? → GitHub Actions 一択 (Public Repo 無制限)
  3. 既存 Azure DevOps 環境? → Azure Pipelines 継続
  4. 大規模エンタープライズで Environment 重視? → Azure Pipelines (現時点)
  5. 多リポジトリ横断テンプレート重視? → 両方対応 (Reusable Workflow / Pipeline Templates)
  6. Microsoft セキュリティスタック統合? → 両方対応 (Defender for DevOps)

運用ベストプラクティス

  1. 新規プロジェクトは GitHub Actions を選択
  2. OIDC / WIF でクラウド認証 (Secret 完全排除)
  3. Composite Action / Reusable Workflow で再利用性確保
  4. Microsoft-hosted Runner が標準、Self-hosted は特殊要件のみ
  5. GitHub Advanced Security を本番リポジトリで有効化
  6. Microsoft Defender for DevOps で集中セキュリティ管理
  7. Matrix Build で並列テスト最適化
  8. Approval Gate を本番デプロイで必須化
  9. Dependabot で依存関係自動更新
  10. Workflow Run 履歴の Retention 設定 (デフォルト 90 日)

関連認定試験

よくある質問

GitHub Actions と Azure Pipelines の関係は?

両方とも Microsoft が提供する CI/CD サービス。GitHub Actions は GitHub (Microsoft が 2018 年買収) の CI/CD 機能、リポジトリと密接統合・OSS / 個人開発で圧倒的シェア。Azure Pipelines は Azure DevOps Services の CI/CD 機能、エンタープライズ Azure 環境で長く採用。両者は機能的に競合関係だが、Microsoft 戦略では新規プロジェクト・OSS は GitHub Actions、既存 Azure DevOps 環境は Azure Pipelines という棲み分け。最近は GitHub Actions への投資が積極的で、Azure Pipelines の機能 (Environment・Approval Gate) も順次 GitHub Actions に移植中。新規開発プロジェクトでは GitHub Actions が標準選択肢になりつつあります。

機能比較で何が違いますか?

GitHub Actions の強み: 1) GitHub Marketplace で 25,000+ の公式・サードパーティ Action 提供 (圧倒的なエコシステム)、2) Pull Request ベースの自然な統合、3) 個人開発で実質無料 (Public Repo 無制限・Private 2,000 分/月)、4) Workflow as Code (.github/workflows/*.yml) が GitHub UI で見やすい。Azure Pipelines の強み: 1) Environment 機能・Approval Gate がエンタープライズ向けに成熟、2) Self-hosted Agent Pool 管理が高度、3) Azure Artifacts 統合 (nuget/npm/maven/python の Private レジストリ)、4) Service Connection 管理が集中化。両者は基本機能 (YAML パイプライン・Multi-stage・Matrix Build・Container Job) はほぼ同等で、エコシステム重視なら GitHub Actions、エンタープライズ管理機能重視なら Azure Pipelines という選定軸が現実的です。

Self-hosted Runner / Agent の使い分けは?

GitHub Actions Self-hosted Runner: 自社サーバーに Runner エージェントをインストール、Microsoft 提供 (Microsoft-hosted) より柔軟、社内 Network のリソース (オンプレ DB・社内ファイルサーバー) にアクセス可能。Azure VMSS と統合した『GitHub Actions Runner Scale Sets (AKS / VMSS ベース)』で自動スケーリング Runner も実装可能。Azure Pipelines Self-hosted Agent: Azure DevOps の Agent Pool として登録、複数 Agent をプール化、Capability ベースのジョブ振り分け。新規 GitHub Actions プロジェクトでは Microsoft-hosted Runner で十分なケースが多く、Self-hosted は 1) 機密データ処理、2) GPU が必要、3) 既存社内インフラ統合、のような特殊要件のみ。本番運用では Self-hosted の OS パッチ管理・スケーリング管理が追加負担となる点に注意が必要です。

Authentication: PAT vs OIDC の違いは?

Personal Access Token (PAT) / Service Principal Secret: 従来の認証方式、Token / Secret を CI/CD 環境変数に保存。リスク: Secret 漏洩・ローテーション運用負荷・Token 失効管理。OIDC (OpenID Connect) / Workload Identity Federation: 2022 年から GitHub Actions・Azure Pipelines で標準対応、Secret 不要のクラウド認証。フロー: GitHub Actions / Azure Pipelines が OIDC Token を発行 → クラウド (Azure・AWS・GCP) が Token を検証 → 一時的なクラウド Credential を発行。Azure Pipelines は azure/login@v2 Action で OIDC 標準対応 (Workload Identity Federation)。新規プロジェクトでは OIDC / WIF 一択が現代のベストプラクティスで、Secret ベース認証は段階的に廃止される方向です。

Matrix Build はどう活用しますか?

Matrix Build は複数の組み合わせ (OS × ランタイムバージョン × Configuration) を並列実行する機能。両方とも YAML で simple に定義可能。GitHub Actions 例: strategy.matrix で os: [ubuntu-latest, windows-latest, macos-latest] と node: [18, 20, 22] を組み合わせ、9 並列ジョブ実行。Azure Pipelines 例: strategy.matrix で複数構成 (configuration: { 'Debug-x86': { cfg: 'Debug', plt: 'x86' }, ... }) を定義。代表的なユースケース: 1) クロスプラットフォーム OSS テスト (Node.js Library を 3 OS × 3 バージョン = 9 環境で並列テスト)、2) コンテナイメージの multi-arch ビルド (amd64・arm64)、3) Visual Studio C++ プロジェクトの multi-config ビルド。Matrix Build により CI 時間が劇的に短縮 (順次なら 1 時間 → 並列 5 分) され、開発生産性に直結する重要機能です。

Composite Action と Reusable Workflow は?

GitHub Actions の再利用機能。Composite Action: 複数の Step を 1 つの Action にバンドル、action.yml で定義、Marketplace 公開可能。Reusable Workflow: Workflow 全体を別 Repository から呼び出し、workflow_call トリガーで定義、組織横断テンプレート。標準パターン: 1) 組織共通の『Build → Test → Scan → Deploy』ステップを Composite Action 化、2) リポジトリ横断の標準パイプラインを Reusable Workflow 化 (例: org/.github リポジトリに集中保管)、3) Marketplace 公開して OSS コミュニティ貢献。Azure Pipelines の対応機能は Pipeline Templates (Stage / Job / Step Templates) で、同様の再利用性を提供。エンタープライズでは数十-数百のリポジトリで同じ CI/CD ロジックを共有する場合、Composite Action + Reusable Workflow の組み合わせが運用負荷を劇的に削減します。

DevSecOps 統合は?

GitHub Actions の DevSecOps: 1) GitHub Advanced Security (GHAS) で CodeQL (SAST)・Secret Scanning・Dependabot・Push Protection、2) Microsoft Defender for DevOps で Azure DevOps / GitHub の集中セキュリティ管理、3) Container Image Scanning (Trivy・Microsoft Defender for Containers)、4) IaC スキャン (Checkov・tfsec)、5) SBOM 生成 (Anchore・SPDX)。Azure Pipelines の DevSecOps: 同等機能を Microsoft Defender for DevOps + Azure Pipelines Tasks (CodeQL・OWASP Dependency Check・SonarCloud) で実装。両者とも DevSecOps の Shift Left (CI/CD パイプライン早期での脆弱性検知) を強力サポート、本番プロジェクトでは必須レベル。詳細は AZ-400 完全ガイドの DevSecOps 章を参照してください。

関連認定試験は?

AZ-400 (DevOps Engineer Expert) のドメイン 3 (Build and Release Pipelines 40-45%) で両方が深く問われ、YAML 構文・Stage / Job / Step・Approval Gate・Marketplace・OIDC 認証などの設計判断が頻出。GitHub Actions は新規プロジェクトの主流のため重点学習推奨。AZ-104 (Administrator) で基礎、AZ-204 (Developer Associate、2026-07 リタイア注意) で開発者視点での CI/CD、AZ-305 (Solutions Architect Expert) でアーキテクチャ視点。Azure DevOps エンジニア キャリアロードマップでも GitHub Actions と Azure Pipelines は中核技術として位置付けられます。

関連記事・技術深掘り

Azure Managed Identity vs Service Principal 完全比較|認証パターンの選定と実装ベストプラクティス【2026 年版】

Azure の認証エンティティ Managed Identity と Service Principal を完全比較。System-assigned / User-assigned の使い分け、Client Secret vs Certificate vs Workload Identity Federation の選定、AKS Workload Identity、Azure サービス対応状況、関連認定試験 (SC-300 / AZ-204 / AZ-400) を日本語で網羅。実装パターン集付き。

Azure Bicep チュートリアル|ARM 後継 IaC の基本構文・モジュール化・What-If・CI/CD 統合【2026 年版】

Azure 純正 IaC ツール Bicep の完全チュートリアル。ARM JSON との違い・基本構文 (param/var/resource/module/output)・モジュール化ベストプラクティス・What-If デプロイ・GitHub Actions / Azure Pipelines 統合・ARM からの移行手順・関連認定試験 (AZ-104 / AZ-204 / AZ-400 / AZ-305) を日本語で網羅。

Terraform on Azure 完全ガイド|AzureRM/AzAPI Provider・State 管理・Module 設計・CI/CD 統合【2026 年版】

Terraform で Azure リソースを管理する完全ガイド。AzureRM Provider と AzAPI Provider の使い分け、Terraform State の Azure Storage Backend 管理、Module 設計と Azure Verified Modules (AVM)、Bicep との併用、Drift Detection、GitHub Actions / Azure Pipelines 統合、関連認定試験 (AZ-400 / HashiCorp Terraform Associate) を日本語で網羅。

AZ-104 vs AZ-204 完全比較|Microsoft Azure Administrator vs Developer Associate の違いと選び方【2026 年版】

Microsoft Azure の 2 大 Associate 認定 AZ-104 (Administrator) と AZ-204 (Developer) を完全比較。対象ロール・出題範囲・難易度・学習時間・受験料・キャリアパスを表形式で整理。AZ-204 2026 年 7 月リタイア後の判断材料、両方取る価値、次の認定への進路まで日本語で網羅。

本記事の技術情報は GitHub Actions Documentation およびAzure Pipelines Documentation に基づいています。 本記事は Microsoft Corporation の公式商品ではなく、いかなる提携・後援関係もありません。 Microsoft、Azure、Azure DevOps、GitHub は Microsoft group of companies の商標です。 情報は 2026 年 5 月 24 日時点の公式公開資料に基づきます。最新情報は必ず公式ページをご確認ください。

この記事で学んだ内容を問題で確認しましょう

16,000問以上の問題で実力チェック

Azure 試験対策ページを見る
この記事の著者

NicheeLab編集部

データエンジニアリング・クラウド資格の専門家。Databricks・Snowflake等の認定資格を保有し、実務経験に基づいた問題作成・解説を行っています。NicheeLab運営。


関連記事
Azure

AZ-900 完全ガイド|Microsoft Azure Fundamentals 出題範囲・学習リソース・合格戦略

Microsoft Azure Fundamentals (AZ-900) の 2026 年 1 月 14 日改訂版に対...

Azure

Azure 認定資格ロードマップ 2026 完全版|全 26 試験の体系と大型再編 (AI-901/AI-103/SC-500)

Microsoft Azure 認定資格 全 26 試験 (現行 23 + 退役 3) の 2026 年版ロードマップ。...

Azure

AI-901 完全ガイド|Azure AI Fundamentals 新試験

Microsoft Certified: Azure AI Fundamentals (AI-901) の出題範囲・Mi...

Azure

Microsoft Entra ID 入門|旧 Azure AD から学ぶ ID 管理 (AZ-900/SC-900/AZ-104 必須知識)

Microsoft Entra ID (旧 Azure Active Directory) の入門解説。2023 年 7...

Azure

DP-900 完全ガイド|Azure Data Fundamentals 出題範囲・学習リソース・合格戦略

Microsoft Azure Data Fundamentals (DP-900) の完全ガイド。4 ドメインの出題範...

Azureの記事一覧 (103件)
© 2026 NicheeLab All rights reserved.