結論から言うと、会社所有のAndroid端末を複数人で使い、シフトの開始時に利用者を識別したい場合は、Android Enterprise Dedicated DeviceにMicrosoft Entra Shared Device Modeを組み合わせ、Managed Home Screenを認証の入口にする構成が適しています。
この構成では、端末自体は特定ユーザーにひも付けずIntuneで管理し、勤務者はシフト開始時にMicrosoft Entra IDでサインインします。シフト終了時にManaged Home Screenからサインアウトすると、Shared Device Mode対応アプリからもまとめてサインアウトされ、次の利用者へ端末を引き渡せます。(Microsoft Learn)
ただし、Shared Device Modeは端末内のすべてのデータを強制消去する仕組みではありません。安全な運用には、Android Enterprise Dedicated Device、Microsoft Entra Shared Device Mode、Managed Home Screen、各業務アプリの役割を分け、未対応アプリやローカル保存データまで含めて確認する必要があります。
共有Android端末をIntuneとEntra Shared Device Modeで安全に運用する推奨構成
Microsoftが2026年7月に公開したフロントライン端末向けのガイダンスでも、端末の実際の利用形態に合わせてIntuneの登録方法を選ぶことが中心テーマとなっています。単に「共有端末だからキオスクにする」のではなく、端末の所有者、利用者の入れ替わり、必要なアプリ、個人データの扱いを分けて判断することが重要です。(TECHCOMMUNITY.MICROSOFT.COM)
推奨構成は、次の4層で考えると理解しやすくなります。
| 構成要素 | 主な役割 | この機能だけではできないこと |
|---|---|---|
| Android Enterprise Dedicated Device | 会社所有端末をユーザーなしでIntuneへ登録し、アプリ配布、制限、キオスク化、準拠状態を管理する | シフトごとの利用者認証やアプリ横断のサインアウト |
| Microsoft Entra Shared Device Mode | 利用者のサインイン状態を対応アプリ間で共有し、SSOとグローバルサインアウトを実現する | アプリの表示制限、ホーム画面固定、任意アプリのローカルデータ消去 |
| Managed Home Screen | 共有端末用ランチャー、サインイン画面、アプリ一覧、セッションPIN、自動サインアウトを提供する | Shared Device Mode未対応アプリの安全性を保証すること |
| Shared Device Mode対応アプリ | 利用者変更を検知し、前利用者のトークン、キャッシュ、画面表示などを消去する | 未対応アプリや端末共有フォルダー内のデータ消去 |
Android Enterprise Dedicated Deviceは、Intune上では特定ユーザーと関連付けられない「ユーザーレス端末」です。一方、Microsoft Entra Shared Device Modeでは、アプリ利用中の人物をMicrosoft Entra IDで識別できます。つまり、端末管理はデバイス単位、業務アクセスと監査はユーザー単位という分担になります。(Microsoft Learn)
シフト開始から終了までの動き
推奨構成では、利用者の操作は次のようになります。
- 利用者が共有端末を受け取る
- Managed Home ScreenでMicrosoft Entra ID認証を行う
- 必要に応じて、そのシフト中だけ使用するセッションPINを作成する
- Teams、Outlook、EdgeなどのShared Device Mode対応アプリを開く
- 対応アプリでは原則として再認証せず、同じ利用者としてSSOする
- 休憩中はセッションPINで端末を一時保護する
- シフト終了時にManaged Home Screenからサインアウトする
- 対応アプリからもグローバルサインアウトされる
- セッションPINが消去され、次の利用者のサインイン画面へ戻る
Microsoft Entra Shared Device Modeでは、対応アプリのいずれかで行ったサインインやサインアウトを、ほかの対応アプリにも反映できます。Managed Home Screenを入口にすれば、シフト開始と終了の操作場所を一本化しやすくなります。(Microsoft Learn)
Shared Device Modeは「端末全消去」ではない
Shared Device Modeのサインアウトで確実に扱われるのは、主にMicrosoft Entraのアカウント情報と認証トークンです。対応アプリは利用者の変更を検知し、前の利用者が表示していたデータやキャッシュを消去するよう実装する必要があります。
Microsoftの開発者向け資料でも、アプリがフォアグラウンドへ戻るたびに利用者の状態を確認し、利用者が変わっていれば前利用者のデータやキャッシュ表示を消去するよう求めています。Shared Device Mode対応アプリでMSALのサインアウトを実行すると、アプリとデバイスからアカウントおよびキャッシュ済みトークンが削除されます。(Microsoft Learn)
一方、次のようなデータが自動的にすべて消えるとは限りません。
- Shared Device Mode未対応アプリのログイン状態
- アプリが独自に保存したデータベースやキャッシュ
- ダウンロードフォルダーへ保存したファイル
- カメラで撮影した写真
- スクリーンショット
- クリップボードにコピーした情報
- Webアプリが独自に保持するCookieやオフラインデータ
- 通知欄や最近使ったアプリに残る情報
したがって、端末へ導入するアプリは「Microsoft製かどうか」ではなく、Android版がShared Device Modeに対応しているかで判断しなければなりません。
現行のMicrosoft公式資料では、Android向けの対応アプリとして、Microsoft Teams、Viva Engage、Outlook、Power Apps、Microsoft 365、Power BI Mobile、Microsoft Edge、Managed Home Screenが挙げられています。対応状況は更新される可能性があるため、本番導入前に最新の公式一覧を確認してください。(Microsoft Learn)
この構成が向いているケース
Android Enterprise Dedicated DeviceとShared Device Modeの組み合わせは、次のような環境に向いています。
| 利用シーン | 適合度 | 理由 |
|---|---|---|
| 店舗スタッフがシフトごとにタブレットを受け取る | 高い | 個人認証と短時間での引き渡しを両立しやすい |
| 倉庫で複数人がハンディ端末を共有する | 高い | 業務アプリだけを表示し、利用者単位でアクセスを記録できる |
| 医療・介護現場で共用端末から個人別データへアクセスする | 高い | セッションPIN、自動サインアウト、条件付きアクセスを組み合わせやすい |
| 受付端末でTeams、Outlook、業務アプリを利用する | 高い | 対応アプリ間のSSOと一括サインアウトを使える |
| デジタルサイネージや無人案内端末 | 低い | 利用者認証が不要なら通常のDedicated Deviceや単一アプリキオスクで足りる |
| 1人に1台を長期間割り当てる | 低い | Fully Managedなどのユーザー関連付け型が適している |
| ユーザーごとにAndroidのアプリ構成を大きく変える | 低い | Dedicated Deviceのアプリ配布と画面構成は基本的にデバイス単位 |
| Shared Device Mode未対応アプリに機密データを保存する | 低い | サインアウト後のデータ消去を保証しにくい |
この構成では、端末へ配布するアプリやManaged Home Screenのアイコン構成は基本的にデバイスグループ単位です。そのため、利用者Aには3アプリ、利用者Bには5アプリというように、サインインしたユーザーごとにホーム画面を完全に切り替える用途には向きません。
職種ごとに必要なアプリが大きく異なる場合は、次のいずれかで対応します。
- 職種別に端末プールと登録プロファイルを分ける
- アプリのアイコンは共通にし、アプリ内部でロールベースのアクセス制御を行う
- ユーザー関連付け型のAndroid Enterprise Fully Managedを検討する
構築前に確認する要件
端末要件
Android Enterprise Dedicated DeviceをShared Device Modeで登録するには、次の条件を確認します。
- Android 8.0以降
- Android Enterprise対応端末
- Google Mobile Servicesに接続できる端末
- Google Play Protect認定を受けた構成
- 初期化済み、またはShared Device Mode対応アプリをクリーンに再導入できる状態
- IntuneからGoogleの各種サービスへ通信できるネットワーク
Microsoftの公式資料では、Android Enterprise Dedicated DeviceにAndroid 8.0以降、GMS接続、Android Enterprise対応が必要とされています。Shared Device Modeを設定する端末についても、初期化または既存のMicrosoftアプリと対応アプリの再インストールが推奨されています。(Microsoft Learn)
すでに通常のDedicated Deviceとして登録済みの端末をShared Device Modeへ変更する場合は、設定を上書きするだけで済ませず、端末のワイプと再登録を前提に計画する方が安全です。
テナント側の要件
事前に次の準備が必要です。
- IntuneのMDM機関が設定済み
- IntuneとManaged Google Playが接続済み
- 共有端末専用のデバイスグループ
- Android Enterprise用のコンプライアンスポリシー
- Microsoft Entra IDの利用者アカウント
- 利用するMicrosoft 365サービスのユーザーライセンス
- 条件付きアクセスを使う場合は必要なMicrosoft Entraライセンス
Android Enterprise Dedicated DeviceはIntuneのデバイス専用ライセンスの対象ですが、デバイス専用ライセンスでは条件付きアクセス、アプリ保護ポリシー、ユーザーベースのメールや予定表管理などはサポートされません。OutlookやTeamsを利用者単位で使い、条件付きアクセスやMAMも適用する構成では、デバイス専用ライセンスだけで足りると判断せず、ユーザー側のライセンスを確認してください。(Microsoft Learn)
Intuneでの設定手順
利用するアプリを対応状況別に分類する
最初に、端末へ入れるアプリを次の3種類に分けます。
| 分類 | 判断基準 | 対応方針 |
|---|---|---|
| Shared Device Mode対応アプリ | 公式に対応が確認できる | 基本構成に採用する |
| 自社開発アプリ | MSALのShared Device Mode対応を実装できる | 利用者変更とキャッシュ消去を実装してテストする |
| 未対応のサードパーティーアプリ | グローバルサインアウトに参加しない | 機密データを扱わせないか、独自の消去処理を検証する |
自社開発のAndroidアプリは、MSALのシングルアカウントモードでShared Device Modeに対応させる必要があります。マルチアカウントモードはShared Device Modeでは使用できません。アプリ起動時やフォアグラウンド復帰時に利用者変更を検知し、前利用者のデータを消去する実装も必要です。(Microsoft Learn)
Managed Google Playからアプリを追加する
Intune管理センターで、Managed Home Screenと業務アプリをManaged Google Playから追加します。
一般的な操作経路は次のとおりです。
アプリを開くすべてのアプリを開く作成を選ぶ- アプリの種類で
Managed Google Playアプリを選ぶ - Managed Home Screenを検索して追加する
- Teams、Outlook、Edgeなど必要なアプリも追加する
- Intuneへ同期する
- 共有端末のデバイスグループに
必須で割り当てる
Managed Google Playアプリは、Intune内のManaged Google Play画面から選択して同期します。Android Enterprise Dedicated Deviceへ導入するアプリは、基本的にデバイスグループへ必須アプリとして割り当てます。(Microsoft Learn)
Shared Device Mode用の登録プロファイルを作成する
Intune管理センターで、Android Enterprise Dedicated Device用の登録プロファイルを作成します。
デバイスを開く登録またはDevice onboarding > Enrollmentを開くAndroidタブを選ぶ会社所有の専用デバイスを開くプロファイルの作成を選ぶ- トークンの種類で、Microsoft Entra ID Shared Modeを含む専用デバイスを選ぶ
- トークンの有効期限を設定する
- 必要に応じて端末名テンプレートを設定する
- 共有端末専用のデバイスグループを指定する
- プロファイルを作成する
英語表示では、トークンの種類としてCorporate-owned dedicated device with Microsoft Entra ID shared modeを選択します。このトークンで登録すると、登録中にMicrosoft AuthenticatorがShared Device Mode用に構成されます。Microsoft AuthenticatorとCompany Portalは、この登録方式では自動的にインストールされます。(Microsoft Learn)
通常のCorporate-owned dedicated deviceを選ぶと、端末はユーザーレスで登録されますが、Shared Device Modeによるアプリ横断のSSOとサインアウトは有効になりません。トークンの種類を間違えないようにしてください。
端末を初期化して登録する
作成した登録トークンを使って端末を登録します。少数の検証端末ではQRコード登録、大量展開ではAndroid Zero-touch enrollmentや対応するOEMの自動登録サービスを使うと効率的です。
端末の登録方法として、QRコード、トークン入力、NFC、Google Zero-touch enrollment、Samsung Knox Mobile Enrollmentなどが利用できます。登録中は処理が完了するまで端末を再起動しない方が安全です。(Microsoft Learn)
登録後は、Intune上で次の状態を確認します。
- 端末が想定した登録プロファイルに属している
- Microsoft Authenticatorが自動インストールされている
- Company Portalが自動インストールされている
- Managed Home Screenがインストールされている
- 必要な業務アプリがすべてインストールされている
- 端末がMicrosoft Entra IDへ登録されている
- コンプライアンス状態が評価されている
Multi-appキオスクを設定する
Managed Home Screenを共有端末のランチャーとして使う場合は、Android Enterpriseのデバイス制限プロファイルでMulti-appキオスクを設定します。
一般的な操作経路は次のとおりです。
デバイス構成新しいポリシーの作成- プラットフォームで
Android Enterprise - プロファイルの種類で
テンプレート デバイスの制限デバイス エクスペリエンス- 登録プロファイルの種類で
専用デバイス - キオスクモードで
Multi-app - 利用を許可するアプリを追加する
Managed Home Screen自体と、Multi-appキオスクで表示するすべてのアプリを、対象デバイスグループへ必須で割り当ててください。キオスクポリシーへ追加したアプリが必須配布されていないと、端末がロック状態になり、利用できなくなることがあります。(Microsoft Learn)
端末を安全に固定するため、少なくとも次の設定を検討します。
- ホーム画面のロック：有効
- エンドユーザーによる端末設定へのアクセス：ブロック
- 不要なシステムアプリ：無効化または非表示
- 個人Googleアカウントの追加：ブロック
- USBデバッグ：ブロック
- 不明な提供元からのアプリ導入：ブロック
- スクリーンショット：業務要件に応じてブロック
- ファイル共有：業務要件に応じて制限
- ホームボタン：必要に応じて許可
- Overviewボタン：原則として許可しない
Managed Home Screenでシフト認証を設定する
Managed Home Screenの詳細設定は、デバイス制限プロファイルとアプリ構成ポリシーの両方から行えます。設定項目がある場合はデバイス制限プロファイルを優先し、そこにない項目はManaged Home Screenのアプリ構成ポリシーで補うと管理しやすくなります。(Microsoft Learn)
アプリ構成ポリシーは、一般的に次の経路から作成します。
アプリ構成- 管理対象デバイス向けのAndroidポリシーを追加
- 関連付けるアプリとして
Managed Home Screenを選択 - 構成デザイナーまたはJSONで設定する
- 共有端末のデバイスグループへ割り当てる
推奨するManaged Home Screen設定
以下はMicrosoftの既定値ではなく、シフト制の共有端末を安全に運用するための初期設計例です。業務中の操作頻度や端末の設置場所に合わせて調整してください。
| 設定 | 推奨初期値 | 目的 |
|---|---|---|
| サインインを有効化 | 有効 | Managed Home Screenを利用者認証の入口にする |
| サインインの種類 | Microsoft Entra ID | Shared Device Mode対応アプリへSSOする |
| セッションPIN | 有効 | 同じ利用者が休憩後に素早く復帰できるようにする |
| PINの複雑性 | 複雑な数字のみ | 入力速度と推測耐性を両立する |
| PINの最小長 | 6桁程度 | 4桁より推測されにくくする |
| PIN試行回数 | 5回程度 | 総当たりを防ぎ、超過時にサインアウトする |
| スクリーンセーバー後のPIN要求 | 有効 | 放置端末へのアクセスを防ぐ |
| PIN要求までの非アクティブ時間 | 60～120秒 | 短時間の放置を保護する |
| 自動サインアウト | 有効 | サインアウト忘れを補う |
| 自動サインアウトまでの時間 | 300～900秒 | 業務とリスクに合わせて調整する |
| サインアウト前カウントダウン | 30～60秒 | 作業中の誤サインアウトを防ぐ |
| 認証画面中のアプリ抑制 | 有効 | 前利用者の通知や画面表示を抑える |
| サインイン前に使えるアプリ | 原則なし | 未認証状態での業務アプリ利用を防ぐ |
| ホーム画面のロック | 有効 | アイコン配置の変更を防ぐ |
| 端末設定へのアクセス | ブロック | キオスクからの離脱を防ぐ |
Managed Home ScreenのセッションPINは、Microsoft Entra IDのパスワードを置き換えるものではありません。利用者がMicrosoft Entra IDでサインインした後、そのシフト中だけ端末を再開するためのローカルPINです。サインアウトするとセッションPINも消去されます。(Microsoft Learn)
休憩時のロックとシフト終了時のサインアウトを分ける
共有端末では、次の2つを混同しないことが重要です。
| 操作 | 使用場面 | 結果 |
|---|---|---|
| セッションPINによる再ロック | 休憩、短時間の離席 | 同じ利用者のセッションを維持する |
| Managed Home Screenからのサインアウト | シフト終了、端末返却 | 対応アプリを含めて利用者セッションを終了する |
休憩のたびにグローバルサインアウトさせると、業務再開時の認証負担が大きくなります。反対に、シフト終了時にセッションPINだけでロックすると、次の利用者へ前利用者のセッションを引き継ぐ危険があります。
運用マニュアルでは、離席はロック、返却はサインアウトと明確に分けてください。
見落としやすいセキュリティ設定
Overviewボタンを有効にしない
Managed Home Screenを使っていても、AndroidのOverviewボタンを有効にすると、利用者がサインイン画面やセッションPIN画面を無視できる場合があります。
同様に、ステータスバーでシステム通知を完全に表示する設定も、認証画面を回避できる状態につながることがあります。認証を必須にする場合は、ナビゲーションをホームボタンのみにし、Overviewボタンは無効にする構成が安全です。(Microsoft Learn)
端末設定へのアクセスをブロックする
OverviewボタンとAndroid設定画面へのアクセスが同時に許可されていると、利用者がネットワークやセキュリティ設定を変更したり、端末リセットへ進んだりできる可能性があります。
キオスク端末では、エンドユーザーによる端末設定へのアクセスをブロックし、Wi-FiやBluetoothなど必要な機能だけをManaged Home Screenから限定的に提供してください。(Microsoft Learn)
自動サインアウト用の権限を確認する
Managed Home Screenの自動サインアウトには、オーバーレイ権限が必要です。Android 14以降では、正確なアラームの権限も必要になります。
対応OEMでは、Samsung Knox Service Plugin、Zebra OEMConfig、Honeywell UEMConnectなどのOEMConfigを使い、Managed Home Screenに必要な権限を自動付与できます。自動付与できない場合は、初回起動時の権限要求がキオスク運用を妨げないか検証してください。(Microsoft Learn)
また、デバイス制限で通知ウィンドウを無効にすると、オーバーレイを利用する自動サインアウトが正しく機能しない場合があります。セキュリティ設定を強くするほど安全になるとは限らないため、自動サインアウトの実機テストが必要です。(Microsoft Learn)
条件付きアクセスで準拠端末だけを許可する
Shared Device Modeを利用すると、ユーザーが共有端末からMicrosoft 365へアクセスする際に、端末の準拠状態を条件付きアクセスで評価できます。
Android Enterprise Dedicated Device用のコンプライアンスポリシーは、ユーザーグループではなくデバイスグループへ割り当てることが重要です。Microsoftの資料でも、専用デバイスのコンプライアンスポリシーはデバイスグループを対象にするよう案内されています。(Microsoft Learn)
基本的な構成例は次のとおりです。
- Android Enterprise用のコンプライアンスポリシーを作成する
- 共有端末のデバイスグループへ割り当てる
- ルート化端末を非準拠にする
- 最低OSバージョンやセキュリティパッチ要件を設定する
- Google Play Protectや脅威レベルを必要に応じて評価する
- Microsoft Entraの条件付きアクセスをレポート専用で作成する
- 対象アプリに対して
準拠としてマークされたデバイスを要求するを設定する - サインインログで影響を確認してから有効化する
Shared Device Modeを使わずに登録したDedicated Deviceでは、Intune上で端末が準拠していても、利用者が準拠端末を要求する条件付きアクセス対象リソースへサインインできないことがあります。ユーザー認証と端末準拠を組み合わせる点でも、Shared Device Modeを選ぶ意味があります。(Microsoft Learn)
アプリ保護ポリシーでデータ流出を抑える
Shared Device Mode対応のAndroid Enterprise Dedicated Deviceでは、対応するアプリにIntuneアプリ保護ポリシーを適用できます。たとえば、次の制御を検討します。
- 管理対象外アプリへのコピーと貼り付けを制限する
- ローカルファイルへの保存を制限する
- 管理対象外アプリへのデータ転送を制限する
- 個人アカウントの追加を制限する
- Webリンクを管理対象のMicrosoft Edgeで開く
- 通知に機密情報を表示しない
Microsoftのフロントライン端末向け資料でも、Shared Device Mode未対応アプリへの情報流出を防ぐため、コピー、ローカル保存、データ転送を制限するアプリ保護ポリシーが案内されています。なお、デバイス専用ライセンスだけではアプリ保護ポリシーを利用できないため、ライセンス構成も併せて確認してください。(Microsoft Learn)
QRコードとPINでシフト開始を速くする方法
利用者数が多く、長いメールアドレスやパスワードの入力が負担になる場合は、Microsoft Entra IDのQRコード認証も検討できます。Managed Home ScreenはMicrosoft Entra IDのQRコード認証をネイティブにサポートしています。(Microsoft Learn)
QRコード認証では、利用者固有のQRコードを社員証などに印刷し、数字のPINと組み合わせてサインインします。現行仕様ではQRコード認証は既定で無効であり、PINは8～20桁です。また、単一要素認証として扱われるため、準拠端末、利用場所、対象アプリなどの条件付きアクセスと組み合わせることが推奨されています。(Microsoft Learn)
導入時には次の制約も確認してください。
- 最初の利用前に、既存の認証方法で一度サインインする必要がある
- QRコードとPINの一括発行は現行仕様ではサポートされない
- QRコードを紛失した場合の失効手順が必要
- 一時QRコードの発行運用を決める必要がある
- QRコード認証だけを全社員へ一律に有効化しない
- 職場外からのアクセスにはMFAなど別の強い認証を要求する
QRコード認証は入力負荷を大きく下げられますが、Shared Device Modeそのものとは別の認証方法です。まず通常のMicrosoft Entra ID認証でShared Device Modeを完成させ、その後にQRコード認証を追加すると、問題を切り分けやすくなります。
業種別の自動サインアウト設計例
自動サインアウト時間は、短ければ安全とは限りません。業務中に端末を操作しない時間が長い職場では、短すぎる設定が再認証の多発につながります。
| 利用環境 | PIN再要求の目安 | 自動サインアウトの目安 | 設計上の注意 |
|---|---|---|---|
| 店舗レジ周辺 | 60～120秒 | 300秒前後 | 顧客から見える位置では短めにする |
| 倉庫・物流 | 120～300秒 | 600～900秒 | 移動や荷役中の非操作時間を考慮する |
| 医療・介護 | 60秒前後 | 300秒前後 | 機微情報の表示を最優先する |
| 工場の固定端末 | 120～300秒 | 600秒前後 | 手袋使用時の再入力負担を確認する |
| 受付・接客端末 | 60秒前後 | 300秒前後 | 前利用者の通知と最近使ったアプリを重点確認する |
自動サインアウトは「最後の安全装置」であり、シフト終了時の手動サインアウトを不要にするものではありません。勤務終了時には必ずサインアウトする運用を基本とし、忘れた場合に自動サインアウトが働く設計にします。
よくある失敗と確認ポイント
Shared Device Mode対応トークンを選んでいない
通常のDedicated Device用トークンで登録すると、端末はIntune管理下に入りますが、Shared Device Modeは有効になりません。
Intuneの登録プロファイルで、Microsoft Entra ID Shared Modeを含むトークンを選択したか確認してください。登録済み端末では、ワイプして正しいトークンで再登録する方が確実です。
Managed Home Screenのサインインを有効にしていない
Shared Device Modeで端末を登録しても、Managed Home Screenのサインインを有効化が無効なら、ホーム画面で利用者認証を要求できません。
サインインを有効化を有効にし、サインインの種類をMicrosoft Entra IDに設定します。(Microsoft Learn)
一部のアプリだけSSOまたはサインアウトされない
原因として、次の可能性があります。
- アプリがShared Device Modeに対応していない
- アプリが古い
- Shared Device Mode有効化前からアプリがインストールされている
- 自社アプリがマルチアカウントモードで実装されている
- 自社アプリが利用者変更時にキャッシュを消去していない
- アプリ独自のWebViewやCookieが残っている
Microsoft製アプリでも、Android版の公式対応一覧に含まれるかを確認してください。
Multi-appキオスクへ追加したアプリが起動しない
キオスクポリシーへアプリを追加しただけでは不十分です。
次の3点をそろえます。
- アプリをIntuneへ追加済み
- 共有端末のデバイスグループへ必須で割り当て済み
- Multi-appキオスクの許可アプリへ追加済み
Managed Home Screen自体も、対象デバイスグループへの必須割り当てが必要です。(Microsoft Learn)
サインイン画面やセッションPINを回避できる
Overviewボタンや完全なシステム通知表示が有効になっていないか確認します。
認証必須の共有端末では、原則として次の構成にします。
- ホームボタンのみ許可
- Overviewボタンは無効
- Android設定画面へのアクセスはブロック
- 通知は必要最小限
- 認証中はアプリを抑制
自動サインアウトが動作しない
Android 14以降では正確なアラーム権限を確認します。併せて、オーバーレイ権限、通知ウィンドウの制限、OEMConfigの適用状態も確認してください。(Microsoft Learn)
条件付きアクセスで全員がブロックされる
次の順で確認します。
- 端末がIntuneで準拠になっているか
- コンプライアンスポリシーがデバイスグループへ割り当てられているか
- Shared Device Modeとして登録されているか
- Microsoft Entraのサインインログに端末情報が渡っているか
- 条件付きアクセスをレポート専用で検証したか
- 緊急アクセス用アカウントを除外しているか
- 必要なユーザーライセンスがあるか
本番展開前に行う引き渡しテスト
共有端末では、設定画面上の「成功」だけでなく、利用者Aから利用者Bへ実際に引き渡して確認する必要があります。
最低限、次のテストを実施してください。
| テスト | 合格条件 |
|---|---|
| 利用者AがManaged Home Screenへサインイン | 対応アプリへSSOできる |
| 利用者Aが複数アプリを使用 | すべて利用者Aのデータだけが表示される |
| 端末を短時間放置 | セッションPINが要求される |
| Managed Home Screenからサインアウト | 対応アプリから利用者Aがサインアウトされる |
| 最近使ったアプリを確認 | 利用者Aの画面が残っていない |
| 通知欄を確認 | 利用者Aの氏名やメッセージ本文が残っていない |
| ダウンロード領域を確認 | 利用者Aのファイルが残っていない、またはアクセスできない |
| 利用者Bがサインイン | 利用者Aのデータへアクセスできない |
| 自動サインアウトまで放置 | 設定時間後にグローバルサインアウトされる |
| 端末を再起動 | Managed Home Screenで再度サインインを要求される |
| 端末を非準拠にする | 条件付きアクセス対象リソースへのアクセスが拒否される |
| ネットワークを切断 | 未認証状態で機密アプリへアクセスできない |
| QRコードを失効する | 失効したQRコードでサインインできない |
特に重要なのは、利用者Aがサインアウトした直後に利用者Bが同じアプリを開くテストです。トークンだけでなく、画面表示、通知、検索履歴、ダウンロード、WebView、アプリ内キャッシュまで確認します。
安全に展開するための進め方
最初から全端末へ配布せず、次の順序で進めると失敗を減らせます。
- 利用予定アプリのShared Device Mode対応状況を一覧化する
- 機密データがローカルへ残る経路を洗い出す
- 共有端末専用の登録プロファイルとデバイスグループを作る
- 2～3台をQRコードで登録して検証する
- 利用者Aと利用者Bによる引き渡しテストを行う
- セッションPINと自動サインアウト時間を現場で調整する
- コンプライアンスポリシーをデバイスグループへ適用する
- 条件付きアクセスをレポート専用で検証する
- 操作マニュアルに「離席はロック、返却はサインアウト」と明記する
- 検証後にZero-touch enrollmentなどで台数を拡大する
共有Android端末で個人を識別しながら安全に運用するポイントは、端末をユーザーに関連付けることではありません。端末はDedicated Deviceとしてデバイス単位で管理し、利用者はShared Device Modeのセッションとしてシフトごとに認証することです。
そのうえで、Managed Home Screenをサインインとサインアウトの共通入口にし、セッションPIN、自動サインアウト、準拠端末を要求する条件付きアクセスを組み合わせます。最後に、Shared Device Mode未対応アプリやローカル保存データが残らないことを、利用者交代テストで確認してから本番展開してください。
コメント