VS Code 1.138でAgentがPRを作成した後、Macビルドはどこに置く？2026

まず結論

VS Code 1.138の公式リリースノートでは、Agent Hostの会話からPull Requestを作成し、ドラフト状態やマージに関する選択肢を扱えることが確認されています。 VS Code 1.138のリリースノート

症状：AgentはPRを作れたのに、Xcodeのビルド結果を同じ環境で再現できない。
最短解決：PR作成はAgent Host、確定的な検査はCI、Xcode・署名・Appleプラットフォームの回帰は独立したクラウドMacへ分けます。

これは、PRが作成済み、チェックが成功済み、コードがリリース可能という3つの状態を混同しないための分離です。低リスクの試作だけは一時的に共用できますが、署名や公開権限を含む処理では、最初から環境を分けてください。

対象読者

iOS・macOSチームで、Agentが作成したPRをどのMacでXcode検証するか判断したい方に向いています。
プラットフォームエンジニア、そしてコストを抑えながら共有ホストの汚染やビルド待ちを避けたいAIスタートアップにも役立つ構成です。

状態の分離

Agent Hostは、コードの変更、コミット、PRの作成を担当する場所です。CI Runnerは、同じ入力に対して同じ検査を繰り返す場所であり、Xcodeビルドを必ず代替するものではありません。GitHub Actionsではジョブごとに実行先を選べ、自社管理Runnerを使う場合も、そのRunnerの管理責任が残ります。 Runnerの選択に関する公式説明 自社管理Runnerの公式説明

判定を次のように分けると、Agentが「完了」と報告したときの誤解を減らせます。

• PR作成済み：変更がレビュー対象としてGitHubへ登録された状態です。
• チェック成功：指定されたCIジョブが成功し、ログと成果物を確認できる状態です。
• リリース可能：レビュー、必須チェック、Appleプラットフォーム検証、署名と公開承認まで完了した状態です。

最低限、コミットID、実行したテスト、RunnerまたはMacの識別情報、依存関係の状態、ログ、成果物を保存します。GitHub Actionsの成果物はWorkflow artifactsとして保存できますが、成果物を残したこと自体がテストの正当性を証明するわけではありません。 Workflow artifactsの公式説明

シナリオ別の配置

Web・クロスプラットフォーム

静的解析、単体テスト、コンテナ内のビルドだけで完結するPRなら、Agent Hostが変更とPR作成を行い、通常のCI Runnerへ検査を渡す構成で足ります。新しいMacを追加しなくてもよい条件は、次のすべてを満たす場合です。

• XcodeやSimulatorを使わない
• Apple固有のシステムフレームワークに依存しない
• 署名証明書や公開用秘密情報をジョブへ渡さない
• 依存関係を固定し、CIのログを再確認できる
• 失敗時にAgentの作業途中ではなく、コミットから再実行できる

一つでも外れるなら、CIの成功をApple向けの出荷証明として扱わないでください。停止条件は、同じコミットをクリーンなRunnerで再実行できない場合、またはテスト結果と実行環境を後から特定できない場合です。

iOS・macOS

Xcode、Simulator、Appleのシステムフレームワーク、実機接続、署名設定が関係するPRでは、汎用Runnerやコンテナだけでは不十分です。AppleもSimulatorと実機でのアプリ実行・検証を別の実行対象として説明しています。 AppleのSimulator・実機テスト説明

Agent Host上でそのままXcodeを動かす方法には、短時間で結果を得られる利点があります。しかし、未コミットの変更、DerivedData、依存関係のキャッシュ、証明書、前のタスクのプロセスが混ざると、再現性が下がります。長時間のXcodeジョブがAgentの作業を占有する点も見落とせません。

基本構成は、Agent HostがPRを作成し、独立Macがコミットを取得してXcodeジョブを実行する形です。署名と公開の権限は、コード生成を行うAgentの認証情報から切り離します。クラウドMacの利用条件や接続方式を確認する場合は、kvmsyncの利用ガイドも併せて確認してください。

保護ブランチ・高リスクリポジトリ

AgentがPRを作成できても、ブランチ保護、必須チェック、レビュー承認、マージキューを通過できるとは限りません。GitHubの保護ブランチでは、必須ステータスチェックやレビューなどを設定できます。 保護ブランチの公式説明

次の確認を、PR作成直後に行います。

1. Agentが使ったリポジトリの身元を確認する
2. 作業ブランチへの書き込み権限と、保護ブランチへの権限を分ける
3. CIの結果が、変更者と同じ身元による自己承認になっていないか確認する
4. 必須チェックの名前と対象コミットを照合する
5. 高リスク変更はドラフトPRとして開始し、独立した検査と人手承認を要求する

Agent Mergeが有効な場合でも、これを安全な出荷の証明とみなしてはいけません。VS Code 1.138の機能状態や実験扱いの範囲は、運用前にリリースノートを再確認してください。停止条件は、必須チェックの出所を説明できない場合、またはAgentの権限で保護ルールを迂回できる構成が残っている場合です。

リモートAgent Host・長時間ジョブ

Agent Hostが遠隔のホストやクラウドMac上で動いている場合、保存先を3つに分けます。

• コード作業領域：Git worktreeまたは作業ディレクトリ。コミットとブランチを基準に再取得できるようにします。
• タスク状態：Agentの指示、実行済み操作、失敗位置、再開に必要なメタデータを保存します。
• ビルド成果物：ログ、テスト結果、アーカイブ、診断情報をCIの成果物領域へ保存します。

クライアントとの接続が切れただけでは、Xcodeビルドが再開可能だとは証明できません。実際に再接続し、途中ジョブの状態、ワークスペースの所有者、成果物の整合性、同じコミットからの再実行を確認してください。Agent Hostの構造と役割は、Agent Hostの公式ドキュメントで確認できます。

長時間Xcodeを占有する処理は、コード生成用のホストではなく専用キューへ送ります。ジョブが中断したときに同じMacを再利用できないなら、リース解放、プロセス停止、ワークスペース破棄の手順を先に自動化してください。

複数Agent・ビルド集中

複数のAgentが同じプロジェクトの文脈を共有すると、生成速度よりも依存関係の取得、テスト待ち、Macのビルド待ちがボトルネックになります。Agentのセッション数だけを見てMacを一対一で増やすと、待機中の容量が増えるだけの可能性があります。

実行時間が安定しているのに待機だけが増えるなら、まずキューを調整します。実行中のMac不足が明確で、署名を含むジョブが互いに干渉しているなら、基礎容量とピーク用の弾性容量を分けて検討します。状況に合う運用記事は、kvmsyncのブログ一覧から確認できます。

3層構成の判断表

あなたが最初に採用する標準は、Agent Hostが変更とPR作成、CIが確定的な検査、独立したクラウドMacがAppleプラットフォームの交付確認です。低リスクの試作であれば共用しても構いませんが、次の条件では分離を止めないでください。

• 署名証明書、秘密鍵、公開用トークンを扱う
• 無人の長時間ジョブを実行する
• 複数のPRが同じMacを奪い合う
• 前のジョブのキャッシュやプロセスを完全に消せない
• 失敗後に同じコミットから再現できない
• 必須チェックの結果を独立した主体として説明できない

運用開始の5手順

1. PR経路を図にする
   Agent Host、Git作業領域、Pull Request、CI Runner、Xcode Mac、署名・公開権限を別の箱に書き出します。

2. コード種別を判定する
   Xcode、Simulator、Appleフレームワーク、実機、署名のいずれかがあれば、独立Macの候補に入れます。

3. 証拠の保存先を決める
   コミットID、CIログ、Macのビルドログ、テスト結果、成果物を、後から同じPRに結び付けられるようにします。ログの確認方法はGitHub Actionsログの公式説明に沿って設計してください。

4. 権限を分けてドラフトPRを流す
   Agentにはコード変更とPR作成に必要な権限だけを与え、署名と公開は別の承認経路に置きます。

5. 中断と再実行を検証する
   クライアント切断、Agent停止、Macの解放、依存関係の再取得、同じコミットからの再ビルドを実際に確認します。

6. 待機と実行を記録して拡張する
   最初からMacを増やすのではなく、キュー待機、実行、再試行、承認の時間を分けて記録します。停止条件を満たさないジョブは、PRが作成済みでもリリース判定へ進めません。

FAQ

上の設計を実際の運用へ移すとき、特に判断が分かれやすい点をまとめます。

VS CodeのAgent HostからPRを作った後もCIは必要ですか？

必要です。PRの作成は変更をレビュー対象へ移す操作であり、静的解析、単体テスト、依存関係の確認を独立したCIで実行した証明にはなりません。Agent Hostと同じ認証主体に判定を任せず、コミット、実行環境、テスト結果、ログを保存してからレビューとマージへ進めてください。

Agentが作成したiOSのPRは、どこでXcodeビルドを実行すべきですか？

Xcode、Simulator、Appleのシステムフレームワーク、署名設定に依存するPRは、独立したmacOS環境で実行するのが基本です。Agent Host上で生成とビルドを兼ねると、作業途中の変更、キャッシュ、証明書、依存関係が混ざります。専用または分離されたクラウドMacへ渡し、結果をPRへ戻してください。

Agent HostとGitHub Actions Runnerを同じMacで動かせますか？

低リスクの試作や短時間の確認なら可能ですが、恒常的な構成には向きません。同じMacを使う場合は、ワークスペース、認証情報、キャッシュ、ログの保存場所を分け、失敗後にクリーンな状態へ戻せることを確認します。署名、公開、高権限ツール、無人実行が入る場合は環境を分離してください。

複数のAgentが同時にPRを作るとき、Macのビルドキューはどう設計しますか？

Agentのセッション数とMac台数を一対一で対応させず、待機時間、実行時間、再試行時間、承認待ち時間を別々に記録します。Xcodeの長時間ジョブは専用キューへ送り、コード生成用のAgent Hostを占有させません。待機だけが増えるならキュー制御を見直し、実行時間が詰まる場合に限って容量を増やします。

現在の構成からの移行判断

Agent HostとXcodeを同じMacで動かす方式は、初期費用や受け渡しの手間を抑えやすい反面、作業途中の状態がビルドへ混ざり、長時間ジョブがAgentを占有し、証明書やキャッシュの境界も曖昧になります。一般的なCI RunnerだけでApple向けの証明まで済ませようとする構成も、macOS固有の検証、署名、実機に近い確認を別途説明しなければなりません。

そのため、短期の試作では現状維持、Xcodeの再現性が問題になった段階ではビルド層を分離、ピーク時の待機が継続する段階ではクラウドMacの基礎池と弾性池を分ける、という順序が現実的です。必要な時間だけMacを借りてPR検証や一時的なXcode作業を行うなら、kvmsyncの料金案内で利用条件を確認し、既存の三層表に自社のPR経路を当てはめてください。

最終更新：2026年9月20日。VS Code 1.138のリリースノート、Agent Hostの公式ドキュメント、GitHub ActionsのRunner・成果物・ログ資料、GitHubの保護ブランチ資料を基に内容を確認しています。
Agent Mergeの提供範囲、権限モデル、Agent Hostのリモート実行方式が変わった場合は、同じコミットによるPR作成、CI実行、Macビルド、再接続復旧を再検証してください。