ベテランエンジニアのAIエージェント奮闘記 #3 〜成分データを3倍にして、テストで"信頼できる"に変えた話〜
AIに数を増やしてもらうのは、簡単でした。難しかったのは、その数を信じられるようにすることでした。
前回は、化粧品の表記チェッカーを、改良を重ねて"使える"に近づけた話を書きました。ただ、肝心の成分照合データベースは、まだ126件しかありません。これでは「使える」とは言えても、「信頼できる」とまでは言えませんでした。
第3話は、この126件を384件へと増やし、テストの網を張り直して、アプリを"信頼できる"に引き上げていった話です。
先に、この回の結論を書いておきます。データの数を増やすのは、AIの仕事でした。でも、それを信頼に変えたのは、表記ゆれの吸収と、テストという安全網と、最後の人手の検証という、どれも地味な作業でした。
126を384に——数は、AIがすぐ増やした
まず手をつけたのは、成分照合データベースの拡充です。立ち上げ時点で126件だったものを、384件——およそ3倍に増やしました。
データの形は、1つの成分につき、日本語名・INCI名（成分の国際表記）・そして「表記ゆれ」の3点セットです。これを、公開されている情報（日本化粧品工業連合会や厚生労働省の資料、ISOの国際規格など）を参考に、AIに調べさせ、決まった形に整えてもらいました。
新しく足したのは258件です。保湿成分、油性成分、界面活性剤、増粘剤、植物エキス、紫外線吸収剤や散乱剤、着色料、医薬部外品の有効成分、pH調整剤、精油——と、分類ごとに埋めていきました。
数を増やすだけなら、AIは速い。一人で何百件も手入力していたら気が遠くなる作業を、短い時間で形にしてくれます。
ただ、ここで立ち止まりました。「件数が増えた」ことは、「使える」ことを意味しません。むしろ、本番はここからでした。現場の成分表を見ると、同じ成分が、まったく違う書き方で並んでいたのです。
同じ成分が、何通りにも書かれる——表記ゆれとの戦い
たとえば「水」。製品のパッケージを見ると、「水」と書かれていることもあれば、「精製水」「イオン交換水」「蒸留水」、あるいは英語で「Aqua」と書かれていることもあります。どれも、中身は同じ成分です。
人間なら「ああ、どれも水ね」と分かります。でも、ただ文字を突き合わせるだけの照合では、「水」と「Aqua」は別物として弾かれてしまう。これでは、正しく書いてあるのに「未登録の成分です」と誤判定する、使えないツールになってしまいます。
そこで、データベースは1つの成分に対して、複数の「表記ゆれ」を持たせる作りにしました。「水」の項目には、先の4つに「Pure Water」「滅菌精製水」を加えた6通りを持たせています。「ブチレングリコール」なら「BG」「1,3-BG」「1,3-ブタンジオール」といった具合です。照合するときは、大文字と小文字の違いや空白も無視したうえで、この揺れを吸収して、表記が違っても同じ成分だと判定します。
結果の画面には、「登録済み」「未登録」「表記ゆれ」の件数を並べ、揺れていた成分には「→ 正式名称」を横に添えるようにしました。なお、計画書の段階では「成分の並び順がおかしいところ」も検出対象に挙げていましたが、実際に作り込んだのは、この三つの仕分けまでです。
信頼できるかどうかの分かれ目は、件数の多さ（量）ではありませんでした。この"揺れの吸収"こそが核でした。現実のデータは、いつも汚れている。それを前提に作る——というのは、組込みで嫌というほど経験してきた感覚です。
データを整えたら、次は「壊れないこと」を保証する番でした。
AIが書いたものを、テストで縛る——回帰の安全網
ここで、私はテストに本腰を入れました。
自動テストの仕組み自体は、立ち上げのときに入れてありました。今回やったのは、その網を大きく広げることです。ブラウザを自動操作して動作を確かめるテストは、25本から37本、そして9つのファイル・49本へと増えていきました。内訳は、もともとあった機能が壊れていないかを確かめる「回帰テスト」と、新しく足した機能——レポート出力、テキスト入力、そして成分照合——のためのテストです。49本のうち12本は、実際にAIを呼び出すため、本物のAPIキーがある環境でだけ動き、ない環境では自動で飛ばす作りにしました。
そして、開発のルールを一つ決めました。コードを変えたら、必ず全部のテストを走らせ、すべて通ってからでないとコミットしない。 このルールは私の頭の中に置いておくのではなく、全体を統括するエージェントと実装担当のエージェントの指示書に書き込みました。人間がうっかり忘れても、手順のほうが覚えている状態にしたかったのです。
なぜ、ここまでやるのか。AIは、コードを直すのも速い。けれど、速く直すぶん、直したついでに別のどこかを静かに壊していることがあります。人間が一行直すのとは、影響の及ぶ範囲の読みにくさが違うのです。
回帰テストは、その「直したら、ほかは壊れていないか」を毎回自動で保証してくれる安全網です。AIにたくさん作らせ、たくさん直させるほど、この網がないと怖くて先に進めません。これは、組込みでやってきた品質保証の考え方と、まったく同じでした。
もっとも、その網自体も、最初から頼れるものだったわけではありません。
網そのものも、最初は穴があった
画像のチェックを実際に走らせ、結果が画面に出るところまで確かめるテストを12本足したとき、1回目の実行は、8本が通って4本が落ちました。
原因を一つずつ潰していくと、落ちた理由はアプリの不具合だけではありませんでした。テストを動かす設定が、私の手元の環境に合っていなかったこと。途中でテスト用のサーバーが止まっていたこと。そして、テストのコードそのものが、画面の部品を実在しない名前で探していたこと。アプリ側にも、AIが読み取った文字が空だと、その表示欄ごと消えてしまう不具合が一つ見つかりました。
2回目で10本、3回目でようやく12本すべてが通りました。
テストは、書いた瞬間から正しいわけではありません。網を張ったら、その網が本当に魚を捕まえられるのかも確かめる。検証する側も、検証の対象です。
実は、網を広げる前の点検の段階でも、いちばん怖いミスを一つ捕まえていました。
テストが捕まえた、いちばん怖いミス
テスト担当のエージェントに、チェック項目の定義をコードから点検させていたときのことです。ある項目の根拠として書いた「条文番号」が、別の項目と同じ番号を重複して指していたのが見つかりました。表示そのものは動いていて、ぱっと見では気づきません。点検の判定も「リリースは可。ただし業務の正確さに影響するので修正を推奨」というものでした。
第1話で、私は「法律の判断はAIにさせず、根拠となる条文番号は人間がコードに固定する」と書きました。ところが、その固定したはずの条文番号自体が間違っていたら、わざわざ人間が握った意味がなくなってしまう。検証とレビューの網が、その取り違えを捕まえてくれたのです。すぐに正しい根拠へ書き直しました。
ヒヤリとしました。そして、同時に納得しました。信頼というのは、華やかな新機能では作れません。こういう地味な検証を、何度も通すことでしか積み上がらない。
ついでに、網はもう一段重ねました。コードの中に、うっかり秘密の情報（APIキーなど）が紛れ込んでいないかを自動で調べる仕組みと、使っている部品（ライブラリ）に既知の弱点がないかを調べる仕組みも、変更のたびに走るようにしておきました。
"使える"が、ようやく"信頼できる"に近づいた
振り返ると、この回でAIに任せたのは、主に「数を増やす」ところでした。そして、その数を"信頼できる"に変えたのは、私のほうの仕事——表記ゆれを吸収する設計、テストという安全網を広げること、そして最後に人の目で確かめることでした。
第1話では「どこまで任せ、どこを握るか」の線を引きました。第2話では、AIの不確実性とコストに計器をつけて「育てる手綱」を握りました。そして今回、その上に「品質の安全網」を張った。任せ方が、一段ずつ深まってきた感覚があります。
動く、使える、そして信頼できる。三つが、ようやく揃いました。
次回は、これを実際に世に出す話です。Vercel というサービスで公開し、自分以外の人にも使ってもらう——化粧品チェッカー編の結びを書きます。
