ガードレールを設定

このガイドでは、ガードレールの設定方法を説明します。ガードレールとは、エージェントのアクションを実行するか、先に承認を求めるか、拒否するかを決めるルールです。

ガードレールは、変更を伴うすべてのツールが宣言する 13 のエフェクトクラスを対象とします。これらはプロンプト内の指示によってではなく、ツールが呼び出される時点でサーバー側で適用されます。

アクションクラスに対する決定を設定する

設定 → ワークスペース → エージェントの権限を開きます
セグメントコントロールでスコープを選びます: ワークスペース、エージェント（続いてエージェントを選択）、またはスペース（続いてスペースを選択）
アクションクラスの行で、許可、先に確認、拒否のいずれかを選びます
設定したルールを解除するには、その行の末尾に表示されるリセットボタン（継承に戻す）を押します — 決定はより広いスコープにフォールバックします

各行は、有効な決定をステータスタグとして、その由来をバッジとして表示します: このスコープ、継承、組み込みのデフォルトのいずれかです。マトリクスはエージェント（chat）モードで解決されるため、モードプリセットがここに現れることはありません — そのレイヤーを確認するには、読み取り専用モードを選択した状態で what-if プローブを使用します。

ルールの書き込みには admin ロールが必要です。マトリクスの閲覧には不要です。

チェックポイント: ワークスペーススコープでリモートへプッシュを拒否に設定し、以下の what-if プローブを git push origin main に対して実行します。結果は deny、ソースは workspace と表示されます。

決定がどのように解決されるかを理解する

解決の順序はまず具体性、次に制限の強さです:

スペースのルール、次にエージェント、次にワークスペースです。一致するルールを持つ最初のスコープが決定し、そこで解決は停止します
一致するルールがなければ、モードプリセットが適用されます — 読み取り専用モード（plan、review、orchestrate）は 13 クラスのうち 11 を拒否します
モードが何も指定しない場合、組み込みのデフォルトが適用されます

1 つのスコープ内では、コマンドルールは最長一致プレフィックスで解決され、同じ具体性の競合は最も制限の強いもので解決されます — 拒否は先に確認に、先に確認は許可に優先します。複数のクラスを宣言するアクションは、それぞれを独立に解決し、その後で最も制限の強いものに統合します。

先に確認の決定は、prompt に解決されたすべてのクラスを対象とする 1 つの承認プロンプトを表示します。承認者が接続されていない場合は拒否されます — シェルコマンドとハーネスのツール呼び出しの両方でそうです。これは意図的なものです。ゲートされない実行は、拒否される実行よりも悪いからです。

アクションクラスと組み込みのデフォルト

アクションクラス	組み込みのデフォルト
ファイルを削除	先に確認
ワークツリー外への書き込み	許可
コミットを作成	許可
リモートへプッシュ	先に確認
プルリクエストを作成	先に確認
レビューの公開またはマージ	先に確認
外部トラッカーへの書き込み	先に確認
ネットワークにアクセス	許可
シークレットを読み取る	許可
パッケージをインストール	許可
プロセスを実行	許可
ワークスペース構造の変更	許可
エンクロージャー（リグ）を操作	許可

分類は閉じられています。クラスを宣言せずに出荷された新しいツールは CI のラチェットテストに失敗するため、エフェクト集合が黙って空のまま何かが入り込むことはありません。

what-if プローブでルールをテストする

ルールを変更する前に、現在のポリシーがそれをどう解決するかを確認します。

同じページで**もしも？**までスクロールします
アクション（13 クラスのいずれか）を選びます
任意でコマンド（例: git push origin main）、エージェント、スペース、モードを入力します
結果を読み取ります: 決定、理由、そしてソース:

プローブは、適用パスが使うのと同じリゾルバーを、あなたの現在のルールに対して実行するため、答えは正確です。結果に驚いたら、上のマトリクスでルールを変更し、もう一度プローブします。

スペースの自律度ダイヤルを設定する

ダイヤルはスペースごと・エージェントごとに設定し、ルールを置き換えるのではなく、ルールと組み合わせて機能します。

スペースを開きます
スペースヘッダーから参加者を管理を開きます
エージェントの行の自律度で、レベルを選びます:

レベル	効果
デフォルト	スペース設定なし — 承認後に実行として動作します
提案のみ	ゲートされたすべてのツールが即座に拒否され、代わりにそのアクションを提案するようエージェントに伝えるメッセージが表示されます
承認後に実行	危険なアクションはフェイルクローズの承認ゲートに到達します
自由に実行	ハード拒否に解決されなかったものはすべて事前承認されます

このダイヤルが届くのは内蔵ハーネスだけです。Claude Code アダプターは、このゲートの外で独自のツールを実行します。

ガードレールが届かない範囲を知る

同じページの下部にあるルールの適用箇所の表は、これをアプリ内で表したものです。エフェクトクラスごとに、各ランナーがそれをポリシーゲートで捕捉するのか、サンドボックスに委ねるのか、まったく横取りできないのかを示します。

Claude Code アダプターは、自身のツール呼び出しの一部しかゲートされません。Claude Code は --dangerously-skip-permissions 付きで起動されるため、その read、write、edit 呼び出しはガードを通過しません。bash コマンドはコマンドラインを分類するフックを通じてガードに届き、プッシュは他のエージェントと同じくプッシュゲートウェイを通ります。それが呼び戻す MCP ツールサーフェスと、Control Center が起動のためにスポーンするシェルコマンドもゲートされます。
モード自身の出力動詞（submit_plan、propose_orchestration）は固定されており、決して拒否できません — そうでなければ、モードはその唯一の成果物を構造的に生み出せなくなります。
サンドボックスがこれらのルールを支えるかどうかはホスト次第です。 cc_server がバックエンドを見つけた場合、Claude Code CLI とハーネスの bash ツールをラップするため、あなたが書いていないルールにも OS の土台が下に存在します。Windows にはそれがなく、bwrap と socat のない Linux や WSL2 にもありません — そこでは、ガードレールとモードのツールサーフェスが適用のすべてであり、第二の防衛線ではありません。どちらのケースに当てはまるかはサンドボックスポリシーを設定で確認してください。