Using GitHub Actions to Deploy to Azureを確認している方が最初に押さえるべき結論は、Azureへのデプロイ自動化では、従来の発行プロファイルや長期保存型シークレットに頼る構成から、OpenID Connect（OIDC）を使った短期トークン認証へ移行することが重要という点です。Microsoft Learnの該当ページは、GitHub ActionsでAzureへコンテナ化アプリをデプロイする流れを紹介するDevOps Labのエピソードですが、2026年時点で実運用に落とし込むなら、現在の公式ドキュメントに沿ってazure/login、azure/webapps-deploy、GitHub Environments、最小権限のロール割り当てを確認する必要があります。(Microsoft Learn)
特に管理者と開発者が見るべきポイントは、OIDC認証の有効化、古いAzure GitHub Actionsリポジトリへの依存解消、デプロイ先ごとの権限スコープ、production環境の承認ルール、ワークフロー内のシークレット露出対策です。すでにAzure App ServiceへGitHub Actionsでデプロイしている環境でも、すぐに壊れる変更とは限りません。ただし、発行プロファイルやサービスプリンシパルのシークレットをそのまま使い続けている場合は、セキュリティと運用負荷の面で見直し対象になります。(GitHub Docs)
Using GitHub Actions to Deploy to Azureは何を扱う公式情報か
Microsoft Learnの「Using GitHub Actions to Deploy to Azure」は、Damian Brady氏がProduct ManagerのGopinath Chigakkagari氏と、GitHub Actionsを使ったAzureデプロイについて話すDevOps Labのエピソードです。内容としては、リポジトリへのpushをきっかけに、GitHub Actions内でコンテナ化アプリケーションをAzureへデプロイする流れを紹介しています。(Microsoft Learn)
このページを2026年時点で読む際に注意したいのは、動画ページ内で紹介されている周辺リンクや前提が、現在の推奨構成とは異なる可能性があることです。たとえば、該当ページから案内されているAzure/github-actionsリポジトリは、現在はアーカイブ済みで、説明にも「DEPRECATED」と記載されています。つまり、古いサンプルをそのままコピーするのではなく、現在メンテナンスされている個別のAzure Actionsと公式ドキュメントを確認するのが安全です。(Microsoft Learn)
2026年時点で見るべき主な変更点
Using GitHub Actions to Deploy to Azureの考え方自体は、「GitHubのイベントを起点にAzureへ自動デプロイする」というシンプルなものです。ただし、実装の推奨形は大きく変わっています。特に重要なのは、認証方式・利用するAction・本番環境の保護・権限管理です。
| 観点 | 以前の理解で起きやすいこと | 2026年時点の確認ポイント | 影響 |
|---|---|---|---|
| Azure用Action | 古いまとめリポジトリや古いサンプルを参照する | azure/loginやazure/webapps-deployなど、個別Actionの現行ドキュメントを確認する | 非推奨Actionへの依存、予期しない失敗を避けられる |
| 認証方式 | 発行プロファイルやサービスプリンシパルのシークレットをGitHub Secretsに保存する | OIDCによる短期トークン認証を優先する | シークレット漏えい時の影響を小さくできる |
| App Service連携 | 手動でYAMLだけを書く | Deployment Centerでワークフロー生成やOIDC構成を使える場合がある | 初期設定のミスを減らせる |
| 本番デプロイ | mainへのpushで即productionへ反映する | GitHub Environmentsで承認者・ブランチ制限・保護ルールを設定する | 誤デプロイや未承認リリースを防ぎやすい |
| 権限スコープ | サブスクリプション全体にContributorを付ける | 対象Web App、スロット、リソースグループなど必要範囲に絞る | 侵害時の被害範囲を限定できる |
Azure App Serviceの公式ドキュメントでは、GitHub Actionsを使ってGitHubからApp Serviceへデプロイでき、アプリ作成時やDeployment Centerから継続的デプロイを構成できると説明されています。また、OpenID Connectは短期トークンを使うため、設定はやや複雑でもセキュリティ強化につながる方式として推奨されています。(Microsoft Learn)
影響を受ける対象者
この変更・見直しの影響を受けやすいのは、GitHub ActionsでAzureへ継続的デプロイしているチームです。特に次のような環境では、ワークフローの棚卸しを優先してください。
Azure管理者
Azure管理者は、GitHub ActionsからAzureリソースへ接続するためのID、ロール、フェデレーション資格情報を確認する必要があります。OIDCを使う場合、Azure側でGitHubのOIDCプロバイダーを信頼する設定を行い、どのリポジトリ・ブランチ・環境からのトークンを許可するかを条件として定義します。GitHub Docsでも、信頼できないリポジトリがクラウドリソース用のアクセストークンを取得できないよう、少なくとも1つの条件を定義する必要があると説明されています。(GitHub Docs)
実務では、次のような確認が必要です。
| 確認項目 | 推奨される判断基準 |
|---|---|
| ロール割り当て | サブスクリプション全体ではなく、対象リソースまたはリソースグループに絞る |
| 本番環境用ID | 開発・検証・本番でIDを分ける |
| フェデレーション資格情報 | main、release/*、environment:productionなど、許可するsubjectを明確にする |
| 監査 | GitHub Actionsの実行者、Azure側のサインインログ、ロール変更履歴を確認する |
| 退職者・外部委託 | GitHubのリポジトリ権限とAzure RBACの両方を見直す |
GitHub管理者
GitHub管理者は、OrganizationまたはRepository単位で、Actionsの実行ポリシー、Secrets、Environments、承認ルールを確認します。production環境へデプロイするジョブにenvironment: productionを設定しておけば、環境ごとのシークレットや承認者、デプロイ可能なブランチを管理できます。GitHub Environmentsでは、Required reviewers、Wait timer、デプロイ可能なブランチやタグの指定などを設定できます。(GitHub Docs)
見落としやすいのは、.github/workflows/配下の変更権限です。ワークフローを書き換えられる人は、実質的にデプロイ手順や実行コマンドを変えられます。GitHubのセキュリティガイドでも、ワークフローファイルにCODEOWNERSを設定し、変更時に指定レビュアーの承認を求める運用が紹介されています。(GitHub Docs)
開発者・DevOps担当者
開発者は、YAMLの書き方だけでなく、ビルド成果物とデプロイ対象の対応を確認する必要があります。たとえばNode.jsやTypeScriptのようにビルド成果物がdist/やbuild/へ出力される構成では、ソースルートをそのままデプロイすると、Azure側で期待したファイルが見つからないことがあります。Azure App Serviceのドキュメントでも、TypeScriptなどのコンパイルが必要なNode.jsアプリでは、GitHub Actionsで先にビルドし、コンパイル済みの出力フォルダーをデプロイする考え方が示されています。(Microsoft Learn)
最重要ポイントはOIDC認証への移行
GitHub ActionsからAzureへデプロイする場合、現在の第一候補はOIDC認証です。OIDCを使うと、GitHub Secretsに長期保存型のAzure資格情報を保存せず、GitHub Actionsの実行時に短期トークンを取得してAzureへアクセスできます。GitHub Docsでも、OIDCによりGitHub Actionsワークフローが長期保存型のAzure資格情報を保存せずにAzureリソースへアクセスできると説明されています。(GitHub Docs)
認証方式ごとの判断基準は次の通りです。
| 認証方式 | 向いている場面 | 注意点 |
|---|---|---|
| OIDC | 新規構築、本番運用、セキュリティを重視するCI/CD | Azure側のフェデレーション資格情報とGitHub側のid-token: write設定が必要 |
| サービスプリンシパルのシークレット | 既存環境の暫定運用、OIDC移行前の一時対応 | シークレットの保管・ローテーション・漏えい対応が必要 |
| 発行プロファイル | App Serviceの簡易デプロイ、検証環境 | 本番では管理・監査・権限分離の面で慎重に扱う |
| マネージドID | Azure上のセルフホストランナーからAzureへアクセスする場合 | ランナー自体の保護とネットワーク分離が重要 |
Azure Login Actionは、OIDC、サービスプリンシパルシークレット、システム割り当てマネージドID、ユーザー割り当てマネージドIDによるログインをサポートしており、公式のMarketplaceページでもOIDCベースの認証が推奨されています。(GitHub)
OIDC移行時に確認すべき設定
OIDCへの移行では、GitHub側とAzure側の設定が噛み合っていないとログインに失敗します。特にsubject、audience、permissions、Azureのロール割り当ては必ず確認してください。
| 設定箇所 | 確認内容 | よくある失敗 |
|---|---|---|
| GitHub workflow | permissions: id-token: writeを設定しているか | OIDCトークンを取得できずazure/loginで失敗する |
| Azure federated credential | subjectが実際のブランチ・タグ・Environmentと一致しているか | main用の設定なのにrelease/*から実行して失敗する |
| GitHub Secrets | AZURE_CLIENT_ID、AZURE_TENANT_ID、AZURE_SUBSCRIPTION_IDを設定しているか | 値の取り違え、別テナントのIDを設定する |
| Azure RBAC | デプロイ先に必要なロールがあるか | ログインは成功するが、デプロイ時に権限不足になる |
| Environment | productionに承認ルールやブランチ制限があるか | 誤って本番へ自動反映される |
GitHub Docsでは、OIDCを使うワークフローにid-token: writeのpermissions設定が必要であり、これはリソースへの書き込み権限を与えるものではなく、OIDCトークンの取得を許可するための設定だと説明されています。(GitHub Docs)
App Serviceへデプロイする基本ワークフロー例
次の例は、GitHub ActionsからAzure App Serviceへデプロイする最小構成に近いサンプルです。実際のプロジェクトでは、ビルドコマンド、テスト、成果物のパス、ブランチ戦略、Environment名を自社の運用に合わせて調整してください。
name: Build and deploy to Azure App Service
on:
push:
branches:
- main
workflow_dispatch:
permissions:
id-token: write
contents: read
env:
AZURE_WEBAPP_NAME: your-app-name
AZURE_WEBAPP_PACKAGE_PATH: .
jobs:
build-and-deploy:
runs-on: ubuntu-latest
environment: production
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Azure login with OIDC
uses: azure/login@v3
with:
client-id: ${{ secrets.AZURE_CLIENT_ID }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
- name: Build
run: |
npm ci
npm run build --if-present
npm test --if-present
- name: Deploy to Azure Web App
uses: azure/webapps-deploy@v3
with:
app-name: ${{ env.AZURE_WEBAPP_NAME }}
package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}
- name: Azure logout
run: az logoutAzure App Serviceへデプロイする場合、公式ドキュメントでは/.github/workflows/配下のYAMLでワークフローを定義し、最低限「認証」「ビルド」「デプロイ」のステップを含める構成が説明されています。また、App Serviceへのデプロイにはazure/webapps-deploy@v3を使用でき、app-nameとpackageの指定が必要です。(Microsoft Learn)
本番運用では、上の例をそのまま貼り付けるだけでなく、次の調整を入れると安全性が上がります。
| 調整項目 | 実務での考え方 |
|---|---|
environment: production | GitHub Environmentsで承認者とブランチ制限を設定する |
package | Node.js/TypeScriptならdist/やbuild/など実際の成果物パスにする |
on.push.branches | 本番はmainのみ、検証はdevelopやrelease/*などに分ける |
| Actionのバージョン | 重要な環境ではタグだけでなく、コミットSHA固定も検討する |
| ログ出力 | Azure CLIの出力に機密情報が混ざらないよう制御する |
Deployment Centerを使う場合の確認ポイント
Azure App Serviceでは、Deployment CenterからGitHub Actionsのデプロイ設定を始められます。既存アプリに対して、アプリケーションスタックに基づいたワークフローファイルを生成し、GitHubリポジトリへコミットする方法が用意されています。また、Deployment Centerではユーザー割り当てIDを使ったOIDC認証を構成できる場合があります。(Microsoft Learn)
ただし、管理者権限が不足していると、ユーザー割り当てマネージドIDの作成や構成でエラーになることがあります。この場合は、Azure管理者が事前にユーザー割り当てマネージドIDを作成し、対象Web Appに必要なロールを割り当てたうえで、開発チームがそのIDを選択する流れにすると運用しやすくなります。Microsoftのドキュメントでも、必要な権限がない場合は既存のユーザー割り当てマネージドIDを選択し、Azure管理者と協力してWebsite Contributorロールを使う旨が説明されています。(Microsoft Learn)
本番デプロイではEnvironmentと保護ルールを必ず使う
mainブランチへのpushだけでproductionに自動反映する構成は、少人数の検証環境では便利ですが、業務システムや顧客向けサービスではリスクがあります。GitHub Environmentsを使うと、デプロイ前の承認者、待機時間、管理者による保護ルールのバイパス可否、許可するブランチやタグを設定できます。(GitHub Docs)
特におすすめなのは、環境を次のように分ける構成です。
| Environment | トリガー例 | 保護ルール |
|---|---|---|
dev | developへのpush | 自動デプロイ可。ただしSecretsは開発用に限定 |
staging | release/*へのpush | チーム内レビュアー1名以上の承認 |
production | mainへのマージ、または手動実行 | 承認必須、自己承認禁止、デプロイ可能ブランチを限定 |
OIDCのフェデレーション資格情報でも、repo:組織/リポジトリ:environment:productionのようにEnvironmentをsubjectに含める設計ができます。これにより、production Environmentを通過したジョブだけが本番用Azure IDを使えるようになります。Azure App Serviceのドキュメントでは、Environmentを使う場合のsubjectや、ブランチ・タグ・pull requestに応じたsubject形式が示されています。(Microsoft Learn)
デプロイスロットを使う場合の注意点
Azure App Serviceのデプロイスロットを使う場合は、azure/webapps-deploy@v3のslot-nameを指定して、productionではなくstagingスロットへデプロイできます。公式ドキュメントでも、slot-nameパラメーターを使ってデプロイスロットへデプロイする例が示されています。(Microsoft Learn)
ただし、OIDCまたはサービスプリンシパル認証を使う場合、IDにはアプリ本体だけでなく対象スロットにも必要なロールが必要です。権限がアプリ本体にしか付いていないと、ログインは成功してもスロットへのデプロイで失敗します。(Microsoft Learn)
スロット運用では、次の流れが現実的です。
| 手順 | 内容 |
|---|---|
| stagingへデプロイ | GitHub Actionsでslot-name: stagingを指定 |
| 動作確認 | ヘルスチェック、ログ確認、DB接続確認 |
| スワップ | Azure側でstagingとproductionを入れ替える |
| ロールバック | 問題があれば再スワップまたは前回成果物を再デプロイ |
古いワークフローから移行する手順
すでにGitHub ActionsでAzureへデプロイしている場合は、いきなりYAMLを書き換えるのではなく、棚卸しから始めると失敗しにくくなります。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 現状把握 | .github/workflows/内のAzureデプロイ処理を洗い出す | publish-profile、AZURE_CREDENTIALS、古いActionを探す |
| 認証方式の分類 | 発行プロファイル、サービスプリンシパル、OIDCを分類する | 本番から優先してOIDC化する |
| Azure ID設計 | 環境ごとにサービスプリンシパルまたはユーザー割り当てIDを用意する | 開発・検証・本番を分離する |
| ロール割り当て | 対象Web App、スロット、リソースグループに必要ロールを付与する | 過剰なContributor権限を避ける |
| フェデレーション資格情報 | GitHubのOrganization、Repository、Branch、Environmentに合わせて設定する | subjectの不一致に注意する |
| YAML更新 | permissions、azure/login、デプロイActionを更新する | id-token: writeを忘れない |
| 検証 | staging環境でpush、手動実行、失敗時のログを確認する | ログに秘密情報が出ていないか確認する |
| 本番展開 | Environment承認付きでproductionへ展開する | ロールバック手順を事前に決める |
GitHubのセキュリティガイドでは、クラウドプロバイダーへのアクセスにはOIDCを使い、短期でスコープを絞ったアクセストークンを作成することが推奨されています。長期保存型シークレットを減らすだけでなく、どのワークフローがどのクラウド権限を使えるかを明確にできる点が大きなメリットです。(GitHub Docs)
よくある失敗と対処法
azure/loginで認証に失敗する
最も多い原因は、permissions: id-token: writeの不足、またはAzure側のフェデレーション資格情報のsubject不一致です。GitHub ActionsのOIDCでは、ワークフローまたはジョブ単位でid-token: writeを設定しないとOIDCトークンを取得できません。(GitHub Docs)
対処として、次の順番で確認してください。
| 確認順 | 見る場所 | チェック内容 |
|---|---|---|
| 1 | GitHub Actions YAML | permissions: id-token: writeがあるか |
| 2 | Azure federated credential | repo:org/repo:ref:refs/heads/mainなどが実行元と一致するか |
| 3 | GitHub Secrets | AZURE_CLIENT_ID、AZURE_TENANT_ID、AZURE_SUBSCRIPTION_IDが正しいか |
| 4 | Azure RBAC | 対象リソースに必要ロールがあるか |
デプロイは成功したのにアプリが動かない
ビルド成果物のパスが間違っている可能性があります。たとえば、ローカルではnpm run build後にdist/へ成果物が出るのに、YAMLではリポジトリルート.をデプロイしているケースです。Node.jsやTypeScriptでは、GitHub Actions上でビルドしてから、実際の出力フォルダーをpackageに指定してください。Azure App Serviceのドキュメントでも、コンパイルが必要なNode.jsアプリでは先にビルドし、dist/やbuild/などのコンパイル済み出力フォルダーをデプロイする考え方が示されています。(Microsoft Learn)
stagingスロットには失敗するが本体には成功する
対象IDにスロット側の権限がない可能性があります。App Serviceのスロットは、本体と同じように権限を確認する必要があります。OIDCまたはサービスプリンシパル認証では、アプリとデプロイスロットの両方にWebsite Contributorなど必要なロールがあるか確認してください。(Microsoft Learn)
ログに余計な情報が出る
Azure Login ActionのMarketplaceページでは、Azure CLIコマンドの出力は標準出力へ表示され、Actionのビルドログに保存されるため、必要に応じてAZURE_CORE_OUTPUTをnoneに設定することが案内されています。デプロイログは障害調査に必要ですが、サブスクリプション情報、リソース名、接続先などを不用意に出しすぎないようにしましょう。(GitHub)
例として、ワークフロー全体に次の環境変数を入れると、Azure CLIの既定出力を抑制できます。
env:
AZURE_CORE_OUTPUT: none必要なコマンドだけ出力したい場合は、そのコマンドに明示的な--output tableや--output jsonを付けるなど、ログに残す内容を限定します。
Actionのバージョン固定とサプライチェーン対策
Azureへのデプロイワークフローは、クラウド環境へアクセスする強い権限を持ちます。そのため、uses:で参照するActionの管理も重要です。GitHubのセキュリティガイドでは、サードパーティActionの侵害がSecretsやGITHUB_TOKENへのアクセスにつながる可能性があり、Actionをフル長のコミットSHAに固定することが、immutable releaseとして使う唯一の方法だと説明されています。(GitHub Docs)
実務では、次のように段階的に進めると現実的です。
| レベル | 対応 | 向いている環境 |
|---|---|---|
| 最低限 | 公式・信頼できるActionのみ使い、古いActionを削除する | 小規模開発、検証環境 |
| 標準 | @v3などメジャーバージョンを固定し、Dependabotで更新確認する | 一般的な業務システム |
| 強化 | フル長コミットSHAで固定し、更新PRをレビューする | 本番、金融・医療・重要システム |
| 組織管理 | Organizationポリシーで許可ActionやSHA pinningを制御する | 複数チーム・複数リポジトリ運用 |
タグ指定は読みやすく便利ですが、タグは移動・削除される可能性があります。productionへデプロイするワークフローでは、少なくとも利用Actionの棚卸しと更新ルールを決めておきましょう。
管理者と開発者が今すぐ確認すべきチェックリスト
| 対象 | チェック項目 | 優先度 |
|---|---|---|
| Azure管理者 | GitHub Actions用IDが環境ごとに分かれているか | 高 |
| Azure管理者 | ロールが対象リソースまたはリソースグループに限定されているか | 高 |
| Azure管理者 | フェデレーション資格情報のsubjectがブランチ・Environmentと一致しているか | 高 |
| GitHub管理者 | production Environmentに承認者とブランチ制限があるか | 高 |
| GitHub管理者 | .github/workflows/の変更にCODEOWNERSレビューがあるか | 中 |
| 開発者 | permissions: id-token: writeとcontents: readを明示しているか | 高 |
| 開発者 | publish-profileやAZURE_CREDENTIALSを使い続けていないか | 高 |
| 開発者 | ビルド成果物のパスを正しくpackageに指定しているか | 中 |
| 開発者 | デプロイスロットの権限とslot-nameを確認しているか | 中 |
| DevOps担当 | Actionのバージョン固定、更新、監査ルールを決めているか | 中 |
まとめ：まずは認証方式と本番保護から見直す
Using GitHub Actions to Deploy to Azureは、GitHub ActionsでAzureへデプロイする基本的な考え方を知る入口として有用です。ただし、2026年時点で実運用に適用するなら、古いサンプルをそのまま使うのではなく、OIDC認証、個別のAzure Actions、GitHub Environments、最小権限のAzure RBACを前提に設計し直すべきです。
まず取り組むべきことは、.github/workflows/内のAzureデプロイワークフローを棚卸しし、発行プロファイルや長期保存型シークレットを使っている箇所を特定することです。そのうえで、開発・検証・本番の順にOIDCへ移行し、productionにはEnvironmentの承認ルールとブランチ制限を入れてください。
Azureデプロイの自動化は、単に「pushしたら反映される」仕組みではありません。誰が、どのブランチから、どの権限で、どのAzureリソースへデプロイできるのかを明確にすることで、GitHub Actionsは安全で再現性の高いCI/CD基盤になります。
コメント