Azure Synapse で Managed Private Endpoint を作成しようとしたときに「Tenant is not in allowed list（PrivateEndpointTargetResourceTenantUnauthorized/2164）」と表示されるケースが増えています。本記事では、このエラーの正体と、Synapse 側でどの設定を直せばよいのか、そしてクロステナントの Private Link Service（PLS）に接続する際の FQDN の扱いまでを、一気に整理します。
エラー「Tenant is not in allowed list」とは？
まずは問題のエラーメッセージを整理します。Synapse の Managed Private Endpoint を作成するとき、次のような内容で失敗することがあります。
{
"StatusCode": 401,
"ErrorType": "PrivateEndpointTargetResourceTenantUnauthorized",
"ErrorNumber": 2164,
"ErrorCode": "PrivateEndpointTargetResourceTenantUnauthorized",
"ErrorMsg": "Unauthorized tenant: Message=Target resource subscription id ... not in allowed list."
}
ポイントは以下の 2 つです。
- StatusCode = 401 で「Unauthorized tenant」と書かれている
- ErrorType / ErrorCode が
PrivateEndpointTargetResourceTenantUnauthorized（エラー番号 2164）である
このエラーは「プライベート エンドポイントの接続先サブスクリプション（＝テナント）が、接続を許可されたテナント一覧に含まれていない」という意味です。実際、Microsoft Q&A でも同じエラー メッセージで質問が上がっており、Synapse の Managed Virtual Network とデータ流出防止を有効化した環境で再現していることが報告されています。
どの操作で発生するか
よくあるのは次のようなパターンです。
- Synapse ワークスペースは「Managed workspace Virtual Network（Managed VNet）」と「データ流出防止」を有効化している
- Synapse Studio から Managed Private Endpoint を新規作成しようとしている
- 接続先が別テナントにあるストレージ アカウントや Private Link Service（PLS）
- 作成ウィザードを最後まで進めて「作成」すると、上記の 401 / 2164 エラーで失敗する
一方で、同じ接続先に対しても、Azure ポータルから 通常の Private Endpoint を作成すると問題なく作成できる、という報告もあります。これは「Managed Private Endpoint 固有の制限」が関わっているサインです。
よくある勘違い：ストレージ アカウントの「allowedTenants」を探してしまう
エラーメッセージに「allowed list」「Unauthorized tenant」と出てくるため、ついターゲット側（例：ストレージ アカウント）の properties.allowedTenants を Azure ポータルや ARM テンプレートで探してしまいがちです。
しかし、このケースではブロックしているのは Synapse ワークスペース側 の Managed VNet／Managed Private Endpoint のポリシーです。ストレージ アカウント側の allowedTenants を見つけられなくても不思議ではありませんし、設定しても今回のエラーは解消されません。
| 探してしまいがちな場所 | 実際の制御点 | コメント |
|---|---|---|
ストレージ アカウントの properties.allowedTenants | Synapse ワークスペース（Managed VNet の許可テナント設定） | 今回のエラーは Synapse 側の制御で発生 |
| ターゲット側リソースの NSG / FW | Managed Private Endpoint の作成ポリシー | ネットワーク到達以前に「作成自体」が拒否されている |
原因：Managed VNet ＋ データ流出防止 ＋ テナント制御
公式ドキュメントでは、Azure Synapse のワークスペースに Managed workspace Virtual Network を関連付けた場合、Synapse が管理する専用 VNet 内に Spark やデータ統合リソースをデプロイし、Managed Private Endpoint でのみ外部サービスに接続させることでデータ流出防止を行うと説明されています。
このとき、次の 3 つの制御が効きます。
- Managed VNet によるネットワーク分離 → ワークスペースごとに専用の仮想ネットワークが作られ、外部と直接通信できない
- データ流出防止（Outbound 制限） → Managed Private Endpoint 経由の接続先にしか通信させないオプション
- Managed Private Endpoint の「許可テナント」 → どの Microsoft Entra テナント（旧 Azure AD）のリソースに対して Managed Private Endpoint を張れるかを制御
公式ドキュメントにも、次のような記述があります（要約）。
- Managed Private Endpoint は、同じ Microsoft Entra ID テナント内のリソースには既定で作成可能
- 別テナントのリソースに Managed Private Endpoint を作成したい場合は、そのテナント ID を「許可テナント」として追加する必要がある
つまり、今回のエラーの本質は以下のように整理できます。
「Managed VNet ＋ データ流出防止」構成の Synapse ワークスペースでは、
既定では「同一テナントのリソース」にしか Managed Private Endpoint を張れない。
別テナントのリソースに張ろうとすると、「Tenant is not in allowed list」で拒否される。
Managed Private Endpoint は Managed VNet 前提
補足として、Managed Private Endpoint は Managed workspace Virtual Network を有効化したワークスペースでのみサポートされる点にも注意が必要です。
| 項目 | Managed VNet あり | Managed VNet なし |
|---|---|---|
| Managed Private Endpoint | 利用可能（今回のエラーもここで発生） | 利用不可 |
| 通常の Private Endpoint（IaaS 側） | Managed VNet 外の VNet に対して作成 | 同様に利用可能 |
さらに、Managed VNet の有無はワークスペース作成後に変更できない仕様であるため、誤った構成で作成してしまうと作り直しが必要になります。
本当の制御ポイント：Synapse ワークスペースの「許可テナント」設定
Microsoft Q&A では、同じエラーに対して「Synapse ワークスペースの Managed Private Endpoint が接続を許可する Microsoft Entra テナントを追加したところ解消した」と報告されています。
概念的には、次のようなイメージです。
| 項目 | 内容 |
|---|---|
| 許可テナントの既定値 | Synapse ワークスペースが属するテナントのみ |
| 許可テナントに追加できるもの | 他の Microsoft Entra テナント ID（GUID） |
| 追加しない場合 | 別テナントのリソースへの Managed Private Endpoint 作成が 401/2164 で失敗 |
つまり、「どのテナントのリソースに対して Managed Private Endpoint を張ってよいか」を決めているのは Synapse ワークスペース 側であり、今回のエラーもここで拒否されています。
解決策：Synapse で許可テナントを追加し、Managed Private Endpoint を再作成
では、実際にどのように設定すればよいのでしょうか。ここでは、できるだけ手順を絞った「最短ルート」を紹介します。UI の文言や配置は随時変わる可能性がありますが、概ね次のような流れです。
手順 1：Synapse Studio にサインイン
- 対象の Synapse ワークスペースを開き、「Synapse Studio を開く」（もしくは「Open Synapse Studio」）をクリックします。
- ブラウザで Synapse Studio が開いたら、右上のサインイン アカウントが「ワークスペースを作成したテナント」であることを確認します。
手順 2：Managed Private Endpoint の設定画面を開く
- 左メニューから ［Manage（管理）］ をクリックします。
- ［Security / Networking］（またはそれに相当するセクション）を選択します。
- サブメニューから ［Managed private endpoints（管理対象プライベート エンドポイント）］ を開きます。 （ここには既に
synapse-ws-sql--<workspace>やsynapse-ws-sqlOnDemand--<workspace>など、SQL 用の Managed Private Endpoint が自動作成されて表示されているはずです。）
手順 3：接続を許可するテナント ID を追加
Managed Private Endpoint の一覧画面や、その近くに「接続先として許可する Microsoft Entra テナント」を管理する UI が用意されています（［Tenants］や［Allowed tenants］といったラベルが付いていることが多いです）。
- 画面上部の ［+ Add］（＋追加）ボタンをクリックします。
- 表示されるダイアログで、接続先リソースが所属する Microsoft Entra テナント ID（GUID） を選択または手入力します。
- 複数テナントに張りたい場合は、必要なテナント ID をすべて登録します。
- ［追加］または［保存］を押して反映させます。
公式ドキュメントでも、「同一テナント以外の Microsoft Entra ID テナントに Managed Private Endpoint を作成したい場合は、そのテナントを［+ Add］で追加する」と明記されています。
手順 4：Managed Private Endpoint を再作成する
許可テナントの設定を更新したら、問題の Managed Private Endpoint を 削除 → 再作成 します。
- 先ほど開いた Managed Private Endpoint 一覧から、エラーになっているエンドポイント（あるいは未完了のもの）を削除します。
- ［+ New］または［+ New managed private endpoint］から、再度同じターゲット リソースに対するエンドポイントを作成します。
- 今度は 401 / 2164 エラーではなく、「接続保留（Pending）」などの状態で作成されるはずです。
手順 5：ターゲット リソース側でプライベート リンク接続を承認
Managed Private Endpoint は、ターゲット側リソースの所有者による「承認」が完了してはじめて実際の通信に使えるようになります。
- ターゲット リソース（ストレージ アカウント、PLS など）の Azure ポータルを開きます。
- ［Networking］→［Private endpoint connections］ など、プライベート リンク接続の一覧が表示される画面を開きます。
- Synapse からの要求が 「Pending」 で表示されているのを確認し、［Approve］（承認）を行います。
- 承認後、Synapse Studio 側の Managed Private Endpoint のステータスが 「Approved」 になれば、接続が有効になっています。
別テナントの Private Link Service（PLS）に接続する場合のポイント
質問としてよく出るのが、「相手テナントにある Private Link Service に対して Managed Private Endpoint を張るとき、FQDN に何を入れればよいか？」というものです。
基本：PLS 接続はサービス エイリアス／リソース ID が主役
Synapse の Managed Private Endpoint は、多くの PaaS サービスについて リソース ID を指定して接続先を決める仕組みになっています。
- Azure Storage や SQL、Cosmos DB など → Azure ポータルの［プロパティ］に表示される「リソース ID」をそのまま使用
- Private Link Service（PLS） → PLS の サービス エイリアス（alias） やリソース ID を指定するパターンが一般的
このため、「FQDN を入れないといけない」わけではなく、基本はエイリアス／リソース ID ベースでの接続です。
FQDN 入力欄が表示される場合の考え方
とはいえ、実際には「Managed Private Endpoint 作成ウィザードの中に FQDN を入力する欄があり、そこを適切に埋めないと疎通しない」という事例も報告されています。Microsoft Q&A には、PLS への接続で「FQDNs セクションにすべてのエンドポイントを登録したら解決した」というケースが紹介されています。
この FQDN は、主に Synapse 側の DNS 解決とアウトバウンド先のホスト名制御 に使われます。概ね次のように考えると整理しやすくなります。
| ケース | FQDN の扱い | ポイント |
|---|---|---|
| Azure Storage などの標準 PaaS | 通常は自動で解決されるため明示指定不要 | リソース ID だけで完結することが多い |
| カスタム PaaS / 自前アプリ背後の PLS | Synapse から到達させたい FQDN をすべて登録 | PLS 背後のアプリが複数ドメインを使う場合は特に要注意 |
| Snowflake など SaaS 側の Private Link | ベンダーのガイドに沿って必要なホスト名を登録 | DNS ゾーン設計と合わせて確認 |
まとめると、PLS に対して Managed Private Endpoint を張る場合、
- 第一にサービス エイリアス／リソース ID を正しく指定する
- 接続テストで解決エラーになる／VM からはつながるが Synapse からだけ届かない場合は、FQDN セクションに必要なホスト名をすべて登録する
- それでもダメな場合は、Private DNS ゾーンや NSG・UDR などネットワーク周りも併せて確認する
というステップで切り分けるのが現実的です。
Managed Private Endpoint と通常の Private Endpoint の違い
今回のように、「Managed Private Endpoint は失敗するのに、通常の Private Endpoint は成功する」という状況は、次の違いから生じます。
| 項目 | Managed Private Endpoint（Synapse） | 通常の Private Endpoint（IaaS） |
|---|---|---|
| 作成場所 | Synapse Studio（Managed VNet 内） | 任意の VNet（Azure ポータル / CLI） |
| ネットワーク | Synapse が管理する Managed VNet | ユーザー管理の VNet／サブネット |
| テナント制御 | 「許可テナント」でクロステナントを制御 | 基本的にはターゲット リソース側の設定のみ |
| 用途 | Spark / Data integration など Synapse 内からのアウトバウンド | VM、App Service、AKS などからのアウトバウンド／インバウンド |
つまり、通常の Private Endpoint が通るからといって、同じ条件で Managed Private Endpoint も通るとは限らない、ということです。Managed VNet + データ流出防止によって、Synapse 管理下のアウトバウンドには独自のガードレールが追加されている、と理解しておきましょう。
チェックリスト：どこから確認すべきか
ここまでの内容を、実際の切り分け手順としてチェックリスト化しておきます。
- □ 接続元と接続先は 同一テナント か？ → 同一テナントなら、通常は許可テナントの追加は不要
- □ 別テナントであれば、Synapse ワークスペースの 許可テナントに相手テナント ID が追加済み か？
- □ ターゲット リソース側の Private Endpoint 接続が「承認済み」 になっているか？
- □ Azure Policy や RBAC でクロステナントの Private Endpoint 作成が制限されていないか？
- □ エラーが発生しているのは Synapse の Managed Private Endpoint 作成 であり、ストレージ アカウント側設定を探していないか？
| チェック項目 | 見る場所 | 異常時の典型的な症状 |
|---|---|---|
| テナント一致 / 不一致 | Azure ポータルのテナント情報、サブスクリプション設定 | 思い込みで「同一テナント」と認識しているが実は別テナント |
| 許可テナントへの登録有無 | Synapse Studio の Managed Private Endpoint 設定 | 登録されておらず、「Tenant is not in allowed list」で失敗 |
| Private Link 接続の承認 | ターゲット リソースの［Private endpoint connections］ | ステータスが Pending のままで、Synapse から到達しない |
| Azure Policy / RBAC | サブスクリプション／管理グループのポリシー／ロール割り当て | 特定のテナントからの Private Endpoint 作成が禁止されている |
ストレージ側の「allowedTenants」との切り分け
ここまで Synapse 側の許可テナントの話をしてきましたが、Azure の世界にはもう一つ、「ターゲット リソース側の allowedTenants」という概念も存在します。これは、ストレージ アカウントなど一部の PaaS リソースに対して「どのテナントから Private Endpoint を張れるか」を明示的に制御するためのプロパティです。
例えば、Azure CLI では概ね次のような形で更新します（概略）。
az resource update \
--ids <ターゲット リソースのリソース ID> \
--set properties.allowedTenants="[ '<tenantId1>', '<tenantId2>' ]"
ただし、今回のように Synapse の Managed Private Endpoint 作成時に 401 / 2164 が出ているケースでは、まず Synapse ワークスペース側の許可テナントを見直すのが筋です。
- 通常の Private Endpoint でも同じエラーが出る → ターゲット リソース側の
allowedTenantsを疑う - 通常の Private Endpoint は通るが、Managed Private Endpoint だけ失敗する → Synapse ワークスペース側の許可テナント設定を疑う（本記事のケース）
IaC（ARM/Bicep/Terraform）で運用している場合の注意点
Synapse を含むネットワーク構成を IaC（ARM/Bicep/Terraform など）で管理している環境では、次のような落とし穴があります。
- ストレージ アカウントや SQL などターゲット リソースのテンプレートには気を遣っているが、Synapse ワークスペース側の Managed VNet／許可テナント設定はポータルで作ったままになっている
- テナント構成変更（テナント統合や分割）があったが、許可テナント一覧をテンプレートに反映していない
このような環境では、ある日突然 CI/CD パイプライン上で Managed Private Endpoint の作成が 401 / 2164 で落ち始める、ということが起こり得ます。
対策としては、
- Synapse ワークスペースの Managed VNet 設定と許可テナント一覧も IaC の管理対象に含める
- テナント構成変更時は、「許可テナントの棚卸し」を運用プロセスに組み込む
といった運用を検討するとよいでしょう。
よくある誤解・落とし穴のまとめ
- 誤解 1：ストレージ アカウントの ARM テンプレートに
properties.allowedTenantsを設定すればよい
→ 今回のエラーは Synapse Managed VNet 側のポリシーが原因。ストレージ側ではなく、Synapse の「許可テナント」を操作する必要があります。 - 誤解 2：同一テナントなら絶対に発生しない
→ 同一テナントでも、Azure Policy や RBAC によってクロステナント相当の制約がかかる場合があります。テナント ID とサブスクリプションのひも付き、ポリシー設定もあわせて確認しましょう。 - 誤解 3：PLS 接続では必ず FQDN を入れる必要がある
→ 基本はサービス エイリアス／リソース ID で接続可能です。FQDN は DNS 解決やホスト名ベースの制御が必要な場合にだけ追加する、と理解しておくのが実践的です。
まとめ：エラーの正体と対処の要点
最後に、本記事のポイントをコンパクトに整理します。
- 「Tenant is not in allowed list（PrivateEndpointTargetResourceTenantUnauthorized / 2164）」は、Managed Private Endpoint の接続先テナントが Synapse ワークスペースの「許可テナント」に含まれていないときに発生するエラーです。
- Managed VNet ＋ データ流出防止を有効化した Synapse ワークスペースでは、既定で同一テナント以外のリソースへの Managed Private Endpoint 作成が拒否されます。
- 解決には、Synapse Studio で 許可テナントに相手の Microsoft Entra テナント ID を追加し、そのうえで Managed Private Endpoint を再作成し、ターゲット側でプライベート リンク接続を承認します。
- PLS に対する接続は、基本的に サービス エイリアス／リソース ID を指定して行い、必要に応じて FQDN セクションにホスト名を追加して DNS 周りを整えます。
- ストレージ アカウント側の
allowedTenantsを疑うのは、「通常の Private Endpoint でも同じエラーが出る場合」。Managed Private Endpoint だけが失敗する場合は、まず Synapse ワークスペース側の設定を優先的に確認しましょう。
Synapse の Managed VNet と Managed Private Endpoint は、正しく設計すれば非常に強力なデータ流出防止の仕組みになりますが、その分ガードレールも強めに設定されています。エラー メッセージだけを追いかけてターゲット リソース側を探し回るのではなく、「Synapse 側のテナント制御」という視点を持って調査することで、トラブルシューティングの時間を大きく短縮できるはずです。
コメント