Claude Code + GitHub Issues で Issue から PR まで全自動化する

概要¶

Claude Code と GitHub を連携させ、「Issue を起こして Claude Code に渡す → 実装させる → PR を立てさせる」という自動化フローを実現した事例。人間がやることは Issue を書いて Claude Code に渡すだけ、という開発体験の変化。

詳細¶

フロー全体像¶

1. 人間が GitHub Issue を作成（要件・背景・受け入れ条件を記述）
2. Issue を Claude Code に渡す
3. Claude Code が Issue を読んで実装する
4. Claude Code が git commit + PR 作成まで行う
5. 人間が PR をレビューしてマージ

人間の作業は「Issue を書く」「PR をレビューする」の2点に集約される。実装・テスト・PR 作成という中間工程を Claude Code が担う。

Claude Code が Issue を扱う仕組み¶

Claude Code には gh CLI との連携機能があり、以下のようなコマンドで Issue の内容を読み込める。

# Issue の内容を読み込んで実装させる例
gh issue view 123 | claude -p "この Issue を実装してください"

# または Claude Code のセッション内で
gh issue view 123
# → Claude Code が内容を解釈して実装計画を立てる

Claude Code は Issue のタイトル・本文・ラベル・コメントを文脈として受け取り、既存コードベースを読みながら実装を進める。実装完了後は gh pr create を使って PR を自動作成する。

Issue の書き方が重要になる¶

このフローで品質を左右するのは「Issue の書き方」。曖昧な Issue を渡すと曖昧な実装が生まれる。

良い Issue の構成例：

## 背景
ユーザーがパスワードリセット後に古いセッションが有効なままになっている

## 要件
- パスワードリセット完了時に、そのユーザーの全セッションを無効化する
- 現在のセッション（リセット操作をしているセッション）は継続する

## 受け入れ条件
- [ ] パスワードリセット後、他のデバイスからのアクセスが無効になる
- [ ] 現在のデバイスのセッションは有効なまま
- [ ] 既存のテストがすべてパスする

受け入れ条件を箇条書きで明示することで、Claude Code がテストを書く際の基準にもなる。

PR 作成までの自動化¶

Claude Code は実装後に以下を自動で行う：

# Claude Code が内部で実行するイメージ
git checkout -b feature/password-reset-session-invalidation
git add .
git commit -m "feat: invalidate all sessions on password reset"
gh pr create \
  --title "feat: invalidate all sessions on password reset" \
  --body "Closes #123\n\n## 変更内容\n..." \
  --assignee "@me"

PR の本文には「何を変更したか」「なぜ変更したか」「どのようにテストしたか」が自動的に記述される。

このフローの意義：エンジニアの役割の変化¶

従来：「要件理解 → 設計 → 実装 → テスト → PR 作成」をすべてエンジニアが行う

新しいフロー：「要件定義（Issue 作成）→ レビュー」に集約

エンジニアに求められるスキルが「実装力」から「問題定義力・レビュー力」にシフトする。Issue を正確に書く能力と、AI が書いたコードを正しく評価する能力が重要になる。

なぜ重要か / いつ使うか¶

単純な機能追加・バグ修正など、要件が明確なタスクに特に有効
チーム開発で「実装者が不足している」「並列で複数機能を進めたい」場面
Issue ドリブンな開発文化があるチームへの導入がスムーズ
「Issue を書く = 仕様を考える」という習慣がすでにある組織ほど恩恵が大きい
逆に、Issue の書き方が雑なチームでは効果が薄く、まず Issue 文化の整備が必要