Claude Code 自走の作法 ─ 副業煽りを解体し、本物の自動化を設計する

L3 ─ GitHub Actions で event-driven に動かす

2026/05/09

L3 ─ GitHub Actions で event-driven に動かす

L2 までは「自分が claude を起動する」前提だった。L3 では イベント が起動トリガーになる。PR が作成される、issue がオープンされる、push が起きる ── 何かが起きたら自動で Claude が走り出す世界。

これが「人がいない時間に動く」自動化の入り口。

公式ツール ─ claude-code-action

anthropics/claude-code-action が公式の入り口。GitHub Actions の workflow に追加するだけで、Claude Code を実行できる。

このツールの特徴は 「シェル環境を持った live agent」 がそのまま PR に commit できる点。AI レビューツールは数あるが、「コメントするだけ」のものが多い中で、claude-code-action は コードを書いて push するところまで担う。

2 つのモード

claude-code-action には 2 つの使い分けがある：

graph TB
  subgraph "Interactive モード"
    PR1[PR / Issue] -->|@claude メンション| C1[Claude 応答]
    C1 -->|コメント / commit| PR1
  end

  subgraph "Automation モード"
    Event[push / pr_open / schedule] --> YAML[YAML に prompt 記述]
    YAML --> C2[Claude 自動実行]
    C2 -->|結果| Output[review / commit / report]
  end

  style C1 fill:#e1f5ff
  style C2 fill:#fff4e1

Interactive モード ─ `@claude` メンション

PR や Issue で @claude と書くと反応する：

# .github/workflows/claude.yml
name: Claude Interactive

on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]
  issues:
    types: [opened, assigned]

jobs:
  claude:
    if: contains(github.event.comment.body || github.event.issue.body, '@claude')
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: anthropics/claude-code-action@v1
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}

これで PR コメントに「@claude このバグを直して」と書けば、Claude がコードを修正して新規 commit を push する。会話的な使い方 で、人間との協調が前提。

Automation モード ─ headless 実行

YAML に prompt を書いて、event を契機に headless 実行：

# .github/workflows/auto-review.yml
name: Auto PR Review

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0  # 全 history が必要
      - uses: anthropics/claude-code-action@v1
        with:
          prompt: |
            この PR の変更を以下の観点でレビューしてください：
            - セキュリティリスク
            - パフォーマンス問題
            - 設計の妥当性
            - テストカバレッジ

            指摘は GitHub PR コメントとして投稿してください。
            severity（high/medium/low）を必ず付けて。
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

こちらが本命。人間の介在なしに、PR が来たら自動でレビューが走る。

起点のセットアップ

最小構成は /install-github-app 一発で済む。Claude Code 内で：

/install-github-app

これで：

GitHub App のインストール
リポジトリへの connection
必要な secret（ANTHROPIC_API_KEY、CLAUDE_CODE_OAUTH_TOKEN）の登録
推奨 workflow の draft

までが自動で行われる。詳細は公式 GitHub Actions ドキュメント。

実例 1：LINE ヤフーの「PR レビュー準備」自動化

LINE ヤフー Tech Blog の事例。週 6 時間のレビュー工数を削減した一次体験記。

何をしたか

レビュー そのもの ではなく、レビュー準備（コンテキスト収集）を自動化 した。

graph LR
  PR[PR opened] --> Action[claude-code-action]
  Action --> A[GitHub MCP<br/>diff / files]
  Action --> B[Jira MCP<br/>関連 issue]
  Action --> C[Confluence MCP<br/>仕様書]
  A --> Bundle[コンテキスト束]
  B --> Bundle
  C --> Bundle
  Bundle --> Comment[PR にコメント]
  Comment --> H[人間レビュアー]

  style Bundle fill:#e1f5ff
  style H fill:#fff4e1

人間レビュアーは 散らばった情報を集める時間 を奪われていた。Claude にそこを担わせれば、人間は「実際にコードを評価する」だけに集中できる。

なぜこれが効くのか

「レビュー判断は人間、レビュー準備は AI」という責務分割。

レビュー判断：ドメイン知識、組織の文脈、政治的配慮 → 人間が必要
レビュー準備：機械的な情報収集 → AI が得意

副業煽りは「全自動レビュー」を売りたがるが、本物の事例は「ここまでは AI、ここからは人」を明確に切る。

実例 2：classmethod の Issue → PR → Review → Fix

DevelopersIO のブログの検証記事。一連の流れを 1 つの Action で組む。

graph LR
  I[Issue 作成] -->|trigger| Impl[Claude が実装]
  Impl -->|PR 作成| PR[PR opened]
  PR -->|trigger| Review[Claude が自己レビュー]
  Review -->|@claude fix it| Fix[Claude が修正]
  Fix --> Merge[人間がマージ]

  style I fill:#e1f5ff
  style Merge fill:#e1ffe1

ポイントは Issue を「仕様書」として扱う 設計。Issue テンプレに「目的・仕様・受け入れ基準」を強制すると、Claude の出力品質が跳ね上がる。

<!-- .github/ISSUE_TEMPLATE/feature.md -->
## 目的（why）
<!-- 何のために -->

## 仕様（what）
<!-- 何を作るか、ユーザー視点 -->

## 受け入れ基準（acceptance criteria）
- [ ] 〇〇できる
- [ ] △△が表示される

## 技術的注意
<!-- 既存コードベースとの整合性、避けるべき設計 -->

このテンプレに沿った Issue が立つと、Claude は明確な input から実装できる。input の質が output の質を決める ── 当たり前だが、Issue ベースの自動化ではこれが最大のレバレッジ。

実例 3：Issue triage 自動化

chhoumann/claude-github-triage のような OSS パターン。Issue が立つと Claude が：

重複 issue を検出して link
ラベル提案（bug / feature / docs / question）
必要情報の不足を指摘（再現手順がない / 環境情報がない）
close 候補を判定

on:
  issues:
    types: [opened]

jobs:
  triage:
    runs-on: ubuntu-latest
    steps:
      - uses: anthropics/claude-code-action@v1
        with:
          prompt: |
            この issue について以下を判断してください：
            1. 既存の open issue に重複があるか（gh issue list で検索）
            2. ラベル提案（bug/feature/docs/question/duplicate）
            3. 不足情報（再現手順 / 環境）
            4. close 推奨か

            結果を Issue コメントとして投稿。

OSS リポジトリのメンテナにとっては、これだけでメンテ負荷が大きく下がる。

fail-safe 設計の重要性

L3 でよく失敗するのは暴走だ：

Claude が無限に commit を作り続ける
API key を使い切る
大量の PR コメントが付く

zenn の nogataka の記事「Claude Code で PR レビューを自動化する設計と実装」は fail-safe 設計を丁寧に書いている：

自動化は fail-safe（人間に escalate する条件）の設計が本体。

Fail-safe の典型パターン

A. 実行回数の上限

- uses: anthropics/claude-code-action@v1
  with:
    max_turns: 10  # 10 回以上のツール使用で停止
    timeout_minutes: 15

B. cost guard

- name: Check cost
  run: |
    TODAY_COST=$(gh api ... | jq '.usage')
    if [ "$TODAY_COST" -gt 10000 ]; then
      echo "Cost exceeded, abort"
      exit 1
    fi

C. 人間 escalation

特定の条件で人間に通知：

- name: Notify on uncertainty
  if: contains(steps.claude.outputs.result, 'UNCERTAIN')
  uses: 8398a7/action-slack@v3
  with:
    status: custom
    custom_payload: |
      Claude が判断に迷っています。確認してください。

D. branch protection

main へ Claude が直接 push できないように：

Settings → Branches → main → Protect matching branches
  - Require a pull request before merging
  - Restrict who can push（Claude bot は含めない）

これで Claude は PR までしか作れない、マージは人間 という鉄壁の境界が引ける。

設計の原則 ─ 「責任 fast-track」

L3 で考えるべきは「この自動化が壊れた時、誰がどう気付き、誰が修復するか」。これを「責任 fast-track」と呼んでみる。

graph TB
  Q1[壊れた時に誰が気付く?] --> Q2[気付いたら誰が修復?]
  Q2 --> Q3[修復までの最大 dwell time は?]

  Q1 -.通知.-> S[Slack #alerts]
  Q2 -.責務.-> R[on-call / 自分]
  Q3 -.SLA.-> T[1 時間以内 / 1 営業日]

  style S fill:#e1f5ff
  style R fill:#fff4e1
  style T fill:#e1ffe1

「気付かない自動化」は最悪。少なくとも Slack / メール / GitHub notification への通知は必須。

副業視点での L3

副業煽りで頻出する「Claude Code で完全自動 PR 量産」は技術的には可能だが、現実的には：

API コストが受託額を圧迫する
暴走リスクが高く、頻繁に手動介入が要る
「PR 量産」は受託先に評価されない（質が見られている）

本物の L3 副業活用は「自分の OSS / 個人プロジェクトのメンテ負荷を下げる」が中心。受託案件に L3 を入れるなら、お客様のリポジトリに自分の Action を入れる契約 ができる関係性が前提。

L3 のチェックリスト

graph TB
  C1[claude-code-action インストール] --> C2[interactive / automation を選択]
  C2 --> C3[event trigger 設計]
  C3 --> C4[prompt 設計<br/>L1 の skill 流用]
  C4 --> C5[fail-safe 設計]
  C5 --> C6[branch protection 確認]
  C6 --> C7[通知設計]
  C7 --> Live[本番投入]

  style Live fill:#e1ffe1

この章の要点

L3 = GitHub Actions で event-driven 化。claude-code-action が公式入り口
Interactive（@claude メンション）と Automation（YAML に prompt）の 2 系統
LINE ヤフー：PR レビュー準備の自動化で週 6 時間削減。判断は人、準備は AI
classmethod：Issue を仕様書として扱う設計。input の質が output の質を決める
fail-safe 必須：実行回数上限、cost guard、人間 escalation、branch protection
「責任 fast-track」：気付き / 修復 / SLA を最初から設計
副業視点：完全自動 PR 量産は煽り、現実は OSS / 個人メンテ負荷削減

次章への問いかけ

Event-driven は強力だが、何かが起きないと動かない。

「毎週月曜 9 時にトレンド記事を出す」「毎晩依存をチェックする」のように 時間軸そのものをトリガー にしたい場合は別の仕組みが要る。次章では Scheduled Tasks / Cloud Routines で、自分の PC が落ちていても動く仕組みに進む。

L3 ─ GitHub Actions で event-driven に動かす

公式ツール ─ claude-code-action

2 つのモード

Interactive モード ─ @claude メンション

Automation モード ─ headless 実行

起点のセットアップ

実例 1：LINE ヤフーの「PR レビュー準備」自動化

何をしたか

なぜこれが効くのか

実例 2：classmethod の Issue → PR → Review → Fix

実例 3：Issue triage 自動化

fail-safe 設計の重要性

Fail-safe の典型パターン

A. 実行回数の上限

B. cost guard

C. 人間 escalation

D. branch protection

設計の原則 ─ 「責任 fast-track」

副業視点での L3

L3 のチェックリスト

この章の要点

次章への問いかけ

Interactive モード ─ `@claude` メンション