Azure Functions を GitHub Actions でデプロイしている、またはこれから CI/CD 化する場合、今回まず確認すべきポイントは「YAML ワークフローの配置場所」「認証方式」「Flex Consumption plan でのデプロイ復旧手順」の3つです。GitHub Actions 連携そのものに一律の移行期限が示されたわけではありませんが、Linux Consumption plan や古いランタイムを使っている環境では、ホスティング移行とデプロイ方式の見直しを同時に進める必要があります。Microsoft Learn の該当ページは、Azure Functions のコード更新を GitHub Actions で自動ビルド・自動デプロイするための手順を説明しており、ワークフローは /.github/workflows/ 配下の YAML ファイルで管理します。(Microsoft Learn)
Azure Functions の GitHub Actions 連携で何を確認すべきか
Azure の「Use GitHub Actions to make code updates in Azure Functions」は、GitHub リポジトリにある Azure Functions プロジェクトを、GitHub Actions のワークフローでビルドし、既存の Function App にデプロイするための公式ガイドです。ワークフローは言語にかかわらず、環境セットアップ、コードのビルド、Azure Functions へのパッケージデプロイという流れで動きます。(Microsoft Learn)
2026年7月2日の公式 GitHub 履歴では、Flex Consumption plan のデプロイ復旧ガイドへの導線追加が確認できます。Microsoft Learn 本文の最終更新表示は 2026年3月2日ですが、GitHub 上のドキュメント履歴では 2026年7月2日に functions-how-to-github-actions.md の Next steps が更新され、「Recover from a bad Flex Consumption plan deployment」へのリンクが追加されています。(GitHub)
| 確認項目 | 実務上の意味 | 管理者が見るべきポイント |
|---|---|---|
| ワークフローの配置 | /.github/workflows/ に YAML を置き、push などを契機にデプロイする | リポジトリ、ブランチ、デプロイ先 Function App が正しいか |
| 認証方式 | GitHub Actions が Azure に接続する方法を決める | 本番では OIDC またはユーザー割り当てマネージド ID を優先検討する |
| 発行プロファイル | 手軽だが強い権限を持つ資格情報として扱う必要がある | GitHub Secrets に保存し、Basic 認証の利用有無を管理する |
| Flex Consumption plan | デプロイ方式や復旧手順が他プランと異なる | remote-build、sku、ロールバック手順を確認する |
| Linux Consumption plan | 廃止予定があるため中長期の影響が大きい | 2028年9月30日までの移行計画を作る |
今回の更新ポイントは「デプロイ手順」だけでなく「復旧設計」まで見ること
従来の Azure Functions の GitHub Actions 記事は、ワークフローの作り方や発行プロファイルを使ったデプロイ手順が中心でした。今回注目すべき点は、Flex Consumption plan の利用が広がる中で、デプロイ失敗時にどう戻すかまで運用設計に含める必要があることです。
Flex Consumption plan では、コードは zip パッケージとして Blob Storage コンテナーに配置され、各デプロイで現在のパッケージが上書きされます。プラットフォーム側に以前のリビジョンを保持する組み込み履歴はなく、デプロイ スロットも現在サポートされていません。つまり、障害時に戻れるかどうかは、Git の履歴、CI/CD の実行履歴、アプリ設定の管理方法に大きく依存します。(Microsoft Learn)
特に本番環境では、GitHub Actions を「自動デプロイの仕組み」としてだけ見るのでは不十分です。以下まで含めて設計すると、障害時の復旧が現実的になります。
| 設計対象 | 不十分な例 | 推奨される考え方 |
|---|---|---|
| コード | main ブランチに push したら即本番反映 | PR レビュー、ブランチ保護、環境別承認を入れる |
| 依存関係 | ビルド時に常に最新パッケージを取得 | lock ファイルやバージョン固定で再現性を高める |
| アプリ設定 | Azure ポータルで手動変更 | JSON、Bicep、Terraform などで管理する |
| ロールバック | 障害後に手作業で zip を探す | 直前の成功ワークフロー再実行、git revert、hotfix の手順を決める |
| 監視 | デプロイ完了だけを見る | Application Insights、ヘルスチェック、アラートまで組み込む |
GitHub Actions で Azure Functions を更新する基本構成
Azure Functions の GitHub Actions ワークフローは、基本的に次の流れで構成します。
- GitHub リポジトリに Functions のソースコードを置く
/.github/workflows/に YAML ファイルを作成する- 言語ごとのビルド環境をセットアップする
- アプリをビルドする
Azure/functions-actionで Function App にデプロイする
公式ドキュメントでは、ワークフローを手動で作る方法のほか、Azure portal、Azure CLI、GitHub リポジトリ上のテンプレートから生成する方法が案内されています。(Microsoft Learn)
代表的な構成イメージは次のとおりです。
name: Deploy Azure Functions
on:
push:
branches:
- main
env:
AZURE_FUNCTIONAPP_NAME: your-function-app-name
AZURE_FUNCTIONAPP_PACKAGE_PATH: '.'
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v4
- name: Build application
run: |
echo "ここに言語ごとのビルド処理を記述"
- name: Deploy to Azure Functions
uses: Azure/functions-action@v1
with:
app-name: ${{ env.AZURE_FUNCTIONAPP_NAME }}
package: ${{ env.AZURE_FUNCTIONAPP_PACKAGE_PATH }}実際には、.NET、Java、Node.js、Python、PowerShell など、言語ごとにセットアップアクションやビルドコマンドが変わります。公式テンプレートをそのままコピーするだけでなく、自社のランタイムバージョン、パッケージパス、テスト実行、承認フローに合わせて調整してください。
影響範囲：開発者、Azure 管理者、セキュリティ担当の全員に関係する
この変更・確認ポイントは、単に Azure Functions の開発者だけに関係するものではありません。GitHub Actions から Azure にデプロイする以上、リポジトリ権限、Azure RBAC、Secrets、ホスティングプラン、監視運用まで影響します。
| 対象者 | 影響範囲 | 確認すべき内容 |
|---|---|---|
| 開発者 | ワークフロー YAML、ビルド、テスト | package のパス、言語バージョン、依存関係の固定 |
| Azure 管理者 | Function App、ホスティングプラン、認証 | Flex Consumption、Consumption、Dedicated などの違い |
| セキュリティ担当 | GitHub Secrets、OIDC、発行プロファイル | 長期シークレットを減らし、最小権限にする |
| 運用担当 | デプロイ監視、障害時復旧 | ロールバック手順、ヘルスチェック、アラート |
| グローバル運用担当 | 複数リージョン、ソブリンクラウド | azure/login の environment や audience の指定要否 |
GitHub Actions 公式リポジトリでは、Azure Functions action の認証方式として OIDC、サービスプリンシパル、発行プロファイルが説明されています。このうち OIDC は推奨方式として扱われ、ユーザー割り当てマネージド ID と RBAC を使って、GitHub 側に長期シークレットを持たせずに Azure へ認証できます。(GitHub)
認証方式は本番運用の最重要ポイント
Azure Functions を GitHub Actions からデプロイする場合、最も注意すべきなのは認証方式です。Microsoft Learn の手順では発行プロファイルを GitHub Secrets に保存する方法が案内されていますが、発行プロファイルは Azure リソースへアクセスできる重要な資格情報であり、安全に保管する必要があります。(Microsoft Learn)
一方で、Azure/functions-action 側の最新の考え方では、OIDC が推奨方式として説明されています。発行プロファイルは GitHub にユーザー名とパスワード相当の情報を保存し、HTTP Basic 認証で scm エンドポイントへアクセスするため、本番環境では優先度を下げるのが現実的です。(GitHub)
| 認証方式 | 向いている場面 | 注意点 |
|---|---|---|
| OIDC | 本番、複数環境、セキュリティ重視の組織 | ユーザー割り当てマネージド ID、フェデレーション資格情報、RBAC 設計が必要 |
| ユーザー割り当て ID | Azure portal の Deployment Center から構成する場合 | GitHub リポジトリ、ブランチ、Azure 側権限の対応を明確にする |
| サービスプリンシパル | 既存の自動化資産がある場合 | クライアントシークレットのローテーション管理が必要 |
| 発行プロファイル | 検証環境、簡易セットアップ | GitHub Secrets への保存、Basic 認証の有効化、漏えい時の影響に注意 |
| Basic 認証 | 既存手順の維持 | SCM Basic Auth Publishing Credentials を有効にする必要があり、長期利用は慎重に判断する |
既存の Function App に GitHub Actions を追加する場合、Azure portal の Deployment Center では、GitHub をソースとして選び、認証設定でユーザー割り当て ID または Basic 認証資格情報を選択できます。保存前に追加されるワークフローファイルをプレビューできるため、管理者はその場で YAML のデプロイ先、ブランチ、認証方式を確認してください。(Microsoft Learn)
Azure portal、CLI、手動テンプレートの使い分け
GitHub Actions ワークフローは、主に3つの方法で作成できます。どれが正解というより、組織の管理レベルに合わせて選ぶのが重要です。
| 作成方法 | 向いているケース | メリット | 注意点 |
|---|---|---|---|
| Azure portal | 初回構成、既存 Function App への追加 | GUI でリポジトリ、ブランチ、認証を選べる | 生成された YAML を必ずレビューする |
| Azure CLI | 標準化、自動化、複数環境への展開 | コマンド化しやすい | GitHub 認証や権限の準備が必要 |
| GitHub テンプレート | 開発チーム主導の導入 | リポジトリ側で完結しやすい | Azure 側の認証・権限設計を別途確認する |
| 手動 YAML | 高度な CI/CD、承認フロー、テスト統合 | 柔軟性が高い | テンプレートとの差分管理が必要 |
Azure CLI では、次のようなコマンドでワークフロー構成を追加できます。公式手順では、このコマンドにより適切なテンプレートから YAML が生成され、/.github/workflows/ に保存され、発行プロファイルも GitHub Secrets に追加されます。(Microsoft Learn)
az functionapp deployment github-actions add \
--repo "githubUser/githubRepo" \
-g MyResourceGroup \
-n MyFunctionapp \
--login-with-githubただし、本番環境では「コマンドが成功したか」だけで完了にしないでください。生成された YAML を確認し、次の項目をレビューします。
AZURE_FUNCTIONAPP_NAMEが本番・検証・開発のどれを指しているかAZURE_FUNCTIONAPP_PACKAGE_PATHがリポジトリ内の正しいプロジェクトを指しているかmainへの push だけで本番反映されないか- テストや静的解析がデプロイ前に実行されているか
- GitHub Environment の承認や保護ルールを使うべきか
- 認証が OIDC、ユーザー割り当て ID、発行プロファイルのどれか
ホスティングプラン別にデプロイ方式が変わる
Azure Functions は、ホスティングプランによってデプロイの挙動が変わります。GitHub Actions の YAML をコピーしても、プランに合っていなければ、デプロイ失敗や実行時エラーの原因になります。
公式ドキュメントでは、Flex Consumption plan は One deploy、Windows の Consumption plan は Zip deploy、Linux の Consumption plan は外部パッケージ URL を使うなど、プランごとの違いが示されています。また、Linux Consumption plan でアプリを実行する機能は廃止予定であることも明記されています。(Microsoft Learn)
| ホスティングプラン | 主なデプロイ方式 | GitHub Actions での注意点 |
|---|---|---|
| Flex Consumption | One deploy | remote-build、sku、復旧手順を確認する |
| Consumption Windows | Zip deploy | Windows 前提のテンプレート、ランタイム対応を確認する |
| Consumption Linux | 外部パッケージ URL | 廃止予定を踏まえ、Flex Consumption への移行を検討する |
| Elastic Premium | Zip deploy | スロットやネットワーク要件を含めて設計する |
| Dedicated App Service | Zip deploy | App Service 側の構成、スロット、権限を確認する |
Flex Consumption plan では、発行プロファイルで認証する場合に sku: flexconsumption が必要です。さらに、remote-build: true を使う場合、Flex Consumption では Oryx build がリモートビルド中に常に実行されるため、scm-do-build-during-deployment や enable-oryx-build は設定しないよう案内されています。(Microsoft Learn)
Linux Consumption plan 利用中なら移行期限を必ず確認する
GitHub Actions 連携そのものに対して、今回の公式情報で一律の移行期限が示されたわけではありません。ただし、Azure Functions のホスティングプランには重要な期限があります。
Microsoft Learn では、Linux の Consumption plan で実行されている Azure Functions v3 ランタイムのアプリは、2026年9月30日以降停止すると説明されています。また、Linux Consumption plan で Function App をホストするオプションは 2028年9月30日に廃止予定であり、対象アプリは Flex Consumption plan への移行が推奨されています。(Microsoft Learn)
| 対象 | 期限 | 対応 |
|---|---|---|
| Linux Consumption plan 上の v3 ランタイム | 2026年9月30日以降停止 | v4 ランタイムへ移行 |
| Linux Consumption plan のホスティング | 2028年9月30日廃止予定 | Flex Consumption plan への移行を計画 |
| Windows Consumption plan | 現時点で同じ影響は明記されていない | 継続監視しつつ、将来移行を検討 |
| GitHub Actions 連携 | 一律の移行期限は明記なし | 認証、YAML、復旧設計を見直す |
ここで重要なのは、ホスティング移行と CI/CD 移行を別々に進めないことです。Flex Consumption plan へ移行するなら、GitHub Actions のパラメーター、ロールバック手順、アプリ設定の管理方式も同時に変更対象になります。
Flex Consumption plan ではロールバック手順を事前に決める
Flex Consumption plan で悪いデプロイが入った場合、公式ガイドでは主に3つの復旧方法が示されています。
| 復旧方法 | 使う場面 | 特徴 |
|---|---|---|
| 以前の成功ワークフローを再実行 | 正常な過去バージョンがある | 最も速いが、依存関係や Secrets は再実行時点の状態に影響される |
git revert して push | 壊したコミットを戻したい | Git 履歴を前に進めながら修正できる |
| hotfix commit を push | 原因が分かっている | 修正内容をレビュー・テストできるが時間がかかる |
公式ガイドでは、過去の成功 run を再実行すると、その run をトリガーした元の commit SHA がチェックアウトされ、コードと設定ファイルが再ビルド・再デプロイされると説明されています。ただし、元のバイナリアーティファクトをそのまま再利用するわけではないため、依存パッケージが取得可能であること、lock ファイルで再現性を確保していることが重要です。(Microsoft Learn)
また、再実行では GitHub Secrets やパイプライン変数は再実行時点の値で解決されます。つまり、シークレットをローテーションした後に古い run を再実行すると、当時のシークレットではなく現在の値が使われます。この挙動は、障害時の切り戻し手順に必ず書いておくべきです。(Microsoft Learn)
アプリ設定をコードと一緒に管理しないと、完全な復旧は難しい
Azure Functions の障害復旧でよくある失敗は、コードだけ GitHub で管理し、アプリ設定は Azure portal で手動管理しているケースです。この状態では、GitHub Actions の過去 run を再実行しても、コードは戻せますが、設定の差分までは安全に戻せません。
Flex Consumption の復旧ガイドでは、完全なロールバックを行うにはアプリ設定をソース管理し、デプロイの一部として適用する必要があると説明されています。設定管理の方法として、ワークフロー内で JSON を使って app settings を適用する方法と、Bicep で siteConfig.appSettings を宣言する方法が示されています。(Microsoft Learn)
| 管理方法 | 向いている環境 | メリット | 注意点 |
|---|---|---|---|
| JSON + Azure CLI | 小規模、導入初期 | 始めやすい | 未宣言設定の削除や漏れに注意 |
| Bicep | 本番、複数環境、IaC 運用 | drift 検出やレビューに向く | Bicep の設計・運用スキルが必要 |
| 手動設定 | 一時検証のみ | すぐ変更できる | 再現性が低く、本番復旧に不向き |
本番環境では、FUNCTIONS_WORKER_RUNTIME、AzureWebJobsStorage、Application Insights、接続文字列、機能フラグなどを一覧化し、どれをコード管理し、どれを Key Vault 参照にするかを決めてください。特に接続情報は、可能な範囲でマネージド ID ベースの接続を使い、どうしてもシークレットが必要な場合は Key Vault 参照を使う構成が現実的です。(Microsoft Learn)
よくある設定ミスと回避策
GitHub Actions による Azure Functions デプロイでは、YAML の小さなミスが本番障害につながることがあります。以下は特に確認すべきポイントです。
| ミス | 起きる問題 | 回避策 |
|---|---|---|
package: . のままモノレポに適用 | 不要なファイルまでデプロイされる | Function App のプロジェクトパスを明示する |
| 発行プロファイルをローテーション後、GitHub Secret を更新しない | デプロイ時に認証エラーが発生する | ローテーション手順に Secret 更新を含める |
Flex Consumption で remote-build と Kudu/Oryx 関連設定を混在 | ビルド方式が不整合になる | Flex 向けパラメーターを公式仕様に合わせる |
| Python Functions を Windows 前提で構成 | テンプレート選定を誤る | Python は Linux テンプレートを選ぶ |
slot-name を Flex Consumption で使う | サポート外構成になる | Flex では別アプリやローリング更新戦略を検討する |
| アプリ設定を portal 手動管理 | ロールバックしても設定が戻らない | JSON、Bicep、IaC に寄せる |
| テストなしで main push 即デプロイ | 障害がそのまま本番へ反映 | PR、テスト、承認、環境保護を入れる |
Azure/functions-action のパラメーター説明では、publish-profile をローテーションした場合、GitHub Secret も更新しないと /api/settings へのアクセスで 401 エラーが発生すると説明されています。respect-funcignore は既定で false のため、.funcignore を使って除外したいファイルがある場合は明示的に true を指定することも検討してください。(GitHub)
グローバル環境での確認ポイント
グローバル展開している企業では、単一リージョン・単一サブスクリプションだけを前提にしないことが重要です。Azure Functions と GitHub Actions の連携では、環境ごとに認証、ネットワーク、リージョン、監査要件が異なります。
特にソブリンクラウドや Azure Stack Hub で OIDC またはサービスプリンシパル認証を使う場合、azure/login の environment や audience パラメーターを含める必要がある場合があります。(GitHub)
| 観点 | 確認内容 |
|---|---|
| リージョン | Flex Consumption plan の対応リージョン、既存アプリの配置 |
| クラウド種別 | Public Azure、Azure Government、Azure China、Azure Stack Hub |
| 認証 | OIDC の federation 設定、RBAC スコープ、ユーザー割り当て ID |
| ネットワーク | VNet 統合、Private Endpoint、GitHub-hosted runner からの到達性 |
| 監査 | GitHub Actions の実行履歴、Azure Activity Log、Application Insights |
| 権限分離 | 開発、検証、本番で GitHub Environment と Azure リソースを分ける |
大規模環境では、1つの YAML を全環境で共有するより、共通テンプレートと環境別パラメーターを分けるほうが安全です。たとえば、dev は自動デプロイ、staging はテスト後に自動、production は GitHub Environment の承認後に実行、といった段階的な設計にします。
管理者が今すぐ確認すべきチェックリスト
まずは、既存の Azure Functions と GitHub Actions の棚卸しから始めてください。特に Linux Consumption plan、発行プロファイル認証、本番直結の push トリガーがある環境は優先度が高いです。
| 優先度 | 確認項目 | 判断基準 |
|---|---|---|
| 高 | Linux Consumption plan の利用有無 | 2028年9月30日の廃止予定に向けて移行計画があるか |
| 高 | v3 ランタイムの利用有無 | Linux Consumption では 2026年9月30日以降停止の影響を受けないか |
| 高 | 認証方式 | 本番で発行プロファイルや Basic 認証に依存していないか |
| 高 | GitHub Secrets | 発行プロファイル、サービスプリンシパル秘密情報が適切に管理・ローテーションされているか |
| 中 | YAML のデプロイ先 | 本番 Function App 名、ブランチ、パッケージパスが正しいか |
| 中 | Flex Consumption パラメーター | sku、remote-build、不要な Kudu/Oryx 設定を確認したか |
| 中 | アプリ設定 | portal 手動変更ではなく、コードまたは IaC で管理しているか |
| 中 | ロールバック手順 | 過去 run の再実行、git revert、hotfix の手順が文書化されているか |
| 低 | テンプレート差分 | 公式テンプレートの更新を定期的に確認しているか |
実務での推奨対応
これから新しく Azure Functions の CI/CD を作るなら、OIDC 認証、環境別ブランチまたは GitHub Environment、デプロイ前テスト、アプリ設定のコード管理を前提に設計するのが安全です。検証環境であれば発行プロファイルから始めることもできますが、その場合でも本番導入前に OIDC へ切り替える計画を立てておくべきです。
既に GitHub Actions でデプロイしている場合は、次の順序で見直すと効率的です。
- すべての Function App のホスティングプラン、OS、ランタイムを一覧化する
- Linux Consumption plan と v3 ランタイムを優先的に抽出する
- GitHub Actions の YAML、Secrets、認証方式を確認する
- 本番デプロイに PR、テスト、承認が入っているか確認する
- Flex Consumption plan では復旧ガイドに沿ってロールバック手順を作る
- アプリ設定を JSON、Bicep、Terraform などで管理する方針を決める
- 直近の成功 run を使った復旧訓練を行う
Azure Functions の GitHub Actions 連携は、単に「push したら自動でデプロイできる」仕組みではありません。認証を安全にし、ホスティングプランごとの違いを理解し、失敗時に戻れる CI/CD として設計して初めて、本番運用で安心して使えます。今回の確認では、YAML の有無だけでなく、OIDC への移行余地、Flex Consumption plan の復旧手順、Linux Consumption plan の期限対応までまとめて点検してください。
コメント