Azure REST APIの2026年5月5日更新「Enable auto-merge for SDK PRs created by pipeline」は、REST APIのエンドポイントやリクエスト形式を変える更新ではなく、SDK生成パイプラインが作成したSDK PRを、条件達成後に自動でsquash mergeするための運用変更です。API利用者のコードをすぐ修正する必要は基本的にありません。一方で、Azure REST API仕様からSDKを生成・リリースするサービスチーム、SDKレビュー担当、CI/CD運用担当は、手動マージを前提にした手順を見直す必要があります。(GitHub)
今回のポイントはシンプルです。SDK PR作成後にGitHub CLIで gh pr merge <PR番号> --auto --squash を実行するステップが追加され、必要なレビューやチェックが完了すると、生成されたSDK PRが自動的にマージされる流れになります。(GitHub)
今回の更新で変わること
この更新では、Azure REST API仕様リポジトリ側のパイプラインテンプレート eng/pipelines/templates/stages/archetype-spec-gen-sdk.yml に、SDK PR作成後の自動マージ設定ステップが追加されています。PRの差分では1ファイルに対して9行追加・1行削除が示されており、追加されたコマンドは gh pr merge $(Submitted.PullRequest.Number) --auto --squash です。(GitHub)
| 観点 | 変更前 | 変更後 |
|---|---|---|
| SDK PRのマージ | レビュー・チェック完了後、サービスチームなどが手動でマージする必要があった | 条件を満たすと自動マージが有効化される |
| マージ方式 | 手動操作時の選択に依存 | squash mergeを指定 |
| 対象タイミング | SDK PR作成後に人が戻って確認 | SDK PR作成後のパイプライン内で自動マージを設定 |
| 失敗時の挙動 | 手動で状況確認 | 必須チェックや承認が通らなければ自動マージされない |
| API仕様への影響 | なし | なし。変更対象はSDK PR運用 |
重要なのは、自動マージはレビューやCIを飛ばす仕組みではないという点です。GitHubのauto-mergeは、必要なレビューや必須ステータスチェックなどのマージ要件が満たされたときにPRを自動でマージする機能です。(GitHub Docs)
影響を受ける人・受けにくい人
今回のAzure REST API更新は、すべてのAzure利用者に同じ影響を与えるものではありません。影響の有無は、Azure REST API仕様からSDKを生成し、そのSDK PRをレビュー・マージする立場かどうかで判断できます。
| 対象者 | 影響度 | 確認すべきこと |
|---|---|---|
| Azure REST API仕様を管理するサービスチーム | 高 | SDK PRが自動マージされる前提でレビュー手順を見直す |
| SDK生成パイプラインを使う担当者 | 高 | releaseトリガー、権限、必須チェックの設定を確認する |
| Azure SDKのレビュー担当者 | 中〜高 | 承認後にPRが自動で進むことを前提にレビューする |
| CI/CD・GitHub運用担当 | 中 | GitHub CLI、PAT、auto-merge、squash merge設定を確認する |
| 生成済みSDKを利用するアプリ開発者 | 低 | SDKリリースのタイミングが早まる可能性を意識する |
| Azure REST APIを直接HTTPで呼び出す開発者 | 低 | API仕様変更ではないため、基本的に対応不要 |
Azure REST API仕様リポジトリは、Microsoft AzureのREST API仕様の正本として位置づけられており、仕様完了後の次工程としてSDKやAPIリファレンスドキュメントの生成が案内されています。今回の変更は、その「仕様からSDKを生成し、SDK PRを進める」工程の自動化に関係します。(GitHub)
なぜ自動マージが必要になったのか
背景にある課題は、SDK PRのレビューが終わっても、最後のマージ操作だけが人手に残っていたことです。関連Issueでは、management plane SDK releaseにおいて、SDKオーナーによるレビューと承認が済めば、サービスチーム側で追加作業が不要なケースが多いにもかかわらず、サービスチームが戻って手動マージする必要があり、リリースプロセスを遅らせていたと説明されています。(GitHub)
この更新により、次のような流れを狙っています。
- Azure REST API仕様からSDK生成パイプラインを実行する
- 各SDKリポジトリに生成SDK PRが作成される
- パイプラインが対象PRにauto-mergeを設定する
- 必須チェックとレビューが完了する
- PRがsquash mergeで自動的にマージされる
つまり、手作業をなくす範囲は「PRを確認せずにマージする」ことではなく、条件を満たした後の最後のクリックをなくすことです。
パイプライン上の条件を確認する
差分を見ると、自動マージ設定ステップは無条件で動くわけではありません。追加されたステップには、実行条件が設定されています。(GitHub)
| 条件 | 意味 | 実務上の見方 |
|---|---|---|
endsWith(parameters.TriggerSource, '-release') | release系トリガーの場合にステップを追加 | テスト目的や通常のPR生成にも必ず適用されるとは限らない |
succeeded() | それまでの処理が成功している | SDK PR作成が失敗している場合は対象外 |
variables['HasChanges'] == 'true' | SDKリポジトリに変更がある | 差分がない場合はマージ対象にならない |
Build.Reason != 'PullRequest' | PR起点のビルドではない | PR検証中に勝手に自動マージ設定されるのを避ける |
not(endsWith(variables['SdkRepoName'], '-pr')) | -prで終わるSDKリポジトリ名を除外 | PR用・検証用リポジトリを本番同様に扱わないための条件と考えられる |
GH_TOKEN: $(azuresdk-github-pat) | GitHub CLI用の認証トークンを使用 | PATの権限不足や期限切れが失敗要因になる |
特に確認したいのは、releaseトリガーとPATです。運用担当者は「SDK PRが作られたのにauto-mergeが有効にならない」と判断する前に、そもそも対象トリガーで実行されているか、HasChanges がtrueになっているか、PATでPRのauto-mergeを設定できる権限があるかを確認してください。
squash merge指定の意味
今回のコマンドでは --squash が指定されています。GitHub CLIの gh pr merge では、--auto は必要条件が満たされた後に自動マージする指定、--squash はPR内のコミットを1つにまとめてベースブランチへマージする指定です。(GitHub CLI)
SDK生成PRでは、生成処理や調整により複数コミットが作られることがあります。squash mergeを使うと、SDKリポジトリのmainブランチには「生成SDKの更新」という単位で履歴を残しやすくなります。
ただし、次の点には注意が必要です。
| 注意点 | 理由 |
|---|---|
| 個々の生成コミットはmain上で分離されない | squash mergeではPR内のコミットが1つにまとめられる |
| コミット単位で調査したい場合はPR履歴を見る必要がある | mainの履歴だけでは生成過程を追いにくい |
| SDKリポジトリでsquash mergeが許可されている必要がある | リポジトリ設定とマージ方式が合わないと失敗要因になる |
--delete-branch は指定されていない | ブランチ削除は別設定または別運用に依存する |
「履歴をきれいに保つ」という意味では妥当な選択ですが、生成コードのレビューで細かいコミット差分を確認したいチームは、PRがマージされる前にレビューを完了させる運用がより重要になります。
すぐ対応すべきチェックリスト
Azure REST API仕様やSDK生成に関わるチームは、次の順に確認すると抜け漏れを防げます。
GitHubリポジトリ設定の確認
GitHubのauto-mergeは、リポジトリ側で許可されている必要があります。GitHub Docsでは、リポジトリのSettingsからPull Requestsセクションの「Allow auto-merge」を管理できると説明されています。(GitHub Docs)
確認項目は次の通りです。
- SDKリポジトリでauto-mergeが許可されているか
- squash mergeが許可されているか
- 必須レビュー、必須ステータスチェック、ブランチ保護ルールが意図通りか
- GitHub CLIを実行するトークンに必要な権限があるか
- トークンの期限切れやローテーション手順が整備されているか
特にPATを使っている場合、期限切れや権限変更で突然auto-merge設定だけ失敗することがあります。SDK生成自体は成功しているのにPRが自動マージされない場合は、まず認証まわりを疑うと切り分けが早くなります。
SDK PRレビュー手順の確認
これまで「承認後にサービスチームが最終確認してマージする」という暗黙の手順があった場合、今回の変更でその猶予が短くなる可能性があります。
次のような運用は見直しが必要です。
| これまでの運用 | 見直しポイント |
|---|---|
| 承認後に手動でサンプルを追加してからマージ | 追加作業は承認前に完了する |
| CI成功後に担当者が翌営業日にマージ | CI成功時点で自動マージされる前提にする |
| PR作成後、必要に応じて生成コードを手で直す | 手修正が必要なPRはauto-mergeを無効化する判断を入れる |
| リリース担当だけがマージ可否を判断 | レビュー担当とリリース担当の責任境界を明確にする |
GitHub Docsでは、auto-mergeを有効にしたPRに対して、書き込み権限のないユーザーがhead branchへ変更をpushした場合などにauto-mergeが無効化されることも説明されています。外部コントリビューターやforkを含む運用では、この挙動も確認しておきましょう。(GitHub Docs)
パイプラインログの確認
実際にauto-mergeが有効になったかどうかは、SDK PRの画面だけでなく、パイプラインログでも確認します。今回追加されたステップ名は Apply AutoMerge to Pull Request です。(GitHub)
確認するときは、次の流れで見ると効率的です。
| 手順 | 確認内容 |
| -: | ———————————————— |
| 1 | SDK生成パイプラインがreleaseトリガーで実行されたか |
| 2 | HasChanges がtrueになっているか |
| 3 | SDK PR番号が Submitted.PullRequest.Number に入っているか |
| 4 | Apply AutoMerge to Pull Request ステップが実行されたか |
| 5 | gh pr merge --auto --squash がエラーなく完了したか |
| 6 | SDK PR側でauto-mergeが有効になっているか |
| 7 | 必須チェック・レビュー完了後にsquash mergeされたか |
「PRがまだマージされていない」だけでは失敗とは限りません。必須チェック待ち、レビュー待ち、ブランチ保護ルール待ちの場合、auto-mergeは待機状態になります。
移行時に起きやすい失敗と対処
auto-mergeが有効にならない
原因として多いのは、リポジトリ設定、権限、実行条件のいずれかです。
まず、SDKリポジトリでauto-mergeが許可されているかを確認します。次に、GitHub CLIが使用する GH_TOKEN に対象PRへauto-mergeを設定できる権限があるかを確認します。最後に、パイプライン条件に合致しているかを見ます。
特に、TriggerSource が -release で終わらない場合や、Build.Reason が PullRequest の場合は、今回追加されたステップの対象外になる可能性があります。
チェックが通ったのにマージされない
GitHubのauto-mergeは「すべてのマージ要件が満たされたら」動く仕組みです。必須ステータスチェックだけでなく、必須レビュー、ブランチ保護、競合、base branchの状態なども確認が必要です。(GitHub Docs)
見るべきポイントは次の通りです。
- 必須レビュー数を満たしているか
- CODEOWNERSのレビューが必要になっていないか
- 必須チェックの名称が変更されていないか
- チェックがskipped扱いになっていないか
- merge conflictが発生していないか
- merge queueやrulesetを使っている場合、その条件を満たしているか
意図せず早くマージされる
自動マージが有効になると、承認とチェック完了後にPRが進みます。レビュー後に追加修正やサンプル更新を予定している場合、承認のタイミングを誤ると、作業前にマージされる可能性があります。
対策は、次のどれかです。
- 追加修正を終えてから承認する
- 必要なコメントを解決してから必須チェックを通す
- 自動マージを一時的に無効化する
- 手修正が必要なSDK PRはローカル生成や別フローで対応する
GitHubでは、PR作者や書き込み権限を持つユーザーがauto-mergeを無効化できます。自動マージさせたくないPRでは、早めに無効化しておくのが安全です。(GitHub Docs)
API利用者への実務上の影響
Azure REST APIを直接使っている開発者にとって、今回の更新はエンドポイント、認証方式、リクエストボディ、レスポンス形式の変更ではありません。そのため、アプリケーションコードを即時修正する必要は基本的にありません。
ただし、生成SDKを使っている場合は、次のような間接的な影響があります。
| 影響 | 内容 |
|---|---|
| SDK PRの滞留が減る可能性 | 承認後の手動マージ待ちが減る |
| SDK更新の反映が早まる可能性 | CI・レビュー完了後に自動でmainへ入る |
| 変更確認のタイミングが前倒しになる | SDKリリース前のレビュー猶予が短くなる |
| changelog確認の重要度が上がる | 生成SDKの更新内容を早めに把握する必要がある |
特に、社内でAzure SDKの更新を定期的に取り込んでいるチームは、「SDK PRがいつマージされたか」だけでなく、「パッケージとしていつ公開されたか」を分けて確認してください。SDK PRのマージは、必ずしもそのままパッケージ公開完了を意味するわけではありません。
SDK生成・リリース担当者が更新すべき運用ルール
今回の変更を踏まえると、リリース手順書やチェックリストには次の項目を追加するのが現実的です。
レビュー前の確認
- 生成SDK PRがrelease目的か、テスト目的かを明確にする
- 手修正、サンプル追加、テスト追加が必要かを先に判断する
- 必要な変更がある場合は、承認前に反映する
- 自動マージさせたくない場合は、早い段階でauto-mergeを無効化する
レビュー後の確認
- 必須チェックがすべて成功しているか
- CODEOWNERSレビューが完了しているか
- PRがsquash mergeで取り込まれたか
- リリース計画やパッケージ公開工程に進める状態か
- SDK利用者向けのchangelogや移行案内が必要か
障害時の確認
Apply AutoMerge to Pull Requestステップが実行されたかGH_TOKENの権限・期限に問題がないか- SDKリポジトリでauto-mergeとsquash mergeが許可されているか
- 必須チェック名の変更やruleset変更がないか
- PRがdraft状態のままになっていないか
この更新は、リリース作業を楽にする一方で、「最後に人が見るタイミング」を減らします。レビュー品質を保つには、マージ直前ではなく、PR承認前に確認を終える運用へ寄せることが重要です。
よくある疑問
REST API仕様そのものは変わりますか？
いいえ。今回の主な変更対象は、Azure REST API仕様から生成されたSDK PRのマージ運用です。REST APIのパス、メソッド、パラメータ、レスポンス仕様を変更する内容ではありません。
SDK PRはレビューなしでマージされますか？
いいえ。GitHubのauto-mergeは、必要なレビューや必須ステータスチェックなどのマージ要件が満たされた後に動く仕組みです。今回の更新も、その条件達成後のマージを自動化するものです。(GitHub Docs)
すべてのSDK PRが対象ですか？
差分上は、release系トリガーや HasChanges などの条件が設定されています。関連Issueではmanagement plane SDK releaseの手動マージ削減が背景として説明されていますが、実際の対象範囲は利用しているパイプライン、トリガー、SDKリポジトリ条件によって確認する必要があります。(GitHub)
生成SDKに手を加えたい場合はどうすればよいですか？
承認や必須チェックが完了すると自動マージされる可能性があるため、手修正が必要な場合は承認前に対応します。自動マージさせたくないPRでは、auto-mergeを無効化する運用を入れてください。
SDK PRがマージされたら、すぐパッケージが公開されますか？
必ずしもそうではありません。SDK PRのマージと、SDKパッケージの公開は別工程として扱われる場合があります。リリース計画、パッケージ公開パイプライン、承認プロセスを別途確認してください。
まず確認すべき次のアクション
今回のAzure REST API更新で最初にやるべきことは、APIコードの修正ではなく、SDK生成・リリース運用の確認です。
特に、Azure REST API仕様からSDK PRを自動生成しているチームは、次の3点を優先してください。
- SDKリポジトリでauto-mergeとsquash mergeが許可されているか確認する
Apply AutoMerge to Pull Requestステップが実行される条件をパイプラインログで確認する- レビュー後の手動マージを前提にした手順書を、自動マージ前提に更新する
この更新は、承認済みの生成SDK PRを速やかに取り込むための改善です。うまく使えば、リリース待ち時間を減らせます。一方で、承認後に追加作業をする運用のままだと、意図より早くPRがマージされる可能性があります。SDK生成に関わるチームは、レビュー完了の基準とauto-merge無効化の判断基準を明文化しておきましょう。
コメント