宣言型デバイス管理とは何か？（2026）

宣言型デバイス管理（DDM）は、デバイスがサーバーからの指示を待たずに、ローカルで独自の設定を適用できるようにするAppleのフレームワークです。WWDC 2021で発表されたこの機能は、MDMサーバーとAppleデバイス群との間の通信モデルを根本的に変革します。

macOS、iOS、またはiPadOSデバイスを一定規模で管理している場合、DDMは2010年にMDMが導入されて以来、Appleデバイス管理において最も重要なアーキテクチャの転換点となります。 本ガイドでは、DDMとは何か、技術的な仕組み、従来のMDMとの位置づけ、そしてAppleによる非推奨スケジュールが迫る前にどのような対応が必要かについて解説します。

従来のMDMにスケーラビリティの問題がある理由

DDMが存在する理由を理解するには、DDMが置き換えるプロトコルにどのような問題があるのかを理解する必要があります。従来のMDMはポーリングモデルに基づいて動作します。サーバーがコマンドを送信し、デバイスがそれを実行し、デバイスが結果を報告し、サーバーが次のコマンドを送信します。 ステータス確認、設定のプッシュ、ソフトウェア更新の指示のすべてが、このリクエスト・レスポンスのループを経由します。

デバイスが50台程度であれば、これでも問題ありません。しかし、5,000台になると、サーバーは数千件もの同時チェックインに対応しなければなりません。 50,000台のデバイスになると、インフラを管理するためだけにインフラを管理することになってしまいます。また、このモデルはコンプライアンス上のギャップも生み出します。MDMサーバーに接続できないデバイスは、単に設定を更新できず、サーバーは次回のチェックインが成功するまで、その設定のずれに気づくことができません。

さらに、より微妙な問題もあります。 従来のMDMは、デバイスの観点から見るとステートレスです。デバイスは、自身の「意図された状態」を「認識」していません。単に、コマンドが届くたびにそれを実行するだけです。ユーザーがMDMチェックインの間に設定を変更した場合、サーバーが再度ポーリングを行い、修正を指示するまで、デバイスはコンプライアンス違反の状態のままとなります。

プロトコルレベルでのデバイス管理の仕組みを理解する上で、このポーリングアーキテクチャこそが、DDMが解消を目指している中核的な制約です。

宣言型デバイス管理の仕組み

DDMは管理モデルを逆転させます。サーバーがデバイスに段階的に何をすべきかを指示する代わりに、サーバーはデバイスに意図された状態の完全な記述を送信します。デバイスはその記述をローカルに保存し、サーバーとのライブ接続がなくても自律的にその状態を適用します。

実際の動作は以下の通りです。従来のMDMでは、構成プロファイルをインストールするには、サーバーがコマンドを送信し、デバイスからの応答を待ち、プロファイルのインストールを確認し、エラーを処理する必要があります。一方、DDMでは、サーバーは「このデバイスはこの構成を持つべきである」という宣言を送信します。 デバイスは、その状態を実現し、継続的に維持する責任を負います。

ユーザーが管理対象の設定を削除した場合でも、デバイスはサーバーを待たずに即座にその設定を復元します。デバイスが3日間オフラインの状態であっても、宣言された状態の適用を継続します。再接続時には、ステータスチャネルを通じて、オフライン期間中に何が起きたかを報告します。

3つの柱：宣言、ステータスチャネル、拡張性

AppleのDDMアーキテクチャは、3つのコンポーネントに基づいています。Appleデバイスを扱うすべてのIT管理者は、これら3つすべてを理解する必要があります。

宣言

宣言とは、デバイスがどのような状態であるべきか、どのような動作を行うべきかを記述した構造化されたJSONドキュメントです。宣言には4つのタイプがあります：

• 構成宣言：デバイス上の具体的な設定を定義するもので、従来のMDMにおける構成プロファイルに相当するが、ローカルに保存・適用される。例としては、パスコードポリシー、Wi-Fi設定、VPN構成などがある。
• アセット宣言：設定を有効化するために必要な認証情報や証明書など、宣言が依存する外部リソースを参照します。
• 有効化宣言：設定をいつ適用すべきかを決定する述語を定義します。例えば、「デバイスが企業のIDプロバイダーに登録されている場合にのみFileVaultを適用する」といったものです。この条件付きロジックは、サーバーではなくデバイス上で実行されます。
• 管理宣言：デバイスの登録プロパティやMDMサービスの構成など、登録レベルに関する情報を扱います。

有効化宣言における述語システムは、DDMの最も強力でありながら過小評価されがちな機能の一つです。どのデバイスにどの設定を適用するかを決定するロジックをサーバー側で実行するのではなく、そのロジックをデバイス自体に委ねます。 財務部門のスコープに登録されたデバイスは、ローカルで評価された基準に基づき、一般業務部門のデバイスよりも厳格な暗号化設定を自律的に適用することができます。

ステータスチャネル

ステータスチャネルは、DDMの非同期レポートメカニズムです。デバイスは、ポーリングスケジュールに従うのではなく、重要な変更が発生した際にステータスレポートをサーバーに送信します。デバイスが宣言の適用に成功した場合はその旨を報告し、アクティベーション述語の状態が変化した場合はその旨を報告し、ソフトウェアの更新がインストールされた場合はその旨を報告します。

ITチームにとって、これはデバイス群の可視性に対する考え方を変えるものです。スケジュールに従ってステータスを取得する代わりに、変更イベントのストリームを受け取ることになります。 デバイスインベントリは、デバイス群の規模に比例したサーバー負荷を発生させることなく、ほぼリアルタイムで最新の状態に保たれます。10,000台のデバイス群では、15分ごとに10,000回のチェックインが行われるのではなく、変化が生じた際にのみステータストラフィックが発生します。

これにより、コンプライアンス監視も一変します。従来のMDMでは、チェックイン時に設定の逸脱が判明します。一方、DDMのステータスチャネルでは、デバイスが設定の逸脱を検知して修正した、あるいは自己修正できない逸脱を検知したことを、それが発生した直後に通知します。

拡張性

拡張性により、DDMフレームワークは、AppleがOSのリリースを通じて追加する新しい宣言タイプをサポートできるようになります。Appleが新しい管理機能を導入するたびにプロトコルの変更を必要とするのではなく、拡張性によって、新しい設定やステータスタイプを追加するための標準化されたメカニズムが提供されます。

これは長期的な計画において重要です。AppleがDDMのサポートを拡大し続ける中で、MDMプラットフォームは根本的なアーキテクチャの変更を必要とせずに、新しい宣言タイプを採用できます。MDMベンダーを評価しているITチームにとって、拡張性の原則に基づいてネイティブにDDMをサポートするプラットフォームは、Appleの管理APIが進化しても、維持管理が格段に容易になります。

宣言型デバイス管理と従来のMDMの比較

DDMと従来のMDMの実用的な違いは、実際のデバイス群を管理するITチームにとって重要な形で、日々の運用に影響を及ぼします。

共存関係について明確にしておく価値があります。DDMは、少なくとも現時点では、従来のMDMを完全に置き換えるものではありません。登録済みデバイス上では、これら2つのプロトコルが並行して動作します。特定のアクションは依然としてMDMコマンドによって処理され、登録フローでは従来のMDMチャネルが引き続き使用されており、一部の機能はまだDDMに移行されていません。 Appleは、ソフトウェアアップデート、制限、および特定の設定に関する従来のコマンドがiOS/macOS 26以降で非推奨となることを示唆しており、今後これらの機能を利用するにはDDMが必須となる。

DDMのOSバージョン要件

DDMのサポートは、特定のApple OSリリースに紐づいています。DDMを基盤とした管理ワークフローを構築する前に、管理対象デバイスのOS構成を確認してください：

• iOS 15 / iPadOS 15 / macOS 12 Monterey：DDMのサポートが導入された
• iOS 16 / iPadOS 16 / macOS 13 Ventura：宣言タイプの拡張、DDM によるソフトウェア更新管理
• iOS 17 / iPadOS 17 / macOS 14 Sonoma：構成宣言の追加、ステータス報告機能の改善
• iOS 18 / iPadOS 18 / macOS 15 Sequoia：継続的な拡張；廃止予定となるレガシーMDMコマンドの追加
• iOS/macOS 26 以降：主要なレガシー MDM コマンドの非推奨化；ソフトウェア更新の強制および追加の設定タイプにおいて DDM が必須となる

管理対象のデバイス群に古いOSバージョンを実行している端末が含まれる場合、移行期間中はハイブリッドなアプローチが必要となります。iOS 15またはmacOS 12より前のバージョンの端末はDDMを一切使用できず、無期限にレガシーMDMコマンドを必要とするか、あるいはそれらの端末をサポート対象ハードウェアから除外する計画を立てる必要があります。

企業のコンプライアンスにおけるDDMのセキュリティへの影響

DDMの自律的な適用モデルは、純粋なデバイス管理の観点からは明らかではない、セキュリティ態勢に直接的な影響を及ぼします。

従来のMDMでは、デバイスのコンプライアンス状態は前回のチェックイン時点のスナップショットに過ぎません。午前9時にセキュリティ設定を変更し、午後9時にチェックインしたデバイスは、12時間にわたりコンプライアンス違反の状態にあったことになります。 NIST SP 800-53やmacOS向けのCISベンチマークといったフレームワークの下で運用される規制環境では、たとえ一時的であっても、そのギャップは制御の失敗とみなされます。

DDMはこのギャップを解消します。デバイスが自ら宣言した状態を継続的に強制するため、コンプライアンス違反から是正までの時間は数時間ではなく、数秒単位で測定されます。ステータスチャネルがイベントを記録することで、タイムスタンプ付きの逸脱状況と是正措置を示す監査証跡が得られます。

アクセスの許可または拒否をデバイスのポスチャー信号に依存するゼロトラストアーキテクチャにとって、これは極めて重要です。IDプロバイダーやSSOゲートウェイなどのポリシーエンジンに対してコンプライアンスを主張するデバイスは、正確なポスチャーデータを提供する必要があります。 DDMの継続的なローカル強制とリアルタイムのステータス報告を組み合わせることで、ポーリングベースのチェックでは達成できないレベルの信頼性をデバイス・ポスチャー信号に与えることができます。

これは、より広範なエンドポイントセキュリティ戦略に直結します。デバイス管理とセキュリティを、別々の機能ではなく統合された分野として捉えている場合、DDMのアーキテクチャはまさにその統合モデルに合わせて設計されています。

DDM によるソフトウェア更新の強制

ソフトウェア更新管理は、企業のITチームにとってDDMの利点が最も即座に実感できる分野であり、Appleのサポート終了スケジュールによって最も緊急性が生じている分野でもあります。

従来のMDMでは、特定のmacOSバージョンを強制するには、サーバーが更新コマンドを送信し、デバイスがそれを受信確認し、デバイスが更新をダウンロードして準備し、サーバーがポーリングして成功を確認するという一連のプロセスが必要です。スケジュールされた時間帯にデバイスがオフラインの場合、更新は実行されません。ユーザーが更新を延期した場合は、サーバーが別のコマンドを送信するという手順に戻ることになります。

DDMは、「ソフトウェアアップデート」の設定宣言を通じてソフトウェアアップデートを処理します。管理者は、許容されるOSの最低バージョンを宣言します。デバイスはその宣言と自身の現在の状態を照合し、条件が満たされた時点で自律的にアップデートプロセスを開始し、ステータスチャネルを通じて状況を報告します。オフラインになった後、再接続したデバイスは、サーバーがコマンドを再発行する必要なく、中断した箇所から再開します。

全デバイス対象の更新キャンペーンにおいて、これは保留中のMDMコマンドのキューを管理する必要がないことを意味します。意図を一度宣言するだけで、デバイスは設定されたパラメータの範囲内で、それぞれのスケジュールに従ってコンプライアンス状態へと収束していきます。

DDMの活用事例：IDプロバイダーとSSOの統合

DDMの述語システムが企業に大きな価値をもたらす分野の一つが、IDコンテキストに基づく条件付き設定です。従来のMDMのスコープ設定は比較的粗く、デバイスグループやユーザーグループにプロファイルを割り当てる形でした。一方、DDMのアクティベーションでは、よりきめ細かな条件を評価することができます。

エンタープライズ環境における実用例：

• ディレクトリ属性に基づいて評価し、ユーザーアカウントに特権アクセス権があるデバイスに対して、より厳格なパスコード要件を適用する
• 特定のエンタープライズCA証明書アセットが存在する場合にのみ、証明書ベースの認証設定を適用する
• デバイスが特定のネットワークセグメントに接続されているかどうかに基づいて、VPN設定宣言を有効化する

これらの条件付き動作はデバイス上で実行されます。条件が変更されるたびに、サーバーがスコープの割り当てを再評価する必要はありません。デバイスが条件を追跡し、述語を再評価して、自律的に設定を調整します。

Iruによる宣言型デバイス管理へのアプローチ

IruによるDDMの実装は、後付けではなくネイティブに組み込まれています。IruはAppleの管理APIを基盤として構築されているため、DDM宣言は、レガシーなMDMエンジン上に重ねられた追加機能ではなく、プラットフォームが設定を配信する仕組みの中核をなしています。

数千台のMac、iPhone、iPadデバイスを管理するチームにとって、これはいくつかの具体的な領域で実用的な違いをもたらします。

第一に、Iruによるソフトウェアアップデートの強制実行では、サポート対象のOSバージョンについてDDM宣言が使用されます。つまり、デバイス数が増加しても、アップデートキャンペーンによってサーバー負荷が線形に増加することはありません。10,000台以上のデバイス規模では、ポーリングベースのアップデート管理とDDMベースのアップデート管理との違いは、インフラコストやITチームの作業時間において明確に測定可能です。

第二に、Iruのコンプライアンスエンジンは、デバイスのポスチャに関するデータソースとしてDDMのステータスチャネルを利用しています。デバイスがステータスチャネルを通じて構成変更を報告すると、そのシグナルはほぼリアルタイムでコンプライアンスダッシュボードに反映されます。これにより、セキュリティチームは定期的なチェックインを待つことなく、正確なポスチャデータを入手できます。

第三に、DDMおよびレガシーMDMの移行期間におけるIruのアプローチは、両方のプロトコルを並行して実行することです。Appleがサポートする場面ではDDMを、依然として必要とされる場面ではレガシーコマンドを使用し、ITチームがその区別を手動で管理する必要はありません。 AppleがiOS/macOS 26以降でレガシーコマンドのサポートを終了する中、IruのDDMネイティブアーキテクチャにより、移行にはプラットフォームの変更ではなく、設定の変更のみで済みます。

より広範な移行パスを検討しているチームにとっても、MDMプラットフォームを評価する際には、DDMのサポートに関するApple MDMの移行上の考慮事項を慎重に検討する価値があります。

DDMに備えてITチームが今すべきこと

現在Appleデバイスを管理しており、まだ管理戦略にDDMを取り入れていない場合は、以下の点に注力してください。

OSの配布状況を監査してください。DDMにはiOS 15／macOS 12以降が必要です。この要件を満たさないデバイスには、別の管理パスが必要となります。管理対象のデバイス数と現在のOSバージョンを明確に把握してください。これはハードウェアの在庫管理プロセスに直接影響します。

最優先のDDM活用シナリオを特定する。ソフトウェアアップデートの強制適用と継続的なセキュリティ設定は、最も有力な出発点となります。これらは、DDMの自律的な強制適用モデルが即座に測定可能な価値をもたらす分野です。

MDMプラットフォームのDDM導入状況を評価してください。具体的な質問を投げかけましょう。そのプラットフォームは、ソフトウェア更新にDDM宣言をネイティブに利用していますか？ステータスチャネルはコンプライアンスダッシュボードにリアルタイムで反映されていますか？一部のデバイスがDDMに対応し、一部が対応していないという移行期間を、プラットフォームはどのように処理しますか？iOS/macOS 26におけるAppleのレガシーコマンドの廃止に、プラットフォームはどのように備えていますか？

述語ロジックを計画してください。デバイス側の条件付きロジックへの移行には、設定の範囲設定について異なる視点での検討が必要です。「このデバイスはどのグループに属するか」という考え方ではなく、デバイスがローカルで評価する述語を設計することになります。構築を開始する前に、既存のポリシー構造をDDM宣言ロジックにマッピングしてください。

DDMの完全な対応を待たないでください。現在、DDMと従来のMDMは共存しています。利用可能で価値が得られる場所から、DDMの使用を開始してください。DDMが従来のMDMと完全に同等になるのを待っていると、今すぐ得られる運用上のメリットを逃すことになります。

IruのDDMネイティブプラットフォームは、エンタープライズ規模でのこの移行をサポートするように構築されています。御社の規模のデバイス群において、宣言型構成が実際にどのように機能するかを確認したい場合は、Iruまでお問い合わせください。