Codexを「放し飼い」にしない。「拾い食い」を止めて分かったAIコーディングの境界線

個人開発でCodexを使うようになって、コード作成が早くなった。複数ファイルを横断した調査も、修正案も、テスト作成も全部任せられる。ただ使い続けるうちに、一つ気づいた。Codexに「コードを書くこと」を任せるのと、「何を直すか」を任せるのは別ではないか、ということだ。最初は「AIに任せすぎるのは怖い」くらいに考えていたが、実際の問題は「AIを信用するか否か」ではなく「どこまでをAIの仕事にして、どこからを人間の判断として残すか」にある。

ここで重要な考え方が「拾い食いをさせない」という原則だ。Codexは頼んだ場所だけを見ると限らない。周辺の問題まで発見することがある。そして「見つけたなら修正しましょう」とそのままやってしまう。これが危ない。見つけることはOK。しかし確認せず修正するのはNG。問題を発見したら一度停止させて、人間が確認してから次のタスクに切り出す。このステップを挟まないと、変更同士の因果関係が追いにくくなり、どの修正がどのテストを担保しているのか、どの変更で不具合が入ったのかが曖昧になる。また重要なのが「できる」と「今やる」は別という判断だ。Codexなら認証もCSRF対策も全部実装できるかもしれない。だが「できる」からといって「今まとめてやる」にはならない。優先順位を明確にして、一つずつ確認しながら進める。その過程で、作業範囲の柵（何をするか小さく決める）、環境の柵（テストDBを分離する）、Gitの柵（変更内容を確認してからcommit）という3つの防御線が機能する。

AIに複数の改善を任せるときは、「発見」と「修正」を分離するルールを引く。そして各段階で「今回の範囲外」と判定したら、自動修正させずに報告させるだけ。このプロセスがあれば、変更履歴を追える状態を保ち、予期しない不具合を減らせる。AIは万能だが、判断は人間に残す。