この変更が変えているのは、worktree自体の挙動なのか、それとも入力方法だけなのか?
変わったのは入力方法だけで、worktreeが作成された後の挙動はまったく同じだ。番号+#のみを貼り付けようと、GitHubのプルリクエストURLを貼り付けようと、GitLabのマージリクエストURLを貼り付けようと、Claude Codeは最終的に同じ核心情報——これが何番の変更リクエストなのか——を解析し、同じロジックに従って、あなたのリポジトリのoriginリモートから対応するheadコミットを取得し、同じ命名規則のディレクトリ(.claude/worktrees/pr-<番号>)の下に作成する。
言い換えれば、今回のアップデートが解決しているのは「Claude Codeにどの変更が欲しいかをどのフォーマットで伝えるか」という入力層の問題であって、worktreeの作成・隔離・管理の核心ロジックを変えているわけではない——その仕組み全体は、このアップデートの前後で変わっていない。
なぜ「対応する入力フォーマットが増えた」という小さな変更が、わざわざ取り上げる価値があるのか?
この機能単体を見れば、確かに手動変換のステップが一つ省けるだけで、影響範囲は限定的だ。しかしこれは、より広いパターンを反映している。Claude Codeの多くの機能は、もともとGitHubをデフォルトの対象として設計されており、GitLabへの対応は後から追加される形になることが多い——この順序は、機能自体が両方に存在していても、特定の細部でGitLabユーザーがGitHubユーザーよりも余計な遠回りをする羽目になることをしばしば意味する。
今回の--worktreeのアップデートは、その特定のギャップを埋めるものだ。GitLabユーザーは今や、GitHubユーザーとまったく対等な方法(URLを直接貼り付ける)でこの機能を使えるようになり、頭の中でフォーマット変換をする必要がなくなった。両方のプラットフォームを使う人が混在するチームにとって、この「入力方法の対等化」は、単一機能そのものの価値以上に意味を持つ場合がある。なぜならそれが減らしているのは、チーム内で異なるツールの慣習によって生じるコミュニケーションコストだからだ。
URLを貼り付けた後、Claude Codeは実際にどうやって対応する変更を取得するのか?この過程で何か設定が必要か?
追加の設定は不要で、取得プロセス全体は自動だ。Claude CodeはURLから「番号」という一つの数字だけを読み取る。実際に変更内容を取得する際は、常にあなたのリポジトリで既に設定済みのoriginリモートを通じて行われ、URLに書かれているドメインに別途接続することはない——これは、たとえコピーして貼り付けたURLがリポジトリの実際のリモート設定と完全には一致していなくても、番号さえ正しければ取得は成功することを意味する。システムが信頼しているのはoriginの設定であって、URL自体のドメインではないからだ。
取得パスはoriginが指しているホストの種類に応じて自動的に判断される。GitHub Enterprise、セルフホストのGitLab、あるいはその他の種類のホストの場合、システムはまずpull/<番号>/headというパスを試み、失敗すればmerge-requests/<番号>/headにフォールバックする。この「一方を試し、失敗すればもう一方を試す」という仕組みは今回のアップデートで初めて追加されたものだ。2.1.233以前は、システムは常にpull/<番号>/headという単一のパスしか試みなかった。
もしチームがGitHubとGitLabの両方を使っている場合、実際にこのアップデートをどう活かしてチームの作業習慣を調整すればよいのか?
最も直接的な調整は、2つのプラットフォームごとに「Claude Codeにどの変更を処理してほしいかをどう伝えるか」という別々の操作説明を維持する必要がなくなることだ。これまでは、GitLabユーザーに対して「まずMRページで番号を探し、それから#+その番号を使う」という追加の手順を特別に説明しなければならなかったかもしれない。今では「MRまたはPRのURLを--worktreeに直接貼り付ける」という一言に統一でき、相手がどちらのプラットフォームを使っているかを区別する必要がない。
より細かい点として、チームがセルフホストのGitLabやGitHub Enterpriseを運用している場合、実際の取得時にシステムはまずpull/<番号>/headを試み、失敗した場合のみmerge-requests/<番号>/headにフォールバックする。もし自社のセルフホスト環境自体のパス命名ロジックが特殊な場合(例えばリバースプロキシを経由している、またはAPIパスがカスタマイズされている場合)、取得に失敗した際は、これら2つの標準パスのいずれもあなたの環境に合っていないのではないかをまず確認する価値がある。--worktreeという機能自体が壊れていると即座に決めつけるのではなく。
Claude Codeのバージョン2.1.233(2026年8月のアップデート群の一部)は、--worktreeに小さいが実用的な変更を加えた。今では、対応する番号を自分で調べたり、フォーマットを手動で変換したりすることなく、GitLabのマージリクエストのURLを直接貼り付けられるようになった。この記事では、この機能が実際にどう動作するのか、そして従来の挙動と何が違うのかをまとめる。
--worktreeを使うと、メインの作業ディレクトリに触れることなく、特定のブランチ用に独立したチェックアウトを作成できる。よくあるシナリオは、機能ブランチで作業している最中に、あるPRやMRの内容を急に確認する必要が出てきたが、今やっている作業を中断したくないし、現在コミットしていない変更をstashしたくもない、という場合だ。worktreeを使えば、独立したディレクトリを新たに開き、そこでClaude Codeに別の作業を任せることができ、両者が互いに干渉することはない。
今回のアップデート以前、--worktreeは2種類の入力しか受け付けていなかった。#で始まる番号(例えば#123)か、GitHub形式のプルリクエストURLだ。もしあなたのプロジェクトがGitLabを使っていて、worktree経由でマージリクエストを処理したい場合、まず自分でMRページから対応する番号を見つけ、それから#+番号の形式を手動で組み立ててClaude Codeに貼り付ける必要があった——変換の手間が一つ増えるうえ、チーム内にGitHubを使う人とGitLabを使う人が混在している場合、この入力フォーマットの非対称性は混乱を招きやすかった。
今ではhttps://gitlab.com/group/repo/-/merge_requests/123のような完全なURLを--worktreeに直接貼り付けるだけで、Claude Codeが自分でURLから番号部分を解析してくれる。事前の変換は不要だ。実際に変更内容を取得する際、Claude Codeは常にあなたのリポジトリのoriginリモートからその変更のheadコミットを取得し、originが指しているホストの種類に応じて取得パスを決定する。GitHubまたはセルフホストのGitLabの場合、システはまずpull/<番号>/headを試み、失敗すればmerge-requests/<番号>/headにフォールバックする。作成されるworktreeは常に.claude/worktrees/pr-<番号>というパスに保存される。GitHubのURL、GitLabのURL、あるいは単なる番号のいずれを貼り付けても、生成されるディレクトリの命名ロジックは一貫している。
URL内の#記号はほとんどのシェル環境でコメントの開始として扱われるため、番号+#の形式(例えば#123)を直接使う場合は、引数全体を引用符で囲むことを忘れないようにしよう。そうしないと、シェルが#以降の内容を丸ごと無視してしまう可能性がある。また、worktreeは本質的に新規のチェックアウトであるため、メインの作業ディレクトリでgitに追跡されていないファイル(.envや.env.localといったローカルの設定ファイルなど)は、新しく作成されたworktreeに自動的には現れない。タスクでこれらのファイルが必要な場合は、自分で手動でコピーする必要がある。