なぜ静的なポリシーでは Microsoft Teams の乱立を防げないのか

By Mirko Peters · 2026-08-11

ポッドキャストフィードへようこそ！モダンなデジタルワークプレースを管理している方であれば、Microsoft Teams テナントを一度は見て、どうすればよいのかと考えたことがあるのではないでしょうか…

Automatically translated with AI from the original post. Read the English original

ポッドキャストへようこそ。最新のデジタルワークプレースを管理しているなら、Microsoft Teams のテナントを見て「どうしてこんなに散らかってしまったのか」と思ったことが一度はあるのではないでしょうか。組織内には数十、数百、ときには数千ものワークスペースが散在しています。今回のブログ記事では、テナントをきれいに保つことについて前回のディスカッションをさらに掘り下げます。このトピックの音声版をより詳しく知りたい方は、関連エピソードの Stop Microsoft Teams Sprawl with Lifecycle Automation もあわせてご覧ください。

TL;DR

• 乱立は作成時点で始まります。クリーンアップではありません。ポリシーだけでは予防は不十分です。
• トリガーを自動化する: Power Apps（申請）→ Power Automate（承認・振り分け）→ Graph API（テンプレートとラベルを使って作成）。
• ライフサイクルを仕組み化する: 非アクティブの検出 → オーナーへの通知 → アーカイブ・有効期限切れ → 必要に応じた復元。
• Power BI でレポートし、サイクルを閉じる: 作成件数、更新、アーカイブ、所有者のいない Teams、ポリシーからの逸脱を把握します。

本当の問題（静的ポリシーが機能しない理由）

多くの組織は、Microsoft Teams を管理するために、作成後の命名規則、有効期限ポリシー、基本的な制限に頼っています。しかし、こうした静的ポリシーは、デジタルな乱立がどのように起きるのかを根本的に捉えられていません。命名規則や制限ポリシーは作成後に摩擦を生むだけで、そもそもチームを作るべきかどうかを決めるものではありません。

誰でも自由にセルフサービスで作成できる一方で、オーナーの責任が曖昧なままだと、ゾンビワークスペースと孤立したデータで埋め尽くされたデジタルの荒れ地が必ず生まれます。従業員は、一時的な作業、短時間のブレインストーミング、その場限りのファイル共有のために新しい Teams を作ります。プロジェクトが終わっても、誰もワークスペースを片付けません。手作業による申請プロセスはすぐに機能しなくなり、IT 部門は、数か月前に終わった作業の後始末のためにユーザーを追いかけることになります。乱立を解消するには発想の転換が必要です。つまり、すべてのワークスペースの誕生、運用、終了を自動的に統制しなければなりません。

自動化の設計図（正しく作成する）

乱立を発生源で止めるには、ワークスペースがプロビジョニングされる前に申請を体系的に処理する、確実な作成の設計図が必要です。

1. 申請（Power Apps）: 業務上の目的、オーナー、秘密度レベル、外部ゲストの必要性、プロジェクトコード、必要な保持期間を、最初の段階で取得します。
2. 承認・振り分け（Power Automate）: マネージャーまたはセキュリティ部門の承認を確保し、名前の重複を自動チェックして、適切なチームテンプレートに申請を振り分けます。
3. 作成（Microsoft Graph API）:
   • 正しい命名規則、説明、秘密度ラベル、プライバシー設定、ゲストポリシーを自動的に適用します。
   • ライフサイクル管理とレポートを円滑にするため、必須のメタデータ（部門、コストセンター、プロジェクト ID）を付与します。
   • 標準のチャネルとタブを用意し、オーナーの責任を説明するウェルカムメッセージを投稿します。
4. ガードレール: オーナーを 2 名以上必須とし、必須のメタデータ項目が空欄の場合は申請を拒否するように自動化します。

自律的に動くライフサイクル（運用と廃止）

ワークスペースが正常に作成されたら、自律的に回るライフサイクルが必要です。手作業の監査に頼ることはできません。代わりに、バックグラウンドで静かに動く自動化されたガードレールを構築しましょう。

• 一定期間（例: 投稿、ファイル編集、会議がゼロの状態が 60 日または 90 日間続く）にわたって非アクティブを検出します。
• 適応型の Teams カードまたはメールでオーナーに通知し、有効なビジネス上の理由を添えて、更新、アーカイブ、または延長を行うよう促します。
• オーナーが応答しない場合に発動する自動アクションです。応答のないチームはアーカイブされ、さらに放置が続くと、スケジュールされた削除が実行されます（基盤となる企業の保持ポリシーは常に尊重されます）。
• スマートルール: 四半期末や季節限定のチームについてはチェックを一時停止したり、「Regulated」または「Board」とラベル付けされた項目については、アーカイブを完全にスキップしたりします。

レポートとフィードバック(効果を実証する)

可視化できないガバナンスは、単なる推測にすぎません。Graph と Microsoft 365 レポートを活用した包括的な Power BI ダッシュボードを構築し、テナントの状況を常に把握できるようにしましょう。

次の項目を追跡する Power BI ダッシュボードを構築します。

• 月ごとに作成された新規 Teams の数、承認の SLA、テンプレートの利用割合。
• 「アイドル → 通知 → アーカイブ → 削除」のファネル。
• 所有者のいない Teams、所有者が 1 人だけのリスク、外部ゲストのアクセスが集中している箇所。
• 命名規則と秘密度ラベルの準拠率、および誤検知を測るための復元とアーカイブ解除の件数。
• 組織全体で回収されたストレージ容量と、削減された検索ノイズ。

実際のデータに基づいてパラメーターを調整します。周期的に利用されるチームでは非アクティブ期間を延長し、所有者が既定の設定を頻繁に上書きしているテンプレートでは内容を見直します。

主要コンポーネント(使用するもの)

<ul