この記事では、Windows環境のClaude Codeで実際に試した結果をもとにまとめています。
PRを出したらCIが赤い。修正してpushして、また待って……このループ、何回やっても慣れない。/autofix-prはその辺をClaude Codeに任せられるコマンドだ——CIが落ちたら自動で直し、レビュー指摘が来たら自動で対応する。Windows 11環境のターミナルから実際に試して、どこまで頼むだけで進むか、どこから人が目を通すべきかを確認した。
この記事で確かめること
CI失敗の自動修正、レビュー指摘への自動対応、AIレビューツールとの連携——この3本を/autofix-pr一本でどこまで進められるかを確かめる。
検証環境はWindows 11、ターミナルからClaude Code（v2.1.94以降）を操作する前提。デスクトップ版やIDE拡張ではなく、CLIからの実行で進める。
「Claude Codeに頼むだけで、/autofix-prはどこまで使える？」——これに答えを出す。
前提：用意しておくもの
ざっくり次の3つが揃っていれば試せる。
- Claude Code（2026年4月時点で最新版）。
claude --versionで確認できる - GitHub連携。ターミナルで
gh auth statusが通る状態 - Claude Code on the webにアクセス可能なプラン（Pro、Max等。無料プランでは一部機能が制限される場合があるため、利用時に公式サイトで確認してください）
テスト用のリポジトリをGitHub上に用意しておくと安心。本番のリポジトリでいきなり試すより、壊してもいい環境で触るのが無難だ。
やりたいこと：PRのCI失敗とレビュー指摘を自動で直してほしい
PRを出すとCIが落ちる。ログを見て原因を探して、コードを直して、pushして、またCIが回るのを待つ。これを2回、3回と繰り返すと、修正そのものより待ち時間がしんどい。
レビューの往復も同じだ。「ここ直して」→直す→push→「あそこも」→直す→push。1回の指摘ならまだしも、複数来ると往復だけで半日が消える。
/autofix-prはこのループをClaude Codeに肩代わりさせるコマンド。CI失敗やレビューコメントを自動で監視して、修正→コミット→pushまで進めてくれる。どこまで任せてよくて、どこから自分で確認するか——それを見極めるのが今回の目的だ。
Step 1：最初の依頼——CI失敗の自動修正を頼む
テスト用リポジトリで、わざとテストが落ちるコミットを作った。関数の戻り値の型を数値から文字列に変えて、テストの期待値と合わなくした——よくある小さなCI失敗パターンだ。初心者が引数や戻り値の型でつまずくのと同じようなミスを意図的に仕込んでいる。
git checkout -b test-autofix
echo 'def add(a, b): return str(a + b)' > calc.py
git add . && git commit -m 'change return type to string'
git push origin test-autofix
gh pr create --title 'Test: change return type' --body 'verify autofix'
テストのエラーメッセージは次のようになる。
AssertionError: expected 42 but received "42"
このPRに対して/autofix-prを実行する。
claude /autofix-pr
コマンドを実行すると、ターミナルにセッション開始のメッセージが出る。ここで驚いたのが、CLIで実行したのに裏側でClaude Code on the webのセッションが立ち上がる点。ローカルのターミナルから指示を出しているのに、実際の処理はクラウド側で進む——この境界の曖昧さに少し戸惑った。自分のPC上で動いているのか、ブラウザの向こう側で動いているのか、感覚が追いつかない。
セッションが起きると、CIが失敗するのを待って自動的に修正を試みる流れになる。
Step 2：最初の結果——CI失敗はどう修正されたか
CIが落ちてから数分で、自動的にコミットが追加された。修正内容を見ると、テスト側の期待値を関数の新しい戻り値（文字列）に合わせていた。想定では関数側を直すかと思ったが、テスト側を合わせにきた——エラーの箇所ではなく、関連する別の場所を直すアプローチだった。コミットメッセージは「Fix type mismatch in return value」のように、変更内容を的確に表していた。
この環境での所要時間は、CI失敗の検知から修正コミットまで3〜4分程度。待っている間はターミナルにログが流れるので、何が起きているかは追える。
CIのログへのアクセス範囲は、今回の検証では完全には確認できていない。エラーメッセージの概要は拾っている様子だったが、スタックトレースの深い部分まで参照しているかは判断が難しかった。このあたりの挙動はバージョンによって変わる可能性がある。一部に修正漏れもあったが、ここでは詳細は触れない。
人が確認したポイントは、修正後のコードが意図しない副作用を含んでいないかだった。
CIの修正は一応通った。でも、これがレビューの指摘でも同じ精度が出るのか？——次はGitHub上からレビューコメントを投げてみる。
Step 3：修正指示——レビューコメントへの対応を追加で頼む
GitHub上でPRにレビューコメントを追加した。ピンポイントの指示を出すことで、自動対応の精度を測る狙いだ。
calc.pyの戻り値を文字列ではなく数値に戻してください。
テストは元の期待値のままにしてください。
なぜこの指示にしたかというと、「元に戻す」という操作は修正範囲が明確で、自動対応の精度を判定しやすいからだ。
同時に、CodeRabbit（AIレビューツール）もこのPRに紐付けてある。AIレビューの指摘も/autofix-prが拾ってくれるかを確かめる。
レビューコメントを投げた数秒後にセッションのログが動き出した。手動でレビューを書いて人が反応するのとほぼ同じ速度で拾っている——このリアルタイム感は、CI失敗の検知とはまた違った驚きがあった。ブラウザ側のセッションがコメントを即座に拾っているのを見ると、対人レビューと変わらないUXだ。
Step 4：修正後の結果——レビュー指摘はどう反映されたか
レビューコメントへの対応は、概ね指示通りに進んだ。関数の戻り値が数値に戻り、テストも元の期待値を維持していた。
CodeRabbitの指摘（型アノテーションの追加やdocstringの提案）にも対応していた。複数の指摘が同時に来た場合、順番に処理するが、指摘ごとにコミットを分ける傾向があった。
ここでStep 2で軽く触れた修正漏れについて詳しく見る。Step 2の時点ではテスト側の期待値だけを直したが、文字列→数値の戻しに伴って別のテストケース（境界値テスト）が壊れていた。これに/autofix-pr自身は気づいていなかった。Step 3で「数値に戻して」と指示したことで結果的に直ったが、自力で検出したわけではない。
修正漏れがあった——では、この修正漏れに/autofix-pr自身が気づけるのか？ それとも結局、人が目で見るしかないのか？
Step 5：どこまで頼むだけでできたか
今回の検証での事実を3段階で分ける。
比較的任せやすい
– 小さなCI失敗の修正（型不一致、インポート漏れ等）
– ピンポイントのレビュー指摘への対応
条件付きで使える
– 複数のレビュー指摘の同時対応（順次処理はするが、全部網羅される保証はない）
– AIレビューツール（CodeRabbit等）の指摘への対応（指摘の質に依存）
必ず人が確認すべき
– CIログに基づく原因特定（/autofix-prはCIログに直接アクセスしない）
– アーキテクチャ変更レベルの修正
– 修正漏れの検出（自力では気づかない場合がある）
– 意図しない変更が入っていないかの確認
今回のやり取りは依頼1回＋レビュー指示1回の計2回。CIログへのアクセスが限定的に見えたことが、実用上の一番大きな懸念だった。
事実はここまで。次は、この結果を踏まえて——依頼文をどう書くか、どんな人に向くのかを整理する。
この検証の振り返り
依頼文のコツとして一つ気づいたことがある。具体的な指示ほど精度が高い。「型を直して」より「戻り値をintに戻して、テストは元の期待値のままにして」の方が、確実に意図が伝わった。
向いているのは、CI失敗が頻発する小規模リポジトリを扱っている人や、レビュー往復に疲れている人。逆に、CIログの原因特定が主目的の人や、大規模リポジトリで部分変更の影響範囲が広いケースには向かない。
運用上の利点を整理すると、判断に迷う時間が減る（CI失敗を見てどうするか考える手間が削れる）のと、レビューの往復が減る（指摘が来た瞬間に修正が始まる）の2点が大きい。
用途がはっきり分かれているリポジトリには向く。一方、不特定多数の指摘が飛び交う大規模開発では人の確認が増えるため、導入の恩恵は相対的に下がる。
環境やバージョンによっては、CIログへのアクセスや修正精度が今後さらに進む可能性がある。
次に試すなら
まずは自分のリポジトリで小さなCI失敗から試すのがお勧め。意図的にテストを壊したPRを作って、/autofix-prに任せるところから始めると、挙動がつかみやすい。
CI失敗の自動修正に慣れたら、CodeRabbit等のAIレビューツールと組み合わせて、レビュー→修正の自動ループを試してみる。自動マージの設定も検討できる段階だが、最初は人がマージする運用で様子を見た方が安心だ。
骨組みが短時間でできるので、合わない部分だけ後から直せばいい——この感覚で使い始めるのが現実的だ。
今回の結果は、利用モデル、接続先、時期、環境によって変わる可能性があります。再現する時は検証条件もあわせて確認してください。