AIにコード修正を任せる道具は増えていますが、使うほど「どこを見て監督するか」のほうが重要だと感じます。Codexを触ったときも、最初に気になったのは実装力そのものより、私が何を確認すれば安心して進められるのかでした。
最初の私は、出てきたコードの見た目や説明のわかりやすさを中心に見ていました。もちろんそれも大事です。ただ、きれいなコードに見えても、対象範囲を読み違えていたり、守るべき条件を落としていたりすると、あとから直すのが大変になります。
AIコーディングで怖いのは、間違いが起きることだけではなく、何を根拠にどこを変えたのかが見えないまま進むことです。今回は、Codexのようなエージェント的なコーディングツールに修正を任せるとき、私が見るようにしている監督ポイントを整理します。
- AIにコード修正を任せるときは、実装力より先に対象範囲と変更理由を確認する必要があります。
- 差分、影響範囲、検証、権限の4点を見るだけでも、任せ方の怖さはかなり下がります。
- AIは手を動かしてくれますが、最後に採用するかどうかを決める監督役は人間側に残ります。
まず見るのは、コードの上手さより対象範囲を読み違えていないか
AIが出したコードがきれいでも、見ているファイルや直している問題がずれていたら、その修正は採用しにくいです。私は最初に、どのファイルを読んだのか、どの変更を加えたのか、頼んだ範囲からはみ出していないかを見るようにしています。
たとえば表示崩れを直したいだけなのに、関連しないデザイン全体まで整え始める。小さなエラー修正のはずなのに、関数名や構造まで変わっている。こういう変更は、見た目には改善に見えても、実務では確認範囲が一気に広がります。
AIエージェント全体の整理は、こちらを先に読むとつながりやすいです。
そのうえでCodexを見ると、会話で答えをもらう感覚より、作業の対象と境界線を確認する感覚がかなり強くなります。
私にとって最初のレビューは、「この修正はうまいか」ではなく「この修正は頼んだ問題に対してまっすぐ効いているか」を見ることでした。ここが合っていると、その後の差分確認やテストも落ち着いて進められます。
修正案を出す前に、守る条件を共有しているかを確認する
AIにコード修正を頼むとき、何を正解とするかを共有していないと、もっともらしい改善が返ってきやすいです。コードとしては自然でも、プロジェクトの事情には合っていない。こういうズレは、あとから人間が拾うことになります。
私が先に渡すようにしているのは、守るべき制約、変更してよい範囲、完了条件の3つです。既存の命名を変えない、UIの見た目を変えない、公開済みの挙動を壊さない、特定のファイルだけ触る、テストが通るところまで確認する。こうした条件を最初に出すと、レビューの軸も揃います。
- 守るべき制約を先に書く
- 変更してよい範囲と触らない範囲を分ける
- 最後に何を確認すれば完了かを決める
Claude Code側の詰まり方と見比べると、監督ポイントの共通部分も見えてきます。
道具が違っても、AIに何をさせるかより先に、人間側がどこを守るかを持っていることが効いていました。
差分を見るときは、変更量より理由と影響範囲を追う
Codexの差分を見るとき、私は行数の多さだけでは判断しないようにしています。少ない変更でも影響が大きいことはありますし、多い変更でも単純な整理だけなら怖さが小さいこともあります。大事なのは、その変更がなぜ必要で、どこまで影響するのかです。
たとえば関数の中身を少し変えただけでも、その関数が複数画面で使われていれば確認範囲は広がります。逆に、使われていない文言やコメントの整理なら、影響は比較的限定されます。AIが「軽微な修正です」と言っていても、自分の目で影響範囲を見直すことは外せません。
ここで役に立つのは、変更理由を言葉にしてもらうことです。「このエラーを避けるために条件分岐を追加した」「この表示崩れを直すために余白指定を変えた」のように、理由と変更箇所がつながっていると確認しやすくなります。
理由が説明できない差分や、頼んでいない改善が混ざっている差分は、その場で止めたほうが安全です。一度に気持ちよく直って見えるほど、後から「どこが原因だったのか」を追いにくくなるからです。
説明がきれいでも、検証が薄いときはそのまま進めない
Codex系のツールは、自然な説明まで返してくれるので安心しやすいです。何を直したか、なぜ直したかが文章で返ってくると、つい納得しそうになります。でも、説明がきれいなことと、実際に確認できていることは別です。
私は、理由の説明よりも先に「何を実行して確かめたか」を見るようにしています。テストを走らせたのか、ビルドを確認したのか、画面表示を確認したのか、実行できなかったならなぜできなかったのか。ここがないと、採用判断がかなり弱くなります。
もちろん、環境の都合でテストやビルドを実行できないこともあります。その場合は、できなかったことを隠さずに書いてもらうほうが助かります。「未確認だけれど、おそらく大丈夫」という状態を、確認済みのように扱うのがいちばん危ないからです。
私の中では、AIレビューの完了条件は「説明が自然」ではなく、「確認できたことと未確認のことが分かれている」ことです。ここが分かれていれば、次に自分が何を見るべきかもはっきりします。
権限が強い作業ほど、AIに任せる前に止める場所を決める
コード修正の怖さは、変更内容だけでは決まりません。どこに書き込めるのか、何を削除できるのか、公開やデプロイに近い操作まで届くのかでも変わります。AIが動ける範囲が広いほど、便利さとリスクは一緒に大きくなります。
特に、削除、置換、公開設定、依存関係の更新のような作業は、実行前に人間が止められる形にしたいです。AIに提案までは任せても、実行は確認後にする。大きな変更は一括ではなく、小さな単位で区切る。これだけでも、失敗したときに戻しやすくなります。
私はここを決めないまま任せると、作業中にずっと不安が残ります。逆に「ここまでは読んでよい」「ここまでは修正してよい」「ここから先は確認してから」と分けると、AIの作業を落ち着いて見られます。
AIに任せる範囲を狭くすることは、AIを信頼していないという意味ではありません。むしろ、信頼して使うために、戻せる範囲で進めるということです。
最後は自分で書く量より、確認点を握る力を育てたい
Codexを触っていて感じたのは、AIコーディングで人間の役割がなくなるわけではなく、見る場所が変わるということでした。全部を手で書く時間は減っても、何を採用し、何を止め、何を次に確認するかは人間側に残ります。
今の私にとって現実的なのは、AIに手を動かしてもらいながら、対象範囲、差分、影響範囲、検証結果、権限を確認することです。この5つを見ていれば、少なくとも「なんとなく良さそうだから採用する」状態は避けやすくなります。
次にやりたいのは、この監督ポイントを小さなチェックリストにすることです。毎回頭の中だけで確認していると、忙しいときに抜けます。レビュー前に見る項目として残しておけば、記事制作でも実務のコード修正でも使い回せます。
特に私の場合、AIが速く作業してくれるほど、確認する側の気持ちも急ぎがちになります。そこで一度立ち止まって、対象範囲と差分と検証結果を見直すだけでも、あとから「なぜこうなったのか」と迷う時間を減らせます。
AIは作業速度を上げてくれますが、速度が上がるほど、止まる場所を決めておくことが大事になります。Codexを安心して使うためにも、私はこれから「うまく書けたか」だけでなく、「ちゃんと監督できたか」を残していきたいです。
