無料相談する

カテゴリー / VS Code・Git・ツール連携

Claude Code GitHub連携のやり方｜4つの方法と必要な認証を整理

NO WAVE公開 更新 読了目安 13分

この記事の目次

Claude CodeとGitHubを連携するには、何をすればいいのか？

Claude CodeとGitHubの連携は、1つの設定で済むものではない。この記事では、公式ドキュメントに出てくる接続経路を、GitHubへの認証情報をどこに渡すかで次の4つの接続方法に整理する。

  1. 手元の gh（GitHub CLI）でPRを作らせる: ローカルのClaude Codeに「create a pr for my changes」と頼み、ghでプルリクエスト作成を行わせる。
  2. GitHub MCPサーバーに個人用アクセストークン（PAT）を渡す: 対話の中からPRのレビュー、Issueの作成、自分に割り当てられたPRの一覧取得などを頼む。
  3. Claude GitHub Appをリポジトリに入れる: Code Review、PRのauto-fix、RoutinesのGitHubトリガーはこのAppが前提。GitHub Actionsも通常はこのAppを使う（カスタムAppでの代替も可）。
  4. /web-setup で gh のトークンをClaudeアカウントに預ける: クラウドで動くClaude Codeがリポジトリをcloneし、ブランチをpushできるようになる。

手元でPRを作るだけなら1、会話中にIssueやPRを扱いたいなら2、GitHub上のイベントでClaudeを自動で動かしたいなら3、ノートPCを閉じてもクラウドで作業を続けたいなら4（または3）を選ぶ。

手元のClaude CodeでPRを作るには、どう頼めばいいのか？

公式の手順では「create a pr for my changes」と頼めばPRを作れる。Claudeが gh pr create でPRを作るとセッションがPRに紐づき、後からPR番号で同じ会話に戻れる。

claude --from-pr 1234

PR作成に失敗したときは、まず手元のghの認証状態（gh auth login 済みか）とリポジトリへの権限を確かめるとよい。コミットやコンフリクト解消の手順はClaude CodeでGitを扱う実践ガイドで扱っている。

会話の中からIssueやPRを操作したいときは、MCPをどう設定するのか？

GitHubが提供するリモートMCPサーバーを追加する。認証は、GitHubで発行したfine-grainedトークン（アクセスできるリポジトリを絞れる個人用アクセストークン）をヘッダーで渡す方式だ。公式の例は次のとおり。

claude mcp add --transport http github https://api.githubcopilot.com/mcp/ \
  --header "Authorization: Bearer YOUR_GITHUB_PAT"

YOUR_GITHUB_PAT を、Claudeに触らせたいリポジトリだけにアクセスできるトークンに置き換える。注意したいのは、claude mcp add が認証情報を検証せずに保存する点だ。トークンを間違えても追加は成功し、使う段階で初めて失敗する。追加したら次で確かめる。

/mcp

サーバーの行にチェックマークが付けば接続できている。✘の場合は詳細にGitHubが返したHTTPステータスが出るので、401ならトークンの誤りや失効を疑う。接続後は「Show me all open PRs assigned to me」のように自然文で頼める。スコープやチームでの共有ルールはClaude Code MCPの設定ガイドにまとめている。

Claude GitHub Appを入れると、何が使えるようになるのか？

Claude GitHub Appは、GitHubと連携するClaudeの機能が共有する1つのAppだ。公式ドキュメントには、GitHub Actions、Code Review、クラウドセッションでのPRのauto-fixが同じAppを使うと書かれている。RoutinesのGitHubトリガーもこのAppの導入が条件になっている。ただしGitHub Actionsだけは、後述のカスタムAppで代替できる。

機能 何が起きるか 対象と前提
GitHub Actions @claude のメンションで解析、実装、pushを行う GitHubのホストランナーで動く。設定にはリポジトリのadmin権限が必要
Code Review 複数のエージェントがPRの変更を読み、該当行にインラインでコメントする Team / Enterprise。Claude組織のOwnerが有効化
auto-fix PRのCI失敗やレビューコメントを受けて調べ、修正が明らかならpushする クラウドセッション上で動く
Routines（GitHubトリガー） PRやReleaseのイベントで新しいクラウドセッションを始める Pro / Max / Team / Enterprise

Appの権限はまとめて承認するしかなく、一部だけは選べない。Actionsしか使わず権限を最小にしたい組織向けに、公式はContents、Issues、Pull requestsだけのカスタムGitHub Appを自作する方法を示している。ただしカスタムAppで代替できるのはActionsだけで、Code Reviewとauto-fixには公式Appが要る。

外すときも同じ関係が効く。公式は、Appのアンインストールは他のClaude機能で使っていない場合に限るよう書いている。Actionsをやめるつもりで外すと、Code Reviewやauto-fixも止まる。

GitHub Actionsは、どの順番で設定すればいいのか？

公式のQuick setupは、Claude Codeの中で /install-github-app を実行する方法だ。このコマンドがAppの導入、認証シークレットの登録、ワークフローを追加するPRの準備までを進める。前提は3つある。

  • 対象がgithub.comのリポジトリであること（GitLabやBitbucketでは案内を出して終了する）
  • リポジトリのadmin権限があること
  • GitHub CLIを入れて認証済みであること
gh auth login
/install-github-app

認証シークレットは2種類から選ぶ。APIキーなら ANTHROPIC_API_KEY、Claudeのサブスクリプションで動かすなら CLAUDE_CODE_OAUTH_TOKEN という名前でリポジトリに保存される。サブスクリプション用のトークンはPro、Max、Team、Enterpriseで使え、手動で作るときはローカルで次を実行する。

claude setup-token

最後に、コマンドが用意したPRを作成してマージすると @claude が動く。複数リポジトリで共有するシークレットにはAPIキーが勧められている。OAuthトークンは claude setup-token を実行した人のサブスクリプションに紐づくためだ。実行ごとにGitHub Actionsの実行時間とAPIトークンの2種類を消費し、OAuthトークンで認証した場合はAPI課金ではなくサブスクリプションが使われる。

YAMLやトリガー条件の詰め方はClaude Code GitHub Actionsの設定ガイドで扱う。

@claude に反応しないとき、どこから確認すればいいのか？

公式のトラブルシューティングが挙げる確認項目は次の5つだ。

  1. Claude GitHub Appがそのリポジトリに入っているか
  2. リポジトリでワークフローが有効になっているか
  3. APIキーかOAuthトークンがリポジトリのシークレットに入っているか
  4. コメントに @claude が独立した語として入っているか（/claude や @claude-bot では反応しない）
  5. コメントしたユーザーがリポジトリへの書き込み権限を持っているか

5は見落としやすい。IssueやPRのイベントでは起動したユーザーに書き込み権限が要り、botも allowed_bots に登録しない限り拒否される。公開リポジトリでは、フォークからのPRで起動した実行にGitHubがシークレットを渡さない。

認証エラーは、ワークフローを調べる前にそのキーやトークンをローカルの claude で試す。ClaudeのコミットでCIが走らないなら、github_token: ${{ secrets.GITHUB_TOKEN }} を渡していないかを見る。GitHubは既定の GITHUB_TOKEN によるコミットではワークフローを起動しないため、この行を外してClaude GitHub Appとして認証させる。

クラウドで動くClaude CodeにGitHubを使わせるには、どちらの方法を選ぶのか？

クラウドセッションは、claude.ai/code、Desktopアプリの Cloud、端末の claude --cloud などから始める、手元のマシンではなくクラウドを実行場所とするClaude Codeだ。Pro、Max、Teamと、Enterpriseのプレミアムシートなどで使える。GitHubへのアクセスの渡し方は2つある。

方式 接続のしかた 到達できるリポジトリ
GitHub App ブラウザのオンボーディングでClaude GitHub Appを承認 すべての公開リポジトリと、Appを入れた非公開リポジトリ
/web-setup 手元の gh のトークンをClaudeアカウントに送る gh のトークンが届くすべてのリポジトリ（Appの有無は問わない）

ghを使っているなら /web-setup が手早い。Claude Codeの中で実行すると、gh auth token のトークンを読み、確認を求めてからAnthropicに送る。成功すると Connected as <GitHubのユーザー名> と出る。Anthropicが管理する環境では、GitHubの認証情報はサーバー側で暗号化保管され、セッションのVMには入らないと公式は説明している。

ここに経路をまたぐ落とし穴がある。/web-setup はcloneとpushのアクセスを与えるだけで、Claude GitHub Appは入らない。RoutinesのGitHubトリガーとauto-fixはAppが前提なので、クラウド実行でイベント駆動まで使うなら別途Appを入れる。

TeamとEnterpriseでは、ブラウザ接続にはOwnerがGitHubコネクタを、/web-setup にはQuick setupをオンにしておく必要がある。Web版の使い方はClaude Code Web版の解説を参照してほしい。

/web-setup やクラウド側の接続がうまくいかないときは、どう切り分けるのか？

公式に載っている症状と対処を並べる。

  • /web-setup がコマンド一覧に出ない、Unknown commandになる: APIキーやサードパーティのプロバイダーで認証していることが主な原因だ。/login でclaude.aiアカウントにサインインし直す。Team / EnterpriseではQuick setupがオフのままでも隠れる。
  • 「Not signed in to Claude. Run /login first.」と出る: CLIに有効なclaude.aiのサインインがない。/login の後に /web-setup をやり直す。
  • ワークフローファイルを変えるpushが拒否される: ghのトークンに workflow スコープがないと、GitHubがこうしたpushを拒否することがある。次を実行してから /web-setup をやり直す。
gh auth refresh -s workflow
  • 接続したのにリポジトリが出てこない: ブラウザで接続した場合、非公開リポジトリは、それを持つアカウントか組織にAppが入っていて、Appのアクセス対象に含まれているときだけ表示される。/web-setup で接続した場合は、ghのログインからそのリポジトリが見えるかを確かめる。ghのアカウントを切り替えたなら /web-setup を再実行する。
gh repo view OWNER/REPO

預けたトークンは claude.ai/customize/connectors でGitHubを切断すると外れるが、トークン自体はGitHub上で有効なまま残る。無効にするにはGitHub側で取り消す。Actionsのシークレットも同様で、削除しても中のAPIキーは有効なので、不要なキーはClaude Consoleでも削除する。

PRの自動修正や自動レビューを入れる前に、決めておくべきことは何か？

自動で動く機能は、誰の名義で何に反応するかを先に確かめる。auto-fix は、自動化機能でPRのCI失敗とレビューコメントを監視し、修正が明らかならpushする。端末からはPRのブランチで次を実行すると、ghで開いているPRを見つけてクラウドセッションを立ち上げ、auto-fixをオンにする。

/autofix-pr

auto-fixのレビュー返信はあなたのGitHubアカウント名義で投稿される（Claude Codeのラベルは付く）。AtlantisやTerraform Cloud、issue_comment で動く自作Actionsがあるリポジトリでは、その返信がワークフローを起動しうる。公式は、PRコメントでデプロイや特権操作が走るリポジトリではauto-fixの無効化を検討するよう書いている。

Routines のGitHubトリガーは、Pull requestとReleaseのイベントで新しいクラウドセッションを始める。コミットやPRはあなたのGitHubユーザーとして作られ、プロンプトで別のブランチを指定しない限り claude/ で始まるブランチにpushされる。push先を制限するならGitHubのブランチ保護ルールかルールセットを使う。Routinesは現時点でresearch previewで、挙動や上限が変わりうると公式に明記されているため、使う前にRoutinesのページで現行仕様を確かめてほしい。定期実行の比較はClaude Codeの定期実行スケジュールの選び方で扱う。

Code Review はTeamとEnterprise向けで、Claude組織のOwnerが管理画面から有効にし、ワークフローファイルは要らない。既定は「After every push」で、「Manual」にすると、PRの作成やpushではレビューが始まらず、@claude review とコメントして依頼する。レビューはPRを承認もブロックもしないので、マージの判断は人に残る。どのプランでも手元で /code-review を実行できる。選び方はClaude Codeのコードレビュー解説にまとめている。

結局、最初の一歩はどれから始めればいいのか？

必要な機能に合わせて経路を選び、その経路で渡す権限を確かめてから使い始める。MCPならトークンが届くリポジトリを絞り、Appなら権限一覧を確かめてから /install-github-app を実行する。どの段階でも、キーやトークンをリポジトリにコミットせず、ワークフローには必要な権限だけを与え、Claudeの変更はマージ前に人が確認する。公式のベストプラクティスもこの3点を挙げている。

どこまでClaudeに任せ、どこで人が止めるかの線引きを実践で学ぶ場として、月額1,980円から参加できる学習コミュニティ「AI駆動ラボ」を用意している。

CONTINUE THE SESSION

関連記事