金色の配線パターンが広がる基板の接写
設計と運用

Claude Code v2.1.222の隔離バグ修正から学ぶマルチセッション設計の見直し方

目次を見る

複数の Claude Code(Anthropic 製のターミナル向け AI コーディングエージェント)セッションを並行運用しているチームに向けた内容です。

v2.1.222 では、worktree(Git のワークツリー機能。1 つのリポジトリから複数の作業ディレクトリを切り出せる仕組み)で隔離したセッションが、本来触れてはいけない main チェックアウトに対して破壊的な Git コマンドを実行できてしまう不具合が修正されました。サブエージェント(親エージェントが呼び出す子タスク実行単位)経由でも同様の問題があったと記載されています。

この修正は単なるバグフィックスではなく、エージェント実行環境をどう設計するかという非機能要件の話に直結します。以下では、隔離設計の考え方と、手元の環境がこの種のリスクにさらされていないかを確認する手順を整理します。

前提条件

作業を始める前に、次の環境を用意してください。

  • Claude Code がインストール済みであること(claude --version で確認)
  • 対象プロジェクトが Git 管理下にあること
  • 複数の worktree またはサブエージェントを使う運用、あるいは今後使う予定があること
  • ターミナル操作の基本知識(git worktree コマンドの経験があれば理解が早いです)

バージョンを確認する

まずインストール済みのバージョンを確認します。

claude --version

v2.1.222 より前のバージョンであれば、隔離まわりの修正が未適用の状態です。特に worktree を使ったマルチセッション運用をしているなら、更新を優先的に検討する価値があります。

claude update

更新後、再度 claude --version で反映を確認してください。

なぜ「隔離の破れ」がアーキテクチャ上の問題なのか

worktree 隔離は、複数のエージェントセッションが同じリポジトリの異なるブランチを同時に触っても互いに干渉しないようにする仕組みです。たとえば、セッション A が feature/login ブランチで作業し、セッション B が feature/payment ブランチで作業していても、それぞれの worktree ディレクトリが分かれていれば衝突しません。

ところが今回のバグでは、この隔離が「ファイル編集」と「Bash 実行」の両方に一貫して効いていませんでした。リリースノートには「isolation now applies to file edits and Bash in every session type」と明記されています。つまり以前は、セッション種別によっては隔離の穴があり、サブエージェントが main チェックアウトに対して git reset --hard のような破壊的操作を実行できる余地があったことになります。

これはマイクロサービス間の権限境界設計と同じ構造の問題です。サービス A がサービス B のデータストアに誤って書き込めてしまう状態を許容しないのと同様に、エージェント実行環境でも「どのセッションがどの作業ツリーに書き込めるか」という境界を明示的に保証する必要があります。信頼境界(trust boundary)が曖昧なまま並行実行させると、意図しないブランチ破壊や履歴の巻き戻りといった可用性リスクにつながります。

PreToolUse フックの権限バイパスも同種の問題

同じリリースでは、PreToolUse フック(ツール実行前に割り込んで許可・拒否を判定する仕組み)の auto-allow 設定が、バックグラウンドエージェントタスク(要約・圧縮・リネームなど)でツール制限を素通りしてしまう不具合も修正されています。

これは「メインの対話セッションでは制限が効いているのに、裏側で動く補助タスクでは効いていない」というケースです。設計判断としては、権限チェックのロジックをセッション種別ごとに個別実装するのではなく、共通のポリシーレイヤーで一元的に評価する構成が望ましいことを示唆しています。

手元の運用を点検する手順

実際に自分たちの運用が影響範囲に入っていないかを、次の手順で確認できます。

# 1. バージョン確認
claude --version

# 2. worktree の一覧を確認し、隔離対象のディレクトリを把握する
git worktree list

# 3. 各 worktree で意図しないブランチへの操作履歴がないか確認
git -C <worktree-path> reflog --all

git reflog は、意図しないリセットや強制プッシュが過去に起きていないかを遡って確認する手段です。特に main ブランチのチェックアウトに対して、身に覚えのない reset --hardcheckout の履歴がないかを見てください。

もし複数人・複数エージェントで同じリポジトリを触る運用をしているなら、次の観点でチェックリストを作ることをおすすめします。

  • worktree ごとに書き込み可能な範囲が明確に分離されているか
  • サブエージェントに与える権限が、親セッションより広くなっていないか
  • PreToolUse フックの設定が、バックグラウンドタスクにも一貫して適用されているか
  • 破壊的コマンド(git reset --hardgit push --force など)の実行前に確認ステップが入るか

動作確認の方法

修正が実際に効いているかを確かめるには、隔離されたはずの worktree からメインチェックアウトへの操作が本当にブロックされるかを試すのが確実です。

# 隔離セッション想定の worktree を作成
git worktree add ../repo-isolated feature/test-isolation

# その worktree 内で Claude Code を起動し、
# main チェックアウト側のファイルパスを明示的に操作させてみる

意図した設計であれば、隔離セッションからは main チェックアウトのパスへの書き込みや Git 操作が拒否される、あるいは警告が出るはずです。もし何のブロックもなく操作が通ってしまう場合は、バージョンが古いか、隔離設定自体が有効になっていない可能性があります。

ハマりやすいポイント

見落としやすいのが、/usage コマンドの MCP(Model Context Protocol。外部ツールをエージェントに接続する標準規格)サーバー使用量の表示です。今回の修正前は、あるターンで一度でも MCP サーバーを呼び出すと、そのターン以降の利用量まで丸ごとそのサーバーの消費として計上されていました。

コスト監視や利用量ベースのアラート設定をしているチームでは、この過大計上によって「特定の MCP サーバーが異常に高コスト」という誤った判断をしてしまう可能性があります。アップデート後は実際にそのサーバーのツール結果を消費したリクエストのみが計上されるようになったため、過去のコスト分析結果を鵜呑みにせず、アップデート後の数値で再評価することをおすすめします。

まとめ

v2.1.222 の変更点は単発のバグ修正の集まりに見えますが、根っこにあるのは「並行実行するエージェントセッション間の境界をどう保証するか」という設計課題です。

行動に移すなら、次の 3 点から始めてみてください。

  • claude --version でバージョンを確認し、古ければ claude update で更新する
  • git worktree listgit reflog で、隔離が効いていなかった期間に意図しない操作がなかったか確認する
  • PreToolUse フックやツール制限の設定が、バックグラウンドタスクを含めて一貫しているか棚卸しする

エージェントに任せる範囲が広がるほど、権限境界の設計は後回しにできない非機能要件になります。今回のリリースノートは、その境界がどこで破れやすいかを具体的に示してくれる材料として活用できます。

参考

claude-code v2.1.222

この記事について: 本記事は AI を活用して作成し、forva AI 編集部が内容を確認・監修しています。

AI 駆動開発のご相談は forva AI へ。まずはお気軽にどうぞ。