Admin consent を実行しても Dataverse に弾かれるとき、エラーコードで問題の層が特定できる。
401：サービスプリンシパル（SP）が相手テナントに存在しない——入館証が未発行の状態。
403：入館後のセキュリティロールが不足——室内で許可された操作がない状態。
この2層は独立して動く。片方を解決しても、残りはそのままだ。
入館証と室内権限は別物
クロステナントアクセスを「オフィスビルへの入館」で考えると、構造が見える。
入館証（越境）：相手テナントの管理者が同意（Consent）を実行し、自テナント内に SP を実体化させること。SP ができてはじめて、アプリは「入館者」として認識される。
室内権限（認可）：Dataverse の中で何をしていいかを、セキュリティロールで決めること。
Microsoft 公式（cross-tenant-access-overview・2025）は、クロステナントアクセス設定とテナント制限が独立して動作することを明記している。
“they operate separately from inbound and outbound access settings”
| 設定 | 何を制御するか | SP を作るか |
|---|---|---|
| クロステナントアクセス設定 | テナント間のインバウンド・アウトバウンド | しない |
| テナント制限 v2 | 外部アカウントへの入口制御（門番） | しない |
| 同意（Consent） | SP の実体化（入館証の発行） | する |
| Dataverse セキュリティロール | Dataverse 内の操作許可（室内権限） | — |
テナント制限 v2（Tenant Restrictions v2）は Entra ID P1 または P2 が必要で、設定に Security Administrator ロール以上が要求される（2026年7月時点・出典：Microsoft Learn「Configure Tenant Restrictions v2」2025）。
401 の正体
SP が対象テナントに存在しないと、Entra ID は次のエラーを返す。
The client application {appId} is missing a service principal in the tenant {tenantId}.
（出典：Microsoft Learn「Create an enterprise application from a multitenant application」2024）
SP は同意によって実体化される。Admin Consent エンドポイント（https://login.microsoftonline.com/{tenant}/v2.0/adminconsent）を直接呼び出して管理者同意を行う方法が標準的だ。別テナントのユーザーが初回サインインで同意する流れでも SP が作成される。（出典：Microsoft Learn「Convert single-tenant app to multitenant on Microsoft Entra ID」2024）
「許可リストに追加した」は同意ではない。テナント制限 v2 は候補テナントを絞る門番として機能するが、SP は作成しない。許可リストの設定と Consent の実行は別の操作だ。
2024年10月の変更：対象テナントに SP が存在しないアプリの app-only トークンが非サポートとなった（出典：Microsoft Learn「Retirement of service principal-less authentication」2024）。2024年10月以前に動いていた連携が突然 401 で止まった場合、対象テナントでの SP の有無を最初に確認する。対象環境・例外条件は公式「Important changes」ページで随時更新されるため、実環境対応前に最新状態を確認すること。
403 の正体
認証（入館）は通過しているが、Dataverse の中で許可された操作がない状態だ。
Dataverse の認可は Entra ID の「API アクセス許可」（Azure Portal のスコープ設定）では制御されない。Dataverse 内部のセキュリティロールが判断基準になる。
Microsoft Learn の Dataverse マルチテナント S2S 認証ドキュメント（2024）は次を明記している。
- Dataverse にアプリユーザー（Application User）を登録すること
- カスタムセキュリティロールを作成し、そのアプリユーザーに関連付けること
- アプリユーザーはデフォルトのロールに自動では紐付かない
これを省略した状態で API を呼ぶと、認証は通過するが認可で弾かれる。403 のエラーメッセージの公式引用はドキュメントで確認できなかったため、Dataverse のロール要件（上記公式）から「ロール未割当 → 403」を論理的に導出している。
同一テナントでも認可設定は必要
「越境しないなら認可設定は不要では」——この思い込みが設計ミスを生む。
Dataverse S2S ドキュメント（2024）はマルチテナント・単一テナントの区別なく、アプリユーザー登録とセキュリティロールの関連付けが必須だと明記している。
認可は越境の有無と無関係に常に必要だ。同一テナント内の自動処理から Dataverse を呼ぶ場合でも、アプリユーザーにロールを割り当てなければ 403 が返る。
クロステナントの挙動を手元で確認したい場合、M365 Developer Program（無料）でもう1テナントを用意すると、相手テナントの admin consent 操作を自分でコントロールして動作を確かめられる。
→ 関連記事：[Microsoft 365 開発者向け検証環境の構築]（リンク予定）
診断チャート
| 症状 | 原因層 | 確認事項 | 対処 |
|---|---|---|---|
| 401 が返る | 入館（越境）未完了 | 対象テナントに SP が存在するか | Admin Consent を実行して SP を作成 |
| 401 が返る（2024年10月以降の突然の停止） | SP-less app-only 廃止の影響 | SP 未登録のままトークン取得を試みていないか | 同意フローを実行して SP を作成 |
| 403 が返る | 室内権限不足 | Dataverse にアプリユーザーとロールが設定されているか | アプリユーザー登録 + カスタムロール割り当て |
| 許可リスト追加後も変わらない | テナント制限の誤解（門番 ≠ 入館証） | 同意（Consent）操作を実施したか | 同意フローを改めて実行 |
上記の構造は公式ドキュメント（2024〜2025年）から導出している。2テナント間のエンドツーエンドの PoC は書き手の直接確認が未踏のため、実環境で試す際は公式ドキュメントで最新状態を確認することを推奨する。
まとめ
「同意したのに弾かれる」は、入館証（SP実体化・越境）と室内権限（Dataverseセキュリティロール）が独立した2層であることを前提に切り分ける。401 は入館未完了、403 は室内権限不足——この2軸が決まれば対処は自ずと決まる。
次の一歩：まず Admin Consent エンドポイントで SP の作成状態を確認する。次に Dataverse 管理センターでアプリユーザーとロールの割り当て状態を確認する。
関連記事：
秘密ゼロ・マネージドIDでDBに接続する設計 — SP が「入館の鍵」を持つ仕組みとシークレット不要の認証設計について
受け手側も設定が要る — 両端をそろえる設計思想について