M365Con 2027 – 無料オンラインカンファレンス · 11–22 Jan 2027 · 120 sessions→ m365con.net

ブログ · Mirko Peters

Microsoft Entra の ゲスト ユーザー向け条件付きアクセス

By · · Updated

Microsoft Entra ID のゲスト向け条件付きアクセスで、ID、デバイス、場所、リスクベースの制御と除外設定を組み合わせて外部ユーザーを保護します。

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

▶ BLOGConditional Access forGuest Users in Microso……M365.FM
Titelbild: Conditional Access for Guest Users in Microsoft Entra

クイック回答: 外部ユーザーを保護するには、Microsoft Entra ID でゲスト向けの条件付きアクセスを作成し、ゲストと外部ユーザーのアカウントを対象にして、適切な認証とデバイスの制御を必須にします。また、緊急アクセス用アカウントは除外してください。まずはレポート専用モードで開始し、実際のコラボレーションの流れを検証したうえで、文書化されたサポート体制のもとで段階的に展開します。

条件付きアクセスは、組織のデジタルの扉を守る最前線です。特にゲストや外部ユーザーを対象とする Microsoft Entra ID(旧 Azure AD)では、その役割が重要になります。ハイブリッドワークやクラウド優先のコラボレーションが広がるなかで、社外の人を招き入れることは日常の業務になりました。しかし、善意で始めた共有でも、ゲストアクセスの管理が甘いと、大きなセキュリティリスクにつながりかねません。このガイドでは、IT 担当者やセキュリティ担当者が、エンドユーザーや取引先に過度な負担をかけずにゲストアクセスを適切に制限するために必要な知識を整理します。

条件付きアクセスを使って、Microsoft 365、Teams、SharePoint、および接続済みアプリを安全に保ちつつ、ゲストによるコラボレーションを続ける方法を解説します。ポリシーの構成、判断が難しいエッジケースへの対応、アクセスの安全な監視について、明確で実践的な手順を紹介します。日常的にアクセス管理を担当している方も、現在の設定を見直したい方も、強固なセキュリティとスムーズな業務のバランスを取るための戦略が得られるはずです。

条件付きアクセスとゲストコラボレーションの概要

Microsoft Entra ID の条件付きアクセスは、ユーザー、特にゲストがクラウドリソースへどのように、いつアクセスできるかを制御する門番の役割を果たします。「ゲストユーザー」とは、Teams、SharePoint などの Microsoft 365 プラットフォームで作業するために組織外から招待された人を指します。これらは「B2B ゲスト」と呼ばれ、無条件に信頼するのではなく、アクセスを適切に保護する必要があります。

ゲストとのコラボレーションは、社外パートナーが Teams 会議に参加する場合、ベンダーが共有ドキュメントにアクセスする場合、プロジェクトのために一時的に参加するユーザーがいる場合など、至る所で行われています。社員と異なり、ゲストは人事システムで管理されていないため、アカウントが残ったままになりやすく、リスクが生じます。そのため、ゲスト向けの条件付きアクセスのルールは、別のバランスで設計する必要があります。業務に支障が出ない程度に開放しつつ、トラブルを防ぐには十分に厳格であることが求められます。放置されたゲストに潜む危険性と、その管理方法について詳しく知りたい場合は、Microsoft 365 のゲストアカウントのリスクとライフサイクル戦略の概要をご覧ください。

ゲストアクセスのセキュリティモデルの概要

従来のセキュリティは、企業ネットワークを守ることを基本としていました。社内にいるユーザーは信頼され、社外のユーザーは信頼されない、という考え方です。しかし、ゲストやリモートアクセスの普及によって、こうした従来の境界は崩れています。現代のセキュリティは ID が中心です。サインインするたびに、そのユーザーが誰であるかを正確に把握し、必要に応じて本人であることを証明させることが重要です。

この ID 中心のモデルにより、ポリシーをはるかに細かく設定できるようになります。ここで登場するのが「ゼロトラスト」です。これは信頼を前提とせず、あらゆる段階で常に検証を行うモデルです。広範な社内アクセスを許可する代わりに、条件付きアクセス、リスクスコア、ジャストインタイムのアクセス許可を活用して、ゲストのアクセスを最小限かつ管理された状態に保てます。この考え方の転換については、Microsoft 365 および Dynamics 365 を対象とした「Zero Trust by Design」の解説記事で詳しく説明しています。新しいモデルへの移行は柔軟なセキュリティをもたらしますが、同時に複雑さも増し、特にアプリやユーザーの役割が変わるたびにルールを最新の状態に保つことが課題となります。

Entra ID でのゲストアクセス向け条件付きポリシーの構成

ゲスト向けの条件付きアクセスを設定する段階では、Entra ID が外部ユーザーや B2B ユーザー向けにポリシーを細かく調整するためのツールを提供しています。基本となるのは、「ゲスト」が実際に誰を指すのかを特定することです。ディレクトリの管理方法によっては、ゲストアカウントを直接対象にする場合もあれば、適切なグループ化やタグ付けによって対象を絞り込む場合もあります。ここを誤ると、必要なコラボレーションを妨げてしまうか、デジタルの裏口を開け放したままになってしまいます。

重要なのは、適切なユーザーを対象にし、重要なアプリを組み込むことです。Teams、SharePoint、Power Platform、さらには Power BI のような機密性の高いワークロードも対象になります。アプリ統合は一律には行えません。より緩いポリシーで十分なアプリもあれば、厳格に制限すべきアプリもあります。アプリ単位でスコープを設定すると、ゲストがどこにアクセスできるか、そしてアクセス先でどこまで操作できるかを細かく調整できます。

もう一つの課題は、新しいポリシーが業務プロセスやユーザー エクスペリエンスを妨げないようにすることです。特にサードパーティ製の統合やゲストが関わる重要なワークフローでは、厳しすぎるポリシーがかえって逆効果になることがあります。そのため、導入後も監視と調整を継続することが不可欠です。一貫性のないルールが増え続ける、いわゆる「アイデンティティ負債」を避けるためです。この問題については、Entra ID のセキュリティとポリシーの衛生管理について解説しているこのガイドで詳しく取り上げています。実践的な展開戦略、ベースライン設定、初日からの監視の組み込みについては、こちらの Conditional Access ポリシーの課題に関する概要をご覧ください。次のサブセクションでは、テンプレートを活用して時間を節約し、ミスを防ぎ、最初から業務ニーズに合ったポリシーを展開する方法を解説します。

ゲストポリシーを効率よく構成するためのテンプレート展開

  • 組み込みテンプレートから始める: Microsoft Entra ID には、ゲストコラボレーションや MFA の適用といった一般的なシナリオに対応した、あらかじめ用意された Conditional Access テンプレートが含まれています。実績のある安全な既定値を使うことで、すぐに導入を開始できます。
  • ニーズに合わせてカスタマイズする: 事前構成済みのテンプレートを、特定のアプリ(SharePoint へのアクセスのみを制限するなど)や秘密度の要件に合わせて調整します。テンプレートは万能ではありません。ゲストのシナリオに合わせて条件を編集してください。
  • 標準化して拡張する: テンプレートを展開すると、テナント全体で一貫したポリシーを適用できます。場当たり的に作成した個別のルールと比べて、トラブルシューティング、監査、ガバナンス目標との整合性の維持がはるかに容易になります。
  • ヒント:複製して適応させる: テンプレートを基にして、部門、サイト、アプリのグループごとの派生ポリシーを素早く作成できます。これにより、ポリシーの乱立を抑え、変化する業務ニーズにも対応できます。

機能維持のためにゲストおよび外部ユーザーをポリシーから除外する

どれほど綿密に計画された Conditional Access でも、例外は必要になります。ゲストが、すべてのセキュリティ要件を満たせない場合があるためです。特に、自動化されたシステム、サードパーティ製アプリ、または MFA などの特定の認証手順に対応していない統合が関わるシナリオで起こりがちです。ポリシーが厳しすぎると、重要なパートナーをロックアウトしたり、予期しないタイミングで業務ワークフローを停止させたりするおそれがあります。

そこで役立つのがポリシーの除外です。通常のアクセス要件をすべて満たしていなくても、特定のユーザー、アプリケーション、またはシステムのシナリオで、特定の機能が「問題なく動作する」必要がある場合に例外を設けられます。重要なのは、例外を設けるべき場面を見極めることと、セキュリティ上の不要な穴を開けないよう、その適用範囲を限定することです。

バランスをとることが重要です。外部共有の自動化やサードパーティのスムーズなサインインを可能にするには除外ルールが欠かせません。しかし、除外が多すぎたり、適切に監視されていなかったりすると、深刻な問題を招きかねません。除外をゲストのライフサイクル管理と結びつけ、「ゲストの乱立」を減らすための実践的なアドバイスが必要な場合は、Microsoft 365 のゲストリスク管理に関するこちらの解説をご覧ください。次のセクションでは、Microsoft Teams や SharePoint との相互運用、あるいは負荷を抑えた扱いが必要なレガシーアプリへの対応など、一般的な除外シナリオを取り上げます。

システムとアプリのシナリオにおける除外機能

  • Teams 会議への参加: ゲストが外部からの招待で Teams 会議に参加するだけの場合は、準拠デバイスまたは MFA を要求する Conditional Access ポリシーから除外します。これにより、意図しないロックアウトや会議の中断を防げます。
  • SharePoint での外部共有: ドキュメントのコラボレーションでは、自動共有をブロックしたり統合の失敗を引き起こしたりするフローやアプリ ID は、ポリシーから除外できます。全体に展開する前に、テスト用アカウントで検証してください。
  • サードパーティ製のSSOおよび自動化アプリ: シングルサインオン(SSO)やプロセス連携に使われる一部のアプリは、対話型の認証やMFAのプロンプトを完了できない場合があります。こうしたアプリは、重要な自動処理を動かし続けるために、厳格な適用のポリシーから除外する必要があります。
  • 露出の確認: 除外設定を確定する前に、アクセス許可の範囲と監査ログを再確認し、過剰なアクセスを許可していないことを確かめてください。ガバナンスのレビューは必須です。誤った安心感がもたらすリスクについては、こちらのTeamsガバナンスの解説と、アクセス制御におけるSharePointとDataverseの比較を扱ったこちらの記事をご覧ください。

認証コントロールによるゲストユーザー向け条件付きアクセスの強化

誰が入れるかを制御するだけでは不十分で、その人が本当に本人であることを証明させることも同じくらい重要です。ゲストユーザーに対して強固な認証コントロールを適用することで、不正アクセスを防ぎ、機密データが裏口から流出するのを防げます。多要素認証(MFA)とリスクベースのサインインポリシーは、攻撃者がゲストの資格情報を入手した場合でも攻撃を止めるための最も信頼できる手段です。

Teams、SharePoint、Power BIといった重要なアプリにアクセスする前に、すべてのゲストにMFAを必須とするポリシーを設定できます。さらに、最もリスクの高いアプリに限定して適用したり、ゲストが新しいデバイスや不審な場所からサインインしたときだけ適用したりすることも可能です。これにより、必要なときだけセキュリティを強化し、信頼できるユーザーに不要な手間をかけずに済みます。最新の条件付きアクセスでは、ユーザーのリスクスコアに基づいて発動させることもでき、行動や過去のインシデントからリスクがあると判断されたユーザーにだけ追加認証を求められます。

これらのコントロールは、ユーザー体験との両立が欠かせません。外部の人には確実に扉を閉ざしつつ、正当なゲストが締め出されてサポート窓口が混乱するほど厳しすぎない設定が求められます。ユーザーに負担をかけず、業務フローを壊さずにこのバランスを取るためのヒントは、こちらの、堅牢なM365セキュリティとユーザー体験に関するガイドをご覧ください。次のセクションでは、My Sign-Insアプリやその他のツールを使ってゲストのアクセスを監視し、調査する方法を説明します。

ゲストユーザーの監視に役立つMy Sign-Insアプリの活用

  • サインインアクティビティの確認: 管理者とエンドユーザーの両方が「My Sign-Ins」アプリを使うと、場所、デバイス、認証の種類を含むサインイン試行の詳細な履歴を確認できます。ゲストアクセスの不審なパターンを見つけるうえで特に役立ちます。
  • 不審なアクティビティの検出と報告: ゲストユーザーが見慣れない国からサインインしているなど、おかしな点があれば、管理者やゲスト本人がアプリから直接そのイベントにフラグを付けたり報告したりできます。これにより、より迅速な対応につながります。
  • セルフサービスによる修復の促進: ゲストがアクセスの問題で困っている場合や、資格情報が侵害された可能性がある場合は、My Sign-Insポータルを案内してください。IT部門への問い合わせが減り、業務を滞りなく進められます。
  • 詳細な調査と監査: 高度な調査やコンプライアンスのためには、こちらのアクティビティ監査ガイドで解説されているMicrosoft Purview監査を使用し、サービスをまたいだユーザー操作を追跡して、潜在的なリスクを検出してください。

ゲストの条件付きアクセスにおけるエンドユーザー体験の理解

ゲストユーザーが条件付きアクセスの下でサインインする過程は、ポリシーの設定がつまずきの原因にならなければスムーズに進みます。たとえば、ベンダーがTeamsの招待を受け取り、リンクをクリックすると、MFAを求める画面が表示されるとします。自社の設定をこれまで使ったことがない場合、認証アプリの登録、QRコードのスキャン、テキストメッセージによる確認などが必要になり、すぐに混乱してしまうことがあります。

一般的な画面には、ブランド化されたサインイン ポータル、第 2 認証要素を求める明確な案内、そして手順を平易な言葉で案内するメッセージなどがあります。アクセスが拒否された場合、ゲストは通常、「組織のセキュリティ要件を満たしていません」や「デバイスのコンプライアンスが必要です」といった詳細な理由を目にします。難解な IT 用語ではありません。ただし、エラー メッセージがカスタマイズされておらず分かりやすくなければ、ヘルプデスクへの問い合わせがすぐに増えてしまいます。

管理者は、混乱や不便が生じそうな箇所をあらかじめ想定しておく必要があります。アクセスをブロックする場合(たとえばデバイス要件を満たしていない場合や、より厳格な管理が適用されているアプリにアクセスしようとした場合)は、何が不足しているのか、次に何をすべきかを説明するメッセージを用意しましょう。ほかの環境に慣れているゲストにとっては、Microsoft のセキュリティ制御が新しく、負担に感じられることもあります。そのため、ドキュメントやオンボーディング ガイドを事前に提供しておくことが大切です。

My Sign-Ins アプリのようなツールを使えば、ゲストは自分のサインイン履歴を確認でき、問題を早期に発見できます。事前の周知も効果的です。「今後どのような画面が表示されるか」を伝える簡単なメールを送るだけでも、同じアクセスの問題が繰り返し発生するのを大幅に減らせます。このような体験全体を設計しておくことで、ゲストの生産性を維持しつつ、日常的なサポートの手間も削減できます。

ゲスト ポリシーの展開後の次のステップ、監視、フィードバック

ゲストに対する条件付きアクセスを有効にしたら、それで終わりではありません。むしろ、ここから本当の作業が始まります。展開後は、ユーザー エクスペリエンスとセキュリティの有効性の両方を注意深く確認し続ける必要があります。まずは、サインイン ログと利用パターンを確認しましょう。正当なゲストが大きな支障なくアクセスできているでしょうか。リスクのあるサインインの試行は、計画どおりにブロックされているでしょうか。

業務部門と外部パートナーの両方からフィードバックを集めましょう。ユーザーからの苦情や繰り返し発生するアクセス失敗は、ポリシーの調整が必要であることを示すサインかもしれません。Entra ID と Microsoft 365 の組み込みツールを使って、成功したログインと失敗したログインを監視し、ポリシーの適用範囲と照らし合わせてください。明確な警告なしにアクセスをブロックしてしまう、ポリシーの競合や意図しないルールの重複も忘れずに確認しましょう。条件付きアクセス ポリシーの監視戦略や信頼構築については、こちらのポリシーの信頼性に関する課題のリソースを参照してください。

継続的な監査は、単なるコンプライアンスのチェック項目ではありません。古くなったアカウントや過剰な権限を持つゲスト アカウントから生じる、徐々に高まるリスクを発見するための手段です。この監査とコンプライアンスのガイドで解説されている Microsoft Purview Audit などのソリューションを使った定期的な監査により、除外設定が今も妥当であり、制御が本来の位置からずれていないことを確認できます。

最後に、条件付きアクセスは生きたシステムです。脅威は変化し、コラボレーションのニーズも拡大します。ポリシーは定期的に見直し、改善していく必要があります。四半期ごとのレビューには、業務部門の関係者や IT 責任者にも参加してもらいましょう。これにより全員の認識が揃い、変化がどれほど速くても、ゲストのアクセスが生産的かつ安全に保たれます。

条件付きアクセスによるゲストのセキュリティに関するベスト プラクティスとリソースの概要

Microsoft Entra ID でのゲスト アクセスの管理は、「設定して放置する」ような作業ではありません。まずは適切な適用範囲を持つ、堅牢な条件付きアクセス ポリシーから始めましょう。そのうえでライフサイクル管理によって支えることが重要です。古いゲスト アカウントを放置するとセキュリティの穴になります。テンプレートを使って展開を標準化し、特に Teams、SharePoint、Power Platform との連携時には、ポリシーの除外設定を必ず検証してください。

サインイン ログ、ゲストのライフサイクル状態、監査レポートを定期的に確認しましょう。ポリシーのレビューを IT の運用サイクルに組み込み、最低でも四半期ごとに実施してください。ゲストに対する明確で分かりやすい案内は、混乱やサポートへの問い合わせを減らします。また、継続的なガバナンスの必要性も見過ごさないでください。条件付きアクセスのライフサイクル管理に関するこちらの詳細解説で取り上げられているとおり、規律あるポリシー更新と所有者の責任が、「アイデンティティの負債」を避けるための鍵となります。

トラブルシューティングや高度な監査、そして外部共有を堅牢に管理するためのロードマップについては、こちらのPurview 監査の操作ガイドや、SharePoint と OneDrive で危険な外部共有アクティビティを検出するためのフレームワークが参考になります。ゲストのライフサイクルについてお悩みでしたら、管理されていないゲストのリスクに関するガイドで、有効期限、レビュー、オフボーディングを実践的な手順とともに解説しています。

ポリシーを構築または調整する際は、ぜひ Microsoft の公式ドキュメントも活用してください。また、業務部門のステークホルダーとは常に密に連携してください。条件付きアクセスは、チームの実際の働き方とどれだけ整合しているかによって効果が決まります。優れたガバナンス、継続的な監視、そして変化に柔軟に対応する姿勢が、ゲストとのコラボレーションを強力かつ安全に保つための最良の味方となります。

あわせて聴いてほしいエピソード

ゲスト向け条件付きアクセスについて検討しているなら、以下のエピソードで、ID セキュリティ、ガバナンス、信頼性の高い Microsoft 365 運用に関する実践的な背景を確認できます。

これらのエピソードは、技術的な手順を、より広範な ID・ガバナンス戦略へとつなげる助けになります。


ゲスト向け条件付きアクセスを安全に展開するパターン

  1. どのゲストシナリオにアクセスを許可するかを定義します。Teams でのコラボレーション、SharePoint での共有、特定のアプリケーションなどが対象です。
  2. グループを作成するか、ゲストと外部ユーザーの割り当てを使用して、ポリシーの適用範囲を明確にします。
  3. まずレポート専用モードを使用し、ポリシーを適用する前にサインインの結果を確認します。
  4. 実際のゲストアカウントでテストします。招待の承諾、MFA、デバイスの条件、対象のアプリケーションへのアクセスを含めて確認してください。
  5. 除外設定を文書化し、緊急アクセス アカウントは通常のポリシーの適用対象外にしておきます。

現在の構成の詳細とポリシーの推奨事項については、Microsoft Learn の条件付きアクセスに関するガイダンスを参照してください。

よくある質問

すべてのゲストに MFA を求めるべきですか?

一般的なビジネスでのコラボレーションのシナリオでは、MFA を必須とすることが妥当な基準になります。ただし、具体的な制御内容は、リスク、契約上の要件、ゲストのアクセスレベルに応じて決めるべきです。

ポリシーをレポート専用モードで開始すべき理由は何ですか?

レポート専用モードでは、アクセスをブロックする前に想定外の影響を把握できます。これは、パートナー、顧客、その他の外部コラボレーターを対象とする場合に特に重要です。

🎧 あわせて聴いてほしいエピソード

最終レビュー: 2026年7月。条件付きアクセスのコントロールおよび Microsoft Entra の画面は頻繁に変更される可能性があります。

Entities in this article

Conditional Access Microsoft Entra ID Guest access SharePoint Microsoft Entra Hybrid work Zero Trust Microsoft 365 Power BI

Related articles

RSS