結論：badgeは見落とし防止に使う

Claude Code 2.1.234は、GitLab remoteと認証済みglab CLIがあるrepositoryで、MR番号とdraft・pending・greenの状態をfooterとstatuslineへ表示します。これで作業中のMRを見失いにくくなります。ただしgreenをmerge許可と同一視せず、GitLabのapproval、pipeline、discussion、target branch、最新SHAを開いて最終判断します。

読者の困りごとは、terminalで修正を続けるうちに対応MRやpipeline状態が分からなくなり、古いbranchへ追加commitしたり、draftを完成扱いしたりすることです。この記事を読むと、badgeが成立する条件を整え、表示状態ごとの次の行動を決められます。

次の行動：対象repositoryでglab auth statusとremoteを確認し、draft・pending・greenの各状態で誰が何を確認するかを一行ずつ決めてください。

公式仕様と表示条件を読む

公式changelog 2.1.234はGitLab merge request badgeをfooterとstatuslineへ追加し、GitLab remoteと認証済みglab CLIがある場合に!Nとdraft、pending、green状態を表示すると説明しています。2.1.233では--worktreeとclaude agents viewへのGitLab MR URL対応も追加されています。つまりMR表示は単独の飾りではなく、branchを分離して作業し、対応MRへ戻る導線の一部です。

公式GitLab CI/CD文書ではjobやpipelineの状態、merge request pipeline、保護branch等を別々に管理します。Claude Codeのgreen badgeだけで、必要なapproval、security scan、deployment gateの全条件を表すとは限りません。組織のmerge条件はGitLabのprotected branch、approval rule、pipeline設定を正本にします。

glabはGitLab公式CLIで、hostとtokenの認証状態を保持します。共有端末では個人tokenを置きっぱなしにせず、利用者、host、scope、失効方法を確認します。self-managed GitLabではremote hostとglabの認証先が一致していることも必要です。表示されない時にtokenを広げる前に、version、remote、branch、MR対応を順番に読みます。

draft・pending・greenを4軸で判断する

  1. draft：作業途中として扱い、要件、未完test、breaking changeをdescriptionへ残します。
  2. pending：pipeline実行中、approval待ち、discussion未解決のどれかをGitLabで特定します。
  3. green：required checksが満たされた候補と考え、最新SHAとreview範囲を再確認します。
  4. 不明・非表示：安全側へ倒し、MR URLを直接開いて状態をreadbackするまでmergeしません。

判断軸は、現在branchとMRの対応、latest commit SHA、必須pipeline、必要approvalです。badgeがgreenでも、review後に新しいcommitが追加されていれば再reviewが必要な場合があります。逆にpendingでも、単に非必須jobが待機しているだけかもしれません。色から推測せず、状態の理由へ進む導線として使います。

複数MRを並行する場合はworktreeごとにbranchを固定し、session名へticket番号を含めます。footerの!N、作業directory、branch、repository hostが一致することを作業開始時とpush前に確認します。これにより、別customerや別環境への誤pushを減らせます。

安全に設定・運用する6手順

  1. Claude Codeを2.1.234以降へ更新し、公式changelogで機能名と条件を確認します。
  2. git remote -vを読み、GitLab host、project path、push先を確認します。
  3. glab auth statusで認証hostと利用者を確認し、必要最小限のscopeにします。
  4. 現在branchに対応するMRを開き、番号、draft、target、source、latest SHAを記録します。
  5. footer/statuslineの!Nと状態を確認し、GitLab画面の状態と一致するかtestします。
  6. push前とmerge前に最新SHA、pipeline、approval、discussionをreadbackし、badgeだけで決裁しません。

企業利用では、merge担当とClaude Code利用者が異なる場合があります。作業者はbadgeでpending理由を特定し、reviewerへURL、SHA、test結果、残課題を渡します。reviewerはGitLab側の保護ruleを正本として承認します。自動化は「状態を早く見つける」部分に使い、「誰がmergeを許可するか」は変えません。

チェックリストとHOLD条件

  • 対応versionを確認した
  • remote hostを確認した
  • push URLを確認した
  • glab認証先が一致する
  • token scopeが最小
  • source branchが一致する
  • target branchが一致する
  • MR番号が一致する
  • latest SHAが一致する
  • draft理由を把握した
  • pending理由を把握した
  • required pipelineを確認した
  • approvalを確認した
  • discussionを確認した

HOLDするのは、badgeとGitLab画面が一致しない、別hostへ認証している、MRとbranchの対応が不明、pipelineの正本が分からない、review後に未確認commitが増えた場合です。tokenを再発行して症状を隠さず、versionとrepository検出から切り分けます。

作業分離の基本はClaude Code公式workflow文書、表示の入力と制限はClaude Code公式status line文書も併せて確認します。

よくある質問と次の行動

GitLabロゴがないremoteでも表示されますか？

remoteのhostとrepository検出が重要です。特殊なuserinfo付きremoteは誤検出修正も入っているため、最新版で実hostを確認します。

self-managed GitLabでも使えますか？

公式条件を満たす構成で確認します。remote hostとglab認証hostの一致、network、certificate、権限を個別にtestしてください。

statuslineを自作する必要がありますか？

MR badgeは組み込み表示です。独自status lineにはcontext等だけを載せ、同じ情報を重複させない方が読みやすくなります。

変更点は公式Claude Code changelog、CLI認証はGitLab公式glab文書、MR pipelineはGitLab公式MR pipeline文書で確認してください。

worktree分離はGitLab worktreeガイド、statusline全般はstatus lineガイド、review方法はCode Reviewガイドへつなげます。Miraigentの無料診断では、branch、MR、approval、pipelineの責任分界を整理します。