AIエージェントPRテンプレートの作り方：Summary・Tests run・Not run・Risksを固定する

3行まとめ

Summary

何を変えたかを短く書きます。

Tests

実行した確認と未実行を分けます。

Risks

残るリスクとreviewerへの注意点を書きます。

PR本文は、agent作業を人間が判断するための橋渡しです。

• AIエージェントが作るPull Requestでは、差分だけでなく、Summary、Issue、Scope、Changes、Tests run、Not run、Risks、Reviewer notes、Follow-upを本文に固定するとレビューしやすくなります。
• 特にTests runとNot runを分けることが大事です。未検証を空欄にすると、reviewerは「確認済みなのか、未確認なのか」を差分から推測することになります。
• PRテンプレートは承認の代替ではありません。CODEOWNERS、required reviews、required checks、人間のmerge判断は残し、テンプレートは判断材料を揃えるために使います。

本文の事実確認には、GitHubのPull Request template公式Docs、Pull Request review公式Docs、CODEOWNERS公式Docs、Copilot coding agent公式Docsを使っています。Xで伸びているAI agent PR、PRテンプレート、未検証報告の投稿は需要シグナルとして扱い、本文の根拠にはしていません。

この記事でわかること

9項目

Summary、Issue、Scope、Changes、Tests、Not run、Risks、Notes、Follow-up。

Markdown

PR templateとして置ける形にします。

レビュー

CODEOWNERSやrequired reviewsと並べます。

改善

薄いPR本文をテンプレートへ戻します。

テンプレートはPR本文を埋めるだけでなく、レビュー条件を揃えます。

• AI agent PR本文に固定したい9項目
• SummaryとScopeを短く狭く書かせる理由
• Tests runとNot runを分ける方法
• RisksとReviewer notesに残すべき判断材料
• GitHub Pull Request templateのMarkdown例
• CODEOWNERSやrequired reviewsを残す運用

AI agentがPRを作れるようになると、レビューの入口は楽になります。しかし、PR本文が薄いままだと、reviewerは差分から作業意図、確認済み範囲、未検証項目、リスクを読み解く必要があります。

PRテンプレートは、AIのためだけのものではありません。人間がレビューしやすい情報を、agentにも人間にも同じ形で要求するための型です。

前提知識

項目	内容	見方
PR template		GitHubでPR本文テンプレートを置く方法を確認します。
PR review		approve、request changes、commentの扱いを確認します。
CODEOWNERS		pathごとの責任者レビューを確認します。
Copilot agent		agent PRを人間が確認する前提を確認します。

テンプレートは入力補助であり、レビュー責任そのものではありません。

GitHub公式Docsでは、repositoryにPull Request templateを置くことで、新しいPR本文へテンプレートを入れられると説明されています。単一テンプレートのほか、複数テンプレートをPULL_REQUEST_TEMPLATEディレクトリに置き、URLのtemplate query parameterで指定する方法も案内されています。

GitHubのPR reviewでは、reviewerはコメント、approve、request changesを行えます。CODEOWNERSを使うと、特定pathを変更したPRで責任者レビューを要求できます。つまり、PR本文テンプレートを入れても、review、required checks、CODEOWNERSの責任は残ります。

Copilot coding agentのようにagentがPRを作る場合も同じです。PRが作られたことと、mergeしてよいことは別です。PR本文は、merge判断のための材料を揃える場所として使います。

テンプレートは自動承認ではない

テンプレート項目が全部埋まっていても、それは承認ではありません。PR本文は、reviewerが見るべき情報を揃える道具です。

条件

AI agent PRでは、少なくとも「実行した確認」と「実行していない確認」を分けます。どちらも空欄なら、レビュー前に差し戻します。

注意点

テンプレートを長くしすぎると、agentも人間も形式だけ埋めるようになります。短い固定欄にし、空欄が危険な項目だけ必須扱いにします。

AI agent PR本文で固定する9項目

項目	内容	見方
Summary		変更の要約。
Issue		元Issueや依頼へのリンク。
Scope		触った範囲と対象外。
Changes		主な変更。
Tests run		実行した確認。
Not run		未実行と理由。
Risks		残るリスク。
Notes		reviewerへの注意点。
Follow-up		別Issueに送る項目。

PR本文で確認できないことは、reviewerが差分から推測することになります。

AI agent PRでは、次の9項目を固定します。

項目	目的	例
Summary	変更概要	ログイン失敗時のエラー表示を追加
Issue	元Issue	closes #123
Scope	触った範囲	frontend/auth/*
Changes	主な変更	表示ロジック、テスト追加
Tests run	実行した確認	npm run test -- LoginForm
Not run	未実行と理由	E2Eは対象外、手元環境なし
Risks	残るリスク	文言変更、既存UIへの影響
Reviewer notes	見てほしい点	エラー文言とアクセシビリティ
Follow-up	別Issueに送ること	i18n対応は別Issue

差分から推測させない

PR本文が薄いと、reviewerは差分から意図を読み取る必要があります。AI agent PRでは、agentがどういう入力を受け、何を確認し、何を確認していないかが特に重要です。

Issue Formと対応させる

前の記事で扱ったAIエージェント向けGitHub Issue Formを使うなら、PR本文はIssue Formの項目と対応させます。Issue側のGoal、Scope、Done、Checks、Safetyが、PR側のSummary、Scope、Tests run、Not run、Risksへつながる形です。

Summaryは短く、Scopeは狭く書かせる

1. 1目的

   Issueで求められた変更を1文にします。

2. 2範囲

   触ったpathやmoduleを示します。

3. 3対象外

   今回触っていない範囲を明記します。

4. 4差分

   大きい変更は分割候補にします。

Summaryが長いPRは、Scopeが広がっているサインです。

Summaryは長い説明ではなく、何を変えたかを1から3行で書きます。Scopeは、触ったpathやmoduleを短く書きます。

Summaryの悪い例と良い例

悪い例	良い例
いろいろ修正しました	ログイン失敗時のエラーメッセージ表示を追加しました
UI周りを改善しました	LoginFormの送信失敗時にform下部へエラーを表示します
テストを直しました	LoginFormの失敗ケースにunit testを追加しました

Scopeに対象外も書く

Scopeには、触った範囲だけでなく、触っていない重要範囲も書かせます。

• Changed: frontend/auth/LoginForm.tsx
• Tests: frontend/auth/LoginForm.test.tsx
• Not changed: API response format, auth flow, routing

大きいPRは分ける

Summaryが長くなる、Scopeが複数domainに広がる、Changesが5項目を超える場合は、PRを分けるサインです。AI agentは差分を広げやすいので、テンプレートで早めに気づけるようにします。

Tests runとNot runを分ける

Run

実行したコマンドと結果を書きます。

Fail

失敗したコマンドと理由を書きます。

Not run

未実行の理由を隠しません。

Evidence

スクショやログの場所を書きます。

未検証を空欄にしないことが、AI agent PRの最低ラインです。

AI agent PRで一番大事なのは、検証済みと未検証を分けることです。

Tests runには、実行したコマンドと結果を書きます。Not runには、実行していない確認と理由を書きます。空欄にしないほうがよいです。

Tests runに書くこと

項目	例
command	npm run typecheck
result	pass
command	npm run test -- LoginForm
result	pass
evidence	screenshot path、CI link、log path

Not runに書くこと

未実行	理由
E2E	対象画面のE2Eが未整備
visual check	ローカルbrowser環境なし
integration test	外部API credentialが必要
migration dry-run	DB変更なしのため対象外

未検証を成功扱いにしない

「未実行だが問題なさそう」と書かせないようにします。未実行は未実行です。reviewerが、merge前に追加確認するか、別Issueへ送るかを判断します。

この考え方は、チーム向けAGENTS.mdテンプレートの最終報告形式とも同じです。実行コマンド、結果、未検証項目を固定すると、人間が判断しやすくなります。

RisksとReviewer notesを残す

項目	内容	見方
互換性		API、DB、UI、外部連携への影響。
権限		secret、token、CI/CD、外部通信の変更。
運用		rollback、feature flag、監視の要否。
未決定		別Issueへ送る判断や質問。

AIが判断できない領域を、人間reviewerへ渡します。

AI agentが作ったPRでは、RisksとReviewer notesを明示します。ここは、AIが完璧に判断する場所ではなく、人間へ渡す場所です。

Risksに書くこと

リスク	例
互換性	API responseやpublic interfaceを変える可能性
UI	390px幅や多言語文言で崩れる可能性
データ	migration、既存データ、rollback
権限	token、secret、外部API、CI/CD
運用	feature flag、監視、deploy順

Reviewer notesに書くこと

Reviewer notesは「ここを見てほしい」という依頼です。

• エラー文言がプロダクト方針に合っているか
• 既存UIとの見た目の一貫性
• 追加テストの粒度
• 仕様として対象外にしてよいか
• secretや権限変更が本当にないか

Follow-upを分ける

PR内で全部直そうとすると、差分が広がります。i18n、E2E追加、docs追記、周辺refactorなどは、必要ならFollow-upへ分けます。

PR templateのMarkdown例

項目	内容	見方
Summary		1から3行に制限します。
Linked issue		関連Issueを明示します。
Tests run		command、resultをセットにします。
Not run		未実行理由を必須にします。
Risks		権限、データ、互換性を確認します。

長い文章より、reviewerが見る場所を揃えることを優先します。

GitHubのPull Request templateはMarkdownで置けます。単一テンプレートなら、repository root、docs、.githubなどに置く構成が使われます。

AI agent PR向けの最小例は次のようにします。

Summary:
- 

Linked issue:
- 

Scope:
- Changed:
- Not changed:

Changes:
- 

Tests run:
- Command:
  Result:

Not run:
- Check:
  Reason:

Risks:
- 

Reviewer notes:
- 

Follow-up:
- 

見出しを短くする

テンプレートの見出しは短いほうが埋めやすいです。長い説明はコメントやHTML commentに入れたくなりますが、AI agentがその説明まで本文に残すことがあります。必要最小限にします。

空欄を許さない項目を決める

すべての欄を必須にすると運用が重くなります。AI agent PRでは、Summary、Linked issue、Tests run、Not run、Risksだけは空欄にしない、というように決めます。

複数テンプレートを使い分ける

bugfix

再現、修正、回帰テストを重視します。

feature

仕様、影響範囲、受け入れ条件を重視します。

docs

確認範囲とリンク切れを重視します。

agent

未検証、禁止操作、reviewer notesを重視します。

1つの万能テンプレートより、作業種別ごとに軽く分けます。

GitHub公式Docsでは、複数のPull Request templateを用意し、テンプレートを指定して使う方法も説明されています。AI agent PR用、bugfix用、docs用、release用を分けると、必要な項目を軽くできます。

テンプレート	重視する項目
agent	Tests run、Not run、Risks、Reviewer notes
bugfix	Reproduction、Root cause、Regression test
feature	Spec、Acceptance criteria、Rollout
docs	Updated pages、Link check、Screenshots
dependency	Version change、Lockfile、Security note

万能テンプレートにしない

すべてのPRに同じ長いテンプレートを使うと、形骸化します。AI agent PR用は、未検証、リスク、reviewer notesに強く寄せます。

URLでテンプレートを指定する

複数テンプレートを置く場合、PR作成URLでtemplate query parameterを使う運用もできます。agentやworkflowからPRを作る場合は、使うテンプレートを固定できるか確認します。

CODEOWNERSとrequired reviewsを残す

1. 1PR本文

   agentの報告を確認します。

2. 2Checks

   required checksを確認します。

3. 3Owner

   CODEOWNERSや担当者が見ます。

4. 4Merge

   人間がリスクを受け入れてmergeします。

テンプレートが埋まっていても、承認は別の判断です。

PR templateが整っていても、reviewは必要です。CODEOWNERS、required reviews、required checksを残します。

CODEOWNERSで責任者を呼ぶ

GitHubのCODEOWNERSを使うと、特定pathに責任者reviewを要求できます。AI agentが作ったPRでも、owner reviewを省略しないほうが安全です。

Required checksで検証を止める

PR本文にnpm run testがpassと書いてあっても、CIのrequired checksを通します。PR本文は報告、CIは機械的な検証です。

Authorとreviewerを分ける

agent PRでは、誰がagentに依頼したか、誰がレビューするかを分けます。GitHub Docsでは、Copilotが作成したPRの承認に関する制約にも触れられています。組織設定とbranch protectionに合わせて確認します。

導入初週の進め方

1. 1日目

   agent PR用テンプレートを1つ作ります。

2. 2日目

   小さいdocs修正で試します。

3. 3日目

   test追加やbugfixで試します。

4. 5日目

   薄かった項目を直します。

5. 7日目

   PR種類ごとのテンプレート分割を決めます。

最初は自動化より、reviewerが読める本文を揃えます。

最初の1週間は、テンプレートを1つ作り、小さいPRで回します。

1日目: agent PR用テンプレートを作る

Summary、Linked issue、Scope、Changes、Tests run、Not run、Risks、Reviewer notes、Follow-upだけに絞ります。

2日目: docs修正で試す

低リスクなdocs PRで、agentがテンプレートを埋められるか確認します。Not runが空欄にならないかを見ます。

3日目: test追加やbugfixで試す

小さいbugfixで、Tests runとRisksが実用的に書けるか確認します。

5日目: 薄かった項目を直す

Summaryが長すぎる、Not runが空欄、Risksが「なし」だけ、Reviewer notesがない、といった失敗をテンプレートへ戻します。

7日目: テンプレート分割を決める

agent用、bugfix用、docs用などに分けるかを決めます。分けすぎると運用が重くなるので、よく使う2種類からで十分です。

失敗時に見直す条件

薄いSummary

変更目的が分かりません。

Not run空欄

未検証が隠れます。

Riskなし

人間判断が抜けます。

Scope外

IssueとPRがずれています。

レビューで困った点を、次のテンプレート改善に戻します。

AI agent PRで次の状態が出たら、テンプレートを直します。

失敗	見直す項目
Summaryが薄い	1から3行の例を入れる
Scope外変更が多い	Changed / Not changedを分ける
Tests runが曖昧	commandとresultを分ける
Not runが空欄	未実行理由を必須にする
Risksが空欄	権限、互換性、データ、運用を例示する
Reviewer notesがない	見てほしい点を1つ以上書かせる

「なし」を許す項目と許さない項目を決める

Risksが本当にないPRもあります。ただし、AI agent PRでは、何を見て「なし」としたのかが必要です。たとえば「権限、DB、外部通信の変更なし」と書けば、reviewerが確認しやすくなります。

テンプレートだけで直さない

PR本文が薄い原因は、Issueが曖昧なこともあります。その場合は、AIエージェント向けGitHub Issue Form側の入力項目も見直します。

FAQ

必須化

Not runとRisksは空欄を避けます。

自動merge

テンプレート入力だけではmergeしません。

複数PR

PR種類ごとにテンプレートを分けます。

長文化

短い固定欄にします。

迷ったら、reviewerが判断しやすいかを基準にします。

PRテンプレートを埋めれば人間レビューは不要ですか

不要にはなりません。テンプレートは判断材料を揃える道具です。required reviews、CODEOWNERS、required checks、人間のmerge判断を残します。

Not runは毎回必要ですか

AI agent PRでは必要にするほうが安全です。未実行がなければ「none」と書かせます。空欄は避けます。

Risksに何を書けばよいですか

互換性、権限、secret、DB、外部通信、UI、運用、rollbackを見ます。何もなければ、確認した領域を書いたうえで「該当なし」にします。

複数テンプレートは必要ですか

最初は1つで十分です。運用してから、agent用、bugfix用、docs用のように分けます。

agentがテンプレートを守らない場合はどうしますか

PRを差し戻し、テンプレートの項目名やIssue Formを見直します。長い説明より、短い必須欄と例を増やすほうが効くことがあります。

参照した主な情報源

• https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repository
• https://docs.github.com/en/enterprise-cloud@latest/communities/using-templates-to-encourage-useful-issues-and-pull-requests/about-issue-and-pull-request-templates
• https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews
• https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners
• https://docs.github.com/en/copilot/how-tos/use-copilot-agents/coding-agent/assign-copilot-to-an-issue

次に読むなら

更新履歴

1. 2026年5月31日

   GitHub Pull Request template、PR review、CODEOWNERS、Copilot coding agent公式Docsを確認して初版を作成しました。

導入時には最新Docsと組織設定を再確認してください。

• 2026年5月31日: GitHub Pull Request template、PR review、CODEOWNERS、Copilot coding agent公式Docsを確認し、初版を作成しました。