MENU

Azure SDK documentation updateとは？Azure Relay armrelay v2 betaの変更点と移行確認ポイント

Azure

結論から言うと、2026年5月19日にマージされた「Azure SDK documentation update: [Refresh sdk-resourcemanager/relay/armrelay]-generated-from-SDK Generation – Go-6034393」は、Azure RelayをGoから管理するためのAzure SDK、armrelayのリソース管理ライブラリをv2 betaとして再生成する更新です。既存のAzure Relayそのものが自動で変更される更新ではありませんが、Goアプリや運用ツールでgithub.com/Azure/azure-sdk-for-go/sdk/resourcemanager/relay/armrelayを使っている場合は、インポートパス、型、ネットワーク設定まわりの実装確認が必要です。

特に注意すべき点は、/v2付きのモジュールパス、API Version 2024-01-01、SDK Release Type beta、そしてOperation関連の破壊的変更です。Azure Relayの名前空間、Hybrid Connections、WCF Relays、Private Endpoint、Network Rule Setsをコードで作成・更新している管理者や開発者は、単なるドキュメント更新として流さず、移行前にビルド・テスト・ネットワーク設定の差分を確認しておきましょう。

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

Azure SDK documentation updateの概要

今回の「Azure SDK documentation update: [Refresh sdk-resourcemanager/relay/armrelay]-generated-from-SDK Generation – Go-6034393」は、Azure SDK for GoのAzure Relay向けResource Managerライブラリを、SDK生成パイプラインから更新したPRです。GitHub上ではPR #26316として2026年5月19日にマージされ、設定ファイルはspecification/relay/resource-manager/Microsoft.Relay/Relay/tspconfig.yaml、API Versionは1/1/2024、SDK Release Typeはbeta、SpecRepoのCommitSHAはaa822c9c01b9e83fbc8ad8ec4c308203a3c29287と示されています。(GitHub)

pkg.go.devでも、対象パッケージはgithub.com/Azure/azure-sdk-for-go/sdk/resourcemanager/relay/armrelay/v2、バージョンはv2.0.0-beta.1、公開日は2026年5月19日として確認できます。安定版として扱うのではなく、betaとして検証前提で採用するのが安全です。(Go Packages)

確認項目内容実務上の見方
対象SDKAzure SDK for GoのAzure Relay管理ライブラリAzure RelayをGoで管理するコードが対象
パッケージsdk/resourcemanager/relay/armrelay/v2v1系とはインポートパスが異なる
リリース種別beta本番導入前に非本番環境で検証する
対象APIAzure Relay Resource Manager API 2024-01-01Network Rule SetsやPrivate Link関連の設定確認が重要
主な変更生成コード、モデル、README、サンプル、fake、テスト資産の更新ビルドだけでなく単体テスト・統合テストも確認する

何が変わったのか

モジュールパスが/v2付きになる

今回の更新で、Goのインストール例は次のように/v2付きのモジュールパスへ変わっています。READMEでもgo get github.com/Azure/azure-sdk-for-go/sdk/resourcemanager/relay/armrelay/v2が案内され、クライアント生成例も更新されています。(GitHub)

go get github.com/Azure/azure-sdk-for-go/sdk/resourcemanager/relay/armrelay/[email protected]

既存コードがv1系のパスを使っている場合、依存関係を更新しただけでは自動的にv2へ切り替わりません。Goではメジャーバージョン2以上のモジュールはインポートパスに/v2を含める必要があるため、移行は明示的な作業になります。

変更前の例変更後の例
github.com/Azure/azure-sdk-for-go/sdk/resourcemanager/relay/armrelaygithub.com/Azure/azure-sdk-for-go/sdk/resourcemanager/relay/armrelay/v2

API Versionは2024-01-01が前提になる

生成されたSDKはAzure Relay Resource Manager APIの2024-01-01を対象にしています。Microsoft LearnのAzure Relay REST APIサンプルでも、Hybrid Connectionsの取得例でAPI Version 2024-01-01とGoのarmrelay/v2が示されています。(Microsoft Learn)

ここで重要なのは、API Versionが変わっても、既存のAzure Relayリソースが自動的に再作成されるわけではないという点です。ただし、CreateOrUpdate系の処理で送信するプロパティが変わると、ネットワーク公開範囲やPrivate Link関連の設定に影響する可能性があります。SDKの更新とリソース設定の変更は分けて考え、実際に送信されるリクエスト内容を確認してください。

生成対象が広く、テストコードにも影響する

PRの差分では、Goファイル、JSON、Markdown、Go module、YAMLなどが更新対象になっています。CopilotによるPR要約でも、v2 betaクライアント、モデル、fake、サンプル、ドキュメント、ライブテスト資産が再生成されたことが説明されています。(GitHub)

そのため、影響は本番コードだけに限りません。次のようなコードを持っている場合は確認が必要です。

対象確認すべきこと
本番アプリimport path、クライアント生成、モデル型の変更
管理スクリプトNetwork Rule Sets、Private Endpoint、Hybrid Connectionsの更新処理
単体テストfakeパッケージやモックの型差分
統合テスト実Azure環境での作成・更新・削除動作
CI/CDgo.mod、go.sum、依存関係キャッシュ、静的解析

破壊的変更で特に確認すべきポイント

今回のCHANGELOGでは、v2.0.0-beta.1の破壊的変更として、Operation.Originの型変更、複数の構造体削除、Operation.Propertiesの削除などが記載されています。また、ActionTypeやOriginなどの列挙型、NetworkRuleSetPropertiesのフィールド、SystemData関連のフィールド追加も含まれています。(GitHub)

変更点起きやすい影響対応の考え方
Operation.Originが*stringから*Originへ変更文字列比較していたコードがコンパイルエラーになるenum値を使った比較へ修正する
Operation.Propertiesが削除操作一覧のメタ情報を参照するコードが壊れる利用箇所を洗い出し、代替フィールドで足りるか確認する
ErrorAdditionalInfo、ErrorDetail、ErrorResponseなどが削除独自のエラー処理や型アサーションが失敗するazcore.ResponseErrorなど実際に返るエラー型を前提に見直す
ProxyResource、Resource、TrackedResourceなどが削除共通リソース型を直接参照していたコードが壊れる生成済みの個別モデル型へ置き換える
NetworkRuleSetPropertiesにPublicNetworkAccess、TrustedServiceAccessEnabledが追加ネットワーク公開範囲をコードから扱いやすくなる既存値を取得してから更新する実装にする

例えば、以前にOperation.Originを文字列として扱っていた場合は、v2では次のような修正が必要になります。

if op.Origin != nil && *op.Origin == armrelay.OriginUser {
    // ユーザー起点の操作として扱う
}

この種の変更は、実行時エラーではなくコンパイルエラーとして見つかることが多い一方、削除されたフィールドを使っていたログ出力や監査処理は見落とされがちです。移行時はビルド成功だけで判断せず、「監査ログ」「運用通知」「棚卸しレポート」など周辺コードも確認してください。

影響を受ける人、受けにくい人

この更新はAzure RelayのResource Manager向けSDKに関するものです。Azure Relayの通信そのものを行うデータプレーン処理ではなく、名前空間、Hybrid Connections、WCF Relays、Private Endpoint Connections、Private Link Resources、Operationsなどの管理操作をGoから行う場合に関係します。pkg.go.devのドキュメントでも、これらのクライアントや操作例が公開されています。(Go Packages)

立場・利用状況対応優先度理由
GoでAzure Relayリソースを作成・更新している高import pathとモデル変更の影響を受ける
Network Rule SetsをコードやIaCで管理している高公開ネットワーク、IP制限、信頼済みサービス許可の設定確認が必要
Private EndpointやPrivate Linkを運用している中〜高SDK更新時に関連プロパティの扱いを確認したい
v1系SDKを使い続け、v2へ移行しない中直ちに壊れる可能性は低いが、将来移行に備えて差分把握は必要
Azure PortalだけでRelayを管理している低Go SDKのコード変更による直接影響は小さい
Relayの送受信アプリだけを運用している低〜中管理SDKを使っていなければ直接影響は限定的

管理者が確認すべきAzure Relay設定

Network Rule Setsは最優先で確認する

Azure Relay名前空間は、有効な認証があれば既定でインターネットからアクセス可能です。IP Firewallを使うと、特定のIPv4アドレスまたはCIDR範囲にアクセス元を制限できます。また、ルールは名前空間レベルで適用され、条件に合わないアクセスは拒否されます。(Microsoft Learn)

Microsoft.Relay/namespaces/networkRuleSets@2024-01-01では、defaultAction、ipRules、publicNetworkAccess、trustedServiceAccessEnabledが主要なプロパティとして扱われます。Bicep、ARM JSON、Terraform AzAPIの形式でも同じ考え方で設定できます。(Microsoft Learn)

設定主な値・型確認ポイント
defaultActionAllow / DenyIP制限を有効にしたい場合、既定許可のままになっていないか
ipRulesIPv4またはCIDR運用端末、NAT Gateway、監視基盤の送信元IPが含まれているか
publicNetworkAccessEnabled / Disabled / SecuredByPerimeterPublic accessを許可する設計か、Private Link中心の設計か
trustedServiceAccessEnabledtrue / false信頼済みMicrosoftサービスからのアクセスを許可する必要があるか

注意したいのは、「IP許可リストを設定したから安全」とは限らない点です。Microsoft Learnでは、denyルールを追加するのではなく、制限したい場合はdefaultActionをAllowからDenyへ変更する考え方が示されています。(Microsoft Learn)

SDK移行時にありがちな失敗は、既存のNetwork Rule Setsを取得せず、新しい構造体を最小項目だけで組み立ててCreateOrUpdateすることです。未指定プロパティの扱いはAPIや操作内容によって確認が必要なため、移行時は必ず現在の設定を読み取り、差分を明示してから更新してください。

Private Link利用時はDNSとPublic accessをセットで見る

Azure RelayのPrivate Linkでは、Private Endpointと仮想ネットワークは同じリージョンに配置する必要があり、Relay名前空間は別リージョンでも利用できます。また、Private Endpointを使う場合はPrivate DNS Zoneとの統合が推奨されています。(Microsoft Learn)

Private Link構成で特に確認したいのは、次の3点です。

確認項目失敗例確認方法
Public network accessPrivate Endpointを作ったがPublic accessが残っているpublicNetworkAccessの値を確認する
DNS解決社内ネットワークからRelay名前空間がPublic IPへ解決されるPrivate DNS ZoneとVNetリンクを確認する
信頼済みサービス意図しないMicrosoftサービス経由のアクセスを許可しているtrustedServiceAccessEnabledの利用理由を確認する

Public accessを無効にすること自体は強力な制御ですが、それだけで通信経路の確認が完了するわけではありません。Private Endpoint、DNS、クライアントの送信元ネットワーク、監視・運用ツールの到達性まで含めてテストする必要があります。

開発者向けの移行手順

まず利用箇所を洗い出す

最初に、対象リポジトリでarmrelayを使っている箇所を洗い出します。特に、複数の管理ツールやバッチが同じAzure Relay名前空間を操作している場合は、アプリ本体だけでなく運用スクリプトも対象にしてください。

go list -m all | grep 'sdk/resourcemanager/relay/armrelay'

grep -R 'sdk/resourcemanager/relay/armrelay' -n .

確認したい観点は次の通りです。

観点見る場所
SDK依存go.mod、go.sum
import path.goファイル全体
操作対象Namespaces、Hybrid Connections、WCF Relays、Network Rule Sets、Private Endpoint Connections
型依存Operation、エラー型、共通Resource型
テストfake、モック、録画済みレスポンス、ライブテスト

v2 betaを明示的に導入する

検証用ブランチで、v2 betaを明示的に追加します。

go get github.com/Azure/azure-sdk-for-go/sdk/resourcemanager/relay/armrelay/[email protected]
go mod tidy
go test ./...

既存のv1系とv2系はインポートパスが異なるため、移行中に両方が一時的に存在することがあります。最終的には、リポジトリ内で利用するバージョンをそろえたほうが保守しやすくなります。

クライアント生成コードを更新する

READMEでは、azidentity.NewDefaultAzureCredentialで認証情報を作り、armrelay.NewClientFactoryから各クライアントを生成する例が示されています。fakeパッケージを使ったユニットテスト用の仕組みもドキュメントに含まれています。(GitHub)

package main

import (
    "context"
    "log"

    "github.com/Azure/azure-sdk-for-go/sdk/azidentity"
    "github.com/Azure/azure-sdk-for-go/sdk/resourcemanager/relay/armrelay/v2"
)

func main() {
    ctx := context.Background()
    subscriptionID := "00000000-0000-0000-0000-000000000000"

    cred, err := azidentity.NewDefaultAzureCredential(nil)
    if err != nil {
        log.Fatal(err)
    }

    factory, err := armrelay.NewClientFactory(subscriptionID, cred, nil)
    if err != nil {
        log.Fatal(err)
    }

    hybridConnectionsClient := factory.NewHybridConnectionsClient()
    _ = hybridConnectionsClient

    _ = ctx
}

本番では、DefaultAzureCredentialがどの認証方式を使っているかも確認してください。ローカル開発ではAzure CLI認証、CI/CDではサービスプリンシパルやWorkload Identity、本番環境ではManaged Identityなど、環境によって使われる資格情報が変わることがあります。SDK移行と同時に、不要に広い権限を持つ認証情報を使っていないか見直すと安全です。

Network Rule Sets更新コードは既存値を保持する

NetworkRuleSetPropertiesには、TrustedServiceAccessEnabledが含まれます。また、PublicNetworkAccessの定数としてDisabled、Enabled、SecuredByPerimeterが定義され、public network経由のトラフィック可否を扱えるようになっています。(Go Packages)

以下は、考え方を示す最小例です。実運用では、既存設定を取得したうえで必要な差分だけを適用してください。

package main

import (
    "context"

    "github.com/Azure/azure-sdk-for-go/sdk/azcore/to"
    "github.com/Azure/azure-sdk-for-go/sdk/resourcemanager/relay/armrelay/v2"
)

func updateNetworkRuleSet(
    ctx context.Context,
    factory *armrelay.ClientFactory,
    resourceGroupName string,
    namespaceName string,
) error {
    client := factory.NewNamespacesClient()

    _, err := client.CreateOrUpdateNetworkRuleSet(
        ctx,
        resourceGroupName,
        namespaceName,
        armrelay.NetworkRuleSet{
            Properties: &armrelay.NetworkRuleSetProperties{
                DefaultAction: to.Ptr(armrelay.DefaultActionDeny),
                PublicNetworkAccess: to.Ptr(armrelay.PublicNetworkAccessEnabled),
                TrustedServiceAccessEnabled: to.Ptr(false),
                IPRules: []*armrelay.NWRuleSetIPRules{
                    {
                        Action: to.Ptr(armrelay.NetworkRuleIPActionAllow),
                        IPMask: to.Ptr("203.0.113.0/24"),
                    },
                },
            },
        },
        nil,
    )

    return err
}

この例では203.0.113.0/24を説明用のアドレスとして使っています。実際には、社内出口IP、NAT Gateway、監視基盤、CI/CDエージェントなど、Azure Relayへ管理アクセスする送信元を確認してから設定してください。

展開時の注意点

betaであることを前提に採用判断する

Microsoft LearnのAzure SDK for Goパッケージ一覧では、Azure Relayのリソース管理ライブラリとして1.2.0と2.0.0-beta.1が併記されています。つまり、v2 betaが出たからといって、すべての環境で直ちにv1系を置き換える必要があるわけではありません。(Microsoft Learn)

本番運用で安定性を重視するなら、まず非本番環境でv2 betaを検証し、必要な機能や修正がv2にあるかを確認します。すぐにv2の新機能が必要でなければ、既存のv1系を維持しながら移行計画を作る判断も現実的です。

SDK更新と設定変更を同時にやりすぎない

SDK移行とネットワーク制御の見直しを同時に行うと、障害時に原因を切り分けにくくなります。おすすめは、作業を段階に分けることです。

段階作業確認する結果
1v1のまま現在の設定を棚卸しNetwork Rule Sets、Private Link、DNSの現状が分かる
2v2 betaへ移行してビルド・テスト型変更や削除フィールドの影響が分かる
3非本番で管理操作を実行作成・更新・削除が想定通り動く
4ネットワーク設定を差分適用Public accessやIP制限の変更影響を確認できる
5本番へ段階展開障害時に戻しやすい

特にdefaultAction、publicNetworkAccess、trustedServiceAccessEnabledは、セキュリティ境界に関わる設定です。SDK更新のついでに値を変更する場合は、変更理由、承認者、影響範囲、ロールバック手順を残しておきましょう。

CI/CDではバージョンを固定する

beta版を検証する場合、CI/CDで曖昧にlatestへ追従させるのは避けたほうが安全です。go.modでv2.0.0-beta.1のように具体的なバージョンを固定し、更新時はPRで差分をレビューできる形にしてください。

また、SDKの生成物にはサンプルやfakeも含まれるため、単体テストが通っても実環境での権限、ネットワーク、Azure側の制約で失敗することがあります。少なくとも次のテストは分けて実施すると、問題の切り分けがしやすくなります。

テスト目的
go test ./...コンパイルエラー、型変更、単体テストの検出
fakeを使ったテスト分岐やエラーハンドリングの確認
非本番Azureでの統合テスト実際のARM API、RBAC、ネットワーク制御の確認
ロールバックテストv1系または旧デプロイへ戻せるか確認

よくある疑問

v1系をすぐにやめる必要はある？

すぐにやめる必要があるとは限りません。今回のv2はv2.0.0-beta.1として公開されており、Microsoft Learn上でも既存の1.2.0とbetaの2.0.0-beta.1が確認できます。新しいAPI Versionや追加フィールドを使う必要がある場合はv2検証を進め、安定性を優先する環境では既存版を維持する判断もあります。(Microsoft Learn)

API Version 2024-01-01へ変わるとリソースは再作成される？

API Versionは、Azure Resource Managerへ送るリクエストのスキーマや利用可能なプロパティを決めるものです。API Versionが変わっただけで、既存のAzure Relay名前空間が自動的に再作成されるわけではありません。ただし、CreateOrUpdateや更新処理で送るプロパティが変われば、設定変更は発生します。特にNetwork Rule SetsとPrivate Link関連は、事前に差分を確認してください。

Azure PortalやBicepにも関係する？

関係します。今回のSDKはGo向けですが、扱う対象はAzure RelayのResource Manager APIです。BicepやARM JSONでもMicrosoft.Relay/namespaces/networkRuleSets@2024-01-01として、defaultAction、ipRules、publicNetworkAccess、trustedServiceAccessEnabledを設定できます。IaCとSDKの両方で同じリソースを管理している場合は、どちらが最終的な正とする設定なのかを決めておく必要があります。(Microsoft Learn)

データプレーンのRelay通信にも影響する？

今回の更新は、Azure Relayのリソース管理SDKに関するものです。Hybrid ConnectionsやWCF Relaysのリソース作成・更新には関係しますが、既存の送受信アプリが管理SDKを使っていない場合、コード上の直接影響は限定的です。ただし、管理側のコードでNetwork Rule SetsやPublic accessを変更すると、結果として通信経路に影響する可能性があります。

次にやるべきこと

今回のAzure SDK documentation updateは、Azure RelayをGoで管理しているチームにとって、将来のv2移行に向けた確認ポイントが多い更新です。まずは、armrelayの利用箇所を洗い出し、v2 betaへ移行する必要があるかを判断してください。

移行する場合は、/v2付きのimport pathへ変更し、Operationや削除済みモデルに依存したコードを修正します。そのうえで、Network Rule Sets、Private Link、Public network access、trusted service accessの設定を非本番環境で検証しましょう。

特に管理者は「SDKを更新しただけ」のつもりでネットワーク設定まで変えてしまわないように、既存値の取得、差分確認、段階展開、ロールバック手順をセットで準備することが重要です。

Azure
Go Azure Resource Manager Azure SDK Azure Relay armrelay

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次