Claude Code /autofix-pr 実践ガイド — PR作成からCI修正・レビュー対応・pushまで全自動化する自律PRパイプライン

/autofix-pr とは何か — 従来のCI修正フローとの決定的な違い

PRの「待ち時間」問題 — CI失敗→修正→再レビューの往復コスト

PRを作ったあとの「CI落ちた→直す→push→またレビュー待ち」のループ、まだ手動でやっていないだろうか。

従来のフローを整理すると、こうなる。

1. ローカルで実装を完了し、PRを作成
2. CIが回るのを待つ（5〜15分）
3. lint違反やテスト失敗に気づく
4. ローカルに戻って修正、push
5. 再びCIを待つ
6. レビューコメントがつく
7. またローカルで修正、push
8. 2に戻る

この往復のたびにコンテキストスイッチが発生する。別の作業に移っていた場合、PRの文脈を思い出すところからやり直しだ。

Claude Codeの /autofix-pr は、この問題を根本的に解決する。

クラウドセッションでPRを自動監視する仕組み

/autofix-pr の核心は、新しいクラウドセッションをspawnし、GitHub PRのwebhookを監視してCI修正やレビュー対応を自動で行う点にある。ローカルCLIセッションの会話履歴を転送するのではなく、クラウド側がPRの差分やCIログから文脈を読み取って修正に当たる。なお、セッションの引き継ぎは一方向であり、--teleport でクラウドセッションをローカルに引き込むことはできるが、既存のローカルセッションをクラウドにpushすることはできない。

保護ブランチ（main/master）へのpushはデフォルトで不可になっており、auto-mergeも明示的な設定なしには実行されない。featureブランチ上での修正に限定される安全設計だ。

実践：/autofix-pr でCI修正とレビュー対応を自動化する

CI失敗の自動検知→修正→pushフロー

/autofix-pr を実行すると、クラウド側がCIの結果を監視し、失敗を検知すると自動で修正に入る。ただし、CIログへの直接アクセスにはGitHub Actionsのログ取得権限に依存する制約がある。権限が不足している場合は、エラーメッセージをPRコメントとして貼り付ける運用で補完できる。

修正の精度を上げるには、CLAUDE.md にCI修正ポリシーを明記しておくのが効果的だ。

# CLAUDE.md に追記する CI修正ポリシー例

## CI修正ガイドライン

- テスト失敗時はスキップ（.skip）で回避せず、必ず原因を特定して修正する
- lint違反は `npm run lint -- --fix` を最初に試し、自動修正できないものだけ手動対応
- 型エラーは as unknown as X のような強制キャストで逃げない
- ビルドエラーは依存関係の不足を最初に疑う（package.json を確認）
- 同じCIステップが2回連続で失敗した場合、修正方針を変えて再試行する

正直、CLAUDE.md にこの数行を足すだけで修正の質が目に見えて変わるので、最初にやっておくことをすすめる。

レビューコメントへの自動対応

GitHub上でレビュアーがコメントを残すと、クラウドセッションがそれを検知し、コメント内容に沿った修正を行い、pushまで自動で実行する。レビュアーから見ると、コメントを書いて少し待つだけで修正コミットが積まれている状態になる。

なお、Claudeがレビュースレッドに返信する場合、その投稿はユーザー自身のGitHubアカウントで行われ、Claude Codeからの投稿であることを示すラベルが付与される。チームメンバーに事前に周知しておくとよい。

flaky testや環境起因の失敗にどう対処するか

Auto-Fixが対応できないケースは明確に存在する。

• flaky test: 実行ごとに結果が変わるテストは、コード修正では解決できない
• 環境変数不足: クラウド側にsecretが設定されていない場合、そもそも再現不可能
• 外部サービス障害: APIのレート制限やダウンタイムに起因する失敗

これらのケースでは、Auto-Fixは修正方針が曖昧な場合に勝手に推測せず、ユーザーに確認を求める動作をとる。判断基準として、「同じエラーが2回修正を試みても解消しない場合は環境起因を疑う」と覚えておくとよい。

claude-code-action（GitHub Actions）との使い分け判断フロー

それぞれの得意領域と制約

判断フローチャート

PR作成者は自分か？
├── YES → /autofix-pr（自分のPRを放置して次の作業に移れる）
└── NO  → claude-code-action（自動発火で全PRカバー）

チーム開発では、claude-code-action を全PR共通のガードレール（lint、型チェック、セキュリティスキャン）として常時稼働させ、/autofix-pr は個々の開発者が自分のPRに対して使うのが現実的な運用だ。

自律開発デーモンとの統合 — デプロイ検証失敗→PR作成→放置で完結

デプロイパイプラインの検証ステージに組み込む

筆者が運用している24/365自律開発デーモン（slave）では、autonomous-dev パイプラインの最終ステージでデプロイ後のHTTP検証を行っている。ここで検証失敗を検知した場合、自動でPRを作成し、Claude CLI経由でAuto-Fix相当の処理を投入するフローを組んでいる。

実装コード：vercel deploy後の自動修正フロー

// deploy-and-autofix.ts
import { runClaude } from "./claude-runner.js";
import { execSync } from "child_process";

interface DeployResult {
  url: string;
  status: "success" | "error";
  errorDetails?: string;
}

async function verifyAndAutofix(
  projectDir: string,
  deployUrl: string
): Promise<void> {
  // デプロイ後のHTTP検証
  const res = await fetch(deployUrl);
  if (res.ok) {
    console.log("デプロイ検証OK");
    return;
  }

  const errorBody = await res.text();
  console.log(`検証失敗: ${res.status}`);

  // featureブランチを作成してpush
  const branch = `fix/deploy-error-${Date.now()}`;
  execSync(`git checkout -b ${branch}`, { cwd: projectDir });
  execSync(`git push -u origin ${branch}`, { cwd: projectDir });

  // PR作成
  const prUrl = execSync(
    `gh pr create --title "fix: デプロイエラーを修正" --body "自動検出されたデプロイエラーの修正"`,
    { cwd: projectDir, encoding: "utf-8" }
  ).trim();

  // Claude CLIでAuto-Fix相当の修正を投入
  const prompt = `
このプロジェクトのデプロイ後にHTTPエラーが発生しています。

URL: ${deployUrl}
ステータス: ${res.status}
レスポンス: ${errorBody.slice(0, 2000)}

エラーの原因を特定し、修正してください。
修正後は git commit && git push してください。
PR: ${prUrl}
  `.trim();

  await runClaude(prompt, { cwd: projectDir });
}

既存の claude-runner.ts（spawn + stdin pipe方式）をそのまま活かせるため、統合のコストは低い。レート制限が発生した場合は、デーモン側の指数バックオフ（5分→10分→20分→最大60分）がそのまま適用される。

ハマりポイントと運用Tips

知っておくべき制約と回避策

保護ブランチへのpush不可は仕様である。 mainブランチに直接pushするワークフローでは /autofix-pr は使えない。featureブランチ運用が前提になる。

CIログへのアクセス制限がある場合の対処。 エラーメッセージ全文をPRコメントに貼り付けるワークフローを組んでおくと、Auto-Fixがコメントからエラー内容を読み取って修正できる。

Auto-Fixの無限ループ防止。 修正→CI失敗→修正→CI失敗が繰り返されるリスクがある。対策として以下を意識する。

• 修正回数の上限を設ける（3回程度が目安）
• 同じエラーメッセージが連続した場合は打ち切る
• タイムアウトを設定する

secrets/環境変数のクラウド側利用。 ローカルの .env に設定している値がクラウド側で利用できるかは事前に確認が必要だ。特にAPIキーやデータベース接続情報は、GitHub Secretsとして設定しておく必要がある場合がある。

チーム導入時のベストプラクティス

チームで /autofix-pr を導入する際、最も重要なのは CLAUDE.md での方針統一だ。メンバーごとに修正方針がバラバラだと、Auto-Fixの出力も一貫しなくなる。

• コーディング規約をCLAUDE.mdに明記する
• テスト修正のポリシー（スキップ禁止、モック方針など）を統一する
• セキュリティに関する制約（外部APIキーの扱い、認証周りの変更は人間レビュー必須など）を記載する

まとめ

/autofix-pr は「PRを作ったら放置して次の作業に移れる」ワークフローを実現する。CI修正もレビュー対応もクラウド側が自動で回してくれるため、開発者のコンテキストスイッチが劇的に減る。

ただし万能ではない。環境起因の失敗やflaky testには限界がある。claude-code-action との適切な使い分け、CLAUDE.md による方針の明示、自律デーモンとの統合といった実践パターンを組み合わせることで、PRのターンアラウンドタイムを本質的に短縮できる。

地味だが、これは開発の「待ち」を消す技術だ。一度体験すると、手動でCIの修正をしていた頃には戻れなくなる。