10-2 Claude Code のチーム協業｜CLAUDE.md 共有とレビュー

このレッスンで身につくこと

レッスン 10-1 では、組織導入の 戦略・フェーズ設計・経営層説明 という マクロ の話をしました。10-3 では、.claudeignore や permissions の 実装の詳細 を扱います。このレッスンはその間、現場でチームが日々 Claude Code をどう回すか の話です。

Claude Cowork は本ガイドの造語で、「2 人以上の人間が、1 つ以上の Claude Code を共に使う運用パターン」 を指します。並行実行という機能的な意味だけでなく、チームで Claude を回すときの文化と仕組み を含めた概念です。

所要時間 — 約 45 分　難易度 — ★★★☆☆　想定読者 — テックリード / EM / 推進担当 / チャンピオン

はじめに — 1 人で速いのと、チームで速いのは別物

Claude Code は 1 人で使うと、誰でもすぐに 2〜3 倍速くなる ツールです。でも チームで速くなる は別の設計問題。5 人のチームに配って 1 ヶ月経つと、よくこういう状態になります。

• A さんは習熟、PR 量は 3 倍、品質も高い
• B さんは「自分で書いた方が早い」と触らない
• C さんは使うが、レビューで毎回大量の指摘
• D さんは丸投げで、コードを読んでいない
• E さんは CLAUDE.md を知らず毎回ゼロから指示

平均値は上がったように見えるが、分散が爆発 しています。レビュー負荷は A さんに集中し、D さんのコードがトラブルを生み、E さんは半年経っても初心者のまま。Claude Cowork とは、この分散を抑え、チーム全体の中央値を底上げする運用 のことです。

チーム協業の 4 つのモード

自分のチームが今どのモードか を最初に認識すると、設計がラクになります。

モード A 個別運用（バラ運用）。各メンバーが手元で勝手に使う。CLAUDE.md は各自のリポジトリ依存、テンプレ共有なし。Phase 1 のパイロット期までは正解、それ以降は 確実に失敗パターン。

モード B 並行運用。1 人が複数ターミナルで複数 Claude を同時に走らせる。1 つでテストを書かせ、別でドキュメント、3 つ目で設計レビュー。本質は 「Claude を待つ時間を減らす」 こと。1 タスク 3 分の応答待ちを 3 並列にすれば、人間の待機が 9 分 → 3 分に。1 日 30 局面なら 3 時間 / 日 の節約。

# ターミナル 1 — 機能実装
claude
> users API の POST /signup を実装して

# ターミナル 2 — テスト追加
claude
> internal/handlers/auth_test.go にテストを追加

# ターミナル 3 — ドキュメント更新
claude
> openapi.yaml に新しいエンドポイントを追加

同じファイルを同時に編集しない が鉄則。git の競合と同じ問題が Claude のセッション間でも起こります。

モード C ペアプロ運用。2 人で 1 つの Claude を見ながら共同作業。Driver / Reviewer / Claude の 3 役 で回す形。学習効果が最強 — 2 人がリアルタイムで批評するので、片方が見落とす危険な変更をもう 1 人が止めます。

モード D チーム運用（Cowork 本番）。チーム全体が共通ルール・テンプレ・ナレッジで動く。新人がチームに加わっても オンボーディング 1 週間でフル稼働 できます。10-1 で語った Phase 3 が成功した組織は、ほぼこのモード D です。

CLAUDE.md の 4 階層設計

10-1 では 3 階層に触れましたが、実装目線で 4 階層に細分化 します。

階層 1 組織共通 CLAUDE.md。全社員が必ず読む最上位ルール。コミット規約、セキュリティ、命名規則、禁止事項を 15〜30 行 にまとめ、情シス / アーキテクト部門が単一ソース で管理、リポジトリへの配布は git submodule / コピーで実施。

# 組織共通 CLAUDE.md

## コミット
- Conventional Commits 形式
- Co-Authored-By は付けない

## セキュリティ
- .env / credentials.json / *.pem は読まない
- 顧客 PII を含むコードは事前マスキング

## 言語
- コード内コメント・変数名は英語
- ユーザー向け文言は日本語

## コスト
- 200k トークンを超えたら /compact
- Cowork の並行数は 3 まで

階層 2 プロダクト固有 CLAUDE.md。プロダクトごとのアーキテクチャ・ドメイン用語・主要パスを書く。Claude が「このプロダクトはこういう構造です」と最初に把握する地図。プロダクト責任者が 1 週間以内に更新 する責任。

階層 3 チーム / 機能 CLAUDE.md。特定機能の作法を書く。「請求書生成は税率 0% を許容するため parseInt(x) || N を使わない」など、過去のバグから生まれた局所知識を蓄積する場所。過去のトラブルが、新人を救う未来の知恵 になります。

階層 4 個人 CLAUDE.md（~/.claude/CLAUDE.md）。個人のクセ・好み・働き方。組織で強制せず、あくまで好み。ただ チャンピオンが自分の個人 CLAUDE.md を社内で公開する と、「上手な人の Tips 集」として若手に広まります。

プロンプト規約とテンプレ共有

CLAUDE.md と並ぶもう 1 つの組織資産が、頻繁に使うプロンプトのテンプレ。実務的な置き場所は次の通り。Notion — 非エンジニアも見るならここ。社内 Wiki — Confluence / esa.io 等。GitHub repo — prompts/ ディレクトリで git 管理、PR レビュー可能。Slack canvas — 軽量だが検索性が弱い。チームのスキル分布で選びます。

1 テンプレは次の 5 要素を持ちます。①いつ使うか / ②前提 / ③プロンプト本体 / ④期待される出力 / ⑤よくある失敗。Notion のデータベース機能で タグ / 言語 / 担当 / 頻度 を付けて検索しやすくします。

テンプレ運用の 3 ルール。①使ったテンプレに「使用回数」を毎回 +1、月次で並べ替えて未使用は廃止候補。②テンプレ追加は PR ではなく "自由投稿、削除のときだけレビュー" にすると新陳代謝が回る。③月 1 回のテンプレ会 で良いテンプレを表彰、悪い結果を生むものを廃止。

ペアプロ運用 — 2 人で Claude 1 つ

モード C のペアプロは、学習効果が最も高い 形態。Claude が入ると 3 役になります。Driver — キーボードを握り、プロンプトを書く。Reviewer — Claude の出力を 隣で批評・指摘。Claude — 実装・調査・テストを担う第 3 のメンバー。役割を分けると 承認の判断ミス が大幅に減ります。

ペアプロが効くシーン。①新人のオンボーディング — ベテランが「ここはなぜこう書くか」を解説しながら見せる。②難しい意思決定 — アーキテクチャ判断、データモデル設計など、後で取り返しがつかないもの。③本番に近いリスクある変更 — マイグレーション、認証、課金処理。④チャンピオンの暗黙知の継承 — 上手な人のプロンプト技を 1 時間隣で見るだけで桁違いに学べる。

[悪いペアプロ]
Driver  「テスト書いて」
Claude  「書きました。承認しますか？」
Driver  「y」
Reviewer 「（沈黙）」

[良いペアプロ]
Driver  「テスト書いて」
Claude  「書きました。承認しますか？」
Reviewer 「待って、このアサーション、null チェック入ってる？」
Driver  「あ、入ってない。追加で」
Claude  「null ケースを追加しました」
Reviewer 「これでよし、承認」

レビュー文化 — Claude 出力の人間チェック必須化

Claude を使うと PR の量は 2〜3 倍 に増えます。問題はレビュアーの数が増えないこと。安易に「Claude が出したコードはレビュー軽くしよう」とすると、半年後に必ず大きな事故 が起きます。

Claude が書いたコードは、人間が書いたコードと同じ厳しさでレビュー。むしろ 見た目が綺麗で動きそうに見える ぶん、油断しやすいので、より厳しく見るくらいでちょうど良い。

レビューの 3 観点。①ロジック妥当性 — Claude は「動くテスト」が上手すぎて、本来テストすべき境界が漏れがち。②セキュリティ — SQL インジェクション、認証バイパス、レースコンディションを時々見落とす。③可読性とプロジェクト適合 — CLAUDE.md に書いてあることが守られているか。

PR テンプレに 「Claude 利用」欄 を入れて、レビュアーが事前に身構えられるようにします。

## Claude Code の関与
- [ ] Claude が書いたコードを含む
- [ ] 該当箇所: <ファイル / 関数名>
- [ ] 人間が ==読んで理解した== 上で提出
- [ ] テストは自分で確認した

「人間が読んで理解した」をチェックできない PR は マージ禁止 にすると、コピペ提出が一気に減ります。自動レビュー Bot を CI に組み込むのも有効ですが、Bot の判断を最終承認にしない。Bot は人間の補助輪であり、置き換えではありません。

知識蓄積 — Slack / Discord での失敗共有

組織のナレッジは 成功事例 と 失敗事例 の 2 つを集めます。日常的な形は ==#claude-tips チャンネル==。1 日 1 投稿目標で、フォーマットは緩く 2 種類。

[Tips 投稿]
🎯 やったこと: <要約>
🪄 効いたプロンプト: <プロンプト抜粋>
💡 ポイント: <なぜ効いたか>

[失敗投稿]
🚨 何が起きたか: <事象>
💥 原因: <なぜそうなったか>
🩹 対処: <どう直したか>
🔮 防止策: <次回どうするか>

失敗投稿の方が、長期的には資産価値が高い。同じ失敗を別の人が踏まないだけで、月数十時間の節約に。👍 / 🙏 / 📌 のリアクション文化を作り、📌 が 5 個以上 ついた投稿を月 1 回 Wiki に昇格。Slack は流れていく、Wiki は積み重なる の二段構え。

月 1 回 30 分の ヤラカシ報告会。「今月一番派手にやらかした人」が発表します。①何をしようとしたか / ②何が起きたか / ③なぜそうなったか / ④どう直したか / ⑤組織として何を変えるか。最後の 1 行が 学習を行動に変える ポイント。

失敗パターン — Cowork の 3 大事故

組織でチームに Claude を配って 6 ヶ月、10 社のうち 9 社が次の 3 つにハマります。

チーム導入チェックリスト

Cowork を実装する側のチームリードが、自分のチームの現状を点検するためのリスト。半数以下なら危険ゾーン、8 割以上なら成熟チーム。

4 項目以下 なら、モード A 卒業が課題。5〜9 ならモード B/C を強化。10〜13 ならモード D に向けて文化を磨く段階。14 以上 なら他チームへナレッジを輸出するフェーズ。

まとめ

このレッスンで押さえた Claude Cowork の要点を 7 つ。

1. チームの中央値を上げる — 天才を 10 倍ではなく、全員を 1.5 倍にする
2. 4 つの協業モード — A 個別 / B 並行 / C ペアプロ / D チーム、段階的に進む
3. CLAUDE.md は 4 階層 — 組織共通 / プロダクト / チーム / 個人、単一ソースで管理
4. プロンプトテンプレを Wiki に集約 — 投稿のハードルを下げ、悪いテンプレを淘汰
5. ペアプロは 3 役 — Driver / Reviewer / Claude、学習効果が最強
6. Claude の出力こそ厳しくレビュー — 動く ≠ 正しい
7. 失敗共有は最大のナレッジ資産 — #claude-tips + 月次ヤラカシ報告会

Cowork は機能ではなく文化。設定 1 行で導入できる類のものではなく、半年 1 年かけて組織に染み込ませる種類のもの。焦らず、しかし手を抜かず、毎週 1 つずつ仕組みを足していきます。

<Quiz question="Claude Cowork で最も避けるべき失敗パターンはどれですか？" options={["個人ごとに CLAUDE.md / プロンプト / レビュー基準がバラバラで、組織のナレッジが蓄積しない状態","全員が同じ CLAUDE.md を使っており、個人の工夫が反映されにくい状態","1 人で複数の Claude を並行して動かしている状態"]} answer={0} />

<Quiz question="Claude が書いたコードのレビューで最も重要な観点はどれですか？" options={["テストが通っていれば中身は読まなくてよい","Claude が書いたコードこそ人間が 1 行ずつ目を通し、ロジック / セキュリティ / プロジェクト適合を確認する","Claude のコードは自動マージしてよい"]} answer={1} />

次のレッスン 10-3: セキュリティ では、本レッスンで触れたチーム運用の 下を支える技術設計（.claudeignore / permissions / 監査ログ / Bedrock / Vertex）に踏み込みます。Cowork の文化と、セキュリティの仕組み、両輪が揃って初めて Claude Code が組織のインフラとして機能します。