Contents
1. 構成階層と設計指針
| 項目 | GitHub Actions | Azure DevOps |
|---|---|---|
| 階層構造 | Workflow → Job → Step（3 層） | Pipeline → Stage → Job → Step（4 層） |
| ステージ表現 | needs: で依存関係を記述し、マトリクスや条件分岐で擬似的に実装 |
stage ブロックで環境・フェーズごとに明示的に定義可能 |
| 主な利用シーン | 小規模〜中規模の CI/CD。コードベースで完結したい開発チーム | 大規模・マルチステージデプロイや承認フローが必須のエンタープライズ |
設計上のポイント
- Azure DevOps の Stage は UI でも視覚化でき、環境ごとのゲートウェイ設定（手動承認、チェック）を標準で提供。
- GitHub Actions の Workflow は YAML がシンプルで、マトリクスや if: 条件式だけで柔軟に分岐させられるが、ステージ的概念は自前実装になる。
参考: GitHub Docs – Understanding workflows（閲覧日：2026‑03‑15）
参考: Azure DevOps Docs – Stages in pipelines（閲覧日：2026‑03‑15）
2. ランナー／エージェントの料金体系とスケーラビリティ
| 項目 | GitHub Actions（2026 年） | Azure DevOps（2026 年） |
|---|---|---|
| 無料枠 | 50,000 分 / 月（Linux・Windows 共通） | Microsoft‑hosted エージェント 1 台 が無償（月額 $0） |
| 超過料金（CPU 時間あたり） | Linux $0.008/分、Windows $0.015/分、macOS $0.08/分 | 追加エージェント $40 / エージェント / 月（Microsoft‑hosted） セルフホストは Azure VM の実使用料のみ |
| ジョブ最大実行時間 | 制限なし（課金は実行時間に比例） | 1 ジョブあたり 6 h（パラレルジョブ数が増えれば総実行時間は無制限） |
| スケールアウト方法 | - セルフホストランナーを自前 VM/コンテナで増設 - GitHub Marketplace の「Auto‑scale」アクションで自動拡張 |
- エージェントプールにセルフホストエージェント（Azure VM）を追加 - Microsoft‑hosted エージェントは購入した数だけ同時実行可能 |
料金のポイント
- 短時間・多数ジョブが頻発する場合、GitHub Actions の従量課金はコスト効率が高い。
- 長時間ビルドや大規模テストを継続的に走らせる場合は、Azure DevOps の「無制限ジョブ」＋追加エージェント購入が割安になる。
参考: GitHub Pricing – Actions（閲覧日：2026‑03‑15）
参考: Azure DevOps Services pricing（閲覧日：2026‑03‑15）
3. セキュリティと ID フェデレーション（OIDC）
| 項目 | GitHub Actions | Azure DevOps |
|---|---|---|
| OIDC トークン取得方法 | id-token 権限で steps.id-token.outputs.token を取得 |
Service Connection の「Federated credential」設定で $(System.AccessToken) が利用可能 |
| シークレット保管 | GitHub Secrets（リポジトリ単位・AES‑256 暗号化） | Azure Key Vault 連携、もしくは Pipeline Variables（暗号化オプション） |
| 推奨ベストプラクティス | - GITHUB_TOKEN は最小権限で使用- 必要に応じて PAT を分離し、期限を短く設定 |
- Service Connection に最低権限ロールを付与 - Key Vault のアクセスポリシーでアクセス範囲を限定 |
実装の違い
- GitHub は OIDC が標準機能として組み込まれ、外部クラウド（AWS, Azure, GCP 等）へ直接トークンを渡せる。
- Azure DevOps では「Service Connection」＋ OIDC により同等のフローが実現できるが、Key Vault との連携設定が別途必要。
参考: GitHub Docs – Using OpenID Connect（閲覧日：2026‑03‑15）
参考: Azure DevOps – OIDC authentication（閲覧日：2026‑03‑15）
4. 開発フロー統合・拡張性
| 項目 | GitHub | Azure DevOps |
|---|---|---|
| コード補完 | GitHub Copilot（AI 補助） | 標準機能なし（外部プラグインで実装） |
| パッケージレジストリ | GitHub Packages（Docker, npm, Maven 等） | Azure Artifacts（NuGet, npm, Maven, Docker） |
| タスク管理 | Projects（カンバン/テーブル） | Boards（バックログ、スプリント、バーンダウン） |
| ワークアイテムのトレーサビリティ | PR と Issue の手動リンクが中心 | Work Item ↔ Commit ↔ Build が自動で紐付く |
| エクステンションエコシステム | Marketplace に 10,000 超のアクション・アプリ | Azure DevOps Marketplace に約 2,000 件の拡張機能 |
選択指標
- AI 補助やオープンソース中心 の開発は GitHub が自然なプラットフォーム。
- エンタープライズ規模で要件管理・リリース計画を統合したい 場合は Azure DevOps が優位。
参考: GitHub Marketplace（閲覧日：2026‑03‑15）
参考: Azure DevOps Extensions Marketplace（閲覧日：2026‑03‑15）
5. エンタープライズサポート・ハイブリッド移行戦略
推奨移行ステップ
- 評価フェーズ
-
両ツールの無料組織／リポジトリで PoC を実施。ビルド時間・コストを測定し、レポート化。
-
パイロットフェーズ
-
クリティカル度が低いマイクロサービスだけ GitHub Actions に切り替える。
actions/checkout@v3と Azure CLI の OIDC 連携でデプロイを自動化。 -
本格移行フェーズ
- 成功指標（ビルド成功率、コスト削減率）を満たしたら、残りのパイプラインも GitHub Actions に統合。Azure DevOps の Boards は継続利用し、
azure-devops-connectorで Issue と Work Item を同期。
サポート・SLA
| 項目 | GitHub Enterprise Cloud | Azure DevOps (Standard Support) |
|---|---|---|
| 可用性保証 | 99.9%（月次 SLA） | 99.9%（Standard サポート） |
| 主要サポート窓口 | 専任テクニカルアカウントマネージャー（E5 契約） | Microsoft アカウントマネージャー + Azure Support |
参考: GitHub Enterprise Cloud SLA（閲覧日：2026‑03‑15）
参考: Azure DevOps Service Level Agreement（閲覧日：2026‑03‑15）
6. まとめ
| 観点 | GitHub Actions | Azure DevOps |
|---|---|---|
| 概念モデル | シンプルな 3 層構造で小〜中規模に最適 | Stage を持つ 4 層で大規模・マルチステージ向き |
| 料金・スケーラビリティ | 従量課金（無料 50,000 分）＋セルフホスト自由度高し | 無料エージェント 1 台＋追加エージェントは固定月額 |
| セキュリティ | OIDC + GitHub Secrets が標準 | OIDC + Azure Key Vault 連携が強力 |
| 拡張性・統合 | Marketplace と Copilot が豊富 | Boards·Repos·Artifacts のエンドツーエンド ALM が特徴 |
| サポート・移行 | Enterprise Cloud の SLA = 99.9% | Standard Support で同等、ハイブリッド戦略が実務的 |
判断材料
- シンプルかつコード中心の CI/CD → GitHub Actions
- 大規模マルチステージデプロイや厳格な承認フロー → Azure DevOps
- 既存 Azure 環境が多い／Key Vault 連携を重視 → Azure DevOps
- AI 補助・オープンソースエコシステム活用 → GitHub
自社の開発プロセス、予算感覚、セキュリティ要件に合わせて、単独導入かハイブリッド構成を選択してください。