Teams スプロール：Microsoft Teams の増殖を管理する

Teams スプロールは、Microsoft 365 環境で最も見落とされがちなセキュリティ リスクの一つです。すべての従業員が、承認なしで、命名規則や期限ポリシーなしに、必要なときにチームを作成できてしまうと、その結果として、明確な所有者のない統制されていないワークスペースが数百も生まれ、命名が一貫せず、データも散在してしまいます。

このガバナンスの欠落は、測定可能なリスクを生み出します。Netwrix 2025 Cybersecurity Trends Reportでは、業務ユーザーによるミスや不注意が、3年連続でトップ3のセキュリティ課題に入っていることがわかりました。

Teams スプロールは、そのリスクがどのように表面化するかを示す教科書的な例です。つまり、善意の協力（コラボレーション）判断であっても、ガードレールがないと、組織全体にわたってセキュリティとコンプライアンス上のリスク（露出）を生み出してしまいます。

Microsoft Teams スプロールとは何ですか。また、なぜ起こるのでしょうか？

Microsoft Teams の sprawl（スプレッド）とは、Microsoft 365 環境全体においてチーム、チャネル、コンテンツが制御されないまま増殖していく状態のことです。単にチームが多すぎるという話を超えています。組織の「所有権の追跡」「アクセス制御の徹底」「各ワークスペース内のデータの棚卸し（インベントリ）」を行う能力を、チーム作成のスピードが上回ってしまったときに起こります。

問題が急速に悪化するのは、Teams が単独で存在しているわけではないからです。すべてのチームは、基盤となる Microsoft 365 Group を作成し、さらに関連する SharePoint site 、共有メールボックス、OneNote ノートブックも作成します。この増殖は、単なるデジタル上の散らかりではなく、実際のセキュリティおよびコンプライアンス上のリスク（暴露）につながります。

では、なぜ起こるのでしょうか。Microsoft 365 ではデフォルトで Teams の作成が有効になっており、プラットフォームには承認ワークフローもなく、命名要件もなく、期限ポリシーもありません。そこから、次の4つの要因がスプレッドを環境の奥深くまで広げていきます：

• 許容的なデフォルト設定が土台を作ります：Microsoft 365 Groups の作成は、初期状態（out of the box）で、すべてのユーザーに対して有効になっています。ネイティブの承認メカニズムはなく、命名ポリシーの強制もなく、自動のライフサイクル管理もありません。自分で設定しない限り、そうした仕組みは用意されていません。
• パンデミックがすべてを加速させました： 2020 年に組織が急いでリモートワークを有効化した際、IT チームは「Teams を動かすこと」を優先し、「Teams を統制（ガバナンス）すること」は後回しにしました。2020〜2021 年に生まれたこのレガシーなスプレッドは、いまも放置されていることがよくあります。
• 技術的な専門知識の要件が障壁を生みます： Teams 管理センターではチームの作成を制限できません。このガバナンス制御は Microsoft Entra ID PowerShell および Entra 管理センターにあります。PowerShell の専門知識がない組織は、スクリプト作成の知識を必要とせずに、テンプレートベースの自動化を提供するサードパーティのガバナンス プラットフォームを利用できます。
• 可視性の不足が問題をさらに深刻化させます： ネイティブの利用レポートでは、過去 28 日間の限られたアクティビティ データしか表示されません。非アクティブ、または放置されたチームに関するネイティブ レポートはありません。見えていないものは直せず、Microsoft のネイティブ ツールでは大きな可視性のギャップが残ります。

これらの根本原因は、単に運用上の手間を増やすだけではありません。スパック（sprawl）が放置される時間が長くなるほど、セキュリティ、コンプライアンス、そして財務面での具体的なリスクはさらに悪化していきます。

組織に Teams の sprawl（チームの過剰増殖）問題があるサイン

以下のいずれかに心当たりがある場合、sprawl はすでに定着している可能性があります：

• アクティブなオーナーがいないチーム： オーナーがいないチーム、またはオーナーが5人以上のチームでは、説明責任が薄まり、実際の中身について誰も責任を負っていない状態になり得ます。
• 90日以上活動がない： 完了したプロジェクトに対するアーカイブ戦略がなく、そのまま放置されているチームは、ライフサイクル ポリシーの欠落を示します。非アクティブなチームであっても、権限とデータは引き続き保持されています。
• 制御されていないゲストアクセス： 2025年11月の Teams の更新（MC1182004）により、ユーザーは既定で任意のメールアドレスからチャットを開始できるようになりました。最近ゲストアクセス ポリシーを監査していない場合、外部ユーザーは想定よりも多くのアクセス権を持っている可能性があります。
• 重複していて一貫性のない命名： 類似した名前の複数チーム、「Project」や「Test」などの汎用ラベル、また説明に文脈がないチームはいずれも、命名基準の欠落を示しています。
• 有効期限ポリシーが設定されていない： 使用状況にかかわらずチームが無期限に存続する場合、完了したプロジェクトのチームはすべてアクティブなままでアクセス可能になります。結果として攻撃対象領域が広がり、コンプライアンス監査も複雑になります。
• 制限のないチーム作成: Microsoft Entra ID で作成制限を構成していない場合、すべてのユーザーが監督なしで新しいチームを作成できます。これは既定の Microsoft 365 設定であり、ほとんどの組織はこれを変更しません。

Teams のスパrawl（増殖）がもたらすビジネスおよびセキュリティ上のリスク

統制されていない Teams 環境は、セキュリティ露出、コンプライアンス違反、運用コストの各面でリスクを生みます。これらはそれぞれが互いを悪化させ、結果として「スパrawl」は IT の単なるメンテナンス作業ではなく、セキュリティ上の課題として扱うべきだと言える根拠になります。

1. セキュリティ露出

最も差し迫ったリスクは、不正なアクセスです。監督なしにチームが増殖していくと、メンバーシップ管理が破綻します。退職者はアクセス権を保持したままになり、ゲスト ユーザーはいつまでも残り、権限の割り当ては対応する削除なしに蓄積されます。その結果、access control 管理されていないチームが増えるたびに悪化していく privilege creep につながります。

そのアクセス上の問題は、データの可視性に関する問題へとつながります。PHI、PII、Controlled Unclassified Information (CUI)、および財務記録が管理されていないチーム全体に分散し、集中型インベントリ（棚卸し）を行うことができなくなります。

ネイティブの Microsoft ツールでは、特定のチームの中に何があるかを確認できますが、何百もの増殖したチームや、それらに関連する SharePoint サイトにまたがって機密データを見つけるために必要な audit trails は提供されません。

一方で、ガバナンスのないチーム作成は、管理されるべきプラットフォームの中で実質的にシャドー IT を生み出します。従業員が悪意を持って行っているわけではありませんが、誰でも IT の監督なしにワークスペースを立ち上げてデータを保存できる状況では、この種のリスクに備えて導入された統制を回避してしまうことになります。

2. コンプライアンス違反

Teams sprawl（チームの無秩序な増殖）は、複数の規制フレームワークにまたがるリスクにさらされます:

• HIPAA: PHI（保護対象の医療情報）が監視されていないチームに紛れ込むと、組織は保護対象の医療情報に対する最小権限（least-privilege）アクセスを強制する能力を失います。侵害が起きた場合、60日以内の通知要件は「PHIがどこに存在するか特定できる」ことを前提としていますが、数百ものガバナンスされていないチームにまたがると、その前提が成り立ちません。
• SOC 2: 監査人は、アクセス制御が環境全体で一貫して適用されていることを示す証拠を求めます。Teams sprawl は、監査人がまさに探している種類の不整合を生み出します。管理されていないメンバーシップを持つワークスペース、オーナーシップに対する説明責任の欠如、そして「誰が何にアクセスしたか」を示す監査証跡がない状態です。
• CMMC 2.0: 防衛関連の請負業者にとって、sprawl（無秩序な拡大）は、評価者（assessors）が評価するアクセス制御の実践を損ないます。もし Teams 環境で Controlled Unclassified Information（統制対象の非機密情報）への制御されたアクセスを示せない場合、そのギャップが契約の適格性にコストとして跳ね返る可能性があります。
• GDPR: チームが増えすぎると、必要以上に個人データが保持されます。個人のデータが存在するすべての実例を見つけられない場合、「right to be forgotten（忘れられる権利）」の実現は実質的に不可能になります。

eDiscovery はこれらのコンプライアンスリスクをさらに深刻にします。Microsoft Teams は Microsoft Purview を通じて eDiscovery をサポートしていますが、スプロール（拡散）があると運用上現実的ではなくなります。

管理されていないチームが数百あると、コンテンツ検索は指数関数的に難しくなり、法的ホールド（legal hold）の対象となるワークスペースの特定はほぼ不可能になります。また、コミュニケーションのコンプライアンス監視もスケールできません。

3. 運用面および財務面のコスト

セキュリティやコンプライアンスのリスクは特に大きく注目されますが、スプロール（拡散）はITリソースに対する継続的な負担も生みます。管理されていないすべてのチームは、いずれ誰かが triage（優先順位付けして対処）しなければならないワークスペースです：

• 所有者の特定
• 機密データが含まれているかどうかを評価する
• アーカイブするか削除するかを判断する

ほとんどの組織では、このトリアージが事前に積極的に行われないため、コンプライアンス監査やセキュリティインシデントによって事態が強制的に表面化するまで問題が積み上がります。その時点では、クリーンアップは日常的なプロセスではなく緊急対応になります。

ストレージコストは裏側で増え続けます。すべてのチームが関連する SharePoint サイトを生成し、期限切れや保管（リテンション）ポリシーが設定されていない限り、非アクティブなチームはファイル、チャット履歴、共有ドキュメントを無期限に保持します。

数百の“孤立したチーム（オーファン チーム）”を抱える組織は、業務上の目的がないストレージに対して支払いをしており、さらに想定していなかった責任（リスク）を生み出しています。

次に、ディスカバリーのコストです。訴訟や規制当局の調査の際に、法務またはコンプライアンスチームが統制されていない環境全体を検索する必要がある場合、eDiscovery の処理コストは関係するワークスペース数に応じて増加します。

本来は絞り込んだ検索で済むはずの内容が、命名が統一されていない、所有者が不明確、データ分類がないといった状況のために、何百ものチームにまたがる広範な調査になってしまいます。こうした非効率は、請求対象の作業時間の増加、納期の遅れ、そしてディスカバリー（調査）プロセスそのものにおける露出（リスク）の増大に直結します。

新たな Teams のスプロールを防ぐ方法

Teams の作成、命名、期限切れに関するガバナンス制御はすべて Teams 管理センターではなく、Microsoft Entra ID レベルで行います。予防を適切に実施するには、ディレクトリ レベルで4つの設定を行う必要があります。

チーム作成を制限する

Microsoft Entra ID PowerShell または Entra 管理センターを使用して、チーム作成を許可されたすべてのユーザーを含む専用のセキュリティ グループを作成します。次に、ディレクトリ レベルの設定を構成し、そのグループに対してのみ作成を許可するようにします。AzureADPreview モジュールは 2025 年 3 月 30 日にサポート終了となったため、Microsoft は長期サポートのために Microsoft Graph PowerShell SDK を推奨しています。

IT のボトルネックを生み出す一律の制限は避けてください。目的は、セルフサービスのコラボレーションを完全に排除することではなく、命名規則やデータ分類の要件を理解しているユーザーに対して作成を導くことです。

命名ポリシーの実装

Microsoft Entra ID（Entra 管理センター → Groups → Naming Policy）で命名ポリシーを構成します。固定文字列、または [Department]、[Company]、[Office] などの動的属性を使用して、Teams、Outlook、SharePoint、Planner、Viva Engage を含むすべての Microsoft 365 Groups ワークロードで一貫した命名を強制します。

一貫した命名は、組織の整理にとどまりません。監査のスコーピング、コンプライアンス検索、ライフサイクルに関する判断を、大規模でも現実的に行えるようにします。チームが予測可能な命名パターンに従うことで、所有者・目的・機密度レベルの特定が簡単になります。

有効期限ポリシーの設定

Microsoft Entra ID（Groups → Expiration）で有効期限ポリシーを設定し、一定期間（通常は 365 日）経過するとチームを自動的に期限切れにします。活発に利用されているチームは、期限切れの約 35 日前に自動的に更新されるため、生産的なチームは影響を受けません。すべてのチーム所有者に対して、30 日時点で更新通知が送信されます。

これは スプロール（増殖） の蓄積に対する、最も効果的な単一のコントロールです。期限切れがないと、完了したすべてのプロジェクト チームが無期限に残り、誰も積極的に管理していない権限とデータが蓄積されていきます。

所有者要件の強制

所有権は、その他すべてのガバナンス コントロールの土台です。説明責任を持つオーナーがいないと、命名ポリシーは適用されず、有効期限の更新も評価されず、機密データに関する判断も行われません。

すべてのチームに対して、最低2名のオーナーを設定することを求めます。Microsoft Entra ID Access Reviews を使用して四半期ごとにオーナーの見直しを実施し、現在のオーナーが組織を離れる場合に新しいオーナーを割り当てるためのエスカレーション手順を定義してください。

既存の Teams スパrawl（スプロール）を整理する方法

ガバナンス ポリシーは新たなスプロールを防ぎますが、既に監視されていない状態で存在しているチームには対処できません。構造化されたクリーンアップ プロセスは5つのフェーズで進めます。

フェーズ1：インベントリの評価

まず、チーム名、オーナーの状態、活動レベル、可視性設定などを含め、現在の Teams 環境の完全なインベントリをエクスポートします。次の観点に基づいて、クリーンアップ候補を特定してください。

• 非アクティブ： 90〜180日間活動のないチーム
• 所有者の不在： アクティブな所有者がいない、または所有者がまったくいないチーム
• 重複： 類似または同一名の複数チーム
• 単一メンバーのチーム： 作成されたが、協業のために一度も使われていないワークスペース

フェーズ 2：ステークホルダーとのコミュニケーション

非アクティブなチームのチームオーナーに通知し、クリーンアップのタイムラインを設定します（通常は 30〜60 日前の通知）。さらに、オーナーがチームを更新するか、チームを保持し続けることの根拠を明確に説明できるよう、分かりやすい手順を用意してください。連絡は非常に重要です。通知なしにチームを削除すると、組織内の摩擦が生じ、ITガバナンスへの信頼が損なわれます。

フェーズ 3：非アクティブなチームのアーカイブ

アーカイブすると、すべてのコンテンツを保持したままチームが読み取り専用になります。規制のある業界では、アーカイブは即時削除の代わりにデフォルトのアクションにすべきです。アーカイブされたチームは、コンプライアンス目的のためにデータを保持しつつ、アクティブな共同作業から外すことで、今後の権限の蓄積を防止します。

フェーズ 4：不要なチームの削除

削除は、以下を確認した後にのみ実施してください：

• 適用される保管ポリシーがありません
• データにコンプライアンス上の価値がありません
• 法的保全（レガルホールド）は存在しません
• 必要なデータがエクスポートされました
• 関係者の承認を取得しました

削除されたチームは、完全に削除される前に 30 日間のソフト削除状態に入ります。何かが早まって削除された場合でも復旧できる猶予期間が得られます。

ステップ 5：保持ポリシーの設定

大規模な削除を始める前に、Microsoft Purview を通じて Teams のチャネル メッセージとチャットの保持ポリシーを設定します。保持期間は、規制要件に合わせてください。これらのポリシーを設定しない場合、クリーンアップ作業によって、コンプライアンス上の価値があるデータを誤って削除してしまうリスクがあります。

クリーンアップが完了したら、継続的な課題は、絶え間ない手作業を伴わずにガバナンスを維持することです。上記の「予防」セクションで扱った有効期限ポリシー、所有者レビュー、作成制限により、スプロールが再び増えていくのを防げます。

Netwrix は Teams のガバナンスをどのように支援するか

ガバナンス ポリシーやクリーンアップ スクリプトは、Teams スプロールの構造面に対処します。しかし、より深刻な課題は可視性です。

• 数百のチームとそれに関連する SharePoint サイトにおいて、誰がどのデータにアクセスできるのかを把握すること
• 権限がドリフトしたときに検知する
• 規制当局が実際に受け入れる監査エビデンスを作成する

それが、Microsoft の標準ツールがそのまま残してしまうギャップであり、Netwrix がフィットするポイントです。Netwrix 1Secure 複雑な導入なしで、最初の日から Microsoft 365 環境の可視性を提供します。SharePoint Online では、1Secure がデータ アクセスのアクティビティを追跡し、機微なデータの所在を可視化し、コラボレーション環境全体での権限変更を監視します。

リスク評価ダッシュボードは、Teams スプロール（sprawl）が生み出す問題を強調します。過剰な権限、機微データへのオープンアクセス、アクセスが残ったままの休眠アカウント、そして組織ポリシーに違反する権限設定などです。AI ベースの修復（改善）推奨により、チームは最初に直すべきことの優先順位を付けやすくなります。

Netwrix Auditorは、規制産業が求める、深いコンプライアンス重視の監査を提供します。迅速な導入と、数時間以内に利用可能なレポートにより、Auditor は Teams、SharePoint、Active Directory、ファイルサーバーにまたがる監査ログ（監査トレイル）を提供します。Google のような対話型検索により、調査担当者は「誰が何に、いつアクセスしたのか」を、1つのチームだけでなく、環境全体にわたって答えられます。

HIPAA、SOC 2、GDPR、PCI DSS、CMMC に対する事前定義済みのコンプライアンス対応マッピングにより、監査の準備は、証拠を手作業で集めるのではなくレポートを取得するだけで済みます。

Microsoft 365 環境内の特権アクセスのために、Netwrix Privilege Secureは、常駐の管理者特権をなくすジャストインタイムのプロビジョニングを提供し、監査トレイルのためのセッション記録（session recording）も行います。

多くの組織では、ガバナンスの意図が欠けているわけではありません。問題は、自社の Teams 環境で何が起きているのかを、行動に移せるほど明確に把握する能力が不足していることです。Netwrix は、すでに負荷の高いセキュリティチームに余計な複雑さを加えることなく、そのギャップを埋めます。

デモを予約する Netwrix を実際にご覧いただき、管理されていないスパrawl から監査可能な統制へ、どれほど迅速に移行できるかを確認してください。