Microsoft Teams で作ったTeamsサイト（SharePoint Online のチーム サイト）を、部門ポータルのようなコミュニケーション サイトに変えたい――よくある相談です。結論としては“テンプレートを変換して作り替える”機能は用意されていません。本記事では、なぜ変換できないのかと、失敗しにくい移行の進め方を具体例つきで整理します。
結論：Teams サイトをコミュニケーション サイトへ直接「変換」する方法はない
SharePoint Online のTeams サイト（Microsoft 365 グループに紐づくチーム サイト）を、後からコミュニケーション サイトへ“テンプレート変更”のように置き換える公式機能は提供されていません。現実的な解決策は、新しいコミュニケーション サイトを作成し、必要なコンテンツを移行（移し替え）することです。
まず整理：ここで言う「Teams サイト」「コミュニケーション サイト」とは
言葉が似ていて混乱しやすいので、前提をそろえます。
- Teams サイト：Microsoft Teams のチーム作成と同時に作られる SharePoint の「チーム サイト」。多くの場合、Microsoft 365 グループ（旧 Office 365 グループ）と連動し、メンバー＝共同編集者として設計されます。
- コミュニケーション サイト：社内ポータル、部門サイト、告知・お知らせの配信など、“少数が作って多数が読む”用途に向いたサイト。
Microsoft の解説でも、チーム サイトは「共同作業」、コミュニケーション サイトは「情報発信」の色が強い、と整理されています。
なぜワンクリックで“変換”できないのか
「見た目が違うだけなら、テンプレートを切り替えれば良いのでは？」と思いがちですが、両者は“思想”と“前提”が違います。特に Teams サイトは Microsoft 365 グループ／Teams 連携を前提にしているため、サイトの種類を置き換えると権限モデルや接続サービスの整合性が崩れやすく、簡単な変換機能が用意されていません。
| 観点 | Teams サイト（グループ接続のチーム サイト） | コミュニケーション サイト |
|---|---|---|
| 主目的 | 共同作業（ファイル共同編集、情報共有、タスク連携など） | 告知・ポータル（情報発信、見せる導線、部門横断の閲覧） |
| 権限の中心 | Microsoft 365 グループ（所有者・メンバー）中心 | SharePoint グループ中心（閲覧者を広く設計しやすい） |
| 関連サービス | Teams、Outlook グループ、Planner などと一体になりやすい | （既定では）グループ接続されず、単体サイトとして運用する前提 |
| ナビゲーション | 既定は左ナビ。設定で水平（上部）に切り替え可能なケースあり | 既定は上部ナビ。ハブやメガメニューと相性が良い |
| ページ レイアウト | 共同作業向けの要素が中心 | フル幅セクションなど、ビジュアル重視の作り込みに向く要素がある |
「サイト テンプレートを変えれば変換できる？」という誤解
SharePoint には「サイト テンプレートを適用（Apply a site template）」というメニューがあり、テンプレートを後から切り替えられるように見えます。しかし、ここで適用できるのは“ページやリストを追加してサイトを整えるためのテンプレート”で、チーム サイト⇔コミュニケーション サイトの“サイトの種類”そのものを入れ替える機能ではありません。
要するに、「サイト テンプレート」は同じサイト種類の中での“見た目や構成のスターター”であり、Teams サイトが持つグループ連携や権限構造を、コミュニケーション サイトの前提へ変換してくれるものではない、という理解が安全です。
移行に入る前に：よくある“変換したい理由”別の代替策
移行は手間がかかるため、まずは“本当にコミュニケーション サイトが必要か”を確認します。結論が同じでも、最短ルートは変わります。
左ナビが邪魔なので、上部ナビにしたい
SharePoint Online では、チーム サイトでもナビゲーションの向き（水平／垂直）を「外観の変更」から切り替えられる場合があります。これで「左ナビがスペースを取る」という不満は軽減できることがあります。
メガメニューで階層ナビを作りたい
大規模ポータルの導線でよく使うメガメニューは、コミュニケーション サイトやハブ サイトのナビゲーションで提供される形が一般的です。部門ポータルをハブにして、各プロジェクトの Teams サイトを紐付ける構成にすると、既存の Teams サイトを残しつつ、ポータル側で「探しやすいナビ」を実現できます。
トップページを“ポータルっぽく”作り込みたい（フル幅セクション等）
レイアウト要件が強い場合、コミュニケーション サイトに軍配が上がりやすいです。たとえばフル幅セクション（Full-width）はコミュニケーション サイトのページで利用でき、チーム サイトのページでは利用できない、と案内されています。
結局どっちが正解？判断の目安
| やりたいこと | おすすめ | 理由（実務目線） |
|---|---|---|
| 少人数で共同編集・共同作業が中心 | Teams サイトを継続 | Teams／グループ前提の権限と連携がそのまま使える |
| 部門・全社へ情報を配信したい | コミュニケーション サイトを新規作成 | 閲覧者を広く想定した設計（ナビ・見た目・公開運用）がしやすい |
| 共同作業も配信も両方やりたい | 住み分け（Teams＝作業、コミュニケーション＝公開） | “編集途中が全社に見える”事故を避けやすい。運用が安定する |
現実的な解決策：新しいコミュニケーション サイトを作り、移行する
ここからは「コミュニケーション サイトが必要」という前提で、移行を成功させるための現実的な流れをまとめます。ポイントは、“全部を丸ごと移す”のではなく、公開用に必要なものだけを選び直すことです。
全体像：おすすめの移行フロー
- 新しいコミュニケーション サイトを作成（テンプレート選定、URL・サイト名確定）
- 情報設計（トップページ、ナビ、カテゴリ、検索導線）
- コンテンツ移行（ファイル／ページ／リスト）
- 権限・共有設定の再設計（閲覧者をどう広げるか）
- 公開前チェック（リンク切れ、権限、検索、モバイル）
- 切り替え・周知（旧サイトとの役割分担も含める）
移行前に決めるべきこと（この段階が一番効きます）
移行が泥沼化しやすいのは「作りながら決める」ケースです。最低限、次の項目だけは先に決めておくと失敗しにくくなります。
| 決めること | 具体例 | 決めないと起きがちな問題 |
|---|---|---|
| サイトの目的 | 部門ポータル／全社向け告知／ナレッジ公開 | 共同編集コンテンツが混ざって情報が散らかる |
| 想定閲覧者 | 全社員、特定部門、ゲストの有無 | 権限の付け直しで手戻りが発生する |
| 公開するコンテンツ範囲 | 最新版だけ、年度別、保管庫は別サイト、など | 「全部移す」になり工数が膨らむ |
| ナビゲーション設計 | カテゴリ、FAQ、手続き、規程、フォーム導線 | ページだけ増えて“迷子サイト”になる |
| 旧Teamsサイトとの住み分け | 作業はTeams、公開はポータル、など | 利用者がどっちを見れば良いか分からない |
新しいコミュニケーション サイトの作成手順（実務目線）
作成自体は難しくありませんが、後戻りしやすいのがURL とサイト名です。検索結果やブックマーク、リンク共有に影響するので、命名規則（部署略称、年度、用途など）を先に決めてから作成します。
- SharePoint のホームから「サイトの作成」→「コミュニケーション サイト」を選択
- テンプレート（標準／ショーケース／空白など）を選択
- サイト名、説明、既定言語、サイトの URL を設定
- オーナー（運用担当）を設定し、初期メンバーを最小限にする
コンテンツ移行：ファイル（ドキュメント）の移し替え
Teams サイトで一番多い資産はドキュメントです。移行方法はいくつかあり、規模や“保持したい情報（履歴・メタデータ）”で最適解が変わります。
| 方法 | 向いているケース | 注意点 |
|---|---|---|
| SharePoint の「移動／コピー」 | 小〜中規模、すぐに移したい | 要件次第で保持されない情報が出る可能性があるため事前検証が必要 |
| OneDrive 同期＋エクスプローラーで移動 | ユーザーが少量を手早く | 大量データだと同期トラブルが起きやすい。権限・メタデータが要件に合うか要確認 |
| 移行ツール（例：サードパーティ） | 大量データ、監査・履歴の保持が重要 | ライセンス費用、設計と検証が必要 |
| スクリプト（PowerShell / PnP 等） | 繰り返し移行、整形しながら移す | 開発・運用スキルが必要。失敗時のリカバリ計画も必須 |
実務では、まず「公開ポータルに載せる資料」を棚卸しし、“最新版だけ”など移行範囲を絞ると成功率が上がります。Teams 上の共同作業で頻繁に更新されるファイルまで全部移そうとすると、移行中に内容が変わり“どれが正”か分からなくなりがちです。
コンテンツ移行：ページ（Site Pages）の扱い
Teams サイトのページをそのまま使い回したい場合でも、コミュニケーション サイトではホームの構成や導線の考え方が変わります。ページは「サイト ページ」ライブラリ上のファイルとして移動できることもありますが、ページ内の Web パーツが参照しているリスト／画像／リンク先が変わると表示が崩れることがあるため、主要ページは作り直し（または移した後に手直し）を前提にすると安全です。
- トップページ：新サイトで作り直し推奨（目的・導線が変わるため）
- 規程や手順：内容が固定ならページ移行→リンク・参照先だけ調整、が現実的
- よくある質問：リスト化（Q&A リスト）して検索性を上げるのも有効
コンテンツ移行：リスト／ライブラリ（構造ごと移すか、作り直すか）
リストやライブラリは「列」「ビュー」「権限継承」「Power Automate／Power Apps 連携」などが絡みます。公開用ポータルとしては、リストをそのまま移すより、要件に合わせて作り直してからデータを移すほうが結果的に運用が楽になることが多いです。
特に、次のどれかに当てはまる場合は“作り直し”を前提にしておくと手戻りが減ります。
- 列が増えすぎて入力が破綻している（メタデータ整理が必要）
- ビューが乱立し、どれを使うべきか分からない
- Power Automate のフローが複数紐づいている
- 承認や申請など、業務プロセスと密結合している
権限・共有設定の再設計（ここを雑にすると炎上します）
Teams サイトは「メンバー＝編集できる人」という前提で作られやすい一方、コミュニケーション サイトは「閲覧者が圧倒的に多い」前提です。権限設計を切り替えることで、情報漏えいリスクと運用負荷が大きく変わります。
| 役割 | おすすめの権限 | ポイント |
|---|---|---|
| オーナー（運用担当） | フル コントロール | 人数は絞る。変更管理（誰がいつ何を変えたか）を回せる体制に |
| 編集者（記事作成者） | 編集 | 投稿・更新の責任範囲を明確に。承認フローが必要なら別途検討 |
| 閲覧者（一般社員） | 閲覧 | “広く読ませる”ほど、メタデータとナビ設計が重要になる |
| 限定公開（特定部署のみ閲覧） | 閲覧（対象グループのみ） | Entra ID（Azure AD）セキュリティ グループで管理すると運用が楽 |
コミュニケーション サイトは既定で Microsoft 365 グループに接続されず、コミュニケーション サイトをグループ接続することはサポートされない、と説明されています。Teams のメンバー管理と完全一致させたい場合は、グループ（または Entra ID グループ）を SharePoint の権限グループに追加して近づける、という設計になります。
補足：Teams サイトで“閲覧だけ”を増やしたい場合の注意
Teams サイト側で閲覧者を増やすときに、誤って Microsoft 365 グループのメンバーに追加すると、Teams の範囲（チャットや予定表など）まで広がる可能性があります。SharePoint 側の共有操作では「サイトのみ共有」といった選択肢が案内されることがあり、意図せずグループ加入させない設計が重要です。
ナビゲーション／リンク／Web パーツの調整
移行が終わっても、利用者にとっては「どこから何に辿れるか」が全てです。ポータル運用では、次の3点をセットで整えると定着しやすくなります。
- グローバル導線：ハブ サイトのナビ（必要ならメガメニュー）で全体を束ねる
- カテゴリ導線：トップページに「よく使う手続き」「最新のお知らせ」「人気ページ」などを配置
- 検索導線：ページとドキュメントにメタデータを付け、絞り込みできる状態を作る
公開前チェック（短時間でもいいので必ずやる）
移行の失敗原因は「データが移せない」より「公開したのに使われない／見えない」が多いです。公開直前に、次の観点だけはチェックしておくと事故が減ります。
| チェック観点 | 見方 | よくある不具合 |
|---|---|---|
| リンク切れ | トップページと主要カテゴリをクリックで総点検 | 旧TeamsサイトのURLが残っている |
| 権限 | 閲覧者ロールでログインし、見える範囲を確認 | 一部のライブラリだけアクセス拒否になる |
| 検索 | 代表キーワードで検索し、結果の出方を見る | 新サイトのコンテンツが検索に出ない（反映待ち） |
| モバイル | スマホでトップと主要ページを表示 | 画像やWebパーツが崩れて読めない |
| 更新導線 | 編集者が迷わず更新できるか | “どのページを更新すべきか”が運用者でも不明 |
移行スケジュール例（小さく試してから本番へ）
「いきなり全社公開」ではなく、まずは小さく作って試すと失敗しにくくなります。以下は一例です（規模や承認フローの有無で前後します）。
| 期間 | やること | 成果物 |
|---|---|---|
| 1週目 | 要件整理／情報設計（ナビ、カテゴリ、トップ構成） | サイト構成案、移行対象リスト |
| 2週目 | コミュニケーション サイト作成／トップページ制作 | 公開前サイト（レビュー可能） |
| 3週目 | ドキュメント・ページ移行（先に“公開したいもの”だけ） | 主要コンテンツ移行、リンク修正 |
| 4週目 | 権限確定／代表ユーザー検証／周知文面作成 | 公開手順、FAQ、問い合わせ窓口 |
URL を引き継ぎたい場合の現実的な考え方
「既に社内で共有されているURLを変えたくない」という要望は多いです。この場合は、旧TeamsサイトのURLを変更して“場所を空ける”→同じURLで新しいコミュニケーション サイトを作るという考え方が使われます。ただし、サイトURLの変更後にはリダイレクトが残るため、同じURLを再利用するには管理者側の対応が必要になることがあります。テスト環境で一連の動作（リダイレクト、リンク、検索、Teams タブ）を必ず確認してください。
切り替え（公開）のすすめ方：トラブルを減らす段取り
- 新サイトを“非公開”で構築し、運用担当者だけでレビューできる状態にする
- 移行対象のドキュメント／ページ／リストを移し、リンク切れをチェックする
- 権限を最終形にし、閲覧者の代表（数名）で“見える／見えない”を確認する
- 公開日を決め、旧サイトに「移行しました」案内ページを用意する（混乱防止）
- 公開後1〜2週間は“問い合わせ窓口”を用意し、導線の改善を素早く回す
よくある落とし穴と対処
- Teams の「ファイル」タブが指している場所が変わって混乱
Teams のチャネルにアップロードしたファイルは、チームに紐づく SharePoint フォルダー（ドキュメント ライブラリ）に保存される、と案内されています。共同作業はTeamsサイト、公開はコミュニケーションサイト、と役割分担を明文化し、Teams に“ポータルへのリンク タブ”を追加する運用が現実的です。 - 権限を広げたつもりが、実はグループにメンバー追加してしまった
Teams サイトで「全社に見せたい」場合、誤って Microsoft 365 グループに追加すると、Teams の範囲（チャットや予定表など）まで広がる可能性があります。公開はコミュニケーション サイト側で行うほうが安全です。 - “移したら終わり”で、検索性が悪く使われない
ポータルは導線と検索性が命です。ページのタイトル、説明、ファイルのメタデータ（カテゴリ、年度、文書種別など）まで設計して初めて「使えるサイト」になります。 - ナビが増えすぎて迷子になる
階層を深くするより、トップに“目的別の入口（手続き、規程、FAQ、申請）”を置き、詳細は検索・絞り込みで探せる構造が長期運用に向きます。
おすすめの住み分け：Teams は作業場、コミュニケーション サイトは社内ポータル
Teams サイトを「変換」したくなる背景には、“作業場”と“社内向けの発信”が1つに混ざってしまった問題があることが多いです。次のように役割を分けると、運用が安定します。
| 役割 | 使う場所 | 載せるもの |
|---|---|---|
| 共同作業 | Teams ＋ Teams サイト | ドラフト資料、共同編集中のファイル、タスク、議事メモ |
| 正式公開 | コミュニケーション サイト | 確定版資料、手順、規程、FAQ、全社向けお知らせ |
| 全体導線 | ハブ サイト | 部門横断ナビ、ニュース集約、検索導線 |
移行後に効く“運用ルール”の例（小さく決めて大きく育てる）
コミュニケーション サイトは作って終わりではなく、運用で価値が決まります。最初から完璧を目指すより、まずは次のような“最低限のルール”を決めて、運用しながら改善するのがおすすめです。
- ページの持ち主（オーナー）：ページごとに「最終責任者」を決め、更新依頼の窓口を明確にする
- お知らせの粒度：全社／部門／チーム内のどれに当たるかで投稿先を分ける
- 文書の版管理：確定版は“公開用ライブラリ”に置き、編集途中は Teams サイトに置く
- 期限付き情報：期限切れを放置しないために、期限日やアーカイブ方針を決める
- 新規追加のルール：ページやライブラリを増やすときの命名規則を決め、乱立を防ぐ
「変換機能が欲しい」場合のフィードバック先
現時点で直接変換ができない以上、要望としてはMicrosoft のフィードバック窓口に届けるのが近道です。OneDrive／SharePoint のアイデアは Microsoft Feedback Portal で投稿・投票でき、アプリ内の「フィードバック」から送る導線も用意されています。
要望を書くときは、単に「変換したい」だけでなく、次のように業務インパクトまでセットで書くと伝わりやすくなります。
- なぜコミュニケーション サイトが必要か（ポータル化、閲覧者が多い、承認が必要、など）
- 現状の困りごと（ナビ、権限、ページ レイアウト、運用負荷）
- 変換できると削減できる工数（移行に何日、何人必要か）
- 安全面の要件（Teams の権限と混ぜたくない、など）
“変換できない”こと自体は変えられませんが、新しいコミュニケーション サイトを中心に据え、Teams サイトは共同作業用に残す構成にすると、移行の手戻りが少なく、利用者の混乱も抑えられます。まずは小さく作り、利用実績を見ながら段階的にポータルへ寄せていくのが、現場で成功しやすい進め方です。
コメント