5月11日に研究プレビューとして投入された Claude Code の Agent View を、3日間にわたって本気で並列運用してみた。claude agents で開く一画面ダッシュボードに走行中・入力待ち・完了・失敗の全セッションが並ぶこの機能は、見た目の派手さこそ控えめだが、運用フローを根本から変える可能性を持つ。実測では3並列でPRドラフト到達時間が中央値33%短縮し、その立役者は .claude/worktrees/ への自動切り出しだった。本稿ではインターフェイスの中身、worktree が果たす役割、そして並列運用の実利と限界を整理する。
Agent View の構造は「一覧 + ピーク + アタッチ」の三層
インターフェイスをざっくり言えば、ターミナル内で開く一覧ビューだ。1行が1セッションに対応し、状態（working / waiting / completed / failed / idle / stopped）、最後の活動時刻、最後の発言の冒頭テキストが並ぶ。Space キーで「ピークパネル」が開き、そのセッションが今待っている質問や直近の出力だけを切り出して確認できる。返答はピーク画面から直接打って Enter で送れるため、軽い対応であればアタッチしなくても済む。腰を据えて議論したければ、行を選んでフル会話にアタッチすればよい。
新しい背景セッションを立ち上げる手順も、慣れれば直感的だ。claude agents で一覧を開いた状態のまま、追加で別プロンプトを Enter で送ると、それが「同じセッションへの追記」ではなく「並列で別セッションを起動」として扱われる。最初はこの挙動の違いに少し戸惑うが、思考のスイッチが切り替わる前に次々と投げ込めるようになると速度感が変わる。動作要件はバージョン 2.1.139 以降。
worktree の自動切り出しが並列運用の安全装置として機能する
ここが今回の本題だ。Agent View 内でファイル編集を伴うセッションは、デフォルトで .claude/worktrees/ 配下に git worktree を切り出し、その中で作業する仕様になっている。3本並列で走らせれば3つのワークディレクトリが独立して掘られ、互いのファイル変更が干渉しない。手元のメインチェックアウトには、確定するまで何も上書きされない構造だ。
これがどう効くか、具体例で示す。筆者は同時に「ログ整形のリファクタ」「APIエンドポイント追加」「依存パッケージのメジャー更新」を別エージェントに投げた。通常であれば、リファクタ作業の最中に依存更新で package.json が書き換わると、両方のセッションが破綻する組み合わせだ。worktree が分かれていれば、それぞれが独立した作業コピーで進行する。マージは筆者が手動で順序立てて行うか、Claude に統合を任せるかを選べる。
過去に「同一ディレクトリで Claude を2セッション動かして壊した」苦い経験を持つ筆者からすると、構造的に事故が発生しなくなる設計は本当にありがたい。Vim でいう :vsplit の独立性に近い感覚で、視覚的にも論理的にも気持ちよく作業できる。
3並列でPRドラフト到達時間が中央値33%短縮
定量的な計測も行った。期間は3日間、午前中の作業セッションを計4回測定。同じ規模・難度のタスク群を、(A) 1セッションで順次処理、(B) Agent View で3並列処理、の2条件で比較した。サンプル数が少ないため断定はしないが、PRをドラフトに到達させるまでの中央値で33%、平均で28%短縮という結果が出た。
注意しておきたいのは、ここでいう「時間短縮」が筆者の机に向かっていた絶対時間ではなく、タスクが完了状態に到達するまでの経過時間を指す点だ。並列処理である以上、認知負荷はむしろ少し上がる。具体的には「次にどのセッションを覗くべきか」の判断が余計に挟まる。
その判断負荷を下げてくれるのが、ダッシュボードの状態列だった。waiting がついた行だけを拾えばよい、というシンプルなルールで動けるので、頭の中の追跡コストは想像より低い。計測の前提条件も残しておくと、タスクはすべて同じリポジトリ内の同程度の issue から選び、Claude のモデルは Sonnet 4.6 固定、ネットワーク状況も同条件で揃えた。完璧なベンチではないし、筆者の判断ノイズも混ざる。それでも3並列の優位はある程度安定して観測できた。
並列にしすぎない・worktreeを残しすぎない・深い議論は単一で
3並列まではかなり快適だったが、試しに5並列にしたところ、筆者の頭の容量が破綻した。スイッチコストは線形ではなく、ある閾値を超えると急に重くなる感覚がある。経験的には、自分が同時に追跡できる粒度は4本程度が限度で、それ以上は「並列で速くなる」効果より「どれが何だったか分からなくなる」コストの方が大きくなる。
worktree の後始末も重要だ。デフォルトでは .claude/worktrees/ 配下にディレクトリが残るため、こまめに削除しないとリポジトリサイズが膨らんでいく。筆者はセッションが completed になったらピーク画面で結果を確認し、その日のうちに不要 worktree を一掃するルールにしている。残しておくと3日後には「このブランチは何だったか」と途方に暮れる羽目になる。
そしてもう一つ、Agent View はあくまで「並列のための器」であり、1本ずつ深く議論したいタスクには向かない。設計レビューや繊細なコード提案を吟味する作業は、これまで通り単一セッションで腰を据える方が結果がよかった。並列にする・しないの選別を1日の冒頭で決めるのが運用のコツだと思う。
推奨アクション
- Claude Code を 2.1.139 以降に更新し、
claude agentsで Agent View を起動できる状態にする - 並列で走らせるタスクは「互いに依存しない」「同程度の粒度」「リファクタ・追加・更新のように性質が違う」組み合わせを選ぶ
- 3本程度を上限とし、状態列の
waitingをトリガーに巡回するワークフローを確立する - セッション完了後はピーク画面で結果確認、その日のうちに
.claude/worktrees/を整理する - 設計レビューや深い議論は従来通り単一セッションで対応する
Agent View 単体では「複数セッションのダッシュボード」に過ぎないが、worktree の自動切り出しと組み合わさることで、Claude Code を「単一の対話相手」から「並列に手を動かす同僚たち」へと格上げする手応えがある。研究プレビュー段階のため挙動が変わる可能性はあるが、いま運用に組み込んでおけば、将来 GA された際にスムーズに移行できるはずだ。
