Microsoft Intuneの「Device Action: Locate Device – Microsoft Intune」は、紛失・盗難・置き忘れの可能性がある管理対象デバイスの位置を、Intune管理センターから確認するためのデバイスアクションです。管理者が最初に確認すべき結論は、対応プラットフォーム、位置情報の許可設定、RBAC権限、プライバシー説明、オフライン時の扱いの5点です。特にAndroid EnterpriseやWindowsでは事前設定が不足すると、ボタンが表示されても期待どおりに位置を取得できないことがあります。
2026年5月時点で確認できるMicrosoft Learnの当該情報では、英語版ページの最終更新表示は2026年4月6日、日本語版ページは2026年4月7日です。本記事では、公開中の公式情報をもとに、Microsoft IntuneのLocate Deviceを運用する管理者・開発者が確認すべき変更点、影響範囲、設定、展開時の注意点を整理します。(Microsoft Learn)
Device Action: Locate Device – Microsoft Intuneとは
Device Action: Locate Deviceは、Microsoft Intuneで管理しているデバイスに対して、管理者がリモートから「デバイスの検索」を実行する機能です。紛失、盗難、置き忘れが発生したときに、Intune管理センター上の地図でデバイスの位置を確認できます。Microsoftの説明では、複数拠点やモバイルユーザーが多い組織で、回収の迅速化やダウンタイム削減に役立つ機能として位置付けられています。(Microsoft Learn)
ただし、Locate Deviceは「どの端末でも常に追跡できる機能」ではありません。対象OS、登録方式、位置情報サービス、Intuneアプリ、Lost Mode、デバイス制限プロファイル、管理者権限など、複数の条件がそろって初めて実用的に使えます。
特に重要なのは、位置情報の取得がプライバシーに直結する点です。Intuneでは、通常のLocate Deviceアクションによる位置情報は管理者がアクションを開始したときに取得され、データは転送中・保存時に暗号化されます。取得した位置情報は24時間保存後に自動削除され、手動削除はサポートされません。(Microsoft Learn)
今回確認すべき変更点と実務上の影響
公式ページには旧版との差分表は掲載されていません。そのため、ここでいう変更点は「現行の公式ドキュメントで明確に確認すべき点」として整理します。管理者にとって大きいのは、単にLocate Deviceを実行する手順ではなく、事前に構成すべき設定と、位置情報データの扱いが具体的に示されていることです。
| 確認ポイント | 実務上の意味 | 対応すべき担当者 |
|---|---|---|
| 対応プラットフォームの明確化 | Android Enterprise、iOS/iPadOS、Windowsで条件が異なる | Intune管理者 |
| Android Enterpriseの構成要件 | デバイス制限プロファイルやユーザー許可が不足すると使えない | MDM設計担当 |
| Windowsの位置情報設定 | 設定カタログで位置情報アクセスを許可する必要がある | Windows端末管理者 |
| RBACとスコープタグ | 権限が足りないとアクションや対象ポリシーを扱えない | セキュリティ管理者 |
| 位置情報の保存期間 | 24時間保存、手動削除不可。Android専用端末の最後の既知の場所は最大7日 | 法務・情報セキュリティ担当 |
| Graph APIの利用 | locateDeviceはPOSTで実行し、成功時は204 No Content | 開発者・自動化担当 |
この機能の影響範囲は、ヘルプデスクだけに限定されません。運用ルールを決める情報システム部門、プライバシー説明を整備するセキュリティ・法務担当、Graph APIで自動化する開発者まで関係します。
対象プラットフォームと前提条件
Device Action: Locate Deviceは、公式情報ではAndroid Enterpriseの企業所有デバイス、監視モードのiOS/iPadOS、Windowsに対応しています。対象プラットフォームは広いものの、登録方式ごとに要件が異なるため、導入前に棚卸しが必要です。(Microsoft Learn)
| プラットフォーム | 主な対象 | 事前確認すべきこと |
|---|---|---|
| Android Enterprise 企業所有の専用デバイス（COSU） | キオスク端末、業務専用端末 | 明示的にブロックしていない限りLocate Deviceは既定で有効。オフライン時の最後の既知の場所も重要 |
| Android Enterprise 企業所有のフルマネージド（COBO） | 会社支給スマートフォン | デバイス制限プロファイルでLocate Deviceを明示的に有効化 |
| Android Enterprise 会社所有の仕事用プロファイル（COPE） | 会社支給だが仕事用・個人用領域を分ける端末 | デバイス制限プロファイルでの有効化に加え、ユーザーがIntuneアプリへ位置情報権限を付与 |
| iOS/iPadOS | 監視モードのAppleモバイルデバイス | 監視モード、Lost Mode関連の運用設計を確認 |
| Windows | Intune管理下のWindows端末 | 設定カタログでアプリの位置情報アクセスを強制許可 |
Android Enterpriseでは、位置情報サービスが有効であること、Intuneアプリがインストールされていることが要件として示されています。COPEでは、ユーザーがIntuneアプリに対して「常に許可」に相当する位置情報権限を付与する必要があります。(Microsoft Learn)
Windowsでは、設定カタログポリシーを作成し、カテゴリ「Privacy」の「Let Apps Access Location」を「Force allow」に設定して、対象デバイスを含むグループへ割り当てます。日本語UIでは「プライバシー」「アプリの場所へのアクセスを許可する」「強制許可」に相当します。(Microsoft Learn)
管理者が確認すべきRBAC権限
Locate Deviceを実行できるのは、必要なIntuneロールや権限を持つ管理者です。公式情報では、ヘルプデスクオペレーター、学校管理者、または必要な権限を含むカスタムロールが例示されています。カスタムロールでは、Remote tasks/Locate deviceや、管理対象デバイスを参照するための読み取り権限が必要です。(Microsoft Learn)
Androidデバイスでは、単にデバイスを表示できるだけでは不十分な場合があります。管理者は、デバイス構成の読み取り権限に加え、位置情報を有効にしているデバイス制限プロファイルまたは設定カタログポリシーをスコープタグで表示できる必要があります。(Microsoft Learn)
実務では、次のように権限を分けると安全です。
| 担当 | 推奨される権限設計 | 注意点 |
|---|---|---|
| 一次ヘルプデスク | 対象デバイスの参照とLocate Deviceの実行 | すべての端末を見せず、拠点・部門単位でスコープタグを分ける |
| セキュリティ担当 | 紛失・盗難対応時のLocate Device、Remote lock、Wipe判断 | Locate Device単独では情報漏えい対策にならない |
| Intune設計担当 | デバイス制限、設定カタログ、割り当ての変更 | 権限の過剰付与を避け、変更履歴を残す |
| 開発者・自動化担当 | Graph APIに必要な最小限の権限 | アプリケーション権限は影響範囲が広いため慎重に管理 |
ヘルプデスクに広い管理者権限を付けると、Locate Device以外の強力な操作まで可能になる恐れがあります。カスタムロールとスコープタグを使い、紛失対応に必要な範囲だけを許可する設計が現実的です。
Locate Deviceの実行手順
Locate Deviceは、Intune管理センターから対象デバイスを選んで実行します。公式手順では、Microsoft Intune管理センターで「デバイス」>「すべてのデバイス」を開き、対象デバイスを選択して、デバイス概要ペイン上部のアクションから「Locate device」を選びます。デバイスが見つかると、マップ上に位置が表示され、ピンを選択すると住所と座標を確認できます。(Microsoft Learn)
実行前に確認すべき流れは次のとおりです。
| 手順 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| 対象端末を特定 | ユーザー名、デバイス名、シリアル番号、最終チェックインを確認 | 同名端末や再登録済み端末を取り違える |
| 前提条件を確認 | 対応プラットフォーム、位置情報設定、Intuneアプリ、Lost Modeを確認 | OSや登録方式の違いを見落とす |
| 権限を確認 | Locate Device権限、デバイス読み取り権限、スコープタグを確認 | ボタンが見えない、実行できない |
| アクションを実行 | デバイス概要からLocate Deviceを選択 | オフライン端末では現在地を取得できない場合がある |
| 結果を記録 | 住所、座標、時刻、対応者、次の判断を記録 | 位置情報の保存期間に頼りすぎる |
紛失・盗難時は、Locate Deviceだけで完結させないことが重要です。端末の状態、データの機密性、盗難の可能性、ユーザーへの連絡可否を踏まえ、Remote lock、Lost Mode、Wipeなどの対応を組み合わせて判断します。
オフライン時の「最後の既知の場所」の扱い
Android Enterpriseの企業所有専用デバイス（COSU）では、デバイスが現在オンラインでなくても、7日以内にチェックインしていれば最後の既知の場所を表示できる場合があります。これは、端末がIntuneへチェックインしたときに送信したデータを利用する仕組みです。(Microsoft Learn)
公式情報では、Intuneは最後の既知の場所に関する情報を8時間ごと、またはデバイスがIntuneにチェックインしたときに収集し、最大7日間保持すると説明されています。7日を超えてチェックインしていないデバイスでは、最後の既知の場所を表示できません。(Microsoft Learn)
ここで注意したいのは、Device actions statusに表示される初期の「Complete」です。Android専用デバイスでは、最後の既知の場所機能をサポートするため、初期化によりLocate deviceの既定エントリが「Complete」と表示されることがあります。これは、管理者が実際にLocate Deviceを実行したことを意味しません。(Microsoft Learn)
監査や問い合わせ対応では、次のように切り分けて記録すると混乱を防げます。
| 表示・状態 | 意味 | 管理者の確認 |
|---|---|---|
| 初期状態のComplete | 機能初期化による既定ステータスの可能性 | 実行者・実行時刻と照合する |
| 管理者実行後のComplete | Locate Deviceアクションが実行された結果 | 対応チケットや監査ログに記録する |
| 最後の既知の場所 | 現在地ではなく過去のチェックイン時点の位置 | 位置情報の時刻を必ず確認する |
| 7日超の未チェックイン | 最後の既知の場所を表示できない可能性 | Wipeや回収不能時の手順へ進む |
「地図に表示されたから今そこにある」とは限りません。特にオフライン端末の最後の既知の場所は、現地確認やユーザー連絡の優先順位付けに使う情報であり、現在地の断定材料として扱わないほうが安全です。
セキュリティとプライバシーで押さえるべき点
Locate Deviceは便利な機能ですが、従業員や利用者の位置情報を扱うため、技術設定だけでなく運用ルールが不可欠です。公式情報では、通常のLocate Deviceアクションによる位置情報はアクション開始時にのみ収集され、緯度と経度はGraph API経由で取得されると説明されています。また、位置情報データは転送中・保存時に暗号化され、24時間保存後に自動削除されます。(Microsoft Learn)
一方で、Android Enterprise専用デバイスの最後の既知の場所は、最大7日間保持される場合があります。つまり、通常のLocate Deviceで取得される位置情報と、Android専用デバイスの最後の既知の場所では、保存の考え方が異なります。運用ポリシーではこの違いを明記しておくべきです。(Microsoft Learn)
ユーザー通知にも注意が必要です。Androidのフルマネージドおよび会社所有の仕事用プロファイルでは、Locate Deviceアクションが使われると、通知が有効な端末でユーザーに通知されます。また、Locate Deviceが許可された場合、ユーザーはIntuneが位置情報アクセス権限を使用できることを示す一度限りの通知を受け取ります。(Microsoft Learn)
社内ルールとしては、少なくとも次の項目を決めておきます。
| 項目 | 推奨ルール |
|---|---|
| 実行条件 | 紛失、盗難、業務端末の回収不能、セキュリティインシデントなどに限定 |
| 承認フロー | 通常はチケット起票、緊急時は事後承認を許可 |
| 記録内容 | 実行者、対象端末、理由、時刻、結果、次の対応 |
| ユーザー説明 | 端末管理規程や貸与端末同意書に位置情報利用の目的を記載 |
| データ保持 | Intune上の保持期間に加え、チケットや監査記録側の保存期間を定義 |
| 権限レビュー | ヘルプデスク異動・退職時にLocate Device権限を棚卸し |
プライバシー面で失敗しやすいのは、「会社所有端末だから自由に位置を見てよい」と考えてしまうことです。業務上必要な範囲に限定し、誰が、いつ、なぜ実行したかを説明できる状態にしておくことが、トラブルを防ぎます。
Microsoft Graph APIで自動化する場合の注意点
開発者や運用自動化担当者は、Microsoft Graph APIのlocateDeviceアクションも確認する必要があります。公式のGraph APIリファレンスでは、locateDeviceはPOST /deviceManagement/managedDevices/{managedDeviceId}/locateDeviceで実行し、成功時は204 No Contentを返すとされています。(Microsoft Learn)
重要なのは、このAPIが「位置情報を本文で返す取得API」ではなく、Locate Deviceアクションを実行するAPIである点です。成功レスポンスの本文から座標を取得する設計にすると失敗します。アクション実行後の結果確認や運用画面での確認方法は、別途設計する必要があります。
権限面では、locateDevice APIを呼び出すにはDeviceManagementManagedDevices.ReadWrite.Allが必要です。委任された職場または学校アカウント、またはアプリケーション権限で利用できますが、個人のMicrosoftアカウントはサポートされません。また、IntuneのGraph APIを利用するには、テナントに有効なIntuneライセンスが必要です。(Microsoft Learn)
音を鳴らして紛失デバイスを探すplayLostModeSoundについては、参照先のGraph APIページがbetaとして提供されています。MicrosoftはIntuneのbeta APIをサポートしつつも変更頻度が高いため、可能な場合はv1.0の利用を推奨しています。本番自動化に組み込む場合は、APIバージョン、権限、変更時の影響を事前に確認してください。(Microsoft Learn)
開発・自動化で避けたい設計は次のとおりです。
| 避けたい設計 | 理由 | 代替策 |
|---|---|---|
| 端末一覧に対して無差別にlocateDeviceを実行 | 位置情報取得の正当性を説明しにくい | インシデント番号や承認済み端末IDに限定 |
| アプリケーション権限を広く付与 | 自動化アプリが全端末に強い操作を実行できる | 条件付きアクセス、証明書管理、監査ログを組み合わせる |
| 204レスポンスを位置情報取得成功と誤解 | APIはアクション実行の成功を示すだけ | 実行後の確認フローを別に定義 |
| beta APIを恒久運用に組み込む | 仕様変更の影響を受けやすい | バージョン監視と回帰テストを用意 |
| 実行理由を記録しない | プライバシー監査で説明できない | チケット番号、承認者、実行者をログに残す |
展開前に確認するチェックリスト
Locate Deviceを安全に展開するには、ポータル上で機能を見つけるだけでは不十分です。まず小規模な検証グループを作り、OS別・登録方式別に実行できるかを確認します。
| チェック項目 | 確認方法 | 合格基準 |
|---|---|---|
| 対象デバイスの棚卸し | Intuneのデバイス一覧でOS、登録方式、所有者を確認 | 対象端末と対象外端末が明確 |
| Androidの制限プロファイル | デバイス制限プロファイルを確認 | COBO/COPEでLocate Deviceが有効 |
| COPEのユーザー許可 | テスト端末でIntuneアプリの位置情報権限を確認 | 常時許可に相当する設定になっている |
| Windows設定カタログ | Privacy設定の割り当てを確認 | 対象グループにForce allowが適用 |
| iOS/iPadOS | 監視モードとLost Mode運用を確認 | 紛失時のロック・表示メッセージ手順がある |
| RBAC | テスト用ヘルプデスクアカウントで確認 | 必要端末だけ見え、Locate Deviceを実行できる |
| スコープタグ | Androidの構成ポリシーが見えるか確認 | 権限不足で実行不能にならない |
| 監査手順 | チケットシステムや台帳を確認 | 実行理由と結果を記録できる |
| ユーザー説明 | 端末利用規程、貸与同意書、FAQを確認 | 位置情報利用の目的が明記されている |
検証では、オンライン端末、オフライン端末、最近チェックインしていない端末を分けて試すと、実運用時の判断がしやすくなります。特にAndroid Enterprise専用デバイスでは、最後の既知の場所の表示と現在地の取得を混同しないように確認してください。
よくある失敗と対処法
Locate Deviceのトラブルは、機能そのものの不具合よりも、事前条件の不足や運用設計の抜けで起きることが多いです。
| 症状 | 主な原因 | 対処法 |
|---|---|---|
| Locate Deviceが表示されない | 対象プラットフォーム外、権限不足、画面幅による非表示 | 対応OS、RBAC、オーバーフローメニューを確認 |
| 実行できない | カスタムロールにRemote tasks/Locate deviceがない | ロール権限を見直す |
| Androidで位置を取得できない | デバイス制限プロファイル未設定、位置情報サービス無効、Intuneアプリ権限不足 | 登録方式ごとの要件を再確認 |
| COPEで失敗する | ユーザーがIntuneアプリに位置情報を許可していない | 事前案内と手順書を用意 |
| Windowsで取得できない | 設定カタログで位置情報アクセスを許可していない | Privacy設定をForce allowにする |
| オフライン端末の位置が古い | 最後のチェックイン時点の情報を見ている | 表示時刻を確認し、現在地と断定しない |
| Device actions statusのCompleteを誤解する | 初期化による既定ステータスの可能性 | 実行履歴と照合する |
| Locate後に別アクションが効かない | Retire、Wipe、Deleteなどの保留アクションが優先される可能性 | pending actionを確認してから実行 |
Microsoft Intuneのデバイスアクションでは、Retire、Wipe、Deleteが他のアクションより優先され、複数の保留中アクションがある場合はそれら以外が無視されると説明されています。紛失対応中にWipeやDeleteを同時に進める場合は、Locate Deviceのタイミングを事前に決めておく必要があります。(Microsoft Learn)
運用シーン別の使い分け
Locate Deviceは、紛失対応の入口として使うと効果的です。ただし、状況によって次のアクションは変わります。
| シーン | 推奨判断 |
|---|---|
| 社内で端末を置き忘れた | Locate Deviceで位置を確認し、必要に応じて音を鳴らす機能やユーザー連絡を併用 |
| 外出先で紛失した | 位置確認後、データ機密性に応じてRemote lockやLost Modeを検討 |
| 盗難の疑いがある | Locate Deviceだけで追跡を続けず、Wipeやアカウント保護、警察・社内手順へ移行 |
| Android専用端末がオフライン | 最後の既知の場所を確認し、回収担当へ共有。ただし現在地とは限らない |
| iOS/iPadOS端末を紛失 | 監視モードとLost Modeの前提を確認し、ロック画面メッセージを活用 |
| Windows端末を紛失 | 位置情報設定の適用状況を確認し、BitLockerやサインイン保護もあわせて確認 |
特に盗難の疑いがある場合、位置情報を取得できたとしても、管理者や社員が単独で回収に向かう運用は避けるべきです。Locate Deviceは「端末を取り戻すための地図」ではなく、「次のセキュリティ判断を早くするための情報」と考えると、安全で現実的な運用になります。
管理者と開発者が次に取るべき行動
Microsoft IntuneのDevice Action: Locate Deviceを導入・見直しするなら、まず対象端末をOSと登録方式ごとに分類してください。そのうえで、Android Enterprise、iOS/iPadOS、Windowsの前提条件を確認し、テストグループで実行結果を検証します。
管理者は、RBAC、スコープタグ、設定カタログ、デバイス制限プロファイル、ユーザー通知、監査記録をセットで確認します。開発者は、Graph APIの権限、204レスポンスの扱い、beta APIの利用可否、実行理由の記録を設計に入れるべきです。
最後に、紛失時のフローを文書化します。誰が承認し、誰がLocate Deviceを実行し、位置情報をどう記録し、どの条件でRemote lockやWipeへ進むのかを決めておくことで、実際のインシデント時に迷わず対応できます。
Microsoft IntuneのLocate Deviceは、設定すれば終わりの機能ではありません。端末回収、情報漏えい対策、プライバシー保護を両立するための運用設計まで含めて整備することが、管理者にとって最も重要な対応です。
コメント