claude agents実測｜Windowsで動く機能と限界

Claude Codeのセッションを複数走らせたい。でも公式の更新履歴を読んでも、Windowsで何が動いて何が動かないのかが書いていない。

以前/goalで完了条件を渡してAIに自走させる記事を書いたとき、claude agents（エージェントビュー）については「筆者はまだ動かしていない」と正直に断って公式ドキュメントの整理だけに留めた。今回それを実際に手元で回した。

結論から言うと、主要な機能はWindowsでも動く。ただし2つだけ完全に使えないものがあり、1つは後始末が手作業になる。

2026年8月15日にWindows 11で検証した記録をそのまま書く。検証中にClaude Codeがv2.1.231からv2.1.233へ更新されたので、どちらのバージョンで確認したかも都度書く。

検証した環境と、結論の一覧

まず全体像を出す。

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 からは消えているのに、ディレクトリの実体とブランチだけが残る、という中途半端な状態になる。

結局こうやって片付けた。

4手かかった。macOSやLinuxならファイルロックがないぶん git worktree remove 一発で終わるはずの作業だ。

使えなかった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の但し書きだ。

ムラサキ

Changelogに「(macOS and Linux)」と小さく書いてある行を見落とすと、動かない機能を延々と試すことになります。

もうひとつはバージョン。セッション名を @ でメンションする機能は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）

主要な機能は動く。Windowsで使えないのは2つだけ

主要な機能は動く。claude agents --jsonでセッションを横断で一望でき（対話画面のほうはバックグラウンドセッション専用）、--bgで入力待ちのまま枠を立てられる。-w 名前 --bg はworktree作成と隔離セッション起動が1コマンドで終わるので、本体を汚さず並行作業したいときに素直に使える。

ただしWindowsだけworktreeの後始末が手作業になる。ファイルロックで git worktree remove が失敗し、4手に分けて片付ける必要があった。使い捨てる運用にするならスクリプト化しておいたほうがいい。

できないことははっきりしている。セッション間メッセージングとtmux連携はmacOS/Linux限定で、Windowsからは触れない。更新履歴の「(macOS and Linux)」という但し書きを読み飛ばすと、動かないものを試し続けることになる。

セッションを増やす前に、まずclaude agents --jsonを一度叩いてみるのがいい。放置していたセッションが何本生きているか分かる。筆者はそれで1週間前のセッションを見つけた。

ムラサキ

SE歴20年 · 金融系システム開発課長 · 週末起業1年目

システムエンジニア歴20年。金融系システム開発の課長として勤務する傍ら、AIと副業の最前線を実践レポート。Claude Code Max 5xプランを日常業務・副業開発に活用中。一次情報と実測値にこだわった記事を発信。

20 YRS SE

8 MOS 副業

55 ARTICLES

プロフィール →