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(完了)

フィルタも豊富:

キーバインド

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

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

Shellからの操作

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

claude attach <id>     # 特定セッションにアタッチ
claude logs <id>       # ログを表示
claude stop <id>       # 停止
claude respawn <id>    # 停止セッションを再起動
claude rm <id>         # 削除
claude --bg "..."      # 新規 background セッションを起動

これはスクリプト / 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の扱い

.claude/worktrees/<id> 配下に作られるworktreeは、セッション削除と同時に消えます。これはagent viewの挙動として正しい(コスト効率の観点)ですが、注意点として:

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

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

/loopとの使い分け

agent viewと/loopは補完関係です。

「機能AのテストとレビューとリファクタリングをそれぞれClaudeに分担させたい」場合はagent view、「同じコードベースで定期的にリント実行」のような繰り返しは /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が使えます。