Claude Code autofix-prでPRのCI失敗を自動修正する
/autofix-prはPRのCI失敗とレビューコメントを監視し、クラウドセッションが自動で修正を押し返す仕組みです。動かないときの症状別の切り分けもまとめます。
/autofix-prとは
/autofix-pr は、いま作業しているブランチのPull Requestを見張り続けるクラウドセッションを立ち上げるコマンドです。CIのチェックが落ちたり、レビュアーがコメントを残したりすると、Claude Code on the webのセッションが調査し、確信を持てる修正であればプッシュまで行います。ターミナルからPRを離れずに監視を仕込めるのが利点です。
利用にはGitHub CLI(gh)とClaude Code on the webへのアクセスが必要です。実行するとチェックアウト中のブランチから gh pr view で開いているPRを検出します。別のPRを監視したいときは、そのブランチへ先に切り替えます。
/autofix-pr引数なしだと、CIの失敗とレビューコメントのすべてを直すようクラウドセッションに指示されます。プロンプトを渡すと対象を絞れます。
/autofix-pr only fix lint and type errors起動前に通るべき3つの関門
auto-fixは、コマンドを打つだけでは動きません。手元のCLI、GitHubとの接続、クラウドの実行環境という3か所を順に通ります。
/autofix-prが動き出すまで
- 1
ターミナルでPRを検出する
PRのブランチにいて、
gh pr viewが開いているPRを返すことが前提です。失敗すると、v2.1.273以降はgh自身のエラー(サインイン・SAML・レート制限など)がそのまま表示されます。 - 2
GitHubとの接続を確かめる
対象リポジトリにClaude GitHub Appが入っていて、Claudeアカウントに連携済みのGitHubアカウントがあることが条件です。無いと、PRのイベント通知(webhook)を設定できなかった理由が表示されます。
- 3
クラウド環境でセッションが走る
セッションは、ネットワーク範囲・環境変数・セットアップスクリプトを決める「クラウド環境」の上で動きます。CIの実行に外部ネットワークが要るなら、環境側のアクセスレベルを先に確かめます。
クラウド環境がまだ無い場合は、初回のオンボーディングで「Default」環境が用意され、ネットワークアクセスの水準は「Trusted」になります。同じ環境設定は、Webやターミナルに加えてClaude Tag、routines、モバイルとデスクトップのアプリのどこから起動しても共通で使われます。許可の範囲を変えたいときは、クラウド環境の設定で調整します。
手元のバージョンはv2.1.287で、claude --help の出力に autofix という文字列はありませんでした。/autofix-pr はスラッシュコマンドで、CLIのサブコマンドやフラグとしては提供されていません。同じ --help には --cloud があり、クラウドセッションを直接作れます。ただしauto-fixを有効にする経路の一覧には含まれていません。
/autofix-pr のクラウドセッションは、バックグラウンドで走ります。v2.1.235で、/ultrareview や /autofix-pr のようなセッションが動く間のメモリとCPUの使用量が改善されました。v2.1.246では、タスク進捗の数(3/5 など)が欠けることがある不具合が直っています。
有効化できる4つの経路
auto-fixは、PRの出どころと使っているデバイスによって4通りの方法で有効にできます。
| 経路 | 操作 |
|---|---|
| クラウドセッションで作成したPR | 操作claude.ai/codeでセッションを開き、CIステータスバーの「Auto-fix」を選択 |
| ターミナル | 操作PRのブランチで /autofix-pr を実行(PRの検出・クラウドセッション起動・auto-fix有効化を1ステップで行う) |
| モバイルアプリ | 操作「このPRを監視してCI失敗やレビューコメントを直して」のように指示 |
| 既存の任意のPR | 操作セッションにPRのURLを貼り、auto-fixを頼む |
どの経路でも、対象リポジトリにClaude GitHub Appが必要です。auto-fixはPR単位のトグルで、止めるにはCIステータスバーのAuto-fixを解除するか、Claudeに「このPRの監視を止めて」と伝えます。
動かないときは症状から切り分ける
「トグルは入れたのに何も起きない」場合の原因は、公式ドキュメントと更新履歴から次のように絞れます。
| 症状 | 疑う点 |
|---|---|
gh のエラーが出て始まらない | 疑う点サインイン切れ・SAMLの認可・APIのレート制限(v2.1.273で gh のエラーがそのまま出るようになりました) |
| 「GitHub Appが未インストール」と出るが入れたはず | 疑う点v2.1.285で、インストール状況を確認し終える前に出る誤表示が修正されています。古いバージョンなら更新してから再実行 |
| GitHubアカウントが未連携という趣旨のメッセージ | 疑う点v2.1.268以降は /web-setup かWebの接続ページへの案内が出ます。連携を済ませてから再実行 |
| 「デフォルトブランチでは実行できない」と出る | 疑う点PRのブランチにいるかを確認。v2.1.161で、worktreeや別リポジトリ内でもこの文言が出る不具合が直されています |
| クラウドセッションが認証エラーで止まる | 疑う点組織のIPアローリスト(詳細は「見落としやすい制限」) |
| コンフリクトしたのに反応がない | 疑う点GitHubがコンフリクトのwebhookを送らないため、自動では拾われません(後述) |
クラウドセッションそのものが立ち上がらない場合もあります。サードパーティのプロバイダー設定が有効だと、Cloud sessions aren't available with <provider> と表示されます。CLAUDE_CODE_USE_BEDROCK などを外し、claude auth login でAnthropicアカウントにサインインし直します。APIキー認証なら、/login でclaude.aiアカウントに切り替えます。組織の allow_remote_sessions ポリシーがオフのときは、Cloud sessions are disabled by your organization's policy と出ます。この場合は管理者に有効化を頼みます。
GitHub Appの導入と /web-setup の関係は混同しやすい点です。次の比較のとおり、二つは別の接続方法です。
GitHub接続の2方式
Claude GitHub App
ブラウザのオンボーディングで認可します。公開リポジトリのほか、Appを入れた非公開リポジトリに届きます。
/web-setup
ローカルの gh トークンをClaudeアカウントに送る方式です。gh が触れるリポジトリならAppの有無を問いません。
TeamとEnterpriseでは、Quick web setupの設定が既定でオフです。オフの間は /web-setup 自体が隠れます。Ownerが管理設定の「Quick web setup」トグルでオンにします。オンにすると、ブラウザのオンボーディングでApp導入の案内が出なくなります。メンバーがAppを入れないまま進めるので、auto-fixを使うリポジトリには別途Appを入れます。Zero Data Retentionを有効にした組織は、/web-setup を含むクラウドセッション機能を使えません。
利用できるプラン
クラウドセッションはPro・Max・Teamプランと、premium seatまたはChat + Claude Code seatを持つEnterpriseユーザーが使えます。auto-fixもこのクラウドセッションの機能なので、同じ範囲が前提です。
CIとレビューコメントへの反応のしかた
auto-fixが有効な間、ClaudeはそのPRのGitHubイベント(新しいレビューコメントやCIチェックの失敗を含む)を受け取ります。イベントごとの対応は3通りです。
- 確信のある修正: それまでの指示と矛盾しなければ、変更を加えてプッシュし、セッション内で何をしたか説明する
- 曖昧な依頼: コメントが複数の解釈を許す、あるいはアーキテクチャに関わる内容なら、実行前に確認を求める
- 重複・対応不要: その旨をセッションに記録して先へ進む
レビューコメントのスレッドへ返信することもあります。返信はあなたのGitHubアカウント名で投稿されますが、Claude Codeが書いたと分かるラベルが付きます。
ローカルのバックグラウンドセッションは、Claude Code v2.1.221でPR作成が条件付きになりました。auto-fixのクラウドセッションに同じ仕様が当てはまるとは、公式の説明からは確認できません。PRへのプッシュの流れは、セッションの会話に残る説明で追うのが確実です。
auto-fixが加えた変更を確認する
auto-fixが動いているセッションは、サイドバーの一覧から開けます。各セッションには +42 -18 のような追加・削除行数が出ます。選ぶと差分ビューが開き、特定の行へのインラインコメントを次のメッセージと一緒にClaudeへ送れます。この差分は生のgit blobから計算されるので、リポジトリの diff ドライバーや textconv フィルターは効きません。差分の比較先は既定ではセッションのベースブランチで、「Compare against」から別のブランチへ切り替えられます。バイナリや整形前提のファイルは、見え方が手元の git diff と違う場合があります。
セッションを共有するときの可視性は、アカウントの種類で選択肢が違います。TeamとEnterpriseは「Private」と「Team」で、Teamにすると同じ組織のメンバーが見られます。MaxとProは「Private」と「Public」で、Publicだとclaude.aiにログインしている誰でも見られます。非公開リポジトリのコードや資格情報がセッションに含まれることがあるため、共有前に中身を確認します。監視が終わったセッションは、アーカイブすると既定の一覧から隠せます。アーカイブ済みの一覧は、フィルターで再表示できます。ただし監視中のセッションをアーカイブすると、新しいメッセージを送れません。cloud session <id> is archived and cannot accept new messages と出たら、新しいセッションを始めます。
自動では拾えない場面と衝突しやすい自動化
GitHubはベースブランチが進んでマージコンフリクトが起きても、そのイベント用のwebhookを送りません。auto-fixはコンフリクトを自分で検知できないので、セッションを開いてClaudeにリベースを頼みます。放置すると、PRが古いベースのまま残ります。コンフリクトの通知を待たず、マージ前にPRの状態を目で確かめる習慣が安全です。
もう一つ、コメントをきっかけに動く自動化との衝突があります。AtlantisやTerraform Cloud、issue_comment で動くGitHub Actionsがその例です。Claudeがあなたの代わりに返信したコメント自体が、こうしたワークフローを起動する可能性があります。有効化の前に自動化の中身を確認します。PRコメントでデプロイや権限のある操作が走るリポジトリでは、auto-fixを使わないことも検討します。なお、GitHub Actions側にClaudeを組み込む方法はClaude CodeをGitHub Actionsに組み込むに分けて書いています。
見落としやすい制限
- レート制限は他の利用と共有: クラウドセッションは、アカウント内の他のClaude・Claude Code利用と同じレート制限を使います。複数のPRを同時に監視すれば、その分だけ消費します。クラウドVM自体への追加課金はありません
- GitHub以外には使えない: リポジトリのクローンとPR作成はGitHubが前提です。自己ホストのGitHub Enterprise ServerはTeam・Enterpriseで対応します。GitLabやBitbucketは、
CCR_FORCE_BUNDLE=1を指定するとローカルバンドルとして送れますが、結果をリモートへプッシュし返せません - IPアローリスト: 組織で有効にしていると、Anthropic管理のクラウド基盤からのAPI認証が失敗し、auto-fixのセッションも動きません。自己ホスト環境へ振り分けていれば、この制限は受けません。解除したい場合はAnthropicのサポートに連絡して、Anthropic管理サービスを除外してもらいます
まとめ
導入前に確かめることは、PRのブランチ上で gh pr view が通ること、GitHub Appが入っていること、組織にIPアローリストがないことの3点です。反応しないときはこの順に見ると原因を絞れます。マージコンフリクトだけは、自動では拾われません。