クラウドMacワークフロー：iOSビルド、CI、AI推論

iOS自動ビルド

Gitコミットからアーカイブ可能な成果物まで、各ステップに追跡可能な結果を残します。

安定した自動ビルドは、単一のコマンドだけでは実現できません。ソースコードのバージョン、依存関係の状態、Xcodeの選択、署名入力、書き出しパラメータ、成果物の保存先を固定し、どの失敗もログから特定できるようにする必要があります。

01 · トリガー
コミットとタスク入力を固定

入力：リポジトリURL、ブランチ、コミットハッシュ、ビルド設定、対象Scheme。Webhookやキュータスクは識別子だけを渡し、スクリプト内でブランチを推測しません。

失敗ポイント：コミットが存在しない、サブモジュールが同期されていない、権限不足、または同じタスクが変化中のブランチ先端を読み込む。
02 · 依存関係
キャッシュを復元して依存関係をインストール

入力：Package.resolved、Podfile.lock、その他のロックファイル。キャッシュキーには少なくとも依存関係ロックのダイジェスト、Xcodeバージョン、対象アーキテクチャを含めます。

失敗ポイント：ロックファイルのずれ、ツールチェーンとキャッシュの不一致、プライベート依存関係の認証情報失効、またはディスク容量不足。
03 · アーカイブ
xcodebuild archiveを実行

入力：WorkspaceまたはProjectのパス、Scheme、Configuration、Destination、アーカイブパス。まずツールのバージョンを出力してからアーカイブを実行します。

失敗ポイント：コンパイルエラー、テスト失敗、対象バージョン非対応、DerivedDataの汚染、またはビルドスクリプトがローカルの絶対パスに依存している。
04 · 署名
タスク単位で署名情報を注入

入力：必要最小限の証明書、プロビジョニングプロファイル、環境変数。情報はタスク開始時に注入し、終了後に削除します。

失敗ポイント：証明書とプロビジョニングプロファイルの不一致、権限範囲の誤り、有効期限の問題、または複数タスクが同じ一時キーチェーンを誤って使用している。
05 · 書き出し
書き出してファイルを検証

入力：アーカイブファイルとExportOptions設定。書き出し後は、ディレクトリの存在だけで判断せず、ファイル名、サイズ、チェックサム、生成時刻を記録します。

失敗ポイント：書き出し方法と署名設定の競合、出力ディレクトリへの権限不足、またはスクリプトがゼロ以外の終了コードを握りつぶしている。
06 · まとめ
ログと成果物を集約

出力：ビルド成果物、アーカイブファイル、テストレポート、ビルドログ、コミットハッシュ、タスク番号。作業ディレクトリはアップロード成功後に削除します。

失敗ポイント：アップロード中断、成果物名の衝突、ログへの機密フィールド混入、または結果確認前のクリーンアップ。

ビルドファームのオーケストレーション

複数のリポジトリでキューを共有しつつ、管理されていない作業ディレクトリや署名情報は共有しません。

ビルドファームの要点は、タスクを同時実行することではありません。キュー、ノードタグ、キャッシュ境界、結果の返却を説明可能にすることです。1台のMiniDebug M4は管理された実行経路に適しており、同時実行タスクは別注文に対応する物理ノードへ割り当てます。

キューのスケジューリング例

リポジトリ、タスク、ノードの割り当て順序

1タスク = 1作業ディレクトリ

mobile-app release / archive M4ノードを割り当て

shared-sdk main / test アーカイブタスクの終了を待機

demo-client feature / build 優先度順にキューへ追加

キュー投入：リポジトリ、コミット、優先度、想定タイムアウト、必要なタグを保存します。
マッチング：Xcodeバージョン、ノード状態、タスク種別、使用状況に基づいて実行ノードを選択します。
実行：独立した作業ディレクトリを作成し、キャッシュキーに一致する依存関係を復元してから、今回のタスクに必要な情報を注入します。
終了処理：ステータス、ログ、成果物、所要時間を返し、アップロード確認後に一時ディレクトリと一時認証情報を破棄します。

キャッシュ境界

ダウンロード済みの結果は再利用し、状態不明のものは再利用しません。

依存関係キャッシュは、ロックファイルのダイジェスト、Xcodeバージョン、アーキテクチャ単位で再利用できます。DerivedData、一時キーチェーン、書き出しディレクトリ、未コミットの変更はリポジトリ間で直接共有しません。

結果の集約

キューの状態とビルド結果を分けて管理します。

待機、実行、アップロード、完了はスケジューリング状態です。コンパイル成功、テスト失敗、署名失敗はタスク結果です。分けて記録することで、容量の問題かプロジェクトの問題かを判断できます。

GitHub ActionsセルフホストRunner

まずタグとクリーンアップ方針を設計し、その後ワークフローをMacノードに割り当てます。

Runnerの登録は接続作業にすぎません。安定性を左右するのは、タグの正確さ、単一マシンの同時実行制御、タスク終了時のクリーンアップ、失敗ログを対応するワークフロー実行記録へ戻せるかどうかです。

タグ設計

タグには安定した能力だけを記述します。

システムタグは保持し、長期運用できる能力タグとして macos、arm64、xcode-current 、 signing-readyなどを追加します。一時的なプロジェクト名や短期ブランチをノードタグに含めないでください。

runs-on:
  - self-hosted
  - macos
  - arm64
  - xcode-current

登録と権限

専用の実行アカウントでタスクを実行します。

登録前にRunnerの所属範囲、リポジトリへのアクセス境界、作業ディレクトリを確認します。実行アカウントにはビルドに必要な権限だけを付与し、通常のリモート操作と共用せず、長期認証情報をスクリプトへ直接記述しません。

Runner名、ノード、用途を記録
呼び出し可能なリポジトリまたは組織の範囲を制限
作業ディレクトリとキャッシュディレクトリの権限を確認
登録後に最小ビルド検証を実行

クリーンアップと同時実行

単一経路で実行し、タスク間のクリーンアップを明示します。

同じ作業ディレクトリで書き込みを伴うタスクを2つ同時に実行しないでください。開始前に残存プロセスとディスク容量を確認し、終了後にソースコードのコピー、一時書き出しファイル、一時キーチェーン、プロジェクト単位の環境変数を削除します。

同時実行が必要な場合は、署名、アーカイブ、クリーンアップが同じディレクトリを上書きしないよう、タスクごとに別の物理ノードへ割り当てます。

失敗結果の返却

ビルドに失敗しても診断情報をアップロードします。

失敗時もログ収集ステップを継続し、少なくともxcodebuildの出力、テスト結果、ディスク空き容量、ツールバージョン、タスク識別子を返します。アップロード前にトークン、秘密鍵の内容、証明書パスワード、リポジトリの機密変数を削除します。

Runnerオフライン、タスクタイムアウト、スクリプト終了、成果物アップロード失敗を区別し、すべての問題を「ビルド失敗」とだけ表示しないようにします。

個人開発者向けリリースフロー

GUIは少数の手動確認を担当し、再現可能なビルドとアーカイブはコマンドラインで実行します。

個人開発者は、すべての手順を一度に自動化する必要はありません。GUI操作とコマンドラインタスクの受け渡し地点を明確にし、修正、検証、アーカイブ、TestFlight前の成果物準備をいつでも戻せるようにするのが堅実です。

ローカル開発環境

修正とコミット

コード修正、基本テスト、コミットを完了し、固定ブランチへプッシュします。検証するデバイス条件と期待結果も記録します。

出力：コミットハッシュ、変更内容、テスト範囲

リモートGUI

Xcodeで手動確認

Scheme、対象バージョン、プロジェクト設定を確認し、目視判断が必要な警告に対応します。署名設定が今回のリリースに必要な範囲を指していることも確認します。

出力：確認済みのプロジェクト状態とリリースパラメータ

コマンドラインタスク

アーカイブと書き出し

スクリプト化したアーカイブ、書き出し、検証を実行し、完全なログを保持します。問題が発生したら対応する入力へ戻り、失敗したマシン上で不明な状態を手動修正し続けないでください。

出力：アーカイブファイル、書き出しパッケージ、チェックサム

推奨する受け渡しルール

GUIは人手の判断が必要な設定と確認だけを担当し、アーカイブ、書き出し、再試行、成果物の命名はスクリプトに任せます。手動調整のたびにプロジェクト変更をコミットするか差分を記録し、次回のビルドを再現できなくなるのを防ぎます。

AI推論実験

Apple Silicon上でモデルのバージョンを比較し、1回の実行結果だけを記録しない。

MiniDebug M4はM4、16GB RAM、256GB SSD構成です。実験ではまずモデルとデータがこのリソース範囲に適しているか確認し、読み込み、メモリ、継続推論、出力品質を記録します。異なるパラメータの結果を混在させないでください。

01 · 準備

モデルと実行環境を固定

モデル形式、量子化バージョン、ランタイムバージョン、コミットハッシュ、入力サンプル、乱数パラメータを記録します。モデルファイルはチェックサムで識別し、同名で内容が異なる事態を防ぎます。

必須記録項目: モデルバージョンと量子化方式
リソース範囲: 16GB RAM / 256GB SSD

02 · ベンチマーク

コールドスタートと継続推論を分けて測定

初回ロードにはモデル読み込みと初期化が含まれるため、安定稼働フェーズと合算できません。各テストでは入力長、バッチサイズ、反復回数、サンプリングパラメータを統一します。

時間指標: ロード時間、初回出力、合計時間
リソース指標: ピークメモリと安定時メモリ

03 · 比較

速度、メモリ、結果の差異を比較

量子化バージョンは速度だけで比較しません。同じ入力に対する出力、タスク品質の評価、エラーサンプル、環境情報も保存し、最後に機械可読な結果と人による結論を出力します。

比較項目: レイテンシ、スループット、メモリ、出力品質
実験出力: CSV、ログ、設定、結論

benchmark-run.json

{
  "machine": "MiniDebug M4 / M4 / 16GB / 256GB",
  "model_variant": "project-defined",
  "input_set": "fixed-evaluation-set",
  "measurements": [
    "load_time",
    "first_output_time",
    "total_time",
    "peak_memory"
  ],
  "artifacts": ["result.csv", "runtime.log", "notes.md"]
}

音声・動画ワークフロー

大容量ファイルの同期、リモート編集、一括書き出しを独立した段階に分けます。

音声・動画タスクのボトルネックは、素材転送、プラグイン互換性、リモート画面、ディスク容量、書き出しパラメータにある可能性があります。工程を分離すれば、接続の遅延をホストの計算性能の問題と誤認せずに済みます。

ステージA

プロジェクトと素材を同期

まず素材一覧を作成し、ファイル数、合計サイズ、ディレクトリ構成、チェックサムを記録します。現在の段階で必要なプロキシまたはソース素材だけを同期し、完了後に欠落項目を確認します。

チェックポイント：プロジェクトパスがローカルドライブレターに依存せず、メディア参照を再配置でき、256GBの標準SSDにプロジェクトキャッシュと書き出し用の空きがあること。

ステージB

リモートでプロジェクトを開いて確認

GUI接続でプロジェクトを開き、フォント、プラグイン、メディアリンク、サンプリング設定、出力先を確認します。低速なネットワークでは工程の出力パラメータを変えず、リモート画質と解像度を下げます。

チェックポイント：リモートプレビューの品質と最終ファイルの品質を区別します。プラグインが不足している場合は不完全な結果を避けるため、一括タスクを停止します。

ステージC

一括書き出しを実行

書き出しプリセット、ファイル名、保存先を固定してからタスクリストに沿って実行します。各タスクの終了状態、所要時間、出力サイズ、エラー情報を保存します。

チェックポイント：長時間タスクの開始前にディスク空き容量を確認します。同時実行数はメモリ、素材読み込み、エンコード負荷に応じて段階的に検証します。

ステージD

成果物を検収して返却

画面、音声トラック、長さ、解像度、ファイルヘッダーを抜き取り確認し、チェックサムを生成します。ローカルで完全に受信したことを確認してから、クラウド上の一時ファイルを削除します。

出力：最終ファイル、書き出しログ、失敗一覧、チェックサム、ローカル受信記録。

ノード選択のヒント

シンガポール、日本（東京）、韓国（ソウル）、香港、米国東部からデータ経路に応じて選択します。

ノードはチームの所在地だけで選びません。コードリポジトリ、依存関係の取得元、リモート操作者、最終納品先も同時に考慮します。以下は選択の目安であり、ネットワーク結果を保証するものではありません。実際の接続性能は、利用者のローカルネットワークと地域間経路に左右されます。

MiniDebug M4 5ノードのワークフロー選択ガイド
ノード	優先して検討するチーム所在地	リポジトリと依存関係の所在地	代表的な納品先	注文前の確認
シンガポール	東南アジアのチームまたは地域横断の協働メンバー	リポジトリ、成果物、依存サービスが主に東南アジアにある場合に優先してテスト	東南アジアチームの日常ビルド、リモート開発、結果返却	リポジトリ取得、依存関係のダウンロード、リモートGUI接続をテスト
日本（東京）	日本および周辺の東アジアチーム	コードと依存関係へのアクセス経路が日本に近い場合に優先してテスト	日本チームのiOSビルド、署名確認、リモートXcode操作	ローカルからノードへの操作安定性と大容量ファイルのアップロードを検証
韓国（ソウル）	韓国および北東アジアの協働チーム	韓国方面からリポジトリや社内リソースへ直接アクセスしやすい場合に検討	継続的インテグレーション、セルフホストRunner、地域内の成果物配布	Runnerの再接続、依存関係の取得、ログのアップロードを検証
香港	華南と東南アジア間で協働するチーム	コード、素材、操作者が華南と東南アジアに分散している場合に優先比較	地域横断の開発協業、リモートGUIタスク、素材処理	オフィスネットワークと家庭ネットワークの接続経路を個別にテスト
米国東部	北米東部および西欧と協働するチーム	リポジトリ、CIコントロールプレーン、納品システムが北米東部にある場合に検討	北米の稼働時間帯におけるビルドキュー、結果返却、協業確認	リポジトリ、成果物ストレージ、リモート操作者の3経路をテスト

ワークフローテンプレート

最小構成から始め、プロジェクトのバージョン、証明書、パスを置き換えます。

以下のスニペットはスクリプト構成のたたき台であり、すべてのプロジェクトでそのまま使える完全な設定ではありません。リポジトリに保存する前に、プロジェクトの種類に応じてWorkspace、Scheme、Xcodeバージョン、書き出し設定、署名情報、Runnerタグ、成果物ディレクトリを確認してください。

Shell

xcodebuildアーカイブ構成

archive.sh

set -euo pipefail

PROJECT_ROOT="/path/to/project"
WORKSPACE="$PROJECT_ROOT/Example.xcworkspace"
SCHEME="Example"
ARCHIVE_PATH="$PROJECT_ROOT/output/Example.xcarchive"

xcodebuild -version
xcodebuild \
  -workspace "$WORKSPACE" \
  -scheme "$SCHEME" \
  -configuration Release \
  -destination "generic/platform=iOS" \
  -archivePath "$ARCHIVE_PATH" \
  clean archive

変更箇所

プロジェクトパス、Workspace、Scheme、Configuration、Destination、アーカイブディレクトリを置き換えます。スクリプトはゼロ以外の終了コードを保持し、実行前に必要なXcodeバージョンを確認します。

Fastlane

ビルドと成果物記録の構成

Fastfile

lane :build_release do
  setup_ci

  build_app(
    workspace: "Example.xcworkspace",
    scheme: "Example",
    configuration: "Release",
    output_directory: "output"
  )

  sh("shasum -a 256 output/*")
end

変更箇所

プロジェクトに合わせてWorkspace、Scheme、出力ディレクトリ、書き出し設定を置き換えます。署名情報は管理された変数またはタスク単位の注入で提供し、Fastfileへ直接記述しないでください。

CI

セルフホストRunnerのタスク構成

build.yml

name: ios-build

on:
  workflow_dispatch:

jobs:
  archive:
    runs-on:
      - self-hosted
      - macos
      - arm64
      - xcode-current
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Build
        run: ./scripts/archive.sh

      - name: Collect diagnostics
        if: always()
        run: ./scripts/collect-diagnostics.sh

変更箇所

実際のRunnerタグ、リポジトリポリシー、スクリプトパスに合わせて調整します。使用するアクションのバージョンを固定し、タスクのタイムアウトを設定し、ビルド失敗時も診断情報の収集を続行させます。

ビルドのトラブルシューティング手順を見るワークフロー適用について相談

既存フローの検証を開始

MiniDebug M4を1台選び、まず最小ビルドの一連の流れを動かします。

固定コミット、単一タスク実行、ログのアーカイブ、成果物の検証から始め、キャッシュ、署名情報の注入、キュー制御を段階的に追加します。日・週・月・四半期単位でレンタルでき、注文は米ドル（USD）で決済されます。

支払い方法はUSDT-TRC20とVisa / Mastercard / Amex（Stripe経由）のみです。利用可能な決済ゲートウェイは管理画面の表示に従います。

クラウドMacを今すぐレンタル料金の詳細を見る

Gitコミットからアーカイブ可能な成果物まで、各ステップに追跡可能な結果を残します。

コミットとタスク入力を固定

キャッシュを復元して依存関係をインストール

xcodebuild archiveを実行

タスク単位で署名情報を注入

書き出してファイルを検証

ログと成果物を集約

複数のリポジトリでキューを共有しつつ、管理されていない作業ディレクトリや署名情報は共有しません。

リポジトリ、タスク、ノードの割り当て順序

ダウンロード済みの結果は再利用し、状態不明のものは再利用しません。

キューの状態とビルド結果を分けて管理します。

まずタグとクリーンアップ方針を設計し、その後ワークフローをMacノードに割り当てます。

タグには安定した能力だけを記述します。

専用の実行アカウントでタスクを実行します。

単一経路で実行し、タスク間のクリーンアップを明示します。

ビルドに失敗しても診断情報をアップロードします。

GUIは少数の手動確認を担当し、再現可能なビルドとアーカイブはコマンドラインで実行します。

修正とコミット

Xcodeで手動確認

アーカイブと書き出し

Apple Silicon上でモデルのバージョンを比較し、1回の実行結果だけを記録しない。

モデルと実行環境を固定

コールドスタートと継続推論を分けて測定

速度、メモリ、結果の差異を比較

大容量ファイルの同期、リモート編集、一括書き出しを独立した段階に分けます。

プロジェクトと素材を同期

リモートでプロジェクトを開いて確認

一括書き出しを実行

成果物を検収して返却

シンガポール、日本（東京）、韓国（ソウル）、香港、米国東部からデータ経路に応じて選択します。

最小構成から始め、プロジェクトのバージョン、証明書、パスを置き換えます。

xcodebuildアーカイブ構成

ビルドと成果物記録の構成

セルフホストRunnerのタスク構成

MiniDebug M4を1台選び、まず最小ビルドの一連の流れを動かします。