Intuneのキオスク登録で「利用者が必要なアプリを選んで追加できない」「利用者ごとの証明書を後から配れない」と困るケースがあります。これは設定不足ではなく、キオスク向けの専用デバイスが、特定業務に固定するユーザー非関連付けの端末として設計されているためです。
ただし、アプリや証明書を一切追加できないわけではありません。管理者がアプリを「必須」として端末へ追加配布したり、Wi-FiやVPN用のデバイス証明書を後から配布したりすることは可能です。できない、または適さないのは、Company Portalから利用者が選ぶ「利用可能アプリ」と、現在端末を使っている人にひもづく利用者別証明書です。Android Enterpriseの専用デバイスでは、インストールできるアプリの割り当て方式が「必須」に限定されています。(Microsoft Learn)
複数人で共有しながら個人を識別したい場合は、Microsoft Entra shared device modeを採用します。利用者ごとの証明書や自由なアプリ選択まで必要なら、キオスク登録に機能を継ぎ足すのではなく、ユーザー関連付けのあるAndroid Enterprise fully managedなどへ登録方式を切り替えるのが基本です。
Intuneキオスクで利用可能アプリや利用者証明書が使えない理由
Intuneの設計を理解するときは、次の2つを分けて考える必要があります。
- Android Enterprise専用デバイス登録：端末を特定ユーザーに関連付けず、組織所有の業務端末として管理する登録方式
- キオスクモード：表示するアプリやホーム画面、ナビゲーション操作を制限する端末設定
Intuneでは、専用デバイスだけでなく、ユーザー関連付けのあるfully managedデバイスにもキオスクモードを設定できます。そのため、「キオスクだから利用可能アプリを使えない」というより、ユーザー非関連付けの専用デバイスとして登録していることが主な制約要因です。(Microsoft Learn)
Microsoftが示すAndroid Enterprise専用デバイスは、デジタルサイネージ、チケット発行、在庫管理など、単一または限定された業務を実行する端末です。標準の専用デバイスはユーザーアカウントなしで登録され、特定ユーザーには関連付けられません。(Microsoft Learn)
この前提から、次の制約が生まれます。
| 項目 | 専用デバイスでの扱い |
|---|---|
| 管理者によるアプリの追加配布 | 可能。「必須」で端末グループへ割り当てる |
| 利用者によるアプリの選択インストール | 非対応 |
| キオスク画面へのアプリ追加 | 可能。配布とキオスク許可リストの両方を更新する |
| Wi-Fi・VPN用デバイス証明書 | 配布可能 |
| UPNなどを使った利用者別証明書 | ユーザー情報を取得できないため不適合 |
| 専用デバイス上のSCEP証明書によるアプリ認証 | サポート対象外 |
| 利用者ごとのアプリサインイン | Microsoft Entra shared device modeで対応可能 |
| Company Portalからのセルフサービス導入 | 専用デバイスでは利用しない |
「利用可能アプリ」が専用デバイスで使えない仕組み
利用可能アプリは利用者向けのセルフサービス機能
Intuneの「Available for enrolled devices」は、利用者がCompany Portalへサインインし、必要なアプリを自分で選んでインストールする仕組みです。
通常は、端末を登録したプライマリユーザーがCompany Portalへサインインした場合に、そのユーザーへ割り当てられたアプリが表示されます。Microsoftのドキュメントでは、この割り当て方式はAndroid Enterprise fully managedと、組織所有の仕事用プロファイル端末でサポートされています。(Microsoft Learn)
一方、Android Enterprise専用デバイスには、端末を登録したプライマリユーザーが存在しません。したがって、次の処理を成立させるためのユーザー情報がありません。
- 現在の利用者をIntuneのアプリ割り当て対象として判定する
- 利用者が所属するMicrosoft Entraグループを確認する
- その利用者向けの利用可能アプリ一覧を表示する
- 利用者の操作でアプリをインストールする
このため、専用デバイスでインストールできるのは、管理者が「Required」、つまり必須として割り当てたアプリだけです。(Microsoft Learn)
Microsoft Entra shared device modeでも必須配布が基本
Microsoft Entra shared device mode用の登録トークンを使用すると、Microsoft AuthenticatorとCompany Portalが自動的にインストールされます。
しかし、Company Portalが入っているからといって、専用デバイスがセルフサービス型のアプリカタログになるわけではありません。登録方式は引き続きAndroid Enterprise専用デバイスであり、業務アプリは「必須」で事前配布する必要があります。(Microsoft Learn)
shared device modeが追加するのは、主に次の機能です。
- 利用者によるアプリへのサインイン
- 対応アプリ間でのシングルサインオン
- 業務終了時の一括サインアウト
- 次の利用者へ端末を安全に引き渡すためのセッション切り替え
「利用者ごとに使うアプリを変える機能」ではなく、全利用者に同じアプリを配布したうえで、アプリ内のデータや権限を利用者ごとに切り替える機能と考えると分かりやすいでしょう。
必要なアプリを後付けする正しい方法
専用デバイスでも、管理者が後から業務アプリを追加することは可能です。ただし、アプリの「インストール」と「キオスク画面への表示」は別々に設定します。
アプリ追加時に必要な2段階の設定
マルチアプリキオスクには、次の2つの許可が必要です。
- Intuneから端末へアプリをインストールする
- Managed Home Screenから起動できるアプリとして許可する
アプリを「必須」で配布しただけでは、端末内にインストールされてもManaged Home Screenにアイコンが表示されないことがあります。反対に、キオスク設定へアプリを追加しても、アプリ自体が端末に配布されていなければ起動できません。
Microsoftのドキュメントでも、Managed Home Screenから起動するアプリは、Intuneへ追加し、専用デバイスの端末グループへ割り当てたうえで、キオスク構成へ追加する必要があるとされています。(Microsoft Learn)
後から業務アプリを追加する手順
Managed Google Playへアプリを追加する
Intune管理センターで、対象アプリをManaged Google Playアプリとして追加し、Intuneと同期します。
プライベートアプリ、公開ストアアプリ、Webアプリのいずれを利用する場合も、最初にIntuneのアプリ一覧へ登録します。
専用デバイスグループへ「必須」で割り当てる
アプリの割り当てで、対象となる専用デバイスグループを選択し、割り当ての種類を「必須」にします。
利用者グループではなく、店舗、拠点、端末用途などで分けたデバイスグループへ割り当てると管理しやすくなります。登録プロファイル名を条件に動的デバイスグループを作る方法もあります。(Microsoft Learn)
キオスク構成へアプリを追加する
マルチアプリキオスクでは、次のいずれかを更新します。
- Android Enterpriseのデバイス制限プロファイル
- Managed Home Screenのアプリ構成ポリシー
アプリのパッケージを許可対象へ追加し、必要に応じてホーム画面上の位置やフォルダーも設定します。
シングルアプリキオスクの場合は、起動対象のアプリを変更する必要があります。シングルアプリ構成では利用者が別のアプリへ切り替えられないため、変更前に業務への影響を確認してください。
少数端末で同期と起動を確認する
本番グループへ直接配布せず、検証用の専用デバイスグループで次の項目を確認します。
- アプリがインストール済みになっているか
- Managed Home Screenに表示されるか
- アプリから設定画面や不要な別アプリを起動できないか
- オフラインや低速回線でも業務を開始できるか
- アプリ更新後もキオスク状態が維持されるか
キオスクモードは、許可したアプリが別のアプリやAndroidの設定画面を起動することまでは完全に防げません。不要なアプリを端末へ入れず、許可したアプリの画面遷移も検証する必要があります。(Microsoft Learn)
利用者別証明書を後付けできない理由
専用デバイスには証明書へ埋め込む利用者情報がない
利用者別のSCEP証明書では、一般的に次のようなMicrosoft Entraのユーザー属性を証明書のSubjectやSANへ設定します。
- ユーザー名
- メールアドレス
- ユーザープリンシパル名
- オンプレミスの識別名
- オンプレミスのSAMアカウント名
しかし、Android Enterprise専用デバイスは特定ユーザーに関連付けられていません。
そのため、証明書プロファイルに{{UserPrincipalName}}などを設定しても、Intuneは証明書要求へ埋め込む利用者情報を取得できません。Microsoftも、Android Enterprise専用デバイスのようにユーザー関連付けがない端末では、ユーザー属性を利用できないと明記しています。(Microsoft Learn)
shared device modeのサインインはユーザー関連付けとは異なる
Microsoft Entra shared device modeでは、利用者が端末上のアプリへサインインします。
ただし、このサインインは業務中のアプリセッションを識別するものです。端末そのものを、その利用者のIntune登録デバイスへ変更するものではありません。
shared device modeを使用した専用デバイスも、Intuneにはユーザーアカウントなしで登録され、特定ユーザーには関連付けられません。したがって、利用者がAuthenticatorや業務アプリへサインインしても、その利用者を基にSCEP証明書を自動発行できるようになるわけではありません。(Microsoft Learn)
専用デバイスのSCEP証明書はアプリ認証に使えない
Android Enterprise専用デバイスでも、SCEP証明書そのものは利用できます。ただし、主な用途はWi-Fi、VPN、端末やネットワークの認証です。
Microsoftの制限事項では、Android Enterprise専用デバイスへ配布したSCEP証明書を、アプリ認証に使用する構成はサポートされていません。(Microsoft Learn)
したがって、次のような設計は避ける必要があります。
- 現在端末を使っている従業員のUPNを入れた証明書を動的に発行する
- 共有キオスク上の業務アプリへ、利用者ごとのクライアント証明書を渡す
- デバイス証明書を従業員本人の証明として扱う
- 1枚の共有証明書で全利用者を識別する
デバイス証明書が証明できるのは、原則として「管理対象の端末であること」です。「誰が操作しているか」を証明するものではありません。
デバイス証明書と利用者証明書を分けて設計する
証明書で発生しやすい設計ミスは、端末認証と利用者認証を1つにまとめようとすることです。
| 認証対象 | 適した方式 | 主な用途 |
|---|---|---|
| 端末 | デバイス証明書 | Wi-Fi、VPN、端末からバックエンドへの接続 |
| 利用者 | Microsoft Entraサインイン | 利用者の識別、アクセス権、監査ログ |
| アプリの操作権限 | OAuthアクセストークンなど | 利用者ごとの閲覧・登録・承認権限 |
| 固定端末の識別 | IntuneデバイスIDや証明書 | 店舗、窓口、設備単位の識別 |
専用デバイスでは、SCEP証明書の種類を「Device」とし、端末名、IntuneデバイスID、Microsoft EntraデバイスIDなどのデバイス属性をSubjectやSANへ使用します。Microsoftも、キオスクなどのユーザーレス端末ではデバイス証明書を使用するよう案内しています。(Microsoft Learn)
たとえば、共有端末から社内APIへ接続する場合は、次のように役割を分離します。
- デバイス証明書で「管理対象端末からの接続」であることを確認する
- Microsoft Entraサインインで「現在の利用者」を確認する
- アクセストークンのクレームで利用者の権限を判断する
- 監査ログへ利用者IDと端末IDの両方を記録する
この構成なら、端末を共有しながら、誰がどの端末で何を操作したかを追跡できます。
要件別に選ぶIntuneの代替設計
Intuneの登録方式は、管理の強さだけで決めるものではありません。端末と利用者のどちらを主な識別対象にするかで選びます。
| 業務要件 | 推奨構成 | アプリ配布 | 利用者の識別 |
|---|---|---|---|
| 在庫スキャンなど単一業務 | 標準の専用デバイス＋シングルアプリキオスク | 必須で事前配布 | 原則不要 |
| 複数の共通業務アプリを全員で使う | 標準の専用デバイス＋マルチアプリキオスク | 必須で事前配布 | 各アプリへ個別サインイン |
| 複数人で共有し、サインイン・サインアウトを統一する | 専用デバイス＋Microsoft Entra shared device mode | 必須で事前配布 | Microsoft Entraアカウント |
| 1人に1台を割り当て、利用可能アプリも使わせる | Android Enterprise fully managed | 必須と利用可能を併用 | 端末登録時のユーザー |
| 個人利用領域も許可する組織所有端末 | Corporate-owned work profile | 必須と利用可能を併用 | 端末登録時のユーザー |
| 利用者別証明書によるアプリ認証が必須 | Fully managedなどのユーザー関連付け方式 | ユーザーまたは端末へ配布 | ユーザー証明書 |
| 共有端末で利用者別クライアント証明書が必須 | 認証方式の再設計、または1人1台化 | 要件に応じて設計 | Entra認証などへ変更を検討 |
特定業務に固定するなら標準の専用デバイス
次の条件なら、標準のAndroid Enterprise専用デバイスが適しています。
- 利用者によって使用アプリを変えない
- 全端末に同じアプリを入れる
- 操作者よりも店舗や設備を識別できればよい
- Wi-FiやVPNにはデバイス証明書を使う
- 利用者が端末設定やGoogle Playを操作する必要がない
アプリはすべて管理者が必須配布し、変更が必要な場合も管理者がIntuneから追加・削除します。
共有端末で個人識別が必要ならMicrosoft Entra shared device mode
病院、店舗、倉庫などで、1台の端末を交代で使いながら、利用者ごとのデータや権限を切り替えたい場合に適しています。
専用デバイス用の登録プロファイルを作成するときに、トークンの種類として「Corporate-owned dedicated device with Microsoft Entra ID shared mode」を選択します。これにより、Authenticatorがshared device mode用に構成され、対応アプリ間のサインインとサインアウトを統合できます。(Microsoft Learn)
ただし、完全な共有端末サインイン・サインアウトを実現するには、アプリ側がMicrosoft Authentication Libraryなどのshared device modeに対応している必要があります。導入前に、Microsoft製アプリだけでなく、利用する業務アプリや社内アプリの対応状況も確認してください。(Microsoft Learn)
アプリ選択や利用者証明書が必要ならfully managed
端末を特定の従業員へ割り当てる場合は、Android Enterprise fully managedが適しています。
fully managedでは、登録時に利用者が職場アカウントでサインインし、端末がその利用者に関連付けられます。そのため、次のようなユーザー向けワークフローを構成できます。
- Company Portalで利用可能アプリを選ぶ
- ユーザーグループごとに異なるアプリを表示する
- 利用者属性を使った証明書を配布する
- 利用者単位の構成やアクセス制御を適用する
- Outlookなどの個人データを扱う業務アプリを使用する
Android Enterpriseのfully managedは、組織所有かつ1人の利用者に関連付けられる業務専用端末です。(Microsoft Learn)
なお、fully managedにキオスク制限を設定すること自体は可能です。ただし、Company Portalを開けないほど画面を固定すると、利用可能アプリを利用者が選ぶ目的と矛盾します。セルフサービスが必要な場合は、完全なキオスクではなく、設定画面やインストール元を制御した一般業務端末として設計した方が自然です。
共有アカウントや共有シークレットで代用してはいけない理由
利用者別証明書を使えないからといって、全員で同じアカウント、パスワード、APIキーを共有する構成は推奨できません。
共有シークレットには、次の問題があります。
- 操作した利用者を監査ログから特定できない
- 退職者や異動者だけを個別に無効化できない
- 1台から漏えいすると全端末の認証情報を変更する必要がある
- パスワード変更時に多数の端末が一斉に利用不能になる
- アプリに認証情報を保存すると、端末紛失時の影響が大きくなる
- 利用者ごとの権限分離や条件付きアクセスを適用しにくい
共有端末では、「共有するのはハードウェアとアプリだけ」と考えます。利用者の認証情報やアプリ内セッションまで共有してはいけません。
個人識別が必要な業務では、Microsoft Entra shared device modeなどを利用し、利用者本人のアカウントでサインインさせます。端末固有の接続認証にはデバイス証明書を使用し、利用者認証とは分離します。
登録後に設計変更するときの注意点
アプリや構成ポリシーは登録後でも変更できますが、端末のユーザー関連付けを決める登録方式は、単なるポリシー変更ではありません。
特に、次の変更は初期化と再登録を前提に計画する必要があります。
- 専用デバイスからfully managedへの変更
- ユーザー非関連付けからユーザー関連付けへの変更
- 既存の標準専用デバイスを、登録時からMicrosoft Entra shared device mode構成に統一する変更
Android Enterpriseの専用デバイスやfully managed端末は、登録前の出荷時リセットが基本要件です。また、shared device modeの構成変更では、端末のワイプ、または関連するMicrosoftアプリとshared device mode対応アプリの再インストールが必要になる場合があります。既存端末が登録トークンの変更だけで自動変換されるとは考えず、再登録を含む移行手順を検証してください。(Microsoft Learn)
実際の移行では、次の順序が安全です。
- 新しい登録プロファイルと登録トークンを作成する
- 専用の検証端末で初期化と再登録を行う
- アプリ、証明書、Wi-Fi、VPNを事前配布する
- サインインとサインアウト後のデータ消去を確認する
- 端末交換や業務停止が可能な時間帯を決める
- 拠点または端末グループ単位で段階的に移行する
よくある失敗と確認ポイント
| 症状 | 主な原因 | 確認する項目 |
|---|---|---|
| 利用可能にしたアプリが表示されない | 専用デバイスでは利用可能割り当てを使えない | 割り当てを必須へ変更する |
| アプリはインストール済みだが画面にない | キオスクの許可リストに入っていない | Managed Home Screen構成を確認する |
| SCEP証明書が発行されない | UPNなどのユーザー変数を専用デバイスで使用している | 証明書の種類とSubject、SANを確認する |
| アプリが証明書を使えない | 専用デバイスでのSCEPアプリ認証を前提にしている | 認証方式または登録方式を見直す |
| shared device modeで一括サインアウトできない | アプリがMSALやshared device modeに未対応 | アプリベンダーの対応状況を確認する |
| 利用者を監査ログで特定できない | 共有アカウントやデバイス証明書だけで認証している | 利用者本人のEntraサインインを追加する |
| 後からfully managedへ変えられない | 登録方式を構成ポリシーとして扱っている | 初期化・再登録の移行計画を作る |
導入前に決めておくべき設計項目
Intuneへ端末を登録する前に、最低限、次の項目を整理してください。
- 端末は1人専用か、複数人で共有するか
- 操作者本人を識別する必要があるか
- 全利用者が同じアプリを使うか
- 利用者がアプリを選んで追加する必要があるか
- 証明書は端末を証明するのか、利用者を証明するのか
- 業務アプリはMicrosoft Entra shared device modeに対応しているか
- サインアウト時にアプリデータやキャッシュを消去できるか
- 登録方式を変更する場合に端末を初期化できるか
特に重要なのは、「将来、個人識別が必要になるか」という点です。
現時点では共通アカウントで足りるように見えても、承認処理、医療情報、在庫変更、金銭処理などを追加すると、誰が操作したかを記録する必要が生じます。その可能性がある場合は、最初からMicrosoft Entra shared device modeまたはユーザー関連付けのある登録方式を選ぶ方が、後の再登録やアプリ改修を減らせます。
Intuneキオスクは機能を減らした一般端末ではない
Intuneの専用デバイスとキオスクモードは、一般的なスマートフォンやタブレットから一部の機能を取り除いたものではありません。最初から、用途、アプリ、端末操作を管理者が決める業務端末モデルです。
そのため、必要なアプリは管理者が「必須」で配布し、マルチアプリキオスクではManaged Home Screenの許可対象にも追加します。Wi-FiやVPNにはデバイス証明書を使用し、利用者の識別が必要ならMicrosoft Entra shared device modeを組み合わせます。
利用者によるアプリ選択や、UPNを含む利用者別証明書が必須なら、専用デバイスへ後付けしようとせず、fully managedなどのユーザー関連付け方式へ切り替えるべきです。
端末を登録する前に「誰が使うか」「誰を識別するか」「アプリを誰が選ぶか」「証明書が何を証明するか」を決めることが、Intuneキオスク設計で最も重要な作業です。
コメント