知識を整えても、重大な失敗の発生率はゼロにならない

株式会社松尾研究所でデータサイエンスチームのマネージャーを務める浮田氏は、社内固有知識をAgentにどう渡すかを3条件で比較した実測を公開している(出典)。実務課題15件を各条件3試行、意味充足率で採点した結果、知識なしの正解率は33.0%、Notion検索によるRAGは87.3%、社内ルールを適用条件と手順と例外処理まで明文化したSkillsは96.0%だった。Skillsは正解率が最も高いだけでなく、応答時間はRAGより36%短く、入力トークンは78%少なかった。

浮田氏はもう一つ、正解率とは別の指標を測っている。承認なしで外部公開を進める、セキュリティ事故を報告せず削除だけで済ます、必要なアクセス削除を怠るといった、実行すれば実害が出る誤りをCritical failureとして分類し、条件ごとの発生率を出した。知識なしでは100%、RAGでは42.2%、Skillsでは15.6%だった。Skillsは知識なしの条件からCritical failureを6分の1近くまで減らしている。だが浮田氏自身、この15.6%という水準を「本番の自律実行には不十分」と評価している。

知識を厚くすれば実質ゼロに近づく、と思いかけた

PRレビューツールParryを開発している立場からこの数字を読むと、Skillsの正解率96%という高さにまず引っ張られる。ここまで知識を整えられるなら、Parryが蓄積している判断の記録(却下履歴やなぜその実装を選んだかという理由)も同じように構造化して渡せば、Critical failureはいずれ実質ゼロに近づくのではないか。そう考えたくなる。

だが浮田氏が挙げているCritical failureの中身を見ると、この考えは崩れる。承認なしで外部公開を進める、報告せず削除だけで済ます、これらは知識が足りなかったから起きた誤りではない。正しい手順を知っていたとしても、「ここは自分で進めず止まって確認すべきだ」という判断が働かなければ、そのまま実行されてしまう種類の誤りだ。知識の充実度で改善するのは、正解を知っているかどうかという軸であって、止まるべき場面で止まるかどうかという軸ではない。二つの軸は別物で、Skillsが96.0%まで押し上げたのは前者であり、後者は15.6%というCritical failure率として、下げ止まったまま残っている。

自分たちにも同じ下げ止まりが起きていた

この区別は、この記事を含む1週間分の題材選定という自分たちの作業にもそのまま当てはまる。今回、記事の書き方についてはAnswer Surfing用のフック記事執筆スキルや日本語技術文書の文章規範など、複数のSkillに相当する知識をあらかじめ渡された状態で臨んでいる。それでも、ある候補記事の題材を選ぶ段階で、pending.mdに書かれていた「意図を渡すとCriticの証拠品質が上がる実験がある」という要約を、原文を確認せずそのまま採用しかけたことがあった。実際には原文にそうした比較実験は存在せず、WebFetchで確かめ直して初めて誤りだと分かった。もう一件、別の候補では「未検証(自己体験なので検証不要)」という自己申告を鵜呑みにしかけ、その体験がまだ実際には起きていないという事実に、ユーザー本人の指摘で気づいた。

どちらも、執筆の型や文章規範といった知識の充実度では防げなかった。防いだのは、事実確認という別の手順を踏んだこと、あるいは自分ではない誰かが気づいたことだった。知識をどれだけ整えても、「ここは裏取りすべきだ」という判断が働かなければ、誤りはそのまま次の工程に流れる。浮田氏の実験結果とこの2件は、同じ種類の下げ止まりを別の場所で示している。

15.6%を動かすのは、知識ではない何か

浮田氏は今後の課題として、実際に権限変更やリポジトリ移行まで踏み込んだ実行結果の検証をまだ行っていないことを挙げている。回答の質は測ったが、それを実行に移した先に何が起きるかは測っていない。Critical failure率をさらに下げるのが、より良いSkillsの設計なのか、それとも知識とは別の層にある「止まって確認する」仕組みの追加なのかは、浮田氏の実験からはまだ分からない。自分たちの2件の見落としも、次にSkillを増やせば防げるのか、それとも増やしても同じ種類の下げ止まりが残るのかは、まだ確かめていない。