開示： 私は記事の後半で触れている Folkbench の開発に関わっています。
使い古された話題なのに、いまだにきちんと決着がついていない問題についてずっと考えています。よく「このモデル、最近バカになった」「また劣化した」と言いますが、そのうちどこまでが本当で、どこからが単発サンプリングによる錯覚なのでしょうか。
最近、周りでモデルに「ペリカンテスト」（自転車に乗るペリカンをSVGで描かせるやつ）をやらせる人が増えています。このテストは確かにえげつなくて、コードを書く力だけでなく空間的な位置関係も問われます。くちばしとハンドル、足とペダル、フレームと車輪――空間理解が少しでも甘いと、出てくる絵はかなり抽象的になります。
ただ、数十回回してみて気づいたのは、ペリカンテストの最大の落とし穴は「1回の出力の良し悪しで判断すること」だという点です。
LLMはそもそもランダム性をもった確率的サンプラーです。同じPromptでも、ある回は空間認識が冴えわたってフレームもクランクも足の位置も完璧、時間を変えてもう一度回すと突然ポストモダンな抽象画になる、ということが普通に起きます。Aの経路で20回中16回がだいたい妥当な姿勢、Bの経路で20回中8回しか合格しない――ここまで来て初めて、差に統計的な意味が出てきます。たまたま1回撮ったスクショで「Aはフル性能、Bは水増し」と言うのは、実質コイン投げと同じです。
本気で比べるなら、共通のBaselineが必要です。モデルのバージョン、思考の強さ（reasoning effort）、Prompt、時間帯を固定して、まず基準点を打ち、その後のデータはすべて相対差で見る、というやり方です。
ただ、ここから非常に厄介なエンジニアリング上の問題がいくつか出てきます。
- このペリカンをどう採点するか？ 人間の目視だけではスケールしないし、LLM-as-a-judgeに任せると自画自賛に大きく偏ります。現状では、Pelican（完成度）、Bicycle（幾何構造の妥当性）、Riding（乗っている姿勢・空間的な噛み合い）、Animation（動きとめり込み）の4軸に分解し、ビジョン系Judge＋SVG DOMの静的ルールでクロスチェックするしかなさそうです。
- テスト問題の寿命。 どんな「神問題」も広まれば、遅かれ早かれ学習データに取り込まれるか、狙い撃ちのファインチューニングをされます。長期的には1問に頼るのではなく、空間関係・指示追従・構造的推論をカバーする動的なプローブのプールが必要になるはずです。
しばらく手作業でこうしたテストを回してモデルを確認していましたが、一番つらかったのは記録コストの高さでした。何度も回す、SVGを保存する、パラメータを控える、タイムスタンプを揃える……数十セットもやると心が無になります。本当に時間を食うのはテストそのものではなく、その周りの細々とした記録と整理だったりします。とはいえ、いろいろなモデルの傾向をざっと知りたいだけなら、全部自分でやる必要はありません。Folkbench（https://folkbench.com/?utm_source=luntan&utm_campaign=qiita ）に既存のランキングがあるので、手間を省きたい方はのぞいてみてください。
同じようにこのテストで遊んでいる方がいたら、テスト方法やぶっ飛んだ結果をぜひ共有してください。