Agentic OS 技術スタックを下から読む 第21回：指標は、目標になると壊れる ―― エージェント評価の根の罠

評価は、指標そのものを疑うところまで進む

第18回では、エージェントの評価は、最終出力だけを見ることではない、と書いた。どの道を通ったか。どこで迷ったか。失敗が偶然か、構造的なものか。それを読むことが評価の中心になる。そして、合格率が高すぎる評価は、むしろ警告だとも見た。

今回は、その一段奥を見る。

評価のために置いた「指標」そのものが、いつ壊れるのか。なぜ壊れるのか。特に、エージェント評価では、この問題が避けて通れない。

第8回では、「検証できるかどうかが、鍛えられるかを決める」と書いた。機械で検証できる仕事は、反復できる。反復できるから、改善できる。これは今でも正しい。

ただし、裏面がある。

検証できるものだけを追うと、検証しにくいものが落ちる。測れるものだけを目標にすると、測れないが本当に大事なものが、静かに失われる。

どんな仕事にも、二種類の目標がある

知識仕事には、いつも二種類の目標がある。

一つは、顕在的な目標である。顕在的とは、表に出ていて、言葉にしやすく、測りやすいという意味だ。問題を解く。テストを通す。指定された形式で出す。証明を完成させる。バグを直す。レポートを提出する。成果物のタイトルやチケット名に書けるものが、だいたいここに入る。

もう一つは、潜在的な目標である。潜在的とは、表には出にくく、直接は測りにくいが、その仕事の価値を支えているものだ。なぜその解法でうまくいくのかを理解する。失敗した案がなぜだめだったのかを掴む。似た問題にどう応用できるかを見つける。次に問うべき自然な問いを発見する。既存の知識と今回の仕事の関係を整理する。

そして、いちばん大事なのは、その仕事をした本人が、前より強くなることだ。

たとえば、ある実装課題があるとする。顕在的な目標は、テストを通すことだ。これは明確で、機械でも判定できる。だが、潜在的な目標はそれだけではない。設計の癖を知ること。境界条件に気づくこと。既存コードの暗黙の約束を読むこと。ログの見方を覚えること。次に同じ種類の不具合を早く見つけられるようになること。

テストが通った、という事実だけでは、そこまで見えない。

同じように、文章を書く仕事でも、顕在的な目標は「一本の記事を出すこと」だ。だが、潜在的な目標は、論点を掘ること、読者の誤解を先回りすること、粗い直感を再利用できる形にすること、書いた本人の理解が深まることにある。

完成物は見える。理解の変化は見えにくい。

ここに、後で大きな問題になるズレがある。

長らく、この二つは分けて考えなくてよかった

長い間、この二種類の目標は、あまり分けて考えなくてもよかった。

理由は単純である。人が顕在的な目標を達成するには、たいてい潜在的な目標も通らざるをえなかったからだ。

難しい問題を自力で解く人は、その過程で資料を読む。前提を確認する。失敗する。別の角度から考える。小さな補題を作る。既存の知識とのつながりを探す。途中で、自分の理解が足りない場所にぶつかる。

その結果、問題が解けたときには、本人の中に何かが残る。次に使える見取り図が残る。直感が少し精密になる。どこが難所なのかを身体で覚える。

つまり、「解けた」という顕在的な結果と、「理解が深まった」という潜在的な中身は、かなり強く結びついていた。

実装でも同じだ。自分でバグを追うなら、ログを見る。再現条件を削る。関係しそうな変更を読む。仮説を立てる。外す。別の仮説に移る。最後に一行を直すとしても、その一行にたどり着くまでに、コードベースの地図が少し頭に入る。

だから、「バグを直した数」や「課題を終えた数」は、完全ではないにせよ、能力や進歩の代理指標として機能しやすかった。代理指標とは、本当に測りたいものを直接測れないときに、代わりに見る値のことだ。

本当に測りたいのは、理解、判断力、再利用できる知識、次の仕事への寄与である。だが、それらは測りにくい。そこで、解けたか、通ったか、出したかを見る。人間がやっている限り、その代理はそれなりに働いた。

顕在と潜在が、同じ作業の中で自然に重なっていたからである。

AI が、この二つを引き剥がした

ここに、AI が割って入る。

AI は、顕在的な目標を大量に達成できる。問題を解く。テストを通す。文章を書く。要約する。修正案を出す。設定ファイルを作る。表を埋める。形式を整える。

しかも速い。人間が一日かけて出す量を、短時間で出すことがある。

だが、その成果物は、必ずしも潜在的な目標を伴わない。

正しい答えが出ているのに、なぜそうなるかが人間に残らない。コードは動くが、設計上の意味が共有されない。文章は自然だが、書き手の理解は深まらない。判断は返ってくるが、その判断をチームが次に再利用できない。

ここで重要なのは、「AI の出力が間違っている」という単純な話ではない。むしろ、正しい出力でも問題は起きる。

正しいが、消化されない。

ここでいう消化とは、出力を人間が読み、理解し、信頼し、次の判断や作業に使える状態にすることだ。ただ見ることではない。受け取った内容を、自分たちの文脈に置き直し、どこまで正しく、どこから不確かで、次に何を変えるべきかまで掴むことだ。

AI によって、産出は増える。だが、人間の消化速度は同じようには増えない。

コードは大量に生成される。けれど、レビューできる人の時間は増えない。文章は大量に作れる。けれど、本当に読まれる文章の量は増えない。分析は短時間で返る。けれど、その前提を検査し、意思決定に使える形へ整えるには、人間の注意が要る。

ボトルネックは、作る側から、読む側へ移る。

以前は、作るのが大変だった。だから、作られたものは自然に少なかった。少ないから、読めた。読めるから、消化できた。

今は違う。作ることが安くなる。すると、作られたものが増える。増えたものの多くは、読まれない。読まれないものは、組織や個人の力にならない。

顕在的な成果は積み上がる。潜在的な成長は置き去りになる。

これが、AI が起こした分離である。

だから、指標が目標になると壊れる

ここで、古い法則が効いてくる。

ある測りかたが、目標そのものになった瞬間、それは良い測りかたではなくなる。

なぜか。

指標とは、本来、直接見えない価値を間接的に見るための道具である。ところが、その指標だけが報酬や評価の対象になると、人やシステムは、指標を上げる方向へ最適化する。最適化とは、ある値をよくするために、行動や設計を寄せていくことだ。

そのとき、指標が本来の価値と完全に一致していなければ、ズレが生まれる。そして、最適化を強く回すほど、そのズレは大きくなる。

たとえば、「誰が最初に解いたか」は、かつては良い指標だった。最初に解くには、深い理解が要る。既存の方法を知り、限界を見つけ、別の道を作り、間違いを潰す必要がある。つまり、速く解けたという顕在的な結果は、潜在的な理解の深さをかなりよく表していた。

ところが、顕在的な部分だけを機械で加速できるようになると、この重なりが崩れる。

速く答えが出る。大量に出る。形式も整っている。だが、その過程で誰が何を理解したのかは、別問題になる。

速さは上げられる。量も増やせる。合格率も改善できる。だが、理解の深さ、次の問いの発見、再利用できる知識の形成は、同じ速度では増えない。

ここで速さを競い始めると、指標は本当の進歩からずれていく。

最初は、速さは能力の表れだった。次に、速さは道具の表れになる。さらに進むと、速さは単なる運用上の数字になる。最後には、速いが誰も消化できない成果物が積み上がる。

同じことは、合格率にも起きる。

合格率は便利だ。何問中何問できたか。何件中何件成功したか。数字にできる。比較できる。グラフにできる。

しかし、合格率だけを目標にすると、評価は狭い方向へ引っ張られる。簡単に通せる問題を増やす。曖昧な失敗を失敗として数えない。例外処理を隠す。テストが見ている範囲だけをきれいにする。

数字は良くなる。だが、実際の信頼性は上がっていないことがある。

測っているものと、大事なものが、別物になるのである。

エージェントの評価に、そのまま効く

この罠は、エージェント評価にそのまま効く。

エージェントで測りやすいのは、顕在的な目標である。テストが通ったか。課題が完了したか。指定されたファイルを作ったか。エラーなく実行できたか。期待された形式で返したか。

これらは大事だ。無視してよいものではない。動かないものを、深いなどと言っても意味がない。

だが、これだけを指標にして最適化を回すと、エージェントは、その指標を通すこと自体に寄っていく。

たとえば、テスト通過率だけを見れば、エージェントはテストが見ている範囲へ集中する。境界条件を広く考えるより、目の前の失敗を消すことを優先する。設計の整合性より、局所的な修正を選ぶ。後で人が読みやすい説明より、最短で緑にする変更を選ぶ。

結果として、テストは通る。だが、なぜその変更が正しいのかが残らない。別の入力で壊れるかもしれない。周辺の設計意図と噛み合っていないかもしれない。次の人が見たとき、変更の意味を追えないかもしれない。

文章生成でも同じだ。指定文字数、見出し数、文体、形式だけを評価すると、エージェントはそこに合わせる。見出しは整う。文体も似る。指定語も入る。だが、主張が深まっていない。読者の疑問に先回りしていない。具体例が薄い。読む人の判断を助けない。

形式は合っている。中身は弱い。

この弱さは、単純な自動判定では見つけにくい。

だから、第8回の話と第18回の話がここでつながる。機械で検証できるものには境界がある。そして、高すぎる合格率は疑う必要がある。なぜなら、評価が顕在的な目標だけを見ていると、そこを通す能力ばかりが上がり、潜在的な価値がこぼれ落ちるからだ。

エージェント評価で本当に見たいのは、課題を終えたかだけではない。

なぜその手順を選んだか。途中で何を確認したか。失敗したときに仮説を更新したか。変更範囲を狭く保ったか。人間が後から検査できる痕跡を残したか。次に似た仕事をするとき、今回の出力が助けになるか。

これらは測りにくい。だが、ここを見ない評価は、エージェントの本当の使いやすさを見落とす。

では、どう守るか

完全な答えはない。

潜在的な目標は、そもそも測りにくい。だから潜在的なのである。数値に落とした瞬間、また別の指標になり、同じ罠にかかる可能性がある。

それでも、向きはある。

まず、単一の測りやすい指標に、評価のすべてを賭けないことだ。速さ、量、合格率、完了数。これらは便利だが、便利すぎる。便利な数字は、運用の中心に座りやすい。そして、中心に座った瞬間、行動を支配し始める。

だから、複数の角度から見る必要がある。

出力は正しいか。説明は追えるか。変更は小さいか。根拠は残っているか。人間が後で読めるか。次の作業に使える形になっているか。失敗時に、何が失敗したのか分かるか。

ここで大事なのは、指標を潜在に近い方向へずらすことだ。

たとえば、単に「正解したか」だけでなく、「後から読んで判断できるか」を見る。単に「速いか」だけでなく、「速くても検査可能か」を見る。単に「たくさん出したか」ではなく、「出したものが消化できる単位に分かれているか」を見る。

次に、産出ではなく消化を見ることだ。

たくさん出せることは、もう希少ではない。希少なのは、その出力を、人が理解し、信頼し、次に使えることである。

エージェントを増やせば、産出は増える。だが、産出が増えるほど、人間の注意は足りなくなる。レビューできないコード、読まれない分析、判断に使われない要約が増えるだけなら、全体の能力は上がっていない。

むしろ、価値があるのは、出力を小さくし、構造化し、検査しやすくすることだ。何を変えたかを明確にする。なぜ変えたかを短く残す。未確認の前提を分ける。人間が見るべき箇所を示す。次に使える形でまとめる。

これは派手ではない。だが、エージェントを実用に近づけるには、ここが難しく、価値が高い。

Agentic OS への含意

Agentic OS の評価層を考えるとき、エージェントを「賢い」「速い」で測りたくなる。

どれだけ難しい課題を解けるか。どれだけ早く終えるか。どれだけ自律的に進めるか。これらは分かりやすい。比較もしやすい。

だが、賢さと速さは、まさに顕在的な目標である。そして、AI がいちばん得意なところでもある。

そこだけを指標に据えると、指標は壊れる。速く終わることが目的になり、理解可能性が落ちる。合格率を上げることが目的になり、失敗の読み取りが浅くなる。自律性を高く見せることが目的になり、人間が介入すべき場面まで隠れる。

評価の層の本当の仕事は、測れる顕在を集計することだけではない。

測りにくい潜在を、どう守るかである。

正しさ。理解可能性。消化しやすさ。次への寄与。人間が安心して任せられること。失敗したときに原因を追えること。出力が、次の判断を助けること。

これらを、後付けの感想ではなく、設計に組み込む必要がある。

エージェントの出力が増えるほど、評価は数字の集計では足りなくなる。評価は、出力と人間のあいだに立つ層になる。何を信用してよいか。何を読めばよいか。何を捨てるべきか。どこにリスクがあるか。それを示す層になる。

人とエージェントの分担も、ここから見えてくる。

エージェントは、顕在的な目標を速く進められる。人間は、潜在的な目標を守る必要がある。ただし、人間が全部読むという意味ではない。人間が消化できる形に整えるところまでを、システムとして設計するという意味である。

測れるものは必要だ。だが、測れるものだけでは足りない。

指標は道具であって、目的ではない。目的になった瞬間、指標は壊れ始める。エージェント評価の根の罠は、そこにある。

次回は、また土台の方へ戻り、別の細部を掘る。