🐕‍🦺Codexの「拾い食い」を防ぐ。pytest第3段階で気づいた“ついで修正”対策

はじめに

私は現在、本業でトラックドライバーとして働きながら、PythonやFlaskを使ったWebアプリケーション開発を独学しています。

最近はVS CodeのCodexを使いながら、個人開発中のFlaskアプリでpytestを強化しています。

現在進めているのは第3段階。

認証・認可・CSRFなど、

「誰が操作してよいのか」「その操作が本人の意図したものか」

という部分を確認しているところです。

その作業中、Codexとのやり取りを見ながらふと思いました。

これ、犬の「拾い食い」に似てないか？🦮

今回は、そんな少し変わった気づきについて書いてみます。

---

Codexは頼んでいない問題まで見つける

Codexにコードを調査してもらっていると、今回の作業とは別の問題を見つけることがあります。

たとえば、

今回は認証まわりだけ確認する

と依頼していても、

別のAPIにも問題があります
この処理も改善できます
ここも修正した方がよさそうです

といった具合に、周辺の問題まで見つけてくれます。

これは悪いことではありません。

むしろ、

自分では気づかなかった問題を見つけてもらえる

という意味では、とても助かります。

ただし、そのまま、

ついでに修正しておきました。

まで進まれると話が変わります。

---

「ついでに修正」が犬の拾い食いに見えてきた

Codexとの作業中に思いついたのが、この例えです。

🐕‍🦺散歩中の犬が、

道ばたで何かを発見
↓
気になる
↓
飼い主に確認せず口へ入れる

これが拾い食いです。

Codexも、

コードを調査
↓
別の問題を発見
↓
良さそうだからついでに修正

と進んでしまうと、かなり似ています。

本人としては、

「良いことをした🐶」

つもりかもしれません。

でも飼い主側からすると、

待て待て！
それ誰にもらったの？
勝手に食べちゃだめ！

となります。

Codexでも同じです。

待て待て！
今回そこは頼んでない！
勝手に修正範囲を広げちゃだめ！

となります。

---

見つけるのはOK⭕、 拾い食いはNG✖

そこで最近は、Codexへの指示をかなり明確にしています。

例えば、

想定外の問題を発見しても、
今回の修正範囲を広げず、
報告だけしてください。

という形です。

考え方は単純です。

見つけるのはOK。
勝手に直すのはNG。

問題を発見したら、

問題発見
↓
報告
↓
今回の作業を停止
↓
人間が確認
↓
必要なら次の作業として切り出す

という順番にします。

これなら、

発見することと、修正することを分けられます。

---

なぜ「ついで修正」が怖いのか

一見すると、

問題を見つけたなら、ついでに直した方が早いのでは？

と思うかもしれません。

私も最初はそう思っていました。

ただ、実際に複数の修正を進めていくと、

「ついで修正」にはいくつか困る点があります。

変更範囲が分からなくなる

例えば、

認証を追加する

という作業だったのに、

認証
API修正
DB修正
テンプレート修正
ログ改善

まで一気に入ってしまうと、

どの変更が何のためだったのか

追いにくくなります。

---

問題が起きたとき原因を追いにくい

修正が1つなら、

この変更で壊れた可能性が高い

と考えられます。

しかし複数の「ついで修正」が混ざると、

どの変更が原因？

となります。

---

テストの意味も曖昧になる

私は最近、pytestを

「事故防止台帳」

として考えています。

問題を1つ見つけたら、

危険な状態をテストで再現
↓
赤になることを確認
↓
最小修正
↓
緑になることを確認

という流れで進めています。

ところが途中で別問題まで一緒に修正すると、

どの赤テストに対する修正だったのか

分かりにくくなります。

---

pytest第3段階でも「待て🖐」を使った

現在進めているpytest第3段階では、認証まわりを確認しています。

まずはコードを修正せず、

認証
認可
CSRF

の現在状態だけを調査しました。

その次に、

未認証POSTを拒否する

という将来仕様を赤テストとして追加しました。

さらにログイン仕様も赤テストへ追加し、

5 failed

を確認してから、最小限の認証実装へ進みました。

修正後は、

56 passed

となりました。

この途中でも、

今回は認証だけ
CSRFはまだ触らない
logoutもまだ触らない
API保護もまだ触らない

と範囲を区切っています。

Codexからすると、

「そのまま次もやれそう」

な状態でも、

いったん止めます。

---

「できる」と「今やる」は別

今回特に感じたのは、

Codexができることと、今やってよいことは別

ということです。

例えば、

CSRFも実装できる
logoutも追加できる
APIも保護できる

としても、

それは、

今まとめて全部やる

という意味ではありません。

人間側が、

今回はここまで

と作業範囲を決める必要があります。

これはプログラミング以外の仕事でも同じだと思います。

---

git statusとgit diffは「口の中チェック」

犬が散歩から帰ってきて、

何か変なもの食べてない？

と確認するように、

Codexの作業後は、Gitの状態と差分を確認しています。

例えば、

git status --short
git diff --stat
git diff
git diff --check

などです。

これで、

• 頼んだファイルだけ変更されているか
• 想定外のファイルが増えていないか
• 無関係な修正が混ざっていないか
• 空白エラーがないか

を確認します。

つまり、

Codex
「ちゃんと散歩してきました！🐶」

git diff
「ちょっと口の中見せて」

です。

AIが「指定外の変更はありません」と報告しても、
最終的には差分を確認するようにしています。

---

pytestは拾い食い後の体調確認ではない

さらにpytestも実行します。

ただしpytestは、

Codexが勝手な変更をしていないか確認する道具

そのものではありません。

pytestが確認するのは、

これまで守ってきた仕様が壊れていないか

です。

そのため、

作業範囲
↓
git diff
↓
pytest

それぞれ役割が違います。

私の中では、

作業範囲
= 散歩コースを決める

想定外では停止
= 拾い食い禁止

git diff
= 帰宅後の確認

pytest
= 健康状態・既存ルールの確認

というイメージになっています。

---

Codexは「放し飼い」にしない

以前、Codexを使うときに、

「放し飼いにしない」

という記事を書きました。

今回の「拾い食い」も、その考え方の延長です。

Codexはかなり速く作業できます。

その分、

調査
↓
問題発見
↓
修正
↓
さらに別問題発見
↓
追加修正

と、一気に進められてしまいます。

だからこそ、

速く動けるAIには、止まる場所も決めておく

必要があると感じています。

---

最近よく使う指示

最近、Codexには次のような指示を入れることが増えました。

想定外の問題を見つけても、
今回の修正範囲を広げないでください。

報告だけして停止してください。

次の作業には進まないでください。

commit・pushは行わないでください。

かなり慎重に見えるかもしれません。

でも、Codexを信用していないというより、

Codexが速く動けるからこそ、作業範囲を明確にしている

という感覚です。

---

まとめ

Codexを使ってpytest第3段階を進めている途中、

Codexの「ついで修正」は犬の拾い食いに少し似ている🐩

と気づきました。

Codexの拾い食い対策

• 今回の作業範囲を決める
• 想定外の問題は報告だけ
• 発見と修正を分ける
• 次の工程へ勝手に進ませない
• git diffで変更範囲を確認する
• pytestで既存仕様が壊れていないか確認する

一番大事なのは、

見つけるな

ではありません。

むしろ、

見つけてほしい。
でも勝手に食べないでほしい。

です。

Codexはかなり頼れるワンちゃんです。🐾

だからこそ、

待て。
そこはまだ行っちゃだめ。

と言える状態で使うのが、今のところ私には合っています。

次はpytest第3段階の続きとして、CSRF対策を進める予定です。