Microsoft Entra ID（旧 Azure AD）のサインインログに表示される「位置情報」は、ゼロトラスト時代の監視や条件付きアクセスの判断材料として欠かせません。しかし、IPジオロケーションの誤判定により、実際とは異なる都市が表示されてしまうことがあります。本記事では、こうした誤判定の原因とMicrosoftへの修正依頼方法、さらに運用面でのベストプラクティスを詳しく解説します。
Entra サインインログの位置情報が間違う理由
まず押さえておきたいのは、Microsoft Entra ID（旧 Azure AD）のサインインログに表示される「都市」「地域」は、IPアドレスそのものに紐づいた位置情報データベース（ジオロケーションDB）をもとに機械的に判定されているという点です。
たとえば、あるグローバルIPアドレス 4.42.55.230 が、Entra サインインログ上では「Atlanta, GA」と表示されていたにもかかわらず、実際は「Dallas, TX」の回線である――というケースが実際に発生しています。これは、ジオロケーションDB側に登録されている位置情報が誤っているだけで、必ずしも不正アクセスを意味するわけではありません。
IPジオロケーションとは何か
IPジオロケーションとは、グローバルIPアドレスから「国・地域・都市・緯度経度」などのおおよその物理位置を推定するための仕組みです。多くの場合、以下のような情報を使いながら、IPアドレスの割り当て先を推定しています。
- 各国レジストリ（ARIN、RIPE、APNIC など）に登録されているネットワーク情報
- ISPやクラウド事業者が公開しているルーティング情報
- ユーザーからのフィードバックや、トレンドデータ
- 測定用ノードからの遅延・経路情報
Entra ID もこのような外部のジオロケーションDBやAPIをバックエンドで参照し、サインインログの「位置情報」欄に都市名を表示しています。管理者がポータル上で直接編集しているわけではありません。
Entra ID が参照している情報のイメージ
Entra サインインログの位置情報に関係する代表的な要素を整理すると、下記のようになります。
| 項目 | 内容 | 誤判定との関係 |
|---|---|---|
| IPアドレス | クライアントから見えるグローバルIP（NAT/VPN出口含む） | ここが変わると都市も変わる。NATやVPNで「出口」が変わると位置情報も大きく変動 |
| ジオロケーションDB | IPアドレスに対し「国・都市・緯度経度」を紐づけたデータベース | 登録内容が古い・誤っていると、Entra 側の表示も誤る |
| サインインログ | サインイン発生時に、その時点のジオロケーション情報をもとに記録 | ジオロケーションDBが後から修正されても、既存ログは原則そのまま |
IPジオロケーション誤判定の典型パターン
ジオロケーションの誤判定は、特別な事象ではなく、次のような要因で頻繁に発生しえます。
- IPの割り当てが最近変更された
以前はジョージア州のデータセンターで使われていたIPレンジが、現在はテキサス州の拠点に再割り当てされているが、DBの更新が追いついていない、など。 - NAT／プロキシ／VPN 経由のアクセス
利用者は東京にいるが、VPN出口が大阪のデータセンターにあるため「Osaka」と表示される、など。 - Anycast・CDN・クラウド事業者経由
Anycast IP は世界の複数拠点で同じIPを使うため、単一の「都市」にひも付けることがそもそも難しい場合があります。 - モバイルキャリア回線・動的IP
モバイル回線では基地局やゲートウェイの位置で判定されることが多く、ユーザーの実際の滞在地とはズレることがあります。
そのため、Entra サインインログの「都市名」はあくまで補助的な情報ととらえ、IPアドレス自体・ASN（ISP）・デバイス・クライアントアプリなどと組み合わせて判断することが重要です。
実際の事例：Atlanta 表示の IP が Dallas として修正されたケース
冒頭で触れたように、グローバルIP 4.42.55.230 が Entra サインインログ上で「Atlanta, GA」と表示されていたにもかかわらず、実際には「Dallas, TX」の回線だった、という事例がありました。このケースでは、Microsoft に対してジオロケーション誤判定を報告し、バックエンドの地理データ更新を行ってもらうことで解消されています。
発生から修正までの流れ（概要）
- 管理者がサインインログを確認中に、固定回線の出口IPが Atlanta と表示されていることに気づく
- ISP情報や自社ネットワーク構成を確認した結果、該当IPは Dallas の拠点に割り当てられていることが判明
- テナントID・サインイン日時・スクリーンショットなどを添えて、Microsoft サポートにジオロケーション誤判定の修正依頼を実施
- Microsoft 側で IP 位置情報DB を確認し、「Dallas, Texas, US」となるように修正
- 修正以降に発生したサインインでは、サインインログの位置情報が「Dallas」として表示されることを確認
ポイントは、修正はあくまで Microsoft 側のバックエンド作業で行われるということと、修正が反映されるのは原則として「新しく記録されるサインインログ」からであるという点です。
なぜ過去のログは自動的に直らないのか
サインインログは、「その瞬間に解決された情報」をそのまま保存する設計になっているため、既に保存済みのログが後から一括で書き換えられることは基本的にありません。
- サインイン時点での IP → 位置情報 のマッピング結果がそのまま保存される
- ジオロケーションDBが後日修正されても、過去ログは原則としてそのまま
- よって、「ある時点を境に、同じIPでも異なる都市名が記録される」ことが起こりうる
過去ログを分析する際には、「この期間より前のデータは位置情報が誤っている可能性がある」といった前提条件を付けて解釈することが重要です。
ジオロケーション誤判定を修正する具体的な手順
ここからは、実務で使える形で「Entra サインインログの IP 位置情報が明らかにおかしい」と気づいたときの対処方法を整理します。
1. まずは情報を整理する（最重要ステップ）
Microsoft に修正を依頼する前に、「本当に誤判定なのか」「どのように誤っているのか」を客観的に説明できる材料をそろえておきましょう。以下の観点をまとめておくと、サポート側の解析がスムーズになります。
| 情報項目 | 具体例 | ポイント |
|---|---|---|
| 対象IPアドレス | 4.42.55.230 | 誤判定が疑われるIPを明示する。可能であれば /24 などのレンジ情報も |
| 現在の表示（誤） | Atlanta, GA, US | Entra サインインログのスクリーンショットを用意しておくと説得力が高い |
| 本来の所在地（正） | Dallas, TX, US | ISPの契約情報や社内ネットワーク図など、根拠が示せるとなお良い |
| 再現したサインインログ | サインイン日時、ユーザーUPN、テナントID など | 特定のサインインを例示すると、バックエンドでの調査がしやすい |
| 回線・ISP情報 | 〇〇 Communications 固定回線、企業拠点VPN出口 など | NAT/VPN出口なのか、動的IPなのかなど、IPの性質も併せて伝える |
この段階でできるだけ情報を整理しておくことで、「単なる誤解なのか」「本当にジオロケーションDBが誤っているのか」を自分達でもある程度切り分けられます。たとえば、モバイル回線やVPN出口であれば、都市がズレるのはある程度想定通りと言えるケースもあります。
2. Microsoft へジオロケーション誤判定を報告する
誤判定だと判断できたら、管理者サポートを通じて Microsoft に修正依頼を行います。主な窓口は次のとおりです。
- Azure ポータルからのサポートチケット（Entra ID / Azure AD）
- Microsoft 365 管理センターからのサポートリクエスト
- Microsoft Q&A や公式フォーラム（ただし確実性はサポートチケットに劣る）
Azure ポータルからの問い合わせイメージ
- Azure ポータルに管理者アカウントでサインイン
- 画面右上付近の「ヘルプとサポート」または「?」メニューから「サポート + トラブルシューティング」を開く
- 「新しいサポート要求」を選択し、問題の種類に「技術」を選ぶ
- サービスとして「Microsoft Entra ID（Azure Active Directory）」を選択
- カテゴリを「サインイン」「条件付きアクセス」「レポート」など、該当しそうなものに設定
- 説明欄に、前項で整理した情報（IP、誤表示の内容、正しい所在地、再現ログ、影響範囲など）を記載
このとき、あとで紹介する「連絡用テンプレート」をそのまま貼り付け、必要な箇所だけ置き換えると、説明漏れを防げます。
報告時のポイント
- 「不正アクセスが疑われる」という表現と「ジオロケーションが誤っている」という表現を明確に分ける
セキュリティインシデントとしての調査と、位置情報DBの修正依頼は別物です。落ち着いて状況を整理しましょう。 - ログのタイムゾーンを明示する
Entra サインインログは通常 UTC ベースで表示されますが、ローカル時間とずれるため、問い合わせ時に「UTC」と「ローカル」の両方を記載すると親切です。 - 影響を明確に伝える
たとえば「条件付きアクセスの『不明な場所からのサインイン』アラートで誤検知が多発している」など、運用上の問題点を添えると優先度を理解してもらいやすくなります。
3. 修正の反映を確認する
Microsoft 側で位置情報DBの更新が行われると、その後に記録される新しいサインインログから順次、正しい都市名が表示されるようになります。
確認時のポイントを、簡単にフローとして整理しておきます。
| ステップ | 確認内容 | チェックポイント |
|---|---|---|
| ① サポートからの連絡 | 「バックエンドで位置情報を更新した」「反映には時間がかかる」などの案内 | いつ頃までのサインインから修正が期待できるのか、目安を把握 |
| ② 新規サインインのテスト | 該当IPから意図的にサインインを発生させる | サインインログの位置情報が期待どおりの都市に変わっているか |
| ③ 条件付きアクセス・アラートの挙動確認 | 「不明な場所」「リスクの高いサインイン」などのルールが過剰に発火していないか | 誤検知が収束しているかどうかを数日レベルで観察 |
もし、十分時間が経っても表示が変わらない場合は、
- 問い合わせ番号（ケースID）を引用しつつ、再度 Microsoft に状況を共有する
- IPがその間に再割り当てされていないか、ISP側にも確認する
- 実は別の出口IPからアクセスしていないか、ネットワーク経路を再確認する
といった観点で再調査するとよいでしょう。
運用上のベストプラクティス：都市名に振り回されないために
ジオロケーション誤判定は、どれだけDBが改善されても完全には防げません。そのため、「誤判定をゼロにする」ことではなく、「誤差を前提にした運用にする」ことが現実的なゴールになります。
都市名ではなく IP 範囲／国・地域を基準にする
セキュリティ運用では、次のような方針が推奨されます。
- 「東京」「大阪」「Dallas」など都市名だけを条件にしてアクセス制御しない
- 企業の固定回線やVPN出口など、信頼できるIPレンジを明示的に登録する
- 高リスク国からのアクセスブロックなどは、都市ではなく国・地域で制御する
Entra ID では、これを実現する手段として「名前付きの場所（Named locations）」が提供されています。
「名前付きの場所」で企業IPを管理する
名前付きの場所は、
- IP範囲（CIDR）をグルーピングしたもの
- 国／地域単位で定義した場所
のいずれかを定義し、条件付きアクセスの中で「この場所からのサインインだけ許可」「この場所からは強制的に MFA」などのポリシーを設定できる機能です。
| 種類 | 例 | メリット | 注意点 |
|---|---|---|---|
| IP 範囲ベース | 本社固定回線 (203.0.113.0/24)、VPN出口 (198.51.100.10/32) など | ジオロケーション誤判定の影響を受けにくく、「社内」「社外」を明確に分けやすい | 固定IPでない回線（動的IP・モバイル回線）には向かない |
| 国／地域ベース | Japan, United States など | 「海外アクセスは原則ブロック」などのポリシーを簡単に設定可能 | 国内外に拠点がある場合、例外設定が多くなる可能性がある |
ジオロケーション誤判定に悩まされている場合、都市名ではなく「IP範囲」「国・地域」を条件にしたルールへ順次切り替えていくことをおすすめします。
サインインログの読み方：複数の指標を組み合わせる
位置情報はあくまで「サインインを評価する複数シグナルの1つ」です。以下のような情報を組み合わせて、総合的に正当性を判断すると誤検知を減らせます。
- IPアドレス／ASN（ISP） 同じISP・同じIPレンジからの継続的なアクセスであれば、都市名が多少ずれていても通常利用の可能性が高いと判断できます。
- デバイス情報 登録済みデバイス、Intune 管理下デバイスであるかどうか。
- クライアントアプリ・ブラウザ いつもと異なるクライアントや古いブラウザからのアクセスは要注意。
- ユーザーリスク・サインインリスク（Entra ID Protection） パスワードスプレーや漏洩資格情報など、他のリスクシグナルが連動していないか。
- MFAの有無 MFA が確実に実施されているかどうかで、リスク評価は大きく変わります。
たとえば、いつもの IP・いつものデバイス・いつものブラウザ・MFA 済みだが、ジオロケーションだけが「Atlanta」→「Dallas」に変わった程度であれば、それだけでインシデント扱いする必要は薄いと言えるでしょう。
IPの性質を把握しておく
ジオロケーション誤判定に過剰反応しないためには、自社で扱っているIPの性質を把握しておくことが有効です。代表的なパターンを整理します。
- NAT／プロキシ／VPN出口
多数のユーザーが同じ IP を共有してインターネットへ出る場合、そのIPに紐づく位置情報は「出口装置の場所」であり、ユーザー本人の実地とは一致しません。 - Anycast／CDN
グローバルサービスでは、同一IPが地域ごとに複数拠点へアナウンスされることもあります。この場合、単一の正解都市を定義すること自体が難しいケースがあります。 - 動的IP
ISPから一般家庭向けに配布される動的IPは、時間の経過とともに別地域のユーザーへ再割り当てされることがあります。ジオロケーションDBが追随していないと、以前の利用者の所在地が残ったままになる可能性があります。
こうした事情を理解したうえで、「このIPはそもそも位置情報が揺れやすい」とラベリングしておくだけでも、SOCやヘルプデスクの判断精度は大きく向上します。
SOC・ヘルプデスクへの社内告知
最後に、現場でアラート対応を行うチーム（SOC・CSIRT・ヘルプデスクなど）に対して、次の点を周知しておくと効果的です。
- Entra サインインログの「都市名」は、ジオロケーションDBの精度に依存する推定値であること
- 都市名だけに依存してインシデント扱いするのではなく、IPレンジ・デバイス・クライアント・MFA状況なども確認すること
- 明らかに誤判定と思われるケースが続く場合は、管理者にエスカレーションし、Microsoft への修正依頼を検討すること
このように、ジオロケーションの限界をチーム内で共有しておくことで、誤検知による過剰対応や、ユーザーへの不要な問い合わせを抑えることができます。
Microsoft への連絡用テンプレート（コピペ可）
実際にサポートチケットを起票する際に使える、雛形を用意しました。必要に応じてテナント名やIPなどを書き換えて利用してください。
件名：Entra サインインログのジオロケーション誤判定の修正依頼（IP: xxx.xxx.xxx.xxx）
【概要】
Microsoft Entra ID（旧 Azure AD）のサインインログにおいて、
以下IPアドレスの位置情報（都市名）が実際の所在地と異なって表示されているようです。
ジオロケーションDBのご確認および、必要に応じた修正をご検討いただけますでしょうか。
【対象IP】
・IPアドレス：xxx.xxx.xxx.xxx
【現在の表示（誤）】
・都市／州／国：＜例＞Atlanta, GA, US
【正しい所在地（正）】
・都市／州／国：＜例＞Dallas, TX, US
・根拠：ISP契約情報、社内ネットワーク図、現地拠点情報 等
【再現例（サインインログ）】
・サインイン日時（UTC）：yyyy-MM-dd HH:mm:ss
・サインイン日時（ローカル）：yyyy-MM-dd HH:mm:ss（タイムゾーン：Asia/Tokyo 等）
・ユーザー：[email protected]（サインインユーザーUPN）
・テナント名：xxxxxx
・テナントID：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
・ポータル画面のスクリーンショット：別途添付
【回線情報】
・回線種別：企業拠点固定回線／VPN出口／クラウド環境 等
・ISP名：xxxx Communications
・IP種別：固定IP／動的IP
・備考：NAT／プロキシ／Anycast 利用の有無 など
【影響・懸念】
・条件付きアクセスの「不明な場所からのサインイン」やアラートで誤検知している可能性があります。
・本IPアドレスは弊社の正規拠点からのアクセスであるため、
ジオロケーションDBの更新をご検討いただけますと幸いです。
以上、よろしくお願いいたします。
よくある質問（FAQ）
Q. 管理者側でサインインログの都市名を上書きできますか？
A. できません。 Entra サインインログの位置情報は、Microsoft側のジオロケーションDBをもとに表示されており、テナント管理者がポータルから直接編集する機能はありません。誤判定を修正したい場合は、本記事で紹介したように、Microsoft サポートへ修正依頼を行う必要があります。
運用面では、「名前付きの場所」でIPレンジを管理し、条件付きアクセスの判断を都市名ではなくIP／国・地域ベースで行うのが現実的な対策となります。
Q. ジオロケーションが修正されたら、過去のサインインログの都市名も自動的に直りますか？
A. 一般に直りません。 サインインログは、「サインイン発生時点での位置情報」をそのまま記録しているため、後からジオロケーションDBが更新されても、過去ログに遡って書き換えられることは通常ありません。
そのため、調査報告書やインシデントレポートを作成する際には、
- 「20xx年xx月xx日以前のログでは、IP xxx.xxx.xxx.xxx の位置情報が誤っている可能性がある」
- 「以降のログでは Microsoft により Dallas, TX に修正されている」
といった注記を添えると、将来の再分析や監査時に誤解を防ぎやすくなります。
Q. 自社で独自のジオロケーションDBを持ち込んで、Entra に反映させることはできますか？
A. 現時点ではできません。 Entra ID のサインインログに表示される位置情報は Microsoft 側の仕組みによって決まっており、テナントごとに別のDBを持ち込んだり、任意の都市名を設定したりすることはできません。
ただし、SIEM 製品（Microsoft Sentinel など）にログを送って独自分析する場合は、SIEM側で独自のジオロケーションDBを連携し、カスタムフィールドとして位置情報を再計算するといったアプローチも考えられます。この場合、Entra ポータルの画面表示は変わらないものの、SOC側の分析画面ではより正確な位置情報を使うことができます。
Q. ジオロケーション誤判定はどの程度の頻度で起こりますか？
これは IP の種類やISPによって大きく異なりますが、企業の固定回線やデータセンター向けIPでは比較的安定している一方、モバイル回線や動的IPでは位置情報が頻繁に変わることがあります。
特に、以下の条件に当てはまる場合は、位置情報の揺れを前提に設計しておくとよいでしょう。
- 社員がスマートフォンのモバイル回線からも頻繁にアクセスしている
- リモートワークで各家庭の回線（動的IP）からのアクセスが多い
- クラウドサービス上の仮想マシンから管理アクセスしている
まとめ：ジオロケーションの限界を理解し、運用でカバーする
本記事では、Entra サインインログにおける IP ジオロケーション誤判定の修正方法と、実務での付き合い方について解説しました。最後に、重要ポイントを整理します。
- Entra サインインログの位置情報は、Microsoft 側が参照するジオロケーションDBに依存しており、誤判定が発生しうる
- IP
4.42.55.230が「Atlanta」→「Dallas」に修正された事例のように、誤判定の修正は Microsoft 側の地理データ更新によって行われる - 修正後に記録される「新規サインインログ」から都市名が正しく表示されるのが一般的であり、過去ログは原則として書き換わらない
- サポート依頼時には、対象IP・誤表示・正しい所在地・再現ログ・回線情報・影響範囲を整理し、サポートチケットから Microsoft へ報告する
- 運用面では、都市名ではなく「名前付きの場所（IP範囲／国・地域）」を条件付きアクセスに活用し、ジオロケーション誤差の影響を最小化する
- サインイン評価は、「位置情報」だけでなく、IPレンジ・デバイス・クライアント・MFA・リスクシグナルを組み合わせて行う
- SOC やヘルプデスクには、位置情報があくまで推定値であることと、誤判定時は Microsoft に修正を依頼できることを周知する
ジオロケーションは便利な情報ですが、万能ではありません。限界と特徴を理解したうえで、Microsoft への修正依頼と、適切な条件付きアクセス設計、そして社内運用ルールを組み合わせることで、「誤判定に振り回されない Entra サインインログ活用」を実現していきましょう。
コメント