Apple Business Connect というマーケティング用途のサービスが統合されたり、Appleの新施策な機能も内包されたりで、デバイス管理(MDM)の域を超えた法人向け総合ポータルに仕上がってます。

(リリース日とされていた4月14日は米国時間なので。日本時間では4月15日から)

マーケティング関係は本サイトの主旨とは若干ずれますので、本稿では、デバイス管理(MDM)の機能を中心に Apple Business のざっくりレビューを幾つかに分けてお届けしたいと思います。一通り触ってみた感想を最初に書くと、

• 機能が一部限定されるが、デバイス管理(MDM)の敷居は極めて低くなった
• MDM未導入の企業は、まず Apple Business でデバイス管理を始めるのがお勧め
• MDM導入済の企業でも、業種・業界・規模を問わず再評価する価値がある

です。

弊社は、BizMobile Go!というサードベンダーMDMの販売パートナーでもあるので正直言いにくかったりもするのですが、大半の企業のデバイス管理(MDM)は Apple Business で十分となるという印象です。

圧倒的な導入しやすさ

MDMによるデバイス管理とは、中心的な役割を担うサードベンダーMDMがAppleのサービスと連携するという構図が基本でした。契約したらすぐ使えるのではなく、各サービスを「連携」させる初期の構築作業が必要だったんですね。これが結構面倒くさいのです。

(セミナー等で紹介する図。丸印が連携させるべき箇所)

アプリのライセンス管理には、ABMとMDMのVPP連携が、キッティングの自動化にはABMとMDMのADE連携が、そしてMDMをそもそも機能させるためにAPNs連携が…といった具合。証明書ファイルやトークンファイルなど、多くの人にとっては何それ？なモノをダウンロードしたりアップロードしたりを、幾つか、そして毎年、行う必要がありました。

Apple Business では、それらが一切いらなくなります。

連携作業がゼロ。そりゃそうですよね。連携とはつまり、非AppleなMDMとAppleのサービス群(ABMやAPNs)との間に信頼関係を構築する為の儀式だったわけで、全部がAppleなら信頼関係もへったくれもないからです。

証明書もトークンそのものが不要だし、更新作業も必要ありません。本質的なデバイス管理にのみ目を向けることができます。やることは、最初にデバイス管理機能を使います！と意思表示するだけ。こんなふうに…

(Apple Business でのデバイス管理機能のことを「組み込みデバイス管理」と呼ぶ)

連携作業のような面倒な作業なく、すぐ設定作業に移ることができます。考えなくて済むことが多いのは、管理部門にとっては良いことです。

(連携作業を全てすっ飛ばして管理のための作業にすぐ入れる)

いわゆる情シスのような管理部門の方からすると、正直、冒頭で述べたような余計な(?)マーケティング的機能がノイズに見えなくもありません。Apple Business Connect というサービスが統合された結果ですが、例えば「ブランド」なるページ。

(およそデバイス管理には無関係に見えるブランドメニュー)

デバイス管理(MDM)的には必要ありませんね。でも、ご心配なく。Apple Business では、画面・機能の単位で細かく権限設定ができるようになってます。

(機能単位でON/OFFが指定できる)

権限をある程度まとめた「役割」もプリセットで幾つか用意されています。ABM時代の「コンテンツマネージャ」「デバイス登録マネージャ」「ユーザマネージャ」という管理系の3つの「役割」も移行されています。

(「役割」のプリセットにIT管理者とマーケティング管理者が増えた)

権限設定や「役割」をうまく使えば、Apple Business を、デバイス管理(MDM)の機能しか持たないサイトとして見せることも可能ですので、管理部門に優しい作りになっていると言えるでしょう。

(ブランドメニューを消した。なぜか「広告」だけは表示が残る。が、機能しない)

ちょっと権限系の話に逸れてしまいましたね。話を戻しましょう。

Apple Business はとにかく、デバイス管理(MDM)を始めるのが超絶楽です。そのうえ、台数の上限もなく、さらに無償。軽く試してみて、不要ならやめればいいですし、便利さを実感して本格導入することになっても、費用が発生することもなくそのままスケールできるという安心感があります。

あえて面倒なことをあげるなら、Apple Business の利用申請ぐらいでしょうか。DUNS番号の取得が必要だったり、Apple担当者との電話や場合によっては登記簿の提出が必要だったり…。

ただ専用のサポート窓口がありますから、それほど身構えるような大変さでもありません。日本語で会話できますし、Appleから直接端末を購入すれば各ストアの法人チームからの支援も得られます。

(ABM時代から専用のサポート窓口が設けられている)

なお、すでにABMを利用申請済みな企業は、ABMがそのまま Apple Business にアップグレードされてますから、面倒なことは何一つなくすぐに始められます。Apple から以下のような Apple Business の案内メールが届いている筈です。

(即座に Apple Business でデバイス管理が可能になる)

ここまでで、Apple Business はお手軽に導入ができて、権限設定も柔軟にできることを解説しました。次に気になるのは機能面ですね。もし Apple Business のデバイス管理(MDM)機能が貧弱なら「始めるのは楽だけど機能がちょっとね…」という評価になりますが、実際のところどうでしょうか。

遠隔操作

デバイス管理(MDM)を始める動機の一つに、紛失や盗難時の対策があります。遠隔で一時的にロックするとか、初期化してデータを消すとかとかですね。有事の際に端末を保護するための機能ですが、Apple Business にはこれが標準で搭載されています。

まずは一時的なロック。紛失した端末を全く触れなくなる状態(紛失モードと呼ぶ)への切り替えを遠隔で行うことができます。そのまんまのボタンがありますね。

(紛失モードはiOSが標準で備える特別なモード)

このボタンをポチッとクリックすると、確認画面を経たあと、端末に命令が送られて、一切の操作を受け付けない状態になります。こんな感じ。

(文章や電話番号は Apple Business 上から指定できる)

HOME画面に移動することもできませんし、アプリを起動することもできません。この画面だけ。さらに紛失モード中は、端末の現在位置を Apple Business 上で把握できます。

(セルラー版の端末なら現在位置のトラッキングが可能)

運良く端末が見つかれば、Apple Business の画面から紛失モードを解除。端末の正規の利用者は、データ・設定等そのままに何事もなかったかのように使えるようになるってわけです。便利ですね。

この一連の機能は、従来のMDMで「紛失モード切り替え」とか「管理者ロック」と呼ばれていたものです。従業員の端末紛失というインシデントに備える機能として提供されてきました。Apple Business ではこれをなんと、無償で使えます。台数制限もなければ、複雑な設定もありません。すごくないですか？

さてでは、紛失ではなく、端末の盗難というインシデントの対策はどうでしょう？盗難時は、ロックするだけじゃなく、情報漏洩を阻止するためいっそのこと端末を初期化したくなりますよね。

もちろん、Apple Business に遠隔で初期化する機能が備わってます。

(色んな操作ができるが、ABM時代の機能とMDM特有だった機能が混在している印象)

端末のメニューからただ「消去」をクリックするだけ。初期化命令が飛んで、端末は強制で初期化されます。情報漏洩リスクを軽減できますね。従来のMDMでは「ワイプ」とか「リモートワイプ」と呼ばれていた機能です。

なお、デバイス管理(MDM)の仕組み的には「再起動」「スリープ」「パスコードの消去」といった遠隔操作も可能なのですが、Apple Business には搭載されていないようです。これらの遠隔操作をしたいなら、サードベンダーのMDMを選択することになります。

ずいぶん長くなりました。一度区切りましょう。

ここまでで、Apple Business は簡単に始められること、主要な遠隔操作機能が標準で搭載されていることを紹介してきました。やはり無償で使えて端末数制限もない点に、新しさ(脅威?)を覚えますね。

次回は、デバイス管理(MDM)のもう一つの主要な機能である「設定や制限の配布」が、Apple Business でどのように行えるのか紹介をします。

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削除にあたっては、下手すると取り返しのつかないことになるケースもあったりします。本稿で幾つか注意点を紹介したいと思います。順に見てみましょう。

• 役割が管理者だと削除できない
• 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を削除する場合に注意しておきたいことの紹介でした。削除する時は念の為に確認するようにして下さい。

Every iOS device is assigned a UDID (Unique Device IDentifier), uniquely identifying the device. It’s a unique value different from the device’s serial number and not displayed in the Settings app.

The existence of UDID might be unfamiliar to those not involved in iOS app development. However, collecting the UDID of all target devices is essential when distributing test apps via AdHoc.

(Registering the UDIDs of devices belonging to stakeholders you want to grant app access is necessary.)

Although using TestFlight for test app distribution is recommended, there are instances where it could be more feasible due to various constraints or past issues.

In such cases, collecting UDID is still necessary, but it can be surprisingly cumbersome and bothersome. It would be ideal if you could do it all by yourself, but sometimes you have to ask those unfamiliar with handling Mac or Windows or who do not have high IT literacy, “Could you tell me the UDID of your device ?”

Therefore, in this article, I will introduce a complete guide to finding the UDID of iOS devices, covering all ten methods.

• (1) MDM (for IT Department)
• (2) Xcode (Mac / for Developers)
• (3) cfgutil (Mac / for Developers)
• (4) Apple Configurator (Mac)
• (5) Finder (Mac)
• (6) Music (Mac)
• (7) System report (Mac)
• (8) iTunes (Windows)
• (9) Device Manager (Windows)
• (10) UDID.tech (Web)

Let’s look at them in order.

(1) MDM (for IT Department)

The most efficient way to collect UDIDs is not to have everyone check their UDIDs but instead have you use MDM to find out everyone’s UDIDs.

MDM collects almost all information about the checked-in devices. Naturally, it also contains UDIDs so you can look up the UDIDs of all devices under MDM management with a browser.

(The device information window in BizMobile Go!, an MDM solution developed by a Japanese company)

Many MDMs can export a device detail information list, including UDID, as a CSV file so that you can quickly create a list of UDIDs using Excel or Numbers.

(Opening the CSV file. Quickly obtaining the list of UDIDs is straightforward.)

The initial step in UDID collection is to list the target UDIDs using MDM by the IT Department.

For devices not managed under MDM, it’s advisable to have their owners check each UDID subsequently.

It is also recommended for development companies and SIers to implement MDM in-house, especially since collecting UDIDs is a necessary step during the test phase via AdHoc distribution.

(2) Xcode (Mac / for developers)

If you are a developer, you can use Xcode. Click [Devices and Simulators] in the Xcode menu, and select the device you wish to display its details.

The Identifier in the red rectangle is the UDID. The shortcut [command] + [shift] + [2] is helpful to display this [Devices and Simulators] screen. By the way, you can also check the serial number on the same screen.

(3) cfgutil (Mac / for developers)

Developers familiar with terminal operations can use the cfgutil command to check UDIDs. You can display not only one device’s UDID but multiple devices’ UDIDs simultaneously via a USB hub.

Please connect an iOS device to a Mac via USB and run the following command.

$ cfgutil --format json list | jq .

(Execute cfgutil list command. The jq command needs to be installed separately)

Note that cfguitl is a utility command that comes with Apple Configurator. If you are creative, for example, you can create a system that automatically sends an e-mail with the UDID to the person in charge by connecting a USB cable to a shared Mac within your company. (via cfgutil; exec command)

(4) Apple Configurator (Mac)

If you are a Mac user who is neither an IT professional nor a developer, you can use Apple Configurator.

First, connect your iOS device to your Mac via USB and launch Apple Configurator. Immediately after launch, you can see a list of devices connected to your Mac, as shown below.

You may double-click the device whose UDID you want to check, and the device details screen will appear.

The UDID is the red rectangle on this screen. You can select it as text by double-clicking it. Also, you can use the shortcut [command] + C or the right-click menu.

(5) Finder (Mac)

If Apple Configurator isn’t installed on your Mac, we recommend using the Finder.

You may connect the iOS device to your Mac via USB and click the device in the sidebar of the Finder. The following device information screen will display.

(Since macOS Catalina, the iOS device information screen and various operations to the device have been integrated into Finder.)

On this screen, click the red rectangle area in the above figure to switch to the serial number and UDID.

Further, by right-clicking, you can copy only the UDID as text.

This method is the easiest way to find the UDID for those who are not IT Department staff or developers using Catalina or later Macs.

(6) Music (Mac)

As with the Finder, you can also check the UDID in the Music application.

You may launch the Music and select the device you wish to check UDID from the “Devices” on the sidebar. You will see a window like the following. (If you have downloaded and installed songs, a list of songs will be displayed.)

(Detailed information will not be displayed for a device that has not completed the AppleID setting.)

As with the Finder, clicking the red rectangle displays the serial number and UDID.

(You can copy the UDID by right-clicking on it as text.)

However, although we have introduced this method, Finder is more common, so we don’t think you should look it up using the Music app.

(7) System Report (Mac)

You can also check the UDID from the “System Report”, which provides detailed information about your Mac.

With the device connected to the Mac via USB, go to the Apple menu and click [About This Mac] > [More Info] > [System Report] button.

The System Report will display. Click on Hardware USB in the sidebar and select your iOS device from the list.

The UDID will be displayed in the “Serial Number” field in the lower right pane. (Note that the name is confusing.)

Note that the UDID displayed in the System Report omits the hyphen in the middle if the device’s UDID is in the new format (00000000-0123456789ABCDEF 8-16 digit format). If you are in charge of registering UDIDs on developer.apple.com for AdHoc distribution, please include a hyphen between the 8th and 9th digits when registering.

(8) iTunes (Windows)

To check the UDID in a Windows environment, you may use iTunes.

This method is relatively easy since it’s likely that most Windows PC and iOS users have iTunes installed. If you haven’t installed iTunes, please install it from the Microsoft Store URL or iTunes Downloads

First, you may connect your iOS device to your Windows PC via USB and launch iTunes. Then, clicking on the device icon displays its details.

Each time you click on the red rectangle area, the text will change from ECID to serial number to UDID. Please click twice to display UDID and copy it as text.

Sometimes, iTunes does not recognize the iOS device. If this happens, try unplugging and plugging the cable or restarting iTunes or Windows.

(9) Device Manager (Windows)

You can also find UDID using the “Device Manager” on Windows. This method is exceptional, but we will introduce it here.

First, please right-click on the Windows menu and open [Device Manager]. The following screen will display. Then, please open “Universal Serial Bus Devices”.

In “Universal Serial Bus Devices”, you will find “Apple Mobile Device USB Composite Device”. Please double-click this item or right-click it and click “Properties” to display the following dialog box.

Next, you may select “Details” tab and switch the list box in the “Properties” to “Device Instance Path”, and you will see string separated by \ (backslash) mark in the value column. The right of the last \ mark in the string is the UDID.

Note that if the UDID is displayed in the new format (00000000-0123456789ABCDEF 8-16 digit format), the hyphen will be omitted. Please make sure to insert a hyphen between the 8th and 9th digits when registering at developer.apple.com.

(10) UDID.tech (Web)

There is a service that allows you to find out your UDID without the need for MDM, Mac, or Windows, just by visiting a website called UDID.tech.

You can download a special profile if you access this site with Safari on iOS.

After installing the downloaded profile from the Settings app, the UDID will be displayed on the website.

 
(Not only UDID but also serial number will be displayed. If your device is a cellular model, you can also see IMEI.)

This service, developed by Pixel Rainbow Inc. in the U.S., aims to simplify getting UDID.

You may think, “Isn’t there an API to get UDID now?” “How does this service get the UDID on the web?”. The About page of this site is as follows.

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

This service seems to be using the MDM protocol and not some hack or exploit of an iOS vulnerability.

Strictly writing, it uses the iOS behavior when a configuration profile with a special payload called Profile Service is installed. If you are interested in this, you may read the Apple official document Over-the-Air Profile Delivery and Configuration or analyze the configuration profile from this site.

By the way, anyone can create the same service as UDID.tech using the published specification. But we have yet to be aware of any similar site.

Conclusion: Use TestFlight for test distribution as much as possible

In this article, we have introduced ten ways to find the UDID. I suggest using them for AdHoc distribution in the development phase.

However, as of 2024, it is recommended to use TestFlight for test app distribution and avoid AdHoc distribution as much as possible. This is because UDID management becomes complicated, and it takes time to respond to problems such as “the app doesn’t work on this device !” or “can’t register more UDID on the Apple Developer site !”

Now that non-public business apps must be submitted as Custom Apps to the AppStore, there is no reason not to use TestFlight.

Although TestFlight may be confusing with its many technical words, such as internal and external tests, it is much easier to understand and use TestFlight than in 2014, when Apple first released it.

If you are still using AdHoc distribution for test distribution due to past practices, consider migrating to TestFlight now so you don’t have to worry about UDID collection.

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

記念すべき(?)第一回目は、古い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に移行したいというご相談への回答および関連解説をお届けました。他にも学びのある無償相談は沢山ありますので、また紹介したいと思います。

Appleの審査を避けたい事情はアプリによって様々です。

そもそも審査の手続きが面倒だ、プライベートなAPIを使いたい、本来用途と異なるハック的なAPIの使い方をしている、AppStore Review Guidline に反した事をやりたい…などなど。B2Bの世界では、そもそも「ウチで使う業務アプリをなぜ審査されなくてはならない？」という感覚の方もいます。

理由はどうあれ業務用iOSアプリの世界では、Appleの審査を避けるなら InHouse(ADEP) 一択だ…と誤認されてきました。しかし実は、Appleが InHouse(ADEP) 以外にも審査回避手段を用意していることは意外に知られていません。InHouse(ADEP) が余りにも強力過ぎて(審査不要・無制限配布)、他の手段に目が向けられることがほとんど無かったからでしょう。

そこで本稿では、InHouse(ADEP) を含め、改めてアプリ審査を回避できる配布手段を整理してみたいと思います。当然ながらすべて公式に提供されているもの。まず以下に一覧を示します。

関連する投稿へのリンクも貼っていますので併せて参照して下さい。それでは順に見ていきましょう。

InHouse – ADEP (Apple Developer Enterprise Program)

審査回避手段として一択と誤認されているぐらいですから、真っ先に思いつくのがこちらでしょう。

詳細については以下をご覧下さい。

• ADEP (Apple Developer Enterprise Program) とは何か

しかしAppleは、2019,2020年頃から新規受付を事実上停止しています。また、2022年からその更新も審査制に変わりました。審査の結果、更新を認められなかった、つまり InHouse が使えなくなった企業も出始めています。詳しくは以下をご覧下さい。

• ADEP(Apple Developer Enterprise Program)はもう取得することができないと諦めたほうが良い理由
• そろそろADEP契約更新ができなくなるかも知れない 〜カスタムAppへの移行を急ぐべき理由〜
• そろそろADEP契約更新ができなくなるかも知れない…その後(1), (2)
• 実録！ADEPの更新を拒否されるまでの全て (1), (2), (3)

今後はどうなるか分かりませんが、長らく業務用iOSアプリの世界を見てきた弊社の見解は「新規受付の復活は考えにくいし、更新も徐々に厳しくなっていくと思われる」です。

ADEPの契約が既にできていて且つ2023年現在まだ更新ができている企業の場合、ADEPを使い続けるのが合理的な選択です。そうでない企業がApple審査を回避したいなら、後述の3つの選択肢から選ぶことになります。

AdHoc

ADP(Apple Developer Program)を契約して、その契約の配下で AdHoc 形式の配布を選択することにより Apple の審査を回避できます。(AdHocはADEPでも使えるが実質使い道がない)

(研修資料より)

AdHocはiOSアプリの歴史的経緯から、テスト用の配布手段と認識されていましたが実はそうではありません。ADP契約毎にデバイスごと100台までという上限に注意が必要ですが、本運用で使用しても実は問題ないのです。詳しくは以下をご覧下さい。

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

AdHoc 形式では1年に一回の Provisioning Profile 更新が必要となります。しかしAdHocもMDMからの配布が(多くの場合)使えることも考えれば、ADEPでのInHouseアプリ運用と大差ありません。InHouseアプリと全く同様に、Appleのアプリ審査を受けることなく端末にアプリをインストールできますので、開発しようとしている業務用アプリの配信端末数が100台以下なら、積極的に検討できる手段です。

TestFlight 内部テスト

TestFlight とは Apple が公式に提供しているテストツールです。元々はあるスタートアップが開発したものですが、買収に次ぐ買収で最終的に Apple が買い上げて洗練させ、公式テストツールとした経緯があります。

(歴史に興味があれば Wikipedia-TestFlight を参照(英語))

関係者の間で評価する場合に使う内部テストと、いわゆる公開ベータ版テストのように第三者の評価協力を募る場合に使う外部テストと2種類の仕組みが用意されています。App Store Connect からアプリをTestFlight向けに登録し、本審査前とは別のテスト用審査を受けることでテスト配信が可能となります。

(研修資料より。InHouseの経験しかない場合、TestFlightの使い方が一番の難所。研修ではテスト設計も解説している)

テストに参加するユーザはテスターと呼ばれ、テスター専用のTestFlight というアプリを介して AppStore 登録前のテストバージョンを受け取ってインストール・テスト・フィードバック送信が可能です。

(研修資料より)

この TestFlight を審査回避の手段として使うことができます。先に「本審査前に別のテスト用審査を受けると」と書きましたが、内部テスト用審査は事実上無審査だからです。アプリである ipa ファイルの正当性・妥当性のみチェックされます。

 → 
(実際にTestFligth内部テストで配信されたアプリと起動後の画面。起動後にlabelしかなくても審査は通る。本審査ではありえない)

この特性を利用することで、事実上の無審査アプリ配布が可能となります。もし作ろうとしている業務用iOSアプリが、実験的開発や評価検証用のPoCである場合は、TestFlight の内部テストを使うことも選択肢に入るでしょう。

ただしPoC を抜けた本番運用のフェーズでは、TestFlight を使い続けることができないことに注意すべきです(TestFlightはテスト用途専用)。とりあえずアプリを作ってみたい評価用プロジェクト向きの手法といえます。

Webクリップ

意外に盲点で余り知られていない手法です。通常、開発会社側にMDMと構成プロファイルの理解がなければ思いつかないアイディアだからですね。(そして開発会社の多くは残念ながらそれらを使う機会がほとんどありません)

• Webクリップとは何か(1) -Webサイトのブックマークを配布する-
• Webクリップの作り方と各設定値を徹底解説 [前編] -Webクリップとは何か(2)-
• Webクリップの作り方と各設定値を徹底解説 [後編] -Webクリップとは何か(3)-

WebのショートカットであるWebClipをMDMから配布すれば、事実上の審査不要・無制限配布可能なネイティブアプリ(擬似)を実現することができます。

(研修資料より)

特に iOS 16.4 で Web Push 通知に対応した点は注目に値します。ネイティブアプリを開発する理由として頻繁に上がってくる Push 通知が、JavaScript だけで実現できるようになったのです。もし iOS16.4 以降を前提にできるなら、

「Push 通知を使いたいならネイティブアプリ開発が必要」

という常識(?)は今や非常識となり、時代遅れな認識です。開発しようとする業務用iOSアプリが、

• 審査を回避したい事情があり、
• Push通知ぐらいしかネイティブアプリ開発する理由が無く、
• 端末の原則オンラインが担保できるなら、

WebClip + MDM の組み合わせ技は有力な選択肢になります。以下の投稿も合わせてご覧下さい。

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

読者がもしネイティブは無理だがモダンな Web システム開発は可能な開発会社だという場合、WebClip は顧客への提案に使える新たなツールとなります。「Web技術だけでインストールから起動からユーザ体験までほぼアプリっぽいことができますよ」と言えるのです。これを機会に MDM + WebClip のあわせ技を学習することをお勧めします。

以上、Appleの審査を回避する手段を4種類紹介しました。諸事情や諸条件によって採れる選択肢は変わってきますが、すべての選択肢を知っておくことは有用でしょう。本投稿が、読者の関わるアプリ開発プロジェクトの開発方針決定に役立てば幸いです。

(MDMはブラウザから操作するのが基本だが…)

しかし、ポチポチとクリックしたり入力することが非効率で面倒な場合があります。端末の初期登録や、プロファイルの適用、アプリのインストール等々、毎回同じことを繰り返していることはないでしょうか。

そういった定形処理を自動化すると、省力化やヒューマンエラー回避というメリットを享受できます。ということで本稿では、MDM操作の自動化に際して検討できる選択肢について紹介します。

MDMサービス側が提供するAPIを使う

MDMに限った話ではありませんが、何らかのシステム操作を自動化する際に最初に検討すべきはAPIです。

APIとは、ブラウザを開いて人間が操作をしなくても、システムを操作したのと同じことをプログラムで実現するためのものです。プログラムの開発が必要ですが、一度開発すれば、10ステップの操作が1クリックで済むようになったり、毎回10分かかっていた作業が2分で済むようになったりします。

APIは省力化に欠かせません。

(APIを使えばシステム連携も可能となる。illustrated by Midjourney v5)

昨今のSaaS型のシステムはAPIを搭載していることが多く、MDMも例外ではありません。多くのMDMサービスがAPIを標準で提供しています。以下に代表的な例をAPI資料のURLと一緒に示します。

これらのMDMを使用しているなら、リンク先のAPI資料を見ながら自動化プログラムを開発し、日々のオペレーションを省力化することができます。自社に内製部隊を持たないのであれば、外注先の開発会社にAPI資料を示して相談すると良いでしょう。

上記以外の場合は、MDMベンダーに直接問い合わせてみることをお勧めします。有償か無償かはMDMサービスによりますが、APIを申請ベースで提供している場合もあります。(弊社がよく使う BizMobile Go! はこのタイプです)

APIが提供されていないMDMサービスの操作を無理やり自動化する

MDMによっては、そもそもAPIが存在しない場合があります。また、存在していても条件が満たせず提供して貰えないとか、APIではカバーできない操作を自動化したい場合もあります。

そのような時に使えるのが、ブラウザ自動操作の仕組みです。APIと違い、ブラウザを(プログラムで)自動で立ち上げて、(プログラムで)クリックや入力を行わせることで、本来人がやるブラウザ操作そのものをプログラムにやらせる方法です。

数年前に流行ったRPAはこれに類するものです。既に社内で何かRPAツールを導入しているのであれば、ブラウザ操作の自動化は容易い筈ですので、そのRPAツールをそのまま使用しましょう。

RPAツール未導入なら以下のようなツールを使って、自前で開発することができます。

• Selenium
• Puppeteer
• Playwright

いずれもブラウザの自動化を様々なプログラム言語で実装できるツールです。歴史のある順に並べていますが、これから開発するなら Microsoft が開発している Playwright がオススメです。

(Playwright のAPI。.NET でも使えることが分かる)

前述のAPIと同様に、社内に開発部門がなければ、外注先にMDM操作を自動化したい旨を伝えると良いでしょう。ちなみに弊社では、MDMのAPIでカバーできない処理を、Playwright を使って自動化して省力化しています。

本稿ではMDM操作の自動化について紹介しました。

APIにしても、ブラウザ操作の自動化にしても、プログラムで制御できるということは、MDM操作に付随する周辺業務も併せて自動化できる可能性があるということです。(書類の作成やメール送信等)

生産性の高い企業は、適切で効果的な省力化をして、人が本来やるべきことに注力できるようにしています。日々のMDM操作も省力化できるポイントが多くあるものですので、本稿を参考に是非、自動化を検討してみて下さい。

(Apple at Work のサイトでは管理端末として MacBook が映っていることが多い)

ということで本稿では、業務でiOS端末を導入することになった場合の管理業務用Macのお勧めチョイスと、その購入方法について紹介します。以下目次です。

• 全てのMacがiOS端末管理用途に十分すぎるスペック
• 価格と使い方で選ぶと選択肢は2つに絞り込める
• 中古のMacではダメなのか？
• Macを買わないという選択肢はあるのか？
• Macはどこで購入すべきか？

順に見ていきましょう。

全てのMacがiOS端末管理用途に十分すぎるスペック

ものすごく乱暴に書くと、2023年3月時点で Apple が公式に販売している Mac であればどんな Mac でも構いません。Mac のラインナップには、

• Mac Pro
• Mac Studio
• MacBook Pro
• MacBook Air
• Mac mini

等がありますが、いずれも端末管理の用途としては十分すぎるスペックを持っています。本サイトをご覧頂くと分かりますが、iOS端末管理用途で必要なことは、

1. MDMの操作
2. Apple Configurator の操作
3. 独自業務用アプリのビルドや再署名 (極めて稀)

ぐらいで、いずれを行うにもスペックが不足することはまずないからです。従って、スペックの心配はさておいて、価格と使い方の両軸で選択すると良いでしょう。

価格と使い方で選ぶと選択肢は2つに絞り込める

使い方とは、iOS端末管理の業務をどのように行うか…です。管理業務においてiOS端末とどのように向き合うことになるのかで選ぶべきMacが異なります。

また、前節で「今売ってるものならどんな Mac でも構いません」と書いた通りどれでも良いわけですから、価格が安いほうが良いにきまってます。というわけで、買うべき Mac は以下2通りに絞り込むことができます。

MacPro, Mac Studio, MacBook Pro は、驚くほど高額でかつ、iOS端末管理業務に使うにはオーバースペックにも程があるという水準なので、通常は選択肢には入りません。

それぞれの最低モデルの価格(税込)は2023年3月時点で以下の通りとなっています。

Apple 製CPU (Apple Silicon) の世代を選択できるようになっていますが、2023年春時点で最新のCPU(M2)にする必要はありません。Apple Silicon であるという時点で一世代前のM1であっても管理業務には超高スペックです。

(MacBook Air の購入でM1かM2かを選ぶ画面。M1でも十分高性能)

CPUを決めると次にメモリ/SSDの容量で選択肢が現れますが、いずれも変更不要です。デフォルトの最小スペックで十分です。

(いわゆるBTOができるが基本的には不要)

メモリを増設しないと Apple Configurator が快適に動作しない…なんてことはありませんので、安心して最低スペックのものを選んで下さい。また冒頭で書いた「3. 独自業務用アプリのビルドや再署名」の少し開発よりっぽい作業が必要な場合であっても十分です。

なお、価格優先で後者の Mac mini にする場合、いわゆるデスクトップ型なので、モニター・キーボード・マウスorトラックパッド等の周辺機器が必要になります。予備が社内にあるなら、それを使えば初期コストを安くできます。

(Mac mini は本体のみ。入出力装置は全て別途揃える必要がある)

iOS端末を導入後に、どのような管理業務体制となるかを考えて、ノート型にするかデスクトップ型にするかを決めましょう。BESTチョイスをあげてくれと言われれば、個人的にはノート型で最安価の M1 MacBook Air (¥134,800) です。

中古のMacではダメなのか？

ダメ…ではありませんが、オススメはしません。

Apple は Microsoft と違い、容赦なく旧ハードウェア・旧OSを切り捨てていく企業です。対応の遅い企業に配慮して InternetExplorer のサポート期間を何度も延命した Microsoft とは、根本的に思想が違う事を十分認識しておく必要があります。

Apple は古いものを使い続けることをよしとせず極力最新のものを使うことを要求します。公私ともに約20年Apple製品を使い続けている筆者の感覚的には、OSは2,3世代前まで、ハードウェアは5,6世代前までがサポート範囲です。

(2023年3月時点で最新のmacOSのサポート対象一覧。5,6年程度までがサポート範囲)

MicroSoft のほうが法人に優しい、Appleは厳しい…ということではありません。Apple が古いものを切り捨てるのはセキュリティの為です。購入したMacを長く使えるように、またセキュリティのために、管理業務用Macはなるべく新規に購入することをお勧めします。

中古Macを購入した場合には、以下のような困った事態になる可能性が高いことも覚えておくと良いでしょう。

• しばらくは中古Macで管理業務ができる
• ある年から新しいmacOSにアップデートできなくなる (最新OSの対象ハードウェアから除外される)
• 結果、新しいmacOSに対応した Apple Configuratorを使えない (Apple Configurator も古いOSを除外する)
• 結果、新しいiOS端末を適切に管理できなくなる (欲しい設定を含む構成プロファイルを作れない等)

数年前のモデルを中古で購入すれば、この状況に陥る年月が早く到来するということです。その点も考慮して本当に中古にするか検討して下さい。もし、導入しようとするiOS端末が2,3年の有期限的な用途だといった事情があるなら管理業務用Macは中古でも十分でしょう。

Macを買わないという選択肢はあるのか？

MDMでほぼ全ての管理業務を行うことができますので、Macを買わないという選択肢を完全には否定しません。有りといえば有りでしょう。

(ぶっちゃけMDMだけで管理業務はできる)

ただ Macを社内に置かないということは、管理業務でApple Configurator を使わないことを意味しますので、以下のような不自由を強いられることになります。

• 端末に流し込む構成プロファイルを作成しにくい
• 端末を監視モードに変更しにくい
• 端末をDEP(ADE)端末に変更しにくい

特に、後ろ2つの監視モードとDEP(ADE)は昨今の業務用端末では MUST な設定ですので、正直 Apple Configurator を全く使わない運用は厳しいものがあると考えます。以下も参考にして下さい。

• iOSの監視モードとは何か (Supervised Mode)
• DEP(Device Enrollment Program)とは何か
• SDE, ADP, DEP, ABM, ADE…名称がコロコロ変わる端末登録の歴史

有事の際のサポートスピードや、柔軟な対応ができるかどうかに影響を与えますので、Mac無しでのiOS端末管理業務は余りお勧めしません。円滑な管理業務はメーカ標準・メーカ推奨で揃えてこそです。また、Apple Configurator に触れることで、管理業務スキルが身につくという一面も忘れてはなりません。

結論はこうです。

iOS端末管理業務に十分精通している人が「ウチならMDMだけで十分だ」と判断できる場合を除き、iOS端末導入で初めてApple製品を導入する企業は、管理業務用のMacを必ず購入すべきです。

Macはどこで購入すべきか？

色々と選択肢が考えられますが、自社に都合の良いスタイルを選ぶと良いでしょう。以下に主だった選択肢を列挙します。

• (A) 家電量販店で購入する
• (B) Apple Store Online で購入する
• (C) Apple Store (リアル店舗) で購入する
• (D) Apple正規販売代理店(Apple VAR) に発注する
• (E) 自社専用の Apple Store Online を用意して貰って購入する

会社のルール上、現金やカード決済が難しく、買掛けの請求書払いしかできないなら (D) か (E) です。もしこちらのページに普段IT関連機器調達先としている企業があるなら、そこに依頼するのが一番手っ取り早いでしょう。

Apple と直接やりとりがしたい場合は (B) か (C) か (E) です。(C) のリアル店舗なら、各店舗に法人部門の方がいますので、店内スタッフの方に法人として購入したい旨を伝えると対応してくれます。場合によっては (E) を用意してくれたりもしますので尋ねてみると良いでしょう。ちなみに弊社は (E) です。

(弊社専用に用意して貰った Apple Store Online。ヘッダ部分に「for FEEDTAILOR INC.」と弊社名が明記されている)

また、購入ではなくリースという手段もあります。

が、一般のリース会社からのMac調達は需要と供給のバランスから高額過ぎるため推奨されません。唯一オススメできるのは、Apple Financial Service の利用です。車の残価設定付きリースのApple製品版と言えるサービスですね。

(再販価値の高いApple製品だからこそできる残価設定付きリース)

条件が厳し目ですが、国内であれば Too さんが窓口になりますのでこちらを参考に問い合わせてみると良いでしょう。

以上、管理業務用のお勧めMacについての紹介でした。iOS端末を初めて業務に導入する場合は、Macの同時購入が強く推奨されます。参考にして頂ければと思います。

PUSH通知はMDMの技術的な基盤。PUSH通知証明書の更新漏れはMDMが事実上機能しなくなることを意味します。ですから、エンドユーザも、導入を提案したSIerやアプリ開発会社も、MDMのPUSH通知証明書が遅滞なく確実に更新されるよう最大限の注意を払う必要があります。

(MDMはPUSH通知で端末を叩き起こし、MDMから命令を受信させることで動作する)

予めPUSH通知証明書の更新の仕方や注意点を知っておけば、いざその時が来ても戸惑うことはありません。そこで本稿ではMDMのPUSH通知証明書をどのように更新するのか紹介します。

MDM用PUSH通知証明書を更新する手順

以前の投稿でMDM導入初期にPUSH通知証明書の取得が必要になると書きました。が、初期だけではなく毎年更新が必要となります。

通常、PUSH通知証明書の更新時期が迫ってくると、MDMサービス側から担当者宛に連絡が届いたり、MDMサービスのログイン後画面の一番目立つ位置にその旨が警告表示されたりします。

(上図は期限切れしてしまった場合の BizMobile Go! のダッシュボード。この状態になってはいけない)

MDMのPUSH通知証明書は以下の手順に沿って更新します。上図のようにならないよう、有効期限が切れる前に必ず行って下さい。具体的な画面はMDMサービスによって異なりますが、基本的にやることは一緒です。

(1) MDMサービスにログインしてCSRファイルを取得する

(2) Apple Push Certificates Portal に、PUSH通知証明書を新規取得した時と同じAppleIDでサインインする。

(3) 証明書一覧が表示されるので複数個ある場合は “Vendor” や “Expiration Date” の欄を参考にして特定して [Renew] をクリックする。

(4) 次の画面でMDMサービス側から取得したCSRファイルをアップロードする。Notes欄には日付等のメモを書いておくと良い。

(5) 新しい証明書が発行されるのでダウンロードする。

(6) MDM側に(4)で取得した新たな証明書をアップロードする。

(BizMobile Go! でPUSH証明書の更新アップロードに成功した様子。次の証明書期限が表示される)

このようにMDMサービス側に受理されたら更新完了です。11ヶ月後ぐらいに再び関係者に通知が飛ぶよう、社内カレンダー等でリマインダー登録しておくことをオススメします。

なお、Apple Push Certificates Portal でのPUSH通知証明書の発行には回数制限等がありません。３ヶ月毎や半年毎といった短期更新をしても技術的には問題ありませんが、意味も余りありませんのでやはり11ヶ月程度の周期が良いでしょう。

MDM用のPUSH証明書更新時に一番間違えやすいこと

PUSH通知証明書の更新に失敗する原因のほぼ100%が、Apple Push Certificates Portal に対する理解不足にあります。Apple Push Certificates Portal で証明書が取得できれば何でも良いわけではない点に注意して下さい。

(更新用のPUSH証明書を取得してもMDM側にアップロードできないことがある)

MDM用のPUSH証明書には識別子があります。更新に際しては、その識別子が一致していなければ例えApple Push Certificates Portalで正しく取得した証明書であっても、MDM側がアップロードを受け付けてくれないのです。

識別子はMDMサービスからダウンロードする .csr ファイルと Apple Push Ceritificates Portal にサインインする AppleID に紐づきます。必ず、

• 最初にPUSH証明書を作成した時と同じAppleIDでサインイン
• 初めて作成した時のPUSH証明書を明示的に選択してCSRをアップロード

この2点を守りましょう。PUSH通知証明書がうまく更新できない場合、これができてないことがほとんどです。

(研修資料より。適切なCSRファイルでもAppleIDが違えば取得した証明書は不正となる)

繰り返しになりますが、MDM用のPUSH通知証明書更新の際は必ず初回取得時のAppleIDでサインインしましょう。

もし読者がまだMDM未導入の方なら、MDMのPUSH通知証明書の初回取得時AppleIDは、決して個人のAppleIDにしないようにして下さい。その個人が退職した時に非常に面倒くさいことになります。

正しいPUSH通知証明書を確実に取得する方法

MDM用PUSH通知証明書を更新する手順の(3)で [Renew] ボタンをクリックすると書きました。

この一覧の [Renew] ボタンの左側にある情報ボタンをクリックすると、以下のように証明書の詳細がポップアップ表示されます。

ここに記載されている Serial Number や Subject DN が証明書の識別子。MDMサービス側ではこれを使って同一性をチェックしています。MDMサービス側にもこれらの情報が表示されている場合は、両者の一致を確認することで、正しい証明書更新になっているのか確認することができます。

(上図はBizMobile Go!のPUSH通知証明書詳細画面)

また、PUSH通知証明書を発行してダウロードした後でも、証明書ファイルそのものから識別子を確認することもできます。

macOS環境ならFinderのQuicklook機能を使うと良いでしょう。PUSH通知証明書(.pemファイル)を選択してスペースキーを押すと、以下のような表示が現れます。

一番上の Subject Name の値がMDMサービス側の証明書情報の値と一致していれば問題なくアップロードできる筈です。

もしターミナルでが使える環境なら、openssl x509 コマンドで証明書ファイルの中身を以下のように確認することもできます(-inでファイルを指定、-noout -subject オプションで出力指定)。普段からコマンドライン操作に慣れている方はこの方法が楽でしょう。

PUSH通知証明書の更新でエラーが出たりうまくいかない場合は、ここで紹介したように証明書が持っている固有の値を参照して照らし合わせると問題の原因を特定し易いです。

以上、MDMのPUSH証明書の更新方法について紹介しました。遅滞なく証明書を正しく更新し、MDMを安定稼働させられるようにしましょう。

(Xcodeから.ipaを生成する画面。種類を選び正しく署名ができれば生成に成功する)

本稿では、主要な方法からマイナーな方法まで、.ipa ファイルを端末にインストールする方法を全8種類ご紹介します。詳細を記した投稿へのリンクも載せていますので併せてご覧下さい。

まずは最初に一覧です。

以下で順に見ていきます。

MDM

業務用iOSアプリの .ipa ファイルを語る場合、真っ先にあがるのがMDMを使ったインストールです。端末を集中管理して、情シス部門等の管理部門側からアプリのインストールや削除をコントロールしたい場合に向いています。

(MDMに.ipaファイルを登録する画面。このあと端末を紐付けるとインストールされる)

MDMサービス上にアップロードした .ipa ファイルは、複数端末に一斉インストールすることができます。

厳密には、MDMから端末に .ipa ファイルのパス情報(マニフェスト)が送られ、iOS端末が当該 .ipa ファイルをダウンロード&インストールする流れとなります。MDMがipaファイルを直接送りつけるわけではないことに注意して下さい。

対象となる端末が監視モードの場合は、ユーザの手元端末操作が不要となり、強制的に .ipa ファイルをインストールさせることができます(サイレントインストール)。これはMDMを選択する大きなメリットの一つと言えるでしょう。MDMについては以下をご覧下さい。

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

またMDMサービスによっては、InHouse に限らず AdHoc の .ipa ファイルも登録できる場合があります。以下を参考にして下さい。

• MDMではInHouseアプリだけでなくAdHocアプリも配布できる

Apple Configurator (Mac)

MacとiOS端末を有線接続してインストールする方法です。端末を都度回収して保守するとか、管理部門やアプリ開発会社の担当者が現地に赴いてメンテする運用で向いています。

Apple Configurator は有線版MDMとでも言うべきMac用端末管理アプリケーションで、.ipaファイルのインストール以外にも色んな事ができます。残念ながらWindows用はありません。詳しくは以下を参考にして下さい。

• Apple Configurator とは

Apple Configurator は、大量の端末を集中管理するのには向いてませんが、Macに端末をUSBで繋いで .ipa ファイルをドラッグ&ドロップすれば即インストールを完了できるというお手軽さがあります。

.ipa ファイルのインストールを含む一連の定型作業を自動化できるブループリントという、気の利いた機能も備わっています。

(Apple Configurator の操作マクロのようなものを作り、端末に適用できる)

もし、Apple Configurator 以外の他のアプリケーションや社内システムとの連携などを含んだ自動化をしたい場合、後述の cfgutil がお勧めです。

MDM と Apple Configurator はどちらを使うべきか…と排他的に考えるものではなく、安定運用時はMDM、導入初期や検証・障害対応時は Apple Configurator、という合わせ技がお勧めです。

OTA

自社内Webサーバに .ipa ファイルを置き、iOS端末の Safari から URL アクセスしてインストールして貰う方法です。従業員等のユーザに端末から直接インストール操作をさせたいような運用に向いています。

(研修プログラムの資料から)

分かり易く表現すると、OTAの仕組みを使えば自社内でオレオレAppStoreを構築できます。Webサーバは自社に都合の良い形で構築することができ、Xcode が生成するマニフェストファイルと一緒に .ipa をアップロードするだけ…と手順は非常に簡単です。

OTAについては詳しくは以下の投稿を参考にして下さい。

• OTA(Over The Air)とは何か

MDMのように、自動再インストールや自動アップデートのような気の利いた管理系の仕組みは備えていません。それらの機能が必要な場合は、MDMの導入を検討して下さい。

Xcode (Mac)

余りないと思いますが、Apple Configurator はインストールがされていないが Xcode はインストールされているというMacから .ipa ファイルをインストールしたい場合に役立つ方法です。

Xcode内で使える Devices and Simulators から .ipa ファイルをインストールできます。

(Xcodeのメニューから [Window] → [Device and Settings] で表示される画面)

一覧からデバイスを選び、.ipa ファイルを INSATALLED APPS の欄にドラッグ&ドロップするだけです。AppID (Identifier)や詳細なバージョン番号が表示され、.ipa ファイルに関しては Apple Configurator より詳しい情報を得ることができます。

cfgutil (Mac)

Apple Configrator に付属しているコマンドラインツールを使う方法です。UIを触るまでもない場合や、自社内で自動化スクリプト等を開発していて、一連の自動化処理の中に .ipa インストール処理を組み込みたいような場合に有効です。

シェル操作やサーバ管理に慣れている方でないと使いこなせませんが、使いこなすと非常に便利です。cfgutil については以下をご覧下さい

• Apple Configurator 付属のコマンドラインツール cfgutil の使い方

AirDrop (Mac)

AirDrop は、Bluetooth で互いを認識・識別し、WiFi を使ってデータを送受信するmacOS / iOS に標準搭載されている無線データ転送技術です。この AirDrop を .ipa ファイルのインストールに利用することができます。

Apple Configurator も Xcode もインストールしていないMacから、手元のiOS端末に .ipa ファイルをインストールしたい場合に向いています。追加のソフトウェアや、端末との有線接続も不要なので、最も手軽なインストール方法と言えます。

(OS標準の機能。サイドバーで AirDrop を選び、インストールしたいデバイスのアイコンに向けて .ipa ファイルをドラッグ&ドロップ)

上図のようにFinder のサイドバーからAirDropする方法と、.ipa ファイルを直接右クリックして AirDrop する方法とがあります。

詳しくは以下をご覧下さい。

• ADEPのInHouseなipaファイルをmacOS標準機能を使ってインストールする

Finder(Mac)

macOSに標準搭載されている Finder を使う方法です。Apple Configurator や Xcode など、管理系・開発系の macOS 用ソフトウェアを一切インストールしていない Mac で .ipa をインストールしたい場合に向いています。

(Macに有線接続したiPhoneをFinderで選択し、.ipaファイルを直接ドラッグ&ドロップ)

前記の AirDrop を使う方法と違い、無線ではなく有線になってしまう点には注意が必要です。

ただ、後述の Windows で iTunes を使って .ipa をインストールするのと同じようなことを Mac でやる方法なので、Mac を全く知らない方に案内するには最適かも知れません。

iTunes(Windows)

Windows 環境で使える唯一の方法です。前述の MDM も OTA もなく、Windows PC しかない環境で .ipa ファイルをインストールする場合に役に立ちます。

WindowsにUSBでiOS端末を接続し、iTunesのサイドバーのデバイス一覧に .ipa ファイルをドラッグ&ドロップするとインストールできます。

ただ、この方法はやむを得ず使う…程度の臨時的手法です。常用は推奨されず、前述のMDMやOTA、またはApple Configurator等のMacを使った運用体制を構築することをお勧めします。iOS端末を業務活用するなら Windows に縛られるべきではありません。

かつては、Apple Configurator の前身としてiPhone構成ユーティリティなるソフトウェアが Win/Mac の両方で提供されていました。WIndows でも iTunes を使わずに .ipa ファイルをインストールすることができて便利だったのですが、2023年現在、Windows用iPhone構成ユーティリティは公式には存在しないことになっています。ダウンロードできる野良サイトもありますが、弊社では利用を推奨していません。

以上、InHouse や AdHoc の .ipa ファイルを端末にインストールする方法を全8種類ご紹介しました。

業務用iOSアプリの運用現場では MDM と Apple Configurator、場合によってはOTA。この3つでほぼほぼ事足りますが、手段を一通り知っておくといざというときに役立ちます。是非頭の片隅にとどめておいて下さい。