報告と差分は、別のものです
「テストを追加し、エラー処理を改善しました」という報告は、何が変わったかを説明していません。実際に変わったのは、行です。
レビューは差分から始めます。報告は、差分を読む順番を決めるための地図として使います。
説明ではなく、変わった箇所を見る
レベル 1・実践レビューと安全確認約90分
先に読む回：判定基準から、テストを起こす
この回でできるようになること
- AIの説明ではなく、実際に変わった箇所を順に見てレビューできる
- 指摘に、場所・影響・再現手順・直し方を添えられる
おさえておくこと
見る順番
- 消えたもの
- 削除された行と、消えたテスト。いちばん見落とされます。
- 触っていないはずの場所
- 依頼していない範囲の変更。整形やリネームが混ざっていないか。
- 新しく増えた依存
- 追加されたライブラリと、その理由。
- 中身
- ロジックそのもの。
最後の1つだけを見るレビューが、いちばんよくある形です。
指摘には根拠を付けます
「ここは良くないと思います」は、受け取った側が判断できません。次の4つを添えてください。
- 場所
- ファイルと行。
- 何が起きるか
- この条件のとき、こうなる。
- 再現手順
- その状況をどう作るか。
- 直し方
- こうすれば直る、という案。
この4つが書けない指摘は、まだ思いつきの段階です。書けるまで調べるか、指摘を取り下げます。
ここまでで分からないところがあれば、この回の本文だけを使って答えてもらえます（任意・自分のAPIキーが必要です）。
この回では扱わないこと
- コードスタイルの議論
- チームのレビュー体制づくり
やってみる
自分のリポジトリで約75分
AIが書いた変更を、順番に見る
AIに書かせた変更を1つ選び、消えたもの・範囲外・依存・中身の順にレビューします。指摘には4つの要素を必ず添えます。
やること
- AIに書かせた変更を1つ選びます。まだ取り込んでいないものにしてください。
- 先に報告文を読み、どこを見るかの見当をつけます。
- 削除された行と消えたテストを確認します。
- 依頼していない範囲の変更がないか確認します。
- 増えた依存があれば、必要かどうかを判断します。
- 中身を読み、見つけた問題に場所・何が起きるか・再現手順・直し方を添えます。
- 4つを書けない指摘は、調べ直すか取り下げます。
できあがるもの：4つの観点それぞれの確認結果と、根拠つきの指摘一覧
できたかどうかの確かめ方
作ったものを点検する自分で採点する
見る順番を守ったか
レビューの記録を、次の観点で点検してください。
4つの観点
- まだ
- 中身だけを読んでいる。
- できた
- 消えたもの・範囲外・依存・中身の4つを、それぞれ確認した記録がある。
- よくできた
- 報告文と実際の差分が食い違っていた箇所を指摘している。
観点の表で採点する自分で採点する
その指摘は、受け取った側が動けるか
書いた指摘を、「受け取った側がそのまま直せるか」という観点で採点してください。
4要素がそろっているか
- まだ
- 感想や好みにとどまっている指摘がある。
- できた
- すべての指摘に、場所・何が起きるか・再現手順・直し方がある。
- よくできた
- 4つを書けなかった指摘を取り下げ、その判断を記録している。
この回の情報の出どころ
この回の記録
書いた内容はこのブラウザの中だけに残ります。送信はしません。 成果物そのものではなく、どこにあるか（ファイルの場所、ブランチ名など）を書いてください。 鍵やパスワードは書かないでください。
確かめた結果
見る順番を守ったか
その指摘は、受け取った側が動けるか
置き場所を書き、すべての確認を「できた」以上にすると、記録つきの完了になります。
AIに見てもらう（任意）
使わなくても、すべての回は完了できます作ったものを、この回の観点表に照らして見てもらえます。返ってくるのは助言であって、 合否ではありません。完了にするかどうかを決めるのは、いつでもあなたです。 自分のAPIキーを使うため、料金はご自身のアカウントに請求されます。
先に、上の「この回の記録」ですべての確認に自分で評価を付けてください。 モデルの評価を先に見ると、自分の判断がそれに引きずられます。
キーはこの実行にのみ使われ、保存もログ出力もしません。ブラウザにも残らないため、ページを離れると再入力が必要です。
APIキーを発行する