シンセサイザー工房で学ぶ生成AIの業務別テストデータ設計

朝八時半、ひだまりクラウドのサポート窓口には、窓から細い朝日が差し込んでいた。キーボードをたたく音と、保留中の電話から漏れる小さなメロディーが、静かな部屋に重なっていた。

葵は一番に席へ着くと、前日の問い合わせを一件ずつ確かめる担当者だった。返事を急ぐ人が多い朝ほど、文の終わりをやわらかくする。「お待たせしました」の一言にも、その人が画面の向こうで抱えている不安を思っていた。

「今日も、まずは料金まわりから見ようか」

隣の真帆が、湯気の立つカップを机の端に置いた。葵は笑ってうなずき、サポート画面に届いた新しい質問を開いた。

画面の上には、短い一文が表示されていた。受信時刻の横で、未対応を示す小さな印が静かに点滅していた。

「契約を変更した場合、いつから新しい料金が適用されますか」

葵は、質問の下にある生成AIの下書きを読んだ。文章はすぐに意味がわかり、言葉も親切だった。

ご契約変更のお手続きが完了した場合、新しい料金は原則として次回の請求期間から適用されます。お手続きの状況によって適用開始日が異なる場合がありますので、詳しくは契約内容をご確認ください。ご不明な点がございましたら、いつでもサポート窓口へお問い合わせください。

「うん。丁寧だし、これならそのまま送れそう」

葵は一度、送信ボタンの近くまでカーソルを動かした。けれど、返事の横にある小さな「参照文書」の表示が目に入った。彼女は、念のためそこを開いた。

表示されたのは、「契約変更の基本」と「料金プラン一覧」だった。どちらにも、手続きの流れや通常の請求方法は書かれている。だが、料金改定があるときの適用条件や、契約の種類による例外についての記載は見当たらなかった。

葵は社内規定の保管場所を自分で開き、「料金改定時の適用条件と例外」という文書を探した。そこには、料金改定後の変更申請は、申請日ではなく承認と契約更新のタイミングで適用日が決まること、年払い契約は更新月以外に途中変更できないこと、既存の割引が新しい料金へ自動的に引き継がれないことが、細かく書かれていた。

「この質問に必要な根拠が、参照文書の中にない」

葵の声が、朝の窓口に小さく落ちた。返事の文章は間違っているようには見えないのに、顧客が知りたい条件だけが抜けている。もしこのまま送れば、次回の請求で料金が変わると思った顧客が、実際の請求書を見て驚くかもしれなかった。

「でも、これは回答の作り方が悪いのかな。それとも、文書の探し方が悪いのかな」

真帆が画面をのぞき込んだ。葵は返事と参照文書を交互に見た。どちらに原因があるのか、今の画面だけでは分からなかった。

「生成AIが、知っていることをうまく文章にできなかったのかもしれない。けれど、そもそも大事な規定を探せていなかったら、文章を直しても同じことが起きるよね」

葵はそう言って、参照文書の一覧を指でなぞった。画面の下には、検索語を追加する欄があった。

「こういう仕組みをRAGって呼ぶの。答えを作る前に、社内文書を探してきて、その内容を材料にして返事を作る仕組みだよ」

真帆は、検索結果の欄を見た。そこには、質問に近い言葉を含む文書が並んでいる。けれど、「近い」と「必要な根拠がある」は同じではなかった。

「じゃあ、今回の返事は、文章の試験だけでは見つけにくいね」 「そう。自然に読めるかだけじゃなくて、必要な文書を見つけたかも見ないといけない」

葵は新しいメモを開いた。最初の欄には、顧客の質問をそのまま写した。次の欄には、検索で出てきてほしい文書を記した。その下に、回答へ入れる条件と、書いてはいけない返事を並べた。

「『次回の請求期間から適用されます』だけでは不十分。契約の種類と承認の時期を確認し、例外があれば案内する。根拠が見つからないときは、断定せずに担当者へつなぐ」

真帆はその言葉を読み、静かにうなずいた。カップの湯気が、二人の間でゆっくりほどけた。

「答えを採点する前に、どの文書を見つけたかを残すんだね」 「うん。質問、検索で渡った文脈、根拠になる規定、そして模範回答。四つがそろえば、どこでつまずいたか見えるから」

窓の外で、配送車のドアが閉まる音がした。葵は送信ボタンからカーソルを離し、作りたてのテストケースに「料金変更・例外あり」と名前をつけた。

その朝、葵は流暢な返事を急いで送らなかった。画面の中のやさしい言葉の奥に、まだ届いていない一枚の規定があることを、静かに確かめていた。

品質確認の会議で、葵は料金改定へのAI回答と参照文書を机に並べた。読み進めるほど、担当者ごとに「良い回答」の形が違うことが見えてきた。

会議室の窓には、薄い夕焼けが映っていた。壁際のモニターには、前日に顧客へ返そうとして止めた回答が表示されている。

「新しい料金は、次回の契約更新時から適用されます。詳しくは担当者へお問い合わせください」

直人は画面を見つめ、ゆっくりとうなずいた。

「自然で分かりやすいね。顧客が知りたいことにも答えている」

葵は、回答の下に開いた文書を指でなぞった。営業資料には「次回更新から適用」とあるが、契約規定には、途中でプランを変更した場合の扱いと、一部の旧プランにだけ適用される例外条件が書かれていた。

「文章はきれいです。でも、契約条件の根拠がありません。検索された資料にも、例外条件が入っていないんです」

直人の眉が少し上がった。葵は、検索結果の一覧を開いた。上から三つには営業資料と古いFAQが並び、いちばん下にある契約規定は、回答を作る材料として使われていなかった。

「この回答だけを読めば、間違いには見えないね」

「はい。だから、出荷前の音色に似ています。Web Audio APIのAudioContextで音が自然に鳴っていても、ADSRの設定を一つ取り違えれば、別の機種では音が変わります。見た目や耳ざわりだけでは、原因を見つけられません」

そのとき、営業担当の美咲が資料を閉じた。顧客との打ち合わせを思い浮かべるように、少し身を乗り出す。

「でも、顧客に伝われば十分ではないですか。細かい例外まで書くと、かえって不安にさせてしまいます」

法務の佐伯は、回答の「次回」という言葉を指した。

「その一文では、どの契約にも同じ条件が適用されるように読めます。旧プランの例外条件が抜けている。顧客が該当していたら、伝わりやすくても危ない回答です」

サポート担当の莉子も、手元の問い合わせ記録を開いた。オペレーターは、答えを読むだけではなく、次に何を確認し、どの部署へ引き継ぐかまで必要になる。

「私たちなら、料金の説明のあとに、契約番号の確認と担当窓口への案内が必要です。営業は短い説明が正解で、サポートは手順まで入っていることが正解になります」

会議室が静かになった。葵がこれまで使ってきたExcelの評価表には、「質問」と「AIの回答」、そして五段階の点数しかなかった。

「この表には、AIがどの文書を検索したかがありません。それに、何を含めれば正解なのかも残っていないんです」

直人は席を立ち、ホワイトボードの前へ歩いた。青いペンで、四つの箱を横一列に書く。

「質問」　　「検索された文脈」　　「AIの回答」　　「模範回答」

「質問は、お客さまが実際に言いそうな形にする。検索された文脈には、回答の根拠になった文書と、その部分を書く。AIの回答を並べたら、最後に、業務として必要な模範回答を置くんだね」

葵は、白い空間が残った評価表を思い出した。そこには、正しい文書を拾えたかを確かめる欄がなかった。

「RAGは、AIが社内資料を探し、その内容を手がかりに答える仕組みです。回答だけ採点していたら、どの資料を拾ったか分かりません」

直人はペンを止め、検索された文脈の箱を丸で囲んだ。

「回答生成だけを採点していたから、検索の失敗が見えなかった」

その言葉で、葵の胸にあった焦りが少しほどけた。問題は、AIが文章を作る力だけではなかった。見る場所を決めずに、最後の文章だけを見ていたことだった。

美咲は営業資料を一枚、ホワイトボードの横に貼った。佐伯は契約規定を開き、莉子はオペレーター向け手順書を並べた。四つの文書は同じ料金について書いているのに、営業資料は伝える魅力を、FAQはよくある疑問を、契約規定は例外を、手順書は対応の順番を示していた。

「質問の種類が違えば、正解の形も変わりますね」

美咲が言った。

「営業なら商品の条件を短く正確に伝える。契約なら例外を落とさない。サポートなら、次の作業まで迷わせない」

佐伯も小さくうなずいた。

「だから、ひとつの点数だけでは足りない。事実が合っているか、根拠があるか、必要な案内があるかを分けて見たほうがいい」

直人は新しい表の最初の行に、実際の顧客質問を書いた。次の行には、契約規定から抜き出した根拠を入れる。その下には、例外条件を含む模範回答と、書いてはいけない表現を並べた。

会議が終わるころ、窓の外は青い夜になっていた。葵は評価表を閉じず、空白だった欄に一つずつ文書名と根拠を書き足していた。

「これなら、流暢な回答に迷わされても、どこで音が違ったのかを探せます」

葵の隣で、直人が静かに答えた。

「次は、営業、契約、サポートの質問を分けて作ろう。良い回答を決めるところから、テストを始めるんだ」

古いFAQと最新版の契約規定が混ざる文書管理棚を、真帆が一段ずつ調べていた。夕暮れの光が、紙の端に細い金色の線を引いている。葵は音色の調整画面から顔を上げ、真帆の手元をのぞき込んだ。

「この棚、返品手順のFAQが二つあります。古い方には、今は使っていない条件も残っています」

真帆は、古い文書に黄色の付箋を貼り、最新版の契約規定には青い付箋を貼った。葵は、前の会議で流暢な回答に混ざっていた、古い料金条件を思い出した。文章の形はきれいでも、検索する文書を間違えれば、音の違う音色を出荷するようなものだった。

「だから、検索と回答を一つの点数で見ないのです。先に、必要な根拠を探せたかを確かめます。そのあとで、探し出した根拠を使って、正しい回答を作れたかを見ます」

真帆は机の上に、五つの小さなカードを並べた。カードには、それぞれ `user_input`、`retrieved_contexts`、`response`、`reference`、`reason_text` と書かれている。葵はカードの間に、細い糸がつながっていくように感じた。

「user_input は、利用者の質問です。たとえば『購入した機種の返品条件を教えてください』ですね。retrieved_contexts は、その質問を受けて検索で見つかった文書のまとまりです」

「それなら、response は生成AIが作った返事で、reference は模範回答ですね」

「その通りです。reason_text は、回答の根拠になった本文です。どの文に支えられているかを残しておくと、答えが違ったときに、文書の問題か生成の問題かを追いやすくなります」

真帆は、カードの名前を一枚ずつ付箋に写した。Microsoft Foundryの入力例で見かける question、context、response も、隣に並べていく。question は user_input と同じく利用者の質問で、context は回答に使う文脈を指す、と真帆は説明した。

「一方で、RAGASでは、検索で取れた文脈を retrieved_contexts と複数形で持つことがあります。reference は、期待する答えや評価のよりどころです。名前は少し違っても、質問、検索結果、生成回答、模範回答を分けて記録する考え方は同じですよ」

「つまり、カードの名前を合わせるだけでなく、何を測るための項目かを見るのですね」

「はい。名前が同じでも、入っているものが違えば、評価は迷子になります」

真帆は、返品に関する一つのテストデータを作った。user_input には利用者の質問を置き、retrieved_contexts には最新版の契約規定と、対象機種を説明する製品文書を入れた。古いFAQだけが検索された場合は、文脈の欄にその事実も残した。

「検索のテストでは、まず必要な文書が含まれているかを見ます。次に、本文が途中で切れていないかを確認します。条件の後半だけが欠けると、『未開封の場合』という大切な一文が消えてしまうことがあります」

真帆は検索結果の紙を指でなぞった。必要な規定が見つかっていても、段落の途中で終わっていれば、根拠としては不十分だった。葵は、音の波形の一部だけを見て音色全体を決める危うさに似ていると思った。

「回答生成のテストは、その次です。response に、retrieved_contexts にない内容を足していないかを見ます。それから、質問に必要な条件をすべて含んでいるか、例外や問い合わせ先を落としていないかも確かめます」

「文章が自然かどうかだけでは、足りないんですね」

「ええ。自然な文章でも、根拠のない約束をすれば業務では使えません。反対に、言い回しが少し違っても、必要な事実と条件がそろっていれば、使える回答になります」

窓の外では、工房の看板に明かりがともった。葵はカードを並べ直し、検索の評価には青い線を、回答の評価には緑の線を引いた。二つの線は別々に進みながら、最後に一つの業務回答へつながっている。

「これなら、答えが悪いのか、探し方が悪いのかを分けて見られる」

葵の声に、迷いはなかった。真帆は最新版の規定を棚の前に戻し、古いFAQを別の箱へ移した。葵もテストデータの最初の質問を入力し、音色を確かめるときと同じように、ひとつずつ試してみようと思った。

葵たちは、カスタマーサポートの業務文書から、LLMでテストケースを作り始めた。けれど、最初にできた質問は、現場の困りごとをほとんど映していなかった。

夕暮れの工房には、料金規定、返品手順、障害対応FAQ、オペレーター用メモが並んでいた。真帆はGoogle Driveのフォルダを開き、最新版と旧版を分けた。顧客名や契約番号は、テスト用の名前に置き換え、原文をそのまま外へ出さないようにした。

「まず、評価する業務と文書を決めるよ。全部を一度に試すと、どこで間違えたのか見えなくなるから」

「今回はカスタマーサポートだね。料金、返品、障害対応の三つに絞ろう」

真帆は、対象文書の名前、版、適用日を表にした。文書をそのまま評価に使うのではなく、必要な部分を根拠として取り出し、質問、検索文脈、回答を別々に保存するためだった。

葵はVS Codeを開いた。LLMには、文書の本文と業務名を渡し、「本文に書かれた事実だけで質問を作ること」「根拠が足りない場合は、確認が必要な質問にすること」と指示した。さらに、回答に必要な事実、避けるべき断定、担当者へ引き継ぐ条件も一緒に出すようにした。

「LLMは、文書を読むだけの機械ではないよ。ここでは、文章を作るAIに、テストの設計者として働いてもらう。でも、自動で作ったものを正解とは決めない」

まず作られたのは、「契約変更の適用日はどこに書かれていますか？」という質問だった。文書の見出しを言い換えただけで、実際の問い合わせらしさがない。二人は、最初の案を捨てずに「自動生成」と印を付け、あとで人が見直す箱へ入れた。

葵は、質問と根拠を小さなJSONにした。reason_textは、回答のよりどころとなる規定本文か、その抜粋である。

{
  "question": "契約変更後の料金はいつから適用されますか？",
  "reason_text": "契約変更の申請を受け付けた日と、変更内容が反映される日についての社内規定本文",
  "answer": "契約変更の内容と適用日は、社内規定に記載された条件に従います。個別の契約状況を確認してください。"
}

「このanswerも、規定に書かれた内容から作る。日割りや翌月一日など、本文にない条件を勝手に足さないことが大事だね」

次に二人は、RAGで回答を作った。RAGとは、社内文書を検索し、その抜粋をLLMに渡して回答させる仕組みだ。検索の結果と、LLMが書いた回答を分けて見れば、「探せなかった」のか「読んだのに間違えた」のかを切り分けられる。

最初の実行では、古いFAQが検索された。回答には「変更後の料金は翌月一日からです」と出たが、最新版の料金規定には、その条件が書かれていなかった。葵は画面の前で、鍵盤から手を離した。

「文章は自然なのに、根拠がないね」

「検索が古い文書を拾ったんだ。文書の版と適用日を検索条件に加えて、根拠の抜粋を回答の横に残そう」

二人は、文書に「最新版」「料金」「適用日」といった属性を付けた。さらに、参照文書にない場合は断定せず、「契約状況の確認が必要」と案内する条件をプロンプトに加えた。再実行すると、回答は慎重になったが、今度は必要な確認手順まで抜けていた。

そこで真帆はSlackで、サポート担当者にレビューを頼んだ。

「自動生成データを正解と決めつけません。実際に聞かれた質問と、答えに迷った質問を追加してください」

返ってきたのは、文書の見出しにはない質問だった。「月末にプラン変更を申し込んだが、請求書が先に発行された場合はどうするか」「返品された商品に傷があったとき、誰へ相談するか」「障害が復旧したとき、折り返し連絡をするか」。現場の人は、条件が二つ重なったときに迷っていた。

葵は、それぞれに根拠文書とエスカレーション条件を付けた。答えが文書にない質問には、「担当部署へ確認する」という模範回答を置き、断定的な回答を許さない。模範回答は、きれいな文章ではなく、必要な事実、必要な手順、避ける表現の組み合わせとして作った。

「業務が変われば、テストデータも変えるんだね」

「そう。営業とマーケティングなら、提案資料や製品仕様から質問を作る。商談記録なら、顧客の要望と次回アクションが抜けていないかを問う。オペレーター支援では対応手順とエスカレーション条件、コール分析では会話の要約、分類、対応漏れを見る」

真帆は、別の紙にも書き足した。IT開発では設計書や障害記録から原因と対応策を問う。業務別に、入力、必要な事実、許容できる言い方、許容できない誤りを分けるのである。

評価のとき、二人は文章の一致だけを見なかった。検索文脈が正しいか、回答が質問に答えているか、文書にない内容を補っていないか、担当者の修正がどれほど必要かを確認した。ChatGPTのようなLLMに判定させる場面でも、重要なケースはサポート担当者が読み、人の判断を残した。

最後に、葵は一つのテストケースへ、質問、検索文脈、生成回答、模範回答を並べた。文書の版、プロンプト、検索条件も記録し、テストデータと設定をGitで管理した。条件を変えたときも、同じケースをもう一度走らせ、検索の変化と回答の変化を比べられるようになった。

工房のスピーカーから、穏やかな音が流れた。葵はSpectrumVisualizerの波形を見ながら、同じ音を再現するには、鍵盤だけでなく設定も記録しなければならないことを思い出した。テストデータも同じだった。質問だけでなく、根拠と判断の条件までそろって、業務で使える音になった。

葵は評価画面を開き、検索側と回答側に分かれた結果を見比べた。画面の左には、RAGが拾った文書の一覧が並んでいる。右には、その文書をもとに生成された回答が表示されていた。

以前の画面では、流暢な回答がひとつの大きな枠に収まっていた。文章が自然だと、葵たちはつい安心していた。けれど今は、どの文書を見て、どこから答えを組み立てたのかが、細い線でつながっている。

「まず、左のランプを見よう。回答を直す前に、検索が正しかったかを確かめるの」

真帆が指を置いたのは、三つの評価欄だった。ひとつ目は Context Precision で、取得した文脈の中に、質問に関係する情報がどれだけ含まれているかを見る。関係のない文書ばかりなら、答えを書く材料そのものが濁ってしまう。

「二つ目の Context Recall は、正解に必要な情報を取りこぼしていないかを見るものね」

「そう。料金の変更日と対象機種だけ拾えて、適用条件を落としていたら、検索はまだ足りないの」

三つ目の Context Entities Recall は、正解に必要な固有名詞や条件が文脈に含まれているかを照らす。製品名、契約区分、受付窓口のような小さな情報が抜けると、文章全体がきれいでも業務では使いにくい。

葵は、前のテストケースを開いた。質問は、シンセサイザーの料金改定について尋ねるものだった。検索結果には旧料金を説明するFAQが続き、改定通知と現行の料金表は下の方に隠れていた。

「この回答、文の形は悪くない。でも、古いFAQを見ているね」

「うん。ここで回答文を責めると、間違った材料から上手に答え直すだけになる。先に検索結果を確認しよう」

真帆は、古いFAQの横に赤い印をつけた。回答側には、旧条件を現在の条件のように書いている箇所があった。二人は、回答の良し悪しを判定する前に、どの文書が上位に出たのかを読み直した。

その下には、もうひとつの小さなランプがあった。Noise Sensitivity と表示されている。

「これは、余計な紙が混ざったときの強さを見るの」

真帆は、関係の薄い機種の説明書を一枚取り出した。質問とは別の製品情報が検索結果に混ざっていても、回答がその内容を取り込まず、必要な根拠だけで答えられるかを確かめる指標だった。

右側の回答欄では、三つの読み方を切り替えられた。根拠に沿っているか。質問にきちんと答えているか。必要な情報が抜けていないか。自然な文章かどうかだけではなく、業務でそのまま確認できる内容かを読むための欄だった。

「ここでは、検索が合っていても回答が外れる場合を見られるね」

「そう。現行の料金表を読めていても、質問された機種に答えなかったり、条件を一つ落としたりすることがあるから」

二人は、すべての指標を一度に採用しようとはしなかった。サポートでは、根拠に沿っているかと、必要な案内を漏らしていないかを重く見る。営業では、製品仕様や提案条件を取り違えていないかを確かめる。開発では、障害記録や設計書に基づいて説明しているかを読む。

「業務が変われば、見るランプも変わるんだね」

「うん。点数を集めるためではなく、どこで間違えたかを探すためのランプなんだ」

葵は、サポート用のテストケースに検索結果と回答を並べた。検索側の赤い印は、古いFAQを上位に出したことを示している。回答側の印は、現行条件を答えに含められなかったことを示していた。

評価結果だけを見れば、ひとつの不合格に見える。けれど二人が失敗したケースの文脈と回答を読み直すと、直す場所はひとつではないと分かった。文書の更新日を検索条件に加える作業と、回答に必要な条件をテストデータへ書き足す作業が、それぞれ必要だった。

葵は検索文を直し、真帆は模範回答に含めるべき条件を確認した。再び画面を動かすと、現行の料金表と改定通知が回答の近くに並んだ。右側の文章も、質問された機種と条件を順に示す形へ変わっていた。

工房の奥では、SynthEngineの音が静かに鳴っていた。以前は、音が自然なら調整は終わりだと思いがちだった。今は、Web Audio APIのAudioContextを通る信号を一つずつ追うように、回答へ届く文脈も一枚ずつ確かめている。

葵は三つのランプを見た。名前は難しく見えたが、光る場所ははっきりしていた。検索の抜け、余計な文書への弱さ、そして回答の取り違えが、別々の場所に現れている。

「これなら、間違いを見つけたときに、誰のせいかではなく、どこを直すかを話せるね」

真帆はうなずき、次の営業用テストケースを開いた。工房の空気には、答えを急がずに確かめられる静かな明るさが戻っていた。

夕方のサポート窓口で、葵は更新された料金規定を登録した。画面の右下では、関連するテストケースが静かに再実行されている。窓の外はまだ明るく、机の上には冷めかけた紅茶があった。

「新しい料金規定を入れたら、答えだけでなく、探しに行く場所も変わるかもしれないね」

葵は、文書の改訂日と適用開始日を確かめた。次に、検索インデックスの内容を開いた。インデックスは、文書を検索しやすい形に並べておく棚のようなものだった。

「古い料金が残っていたら、棚の奥から前の規定を拾ってしまう。だから、更新後の文書が見つかることと、古い文書が答えに混ざらないことを別々に見るの」

検索にはElasticsearchを使う場合もあれば、Azure AI Searchを使う場合もある。葵たちは、文書名、本文、製品名、適用日、改訂番号を検索対象のフィールドにした。検索対象にしない欄へ大切な条件を書いてしまうと、文書がそこにあっても探しにくい。

評価画面には、更新前の回答と更新後の回答が並んだ。Context Precisionは、拾った文書の中に必要なものがどれだけ多いかを見る欄だ。Context Recallは、必要な文書を取りこぼしていないかを見る欄だった。

「今回は新料金を答えられた。でも、旧料金の文書も一緒に出ているね」

真帆が画面を指した。葵は古い文書の有効期限を確認し、検索結果から除外する条件を加えた。その後、同じ質問をもう一度走らせると、根拠欄には更新された規定だけが残った。

回答の形も、機械に確認させていた。JSON Schemaという設計図に、必須項目、文字列や配列などの型、許容する値を記している。さらに、決めていない余計な項目を受け取らない設定も加えた。

「回答がきれいな文章でも、必要な項目がなければ窓口には返せないからね」

たとえば、料金の回答には質問、回答文、根拠文書、担当者への引き継ぎ要否が必要だった。引き継ぎ要否には、はい、いいえのどちらかだけを許した。検証に失敗すると、画面には不足している項目や間違った型が表示され、そのエラーが次の生成に返される。

「ここが直っていないよ。根拠文書が空のままだよ」

葵が再生成を押すと、回答は条件に合わせて作り直された。けれど、JSON Schemaを通ったからといって、業務上の正解とは限らない。葵は最後に、根拠文書の該当箇所と回答を担当者の目で照らし合わせた。

自動生成したテストケースの隣には、窓口から追加された実際の質問も並んでいた。返品期限を尋ねる短い質問や、旧製品からの交換条件を聞く長い相談もある。自動生成のケースは入口を広げ、現場の質問は、実際に起きたつまずきを教えてくれた。

以前の葵は、流暢な回答文を見ると、つい安心していた。今は、どの文書を探し、何を根拠に答えたのかを確かめてから、窓口へ返している。

「答えを直すだけじゃなくて、答えが生まれた道も見えるようになったね」

真帆の声に、葵は小さくうなずいた。窓ガラスには、暗くなり始めた空と、更新された評価画面が重なって映っている。しばらくして、次の文書更新を知らせる通知が届いた。

葵は通知を開き、適用日を確認した。新しい質問の欄に、短いテストケースをひとつ追加する。夕方の工房で音の波形を見守っていたころと同じように、葵は変化の小さな揺れを見逃さず、静かに次の確認を始めた。