AIツールの使い方
CodexでPRを作ったあとに確認すること｜マージ前チェックシート
PRができても、緑の印だけではマージを決められない。その止まり方は正常です。
Codexから「PRを作りました」と返ってきた。リンクを開くと英語のタブと緑の印が並び、急に手が止まる。
変更内容を全部理解してからでないと押してはいけない気がする。でも、どこまで見れば終わりなのか分からない。その不安は、知識不足よりも受け取り方が決まっていないことから生まれます。
PRはAIの完成報告ではありません。依頼した目的と実際の変更を、人が照合するための受取票です。
見る順番は、目的、変更のまとまり、チェックの中身、実際の差分。最後に「マージする」「修正を頼む」「保留する」のどれかを選びます。この順番を一枚の確認シートにすれば、コードを上から全て読む必要はありません。
Codexを使う前の作業場所や承認設定がまだ曖昧なら、先にCodexを使い始める前の5つの準備を確認してください。ここでは、PR URLを受け取った後だけに絞ります。
PRは完成品ではなく、変更を受け取るための伝票
通販の荷物が届いたとき、配達完了の通知だけを見て中身を使い始めることはありません。注文した品か、数は合っているか、壊れていないかを見るはずです。
PRも同じです。Codexが作業を終えたことと、依頼どおりの変更であることは別の確認になります。
最初に目的を一文へ戻す
画面を細かく見る前に、今回の依頼を一文で書きます。
判断基準: 「何を変え、何を変えない依頼だったか」を一文で言える状態にする。
たとえば「記事の見出しを5つへ整理し、予約ボタンや料金表示は変えない」です。ここで対象外まで書くと、余計な変更を見つけやすくなります。
次にPRのタイトルと説明を読み、依頼の目的、変更したファイル、実行した確認が書かれているかを見ます。説明が「対応しました」だけなら、マージ判断に必要な材料が足りません。
Codexへ、次のように聞き直せます。
このPRについて、依頼の目的、変更したファイル、変更していない範囲、
実行した検証、未確認の点を日本語で整理してください。
追加の編集はしないでください。
説明を整えてもらうことは、承認を任せることではありません。AIに荷物の明細を書かせ、人が注文内容と照合する作業です。
ConversationからFiles changedまで、4つのタブを順に見る
GitHubのPRには、主に Conversation、Commits、Checks、Files changed があります。GitHub公式のPR説明でも、会話、コミット、チェック、変更ファイルを分けて確認できる構造が示されています。
初心者は、次の順番で十分です。
| 順番 | 見る場所 | 確認すること |
|---|---|---|
| 1 | Conversation | 目的、説明、レビューコメント、未解決の指摘 |
| 2 | Commits | 変更が何回に分かれ、知らない作業が混ざっていないか |
| 3 | Checks | どの検証が実行され、失敗やスキップがないか |
| 4 | Files changed | どのファイルの、どの行が変わったか |
緑の印は「何を検査したか」とセットで見る
Checksが緑でも、それだけで依頼どおりとは限りません。テストは、書かれている検査項目だけを確かめます。文章の意味、料金の正しさ、リンク先、スマホでの見え方などが検査対象に入っていなければ、緑でも未確認です。
GitHub公式のstatus checks説明には、スキップされたワークフローが成功扱いになり、マージを止めない場合があることも書かれています。
そこで、チェック名を一つずつ開きます。
- buildなら、サイトを組み立てられたか
- typecheckなら、型の矛盾がないか
- 画像検査なら、画像数や形式を見たか
- 表示確認なら、どの画面幅とURLを見たか
緑色を確認するのではなく、今回の変更に必要な検査が実行されたかを見る。 これがChecksの読み方です。
Files changedは、目的と危険箇所から絞って見る
Files changedを開くと、赤と緑の行が並びます。赤は削られた側、緑は追加された側です。
全行をプログラマーと同じ深さで理解しようとすると、確認が止まります。先に見る範囲を3つへ絞ります。
1. 依頼したファイルだけか
記事1本の修正なのに、料金設定、ログイン、データベース、環境設定まで変わっていたら保留です。ファイル名の意味が分からない場合は、Codexへ「各ファイルが何を担当し、今回なぜ変更したか」を説明させます。
2. 読者や利用者が見る内容は合っているか
文章、数値、リンク、ボタン名、画像は人が読みます。ここはテストが通っても意味を取り違える場所です。
GitHub公式の自己レビュー手順でも、Files changedで提案した変更を見直し、バグやエラー処理の不足、アクセシビリティなどを確認する流れが案内されています。
記事なら、次を実際に開きます。
- タイトルと冒頭が同じ悩みに答えているか
- 数字や固有名詞に根拠があるか
- 内部リンクが別の記事へつながるか
- スマホで表や画像が切れていないか
AIの文章を確かめる基本は、AIの答えをうのみにしない確認方法にもまとめています。
3. 外へ影響する変更が混ざっていないか
公開、メール送信、課金、権限、秘密情報、データ削除に触れる差分は、内容が小さく見えても別枠で止めます。.env、token、passwordのような名前があれば、値をコピーせずに作業を止めて確認します。
注意: 分からない差分を「たぶん設定用」と決めつけない。役割、必要性、戻し方を説明できるまで保留にする。
CodexにはPRレビュー機能もあります。OpenAI Docsでは、CodexがPR差分とリポジトリの指示を使って重要な問題をレビューできると説明されています。一方で、同じ公式文書は、レビュー規則がテスト、ブランチ保護、必要な承認の代わりにはならないとも明記しています。
AIレビューは二人目の赤ペン役。最終の受け取りを代行する印鑑ではありません。
保存用。PR受入確認シートを1枚埋める
次のシートをPRのコメント用メモや自分のノートへ貼り、空欄を埋めます。チェック数を増やすより、判断理由を一行で残すことが目的です。
【今回の目的】
[何を変える依頼だったか]
【変えない範囲】
[料金、公開設定、別ページなど]
【Conversation】
[目的・変更内容・未確認点が説明されている / 不足あり]
【Commits】
[知らない作業が混ざっていない / 確認が必要]
【Checks】
[実行された検証名]
[失敗・スキップ・未実行]
【Files changed】
[依頼範囲内 / 範囲外のファイルあり]
[文章・数字・リンク・秘密情報の確認結果]
【反映後に見るもの】
[URL、画面、操作を一つ]
【最終判断】
[マージ / 修正依頼 / 保留]
[理由を一行]
たとえば記事修正なら、「反映後に記事URLをスマホ幅で開き、タイトル、画像、リンクを確認する」と書けます。コード修正なら、「対象の操作を練習環境で1回行い、元の機能も動くか見る」です。
PRを作る前に止める操作を決める考え方は、Codex Automationの承認境界とつながります。この記事のシートは、その境界へ着いた後の受け取り用です。
マージ・修正・保留を、3つの出口から選ぶ
確認が終わったら、良いか悪いかの二択にしません。出口を3つに分けると、分からないままマージする必要がなくなります。
| 判断 | 選ぶ状態 | 次にすること |
|---|---|---|
| マージ | 目的と差分が一致し、必要な検証と反映後確認が決まった | マージ後に決めたURL・画面・操作を確認する |
| 修正依頼 | 誤り、依頼外の変更、検証不足が具体的に分かった | 場所、問題、期待する状態を一件ずつ返す |
| 保留 | 差分の意味、影響、戻し方が説明できない | 追加説明か詳しい人のレビューを待つ |
文書1行の修正と、ログインや決済に関わる変更では、確認の深さが違います。見る順番は同じでも、後者には詳しいレビューや追加テストを置きます。
修正を頼むときは「直してください」だけにしません。
Files changedの[ファイル名・箇所]について確認してください。
今回の依頼は[目的]で、[変えない範囲]は変更しない前提でした。
[現在の問題]を、[期待する状態]へ直してください。
修正後は[検証名]を実行し、結果と未確認点を報告してください。
保留も失敗ではありません。判断材料が足りないと分かった状態です。
最初の10分では、練習用PRを一つ開き、確認シートの「今回の目的」「変えない範囲」「Checks」だけを埋めます。三つが書けなければマージせず、Codexへ不足した説明を求める。PRを受け取る仕事は、そこから始まります。