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へのアクセスが必要です。実行するとGitHubの gh pr view でチェックアウト中のブランチから開いているPRを自動検出するため、対象のPRのブランチにいることが前提になります。別のPRを監視したい場合は、そのブランチに先にチェックアウトしてから実行します。
/autofix-pr引数なしで実行すると、既定でCIの失敗とレビューコメントのすべてを修正するようクラウドセッションに指示されます。プロンプトを渡すと挙動を絞り込めます。
/autofix-pr only fix lint and type errors有効化できる4つの経路
auto-fixはPRの出どころと使っているデバイスによって、4通りの方法で有効化できます。
| 経路 | 操作 |
|---|---|
| Claude Code on the webで作成したPR | 操作CIステータスバーを開き「Auto-fix」を選択 |
| ターミナル | 操作PRのブランチで /autofix-pr を実行(gh でPRを検出し、クラウドセッションの起動とauto-fixの有効化を1ステップで行う) |
| モバイルアプリ | 操作「このPRを監視してCI失敗やレビューコメントを直して」のように指示する |
| 既存の任意のPR | 操作セッションにPRのURLを貼り、auto-fixを頼む |
いずれの方法でも、対象リポジトリにClaude GitHub Appがインストールされている必要があります。未インストールの場合はGitHub Appのページから、またはセットアップ時に案内されたタイミングでインストールします。
auto-fixはPR単位のトグルです。監視を止めるには、web版セッションのCIステータスバーでAuto-fixのトグルを解除するか、Claudeに「このPRの監視を止めて」と伝えます。
auto-fixが動く環境
auto-fixのクラウドセッションは、ネットワークアクセス・環境変数・セットアップスクリプトを制御する「クラウド環境」の上で実行されます。初回のオンボーディング時にはTrustedなネットワークアクセスを持つDefault環境が自動で用意され、同じ環境設定はweb・ターミナル・Claude Tag・routines・モバイル/デスクトップアプリのどこからクラウドセッションを起動しても共通で適用されます。CIの実行に外部ネットワークへのアクセスが必要なら、環境側のアクセスレベルを事前に確認しておきます。
GitHub Appが必須な理由
Claude Code on the webにGitHubリポジトリへのアクセスを許可する方法は2通りあります。ブラウザでのオンボーディング時にClaude GitHub Appを認可する方法と、ターミナルで /web-setup を実行してローカルの gh CLIトークンを同期する方法です。どちらの方法でもクラウドセッションはリポジトリのクローン・ブランチのプッシュができますが、auto-fixが必要とするPRのwebhook購読は、Claude GitHub Appのインストールでしか有効になりません。/web-setup だけを済ませている場合、通常のクラウドセッション作成はできてもauto-fixは有効化できない点に注意します。
Team・EnterpriseのOwnerは /web-setup 自体を管理画面のトグルで無効化できます。Zero Data Retentionを有効にしている組織は、/web-setup を含むクラウドセッション機能そのものを使えません。
利用できるプラン
Claude Code on the webはPro・Max・Teamプラン、およびpremium seatかChat + Claude Code seatを持つEnterpriseプランでresearch previewとして提供されています。auto-fixもこの範囲のプランが前提です。
CIとレビューコメントへの反応のしかた
auto-fixが有効な間、ClaudeはそのPRに関するGitHubイベント(新しいレビューコメントやCIチェックの失敗を含む)を受け取ります。イベントごとに、次の3通りのいずれかで対応します。
- 確信のある修正: 修正内容に確信があり、それまでの指示と矛盾しない場合、変更を加えてプッシュし、セッション内で何をしたか説明する
- 曖昧な依頼: レビュアーのコメントが複数の解釈を許す、あるいはアーキテクチャに関わる重大な内容の場合、実行前に確認を求める
- 重複・対応不要なイベント: イベントが重複している、または対応が不要な場合、その旨をセッションに記録して先へ進む
Claudeはレビューコメントのスレッドに返信することがあります。この返信はあなたのGitHubアカウント名で投稿されますが、Claude Codeが書いたものだとレビュアーに分かるようラベルが付きます。auto-fixが動かすクラウドセッションはバックグラウンドセッションの一種で、コミット・プッシュ・PR作成の基本挙動はClaude Code v2.1.221で変わった条件付きPR作成に従います。
auto-fixが加えた変更を確認する
auto-fixが動いているセッションはサイドバーの一覧から開けます。各セッションには +42 -18 のような差分インジケーターが表示され、選ぶと差分ビューが開き、特定の行にインラインコメントを残して次のメッセージと一緒にClaudeへ送ることもできます。この差分はリポジトリの diff ドライバーや textconv フィルターを経由せず、生のgit blobから計算されます。
チーム・Enterpriseアカウントではセッションの可視性を「Private」と「Team」から選べ、Team可視性にすると同じ組織のメンバーがセッションを見られます。Max・Proアカウントでは「Private」と「Public」の2択で、Public可視性にするとclaude.aiにログインしている誰でも閲覧できます。プライベートリポジトリのコードや資格情報が含まれることがあるため、共有前に内容を確認します。
マージコンフリクトには自動で反応できない
GitHubはベースブランチが進んでマージコンフリクトが発生しても、そのイベント用のwebhookを送りません。そのためauto-fixはコンフリクトを自分で検知して直すことができません。コンフリクトが起きたら、セッションを開いてClaudeにリベースを頼む必要があります。ここは自動化の範囲外だと理解しておくと、放置して気づかないという事態を避けられます。
コメントトリガー型の自動化と衝突する場合がある
AtlantisやTerraform Cloud、issue_comment イベントで動くカスタムのGitHub Actionsなど、コメントをトリガーに動く自動化をリポジトリで使っている場合は注意が必要です。auto-fixが有効な間、Claudeがあなたの代わりにレビューコメントへ返信することがあり、その返信自体がそうしたワークフローを起動してしまう可能性があります。auto-fixを有効化する前にリポジトリの自動化を確認し、PRコメントがインフラをデプロイしたり権限のある操作を実行したりするリポジトリでは、auto-fixを無効にしておくことも検討します。
見落としやすい制限
- レート制限は他の利用と共有する: auto-fixが立ち上げるクラウドセッションは、アカウント内の他のClaudeやClaude Code利用と同じレート制限を共有します。複数のPRを同時に監視すると、その分だけレート制限を消費します。クラウドVM自体への追加課金はありません
- GitHub以外のリポジトリには使えない: リポジトリのクローンとPR作成はGitHubが前提です。自己ホストのGitHub Enterprise ServerはTeam・Enterpriseプランで対応していますが、GitLabやBitbucketなどGitHub以外のリポジトリはローカルバンドルとしてセッションへ送れても、結果をリモートへプッシュし返すことはできません
- 組織のIPアローリストと相性が悪い場合がある: 組織がIPアローリストを有効にしていると、Anthropic管理のクラウド基盤から呼び出すAnthropic APIの認証が失敗し、auto-fixのセッションも動きません。自己ホスト環境にルーティングしている場合はこの制限を受けません
まとめ
/autofix-pr は gh pr view でPRを検出し、1コマンドでクラウドセッションの起動とauto-fixの有効化を済ませます。プロンプトを添えれば「lintとtype errorだけ直す」のように対象を絞り込めます。反応は確信のある修正・確認が要る曖昧な依頼・対応不要の記録という3段階で、マージコンフリクトだけは自動検知の対象外です。コメントトリガー型の自動化を使うリポジトリでは、有効化の前に既存のワークフローとの衝突を確認しておきます。GitHub Actionsでの継続的な組み込みを検討している場合は、Claude CodeをGitHub Actionsに組み込むも参考になります。
有効化そのものはターミナルで1コマンド、あるいはCIステータスバーのトグル1つで済みますが、実際に機能するかどうかはGitHub Appのインストール状況・プラン・組織のIPアローリスト設定に左右されます。導入前にこの3点を確認しておくと、「トグルは入れたのに反応しない」という状態を避けられます。