LLM評価の盲点：私たちはなぜ「行動」ではなく「知識」だけを見るのか？

• LLM評価はいまだに「SATの点数」にとどまっている — MMLU、HumanEval、SWE-benchはいずれも単一セッション・単一正解のパラダイムだ。実際のコーディングエージェントは複数セッションにまたがって作業し、ミスから学び、既存の慣習を読む。これは知識(knowledge)ではなく行動(behavior)の問題だ。

• 私たちは人を採用するとき、成績よりも「どう考えるか」を見る — LLM評価ではなぜそれをしないのか。今はすべてのモデルが90パーセンタイルを取る「GPA確認」の段階で止まっている。

• 同じバグを直してもアプローチはまったく異なる — Model Aは30秒でgrepしてパッチを当てる（プロトタイピング型）、Model Bは下位タスクに分解してから体系的に進める（アーキテクチャ型）、Model Cはgit logから先例を学んでから修正する（保守型）。3つともバグは直す。点数は同じだ。役割適合性はまったく異なる。

• 4つの行動観察次元の提案 — Decomposition（分解するか vs すぐ実行するか）、Approach（パターンを探すか vs 原理から推論するか）、Recovery（行き詰まったときに戦略を変えるか vs 押し切るか）、Consistency（似た問題に対して同じアプローチを示すか）。

知識評価 vs 行動評価

既存ベンチマーク	測定するもの	見落としているもの
MMLU	知識の記憶量	応用判断力、「知らないことの認知」
HumanEval	初回試行の合格率	デバッグ、反復、適応の過程
SWE-bench	パッチが通るかどうか	アプローチ経路、アーキテクチャ理解、クロスセッション学習

2026年、本当に必要な問い

コーディングエージェントがデモではなく実際のチームの道具になった今、私たちが投げるべき問いは「何点か」ではない:

• 「レガシー保守にはどのモデルが合うのか」
• 「ジュニアとのペアプログラミングに向くデバッグスタイルは何か」
• 「週単位で最も予測可能な行動を示すモデルは何か」

これはrole-fitの問いだ。採用の問いだ。私たちはまだSATの点数で答えようとしている。

フレームワークを完成形として提示してはいない。「私が間違っているなら訂正してほしい」という姿勢で、4つの仮定を明示的に開いたままコメントでの議論を促す。2026年4月のTang et al.による「In-Situ Behavioral Evaluation for LLM Fairness」論文も、似た方向性を示している。