条件付きアクセスでOffice 365をブロックするとoffice.comまで使えない原因と回避策

条件付きアクセスで「Office 365」をブロックしたら、office.com（Office Home）まで開けず、初回サインインや端末へのメール設定が詰まった――そんなケースは珍しくありません。原因と、office.comは通しつつTeamsやSharePoint/OneDriveを制御する現実的な設計を解説します。

現象：Office 365 をブロックしたのに、なぜ office.com まで使えなくなるのか

外部ユーザー向けのサブドメインアカウントなど、「メール（Exchange Online）と端末管理（Intune）だけ使わせたい」運用はよくあります。そこで次のように構成したところ、意図せず office.com / Office Home までブロックされ、初回サインイン導線が塞がってしまうことがあります。

• ライセンス：Microsoft 365 F3 を付与。ただしサービスプランを絞り、主に「Exchange Online」「Intune」だけを有効化
• 条件付きアクセス（Microsoft Entra 条件付きアクセス / 旧 Azure AD 条件付きアクセス）：クラウドアプリで「Office 365」をブロック
• 例外：ブロックポリシーから「Exchange Online」「Intune」を除外

この状態で起きやすい具体的な困りごとは次のとおりです。

• ユーザーが最初にアクセスする office.com でブロックされ、サインインが完了しない
• Office Home から案内しているセットアップ導線に入れず、初回セットアップが止まる
• 端末側でのメール設定（MAM/MDM の自動配布、アプリ初回起動時のサインイン）まで詰まる
• 「クラウドアプリ」で office.com や OfficeHome を検索しても見つからず、除外設定ができない

結論から言うと、これは「設定ミス」ではなく、条件付きアクセスのクラウドアプリ選択の仕様に起因することが多いです。

まず押さえる：ライセンス制御と条件付きアクセスは役割が違う

「Teams や SharePoint はライセンスを外しているから大丈夫」と考えがちですが、ライセンスと条件付きアクセスは役割が違います。両方を使い分けないと、今回のように入口（office.com）を塞いだり、逆に“見えてしまう”状態が残ったりします。

観点	ライセンス（サービスプラン）	条件付きアクセス（CA）
目的	使える機能を「契約・権利」として制御	サインイン／トークン発行を「条件付き」で制御
得意なこと	Teams/SharePoint/OneDrive の利用権限を外す	MFA必須、準拠デバイス必須、特定IPのみ許可など
苦手なこと	入口（ポータル）の表示やサインイン経路の細かい制御	スイートに内包されたポータルだけを単体で許可する
ありがちな落とし穴	「見えるが使えない」状態になり、問い合わせが増える	入口を塞いで初回サインイン・端末設定まで止めてしまう

つまり、外部ユーザーの運用では「ライセンスを絞る」だけでも、「CAで丸ごとブロック」だけでも不十分になりがちです。入口を通しつつ、不要な先を止める設計が必要になります。

原因：office.com は単独アプリではなく「Office 365 スイート」の一部

条件付きアクセスで選べる「クラウドアプリ」は、いわゆる“URL”や“画面”の単位ではなく、Microsoft 側が定義しているサービス（リソース）の単位でまとまっています。ここが最初のつまずきポイントです。

office.com（Office Home）は、ユーザー体験としては「ポータル」ですが、CAの世界では単独のクラウドアプリとして独立していません。多くの環境で、office.com の挙動は 「Office 365」スイート配下のサービスとして評価されます。

そのため、CAで「Office 365」をブロックすると、Office 365 スイートに含まれる範囲のアクセスがまとめて遮断され、office.com も巻き込まれてブロックされます。ブラウザーで office.com にアクセスした瞬間にブロックされるのは、動作としては“仕様どおり”です。

「アプリ ID をコピーして検索しても出てこない」理由

管理画面で表示される「アプリケーション（エンタープライズアプリ）」のアプリ ID と、条件付きアクセスの「クラウドアプリ」一覧は、同じ概念ではありません。クラウドアプリ一覧は、Microsoft が用意した事前定義（プリセット）が中心で、すべてのアプリIDが検索でヒットするわけではありません。

結果として、office.com や OfficeHome の識別子をそれらしく持ってきても、CAのクラウドアプリ選択で個別に見つからず、“Office 365 スイートの中の一部だけ例外”のような設定はできないケースが出てきます。

結論：Office 365 をブロックしたまま office.com だけ許可するのは難しい

今回の相談の核心はここです。

• 「Office 365」をブロックすると、その配下の office.com / Office Home もブロックされる
• office.com をクラウドアプリとして個別指定し、ブロック対象から除外する…という操作ができない

このため、Office 365 スイートをブロックしながら office.com だけをCAから除外するという発想は、現場ではうまくいかないことが多いです。やりたいこと（Teams/SharePoint/OneDriveを止めたい）は正しいのですが、実現手段として「Office 365 をブロック」が強すぎます。

最短の解決：ブロックポリシーから Office 365 スイートを外して入口を復旧する

まずユーザーが動けない状態（初回サインイン不可）を解消するには、入口である office.com を塞いでいる要因を取り除く必要があります。最もシンプルで再現性が高い手は、「Office 365 スイート」をブロック対象から外すことです。

実務でよくある変更は次のようになります。

項目	変更前	変更後
対象クラウドアプリ	Office 365	（Office 365 をブロック対象から除外）
アクション	アクセスをブロック	別ポリシーで必要なアプリだけ制御
結果	office.com も巻き込まれて停止	office.com でサインインでき、初回セットアップが進む

「Office 365 をブロックしないのは不安」という声もありますが、次の章で紹介するように、ブロックではなく“条件付きで許可”に寄せることで、入口を開けつつセキュリティ要件を保てます。

推奨設計：Office 365 は条件付きで許可し、不要サービスは個別に止める

office.com だけ通したいのに、Office 365 を丸ごとブロックすると破綻します。逆に、Office 365 を無条件に許可すると不安が残ります。そこで現実的な落としどころが、次の「分割統治」です。

• Office 365 スイート：ブロックではなく 条件付きで許可（MFA/準拠デバイス/場所制限など）
• Microsoft Teams：必要がなければ ブロック
• SharePoint Online（OneDrive 含む）：必要がなければ ブロック
• Exchange Online：利用させたいので 許可（必要に応じてMFAやデバイス条件を付ける）
• Intune：端末登録・管理に必要なので 許可（登録に必要な関連アプリも含め要確認）

ポイントは、office.com は“入口”であり、そこから先（Teams や SharePoint など）に遷移した時点で、遷移先アプリに対して別の条件付きアクセス評価がかかることです。入口は開け、不要な行き先を閉じれば、ユーザー体験とセキュリティの両立がしやすくなります。

サンプル：外部ユーザー用の CA ポリシー設計例

以下は、外部ユーザー用サブドメインアカウント（メール＋端末管理だけ）を想定したポリシー例です。環境によってアプリ名表記が多少異なることがありますが、考え方は共通です。

ポリシー名（例）	対象ユーザー	対象クラウドアプリ	制御内容	狙い
外部ユーザー：Office 365 条件付き許可	外部ユーザー用グループ	Office 365	許可 + MFA必須（必要に応じて準拠デバイス必須）	office.com を含む入口を通しつつ強固にする
外部ユーザー：Teams ブロック	外部ユーザー用グループ	Microsoft Teams	アクセスをブロック	Teams を使わせない
外部ユーザー：SharePoint/OneDrive ブロック	外部ユーザー用グループ	SharePoint Online（OneDrive 含む）	アクセスをブロック	OneDrive/SharePoint を使わせない
外部ユーザー：Exchange Online 条件付き許可	外部ユーザー用グループ	Exchange Online	許可 + MFA必須、必要ならアプリ保護ポリシー連携	メールは安全に使わせる
外部ユーザー：Intune 登録と管理を許可	外部ユーザー用グループ	Intune 関連	許可（登録時の条件は慎重に）	端末登録が詰まらないようにする

「Office 365 を条件付き許可」しつつも、Teams/SharePoint を別ポリシーでブロックすれば、ユーザーは office.com にサインインできる一方で、不要なサービスは起動できません。運用が落ち着いてきたら、Office 365 側の条件（準拠デバイス、特定IP、利用時間帯など）を徐々に厳しくしていくと、安全性を上げやすいです。

実装手順：ポリシーを作るときの具体的な進め方

ここでは「まず止血し、次に安全に制御する」順番で、実装の流れを具体化します。管理者の操作画面は環境で多少変わりますが、考え方は同じです。

入口復旧：Office 365 のブロックを解除する

1. Microsoft Entra 管理センターで「条件付きアクセス」へ移動
2. 該当のブロックポリシーを開き、対象クラウドアプリが「Office 365」になっているか確認
3. 外部ユーザーに影響する場合は、ポリシーを一時的に「オフ」または「対象ユーザーから外部ユーザー用グループを除外」
4. 最終的に、Office 365 をブロック対象から外す
5. 外部ユーザーで office.com にサインインできることを確認

この段階で「サインインできる」状態を作ります。ここで慌てて“完全に無条件許可”にするのではなく、次の手順で条件付き許可へ移行します。

安全にする：Office 365 を条件付き許可へ

1. 新規でポリシーを作成し、対象ユーザーを「外部ユーザー用グループ」に限定
2. 対象クラウドアプリを「Office 365」に設定
3. 条件を追加（例：場所、デバイスプラットフォーム、クライアントアプリなど）
4. アクセス制御（Grant）で「アクセスを許可」を選び、MFA を必須にする
5. 必要に応じて「準拠デバイスを必須」「ハイブリッド参加を必須」などを追加
6. まずは「レポートのみ（Report-only）」でログを確認し、問題がないことを見てから有効化

外部ユーザーは利用環境が多様なので、いきなり厳しい条件（準拠デバイス必須など）にすると、登録や移行で詰まりがちです。レポートのみ→段階的に強化、が運用上の事故を減らします。

不要サービスを止める：Teams と SharePoint/OneDrive のブロック

1. 同じく外部ユーザー用グループを対象にしたブロックポリシーを作成
2. クラウドアプリで「Microsoft Teams」を選択し、アクセスをブロック
3. 別のポリシーで「SharePoint Online（OneDrive を含む範囲）」を選択し、アクセスをブロック
4. office.com にはサインインできるが、Teams/SharePoint へ遷移するとブロックされることを確認

OneDrive は多くの環境で SharePoint と同じクラウドアプリ範囲に含まれます。OneDrive だけ個別に止めたい／許可したい場合は、テナントの構成やアプリ選択の表示に合わせて調整してください。

メールと端末管理を成立させるための実務ポイント

「Exchange Online と Intune は除外したから大丈夫」と思っても、実運用では別のところで詰まりがちです。外部ユーザー用に“絞った運用”を成立させるためのチェックポイントをまとめます。

Exchange Online を使わせるなら、クライアント種別の扱いを決める

メール利用の形は組織によってさまざまです。Outlook（PC）、Outlook mobile、ネイティブメール、ブラウザー（Outlook on the web）など、どのクライアントを許可するかで、CAの条件が変わります。

利用形態	メリット	注意点	CAの例
Outlook on the web	端末依存が少ない	共有端末での利用ルールが必要	MFA必須 + 信頼済みIPのみ
Outlook mobile	MAM でデータ保護しやすい	アプリ保護ポリシーの設計が必要	承認済みアプリ必須 + アプリ保護必須
PC Outlook	業務互換性が高い	準拠デバイス要求と相性が良い	準拠デバイス必須 + MFA

外部ユーザーは“会社支給端末ではない”ことも多いため、Outlook mobile + MAM（アプリ保護）を軸にする、あるいはブラウザー限定にするなど、運用方針を決めたうえでCAを組むとブレません。

Intune は「登録フェーズ」と「利用フェーズ」を分けて考える

端末管理を Intune でやる場合、登録時にはサインインが必要です。登録までの導線が塞がれると、準拠デバイス必須などの条件を満たせず、鶏と卵の状態になりがちです。

• 登録前：まだ準拠デバイスではない（条件を厳しくすると登録できない）
• 登録後：準拠デバイスにできる（条件を厳しくしても運用可能）

よくある進め方は、登録に必要な範囲は“緩めに許可”し、登録完了後に“厳しくする”二段階です。たとえば、登録・初回セットアップに必要なクラウドアプリ（Intune 関連）には一時的に例外を設け、登録が完了したら例外を縮小します。

「office.com だけ許可できない」状況で、目的を達成する設計パターン

ここまでの内容を踏まえると、狙い（Teams/SharePoint/OneDrive をブロックしつつ、メールと端末管理は許可）は、次の3つのレイヤーを組み合わせると実現しやすいです。

レイヤー	主な手段	役割
入口	Office 365 を条件付きで許可	office.com を含むサインイン導線を確保しつつ、MFA等で強化
行き先	Teams / SharePoint Online を個別ブロック	不要サービスを確実に停止
権利	ライセンスのサービスプランを絞る	“万一入れたとしても使えない”状態を作り、被害を小さくする

「入口（office.com）を塞がない」ことが最優先です。入口が塞がると、ユーザーは“何をどうすればいいか分からない”状態になり、サポート工数が跳ね上がります。入口を確保したうえで、行き先を止め、権利も絞る。これが安定しやすい順序です。

運用で差が出る：ログ確認と例外設計

条件付きアクセスは「作って終わり」ではなく、ログと例外設計で安定度が大きく変わります。特に外部ユーザーは、場所・端末・ネットワークが一定ではないため、想定外のブロックが起きやすいです。

まず見るべきはサインインログ

ブロックの原因が「どのポリシー」「どのクラウドアプリ判定」で起きているかは、サインインログが最短ルートです。office.com にアクセスしたつもりでも、裏側では Office 365 として評価されている、といった “判定のズレ” が見えます。

What If を使って事前検証する

本番ユーザーに影響を出す前に、条件付きアクセスの What If（評価シミュレーション）で「このユーザーがこのアプリにサインインしたら、どのポリシーが適用されるか」を確認すると、切り戻しの手戻りが減ります。

例外アカウントは必ず用意する

管理者が自分で自分を締め出す事故は現実に起きます。外部ユーザー運用とはいえ、緊急時に復旧できるよう、管理者のブレークグラスアカウント（強力なパスワード、MFA設定、CA除外など）は基本として押さえてください。

よくある落とし穴と回避策

最後に、今回のテーマと親和性が高い「ハマりどころ」をまとめます。該当するものがある場合、設計を見直すだけで問い合わせが激減することがあります。

症状	よくある原因	回避策
office.com でサインイン直後にブロック	Office 365 をブロックしている	Office 365 は条件付き許可へ。不要サービスは個別ブロック
Outlook mobile だけ使わせたいのに PC Outlook も通る	クライアントアプリ条件を使っていない	クライアントアプリ条件でブラウザー/モバイル/デスクトップを分ける
準拠デバイス必須にしたら登録ができない	登録前に準拠条件を要求している	登録フェーズ用の例外（短期間・限定範囲）を設計する
SharePoint を止めたら添付ファイルの扱いで混乱	OneDrive 連携が前提の業務フローがある	業務要件を棚卸しし、必要なら限定許可（サイト単位の権限）へ

まとめ：Office 365 を丸ごとブロックする前に、入口と行き先を分けて考える

今回の問題は「Office 365 をブロックしたら office.com も止まった」という現象に見えますが、本質はoffice.com が単独アプリではなく Office 365 スイートに含まれるため、スイートを止めると入口も一緒に止まる点にあります。

外部ユーザーに「Exchange Online と Intune だけ」を使わせたい場合でも、入口（office.com）を塞ぐと初回サインインや端末設定が破綻します。そこで、次の設計に切り替えるのが現実的です。

• Office 365 は「ブロック」ではなく 条件付きで許可（MFA、場所、準拠デバイスなど）
• Teams / SharePoint / OneDrive は 個別にブロック
• ライセンスのサービスプランも絞り、二重で事故を防ぐ

この形にすると、office.com を使った初回サインインやセットアップを成立させつつ、不要なサービスへのアクセスは確実に止められます。結果として、セキュリティと運用の両方が安定しやすくなります。