Microsoft Entra ID の条件付きアクセスで国/地域制限をしていると、IPの地理判定ズレで正しい国のユーザーまで誤ブロックされることがあります。原因切り分け、復旧手順、再発防止策を実務目線で解説します。
起きている現象：外部サイトは「インドネシア」、サインイン ログは「シンガポール」
条件付きアクセスの「国/地域制限（例：インドネシアからのみアクセス許可）」を長年問題なく運用していたのに、ある日突然、特定ユーザーだけ Microsoft 365（Exchange Online、SharePoint、OneDrive、Teams など）にアクセスできなくなるケースがあります。
よくある調査の流れは次のとおりです。
- ユーザー側：自宅回線で Microsoft 365 にサインインしようとするとブロックされる
- 外部の IP 位置情報サイト：送信元 IP は「インドネシア」判定
- Microsoft Entra のサインイン ログ：同じサインインの Location が「シンガポール」になっており、条件付きアクセスでブロック
このとき重要なのは、条件付きアクセスが最終的に参照するのは「外部サイトの判定」ではなく「Entra のサインイン ログ側で解決された Location 判定」という点です。外部サイトがインドネシアと言っていても、Entra がシンガポールと判断すれば、その判断でポリシー評価が行われます。
条件付きアクセスの「国/地域制限」は何を根拠に判定しているのか
条件付きアクセスの場所（Location）条件は、GPS のような端末の位置情報ではなく、基本的に サインイン時に観測されたグローバル IP アドレスをもとに国/地域を推定します。つまり「どこからアクセスしているか」は「どの IP から見えているか」で決まります。
ここでズレが起きる理由は単純で、IP アドレスと国/地域の対応表（ジオロケーション データ）がサービスごとに異なるためです。更新頻度や参照元が違えば、同じ IP でも国判定が一致しないことは珍しくありません。
| 比較対象 | 国/地域の判定に使われるもの | 一致しないことがある理由 |
|---|---|---|
| 外部の IP 位置情報サイト | 各社独自の IP ジオロケーション DB | 更新タイミングや情報源が異なり、再割り当て・事業者移転などに追従差が出る |
| Microsoft Entra のサインイン ログ / 条件付きアクセス | Microsoft 側の IP ジオロケーション マッピング | Microsoft の判断が最終評価に使われるため、外部サイトと一致する保証がない |
運用上は、「外部サイトの結果を“参考情報”として見る」のは有効ですが、ポリシーの成否を左右する最終判断はサインイン ログの Locationです。国/地域制限を使うなら、この前提を組み込んだ運用（監視と例外設計）が必要になります。
最初にやるべき切り分け：本当に同じ送信元 IP なのか
「外部サイトではインドネシアなのに、Entra ではシンガポール」というとき、まず疑うべきは “同じネットワークに見えて、実は違う経路で出ている”ケースです。誤判定の前に、下記の切り分けをしておくと調査が早くなります。
サインイン ログで確認するポイント
- IP アドレス：該当の失敗サインインで記録されている送信元 IP
- Location：国/地域の判定結果（例：Singapore）
- Conditional Access：どのポリシーでブロックされたか、条件が何だったか
- クライアント アプリ：ブラウザーか、デスクトップ アプリか（ルートが変わることがある）
ユーザー側で確認するポイント
- VPN / プロキシ / セキュア Web ゲートウェイを使っていないか（ブラウザー拡張も含む）
- テザリング（携帯回線）や別 ISP へ切り替わっていないか
- ルーター再起動後に IP が変わっていないか（動的 IP の場合）
- IPv6 優先環境で、外部サイトは IPv4 を見ているが、Entra は IPv6 を見ている…などのズレがないか
切り分けの結論として「サインイン ログ上の送信元 IP が、ユーザーが確認した IP と一致している」「VPN なども使っていない」のであれば、次に疑うのが Microsoft 側のジオロケーション マッピングのズレです。
原因として多い：Microsoft 側の IP ジオロケーション マッピングのズレ
今回のように、外部の IP 位置情報サイトではインドネシア判定なのに、Entra のサインイン ログではシンガポール判定になる場合、原因はほぼ次のいずれかに収束します。
- Microsoft 側の IP→国/地域マッピングが ISP の IP レンジ単位でズレている
- ISP の回線設計上、実際に国外（例：シンガポール）の出口 IP でインターネットに出ている（結果として Entra も国外判定）
多くの現場では前者、つまり Microsoft 側のジオロケーション修正が必要なケースが当たりやすいです。国/地域制限は “完璧な安全装置” ではなく、あくまで IP に紐づく推定情報を使うため、データの更新差や誤差がそのまま業務影響になります。
| 症状 | 条件付きアクセスの動き | 現場でよくある誤解 |
|---|---|---|
| 外部サイトは許可国判定 | 関係ない（外部サイトの判定は評価に使われない） | 「外部サイトが正しいなら通るはず」 |
| サインイン ログの Location が不一致 | その Location が評価に使われ、国/地域制限でブロックされる | 「ユーザーのいる場所が間違っている」 |
| 同じ ISP の一部ユーザーだけ発生 | IP レンジ単位の判定ズレが疑わしい | 「ユーザー端末の不具合」 |
ポイントは、ユーザーの端末側でできることが少ないということです。根本原因が IP ジオロケーションのズレであれば、対処の主戦場は Microsoft 側になります。
恒久対応：Microsoft サポートへ「IP ジオロケーション修正」を依頼する
恒久的に解決したい場合は、Microsoft サポートに調査を依頼し、該当 IP（または IP レンジ）の国/地域情報を修正してもらうのが王道です。コミュニティ経由のケースでも、最終的には内部でデータ更新のエスカレーションが必要になります。
調査をスムーズにするため、依頼時には次の情報を揃えて提示します。
| 提示する情報 | どこで確認するか | コツ / 注意点 |
|---|---|---|
| 失敗したサインインの Correlation ID | Entra 管理センターのサインイン ログ（詳細） | 同じ現象が複数回あれば、代表例を複数提示するとレンジ特定が早い |
| 日時（Timestamp） | サインイン ログのイベント時刻 | タイムゾーンも含めて明確にする（例：UTC か現地時刻か） |
| Tenant ID | Entra テナントの概要情報 | サポート側でログを引く鍵になる |
| 対象 IP（または IP レンジ） | サインイン ログの IP アドレス | 可能なら複数ユーザー/複数イベントからレンジとしてまとめる |
| 正しい想定位置と誤判定位置 | ISP の情報、契約地点、外部 IP 位置情報の参考など | 「期待：Indonesia / 現状：Singapore」のように明確に書く |
修正は即時反映とは限らず、反映まで数日〜数週間かかることがあります。特に IP レンジ規模や地域によっては更新サイクルの都合で時間が読みにくいため、業務影響がある場合は後述の暫定回避策を並行するのが現実的です。
サポート依頼文の例（そのまま貼れる形）
以下は、必要情報を漏れなく伝えるためのテンプレート例です。実際の値に置き換えて利用してください。
現象：
条件付きアクセスで「Indonesia からのみアクセス許可」を設定していますが、
特定ユーザーが自宅回線から Microsoft 365 にアクセスできません。
サインイン ログ：
* Timestamp：YYYY-MM-DD HH:MM (TZ)
* User：user@domain
* Result：Blocked by Conditional Access
* Location (Entra 判定)：Singapore
* IP Address：X.X.X.X
* Correlation ID：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
* Tenant ID：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
期待する位置情報：
* 正：Indonesia（契約回線/利用地点：xxxx）
* 誤：Singapore と判定される
お願い：
上記 IP（または該当 IP レンジ）のジオロケーション マッピングをご確認いただき、
国/地域判定の修正可否をご教示ください。暫定回避策：復旧まで業務影響を止める
恒久対応が「ジオロケーション修正」である一方、現実の運用では復旧までの数日〜数週間、業務を止めない工夫が必要です。国/地域制限のセキュリティ意図をなるべく崩さず、影響範囲を最小にする観点で選択肢を整理します。
| 暫定回避策 | メリット | 注意点 | 向いている状況 |
|---|---|---|---|
| 該当ユーザーを一時的にポリシーから除外 | 即効性が高い。設定も簡単 | 除外中は国制限の保護が外れるため、代替の強化（MFA等）が欲しい | 業務影響が大きく、まず復旧を優先したい |
| 誤判定されている IP（/32 など）を Named locations に登録し、例外として許可 | 国単位ではなく IP 単位で穴を最小化できる | 家庭回線の IP が変わると再発。レンジを広げすぎるとリスク増 | 対象 IP が比較的固定、または影響範囲が限定的 |
| 除外ユーザー向けに別ポリシーを作り「準拠デバイス必須＋MFA」などで補強 | 復旧とセキュリティのバランスを取りやすい | ポリシーが増え、優先度や競合の設計が必要 | 例外が一定期間続く見込みで、守りを落としたくない |
| 一時的に許可国/地域に「誤判定国」を追加 | 最も簡単 | 国単位で穴が大きい。推奨しづらい | 短時間の緊急対応（実施後すぐ戻す前提） |
おすすめは、「ユーザー除外」か「IP 単位の例外（Named locations）」でまず復旧し、同時に Microsoft へ修正依頼を出す運用です。除外する場合は、除外期間だけでも「MFA 必須」「準拠デバイス必須」など、別ポリシーで守りを作ると事故が起きにくくなります。
重要：条件付きアクセスは “Windows へのログオン” には適用されない
よく混同されますが、条件付きアクセスは基本的に Entra を経由したクラウド認証（トークン発行）に対して評価されます。つまり Microsoft 365 などのクラウド リソースへアクセスするときに効きます。
そのため、次のような状態は十分起こり得ます。
- PC には通常どおりログオンできる（Windows のサインインは通る）
- しかし Microsoft 365 へアクセスすると、条件付きアクセスの国/地域制限でブロックされる
| 操作 | 条件付きアクセスの対象 | 補足 |
|---|---|---|
| Windows 端末へのサインイン（PCログオン / 端末ロック解除） | 原則として対象外 | ローカルのログオン自体を国/地域でブロックする用途には使えない |
| Microsoft 365 などクラウド アプリへのサインイン | 対象 | サインイン ログに残り、Location 判定で国/地域制限が評価される |
| デバイスの登録/参加（登録や Entra 参加を求める操作） | 条件付きアクセスの「ユーザー アクション」で対象にできる場合がある | 「デバイス登録は MFA 必須にする」などの設計が可能 |
「PCログオンにも条件付きアクセスを効かせたい」という要件がある場合は、条件付きアクセスではなく、端末管理（Intune の準拠/構成）、Windows のローカル セキュリティ、認証方式（Windows Hello for Business など）を組み合わせて実現するのが一般的です。
確認方法：最終的にはサインイン ログが“正”になる
国/地域制限の誤ブロックを疑ったら、外部サイトをいくつも見比べるより、Entra のサインイン ログで Location と条件付きアクセス結果を確認するのが確実です。運用を安定させるためにも、チーム内で確認手順を標準化しておくと再発時に迷いません。
サインイン ログでの具体的な見方
- 該当ユーザーのサインイン（失敗）を開く
- 「Location」「IP address」を確認し、想定国と一致しているかを見る
- 「Conditional Access」タブで、どのポリシーでブロックされたか確認する
- 同じ ISP で複数ユーザーが発生していないか、IP の傾向を見てレンジを推定する
ここで Location が想定とズレている限り、国/地域制限を“外部サイトの結果”で押し切っても解決しません。サインイン ログの Location が直る（または例外設計を入れる）までは、同様の誤ブロックが起こり得ます。
再発しやすい設計ポイント：国制限だけに依存しない
国/地域の判定ズレはゼロにできません。だからこそ、国制限を使うなら「国だけで守る」のではなく、複数の条件を重ねて “誤判定しても致命傷になりにくい” 形にしておくと安定します。
| 防御レイヤー | 具体例 | 誤判定時の業務影響を下げる理由 |
|---|---|---|
| 準拠デバイス要件 | 「準拠デバイス（Intune 準拠）でのみアクセス許可」 | 国制限で例外を作っても、管理外端末からの不正利用を抑えやすい |
| MFA | 「高リスク操作や外部アクセスは MFA 必須」 | 国判定がズレても、認証強度を維持できる |
| リスクベース | リスクの高いサインインを追加検証/ブロック | 国制限の抜けを “挙動の怪しさ” で補完できる |
| 許可するネットワーク（Named locations） | 拠点回線や固定出口 IP を登録し「信頼できる場所」として扱う | 国判定より IP 範囲の方が安定するケースが多く、誤ブロックを減らせる |
現実的な落としどころとしては、次のような組み合わせが運用しやすいです。
- 全体：レガシー認証はブロック、基本は MFA を要求
- 重要アプリ：準拠デバイス必須（管理端末のみ許可）
- 国/地域制限：要件として必要な場合だけ追加し、例外（救済ルート）をあらかじめ設計
運用のコツ：例外と監視を“最初から”用意しておく
国/地域制限は、うまく動いているときほど「例外を作るのが怖い」設定になりがちです。しかし実際には、ジオロケーションのズレや ISP 側の変更は必ず起こるため、次のような運用部品を最初から用意しておくと事故対応が速くなります。
- 緊急用アカウント（ブレークグラス）：条件付きアクセスの対象外にしておく（厳重に保管・監査）
- 例外の作り方を決める：ユーザー除外、IP 例外、代替の強化ポリシー（MFA/準拠）をテンプレ化
- ログの確認ルール：Location・IP・Correlation ID を必ず記録する運用にする
- 変更時の検証：新規/変更ポリシーは小さく当て、問題がないことを確認してから拡大する
よくある質問
外部の IP 位置情報サイトはどれが正しいですか？
「正しさ」は用途で変わります。条件付きアクセスの評価においては、Entra のサインイン ログが示す Location が事実上の正解です。外部サイトは原因推定やサポート依頼時の補足材料としては有効ですが、外部サイトだけを根拠に運用判断すると誤ブロック/誤許可を招きます。
Named locations に IP を登録すれば、国/地域制限より安全ですか？
拠点回線のように出口 IP が固定されているなら、国判定より安定することが多いです。一方で家庭回線のように IP が頻繁に変わる環境では、運用負荷が上がります。用途に応じて「国で縛る」「IP で縛る」「端末で縛る」を使い分けるのが現実解です。
Microsoft に修正依頼を出したのに直りません
更新が反映されるまで時間がかかることがあります。また、特定の IP だけでなくレンジ単位での修正が必要な場合、対象範囲の確定に追加情報が求められることもあります。サインイン ログの事例（Correlation ID、時刻、IP）を追加で提示し、サポートと認識合わせを進めるのが近道です。
まとめ
Microsoft Entra ID の条件付きアクセスで国/地域制限を運用していると、IP ジオロケーションの判定ズレにより「許可したい国なのにブロック」されることがあります。最終判断はサインイン ログの Location で行われるため、ログで事実を押さえ、Microsoft へのジオロケーション修正依頼を恒久対応として進めるのが基本です。復旧までの間は、ユーザー除外や Named locations を使った最小限の例外で業務影響を抑えつつ、MFA・準拠デバイス・リスク評価などを組み合わせて誤判定に強い設計へ見直すと安定します。
コメント