Worktrees で並列開発

Claude Code に 複数のタスクを同時に走らせる、または リスキーな作業を隔離する 場面で git worktree が劇的に効きます。

従来のフロー (worktree なし)

[main 作業ツリー]
  ├ feat/oauth ブランチで作業中
  ├ urgent: 緊急バグ修正したい
  ↓
  git stash             # 退避
  git checkout main
  git checkout -b hotfix/xxx
  # 修正...
  git checkout feat/oauth
  git stash pop         # 戻す  ← 競合の可能性

→ 切替えごとに stash / checkout / 競合解決 が発生。Claude Code を 2 つ立ち上げて並行作業も難しい。

worktree を使うと

my-app/                # メイン (feat/oauth ブランチ)
  └ claude (作業中)

my-app-hotfix/         # 別ディレクトリ (hotfix/xxx ブランチ)
  └ claude (緊急対応)

→ 2 つの別ディレクトリで別ブランチを同時にチェックアウト。stash 不要、お互い独立。 両方で同時に Claude Code を立てて並行作業できる。

worktree を追加

PII マスキング     → Code (機密)
スクレイピング     → クラウド版 Claude Code (重い)
本番 DB 操作       → Code (機密)
スプレッドシート整形 → クラウド版 Claude Code (重い)

→ ../my-app-hotfix/ に新しい作業ツリーが作成され、hotfix/issue-42 ブランチがチェックアウトされる。 .git は元のリポジトリと共有 (容量を食わない)。

既存ブランチをチェックアウト

インクリメンタル開発 → Code (対話的)
夜間バッチ           → クラウド版 Claude Code (任せきり)

レビュー用に PR ブランチを別ディレクトリに展開。

一覧を見る

クラウド版 Claude Code の VM はタスク終了で消える
   ↓
成果物は必ず Drive / GitHub / Notion / Slack に
   ↓
Code から再アクセスして続きの処理

削除

wzxhzdk:3

Claude Code の Agent ツール には isolation: "worktree" オプションがあります。

何が起きるか

ユーザー: 「リスキーな大規模リファクタを試して」
   ↓
Claude (メイン) → Agent サブを isolation: worktree で起動
   ↓
[サブエージェント]
   git worktree add /tmp/cc-experiment-xxx -b cc-experiment-xxx
   cd /tmp/cc-experiment-xxx
   # ...作業...
   ↓
変更があれば: ブランチとパスを返す (人がレビュー → merge or 破棄)
変更がなければ: worktree を自動削除

→ リスキーな実験をメインの作業ツリーから完全に隔離。最悪サブが暴走しても、メインの作業は無傷。

使い分け

ユーザー: 「キャッシュ層を Redis / Memcached / in-memory の 3 案で試して、
            それぞれ性能を計測したい」
   ↓
Claude (メイン) → 3 つの subagent を並列起動 (各 isolation: worktree)
   ├─ subagent A: ../experiment-redis     (cache/redis 実装)
   ├─ subagent B: ../experiment-memcached (cache/memcached 実装)
   └─ subagent C: ../experiment-inmemory  (cache/inmem 実装)
   ↓ 各々が pytest --benchmark を実行
   ↓
3 つの結果を集約 → ユーザーに比較表で提示

これは Claude Code を 真の並列開発機械 に変える使い方。

[main worktree]: 認証バグの根本修正 (Claude Code セッション 1)
[../docs worktree]: 関連ドキュメント更新 (Claude Code セッション 2)
[../tests worktree]: テストカバレッジ拡充 (Claude Code セッション 3)

→ 3 つの Claude Code を別 IDE タブで同時に動かせる。お互いの状態を意識せず作業可能。

Anthropic の中心テーマは AI Safety。 モデルが強力になるほど、誤用・予期せぬ振る舞い・社会的影響のリスクは増します。 それを技術と運用の両面から減らす活動を AI Safety と呼びます。

Constitutional AI (CAI)

LLM を訓練する際、人間からのフィードバック (RLHF) だけでなく、 「原則 (constitution) に従って AI 自身が自分の出力を批評・修正する」 プロセスを追加した手法。

1. AI が回答を生成する。
2. AI が原則 (例: 「有害な指示は避ける」「誠実に答える」) に照らして自己批評する。
3. AI が修正された回答を出力する。
4. このペアを使ってモデルを再訓練する。

これにより、人間アノテーターの工数を抑えながら 一貫した安全性 を獲得できます。

Refusals (拒否)

Claude には 「やってよいこと/やってはいけないこと」 の判断ロジックが組み込まれています。 たとえば爆発物の製造方法や、本人の同意のない監視ツールの作成は拒否します。 ただし、過剰な拒否 (over-refusal) を避ける研究も継続的に行われています。 誠実でない拒否や安全と無関係な過保護も望ましくありません。

Responsible Scaling Policy (RSP)

Anthropic は Responsible Scaling Policy という社内ガイドラインを公開し、 モデルの能力レベル (ASL = AI Safety Level) に応じて、 取り扱い・公開・運用基準を段階的に厳しくしています。

• ASL-2: 現在の Claude が該当
• ASL-3 以上: 大規模な社会的危害を及ぼし得るレベル — 公開前に追加の評価と緩和策を要求

開発者として知っておくべきこと

• System Prompt (システムプロンプト) で振る舞いをある程度制御できるが、安全性ガードレールを完全に外すことはできない。
• Jailbreak (ジェイルブレイク) 試行はサービス利用規約違反になりうる。
• 自分のアプリで 入力検査・出力検査 を行うことが推奨される。
• AUP (Acceptable Use Policy) に違反する用途は API 利用が停止される。

安全な振る舞いの観察

実際に Claude が拒否する例を見てみましょう (拒否の理由付け方が CAI らしいか観察)。

@@TRY_0@@

💡 worktree は git の隠れた最強機能。Claude Code 時代において再評価されています。

あなたのプロジェクトで、同じ問題を 3 つの異なるアプローチ で実装し比較してください。

例: 「JSON ファイルのパース」を以下 3 案で: 1. worktree-stdlib: 標準 json モジュールのみ 2. worktree-pydantic: pydantic でバリデーション 3. worktree-orjson: orjson で高速化

手順:

git worktree add ../experiment-stdlib -b experiment-stdlib
git worktree add ../experiment-pydantic -b experiment-pydantic
git worktree add ../experiment-orjson -b experiment-orjson

各 worktree で Claude Code を立ち上げて実装 → ベンチマーク → 結果を比較。

Claude Code に大規模リファクタを依頼するとき、サブエージェントを isolation: worktree で起動するよう指示してください。

プロンプト:

大規模なディレクトリ構造変更を試したい。Agent ツールで isolation: worktree を使って、隔離環境で試行してください。完了したら worktree のパスとブランチ名を教えてください。

観察ポイント: - メインの作業ツリーが汚染されないこと - 試行が失敗してもメインに影響がないこと - 成功した場合は git merge で取り込めること