GitHub Actions と Azure Pipelines は、両方とも Microsoft が提供する CI/CD サービスで、機能的に競合関係にあります。 Microsoft 戦略では新規プロジェクト・OSS は GitHub Actions、既存 Azure DevOps 環境は Azure Pipelines という棲み分けで、GitHub Actions への投資が積極化しています。 本記事では、両者の機能比較・選定基準・OIDC 認証・DevSecOps 統合を網羅的に整理します。
| 項目 | GitHub Actions | Azure Pipelines |
|---|---|---|
| 所属 | GitHub (Microsoft 2018 買収) | Azure DevOps Services |
| YAML ファイル | .github/workflows/*.yml | azure-pipelines.yml |
| Marketplace | 25,000+ Actions (圧倒的) | 1,000+ Tasks |
| 個人 / OSS 料金 | Public Repo 無制限 | Public 限定無料 |
| Private Free | 2,000 分/月 (Free Tier) | 1,800 分/月 (Free Tier) |
| Environment | 対応 (2022 GA) | 成熟 |
| Approval Gate | 対応 | 成熟 |
| Self-hosted Runner | Runner Scale Sets (AKS/VMSS) | Agent Pool |
| OIDC 認証 | 対応 | 対応 (azure/login@v2) |
| 用途 | 新規・OSS・GitHub 中心 | 既存 Azure DevOps |
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| 項目 | GitHub Actions Self-hosted Runner | Azure Pipelines Self-hosted Agent |
|---|---|---|
| 分類 | 個別 Runner / Runner Scale Sets | Agent Pool |
| 自動スケーリング | AKS / VMSS ベース | VMSS Agent Pool |
| 用途 | 機密処理・GPU・社内インフラ統合 | 同左 |
| 運用負荷 | OS パッチ + スケーリング管理 | 同左 |
新規 GitHub Actions プロジェクトでは Microsoft-hosted Runner で十分なケースが多く、Self-hosted は特殊要件のみ。
新規プロジェクトでは OIDC / WIF 一択が現代のベストプラクティスです。
| 項目 | PAT / Service Principal Secret | OIDC / WIF |
|---|---|---|
| Secret 管理 | 必要 (環境変数に保存) | 不要 |
| ローテーション | 定期実施必要 | 不要 |
| 漏洩リスク | あり | 最小化 |
| クラウド対応 | Azure / AWS / GCP | Azure / AWS / GCP |
| 推奨度 (2026 年) | レガシー | 主流 |
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複数の組み合わせ (OS × ランタイムバージョン × Configuration) を並列実行する機能。
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 | 複数 Step を 1 つの Action にバンドル | action.yml |
| Reusable Workflow | Workflow 全体を別 Repository から呼び出し | workflow_call トリガー |
Azure Pipelines の対応機能はPipeline Templates (Stage / Job / Step Templates) で、同様の再利用性を提供。
両者とも DevSecOps のShift Left (CI/CD パイプライン早期での脆弱性検知) を強力サポート。本番プロジェクトでは必須レベル。
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 日時点の公式公開資料に基づきます。最新情報は必ず公式ページをご確認ください。
NicheeLab編集部
データエンジニアリング・クラウド資格の専門家。Databricks・Snowflake等の認定資格を保有し、実務経験に基づいた問題作成・解説を行っています。NicheeLab運営。
AZ-900 完全ガイド|Microsoft Azure Fundamentals 出題範囲・学習リソース・合格戦略
Microsoft Azure Fundamentals (AZ-900) の 2026 年 1 月 14 日改訂版に対...
Azure 認定資格ロードマップ 2026 完全版|全 26 試験の体系と大型再編 (AI-901/AI-103/SC-500)
Microsoft Azure 認定資格 全 26 試験 (現行 23 + 退役 3) の 2026 年版ロードマップ。...
AI-901 完全ガイド|Azure AI Fundamentals 新試験
Microsoft Certified: Azure AI Fundamentals (AI-901) の出題範囲・Mi...
Microsoft Entra ID 入門|旧 Azure AD から学ぶ ID 管理 (AZ-900/SC-900/AZ-104 必須知識)
Microsoft Entra ID (旧 Azure Active Directory) の入門解説。2023 年 7...
DP-900 完全ガイド|Azure Data Fundamentals 出題範囲・学習リソース・合格戦略
Microsoft Azure Data Fundamentals (DP-900) の完全ガイド。4 ドメインの出題範...