Pull Requestの書き方 2026年春のAIコーディング対応バージョン
2026/3ごろに社内projectに書いたものを持ってきた
前提
レビュアーは、AIと実装者の間で何が相談されたのか見えません
見えたとしても、読みきれません
これをどうにかする必要がありますshokai.icon
社内規定ではないが、まあ普通に考えてそうだよなという私のやり方を書きます
紹介しているAgent Skillは、大抵のAIコーディングエージェントで動くはずです
人間にコードレビューを求める前にやるべき2つの事
1. codex-consultationをインストールして、Claude Code.iconに「このブランチにbugがないか、Codexと相談しながら確認してください」を依頼する 重いプルリクでは「全力で相談してください」と指示すると超高精度にbug検出できます
bugがボロボロ出てくるので試してみてくださいshokai.icon
私の考える「時間が無限にある超賢い人間2人が共同作業する時の理想のプロトコル」、批判的思考の連鎖が叩き込まれています 人間にレビュー依頼する前にコードの品質上げましょう、という事です
人間にコードレビューを求めるのは、最低限上の2つをクリアしてからにするべきですshokai.icon
bugのないコード
コードとの齟齬のないpull request概要欄
ができます。人間がレビューしやすい。
これらはAIで$1以下でセルフサービスでサッとやれる。もはや他人にやらせる事ではないのだ
さらに効率的に・厳密にやりたい場合
bug検出が重箱の隅をつつきすぎる
やる事、やらない事、検討した結果ダメだった事、検討方法、色々試して発見した事実のメモをテキストファイルで生成できます
AIとの対話ログに埋もれがちだった話に絞って取り出せます
別のAIに引き継ぎできる
shokai.icon → Claude Code.icon → Codex CLI.iconという流れでCodex CLI.iconが好き放題bug報告してきても、Claude Code.iconがうまく弁護してくれます
sanity-reviewをインストールして、レビュー報告書を作成してGithubにコメントとして貼ってみてくださいshokai.icon 私の思考プロセスを解体して作ったAgent Skillです
「なんかbugの匂いがするな」という感覚って、結局1つ1つの要素の質と、要素間の繋がりをチェックしてるんだよね
フルセットのAIレビューが自動で行われます
pull request概要欄の形式がまともである
pull request概要欄とコードに齟齬がない
コードにbugがない
やらないと決めた事の1つ1つがまともである
やらないと決めた事とコードや概要欄に齟齬がない
重箱の隅をつつくようなbugのうち、対応しなければならないものを、やらないと決めた事でフィルタ
結論：正気である or 正気ではない
実装者自身がやりましょう
報告書を自分で読んで、直せる所は直しましょう
レビュアーが助かります
これも$1前後で完了します