Article

チームでClaude Codeを導入するときに最初に決めるルール

Claude Codeをチームで使い始めるときに最初に合意しておくべき7つのルール（権限・レビュー・CLAUDE.md・禁止事項・ログ・責任分界・更新ルール）を、公式の管理ポリシー機能とあわせて整理します。

This article is not published in this language yet, so the Japanese version is shown instead.

Claude Codeを個人で使うときは「自分が読めばいい」で済みますが、チーム導入では事故の責任分界が問題になります。「AIが書いたコードで本番が落ちた」「APIキーが.envからGitに混ざった」「依存が勝手に増えた」といったトラブルは、ツールではなくルールの欠落で起きます。この記事では、チーム導入の最初に合意しておくと後で揉めない7つのルールを、Anthropic公式が用意している管理ポリシー機能とあわせて整理します。

結論：最初に決める7つのルール

権限ルール：誰がどのツールを承認するか
レビュー必須化ルール：AI生成コードを人間が読む条件
CLAUDE.md集約ルール：プロジェクトルールの一元化
禁止事項ルール：絶対にやらせないこと
ログ・監査ルール：誰がいつ何をしたか
責任分界ルール：事故時の責任者
更新ルール：上記のルールを誰がどう変えるか

これらをCLAUDE.mdと.claude/settings.json、必要ならClaude for Enterpriseのmanaged-settings.jsonに落とし込みます。

1. 権限ルール：deny → ask → allowの順で評価される前提を共有

Claude Codeの権限は.claude/settings.jsonで次のように記述します。

{
  "permissions": {
    "deny": [
      "Bash(curl *)",
      "Bash(rm -rf *)",
      "Read(./.env*)",
      "Read(~/.aws/**)",
      "Read(~/.ssh/**)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(npm publish *)"
    ],
    "allow": [
      "Bash(npm test*)",
      "Bash(npm run lint*)",
      "Bash(git status*)",
      "Bash(git diff*)"
    ]
  },
  "defaultMode": "default"
}

公式仕様ではdeny → ask → allowの順で評価されます。allowにBash(*)のような広いルールを書くと事故のもとです。次の原則をチームで合意します。

allowは読み取り系（status/diff/log）と検証系（test/lint/tsc）に限定する
破壊的・外向き通信（push/publish/curl/wget）はaskまたはdeny
Read(./.env*)はチーム共通でdenyに入れる
defaultModeはdefaultを推奨。acceptEditsはファイル編集とfilesystem系Bashを自動承認するため、初期チームでは避ける
bypassPermissionsは隔離環境（devcontainer・サンドボックスVM）でのみ許可する

設定をリポジトリの.claude/settings.jsonに置いてGit管理すれば、全員が同じ権限ルールで作業できます。詳細は「Claude Codeを使うときのセキュリティチェックリスト」を参照してください。

2. レビュー必須化ルール：AIコミットは無条件で人間レビュー

「AIが書いたコードもレビューする」を口頭合意で終わらせると、忙しい時期に省略されます。次の形でルール化します。

PR本文に「AI生成行数」を書く欄を必ず入れる
Co-Authored-By: Claudeを含むコミットを含むPRはApprove 1人＋自動Approve禁止
レビューは「コードレビュー前にローカルで/reviewを回した結果を貼る」を必須化
リファクタ・依存追加・マイグレーション系PRは2人レビュー

/reviewとWriter/Reviewerパターンの使い分けは「Claude Codeをコードレビューに使う方法と人間が見るべきポイント」で扱っています。

3. CLAUDE.md集約ルール：プロジェクト共通ルールはここに集める

CLAUDE.mdをチームで運用するときの原則は次の3つです。

リポジトリルートの./CLAUDE.mdにチーム共通ルールを書く（Git管理）
個人のクセは./CLAUDE.local.mdに書く（.gitignoreに追加）
200行を超えたら.claude/rules/に分割しpaths frontmatterで対象を絞る

書くべき内容は次のとおりです。

プロジェクト概要・触る場所
禁止事項（破壊コマンド・本番URL・特定ファイル）
確認コマンド（lint・型・テスト・ビルド）
コミット・PRルール
秘密情報の取り扱い

完全版テンプレートは「CLAUDE.mdテンプレート完全版」を参照してください。

4. 禁止事項ルール：5つは最初の日に書く

CLAUDE.mdの禁止事項セクションは、チーム導入初日に次の5項目を入れます。

## 禁止事項

- `.env*`の内容を読まない・出力しない
- `git push --force`を使わない
- `npm publish` `pip publish`等の公開系コマンドを実行しない
- 依存追加（package.json/lockの変更）は提案のみ、実行は人間が行う
- データベースのマイグレーション・本番DBへの接続は人間が行う

このセクションはCLAUDE.mdの冒頭付近に置き、強調表記（IMPORTANT や見出し）にします。Best Practicesでも「IMPORTANT/MUST/NEVER」のような明示的な強調が効くと示されています。

5. ログ・監査ルール：誰がいつ何をしたか

チーム規模が10人を超えると、誰がどのAI操作をしたかが分からなくなります。次の3点でログを残します。

GitHub上のAI操作：anthropics/claude-code-actionのログがActionsに残る。リポジトリ管理者が定期確認
コミット署名：AI生成コミットにはCo-Authored-By: Claudeを含めるルールにする
OpenTelemetry連携：Claude for EnterpriseではOpenTelemetryメトリクスが出せる。Datadog・Grafanaへ集約

PreToolUse・PostToolUse・ConfigChangeのHooksを使えば、ローカル側でも操作ログを残せます。ConfigChangeフックを設定すれば、セッション中の.claude/settings.json改変を検知・ブロックできます。

6. 責任分界ルール：AIが間違えても最終責任はマージした人間

AIの出力が原因で事故が起きたとき、責任の所在が曖昧だと再発防止が進みません。次の言葉でチーム合意を取ります。

AIの出力に責任を持つのはApproveした人間：レビュアー＝責任者
マージ承認は1人以上の人間Approveが必須：自動Approveの仕組みを入れない
本番デプロイは人間がgh pr mergeまたは手動デプロイ：AIにmergeを持たせない
インシデント時はAI由来かどうかをポストモーテムで明記：原因分析のためで責任追及ではない

この原則を「Claude Codeのみが原因のインシデントは発生しない」という公式の立場と整合させて、社内ドキュメントに残します。

7. 更新ルール：ルール自体の改廃手順

最後の落とし穴は「ルールが古くなる」ことです。Claude Codeは公式機能が頻繁に更新されるため、3ヶ月で陳腐化します。

CLAUDE.mdの冒頭に「最終更新日」を書く
月1回、.claude/settings.jsonとCLAUDE.mdを見直す時間を取る
公式リリースノート（claude updateの出力／GitHub Releases）をチームSlackに流す
ルール改廃はPRで提案し、リポジトリ管理者がApproveする

チーム導入の最初の1週間ロードマップ

日	やること
1日目	利用プラン決定（Claude for Teams/Enterprise/Console）／OAuth確認
2日目	リポジトリに`.claude/settings.json`を追加（権限ルール）
3日目	`CLAUDE.md`に共通ルール・禁止事項を書く
4日目	GitHub ActionsCIに lint/型/テスト/gitleaksを追加
5日目	レビュー必須化・コミット署名ルールを決める
6日目	新人向けオンボーディングテンプレートを作る
7日目	1週間運用してみてルール調整

CI整備は「Claude CodeとGitHub ActionsでCIを整える手順」で、オンボーディングは「新人メンバーにClaude Codeを安全に使ってもらうオンボーディング」で扱っています。

Claude for Enterpriseのmanaged-settings.json

組織横断で強制したい設定は、Claude for Enterpriseのmanaged-settings.jsonで配布できます。配布された設定はユーザー側のlocal/projectで上書きできません。次のような項目を組織レベルで固定します。

permissions.denyの最低集合（.env*・~/.ssh/**・~/.aws/**）
defaultMode: "default"
modelの指定（チーム標準モデル）
特定MCPサーバーのみallowedMcpServersに許可

ManagedスコープはMDM/サーバー配布で適用されるため、IT部門と協調して設計します。

よくある失敗パターン

症状	原因	対処
`.env`がコミットされた	`.gitignore`頼みでdeny ruleを書いてなかった	`Read(./.env*)`を`deny`／gitleaks／pre-commit
AIが勝手に依存を追加した	`npm install`をallowしていた	`Bash(npm install*)`を`ask`または`deny`
本番DBに繋いだ	DB接続情報がREADMEに書かれていた	接続情報は環境変数／READMEから削除／CLAUDE.mdで禁止明記
レビュー省略でマージ	ブランチ保護なし	Branch protection rules・必須Approve数1以上
設定が人によって違う	`.claude/settings.json`を共有していない	リポジトリにコミット・project scope運用