初日のキーノートでは、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/) 等のセッションもありますので、興味ある方はあわせて視聴してみると良いでしょう。

(黎明期に見られるエンタープライズ機能の進化を紹介する2015年実施の弊社セミナー資料)

今でもメジャー・マイナーのアップデートに関わらず、エンタープライズ機能はアップデートの度に追加・修正され何かしら進化し続けています。その進化の全貌をみる方法はこれまでありませんでした。AppleのプレスリリースやApple Developer 登録者に送られてくる案内、WWDCの各セッションから断片的に知るしか無かったのです。

ご承知のとおり、リリース前の最新iOSを試す方法は色々と用意されています。

• 開発者として Apple Developer Program に参加する
• ユーザとして Apple Beta Software Program に参加する
• 情シス担当者として AppleSeed for IT に参加する

が、業務用iOS端末やアプリの運用観点では期待する網羅的な情報は得られません。業務用iOSに関わるものとしては、iOSがアップデートの度に エンタープライズ機能の何が変わったのか を一覧で知りたいわけです。

という前ふりで、実はありますよ、というのが本稿です。ご紹介したいのが以下のページ。

(更新履歴が事細かにアップデートの度に追記されていく)

まさに求めているページタイトルですね。エンタープライズ機能の何が変わったかを確実に知りたい場合は、このページをブックマークしておき、定期チェックしておくと良いでしょう。

実はiOS14の頃から、Appleはエンタープライズ機能に特化したバージョン毎の更新情報ページを設けるようになりました。現在はiOS14,15,16の業務用機能の各アップデートの詳細を一覧で見ることができます。(iOS13以前はありません)

• iOS 16 のエンタープライズ向けの新機能
• iOS 15 のエンタープライズ向けの新機能
• iOS 14 のエンタープライズ向けの新機能

眺めるだけで、不具合修正が思ったより結構あったり、構成プロファイルで制限できる機能がちょいちょい追加されている様子を見れて興味深いです。新しい発見も多い筈ですので是非一度目を通してみて下さい。

ちなみにこれらを集約したリンク集のようなページは提供されていませんので、新しいメジャーバージョンがリリースされる度に「iOS XX のエンタープライズ向けの新機能」と XX にバージョン番号を入れてググられるのが良いでしょう。

なお、一般消費者向けの情報も含むアップデート情報は昔からあります。メジャーバージョン毎に専用ページが用意されていますので、参考までに以下に一覧しておきます。(iOS4以前はありません)

• iOS 16 のアップデートについて
• iOS 15 のアップデートについて
• iOS 14 のアップデートについて
• iOS 13 のアップデートについて
• iOS 12 のアップデートについて
• iOS 11 のアップデートについて
• iOS 10 のアップデートについて
• iOS 9 のアップデートについて
• iOS 8 のアップデートについて
• iOS 7 のアップデートについて
• iOS 6 のアップデートについて
• iOS 5 のアップデートについて

また、アプリ開発者であれば各バージョンの Release Notes も参考になるでしょう。Apple はここ最近ドキュメントの整備を進めており非常に見易くなっていますのでお勧めです。開発・実装の観点で変更点を俯瞰できます。

(Apple Developer Program の契約が無くても誰でも見れる。ただしiOS12以降のみ)

ということで、本稿ではエンタープライズ向けの新機能を網羅的に見る方法について紹介しました。業務用iOSアプリに関係する方は常にチェックしておくようにしましょう。

おかげさまで業界関係各位の間で参考資料として当サイトの投稿をシェア頂いたり、エンタープライズiOSについて学ぶ入り口として推奨して頂ける例も出てきました。

https://t.co/BxpGju9vrt

iOS カスタムAppの一番わかりやすいまとめ。

— 佐藤伸彦 (@syobon_san) December 20, 2021

そのほか、初めてお会いした方に「あのサイトの…」とおっしゃって頂くことも増えてきています。日頃のご愛顧に御礼申し上げます。

さて今年最後となる本投稿では、この1年で最も読まれた投稿の紹介と、来年の方針を記したいと思います。

2021年で最も読まれた記事

年始の12ヶ月間PV数上位5つの投稿を以下に示します。

• (1) ABM(Apple Business Manager)とは何か
• (2) MDMとは何か 〜今さら聞けないMDMの基礎〜
• (3) ADEP(Apple Developer Enterprise Program)はもう取得することができないと諦めたほうが良い理由
• (4) Apple Configurator2 とは
• (5) ADEP (Apple Developer Enterprise Program) とは何か

基本的な用語解説の投稿にPVが集中しており、まだまだ業務用端末の管理方法や配備方法についての情報が求められていることが分かります。

特に1番目のABM(Apple Business Manager)とは何かのPV数は本サイト全体を見ても突出しており、まだABMを導入できていない企業、ABMを使いこなせていない企業が相当数いらっしゃることが推測されます。まだまだ情報発信が必要だなと感じます。

本サイトでの記事投稿を含めて、昨年/一昨年でiOSDCに登壇したような形式も出来ることなら継続し、来年も色んな形で多くの方にエンタープライズiOSの情報をお届けしたいと思っています。

2022年のサイト方針

本年同様、用語や機能の解説投稿を行っていくつもりです。週1ペースで書けば年内でネタは尽きると考えていましたが、全くそんなことはありませんでした。それだけエンタープライズiOSの世界は奥深いということでしょう。

そもそもABMやMDMの深堀りは十分にできていませんし、Guuided Access や Single App Mode には言及すらできていません。これらを含め、他の用語や機能についても順次解説していく予定です。

加えて、来年は新しい試みも考えています。

もう少し現場の課題解決に貢献できればという考えから、どんなテーマの解説が欲しいかリクエストを受け付けたり、質問と回答を投稿する前提で「こんな場合は何を使えば良い？」といった質問も受け付けてみようと思っています。

(WWDC2020の講演では実顧客を想定して解説したが、具体的で分かり易かったとの声が多く頂いた)

こういうことがしたいならこれをこう使う…のような逆引き集ができると良いですね。折を見て受付フォームなどを設置してご案内したいと思います。

また、体系的にエンタープライズiOSを理解できるコンテンツの開発も予定しています。実は問い合わせを頂く際に「アプリ開発は分かるけど業務用アプリの配布方法がよくわからないので一通り教えて欲しい」という声は意外に多かったりします。

現在、そんな声にお応えするための方法や手段を検討しています。どんな形になるか未定ですが開発時間確保のため2022年は投稿頻度が落ちる見込みです。(本年比50%程度?)

以上、2021年のPV数ベスト5投稿の紹介と、来年の方針について書きました。2022年もエンタープライズiOS研究所サイトをよろしくお願い致します。

(iPod touch で動いていたInHouseアプリ。iOS15アップデート直後に突然起動できない状態に…)

ダイアログには「AppをこのバージョンのiOSで動作させるには、デベロッパによるアップデートが必要です。」とありますが一体何をすれば良いのでしょうか。

本稿では、このような現象に遭遇した方を対象に原因と解決策について解説します。

現象の原因

よく知られているようにiOSアプリはビルド時に署名を行います。アプリの起動時には、iOSがその署名の妥当性を検証します。問題があればそのアプリは起動させて貰えません。例えば、provisioning profile の期限が切れて起動できなくなるのが分かり易い例ですね。

(冒頭のキャプチャとは別の iPad 専用アプリ。Provisioning Profile の期限が切れたわけではない)

今回問題にしているこの現象は、iOS15がよりセキュアな署名チェックを行うようになったことの影響で、署名が妥当でないと判断されるようになってしまったことに起因します。条件が厳しくなって、今まで大丈夫だったのに急に怒られるようになったというわけです。

実は、macOS Mojave(10.14) の頃からアプリの署名が新しい形式となっていて、さらに特別な Entitlement (許可情報) が含まれるようになりました。iOS15がそれらを厳密にチェックするようになったため、

• 新しい形式で署名されていない InHouse アプリ
• 新しい形式だが適切な Entitlement を含んだ署名になっていない InHouse アプリ

である場合に本現象が発生します。

毎年新しい環境でInHouseビルドして配布している環境では問題ない筈ですが、古い InHouse アプリを Provisioning Profile の単体配信で延命利用していたり、ずっと古い macOS や Xcode を使ってビルドしているInHouseアプリなどが該当します。

対応策

やるべきことは至って簡単で、

1. macOS Big Sur 以降でビルド or 再署名する
2. 生成した InHouse の ipa ファイルを配布する

の2ステップで解決できます。

少し余談になりますが、こんな時に MDM が導入されていない現場では大変です。2.の配布を管理側のオペレーションで遠隔一発更新というわけにはいかないからですね。このようなケースでもスピーディな対応ができるように、やはりMDMは導入必須です。まだの企業は是非導入を検討して下さい。

iOS15アップデート前に確認する方法

まだ iOS14 以下で InHouse アプリを使っている場合、事前に本現象が発生するのかしないのか確認しておくことをお勧めします。

iOS15のリリース(2021/9/21)から90日間はアップデートを抑制できますが、本記事執筆時点(2021/12/13)で期限は残り1週間しかありません。2021/12/21以降は、iOSアップデート抑制の設定を配信していても各端末でiOS15へアップデートできるようになります。(参考 : iOSのアップデートができないように抑制する方法 〜前編〜)

現場が勝手に iOS15 にアップデートし始めてしまう前に、本現象に遭遇するのかを調べておきましょう。iOS15環境がなくても InHouse アプリの ipa ファイルさえあれば、以下の手順で確認することができます。

(1) まず InHouse の ipa ファイルを解凍します。 (.ipa は実質 zip 形式のアーカイブファイル)

% unzip myApp.ipa
Archive:  myApp.ipa
   creating: Payload/
   creating: Payload/myApp.app/
   creating: Payload/myApp.app/_CodeSignature/
  inflating: Payload/myApp.app/_CodeSignature/CodeResources
...(略)...

(2) Payload というディレクトリが生成され、中に [アプリ名].app というディレクトリが現れます。(Finder上ではファイルのように見える)

% ls -l Payload
total 0
drwxr-xr-x@ 43 oishi  staff  1376 12 11 19:16 myApp.app/

(3) このパスに対して codesign コマンドを以下のように実行します。

% codesign -dvvvvv Payload/myApp.app
Executable=/path/to/ipa/Payload/myApp.app/myApp
Identifier=jp.feedtailor.myApp.inhouse
Format=app bundle with Mach-O thin (arm64)
...(略)...
Executable Segment base=0
Executable Segment limit=688128
Executable Segment flags=0x1
Page size=4096
    -5=f79bb5d986cfbb60b019f8e4be46a537ae2dcdfc15c9ca56303a45e8ab8bba37
    -4=0000000000000000000000000000000000000000000000000000000000000000
    -3=17891e74b11e06c57310a39c05558d7a0fdeb5c1fc5bb82d8dd76f2d0b22994c
    -2=da7932525b77ccade37b4ac72b436eae3a06271b4e75ee7858527518b317440a
CDHash=fb91e7653ec272ead220a38713a09c95455d43fe
Signature size=4755
Authority=iPhone Distribution: feedtailor Inc.
Authority=Apple Worldwide Developer Relations Certification Authority
Authority=Apple Root CA
Signed Time=Dec 11, 2021 19:16:28
...(略)...

表示された署名情報の中で、-7 という項目が存在していなかったり(上の例。-2から-5までは存在する)、-7 が存在していても 0000〜 となっている場合は再署名が必要です。mac OS BigSur 環境での再署名が推奨されます。逆に以下のように -7 の項目が存在している場合は、再度署名が不要で本現象には遭遇しないと判断できます。

Page size=4096
    -7=6f44c7b43a6b0f20a8126100b905005e4a527bedeb321e598c56c443e394d667
    -6=0000000000000000000000000000000000000000000000000000000000000000
    -5=f79bb5d986cfbb60b019f8e4be46a537ae2dcdfc15c9ca56303a45e8ab8bba37
    -4=0000000000000000000000000000000000000000000000000000000000000000
    -3=17891e74b11e06c57310a39c05558d7a0fdeb5c1fc5bb82d8dd76f2d0b22994c
    -2=da7932525b77ccade37b4ac72b436eae3a06271b4e75ee7858527518b317440a

本件の詳細は Apple も公式ドキュメントで解説してくれています。Using the Latest Code Signature Format のページを併せてご覧下さい。

ということで、InHouseアプリがiOS15で突然動作しなくなる現象の原因と対応策について紹介しました。

ちなみに AppStore アプリや TestFlight 配信されるアプリでは発生しません。AppStoreから各ユーザ端末に配信される前に Apple 側で適切に再署名されるからです。このことを考えてもやはり、ADEPによるInHouseアプリ運用から早く脱却し、AppStore公開アプリかカスタムAppの運用にした方が良いことが分かりますね。(参考 : ADEPはもう取得することができないと諦めたほうが良い理由)

(今年も昨年に続いてオンラインで開催された)

昨年のiOSDC Japan 2020 ではエンタープライズiOSの全体像を俯瞰する話をさせて頂きましたので、今回は特定のテーマにフォーカスを当てようということで Managed App Configuration を選びました。

前回はリアルタイムに300人ぐらいの方にご覧頂きましたが今回はかなり特化したテーマなので多くても100人ぐらいかなぁと思ってました。が、実際には800人超えのエンジニアの方に聞いて頂きました。視聴頂いた皆さん、ありがとうございました。

(リアルタイムの配信は時間割に沿ってニコ生にて配信された)

テーマに選んだ Managed App Configuration は、MDMを使ってアプリ固有の設定値を配信する仕組みです。

(アプリ初回起動時にはもうそのアプリに必要な設定作業が終わってる…という魔法のような機能)

活用すると物凄く強力なので、何年も前からiOSエンジニアの皆さんに知って貰いたかった機能なんですね。それを多くの方に紹介できたのは良かったです。嬉しいことにリアルタイムにTwitterでは、

#iosdc #b Managed App Configuration 圧倒的じゃないか。。。

— sumitch (@sumitch) September 18, 2021

のような感想も頂きました。また、iOSDC 2021閉幕後には以下のような感想コメントも頂きました。

2021/09/18 14:40
素晴らしいトーク、ありがとうございました。
MDM とか ABM 周りは、あまり知見が公開されていないので、いつも困ってました。
oishi さんのトーク、とてもわかりやすくて実用的で、ためになりました。

多数の Mac のキッティングを行なって設定（OS, Apps 両方）まで揃える必要があるのですが、 Apps（Managed App Configuration に対応したものだけとは言え）の設定まで揃えられるのがわかったのはよかったです！

2021/09/18 22:22
Managed App Configurationがどういうものか、それをどう活用できるのかという点が丁寧に解説されていてわかりやすかったです

2021/09/19 06:48
貴重な話が聞けました。ありがとうございます。

2021/10/04 22:09
MDMを利用して端末ごとに値を注入する手法は、現在関わっているプロジェクトで今すぐ使えそうな内容でとても参考になりました。
トークありがとうございました！

評価頂けたのがとても嬉しかったです。準備した甲斐がありましたね。Managed App Configuraion の採用により全ての業務用アプリでデプロイメントの労力を軽減できますので、活用が広がると良いなと思います。

さて、そんな当日の講演がYouTubeで公開されました。どなたでも視聴することができます。

エンタープライズiOS全般の理解が前提となりますので、全体像を捉えきれていない方は昨年の講演を先に視聴されることをお勧めします。

今回のiOSDC Japan 2021は、弊社でも新アプリの開発をしていることもあって興味のあるセッションが多かったです。昨年以上にオーディエンスとして楽しんだイベントになりました。

来年もまた機会を頂けるようであれば、エンタープライズiOS分野の何か特化したテーマでお話ができればなと思います。

(エンタープライズiOSを取り巻く専門用語にはサービスを意味するキーワードも多い)

例えば、ABM や VPP(アプリ一括購入) などは Apple がエンタープライズ向けに提供する立派なWebシステムですし、ADEP の InHouse アプリはあるサービスが落ちていたら起動すらできないこともあったりと目に見えないところで Apple のWebシステムに依存していることもあったりします。

Appleの各種Webサービスが安定してこそのエンタープライズiOSですから、それらが「今」正常に稼働しているのかどうかを確認する方法を知っておくことが大切です。本稿では、エンタープライズiOS関係者が知っておくべき2つのサイトを紹介します。

Apple System Status

Apple System Status サイトは、Appleが提供する各種Webシステム(クラウドサービス)のステータスを一覧で俯瞰できるようになっているサイトです。

(日本国内で提供されているAppleの全サービスの稼働状況を俯瞰することができる)

実に様々なサービスをAppleが運用していることが分かります。総勢57システム。iCloud系は名称からしてすぐクラウドが関係していると想像がつくにしても、「え？このアプリも専用のWebシステムがあるの？」と驚くものも幾つかありますね。

さて、57個のうちエンタープライズiOSに関係があって重要度が高そうなものはどれでしょうか。参考までにですが、筆者が日頃から気にしているものに赤枠をつけてみました。

(大事なものが一つ欠けていることに気づくでしょうか。詳しくは後述)

• AppStore
• Apple ID
• Device Enrollment Program
• iOSデバイスアクティベーション
• Volume Purchase Program

サイトの見方は簡単で、緑色が正常稼働中であることを意味します。上図では全て緑色(Available)ですので、つまり何もトラブルが起こってないということです。万が一障害が発生した場合には、問題のあるシステムのマークが黄色や赤色に変わります。例えば、直近の2020年9月に大規模な障害が発生した時は以下のような状態になりました。

(Appleのネットサービスで大規模な接続障害が発生【復旧済み】より引用 @ITmedia NEWS 2020/9/30)

赤色(Outage)はサービスが完全に落ちて停止している状態。赤色のサービスは「今」使えない状態であることを意味します。また黄色(Issue)は「今」部分復旧を含む復旧過程である状態を表します。クリックすると問題の所在や、Appleがどのように対応したか詳細情報を見ることができます。

もし、「ABMにサインインできないぞ…」とか「カスタムAppを一括購入できないぞ…」と不審に感じた時は、この Apple System Status の画面を見てみると良いでしょう。Appleによる公式情報ですので、もし赤色や黄色になっていれば、お客様に状況を説明する一次情報としても使うことができます。

ただ、上の画像で気付いた方もいるかも知れませんが、日本語と英語とで表示される項目が異なっていることに留意して下さい。各国で提供されているサービスが異なるので当然といえば当然なのですが。(興味ある方は URL の jp の部分を uk や cn や kr に変えると各国での状況が見えますのでお試し下さい)

が、エンタープライズiOS関係者として気になるのは、日本向けの Apple System Status サイトに Apple Business Manager が含まれていないこと。Apple Business Manager は米国本家の System Status サイトにしか表示がありませんので、米国の Apple System Status の画面も同時に確認することをお勧めします。

(日本向けと違って Apple Business Manager がきちんと存在するのが分かる)

Apple Business Manager は申請時に国を指定したり、アプリ一括購入の関係で国に関連付いて既に提供されているものですので、ここは一点不思議な点ではあります。DEPやVPPを各国で表示するならそれを内包するABMも各国表示して貰いたいところです。

さて、少し横道にそれましたが、もう一つ見るべきサイトがありますのでご紹介します。

Apple Developer System Status

名称は筆者が勝手につけて呼んでいるものですが、Apple Developer System Status は開発者向けに用意されたAppleの各種Webシステム(クラウドサービス)のステータスを俯瞰するサイトです。

システムは全部で38個。多くの項目でリンク先がそれぞれ対応する公式ページになっているのは親切な作りですね。この一覧の中で筆者が日頃 watch しているものは以下の通りです。

(先ほどと同じ System Status という名称だが内容は開発者向けシステムの状態一覧)

• APNS
• Certificates, Ideitifiers & Profiles
• Enterprise App Verification
• Program Enrollment and Renewals

MDMはPUSH通知が必須の仕組みですので、MDMの調子が悪いと思ったときにはAPNSのステータスを確認しますし、InHouse アプリの起動に影響を与えかねない Enterprise App Verification の状態にも注意を払っています。

見るべきものは企業やアプリ毎によって異なるでしょうが、前述の Apple System Status サイトに加えてこちらも併せて確認しておくのが良いでしょう。

ということで、エンタープライズiOS関係者が見ておくべき Apple の System Status サイトを2つご紹介しました。お手元のブラウザにブックマーク登録して、何かおかしいと思った時にすぐに開けるようにしておくことをお勧めします。

そこで本稿では、業務用iOS端末の登録(device enrollment)に関連してAppleが使ってきた用語を時間軸で整理します。端末登録(device enrollment)の用語の歴史を知って頂くことが、複雑なエンタープライズiOSを理解する一助になればと思います。

SDE(Streamlined Device Enrollment)

iOSがMDMに対応したのは2010年のiOS4のとき。MDM対応をうけてiOS端末の業務活用が急加速すると、MDMのチェックインや監視モードにする手間が問題視されるようになりました。

エンタープライズ強化を図っていたAppleは、これを受け満を持してWWDC2013のセッション Managing Apple Devices で端末登録(device enrollment)という概念を新たに発表します。

(同セッションでの「たったこれだけです」というAppleエンジニアからの説明に拍手が起こる。41:29)

同セッションではアプリのサイレントインストールやVPPの仕組みも発表されてますので、2014年は2010年のMDM対応に続くエンタープライズiOS転換点と言えるでしょう。この発表当初は、Streamlined という言葉が使われていました。無駄のない簡素化された端末登録…といったところでしょうか。

(MDM支配下から逃れられなくなることが特に歓迎された)

このセッション中に何度も何度も聴衆から拍手が起こっているのが印象的です。SDEはそれだけエンタープライズiOS界隈で待望だったのですね。

ただ発表当初、SDEが可能なのは米国のみで且つ Apple から端末購入した場合に限られていました。

DEP(Device Enrollment Program) と ADP (Apple Deployment Programs)

翌年、進展があります。

2014年、Streamlined Device Enrollment の仕組みの米国以外への提供、及びApple直販以外の購入(公式リセラーやキャリア経由)でもSDEが可能になるのにあわせて、名称が Device Enrollment Program に変わります。

同時に、「配備」という観点で、アプリ一括購入機能の VPP (Volume Purchase Program) もひとくくりにしてしまって、 Appleは ADP(Apple Deployment Programs) という名称を使うようになりました。(参考 : VPP・アプリ一括購入とは何か)

(Device Enrollment と Volume Purchase の制度という体でひとくくりにされているのが分かる)

エンタープライズ向けのデバイスとアプリの特別な仕組みを「配備プログラム郡(Deployment Programs)」としてまとめたかったAppleの意図を感じることができます。

ABM(Apple Business Manager) の登場

DEPとVPPをADPとして提供していたAppleは、2018年末にADPの後継として Apple Business Manager (ABM) の提供を開始します。(2018年4月には米国企業向けにベータ版は提供開始していた。詳しくはABMとは何かを参照)

ADP(Apple Deployment Programs)のDEP(Device Enrollment Program)を使用していた企業には、ABMにアップグレードを促しはじめます。

(2021年8月現在でもADPでググってたどり着く公式ページはアップグレード誘導ページ)

このアップグレードには、

• DEPとVPPがADPで統合されたように見せかけて実は管理画面のUX/UIは統一されていなかった
• 端末やアプリだけでなくAppleIDの管理も求められるようになってきた

といった事情から、Programのかき集め(Programs)ではなく、Appleが提供する業務用リソースを一括管理できる統合環境という建て付けが必要だった背景があると思われます。

また別の側面もあります。

2015年、Appleは開発者向けプログラムである iOS Developer Program にiOS以外も統合して名称を Apple Developer Program に変えました(参考 : iDEPではなくADEP)。これによって、Apple Deployment Programs (ADP) と Apple Developer Program (ADP) という2つのADPが存在することになってしまいます。

Development(開発)とDeployment(配備)の両方に関わっていた弊社のようなベンダーは大いに困惑したものです。この略称の競合を解消するため、Apple Deployment Programs の名称や位置づけを変えたいという意図もあったでしょう。

ADE(Automated Device Enrollment)

2018年のABMの登場後、AppleはDEPという用語を使うことを避けているようにも見えます。後継である筈のABM内ですら使われていませんし、Appleの公式ドキュメントでも見なくなりました。

そうこうしてるうちに、2020年のWWDCの What’s new in managing Apple devices というセッションで初めて、Automated Device Enrollment (ADE) という新しい用語が現れました。

(WWDC2020のセッション資料)

セッションで解説される内容はDEPそのものでしたので、WWDC2020以降は各MDMベンダーが Automated Device Enrollment という言葉を積極的に使うようになります。Appleの公式ドキュメントでも見られるようになりました。

Automated Device Enrollment は、元々の名称 Streamline Device Enrollment に一旦原点回帰して、より分かり易くした表現とも言えるでしょう。自動で(Automated)、デバイスを(Device)、登録する(Enrollment)ための機能ですから。

ただ筆者感覚ですが、2021年8月現在、ADE という言い方はまだそれほど広がっていないように思います。MDMベンダーが無理して使っている感じでしょうか。DEP端末とかDEP化とかDEPを前提とした表現が既に浸透してしまっていますから、ADEという表現が広がりきるのは結構時間がかかりそう…という見立てをしています。何だか iDEP が ADEP へと名称を変えても多くの人が iDEP と言い続けていたのと似ていますね。

ということで、本稿では端末登録をめぐるキーワード変遷の歴史を見てきました。一連のキーワードを簡潔に数式のように書くとこうなります。

• SDE = DEP = ADE
• ADP = VPP + DEP (だった)
• ABM = ADE + 一括購入 + Managed Apple ID

太字部分が端末登録関係でおさえておいたほうが良いキーワードとなります。当サイトでは、ADEではなくまだDEPという表現をあえて使ってますが、ADEという言葉が浸透するまでこのままでいこうと思っています。

なお、DEPについては以下のような投稿もあります。併せてご覧下さい。

• DEP(Device Enrollment Program)とは何か
• MDMとDEPの組み合わせで設定アシスタントをカスタマイズする
• iOS端末をMDM管理下から外せないようにする方法
• MDM管理下から外れられないようにしたDEP端末を端末側で無理やり初期化したらどうなるか

このiOSDC2021に、昨年同様、本サイトのメインライター @oishi も登壇させて頂くことになりました。Day1 9/18(土) の14:10 から20分のセッションで、内容はもちろんエンタープライズ分野です。

今回は、MDMと連携してiOSアプリの初期設定を自動で行うManaged App Configurationという技術について紹介する予定です。実は、前回iOSDC2020のトークで話しきれなかったことをお伝えする続編的な内容だったりします。

本記事では Managed App Configuration についてお話したい理由を書いてみます。

業務用端末のdeploymentを真に自動化する最後のパーツ

前回iOSDC2020のトークでは、エンタープライズiOSの全体像を描かせて貰いました。(参考:キーワード多すぎ！なエンタープライズiOSの世界を概観する – 2020年版)

(developmentからdeployment/deistribution までの繋がりを紹介した)

詳細は録画配信に譲りますが、一連の仕組みを組み合わせると電源ONで端末設定とアプリ配信まで全自動で完了させられるのだ…というところまでがiOSDC2020でのトーク内容でした。

が、これだけでは実は片手落ちです。

セッションを視聴して頂いた方も気付かれていたかも知れません。「全自動とはいえ、それぞれのアプリの設定は必要でしょ？」と。そう、たとえOSレベルの設定やアプリインストールが自動でも、各アプリの設定、例えば

• 接続先サーバのURLやポート番号
• 企業や組織を識別するコード
• 特別な機能を有効化するシリアル番号

といったアプリ固有の設定値はアプリ内で個別に入力しなければならないんですね。1000台あれば、従業員1000人の皆が皆、同じ設定値を入力することになります。これでは全自動とはとても言えません。なんだ、結局1000台それぞれでアプリの初期設定をしなくちゃならんのか…。これではやはり片手落ちと言わざるを得ないでしょう。

そこを片手落ちにしない技術が Managed App Configuration。MDMからアプリと一緒にアプリ固有の設定値も配布する技術なのです。

例えば、接続先サーバを最初に入力する必要があるAppStore配信の業務用アプリがあるとしましょう。こんな感じのものです。

(よくある業務用アプリの設定画面。サービスとして顧客企業ごとに用意する接続先サーバの入力を求める)

赤枠部分はクライアント企業ごとに用意するサーバ名。お客様であるA社の配布端末が100台だろうが1000台だろうが全部同じ値をアプリとしては要求します。なので、仮に100台あれば、端末配布後に全員に入力させる(100人で1回ずつ)か、配布前に集中入力する(1人で100回)わけです。時間の無駄もさることながらミスも起こりますね、サポートも大変です。そして、できれば(パスワードはともかく)ユーザ名などの他の項目も自動で入力しておきたいわけです。どの従業員にどの端末を配布するかはMDMで管理できているのですから。

一部の業務アプリでは、QRコードをスキャンさせて入力支援する機能を備えていますが、それも端末の数だけ同じ手間を強いるという意味では一緒です。真の自動化とは言えず、片手落ちです。

ここでもし、A社の従業員が使う場合には赤枠欄が自動的に a-server.example.com に、別のお客様であるB社の従業員が使う場合には自動的に b-server.example.com に繋がるようになっていれば便利だと思いませんか？全く同じバイナリで、AB両社の従業員には何も入力して貰わずにです。起動した直後にもう値が入ってる。これができればアプリ初期設定の手間は軽減できるはずです。

Managed App Configuration はこれを可能にします。

ちょっと不思議ですよね、同じバイナリなのにアプリの配布先企業によってアプリの設定や振る舞いを変えることができるのですから。応用すれば端末毎のアプリ初期設定や振る舞いを変えることすら可能です。上図でいうと、ユーザ名の項目を端末ごとに異なる自動入力済み状態にできるということですね。

このように、Managed App Configuration を活用した時に受けられる恩恵はとても大きいのですが、Appleによる公式情報がほとんど無いことが原因で仕組みそのものが余り知られていません。今回のトークではその仕組みだけでなく、アプリ側の実装方法、具体的なMDMの設定方法、応用例など網羅的にお話したいと思います。

以上、iOSDC2021のトークセッションについてのご紹介でした。

アプリ開発エンジニアの方だけでなく、業務用アプリを提案して普段開発は外注するって立ち位置のSIerやコンサル企業、またはエンドユーザ企業の方々にも是非お聞き頂きたいなと思っています。アプリの可能性がグッと広がりますから。

有償イベントにはなりますが、よろしければ是非こちらよりお申し込みください。イベント全体では、スポンサーセッションやLTを含めると100近いセッションが用意されています。どれも興味深いものばかりで一聴に値するものばかりです。是非タイムテーブルもご覧下さい。

• (A) MDM
• (B) iOS端末
• (C) Apple Configurator2

初期化は管理部門が使うにはとても便利ですが、従業員が故意に、または誤って端末を初期化してしまうと困ります。

上記の(A),(C)は従業員による勝手な初期化を避けられますが((A)はそもそもMDMを触らせない。(C)は指定Mac以外との接続を禁止)、iOS端末を従業員が自由に触れる場合に(B)による初期化を阻むことはできるのでしょうか。

(デフォルトでは設定アプリを開き、[一般]→[リセット]の画面から誰でも初期化ができてしまう)

ということで、本稿ではiOS端末からの初期化を禁止する方法を紹介します。

iOS端末からの初期化を禁止する方法

iOS端末の操作で初期化するには、設定アプリを立ち上げて [一般]→[リセット]→[すべてのコンテンツと設定を消去] をタップするのでした。

 → 

これを禁止するため、そのものズバリの構成プロファイルの項目が用意されています。(参考→ 構成プロファイルとは)

(Apple Configurator2 で該当のチェックを外して保存したプロファイルを端末に流し込む)

項目名を見ると分かる通り、監視モードでなければこの設定は有効になりません。監視モードについてはこちらの記事を参考にして下さい。端末を監視モードにした上で、この項目をOFF(許可をしない、つまり禁止する)にした構成プロファイルを流し込むとリセット画面が以下のようになります。

(リセットするための項目がなくなっている)

違いが分かるでしょうか。「すべてのコンテンツと設定と消去」の項目がなくなっていますね。これで従業員がiOS端末を初期化することができなくなったというわけです。改めて整理すると、

• 監視モードにする
• “すべてのコンテンツと設定を消去”許可をOFFにした構成プロファイルを流し込む

この2つが、iOS端末からの初期化操作を禁止する方法となります。構成プロファイルの流し込み方は、MDMを使う手法やAppleConfigurator2を使う手法など、運用に最適な方法を選ぶと良いでしょう。

iOS端末からの初期化を禁止するときの留意点

ここであえて、iOS端末からの初期化を禁止する是非について言及しておきたいと思います。

何ごとも禁止すると業務上の運用は楽になりトラブルも起きにくいものですが、ことiOS端末からの初期化については、企業ごと案件ごとに是非が分かれますので慎重に検討して下さい。初期化の手順と初期化後のオペレーションマニュアルを用意して、従業員にやって貰ったほうが良いケースもあるからです。

(this photo by Clay Banks from Unsplash)

特に、商業施設での設置型端末や、各支社の受付・打ち合わせルームに常設するiOS端末がそうです。現地判断で当事者が初期化を行えたほうがいい場合もあります。

また、DEP端末の場合は、iOS端末から初期化すると再度自動チェックインと自動設定が行われることも覚えておくと良いでしょう。DEP+MDMを前提に現地従業員にiOS端末から初期化して貰う運用のほうが楽になることもあります。

以上、端末を初期化させない方法について解説しました。

本エントリでは、業務用に配布・配備しているiOS端末を初期化する3つの方法について解説します。

• MDMを使って遠隔で初期化
• iOS端末単体で初期化
• Apple Configurator 2 を使って初期化

それでは順に見ていきましょう。

MDMを使って遠隔で初期化

MDM管理下にある端末では通常この方法を使用します。

どんなMDMサービスでも、管理対象デバイスを遠隔で工場出荷時に戻すワイプ機能が備わっています。操作方法はMDMサービス毎に異なっていますので各マニュアルを参照して下さい。以下では弊社がよく使う BizMobile Go! での実行例を紹介します。

(1) デバイスの詳細画面を表示し、コマンドボタンのメニューから [ワイプ] をクリックします

(2) ワイプコマンドを受け取ったiOS端末は自らを工場出荷時にリセットします

(遠隔で複数同時に行えるので一番楽な初期化方法)

ワイプしたあとの端末は当然MDMから遠隔操作も監視もできなくなります。端末が常にMDM管理下でなければならない場合、再度手動チェックインを行うか、DEP端末の設定を行って自動チェックインさせる必要があります。(参考 → DEPとは何か)

iOS端末単体で初期化

iOS端末を直接触れるなら、これが最も簡単な方法です。

管理部門でないユーザにも容易に操作して貰い易いという特徴があります。また、MDMやiOS端末の設定状況によっては、初期設定までの労力を最小化できる場合もあります。

(1) 設定アプリを開き [一般]→[リセット]→[すべてのコンテンツと設定を消去] をタップ

 → 

(2) [iPhoneを消去]をクリック

(AppleIDの設定をしているiOS端末では、さらにパスワード入力が求められる)

このあとiOSは自ら工場出荷時に戻り、出荷直後の状態で再起動してきてくれます。iOS端末がMDMに手動チェックインがされていた場合、MDMとの接続は失われ、制御・監視ができなくなりますので注意しましょう。

別の見方をすると、手動チェックインされた端末は、iOS端末側の操作でMDM支配下から逃れられるということです。端末がMDM支配下に常に入っている必要がある場合は、この方法で初期化した後に手動チェックインするまでを忘れずに行う必要があります。が、DEP端末の場合はこの限りではありません。再度自動チェックインし自動で然るべき初期状態に戻ります。(参考 → DEPとは何か)

AppleConfigurator2を使って初期化

iOS端末が手元にあって複数台同時に初期化したい時に便利です。必要なものは以下となります。

• Mac本体
• Apple Configurator2
• USBケーブル
• USBハブ (必要なら)

以下に順を追って説明します。

(1) Macと端末を接続し、Apple Configurator 2 を起動します

(USB接続されている端末が一覧される。USBハブ等の相性により最大10台程度しか認識されないこともある)

(2) 初期化する端末を選択し、メニューから [アクション]→[復元] をクリックします。一覧から右クリックでもokです。

(3) ダイアログで確認されますので [復元] をクリックします

初期化終了後はiOS端末が工場出荷時状態で再起動してきます。上述のiOS端末単体で初期化と同様に、MDMからは管理不能な状態となりますので注意して下さい。

なおこの方法は、iOS端末側が監視モードでMacとのペアリング制限がかかっている場合や、iOS端末がDEP端末であってDEPプロファイルでペアリングが禁止されている場合は使用できません。

以上3種類の初期化方法を紹介しました。表にまとめると以下のようになります。

実のところ、これら以外にMac上のターミナルを使った初期化方法もあるのですが、余りに特殊な用途なので割愛しました。別の投稿で機会があればまた紹介しようと思います。