Claude CodeのGitHub連携でできること。非エンジニアがコミットを任せる3段階の手順

GitHub Appを入れて、ワークフローのファイルを置いて、Issueに@claudeと書けば動く。手順としてはそのとおりです。書いてあることは正確です。ただ、私のように非エンジニアでAIにコードを書いてもらっている人間には、もう少し手前で知りたいことがありました。つないだ結果、毎日の作業が具体的にどう変わるのか、という話です。私は仕事で使っているいくつかのリポジトリをGitHubと同期させていて、コミットの整理はほとんどClaude Codeに任せています。gitのコマンドは、いまも半分くらいしか覚えていません。

Claude CodeとGitHubをつなぐと変わること

先に言葉を短く整理します。gitは、ファイルの変更を少しずつ記録していく仕組みです。GitHubは、その記録をインターネット上に置いて共有できるようにしたサービスで、置き場所ひとつぶんの単位をリポジトリと呼びます。作業のひと区切りを記録することがコミット、記録した内容をGitHub側に送ることがpushです。プルリクエスト（PR）は「この変更をまとめて本体に入れていいですか」という提案の箱だと思ってもらえれば、ほぼ間違いありません。

つないで変わったことを、私の実感で3つ挙げます。1つ目は、いつ何を変えたかが全部残ること。2つ目は、おかしくなった地点まで巻き戻せること。3つ目が、非エンジニアには一番大きいのですが、変更の中身をAIに日本語で説明してもらえることです。

3つ目を補足します。AIにコードを書いてもらうと、動くものは手元にできますが、中身を全部読み切れているわけではありません。1週間後に「先週なにを直したんだっけ」となったとき、記録が残っていないと、動いているファイルを上から読み直すしかなくなります。GitHubにつないでおくと、そこが「この日はフォームの送信先を変えて、ついでに通知の文面を直しました」という日本語の一覧に変わります。gitを覚えるためではなく、自分が書いていないコードを他人事にしないために使っている、というのが正直なところです。

非エンジニアがGitHubを使う理由

GitHub連携の解説は、ほとんどが開発チーム向けに書かれています。レビューの工数を減らす、Issueの消化を早める、といった文脈です。読んでいて悪くはないのですが、レビューをお願いする相手も、Issueを積んでくれる同僚もいない一人運用の人にとっては、動機としてかなり弱いです。

私が使っている理由は単純で、AIに書かせたものが壊れたときに、壊れる前へ戻すための保険です。手元にはスプレッドシートを動かす小さなプログラム（Google Apps Script）、数字を見るためのローカルのWebアプリ、AIに自分の道具を持たせるための自作の連携サーバー（MCP）などが、少しずつ増えてきました。どれも仕事の道具なので、動かなくなると単純に困ります。

困る場面は、だいたい決まっています。うまく動いているものに「ついでにこれも足して」と頼んだ結果、足した機能は動くけれど元の機能が黙って壊れる、というパターンです。全部を読める人なら差分を見て気づけますが、私は気づけないことがあります。記録が残っていれば、少なくとも「動いていた地点」に戻せます。戻せる状態が用意できているだけで、AIに頼むときの心理的なハードルがだいぶ下がりました。

ついでに言うと、パソコンが壊れたときの保管場所にもなります。手元にしか置いていないファイルは、パソコンごと壊れると取り戻せません。AIに作ってもらったスクリプトほど「また作ってもらえばいい」と軽く考えがちですが、実際にやり直すと、当時どういう条件で作ったかを思い出すところで止まります。

段階1：Claude Codeにコミットを任せる

いきなりGitHub Actionsまで行かなくていい、というのが私の考えです。順番としては、まず手元でコミットを任せる。次にpushとプルリクエストまで任せる。最後にGitHub上で自動的に動かす。3段階で慣れると、途中で何が起きているか分からなくなる場面が減ります。

つなぎ方そのものも、頼めばやってもらえます。まずブラウザでGitHubのアカウントを作り、置き場所（リポジトリと呼びます）を非公開で1つ作っておきます。作った直後の画面に、手元のフォルダとつなぐための短いコマンドが表示されるので、作業用のフォルダをClaude Codeに開かせて、その内容をそのまま渡します。「この手順でつないで」と伝えるだけで、順に進めてくれます。自分の手で打つのはブラウザ側の操作だけなので、コマンドを覚える必要はありません。

リポジトリの作成ごとClaude Codeに頼む方法もあります。ただ、最初の1回はブラウザで作っておくほうが、どこに何ができたのかを目で確認できるぶん迷いにくいです。

最初の段階でやっていることは3つです。

1つ目は、差分の説明です。「いま変わっているところを、一覧にして日本語で説明して」と頼みます。変更のあったファイルと、その中身をどう変えたかが並びます。コミットする前に、変更点を日本語で読む。手間はかかりますが、省かないと決めています。頼んでいないファイルが混ざっていることが、たまにあるからです。

2つ目は、コミットメッセージです。あとから読んで意味が分かる短い一文を書いてもらいます。自分で書くと「修正」「更新」のような、3日で意味を失う言葉になりがちでした。AIは変更の中身を読んで書くので、「通知の送信時刻を朝8時に変更」くらいの具体さで残ります。

3つ目が、作業単位でのグルーピングです。数日ぶんの変更が溜まっていると、無関係なファイルが1つのコミットに全部入ります。あとで戻したいときに、必要な変更まで一緒に消えるので都合が悪い。「関係のあるファイルごとにまとめて、コミットを分けて。分け方を先に提案して」と頼むと、まとまりごとの案が出てきます。私はその提案を見て、了解を出してから実行させています。

一点だけ、譲らないほうがいいことがあります。パスワード、APIキー、接続情報の入ったファイルは、コミットに含めないことです。一度GitHubに送ってしまうと、あとから消しても記録のほうに残り続けます。「認証情報を含むファイルはステージしない、見つけたら警告する」と頼み方の側にも書いておくと、うっかりが減ります。Claude Codeの導入そのものについてはClaude Codeの始め方で書いているので、まだ触っていない方はそちらから読んでみてください。

段階2：pushとプルリクエストまで任せる

手元のコミットに慣れたら、GitHub側へ送るところまで任せます。gh CLIというGitHubの公式コマンドを入れておくと、Claude Codeがプルリクエストの作成まで一続きでできるようになります。「いまのブランチをpushして、変更の要点をまとめたプルリクエストを作って」と頼む形です。

ひとつ疑問が出ます。レビューする相手が自分しかいないのに、プルリクエストを作る意味はあるのか、という話です。上位に並ぶ解説記事は、ほぼ全部がチーム開発を前提にしているので、この点には答えてくれません。

レビューする相手が自分しかいなくても、プルリクエストを挟む意味はあります。私も一人で回していますが、プルリクエストの作成はClaude Codeに任せています。理由は3つあります。1つ目は、変更が1画面で一覧になることです。手元のファイルを行ったり来たりするより、追加された行と消えた行が色で並んでいるほうが、素人でも異変に気づけます。2つ目は、まとめて取り消せることです。プルリクエストの単位で戻せるので、「先週の実験ぶんだけ無かったことにする」ができます。3つ目は、説明が残ることです。プルリクエストの本文には、AIに変更の要点を書いてもらえます。数ヶ月後に読み返したとき、当時なぜそう変えたのかまで追えます。

ブランチという言葉が出たので、こちらも短く説明します。ブランチは、本体をそのままにして作業用の枝を作る仕組みです。枝の上で好きに壊してみて、うまくいったら本体に合流させます。うまくいかなければ枝ごと捨てれば、本体は触られていない状態で残ります。AIに実験的な変更を頼むときは、枝を切ってからにすると、失敗しても戻す手間がかかりません。

段階3：GitHub ActionsでClaude Codeを動かす

3段目が、検索で最初に出てくる話です。GitHub Actionsは、GitHub側で自動的にプログラムを走らせる仕組み（CIと呼ばれる領域です）で、Claude Codeを組み合わせると、手元のパソコンを開いていなくてもGitHub上でAIが作業する状態になります。IssueやプルリクエストのコメントにAI宛てのメンション（「@claude」と書きます）を残すと起動する、という作りが基本です。

導入の全体像はおおむね決まっています。GitHub Appを入れて動かしたいリポジトリを選ぶこと、ワークフローのファイル（yml形式のテキストで、リポジトリの .github/workflows という場所に置きます）を用意すること、APIキーをGitHubのSecretsという保管場所に登録すること。以上の3つです。Claude Codeの中で「/install-github-app」というクイックセットアップ用のコマンドを実行すると、Appの導入からファイルの作成まで案内してくれます。自分でymlを書く手動セットアップもありますが、最初は案内に乗ったほうが早いでしょう。

APIキーの置き場所だけは、間違えると取り返しがつきません。ワークフローのファイルに直接書くと、リポジトリを見られる人全員に見えます。必ずSecretsに登録して（ANTHROPIC_API_KEY のような名前を付けます）、ワークフローの側からは名前で呼び出す形にしてください。

できることとして紹介されるのは、だいたい次の3つです。Issueに要件を書いてメンションすると、実装してプルリクエストまで作らせる。プルリクエストに対して自動でコードレビューをさせる。リポジトリに置いてあるCLAUDE.md（プロジェクトの前提やルールを書いておくテキスト）を、GitHub側で動くAIにも読ませて作法を揃える。どのタイミングで動かすかは、ワークフローファイルのトリガー条件を書き換えれば変えられます。

正直に書くと、私はここまで踏み込んでいません。手元で差分を見てからGitHubへ送る形で間に合っているからです。一人で回している範囲だと、GitHub上でAIが勝手に動いていることの安心感より、手元で差分を見てから送る安心感のほうが勝ちます。無理に3段目へ行かなくても、段階1と段階2だけで履歴と巻き戻しの恩恵はほぼ取れます。チームで回していて、レビュー待ちが渋滞しているような状況なら、3段目の価値は変わってくるはずです。

勝手にpushさせないための線引き

AIに任せる範囲を広げるときは、先に止め方を決めておくと落ち着きます。私が外に触るものを自動化するときは、いつも同じ考え方をしています。上限を先に決める、外へ出る操作は手前で止める、緊急停止の手段を用意しておく。あとから機能を足したときに走りすぎないよう、先に枠をはめておく順番です。

GitHubまわりに当てはめると、線引きはこうなります。読むこと、差分を出すこと、コミットを作ることまでは自由にやってもらう。pushだけは自分の合図で動かす。本体のブランチへ直接送ることは禁止して、必ず枝からプルリクエストを経由させる。3つを決めておくと、暴走らしい暴走は起きにくくなります。

Claude Codeには、特定の操作をするたびに自分で決めた処理を挟み込む仕組みも用意されています。毎回口頭で「pushはしないで」と言い続けるのではなく、仕組みの側で止めておきたい方はClaude Codeのhooksの使い方もあわせて読んでみてください。言わなくても止まる状態にしておくほうが、結局は楽でした。

あわせて、コミット前に差分を自分で見る運用は崩さないほうがいいと思っています。全部のコードが読めなくても、変更されたファイルの名前と数を見るだけで「頼んでいないところが動いている」には気づけます。読めないから見ない、ではなく、読めない人ほど一覧だけは見る。地味な確認ですが、私はここで何度か助かっています。

GitHub連携にかかる費用

混同しやすいところなので、分けて書きます。手元のパソコンでClaude Codeを動かし、コミットやpushを任せる範囲であれば、GitHub側に追加の費用はかかりません。GitHubのアカウントは無料で作れますし、非公開のリポジトリも無料の範囲で持てます。

費用の話が出てくるのは、3段目のGitHub Actionsからです。2種類の請求が同時に発生します。ひとつはAIを動かした分の従量課金、もうひとつはGitHub Actionsの実行時間ぶんです。非公開リポジトリでは毎月の無料枠があり、超えた分は実行時間に応じて課金される形になっています。サブスクの定額と、Actionsの実行時間は別の財布だと考えておくと、請求を見て驚かずに済みます。

サブスクに入っていればGitHub側もそのまま使えるのか、という質問はよく見かけますが、扱いは時期によって変わります。契約する前に公式の料金ページで最新を確認するのが確実です。走りすぎ対策としては、ワークフローの設定でAIとのやり取りの上限回数を切っておく方法（max-turnsという項目です）があり、1回の起動で延々と考え続けるのを防げます。Claude Code本体の料金と、私が実際に払っている金額の内訳はClaude Codeの料金にまとめました。

うまく動かないときの確認先

つまずきどころは、だいたいパターンが決まっています。

メンションしてもAIが反応しない場合、まず疑うのはGitHub Appが対象のリポジトリに入っているかどうかです。App自体は入れたけれど、有効にするリポジトリの選択から漏れている、というのがよくあります。次にSecretsに登録したAPIキーの名前と、ワークフローファイルで呼び出している名前が一致しているか。大文字小文字の違いだけで動きません。あわせて、そのリポジトリで誰が起動できる設定になっているかも見てください。外部の人のコメントでは動かない作りが標準です。

AI自身が作ったコミットやプルリクエストをきっかけに、別のワークフローが連鎖して動かない、という挙動もあります。自動で作られたものが次の自動を呼んで無限に回り続けるのを防ぐための仕組みなので、故障ではありません。連鎖させたい事情があるなら、起動条件の書き方を変える必要があります。

認証まわりのエラーが出るときは、キーの有効期限、支払い方法の登録状況、権限の範囲の3つを順に見ます。エラーの文面をそのままClaude Codeに貼って「原因の候補を3つ、確認する順番も付けて」と頼むと、当たりを付けるところまでは代わりにやってくれます。

git logという作業ログ

思いがけずよかったのが、履歴が作業ログとして使えることでした。git logは、いつ何をコミットしたかを時系列で並べて表示するコマンドです。週の終わりに「今週のコミットを一覧にして、種類ごとにまとめて」と頼むと、その週に手を動かした中身が箇条書きで出てきます。

git logが、そのまま週の振り返りになるとは思っていませんでした。記憶で書く週報は、印象の強い出来事に引っ張られます。実際に残っている記録から起こすと、地味な整備作業が結構な割合を占めていたことに気づけます。何に時間を使っているかを、感覚ではなく記録で見られる。マーケティングの仕事をしている身としては、ここが一番ありがたかった部分かもしれません。

履歴の管理をAIに渡してから、私の側に残ったのは「何を作るか」と「どこで止めるか」を決める時間でした。コマンドを思い出す時間、コミットメッセージを考える時間、先週の自分が何をしたか探す時間は、まとめて向こうへ渡してしまってかまわないと思っています。手放してみると、思っていたよりも自分がやらなくていいことをやっていました。

よくある質問

Q. GitHubでClaude Codeを使うには何が必要ですか？
A. 手元でコミットやpushを任せるだけなら、GitHubのアカウントとリポジトリ、それにパソコンにgitが入っていれば大丈夫です。GitHub上でAIを自動的に動かしたい場合は、追加でGitHub Appのインストール、ワークフローファイルの設置、SecretsへのAPIキー登録の3つが必要になります。

Q. Claude CodeはGitHubのリポジトリを読めますか？
A. 手元にリポジトリを取り込んでいれば、ファイルも変更履歴も読めます。読ませたうえで「このリポジトリが何をするものか説明して」と頼めば、構成の概要を出してくれます。GitHub上にあるリポジトリを直接読ませたい場合は、GitHub App経由で連携するか、gh CLIを入れておくと扱いやすくなります。

Q. Claude CodeとGitHub Copilot、どっちを使えばいいですか？
A. 私はCopilotを使っていないので優劣は判断できませんが、役割は違います。Copilotはエディタの中で書きかけのコードの続きを提案する使い方が中心で、Claude Codeは「この機能を足して」と目的を伝えて、複数のファイルをまたいで作業してもらう使い方が中心です。自分でコードを書く人は前者が手放せないでしょうし、私のように書かない人は後者から入るほうが自然だと思います。

Q. Claude CodeにGitHubは必須ですか？使わないとどうなりますか？
A. 必須ではありません。GitHubにつながなくてもClaude Codeは動きますし、手元でファイルを作ってもらうところまでは何も変わりません。違いが出るのは壊れたときで、履歴が無いと「動いていた状態」に戻せず、直したところと壊れたところが混ざったまま手探りになります。作ったものを使い続ける予定があるなら、早めにつないでおくほうが後悔しにくいでしょう。

まとめ

Claude CodeのGitHub連携は、いきなり全部を自動化する必要はありません。まず手元でコミットを整理してもらう。慣れたらpushとプルリクエストまで任せる。必要になったらGitHub Actionsまで広げる。順番を踏めば、非エンジニアでも途中で迷子になりにくいです。

覚えておきたいのは2つだけです。外へ出る操作は自分の合図で動かすこと。コミットの前に変更点の一覧は自分で見ること。2つを守っている限り、AIに任せる範囲を広げても、そこまで怖い思いはしないでしょう。

gitのコマンドを覚えなくても、変更が残って、戻せて、説明してもらえる状態は作れます。作れてしまうと、自分が考えるべきことが「どう記録するか」から「次に何を作るか」へ移っていきます。手を動かす部分をどこまで渡せるか、興味があれば少しずつ試してみてください。