Claude Codeのagent view — 複数セッションを束ねる常駐プロセス設計

背景

Claude Codeを日常的に使うエンジニアは、いつの間にか複数ターミナルで複数のClaudeセッションを並走させる運用に至ります。「機能Aを実装するセッション」「テストを書くセッション」「コードレビュー指摘を直すセッション」が、それぞれ別ターミナルで動いている状態です。

問題はそこから始まります。どのセッションが今何をしているか分からない。レビュー待ちで止まっているセッションを探すために、ターミナルを片っ端から開き直す。/loopで走らせたバックグラウンドジョブが、いつの間にか終わっているのか走っているのか把握できない。

v2.1.139で導入されたagent view(claude agentsコマンド)は、この「複数セッション並走の見える化」を解決するResearch Preview機能です。背後ではper-user supervisor processという新しい実行モデルが動いており、これがClaude Codeを「単発ツール」から「マルチエージェント運用基盤」に変える基盤になっています。

本記事では仕様の掘り下げと内部設計、運用上の注意点を解説します。

仕様の掘り下げ

起動とスコープ

claude agents

これだけでagent viewが起動します。表示されるのはユーザーの設定ディレクトリ(config dir)配下にある全バックグラウンドセッションで、プロジェクト / worktree横断です。「あるリポジトリで動いている全Claudeセッション」ではなく、「あなたが動かしている全Claudeセッション」が見えます。

ただし、claude agentsはResearch Previewのため、UI / キーバインドは将来変更される可能性があります。組織レベルで無効化するにはdisableAgentView設定を使います。

状態アイコンの意味

セッションごとに状態 + プロセス生死の2軸で表示されます。

状態(色 / アニメーション):

プロセス生死(形状):

この状態 × プロセス生死の二重表示により、「Needs input + ✻」(プロセス生存)と「Needs input + ∙」(プロセス停止中、再開時に入力待ち状態に戻る)が区別できます。

グループとフィルタ

セッションは以下のグループに分類表示されます:

• Pinned(ユーザーがピン留めしたもの、常に上)
• Ready for review(Completed 等、確認待ち)
• Needs input(ユーザー入力待ち、優先度高)
• Working(動作中)
• Completed(完了)

フィルタも豊富:

Pull Request status dot

セッションがPRを開くと、各行にPRの状態を色で示すstatus dotが表示されます。複数のセッションが並列でPRを作っている運用では、レビュー待ち / マージ可否をagent view上で判別できます。

セッションが複数のPRを開いている場合、状態がもっとも進んでいないPRを代表色として表示し、件数も並記されます。

ディスパッチプロンプトの拡張構文

agent viewから新規セッションを起動する際、プロンプトの先頭にプレフィックスを付けて起動先を指定できます。

これらを組み合わせることで、エージェント・リポジトリ・skillの3軸を1ストロークで切り替えながらディスパッチできます。

Row summaryはHaikuで15秒ごとに更新される

各行に出る「1行サマリ」はHaikuクラスの小型モデルで生成され、約15秒に1回更新されます。サマリ生成は通常プロバイダ経由で課金されるため、大量のセッションを並走するとサマリ分のトークン消費も累積します。1セッションあたりは小さい(数十〜数百トークン)ですが、10本以上常時走らせる運用ではコスト要因として意識する価値があります。

キーバインド

agent view内の操作は以下の通り:

Alt+1..9 で1ストロークの切替ができるのは、複数セッション運用での生産性を大きく上げます。

Shellからの操作

agent viewを起動しなくても、shellから個別操作できます:

claude attach <id>     # 特定セッションにアタッチ
claude logs <id>       # ログを表示
claude stop <id>       # 停止(`claude kill` も同義のエイリアス)
claude respawn <id>    # 停止セッションを再起動
claude rm <id>         # 削除
claude --bg "..."      # 新規 background セッションを起動

claude --bg には --agent <subagent名> や --permission-mode <mode> を組み合わせられます。例えば claude --bg --agent reviewer "PR #123 をレビュー" のように起動先サブエージェントを指定したり、--permission-mode bypassPermissions でツール承認をスキップしたりできます。ただし bypassPermissions と auto を渡すには、事前に対話セッションで該当モードを受諾済みである必要があります(セキュリティガード)。

セッション内からのバックグラウンド送出には /background(エイリアス /bg)、セッション内終了には /stop が使えます。claude agents の外からでも、shellコマンドと組み合わせてスクリプト / Makefile / CIから制御可能です。

環境変数による挙動制御

実装イメージ / 内部動作の推察

ここからがagent view真の価値が見えてくる部分です。

ユーザー単位の常駐プロセスという設計

公式ドキュメントによると、agent viewの背後にはユーザー単位の常駐プロセス(per-user supervisor process)が動いています。これはClaude Code v2.1.139で導入された新しい実行モデルです。

              ┌──────────────────────────────────┐
              │  per-user supervisor process     │
              │  (background daemon)             │
              │                                  │
              │  ┌──────┐  ┌──────┐  ┌──────┐    │
              │  │ ses1 │  │ ses2 │  │ ses3 │... │
              │  └──────┘  └──────┘  └──────┘    │
              │      ↑                           │
              └──────│───────────────────────────┘
                     │
                  state.json (per session)
                  roster.json (supervisor)

各バックグラウンドセッションは独立したClaude Codeプロセスとして常駐プロセスの子プロセスで動きます。常駐プロセスはroster.json(~/.claude/daemon/roster.json)で全セッションを管理し、各セッションの状態はstate.json(~/.claude/jobs/<id>/state.json)に保存されます。

Idle時の省リソース動作

注目すべきは、1時間アタッチがないと省リソースのためプロセスが停止する仕組みです。次回peek / reply / attach時に、常駐プロセスがstate.jsonから新しいプロセス(fresh process)を再起動します。これは内部的に --resume 相当の挙動で、ユーザーから見ると「セッションがいつでも生きているように見える」が、実際は必要なときだけプロセスが立ち上がる仮想化された設計です。

これにより:

• 10セッション並走しても、Idle中はメモリ / CPUを消費しない
• 常駐プロセス自体は軽量(roster管理のみ)
• 再起動時にプロセスが立ち上がる分の僅かな遅延はあるが、人間がpeekするときには気づかない

自動更新との両立

Claude Codeが更新された際、常駐プロセスはバイナリのファイル監視で新版に切り替えます。常駐プロセスはdetachedなため、動作中のセッションには影響しません。次回spawn時から新版が使われます。

これも複数セッション運用前提の設計です。1セッションだけなら手動再起動で済みますが、10セッション並走している環境で自動更新が来ると、整合性管理が複雑になります。常駐プロセスを介在させるモデルがそれを解決しています。

運用上の注意点とパターン

Rate Limitは通常セッションと同じ

agent view経由のバックグラウンドセッションも、Claudeのプロンプト消費 / トークン消費は通常セッションと同じです。公式ドキュメント(agent-viewのLimitations節)には「10並列で動かすと10倍のusageを消費する」と明記されており、並列度に応じて利用プランのusage limitがそのまま掛かります。

公式から並列数の上限は明示されておらず、各プランのusage limitに応じて自分で調整する形になります。上位プランの方が並列度の余裕は大きい傾向ですが、具体的な並列数の指針は公式に出ていないため、実運用でusage limitが来る前に上限を肌感で測ることになります。

組織レベルでagent view全体を無効化したい場合は、disableAgentView 設定でOFFにできます。

Sleep / Shutdownで停止する制約

agent viewのsupervisorはローカル実行のため、PCがスリープ / シャットダウンすると全バックグラウンドセッションが停止します。再起動後は:

claude respawn --all

で一括復旧できますが、長時間タスクが中断されたままになる可能性があります。「常時稼働させたい」要件には、agent viewではなくClaude Code Routines(Cloudflareのクラウド側で動く)を組み合わせる必要があります。

Worktreeの自動隔離と削除

agent viewのバックグラウンドセッションは、ファイル編集時に自動的に.claude/worktrees/<id>配下に隔離されます。これは並列セッションが互いの作業を踏み合うのを防ぐ仕組みで、subagent frontmatterの isolation: worktree 指定でも明示的に有効化できます。

隔離されたworktreeはセッション削除と同時に消えます(コスト効率優先の設計)。注意点として:

セッションを削除する前に、worktree内の作業がmerge / push済みか確認すること

セッション内で書いたコードを残したい場合は、必ず先にmainにマージ(またはPR作成)してからclaude rm <id>を実行してください。

subagents / agent teams / /loopとの使い分け

agent viewは「複数セッションを束ねるUI」ですが、Claude Codeには他にも「複数のClaudeを動かす」仕組みがいくつかあり、それぞれ役割が違います。

agent viewが「複数のターミナルを一覧化する箱」なら、subagentsとagent teamsは「1セッション内で複数のClaudeをオーケストレーションする仕掛け」です。両者を組み合わせると、「複数の独立セッション × 各セッション内のサブエージェント協調」という二階層の並列が実現できます。

「機能AのテストとレビューとリファクタリングをそれぞれClaudeに分担させたい」場合はagent view、「1つのセッション内でレビュー専任サブエージェントに委譲したい」場合はsubagents、「同じコードベースで定期的にリント実行」のような単純反復は /loop という棲み分けです。

「複数本同時運用が前提」へのシフト

agent viewとper-user supervisorの登場は、Claude Codeが「1人1セッション」から「1人複数セッション」前提のツールに変わったことを示します。これは大きな思想転換です。

これまでは「1つのターミナルで1つのClaudeセッション」が標準的な使い方でしたが、agent view以降は「ブラウザのタブのようにセッションを並列管理」が標準モデルになります。1セッションで全部やる重い対話から、目的別に分解した複数の軽いセッションへ。

この変化は、関連する3つの機能と合わせて読むと立体的に見えます。

• Claude Code Routines:クラウド側で常時動く「予定されたClaude」
• /goalコマンド:各セッションに「達成条件」を渡して自走させる
• agent view(本記事):複数のローカルセッションを一覧で管理する

これら3つで、「クラウドで予定実行 + ローカルで複数並走 + 各セッションは自律完了」という運用パターンが揃いました。Claude Codeは単発のコーディング支援ツールから、複数エージェントを並走させるオーケストレーション基盤に近づいています。

まとめ

agent viewはClaude Code v2.1.139で導入されたResearch Preview機能で、複数バックグラウンドセッションの一覧管理をper-user supervisor設計で実現します。

/goalやRoutinesと組み合わせると、「複数セッションを並列に動かし、各々に達成条件を渡し、クラウドでも常時実行する」という運用が現実的になります。Research PreviewのためUIは変わりうるので、組織導入は安定化を待つ判断もあります。

更新はclaude updateで取得でき、claude --versionで2.1.139以降であればclaude agentsが使えます。