Swift 6.4.2のクラウド同期ディレクトリ署名失敗をどう受け入れる？2026ガイド

修正対象との一致度

Swift 6.4.2のリリースノートには、macOS 14以降でクラウド同期ディレクトリ内のビルドを行う際に発生するコード署名失敗の修正が記載されています。したがって、OSの範囲、ディレクトリの性質、失敗した工程が一致する場合は、修正候補として隔離試験する価値があります。(forums.swift.org)

ただし、これは「すべてのcodesignエラーが直る」という意味ではありません。証明書やキーチェーンの読み込み、署名対象の不整合、ネストされたコード、アーカイブ後の検証など、別の原因でも署名工程は失敗します。まず、エラーがビルド中の署名で起きたのか、Archive、Export、署名検証のどこで起きたのかをログから切り分けます。

CIが使うSwiftの実体

Xcode 27.2とSwift 6.4.2の関係

Swiftの公式発表は、Xcode 27.2にSwift 6.4.2が含まれると説明しています。一方、独立したSwiftツールチェーンもインストールできます。したがって、CI設定に「Xcode 27.2」や「Swift 6.4.2」と記載されているだけでは、実行時に選択されたコンパイラを確定できません。(forums.swift.org)

AppleのXcode対応表では、Xcode 27.2のコンパイラがSwift 6.4と表記されています。パッチ版を含め、特定のビルドジョブが実際に選択しているツールチェーンは、CI上のコマンド出力で確認するのが確実です。Xcodeの選択先と独立ツールチェーンの選択は別々に記録します。(developer.apple.com)

xcode-select --print-path
xcodebuild -version
swift --version
xcrun swift --version

xcode-select --print-pathは、コマンドラインツールが参照するDeveloperディレクトリを表示します。独立ツールチェーンを指定する設定がある場合は、環境変数TOOLCHAINSやxcrun --toolchainの有無もログに残してください。Appleの説明でも、アクティブなDeveloperディレクトリはxcode-select --print-pathで確認でき、独立ツールチェーンは別途選択できます。(developer.apple.com)

出力の版番号だけでなく、ジョブ内の作業ディレクトリ、環境変数、実行したビルドコマンドも保存します。Xcodeの画面で選択されているツールチェーンと、CIのシェルから呼び出すswiftが異なる場合もあるためです。

CIの実行パス

リポジトリが同期ディレクトリにあることだけを根拠に、署名対象も同じ場所にあると判断しないでください。ソース、Derived Data、Archive、Export先、署名対象のアプリやフレームワークを、それぞれ実パスで記録します。Xcode Cloudを含む環境では、ビルド用ディレクトリを示す環境変数も確認できます。(developer.apple.com)

pwd
printf 'DEVELOPER_DIR=%s\nTOOLCHAINS=%s\n' "$DEVELOPER_DIR" "$TOOLCHAINS"

ビルド条件を比較するときは、コミット、スキーム、署名設定、証明書、キャッシュ条件をそろえ、出力先だけを同期ディレクトリと非同期ディレクトリに分けます。リポジトリの場所を変える試験とDerived Dataの場所を変える試験を同時に行うと、どの差が結果に影響したのか判別できません。

署名結果と再現性の確認

成功判定は、ビルドコマンドの終了コードだけで終わらせません。ビルド、ArchiveまたはExport、署名検証を別々に記録し、どの工程まで完了したかを区別します。失敗した場合は、最初に署名エラーが現れた工程と、ログに表示された対象パスを保存します。

codesign --verify --deep --strict --verbose=2 "/path/to/App.app"

このコマンドは署名の検証に使えます。Appleのコード署名資料では、codesignによる検証と、ネストされたコードを含めて確認する方法が説明されています。ただし、検証コマンドの成功だけで配布工程全体が受け入れ可能とは限りません。実際に出荷するArchiveやExport済み成果物を、対象の配布手順に沿って確認します。(developer.apple.com)

ログ、ビルド成果物、署名検証結果は同一コミットに結び付けて保管してください。同期先の状態が変わったり、CI設定が後から更新されたりすると、版番号だけでは結果を再現できません。単発の成功はその実行条件での観測であり、継続運用で安定した証拠とは分けて扱います。

隔離試験の進め方

以下の順で、修正と失敗条件が結び付く証拠をそろえます。

• [ ] OSと失敗段階を記録する。 macOSのバージョン、ジョブID、エラー全文、失敗した工程を保存します。リリースノートに記載された対象OSとずれている場合は、同修正への該当を前提にしません。
• [ ] ツールチェーンを確定する。 xcode-select --print-path、xcodebuild -version、swift --version、xcrun swift --versionの出力を同じジョブのログに残します。
• [ ] 入出力パスを一覧化する。 リポジトリ、Derived Data、Archive、Export、署名対象それぞれの実パスを記録します。同期ディレクトリかどうかは、各パスごとに確認します。
• [ ] 同一コミットで経路を対照する。 ビルド設定と署名条件をそろえ、同期ディレクトリと非同期ディレクトリで実行します。出力場所だけを変えた試験を設け、差分が追えるようにします。
• [ ] 成果物の署名を検証する。 署名工程の終了コードとログに加え、ArchiveまたはExportされた実物にcodesignの検証を実行します。
• [ ] 結果を再試行で確かめる。 同じ条件の再実行で結果が変わらないか確認し、成功・失敗それぞれのログと成果物を保存します。成功が続かない場合は、恒久修正として扱わず、パスや署名設定を再調査します。
• [ ] 限定したジョブから適用する。 既存の本番ノードをすぐに置き換えず、隔離したジョブで確認した結果を基に、対象プロジェクトやRunnerを段階的に広げます。

受け入れ判断の比較表

修正範囲が一致し、同期ディレクトリ側で従来の失敗が再現し、ツールチェーン更新後に同じ条件で署名検証まで完了するなら、限定したジョブへの適用を検討できます。差が出ない、または失敗工程が変わらない場合は、パッチだけで解決したとせず、非同期パスでの運用や署名条件の調査を続けます。

macOS CIの移行先を選ぶ

現在のCIがLinuxのみなら、XcodeやmacOS上のコード署名を実行する工程は別途macOS環境で確かめる必要があります。共有のローカルMacは、利用者の作業とCIの負荷が競合しやすく、スリープやログイン状態、キーチェーンの扱いも運用上の確認点になります。既存のLinux環境は他の処理に活用しつつ、署名対象の工程だけを隔離したMac実行環境に分ける構成が現実的です。

まずはNodeMiniの案内で利用方法を確認し、短期の検証環境が必要か、継続利用を前提に自前のMacを用意すべきかを切り分けます。たとえばリリース前の再現試験や一時的なツールチェーン比較なら、Macを購入して保守するより、必要な期間だけリモート環境を使う選択肢があります。一方、物理デバイス接続が必須、あるいは長期にわたる固定負荷が中心なら、手元のMacや専用機の方が適しています。

現行のLinux CIだけではmacOS固有のビルド・署名工程をそのまま検証できず、共有Macではジョブと人の作業が競合し、ローカル端末では常時稼働や環境固定が難しくなることがあります。こうした制約のある検証期間だけ独立したMac環境を確保したい場合は、NodeMiniのMac利用案内を確認し、必要な作業経路と利用期間に合うかを判断してください。最初から本番CIを移すのではなく、対象ジョブを分け、ツールチェーン、パス、署名結果を同一コミットの証拠で比較するのが安全です。