GitHub上のプロジェクトを持っていて、issueやPRに @claude とコメントするだけでClaudeに実装・修正・PR作成を任せたい人向け
GitHub上で開発が回っているプロジェクトで、issueやPRのコメントに「@claude これ実装して」「@claude このバグ直して」と書くだけでClaudeにコードを書かせPRまで作らせたい場面で、まずターミナルで /install-github-app を叩いて導入する。設計の相談だけ投げる使い方や、cronで毎朝サマリーを自動生成させる使い方もできる。
GitHub上のプロジェクトのissueやPRに「@claude これ実装して」と書き込むだけで、Claudeがコードを読んで、機能を足したり、バグを直したり、PRまで作ってくれる仕組みです。公式の説明そのままだと「a simple @claude mention in any PR or issue, Claude can analyze your code, create pull requests, implement features, and fix bugs」。つまりコメント1個が作業依頼になる、という発想です。
毎回ターミナルでClaude Codeを立ち上げて指示を出す、というやり方の手前を省く感じですね。チームのやり取りがすでにGitHub上で回っているなら、その場でClaudeに振れる。これが効いてくる場面は意外と多いです。
噛み砕くと、社内チャットに常駐してる実装担当を呼ぶ感じ
新しい職場に、コードを任せられる担当が1人ジョインした状況を想像してみてください。あなたは席まで歩いていって口頭で頼む必要はなくて、いつものチャットで「@その人 ログイン機能お願い」と書けば動いてくれる。GitHub Actionsで入るClaudeはこれに近いです。
違うのは、その担当が動く場所。あなたのGitHubの中の作業用マシンで動きます。公式も「Your code stays on Github's runners」と書いていて、コードが外に丸ごとコピーされて処理されるわけではない。ここは地味に安心できるポイントです。
あと、勝手にジョインはしてくれません。最初に1回、迎え入れる作業が要ります。そこは後で実演します。
大事な前提:これは「呼んだら実装する」仕組み。自動レビューだけが欲しい人は別物を見る
ここを取り違える人がいちばん多いので先に潰します。Claude Codeには名前の似た2つのGitHub連携があります。
1つがこのGitHub Actions。@claudeと呼ぶと動いて、実装・修正・PR作成まで何でもやらせられる。Claude APIのkey(後述)があれば、どのプランでも入れられます。
もう1つがCode Review。こっちは呼ばなくても全部のPRに自動でレビューが付くAnthropic運用のサービスで、Team / Enterpriseプラン限定です。公式も「For automatic reviews posted on every PR without a trigger, see GitHub Code Review」と、わざわざ案内を分けています。
「とにかく毎回のPRに自動でコメントしてほしいだけ」ならCode Review。「呼んだら実装やバグ修正やPR作成までやってほしい」ならGitHub Actions。求めてるものが違うと、入れても期待した動きになりません。
「料理ブログのプロジェクト」を例に、実際の手順を見る
題材は、私が料理ブログをGitHubで管理していて、「レシピ名と材料で検索できる機能」をissue経由でClaudeに作らせる、という流れです。頭の中で再現できるように順番に追います。
ステップ1: 前提を確認する
2つだけ要ります。1つ目は、その料理ブログのプロジェクトのadmin権限。2つ目は、console.anthropic.com で取ったClaude APIのkey。公式も「You must be a repository admin to install the GitHub app and add secrets」と明記していて、admin権限がないと次のステップで詰まります。
ステップ2: ターミナルで /install-github-app を叩く
いちばん楽な入れ方がこれです。ターミナルでClaude Codeを開いて、そのまま打ちます。
$ claude
> /install-github-app
公式いわく「This command will guide you through setting up the GitHub app and required secrets」。案内に沿って進めるだけで、面倒な準備をまとめて済ませてくれます。
ステップ3: 案内に沿ってGitHub Appとsecretを入れる
途中でブラウザが開いて、Claude GitHub Appをこの料理ブログのプロジェクトに入れる許可を求められます。求められる権限は Contents / Issues / Pull requests の読み書き。あわせて、ステップ1で取ったAPI keyを ANTHROPIC_API_KEY という名前のsecretとして登録します。
ここで初心者がやりがちな勘違いを1個。API keyを焦ってworkflowファイルやコードに直接書き込もうとする人がいますが、それは事故のもとです。公式も「Never commit API keys directly to your repository」とはっきり書いている。keyは必ずsecretに入れて、呼び出すときは ${{ secrets.ANTHROPIC_API_KEY }} と参照します。
ステップ4: 入ったworkflowファイルを確認する
セットアップが終わると、料理ブログのプロジェクトの .github/workflows/ という場所に claude.yml が置かれます。中身はだいたいこんな最小形です。
name: Claude
on:
issue_comment:
types: [created]
pull_request_review_comment:
types: [created]
jobs:
claude:
runs-on: ubuntu-latest
steps:
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
anthropics/claude-code-action@v1 がClaudeを動かす本体で、anthropic_api_key に先ほどのsecretを渡しているだけ。issue_comment はissueのコメント、pull_request_review_comment はPRのコード上のコメントへの反応で、この2つを書いておくとどちらの「@claude」にも反応します。片方しか書かないと、もう片方では呼んでも無反応になります。
ステップ5: issueを立てて @claude と書く
ここが本番です。GitHubで新しいissueを立てるか、既存のissueのコメント欄に、こう書きます。
@claude レシピ名と材料で検索できる機能を実装して
公式のコメント例も「@claude implement this feature based on the issue description」という、まさにこの形です。書いて投稿した瞬間にworkflowが走り出します。
ステップ6: ClaudeがコードとPRを作る → 人がレビューしてマージ
少し待つと、runner上でClaudeがコードを書いて、検索機能を足したPRを作ってくれます。しかもこのとき、プロジェクトに置いてある CLAUDE.md のルールも見てくれる。公式が「Follows your standards」「Claude respects your CLAUDE.md guidelines」と言っている部分です。
ただし、できたPRが自動でマージされることはありません。公式も「Review Claude's suggestions before merging」と釘を刺しています。検索の中身を私が読んで、納得したら取り込む。最後の判断は人が握ったままです。
つまり GitHub Actions は何をしてくれるのか
- やってくれる: @claudeと呼ぶと、issueの内容からコードを書き、バグを直し、PRを作る。CLAUDE.mdのルールにも従う。cronなどで毎朝サマリーを自動生成する、といった呼ばずに即実行する使い方もできる
- やってくれない: 自動マージはしない(取り込むのは人の判断)。呼ばないと動かない(@claudeのコメントが合図)。「/claude」と打っても無反応で、公式トラブルシュートも「confirm the comment contains @claude (not /claude)」と注意している
- 意味が薄い場面: 「呼ばなくても毎PRに自動レビューだけ欲しい」場合。それはCode Review(Team/Enterprise限定)の役目で、こちらを入れても用途が噛み合わない
使いどころ3シナリオ(具体題材で再現)
シナリオ1: 料理ブログに「材料から逆引き検索」を足したいとき
「冷蔵庫の余り物から作れるレシピを探したい」という要望をissueに書いて「@claude 材料の組み合わせで絞り込める検索を実装して」と投げる。Claudeが既存のレシピデータの持ち方を読んだ上で、検索機能を足したPRを返してきます。私はPRの差分を見て、検索が日本語の表記ゆれにも耐えるか確認してからマージ。手元のターミナルを開かずに、ブラウザのGitHub画面だけで完結するのが楽です。
シナリオ2: 家計簿アプリのバグ報告がissueで上がってきたとき
「ダッシュボードで金額を入れるとエラーが出る」とissueが立った。そこに「@claude fix the TypeError in the user dashboard component」と書く。これは公式のコメント例そのままで、Claudeが該当箇所を読んで修正PRを作ります。バグ報告のissueがそのまま修正依頼になるので、報告→修正の間に人が状況を整理し直す手間が減ります。正直これは効率いいです。
シナリオ3: 設計の相談だけしたいとき
必ずしも実装させなくてもいい。「@claude how should I implement user authentication for this endpoint?」のように、方針を聞くだけの使い方も公式が例に挙げています。料理ブログに会員機能を足すか迷っている段階で、issueに認証のやり方を相談する。コードを書かせる前に、設計の壁打ち相手として使えるわけです。
初心者が踏みやすい落とし穴
- Code Reviewと混同して入れる。これは@claudeで呼んで実装まで任せる仕組み。呼ばずに毎PR自動レビューだけ欲しいなら別物のCode Review(Team/Enterprise限定・Anthropic運用)を見る。求めるものが違うと空振りする
- 「/claude」と書いて動かないと悩む。正しくは「@claude」。公式トラブルシュートでも「@claude (not /claude)」と名指しで注意されている。スラッシュではなくアットマーク
- admin権限がないのに入れようとする。GitHub Appの導入とsecret追加には、そのプロジェクトのadmin権限が要る。権限がないと途中で止まる
- API keyをコードやworkflowに直書きする。「Never commit API keys directly to your repository」。必ずsecretに入れて
${{ secrets.ANTHROPIC_API_KEY }}で参照する。直書きは漏洩事故に直結する - /install-github-appが万能だと思う。この楽な入れ方はClaude APIを直接使う人向け。Amazon BedrockやGoogle Vertex AI経由で使う企業は手動セットアップになり、workflowに
use_bedrock: "true"かuse_vertex: "true"を足す。このときanthropic_api_keyの代わりに各クラウド側の認証設定が前提になる。独自のGitHub Appを使うのが公式推奨です - 古いworkflowのまま放置する。beta版からv1.0で書き換えが要る変更が入った。
@beta→@v1、direct_prompt→prompt、mode指定は廃止(自動判定に)、custom_instructionsやmax-turnsやmodelなどはclaude_argsにまとめて渡す形になった。古い書き方のままだと動かない - 料金が1種類だと思い込む。費用は2重にかかる。GitHubのrunnerの稼働時間と、ClaudeのAPIのtoken代。
claude_argsに渡す--max-turns(標準10)やworkflowのtimeoutで、暴走して延々動き続けるのを防ぐ - できたPRを中身を見ずにマージする。自動でマージはされない=裏を返せば、取り込むかは人の責任。公式も「Review Claude's suggestions before merging」。検索やバグ修正の中身を必ず読んでから取り込む
- 標準モデルがOpusだと思う。標準はSonnet。Opus 4.7を使いたいなら
claude_argsに--model claude-opus-4-7を渡す。v1.0では直接のmodel指定は廃止されていて、claude_args経由が正しい書き方です。指定しなければSonnetで動く
書き方
@claude (issue / PR のコメント欄に書く)
# 導入: ターミナルで claude を開いて /install-github-app
やってみるとこうなる
入力
@claude レシピ名と材料で検索できる機能を実装して
出力例
workflowが走り、Claudeが料理ブログのコードを読んで検索機能を足したPRを作成。CLAUDE.mdのルールにも従う。人が中身を確認してマージすると反映される(自動マージはされない)。
このページに出てきた言葉
- issue
- GitHub上で「これ直して」「ここバグってる」を1件ずつ立てておく掲示板のような機能
- PR
- Pull Requestの略。「この変更を本体に取り込んでください」と提案する単位。中身を見て問題なければ取り込む
- @claude mention
- issueやPRのコメント欄で「@claude」と打って呼びかけること。これがClaudeへの作業の合図。<code>/claude</code> では動かない
- GitHub App
- GitHubに権限を持って常駐する小さなアプリ。Claudeがコードを読み書きしPRを作るために入れて許可を渡す
- secret
- GitHubが安全に預かる秘密の保管庫。API keyのような文字列を入れ、コードからは <code>${{ secrets.ANTHROPIC_API_KEY }}</code> のように名前で呼び出す
- runner
- GitHub Actionsが処理を実際に動かす作業用マシン。Claudeはこの中でコードを書く。コードは外に出ずGitHub側にとどまる
- workflow
- 「どういう時に何を動かすか」を書いたルール表。<code>.github/workflows/</code> という場所に置いた <code>.yml</code> ファイルが自動で読まれる
- claude_args
- Claude Code本体への指定をまとめて渡す入れ物。<code>--max-turns</code>(標準10)や <code>--model</code> をここに書く