Azure API ManagementのWorkspacesは、複数のAPI開発チームが同じAPI Managementサービス基盤を使いながら、チームごとにAPI・製品・サブスクリプション・権限・ランタイムを分けて管理するための機能です。結論から言うと、導入前に確認すべきポイントは「利用できるサービスレベル」「ワークスペースゲートウェイの設計」「RBAC」「グローバルポリシーの影響」「プレビュー利用時の移行」の5つです。
2026年5月8日に公開または更新された公式情報では、Workspacesは単なる整理用フォルダーではなく、分散したAPI開発チームに運用権限を委譲しつつ、中央のAPIプラットフォームチームがガバナンス・監視・開発者ポータルを統制するための仕組みとして整理されています。Microsoft Learnでは、WorkspacesはPremiumおよびPremium v2を対象とし、API、製品、サブスクリプション、名前付き値などをワークスペース内に持てるほか、RBAC、ワークスペースゲートウェイ、組織横断ポリシー、ログ監視と組み合わせて使う構成が示されています。(Microsoft Learn)
Azure API ManagementのWorkspacesとは
Azure API ManagementのWorkspacesは、API Managementインスタンス内に複数の管理領域を作り、チーム単位でAPIを管理できるようにする機能です。Microsoftの説明では、WorkspacesはAPI Managementサービス内の「フォルダー」のように機能しますが、実務上は単なる分類機能ではありません。各ワークスペースにはAPI、製品、サブスクリプション、名前付き値などのリソースを含められ、アクセス権はAzure RBACで制御されます。(Microsoft Learn)
たとえば、社内に「決済APIチーム」「顧客管理APIチーム」「社内業務APIチーム」がある場合、それぞれを別ワークスペースとして分けられます。各チームは自分たちのAPIを開発・公開・製品化し、中央のAPIプラットフォームチームは共通基盤、監視、回復性、全体ポリシーを管理します。
この考え方は、Microsoftが「フェデレーションAPI管理」と呼ぶモデルに近いものです。完全に中央集権化すると開発チームのスピードが落ちやすく、逆にチームごとにAPI Managementを分散させるとガバナンスや監視がばらつきます。Workspacesは、その中間として「チームごとの自律性」と「共通基盤での統制」を両立させるための機能です。(Microsoft Learn)
何が変わるのか：管理単位とランタイム設計を分けて考える必要がある
Workspacesで重要なのは、APIの管理権限だけでなく、APIトラフィックを処理するランタイムもワークスペース単位で設計する必要がある点です。
各ワークスペースは、1つ以上のワークスペースゲートウェイに関連付けられます。ワークスペースゲートウェイは、ワークスペース内のAPIトラフィックをバックエンドへルーティングするスタンドアロンのAzureリソースです。これにより、ワークスペース間または用途別にランタイムを分離し、信頼性、回復性、セキュリティを高めやすくなります。(Microsoft Learn)
主な確認ポイントは次のとおりです。
| 観点 | 確認すべき内容 | 実務上の影響 |
|---|---|---|
| サービスレベル | Workspacesの公式ドキュメントはPremium / Premium v2を対象としている | 既存のDeveloper、Basic、Standard系で利用していた構成は再確認が必要 |
| ゲートウェイ | ワークスペースはワークスペースゲートウェイに関連付ける | APIのURL、ネットワーク、スケール、コストに影響する |
| 共有ゲートウェイ | 2025年4月15日以降に作成されたゲートウェイでは複数ワークスペースの関連付けが利用可能 | コスト削減になる一方、リソース枯渇時の影響範囲が広がる |
| ホスト名 | ワークスペースゲートウェイは固有のホスト名を提供する | クライアントアプリやDNS設計の見直しが必要 |
| カスタムホスト名 | ワークスペースゲートウェイ自体では現在カスタムホスト名をサポートしない | Azure Front DoorやApplication Gatewayの前段配置を検討する |
| ネットワーク | ゲートウェイのネットワーク構成は作成時のみ設定可能 | 後からVNet構成を変えられないため初期設計が重要 |
| ポリシー | グローバルポリシーはワークスペースゲートウェイでも実行される | 既存の全体ポリシーが意図せず適用される可能性がある |
特に見落としやすいのが、ワークスペースを作ることと、ワークスペースゲートウェイをどう配置するかは別の設計論点であることです。管理単位を分けるだけなら簡単に見えますが、実際にはAPIの通信経路、スケーリング、監視、コスト、障害時の影響範囲まで変わります。
対象者：API管理者だけでなく開発・運用・セキュリティ担当も影響を受ける
Workspacesの変更や導入は、API Managementを管理する一部の管理者だけの話ではありません。APIの開発、公開、監視、セキュリティ、ネットワーク設計に関わるチーム全体で確認が必要です。
| 対象者 | 主な確認ポイント |
|---|---|
| APIプラットフォーム管理者 | サービスレベル、ワークスペース作成、ゲートウェイ構成、全体ポリシー、監視設計 |
| API開発者 | API、製品、サブスクリプション、ポリシー、名前付き値、バックエンド接続 |
| セキュリティ担当 | RBAC、グローバルポリシー、認証、Defender for APIsの対象範囲、マネージドIDの制約 |
| ネットワーク担当 | VNet、サブネット、Front Door、Application Gateway、プライベート接続の可否 |
| DevOps担当 | IaC、CI/CD、REST APIバージョン、環境ごとのデプロイ手順 |
| SRE・運用担当 | ゲートウェイ単位のメトリック、ログ収集、障害時の切り分け、共有ゲートウェイのリスク |
ワークスペースを導入すると、API開発チームは自分たちの範囲で素早く作業できます。一方で、共通基盤を守るためのルールを最初に決めておかないと、ワークスペースごとに命名、ポリシー、ログ、公開手順がばらつき、後から統制しにくくなります。
管理者が最初に確認すべき設定
サービスレベルとリージョンを確認する
Workspacesを使う前に、まずAPI Managementインスタンスのサービスレベルを確認します。公式のWorkspaces概要および作成手順はPremium / Premium v2を対象としています。(Microsoft Learn)
また、ワークスペースゲートウェイはAPI Managementのすべてのリージョンで使えるわけではありません。Microsoft Learnでは、v2レベルとワークスペースゲートウェイはクラシックレベルが利用可能なリージョンの一部で提供されると説明されており、リージョンごとの提供状況は定期的に更新されます。(Microsoft Learn)
日本リージョンを使う場合は、特に「東日本」「西日本」のどちらでAPI Managementインスタンスを作るのか、ワークスペースゲートウェイが必要な構成に対応できるのかを事前に確認してください。リージョン制約は後からの移行コストが大きくなりやすい項目です。
ワークスペースゲートウェイを専用にするか共有にするか決める
ワークスペースゲートウェイは、1つのワークスペース専用にも、複数ワークスペース共有にもできます。ただし、複数ワークスペースを1つのゲートウェイに関連付ける機能は、2025年4月15日以降に作成されたワークスペースゲートウェイで利用できます。(Microsoft Learn)
設計の目安は次のとおりです。
| 構成 | 向いているケース | 注意点 |
|---|---|---|
| 専用ゲートウェイ | 決済、認証、外部公開APIなど停止影響が大きいAPI | コストは高くなりやすい |
| 共有ゲートウェイ | 社内API、検証環境、重要度が中程度以下のAPI | 1つのワークスペースの異常トラフィックが他に影響する可能性がある |
| 用途別ゲートウェイ | 社内向け、外部向け、パートナー向けなど通信要件が異なるAPI | 用途ごとのネットワーク・監視設計が必要 |
| Front Door / Application Gateway前段配置 | カスタムドメイン、経路制御、ワークスペース移動の柔軟性が必要な場合 | 構成が複雑になるため運用設計が必要 |
ミッションクリティカルなAPIは専用ゲートウェイを使い、重要度が低いAPIは共有ゲートウェイでコストを抑える、という分け方が現実的です。共有ゲートウェイを使う場合は、CPU・メモリ使用率の監視と、問題のあるワークスペースを別ゲートウェイへ移す手順を用意しておきましょう。Microsoftも、共有ゲートウェイの前段にAzure Application GatewayやAzure Front Doorを置くことで、問題のあるワークスペースの移動をしやすくする考え方を示しています。(Microsoft Learn)
RBACは「サービス」「ワークスペース」「ゲートウェイ」の3層で考える
Workspacesの権限管理は、Azure RBACを使います。重要なのは、ワークスペースのメンバーには、ワークスペーススコープのロールだけでなく、サービススコープのロールも必要になる点です。Microsoft Learnでは、ワークスペースコラボレーターにはワークスペーススコープのロールとサービススコープのロールの両方を割り当てる必要があると説明されています。(Microsoft Learn)
代表的なロールは次のとおりです。
| スコープ | 代表的なロール | 用途 |
|---|---|---|
| サービススコープ | API Management Service Workspace API Developer | API編集に必要なサービス側の参照・割り当て |
| サービススコープ | API Management Service Workspace API Product Manager | API公開、ユーザーやグループ関連の操作 |
| ワークスペーススコープ | API Management Workspace Reader | ワークスペース内リソースの参照 |
| ワークスペーススコープ | API Management Workspace Contributor | ワークスペース管理とリソース操作 |
| ワークスペーススコープ | API Management Workspace API Developer | API編集 |
| ワークスペーススコープ | API Management Workspace API Product Manager | API公開・製品化 |
| ゲートウェイスコープ | Reader / Contributor / Owner | ゲートウェイ設定、スケール、確認作業 |
実務では、個人に直接ロールを付けるより、Microsoft Entraグループを作成してロールを割り当てるほうが管理しやすくなります。たとえば「apim-ws-payment-developer」「apim-ws-payment-product-manager」のように、ワークスペース名と役割が分かるグループ名にしておくと、監査時にも確認しやすくなります。
グローバルポリシーの影響を必ず確認する
ワークスペースゲートウェイでは、サービスレベルのグローバルポリシーを含むポリシーチェーンが実行されます。つまり、既存のAPI Managementインスタンスで設定していたglobal.policy.xmlの内容が、ワークスペースゲートウェイで処理されるAPI呼び出しにも適用される可能性があります。(Microsoft Learn)
導入前に、次のようなポリシーを棚卸ししてください。
| 確認するポリシー | リスク | 対応例 |
|---|---|---|
| 認証・認可ポリシー | ワークスペースAPIに意図しない認証方式が適用される | APIまたは製品スコープへ移す |
| IP制限 | 内部APIや外部APIで条件が合わない | ゲートウェイIDやAPI単位で条件分岐する |
| レート制限 | 共有ゲートウェイで想定外の制限になる | ワークスペースまたはAPI単位で再設計する |
| ヘッダー変換 | チームごとの仕様差を吸収できない | APIごとのポリシーへ分離する |
| マネージドID利用 | ワークスペースゲートウェイでサポートされない機能に依存する | 別の認証方式やスコープ変更を検討する |
ゲートウェイごとに挙動を変える必要がある場合、公式情報ではcontext.Deployment.Gateway.Idを使って条件付きでポリシーを実行する方法が推奨されています。(Microsoft Learn)
開発者が確認すべきポイント
APIの公開URLが変わる可能性がある
ワークスペースゲートウェイは、ワークスペースに関連付けられたAPI用の一意のホスト名を提供します。既定のホスト名は<gateway-name>-<hash>.gateway.<region>.azure-api.netの形式です。(Microsoft Learn)
既存APIをワークスペースへ移行する場合、クライアントアプリ、SDK、テストツール、監視ツール、外部連携先に設定しているエンドポイントの変更が必要になる場合があります。特に、以下の場所を確認してください。
- モバイルアプリやWebアプリのAPIベースURL
- バックエンドサービス間通信の接続先
- Postman、REST Client、テスト自動化ツール
- CI/CDパイプライン内の疎通確認URL
- 外部パートナーに共有しているAPI仕様書
- DNS、WAF、Front Door、Application Gatewayのルーティング設定
カスタムホスト名を使っている場合は、ワークスペースゲートウェイ自体では現在カスタムホスト名を割り当てられないため、Azure Front DoorやAzure Application Gatewayを前段に置く構成を検討します。(Microsoft Learn)
ワークスペース内から参照できるリソースには制限がある
ワークスペース内のリソースは、同じワークスペース内のリソースと、サービスレベルの一部リソースを参照できます。ただし、別のワークスペースのリソースは参照できません。また、セキュリティ上の理由から、ワークスペースレベルのポリシーからサービスレベルの名前付き値などを参照することはできません。(Microsoft Learn)
移行時に失敗しやすい例は次のとおりです。
| 失敗しやすい例 | なぜ問題になるか | 対応 |
|---|---|---|
| 複数ワークスペースで同じAPI名を使う | API Managementサービス内ではリソース名の一意性が必要 | 命名規則を先に決める |
| 既存のサービスレベル名前付き値をポリシーで参照する | ワークスペースレベルポリシーでは参照できないケースがある | ワークスペース内に必要な値を定義する |
| 別ワークスペースのバックエンドを参照する | ワークスペース間参照はできない | 共通バックエンドをサービス設計側で分離する |
| APIと製品の公開ルールをサービスレベル前提で組む | ワークスペース内の製品管理と整合しない | ワークスペース単位の製品設計にする |
リソース名は、ワークスペースが違っても同じAPI Managementサービス内で一意である必要があります。命名規則を後から直すとAPI定義、ポリシー、IaC、監視クエリに影響するため、導入前にルール化しておくべきです。(Microsoft Learn)
マネージドIDやKey Vault依存の構成は見直す
ワークスペースゲートウェイでは、マネージドIDがサポートされていません。これには、Azure Key Vaultへのシークレット格納やauthentication-managed-identityポリシーの利用など、関連機能も含まれます。(Microsoft Learn)
そのため、既存APIで次のような構成を使っている場合は、ワークスペース移行前に代替策を検討してください。
authentication-managed-identityポリシーでバックエンドに接続している- 名前付き値や証明書をKey Vault参照で管理している
- グローバルポリシーでマネージドIDトークンを取得している
- Azure OpenAI Service、App Service、Function Appsなどとの連携をポータル上の直接作成手順に依存している
特にグローバルポリシーでマネージドIDを使っている場合、ワークスペーススコープのAPIに意図せず影響する可能性があります。Microsoft Learnでも、グローバルスコープにあるauthentication-managed-identityをワークスペーススコープのAPIで使わせたくない場合は、製品やAPIなど、より狭いスコープへ移すことが推奨されています。(Microsoft Learn)
プレビューWorkspacesを使っていた場合の移行ポイント
プレビュー版Workspacesを作成していて継続利用したい場合は、一般提供版の機能に合わせて移行が必要です。公式情報では、プレビューWorkspacesを引き続き使う場合、各ワークスペースにワークスペースゲートウェイを関連付けて一般提供版へ移行すると説明されています。(Microsoft Learn)
特に、GA前に作成したプレビューWorkspacesは影響を受ける可能性があります。2025年3月の破壊的変更に関する公式情報では、プレビューWorkspacesにはワークスペースAPIゲートウェイが必要になり、サービスレベルのマネージドIDはワークスペースでサポートされないと説明されています。(Microsoft Learn)
移行時は、次の順番で確認すると安全です。
| 手順 | 確認内容 | 注意点 |
|---|---|---|
| 現状確認 | 対象ワークスペースがプレビュー由来か確認する | GA後に作成したワークスペースとは影響が異なる |
| サービスレベル確認 | Premium / Premium v2など、利用可能なレベルか確認する | 旧構成のままでは利用条件に合わない可能性がある |
| リージョン確認 | ワークスペースゲートウェイが対象リージョンで利用できるか確認する | ゲートウェイはプライマリリージョンに作成される |
| ゲートウェイ追加 | 各ワークスペースにゲートウェイを関連付ける | 新規ゲートウェイ作成には数時間かかる場合がある |
| URL更新 | クライアントアプリを新しいゲートウェイホスト名へ更新する | 外部連携先の変更漏れに注意 |
| ポリシー確認 | グローバル、製品、API、操作レベルのポリシーを検証する | マネージドID依存に注意 |
| 監視確認 | サービスレベルとワークスペースレベルの診断設定を確認する | ログが取れていないと障害時に切り分けできない |
| 切り戻し計画 | 旧URL、旧ポリシー、旧構成との差分を記録する | 本番移行では段階的な切替が望ましい |
なお、2025年8月には、以前発表された破壊的変更の一部見直しとして、組み込みゲートウェイ上のWorkspacesサポートを再導入する方針がMicrosoft Tech Communityで示されています。発表では、一定のワークスペース数上限内で、Premium / Premium v2は最大30、Standard / Standard v2は最大5、Basic / Basic v2とDeveloperは最大1のWorkspacesを組み込みゲートウェイ上で扱う方向性が説明されています。ただし、ワークスペースゲートウェイは引き続き大規模・分離・長期的な柔軟性が必要な構成で推奨され、サービスレベルのマネージドIDがWorkspacesで利用できない点は変わらないとされています。(aka.ms)
このため、既存プレビュー環境では「ワークスペースゲートウェイへ移行すべきか」「組み込みゲートウェイの今後のサポートを待つべきか」を、APIの重要度、コスト、分離要件、移行期限、公式の最新提供状況を踏まえて判断してください。
展開時に注意したい制限
Workspacesは便利ですが、通常のAPI Managementと同じ感覚で使うとつまずく制限があります。導入前に、少なくとも次の制限は確認しておくべきです。
| 項目 | 現在の主な制限・注意点 |
|---|---|
| セルフホステッドゲートウェイ | ワークスペースをセルフホステッドゲートウェイに関連付けることはできない |
| 受信プライベートエンドポイント | ワークスペースゲートウェイではサポートされない |
| カスタムホスト名 | ワークスペースゲートウェイのAPIには直接割り当てられない |
| Defender for APIs | ワークスペース内APIは対象外 |
| 外部キャッシュ | ワークスペースゲートウェイは内部キャッシュのみ対応 |
| 合成GraphQL API | サポートされない |
| MCPサーバー | サポートされない |
| Azureリソースからの直接API作成 | Azure OpenAI Service、App Service、Function Appsなどからの直接作成はサポートされない |
| Azure Monitorメトリック | 要求メトリックをワークスペース単位で分割できず、サービスレベルで集計される |
| マネージドID | Key Vault連携やauthentication-managed-identityポリシーを含めサポートされない |
| 作成リージョン | API ManagementインスタンスのプライマリAzureリージョンでのみ作成可能 |
これらは「後から設定を足せば解決できる」ものばかりではありません。特に、カスタムホスト名、ネットワーク、マネージドID、監視粒度は、API公開方式やセキュリティ設計に直接関わります。(Microsoft Learn)
リソース上限も導入前に確認する
Workspacesにはリソース上限があります。代表的な制限として、Premium tierのワークスペースでは、インスタンスあたりのワークスペース数、ワークスペース内のAPI数、操作数、製品数、サブスクリプション数などに上限があります。Microsoft Learnの制限情報では、例としてWorkspaces per instanceは100、Premium workspace gatewayのscale unitsは12、APIsは200、API operationsは5,000、Productsは100、Subscriptionsは5,000といった値が示されています。(Microsoft Learn)
| リソース | 代表的な上限 |
|---|---|
| Workspaces per instance | 100 |
| Scale units per premium workspace gateway | 12 |
| APIs | 200 |
| API operations | 5,000 |
| Operations per API | 100 |
| Products | 100 |
| Subscriptions | 5,000 |
| Named values | 200 |
| Backends | 200 |
| Policy fragments | 50 |
| Version sets | 50 |
上限は将来変更される可能性があるため、本番導入前には必ず最新の公式ドキュメントで確認してください。特にAPI数や操作数が多い大規模サービスでは、「チーム単位で分ける」だけでなく、「どのAPIをどのワークスペースへ配置するか」を上限から逆算する必要があります。
監視とログはサービスレベル・ワークスペースレベルの両方を見る
Workspacesを使うと、チームごとにAPIを管理しやすくなりますが、監視設計を誤ると障害時の切り分けが難しくなります。
公式の作成手順では、ワークスペースAPIのログを収集するには、サービスレベルとワークスペースレベルの両方で診断設定が必要と説明されています。サービスレベルの診断設定がAPI Managementインスタンス全体のログ収集を構成し、ワークスペースレベルの診断設定によってワークスペースゲートウェイのログをLog Analyticsなどへ送信できます。(Microsoft Learn)
実務では、次のように役割を分けると運用しやすくなります。
| 監視対象 | 主担当 | 見るべき内容 |
|---|---|---|
| ゲートウェイCPU・メモリ | APIプラットフォームチーム / SRE | 共有ゲートウェイのリソース枯渇 |
| APIごとのエラー率 | 各ワークスペースチーム | 4xx、5xx、バックエンド障害 |
| レイテンシ | 各ワークスペースチーム / SRE | ゲートウェイ、バックエンド、ネットワークの遅延 |
| ポリシーエラー | API開発者 | 認証、変換、ルーティング、レート制限の失敗 |
| 全体監査 | セキュリティ担当 / 管理者 | 権限変更、公開API、サブスクリプション利用状況 |
Azure Monitorの要求メトリックはワークスペース単位に分割できないため、ログや診断設定を使ってワークスペース単位の可視性を補う設計が必要です。(Microsoft Learn)
導入・移行前のチェックリスト
Workspacesを本番環境で使う前に、次のチェックリストを確認してください。
| チェック項目 | 確認内容 |
|---|---|
| サービスレベル | 利用中のAPI ManagementがWorkspaces対象のレベルか |
| リージョン | ワークスペースゲートウェイが対象リージョンで使えるか |
| ゲートウェイ設計 | 専用か共有か、スケール単位はいくつか |
| ホスト名 | クライアントアプリの接続先変更が必要か |
| カスタムドメイン | Front DoorまたはApplication Gatewayが必要か |
| ネットワーク | VNet構成を作成時に正しく決めているか |
| RBAC | サービス、ワークスペース、ゲートウェイの各スコープで権限を割り当てたか |
| Entraグループ | 個人ではなくグループ単位で権限管理できているか |
| グローバルポリシー | ワークスペースゲートウェイにも適用されて問題ないか |
| マネージドID | Key Vaultやauthentication-managed-identityに依存していないか |
| リソース名 | ワークスペースをまたいでも一意になる命名規則があるか |
| 監視 | サービスレベルとワークスペースレベルの診断設定があるか |
| CI/CD | REST APIバージョン、IaC、パイプラインがWorkspacesに対応しているか |
| 移行計画 | プレビューWorkspaces、旧URL、旧ポリシーとの差分を確認したか |
| 削除リスク | ワークスペース削除時に子リソースや関連ゲートウェイも削除されることを理解しているか |
特に本番APIでは、ワークスペースを作成してから設定を考えるのではなく、ゲートウェイ、ネットワーク、RBAC、ポリシー、監視を先に設計してからワークスペースを作るほうが安全です。
Workspacesを使うべきケース、使わないほうがよいケース
Workspacesは、APIの数やチーム数が増えてきた組織ほど効果を発揮します。ただし、すべての環境で必要になるわけではありません。
Workspacesを使うべきケース
- 複数のAPI開発チームが同じAPI Managementを使う
- チームごとにAPIの編集・公開権限を分けたい
- 中央のAPIプラットフォームチームが共通基盤だけを管理したい
- APIのランタイムを用途や重要度ごとに分離したい
- 開発者ポータルは統一しつつ、API管理はチームへ委譲したい
- 監査やコンプライアンス上、チーム単位の権限分離が必要
慎重に検討すべきケース
- API数が少なく、単一チームだけで管理している
- DeveloperやStandardなど、対象レベルや今後のサポート状況が不確定な構成で運用している
- マネージドID、Key Vault、カスタムドメイン、プライベートエンドポイントに強く依存している
- ワークスペースゲートウェイの追加コストを許容できない
- 既存のグローバルポリシーが複雑で、影響範囲をすぐに把握できない
小規模なAPI管理であれば、通常のAPI Management内でAPI、製品、グループ、サブスクリプションを整理するだけで十分な場合もあります。Workspacesは「チームごとの自律運用」と「中央統制」を両立させたいときに効果が大きい機能です。
まず取るべき行動
Azure API ManagementのWorkspacesを検討している場合、最初にやるべきことは新規作成ではなく、既存環境の棚卸しです。
まず、API Managementのサービスレベル、リージョン、既存API数、グローバルポリシー、マネージドID利用、カスタムドメイン、監視設定を確認します。次に、APIをどのチーム・用途・重要度で分けるかを決め、専用ゲートウェイと共有ゲートウェイの使い分けを設計します。そのうえで、RBAC、命名規則、CI/CD、ログ収集を標準化してから、検証環境でワークスペースを作成してください。
Workspacesは、API管理を分散させながら統制を失わないための強力な選択肢です。ただし、ゲートウェイ、ネットワーク、権限、ポリシーの設計を後回しにすると、移行や本番展開で手戻りが発生しやすくなります。導入前のチェックリストを使い、管理者・開発者・運用担当が同じ前提で設計を進めることが、失敗を避ける一番の近道です。
コメント