AI が変更したコードを受け入れる前に確認する方法
Mono Code で変更範囲、差分、ステージ済み内容、テスト結果、未確認事項を点検する手順と、レビュー用テンプレートを紹介します。
エージェントの要約だけでなく、リポジトリに存在するコードを確認してください。説得力のある説明でも、修正が不完全だったり、テストが未実行だったり、無関係な編集が含まれていたりします。結果を受け入れる前に、求めた動作、実際の変更、検証の証拠を分けます。
Mono Code では、プロジェクトのファイルを開き、コーディングエージェントと作業し、エディターの中で Git の変更を確認できます。この記事は、完了した小さな変更のレビューについて説明します。接続の方法はリモートコーディングのガイドを参照してください。リポジトリとコマンドは、いつもあなた自身のパソコン（ホスト）にあります。Mono はまだ公開前ですが、ウェイトリストに登録できます。
1. 受け入れ条件を書き直す
架空のタスク入力フォームが、空白だけのタイトルを受け付ける例を考えます。依頼した修正は、通常のタイトルを維持しながらその入力を拒否することです。パッチを見る前に、満たすべき条件を書きます。
- 空のタイトルと空白だけのタイトルを送信できない。
- 通常のタイトルは正常に送信できる。
- 利用者に分かりやすい検証メッセージが表示される。
- フォームのほかの動作は合意した範囲内に保たれる。
この短い一覧を差分の横に置きます。エージェントの説明に同意するだけでなく、要求に照らして判断できます。元の依頼が曖昧なら、実装範囲を広げて受け入れる前に、期待する動作を決めてください。
2. リポジトリの状態を確かめる
ホスト、プロジェクトのフォルダー、ブランチを確認します。変更ファイル一覧を、エージェントが作業する前に記録した状態と比較します。同じファイルにあるというだけで、以前からの利用者の編集までエージェントの成果にはなりません。
対象ホストのターミナルでは、次の読み取り専用コマンドが役立ちます。
git status --short
git diff --stat
git diff -- path/to/file
git diff --cached -- path/to/fileパスは実際のものに置き換えます。通常の git diff は未ステージの変更、--cached はステージ済み内容とコミットとの差分を表示します。未追跡ファイルは別途確認します。Git diff の文書に比較の説明があります。作業ツリーがきれいでも、エージェントが既にコミットしたかどうかは分かりません。その場合は関連履歴も確認します。
3. パッチと周囲のコードを読む
Mono のエディターでは、行番号の横に追加・変更された行の印が付き、印をタップするとその部分の差分が開きます。一つの変更を見るには便利ですが、すべての変更をレビューした証明にはなりません。印がない、または古いままでも、ファイルが変わっていないとは限りません。
タイトルの例では、検証条件を探し、その後の処理をたどります。正規化した値を調べているか、エラーが見えるか、送信を止めるかを確認します。追加条件だけを切り離さず、呼び出し元を含む周囲のコードを見てください。
新規ファイル、削除されたコード、依存関係、関係のない整形も確認します。短い説明だけで、大量の説明されていない差分を正当化することはできません。行が省略されたり変更が横に広すぎたりするなら、ホストや大きな画面で読みます。
4. テストを期待する動作に対応させる
実際に実行したコマンド、結果、省略した検証を確認します。「テストは通るはず」は予測であり、記録された結果ではありません。一式が成功していても、報告された不具合に対応するケースが必要です。
| ケース | 期待する観察結果 |
|---|---|
| 空のタイトル | 意図した表示とともに送信が止まる |
| 空白のみ | 項目を作成せず、同じように拒否する |
| 通常のタイトル | 引き続き送信できる |
| 変更対象外の既存動作 | 関連する既存の確認が成功する |
画面のフィードバックには手動確認が適し、検証ルールの保護には自動回帰テストが役立ちます。実装をなぞるだけでなく、動作を示す証拠を選びます。環境の制約で試せない場合は明記し、不足分をどこで確認するか決めてください。
5. ほかの作業を失わずに指摘を解決する
「空白のタイトルは拒否されるが、エラー表示が出ない」「この検証修正で依存関係ファイルを変えた理由を説明して」のように具体的に伝えます。「やり直して」だけでなく、動作とファイルを示してください。
別の作業が存在する状態で、小さな不要変更を除くために一括リセットや復元を行うのは避けます。対象を絞った修正を依頼し、新しい差分を見ます。修正後は影響する検証を再実行します。以前の成功は、その後の編集を検証しません。
コマンドの許可とコードの受け入れは別の判断です。テスト実行の承認は、コミット、マージ、デプロイの承認ではありません。操作自体は権限確認ガイドを参考にしてください。
6. レビューできる引き継ぎを残す
短いメモに結論を記録します。
求めた動作：空白のタスクタイトルを拒否する。
確認したファイル：実際のパスを列挙する。
証拠：コマンド、結果、関連する手動確認。
未解決の質問：まだ検証していないこと。
次の判断：変更を受け入れる、修正を求める、または保留する。コミットとリリースは明示的に決めます。会話を残すなら Markdown に書き出せますが、実際のプロジェクトファイルも保存してください。会話は議論を記録し、リポジトリと検証結果は何が変わったかを示します。
