Apple公式の説明では、Apple ContainerはApple silicon搭載MacとmacOS 26でLinuxコンテナを実行する仕組みです。AppleのContainerization公式説明に照らすと、Cursor Agentチームサンドボックス設定は、全員に同じ権限を与える設計では成立しません。今週は、通常の開発はCursor標準サンドボックス、依存導入や高リスクのスクリプトはApple Container、署名と公開は承認付きの独立Mac環境へ分ける方針に切り替えるのが妥当です。
この記事は、チームの実行基準を決める開発責任者、依存関係や一括変換を扱うリポジトリ保守担当、キャッシュとテスト環境を管理する構築担当、そして署名・公開を担う担当者向けです。個人の事故対策ではなく、担当業務ごとに許可資源と責任の境界を設計したい場合に適しています。
最初に決めるチーム権限の境界
一つの緩い設定を全員へコピーし、一般の開発者にも構築と公開の権限が同時に付与される失敗は、個別の誤削除より組織的な影響が大きくなります。問題はCursor Agentの性能ではなく、誰がどの資源へ到達でき、失敗時に誰が復旧を承認するかが決まっていないことです。
CursorのRun Modes公式仕様では、実行モードごとに確認や自動実行の扱いを調整できます。また、ターミナル操作には保護機能があるため、日常のコード生成、静的解析、単体テストは、まず標準サンドボックスと確認操作の組み合わせで運用します。
ただし、ワークスペースを書き込み可能にしただけではデータ保護になりません。作業開始前にブランチを分けるか、復元可能な複製を用意し、ホームディレクトリ、SSH鍵、クラウド認証情報、汎用の資格情報フォルダーは対象外にします。復旧可能性を先に作ることが、最小権限の前提です。
役割別の許可資源と昇格経路
個人開発者の最小権限
個人開発者は、現在のリポジトリ内のソース、テスト用の一時ファイル、ローカルの静的解析結果だけを基本資源にします。外部通信は依存取得など必要な場合に限り、任意の送信先を許可するのではなく、パッケージ配布元をチームで確認します。
禁止するのは、ホーム全体の書き込み、認証情報の読み取り、シェル設定の変更、確認なしの破壊的操作です。データベース移行や外部サービスへの書き込みが必要になった場合は、個人設定を緩めるのではなく、保守担当または構築用の隔離環境へ申請します。
機能開発メンバーのリポジトリ単位隔離
Cursorのsandbox.jsonフィールド説明を確認し、ユーザー単位の設定とプロジェクト単位の設定を分けて管理します。前者は組織の最低基準、後者はリポジトリ固有の読み取り・書き込み範囲や依存取得の例外を定義する場所です。チームポリシーがある場合、プロジェクト側で無制限に緩和できない優先関係を確認しておきます。
許可範囲は、現在のリポジトリを読み書き可能、共有資料は読み取り専用、ジョブ専用の一時領域は期限付き書き込み可能、という分け方が扱いやすいです。主ディレクトリ全体や共通の認証情報ディレクトリをマウントすると、別プロジェクトのソースやトークンまでAgentの到達範囲に入るため避けます。
リポジトリ保守担当の高リスク実行区
移行、コード生成、一括置換、第三者スクリプトの実行は、ワークスペースだけを制限しても不十分な場合があります。依存関係のインストール処理がユーザー領域へ設定を書き込んだり、生成ツールが想定外のパスを走査したりするためです。
この場合は、復元可能な一時リポジトリへ必要な入力だけを複製し、Apple Container内で処理します。出力は専用の受け渡しディレクトリだけへ戻し、元の作業ツリーへ直接書き込ませません。Apple Containerのボリューム仕様にある読み取り専用の扱いを確認し、入力、出力、キャッシュを別々に設計します。
Apple Containerが実行するのはLinuxワークロードです。Xcode、macOS専用のビルドツール、シミュレーター、キーチェーン、コード署名をそのまま代替できるものではありません。この境界を無視して「すべてをコンテナへ移す」と、保守担当の作業が途中で止まります。
構築・テスト担当のキャッシュと通信例外
構築担当には、パッケージ配布元、コンテナレジストリ、テスト用サービス、共有キャッシュという追加資源が必要です。しかし、構築を成功させるために全通信やホストの広い範囲を許可するのは、障害時の影響範囲を広げます。
Apple Containerのネットワーク設定を参照し、許可ドメイン、読み取り専用パス、ジョブ専用の書き込みキャッシュ、例外の期限を記録します。キャッシュが消えた場合は、全ネットワークへ降格するのではなく、承認済みの配布元から再取得する経路へ切り替えます。外部サービスが使えないテストは、モックまたはオフライン用の固定データへ切り替える手順をあらかじめ用意します。
| 役割 | 標準で許可する資源 | Apple Containerへ移す作業 | 禁止または承認が必要な操作 |
|---|---|---|---|
| 機能開発 | 現在のリポジトリ、静的解析、単体テスト | 原則不要 | ホーム全体、認証情報、外部書き込み |
| リポジトリ保守 | 複製した作業ツリー、限定した入出力 | 移行、一括変換、第三者スクリプト | 元リポジトリへの直接上書き |
| 構築・テスト | 限定ドメイン、専用キャッシュ、テスト資源 | 外部依存が多い再現可能なジョブ | 全通信、共有キャッシュへの無制限書き込み |
| 署名・公開 | 検証用成果物のみ | コード準備と構築確認 | 証明書、キーチェーン、公開トークン |
| プラットフォーム管理 | 監査記録、テンプレート、検証用環境 | 破壊的テストと隔離検証 | 本番操作の自動承認 |
FAQ:役割ごとの設定判断
Cursor Agentチームサンドボックス設定の配布単位
ユーザー共通の最低権限と、リポジトリ固有の必要資源は別管理にします。同じsandbox.jsonを全員へ配ると、機能開発者が構築・公開向けの例外まで引き継ぐためです。権限を増やす場合は、担当者、対象作業、許可パス、許可ドメイン、終了日を申請に記録します。
Apple Containerへ移す作業
依存導入、データベース移行、生成処理、一括改変、出所を精査できないインストールスクリプトは、作業ツリーの複製と最小限の入出力を使って隔離します。一方、Xcode、署名、シミュレーターなどMac固有の工程は、管理されたMac側で別に実行します。
構築担当のキャッシュ設計
キャッシュは共有する場合でも読み取り専用を基本にし、書き込みはジョブごとの領域へ限定します。依存関係の取得先は許可ドメインとして明示し、期限のない例外を残しません。キャッシュが使えない場合の再取得手順と、外部サービスをモックへ置き換える手順も同じテンプレートに記載します。
署名・公開情報の扱い
証明書、秘密鍵、キーチェーン、公開用トークンは、通常のCursor Agent会話にも汎用コンテナにも渡しません。成果物の準備と構築確認を隔離環境で済ませ、署名と公開は管理されたMacで人が差分と対象環境を確認して実行します。
署名と公開を分離する実行境界
公開担当の作業は、コード準備、構築確認、署名、公開の4段階に分けます。前半はApple ContainerまたはCursor標準サンドボックスで再現性を確保できますが、後半はMac固有のツールチェーンと秘密情報を必要とするため、通常のAgentから切り離します。
Cursorへ署名用の鍵を環境変数で渡す方法も、ログ、子プロセス、誤った送信先への漏えいを完全には防げません。署名対象のハッシュや成果物だけを受け渡し、管理者が承認してからキーチェーンへアクセスする設計にします。App Store公開の手順を運用に含める場合は、App Store Connectの通知と公開フローに関する手順も、署名処理と混同しない形で確認します。
チーム導入の条件分岐
次の条件でテンプレートを選ぶと、ツール名ではなく作業リスクに沿って判断できます。
- 現在のリポジトリ内だけで生成、静的解析、単体テストを行うなら、Cursor標準サンドボックスを選びます。復元可能なブランチがない場合は、実行を止めて先に複製を作ります。
- 依存導入、一括変換、移行、第三者スクリプトがあり、入力と出力を限定できるなら、Apple Containerを追加します。入力を読み取り専用にできない場合は、作業を承認制へ戻します。
- パッケージ取得やテストサービスが必要でも、許可ドメインと専用キャッシュを列挙できるなら、期限付きの構築例外を付与します。列挙できない場合は、隔離した再現環境へ移します。
- Xcode、シミュレーター、キーチェーン、署名が必要なら、Apple Containerだけで完結させません。管理されたMac環境で人の確認を必須にします。
- 複数人が同時に高リスク処理を行う、または従業員端末へ秘密情報を置けないなら、独立したクラウドMac環境を候補にします。物理デバイス接続や長期の安定した高負荷が必要なら、専用の自社Macや別の運用方式も比較します。
プラットフォーム担当の運用マトリクス
| 管理項目 | 記録する内容 | 見直し条件 |
|---|---|---|
| テンプレート版 | Cursor設定、Apple Container設定、所有者 | 仕様変更または安定版更新 |
| 例外申請 | 作業目的、パス、ドメイン、担当者、終了日 | 作業完了または期限到来 |
| 破壊的テスト | 複製環境、想定損害、復旧方法 | 新しいスクリプト導入時 |
| 公開工程 | 成果物、承認者、署名環境、実行記録 | ツールチェーン変更時 |
| 回 rollback責任 | 復元担当、停止条件、連絡経路 | 担当者変更または障害後 |
AppleのWWDC25 Containerizationセッションと、Containerizationのアーキテクチャ説明を基準資料にし、Apple Containerの安定版更新時には、ホスト要件、マウント、ネットワークの挙動を再確認します。Cursor側もRun Modesやsandbox.jsonの仕様が変われば、チームテンプレートをそのまま信頼せず、許可範囲を再検証します。
従業員のMacだけで運用する方式は、OSやツールの差異が残りやすく、秘密情報が日常端末に滞留し、同じ端末上の別作業とAgentの実行面が競合しやすいという欠点があります。署名公開や機密リポジトリを複数人で扱うなら、独立したMac環境へ実行面を分けるほうが、権限記録と回収を管理しやすくなります。
一方で、物理インターフェースが必要な作業、長期間の固定負荷、社内規定で外部環境を使えない工程には、レンタルが適さない場合もあります。短期の検証、チーム並行作業、従業員端末から署名環境を切り離す目的なら、JexMacのMac環境と、利用条件を確認できる料金案内を候補に加え、まず本文の役割権限マトリクスで移行対象を絞るのが現実的です。
よくある質問
Cursor Agentのチームメンバー全員で同じsandbox.jsonを使うべきですか?
同じファイルを全員に配布する運用は避けるべきです。ユーザー単位の基本方針とプロジェクト単位の制限は目的が異なり、構築や公開担当まで同じ許可を持つと権限が過剰になります。一般の開発者は現在のリポジトリだけを書き込み可能にし、担当業務に応じた例外を申請制で追加します。
どの開発作業でApple Containerを重ねて使うべきですか?
依存関係の導入、移行処理、コードの一括変換、生成スクリプト、提供元を十分に確認できないインストールスクリプトなど、作業ディレクトリ以外へ影響し得る処理が対象です。Apple ContainerはLinuxワークロードを隔離する仕組みなので、XcodeやシミュレーターなどMac固有の処理まで置き換えるものではありません。
構築担当者はCursor Agentにキャッシュと依存関係のディレクトリをどう許可しますか?
共有キャッシュは必要な場所だけを読み取り専用で公開し、書き込み先はジョブ専用のキャッシュに分けます。パッケージ取得先も許可ドメインを列挙し、全通信を開放しないことが重要です。キャッシュが無効になった場合に、ネットワークを広げるのではなく、依存関係を再取得する限定経路へ切り替えます。
コード署名用の証明書や公開用トークンをCursor Agentに渡せますか?
通常のAgentセッションや汎用コンテナへ渡すべきではありません。コードの準備と構築確認までは隔離環境で行い、署名と公開は管理されたMac環境で人が内容を確認して実行します。Apple ContainerはmacOSのキーチェーン、Xcode署名、シミュレーターをそのまま提供する仕組みではないため、秘密情報の代替にもなりません。
チームに適したMac環境をJexMacで整えませんか
担当業務や検証内容に応じて、必要なMac環境を柔軟にご利用いただけます。