Claude Code を個人で使っているときは、自分の設定を自分で気をつければ済みます。けれどもチームや組織で使い始めると、前提が変わります。
私が最初に困ったのは、開発者ごとに設定がバラバラで、誰がどこまで安全の対策をしているのか分からない、という状態でした。ある人は危険な操作を止める設定を入れているけれど、別の人は何も入れていない。新しく入った人は、設定をしないまま本番のリポジトリで AI を動かしてしまう。
チームで使うときの本当のリスクは、ここにあります。一番慎重でない一人の設定が、組織全体のリスクになるからです。19人がどれだけ気をつけていても、残りの1人の手元で AI が再帰的にファイルを消したり、.env を git に取り込んだり、本番のデータベースを壊したりすれば、被害は組織全体に及びます。
そこで考え方を変えました。「各自が気をつける」のではなく、全員に同じ安全の土台を配る。これがうまくいって、安心してチームに Claude Code を任せられるようになりました。この記事は、そのときに効いた「組織で配るガードレールの型」を、コピーして使える形でまとめたものです。
まず、安全の設定をリポジトリに入れて git で共有します。.claude/settings.json をリポジトリに置くと、そのリポジトリで作業する全員に同じ設定が効きます。新しく入った人も、リポジトリを clone した時点で同じ土台に乗ります。
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [{ "type": "command", "command": "bash .claude/hooks/rm-safety-net.sh" }]
}
]
}
}
ポイントは、各自の手元の設定（ユーザー全体の設定）ではなく、リポジトリの中に置いて配ることです。手作業で「この設定を入れておいてね」と配ると、必ず誰かが忘れます。リポジトリに入れておけば、配り忘れが起きません。
次に、人間の注意力に頼らず、危険な操作を実行の手前で止める hook を入れます。うまくいっている組織に共通しているのは、「気をつける」をルールではなく仕組みにしている点です。
たとえば、再帰的な削除を止める hook はこういう形になります（終了コード 2 で操作を止めます）。
INPUT=$(cat)
CMD=$(printf '%s' "$INPUT" | jq -r '.tool_input.command // empty')
if printf '%s' "$CMD" | grep -qE 'rm[[:space:]]+(-[a-zA-Z]*r[a-zA-Z]*[[:space:]]+)+(/|~|\$HOME)'; then
echo "BLOCKED: 危険な再帰削除です。対象を確認してください。" >&2
exit 2
fi
exit 0
同じ考え方で、.env の git への取り込み、本番のデータベースへの破壊的な操作、force での push なども止められます。一つずつ手で書いてもよいのですが、こうした安全 hook を1コマンドでまとめて入れられる無料のツール（後述の cc-safe-setup）があるので、私はそれを土台にして、自社の事情に合わせて足しています。
大事なのは、「やってはいけない」をドキュメントに書くのではなく、実行の手前で止まる形にすることです。ドキュメントは読まれないこともありますが、hook は必ず効きます。
手元の設定は、手元でしか効きません。出荷の手前でもう一段、CI に安全のゲートを置くと安心です。Pull Request ごとに、その変更で安全の設定が外れていないかを自動でチェックします。
name: safety
on: [pull_request]
jobs:
audit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npx cc-safe-setup --audit --json
これで、誰かが安全の設定をうっかり外しても、マージの手前で気づけます。組織全体で「安全の土台が外れていない」ことを、機械的に担保できます。
チームは人が入れ替わります。新しく入った人が、安全の設定を知らないまま作業を始めても大丈夫なように、最初のセッションの開始時に土台が効くようにしておきます。.claude/settings.json をリポジトリに入れておくこと（①）が、そのまま新メンバーへの自動の配布になります。加えて、セッションの開始時に、この組織の安全の前提を一言出す hook を入れておくと、迷いがなくなります。
組織で導入を進めるとき、上長や情シスに「なぜここまでやるのか」を説明する場面があります。そのとき、抽象的な不安ではなく、実際に報告された事例で話すと伝わります。
公開されている事例には、たとえば次のようなものがあります（GitHub の起票の番号で辿れます）。
- AI が無断で送金の操作を実行して金銭の損失が出た（#46828）
- エージェントが本番のデータベースに破壊的なコマンドを実行して消えた（#27063）
- CLAUDE.md に書いた指示を素通りして、API キーが git に取り込まれた（#2142）
これらは、気をつけていれば防げたのではなく、人間の注意力に頼っていたから防げなかった事例です。だからこそ、機械的に止める土台を全員に配る。先人の学びを自分の組織で繰り返さないための投資、という説明が一番通ります。
組織で導入の研修を行う場合、従業員の IT・AI のスキルの研修には、国の人材開発支援助成金が使える場合があります（厚生労働省の公式の案内）。対象や助成の率や申請の要件は制度と年度で変わるので、必ず公式の案内と、自社の所在地の労働局で確認してください。
チームで Claude Code をうまく回すコツは、「各自が気をつける」を「全員に同じ安全の土台を配る」に変えることでした。
- 安全の設定はリポジトリに入れて git で配る
- 危険な操作は実行の手前で機械的に止める
- CI に安全のゲートを置く
- 新しく入った人も最初から安全になる
- 「なぜやるか」は実際の事例で説明する
- 研修費は助成金が使えることがある
ここまでの土台を、コピーして使える形でチェックリストにまとめました。技術リードがそのまま社内で使えます。
- 無料のチェックリスト: Claude Code をチームに安全に導入する実務チェックリスト
- 安全 hook を1コマンドで入れる（無料・MIT）: cc-safe-setup
チェックリストと hook を配った先で、組織の安全基盤をゼロから組む時間を肩代わりする一式として、チーム安全導入パック（¥3,000・買い切り・社内配布可） を用意しています。無料の cc-safe-setup（MIT）で足りる個人には不要で、これは組織で配って強制し、CI で実行し、監査まで回すための運用一式です。中身は、なぜお願いでは止まらないかを扱う中核の文書（PDF）、そのまま自社のリポジトリに置けるチームの安全ポリシーの雛形と CI の安全ゲート（弱い設定を pull request で捕まえ、安全スコアが閾値を下回ると build を落とす）、そして番号で辿れる実在の事故の実例集（取り返しの付かない操作・子エージェントの境界・利用枠の漏れ・停止が効かない の4系統）です。無料の試し読みもあります。 -
チーム安全導入パック（¥3,000・無料試し読みあり）
全員に同じ土台が配られていると、安心してチームに任せられます。
このチームへ安全に配るための設定の土台になる、個人が踏みやすい事故とその予防を症状別にまとめたのが 事故防止本（¥800・第3章まで無料） です。無料の cc-safe-setup の hook を試して、もう一段 予防を深めたい方への手引きです。
同じ事故防止本は Kindle 版（Amazon・¥800）でも読めます。Kindle Unlimited なら追加料金なしで全文読めるので、まず無料で中身を確かめたい方はそちらが早いです。
ほかにも、800時間の運用データから、トークン消費の削減・複数ベンダー(Claude / Codex / Gemini / Copilot)の並行運用・サブエージェントの沈黙の失敗対策など、テーマ別の手引きを公開しています。気になる人は著者の本の一覧から、価格と評価を見て選べます。