> ## 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 をセットアップします。全メンバーへの hook のインストールを徹底し、プロジェクト既存のセットアップ手順にインストールを組み込み、必要ならプロジェクトポリシーと取り込み済みの rulebook をコミットしてリポジトリの保護を統一します。

CC Safety Net は 2 つの層でチームを保護します。第 1 の層には、リポジトリ側の設定は一切要りません。メンバーが hook をインストールすれば、作業するすべてのリポジトリがそのメンバーのユーザーポリシーで保護されます。ユーザーポリシーは既定で standard preset を使います。第 2 の層は任意です。チームで preset を統一したいときや、カスタムルール・保護対象パスを追加したいときは、プロジェクト設定を `.cc-safety-net/` 配下にコミットします。どのクローンも自動でそれを読み取り、メンバー側の操作は不要です。

つまり最小のチームセットアップは、全メンバーに CC Safety Net をインストールしてもらうことだけです。

## 全メンバーへのインストールを徹底する

各メンバーは**マシンごと・エージェント CLI ごとに 1 回** hook をインストールします。リポジトリごとに繰り返すことはありません：

```bash theme={"dark"}
npx -y cc-safety-net@latest install
```

対話式セレクターがインストール済みのエージェント CLI を検出します。`--claude-code`、`--codex`、`--cursor` などのターゲットフラグを付ければ 1 つを非対話でインストールできます。`npx -y cc-safety-net install --help` で全フラグを一覧できます。

### インストールの自動化

プロジェクトが既に持っているセットアップ手順に、インストールを組み込んでください。どの手順になるかは言語とツーリング次第です。npm プロジェクトの `postinstall` スクリプト、`Makefile` や `justfile` のセットアップターゲット、dev container の `postCreateCommand`、`mise` のタスクなどが該当します。セットアップ手順のないプロジェクトは、ワンライナーをオンボーディング文書に載せてください。

たとえば npm プロジェクトでは：

```json theme={"dark"}
{
  "scripts": {
    "postinstall": "node -e \"process.env.CI || require('child_process').execSync('npx -y cc-safety-net install --claude-code', {stdio: 'inherit'})\""
  }
}
```

どの仕組みを選んでも、次の 2 つの注意点は共通です：

* セットアップ手順は CI やコンテナ内でも実行されがちですが、そこでエージェントの hook をインストールするのは無駄です。上の `process.env.CI` ガードが、そうした環境でのインストールをスキップします。
* インストールはマシンごと・エージェント CLI ごとなので、チームが実際に使うターゲットフラグを選んでください。複数 CLI が混在するチームなら、対話式のワンライナーを文書化するほうが向いています。

## リポジトリの保護を統一する（任意）

standard preset のもとでは、メンバー自身のポリシーがすでに破壊的コマンドの実行とシークレットへのアクセスをブロックしています。`.cc-safety-net/` 配下に設定をコミットするのは、チームがそれ以上を求めるときだけです。特定の preset、カスタムのブロックルール、追加の保護対象パスが該当します。コミットできる設定は次の 2 つです：

* **`.cc-safety-net/policy.json`**：各メンバーのユーザーポリシーの上に重なるスパースなプロジェクトポリシーで、安全 preset、組み込み保護の切り替え、ルール単位の上書き、追加の保護対象パスを設定します。マージの仕様は[プロジェクトポリシー](/docs/ja/configuration/policy#project-policy)を参照してください。
* **`.cc-safety-net/rule.json` と `.cc-safety-net/rules/`**：プロジェクトのカスタムルールです。取り込み済みの rulebook ファイルは通常のコミット済みファイルなので、チームメイトは何も実行しなくても受け取れます。形式は[カスタムルール](/docs/ja/configuration/custom-rules)を参照してください。

<Steps>
  <Step title="プロジェクトポリシーをコミットする">
    チームで共有したいポリシーのフィールドを提案ファイルに書き、検証してから適用します：

    ```bash theme={"dark"}
    npx -y cc-safety-net policy check proposal.json
    npx -y cc-safety-net policy apply proposal.json
    ```

    `policy check` はマージ後の実効ポリシーとの差分を表示します。`policy apply` は、その差分をターミナルで確認した後に `.cc-safety-net/policy.json` を書き込みます。`npx -y cc-safety-net gui` のポリシータブでもプロジェクトポリシーの下書きを作れます。ファイルはスパースに保ち、チームで統一したいものだけを設定してください。それ以外のフィールドは各メンバーのユーザーポリシーを継承し続けます。
  </Step>

  <Step title="プロジェクトルールを追加する">
    [公式 rulebook](/docs/ja/configuration/rulebooks) をプロジェクトスコープに導入し、プロジェクト固有のルールがあれば作成します：

    ```bash theme={"dark"}
    npx -y cc-safety-net rule add cc-safety-net/rulebooks --only terraform aws
    ```

    `--global` を付けなければ、取り込まれた rulebook ファイルはリポジトリの `.cc-safety-net/rules/` 配下に置かれます。
  </Step>

  <Step title="コミットして検証する">
    `.cc-safety-net/` ディレクトリをコミットします。プッシュ前に、このチェックアウトで期待どおりの保護が効いていることを確認してください：

    ```bash theme={"dark"}
    npx -y cc-safety-net status
    npx -y cc-safety-net rule verify
    npx -y cc-safety-net explain "terraform destroy"
    ```
  </Step>
</Steps>

## メンバーから見えるもの

プロジェクトポリシーは書かれたとおりに適用され、緩和は隠れずに可視化されます。プロジェクトファイルがメンバーのユーザーポリシーより緩めたフィールドには、それぞれ 1 行の報告が付き、`status`、`doctor`、ステータスライン、`explain`、GUI に表示されます。たとえば `project policy lowers level: strict -> standard` や `project policy disables rule <id>` です。完全な一覧は[プロジェクトポリシー](/docs/ja/configuration/policy#project-policy)を参照してください。

メンバー側に保たれる境界：

* \*\*ユーザーポリシーはメンバーのものです。\*\*プロジェクトファイルはその上に重なるだけです。未設定のフィールドは継承され、メンバーはプロジェクトの基準より厳しいユーザーポリシーを使えます。
* \*\*監査はユーザースコープのままです。\*\*プロジェクトポリシーの `audit` セクションは無視され、その旨が報告されます。メンバーがローカルで何を記録するかをプロジェクトは変えられません。
* \*\*プロジェクトルールはユーザールールに干渉できません。\*\*ユーザースコープのルールを指すプロジェクトの上書きは、警告とともに無視されます。

## ポリシー変更は人間の手で

`policy apply` は確認できるターミナルがないと実行を拒否し、エージェントによる呼び出しは、バイナリの直接実行でも、`npx`/`bunx`/`pnpx` 経由でも、ランタイムエントリポイントの実行でも、例外なくブロックされます。想定フローは上記のとおりです。エージェントは提案ファイルを起草して `policy check` で検証できますが、差分を読んで適用するのは人間です。ポリシーファイル自体の改変ガードと合わせて、コミットされるポリシー変更は必ず人間を経由します。通常は、`.cc-safety-net/` を変更するレビュー済みのプルリクエストという形を取ります。

<Tip>
  コードレビューでは `.cc-safety-net/` を CI 設定と同じように扱ってください。チームメイト全員のエージェントに許される操作を変える小さなディレクトリなので、レビュアーは全行を読むべきです。リポジトリが `CODEOWNERS` を使っているなら、オーナーを割り当てましょう。
</Tip>

## 検証を続ける

`rule verify` はコミット済みのルール設定と各 rulebook ディレクトリをオフラインで検証するので、そのまま CI に組み込めます：

```yaml theme={"dark"}
- run: npx -y cc-safety-net@latest rule verify
```

これにより、手編集で検証を通らなくなった rulebook や、ルールが満たさなくなったフィクスチャを、壊れた状態がチームメイトのクローンに届く前に検出できます。手元の状態をいつでも確認したいメンバーは、実効ポリシーなら `npx -y cc-safety-net status` を、インストール全体のチェックなら `npx -y cc-safety-net doctor` を実行してください。