Claude CodeとGitHubの連携とは？つないでできること
Claude CodeとGitHubの連携とは、手元の CLI（コマンドラインインターフェース、ターミナルから文字で操作する仕組み）で動かしている AI コーディングエージェントを、リポジトリ側のイベントに反応して動くようにする仕組みです。連携すると、次のような作業を GitHub 上で完結させられます。
- @claude メンションへの応答：Issue やプルリクエストのコメントに
@claudeと書いて依頼すると、内容を読んで作業し、同じスレッドに結果を返します - Issue からプルリクエストの作成：課題の説明を渡すと、コード生成から変更の push までを一続きで進めます
- プルリクエストの自動レビュー：差分を読み、指摘があった行にインラインコメントを付けます
- CI 失敗とレビューコメントへの自動対応：テストが落ちた、レビューで指摘が付いた、といったイベントに反応して修正を試みます
- 任意のイベントでの自動実行：定期実行やラベル付与など、GitHub 側のイベントを起点に決まった作業を回します
いずれも共通しているのは、人が席に着いてターミナルを開かなくても、リポジトリの動きに合わせて AI が作業を進める点です。ローカルでの対話を GitHub 側へ持ち出すことで、AI がチームの開発フローの中に入ってきます。
関連記事：Claude Codeとは？できること・料金・使い方と社内導入の判断軸
GitHub上でClaudeに任せられる作業の範囲
任せられる作業は、コード生成に限りません。既存コードのリファクタリング、テストコードの追加、バグの原因調査といったデバッグ寄りの作業も依頼できます。リポジトリを丸ごと読める状態で動くため、「この関数を使っている箇所をすべて直して」のように、横断的な変更も指示できます。
リポジトリのルートに CLAUDE.md を置いておくと、コーディング規約やレビュー基準をそこに書いておけます。Claude はプルリクエストを作るときも指摘を返すときも、この内容に沿って判断します。プロンプトを毎回書き直さなくても、チームのルールが反映されるということです。
一方で、作業結果がそのまま本番に入るわけではありません。Claude が作ったブランチも通常のプルリクエストとして上がるため、マージするかどうかは人が判断します。既存のレビュー体制を壊さずに、一次作業だけを前倒しできる形です。
ローカルでそのまま使うときとの違い
ローカルで Claude Code を動かす場合、AI が触れるのは自分のマシンにあるファイルです。作業の起点は常に自分で、席を離れれば進みません。対して GitHub との連携では、起点がリポジトリのイベント側に移ります。
この違いは、チームで使うときにはっきり出ます。ローカル運用だと AI の使い方が個人の中に閉じますが、GitHub 上で動かせば、コメント欄でのやり取りも生成された差分もチーム全員から見えます。誰がどんな指示を出したかが履歴に残るので、使い方の共有もしやすくなります。
反対に、ローカルのほうが向いている場面もあります。試行錯誤しながら設計を固めたいときや、まだ push したくない変更を触っているときは、手元で対話するほうが速く進みます。GitHub 連携は、やることが固まった作業を任せる場所だと考えると使い分けやすくなります。
連携の仕組みと4つの経路｜費用の乗り方まで整理
公式に用意されている連携の経路は 4 つあります。名称が似ているため混同されやすいのですが、設定の重さも費用の発生の仕方も別物です。まず全体像を押さえてから、自分の目的に合うものを選びます。
| 経路 | 何をするものか | 設定の重さ | 費用の乗り方 |
|---|---|---|---|
| GitHub Actions | ワークフローを自分で書き、`@claude` への応答や自動実行を組む | 中（ワークフローファイルが必要） | GitHub Actions の実行時間 ＋ トークン利用料 |
| Code Review | プルリクエストを自動レビューする管理されたサービス | 軽（ワークフロー不要） | レビュー単位のトークン従量 |
| Web版の自動修正 | CI 失敗とレビューコメントに反応して修正を push する | 軽（プルリクエスト単位の切り替え） | 契約中のプランの利用枠 |
| ローカルの CLI | 手元からプルリクエストを指定してレビュー・修正する | 軽（コマンドのみ） | 契約中のプランの利用枠 |
迷ったときは、ワークフローを書いてでも動きを細かく決めたいかどうかで切り分けると判断しやすくなります。細かく決めたいなら GitHub Actions、レビューだけ任せたいなら Code Review、手元の作業の延長で足りるなら CLI です。
GitHub Actions｜ワークフローを書いて自由に組む
最も自由度が高い経路です。リポジトリの .github/workflows/ にワークフローファイルを置き、そこから Claude Code を呼び出します。prompt を指定しなければ @claude というトリガーフレーズを待つ動き方になり、指定すればメンションを待たずに任意のイベントで自動実行されます（出典: claude.com）。
定期実行やラベル付与を起点にした自動化も、この経路で組みます。CI/CD のパイプラインに AI の作業を組み込みたい場合は、実質的にここが選択肢になります。
Code Review｜ワークフローなしで自動レビューを回す
プルリクエストのレビューだけを任せたい場合は、ワークフローを書かずに使える Code Review があります。管理画面から組織単位で有効にし、リポジトリごとに「プルリクエスト作成時に 1 回」「push のたび」「手動のみ」からトリガーを選ぶ形です。
指摘は重要度の 3 段階で分類され、該当行にインラインコメントとして付きます。チェックの結果は常に中立で完了するため、ブランチ保護ルールでマージを止めてしまうことはありません。
ただし提供条件が限定されています。2026年8月時点ではリサーチプレビューとして、Team と Enterprise の契約向けに提供されています。料金は 1 レビューあたり平均 15〜25 ドルで、プランに含まれる利用枠とは別に課金されます（2026年8月時点、出典: claude.com）。
Web版の自動修正｜CI失敗とレビューコメントに反応させる
ブラウザから使う Claude Code には、開いているプルリクエストを見張らせる機能があります。テストが落ちたときやレビューコメントが付いたときに、内容を調べて明らかな修正であれば push まで進めます（出典: claude.com）。
プルリクエスト単位の切り替えなので、重要なものだけ有効にする使い方ができます。ただし GitHub App の導入が前提になる点と、ベースブランチが進んで発生したコンフリクトには自動で反応できない点は押さえておく必要があります。
全国8,000人調査で、AI活用方法によって生産性向上に約3.8倍の差が生まれることが判明。
ローカルのCLI｜手元からプルリクエストを扱う
GitHub App を入れずに始めたい場合は、手元の CLI からプルリクエストを指定する方法もあります。差分をレビューして指摘を返すコマンドが用意されており、指摘をそのままプルリクエストへコメントとして投稿することもできます。
リポジトリの設定を変えずに試せるため、チームに提案する前の下見に向いています。まずここで手応えを確かめてから、GitHub Actions へ広げる進め方が現実的です。
GitHub Actionsで連携する導入ステップ
ここからは、最も利用が多い GitHub Actions での設定手順を追います。作業はリポジトリの管理者権限を持つ人が行います。手順は大きく 3 つで、認証情報の用意、ワークフローの設置、用途の追加という流れです。
ステップ1｜GitHub Appと認証情報を用意する
Claude Code のセッションから /install-github-app を実行すると、GitHub App の導入と認証情報の登録、ワークフローのプルリクエスト作成までをまとめて進められます。実行前に GitHub CLI を入れて gh auth login を済ませておく必要があります。認証には次の 2 通りがあります（出典: claude.com）。
- API キーを使う：リポジトリのシークレットに
ANTHROPIC_API_KEYとして登録します - サブスクリプションを使う：
claude setup-tokenで長期トークンを発行し、CLAUDE_CODE_OAUTH_TOKENとして登録します。Pro、Max、Team、Enterprise の各プランで利用できます
組織全体へ広げるなら、シークレットは組織レベルの Actions シークレットに置くとリポジトリごとの登録が要らなくなります。ただし長期トークンは発行した個人の契約に紐づくため、複数リポジトリで共有する用途には API キーのほうが向いています。
ステップ2｜ワークフローを置いて@claudeを試す
手動で進める場合は、公式リポジトリのサンプルワークフローを .github/workflows/ にコピーします。コメント作成のイベントを購読し、本文に @claude が含まれるときだけジョブを起動する形が基本形です。ワークフローには次の権限を与えます（出典: claude.com）。
- 書き込み権限：
contents: writeとpull-requests: write、issues: writeを、ファイルの変更とコメント投稿に使います - トークン発行の権限：
id-token: writeは既定の認証で必要になります - CI 結果の参照：
actions: readは Claude がプルリクエスト上の CI 結果を読むために使います
環境変数やシークレットの参照を書き換える必要はなく、認証方式に合わせて 1 行変えるだけです。設置できたら、適当な Issue に @claude と書いて依頼を投げてみます。同じスレッドに返答が付き、作業の進み方が更新されていけば連携は成立しています。うまく動かないときは、GitHub App が対象リポジトリに入っているか、ワークフローが有効になっているかを先に確認します。
ステップ3｜レビュー自動化など用途を足す
@claude への応答が動いたら、用途を足していきます。プルリクエストが開かれたときにレビューを走らせる、定期実行で前日の変更をまとめる、といった自動化はワークフローを 1 本増やすだけで組めます。
このとき効くのが、モデルや上限を指定する引数です。会話の往復回数に上限を設ける、使うモデルを指定する、といった調整をワークフロー側から渡せます。開発効率を上げる方向に振りつつ、1 回の実行が伸びすぎないよう抑えるバランスを取ります。
連携前に決めておきたい権限と実行者の制限
連携で最初に相談になるのが権限です。GitHub App は導入時にまとめて権限を要求し、一部だけを承認することはできません。実際に要求されるのは次の範囲です（出典: claude.com）。
| 権限 | アクセス |
|---|---|
| Actions / Checks / Contents | 読み取りと書き込み |
| Discussions / Issues / Pull requests | 読み取りと書き込み |
| Repository hooks / Workflows | 読み取りと書き込み |
| Members / Metadata / Statuses | 読み取り |
このうち GitHub Actions 連携が実際に使うのは Contents、Issues、Pull requests の 3 つです。この App は自動レビューなど他の機能とも共有されているため、権限セットが広めに取られています。範囲を絞りたい組織は、必要な 3 権限だけを持つ独自の GitHub App を作って差し替えられます。ただしその場合、自動レビューやブラウザ版の自動修正は公式 App が必要なままです。
関連記事：Claude Code は安全に使える？セキュリティリスクと最初にすべき設定
起動できる人は2段階で絞られている
権限とあわせて押さえたいのが、誰が Claude を動かせるかです。Issue やプルリクエストのイベントでは、依頼した人がリポジトリへの書き込み権限を持っているかが確認され、持っていなければ実行されません。さらに、あらゆるイベントで bot からの起動は既定で拒否されます（出典: claude.com）。
2 段目の確認は、bot 同士が反応し合って実行が止まらなくなる事態を防ぐためのものです。定期実行はリポジトリの利用者に紐づけられるため、その利用者が bot の場合は明示的に許可する設定が要ります。外部の協力者に使わせたいときも、許可リストへの追加という形で個別に開けます。
GitHub Copilotとの違いを比較
併用中のツールがある場合、よく問われるのが GitHub Copilot との関係です。両者は同じ「AI で開発を助ける」領域にありますが、動く場所と任せる作業の粒度が異なります。
| 観点 | Claude CodeのGitHub連携 | GitHub Copilot |
|---|---|---|
| 主に動く場所 | GitHub 上のイベント（Issue、プルリクエスト、CI） | エディタ上の編集作業 |
| 任せる単位 | 課題や指摘の単位で、複数ファイルにまたがる変更 | 書いている箇所の補完と対話 |
| 人の関わり方 | 依頼して結果のプルリクエストを確認する | 書きながらその場で採否を決める |
書いている最中の速度を上げたいのか、書き始める前の一次作業を減らしたいのかで役割が分かれます。前者はエディタ側の支援が向き、後者は GitHub 側で動く連携が向きます。用途が重ならないため、どちらかに寄せるより、目的ごとに使い分けているチームのほうが多い状況です。
なお、Claude Code が動く場所は GitHub だけではありません。手元のターミナルからもブラウザからも同じエージェントを呼び出せるため、GitHub との連携はその使い方の一部という位置づけです。すでに補完系のツールを入れているチームでも、置き換えを前提に考える必要はありません。
関連記事：GitHub Copilotでできること｜開発の5つの場面と料金・違いを整理
連携で変わる開発の進め方｜自社事例とBefore/After
実際に導入すると、どこの時間が減るのでしょうか。自社の実績と、レビューおよび Issue 対応にあてはめた試算で見ていきます。
全国8,000人調査で、AI活用方法によって生産性向上に約3.8倍の差が生まれることが判明。
AIコーディングエージェントで開発工数を約75%削減した自社事例
GiftX では、自社サービス GIFTFUL のフロントエンドとバックエンドの開発に Claude Code を組み込んでいます。仕様を渡してコード生成、リファクタリング、テスト作成までを AI が進め、エンジニアはレビューと微調整に回る進め方です。
結果として、機能追加 1 件あたりの所要時間は平均 2 日から平均半日になり、工数はおよそ 75% 減りました。あわせてユニットテストと E2E テストの自動生成にも広げており、テスト作成にかかる時間は 1 機能あたり約 4 時間から約 30 分に短縮しています。
レビューとIssue対応にあてはめた試算
同じ考え方を、GitHub 上の日常作業にあてはめると次のようになります。人が担う部分を、指摘の妥当性確認と設計判断に絞った場合の試算です。
| 業務 | 連携前 | 連携後 | 削減率 |
|---|---|---|---|
| プルリクエストのレビュー（週 25 本） | 1 本 25 分 / 週 約 10 時間 | 1 本 10 分 / 週 約 4 時間 | 60% |
| Issue の一次対応（週 6 件） | 1 件 90 分 / 週 9 時間 | 1 件 30 分 / 週 3 時間 | 約 67% |
例えば 5 名の開発チームで、レビューの最終確認が特定のメンバーに集中しているようなケースでは、週 6 時間ほどが設計判断に回せる計算になります。時給 5,000 円で換算すると週 3 万円、年間で 150 万円ほどの余力にあたります。数字そのものより、待ち時間が減ってマージまでの日数が縮む効果のほうが体感しやすい部分です。
AIエージェントをGitHubにつなぐときに陥りがちな3つの落とし穴
ここまで見てきた連携は、AI に複数の工程をまとめて任せる使い方にあたります。自社調査では、この段階まで進んでいる割合は職種を問わず高くありません。
| 項目 | エンジニア | オフィス系7職種の全体 |
|---|---|---|
| AI 利用率 | 74.7% | 約 67% |
| AIエージェント化（複数工程の半自動〜自動運用）の割合 | 5% | 10.5% |
エンジニアは利用率が 7 職種で最も高い一方、複数工程を任せる段階に進んでいる割合は 5% にとどまります（職種別の内訳は該当者数が少ないため参考値です）。この 4 段階は AI を業務フローに組み込む使い方を測る軸で、コーディング支援そのものの習熟度を測るものではありません。とはいえ、日々の対話では使えているのに GitHub 側へ持ち出せていないチームが多いことは読み取れます。実際につまずくのは、次の 3 点です。
詳細な調査データは「ビジネス職生成AI活用実態調査（2026年版）」にてご覧ください。
落とし穴1｜いきなり全部を自動化しようとする
最初からレビュー、Issue 対応、定期実行をまとめて有効にすると、通知が一気に増えて誰も見なくなります。動かす範囲を広げるほど、指摘の質を確かめる余裕もなくなります。
落とし穴2｜壮大なAI戦略から考えて手が止まる
全社の開発標準をどうするか、どのモデルを標準にするかから議論を始めると、決めることが増えて着手できません。連携はリポジトリ単位で始められるため、全体方針を待つ必要はありません。
落とし穴3｜既製のチャット型AIでは業務フローに組み込めない
チャット画面に貼って質問する使い方は手軽ですが、自社の規約や手順を毎回説明し直すことになります。出力の質も安定せず、そのままプルリクエストに載せられる水準には届きません。
スモールスタートで1業務をAIエージェントに任せる
現実的なのは、1 つの作業だけを選んで任せることです。レビューの一次確認だけ、あるいは特定ラベルが付いた Issue の下調べだけ、と範囲を決めて始めます。1 リポジトリで 2 週間ほど回し、指摘の妥当性と手戻りの量を見てから広げれば、通知に埋もれることもありません。
範囲を決めるときは、既に手順が固まっていて、間違えても人が気づける作業から選ぶのが安全です。逆に、判断が属人的な作業や、失敗したときに気づきにくい作業は後回しにします。GiftX では、こうしたスモールスタート前提のAIエージェント構築を 1 業務単位から伴走支援しています。詳細は AIエージェント構築支援サービス をご覧ください。
Claude CodeとGitHubの連携に関するよくある質問
最後に、導入前に確認されることの多い点をまとめます。
プライベートリポジトリでも使えますか
使えます。GitHub App を導入したリポジトリであれば、公開・非公開を問わず動作します。ただし公開リポジトリでは、フォークから作られたプルリクエストの実行時に GitHub 側がシークレットを渡さないため、自動レビューは同じリポジトリ内のブランチに限られます。
サブスクリプションのままで使えますか。APIキーは必要ですか
どちらでも構いません。claude setup-token で発行した長期トークンを登録すれば、契約中のプランの枠で動きます。API キーを登録した場合は、トークン利用料として別に課金されます。組織で共有するなら API キー、個人の範囲で試すなら長期トークンが扱いやすい形です。
誰でも@claudeを呼べてしまいますか
既定では、リポジトリへの書き込み権限を持つ人だけが起動できます。加えて bot からの起動は拒否されるため、自動化同士が反応し合う心配もありません。書き込み権限のない協力者に使わせたい場合は、許可リストに個別に追加します。
Claudeが作ったコミットでCIが動かないのはなぜですか
既定のトークンで作られたコミットでは、GitHub がワークフローを起動しない仕様のためです。ワークフローに github_token を明示的に渡している場合はその行を外し、GitHub App として認証させると解決します（出典: claude.com）。
連携をやめたいときはどうすればよいですか
ワークフローファイルを削除すれば、その時点で実行は止まります。あわせてリポジトリと組織のシークレットを削除し、他の機能で使っていなければ GitHub App も外します。なお、シークレットを消しても認証情報そのものは有効なままなので、API キーを完全に無効にしたい場合は発行元の管理画面から削除します。
まとめ
Claude Code と GitHub の連携には、ワークフローを書く GitHub Actions、レビューに特化した Code Review、ブラウザから使う自動修正、手元の CLI という 4 つの経路があります。設定の重さも費用の乗り方も異なるため、どこまで自分で組みたいかで選ぶのが早道です。導入時は、GitHub App がまとめて要求する権限の範囲と、書き込み権限を持つ人だけが起動できる仕組みを先にチームで確認しておくと、後から差し戻しになりません。
そのうえで、最初から全部をつなごうとしないことが結果的に近道になります。レビューの一次確認のように範囲の決まった 1 業務を選び、2 週間ほど回して手応えを確かめてから広げる。この進め方であれば、通知に埋もれることも、判断のつかない指摘に振り回されることもありません。スモールスタートで 1 業務を AI エージェントに任せるところから始めてみてください。
AI活用の伴走支援をご検討の方へ
本記事で紹介したAIエージェントの活用に向けて、自社の業務でも具体的に進めたい・相談したいとお考えの方は、ぜひGiftX AIエージェント構築支援までお問い合わせください。
GiftX AIエージェント構築支援では、貴社の業務に合わせて1業務単位のスモールスタートから本番運用まで、AIエージェント構築をワンストップで支援します。ユースケースの洗い出しから、PoC、本番運用、社内ナレッジ化まで伴走します。
AI活用にご関心のある方は、ぜひ一度ご相談ください。
▶ GiftX AIエージェント構築支援の詳細・お問い合わせはこちら
