公式のGemini CLI設定文書には、状態保存先を分けるためのGEMINI_CLI_HOMEが記載されています。設定リファレンスが示す通り、状態ディレクトリを分けることは有効です。ただし、それだけで安全な共有環境にはなりません。
結論は明確です。共有してよいのは、条件を満たした物理Macの計算資源です。管理者アカウント、macOSのユーザー身份、Gemini CLIの状態、プロジェクト作業領域、認証情報、Appleの署名資格情報は共有しません。 通常の開発補助は独立アカウントで同一ホストを使えますが、Agentの自動処理と正式リリースは隔離ノードまたは専用ノードへ分けます。
[ SECTION_01 ] 対象となる責任者
本稿は、複数の開発者へGemini CLIを配布する企業IT責任者向けです。共有ホストの安全境界と、アカウント撤権の証拠を決める場面を対象にします。
iOSやmacOSの流水線を管理する研发効率チームには、Agentの作業領域を本番署名資産から切り離す判断基準を示します。セキュリティ監査と算力調達を担う管理者には、共有ノード、Agent隔離プール、署名専用ノードを選ぶための検証項目を整理します。
[ SECTION_02 ] 共有の三層境界
「1台を共有する」という表現には、少なくとも三つの意味があります。ここを分けずに導入すると、物理ホストの共有が、管理者資格情報の共有へ拡大します。
- 物理ホストの共有：条件付きで許容できます。利用者ごとにOSアカウント、作業領域、認証状態を分けます。
- macOSアカウントの共有：原則として不可です。履歴、SSH鍵、環境変数、Keychain、シェル設定が混ざります。
- Gemini CLI状態の共有：不可です。履歴、設定、認証状態、プロジェクト規則が利用者間で交差する可能性があります。
root権限を持つ遠隔Macでは、サンドボックスを強く設定しても、管理者自身がポリシーファイルや権限を変更できる問題が残ります。公式Sandbox文書の機能説明と、悪意ある管理者への防御を混同してはいけません。
判断時には、次の五項目を先に記録します。
- タスクの入力元。社内リポジトリ、外部プルリクエスト、生成物の再利用など。
- データの機密度。公開コード、社内コード、顧客情報、署名資格情報など。
- 失敗時の影響。作業の再実行で済むか、公開やリリース事故につながるか。
- 認証の種類。個人ログイン、サービスアカウント、短期トークンのどれか。
- 交代と撤権の方法。担当者の異動や退職時に、何をいつ無効化するか。
この評価で、低リスク開発は共有ホスト、高リスクAgentは隔離プール、正式署名は専用ノードへ振り分けます。
[ SECTION_03 ] 開発者向けのアカウント分離
担当範囲
開発チームの責任は、各メンバーに独立したmacOSログイン身份を割り当てることです。共有の管理者アカウントに全員がVNCやSSHで入る方式は、誰がどのファイルを読んだかを後から説明できません。
各アカウントには、別々のホームディレクトリ、プロジェクト作業領域、Gemini CLI設定を持たせます。GEMINI_CLI_HOMEは状態保存先を分離する手段ですが、OSのユーザー権限を代替するものではありません。
検証動作
受け入れ試験では、次を一人ずつ確認します。
- アカウントと担当者の対応表が存在する。
- 利用者Aの作業領域を利用者Bが読み取れない。
- AのGemini CLI履歴、設定、認証状態がBのセッションに表示されない。
- Aが作成した一時ファイルを、Bの標準作業領域から参照できない。
- 退職または異動を想定し、ログイン、SSH鍵、トークン、共有フォルダーを撤回できる。
ここで一つでも越境が確認された場合、共有ホストの採用を止めます。先に専用アカウントとディレクトリ権限を直し、再試験を行います。
引き継ぎ先
アカウント表と読み取り試験の結果は、セキュリティ担当へ渡します。個人認証を使うのか、企業管理の認証方式を使うのかは、Gemini CLIの認証文書にある対象バージョンの説明と照合します。
[ SECTION_04 ] CI Agentの隔離
自動化担当の責任
CI Agentは、開発者の対話セッションをそのまま継承させません。専用サービスアカウント、実行ごとの一時作業領域、明示的な入力元を用意します。
Agentが利用する認証は、個人のログイン状態から分離します。処理終了後は、作業領域、生成された一時ファイル、キャッシュ、状態ディレクトリを消去した記録を残します。
ポリシーと非対話実行
企業設定では、システム側の設定、ツールの許可・拒否規則、非対話モードのコマンド範囲を確認します。Policy Engineの公式仕様では、ポリシーの配置と判定順序を対象バージョンごとに確認しなければなりません。
「サンドボックスを有効にした」という表示だけでは不十分です。拒否すべきコマンドを実際に実行し、終了コード、監査記録、ネットワーク出口、作業領域の残存を確認します。
外部投稿や信頼できないブランチを処理する場合は、使い捨ての作業領域、または専用の遠隔Macへ移します。共有ホストで処理するなら、入力データと社内資格情報が同じユーザー境界に入らない設計が必要です。
注意：macOSのサンドボックスやGemini CLIのポリシーは、誤操作や許可外ツールの実行を減らすための制御です。root権限を持つ利用者や侵害済み管理者から、署名鍵や他ユーザーのデータを完全に守る仕組みとして扱ってはいけません。
交付する証拠
Agent担当者は、次の証拠をセキュリティ担当へ引き継ぎます。
- サービスアカウントの所有者と用途。
- 作業領域の作成・消去ログ。
- 許可・拒否したツールとコマンドの結果。
- 実行終了後に残った状態ファイルの確認結果。
- ネットワーク出口と企業プロキシの適用結果。
- プロンプトやソースコードを含めないテレメトリ設計。
[ SECTION_05 ] セキュリティ担当のポリシー確認
セキュリティチームは、設定ファイルが存在するかではなく、実行時に本当に効いているかを確認します。Enterprise設定、Configuration、Policy Engineを、同じリリースタグまたはコミットへ固定して照合します。
確認対象は以下です。
- システム設定とユーザー設定の優先順位。
- 管理者用ポリシーの配置場所とファイル権限。
- 許可リストと拒否リストの実効結果。
- サンドボックスの提供方式と適用範囲。
- モデル認証の保存先と撤回手順。
- 監査ログに秘密情報が残らないこと。
- VNC、SSH、コンソール経由で同じ境界が維持されること。
公式文書のmainブランチは更新される可能性があります。導入時は最新Releaseを確認し、採用したタグまたはコミットを社内記録へ残します。公式Release一覧に変更があれば、ポリシーの優先順位、Sandbox、認証方式を再試験します。
[ SECTION_06 ] Xcode署名の専用境界
リリース担当の責任
Gemini CLIの一般開発ワークスペースから、Xcodeの正式署名に使う証明書秘密鍵、リリース用Keychain、App Store Connect資格情報へ到達できない状態を標準にします。
開発支援Agentは、コード変更、テスト結果、ビルド案の作成までに限定します。アーカイブ、署名、アップロードは、受け入れ済みの入力だけを受け取る専用Macと管理対象の流水線で実行します。
最小権限の確認
署名境界の試験では、次の操作だけを行います。
- Agentノードから署名用Keychainを検索できないこと。
- 開発用証明書と正式証明書の保存先が分かれていること。
- App Store Connect用APIキーの読み取り経路が専用ノードだけに限定されること。
- 署名専用ノードへ未承認のブランチや任意の生成物を渡せないこと。
- ノード再起動後も、資格情報が意図せずログインセッションへ戻らないこと。
App Store ConnectのAPIキーは、発行後の秘密鍵管理も含めて、公式のAPIキー作成文書と社内の資格情報管理基準を照合します。
署名ノードを共有開発ホストへ統合する設計は、監査対象を広げます。開発者の履歴、Agentの入力、署名鍵の利用記録が同一環境に集まるためです。署名が必要な組織では、開発共有ホストとリリース専用ノードを分ける方が、否決条件を明確にできます。
[ SECTION_07 ] 運用試験とノード選定
性能値や同時実行数を一般化する前に、企業自身のタスクで試験します。特定の構成、価格、地域、納期について本稿で根拠のない数字は提示しません。
試験は次の順で実施します。
- 固定開発者が独立アカウントでログインする。
- 同時に複数の作業領域を作成し、履歴と認証状態を確認する。
- Agentが一時領域で処理し、終了後に残存ファイルを調べる。
- 外部入力を含むブランチを、共有ホストと隔離ノードで比較する。
- Macを再起動し、ポリシー、アカウント権限、作業領域の消去状態を再確認する。
- 利用者の撤権後に、VNC、SSH、CLI認証、共有ディレクトリへ入れないことを確認する。
- 失敗時の担当者、復旧手順、証拠の保管場所を確定する。
チームの人数だけでノード数を決めるのは適切ではありません。重要なのは、同時実行の波、作業領域の消去時間、再起動後の復旧、入力データの機密度、署名処理の有無です。
チーム向けMac miniの調達条件を確認する場合も、購入台数だけでなく、固定資産化、保守担当、交換時のデータ消去、設置場所まで比較します。短期PoCや変動するAgent処理では、遠隔Macの利用案内と自社のセキュリティ試験を組み合わせ、先に小さな隔離環境で証拠を取ります。
[ SECTION_08 ] 選択肢の比較と採点
次の表は、導入前の判断に使う簡易スコアです。点数は一般的な性能値ではなく、隔離設計と監査のしやすさを比較するための目安です。自社の試験結果で置き換えてください。
| 選択肢 | 適したタスク | 認証・状態の境界 | 監査のしやすさ | 否決条件 | 初期評価 |
|---|---|---|---|---|---|
| 開発者向け共有ホスト | 低リスクのコード補助、個人開発 | 個別macOSアカウントと作業領域 | 中 | 他ユーザーの読み取り、共有ログイン | 条件付き |
| Agent隔離プール | 外部入力、並列自動化、使い捨て処理 | サービスアカウントと一時領域 | 高 | 状態や資格情報が次の実行へ残る | 推奨 |
| 署名専用ノード | Xcodeの正式署名、公開処理 | 専用Keychainと限定された認証 | 高 | Agentノードから鍵へ到達できる | 必須 |
| 管理者アカウントの共有 | 全種類 | 境界を証明しにくい | 低 | 監査不能、撤権不能 | 不採用 |
スコアを決める際は、「共有できるか」ではなく「失敗したときに誰が、どの証拠で、どの範囲を止められるか」を見ます。開発共有が合格しても、正式署名の合格を意味しません。
[ SECTION_09 ] 受け入れチェックリスト
| 役割 | 必須確認 | 証拠 | 否決条件 | 引き継ぎ先 |
|---|---|---|---|---|
| IT管理 | アカウントと権限の対応 | アカウント表、撤権記録 | 共有管理者アカウント | セキュリティ |
| 開発 | 履歴、状態、作業領域の分離 | 相互読み取り試験 | 他ユーザーのファイルが見える | IT管理 |
| CI Agent | 一時領域と終了後の消去 | 実行ログ、残存確認 | 個人認証を継承する | 研发効率 |
| セキュリティ | ポリシー、サンドボックス、出口制御 | 設定権限、拒否試験 | 管理者が容易に迂回できる | リスク管理 |
| リリース | Xcode署名とアップロードの分離 | Keychain到達試験 | Agentから秘密鍵へ到達する | リリース責任者 |
| 運用 | 再起動、復旧、撤権 | 復旧記録、再試験結果 | 再起動後に設定が変わる | IT管理 |
この表をPoCの合否記録にします。いずれかの否決条件に該当した場合、共有ホストの利用範囲を低リスク開発へ戻すか、Agent隔離プールまたは専用ノードへ移します。
[ SECTION_10 ] FAQ
FAQでは、検索時に多い判断を実際の運用条件へ置き換えます。製品のインストール手順ではなく、共有境界の確認を優先します。
[ SECTION_11 ] 現在の構成とMac構成の比較
開発者が各自のMacを購入する構成は、個人作業には向いています。しかし、端末ごとにXcode、CLI設定、証明書、OS更新、退職時の消去を管理する負担が増えます。1台のMacへ全員が同じアカウントで入る方法は、費用を抑えられても、履歴、認証、監査、署名資産が混ざります。
短期の検証や利用量が変動するAgent処理では、NOVAKVMのリモートMacを隔離PoCの候補にすると、物理端末の一括購入、設置、交換、遊休期間を避けながら構成を試せます。反対に、長期かつ常時高負荷で固定利用する場合、物理Macの購入や自社管理の方が適することもあります。物理USB機器や社内ネットワークへの直接接続が必須なら、レンタルだけで完結しません。
まずは1台を使い、本文の役割別チェックリストでアカウント、状態、Agent、署名、再起動、撤権を検証します。共有アカウントや本番署名の分離に失敗した場合は、開発共有ホストを無理に拡大せず、Agent隔離プールと署名専用ノードを組み合わせる判断へ切り替えます。
最終更新：2026年9月13日。Gemini CLIのRelease、Enterprise、Configuration、Policy Engine、Sandbox、Authentication関連文書、およびApple DeveloperのAPIキー文書を確認しています。公式文書や提供方式が更新された場合は、採用したタグまたはコミットを固定して隔離試験を再実施してください。