Claude Code を触ってる人、たぶん一回はこうなる。
Rulesが増え、
sub-agentが増え、
MCPを繋ぎ始め、
気づいたら CLAUDE.md が300行を超えていて、
worktree が5個並んでて、
「これ本当に運用できてるのか?」
が分からなくなる。
これは、その状態のままClaude Codeを使い倒した結果、
個人開発が「工場」みたいになっていった話。
最後に Anthropic公式PDF「How Anthropic teams use Claude Code」と並べてみたら、
1人の個人開発者でも社内10チーム中6チームの運用に届いていた、という答え合わせまで書く。
Anthropic公式PDFの日本語解説HTML版を別途用意した → anthropic-teams-guide.vercel.app
10チーム+共通5パターン+10項目チェックを、要約ページ→各チーム1枚の構成で読める。本記事と合わせて読むと、自分の運用と公式チーム運用の差分が見える。
気づいたら worktree が5個並んでいた
きっかけは、深夜にちょっとした検証をしたかっただけ。
Cockpit という個人プロジェクトに新機能を足そうとして、
最初は1つの worktree で書き始めた。
途中で「別の設計の方が良くね?」と気になって、もう1つ立てた。
さらに「テスト先に書かせる方が早そう」で3つ目を切った。
気づいたら worktree が5個開いていて、
別々のClaude Codeセッションが、
別々のブランチで、
別々の修正を並列で進めていた。
~/projects/cockpit/ ← main(俺が監視)
~/projects/cockpit-A/ ← Claude #1 (auto-accept放置)
~/projects/cockpit-B/ ← Claude #2 (テストから書かせ)
~/projects/cockpit-C/ ← Claude #3 (リファクタ試案)
~/projects/cockpit-D/ ← Claude #4 (UIだけ別実装)
俺がやってたのは、各worktreeを巡回して、
「これは採用」「これは捨て」「これは部分採用」を判定するだけ。
手は動かしてない。
判定だけしてた。
この時点で、
1人の個人開発が、
1人のディレクター + 4人のジュニア、
みたいな構造に勝手になっていた。
「修正するより捨てる」を覚えた夜
最初は worktree が壊れる度に直そうとしていた。
30分かけて修正して、また30分かけて別の壊れ方を直して、
気づいたら2時間溶けていた。
ある夜、面倒くさくなって、
壊れた worktree を git worktree remove --force で消して、
さっきの指示プロンプトをそのままもう一度Claudeに投げ直した。
git worktree remove ../cockpit-B --force
git worktree add ../cockpit-B -b retry-b
cd ../cockpit-B
claude "$LAST_PROMPT"
30分後、別の方向の解が出てきた。
これが普通に動いた。
これ以降、
「直す」より「捨ててやり直す」方が早い、
が個人開発の中で定着した。
Claudeは1回目より2回目の方が良い解を出してくることが普通にある。
人間が修正で粘ると、Claudeの最初の選択肢に引っ張られて、
むしろ詰む。
「直さない」というのは、
最初は罪悪感があった。
書いてもらったコードを30分かけて生成して、消すのか、と。
でもAIに対して罪悪感を持つ意味は無い。
Claudeは何回でも回せる。
時間は1回しかない。
これに気づいてから、
worktree は「使い捨ての試作工場」になった。
CLAUDE.md に書き込みすぎて、AIが別人格になった
並列で回し始めると、
worktreeごとにClaudeの挙動がブレてくる。
「テスト書いてから実装」と言ったのに、いきなり実装から始めるやつ。
「コア領域は触るな」と言ったのに、コアファイルを書き換えるやつ。
auto-accept に任せたら、依存ライブラリを勝手に追加するやつ。
毎回プロンプトで縛るのが限界に来た。
それで CLAUDE.md に運用ルールを書き始めた。
# Workflow rules
- After every code edit, run `npm run lint && npm test` automatically.
- If a test fails, fix it in the same iteration before reporting back.
- Use git worktree for parallel exploration. Commit a checkpoint per worktree.
- Auto-accept mode is allowed only for files under `src/components/` and `tests/`.
- Core business logic under `src/core/` requires synchronous review.
- Never add new dependencies without an explicit instruction.
書き込み始めたら、止まらなくなった。
気づいたら CLAUDE.md が300行を超えていた。
そのプロジェクトの Claude は、
他のプロジェクトの Claude と明らかに性格が違った。
口数が減って、確認の頻度が増えて、
こっちが「いきなりリファクタしていい?」と聞くと、
「先に該当ファイルを Read します」と返してきた。
別人格になった、と表現するしかなかった。
これが効きすぎて、
他のプロジェクトでも CLAUDE.md を書き込むようになった。
ルールが資産になった。
auto-accept は「外側だけ」放置、コアは隣に座る
並列で回すうちに、
auto-accept を全部にかけると事故る、
逆に全部監視すると速度が出ない、
というのを何度かやらかして覚えた。
落ち着いた境界はこれ。
| 領域 | モード | 理由 |
|---|---|---|
| UIコンポーネント、ユーティリティ、テスト | auto-accept で放置 | 失敗してもgit revertすればいい |
| ビジネスロジックのコア、認証、決済、DBスキーマ | 同期監視（隣に座る） | revertでは取り返しがつかない領域 |
| 依存追加、設定ファイル、CI/CD | 必ず確認 | 影響範囲が読みにくい |
この境界を CLAUDE.md に書いておくと、
Claude側が自主的に確認に来る。
「src/core/payment.ts を編集していいか?」
みたいに止まってくれる。
監督コストを CLAUDE.md に外出ししたら、
監視疲れがほぼ消えた。
sub-agent に役割を割ると、自分が編集者になる
Claude Code 1個に全部やらせていた頃は、
プロンプトが長くなり過ぎて、Claudeが混乱する場面が多かった。
「Qiita記事のネタを選んで、調査して、書いて、品質チェックして、投稿して」
を1プロンプトで投げると、調査が浅いまま書き始めたり、品質チェックを飛ばしたりした。
役割を分けたら直った。
const qiitaWorkflow = {
topicSelector: spawn("research", { tools: ["WebSearch", "WebFetch"] }),
writer: spawn("writer", { tools: ["Read", "Write"] }),
qualityGate: spawn("reviewer", { tools: ["Read", "Bash"] }),
publisher: spawn("publisher",{ tools: ["Bash"] }),
};
ネタ選定が終わってから writer に渡す。
writer の出力を quality gate が見る。
通ったら publisher が Qiita API を直接叩いて投稿する。
ここまで来ると、
俺がやっているのは「方針を決める」と「最終確認」だけ。
実作業はClaudeが全部やる。
工場のラインに立っている感じが強くなった。
ここで答え合わせ。Anthropic公式と並べてみた
ここまでの運用を、
2025-06に Anthropic が公開したPDF
How Anthropic teams use Claude Code
と並べてみた。
社内10チームのインタビュー集で、
データインフラ、Product Dev、Security、Inference、Data Science、API、Growth、Design、RL、Legal の10チームの運用が書いてある。
10項目で自己採点した結果がこれ。
| チーム | 公式の主要パターン | 自分の状況 | 判定 |
|---|---|---|---|
| Product Development | auto-accept放置、worktree並列、checkpoint頻発 | 同じ運用が動いている | ◎ |
| Growth Marketing | sub-agent分離、量産パイプライン、自作MCP |
/qiitaスキルで同構造 |
◎ |
| Security Engineering | カスタムslash多用、設定レビュー |
/verifyスキル+公開22項目チェック |
○ |
| Data Science & Viz | スロットマシン運用、永続Reactダッシュボード | worktree隔離でスロットマシン運用 | ○ |
| API | "first stop"原則、model dogfooding | メモリ自動更新で文脈ゼロから即動作 | ○ |
| Product Design | スクショ→プロトタイプ、Actions経由ticket | スクショ運用は同じ、Actions未着手 | ○ |
| Data Infrastructure | Claude.md整備、MCP優先 | BigQuery系は対象外 | △ |
| RL Engineering | try & rollback | RL対象外、運用パターンだけ流用 | △ |
| Legal | 1hでアクセシビリティアプリ | 法務領域は対象外 | △ |
| Inference | ML概念学習 | 対象外 | − |
集計は ◎2 / ○4 / △3 / −1。
10チーム中6チームの主要運用に届いていた。
特に深くマッチしたのは Product Development と Growth Marketing。
正直、社内の話を聞いて「あー、自分もそれやってるな」が連発した。
worktree 並列も、スロットマシン運用も、sub-agent分離も、
個人開発の現場で勝手に同じ結論に辿り着いていた。
逆に未達は2つで、ここが伸びしろ。
- MCP server の自作: Growth Marketing が Meta Ads API の MCPサーバを自作している。自分は使う側しかやってない。
- GitHub Actions 経由の Claude 自動PR: Product Design / Product Dev が言及。Issue を切るだけで Claude が修正PRを出す構成。これも個人OSSで効くはず。
工場化が進むと、ボトルネックは人間になる
並列でClaudeを回せば回すほど、
俺がやることは「方針決め」「採否判断」「次に何をやらせるか」
だけになってきた。
Claudeの出力速度に、
俺の判断速度が追いつかない、
という瞬間が出てきた。
これは技術的問題じゃなくて、
意思決定の問題。
- 何を作るか
- どう作るか
- どこで諦めるか
- どこに時間を投資するか
ここは最後まで人間に残る。
むしろClaudeが手を動かしてくれる前提で、
人間側は「何をやらないか」を決める仕事になる。
CLAUDE.md の300行は、
ルールの集積であり、
「何をやらないか」のリストでもある。
公式PDFに書いていない、自分が先行している領域
10チーム読み終わって気づいたのは、
公式が触れていない運用がいくつかあること。
-
メモリ自動改善ループ: session 終わりに、Claudeに
CLAUDE.md自体のリファクタ案を出させる。公式は Data Infrastructure が「end-of-session updates」を1行触れる程度。 - 設計書ファースト原理を skill 化: 仕様→設計→実装→検証を段階制御するスラコマを自作。公式は RL が「pseudocode→TDD」と言うのみ。
- 公開時セキュリティ22項目チェック: Vercel/GitHub/Qiita/npm 公開時にAIが自動で blocking する仕組み。公式 Legal チームは「conservative posture が必要」と言うだけで具体策が無い。
ここは個人開発者がドキュメント化していけば、
公式と差別化できる領域だと思っている。
次に作るもの
弱点の2つを埋める。
1個目は MCP server の自作。
題材は Qiita 自分のアカウント分析。
PV / いいね / ストック / コメント を Claude Code から直接問い合わせて、
記事ネタの選定にフィードバックさせる。
Anthropic Growth が Meta Ads でやっていることの Qiita 版。
2個目は GitHub Actions 経由の自動PR。
Issue を切ると Claude が draft PR を出してくる構成を、
個人OSSの Cockpit に組み込む。
両方できたら、また書く。
個人開発者向け、10項目チェックリスト
最後に、自分で採点したい人向けに置いておく。
□ CLAUDE.md / AGENTS.md にプロジェクト固有のルールを15項目以上書いた
□ worktree を日常的に2つ以上並列で動かしている
□ sub-agent を2種類以上、役割分担で使い分けている
□ 自作の slash command を5個以上持っている
□ 失敗時は「直す」より「捨ててやり直す」を選んでいる
□ auto-accept とコア同期監視の境界をルール化している
□ MCP server を1つ以上「消費」している
□ MCP server を1つでも「自作」したことがある
□ Claude Code から GitHub Actions / CI を直接動かせる
□ session 終わりに CLAUDE.md / メモリを Claude 自身に更新させている
7個以上Yesなら、Anthropic公式10チームの平均運用に届いている。
自分は現時点で 8/10。
公式PDF本体は こちら、22ページで30分で読める。
読み終わったら、自分の運用を採点してみると、Claude Codeの伸びしろが嫌でも見える。
参考リンク。