AIに実装を頼んだら、コードはできた。テストも通った。それでも、そのまま本番に出してよいかは別に確認が必要です。仕様を取り違えたまま、取り違えた仕様のテストを作ることも考えられるからです。
小さな開発チームなら、確認を「変更対象」「業務の期待結果」「機械で確かめること」「人が判断すること」に分けるところから始められます。この記事は、AIによる実装やレビューを利用する際の確認表です。特定のツールを導入すれば品質が保証される、という内容ではありません。
AIレビューを増やす前に、誰が何を見たかを残す
AI開発の実践記事を比較すると、レビュー量の増加に加え、対象の取り違えや判断の境界が論点になっています。LayerXの開発プロセスの記事には、意図と違うコードをAIが確認した失敗と、変更対象を確かめ直す過程が書かれています。
また、ZOZOのPR自動レビューの記事は、AIへの指示と機械的に強制する処理を分けています。本稿では両者の問題意識を参考に、少人数で使うレビュー記録を提案します。各社の自動承認の仕組みを移植する手順ではありません。
まず7項目を、PRの説明に貼る
| 確認項目 | 記録すること |
|---|---|
| 1. 対象 | リポジトリ、ブランチ、対象コミット、変更ファイル |
| 2. 目的 | どの利用者の、何の操作が、どう変わるか |
| 3. 影響 | 権限・課金・個人情報・既存データへの影響の有無 |
| 4. 自動確認 | 実行したチェック、対象環境、結果へのリンク |
| 5. 業務確認 | 成功時と失敗時の期待結果、実際の確認結果 |
| 6. 未確認 | 確認できなかった条件と、その理由 |
| 7. リリース判断 | 確認者、反映方法、問題が出た場合の戻し方 |
「テスト済み」の一言では、変更前の状態を見たのか、別の環境で試したのか、実際の送信まで確かめたのかが分かりません。対象と結果を一緒に残せば、追加修正が入った後も、どの確認をやり直すべきか判断できます。
問い合わせフォームなら、完了表示の先まで決める
たとえば「フォームを送信すると受付完了になる」という要件には、画面表示とデータの保存、通知の扱いが含まれます。以下は架空のフォームの受け入れ条件です。実際のシステムで合格した結果ではありません。
| 場面 | 期待する結果 | 主な確認先 |
|---|---|---|
| 必須項目が空 | 入力エラーになり、受付データは作られない | 画面と保存先 |
| 正しい内容を1回送信 | 受付IDが表示され、対応するデータが1件保存される | 画面とデータ |
| 同じ送信を繰り返す | 決めた重複処理の方針に従い、受付が意図せず増えない | 保存先と処理記録 |
| 通知先でエラー | 受付の状態と通知失敗を区別でき、再送方法が分かる | 処理記録と通知先 |
| 権限のない利用者が参照 | 他者の受付内容が表示されない | 権限を変えた操作 |
通知の送信APIが成功したことと、通知先で受け取ったことも別の確認です。受信まで確認できなければ、未確認として残します。自動テストに含めるか、検証用の通知先で人が確認するかを、運用に合わせて決めます。
CIは形式的に確認できることを担当する
型チェックや静的解析、単体テストを毎回同じ条件で実行するようにします。E2Eテストでは、重要な利用経路の結果を確認します。テストが実装の内部構造だけに依存すると、利用者が困る不具合を見落とすおそれがあります。
Playwrightの公式ガイドも、利用者に見える振る舞いを確認し、テストを互いに独立させる方針を示しています。テストケースはAIに大量生成させる前に、先ほどの期待結果と対応させてください。
チェックを実行していても、失敗したままマージできる設定なら、確認の抜けは残ります。GitHubの保護ブランチでは、必要なレビューやステータスチェックなどを条件にできます。利用できる設定はリポジトリの公開範囲や契約によって異なるため、実際の管理画面と公式情報を確認します。
AIの指摘は、根拠と再現条件を付けて扱う
AIが指摘したという理由だけで、仕様やコードを変更しないようにします。「どのファイルの、どの条件で、どんな結果になるのか」を確認し、必要なら小さな再現手順を作ります。誤った指摘を採用しなかった場合も、理由を一言残すと同じ議論の繰り返しを減らせます。
確認対象: <コミットID>
利用者の期待結果: <操作と結果を1文で>
自動チェック: <実行内容と結果のリンク>
実操作の確認: <環境・入力・観察した結果>
AIの指摘: <再現条件・根拠・対応／見送り理由>
未確認事項: <条件と残る影響>
反映・復旧: <実行者・手順・戻す条件>権限やデータを変える修正は、確認者を先に決める
データ削除、認証・権限、課金、外部への一括送信などは、同じ差分量でも影響が大きくなります。実装の後に判断者を探すと、レビューが止まりやすくなります。変更前に、何をもって反映可能とするか、誰が判断するかを決めます。
少人数のチームでは、全ての変更に同じ重さの手続きを用意する必要はありません。文言の修正と、権限条件の変更を分け、影響に応じて確認を厚くします。ただし「AIが安全と言った」だけで、人が確認すべき範囲を省く基準にはしないでください。
確認表は、次の1件で使える大きさにする
まずは1つのPRで、7項目を記入し、他の担当者が結果を追えるか確かめます。欄を増やすより、未確認のまま完了にしている工程を見つけることが先です。実装・レビュー・リリースのどこが詰まっているかも、記録がそろってから比較できます。
参考資料・確認範囲
LayerX：AI開発での人の役割 — 対象取り違えとレビュー・QAの実践。報告された成果は同社の条件に依存します。
ZOZO：PR自動レビューの設計 — 指示と機械的制御を分ける実践。記事は効果測定そのものを扱っていません。
Playwright：Best Practices — 利用者に見える振る舞いとテストの独立性。2026年11月2日確認。
GitHub：About protected branches — レビュー・ステータスチェックの必須化に関する公式資料。2026年11月2日確認。
コメント