Agentic OS 技術スタックを下から読む 第18回：本当にできているか、どう確かめるか ―― 答えではなく「たどった道」を読む

作ったあとに残る問い

ここまで、エージェントをどう作るかを下から見てきた。

賢く動かすための設計。無駄を減らすための分解。外部の道具を安全に使うための境界。記憶を持たせる方法。途中の実行を見えるようにする方法。失敗しても壊れにくくするための仕組み。

だが、ここで最後に大きな問いが残る。

それは本当にできているのか。

一度うまく動いた。手元の例ではよい答えを返した。画面で見ると賢そうに見える。だが、それは仕事を任せてよいという意味だろうか。長い手順を、条件が少し変わっても、毎回こなせるという意味だろうか。

この問いに答えるのが、評価である。

ただし、ここで言う評価は、最後に付け足す採点表ではない。完成したものに点数を付けて終わる作業でもない。作っている途中から、出力を読み、実行の記録を読み、失敗を集め、型に分け、次の直し方を決める工程である。

以前、「最終出力だけを見ても、なぜ成功したか、なぜ失敗したかは分からない」と書いた。だから実行の木を見る必要がある、とも書いた。また、「検証できるかどうかが、鍛えられるかどうかを決める」とも書いた。

評価の層は、この二つの上に立っている。

「賢く見える」と「できている」は違う

エージェントは、手元で動かすと見事に見えることがある。

曖昧な依頼を受け取り、必要そうな情報を探し、道具を呼び、文章を整えて返す。人間が横で見ていると、かなり高度なことをしているように見える。

しかし、デモで見栄えがよいことと、実際の仕事を安定してこなせることは違う。

一回の成功は、運がよかっただけかもしれない。問題が簡単だったのかもしれない。途中で間違えたのに、最後だけ偶然それらしくまとまったのかもしれない。人間が暗黙に助けていたのかもしれない。

普通のソフトウェアなら、入力と出力を比べればかなりのことが分かる。決まった入力に対して、決まった出力が返る。違っていれば失敗である。もちろん現実はもっと複雑だが、それでも「この入力ならこの結果」という形に落としやすい。

エージェントは少し違う。

エージェントは、途中にいくつもの判断を挟む。何を調べるか。どの順番で進めるか。どの道具を使うか。結果をどう解釈するか。失敗したときにやり直すか、別の方法に切り替えるか。

そのため、最後の答えだけを見て丸かバツかを付けても、肝心なことが見えない。

答えは合っているのに、途中で危ない近道をしていることがある。逆に、答えは外れていても、途中の方針はかなりよく、最後の一箇所だけで崩れていることもある。この二つは、直し方がまったく違う。

評価でまず見たいのは、点数ではない。

どこで道を間違えたのかである。

答えではなく「たどった道」を読む

ここで、前に扱った実行の記録が重要になる。

エージェントを評価するなら、最終的な答えだけでなく、そこへ至る道を読む必要がある。どんな判断をしたのか。何を調べたのか。どの道具を呼んだのか。返ってきた結果をどう扱ったのか。途中で方針を変えたのか。変えなかったのか。

評価の対象は、点ではなく線である。

同じ正解にも、いろいろな道で着く。堅実な道もあれば、危なっかしい道もある。たまたま正しい情報に当たっただけの道もある。途中の確認を飛ばしたのに、最後だけ自然な文章になったものもある。

人間が仕事を見るときも同じである。

新人に資料作成を任せたとする。完成した資料だけを見れば、一見まともかもしれない。しかし、参照した情報が古い。根拠の確認をしていない。重要な関係者に聞いていない。数字の意味を取り違えている。こうしたことが分かれば、次に同じ仕事を任せる判断は変わる。

エージェントでも同じことが起きる。

最後の文章だけを見ると、もっともらしく見える。しかし、途中の記録を読むと、調べるべき場所を調べていないことがある。最初の仮説に引きずられていることがある。道具の結果を読み間違えていることがある。失敗した呼び出しを成功したものとして扱っていることがある。

これを見ずに評価すると、直すべき場所を間違える。

文章の書き方を直すべきなのか。情報の探し方を直すべきなのか。手順を細かく分けるべきなのか。道具の戻り値をもっと検査すべきなのか。役割の境界を狭めるべきなのか。

答えだけでは、この判断ができない。

だから、エージェントの評価は、実行の記録を読むところから始まる。

評価の本質は、失敗を読むこと

評価と聞くと、立派な画面を思い浮かべやすい。

成功率の数字が並ぶ。折れ線が動く。分類ごとの集計が表示される。問題ごとに点数が付く。そうしたものは、あとで役に立つ。変化を追うには便利である。大きな傾向を見るにも必要になる。

しかし、最初に効くのは、もっと地味な作業である。

実際の出力を読む。途中の記録を読む。うまくいった例も読む。失敗した例はもっと読む。何件も読む。退屈でも読む。

ここを飛ばすと、評価は形だけになる。

一つのきれいな数字は、安心を与えてくれる。だが、その数字が何を見ているのか分からなければ、安心の根拠にはならない。数字がよくても、実際には重大な失敗を見逃しているかもしれない。数字が悪くても、実は直すべき場所が一箇所に集中しているだけかもしれない。

生の失敗は、数字よりも多くを教える。

たとえば、あるエージェントが調査の仕事で失敗したとする。最終出力だけを見れば、「事実誤認」としか言えないかもしれない。だが途中を読むと、失敗の姿はもっと具体的になる。

最初に古い情報を拾ったのかもしれない。新しい情報を見つけたのに、古いほうを優先したのかもしれない。根拠の弱い情報を、確定した事実として扱ったのかもしれない。調べる範囲を狭く取りすぎたのかもしれない。

どれも最終的には「間違った答え」になる。

しかし、原因は違う。

原因が違えば、評価の作り方も、改善の仕方も違う。

失敗を型に分ける

ただ読むだけでは足りない。

読みながら、どこで何を間違えたのかを書き留める必要がある。そして、それを束ねていく。似た失敗を同じ箱に入れていく。

情報を取り違えた。必要な手順を飛ばした。古い前提のまま進んだ。道具の使い方を誤った。役割からはみ出した。途中の失敗を検知しなかった。曖昧な依頼を確認せずに進めた。

こうして失敗の型が見えてくる。

この順番が大事である。

先に評価項目を決めるのではない。まず実例を読む。失敗を集める。型に分ける。その型を捕まえるために、評価を作る。

順番を逆にすると、見たいものだけを見る評価になりやすい。作り手が最初から想像していた失敗だけを測ることになる。しかし、本当に怖い失敗は、最初の想像から外れたところに出ることが多い。

また、十件ほど読んだだけでは足りない。

十件読むと、少し分かった気になる。だが、それはたいてい早すぎる。よくある失敗は見えるかもしれないが、少し条件が変わったときに出る失敗はまだ見えない。めったに起きないが致命的な失敗も見えない。

目安としては、少なくとも百件ほどは読みたい。

もちろん、仕事の種類や危険度によって変わる。百という数字に特別な意味があるわけではない。ただ、十数件で「だいたい分かった」と思うのは危ない。新しい失敗の型がほとんど出てこなくなるまで読む必要がある。

失敗の型が見えれば、評価は急に具体的になる。

「よい答えか」を見るのではなく、「古い情報に引きずられていないか」を見る。「役に立つか」を見るのではなく、「必要な確認手順を飛ばしていないか」を見る。「自然な文章か」を見るのではなく、「根拠のない断定をしていないか」を見る。

評価は、失敗の型から生まれる。

高すぎる合格率を疑う

評価を作ると、合格率が気になる。

ほとんど合格した。九割以上通った。満点に近い。そう聞くと、うまくいっているように思える。

しかし、エージェントの評価では、高すぎる合格率は警告でもある。

もちろん、本当にできている場合もある。簡単な仕事なら高くてよい。十分に鍛えられた範囲なら、安定して通ることもある。

だが、作り始めたばかりの評価でほとんど全部通るなら、まず疑ったほうがよい。問題が緩すぎるのではないか。実際の失敗を含んでいないのではないか。難しい分岐を避けているのではないか。最後の答えだけを浅く見ているのではないか。

本当に役に立つ評価は、システムの弱いところを突く。

だから、最初は七割くらいしか通らない評価のほうが、むしろ価値があることがある。そこには直すべきものが見えている。失敗の型を捕まえている。改善したときに、変化が分かる。

満点は、できている証拠とは限らない。

測れていない疑いでもある。

これは、人を責める話ではない。評価を作るときの自然な落とし穴である。作り手は、自分が作ったものに通ってほしい。すると無意識に、通りやすい問題を選んでしまう。曖昧な失敗を外してしまう。採点しにくい事例を避けてしまう。

だからこそ、生の失敗を先に読む必要がある。

評価は、希望ではなく、現実から作る。

自動の採点は、人の判断のあとに置く

件数が増えると、人が毎回読むのは続かない。

百件を読むだけでも大変である。千件、万件になれば、手作業だけでは回らない。そこで、採点そのものを別の仕組みに任せたくなる。出力を読み、よいか悪いかを判定させる。途中の記録を見て、失敗の種類を付けさせる。

これは有効である。

ただし、順番がある。

まず人が読む。人が失敗の型を作る。どこまでなら合格で、どこから失敗かを決める。そのうえで、自動の採点が人の判断とどれくらい合っているかを確かめる。

ここを飛ばすと、ずれた採点器ができる。

ずれた採点器は危ない。間違った失敗を失敗と呼び、重大な失敗を見逃す。しかも件数だけは大量に処理できるので、間違った安心を増やしてしまう。

自動で確かめやすい仕事もある。

正しい値がはっきりしている。必要な項目が決まっている。手順の有無を記録から確認できる。こうした仕事は、機械的に判定しやすい。

一方で、良し悪しが曖昧な仕事もある。

説明が分かりやすいか。判断が妥当か。読み手にとって十分か。危険な言い方を避けられているか。こうしたものは、先に人間が基準を作らなければ評価できない。基準が曖昧なまま自動化しても、曖昧さが速く広がるだけである。

自動化は、人の判断を置き換える魔法ではない。

人が作った基準を、より多くの件数に広げるための道具である。

評価は作る工程そのものになる

ここまで見ると、評価は最後の検査ではないことが分かる。

作る。動かす。出力を読む。途中の記録を読む。失敗を型に分ける。その型を捕まえる評価を作る。直す。もう一度読む。前よりよくなったかを見る。

この繰り返しが、エージェントを鍛える。

そして、この評価が成り立つためには、これまで積み上げてきた層が必要である。

途中が見えなければ、道を読めない。記録が残らなければ、あとから失敗を調べられない。道具の呼び出しが追えなければ、どこでつまずいたか分からない。何が正解かを決める仕組みがなければ、合格も失敗も言えない。

見える化、記憶、検証可能性、安全な境界。これらは、それぞれ別の機能に見える。だが評価の層から見ると、すべて土台である。

エージェントは、答えを返す機械ではない。

途中で判断し、調べ、試し、修正しながら進む実行体である。だから評価も、最後の答えだけを採点するものでは足りない。たどった道を読み、失敗を分類し、直すべき場所を見つけるものでなければならない。

本当にできているかを確かめるとは、そういうことである。

次回は、この評価を一度きりの作業にせず、開発の流れの中でどう回し続けるかを見ていく。