SECTION 01
Claude Code Actionで何が自動化できるのか
Claude Code Actionは、Anthropicが公式に提供しているGitHub Actions向けのアクションです。PRへのコードレビューコメントの自動投稿、Issueからのブランチ作成・実装・PR作成の補助、コミットメッセージやPR本文の自動生成といった作業をCI上で動かせます。
できることを整理すると、大きく3つの領域に分かれます。
- PRレビューの自動化: プルリクエストが開かれたタイミングでコード差分を読み、レビューコメントを投稿する
- Issue対応の自動化: 特定ラベルのIssueをトリガーにして、ブランチ作成から実装・PR用ブランチの作成まで進める
- PR文章・コミットメッセージの自動生成: 差分内容をもとに、人間が読みやすい形で変更内容を要約する
デフォルトの動作では、PRを完全に自動作成するのではなく、ブランチにコミットしたうえで事前入力済みのPR作成ページへのリンクを提示する形になります。最終的なPR作成は人間が確認してから行う設計です。
自分の場合、Claude Code ActionはDevinの代替として動かしているイメージに近いです。手元のエディタで進めながら、Issueを複数起票してClaude Code Action側に並列で投げる。指示を出したら並列で仕事が進む感覚があります。
Devinはマネージドなぶん依存が強くなりますが、Claude Code Actionはリポジトリに密着して動くので自分でコントロールしやすいのが特徴です。コストもAPIの従量課金とGitHub Actionsの実行コストで構成されるため、個人開発者にとっては現実的な選択肢になります。
SECTION 02
最小構成のYAMLとSecrets設定——コピペで動くPRレビュー自動化
まず動く状態を作るのが最優先です。公式のanthropics/claude-code-actionを使えば、最短ではYAMLファイルひとつとAPIキーの登録だけでPRレビューの自動化を試せます。
ただし実運用では、Claude GitHub Appの導入が前提になります。GitHub AppにはContents・Issues・Pull requestsのread/write権限が必要です。認証方法もAPIキーだけでなく、OAuth、Bedrock、Vertex AIなど複数の選択肢があるので、チームの環境に合った方式を選んでください。
最小構成のYAMLでは、トリガーにpull_requestとissue_commentを指定します。必要なパーミッションは以下の通りです。
- contents: read — リポジトリのコードを読み取る権限
- pull-requests: write — PRにレビューコメントを書き込む権限
- issues: write — Issueへのコメント権限（Issue対応を使う場合）
- id-token: write — デフォルトのGitHub App認証で必要な権限
CI結果をClaudeに読ませたい場合は、追加でactions: readを設定します。こちらは最小構成では必須ではなく、CI連携を使う場合のオプションです。
Secretsの登録は、リポジトリのSettings → Secrets and variables → ActionsからANTHROPIC_API_KEYを追加します。Organization全体で使う場合はOrganization Secretsに登録すると、リポジトリごとの設定が不要になります。
トリガー条件の選び方は用途によって変わります。PRレビューだけならpull_requestのopenedとsynchronizeで十分です。Issueからの自動実装も使うならissuesのopenedとlabeledを追加します。
初回の動作確認は、小さなPRを1本出してみるのが確実です。Actions タブでワークフローの実行ログを確認し、レビューコメントがPRに投稿されていれば成功です。エラーが出る場合はパーミッションの不足がほとんどなので、ログのエラーメッセージを見て権限を追加してください。
SECTION 03
レビュー精度を上げるプロンプト設計——ノイズを減らす実践テクニック
デフォルト設定のまま動かすと、スタイルの細かい指摘やフォーマットの統一提案が大量に飛んでくるのが最初の壁です。実務で使えるレベルにするには、システムプロンプトで「何を見て・何を無視するか」を明示する必要があります。
効果的なプロンプト設計のポイントは3つあります。
- レビューの焦点を絞る: 「セキュリティ上の問題」「ロジックのバグ」「パフォーマンスの劣化」に限定し、スタイルや命名規則の指摘は抑制する
- プロジェクト固有の文脈を渡す: CLAUDE.mdにアーキテクチャ方針や使用ライブラリの規約を書いておく
- 無視すべきファイルを指定する: ロックファイルや自動生成コード、テストのスナップショットなどはレビュー対象外にする
CLAUDE.mdの活用がレビュー精度を最も大きく改善する要素です。プロジェクトのディレクトリ構造、状態管理の方針、テストの書き方のルールなどを書いておくと、文脈を踏まえた指摘が返ってくるようになります。逆にCLAUDE.mdがないと、一般的なベストプラクティスを押しつけるだけの指摘になりがちです。
大きなPRや複数ファイルにまたがる変更では、Claudeのコンテキストウィンドウの広さが活きるケースと、逆に焦点がぼやけるケースがあります。ファイル間の依存関係が強いリファクタリングでは的確な指摘が来やすく、無関係な機能を1つのPRにまとめた場合はノイズが増えます。
つまり、Claude Code Actionの精度はPRの切り方にも依存するということです。1つのPRで1つの関心事を扱うという基本原則が、AI レビューでもそのまま効いてきます。
SECTION 04
Issue対応の自動化——Issueを立てたらPR用ブランチが返ってくる仕組み
Claude Code Actionの真価が出るのは、Issueをトリガーにした自動実装です。特定のラベル（たとえばclaude）が付いたIssueを検知して、ブランチ作成→コード変更→PR作成ページへのリンク提示までを自動で進めてくれます。
IssueトリガーのYAML設定では、issuesイベントのlabeledアクションを使います。ラベル制御を入れることで、すべてのIssueに反応するのではなく、明示的に依頼したものだけを処理させられます。誤動作の防止にもなるので、ラベルによるフィルタリングは必須です。
Issueの書き方で精度が大きく変わります。
- タスクの粒度は小さく: 「認証機能を作って」ではなく「ログインAPIのバリデーションを追加して」レベルまで分解する
- 受け入れ条件を明記する: 「どうなっていれば完了か」を箇条書きで書く
- 変更対象のファイルやディレクトリを示唆する: Claudeが探索する範囲を狭めることで精度が上がる
これまでの試行錯誤の中で見えてきたのは、複数のIssueを並列で投げると擬似的な開発チームになるということです。手元のエディタで本丸の機能を進めながら、周辺タスクをIssueとしてClaude Code Actionに投げる。それぞれがブランチとして返ってくるので、PRを確認してマージするだけで開発が進みます。
ただし並列で投げるほど、どのIssueが完了してどのPRが待ちなのかの管理が必要になります。GitHubのProjectsボードやラベル運用でステータスを可視化しておかないと、確認漏れが起きやすくなります。
SECTION 05
Devin代替としてClaude Code Actionを並列運用している実例
自分がClaude Code Actionを本格的に使い始めたのは、手元のエディタとの並列開発が成立すると分かったときでした。エディタでメインの機能を書きながら、Claude Code Actionにはリファクタリングやテスト追加、ドキュメント更新といったサブタスクを任せています。
PR本文やコミットメッセージの作成も、もはやClaude Codeに任せきりです。「変更内容をプルリクエスト用に日本語で書き出してください」と頼むだけで、自分で書くより整理されたものが返ってきます。差分からコミットメッセージを生成してPRを出すところまで一連の流れで任せるのが日常になりました。
ただし、使えるエージェントが増えるほど管理コストが先に爆発するという問題があります。どのタスクが終わったのか、どのエージェントが何をしているのか、確認するだけで時間が溶けていきます。並列化の恩恵を受けるには、管理の仕組みを先に設計する必要があります。
管理の設計としてやっていることは以下の通りです。
- 1 Issueに1タスク: 粒度を揃えて、完了判定を明確にする
- ラベルでステータス管理: claude-working / claude-done / needs-reviewのようにフェーズを可視化する
- PRのレビューは人間が最終判断: 自動マージはせず、必ず目を通してからマージする
個人開発の初期段階に無理にこの仕組みを入れる必要はないと考えています。手動デプロイで数分で終わる段階なら、その自動化は後回しでいいです。プロダクトが育ってきてPRの頻度が上がったタイミングで導入するのが、時間対効果の面で合理的です。
SECTION 06
セキュリティとデータ送信の確認ポイント
Claude Code Actionを導入する際に必ず確認すべきなのが、APIに送信されるデータの範囲と取り扱いです。
GitHub Actionsの公式ドキュメントでは、コードはGitHubランナー上に留まると説明されています。ただし、Claude Code自体はコードベースを読み、ファイルを編集し、コマンドを実行できるツールです。実際にAPIへ送信されるデータの範囲は、ワークフローの設計や実行内容に依存するため、「差分だけが送られる」と一概に断定することはできません。ワークフローのログで実際の送信内容を確認するのが確実です。
データの学習利用については、認証方法によって扱いが異なる点に注意が必要です。
- APIキーやTeam/Enterpriseなどの商用条件では、明示的なオプトインがない限り、送信データはモデルの学習に使用されません
- Free / Pro / MaxなどのconsumerアカウントでOAuth認証を使う場合、設定によってはClaude Code経由のデータもモデル改善に使われる可能性があります
チームで導入する場合は、どの認証方法を使うかによってデータの扱いが変わることを踏まえて、自社のセキュリティポリシーと照らし合わせて確認するプロセスを踏むべきです。
チーム導入前に確認すべきポイントを整理します。
- 送信範囲の把握: どのファイルがAPIに送られるかをワークフローのログで確認する
- 認証方法の選定: データの学習利用ポリシーを踏まえ、APIキー認証か商用プランかを選ぶ
- シークレットの管理: APIキーはOrganization Secretsで一元管理し、個人のキーを使い回さない
- アクセス制御: claude_argsに--allowedToolsを渡して使用できるツールを制限し、ファイル操作やコマンド実行の範囲を絞る
- 実行回数の制限: claude_argsに--max-turnsを渡して、想定外のループを防止する
とくに--allowedToolsと--max-turnsは、動作範囲を制限する安全弁として重要です。レビュー用途であればファイルの読み取りとコメント投稿だけに絞り、コードの書き換えや外部コマンドの実行は許可しない設定にするのが安全です。
社内の承認プロセスを通す場合は、テスト用のプライベートリポジトリで動作を検証してからプロダクションに適用する流れが確実です。いきなり本番リポジトリに入れるのではなく、段階的に導入範囲を広げていくのがトラブルを防ぐコツです。
SECTION 07
Hook・Subagent・Actionの役割分担——自動化が破綻しない設計
Claude Code周辺にはAction・Hook・Subagentという3つの自動化レイヤーがあります。それぞれの守備範囲を理解しておかないと、責務が重複したり抜け落ちたりして運用が混乱します。
3つの役割を整理すると以下の通りです。
- Action: GitHub Actions上で動く自動トリガー。PRやIssueをきっかけにCI環境で実行される
- Hook: ローカル環境での前後処理。コミット前のリント実行やレビュー後の自動フォーマットなど
- Subagent: Claude Code内部でのタスク分担。メインのタスクから切り出した作業を並列に処理する
どこまでActionに任せ、どこから人間が判断するかのラインを決めておくのが最も重要です。自分の場合、Actionにはレビューコメントの投稿とPR文章の生成までを任せ、マージ判断は必ず人間がやると決めています。
Hookはローカルの開発体験を整えるものなので、チームメンバー全員が同じ環境でなくても動く設計にします。Actionはリポジトリ単位の共通ルール、Hookは個人の作業環境に合わせた補助、という棲み分けが自然です。
コーディングの速度が上がると、次のボトルネックは動作確認に移ります。コードを書いた後に「それが意図通り動くか」を目で見て確認する作業が残っていて、ここの自動化が次の課題です。Action でレビューを自動化しても、最終的な動作検証を人間がやるフローは変わりません。
自動化の設計で大事なのは、すべてを自動化しようとしないことです。判断が必要な部分は人間に残し、定型的な部分だけを自動化する。このバランスを間違えると、自動化が逆に負債になります。
SECTION 08
導入タイミングの判断軸——今の開発に本当に必要か
Claude Code Actionは強力ですが、すべてのプロジェクトに最初から入れるべきものではないです。導入の判断軸は「その自動化が今の自分の開発ペースに必要か」というシンプルな問いに帰着します。
導入が効果的なタイミングの目安は以下の通りです。
- PRの頻度が週に数本以上ある: レビューの手間が積み上がっている状態
- チームで開発している: 他人のコードを読む時間を短縮したい
- 定型的な修正が繰り返されている: 同じ指摘を何度もしている
逆に、個人開発の立ち上げ期でPRが週に1本あるかどうかの状況なら、その時間はプロダクトの改善に使ったほうがいいです。手動で十分回る段階で自動化の仕組みを整えるのは、時間の使い方として非効率です。
AIとの開発の関係は段階ごとに変わっていくものです。最初はコンテキストを工夫してコードを書かせる段階。次にClaude Code ActionやDevinでタスクを依頼して並列に進めるフェーズ。自分の関与は判断と承認だけに絞っていくのが、この先の方向だと考えています。
まずは小さなPRでレビュー自動化だけ試すのが最もリスクの低い始め方です。効果を実感できたらIssue対応に広げ、並列運用のフローを作っていく。段階的に導入範囲を広げることで、自動化が破綻するリスクを抑えられます。
SECTION 09
実務で効くYAML設定のカスタマイズ例
最小構成で動かした後に調整したくなるのが、トリガー条件の細かい制御です。すべてのPRにレビューを走らせると、依存ライブラリの更新やドキュメント修正など、レビュー不要なPRにもコストがかかります。
よく使うカスタマイズのパターンをまとめます。
- パスフィルターの追加: pathsで特定のディレクトリ配下の変更だけをトリガーにする
- ラベルによるスキップ: skip-reviewラベルが付いたPRではワークフローを実行しない
- ドラフトPRの除外: ドラフト状態のPRはレビューを走らせず、Ready for Reviewになったタイミングでトリガーする
システムプロンプトのカスタマイズもYAML内のwithパラメータで渡せます。レビューの厳しさや注目すべき観点をここで指定すると、CLAUDE.mdとの二段構えでレビューの方向性を制御できます。
ワークフローの実行時間とコストも気になるポイントです。claude_argsに--max-turnsを小さめに設定しておくと、想定以上のトークンを消費するケースを防げます。レビュー用途なら差分を読んでコメントするだけなので、大きな値は不要です。
なお、コストはClaude APIのトークン消費に加えてGitHub Actionsのランナー実行時間も発生します。大きなPRが頻繁に出るリポジトリでは、パスフィルターやドラフトPRの除外で不要な実行を減らすことが、両方のコスト削減につながります。
複数リポジトリで同じ設定を使い回すなら、Reusable Workflowとして切り出すのが効率的です。共通のYAMLをひとつのリポジトリに置いて、各リポジトリから参照する形にすると、設定の変更を一元管理できます。
SECTION 10
よくあるつまずきと対処法
導入直後に多いのが、パーミッション不足によるエラーです。GitHub Actionsのワークフローに書いたpermissionsと、リポジトリの設定で許可されている権限が食い違っていると動きません。Actionsタブのログにエラー内容が出るので、まずそこを確認します。
とくにid-token: writeの設定漏れは見落としやすいポイントです。デフォルトのGitHub App認証ではこの権限が必要なので、エラーが出たら最初に確認してください。
もうひとつ多いのが、レビューコメントが多すぎて逆にノイズになるパターンです。これはシステムプロンプトの調整で改善できます。
- 「スタイルに関する指摘は行わないでください」と明示する
- 「重大度が高い問題だけを報告してください」とフィルタリング条件を入れる
- 無視するファイルパターンを具体的にリストアップする
APIキーの請求額が想定を超えるケースもあります。大きなPRが頻繁に出るリポジトリでは、差分のトークン数が膨れやすいです。パスフィルターやドラフトPRの除外で、不要な実行を減らすのが第一の対策です。
Issue対応の自動化では、Claudeが想定外のファイルを変更してしまうことがあります。Issueの記述が曖昧だと変更範囲が広がりやすいので、対象ファイルや変更方針をIssueに明記する習慣が大事です。
トラブルシューティングの基本は、Actionsのログを丁寧に読むことです。Claude Code Actionはログに実行過程を出力するので、どの段階で何が起きたかを追えます。闇雲に設定を変えるより、ログから原因を特定するほうが早く解決します。
