Azure SQL の GitHub Actions 連携として調べている場合、まず注意すべき点は、公式ページ「Quickstart: Connect with GitHub Actions – Azure Database for PostgreSQL」が Azure SQL Database ではなく、Azure Database for PostgreSQL フレキシブル サーバー向けのクイックスタートであることです。内容の中心は、GitHub Actions ワークフローから PostgreSQL のデータベース更新をデプロイする手順で、認証には Microsoft Entra ID、GitHub Secrets、Azure Login Action、azure/postgresql@v1 を使います。(Microsoft Learn)
一方で、Azure SQL Database 向けにも GitHub Actions の公式クイックスタートは別に用意されており、こちらは .dacpac と azure/[email protected] を使う構成です。つまり、管理者が最初に確認すべきなのは「対象が Azure SQL Database なのか、Azure Database for PostgreSQL なのか」です。ここを取り違えると、接続文字列、デプロイ対象ファイル、実行ランナー、GitHub Secrets の名前、利用する Action がすべてずれます。(Microsoft Learn)
Azure SQL の新機能・変更点：「Quickstart: Connect with GitHub Actions – Azure Database for PostgreSQL」で確認すべきポイント
今回の公式情報で押さえるべきポイントは、GitHub Actions から Azure Database for PostgreSQL フレキシブル サーバーへ接続し、SQL ファイルをデプロイする標準的な流れが整理されていることです。ワークフローは /.github/workflows/ 配下の YAML ファイルで定義し、大きく「認証」と「デプロイ」の2段階で構成します。(Microsoft Learn)
特に重要なのは、Azure への認証方式として OpenID Connect（OIDC） と サービス プリンシパル の2系統が示されている点です。OIDC を使う場合は、Microsoft Entra アプリケーションまたはユーザー割り当てマネージド ID にフェデレーション ID 資格情報を構成し、GitHub Actions が発行するトークンを信頼させます。(Microsoft Learn)
実務では、従来のクライアント シークレット方式をそのまま使い続けるより、OIDC へ寄せる設計を優先して検討した方がよいでしょう。Azure Login Action の公式リポジトリでも、セキュリティ向上の観点から OIDC ベースの認証が推奨されています。(GitHub)
これは Azure SQL Database 向けの手順ではない
記事タイトルや検索結果だけを見ると、Azure SQL の GitHub Actions 連携と混同しやすいですが、公式ソースのメタデータ上も対象サービスは azure-database-postgresql です。GitHub Actions から扱うデータベース更新という意味では似ていますが、Azure SQL Database と Azure Database for PostgreSQL では、使うアクションもデプロイ成果物も異なります。(GitHub)
| 確認項目 | Azure Database for PostgreSQL | Azure SQL Database |
|---|---|---|
| 公式クイックスタートの対象 | PostgreSQL フレキシブル サーバー | Azure SQL Database |
| 主なデプロイファイル | data.sql などの SQL ファイル | Database.dacpac |
| GitHub Action | azure/postgresql@v1 | azure/[email protected] |
| 接続文字列の Secret 例 | AZURE_POSTGRESQL_CONNECTION_STRING | AZURE_SQL_CONNECTION_STRING |
| 公式例のランナー | ubuntu-latest | windows-latest |
| 主な用途 | PostgreSQL への SQL スクリプト適用 | Azure SQL Database への DACPAC 発行 |
Azure SQL Database の更新作業を自動化したい場合は、PostgreSQL 用の azure/postgresql@v1 ではなく、Azure SQL 用の azure/[email protected] と .dacpac を使う必要があります。逆に、PostgreSQL のスキーマ変更や初期データ投入を GitHub Actions で流したい場合は、今回の PostgreSQL 向けクイックスタートが参考になります。(Microsoft Learn)
公式情報の日付で注意したい点
本稿で確認できる Microsoft Learn の日本語ページでは、ページ下部に「Last updated on 2025-12-22」と表示されています。また、GitHub 上のドキュメントソースでは ms.date が 02/10/2025 と記載されています。2026年6月25日付の更新情報として社内で確認対象になっている場合でも、実装や記事公開の前には Microsoft Learn の表示日、GitHub の履歴、対象ブランチを確認しておくと安全です。(Microsoft Learn)
この点は、単なる日付の問題ではありません。Microsoft Learn の記事は再構成、翻訳反映、関連 include ファイルの更新、メタデータ更新などで表示内容が変わることがあります。管理者は「更新日だけを見る」のではなく、実際に変更された要素が認証方式なのか、Action のバージョンなのか、接続文字列の扱いなのかを切り分ける必要があります。
影響範囲：誰が確認すべきか
このクイックスタートの影響を受けるのは、PostgreSQL を Azure 上で運用している開発チームだけではありません。GitHub Actions、Microsoft Entra ID、Azure RBAC、ネットワーク制御、データベース接続情報が関わるため、複数の担当者で確認する必要があります。
| 担当領域 | 確認すべき内容 | 放置した場合のリスク |
|---|---|---|
| DevOps / CI/CD 担当 | ワークフロー YAML、Action バージョン、トリガー条件 | 本番環境への意図しないデプロイ、ワークフロー失敗 |
| Azure 管理者 | Microsoft Entra アプリ、フェデレーション資格情報、RBAC | 過剰権限、認証失敗、監査不備 |
| DB 管理者 | 接続先 DB、SQL ファイル、実行順序、権限 | 誤った DB への変更、スキーマ破損 |
| セキュリティ担当 | GitHub Secrets、環境シークレット、ログ出力 | 接続文字列やトークンの漏えい |
| ネットワーク担当 | PostgreSQL のファイアウォール、ランナーの到達性 | GitHub Actions から DB に接続できない |
特に本番環境で利用する場合は、「GitHub Actions が Azure にログインできるか」だけでは不十分です。どのブランチから実行できるのか、誰の承認で本番 Secret にアクセスできるのか、どの SQL がどの順番で実行されるのかまで確認する必要があります。
設定変更の要点
今回のクイックスタートで実際に設定する主な項目は、次の4つです。
| 設定項目 | 内容 | 実務での確認ポイント |
|---|---|---|
| Azure 側の認証情報 | Microsoft Entra アプリまたはユーザー割り当てマネージド ID | OIDC を使うならフェデレーション ID 資格情報を設定する |
| GitHub Secrets | AZURE_CLIENT_ID、AZURE_TENANT_ID、AZURE_SUBSCRIPTION_ID、接続文字列 | 値を YAML に直書きしない |
| PostgreSQL 接続文字列 | Azure Portal の接続画面から取得する ADO.NET 接続文字列 | パスワードを含むため Secret として扱う |
| ワークフロー YAML | azure/login と azure/postgresql@v1 を組み合わせる | 対象ブランチ、実行権限、ログ出力を確認する |
Microsoft Learn では、Azure Portal の PostgreSQL フレキシブル サーバーから接続文字列をコピーし、{your_password} を実パスワードに置き換えたうえで GitHub Secret として使う流れが示されています。接続文字列の例には、サーバー名、データベース名、ポート 5432、ユーザー ID、パスワード、SSL 必須設定が含まれます。(Microsoft Learn)
OIDC とサービス プリンシパルの違い
GitHub Actions から Azure にログインする方法は、大きく分けて OIDC とサービス プリンシパルのクライアント シークレット方式があります。新しく構成するなら、まず OIDC を検討するのが現実的です。
| 認証方式 | 特徴 | 向いているケース | 注意点 |
|---|---|---|---|
| OIDC | GitHub Actions が発行するトークンを Microsoft Entra ID 側で信頼する | 新規構築、本番環境、シークレット削減を重視する環境 | フェデレーション ID 資格情報と id-token: write の設定が必要 |
| サービス プリンシパル Secret | AZURE_CREDENTIALS などにクライアント シークレットを保存する | 既存ワークフローの暫定運用、短期検証 | シークレットの有効期限管理、漏えい対策、ローテーションが必要 |
| ユーザー割り当てマネージド ID | Azure リソースに紐づく ID を使う | self-hosted runner など Azure 内で完結する構成 | public repository の self-hosted runner では慎重な設計が必要 |
OIDC を使う場合、Azure Login Action の公式例では、ワークフローまたはジョブの permissions に id-token: write を設定する必要があると説明されています。これを忘れると、azure/login の設定値が正しくても OIDC トークンを取得できず、ログインに失敗します。(GitHub)
実務向けのワークフロー例
公式クイックスタートの構成要素を、実務で確認しやすい形に整理すると次のようになります。Action のメジャーバージョンは、組織で検証済みのものに固定し、更新時はリリースノートや公式リポジトリを確認してください。
name: PostgreSQL for GitHub Actions
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
permissions:
id-token: write
contents: read
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v4
- name: Azure login with OIDC
uses: azure/login@v2
with:
client-id: ${{ secrets.AZURE_CLIENT_ID }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
- name: Deploy SQL file to Azure Database for PostgreSQL
uses: azure/postgresql@v1
with:
server-name: POSTGRESQL_SERVER_NAME
connection-string: ${{ secrets.AZURE_POSTGRESQL_CONNECTION_STRING }}
plsql-file: './data.sql'
- name: Azure logout
run: az logoutこの例で特に確認したいのは、AZURE_POSTGRESQL_CONNECTION_STRING に本番 DB の接続文字列を入れる場合です。main ブランチへの push で即時に SQL が適用される設計にすると、レビューを通過していない変更が本番 DB に入る可能性があります。本番向けには、GitHub Environments の承認、保護ブランチ、手動実行、ステージング環境での事前検証を組み合わせるべきです。
GitHub Secrets は repository secrets より environment secrets を優先する
公式ページでは、GitHub Secrets にクライアント ID、テナント ID、サブスクリプション ID、接続文字列などを保存する流れが説明されています。パブリック リポジトリでは、repository secrets ではなく environment secrets を使うと、承認が完了するまでジョブが Secret にアクセスできない構成にできます。(Microsoft Learn)
実務では、次のように分けると管理しやすくなります。
| Secret 名 | 用途 | 管理上の注意 |
|---|---|---|
AZURE_CLIENT_ID | Entra アプリまたはマネージド ID のクライアント ID | OIDC でも Secret として保存する |
AZURE_TENANT_ID | Microsoft Entra テナント ID | 複数テナント運用では環境ごとに分ける |
AZURE_SUBSCRIPTION_ID | 対象 Azure サブスクリプション | 本番・検証で取り違えない |
AZURE_POSTGRESQL_CONNECTION_STRING | PostgreSQL 接続文字列 | パスワードを含むため最重要 Secret として扱う |
AZURE_CREDENTIALS | サービス プリンシパル Secret 方式で使う JSON | OIDC 移行後は不要になったものを削除する |
接続文字列にはパスワードが含まれます。誤ってログに出力したり、デバッグ用に echo したり、YAML に直書きしたりしないでください。
ネットワークとファイアウォールで失敗しやすい
GitHub Actions から PostgreSQL に接続できない場合、認証情報よりもネットワーク制御が原因になっていることがあります。Azure PostgreSQL Action の公式リポジトリでは、GitHub Actions のランナーから PostgreSQL サーバーへ通信するには、ランナーの IP アドレスがファイアウォールで許可されている必要があると説明されています。(GitHub)
GitHub-hosted runner は実行ごとに IP が変わる可能性があるため、本番環境では安易に広い IP 範囲を許可しない方が安全です。現実的には、次のいずれかを検討します。
| 方法 | メリット | 注意点 |
|---|---|---|
| Action によるファイアウォール例外の自動追加 | 手早く動作確認できる | 追加・削除に必要な権限が大きくなりやすい |
| CLI / PowerShell で明示的にファイアウォールを管理 | 変更履歴を残しやすい | 実装と運用ルールが必要 |
| self-hosted runner を固定ネットワークに置く | 接続元を固定しやすい | runner の保護、更新、アクセス制御が必要 |
| プライベート接続を前提に設計する | 本番向き | 初期設計とネットワーク構成が重くなる |
ファイアウォール例外の自動追加を使う場合、Azure Login Action を先に実行し、ファイアウォール ルールを作成できる十分な権限を持たせる必要があると説明されています。権限を増やせば動くようになる一方で、CI/CD に過剰権限を与えるリスクも高まります。(GitHub)
ログ出力にも注意が必要
Azure Login Action の公式リポジトリでは、Azure CLI コマンドの出力は標準出力に表示され、その内容が GitHub Actions のビルドログに保存される可能性があると警告しています。不要な出力を抑制するには、AZURE_CORE_OUTPUT を none に設定する方法が示されています。(GitHub)
たとえば、ワークフロー内で Azure CLI を追加実行する場合は、次のようにログ出力を抑える設計を検討します。
env:
AZURE_CORE_OUTPUT: noneただし、すべての出力を消すと障害調査が難しくなることがあります。実務では、通常時は出力を抑え、失敗時だけ必要最小限の情報を出すようにします。接続文字列、アクセストークン、パスワード、SQL の中に含まれる個人情報や機密情報は、ログに出さない前提で設計してください。
移行期限はあるのか
この公式クイックスタート自体には、特定日までに移行しなければならない期限は示されていません。したがって、すぐに既存ワークフローを停止しなければならない種類の変更ではありません。
ただし、管理者は次のような観点で棚卸しを行うべきです。
| 確認対象 | 判断基準 | 対応 |
|---|---|---|
| サービス プリンシパル Secret を使っている | 有効期限切れや漏えい時の影響が大きい | OIDC への移行を検討 |
AZURE_CREDENTIALS を長期間更新していない | 誰が作成した資格情報か分からない | 所有者、権限、期限を確認 |
| 本番接続文字列を repository secret に置いている | 承認なしで参照される可能性がある | environment secrets へ移す |
| main ブランチ push で本番 DB に適用される | レビュー漏れが本番反映につながる | 承認フローを追加 |
| Action のバージョンが古い | セキュリティ修正や互換性に不安がある | 検証環境で更新テスト |
「移行期限がないから何もしない」ではなく、既存の GitHub Actions が本番 DB にどの権限で接続しているかを確認する機会として扱うのがよいでしょう。
管理者が確認すべきチェックリスト
本番または共有環境でこのクイックスタートを参考にする場合は、次の順番で確認すると抜け漏れを減らせます。
対象サービスの確認
最初に、対象が Azure SQL Database なのか Azure Database for PostgreSQL なのかを確認します。PostgreSQL なら azure/postgresql@v1 と SQL ファイル、Azure SQL Database なら azure/[email protected] と .dacpac が基本になります。(Microsoft Learn)
認証方式の確認
新規構築なら OIDC を優先し、既存のサービス プリンシパル Secret 方式は移行候補として整理します。OIDC では、Microsoft Entra 側のフェデレーション ID 資格情報と、GitHub Actions 側の id-token: write が必要です。(Microsoft Learn)
Secret の保管場所
本番 DB の接続文字列は repository secrets ではなく、承認付きの environment secrets に置くことを検討します。特に public repository や外部コントリビューターがいるリポジトリでは、Secret へアクセスできる条件を厳しくする必要があります。(Microsoft Learn)
接続先 DB の確認
接続文字列の Server、Database、User Id が本当に意図した環境を指しているかを確認します。ステージング用 Secret と本番用 Secret の名前が似ていると、ワークフローのコピー時に取り違えが起きやすくなります。
SQL ファイルの扱い
公式クイックスタートでは、リポジトリのルートに data.sql を置く例が示されています。実務では、マイグレーション番号、レビュー履歴、ロールバック方法、冪等性を決めておく必要があります。単純な data.sql だけで本番スキーマを更新すると、途中失敗時の復旧が難しくなります。(Microsoft Learn)
ネットワーク到達性
GitHub-hosted runner から PostgreSQL に到達できるかを確認します。到達できない場合に、ファイアウォールを広く開けるのではなく、固定された self-hosted runner、明示的なファイアウォール管理、プライベート接続などを検討します。(GitHub)
ログと監査
ワークフローのログに接続文字列や SQL の機密情報が出ていないか確認します。Azure CLI を追加実行している場合は、標準出力に機密情報が出ないように設計します。(GitHub)
よくある失敗と対策
| 失敗例 | 原因 | 対策 |
|---|---|---|
Azure SQL 用のつもりで azure/postgresql@v1 を使う | 対象サービスの取り違え | Azure SQL Database なら azure/[email protected] を使う |
| OIDC ログインに失敗する | permissions: id-token: write がない | ワークフローまたはジョブに権限を明示する |
| PostgreSQL に接続できない | ファイアウォールで runner の IP が許可されていない | 接続元の設計を見直す |
| 本番 DB に誤って SQL を適用する | ブランチ条件や環境承認が弱い | environment protection rules を使う |
| Secret がログに出る | デバッグ出力や CLI 出力の扱いが甘い | 出力抑制とマスキングを徹底する |
| 古いサンプルをそのまま使う | Action バージョンや構成が現行運用に合わない | 公式リポジトリと検証環境で確認する |
特に危険なのは、「まず動かす」ために権限を広く付与し、そのまま本番運用に入ってしまうパターンです。CI/CD の資格情報は、人間の管理者アカウントよりも実行頻度が高く、漏えい時の影響も大きくなります。最初から最小権限、承認、ログ抑制を前提にしてください。
グローバル環境での追加確認
グローバル企業や複数リージョン運用では、Azure Public Cloud 以外のクラウド環境も考慮が必要です。Azure Login Action では、Public Cloud 以外に接続する場合、environment や audience の指定が必要になる場合があります。(GitHub)
また、Azure PostgreSQL Action の公式リポジトリでは Azure US Government での利用にも触れられています。政府機関向けクラウド、リージョン制約、データ所在地要件がある環境では、サンプル YAML をそのまま使わず、対象クラウド、接続先 FQDN、認証の audience、監査要件を確認してください。(GitHub)
まず取るべき対応
この更新情報を見た管理者が最初に行うべきことは、既存ワークフローの棚卸しです。新機能として急いで導入するより、現在の GitHub Actions がどのデータベースに、どの権限で、どの Secret を使って接続しているかを可視化する方が重要です。
まず、対象サービスが Azure SQL Database か Azure Database for PostgreSQL かを切り分けます。次に、サービス プリンシパル Secret を使っているワークフローを洗い出し、OIDC 化できるものを優先順位付けします。最後に、本番接続文字列を environment secrets に移し、承認付きデプロイに変更します。
今回のクイックスタートは、単なる「GitHub Actions から PostgreSQL に接続する手順」ではありません。Azure と GitHub をつなぐ CI/CD の認証、Secret 管理、ネットワーク制御、ログ管理を見直すきっかけとして活用するのが実務的です。
コメント