【2026年最新】Claude Code開発環境標準化7項目

この記事の要点

Claude Codeをチームへ導入するときは、ツールを配る前に「どの端末・どの設定・どの権限で、どこまで自動化するか」を決めるのが先です。2026年9月18日時点で、公式ドキュメントにある設定ファイル、権限ルール、フック、worktree、非対話実行を組み合わせると、個人の好みに依存しない開発環境を段階的に作れます。

この記事は、既存のCLI利用を前提に、開発者が手元で確認できる標準化の7項目を扱います。数値の削減率や架空の導入成果は置かず、公式仕様と想定シナリオを分けて書きます。

1. 実行環境：ローカル、SSH、クラウド、CIの境界を決める
2. 設定の置き場：CLAUDE.md、settings.json、managed settingsを分ける
3. 権限：deny・ask・allowの順序と禁止操作を定義する
4. 作業分離：worktreeとブランチの単位を揃える
5. 品質ゲート：PreToolUseフックとテストを組み込む
6. 自動化：claude -p、allowedTools、CIの責任範囲を決める
7. 運用確認：導入後に設定・ログ・レビュー経路を点検する

対象読者：Claude Codeを業務導入したい開発者、テックリード、プラットフォームエンジニア。今日やること：対象リポジトリを1つ選び、現在のCLAUDE.mdと.claude/settings.jsonの責任範囲を棚卸ししてください。

1. 最初に固定するのは「どこで実行するか」

ローカル・SSH・クラウドを同じものとして扱わない

Claude CodeはCLI、IDE拡張、Desktop、クラウドセッションなど複数の入口から使えます。ただし、同じプロンプトを送っても、ファイルの置き場、ネットワーク、認証情報、利用できる設定の届き方が同一とは限りません。標準化の最初の成果物は、ツールのインストール手順ではなく「この種類の仕事はどこで走らせるか」の表です。

仕事	標準の実行場所	理由
対話的な実装	開発者のローカル	差分・テスト・依存関係を同じ端末で確認する
リモート環境が必要な作業	SSHセッション	実行環境とデータ境界を合わせる
長時間で端末から切り離す作業	クラウドセッション	ネットワークとリポジトリ要件を確認したうえで使う
定期実行・CI	非対話CLI	入力・権限・出力をパイプラインとして記録できる

クラウドセッションの隔離やGitHub連携の前提は、Anthropic「Use Claude Code on the web」の現行仕様を確認してください。ネットワーク境界を理由に「安全」と断定せず、許可リスト、認証経路、ログの保存場所を組織の規程と突き合わせます。

2. 設定ファイルの責任範囲を分ける

CLAUDE.mdは判断基準、settings.jsonは機械的な設定

CLAUDE.mdには、リポジトリの構成、テストコマンド、レビュー観点、変更してはいけない領域など、Claudeが作業時に読むプロジェクトルールを書きます。一方、settings.jsonには権限ルール、環境変数、フックなど、ランタイムが解釈する設定を置きます。説明文をCLAUDE.mdだけに書いても、権限の境界そのものは変わりません。

公式の設定ドキュメントでは、ユーザー、プロジェクト、ローカル、managed settingsなどのスコープと優先順位が説明されています。Anthropic「Settings」を基準に、コミットする設定と端末固有の設定を分けてください。

チームで共有する最小のCLAUDE.md

# Project rules

## Before editing
- Read the relevant tests and existing interfaces first.
- State assumptions when requirements are incomplete.

## Validation
- Run the focused test command before the full suite.
- Report changed files and remaining risks.

## Review boundary
- Do not push, deploy, or send external messages without human review.

これは想定シナリオの最小例です。実際のコマンド名はリポジトリに合わせて書き換え、存在しないスクリプトやテストを例として固定しないでください。

3. 権限はdeny・ask・allowの順で設計する

先に禁止を決め、次に確認、最後に許可を絞る

Claude Codeの権限ルールはdeny、ask、allowの順に評価され、先に一致した結果が使われます。狭いallowを書いても、広いdenyの例外にはなりません。まず本番環境への操作、外部送信、秘密情報の読み取りなど「実行させないもの」を整理し、その後に読み取りやテストなど戻せる操作を許可します。

Anthropic「Permissions」には、Bashのパターン、ファイルパス、MCP、PreToolUseフックとの関係が記載されています。`CLAUDE.md`の指示は行動を誘導しますが、権限を強制する仕組みではない点に注意が必要です。

{
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)",
      "Bash(git diff *)"
    ],
    "ask": [
      "Bash(git commit *)"
    ],
    "deny": [
      "Bash(git push *)",
      "Read(./.env)",
      "Read(./secrets/**)"
    ]
  }
}

上のJSONは設計例です。`npm run lint`やテストの実在、`.env`の配置、Git運用の責任者を確認してから採用します。denyのパターンだけで全てのシェル表現を網羅できるとは限らないため、ネットワーク側の制御やフックも組み合わせます。

4. worktreeで並列作業の境界を作る

セッションを増やす前にブランチの責任を決める

複数のClaude Codeセッションを同じ作業ディレクトリで動かすと、変更ファイルやテスト結果が混ざります。Gitリポジトリではworktreeを使い、調査、実装、テストなどの作業単位ごとに作業コピーを分けます。公式のGit worktreesにも、セッションごとの隔離と後片付けの考え方があります。

git worktree add ../repo-feature-a -b feature/a
git worktree add ../repo-fix-b -b fix/b

# 作業終了後に確認して削除する
git worktree list
git worktree remove ../repo-feature-a

worktreeを使えば競合が消えるわけではありません。共有DB、同じ開発サーバー、生成物の出力先、環境変数など、リポジトリの外側にある共有資源も別途分離します。

5. PreToolUseフックを品質ゲートにする

権限ルールとフックの役割を混同しない

PreToolUseフックはツール呼び出しの直前に実行され、入力を検査してallow、ask、denyなどの判断を返せます。権限ルールが広い操作の境界を決めるのに対し、フックはコマンド全体や引数を見て条件を追加する用途に向きます。公式のHooksには、stdinのJSONを読む例と、`permissionDecision`を返す形式が掲載されています。

#!/usr/bin/env bash
set -euo pipefail
input=$(cat)
command=$(printf '%s' "$input" | jq -r '.tool_input.command // ""')

if printf '%s' "$command" | grep -Eq 'git push|deploy|curl.*-X[[:space:]]+POST'; then
  jq -n '{hookSpecificOutput:{hookEventName:"PreToolUse",permissionDecision:"deny",permissionDecisionReason:"External side effect requires human review"}}'
fi

この例は外部副作用を一律に止める想定です。jqの有無、コマンドのラッパー、OS差分を検証し、フックが失敗したときの既定動作も確認してください。フックを置いたことだけでデプロイ事故を完全に防げる、とは書きません。

6. 非対話実行はCLIとCIに閉じ込める

claude -pの入力・権限・出力を固定する

Claude Code公式ドキュメントは、`-p`（`–print`）で非対話実行し、`–allowedTools`や`–output-format`を組み合わせる方法を示しています。Desktopの対話操作と同じ感覚でCIに持ち込むのではなく、入力を明示し、許可するツールを絞り、結果を機械的に扱える形式で保存します。

git diff --no-ext-diff origin/main...HEAD | \
  claude -p "Review this diff. Return only findings with file and line." \
  --allowedTools "Read" \
  --output-format json

Anthropic「Run Claude Code programmatically」では、`claude -p`の終了コード、構造化出力、ツールの自動承認、CIでの扱いが説明されています。CIで書き込みを許可する場合は、対象ブランチ、成果物、ロールバック手順を先に定義してください。

7. managed settingsと運用確認をセットにする

管理設定は配布経路と優先順位まで記録する

組織で共通ポリシーを適用するなら、managed settingsの配布経路と、ユーザー・プロジェクト設定との優先順位を確認します。公式のDeploy managed settingsには、管理者が上位の設定を配布する方法や、権限ルールだけを管理設定に限定するキーが記載されています。

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  },
  "disableAutoMode": "disable"
}

上の値をそのまま全社適用するのではなく、対象プラン、利用サーフェス、開発環境、例外申請の有無を確認します。managed settingsでCLI・Desktop・クラウドの挙動が同じになるとは限らないため、代表端末で実効設定を確認します。

導入後チェックリスト

• 設定ファイルのスコープとコミット状態を確認した
• deny・ask・allowの代表ルールを安全なテストコマンドで確認した
• PreToolUseフックの正常系・拒否系・失敗時を確認した
• worktreeの作成・レビュー・削除を一巡した
• CIの入力、allowedTools、出力、終了コードを記録した
• managed settingsがどの環境に届くかを確認した

導入を小さく始めるための実装順

最初の対象はリポジトリ1つ、作業1種類に絞る

業務導入の初手で、全リポジトリ・全開発者・全ツールを同時に統一しようとすると、設定の正しさと運用の使いやすさを切り分けられません。まずは、テストコマンドが明確で、レビュー担当が決まっているリポジトリを1つ選びます。対象を絞るのは導入を小さく見せるためではなく、失敗時の影響範囲を管理するためです。

候補を選ぶときは、次の順番で棚卸しします。第一に、コードを変更しても本番へ直結しないこと。第二に、テストと静的解析をローカルで再現できること。第三に、作業前後の差分をレビューできること。第四に、秘密情報や個人情報を含むファイルの境界が説明できることです。ここが曖昧なまま、権限だけを広げるのは避けます。

導入前に取るベースライン

導入効果を主張するには、導入前後の測定方法と対象範囲が必要です。実施していない時間短縮率や削減率を記事や社内資料に書くのではなく、まず記録項目を決めます。想定シナリオでは、タスクの種類、変更ファイル数、テスト実行の有無、レビューで戻った回数、手動で確認した箇所を記録する設計にします。

記録項目	確認する理由	記録の単位
タスクの種類	実装、調査、レビューを混ぜない	Issueまたは作業単位
変更範囲	大規模変更と小修正を分ける	ファイル・行の差分
検証内容	AIの出力とテスト結果を混同しない	コマンドと終了コード
人の判断点	どこを自動化しなかったかを残す	レビューコメント

効果を可視化する場合も、Claude Codeだけの寄与と、テスト整備・仕様の明確化・レビュー手順の変更を切り分けます。単一のツールが結果を保証したように書かないことが、チーム内の期待値調整にもつながります。

設定をレビューするための差分チェック

設定変更もコード変更と同じように扱う

`.claude/settings.json`、`managed-settings.json`、`CLAUDE.md`、フックのスクリプトは、見た目が文書でも実際の動作境界を変えます。誰かがローカルで権限を追加した場合、その設定がチームの標準なのか、個人だけの例外なのかをレビューで判定できる状態にします。

具体的には、プロジェクトにコミットするファイル、端末ごとに置くファイル、管理者だけが配布するファイルをREADMEや運用メモに列挙します。値そのものに秘密が入る場合は、リポジトリや記事に実値を書かず、環境変数名と設定方法だけを共有します。

変更レビューで見る5つの観点

1. 対象スコープ：ユーザー、プロジェクト、ローカル、managedのどこに置かれたか
2. 権限の広がり：allowが追加され、denyが狭くなっていないか
3. 外部通信：curl、WebFetch、MCPなどの到達先が増えていないか
4. 実行者：開発者の対話操作か、CIやスケジュールか
5. 戻し方：設定を元へ戻したときに、既存セッションへどう反映されるか

設定設計の全体像を既刊と見比べたい場合は、Claude Codeチーム導入ロードマップとClaude Code権限設計ガイドも参照してください。本稿は開発環境の標準化に絞り、個別の組織ポリシーは各社の規程に合わせて決めます。

テストとレビューを作業ループに組み込む

生成→検証→差分確認を分ける

Claude Codeに大きな依頼を一度に渡すのではなく、作業を段階に分けます。最初は既存コードとテストを読ませ、次に変更案を計画させ、最後に限定したファイルだけを編集させます。各段階で人が確認できるため、仕様の読み違いを早い段階で止められます。

初回は読み取りだけで進めてください。
認証モジュールと関連テストを読み、責任範囲、依存インターフェース、確認済みの条件、不足情報を分けて報告してください。

変更後は、変更ファイル、実行したテスト、未確認のリスクを分けて報告してください。

この形式はプロンプトの正解を保証するものではありません。プロジェクトのテストやレビュー基準に合わせ、読み取りだけで済む工程と、編集を許可する工程を分けます。

失敗したときの戻し方を先に書く

作業の前にコミットやブランチの状態を確認し、どの変更ならgitで戻せるかを決めます。未コミットの変更があるリポジトリでは、Claude Codeに触らせる前に、人が差分を保存するか、別のworktreeを用意する方が安全です。

失敗ログを残すときは、秘密情報、アクセストークン、顧客データ、環境固有のURLを含めないようにします。ログをチケットに貼る場合も、まずマスキングしてから共有し、元データの保存場所とアクセス権を確認します。

チームに展開するときの役割分担

開発者・レビュアー・管理者の仕事を分ける

開発者が毎回すべての設定を決める運用は、チームが大きくなるほどばらつきます。開発者は担当リポジトリのCLAUDE.mdとテストを更新し、レビュアーは差分と検証結果を確認し、プラットフォーム担当者はmanaged settingsやCIの共通部分を管理する、というように責任を分けます。

役割	担当するもの	判断しないもの
開発者	コード、テスト、プロジェクトルール	全社の外部通信ポリシー
レビュアー	差分、テスト、変更理由、残リスク	個人端末の秘密値
プラットフォーム担当	managed settings、CI、監査ログ	業務仕様の最終判断
セキュリティ担当	機密区分、ネットワーク、インシデント対応	個々の実装内容の代替レビュー

権限を中央管理しても、AIの出力が業務仕様に合っているかは別のレビューです。技術的な実行権限と、変更内容を承認する責任を混ぜないことが、導入後の事故対応を分かりやすくします。

例外申請を標準フローに含める

現実には、通常のdenyルールでは動かない特殊なビルドや、一時的な外部サービス連携が出てきます。例外を個人のsettings.local.jsonに隠すのではなく、対象作業、期限、許可するツール、レビュー担当、終了後の撤去を記録します。期限のない例外は、次の監査で標準設定の一部と誤認されます。

導入後30日ではなく、最初の数回を観測する

日数を成果の約束にしない

導入スケジュールはチームの規模やリポジトリの状態で変わります。ここで「何日で定着する」と断定するより、最初の数回のセッションを観測し、どの承認が多いか、どのテストで止まるか、どの設定が読まれていないかを確認します。

観測の結果から、CLAUDE.mdの説明不足と権限不足を分けます。説明不足ならルールの書き方を直し、権限不足なら最小の範囲だけallowやaskを追加します。失敗したからといって、いきなりbypassPermissionsを標準にするのは逆方向です。

定期点検で見るログ

• 誰がどのモデルと環境を使ったか
• どの権限プロンプトが繰り返し発生したか
• 拒否されたツール呼び出しが、正しい拒否だったか
• フックの失敗やタイムアウトがなかったか
• CIで生成された変更を人がレビューしたか
• 不要になったworktreeや例外設定が残っていないか

ログの保存期間や個人情報の扱いは、所属組織のポリシーに合わせます。AIの会話やツール入力を無制限に保存する前に、何を監査に使うのか、誰が見られるのか、削除手順は何かを決めてください。

導入前に作る運用テンプレート

作業タイプごとの許可表を先に書く

標準化で役立つのは、抽象的な「安全に使う」という宣言ではなく、作業タイプと許可範囲の対応表です。たとえば、コードの読み取りは自動許可、テストの実行はリポジトリ内に限定、コミットは確認、pushとデプロイは人が実行、というように操作を分けます。開発者が迷うポイントを先に表にしておけば、毎回の承認画面で判断をやり直す必要がありません。

作業タイプ	Claude Codeに任せる範囲	人が確認する点
コード調査	Read、Grep、Glob、差分の要約	対象パスと機密情報の有無
テスト	決められたテストコマンド	入力データ、実行時間、外部通信
実装	対象ディレクトリ内のEdit	仕様、差分、テスト結果
コミット	メッセージ案の作成まで	変更範囲とコミット内容
公開操作	手順と確認項目の整理まで	push、deploy、外部送信の直前

停止条件を明文化する

AIが判断に迷ったときに作業を続けるのか、質問して止まるのかも標準化の一部です。要件が不足している、対象ファイルが想定より広い、テストが失敗した、秘密情報らしい値が見つかった、外部サービスへの送信が必要になった、という条件では停止して人へ返すルールをCLAUDE.mdに書きます。

停止条件は、AIを信用しないためだけに置くものではありません。作業の境界を明確にし、レビュー担当者が「なぜここで止まったか」を追跡できるようにするためです。

設定のテストを自動化する

JSONの妥当性だけでなく、意図した拒否を確認する

settings.jsonがJSONとして読めても、権限ルールが意図どおりに働くとは限りません。代表的な許可、確認、拒否の3ケースを用意し、Claude Codeの実行環境で確認します。確認用の操作は、破壊的なコマンドではなく、読み取りや一時ディレクトリへの安全なテストで構成します。

設定ファイルの構文確認例：python3 -m json.tool .claude/settings.json >/dev/null
代表ケースは安全なコマンドで確認する：読み取りが通る／テスト実行が許可または確認になる／外部送信が拒否される

設定のテストは、設定ファイルを更新したPull Requestのチェックにも組み込めます。ただし、静的な文字列検査だけでは、Claude Codeのバージョン差分やラッパーの挙動までは見えません。対象バージョンと実行環境を記録し、重要な変更は実機でも確認します。

フックには失敗時の観測性を持たせる

PreToolUseフックが動かなかった場合、作業がそのまま通るのか、Claude Codeがエラーを返すのかを把握します。フックの標準出力をJSONに限定し、デバッグ情報は標準エラーや別の監査ログへ分けます。エラーを握りつぶすスクリプトは、見かけ上の自動化だけを残して境界を失わせます。

リポジトリの規模に応じた標準化

小規模チームはルールを増やしすぎない

開発者が数名で、リポジトリも限定されている場合は、CLAUDE.mdとプロジェクトsettings.json、Pull Requestレビューの3点から始められます。managed settingsや複雑なフックを先に導入すると、例外の説明にコストがかかることがあります。まず、機密ファイルのdeny、テストの手順、push前のレビューを共有するだけでも、作業の再現性は上がります。

複数チームでは共通層と個別層を分ける

複数チームに広げるときは、全社共通の禁止事項、組織共通の管理設定、リポジトリ固有のCLAUDE.md、開発者個人のローカル設定を分けます。共通層に業務固有の細かい前提を詰め込むと、別チームで使えないルールが増え、ローカル設定で上書きしたくなります。

共通層に置くのは、秘密情報の取り扱い、外部送信の境界、ログの扱い、承認が必要な操作など、チームをまたいでも変わりにくい原則です。技術スタックやテストコマンドは各リポジトリへ置き、変更の責任者を明示します。

標準設定を更新するときは、適用範囲、対象バージョン、ロールバック方法、例外の扱いを同じPull Requestに記録します。設定の説明と実際のJSONが別の場所にあると、変更理由が追えず、古い手順だけが残ります。

レガシーリポジトリは先に観測する

古いリポジトリでは、暗黙のビルド手順、手動でしか再現できないテスト、更新されていないドキュメントが残っていることがあります。いきなり自動編集を許可せず、まずClaude Codeに構成と依存関係を読ませ、現状の不明点を一覧にします。標準化は、ルールを増やす作業ではなく、暗黙知をレビュー可能な形へ変える作業でもあります。

観測の成果物には、依存関係の境界、データの流れ、テストの入口、手動作業の一覧を含めます。ここまで整理すると、Claude Codeに任せる部分と、既存の運用を変えずに人が担当する部分を分離できます。

レビュー記録をチームの資産にする

プロンプトではなく判断結果を残す

AIとの会話をそのまま保存するだけでは、後から判断を再利用しにくいことがあります。レビュー記録には、依頼の目的、対象範囲、採用した変更、採用しなかった提案、実行したテスト、残っているリスクを短く残します。これなら次の担当者は会話全体を読み直さず、変更の根拠と検証結果を確認できます。

記録欄	書く内容
目的	何の不具合・要件・調査を扱ったか
対象	リポジトリ、ブランチ、変更したディレクトリ
判断	採用した案と、採用しなかった案の理由
検証	テスト名、終了コード、手動確認の有無
残リスク	未確認の環境、次に人が確認する項目

レビューの責任者を置く

Claude Codeの出力を読んだ人と、変更を承認する人が同じとは限りません。特に認証、課金、個人情報、インフラ、外部公開に関わる変更は、専門領域の担当者が最終判断します。AIが「テストが通った」と報告しても、テストが要件を十分に表しているかは別の問いです。

導入が進んだ後も、設定の変更、例外の追加、フックの停止、CIの権限変更はレビュー対象から外しません。開発環境を標準化する目的は、AIを無条件に自動化することではなく、誰が何を確認したかを追跡できる状態を作ることです。

この記録を毎回同じ場所に残すと、似た作業のレビュー観点を再利用できます。ただし、個人の会話履歴や秘密値をそのまま共有するのではなく、必要な判断と検証結果だけを要約し、アクセス権のあるリポジトリやチケットで管理します。

レビュー記録の形式は、チームの既存のPull Requestテンプレートや変更管理票に合わせます。新しい帳票を増やすこと自体が目的にならないよう、目的・検証・残リスクの3点が追える最小の形から始めます。記録の更新者と見直すタイミングも決め、古い手順が標準として残り続けないようにします。変更の背景、確認した環境、判断を保留した理由まで残しておくと、同じ問題を別の担当者がもう一度調査する負担も下げられます。担当者が変わっても同じ確認を再現できるように、対象ブランチと検証コマンドも併記します。レビューに使ったルールの版も記録し、変更後に結果が変わったときの比較材料にします。関係者が読んだときに判断の前提を追えるよう、用語の定義や前提条件も必要な範囲で添えます。確認した担当と承認日時も記録し、後から誰に聞けばよいか分かるようにします。レビューの根拠、対象環境、保留理由を同じ記録にまとめることで、後続の担当者が確認を再現しやすくなります。

よくある質問

CLAUDE.mdだけでチームの権限を統一できますか

できません。CLAUDE.mdはルールや前提を伝えるファイルで、権限の強制はsettings.json、managed settings、権限モード、フックなどで行います。両方を同じレビュー対象にしてください。

DesktopとCLIで設定は共有されますか

共有される設定がある一方、利用できるコマンド、セッションの見え方、環境変数、managed settingsの届き方には差があります。対象サーフェスの公式ドキュメントを確認し、同じ挙動だと決めつけないでください。

denyルールだけでpushを完全に止められますか

denyルールは重要な第一線ですが、コマンドの書き方やラッパーの差分まで自動的に保証するものではありません。PreToolUseフック、GitHub側の保護ルール、CIの権限分離を併用します。

非対話実行でツールを自動承認してよいですか

読み取りや決められたテストなど、戻せる操作に限定するのが基本です。書き込み・外部通信・デプロイを許可するなら、対象環境と監査ログ、失敗時の停止条件を先に決めます。

worktreeを使えば並列作業は安全ですか

ソースツリーの変更を分離しやすくなりますが、共有DB、ポート、生成物、秘密情報などは別問題です。作業開始前に共有資源の一覧を作り、必要なら環境も分けてください。

運営元 Uravation よりこの事例を自社の業務で試す場合のテーマ選定・評価・本番移行の確認項目を、無料のチェックリストにまとめています。 Claude Code業務自動化PoCチェックリストを受け取る（無料）

参考・出典

• Anthropic「Claude Code Overview」
• Anthropic「Settings」
• Anthropic「Permissions」
• Anthropic「Hooks」
• Anthropic「Git worktrees」
• Anthropic「Deploy managed settings」
• Anthropic「Run Claude Code programmatically」

著者：佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。生成AIとAIエージェントの業務導入を支援し、Claude Codeのチーム運用、権限設計、開発ワークフロー整備に取り組んでいます。

導入判断を自社のリポジトリ構成に合わせて詰めたい場合は、お問い合わせフォームから、対象環境と困っている工程を添えてご相談ください。

関連記事: 【2026年9月】Claude Code課金判定｜/status7項目

このテーマの関連記事

• ▸ 【2026年10月】Claude Code課金判定｜/status7項目
• ▸ Claude CodeがAGENTS.md対応｜優先順位と共通化手順【2026年10月】
• ▸ Claude Code×Playwright MCP連携｜E2Eテスト7手順
• ▸ Claude Projects刷新の使い方｜並列スレッド活用【2026年9月】
• ▸ 【2026年最新】Claude Codeのチーム導入を安全に進める7手順