Claude Code DesktopのPR監視機能(CI status bar)を使う

Claude Code Desktopでプルリクエストを開くと、セッション画面にCIステータスバーが現れます。裏でチェック結果を取りに行くのはGitHub CLI(gh)で、失敗はバーに表示されます。バーのトグルは2つあり、Auto-fixは失敗したCIの修正、Auto-mergeは全チェック通過後のマージを担当します。

この記事は、Desktopの設定画面を操作する前に何を確かめておくかを軸にしています。見落としやすいのは、ghの認証とGitHubリポジトリ側のauto-merge設定の2点です。

使う前に確かめておくこと

PR監視は、手元のマシンにGitHub CLIが入っていて、認証済みであることが前提です。未インストールのときは、初めてPRを作ろうとした時点でDesktopがインストールを促します。

認証が切れていないかは、ターミナルでgh auth statusを実行すると分かります。ghのヘルプ(v2.90.0で確認)には、認証に問題があるアカウントがあるとこのコマンドは終了コード1で終わり、エラーは標準エラー出力に出ると書かれています。--jsonを付けた場合は、認証に問題があっても終了コードは常に0です。スクリプトで判定するときは注意が必要です。

手順

PR監視を使い始める前の確認

1. 1

   ghを入れて認証する

   前のセクションのgh auth statusで確かめます。

2. 2

   リポジトリでauto-mergeを許可する

   Auto-mergeを使うなら、リポジトリのSettings → Generalの「Pull Requests」にあるAllow auto-mergeをオンにします。ここがオフだと、Claudeはマージできません。Auto-fixだけなら不要です。

3. 3

   PRを開いてバーを出す

   Claudeに作らせても、自分で開いても構いません。CIステータスバーはPRを開いたあとに現れます。

4. 4

   バーのトグルで挙動を選ぶ

   Auto-fixとAuto-mergeは、どちらもこのバーの上で切り替えます。

CIステータスバーでは何が起きるか

Claude CodeはPRを開いたあと、ghでチェック結果をポーリングし、失敗を画面に出します。CIが終わるとデスクトップ通知も届きます。バーはセッションに紐づくので、別々のPRを別セッションで開いていれば、サイドバーで切り替えるだけでPRごとの状況を見比べられます。

変更そのものは、PRにする前にdiff viewでレビューしておくのが公式の流れです。diff viewで中身を見てからPRにし、バーでCIを待つ順番になります。この機能がDesktopとCLIのどちらに寄った強みなのかは、DesktopとCLIの使い分けで比べています。

Auto-fixとAuto-mergeの違い

2つのトグルは目的も前提も別物です。役割を分けて考えると迷いません。

くらべる

2つのトグルの役割

失敗したら直す

Auto-fix

CIが落ちたとき、Claudeが失敗の出力を読み、直しながら繰り返します。ドキュメントに前提条件の記載はありません。

通ったら閉じる

Auto-merge

全チェックが通るとClaudeがPRをマージします。方式はsquashです。GitHub側の設定が前提になります。

マージ方式がsquashなので、コミット履歴をマージコミットやリベースの形で残したいリポジトリでは、Auto-mergeを使わずに手動でマージする運用になります。

GitHub側のauto-merge設定で知っておきたいこと

GitHubのドキュメントには、Desktopの記述だけでは分からない条件が書かれています。

• 手順は、リポジトリのトップページでSettings、Generalの順に開き、ページ下部の「Pull Requests」でAllow auto-mergeを選ぶか外す。
• 自動マージのオプションが表示されるのは、すぐにはマージできないPRだけ。たとえばブランチ保護で「Require pull request reviews before merging」が有効で、条件が未達の場合。「Require status checks to pass before merging」でも同じ。
• 書き込み権限のない人がauto-mergeを有効にしたPRへpushすると、そのPRのauto-mergeは無効になる。

2点目は、すぐにマージできる状態のPRにはauto-mergeの選択肢が出ないことを意味します。ブランチ保護やルールセットで条件を課していない場合などが当たります。DesktopのAuto-mergeを使うつもりなら、ブランチ保護の設定も合わせて見ておく必要があります。Claudeのマージ処理がこの場合にどう動くかは、ドキュメントに書かれていないため確認できていません。

3点目は、PRをチームで共有しているときに効きます。権限のないメンバーが同じブランチへpushすると、Auto-mergeが無効になるのはGitHubの仕様です。

ghでCIの状態を見るときの手がかり

CI監視はGitHub CLIの結果に基づくため、同じ情報はターミナルからも取れます。gh pr checksのヘルプ(v2.90.0で確認)から、Desktopの表示を読み解く手がかりを拾えます。

ヘルプには、次の内容が書かれています。

• --jsonを付けるとbucket欄が出て、stateをpass・fail・pending・skipping・cancelの5つに分類する
• チェックが保留中のときの終了コードは8
• --requiredで必須チェックだけに絞れる
• --watchでチェックが終わるまで監視し、--fail-fastで最初の失敗の時点で抜けられる
• 監視中の更新間隔は-i(--interval)で秒数を指定でき、既定は10秒
• --jsonで取れる項目は、bucket・completedAt・description・event・link・name・startedAt・state・workflow
• --web(-w)を付けると、チェックの詳細をブラウザーで開く

たとえば、PRのチェックが終わるまで待ち、最初の失敗で止めたいときは次のように打ちます。

引数なしなら、いま作業しているブランチのPRが対象です。

Desktopのバーに出る失敗が、必須チェックの失敗なのか任意チェックなのかを切り分けたいときは、gh pr checks --requiredを手元で実行すると差が分かります。

PRが片付いたセッションを自動で畳む

PRがマージまたはクローズされたあとは、セッションが残り続けます。Settings → Claude CodeのAuto-archive after PR merge or closeをオンにすると、その時点でセッションが自動でアーカイブされます。対象はローカルセッションのうち、すでに実行が終わっているものだけです。

自動アーカイブをオフにしたままでも、手で片付ける手段はあります。サイドバーでセッションにカーソルを合わせ、アーカイブのアイコンを押せば同じ結果です。またClaudeに「PRがマージされたセッションを片付けて」と頼めます。Claudeは、サイドバーのアイコンと同じ方法でアーカイブします。

ただしこの依頼で扱えるのは、Desktopが自分で動かすセッションに限られます。クラウドセッションや、ターミナルのCLI・VS Code拡張から始めたセッションは、Claudeからは見えません。見えるセッションも既定では直近アクティブの20件で、アーカイブ済みのものは頼まない限り除外されます。並行セッションの全体像は、Claude Code Desktopの並列セッション機能の使い方にまとめています。

複数のPRを並行して見る

セッションごとにバーが出るので、PRを複数抱えているなら、PRごとに別セッションを割り当てるのが基本です。サイドバーには、ステータス・プロジェクト・環境でセッションを絞るフィルターがあり、プロジェクト単位でグループ分けもできます。リポジトリをまたいで監視する場面でも、目的のセッションを探しやすい作りです。

同じプロジェクトで並行して進めるなら、ブランチ名の横のworktreeオプションで、セッションごとに作業コピーを分けられます。ワークツリーは既定で<project-root>/.claude/worktrees/に作られ、保存先はSettings → Claude Codeの「Worktree location」で変えられます。ブランチ名の接頭辞の設定と、gitignore済みファイルを持ち込む.worktreeincludeも用意されています。

worktreeで動かすセッションにはGitが必要です。入っていないと「Git is required」と表示されるので、インストールしてからやり直します。Claudeが現在の作業の範囲外の修正点を見つけると、チャットにタスクのチップとして提案します。チップを押すと、専用のworktreeを持つ新しいセッションでその作業が始まり、元のセッションは中断されません。

トグルは各セッションのバーにあります。セッションを切り替えるたびに、Auto-fixとAuto-mergeが意図した状態か目で確かめておくと、意図しない自動修正やマージを避けられます。

よくある落とし穴

• Auto-mergeをオンにしたのにマージされない: トグルがDesktop側にあるため、GitHub側の設定は見落としがちです。許可の有無に加えて、権限のない人のpushでauto-mergeが無効になっていないかも見ます
• CIの表示が長く動かない: 監視はghに依存しています。gh auth statusで認証状態を確認すると、原因の切り分けに使えます
• Auto-fixの修正をそのままマージする: 自動修正がどんな変更を入れたかは、マージ前にdiff viewで見ておくと安心です

ghを使うほかの選択肢

gh pr checksを自分で打つ運用と比べると、Desktopはその確認をセッション画面のバーにまとめ、Auto-fixとAuto-mergeのトグルを足したものです。同じghを使う点は変わりません。

GitHub Actions自体にClaude Codeを組み込みたいときは、Desktopのバーとは別の話になります。Claude CodeをGitHub Actionsに組み込む方法で、ワークフロー側の設定を扱っています。

よくある質問

Auto-fixが同じ失敗を繰り返すときは

ドキュメントには、繰り返し失敗したときの扱いは書かれていません。トグルをオフにして、バーに出たチェックの詳細を自分で読む選択肢があります。gh pr checksで失敗したチェック名を確かめ、ログを見に行く手もあります。

まとめ

Auto-fixは前提が少なく、Auto-mergeはGitHub側の設定に左右されます。まず小さなPRでAuto-fixだけを試し、挙動を見てからAuto-mergeを足すという進め方もあります。