Teams に紐づく SharePoint のチームサイト（Microsoft 365 グループ接続サイト）を、情報発信向けのコミュニケーションサイトに変えたい――しかしサイト数が多いと手作業の作り直しは現実的ではありません。PnP PowerShellで何ができて何ができないのか、そして大量サイトを効率よく移行する現実的な手順を整理します。
今回よくある悩み：Teamsサイト（チームサイト）をコミュニケーションサイトに変換したい
Microsoft Teams を作成すると、裏側で SharePoint に「Microsoft 365 グループ接続のチームサイト（いわゆる Teams サイト）」が自動作成されます。共同作業には最適ですが、運用が進むほど「社内ポータル的に見せたい」「ナビゲーションをトップ中心にしたい」「発信サイトとして整えたい」といった理由で、コミュニケーションサイトへ置き換えたくなる場面が増えます。
ここで最初にぶつかるのが、PnP PowerShell で“変換コマンド一発”ができないか？という疑問です。結論から言うと、期待している意味での直接変換はできません。
結論：PnP PowerShellで「Teamsサイト → コミュニケーションサイト」へ直接変換はできない
Teams に接続された SharePoint チームサイト（Microsoft 365 グループ接続サイト）を、PnP PowerShell でコミュニケーションサイトへ“直接変換”することは公式にはサポートされていません。
ポイントは「Teams サイト＝グループ接続サイト」であることです。コミュニケーションサイトは（基本的に）発信向けで、サイトの前提（用途・権限モデル・連携の仕組み）が異なります。そのため、単純な“サイト種別の切り替え”は提供されていません。
「Enable-PnPCommSite」は使えないの？
よく名前が挙がる Enable-PnPCommSite は、クラシック チームサイトに対して、モダンのコミュニケーションサイト体験（機能）を有効化するためのコマンドです。つまり、対象は「クラシック チームサイト」であり、Teams に紐づいたモダンのグループ接続サイトには適用できません。
さらに、このコマンドは「サイトコレクションのルートが対象」といった前提もあります。
なぜ変換できないのか：Teamsサイトとコミュニケーションサイトは設計思想が違う
「見た目を変えるだけでは？」と思いがちですが、Teamsサイトとコミュニケーションサイトは“土台”が違います。目的に合わせた最適化の方向性がそもそも異なるため、変換というより“新規に作って移行”が基本戦略になります。
| 観点 | Teamsサイト（グループ接続のチームサイト） | コミュニケーションサイト |
|---|---|---|
| 主目的 | チームでの共同編集・プロジェクト運用 | 社内向けの情報発信・ポータル・広報 |
| Microsoft 365 グループ/Teams 連携 | 強く連携（メンバー/所有者、メール、予定表など） | 基本は非連携（発信サイトの前提） |
| 典型的な権限モデル | “メンバーが編集する”前提（共同作業） | “少数が編集し多数は閲覧”前提（発信） |
| ナビゲーション | 左ナビ中心（クイック起動）で運用されがち | トップナビ中心（発信導線を設計しやすい） |
| 運用で増えがちな課題 | 情報が散らかる／ページが埋もれる／発信には不向き | 共同作業には権限や運用ルール設計が必要 |
“変換”ではなく“置き換え”が現実解：推奨される対応方針
直接変換ができない以上、実務的には次の3ステップで「大量サイトを半自動化」するのが最短ルートです。
新しいコミュニケーションサイトを一括作成する（PnP PowerShell）
まずは移行先となるコミュニケーションサイトを作成します。PnP PowerShell の New-PnPSite -Type CommunicationSite で一括作成できます。
# 例：コミュニケーションサイト作成（PnP PowerShell）
# 事前に、テナント管理者または SharePoint 管理者権限で接続してください
Connect-PnPOnline -Url "https://tenant-admin.sharepoint.com" -Interactive
New-PnPSite -Type CommunicationSite `
-Title "広報ポータル" `
-Url "https://tenant.sharepoint.com/sites/pr-portal" `
-Lcid 1041 `
-Owner "[email protected]"運用面でのコツは、最初からサイトデザイン（SiteDesignId）やテンプレート適用の前提で作ることです。これにより「見た目・構造のブレ」を抑えながら大量作成できます。
既存 Teams サイトから構造を移す（PnP プロビジョニング）
コミュニケーションサイトを作ったら、次に“器（構造）”を整えます。ここで有効なのが PnP Provisioning（プロビジョニングテンプレート）です。
「既存サイトの構造をテンプレート化 → 新サイトへ適用」という流れにすると、サイト設計をスクリプトで再現できます。
代表的なイメージは次の通りです（環境や要件により、ページやリストの取り込み条件は調整してください）。
# 例：構造のテンプレート化（概念例）
# 1) 既存 Teams サイトへ接続してテンプレートを取得
Connect-PnPOnline -Url "https://tenant.sharepoint.com/sites/source-teams-site" -Interactive
Get-PnPProvisioningTemplate `
-Out ".\site-structure.pnp" `
-Handlers Lists,Fields,ContentTypes,Navigation,Branding,Pages
# 2) 新しいコミュニケーションサイトへ接続して適用
Connect-PnPOnline -Url "https://tenant.sharepoint.com/sites/target-comm-site" -Interactive
Apply-PnPProvisioningTemplate -Path ".\site-structure.pnp"テンプレート運用のポイントは「最初から“移行しないもの”を割り切る」ことです。Teams/グループ連携、Teams のタブ設定、チャネル関連などは SharePoint サイト構造の範囲外になります。
コンテンツを移す（ページ・ドキュメント・リスト）
器ができたら中身を移します。移行対象は大きく分けて次の3つです。
- ページ（Site Pages）：発信サイトとして最重要。トップページ、カテゴリ別のまとめページなど。
- ドキュメント：共同編集の成果物や公開したい資料。
- リスト：FAQ、手続き一覧、申請状況など。移行には設計が必要（列、ビュー、フォーム、ワークフローの依存関係）。
| 対象 | 移行の難易度 | PnPでの現実的な手段 | 注意点 |
|---|---|---|---|
| モダンページ | 中 | テンプレートに含める／ページ単位でエクスポート・適用 | 参照している画像/ファイルのパス、埋め込み、Webパーツ依存を確認 |
| ドキュメント | 低〜中 | ライブラリ構造を作り、スクリプトでコピー/移行 | 大容量は時間とスロットリング対策が必要 |
| リストデータ | 高 | 列・ビューはテンプレート化、データは段階移行（必要に応じて別手段） | ルックアップ/ユーザー列/添付/Power Automate 連携を事前に設計 |
大量サイトを捌くための運用イメージ：CSV＋スクリプトで“半自動化”する
「サイトが多すぎる」場合、1サイトずつの作業は避け、最初から“一覧（CSV）ドリブン”で回すのが鉄則です。
棚卸し（元サイト情報のCSV化）
最低限、次の列を用意すると後工程が安定します。
| 列名（例） | 用途 | 例 |
|---|---|---|
| SourceUrl | 元 Teams サイトURL | https://tenant.sharepoint.com/sites/proj-a |
| TargetUrl | 新コミュニケーションサイトURL | https://tenant.sharepoint.com/sites/proj-a-portal |
| Title | サイト名 | プロジェクトA ポータル |
| OwnerUPN | サイト所有者（管理用） | [email protected] |
| HubSiteId | ハブに紐付ける場合 | xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx |
CSVを読み込み、コミュニケーションサイトを一括作成する
New-PnPSite はコミュニケーションサイトを作成できます。
Connect-PnPOnline -Url "https://tenant-admin.sharepoint.com" -Interactive
$rows = Import-Csv ".\sites.csv"
foreach ($r in $rows) {
Write-Host "Creating:" $r.TargetUrl
New-PnPSite -Type CommunicationSite ` -Title $r.Title`
-Url $r.TargetUrl ` -Owner $r.OwnerUPN`
-Lcid 1041 `
-TimeZone "Tokyo"
# 必要ならサイトデザインIDで初期構成を統一（任意）
# New-PnPSite -Type CommunicationSite ... -SiteDesignId $r.SiteDesignId
}実務では、ここに「ログ出力」「エラー時のリトライ」「API制限（スロットリング）を見越した待機（Start-Sleep）」を組み込み、夜間バッチで回すと安定します。
URLを維持したい場合：サイトリネームで“URLを空ける”のが基本
「ユーザーが慣れているURLを残したい」「ブックマークを壊したくない」という要望は非常に多いです。ただし、ここで注意点があります。
- Invoke-SPOSiteSwap（サイトスワップ）は万能ではありません。このコマンドは、基本的にルートサイト（https://tenant.sharepoint.com）または検索センターを置き換える用途が中心です。
- さらに、サイトスワップはグループ接続サイト（Teamsサイト）を対象にできないといった制約も明記されています。
そのため、一般的な Teams サイトのURLを維持する場合は、次のような流れが現実的です。
一般サイトのURLを引き継ぐ手順（おすすめ）
- 既存 Teams サイトのURLを変更して、元のURLを空ける（例：
/sites/proj-a→/sites/proj-a-archive）。 - 必要なら、リダイレクト（旧URL→新URL）の扱いを設計する（残す/消す）。
- 空いたURLに新しいコミュニケーションサイトを作成する。
- コンテンツ移行後、必要なリンク（Teams タブ、ポータルリンク、社内リンク集）を更新する。
SharePoint の「サイトのアドレス変更」は処理中にサイトが読み取り専用になり、完了後は旧URLから新URLへのリダイレクトが作られる、といった影響があります。
PowerShellで実施する場合、SharePoint Online 管理用コマンドでサイトURLの変更を開始できます。
# SharePoint Online Management Shell 例（概念）
Connect-SPOService -Url "https://tenant-admin.sharepoint.com"
Start-SPOSiteRename ` -Identity "https://tenant.sharepoint.com/sites/proj-a"`
-NewSiteUrl "[https://tenant.sharepoint.com/sites/proj-a-archive](https://tenant.sharepoint.com/sites/proj-a-archive)" `
-NewSiteTitle "プロジェクトA（アーカイブ）"リダイレクトは運用上便利ですが、「どうしても同じURLを再利用したい」場合は、リダイレクト（リダイレクト用サイト）を管理・削除する作業が必要になります。管理については公式の案内があります。
ルートサイト置換だけは「サイトスワップ」が有効
一方で「テナントのルートサイト（https://tenant.sharepoint.com）を、コミュニケーションサイトに置き換えたい」というシナリオでは Invoke-SPOSiteSwap が選択肢になります。
ただし、前述の通り制約が多く、グループ接続（Teams）サイトは対象にできない、ハブ関連の扱い、Publishing 機能を有効化したことがあるサイトは不可など、事前チェックが必須です。
# ルートサイト置換の例（イメージ）
Invoke-SPOSiteSwap `
-SourceUrl "https://tenant.sharepoint.com/sites/NewRootCommunication" `
-TargetUrl "https://tenant.sharepoint.com" `
-ArchiveUrl "https://tenant.sharepoint.com/sites/RootArchive"移行でつまずきやすいポイント（実務メモ）
「サイトを作って移せば終わり」と思うと、最後に小さな不具合が積み上がります。特に大量サイトでは“同じ落とし穴”が繰り返し起きるため、先回りして潰しておくのが重要です。
| 落とし穴 | 起きること | 対策の考え方 |
|---|---|---|
| Teams タブ/リンク | Teams のタブが旧サイトURLを参照し続ける | 移行後にタブを張り替える運用を用意（最小限の手作業ポイントとして割り切る） |
| 権限の“そのまま移植” | 共同編集前提の権限が発信サイトに残り、改ざんリスクが上がる | コミュニケーションサイトは「編集者は少数」「閲覧は多数」に再設計する |
| ハードコードされた絶対URL | ページ内リンク・Webパーツが旧URLのまま | 移行前に“相対リンク化”を意識／移行後のリンク検査スクリプトを用意 |
| リダイレクトの扱い | 旧URLの再利用ができない／想定外の転送が残る | 「残す/消す」を要件化し、公式の管理手順に沿って運用する |
| プライベート/共有チャネルのサイト | 想定外の“別サイト”が混ざり棚卸しが崩れる | 棚卸し時にテンプレートや用途で除外ルールを決める |
そもそも全部をコミュニケーションサイトにするべき？判断基準を作ると失敗しにくい
ここが実務で一番効くポイントです。Teamsサイトをコミュニケーションサイトにしたくなる理由の多くは「情報発信の導線が弱い」ことですが、全部を置き換えると、逆に共同作業の速度が落ちることがあります。
おすすめは、サイトを次の3タイプに分類して“移行対象を絞る”ことです。
| タイプ | 向いているサイト種別 | 例 | 設計のコツ |
|---|---|---|---|
| 発信（全社/部門ポータル） | コミュニケーションサイト | 社内ニュース、規程、手続き、FAQ | 閲覧中心。編集者を絞り、ナビと検索導線を重視 |
| 共同作業（プロジェクト/チーム運用） | Teamsサイト（グループ接続） | 案件管理、議事録、作業フォルダ | メンバーが編集する前提。ファイル運用と権限設計を軽く |
| 中間（チーム内の“掲示板”） | Teamsサイト＋運用改善 or 小規模な発信サイト | チームのお知らせ、部内共有 | まずはページ整理とナビ設計で改善し、必要なら置換 |
「ナビを整えたい」「見せ方を揃えたい」だけなら、ハブサイトでの統一ナビやページテンプレート運用で解決できる場合もあります。置き換えは“最後の手段”として位置付けると、移行コストと運用のバランスが取りやすくなります。
よくある質問
Teams（チーム）と、新しいコミュニケーションサイトを再リンクできますか？
Teams は“チームに紐づく SharePoint サイト”を前提に動くため、コミュニケーションサイトに置き換えたあとも、Teams 側の標準ファイル領域をそのまま差し替える発想は取りにくいです。現実的には、Teams のタブとしてコミュニケーションサイトのページ/ライブラリを追加して導線を作る、という運用になります。
グループ接続を解除してコミュニケーションサイトにできませんか？
“解除してテンプレートを変える”という一発操作は公式には想定されていません。Teams/グループ連携が前提のサイトは、設計が強く結びついているため、無理に構造を変えると権限やナビ、連携周りで不整合が起きやすくなります。
Enable-PnPCommSite があるなら、強制的にいけるのでは？
Enable-PnPCommSite は、クラシック チームサイト向けに“コミュニケーションサイト体験を有効化”するコマンドです。Teams に接続されたモダンのグループ接続サイトに対する“Teamsサイト→コミュニケーションサイト変換”とは前提が違います。
まとめ：PnPでできることは「変換」ではなく「作成＋移行の自動化」
Teamsサイト（Microsoft 365 グループ接続のチームサイト）をコミュニケーションサイトへ直接変換する手段は、PnP PowerShell でも提供されていません。
一方で、PnP PowerShell はコミュニケーションサイトの一括作成、テンプレート（PnP Provisioning）での構造展開、移行のスクリプト化に強みがあります。
大量サイトの移行では「変換コマンド探し」に時間を使うより、CSVドリブンで“作成→構造→移行→URL引き継ぎ（必要に応じてリネーム）”を自動化する方が、結果として速く・安全に・再現性高く進められます。
コメント