PR・提出
Phase 7 PR と提出前チェックリスト。
PR 作成と 提出前チェック で品質を担保する。
完了: CI green・レビュー可能な説明がある
提出前に PR前チェック。指摘 → tasks/lessons.md
Phase 7 では PR を出し、CI を green にしたうえでレビューループを回します。説明文と個人メモを AI に整えさせると、レビュアーの負担が下がります。
PR 作成の流れ
開発者・AI・CI・レビュアーの典型的な流れは次のとおりです。
sequenceDiagram
participant Dev as 開発者
participant AI as AI
participant CI as CI
participant Rev as レビュアー
Dev->>AI: PR description 生成
AI-->>Dev: 概要・確認手順・観点
Dev->>CI: PR 作成
CI-->>Dev: green
Dev->>Rev: レビュー依頼
loop レビュー対応
Rev-->>Dev: コメント
Dev->>AI: [REVIEW] 修正依頼
Dev->>CI: 再実行
CI-->>Dev: green
end
Rev-->>Dev: Approve
PR description に載せる項目と、参照すべき docs は次の表にまとめています。
| PR description 項目 | 必須 | 参照先 |
|---|---|---|
| 概要(ユーザ視点) | 必須 | — |
| 変更内容・影響範囲 | 必須 | docs/<feature>/ |
| テスト戦略 | 必須 | 05_test_plan.md |
| 動作確認手順 | 必須 | — |
| 関連 Issue / ADR リンク | 推奨 | docs/adr/ |
| レビュー観点 | 推奨 | Plan 出力 |
| 既知の残課題 | 任意 | Follow-up Issue |
貼り付けタイミング:ローカルテストと CI が通ったあと、PR を開く直前(または 下書き PR(下書き PR(Draft PR)) を Ready にする直前)に、当該機能のチャット履歴をコンテキストに含めて送ります。
ここまでの全チャットから、PR descriptionと、必要なら個人メモ用のサマリを作ってください。
【PR description】
リポジトリの .github/pull_request_template に合わせる。なければ以下:
- 概要 (1段落、ユーザ視点での変更点)
- 変更内容 (機能/設計/影響範囲、箇条書き)
- テスト戦略 (新規/変更したテストの種類と網羅範囲)
- 動作確認手順 (レビュアーがローカルで再現するための手順)
- 関連Issue / 関連ドキュメントへのリンク (**docs/<feature>/** へのリンク、関連ADRがあれば **docs/adr/NNNN-*.md** へのリンク)
- スクリーンショット/動画 (UI変更なら)
- レビュー観点の指示 (重点的に見てほしい箇所)
- 既知の残課題 / Follow-up Issue化候補
【任意の個人メモ z_docs/<feature-name>/history/yymmdd-hhMM-summary.md】
- フェーズごとの主要な意思決定 (時系列)
- 私が指摘・修正させたAI出力 (業務知識が反映されている箇所)
- 採用しなかった代替案とその理由
- 残課題 / TODO / 改善余地 (次のPR/Issue化候補)
- 学び (チーム共有したい知見)
【含めないもの】
- AI出力のコード全文 (要点のみ)
- 試行錯誤のノイズ
レビューコメント対応のループ
GitHub のレビューコメントが付いたら、本文をそのまま次のプロンプトに入れて AI に渡します。コミット接頭辞は [REVIEW] を使います。
レビューコメントを取り込みます。
【コメント】
[GitHub のコメント本文をそのまま貼る]
【対応方針案】
- 修正方針: [A案 / B案]
- 影響範囲: [ファイル/テスト]
このコメントに対する対応を:
1. テスト追加 (RED)
2. 実装修正 (GREEN)
3. 必要なら公式ドキュメント更新 (docs/)
の順で行ってください。
コミットメッセージ接頭辞は [REVIEW] を使ってください。
Phase 7 後の最終確認。関連 → 履歴 · AIの誤り
PR 提出前に 9 カテゴリを確認する。詳細は折りたたみ内。抜けがあればレビューで指摘される前に直す。
下表はカテゴリ一覧。各リンクで詳細チェック項目へジャンプする。
| カテゴリ | 確認項目数 | 詳細 |
|---|---|---|
| 規約・基盤 | 2 | 15.1 |
| ドキュメント | 5 | 15.2 |
| コード | 5 | 15.3 |
| 検証 | 5 | 15.4 |
| 動作 | 5 | 15.5 |
| ログ・モニタリング | 4 | 15.6 |
| 履歴・PR | 3 | 15.7 |
| セキュリティ | 8 | 15.8 |
| インフラ・CI/CD | 5 | 15.9 |
AI レビュー — Agent Review · Bugbot(2026)
出典: Cursor 公式 BP。人間レビューの前に AI で一次スクリーニング。
| タイミング | 手段 | 本リポ |
|---|---|---|
| 生成中 | diff ビューで Stop · 指示し直し | Plan に戻る(18-plan-revert) |
| Agent 完了後 | Review → Find Issues(Agent Review) | /review |
| ローカル差分 | Source Control → Agent Review vs main | 提出前チェック「検証」 |
| PR 作成後 | Bugbot 自動レビュー | CI green 後 · CodeRabbit 等 と併用可 |
カテゴリ別チェック項目(9種・クリックで展開)
規約・基盤
- 利用中ラインのルール (
.cursor/rules//AGENTS.md/CLAUDE.md/.claude/skills//.agents/skills/) が最新の業務制約を反映している - ルールに違反する実装を書いていない(CI lint で検知できると尚良)
ドキュメント (docs/ が公式、個人メモは任意) → 11.6
docs/<feature-name>/に公式ドキュメント(要件・設計・DB・技術選定・テスト計画・ログ・デプロイ)が揃っている- 重要な技術選定は docs/adr/ に ADR 起票されている(11.7 ADR)
- docs/README.md / docs/architecture.md / docs/glossary.md が最新と整合
- docs/glossary.md に新規用語が追加されている
- Mermaid は最小構文。エッジラベルに HTML を使っていない
コード
- レイヤ構成通り(依存方向が正しい)
- 業務不変条件を破る実装がない
- 業務例外と技術例外が分離されている
- エラーメッセージに業務情報が含まれる
- 既存規約・既存パターンに従っている(理由なく外れていない)
検証(ルール・テスト)
- 利用中ラインのルールに沿った実装(CI lint / レビューで確認)
- 追加・更新したテストがあり、CI で green
- 境界値・異常系が必要な範囲でカバーされている
- 既存テストが落ちていない
- TDD 採用チームのみ:
[RED]→[GREEN]→[REFACTOR]のコミット順序
動作
- CI green
- ローカル(Docker)/ staging で動作確認済み
make upで起動 /make testでテスト通過- マイグレーションが forward / rollback できることを確認済み
- リスク高い場合は機能フラグ等の段階リリース手段を用意
ログ・モニタリング
- 業務イベントでログが出ている
- 機微情報がマスキングされている
- 必要なメトリクス・トレースが追加されている
- 重要機能ならエラー時にアラートが飛ぶ設定がある
履歴・PR
- PR description が埋まっている
- 採用しなかった代替案と理由が PR description または docs に記録されている(重要なものは docs/adr/ にも)
- レビュアーが見るべきポイントが明示されている
セキュリティ
.envなどシークレットがコミットに混入していない- API キー・トークン類が履歴・コード・ログに含まれていない
- 認可チェックが必要な箇所に漏れがない
.gitignoreで必要なファイルが除外されている(11.2).env.exampleが最新の必要環境変数を反映している- 個人 IDE 設定(
.vscode/.idea/個人分)がコミットに含まれていない - AWS 長期アクセスキーがコード・ワークフロー・履歴に含まれていない(OIDC 使用)
- IAM Role の権限が最小化されている(
Resource: "*"がない)
インフラ・CI/CD (該当する場合)
.github/workflows/ci.ymlが green.aws/task-definition.jsonの environment / secrets が新規環境変数を反映- 新規 AWS リソースは Terraform/CDK でコード化されている(手動作成していない)
- S3 バケット名・IAM Role ARN 等が環境別(dev/staging/prod)に分離されている
- 新規リソース時は CloudWatch Logs / S3 のライフサイクル/保持期間を設定