Claude Codeのパワーユーザーtips — 検証を軸にした並列・計画の型

Claude Codeチームのエンジニアたちが日常で使っている型は、ヘルプセンターの記事にまとまっています。その中で最も効くと明記されているのが、検証、つまりClaudeに自分の出力を確かめる手段を渡すことです。1つだけ取り入れるならこれ、というのが原文の立場です。

この記事では、その型を「検証 → 並列 → 計画 → 学習の積み上げ」の順に組み直します。あわせて、ヘルプセンターの記述とコマンドリファレンスで数字や範囲が食い違う箇所も拾います。

なぜ検証が最優先なのか

Claudeが自分でフィードバックループを閉じられれば、出力が正しくなるまで反復します。人間に「ブラウザを使わせずにWebサイトを作れ」と頼んでも出来が悪いのと同じ理屈です。

検証手段は領域ごとに変わります。bashコマンド、テストスイート、シミュレーター、ブラウザテストなどです。原則は共通で、領域に合った検証に投資することです。

検証手段を渡す3つの経路

Chrome拡張には前提条件があります。Chrome連携のドキュメントによると、必要なのはChromiumベースのブラウザ、拡張のバージョン1.0.36以上、そしてAnthropic直契約のプラン(Pro、Max、Team、Enterprise)です。APIキーやclaude setup-tokenの長期トークンで認証している場合、--chromeを付けてもChrome連携はオフのままです。Amazon Bedrockなどのサードパーティ経由だけで使っている環境でも使えません。

手元で回す検証ループの例

ブラウザがなくても、検証の考え方は移せます。CLAUDE.mdに「完了の定義」を書き、Claudeに実行させる型です。次はその書き方の例です。

## 完了の定義
- 変更後は必ず `npm test` と `npm run typecheck` を実行し、出力を読んでから報告する
- 失敗したら原因を直して再実行する。通るまで「完了」と言わない
- UI を変えた場合は dev サーバーを起動し、該当画面の表示を確認する

ヘルプセンターのサンプルではなく、検証を渡すという原則をCLAUDE.mdに落とした一例です。検証コマンドがプロジェクトごとに違うなら、そのコマンド名まで書いておくと迷いが減ります。

バグ探しではない(/simplify)

ヘルプセンターは、変更後に/simplifyを付けると再利用・品質・効率・CLAUDE.mdへの準拠を1回でレビューする、と書いています。一方でコマンドリファレンスの説明は少し違います。

• 4つのレビュー用エージェントが並列で動く
• 観点は、既存ヘルパーの再利用、簡素化、効率、抽象度が適切か
• 正しさのバグは探さない。バグ探しは/code-reviewの領分

つまり/simplifyは検証の一手ではあっても、動作の正しさを保証する道具ではありません。テストやブラウザ確認と組み合わせて使う位置づけです。単体の使い方は/simplifyの解説にまとめています。

並列実行は3〜5セッションから

生産性がいちばん伸びるのは、3〜5セッションをそれぞれ別のgit worktreeで並列に回す使い方です。

claude --worktree my_worktree --tmux

--worktree(短縮形-w)は、<repo>/.claude/worktrees/<name>に隔離されたworktreeを作ってセッションを始めます。--tmuxはworktree用のtmuxセッションを作るフラグで、--worktreeと併用が必須です。名前を省くと自動で付きます。

迷子にならない工夫は次のとおりです。

• worktreeに名前を付け、シェルのエイリアスで行き来する
• ターミナルのタブを色分けする
• 通知を有効にして、どのClaudeが待っているか分かるようにする
• ログ読みやクエリ実行専用の「分析用」worktreeを1つ持つ

セッションを色で見分ける(/color)

/colorはプロンプトバーの色を変える組み込みコマンドです。選べる色はred・blue・green・yellow・purple・orange・pink・cyanで、defaultで戻せます。引数なしだとランダムです。v2.1.205以降で使えます。3〜5セッションを並べたときに、見た目で取り違えを防ぐのが主な用途です。

サブエージェントにもworktreeを与える

サブエージェントの定義にも隔離を指定できます。サブエージェントのドキュメントでは、isolation: worktreeを指定すると一時的なgit worktreeで動き、変更がなければworktreeは自動で片付けられます。

---
name: worktree-worker
model: haiku
isolation: worktree
---

これは.claude/agents/worktree-worker.mdの冒頭に置く形です。続けて「同期I/Oをすべて非同期に移行して。変更をバッチ化し、worktree隔離の10エージェントを並列に起動。各エージェントはエンドツーエンドでテストしてPRを出す」のように自然な言葉で頼む例があります。

worktreeはgitリポジトリが前提です。Mercurial、Perforce、SVNなどでは、WorktreeCreateとWorktreeRemoveのフックで作成と削除の処理を差し替えます。並列セッションの隔離と落とし穴はWorktree実践ガイドが詳しいです。

大規模移行の規模感(/batch)は記事で違って見える

大規模移行には/batchがあります。ヘルプセンターは「必要なだけのworktreeエージェント(数十、数百、それ以上)に展開する」と書いています。コマンドリファレンスの説明は、作業を5〜30の独立した単位に分解し、計画を提示し、承認後に単位ごとにバックグラウンドのサブエージェントを起動する、という具体的な範囲です。

実際に使うときは、後者の「5〜30単位に分解され、承認を挟む」前提で見積もるほうが外れません。手順は/batchコマンドの解説を参照してください。

計画は実装より先に厚くする

計画まわりの型は次のとおりです。

セッション名は、プランモードの後にClaudeが自動で付けます。claude --name "auth-refactor"で先に決めることもできます。

押し返すプロンプトと/btw

最初の解を受け入れず、押し返すプロンプトも使います。

• 「この変更について私を問い詰めて。私が合格するまでPRを作らないで」
• 「これが動くと証明して」(mainと機能ブランチの挙動をdiffさせる)
• 「今わかっていることを踏まえて、これを捨ててエレガントな解で実装し直して」

Claudeが作業している最中に、手を止めさせず質問したいときは/btwです。単発のターンでツール呼び出しはしませんが、会話の全文脈を見ています。履歴にも残りません。引数なしで実行すると直近の副質問を一覧でき、この挙動はv2.1.212以降です。詳しくは/btwの使い方にあります。

CLAUDE.mdに間違いを貯める

もう1つの型は、修正のたびにCLAUDE.mdを育てることです。Claudeが間違えたら毎回「同じ間違いをしないよう、CLAUDE.mdを更新して」と締めます。PRレビューでは、/install-github-appで入れたGitHub Actionに対し、コメントで@claudeにCLAUDE.mdへの追記を頼む運用もあります。

nit: use a string literal, not ts enum
@claude add to CLAUDE.md to never use enums, always prefer literal unions

修正の指摘がそのままルールに変わる流れで、この流れは「Compounding Engineering」と呼ばれます。自動メモリーは/memoryで設定し、~/.claude/projects/<project>/memory/に保存されます。手で書くCLAUDE.mdとは別枠です。

繰り返しはスキルとループに

「1日に2回以上やることはスキルにする」が目安です。スキルは.claude/skills/<name>/SKILL.mdに置き、チームで共有します。例は、セッション終了時に重複コードを探す/techdebtです。

繰り返し実行の期間は3日か7日か(/loop)

/loopは、セッションを開いたまま同じプロンプトを繰り返し走らせるバンドルスキルです。ここで数字が割れます。

期限を前提にする運用なら、スケジュールタスクのドキュメントの7日を基準にし、実際の挙動は手元のバージョンで確かめるのが安全です。最小間隔は1分で、間隔を省けばClaudeが毎回の間隔を決めます。

チームの使い方は、/loop 5m /babysit(レビュー対応・リベース・PR見守り)、/loop 30m /slack-feedback(Slackの指摘からPR作成)、/loop 1h /pr-pruner(古いPRの整理)です。PCを閉じても動かしたいなら、クラウドで走る/scheduleを使います。詳細は/loopの解説にあります。

フックと権限で人手を減らす

フックは、エージェントのライフサイクルの決まった時点で処理を走らせます。代表例は、PostToolUseでの自動整形です。

"PostToolUse": [
  {
    "matcher": "Write|Edit",
    "hooks": [{ "type": "command", "command": "bun run format || true" }]
  }
]

長い作業の完了確認には3案があります。バックグラウンドのエージェントに検証させる、Stopフックで決定的なチェックを走らせる(監査が要るワークフロー向け)、コミュニティ製の「ralph-wiggum」プラグインを使う、の3つです。このプラグインはAnthropicが審査したものではないため、管理環境に入れる前に管理者へ確認が必要です。

権限は/permissionsで安全なコマンドを事前許可し、.claude/settings.jsonにコミットする運用が、権限確認を丸ごと飛ばすより監査しやすい選択肢です。Bash(bun run *)やEdit(/docs/**)のようなワイルドカードも使えます。

自動判定とサンドボックス

auto modeは、Claudeの代わりに権限判断を分類器が下します。安全な操作は自動で通り、危険なものは確認に回ります。Shift+Tabでセッション中いつでもモードを切り替えられます。仕組みはauto modeの解説にあります。

/sandboxは、ファイルとネットワークの両方を隔離するサンドボックスを有効にします。選べるのは「BashToolをサンドボックス化して自動許可」「サンドボックス化して通常の権限確認」「サンドボックスなし」の3つです。詳しくはサンドボックスの解説を参照してください。

モデルと思考の深さを選ぶ

ヘルプセンターに載るチームの考えは、Opusを思考付きで常用する、というものです。Sonnetより大きく遅くても、誘導の手間が減りツール使用も上手なので、最終的には速い、という理屈です。

思考の深さは/effortで選びます。段階はlow・medium・high・xhigh・max・autoです。複雑なコーディングやエージェント作業では、maxほど重くないxhighが候補になります。maxは難しいデバッグや設計判断向けで、利用上限の減りが速いため、セッション単位で切り替えるのが前提です。

学び方を変える出力スタイル

/configで出力スタイルをExplanatoryにすると、変更の理由まで説明が付きます。Learningにすると、変更の進め方をコーチしてくれます。未知のコードにはHTMLの解説スライドやASCII図を頼む、理解を話して追加質問で穴を埋めさせる、といった使い方も挙がっています。スタイルの使い分けは出力スタイルとCLAUDE.mdの比較が詳しいです。

外出先・複数リポジトリ・環境の整え方

スマホと端末間の引き継ぎ

ClaudeアプリのCodeタブから、モバイルでも操作できます。claude --teleport(セッション内では/teleport)は、クラウド上のセッションを手元に引き継ぎます。/remote-controlは手元のセッションをスマホやWebから操作する機能で、Pro・Max・Team・EnterpriseプランのCLI v2.1.51以降が対象です。

MCPとプラグイン

SlackのバグスレッドをMCP経由で貼って「fix」と頼む、bq CLIでBigQueryの指標を引く、といった外部ツール連携は、claude mcp addかsettings.jsonのmcpServersで足します。LSP・MCP・スキル・エージェント・フックをまとめた配布単位がプラグインで、/pluginから入れます。設定はMCPサーバー設定ガイドとプラグインとマーケットプレイスの解説で追えます。

ステータスラインと端末まわり

/statuslineは、.bashrcや.zshrcをもとに、モデル・ディレクトリ・残りコンテキスト・コストなどを出す表示行を作ります。/keybindingsでキーを割り当て直せ、設定は~/.claude/keybindings.jsonに保存されて即時反映されます。IDE端末などでShift+Enterを改行にするには/terminal-setupを使います。

SDKと複数リポジトリ

claude -pは既定でローカルのCLAUDE.md・設定・MCPを探しに行きます。非対話の用途では--bareを付けて必要なものだけ明示すると、起動が約10倍速くなります。複数リポジトリをまたぐ作業は、--add-dir(セッション内では/add-dir)で追加フォルダへのアクセスを渡します。既存セッションから枝分かれするには/branchです。

取り入れる順番

全部を一度に入れる必要はありません。効果の大きい順に並べると次のとおりです。

1. 検証手段を渡す(テスト・型チェック・ブラウザ確認をCLAUDE.mdに明記)
2. 並列セッションを2つから始め、慣れたら3〜5に増やす。/colorと名前で見分ける
3. 複雑な作業はプランモードで計画してから実装する
4. 間違いを指摘するたびにCLAUDE.mdへ追記する
5. 1日に2回以上やる作業をスキル化し、/loopに載せる

ヘルプセンターの記事自体が、Claude Codeは頻繁に更新されるため、社内に配る前にバージョン固有の事項はコードドキュメントで確かめるよう注記しています。ここまでの数字の食い違いも、その典型です。チーム別の使い道を知りたい場合はAnthropic社内の活用事例が参考になります。