PR・提出

Phase 7 PR と提出前チェックリスト。

PR 作成と 提出前チェック で品質を担保する。

やること

  1. Phase 7 で PR
  2. 提出前チェック

完了: 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 カテゴリを確認する。詳細は折りたたみ内。抜けがあればレビューで指摘される前に直す。

下表はカテゴリ一覧。各リンクで詳細チェック項目へジャンプする。

カテゴリ確認項目数詳細
規約・基盤215.1
ドキュメント515.2
コード515.3
検証515.4
動作515.5
ログ・モニタリング415.6
履歴・PR315.7
セキュリティ815.8
インフラ・CI/CD515.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 のライフサイクル/保持期間を設定