CI/CD 2026年10月18日 約20 分 fastlane リモートMac

fastlane scanはリモートMacでどうテストする?2026年ガイド

fastlane scanをリモートMacで使うiOS開発者とCI担当者向けに、環境準備からlane設定、初回実行、結果の保管、CI移行までを順にまとめます。Simulatorでの確認と実機検証を分け、試運転を本番運用へ進める判断材料を示します。

fastlane scanはリモートMacでどうテストする?2026年ガイド

fastlane scanをリモートMacで使うiOS開発者とCI担当者向けに、環境準備からlane設定、初回実行、結果の保管、CI移行までを順にまとめます。Simulatorでの確認と実機検証を分け、試運転を本番運用へ進める判断材料を示します。

手元では通るfastlane scanが、リモートMacではSimulatorの選択や結果保存で止まる。
最短策は、scanをテストの呼び出し役と捉え、Mac上のXcode、scheme、利用可能なiOS Simulatorを照合してから小さなテストを実行し、結果を回収してCIへ進めることです。実機による確認は別工程にします。

iOSプロジェクトのテストをfastlane scanで管理したい開発者と、リモートMacのビルドノードを運用するCI担当者向けです。
Macを常時保有しない個人開発者や小規模チームが、リモート実行を試す前の判断にも使えます。

01

fastlane scanのリモートMacテストで先に固める基準

fastlaneのscanはiOSテストを呼び出す仕組みであり、Mac環境そのものやテスト結果を代替するものではありません。公式資料ではrun_testsアクションとしてテストを実行し、CIから呼び出す手順も案内されています。したがって、まず遠隔Macでプロジェクトのテストが実行できることを確認し、その後に継続的インテグレーションへ接続します。fastlaneのiOSテスト実行ガイドとrun_testsの設定項目を、プロジェクトの構成と照らし合わせてください。

遠隔Macに接続できることだけでは、テストノードとして使えるとは限りません。作業開始前に、少なくとも次の条件を記録します。

  • 対象プロジェクトと依存関係の取得が完了し、既存のロックファイルに沿って環境を復元できる。
  • 指定するXcodeが選択され、プロジェクトのschemeとテスト対象がその環境で認識される。
  • 実行先として指定するiOS Simulatorが、遠隔Macで利用可能なデバイス一覧に存在する。
  • Rubyとfastlaneの管理方法がプロジェクト内で定まっており、ローカルと遠隔で同じ依存関係を使える。

fastlane scanを動かす前に、遠隔Macの何を確認しますか。
xcode-select -pとxcodebuild -versionで選択中の開発ツールを確認し、xcrun simctl list devices availableで利用可能なSimulatorを調べます。Rubyとfastlaneについても、プロジェクトが採用しているバージョン管理方法に従って確認してください。特定のXcodeやRubyの版を一律に指定するのではなく、リポジトリの設定とチームの基準を優先します。

依存関係の復元方法が個人のシェル設定だけに依存していると、SSH接続後やCI実行時にコマンドが見つからないことがあります。プロジェクトのロックファイルをコミットし、実行コマンドもチームで共有できる形にそろえるのが基本です。

02

初回設定からテスト実行まで

最初から全テストをCIへ流すのではなく、実際のテストschemeを使って小さく確認します。テスト計画を利用しているプロジェクトでは、その名前もプロジェクト側の設定に合わせます。Appleのテスト計画の構成に関する説明を参照し、既存のテスト構造を保ったまま呼び出し口を整えます。

fastlane scanがiOS Simulatorを見つけられない場合、最初に何を照合しますか。
まず、Fastfileに書いたデバイス名が、遠隔Macでsimctlが返す一覧と一致しているかを見ます。次に、選択中のXcodeとscheme、テスト計画を確認します。手元のMacで使えるデバイス名をそのまま遠隔側へ指定せず、実行ノードで実際に認識された対象を設定してください。

Fastfileには、再利用できるlaneとしてテスト実行を登録します。次の例では、プロジェクト名、scheme、テスト計画、デバイス名、結果保存先を置き換えてください。

lane :test do
  scan(
    scheme: "<SCHEME>",
    testplan: "<TEST_PLAN>",
    devices: ["<AVAILABLE_SIMULATOR>"],
    result_bundle: true,
    result_bundle_path: "<RESULT_PATH>"
  )
end

テスト計画を使わない場合は、testplanを省きます。デバイス指定や結果出力のオプション名と挙動は、導入中のfastlaneとプロジェクト構成に合うことを、公式のrun_testsパラメーター一覧で確認してください。設定例をコピーしただけで実行先や成果物の場所まで確定したと考えないことが重要です。

初回は、プロジェクトの小さなテスト対象を指定してlaneを実行します。プロジェクトでBundlerを使っている場合は、たとえば次のようにロックされた依存関係を通して起動します。

bundle exec fastlane ios test

続けて、テスト対象を段階的に増やします。出力は「依存関係の解決」「ビルド」「Simulatorの起動」「テストの実行とアサーション」に分けて記録してください。コマンドが開始したことだけでは成功と判断できません。fastlaneの出力に加えて、Xcode側のテスト結果と失敗箇所を確認します。

03

失敗時の証拠を保管する

テストが失敗しても原因をあとから確認できるよう、結果の出力先を明示し、CIのログと結果ファイルを保存対象にします。AppleのXcodeコマンドラインツール資料では、コマンドラインからのテスト実行方法が説明されています。また、Appleはテスト結果を実行内容の確認に使えるXcodeのテスト実行・結果解釈ガイドを公開しています。

テスト失敗後も、CIで結果ファイルを残すにはどうしますか。
テスト実行が失敗しても後続の保管処理が動くように、利用中のCIで「失敗時にも実行する」成果物保存ステップを設定します。ログ、指定した結果ファイル、対象コミット、実行したlaneを同じ実行記録にひも付け、ダウンロード後に開けることまで確認してください。アップロード方法や保存期間はCI環境とチームの運用基準に合わせます。

結果ファイルが生成されたことと、チームがあとから取得・閲覧できることは別の確認項目です。保存先のパスが実行ごとに変わる場合は、CIの保管設定がその出力を拾えるかを確かめます。ログだけ残して結果ファイルを取りこぼす構成や、テスト失敗時に保存処理までスキップする構成は、試運転の段階で修正します。

結果ファイルの保存設定を足した後は、成功時だけでなく意図的な失敗時にも、ログと結果を回収できるかを確認します。テストを起動できたという記録だけでは、失敗の再調査に必要な情報が揃ったとは限りません。

04

CI接続と検収の判断

遠隔Macで同じコミットを実行し、テストの開始、失敗時の通知、結果ファイルの取得、ノード復旧までを確認してから、正式なCIへ移します。fastlaneのCI連携ガイドは、CI環境でfastlaneを呼び出す際の参考になります。特定のCI製品に依存しない部分と、チーム固有の成果物保存処理を分けて実装してください。

fastlane scanが通れば、iOSアプリの実機検証も完了したことになりますか。
なりません。Simulatorのテストはシミュレーション環境での確認であり、実機固有の挙動を保証しません。AppleのSimulatorと実デバイスでアプリを実行する説明に沿って、対象アプリが必要とする実機検証を別途計画します。実機が必要なテストだけを追加し、Simulatorの合格を端末での受け入れ完了と読み替えないでください。

下表は、試運転の段階を決めるための比較です。評価は性能測定ではなく、構成を選ぶときの確認観点です。

選択肢 適する用途 先に確認する点 判断
開発者のローカルMac laneやschemeの初期確認 CIと同じ依存関係・Xcodeを使えるか 開発中の切り分けに向く
リモートMacでの手動試運転 CI接続前の実行先・成果物確認 Simulator、ログ、結果ファイルを取得できるか 本番接続前の検証に向く
リモートMacをCIから実行 継続的なテストと失敗記録 失敗時保存、通知、再実行、復旧を検収したか 実運用条件を満たしてから移行

試運転の記録は、設定値、同一コミットでの実行結果、失敗時に回収できたファイル、再実行後の復旧状況を含めます。次の表で未確認項目を整理し、足りない条件があれば本番接続を保留します。

検収項目 合格と判断できる状態 未達時の対応
schemeとテスト対象 遠隔Mac上で意図したテストが実行される プロジェクト設定とlaneを照合
Simulator 指定した利用可能な対象で起動する 実行ノードの一覧に合わせて修正
結果の保管 成功・失敗の両方でログと結果を回収できる CIの後続保存処理を見直す
実機カバレッジ 必要な場合に別の端末検証が定義されている 実機検証を独立工程として追加
継続運用 同一コミットの再実行とノード復旧を確認済み 試運転を続け、正式CIへの移行を保留

Macを持たずに試す場合は、まず実際のschemeで作業時間、依存関係、結果の取り出し方が要件に合うかを確かめます。利用条件を調べる際は、VNCMacのリモートMac利用案内を確認し、地域や継続利用の条件が必要なら日本向けの案内も参照できます。

Linux中心の実行環境だけで済ませる案は、macOS専用のXcodeテストを実行できない点が制約です。一方、Macを購入して専用ノードにすると、初期費用に加えて保守、稼働管理、故障時の復旧を自前で担います。短期の検証や必要な期間だけのテスト環境なら、実機購入を決める前にVNCMacのリモートMacを試し、プロジェクトのツールチェーンと成果物回収が成立するかを確かめるのが堅実です。常時の高負荷運用や物理端末への接続が必須なら、自前のMacや実機を含めて比較し、要件に合う場合に限って利用条件を確認してください。