Claude Code Agent View を使い込む：dispatch 4経路・filter・supervisor の詳細仕様

並走している session が5本を超えたとき、自分の監視コストが一番のボトルネックになっていると気づいた。タスクを投げるのは1分で済む。でも「今どうなってる？」を確認するためにターミナルを切り替えるたびに集中が途切れ、結局1画面に貼り付いてしまう——それでは agent を立てる意味が半減する。

Agent View が欲しいのは、複数 session を管理する「機能」ではなく、その管理から自分が解放される「体験」だ。dashboard を開いたまま別の仕事をしていて、気がついたら3本の session が完了している——そういう使い方が本来の価値だと思う。

2026年5月19日に公開した概要記事（Claude Code Agent Viewで複数セッションを1画面管理する）では、基本概念・状態 icon 5種・shell コマンドの基本を扱った。本稿はその後の運用で見えてきた詳細仕様と落とし穴を深掘りする。

dispatch の4経路と入力 prefix を理解する

Agent View の起点は「どう session を立ち上げるか」だ。公式ドキュメントが説明する dispatch 経路を4つに整理する。

経路A：Agent View 内の入力欄

claude agents を開いた画面下部の入力欄からそのまま task を書いて Enter を押す。最もシンプルな経路で、セッション名は prompt から自動命名される（後で Ctrl+R でリネーム可能）。画像の paste も受け付けるため、スクリーンショットや図を添付して指示できる。

入力には prefix と mention の構文がある。

@ は特に便利で、別リポジトリのコードレビューや調査を一行で投げられる。

経路B：既存 session から /bg

現在の会話を background に送るコマンド。◎ 公式の注記にある通り、background 化すると元のプロセスは破棄されて保存済みの会話から fresh process が再起動する。そのため、走行中の subagent・/loop・background bash コマンドは引き継がれない。Claude が確認ダイアログを出すので、走行中の処理があれば一度止めてから実行する必要がある。

引き継がれる設定は --mcp-config・--strict-mcp-config・--settings・--add-dir・--plugin-dir・--fallback-model・--allow-dangerously-skip-permissions・session 中に /add-dir で追加したディレクトリ。

経路C：シェルから claude --bg

claude --bg "investigate the flaky SettingsChangeDetector test"

claude --agent code-reviewer --bg "address review comments on PR 1234"

# 表示名を明示する場合
claude --bg --name "flaky-test-fix" "investigate the flaky ..."

実行後、short ID と管理コマンドが端末に表示される。スクリプトや makefile から呼び出すのに適している。

経路D：空入力で ← を押す

◎ 公式の説明:

> pressing ← on an empty prompt works from any Claude Code session, not only ones you attached to from agent view. It backgrounds the current session and opens agent view with that row selected.

つまり、通常の interactive session でもテキストを入力していない状態で左矢印を押すだけで current session が background 化して Agent View に飛ぶ。操作が最少で済むため、「あ、これ長くかかりそう」と気づいた瞬間に session を手放すのに使いやすい。/config の leftArrowOpensAgents で無効化できる。

filter syntax でセッションを絞り込む

入力欄に特定の構文を書くと、新規 dispatch ではなく 既存セッションのフィルタとして動く。◎ 公式仕様：

4文字未満は Too short で reject される。誤入力でセッションが立ち上がってしまうのを防ぐガードだ。session が10本を超えてくると、まず s:blocked で human input が必要なものを洗い出し、続けて s:working で稼働中を確認する流れが定着する。

PR status dot の4色と、キーバインドの新規追加分

PR status dot

セッションが PR を開いた場合、リスト行の右端に色付き dot が表示される。◎ 公式の定義：

複数 PR がある場合は最も注意が必要な色が表示され、件数が数字で前置きされる。terminal が hyperlink をサポートしていれば PR ページへ直リンクになる。「mergeできる状態かどうか」を会話を開かずに dot の色で判断できる。PR を数本同時に進めているときほど、この一目感知が積み重なる。

キーバインドの新規追加分

概要記事で触れた基本操作（Space/Enter/←/Ctrl+T/Ctrl+S/Ctrl+X）に加えて、v2.1.139 以降で追加されたキーバインドを補足する。

Alt+1..9 が特に実用的で、同一ディレクトリに複数 session が並走する場合に数字キー一発で切り替えられる。長文の prompt を書くときは Ctrl+G でエディタに逃がせるのも地味に助かる。

supervisor process の詳細仕様

状態保存の3パス

◎ 公式ドキュメントが定義する状態保存先：

daemon status コマンド（claude daemon status）または session 内の /doctor で supervisor の到達性・PID・version・socket・worker 数を確認できる。セッションが意図せず消えた感覚があるときはここを最初に見る。

auto-update 追随の挙動

supervisor は binary の更新を local file watch で検知し、更新があれば自動再起動して新版を読み込む（network チェックではない）。これにより、Claude Code を意識して再起動しなくても最新版に追随する。ただし更新直後の短い時間は session の応答が止まることがある。慌ててプロセスを kill しないほうがいい。

CLAUDE_CONFIG_DIR で別 instance を立てる

CLAUDE_CONFIG_DIR 環境変数を変更すると別 instance として supervisor が起動し、複数の supervisor を並列で走らせられる。プロジェクトごとに config を完全に分離したい場合に使う。

起動オプション・permission mode 継承の詳細

バージョン別の追加オプション

◎ 公式リリースノートより：

v2.1.141 以前のバージョンでは --cwd が使えないので、claude --version で確認しておく。

起動経路ごとの permission mode 継承

◎ 公式の制約：

> Using bypassPermissions or auto is refused until you have accepted that mode by running claude with it once interactively, since those modes let a session you aren't watching act without approval.

一度も対話で承認していない mode は background に投げられない。Auto Mode は Anthropic API 限定であり、Bedrock では使えない（Bedrock 経由での注意事項はBedrock vs サブスク比較記事に詳しい）。

行サマリの Haiku コストと、組織制御の設定

行サマリは Haiku で生成されている

◎ 公式:

> The one-line summary in each row is generated by a Haiku-class model so the row can tell you what the session is doing, what it needs, or what it produced without opening the transcript. While a session is actively working, the summary refreshes at most once every 15 seconds, plus once when each turn ends.

各リフレッシュは通常プロバイダー経由の短い Haiku リクエスト1件として課金される。

○ 筆者推計：10 session が working 中の場合、最大で15秒ごとに10件の Haiku リクエストが走る。単純計算で1分あたり40件相当（公式は更新間隔と並列数を示すのみで具体的なリクエスト数の試算は提示していない。本数値は公式仕様からの計算）。Haiku 単価は安いが、dashboard を開きっぱなしにして大量の session を走らせ続けると予想外に積み上がる場合がある。Bedrock 経由で Haiku がリージョンで有効化されていない場合、primary model にフォールバックしてコストが跳ね上がる（詳細は前掲のBedrock 記事参照）。観測の文脈でコスト可視化を入れるなら、OTel 記事で紹介したトレーシング設定と組み合わせると session ごとの Haiku コストも追跡できる。

組織として Agent View を無効化する

◎ 公式:

> To turn off background agents and agent view entirely, set the disableAgentView setting to true or set the CLAUDE_CODE_DISABLE_AGENT_VIEW environment variable. Administrators can enforce this through managed settings.

チームや企業で「複数 agent 並走を組織方針として禁止したい」場合、managed settings で disableAgentView: true を全員に配布できる。MDM 経由での配布を前提とした設定で、エンタープライズ用途に向けた制御だ。

worktree 削除前に必ず確認すること

Agent View の Ctrl+X で session を止めた後、2秒以内に再度 Ctrl+X を押すと session が削除される。◎ 公式の注意:

> Claude-created worktrees are deleted with the session in agent view: merge or push changes before deleting a session that edited files in its own worktree.

未コミットの変更ごと消える。確認ダイアログは出ない。作業途中のコードが残っている session を誤操作で削除してしまうと、ファイルごと消えて復元できない。shell の claude rm は未コミット変更があれば worktree を残して path を表示するので安全だが、Agent View の UI 操作はそのガードがない。

削除前に claude logs で作業状態を確認するか、Enter で attach して変更を commit/push してから消す。

また、worktree 分離を無効化したい場合（git worktree が使えない環境など）は .claude/settings.json に以下を記述する。

{
  "worktree": {
    "bgIsolation": "none"
  }
}

まとめ：今日から運用に加える1点

最初に手をつけるなら s:blocked の filter だけでいい。session を5本以上走らせると、自分の承認待ちで止まっているセッションがどこかに必ず出てくる。入力欄に s:blocked と打つだけで human input が必要な session だけが残る。これを1日2〜3回確認するだけで、自分の監視時間はかなり削れる。

細かい仕様（dispatch 4経路・filter syntax・Haiku コスト）は必要になったときに戻ってきてほしい。今日の運用に s:blocked を1つ加える。それだけでいい。

なお、/batch（複数 worktree を一斉生成するコマンド）は2026年5月時点で planned / 未リリースだ。比較表などで見かけることがあるが、現時点では利用できないので注意してほしい。