Microsoft 365のゲストアクセス管理：完全ガイド

By Mirko Peters · 2026-02-24 · Updated 2026-09-13

オンボーディング、アクセスレビュー、条件付きアクセス、ライフサイクル管理、ゲストのオフボーディングを通じて、TeamsとSharePointにおけるMicrosoft 365のゲストアクセスを管理します。

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

正直に言えば、社外とのコラボレーションと堅固なセキュリティのバランスを取ることは、本格的な組織でMicrosoft 365を使う際の最大の悩みの一つです。ゲストアクセスを使えば、パートナー、協力会社、顧客にTeams、SharePoint、その他のMicrosoft 365の機能を開放できますが、開けたドアはすべて潜在的なリスクになります。だからこそ、ゲストアクセスの管理はチェックリストではなく、継続的な戦略なのです。

このガイドでは、Microsoft 365におけるゲストアクセスの基本から、セキュリティ制御、ライフサイクル管理、高度なリスクスコアリング、自動化までを扱います。Microsoft 365のセキュリティ、コンプライアンス、ITオペレーションの責任者であれば、コラボレーションを維持しながら、重要な場所のドアはしっかり施錠しておくための実践的なヒントが見つかるはずです。余計な前置きは抜きにして、データと評判を守りつつ生産性を保つための明確な戦略をお届けします。

1. ゲストはAzure ADに追加され、通常のユーザーと同様に表示されます。ゲストアカウント（userType=Guest）はAzure AD内に存在し、ユーザー一覧、グループのメンバーシップ、アクセスレビューに表示されます。そのため、ライセンスやガバナンスの可視性に影響します。
2. ゲストアカウントは、ほとんどのリソースへのアクセスにMicrosoft 365ライセンスを必要としません。ゲストはTeams、SharePoint、OneDriveのリソースを、フルユーザーライセンスを消費せずに利用できます。ただし、一部の機能は制限される場合があります。
3. B2Bコラボレーションは、Microsoftアカウント以外の外部IDにも対応しています。ゲストは、Azure AD B2BとフェデレーションされたIDプロバイダーを通じて、職場や学校のメールアドレス、Gmailなど多くのメールIDでサインインできます。
4. ゲストには条件付きアクセスを適用できます。条件付きアクセスポリシーを使えば、ゲストのサインインに対してMFA、デバイスのコンプライアンス、場所による制限を適用でき、社外のコラボレーターに対するセキュリティを強化できます。
5. アクセスレビューによって非アクティブなゲストを自動的に削除できます。Azure ADのアクセスレビューにはゲストユーザーを含めることができ、設定した期間を過ぎるとゲストを削除します。これにより、使われなくなった社外からのアクセスを減らせます。
6. ゲストの共有設定は複数の層で管理されています。テナントレベルのAzure AD設定、SharePointとOneDriveの共有ポリシー、Teamsのゲスト設定が相互に作用するため、足並みがそろっていないと予期しないアクセス結果を招く可能性があります。
7. ゲストアクセスは秘密度ラベルによって制限できます。Microsoft Information Protectionの秘密度ラベルは、サイトやチームでゲストアクセスが有効になっていても、共有を防いだり、社外からのアクセスを制限したりできます。
8. ゲストはMicrosoft Graphで検索できます。ゲストユーザーとそのアクティビティはプログラムから照会・管理でき、レポート作成や是正措置といったガバナンス作業を自動化できます。
9. Teamsのプライベートチャネルのゲストは、チームのゲストとは異なります。プライベートチャネルのメンバーシップは、チーム全体のメンバーシップに比べて制限が厳しく、以前はゲストの動作や管理面でチームとは別の扱いがありました。
10. 招待したゲストは、社外とのコラボレーション関係として残り続けます。ゲストを招待すると、Azure ADは外部コラボレーション関係を作成し、場合によってはホームテナントのメタデータも作成します。そのため、同じメールアドレスを再招待すると、以前の関係とアクセス許可が再利用される可能性があります。

Microsoft 365環境におけるゲストアクセスの理解

Microsoft 365を社外のユーザーに開放すると、プラットフォームの柔軟性は一気に高まりますが、同時に複雑さも増します。ゲストアクセスは、組織外の人がお客様のプロジェクト、ドキュメント、会話に参加するための正式な方法です。Teamsでベンダーとリモート会議をする場合も、SharePointでコンサルタントとフォルダーを共有する場合も、ゲストアクセスが企業間コラボレーションを支えています。

ただし、柔軟性が高まるほど、リスクも大きくなります。設定ミス、放置されたアカウント、過剰に許可されたゲストの権限は、セキュリティ侵害やコンプライアンス上の問題につながりかねません。そのため、Microsoft 365のガバナンスを任された人にとっては、ゲストアクセスの基本的な仕組みと、どこで問題が起きやすいかを理解することが不可欠です。

Microsoft 365 には、ゲストユーザーを追跡および管理するためのツールが用意されています。ただし、組織のリスク許容度とコラボレーションの必要性に合った枠組みを設計するのは、皆さんの役割です。アクセス許可からライフサイクル管理まで、すべてを整理された状態に保つための方法が必要です。隠れたリスクや、構造化されたオフボーディングの重要性が気になる場合は、残存するゲストアカウントに潜む危険性についての解説記事をご覧ください。外部ユーザーのガバナンスがいかに重要かが、よく分かります。次に、基本を整理し、ゲストアクセスが Teams や SharePoint などのサービスとどのように関わるかを見ていきましょう。

ゲストアクセスの基礎とアクセス許可の解説

Microsoft 365 におけるゲストアクセスは、パートナー、契約社員、サプライヤー、顧客などの組織外の人が、組織のデジタル環境内で共同作業できるようにするための仕組みです。こうした「ゲスト」は、Teams、SharePoint、その他の Microsoft 365 ワークロードなどのサービスに招待できます。ただし、そのアクセスは、正社員やメンバーのアクセスよりも制限されることが前提になっています。

要点は次のとおりです。ゲストを招待すると、組織のディレクトリにアカウントが作成されます。ただし、メンバーと異なり、ゲストアカウントは通常、より少ないアクセス許可を持ちます。ゲストはチームに参加し、会議に出席し、共有ファイルにアクセスし、チャットを行い、自分に共有されたコンテンツを操作できます。一方で、既定の制御を緩めていない限り、新しいチームを作成したり、機密性の高い社内リソースにアクセスしたりすることはできません。

流れは、招待から始まります。通常は管理者または委任された権限を持つユーザーが招待を送信します。招待されたゲストは、自社または個人の資格情報を使用して認証を行い、アクセスの有効期限から多要素認証まで、組織のポリシーの管理下に置かれます。注意すべき点は、適切なライフサイクル管理がなければ、ゲストアカウントが増え続け、管理が行き届かないリスクの高い状態になることです。ゲストアカウントのリスクに関する詳しい解説にもあるように、終了したプロジェクトの残存アカウントは、コンプライアンス上の問題や実際のセキュリティ侵害を引き寄せやすいものです。

ゲストとメンバーのロールは、設計上異なります。メンバーは社内ポリシーの下で完全な権限を持ちますが、ゲストは通常、割り当てられたチーム、サイト、リソースに限定されます。アクセス許可は、テナント、グループ、サイトのいずれのレベルで設定するかによって、細かくも広くも設定できます。基本原則は、外部ユーザーには役割に必要な最小限のアクセスのみを許可し、定期的なレビューと期限付きのアクセス許可を徹底して、脅威の対象範囲を減らすことです。

ゲストアクセスと Teams および SharePoint の連携

Microsoft Teams と SharePoint は、Microsoft 365 においてほとんどのゲストとのやり取りの中心となります。これが機能する理由は、両アプリがプラットフォーム全体の幅広いゲストアクセスの仕組みと統合されているためです。ゲストをチームに追加すると、チャネルに投稿したり、会議に参加したり、ファイルを共有したり、チャットを利用したりできます。ただし、組織全体の設定を変更したり、新しいトップレベルのチームを作成したりすることはできません。これにより、中核となるガバナンスの構造を維持しながら、共同作業を進めることができます。

SharePoint では、ゲストアクセスとは、共有されたサイト、ライブラリ、特定のファイルやフォルダーに外部ユーザーがアクセスできることを意味します。社員と並んで作業することさえ可能です。ただし、重要な注意点があります。SharePoint の柔軟性は強みであると同時にリスクでもあります。注意を怠ると、「共有」ボタンによって意図しないデータの拡散、脆弱なアクセス許可、本来は厳重に保護すべきデータへの外部アクセスが生じるおそれがあります。このため、多くの組織がガバナンスの取り組みを延々と繰り返し、完全に管理できている実感を得られないという状況に陥ります。この点については、Teams ガバナンスにおける管理の幻想をテーマにしたエピソードで詳しく取り上げています。

そして本当に厄介なのは、TeamsとSharePointを連携させるたびに(Teamsはファイル保存にSharePointを基盤として使うため)、両方のプラットフォームのガバナンス上の癖をそのまま引き継いでしまう点です。Teamsのゲストには、基になるSharePointのドキュメントへのアクセス権が自動的に付与されます。ゲストユーザー向けにSharePoint Listsを使ったアプリを構築する場合は注意が必要です。こちらで解説しているとおり、複雑で機密性が高く、長期間使われるソリューションにSharePoint Listsを使うと、ガバナンス上の深刻な問題になりかねません。管理者にはゲストのアクセス許可を制限する仕組みがありますが、結局のところ、ポリシーの適用と継続的なレビューにかかっています。

外部ユーザーのアクセス ガバナンスとコンプライアンスへのアプローチ

ガバナンスの課題はゲストのオンボーディングだけでは終わりません。Microsoft 365で社外の人と共同作業を始めた時点で、定期的なチェック、継続的な監視、そして業界に適用される規制への準拠に対する責任が生じます。だからこそ、明確なアクセス ガバナンス戦略がもう一方の柱として必要になります。

主な課題は何でしょうか。ゲストのアクセスを実際のビジネス ニーズと常に一致させること、権限の肥大化(プリビレッジ クリープ)を防ぐこと、そして古いゲスト アカウントが蓄積し、監査上の指摘やセキュリティ上の脆弱性になってしまう状況を避けることです。組織は、オンボーディング、レビュー、削除といった運用ワークフローを、コンプライアンス活動と密接に結び付ける必要があります。

外部ユーザーのアクセス権の管理と定期的なアクセス レビューの実施は、もはや任意ではなくベスト プラクティスです。規制当局や経営層が厳しく注視するなか、誰が何にアクセスできるのか、なぜそのアクセス権を得たのか、いつ期限切れになるのかを、いつでも証明できなければなりません。ポリシーのずれ、忘れられたアクセス許可、オフボーディングの漏れは、すぐにコンプライアンス上の問題につながりかねません。特に、コンテンツ作成や自動保存の動作によってデータの実際の状態が見えにくくなっている場合は、なおさらです。Microsoft 365に潜むコンプライアンス上のリスクについては、コンプライアンス ドリフトに関するこのポッドキャスト エピソードをご覧ください。信頼できるガバナンスを実現するには、ポリシーの結果だけでなく、ユーザーの行動を測定する必要があることを解説しています。

以降のセクションでは、定期的なアクセス レビューの手順、堅牢なライフサイクル管理、そしてエンタイトルメント管理を、誰にどのリソースへのアクセスを、どの期間、どの条件で許可するかを自動化し制御するフレームワークとして活用する方法を解説します。

アクセス レビューとライフサイクル管理のプロセスの構築

1. 定期的なアクセス レビューのスケジュール化: M365環境にアクセスできるゲストを確認するサイクル(毎月、四半期ごと、またはプロジェクトやイベントごと)を決めてください。Entra IDのネイティブなアクセス レビュー機能を使えば、リソース所有者やシステム管理者への通知を自動化し、回答を収集できます。
2. 業務上の理由と必要最小限の範囲でゲストをオンボーディングする: オンボーディングでは、すべてのゲスト招待に業務上の必要性があり、必要なリソースだけに範囲を限定されていることを確認してください。過不足のない範囲に絞ることが重要です。可能な限り、包括的なアクセス権や無期限のアクセス許可は避けましょう。
3. ライフサイクル通知と有効期限の自動化: ゲストアカウントに有効期限ポリシーを設定し、ゲストユーザーとスポンサーの両方に通知が届くようにしてください。期限が切れたら、手動で更新されない限りアクセスをブロックまたは削除し、忘れ去られた不要なアカウントが残るリスクを減らします。
4. アクセス レビューの結果を確認し、対応する: レビューのたびに結果を分析し、すぐに対応してください。非アクティブまたは重複しているゲストのアクセス許可は削除または調整し、アクセス権が現在のビジネス運用の状況と一致していることを確認します。
5. 監査に備えてすべての操作を記録する: Microsoft Purview監査、または同等のツールを使って、アクセス レビュー、承認、削除、変更のイベントを記録してください。アクティビティ監査のガイドで解説しているとおり、規制当局の調査が入ったときに、堅牢な監査証跡があればコンプライアンスとセキュリティの両面を強化できます。

エンタイトルメント管理を外部ユーザー向けに有効にする

Microsoft 365のエンタイトルメント管理を使うと、Teams、SharePointサイト、アプリなどのリソースをアクセスパッケージにまとめ、ひとつの単位として管理できます。外部ユーザーにとっては、この仕組みで手続きが簡素化されます。ゲストはパッケージを申請するか、割り当てを受け、承認は自動化するか必要に応じて経路を分けて処理されます。そしてアクセスは、期間やレビューのトリガーといった設定済みのポリシーで管理されます。これにより、各ゲストがどのデータやツールに触れられるかを正確に制御・追跡でき、手作業のプロビジョニングを減らし、過剰な権限付与のリスクを抑えつつ、監査性も高められます。

Microsoft Entra ID ガバナンスと安全な B2B コラボレーション

ゲストアクセスを「とりあえず動く」状態から「安全かつ拡張可能」な状態へ引き上げたいなら、Microsoft Entra ID が real価値を発揮します。このクラウドID サービスは、Microsoft 365 におけるすべてのユーザーとゲストの認証を支えており、制御、承認、リスク管理を一元化できます。Entra には組み込みのガバナンス機能があり、誰が入れるかを絞り込み、何が起きているかを把握し、正当なコラボレーションを妨げずに組織全体のルールを適用するのに役立ちます。

堅牢な Entra ID ポリシーは、安全な B2B（企業間）コラボレーションの土台です。このプラットフォームは、追跡と監査だけでなく、データ漏えいの制限、エンタイトルメントのワークフローの自動化、単発および定常的なゲストシナリオの境界設定を可能にするツールを提供します。変化する脅威にすばやく対応したい、あるいはIDの逸脱を防ぎたいですか。Entra のポリシーと統合機能を使えば、業務を止めることなく適応できます。

もちろん、コントロールプレーンとしてのIDも万全ではありません。例外を積み重ねたり、ポリシーの見直しを怠ったりすると、「IDの負債」が忍び込み、予測できないリスクを生みます。IDリスクへの実践的な対策については、Entra の条件付きアクセスのセキュリティループに関するこのエピソードをご覧ください。次は、Entra が IDガバナンスにどう正面から取り組むかを見ていき、その後で B2B ゲスト管理の実践的な手法を取り上げます。

Microsoft Entra における ID ガバナンス機能

Microsoft Entra ID は、内部アカウントと外部アカウントの両方に対して強力な ID ガバナンス機能を提供します。ポリシー、承認ワークフロー、組織のルールに合わせて調整される条件分岐ロジックを使ってアクセスを制御できます。Entra を使えば、リスクベースの認証を適用し、アクセスレビューを自動化し、機密性の高いリソースに対する承認の流れを設定できます。これにより、ゲストを含め、適切なユーザーだけが適切なアクセス権を持つ状態を保ちやすくなり、すべての要求と変更が Microsoft クラウド内で記録され、追跡性とコンプライアンスを確保できます。

B2B コラボレーションと外部ユーザーの効果的な管理

Microsoft 365 における効果的な B2B コラボレーションは、統制されたゲストのオンボーディングから始まります。招待のプロセスは信頼できる社内スポンサーに委任することも、文書化された業務上の必要性に基づいて自動化することもできます。その際は、必ずセキュリティチェックと承認が行われるようにしてください。安全な招待には通常 Entra B2B を活用します。これによりゲストは自分の資格情報を使えると同時に、組織のコンプライアンスの枠組みの中に置かれます。

適切な管理はオンボーディングで終わりではありません。ロールを制限し、期間を限定したアクセス許可を設定し、現在のアクセス状態を定期的にレビューして、ゲストアクセスを体系的に管理してください。過剰なプロビジョニングは避けることが重要です。権限が多すぎると、環境が悪用や侵害にさらされかねません。自動化は役立ちますが、責任の所在を明確に保つには人による監視が欠かせません。

プロジェクトが完了したら、オフボーディングは迅速に行うべきです。アクセスを取り消し、グループやサイトから削除し、古いエンタイトルメントをすべて整理してください。放置されたアカウントは見落とされやすく、コンプライアンスのギャップやセキュリティリスクにつながります。休眠アカウントや忘れられたアカウントへの対処を含め、ゲストアクセスを適切に管理するための詳細な手順については、ゲストアカウントの継続的なガバナンスに関するこれらの戦略をご覧ください。

条件付きアクセスとポリシーの適用によるゲストアクセスの保護

外部ユーザーがMicrosoft 365環境を利用する以上、強力なポリシーの適用が最初であり最後の防御線になります。条件付きアクセスと多要素認証は、最新のセキュリティ制御の中核です。正当なコラボレーションを止めることなく、リスクを考慮したポリシーを適用できます。さらに、テナント間アクセス設定によって、どのゲストが入場できるか、どのような条件で入場できるかを決められます。

ポリシーの選択によって、ゲストが特定のデバイスや地域からデータにアクセスできるかどうか、あるいは特定のリスクシグナルが検出されない場合にのみアクセスできるかどうかを決めます。ここで重要なのはバランスです。脅威を防ぐのに十分な厳格さを保ちつつ、業務が絶え間ない摩擦なしに進むだけの柔軟性も確保する必要があります。

ただし注意が必要です。ポリシーは常に最新の状態に保つ必要があります。除外設定が広すぎる、アラートを放置する、コンプライアンス上の「近道」をとるといったことがあると、構成全体が無効になり、テナントが脅威や情報漏えいにさらされるおそれがあります。条件付きアクセスの落とし穴と対策について現実的に知りたい場合は、条件付きアクセスの信頼性の問題に関するこの解説をご覧ください。それでは、ゲストに対する条件付きアクセスと、テナント間のアクセス管理の戦略を実際に見ていきましょう。

ゲストに対する条件付きアクセスと多要素認証の実装

• ベースラインの条件付きアクセスポリシーを適用する: すべてのゲストユーザーが、準拠デバイスや承認されたネットワークからの認証など、ベースラインのセキュリティ要件を満たすように、既定のルールを設定します。除外設定を広げすぎないよう注意してください。広すぎる除外設定は、目に見えないセキュリティの穴の主な原因になります。詳細は条件付きアクセスの信頼性の問題に関するこの分析を参照してください。
• 多要素認証(MFA)を強制する: すべてのゲストのサインインで MFA を必須にします。機密性の高いコンテンツやツールにアクセスする際は、ゲストに第 2 要素で本人確認を行ってもらいます。これにより、ゲストの主要なログイン情報が侵害された場合のリスクを減らせます。
• 場所とデバイスのフィルターを使用する: 地理的な場所またはデバイスの状態に基づいて条件付きアクセスのルールを設定します。リスクの高い国や非準拠デバイスからアクセスしようとするゲストは、ブロックするか、追加の確認を求めることができます。
• リスクベースのトリガーを活用する: Microsoft Entra のリスクエンジンは、不審なサインインのパターン(なじみのないブラウザーや、物理的にありえない移動など)を検出し、追加の確認を求めたり、ゲストアカウントへのアクセスを完全にブロックしたりできます。
• ポリシーの有効性を監視し、調整する: セキュリティログ、認証の成功と失敗、実際のゲストのアクティビティを定期的に確認し、条件付きアクセスの構成が脅威を防げているか、また正当な外部ユーザーに不必要な手間をかけていないかを検証します。

テナント間アクセスポリシーとアクセス制御の管理

Microsoft 365 のテナント間アクセスポリシーを使うと、特定の組織やドメインからのゲストに対して詳細なルールを設定できます。これらの制御により、外部ユーザーがアクセスできるリソースを指定し、コラボレーションを特定のチームやプロジェクトに限定し、許可されていない共有をブロックできます。きめ細かなアクセス制御によって、機密データを意図しない人の目から守りつつ、生産性の高い B2B の関係を維持できます。これらのポリシーは「設計によるゼロトラスト」の中核原則を支えるものです。この考え方については、Microsoft 365 のゼロトラストに関するこのエピソードで詳しく解説しています。

ゲストアクセスのセキュリティとコンプライアンスのための監査と監視

ゲストアクセスのガバナンスは、最初のポリシー設定で終わりではありません。日々のセキュリティと長期的なコンプライアンスは、外部ユーザーが Microsoft 365 環境でどのように操作しているかを継続的に見守ることにかかっています。事前の監査と注意深い監視によって、問題が大きくなる前に見つけられます。それが危険な共有の動作であれ、不審なアクティビティのパターンであれ、とうに取り消されているべきだったゲストのアクセスであれ、同じです。

適切な監査証跡とID 中心のアクセスレビューを設定することは、万一問題が起きたときの最善の防御策です。誰が何にアクセスしているかだけでなく、いつ、どこから、そして可能であればなぜアクセスしているかを把握する必要があります。この継続的な監視により、コンプライアンスやインサイダーリスクの問題につながりうる異常な利用や非アクティブなアカウントを特定できます。

標準のログ記録やアラートの機能にも一定の役割はありますが、文脈に依存する細かなイベントの検出までは十分にカバーできない場合があります。そうしたギャップを埋めるには、Microsoft Purview による拡張監査が、規制のある大規模な環境では欠かせません。効果的なアクティビティ監視の設定を実践的に掘り下げたい方は、Microsoft Purview 監査の利用に関する包括的なガイドをご覧ください。次に、ゲストのアクセス履歴を追跡し、休眠状態や高リスクのゲストアカウントに対応する方法を説明します。

監査証跡とアクセス レビューによるゲストのアクティビティ追跡

Microsoft Purview などのプラットフォームで支えられる Microsoft 365 の監査証跡は、ゲストアカウントを含め、誰が、いつ、何にアクセスしたかの詳細な記録を取得します。これらのログを有効にし、レポートを定期的にエクスポートすることで、Teams、SharePoint などのサービス全体でゲストのアクティビティを追跡できます。アクセス レビューは、自動または手動で実施でき、リソース所有者に現在のゲストのアクセス許可の確認または取り消しを促すことで、監査ログを補完します。これにより、コンプライアンスと事後調査のワークフローの両方を支援します。段階的な監査の手順については、Microsoft Purview によるアクティビティ監査に関するこちらの記事で確認できます。

非アクティブなユーザーとデータ流出リスクの検出

非アクティブなゲストアカウントは、悪用やデータ漏えいの主な標的になります。Microsoft 365 に組み込まれたアクティビティ レポートと監視ソリューションを使えば、一定期間ログインしていない、またはリソースを操作していないアカウントを特定できます。さらに、脅威監視ツールを使うと、データ流出の試みを示す可能性がある、通常と異なるダウンロードや共有のパターンを見つけられます。その後、自動化されたポリシーによって休眠アカウントを無効化または削除し、外部からのアクセス権を厳格に管理し続けられます。こうした対策は、Dataverse での外部への情報漏えい防止に関するこちらのガイドで説明されているように、Dataverse などのプラットフォームを保護するうえでも欠かせません。

ゲストアクセスのガバナンスを次のレベルへ: リスクスコアリングと自動化

外部のコラボレーターが数十人、場合によっては数百人にのぼる場合、手作業によるガバナンスでは対応しきれません。リスクスコアリングや自動化といった高度な戦略は、複数テナントにまたがる広範な環境でもポリシーの適用を拡張し、人為的ミスを減らすための有効な手段です。これらの手法により、静的なアクセス制御を超えて、実際のリスク要因や業務の変化に動的に対応できる環境を構築できます。

リスクベースのゲストガバナンスは、ユーザーの動作を分析し、アクティビティを機密性によって分類することから始まります。Azure Logic Apps などのツールによる自動化は、アクセス レビューの開始、アラートの送信、入社・退社時のワークフローの効率化など、反復的なタスクを肩代わりします。これらのアプローチを組み合わせることで、チームの作業を遅らせたり、管理者に煩雑なレビューの負担をかけたりすることなく、アクセス権を業務ニーズとセキュリティのベスト プラクティスに厳密に沿った状態に保てます。

ダッシュボードや画一的なレポートに気を取られ、ガバナンスの成熟度を実際に高めない組織は少なくありません。その罠を避け、ゲストアクセスを回復力があり拡張可能な形で制御するには、動的でリスク主導の環境向けに設計されたフレームワークやテクノロジーを検討することが大切です。大規模なガバナンスについての将来を見据えた視点（管理されていない AI エージェントのリスクや、安定したコントロール プレーンの重要性を含む）については、AI エージェントのガバナンス課題に関するこちらのエピソードをご覧ください。

ゲストアクセスのリスクスコアリングと行動プロファイリングの実装

• アクティビティの頻度を分析: ゲストユーザーがログインして共有コンテンツを操作する頻度を追跡します。まれな操作や急な増加があれば、より詳細なレビューを行うきっかけになります。
• データの機密性を評価: ゲストの許可を、アクセスされるデータの分類（例: 公開、社内、機密）と照合し、最小特権の原則を適用します。
• ポリシー違反を監視: 行動分析を使って、過剰なダウンロード、ログインの失敗、制御の回避を試みるといった、リスクの高いゲストの行動の兆候を検出し、スコアを付けます。
• リスクプロファイルを動的に更新: ゲストのリスクスコアは、アクティビティやアクセスの必要性が変わるたびに調整されるべきです。必要に応じて、より厳しい制御を適用したり、重点的なレビューを開始したりできます。

Azure Logic Apps によるアクセスレビューとガバナンスの自動化

1. アクセスレビューを自動的にトリガー: 在籍期間、非アクティブ状態、または高いリスクに基づいて、ゲストアクセスのレビューをスケジュールし、リソース所有者に通知する Azure Logic Apps のワークフローを構築します。動的なトリガーにより、カレンダーだけでなく、必要なタイミングでアクセスをレビューできます。
2. オンボーディングとオフボーディングを効率化: Logic Apps を ID プラットフォームに接続し、新しいゲストの招待を処理し、承認をルーティングし、アクセス パッケージの有効期限が切れたときやリスクのしきい値を超えたときに削除を自動化します。
3. アラートとインシデント対応を統合: 繰り返しのサインイン失敗や機密データへのアクセス試行など、不審なゲストアクティビティが検出された場合に、リアルタイムのアラートを IT セキュリティチームに送信するワークフローを設定します。これにより、脅威への対応を迅速化できます。
4. コンプライアンス レポートを自動化: Logic Apps を使用して、監査人向けの証拠を収集・整理します。たとえば、完了したレビューのログ、期限切れのアカウント、アクセス パッケージの変更履歴などです。これにより、適切な注意義務を果たしていることand ガバナンスの有効性を実証しやすくなります。
5. テナントとワークロード全体に拡張: 複数の Microsoft 365 テナントやワークロードにまたがる自動化テンプレートを展開し、管理リソースを消耗させることなく、どこでも一貫したガバナンスを確保します。自動化の落とし穴についてヒントや現実的な視点が必要な場合は、最近の M365 FM ポッドキャストのエピソードを参照してください。専用のコンテンツがなくても、エンタープライズ自動化の課題に触れたガバナンスの議論が取り上げられています。

ゲストユーザーのアクセス に関するよくある質問: アクセスレビューを実施して、ゲストアクセスを管理し、ゲストユーザーを保護します

Microsoft 365 におけるゲストアクセスガバナンスとは何ですか。また、なぜ重要なのですか。

Microsoft 365 におけるゲストアクセスガバナンスとは、チーム、SharePoint サイト、Microsoft 365 グループ、アプリケーションへのゲストユーザーのアクセスを管理するために使用されるポリシーとプロセスの一式です。ゲスト(usertype が guest)は一時的または限定的なアクセスを必要とすることが多いため、重要です。ゲストの定期的なアクセスレビューや、アクセス削除プロセスといった制御がなければ、過剰なアクセス許可、データの漏えい、コンプライアンス違反のリスクが生じます。

Microsoft Entra を使用して、ゲストのアクセスレビューを実施するにはどうすればよいですか。

Microsoft Entra アクセス レビュー(Microsoft Entra 管理センター、または Microsoft 365 管理センターとの統合経由)を使用して、アクセスレビューを実施します。グループまたはアプリケーションを選択し、レビュー担当者、頻度、判断オプションを指定して、アクセスレビューまたはゲストの定期的なアクセスレビューを作成します。レビュー時には、Microsoft Entra ID から電子メールでレビュー担当者に通知が送られるか、アクセス パネルに表示され、ゲストユーザーのメンバーがアクセスを継続すべきかどうかを確認します。

ゲストユーザーを含むグループのアクセスレビューは、いつ作成して実施すればよいですか。

ゲストユーザーを含むグループに気付いたとき、大規模なプロジェクトが終了した後、またはベストプラクティスとして定期的(毎月または四半期ごと)にアクセスレビューを作成して実施します。グループの定期的なアクセスレビューは、ユーザーに引き続きアクセスが必要かどうかを確認するのに役立ち、Microsoft 365 グループおよび Microsoft Entra ID のグループ全体で、所有者のいない不要なアクセス許可を減らします。

ゲストユーザーのアクセスレビューには、どのレビュー担当者を割り当てるべきですか。

リソースを理解している担当者を割り当てます。たとえば、グループ所有者、アプリケーション所有者、または指名されたコンプライアンス管理者などです。ゲストユーザー本人による自己レビューや、Microsoft Entra アクセス レビューによる自動レビューを割り当てることもできます。説明責任と作業負荷のバランスを取り、Microsoft Entra アクセスを使ったアプリケーション全体のアクセス管理を支えるレビュー担当者を選んでください。

アクセスレビューは、ゲストのアクセスを安全に削除したり、ゲストアカウントを削除したりするのにどのように役立ちますか。

アクセスレビューでは、もはや必要とされていないゲストユーザーのアクセスが明らかになります。レビュー担当者は、レビュー中にアクセスを削除する(または維持するとマークする)ことができます。ゲストが Microsoft 365 グループまたはアプリケーションから削除されると、組織のテナント内の基になるユーザーアカウントを削除することなく、アクセスが取り消されます。ガバナンスのライセンス機能を使用すると、レビュー後にゲストの削除やグループまたはアプリケーションへのアクセスの取り消しなどの操作を自動化できます。

Microsoft Entra アクセス レビューとガバナンスには、特別なライセンスが必要ですか。

Microsoft Entra ID ガバナンスおよび Microsoft Entra アクセス レビューの一部の高度な機能には、Microsoft Entra ID ガバナンスのライセンスまたは Microsoft 365 SKU が必要な場合があります。自動修復、高度なレポート、アクセス パッケージの割り当て連携などの機能で追加ライセンスが必要かどうかは、Microsoft Learn の「Entra ID ガバナンス ライセンスの基礎」を確認して判断してください。

Microsoft 365 グループとアプリケーション全体で、ゲスト ユーザーのアクセスを効果的に管理するにはどうすればよいですか?

複数のポリシーを組み合わせて使用します。Microsoft 365 管理センターまたは Microsoft Entra 管理センターで招待権限を制限し、管理された受け入れ手順のためにアクセス パッケージの割り当てを伴う権限の管理を使用し、グループやアプリケーションへのアクセスを確認するために定期的なアクセス レビューをスケジュールします。また、監査ログでユーザーとゲストのアクセスを監視し、ゲスト ユーザーのアクセス レビューでレビュー担当者にユーザーのアクセスを確認させてください。

ゲスト ユーザー アカウントとそのアクセスを保護するには、どのような手順に従えばよいですか?

まず、ゲスト アクセスを許可するリソースを分類し、最小特権の原則を適用して、ゲスト ユーザーのアクセスに対する条件付きアクセスを有効にします。必要に応じて MFA を必須にしてください。アクセス レビューを使用してゲスト アクセスを検証し、不要になったアクセスは削除します。判断内容は、組織のガバナンス プロセスにおけるアクセス レビューの記録として文書化してください。レビュー担当者への連絡にはアクセス レビューへのリンクを含め、アクセス パネルも併せて案内すると、レビュー作業が簡単になります。

アクセス レビューでは、ゲスト アクセスとアプリケーション アクセスを含む Microsoft 365 グループの両方を扱えますか?

はい。Microsoft Entra アクセス レビューは、グループのアクセス レビューと、グループまたはアプリケーションへのアクセスのレビューに対応しています。Microsoft 365 グループ、ゲスト ユーザーを含むグループ、エンタープライズ アプリケーション (Microsoft Entra アクセスを使用するアプリケーション) を対象にすることができ、1 つのガバナンス ワークフローで、ゲスト ユーザーのメンバーシップとアプリケーションの割り当てを確認できます。

アクセス レビューの作成と実施について詳しく知り、手順を確認するにはどこを参照すればよいですか?

Microsoft Learn には、Microsoft Entra ID と Microsoft Entra アクセス レビューの使用方法に関するドキュメントとチュートリアルがあります。アクセス レビューの作成方法、ゲスト向けの定期的なアクセス レビューの構成、権限の管理との統合などが含まれます。手順を確認する際は、Microsoft Learn のガイダンスと、Microsoft 365 管理センターまたは Microsoft Entra 管理センターのヘルプ トピックを参照してください。