Azure DevOps macOS Agentは、通常のプロジェクトならまずMicrosoftのホステッドmacOS Agentを検証し、固定Xcode、永続キャッシュ、社内ネットワーク、管理可能な署名キーチェーンが必要な場合だけ、専用アカウントで動くリモートMacの自ホスト型Agentを選ぶのが安全です。AgentがOnlineになっただけでは本番投入とはみなせず、実ビルド、再起動後の復旧、署名情報の隔離まで確認してから運用へ移します。
この記事は、Azure PipelinesでiOSまたはmacOSアプリを構築・テストする開発者向けです。リモートMacをチームのAgent Poolへ常時接続したいDevOps担当者、証明書や配布プロファイルを管理するモバイル開発基盤の担当者にも適しています。
導入判断と責任範囲
Microsoftの説明では、ホステッドAgentはMicrosoftが管理する実行環境であり、自ホスト型Agentはチーム側がマシン、ツール、更新、アクセス権を管理する方式です。Agentの種類と役割の公式説明を先に確認すると、単に「Macで動かしたい」という理由だけで自ホスト化する判断を避けられます。
ホステッド環境を優先しやすいのは、外部から取り込んだコードを隔離して実行したい場合、毎回クリーンな環境で検証したい場合、Xcodeや依存ツールを固定する必要がない場合です。反対に、次のような条件が重なると、管理下のリモートMacを自ホスト型Agentとして検討する価値があります。
- 大きな依存キャッシュを継続利用したい
- 社内API、VPN、プライベートリポジトリへ接続する必要がある
- 特定のXcodeとmacOSの組み合わせを維持したい
- 署名用キーチェーンへのアクセス範囲を限定したい
- SimulatorやGUIテストのためにmacOSログインセッションを管理したい
ただし、自ホスト型Agentは信頼できないコードを実行する場所ではありません。Azure PipelinesのホステッドAgentに関する隔離と実行の説明およびパイプラインのセキュリティガイドに沿い、外部コードは権限を持つ署名ノードへ直接流さない設計が必要です。
| 判断条件 | ホステッドmacOS Agent | リモートMac自ホスト型Agent |
|---|---|---|
| ツールチェーン | 標準イメージで足りる場合 | 特定のXcodeや補助ツールを固定する場合 |
| キャッシュ | ジョブ間の永続利用を前提にしにくい | キャッシュを管理者の責任で保持できる |
| 内部接続 | 公開範囲の依存関係向け | VPNや社内ネットワークが必要な場合 |
| 署名 | パイプライン権限で制御 | Agent PoolとMacの権限を追加分離できる |
| 運用負担 | Microsoft側の管理範囲が広い | 更新、清掃、監視、復旧をチームが担う |
Agent Poolと実行アカウント
リモートMacを登録する前に、専用のAgent Poolと専用のmacOSシステムアカウントを用意します。管理者権限を持つ普段使いのアカウントでAgentを実行すると、ビルドスクリプトの誤動作や依存ツール経由のアクセス範囲が広がるため、通常の開発作業とCI実行を同じアカウントにまとめないことが重要です。
Pool名、Agent名、組織URL、作業ディレクトリ、認証トークンは例示値を使わず、Azure DevOps管理画面で生成された値を入力します。認証方式も固定せず、自ホスト型Agentの認証方式に関する公式資料をその時点の組織設定と照合してください。
| 登録項目 | 決める内容 | 初期確認の証拠 |
|---|---|---|
| Agent Pool | 署名用と一般ビルド用を分けるか | プロジェクト権限と利用対象 |
| Agent名 | ノードの用途が分かる命名 | 管理画面のOnline表示 |
| 実行ユーザー | 専用の低権限アカウント | プロセス所有者 |
| 作業ディレクトリ | 専用ボリュームまたは専用パス | ジョブ後の残存ファイル |
| 認証情報 | 管理画面が示す方式 | トークンや資格情報の保管場所 |
| Capabilities | Xcodeなどの実行能力 | Agent詳細画面と実コマンド |
登録直後に確認できるのは「Agentが接続された」という事実です。Agentのバージョン表示、能力一覧、実行ユーザー、作業パスを確認し、Agentとジョブのマッチングに関する公式説明にあるdemandsの考え方と一致させます。
常駐方式とmacOSセッション
純粋なコマンドラインのビルドやテストは、ログイン中のターミナルやSSHセッションから切り離して実行できる状態を作ります。SSH接続を閉じるとジョブも終了する構成では、ネットワーク瞬断や管理作業がそのままビルド失敗につながります。
MicrosoftのmacOS Agentサービス設定に従い、Agentのsvc.shでサービス状態を確認します。launchdのLaunchAgentはユーザーのログインセッションと関係するため、SimulatorやUIテストでは、単なるバックグラウンドサービスとして扱わず、画面セッション、キーチェーンのロック状態、ウィンドウサーバーへのアクセス条件を個別に確認してください。
常駐確認のチェック
- [ ] SSHを切断しても実行中のジョブが継続する
- [ ] macOSからログアウトした後、想定した種類のジョブが拒否されるか確認する
- [ ] 再接続後にAgentのサービス状態とログを確認する
- [ ] OSを再起動し、Agentが自動的にOnlineへ戻る
- [ ] SimulatorまたはUIテストでログインセッションの要件を満たす
- [ ] 一時的なSSH起動スクリプトに依存していない
注意：Online表示、疎通確認、サービス起動は本番受け入れの一部にすぎません。実際のXcodeジョブが正しい能力へ割り当てられ、再起動後にも成果物を生成できることまで確認してください。
Xcode能力と構築経路
Azure PipelinesからXcodeを実行する場合、Agentのcapabilityとパイプラインのdemandsが一致しなければ、該当ノードが空いていてもジョブは割り当てられません。Xcodeをインストールしただけで能力が正しく更新されるとは限らないため、切り替え後はAgentを再起動し、管理画面の一覧を再確認します。
最初は署名を含まない小さなテストプロジェクトを使います。次の順序で確認すると、Agent登録、Xcode選択、プロジェクト設定、署名の問題を切り分けられます。
xcode-select -pで選択中のDeveloperディレクトリを確認します。xcodebuild -versionで実行対象のXcodeを確認します。- 共有設定されたSchemeがコマンドラインから見えることを確認します。
xcodebuildによるビルドとテストを実行します。- テスト結果とビルド成果物がAzure Pipelinesへ保存されることを確認します。
- Xcodeを追加または切り替えた場合はAgentを再起動し、capabilityとdemandsを再照合します。
コマンドのオプションや利用可能な構成はXcodeの版によって変わるため、AppleのXcodeコマンドラインツール資料を基準にします。パイプラインのXcodeタスクを使う場合も、タスク入力を現在のAzure DevOps管理画面と公式仕様で確認し、古いサンプルをそのまま流用しないことが安全です。
署名情報の分離
署名なしの構築が成功した後に、受け入れ対象を限定した署名アーカイブへ進みます。Apple Developerの証明書、配布プロファイル、秘密鍵をリポジトリ、スクリプト、通常の変数へ直接埋め込む設計は避けます。
Azure PipelinesのSecure Filesの公式仕様では、保護されたファイルに対するパイプライン権限と承認を管理できます。Appleアプリの署名手順はMicrosoftのモバイルアプリ署名資料と照合し、誰がどのパイプラインから利用できるかを限定します。
署名ジョブの受け入れ条件
- [ ] 署名なしのビルドとテストが先に成功している
- [ ] 署名用Secure Filesの利用パイプラインが限定されている
- [ ] 署名用Agent Poolを一般の外部コード実行から分離している
- [ ] 一時キーチェーンの作成と削除をログで確認できる
- [ ] ジョブ終了後に証明書、プロファイル、秘密鍵のコピーが残っていない
- [ ] 失敗時にも後処理が実行される
- [ ] 配布先と公開権限が構築ジョブから分離されている
複数プロジェクトが同じMacを使う場合、キャッシュ共有の利点よりもワークスペースや署名情報の混在リスクが大きくなることがあります。非署名ビルドとリリース用署名ジョブを別Poolへ分け、必要であれば物理ノードも分離します。
長期運用の受け入れ条件
自ホスト型Agentは、登録後の保守まで含めて初めて成立します。ジョブ終了後に作業ディレクトリを清掃するのか、依存キャッシュだけを残すのか、同時実行を許可するのかを先に決めないと、後続プロジェクトの成果物や設定が混ざります。
以下の条件分岐で運用開始の判断を行います。
- 固定Xcode、内部接続、永続キャッシュ、管理対象の署名鍵が不要なら、ホステッドmacOS Agentへ戻します。
- 固定ツールチェーンだけが必要なら、署名用ジョブを載せず、専用の自ホストPoolで最小構成を運用します。
- 署名と公開まで必要なら、低権限アカウント、専用Pool、Secure Files、作業領域の清掃をすべて満たした場合だけ採用します。
- SimulatorやUIテストがログイン状態に依存するなら、launchdの状態だけで判断せず、ログアウトと再起動後の実ジョブを確認します。
- 失敗時の清掃、Agent更新、ディスク増加、復旧担当が決まっていないなら、採用を延期してホステッド環境へ戻します。
連続したビルド、意図的な失敗からの再実行、Macの再起動、Agent更新後の実ジョブを通して、キャッシュの残り方、作業領域の衛生状態、成果物の再現性を確認します。Online表示だけでなく、これらの証拠を記録できて初めて、チームの本番Poolに追加できます。
よくある導入上の疑問
FAQでは、登録方法だけでなく、Xcodeの能力ルーティング、再起動復旧、iOS署名の分離まで確認できます。各項目は、導入時の設定値を固定するのではなく、当日のAzure DevOps管理画面とMicrosoft公式資料を照合する前提です。
リモートMacを選ぶ前の費用と運用比較
短期検証では、既存のMacを使う方法が最も簡単に見えます。しかし、常時稼働、電源管理、回線、バックアップ、物理障害対応、社内アクセス制御まで担当する場合、購入したMac miniを自前で運用する案にも見えにくい管理コストがあります。
一方、リモートMacのレンタルでは、必要な期間だけmacOS環境を確保し、Agent Pool用の専用ノードとして切り出せます。利用可能な構成や契約期間は条件によって異なるため、RUVCLOUDのリモートMac構成とレンタル期間を確認し、長期固定運用と短期検証を同じ前提で比較しないことが大切です。
| 選択肢 | 向いている条件 | 見落としやすい負担 |
|---|---|---|
| ホステッドmacOS Agent | 標準ツールで外部コードを安全に検証したい | 固定環境や内部接続の制約 |
| 自社所有のMac | 長期の固定負荷、物理ポート、社内設備を使う | 保守、電源、回線、障害対応 |
| リモートMacレンタル | 期間限定のCIノード、固定Xcode、常時接続 | 接続経路、権限、清掃設計 |
| 仮想化環境 | 互換性検証や一時的な実験 | Appleプラットフォームの機能要件確認 |
macOS専用の実行環境を短期間だけ追加したい場合、購入機では初期費用と余剰期間が発生しやすく、一般的なLinuxサーバーではXcodeやApple署名工程を置き換えられません。固定Xcodeと専用アカウントが必要だと判断した段階で、RUVCLOUDの料金と利用条件を照合し、最小のテストPoolから始める方法が現実的です。
まとめと次の判断
Azure DevOps macOS Agentの導入では、登録作業よりも「どのジョブをどの権限で、どの状態のMacへ流すか」の設計が重要です。ホステッド環境で足りるプロジェクトはそこへ戻し、固定Xcode、内部依存、永続キャッシュ、署名隔離が必要な場合だけ、実ジョブと再起動復旧を証拠にして自ホスト型リモートMacを採用します。
自前のMacは物理保守、電源・回線管理、故障時の交換、未使用期間の費用が発生します。一般的なクラウドLinux環境もXcode、macOSのログインセッション、Apple向け署名工程をそのまま代替できません。固定されたCIノードを一時的または段階的に確保するなら、RUVCLOUDのリモートMacを専用アカウントとAgent Poolで試し、構成とレンタル期間を確認してから本番運用へ進めるのが堅実です。