Claude CodeでCI失敗を自動修正する｜GitHub Actions・Playwrightのエラー解析から再テストまで【2026年版】

AIがコードを書けるようになっても、CIが失敗するたびに人間がログを開き、原因を調べ、コードを修正しているなら、開発工程にはまだ大きな手作業が残っています。

そこで次に自動化したいのが、CI失敗後の原因調査と修正です。

Claude Code ActionをGitHub Actionsと組み合わせると、ClaudeからCIの状態やJob Logを確認し、失敗原因を調査してコード修正へ進むワークフローを構築できます。

さらにPlaywrightのE2E結果やTrace、Screenshotまで組み合わせれば、単なるコードエラーだけでなく、実際のユーザー操作で発生した不具合の調査にも広げられます。

今回作るCI修正フロー

目指すのは、次のような開発ループです。

Claude Code
↓
Implementation
↓
Push / Pull Request
↓
GitHub Actions
↓
Lint / Typecheck / Build / E2E
↓
PASS ─────────────→ Human Review
↓
FAIL
↓
Claude Code
↓
CI Status
↓
Job Log
↓
Playwright Error
↓
原因調査
↓
最小修正
↓
Commit
↓
GitHub Actions再実行

これまで人間が行っていた「ログを読む→原因を探す→直す」という部分まで、AI開発フローへ組み込むのが今回のテーマです。

Claude Code ActionはCI結果を読める

Anthropic公式のClaude Code Actionでは、必要な権限を設定すると、GitHub ActionsのWorkflow RunやJob LogをClaudeから参照できます。

設定のポイントは2つあります。

GitHub Actionsの権限を設定する

まずWorkflow側で、ClaudeがGitHub Actionsを読めるようにします。

permissions:
  contents: write
  pull-requests: write
  issues: write
  actions: read

続いてClaude Code Action側へ、追加権限を指定します。

- name: Run Claude Code
  uses: anthropics/claude-code-action@v1
  with:
    anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}

    additional_permissions: |
      actions: read

これによりClaude Code ActionからCIの状態やWorkflow情報、Job Logを確認できるようになります。

Claudeが利用できるCI情報

Anthropicの公式設定では、Actionsへの読み取り権限を有効にすると、Claude Code ActionからCI用のツールを利用できます。

つまり、人間がGitHub Actions画面を開いて調べていた情報を、Claude自身が確認できるようになります。

まずは「原因調査」から任せる

いきなり自動修正まで許可する必要はありません。

最初はPR上でClaudeへ、CI失敗の原因だけを調べてもらう運用でも十分有効です。

@claude

CIが失敗している原因を調査してください。

確認するもの：
- GitHub Actions status
- 失敗したjob
- job log
- 今回のgit diff
- 関連テスト

まだコードは変更せず、

1. 原因
2. 影響範囲
3. 最小修正案
4. 回帰リスク

を報告してください。

これなら、人間が原因を確認してから修正を許可できます。

次に最小修正まで任せる

原因分析が安定してきたら、修正までClaudeへ任せます。

@claude

現在のCI失敗について、

原因調査
↓
最小修正
↓
関連テスト
↓
lint
↓
typecheck
↓
build
↓
E2E
↓
diff report

まで進めてください。

重要：

・テストを通すためだけにassertionを弱めない
・失敗テストをskipしない
・不要なtimeout延長をしない
・無関係なコードを変更しない
・仕様変更が必要なら勝手に変更せず報告する
・修正後も既存機能の回帰を確認する

このように、AIへ「PASSさせろ」とだけ指示するのではなく、修正ルールも一緒に与えることが重要です。

Playwrightが失敗した場合は何を見る？

E2Eテストでは、単純なコンパイルエラーより原因が複雑になることがあります。

Playwrightが落ちた場合は、最低でも次の情報を確認します。

CI失敗には種類がある

すべてのFAILを同じように扱わないことも重要です。

CI FAIL
│
├── Lint
│   └── Code Style / Rule
│
├── Typecheck
│   └── Type Error
│
├── Unit Test
│   └── Logic / Regression
│
├── Build
│   └── Dependency / Env / Compile
│
├── E2E
│   └── UI / API / Auth / DB
│
└── Infrastructure
    └── CI / Network / Service

たとえばInfrastructure側の一時的な失敗を、アプリコードを変更して直そうとすると、逆に不要な変更が入ってしまいます。

一番危険なのはテストを弱くすること

AIへ修正を任せるときに最も注意したいのが、テストそのものを変更してPASSさせてしまうケースです。

AIには最初から、次の優先順位を渡しておくと安全です。

1. 1

   仕様を確認

   現在期待されている正しい動作を確認します。

2. 2

   失敗原因を特定

   Code・Test・Environmentのどこが原因かを分類します。

3. 3

   最小修正

   原因に直接関係する部分だけを変更します。

4. 4

   回帰確認

   直した機能だけでなく関連機能も確認します。

Claude Code ActionのBranch動作

Claude Code Actionは、実行されたコンテキストによってBranchの扱いが変わります。

Anthropic公式ドキュメントでは、Open中のPull RequestでClaudeを起動した場合、そのPRの既存Branchへ変更をPushできます。

一方でIssueから作業する場合は新しいBranchを作る設計です。

ClaudeにPRを勝手にマージさせない

自動化を進めても、Productionへ入る最後の境界まで無人にする必要はありません。

Claude Code ActionはデフォルトでPRを自動作成するのではなく、BranchへCommitしたうえでPR作成用のリンクを提示する設計になっています。

Branch ProtectionやRequired Checksと組み合わせて、人間のApprovalを残す構成が安全です。

AI Implementation
↓
Pull Request
↓
CI
↓
FAIL
↓
AI Fix
↓
CI PASS
↓
Required Checks PASS
↓
Human Review
↓
Merge

GitHub Actionsの再実行について

GitHub Actionsでは、Workflow全体、失敗したJob、特定Jobを再実行できます。

ただし「同じRunをそのまま再実行する」のと、「Claudeがコードを修正して新しいCommitをPushし、そのCommitで新しいCIが走る」のは別です。

アプリコードに原因がある場合は、修正Commitによって新しいCIを発生させる方が自然です。

自動修正の停止条件を決める

AI自動修正を運用するなら、成功条件だけでなく停止条件も重要です。

権限は必要最小限にする

AIエージェントへGitHubを操作させる以上、権限設計は非常に重要です。

CIログを見るだけなら、Actionsには読み取り権限だけを与えるのが基本です。

使わない権限を念のため付与するのではなく、必要になった権限だけを明示的に追加します。

ここまでつなぐとAI開発ループが完成してくる

これまで構築してきたPreview・QA DB・E2E・CI修正をまとめると、次のような構成になります。

Issue / Specification
↓
Claude Code
↓
Feature Branch
↓
GitHub
↓
Vercel Preview
↓
QA Database
↓
GitHub Actions
↓
Playwright
↓
PASS ───────────────→ Human Review
↓
FAIL
↓
Claude Code
├── CI Status
├── Job Log
├── Trace
├── Screenshot
└── Git Diff
↓
Root Cause Analysis
↓
Minimal Fix
↓
Commit
↓
CI / E2E
↓
PASS
↓
Human Approval

ここまで来ると、AIは単にコードを生成するだけではありません。

実装 → 検証 → 失敗分析 → 修正 → 再検証という開発ループそのものへ参加できるようになります。

完全無人化よりHuman in the Loop

技術的に自動化できる範囲が広がっても、すぐにProductionまで完全無人化する必要はありません。

特に初期段階では、AIが何度でも安全に試せる環境を作りつつ、最後の承認だけ人間に残す設計が現実的です。

次はSentryの本番エラーをClaude Codeへつなぐ

CIやE2Eは、本番へ出す前の問題を検出する仕組みです。

しかし実際のサービス運用では、本番に出したあとにしか発生しないエラーもあります。

次のステップでは、Sentryで検知したエラーからIssueを作り、Claude Codeへ原因調査・修正をつなげる運用を考えていきます。

出典：Anthropic Claude Code Action公式ドキュメント / GitHub Actions公式ドキュメント / Microsoft Playwright公式ドキュメント