Gemini CLI サンドボックスモード：有効化、バックエンド、YOLO 対策
Gemini CLI のサンドボックス化を図解で無駄なく解説。-s で起動し、常時有効化し、OS に合ったバックエンドを選び、YOLO モードに安全装置を付けるところまで。
要点まとめ
- gemini -s を実行すると、シェルコマンド・ファイル編集・ネットワーク通信を含むセッション全体が隔離サンドボックス内で動作します。フッターにサンドボックス表示が出るので有効か一目で分かります。
- 有効化は 3 通り、優先順位の高い順に -s / --sandbox フラグ、GEMINI_SANDBOX 環境変数、settings.json の tools オブジェクト内の "sandbox": true です。
- バックエンドは OS ごとに選択：macOS は Seatbelt プロファイル（既定は permissive-open）、Linux は最強の gVisor runsc、それ以外は Docker または Podman コンテナ。
- YOLO モード（--yolo）はすべての権限確認をスキップします——サンドボックスと併用を。v0.61.0（2026 年 9 月 23 日）でサンドボックスのファイルシステム境界が強化され、ランタイム状態も分離されました。
Gemini CLI Essentials – Full Course (sandboxing chapter)
チャンネル：freeCodeCamp.org3:49:40
Gemini CLI: Everything You Need To Know (Full Tutorial)
チャンネル：lustoykov42:54
Sandboxing in Gemini CLI — official documentation
公式ドキュメント：google-gemini/gemini-cli (GitHub)
スクリーンショットは freeCodeCamp コースのサンドボックス章から。フラグ名・設定項目・プロファイル名は公式サンドボックスドキュメントと v0.61.0 リリースノートで照合済みです。
スクリーンショット出典：freeCodeCamp.org および lustoykov——視覚的参考として出典付きで利用。手順文はすべて当サイトのオリジナルです。
Gemini CLI を段階的にサンドボックス化
最初のサンドボックスセッションを起動
- 1
サンドボックスが何を隔離するのか知る
サンドボックスは、AI エージェントが危険になり得る操作——シェルコマンド、ファイル書き込み、ネットワークアクセス——をホストから切り離します。Gemini CLI v0.61.0（2026 年 9 月 23 日）はサンドボックスのファイルシステム境界を強化し、ランタイム状態を分離。ビルドファイルや信頼できないフラグ経由の間接プロンプトインジェクション経路を塞ぎました。
サンドボックスの正体：OS ごとに選ばれる隔離ライブラリ。140:00 に視聴 - 2
フラグでそのままサンドボックス起動
最短ルートはコマンドフラグ：gemini -s（長い形は --sandbox）を実行します。初回はサンドボックスイメージの取得で時間がかかることがあります。単発実行ならプロンプトと組み合わせて gemini -s -p "analyze the code structure" のようにします。
フラグを付けて、フッター表示を確認——それだけの簡単なチェック。140:50 に視聴 - 3
3 つの有効化方法と優先順位を理解する
Gemini CLI はサンドボックス設定を優先順位で解決します。まず -s / --sandbox コマンドフラグ、次に GEMINI_SANDBOX 環境変数（true・docker・podman・sandbox-exec・runsc・lxc）、最後に settings.json の tools オブジェクト内の "sandbox" エントリです。
公式ドキュメントが 3 つの方法を優先順位付きで列挙しています。145:45 に視聴 - 4
フッターでサンドボックス有効を確認
CLI が起動すると、ステータスフッターにサンドボックスのバージョン表示が現れ、モデルセレクターの横に並びます。表示がなければサンドボックスは無効——有効化したつもりのフラグや設定を見直しましょう。
実セッションの例：Auto (Gemini 3) の隣にサンドボックス表示。146:40 に視聴
OS に合ったバックエンドを選ぶ
- 5
macOS は内蔵の Seatbelt を活用
macOS はコンテナ不要です。Gemini CLI は Seatbelt（sandbox-exec）でプロセスを包みます。既定プロファイルの permissive-open は書き込みをプロジェクトディレクトリに制限し、読み込みとネットワークは開放。厳しくするには SEATBELT_PROFILE 環境変数で permissive-proxied・restrictive-open・restrictive-proxied・strict-open・strict-proxied を選びます。
- 6
Linux / WSL2 は gVisor runsc へ
Google の gVisor（runsc ランタイム）は最高強度の隔離を提供します。コンテナはすべてのシステムコールを横取りするユーザースペースカーネル上で動きます。GEMINI_SANDBOX=runsc または "sandbox": "runsc" で明示的に選択（自動検出されません）すると、Gemini CLI が docker run --runtime=runsc を実行してくれます。
ドキュメントは runsc を最強の Linux 専用バックエンドと位置付けています。141:20 に視聴 - 7
runsc ランタイムをインストール
Ubuntu（ネイティブでも WSL2 内でも）なら apt 一発で入ります：sudo apt get install runsc。Gemini CLI は runsc を単体ツールではなく Docker ランタイムとして扱うため、Docker もインストール済みで起動している必要があります。
WSL2 の Ubuntu ターミナルでインストールコマンドを入力。143:35 に視聴 - 8
インストール結果を確認
apt は runsc を Ubuntu のセキュリティアップデートリポジトリからそのまま展開します。追加 PPA は不要。この工程を飛ばすと、Linux での gemini -s が失敗するか黙ってコンテナバックエンドにフォールバックするので、初回のサンドボックス実行前にパッケージを確認しましょう。
Ubuntu 24.04 で runsc の展開が完了したところ。144:15 に視聴 - 9
コンテナ派は Docker / Podman でどの OS でも
コンテナベースのサンドボックスは Docker や Podman が動く環境ならどこでも使えます。開始前にインストールと起動まで済ませ、docker を一度実行して応答を確認してください。既定では ghcr.io/google/gemini-cli:latest イメージを使い、作業ディレクトリはホストと同一の絶対パスでコンテナ内にマウントされます。
docker を一度実行してエンジンの応答を確認。145:30 に視聴
YOLO モードを安心して走らせる
- 10
サンドボックスと YOLO モードを組み合わせる
gemini --yolo（--approval-mode=yolo の略称）はすべての権限確認を危険を承知でスキップします。自律実行に必要な挙動であり、まさにサンドボックスの出番です。サンドボックスフラグ付きで YOLO セッションを起動すれば、スキップされた確認も隔離環境の中に収まります。
YOLO モードを一枚で解説：中断なし、全権限をそのまま実行。148:20 に視聴 - 11
自律実行がサンドボックス内に留まったことを確認
YOLO セッション中はフッターが青い YOLO Mode バッジに切り替わり、権限確認がスキップされている合図になります。実行後は /stats のインタラクション概要でどのツールが動いたか分かり、サンドボックス表示が「箱の中で作業した」証拠として残ります。
自律セッション終了後のフッターに輝く YOLO Mode バッジ。147:40 に視聴
カスタムサンドボックスイメージとコンテナフラグ
既定のコンテナイメージは汎用コーディングには十分です。プロジェクト固有のツールチェーンが必要なとき、コンテナ環境がどうも思いどおりにならないときは、4 つの調整ポイントが用意されています。
- 1任意のイメージを指定：GEMINI_SANDBOX_IMAGE を設定するか、settings.json でオブジェクト形式 "sandbox": "command": "docker", "image": "..." (a JSON object) を使います。bash が入っている Docker / Podman イメージなら何でも可。
- 2自前ビルド：プロジェクトルートに .gemini/sandbox.Dockerfile を置き、BUILD_SANDBOX=1 で実行すると Gemini CLI が自動ビルドします。自動ビルドはソースから実行している場合のみ有効で、npm インストールではビルド済みイメージを参照してください。
- 3コンテナコマンドの調整：SANDBOX_FLAGS で docker/podman に追加フラグを渡せます。例えば export SANDBOX_FLAGS="--security-opt label=disable" は Podman で SELinux がボリュームマウントを拒否する場合の定番の対処です。
- 4Linux のファイル所有者を修正：サンドボックスはユーザー権限を自動マッピングしますが、生成ファイルの所有者が違うときは SANDBOX_SET_UID_GID=true でホストの UID/GID を強制できます。
Gemini CLI 自身をコンテナ内で動かしつつサンドボックス化する場合は、/var/run/docker.sock をマウントして CLI がホストデーモン経由で兄弟コンテナを起こせるようにし、ワークスペースのパスをホストの絶対パスと完全に一致させてください。ボリュームマウントを解決するのはコンテナではなくホスト側デーモンです。
トラブルシュート：エラー、ファイルアクセス、無効化
サンドボックスのトラブルは 5 つの型にほぼ集約されます。まずはデバッグ出力で再現から：DEBUG=1 gemini -s -p "your prompt"。
- 1「Operation not permitted」——コマンドがサンドボックス外へのアクセスを求めています。より緩いプロファイル（macOS：SEATBELT_PROFILE）に切り替えるか、必要なマウントを追加してください。
- 2サンドボックス内にコマンドがない——必要なツールをカスタムイメージに焼き込むか、sandbox.bashrc でインストールします。BUILD_SANDBOX 自動ビルドはソースチェックアウト専用です。
- 3ネットワーク不通——現行プロファイルがネットワークを許可しているか確認し、プロキシ設定も検証。-proxied 付きプロファイルはサンドボックスプロキシ経由で通信します。
- 4Linux で生成ファイルの所有者が違う——SANDBOX_SET_UID_GID を切り替えます（true でホスト UID/GID を強制、false でマッピング無効）。
- 5Windows でファイルが Low 整合性のまま——ネイティブサンドボックスは icacls で書き込み可能パスに印を付けます。icacls "C:\path\to\dir" /setintegritylevel Medium で戻せます。
サンドボックスから見える範囲を確かめるには CLI に聞きます：gemini -s -p "run shell command: env | grep SANDBOX" でサンドボックス環境変数一覧、mount | grep workspace でマウント一覧。ファイルの書き出しは不要で、コンテナサンドボックスはプロジェクトを同一絶対パスでマウントするので編集は直接フォルダに反映されます。無効化は -s フラグを外す・GEMINI_SANDBOX を unset・settings.json の "sandbox" エントリ削除。ツールレベルのサンドボックスは "security": "toolSandboxing": false の専用スイッチ（要再起動）です。