SharePoint の「Change your SharePoint domain name」は、Microsoft 365 テナント作成時に決まった contoso.sharepoint.com のような SharePoint ドメイン名を、組織名変更・合併・買収などに合わせて変更するための公式手順です。結論から言うと、これは単なる表示名変更ではなく、SharePoint サイト、OneDrive、Teams 連携、Power Automate、Power BI、カスタムアプリまで影響する大きなテナント単位の変更です。実施する場合は、URL変更後のリダイレクト期限、対象外構成、業務停止リスク、PowerShellでのスケジュール設定を事前に確認してから進める必要があります。Microsoft Learn の該当ページでは、SharePoint と OneDrive の URL に使われる元の onmicrosoft.com ドメインを変更できる一方、メールアドレスには影響しないと説明されています。(Microsoft Learn)
なお、Microsoft Learn の該当ページは確認時点で「Last updated on 2026-06-17」と表示されています。そのため、記事や社内資料では「2026年7月時点の公式情報をもとに確認」と表現すると安全です。(Microsoft Learn)
SharePoint のドメイン名変更とは何か
SharePoint のドメイン名変更とは、組織の SharePoint Online と OneDrive for Business の URL に含まれるテナント名部分を変更する機能です。
たとえば、会社名が Contoso から Fabrikam に変わった場合、次のような変更を行えます。
| 変更前 | 変更後 |
|---|---|
https://contoso.sharepoint.com | https://fabrikam.sharepoint.com |
https://contoso-my.sharepoint.com | https://fabrikam-my.sharepoint.com |
https://contoso.sharepoint.com/sites/sales | https://fabrikam.sharepoint.com/sites/sales |
ここで重要なのは、変更されるのは主にドメイン名部分であり、サイトパスやユーザー名に基づく OneDrive の相対パスまで別名に変わるわけではない点です。Microsoft の公式情報でも、OneDrive は URL のドメイン名部分が変更対象で、UPN に基づく相対パスは変更されないとされています。(Microsoft Learn)
メールアドレスや独自ドメイン変更とは別物
混同しやすいのが、Microsoft 365 の独自ドメイン追加やメールアドレス変更です。
example.co.jp のような独自ドメインを Microsoft 365 に追加しても、既存の SharePoint URL が自動で example.sharepoint.com のように変わるわけではありません。SharePoint の URL は、テナント作成時の onmicrosoft.com ドメイン名をもとに作られるため、別途 SharePoint ドメイン名変更の手順が必要です。Microsoft 365 の fallback domain に関する公式情報でも、新しい onmicrosoft.com ドメインを fallback domain にしても既存の SharePoint と OneDrive の URL はそのままだと説明されています。(Microsoft Learn)
どのような組織が検討すべきか
SharePoint ドメイン名変更は、見た目を少し整えるためだけに実施するには影響が大きい作業です。検討すべき典型例は、次のようなケースです。
| 検討すべきケース | 判断のポイント |
|---|---|
| 社名変更・ブランド変更 | 外部共有リンクやブラウザURLに旧社名が残ることが問題になる |
| 合併・買収 | 旧法人名の SharePoint URL を長期利用したくない |
| テナント作成時の名称ミス | 初期導入時の仮名や略称が本番URLに残っている |
| グローバル統合 | 地域ごとに異なるテナント名を統一したい |
一方で、単に特定サイトの /sites/sales を /sites/marketing に変えたいだけなら、テナント全体のドメイン名変更ではなく「サイトアドレスの変更」を検討すべきです。Microsoft も、サイト単位のアドレス変更は別手順として案内しています。(Microsoft Learn)
2026年7月時点で確認すべき主な更新ポイント
今回の公式情報で管理者が特に押さえるべきポイントは、標準のテナントリネームと、SharePoint Advanced Management を使う Advanced Tenant Rename の使い分けです。
| 確認項目 | 内容 |
|---|---|
| 標準機能の対象 | SharePoint サイト、OneDrive アカウント、SharePoint Embedded コンテナーの合計が 10,000 以下の組織 |
| 大規模環境の対応 | 10,000 を超える、または優先制御が必要な場合は Advanced Tenant Rename を利用 |
| Advanced Tenant Rename の位置づけ | SharePoint Advanced Management の機能として提供 |
| 優先処理 | 最大 4,000 サイトを優先リネーム対象に指定可能 |
| 変更回数 | 原則として SharePoint ドメイン名変更は 1 回のみ |
| リダイレクト期限 | 旧URLからのリダイレクトは 1 年で期限切れ |
| メールへの影響 | メールアドレスには影響しない |
標準版のリネーム機能は、合計 10,000 サイト以下の組織向けとされています。ここでいうサイト数には、SharePoint サイト、OneDrive アカウント、SharePoint Embedded コンテナーが含まれます。一方、Advanced Tenant Rename は SharePoint Advanced Management の一部で、サイト数に関係なく利用でき、重要サイトを先に処理するための優先指定にも対応しています。(Microsoft Learn)
影響範囲：SharePoint だけでなく OneDrive、Teams、Power Platform も確認する
SharePoint ドメイン名変更の最大の落とし穴は、「SharePoint のURLだけ変わる」と考えてしまうことです。実際には、SharePoint をデータ基盤として使う多数の Microsoft 365 サービスに影響します。
| 影響対象 | 起こり得る影響 | 管理者の対応 |
|---|---|---|
| SharePoint サイト | リネーム中、旧ドメイン上のサイトが一時的にアクセス不可になる | 低利用時間帯に実施し、利用者へ事前周知 |
| OneDrive | 同期アプリやクイックアクセスで一部影響が出る可能性 | OneDrive 同期アプリのバージョンと通信先を確認 |
| Teams | ファイルタブ、SharePoint リストタブ、会議メモなどに一時的な影響 | Teams 利用部門へ作業時間と復旧見込みを案内 |
| Power Automate | SharePoint 接続を使うフローが動作しない場合がある | 重要フローを棚卸しし、必要に応じて再作成・URL更新 |
| Power BI | SharePoint をデータソースにしたレポートが動作しない場合がある | .pbix を退避し、接続先を更新して再発行 |
| eDiscovery | 保持対象URLの更新が必要になる | Microsoft Purview 側の hold URL を新URLへ変更 |
| カスタムアプリ | 絶対URLや HTTP 308 リダイレクト未対応で失敗する可能性 | アプリ内URLとリダイレクト処理を事前検証 |
| 検索・Delve | 検索インデックスが新URLを反映するまで時間がかかる | 検索結果の一時的な揺れを利用者へ説明 |
公式情報では、リネーム開始後、各サイトは新ドメインへの個別リネームのキューに入り、旧ドメイン上に残っている間は一時的にアクセスできなくなるとされています。また、検索インデックスの反映には、サイト規模によって数日から数週間以上かかる場合があると説明されています。(Microsoft Learn)
実施できない、または注意が必要な構成
SharePoint ドメイン名変更は、すべての Microsoft 365 テナントで使えるわけではありません。特にグローバル企業や公共系クラウドを利用している組織では、最初に制限事項を確認する必要があります。
| 構成・状態 | 可否・注意点 |
|---|---|
| Microsoft 365 Multi-Geo | 現在または過去に構成されている場合、利用不可 |
| GCC、GCC High、DoD などの政府系クラウド | 利用不可 |
特殊クラウド、.de ドメイン | 利用不可とされるケースあり |
| Vanity domain 構成 | 利用不可 |
| Alternate URLs が残っているテナント | 事前削除が必要 |
| BPOS サイトが残っているテナント | 事前削除・サポート対応が必要 |
| 古い SharePoint public sites が残っているテナント | 事前削除・サポート対応が必要 |
| 削除済みサイト | 変更後に復元できないサイトがあるため事前確認が必要 |
| ルートサイト置換 | 予約から完了までの間は実施不可 |
特に Multi-Geo は注意が必要です。公式情報では、現在 Multi-Geo を利用している組織だけでなく、過去に試用版や有料提供で有効化したことがあるテナントも制限対象に含まれると説明されています。(Microsoft Learn)
移行期限として重要なのは「旧URLリダイレクトの1年」
SharePoint ドメイン名変更では、旧URLから新URLへのリダイレクトが作成されます。ただし、このリダイレクトは恒久的ではなく、公式情報ではリネーム後 1 年で期限切れになるとされています。(Microsoft Learn)
つまり、管理者が実務上設定すべき移行期限は「リネーム完了日から1年以内」です。
この1年の間に、少なくとも次の作業を完了させる必要があります。
| 期限内に行う作業 | 具体例 |
|---|---|
| 社内ポータルのリンク更新 | トップページ、部門ポータル、ナビゲーション、ブックマーク集 |
| 業務アプリのURL更新 | ワークフロー、承認アプリ、社内システム連携 |
| Power Platform の接続更新 | Power Automate、Power Apps、Power BI の SharePoint 接続 |
| ドキュメント内URLの修正 | 手順書、マニュアル、Excel台帳、メールテンプレート |
| 外部共有先への案内 | 取引先、委託先、グループ会社へのURL変更通知 |
| 監査・コンプライアンス設定の更新 | eDiscovery、保持ポリシー、監査手順書 |
1年のリダイレクト期間があるからといって、後回しにするのは危険です。実務では、リネーム後 1〜2 か月以内に主要リンクを更新し、半年以内に業務アプリと自動化フローを点検し、期限の 2〜3 か月前に旧ドメインアクセスの残存確認を行うスケジュールが現実的です。
設定変更の流れ
公式手順では、大きく分けて新しい onmicrosoft.com ドメインの追加、PowerShell によるリネーム予約、必要に応じた優先サイト設定、進行状況の監視、リネーム後の確認という流れになります。
新しいドメイン名を追加する
最初に、新しく使いたい SharePoint ドメイン名が利用可能か確認します。たとえば fabrikam.sharepoint.com を使いたい場合、ブラウザでアクセスし、見つからないことを示す画面が出る場合は利用できる可能性があります。ただし、他の顧客が登録済みの場合、Microsoft はその顧客情報を提供できません。(Microsoft Learn)
次に、Microsoft 365 管理センターで新しい .onmicrosoft.com ドメインを追加します。このとき、通常の「ドメインの追加」操作ではなく、公式手順に沿って onmicrosoft.com ドメインを追加する必要があります。Microsoft 365 では onmicrosoft.com ドメインを合計 5 個まで作成でき、作成後は削除できないため、スペルミスは重大な問題になります。(Microsoft Learn)
PowerShell でリネームを予約する
SharePoint ドメイン名変更は、SharePoint Online Management Shell から実行します。公式手順では、最新の SharePoint Online Management Shell を利用し、SharePoint 管理者以上の権限で接続する必要があります。(Microsoft Learn)
基本的な流れは次のとおりです。
Connect-SPOService -Url "https://contoso-admin.sharepoint.com"Start-SPOTenantRename -DomainName "fabrikam" -ScheduledDateTime "2026-07-20T22:00:00"DomainName には fabrikam.sharepoint.com 全体ではなく、sharepoint.com や onmicrosoft.com の前に来る名前だけを指定します。ScheduledDateTime は、現在時刻から 24 時間以上先、30 日以内に設定する必要があります。(Microsoft Learn)
予約後、開始前であれば次のコマンドでキャンセルできます。
Stop-SPOTenantRenameただし、リネーム処理がすでに開始されている場合は停止できないため、実行日時の承認フローは慎重に設計するべきです。
Advanced Tenant Rename で重要サイトを優先する
SharePoint Advanced Management のライセンス条件を満たす場合、Advanced Tenant Rename を利用できます。この機能では、最大 4,000 サイトを優先対象として指定できます。公式情報では、優先サイトは全体の中で先に処理されるものの、必ず最初に完了する保証ではないと説明されています。(Microsoft Learn)
重要サイトを優先する例は次のとおりです。
Set-SPOTenantRenameSitePrioritization -SiteUrl https://contoso.sharepoint.com/sites/projectxCSVでまとめて指定する場合は、SiteUrl という列を用意し、各行に対象サイトのURLを記載します。
Import-Csv <Path> | ForEach-Object {
Set-SPOTenantRenameSitePrioritization -SiteUrl $_.SiteUrl
}優先対象にすべきなのは、全社ポータル、経営会議資料、営業共有サイト、ヘルプデスク用サイト、基幹業務の Power Automate や Power BI が参照するサイトなどです。逆に、アーカイブ用途のサイトや利用頻度が低い部門サイトまで優先枠に入れると、本当に重要なサイトの優先度が薄れます。
管理者が事前に確認すべきチェックリスト
実施前には、技術面だけでなく、業務影響と利用者対応まで含めて確認します。
| 確認項目 | 確認内容 | 完了目安 |
|---|---|---|
| サイト数 | SharePoint サイト、OneDrive、SharePoint Embedded を含めた総数 | 実施1か月前 |
| Multi-Geo | 現在または過去に有効化していないか | 実施1か月前 |
| 削除済みサイト | 復元が必要なサイトが残っていないか | 実施2週間前 |
| ロック済みサイト | Teams チャネルや Microsoft 365 グループ接続サイトがロックされていないか | 実施2週間前 |
| カスタムアプリ | 絶対URLを埋め込んでいないか | 実施2週間前 |
| Power Automate | SharePoint 接続を使う重要フローを洗い出したか | 実施2週間前 |
| Power BI | SharePoint をデータソースにするレポートを確認したか | 実施2週間前 |
| Teams | ファイルタブ、リストタブ、Wiki、会議メモの影響を周知したか | 実施1週間前 |
| OneDrive 同期 | 同期アプリのバージョンと通信先ブロックの有無を確認したか | 実施1週間前 |
| 利用者周知 | 作業時間帯、アクセス不可の可能性、旧URLの扱いを案内したか | 実施1週間前 |
| 監視体制 | 実施中のステータス確認担当と障害連絡先を決めたか | 実施前日 |
この中でも特に重要なのは、絶対URLの棚卸しです。SharePoint のページ本文、ハブサイトメニュー、カスタムWebパーツ、PowerShellスクリプト、Excel台帳、社内ポータルのリンク集などに旧ドメインが直接書かれている場合、自動更新されないことがあります。公式情報でも、絶対URLを含むカスタムアプリ、グループポリシー、サイトカスタマイズ、埋め込みコードなどは手動更新が必要になる可能性が示されています。(Microsoft Learn)
実施中・実施後の監視方法
リネームの進行状況は、PowerShell で確認します。
Get-SPOTenantRenameStatusサイト単位の状態を確認する場合は、次のコマンドを使います。
Get-SPOSiteRenameState失敗したサイトを抽出してCSVに出力する場合は、次のように確認します。
Get-SPOSiteRenameState -ParentOperationID <RenameJobID> -State Failed |
Export-Csv -Path <Path>公式手順では、リネーム成功の確認として、全体ステータス、リネーム済みサイト数、総サイト数、Attention Required に表示されるリネームできないサイト数を確認するよう案内されています。(Microsoft Learn)
実務では、PowerShell の結果だけで完了判断をしないほうが安全です。代表的なサイトに実際にアクセスし、Teams のファイルタブ、OneDrive同期、Power Automate、Power BI、検索結果、外部共有リンクまで確認してから、社内向けに「通常利用再開」の案内を出すのがおすすめです。
失敗しやすいポイントと回避策
旧URLのリダイレクトに頼り続ける
旧URLのリダイレクトは 1 年で期限切れになります。リダイレクトが効いている間は問題が見えにくいため、期限直前になって業務アプリや手順書のリンク切れが一気に表面化することがあります。
回避策は、リネーム直後から旧ドメインを含むURLを検索し、更新計画を作ることです。SharePoint ページ、Teams のタブ、Power Automate、Power BI、社内Wiki、マニュアル、グループポリシー、スクリプトを対象にします。
テスト環境で本番用ドメイン名を使ってしまう
公式手順では、テスト環境で本番用のドメイン名を使ってこの手順を試さないよう警告されています。一度使うと、本番環境で利用できなくなる可能性があるためです。(Microsoft Learn)
検証では、本番ブランド名とは異なる検証用の名前を使い、本番で使う予定の onmicrosoft.com 名は最後まで温存してください。
Teams と SharePoint の関係を軽く見る
Teams のファイルは SharePoint に保存されます。そのため、SharePoint ドメイン名変更は Teams にも波及します。公式情報では、Teams のファイルタブ、SharePoint リストタブ、会議メモ、Wiki などに影響が出る場合があるとされています。(Microsoft Learn)
特に現場部門では「Teams が止まった」と受け止められることがあります。利用者向け案内では「SharePoint のURL変更作業」ではなく、「Teams のファイル利用にも一時的な影響が出る可能性がある作業」と説明したほうが混乱を減らせます。
Power Platform の接続を後回しにする
Power Automate や Power BI は、業務プロセスの裏側で動いていることが多く、管理者が把握しきれていない場合があります。公式情報では、SharePoint 接続を使う一部の Power Automate フローや、SharePoint をデータソースにする Power BI レポートで対応が必要になる場合があるとされています。(Microsoft Learn)
事前に環境単位で所有者、接続先URL、実行頻度、業務重要度を整理し、リネーム後に優先確認する順番を決めておきましょう。
グローバル組織での進め方
グローバル展開している組織では、単純に週末夜間に実施すればよいとは限りません。日本では夜間でも、欧米やアジアの別拠点では業務時間中になることがあります。
進め方の目安は次のとおりです。
| フェーズ | 実施内容 |
|---|---|
| 企画 | 変更理由、対象テナント、制限事項、ライセンス要件を整理 |
| 棚卸し | サイト数、OneDrive数、Teams連携、Power Platform、カスタムアプリを洗い出し |
| 影響評価 | 業務停止が許容できないサイトとアプリを特定 |
| 優先順位付け | Advanced Tenant Rename を使う場合、優先サイトを最大 4,000 件まで選定 |
| 周知 | タイムゾーン別に利用者向け案内を出す |
| 実施 | 低利用時間帯にリネームを開始 |
| 監視 | PowerShell と実アクセスで状態を確認 |
| 後処理 | 旧URLの更新、リダイレクト期限管理、残課題の追跡 |
グローバルでは「作業日」よりも「どの地域の業務時間を避けるか」が重要です。全地域で完全に影響ゼロにするのは難しいため、重要サイトの優先処理、利用者周知、緊急時の問い合わせ窓口をセットで準備する必要があります。
実施判断の基準
SharePoint ドメイン名変更を実施すべきか迷う場合は、次の基準で判断すると現実的です。
| 判断基準 | 実施を検討すべき状態 | 見送ってもよい状態 |
|---|---|---|
| ブランド影響 | 外部共有URLに旧社名が出ることが問題 | 社内利用中心で旧名が許容される |
| 業務影響 | 影響範囲を棚卸しでき、停止時間を調整できる | Teams、Power Platform、カスタムアプリの把握が不十分 |
| 技術条件 | Multi-Geo や政府系クラウドなどの制限に該当しない | 制限事項に該当する可能性がある |
| 運用体制 | 実施後1年以内に旧URL更新を完了できる | リダイレクトに頼ったまま放置される可能性が高い |
| 大規模対応 | SAM による優先制御や十分な検証計画がある | サイト数が多く、重要サイトの選別もできていない |
社名変更や統合ブランドの確立が重要な場合、SharePoint ドメイン名変更は有効な選択肢です。ただし、URLが変わるという性質上、情報システム部門だけで完結する作業ではありません。Teams、Power Platform、データ分析、監査、現場部門、外部共有先まで含めた移行プロジェクトとして扱うべきです。
まず管理者が取るべき次の行動
SharePoint の「Change your SharePoint domain name」を検討している管理者は、いきなり PowerShell を実行するのではなく、まず次の順番で確認してください。
- 現在の SharePoint ドメイン名と、変更したい新ドメイン名を確定する
- Multi-Geo、政府系クラウド、Vanity domain、古い public site などの制限に該当しないか確認する
- SharePoint サイト、OneDrive、SharePoint Embedded コンテナーの合計数を把握する
- 標準機能で足りるか、Advanced Tenant Rename と SharePoint Advanced Management が必要か判断する
- Teams、Power Automate、Power BI、カスタムアプリ、eDiscovery の影響を棚卸しする
- リネーム後 1 年以内に旧URLを更新する移行計画を作る
- 低利用時間帯に PowerShell でリネームを予約し、完了後はステータスと実利用の両面で確認する
SharePoint ドメイン名変更は、成功すれば旧社名や誤った初期テナント名を整理でき、外部共有やブランド管理の面で大きな効果があります。一方で、事前確認が不足すると Teams や自動化フロー、レポート、カスタムアプリの不具合につながります。管理者は「URLの見た目を変える作業」ではなく、「Microsoft 365 全体に影響する移行作業」として計画することが重要です。
コメント