Claude Codeを導入して権限設定も済ませた後、現場から「破壊的な変更はどこまで自動で進めていいか」「AIが開いたPRは誰がマージするか」という質問が出てくる段階がある。これは権限設計の話ではない。許可・禁止をどう設定するかは決まっていても、日々の運用でその設定をどう使い、どこを人の判断に残すかは別の論点だからだ。公式ドキュメントが機械的に強制できると明記している範囲と、ドキュメントが「ここは決めてください」と線を引いている範囲を分けて整理する。

機械的に強制できる範囲

1. 破壊的操作をhookで止める

公式のhooksドキュメントは、PreToolUseイベントでツール呼び出し自体をブロックする仕組みを用意している。スクリプトがstderrにメッセージを出してexit 2で終了すると、その呼び出しは実行されずに理由がClaudeへ伝わる。rmコマンドやterraform destroyのような取り返しのつかない操作を狙い撃ちでブロックするhookは、この仕組みの典型的な使い方だ。

ここで詰まりやすいのが終了コードの扱いだ。公式ドキュメントは「終了コードの扱いは厳密で、exit 2以外の非ゼロ終了（exit 1など）はブロックにならない」と明記している。さらに、hookの実行がタイムアウトした場合もPreToolUseではツール呼び出しはブロックされず、通常の権限フローに進んでしまう。「hookを書いたから安全」と思い込むのではなく、タイムアウトしても安全側に倒れる設計になっているかを初回実行時に確認しておく必要がある。

2. 誰の設定が勝つかを決める

hookや権限ルールは~/.claude/settings.json（個人・全プロジェクト）、.claude/settings.json（プロジェクト共有・git管理）、.claude/settings.local.json（プロジェクト・個人用・gitignore対象）、組織の管理ポリシー設定の4段階に分かれる。公式ドキュメントによれば、これらは置き換えではなくマージされる。つまり個人の設定で管理者のhookを無効化することはできない。より厳密な統制が必要な組織にはallowManagedHooksOnlyという設定もあり、これを有効にすると管理者配布のhook以外（ユーザー・プロジェクト・プラグインのhook）を一律でブロックできる。

「チームで共有したいルール」と「個人の好みの設定」をどちらに置くかを最初に決めておかないと、.claude/settings.local.jsonに書いた個人設定がgitにコミットされず、他のメンバーの環境では無言で発動しないという事故が起きる。

3. レビュー基準をCLAUDE.mdとREVIEW.mdで書き分ける

Claude CodeのCode Review機能は、PRの差分を解析して行単位でコメントを付ける。公式ドキュメントは、このレビューが読む2つのファイルの役割を明確に分けている。CLAUDE.mdは通常のセッションでも使う共有の前提知識で、レビューではここへの違反を「Nit（軽微）」として扱う。一方REVIEW.mdはレビュー専用の指示ファイルで、「自社では何を🔴Important（マージ前に直すべき）として扱うか」「生成ファイルやlockfileなど報告しなくていい対象」「新しいAPIルートには必ず結合テストを求める、といった自社固有のチェック項目」をここに書く。公式ドキュメントも「レビューだけに関わる指示は、長いCLAUDE.mdに混ぜるよりREVIEW.mdに書いた方が確実に効く」としている。

人が決めるしかない範囲

4. レビュー結果をマージ判断にどう繋ぐか

ここが見落としやすい。公式ドキュメントは、Code ReviewのGitHub上のチェック実行について「常にneutralな結果で完了し、ブランチ保護ルールによるマージを一切ブロックしない」と明記している。🔴Importantの指摘が残っていても、設定次第ではそのままマージできてしまうということだ。レビュー結果でマージを止めたいなら、チェック実行の出力をCIが読み取って自社のブランチ保護に反映する仕組みを自分で組むしかない（出力の末尾にはghとjqで読み取れる機械可読な行が用意されている）。「AIが指摘したら直すまでマージしない」という運用にするかどうかは、機能ではなくチームの合意で決める話になる。

5. CIがAIのコミットに反応する設計になっているか

GitHub Actionsのドキュメントには、トラブルシューティングとして「GitHubは既定のGITHUB_TOKENで作られたコミットに対してワークフローを発火させない」という注意書きがある。Claude Code GitHub Actionにこのトークンをそのまま渡していると、AIが開いたPRでCIが一切回らないという事故になる。GitHub Appとして認証するか、カスタムトークンを使うかを明示的に選ぶ必要がある。加えて、誰が実行をトリガーできるかにも仕組みがある——issueやPRコメントでの起動は投稿者がリポジトリへの書き込み権限を持つ場合に限られ、ボットアカウントによる起動もallowed_botsに明示しない限り拒否される。定期実行（cronトリガー）も、ワークフローのスケジュールを最後に変更したユーザーがボットだと同じ理由で止まる。

自社の場合で実際に決めたこと

このLP自体の記事公開パイプラインも、この5項目のうち4と5に当たる判断を実際に下している。記事PRはnpm run buildの成功とAnthropicの一次ソースとの事実確認を条件に自動マージして構わないが、助成金・補助金を主題にした記事は事実確認で問題がなくてもマージせず、人間の確認を待つという例外をCLAUDE.mdに明文化している。数値・期限の断定リスクが、技術的な正しさとは別の基準で判断を要するからだ。「機械的に正しいことを確認できる範囲」と「人の判断が要る範囲」の境界線をどこに引くかは企業ごとに違ってよいが、境界線を引かずに「だいたい大丈夫だろう」で運用しているチームは、定着しない理由で触れたオーナー不在と同じ構造の問題を抱えていることが多い。

この5項目に即答できない場合、まず埋めるべきは追加のツール導入ではなく、この5つを文書にして関係者で合意することだ。自社の運用ルール設計を一緒に整理したい場合は、パイロット・構築のフェーズで相談できる。まずは30分の無料診断から。