> ## Documentation Index
> Fetch the complete documentation index at: https://ccsafetynet.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# CC Safety Net が破壊的コマンドをインターセプトしてブロックする仕組み

> 1 つのツール呼び出しのライフサイクルを説明します。エージェントの要求、連携によるインターセプト、順序付きの保護と解析、許可またはブロックの応答、監査記録、および予想外の判定を調べる方法を示します。

CC Safety Net は、コーディングエージェントと保護対象ツールの間にあります。対応する各ツール操作を実行前に検査します。その後、操作を許可するか、エージェントが対応できるブロック結果を返します。このページでは、1 つのツール呼び出しを最初から最後まで説明します。

各エージェントを CC Safety Net に接続する連携については、[連携アーキテクチャ](/docs/ja/guides/integration-architecture)を参照してください。

## 1 つのツール呼び出しのライフサイクル

<Steps>
  <Step title="エージェントがツール呼び出しを準備する">
    エージェントは、`git reset --hard` などの shell コマンド、またはファイルの書き込み、編集、検索、patch を実行すると決定し、ツールレイヤーに渡します。
  </Step>

  <Step title="連携がツール呼び出しをインターセプトする">
    そのエージェント用の CC Safety Net 連携が、ツールの実行前かつオペレーティングシステムが処理する前に呼び出しを受け取ります。一部のエージェントは、CC Safety Net を短時間の subprocess hook として呼び出します。その他のエージェントは、プロセス内のプラグインまたは拡張機能として読み込みます。どちらの場合も同じ guard が動作します。各エージェントが使用する方式については、[連携アーキテクチャ](/docs/ja/guides/integration-architecture)を参照してください。
  </Step>

  <Step title="CC Safety Net が操作を確認する">
    CC Safety Net は、深さ、サイズ、フィールド数の上限を適用してツール入力を読み取ります。入力を 1 回解析し、[確認する順序](#確認する順序)に示す固定手順を実行します。順序はエージェントによって変わりません。
  </Step>

  <Step title="許可またはブロックの結果を返す">
    安全な呼び出しは許可され、通常どおり実行されます。ブロックされた呼び出しは実行されません。エージェントは、理由、問題のコマンド、次に実行すべきことを示すブロックメッセージを受け取ります。[ブロック結果の形式](#ブロック結果の形式)を参照してください。
  </Step>

  <Step title="判定を監査できる">
    拒否はローカル監査ログに追加します。対象となる許可済みコマンド判定も、設定済みの監査 scope に含まれる場合は記録します。[監査記録](#監査記録)を参照してください。
  </Step>
</Steps>

## 確認する順序

すべてのツール呼び出しは、次の順序で同じ段階を通ります。

1. **上限付き入力抽出。** 深さ、node 数、key 数、サイズの走査上限を適用して、ツール入力からコマンドを読み取ります。上限を超える呼び出しは、無制限の走査を防ぐためにブロックします。
2. **1 回の解析。** コマンドを 1 回解析し、後続のすべての段階が再利用する構造的事実を作成します。parser の作業予算を使い切ると、すべての安全レベルで呼び出しをブロックします。
3. **ポリシーファイル保護。** CC Safety Net 自身の `policy.json`、そのディレクトリ、または祖先を変更または削除するすべての操作を停止します。
4. **Git メタデータ保護。** リポジトリの `.git` メタデータまたは hooks ディレクトリを削除、移動、上書き、patch するすべての操作を停止します。作業ディレクトリ内からの操作も対象です。
5. **設定の読み込み。** ポリシー、rulebook、安全レベルを解決します。
6. **機密パス保護。** コマンド、パス、検索、patch を、組み込みの機密場所（`.env`、`~/.ssh`、cloud およびコーディング CLI の認証情報ファイル）と設定済み deny path に照らして確認します。
7. **破壊的コマンド解析。** コマンドを segment に分割し、wrapper と interpreter を展開し、各 segment を対応する analyzer で分類します。対象は `git`、`rm`、`Remove-Item`、`find`、`xargs`、`parallel`、device コマンド、およびカスタムルールです。

手順 3 と 4 は、意図的に手順 5 の**前**に実行します。この 2 つの保護は常に有効であり、設定を読み取る前に適用されるため、設定で弱めることはできません。手順 6 はポリシーで制御できます。無効にするか、独自の deny path を追加できます。

段階名と evidence を含む maintainer 向けの同じ手順については、[アーキテクチャ](/docs/ja/guides/architecture#順序付き-guard-stage)を参照してください。分類器の内部については、[解析エンジン](/docs/ja/guides/analysis-engine)を参照してください。

## 文字列ではなく意図を解析する理由

CC Safety Net は、コマンドの*見た目*ではなく、コマンドの*動作*を解析します。実行ファイル、subcommand、flag、引数を解析します。その実行ファイルの analyzer が option grammar を適用します。

| コマンド                      | 動作                | 結果       |
| ------------------------- | ----------------- | -------- |
| `git checkout -b feature` | 新しい branch を作成する  | **許可**   |
| `git checkout -- file`    | ファイルの未コミット変更を破棄する | **ブロック** |

どちらも `git checkout` で始まります。単純な prefix ルールでは、Git の option logic を複製しない限り、この 2 つの結果を区別できません。構造解析は、順序を変えた flag（`rm -r -f /`）、shell wrapper（`sh -c "rm -rf /"`）、interpreter の 1 行コード（`python -c 'import os; os.system("rm -rf /")'`）も処理します。CC Safety Net は、最大 10 階層までネストしたコマンドを展開して再解析します。

このページはすべてのルールを示しません。停止するものの完全な動作 matrix については、[ブロックされるコマンド](/docs/ja/reference/blocked-commands)を参照してください。意図的にブロックしないものについては、[許可されるコマンド](/docs/ja/reference/allowed-commands)を参照してください。

## ブロック結果の形式

エージェントは、ツール結果としてブロックメッセージを受け取ります。

```text theme={"dark"}
BLOCKED by CC Safety Net

Reason: git checkout -- discards uncommitted changes permanently. Use 'git stash' first.

Command: git checkout -- src/main.py

If this operation is truly needed, ask the user for explicit permission and have them run the command manually.
```

該当する場合、メッセージには一致した `Rule:` id、`Tool:` 名、ブロックを発生させた特定の `Segment:`、およびフォールバック設定が有効な場合の `Config warning:` も含まれます。コマンドと segment のテキストは抜粋され、プロセス外に出る前にメッセージ全体から機密情報をマスクします。

ブロックによってエージェントセッションが終了することはありません。メッセージは通常のツール結果として届き、別の形式を再試行せずにタスクへ戻るようエージェントに指示します。ルールの intent によって最後の指示が決まります。

| Intent             | エージェントへの指示                              |
| ------------------ | --------------------------------------- |
| `hard_stop`        | どの方法でも再試行または回避せず、ブロックを報告して残りのタスクを続ける    |
| `use_alternative`  | ブロックされた形式を再試行せず、理由に示された安全な代替手段を使って続ける   |
| `scope_down`       | より狭い明示的な対象で再試行し、広い操作が本当に必要な場合はユーザーに確認する |
| `manual_only`      | ユーザーに明示的な許可を求め、ユーザー自身に手動で実行してもらう        |
| `stop_and_explain` | 別の形式を総当たりせず、コマンドを単純化または再構成するか、ブロックを報告する |

このメッセージ形式を使う理由と、指示は助言である一方で enforcement は guard に残す理由については、[設計原則](/docs/ja/guides/design-principles#エージェントが作業を続けられる-denial)を参照してください。

## 監査記録

CC Safety Net は、拒否を常にローカル監査ログに記録します。許可されたコマンド判定は既定で記録します。次のコマンドでログを読み取ります。

```bash theme={"dark"}
npx cc-safety-net logs
```

ログの場所、各記録の内容、保持期間、および書き込み前にマスクする情報については、[監査ログのリファレンス](/docs/ja/reference/audit-log)を参照してください。

## 判定が予想と異なる場合

<Steps>
  <Step title="理由を確認する">
    `npx cc-safety-net explain "<command>"` はコマンドの解析を再実行し、一致したルールと理由を示します。構造化トレースには `--json` を追加します。
  </Step>

  <Step title="保護が実際に有効か確認する">
    `npx cc-safety-net status` は `ready` または `degraded` を 1 画面に表示し、無効な Claude Code プラグインを含む、適用されていない項目を `Not active` に示します。`degraded` は設定ソースが拒否され、フォールバックが適用されていることを示します。有効なもの、無効なもの、修復方法については、[設定の復旧](/docs/ja/configuration/recovery)を参照してください。`npx cc-safety-net doctor` は完全なレポートを表示します。
  </Step>

  <Step title="調整または報告する">
    ブロックが正しいがワークフローには厳しすぎる場合は、[安全モード](/docs/ja/configuration/modes)を変更するか、ルールごとの override を追加します。安全なコマンドがブロックされた場合、または破壊的なコマンドがブロックされなかった場合は、[トラブルシューティング](/docs/ja/guides/troubleshooting)と[セキュリティポリシー](/docs/ja/security)で報告先を確認してください。
  </Step>
</Steps>

## 対象外のもの

CC Safety Net はエージェントが実行しようとするツール呼び出しを解析するため、任意の binary、未設定または不透明なコマンド proxy、network activity に隠された動作は検出できません。これは静的な実行前 policy gate です。OS sandbox でも privilege boundary でもありません。インストール済み連携を経由しないコマンドはまったく保護しません。完全な一覧と推奨される緩和策については、[既知の制限](/docs/ja/guides/known-limitations)を参照してください。

次に、各エージェントが CC Safety Net に接続する方法について、[連携アーキテクチャ](/docs/ja/guides/integration-architecture)を参照してください。