症状 → 最速の対処：SwiftPM 6.4 ビルド成果物のパスを推測したり、.build 内の階層をハードコードしたりせず、実行するビルドと同じ条件で swift build --show-bin-path を使って実際の出力先を取得してください。 適用条件 → ビルドは成功しているのに、後続のコピー、テスト結果収集、署名、アップロードだけが失敗する場合は、まずパス解決と作業ディレクトリを疑います。

この手順は、Shell、Fastlane、Makefile、CIスクリプトを保守し、更新後に「成果物がない」と報告される開発者向けです。Swift Packageやプラグインの保守担当者、リモートMacのキャッシュとツールチェーンを管理するDevOps・リリース担当者にも適しています。

最終更新：2026年8月27日。SwiftPMの公式移行資料、Swift Build公式リポジトリ、Swift Evolution、Apple DeveloperのSwift資料を基に確認しています。Swift 6.4の独立した安定版リリース状況とXcode 27の提供段階は、導入時点の公式情報で再確認してください。

まず失敗地点を固定して証拠を残す

「コマンドは終了コード0なのに、アップロード対象のファイルが存在しない」という場合、コンパイル失敗と成果物の探索失敗は別の問題です。さらに、CIが想定する作業ディレクトリと、swift build が実行されたディレクトリが違えば、同じ相対パスでも別の場所を見ます。

最初に、次の情報を同じログへ保存してください。

  • 実行したコマンド全文
  • 実行時の作業ディレクトリ
  • swift --version と選択中の開発ツール
  • configuration、architecture、destination
  • swift build の終了コード
  • --show-bin-path が返した実際のパス
  • コピーまたはアップロード処理が参照したパス
SwiftPM 6.4ではSwift Buildが既定のビルドシステムになり、成果物の置き場所に関する従来の前提をCIインターフェースとして使い続けるべきではありません。変更点と移行上の注意は、[Swift Buildの公式移行ドキュメント](https://github.com/swiftlang/swift-package-manager/blob/main/Sources/PackageManagerDocs/Documentation.docc/SwiftBuildPreview.md)で確認できます。

スクリプトを出力パスの照会方式へ変更する

ShellやMakefileで、.build/arm64-apple-macosx/releaseのような文字列を直接組み立てている箇所を探します。Fastlaneのlane、アーカイブ用スクリプト、バイナリTargetの配布処理にも同じ前提が残っていることがあります。

ビルドとパス照会には、必ず同じ値を渡します。たとえば、対象プロダクトをプレースホルダーで表すなら、次のようにします。

CONFIG="release"
ARCH="arm64"
PRODUCT="<PRODUCT_NAME>"

swift build \
  --configuration "$CONFIG" \
  --arch "$ARCH" \
  --product "$PRODUCT"

BIN_PATH="$(
  swift build \
    --configuration "$CONFIG" \
    --arch "$ARCH" \
    --product "$PRODUCT" \
    --show-bin-path
)"

test -d "$BIN_PATH" || {
  printf 'output directory was not found: %s\n' "$BIN_PATH" >&2
  exit 1
}

cp "$BIN_PATH/<ARTIFACT_NAME>" "<STAGING_DIRECTORY>/"

destinationを指定する構成では、実際のビルドと照会の両方に同一のdestinationを渡します。configurationだけを合わせても、architectureやdestinationが違えば、照会結果を別タスクの成果物として扱う可能性があります。

CIでswift build --show-bin-pathを使うとき、どこを確認すべきですか。 --show-bin-pathは「推測したディレクトリ名」ではなく、指定したパッケージとビルド条件に対応するバイナリ出力先を返すために使います。出力を変数へ保存し、存在確認、対象ファイルの検査、コピーの順に処理してください。空白や改行を含む環境でも壊れないよう、Shell変数は引用します。

SwiftPMの公開コマンドと、内部実装のディレクトリ構造を区別することも重要です。Swift Package Manager公式リポジトリにない内部パスへ依存すると、ビルドシステムの更新時に再び断線します。

Packageとプラグインの成果物契約を点検する

Swift Packageの作者は、単に最終バイナリだけを確認してはいけません。ビルドツールプラグイン、バイナリTarget、リソース処理、スクリプトプラグインが、出力ディレクトリを自前で連結していないかを確認します。

各プラグインについて、次の証拠を残してください。

  • 入力ファイルとして何を受け取ったか
  • 出力ファイルまたは出力ディレクトリをどう宣言したか
  • 実際に生成されたファイルの一覧
  • 失敗時の標準エラー出力
  • 成果物を後工程へ渡す公開インターフェース
プラグインの出力を.buildの相対位置から再計算する実装は、公開されたコマンドの利用へ置き換えます。SourceKit-LSPの[公式補助スクリプト](https://github.com/swiftlang/sourcekit-lsp/blob/main/Utilities/build-script-helper.py)も、ビルド条件と生成物の扱いを考える際の実装例になります。

Swift Buildとnativeの違いが疑われても、すぐに権限やリモートMacの障害と決めつけないでください。公式のSwift Buildリポジトリと、出力ディレクトリ差異を扱う公式Issueを別の調査記録として参照し、ツールチェーン由来の既知問題と環境固有の失敗を分離します。

テスト結果とアップロード対象を別々に検証する

テスト処理では、実行ファイルの場所、テストランナーの結果、カバレッジ、ログの保存先を一つの固定ディレクトリとして扱わないでください。swift testの終了状態が成功でも、レポート収集側の検索条件が古ければ、CIは失敗します。

次の順序で確認します。

  • swift testを単独で実行し、終了状態を保存する
  • テストログの発生元と保存先を確認する
  • カバレッジを有効にした場合の生成物を個別に探す
  • 失敗したテスト名をログから特定できるか確認する
  • 最終的なアップロード対象をファイル単位で検査する
**Swift Buildとnativeの出力パスは同じですか。** 同じとは限りません。ビルドシステムが異なる場合、生成物の配置、テスト結果の構成、キャッシュの識別方法が一致する前提を置けません。Swift Buildを本番候補にするなら、同じコミット、同じ入力、同じ成果物検査をnative側にも実行し、差分をログで比較します。

CIキャッシュとリモートMacのノード条件を分離する

キャッシュキーにSwiftのバージョンだけを入れる設計では不十分です。少なくともビルドシステム、configuration、architecture、依存関係のロックファイルを識別情報に含め、新旧の出力ディレクトリが混ざらないようにします。

<
確認対象固定または記録する値失敗時に起きること
ツールチェーンswift --version、xcode-selectの状態異なるSwift Buildが同じキャッシュを読む
ビルド条件configuration、architecture、destination照会したパスと実成果物が一致しない
依存関係ロックファイルと解決結果古いPackageの生成物を再利用する
実行環境実行ユーザー、作業ディレクトリ権限または相対パスで収集に失敗する
清掃条件冷キャッシュ、既存キャッシュの扱い偶然残った成果物を成功と誤認する
ローカルでは成功し、リモートMacのCIだけアップロードできない場合は、まずこの表の実行環境とキャッシュを比較します。SSHで入れること自体は、CI実行ユーザーが同じファイルを読める証明にはなりません。

リモートMacのSwift開発環境とツールチェーン固定の手順を使い、xcode-select、実行ユーザー、作業ディレクトリをジョブの冒頭で記録すると、ノード間の環境差を追いやすくなります。

冷キャッシュから二重検証して切り替えを判断する

修正後は、既存キャッシュの上で一度成功しただけでは不十分です。新しい作業領域で、ビルド、パス照会、テスト、署名、コピー、アップロードを連続して実行します。その後、キャッシュありの再実行とノード再起動後の実行を行い、三つのログで出力先と成果物のハッシュを比較してください。

判断は次の基準にします。

  • [ ] 新しい作業領域で、ビルドと--show-bin-pathの条件が一致している
  • [ ] .buildの内部階層を直接参照する処理を削除している
  • [ ] バイナリ、テスト結果、カバレッジ、ログを別々に検査している
  • [ ] Swiftのバージョン、ビルドシステム、構成、アーキテクチャをキャッシュキーへ反映している
  • [ ] キャッシュなしで成果物を収集できる
  • [ ] キャッシュありでも同じ成果物検査を通過する
  • [ ] ノード再起動後にツール選択、権限、作業領域が復元される
  • [ ] Swift Buildとnativeで同一コミットの差分を保存している
  • [ ] nativeだけ成功した場合、最小再現と完全なエラーを保管している
Swift Buildだけが失敗し、nativeでは同じ条件で成功するなら、nativeへの切り替えは診断用の一時措置に限定します。公式資料では既定システムの変更と回避策が案内されていますが、[SwiftPMの変更説明](https://forums.swift.org/t/swiftpm-development-update-default-build-system-change/85548)を確認したうえで、対象の既知問題が解消したと判断できる条件を記録してください。

Swift 6.4が独立した安定版として扱えるかは、Swift Evolutionの公開状況で確認します。Xcode 27についても、Apple DeveloperのSwift資料と導入時点の公式リリース情報を照合し、ベータ版の挙動を本番互換性の根拠にしないでください。

既存のLinux CIや手元のMacで修正を急いで済ませる方法は、ノード再起動、実行ユーザー、macOS固有の署名環境を検証しにくいという弱点があります。物理Macを買って固定する方法も、検証用ノードを増やすたびに初期設定、保守、アイドル期間の費用が発生します。修正後の冷キャッシュと再起動試験だけを分離して確認したいなら、リセット可能なMACGPUのリモートMacを使う方が、既存の本番ノードを直接壊さずに検証しやすい選択です。

ただし、長期間の高負荷処理や物理ポートへの接続が必須なら、自前のMacが適しています。短期のSwiftPM 6.4移行、ツールチェーンの二重試験、リモートMac CIの復旧確認が目的なら、MACGPUのMacレンタル案内から利用条件を確認し、検証期間と撤退条件を先に決めてください。