プルリクエストが何であるかを技術に詳しくない友人に説明しようとして、まるで Krispy Kreme のコンベアベルトのように彼らの目がうつろになるのを見たことがありますか？ AI があなたのリポジトリを理解するだけでなく、あなたのために PR を開くことができると伝えたらどうなるでしょう。 ようこそ 2025 年へ。あなたのコードエディターは、ちょっとした副操縦士であり、ちょっとしたおせっかいな運転手であり、そして—正しく設定すれば—かなりまともなインターンです。
このガイドでは、GitHub を Claude Code に接続し、プルリクエストを自動生成する方法について説明します。 ステップごとの設定、実際のワークフロー、および回避すべきいくつかの落とし穴を通して、「え？」から「Ship it（リリース）！」へと進んでいきます。 GitHub を接続し、Claude Code に何が起こっているかを確認させ、アルゴリズム的な悪魔と取引したような気分になることなく、実際にマージできる PR を開いて更新する方法を学びます。
注意: ここでは主に 2 つのパスが表示されます。Claude Code の GitHub Actions 統合を使用する方法と、Model Context Protocol (MCP) サーバーを使用して、Claude に GitHub API への安全でスコープされたアクセスを許可する方法です。 どちらを選ぶべきでしょうか？ GitHub でプラグアンドプレイの PR ヘルプが必要な場合は、Actions ルートが最適です。 粒度の細かい権限でローカルのチャット駆動型リポジトリ制御が必要な場合は、MCP が強力なツールとなります。
構築するもの
- GitHub を Claude Code に安全に接続します。
- Claude にリポジトリを分析させ、変更を提案し、PR を開かせます。
- レビュー、ラベル、チェックリスト、さらにはフォローアップコミットも自動化します。
- リポジトリ全体の名前を「final_final_v2」に変更しないように、安全策を追加します。
これが重要な理由
コンテキストの切り替えは、誰も投票しなかった生産性税だからです。 (調子の良い日の) ジュニア開発者と同等の厳密さで PR を開くことができる AI は、実際に時間を節約できます。 人間を置き換えるためではなく—落ち着いてください—エンジニアリングの「ああ、定型文」の部分を置き換えるためです。
パス A: Claude Code GitHub Actions で PR を自動生成する
一日中 GitHub にいる (仲間入りしましょう) 場合、このパスを使用すると、Issue や PR のコードを分析し、変更を提案し、PR を開いたり更新したりできるボットをリポジトリから直接利用できます。
必要なもの
- 制御できる GitHub リポジトリ (または、泣かずに壊すことができるブランチ)。
- Actions とシークレットを構成するためのリポジトリ管理者アクセス権。
- アクションまたはワークフローで必要な場合は、Claude API キー。
ステップ 1: リポジトリで GitHub Actions を有効にする
- リポジトリ → [Settings] → [Actions] → [General] に移動します。
- 「Allow all actions and reusable workflows（すべてのアクションと再利用可能なワークフローを許可する）」を有効にします (または、セキュリティ担当者がすでに疑いの目を向けている場合は、組織が承認したアクションに制限します)。
ステップ 2: Claude Code ワークフローを追加する
.github/workflows/claude-pr-bot.yml を、希望するワークフローに基づいてトリガーを作成します。 一般的なパターンを 2 つ示します。
オプション 1: Issue 駆動型 PR
- 特別なラベル (例: ai-pr) を付けて Issue を開くと、ワークフローが実行されます。
- Issue プロンプト (例: 「ダークモードトグルを追加」) を読み取り、新しいブランチを作成し、Claude を使用してファイルを編集し、コミットをプッシュし、詳細な概要を含む PR を開きます。
オプション 2: 既存の PR でコメント駆動型の編集
- 「@claude please refactor the settings modal」とコメントすると、ワークフローが実行されます。
- 差分を分析し、変更を提案し、PR ブランチに更新をプッシュします。
スターターワークフロー (ハイレベルなスケッチ)
name: Claude PR Bot
on:
issues:
types: .
- 統合とユースケースに関する簡単なガイドは、実際のチームで自動化するのが妥当なこと (およびそうでないこと) を鳥瞰的に示します。
- 視覚的な学習者であれば、このチュートリアルで、AI によって自動生成された PR が最初から最後まで実際に動作する様子を確認できます。
パス B: MCP 経由で GitHub を Claude Code に接続する (ローカルのパワーユーザー向け)
Claude にローカルリポジトリのコンテキスト—マシン上のファイル、調整中のブランチ、信頼できるコマンド—で作業させたい場合は、MCP が許可されたブリッジを提供します。 これはリポジトリのドアマンのようなものと考えてください。Claude が開くことができるドアを決定します。
必要なもの
- Claude Desktop または MCP ツールをサポートする IDE 統合。
- ローカルで実行する GitHub MCP サーバー。スコープを制限するトークンで構成されています。
- 本当に必要なスコープ (例: repo:status、public_repo、pull_request write) のみの個人アクセストークン (PAT)。
ステップ 1: GitHub MCP サーバーを取得する
- 選択した GitHub API 操作 (Issue の検索、ブランチの作成、PR のオープンなど) を公開する公式のオープンソースサーバーがあります。 必要なものだけを有効にするように構成可能なので、AI の混乱を減らし、セキュリティを維持できます。 MCP サーバーと例のより広いビューについては、中央ディレクトリを確認してください。
ステップ 2: サーバーと通信するようにクライアントを構成する
- クライアント構成ファイル (例: AI アプリの JSON 構成) で、GitHub MCP サーバーを登録し、環境変数を介してトークンを渡し、許可されたリポジトリをホワイトリストに登録します。
- プロのヒント: トークンを構成ファイルではなく、システムのキーチェーンまたは dotenv ファイルに配置します。 次の全体会議で注意事例にならないようにしてください。
ステップ 3: ツールの表面領域をテストする
- Claude にオープンな Issue をリストしたり、特定のファイルを読んだり、ブランチを作成したりするように依頼します。 明示的に許可しなかったことは何もできないことを確認します。
- 基本的なコマンドの正当性を確認した後にのみ、create_pull_request を有効にする必要があります。
ステップ 4: Claude に PR を提案して開かせる
- プロンプトの例: 「リポジトリ org/app-frontend で、新しいブランチ feat/dark-toggle を作成し、SettingsPanel.tsx でダークモードの設定トグルを実装し、テストを更新し、QA のチェックリストを含む PR を開きます。」
- サーバーが調整します。リポジトリの状態を読み取り、(ローカルファイルツールを構成した場合) 変更を書き込み、ブランチをプッシュし、テンプレートで PR を開き、概要を投稿します。
本音を言うと: 実際に必要なガードレール
- 読み取り専用のドライラン: 書き込みアクセス権の前に、Claude に統合された差分 (git diff) を生成させます。 目視で確認した後でマージします。
- テンプレート化された PR 本文: リスクノート、テスト計画、およびロールアウト手順を含めます。 ボットにテンプレートを完成させます。 人間にそれをレビューさせます。
- ラベリングルール: ai-generated や needs-tests などのラベルを自動的に適用して、物事を検出可能で正直に保ちます。
- ブランチ名: ブランチ保護ルールを使用して、プレフィックス (ai/ または bot/) を必須にします。 ロボットにも制服が必要です。
逸話の時間: AI に「認証バグを修正」するように依頼しました。 AI は認証を削除することでそれを「修正」しました。 生産性には最適です！ 文字通り他のすべてにとって最悪です。 スコープを狭く、プロンプトを具体的にし、CI テストを厳密に保ちます。
ゼロから PR へ: 現実的なエンドツーエンドのシナリオ
シナリオ: React プロジェクトで不安定な debounce テストを修正する
- Issue を開きます: 「Debounce util: CI で 200ms の境界で不安定。」 ai-pr のタグを付けます。
- ワークフローがトリガーされます。 debounce.ts と関連するテストを検索します。
- Claude は差分を提案します: jest.useFakeTimers でタイマーを調整し、アサートにマージンを追加し、ドキュメントを更新します。
- ボットは次の情報を含む PR を開きます: タイトル、概要、理論的根拠、テスト計画、およびリスク評価。
- 差分を確認し、プッシュバックします: 「遅延=0 のエッジケース」
- @claude handle delay=0 with immediate flush; add test とコメントします。 ワークフローが再実行され、コミットがプッシュされます。
- CI が合格します。 Squash してマージします。 どこかで、不安定なテストが「参った」と叫びます。
優れたプロンプトの見え方 (および避けるべきこと)
- 優れている: 「SettingsPanel.tsx にダークモードトグルを追加します。 localStorage に永続化します。 SettingsPanel.test.tsx を更新します。 ESLint ルールに従ってください。 /src/ui/ および /src/utils/ のみを変更します。 最大 250 行。」
安全にする: セキュリティとコンプライアンスのクイックチェック
- トークンスコープ: 必要な場合にのみ repo:contents write を使用します。 PR 作成には pull_request write を推奨します。
- リポジトリの許可リスト: ボットを単一のリポジトリまたは組織にロックします。
- ログ: ボットがそのアクションとプロンプト (シークレットを除く) をログに記録していることを確認します。 Dockerfile を「改善」したときに証拠が必要になります。
- ブランチ保護: ai/* ブランチには 2 人の人間による承認が必要です。
トラブルシューティング: ボットがボットにならない場合
- ブランチをプッシュできません: contents: write の Actions 権限と、トークンにリポジトリ書き込みアクセス権があることを確認します。
- 空の PR を開きます: コンテキストビルダーが適切なファイルを渡していません。 ファイル選択ロジックを厳密にします。
- 大きなリポジトリでタイムアウトします: コンテキストを変更されたパスまたはマニフェストに制限します。 AI は、他の私たちと同じように、10GB のモノレポでは消化不良を起こします。
- PR テンプレートを無視します: テンプレートが .github/pull_request_template.md にあるか、リポジトリ設定でリンクされていることを確認します。
どちらのパスを使用するか
- Issue またはコメントから PR を自動生成する軽量な方法が必要で、すべてが GitHub で発生する場合は、GitHub Actions を使用します。
- Claude をローカル環境または複数のツールで非常に具体的なコントロールで操作させたい場合は、MCP を使用します。
注目すべき点: ワークフローの簡単な健全性チェックをしたい場合、または堅実なスタータープロンプトを生成したい場合は、Sider.AI が PR テンプレートとガードレールプロンプトの作成を支援し、実際のリポジトリスニペットを使用してそれらを反復処理できます。 まるで、実際にコードを書き、あなたのデスクチェアを盗まない、意見の強いエディターがいるようなものです。 コピーしたい一般的なパターン
- AI PR ラベルと CODEOWNERS: ロボットと議論するのが好きなレビューグループに ai/* PR をルーティングします。
- ステップごとのコミット: Claude に「stuff」という名前の 1 つのメガコミットではなく、明確なメッセージを含む小さなアトミックコミットを作成するように依頼します。
- テストファーストモード: ワークフローに最初にテストを生成させ、CI を実行し、次に実装を生成させます。 遅くなります。 より良いです。
- マージ後の雑用: ドキュメント、フィーチャーフラグ、またはクリーンアップのためのフォローアップ Issue を自動的に開くワークフローを追加します。
簡単な競合他社の状況確認
- 他の人も同様の GitHub フローに他の LLM を接続しています。 それらは機能しますが、Claude Code のコード推論と「よくわかりません」と言う意欲により、何時間もの推測とチェックを節約できます。 GitHub Actions の統合により、レビューが自然に行われる場所に適切に維持され、MCP ルートはパワーユーザーにとって柔軟です。
10 分間のセットアップチェックリスト
- パスを選択します: GitHub Actions (より高速) または MCP (より多くの制御)。
- ワークフローを追加するか、MCP サーバーを構成します。
- 厳密なコンテキストビルダーを構築します: ファイルリスト、制限、およびルール。
- 最初に小さな変更でテストします。 マージします。 お祝いします。 PM に「スループットを拡大した」と伝えます。
手元に置いておくためのクイックリファレンス
- Claude Code GitHub Actions のドキュメント (パターン、トリガー、例)。
- ビデオチュートリアル: AI によって生成された PR のエンドツーエンド。
- きめ細かい、許可されたアクセスのための GitHub MCP サーバー。
- インスピレーションのための MCP サーバーのディレクトリと例。
Stern のまとめ
Claude Code で PR を自動化しても、エンジニアリングチームを置き換えることはありません。 エンジニアリングチームが最も嫌う雑用を置き換えることになります。 狭いスコープ、明確なプロンプト、および厳密なレビューから始めます。 ボットに足場を処理させ、あなたが考えることを処理させます。 次に、utils2.ts ファイルをやっと削除するなどの楽しい作業に戻ります。 ダクトテープと夢でアプリをまとめて保持していることを知っているため、避けてきました。
今すぐ未来の自分を少しでも不機嫌にしないようにしてください。 そして、ボットが暴走したら？ [Revert] ボタンがどこにあるかはわかっています。
FAQ
Q1:Claude Code は単独でプルリクエストを開くことができますか？
はい。 GitHub Actions または MCP のセットアップにより、Claude Code はブランチを作成し、変更をプッシュし、概要とチェックリストを含むプルリクエストを開くことができます。 許可を厳密に保ち、人間によるレビューを必須にして、セキュリティを削除してセキュリティを「最適化」しないようにしてください。
Q2:GitHub を Claude Code に接続する最も安全な方法は何ですか？
最小限のスコープのトークン、リポジトリの許可リスト、およびブランチ保護を使用します。 Actions または MCP のどちらを使用する場合でも、ドライランを有効にし、AI によって生成されたプルリクエストをマージする前にテストに合格することを要求します。
Q3:AI PR がモノレポ全体に触れないようにするにはどうすればよいですか？
許可されたディレクトリとファイルマニフェストを使用してコンテキストをスコープし、実行あたりのファイル数を制限します。 優れたプロンプトも役に立ちます—パスとサイズの制限について具体的にしてください。
Q4:AI プルリクエストが空または低品質なのはなぜですか？
コンテキストビルダーが Claude に間違ったファイルまたは詳細が少なすぎるファイルを供給している可能性があります。 明確な目標、制約、およびテストの期待を提供し、2 パスフローを検討してください: 最初にテストを生成し、次いで実装を生成します。
Q5:Claude Code に GitHub Actions または MCP を使用する必要がありますか？
PR とレビューの迅速なリポジトリネイティブ自動化が必要な場合は、GitHub Actions を使用します。 ローカル制御、カスタムツール、またはきめ細かい権限が必要な場合は、MCP を使用すると、より多くのパワーが得られます (ただし、セットアップが少し多くなります)。
