マルチテナントのApp Registrationで「ホームページ URL」を変更したのに、顧客テナントのEnterprise Application（サービス プリンシパル）のURLが更新されない…。この現象は“仕様”に起因します。本記事では混在理由と、最短で直す手順、運用で困らない設計をまとめます。
起きている現象をもう一度整理
質問の状況は、Microsoft Entra ID（旧 Azure Active Directory / Azure AD）でよくあるマルチテナント配布パターンです。
- 自社テナントで マルチテナントの App Registration（アプリ登録） を作成している
- 顧客テナントでは、初回同意（Admin consent / User consent）のタイミングで Enterprise Application（エンタープライズ アプリケーション） が作られ、実体は サービス プリンシパル（Service Principal） として存在する
- App Registration 側でロゴを変更すると顧客テナントにも反映されるが、ホームページ URL を変更しても顧客側のホームページ URL が更新されない
- 顧客テナントによって「古い URL が残る」「空欄のまま」が混在している
結論から言うと、ロゴとホームページ URL は「反映される仕組み」が別物です。同じように同期される前提で設計すると、テナントごとにズレが出ます。
まず押さえるべき前提：App Registration と Enterprise Application は“別オブジェクト”
この問題は、アプリケーション オブジェクト（Application） と サービス プリンシパル（Service Principal） の役割を分けて理解するとスッキリします。
| 項目 | App Registration（アプリ登録） | Enterprise Application（エンタープライズ アプリ） |
|---|---|---|
| 実体 | Application オブジェクト（主に開発者・提供側が管理） | Service Principal（各テナントに作られる“利用インスタンス”） |
| 存在場所 | アプリの“ホーム（発行元）テナント”に1つ | 利用する各テナントごとに1つ（または複数） |
| 主な用途 | 認証設定、リダイレクト URI、証明書/シークレット、API スコープなど | 割り当て、条件付きアクセス、SSO 設定、プロビジョニング、ユーザー/グループ管理など |
| 運用上のポイント | 提供側で一元管理しやすい | 顧客（テナント）管理者の裁量が強く、提供側が勝手に書き換えられない領域が多い |
顧客テナントに作られている Enterprise Application は「App Registration の表示をそのまま映すビュー」ではなく、顧客テナントが所有する“ローカルな設定を持った別物”です。ここが挙動差の根っこです。
なぜ「ホームページ URL」は同期されないのか
ポイントは“初回同意時にコピーされて固定される値”かどうかです。
Enterprise Application は初回同意時の状態で作成される
顧客が最初に同意した瞬間に、顧客テナント側にはサービス プリンシパルが作成されます。この作成時に、App Registration から一部の表示用メタデータがコピーされます。
しかし、コピーされた後は、すでに稼働しているインスタンスとして扱われるため、App Registration 側のメタデータをあとから変更しても、既存のサービス プリンシパルが自動で再取得して更新する仕組みがありません。
ロゴだけ更新されるのは “参照” だから
ロゴは、ポータルや My Apps の表示で、CDN などの仕組みを通じて「画像を参照している」ケースが多く、提供側で差し替えると結果として顧客側にも新しいロゴが見えるようになります。
一方でホームページ URL は、サービス プリンシパル作成時に「文字列としてコピーされた値」であり、後続の自動同期対象になっていないため、変更しても動きません。
なぜ顧客によって「古い URL」「空欄」が混在するのか
この混在はほぼ初回同意した時点の App Registration の状態で説明できます。
| 初回同意（サービス プリンシパル作成）時点 | その顧客テナントでの Enterprise Application の状態 | 後から App Registration を変更した場合 |
|---|---|---|
| ホームページ URL が未設定（空欄） | ホームページ URL も空欄で作成される | 基本的に自動では埋まらない |
| ホームページ URL が設定済み | その URL がコピーされる | コピーされた古い URL が残り続ける |
つまり、「空欄の顧客」と「古い URL の顧客」がいるのは、提供側が過去にホームページ URL を設定する前に同意が発生した顧客がいる、あるいは検証/本番・担当者・案内資料の版の違いで同意タイミングがズレたなど、オンボーディングの歴史が反映されていると考えるのが自然です。
ここを混同しやすい：ホームページ URL と認証設定は別
「ホームページ URL が変わらない＝認証の挙動が変わる」と誤解されがちですが、通常は別物です。
- ホームページ URL：主にポータル上の表示、My Apps のタイルの遷移先、管理者向け情報としての意味合いが強い
- リダイレクト URI（返信 URL）：OAuth/OIDC の認証フローで必須。誤るとサインインが失敗する
- サインオン URL / Identifier：SAML 連携の設定で重要（構成次第）
今回の論点はあくまで「表示/導線としてのホームページ URL」の同期であり、認証そのもの（サインイン可否）と切り分けて考えると判断が早くなります。
実務で困るポイント：どこに影響が出るのか
ホームページ URL が古い／空欄でも、認証自体は問題なく動くことが多い一方で、運用やユーザー体験に地味に効きます。
- My Apps / アクセス パネルからアプリを起動したいときに、タイルの遷移先が不正確になる（空欄だと起動できないケースも）
- 管理者が Enterprise Application のプロパティを見たとき、問い合わせ先・導線が分からずサポートが遅れる
- 提供側がドメイン移行やブランド変更をしたとき、旧 URL が残り続けて混乱する
最初にやるべき切り分けチェック
原因が「仕様」だとしても、現場では別の要因が混ざっていることがあります。以下を先に確認すると、余計な遠回りを避けられます。
| チェック項目 | 確認観点 | 判断の目安 |
|---|---|---|
| アプリが本当にマルチテナントか | App Registration の「アカウントの種類」（単一/複数テナント） | 単一テナントなら顧客側に同様の形では作られない（別方式の可能性） |
| 顧客側の対象が“同じアプリ”か | Enterprise Application のアプリケーション ID（クライアント ID / AppId） | 別の AppId なら別アプリの可能性 |
| 初回同意の時期がいつか | 監査ログ、サインインログ、社内の案内メールや手順書の改版履歴 | URL 未設定時期に同意していれば空欄/旧 URL が説明できる |
| 顧客側でローカル変更していないか | Enterprise Application のプロパティが手で書き換えられていないか | 顧客ごとに値がバラバラなら手動変更の可能性 |
既存テナントの「ホームページ URL」を更新する方法
ここが一番重要です。既に作成済みの Enterprise Application（サービス プリンシパル）に対して、提供側だけで“一括自動同期”させる万能手段は基本的にありません。現実的な対応は次の3つです。
方法A：顧客テナントの管理者にポータルで手動更新してもらう
最も確実で、影響範囲も読みやすい方法です。テナント数が少ない場合や、顧客のIT管理が整っている場合に向きます。
- 顧客に Microsoft Entra 管理センターへサインインしてもらう
- 「エンタープライズ アプリケーション」から対象アプリを開く
- 「プロパティ」画面で ホームページ URL を新しい URL に更新
- 必要なら My Apps の表示やタイル起動を確認
提供側としては、更新手順をスクリーンショット付きで配布し、入力する URL をコピー＆ペーストできるようにしておくと、ミスが激減します。
方法B：顧客テナント側でスクリプト更新（Microsoft Graph / PowerShell）
顧客が複数環境（本番/検証）を持っている、子会社テナントが多い、運用を自動化したい、といったケースではスクリプトが効きます。ポイントは「顧客管理者が、自分のテナント内のサービス プリンシパルを更新する」ことです。
例：Microsoft Graph PowerShell を使って、特定の AppId のサービス プリンシパルのホームページを更新するイメージです。
# 例：顧客テナントの管理者が実行（必要権限・組織ポリシーに注意）
# Connect-MgGraph -Scopes "Application.ReadWrite.All"
$appId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" # 提供側アプリのクライアントID
$newUrl = "https://example.com/new-home"
# 対象サービス プリンシパルを取得
$spList = Get-MgServicePrincipal -Filter "appId eq '$appId'"
if ($null -eq $spList) {
throw "Service Principal が見つかりません。AppId を確認してください。"
}
# 複数返る可能性もあるため、全件更新の例
foreach ($sp in $spList) {
Update-MgServicePrincipal -ServicePrincipalId $sp.Id -BodyParameter @{ homepage = $newUrl }
Write-Host ("Updated: " + $sp.DisplayName + " (" + $sp.Id + ")")
}
注意点：
- スクリプト実行には、組織のポリシーや権限承認が必要です。目安として Application.ReadWrite.All や Directory.ReadWrite.All 相当の権限が必要になることがあります。
- 顧客によっては同じ AppId のサービス プリンシパルが複数存在することがあるため、まずは 取得結果を表示して対象を確認する運用を推奨します。
- 誤更新を防ぐため、AppId だけでなく表示名やアプリ所有組織なども合わせて確認できる手順にしておくと安全です。
方法C：Enterprise Application を作り直す（削除→再同意）
「初回同意時のメタデータを取り込み直す」には、サービス プリンシパルを作り直すのが確実です。ただし、影響が出やすいので慎重に。
- 顧客テナントで対象 Enterprise Application を削除
- 新しいホームページ URL を設定済みの App Registration に対して再度同意
- 必要に応じて、ユーザー/グループ割り当て、条件付きアクセス、SSO設定、プロビジョニング設定を復元
削除・再同意が向くのは次のようなケースです。
- まだ利用ユーザーが少ない、あるいは導入直後で影響が限定的
- 設定がほぼデフォルトで、再構成の手間が小さい
- どうしても“作成時点の情報”を最新化したい（監査/ガバナンス要件など）
3つの方法を比較：どれを選ぶべきか
| 方法 | 工数 | 影響リスク | 向いているケース | 提供側ができる支援 |
|---|---|---|---|---|
| 手動更新（ポータル） | 小〜中 | 低 | テナント数が少ない／顧客管理が成熟 | 手順書、入力URLの案内、対象アプリ特定のガイド |
| スクリプト更新（Graph） | 中 | 中 | テナントが多い／運用自動化したい | 検証済みスクリプト例、権限説明、ロールバック案 |
| 削除→再同意 | 中〜大 | 高 | 導入初期／設定が少ない／取り込み直しが必須 | 影響説明、復元チェックリスト、再同意手順 |
顧客への案内にそのまま使えるテンプレ
サポート窓口でのやり取りを減らすには、提供側が「どの画面で何を直すか」を明確に伝えることが重要です。以下はメール/チケットに貼れる例です。
| 項目 | 記載例 |
|---|---|
| 対象アプリ名 | （例）Contoso SSO |
| クライアントID（AppId） | xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx |
| 更新する値 | Enterprise Application の「ホームページ URL」 |
| 更新後URL | https://example.com/new-home |
| 操作場所 | Microsoft Entra 管理センター → エンタープライズ アプリケーション → （対象アプリ）→ プロパティ |
（案内文例）
お手数ですが、貴テナントの Microsoft Entra 管理センターにて、
対象 Enterprise Application（クライアントID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx）の
「プロパティ」画面にある「ホームページ URL」を以下へ更新してください。
更新後URL: https://example.com/new-home
本変更は表示・起動導線の更新であり、通常サインイン可否には影響しません。
「自動同期したい」を現実に寄せる設計アイデア
残念ながら、App Registration のホームページ URL を変更したら、全顧客テナントの Enterprise Application に自動で降っていく――という同期は基本的に期待できません。そこで、運用負荷を下げるための“設計側の工夫”が効きます。
アイデア：URL を“変わる前提”で設計し、リダイレクトで吸収する
ホームページ URL が古いまま残る可能性がある以上、一度配った URL はできるだけ変えない、または 変わっても吸収できる形にします。
- ホームページ URL は 製品トップではなく、将来も維持する ランディングページ（例：/entra-home）にする
- ブランド変更やサイト移行があっても、ランディングページは 301/302 で新ページへ誘導する
- ランディングページに「管理者向け：SSO 設定」「問い合わせ」「障害情報」などの導線を集約する
こうしておけば、顧客の Enterprise Application に旧 URL が残っても、実害を最小化できます。提供側のコントロールが効くのが最大のメリットです。
アイデア：オンボーディング前に必ずメタデータを確定させる
混在の原因の多くは「同意が先に走った」ことです。次の運用ルールを作るだけで再発を抑えられます。
- 顧客に同意 URL を渡す前に、App Registration の「ブランド（ロゴ/ホームページ URL/サポート連絡先）」を確定させる
- テストテナントで同意→Enterprise Application の見え方を確認してから公開する
- URL 変更が発生したら、変更日と新旧 URL をリリースノートに残す
アイデア：顧客向け“更新手順”を最初から提供する
将来の変更は避けられないことが多いので、最初から「変更があったらこう直す」を提供しておくと、サポートが楽になります。
- 顧客管理者向けに「Enterprise Application のプロパティ更新手順」を1ページにまとめる
- 更新対象の値（新URL）は、コピーしやすい形で案内する
- スクリプトで更新したい顧客向けに、Graph/PowerShell のサンプルを添える
アイデア：ギャラリー アプリ（アプリ ギャラリー）公開を検討する
多テナントに配布する ISV/SaaS 提供者で、顧客側の導入体験や情報統一を重視するなら、Microsoft Entra のアプリ ギャラリー（ギャラリー アプリケーション）として掲載する選択肢があります。
- 顧客はギャラリーから検索して追加でき、導入フローが整う
- 説明文、サポート情報、ロゴなどの“公開情報”を整備しやすい
- テンプレート化によって、初期設定のブレを減らせる
ただし、ギャラリー掲載＝既存の Enterprise Application の全プロパティが自動で書き換わる、という意味ではありません。ギャラリーはあくまで「見つけやすさ」「導入の型」「情報提供」を強化する手段として捉え、既存テナントの URL 更新は別途運用でカバーするのが現実的です。
よくある質問
App Registration 側の表示名も顧客側で変わらない？
ホームページ URL と同じく、表示名も顧客テナントのサービス プリンシパル作成時点の値が残り、あとから自動同期されないことがあります。顧客側でローカルに変更されている場合もあるため、更新したい場合は顧客側での変更が必要です。
提供側が顧客テナントの Enterprise Application を“勝手に”更新できないの？
原則できません。Enterprise Application（サービス プリンシパル）は顧客テナントのディレクトリ オブジェクトであり、更新には顧客側の管理者権限と承認が必要です。提供側が一括で直したい場合は、顧客に対して管理者同意を得た上で、顧客が許可した権限範囲で管理ツールを提供する、という設計になります。
削除→再同意するとユーザー影響はある？
あります。割り当て、条件付きアクセス、プロビジョニング、SSO 設定など、Enterprise Application 側で持っている設定が消える可能性があります。実施する場合は、事前に「何が消えるか」「復元手順」「影響時間」を顧客に説明し、チェックリストを用意するのが安全です。
まとめ
- Enterprise Application（サービス プリンシパル）は、初回同意時に App Registration から一部メタデータをコピーして作成される
- ロゴは参照型のため反映されやすいが、ホームページ URL はコピーされた値で、自動同期されない
- 顧客ごとの「古い URL」「空欄」の混在は、初回同意時点の App Registration の状態差で説明できる
- 既存テナントで URL を直すには、手動更新、顧客側スクリプト更新、削除→再同意のいずれかが現実的
- 今後の運用負荷を下げるなら、変わらない URL 設計（ランディング＋リダイレクト）と、オンボーディング手順の整備が効果的
コメント