#評価

率直に、かなり気持ち悪さのある話だと思った。AIの安全性をチェックする側が、チェックされる側からお金を受け取る。しかも当事者がそれを「本来は違う形であるべきだ」と同じ発表文の中で認めている。そこまで分かっていて、なおその形で進めるしかないのか、という後味の悪さが残る。 ただ、完全に机上のきれいごとで済まないのも分かる。外部の独立評価って、実際にやろうとすると人も金も足りない。専門家を集めて、モデル内部に近いところまで入ってもらうには、かなり重いコストがかかるはずだ。記事にあるように、非営利団体や政府資金の受け皿がまだないなら、企業が先に金を出すしかない、というのは現実としては理解できる。だからこそ厄介で、理想と実装の間に大きな穴が空いているのだと思う。 いちばん引っかかったのは、「独立」の意味がどこまで本当に独立なのか、という点だ。評価者に社員並みのアクセスを与えるのは、それ自体は強い。外から遠く眺めるだけより、ずっと踏み込める。でも報告義務や公開のルールが未整備なら、その結果は結局、企業の内部事情に吸い込まれてしまうかもしれない。危ない発見があっても、製品を売る側の都合で止まるのでは

いちばん面白いのは、これまでの分析ツールが見ていた「人間のクリック」ではなく、AIエージェントに渡した仕事の実行過程を測ろうとしているところだと思った。ユーザーはもうUIを触らず、ClaudeやChatGPTの中で用事を済ませる。そうなると、従来のプロダクト分析はかなり手が届かない。アクセス解析を入れているのに、肝心の利用実態が見えない、という少し不気味な空白がある。Armatureはそこを埋めにいっている。 読んでいて引っかかったのは、「成功したかどうか」だけでなく、「なぜ失敗したか」をセッション単位で再構成する、という発想の強さだ。APIが200 OKを返していても、ユーザーは目的を果たせていないことがある。人間向けのWebプロダクトでもよくある話だけれど、agentic workflow ではそれがさらに見えにくい。しかも、agent の thinking や tool call の並びを見せることで、単なるログではなく“体験”として追えるようにしている。ここは便利そうだし、同時にかなり怖くもある。便利さの裏で、どこまでを記録してよいのかという線引きが難しいからだ。 もう一つ、e

読んでまず思ったのは、いちばん怖いのはモデルの失敗じゃなくて、失敗を数えている側の思い込みだな、ということだった。しかもこの話はかなり実務っぽい。LLM の eval って、つい「点が出た」「下がった」で安心してしまうけれど、実際には“どの失敗を失敗と呼んでいるのか”が曖昧だと、数字がきれいなほど危ない。 特に引っかかったのは、multi-step な作業を single-step の問題として採点してしまう部分だった。たとえば thread_ts のように、最初の操作をしないと次の引数が取れないものを、最初から完成形の入力がある前提で評価してしまう。これ、言われてみれば当たり前なのに、ベンチマークを作る側はけっこうやりがちだと思う。モデルが「まだ足りない」と判断して保留したのに、採点側はそれを不正解にしてしまう。つまり、慎重さが減点される。 もうひとつ面白かったのは、静的なチェックと LLM の eval が、別々の方法なのに同じところでつまずく、というくだりだ。名前の紛らわしい tool 同士があると、モデルも迷うし、静的ルールでも危ないと出る。ここはかなり気持ちいい発見で、安い静