小さな会社を Microsoft 365 で回していて、全員のスマホで仕事のメールを読めるようにしたいなら、一見シンプルに見えて実はそうではない問いにぶつかる:自分の所有物ではないデバイス上で、会社のデータをどう守るのか?

答えは、明確なトレードオフを持つ、よく定義されたツールの積み重ねだ。正しく使えば、同じ一台のスマホの上で、会社のデータには強力な保護を、個人のデータには完全なプライバシーを与えられる。これは、その概念とトレードオフ、私たちが使った具体的なセットアップ — そしてそこにたどり着くまでにぶつかった問題たちのガイドだ。問題は、いくつもあったのだから。

なぜわざわざやるのか — 事実

これをきちんとやる価値がある、いくつかの率直な理由:

スマホはすでに個人のものだ。小さな会社は会社支給のハードウェアを配らない。みんなポケットの中のデバイスでメールや Teams をチェックしている。つまり、管理していようがいまいが、そのデバイスはすでにスコープの中にある。
管理されていないアクセスは、現実のデータ経路だ。放置すれば、会社のメールやファイルは、暗号化要件も PIN もなく、データのコピー先を制御する手段もなく、スマホを紛失したり人が辞めたりしたときに削除する方法もないアプリの中に置かれることになる。
私たちは重要なデータを預かっている。プレイヤー資金と個人情報を扱うプラットフォームを運営している以上、社内のアクセスもベストエフォートではなく、定義された基準(CIS/SOC 2 スタイルのコントロール)で守る。
プライバシーは「あれば嬉しい」ではなく要件だ。何をやるにせよ、IT の手が誰かの個人のアプリ、写真、メッセージ、位置情報にまで届くようなことがあってはならない。

ゴールは具体的だった:スマホ上の会社データへのあらゆる経路が、定義されたセキュリティ基準を満たすこと。ただし、その周りの個人デバイスは管理しない。

問題を正確に言うと

2 つの要件が同時に成り立つ:

会社のデータには保護が必要 — 暗号化され、アクセス制御され、スマホの紛失や退職の際には削除できること。
個人のスマホは本人のもの — 写真、チャット、アプリ、位置情報はプライベートなまま、IT の手の届かないところにあること。

モバイルデバイス管理は、この両方を同時に満たすために作られたツール群だ。このガイドの残りは、そのツールボックスと、ピースがどう組み合わさるかの話だ。

ツールボックス:スマホを管理する 3 つの方法

Microsoft Intune が提供するのは、スイッチではなくスペクトラムだ:

1. MAM — モバイルアプリケーション管理はアプリを管理する。仕事のアプリだけを保護し、スマホの残りには手を触れない。登録(エンロール)は不要。

2. MDM — モバイルデバイス管理はデバイスを管理する。これには 2 つの明確に異なるフレーバーがある:

仕事用プロファイル / ユーザー登録 — 個人のスマホ上に作られる、独立した暗号化済みの仕事用コンテナ。IT が管理するのはコンテナだけ。
フル管理 — IT がデバイス全体を管理する。会社所有のハードウェア向けであって、個人のスマホには不適切。

多くのチームは、選択肢 1 と選択肢 2 の「フル管理」の端だけを検討し、両方を却下して、ゆるい何かで妥協する。本当に使えるのは、真ん中にある選択肢だ。

概念 1:MAM / アプリ保護

Intune のアプリ保護ポリシーが MAM のレイヤーだ。Outlook のようなアプリに適用されたポリシーは:

アプリ内の会社データを暗号化する。
開くのに PIN か生体認証を要求する。
会社データから個人アプリへの copy、Save As、Open in をブロックする。
会社データだけの選択的ワイプを可能にする。個人データには一切触れない。

このどれも、デバイスの登録を必要としない。スマホは完全に個人のままで、管理されるのは仕事のアプリだけだ。多くの BYOD ケースにはこれで十分 — そして、私たちの出発点でもあった。

概念 2:コンプライアンスは登録を前提とする

すべてをつなぐ概念がデバイスのコンプライアンス(準拠)だ。

デバイスが「準拠」しているとは、管理に登録されていて、かつあなたが定義した正常性ルール — ディスク暗号化が有効、画面ロックが設定済み、OS にパッチ適用済み、root 化されていない、など — を満たしている状態のことだ。コンプライアンスとは、デバイスが報告し、管理側が検証する状態である。

ポイントはここだ:一度も登録されていないデバイスのコンプライアンスは評価できない。MAM の前提は「登録なし」なので、MAM のみのスマホはアプリレベルでは保護されていても、決して「準拠」にはなれない — チェックすべき登録済みの何かが存在しないからだ。Require compliant device と「登録なし」は、設計上、相互に排他なのだ。

デバイスレベルの保証が欲しいなら、デバイスは何かに登録されていなければならない。それが指し示すのは、真ん中の選択肢だ。

概念 3:仕事用プロファイル

Android では、真ん中の選択肢は(Android Enterprise による)仕事用プロファイルだ。iOS での相当物はユーザー登録。モデルはこうだ:

仕事用プロファイルとは、個人のスマホ上に作られる、独立した暗号化済みコンテナである。IT はそのコンテナの中身だけを管理する。その外側にあるもの — 個人のアプリ、写真、メッセージ、アカウント — は、IT が見ることも、触れることも、ワイプすることもできない空間にある。

仕事のアプリは、個人のホーム画面の隣にバッジ付きのセットとして現れ、コンテナ内にサンドボックス化される。デバイスは、仕事用コンテナにスコープを絞った形で登録され、準拠した状態になる。個人データはプライベートのまま。ここでの「登録」が意味するのは、会社がコンテナを管理するということであって、デバイスを管理するということではない。

概念 4:条件付きアクセス

Microsoft Entra の条件付きアクセス(CA)がアクセスのゲートだ。サインインを許可する前に、あなたが定義した条件をチェックする。ここで関係する付与(グラント)は 2 つ:

Require app protection — アプリに MAM ポリシーが適用されていればアクセスを許可。MAM とペアになる。
Require compliant device — デバイスが登録済みかつ健全であればアクセスを許可。MDM / 仕事用プロファイルとペアになる。

どのモデルを使うのかを強制する場所が CA だ。グラントを変えれば、アクセスの基準が変わる。

私たちが辿った道

モデルが頭に入っていれば、構築はストレートだ:

MAM から始める。仕事のアプリにアプリ保護を適用し、アプリ保護を要求する CA ルールを足す。もっとも軽いタッチ。
必要な保証を決める。「アプリが保護されている」で十分なら、ここで止まっていい — それも正当な選択だ。私たちはデバイスレベルの保証が欲しかった。
Android Enterprise を有効化する。Managed Google Play をテナントにリンクする。一度きりの接続で、仕事用プロファイル登録が解放される。
スマホを個人所有の仕事用プロファイルとして登録する。バッジ付きの暗号化されたワークスペースが作られ、個人側には手が付かず、デバイスは数分以内に compliant を報告する。
仕事のアプリを Managed Google Play から配信する。Outlook、Teams、Edge、Office アプリを承認して割り当てれば、コンテナの中にインストールされる。
CA のグラントを移す。Require app protection から Require compliant device へ — ラップトップに使っているのと同じ基準だ。

これがきれいなバージョン。実際に起きたことはこうだ。

ぶつかった問題と、その解決

1. 管理対象アプリがすべて「デバイスが準拠していません」でブロックされた。私たちの MAM アプリ保護ポリシーには、条件付き起動ルール appActionIfDeviceComplianceRequired が block に設定されて載っていた。緩めようとしても、Intune は block か wipe しか受け付けない — API は null も warn も拒否する。概念 2 と組み合わせると、これは閉じたループだ:ポリシーは準拠デバイスを要求し、MAM のみのスマホは決して登録されず、だから決して準拠にならず、だからすべてのアプリがブロックされ、Company Portal は登録を試み続ける。しかもクライアント側で強制されるため、Entra のサインイン失敗としては一切現れない — 診断を難しくするディテールだ。

解決策:ゲートと戦うのをやめる。デバイスを(仕事用プロファイルで)登録して実際に準拠できるようにし、そのプラットフォームでは MAM から移行する(問題 5)。

2. Company Portal:「登録の要件を満たしていません」。Android Enterprise が接続される前は、仕事用プロファイルの登録経路がそもそも存在せず、登録の試みには着地する場所がなかった。

解決策:Managed Google Play を接続して Android Enterprise をバインドする。この 1 つの接続こそが、仕事用プロファイル登録を可能にする。

3. Google アカウントの競合 — いちばん時間を食ったステップ。Managed Google Play のバインドには、エンタープライズのオーナーとなる Google アカウントを使う。私たちのビジネスメールはすでに個人の Google アカウントに紐付いており、Google はこれを競合するアカウントとして扱う — 同じアドレスで組織/Workspace の管理者を作らせてくれないのだ。これは見落としやすく、そしてすべてを止める。

解決策:まず競合を解消する。Google の競合アカウントのプロセスでそのメールアドレスを解放する(そのアドレス上の既存の個人 Google アカウントをリネームするか閉鎖する)か、Google への登録歴が一切ない専用アカウントを使う。ここには本気で時間を見積もっておくこと — 小さなチームが初日に詰まる可能性がもっとも高いのはここで、しかも Intune とは何の関係もない。

4. 登録後、仕事用プロファイルが空だった。仕事用プロファイルのアプリは、個人側から引き継がれない。作りたてのコンテナには何も入っていない。

解決策:Managed Google Play でアプリを承認し、グループに Required(自動インストール)または Available(仕事用プロファイルのストアからのセルフインストール)として割り当てる。すると、バッジ付きアプリとしてコンテナに現れる。

5. デバイスが準拠になった後でも、まだ「準拠していない」。デバイスは compliant を報告するようになったのに、Outlook はまだ拒否した。原因:MAM アプリ保護ポリシーが、いまや仕事用プロファイルで MDM 管理されている同じアプリにまだ適用されたままで、そのデバイスコンプライアンスのゲートが登録と衝突していたのだ。MAM と MDM は、同じアプリを共同管理したがらない。

解決策:プラットフォームごとに 1 つのモデルにコミットする。私たちは Android のアプリ保護ポリシーの割り当てを解除し、Android の条件付きアクセスのグラントを Require app protection から Require compliant device に切り替えた。仕事用プロファイルのデバイスはこれを直接満たすので、衝突する MAM のゲートはもう残っていない。

6. 自分たちのポリシーが自分たちの管理ツールをブロックした — AADSTS530033。Intune の変更を自動化していたとき、管理者のサインインが拒否された:条件付きアクセスがデバイスコードログインを拒んだのだ。そのトークンは準拠デバイスに紐付いていないから。

解決策:特権作業は、すでに準拠しているデバイスから実行し、トークンがデバイスに紐付くようにする — たとえば、管理されたマシンから Connect-MgGraph を対話的に実行する。ここから得られる学びはポジティブだ:あなたの条件付きアクセスがデバイスコードのログインを止められるなら、それは正しく構成されている。

AI と共に作ることについて

私たちは公の場で作っていて、運用も含めて AI と共に作っている。AI は、構成作業を多くの分岐にわたって素早く進めるのが得意だ。私たちはそれに 1 つのルールを組み合わせている:AI が提案し、人間が決める — 特にセキュリティに触れるものについては。この分業が、小さなチームに大きなチームのペースで動くことを可能にしてくれる。

持ち帰るべきメンタルモデル

MAM はアプリを管理し、MDM はデバイスを管理する。必要な保証に基づいて選ぶこと。
コンプライアンスは登録を前提とする。一度も登録されていないデバイスは検証できない。だから Require compliant device と「登録なし」は両立しない。
仕事用プロファイルは真ん中の選択肢。管理するのはデバイスではなくコンテナ — デバイスのコンプライアンスと個人のプライバシーを同時に。
アプリごとにモデルは 1 つ。MDM に移したアプリに MAM ポリシーを残さないこと。レーンを 1 つ選べ。
条件付きアクセスが基準を決める。自分のモデルに合ったグラントを選び、あとは強制に任せる。

私たちがいくつかの仕事用インボックスにここまでの手間をかけるのは、モバイルアクセスを守るこの規律と同じものが、プラットフォーム上のあなたのアカウント、あなたの資金、あなたのデータを守っているからだ。セキュリティとは、顧客から見える部分だけでなく、内部の仕事全体を貫く習慣である。

それでは、テーブルでお会いしましょう。

BYOD を正しくやる:Intune で個人のスマホを守るフィールドガイド