結論：Claude Codeをチームの開発工程へ入れるなら、最初に整えるべきはプロンプトではなく、PRを作る前後の責任境界です。2026年9月17日時点の公式ドキュメントに合わせると、計画・実装・テスト・差分レビュー・人間承認を分け、共有設定と個人設定を分離する7手順が、再現しやすい出発点になります。
- 要点1：
CLAUDE.mdにプロジェクトの規約とレビュー条件を置き、チームで共有する。 - 要点2：権限はモード任せにせず、
.claude/settings.jsonの許可・確認・拒否ルールとPreToolUseフックで二重化する。 - 要点3：CIでは
claude -pと明示的な--allowedToolsを使い、書き込みやマージは別の人間承認へ戻す。
対象読者：Claude Codeを個人の補助からチームの開発工程へ広げたいエンジニア、テックリード、開発基盤担当者。
今日やること：対象リポジトリに、読み取り専用のレビュー依頼と、実行してよいコマンドだけを列挙した小さな設定を追加する。
「Claude Codeをチームでも使いたい。ただ、誰がどの権限で何を実行したか分からなくなるのは困る」。導入相談で、最初に出てくるのはこの種の話です。
個人のローカル環境なら、多少の設定の揺れは本人が吸収できます。複数人のリポジトリではそうはいきません。プロンプトの書き方、参照できるディレクトリ、シェルコマンドの許可、レビューの完了条件が人によって違うと、同じ作業名でもリスクが変わります。
この記事は、特定企業の実績を紹介するものではありません。想定シナリオ／実装パターン解説として、公式ドキュメントに記載されたClaude Codeの設定・権限・フック・CLIの機能を、チームのリポジトリに落とし込む順番を整理します。効果の割合や架空の削減時間は置きません。
なぜ「使い方」より先に責任境界を決めるのか
コード生成と変更承認は別の仕事
Claude Codeにテストや実装案を作らせることと、その変更をリポジトリへ取り込むことは別です。前者は開発支援、後者はチームの変更管理です。PR、差分、テスト結果、レビュー担当を分けておくと、「AIが出したから採用した」という曖昧な状態を避けられます。
共有設定と個人設定を分ける
Anthropicの設定ドキュメントでは、ユーザー設定、プロジェクト共有設定、プロジェクトローカル設定、管理設定というスコープが説明されています。チームでコミットする規約は.claude/settings.jsonへ、個人だけの例外は.claude/settings.local.jsonへ置く、という整理が基本です。後者を手作業で作る場合は、Git管理対象から外す必要があります。
評価するのは「賢さ」だけではない
業務導入で見るべき指標は、生成されたコードの見た目だけではありません。レビュー可能な差分になっているか、テストが再現できるか、失敗時に戻せるか、ログに秘密情報が残らないかを、工程の完了条件へ入れます。
Claude Codeの公式機能を工程へ対応づける
| 工程 | 使う機能 | 人間側の完了条件 |
|---|---|---|
| 要件整理 | CLAUDE.md、計画モード |
前提・非対象・受入条件がレビューされている |
| 実装 | Read、Edit、Bashなどの標準ツール | 変更範囲が対象ディレクトリ内に限定されている |
| 安全制御 | permission rules、PreToolUse |
許可・確認・拒否の境界が設定ファイルに残っている |
| 連携 | MCP、--strict-mcp-config |
接続先と書き込み操作の責任者が決まっている |
| 検証 | claude -p、テスト、差分確認 |
CIログとPRレビューで結果を追跡できる |
Claude Codeの概要ページは、ターミナルでコードベースを読み、編集やテストを支援する使い方に加え、CLAUDE.md、スキル、フック、MCPで動作をカスタマイズできると説明しています。ポイントは機能を全部有効にすることではなく、工程ごとに必要な機能だけを割り当てることです。
導入を始める7手順
手順1：対象リポジトリと非対象領域を決める
最初から全社の全リポジトリを対象にしません。まず1つのサービス、1つのチーム、1つの反復的な開発作業を選びます。対象にするディレクトリと、参照してはいけないディレクトリを文書化してください。顧客データ、秘密鍵、ローカルの認証ファイルを「便利だから」という理由で作業ディレクトリへ置かないことも、導入条件に含めます。
初回の依頼は、いきなり編集ではなく次のような読解にします。
リポジトリの構成を読み取り、変更せずに報告してください。
- 起動方法
- テストコマンド
- 変更してはいけないディレクトリ
- 既知の制約
不明な点は推測せず、質問として列挙してください。この段階で、出力がチームの期待する粒度かを確認します。期待と違えば、プロンプトを長くする前にCLAUDE.mdの不足を疑います。
手順2：CLAUDE.mdに「完了条件」を書く
CLAUDE.mdは、リポジトリの構造、開発コマンド、コーディング規約、レビュー前の確認事項を共有する場所です。単なる「丁寧に実装してください」ではなく、作業を止める条件まで書きます。
# 開発ルール
## 変更前
- 目的、対象ファイル、非対象ファイルを最初に列挙する
- 不明な仕様は推測せず質問または仮定として明示する
## 実装後
- 変更したファイルを列挙する
- 実行したテストと結果を示す
- 失敗したテストを隠さない
- 破壊的な変更には戻し方を書く
- 秘密情報、個人情報、トークンをログへ出さない
## 完了条件
- 差分を人間がレビューできる
- テストまたは検証手順が再現できる
- PRの説明に制約と未確認事項が残っている「何をするか」より「何をもって終わりにするか」を共有するのがコツです。作業者が変わっても、レビューの物差しが残ります。
手順3：まず計画モードで変更範囲を絞る
仕様が曖昧な作業では、いきなり編集を許可しません。対象ファイル、依存関係、テスト方法、リスクを先に出させます。計画が固まったら、承認された範囲だけを編集へ進めます。
公式の権限ドキュメントは、permission modeがツールの承認方法を変える一方、明示的な拒否ルールはモードをまたいで適用されると説明しています。つまり、モードだけを「安全装置」と考えず、ルールとフックを組み合わせます。
claude --permission-mode plan -p \
"変更候補、影響範囲、テスト計画、戻し方を整理してください"実際のCLIオプション名・利用可能なモードは、導入時点の公式CLIリファレンスで再確認してください。バージョンによる差を、記事や社内手順へ固定しないことが重要です。
手順4：許可・確認・拒否を設定ファイルで分ける
共有する設定では、リポジトリのテストや静的解析など、許可してよい操作を限定的に書きます。削除、資格情報の操作、本番環境への接続などは、拒否または毎回確認の領域として扱います。設定ルールの構文は更新されるため、ここでは考え方を示します。
{
"permissions": {
"allow": [
"Read",
"Bash(git diff *)",
"Bash(npm test)"
],
"ask": [
"Bash(git push *)"
],
"deny": [
"Bash(rm -rf *)"
]
}
}この例をそのまま全プロジェクトへ配布するのではなく、利用するClaude Codeのバージョンと公式の権限ルールで検証します。特にワイルドカードの解釈、複合コマンド、ラッパー経由の実行は、想定どおりに一致するかを小さなテストリポジトリで確認してください。
手順5：PreToolUseフックで危険操作を二重化する
権限ルールを設定しても、危険操作の検知をフックで補強できます。公式のHooks referenceには、PreToolUseでツール呼び出し前にコマンドを検査し、JSON形式で拒否理由を返す例が掲載されています。
#!/usr/bin/env bash
set -euo pipefail
command=$(jq -r '.tool_input.command // ""')
if [[ "$command" == *"rm -rf"* ]]; then
jq -n '{hookSpecificOutput:{hookEventName:"PreToolUse",permissionDecision:"deny",permissionDecisionReason:"destructive command blocked"}}'
fiフックは万能ではありません。スクリプト自体の権限、ログの扱い、JSON入力の形、エラー時の挙動をテストします。拒否したい操作の定義が広すぎると、必要な開発まで止まります。逆に狭すぎると安心感だけが残ります。
手順6：MCPは接続先と書き込み操作を別々に審査する
MCPは外部の設計資料、チケット、社内ツールなどとClaude Codeをつなぐ仕組みです。読み取りだけのサーバーと、チケット更新やコメント投稿を行うサーバーを同じ扱いにしません。
公式のMCPドキュメントには、プロジェクトのMCP設定、無効化リスト、厳格なMCP設定で指定したサーバーだけを使う方法が説明されています。導入時は、サーバー名、接続方式、必要な認証、読めるデータ、書けるデータ、停止方法を台帳にします。
claude -p "設計資料を参照して変更案だけを作成してください" \
--strict-mcp-config \
--mcp-config ./config/read-only-mcp.json外部ツールへの書き込みは、レビュー済みの別コマンドや人間の承認を経由させます。MCPサーバーが安全だと仮定するのではなく、そのサーバーが受け取る入力と返す出力を検査可能にします。
手順7：CIでは読み取り・レビューから始める
CIに組み込む最初の仕事は、差分の説明、テスト失敗の要約、危険な変更の指摘など、読み取り中心のタスクが向いています。書き込みや自動マージは、レビュー運用が定着してから別に検討します。
git diff --name-only origin/main...HEAD | \
claude -p "変更ファイルをレビューし、重大度・根拠・再現手順をMarkdownで返してください" \
--permission-mode dontAsk \
--allowedTools "Read" "Bash(git diff *)"公式CLIリファレンスでは、claude -pによる非対話実行や、--allowedToolsによる許可ツールの指定が案内されています。CIでは環境変数、ログ、ネットワーク、実行時間、コスト上限も別途設計してください。CIの「非対話」は、無制限の権限を意味しません。
実装パターン：仕様書から安全なPRまで
入力を「要求」「制約」「受入条件」に分解する
開発チームがClaude Codeへ渡す入力は、自然文一枚にまとめません。次の3ブロックに分けると、レビュー対象が見えます。
- 要求：ユーザーが達成したい動作。
- 制約：変更してよい範囲、使える依存、互換性、セキュリティ条件。
- 受入条件：テスト、エラーメッセージ、ログ、ドキュメントの期待値。
入力の不足を埋めるために、最初から実装を依頼するのではなく、質問一覧を返すよう指定します。
次の仕様を読み、実装はまだ行わないでください。
1. 不明な点
2. 影響を受けるファイル
3. 受入条件の不足
4. セキュリティ上の確認事項
を表で整理してください。
推測した内容には「仮定」と付けてください。差分を小さく保ち、レビューの単位をそろえる
一度に複数機能を実装させると、失敗原因が追いにくくなります。機能、テスト、ドキュメントを一つの小さな差分に閉じ込めます。大きな変更が必要な場合は、データモデル、API、UI、移行処理のようにPRを分けます。
「全部直して」ではなく、「この関数の境界を変えずに、異常系のテストを追加し、変更ファイルを3つ以内に収める」と書く方が、レビューしやすい結果になります。
失敗時の出力を成果物として残す
テストが通らないことは失敗ではありません。失敗を隠したまま完了扱いにすることが失敗です。コマンド、終了コード、再現条件、未解決の前提をPR説明へ残します。CIからの出力に秘密情報が含まれないかも確認します。
チームでの権限設計をレビューする
権限モードは運用シーンごとに選ぶ
対話的に設計を確認する場面と、CIで定型の読み取りを行う場面は異なります。前者は確認を残し、後者は明示的な許可リストとサンドボックスに寄せます。完全自動化を急ぐより、まず「自動でよい操作」の集合を小さく定義します。
拒否ルールは最も危険な経路から書く
拒否する対象は、ファイル削除だけではありません。本番接続、秘密情報の読み取り、認証設定の変更、外部サービスへの書き込み、Gitの強制操作など、失敗したときに戻しにくい操作を洗い出します。公式ドキュメントにある「拒否ルールはすべてのモードでブロックする」という説明と、組織の規程を照合してください。
レビュー担当をAIの出力から独立させる
AIに実装させた人が、同じ出力だけを根拠に承認する状態を避けます。変更の目的を理解している担当者が、差分、テスト、ログ、戻し方を見ます。AIのコメントはレビュー材料ですが、承認者ではありません。
セキュリティと秘密情報の扱い
.envを読ませないことを前提にする
.envや認証ファイルは、Git管理しないだけで安全になるわけではありません。Claude Codeが参照する作業ディレクトリ、シェルの環境変数、CIログ、MCPサーバーの入力経路を分けて確認します。サンプル設定には値ではなく変数名とプレースホルダーだけを書きます。
自己ホストやローカル実行を安全性の断定に使わない
実行場所がローカルでも、読み込むファイル、接続先、ログ、権限設定が適切とは限りません。公式のセキュリティ説明と組織の規程を確認し、個人情報や秘密情報を入力しないルールを先に決めます。「ローカルだから漏れない」「オンプレだから準拠済み」といった断定はできません。
ログを証跡と漏えい源の両面で見る
ログには、コマンド、ファイル名、エラーメッセージ、差分の一部が残る可能性があります。監査に必要な識別子を残しつつ、本文やトークンを出さないマスキングを用意します。ログを長く保存するほど安全になるわけではないため、保管期間と削除手順も決めます。
導入後に見るべきチェック項目
週次レビューで確認する5項目
- 許可ルールに、不要になったコマンドが残っていないか。
- フックが実際に発火し、拒否理由が開発者へ伝わるか。
- CIのログに秘密情報や個人情報が混ざっていないか。
- AIが作ったPRの差分とテスト結果を人間が確認しているか。
- 仕様変更時に
CLAUDE.mdと設定が更新されているか。
測定値は自社で取ってから公開する
開発速度、レビュー時間、修正回数などは、チームの言語、リポジトリ、テスト構成で変わります。一般記事の数字を自社の成果として転用せず、導入前の定義と導入後の測定方法を先に決めます。本記事では自社測定値を提示していません。
【要注意】よくある失敗パターンと回避策
失敗1：権限モードだけで安全だと思う
❌ モードを切り替えれば、どの操作も安全になると考える。
⭕ 拒否ルール、フック、作業ディレクトリ、レビュー承認を別々に定義する。
失敗2：共有設定へ個人の例外を混ぜる
❌ 自分だけ必要な許可を.claude/settings.jsonへコミットする。
⭕ チーム共通の設定と、ローカルだけの設定を分け、ローカル設定の管理方法を確認する。
失敗3：CIでいきなり書き込みまで許可する
❌ 非対話実行だからという理由で、pushやマージまで許可する。
⭕ まず読み取りとレビューから始め、書き込みは別の承認段階へ置く。
失敗4：MCPを一括で信頼する
❌ 接続できたMCPサーバーの全ツールを同じ権限で使う。
⭕ 読み取りと書き込みを分け、サーバーごとの入力・出力・認証・停止方法を台帳化する。
実装チェックリスト
- 対象リポジトリ、非対象ディレクトリ、扱わないデータを定義した。
CLAUDE.mdにテスト、差分、ログ、戻し方の完了条件を書いた。- 共有設定と個人設定を分けた。
- 許可・確認・拒否のルールを小さなリポジトリで試した。
- 危険操作を
PreToolUseフックでも検査した。 - MCPの接続先と書き込み操作を分離した。
- CIは読み取り中心で始め、
--allowedToolsを限定した。 - PRにテスト結果、未確認事項、ロールバック手順を残した。
- 秘密情報や個人情報をプロンプトとログへ入れない規程を確認した。
運用を広げる前のレビュー設計
レビュー観点をコードだけに限定しない
AIが作った差分を見るとき、変数名やテストの書き方だけを確認して終わりにしがちです。チーム導入では、要件に対して余計な変更が入っていないか、ログの粒度が適切か、例外時に安全側へ倒れるか、運用担当が戻せるかまで確認します。機能レビュー、セキュリティレビュー、運用レビューを同じ人が一度に行えない場合は、チェック欄を分けるだけでも抜けを減らせます。
PRテンプレートにAI利用の事実を残す
AIを使ったこと自体を隠す必要はありません。むしろ、どの工程で使ったかをPRへ残す方が、再現性とレビューの透明性を上げやすくなります。ただし、AIが出した説明をそのまま信頼するのではなく、実行したコマンドと人間が確認した範囲を書きます。
## 変更の目的
## AIを使った工程
- 仕様の整理 / 実装補助 / テスト案 / レビュー補助
## 人間が確認したこと
- 変更ファイル
- テスト結果
- 権限・ログ・個人情報の扱い
## 未確認事項と戻し方
- 未確認:
- ロールバック:承認を「はい・いいえ」だけにしない
承認者が見るべき情報を、差分の要約、影響範囲、テスト結果、未確認事項、戻し方に分解します。「AIが作ったので確認してください」では判断できません。承認者が短時間で確認できる形にしておくことが、チームの使い続けやすさにつながります。
段階的な導入ロードマップ
フェーズ1：個人環境で読み取りを試す
最初の段階では、コードベースの説明、テスト失敗の要約、ドキュメントの差分確認だけを対象にします。実データや本番認証を使わず、サンプルリポジトリまたは匿名化したブランチで、出力の再現性とログの見え方を確認します。
フェーズ2：小さなPRで編集を試す
次に、変更範囲とテストが明確な小さな修正へ広げます。許可するコマンドを列挙し、変更前のコミットを保存し、PRの承認者を決めます。ここで拒否ルールやフックの誤検知を洗い出します。止まること自体は問題ではなく、止まった理由が理解できることが重要です。
フェーズ3：CIと外部ツールへ接続する
CIやMCPを加えるのは、ローカルの境界が安定してからです。CI用の認証はジョブごとに最小権限とし、外部ツールへの書き込みは最初から自動化しません。実行ログの保存先、失敗通知、停止方法、認証の失効手順まで、運用ドキュメントに書いてから接続します。
各フェーズの移行条件を決める
「一週間問題がなかった」のような曖昧な移行条件ではなく、チェック項目で判断します。たとえば、対象外ディレクトリを読まないこと、拒否フックのテストが通ること、PRに未確認事項が残ること、CIログに秘密情報が出ないことを、次のフェーズへ進む前の条件にします。数値目標を置く場合は、チーム自身の測定方法と期間を明記してください。
障害時の切り戻しを先に決める
自動化を止めても開発が続く経路を残す
フックの不具合やMCPの停止で開発全体が止まらないよう、手動実行の手順を残します。CIのジョブを無効にする方法、設定を一つ前へ戻す方法、外部接続を解除する方法を、担当者以外でも実行できる形にします。
設定変更もコードレビューの対象にする
.claude/settings.json、フック、MCP設定、CLAUDE.mdは、アプリケーションコードと同じく動作へ影響します。設定だけの変更にも差分と理由を付け、危険な許可が追加されていないかを確認します。設定ファイルを直接本番へ上書きする運用は避け、Gitの履歴から戻せるようにします。
失敗の分類を残す
止まった理由を、権限拒否、仕様不足、テスト失敗、外部サービス停止、認証エラー、モデル出力の不備に分けます。分類があると、プロンプトを直すべきなのか、設定を直すべきなのか、運用手順を直すべきなのかを判断しやすくなります。エラーを「AIの気分」として片付けないことが、改善の出発点です。
導入時にチームへ説明する内容
できることと、できないことを同じ資料に書く
導入説明では、コードの読解、テスト作成、差分の整理など、使いやすい例だけでなく、最終判断を代替しないことも同じページに書きます。医療、金融、個人情報、顧客固有の仕様に関わる場合は、所属組織の規程と専門担当者の確認を優先します。
入力してはいけない情報を例示する
「機密情報を入れない」という抽象的な注意だけでは、現場で迷います。APIキー、パスワード、Cookie、患者・顧客を識別できる情報、未公開の契約情報など、具体的な例を列挙します。サンプルログやスクリーンショットにも同じルールを適用します。
困ったときの相談先を決める
権限の追加、MCPサーバーの接続、データ分類、CIの失敗を、個人の判断だけで進めない窓口を用意します。質問を受け付ける担当、緊急時に停止する担当、セキュリティ判断をする担当を分けると、導入の速度と安全性を両立しやすくなります。
要点の整理と次の一歩
Claude Codeの業務導入は、モデルに仕事を丸ごと渡す計画ではありません。どこまでを自動化し、どこからを人間が承認し、失敗時にどう戻すかを、コードと設定に残す計画です。
- 対象リポジトリを一つ選び、読み取り中心の作業で始める。
CLAUDE.mdと共有設定へ、完了条件と権限境界を書く。- 差分・テスト・ログをレビューしてから、書き込みや外部連携へ広げる。
自社の開発工程に合わせた導入順を整理したい場合は、お問い合わせフォームから、対象リポジトリの種類と現在の運用課題を共有してください。具体的な権限やデータの判断は、所属組織の規程とセキュリティ担当の確認を前提に進めます。
よくある質問
Q. Claude Codeにコードを自動で本番反映させられますか？
技術的な可否と、組織として許可するかは別です。まずは読み取り・テスト・PR作成など、戻しやすい工程から始め、本番反映は既存の承認・デプロイ手順へ従わせてください。
Q. CLAUDE.mdだけで権限を制御できますか？
できません。CLAUDE.mdは作業上の指示を共有する場所であり、権限ルールそのものの代わりにはなりません。公式ドキュメントにある設定ファイルの権限ルールやフックと組み合わせます。
Q. .claude/settings.local.jsonはコミットしてよいですか？
個人だけの例外を置くファイルとして扱うなら、通常はチーム共有の設定と分けます。手作業で作成した場合のGit除外を含め、プロジェクトの管理方針を確認してください。
Q. MCPを使うときに最初に確認することは何ですか？
サーバーが何を読み、何へ書けるかです。読み取りだけの接続から始め、書き込みツールは別の承認・監査経路に置きます。必要なら厳格なMCP設定で許可したサーバーだけを読み込ませます。
Q. CIでClaude Codeを使う場合、何を許可すべきですか？
対象ジョブに必要な最小限の読み取りとテストだけです。--allowedToolsで許可対象を限定し、ログに秘密情報を出さない設定と、失敗時の停止条件を用意してください。
運営元 Uravation よりこの事例を自社の業務で試す場合のテーマ選定・評価・本番移行の確認項目を、無料のチェックリストにまとめています。 Claude Code業務自動化PoCチェックリストを受け取る（無料）
参考にした一次情報・関連資料
- Claude Code overview — Anthropic公式（参照日: 2026-09-17）
- Configure permissions — Anthropic公式（参照日: 2026-09-17）
- Settings files and precedence — Anthropic公式（参照日: 2026-09-17）
- Hooks reference — Anthropic公式（参照日: 2026-09-17）
- Connect Claude Code to tools via MCP — Anthropic公式（参照日: 2026-09-17）
- CLI reference — Anthropic公式（参照日: 2026-09-17）
- Claude Code権限設計ガイド — 関連記事
- Claude Codeチーム導入ロードマップ — 関連記事
- DLP対応のClaude Code推論フック実装ガイド — 関連記事
