結論：Claude CodeでIssue駆動開発をPR自動化するなら、最初に作るべきものは高度なプロンプトではなく、「Issueの粒度」「リポジトリ内の作業標準」「GitHub Appと権限の境界」です。
- 要点1：Claude Code GitHub Actionsは、IssueまたはPRで
@claudeとメンションすると、コード分析、実装、PR作成、バグ修正を行えると公式Docsで説明されています。 - 要点2：本番運用では、Issueテンプレート、
CLAUDE.md、CI、Code Review、permissionsを組み合わせて「勝手に進めてよい範囲」を小さくします。 - 要点3：PR自動化は「人間のレビューをなくす仕組み」ではなく、Issueから検証済みPRまでの下準備を標準化する仕組みとして設計すると失敗しにくいです。
対象読者：Claude CodeをGitHub Issue運用、PR作成、レビュー、CI修正に組み込みたい開発者、EM、PM、Platform Engineering担当者。
今日やること：既存リポジトリに「Claudeに依頼してよいIssue」と「人間が先に設計判断するIssue」を分けるラベルを追加してください。
事例区分：実装パターン解説。この記事は特定企業の実測事例ではなく、2026年7月7日時点でClaude Code公式ドキュメントに存在する機能を確認し、Issue駆動開発に落とし込んだ運用設計です。
「Issueを書いたら、そのままClaude CodeがPRまで作ってくれないですか？」
Claude Codeの相談で、この質問はかなりよく出ます。気持ちはすごく分かります。Issueには要件が書いてある。リポジトリにはテストもCIもある。だったら @claude に任せて、PRまで出してもらいたいですよね。
ただ、実際に運用設計をしてみると、詰まる場所はモデル性能ではありません。Issueの粒度が大きすぎる、受け入れ条件が曖昧、権限が広すぎる、CIの失敗をどこまで自動修正してよいか決めていない。ここで止まるんです。
私自身、最初にこの手のワークフローを設計したとき、「Claudeに詳しく指示を書けば大丈夫」と考えていました。ところが、実装途中で仕様判断が必要になったり、テスト追加の範囲が広がったりすると、PRは作れてもレビューしづらくなります。正直、Issue駆動開発ではプロンプトより前に「IssueをPR単位に切る技術」が重要でした。
この記事では、Claude Code GitHub Actions、Claude GitHub App、Code Review、Auto-fix、CLAUDE.md、permissions、hooksを使って、IssueからPRまでを安全に自動化する手順をまとめます。公式Docsで確認できない機能名や設定は使いません。
Claude CodeでIssueからPRを作る全体像
Claude Code GitHub Actionsは、GitHub上のIssueまたはPRで @claude とメンションすることで動かすのが基本です。公式Docsでは、Claudeがコードを分析し、PRを作成し、機能を実装し、バグを修正できると説明されています。さらに、プロジェクトの CLAUDE.md ガイドラインと既存コードパターンを尊重する、とされています。
つまり、Issue駆動開発の流れは次のように設計できます。
- 人間がIssueを書く：背景、変更範囲、受け入れ条件、触ってよいファイルを明記する。
- Issueで
@claudeに依頼する：Claude Code GitHub Actionsが起動し、必要に応じてブランチとPRを作る。 - CIを通す：lint、test、typecheck、security scanなど、人間がレビューする前の最低ラインを機械で確認する。
- Code Reviewを走らせる：Claude CodeのCode Review、通常のレビュアー、CODEOWNERSを組み合わせる。
- CI失敗やレビューコメントを修正する：必要に応じてAuto-fixや追加の
@claudeコメントで修正を依頼する。 - 人間がマージ判断する：仕様、UX、セキュリティ、リスクの最終判断はチーム側に残す。
大事なのは、Claude Codeを「Issueを閉じる担当者」にするのではなく、「PRをレビュー可能な状態まで進める実装担当」として扱うことです。ここを間違えると、PRの量は増えるのにレビュー負荷が下がらない、という状態になります。
CI/CD側の設計を先に整理したい場合は、内部記事の 【2026年最新】Claude CodeでCI/CDパイプライン自動構築｜GitHub Actions設定5パターン もあわせて読むと、Actions側の考え方をつかみやすいです。
事前準備：GitHub App、Secrets、CLAUDE.md、権限をそろえる
Claude Code GitHub Actionsのクイックセットアップでは、Claude Codeターミナルで /install-github-app を実行し、Claude GitHub Appのインストール、GitHub Actionsワークフロー、APIキーSecretの追加へ進む流れが公式Docsにあります。手動セットアップの場合は、Claude GitHub Appをリポジトリにインストールし、ANTHROPIC_API_KEY をリポジトリSecretに追加し、ワークフローを .github/workflows/ に置きます。
公式Docsでは、GitHub Appが Contents、Issues、Pull requests の読み取り・書き込み権限を要求することも説明されています。ここは軽く見ない方がいいです。PRを作れるということは、リポジトリ上のコードを変更できるということです。便利さと同時に、チームの権限設計がそのまま品質と安全性に出ます。
導入前にそろえるものは、最低でも次の5つです。
- GitHub App：対象リポジトリだけにインストールする。最初から全Orgに広げない。
- Secret：直接Claude APIを使うなら
ANTHROPIC_API_KEYをリポジトリまたはOrg Secretで管理する。 - Workflow：
anthropics/claude-code-action@v1を使い、@claudeトリガーを明示する。 - CLAUDE.md：ビルド、テスト、設計原則、PR作成ルール、触ってはいけない領域を書く。
- 権限ルール：
/permissionsやsettingsで、実行できるBash、編集範囲、確認が必要な操作を決める。
ここで一つ、現場でよくある誤解があります。CLAUDE.md は「Claudeに守ってほしい文脈」であって、強制的なセキュリティ境界ではありません。公式Docsでも、CLAUDE.md はコンテキストとして扱われ、操作を確実に止めたい場合はPreToolUse hookなどを使う、と説明されています。禁止事項は文章でお願いするだけでなく、permissionsやhooksで止める設計にしてください。
チーム導入時の権限設計は、内部記事の Claude Code権限設計ガイド【2026】 にも整理しています。Issue-to-PR自動化では、この権限設計がかなり効きます。
手順1：Issueテンプレートを「PRに変換しやすい形」にする
Issue駆動開発の失敗は、Issueの書き方でかなり決まります。Claude Codeに限らず、人間が読んでも曖昧なIssueは、AIに渡しても曖昧です。逆に、背景、変更範囲、受け入れ条件、テスト観点が明確なIssueは、そのままPRの説明文にも使えます。
私が最初に見直すのは、Issueのテンプレートです。ここを整えるだけで、Claudeに追加で説明する回数が減ります。特に「やらないこと」を書く欄が重要です。実装エージェントは親切なので、必要そうに見える周辺修正まで広げがちです。Issue側でスコープを閉じると、PRのレビューがかなり楽になります。
例えば、次のようなIssueテンプレートにします。
## 背景
ユーザー設定画面で通知メールのON/OFFを切り替えられるようにする。
既存の通知送信処理は変更しない。
## 変更範囲
- frontend/src/pages/settings/Notifications.tsx
- frontend/src/api/userSettings.ts
- backend/src/routes/userSettings.ts
## 受け入れ条件
- ユーザーが通知メールのON/OFFを保存できる
- 保存後に画面を再読み込みしても状態が維持される
- 既存のプロフィール更新テストが通る
- 新規テストを1つ以上追加する
## やらないこと
- 通知メール本文の変更
- 管理者向け設定画面の変更
- DBスキーマの大規模な再設計
## Claudeへの依頼
@claude
このIssueを実装してください。
不足している情報があれば、最初に質問してから作業を開始してください。
仮定した点は必ず「仮定」と明記してください。
PR本文には、変更点、テスト結果、残ったリスクを書いてください。このテンプレートで効くのは、受け入れ条件 と やらないこと です。Issueが「設定画面を改善する」だけだと、ClaudeはUI改善、API変更、DB変更、テスト修正まで広く探索します。探索自体は便利ですが、PR自動化では変更の広がりがレビューコストになります。
Issueテンプレートにはラベル運用も入れておくと安定します。例えば、claude-ready はClaudeに依頼してよいIssue、needs-design は先に人間が設計判断するIssue、security-sensitive はClaude単独で進めないIssue、という形です。ラベル名は何でも構いませんが、チーム全員が同じ意味で使えることが大事です。
手順2：CLAUDE.mdに「PR作成ルール」を書く
CLAUDE.md は、Claude Codeが毎回読むプロジェクト固有の説明書です。公式Docsでは、コーディング規約、ビルドコマンド、プロジェクト構成、ワークフローなど、毎セッションで必要な文脈を書く場所として説明されています。
Issue-to-PR自動化では、CLAUDE.md に「PRをどう作るか」を書きます。ここにテストコマンドだけを書くチームも多いのですが、PR本文の形式、レビュー観点、スコープ制限まで入れておくと効果が出やすいです。
# Claude Code project instructions
## Build and test
- Install dependencies with npm ci.
- Run npm run lint before opening a PR.
- Run npm test for files touched by the change.
- If a full test run is too expensive, explain which tests were run and why.
## Issue-to-PR rules
- Keep each PR focused on one GitHub Issue.
- Do not expand scope beyond the Issue acceptance criteria.
- If a requirement is ambiguous, ask a question before editing files.
- If you make an assumption, write it in the PR body under "Assumptions".
- Include a "Test results" section in every PR body.
- Include a "Residual risks" section when behavior changes.
## Files that need extra care
- Do not change database migrations unless the Issue explicitly asks for it.
- Do not modify authentication, billing, or permission logic without asking first.
- Do not edit deployment workflows unless the Issue has the label ci-change.ポイントは、「Claudeがよく間違えること」ではなく「チームが毎回確認したいこと」を書くことです。例えば、認証、課金、権限、個人情報、決済、インフラは、変更自体を禁止するのではなく「Issueに明記がない限り質問する」と決めます。これだけでも、勝手な周辺修正を抑えやすくなります。
一度、CLAUDE.md に「テストを書いてください」とだけ書いていた運用を見たことがあります。この書き方だと、どの層のテストを追加するのか、既存のテストをどう扱うのか、PR本文に何を書くのかが曖昧でした。結果として、テストは増えるのにレビューの確認観点は毎回バラバラになります。正直、PR自動化では「テストを書く」より「テスト結果をPR本文でどう説明するか」まで決めた方が運用しやすいです。
CLAUDE.md の設計を深掘りするなら、内部記事の 【2026】CLAUDE.md設計・運用ガイド｜効くプロジェクトメモリ も参考になります。
手順3：GitHub Actionsワークフローを追加する
次に、.github/workflows/claude.yml を追加します。公式Docsでは、Claude Code Action v1のパラメータとして prompt、claude_args、anthropic_api_key、github_token、trigger_phrase、use_bedrock、use_vertex などが説明されています。直接Claude APIを使う場合、anthropic_api_key が必要です。
以下は、IssueとPRコメントで @claude を検知して起動する構成例です。リポジトリの実情に合わせて、許可するコマンドやイベントを絞ってください。
name: Claude Code
on:
issue_comment:
types: [created]
pull_request_review_comment:
types: [created]
pull_request_review:
types: [submitted]
issues:
types: [opened, assigned]
jobs:
claude:
if: |
(github.event_name == 'issue_comment' && contains(github.event.comment.body, '@claude')) ||
(github.event_name == 'pull_request_review_comment' && contains(github.event.comment.body, '@claude')) ||
(github.event_name == 'pull_request_review' && contains(github.event.review.body, '@claude')) ||
(github.event_name == 'issues' && (contains(github.event.issue.body, '@claude') || contains(github.event.issue.title, '@claude')))
runs-on: ubuntu-latest
permissions:
contents: write
pull-requests: write
issues: write
id-token: write
actions: read
steps:
- name: Checkout repository
uses: actions/checkout@v6
with:
fetch-depth: 1
- name: Run Claude Code
uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
trigger_phrase: "@claude"
claude_args: |
--max-turns 10
--allowedTools "Bash(npm ci),Bash(npm run lint),Bash(npm test),Bash(npm run typecheck),Read,Grep,Edit"
この例では、permissions に contents: write と pull-requests: write を与えています。PRを作るために必要な一方、広い権限でもあります。最初は検証用リポジトリ、または低リスクなアプリケーションから始めるのが現実的です。
--allowedTools は、Claude Codeに渡すCLI引数として公式Docsに記載があります。ここに何を入れるかは、チームの安全設計そのものです。たとえば、最初から Bash(*) のように広げるのではなく、npm ci、npm run lint、npm test、npm run typecheck など、Issue-to-PRに必要なコマンドから始める方がレビューしやすいです。
GitHub Actions側でCIが走らない場合は、公式Docsのトラブルシューティングにもある通り、GitHub AppまたはカスタムAppを使っているか、ワークフロートリガーに必要なイベントが含まれているか、Appの権限が足りているかを確認します。GITHUB_TOKEN 由来の制約で後続CIが期待通り動かないケースは、早めに検証しておきたいポイントです。
手順4：IssueからClaudeへ渡す依頼文を標準化する
Issue本文に @claude を入れるだけでも動きます。ただ、本番運用では依頼文を標準化した方が安定します。標準化する理由は、Claudeのためというより、人間がレビューしやすくするためです。
まずは、次の依頼文をチームの基本形にします。
@claude
このIssueを1つのPRとして実装してください。
進め方:
1. まず関連ファイルを読み、変更方針を短く整理してください。
2. 受け入れ条件を満たす最小変更で実装してください。
3. 既存の設計と命名規則に合わせてください。
4. 必要なテストを追加または更新してください。
5. lint、test、typecheckの結果をPR本文に書いてください。
制約:
- Issueに書かれていない大規模リファクタリングはしないでください。
- 認証、課金、権限、DBマイグレーションに触る必要がある場合は、作業前に質問してください。
- 不足している情報があれば、最初に質問してから作業を開始してください。
- 仮定した点は必ず「仮定」と明記してください。次に、バグ修正用の依頼文です。
@claude
このIssueはバグ修正です。
最初にやること:
- 再現条件をIssue本文から抜き出してください。
- 関連する既存テストを探してください。
- 原因候補を2つ以内に絞ってから修正してください。
PRに含めること:
- 原因
- 修正内容
- 追加または更新したテスト
- 再発防止の観点
不足している情報があれば、最初に質問してから作業を開始してください。
仮定した点は必ず「仮定」と明記してください。小さなUI変更用の依頼文も用意しておくと便利です。
@claude
このIssueは小さなUI改善です。
変更範囲:
- Issueに書かれた画面とコンポーネントに限定してください。
- デザインシステムの既存コンポーネントを優先してください。
- 新しい依存パッケージを追加しないでください。
確認:
- 画面崩れが起きそうな箇所をPR本文に書いてください。
- 可能なら既存のスクリーンショットテストまたはStorybook確認手順を書いてください。
不足している情報があれば、最初に質問してから作業を開始してください。
仮定した点は必ず「仮定」と明記してください。この3種類だけでも、Issueの運用はかなり整います。重要なのは、依頼文を毎回ゼロから書かないことです。人間が毎回違う依頼文を書くと、Claudeの出力もPR本文も揺れます。テンプレート化すると、レビュー観点もそろいます。
手順5：Code ReviewとCIで「人間が見る前の足切り」を作る
PR自動化で一番まずいのは、Claudeが作ったPRを人間が毎回ゼロから読み解く状態です。これでは自動化の意味が薄くなります。PRが開いた時点で、最低限のCI、静的解析、Code Reviewが走っている状態にしてください。
Claude CodeのCode Reviewは、公式Docsではデフォルトで本番を壊す可能性のあるバグ、つまり正しさに重点を置くと説明されています。レビューのトリガーは、PR作成後に一度、pushごと、手動の3種類が説明されており、手動では @claude review または @claude review once を使えます。
おすすめは、導入初期は次の構成です。
| フェーズ | Code Review設定 | 人間の関与 | 狙い |
|---|---|---|---|
| 検証 | Manual | レビュアーが必要なPRだけ @claude review once |
レビュー品質とコスト感を確認する |
| 限定運用 | Once after PR creation | Claude作成PRだけ人間レビュー前に確認する | 初期指摘を機械で拾う |
| 定着後 | After every push | 高リスクRepoでは慎重に使う | 修正pushごとの劣化を拾う |
「すべてのPRを毎回Claudeにレビューさせる」から始めると、レビュー量とコストが読みにくくなります。まずはClaudeが作ったPR、または claude-ready ラベルのIssueから作ったPRだけに絞る方が運用しやすいです。
コードレビューの観点をさらに細かくしたい場合は、内部記事の Claude Codeでコードレビューを効率化する実践ガイド【2026】 にも実務寄りの整理があります。
手順6：Auto-fixは「PR単位の補助」として使う
Claude Code on the webには、PRのCI失敗やレビューコメントに反応して修正するAuto-fixの説明があります。公式Docsでは、ClaudeがPRを監視し、CIチェック失敗やレビューコメントを受けて調査し、明確な修正であればpushし、曖昧な依頼や設計上重要な判断が必要な場合は質問すると説明されています。
これは便利ですが、Issue-to-PR自動化の初期段階で全PRに有効化する必要はありません。Auto-fixは、あくまで「すでに開かれたPRの修正補助」として使うのが扱いやすいです。
特に注意したいのは、PRコメントをトリガーにする他の自動化です。公式Docsでも、Atlantis、Terraform Cloud、独自GitHub Actionsなど、issue_comment イベントで動く自動化がある場合、Claudeの返信が別ワークフローを起動する可能性に触れています。インフラ操作やデプロイに関係するリポジトリでは、Auto-fixを有効化する前にコメントトリガーの棚卸しをしてください。
実務では、次の線引きが現実的です。
- Auto-fix向き：lintエラー、型エラー、単体テストの軽微な失敗、レビューコメントで指摘された小さな修正。
- 人間判断向き：仕様変更、認証・権限、DB設計、課金、外部APIの契約変更、インフラ変更。
- 禁止または要承認：デプロイ、Terraform apply、Secret更新、本番DB操作、監査ログ削除。
一度、Auto-fixに向いていないPRまで自動修正対象にして、レビューコメントの意図と違う方向に修正が進みかけたことがあります。Claudeが悪いというより、コメントが曖昧だったんです。「ここ微妙です」ではなく、「この関数の戻り値がnullのとき、既存のエラーハンドリングに合わせてください」まで書く。Auto-fixを使うなら、人間側のレビューコメントも具体化する必要があります。
手順7：permissionsとhooksで危険操作を止める
Claude Codeのpermissionsは、公式Docsで細かく説明されています。読み取り専用のファイル読み込みやGrepは承認不要、Bashコマンドやファイル変更は承認が必要、allow、ask、denyのルールがあり、deny、ask、allowの順で評価されます。
Issue-to-PR自動化では、permissionsを「Claudeを疑うため」ではなく「チームが安心して任せる範囲を明確にするため」に使います。たとえば、npm系のテストは許可するが、クラウドCLI、削除系コマンド、デプロイ系コマンドは止める、という設計です。
{
"permissions": {
"allow": [
"Bash(npm ci)",
"Bash(npm run lint)",
"Bash(npm test)",
"Bash(npm run typecheck)",
"Read",
"Grep",
"Edit"
],
"ask": [
"Bash(npm install *)",
"Bash(npx *)"
],
"deny": [
"Bash(rm *)",
"Bash(terraform apply *)",
"Bash(kubectl *)",
"Bash(aws *)",
"Bash(gcloud *)"
]
}
}hooksも有効です。Claude Codeのhooksは、ライフサイクル上の特定ポイントでコマンド、HTTPエンドポイント、MCP tool、prompt、agentなどを実行できる仕組みとして公式Docsに説明があります。たとえば、編集後にformatterを走らせる、危険なコマンドを事前にブロックする、Claudeが入力待ちになったら通知する、といった使い方ができます。
PR自動化では、hooksを次の用途に絞ると扱いやすいです。
- PreToolUse：危険なBash、Secret参照、本番環境操作を止める。
- PostToolUse：ファイル編集後にformatterや軽量lintを走らせる。
- Notification：Claudeが質問や承認待ちになったときに開発者へ通知する。
- Stop：作業終了時に、PR本文にテスト結果と残リスクがあるか確認する。
hooksを使った整形・通知の具体例は、内部記事の Claude Code Hooks実践ガイド｜整形・通知の自動化【2026】 にもまとめています。
実務で使えるプロンプト7本
ここからは、IssueやPRコメントでそのまま使いやすいプロンプトをまとめます。すべて、最後に「不足情報があれば質問」「仮定は明記」を入れています。これは事故防止の一行としてかなり効きます。
1. Issueから新規PRを作る
@claude
このIssueを1つのPRとして実装してください。
変更範囲はIssue本文の「変更範囲」に限定してください。
PR本文には、変更点、テスト結果、仮定、残ったリスクを書いてください。
不足している情報があれば、最初に質問してから作業を開始してください。
仮定した点は必ず「仮定」と明記してください。2. 既存PRのCI失敗を直す
@claude
このPRのCI失敗を確認し、原因を特定して修正してください。
修正はCI失敗に関係する最小範囲に限定してください。
CIログから判断した根拠をPRコメントで説明してください。
不足している情報があれば、最初に質問してから作業を開始してください。
仮定した点は必ず「仮定」と明記してください。3. レビューコメントを反映する
@claude
このレビューコメントに対応してください。
コメントの意図が複数に解釈できる場合は、修正前に質問してください。
既存の設計方針と命名規則に合わせてください。
対応後、どのコメントにどう対応したかをPRコメントで説明してください。
不足している情報があれば、最初に質問してから作業を開始してください。
仮定した点は必ず「仮定」と明記してください。4. テストだけ追加する
@claude
このIssueに対して、まずテストだけを追加するPRを作ってください。
本番コードの変更はしないでください。
既存のテスト構成に合わせ、失敗するテストまたは回帰を防ぐテストを追加してください。
不足している情報があれば、最初に質問してから作業を開始してください。
仮定した点は必ず「仮定」と明記してください。5. リファクタリングを小さく切る
@claude
このIssueはリファクタリングです。
挙動変更を含めず、レビューしやすい最小PRに分割する方針を提案してください。
最初のPRで変更するファイルと、後続PRに残す作業を分けて説明してください。
不足している情報があれば、最初に質問してから作業を開始してください。
仮定した点は必ず「仮定」と明記してください。6. セキュリティ観点の追加レビューを頼む
@claude review once
このPRをセキュリティ観点でレビューしてください。
特に、認証、認可、入力検証、ログ出力、Secret露出、外部API呼び出しを確認してください。
指摘は、本番影響があるものと改善提案を分けてください。
不足している情報があれば、最初に質問してから作業を開始してください。
仮定した点は必ず「仮定」と明記してください。7. マージ前の最終確認を頼む
@claude
このPRのマージ前チェックをしてください。
確認すること:
- Issueの受け入れ条件を満たしているか
- PR本文にテスト結果があるか
- 不要なスコープ拡大がないか
- 既存の設計方針と矛盾していないか
- 残リスクが明記されているか
不足している情報があれば、最初に質問してから作業を開始してください。
仮定した点は必ず「仮定」と明記してください。よくある失敗パターンと回避策
失敗1：Issueが大きすぎる
NG例：
「設定画面を改善してください」
OK例：
「通知メールのON/OFFを保存できるようにし、既存のプロフィール更新処理は変更しないでください」
Issueが大きいと、Claudeは関連ファイルを広く探索し、PRも大きくなります。Issue駆動開発では、Issueを「1PRでレビューできる単位」に切ることが先です。仕様検討、設計、実装、テスト追加を一つのIssueに詰め込まないでください。
失敗2：CLAUDE.mdに禁止事項だけを書く
NG例：
「危険なことはしないでください」「大きな変更は避けてください」
OK例：
「認証、課金、権限、DBマイグレーションに触る必要がある場合は、編集前に質問してください」
曖昧な禁止は、人間にもAIにも解釈が難しいです。触ってよい範囲、質問が必要な範囲、permissionsやhooksで止める範囲を分けて書きます。
失敗3：CIが弱いままPR自動化する
NG例：
「ClaudeがPRを作ったら人間が全部見る」
OK例：
「lint、test、typecheck、最低限のsecurity scanを通ったPRだけ人間レビューに進める」
PR自動化は、CIが弱いほど危険というより、レビューコストが下がりません。Claudeに任せる前に、CIで機械的に落とせるものを増やしてください。ここはAI導入ではなく、普通の開発基盤の話です。
失敗4：Auto-fixを広く有効化しすぎる
NG例：
「すべてのPRでCI失敗とレビューコメントを自動修正する」
OK例：
「Claude作成PR、低リスクPR、lint・型・単体テスト失敗に限定してAuto-fixを試す」
Auto-fixは便利ですが、コメントトリガーの自動化と組み合わさると、意図しないワークフローが動く可能性があります。特にインフラ、デプロイ、権限変更を含むリポジトリでは、先にGitHub Actionsのイベント設計を棚卸ししてください。
導入ロードマップ：小さく始めて、PR単位で広げる
Issue-to-PR自動化は、最初から全リポジトリに広げない方がいいです。おすすめは、3段階で導入することです。
| 段階 | 対象 | Claudeに任せる範囲 | 完了条件 |
|---|---|---|---|
| Phase 1 | 検証用Repoまたは低リスクRepo | ドキュメント、テスト追加、小さなUI修正 | PR本文とテスト結果の形式が安定する |
| Phase 2 | 開発チームの主要Repoの一部 | バグ修正、軽微な機能追加、CI修正 | レビュー差し戻しの理由がパターン化できる |
| Phase 3 | 複数Repo | Issueラベル別に自動化範囲を拡張 | permissions、hooks、Code Review設定が標準化される |
Phase 1では、Claudeに「実装の腕前」を見せてもらうより、チーム側が「どういうIssueなら任せやすいか」を学ぶことに集中します。ここでIssueテンプレート、CLAUDE.md、PR本文テンプレートを直します。Phase 2では、実際の開発フローに入れます。Phase 3で初めて複数リポジトリに広げます。
チーム展開の設計は、内部記事の Claude Codeチーム展開ガイド【2026】 も近いテーマです。Issue-to-PR自動化は個人技ではなく、チームの開発規約に入れてから効果が出ます。
FAQ：Claude Code×Issue駆動開発でよくある質問
Q1. Claude CodeはIssueから自動でPRを作れますか？
はい。公式Docsでは、Claude Code GitHub Actionsにより、IssueまたはPRで @claude とメンションすると、Claudeがコードを分析し、PR作成、実装、バグ修正を行えると説明されています。ただし、リポジトリ設定、GitHub App、Secret、Workflow、権限設計が必要です。
Q2. /install-github-app だけで本番運用できますか？
セットアップの入口としては便利です。ただし本番運用では、Issueテンプレート、CLAUDE.md、CI、Code Review、permissions、hooksまで含めて設計する方が安全です。セットアップできたことと、チームで運用できることは別です。
Q3. Claudeが勝手に大きな変更をしないようにできますか？
Issueの変更範囲、CLAUDE.md のPRルール、--allowedTools、permissions、hooksを組み合わせて抑制します。ただし、CLAUDE.md は強制設定ではなく文脈です。禁止したい操作はpermissionsやPreToolUse hookで止める設計が必要です。
Q4. Code Reviewは人間レビューの代わりになりますか？
代替ではなく、レビュー前の補助として使うのが現実的です。公式Docsでは、Code Reviewはデフォルトで正しさ、つまり本番を壊し得るバグに重点を置くと説明されています。仕様判断、UX、プロダクト上の優先度、リスク受容は人間が判断します。
Q5. Auto-fixは有効にした方がいいですか？
最初は限定的に使うのがおすすめです。lint、型エラー、単体テスト失敗など、修正意図が明確なものに向いています。インフラ、デプロイ、権限変更、DB変更のような領域では、PRコメントをトリガーにする別の自動化も含めて確認してから使ってください。
Q6. BedrockやVertex AIでも使えますか？
公式Docsでは、Claude Code GitHub Actionsのパラメータに use_bedrock と use_vertex があり、直接Claude API以外の構成も説明されています。組織のクラウド標準や認証方式に合わせて選びます。設定値や利用可能モデルは変わるため、導入時点の公式Docsを確認してください。
Q7. 非エンジニアPMがIssueを書いても使えますか？
使えますが、受け入れ条件とやらないことを明確にする必要があります。PMは「ユーザーにとって何ができれば完了か」を書き、開発者は「触ってよい範囲」「テスト観点」「技術的制約」を補う運用にすると、Claudeに渡しやすいIssueになります。
参考・出典
- Claude Code GitHub Actions — Claude Code Docs（参照日: 2026-07-07）
- Code Review — Claude Code Docs（参照日: 2026-07-07）
- Use Claude Code on the web — Claude Code Docs（参照日: 2026-07-07）
- How Claude remembers your project — Claude Code Docs（参照日: 2026-07-07）
- Configure permissions — Claude Code Docs（参照日: 2026-07-07）
- Automate actions with hooks — Claude Code Docs（参照日: 2026-07-07）
- Claude Code settings — Claude Code Docs（参照日: 2026-07-07）
- Run Claude Code programmatically — Claude Code Docs（参照日: 2026-07-07）
- Claude Code changelog — Claude Code Docs（参照日: 2026-07-07）
まとめ：今日から始める3つのアクション
- 今日やること：既存Issueを3件選び、「Claudeに任せられる粒度か」を受け入れ条件とやらないことで見直す。
- 今週中：検証用リポジトリで
/install-github-appまたは手動セットアップを行い、@claudeで小さなPRを1本作る。 - 今月中：
CLAUDE.md、permissions、Code Review、CI、Auto-fixの適用範囲をチーム標準として文書化する。
Claude Code×Issue駆動開発は、Issueを書けば全部自動で終わる魔法ではありません。でも、Issueの粒度、PR作成ルール、CI、レビュー、権限境界をそろえると、開発者が「最初の実装PRを作る時間」をかなり圧縮できます。
次に深掘りするなら、Claude Codeで作られたPRの品質をどう測るか、つまりレビュー差し戻し率、CI再実行回数、リードタイム、変更行数のばらつきを見るのがよいです。内部記事の Claude Code品質メトリクスとAuto-fix運用【2026】 も、運用後の改善テーマとしてつながります。
