Azure API Management workspacesがbuilt-in gateway対応、変更点と管理者の確認ポイント

Azure API Management workspacesで、v2レベルの既定マネージドゲートウェイ、いわゆるbuilt-in gatewayを使えるようになりました。これにより、ワークスペースを使うために必ず専用のworkspace gatewayを用意する必要がなくなり、コストと運用負荷を抑えながら、チーム単位のAPI管理を導入しやすくなります。Microsoft Azure Updatesでは、この更新はAzure API Managementの「Launched」「General Availability」として案内されています。(マイクロソフトアジュール)

ただし、すべての環境で専用gatewayが不要になるわけではありません。built-in gatewayは追加gatewayリソースなしで始めやすい一方、複数ワークスペースやサービスレベルAPIと容量・構成を共有します。高い分離性、個別スケール、独自ネットワーク要件がある本番APIでは、引き続きworkspace gatewayを選ぶ判断も必要です。

Azure API Management workspacesのbuilt-in gateway対応で何が変わるのか

今回の変更の要点は、Azure API Management workspacesを利用する際の入口が広がったことです。

これまでワークスペースベースのAPI管理を本格的に使う場合、ワークスペースごと、または複数ワークスペース共用のworkspace gatewayを用意する構成が中心でした。workspace gatewayは実行基盤を分離できる反面、追加コスト、デプロイ時間、リージョン対応、ネットワーク設計などの検討が必要です。

今回、v2レベルのAzure API Managementでは、ワークスペースのAPIトラフィックをサービス既定のマネージドゲートウェイへルーティングできるようになりました。Microsoft Learnでは、v2レベルのワークスペースを既定マネージドゲートウェイ、または別個のworkspace gatewayに関連付けられると説明されています。(Microsoft Learn)

つまり、管理者や開発チームは次のような選択ができます。

選択肢	向いているケース	注意点
既定マネージドゲートウェイ built-in gateway	小〜中規模のAPI、検証環境、チーム分散管理を低コストで始めたい場合	gateway容量と構成を他ワークスペースやサービスレベルAPIと共有する
workspace gateway	重要API、強いランタイム分離、個別スケール、用途別ネットワーク分離が必要な場合	追加コスト、作成時間、構成管理が発生する
複数workspace gatewayの使い分け	内部APIと外部API、本番系と非本番系を分けたい場合	設計と監視の粒度を事前に決める必要がある

特に重要なのは、「built-in gateway対応＝workspace gateway廃止」ではない点です。これはコスト最適化と展開簡素化の選択肢が増えた更新と捉えるべきです。

そもそもAzure API Management workspacesとは

Azure API Management workspacesは、中央のAPI基盤を維持しながら、各開発チームが自分たちのAPI、製品、サブスクリプションなどを管理できる仕組みです。

Microsoft Learnでは、workspacesは分散したAPI開発チームが共通のAPI Managementサービス基盤内でAPIを管理・製品化できるようにする機能と説明されています。対象レベルはBasic v2、Standard v2、Premium、Premium v2です。(Microsoft Learn)

実務では、次のような組織に向いています。

複数チームがそれぞれAPIを開発している
API公開ルール、認証、監視、ポリシーは中央で統制したい
APIごとの管理権限をチーム単位で分けたい
1つのAPI Managementインスタンス内で、部門別・プロダクト別に管理境界を作りたい

従来の「すべてを中央チームが管理する」方式では、API追加や変更のたびに基盤チームがボトルネックになりがちです。一方、チームごとにAPI Managementインスタンスを乱立させると、コスト、監視、セキュリティポリシー、開発者ポータルが分散します。

workspacesは、この中間にある「中央統制とチーム自律の両立」を狙う機能です。

built-in gateway対応による主なメリット

専用workspace gatewayなしでワークスペースを始めやすい

最も大きなメリットは、ワークスペース利用開始時のハードルが下がることです。

Microsoft Learnでは、既定マネージドゲートウェイを使う構成について、追加gatewayリソースのコストと複雑さを避けられ、APIトラフィックは既定ホスト名、たとえば<service-name>.azure-api.netを通じてルーティングされると説明されています。(Microsoft Learn)

これにより、次のような展開がしやすくなります。

まず1〜2チームでworkspacesを試す
既存API Managementインスタンス内に新しいAPI管理単位を作る
非本番APIや社内向けAPIからワークスペース化する
専用gatewayの設計を後回しにして、権限分離やAPI管理プロセスを先に整える

PoCや段階導入では、最初からworkspace gatewayのスケール、ホスト名、ネットワーク分離まで設計すると、検証前の負担が大きくなります。built-in gatewayを使えば、まず管理モデルの有効性を検証しやすくなります。

Basic v2やStandard v2でも検討しやすくなる

workspacesはBasic v2とStandard v2にも対応しています。Microsoft Learnでは、Basic v2とStandard v2でもworkspacesが利用可能になり、v2レベルでは既定マネージドゲートウェイまたはworkspace gatewayに関連付けられるとされています。(Microsoft Learn)

これにより、Premium前提で考えていた組織でも、要件によってはより小さな構成からワークスペース管理を検討できます。

ただし、価格や利用可能な機能はレベルによって異なります。実際の導入前には、API Managementの価格、レベル別機能、リージョン対応、SLA、ネットワーク要件を必ず確認してください。

API管理の分散化を段階的に進められる

built-in gateway対応は、組織設計にも影響します。

たとえば、中央のAPIプラットフォームチームがAPI Managementインスタンスを管理し、各プロダクトチームにworkspaceを割り当てる構成を取りやすくなります。Microsoft Learnでも、中央チームがAPI Managementインスタンスや監視、回復性、全API向けポリシーを管理し、workspaceメンバーがAPIを開発・公開・製品化・保守する流れが例示されています。(Microsoft Learn)

実務上は、次のような責任分担にすると運用しやすくなります。

役割	主な担当
APIプラットフォームチーム	API Managementインスタンス、共通ポリシー、監視、ログ、全体ガバナンス
各API開発チーム	workspace内のAPI定義、製品、サブスクリプション、API単位のポリシー
セキュリティ・監査チーム	認証方式、ログ保持、アクセス権、ポリシー継承の確認
運用チーム	gateway容量、エラー率、遅延、異常トラフィックの監視

影響範囲：誰が何を確認すべきか

今回の更新は、Azure API Managementを使うすべての利用者に直接影響するわけではありません。特に影響があるのは、workspacesを使っている、またはこれから導入する組織です。

対象者	影響	確認すべきこと
Azure管理者	APIMの構成選択肢が増える	使用レベル、gateway構成、ネットワーク要件、課金影響
APIプラットフォーム担当	ワークスペース展開方針を見直せる	built-in gatewayとworkspace gatewayの使い分け
API開発者	チーム単位でAPI管理しやすくなる	自分のworkspace権限、API公開手順、ログ確認方法
セキュリティ担当	gateway共有時の影響範囲確認が必要	共通ポリシー、RBAC、認証、ログ、監査設定
FinOps担当	専用gateway削減による最適化余地がある	gatewayリソース数、ユニット数、不要な専用構成

特に既存のworkspace gatewayを使っている環境では、「すぐbuilt-in gatewayへ寄せる」よりも、APIの重要度と分離要件を棚卸しするのが先です。

built-in gatewayとworkspace gatewayの使い分け基準

built-in gatewayを選びやすいケース

built-in gatewayは、追加gatewayリソースを避けながらworkspacesを使いたい場合に適しています。

具体的には、次のようなケースです。

社内向けの低〜中トラフィックAPI
非本番、検証、開発環境
ワークスペース管理のPoC
チームごとに管理権限は分けたいが、ランタイム分離までは不要なAPI
カスタムホスト名やプライベートリンクなど、サービスレベル側のgateway機能を活用したい場合

ただし、built-in gatewayでは容量や構成を共有します。あるworkspaceのAPIで急激なトラフィック増加やポリシー設定ミスがあると、共有gatewayを使う他のAPIへ影響する可能性があります。

「管理境界は分けたいが、実行基盤の完全分離までは不要」というAPIに向いていると考えると分かりやすいです。

workspace gatewayを選ぶべきケース

workspace gatewayは、ワークスペースごとの実行基盤分離を重視する場合に適しています。

Microsoft Learnでは、workspace gatewayは既定マネージドゲートウェイと同じコア機能を持つスタンドアロンAzureリソースで、API Managementサービスや他のgatewayから独立して管理できると説明されています。これにより、ワークスペース間や用途間のランタイム分離を実現し、信頼性、回復性、セキュリティを高められます。(Microsoft Learn)

次のようなAPIでは、workspace gatewayを検討すべきです。

外部公開している重要API
障害影響範囲を明確に分けたいAPI
内部APIと外部APIでネットワーク構成を分けたい場合
チームごとにスケール単位を分けたい場合
特定のAPI群だけ監視・運用責任を明確化したい場合
トラフィック急増や重いポリシー処理が想定されるAPI

Microsoft Learnでも、ミッションクリティカルなワークロードでは専用workspace gatewayを割り当てること、重要でないワークロードでは複数workspaceをgatewayに関連付けてコストと信頼性のバランスを取ることが推奨されています。(Microsoft Learn)

管理者が最初に確認すべき設定

API Managementのサービスレベル

まず、対象のAzure API Managementインスタンスがworkspacesとbuilt-in gateway利用に対応するレベルか確認します。

Microsoft Learnのworkspacesページでは、対象レベルとしてBasic v2、Standard v2、Premium、Premium v2が示されています。一方、既定マネージドゲートウェイとの関連付けは、現在v2サービスレベルでのみサポートされると説明されています。(Microsoft Learn)

確認ポイントは次の通りです。

対象インスタンスがBasic v2、Standard v2、Premium v2などの該当レベルか
既存のClassicレベルで同じ構成ができると誤解していないか
リージョン、ネットワーク、価格、SLAが要件に合うか
既存のAPI Management設計とワークスペース導入方針が矛盾しないか

特に「Premiumなら何でも同じ」と考えるのは危険です。built-in gatewayをworkspaceに関連付ける機能はv2レベルでの扱いが中心になるため、実際の構成前に公式ドキュメントの対象条件を確認してください。

workspaceの作成方法

現時点では、既定マネージドゲートウェイに関連付けるworkspace作成はREST API経由が前提です。Microsoft Learnでは、default managed gatewayに関連付けるworkspace作成はv2レベルかつAPI Management REST API経由でのみサポートされると説明されています。(Microsoft Learn)

例として、workspace作成時にserveOnへworkspaceAndDefaultを指定する構成が示されています。

{
  "properties": {
    "displayName": "my workspace",
    "description": "Workspace using default managed gateway",
    "serveOn": "workspaceAndDefault"
  }
}

実務では、ポータル操作だけで完結できる前提にしないことが重要です。IaCやCI/CDでAPIM構成を管理している場合は、REST API、ARM/Bicep、Terraformプロバイダーの対応状況を確認してから展開計画を立てましょう。

RBACと権限設計

workspacesを使う目的の一つは、チームごとに管理権限を分けることです。したがって、gatewayの選択だけでなくRBAC設計が重要になります。

Microsoft Learnでは、workspaceユーザーにはサービススコープのworkspace RBACロールと、workspaceスコープのRBACロールを割り当てる必要があると説明されています。workspace gatewayを使う場合は、gatewayスコープのロールも考慮します。(Microsoft Learn)

確認すべきロール設計は次の通りです。

確認項目	具体例
誰がworkspaceを作成できるか	APIプラットフォームチームのみに限定
誰がAPIを追加・変更できるか	各開発チームにWorkspace API Developer相当を付与
誰が製品やサブスクリプションを管理するか	API Product Manager相当の権限を整理
誰がgatewayや診断設定を変更できるか	運用・基盤担当に限定
個人ではなくグループで管理しているか	Microsoft Entraグループで割り当てる

個人ユーザーへ直接権限を付けると、異動や退職時に棚卸しが難しくなります。最初からMicrosoft Entraグループ単位で割り当てる方が、運用負荷を抑えられます。

診断設定とログ収集

workspacesを分けても、ログが見えなければ運用は成立しません。

Microsoft Learnでは、workspace APIのAzure Monitorログを収集するには、サービスレベルとworkspaceレベルの両方で診断設定が必要だと説明されています。workspaceレベルの診断設定を有効にしない場合、そのworkspaceのgatewayログはLog Analyticsに収集・集約されません。(Microsoft Learn)

確認すべき項目は次の通りです。

サービスレベルの診断設定が有効か
workspaceレベルの診断設定が有効か
Log Analyticsワークスペースの集約先が統一されているか
APIごとのエラー率、レイテンシ、認証失敗を追跡できるか
workspace単位で運用チームがログを確認できるか
監査・保持期間の要件を満たしているか

gateway構成を変えた後にログが途切れると、障害時の切り分けが難しくなります。移行前後で同じクエリを実行し、ログ粒度と欠損有無を確認しておきましょう。

移行・展開時の注意点

既存workspace gatewayを安易に削除しない

built-in gatewayが使えるようになったからといって、既存のworkspace gatewayをすぐ削除するのは避けるべきです。

workspace gatewayには、強いランタイム分離、独立したスケール、独自のネットワーク構成という役割があります。特に本番APIや外部公開APIで使っている場合、built-in gatewayへ寄せることで障害影響範囲が広がる可能性があります。

移行前には、少なくとも次を確認してください。

そのworkspace gatewayに関連付くAPI一覧
月次・日次・ピーク時のリクエスト数
APIごとの重要度
内部向けか外部向けか
カスタムドメイン、フロントドア、WAF、Private Linkなどの構成
バックエンド接続のネットワーク要件
監視、アラート、ログ転送先
利用者に公開しているURL

特にURLが変わる場合は、クライアントアプリ、DNS、証明書、CORS、IP制限、監視設定にも影響します。

gateway共有時のリソース競合を想定する

built-in gatewayでは、workspaceがgateway容量と構成を他workspaceやサービスレベルAPIと共有します。Microsoft Learnでも、既定マネージドゲートウェイを使うworkspaceは、他のworkspaceおよびサービスレベルAPIとgateway容量・構成を共有すると説明されています。(Microsoft Learn)

そのため、次のような失敗が起きやすくなります。

失敗例	起きる問題	対策
大量トラフィックAPIをbuilt-in gatewayへ集約	他APIの遅延やエラーが増える	重要APIは専用workspace gatewayへ分ける
重い変換ポリシーを複数APIに適用	gateway負荷が上がる	ポリシー処理を見直し、負荷テストを実施
非本番と本番を同じgatewayで扱う	検証中の変更が本番監視を混乱させる	環境別にAPIMまたはgatewayを分ける
アラートをサービス全体でしか見ていない	workspace単位の異常に気づきにくい	workspace別ログとメトリックを用意

「管理上の分離」と「実行基盤の分離」は別物です。workspacesで管理権限を分けても、built-in gatewayを共有すればランタイム上の影響は共有されます。

workspace gateway作成には時間がかかる

専用workspace gatewayを使う場合、作成がすぐ終わるとは限りません。Microsoft Learnでは、新しいworkspace gatewayの作成は長時間実行操作で、完了まで最大3時間以上かかる場合があると説明されています。(Microsoft Learn)

本番展開では、次の点に注意してください。

gateway作成をリリース当日に初めて実施しない
検証環境で作成時間と手順を確認する
作成中はworkspace APIのランタイム呼び出しが成功しない可能性を考慮する
デプロイ完了後に疎通、認証、ポリシー、ログを確認する
ロールバック手順を用意する

APIMはAPI公開の入口になるため、gateway作成や関連付けの変更は通常のアプリリリースより影響が大きくなります。ネットワーク変更やDNS変更が絡む場合は、変更審査の対象に含めるべきです。

ネットワーク構成は後から変えにくい

workspace gatewayでは、仮想ネットワークによる受信・送信トラフィックの分離を構成できます。ただし、Microsoft Learnでは、workspace gatewayのネットワーク構成は作成時にのみ設定でき、後から変更できないと説明されています。(Microsoft Learn)

この点は、移行設計で非常に重要です。

たとえば、最初にパブリックアクセス前提で作成したgatewayを、後から内部API向けにプライベート化したいと思っても、単純な設定変更では済まない可能性があります。再作成、再関連付け、疎通確認、URL変更が必要になる場合があります。

設計段階では、以下を確認してください。

APIは社内向けか外部向けか
バックエンドはパブリックかプライベートか
Private LinkやVNet統合が必要か
Azure Front DoorやApplication Gatewayを前段に置くか
WAF、証明書、DNSの管理主体は誰か
将来的に閉域化する可能性があるか

将来のセキュリティ要件が見えているなら、初期段階からworkspace gatewayを分ける方が安全な場合があります。

開発者が確認すべきポイント

APIの公開URLと接続先

built-in gatewayを使うworkspaceでは、APIトラフィックはサービス既定のホスト名を通ります。Microsoft Learnでは、例として<service-name>.azure-api.netが示されています。(Microsoft Learn)

開発者は、APIのベースURL、サブスクリプションキー、認証方式、CORS、クライアント側設定を確認してください。

特に注意すべきなのは、以下のようなケースです。

クライアントアプリにURLをハードコードしている
API仕様書やSDKに古いendpointが残っている
監視ツールが旧gateway URLを叩いている
IP許可リストをgateway単位で制御している
開発・検証・本番で同じ命名規則を使っていない

APIのURLは利用者にとって契約の一部です。gatewayを変える場合は、単なるインフラ変更ではなくAPI利用者への影響を含めて扱いましょう。

ポリシー継承と`<base />`の確認

workspacesでは、workspace、product、API、operationなど複数スコープでポリシーを適用できます。中央チームが定義した認証、レート制限、ヘッダー制御などを各workspaceのAPIでも確実に継承するには、ポリシー設計が重要です。

Microsoft Learnでは、プラットフォームチームがworkspace内のAPIやproductを横断してポリシーを適用でき、<base/>を使った親スコープポリシー継承を監査または強制するAzure Policy定義があると説明されています。(Microsoft Learn)

開発者は、API単位でポリシーを上書きする際に、共通ポリシーを誤って無効化していないか確認してください。

よくある失敗は次の通りです。

API固有ポリシーを書いた結果、親ポリシーの<base />が抜ける
認証ポリシーやレート制限を迂回してしまう
CORSやヘッダー変換のルールがworkspaceごとにバラつく
エラーレスポンス形式がAPIごとに異なる

API利用者から見ると、同じ組織のAPIなのに認証やエラー形式が違うのは大きな負担です。workspaceの自律性を高めるほど、共通ポリシーの継承ルールを明文化する必要があります。

導入前チェックリスト

built-in gateway対応を活用する前に、次のチェックリストで現状を整理してください。

チェック項目	確認内容
サービスレベル	対象APIMがv2レベルで、workspacesと既定gateway関連付けに対応しているか
API重要度	built-in gatewayでよいAPIと専用gatewayが必要なAPIを分類したか
トラフィック	ピーク時リクエスト、遅延、エラー率を把握しているか
URL影響	gateway変更で公開URL、DNS、証明書、クライアント設定に影響がないか
RBAC	サービススコープ、workspaceスコープ、必要に応じてgatewayスコープの権限を設計したか
ポリシー	共通ポリシーの継承、`<base />`、認証、レート制限を確認したか
監視	サービスレベルとworkspaceレベルの診断設定を有効化したか
ネットワーク	VNet、Private Link、Front Door、Application Gateway、WAF要件を確認したか
コスト	workspace gateway削減による効果と、共有によるリスクを比較したか
展開手順	REST API、IaC、CI/CD、ロールバック手順を用意したか

このチェックを行うと、単に「コストが下がりそうだからbuilt-in gatewayへ寄せる」という判断を避けられます。APIごとの重要度と運用要件に合わせて、gatewayを選ぶのが現実的です。

手順	内容
現状確認	対象APIMのレベル、既存API、gateway構成を確認
workspace設計	チーム単位、プロダクト単位、環境単位のどれで分けるか決める
権限設定	Microsoft Entraグループを作り、workspaceロールを割り当てる
workspace作成	REST APIで既定マネージドゲートウェイに関連付ける
API配置	検証用APIをworkspaceに登録し、productやsubscriptionを設定
ポリシー確認	共通ポリシー継承、API固有ポリシー、認証を確認
監視設定	サービスレベルとworkspaceレベルの診断設定を有効化
負荷・疎通確認	レイテンシ、エラー率、ログ出力、アラートを確認
本番判断	API重要度に応じてbuilt-in gateway継続かworkspace gatewayへ分離

まとめ：まずはAPIの重要度別にgateway方針を決める

Azure API Management workspacesのbuilt-in gateway対応により、専用workspace gatewayを用意しなくても、v2レベルでワークスペースベースのAPI管理を始めやすくなりました。コストと運用の複雑さを抑えながら、チーム単位のAPI管理、RBAC、共通ポリシー、ログ管理を段階的に整えられる点が大きなメリットです。

一方で、built-in gatewayはgateway容量と構成を共有します。高トラフィックAPI、外部公開API、ミッションクリティカルなAPI、ネットワーク分離が必要なAPIでは、引き続きworkspace gatewayを使う判断が重要です。

管理者と開発者が次に行うべきことは、既存APIを「built-in gatewayでよいAPI」と「専用workspace gatewayで分離すべきAPI」に分類することです。そのうえで、非本番または低リスクAPIからworkspace化を試し、RBAC、ポリシー継承、診断設定、負荷影響を確認してから本番展開へ進めましょう。

この記事を書いた人

佐藤健司

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

Azure API Management workspacesがbuilt-in gateway対応、変更点と管理者の確認ポイント

Azure API Management workspacesのbuilt-in gateway対応で何が変わるのか

そもそもAzure API Management workspacesとは