EsoLang-Bench は、LLM がコーディング能力で見せる高い成績は訓練データの暗記に支えられているだけで、真の推論能力ではないのではないかという疑いを検証するベンチマークだ。訓練データが Python の 1,000〜100,000 分の 1 しか存在しない Befunge や Brainfuck のような、書くのも読むのも困難な難解プログラミング言語 (esoteric language, esolang) でコードを書かせることで、暗記では対処できない状況を作り出している。80 問を 4 段階の難度に分け、5 つの esolang でコードを生成、正誤を判定する。
結果、Python では正答率 90% 近くに達するモデル・問題でも、esolang では数パーセントまで悪化した。よって、今のLLMの見かけのコーディング能力は過大評価されている、という主張をしている。
公開されている結果を見ると、最高性能の GPT-5.2 でも全体正答率は 3.8%。Medium 以上の難度の問題はすべてのモデル・すべての設定で正答率 0% であり、成功は Easy 問題に限られている。extra-hard に至っては完全に手つかずという扱いだ。
このベンチを見た最初の印象は、本当に今の高性能なLLMが esolang 相手とは言え、こんなに惨敗するだろうか、というものだった。
なので自分でも試してみることにした。言語は esolang の中で個人的に好きな Befunge だ。Befunge は2次元のグリッド上に命令を配置する、カルネージハート的な言語で、例えば Hello World は以下だ。面妖だろう。
v @_ v >0"!dlroW"v v :# < >" ,olleH" v ^ <
この面妖な言語に、GPT-5.4 (medium) の Codex で挑む。Befunge-93 ベースの node.js 上で動くインタプリタを使ったので、EsoLang-Bench で使われた Befunge-98 と厳密には異なるが、大まかな難度は変わらないだろう。（93と98のメモリの扱いの違いを考えると、ちゃんと Befunge-98 に沿ったインタプリタを使った方が良いとは思う）
この環境で、extra-hard の X01 Prime Factorization （素因数分解）のコードを Befunge で書かせてみると、正しく動作するコードが得られた。X12 Least Common Multiple （最小公倍数）でも試したが、こちらも動作した。
もちろん1回の試行で出たものではない。最初のコードをインタプリタにかけ、その結果うまく動かなかった場合は、その結果を踏まえてデバッグし再度動かしてみるという試行を Codex が何回か繰り返した結果得られたものだ。Codex の出力が壊れていて、人間が指摘して直させることもあった。
一方、論文の公式結果における試行プロセスはこれとは異なる。論文には self-scaffolding について次の記述がある。
Self-Scaffolding: An iterative approach where the model generates code, receives interpreter feedback ... and refines its solution for up to 5 iterations.
README にも同様に書かれている。
All iterative regimes ... run up to 5 attempts per problem
つまり、コード生成→インタプリタ実行→結果をプロンプトに戻す→再生成、という完全自動のループが最大 5 回だけ許されている。人間のフィードバックも外部ツールの使用もなく、1 回の反復につき LLM 呼び出し 1 回のみ。今回の試行のように人間の介入による修正はしない。
モデルも GPT-5.2 ベースであり、今回の試行と直接の比較はできない。ただ、「extra-hard は 0%」という数字を「その難度帯は今の LLM では本質的に不可能である」とまで読む必要はなさそうだ。
実際、論文自身の結果でも、ツールアクセスのある agentic 環境では成績が大きく変わる。Codex が Brainfuck で 13.8%、Claude Code が 12.5% を達成しており、非 agentic の最良結果（GPT-5.2 Self-Scaffolding の 6.2%）の約 2 倍だ。
失敗の中身にも偏りがある。サイトの Error Analysis によると、Befunge-98 のエラーの 93.4% は runtime エラー、主に無限ループだ。モデルは Befunge の命令セットを概ね理解しているが、2D グリッド上に制御フローを正しく配置することに失敗している。一方で Brainfuck では 83.9% が logic エラー、つまり構文は正しいが出力が合わないという結果であり、言語ごとに壊れ方が違う。一律な推論能力の不足とは言えない。
LLM に実装をさせてみて、この壊れ方の違いはなんとなく実感できた。Befunge ではアルゴリズムそのものよりも、グリッド配置の整合性を保つのが難しい。空行の行数、分岐の位置、戻り経路など、些細に見える差で全体が壊れる。最小公倍数の実装では、余計な 1 文字の混入や、空行を削ったことによる座標のずれなどで実行不能になった。問題を理解していないから壊れるのではなく、言語の表現があまりに不親切だから壊れたのであって、人間がやっても同じように壊しそうだ。
結局、EsoLang-Bench が測っているのは、昨今のAIコーディングエージェントを使ったプログラミング能力ではないように思える。どちらかというと、壊れやすい表現系で事故を避ける能力、乏しいフィードバックから自力で修正する能力、厳しく制限された探索回数の中で収束させる能力、それらの複合体だ。
なので、LLMはWebのサンプルコードを見ているだけ、それ以外はてんでダメ、みたいな読み取り方をするのはあまり良くない。Python コードなら複雑なロジックも一撃で作れる、みたいな LLM の特殊能力を、一般的な能力と過大評価してはいけない、くらいのトーンで読みたいところだ。
