レビュー 中級 約5分

指摘を修正計画に変えるプロンプト

反射で直さず、意図と検証まで持っていく

Use cases
4場面
Variations
3通り
Sources
4件
Ready to use

今日のプロンプト

あなたは、レビュー指摘を実行可能な修正計画に変える補助者です。

次のレビュー指摘を、ただ修正案に変えるのではなく、指摘の意図、影響範囲、確認方法まで分けて整理してください。
不明点がある場合は推測で埋めず、「確認が必要なこと」に分けてください。

対象:
<レビュー対象の文章、コード、資料、PR概要など>

レビュー指摘:
<受け取った指摘を貼る>

前提:
- 目的: <この作業で達成したいこと>
- 守りたい意図: <残したい主張、仕様、制約>
- 変更してよい範囲: <文言、構成、実装、テストなど>
- 変更してはいけない範囲: <仕様、公開済みAPI、トーンなど>
- 利用できる根拠: <仕様書、Issue、公式ドキュメントなど>

出力形式:
1. 指摘の要約
2. 指摘の背景にある意図
3. 修正が必要な箇所
4. 影響範囲
5. 修正案
6. 検証方法
7. 人間に確認したいこと

制約:
- 指摘を鵜呑みにせず、前提と衝突する場合はその理由を書く
- 大きな変更が必要な場合は、小さな順番に分ける
- 確認できないことは断定しない
- 最後に「最初に着手する1点」を示す

使いどころ

レビュー指摘をもらった直後は、早く直したくなります。特にAIに貼ると、修正案がすぐ返ってくるので、手戻りを減らせそうに見えます。 ただ、急いで直した結果、「指摘された箇所は変わったのに、何を守るための変更だったのか」が残らないことがあります。文章添削、コードレビュー、コメント対応に共通する話です。直したという事実だけが残り、意図や検証方法が抜けると、次のレビューでまた似たところに引っかかります。 ここで分けたいのは、指摘を処理することと、指摘の意図を理解することです。AIに任せたいのは、反射的な修正ではなく、指摘の背景、変更してよい範囲、影響範囲、確認方法を並べ直すところです。 OpenAIのAI-native engineering team向けガイドでは、AIコードレビューは欠陥を防ぐ助けになる一方、最終的にコードを理解し、出荷責任を持つのはエンジニア側だと説明されています。GPT-5.6の prompting guidance では、成果物、制約、根拠、完了条件、検証条件をプロンプトに残す考え方が示されています。Anthropicの prompting best practices は、欲しい出力形式や手順を明確にすること、必要な文脈を渡すことを勧めています。 今日のプロンプトは、レビュー指摘を「直す作業」へ急がせるのではなく、「修正計画」へ変えるための型です。指摘を要約し、意図を読み、影響範囲と検証方法に落とす。そこまで分けてから手を動かすと、AIの速さを使いながら、人間側の判断も残しやすくなります。

  • コードレビュー対応
  • 文章添削の反映
  • 資料レビュー後の修正計画
  • 学習時のフィードバック整理

この形にした理由

  • レビュー指摘を、要約、意図、修正箇所、影響範囲、検証方法に分けるため、AIの回答をそのまま採用する状態を避けやすくなります。
  • 守りたい意図と変更してよい範囲を先に渡すので、読みやすさや修正しやすさのために仕様、主張、トーンが勝手に変わるリスクを下げられます。
  • 最後に人間へ確認したいことと最初の1点を出させるため、レビュー対応を大きな不安のまま抱えず、検証可能な小さな作業へ戻せます。

公式ガイドと照らしたメモ

OpenAI

レビューを任せても、判断と検証は人間に残す設計

OpenAIのAI-native engineering team向けガイドは、AIコードレビューが欠陥予防に役立つ一方、最終的な理解と出荷責任はエンジニアに残ると整理しています。GPT-5.6のprompting guidanceとも相性がよく、成果物、制約、根拠、完了条件、検証条件を明示する型にできます。

Anthropic

手順と出力形式を明確にして、指摘の読み替えを減らす設計

Anthropicのprompting best practicesは、明確な指示、必要な文脈、順序がある場合の番号付き手順、出力形式の指定を勧めています。Skill authoring best practicesのcode review process例とも近く、レビュー作業では自由度を残しつつ、確認観点を構造化するのが向いています。

場面に合わせた直し方

コードレビュー

修正案には、変更ファイル、想定される副作用、実行すべきテストまたは確認コマンドを含めてください。

文章添削

直す前に、残す主張、変えてよい文体、変えてはいけない温度感を分けてください。

学習

指摘を、理解不足、手順ミス、判断ミス、次回のチェック項目に分類してください。責める表現ではなく、次の行動に変えてください。

使う前に見ること

  • レビュー指摘が常に正しいとは限りません。仕様、要件、既存ルールと衝突する場合は、AIに反論材料ではなく確認事項として整理させます。
  • 社外サービスに機密コード、未公開資料、個人情報を貼る場合は、利用ルールと入力範囲を先に確認します。安全に扱えない情報は要約や抽象化に留めます。
  • 検証方法が書けない修正案は、まだ計画として弱い状態です。コードならテスト、文章なら読み手と目的、資料ならレビュー観点まで戻して確認します。

参考資料

Loading...