Flutter + GitHub Actions + Mac mini セルフホストRunner iOS CIアーキテクチャ

三層CIモデル

具体的なツールを見る前に、一つの等式を確立しましょう——どの層を修正すべきかを決定します：

Flutter iOS CI =
  コントロールプレーン（GitHub Actions：トリガー・承認・Secrets管理）
+ 実行プレーン      （Mac mini M4  ：iOSネイティブビルド・署名・環境確定性）
+ キャッシュプレーン（ローカルSSD  ：依存関係とビルド成果物の永続化）

このシリーズ全体の判断を左右する3つの推論：

1. コントロールプレーンはコードを実行しない。 workflow YAMLを最適化してもビルドは速くなりません。ビルド時間を削減するには実行プレーンを置き換える必要があります。
2. 実行プレーンが再現性を決定する。 共有プール（macos-latest）のXcodeバージョンはGitHubの更新に追従します。セルフホストマシンのバージョンはあなたが固定できます。
3. キャッシュプレーンが速度を決定する。 セルフホストの速度優位はCPUではなく、ローカルSSDがジョブごとのリモートキャッシュアップロード/ダウンロードを不要にすることから生まれます。

なぜFlutter iOS CIに専用macOS実行プレーンが必要か

FlutterはLinuxでAndroidビルドと単体テストを処理できますが、iOSビルドとApp Store公開はmacOSでのみ実行できます——これはAppleツールチェーンの制約であり、Flutter自体の問題ではありません。

そのため、すべてのFlutterチームはアーキテクチャの選択に直面します：iOSの実行はどこで行うか？macos-latestから離れる動機となる3つの摩擦：

• コスト：GitHubホストのmacOS Runnerは、Linuxと比べて分単価が大幅に高くなります。iOSのコールドビルドは20〜30分かかることもあり、ビルド頻度が上がると請求額が急増します。
• 環境の確定性：ホストイメージのXcodeバージョンはGitHubの更新に追従し、固定できません。「ローカルは通る、CIは失敗する」という調査コストが繰り返し発生します。
• ビルド速度：iOS依存関係のサイズは大きく、ホストRunnerはジョブごとにキャッシュを再アップロード・再ダウンロードします。ローカルSSDを持つセルフホストマシンはこのボトルネックを根本から解消します。

「macOS実行プレーンを制御された境界内に戻す」——これがこのアーキテクチャの中心的な設計判断です。コントロールプレーンはGitHubに残し（PRトリガー、レビューゲート、Secrets管理）、実行層だけをテナント専用のMac mini M4に切り替えます。

公式ドキュメント：GitHubセルフホストRunner · Flutter CD ガイド

アーキテクチャ全体像

パイプライン全体を三層モデルにマッピングします——障害発生時はまずどの層かを特定し、対応する専門記事へ：

Flutter iOS CIの障害はすべてこの3行のいずれかに分類できます。プレーンを正しく特定すれば、修正の道筋が明確になります。

移行判断マトリクス：いつ移行すべきか

セルフホストがデフォルトの答えではありません。5分間のチームレビューで判断するためのマトリクス：

経験則：「移行」シグナルに3つ以上該当する場合——セルフホストは通常2〜4週間でコストを回収できます（マシンレンタル費 vs 節約できるホストmacOS分単価）。

専門記事シリーズ：問題箇所から直入り

本記事はアーキテクチャの理解と移行判断のみを扱います。各実行層の詳細は専門記事でカバーしています：

シナリオ別の入口選択

• ゼロから構築：本記事でアーキテクチャ方向を確認 → ①「Runner構築」でマシンをセットアップ → ②「キャッシュモデル」で速度を最適化 → ③「署名」でリリースパイプラインを接続。
• Runnerはあるが、iOSビルドが遅い：②「三層キャッシュモデル」に直行。
• 署名またはTestFlightがスタック：③「署名とリリース」へ。
• Runnerがオフライン / ビルドがランダムに失敗：⑤「運用と安定性」へ。
• BitriseなどのクラウドCIから移行：移行コスト比較表は Bitrise vs セルフホストクラウドMac判断ガイド を参照。