Azure PipelinesでiOSアプリを構築する企業向けに、Apple Siliconのホスト型Agentと自托管Macをワークロード別に比較します。署名資産、社内ネットワーク、キュー、キャッシュ、運用責任を整理し、固定容量と弾力容量を組み合わせる混合構成の判断基準を示します。
Azure PipelinesでiOSアプリを構築する企業向けに、Apple Siliconのホスト型Agentと自托管Macをワークロード別に比較します。署名資産、社内ネットワーク、キュー、キャッシュ、運用責任を整理し、固定容量と弾力容量を組み合わせる混合構成の判断基準を示します。
本番リリースをAzure PipelinesのApple Siliconホスト型Agentへ一括移行するのは、2026年時点では避けるべきです。短時間の検証とビルドのピークにはホスト型を使い、安定した署名、専用ネットワーク、固定キャッシュ、高負荷の継続処理には自托管Macを残す混合構成が最も判断しやすい選択です。
本記事は、Azure DevOpsでiOSアプリを構築・配布し、Xcode 27に向けてApple Silicon容量を計画する開発生産性責任者向けです。署名資格情報、社内ネットワーク、データ保管場所、Agent費用を審査するIT・セキュリティ担当者と、購入・レンタル・ホスト型の組み合わせを決める技術責任者にも適しています。
先に確認すること：2026年8月20日時点で、Apple Silicon macOS Agentの公開プレビュー情報は確認されています。ただし、正式提供、SLA、価格、地域、イメージ範囲は固定情報として扱わず、公開前に必ず公式資料と実際の組織設定で再確認してください。
| ワークロード | 推奨する池 | 主な理由 | 合格させる証拠 |
|---|---|---|---|
| プルリクエストの一時ビルド | ホスト型 | 実行ごとの隔離と短時間利用に向く | 成功率、待ち時間、外部接続の遮断 |
| ベータ互換性確認 | ホスト型または検証用自托管 | XcodeとSDKの組み合わせを試しやすい | イメージ、Xcode版、ログの再現性 |
| 本番署名と配布 | 専用の自托管Mac | Keychain、証明書、Profileを固定できる | 署名分離、撤回手順、監査ログ |
| リリースピーク | 自托管の基準容量＋ホスト型 | 固定資源と弾力容量を役割分担できる | キュー、再実行率、ピーク時の処理時間 |
| 社内APIや非公開成果物を使う処理 | 接続を証明できる自托管Mac | 出口制御と内部経路を管理しやすい | 許可リスト、監視、データ滞留場所 |
ホスト型は「運用不要だから常に優れる」ものではなく、自托管Macは「高性能だから常に速い」ものでもありません。ジョブが一時的か、信頼できるコードだけか、署名資産を持つか、社内経路を必要とするかでAgent Poolを分ける必要があります。
Azure PipelinesのApple Siliconリソースは、従来のMicrosoft-hosted macOSイメージや、過去に停止されたmacOS 15 ARM64プレビューと同一視できません。GitHub-hosted AgentsをAzure Pipelinesから利用する構成も含め、公式のAgent種別と提供条件で、リソースの名称、状態、請求条件を個別に確認します。
AppleはXcode 27をBetaとして案内し、Apple Silicon Macでのみインストール・実行できる要件を示しています。Xcode 27 Release Notesに記載された状態は、正式版のサポート範囲やホスト型イメージの提供を保証するものではありません。
したがって、既存のIntel流水線を単純にApple Siliconへ置き換えるのではなく、次の順で互換性を確認します。
ここで重要なのは、Xcode 27への移行手順そのものではなく、同じソースと依存関係から同じ署名済み成果物を再現できるかです。Betaの段階で本番リリースを全面移行すると、Agent側のイメージ変更とXcode側の仕様変更を切り分けにくくなります。
プルリクエスト、外部コントリビューターのブランチ、ベータSDKの互換性確認、一度だけ必要な分岐ビルドは、毎回クリーンな環境を用意しやすいホスト型と相性があります。自托管Macに残ったワークスペース、認証情報、依存キャッシュを信頼できないコードへ公開しない点でも有利です。
ただし、実行場所が一時的であることは、本番SLAや特定地域でのデータ処理を意味しません。Microsoft-hosted Agentの地域やネットワーク挙動については、ホスト型Agentの地域に関する説明を確認し、Azure DevOps組織の地域だけからビルドノードの所在地を推測しないでください。
実装では、ジョブの入口で信頼境界を判定します。外部ブランチは署名処理、内部API、秘密変数、社内パッケージレジストリへ到達させず、成果物を検査した後にだけ受け入れ側の自托管Poolへ渡します。Azure Pipelinesのセキュリティに関する公式推奨事項も、権限、変数、Agentの共有範囲を確認する基準になります。
正式配布を担うジョブでは、持続的なKeychain、Apple Developerの証明書、Provisioning Profile、依存キャッシュ、専用の配布アカウントを同じ実行環境で管理する必要があります。ここでは「ジョブごとに初期化される」ことよりも、誰が、どの環境で、どの資格情報を使って署名したかを説明できることが優先されます。
自托管Macを選ぶと、環境を凍結できる代わりに責任も増えます。OSとXcodeの更新、Agentのアップデート、ディスクの清掃、証明書の撤回、故障時の再登録、ログ保全、遠隔復旧を自社側で設計しなければなりません。macOS自托管Agentの公式手順に沿って登録方法を確認し、登録後はAgent Pool単位でプロジェクトとパイプラインの利用範囲を制限します。
通常のテストジョブと署名ノードを同じ高権限Poolに置く設計は避けます。署名専用Poolは、承認済みブランチ、保護された変数、限定されたサービス接続だけを受け入れ、証明書を撤回した場合に別の環境へ切り替えられる復旧手順まで試験します。
プライベートなパッケージレジストリ、社内API、未公開ソース、輸出管理対象の成果物を扱う場合、ホスト型Agentが必要な経路へ接続できるかを先に確認します。出口IPの固定、VPNやプライベート接続、DNS、ファイアウォール、ログの保管場所が証明できないなら、ホスト型を本番経路に置くべきではありません。
特に確認する項目は次のとおりです。
条件を確認できない場合は、専用の自托管Macを内部経路の近くに置き、対象プロジェクトとパイプラインだけにPool権限を与えます。Azure DevOpsの権限設定は、GitHub-hosted Agentに関するFAQも参照しながら、ホスト型と自托管型を同じ信頼レベルとして扱わないことが重要です。
日常のビルド量が安定しない組織では、すべてを自托管にすると閑散期のアイドル容量が残り、すべてをホスト型にすると署名や内部接続の制約が残ります。現実的なのは、署名と通常の高頻度ジョブを自托管Macの基準容量へ置き、プルリクエストや一時的なピークをホスト型へ送る構成です。
YAMLテンプレートでは、ジョブタグや要求条件を明示します。たとえば、requires-signing、private-network、ephemeral-buildのように役割を分け、署名ジョブが弾力容量へ誤送信されない条件を先に定義します。ホスト型で作った成果物を自托管側で署名する場合は、受け渡すファイルの検査、ハッシュ確認、保存期限、再実行時の扱いも決めておきます。
コスト比較は、単純なAgentの分単価だけでは不十分です。次の項目を同じ期間の実績で比較します。
価格や利用地域は提供条件の変更を受けるため、公開価格だけで結論を固定しません。Azure Pipelinesの請求方式は、GitHub-hosted Agentsの公式説明と契約中の請求画面を突き合わせ、実際のキューと再実行の記録から拡張開始点を決めます。
短時間の検証、プルリクエスト、ベータ互換性確認には候補になりますが、公開プレビュー中のリソースを本番署名の唯一の基盤にする判断は避けるべきです。署名鍵、固定キャッシュ、社内接続、監査要件があるリリースは、独立した自托管Mac Poolを基準にし、公開情報を再確認してから段階的に併用します。
Xcode 27はApple Silicon Macでの動作が前提とされているため、既存のIntel環境をそのまま継続する前に互換性を確認する必要があります。短期テストならホスト型、署名、依存関係、社内API、再現性を固定するなら自托管Macが適しています。正式版の対応範囲は公開時点で再確認します。
自社証明書を使う本番配布、専用Provisioning Profile、内部パッケージレジストリ、固定したXcodeや依存キャッシュを必要とするジョブに適しています。一方、信頼できないブランチのコードを同じ高権限ノードで実行する設計は避け、プロジェクト権限とAgent Poolを分離して運用します。
請求されるビルド時間だけでなく、同時実行数、待ち時間、常時確保するアイドル容量、Macの保守工数、証明書対応、失敗時の再実行、監視と復旧を分けて集計します。実際のパイプラインログと請求情報を同じ期間で照合し、平均値だけでなくリリースピークも含めて比較することが重要です。
可能です。YAMLの条件、ジョブタグ、テンプレート、Agent Poolの要求条件を使い、プルリクエストや負荷の急増はホスト型、署名と社内接続を伴う公開処理は自托管へ振り分けます。共有Poolに高権限の署名ノードを混在させず、成果物と認証情報の受け渡しも明示的に設計します。
本番化を急ぐ前に、同じコミットをホスト型と自托管Macの両方で実行します。記録対象は、ビルド成功率、待ち時間、実行時間、依存キャッシュの有無、署名の分離、社内サービスへの接続、失敗時の再実行、Macへ再接続できるまでの時間です。
試験結果は、次のように判定します。
運用手順を固める際は、Azure DevOps向けMac環境の構築情報を確認し、専用Agentの登録、アクセス制限、復旧テストを別々の受け入れ項目として扱います。また、企業内のiOSビルド資源を購入だけで確保するか、Apple Silicon Macのレンタル構成を試験用に使うかは、実測した稼働率と保守担当者の工数を加えて判断します。
Xcode 27の正式版公開、Apple Silicon Agentの正式提供、macOSイメージタグの変更、価格や対応地域の変更は、再評価のトリガーです。公開情報は、Agentの提供形態に関する公式資料とAppleのリリースノートで更新確認し、最終判断は請求記録と自社のビルドログで行います。
現行のホスト型だけに依存すると、本番署名の環境固定、社内ネットワーク接続、キューの予測、プレビュー変更への追随を同時に負担することになります。反対に自社購入だけで基盤を作ると、ピーク外の空き容量、故障時の交換、OS・Xcode更新、証明書復旧を継続して抱えることになります。
そのため、まず隔離したApple Silicon Macを自托管Agentとして試し、実際のキュー、ビルド、再実行、復旧記録を取得する進め方が適しています。固定容量を購入するか、VNCMacのMacレンタル環境で試験・一時増強するかは、長期高負荷なら購入、容量を段階的に変えたい場合や検証期間ならレンタル、という条件で比較してください。レンタルが必ず安くなるとは限りませんが、判断に必要な実機の自托管データを先に得られる点に価値があります。
最後に、Xcode 27とAzure Pipelines Apple Siliconの状態を再確認し、署名を担う固定Poolと、変動する検証用ホスト型Poolの比率を決めます。価格表だけでなく、復旧責任とセキュリティ境界まで含めて比較できる状態になってから、本番の移行範囲を確定するのが安全です。
短時間の検証、プルリクエスト、ベータ互換性確認には候補になりますが、公開プレビュー中のリソースを本番署名の唯一の基盤にする判断は避けるべきです。署名鍵、固定キャッシュ、社内接続、監査要件があるリリースは、独立した自托管Macプールを基準にし、公開情報を再確認してから段階的に併用します。
Xcode 27はApple Silicon Macでの動作が前提とされているため、既存のIntel環境をそのまま継続する前に互換性を確認する必要があります。短期テストならホスト型、署名、依存関係、社内API、再現性を固定するなら自托管Macが適しています。正式版の対応範囲は公開時点で再確認します。
自社証明書を使う本番配布、専用Provisioning Profile、内部パッケージレジストリ、固定したXcodeや依存キャッシュを必要とするジョブに適しています。一方、信頼できないブランチのコードを同じ高権限ノードで実行する設計は避け、プロジェクト権限とAgent Poolを分離して運用します。
請求されるビルド時間だけでなく、同時実行数、待ち時間、常時確保するアイドル容量、Macの保守工数、証明書対応、失敗時の再実行、監視と復旧を分けて集計します。実際のパイプラインログと請求情報を同じ期間で照合し、平均値だけでなくリリースピークも含めて比較することが重要です。
可能です。YAMLの条件、ジョブタグ、テンプレート、Agent Poolの要求条件を使い、プルリクエストや負荷の急増はホスト型、署名と社内接続を伴う公開処理は自托管へ振り分けます。共有プールに高権限の署名ノードを混在させず、成果物と認証情報の受け渡しも明示的に設計します。