Claude Code v2.1.233でGitLabのMRをworktreeとagentsビューで扱えるようになった

GitLabでマージリクエストを使っていると、「Claude CodeのworktreeはGitHubのPull Request向けなのかな」と思うことがあります。私も最初は、GitLabのMRを開いたまま別作業用のworktreeを作る方法を探していました。

Claude Code v2.1.233で、--worktreeとclaude agentsがGitLabのマージリクエストURLを認識するようになりました。大きな機能追加というより、GitHub以外を使っているチームの「ここだけ対応していない」を埋める変更です。

まずはworktreeを作る

worktreeは、今いる作業ツリーを汚さずに別のブランチをチェックアウトする仕組みです。Claude Codeでは、次のように名前を付けて起動できます。

claude --worktree review-mr-42

実際の作成場所やブランチ名は、現在のClaude CodeとGitの設定に従います。ここは「このディレクトリに必ず作られる」と決めつけない方が安全です。起動後にgit statusとgit branch --show-currentで確認しましょう。

v2.1.233の変更点は、GitLabのMR URLを--worktreeで認識できるようになったことです。たとえば次のようなURLです。

claude --worktree https://gitlab.example.com/group/project/-/merge_requests/42

URLのドメインは例です。実際には自分のGitLabインスタンスのMR URLを使います。公開リリースノートには、claude agentsの一覧でもMRが!42のように表示される、とあります。

つまり、GitHubのPRだけを特別扱いするのではなく、GitLabのMRも「レビュー対象の作業」として同じ画面で追いやすくなりました。

レビュー中のセッションが増えると、ブランチ名だけでは何の作業か分からなくなります。MR番号が!42のように出れば、GitLabの画面との照合が簡単です。

claude agents

ここで表示された番号をGitLabのMR一覧と見比べ、対象を間違えていないか確認します。AIにレビューを任せる場合ほど、作業対象の確認を省かない方がよいです。

今回の変更はGitLab対応の追加です。GitHubやBitbucketで使っていたPR URLの扱いを置き換えるものではありません。既存の運用がGitHub中心なら、すぐにコマンドを変更する必要はありません。

一方で、GitLabのリポジトリでは「URLを渡したらMRとして認識されるか」を確認する価値があります。まずは読み取りやブランチ確認だけを行い、いきなりマージや公開操作まで自動化しないのが無難です。

私なら、最初は次の順番で確認します。

worktreeは便利ですが、対象を間違えたまま作業すれば別のブランチを直してしまいます。URLを受け取った時点で、リポジトリ名・MR番号・現在のブランチを声に出して確認するくらいでちょうどよいと思います。

Claude Code v2.1.233では、GitLabのマージリクエストURLが--worktreeとclaude agentsで扱いやすくなりました。

GitLabを使っている場合は、今までURLを手で分解していた作業が少し楽になります。まずは既存のMRを1件だけ対象に、worktreeと番号表示が自分の環境でどう見えるか確認してみてください。