「@claudeとメンションすればIssueからプルリクエストまで全部自動、と聞いて設定したのに、思っていた動きと違う」
「解説記事によって手順も料金の説明もバラバラで、どれが今の正解なのか分からない」
この記事は、そんな混乱を解きほぐすClaude CodeとGitHubの連携ガイドです。ひとくちに「GitHub連携」と言っても、仕組みも料金も違う4つの別物が存在します。最初に4つの全体像を整理したうえで、今日から使える方法からGitHub Actionsで@claudeを動かす手順までを、公式ドキュメント(英語版)と公式リポジトリの一次情報を根拠に解説します。
扱う範囲は次の4つです。①Claude Codeに手元のPCでgit操作をさせる方法、②GitHub Actionsで@claudeに応答させる方法、③自動レビュー製品(Code Review)との違い、④GitHub MCPサーバーの位置づけ。「GitHubでclaude codeのソースコードを探している」という方への案内も後半にあります。
- 「GitHub連携」と呼ばれる4つの方法の違いを人に説明できるようになる
- Pro/MaxプランのままAPI課金なしでGitHub Actions連携を使う設定(
claude setup-token) /install-github-appの前提条件(gh CLIと2つのスコープ)と4ステップの手順- 「@claudeはPRを自動作成しない」という公式仕様の正確な理解
- @claudeが反応しないときの公式チェック5項目と、古い解説記事の見分け方
Claude CodeとGitHubの連携とは?【4つの方法を最初に整理】
Claude CodeとGitHubの連携とは、AIコーディングツールのClaude Codeに、GitHub上のコード・Issue・プルリクエストを読み書きさせる仕組みの総称です。
Claude Code自体をまだ触ったことがない方は、先にClaude Codeとは何かで全体像をつかんでおくと、この後の話がすんなり入ります。
そもそも何ができるようになるのか
- 手元のPCで:「この変更をコミットして」「プルリクエストを作って」と日本語で頼むだけで、Claude Codeがgitコマンドを代わりに実行してくれます
- GitHub上で:IssueやプルリクエストのコメントでClaudeを呼ぶと、GitHub側で動くClaudeが修正をブランチに反映して返してくれます
- レビューで:プルリクエストの内容をAIが自動でチェックする「Code Review」という製品もあります
用語もここで押さえておきましょう。リポジトリはコードの保管場所、Issueは課題やバグを記録するメモ、プルリクエスト(PR)は「この変更を取り込んでください」という提案、GitHub ActionsはGitHub上で決まったきっかけをもとにプログラムを自動実行する仕組みです。
【重要】「GitHub連携」と呼ばれるものは4種類ある
同じ「Claude CodeのGitHub連携」という言葉が、実際には次の4つのどれかを指しています。
| 方式 | 呼ばれ方 | 動く場所 | 動かし方 | 課金 |
|---|---|---|---|---|
| A | ローカルのgit・GitHub操作 | 自分のPC | Claude Codeに日本語で指示 | プランの利用枠 |
| B | GitHub Actions連携(claude-code-action) |
自分のリポジトリのGitHub Actions | Issue・PRで@claudeとメンション |
Actions実行時間+トークン(API課金またはサブスク枠) |
| C | Code Review(@claude review) |
Anthropicのインフラ | PR作成時などに自動実行 | usage credits(プラン枠とは別) |
| D | GitHub MCPサーバー | ローカルまたはActionsの中 | Claudeが必要なときにツールとして呼ぶ | トークン消費 |
解説記事の多くはこの4つを区別せずに「GitHub連携」と呼んでおり、記事によって手順や料金の説明が食い違って見える最大の原因になっています。本記事ではA〜Dを順に解説します。
初心者はどれから始めるべき?
結論は、方法A(ローカルのgit操作)から始めて、慣れたら方法B(GitHub Actions)に進むです。方法Aは追加設定なしで今日から使え、方法BはIssue対応やPRレビューをGitHub上で回せる本命の連携です。方法CはTeam・Enterpriseプラン限定で、組織の管理者による設定と別課金が前提なので、個人が急いで触る必要はありません。方法Dは応用編で、詳細はMCPの設定ガイドに委ねます。
【前提】料金はかかる?Pro・Maxプランでも使える?
Claude Code自体は無料プランでは使えない
公式セットアップページには「Claude CodeにはPro、Max、Team、Enterprise、Consoleいずれかのアカウントが必要。無料のClaude.aiプランにはClaude Codeへのアクセスは含まれない」と明記されています(2026年8月時点)。連携の前に、まず有料プランまたはConsole(API課金)のアカウントが前提です。プラン選びに迷う方は料金プランの比較記事をどうぞ。
GitHub Actions連携は「API課金」でも「サブスク」でも使える
ここが日本語の解説で間違いの多いポイントです。Pro/Maxなどのサブスクリプションプランのまま、API課金なしでGitHub Actions連携を使えます。英語版公式ドキュメントの原文がこちらです。
CLAUDE_CODE_OAUTH_TOKEN: an OAuth token that authenticates with your Claude subscription, available on Pro, Max, Team, and Enterprise plans. Generate one by runningclaude setup-tokenlocally. (訳:CLAUDE_CODE_OAUTH_TOKENは、Claudeのサブスクリプションで認証するOAuthトークン。Pro・Max・Team・Enterpriseプランで利用でき、ローカルでclaude setup-tokenを実行して生成する)
コスト解説のページにも「OAuthトークンで認証した場合、実行分はAPI課金ではなくClaudeサブスクリプションの利用枠を使う」という趣旨の記載があります。API課金は必須ではありません。
【注意】日本語版の公式ドキュメントは記述が古い
公式ドキュメントの日本語版には「このクイックスタート方法は、直接 Claude API ユーザーのみが利用できます」という古い記述が残っています(2026年8月時点で確認)。英語版の同じ箇所は「Quick setup works with the Claude API and Claude subscriptions.(クイックセットアップはClaude APIとClaudeサブスクリプションの両方で使える)」に更新済みです。「GitHub Actions連携はAPI課金必須」と書いている日本語記事は、この古い日本語版が発生源とみられます。本記事は英語版を正として書いています。
かかる費用は2種類ある
公式ドキュメントは、GitHub Actions連携の実行ごとに消費されるリソースを2種類挙げています。
- GitHub Actionsの実行時間:GitHub側の課金です(Anthropicへの支払いとは別)
- トークン消費:API課金のユーザーは従量課金、OAuthトークンのユーザーはサブスクの利用枠を消費します
あわせて公式は、コストを抑える設定として次を挙げています。
@claudeへの指示を具体的に書く(あいまいな指示は試行回数が増える)- Issueテンプレートで前提情報を渡す
CLAUDE.md(プロジェクトのルールを書くファイル)を簡潔に保つclaude_argsで--max-turns(やり取り回数の上限)を設定する- ワークフローにtimeout(制限時間)を設定する
- concurrency(同時実行数)を制御する
認証方式は2つ:ANTHROPIC_API_KEYとCLAUDE_CODE_OAUTH_TOKENの違い
方法Bの設定で最初に迷うのが「どちらの認証にするか」です。違いを一覧にしました。
ANTHROPIC_API_KEY |
CLAUDE_CODE_OAUTH_TOKEN |
|
|---|---|---|
| 取得方法 | Claude Console(API管理画面)で発行 | 手元でclaude setup-tokenを実行 |
| 対応プラン | Console(API従量課金) | Pro / Max / Team / Enterprise |
| 課金のされ方 | API従量課金 | サブスクの利用枠を消費 |
| 有効期限 | – | 1年 |
| 向いている使い方 | チーム・組織の共有リポジトリ | 個人のリポジトリ |
Pro/Maxの人は claude setup-token でトークンを発行する
ターミナルで次を実行します。
claude setup-token
本体ヘルプに「長期間有効な認証トークンを設定する(Claudeサブスクリプションが必要)」と説明されているコマンドです。発行されるOAuthトークンの有効期限は1年で、公式の認証ドキュメントにも「generate a one-year OAuth token with claude setup-token(claude setup-tokenで1年間有効なOAuthトークンを生成する)」と明記されています(2026年8月時点)。同ページは、このトークンの利用にPro・Max・Team・Enterpriseいずれかのプランが必要とも記載しています。
発行時に「Store this token securely. You won't be able to see it again.(安全に保管してください。再表示はできません)」と案内される仕様です。表示されたらすぐ、GitHubリポジトリのシークレット(機密情報を安全に保存するGitHubの仕組み)にCLAUDE_CODE_OAUTH_TOKENという名前で登録しましょう。後述の/install-github-appウィザードを使う場合は、シークレット登録もgh secret setコマンド経由で代行してくれます。
チーム・組織のリポジトリならAPIキーを選ぶ
公式は、複数リポジトリで共有するシークレットにはOAuthトークンではなくConsoleのAPIキーを推奨しています。OAuthトークンは「claude setup-tokenを実行した本人のサブスクリプションに紐づく」ためで、担当者の交代がありうる環境では個人に紐づかないAPIキーのほうが運用しやすいという整理です。
方法A:Claude Codeから直接git・GitHubを操作する【まずここから】
前提:GitとGitHubアカウントがあればすぐ使える
方法Aに特別な連携設定はありません。必要なのはGitのインストール・GitHubアカウント・Claude Codeが動く環境の3つだけです。インストールがまだの方は始め方ガイドからどうぞ。
コミットもPR作成も日本語で頼める
Claude Codeのセッション内で、そのまま日本語で指示します。
- 「ここまでの変更内容を確認して、意味のある単位でコミットして」
- 「このブランチの変更をプルリクエストにして。説明文も書いて」
- 「直近のコミットの差分を確認して、問題がないかレビューして」
ブランチ名の相談や、コミットメッセージの書き直しにも応じてくれます。まずこの「対話でgitを扱う」感覚をつかむのが、方法Bに進む近道です。なおPRに紐づくセッションを再開する--from-prオプションも本体に用意されています(v2.1.205で確認)。
git操作をどこまで許可するか(--allowedTools)
「AIに勝手にpushされたら怖い」という方は、許可するツールを明示できます。claude --helpには許可指定の例として次の書式が示されています(v2.1.205で確認)。
claude --allowedTools "Bash(git *) Edit"
「git系コマンドの実行とファイル編集だけを許可する」という指定です。慣れるまで許可範囲を狭くしておき、分かってきたら広げる運用が安心です。
事前準備:GitHub CLI(gh)を入れて認証する【方法Bの必須前提】
方法Bに進む前に必要なのがGitHub CLI(gh)です。GitHubをコマンドラインから操作するGitHub公式のツールで、英語版公式ドキュメントはセットアップの前提として次のように明記しています。
Before you start, install the GitHub CLI and authenticate it with
gh auth login. Claude Code checks for it and warns you if it's missing. (訳:始める前にGitHub CLIをインストールし、gh auth loginで認証しておくこと。Claude Codeはghの有無をチェックし、無ければ警告する)
この前提に触れていない日本語の解説記事が多く、「手順どおりなのに進まない」原因になりがちです。先に済ませておきましょう。
インストール(Windows/Mac/Linux)
# Windows
winget install --id GitHub.cli
# macOS
brew install gh
Linuxは公式サイト(cli.github.com)の手順に従ってください。
gh auth login で認証する
gh auth login
表示される案内に従って、GitHubアカウントの認証を済ませます。
必要なスコープは repo と workflow
ghの認証には「どこまでの操作を許可するか」を決めるスコープという概念があります。Claude CodeのGitHub Actionsセットアップにはrepoとworkflowの2つが必要で、足りない場合はClaude Codeが次の修正コマンドを案内する実装になっています(v2.1.205で確認)。
gh auth refresh -h github.com -s repo,workflow
セットアップ途中でスコープ関連の警告が出たら、このコマンドを実行してから再開してください。
方法B:GitHub Actionsで@claudeを動かす【本命・4ステップ】
方法Bでは、Issue・PRのコメントで@claudeを呼べる状態を作ります。全体は「ウィザード実行→認証選択→作成物の確認→PRマージ」の4ステップです。以下の手順と画面文言は、英語版公式ドキュメントとClaude Code v2.1.205本体の実装に基づいています。
手順1:セッション内で /install-github-app を実行する
claudeを起動し、セッション内で次のスラッシュコマンドを入力します。
/install-github-app
ターミナルに直接打つコマンドではなく、Claude Codeのセッション内で使うスラッシュコマンドである点に注意してください。実行には対象リポジトリの管理者権限が必要です。ウィザードは最初にgh CLIの状態(インストール→認証→スコープ)を確認し、リポジトリの選択、Claude GitHub Appのインストール案内へと進みます。
v2.1.187より前のClaude Codeは、Appインストール後すぐワークフロー選択に進む画面でした。現在は「GitHub Actionsのワークフローを設定する」「今はスキップする(後で/install-github-appを再実行できる)」を選べる画面に変わっています(公式ドキュメント明記)。手元の画面が解説記事と違っても慌てなくて大丈夫です。
手順2:認証方法を選ぶ(サブスク or APIキー)
ウィザードの途中で認証方法を選びます。選択肢は「サブスクリプションプラン(Claude Pro/Max)」と「API従量課金(Claude Console)」の2系統です。個人利用ならサブスク認証で問題ありません。既存のANTHROPIC_API_KEYシークレットがあれば流用されます。
手順3:作成されるものを確認する
ウィザードが作成するのは次の3点です。
| 作成されるもの | 内容 |
|---|---|
| ブランチ | add-claude-github-actions-+タイムスタンプの名前で新規作成 |
| ワークフローファイル2つ | .github/workflows/claude.yml(@claude応答用)と.github/workflows/claude-code-review.yml(自動レビュー用) |
| シークレット | 手順2で選んだ認証に対応する名前で登録(APIキーならANTHROPIC_API_KEY、サブスクならCLAUDE_CODE_OAUTH_TOKEN)。登録はgh secret setコマンド経由 |
デフォルトでは2つとも作成されますが、選択画面で片方だけにもできます。
手順4:PRをマージして@claudeをテストする
ウィザードの最後に、内容が入力済みのPR作成ページが用意されます。このPRをマージすると連携が有効になります。テストは、Issueを立ててコメント欄に次のように書くだけです。
@claude このIssueの内容を確認して、修正案を出してください
Claudeがコメントに応答し、作業を始めれば成功です。
コピペで動く最小ワークフローYAML【2026年8月時点の現行形】
手動で設定したい方や、作られたファイルの中身を理解したい方向けに、現行のワークフローを載せます。公式リポジトリのexamples/claude.ymlについて、公式は「実際に動くワークフローであり、単なる例ではない」と明記しています。以下は主要部分の抜粋です。
on:
issue_comment:
types: [created]
pull_request_review_comment:
types: [created]
issues:
types: [opened, assigned]
pull_request_review:
types: [submitted]
jobs:
claude:
if: |
(github.event_name == 'issue_comment' && contains(github.event.comment.body, '@claude')) ||
(github.event_name == 'pull_request_review_comment' && contains(github.event.comment.body, '@claude')) ||
(github.event_name == 'pull_request_review' && contains(github.event.review.body, '@claude')) ||
(github.event_name == 'issues' && (contains(github.event.issue.body, '@claude') || contains(github.event.issue.title, '@claude')))
runs-on: ubuntu-latest
permissions:
contents: write
pull-requests: write
issues: write
id-token: write
actions: read # Required for Claude to read CI results on PRs
steps:
- uses: actions/checkout@v6
with:
fetch-depth: 1
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
このYAMLのポイント5つ
if::@claudeを含むコメントやIssueのときだけジョブを動かすための絞り込み条件です。この行がなくても連携自体は動きますが、関係のないコメント1件ごとにActionsのランナーが起動し、実行時間(=GitHub側の課金)を消費します。Claudeは起動後に「トリガー語がない」と判断して終了するためトークンはほとんど消費しませんが、無駄なので公式ファイルどおり残しておくのが安全ですanthropics/claude-code-action@v1:バージョン指定は@v1が現行です。v1は常に最新版を指す動くタグで、2026年8月12日時点の最新リリースはv1.0.191(v1タグも同じコミットを指しています)actions/checkout@v6:公式の現行例示は@v6です(@v4のままの解説記事は情報が古い可能性があります)id-token: write:Claude GitHub Appのデフォルト認証に必須と公式が明記しています。消すと動きませんactions: read:PRのCI(自動テスト)結果をClaudeに読ませるための権限です
サブスク認証(Pro/Max)に差し替える
サブスクの利用枠で動かす場合は、最後の行を次に差し替えます。
claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
事前にclaude setup-tokenで発行したトークンを、同名のシークレットとして登録しておいてください。
旧仕様(@beta)のYAMLは動かない・移行が必要
公式は「ワークフローがanthropics/claude-code-action@betaを参照したままなら、v1に更新すること」と明記しています。2026年8月時点でも、直近更新の日本語解説記事に@betaのYAMLが載っている例を確認しています。コピペ元が旧仕様かどうか、下の表で確認してください。
| 旧仕様(非推奨) | 現行(v1) |
|---|---|
anthropics/claude-code-action@beta |
anthropics/claude-code-action@v1 |
mode: "tag"/mode: "agent" |
廃止(自動判定に変更) |
direct_prompt |
prompt |
max_turns/model/allowed_tools |
claude_argsに--max-turns/--model/--allowedTools |
custom_instructions |
claude_args: --append-system-prompt |
なおモデルはopusやsonnetのようなエイリアス(常に最新版を指す別名)で指定できます(claude --helpの例示で確認)。具体的なモデル名を固定で載せた記事は、その部分から古くなりがちです。
@claudeメンションの使い方と前提条件
2つのモード:メンション待ちと自動実行
claude-code-actionの動作モードは、ワークフローの書き方で自動的に決まります。
- インタラクティブモード:ワークフローに
prompt入力がない場合。Claudeはトリガーフレーズ(デフォルトは@claude)を待ちます - オートメーションモード:ワークフローに
prompt入力がある場合。メンションを待たず、イベント発生時に自動で実行されます
この記事の手順で作られるclaude.ymlは前者です。
誰が@claudeを使えるのか(write権限+人間だけ)
公式仕様として、@claudeの実行前にトリガーした人への2つのチェックが走り、どちらかで拒否されると実行は失敗します。
- write権限チェック:Issue・PRイベントでは、トリガーしたユーザーにリポジトリのwrite権限(書き込み権限)が必要です
- 人間チェック:botによるトリガーは拒否されます(AI同士の無限ループ防止)
例外用の設定(allowed_non_write_usersやallowed_bots)もありますが、まずは「書き込み権限を持つ人間だけが呼べる」と覚えておけば十分です。外部の人が@claudeと書いても動かないのは、不具合ではなく安全側の仕様です。
トリガーは「@claude」の完全な単語だけ
トリガー判定は単語の区切りで行われ、@claudeが完全な単語として含まれている必要があります。公式FAQが挙げる動かない例は@claude-bot・@claude!・claude@mentionで、/claudeも不可と明記されています。トリガー語はtrigger_phrase設定で変更できます。
効果的な指示の書き方とCLAUDE.md
公式がコスト面からも推奨しているのは「具体的に頼む」ことです。
- 悪い例:
@claude なんとかして - 良い例:
@claude このIssueのエラーは〇〇の画面で発生します。再現手順は本文のとおり。原因を特定して修正案をブランチにpushしてください
チーム共通のルール(コーディング規約やレビュー観点)はCLAUDE.mdに書いておくと、GitHub上のClaudeもそれを守ります。ただし長すぎるルールはトークン消費を増やすため、公式は簡潔に保つことを推奨しています。手元のPCで複数のClaudeに作業を分担させる自動化は、エージェントチームの解説で扱っています。
【誤解注意】@claudeが「できないこと」を正確に知る
方法Bを使い始める前に、いちばん誤解の多いポイントを押さえておきましょう。
PRは自動作成されない(公式FAQの原文)
多くの解説記事が「IssueからPRまで自動作成」と紹介していますが、公式FAQの記述は違います。
Claude doesn't create PRs by default. Instead, it pushes commits to a branch and provides a link to a pre-filled PR submission page. (訳:Claudeはデフォルトではプルリクエストを作成しません。代わりにブランチへコミットをpushし、内容が入力済みのPR作成ページへのリンクを提示します)
最後の「PRを作る」ボタンを押すのは人間です。公式はこの設計理由を「ブランチ保護ルールを守り、PR作成の最終判断を人に残すため」と説明しています。意図された安全設計というわけです。ブランチの挙動も整理しておきます。
| @claudeを呼んだ場所 | ブランチの挙動 |
|---|---|
| Issue | 常に新しいブランチを作成(タイムスタンプ付きの名前) |
| オープン中のPR | そのPRのブランチに直接push |
| クローズ済みのPR | 新しいブランチを作成 |
マージ・rebase・force pushはしない
公式の機能一覧ドキュメントには、セキュリティ上の理由から「コミットのpush以外のブランチ操作(マージ、rebaseなど)はできない」と明記されています。この制限はClaudeへのシステムプロンプト(AIへの基本指示)で強制されており、公式FAQによれば、設定でgit系ツールの実行を許可していてもrebaseの依頼は断る動作になります。
PRの承認・正式レビュー・複数コメントもできない
同じく公式の機能一覧より、次も「できないこと」です。
- PRの承認:セキュリティ上の理由で不可
- 正式なGitHubレビューの提出:不可
- コメントの連投:Claudeは自分の最初のコメントを更新する形でのみ応答します
「Claudeのコメントが増えない」のは正常な動作で、進捗は最初のコメントの中身が書き換わる形で報告されます。
ワークフローファイルは書き換えられない
公式FAQには「Claude用のGitHub Appには、セキュリティ上の理由からワークフローへの書き込みアクセスがない」とあります。@claudeに「ワークフローYAMLを直して」と頼んでも反映できないのは、この仕様によるものです。
できること/できないこと早見表
| 項目 | 可否 |
|---|---|
| Issue・PRコメントへの応答(最初のコメントを更新して進捗報告) | できる |
| コードを変更してブランチにpush | できる |
| 内容が入力済みのPR作成ページのリンクを提示 | できる |
| PRそのものの自動作成 | できない |
| PRの承認・正式なレビューの提出 | できない |
| コメントの複数投稿 | できない |
| マージ・rebase・force push | できない |
| ワークフローファイルの書き換え | できない |
| 任意のBashコマンド実行 | デフォルト不可(claude_argsの--allowedToolsで明示的に許可した場合のみ) |
方法C:「@claude review」は別製品のCode Review【混同注意】
@claudeとよく似た@claude reviewというコマンドがありますが、この2つは別物です。@claude reviewは「Code Review」という別製品のコマンドで、自分のリポジトリのActionsではなくAnthropicのインフラ上で動きます。
なお公式ドキュメントによると、Code Reviewは2026年8月時点でリサーチプレビューであり、Team・Enterpriseプランでのみ利用できます(Pro/Maxプランでは有効化できません)。Zero Data Retentionを有効にした組織も対象外です。
方法Bとの違いを一覧で
方法B:@claude(GitHub Actions) |
方法C:@claude review(Code Review) |
|
|---|---|---|
| 動く場所 | 自分のリポジトリのActionsランナー | Anthropicのインフラ |
| 対応プラン | Pro/Max/Team/Enterprise/Console | Team・Enterpriseのみ(リサーチプレビュー) |
| 必要な設定 | ワークフローファイル+シークレット | 組織のOwnerが管理画面で有効化(ワークフローファイル不要) |
| 主なトリガー | @claudeメンション、任意のGitHubイベント |
PR作成時/pushごと/@claude reviewコマンド |
| 課金 | Actions実行時間+トークン | usage credits(プラン枠とは別) |
料金は1レビュー平均$15〜25・プラン枠とは別課金
公式ドキュメントには、Code Reviewは1レビューあたり平均$15〜25のコストで、プランに含まれる利用枠は消費せず、usage creditsという別枠で課金されると明記されています(2026年8月時点)。レビューの所要は平均20分で、チェック結果は常にニュートラル(中立)で完了するため、マージをブロックしません。
どちらを選ぶべきか
そもそもPro/Maxプランでは方法Cを選べないため、個人開発者や小規模チームなら方法Bで十分です。この記事では「@claudeと@claude reviewは別物で、後者はTeam・Enterprise向け・別課金」という区別だけ持ち帰ってもらえれば大丈夫です。
方法D:GitHub MCPサーバーで連携する
Actionsの中には最初から2つのMCPサーバーが入っている
MCP(Model Context Protocol)は、AIと外部ツールをつなぐ共通規格です。実は方法BのActions実行環境には、公式FAQに明記のとおりGitHub MCPサーバーとファイル操作サーバーの2つが自動で構成されています。ただしこれらのツールを実際に使わせるには、claude_argsの--allowedToolsで明示的な許可が必要という仕様です。
ローカルでGitHub MCPを使う場合
手元のClaude CodeからGitHubのIssueやPRをAPI経由で操作したい場合は、GitHub公式のMCPサーバーを追加します。追加コマンドや「npm版サーバーは開発終了している」といった注意点はMCPの設定ガイドで解説済みなので、そちらをどうぞ。公式ドキュメントは、ghのようなCLIツールで済む場面ではCLIのほうがコンテキスト効率が良いとしており、日常のgit操作は方法Aで足ります。MCPは「GitHub APIレベルの操作を任せたくなってから」で遅くありません。
うまく動かないときのトラブルシューティング
@claudeが反応しない:公式チェック5項目
公式トラブルシューティングが挙げる確認項目は次の5つです。上から順に確認してください。
- Claude GitHub Appが対象リポジトリにインストールされているか
- リポジトリでGitHub Actionsのワークフローが有効になっているか
- APIキーまたはOAuthトークンがリポジトリのシークレットに登録されているか
- コメントに
@claudeが完全な単語として含まれているか(/claudeや@claude-botは不可) - コメントした人がリポジトリのwrite権限を持っているか
Claudeのコミットを作ったのにCI(テスト)が走らない
公式ドキュメントに明記された仕様として、GitHubはデフォルトのGITHUB_TOKENで作られたコミットに対してワークフローを起動しません。ワークフローでgithub_token: ${{ secrets.GITHUB_TOKEN }}をActionに渡している場合は、その行を削除してください。Claude GitHub Appとして認証され、CIが動くようになります。
過去のコミット履歴が参照できない(浅いクローン)
公式FAQによると、Claudeは実行速度のためにリポジトリを浅くクローンします(PRでは直近20コミット、新規ブランチでは1コミットのみ)。「昔のコミットを調べて」系の指示が失敗するときは、この仕様を疑ってください。
参照した記事・YAMLが古くないかを見分ける
エラーの原因が「コピペ元の古さ」であるケースは多いです。次のサインがあれば、その記事の手順は現行仕様とずれています。
- YAMLに
@beta・mode:・direct_promptがある(旧仕様。現行はv1) actions/checkout@v4のまま(公式の現行例示は@v6)- 「GitHub Actions連携はAPIユーザーのみ」と書いてある(古い日本語版ドキュメント由来の誤り)
- 「IssueからPRまで全自動作成」と書いてある(公式仕様はPR作成ページのリンク提示まで)
この分野は数週間単位で仕様が動きます。解説記事同士で言っていることが食い違ったら、英語版公式ドキュメント(code.claude.com/docs/en/github-actions)と公式リポジトリのexamples/claude.ymlを見るのが最短です。日本語版ドキュメントは更新が遅れている点に注意してください(2026年8月時点)。
またWeb記事からコピペしたYAMLやコマンドは、半角ハイフン2つ(--)が全角ダッシュに化けて構文エラーになる事例があります。エラーが出たらハイフン部分だけ手打ちし直すと確実です。
セキュリティと権限で気をつけること
GitHub Appの権限は一括承認(実際に使うのは3つ)
Claude GitHub Appのインストール時に承認する権限は11種類あります。公式ドキュメントは「権限セットには、Claude Code GitHub Actionが使わないものも含まれる」「承認は権限セット全体が単位で、一部だけの承認はできない」と説明しています。そのうえで、Actionが実際に使うのはContents・Issues・Pull requestsの読み書き3つだけとも明記されています。絞りたい場合は、この3権限だけのカスタムAppを自作する方法も公式に案内されています(Code Reviewなど一部機能は公式App必須)。
キーやトークンをYAMLに直書きしない
APIキーやOAuthトークンをワークフローYAMLへ直接書くと、リポジトリを見られる全員(公開リポジトリなら全世界)に漏れます。必ずGitHubのシークレットに登録し、YAMLからは${{ secrets.ANTHROPIC_API_KEY }}のような参照で使ってください。
連携をやめるときは3か所を消す
アンインストールの手順も公式ドキュメント(英語版)に専用セクションがあります。消すのは次の3か所です。
- ワークフローファイル:
.github/workflows/からclaude.ymlとclaude-code-review.ymlを削除 - シークレット:
ANTHROPIC_API_KEY/CLAUDE_CODE_OAUTH_TOKENを削除 - Claude GitHub App:リポジトリまたは組織からアンインストール
公式は「シークレットを削除しても、そこに入っていた資格情報自体は有効なまま」と注意しています。APIキーを完全に無効化するには、Claude Console側でキー本体の削除も必要です。またGitHub Appは、Code Reviewなど他のClaude機能で使っていない場合にのみアンインストールするよう案内されています。
GitHubで「claude code」を検索してたどり着いた人へ
「claude code github」と検索する人の中には、連携ではなく「GitHubにあるClaude Codeのリポジトリ」を探している人もいるはずです。その場合の注意点をまとめます。
公式リポジトリは anthropics/claude-code の1つだけ
Claude Code本体の公式リポジトリはgithub.com/anthropics/claude-codeだけです(スター数は約14万・2026年8月時点)。英語圏の検索結果では、名前のよく似た非公式のミラー・転載リポジトリが複数混ざっていることを確認しています(日本語検索での出方は未調査です)。anthropicsという組織名(Anthropic公式アカウント)以外のリポジトリからファイルをダウンロードして使うのは避けてください。GitHub Actions用のclaude-code-actionも同じanthropics配下にあります。
GitHubからソースコードを落として使うものではない
公式リポジトリの中身はソースコードの公開ではなく、インストール案内・プラグイン関連・バグ報告の窓口です。インストールは公式の配布経路で行います(README記載の現行手順・2026年8月時点)。
# Windows(PowerShell)
irm https://claude.ai/install.ps1 | iex
# macOS / Linux
curl -fsSL https://claude.ai/install.sh | bash
WinGet(winget install Anthropic.ClaudeCode)やHomebrewにも対応しており、npm経由のインストールは公式が非推奨と明記しています。詳しい手順は始め方ガイドにまとめています。
Actions内でSkillsも呼び出せる
応用として、方法Bのワークフローのprompt入力には、プレーンな文章だけでなく/skill-name形式のスキル呼び出しも書けると公式ドキュメントに明記されています。リポジトリの.claude/skills/に置いたスキルを、actions/checkout実行後に呼び出す形です。スキル自体の作り方はSkillsの解説記事をどうぞ。
よくある質問(FAQ)
無料のClaude.aiプランではClaude Code自体が使えません。公式は「Pro、Max、Team、Enterprise、Consoleのいずれかのアカウントが必要」と明記しています。GitHub Actions連携ではさらに、GitHub Actionsの実行時間と、トークン消費(API課金またはサブスクの利用枠)の2種類のコストがかかります。
使えます。API課金は必須ではありません。ローカルでclaude setup-tokenを実行してOAuthトークンを発行し、CLAUDE_CODE_OAUTH_TOKENという名前でリポジトリのシークレットに登録すれば、実行分はサブスクの利用枠から消費されます(Pro/Max/Team/Enterpriseが対象)。日本語版の公式ドキュメントには「直接APIユーザーのみ」と書かれていますが、これは英語版より古い記述です(2026年8月時点)。
いいえ。公式FAQは「Claudeはデフォルトではプルリクエストを作成しない。ブランチにコミットをpushし、内容が入力済みのPR作成ページへのリンクを返す」と明記しています。ブランチ保護ルールを尊重し、PR作成の最終判断を人に残すための意図的な仕様です。
対象リポジトリの管理者権限と、GitHub CLI(gh)のインストール・認証が必要です。Claude Codeはghのインストール状況と認証状態を確認し、repoとworkflowのスコープが足りない場合はgh auth refresh -h github.com -s repo,workflowの実行を案内します。
別物です。@claudeは自分のリポジトリのGitHub Actionsで動くclaude-code-actionで、ワークフローファイルが必要です。@claude reviewは組織のOwnerが有効化する「Code Review」という別製品で、Anthropicのインフラ上で動き、ワークフローファイルは不要です。ただしCode Reviewは2026年8月時点でリサーチプレビューのTeam・Enterpriseプラン限定機能で、Pro/Maxプランでは使えません。料金は1レビューあたり平均$15〜25で、プランの利用枠とは別のusage creditsで課金されます。
まとめ|まずは方法Aから、慣れたら@claudeへ
- 「GitHub連携」は4種類(ローカル操作/GitHub Actions/Code Review/MCP)。区別しないことが混乱のもと
- Pro/Maxプランでも
claude setup-tokenでGitHub Actions連携を使える。API課金は必須ではない(日本語版ドキュメントの古い記述に注意) - 方法Bの必須前提はgh CLI。スコープは
repoとworkflowの2つ - @claudeはPRを自動作成しない。「ブランチへのcommit push+入力済みPR作成ページのリンク提示」が公式仕様
- 迷ったら英語版公式ドキュメントと
examples/claude.ymlを確認する
GitHub連携は、Claude Codeの活用範囲を「自分のPCの中」から「チームの開発フロー」へ広げてくれる機能です。最初の一歩は小さくて構いません。まず方法Aで「変更をコミットして」と頼むところから始めて、感覚がつかめたら/install-github-appに進んでください。
Claude Codeの基本操作から見直したい方は、使い方マスターガイドもあわせてどうぞ。