Skip to main content
CC Safety Net は、コーディングエージェントと保護対象のツールの間に入り、対応する操作を実行前に検査します。操作を許可するか、次に取れる行動を示してブロックします。このページでは、1 つのツール呼び出しを最初から最後まで追います。 各エージェントを CC Safety Net に接続する連携については、連携アーキテクチャを参照してください。

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

1

エージェントがツール呼び出しを準備する

エージェントが、git reset --hard のようなシェルコマンドや、ファイルの書き込み・編集・検索・patch を実行しようと判断し、それを自身のツール層に渡します。
2

連携がツール呼び出しをインターセプトする

エージェント用の連携が、ツールを実行する前、つまり OS に届く前に呼び出しを受け取ります。CC Safety Net を短命の subprocess hook として呼び出すエージェントもあれば、プロセス内のプラグインや拡張機能として読み込むエージェントもあります。どちらも同じガードを使います。各エージェントの方式は、連携アーキテクチャを参照してください。
3

CC Safety Net が操作を検査する

CC Safety Net は、深さ・サイズ・フィールド数に上限を設けたうえでツール入力を読み取ります。入力を 1 回だけ解析し、検査の順序に示す決まった手順を実行します。この順序はエージェントによって変わりません。
4

許可またはブロックが返る

安全な呼び出しは許可され、通常どおり実行されます。ブロックされた呼び出しが実行されることはありません。エージェントには、理由、問題になったコマンド、次に取るべき行動を示すブロックメッセージが返ります。ブロック結果の形式を参照してください。
5

判定を後から監査できる

拒否は必ずローカルの監査ログに追記されます。許可されたコマンドの判定も、設定した記録範囲に含まれていれば記録されます。監査記録を参照してください。

​
検査の順序

どのツール呼び出しも、同じ段階を次の順に通ります。
  1. 上限付きの入力抽出。 深さ、ノード数、キー数、サイズに走査上限を設けたうえで、ツール入力からコマンドを読み取ります。上限を超えた場合は、際限のない走査を避けるためにその呼び出しをブロックします。
  2. 1 回だけの解析。 コマンドを 1 回だけ解析し、後続のすべての段階が再利用する構造情報を作ります。パーサーの処理上限を使い切った場合は、どの安全レベルでもその呼び出しをブロックします。
  3. ポリシーファイルの保護。 CC Safety Net 自身の policy.json、そのディレクトリ、上位ディレクトリを変更・削除しようとする操作は、この時点で止めます。
  4. Git メタデータの保護。 リポジトリの .git メタデータや hooks ディレクトリを削除・移動・上書き・patch しようとする操作は、作業ディレクトリ内からのものも含めてこの時点で止めます。
  5. 設定の読み込み。 ポリシー、rulebook、安全レベルを解決します。
  6. 機密パスの保護。 コマンド、パス、検索、patch を、組み込みの機密の場所（.env、~/.ssh、クラウドやコーディング CLI の資格情報ファイル）と、設定済みの deny path に照らして検査します。
  7. 破壊的コマンドの解析。 コマンドをセグメントに分割し、ラッパーとインタープリターを展開したうえで、各セグメントをそれを理解するアナライザーで分類します。対象は git、rm、Remove-Item、find、xargs、parallel、デバイス系コマンド、そしてカスタムルールです。
手順 3 と 4 は、意図的に手順 5 の前に実行します。この 2 つの保護は常に有効で、設定を読み込む前に効くため、設定では弱められません。手順 6 はポリシーで制御でき、無効にすることも、独自の deny path で拡張することもできます。 同じ手順をメンテナー視点で、ステージ名や判断材料まで含めて見たい場合はアーキテクチャを、分類処理の内部は解析エンジンを参照してください。

​
文字列一致ではなく意図で判定する理由

CC Safety Net が解析するのは、コマンドの見た目ではなく実際の動作です。実行ファイル、サブコマンド、フラグ、引数を解析し、その実行ファイル担当のアナライザーがオプションの文法を適用します。 どちらも git checkout で始まります。単純な前方一致のルールでは、Git のオプション解釈をそっくり作り直さないかぎり、この 2 つを区別できません。構造解析は、順序を入れ替えたフラグ（rm -r -f /）、シェルによるラップ（sh -c "rm -rf /"）、インタープリターの 1 行コード（python -c 'import os; os.system("rm -rf /")'）にも対応します。CC Safety Net は、最大 10 階層までネストしたコマンドを展開して解析し直します。 このページではすべてのルールを列挙しません。何がブロックされるかの一覧はブロックされるコマンドを、意図的にブロックしないものは許可されるコマンドを参照してください。

​
ブロック結果の形式

エージェントは、ツール結果としてブロックメッセージを受け取ります。
該当する場合は、次の情報もメッセージに含まれます。
  • 一致したルールの Rule: ID
  • ツール名を示す Tool:
  • ブロックのきっかけになった Segment:
  • フォールバック設定が有効なときの Config warning:
コマンドとセグメントのテキストは抜粋され、プロセスの外に出る前にメッセージ全体から資格情報がマスクされます。 ブロックによってエージェントのセッションが終了することはありません。メッセージは通常のツール結果として届き、別の書き方を試すのではなく本来のタスクに戻るようエージェントを促します。最後に添える指示は、ルールの intent によって決まります。 このメッセージ形式を使う理由と、強制をガード側に担わせている理由は、設計原則を参照してください。

​
監査記録

CC Safety Net は、拒否を常にローカルの監査ログに記録します。許可されたコマンドの判定も、既定では記録します。ログは次のコマンドで読み取れます。
ログの場所、各レコードの内容、保持期間、書き込み前にマスクされる情報については、監査ログのリファレンスを参照してください。

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

1

理由を確認する

npx cc-safety-net explain "<command>" を実行すると、そのコマンドの解析を再現し、どのルールがなぜ一致したかを表示します。構造化されたトレースが必要な場合は --json を付けます。
2

保護が実際に効いているか確認する

npx cc-safety-net status は ready または degraded を 1 画面に表示し、無効になっている Claude Code プラグインを含め、適用されていない項目を Not active の下に並べます。degraded は、設定元のいずれかが拒否され、フォールバックが適用されていることを示します。何が有効で何が無効か、どう直すかは設定の復旧を参照してください。詳細なレポートが必要なら npx cc-safety-net doctor を実行します。
3

設定を調整する、または報告する

ブロック自体は正しいものの自分のワークフローには厳しすぎる場合は、安全モードを変更するか、ルール単位の override を追加します。安全なコマンドがブロックされた場合や、破壊的なコマンドがブロックされなかった場合の報告先は、トラブルシューティングとセキュリティポリシーで確認してください。

​
対象外のもの

CC Safety Net が解析できるのは、エージェントが実行しようとするツール呼び出しだけです。そのため、任意のバイナリの内部、未設定または不透明なコマンドのプロキシ、ネットワーク通信に隠された動作は検出できません。これは静的な実行前ポリシーゲートであり、OS のサンドボックスでも権限境界でもありません。インストール済みの連携を経由しないコマンドは、まったく保護できません。全一覧と推奨される緩和策は、既知の制限を参照してください。 各エージェントの接続方式は、連携アーキテクチャを参照してください。
最終更新日 2026年9月3日