AIが「修正しました」と言っていても、何が変わったか分からないまま本番へ反映するのは不安です。GitHubのプルリクエストでは、元のコードと提案されたコードの差分を確認できます。
確認するのは、依頼した変更、実際の差分、動作の三つが一致しているかです。この記事はAIを使ってサイトや小さなアプリを直す人向けに、PRをマージする前の点検を整理します。
対象ブランチと変更ファイルを開く
- GitHubで対象のリポジトリを開き、Pull requestsから今回のPRを選ぶ。
- 取り込み先のブランチが、作業を依頼した対象と合っているか確認する。
- Files changedを開く。比較しにくければ差分の表示を左右に並べるSplitへ切り替える。
PRはコード変更の提案です。マージすると取り込み先へ変更が入りますが、本番公開まで自動で進むかはプロジェクトの設定によります。
依頼が「スマホの検索表示」なら、PCのレイアウトや別の機能まで変更されていないかを点検します。
広い変更が必要な場合もありますが、その理由が説明できることが大切です。「まとめて整理しました」としか分からない変更は、今回必要な修正と追加の整理を分けるよう依頼できます。
追加した行と削除した行を読む
差分を見てもコードの意味が分からないときは、すぐに良し悪しを決める必要はありません。まず、ファイル名と行番号を添えて「今回の依頼に必要な変更か」「消すと何が変わるか」を確認します。説明を読んでも判断できない部分は、未確認として残してください。
新しく書かれた行だけではなく、消された行も確認します。削除された条件分岐、スタイル、エラー処理が、以前の不具合への対処だった可能性もあります。大きな差分はファイルごとに読み、分からない箇所を番号や周辺コードで特定します。
このPRで、依頼したスマホの検索修正に直接関係するファイルと行を説明してください。削除した条件の役割、PC表示への影響、元へ戻す方法を分けて答えてください。動作確認していない項目は未確認と書いてください。
これは本記事のために作った確認用の指示です。AIの回答は理解の補助に使い、差分そのものと照合します。GitHubのAI要約やレビューも、すべての不具合を検出した保証ではありません。
読み終えたファイルはViewedにチェックすると進み具合を追えます。ただし、これは読んだ印であり、動作確認やマージの承認ではありません。後からそのファイルが変更されると印が外れるので、変更部分を読み直します。
表示変更は操作順を含めてテストする
| 確認すること | 試す例 |
|---|---|
| 初期表示 | PC・スマホのページを開く |
| 単独の操作 | 検索を開き、入力し、閉じる |
| 連続する操作 | サイドバーから検索へ切り替える |
| スクロール | パネル内と背景が意図通り動くか |
| 再表示 | 閉じて開き直しても状態が残らないか |
一度ボタンを押して開いた画面だけでは、重なりや状態の不整合を見逃します。読者が実際に行う順序で試すことが大切です。変更していないはずのPC画面も、共通のスタイルへ触れた場合は確認します。
チェックが緑でも、手動確認は必要
PRのChecksで、ビルドや自動テストの結果を確認します。成功している場合も、そのチェックが何を対象としているか読みます。コードの形式だけを確認するチェックなら、スマホの見た目まで検証したことにはなりません。
失敗しているチェックを、理由を理解せず無視しないでください。逆に自動テストがないプロジェクトでは、実際に試したページと操作を記録して、確認範囲を明確にします。「全部問題なし」と広く書くより、確認したことを具体的に残します。
確認したコードの版も残す
動作確認の記録には、PR番号、確認したコミットの識別子（SHA）、プレビューURL、試した操作を一緒に残します。プレビューの対象がそのコミットか分からない場合は、公開先のデプロイ履歴と照合してください。修正を追加した後は、古いプレビューでの成功をそのまま使わず、新しい版で問題の操作を試します。
分からない変更へコメントを残す
Files changedで該当行の横にあるコメントアイコンを選び、疑問を書きます。レビューとしてまとめる場合、保留中のコメントは送信前には自分にしか見えません。書いただけで相手へ届いたと思わず、レビューの送信まで確認してください。
スマホの検索欄を直す依頼でしたが、この行でPC側の幅指定も削除されています。PC表示を保つために、この削除が必要な理由と確認結果を教えてください。まだ確認していなければ、PC側の変更を外してください。
これは修正依頼の記入例です。「直っていない」だけでなく、依頼内容と差分の食い違いを示すと、次に直す範囲を絞れます。
マージ前の確認手順
- 依頼した変更を一文で書き、対象のPRとブランチを確認する。
- 変更ファイルと追加・削除の差分を読む。
- 関連しない変更や秘密情報が含まれていないか見る。
- 自動チェックとプレビューの実動作を確認する。
- 問題があれば修正を依頼し、新しい差分と動作を確認し直す。
- 取り込み後の確認と、問題時に戻す方法を準備する。
環境変数の値やAPIキーが差分へ入っていた場合は、そのままマージしません。設定名と秘密の値を区別し、必要な処理を行います。秘密情報をAIへの説明へ貼り付けることも避けてください。
運営者も「直った説明」と実画面の差を経験
運営者はGitHubやRailwayを自動化に使う一方、AIに頼んだサイトの表示が一向に直らなかった経験があります。指示を繰り返すだけでは、どの変更が効いたのか追いにくくなります。
一つの不具合に一つのPRで対応し、変更と確認結果を結び付けると、次の修正を具体的に依頼できます。PRの説明には「変更したファイル」と「試した操作」を並べて残しておくと、後で同じ問題が起きたときにも確かめ直せます。
迷ったときの追加確認
AIが変更理由を説明できない場合
分からない差分をそのまま取り込まず、対象のファイルと行を示して説明や変更の分割を依頼します。意図のない整理は別のPRへ分ける判断もできます。
取り込み後に不具合が見つかったら
どの変更と操作で問題が出るか記録します。元に戻す方法を確認し、修正を重ねる前に正常だった版と比較します。コードを戻しただけでは、データ更新や外部サービスへの操作まで戻らない場合があるため、PRで変更した範囲を先に確認しておきます。
AI開発で起こりやすい限界は、AIへ任せる作業と確認を残す作業で確認できます。
確認日：2026年10月8日。参考：GitHub・変更内容のレビュー、GitHub・CopilotでPRを確認。画面や利用条件は更新される場合があります。
当サイトはアフィリエイト広告を利用しています。
コメント