初日のキーノートでは、LockScreen刷新を含む多数のiOS16の新機能、ほぼデスクトップOS化したiPadOS16に加え、M2チップ搭載のMacBook Proなどハード的な進化も発表されました。

例年WWDCのキーノートではエンタープライズ向け機能が紹介されることはなく目立ちませんが、今回も着実な進化を遂げていました。本稿ではエンタープライズiOS関係者が、特に見ておいたほうが良いWWDC2022のセッションを3つ紹介します。

What’s new in managing Apple devices

(エンタープライズ系のセッションではお馴染みの Graham と Nadia)

最近のWWDCでは必ずエンタープライズ系の新機能をザックリ全て紹介するセッションが用意されています。2022年も同様で、本セッションは全ての関係者がチェックしておくべきでしょう。

しれっと手短に紹介された幾つかの機能が3つ印象に残りました。

まず、Apple Configurator for iPhone の新機能。iOS16からは iPhone 用の Apple Configurator を使ってDEP(ADE)端末化することができるようになります。Macとの有線接続必須だった従来に比べ劇的な作業効率向上が期待できます。

(iPhoneでかざすだけでABMに登録される)

2つ目は、MDMでのeSIM対応。ソフトウェア化されたSIMだからこそ実現できることですね。CelullarモデルのiPhoneを電源ONしてWiFiに繋ぐだけで電話回線まで有効にする…ってことが実現できます。Kittingが更に楽になります。

(キャリアとMDMが連携してeSIMを配信できるようになる)

3つ目は、ドキュメント。MDMや構成プロファイルに関する仕様が GitHub に公開されました。

仕様書という書面ではなく、YAMLで記述されていてプログラムが解釈できるようになっているのが特徴。開発部門を内部に持つ企業はMDM運用の手間を削減できる独自ツール開発ができそうです。

Discover Sign in with Apple at Work & School

ABMでは Managed AppleID という、組織が管理するAppleIDを作れます。その Managed AppleID がiOS16で Sign In With Apple (SIWA) に対応します。業務用アプリ開発会社は特に視聴すべきセッションです。

Managed AppleID は AzureAD と Google Workspace のアカウント連携に対応済みですから、SIWA対応の業務用アプリは独自のアカウント機構を持たずとも2要素認証機能を持つことができることを意味します。

(AppleIDをアカウントとして使えるSIWA。iOS15までは Managed AppleID では使えなかった)

iOSのみを対象とする業務用アプリを新規開発する場合、独自のアカウント機構は持たずSIWAの対応だけにする選択肢が検討に値することになります。

Explore Apple Business Essentials

Apple 公式のMDMである Apple Business Essentials についての紹介です。昨年発表され月額課金型のSaaSであり、ABMにビルトインされています。その詳細の紹介セッション。

ADEPによるInHouseアプリ開発ができなくなる未来が確定している中、業務用iOSアプリに関わる関係者は MDM を中心とする Deployment の知識が今後求められます。Apple 公式の MDMを知っておくことも重要ですので、本セッションはしておきたいセッションです。

(MDMとABMは基本的にセットで必要になるので、ABMに統合されたMDMであることは最大の強み)

Apple Business Essentials は2022年現在、米国の中小企業のみが契約できます。が、過去にVPP(Volume Purchase Program) や DEP(Device Enrollment Program。現在はADEと称する) がそうであったように、日本でも使えるようになるのは時間の問題でしょう。

以上、エンタープライズiOS関連のWWDC2022セッション3選をご紹介しました。他にも、セキュリティ関係で Discover Managed Device Attestation のセッション、MDM関連では [Adopt declarative device management](https://developer.apple.com/videos/play/wwdc2022/10046/) 等のセッションもありますので、興味ある方はあわせて視聴してみると良いでしょう。

(MACアドレスはiOSではWi-Fiアドレスと表記される。EC:CE:D7はAppleに割り当てられたベンダーID)

しかし、iOS14以降のiOS端末はMACアドレス制限のかかった無線ネットワークとの相性が非常に悪く、ハマりポイントがあるので注意が必要です。本稿では、iOS14以降のiOS端末をMACアドレス制限有りのネットワーク下で使用する場合の注意点と対策方法をご紹介します。

iOS14以降でハマるプライベートWiFiアドレス

iOS14以降から、プライベートWiFiアドレスなる機能が搭載されました。iOS端末のMACアドレスを隠蔽するためのもので、デフォルトではONになっています。

 → 
(接続中WiFi名の右端 (i) ボタンから詳細情報画面で確認できる)

iOS14以降のiOS端末では、接続される側(ネットワーク機器)から見た場合の端末MACアドレスが真のMACアドレスではなくなっているということですね。デフォルトでこの挙動になります。

MACアドレス制限は通常、端末側のMACアドレスが変わらない前提で「MACアドレスが XX:XX:XX:XX:XX:XX なら接続を許可します」と設定するものです。真のMACアドレスでないのなら、条件が満たされず接続できなくなってしまうことは容易に想像がつきます。

  
(真のMACアドレス(左)と、接続先のネットワーク機器に伝わるMACアドレス(右)の違い。全く異なることが分かる)

結果、プライベートWiFiアドレスの存在を知らずにiOS13以前からiOS14以降にアップデートすると、WiFiが繋がらなくなったというトラブル報告が大量発生してしまうことになります。

MACアドレスのランダム化を無効にするために

もしMACアドレス制限付きのネットワークを構成していて、iOS14以降を使用するのなら、トラブルを避けるためプライベートWiFiアドレス機能を無効にしなければなりません。無効化には以下が必要となります。

• 監視モード端末であること
• 構成プロファイルを流し込むこと

DEP(ADE)端末であれば後者の構成プロファイルのみを意識すれば良いでしょう。そうでない場合はiOS端末を Apple Configurator で明示的に監視モード化する必要があります。詳しくは以下をご覧下さい

• iOSを監視モードにする方法 〜保存版 : Apple Configurator2編〜
• iOSの監視モードとは何か

実は、プライベートWiFiアドレス機能の無効化に監視モードは必須ではありません。しかし、厳密な運用をする為には必要となります。この点は後述します。ひとまずやり方を先に確認しておきましょう。

MACアドレスのランダム化を無効にする方法

手順はいたって簡単で、構成プロファイルの中で無効化を明示するのみです。端末全体に対して設定するのではなくWiFi接続先情報ごとに指定するという点に注意して下さい。

Apple Configurator の構成プロファイルエディタでは、各WiFi接続情報の中にある「関連付けを回避するためのMACランダム化を無効にする」のチェックが該当します。これをONにして保存します。

構成プロファイルのXMLを直接編集している場合は、WiFi接続情報のXMLの中に以下のように DisableAssociationMACRandomization キーに true を指定しましょう。

作成した構成プロファイルを Apple Configurator か MDM を使って流し込むと設定が反映されます。構成プロファイルをMDM上で編集する場合は、各MDMサービスのマニュアルを参照して下さい。

構成プロファイルを流し込んだ後、端末の設定アプリからWiFi接続情報の詳細画面を開くと、本当に無効になっているかどうか確認することができます。

  
(スイッチのON/OFFだけでなく、WiFi一覧でも、接続詳細画面の最上部にも警告が表示される)

MACアドレスがランダム化されたものかどうかを確認する方法

実は、iOS側の設定を見なくても、例えばWiFiアクセスポイント機器の接続端末一覧などの画面で、MACアドレスがランダム化された端末かどうかを(ほぼ確からしく)見分ける方法があります。

MACアドレスは48ビット(6バイト)で構成されますが、ランダム化されたMACアドレスの場合、その最初の1バイト(図中の赤色部分)中の0ビット目(I/Gビット)と1ビット目(G/Lビット)の並びが下図のとおり 10 となります。

従ってMACアドレス表記の2文字目が 2,6,A,E のいずれか(16進数表記で0,1ビット目が10となる)であれば、接続されているiOS端末はプライベートWiFiアドレス機能が有効になっている可能性が高いということです。

(あるアクセスポイントの接続ログ一部。2文字目がA,Eなのでランダム化されたものと思われる)

本件I/GビットとG/Lビットとランダム化ついては、標準化団体IETFに Internet-Draft (草稿文書) として提出されている文書にも記載がありますので、興味のある方は確認されると良いでしょう。

(2022年7月時点のステータスは WG Document)

ちなみにこのランダム化、実はiOS8(iPhone5の時代)から採用されています。ユーザが意図せず位置情報をトラッキングされてしまうことを避けるため、WiFi接続確立前のプローブ要求(Probe Request)に限って長らく使われてきた仕掛けです。

iOS14のプライベートWiFiアドレス機能はその延長線上にあるもので、接続確立前だけでなく接続確立後のMACアドレスも隠すようになったものです。詳しくは以下の資料を参照して下さい。iOS端末の運用だけでなく、ネットワーク管理もされている情シス担当者の方は一読されると良いでしょう。

• MAC認証や位置情報が使えなくなる!?Private MACアドレス説明と影響について(CISCO日本法人)
• Wi-Fiのプライバシー(Apple公式ドキュメント)

昨今のAppleは個人情報を守る姿勢を強めています。プライベートWiFiアドレス機能はその姿勢強化を裏付ける機能と言えるでしょう。

MACアドレスのランダム化の無効に監視モードが必要なわけ

ところで、前述のMACアドレスのランダム化を無効にするためにの項で、監視モードは必須ではないと書きました。実際その通りで、構成プロファイルさえ流し込めば、監視モードかどうかに関わらずプライベートWiFiアドレス機能は無効になります。

が、監視モードでない場合、流し込んだ直後は無効化されるもののユーザが手動で有効化できてしまう点に注意が必要です。

 → 
(監視モードでない場合、簡単にランダム化の無効化を解除されてしまう)

これでは余り意味がありませんね。監視モードの端末であれば、上記のような手動有効化ができず、画面上でも下図の赤枠のように注意書きが表示されるようになります。

(プライベートWi-Fiアドレスのスイッチをタップしても反応しない。つまりユーザが勝手に無効化を解除することはできない)

業務端末としてiOS端末を配布する場合、この画面の存在すら知らない従業員が大半でしょうから、監視モードでなくても別に構わない…という割り切りもアリでしょう。従って、各社ごとプロジェクトごとに諸事情を勘案し総合的に判断することとなります。

以上、MACアドレス制限のかかったネットワークでiOS端末を使用する場合に注意すべきことについて解説しました。

セキュリティの観点からフリーWiFiに繋げさせたくない場合もあれば、施設設置型のキオスク端末用途で特定のWiFiに繋がってないとアプリが機能しないといった場合もあるでしょう。(施設ローカルネットワークにコンテンツサーバがある等)

(WiFi接続制限は業務用端末ならではの機能の一つ)

そこで本稿では、指定のWiFi以外に接続を許可しない方法について解説します。

動作紹介

接続先WiFiを制限された端末では、設定アプリでの表示が以下のようになります。

 → 
(通常は左側。右側が制限された端末)

通常ならネットワークの欄に接続先候補が現れますが、制限された端末では待てども待てども表示されません。オープンなSSIDが表示されないのはもちろん、制限を有効にする前に手動で接続したことのあるSSIDも表示されません。

管理部門が許したWiFiにのみ接続できる状態になるわけです。MDM管理下から逃れる以外に、この制約から逃れるすべはありません。MDMに自動チェックインするDEP(ADE)端末なら、端末側からMDM管理下を抜け出すことは不可能ですので、セキュリティ的にかなり安心ですね。

前提条件

条件は2つです。

• 端末が監視モードであること
• WiFiのSSID接続情報を構成プロファイルでインストールすること

監視モード端末に対して、WiFiの接続情報と一緒に制限設定も流し込みます。接続対象とするWiFiは1つに絞る必要はありません。複数個あってもokです。

監視モードや構成プロファイルについては、書くと長くなりますので以下投稿をご覧下さい。

• 監視モードとは何か
• 監視モードにする方法
• 構成プロファイルとは

設定方法

構成プロファイルを作成して監視モードの端末に流し込む必要があります。本稿では Apple Configurator を使って作成する方法で解説しますが、他のツールやMDMに備わっている作成支援機能を使っても良いでしょう。

(1) まず端末を監視モードにします。詳しくは監視モードにする方法やDEPとは何かの投稿をご覧下さい。既に対象端末が監視モードなら不要です。

(2) WiFi の接続情報を含む構成プロファイルを作成します。Apple Configurator の WiFi のカテゴリで [+] をクリックして必要情報を入力します。自動接続させたい場合は「自動接続」のチェックをONにします。

(接続情報を複数個指定しても良い。個数制限はない)

(3) (2)とは別に新たな構成プロファイルを作成し、制限のカテゴリで「Wi-FiペイロードによってインストールされたWi-Fiネットワークのみに接続」のチェックをONにします

(デフォルトはOFF)

(4) (2)で作成した構成プロファイル(WiFi接続情報)と、(3)で作成した構成プロファイル(接続先制限) の両プロファイルを Apple Configurator か MDM を使って端末に流し込みます。

(5) 設定アプリのWiFiから、流し込んだWiFi以外が一覧から見えなくなっていることを確認します。

(制限の構成プロファイルが流し込まれ反映されると、直前まで接続されていたWiFiは一度切断される)

以上です。必要な構成プロファイルを用意して流し込むだけなので簡単ですね。(5)でもし他のSSIDが見えてしまう場合、端末が恐らく監視モードになっていません。iOS端末が監視モードかどうかを確認する方法を参考にしてチェックして下さい。

構成プロファイルを2つに分ける理由

ところで、上記の設定方法の (2) (3) で、WiFi接続用と接続制限用の構成プロファイルを別々に作りました。しかし、構成プロファイルには幾らでも設定を内包できますので、2つに分けず1つの構成ファイルにまとめることも可能です。

(1つの構成プロファイルに両者を一緒に含めた例)

ですが、構成プロファイルはなるべく細かい粒度で分けるのが推奨されます。柔軟なオペレーションができるからです。例えば上記(2)(3)のように、WiFi接続情報と、WiFi接続制限を別々の構成プロファイルに分けておくことで、以下のような運用が行えます。

• WiFi接続情報(2)のみ流し込んで端末の接続確認とサーバとの疎通確認
• もし繋がらなければ他の接続可能なWiFiに切り替えてトラブルシュート
• 問題解決してからWiFi接続制限(3)を流し込む

1つにまとめてしまうと、こうはいきません。

筆者は様々な構成プロファイルを作成・変更・削除を運用御支援で体験してきましたが、構成プロファイルを肥大化させることが運用時のメリットになったことは一度もありません。なるべく粒度は細かくして、構成プロファイルは小さくするようにしましょう。

まとめ

本稿では、特定のWiFiにしか接続できないようにする方法について解説しました。

• 監視モードにする
• WiFi接続情報とWiFi制限の構成プロファイルを流し込む

の2つが条件であることと、構成プロファイルの具体的な作成方法をご紹介しました。通信の秘匿性が必要なシーンで導入を検討されると良いでしょう。

しかしアプリ開発に携わっていて開発中アプリをテスト用にAdHoc配布する場合、対象端末のUDIDを全て収集しなければならなくなります。provisioning profile にUDIDを含めておく必要があるためです。

(アプリの起動を許可したい関係者の端末のUDIDを登録していく必要がある)

テスト用のアプリ配布にはTestFlightを使うことが推奨されますが、過去の経緯や様々な理由でTestFlightを使えない場合もあります。

そんな時にはやはり UDID の収集が必要ですが、これが意外に面倒くさく煩わしいのです。自分で全部出来れば良いですが、MacやWindowsを扱うのに慣れていない方やITリテラシーがそれほど高くない人にまで「お手元の端末のUDIDを教えて下さい」とお願いしなければならない場合もあるからです。

そこで本稿では、iOS端末のUDIDを調べる方法大全ということで全10種類ご紹介します。

• (1) MDM (情シス向け)
• (2) Xcode (Mac / 開発者向け)
• (3) cfgutil (Mac / 開発者向け)
• (4) Apple Configurator (Mac)
• (5) Finder (Mac)
• (6) ミュージック (Mac)
• (7) システムレポート (Mac)
• (8) iTunes (Windows)
• (9) デバイスマネージャ (Windows)
• (10) UDID.tech (Web)

情シスや開発者にしか使えなさそうな方法は明記しています。それら以外は、エンドユーザや商流の間にいる開発をしないSIerの方でも可能な方法です。以下、順に見ていきましょう。

(1) MDM (情シス向け)

UDIDの収集効率をあげるには、関係者全員にUDIDの確認を依頼するのではなく、代わりに全部調べてあげるのが一番です。MDM導入済みの環境であれば、それが可能です。

MDMでは、チェックインしている端末の基本情報を根こそぎ収集しています。当然 UDID も収集していますから、ブラウザでMDM管理下にある全端末のUDIDを調べることができます。

(弊社がよく使用するBizMobile Go!での端末詳細画面。UDID以外にも各種の情報が収集される)

多くのMDMでは端末一覧のCSVエクスポート機能も備えていますので、ExcelやNumbersを使えばUDID一覧の作成もあっという間に終わります。

(一覧のCSVファイルを開いている様子。MDMで管理している端末のUDID一度を取得するのは容易い)

ということで、UDID収集の初手は、情シス側でMDMを使って対象のUDIDを調べあげることです。その後、後続の方法でMDM配下にない端末についてのみ端末所有者毎に調べて貰う、という進め方がオススメです。この意味で、開発会社やSIerであってもMDMを社内導入することが推奨されます。MDMについてはMDMとは何か 〜今さら聞けないMDMの基礎〜の投稿をご覧下さい。

(2) Xcode (Mac / 開発者向け)

開発者であれば Xcode が使えます。Xcodeのメニューから [Devices and Simulators] をクリックして表示される画面で、調べたい端末を選んで詳細表示します。

赤枠の部分 Identifier がUDIDです。ちなみにシリアル番号も同じ画面内から調べることができます。[Devices and Simulators] の画面を表示するには、ショートカット [command] + [shift] + 2 が便利です。

(3) cfgutil (Mac / 開発者向け)

ターミナルの操作になれた開発者なら cfgutil コマンドを使って調べることもできます。USBハブを使って複数台を一度に調べることも可能です。

MacにiOS端末をUSB接続し、以下のようなコマンドを実行します。

$ cfgutil --format json list | jq .

(cfgutil の listコマンドを実行。 –format オプションでJSON出力を指定すると加工し易い。jq は別途インストール必要)

なお cfguitl とは、AppleConfigurator2 に付随するユーティリティコマンドです。詳しくはApple Configurator2 付属のコマンドラインツール cfgutil の使い方の投稿をご覧下さい。

工夫すれば、社内共用のMacにUSB接続するだけで、担当者にUDIDを記したメールが自動送信されるといった仕組みを作ることも可能です。(exec コマンドを使います)

(4) Apple Configurator (Mac)

情シスでも開発者でもないMacユーザなら Apple Configurator が使えるでしょう。詳細は Apple Configurator とは をご覧下さい。

まずMacにiOS端末をUSB接続して、Apple Configuratorを起動します。起動直後に以下のようにMacに接続中の端末一覧が表示されます。

UDIDを調べたい端末をダブルクリックすると、端末の詳細情報画面が表示されます。

この画面の赤色枠部分がUDIDです。ダブルクリックするとテキストとして選択できますので、[command] + C や右クリックメニューからコピーすると良いでしょう。

(5) Finder (Mac)

もし AppleConfigurator2 をインストールしていないMac端末なら、Finder を使うのがお勧めです。

iOS端末をUSBケーブルでMacに接続し、FInder のサイドバーから端末をクリックします。すると以下のような端末情報画面が表示されます。

(macOS Catalina 以降ではiOS端末の詳細確認や各種操作がFinderに統合された)

この画面で、上図の赤枠部分をクリックすると、シリアル番号とUDIDの表示に切り替わります。

さらに右クリックすると、UDIDのみをテキストとしてコピーすることもできます。

情シスや開発者以外で Catalina 以降のMacを使っている方には、一番簡単なUDID確認方法です。

(6) ミュージック (Mac)

Finder と同様にミュージックアプリでもUDIDを調べることもできます。

ミュージックアプリを起動して、サイドバーの「デバイス」の欄から調べたい端末を選択します。以下のような表示になります。(端末に楽曲をダウンロード・インストールしていると楽曲一覧が表示される)

(AppleIDの設定が完了していない端末では詳細情報は表示されない)

Finderと同様に、赤枠部分をクリックするとシリアル番号やUDIDが表示されます。

(Finderと同様に右クリックからコピーができる)

ただご紹介はしたものの Finder の方が一般的ですので、ミュージックアプリを使ってわざわざ調べることはない気はします。

(7) システムレポート (Mac)

Macの詳細情報を確認する「システムレポート」からもUDIDを確認することができます。

Macに端末をUSB接続した状態で、Apple メニューから [このMacについて]→[システムレポート] ボタンをクリックします。

システムレポートが表示されますので、サイドバーでハードウェアのUSBをクリックし、一覧からiOS端末を選択します。

右下ペインにある「シリアル番号」の欄にUDIDが表示されます。(名称が紛らわしいので要注意)

なおシステムレポートに表示されるUDIDは、端末のUDIDが新しいフォーマット(00000000-0123456789ABCDEF の8桁-16桁形式)の場合、真ん中のハイフンが省略されてしまう点に留意して下さい。AdHoc配布用に developer.apple.com にUDID登録する担当者は、登録時に8,9桁目の間にハイフンを入れるようにして下さい。

(8) iTunes (Windows)

Windows環境でUDIDを調べる場合、iTunes を使います。

Windows + iOSユーザなのにiTunesをインストールしていない方はほとんどいないので、比較的やり易い方法です。未インストールの場合は Microsoft Store のURLからインストールして下さい。

WindowsPCにiOS端末をUSB接続し、iTuneを起動。その後、デバイスを表すアイコンをクリックすると詳細が表示されます。

詳細表示の赤枠で囲った部分をクリックする度に、ECID→シリアル番号→UDIDと表示が変わります。2回クリックしてUDIDを表示し、テキストとしてコピーしましょう。

時々 iTunes にiOS端末が認識されないことがありますが、その場合はケーブルの抜き差しや iTunes や Windowsの再起動をしてみて下さい。

(9) デバイスマネージャ (Windows)

「デバイスマネージャ」を使って確認することもできます。非常に特殊な方法ですが、一応紹介します。

Windows メニューを右クリックして [デバイスマネージャ] を開きます。以下のような画面が表示されますので、[ユニバーサルシリアル バス デバイス] を開きます。

[ユニバーサルシリアル バス デバイス] 内に [Apple Mobile Device USB Composite Device] がある筈ですので、この項目をダブルクリックするか、または右クリックしてプロパティをクリックすると以下のようなダイアログが表示されます。

[詳細]タブを選び、[プロパティ] 欄のリストボックスを [デバイスインスタンス パス] に切り替えると、値の欄に ¥ マークで区切られた文字列が表示されます。最後の ¥ マークより右側の文字列がUDIDとなります。

ただ、iOS端末のUDIDが新しいフォーマット(00000000-0123456789ABCDEF の8桁-16桁形式) の場合は、真ん中のハイフンが省略された表示になっている点に注意して下さい。developer.apple.com に登録する担当者は、登録時に8,9桁目の間にハイフンを入れるようにして下さい。

(10) UDID.tech (Web)

MDMもMacもWindowsも不要で、ただWebサイトにアクセスするだけでUDIDを調べることのできるサービスがあります。UDID.tech といいます。

このサイトにiOSのSafariでアクセスすると、特別なプロファイルをダウンロードすることができます。

 → 

ダウンロードしたプロファイルを設定アプリからインストールすると、UDIDをWebサイト上に表示してくれます。

 → 
(Web上にUDIDだけでなくシリアル番号の他、cellular端末ならIMEIも表示される)

本サービスは米国の Pixel Rainbow Inc. が「UDIDをもっと手軽に調べられないか」という課題認識から開発したサービスです。「UDIDを取得するAPIは今は存在しないのでは？」「そもそもWeb側でどうやって？」と思う方もいるかも知れませんが、Aboutページに、

UDID.tech uses Apple Mobile Device Management concepts to provide you information about your device. The profile you install tells your iPhone, iPad, or iPod to send encrypted data (UDID, IMEI, Serial No, etc.) to your browser.

とある通り、MDM のコンセプトを使って実現していて、何かハックをしているとかiOSの脆弱性を突いているといった類のものではありません。

厳密には、Profile Service という特別なペイロードを含む構成プロファイルをインストールした際のiOSの振る舞いを利用しています。Appleもその仕様を公開していますので、興味のある方は公式ドキュメント Over-the-Air Profile Delivery and Configuration を読んだり、同サイトからダウンロードできる構成プロファイルを解析してみると良いでしょう。(UDID.tech と同じサービスは公開された仕様を使って誰でも作れます。弊社では同類サイトの存在は認識していませんが)

このUDID.tech、非常に便利なのですが利用は自己責任となる点、ご留意下さい。弊社では率先して利用を勧めることはありませんが、どうやってもUDIDを取得できない人がいる場合の最終兵器…という程度に捉えています。

まとめ : テスト配布はできるだけTestFlightを使う

以上、本稿ではUDIDを取得する全10種類の方法を紹介しました。開発中のアプリをAdHoc 配布する時にご活用下さい。

ただ、2022年現在ではテスト用アプリ配布はTestFlightを使い、AdHoc配布は極力避けるのが無難です。UDIDの管理が煩雑になって「この端末では動く・動かない」「これ以上の台数を登録できない」といったトラブル対応に時間を取られるからです。

非公開な業務用アプリもカスタムAppとしてAppStore申請が必要になっている今、業務用アプリの関係者がTestFlightを避け続ける理由はありません。

TestFlightは、内部テストや外部テストなど専門用語も多くとっつきにくい印象がありますが、Apple がリリースした2014年当時に比べると格段に分かり易く・使い易くなっています。過去の慣習でまだAdHoc配布によるテスト配布を続けている方は、UDID収集に苦労することのないTestFlightへの移行を今すぐ検討しましょう。

通常、アプリのインストールにはAppleIDが必須ですが、業務用として設定された端末の場合は AppleID が無くてもアプリのインストールが可能だから…というのが大きな理由です。また、iCloud バックアップや「探す」機能など、AppleIDに紐づく機能の多くは代替する仕組みがあったり、むしろそんな機能は使わせたくない…となることも多いからです。

ただ、不要だからといって AppleID 未設定のまま端末を配布してしまうべきではありません。

(業務用端末に個人のAppleIDを入れられてしまうと…?)

従業員が個人AppleIDを入れることで情報が同期され、業務用端末に余計なアプリがインストールされてしまったり、逆に業務用の情報が個人端末に転送されて情報漏えいに繋がりかねません。端末を顧客や取引先に一時貸与するような場面では、返却後に端末初期化が難しくなったりします。

こういったことを避ける唯一の方法は、AppleiD を設定できないようにすることです。本稿ではその方法をご紹介します。

前提条件

業務用の制限機能の多くと同様に、端末は監視モード(Supervised Mode)でなければなりません。監視モードについてはiOSの監視モードとは何かをご覧下さい。

(iOSには2つのモードがある)

監視モードにするには、Apple Configurator2 から「準備」をするか、DEP(ADE)端末を購入してMDMに自動チェックインさせるか、2つの方法があります。それぞれの具体的方法は以下投稿を参考にして下さい。

• iOSを監視モードにする方法 〜保存版 : Apple Configurator2編〜
• DEP(Device Enrollment Program)とは何か

監視モードにできない端末の場合、AppleIDの無効化はできません。なお MDM へのチェックインは必須ではありません。

設定方法

(1) 監視モード化された端末を用意します。

(2) 次に構成プロファイルを作成します。Apple Configurator2 の構成プロファイルをエディタを使っても良いですし、MDMが備える作成画面を使ってもいいでしょう。「制限」のカテゴリにあるアカウント設定の変更を許可の項目をOFFにして保存します。

もし構成プロファイルを手動で作成する場合は、以下のように PayloadContent 内に allowAccountModification を false とする設定値をXML(plist)内に含めて下さい。

<key>PayloadContent</key>
<array>
    <dict>
...(略)...
        <key>allowAccountModification</key>
        <false/>
...(略)...
    </dict>
</array>

(3) 作成した構成プロファイルを端末に流し込みます。Apple Configruator2 を使う場合は構成プロファイルの作成とインストールの基礎 〜Apple Configurator2を使う方法〜をご覧下さい。MDMの場合は使用するMDMのマニュアルを参照して下さい。

(4) 流し込み完了後、設定が適用され以下のようにAppleIDが入力できないようになります。

 → 
(違いがほとんどなく分かりにくいが、適用後(右側)はAppleIDを入力する行がグレーアウトしタップできなくなる)

手順は以上となります。もしうまくいかない場合は、端末が監視モードかどうか確認しましょう。監視モードかどうか確認するにはiOS端末が監視モードかどうかを確認する方法の投稿を参考にして下さい。

本稿では、AppleIDの入力を無効にする方法について紹介しました。業務用として従業員に配布する端末や、施設に設置して使用するキオスク端末用途では特に有用です。よからぬトラブルを避けるため、AppleID が不要ならあらかじめ無効にしておきましょう。

(あるアプリの例。AppStoreへのアプリ申請では最初にBudnelIDを指定することになる)

業務用iOS関連の作業では、ときおりiOS端末にインストールされているアプリの BundleId を知りたくなることがあります。構成プロファイルを作成したり、MDMでアプリケーション関連の操作をしたり、Apple Configurator2 を触っているような時です。

自分が開発を担当しているアプリならそのBundleIDを記憶しているでしょうが、そうでない場合はどうやってBundleIDを調べるのでしょうか。本稿ではその方法を幾つか紹介します。

Xcode (development, InHouse, AdHoc)

手元にMacがあり開発環境のXcodeがインストールされているなら、iOS端末をMacにUSB接続した上で Xcode の Devices and Simulators の画面を見るとすぐに分かります。

(Xcode を起動した状態で、command + shift + 2 のショートカットが便利)

サイドバーで見たいiOS端末を選択すると、INSATLLED APPS の蘭にインストールされているアプリの一覧が表示されます。Identifier の列がアプリの BundleID です。

AppStoreからインストールされたアプリ(公開App/カスタムApp/非表示App/TestFlight)は基本的に表示されません。

MDM (InHouse, AppStore)

対象となるiOS端末がMDMの管理下にあるならMDMの管理画面を見るのが一番手っ取り早いでしょう。

どんなMDMにも端末の詳細情報画面があり、その中でインストールされているアプリの一覧が表示されている筈です。

(MDMは管理化の端末にインストールされているアプリ一覧を把握している)

アプリの種類によらず全て確認できます。MDMによっては、MDMで配信したアプリのみを表示する設定ができる場合もあります。(BYOD端末の場合、個人がその端末で使用するアプリを見ることは適当でないため)

cfgutil (development, InHouse, AdHoc, AppStore)

Apple Configuratoe2 に付属している cfgutil を使って確認することもできます。cfgutil の詳細はApple Configurator2 付属のコマンドラインツール cfgutil の使い方の投稿をご覧下さい。

iOS端末をmacにUSB接続し、ターミナルを起動して、cfgutilの list コマンドで端末のECIDを特定します。

$ cfgutil list

(cfgutilの大半のコマンドで ECID は必須となる)

次にECIDを引数に指定して以下のように get installedApps コマンドを実行すると、インストールされたアプリの一覧が出力されます。数秒程度待った後に、ECIDで指定された端末にインストールされているアプリ一覧が表示されます。

$ cfgutil -e [ECID] get installedApps

(出力テキストのアプリ名がエスケープされないため、加工しやすいテキストとは言えない)

cfgutil コマンドでは、development, InHouse, AdHoc だけでなく、AppStore からインストールしたアプリも表示されます。

iTunes Search API (AppStore)

AppStoreに公開されているアプリに限りますが、iTunes Search API を使ってアプリidから BundleID を調べることもできます。

まずアプリidを調べる必要がありますが、アプリのURLが分かるならそのURL末尾の数字がアプリidです。

アプリのURLを探すには、アプリ名とiOSでググると良いでしょう。あるいは、マーケティング担当者向けに用意されている App Store Marketing Tools を使うこともできます。

検索ボックスにアプリ名を入れると、アプリのURLやアイコン画像等の情報を確認することができます。

(アプリアイコンの高解像度画像ファイルをダウンロードすることもできる)

アプリidを特定したら、ターミナルから以下のように入力すると BundleID を特定できます。(iTunes Search API は JSON を返すため、jqコマンドで必要な箇所のみに絞り込んでいます)

% curl -s 'https://itunes.apple.com/lookup?id=[アプリid]' | jq -r '.results[0].bundleId'

(jqコマンドについては公式ページを参照のこと)

なお iTunes Search API を使う方法は InHouse アプリでは使えません。AppStoreに登録されないアプリだからです。またカスタムAppでは、アプリidは付与されるものの使えませんのでご注意下さい。

以上、アプリのBundleIDを調べる方法を紹介しました。BundleID(バンドルID)を調べる必要がある時に、試してみて下さい。

業務用アプリを配布する方法は、全て列挙すると実に7種類もあります。どの配布方法を選ぶべきかはアプリの特性や各社の状況によりますので、一通り配布方法を知っておくのは良いことです。

(用途やアプリに応じて様々な配布方法がある)

そこで本稿では全ての配布方法の概要を網羅的に紹介します。また、各方式について詳細を記している本サイトの別投稿へのリンクも紹介しますので、詳しく知りたい場合は各リンク先を参照して下さい。

本稿は、アプリの配布方法に迷った時の道標として使えるページです。是非、本稿をブックマークして頂き、アプリ配布方法に迷ったら参照するようにして下さい。

配布方法全7種

以下に一覧を列挙します。

AppStore公開アプリ

AppStore上に公開されている既存アプリは全てABM+MDM経由で配信することができます。例えば Box や DocuSign など既存アプリを業務でそのまま使う場合が該当します。

(業務用バージョンを別アプリとしてAppStore公開しているものもある。上手はBoxの例)

ABMやMDMという言葉が初見という方は以下を参考にして下さい。

• MDMとは何か 〜今さら聞けないMDMの基礎〜
• ABM(Apple Business Manager)とは何か
• iOSDC 2020 Day1 でエンタープライズiOSについて講演しました（YouTubeで収録動画が公開されました）

ABMでAppStoreのアプリを一括購入(VPPということもある)してMDMに同期して、MDMから配布します。

(ABMでAppStoreにあるGMailアプリを一括ライセンス購入する様子)

多くのMDMで、アップデート時の振る舞いをアプリごとに制御できます。

(アプリ毎に自動更新するかどうかを決めることができる。上手はBizMobile Go!)

自動で更新させることもできれば、明示的な更新を強いることもできます。通常は自動更新としておくのが良いでしょう。

カスタムApp

現時点(2022年3月)で、特定企業用の非公開アプリを無制限に配信できる唯一の方法です。

AppStoreのインフラをそのまま使いますので、ADP(Apple Developer Program)の契約が必要で、アプリ毎にAppleの審査が必要です。

(AppStoreに申請する際に、実は「非公開」を選択できる)

審査が通ればそれで完了…ではありません。ABMから当該カスタムAppを一括購入し、MDM経由か引き換えコードを使った配布をする必要があります。カスタムAppについては以下に記事をまとめていますので御覧下さい。

• カスタムAppのカテゴリ全記事 (全記事11件の一覧)

非表示App

2022年に新たに登場した配布形式です。

AppStore公開アプリではあるものの、AppStoreアプリでの検索に出てこなくなり、当該アプリのURLを知っている人だけがインストールできるという配布形式です。

例えば「特定組織内で限定的に使うわけではないが第三者に見せる必要のないアプリ」で利用できます。

AppStoreへの通常のアプリ審査の他、非表示化を申請して受理される必要があります。申請時に合理的な理由(なぜカスタムAppではないのか)を説明することが求められます。詳しくは以下をご覧下さい。

• 非表示App(Unlisted App)とは何か

InHouseアプリ

ADEP(Apple Developer Enterprise Program)の契約を締結できている組織だけが利用できます。現在その契約を持っていない組織ではこの配布方法は事実上採用不可です。

AppStoreインフラを使いませんので審査は不要です。配布台数制限もなく、MDMとABMの連携も不要で、最もシンプルで理解しやすい配布方法です。詳しくは以下の投稿をご覧下さい。

• ADEPとは
• ADEPはもう取得することができないと諦めたほうが良い理由

なお、ADEPを契約済である企業であっても、ADEP契約が更新できなくなってきている点は注意して下さい。2022年に入ってから ADEP の更新を Apple に拒絶されたとの報告が幾例かあります。更新を拒否された場合、急いでカスタムAppを使った配布体制に切り替える必要があります。以下を御覧ください。

• ADEP契約を更新せず放置するとInHouseアプリはどうなるのか
• そろそろADEP契約更新ができなくなるかも知れない 〜カスタムAppへの移行を急ぐべき理由〜

ADEPを継続できている企業は、規約違反で契約取り消しとならないよう注意しましょう。以下で規約違反になるパターンをおさえておくことをお勧めします。

• ADEPの契約ができないパターン集

Webクリップ

WebサイトやWebシステムをアプリのように配布する形式です。MDMを使ってWebのショートカットを配布するようなイメージです。

(アプリのように見えるが実はWebサイトのショートカットという例)

ハードウェアの機能を使わない、オンライン前提にできる、通知はメールやチャットで十分、といった条件を満たせる環境なら、わざわざネイティブアプリを開発しなくても擬似的にアプリ配布が可能です。

面倒なAppleへのアプリ申請やABMの操作等が不要になります。MDMさえ用意できればアプリ配布ができますので、ネイティブアプリ開発に課題がある場合、積極的に活用を検討すべき配布方法です。アプリ開発の知見が余りないWebシステム会社にとっては、アプリ開発提案の「亜種」として採用できる可能性があります。詳細は以下にまとめていますのでご覧下さい。

• Webクリップのカテゴリ全記事 (全7記事)

TestFlight

アプリの申請前や、申請後の本配信前に、関係者限定のテスト用途で使用する配布方法です。

前述したAppStore公開アプリやカスタムAppを使って業務用アプリを配布する場合に、アプリの初回配布前のフェーズや、アプリのアップデート版の本配信前テストに使用します。

ADPの Apple Developer サイトでテストしたいバージョンを指定し、テスターをグループ単位や個人単位で紐付けます。

(これまでInHouseでの配布経験しかない企業は TestFlight をよく理解することが求められる)

テスターは情シス担当者、社内評価担当者等が対象となります。テスターのiOS端末には TestFlight なるApple公式専用アプリを予めインストールしておく必要があります。

TestFlightアプリでインストールされたテスト用アプリには、有効期限が90日、旧バージョンにいつでも戻せる、などの特徴があります。なお、TsetFligth は原則、本番運用アプリで使ってはいけません。

AdHocアプリ

上限100台という台数制限があるものの、審査不要のアプリ配信が可能な方法です。動作対象端末のUDID(端末識別子)をあらかじめ収集しておく必要があって運用は少々面倒です。

UDIDを紐付けたAdHoc用の Provisioning Profile を使ってアプリを署名して生成した .ipa ファイルは、UDIDが一致する端末でのみインストール・起動できるようになるという仕組みです。

(UDIDを登録した権限ファイルを生成する様子。生成したファイルをビルド時にアプリに紐付ける)

インストールには有線・無線の両方が使えます。それぞれ以下を参照して下さい。(前者のタイトルはInHouseアプリだが、AdHocアプリでも使用できる)

• Apple Configurator2 で InHouse アプリをインストール・アンインストールする方法と「信頼」について
• OTA(Over The Air)とは何か

また、AdHocアプリの用途や配布先制限については以下を参照して下さい。

• AdHoc配布はテスト用途以外に使用できるのか
• AdHocアプリを社外ユーザに配布できるのか

以上、業務用アプリの配布方法7種を解説しました。詳細についてはそれぞれ対応する投稿がありますので併せてご覧下さい。

(WWDC2020でMac端末の自動初期設定を紹介するセッションで zero touch という言葉が使われた)

Deployment とは多数の業務用端末を管理下に置いてポリシーに基づく設定を行うことです。その煩わしい作業を Zero Touch でやることを Zero Touch Deployment と呼んでます。さすがに文字通り Zero Touch とはいかないので実のところ誇張表現ですが、1台1台ポチポチ設定する行為がほぼ不要なので Zero と言っています。

誇張表現になっているからかなのか分かりませんが、Appleが公式に Zero Touch Deployment ということは実は余りありません。また他のエンタープライズiOS用語のように略称で呼ばれることもありません。例えばZTDとでも略記しそうなものですが、そのような表記もありません。

ですが、Zero Touch Deployment を正しく理解しておくことは重要です。設定作業の省力化を突き詰めた究極の理想形であり、全ての業務用iOS端末が目指すべきゴールだからです。

そこで本稿では Zero Touch Deployment の全体像を解説します。複数のエンタープライズiOSキーワードの理解が必須となりますが、長くなるので個別の説明は省きます。ただ既存投稿を参照情報として示して説明しますので、適宜関連投稿を参照しながら読み進めて下さい。

また、最後に Zero Touch Deployment が機能している様子が分かる動画も紹介します。

Zero Touch Deployment = MDM + DEP + ABM

業務用端末で一番大変なことは設定作業です。5台10台なら手作業で何とかなりますが、50台を超えて3桁4桁の台数になってくるともう手に負えなくなります。

(有線だと十数台設定しようとするだけでこんなことになる)

そこで役立つのが MDM (Mobile Device Management)。端末を支配下に置き、遠隔でアプリや設定を流し込めるようになって設定作業を省力化できるのでした。

• MDMとは何か 〜今さら聞けないMDMの基礎〜

ただMDMで万事解決とはいかないことに注意が必要です。そもそもMDMにチェックインしなければ、MDMから遠隔設定やアプリ配布はできません。ではそのチェックインは誰がやるのか。3桁4桁に及ぶ台数の端末のMDMチェックインを手作業で行うのは苦行でしかなく、現実的ではありません。

• MDMの導入から利用開始まで(2) -MDMチェックイン-

それを楽にしてくれるのが DEP (Device Enrollment Program)。DEPの仕組みを使えば、端末をMDMに自動チェックインさせられるのでした。

• DEPとは何か
• SDE, ADP, DEP, ABM, ADE…名称がコロコロ変わる端末登録の歴史

では DEP はどうすれば使えるのか。DEPはMDMチェックインを自動化する仕組みですから、MDMに内包される機能ではない筈です。MDM外の世界に別の仕組みが必要になります。それが ABM (Apple Business Manager) なのでした。

• ABM(Apple Business Manager)とは何か

DEPが使える端末は購入と同時にABMに自動登録され、それらがMDMに連携される。この3つが連携してはじめて Zero Touch Deployment が実現できるというわけです。

Zero Toutch Deployment を行う手順

前項のとおり MDM + DEP + ABM ですので、以下のようにやるべきことは多岐に渡ります。

(1) MDMを契約する
(2) ABMアカウントを取得する
(3) ABMとMDMを連携させる
(4) DEP端末を購入する
(5) ABMでDEP端末をMDMに割り当てる
(6) MDMでDEP端末の自動チェックイン時の設定を行う
(7) MDMでDEP端末に割り当てるアプリやiOS設定情報を紐付ける

ここまでやってようやく、開梱してネットに接続すれば Zero Touch Deployment で自動設定完了できる環境の出来上がりとなります。一つ一つ漏れなく進めていく必要があります。前項に記した関連投稿リンク先を参照することで滞りなく進めることができるでしょう。

また、非公開アプリの配布を含めると上図のように App Store Connect や Custom App 等の理解も必要になります。こちらも長くなりますのでここでは割愛しますが、興味があれば以下を参照して下さい。

• iOSDC 2020 Day1 でエンタープライズiOSについて講演しました（YouTubeで収録動画が公開されました）

Zero Touch Deployment が機能する様子のノーカット動画

実は、Zero Touch Deployment が実際に機能する様子を目にする機会は余りありません。開梱から電源ONしてネットに繋げるだけで設定が完了する…という挙動ですから、そう何度も何度も新規端末購入とその開梱作業に立ち会える訳ではないからです。

そこで、実際に新規DEP端末購入した未開封の端末で Zero Touch Deployment が機能する様子の動画を公開することにしました。

以下は、Appleから納品された未開封のDEP端末である iPod touch を開封、WiFi に繋ぐだけでMDM自動チェックイン、監視モード化、設定アシスタントは「位置情報」のシートのみの表示とし、HOME画面で設定が適用される様子の動画です。設定は「設定アプリ以外を全部非表示化する」のみ。アプリ等は配信していません。(動画はノーカットで約3分)

Zero Touch Deployment の雰囲気や「楽さ」を感じて頂けると思います。

無論、この動画のような「標準アプリ非表示化」の設定は必須ではありません。あくまで見た目に分かり易い例にしているだけです。本来は、各企業や各案件ごとの要件に応じて各種アプリのインストールやその他iOS設定の流し込みをするようMDMを適切に設定することになります。

以上、Zero Touch Deployment の詳細と動画を紹介しました。是非活用してみて下さい。手順にも言及しましたが、自社で行うのは難しそうという場合は MDM ベンダーに頼るのが良いでしょう。弊社にご連絡頂いても結構です。

(iPod touchの工場出荷時状態のホーム画面。業務で不要なアプリは結構ある)

大半の標準アプリは下図のようにアプリアイコンを長押しして、削除することができます。

ただ、よく知られている通り全ての標準アプリを完全に消せるわけではありません。下図のアプリは、HOME画面で一時的に非表示にできてもAppライブラリから容易に復元できるので完全削除できないものです。

またこの方法は、一つ一つ削除するという面倒な手動操作が必要になります。一度に複数の端末で例外なく標準アプリを削除したい業務端末には向いていない方法です。

ということで本稿では、業務用iOS端末に適した、任意の標準アプリを(ほぼ)もれなく削除する方法を紹介します。

概要

iOS標準アプリを全て削除するには、構成プロファイルで指定できる「アプリの使用の不許可」設定を使用します。

ここは任意のアプリを使用禁止や使用許可を指定する項目で、ここに消したい標準アプリを使用禁止アプリとして列挙します。エディタを保存し生成した構成プロファイルを端末にインストールすれば、指定した標準アプリを削除できます。(構成プロファイルの作成方法はこちら、インストールについてはこちらとこちらを参照)

インストールした様子が以下です。一瞬で根こそぎ消えているのが分かります。

(Safariと設定アプリを残して標準アプリを全削除する設定を流し込んだ)

以上が全体の流れと実際の動きです。続いて、詳細な作り方や制限事項を詳しく見てみましょう。

iOS標準アプリを削除する構成プロファイルの作り方

まず、Apple Configurator2 で構成プロファイルエディタを起動します。iOS標準アプリ削除用と分かるよう構成プロファイルの一般情報を指定しておきます。(Apple Configurator2についてはこちらを参照)

(構成プロファイルは用途ごとに分けて作成するのが望ましい)

次に「制限」カテゴリをクリックして「App」タブをクリックし、タブ内にある「Appの使用を制限」のリストボックスを「一部のAppを許可しない」に変更します。

リストの下にある「+」ボタンをクリックするとダイアログが現れますので、検索ボックスにアプリ名か、アプリを表すID(バンドルID)を入力します。

上記は株価アプリを指定しようと検索している例です。アプリ名やバンドルIDで検索可能。出てきた候補から削除したい標準アプリを選んでから「選択」ボタンをクリックします。

リストに並びました。

同じ手順で他の削除したい標準アプリを追加していきます。制限数はありません。必要なだけ登録できたら、保存して構成プロファイルのファイル(拡張子 .mobileconfig)を生成します。

インストールの前提条件

構成プロファイルを作る時、「監視対象のみ」と書かれていたことに気づいたでしょうか。

そう、「Appの使用の制限」設定が機能するのは監視モード(Supervised Mode)の端末に限られているのですね。よって、iOS標準アプリを削除する場合、以下いずれかの端末でなければなりません。

• Apple Configurator2 で監視モード化した端末
• DEP端末として購入(またはDEP化)したMDMチェックイン済み端末

個人用の端末はもちろんのこと、MDMチェックイン済みだけど監視モードにはなっていない端末は、上記で作成した構成プロファイルをインストールはできますが、標準アプリは期待通りに消えてくれないので注意して下さい。(監視モードについてはこちら、監視モード化する方法はこちらを参照)

絶対に消せないiOS標準アプリ

実は絶対に消すことができない標準アプリがあります。

• 電話
• 設定

こちらの2つですね。当然と言えば当然でしょう。iPhoneですから「電話」を消したらアイデンティティの喪失です(笑) さすがにそれはできません。設定アプリは言わずもがなですね。全ての設定を一切何も変更できない端末なんて使い物になりませんので消せません。

(使用禁止アプリに電話を指定することもできるが….)

上図の通り禁止対象として指定することはできますが、それらを含む構成プロファイルは端末へのインストールに失敗し、他に指定したアプリも消えてくれません。くれぐれも電話と設定アプリは含めないように注意して下さい。

(インストールに失敗する。電話アプリ・設定アプリ以外に指定していたものも消えない)

iOS標準アプリの一覧について

構成プロファイルを作成していると、iOS標準アプリを全部列挙することに結構難儀します。

工場出荷時状態の端末が手元にあればすぐ分かりますが、工場出荷時状態の端末はそうそう簡単に用意できるものではありません。またiOSのアップデートで標準アプリは増えたり減ったりもしますので、それを調べるのも面倒です。

そこで役立つのが、GitHubに公開されているiOS標準アプリ一覧リポジトリ。

毎年新しいiOSが登場する度に更新してくれていますので、ここを参考に一覧を作っていくことをお勧めします。

ということで、iOS標準アプリを(ほぼ)全て削除する方法を紹介しました。

(設計図-ブループリントを作り、それを然るべき端末郡に適用する)

組織内の全端末が全く一緒というケースは稀ですので、多くの場合、設計図は幾つも作ることになります。ただ設計図を作るといっても、まずその設計図に何が含まれるのか網羅的に把握しておく必要はあるでしょう。

そこで本稿では、設計図を介してデバイスに流し込む「プロファイル」に何が含まれるかを解説します。ただ、MDMによって設定の仕方やUI/UX、使っている用語などが異なるという点は留意して下さい。冒頭の図に沿った基本的なMDMの考え方として捉えて頂ければと思います。

プロファイルは大きく3種類

エンタープライズiOSにおけるプロファイルとは組織として端末をどのように使わせるのかを規定するものです。別の言い方をすると、端末に対する「設定」「制限」「権限」「許可」といったものの定義情報と言えるでしょう。

アプリ開発者の方であれば、プロビジョニングプロファイルに馴染みがある筈です。これはInHouseアプリを起動する「権限」情報ですね。そのプロビジョニングプロファイルを含めて、プロファイルには大きく3種類があります。

そもそもプロファイルという言葉を使わないMDMサービスもありますので、この3種のプロファイル名が言葉通りには出てこなくても心配は不要です。

ようは、(1)OSレベルの設定、(2)DEP端末用の設定、(3)アプリの起動権限、この3つを設計図に紐付けることができるということだけ押さえて下さい。(DEP端末についてはこちらを参考)

順に詳細を見ていきましょう。

(1) OSレベルの設定・制限 : 何ができるか Apple Configurator2 に学ぶ

以前の投稿でMDMの設計指針は Apple Configurator2 のブループリントという機能に学ぶと良いと書きました。実は、Apple Configurator2は、構成プロファイル(OSレベルの設定・制限)について学ぶ学習教材としても最適なツールです。

というのも、適用可能な設定・制限をほぼ全てカバーする構成プロファイルエディタを搭載しているからです。厳密には Apple の公式情報 Configuring Multiple Devices Using Profiles を見るべきですが、Apple Configurator2 の構成プロファイルエディタでほぼ全てを楽に俯瞰することができます。

(Apple Configurator2 の構成プロファイルエディタ。カテゴリ毎に指定可能な設定・制限を俯瞰できる)

左のペインが設定・制限できる大分類です。画面キャプチャでは見えないぐらいにカテゴリが並んでいますね。それぐらいiOSに指定できる設定・制限が多様だということです。是非、手元のMacで Apple Configurator2 から構成プロファイルエディタを起動して、どんな設定が可能なのか眺めてみて下さい。(Apple Configurator2 の使い方はこちら)

さて一方で多くのMDMサービスは、Apple Configurator2 と同様の構成プロファイルエディタ(または設定・制限エディタ)を備えています。

(jamf NOW の画面。制限を指定している様子。構成プロファイルというキーワードは使用していない)

ですが、いきなりMDMサービス上で設定・制限を設計することは余りお勧めしません。MDMサービスの契約プランによって使えない機能があり全貌を把握できない場合があるからです。また、iOS以外にWindowsやAndroidの設定用UIまで混在しているMDMもあり、MDM利用経験が浅い方は混乱必至だからです。

(あらゆるOSの設計図を Policy という概念でまとめている hexnode mdm の例)

これに対し Apple Configurator2 の構成プロファイルエディタなら、iOSに限定してどんな設定ができるのかだけを、ほぼ全て把握できます。またADP/ADEPで developer 登録していたり AppleSeed for IT の契約をしている場合は、未公開beta版の Apple Configurator2 を先行して見ることもできます。

(リリース前のiOSに設定・制限できる見込みの内容を確認できる。これはサードベンダーのMDMサービスではできない)

そういうわけで、できれば常に最新バージョンの Apple Configurator2 の構成プロファイルエディタを使って、OSレベルでどんな設定・制限ができるのか概観しておきましょう。弊社では、情シス部門に最低Mac1台を用意して、リファレンスとして Apple Configurator2 をいつでも確認できるようにしておくことを推奨しています。(Beta版利用のためにもう1台加えた計2台が理想です)

(2) DEP端末の設定 : MDMサービスの管理画面で確認

DEP端末にはOSレベルの設定・制限とは異なる次元の設定・制限があります。これをDEPプロファイルと呼びます。例えば、MDM支配下から外れることを許可するかどうかや、初期設定アシスタントの表示抑制などが含まれます。(詳しくはこちら)

DEPプロファイルの一覧は残念ながら Apple Configurator2 では見ることができません。

 
(DEP化という作業を行う過程でDEPプロファイルに含める設定を見ることができるが面倒臭い)

MDM仕様書の Device Enrollment Program の章(p.96)を見るのもの良い選択ですが、英語な上にこちらも分かりにくいので余りお勧めできません。

(DEP端末の詳細が記載されているが、どちらかというとMDMサービスを開発するベンダーのための内容)

よってDEP端末の設定に何が指定できるのかは、使用しているMDMサービスのサポートに、DEP(Device Enrollment Program)やADE(Automated Device Enrollment)のキーワードを告げて確認するかマニュアルを検索するのが良いでしょう。(DEPやADEの違いについてはこちら)

(弊社がよく使うBizMobile Go!ではDEPプロファイルという設定画面が用意されている)

(3) プロビジョニングプロファイルは詳細確認不要

最後のプロファイルは、プロビジョニングプロファイルです。ただプロビジョニングプロファイルを普段意識する必要はないでしょう。意識する必要があるのは、

• MDMでInHouseアプリを配信している
• 当該InHouseアプリの ipa ファイルのリビルドや再署名が困難

という極めて稀なケースです。

余り知られていませんが、プロビジョニングプロファイルの期限が切れたからといってInHouseアプリを毎年再署名(再ビルド)する必要はありません。実は MDM でInHouseアプリ用のプロビジョニングプロファイルを単体で配信し、期限が切れたInHouseアプリの利用を継続させることができます。

そのような運用が必要な場合に、設計図にInHouseアプリ用のプロビジョニングプロファイルを登録します。ただこの機能に対応していないMDMもありますので注意して下さい。

(MDMの管理下にある端末には、プロビジョニングプロファイルを単体で配信できる)

なおプロビジョニングプロファイルは Apple の Developer Console で生成するもので、InHouseアプリの場合プロビジョニングプロファイルに特別な設定は特に行いません。せいぜい Bundle Identifier と署名時に使う証明書の指定ぐらいです。

(InHouse用のプロビジョニング作成時には特別な設定を何も行わない)

通常は、再署名やリビルドで毎年InHouse用のipaファイルを生成し直す運用が多いことでしょう。プロビジョニングプロファイルは当該InHouseアプリと共にデバイスにインストールされますので、普段は特別に意識しなくてもいいわけです。この件はまた別の投稿で詳しく解説します。

以上、MDMの導入設計に関連して「プロファイル」について解説しました。

今一度まとめると、「設計図」に盛り込むプロファイルが3つあるということでした。

• (1) 構成プロファイル
• (2) DEPプロファイル
• (3) プロビジョニングプロファイル

通常、MDM導入の設計時には構成プロファイル、つまりOSレベルの設定・制限を意識するのみで十分です。(1)に書いた通り Apple Configurator2 の構成プロファイルエディタを設計の参考にして下さい。