/autofix-pr(オートフィックスピーアール)

スラッシュコマンド
/autofix-pr
オートフィックスピーアール
いま立っている枝のPRを、クラウド側の見張りセッションに監視させるスラッシュコマンド。CIが失敗したりレビューコメントが付いたりすると、見張り役が自分で調べて直しを送り返す。手元の画面は閉じてよい

GitHubでPRを使って開発している人向け

GitHubでPRを出した後、CIの失敗やレビューコメントへの対応を毎回手元で往復するのが面倒なときに、対象PRの枝に立った状態でこれを叩いて、見張りと自動修正をクラウド側に任せる

GitHubで開発をしていると、PRを出した後がいちばん地味に疲れます。CIの自動テストが赤くなる、レビュアーが「ここ直して」とコメントを残す。そのたびに自分のパソコンに戻って原因を調べて、直して、また送り直す。この往復を肩代わりさせるのが /autofix-pr です。

一度叩くと、Claude Code on the webに見張り役のセッションが立ち上がります。テストが落ちたりコメントが付いたりするたびに、そのセッションが自分で調べて、直しを送ってくれます。手元の画面は閉じてしまって構いません。

噛み砕くと

新しい職場で、提出した書類に上司が赤ペンを入れて戻してくる場面を思い浮かべてください。普通なら自分で席に戻って書き直して、また提出します。/autofix-pr がやるのは、その赤ペンが入った瞬間に気づいて、代わりに直して再提出してくれる秘書を1人雇うようなものです。

しかも雇い先は自分の机ではなく、クラウド側の別室です。だから自分は別の仕事に移れます。秘書は「明らかにこう直せばいい」ものは黙って直し、「これどっちの意味?」と迷う指摘は本人に確認を取ってから動きます。全部を勝手にやるわけではない、ここが地味に賢いところです。

大事な前提:これは手元のセッションが見張るコマンドではない

勘違いしやすいのですが、/autofix-pr を叩いた手元の画面が見張り続けるわけではありません。叩いた瞬間にクラウド側へ新しい見張りセッションが生まれて、そっちが仕事を引き継ぎます。手元のClaude Codeは閉じて大丈夫です。

そして動かすには3つの準備が要ります。ghが入ってログイン済みであること、Claude Code on the web が使える契約であること、そしてClaude GitHub App という連携アプリが、その対象プロジェクトに入っていること。3つ目は特に抜けやすいので後の落とし穴でもう一度触れます。

「料理ブログ」を例に、実際の手順を見る

世界の料理レシピを載せる料理ブログを作っていて、コードはGitHub上のプロジェクトで管理しているとします。今日は「カレーの分量表示が崩れるバグ」を直すPRを出すところから始めます。

ステップ1: 直す作業用の枝に移っておく

/autofix-pr は「いま自分が立っている枝のPR」を見張り対象にします。枝とは、本体を傷つけずに作業するための分かれ道のようなものです。まずはバグ修正用の枝に移ります。

$ git switch fix-curry-amount

この状態を作っておかないと、見張ってほしいPRが定まりません。

ステップ2: 変更を送ってPRを出す

分量表示のコードを直して、いつも通りGitHubへ送り、PRを作ります。ここまでは普段の流れと同じです。PRを出すと、料理ブログのCIが走り始めます。

ステップ3: その枝にいる状態で叩く

ここが本番です。さっきの枝にいるまま、Claude Codeで打ちます。

/autofix-pr

Claude Code は gh pr view を使って「いまの枝に紐づく開いているPR」を自分で見つけ、クラウド側に見張りセッションを立ち上げ、見張りをオンにします。ここまでが1回の操作でつながります。

ステップ4: CIが赤くなる

しばらくすると、料理ブログのテストが1つ落ちました。分量を表示する関数で、数字をうっかり文字として扱っていた、というよくあるやつです。見張りセッションがこの失敗の通知を受け取ります。

ここで初心者がやりがちな勘違いがあります。「自分のパソコンが起動してないと直してくれないのでは?」と心配しがちですが、見張りはクラウド側です。自分のパソコンの電源が落ちていても、セッションは反応します。

ステップ5: 直しが送られてくる

セッションは落ちたテストのログを読み、原因を特定し、数字として扱うように直して、その変更をPRへ送り直します。何をやったかはセッションの中に説明として残るので、後から「なぜこう直したか」を追えます。CIがもう一度走り、今度は緑になりました。

ステップ6: レビューコメントにも反応する

同僚が「この関数、レシピ名が空のときも考慮して」とレビューコメントを残しました。意味が一通りに決まる指摘なら、セッションがそのまま直して送ります。もし「どっちの意味にも取れる」「全体の作りに関わる大きな話」なら、勝手に進めず本人に確認を投げてきます。

なお、レビューコメントへの返信は自分のGitHubアカウント名義で投稿されます。ただし各返信には「Claude Codeが書いた」という印が付くので、レビュアーは人間ではなくAIが返したと分かります。

つまり /autofix-pr は何をしてくれるのか

  • やってくれる: いま立っている枝のPRを対象に、CI失敗とレビューコメントを見張る別働セッションを1回の操作で立ち上げ、はっきり直せるものは直して送り返す
  • やってくれない: 本体側が先に進んで起きたマージの衝突(直しが食い違う状態)には反応しない。GitHubがその通知を出さないため、衝突はセッションを開いて手で頼む必要がある
  • 意味が薄い場面: そもそもPRが1つも開いていない枝で叩く、CIもレビューも回っていない個人の手元プロジェクト

使いどころ3シナリオ(具体題材で再現)

シナリオ1: 料理ブログの細かいlintエラーだけ自動で潰したいとき

料理ブログのPRで、毎回コードの書き方チェック(lint)と型チェックばかり赤くなるとします。レシピの内容に関わる指摘は自分で見たいけど、空白や書式の指摘は機械的に直したい。そんなときはコマンドの後ろに指示を書き足せます。

/autofix-pr only fix lint and type errors

こう打つと、見張りセッションへの指示が「全部直せ」から「書き方と型のエラーだけ直せ」に差し替わります。後ろに足す文章は、見張る対象の指定ではなく、見張り役への指示書きだと覚えると混乱しません。

シナリオ2: 家計簿アプリの別のPRを見張りたいとき

料理ブログとは別に家計簿アプリも作っていて、そっちのPRを見張りたいとします。/autofix-pr にPRの番号やURLを渡す方法はありません。見張る対象は「いまの枝のPR」で固定です。だから先に対象のPRの枝へ移ってから叩きます。

$ git switch add-monthly-report
/autofix-pr

枝を切り替えるのがPRを切り替える操作にあたる、という関係です。

シナリオ3: GitHub外から来たOSSのPRを取り込み前に見張りたいとき

料理ブログを公開していて、外部の人がレシピ追加のPRを送ってきたとします。そのPRの枝を自分の手元に取り寄せて移り、そこで /autofix-pr を叩けば、CIが落ちるたびに直しを試みる見張りが付きます。レビューのたびに自分が張り付かなくて済むぶん、内容の確認に集中できます。

初心者が踏みやすい落とし穴

  • Claude GitHub App を入れ忘れている/web-setup でGitHub連携を済ませただけでは足りません。見張り(Auto-fix)はこのアプリ経由でPRの出来事を受け取るので、対象プロジェクトにアプリが入っていないと反応しません。連携済みでも後から見張りを使いたくなったら、改めてアプリを入れます。
  • 手元の画面が見張ると思い込む。見張るのはクラウド側の別セッションです。叩いた後の手元の画面は閉じて問題ありません。
  • PR番号やURLを後ろに付けようとする。それは受け付けません。後ろに足せるのは見張り役への指示文だけです。対象を変えたいなら枝を切り替えます。
  • 枝に移らずに叩く。開いているPRに紐づく枝に立っていないと、見張る相手が見つかりません。git switch で先に移ってから叩きます。
  • マージの衝突まで直してくれると期待する。本体が先に進んで起きた食い違いには反応しません。セッションを開いて、整え直し(rebase)を自分で頼む必要があります。
  • コメント起動の自動化が裏で走るプロジェクトで使う。PRへのコメントが自動デプロイなどを発火させる仕掛けがある場合、セッションの返信がそれを誤って起動しかねません。そういうプロジェクトでは見張りをオフにしておくのが安全です。
  • Zero Data Retention の組織で使おうとする。データを残さない設定の組織は、クラウドセッション機能ごと使えません。この機能の手前で止まります。
  • 止め方を知らずに見張らせ続ける。見張りはPR1つごとのオン・オフです。止めたいときは、見張りセッションのCI状態バーで Auto-fix を外すか、Claudeに「このPRの見張りをやめて」と頼みます。

書き方

/autofix-pr [見張り役への指示文]

やってみるとこうなる

入力

/autofix-pr only fix lint and type errors

出力例

いまの枝の開いているPRをghで見つけ、クラウド側に見張りセッションを立ち上げ、見張り(Auto-fix)をオンにする。以後CIが落ちるたび/レビューコメントが付くたびに、はっきり直せるものはセッションが直して送り返す。後ろに指示文を足すと『全部直せ』から指定した内容だけに差し替わる

このページに出てきた言葉

PR
GitHubで「コードをこう変えたい」という変更案を出し、本体に取り込む前にチェックやレビューをしてもらう仕組み。pull request の略
CI
コードを送るたびに自動でテストやチェックを走らせる仕掛け。結果が緑(成功)か赤(失敗)で表示される
Claude Code on the web
自分のパソコンではなくブラウザ越しにクラウド側でClaude Codeを動かす機能。手元の画面を閉じても処理が続く
Claude GitHub App
ClaudeとGitHubをつなぐ連携アプリ。これが入っていると、PRで起きた出来事の通知がClaudeへ届く。見張り(Auto-fix)の必須要件
gh
GitHubが配っている公式の操作ツール。<code>gh pr view</code> のように打って、PRやプロジェクトを文字だけで操作できる
Auto-fix
PRを見張ってCI失敗やレビューコメントに自動で反応する機能。PR1つごとにオン・オフを切り替える

関連項目

公式ドキュメント

https://code.claude.com/docs/en/claude-code-on-the-web#auto-fix-pull-requests

-

← 戻る