Claude Codeチーム開発ガイド｜CLAUDE.mdと権限管理の設計

Claude Codeをチームで使うということは、個人の生産性ツールを配るのではなく、プロンプトとルールを仕組みとして共有資産に変えるということです。

「メンバーごとにAIの出力品質がバラバラで、レビューの負荷がむしろ増えた」「各自がローカルで好き勝手にAIを動かしていて、何を許可しているのか誰も把握していない」「便利そうなので全社展開したいが、どこから手を付ければいいのかわからない」——開発リーダーやCTOの方から、こうしたご相談をいただくことが増えています。

Claude Codeのチーム開発とは、CLAUDE.mdでプロジェクトの前提知識を全員に自動適用し、settings.jsonで実行できる操作の範囲をリポジトリ単位で統制する運用設計のことです。個人利用との違いは機能ではなく、「暗黙知をファイルに落とし、権限をコードで管理する」という設計思想にあります。

本記事では、Claude Codeをチーム開発に導入する際のCLAUDE.mdの設計、settings.jsonによる権限管理、Agent Teamsによるマルチエージェント並列開発、コードレビュー自動化まで、開発リーダーやCTOが押さえるべき実践ノウハウを体系的に解説します。組織全体のセキュリティ設計については「Claude Codeの企業導入セキュリティガイド」で、AI活用の全体像は「AI活用完全ガイド」で解説しています。

この記事でわかること

チーム全体でClaude Codeを使いこなすには、機能の使い方よりも先に「何を共有し、何を止めるか」という設計を決める必要があります。ここでは、その設計に必要な要素を順番に整理します。

• CLAUDE.mdによるコンテキストの共有設計 — セッション開始時に自動で読み込まれる指示書に、規約・アーキテクチャ方針・禁止事項を明文化する方法を整理します。
• settings.jsonの3階層と権限ポリシー — ユーザー・プロジェクト・ローカルの評価順序を理解し、denyルールで破壊的操作を止める設計を解説します。
• Agent Teamsによる並列開発の実像 — 実験的機能としての制約も含め、どんなタスクなら分担が効いて、どんなタスクだと逆効果かを示します。
• PRレビュー自動化の組み込み方 — GitHub Actions連携でレビュー観点を標準化し、人間のレビューを設計判断に集中させる流れを紹介します。
• 組織規模に応じた導入ステップ — パイロットから全体展開まで、スモールスタートで広げる段階設計とプラン選定の考え方をまとめます。

チーム全体の開発基盤としてClaude Codeを導入したい開発リーダー・CTO・情報システム部門の方に向けて書いています。最後まで読むと、自社のリポジトリに明日コミットできるCLAUDE.mdとsettings.jsonの骨格を、自分の言葉で設計できるようになります。

チーム開発で最初に起きるのは「品質のばらつき」という課題

Claude Codeの導入は、多くの場合エンジニア個人の自発的な利用から始まります。ところが人数が増えた瞬間に、個人利用では見えなかった問題が一斉に顔を出します。ここを設計せずに広げると、生産性が上がるどころかレビュー負荷が増えるという逆転が起きがちです。まずは、チーム展開で共通して起きる3つの課題を整理します。

• 暗黙知の閉じ込め ── 前提が個人のプロンプトの中に留まる
• 権限の把握不足 ── 誰が何を実行できるのかが見えない
• 導入順序の不在 ── 順番を決めずに全社展開してしまう

暗黙知が個人のプロンプトに閉じ込められている

「このプロジェクトではこのディレクトリ構成を守る」「このライブラリは使わない」「テストはこの命名規則で書く」。こうした前提は、ベテランなら頭に入っていますが、AIエージェントは何も知りません。結果として、各メンバーが毎回自分のプロンプトに前提を書き足すことになります。

これは、スプレッドシートに各担当者が独自のフォーマットで案件を記録している状態とよく似ています。個人の手元では回っていても、チームで集約した途端に整合性が取れなくなる。Excelや個人メモで運用してきた業務をCRMに移す際と同じで、最初にやるべきは「共通の型をどこに置くか」を決めることです。Claude Codeの場合、その置き場所がCLAUDE.mdになります。

誰が何を実行できるのかを把握できていない

もう一つの課題が権限です。AIエージェントはファイルの読み書きだけでなく、シェルコマンドも実行できます。各自のローカル設定に任せていると、git push --force のような破壊的操作をどこまで許しているのかを誰も把握できません。

ここで重要なのは、「気をつけましょう」という注意喚起ではなく、設定ファイルで止めるという発想です。私たちがCRMの運用設計で「入力してね、では入らない。必須項目にして仕組みで担保する」とお伝えしているのと同じ考え方で、人の注意力ではなくリポジトリにコミットされたルールで統制します。

導入の順番を決めずに全社展開してしまう

3つ目は進め方の課題です。いきなり全エンジニアにアカウントを配ると、使い方の質問が特定の人に集中し、CLAUDE.mdもsettings.jsonも整備されないまま各自が独自運用を始めます。

私たちがHubSpotの導入支援でも一貫してお伝えしているのは、効果が出そうなところから優先順位をつけて段階的に広げるという考え方です。Claude Codeも同じで、少人数のパイロットで型を作り、その型をリポジトリに固定してから人数を増やすほうが、結果的に定着が早くなります。

CLAUDE.mdでチームのコンテキストを統一する

チーム開発の出発点は、プロジェクトの前提知識を1つのファイルに集約することです。ここが曖昧なままだと、どれだけ権限管理や自動化を整えても、出力される成果物の品質が安定しません。CLAUDE.mdは、その共通の型を置く場所です。

CLAUDE.mdとは何か

CLAUDE.mdは、Claude Codeがセッション開始時に自動で読み込む指示書ファイルです。プロジェクトのルート直下に .claude/CLAUDE.md として配置することで、チームメンバー全員が同一のコンテキストでClaude Codeを利用できます。

個人利用では暗黙知として各自が持っていた「コーディング規約」「アーキテクチャの前提」「禁止事項」を、CLAUDE.mdに明文化することでチーム全体に自動適用できる点が最大のメリットです。新しく参加したメンバーが初日から同じ前提でエージェントを動かせるため、オンボーディングの負荷も下がります。

なお、既存プロジェクトにCLAUDE.mdを新規作成する場合は、/init コマンドを実行するとClaude Codeがプロジェクトのディレクトリ構造・package.json・README等を自動スキャンし、技術スタック、ビルドコマンド、テストコマンド、ディレクトリ構成を含むCLAUDE.mdのひな形を自動生成してくれます。

ゼロから手書きする必要はありません。最初の一歩としては、この /init を実行してひな形を眺めるところから始めるのが現実的です。

チーム向けCLAUDE.mdの設計パターン

効果的なCLAUDE.mdには以下の要素を含めます。どれも「エージェントが判断に迷うポイント」を先回りして潰すための項目です。

ここで意識したいのが、項目を盛りすぎないことです。CRMのプロパティ設計でも、使われない項目が大量にあるより、実際に参照される項目が絞られているほうが機能します。CLAUDE.mdも同じで、誰も守っていないルールを並べるより、「これだけは外さない」という項目に絞って運用したほうが、更新も継続します。

実世界の事例: ShopifyのオープンソースCLAUDE.md

Shopifyは自社のオープンソースプロジェクトで詳細なCLAUDE.mdを公開しており、チームでのClaude Code活用の先進事例として注目されています。ShopifyのCLAUDE.mdには、モジュール境界の定義、検証コマンドの一覧、PRテンプレート、コントリビューション時の注意事項が明記されており、外部コントリビューターを含む大規模チームでもエージェントが独立してコードベースを探索できるよう設計されています。

ShopifyのCEO Tobi Lutke氏は「AIの活用は全社員の基本スキル」と公言しており、CLAUDE.mdをチームのナレッジハブとして位置づける運用方針は、同社のAIファースト文化を反映したものです。

ただし、公開事例をそのまま真似ても機能しないケースがあります。Shopifyの構成は、外部コントリビューターが多い大規模OSSという前提に最適化されたものです。数名の内製チームであれば、モジュール境界の厳密な定義より、まずビルド・テストコマンドと禁止事項を書くほうが効果が出ます。企業様によって最適な形は異なりますので、事例は構成要素の参照先として使い、自社の開発プロセスに合わせて取捨選択するのがよいでしょう。

CLAUDE.mdの階層構造

CLAUDE.mdは複数階層で管理できます。

• リポジトリルート .claude/CLAUDE.md — プロジェクト全体のルール
• サブディレクトリ src/api/CLAUDE.md — モジュール固有のルール
• ユーザーローカル ~/.claude/CLAUDE.md — 個人の好み（Gitに含めない）

この階層構造により、チーム共通ルールと個人設定を分離しつつ、特定モジュールには追加ルールを適用できます。たとえば、フロントエンドチームは src/frontend/CLAUDE.md にReactのコンポーネント設計規約を、バックエンドチームは src/api/CLAUDE.md にAPIのエラーハンドリング方針を配置するといった運用が可能です。

最初から全階層を埋める必要はありません。まずはリポジトリルートの1枚だけを作り、「このモジュールだけルールが違う」という不満が現場から出てきた時点でサブディレクトリに追加する。この順番のほうが、実態に合った階層構造に育ちます。

settings.jsonによる権限管理を仕組みで担保する

CLAUDE.mdが「何をしてほしいか」を伝えるファイルだとすれば、settings.jsonは「何をさせないか」を決めるファイルです。チーム開発では後者のほうが重要になります。人数が増えるほど、注意喚起は機能しなくなるためです。

権限設定の3階層

Claude Codeの権限設定は、3つのレベルで管理されます。

1. ユーザー設定（~/.claude/settings.json）— 個人のグローバル設定
2. プロジェクト設定（.claude/settings.json）— リポジトリ共有設定
3. ローカルオーバーライド（.claude/settings.local.json）— 個人の上書き設定

評価順序は ローカル > プロジェクト > ユーザー で、deny > ask > allow の順に判定されます。denyルールは常に最優先されるため、危険な操作を止めやすくなります。

この3階層は、CRMの権限設計における「全社共通のルール」「チーム単位の設定」「個人の表示設定」の分け方とよく似ています。全員に守らせたいものはリポジトリ共有の階層に置き、好みの範囲はローカルに逃がす。この線引きを最初に決めておくと、後から設定が増えても混乱しません。

プロジェクト向け推奨設定

チーム開発では、.claude/settings.json に以下のような設定を書いてリポジトリにコミットし、チームで共有するのが基本的な運用です。

{
  "permissions": {
    "allow": ["Read", "Edit", "Write", "Glob", "Grep"],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push --force)",
      "Bash(git reset --hard)"
    ]
  }
}

これにより、ファイルの読み書きは許可しつつ、破壊的なGit操作やファイル削除はチーム全体でブロックできます。ポイントは、このファイルをリポジトリにコミットすることです。設定がコードとして管理されていれば、新メンバーが git clone した瞬間に同じ制約が適用され、誰かが口頭で伝える必要がなくなります。

以下の画面は、本記事で扱う git worktree add による並列実行の準備コマンドと、denyルールでブロック対象とする git push --force / git reset --hard、CLAUDE.mdのひな形を生成する /init を並べたものです。

4つのパーミッションモード

acceptEdits モードは、ファイルの編集操作は自動承認しつつ、シェルコマンド実行時には確認を求めるモードです。コード生成やリファクタリングのような編集中心の作業では操作の中断が減ります。

チーム開発では、NormalモードをデフォルトとしつつCIパイプラインではAuto-acceptを使う構成が一般的です。

ただし、Bypassモードをローカルの通常開発で常用するのは避けたほうが無難です。全操作が自動承認されるため、意図しないコマンドが実行されてもその場で止める手段がなくなります。使う場合は、壊れても復旧できるサンドボックス環境での利用に留めるのが無難な線引きです。

Claude Codeでプロジェクト管理を効率化する方法では、タスク分割やマルチエージェント構成の運用パターンも紹介しています。

Agent Teamsによる並列開発と、その適用範囲

権限と前提知識が整ったら、次は処理の並列化です。ただしここは、期待値を正しく設定しないと投資対効果が読めなくなる領域でもあります。仕組みと制約の両方を押さえた上で判断してください。

サブエージェントの仕組み

Claude Codeでは、メインのエージェントから専門的なタスクをサブエージェントに委任できます。サブエージェントは親と同じCLAUDE.md、MCPサーバー、スキルを読み込むため、プロジェクトのコンテキストを維持したまま並列処理が可能です。

出典: Anthropic公式: Sub-agents

その発展形が「Agent Teams」です。Agent Teamsでは、メインセッション（チームリード）が複数のチームメイトを起動し、共有タスクリストとメールボックスを通じてチームメイト同士が直接メッセージをやり取りしながら並列で作業します。結果をメインエージェントに返すだけのサブエージェントとは、この点が決定的に異なります。

Agent Teamsは実験的機能で、既定では無効です。 利用するにはCLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1を環境変数またはsettings.jsonのenvブロックに設定します。未設定だとチームは一切セットアップされません。

• 以前のバージョンで必要だった「先にチームを作成する」手順（TeamCreate / TeamDeleteツール）は廃止されており、現在の仕様ではチームメイトを1体起動した時点でチームが自動生成され、セッション終了時に自動でクリーンアップされます。
• Agent toolのteam_name入力とフックペイロードのteam_nameフィールドは受理されますが非推奨です。
• 表示モードの既定値もバージョンによって変更されており、明示設定しない限り分割ペインは開かず1つのターミナル内に収まる構成が既定になっている場合があります。

（出典: Agent teams）

実験的機能であるという点は、導入計画を立てるうえで率直に踏まえておく必要があります。仕様が変わる前提で、業務のクリティカルパスに組み込まないという線引きをおすすめします。

実際に試す際の進め方としては、まず環境変数を設定してチームメイトの起動が受理されるかを確認し、動かない場合は環境変数の有効化と利用中のバージョンを見直す、という順で切り分けると原因を絞りやすいです。バージョンごとの既定値やツールの有無は変わり得るため、導入前に最新の公式ドキュメントで仕様を確認しておくと、設定差異によるつまずきを減らせます。

たとえば大規模なリファクタリングを依頼し、観点ごとに分担するようチームメイトを立てると、以下のような役割分担が組めます。

• UX専門エージェント — UIコンポーネントの変更とアクセシビリティの検証を担当
• アーキテクチャ専門エージェント — モジュール間の依存関係と設計の整合性を検証
• セキュリティ専門エージェント — 認証・認可の実装とセキュリティリスクの検出を担当
• テスト専門エージェント — 変更箇所のテストケース生成とカバレッジの確認

どの観点で何人立てるかはプロンプトで指定できますし、Claudeが提案してくることもあります。いずれの場合も起動には人間の承認が必要で、Claudeが勝手にチームメイトを立ち上げることはありません。チーム規模は3〜5体、チームメイト1体あたりタスク5〜6個が公式に推奨されている目安です。この「3〜5体」「5〜6個」という数値は、並列化を検討する際の現実的な上限として覚えておくとよい基準です。

Orchestrator-Workersアーキテクチャ

Agent Teamsの設計思想は、Anthropicが提唱する「Orchestrator-Workers」パターンに基づいています。このパターンでは、中央のオーケストレーター（調整役）がタスクを分解し、複数のワーカーエージェントに並列で委任した後、それぞれの成果を統合します。

出典: Anthropic「Building Effective Agents」

Orchestrator-Workersパターンの流れは以下のとおりです。

1. タスク受領 — オーケストレーターが開発者からの指示を受け取る
2. 分解と委任 — タスクを独立した単位に分解し、各ワーカーに割り当て
3. 並列実行 — 各ワーカーが独立して作業を実行
4. 統合と検証 — オーケストレーターが各ワーカーの成果物を統合し、整合性を検証
5. 結果の返却 — 統合された成果物を開発者に返す

このパターンは、コードベースのモジュール性が高く、各タスクが独立して実行可能な場合に最も効果を発揮します。モノリシックなコードベースでは、ワーカー間のファイル競合が頻発するため、事前にモジュール境界をCLAUDE.mdに明記しておくことが重要です。ここでCLAUDE.mdの設計が効いてくる、というのが一気通貫で見たときの構造です。前工程の整備を飛ばして並列化だけを導入すると、競合の調整に人間の時間が吸われます。

Git Worktreeによる並列実行

CCPM（Claude Code Project Manager）のようなツールを使えば、Git Worktreeを活用して複数のエージェントが同じリポジトリの異なるブランチで同時に作業できます。GitHub Issuesと連携してPRDから実装、PR作成まで自動化する構成も実現可能です。

# メインブランチからWorktreeを作成し、各エージェントが独立作業
git worktree add ../feature-auth feature/auth
git worktree add ../feature-payment feature/payment
git worktree add ../feature-notification feature/notification

各Worktreeで独立してClaude Codeを起動し、実装が完了したらPRを作成してマージする流れです。Worktreeはファイルシステムレベルで分離されるため、ブランチ間のファイル競合を物理的に防止できます。

ただし、マルチエージェント構成ではAPIコストが増大するため、タスクの粒度とエージェント数のバランスを慎重に設計する必要があります。

並列化が向くケース・向かないケース

導入判断を誤らないために、適用範囲を整理しておきます。

仕様が固まっていないフェーズでの並列化は、方向性がずれた成果物が複数同時に出てくるため、手戻りが増えやすくなります。そうした段階ではPlanモードで設計を固めてから、実装フェーズで並列に切り替える。この使い分けが、実務上は扱いやすいです。

コードレビューの自動化で人間の時間を設計判断に回す

並列で実装量が増えると、次に詰まるのがレビューです。ここを人海戦術のままにすると、AI導入の効果がレビュー待ちで相殺されます。機械が判定できる観点を自動化し、人間は設計判断に集中するという役割分担が要になります。

GitHub Actions連携

Anthropicが公式に提供する anthropics/claude-code-action@v1 を使えば、PRが作成されるたびにClaude Codeが自動でコードレビューを実行し、コメントを投稿します。

出典: Anthropic公式: GitHub Actions

name: Claude Code Review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: $
          prompt: |
            このPRの変更点をレビューしてください。
            以下の観点で評価してください：
            1. ロジックの正確性
            2. エラーハンドリングの網羅性
            3. パフォーマンスへの影響
            4. セキュリティリスク
            5. テストの十分性

人間のレビューアがコードを読む前に構文チェック、ロジックの問題、セキュリティリスクを事前に検出することで、レビューの質と速度が同時に向上します。レビュー待ちで着手が止まるという状態も緩和されます。

詳しいCI/CD統合の設計については、Claude Code × CI/CDのパイプライン設計で解説しています。

AIに任せる観点・人間が判断する観点

自動化で失敗しやすいのは、判断の全てをAIに寄せてしまうケースです。役割を分けて考えます。

AIのレビューコメントは、優秀なアシスタントが一次チェックを済ませて持ってきてくれる叩き台と捉えるのが実態に近い位置づけです。マージの最終判断まで自動化してしまうと、問題が起きたときに誰も経緯を説明できなくなります。人間の承認を1箇所は残す設計をおすすめします。

レビューチェックリストのカスタマイズ

CLAUDE.mdにレビュー観点を記載しておけば、Claude Codeは毎回同じ基準でレビューを実施します。コーディング規約の遵守、テストの有無、パフォーマンスへの影響、セキュリティリスクなど、チーム固有の観点を統一できます。

これは「ベテランのレビュー基準を個人の頭の中から取り出して、ファイルに置く」という仕組み化そのものです。特定のレビューアが不在でも同じ観点でチェックが回り、新人が「何を見ればいいのか」を学ぶ教材にもなります。引き継ぎのたびに基準が変わるという属人化の問題を、設定ファイルで解消できます。

さらに、claude-code-action はPRの差分だけでなくリポジトリ全体のコンテキストを読み込むため、変更箇所が他のモジュールに与える影響（たとえば共通コンポーネントの変更が依存先に破壊的影響を与えないか）まで検出できる点が、単純なリンターやコード分析ツールとの大きな違いです。

Team/Enterpriseプランの選定と全社ポリシー

運用の型が固まったら、契約形態とポリシー配布の設計に進みます。ここは技術というより、情報システム部門と合意を取る領域です。

プラン比較

AnthropicはClaude Code対応のTeam/Enterpriseプランを提供しています。

5名以下の小規模チームならTeamプラン、SSO・監査ログ・ポリシーの組織展開が必要な場合はEnterpriseプランを選択するのが一般的です。判断軸は機能の多さではなく、「IT部門が設定の上書きを禁止する必要があるか」という点が分かれ目になりやすいです。

managed-settings.jsonによる全社ポリシー

Enterpriseプランでは、IT部門が managed-settings.json で全社統一のポリシーを強制適用できます。個々の開発者がローカルで設定を変更しても、managed-settingsの内容はオーバーライドできないため、セキュリティポリシーの徹底が可能です。

ただし、最初から全社ポリシーをガチガチに固めると、現場が必要な操作まで止まって運用が回らなくなります。パイロットチームで実際にブロックすべき操作を洗い出してから、managed-settingsに昇格させる。この順番のほうが、現実に即したポリシーになります。組織レベルのセキュリティ対策については、Claude Codeの企業導入セキュリティガイドも合わせてご覧ください。

スモールスタートで広げる導入ステップ

最後に、ここまでの要素をどの順番で組み立てるかを整理します。全部を一気に進めるのは難しいので、効果が出やすい順に優先順位をつけて進めるのがおすすめです。

段階的な導入プロセス

チーム全体への展開は、以下のステップで進めるのが効果的です。

期間はあくまで目安です。既存のCI/CDが整っているチームならCI/CD統合を先に進めても構いませんし、リポジトリが複数ある場合は1リポジトリで型を作ってから横展開するほうが早いこともあります。企業様によって最適な進め方は異なりますので、自社で効果が出そうなところを見極めて順番を組み替えていただければと思います。

運用を継続させるための仕組み

Claude Codeの導入で最も重要なのは、CLAUDE.mdの継続的なメンテナンスです。プロジェクトの進化に合わせてCLAUDE.mdを更新し続けないと、エージェントの出力品質が徐々に低下します。

ここでも、担当者の善意に頼るのではなく仕組みで解決します。具体的には、次の3つをチームのルールとして設定ファイルと同じ場所に書いておくのが有効です。

• CLAUDE.mdの更新をPRレビューの対象に含める — 規約が変わったPRでCLAUDE.mdが更新されていなければ指摘対象とする
• denyルールの追加提案を誰でも出せるようにする — ヒヤリとした操作があったらその場でPRを立てる運用にする
• 四半期などの定期タイミングで棚卸しする — 使われていない記述を削り、項目を最小限に保つ

また、Claude Codeの基本的な使い方をチームメンバー全員が理解していることが前提になるため、導入前の教育セッションも欠かせません。

開発以外の業務への横展開

CLAUDE.mdと権限管理の考え方は、コードを書く場面に限った話ではありません。設定ファイルで前提とルールを共有し、AIに任せる範囲と人間が判断する範囲を分けるという構造は、レポート作成やデータ整備といった業務にもそのまま応用できます。経営データの可視化やコンテンツマーケティングを含め、Claude Codeの業務活用に関心のある方はぜひ参考にしてください。

エンジニア組織の話として閉じず、業務全体の仕組み化として捉えていただくと、投資対効果が見えやすくなります。

よくある質問

ここでは、チーム導入でよく聞かれる質問に答えます。

• 設定ファイルの共有 ── CLAUDE.mdとsettings.jsonの扱い
• コストとプラン ── マルチエージェントのAPIコスト、TeamとMaxの違い
• 既存ツールとの併用 ── ESLint/Prettierとの分担
• Agent Teamsと小規模チーム ── 手動指定の可否、必要な設計の範囲

Q1. CLAUDE.mdはGitリポジトリにコミットすべきですか？

はい、.claude/CLAUDE.md と .claude/settings.json はリポジトリにコミットしてチーム全員で共有するのが推奨です。個人的な設定は .claude/settings.local.json や ~/.claude/ に配置し、.gitignore で除外します。なお、/init コマンドで生成したCLAUDE.mdは、チームの運用に合わせてカスタマイズしてからコミットしてください。

Q2. マルチエージェント構成のAPIコストはどう考えればよいですか？

エージェント数に比例してAPIコストが増加します。タスクの粒度が大きい場合（モジュール単位のリファクタリングなど）はコスト効率が良く、細かいタスクの並列化はオーバーヘッドが大きくなる傾向があります。公式に推奨されているチーム規模は3〜5体、チームメイト1体あたりタスク5〜6個ですので、この範囲を上限の目安として設計するとブレにくくなります。

Q3. Claude CodeのTeamプランとMax（個人向け）プランの違いは何ですか？

Maxプランは個人開発者向けで、Teamプランはチーム管理機能（シート管理、利用分析、支出制御）が追加されます。Teamプランでは管理者がメンバーの利用状況を把握し、組織・ユーザー単位で支出上限を設定できます。複数名で継続的に利用し、利用状況の可視化や支出の統制が必要になった段階がTeamプランへの切り替えどきです。

Q4. 既存のESLint/Prettierとの併用は可能ですか？

はい、CLAUDE.mdにフォーマッタやリンターの設定を記載しておけば、Claude Codeはそれらのルールに従ってコードを生成します。CI/CDパイプラインでESLint/Prettierのチェックを走らせれば、Claude Codeが生成したコードも同じ基準で検証されます。機械的に判定できる観点は既存ツールに任せ、AIには設計意図や影響範囲の指摘を担わせる分担が現実的です。

Q5. Agent Teamsのサブエージェントは手動で指定できますか？

はい、指定できます。プロンプトで「フロントエンドとバックエンドを別々のチームメイトで実装してください」のように人数と役割を明示すれば、その通りに起動されます。

既存のサブエージェント定義（.claude/agents/*.md）を役割として指定することも可能で、その定義のtools許可リストとmodelが引き継がれます。

CLAUDE.mdにモジュール境界を明記しておけば、分担がより適切になります。なお、Agent Teamsの利用にはCLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1の設定が必要です。

Q6. 小規模チームでもここまでの設計は必要ですか？

最初から全部を揃えようとすると整備で止まってしまうので、/init の実行から始めるのがおすすめです。CLAUDE.mdとdenyルールの最小構成だけ整えて、必要になった項目から後付けで増やしていく進め方が、小規模チームには合っています。

まとめ

Claude Codeのチーム開発は、ツールを配ることではなく、前提知識と権限をファイルとして共有資産に変える設計作業です。本記事の要点を整理します。

• CLAUDE.mdが共通の型の置き場所 — 規約・アーキテクチャ方針・禁止事項を明文化し、全員が同一コンテキストで作業できる状態を作ります。項目は盛りすぎず、実際に参照されるものに絞るのがコツです
• settings.jsonの3階層で権限を仕組み化 — ローカル > プロジェクト > ユーザー、deny > ask > allow の評価順序を押さえ、破壊的操作はリポジトリにコミットした設定でブロックします
• 並列化は適用範囲を見極めてから — Agent Teamsは実験的機能であり、モジュール境界が曖昧なコードベースでは競合の調整コストが上回ります。公式目安の3〜5体を上限として設計します
• レビュー自動化はAIと人間の分担設計とセット — 規約逸脱や影響範囲の検出はAIに、アーキテクチャの妥当性とマージ可否は人間に残します
• 導入はスモールスタートで — パイロットで型を作り、リポジトリに固定してから人数を増やす順番が、結果的に定着を早めます

最初の一歩は、既存リポジトリで /init を実行し、生成されたCLAUDE.mdを眺めることです。そこから次の3ステップで進めてください。

1. 生成されたCLAUDE.mdに、禁止事項とテスト方針を3〜5行だけ追記してコミットする
2. .claude/settings.json にdenyルールを書き、破壊的Git操作をチーム全体でブロックする
3. 1〜2週間運用し、実際に困った点をCLAUDE.mdに追記してから人数を増やす

このテーマの全記事はClaude Code実践ガイドでご覧いただけます。

CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお気軽にお問い合わせください。

あわせて読みたい

• Claude Codeでプロジェクト管理を効率化する方法｜CLAUDE.md・タスク分割・進捗管理の実践
• Claude Codeの企業導入セキュリティガイド
• Claude Code × CI/CD｜コードレビュー・テスト・デプロイを自動化するパイプライン設計
• Claude Coworkとは？AIが仕事を実行する新しい働き方の全体像
• AI駆動開発とは？従来開発との違い・メリット・導入ステップを実践者が解説