Claude Codeの並列作業で「画面に張り付く」をやめるためにやったこと

Claude Codeを複数ペインで並列に動かしても、画面を見続けていたら1本しか進みません。

ターミナルを分割して3本のClaude Codeを起動する。すると承認ダイアログが出るたびに目が吸い寄せられ、エラーが出れば手が止まり、うまくいっているか気になって経過を眺めてしまう。結果、3本動いているのに実質1本分の生産性しか出ない。

並列数の上限はツール側にあるのではなく、「張り付き」という人間側のボトルネックにありました。この記事では、張り付きをやめるために自分がやったことを書きます。現在は5〜6本のワークストリームを同時に回しており、各ストリーム内でさらにサブエージェントが最大6本並列で動くこともあります。

「張り付き」が生まれる3つの原因

まず、なぜ画面から目が離せないのかを整理しました。

1. 承認ダイアログの待ち

Claude Codeはデフォルトでファイル編集やコマンド実行のたびに承認を求めます。承認しないと処理が止まるので、画面を監視せざるを得ません。

2. エラー時の手動介入

ビルドエラーやテスト失敗が起きると、Claude Codeが質問してきたり、間違った方向に修正を始めることがあります。早めに気づかないと手戻りが大きくなる不安から、経過を見守ってしまいます。

3. 「今何やってるか気になる」

単純に、動いているClaude Codeが何をしているか気になって眺めてしまう。これが一番厄介です。生産的な監視ではなく、ただの見物になっている時間が意外と長い。

「張り付き」を打破する4つの手法

やったこと

承認ダイアログをなくす — hooks と権限設定

最初に手をつけたのは、承認ダイアログの削減です。

Claude Codeのsettings.jsonで、信頼できる操作を自動承認に設定しました。

{
  "permissions": {
    "allow": [
      "Bash(git *)",
      "Bash(npm *)",
      "Bash(go *)",
      "Edit",
      "Write"
    ]
  }
}

加えて、hooksを使ってプロジェクト固有の自動化を入れました。EUC-JPファイルの編集時にエンコーディングチェックを挟む、コミット前にtextlintを実行する、といった処理です。

これにより、承認のために画面を見る必要がなくなりました。安全性はhooksに任せ、自分は別の作業に集中できます。

指示を「丸投げできる粒度」にする — スキル化

次に取り組んだのは、指示の定型化です。

「このPRのレビューコメントに対応して」という指示は、実行途中で判断が必要になります。「対応方針はAとBがありますが、どちらにしますか」と聞かれるたびに画面へ戻ることになる。

これを防ぐために、よくあるタスクをスキル（.claude/skills/配下のマークダウンファイル）として定義しました。

# Review-Fix Loop

並行マルチエージェントレビューと自動修正を、指摘がなくなるまで繰り返す。

## 手順
1. PR差分を取得
2. 6つのレビュワー（コード/セキュリティ/テスト/DDD/可読性/仕様）を並列起動
3. critical/warningの指摘を自動修正
4. 再レビュー → 指摘ゼロになるまで繰り返す
5. CIが通ったらレビュー回答を投稿

スキルには「判断が必要な分岐」を含めず、「このスキルを呼んだら完了まで自走する」設計にしています。/review-fix-loop、/triage-issues、/e2e-test など、投げたら放置できるスキルが増えるほど、張り付きの時間が減りました。

非同期で投げて回収する — cmux

cmuxは、複数のClaude Codeセッションをペイン分割で管理できるターミナルアプリです。

cmuxの導入で変わったのは、作業スタイルそのものです。

以前は、1つのClaude Codeに指示を出して完了を待ち、それから次の指示を出していました。今は、5つのペインにそれぞれ指示を投げて別の作業に移り、完了通知が来たペインから順に結果を確認しています。

「投げて放置、終わったら回収」の非同期スタイルです。cmuxには完了通知機能があるので、各ペインの進捗を目で追う必要がありません。

実際の運用では、こんな感じでペインを使い分けています。

ペイン 用途 例
1 メインタスク開発 AIサイトエージェント機能実装
2 レビュー対応 PR #1844 のレビュー指摘修正
3 調査・エスカレ対応 お問い合わせissueの本番DB調査
4 CI修正・テスト flaky test調査、dbサブモジュール更新
5 OSSメンテ myshの新機能開発・レビュー

「完了まで自走する」設計にする

スキルの設計で意識しているのは、「途中で人間に聞かない」ことです。

たとえば/review-fix-loopは、コード・セキュリティ・テスト・DDD・可読性・仕様の6観点でサブエージェントを並列起動し、指摘ゼロまで修正と再レビューを自動で繰り返します。1つのワークストリームの中で6本のエージェントが同時に動いている状態です。途中で「この指摘は修正すべきですか」とは聞きません。criticalとwarningは全て修正し、infoは無視する、というルールをスキル内で定義しています。

5つのペインでそれぞれワークストリームを走らせ、そのうち1つで/review-fix-loopが6本のサブエージェントを起動すると、合計で10本以上のエージェントが同時に動くことになります。これを人間が1本ずつ見守るのは物理的に不可能なので、「見守らなくていい設計」が必須です。

同様に、/triage-issuesは10リポジトリのopenなissueを巡回し、クローズ可能なものはクローズ、PR作成可能なものはPRまで作る。/e2e-testはブラウザ操作からスクリーンショット撮影、PRへのエビデンス投稿まで一気通貫で実行します。

判断基準をスキルに埋め込むことで、「投げたら終わるまで放置できる」タスクの割合が増えます。

実際の1日の流れ

ある日の運用記録から、時系列を抜粋します。

時刻 操作 やっていたこと
9:00 ペイン1にメインタスク投入 —
9:02 ペイン2にissue調査を投入 —
9:05 ペイン3にレビュー対応を投入 Slackを確認
9:13 ペイン2完了 → 結果確認、issueにコメント ペイン1,3は稼働中
9:20 ペイン2にCI修正を投入 ペイン4でOSSのissue確認
9:30 ペイン3完了 → push、CIを待つ —
9:35 ペイン1完了 → 差分確認、コミット —
9:40 ペイン1に次タスク投入 ペイン2,4は稼働中

ポイントは、自分が「Claude Codeの出力を眺めている時間」がほぼゼロなことです。投げる → 別のことをする → 通知で戻る、のサイクルで動いています。

張り付きをゼロにはできない

もちろん、全ての作業が放置できるわけではありません。

  • 設計判断を要する場面。アーキテクチャの選択は人間の仕事である
  • 本番環境への操作では、DB変更やデプロイの結果を確認しながら進める
  • 新しい種類のタスクでは、スキル化されていないため初回は張り付いて進め方を確認する

大事なのは、張り付きが必要なタスクと不要なタスクを区別することです。定型作業はスキル化して放置し、判断が必要な作業に自分の時間を集中させる。

まとめ

並列数を増やすために必要なのは、ツールの性能ではなく「画面から目を離せる仕組み」でした。

  • 承認ダイアログの削減。hooksと権限設定で自動化する
  • 指示の定型化。スキルに判断基準を埋め込み、丸投げできる粒度にする
  • 非同期スタイルへの移行。cmuxで投入と回収を分離する
  • 自走するスキル設計。途中で人間へ聞かない構造にする

これらを整えた結果、5〜6本のワークストリームを同時に回せるようになりました。張り付きをやめると、自分の役割が「コードを見守る人」から「何を解決すべきか判断する人」に変わります。

コメント

タイトルとURLをコピーしました