Codex GitHub ActionをXcode CIに加える際は、Agentの実行とMac上のビルド・テストを分離して設計します。権限を絞った試行から、成果物の受け渡し、署名情報の隔離、失敗後の復旧確認まで順に解説します。
Codex GitHub ActionをXcode CIに加える際は、Agentの実行とMac上のビルド・テストを分離して設計します。権限を絞った試行から、成果物の受け渡し、署名情報の隔離、失敗後の復旧確認まで順に解説します。
症状：CodexをCIへ加えたいが、変更内容とXcodeの合格判定が混ざりやすい状態です。
最短の解決策：Codexの実行とMacでのビルド・テストを別段階にし、署名情報を渡さずに試します。
iOS／macOS開発者：コードレビューや管理された変更の後、Mac上でプロジェクトを検証したい方に向けています。
DevOpsエンジニア：Agent処理と既存のGitHub Actions、Xcode Runnerを分けて編成する方に向けています。
開発基盤の責任者：遠隔Macノードの権限、認証情報、公開条件を評価する方に向けています。
最終更新：2026年10月10日。確認対象はOpenAIのCodex GitHub Action公式README、GitHub Actionsの安全な利用ガイド、自ホストRunnerとAppleのテスト資料です。Actionの入力項目や既定動作は変更される可能性があるため、公開前にもリンク先の最新版を確認してください。
Codex GitHub ActionはAgentの作業を担い、XcodeとxcodebuildはAppleプラットフォーム向けのビルドやテストを担います。GitHub Actionsは、それらのジョブ、条件、成果物の受け渡しを編成します。Agentが成功したという記録だけで、ビルドやテストまで合格したとは判断できません。
Codex GitHub ActionはmacOS Runner上で動かせますか？
公式READMEにはGitHub Actionsで使う方法が記載され、macOSとLinuxの安全ポリシーも説明されています。ただし、実際に利用できるRunner、必要な設定、Actionの入力値は、導入時点のREADMEとAction定義で確認します。対応環境という説明だけで、任意のRunner構成で安全に動くと判断しないでください。
| 構成 | Agentの役割 | Xcode CIの役割 | 適する段階 |
|---|---|---|---|
| 同一ジョブ | Agent処理とビルドを連続実行 | 同じ作業環境で検証 | 信頼できるリポジトリ内の小規模な試行。権限と作業領域の分離を確認できる場合 |
| 分離したジョブ | 結論またはレビュー可能な変更を出す | Mac Runnerで別途ビルド・テスト | Agentと署名情報、Runnerの境界を明確にしたい場合 |
| 人手を挟む構成 | Agentの結果をレビュー対象として提出 | 承認後にMac検証を実行 | 変更の妥当性を確認してからCIを進めたい場合 |
役割を整理したら、合格条件も別々に定義します。Agentの終了状態、差分、xcodebuildの終了状態、テスト結果、署名・配布物は、それぞれ別の記録として追跡します。
最初の試行は、本番署名に使う証明書、プロビジョニングプロファイル、Keychainの情報を含まない環境で行います。Agentに与えるリポジトリ権限と、処理を実行するホストの権限は別の境界です。Codex側のポリシーを絞っても、Runnerに残された認証情報やファイルへのアクセスまで自動で制限されるわけではありません。
GitHubの自ホストRunnerに関する説明は、Runnerを組織内の通常の実行環境と同じように扱えないリスクを説明しています。とくに、信頼していないプルリクエストのコードを、機密情報にアクセスできる自ホストRunnerで実行する設計は避けます。
注意：
pull_request_targetは、イベント名だけを見て安全と判断できません。GitHubの安全な利用上の注意を確認し、信頼していないコードのチェックアウトや実行を特権付きワークフローへ持ち込まないでください。
Codex Agentとxcodebuildを同じCIジョブに置くべきですか？
分離できるなら、最初は別ジョブを基本にします。Agentの変更を人が確認してからMacで検証でき、Agent処理の再実行とビルドの再実行も切り分けやすくなります。同一ジョブは、信頼できるコードだけを対象にし、権限・作業領域・後続処理への影響を確認できる試行に限定します。
Codexを呼び出すワークフローでは、トリガー、対象ブランチ、トークン権限を先に絞ります。GitHubの安全なワークフロー利用資料に沿い、読み取り中心の試行では、たとえば次のように必要な権限を明示します。これは設定例であり、リポジトリやActionが要求する権限を確認してから調整してください。
permissions:
contents: read
権限を追加する場合は、その権限が必要な処理と、書き込み可能な対象を説明できる状態にします。トークンの権限はGitHubのGITHUB_TOKEN資料で確認し、広い権限を慣例で付け足さないようにします。
Codex GitHub ActionをXcodeのビルドとテストに参加させるには、どう組みますか？
Agentジョブでは、結果の文章と作業ツリーの差分を別々に確認できる形で残し、Macジョブは承認済みの変更を対象にします。Codexの応答をビルド成功の証明として扱わず、Mac側でxcodebuildを実行して初めてプロジェクトの検証結果を得ます。
GitHub Actionsでは、ジョブ間で必要なデータを渡す場合、何を渡すかを明示します。たとえばAgentの説明文、レビュー対象のパッチ、Macジョブで使うソースを同一視せず、信頼できる方法で取得したソースを検証対象にします。GitHubのワークフロー成果物の共有手順を参照し、成果物の保存と受け取りを設計してください。
GitHub ActionsのmacOS Runnerは、Appleのツールチェーンを使う工程に配置します。プロジェクトに合うXcodeとmacOSの組み合わせを選び、スキーム、テスト先、結果の保存先を明示します。RunnerのラベルやXcodeのバージョンは環境依存なので、固定値を例示して決め打ちするのではなく、実際のRunnerで確認します。
xcodebuild test \
-scheme "<SCHEME>" \
-destination "<DESTINATION>" \
-resultBundlePath "<RESULT_BUNDLE_PATH>"
この例の<SCHEME>、<DESTINATION>、<RESULT_BUNDLE_PATH>は、実際のプロジェクトに合わせて置き換える値です。Appleのテスト実行と結果の解釈に関する資料をもとに、テストの終了状態と結果バンドルを確認します。ビルドログだけで合格扱いにせず、テスト結果も保存して追跡します。
| 検証項目 | 確認するもの | 合格とみなす条件 |
|---|---|---|
| Agent処理 | 実行状態、提案、作業ツリーの差分 | 想定したファイルと変更理由をレビューできる |
| Macビルド | xcodebuildの終了状態、ログ |
対象スキームでビルドが完了し、失敗理由を追える |
| テスト | テスト結果と結果バンドル | 実行結果を参照でき、失敗時に対象を特定できる |
| 配布物 | 署名、証明書、プロファイルを含む成果物 | 試行段階では本番の署名情報を含めない |
ここで重要なのは、Agentの作業記録と、Mac上で得た検証記録が別々に残ることです。遠隔Mac Xcode CIを導入する場合も、通信できることだけでなく、遠隔Mac環境の案内で提供環境を確認し、Runner上のXcode、ログ、結果バンドルに必要な担当者がアクセスできるかを確かめます。
AgentのAPI認証情報、GitHubトークン、Keychain、証明書、プロビジョニングプロファイルは、用途の異なる認証・署名情報です。一つの「CI用シークレット」にまとめず、どのジョブが何を使うか、信頼するイベントは何かを個別に記録します。
Codex GitHub ActionにiOSの署名情報を触れさせないには、どうしますか？
Agentジョブを署名情報のない実行環境に置き、署名を必要とするMacジョブとは分離します。秘密情報を設定するだけで安全になるわけではありません。信頼していないコードが秘密情報へ到達しないトリガー、Runner、後続ジョブの設計が必要です。
| 選択肢 | 相対評価 | 留意点 |
|---|---|---|
| 共有の自ホストRunner | 分離性：低 | 別のワークフローやジョブが残した状態、認証情報の扱いを厳格に管理する必要があります |
| 使い捨て・分離したMac環境 | 分離性：高 | 作成と破棄、復旧手順を含めて検証します。実行環境の具体的な安全性は構成に依存します |
| AgentとMacの別ジョブ | 境界の明確さ：高 | ソースや成果物の受け渡し方法を明示し、Agent出力を承認なしに公開工程へ直結させません |
比較は運用設計上の相対評価であり、特定のホストが安全であることを保証するものではありません。署名工程を本番に進める条件は、信頼するコードだけが実行されること、必要なジョブだけが認証情報へアクセスできること、失敗時にRunnerを隔離・再作成できることです。いずれかを確認できなければ、署名を伴う公開工程への接続を止めます。
公開前には、本番署名を使わない実プロジェクトで、Agent処理、Macビルド、テスト、成果物の受け渡しを一連で検証します。意図的に失敗させた場合も、Agentだけ、Macビルドだけ、テストだけのどこで止まったかを記録し、それぞれを個別に再実行できることを確かめます。
| 判定 | 条件 | 次の対応 |
|---|---|---|
| 公開工程へ進む | 権限境界、成果物、失敗時の復旧を確認済み | 変更承認と署名工程を分けて段階的に有効化します |
| 信頼できるリポジトリに限定 | 自ホストRunnerの隔離や復旧が未確認 | 対象ブランチと実行者を限定し、検証記録を追加します |
| 構成を差し戻す | Agent出力とMacの検証結果を区別できない | AgentとXcodeビルドを分離した2ジョブ構成へ戻します |
Runnerのクリーンアップや再作成、権限変更後の動作も再試験の対象です。GitHub Actionsの設定だけでホスト上の残留データまで消えると仮定せず、復旧後に不要なファイルや認証情報が残っていないかを運用手順に含めます。
Macを持たない、または既存のLinux環境だけではXcodeの実行、Apple固有のツールチェーン確認、Mac上の結果バンドル保管ができない場合、Mac工程だけを別に用意する選択肢があります。一方、常時稼働する重い処理を長期間固定して回す場合や、物理インターフェースが必要な検証では、レンタルが最適とは限らず、自社保有のMacとの費用・運用比較が必要です。
試行でRunnerと権限の境界を確認できた後、実際のプロジェクトにmacOS実行ノードが必要かを判断できます。短期の検証環境を用意する場合は、VNCMacのMac環境で利用条件を確認してください。常設の高負荷運用や物理機器を伴う試験に当てはまる場合は、購入や既存機材の継続利用も含めて選定するのが現実的です。