Apple BusinessのMDMでは足りなかった——Mac環境でJumpCloudを検討して確認した7つのこと

▼ はじめに：Apple Businessを入れたのに、まだ足りない

ある会社でMDM/IDaaSの選定を担当した。Macが端末の約95%を占める100名規模の組織で、年間100名ペースで増えている環境だ。

2026年4月のApple Business統合をきっかけに、外部MDMなしでデバイス管理を回す方針でApple Businessを導入した。構成カタログの全19項目をレビューし、FileVault強制やパスワードポリシー、ソフトウェアアップデート制御など、基本的なセキュリティ構成は組めるようになった。

ただし、運用を始めてすぐに「これだけでは足りない」と感じる場面が出てきた。

決定的だったのは、上場準備で大手取引先のセキュリティチェックシートに回答する場面だ。「ID管理の方針は？」「退職時のアカウント無効化プロセスは？」「アカウント棚卸しの頻度は？」——こうした項目に対して、Apple Businessだけでは胸を張って回答できる状態ではなかった。

デバイスの構成管理はできても、IDとアクセスの管理はまったく別の話だった。そこから、MDMとIDaaSを統合的にカバーできるプラットフォームとしてJumpCloudの検討が始まった。

この記事では、Apple BusinessからJumpCloudへの乗り換えを検討する中で確認した観点と、実際にぶつかった論点を整理する。

▼ 前提：会社のIT環境

項目	内容
デバイス構成	Mac約100台（アクティブ）、Windows約3~5台
利用サービス	Google Workspace、Slack、Zoom、Notion
現行MDM	Apple Business（導入直後）
セキュリティ	CrowdStrike（NGAV）、HENNGE（DLP）、FortiGate
認証基盤	Google Workspaceが実質的なIdP

Active Directoryは使っていない。Google Workspaceのアカウントが事実上のマスターという、スタートアップではよくある構成だ。

▼ チェックポイント1：Apple Businessで「足りなかった」こと

Apple Businessの構成カタログは、デバイスレベルのセキュリティ設定としては十分に機能する。FileVault、Gatekeeper、パスワードポリシー、ソフトウェアアップデート強制——このあたりはApple Businessだけでカバーできた。

しかし、実際に運用してみると「デバイスの設定」と「ユーザーの管理」は完全に別のレイヤーだということが見えてきた。

やりたいこと	Apple Business	JumpCloud
FileVault強制＋エスクロー	○	○
パスワードポリシー	○	○
ソフトウェアアップデート強制	○	○
Gatekeeper制御	○	○
アカウント発行の自動化	×	○（API）
グループベースのポリシー適用	△	○
SSO（シングルサインオン）	×	○
退職時の全リソース一括無効化	×	○
Chrome Enterprise Enrollment Token配布	△ ※	○
パッチ管理（OS・アプリ）	△（OS更新のみ）	○
コマンド実行（リモート）	×	○
ソフトウェア配布	×	○

※Apple Businessでは、Chrome Enrollment Tokenの配布にカスタム構成プロファイル（com.google.Chrome のmanaged preferences）を使う必要があり、標準機能としては用意されていない。

特に運用で困ったのは以下の3つだ。

• ▶ 退職時のアカウント無効化：Apple Businessにはユーザーライフサイクル管理の概念がない。各SaaSを手作業で個別停止する必要があり、漏れが起きやすい
• ▶ ソフトウェア配布：全社に特定のアプリを一括配布したり、バージョンを統一したりする仕組みがない
• ▶ グループベースの制御：「開発チームだけにこのポリシーを適用する」といった柔軟なグルーピングが難しい

▼ チェックポイント2：OS別の機能差を最初に確認する

JumpCloudに限らず、MDM/IDaaS製品はどれも「Mac / Windows / iOS / Android / Linux 対応」と謳っている。しかし、OSごとにできることが結構違う。

JumpCloudのベンダーブリーフィングで確認したところ、以下のような差があることがわかった。

ゼロタッチキッティングの対応差

OS	ゼロタッチ対応	備考
Mac	○	Apple Business連携で対応可能。ABMにMDMサーバーとして登録すれば、ユーザーが箱を開けてWi-Fiに繋ぐだけでポリシーが適用される
Windows	△（単体では不可）	Microsoft Intuneとの併用が必要。エージェント手動インストール→接続キー入力→テナント紐付けが発生する

Windows端末が数台しかないこの環境では、Windowsのゼロタッチがないこと自体は大きな問題にならない。ただし、「Windowsも管理できます」という説明だけでは、この差に気づけない。

ポリシー管理の項目数

JumpCloudに確認したところ、設定できるポリシーの項目数はOSによって異なり、Macで約80項目、iOSで約40項目程度とのことだった。Apple Businessの構成カタログ19項目と比べると、カバー範囲の差は明確だ。

▼ チェックポイント3：Google Workspaceとの連携品質

Google Workspaceが認証基盤の組織にとって、IDaaS選定で最も重要なのはGoogle Workspaceとの連携品質だ。

ディレクトリ同期の方向

Google Workspace → IDaaSへの片方向同期か、双方向か。どちらがマスターになるか（ユーザー作成はどちら側で行うか）。この点は最初に確認しておく必要がある。

プロビジョニングの自動化

JumpCloudの場合、REST APIが公開されており、Google Apps Script（GAS）から POST /api/systemusers でユーザー作成が可能なことを確認した。Google Workspaceを使っている組織にとって、GASは最もアクセスしやすい自動化手段なので、この相性の良さは大きいポイントだ。

また、APIの認証にService Accountが使えるかどうかも重要だ。Service Accountであれば管理者個人のAPIキーに依存せず、かつライセンスカウントの対象外になるため、運用上の安定性とコストの両面でメリットがある。

▼ チェックポイント4：Entra ID連携の複雑さを甘く見ない

Active Directoryを使っていない環境でも、将来的にMicrosoft 365やEntra ID（旧Azure AD）と連携する可能性はゼロではない。

ベンダーブリーフィングで得た情報として、Entra IDとJumpCloudを連携させる場合、属性マッピングがかなり面倒になるケースがあるとのことだった。Entra ID側の属性とJumpCloud側の属性を突き合わせる作業が必要で、コツが要ると。

逆に、JumpCloud側で全ユーザーを直接管理し、APIでプロビジョニングを回す方式であれば、Entra IDとの複雑な連携を回避でき、シンプルな構成を維持できる。

▼ チェックポイント5：英語UIの運用負荷

地味だが無視できないのが管理コンソールのUI言語だ。

JumpCloudの管理コンソールは英語のみだった。ブラウザの翻訳機能で日本語表示はできるが、公式にサポートされた翻訳ではないため、設定項目の意味が不明瞭になるケースがある。

これは単に「読みにくい」という話ではなく、運用上のリスクだ。

• ▶ 設定ミスの可能性が上がる
• ▶ 他のメンバーへの引き継ぎコストが上がる
• ▶ トラブル時にサポートとのやり取りも英語になる

サポート体制の現実

JumpCloudのStandard（標準）サポートは米国マウンテン時間のビジネスアワー対応のメールのみだった。日本時間に換算すると深夜1時〜朝8時頃にしか返信が来ない。代理店経由であれば日本語サポートも可能だが、別途費用がかかる。

「情シスが自分1人しかいない」フェーズでは英語UIでも耐えられる。ただし、チームが拡大したときに引き継ぎのボトルネックになる可能性は頭に入れておくべきだ。

▼ チェックポイント6：ライセンス体系を正しく理解する

IDaaS/MDM製品のライセンス体系は、製品によってかなり異なる。JumpCloudで確認した観点を整理する。

課金単位：ユーザー or デバイス

JumpCloudは「1ユーザーあたり月額課金」で、1ユーザーに最大5デバイスまで紐付け可能というモデルだった。Mac＋iPhoneを持っている社員は1ユーザーとしてカウントされる。

一方、在庫や予備機などユーザーに紐付いていないデバイスはライセンスを消費しない。デバイス情報としては登録可能（PC台帳的に使える）だが、ユーザーとの紐付けが行われるまでは課金対象外だ。

パッケージ構成の違い

方式	特徴
単体ライセンス	機能単位で積み上げ（MDM $5 + SSO $3 = $8/user/月）
パッケージ	用途別にバンドル（デバイス管理／SSO／統合管理の3種）
プラットフォーム	ほぼ全機能入りのバンドル（$20〜$31/user/月）

MDMもSSOもやりたい場合、単体ライセンスで個別に積み上げるよりプラットフォームパッケージの方がコスパが良くなるケースがほとんどだ。ただし、「リモートアクセス機能はエッセンシャルズには含まれない」「条件付きアクセスは最上位プランのみ」など、プランごとに微妙な機能差があるので要確認。

▼ チェックポイント7：セキュリティチェックシートの回答力で評価する

選定の判断軸として意外と実用的だったのが、取引先のセキュリティチェックシートに対してどう回答できるようになるかという観点だ。

大手取引先のチェックシートの頻出項目を松竹梅フレームワーク（最低限／標準／理想）で整理した。JumpCloud導入によって回答が改善される項目を洗い出すことで、「なぜApple Business無料で済んでいるのに年間400万円かけるのか」を経営層に説明しやすくなる。

チェック項目	Apple Businessのみ	JumpCloud導入後
退職者のアカウント無効化プロセス	手作業で各サービス個別停止	ワンクリック一括無効化＋リモートワイプ
多要素認証の全ユーザー強制	各サービス側で個別設定	JumpCloud側で一括ポリシー適用
アクセスログの一元管理	サービスごとにバラバラ	Directory Insightsで統合可視化
デバイスへのソフトウェア配布	手動インストール	一括配布＋バージョン管理
アカウント棚卸しの実施	スプレッドシートで手動管理	API経由で自動取得可能

こうした改善項目をリストアップしておくと、ROI説明の材料になるだけでなく、トライアル時の検証ポイントも明確になる。

▼ まとめ：Apple Businessの限界と、選定時のチェックリスト

Apple Businessは「デバイスの初期設定と基本セキュリティ構成」を無料でカバーできる優れた基盤だ。ただし、組織が100名を超え、上場準備や大手取引先とのセキュリティ要件が求められるフェーズに入ると、IDとアクセスの管理レイヤーが決定的に不足する。

#	チェックポイント	確認内容
1	Apple Businessの限界	デバイス構成は足りるが、ID管理・アプリ配布・アクセス制御は守備範囲外
2	OS別の機能差	主要OS（Mac／Windows／iOS）でポリシー管理・ゼロタッチの対応状況は？
3	Google Workspace連携	ディレクトリ同期・API経由のプロビジョニング・GAS対応・Service Account対応は？
4	Entra ID連携の複雑度	属性マッピングの手間は？API直接管理で回避できるか？
5	英語UIの運用負荷	コンソール・サポートの言語は？引き継ぎへの影響は？
6	ライセンス体系	ユーザー／デバイス課金？パッケージの機能差は？年間コストの概算は？
7	チェックシート回答力	導入によってセキュリティチェックシートの回答がどれだけ改善されるか？

この後はトライアル環境での実機検証に入る。Apple BusinessからJumpCloudへの移行パスと、実際にポリシーを組んでみた結果は、また別の記事でまとめる予定だ。