Claude Codeのセッションを複数走らせたい。でも公式の更新履歴を読んでも、Windowsで何が動いて何が動かないのかが書いていない。
以前/goalで完了条件を渡してAIに自走させる記事を書いたとき、claude agents(エージェントビュー)については「筆者はまだ動かしていない」と正直に断って公式ドキュメントの整理だけに留めた。今回それを実際に手元で回した。
結論から言うと、主要な機能はWindowsでも動く。ただし2つだけ完全に使えないものがあり、1つは後始末が手作業になる。
SE歴20年、副業でブログとパイプライン開発を並行している筆者が、2026年8月15日にWindows 11で検証した記録をそのまま書く。検証中にClaude Codeがv2.1.231からv2.1.233へ更新されたので、どちらのバージョンで確認したかも都度書く。

Changelogに「(macOS and Linux)」と小さく書いてある行を見落とすと、動かない機能を延々と試すことになります。
検証した環境と、結論の一覧
まず全体像を出す。
| 試したこと | 結果 |
|---|---|
claude agents --json でセッション一覧 | 動く。他プロジェクトのセッションも横断で見える |
claude agents(対話画面) | 動く。ただし出るのはバックグラウンドセッションだけ |
claude --bg でバックグラウンド起動 | 動く。プロンプトを渡さなければ入力待ちで止まる |
claude -w 名前 --bg でworktree隔離+起動 | 動く。1コマンドで両方片付く |
claude stop / claude rm | 動く |
| worktreeの後始末 | Windowsだけ手作業が必要(後述) |
--tmux | 使えない(iTerm2必須=macOS専用) |
| セッション間メッセージング | 使えない(macOS/Linux限定+v2.1.232以降) |
claude agents|他プロジェクトのセッションまで見える
claude agents --json を叩くと、今マシンで生きているClaude Codeセッションが配列で返ってくる。
驚いたのは、実行したプロジェクト以外のセッションも出てくることだった。筆者の環境ではこう返ってきた。
photobank-20260808-2058(C:\work\photobank・status: busy)trading-20260811-0901(C:\work\trading・status: idle)
content-pipelineのディレクトリで叩いたのに、写真管理と株の自動売買の作業セッションが並んで出てくる。8月8日に起動したphotobankのセッションが、1週間経ってまだ生きていたことにこの時初めて気づいた。
副業だと「平日夜にちょっと触って、そのまま放置」が普通に起きる。どこに何を開きっぱなしにしたか、これで一覧できる。
対話画面と--jsonで見えるものが違う
ここが一番はまった。--json を付けずに claude agents だけで叩くと対話画面が開くのだが、さっきの2件がどこにも出てこない。
画面は「Needs input(入力待ち)」「Working(作業中)」「Completed(完了)」の3枠に分かれていて、最初に開いたときは全部ゼロだった。試しに claude --bg でバックグラウンドセッションを1本立ててから開き直すと、今度はNeeds inputに1件現れた。

同じタイミングで --json を叩くと、こちらは3件返ってくる。
"cwd": "C:\\work\\photobank", "kind": "interactive"
"cwd": "C:\\work\\trading", "kind": "interactive"
"cwd": "C:\\work\\content-pipeline", "kind": "background"
違いは kind だ。対話画面に出るのは background だけで、interactive(普通に開いているセッション)は出ない。対話画面はバックグラウンドに投げた仕事を見る管理板、--json はマシン上のセッションを全部返すコマンド、という住み分けになっている。
放置セッションを探したいなら --json のほうを使う。対話画面をいくら眺めても、開きっぱなしのターミナルは見つからない。
自分自身は一覧に出ない
--json のほうにも引っかかった点がある。このコマンドを叩いた当のセッションが一覧に出てこない。photobankとtradingは出るのに、content-pipelineで実行しているセッション自身は現れなかった。
「あれ、自分は?」となるが、他のセッションは正しく取れているので、実用上の困りごとではない。ただ「全部で何本動いているか」を数えるときは、表示された数+自分、で数える必要がある。
--bg|プロンプトを渡さなければ課金されない
claude --bg を叩くとバックグラウンドセッションが起動する。
$ claude --bg
Starting background service…
backgrounded · c5c34c81 (idle — send a prompt to start)
claude agents list sessions
claude attach c5c34c81 open in this terminal
claude logs c5c34c81 show recent output
claude stop c5c34c81 stop this session
注目すべきは (idle — send a prompt to start) の部分だ。プロンプトを渡さずに起動すると入力待ちで止まる。この状態ではモデルへのリクエストが飛ばないので、枠を確保するだけならコストがかからない。
この直後に一覧を取ると、確かに増えている。
"kind": "background",
"name": "c5c34c81",
"status": "idle",
"state": "blocked"
kind が background になり、state が blocked(入力待ち)。対話セッションとは区別して表示される。
「先に枠だけ立てておいて、あとから仕事を投げる」が成立する。何本まで並べられるかを試したいだけなら、プロンプトを投げずに確認できる。
-w|worktree作成と隔離セッション起動が1コマンド
ここが一番よかった。
$ claude -w yt-test --bg
backgrounded · 10f03d6e
これだけで、gitのworktreeを作り、その中でバックグラウンドセッションを起動するまで終わる。実行後に確認すると、確かにworktreeが増えていた。
C:/work/content-pipeline [main]
C:/work/content-pipeline/.claude/worktrees/content-pipeline-new [worktree-content-pipeline-new]
C:/work/content-pipeline/.claude/worktrees/yt-test [worktree-yt-test] locked
セッション一覧側でも、作業ディレクトリがworktree配下になっている。
"cwd": "C:\\work\\content-pipeline\\.claude\\worktrees\\yt-test",
"kind": "background",
"name": "yt-test"
つまり本体の作業ツリーを一切汚さずに、別ブランチで並行作業を走らせられる。試したい変更があるけど今の作業を止めたくない、という副業でよくある状況にそのまま使える。
どこに何ができるかを図にするとこうなる。

なお筆者はコードレビューの比較検証でも、各手法の閲覧範囲をworktreeで区切るという使い方をしている。隔離したい理由がある作業とは相性がいい。
詰まった点|Windowsだとworktreeの後始末が手作業になる
ここが今回いちばんの発見だった。
セッション自体は素直に消える。
$ claude stop c5c34c81
stopped c5c34c81
$ claude rm c5c34c81
removed c5c34c81
問題はworktreeのほうだ。セッションを消してもworktreeは locked のまま残る。そこで削除しようとすると、こうなる。
$ git worktree remove .claude/worktrees/yt-test
error: failed to delete 'C:/work/content-pipeline/.claude/worktrees/yt-test': Permission denied
Permission denied。Windowsのファイルロックだ。しかも厄介なことに、この状態でもworktreeの登録自体は消えている。git worktree list からは消えているのに、ディレクトリの実体とブランチだけが残る、という中途半端な状態になる。
結局こうやって片付けた。
- STEP1ロックを外す
git worktree unlock .claude/worktrees/yt-testを実行する。 - STEP2削除を試す
git worktree removeを実行。Permission deniedで失敗するが、登録だけは外れる。 - STEP3ディレクトリを消す
中身が空になっているので
rmdirで消える。削除前にgit statusで未コミットの変更がないことを確認しておく。 - STEP4ブランチを消す
worktree-yt-testブランチが残るのでgit branch -Dで削除する。
4手かかった。macOSやLinuxならファイルロックがないぶん git worktree remove 一発で終わるはずの作業だ。
worktreeを日常的に使い捨てるなら、この4手をシェルスクリプトかバッチにしておいたほうがいい。1回なら手でやれるが、毎回だと確実に面倒になる。
使えなかった2つ
正直に書く。試そうとしてできなかったものが2つある。
セッション間メッセージング
これが今回いちばん試したかった機能だった。セッション同士がメッセージを送り合える、というものだ。
結論、この環境では触れなかった。理由は2つ重なっている。
ひとつは対応OS。公式の更新履歴には「Claude Code sessions can now message each other, on any of your machines, with ListAgents to discover them (macOS and Linux)」と書かれている。カッコの中が対応OSの但し書きだ。
もうひとつはバージョン。セッション名を @ でメンションする機能はv2.1.232からで、検証を始めた時点はv2.1.231だった。ただし検証中にv2.1.233へ上がったので、バージョン条件のほうは途中で満たされた。それでも状況は変わらない。残っている理由は対応OSだけだ。
実際、v2.1.231の時点でセッション一覧を取得する ListAgents は手元に存在しなかった。似た名前の SendMessage は使えるが、こちらは同一セッション内のサブエージェント宛てで、別セッションには送れない。名前が近いので混同しやすい。
tmux連携
--tmux オプションは存在するが、ヘルプに「requires –worktree. Uses iTerm2」と書かれている。iTerm2はmacOS専用のターミナルなので、Windowsからは使えない。
Windowsで並行運用するときの注意点
実際に回してみて感じた注意点を挙げる。
1本ずつ止める必要がある。 claude stop はセッションIDを1つずつ指定する形式だった。まとめて止めるオプションは見当たらない。増やしすぎると片付けが面倒になる。
利用枠は共有される。 複数セッションを並列で動かせば、そのぶん消費は速くなる。筆者は以前5時間制限に当たったときの立て直し方を書いたが、並列化はその制限に早く到達する方向に効く。速さと引き換えに枠を使う、という理解でいたほうがいい。
放置セッションが積み上がる。 今回claude agents --jsonを叩いて、1週間前のセッションが生きていることに初めて気づいた。定期的に一覧を見て、不要なものをrmする運用が要る。
よくある質問(FAQ)
- QWindowsでclaude agentsは使えますか?
- A
使えます。筆者はWindows 11 / Claude Code v2.1.231〜v2.1.233で
claude agents --jsonの動作を確認しました。実行したプロジェクト以外のセッションも横断で表示されます。ただし2点注意があり、コマンドを実行しているセッション自身は一覧に出てこないこと、--jsonを付けない対話画面にはバックグラウンドセッションしか表示されないことです。
- Qバックグラウンドセッションを起動するとコストはかかりますか?
- A
プロンプトを渡さずに
claude --bgだけで起動した場合、セッションは入力待ち(state: blocked)で止まるため、モデルへのリクエストは発生しません。実際に仕事を投げた時点から消費が始まります。枠だけ先に確保しておく使い方ができます。
- Qセッション間でメッセージを送り合えますか?
- A
Windowsではできません。公式の更新履歴に「(macOS and Linux)」と対応OSが明記されています。セッション名を@でメンションする機能はv2.1.232以降ですが、筆者の環境は検証中にv2.1.233へ上がってこの条件を満たしても、使えるようにはなりませんでした。なお同じ名前の SendMessage というツールがありますが、こちらは同一セッション内のサブエージェント宛てで、別セッションには届きません。
- Qworktreeを作ったあとの片付けはどうすればいいですか?
- A
Windowsでは
git worktree removeがファイルロックで失敗します。unlock →remove(登録だけ外れる)→ディレクトリを rmdir →ブランチを削除、の4手が必要でした。削除前に必ず未コミットの変更がないか確認してください。
- Q並行運用すると利用制限に早く当たりますか?
- A
当たりやすくなります。セッションを分けても利用枠は共有されるため、並列で動かすほど消費は速くなります。作業を速く進める代わりに枠を使う、というトレードオフとして捉えるのが実態に近いです。
まとめ
Windowsで複数のClaude Codeセッションを並行運用した結果を3つに絞る。
1つ目、主要な機能は動く。claude agents --jsonでセッションを横断で一望でき(対話画面のほうはバックグラウンドセッション専用)、--bgで入力待ちのまま枠を立てられる。-w 名前 --bg はworktree作成と隔離セッション起動が1コマンドで終わるので、本体を汚さず並行作業したいときに素直に使える。
2つ目、Windowsだけworktreeの後始末が手作業になる。ファイルロックで git worktree remove が失敗し、4手に分けて片付ける必要があった。使い捨てる運用にするならスクリプト化しておいたほうがいい。
3つ目、できないことははっきりしている。セッション間メッセージングとtmux連携はmacOS/Linux限定で、Windowsからは触れない。更新履歴の「(macOS and Linux)」という但し書きを読み飛ばすと、動かないものを試し続けることになる。
セッションを増やす前に、まずclaude agents --jsonを一度叩いてみるのがいい。放置していたセッションが何本生きているか分かる。筆者はそれで1週間前のセッションを見つけた。


