Claude Code v2.1.149 — /usage の内訳と PowerShell sandbox 修正を実務で読む

結論

2026-05-22 にリリースされた Claude Code v2.1.149 で、私が一番効いたのは /usage の category breakdown（消費トークンを skill 単位で分割表示するモード）でした。skills / subagents / plugins / per-MCP-server の単位でトークン消費の内訳が出るようになり、auto-publish パイプラインの原価が初めて「どの skill が重いのか」レベルで見えるようになりました。

ほかにも PowerShell の permission bypass 修正、git worktree が sandbox を抜けていた問題の修正、GFM task list の本文 reflect、agent_id を継承する OTEL span など、運用に直接効く変更が並びます。本稿は毎日 Claude Code を回している立場から、それぞれを「実際にどう違って見えるか」で書きます。

/usage の category breakdown を auto-publish で読む

/usage は v2.1.149 から、skill / subagent / plugin / per-MCP-server の 4 軸で消費トークンの内訳を返します。これまでは「その日 / 月の総使用量と概算コスト」しか出なかったため、複数 skill を連鎖させたパイプラインの原価分解は Sentry のスパンを開いて積算する必要がありました。

4 軸の内訳とは具体的に、こうです。

• skill (slash command 単位、例: article-write / article-pick)
• subagent (Agent tool 経由で起動した子エージェント)
• plugin (mcp サーバ群を含む)
• per-MCP-server (Notion / Gmail / Playwright など個別)

私が auto-publish の 6 カテゴリ × 4 段スキル (pick / write / verify / video) を 1 週間回した結果、article-write 1 本だけで article-pick の 4 倍弱のトークンを使っていることがその場で分かりました。これは肌感とほぼ一致していて、article-pick は重複検出と JSON 書き出しで終わるのに対し、article-write は outline / draft / リトライ最大 5 回までを全部 inline で持つからです。原価の根拠が CLI 1 コマンドで取れるようになったので、今後どこを compact 化するかを決めるときの一次情報として使い始めました。

ちなみに per-MCP-server の内訳で意外だったのは、Notion MCP より Playwright MCP の方がトークン消費が大きかった点です。Playwright はスナップショットの DOM テキストを丸ごと返すぶん 1 ターンあたりのプロンプトが膨らみやすい、というのを数字で初めて納得しました。

PowerShell の permission bypass を修正した話

Windows 環境で pwsh を経由した child process が、Claude Code 側の permission policy を継承しないまま走ってしまう bug の修正が入りました。Linux / macOS では bash 経由でも子プロセスに policy が継承されていたため気付きにくい、シェル差分の見落としです。

修正前は permission-decisions hook で「Bash(rm:*) を deny」と書いていても、pwsh -c "Remove-Item ..." のような書き換えで policy を抜けられました。修正後は spawning 経路に依らず policy ID をプロセス環境変数として継承し、子プロセス側の Claude Code エージェントが起動時に同じ policy を読み込みます。Windows をメイン環境にしているチームは v2.1.149 まで上げておくのが安全です。

git worktree が sandbox を抜けていた問題

git worktree add で別ディレクトリを作って Claude Code を起動した場合、そのワークツリー側で .claude/settings.json の permissions が元 worktree のものを引かず、デフォルトの ask モードに戻ってしまう症状がありました。私自身、isolation: "worktree" で subagent を回したときに「えっ、なぜここで承認を聞かれる」と止まることが月に数回あって、原因が掴めずにいました。

v2.1.149 では worktree 起動時に親リポジトリの .git/config から worktree path を辿り、親側の .claude/settings.json を必ず一緒にロードします。私の手元では、Agent tool で isolation worktree を指定して subagent を立てたケースで、承認ダイアログがゼロになりました。再現条件が分かっていなかったぶん、修正されてから初めて「あれは bug だったのか」と気付いた、地味だけれど効く変更です。

GFM task list と agent_id-aware OTEL

GFM の task list (- [ ] / - [x]) が、/edit-file 系コマンドで checkbox を切り替えた時に source markdown へ直接 reflect されるようになりました。これまでは UI 側 state だけが変わって、次回読み込み時に元に戻る、という挙動だったので、TODO リストを Claude Code 内で運用していた人は地味に嬉しい変更です。

OTEL 側では、subagent / plugin / mcp 経由で発火する span に agent_id が継承されるようになりました。以前は「親エージェントの span にぶら下がるが、agent_id は親のまま」だったので、子 span がどの subagent から発火したかを後追いするには description を grep するしかありませんでした。v2.1.149 以降は span attributes に claude.agent_id が必ず付くので、Sentry / Honeycomb 側で agent_id="my-subagent" でフィルタが普通に効きます。

auto-publish の場合、article-write の本体 span と、その中で Agent(Explore) などで起動した子 span が別の agent_id を持つので、リトライがどの subagent でつまずいたかを後から特定しやすくなりました。これまで「リトライ 3 回目でいつも落ちる」までしか言えなかった粒度が、「リトライ 3 回目で Explore subagent が timeout した」まで言える粒度に上がります。

まとめ

v2.1.149 で実務に効くのは次の 3 つです。

1. /usage の category breakdown で skill / subagent / plugin / MCP-server 別のトークン内訳が見え、auto-publish のような複数スキル連鎖の原価が初めて分割可視化される
2. PowerShell と git worktree の permission policy 抜けが修正され、Windows / 多 worktree 運用の安全性が上がる
3. OTEL の agent_id 継承で、subagent 単位の障害追跡が grep からフィルタへ進化する

PowerShell まわりが Windows 限定なので Mac / Linux ユーザにとっては「ふーん」かもしれませんが、/usage の内訳と OTEL の agent_id だけでも上げる価値はあると私は感じました。毎日 Claude Code を回す立場だと、原価の見え方が変わるのは単純に意思決定の質が変わります。