はじめに
AI コーディングエージェントをターミナルから使うときの不安は「勝手にコマンドを実行されてホスト(PC)環境を壊されないか」です。
IBM の Bob Shell（bobshell） には、この不安を解消する Sandbox（サンドボックス） 機能が用意されています。
本記事では、Bob Shell の Sandbox についてまとめました。
- Bob Shell / Sandbox とは何か（概要）
- 設定の仕組み（レイヤード構成）と Sandbox の構成
- 導入から有効化までの手順
- カスタマイズ方法（カスタム Dockerfile・カスタムモード・信頼フォルダ・承認モード）
⚠️ 本記事は IBM Bob 公式ドキュメント（bob.ibm.com/docs/shell）をもとにまとめています。活発に更新されるため、導入時は必ず公式ドキュメントで最新仕様を確認してください。
記事の作成にAIを使用した調査、文章作成、動画作成、校正を行っております。
動画
本記事を元に作成した動画を公開しています。理解の一助にご参照ください。
Bob Shell とは
IBM Bob は、ソフトウェア開発ライフサイクル（SDLC）全体を支援する AI コーディングエージェントです。
その中で Bob Shell は、ターミナル（CLI）上で動作する Bob です。IDE 版と同じコンテキスト認識・推論能力を、シェル環境向けに最適化したもので、次のような用途に使えます。
- シェルスクリプトの生成・最適化
- ターミナルコマンドの実行支援・検証
- コマンド失敗のデバッグ、ログ解析
- プロジェクトの雛形生成
実行形態は 対話セッション（interactive） と 非対話セッション（non-interactive、自動化・スクリプト向け） の両方に対応します。ダウンロードは公式のダウンロードページから、Mac (ARM/Intel)、Windows x64、Linux (.deb / RPM) 向けに入手できます。
Sandbox とは — なぜ必要か
Bob Shell にコマンド実行を任せると便利な一方で、ファイルの誤削除・上書き、ホスト環境への意図しない変更といったリスクが生じます。特に各操作を承認なしで自動実行する --yolo（You Only Live Once）モード ではリスクが顕著です。
Sandbox は、潜在的に危険な操作を隔離環境で実行してホストシステムを保護する仕組みです。公式でも、yolo のように承認なしで動かす場合は Sandbox 内で実行することが推奨されています。
Bob Shell の Sandbox には大きく 2 つの方式があります。
-
macOS Seatbelt：macOS 組み込みの軽量サンドボックス（
sandbox-exec） - コンテナ方式：Docker / Podman を使ったクロスプラットフォームな隔離
設定の仕組み（レイヤード構成）
Bob Shell の設定は、複数のソースを優先度順に重ね合わせる レイヤード方式です。同じ設定が複数箇所にある場合は、優先度の高いソースが勝ちます。
| 優先度 | ソース | 場所 |
|---|---|---|
| 1（最高） | コマンドライン引数 | bob --option value |
| 2 | 環境変数 | シェル / .env
|
| 3 | システム設定 |
/etc/bobshell/settings.json ほか OS 別 |
| 4 | プロジェクト設定 | .bob/settings.json |
| 5 | ユーザー設定 | ~/.bob/settings.json |
| 6 | システムデフォルト | system-defaults.json |
| 7（最低） | ハードコードされたデフォルト | Bob Shell 組み込み |
設定方法は主に 3 つです。
-
プロジェクト単位：プロジェクト直下に
.bob/settings.jsonを作成 -
ユーザー全体：ホームの
~/.bob/settings.jsonを編集 -
コマンドライン引数：起動時に
--sandboxなどを付与
Sandbox の構成
Sandbox は settings.json の tools カテゴリで指定するか、起動時のフラグで有効化します。
設定ファイルで指定する
{
"tools": {
"sandbox": "docker",
"allowed": ["run_shell_command(git)", "run_shell_command(npm test)"],
"exclude": ["write_file"]
}
}
-
sandbox：Sandbox 実行環境（booleanまたは"docker"のような文字列） -
allowed：確認をバイパスして自動許可するツール -
exclude：そもそも使わせないツール
sandbox と allowed/exclude を組み合わせることで、「隔離環境で、許可したコマンドだけを自動実行する」といった安全な構成が作れます。
コンテナ方式は Docker のほか Podman（rootless な代替）も使えます。環境変数 BOB_SHELL_SANDBOX でも指定でき、設定の優先順位は コマンドフラグ > 環境変数 > settings.json です。
# 真偽値で有効化（セッション全体）
export BOB_SHELL_SANDBOX=true
bob "実行前にこのスクリプトを分析して"
# 種類を明示（docker / podman / sandbox-exec）
export BOB_SHELL_SANDBOX=docker
bob --sandbox
コンテナ方式はサンドボックスイメージをローカルでビルドするか、組織のレジストリの公開イメージを使う必要があります。
フラグで有効化する
# セッション単位で Sandbox を有効化
bob --sandbox
# 短縮形
bob -s
構成イメージ
┌─────────────────────────────────────────┐
│ ホスト環境（あなたの PC） │
│ ┌─────────────────────────────────┐ │
│ │ Sandbox（隔離環境） │ │
│ │ ・Docker コンテナ など │ │
│ │ Bob Shell がここでコマンド実行 │ │
│ └─────────────────────────────────┘ │
│ ↑ ホスト本体は保護される │
└─────────────────────────────────────────┘
📌 注意：
create-prコマンドは Sandbox セッションと併用できません。
macOS Seatbelt
Seatbelt は macOS に標準で組み込まれているサンドボックス機構で、コマンドラインからは sandbox-exec を通じて利用します。Docker のようにコンテナランタイムを別途用意する必要がなく、軽量・高速にプロセスを隔離できるのが利点です。macOS でローカルのちょっとしたタスクを安全に回したいときに向いています。
有効化
settings.json の tools.sandbox に sandbox-exec を指定するか、環境変数・フラグで有効化します。
{
"tools": {
"sandbox": "sandbox-exec"
}
}
# 単発で有効化（プロンプト付き実行例）
bob -s "実行前にこのシェルスクリプトのセキュリティ問題を分析して"
Seatbelt プロファイル
Seatbelt では「何を許可するか」をプロファイルで制御します。プロファイルは環境変数 SEATBELT_PROFILE で切り替えます。
# プロファイルを指定して Sandbox で起動
export SEATBELT_PROFILE=permissive-open
bob --sandbox
組み込みプロファイルは次の通りです。ポイントは「ネットワークアクセス」と「書き込み可能な範囲」の組み合わせです。
| プロファイル | ネットワーク | 書き込み範囲 | 想定用途 |
|---|---|---|---|
permissive-open（既定） |
✅ 許可 | プロジェクトのみ | 通常開発。通信ありで適度な保護 |
permissive-closed |
❌ 遮断 | プロジェクトのみ | オフライン作業 |
permissive-proxied |
🔶 プロキシ経由 | プロジェクトのみ | プロキシ必須の企業環境 |
restrictive-open |
✅ 許可 | 厳格に制限 | 高セキュリティ＋通信が必要なコード |
restrictive-closed |
❌ 遮断 | 最大限に制限 | 最高セキュリティ。完全隔離 |
既定の permissive-open はプロジェクトディレクトリ外への書き込みを制限しつつ、それ以外はおおむね許可します。restrictive-* はファイルアクセスをさらに厳格化、*-closed は通信を遮断します。信頼できないコードを完全隔離したいなら restrictive-closed、外部 API を叩く必要があるなら permissive-open や permissive-proxied を選ぶ、という使い分けです。
export SEATBELT_PROFILE=restrictive-open
bob -s "実行前にこのシェルスクリプトのセキュリティ問題を分析して"
コンテナ向けのカスタムフラグ
コンテナ方式（Docker/Podman）では、SANDBOX_FLAGS 環境変数で docker/podman コマンドに任意のフラグを差し込めます。メモリ・CPU 制限やボリュームマウント、SELinux 設定の調整などに使います。
# リソース制限
export SANDBOX_FLAGS="--memory=4g --cpus=2"
bob -s
# Podman の SELinux ラベルを無効化
export SANDBOX_FLAGS="--security-opt label=disable"
bob -s
Linux ではコンテナ内で作成したファイルの所有権を Bob Shell が自動調整します。必要なら SANDBOX_SET_UID_GID=true/false で上書きできます。
Seatbelt と コンテナ方式の比較
Seatbelt は手軽な反面、隔離レベルはコンテナより緩い点に注意が必要です。
| 観点 | macOS Seatbelt | コンテナ（Docker/Podman） |
|---|---|---|
| 隔離の強さ | 🔶 コンテナより緩い | ✅ 完全なプロセス隔離 |
| セットアップ |
sandbox-exec 標準搭載で手軽 |
イメージのローカルビルド等が必要 |
| パフォーマンス | 高速（ネイティブに近い） | 初回ビルド後はオーバーヘッド小 |
| 対応プラットフォーム | macOS のみ | クロスプラットフォーム |
| 向いている用途 | macOS でのローカル作業 | 再現性が要る環境・CI/本番 |
つまり、macOS でサッと安全に試すなら Seatbelt、強い隔離や再現性が必要ならコンテナ が基本方針となります。
Seatbelt の制限事項（公式）
- macOS 専用。Linux/Windows では使えない。
- 隔離はコンテナより弱い。プロファイルによっては一部操作がブロックされる。
- 既定ではプロジェクトディレクトリのみアクセス可。外部を指すシンボリックリンクは正しく動かないことがある。
-
permissive-closed/restrictive-closedは全ネットワークを遮断する。 -
sudoなどシステムレベル権限が必要なコマンド、GUI アプリ、USB/GPU などハードウェア直接アクセスは Sandbox 内では基本的に動作しない。
⚠️ Sandbox は「完全なセキュリティ解」ではありません。リスクを減らすものの、ゼロにはしません。Bob の提案は承認前に必ず確認し、信頼フォルダで対象を絞り、API キーを安全に保つことが引き続き重要です。
導入・使用の手順
Step 1. インストール
公式ダウンロードページから Bob Shell を入手・インストールすると、bob コマンドが使えるようになります。
Step 2. （Docker を使う場合）Docker を準備
docker --version # 動作確認
Step 3. 設定で Sandbox を有効化
~/.bob/settings.json（ユーザー全体）または .bob/settings.json（プロジェクト単位）に記述します。
{
"tools": {
"sandbox": "docker"
}
}
Step 4. Sandbox 付きで起動
# シンプルに有効化
bob --sandbox
# 承認モードと組み合わせる例
bob --sandbox --approval-mode auto_edit
主な承認まわりのフラグ：
| フラグ | 説明 |
|---|---|
--sandbox, -s
|
Sandbox を有効化 |
--yolo |
すべてのツール呼び出しを自動承認 |
--approval-mode |
承認モードを指定（例：auto_edit） |
--allowed-tools |
自動承認するツールを指定 |
yolo のような無承認実行は、必ず
--sandboxと併用するのが安全です。
カスタマイズ方法
1. カスタム Sandbox（独自 Dockerfile）
依存ライブラリを足した独自の隔離環境を作れます。
- プロジェクトに
.bob/sandbox.Dockerfileを作成 - ベースイメージ
bobshell-sandboxを継承 - 必要な依存を追加
FROM bobshell-sandbox
# 独自の依存を追加
RUN apt-get update && apt-get install -y python3-dev
ビルドして使うには BUILD_SANDBOX を付けて起動します。
BUILD_SANDBOX=1 bob -s
2. カスタムモード × Sandbox
~/.bob/custom_modes.yaml（全プロジェクト）または .bob/custom_modes.yaml（プロジェクト単位）で、用途特化のモードを定義できます（YAML 推奨、JSON も可）。groups で許可するツール群（read / edit / command / browser / mcp）を制御できるのがポイントです。
customModes:
- slug: script-dev
name: 📜 Script Developer
roleDefinition: >-
You are a shell scripting expert specializing in bash, zsh,
and POSIX-compliant scripts.
whenToUse: Use for creating, debugging, or improving shell scripts.
groups:
- read
- - edit
- fileRegex: \.(sh|bash|zsh)$
description: Shell script files only
- command
定義したモードを Sandbox と組み合わせて起動します。
# カスタムモードを Sandbox 内で実行
bob --chat-mode=script-dev --sandbox
# Docker Sandbox と組み合わせる
bob --chat-mode=deploy-helper --sandbox
本番環境向けには、command/edit グループを外して読み取り専用にした「Production Operations」のような安全重視モードも定義できます。
3. 信頼フォルダ（Trusted Folders）
Sandbox（隔離）に加え、信頼フォルダで「Bob が動作してよいディレクトリ」を制限できます。フォルダで初回起動すると信頼ダイアログが出て、
- Trust folder：そのフォルダを信頼
- Trust parent folder：親フォルダごと信頼（配下も自動的に信頼）
- Don't trust：信頼しない（制限付きセーフモードで動作）
を選べます。選択は ~/.bob/trustedFolders.json に保存されます。信頼していないフォルダでは、プロジェクト設定・.env・MCP サーバ接続・ツール自動承認などが無効化され、安全側に倒れます。信頼状態は /permissions スラッシュコマンドで後から変更できます。
4. その他のカスタマイズ
settings.json では general（エディタ、Vim モード、チェックポイント）、ui（テーマ、表示）、context（コンテキストファイル名や対象ディレクトリ）、mcpServers（MCP 連携）なども調整できます。テレメトリを止めたい場合は次を追加します。
{
"privacy": {
"usageStatisticsEnabled": false
}
}
注意点
-
無承認実行（
--yolo）は必ず Sandbox 内で。 ホストを直接触らせない。 - Sandbox × 信頼フォルダ × ツール allowlist を併用し、多層で安全性を確保する。
- まず隔離環境で試す → 確認後に反映 の流れを徹底する。
-
create-prは Sandbox と非互換である点に注意。 - 設定変更後は Bob Shell を再起動する。効かない場合は JSON 構文や設定ファイルの場所・優先順位を確認する。
まとめ
IBM Bob Shell の Sandbox は、AI エージェントにターミナル操作を任せる際の「ホスト破壊リスク」を抑えるための機能です。
- 概要：Bob Shell はターミナル上で動く AI エージェント。Sandbox はその操作を隔離環境で実行する。
-
構成：方式は macOS Seatbelt（
"sandbox-exec"+SEATBELT_PROFILE）と コンテナ（"docker"/"podman"）の 2 つ。bob --sandboxで有効化。独自プロファイル/Dockerfile も作成可能。 -
手順：インストール → 設定で Sandbox 指定 →
bob --sandboxで起動。 -
カスタマイズ：カスタム Dockerfile、カスタムモード（
groupsで権限制御）、信頼フォルダ、承認モードの組み合わせ。
「速さ（自動実行）」と「安全（隔離）」を両立したいときに、Sandbox を使用して気軽に試すことが可能になります。
以上、ご参考まで。