GitHub IssueからPRにする流れ
Issueは作業の入口、PRは変更確認の場所です。Issueの目的を小さく切り、branch、差分、確認項目へつなげると、AI作業でも迷いにくくなります。
このページでわかること
- Issueで目的と範囲を決める
- branch名と対象ファイルを揃える
- PRで完了条件を確認する
まず確認すること
- IssueにSecretsや個人情報を書きすぎていないか見る
- やらないことを明記する
- closeする条件をPR側で説明する
やってはいけないこと
- 曖昧なIssueから大きな差分を作る
- 認証情報を作業メモへ残す
- 確認項目なしでmerge判断へ進む
安全寄りに進める手順
- 対象のrepo、branch、PR、Actions runを確認する。
- Secrets、APIキー、token、.env、個人情報が差分やログに出ていないか見る。
- 必要な場合は値を停止または再発行し、影響範囲を整理する。
- 変更は小さなbranchとPRに分け、CIとreviewで確認する。
CodexやAI作業時の注意
AIに作業を渡す時は、対象ファイル、触らないファイル、確認項目を明記します。認証情報や実際のキー値は本文、Issue、PR説明、ログ、レポートに残さないようにします。
公式情報で確認する領域
Actions、Secrets、PR、repository visibility、workflow permissionsは仕様が変わることがあります。実作業前にはGitHub Docsで最新の説明を確認してください。
IssueとPRをつなぐと「なぜ」と「どう」が1本の線になる
Issueは「何を・なぜやるか」を書く場所、PRは「どう変えたか」を見る場所です。この2つをつなげておくと、後から見た人（未来の自分を含む）が「この変更はどんな問題を解決するために行われたのか」を一気通貫で追えます。つなげ方は簡単で、PRの説明文にIssue番号（例：#12）を書くだけでリンクされ、closes #12と書けばmerge時にIssueが自動で閉じます。
実務での流れ：Issue起点の作業サイクル
- ①気づいた問題・やりたい改善をIssueに書き溜める（この時点では着手しない）
- ②着手する時、そのIssue用のbranchを作る（例：
fix-issue-12） - ③作業してPRを作り、説明文に
closes #12と目的の要約を書く - ④差分を確認してmerge → Issueが自動で閉じ、記録が完結する
この流れはCodexやClaude Codeとの相性が特に良く、「Issue #12の内容に沿って修正して」という指示だけで、AIに文脈ごと作業を渡せます。頭の中のTODOをIssueに出しておくことが、そのままAIへの指示書のストックになる、という一石二鳥の運用です。着手前のタスクが全部Issueに見える状態は、作業の抜け漏れ防止にも効きます。