Azure Pipelines macOS-14 下線：2026年企業移行の選び方

Azure Pipelines macOS-14 下線：2026年企業移行の選び方

結論：勝者は、ジョブを分流できる企業の混成構成です。 状態を持たない PR ビルドは、利用可能な托管 macOS イメージへ移行します。固定 Xcode、社内ネットワーク、製品署名を必要とするジョブは、自托管 Mac に残します。すべてを macOS-latest へ一括変更せず、macOS-14 の停止期間中に双軌で検証してから切り替えてください。

この記事は、macOS-14 をまだ指定している Azure Pipelines 管理者向けです。企業 IT、技術責任者、Xcode ツールチェーン、秘密鍵、リリース継続性を担当するチームも対象です。

Azure Pipelines macOS-14 下線移行で最初に分けるべきジョブ

Microsoft の計画では、macOS-14 の托管イメージは 2026年10月に brownout が予定され、2026年11月2日に削除される扱いです。これは通常のコンパイルエラーではなく、エージェントイメージを取得できないことによる停止です。日程と対象は、必ず公式の托管 Agent ドキュメントで再確認してください。

最初にリポジトリ全体から、次の指定を抽出します。

pool:
  vmImage: 'macos-14'

xcodeVersion: '指定値'

検索対象は vmImage だけではありません。Xcode の選択処理、Simulator Runtime、証明書インストール、App Store 配布タスク、社内パッケージレジストリの接続先も対象にします。

第1段階：タスク資産を固定する

各パイプラインについて、以下の項目を記録します。

  • 使用中のイメージタグと Xcode バージョン
  • Simulator Runtime と対象デバイス
  • Swift Package、CocoaPods、社内 SDK の取得元
  • アーカイブ、署名、配布の有無
  • 担当チームと変更承認者
  • 移行を止めている依存関係
  • 失敗時に戻す旧プールとブランチ

「Agent が起動した」という結果だけでは合格にしません。依存解決、コンパイル、テスト、アーカイブ、署名、配布物の検査までを一つの受け入れ単位にします。

標準 PR ビルドは新しい托管イメージへ移す

PR のコンパイル、単体テスト、静的解析が外部状態に依存しないなら、まず托管イメージで検証します。macOS-15、macOS-26 などの利用可否やプリインストールソフトは更新されるため、公式 runner-images の一覧と Azure Pipelines の対応表を同じ日に確認します。

候補の選択は、次の順序が安全です。

  1. プロジェクトが要求する Xcode と SDK を整理する。
  2. 候補イメージで同じコミットを実行する。
  3. 依存解決、コンパイル、テスト、アーカイブを比較する。
  4. キャッシュなしの初回実行と、通常のキャッシュ実行を分けて記録する。
  5. 失敗時に旧プールへ戻せる期限を決める。

托管 Agent は毎回クリーンな実行環境を用意します。ローカルに残る DerivedData、Simulator の状態、秘密鍵、手作業で入れたプラグインを前提にしたジョブは、そのまま移せません。キャッシュが効く場合でも、キャッシュキーに Xcode、SDK、アーキテクチャを含めないと、古い生成物を誤って再利用する可能性があります。

Apple Silicon を使う検証では、Intel と Arm64 の差を別の軸で記録します。ネイティブバイナリ、Homebrew の依存、シェルスクリプトのパス、Simulator の挙動が一致するとは限りません。

固定 Xcode と旧 SDK は自托管 Macへ残す

旧 Simulator Runtime、特定の Xcode 小版本、社内プラグイン、固定 SDK に依存するジョブは、macOS-latest へ移す優先度を下げます。最新版イメージに合わせてツールチェーンを変えると、再現可能だったビルドが崩れ、原因が SDK 変更なのか依存解決なのか分かりにくくなるためです。

次の条件に該当する場合は、自托管 macOS Agent を候補にします。

  • 製品リリースが特定 Xcode 小版本に固定されている
  • 旧 Simulator Runtime が必要である
  • 社内 Git、成果物保管庫、チケット基盤へ私網経由で接続する
  • 固定した出口 IP やファイアウォール許可が必要である
  • Keychain と製品証明書を専用ノードに限定する
  • Apple Silicon など、対象アーキテクチャを明示的に管理する

自托管 Agent は環境を細かく管理できますが、OS 更新、ディスク容量、再起動、監視、証明書の交換は企業側の責任になります。macOS Agent の公式説明にある実行ユーザーや権限の条件も、導入前に確認します。

注意：署名ジョブを「共有 Mac に置けば便利」と考えるのは危険です。秘密鍵が存在するノードでは、プロジェクト単位の許可、実行アカウント、ログへの秘密情報混入、ジョブ終了後のワークスペース消去を別々に検査してください。

Xcode 27 と Apple Silicon は本番置換ではなく互換性検証から始める

Xcode 27 の Arm64 イメージは、公式の個別説明にある状態とソフトウェア一覧を基準に判断します。プレビューや新しいイメージが利用できても、それだけで本番プールの置換条件を満たすわけではありません。Xcode 27 Arm64 イメージの公式リードミーでは、対応するツールとイメージ状態を確認できます。

検証時は、次の四つを分けて記録します。

  • ネイティブ Arm64 で依存ライブラリが解決するか
  • Simulator と実機向けアーカイブが完了するか
  • 署名後のアプリが配布先で受け入れられるか
  • 失敗時に既存の安定プールへ回退できるか

Microsoft-hosted Agent、按量で用意する托管 Agent、自托管 Apple Silicon Mac は同じものではありません。Agent Pool はジョブの論理的な振り分け先であり、実際の Mac 主機や署名ノードそのものではありません。この区別を設計書と YAML の両方に残します。

私網依存と製品署名は専用プールへ分離する

社内 Git、プライベートな成果物保管庫、固定出口、Keychain、製品証明書のいずれかがある場合、標準 PR ビルドと同じプールへ集約しない方が安全です。自托管ノードは便利ですが、複数プロジェクトのジョブが同じ秘密鍵へ到達できる設計では、障害時の調査範囲も漏えい時の影響範囲も広がります。

最低限、次の流れを図にします。

Pull Request
   └─ 一般ビルド Pool
       └─ 托管 macOS Agent

Release 承認
   └─ 署名 Pool
       └─ 専用自托管 Mac
           └─ Keychain / 製品証明書

そのうえで、Pool の利用許可、Pipeline の編集権限、サービス接続、実行アカウントを確認します。Microsoft のパイプライン安全ガイドは、秘密情報と実行権限を分離して管理する考え方を示しています。また、Agent の安全な運用条件は公式 Agent ドキュメントにも整理されています。

混成ノードの判断を対比表で決める

選択肢 向いているジョブ 強み 先に確認する失敗条件 回退先
新しい托管イメージ 状態を持たない PR、単体テスト、静的解析 クリーン環境、ホスト保守が不要 SDK、Xcode、Simulator の差 別の受け入れ済み托管タグ
専用自托管 Mac 固定 Xcode、私網依存、製品署名 環境と秘密鍵を限定できる パッチ、監視、再起動、消去 予備の専用 Mac
混成ノード Pool 日常ビルド、固定環境、リリースの併用 役割ごとにリスクを分離できる Pool 条件、権限、待ち行列 托管 PR ＋予備署名ノード

判断を急ぐ場合でも、最低五段階は省略しません。

  1. macOS-14 の指定箇所とツールチェーンを棚卸しする。
  2. PR 用、固定環境用、署名用にジョブを分類する。
  3. 新しい托管イメージと自托管 Mac で同じコミットを双軌実行する。
  4. 依存解決から配布物検査までの結果を比較する。
  5. Pool 権限、秘密鍵、私網経路を最小権限で検査する。
  6. brownout 中の失敗と再起動後の復旧を確認する。
  7. macOS-14 を無効化する承認条件と回退期限を記録する。

合格条件は、ビルド成功率だけではありません。排隊時間、ツールチェーンの一致、署名の再現性、障害からの復旧、運用担当者の対応時間を同じ記録票に残します。性能や費用を一般論で決めず、企業の実行履歴と契約条件から算出します。

FAQ の設計では、macOS-14 削除後の brownout と正式削除を分けます。macOS-15 と macOS-26 の選択も、番号ではなくプロジェクトの受け入れ結果で決めます。固定環境、私網、署名を必要とするジョブだけを自托管へ移し、托管 Mac と自托管 Mac を同じ Azure Pipelines 内の別 Pool として混在させる構成が基本です。

停止前の PoCから Mac 運用を選び直す

現在の構成が Microsoft-hosted Agent だけの場合、実行環境の変更を短期間で吸収しやすい反面、固定ツールチェーン、私網経路、署名用 Keychain、リリース集中時の待ち行列を同時に解決しにくい点があります。物理 Mac の購入だけで置き換える案も、調達期間、保守担当、故障時の予備、遊休時間という負担が残ります。

そのため、最初に実際の PR パイプライン一つと製品リリースパイプライン一つを選び、双軌 PoC を実施します。自社で Mac の保守要員や予備機をすぐに確保できない場合は、Mac のレンタル費用を比較する情報や、企業向け Mac 調達の選択肢も同じ TCO 条件で確認できます。

固定環境、私網、署名のいずれかが新しい托管イメージで合格しないなら、按周期で専用のリモート Mac ノードを確保する方が、全ジョブを無理に書き換えるより管理しやすい場合があります。SFTPMAC の Mac レンタルを候補にする場合も、先に必要な Xcode、接続方式、再起動後の復旧、証明書の保管責任、返却時の消去手順を PoC の受け入れ項目へ入れてください。

macOS-14 の指定を削除すること自体は移行の完了ではありません。新しい托管 Pool、自托管の固定 Pool、製品署名用の専用 Pool を実際の成果物で検証し、回退手順まで承認できた時点で、旧イメージを閉じるのが安全です。