Agentic OS 技術スタックを下から読む 第28回：検証は、点数を眺める仕事ではない ―― 失敗の記録を読み、型にまとめる

Agentic OS 技術スタックを下から読む 第28回：検証は、点数を眺める仕事ではない ―― 失敗の記録を読み、型にまとめる

書いた仕様は、守られたか

前回は、仕様をどう書くかを考えました。注意を向けられる量には限りがあります。だから、巨大な一枚の仕様にせず、段階に割ります。関係する分だけ渡します。版を持たせます。そうすれば、やってほしいことを取り違える余地を減らせます。

しかし、書いた仕様が実際に守られたかは、別に確かめなければ分かりません。表向き動くことと、要求を満たすことは違います。返事が自然でも、条件を一つ落としているかもしれません。手順が進んでいても、最初の日付を読み違えているかもしれません。

今回の主題は、この確かめる側です。検証とは、最後に総合的な良さの点数を一つ出して眺める仕事ではありません。失敗の記録を一件ずつ読み、似たものを型にまとめ、頻度で一点に絞り、直して、また読む。その輪を回す仕事です。

総合点は進んだ気にさせます

確かめると言うと、まず一つの点数を作りたくなります。役に立ったか。正しかったか。自然だったか。それらを混ぜて、全体として良かった度を一つの数字にします。数字が上がれば良くなった気がします。

ここに落とし穴があります。平均は失敗を薄めます。百件のうち十件がひどく外れていても、残り九十件がそこそこなら、平均は高く見えます。しかし直すべきなのは、その十件です。利用者が強く困るのも、たいていその十件です。平均にすると、そこだけが沈みます。

もう一つの問題は、総合点が方向を示さないことです。点が〇・七から〇・七二に上がったとしても、何が良くなったのかは分かりません。日付を直したのか。条件の読み落としが減ったのか。余計な質問が減ったのか。次に何を直せばよいかが出てきません。

見栄えのする一枚の数字盤は、会議では便利です。しかし、改修の手がかりとしては弱いのです。数字はあるのに、手が動きません。これが偽の進み具合です。

まず一件ずつ読みます

投じた手間に対していちばん効くのは、実際のやり取りを人が読むことです。入力は何だったのか。返したものは何だったのか。途中でどの情報を見て、どこで外したのか。これを生のまま見ます。

一件ずつ読むと、総合点では消えていた失敗が見えてきます。たとえば、返事は丁寧なのに、質問に答えていない記録があります。条件が三つあるのに、二つだけ満たしている記録があります。今日、昨日、来週のような言葉を、実際の日付に直すところでずれている記録があります。

この作業は地味です。けれど、ここを飛ばすと、後の数字が空になります。何を測っているのかを知らないまま測ることになるからです。失敗を自分の目で見ていない状態で、評価の仕組みだけ整えても、現場の手触りが入りません。まず読む。検証はそこから始まります。

失敗の型は下から作ります

読んだだけでは、記録は散らかったままです。次に、似た失敗をまとめます。ここで大事なのは、先に大きな分類を決めないことです。役立ち度、正確さ、読みやすさのような箱を上から置くと、実際の失敗がその箱に押し込まれます。

順番は逆です。記録を読みます。似ているものを寄せます。後から名前を付けます。これが下から型を作るということです。

たとえば、十件、二十件、五十件と読んでいくと、同じ形の失敗が何度も出ます。日付の解釈を取り違える。条件を一つ落とす。本文の根拠ではなく、もっともらしい一般論で答える。丁寧だが結論がない。質問されていない作業まで始める。こうした型は、机の上で考えた分類ではありません。記録の山から浮かんできた分類です。だから、直す場所に近いのです。

型は細かすぎても困ります。一件ごとに別名を付けると、数えられません。粗すぎても困ります。すべてを「正しくない」に入れると、直せません。目安としては、同じ直し方で効きそうな失敗を一つの型にします。日付の取り違えなら、基準日を明示する、相対表現を絶対日付に直す、範囲の端を確認する、という同じ手当てが効きます。だから一つの型にできます。

頻度で一点に絞ります

型ができたら、初めて数字を使います。ただし、総合点ではありません。型ごとの件数を数えます。百件読んで、日付の取り違えが二十二件、条件落ちが十八件、答えになっていない返事が十四件、その他が散らばっている、という数え方です。

こうして見ると、たいてい少数の型が大半を占めます。ある事例では、上位三つの型だけで全失敗の六割を超えていました。残りは細かく散らばっていました。この状態で全部を直そうとすると、手が広がりすぎます。まず、いちばん多い型を一つ選びます。

直し方も一点に絞ります。たとえば日付の扱いが最大の型なら、そこだけ見ます。入力に「昨日」「来週金曜」「月末」のような表現があるとき、基準日を先に固定します。次に、それを具体的な年月日に変えます。さらに、開始日と終了日の境目を含むのか含まないのかを決めます。この三段を明示してから処理させます。

その結果、日付を正しく通せる割合が三割三分から九割五分まで上がったとします。これは総合点を少し上げた話ではありません。支配的な失敗の一つを、実際に潰した話です。検証で使う数字は、このように手を動かす場所を選ぶために使います。

読むための道具を先に作ります

一件ずつ読み、型を付け、件数を数える。これを紙や表だけで続けると、すぐに止まります。だから、読むための道具を先に作ります。

必要なのは、凝った表示ではありません。一画面に、入力、出力、途中で使った文脈を並べます。読みながら一押しで印を付けられるようにします。気づいたことを自由に書ける欄を置きます。型、日付、機能、利用者像のような条件で絞り込めるようにします。隣の記録へ、指の移動だけで進めるようにします。

この程度の道具なら、数時間で作れます。そして、あるかないかで速さが大きく変わります。記録を開く、別の場所に写す、分類を書く、次の記録を探す、という小さな手間が毎回あると、百件読むだけで疲れます。道具があれば、同じ時間で十倍ほど読めることがあります。

多くの場合、順番を間違えます。先に立派な評価画面を作ります。折れ線や円の表示を並べます。しかし、肝心の一件ずつ読む作業は遅いままです。逆です。まず読む道具を作ります。数字を飾る道具ではなく、失敗を見る道具です。

記録がまだないときは作ります

立ち上げ直後には、読むべき実際の記録がありません。利用者がまだいないからです。この段階で何もしないと、最初の利用者がそのまま試験役になります。それは避けたいところです。

そのときは、試験用の記録を自分で作ります。やみくもに作るのではなく、三つの軸で散らします。どの機能を試すのか。どんな場面なのか。どんな利用者像なのか。この三つを掛け合わせます。

たとえば、機能が五つ、場面が四つ、利用者像が三つあるなら、組み合わせは六十通りになります。全部を深く試せなくても、各組み合わせから一つずつ入力を作れば、偏りは減ります。慣れた人の短い依頼だけでなく、初めて使う人の長い依頼も入ります。平常時だけでなく、急ぎの場面も入ります。条件が一つのものだけでなく、条件が三つ重なるものも入ります。

こうすると、利用者がゼロの段階でも、起こりそうな失敗を先に引き出せます。実際の記録がたまってきたら、重心を移します。作った記録を捨てる必要はありませんが、本物の記録を中心にします。最初の一歩は自分で作り、その後は現実に寄せていきます。

確かめる設計は、書く設計と対になります

前回の仕様は、やってほしいことを取り違えさせないための設計でした。今回の検証は、取り違えがどこで起きているかを、現実の記録から見つけるための設計です。書く側と確かめる側は対になります。

検証とは、最後に良さの点数を一つ出すことではありません。失敗の記録を読みます。下から型にまとめます。頻度を数えます。いちばん多い一点に絞って直します。そして、また読みます。この輪の中で使う数字は強いです。型ごとの件数は、次に直す場所を教えてくれるからです。

ただし、ここには続きの問題があります。記録が増えるほど、人が全部を読むことは難しくなります。一日に数千件の記録が出るなら、人手で読み切ることはできません。そこで、読む仕事の一部を別の判定に任せたくなります。

しかし、その判定を下すのもまたモデルです。では、その判定をどう信じればよいのでしょうか。次回は、判定者の話に進みます。人が読む検証から、判定を任せる検証へ。そして、任せた判定そのものをどう確かめるかへ進みます。