Claude Codeの裏側：supervisorデーモンが変えるエージェント開発の常識

深夜のデバッグ作業中、重いタスクを走らせたままターミナルを閉じてしまい、翌朝になって「あの処理は完了したのか？」と冷や汗をかいた経験は、エンジニアなら誰しも一度はあるはずだ。これまで我々が使ってきたCLIツールは、基本的にターミナルのプロセスと運命共同体だった。しかし、Claude Code v2.1.139以降に実装された「supervisorデーモン」は、この常識を根本から覆そうとしている。これは単なるバックグラウンド実行機能ではない。tmuxやGNU screenが端末の表示を維持するのに対し、Claude Codeのsupervisorは「セッションというデータそのもの」をOSのプロセスから切り離し、永続化する仕組みなのだ。

具体的には、claude daemon runによって起動するこのデーモンは、ユーザー単位で常駐し、~/.claude/daemon/roster.jsonという台帳を通じてすべてのセッションを管理する。特筆すべきは、このデーモンが「オンデマンド」で起動し、管理対象がなくなれば静かに終了するという、極めてモダンなリソース管理を行っている点だ。ターミナルを閉じても、PCをスリープさせても、あるいはClaude Codeのバイナリをアップデートしても、セッションは生き残る。これは、プロセスが死んでもtranscript（会話履歴）と状態台帳さえあれば、いつでも新しいプロセスを立ち上げて続きから再開できるという、エージェントOSとしての強固な設計思想の現れである。

我々エンジニアが注意すべきは、CLIの入力欄が空のときに押す「←」キーの挙動だ。これは単なるカーソル移動ではなく、現在のセッションをバックグラウンドへ追い出し、Agent viewへ遷移させるトリガーとなっている。意図せずこの操作を行ってしまうと、メインの作業がバックグラウンドへ隠れてしまい、混乱を招く。もしこの挙動が煩わしいのであれば、/configからleftArrowOpensAgentsをfalseに設定することを強く推奨する。この小さな設定変更一つが、日々の開発体験における「意図しないセッションの迷子」を防ぐための重要な処方箋となるだろう。

Agent viewは、単なる一覧画面ではない。これはsupervisorデーモンという「インフラ」を操作するためのコントロールパネルである。claude agentsコマンドで呼び出されるこの画面では、現在実行中の全セッションの状態を俯瞰できる。ここで重要なのは、セッションの「状態」がタスクの進捗（Working, Needs input, Completedなど）と、プロセスの生死という2つの軸で管理されている点だ。特に興味深いのは、プロセスが終了していても、transcriptさえ残っていれば、ユーザーが話しかけるだけで即座にプロセスが蘇生する仕組みである。これは、メモリを食いつぶす常駐プロセスを極限まで減らしつつ、必要な時にだけ計算リソースを割り当てるという、極めて効率的なエージェント運用モデルを提示している。

また、/bgや/forkといったコマンドを使い分けることで、作業の並列化が劇的に加速する。/bgは現在のセッションをそのままバックグラウンドへ移す「退避」であり、/forkは現在の文脈をコピーして新しいセッションを送り出す「並列化」だ。これらを駆使することで、例えば「重いテストを走らせながら、別の機能の実装を並行して進める」といったマルチタスクが、ターミナルのペイン分割に依存することなく実現できる。以下に、バックグラウンドセッションを扱うための主要な操作を整理した。

この設計において、gitリポジトリ内では.claude/worktrees/配下に隔離されるという仕様も非常に賢い。これにより、複数のセッションが同じファイルシステムを書き換えて競合するリスクを、gitのworktree機能を利用して物理的に回避している。ただし、Bash経由の書き込みなど一部の操作では隔離が効かないケースもあるため、エンジニアとしては「どのツールがどのレイヤーで動いているか」を意識する必要がある。この「隔離の境界線」を理解しているか否かが、複雑なエージェント運用における障害の有無を分けることになるだろう。

Claude Codeが目指しているのは、単なるAIチャットボットではない。それは、ターミナルという古き良きインターフェースを「エージェントの実行基盤」へと昇華させる試みだ。supervisorデーモンとAgent viewの導入により、我々は「プロセスを管理する」という低レイヤーな作業から解放され、「セッションという文脈を管理する」という高レイヤーな作業へとシフトしつつある。しかし、ここで我々が直面するのは、AIエージェントが自律的に動き回る環境における「可観測性の欠如」という新たな課題である。バックグラウンドで何が起きているのか、どのセッションがどのリソースを消費しているのか。これらを完全に把握しきれないまま、エージェントにタスクを委譲し続けることは、一種のブラックボックス化を許容することに他ならない。

明日から我々が取るべき対策は明確だ。まずは、自身の開発フローにおいて「どのタスクをバックグラウンドに逃がすべきか」という基準を言語化すること。そして、Agent viewを単なる「終了待ちのリスト」としてではなく、エージェントの活動を監視する「ダッシュボード」として積極的に活用することだ。セッションの同一性をsessionIdで管理し、プロセスを使い捨てるという設計は、クラウドネイティブなマイクロサービスアーキテクチャの思想をローカル開発環境に持ち込んだものと言える。このパラダイムシフトを理解し、使いこなせるエンジニアだけが、AIエージェントを「ただのツール」から「真のパートナー」へと昇格させることができるのではないだろうか。

最後に、我々自身に問いかけたい。AIがバックグラウンドで自律的にコードを書き、テストを回し、PRを作成する世界において、人間であるエンジニアの「手触り感」はどこまで残るべきなのか。セッションを管理するデーモンが賢くなればなるほど、我々は「何が起きているか」を把握する努力を怠るようになるのではないか。技術の抽象化が進む中で、我々が守るべき「エンジニアとしての直感」とは一体何なのか。この問いに対する答えを、日々のエージェント運用の中で見つけ出さなければならない。