Microsoft 365の「Microsoft 365 app: Microsoft Loop – Require Existing Microsoft 365 Group for New Loop workspaces」は、Loopの新しい共有ワークスペースを、既存のTeams対応Microsoft 365グループに接続して管理できるようにする変更です。結論から言うと、これは単なるLoopの画面変更ではなく、ワークスペースの所有者管理、ライフサイクル、アクセス制御をMicrosoft 365グループ中心に寄せるためのガバナンス強化です。Microsoft 365 Roadmap ID 422725では、対象はMicrosoft 365 app、プラットフォームはWeb、一般提供は2026年4月、状態はLaunchedとして示されています。(Microsoft)
特に確認すべきなのは、「誰でもLoopアプリから自由に共有ワークスペースを作れる状態を続けるのか」「TeamsやMicrosoft 365グループの管理ルールに沿って作らせるのか」という運用方針です。既存のLoopコンテンツをすぐに止める変更ではありませんが、新規作成ルール、Teams標準チャネルの使い方、Cloud Policy、SharePoint Embeddedコンテナー管理を事前に見直しておかないと、ユーザーの作成手順や管理者の棚卸し作業で混乱が起きやすくなります。(Microsoft Learn)
Microsoft Loopの新しいワークスペース制御で何が変わるのか
今回の変更の中心は、新しい共有Loopワークスペースを既存のTeams対応Microsoft 365グループに接続し、そのグループで管理できるようにする点です。Microsoft 365グループ所有のLoopワークスペースでは、アクセス権やライフサイクル管理がグループにひも付き、SharePointチームサイトに近い考え方で管理できます。(Microsoft)
従来、Loopアプリ内で作成された共有ワークスペースは、ワークスペース所有者がLoopアプリ内でメンバーや所有者を管理する「テナント所有」の形で扱われます。所有者が全員退職すると、ワークスペースは所有者なしのままテナントに残り、自動削除されません。管理者が後から所有者を割り当てる必要があります。(Microsoft Learn)
一方、Microsoft 365グループ所有のLoopワークスペースは、Teamsチャネル内で作成され、Microsoft 365グループによってアクセス制御されます。ユーザーの入退場やチーム所有者の変更に合わせて権限が動くため、部門、プロジェクト、委員会のようにメンバー変更がある共同作業では管理しやすくなります。(Microsoft Learn)
| 観点 | テナント所有の共有Loopワークスペース | Microsoft 365グループ所有のLoopワークスペース |
|---|---|---|
| 主な作成場所 | Loopアプリ | Teams標準チャネル |
| メンバー管理 | Loopワークスペース内で管理 | Microsoft 365グループ、Teamsメンバーシップで管理 |
| 所有者退職時 | 所有者なしで残る可能性がある | グループ所有者・メンバー管理に連動しやすい |
| 向いている用途 | 少人数の一時的な共同編集 | 部門、チーム、長期プロジェクト |
| 注意点 | 棚卸しと所有者管理が必要 | 事前に適切なTeams・グループ設計が必要 |
影響を受けるユーザーと組織
影響が大きいのは、Loopを個人や小規模チームの自由な作業場所として使わせている組織よりも、情報管理、監査、退職者対応、外部共有制御を重視する組織です。LoopワークスペースはSharePoint Embeddedに保存され、ストレージは組織のSharePointクォータにカウントされます。Microsoft 365グループ所有のワークスペースは、グループが権限とライフサイクルを管理します。(Microsoft Learn)
管理者は、Loopアプリだけでなく、Teams、SharePoint、Microsoft Purview、Microsoft 365グループの運用ルールも合わせて確認する必要があります。Loopの管理はCloud Policyだけでは完結せず、TeamsのLoopコンポーネントや会議ノートを制御するにはSharePoint PowerShell側の設定も関係します。(Microsoft Learn)
開発者や業務アプリ担当者は、Loopワークスペースを前提にした業務手順、社内ポータルの案内、オンボーディング資料を見直す必要があります。たとえば「Loopアプリで新しいワークスペースを作成してください」と案内していた業務フローは、「該当するTeams標準チャネルにLoopワークスペースを追加する」手順へ変更した方が、今後のガバナンス方針と整合しやすくなります。Teamsチャネル内のLoopワークスペースは、現時点ではTeams標準チャネルで利用できます。(Microsoft サポート)
管理者が確認すべき設定
まず確認すべきは、Loopワークスペース作成に関するCloud Policyです。Microsoft Learnでは、Loopワークスペースの制御に「LoopでLoopワークスペースを作成する」、Loopコンポーネントの制御に「LoopをサポートするMicrosoftアプリでLoopファイルを作成して表示する」、Outlook向けの詳細制御に「OutlookでLoopファイルを作成して表示する」が示されています。(Microsoft Learn)
| 確認項目 | 見る場所・設定 | 実務上のポイント |
|---|---|---|
| Loopワークスペース作成 | Cloud Policy「LoopでLoopワークスペースを作成する」 | 新規ワークスペース作成の可否に関係する |
| テナント全体の簡易設定 | Microsoft 365管理センター > 組織の設定 > サービス > Loop | 全ユーザー向けの大まかな有効・無効確認に使う |
| Teams内のLoop体験 | SharePoint PowerShell Set-SPOTenant -IsLoopEnabled | TeamsチャットやチャネルのLoopコンポーネント制御に関係する |
| Teams会議ノート | SharePoint PowerShell Set-SPOTenant -IsCollabMeetingNotesFluidEnabled | 共同会議ノートの制御に関係する |
| ポリシー適用範囲 | Microsoft 365グループ、セキュリティグループ、動的グループ | 全社展開前に一部ユーザーで検証しやすい |
| 外部共有・秘密度 | Microsoft Purview、秘密度ラベル、SharePoint共有設定 | ワークスペース単位の外部共有ルールと整合させる |
Cloud Policyは、Microsoft 365 Apps admin centerのPolicy Managementから構成できます。ポリシーは全ユーザーまたは特定グループに適用でき、複数ポリシーが同じユーザーに当たる場合は優先度も確認が必要です。変更反映には、既存ポリシーがある場合で最大90分、初回構成では最大24時間かかる可能性があります。(Microsoft Learn)
ここで注意したいのは、「Loopワークスペース」と「Loopコンポーネント」は同じではないという点です。Outlook、OneNote、Whiteboard、Teamsの一部で使うLoopコンポーネントを制御する設定と、LoopアプリやTeamsチャネルのワークスペース作成を制御する設定は分かれています。ワークスペース作成を制限しても、既存のLoopファイルやワークスペースへのアクセスまで自動的に止まるわけではありません。既存コンテンツへのアクセス制御には、条件付きアクセスや情報バリアなど別の設計が必要です。(Microsoft Learn)
Teams対応Microsoft 365グループを使うメリット
Teams対応Microsoft 365グループにLoopワークスペースを接続する最大のメリットは、メンバー管理を二重化しにくくなることです。Teamsチャネル内のLoopワークスペースでは、ワークスペースのメンバーはTeamsチャネルのメンバーと同じになり、新しいメンバーがチームに追加されるとワークスペースにもアクセスできます。チーム所有者はワークスペース所有者になり、Purview Information Protectionのラベルもチームから継承されます。(Microsoft サポート)
たとえば、営業部の提案書ドラフト、開発チームのスプリント計画、人事部のオンボーディング改善案など、チーム単位で継続的に編集する情報は、Loopアプリ内で個別にメンバー招待するより、TeamsチャネルにLoopワークスペースを追加した方が管理しやすくなります。メンバー変更のたびにLoop側でも手作業で追加・削除する運用は、退職者や異動者のアクセス残りにつながりやすいためです。(Microsoft サポート)
一方で、すべてをグループ所有に寄せればよいわけではありません。短期の下書き、数人だけの検討、まだチーム化するほどではないアイデア出しでは、グループ作成やTeamsチャネル整備の手間が増える場合があります。重要なのは、Loopの自由度を完全に捨てることではなく、情報の重要度や継続期間に応じて「グループ必須にする範囲」を決めることです。
有効化を検討すべき組織、慎重に進めるべき組織
このポリシーは、全社一律で即時適用するより、管理要件の強い部門から段階的に検証するのが現実的です。Microsoft 365 Roadmapの情報は推定リリース日を含み、内容は変更される可能性があるため、実際のテナントで表示されるポリシー名、対象範囲、Message centerの通知も併せて確認してください。(Microsoft)
| 判断軸 | 有効化を優先しやすいケース | 慎重に検証したいケース |
|---|---|---|
| コンプライアンス | 監査、退職者対応、情報分類が厳しい | 個人主導の試行利用が多い |
| Teams運用 | チーム・チャネル設計が整理されている | Teamsの命名や所有者管理が未整備 |
| 情報の寿命 | 長期プロジェクトや部門ナレッジが多い | 短期メモや一時的な共同編集が多い |
| 管理負荷 | 所有者なしワークスペースを減らしたい | グループ作成依頼が増えると困る |
| ユーザー教育 | Teams中心の作業に移行済み | Loopアプリ単体利用が定着している |
特に、既にLoopを広く展開している組織では、ユーザーがどの場所でLoopを使っているかを分けて把握する必要があります。Loopアプリの共有ワークスペース、Teamsチャネルのワークスペース、Teamsチャット内のLoopコンポーネント、Outlookメール内のLoopコンポーネントでは、保存場所や確認すべきポリシーが異なります。(Microsoft Learn)
移行・棚卸しで注意すべきポイント
今回のRoadmap項目は「新しい共有Loopワークスペース」を対象にした説明です。そのため、既存のテナント所有ワークスペースが自動的にMicrosoft 365グループ所有へ変換される、とまでは読み取れません。既存ワークスペースについては、所有者、メンバー、外部共有、保管場所を棚卸しし、必要に応じてTeamsチャネル側に作り直すか、既存のまま管理者が所有者を補完するかを判断します。(Microsoft)
所有者なしのLoopワークスペースは、SharePoint管理センターやPowerShellで確認できます。Microsoft Learnでは、Loop WebアプリケーションIDとして a187e399-0c36-4b98-8f04-1edc167a0996 が示されており、Get-SPOContainer を使って所有者なしコンテナーやユーザー所有コンテナーを抽出する例が掲載されています。(Microsoft Learn)
Get-SPOContainer -OwningApplicationId 'a187e399-0c36-4b98-8f04-1edc167a0996' | WHERE {$_.Owners.Count -eq 0} | FT既存のSharePoint EmbeddedコンテナーをMicrosoft 365テナント間で転送する方法は、現時点ではサポートされていません。合併、分社、テナント統合を予定している場合は、Loopワークスペースを後から簡単に移せる前提で設計しない方が安全です。(Microsoft Learn)
展開前に行うべき実務チェックリスト
展開前は、ポリシーを有効化すること自体よりも、「有効化した後にユーザーがどこで作ればよいか」を明確にすることが重要です。Teams標準チャネルのLoopワークスペースは、チームのメンバー変更に合わせてアクセスを維持しやすく、グループのガバナンス、ライフサイクル、コンプライアンス標準に沿いやすい作成方法です。(Microsoft サポート)
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 現状把握 | Loopワークスペースと所有者なしコンテナーを棚卸し | 退職者所有、外部共有、放置ワークスペースを確認 |
| グループ設計 | Teams対応Microsoft 365グループを整理 | 命名規則、所有者2名以上、秘密度ラベルを確認 |
| ポリシー検証 | 一部ユーザー・部門でCloud Policyを適用 | Loopアプリ、Teamsチャネル、Outlookで挙動を確認 |
| 手順書更新 | Loop作成手順をTeams標準チャネル中心に変更 | ユーザーが迷わない画面単位の手順にする |
| 問い合わせ準備 | 作成できない、共有できない場合のFAQを用意 | ライセンス、ポリシー、チャネル種別、権限を切り分ける |
| 本番展開 | 部門単位で段階展開 | 反映時間、既存ワークスペース影響、例外申請を確認 |
よくある失敗は、管理者側でポリシーだけを変更し、ユーザーへの作成手順を変えないことです。ユーザーから見ると「新しいLoopワークスペースが作れない」「どのチームを選べばよいか分からない」という体験になります。業務部門ごとに、既存Teamsを使うのか、新しいTeamsを申請するのか、どのチャネルにLoopタブを追加するのかを先に決めておく必要があります。
開発者・業務アプリ担当者が見直すべき点
開発者や業務アプリ担当者は、Loopを直接操作するコード変更よりも、業務プロセスと権限前提の見直しを優先すべきです。Loopワークスペースの作成場所がTeams対応Microsoft 365グループ側に寄ると、アクセス権は個別招待ではなくグループメンバーシップに依存しやすくなります。Teamsチャネルワークスペースでは、ワークスペース招待やワークスペースリンクは利用できず、メンバーシップはTeamsチャネルと同期されます。(Microsoft サポート)
社内アプリ、Power Automate、SharePointページ、研修資料などで「Loopアプリでワークスペースを作る」と案内している場合は、対象業務の性質に応じて文言を変えましょう。長期運用するチーム作業なら「対象のTeams標準チャネルにLoopワークスペースを追加する」、一時的なメモなら「LoopコンポーネントをTeamsチャットやOutlookで使う」など、作成場所を分けて案内すると混乱を減らせます。(Microsoft Learn)
また、外部共有を含む業務では、Microsoft 365グループ、SharePoint共有設定、秘密度ラベル、条件付きアクセスの整合性を確認してください。Loopワークスペースの外部共有には組織レベルの外部共有、ゲストアカウント、秘密度ラベルや条件付きアクセスが関係します。SharePointサイトとは異なり、特定のLoopワークスペースだけに対するゲスト共有を管理する専用の管理者設定はありません。(Microsoft Learn)
既存ワークスペースをどう扱うべきか
既存のLoopワークスペースは、まず「残す」「移す」「削除候補にする」の3つに分類します。業務で使われており、所有者とメンバーが明確で、情報分類にも問題がないものは当面残せます。部門やプロジェクトの恒久的な作業場所になっているものは、Teams標準チャネルにLoopワークスペースを作り直し、旧ワークスペースを参照専用に近い扱いへ移行する運用が現実的です。
削除候補にすべきなのは、所有者不在、最終更新が古い、退職者だけが所有者、外部共有の意図が不明、といったワークスペースです。テナント所有の共有Loopワークスペースは、所有者が全員退職しても自動削除されないため、放置すると管理負債になります。(Microsoft Learn)
ただし、移行時に無理な一括削除は避けるべきです。Loopは共同編集の文脈で使われるため、ページ内に会議メモ、タスク、未完了の検討事項が残っている場合があります。削除前に所有者確認、最終更新、外部共有、業務上の必要性を確認し、必要ならTeamsチャネル側へ内容を移してから整理します。
まとめ：次に取るべき行動
Microsoft 365の「Microsoft Loop – Require Existing Microsoft 365 Group for New Loop workspaces」は、Loopをより管理しやすい共同作業基盤にするための重要な変更です。ポイントは、新しい共有LoopワークスペースをTeams対応Microsoft 365グループに接続し、メンバー管理、ライフサイクル、コンプライアンスをグループ中心にそろえることです。(Microsoft)
管理者はまず、Roadmap ID 422725の状態、Cloud Policy、Microsoft 365管理センターのLoop設定、Teams関連のSharePoint PowerShell設定を確認してください。そのうえで、既存ワークスペースの棚卸し、Teams標準チャネルでの作成手順、秘密度ラベルと外部共有ルール、ユーザー向け案内を整備します。(Microsoft Learn)
最初の一歩としては、全社適用ではなく、情報管理の要件が高い部門や既にTeams運用が成熟している部門でパイロットを行うのが安全です。Loopの利便性を保ちながら、所有者不在やアクセス権の属人化を減らすことが、この変更を活かすための実務上のゴールです。
コメント