Microsoft Entra 管理センターでデバイスを管理しようとしたのに、なぜか組織内の「特定の1台」へ飛ばされてしまう――。キャッシュ削除や別ブラウザーでも直らないと、原因の切り分けが難しくなります。本記事では実際の事例をもとに、症状の特徴、確認すべきポイント、復旧までの回避策、そしてサポートに渡すと調査が進みやすいHAR/録画の取り方を整理します。
現象：Entra 管理センターの「Manage」が別の1台へリダイレクトされる
今回のトラブルは、Microsoft Entra 管理センターのユーザー起点の導線からデバイス管理を行おうとした際に、意図した端末ではなく、組織内の特定の1台のデバイスに遷移してしまうというものです。ポイントは「常に同じ1台」に飛ぶこと、そして「別環境でも再現する」ことでした。
なお、Microsoft Entra 管理センターはMicrosoft Entra ID（旧 Azure Active Directory / Azure AD）を中心とした管理ポータルです。検索キーワードとしては「Entra ID」「Azure AD」「Intune」「デバイス 管理（Manage）」などで同じ事象に辿り着く方が多いため、本記事でも用語を併記しながら解説します。
発生した操作パス（ユーザー起点）
- Microsoft Entra 管理センター：Users > Devices > Properties > Manage
- Intune 管理センター：ユーザー経由でデバイスを管理する導線（ユーザーを開いてデバイスへ進むルート）
正常に動作した操作パス（デバイス起点）
- Intune 管理センター：Devices から対象デバイスを直接検索して開く
見た目としては「対象デバイスを開くためのリンクを踏んだのに、別のデバイス詳細ページに着地する」挙動です。エラー画面が出ないケースもあり、現場では「権限が足りないのか」「対象端末が重複登録されているのか」など、原因が散らばりやすいのが厄介な点です。
最初に押さえる：この症状は“クライアント依存”か“サービス側”か
ポータルの挙動がおかしいとき、まず疑うのはブラウザーのキャッシュ・Cookie・拡張機能などのクライアント要因です。しかし本件では、別ブラウザー・別管理者アカウントでも再現しており、ローカルキャッシュ起因ではなさそう、という判断材料が揃っていました。
| 確認項目 | 狙い | 結果の解釈（本件のようなケース） |
|---|---|---|
| 別ブラウザー（Edge/Chrome）で再現するか | ブラウザー固有のキャッシュ・拡張機能を排除 | 両方で再現するならクライアント要因の可能性が下がる |
| InPrivate/シークレットで再現するか | Cookie/ローカルストレージ影響を最小化 | 再現するなら「保存された状態」よりポータル処理の可能性が高い |
| 別端末（別PC）で再現するか | 端末固有のネットワーク/証明書/拡張を排除 | 再現するならユーザー環境よりサービス側の疑いが強い |
| 別管理者アカウントで再現するか | アカウント状態・権限・セッションの偏りを排除 | 再現するなら「特定ユーザーのセッション不整合」ではない可能性が高い |
| ユーザー起点だけ壊れて、デバイス起点は正常か | 導線（画面遷移）に依存する問題か確認 | 導線依存ならフロントエンド/ルーティング/パラメータ処理の不具合が疑わしい |
この表の最後の行が特に重要です。ユーザー起点の「Manage」だけが壊れている場合、端末データそのもの（登録情報、管理状態、権限）よりも、ポータル側のリンク生成や遷移ロジック、またはバックエンドが返す関連付け情報（ユーザーとデバイスの紐付け）の不整合が疑われます。
短時間で試せるクイックチェック（ただし深追いしない）
サービス側不具合が濃厚でも、初動として数分で潰せる項目はあります。ポイントは「やるのは良いが、ここで沼らない」ことです。
- 一度サインアウトして、同じ管理者でサインインし直す（セッション更新）
- InPrivate/シークレットで再現するか確認（保存状態の影響を切る）
- 拡張機能（広告ブロッカー等）を一時的に無効化して確認
- ユーザー起点の導線を諦め、すぐにデバイス起点で管理作業を続行する
この段階で直らない場合は、回避策で業務を止めず、証跡（HAR/録画）の採取へ進むのが最短です。
再現のしかたを言語化すると、サポートの調査が一気に早くなる
ポータル不具合は「何となくおかしい」だけだと再現できずに終わりがちです。サポートへエスカレーションする前に、誰が見ても同じ操作をできるレベルまで手順を文章化しておくと、内部調査に繋がりやすくなります。
再現手順（例）
- Microsoft Entra 管理センターに管理者でサインインする
- Users を開き、対象ユーザーを選択する
- Devices を開き、対象デバイス（例：PC-001）を選択する
- Properties を開き、Manage をクリックする
- 意図したデバイスではなく、特定の別デバイス（例：PC-999）に遷移する
正常系（比較用）
- Intune 管理センターに管理者でサインインする
- Devices > All devices から対象デバイス（PC-001）を検索する
- 検索結果からデバイスを直接開く
- デバイスの管理画面が正常に表示される
この「同じデバイスでも、入口（導線）によって挙動が変わる」という情報は、サービス側での原因箇所を絞る上で非常に強い材料になります。
なぜ“ポータル側の不具合”が濃厚だったのか
本件では、最終的にMicrosoft 側でバグとして起票・内部確認が行われ、2024年6月20日時点で問題が解消した（サービス側で修正された可能性）という結末になりました。質問者側でも数日後に自然復旧しており、運用側で何かを変更して直した、というより「待っているうちに直った」に近い挙動です。
この結末に照らすと、発生当時に“ポータル側の不具合”を疑えた理由は次のとおりです。
- 別ブラウザー・別管理者でも再現し、ローカルキャッシュや単一アカウントの問題に見えにくかった
- ユーザー起点の導線だけ壊れて、デバイス起点は正常だった（データ自体が破損しているなら両方で問題が出やすい）
- 常に同じ1台へ飛ぶという一貫性のある誤動作があり、偶発的なタイムアウトや一時的なセッション切れと異なる
- Entra/Intune の複数ポータルで似た挙動が見え、共通コンポーネントの問題が疑えた
「直前に Entra 経由で Remote Help を使ったのがきっかけに見えるが因果は不明」という点も興味深いポイントです。Remote Help はIntune と連携する運用が多く、画面上の操作がデバイスIDやユーザーIDをパラメータとして渡して遷移するため、もしポータル側のリンク生成・状態保持にバグがあると、特定の端末IDが誤って参照され続けるような症状が起こり得ます。ただし、これはあくまで現象からの推測であり、確定にはサーバー側ログが必要になります。
復旧までの現実的な回避策：ユーザー起点を避け、デバイスを直接開く
この種のポータル不具合は、テナント側で「確実に直すスイッチ」がないことが多く、業務を止めないためには回避策を先に確立するのが現実的です。本件で有効だったのは、質問者が実施していたとおり、Intune 管理センターで対象デバイスを直接開いて管理する方法でした。
手順：Intune 管理センターで対象デバイスを直接開く
- Intune 管理センターにサインインする
- Devices > All devices を開く
- 検索ボックスでデバイス名（例：PC-001）やシリアル、またはユーザー名で絞り込む
- 該当デバイスをクリックして詳細へ進む
- 必要な操作（同期、再起動、リモート操作、Remote Help 連携、構成プロファイル確認など）を実施する
「ユーザーから辿った方が早い」ケースは確かに多いのですが、導線が壊れているときは、All devices からの直アクセスが最短です。運用手順書にも「ユーザー起点のManageが不安定な場合は、All devices を優先する」という一文を入れておくと、ヘルプデスクの対応品質が安定します。
回避策が有効かを判断するチェック
| やりたいこと | ユーザー起点の導線 | デバイス起点（推奨） |
|---|---|---|
| 対象端末の管理画面を開く | Manageが別端末へ飛ぶ可能性 | All devices からの検索・直接オープン |
| 端末のコンプライアンス状態を確認 | 誤端末の状態を見てしまうリスク | 対象端末を直接開き「Compliance」等を確認 |
| リモート操作（同期/再起動/ワイプ等） | 誤端末に実行すると重大事故 | 端末名・シリアルを必ず確認してから実行 |
特にワイプや削除などの破壊的操作は、ポータルの誤遷移がある状態で行うべきではありません。必ずデバイス名・シリアル・最終チェックイン時刻などを照合し、誤操作を防いでください。
サポートへエスカレーションするなら、最初から“情報セット”を揃える
Microsoft 側で調査が必要になった場合、情報が足りないと「再現しない」「追加情報待ち」で止まりやすくなります。逆に、最初から調査に必要な材料を一式で渡すと、ポータルチーム側のログ追跡やデバッグが進みやすくなります。
| 項目 | 例 | なぜ必要か |
|---|---|---|
| 発生日時（タイムゾーン付き） | 2024年6月18日 10:15 JST | バックエンドログの検索範囲を特定するため |
| テナント情報 | Tenant ID（GUID） | Microsoft 側の環境特定に必須 |
| 操作した管理者のUPN | [email protected] | 監査/トレースで操作主体を紐付ける |
| 対象ユーザーのUPN | [email protected] | ユーザー起点導線の再現に必要 |
| 対象デバイス情報 | デバイス名、Azure AD Device ID、Intune Device ID | 誤遷移の「本来の行き先」を確定する |
| 誤遷移先デバイス情報 | 飛ばされる端末の同様のID | 「なぜその端末に固定されるのか」の鍵になる |
| 再現手順 | クリック順、画面名、メニュー階層 | ポータルチームが同じ導線を辿れるようにする |
| HAR トレース | Networkログ（再現直後に保存） | どのAPI呼び出しで誤ったIDが返っているか解析できる |
| スクリーンショット/録画 | クリック→リダイレクトが分かる動画 | 口頭説明よりも現象の理解が速い |
実際に本件でも、追加調査が必要な場合はHAR トレースとスクリーンショット／録画の提供が有効、という方向で話が進みました。ポータル不具合は、画面だけ見ても原因が分からないことが多く、Networkログがあるかどうかで調査の深さが変わります。
HAR トレースの採取方法（Edge / Chrome）
HAR（HTTP Archive）は、ブラウザーが行った通信の履歴を保存する形式です。Entra/Intune のようにフロントエンドがAPIを叩いて画面を構成するサービスでは、HARが最重要級の手がかりになります。
採取手順
- Edge または Chrome で対象ポータルを開く（可能なら InPrivate/シークレットを推奨）
- キーボードで
F12を押して開発者ツールを開く - Network タブを選択し、Preserve log（ログ保持）をオンにする
- 同じ画面で Disable cache（キャッシュ無効）をオンにする（開発者ツールを開いている間のみ有効）
- ログが溜まり過ぎている場合は「クリア」してから、問題の操作（Manageクリック→誤遷移）を再現する
- Networkログ一覧で右クリックし、Save all as HAR with content（コンテンツ込み）で保存する
- 保存したHARをサポートへ添付する（組織の手順に従い、必要に応じてマスキング）
採取時の注意点
- HARにはトークンやCookieなどの機微情報が含まれる可能性があります。社内のセキュリティ手順に従い、提出先と保管場所を明確にしてください。
- 可能なら、再現直前にログをクリアし、短時間の操作だけを記録すると解析がしやすくなります。
- 同じ操作を2回以上行った場合、どの試行が本命か分かるように、動画やメモで試行番号と時刻を残すと親切です。
スクリーンショット／録画で押さえるべきポイント
「クリックしたのに別端末に飛ぶ」は、文章だけだと誤解されやすい典型例です。録画は大げさに見えますが、ポータル不具合では最短ルートになることがあります。
- Manage を押す直前に、対象ユーザー名と対象デバイス名が表示されている状態を映す
- クリック後に遷移した画面で、誤遷移先のデバイス名が確認できるようにする
- 可能ならブラウザーのアドレスバーも映し、遷移先URLのパラメータが変わる瞬間を残す
- 個人情報が映る場合は、社内手順に従いモザイク処理や共有範囲の制限を行う
再発時の実務的な初動フロー
同じ症状が再発したときに、場当たり的にキャッシュ削除だけ繰り返すと時間が溶けます。再現性が高いポータル不具合ほど、初動を定型化しておくと強いです。
| ステップ | やること | 判断 | 次のアクション |
|---|---|---|---|
| 切り分け | 別ブラウザー/別端末/別管理者で再現確認 | 再現する | クライアント要因よりサービス/テナント要因を優先 |
| 回避 | Intune の All devices から対象端末を直接開く | 管理作業が継続できる | 業務を止めず、並行して原因調査へ |
| 証跡 | 再現手順の文章化、動画、HARを採取 | 材料が揃う | サポートケースを起票し、まとめて提出 |
| 監視 | 復旧後も数日間、同じ導線で再発しないか確認 | 再発なし | 運用手順に「回避策」と「証跡採取」を追記 |
結末：2024年6月20日時点で解消、数日後に自然復旧
今回のケースでは、Microsoft 側でバグとして起票・内部確認が行われ、2024年6月20日時点で問題が解消しました。質問者側でも数日後に自然復旧しているため、サービス側の修正（または段階的なロールアウト）で改善した可能性が高いと考えられます。
このタイプの不具合は、管理者側で設定変更をしていないのに突然直る（または突然再発する）ことがあるため、復旧した後も「原因が分からないまま終わる」ことが珍しくありません。だからこそ、発生時にHARや録画を取っておく価値があります。再発した場合に、前回との差分が追えるからです。
運用で再発ダメージを小さくするコツ
ポータル不具合はゼロにできません。ですが、運用を少し工夫すると“詰み”を避けられます。
ヘルプデスク向けに「安全な導線」を決めておく
- ユーザー起点の導線が不安定なときは、Intune の All devices を正とする
- 破壊的操作（ワイプ、削除など）は、端末名・シリアル照合を必須にする
- 誤遷移がある状態では、操作を急がず、まず回避策へ切り替える
「サポートに渡すテンプレ」を作っておく
前述の情報セットをテンプレ化しておくと、問い合わせ品質が安定します。例えば次のような項目をチケットフォームにしておくと便利です。
- 発生日時、再現頻度、再現手順
- 対象ユーザー/対象デバイス/誤遷移先デバイスの各ID
- HARファイル、録画（社内ルールに従う）
“直前にやったこと”はメモする（ただし因果は決めつけない）
本件では「Entra 経由で Remote Help を使った直後に起きたように見える」という状況がありました。こうした直前操作は有力なヒントになり得ますが、原因の決めつけは禁物です。メモとして残し、サポートへ渡すことで、Microsoft 側が関連コンポーネントを当たりやすくなります。
よくある質問
Q. キャッシュ削除やCookie削除はやる意味がありますか？
A. 初動としては有効です。ただし、本件のように「別ブラウザー・別管理者でも再現」「ユーザー起点だけ壊れてデバイス起点は正常」という条件が揃う場合、クライアント側で粘っても改善しないことが多いです。回避策（All devices から直接開く）で業務を継続しつつ、証跡採取へ進むのが現実的です。
Q. なぜ“特定の1台”に固定されてしまうのですか？
A. 断定はできませんが、ポータルが内部的に保持している状態（最後に参照したデバイスIDなど）や、ユーザーとデバイスの関連付けを返すAPIのキャッシュ/不整合、リンク生成の不具合などが考えられます。HARにより、どの通信のレスポンスで誤ったIDが出ているかを追える可能性があります。
Q. どうしてもユーザー起点で作業したいのですが…
A. 導線が壊れている間は、ユーザー起点に固執しない方が安全です。特にリモート操作系は誤端末に実行すると影響が大きいため、デバイス起点で対象端末の同一性を確認してから操作する運用に切り替えてください。
Q. 復旧した後にやっておくべきことは？
A. 再発時に備え、社内のナレッジに「症状」「回避策」「サポートに渡す情報（HAR/録画/ID一覧）」を残しておくのがおすすめです。自然復旧した場合でも、次回は別の導線で同様の症状が出る可能性があるため、手順として残すことが重要です。
コメント