Microsoft Intuneの公式ドキュメント更新「actions updates」は、単なるドキュメント差分として流し読みせず、デバイス操作の手順書・権限設計・承認フロー・監査ログ確認まで見直すべき更新です。結論から言うと、今回の確認ポイントは「新機能が追加されたか」ではなく、IntuneのDevice actionsに関する公式説明と、自社の運用ルールがずれていないかを点検することです。
特に、Wipe、Retire、Delete、Locate deviceのような操作は、端末データの削除、組織管理からの解除、位置情報の取得に直結します。security admins、compliance teams、enterprise IT readersは、2026年4月30日の更新をきっかけに、管理者権限、Multiple Administrative Approval、監査ログ、端末ライフサイクル管理の4点を確認しておくと安全です。
Microsoft Intuneの公式ドキュメント更新「actions updates」で何が変わったか
今回扱う「actions updates」は、MicrosoftDocs/memdocsリポジトリで公開されたMicrosoft Intune関連の公式ドキュメント更新です。GitHub上のコミットでは、intune/device-management/actions/index.mdとアイコンファイルが変更対象になっており、3ファイルの変更、14行追加、14行削除として記録されています。Microsoft Learn上のDevice Actionsページも、最終更新日が2026年4月30日となっています。(GitHub)
この更新は、現時点では「Intune製品の大規模な仕様変更」と断定するより、Device actionsドキュメントのリンク・表記・アイコン周りの整理として読むのが妥当です。ただし、対象がデバイス削除やワイプなどの強い操作であるため、ドキュメント上の小さな変更でも運用への影響は無視できません。
| 確認対象 | 今回見るべき内容 | 実務上の意味 |
|---|---|---|
| Device actions一覧 | Delete、Wipe、Retire、Locate deviceなどの説明と対応プラットフォーム | 社内手順書やヘルプデスク手順との整合性を確認する |
| リンク参照 | Delete、Disable Activation Lock、Locate deviceなどのリンク先 | 誤った手順ページを参照していないか確認する |
| アイコンファイル | remove-apps-and-configurations関連のファイル追加・変更 | 自社ドキュメントで公式画像や画面説明を引用している場合に確認する |
| 権限・承認 | RBAC、MAA、監査ログ | 管理者の過剰権限や誤操作リスクを下げる |
「新機能追加」よりも「公式手順とのズレ」を確認する
Microsoft IntuneのDevice actionsページでは、Windows向けにAutopilot reset、BitLocker key rotation、Collect diagnostics、Delete、Fresh Start、Locate device、Retire、Sync、Wipeなどのアクションが一覧化されています。また、Apple、Android、ChromeOSなどプラットフォーム別の対応アクションも整理されています。(Microsoft Learn)
ここで重要なのは、一覧に載っているアクションをそのまま「全端末で使える」と解釈しないことです。Intuneのアクションは、OS、登録方式、端末所有形態、構成プロファイル、権限、スコープタグによって実行可否が変わります。
たとえば、Locate deviceは端末の位置情報を扱うため、Windowsでは位置情報を許可する設定カタログポリシーが必要です。Androidでは、端末種別や管理者が該当ポリシーを読めるかどうかも条件になります。(Microsoft Learn)
そのため、今回の更新を見た管理者は、まず次のように切り分けると判断しやすくなります。
| 判断項目 | 確認方法 | 対応の優先度 |
|---|---|---|
| 製品仕様の変更か | Microsoft Learn本文、GitHub差分、Intune管理センターの実画面を比較 | 高 |
| ドキュメント上の表記整理か | コミット差分の対象ファイルと変更行を確認 | 中 |
| 自社手順への影響があるか | ランブック、監査証跡、承認フローと照合 | 高 |
| 画面キャプチャだけの差分か | アイコン・画像ファイルの変更有無を確認 | 低〜中 |
Deleteリンクのような参照先の不整合は必ず確認する
今回の差分で特に注意したいのは、リンク参照の扱いです。コミット差分では、[Delete]の参照先としてMicrosoft Entra IDの認証関連ページが追加されている箇所があり、本稿確認時点ではDevice Actionsページ上のDeleteリンクがIntuneのDelete actionページではなく、Passkeys関連ページへ遷移する動きが確認できます。(GitHub)
これは、IntuneのDelete機能そのものが変わったという意味ではありません。むしろ、公式ドキュメントであっても、更新直後はリンク先を直接確認する必要があるという実務上の注意点です。
社内手順書を更新する場合は、概要ページのリンクだけを信頼せず、次のように確認してください。
| 確認するリンク | 確認ポイント |
|---|---|
| Delete | IntuneのDevice Action: Deleteページに遷移するか |
| Locate device | Locate deviceの前提条件、権限、位置情報の扱いが確認できるか |
| Disable Activation Lock | Apple端末向けのActivation Lock解除ページに遷移するか |
| Wipe / Retire | MAA、Autopilot、Entra ID、Apple Business Managerとの関係を確認できるか |
特にコンプライアンスチーム向けの資料では、「公式ページにリンクしたから安全」と考えず、リンク先のページタイトルと対象サービスが一致しているかまで確認するのが安全です。
Device actionsで優先的に確認すべき操作
Microsoft IntuneのDevice actionsには多数の操作がありますが、運用影響が大きいものから確認するのが現実的です。優先度が高いのは、端末やデータの状態を不可逆に変える操作です。
| アクション | 主な影響 | 確認すべき観点 |
|---|---|---|
| Wipe | 端末を初期状態へ戻し、データや構成を削除する | 実行権限、承認、対象端末、復旧手順 |
| Retire | 会社データや管理設定を削除し、個人データは残す | BYOD運用、退職・異動時の手順 |
| Delete | Intune管理から端末を削除する | Entra ID、Autopilot、ABMなどの残存レコード |
| Locate device | 端末の位置情報を確認する | 位置情報ポリシー、プライバシー、監査ログ |
| Remote lock / Restart / Sync | 運用補助的なリモート操作 | ヘルプデスク権限と操作記録 |
| Disable Activation Lock | Apple端末の再利用に関係する | ADE、監督モード、Apple Business Manager |
Wipeは端末を工場出荷時の状態へ戻す操作で、個人データと組織データの両方に影響します。Retireはフルワイプではなく、会社データやMDM配布の設定を削除しつつ個人データを残す用途に向いています。(Microsoft Learn)
この違いを社内で明確にしていないと、「退職者端末にはRetireでよいのか」「紛失端末にはWipeが必要なのか」「棚卸しでDeleteしてよいのか」といった判断が担当者ごとにばらつきます。手順書では、操作名だけでなく、使ってよい場面・使ってはいけない場面・事前承認の要否をセットで定義しましょう。
RBACと最小権限を見直す
Device actionsは、誰でも実行できてよい操作ではありません。Delete actionの公式ページでは、実行に必要なロールとしてSchool Administrator、Endpoint Security Manager、または必要なカスタムロール権限が示されています。カスタムロールの場合は、Managed devices/Deleteに加え、管理対象デバイスを参照するための読み取り権限も必要です。(Microsoft Learn)
Locate deviceも同様に、Help Desk Operator、School Administrator、またはRemote tasks/Locate deviceなどを含むカスタムロールが必要です。Android端末では、位置情報を有効にするポリシーを管理者が読めることや、該当スコープタグへの可視性も条件になります。(Microsoft Learn)
実務では、次のような権限分離が有効です。
| 管理者グループ | 付与する権限の考え方 | 避けるべきこと |
|---|---|---|
| ヘルプデスク一次対応 | Sync、Restart、必要に応じてLocate device | WipeやDeleteを広く付与しない |
| セキュリティ管理者 | Wipe、Retire、Deleteの実行または承認 | 1人で申請から承認まで完結させない |
| コンプライアンス担当 | 監査ログ閲覧、証跡確認 | 端末操作の実行権限を不要に付与しない |
| Intune管理者 | ポリシー設計、RBAC、MAA設定 | 常用アカウントに強すぎる権限を持たせない |
ポイントは、「実行できる人」を増やすのではなく、「実行できるが、承認と証跡が残る状態」を作ることです。
Multiple Administrative Approvalを使うべき操作
IntuneのMulti Admin Approvalは、保護対象の変更を別の管理者が承認するまで適用しない仕組みです。Microsoftの公式説明では、Device actionsの対象としてWipe、Retire、Deleteが挙げられています。(Microsoft Learn)
Wipe、Retire、Deleteは、誤操作や侵害された管理者アカウントによる被害が大きくなりやすい操作です。そのため、少なくとも本番テナントでは、以下の操作にMAAを適用するか検討しましょう。
| 操作 | MAAを推奨する理由 |
|---|---|
| Wipe | 端末データを消去するため、誤実行時の影響が大きい |
| Retire | BYODや退職者端末で会社データ削除に関係する |
| Delete | Intune管理から外れ、棚卸しや監査に影響する |
| RBAC変更 | MAAや権限設計そのものを壊す可能性がある |
MAAでは、承認者は自分自身のリクエストを承認できず、別の管理者による承認が必要です。また、承認後もリクエスト元の管理者がCompleteを実行して処理を完了させる流れになります。緊急時の連絡ルールも重要です。公式ドキュメントでは、新しいリクエストや状態変更時に通知が送られない点も注意事項として示されています。(Microsoft Learn)
つまり、MAAを設定しただけでは不十分です。実際の運用では、次の3点を決めておく必要があります。
- 承認者グループに誰を入れるか
- 業務時間外の緊急Wipeを誰が承認するか
- 却下時の理由や再申請ルールをどう記録するか
Locate deviceはプライバシーと監査ログをセットで扱う
Locate deviceは紛失端末の回収に有効ですが、位置情報を扱うため、コンプライアンス上の確認が欠かせません。公式ドキュメントでは、Locate Deviceの実行時に位置情報を取得し、緯度・経度がGraph API経由で取得されること、位置情報は転送中・保存時に暗号化されること、通常の位置データは24時間で削除されること、最終既知位置は最大7日間保持される可能性があることが説明されています。(Microsoft Learn)
運用上は、次のようなルールを用意しておくとトラブルを避けやすくなります。
| 項目 | 推奨ルール |
|---|---|
| 実行条件 | 紛失、盗難、重大インシデントなどに限定する |
| 申請理由 | チケット番号、端末ID、実行理由を記録する |
| 利用者通知 | 就業規則、端末利用規程、MDM同意文書に明記する |
| 実行権限 | ヘルプデスクに広く付与せず、必要な担当者に限定する |
| 証跡確認 | Intune監査ログまたは連携先のログ基盤で確認する |
特にグローバル企業では、国や地域によって位置情報の扱いに対する期待値が異なります。日本法人だけでなく、海外拠点の管理対象端末にも同じ設定を適用している場合は、法務・人事・セキュリティの確認を挟むべきです。
監査ログで「誰が何をしたか」を追える状態にする
Intuneでは、作成、更新、削除、割り当て、リモートアクションなど、変更を発生させる操作が監査イベントとして記録されます。監査ログはすべての顧客で有効で、無効化できないと説明されています。(Microsoft Learn)
Device actionsの運用では、監査ログを「何か起きた後に見るもの」ではなく、手順の一部として扱うのが重要です。
たとえば、端末紛失対応では次のような流れにします。
| 手順 | 実施内容 |
|---|---|
| 申請 | チケットに端末名、ユーザー、理由、希望アクションを記録 |
| 承認 | MAAまたは社内承認ワークフローで承認 |
| 実行 | Intune管理センターからWipe、Retire、Locate deviceなどを実行 |
| 確認 | Device actions statusと監査ログを確認 |
| 完了記録 | 実行者、時刻、対象端末、結果をチケットに追記 |
Intuneの監査ログは管理センターから確認でき、日付、カテゴリ、アクティビティなどで絞り込めます。また、Graph APIで監査イベントを取得する方法も公式に案内されています。(Microsoft Learn)
Bulk device actionsは便利だが、対象選定を誤ると影響が大きい
Device actionsページでは、Bulk device actionsも説明されています。大規模環境では、複数端末に対して一括でDelete、Retire、Sync、Wipeなどを実行できるため、学校、店舗、工場、キッティング部門では有効です。公式ページでは、Intuneが最大100台まで同時に一括デバイスアクションを実行できる旨が説明されています。(Microsoft Learn)
ただし、一括操作は「速く処理できる」ことがメリットである一方、「誤った対象にも速く処理される」ことがリスクです。特にWipeやDeleteをBulkで使う場合は、実行前に対象端末リストを二重確認する仕組みを入れてください。
実務では、次のチェックが有効です。
| チェック項目 | 確認内容 |
|---|---|
| 対象グループ | 動的グループ条件が意図通りか |
| 端末名 | 命名規則から対象部署・用途が分かるか |
| 最終チェックイン | 長期間未チェックイン端末をどう扱うか |
| 所有形態 | Corporate-ownedとPersonal-ownedを混在させていないか |
| 例外端末 | 役員端末、検証端末、共有端末を除外しているか |
| 承認 | Bulk WipeやBulk Deleteに追加承認を設けているか |
Delete後にIntune以外の管理面も確認する
Delete、Retire、Wipeを実行しても、必ずしも関連するすべての管理レコードが自動的に整理されるとは限りません。Delete actionの公式ページでは、Intune上でアクションを実行した後、Microsoft Entra IDのデバイスレコード削除を検討することや、Apple ADEデバイスではApple Business Managerからのリリースが必要になる場合があることが説明されています。(Microsoft Learn)
Wipeでも、Windows Autopilot登録やMicrosoft Entra IDレコードの削除確認が必要になる場合があります。(Microsoft Learn)
端末ライフサイクル管理では、Intuneだけを見て完了とせず、次の管理面を確認してください。
| 管理対象 | 確認すべき内容 |
|---|---|
| Microsoft Intune | 端末が管理対象から外れているか |
| Microsoft Entra ID | デバイスレコードが残っていないか |
| Windows Autopilot | 再利用・廃棄時に登録が残っていないか |
| Apple Business Manager | ADE端末を組織からリリースする必要があるか |
| 資産管理台帳 | 廃棄、再配布、返却ステータスが更新されているか |
| SIEM / ログ基盤 | 操作証跡が保存されているか |
ここを省略すると、「Intune上は消えたが、Entra IDやAutopilotには残っている」「Apple端末を再利用しようとしたらActivation Lockで詰まる」といったトラブルにつながります。
社内ドキュメントを更新する手順
今回のMicrosoft Intuneの公式ドキュメント更新「actions updates」を受けて、社内手順書を見直す場合は、次の順番で進めると抜け漏れを防げます。
| 手順 | 作業内容 | 担当の目安 |
|---|---|---|
| 公式差分の確認 | GitHubコミットとMicrosoft Learnの該当ページを確認 | Intune管理者 |
| 影響アクションの抽出 | Wipe、Retire、Delete、Locate deviceなどを分類 | セキュリティ管理者 |
| 権限棚卸し | RBAC、カスタムロール、スコープタグを確認 | Intune管理者 |
| 承認設計 | MAA対象、承認者グループ、緊急時対応を決定 | セキュリティ・IT統制 |
| 監査設計 | 監査ログの確認方法、保存先、チケット連携を決定 | コンプライアンス |
| 手順書更新 | 操作手順、禁止事項、判断基準を明文化 | IT運用 |
| 検証 | テスト端末で実行結果とログを確認 | IT運用・監査担当 |
特に、画面キャプチャだけを更新して終わらせないことが大切です。Device actionsは「押せるボタンの説明」ではなく、端末ライフサイクル、情報漏えい対策、監査対応を支える運用プロセスです。
失敗しやすいポイント
Microsoft IntuneのDevice actions運用でよくある失敗は、機能そのものの理解不足よりも、権限と手順の曖昧さです。
| 失敗例 | 起きる問題 | 対策 |
|---|---|---|
| ヘルプデスク全員にWipe権限を付与 | 誤操作時の影響が大きい | 最小権限とMAAを適用する |
| DeleteとRetireを混同 | 必要なデータ削除や管理解除が不完全になる | 用途別の判断表を作る |
| Locate deviceを自由に使える状態にする | プライバシー上の懸念が出る | 実行条件と記録ルールを決める |
| Bulk actionsの対象確認が甘い | 複数端末に誤操作が広がる | 対象リストの二重確認を必須にする |
| 公式リンクを未確認で手順書に貼る | 誤ったページを参照する可能性がある | ページタイトルと遷移先を確認する |
| Intuneだけで削除完了と判断 | Entra ID、Autopilot、ABMに残骸が残る | 関連管理面のチェックリストを使う |
まず実施すべきアクション
今回の更新を受けて、すぐに実施すべきことは3つです。
まず、Microsoft LearnのDevice actionsページとGitHubの差分を確認し、自社の手順書で参照しているリンクと説明が正しいかを点検します。次に、Wipe、Retire、Delete、Locate deviceの権限とMAA設定を見直します。最後に、端末操作後の監査ログ確認と、Entra ID、Autopilot、Apple Business Managerなど関連システムの後処理をチェックリスト化します。
Microsoft Intuneの公式ドキュメント更新「actions updates」は、派手な新機能発表ではありません。しかし、Device actionsは端末管理の中でもリスクの高い領域です。更新内容をきっかけに、公式仕様、社内権限、承認、監査、移行準備をそろえておくことで、誤操作と監査対応の負担を大きく減らせます。
コメント