Claude Code 2.1で公式に出てきた Agent View について、ダッシュボード機能と並列実行UIばかりが取り上げられているが、運用に踏み込むと別の論点が出てくる。1つはバックグラウンドセッションが起動マシン上でしか動かないという「ローカル前提」の制約、もう1つは claude agents コマンドに追加された一連のオプションフラグだ。本稿では、この2点を実機ベースで整理する。
バックグラウンドセッションの「ローカル前提」が地味に効く
公式が明記している、Agent View運用上のもう1つの制約がある。バックグラウンドセッションは、起動したMac/PC上で走る。スリープしたら止まる。シャットダウンしたら消える。
これはクラウドエージェントを想像していた人ほど引っかかる仕様だ。筆者も最初、寝る前に5本仕込んでスリープに入った。朝起きてダッシュボードを開いたら、全部止まっていた。
サーバー側で常時走り続けているわけではなく、あくまでローカル端末上のプロセスとしてバックグラウンド化されているだけ、という理解が必要になる。
「電源は付けっぱなし、スリープなし」の前提が要る
回避策は実質3つある。1つ目は、Mac側で caffeinate -d を叩いてディスプレイスリープを抑止する方法。コマンド1発で済むのが利点だ。2つ目は、システム設定でスリープを完全に切ってしまう方法。3つ目は、外部の常時稼働サーバーにClaude Code環境を構築する方法だが、これは別の依存関係が増える。
筆者は2つ目を選んでいる。電気代は月で数十円増える計算だが、Agent Viewでの体験そのものは段違いに安定する。常駐型のエージェント運用を志向するなら、最初の段階で電源管理の運用方針を決めておいたほうがいい。
claude agents のオプション引数追加が、運用パターンを広げている
Agent View本体ばかりが注目を集めているが、claude agents コマンドに追加された一連のフラグも、見逃せない変更だ。具体的には --add-dir、--settings、--mcp-config、--plugin-dir、--permission-mode、--model、--effort、--dangerously-skip-permissions が追加された。
これが何を可能にするかと言うと、バックグラウンドで起動するセッションを「主開発セッションとは別の設定」で動かせる、という点に尽きる。たとえばメインのセッションは Sonnet 4.7 で動かしつつ、バックの自動テスト修正担当だけを軽量モデル＋権限制限モードで走らせる、といった構成が公式に組めるようになった。
「別人格を裏で常駐させる」発想が公式機能化された
筆者の現運用だと、ドキュメント担当セッションは --effort low --permission-mode strict で走らせている。テスト修正担当は逆に少し権限を緩めに、ドキュメント担当は権限を絞って、というふうに役割ごとに人格を分けるイメージだ。
これは「権限を絞った別人格」を裏で常駐させる発想で、Vim時代のプラグイン分割の延長線上にある、と筆者は捉えている。エディタの設定ファイルを役割ごとに分けて読み込む発想に近い。
特に --permission-mode strict と --effort low の組み合わせは、ドキュメント整形・コード読解レポート生成・テスト出力サマリといった「壊さない読み取り中心の作業」を任せる用途と相性がいい。Opus 4.7をメインで走らせつつ、サブを軽量モデルに振り分けることで、クオータ消費のバランスも取りやすくなる。
推奨する claude agents の使い分け
筆者が試した範囲で、運用テンプレートとして固まりつつあるのはこうした構成だ。
- 主開発セッションは対話モード、フルモデル、権限通常
- テスト修正担当はバックグラウンド、
--effort lowで軽量モデル、権限通常 - ドキュメント担当はバックグラウンド、
--effort low --permission-mode strictで書き込み範囲を限定 - MCP構成が必要な場合は
--mcp-configでセッションごとに別ファイルを指定
--add-dir を使うと、そのセッションがアクセスできるディレクトリを限定できるので、サブセッションを「特定のサブツリーだけを触る作業員」として運用することもできる。モノレポで複数パッケージを並行管理しているチームには、このフラグの効果は大きい。
結論: 「ローカル前提」を受け入れた上で、フラグで人格を分ける運用が現実解
Agent ViewとAgent CLIフラグの組み合わせは、単体で評価するとそれぞれ地味な変更に見える。だが2つを合わせて運用すると、「自分のマシン上で、役割ごとに別設定のClaude Codeを並列起動する」という構図が、ようやく公式機能だけで素直に組めるようになった。
ローカル前提という制約は、クラウド常駐型のエージェントを期待していた層には不満が残るだろう。ただし、現状の料金体系とセキュリティモデルを考えると、ローカル実行の選択は妥当だ。電源管理を運用方針として明文化した上で、claude agents のフラグで人格を分けるアプローチを取れば、Agent Viewの実用度はもう一段上がる。
次に注目したいのは、これらのフラグ群がプロジェクトごとの設定ファイル（.claude/settings.json 系）にどう統合されていくかだ。CLIフラグで毎回指定する運用はいずれ崩れるので、設定ファイル側にプロファイルとして書ける仕組みが整うと、Agent Viewの完成度は一気に上がるはずだ。
