Teamsの「ゲストアクセス」ガバナンス ― 招待・権限・棚卸しのルール設計と運用
「取引先をTeamsのチームに招待したら便利だった」——ゲストアクセスは社外パートナーとのコラボレーションを劇的に効率化しますが、ガバナンスなしで運用すると、退職した取引先担当者、終了したプロジェクトのゲスト、誰が招待したかわからないゲストがテナントに残り続ける状態になります。
ゲストアクセスのリスク
不要なゲストの残存： プロジェクト終了後もゲストが残り、社内のTeamsチャネルやSharePointサイトにアクセスし続ける。
招待の無秩序化： 誰でも自由にゲストを招待できる設定の場合、管理者が把握していないゲストが大量に存在する。
情報の過剰共有： ゲストがアクセスできるチーム/チャネルに、本来見せるべきでない社内情報が共有されている。
最も見落とされるのは、先方の担当者の異動・退職です。 自社のテナントに残ったゲストアカウントは、相手企業でその人が退職しても自動では無効になりません。取引先の元社員が、自社のチームにアクセスできる状態が続きます。
「ゲスト」と「外部アクセス」を区別する
Teamsで社外とやり取りする方法は複数あり、それぞれ管理方法とリスクが違います。 混同したまま設定すると、意図しない範囲が開きます。
| 方式 | 相手の状態 | 特徴 |
|---|---|---|
| ゲストアクセス | 自社テナントにアカウントが作られる | チームに参加できる。棚卸しの対象になる |
| 外部アクセス（フェデレーション） | 相手のテナントのまま | 1対1チャットや通話が中心。アカウントは作られない |
| 共有チャネル | 相手のテナントのまま特定チャネルに参加 | チーム全体は見せずに済む |
「チャットだけできればよい」なら、ゲストにする必要はありません。 外部アクセスで足りる相手をゲストとして招待すると、棚卸しの対象が無駄に増えます。逆に、特定のチャネルだけ共有したい場合は共有チャネルを検討してください。チーム全体を見せずに済みます。
ガバナンス設計の4つのポイント
1. 招待権限の制限
Entra IDの「外部コラボレーション設定」で、ゲストを招待できるユーザーを制限します。
- 全員が招待可能（既定）： 最もリスクが高い。中小企業でも非推奨
- 特定のロールのみ招待可能： ゲスト招待者ロールまたは管理者のみに限定。推奨設定
- 管理者のみ招待可能： 最も制限が厳しい。少人数の組織で管理者の負荷が許容できる場合
2. ゲストのアクセス範囲制御
Teamsの設定： Teams管理センターで、ゲストが利用できる機能（チャット、通話、画面共有、ファイル共有等）を制御できます。
SharePointの外部共有レベル： 「認証済みの外部ユーザーのみ」に設定し、匿名リンクは禁止を推奨。
ゲストのディレクトリ参照制限： Entra IDの設定で、ゲストが社内ユーザーの一覧を参照できないよう制限可能です。
3. 定期棚卸しの仕組み化
手動棚卸し： 四半期に1回、Entra管理センターで「ユーザータイプ：ゲスト」でフィルタし、不要なゲストを削除。
自動棚卸し（Entra ID P2）： Entra IDのアクセスレビュー機能を使えば、チームの所有者に対して「このゲストはまだ必要ですか？」という確認を自動的に定期送信し、応答がなければ自動でアクセスを剥奪する運用が構築できます。
4. ゲストの有効期限設定
Entra IDの「外部コラボレーション設定」で、ゲストアカウントの有効期限（たとえば90日）を設定できます。期限が近づくと所有者に更新確認が送信され、更新されなければ自動的にアクセスが失効します。
運用ルールテンプレート
- ゲスト招待はチーム所有者または管理者のみ可能
- 招待時に「目的」「想定期間」をチーム所有者が記録
- ゲストにはMFAを必須化（条件付きアクセスポリシー）
- 四半期ごとにゲスト一覧を棚卸し（Entra IDアクセスレビューまたは手動）
- プロジェクト終了時にゲストの削除をプロジェクト完了チェックリストに含める
ゲストのMFAは自社側で要求できます。 相手企業のセキュリティ対策に依存せず、条件付きアクセスで「ゲストにはMFAを要求」と設定してください。相手のパスワードが漏えいしても、自社のデータには到達させないための最低限の設定です。
準拠デバイスの要求はゲストに適用できません。 相手の端末は自社のIntuneに登録されていないためです。ゲストが参加するチームに対して「準拠デバイス必須」の条件を適用すると、社外のメンバーが一切アクセスできなくなります（認証コンテキストの記事も参照）。
棚卸しの実務
一覧を眺めるだけでは判断できません。 削除の可否を決める基準を先に用意してください。
- Entra管理センターでゲストを一覧化し、最終サインイン日を出す
- 6ヶ月以上サインインがないゲストは削除候補とする
- 判断がつかないゲストは、招待したチームの所有者に確認する
- 所有者が退職している場合は、そのチーム自体が管理不在。チームの扱いから決める
削除するとどうなるかも把握しておいてください。 ゲストアカウントを削除すると、そのゲストが投稿したチャットやファイルの表示が変わったり、共有していた資料にアクセスできなくなったりします。案件の記録として残す必要があるものは、削除前に社内のサイトへ移してください。
削除ではなく「サインインブロック」から始める方法もあります。 影響が読めない場合、まずブロックして数週間様子を見てから削除すると、業務が止まるリスクを避けられます。
まとめ
- 取引先の担当者が退職しても、自社のゲストアカウントは自動では無効にならない
- ゲスト・外部アクセス・共有チャネルを区別する。チャットだけなら外部アクセスで足りる
- 特定チャネルだけ共有したいなら共有チャネル。チーム全体を見せずに済む
- 招待権限はチーム所有者または管理者に限定する
- ゲストのMFAは自社側で要求できる。相手のセキュリティ対策に依存しない
- 準拠デバイスの要求はゲストに適用できない。適用すると社外は一切アクセスできなくなる
- 棚卸しは最終サインイン日で判断する。6ヶ月以上なしは削除候補
- 所有者が退職しているチームは、チーム自体が管理不在。そこから扱いを決める
- 削除前に、案件の記録として残すものを社内サイトへ移す
- 影響が読めないときは、削除ではなくサインインブロックから始める
ゲストアクセスは「招待の制限」「権限範囲の制御」「定期棚卸し」の3点をルール化するだけで、リスクを大幅に低減できます。まずは招待権限を管理者・チーム所有者に限定するところから始めてください。
情シス365では、Teamsのガバナンス設計（ゲスト管理、チーム作成ポリシー、命名規則）を支援しています。お気軽にご相談ください。