時折、聞かれる質問ですので、本稿でその是非の根拠となる情報を紹介します。最初に弊社の見解を書くと、同じAppleIDが設定された複数の業務端末がある場合、

• 同じ従業員が使うのは問題ない
• 異なる従業員が各端末を専属的に使用する場合は規約違反に近いグレーで非推奨

です。つまり、1人1台配布している複数台の業務端末に同じAppleIDを設定してアプリを使う事は推奨されない、ということですね。色々企業様毎に諸事情がありますから余り積極的に非推奨を強調して案内することはないのですが、これを一応の弊社見解としています。

以下、詳しく見ていきます。

AppStoreアプリはApple メディアサービス利用規約に従う

Appleのサイトには利用規約やライセンス契約等の契約書面を集約したポータルサイト Apple Legal があります。ご覧になったことはあるでしょうか？

(Appleの製品やサービスの契約書や規約が集約されている)

AppStoreのアプリに関する契約は、このページから [インターネットサービス] をクリックした先にあります。

App Store について規定されているのは [Appleメディアサービス] ですので、リンクをクリックします。ここでようやく規約がhtmlで表示されます。

(PDFと違って見易い。スマホでも十分に閲覧できる)

自動的に日本用のAppleメディアサービス利用規約が表示される筈ですが、もし他国のものが表示される場合は、画面上部にある「国/地域を選択して下さい」をクリックして日本を選択しましょう。

(AppStoreは世界で1つではなく国の数だけある。当然、規約も国の数だけある)

この規約を読めば、本稿の問い「複数の端末に同じAppleIDを使ってアプリをインストールしても良いのか？」が分かる筈です。InHouse・AdHoc・TestFligthのいずれでもないアプリ配布形態を採るなら、開発会社もエンドユーザ企業も目を通しておくべき文書です。

複数端末にAppleIDを設定することは問題ない

この規約の「本サービスと本コンテンツのルール」という項目に以下の記載があります。

本サービスと本コンテンツを利用するには、本セクション (以下「利用ルール」という) に明記されている規則に従う必要があります。

規則には従って下さいということですね。「本セクション」には、細かくコンテンツの種類ごとに定められた規則と、コンテンツの種類によらない共通規則とが並びます。共通規則は「全てのサービス」というサブ項目に記載されており、AppleIDについて以下のように述べています。

いかなる本サービスについても、最大 10 台までのデバイス (ただし、コンピュータは最大 5 台まで) でご自分の Apple ID で同時にサインインすることができます。

最大10台までと上限が決まっているようです。これは現実に AppleID を複数端末に設定して利用している方はご存知かも知れません。規約にも明記されているのですね。

アプリをインストールできる端末の定義

共通規則に続くのは「App Store コンテンツ」のサブ項目。実はここに、業務用途での考え方がしっかりと書いてあります。以下に全て引用します。

営利事業、政府機関、教育機関 (以下「エンタープライズ」という) を代理して業務を行う個人は、(i) エンタープライズが所有または管理する 1 台または複数のデバイスで 1 名の個人が使用する目的で、または (ii) エンタープライズが所有または管理する 1 台の共有デバイスで複数人が使用する目的で Arcade 以外の App をダウンロードし、同期できます。明確にするために記すと、複数のユーザが連続して、または集団で使用する各デバイスには、別個の使用許諾が必要です。

業務用に AppStore アプリを使う場合、インストールが許容される場合は限定されてそうです。文章中の (i)と(ii) に限られ、それらに該当しないなら規約違反と考えるのが妥当でしょう。

(i)は、「1名」という点が強調されています。1名の従業員が、会社支給端末の複数台端末で使う為にAppStoreアプリをインストールするのは問題無さそうです。これは、個人が iPhone, iPad を2台持ちしている場合に同じAppleIDを設定して使うことに相当します。

(ii)は、「1台」という点が強調されています。これは1台のデバイスにインストールされたアプリを複数人で使うような、いわゆる設置型端末のアプリのことを指していると解釈できます。飲食店でPOSレジ端末として使われるiPad等が当てはまるでしょう。

以上の2点が、業務用途で許容される App Store アプリのインストール形態となります。

では、冒頭の質問、

「複数の端末に同じAppleIDを使ってアプリをインストールしても良いのか？」

の問いに対する解はどうなるでしょうか。

同じAppleIDを使って同じ1人の人が使うなら、(i)に該当しますから問題なさそうです。(ii)は端末の共有利用時のことを書いていますから、今回の問いとは関係がありません。

よって(i)に該当しないパターンである、

• 支給した複数の業務端末に同じAppleIDを設定し
• 各端末を個別の従業員専用端末として支給しAppStoreアプリを使用させる

という使い方は、規約で許容される AppStore アプリの使い方ではないと考えることができそうです。

以上、アプリ利用に関する規約と弊社見解を紹介しました。あくまで弊社見解ですので、実際にiOS端末やアプリを業務用途に使う場合は、法務部門に確認を取った上で実運用ポリシーを定めて下さい。

なお、ABM(Apple Business Manager)とMDMを介して法人用に一括ライセンス購入(VPP)する場合は事情が異なってきます。ABMを使えば、AppleID を必要とせずにデバイスそのものに紐付ける「管理対象ライセンス」という特別なライセンスでAppStoreアプリ(非公開のカスタムAppを含む)が供与されるからですね。

(ABMでAppStore公開アプリを一括購入しようとする様子。ABMの利用規約が別途ある)

ABMを使う場合のライセンスの考え方については、機会あればまた改めて投稿しようと思います。

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

業務用アプリを配布する方法は、全て列挙すると実に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種を解説しました。詳細についてはそれぞれ対応する投稿がありますので併せてご覧下さい。

結論を先に書くと、アプリ配信の選択肢が1つ増えました。今後アプリの配信方法は以下の4つから選ぶことになります。

今回追加された非表示App(D)は、公開App(A)と非公開App((B)または(C))を足して2で割った、かゆいところに手が届く特別な配信方式です。ただ開発者が自由に設定できるものではなくAppleの審査があります。また、非公開にしたい企業向けアプリは(B)(C)のいずれか、という点は従来と何ら変わりません。

以下、詳しく見ていきましょう。

非表示Appの概要

早速公開されたAppleの日本語ドキュメントによると

以下のような記述があります。

開発中のAppが一般配信に適していない場合は、App Storeで非表示Appとしてリリースし、ダイレクトリンク経由に限定して、ユーザーに見つけてもらうことができます。非表示Appは、App Storeのカテゴリ、おすすめ、ランキング、検索結果、その他のリストのいずれにも表示されません。

非表示アプリは、AppStore上に公開されるが、URL直リンク以外ではそのアプリにたどり着けないようにしたものです。URLを知っている人だけがインストールできる状態になりますが、URLを知ってさえいれば誰でもインストールできるという点が注意事項です。

YouTubeで動画を公開するときの限定公開と同じです。検索結果や関連動画には現れませんがURLを知っている人だけが見れる動画。そのアプリ版です。非表示Appは、限定公開Appと言い換えても良いのかも知れません。

一部の業務用アプリやイベント参加者向けに提供するアプリ等で活用できるでしょう。

非表示Appにするには、特別に用意されたフォームから申請が必要になります。β版やテスト用途では使えません。既に公開されているAppStore上のアプリや、通常のAppStore公開アプリとして審査提出前状態のアプリのみが対象です。

では今後、業務用アプリは非表示Appで良い？

いいえ。

非表示Appは非公開App ではないことに注意して下さい。AppStoreで公開されるアプリにたどり着く方法を直リンクに限るだけの話です。直リンクURLが広く知られたら、AppStoreで公開するのとさほど変わらない状態になります。

Appleは公式ドキュメントで

Unlisted Appは、リンクを持っているユーザーなら誰でも利用できます。そのため、不正使用を防止するための仕組みをAppに実装することを検討してください。

と注意を促しています。そもそも存在を知られたく無いような非公開状態を期待するアプリは、やはり

• ADEPによるInHouseアプリ
• カスタムApp

のいずれかを選択することになります。前者のInHouseアプリの手段が使える企業は限られていますので、非公開状態を望む場合は、ほぼすべての企業が後者カスタムApp配信をすることになります。非公開Appの配布方法は、従来と何ら変わらないわけです。

(非公開アプリであるカスタムAppとして申請しているアプリの例)

URL漏洩や不正利用に注意すれば、業務用アプリは非表示Appでも良い？

いいえ。

非公開App のカスタムAppは、MDMやABMの導入と運用が前提で、加えてVPPの理解も必要ですからかなり複雑になります。色々新しいことを調べるよりも、今までのよく知ったAppStore向け公開アプリの開発や申請フローで進めて、最後に非表示App申請するほうが楽そうだ…と思えなくもありません。

(iOSDC2021の講演資料より)

ですが、非表示Appは開発者の意思で自由に設定できるわけではないため、そう簡単ではなさそうです。Appleに申請し、非表示App化を認めて貰わなくてはなりません。その申請フォームに気になる項目があります。

Why do you prefer to distribute this app unlisted on the App Store instead of privately to specific organizations on Apple Business Manager or Apple School Manager?

「ABMを使わずに非表示Appにしたい理由はなんですか？」と説明を求められます。ABMをなぜ使わないのか。さすがに「面倒だから」とか「ABMはよく分からないから」と書いて申請しても認めて貰えないでしょう。

またフォームの末尾には「これらを理解しています」と自己宣言するチェックボックスがあり、幾つか並ぶ項目の1つにこんなものがあります。

• Because the app will be accessible by anyone with the link, unlisted distribution is not private. If you need private app distribution, consider offering a custom appon Apple Business Manager or Apple School Manager.

非公開アプリはカスタムAppとABMの利用を検討して下さいと明記されています。ここからも、ABMやカスタムAppやMDMの検討をすっ飛ばして「とりあえず非表示Appの申請をすりゃ良いや」とはならなさそうなことが分かりますね。

その他、非表示Appの申請フォームには結構な数の回答項目があります。全て素直に回答すると「いぁそれはABMとカスタムAppでやれるでしょ」と Apple がツッコミを入れやすいよう誘導しているかのような設問で、ADEPを取らせないようにするAppleの姿勢に似たものを感じます。

では、どんなときに非表示App申請が適切になるのでしょうか。

非表示Appの審査が適切なケース

既存の配布方法ではカバーできない用途です。つまり、

• AppStoreで広く公にする必要がないアプリで、
• ABM + カスタムApp での非公開Appが適切ではない or 難しいアプリ

になるでしょう。具体的には以下のようなアプリが該当します。

• イベントやカンファレンスの参加者専用アプリ
• 雇用関係にはないが一時的に組織外の人物に使わせる業務用アプリ
• あるメーカ製品を営業するための販売代理店使用を前提とするアプリ
• 海外を含む全グループ子会社に提供する従業員専用アプリ

いずれも、限定的なユーザに使わせたいアプリで、かつ、ABM + カスタムApp の配布可能範囲の制約が障壁になるケースです。

こうした例では従来、カスタムAppをインストールした端末を貸与する形をとったり、全関係企業でABMが必要になったり、カスタムAppを引き換えコード付きで入手して配布したりしていました。非表示Appは、これらの運用が複雑になるパターンを救済する仕組みと捉えるべきです。

ですので今後、業務用アプリを新たに開発する場合は、

• STEP1 : ABM + カスタムApp での非公開のApp開発・配布を検討する
• STEP2 : カスタムApp のライセンス的に現実的でないなら非表示Appを申請する

で進めるのが順当でしょう。以下のカスタムApp関連の投稿が参考になりますので併せてご覧下さい。

• カスタムAppとは何か(1) 〜非公開アプリをリリースする唯一の方法〜
• カスタムAppとは何か(8) 〜業務用アプリを配布しても良い範囲〜

以上、2022年1月に発表された非表示App(Unlisted App)について解説しました。

(昨今はXcodeやSwiftを使いこなせるエンジニアや外注先の確保が大変)

本稿は、そんな選択肢に待ったをかける投稿です。

本稿を読めば、業務用iOSアプリ提供の選択肢がネイティブアプリ開発だけではないことが理解できるでしょう。2008年からアプリ開発を生業にしてきた弊社が書くのもおかしな話ですが、ある程度のユーザ体験(UX)を妥協できるなら、実はネイティブアプリ開発は不要にできるのです。

一体どういうことか。2回に分けて解説していきます。

Webをネイティブのように動かす

はじめにお断りしておくと、本稿で紹介するのは「Web技術でネイティブアプリを開発する」方法ではありません。

世の中には React Native や ionic や Monaca のように Javascript を使ってネイティブアプリを開発できる技術もありますが、それらの紹介は本旨ではありませんので取り上げません。Flutter や Xamarin のようなマルチプラットフォーム対応のネイティブアプリ開発フレームワークにも言及しません。

本稿で紹介するのは、あくまで既存Webシステムをネイティブアプリのように提供するテクニックです。

まずは実例を見ていただいたほうが早いので、以下動画をご覧下さい。ある企業で配布されたある業務用iPad…という想定です。HOME画面に業務で使う「アプリ」が最初からありますね。これをタップして起動してみます。

これは、Apple Business Manager (ABM) のiPadOS用ネイティブアプリ…のようなものを操作している様子です。ABMはiOSの業務活用で主に管理部門が触るWebシステムです。(ABMについてはこちら)

何となくネイティブアプリっぽく見えませんか？ABMを普段お使いの方なら「あれ？ABMってAppStore にアプリあったっけ？」と思われた方もいるかも知れません。

もちろん ABM に AppStore で公開されたネイティブアプリはありません。大事なポイントは、ネイティブアプリが存在しない既存Webシステムをネイティブアプリのように振る舞わせることができている点です。

ちなみに、Safariのブックマークをアイコン化してホーム画面に配置する方法があることをご存じの方もいるでしょう。こんなやつですね。

(Safariでは表示中のサイトブックマークをホーム画面に保存できる機能がある)

この方法でもホーム画面にアイコンを置くことができます。が、タップすると以下のような表示のされ方になります。

明らかにブラウザで開いていることが分かりますね。アドレスバーを含めてブラウザ付随の色んな機能も使えてしまいます。これらを非表示にするような html の書き方もありますが、いずれにしてもブックマーク登録作業を全従業員にやって貰うことは現実的ではありませんね。業務用のアプリは配布端末に最初からインストールされているべきです。

Webをネイティブのように動かす種明かし

既存のWebをネイティブアプリのように提供するには、2つの技術を組み合わせます。

1つ目は以下の画像の通りWebクリップです。

構成プロファイルで指定するWebクリップを「Webサイトがネイティブアプリに見える」ような設定で作成しているのですね。もちろんURLの欄はWebシステムのURLです。詳細は以下をご覧下さい。

• Webクリップの作り方と各設定値を徹底解説 [前編] -Webクリップとは何か(2)-
• Webクリップの作り方と各設定値を徹底解説 [後編] -Webクリップとは何か(3)-

2つ目の技術はMDM。ネイティブっぽく見える設定にしたWebクリップを含む構成プロファイルを、MDMから端末に配信します。そうすると配布端末は勝手に以下のようになってくれます。

(MDMなら予めWebクリップをアイコンとして表示できる。見た目上はネイティブアプリと違いは無い)

再掲しますが、これをタップすると以下のように動作するわけです。

さて、これはネイティブアプリでしょうか。それともWebでしょうか。余り詳しくない方が見れば、これを言い当てるのは難しいでしょう。

十分にスマホ/タブレット最適化されたWebを適切にWebクリップとして設定し、適切にMDMから配信した時、そのWebはネイティブアプリと区別できないのです。

このように、使っている様子を切り取ってもほぼほぼネイティブアプリですね。

(Webクリップ起動状態からタスクスイッチする様子。個別のネイティブアプリのように見える)

HOME画面上にアイコンとして表示されて、起動してもアドレスバーやツールバーがなく、画面遷移してもその状態が維持できて、インストールに特別な手間が不要で、普通に業務がこなせるなら、それはもう立派なiOS端末向けの業務アプリです。

WebクリップとMDMの知識は必要になりますが、Swift言語でプログラムを1行も書かずともXcodeを1秒も触らなくてもアプリ(と遜色ないもの)を提供できるというわけです。何だか「業務用アプリ」の可能性が広がると思いませんか？

以上、本稿ではWebクリップとMDMを使って、既存Webシステムをネイティブアプリのように提供できることを紹介しました。もちろん全てのWebシステムに適用できる考え方ではありませんし制限事項もあります。次回は、この手法を採用できる条件や制約について説明します。

(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 ベンダーに頼るのが良いでしょう。弊社にご連絡頂いても結構です。

そこで本稿では、業務用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端末を端末側で無理やり初期化したらどうなるか

前回はABMとMDMを使って社用管理端末にカスタムAppを配布する方法について書きましたが、本稿ではもう一つの配布方法である引き換えコードについて紹介します。(上図の中央の茶色線)

• 引き換えコードを使うケース
• 引き換えコードでのカスタムApp購入と配布
• カスタムAppの引き換えコード配布と留意点
• 引き換えコードでカスタムAppをインストールする

引き換えコードを使うケース

カスタムAppの配布は原則MDM連携です。ただMDM管理下にない端末にカスタムAppをインストールさせたい場合もあります。例えば以下のようなケースです。

• 社用端末はあるが都合でMDM管理できない端末がある場合
• 社用端末を用意せず個人所有のiOS端末を業務にも使って貰っている場合
• 社内報アプリのように社用端末を前提とするには大げさ過ぎるカスタムAppが対象になる場合

等々、企業や業務の都合、アプリの種類によってMDMで集中管理…とはいかない時は引き換えコードでカスタムAppを配布する必要があります。

それでは具体的に引き換えコードでカスタムAppを購入する方法と、従業員の端末にインストールして貰う方法(配布方法)について見てみましょう。

引き換えコードでのカスタムApp購入と配布

カスタムAppの申請が通過すると自社のABM画面に現れます。(申請についてはカスタムApp(CustomApp)とは何か(２) 〜ABMとの関係と申請方法について〜を参照)

目的のカスタムAppを選択して、ライセンスの種類を「引き換えコード」にします。

(MDMと連携させる管理対象ライセンスとは違い「割当先」 のような概念はない)

取得したい数を入力して [入手] をクリックします。

(1000や10000などの大きな数も指定可能。5000を超える場合はライセンス発行に時間がかかる → 参考)

多くの場合カスタムAppはその性質上0円ですが、0円以外の場合は指定数と価格を積算した金額がABMに登録したクレジットカードで決済されます。購入が完了するとカスタムAppの詳細画面の最下部に「引き換えコード」という欄が現れます。

(ダウンロードリンクは購入直後は表示されないため、5分10分程度待つと良い)

引き換えコードで購入する度に行が追加されていきます。購入ごとにダウンロードリンクが用意されますので、クリックしてExcelファイルを入手します。

Excelファイルには、引き換えコード購入に関する基本情報と、購入した個数分の12桁の英数字列が列挙されています。A列が引き換えコードです。各コードに対応するURLも一緒に提供されます。

カスタムAppの引き換えコード配布と留意点

配布する前に、引き換えコードは再利用できないことに注意しましょう。

(コード一覧のExcelファイルで使用済みのものは redeemed と表記される)

Aさんが使った引き換えコードを、Bさんが使うことはできないということです。BさんにはBさん用の引き換えコードを割り当ててあげる必要があります。もし引き換えコードが不足する場合はABMから追加購入します。

重複しないよう各従業員に引き換えコードを割り当て、どう配布するのが良いか。これは企業や業務の都合、アプリの特性によるでしょう。確実なのは手作業を避け、社内システムやプログラムと連動させることです。弊社では以下のような運用を推奨しています。

• Excelから一覧部分のみを切り出してCSV化して既存社内システムに取り込む
• 従業員ID・名前・メールアドレスなどの既存テーブルと結合して管理
• 1行単位でメール送信するか、従業員IDをキーに社内ポータルのマイページ等に掲載する

事情はそれぞれ異なるでしょうから、紐付けが管理できて重複なく配布できる仕組みをあらかじめ検討しておくことをお勧めします。

一番やってはいけないのは、Excelファイルを共有フォルダで全社共有して適当にコードを選ばせる方法です。重複問題が発生し易いですし、何よりコード一覧が関係者以外に漏洩してしまうリスクを高めます。カスタムAppはABM利用企業の従業員や業務委託者以外に配布してはいけないことに留意して下さい。

引き換えコードでカスタムAppをインストールする

従業員に配布するのは、コードでもURLでもどちらでも構いません。以下にそれぞれの使い方を紹介しますので、社内都合や事情に合わせて選んで下さい。

引き換えコードそのもの

12桁英数字の引き換えコードそのものの配布を受けたら、iOS端末上でAppStoreアプリを起動して、右上のAppleIDアカウントアイコンをタップします。

アカウントメニューが現れますので、[ギフトコードまたはコードを使う]をタップします。

カスタムAppのインストールはカメラからの読み取りには対応していませんので、[コードはキーボードでも入力できます]をタップします。

引き換えコードを入力して[完了]し、最後に[コードを使う]をタップします。

しばらくするとカスタムAppがインストールされ、HOME画面に現れます。

引き換えコードつきのURL

URLで提供を受けた場合、そのURLを mobile Safari で開くだけでカスタムAppのインストールが完了します。iOS14以上の端末でデフォルトブラウザを変更している場合は、明示的にSafariでURLを開いて下さい。

URLを開くだけで、自動的に引き換えコード入力とインストールまでが完了します。楽ですね。

(インストールされるカスタムAppのアイコンが表示される)

ただ注意しなければいけないのは、iTunes Store アプリがインストールされていなければならないという点です。iOS端末にiTunes Storeアプリがインストールされていない場合、引き換えコード用のURLを踏むと以下のようなダイアログが表示されます。

(iTunes Store アプリがない場合、復元を求められる。ユーザによっては混乱してしまうかも知れない)

これは意外に見落としがちなポイントです。iTunes Store アプリは標準で手動削除できますので、カスタムAppの引き換えコードをURL配布する場合は、iTunes Store アプリが必要なことを周知しておきましょう。

以上、カスタムAppを引き換えコードを使って配布する方法をご紹介しました。MDMを使えない企業や、MDM管理できない端末がある場合に活用を検討してみて下さい。

ただどちらを選ぶにしても、引き換えコードはライセンス配布より面倒なのは違いありません。運用を楽にしたい、ユーザのサポート対応時間を少なくしたい、と考える場合はMDM導入を検討するのが先かも知れません。

カスタムAppとは何か(２) 〜ABMとの関係と申請方法について〜 で、非公開Appの登録領域を確保するためにABMが必要であると解説しましたが、ABMはカスタムAppを配布する側でも重要な役割を担っています。

(ABMはカスタムApp登録の器を用意してくれるのと同時に配布手段も提供してくれる)

これから2回に渡って、ABMを使ったカスタムAppの購入と配布について解説します。

カスタムAppを配布するときの注意点

カスタムAppを「配布」するといっても、まずは「購入」する必要があります。(例え0円のアプリでも)まず「購入」ありきの配布になるわけですが、気をつけなければならないのは購入の方法が配布の方法を決めるという点です。

購入してから配布方法の内訳を決めるのではないため、どのように配布するかを決めた上で購入する必要があります。以下にカスタムAppの購入方法と配布方法の関係を並べました。

カスタムAppの配布先となる端末が、MDM配下の管理端末なのか、そうでないのか、きちんと把握したうえで配布計画を立てる必要があります。

カスタムAppは¥0で登録されることが大半ですので無計画でも大きな問題にはなりませんが、もしカスタムAppが有償なら購入費用を無駄にしてしまう可能性があります。(カスタムAppとは何か(3)で紹介した既存アプリのカスタマイズ版が有償カスタムAppとして提供される場合もある)

管理対象ライセンスとして一括購入する

カスタムAppの申請が審査通過してから Ready for Sale 状態になると、申請時に指定した組織IDのABM画面上に当該のカスタムAppが表示されて「購入」できるようになります。

カスタムAppの一覧から目的のアプリをクリックし、ライセンスの種類を「管理対象ライセンス」にします。右側の「割当先」には、ABMとMDMを連携していればABM利用申請時に指定した自社組織名が唯一の選択肢として表示さます。（割当先の詳細は別の記事で解説予定）

数を指定して入手をクリックします。最初に数個だけ購入して後から追加していくこともできます。

購入が無事に終われば、購入数分の使用権(つまりライセンス)を入手できたことになります。入手したライセンスの個数はカスタムAppごとに管理されており、カスタムAppの詳細画面に表示されます。

使用中0とありますが、購入直後はまだどの端末にもインストールされていませんので当然ですね。管理対象ライセンスで購入したカスタムAppを配布するには、後述のMDM側の操作が必要となります。

MDMで端末とアプリを紐付けて同期する

ABMで購入したアプリのライセンス情報は、ABMと連携しているMDMに自動的に転送されます。早ければ購入から5分後ぐらいにはMDM側でライセンス情報を確認できます。

(ABMでの購入情報は連携したMDMに自動で同期される。赤枠がカスタムApp。AppStore公開アプリのライセンスも一緒に同期される)

次にMDMの画面から、どの端末にカスタムAppを配布するのかを設定します。設定のUIはMDMサービスごとに異なりますが、端末のグループ単位でカスタムAppを紐づけて一斉配信する機能を備えているのが一般的です。

(BizMobileではテンプレートという概念を使ってカスタムAppを複数の端末に一斉配信する)

設定を保存すると、あとはMDMの仕組みでアプリが端末に配布されます。

(MDM管理下の端末が監視モードならダイアログ表示もなくサイレントインストールされる。参考 → iOSの監視モードとは何か)

もし端末数に対してカスタムAppのライセンス数が不足している場合は、MDMサービスが警告等を表示してくれますのでABMで追加購入しましょう。

以上、カスタムAppをMDM連携で配布する方法を紹介しました。

カスタムAppを社内配布する場合、基本的に本稿で紹介したMDM経由の配布が推奨されます。管理側のオペレーションだけでカスタムAppの配布作業が完結するからです。

端末をMDM管理できない事情があったり、そもそもアプリの用途がMDMで管理される端末を想定してない場合もあるでしょう。そんな時はもう一つの配布方法である引き換えコードを活用することができます。次回の投稿では、カスタムAppを引き換えコードで配布する方法について解説します。

• カスタムAppとABMの関係
• カスタムAppはどのように申請するのか
• カスタムAppのためのADPは誰が契約するのか。エンドユーザ？開発会社？

カスタムAppとABMの関係

前回のカスタムAppとは何か(１)の投稿で、カスタムAppは、AppStore内の非公開領域に登録されたアプリで、その非公開領域は企業毎に分かれていることを紹介しました。

AppStore内にある、この企業毎の非公開領域(上図のA,B,C社の領域)はどうやって作って貰うのでしょう。Appleに直接申請するのでしょうか？ADPを契約した企業なら勝手に作られるものなのでしょうか？

…答えは ABMを利用申請して受理されると作られる です。

非公開アプリを使う企業がABMを利用申請することに注意して下さい。ABMは、デバイス・アプリ・AppleID・MDMを管理する法人用ポータルサイトですが、DUNS番号を持つ企業であれば企業規模によらず利用申請ができます。(参考 : ABMとは何か)

ABMの利用申請がAppleに受理されると、自社専用のAppStore非公開領域が作られ、領域を識別する7桁の組織IDが割り当てられます。

(ABM上で組織IDを確認できる。カスタムAppでは組織IDが重要になる)

この組織IDをカスタムAppの申請先として指定します。

カスタムAppはどのように申請するのか

カスタムAppとは(１)の投稿で書いた通り、カスタムAppもAppStoreアプリなのでした。ですので、カスタムAppの申請方法はAppStore公開アプリと一点を除いて全く同じです。

(AppStore公開アプリを作成するのと同じ)

App Store Connect でアプリを新規作成し、Xcodeでビルドした ipa をアップロード、各種メタデータを登録して申請する…。手続きは全く何も変わりません。

Provisioning Profile には AppStore 用のものを使用。App Store Connect で作成した「バージョン」に対して、ビルドしたipaファイルを Xcode または Transporter を使ってアップロードするのも一緒です。

(XcodeからカスタムAppをアップロードする様子。通常のAppStore公開アプリと何も変わらない)

もちろん、TestFlight の内部テスト・外部テストも使えます。課金のTierを設定したり配信国を決めるところも一緒です。唯一公開アプリと違うのは、配信の設定のみ。[価格及び配信状況]→[Appの配信方法] の画面で非公開を選択する点だけです。

(カスタムAppを申請するとは、つまり、非公開でAppStoreに申請するということ)

非公開を選べば、もうそのアプリはカスタムAppです。画面上に新たな入力フィールドが現れますので、ここで先ほどの組織IDを使います。

(組織IDと組織名を入力する。組織名もABMで確認できる)

ここで、どの企業の非公開領域にアプリを登録申請するか指定するわけです。UIから想像がつくと思いますが複数の組織IDを指定することもできます。（同じアプリを色んな企業に非公開配布できるということ）

ここまでの内容で、カスタムApp申請時に非公開領域の組織IDが必要で、非公開領域と組織IDはエンドユーザ企業がABM利用申請して作られることが分かりました。ということは、カスタムApp申請には、アプリを使うエンドユーザ企業にまずABM申請をして貰う必要があることを意味します。

一方、申請する側のADPはどうでしょう？

カスタムAppのためのADPは誰が契約するのか。エンドユーザ？開発会社？

カスタムAppの申請にはADP(Apple Developer Program)の契約が必要です。ではそのADPは誰が契約すべきなのでしょうか？これは、案件の性質やアプリの種類によって異なります。

以下にカスタムAppのパターンを全て列挙してみました。

エンドユーザ企業が独自の業務用アプリを開発しようとすることが多いので、通常は(A)か(B)です。(C)は既存アプリのカスタマイズバージョンを個別提供する(提供して貰う)パターンです。長くなりますので (C) は別の記事で紹介します。

上の表から読み取れる通り、ADP契約はアプリの著作権・所有権を持つ企業が取得します。

エンドユーザ企業視点で書くと、自社専用アプリを新たに開発するなら内製か外注かによらずエンドユーザ自身でADPを契約しなければなりません。

開発側視点で書くと、受託開発アプリが最終的に顧客の「もの」なら、エンドユーザのADPアカウントを使う必要があります。ADPが未契約なら契約して貰い、App Mangaer の権限を貰いましょう。自社(開発会社)のADPアカウントからお客様の受託開発アプリをカスタムApp申請してはなりません。というのも、エンドユーザ側のABMでアプリの見え方に不都合が生じるからです。

(ある顧客企業に feedtailor Inc. のADPアカウントからカスタムApp申請した時の顧客側ABMの画面。feedtailor Inc. のアプリとして表示される)

ABMのカスタムAppの画面、上図の赤枠部分で、カスタムApp申請をするADPアカウントの企業名が表示されます。これが気持ち悪くなければ別に構わないのですが、発注するエンドユーザ企業の立場では普通に違和感を覚えるでしょう。自社の業務アプリなのに、ABM上では発注先企業のアプリのように表示されるのですから。

ということで、自社専用アプリを独自開発したいと考えるエンドユーザ企業は、カスタムApp申請用にADPの契約は必須です。またカスタムAppを使うために、ABMの利用申請も必要になります。

以上、カスタムAppとABMの関係、申請の方法、カスタムAppでADPを誰が契約するのか説明しました。ポイントは以下の通りです。

• AppStoreの非公開アプリ用領域はABM利用申請が受理されると作られる
• カスタムAppはAppStore公開アプリと申請方法がほぼ一緒
• AppStore申請時に「非公開」を選ぶとカスタムApp申請となる
• カスタムApp申請では組織ID・組織名を指定する

次回はさらに深掘りして、カスタムAppの特殊な使い方である、既存アプリのカスタマイズバージョンの提供について解説します。