Codexの変更差分をGitHubで見るには

差分が大きすぎて読めない時

変更が数十ファイルに及ぶと、丁寧に読むこと自体が現実的でなくなります。その場合は読み方を変えます。

• まずファイル一覧だけ見る：中身を読む前に、想定外のファイルが混ざっていないかを確認します。ここで異常が見つかれば、中身を読む必要はありません。
• 設定ファイルを優先して読む：本文の変更より、設定の変更の方が影響が広く、間違いの代償も大きくなります。
• 削除行だけ先に通して見る：追加は依頼と照らせば分かりますが、削除は元を知らないと気づけません。
• 次からは作業を分割する：差分が読めない規模の依頼は、そもそも分けるべきだったというサインです。

最後の項目が本質的な対策です。「確認できる量」が依頼できる量の上限だと考えてください。作れる量ではなく、確かめられる量が基準になります。

差分を読む順番｜全行読まない前提で、何を必ず見るか

AIの変更は差分が大きくなりがちで、「全行読む」は現実には続きません。続かない精読より、順番を決めた抜き取りのほうが事故を防ぎます。実際に使っている順番です。

1. 1. 中身より先に、ファイル一覧だけを見る。「触るはずのないファイルが混ざっていないか」はここで分かります。1行も読まずに検出できる最重要チェックです。
2. 2. 想定外のファイルがあれば、そこで止める。中身の良し悪しを検討する前に、なぜ触ったのかを確認します。理由が説明できない変更は差し戻します。
3. 3. 意図したファイルは「削除が混ざっていないか」を先に見る。追加だけのはずの作業に削除行が混ざっているのが、事故の典型です。
4. 4. 数字・URL・パス・日付だけは1文字単位で精読する。文章の言い回しと違い、ここの1文字ミスはそのまま実害になります。精読の対象をここに絞ります。
5. 5. 同じ形の変更が大量にある時は、先頭の数件と途中の数件を抜き取る。一括置換系は全件が同じ形のはずなので、抜き取りで形が揃っていれば残りも信用できます。揃っていなければ全件見ます。

意図しない変更の典型と、気づき方

差分レビューで実際に引っかかるのは、凝ったバグより次のような機械的な混入です。それぞれ「どこで気づけるか」が決まっています。

共通するのは、ほとんどがファイル一覧と行数の形だけで検出できることです。差分レビューの負担が重いと感じたら、読み方をこの型に変えるだけで、かかる時間は減り、見落としも減ります。

やってはいけないこと

• GitHub上の重い操作は、人間が範囲と結果を確認してから判断する。
• main直push、勝手なmerge、本番deployを軽作業扱いしない。
• APIキー、トークン、秘密鍵、GitHub Secrets、認証情報を本文に出さない。
• DB、cron、.htaccess、AdSense、Search Console確認タグ、robots.txt、ads.txtを触らせない。
• 成果や検索順位、安全性を約束する表現を書かない。