個人スマホから Windows 365 や Azure Virtual Desktop に入らせたい。でも、Intune で端末登録まで求めると現場の負担が重い。そんな BYOD の悩みに対して、Windows App の Intune MAM 対応はかなり実務的な答えです。Microsoft は 2026年3月30日の公式ブログで、iOS / Android の Windows App から Windows リソースへアクセスする際に Intune Mobile Application Management を使って DLP コントロールを適用でき、フルデバイス登録なしの BYOD に向くと案内しています。 (TECHCOMMUNITY.MICROSOFT.COM)
この記事では、Windows App の Intune MAM 対応で 何が守れて、何は別レイヤーで守る必要があるのか、そして App Protection Policies をどう運用設計に落とし込むべきか を実務目線で整理します。結論から言えば、BYOD でも「どのアプリから接続させるか」「端末側へ何を持ち出せるか」「最低限の端末健全性」をかなり細かく絞れます。ただし、機密性の高い業務では MAM だけで完結させず、Conditional Access、managed app configuration、そして Windows 365 / Azure Virtual Desktop 側のリダイレクト設定まで合わせて設計するのが安全です。 (Microsoft Learn)
Windows App の Intune MAM 対応で何が変わったのか
Microsoft の公式ブログでは、Windows App のセキュリティ強化の一つとして Intune MAM support が取り上げられており、iOS と Android の Windows App から Cloud PC や仮想デスクトップへアクセスするときに DLP コントロールを適用できると説明されています。加えて Microsoft Intune の保護対象アプリ一覧でも、Windows App は iOS / Android で Core App Protection Policy settings と App configuration をサポートするアプリとして掲載されています。 (TECHCOMMUNITY.MICROSOFT.COM)
ここで重要なのは、Windows App が Word や Outlook のように文書そのものを持つアプリではなく、リモート Windows への接続経路 だという点です。Intune の保護対象アプリ一覧でも、Windows App は core APP と app configuration には対応する一方、Office 系アプリで見かける高度な MAM 項目の多くが N/A です。さらに Microsoft Learn でも、Windows App では「アプリ内データ」より session host とローカル端末のやり取り に関係する設定だけが relevant とされており、実務上の主戦場は「端末側への持ち出し」と「安全でない入力・表示経路の遮断」になります。 (Microsoft Learn)
MAM と MDM の違いを先に整理しておく
Intune の App Protection Policies は、会社データを アプリ単位 で保護する仕組みです。Microsoft は、MAM はデバイス管理を前提にせず、管理対象・非管理対象の両方で会社データを保護でき、しかもポリシーは個人コンテキストではなく work context にだけ適用 されると説明しています。一方で MDM は、端末登録、アプリ配布、継続的なデバイス準拠、証明書や Wi‑Fi / VPN 配布といった 端末全体の管理 を担います。 (Microsoft Learn)
実務での違いをざっくり言い換えると、次のようになります。
- MAM だけでできること
BYOD 端末に対して、Windows App 経由の会社データの扱いをアプリ単位で制御する。コピー＆ペースト制限、画面キャプチャ制御、キーボード制御、最小 OS / アプリ バージョン、脅威レベル条件などが中心です。 - MDM があると追加できること
アプリの管理配布、証明書プロファイル、会社 Wi‑Fi / VPN 設定、より広い準拠管理、会社所有端末向けの一貫した運用です。 - 両方を併用する意味
会社支給端末は MDM + MAM、個人端末は MAM のみ、という住み分けができます。Microsoft も、Intune 管理端末には緩め、非登録 BYOD には厳しめの MAM を当てる設計を案内しています。
この差を理解しておくと、「BYOD にどこまで期待できるか」がぶれません。 (Microsoft Learn)
BYOD で実際に守れるもの
Windows App 向けの App Protection Policies で実務上効くのは、主に 持ち出し制御、画面表示の保護、入力経路の保護、起動条件 の4つです。Microsoft Learn が Windows App 向けに relevant として示している内容を整理すると、次の通りです。 (Microsoft Learn)
| 制御したいこと | iOS / iPadOS | Android |
|---|---|---|
| クリップボードの持ち出し | Restrict cut, copy, and paste between other apps = Blocked | Restrict cut, copy, and paste between other apps = Blocked |
| 画面キャプチャ | Send org data to other apps = None で画面キャプチャ保護を有効化 | Screen capture and Google Assistant = Block |
| キーボード制御 | Third-party keyboards = Blocked | Approved keyboards で許可対象を限定 |
| 起動条件 | 最小アプリ版、最小 OS、Primary MTD service、最大脅威レベル | 最小アプリ版、最小 OS、Primary MTD service、最大脅威レベル |
上の表は、Microsoft が Windows App on iOS / iPadOS / Android 向けに案内している設定を要約したものです。言い換えると、個人スマホからリモート Windows に入ること自体は許可しつつ、端末側へのコピペ、スクショ、危険なキーボード、危ない端末状態はかなり絞れる ということです。 (Microsoft Learn)
BYOD で特に効くのは、「会社が個人端末そのものを管理する」のではなく、会社アカウントで Windows App を使う瞬間だけを締める ことです。App Protection Policies は work context のみを保護し、個人コンテキストには触れないため、BYOD でよく出る「会社に私物スマホを全部見られたくない」という心理的な抵抗を下げやすいのも利点です。 (Microsoft Learn)
ただし、MAM だけでは守り切れないポイントもある
ここは誤解されやすいところです。Windows App の MAM 対応だけで 完全な DLP ができるわけではありません。Microsoft 自身が、Windows App ではアプリ内データよりも session host とのやり取り が中心であり、ローカルリソースのリダイレクト制御は Intune の app configuration policies と Conditional Access を組み合わせて扱う設計を案内しています。 (Microsoft Learn)
具体的には、Windows App の managed apps 向け app configuration で次のようなリダイレクト制御ができます。
redirectclipboard：クリップボードのリダイレクトdrivestoredirect：ドライブのリダイレクトcamerastoredirect：カメラのリダイレクトaudiocapturemode：マイク入力のリダイレクト
これらは client 側 の制御です。もし Azure Virtual Desktop の host pool / session host や Windows 365 側の設定と衝突した場合は、より厳しい設定が優先 されます。逆に言えば、高セキュリティ業務では client 側だけに頼らず、host 側でもリダイレクトを無効化するのが基本です。Microsoft も、Intune による Windows App / Remote Desktop app の制御は高セキュリティ要件の代替ではなく、可能なら session host 側で redirection を止め、DLP も併用することを推奨しています。 (Microsoft Learn)
また、MAM without enrollment には限界もあります。BYOD 端末では、アプリはユーザーがストアから入手する前提で、証明書プロファイルや会社 Wi‑Fi / VPN 設定は配布されません。つまり、「会社データの扱い」は守れても、「端末を会社標準に揃える」ことまではできません。ここは MDM と混同しない方が運用判断を誤りません。 (Microsoft Learn)
フル MDM なし運用はどこまで現実的か
結論として、かなり現実的です。Microsoft は登録されていないデバイス向け MAM を BYOD の典型シナリオとして案内しており、managed apps 向け app configuration は MAM チャネル で配信され、デバイス登録や Intune からのアプリ配布を必須としません。app-based Conditional Access も、Intune 登録済み端末だけでなく、登録していない社員所有端末 に対して機能します。 (Microsoft Learn)
実務でまず試しやすい最小構成は、次の形です。
- Windows App を使わせたいユーザーをグループ化する
BYOD と管理端末で厳しさを変えたいなら、最初から分けて考えます。フィルターを使わないと managed / unmanaged に同じ device security compliance や redirection 設定がかかるためです。Intune は非登録端末だけに厳しい MAM を当てる設計もサポートしています。 (Microsoft Learn) - iOS / iPadOS 用、Android 用に別々の App Protection Policy を作る
Windows App を対象アプリとして選び、クリップボード、画面キャプチャ、キーボード、起動条件を設定します。 (Microsoft Learn) - Conditional Access で「App Protection Policy が適用された Windows App だけ通す」
Microsoft の例では、Azure Virtual Desktop、Windows 365、Windows Cloud Login を対象にし、iOS / Android でRequire app protection policyを使う構成が案内されています。 (Microsoft Learn) - 必要に応じて managed apps 向け app configuration を追加する
redirectclipboardやdrivestoredirectを 0 にして、端末側への持ち出し経路をさらに絞ります。 (Microsoft Learn) - 前提アプリを見落とさない
Microsoft の案内では、iOS / iPadOS では Microsoft Authenticator、Android では Company Portal が必要です。特に Android の個人端末では、Windows App と Company Portal を同じプロファイルに置く必要があります。 (Microsoft Learn) - 最後は実機で検証する
Microsoft も、managed / unmanaged の両方で想定通りに操作が制限されるかを確認するよう案内しています。机上設計だけで終わらせないのが重要です。 (Microsoft Learn)
実務でハマりやすいポイント
「MAM を入れたのにコピペや持ち出しが止まらない」
Windows App では APP だけでなく、managed app configuration と host 側設定 の両方を見る必要があります。APP でコピペを block しても、リモート側の clipboard / drive redirection をどう設計するかで体感は変わります。特に機密データでは、session host 側でもリダイレクトを切る前提で考えた方が安全です。 (Microsoft Learn)
「管理端末と BYOD で同じポリシーが当たってしまう」
Intune は、device management state を意識せずに MAM を当てると、BYOD と Intune 管理端末の両方に同じポリシーがかかります。Microsoft は、非登録 BYOD には厳しめ、管理端末には緩め といった分け方を明示的に案内しています。 (Microsoft Learn)
「Android の個人端末だけ適用が不安定」
Android の APP は Company Portal が必要です。しかも Windows App と Company Portal が 同じプロファイル にある必要があります。ここを外すと、ポリシー自体は正しくても期待通りに動かないことがあります。 (Microsoft Learn)
「Intune 管理センターで Android 向け Windows App が見つからない」
Microsoft の手順では、Android では移行タイミングの都合で Intune 上にまだ Remote Desktop と表示される場合があります。その場合でも、Windows App と Remote Desktop は同じパッケージ ID com.microsoft.rdc.androidx を使うため、app configuration policy は適用されます。探しても出てこないときは、ここを疑うと手が止まりにくいです。 (Microsoft Learn)
「BYOD なのに証明書や Wi‑Fi 配布まで期待してしまう」
それは MAM ではなく MDM の役割です。登録なし MAM は、会社データをアプリ単位で守る仕組みであって、端末全体を会社標準に構成する仕組みではありません。 (Microsoft Learn)
どの運用パターンを選ぶべきか
MAM 中心で始めやすい企業 は、個人スマホから Windows 365 や Azure Virtual Desktop に入らせたいが、端末登録のハードルは上げたくない企業です。ユーザーにストアから Windows App を入れてもらえる、会社 Wi‑Fi や証明書配布までは不要、まずはコピー・スクショ・危険端末の抑止から始めたい、という条件なら相性がいいです。 (Microsoft Learn)
MDM も併用した方がいい企業 は、会社支給端末が中心、Wi‑Fi / VPN / 証明書まで一括配布したい、あるいは host 側も含めて厳格に標準化したい企業です。特に金融、人事、法務のように「端末に一切持ち出させない」要件が強いなら、MAM 対応を入口にしつつも、最終的には MDM と host 側制御をセットにした方がブレません。 (Microsoft Learn)
迷ったら、この順番で進める
Windows App の Intune MAM 対応は、BYOD を全面解禁する魔法の機能ではありません。ただ、個人端末を完全管理しなくても、会社データの扱い方だけは厳しくする という現場ニーズにはかなり合っています。Microsoft の情報を踏まえると、Windows App on iOS / Android に App Protection Policy を当て、Conditional Access で保護された接続だけを許可し、必要に応じて managed app configuration で clipboard / drive / camera / microphone のリダイレクトを止める、という構成が BYOD の現実解です。 (TECHCOMMUNITY.MICROSOFT.COM)
次にやるべきことは 3 つです。BYOD と管理端末のポリシーを分けるか決めること、Windows App 向けの APP を iOS と Android で個別に作ること、そして実機で「本当にコピペ・スクショ・リダイレクトが止まるか」を確認すること。この3点を押さえれば、Windows App の Intune MAM 対応は「発表を追うだけのニュース」ではなく、すぐ導入判断に使える選択肢になります。 (Microsoft Learn)
コメント