PRレビューとIssue整理を任せる

前のレッスンで、リポジトリに claude-code-action を入れ、コメントで @claude と呼べば応える状態にしました。

ここから一段進めます。誰かが呼ぶのを待つのではなく、決まった出来事が起きたら自動で動く形です。公式ドキュメントとリポジトリの解説ページには、PRが開かれたら動くレビュー、Issueが立ったら動くトリアージ、そして決まった時刻に動く定期実行という3つの使用例が載っています。どれも「GitHubにClaudeを置く」で入れた claude-code-action の上に、トリガーとプロンプトを変えて乗せているだけです。

このレッスンでは、この3つがそれぞれ何をして、あなたが何を見ればいいかを確認します。あわせて、同じ役目を持つマネージドの機能（Code Review・Routines）との使い分けと、自動である以上必ず要る「暴走させない設定」もまとめて押さえます。

PRを自動でレビューしてもらう

公式ドキュメントが「Run a skill」として挙げている例は、PRが開かれる・更新されるたびに動くレビューのワークフローです。トリガーは pull_request イベントの4種類（開かれた・コードが更新された・下書きから戻された・再開された）。ここでAnthropic公式の code-review プラグインを読み込み、/code-review:code-review --comment を実行させます。

見るべき場所は普段のレビューコメントと同じです。レビューする人が入れ替わるわけではなく、最初の一読み分をClaudeが引き受けている状態だと考えてください。出てきたコメントをチームがどう扱うかは、次のレッスンで扱います。

Issueを分類してラベルを付ける

2つ目は、Issueが立った瞬間に動くトリアージです。anthropics/claude-code-action リポジトリのドキュメントに、issues: opened をトリガーにした完全な例が載っています。権限は issues: write と id-token: write の2つだけ。用意したスクリプト（ラベル編集用・GitHub操作用の2本）だけを許可リストに入れ、それ以外は触らせません。

ここで効いてくるのが権限の絞り方です。レビューのワークフローは contents・pull-requests・issues を読み取りだけで済ませているのに対し、トリアージは issues を書き込みで持ちます。同じ仕組みでも、やらせたい仕事が変われば渡す権限も変えます。これは後半でもう一度出てきます。

決まった時刻に動かす（schedule）

3つ目は、人の行動をきっかけにせず、時刻だけをきっかけにする方法です。公式ドキュメントの「Run on a schedule」は「Daily Report」という名前で、毎日9:00 UTCに動き、GitHub用のMCPツールで前日のコミットとIssueを要約します。同じリポジトリのドキュメントには、毎週日曜0時に依存関係の点検・npm audit・古いIssueの棚卸しを1つのIssueにまとめる「Weekly Maintenance」の例もあります。

Actionsで自分で書くか、マネージドに任せるか

ここまでの3つは、すべて自分でワークフローファイルを書いて維持するやり方です。同じ目的を、ワークフローを持たずに実現する選択肢も用意されています。

マネージドのCode Reviewは、有効にした後も動くタイミングをリポジトリごとに選べます。組織のOwnerがadmin settingsで一度有効化した後、対象リポジトリごとに「PR作成時のみ」「毎プッシュ」「手動」のどれかを選びます。手動を選んだ場合は、PRのコメントで @claude review と書けばその場で一度だけ、@claude review always と書けば以降のプッシュもレビュー対象に登録されます。ワークフローファイルの on: を書き換えなくても、この設定変更だけで頻度を調整できるのがマネージド版の利点です。

Routinesはレビューだけの機能ではなく、この章の「決まった時刻に動かす」の受け皿でもあります。cronを自分で書きたくなければ、RoutinesのScheduledトリガーで同じことができます。ただし成果物は実行した本人のアカウント名義になります。チームの成果として履歴に残したいなら、Actionsで書いて残す方が向いています。

暴走させないための設定

自動で動くということは、誰も見ていない時間にClaudeが判断し続けるということでもあります。公式ドキュメントがコスト対策として挙げている項目は、そのまま暴走対策としても読めます。

最後の権限の最小化は、前の2つの例がそのまま実例です。レビューのワークフローは contents・pull-requests・issues を読み取りだけ持ち、書き込みを渡すのは id-token だけです。差分を読んでコメントを残すだけなら、コードやIssueへの書き込み権限は要りません。対してトリアージのワークフローは、ラベルを付け替える仕事のために issues と id-token を両方書き込みで持ちます。仕事の中身が変われば、渡す権限の質も変わります。

jobs:
  review:
    timeout-minutes: 15
    concurrency:
      group: claude-review-${{ github.event.pull_request.number }}
      cancel-in-progress: true
    permissions:
      contents: read
      pull-requests: read
      issues: read
      id-token: write
    steps:
      - uses: anthropics/claude-code-action@v1
        with:
          claude_args: "--max-turns 5"

timeout-minutes と concurrency はGitHub Actions自体の標準機能、permissions の中身と claude_args・@v1 の指定がClaude Code側の設定です。

今日のまとめ

• PRの自動レビュー、Issueの分類、定期実行は、どれも同じ claude-code-action にトリガーとプロンプトを変えて乗せているだけ
• automation modeの結果は既定でワークフロー実行ログにしか出ない。見える形にするにはプロンプト側で指示が要る
• ワークフローを自分で書く代わりに、マネージドのCode ReviewやRoutinesに任せるという選択肢もある

自動化したレビューやIssue整理を、チームがどう受け止めるかは別の話です。次のレッスン「AIが書いた変更をチームで受け止める」で、レビュー規約とコストの見える化を扱います。