あなたも、AIへの注意書きが守られなかった経験はありませんか。私は、個人で作っているアプリで、それを体験しました。自分で「大事だ」と書いた注意書きが、その20行下で、実際とずれていたのです。なぜ防げなかったのか。そこから今、どう運用を変えたかを紹介します。AIを責める話ではなく、確認の手順の話です。
【体験】書いたはずの注意書きが、守られていませんでした
個人でアプリを作っています。最近は、AIにコードを書いてもらう機会が増えました。
早く形になるぶん、確認の手間も増える。そう感じることが多くなりました。
これまでも、AIが書いたコードの不具合には、何度か気づいてきました。今回、初めて気づいたのは、コードではなく文書のずれです。
ある日、こんな作業がありました。利用者向けの説明文を、画面に表示する機能です。
「何を保存し、何を保存しないか」を、利用者に伝える文章でした。個人情報を扱う以上、誤りがあってはいけない部分です。
AIに、そのコードを書いてもらいました。ファイルの冒頭には、こんな注意書きも一緒に残されていたのです。
いま実際に保存しているものだけを書く。将来の予定を書かない。
ここに書いてあることと実装がずれた瞬間、この注意書き全体が信用されなくなる。
読んだとき、「よく気が付いた注意書きだ」と感じました。自分でも大事だと思い、そのまま残すことにしました。
ところが、その注意書きから、わずか20行下で、実際とずれていたのです。書いてある内容の一部が、実装されていませんでした。
見つけたのは、私自身ではありません。AIに、そのコードのレビューを頼んだときでした。
自分で「大事だ」と思って書いた文が、すぐ近くで破られている。それに、自分では気づけなかった。これが、この記事のきっかけです。
指摘を受けたときは、正直、驚きました。同時に、「よく見つけてくれた」とも思いました。自分ひとりの目では、限界があると実感した瞬間です。
【原因】「書いてあるのに」防げなかった理由
なぜ、自分で書いた注意書きが、自分を止められなかったのか。順番に考えてみました。
答えは、案外単純でした。コメントは、実行されません。読むかどうかは、そのときの自分次第です。
読んでいれば気づけたかもしれません。でも、忙しいときほど、コメントは読み飛ばされます。
私自身、コードを見返すとき、コメントより先に処理を追ってしまう癖があるのです。注意書きは、その分だけ見落としやすいのだと思います。
止めてくれるのは、テストのような、実行されるものだけです。人の注意力には頼れません。
実は、この機能にはテストも書いていました。「保存する内容が正しいか」を確認するテストです。
ところが、そのテストは、形だけを見ていました。「注意書きに書いた各項目が、本当に保存されるか」。それは、誰も確認していなかったのです。
似たようなことが、別の機能でも起きていました。「保存した内容から、機密情報を隠す」というテストです。
このテストは、テスト用のデータに、機密情報を1つも含めていませんでした。そのため、隠す処理を丸ごと削除しても、テストは通る状態でした。
見ているつもりで、実は見ていない。同じ型のずれが、2箇所で起きていました。
1つ見つかると、つい「もう直った」と安心してしまいます。ただ、同じ型のずれは、他の機能にも潜んでいるかもしれません。1箇所直して終わり、にはしないよう気をつけています。
【独自検証】ずれていたのは、コードではなく文書でした
振り返ると、この画面の説明文を、4回書き直していました。
理由は、毎回同じでした。「書いてあることが、実際には起きていなかった」からです。
| 版 | ずれていた内容 |
|---|---|
| 1回目 | 「やり取りの本文を保存する」と書いたが、実装していなかった |
| 2回目 | 「添付ファイルの種別とサイズを保存する」と書いたが、実際は保存していなかった |
| 3回目 | 「期間を過ぎたら自動で削除する」と書いたが、自動削除は未実装だった |
| 4回目 | 「本文は同意した時点まで保存する」と書いたが、実装は違う範囲だった |
見つかったのは、コードの不具合ではありません。ずれていたのは、いつも文書のほうでした。
AIは、文書を書くのがとても速いです。そのぶん、実装との差も、速く生まれてしまいます。そう感じています。
もう一つ、気づいたことがあります。「テストのテスト」という確認作業です。
わざとバグを戻し、テストが赤くなるかを確かめる作業です。今回のスライスだけでも、10回以上やっていました。
それでも、今回のずれは通り抜けました。テストのテストには、限界があったのです。
テストのテストで分かるのは、「そのテストが、壊れたコードを捕まえるか」だけです。
「そのテストが、正しいものを見ているか」までは、分かりません。狙いがずれていれば、何度確かめても素通りします。
【気づき】想定と違ったこと
私はもともと、「テストさえ書けば、ずれは防げる」と思っていました。ところが、実際はそうではなかったのです。
大事なのは、テストの数ではありませんでした。「何を確認するテストなのか」を、先にはっきりさせることだと気づきました。
数だけ増やしても、狙いがずれていれば、素通りしてしまいます。今回、身をもって分かりました。
注意書きを書くこと自体は、悪いことではありません。ただ、それだけで満足してはいけない。それが、今回の実感です。
似たようなことが、他の画面にもないか。今、あらためて見直しているところです。
【今の運用】注意書きを、動くテストに置き換える
この経験から、やり方を変えました。特別に新しいことは、していません。既存のやり方に、手を加えただけです。
| 場面 | 今やっていること |
|---|---|
| 利用者向けの説明文を書くとき | 1行ごとに、それを検証するテストを用意する。紐付けられない行は、書かない |
| 既存のテストを見直すとき | 「テストのテスト」の対象を、その機能だけでなく、関係するテスト全体に広げる |
| 確認項目（チェックリスト）を作るとき | 「必須」か「任意」かを、作る時点で決めておく |
あとから基準を変えると、判定がゆるくなりがちです。だから、作る時点で決めます。
この表は、AIに読ませる作業ルールのファイルにも、そのまま反映しました。私の記憶だけに頼らないためです。
今も、新しい機能を作るたびに、この表に沿っているか見直しています。まだ完璧にはできていません。それでも、ずれに気づく速さは、明らかに変わりました。
まとめ：注意書きではなく、実行されるものに約束を任せる
「書けば伝わる」「書けば守られる」は、私の思い込みでした。
コメントや説明文は、自分を止めてくれません。止めてくれるのは、テストや型のような、実行されるものだけです。
あなたのプロジェクトにも、こんな注意書きはありませんか。「書いたはずなのに、実装が違う」というものです。
私も、まだ探している途中です。よければ、一緒に確認の手順を見直してみませんか。
完璧な注意書きを目指すより、少しずつでも、実行されるものに約束を移していく。今の私は、その考え方で開発を続けています。
X（@kandt0517）でも、AI活用やアプリ開発の気づきを発信しています。よければ、フォローして一緒に学んでいきましょう。
参考・引用元ソース
本記事は、個人開発の記録（自分用のメモ）にもとづいています。外部の情報源からの引用はありません。
コメント