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 を触ってみて色々とまた発信ができればと思います。

ADEPからADPへの移行(カスタムApp化)を進める企業や、新たに独自アプリを作る企業、またそうした企業を支援する関係者の方に役立てて頂けるかと思います。

自社従業員に使わせるアプリで、かつADPを前提としている点はご留意下さい。1枚ものの簡単なチャートになります。

画像貼り付けだと少し見にくいのでPDFも用意しました。以下にチャートの順に解説しますので、別ウィンドウでPDFを拡大しながら読み進めて頂くと良いと思います。

配信方法選定チャートの解説(1) : そもそも論

チャートは左上からスタートです。まず最初の判断は、

ここですね。まさかの「Webにしましょう」です。本サイトでもいくつか関連エントリを書いています。

• 業務用WebシステムのiOS用クライアントアプリ開発は本当に必要か？を考える (前編)
• 業務用WebシステムのiOS用クライアントアプリ開発は本当に必要か？を考える (後編)

弊社はiOSアプリと関わり始めて2025年6月時点で17年近く。その間、B2C/B2B/自社アプリ/受託アプリこれら全ての組み合わせを色々経験していますが「安易な自社アプリ開発はお勧めしない」が一貫したスタンスです。今も昔も業務用iOSアプリの真理だと思っています。

(10年以上前のセミナー資料。自社アプリを作るのは最終手段であると解説し続けてきた)

MDM/ABMを併用すれば、自社専用のアプリがなくてもWeb技術だけでiOS端末を十分に活用できます。なので、カスタムApp化を考える場合も新規アプリ開発をする場合も、まず真剣に「本当にWebではダメなのか？」を問うてみることをお勧めします。

2025年現在、業務用アプリの9割はWebで十分であるという感触を持っています。以下もご覧下さい。

• Webクリップとは何か(1) -Webサイトのブックマークを配布する-
• Webクリップの作り方と各設定値を徹底解説 [前編] -Webクリップとは何か(2)-
• Webクリップの作り方と各設定値を徹底解説 [後編] -Webクリップとは何か(3)-
• WebクリップはSafariを削除していても使用できる(ようになった) -Webクリップとは何か(4)-

配信方法選定チャートの解説(2) : PoCや実験

Webが無理なら、次はTestFlightの活用を検討して下さい。

TestFlightの最大のメリットは審査関連の面倒臭さがないことです。ユーザが100人以下ならTestFlightの内部テスト、ユーザが100人より多く10000人以下なら外部テストが使えます。外部テストには審査が必要ですが、あってないようなものですし、バージョンを変えない限り無審査というハックもあります。

TestFlightのデメリットは主に以下2つ。

• 有効期間は90日
• AppleIDが必要

ただ前者は1,2ヶ月ごとに定期的にビルドを作ればほぼ解決です。後者は、ABMを使って全社員にAppleID(Manged AppleID)の供与が容易になっているため、昔に比べてハードルは下がってます。Managed AppleID については以下をご覧下さい。

• AppleIDの新規登録方法 2024年保存版 – ABMからの登録 –

従業員が多い場合は EntraID や GoogleWorkspace との連携も活用できますので、TestFlightのAppleID要件はデメリットにならないケースもあります。

配信方法選定チャートの解説(3) : 本番稼働でも審査回避

TestFlight が適切でない場合、AdHoc 配布を検討することをお勧めします。

繰り返しますが、業務用iOSで一番面倒でかつ運用に制約を与えるのは審査関連です。それを避けるためのWebであり、TestFlight であったわけですが、それらがダメなら次は AdHoc です。

AdHoc についての詳細は以下をご覧ください。

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

Apple Developer Program に明示的に端末識別子(UDID)を登録して稼働させる方法で、端末種別ごとに上限100台以下に抑えられるなら、ADEP の InHouse に近しい運用が可能です。

先に書いたTestFightの「AppleIDが必要」という条件は満たせないが、100台以下のPoCや実験アプリである場合でも有用です。

配信方法選定チャートの解説(4) : AppStoreからの配信

チャートもここまでくると、AppStoreからの本配信しか選択肢がありません。

AppStoreからの本配信にも種類があり、最初に検討すべき配信方法は「公開アプリ」です。我々が個人利用で App Store で見かけるようなアプリと同じ位置付けとなります。社名や関連名で検索した時にアプリの存在を知られても良い場合に採用できます。

公開アプリをまずお勧めするのは、他の選択肢である非公開アプリ(カスタムApp)と非表示アプリに比べて、実績のある開発会社が多くアプリ開発から配信までスムーズに進む可能性が高いからです。

非表示アプリなら追加の特別な審査が必要だったり、非公開アプリ(カスタムApp)ならABM/MDMの知識や運用体制も必要だったりと少々面倒臭くなります。

配信方法選定チャートの解説(5) : カスタムApp or 非表示アプリ

ここまでくるということは、Web技術では実現できず、まとまった端末数で本稼働させる必要があり、世間に知られたくないアプリです。この場合、どんな端末で動作させるのか？という視点で三択になります。

ひとことでカスタムAppといっても配信の仕方には2種類あり、インストールの仕方も変わります。どのような端末に配信するかに応じてどちらかを選ぶことになります。

• カスタムApp (管理対象ライセンス)
• カスタムApp (引き換えコード)

大半の場合(国内従業員向けの非公開アプリ)は、前者です。一方で以下に該当する場合は後者です。

• 端末を会社支給せず個人端末を業務に使わせるBYODスタイル
• MDMが導入できないケース

後者の引き換えコードを選んだ場合、業務用アプリが個人AppleIDに紐づいてインストールされる(つまり退社後も使われる可能性がある)点には注意して下さい。万が一に備えて認証機構を備えたアプリでなければ採用はできないでしょう。

また、日本企業としてABMの利用申請を行った場合、海外従業員のBYOD端末に対しては、カスタムAppの引き換えコードライセンスは使用できません。必然的に非表示アプリを選択することになります。

(研修資料より。AppStoreは国ごとに分かれており、カスタムAppの配信は国単位で閉じる必要がある)

あるいは、端末管理や運用体制まで調整して「国内法人で調達した端末に管理対象ライセンスでインストールして、海外従業員に当該端末を使わせる」という逃げ道を採用することもできます。

海外従業員への非公開業務用アプリの配布は、カスタムAppやライセンスの種類、ABM/MDMの十分な理解がないと難しいので余りお勧めしません。素直にWebアプリにしましょう(笑) というのは冗談で、非表示アプリか公開アプリにしてログイン機構を設けるのがベストです。

以上、ADP前提で自社従業員が使うアプリをどう配信するかの判定チャートを解説してきました。配信方法を決定する社内ルールを作る時の参考として頂ければと思います。もし「このアプリはどの配信方法が良いんだろう？」と気になる場合、こちらよりお問い合わせ下さい。

なお、本チャートは ADEP InHouse は考慮していません。ADEPは意外にもまだ使えている企業が多く、徐々に移行を強いられている印象ですが、まだ使えるなら使い続けるのが最善です。カスタムApp化を考える時に本ページのチャートを参考にして下さい。

また本チャートでは、従業員が使用するアプリを前提としました。もし「販売代理店に使って貰うアプリ」「ソリューションを販売した顧客企業の従業員が使うアプリ」のように自社従業員利用でない場合は少し異なるので注意して下さい。非従業員のケースはまた別の機会に紹介したいと思います。

(研修資料より)

カスタムAppの開発シーンでは、主に内部テストを使います。

一方で外部テストは、動作確認だけお願いしたいなぁというライトな関係者、つまり開発会社やエンドユーザ企業のアプリ担当者ではないけどテストだけは…という場合に活用できます。(一般消費者向けアプリではベータテスターを募集して使って貰う…的な用途に使用しますね)

この外部テスト、AppleIDとして登録されたメールアドレスさえあればokなため超お手軽で便利なのですが、余り知られていないちょっとした罠があります。本稿はそんな外部テストの罠について紹介します。順に見ていきましょう。

• Xcodeリリース版以外でビルドしたipaは配布できない
• 外部テストの「壁」を意識する

Xcodeリリース版以外でビルドしたipaは配布できない

開発現場によっては、毎年9月頃に発生するかも知れない現象が以下のようなものです。外部グループのテスターに向けてTestFlight配信しようとする時に表示されるエラーです。

(ADEPからカスタムAppに移行して、少し慣れてきた頃に発生するかも知れない)

自動配信をONにしていないテストグループにはアプリのTestFlightタブから明示的にTestFlight向け配信操作を行いますが、登録されているビルド(ipa)がベータ版Xcodeで生成されていた場合、配信先に外部グループを指定できません。上図のようなエラーが出てしまいます。

ipaの中にはXcodeのビルド情報が含まれているため、その情報で判断しているものと思われます。ベータ版に限らずリリース候補版(RC版)でも同じです。リリース版のXcodeでビルドされていない限り、外部テスト配布はできません。

上図のようなエラーが表示されたら、リリース版のXcodeに切り替えてビルドし直して再度アップロードしましょう。最新のXcodeを使っていこうという姿勢は基本的に推奨されるべきものですが、不特定多数(上限1万人)に配布するにはまだ気が早いということなのだと思います。

(リリース版が出るまで待つか、待てないなら前バージョンのリリース版Xcodeを使う)

外部テストの「壁」を意識する

Appleには、不特定多数に無制限にアプリを配布されたくないという強い意思があります。

App Store を原則必須としていることも、証明書やプロビジョニングプロファイル等のややこしい仕組みを強いていることも全部そのためです。自由なアプリ開発と配布を許容した為にセキュリティインシデントを多発させてきたWindowsとは対照的です。

TestFlightの外部テストは上限が10000ユーザで、受け取り手に必要なのはAppleIDだけなので、不特定多数にアプリ配布するのに結構近いと言えなくもありません。なので、悪用されないよう、外部テストには何かと制限や制約がついて回ります。本稿で紹介した制限も含めて例えば、

• 内部テストを実施していない状態で外部テストはできない
• ベータ版/RC版のXcodeでビルドしたipaファイルは配布できない
• (本審査ほど厳しくはないが)一応審査がある

等々ですね。

(外部テストの配信をする画面。「審査へ提出」とある)

小規模な業務用アプリであればTestFlight外部テストを使うこともないかも知れませんが、内部テストのように自由にはいかないことを意識しておくと良いでしょう。

以上、Xcodeベータ版/RC版を使用している時の注意事項を紹介しました。何かの参考になれば幸いです。

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

前回の投稿では1つ目を解説しました。本稿では2つ目の方法について解説します。ADPやADEPに招待するメールアドレスが明らかな関係者に、「AppleIDを先に取っておいて下さいね〜」とわざわざ言わなくてもいい方法があります。

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

• ADP/ADEPからの登録が有用なケース
• ADP/ADEPへの招待とAppleIDを同時に済ませる手順
• おまけ : ADP/ADEPの管理画面は不安定かつコロコロ変わる

ADP/ADEPからの登録が有用なケース

業務用iOSアプリの開発では、ほぼ全ての関係者があらゆるシチュエーションで AppleID を必要とします。ザッとあげると以下の通り。

エンドユーザ視点でもデベロッパー視点でもどちらでも必須です。ADPのカスタムAppなら、エンドユーザやデベロッパーだけでなく、テストに参加するだけの関係者にも必要な場合があります。(ADEPのInHouseでアプリ開発運用しているなら、テストだけの関係者にはAppleIDは不要)

AppleID を持たずして業務用iOSアプリに関係することは不可能と言っても過言じゃありません。なので、アプリ開発プロジェクトが始まると普通は以下のように進めるわけです。

1. 関係者にはまず AppleID サイトから AppleID を登録して貰う
2. その後 ADP/ADEP で招待する

ただ最近は Apple もよく考えていて、1. をすっ飛ばしてもういきなり 2. だけで良いようにしてくれています。どういうことか。

ADP/ADEPへの招待とAppleIDを同時に済ませる手順

2024年現在、ADP/ADEPに招待されたメールアドレスが AppleID として未登録な場合、招待を受け取った側で同時に AppleID 登録までできる作りになっているのです。実際の挙動を見た方が早いので、以下に画面キャプチャ付きで紹介します。

登場人物が「招待する側」と「招待される側」と2人いることに注意して読み進めて下さい。まず招待する側です。

ADP/ADEPに招待する側

主にエンドユーザ企業が該当します。

自社ADP/ADEPのユーザとして、自社従業員や開発担当の委託先関係者を招待することになりますね。その際、相手がAppleIDの登録をしてるかどうか確認することも登録依頼もすることなく、もういきなり招待してしまうのです。

(1) App Store Connect にサインインして [ユーザとアクセス] の画面に移動します。

(ADEPでは App Store Connect 画面が無いので、Apple Developer のTOPから [ユーザ] をクリック)

(2) ユーザの一覧が表示されますので、[+] ボタンをクリックします。

(ADPの場合、誰かを招待するには Account Holder / Admin / App Manager のいずれかでなければならない)

(3) ダイアログが表示されますので、招待したい人(社内の同僚や、委託先の社外の人)の姓名・メールアドレスを入力します。

(誰が誰にどの役割と設定で招待すべきか？は本稿主旨ではないので省略)

(4) アクセス権を付与したいアプリを選択します。コンプライアンスの観点から必要最低限のアプリにしておくことが推奨されます。

(新しいアプリ開発プロジェクトが始まる時、関係者の招待より先にアプリの登録が必要になる事を意味する)

以上で招待作業は完了です。入力したメールアドレスには Apple から以下のようなメールが届くことになります。

このメール中のリンク「Accept invitation」から、ADP/ADEP の招待受託だけでなく AppleID の登録まで一度に完了するというわけです。招待される側の動きを見てみましょう。

ADP/ADEPに招待される側

上でも紹介した通り招待メールが届きますので、それを開くところからですね。

(1) 受信した招待メールのリンク「Accept invitation」をクリックします。

(2) クリックすると以下のような画面に遷移します。

招待側が入力した情報に基づき、姓名やメールアドレスはあらかじめ入力されています。その他の項目を以下の表を参考にして埋めていきます。

(3) ロボット防止の文字入力を求められますので入力し [次に進む] をクリックします。

(4) メールアドレス用の確認コードを入力するよう求められます。

招待を受けたメールアドレスに以下のようなメールが届きますので、メール本文に書かれている数字をそのまま入力し [続ける] をクリックします。

(5) 続けて電話番号用の確認コードの入力を求められます。(2)で入力した電話番号に、SMS/音声通話かどちらか選択した方式で確認コードが届きます。そのまま入力し [続ける] をクリックします。

(6) 入力後、以下のようにADEP/ADPの契約確認画面に遷移します。契約書を確認し、画面最下部にあるチェックボックスをONにして [同意する] をクリックします。

(AppleID公式サイトでの登録と異なるところ。AppleID登録が終われば即座にADP/ADEPの手続きに進む)

(7) 招待の受諾が完了し、以下のように Apple Developer サイトのTOP画面に遷移します。

(「今すぐ始めましょう」とあり登録が完了したことがうかがえる)

(8) 念のために「メンバーシップの詳細」をクリックして確認しておきます。画面がスクロールして以下のような表示になり、どの企業のADP/ADEPのメンバーになったのか、自分に割り当てられた役割は何なのか、を見ることができます。

(想定と異なっていれば招待してくれた担当者に問い合わせる必要がある)

以上で AppleID 登録と ADP/ADEP の招待受諾の作業が完了です。開発者なら Xcode で開発が始められるでしょうし、テスターなら TestFlight 内部テストに参加できるようになります。

なお既に AppleID に登録されている人を招待した場合は、招待される側の手順のみ変わり上記の (2)〜(5) が省略されます。

おまけ : ADP/ADEPの管理画面は不安定かつコロコロ変わる

ADP/ADEPで使うことのできる Apple Developer サイトや App Store Connect は実は結構不安定です。動作は安定してるとは言えず、不具合もままあります。ですので、以下のような表示になることがあると知っておくと慌てずにすみます。

上図は AppleID 登録時に情報を入力して [次へ進む] をクリックした直後のエラー表示例です。このような表示になっても、取り乱さず数分時間をあけてリトライしてみましょう。

また、動作が不安定なだけでなく、画面表示や遷移先などUI/UXがコロコロ変わる点も覚えておいて下さい。上記手順の (7) で最終的な遷移先を紹介しましたが以前は以下のような画面でした。

2024年現在、こんな画面はありません。社内マニュアル等が存在する場合、上図が掲載されていたりするかも知れませんが、表示が違うだけなので気にしないでおきましょう。上記手順 (8) の件を確認して間違いがなければokです。

以上、ADP/ADEP のユーザ招待から AppleID 登録も一緒に終わらせる方法を紹介しました。2024年現在、自社の ADP/ADEP に招待することが明らかな関係者に対しては本稿紹介の方法が便利です。

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

• 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ユーザ招待ポリシーを定めることが大切です。

(研修資料から。各サービス内の操作可能範囲をコントロールする)

ただこの「役割」が、とてもわかりにくいのです。誰にどう割り当てるのか…あっちを立てればこっちが立たず…となりがちで、社内ルールを定めようとすると結構悩みます。開発を外部委託している場合は特にそうです。

結果、エイヤーッとできることが多い権限をむやみに与えてしまって、無意識にリスクを内在させた状態の運用をしてしまいがちだったりします。iOSアプリ開発では、ADPのユーザの「役割」を正しく理解して適切に設定することが大切です。

そこで、ADPにおける「役割」の基本を2回に分けて解説します。「役割」を検討する時に役立てて頂けると思います。以下、前編の目次です。

• 役割の種類とコントロール範囲
• 権限を5つのグループで考える
• 権限を細かくコントロールすることはできない
• 複数の役割を割り当てることができる

順に見ていきましょう。

役割の種類とコントロール範囲

ADPに招待するユーザには何らかの「役割」を割り当てる必要がありますが、Apple の公式マニュアルによれば「役割」には8種類あります。

多いですね。

このうちの1つ、一番上にある Account Holder はADPの契約主体であり、組織に1名しかおけず招待するユーザに割り当てるものではありません。従ってADPのユーザ招待時に考慮すべき「役割」は、実質7つとなります。

それぞれの「役割」で具体的に何ができるのかは、Apple の公式ドキュメントに明記されています。

横方向に並ぶのが「役割」です。縦方向には操作の項目が並びます。交わるところに黒丸チェックがあればその操作の権限を付与できて、なければ制限されます。例えば、「ユーザとアクセス」の閲覧の操作。これは全てに黒丸チェックがありますので、どんな「役割」を割り当てても可能になる操作だということです。

このように操作 x 役割のマトリックスを全て確認して、自社のセキュリティポリシーに合うよう適切な役割を選びます。

以上！

…なのですが、操作内容の項目がありすぎる上に何が何を意味するのかが分かりにくかったり、表の見方も初見ではよく分からなかったりするので、全体像を捉えるのは極めて困難です。

ここからは、公式ページの権限テーブルの読み解きの助けになる豆知識を紹介します。

権限を5つのグループで考える

公式ドキュメントの権限テーブルは、Apple Developer と App Store Connect で可能な操作群を大きく5グループに分けています。

まずは Apple Developer (Aとします)で1つ目、そして App Store Connect を下図のように4つに区分(B,C,D,Eとします)し、あわせて5グループとなります。

(App Store Connect の全機能。それぞれをモジュールと呼ぶ)

公式ドキュメントの権限テーブルで、A〜Eが以下のように対応します。

権限テーブルの区切りが Apple Developer サイトや App Store Connect のモジュール郡に対応すると覚えておくと良いでしょう。一応、表にまとめてみました。

なお、業務用iOSアプリの世界では以下に掲げる役割と操作項目の権限は、ほぼほぼ無視の扱いで大丈夫です。これらは主に一般消費者向けの公開アプリや課金アプリで使うものだからです。

逆に言うと、業務用iOSアプリで意識すべきなのは、基本的に以下のみということになります。

「役割」に関連することはただでさえ複雑ですから、余計なものは考慮対象から外すのがお勧めです。

権限を細かくコントロールすることはできない

実は、各操作の権限設定には余り融通がききません。上述のAグループ(Apple Developerサイト)での操作一覧を例にして解説します。下図はAグループの上から10件程の操作をピックアップしてみたものです。

権限テーブルに黒丸チェックと白丸チェックとがあり、両マークはそれぞれ以下を意味しています。

1つ例を挙げて解説します。

赤枠で囲った「配布用証明書の作成と無効化」という操作は、招待するユーザの「役割」が Admin なら自動的に可能になります。黒丸チェックだからですね。一方「役割」を App Manager としたなら、許可することも禁止にすることもできます。この白丸チェックの場合の許可/禁止の決定は、ユーザを招待する時の以下ダイアログで、

赤枠で示したチェックボックスをONすることで行います。この設定で招待したユーザの場合、今着目している操作「配布用証明書の作成と無効化」が許可されます。が、注意しなければならないことがあります。

それは、赤枠で示す白丸チェックの行の操作が全て可能になるという点です。

最初は「配布用証明書の作成と無効化」という操作(上図の下から2行目)にのみ着目していた筈です。それをできるようにとチェックボックスをONにした結果、他の白丸チェックの操作も可能になってしまうのです。この3つだけではありません。Aグループには14個も白丸チェックがあり全部が可能になります。

また黒丸チェックは、自動的に操作権限を得ることを意味しています。一度その「役割」が割り当てられたら、縦方向に見て黒丸チェックのある操作が全て可能になります。

(ユーザの役割を「Admin」に割り当てるとこれらの操作が全て自動的に可能となる)

この種の権限テーブルでは各項目ごとで個別にON/OFFできそうなものですが、そうした細かな制御ができずザックリとしか指定できません。結果として、あっちを立てればこっちが立たず…になりがちなのです。

各項目の意味が分かりにくい上に個別にON/OFFできませんから、自社のADPに招待したユーザに一体何ができるようになっているのか、それが自社にどのような影響を及ぼすのかということが、捉えにくく且つコントロールしにくい構造になっています。

複数の役割を割り当てることができる

ADPのユーザには複数の「役割」を割り当てられることにも留意する必要があります。例えばあるユーザに App Manager と Customer Support の両方の役割を与えることができます。

更にややこしいことに、ある役割が別の役割も有効にする場合があります。例えば App Manager の「役割」を割り当てると自動的に Developer と Marketing の「役割」もONになります。

(App Manager の役割をONにした様子。Developer と Marketing が自動的にONとなり、OFFにはできない)

自動的に付与される役割には以下のようなものがあります。

自動的に付与された「役割」をOFFにすることはできませんので、あるユーザに App Manager の「役割」を割り当てたいけど Marketing の「役割」だけは与えたくない…といったことは実現不可です。どの「役割」がどの操作権限を持つのか、またどの「役割」が巻き込まれて付与されてしまうのかも考慮する必要があります。

以上、ADPのユーザに割り当てる「役割」や操作権限について解説しました。まだまだありますが、長くなってきましたので続きは後編で紹介したいと思います。

• カスタムAppのアプリ審査についてよくある誤解(1) 〜審査には時間がかかる〜
• カスタムAppのアプリ審査についてよくある誤解(2) 〜仕様や機密情報を開示する必要がある〜
• カスタムAppのアプリ審査についてよくある誤解(3) 〜特殊なアプリは審査して貰えない〜

今回は、「緊急アップデートは不可である」という誤解についてです。

ADEP(InHouse)なら自社の都合だけで即時配信が可能ですが、審査が必須となるカスタムAppではそうはいきません。とはいえやはり業務用アプリ。業務停止する程のクリティカルな不具合が発覚した時に、現場の端末にアプリを即時配信できないのは困りますよね。

緊急アップデートができないからADEP(InHouse)から移行はできません、という言葉はADP(カスタムApp)移行検討時の現場あるあるです。実際のところはどうなのでしょうか。

半分正解。アップデート版の即時配信はやはり不可

カスタムAppは緊急アップデートできない、という理解は半分正解で半分誤りです。まず正解部分を解説します。

理屈上は確かにそうなのです。カスタムAppは緊急アップデートできません。絶対に審査して貰う必要がありますから。例外はありません。

全てのAppStoreアプリは、審査をして貰い、Appleからの回答を待ち、その上で申請者側が「リリース」をする必要があります。業務用の非公開なカスタムAppでも同様です。

(カスタムAppのリリース作業の様子。審査合格で自動リリースする設定も可能だが、業務用では通常手動にする)

細かく流れを並べると以下のようになります。自社でコントロール可能なことを主導権欄に○で示しています。

コントロールできる範囲が全てではないため、自社都合で即時アップデート配信ができるとはとても言えそうにないですよね。その意味で「緊急アップデートはできない」という理解は正解です。ただ、正解度合いは半分です。

というのも、「緊急」の温度感は各社毎に、アプリ毎に、シチュエーション毎に、全て異なるからです。致命的な不具合が発覚したとして、何時間以内ならokと言えるか。これに明確な答えを出せる現場は少ないでしょう。そもそも「緊急」とは曖昧であり、定量化しにくいものなのです。定性的な表現で物事を断定すべきではありません。

緊急時対策を考える時に大切なのことは、

• (A) 緊急時を極力発生させないように開発・運用すること
• (B) 緊急時の業務フローを定めること

です。

カスタムAppは緊急アップデートができない…と嘆く関係者ほど、カスタムAppを前提としたルールや業務フローを検討すらしていないように感じます。例えば以前の投稿で紹介したような、本番用・テスト用でアプリを分けるといった開発手法を採ってしまっているとかですね。

(A)は開発テクニック論になるので別途紹介することとして、ここで考えたいのは(B)の緊急時の業務フローです。先ほどの表を再掲します。

実は各手順を細く見ると、カスタムAppでも「緊急」と言えるスピード感で対応できる可能性が見えてきます。

1,3はAppleを待つ時間ではありません。自社の問題です。誰がどのようにやるかを決めて正しい設定をすれば瞬殺で完了できるタスクです。また5,6はADEP(InHouse)を使っている場合でも一緒ですから考慮は不要。4はMDMの実装や仕様によりますので、MDMベンダーに確認し最短化する方法を提案して貰うことができます。

1,3,4,5,6は自分達が頑張れば瞬殺または最小化できること。では、残った2はどうでしょう。ここはAppleに依存する部分です。

緊急審査の要請ができる

余り知られていませんが、先ほどの表の1と2の間に、緊急審査要請を行うことができます。実は、公式ドキュメント App Review のページの中ほどに書いています。

唯一、自社だけの努力ではどうにもならない、かつ一番時間がかかりそうな Apple 審査の所要時間について、短縮の要請が可能になっているのです。もちろん然るべき理由は必要で、常に認められるわけではありません。

リンク先から専用のフォームを開くと、以下のようにどのアプリについてなぜ緊急審査が必要なのか入力を求められます。

(ADPのユーザとしてサインインした状態で入力する)

この緊急審査要請が受け入れられると、ものの数時間で審査して貰えてリリースが可能だということです。ただ、繰り返しになりますが理由が妥当でなければなりません。理由が不適切なら緊急審査を受理して貰えない場合もあります。

また、下図の注意表記(特に赤枠部分)は英文だからとスルーせずよく目を通しておきましょう。

過度な申請は将来の申請受理を難しくすると書いてありますね。従って乱用は避けるべきです。メールのタイトルにいつも「緊急」と書く人が信用されなくなるのと一緒です。

本当の緊急時に緊急審査をして貰えなくなる可能性がありますので気をつける必要がありますし、勝手に申請しないよう社内関係者や(AdminやAppManager権限を付与している)委託先にも注意を促しておくのが良いでしょう。

そもそも緊急審査要請は必要か？

実は、緊急審査の有用性は下がっています。

以前の投稿でも紹介した通り、90%のアプリが24時間以内に審査されていると公式に表明されていて、実際に数時間で審査が完了する場合もままあるからです。緊急審査要請の画面でも強調されています。

文頭から「今は平均で90%が24時間以内に審査されますよ。それにも関わらず御社は…」と書いてありますね。

審査を開始して貰うにも2週間かかっていた…という時代ならまだしも、審査スピードが上がっている昨今では、「Appleに緊急対応を求めても恥ずかしくない程度に、自社の緊急時体制は果たして整備されているか？」をまず問うことをお勧めします。

企業によっては非現実的なこともありますが、例えば以下のような検討/確認を行なって、体制を整えておくのが良いでしょう。

• 外部委託では商流段数を少なくし App Store の知見を持つ企業を選定する
• App Store アプリ申請の手順や役割分担を明確にする
• 本番用アプリとテスト用アプリを分けて開発しない
• TestFlight を活用して本番用アプリ想定で十分なテストを行う
• 端末側で TestFlight を配信し過去バージョンに戻せる体制を作っておく
• AdHoc 配布を併用することで有事のワークアラウンドにできないか検討する
• 初回バージョン以降は審査時間が短い傾向を活用し事前に初回審査を通しておく
• そもそも本当にアプリである必要があるかを考え、場合によってはWebアプリ化してWebClipでMDM配信する

緊急時を気にすればこそ色々と考えることがあるということですね。

以上、AppStoreアプリでは緊急アップデートができないという誤解について解説しました。半分正解で半分誤りです。なぜそう言えるのか、また緊急時対応が気になるアプリで事前に検討できる項目についても紹介しました。

アプリの緊急アップデートができないことを理由に、ADEP(InHouse)からADP(カスタムApp)には移行しないと決めてしまうのも一つの選択です。しかし、ADEPの将来が明るいとは考えにくいため、契約継続が難しくなる場合に備え本稿等を参考にして頂き諸々検討しておくことをお勧めします。

• カスタムAppのアプリ審査についてよくある誤解(1) 〜審査には時間がかかる〜
• カスタムAppのアプリ審査についてよくある誤解(2) 〜仕様や機密情報を開示する必要がある〜

審査のことがよく分からないという不安から、心配が誤解に繋がっていることが多いです。

これには非常に分かり易い理由があります。業務用iOSアプリを請け負う開発会社も、商流の間に入るコンサル会社やSIer企業も、B2Cの世界とは無縁な場合が多いのです。つまり AppStore に触れる機会がほとんど無い(無かった)。だから知らないし、よく分からないし、不安、となります。当然ですね。

ですが、誤解は紐解いてみれば「な〜んだ、そうなんだ」と拍子抜けすることがほとんどです。

シリーズ3つ目となる本稿では「専用機器やローカルネットワークの使用を前提とする特殊アプリは、そもそも審査して貰えない」という誤解について解説します。

結論 : 審査して貰える

結論を書くと、審査して貰えます、となります。

この誤解は、AppStoreのアプリ審査の経験がない業務用iOSアプリ関係者にありがちな思い込みです。ADEP(InHouse)からADP(カスタムApp)への移行検討時には特によく聞かれる言葉でもあります。

業務で使う専用ハード用のアプリだから審査して貰える筈がない、だから移行は無理です…ってなもんですね。

実は、AppStore で公開されている(審査を通過している)アプリ群を冷静に見渡してみると、専用ハードウェアと連携する前提のアプリが多く存在していることが分かります。例をあげましょう。

(最近何かと問題のLUUPのアプリ)

(SONYのDIY用IoTモジュールMeshのアプリ)

前者はバイクのQRコードを読み取る機能があります。後者は 2cm x 5cm 程度のIoT用パーツとBluetooth連携するアプリです。どちらも「ブツ」が必要ですね。

さて、これらの専用ハードウェアが必要なアプリを Apple はどのように審査しているのでしょうか？

ハードウェアをApple 現地法人に送付する…と思われますか？それとも審査が難しいという事情があれば無審査で通過させて貰えると思われますか？はたまたAppleの審査員(レビュワー)が開発元までわざわざ飛行機で来日して審査してくれると思いますか？

答えは、

• アプリの起動等の最低限のチェックは行われる
• その上で、アプリを説明する動画や画像を送って審査して貰う

です。

そう、専用機器を触って貰えないからAppleは審査ができない、社内ローカルネットワークでしか動作しない特別なアプリだから審査がそもそも不可、ではないのですね。

動画や画像で審査して貰った具体例

弊社実績の中からの具体例を2つほどあげてみます。

• 自社開発の、BLE (Bluetooth) 通信前提の専用ハードウェアと連携するB2Cアプリ
• 受託開発の、商業施設内に固定された機器をネットワーク経由で遠隔操作するB2Bアプリ

前者のB2Cアプリは、アプリ使用中の様子を動画撮影して審査して貰い、AppStore公開アプリとして国内で配信しました。2014年のことです。詳細は以下に掲載されていますのでご興味あればご覧ください。(2016年に(株)そらかぜに事業譲渡。その後、販売/サポート終了)

• 玄関先で雨降りを予想！iBeaconと連動する降雨予想自動通知アプリがお目見え
• 外出の際に傘が必要か知らせてくれる「そらビーコン」を衝動買い！

後者のB2Bアプリは、いわゆる専用ハードウェアのリモコンアプリ。同様に撮影動画で審査を受け AppStore の非公開アプリ(カスタムApp)としてABM→MDM経由でお客様の業務用端末に配信しています。ADEP(InHouse)からADP(カスタムApp)に移行した例で、審査は2022年のことです。2023年12月現在も現役稼働中です。

他にも事例はありますが、審査の受け方はどれも一緒です。アプリを実際に触ることだけが審査というわけではなく、Appleなりにアプリを理解しようと頑張ってくれます。そのための追加情報を提供するわけです。

どのようにして動画や画像を提出するのか

AppStore向けアプリは App Store Connect から審査に提出します。

(App Store Connect ではアプリ毎に詳細な情報を登録する)

アプリに関する様々な情報を入力しますが、その中にAppleの審査員(レビュワー)向けに各種ファイルを送付できるUIが用意されています。下図のように添付ファイルをアップロードできるのですね。

(通常は余り使わない)

1ファイルしか添付できませんので、複数ファイルを送る必要がある場合はzip化して添付します。

動画の場合はサイズが大きくなりがちですので、Box や Dropbox 等のクラウド型ファイルストレージを使ってもokです。共有用URLを発行し、そのURLをメモ欄に記載します。

秘密情報が含まれていてAppleのレビュワー以外にダウンロードされたら困る場合は、共有用URLにパスワードをかけメモ欄にパスワードを併記すれば良いでしょう。

「最初から動画をいちいち用意しなければならないのか？」

と気になる方もいると思います。最初から添付すると確かに親切なのですが、最初から必須というわけではありません。レビュワー用のメモ欄にテキスト解説するだけで十分な場合もあるからです。社内用のマニュアル動画を用意しているのであれば、ついでに添付するぐらいのスタンスで最初は良いと思います。

仮に、動画や画像なしで審査提出したとします。Apple のレビュワーが実際にアプリを起動して確認し「ちょっとこれでは審査しようがないなぁ…」となったとします。そうすると審査情報不足とされ、以下のように reject されます。(ガイドラインの2章「パフォーマンス」の違反という扱い)

(審査の情報が足りないとして reject されている様子)

Apple からはこんなメールが届きます。(太字は筆者)

We have started the review of your app, but we are not able to continue because we need access to a video that demonstrates the current version of your app in use on a physical iOS device, which shows 〜〜〜.

(rejectメールは基本的に英語だが、2023年12月頃からは日本語で送られてくる試みも始まっている)

要約すると「実機で動作している様子が分かるデモ動画を送ってください」ということです。文中 〜〜〜 の箇所は具体的に Apple のレビュワーが確認したいと考えている内容です。かなり親切に分かり易くアドバイスしてくれていると思いませんか？

こうなってから動画や画像を制作してもokです。reject を受けたからといってペナルティを課されたり、以後の審査で通りにくくなる…なんてことはありません。

また、このような情報不足系 reject ではアプリを修正して再ビルドしてアップロードする必要はありません。レビュワーのアドバイス通りに動画や画像を添付するか、共有URLを提示して再度申請するだけです。

(reject時にレビュワーと会話できるスレッドが用意される。ここで返信しても良い)

ちなみに、アプリ情報の修正/追加だけを求められるタイプの reject のことをメタデータリジェクトといいます。メタデータリジェクトでは、アドバイス通りに情報を修正/追加すれば審査が続行され、別の問題がない限りすぐ審査通過となります。

以上、「特殊なアプリは審査して貰えない」という誤解について 、実は動画や画像などのリッチメディアを提出することで審査して貰うということを解説しました。

カスタムAppは特定企業の非公開アプリですので、Appleが決して使うことのない専用機器や専用環境を前提とする場合が多くなります。動画や画像で説明が求められることに備えて、それらを制作するための体制作りと時間確保をしておくと良いでしょう。

そんなに恐れる必要はないしAppleもちゃんとやってるんですよ、ということを伝えるべくAppStore審査関係の投稿を幾つか投稿してきました。

• 業務用AppStoreアプリで審査にリジェクトされないために読んでおくべき公式ドキュメント
• カスタムAppのアプリ審査についてよくある誤解(1) 〜 審査には時間がかかる〜

AppStoreアプリ審査のことをよくご存知ない方は是非、上記の2投稿を先にご覧下さい。本稿では、カスタムAppアプリの審査について持たれがちな「Appleに仕様書や機密情報を開示しなけれならない」という誤解について解説します。

結論 : 開示の必要はない

今回も結論から書きます。アプリ審査にあたり仕様書の提出や機密情報の開示は不要です。

ドキュメント類の提出を求められることはありません。例えば、アプリの要件定義書や画面設計、サーバ構成、サーバ〜アプリ間で行う通信APIやプロトコル仕様書…等々、いずれも提出または開示する必要はありません。

この誤解も、AppStore 審査をよく知らないことからくる不安や猜疑心に起因しているかもしれませんね。

(AppStoreには200万個近いアプリが存在する。全アプリが書類提出していると想像するのは果たして妥当か？)

Appleによる審査は物凄い数のアプリに対して行われています。しかもアプリ毎に最初だけ…というではなく、全てのアプリの全てのバージョンで審査しているわけです。世界中の百万個を超えるアプリが、です。とてつもない数の審査が日々行われており、いちいち仕様書を渡されたところで Apple が見れる筈もないことは想像に難くないでしょう。

それに、我々は多くのソフトウェアで「ドキュメントは嘘が多い」ことを知っている筈です。メンテがされず仕様変更に追随できていないドキュメントが多いことはソフトウェア業界の経験則です。Apple にはそんなドキュメントを確認することの合理性はないと考えるのが順当です。

見られるのはアプリです。資料ではありません。

判断基準は App Store Review Guideline ただ一つ。これを守ること、本当にこれだけなのです。当該ガイドラインに書類提出要件はありません。App Store Review Guideline を熟読しましょう。弊社は15年以上アプリ審査を3桁以上のアプリで経験していますが、資料提出を求められたことは一度もありません。

提出しようと思えば資料をアップロードできる

審査をする際に各種の情報を登録する App Store Connect には、レビュワー(審査員)に対してファイル送付できる機能が備わっています。

(あるアプリのバージョン1.0申請準備の画面。ファイルを添付できる)

なので、提出しようと思えば提出できます。複数ファイルにまたがる場合は zip 化して送ることもできますし、レビュワーに向けて審査情報テキストを入力するメモ欄にクラウド型ストレージのURLを記載することも可能です。

(あるアプリで審査員向け文章中にDropboxのURLを記載した例)

が、仕様書や機密情報を提示したから審査が早くなるとか、ガイドライン違反も許容して貰えるといったものではありませんので、あえて提出する必要はないでしょう。

本来、審査提出時のファイル送付機能は、レビュワーにアプリの概要をテキストでは伝えにくい時に画像や映像を送るために使うものです。

暗号化技術については別。だが開示先はAppleではない

App Store Connect にアップロードしたアプリを、TestFlightで配信する時やTestFlight配信をせず直接申請する場合、原則、暗号化に関する自己申告を行う必要があります。

いわゆる暗号化技術に関する「輸出コンプライアンス情報」の設定です。

AppStore アプリの配布はB2CかB2Bか、公開か非公開か、に関係なく米国からみればソフトウェアの「輸出」になります。公式ページの輸出コンプライアンスの概要が詳しいですが、iOS SDK が標準で備えている暗号化機構を使わずに独自暗号技術を使う場合は情報提供が必要となります。

とはいえ、何を目的に暗号技術を使っているかの情報開示のみであり、暗号アルゴリズムを開示することまで求められるわけではありません。

(独自暗号技術を使っている場合、商務省管轄のBISに書類の提出が必要になる)

さらに、開示先は Apple ではなく、米国商務省産業安全保障局(BIS)です。BISに情報提示をして発行された書面PDFをApp Store Connect にアップロードするだけのことで、Apple に情報開示するわけではありません。

以上、「Appleに仕様や機密情報を開示しなければならない」という App Store のアプリ審査によくある誤解について解説しました。結論は、必要ないです。審査について不安になったら必ず App Store Guideline を読むようにして下さい。