Microsoft Entra のサインインログで「実際の場所」と「表示される場所」がズレていると、なりすましや不正アクセスなのか、単なる位置情報の誤判定なのか判断が難しくなります。本記事では、タイの「サムットプラーカーン県プラプラデーン」の IP が「プーケット県プーケット」と誤表示されたケースを例に、Microsoft Entra での IP 位置情報の仕組みと、誤表示が発生した場合の具体的な対処方法・運用のベストプラクティスを詳しく解説します。
Microsoft Entra のサインインログで IP 位置情報がズレる理由
まず前提として、Microsoft Entra（旧 Azure AD）のサインインログに表示される「場所」は、IP アドレスそのものに含まれる情報ではなく、第三者の IP ジオロケーションデータベースを参照して推定されたものです。
そのため、実際の接続元がタイ・サムットプラーカーン県プラプラデーンであっても、データベースの登録情報が古かったり、ISP の再割り当てが反映されていなかったりすると、「プーケット県プーケット」といった別の地域として表示されることがあります。
IP ジオロケーションの基本的な仕組み
IP ジオロケーションは、次のような情報に基づいて「大まかな位置」を推定します。
- IP ブロックを保有している通信事業者（ISP）の情報
- ISP がその IP ブロックをどの地域に割り当てているかという登録情報
- 過去のアクセスログ・位置情報の統計データ
これらは国際的なレジストリや商用データベースで管理されますが、リアルタイムで常に最新というわけではありません。ISP が IP の割り当てを変更しても、ジオロケーションデータベースが更新されるまでタイムラグが発生します。
企業ネットワークで誤表示が起きやすいパターン
企業環境では、次のような要因が重なることで位置情報のズレが発生しやすくなります。
| 要因 | 内容 | 位置情報への影響 |
|---|---|---|
| キャリア NAT / 共有 IP | 複数ユーザーが同じグローバル IP を共有 | 他地域の利用状況に引きずられ、別の県・都市と判定される |
| ISP の IP 再割り当て | 以前は別地域で使われていた IP を新拠点で利用 | 旧拠点の地名がログに表示される |
| プロキシ / VPN 経由 | インターネットへの出口が別地域のデータセンター | 実際のユーザー所在地ではなく出口拠点の場所が表示される |
| モバイル回線 | 基地局やコアネットワークの設計に依存 | 県をまたいだ場所や、全く別都市の名前で表示される |
今回のように「サムットプラーカーン県プラプラデーン」が「プーケット県プーケット」と表示されるケースも、主にこうした要因と、ジオロケーションデータベース側の登録情報の誤り・遅延が原因です。
ケーススタディ：プラプラデーンの IP がプーケットとして表示された
実際に報告された事例では、タイの サムットプラーカーン県プラプラデーン に設置されている拠点からのサインインが、Microsoft Entra のサインイン監査ログ上では プーケット県プーケット として表示されていました。
この拠点では専用回線を利用しており、社内のネットワーク管理担当者は「この IP アドレスは確実にプラプラデーン拠点の出口である」と把握していました。そのため、ログ上の「プーケット」という表示は明らかに誤りであり、位置情報データベースの修正が必要な状態でした。
このような場合、管理者が自分たちだけで設定を変えても表示は修正されません。Microsoft およびその背後にいるジオロケーションプロバイダーに、正しい情報を伝えてデータを更新してもらう必要があります。
位置情報誤表示を修正する具体的な手順
位置情報の誤表示を修正するためには、大きく分けて次の 3 ステップで対応します。
- 必要な情報を整理して Microsoft サポートに共有する
- Microsoft エンジニアリングチームがジオロケーションデータベースを更新する
- サインインログで修正結果を確認し、必要に応じて再調査を依頼する
サポートに共有する情報の整理
まず最初に行うべきことは、サポートに伝えるべき情報を整理することです。以下の情報を「公開フォーラムではなく、プライベートなチャネル」で共有します。
| 項目 | 内容 | 具体例 |
|---|---|---|
| 公開 IP アドレス | 誤った位置で表示されているグローバル IP | 例：203.xxx.xxx.xxx |
| 誤って表示されている場所 | サインインログ上に表示されている住所・地域名 | 例：Phuket, Phuket, Thailand |
| 正しい場所 | 実際にその IP が設置されている拠点の場所 | 例：Phra Pradaeng, Samut Prakan, Thailand |
| Correlation ID | 該当サインインイベントの相関 ID | 例：00000000-0000-0000-0000-000000000000 |
| 発生日時 | 誤表示が確認された日時（タイムゾーンも含める） | 例：2025-01-15T09:30:00+07:00 |
これらの情報には IP アドレスなどの PII（個人情報）に該当しうる情報 が含まれるため、公開の技術フォーラムやコミュニティサイトにそのまま書き込むのは避け、サポート チケット や プライベートメッセージ で共有します。
サインインログから Correlation ID を取得する手順
Correlation ID は、Microsoft 側でログを特定する際に非常に重要なキーとなります。Microsoft Entra 管理センターから次のように取得できます。
- Microsoft Entra 管理センターにサインインする。
- 左メニューから [ID] → [サインイン] を開く。
- 問題の IP アドレスからのサインインイベントを一覧から選択する。
- 右側に表示される「詳細」ペインで、「相関 ID（Correlation ID）」 を確認する。
- サポートへの連絡用に、Correlation ID と タイムスタンプ をセットで控えておく。
Correlation ID と時刻がわかれば、Microsoft 側で対象イベントをピンポイントに追跡し、どのジオロケーション情報が参照されたのかを確認できます。
Microsoft エンジニアリングチームによる位置情報データベースの更新
必要な情報をサポートに伝えると、Microsoft のエンジニアリングチームが、バックエンドで使用しているジオロケーションプロバイダーに対して修正を依頼します。
一般的な流れは次の通りです。
- サポートが提供された IP、誤表示地点、正しい地点、Correlation ID をもとに内部調査を実施
- ジオロケーションプロバイダーへ「この IP ブロックの所在地を修正してほしい」というリクエストを送付
- プロバイダー側でデータベースが更新される
- Microsoft 側のキャッシュや各種サービスに新しいジオロケーションデータが反映される
環境によって差はありますが、通常は数日〜1 週間程度 で反映されるケースが多く、今回の事例では「週末までに反映予定」と案内され、その通りに修正が完了したと報告されています。
修正後の確認手順
ジオロケーションデータベースの更新が完了したあと、管理者側で確認すべきポイントは次の通りです。
- Microsoft Entra 管理センターの [サインイン] 画面を開く。
- 該当拠点（プラプラデーン）からのサインインをいくつか抽出する。
- 各イベントの「場所」欄が 「Phra Pradaeng, Samut Prakan」 と正しく表示されているか確認する。
- サインイン元 IP アドレスが複数ある場合は、それぞれが正しい県・都市で表示されているかをチェックする。
もし数日待っても表示が変わらない場合は、次のような追加確認を行い、再度サポートに連絡します。
| 確認項目 | 内容 | ポイント |
|---|---|---|
| ブラウザキャッシュ | ブラウザのキャッシュや Cookie をクリアして再表示 | 古い情報がキャッシュされている可能性を排除 |
| 別ブラウザ / 別端末 | 別のブラウザや PC から同じログを確認 | クライアント依存の表示問題かを切り分け |
| 時間をおいて再確認 | 24〜48 時間後に再度サインインログを確認 | バックエンドの反映遅延に備える |
| 新規サインインの確認 | 修正後に発生した新しいサインインイベントのみを確認 | 過去ログは古いジオロケーションが残っていることがある |
これらを踏まえても依然として誤表示が続く場合は、最新の Correlation ID と画面キャプチャ を添えて、サポートに「継続調査」を依頼しましょう。
IP ジオロケーションに依存しすぎない設計が重要
IP 位置情報は便利な指標ですが、前述のように「常に正確ではない」という前提を持っておく必要があります。特に、条件付きアクセスなどセキュリティポリシーの設計において、位置情報に依存しすぎると誤検知や業務影響を招きかねません。
条件付きアクセスで押さえるべき設計の考え方
Microsoft Entra の条件付きアクセスでは、「場所」を使ってアクセス制御を行うことができますが、以下のように設計するのがおすすめです。
| 観点 | 推奨アプローチ | 避けたい例 |
|---|---|---|
| 許可する拠点の定義 | 固定グローバル IP を 信頼済み場所（Named Location） として登録 | 「タイ国内」など、ジオロケーションだけで許可 |
| ブロック条件 | 既知の国・地域以外からのアクセスを「追加の MFA 要求」や「リスク高」として扱う | ジオロケーションで「県」「市」レベルまで厳密にブロック |
| リスクベース制御 | サインインのリスク判定やデバイス情報と併用して判断 | 位置情報だけで即座にブロックまたはアラート |
つまり、位置情報はあくまで「補助情報」として活用し、固定 IP アドレスやデバイスのコンプライアンス状態、MFA などと組み合わせて多層防御を構成する ことが重要です。
IP 範囲・信頼済み場所を活用した運用例
実務でよく取られる運用パターンの一例を紹介します。
- 各拠点・VPN ゲートウェイのグローバル IP を整理して一覧化
- それぞれを Microsoft Entra の 「名前付きの場所（Named locations）」 に登録
- 条件付きアクセスで「信頼済み場所からのアクセスは MFA 緩和」「それ以外は MFA 必須」などのルールを設定
- 拠点や ISP が変わった場合は、ネットワークチームから IP 変更情報を受け取り、Named Location を随時更新
このようにしておけば、ジオロケーションが多少ズレて表示されていても、IP アドレスベースで正しく制御 できるため、今回のような「県違い・都市違い」の影響を最小限に抑えられます。
監査ログで位置情報が怪しいと感じたときのチェックポイント
日々の監査ログを見ていると、「あれ、このユーザーは普段プラプラデーンにいるはずなのに、プーケットからサインインしている…？」といった違和感を覚えることがあります。そんなとき、いきなり不正アクセスと決めつけずに、次のような観点で確認しましょう。
| 確認ステップ | チェック内容 | 判断のポイント |
|---|---|---|
| IP アドレスの一致 | 普段の社内 IP と同じか/近いレンジかを確認 | IP が同じで場所だけ違うなら、ジオロケーション誤判定の可能性大 |
| デバイス情報 | ブラウザ、OS、登録デバイスなど | 普段と同じデバイスからのアクセスなら、位置情報のブレであることが多い |
| サインイン時間 | 勤務時間帯か、深夜・休日か | 勤務時間内であれば誤判定、深夜に見慣れない場所なら要注意 |
| MFA の結果 | MFA を通過しているか | 正しくユーザー自身が MFA を通過していれば、ジオロケーション誤判定の可能性が高い |
| ユーザーへのヒアリング | 実際に出張・移動していなかったか | 「出張していない」「移動していない」場合にのみ、不正アクセスの可能性を疑う |
これらを踏まえ、「IP・デバイスは既知だが、場所表示だけおかしい」という結論になれば、今回のように 位置情報データベースの修正依頼 を検討するとよいでしょう。
再発防止と継続的な運用のコツ
位置情報の誤表示は、一度修正しても、他の拠点や新しく追加された IP で再び発生する可能性があります。そのため、一度きりの対応で終わらせず、運用プロセスに組み込むこと が大切です。
ネットワーク構成変更時のチェックリスト
新拠点の開設や ISP の変更など、ネットワーク構成に変更が入ったときには、次のようなチェックリストを用意しておくと安心です。
| タイミング | 実施項目 | 目的 |
|---|---|---|
| 新拠点開設前 | 予定しているグローバル IP の把握と一覧への追記 | Named Location に追加できるよう、事前準備を行う |
| 開設直後 | テストユーザーでサインインし、ログの場所表示を確認 | 明らかな県・都市の誤表示がないか早期に把握 |
| 運用開始後 1〜2 週間 | 代表的なユーザーのサインインログを抽出して再確認 | ジオロケーションデータベースの遅延反映も含めて確認 |
| ISP 変更や IP 追加時 | 変更後の IP を Named Location に追加・更新 | 条件付きアクセスの制御が最新のネットワークに追随するようにする |
監査ログレビューの運用ルールを決める
加えて、監査ログをどのような頻度と粒度でレビューするかを、チーム内でルール化しておくとよいでしょう。例えば、次のようなイメージです。
- 毎日：高リスクサインイン、失敗したサインインのサマリ確認
- 毎週：特定の重要ユーザー（管理者・経営層）のサインインログを重点レビュー
- 毎月：全体的な傾向（新しい国・地域からのアクセスが増えていないか）を確認
この中で、「見慣れない国・地域」「普段と違う県・都市」でのアクセスを検知した場合は、まず IP とデバイスの一致を確認し、ジオロケーション誤判定かどうかを切り分ける という流れを定着させると、無駄なインシデント対応を減らしつつ、本当に危険なサインインを見逃さない運用につながります。
サポートへの問い合わせをスムーズにするためのコツ
Microsoft サポートへの問い合わせをスムーズに進めるためには、「最初から必要な情報を揃えておく」ことが重要です。ここでは、問い合わせ時にまとめておくと便利な情報を再度整理しておきます。
| カテゴリ | 必要な情報 | 備考 |
|---|---|---|
| 技術情報 | 対象 IP、Correlation ID、テナント名、ディレクトリ ID | スクリーンショットがあるとより正確に伝わる |
| 現象の概要 | 誤表示されている場所と、正しい場所 | 国・県・都市レベルで詳しく記載する |
| 再現性 | いつから発生しているか、常にそうなのか | 特定の期間だけか、常時誤表示なのかを明確にする |
| 影響範囲 | 問題の IP を利用している拠点数・ユーザー数 | 重要度・優先度を判断してもらう材料になる |
これらを一度テンプレート化しておけば、今後別の拠点でも同様の問題が起こった際に、短時間でサポート依頼を出せるようになります。
まとめ：IP 位置情報は「補助情報」として冷静に扱う
本記事では、Microsoft Entra のサインイン監査ログで、実際は サムットプラーカーン県プラプラデーン にあるはずの公開 IP が プーケット県プーケット と誤表示されるケースを例に、IP 位置情報の仕組みと具体的な対処方法を解説しました。
ポイントを改めて整理すると、次のようになります。
- サインインログの「場所」は第三者のジオロケーションデータベースに依存しており、常に正確とは限らない。
- 明らかな誤表示を見つけたら、公開 IP・誤表示地点・正しい地点・Correlation ID などを整理して、Microsoft サポートにプライベートチャネルで共有する。
- Microsoft エンジニアリングチームがジオロケーションプロバイダーに修正を依頼し、通常は数日〜1 週間ほどで反映される。
- 修正後はサインインログで正しい地名に変わっているか確認し、変わっていなければキャッシュクリア・別ブラウザでの確認・再問い合わせを行う。
- 条件付きアクセスやセキュリティ運用では、IP 位置情報に依存しすぎず、固定 IP や Named Location、MFA、デバイス状態などと組み合わせて多層防御を構成することが重要。
IP 位置情報は、ユーザーのサインインを俯瞰するうえで非常に役立つ指標ですが、「ログ上の場所 ＝ 実際の場所」とは限らない という前提さえ押さえておけば、誤表示に振り回されることなく、冷静にセキュリティ判断を下せるようになります。今回紹介したフローやチェックリストを、自社の運用プロセスに取り入れ、Microsoft Entra の監査ログをより安全かつ賢く活用していきましょう。
コメント