プロンプト工房
なぜこう書くのか
ブロックを押すとその段落が見られます
この文章を読む人は、このタスクの背景を知らず、今日初めてこの変更内容を見ます。私が動作確認した方法は次のとおりです。{{テスト 方法}}
以下のメモとファイル一覧を読んで、プルリクエストの本文を作成してください。「何を変えたか」よりも「なぜ変える必要があったのか」が先に伝わるようにしてください。
フォーマット：「なぜ変更したのか・何が変わるのか・特に見てほしいポイント・確認手順・今回は対応していないこと」の5つの小見出しに分けてください。前の2つはそれぞれ3行以内、「見てほしいポイント」は箇条書きで最大3つ、一番上には1行の要約を付けてください。
私が記載していないパフォーマンス数値やIssue番号、リリース日程などは勝手にでっち上げないでください。メモだけでは判断が難しい箇所がある場合は、本文の末尾に「作成者への確認事項」として最大3つまで箇条書きで記載してください。
- 役割 誰として答えるか ×1
- 材料 AIが知るべきこと ×3
- やること 何をどう進めるか ×1
- 仕上がり どんな形で受け取るか ×2
PRの説明文を書く際、多くの人は「何を変えたか」だけを書いてしまいます。しかし、ファイル一覧やdiffはすでに画面上に表示されています。レビュアーが本当に知りたいのは「なぜこのアプローチを選んだのか」であり、それがないとレビューは「これ、なぜこうしたのですか？」という質問から始まり、余計な時間がかかってしまいます。
解説をもっと読む · 4段落
役割を「レビュアーの時間を節約するエンジニア」としたのは、文章量を適切にコントロールするためです。指定しないと変更ファイルごとに1段落ずつ説明するような長文が生成され、誰も最後まで読まなくなってしまいます。文脈の「背景を知らず、今日初めて見る」という一文は、社内特有の略語や前提の省略を防ぎます。
形式の5つの小見出しがこのプロンプトの骨組みです。特に「特に見てほしいポイント」と「今回は対応していないこと」が重要です。前者はレビューの焦点を絞り、後者は「これはなぜ直していないの？」という手戻りの質問を未然に防ぎます。小見出しごとに行数を指定しているのも同じ理由です。
「でっち上げないでください」という指示は、ChatGPTでPull Requestの説明を作る際に特に必要です。「パフォーマンスが〇％向上した」や関連Issue番号といった、それらしい内容が勝手に追加されがちで、そのまま投稿するとレビュアーが事実だと誤認してしまいます。代わりに「作成者への確認事項」という枠を設けることで、不明点を推測で埋めずにそこへ逃がすようにしています。
確認手順を変数として受け取り前方に配置したのは、レビュアーが最も気にするのが「これ実際に動かしてみた？」だからです。何をどう確認したかが1行あるだけで、レビュアーが同じ手順をなぞったり、漏れているテストケースを指摘したりしやすくなります。
用語が分からなければAha AIで: role-prompting, context-window
悪い例との比較
PRの説明書いて
(変更ファイル一覧を貼り付け)
ファイル名を1行ずつ説明しただけのリストが出力されます。読んでもdiffを見ているのと大差がなく、背景がわからないためレビュアーは結局チャットで質問する羽目になります。どこを重点的に見るべきかも不明なため、レビューが誤字脱字の指摘だけで終わったり、中身を見ずにApproveボタンだけが押されたりします。
バリエーション
緊急の修正をすばやく上げたいとき
障害対応など、先に出して後から説明するときに使います。緊急リリースでは「ロールバック方法」を明記しておくことが最も重要です。
プロンプトを見る
以下のメモをもとに、簡潔なプルリクエストの本文を作成してください。「1行要約、緊急である理由（2行）、確認手順、ロールバック方法」の順番でのみ記載し、それ以外の項目は含めないでください。確認手順は次のとおりです。{{テスト 方法}}
""" {{作業の内容}} """
レビュアーに相談・質問したいことがあるとき
設計に迷いがある状態でレビューを出すときに使います。本文に質問を明記しておくことで、レビューをその論点からスムーズに開始できます。
プロンプトを見る
以下の作業内容から、私が判断に迷っている選択肢を見つけ出し、レビュアーに相談するための質問3つに変換してください。各質問には、私が検討した選択肢と現在選んでいる理由を1行ずつ添えてください。答えを勝手に決めないでください。
""" {{作業の内容}} """
最終更新 2026-09-02 · 誤りがありますか？ 知らせる