ABMがMDM機能を内蔵し、その他諸々の機能も取り込んで Apple Business として爆誕！という公式リリースです。

遂に来てしまったかーというのが初見の感想。本稿では、AppleとMDMの歴史を振り返り、Apple Business の登場が意味することやアプリ開発への影響という論点で見解を書いてみたいと思います。

MDMはずっとサードベンダーの領域だった

お客様向けのセミナーや講演でもよく見て頂く図なのですが、MDMを中心とする端末管理は、上図の通りMDM単体だけでは成り立たず、

• PUSH通知インフラであるAPNs (通知が命令伝達トリガになる)
• 高度な管理をしたり、アプリの一括購入に必要なABM
• 自社独自の非公開アプリのカスタムアプリにはADP

というように、現場の要件に合わせて複数のサービスを組み合わせて使う必要がありました。ABMやADP(ADEP)については本サイトでも色々とご紹介してきました。

• ABM(Apple Business Manager)とは何か
• ADEP (Apple Developer Enterprise Program) とは何か
• 業務用アプリの配布方法 全7種類一覧
• iOSDC Japan 2023 でカスタムApp移行について講演します

要件に合わせて組み合わせて使う…と書きましたが、実は大量端末の展開にかかる労力や、各種の強力な設定・制限を考えると、ABM+MDMの組み合わせはどんな現場でも基本MUSTとなり、端末管理と言えば結局以下3パターンに分類されるのが実情です。

• (A) MDM+ABMをセットで使って端末管理する
• (B) Apple Configurator で端末管理する
• (C) 端末管理しない(していない)

このうち(A)と(C)が圧倒的に大多数を占めます。大手企業や意識の高い中小企業は(A)、数十台や数台といった規模感は(C)、ちょっと変わったところで(B)、でしょうか。

MDMは便利だし運用も圧倒的に楽になるので、MDM業界やAppleは(A)を推し進めてきましたし、弊社のようなMDMの販売パートナーも(A)を推奨してきました。

ここで重要なポイントは、MDMはサードベンダーの領域だったということ。AppleはMDMプロトコルを規定するのみで、それに準拠したMDMサービスをMDMベンダーが開発して法人に提供するという構図が基本でした。

(MDM業界を表す図。仕様準拠なので横並びになり易く差別化が難しい)

端末管理や業務用アプリはサードパーティのMDMを中心として、その周辺に位置づくAppleのサービス(APNsやABM、ADP)との連携で提供されてきたのです。Apple、Apple、他社、Apple…みたいな座組でした。

Apple純正MDMという2つの例外があった

MDMは基本はサードベンダーですが、実はApple純正MDMが例外的に2つ存在しています(いました)。

• macOS Server
• Apple Business Essential

の2つです。

前者の macOS Server は、macOS (古くはOSX) で動作するサーバプログラム群ともいうべきmacOS 用の有償アプリケーション(¥2,000)。

(今はもう購入できない。購入済みのユーザはmacOS Monterey以前でなら使用継続できる)

WebサーバやDNSサーバ、コンテンツキャッシュサーバなどサーバ機能が色々含まれていて、ある時、その中に「プロファイルマネージャ」というMDMサービス(サーバ)機能が追加されました。オンプレ版のMDMサーバをAppleが提供してきたわけですね。

ただこのプロファイルマネージャは、数十台程度の規模感にしか耐えられず、評判があまり良くありませんでした。2022年には、macOS Server アプリそのものの廃止に伴い、プロファイルマネージャーも廃止となります。こうして、Apple純正MDMという最初の例外は幕を閉じました。

その代替という位置付けだったのか、あるいは今回の Apple Business への布石だったのか、macOS Server 終了前の 2021年11月に Apple Business Essential がベータ版で発表されました。これが2つ目の例外。

今度はオンプレではなくクラウド版です。

当時、既に登場して2年が経ち浸透していたABMの一機能として、MDMの機能が内包されたことになりました。MDM業界では少し話題になったものです。とはいえ機能は限定的であり、500名程度規模の想定で、対象は米国企業のみ、そして有償であるという点が特徴でした。

(今の円安状況を考えるとちょっと高額な部類になる)

ベータ版から正式版に移行したのが2022年。VPP(アプリ一括購入)のようにすぐさま世界展開になるのかと思いきや、そうはなりませんでした。が、当面米国のみとなりそう…と油断していた(?)ところに、今回2026年3月のリリースが突然あったというわけです。

Apple純正MDMが標準となる未来

今回のリリースからわかるのは、Apple純正のMDMが標準となる可能性が非常に高いということです。

ABMは、米国限定だった Apple Business Essential のMDM機能を取り込んで、Apple Business という総合ポータルとして昇華することになります。

MDM機能は強化され、日本を含む世界展開となり、500人規模の想定もなくなり、さらに(ここが一番大きいですが)無償で提供される見込みです。

(公式ページにも無償で提供するとあるがどこまでの範囲かは明記がない…が、多分無償)

また端末管理以外にも、Apple Business Connect と呼ばれる法人用ブランディング機能も包含するようになります。Apple Map でのブランディング(Google Business Profile みたいなもの)や、Appleメールのブランディング(BIMIみたいなもの)や、ApplePayのブランディング等が含まれます。

なんと、Apple Business を通してドメインの取得までできるっていうんですから、もう全部入りですよね。Appleさん、ドメインレジストラになるの？と、さすがにこれには驚きました。

とはいえ、管理対象Appleアカウントで自社ドメインを使う場合にドメイン設定(DNSのTXTレコード)が必要になったりするので確かに関係あるか…と納得するところでもあるのですが。

• ABMで管理対象AppleIDを作成する際にドメイン認証が必要な理由
• ABMで管理対象AppleIDを作成する際に必要なドメイン認証の手順

上記の記事で紹介したような作業も省略できるようになるのでしょう。Apple Business で発行されるドメインを、Appleがわざわざ改めて認証する必要がなくなるわけですからね。その他、いわゆるMDM関連の初期設定作業も大幅に簡略化されるに違いありません。

(公式サイトから。文字通り All in one place)

Apple Business は、iOS端末(やMac等も含む)を業務に使う・使おうとする法人向け機能が全て収まる総合ポータルとなるのです。そしてそこに、MDMが無償でついてくると。Apple Business は、iOS端末管理の文脈で語られるMDMをコモディティ化する存在になります。

実際には4月のリリースを迎えてみないと分かりませんが、リリース資料を見る限り、やはり基本的なMDM機能は一式揃うように見受けられ、今後MDMベンダーは厳しい戦いを強いられるような気がします。

サードベンダーのMDMを使う理由は、

• (a) Apple製品以外の端末管理もできる
• (b) MDMプロトコルに存在しない独自機能・アプリがある
• (c) In-House や AdHoc など .ipa を配布できる

ぐらいになってしまいそうなんですよね。iOS18の時代に、MDMを簡単に移行できる仕様が追加されたのですが、MDMによる端末管理はもう Apple Business で全て吸収するよ〜って布石だったと言えるのかも知れません。

あ、ちなみにABMがビジネス用だとすると、教育用として提供されているASM(Apple School Manager)ってのがありますが、そちらの言及は今回のリリースにはありません。なので、ASMは話が違うかも知れませんし、ほぼABM=ASMなので時間の問題という気もします。いずれにしても本サイトはエンタープライズが基本なのでASMは扱いません。

業務用アプリ開発に影響が及ぶ可能性

Apple Business のリリースを見る限り、業務用アプリの開発に関する具体的な記述はありません。ので、直接的な影響はなさそうです。依然として企業ごとの業務用アプリは、カスタムアプリとして申請するという従来通りの開発から変わることは無いはずです。

ただ、Apple Business のリリースにより、MDM導入のハードルが下がることの意味は意識しておいても良いかも知れません。MDMが無償になると、エンドユーザ企業がカスタムアプリを扱いやすくなるんですよね。

カスタムアプリの視点で見ると、従来のABMとMDMはそれぞれ、

• ABM : カスタムアプリの取得窓口 (無償)
• MDM : カスタムアプリの配信インフラ (有償)

という役割を担っていました。カスタムアプリをちゃんと使おうとすると、開発サイドは当然ながらADP、そして配信サイドは ABM + MDM の両方が必須だったわけです。

MDMは欠かせないのですね。

でもそのMDMが有償なうえに非Appleだったのですから、Appleとしても「カスタムアプリにしなさい！」とは強く出れない側面はあったでしょう。まぁ普通にそうですよね、どんなビジネスでも「ウチのものを使ってね。一部は他社で有償のモノを買ってもらわなくちゃだけど」とは強く言えませんから。

でも今後は、自社独自の業務アプリを作るなら開発サイドはADP、配信サイドはApple Business で完結します。All Apple な、業務用アプリ企業版エコシステムが完成するのですよね。かかる費用はADPだけの年1万円強。

そして、忘れてならないのは、なんと(?) Apple Business に取り込まれる Apple Business Essential は、MDMでありながらIn-House アプリ(.ipaファイル)の配布機構を持っていないということ。おそらくこれは Apple Business に取り込まれても一緒でしょう。これが何を意味するのか。

深読みし過ぎかも知れませんが、今回のリリースを開発視点で読み解くと「もう .ipa ファイルでの配布はやめてよね。インフラは全部整えたからさ」というAppleからのメッセージに読めなくはないなぁ…と感じるのです。

さすがにADEPの終焉が即座に訪れるとは思いませんが、Apple Business が本当にMDMを無償化し .ipa ファイル配布にも対応しないのなら、ADEP終焉を推し進める一要素にはなりそうです。

ということで、以上、長々と Apple Business が誕生するまでの経緯と、今回のリリースを受けた見解を記してみました。業務用アプリ開発に影響が及ぶ可能性についても少しだけ書いてみた次第です。

Apple Business は間違いなくiOS端末の管理体制を変えるでしょう。4/14以降、実際に Apple Business を触ってみて色々とまた発信ができればと思います。

本稿では、管理対象AppleIDに使うドメインを新たに追加登録するところから手順を解説したいと思います。では順に見てみましょう。

• 準備
• ABMでのドメイン登録
• ABMでのドメイン認証

準備

スムーズに作業を進めるためにまずは準備が必要です。準備といっても、確認するだけなのですけどね。以下3点が事前に確認しておくべきことです。

• (1) 管理対象AppleIDに使おうとする自社ドメイン
• (2) 当該ドメインの設定を行うDNSレコード管理画面アカウントの情報
• (3) ABMを操作するためのアカウント(役割は管理者・ユーザマネージャのいずれか)

(1)は、自社が真に保有しているドメインでなければなりません。当然ですね。ここで「なぜ？」と疑問が湧く方は前回の投稿を読んで下さい。

(2)は、ドメインを取得した先(ドメインレジストラと言います)から提供されている管理画面にログインする情報です。お名前.com、Value Domain、さくらのドメイン、Xserver Domain など色々ありますが管理画面に入ることさえできれば特に違いはありません。

(ドメインの設定を管理する画面例。DNSの設定をあえて分かりにくくしている悪質業者もあるので注意が必要)

もしドメインレジストラとネームサーバが異なっている場合は、(DNSレコードを設定する)ネームサーバ側管理画面のアカウント情報が必要になります。たとえば value domain でドメインは取っているがネームサーバは AWS Route53 だ…みたいなケースですね。こうした場合は、社内でドメインを管理している部門に確認しておきましょう。

また、ドメインの設定を他社に委託している場合は少し面倒なことになりがちですので注意する必要があります。ドメイン認証がなぜ必要なのか、何を設定するのか、そうしたことを委託先に理解して貰えない場合があるからです。

特に、創業期に自社サイトを作るにあたりWeb制作会社に丸投げしてドメインはそれっきり…みたいなパターンではスムーズに進まない可能性があります。残念ながらWeb制作会社はドメインを正しく理解できていない場合が少なくなく、TXTレコードを設定した経験がないとか、よく分からないドメイン設定は怖くて責任が持てない…ってなことになりがちです。理解不足が原因で間違った設定をする可能性もあります。

そういうわけで、ドメイン設定や管理を委託している場合は前回の投稿や本稿のURLを事前に共有しておくと良いでしょう。

(3)のABMアカウントについては、その役割に注意して下さい。「管理者」「ユーザマネージャ」のどちらかでなければなりません。

(ユーザマネージャのアカウントを安易に作ると自由にドメイン認証をされてしまうということでもある)

役割が「デバイス登録マネージャ」「コンテンツマネージャ」「職員」のABMアカウント(管理対象AppleID)の場合、そもそもドメイン関係の作業ができません。

ABMでのドメイン登録

では、まずドメインを登録する手順です。既にドメインを登録済みで認証のみやりたいという場合は次のセクションに進んでください。

(1) ABMで、[環境設定]→[管理対象AppleID]の画面を開き、[ドメインを追加] をクリックします 。

(2) ドメイン名の入力が求められますので入力します。国内企業でしたら xxxxx.jp とか xxxxx.co.jp とかだと思いますが、自社が保有するドメインなら.comや.bizなど何でもokです。以下では弊社が別用途で使っているドメイン feedtailor.biz を指定しました。

(3) ドメイン一覧に現れます。

ですが、見ての通りまだ Apple に認証されていない状態ですので、管理対象AppleIDのドメインとしては使用できません。次にドメイン認証に進みます。

ABMでのドメイン認証

管理対象AppleIDのドメインとして使用するには、そのドメインが確かに自社保有のものであることを Apple に示す必要があります。前回の投稿で解説した通りですね。

以下に手順を紹介します。

(1) ドメイン一覧で [認証を受ける] をクリックします。

(2) 合言葉が表示されました。文字列からしてもう apple によるドメイン認証の合言葉だということが分かります。これはドメインごとに値が異なります。

(合言葉をマスクしていないのは意図的なもの。なぜ隠す必要がないのか分かるでしょうか？)

(3) この合言葉をコピーします。右端のアイコンをクリックするとクリップボードにコピーされます。

次にドメインの設定ですが、読者自身ができるのであればベストです。次の手順(4)に進んでください。もし設定できる立場でないなら、このページをドメインの担当者に知らせ「14日以内に○○○のドメインのTXTレコードに設定して下さい」 と依頼し、本手順(4)から進めるよう言い添えて下さい。期限があることにも要注意です。担当者から設定完了の知らせを受けたら (7) に進みます。

(4) DNSレコードの設定変更画面を開きます。ドメイン取得先の業者やネームサーバによって違いますが、ここでは AWS Route53 を例に解説します。AWS Route53 では、AWS console から Route53 を選び、ホスト一覧から対象ドメインをクリックすると以下の画面が表示されます。

(5) 既存にTXTレコードがありませんので新たに作成すべく [Create record] をクリックします。ここで (3) の合言葉を入力します(赤枠)。DNSレコードの種類はTXT、[Record Name] は空に、TTL はデフォルトのままとして、 [Create records] をクリックします。

(ドメインそのものに対するTXTレコードを追加するので Record Name は空欄で良い)

(6) 設定一覧に増えていれば成功です。以上でTXTレコードの設定は完了しました。(もし読者がドメイン管理受託をしている業者なら完了した旨をお客様に伝えてください。なお本作業の無償支援はできませんのでお問い合わせはご遠慮願います。DNSの基礎から勉強しましょう)

(7) ドメインの設定が完了したところで、次は Apple に確認して貰います。ABM をサインアウトしている場合は、ABMの (2) のダイアログを改めて表示して [認証を受ける] ボタンをクリックします。TXTレコードに合言葉が正しく設定されていれば、以下のように [確認済み] と表示されます。

(管理対象AppleIDが「なし」なのは当然。今後追加していくと数がカウントされる)

(8) ドメイン一覧に戻るとグリーンのチェックボックスがついている筈です。

これでようやく管理対象AppleIDのドメイン部分として使えるようになりました。ABMのユーザ登録画面でリストボックスのドメインが増えていることを確認して下さい。

(無事に選択できるようになった)

以上、ABMでのドメイン認証について解説しました。管理対象AppleIDとして使えるドメインを増やすことは余りありませんので、手順が分からなくなりがちですね。参考として頂けたら幸いです。

このドメイン部分は選択式になっています。上図だと3択。さて、このドメイン一覧の候補はどのように決まるのでしょうか。任意に増やすことはできるのでしょうか？

答えは「ドメイン認証されたドメインだけが候補として列挙され、(ある程度)任意に増やすことができる」です。自由にドメインを指定できるわけではなく、ドメイン認証という手順を経たドメインに限られます。

本稿ではこのドメイン認証が必要な理由について解説します。仕組みや原理を理解した上で作業することが推奨なので独立した解説投稿としています。が、手順だけ知りたい方は後続の投稿を参照して下さい。

順に見ていきましょう。

• なぜドメイン認証が必要なのか
• ドメイン認証のからくり
• Appleがドメインの設定を確認？どうやって？

なぜドメイン認証が必要なのか

ドメイン認証とは、管理対象AppleIDに使うドメインがその企業に所有されているかを確認する儀式みたいなものです。

ABMは企業単位に契約するものでした。…ということは、ABMで作成する管理対象AppleIDは、自ずからその企業が管理するものになります。仮に弊社がABMで hoge@feedtailor.jp を作るなら、それは弊社管理の管理対象AppleIDとなるわけです。当たり前のことですね。

アットマーク右側のドメイン表記部分が企業を表してますが、

(管理対象AppleIDのドメイン名部分はリストボックスから選ぶ)

ここが仮に任意のドメイン名を自由に記述できたらどうでしょう。普通はやらないでしょうが、勝手に他社を名乗るような管理対象AppleIDを作れてしまうことになりますね。これはちょっと違和感があります。

読者がもし自社のABMで管理対象AppleIDを作る時に、弊社のドメインである feedtailor.jp を勝手に指定できるのはおかしいわけです。逆も然りで、読者の所属する会社のドメインを、弊社が勝手に管理対象AppleIDのドメイン部分に使えるとしたら「それはやめてくれ」となる筈です。

こうした行為を禁止するため、ドメイン認証が必要になります。自社で認証をクリアしたドメインだけが管理対象AppleIDのドメイン部分として使えるというわけです。自社が所有するドメインであることをAppleに宣言し、それを認めてもらう行為とも言えます。

ドメイン認証のからくり

では、あるドメインが自社所有であることを、第三者に詐称されることなく、どのようにAppleに証明しましょうか。「ドメイン保有証明書」のような書面をドメイン業者の印鑑付きで発行して貰って、 Apple に送りましょうか？

もちろん…そんなことは不要です。実はドメインの仕組みを使えば、簡単にその所有者であることを証明することができます。理屈はこう。

1. ドメインは企業が所有している筈のものである
2. ならば、そのドメインの設定は当該企業にしか行えない筈である
3. Appleは当該企業向けに特別な合言葉を用意する
4. 企業はその合言葉をドメインに設定する
5. Appleはその合言葉を設定できたかどうかドメインの設定を調べる
6. 合言葉が設定されていれば、そのドメインが当該企業の所有であると断定する

図にするとこんな感じです。

企業の関係者しか触れない筈のものを触らせてみて、実際に触れていることが明らかなら企業の所有物だと判断するわけですね。

Appleがドメインの設定確認？どうやって？

先述の手順5.にある「Appleは(中略)ドメインの設定を調べる」が気になったでしょうか？Appleがどうやってウチのドメインの設定値を調べられるのだろう？管理画面のログイン情報を伝えるのか？と。

実は、ドメインの設定は所有者にしかできない一方で、設定値の確認は誰にでもできます。ABMを操作する管理部門担当者の方には馴染みがないと思いますが、ドメインを調べる無償のツールやサービスは多々あります。

以下は弊社の feedtailor.jp ドメインのTXTレコードを調べた様子。TXTレコードとは、ドメイン所有者が任意の文字列を設定できるフィールドです。

(ドメインさえ分かればその設定は誰もが自由に閲覧可能。上図は Linux の dig コマンドを使っている様子)

例えるなら、法務局で誰でも取得できる登記簿謄本(履歴時効全部証明書)のようなものと言えます。分かる人なら誰でも企業情報をある程度入手できますよね。ドメインも一緒です。見ようと思えば誰でも見れるのです。

「所有企業だけにしか触れない、でもAppleはいつでも確認できる」

その要件にピッタリ合うのがドメインの設定だというわけですね。中でもTXTレコードと呼ばれる設定領域は、自由なテキストを設定できる領域です。ここが大変都合がいいのですよね。

(AWS Route53 から。TXTレコード以外にAやMX,CNAMEなど色々と種類がある。ドメイン認証ではTXTを使う)

ちなみにこのドメイン認証。ABMでのみ使われる特別な方法というわけではなく、インターネットの世界でドメイン所有を確認する一般的な方法です。例えば、httpsに必要なサーバ証明書を取得する時に利用されることもあります。

以上、ABMで必要となるドメイン認証が必要な理由、そしてドメイン認証のからくりについて解説しました。原理ができたところで、次回はABMでのドメイン認証の具体的手順を紹介したいと思います。

ただ管理対象AppleID削除にあたっては、下手すると取り返しのつかないことになるケースもあったりします。本稿で幾つか注意点を紹介したいと思います。順に見てみましょう。

• 役割が管理者だと削除できない
• TestFlightが使えなくなる
• Apple Push Certificates Portal は初期状態に戻る

役割が管理者だと削除できない

管理対象AppleIDには役割があります。何ができるかを定める項目ですね。

(ADP/ADEPのユーザに対する「役割」とは全く別物)

この役割が「管理者」になっている管理対象AppleIDは削除ができません。正確に書くと、役割が管理者の管理対象AppleIDは無効化できないので削除ができません。どうしても削除したいなら、先に役割を変更する必要があります。

(3人同時に無効化しようとして、3人のうち1人の役割が管理者でエラーが出た様子)

「管理者」以外の役割にすると無効化できます。そしてその後に削除が可能です。

ですが、管理者が1人しかいない…という状態にならないように注意して下さい。万が一、たった1人の管理者がサインインできなくなると、アプリライセンスが購入できない、自動チェックイン端末の管理操作ができない、なんて致命的なことになりうるからです。(ABMの設定状況にもよります)

TestFlightが使えなくなる

管理対象AppleIDは、TestFlight内部テストのテスターとして使うことができます。管理対象AppleIDは個人に帰属しないためチームで共有するテスト用端末でTestFlightを使う場合にはとても便利です。

(TestFlightの設定画面。ADPでアプリを開発・配信する場合は必ずお世話になる)

ですが、共用している管理対象AppleIDを削除すると、TestFlightに以下のような影響がありますので注意が必要です。

• TestFlightで新しいビルドを受け取ることができなくなる
• TestFlightでフィードバックを送ることができなくなる

管理対象AppleIDを削除した直後、端末上では再びサインインを求められます。

キャンセルしてTestFlightアプリを起動しようとしてもやはりサインインを求められるか、下図のように未設定の初期状態に戻されます。

(TestFlightがAppleIDと強力に紐づいていることが分かる)

iOSもTestFlightも常にAppleIDの有効性を確認しているというわけです。無効化→削除とした管理対象AppleIDが使い続けられる筈もありません。

ただ、配信済みのテスト用バージョンのアプリは起動することができます。が、それも最大90日の期限まで。いずれ起動できなくなってしまいますから、テストは継続できなくなります。

以上のような影響がありますので、削除しようとする管理対象AppldIDがTestFlightで使う目的で作られたものかどうか事前に確認するようにしましょう。

Apple Push Certificates Portal は初期状態に戻る

以前にApple Push Certificates Portal で使うべき AppleID のガイドラインという投稿をしました。会社として共用の扱いになるので管理対象AppleIDを使うのが良いですよ…という内容です。

さて、その管理対象AppleIDを削除するとどうなるでしょうか。

当然と言えば当然ですが、MDM用のPush通知証明書を次年度更新できなくなります。期限が来るとMDMが機能しなくなり、復旧には全端末をチェックインし直す必要がありますから企業によっては大障害です。

ですので、Apple Push Certificates Portal で使用した管理対象AppleIDは絶対に削除してはいけません。管理対象AppleIDを削除するには至らず無効化しただけなら、再有効化すれば問題ありません。

(再有効化してサインインすれば以前に作成したものがそのまま見れる)

ですが、管理対象AppleIDを削除してしまうと、そのAppleIDで取得したMDM用Push通知証明書の情報が完全に失われます。同じ管理対象AppleIDをABMから作成し直しても手遅れです。

(全く同じ管理対象AppleIDを作り直しても復活はせず新規作成となる。以前の情報は完全に消失し、更新はできない)

まぁこれは、管理対象AppleIDではなく、普通のAppleIDで Apple Push Certificates Portal を使っていても同様なのですが。

以上、管理対象AppleIDを削除する場合に注意しておきたいことの紹介でした。削除する時は念の為に確認するようにして下さい。

(ABMの管理対象AppleIDは、管理しているからこそのオペレーションができる)

一方、AppleIDサイトやADP/ADEPからの招待で登録したAppleIDは、管理部門が勝手に無効化したり削除することができません。完全に個人に任せる形になり、例えば削除は専用サイトからAppleID登録者それぞれがやる必要があります。無効化はそもそもその概念が存在しません。

(専用サイトから本人に削除して貰う必要がある)

そうしたこともあって、管理対象AppleIDは管理上のメリットが大きいというわけです。メリットや登録方法はこちらの投稿で紹介しましたが、大量の従業員用に管理対象AppleIDを登録するのは困難が伴うことにも言及しました。

本稿では、管理対象AppleIDをABMから手動登録した場合のアカウント削除について解説します。

管理対象AppleIDを削除する手順

早速、手順を見てみましょう。実は管理対象AppleIDはいきなり削除ができません。まず「無効化」という作業を行う必要があります。

(1) ABMにサインインして [ユーザ] 一覧から削除したい対象のユーザをクリックします。

(2) 画面上部のユーザ管理メニューから […] をクリックしてメニューを出します。いきなり削除はできないようになっていますので、まず [アカウントを無効化] クリックします。

(有効な管理対象AppleiDは一発削除ができない)

(3) 確認ダイアログが表示されますので、問題なければ [無効化] をクリックします。

(4) 次に同じユーザの詳細表示から同じく […] をクリックします。今度は [削除] をクリックします。(3)で間違って無効化してしまった場合は再度有効化もできます。

(5) 確認ダイアログが表示されます。取り消しはできませんので間違いないことを確認して [削除] をクリックします。

(6) 削除が無事に完了すると以下の表示となります。

以上で削除作業は完了です。それほど難しくはありませんね。

管理対象AppleIDはいきなりは消せないこと、まずは無効化する必要があることを覚えておきましょう。これは ABM ユーザの削除は致命的なことに繋がる可能性があるからだと思います。

ちなみに無効化のまま放置しておくと一定期間で勝手に削除されます。

無効化という状態があるのは管理対象AppleIDの特徴ですが、永続的なものではないことに注意して下さい。

管理対象AppleIDの複数一括削除

1人ずつ削除するのが面倒な場合は、複数まとめて削除することもできます。ABM上のユーザ一覧画面では、複数選択して同時に処理することができるのですね。

( [shift] キーや [control] キー(Macの場合は [command] キー)を押しながら複数選択できる)

ここで「アカウントステータスの変更」という項目の [変更] ボタンをクリックするとダイアログが表示されます。ここでまず「無効化」を選びます。

削除も選べますが、前述の1人ずつ削除する手順と一緒でいきなりの削除はできません。複数の管理対象AppleIDに対する操作でもまず最初は無効化からです。

(いきなり3人同時削除をしようとして怒られている様子)

対象のAppleIDが全て無効化の状態で削除を行うと、下図のように成功の表示となります。

以上、ABMで手動作成した管理対象AppleIDの削除方法を紹介しました。無効化したり削除した管理対象AppleIDは、当然ながら即時で使えなくなります。

(無効化されたAppleIDでサインインできなくなった様子)

管理対象AppleIDの無効化や削除は余り無いオペレーションだと思いますが、何かの参考になれば幸いです。削除する際の注意点が幾つかあったりするのですが、これはまた別の投稿で紹介しようと思います。

またABMで Federation Authentication を使っている場合、紐づけているID管理ソリューションで削除すると反映されることになりますので少し勝手は違います。これも本稿主旨からは外れるので省略します。

• AppleIDサイトから登録
• ADP/ADEPから招待して登録
• ABMで登録

上の2つまでを紹介してきました。本稿では最後となる3つ目のABMで登録する方法を解説します。ABMは、カスタムAppに関係する方には馴染みのあるものですね。ABMの詳細についてはABMとは何かの投稿をご覧頂くとして、本稿ではABMを使って特別なAppleIDを作成する手順紹介に力点を置きます。

順に見てみましょう。以下目次です。

• ABMからの登録が有用なケース
• ABMで管理対象AppleIDを作る手順
• 管理対象AppleIDをAppleIDとして使う
• 個人に紐づくAppleIDとしての管理対象AppleID

ABMからの登録が有用なケース

iOS端末管理や業務用のiOSアプリ開発に関わっていると、従業員個人に帰属しないAppleIDが欲しくなることがあります。チームや組織内で共用で使うようなAppleIDですね。例えば、

• 共用テスト用端末でTestFlightを使うためのAppleIDとして
• MDMのPush通知証明書を作るためのAppleIDとして

のようなことです。また、個人に帰属させるAppleIDだとしても管理部門側でコントロールしたいと考える企業もあるかも知れません。何かあったらすぐ無効化できる権限を管理側で持っておきたい…みたいな。

このような少し特殊な要件にピッタリはまることがあるのがABMで作成するAppleIDです。AppleIDといえば、それを使う個人が作るしかないと思いがちですが、ABMを使えば企業管理下における特別な AppleID を作ることができます。これを 管理対象AppleID(Managed AppleID) と呼びます。

(ABMの公式マニュアルにも組織が所有して管理するAppleIDとある)

まさに読んで字の如し。ABMは、企業が自由にAppleIDを作れるツールとしても機能するというわけですね。管理対象AppleIDが興味深いのは、

• ABMのユーザアカウントである
• AppleIDである

という2つの顔を持っているところ。

通常は前者の用途で使っているケースが多い印象です。ABMで作ったユーザは、AppStoreアプリの法人ライセンス管理や、

(研修資料より。ABMはAppStoreとMDMの繋ぎ役)

MDMに自動チェックインする端末(ADE/DEP端末)の管理

(研修資料より。ABMはデバイス調達先とMDMの繋ぎ役)

などが主な用途で、そうした管理用のユーザとして管理対象AppleIDを使います。が、管理対象AppleIDは、前述の通りABMのユーザアカウントであると同時にAppleIDでもあるのです。

ABMを触らせることが目的ではなく、単にAppleIDとして使いたいって目的だけで管理対象AppleIDを作っても別に構いません。そうした権限設定(役割)が指定できるようにもなっています。うまく使うと有用なので、本稿では主に「個人に帰属しない管理下におきたいAppleID」を作る手段として手順紹介したいと思います。

ABMで管理対象AppleIDを作る手順

大前提として、ABMを使える法人でなければなりません。個人の方はそもそも本稿で紹介する方法は使えませんので要注意です。ウチは法人だけどABMって何？という企業はこちらの投稿を確認頂いた上で、先に利用申請を済ませて下さい。

また、AppleIDサイトからの登録方法を解説した投稿の準備するものと注意点というセクションも確認しておくことをお勧めします。登録作業がスムーズに進む筈です。

以下はABMが使える前提での手順となります。

(1) まずABMにサインインします。

(2) [ユーザ] のメニューから [+] ボタンをクリックすると、追加用UIが表示されますので各欄を入力します。AppleIDサイトで普通に登録する時と入力項目が全く違うのが分かりますね。

入力する際は下表を参考にして下さい。

なお、既に AppleID として登録済みのメールアドレスと一致する管理対象AppleIDの指定は受け付けられませんので注意して下さい。以下のようなエラーが表示されます。

(3) [保存] をクリックすると登録が完了して以下のような表示になります。が、まだ有効ではありませんので上にある [サインイン情報を作成] をクリックします。

(4) ダイアログが現れますので、どちらか選んで [続ける] をクリックします。

どちらを選んでも構いませんが、この選択が何のためのものか解説します。

AppleIDサイトやADP/ADEPを使ったAppleID登録と違い、ABMからの管理対象AppleID登録では登録時の電話番号/メール認証を行いません。

まず仮パスワードが発行され、初ログインの時にパスワードの再設定と電話番号を使った2要素認証を求められる…という流れになります。

上図でやっているのは、その仮パスワードをどの形式で伝えるのかを決めること。ただ、本稿で作ろうとしているのは「個人に帰属させない管理側で管理するAppleID」でした。作るのも使うのも管理側。だからどちらでもよく、都合の良いほうを選べばokというわけです。

手間が省けて楽なのはデフォルトで選択されている「ダウンロード可能なPDFおよびCSVを作成」です。続けて見ていきましょう。

(5) (4) で[続ける] をクリックすると少し待たされた後、準備完了となり、作成した管理対象AppleIDと一時パスワードが表示されます。

(6) [ダウンロード] ボタンをクリックすると以下のような画面が表示されます。

どれでもokです。好みのものを選択して [ダウンロード] をクリックします。PDFなら以下のようなPDFが、

CSVなら以下のようなファイルがダウンロードできます。

ちなみに (4) で [メールで送信] を選んでいると、新規のユーザ登録時に「メールアドレス」に指定したメールアドレスに以下のようなメールが届きます。

(登録時に「管理対象AppleID」に指定したメールアドレスではないことに注意)

(7) 以上で作成と準備が終わりました。このまま使うこともできますが90日後に無効になってしまいますので、作りたての管理対象AppleIDでサインインしておきます。一度サインアウトしてサインインするか、別のブラウザを使いましょう。

(8) 作りたての管理対象AppleIDは、サインイン直後に電話番号の入力を求められます。2要素認証の設定ですね。電話番号を入力し、SMSか音声通話かを選び [次に進む] をクリックします。

(9) SMSか音声通話で確認番号が届きます。次の画面でそのまま入力します。

(10) 以下のような画面になります。最初はドキッとしますが、そもそも初回ですし期限切れも何もありませんので気にする必要はないです。

(ABMでは管理対象AppleIDのパスワードを強制リセットする機能があり、そのUIを流用している)

(11) 無事にパスワードが設定されました。

(12) プライバシーに関する案内が表示されますので確認して [次に進む] をクリックします。

(13) 次に進むとまさかののエラー画面。驚きますね。

でもこれは正解です。(2) で「職員」という役割を指定した筈ですね。ABMには複数の「役割」があり「職員」を指定した場合、ABMのユーザとして使えない(つまりABM上で何も管理できない)単なるAppleIDとして管理対象AppleIDを使うことになります。

よって上記の画面になっても狼狽えずただただブラウザを閉じるだけでok。無事に完了ということになります。作業手順の最後がエラー画面を確認して完了という気持ち悪い動線ですが、気になるようなら作成時のABMユーザでサインインし直して [ユーザ] の一覧から状態を確認すると良いでしょう。

正しく完了していれば上図の「新規」のアイコンが消えている筈です。

管理対象AppleIDをAppleIDとして使う

無事に作成できた AppleID ですが、通常のAppleIDと等価ではありません。上述の通り作り方も違いましたし企業によって「管理」されている訳ですから扱いも違います。

その違いは、iOS端末の設定アプリから管理対象AppleIDでサインインすれば一目瞭然。設定アプリ内のAppleID詳細画面が以下のようになります。

(管理されているAppleIDであることがよく分かる)

ユーザ体験の中で一番大きな違いは App Store が使えないということです。いぁ、正確に表現すると、App Store は見れるけどアプリを入手できないという状態になります。

(App Store アプリを起動してアプリの詳細画面を見た様子。[入手] がグレーアウトしていてタップできない)

「管理」されているAppleIDなのですから当然といえば当然ですね。勝手に AppStore からアプリをインストールされたら困ります。このようにiOS端末側を管理対象AppleIDでサインインさせて使わせるような場合、アプリはABMで一括購入し、MDMかApple Configuratorを介して配布する必要があります。

そのほか管理対象AppleIDでは制約が多くありますので、公式ページを確認しておいても良いと思います。

• 管理対象Apple IDでのサービスへのアクセス

ただ、本稿では以下のような「個人に帰属させずに管理したいAppleIDを作成する」のが主旨でした。

• 共用テスト用端末でTestFlightを使うためのAppleIDとして
• MDMのPush通知証明書を作るためのAppleIDとして

この目的なら管理対象AppleIDの制限も余り関係ありません。有用ですので気にせず使いましょう。

なお前者のTestFlight利用は、公式マニュアルで使用不可とあり、また各種サイト等でも不可である記載が見られます。が、実は昔からそして2024年時点でも可能だったりします。これはまた別途ご紹介しようと思います。

(App Store Connect 関係は公式の記述が間違っていたり、振る舞いにバグがあったりすることが意外にある)

後者のMDM用Push通知証明書で必要なAppleIDについては過去に紹介していますので参照して下さい。

個人に紐づくAppleIDとしての管理対象AppleID

管理対象AppleIDは個人に紐づく AppleID として作ることもできます。というか、どちらかというとそれが主です。

なので、業務用iOSアプリの開発や配布の文脈で、関係者のAppleIDは管理対象AppleIDにしたい！管理側でまとめてもう作っておきたい！となりますよね。気持ちはわかります。過去に紹介したAppleID サイトで取って貰う方法やADP/ADEPに招待する時に同時に取らせる方法より、完全に管理できますから都合が良いのです。

がしかし、残念ながら管理対象AppleIDをまとめて一括登録するハードルは高いです。一筋縄ではいきません。できても良さそうなCSVアップロードでの登録はできない上に、Federation Authenticationという方法を採用する必要があるんですね。Google Workspace 等々と連携させて、勝手に管理対象AppleIDが作られるような連携ができるというものです。

(Federationの設定をしようとしている様子)

ただiOSアプリ開発や端末管理の文脈ではメリットが少ないので、余りお勧めはできないかな…というのが正直なところ。本旨を外れるので詳細はまた別の投稿に譲りますが、

• 共有iPad (Shared iPad) を使いたい
• iCloudやSIWA(Sign in With AppleID)に対応した公開/非公開アプリを使いたい

といった個人に紐づく管理対象AppleIDを必要とする要件があり、かつ、ABM上で手動作成するのが現実的ではない場合に限られるでしょう。SSO(Single Sign On)の導入企業などでID管理を統合したい欲求は分からなくもないのですが…。AppleIDは影響範囲が広すぎるため、まぁまぁ結構な茨の道を覚悟する必要があります。

以上、だいぶ長くなりましたがABMを使ったAppleID作成について紹介しました。iOSアプリ開発や端末管理の文脈ではほぼほぼ使うことは無いと思います。が、個人に帰属しないAppleIDが必要になった時に選択肢の一つとして検討してみて下さい。

両サイトにはユーザという概念があり、適切な人を適切な権限で招待するために「役割」を正しく理解する必要があるということを以前に書きました。

• ADPのユーザに割り当てる役割の基礎(前編)
• ADPのユーザに割り当てる役割の基礎(後編)

本稿では、ユーザのメールアドレスと姓名について、知っておくと良いプチ情報を幾つか紹介します。

App Store Connect は余り親切な設計になっていませんので、本稿で紹介することをあらかじめ知っていると、いざという時に詰まることが避けられるかも知れません。目次は以下の通り。

• 姓名にアンダースコアは使えない
• UIが変更されることがある
• メールアドレスに + を使えない
• メールアドレスには Managed AppleID も指定できる

では順番にみてみましょう。

姓名にアンダースコアは使えない

App Store Connect にユーザ招待する場合、ユーザの名前を「姓」「名」に分けて入力する欄があります。その両方の入力欄で、アンダースコアが使えません。

部門名等の属性情報も一緒入れておきたい…ってな時に遭遇しがちな問題です。上図の通りエラー文言で教えてくれますが、実は正確ではありません。スペースが利用できます。姓名情報に何か属性情報的なものを付加したい場合は、ピリオド・ハイフン・スペースを使うと良いでしょう。

UIが変更されることがある

App Store Connect の UI は時々ひっそりと通知もなく変更されます。ユーザを招待するUIも例外ではありません。

以下画像は、2024年2月時点の新規ユーザ招待画面です。冒頭にも同じ画面を載せました。実はこの画面が何度も変更されています。

以下は、同じ画面の2023年10月時点のキャプチャです。違いが分かるでしょうか。

メールアドレス入力欄の幅が違っていて、最下部のアプリ項目の有無(次の画面に移っただけ)も相違点です。加えて驚くべきは、一番上の「姓」「名」欄の順番が入れ替わっていることです。さすがに普通はやらない変更ですよね

ブラウザの言語設定によるものでもないため理由は謎ですが、このように App Store Connect ではUIが変更になることが時折あることは知っておくと良いでしょう。(Appleは過去にユーザの「役割」設定の UI を変更し、致命的なバグを発生させていたこともありますので油断できません)

メールアドレスに + を使えない

Google の Gmail を常用している方にはお馴染みの機能です。これが使えません。

ご存知ない方のために説明すると、一部のメールサービスではアドレスのアットマーク(@)の自分の名前の後に + と任意文字列を追加して擬似的にメールアドレスを量産できる仕組みがあります。Plus Addressing と呼ばれるもので、Gmail や Exchange Online が当該機能を備えています。

例えば、bob@example.com のメールアドレスを持つボブさんが、メールマガジン受信用メールアドレスとして bob+mailmagazine@example.com を勝手に作ることができます。当該メールアドレス宛のメールは全て bob@example.com の受信箱に届きます。

これを Plus Addressing (Sub Addressing と呼ぶこともある) と言い、App Store Connect でユーザ招待する際に使いたくなる場合があります。App Store Connect 用のメールアドレスだ、という意味で bob+appstoreconnect@example.com ってな感じで登録したくなるわけですね。

が、下図の通りエラーとなります。

(無効であるとしか表示されない不親切なエラー。パッと見で原因が分からず混乱する)

過去にはokだったのですが、2024年現在、App Store Connect に招待しようとするユーザのメールアドレスに Plus Addressing なメールアドレスは指定できません。

どうしても App Store Connect 用の意味づけを与えたメールアドレスで既存のアドレスと同じ受信箱に届くようにしたい場合は、エイリアスかメール転送を使いましょう。業務用途のメールサービスでは、いずれも管理部門での設定が必要になる場合が多いですので担当部門に相談して下さい。

メールアドレスには Managed AppleID も指定できる

ABM(Apple Business Manager)には、Managed AppleID と呼ばれる特別な AppleID が存在します。従業員用の AppleID を企業が自由に作成できる機能です。

(ABMで特別な AppleID を作成する様子。任意数作成可能。ABMについてはこちら)

活用されている例は多くはありませんが、実は ABM 上で作成した Managed AppleID を App Store Connect のユーザとして招待できます。

従業員が自身の会社用メールアドレスを appleid.apple.com で AppleID として登録済みの場合は役に立ちませんが、App Store Connect に招待するためだけの AppleID を新たに用意したい場合には活用できます。(チーム共用の AppManager 権限ユーザを作って招待したい…等)

なお Managed AppleID でサインインした端末は AppStore アプリのインストールができないため、TestFlight でのカスタムAppテスト目的で上記を行う場合は少し工夫が必要です。また改めて別投稿で紹介します。

以上、App Store Connect でユーザを作成する時にあらかじめ知っておくと良い豆知識を紹介しました。App Store Connect でのユーザ管理の際に役立てて頂ければと思います。

• ADPのユーザに割り当てる役割の基礎(前編)

ユーザに割り当てる「役割」には結構クセがあって設定には注意を要するのでした。前編に続く本稿では「役割」に関するさらに細かな権限周りの仕様を解説します。

• Apple Developer へのアクセス権を得られる役割
• Apple Developer へのアクセス権を付与できる役割
• アプリのアクセス権と役割
• アプリごとに役割を変えることはできない
• ABMのユーザや役割はADPに関係ない

順に見ていきましょう。

Apple Developer へのアクセス権を得られる役割

証明書やProvisioning Profile等、アプリの開発フェーズで必要なものを作成するのが Apple Developer サイトです。

前編の権限を細かくコントロールできないで解説した通りですが、この Apple Developer サイトを触って貰うには ADP のユーザを招待する時に「その他のリソース」の権限を付与する必要があります。

このチェックをONにしていないと、当該のユーザに Apple Developer サイトを操作してもらうことができません。そのユーザが開発会社の実装担当者なら Xcode でまともにデバッグできないという事態にも陥りますから、然るべきユーザに漏れなく付与しなければなりません。

権限付与に際し注意を要するのは、この Apple Developer へのアクセス権はどんなユーザに対してでも付与できるものではないという点です。アクセス権を得られる「役割」は限定されているのですね。

この表から分かるように結構限られています。Marketing の「役割」を指定したユーザに Apple Developer へのアクセス権を付与する…といったことはできません。また、Admin を割り当てるということは Apple Developer サイトへのアクセス権も無条件に与える点にも留意が必要です。

Apple Developer へのアクセス権を付与することは、証明書やID、Provisioning Profile など大事なデータやファイルの操作に繋がります。誰に、またどの「役割」の人に付与するか慎重に検討しましょう。

Apple Developer へのアクセス権を付与できる役割

Apple Developer へのアクセス権を誰が持てるか、とあわせて誰が付与ができるかについても知っておくと良いでしょう。権限を付与するという行為を誰もができるわけでなく一定の制限があるのですね。ルール策定時に意外にハマるポイントです。

今、App Manager を割り当てられた「役割」のユーザがいるとします。そのユーザが Apple Developer へのアクセス権つきで新たな Developer のユーザを招待したい場合、App Manager である自分自身が Apple Developer へのアクセス権を持っている必要があります。

(研修資料より。自分が持っていない権限を他人に割り当てられないのは権限管理の基本)

自身が与えられていない権限は、自分が招待するユーザに付与できません。セキュリティの観点からも当然と言えば当然でしょう。Apple Developer へのアクセス権限を持っている人だけが、それを付与できます。つまり、

• Account Holder
• Admin
• 自身がアクセス権を持っている App Manager

の「役割」のユーザだけに可能です。これらに該当しないなら、Apple Developer へのアクセス権を誰かに付与するというオペレーションはできませんので注意して下さい。Developer や Marketing の「役割」のユーザが、別の誰かに Apple Developer へのアクセス権を付与することはできません。

Apple Developer へのアクセス権をどう与えるか、どう与えさせるかは、アプリ開発体制のあり方を大きく変えます。この扱いをおろそかにすると深刻なトラブルにも繋がりかねません。たとえば、委託先の開発会社の操作ミスが別アプリの開発をストップさせてしまうとか、開発会社側の誰かが悪意を持って機密情報を漏洩させることも可能になってしまう…等です。

自社のポリシーにあった適切な設定を熟慮することが求められます。

アプリのアクセス権と役割

ADPのユーザを招待するとき、そのユーザにどのアプリを見せるのかを決めることができます。これをアプリのアクセス権と呼びます。あるユーザにとって自身にアクセス権のないアプリは存在していないことになります。

(招待しようとするユーザにアクセス権を与えるアプリを絞り込んでいる様子。チェックが入っているアプリだけを見せる)

アプリのアクセス権も「役割」と微妙に関係しており、以下のような違いがあります。

数ある「役割」のうち Admin と Finace はアプリのアクセス権について特別な扱いを受けることに留意しましょう。もし委託先の開発会社に付与すると、委託していないアプリ以外も全部見えることになリます。

アプリごとに役割を変えることはできない

ADPのユーザは一者二役ができません。「役割」によって得られる権限が、そのユーザがアクセスできる全アプリに適用されます。

具体的な例で示します。あるエンドユーザ企業が、複数の業務用アプリを同じ開発会社の異なるチームに委託しているようなケース。大手企業なら普通にありますね。

開発会社Xに、アプリAとアプリBを委託しているとします。Aの開発責任者はaさん(下図の青色)、Bの開発責任者は別部門のbさん(下図の緑色)とします。そして、bさんはアプリAのテストを手伝っているとしましょう。

さて、エンドユーザ企業はADPのユーザとして開発会社を招待するとき、リーダー相当の人を AppManager に、それ以外の関係者は Developer にすると定めているとします(実は現実的でないルール)。その場合、下表のような「役割」の割り当てをイメージする筈です。

アプリごとに「役割」を変えたくなるというわけですね。bさんはアプリAに参画するけどリーダーではないから Developer の権限までにしておきたい…という考えです。分からなくはありません。

ですが、残念ながらこの設定はできません。ユーザに割り当てられた「役割」は、そのユーザにアクセス権が与えられた全アプリに及びます。よってこの例では、アプリAへのアクセス権も付与されたbさんは、アプリA「も」 App Manager として操作できることになります。

「役割」とアプリはマトリックスを形成しないのです。「役割」はユーザに紐付き、ユーザにアクセス権が設定されたアプリは全てその「役割」が持つ権限で操作できます。

前述の「Admin はアプリのアクセス権の絞り込みができない」と併せて考えると、Admin のユーザとして委託先の開発会社を招待することの重大さが分かると思います。Admin を付与したが最後、その開発会社のユーザに現存する＆今後開発する全てのアプリを Admin としての操作を許すことになるからです。

ABMのユーザや役割はADPに関係ない

ABM(Apple Business Manager)は、App Store アプリを法人として一括購入する窓口です。実は ABMにもユーザと「役割」という概念が存在しています。(ABMについてはこちらの投稿を参照)

同じ言葉が使われていますが、ABMとADPのそれぞれのユーザ・役割は全く関係がありません。間違え易いので注意しましょう。実際に、こんな質問をあるエンドユーザ企業から頂いたことがあります。

「開発会社の担当者をADPに招待したところ、ABMにもアクセスできるようにして欲しいと言われました。どうしたらいいですか？」

これは色んな意味で誤った理解です。

まず、ADPでABMのアクセス権を制御できるわけではありません。そしてABMはエンドユーザ企業が直接触るべきものであり、一アプリを開発委託したに過ぎない担当者に触らせてはならないものです。ABMの利用規約にも明記されています。

(ABM契約書。ABMの管理画面からいつでも参照できる)

ABMのユーザは、管理対象AppleIDという特別なAppleIDで作られるもので、正規ユーザーにしか割り当ててはいけないことになっています。正規ユーザーとは原則 ABM 利用企業の従業員を指しており、アプリを委託する開発会社にアカウント発行すべきではありません。(ただ、エンドユーザ企業の端末管理やAppleID管理を含め全オペレーションを委託されているグループ子会社といった立場であればこの限りではありません。詳しくはABMの契約書の「1.定義」の「正規ユーザー」と「サービスプロバイダ」を参照)

ADPのユーザと役割はABMのユーザと役割とは全く別物です。ABMは触る人が限られているため全容を正しく理解している人が少なく、誤解し易いので注意して下さい。

以上、ADPの「役割」について前編と後編の2本立てで解説してきました。しかし正直なところ、「役割」はややこしいということをお示ししたに過ぎません。

悩ましいことにADPの「役割」は、自社内に開発部門があってアプリを内製する企業を前提にしているきらいがありますので、日本企業にあった「これ」というパターンはありません。

弊社より、業務委託が常という場合のベーシックな権限設計モデルをご提案することはありますが、基本的には公式の権限テーブルのページを読み解いて各社なりのADPユーザ招待ポリシーを定めることが大切です。

そんな無償解決したお問い合わせストックの中から、シェアするのが有用と思われるものを紹介するケーススタディ企画を始めることにしました。具体的な課題や背景・ストーリーがあるほうがより分かり易い場合もあるからです。

記念すべき(?)第一回目は、古いInHouseアプリをカスタムApp化したいというご相談です。実際にはメールやビデオ会議で数回に分けてやりとりしていますが、本稿では、質問→回答、とシンプルな構成で書いてます。また、その後に解説も記しています。

• 質問 : 7,8年前のアプリをカスタムApp化したいのですが？
• 回答 : 作り直したほうが早いです。開発体制も再考の余地ありです
• 解説1 : 自社アプリのカスタマイズ版を他社提供する方法
• 解説2 : App Store アプリの開発経験を持った外注先を選ぶ

それでは質問からいってみましょう。

質問 : 7,8年前のアプリをカスタムApp化したいのですが？

Q. 当社はシステム開発事業を行っている上場企業です。7,8年前に、社内のある事業で作ったB2B向けの業務アプリを顧客のADEP(InHouse)を使って提供していたことがあります。アプリは諸般事情で提供をやめたのですが、ここに来て当該のアプリを復活させることになりました。

貴サイトを見て、業務用アプリはカスタムApp化が必要なことを知って取り組み始めたところです。開発には外部の開発会社を使っていますが、Xcodeでうまくビルドできないと言われてて進捗は良くありません。deprecated というエラーや警告が多発したり、SDK が見つからないと言われたりして、ipa ファイルが生成できないとのことです。どう進めていけば良いでしょうか？

回答 : 作り直したほうが早いです。開発体制も再考の余地ありです

A. deprecated や SDK が見つからない等の警告やエラーは、廃止されたAPIを使っていたり古いSDKを参照するソースコードで発生します。代替の実装を行う必要がありますが、軽微で済むものからインパクトの大きなものまで様々です。

App Store への申請が伴うアプリ開発では、deprecated となるAPI情報をチェックし、SDK も新しくして、継続的かつ計画的にiOS エコシステムの進化に追随していく必要があります。

(deprecated の例。上図はUIKit)

App Store と無関係でいられたADEP(InHouse)の場合は Xcode や iOS SDK を自社都合や顧客都合で固定できていたため、deprecated を意識することは余り無かったかも知れません。良い意味でも悪い意味でもやりたい放題だったというわけです。

7,8年もの間に蓄積したiOSアプリとしての「遅れ」を、ツギハギや小手先の調整で取り戻すのは困難な作業になると思われますし、実装の見直しが広範囲に及ぶ可能性も高いと推測します。残念ながら、御社は「カスタムApp を考える以前の状態」と言えるでしょう。

(Swiftの登場は2014年ですっかり定着。Android版の同時開発でもない限り昨今はSwiftがスタンダード)

当該アプリのソースコードは Objective-C のようですが、最新のXcodeを使ってSwift言語で今風に作り直す方針を推奨します。昨今ではそのほうが外注先開発会社の選択肢も増えます。また今後のビジネス持続性も考えて、App Store 向けアプリの経験がある開発会社を選ぶほうが良いでしょう。

既存ソースについて補足すると、全部捨てることが常に正解だとは限りません。基本的に捨てる方針としながら、一部流用できるビジネスロジックがある場合は Objective-C のまま当該部分を抜き出して再利用するのが賢明でしょう。とはいえ Swift と Objective-C を混在させるデメリットもありますので、そのあたりも含めて相談できる開発会社を探されると良いと思います。

解説1 : 自社アプリのカスタマイズ版を他社提供する方法

ここからは相談内容に関連する解説となります。さて、今回のご相談のように、

• 自社で開発したソースコードをビルドして
• 他社のADEP(InHouse)契約配下の証明書・秘密鍵・Provisioning Profileで署名する

というやり方は、自社開発の業務用iOSアプリを他社販売する時に行われてきました。しかし、ADEPが使えない(使えなくなっていくと思われる)今、今後はこの方式は使えない(使えない前提でビジネスを組み直さなければならない)と考えるべきです。

カスタムAppでは、

• 販売先企業毎にそれぞれアプリを作る
• 自社 ADP にカスタムAppとして個別に申請
• App Store Connect 上の配信設定で販売先企業の組織IDと組織名を指定
• 販売先企業にはABM+MDMの導入必須であることを説明

を行う必要があります。

(研修資料より。提供先企業がMDM+ABMを持っている前提でカスタマイズ版を他社向けABMに放り込む)

このことから分かるのは、業務用自社開発iOSアプリを他社提供するメーカ企業がADEP(InHouse)からの移行を目指す場合、メーカ企業自身にもABMとMDMの理解が必要になるということです。これらの理解なく、事業を営むのは今後難しくなっていくでしょう。該当する企業におかれは、以下を参照のうえ準備することをお勧めします。

• MDMとは何か 〜今さら聞けないMDMの基礎〜
• ABM(Apple Business Manager)とは何か

解説2 : App Store アプリの開発経験を持った外注先を選ぶ

本サイトで度々強調していることですがカスタムApp は App Store アプリです。そして App Store アプリには、ADEPの InHouse アプリと全く異なる、複雑で沢山のノウハウが求められます。

(App Store Connect は豊富な機能を備える。カスタムAppで必要なのは一部だけだが、それでも知るべきことは膨大)

ADEP では触れる事のなかった App Store Connect の基礎理解は必須であり、アプリ審査に関係するワークフローや審査結果に対するオペレーションも押さえる必要があります。テストの仕方もそもそも変わります(TestFlightを使用)し、前述の deprecated の対応も常に必要です。

ADEPとは比較にならない知識と経験が必要になるわけです。ipa ファイルを作って、審査もなく、本番・テストの区別なく自由にバラまけたInHouse配布のADEP時代とは全く違う世界だと認識しなければなりません。ADEPからEが取れた程度…と安易に考えてはいけません。

(アプリの詳細画面。たった1つのアプリでも、多くのタブと多数のメニュー、そして膨大な入力項目がある)

また、カスタムApp化で大きな課題になるのがiOS の API の進化に追随しなければならないという点です。

iOSは進化とともに古いAPIが使えなくなります。App Store アプリでは、この廃止予定のAPIを使っているとそもそも申請を受け付けてくれませんので、代替の実装に置き換えることをしばしば行います。

(iOS Release Noteから。上図は iOS16で UIKitの一部関数が廃止されることを示している)

開発者視点でiOS最新情報を確認できる iOS Release Note のページをチェックし、対応し続けられる開発体制かどうかは非常に重要です。App Store アプリの開発経験のない企業の場合、そもそもそういったことに慣れていない可能性があります。

「現場の iOS 端末で動けば良い」

この発想ではダメで、今後はアプリ審査に耐えうるクオリティの実装が必要です。では審査に耐えうるクオリティとは一体？…そうしたことに知見を持って対応できる、業務アプリの持続可能性を高める体制作りが必要になるのです。

そのために、App Store アプリの経験のある企業に発注する、または内製するなら経験者を雇うのは良い選択でしょう。それが適わないなら、最低限、その知見や経験を持った企業や個人に技術支援を依頼することをお勧めします。

今回はケーススタディ企画の第一弾ということで古いInHouseアプリをカスタムAppに移行したいというご相談への回答および関連解説をお届けました。他にも学びのある無償相談は沢山ありますので、また紹介したいと思います。

時折、聞かれる質問ですので、本稿でその是非の根拠となる情報を紹介します。最初に弊社の見解を書くと、同じ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を使う場合のライセンスの考え方については、機会あればまた改めて投稿しようと思います。