テストは本番で

一月二十六日 第二会議室

十二月に発注した受注入力の刷新のうち、先に頼んだ「受注メールから入力項目を埋める部分」が、一月の終わりに納品された。アストラム・データ営業部長の間宮は、受け入れ検査の報告書を配った。

「基準を大きく上回っております。生成AIは出力が毎回変わりますので、細かいテストを重ねるより、本番で様子を見ながら調整していくのが近道です。どちらのお客様でも、そうされています。それに、使っていくうちに精度は上がっていきます」

「200件は、一回ずつ流した結果ですか」

「はい、1回で8件です。毎回変わるものですから、何回流しても意味は同じかと存じます」

倉田は何も言わず、報告書の余白に「一回」とだけ書いた。

AI推進室の室長代理、瀬尾奈々は、報告書の1行目で止まった。検査データの出どころが書いていなかった。

「この200件は、どなたが用意されたものですか」

「弊社で、御社の書式に合わせて作成いたしました。個人情報の心配もございません」

「使っていくうちに上がる、というのは、何をどう足すと上がるのでしょうか。その作業は、どなたがされますか」

「そこは、運用の中で、ご一緒に」

総務課で契約を担当する戸田美和が、発注書の写しを開き、受け入れ条件を声に出して読んだ。

「過去の受注メール、とあります。でも、どのメールを誰が選ぶのか。ここ、書いてないですね」

十二月に瀬尾が件数で書いた条件は、半分しか閉じていなかった。情報システム課の森拓海が手を挙げた。入社三年目で、十二月に内製の試作を作った本人だった。

「自分がやります。去年1年分の受注から、実際の比率のまま200件抜きます。期待する入力は、業務課に書いてもらいます」

間宮は隣の技術者の顔を一瞬だけ見てから、うなずいた。

「もちろん、ご確認いただいて結構です」

一月二十八日 カスタマーサポート課

その二日後、カスタマーサポート課長の村瀬早苗から推進室に電話があった。四月の本導入から、汀システムの回答案づくりを使っている課だった。

「最近、回答案の口調が変わったのよ。どれも最初に長いお詫びが入るし、旧版と新版の違いの注意書きが、ときどき抜けてる。誰か、何か変えた?」

情報システム課の係長で推進室を兼ねる倉田誠が、変更の記録を調べた。AIへの指示文も、参照している手順書も、十二月から一文字も変わっていなかった。

「こっちは何も変えてない。変わったとすれば、その先だ」

瀬尾が電話をすると、汀システムの技術営業の岸本優は、調べて折り返すと言い、一時間後にかけ直してきた。

「一月の中旬に、うちが使っている上流のモデルが更新されていました。通知はうちに届いていたのに、御社にお伝えするまで2週間かかっています。更新のあと、御社の問い合わせで検証もしていません。うちの落ち度です」

「更新の前と後で、どれくらい変わったか比べられますか」

「正直に言うと、比べる元がありません。本導入のときの確認用の問い合わせは、試験のたびにうちで作り直していて、残していませんでした」

比べる元は、別のところにあった。CS課は本導入のときから、回答案を「AI案」と「担当者確認」の2列で記録していた。森がその2列を突き合わせ、担当者が手を入れた回答案の割合を月ごとに出した。記録はあったのに、誰も月次では集計していなかった数字だった。

「線が跳ねたところに、更新が1本だけ立ってる。この図を毎月見ていれば、村瀬さんに言われる前に気づけた」

村瀬は、図の「一月後半」を指でたたいた。

「それでも4割で済んでるのは、うちの子たちが直してるからよ。ただ、忙しい日は『確認済み』にチェックだけ入れて送ってる子もいると思うの。そうなったら、この数字は下がって見えるでしょう」

間宮の「テストは本番で」と、岸本の「比べる元がありません」。同じ週に聞いた2つの言葉は、瀬尾の中で一つにつながっていた。

二月六日 情報システム課

森は、2つの200件を作った。

一つめは受注メールだった。去年1年分から、ファクスを読み取ったPDF、分納で納期が3つあるもの、旧品番のままの注文、前日の注文を訂正するメールまで、実際の比率のまま抜いた。アストラムの200件には、そのどれも入っていなかった。同じ処理を流すと、結果はこうなった。

「項目ごとに見ると、どれも9割を超えてます。でも一件の中にどれか一つでも間違いがあれば、業務課はその一件を見直すことになります。確認の手間を決めるのは、件ごとの数字です」

41件の中身を営業部業務課の課長に見せると、分納の納期と訂正メールが半分を占めていた。

「そこは、うちでも新人が間違えるところです」

二つめは、CS課の問い合わせだった。村瀬のチームと3日かけて代表的な問い合わせ200件を選び、一件ごとに「回答案に入っていなければならないこと」を書いた。型番、該当する手順書の番号、旧版と新版の違い、次にお客様がすること。村瀬ノートにある「たまにある」問い合わせも、実際の割合で混ぜた。

「文章って、正解が一つじゃないよね。それでも採点できるの?」

「文章のよしあしは、人が読まないと決まりません。でも、入っていなければならないことが入っているかは数えられます。それと、一回では決めません。同じ問い合わせを5回ずつ流して、5回とも許容範囲に入るかを見ます」

5回ずつ流すと、同じ問い合わせでも、手順書の番号が抜ける回が5回に1、2回出るものがあった。一回だけ試していれば、見えなかった揺れだった。

間宮の言ったことの半分は、本当だった。同じ入力に同じ答えが返ることを確かめるやり方は、確かに使えない。違っていたのは、そこから先の結論だった。

岸本は翌週から、この200件を使って指示文の調整を試した。最初の案でお詫びの一文は消えたが、同じ変更で、旧版の注意書きが入る割合が下がった。

「一度に変えるのは一か所だけにします。良くなった項目と悪くなった項目を、両方並べてお出しします。モデルが変わると、効く書き方も変わるので」

3回目の調整で、修正率は一月前半の水準に戻った。森は、200件を流して結果を記録するスクリプトを1本書いた。

「回帰テストと言うと大げさだけど、中身はこれだけだ。検証用の問い合わせと、スクリプト1本。毎月一日に流す。モデルが変わったと聞いたら、その日にも流す。本番で様子を見るのも要るけど、それは修正率で見る。検査の代わりにはならない」

二月十九日 常務室

アストラム・データとの受け入れ条件は、戸田が書き直した。

4番目は、岸本の「比べる元がありません」から足した一行だった。

「前例のない条件ですね」

間宮はそう言ったが、翌日、アストラムの技術者から、朝凪の200件で調整をやり直させてほしいという連絡が来た。

二月の月次報告から、推進室はAIの仕組みを3つの層で見ることにした。

「3つを混ぜないのがこつだ。検証セットの点が変わらないのに修正率だけ上がったら、変わったのはモデルじゃなくて、来る問い合わせのほうだ。どっちが動いたかで、打つ手が違う」

CS課の確認欄も変えた。「確認済み」のチェックをやめ、何を直したかを型番・手順書・口調・その他から選ぶ形にした。修正率が急に下がったら、品質が上がったのか、確認が軽くなったのかを調べる。村瀬の心配を、数字で見るための欄だった。上流の更新の知らせは、担当者個人ではなく推進室の共有の窓口で受けること、更新が予告されたら切り替える前に200件を流すことを、汀システムと決めた。

三つめの層のために契約の一覧を洗うと、小さな発見があった。二年前に営業部と購買課で40人分を契約した翻訳サービスで、この3か月、月に一度でも使った人は7人だった。契約数の2割に届かない。障害の記録は一件もなく、苦情も来ていなかった。使わない理由を聞くと、ほとんどが「使う場面がなくなった」だった。

常務の大槻修は、報告のその行で手を止めた。

「問題が起きていないものまで数えるのか」

「問題が起きていないので、数えないと分からないんです。次の更新で、使っている人の分だけに減らします。やめるのも、改善のうちだと思います。ほかの仕組みにも、止める条件を先に書いておきます。使う人が契約の2割を切って3か月戻らなければ、見直す、というふうに」

「汀のほうは、どうする」

「続けます。岸本さんは、検証していなかったことを、検証していなかったと言いました。比べる元は、いまはうちの手元にあります」

その晩、森のスクリプトは、三月一日の朝に動くように設定された。

瀬尾は手帳に書いた。「毎回変わるからテストできない、ではない。毎回変わるから、毎月測る」