Microsoft IntuneのiOS/iPadOSアプリ保護ポリシー設定ガイダンス更新で変わることと見直すべき設定

Microsoft が2026年4月上旬に案内した最新の iOS/iPadOS 向けアプリ保護ポリシー設定ガイダンスで、管理者がまず押さえるべき結論は明確です。Genmoji、Writing Tools、Screen capture を Intune のアプリ保護ポリシーで個別に見直せるようになり、BYOD を含む iPhone / iPad 運用でも、生成 AI 機能や画面共有からの情報流出リスクを従来より細かく制御しやすくなりました。(Microsoft Learn)

ただし、ここで安心はできません。既存のアプリ保護ポリシー(APP)で Send Org data to other apps を All apps 以外にしていると、新しい3設定は Block として引き継がれます。さらに、古い app configuration policy やアプリ側の Intune SDK バージョン条件が残っていると、想定外のブロックや未反映が起こります。なお、Intune の更新情報ページは2026年4月7日更新、設定ガイド本体は2025年11月18日更新表示です。(Microsoft Learn)

この記事では、今回の更新で何が変わったのか、企業のモバイルセキュリティ体制にどんな意味があるのか、そして Microsoft Intune 管理者が今すぐ見直すべき設定と検証手順を、実務目線で整理します。(Microsoft Learn)

目次

Microsoft Intune の iOS/iPadOS アプリ保護ポリシー更新ポイント

4月上旬時点の論点は、設定項目が増えたこと自体よりも、「既存の iOS/iPadOS 運用のどこに影響するか」を正しく読むことです。先に要点だけ整理すると、次の6つです。(Microsoft Learn)

  • Genmoji、Writing Tools、Screen capture は Data protection セクションの独立設定として扱われます。対象アプリは、Xcode 15 系では Intune App SDK / App Wrapping Tool v19.7.12 以降、Xcode 16 系では v20.4.0 以降が必要です。対応アプリでなければ、この設定を前提にした統制は当てにできません。(Microsoft Learn)
  • Screen capture の Block は、スクリーンショットだけを止める設定ではありません。端末内の画面録画、Teams や Zoom モバイルでの画面共有、AirPlay でのミラーリング、Mac の QuickTime 経由のミラーリングや録画まで影響します。(Microsoft Learn)
  • 既存ポリシーで Send Org data to other apps が All apps 以外なら、新しい3設定は Block に設定され、従来の利用感を維持するように移行されます。新規ポリシーと既存ポリシーで初期状態の見え方が違う点は、かなり見落とされやすい部分です。(Microsoft Learn)
  • 以前から Managed apps の app configuration policy(ACP)で screen capture を許可していた場合、その ACP が APP 設定を上書きします。Microsoft は、新しい APP 側の設定に統一し、旧 ACP を外すことを勧めています。(Microsoft Learn)
  • APP の Data protection 設定では、Apple managed open-in は制御できません。APP だけで iOS/iPadOS の共有経路を完全に閉じられると考えると、設計を誤ります。(Microsoft Learn)
  • 2020年6月15日より前に作られたポリシーは、tel / telprompt の URL スキーム例外を引きずっている可能性があります。今は Transfer telecommunication data to を使う設計が推奨です。(Microsoft Learn)

iOS/iPadOS アプリ保護ポリシー更新が企業のモバイルセキュリティに与える影響

BYOD と未登録端末の防御力を底上げしやすくなる

Intune の APP は、デバイス登録がなくてもアプリ単位で企業データを守れるのが強みです。Microsoft は、APP が管理端末・非管理端末の両方で企業データ保護に使える一方、未登録端末ではアプリ配布、証明書、Wi-Fi/VPN などは提供されないと説明しています。今回の更新が重要なのは、その「未登録でも守れる範囲」に、Apple Intelligence や画面出力のような新しい漏えい経路への対処が入り、BYOD の実効性が上がるからです。(Microsoft Learn)

これまでの「アプリ間転送の制御」だけでは足りなくなった

これまで iOS/iPadOS の APP は、Send Org data to other apps、コピー/貼り付け、保存先、通知、ブラウザ連携といった「データの行き先」を抑える設計が中心でした。最新ガイダンスではそこに Genmoji、Writing Tools、Screen capture が加わり、「どのアプリに送るか」だけでなく、「AI 補助機能に渡してよいか」「画面として外に出してよいか」まで管理対象が広がっています。Microsoft 365 / Intune を軸にしたモバイルセキュリティ体制にとっては、単なる設定追加ではなく、漏えい対策の粒度が一段細かくなったと見るべきです。(Microsoft Learn)

Conditional Access と組み合わせないと効果が薄い

Microsoft は、APP に対応したアプリだけが業務データへアクセスできるようにするため、Microsoft Entra Conditional Access の併用を前提にしています。APP だけを配っても、アクセス経路そのものが開いたままだと穴が残ります。さらに、APP では Apple managed open-in まで閉じられないため、必要に応じて MDM 側の iOS/iPadOS 制御も組み合わせる設計が必要です。(Microsoft Learn)

管理端末と BYOD を同じポリシーで縛らないほうが安全

同じユーザーに device state を分けずに MAM ポリシーを当てると、BYOD と Intune 管理端末の両方に同じ制御が適用されます。Microsoft は、Intune 管理端末には少し緩め、非 MDM 登録端末にはより厳しめ、あるいは未登録端末だけに MAM を適用する設計を案内しています。今回のように screen capture や AI 機能が業務フローへ直接影響する更新では、この切り分けが特に重要です。(Microsoft Learn)

Genmoji・Writing Tools・Screen capture の実務判断基準

3つの新設定は、一律に Block すればよいわけではありません。「その機能が便利かどうか」ではなく、「そこが実際の漏えい経路になるか」「業務上どうしても必要か」で分けると、運用が安定します。(Microsoft Learn)

Genmoji

Genmoji は、業務データを Genmoji generator に渡せるかどうかを制御する設定です。一般的な企業では、原則 Block が無難です。ブランド運用や社内コミュニケーション施策でどうしても必要な部門だけを別ポリシーに切り出し、顧客名・案件名・機密語を入力しない運用ルールまでセットで決めたときだけ Allow を検討すると失敗しにくくなります。(Microsoft Learn)

Writing Tools

Writing Tools は、モバイル上の文章校正や要約の利便性が高い半面、組織データを Writing Tools に共有できる状態を意味します。社内で生成 AI の利用ルールが未整備なら、まず Block を基準にしておくほうが安全です。逆に、営業下書きや社内メモの整文など、利用目的と入力可能なデータ区分を明文化できる部門では Allow を検討できます。契約審査、取締役会資料、研究メモのように文脈そのものが機密になる業務は、モバイルでも Block を基本にしたほうがよいでしょう。(Microsoft Learn)

Screen capture

Screen capture は、今回もっともサポート問い合わせを生みやすい設定です。Block の対象はスクリーンショットだけではなく、画面録画、Teams / Zoom モバイル共有、AirPlay、QuickTime まで含まれます。つまり、モバイル画面共有が日常業務に入っている営業デモ、現場支援、教育担当に全社一律で Block を入れると、セキュリティは上がっても業務が止まりやすくなります。役員資料、設計情報、財務データ、顧客個人情報を iPhone / iPad で閲覧する部門では Block が有効ですが、画面共有が必要な部門は別ポリシー化を先に考えるほうが現実的です。Microsoft はさらに、今後の iOS 向け Intune App SDK 20.3.0 で、screen capture がブロックされたときのユーザー向けアラート表示も案内しています。(Microsoft Learn)

Microsoft Intune の公式フレームワークで見直す基準

Microsoft は APP の推奨構成を Level 1、Level 2、Level 3 の3段階で整理しています。Level 2 は機密性のある情報へアクセスする一般的なモバイルユーザー向け、Level 3 は大規模なセキュリティ組織や、特に狙われやすい役員・研究部門・法務部門など向けです。多くの企業は、まず Level 2 を全社標準にし、必要部門だけ Level 3 を別ポリシーで持つ形が扱いやすいです。(Microsoft Learn)

まずは Level 2 を標準にする

Level 2 の考え方は、「日常業務は止めすぎず、漏えい経路だけをしっかり狭める」です。iOS/iPadOS では次の組み合わせが基準になります。(Microsoft Learn)

  • Back up org data を Block、Send org data to other apps を Policy managed apps にする。Intune 登録端末で管理アプリ間のファイル受け渡しが必要なら Policy managed apps with OS sharing、iOS の共有シート自体を絞るなら Policy managed apps with Open-In/Share filtering を選ぶと設計しやすいです。(Microsoft Learn)
  • Save copies of org data は Block を基本にし、保存先は OneDrive for Business と SharePoint を中心に必要最小限へ絞ります。公式の Level 2 では Photo Library も候補に入っていますが、機密文書が中心の組織では運用判断で外したほうが安全なことが多いです。(Microsoft Learn)
  • Restrict web content transfer with other apps は Microsoft Edge を基本にします。iOS/iPadOS では他の managed browser は許可されないため、保護ブラウジングを前提にするなら実質 Edge 基準で考えるのが無難です。(Microsoft Learn)
  • Org data notifications は Block org Data が基準です。通知は iPhone / iPad 本体だけでなく、接続されたウェアラブルやスマートスピーカーにも影響し得るため、ここを緩くすると意外な場所で情報が露出します。(Microsoft Learn)
  • Conditional launch では Min OS version を Microsoft アプリの iOS サポート方針に合わせた N-1 基準で Block access、Offline grace period の wipe は 30 日を基準にすると、古い OS や長期間オフライン端末を放置しにくくなります。なお、offline block を 30 分未満にすると、中断が増えやすく Microsoft も推奨していません。(Microsoft Learn)
  • 新しい Genmoji と Writing Tools は、全社標準ではまず Block を置き、Screen capture だけを業務フローに応じて部門別に分けると、利便性と統制のバランスを取りやすくなります。(Microsoft Learn)

高リスク部門は Level 3 を分離する

Level 3 は、高リスクデータを扱う部門や狙われやすい役割に対して、データの入口・出口・端末健全性をさらに厳しくする構成です。iOS/iPadOS では次の追加が実務上の軸になります。(Microsoft Learn)

  • Receive data from other apps を Policy managed apps、Open data into Org documents を Block、Third-party keyboards を Block、Printing org data を Block にして、取り込み・出力・入力補助まで含めて統制を強めます。(Microsoft Learn)
  • アクセス要件では Simple PIN を Block、最小 PIN 長を 6、PIN の定期変更を有効にし、アプリ内認証自体を強くします。(Microsoft Learn)
  • Conditional launch では Jailbroken/rooted devices を Wipe data、Max allowed device threat level を Secured、必要に応じて Max OS version を設定し、脱獄端末やベータ OS 端末を締め出します。Mobile Threat Defense(MTD)を使っている環境では、ここが iOS の高リスク対策として効きやすい部分です。(Microsoft Learn)

iOS/iPadOS アプリ保護ポリシー運用の落とし穴

実務で止まりやすいのは、設定そのものより「前提条件の読み違い」です。特に次の点は見落としやすいので、変更前に必ず確認してください。(Microsoft Learn)

  • 新規ポリシーの既定値だけを見て判断しない。設定ガイド上では新しい3項目の既定値は Allow ですが、既存ポリシーでは従来挙動を維持するため Block に移行されることがあります。(Microsoft Learn)
  • Screen capture を過去の Managed apps ACP でも制御していたなら二重管理です。APP 側だけ変えても、旧 ACP が残っていると結果が変わりません。(Microsoft Learn)
  • アプリ側が必要な Intune SDK を満たしていないと、新設定は期待どおりに効きません。反映確認はポータルの見た目ではなく、後述の App protection status report とデバイス側ログで行うべきです。(Microsoft Learn)
  • Min SDK version は便利そうに見えて、アプリごとに SDK バージョンが異なるため、Microsoft も essential blocking scenarios 以外では慎重な利用を示しています。全アプリ共通で乱用しないほうが安全です。(Microsoft Learn)
  • tel / telprompt などの古い data transfer exemptions が残っていると、設計意図を読み違えやすくなります。電話発信は Transfer telecommunication data to へ寄せたほうが管理しやすいです。(Microsoft Learn)
  • Unmanaged browser protocol や unmanaged の Universal Links 例外は、本当に必要なときだけに絞るべきです。Microsoft は unmanaged 先への Universal Link 例外がデータ漏えいにつながり得ると明示しています。(Microsoft Learn)
  • Offline grace period を短くしすぎると、ユーザーはアプリ再開のたびに中断されやすくなります。厳しさだけで値を詰めると、現場では使われないポリシーになりがちです。(Microsoft Learn)

Microsoft Intune 管理者が反映前にやるべき検証手順

更新内容を理解したら、次は「設定する」より先に「確認できる状態を作る」のが順番です。次の流れで進めると失敗が減ります。(Microsoft Learn)

  1. 既存の iOS/iPadOS APP を棚卸しします。Intune 管理センターの Apps > Protection > 対象ポリシー > Properties > Basics > Apps > Data protection で、対象アプリ、割り当てグループ、device state の分け方、Send Org data to other apps の値、古い screen capture 用 ACP、tel / telprompt 例外の有無を確認します。BYOD と管理端末を同じポリシーで抱えているなら、この段階で分離候補を決めておくと後が楽です。(Microsoft Learn)
  2. 本番一括ではなくリングで試します。Microsoft は APP フレームワークでも、QA 用の事前検証、少人数プレビュー、本番展開という ring 方式を推奨しています。screen capture や Writing Tools はユーザー体験に直接触るため、特に段階展開が有効です。(Microsoft Learn)
  3. Apps > Monitor > App protection status で対象ユーザーの実態を掴みます。ここでは App version、Platform version、iOS SDK version、Last sync などが見られ、データは最低 90 日保持されます。なお iOS 16 以降は Device Name が汎用名になるため、端末特定はユーザー・アプリ・Last sync を組み合わせて行うほうが確実です。(Microsoft Learn)
  4. パイロット端末では Microsoft Edge for iOS/iPadOS から about:Intunehelp を開いて確認します。ログ上では GenmojiConfigurationState、ScreenCaptureConfigurationState、WritingToolsConfigurationState などの値を見られるので、ポータルの設定値と端末の実効値が一致しているかを確認できます。(Microsoft Learn)
  5. 業務シナリオを必ず実機で試します。最低でも、スクリーンショット、画面録画、Teams / Zoom 共有、AirPlay、QuickTime、コピー/貼り付け、Save As、通知表示、ブラウザ遷移、電話番号タップの挙動は確認したいところです。Screen capture と Org data notifications は、思った以上に利用者の体感差が大きい設定です。(Microsoft Learn)
  6. ヘルプデスク向け文書と利用者案内を先に更新します。Microsoft も、ポリシー見直しや helpdesk / 利用者への通知を準備項目として案内しています。特に screen capture を block した環境では、今後の SDK でユーザー向けアラートが表示されるため、「故障ではなく組織ポリシーで止めている」ことがすぐ伝わる FAQ を用意しておくと混乱を減らせます。(Microsoft Learn)

まとめ

今回の Microsoft Intune の iOS/iPadOS アプリ保護ポリシー設定ガイダンス更新は、APP を「アプリ間コピーや保存先を止めるための設定」から、「生成 AI・画面出力・BYOD を含む現実的な漏えい経路を部門別に制御する設定」へ一段引き上げるものです。今すぐやるべきことは、既存 APP と ACP の棚卸し、Level 2 / Level 3 の分け方の決定、そして App protection status report と about:Intunehelp を使った実機検証の3つです。ここまでやってから展開すれば、利便性を落としすぎずに、Microsoft ベースのモバイルセキュリティ体制をかなり堅くできます。(Microsoft Learn)

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次