Microsoft Intuneで無人運転のMacビルドマシンを管理できるか？2026年受入ガイド

MacビルドマシンがIntune上では正常なのに、再起動後にCIジョブを受け付けない状態になっています。

最短の解決策は、Microsoft IntuneでMacビルドマシンを管理しつつ、Intune単独で本番復旧まで保証しないことです。Intuneは端末の登録、セキュリティポリシー、FileVault、ソフトウェア配布、更新状態を担当し、構成自動化、CIサービス管理、遠隔復旧を別の層として検証します。

すでにMicrosoft Intuneで従業員向けMacを管理し、無人のXcodeビルドノードを同じ管理面に加えたいIT責任者向けの記事です。CI Agent、署名ノード、再起動後の復帰を担当するプラットフォームチームや、レンタルMacを候補にしている技術責任者にも適しています。

本番投入前に、次の4層を別々の合格条件として定義します。

Intuneの管理画面で「準拠」や「オンライン」と表示されても、CI Agentが正しいユーザーコンテキストで起動し、実際のジョブを完了できる証拠にはなりません。したがって、端末状態と本番ジョブの成否を同じチェック項目にまとめないことが重要です。

次の条件に該当する場合は、先に設計を戻します。

• 企業所有端末としての登録経路や責任者が決まっていない場合は、無人ノードの投入を保留します。
• FileVault回復後の操作経路がない場合は、暗号化ポリシーを本番へ広げません。
• CI Agentの再起動、再登録、ジョブ停止時の担当者が不明な場合は、Intuneだけでの運用を不合格とします。
• 署名用資格情報と一般的な管理スクリプトを同じ権限領域に置く場合は、署名ノードを分離します。

最初の工程は、端末を誰の所有物として、どの方式で企業管理へ入れるかの確認です。企業所有Macを自動登録する場合は、Automated Device Enrollmentの前提条件と設定を確認し、端末が企業のデバイス割り当て体系に入っていることを証拠化します。

一方、直接登録は、既存端末や限定的な検証環境で使える場合があります。適用条件が異なるため、macOSの直接登録に関するMicrosoftの手順と照合し、企業所有として扱う端末に個人向けの登録手順を混在させないようにします。

無人ビルドノードでは、ユーザーとの関連付けを必須にしない構成が候補になります。ただし、これは「ユーザーなしなら安全」という意味ではありません。構成プロファイルを端末側から勝手に削除できないか、デバイスグループの対象が想定どおりか、監視状態や登録方式が記録と一致しているかを確認します。

合格証拠は、管理画面のオンライン表示だけでは不十分です。端末レコード、登録方式、監視状態、適用済みポリシー、端末側ログ、意図的な設定変更後の修復結果を一式で保存します。

アカウント設計では、通常のローカル管理者、CIサービスアカウント、緊急時の復旧アカウントを分離します。従業員向けMacのログイン制限や休止設定を、そのまま無人ビルドノードへ適用すると、CI Agentのサービス起動やリモート復旧を妨げることがあります。

FileVaultは、暗号化の有効化だけでなく、回復キーの保管と再起動後の復帰まで確認します。Intuneのディスク暗号化設定については、FileVault設定の公式リファレンスを基準にし、回復キーが組織の監査要件を満たす場所へ保存されるか確認します。

AppleのAutomated Device Enrollmentにおける管理機能も参照し、監視状態や構成プロファイルの削除防止が、実際の端末ライフサイクルと一致しているかを検証します。

ネットワーク側では、ファイアウォール、プロキシ、証明書、社内リポジトリ、依存パッケージ配布先、成果物保存先を確認します。安全側にポリシーを寄せすぎると、Xcodeの導入、コード取得、依存関係解決、成果物のアップロードが止まるため、セキュリティ設定の適用前後で同じ接続試験を行います。

Intuneのシェルスクリプトやアプリ配布は、初期コンポーネントの交付に利用できます。ただし、1回成功したことを継続的な構成管理とみなしてはいけません。

macOSシェルスクリプトの公式仕様を確認し、次の項目を記録します。

• スクリプトがどのユーザー権限で実行されたか。
• 失敗時に管理面へどの状態が返るか。
• 同じスクリプトを再実行しても設定が壊れないか。
• Apple Silicon上でパス、権限、バイナリが期待どおりに動くか。
• Xcodeのバージョン選択、ライセンス初期化、追加コンポーネント導入を誰が管理するか。
• CI Agentの登録、サービス起動、停止、再接続をどの仕組みが担うか。

環境を意図的に変更し、ポリシー再適用や構成自動化によって元へ戻るかを確認します。端末ポリシーの適用結果だけでなく、主ホストのログ、実ファイルの権限、CI Agentの接続状態まで記録するのがポイントです。

最初の実ジョブでは、単純な疎通確認ではなく、企業プロジェクトのコード取得、依存関係の導入、コンパイル、テスト、成果物出力までを一続きで実行します。Intune適用前後で、CI Agentのアカウント、作業ディレクトリ、証明書アクセス権、成果物の所有者が変わっていないか比較します。

署名処理は一般ビルドと分離する設計が安全です。管理スクリプトが署名資格情報を読み取れる権限を持つと、端末管理の利便性と本番秘密情報の保護が衝突します。署名ノードを独立した権限領域へ置けない場合は、少なくとも資格情報の保管場所、使用ログ、ジョブ終了後の消去条件を受入項目に含めます。

その後、更新、通常の再起動、FileVault解除、ネットワーク切断、CI Agent異常終了を順番に実施します。Appleのソフトウェアアップデートをインストールして適用する方法に沿って更新ポリシーを確認し、更新状態の報告だけでなく、再起動後にジョブを再び受けられるかを検証します。

条件分岐による最終判定

• 端末登録、ポリシー適用、FileVault回復、実ビルド、再起動後のCI復帰がすべて証拠付きで確認できる場合は、分層管理で限定的に放量します。
• Intuneの端末管理は安定しているが、XcodeやCI Agentの再現性が不足する場合は、構成自動化を追加してから再試験します。
• 再起動後の復旧経路、署名権限、ネットワーク依存のいずれかが未確認の場合は、本番投入を保留します。
• IntuneだけでCIの復帰まで保証しようとしている場合は不合格とし、管理層を分離して受入計画を作り直します。

FAQ

Microsoft Intuneでユーザーを割り当てないMacビルドマシンを登録できますか？
可能性はありますが、登録方式と企業所有端末としての割り当て条件を先に確認する必要があります。無人ノードでは、ユーザーのサインインを前提にしたポリシーを避け、端末レコード、監視状態、構成プロファイルの適用結果を証拠として確認します。管理画面でオンラインに見えるだけでは受入完了とは判断しません。

IntuneのシェルスクリプトだけでXcodeとCI Agentを構成できますか？
初期導入の補助には使えますが、シェルスクリプトだけを構成管理の全体とみなすのは危険です。実行ユーザー、再実行時の冪等性、失敗時の状態、Apple Silicon対応、Xcodeのライセンス初期化、CI Agentのサービス管理を個別に検証し、継続的な差分修復は別の自動化層で設計します。

FileVaultを有効にしたMacを無人で再起動した後、どう復旧しますか？
FileVaultの暗号化設定だけで、再起動後のCI復帰まで自動化されるわけではありません。回復キーの保管先、Secure Tokenやボリューム所有者の関係、復号前後のネットワーク接続、CI Agentが再びジョブを受ける条件を隔離環境で確認します。遠隔操作だけに依存せず、失聯時の代替経路も用意します。

IntuneはmacOS CIノードの構成自動化ツールを置き換えられますか？
置き換えではなく、責任範囲を分けて併用する設計が現実的です。Intuneは端末の登録、ポリシー、暗号化、配布、更新状態を扱い、構成自動化はツールチェーンと依存関係、CIサービス管理はジョブ実行状態、遠隔復旧機構は失聯したノードの回復を担います。

最終的な調達判断では、端末価格だけでなく、管理設定、障害時の作業、更新検証、交換まで含めて比較します。自社所有ノードは物理的な管理権限を持ちやすい一方、設置場所、予備機、保守担当、遠隔復旧経路を自社で維持する必要があります。

現在の自社設置方式では、Mac本体の調達だけでなく、物理交換、予備機の保管、無人再起動後の現地対応が継続的な負担になります。一般的な仮想環境だけではApple SiliconやXcodeの実機条件をそのまま再現できない場合もあり、CIの再現性確認に別の検証費用が発生します。

そのため、Microsoft Intuneの登録・ポリシー検証を短期間で行うなら、JEXCLOUDの実機Macを隔離したPoCノードとして使い、管理権限、FileVault、更新、実ビルド、再起動復帰を同じ受入表で確認する方法が合理的です。JEXCLOUDのMacレンタル環境を候補に加え、必要に応じて申込み可能なMac環境で試験条件を確認してください。

最終的に、長期かつ高負荷の基幹ジョブを固定運用し、物理インターフェースや専用設備が必要なら自社購入が適します。一方、Intuneの無人登録や復旧手順をまだ検証できていない場合、いきなり本番設備を増やすより、JEXCLOUDの管理権限付きMacでPoCを行い、証拠がそろった構成だけをチームのノード群へ広げる方が、調達判断の失敗を抑えられます。

• Mac構築機を含むiOS CIの構成と受入判断を整理する
• SSH切断・ログアウト・再起動後も続くビルド運用を検証する
• ビルドノード更新前の互換性確認と段階的な検証方法を学ぶ