チーム展開とGit/PRワークフロー

Agent Teamsで並列開発

Claude CodeにはAgent Teamsという実験的機能があります。 複数のAIエージェントが同一コードベース上で協調して作業する仕組みで、 大規模な開発タスクを並列に処理できます。

セットアップ手順

Agent Teamsを使うには、iTerm2とtmuxが必要です。 セットアップ手順は以下の通りです。

# 1. 前提ツールのインストール
brew install --cask iterm2
brew install tmux

# 2. iTerm2を起動し、tmuxセッションを開始
tmux new -s dev

# 3. Agent Teamsを有効化してClaude Codeを起動
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 claude

teammateMode設定

Agent Teamsの表示モードはteammateMode設定で制御できます。

• auto — 環境に応じて自動選択（デフォルト）
• in-process — 同一プロセス内で実行。画面共有なし
• tmux — tmuxウィンドウで各エージェントを表示。作業状況を視覚的に確認可能

協調の仕組み

各エージェントはそれぞれ独立した完全なコンテキストウィンドウを持ちます。 Subagents（親セッション内の分離コンテキスト）とは異なり、 CLAUDE.md、MCPサーバー、Skillsがそれぞれ自動的に読み込まれます。 エージェント間の協調は共有タスクリストを通じて行われます。

# チームの起動例（プロンプトでロールを指定）
# tmuxウィンドウ1: Command設計担当
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 claude
"あなたはCommand設計担当です。.claude/commands/にワークフローを作成してください"

# tmuxウィンドウ2: Agent設計担当
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 claude
"あなたはAgent設計担当です。.claude/agents/にカスタムエージェントを作成してください"

# tmuxウィンドウ3: Skill設計担当
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 claude
"あなたはSkill設計担当です。.claude/skills/にSkillを作成してください"

Git Worktreesで分離作業

Agent Teamsをさらに安全に運用するために、Git Worktreesを活用します。 各エージェントが独立したgitブランチで作業することで、コードの競合を防ぎます。

Boris Cherny氏は、Git Worktreesの5つの活用法を提唱しています。

• 機能開発の並列化 — 複数の機能を同時に別ブランチで開発
• レビューとコーディングの同時実行 — レビュー用worktreeとコーディング用worktreeを分離
• 実験的変更の隔離 — 本番コードに影響を与えずに実験
• テストの並行実行 — テスト用worktreeで本番開発を止めずにテスト
• リファクタリングの安全な実施 — リファクタリングが失敗してもメインブランチに影響なし

# worktreeを作成して分離作業
git worktree add ../feature-auth feature/auth
git worktree add ../feature-api feature/api

# 各worktreeでClaude Codeを起動
cd ../feature-auth && claude
cd ../feature-api && claude

# Claude Code起動時に--worktreeフラグを使う方法もある
claude --worktree

PRは小さくsquash merge

Claude Codeで開発する場合、PRは小さく、squash mergeでマージするのが鉄則です。 Boris Cherny氏の実績データが説得力を持っています。

小さなPRとsquash mergeの組み合わせは、git revertやgit bisectを容易にします。 AIが生成したコードに問題があった場合、該当PRを丸ごとrevertすれば確実に元に戻せます。 大きなPRでは「どの変更が原因か」の特定に時間がかかりますが、 118行程度のPRなら原因箇所は一目瞭然です。

# squash mergeでクリーンな履歴を維持
git merge --squash feature/auth
git commit -m "feat: 認証機能を追加"

# 問題があればワンコマンドでrevert
git revert HEAD

# bisectで問題コミットを特定（線形履歴なので高速）
git bisect start
git bisect bad HEAD
git bisect good v1.0

/code-reviewでマルチエージェントPR分析

Claude Codeの/code-review機能は、PRの品質を自動的に分析します。 バグ、セキュリティ脆弱性、リグレッションを検出し、レビュアーの負担を大幅に軽減します。

Boris氏が推奨するさらに進んだ活用法として、@claudeタグでPRレビューのフィードバックを自動的にlintルールに変換する方法があります。 レビューで指摘された問題を一度きりの修正で終わらせるのではなく、再発防止のためのルールとして定着させます。

# PRの自動レビューを実行
/code-review

# GitHub PRで@claudeタグを使ったレビュー
# PRコメントに @claude と書くとレビューが実行される
# 指摘事項を .claude/rules/ にlintルールとして自動追加

Cross-Modelワークフロー

私が実際に効果を実感しているのが、異なるAIモデルを組み合わせたレビュー体制です。 Claude Codeで実装した後、Codexや別のClaudeインスタンスでレビュー・QAを行います。

Boris氏はこう表現しています。「spin up a second Claude to review your plan as a staff engineer」 ――2つ目のClaudeをスタッフエンジニアとして起動し、計画をレビューさせるという考え方です。 同じモデルでも異なるセッションでレビューすることで、実装時のバイアスに引きずられない客観的なフィードバックが得られます。

# セッション1: 実装
claude
「認証システムを実装して」

# セッション2: レビュー（別ターミナルで）
claude
「src/auth/ の実装をスタッフエンジニアの視点でレビューして。
セキュリティ、エッジケース、保守性の観点で問題を指摘して」

# さらにCodexでも確認
# 異なるモデルの視点で品質を多角的に検証

チーム展開の段階的アプローチ

組織全体にClaude Codeを展開する場合、一気に全社導入するのではなく段階的に進めるべきです。 私が推奨する4段階のアプローチを紹介します。

• ステップ1: パイロット5名 — 技術的に適応力のあるメンバー5名でパイロット開始。 2〜4週間で効果測定と課題の洗い出しを行う
• ステップ2: 内部トレーナー育成 — パイロットメンバーが内部トレーナーとなり、 次のグループに知見を伝達。実体験に基づく指導が最も効果的
• ステップ3: 全社展開 — トレーナーが各チームをサポートしながら段階的に展開。 チームごとの業務特性に合わせたCLAUDE.mdを整備
• ステップ4: 運用ガイドライン整備 — 全社共通の運用ルールを策定。 CLAUDE.mdはGit管理し、変更時はPRレビューを必須とする

Ralph Wiggum Loop

Ralph Wiggum Loopは、Claude Codeを長時間にわたって自律的に開発ループさせるテクニックです。 完了条件を満たすまで反復的にタスクを実行し続けるプラグインとして実装されています。

長期タスクの自動化に威力を発揮しますが、使いどころを見極めることが重要です。 明確な完了条件が定義できるタスク（テストがすべてパスする、lintエラーがゼロになる等）に限定し、 曖昧な判断が必要なタスクには使わないようにしています。

# Ralph Wiggum Loop の概念
# 「テストがすべてパスするまで修正を繰り返す」
# 「lintエラーがゼロになるまでリファクタリングを繰り返す」

# 公式のloopスキルを使う例
/loop 5m "npm test を実行し、失敗したテストを修正して"

# 完了条件を明確に定義することが成功の鍵
# 良い例: テスト全パス、lint全クリア、型エラーゼロ
# 悪い例: 「コードをきれいにして」「パフォーマンスを改善して」

/batchで大規模並列処理

/batchは、大量のファイルやタスクを並列に処理するためのビルトインSkillです。 インタビュー形式でタスクの内容を確認した後、 数十〜数百のWorktreeエージェントを自動でスポーンして一斉に処理します。

典型的な活用場面:

• 大規模コードマイグレーション — APIの変更に伴う数百ファイルの修正
• 一括リネーム・リファクタリング — 命名規則の変更を全ファイルに適用
• テストの一括生成 — 既存コードに対するテストファイルの並列生成
• ドキュメントの一括更新 — READMEやJSDocの一斉更新

# /batchの実行例
/batch
# → Claudeが対話形式で処理内容を確認
# → "どのファイルを対象にしますか？"
# → "各ファイルに対してどんな処理をしますか？"
# → 確認後、Worktreeエージェントが並列で処理開始

Borisの運用Tips

Claude Code開発チームのBoris Chernyが日常的に使っている、 生産性を上げるためのTipsを紹介します。

/btwでサイド質問

/btwコマンドを使うと、進行中のタスクを中断せずにサイド質問ができます。 Claudeが長い処理を実行している最中に「ちょっと確認したいことがある」という場面で便利です。

# エージェントが作業中に...
/btw このプロジェクトのテストフレームワークは何？

/branchでセッション分岐

/branchで現在のセッションを分岐できます。 「この方向で試してみたいけど、失敗したら元に戻りたい」という場面で使います。

# 現在のセッションを分岐
/branch experimental-approach

# 元のセッションに戻る
claude -r <元のセッションID>

--add-dirで複数リポジトリ作業

--add-dirフラグで別のリポジトリを追加すると、 複数リポジトリにまたがる作業が1つのセッションで完結します。 settings.jsonのadditionalDirectoriesで恒久的に設定することもできます。

# フロントエンドとAPIの両方にアクセス
claude --add-dir ../api-server

# settings.jsonで恒久設定
{
  "additionalDirectories": ["../api-server", "../shared-lib"]
}

まとめ

Claude Codeをチームで展開する際は、Git WorktreesとAgent Teamsで並列開発の基盤を整え、 小さなPRとsquash mergeでクリーンな履歴を維持してください。 /batchで大規模処理を並列化し、/btwや/branchでセッション管理を効率化する。 Cross-Modelワークフローで品質を多角的に検証し、段階的な展開アプローチで組織全体に浸透させていく。 これらを組み合わせることで、AIを活用した開発チームの生産性を最大限に引き出せます。