2026年9月16日時点で、Godotの公式バージョンアーカイブでは4.7系の安定版として4.7.2が掲載されています。公式アーカイブ
結論は明確です。Godot 4.7 iOSエクスポートは、Xcodeを導入したmacOS環境が必要です。 ただし、シーン制作、スクリプト作成、素材整理、通常の開発作業までMacへ移す必要はありません。短期または負荷が読めない場合はリモートMac、継続的に高稼働する場合は購入、運用コストを分けたい場合は通用ノードとMac公開ノードの混合構成が適しています。
WindowsまたはLinuxでゲームを開発し、主力PCを変えずにiOS向けへ公開したい開発者が対象です。
ビルド担当者、DevOps担当者、技術責任者が、Macの役割と運用方式を決める際にも利用できます。
最終更新：2026年9月16日。Godot 4.7の公式文書、公式バージョンアーカイブ、AppleのXcodeおよびApp Store提出資料を基に確認しています。
[ SECTION_01 ] iOS向け成果物ではMacが担当する範囲が決まっています
Godot 4.7の公式iOSエクスポート文書は、iOSプロジェクトのエクスポートを、XcodeがインストールされたmacOSコンピューター上で実行する必要があると説明しています。Godot 4.7のiOSエクスポート要件
WindowsやLinux上でGodotプロジェクトを編集し、iOS用のエクスポート設定を準備することはできます。しかし、Xcodeプロジェクトが生成された時点で納品が完了したわけではありません。Xcodeでのビルド、署名、Archive、テスト、提出用制品の作成が残っています。
| 工程 | Windows / Linux | macOS上のMac | 判断 |
|---|---|---|---|
| シーン、GDScript、素材の編集 | 実行可能 | 実行可能 | 主力PCに残せる |
| Godotのエクスポート設定 | 実行可能 | 実行可能 | プロジェクトとテンプレートを固定する |
| iOS向けエクスポート | 完結しない | 実行可能 | Macが必要 |
| XcodeビルドとArchive | 実行不可 | 実行可能 | Xcodeの環境が必要 |
| 署名と提出用制品 | 完結しない | 実行可能 | 秘密鍵を管理できるノードに限定する |
| Simulator・実機検証 | iOS環境としては不可 | 実行可能 | 目的ごとに検証方法を分ける |
Windowsで作成したGodotプロジェクトは、どのようにiOSアプリへ進めるのでしょうか。
一般的には、リポジトリをMacへ取得し、指定したGodot 4.7のエクスポートテンプレートでiOS向けプロジェクトを生成します。その後、Xcodeでビルドと署名を行い、Archiveまたは提出用の制品を作成します。開発データをすべてMacへ移行するのではなく、MacをApple固有工程の実行ノードとして扱う構成です。
Godotのコマンドラインエクスポートも自動化できます。公式のコマンドラインエクスポート手順を基に、プロジェクト、エクスポートプリセット、出力先を分離して管理します。
[ SECTION_02 ] ツールチェーンを固定できないMacは採用しない
リモートMacを選ぶ際は、エディターが起動するかだけで判断してはいけません。必要なのは、同じプロジェクトを同じ条件で再実行できる管理権限と環境の再現性です。
最低限、次の項目を確認します。
- 指定したGodot 4.7系のバージョンを導入できること。
- 必要なiOSエクスポートテンプレートを保存できること。
- 対象プロジェクトに合うXcodeと追加コンポーネントを利用できること。
xcode-selectの参照先を確認し、CIから明示的に固定できること。- SSH経由で、確認待ちのダイアログなしにコマンドを実行できること。
- 作業ディレクトリを初期化し、汚染された成果物を除去できること。
- 再起動後に必要なサービス、Runner、SSH接続を復旧できること。
AppleのXcodeシステム要件は、XcodeとmacOSの対応関係を示しています。AppleのXcodeシステム要件に対象バージョンを照合し、提供側がOSやXcodeを一方的に更新しないかも確認します。
Godot iOSのエクスポートに完全なXcode環境は必要でしょうか。
Godot公式文書の要件は、macOS上にXcodeを導入することです。コマンドラインツールだけを置いたLinux風のビルド環境では、Xcodeプロジェクトのビルド、署名、Simulatorや実機での検証までを同じ前提で完結できません。利用するXcode、SDK、署名設定を固定できない場合は、試行を続けず、別のMacノードへ切り替えるのが安全です。
Godot C#プロジェクトは、GDScriptプロジェクトと同じ前提で扱わない必要があります。Godot 4.7公式文書にあるC#およびiOSの対応状況を確認し、使用する.NET機能、ネイティブプラグイン、エクスポートテンプレートを実際のプロジェクトで検証します。Godot 4.7 iOS公式文書にない機能を、安定動作すると推定してはいけません。
[ SECTION_03 ] 署名と公開は「ビルド」と分けて設計します
iOS向けの公開工程では、次の値を一つの「打包」作業として扱わないことが重要です。
- Bundle ID：
com.example.game - Team ID：
TEAM_ID_PLACEHOLDER - 証明書：
CERTIFICATE_PLACEHOLDER - Provisioning Profile：
PROFILE_PLACEHOLDER - Archive：
ARCHIVE_PATH_PLACEHOLDER - App Store Connect用制品：
ARTIFACT_PATH_PLACEHOLDER
アプリ本体だけでなく、拡張Targetやネイティブプラグインがある場合は、それぞれの署名状態を確認します。自動署名は初期設定を簡略化しやすい一方、Appleアカウントの権限や認証情報に依存します。手動署名は再現性を作りやすい一方、証明書、秘密鍵、Profileの更新を担当者が管理しなければなりません。
| 方式 | 適した用途 | 強み | 停止条件 |
|---|---|---|---|
| 自動署名 | 少人数の試作、手動公開 | 初期設定が比較的簡単 | CIで認証待ちが発生する |
| 手動署名 | 継続的な公開、監査が必要なチーム | 参照する資産を固定しやすい | Profile更新の運用がない |
| 分離型 | 通用ビルドと公開を分けるCI | 秘密鍵を公開ノードに置かずに済む | 制品の受け渡し設計がない |
リモートMacで署名とApp Storeへの提出まで完了できますか。
必要なXcode、Appleアカウント権限、証明書、秘密鍵、Provisioning Profileを用意できれば、リモートMacを公開ノードとして使えます。ただし、秘密鍵を一般のビルドノードへ配布する設計は避けます。通常のアセット処理や非Apple向けビルドは通用ノードに残し、署名と提出だけを制限されたMacへ渡す方式が管理しやすいです。
Appleの登録済みデバイス向け配布手順は、Xcodeでの署名と配布の考え方を説明しています。AppleのXcode配布文書を基準に、アプリ本体と拡張Targetの設定を個別に確認します。提出時はApp Store Connectの公式提出手順も照合します。
[ SECTION_04 ] 実機、Simulator、Apple Silicon Macは証明できる内容が異なります
エクスポート先にファイルが生成されたことだけでは、公開可能なiOSアプリとは判断できません。最低限、次の順序で制品を確認します。
- クリーンな作業ディレクトリへリポジトリを取得する。
- Godot 4.7のバージョンとエクスポートテンプレートを確認する。
- iOS向けプロジェクトを生成し、Xcodeで開く。
- 署名設定を適用してXcodeビルドを実行する。
- Archiveまたは対象チャネル向け制品を生成する。
- ログ、Bundle ID、署名状態、出力ファイルを保存する。
- 失敗した場合は、同じコミットから再実行し、環境差分を記録する。
AppleはSimulatorまたは実機でのアプリ実行について別々の説明を提供しています。Simulatorと実機での実行に関するApple文書を基に、検証結果を混同しないようにします。
Apple Silicon Macでの実行は、Mac上のビルド環境が起動し、Mac側のツールチェーンが動くことを確認するものです。iOS Simulatorは画面遷移、UI、ログ、基本的な入力の確認に役立ちます。実機は、実際の入力、グラフィック、権限、プラットフォームサービス、ネイティブ拡張を確認する工程です。どれか一つを、他の二つの完全な代替とは扱いません。
[ SECTION_05 ] CIではMacをすべての処理に使わない構成が有力です
Godot iOSのCIは、すべてMacへ置くべきでしょうか。
必ずしもそうではありません。リポジトリ検査、一般的なスクリプト、素材変換、非iOS向けビルドは通用ノードで実行し、GodotのiOSエクスポート、Xcodeビルド、署名、公開だけをMacノードへ渡す混合CIが基本的な選択肢になります。
GitHub Actionsの自ホストRunnerを使う場合は、Mac側でRunnerを登録し、ラベルでiOS専用ジョブを振り分けます。自ホストRunnerの公式手順を基に、署名秘密情報、キャッシュ、制品の保存先を分離します。
Mac構成の比較は次の通りです。評価は機能の優劣を断定するものではなく、運用条件に対する5段階の適合度です。
| 構成 | 短期移植 | 高稼働CI | 運用負担 | 故障時の影響 | 適合度 |
|---|---|---|---|---|---|
| Mac 1台へ集約 | 4/5 | 3/5 | 3/5 | 大きい | 条件付き |
| 専用の公開Mac | 3/5 | 5/5 | 4/5 | 中程度 | 高い |
| 通用ノード＋Macノード | 5/5 | 5/5 | 4/5 | 分散 | 最有力 |
| ローカル購入Macのみ | 2/5 | 4/5 | 2/5 | 所有機器に依存 | 高稼働時向け |
SSH断線後もジョブが継続するか、Runner再起動後に登録状態が戻るか、ワークスペース汚染を除去できるかを確認します。ノードがオンラインであることと、ジョブを安全に実行できることは別の条件です。
[ SECTION_06 ] 利用期間と保守責任でレンタルか購入かを決めます
費用を比較する際は、月額だけを並べると判断を誤ります。次の変数を同じ表に入れます。
- レンタル期間または所有期間
- 環境準備の作業時間
- 使用しない期間の遊休
- 故障時の代替ノード
- 証明書と秘密鍵の管理工数
- OS、Xcode、Godotの更新確認
- バックアップ、監視、復旧の担当者
短期移植、公開頻度が不安定、Macを常時稼働させる予定がない場合は、リモートMacのレンタルが適しています。一定期間にわたって高い利用率が見込まれ、電源、ネットワーク、保守、交換、バックアップを自社で担える場合は購入を検討できます。
すでに通用ビルド基盤があり、Apple固有の処理だけを切り出したいチームは、混合CIが合理的です。Mac miniの購入条件を詳しく比較したい場合は、Mac miniの購入判断に関するガイドも参照できます。購入ではなく、まず利用期間と必要な権限を確認したい場合は、NOVAKVMのMac利用案内から条件を確認します。
選択マトリクス
| 条件 | 推奨方式 | 実行ノードの分担 | 判断理由 |
|---|---|---|---|
| 数回の移植、公開時期が未確定 | リモートMacのレンタル | Windows/Linux＋Mac公開ノード | 初期投資と遊休を抑えやすい |
| 継続開発、負荷が変動 | 混合CI | 通用ノード＋専用Mac | Apple工程だけを分離できる |
| 高利用率、保守担当がいる | Mac購入 | 自社管理Mac＋既存CI | 長期の運用責任を引き受けられる |
| 秘密鍵を外部ノードへ置けない | 管理された公開Mac | 公開専用Mac | 署名資産の範囲を限定できる |
| Xcodeやテンプレートを固定できない | 採用を停止 | 別のMacへ切り替え | 再現性がないまま修正を続けない |
まず実際のGodotプロジェクトを使い、回復可能な試験ビルドを1回実施します。エクスポートテンプレート、Xcodeビルド、署名、制品保存、再起動後の復旧まで通過した時点で、必要なレンタル期間または購入判断を確定させます。
Windows/Linuxの開発環境を維持できる一方、ローカル環境だけではXcode、iOS署名、実機検証、App Store提出を完結できません。購入したMacは初期費用、遊休期間、保守担当、故障時の代替が課題になります。利用期間が短い、負荷が読めない、公開工程だけMacが必要という条件なら、NOVAKVMでリモートMacを試し、実プロジェクトで環境の再現性を確認する方が判断を先送りしません。高稼働が確認できた後に購入へ移行する運用も可能です。