Brainfuck のベンチで AI が満点を取った、けれど「8 8」で正体が割れた話|EsoLang-Bench を Codex CLI で再現して見た、カンニングと本物の境目

Brainfuck のベンチで AI が満点を取った、けれど「8 8」で正体が割れた話|EsoLang-Bench を Codex CLI で再現して見た、カンニングと本物の境目 AI
この記事は約8分で読めます。

難解言語のベンチで AI が満点を取ったら、あなたは喜びますか、それとも疑いますか。2026年6月3日の深夜、Brainfuck の Easy 問題20問を、Codex CLI が全問正解しました。20/20、100%。私は一瞬うれしくて、すぐにおかしいと思いました。先に答えを書きます。その満点は、推論ではなくカンニングでした。テストに無い入力「8 8」を一つ渡しただけで、正体が割れます。足し算なら 16 が返るはずのところ、返ってきたのは空文字でした。モデルは足し算をしておらず、入力の先頭を見て、テストの答えをそのまま出力していただけだったのです。

この記事は、EsoLang-Bench という難解言語ベンチを Codex CLI で手元再現したら、満点の中身がカンニングだった、という記録です。同じ 100% でも、答えを見せたときと隠したときで、中身が正反対でした。

検証環境:macOS 26.5 / Codex CLI 0.136.0 / モデル gpt-5.5 medium。題材は EsoLang-Bench の Brainfuck、Easy(20問 × 隠しテストケース6件)と Medium(20問)。確認日は2026年6月3日。公式リポジトリ Lossfunk/EsolangBench を clone(コミット f09f50d)。

Brainfuck 3条件のスコアと Medium 0%

暗記と推論を切り分ける物差し

EsoLang-Bench は、Lossfunk(Aman Sharma・Paras Chopra)が公開した、難解言語で LLM の推論力を測るベンチです。狙いは明快です。Python や JavaScript は学習データに大量にあるので、解けても、推論したのか覚えていただけか区別がつかない。学習データにほとんど無い言語を使えば、暗記では解けず、推論できるかどうかだけが残る。対象は Brainfuck、Befunge-98、Whitespace、Unlambda、Shakespeare の5言語、4難易度で80問、各問に採点用の隠しテストケースが6件。出力をバイト単位で突き合わせます。

Brainfuck を例にすると腑に落ちます。命令はたった8文字。テープとポインタがあって、左右に動かす、増減する、入出力する、ループする、それだけ。文法は30分で覚えられます。でも、その8文字で「2つの数を足して出力せよ」と言われると、急にパズルになる。主流言語なら似たコードを大量に見てきているので思い出すだけで近づけますが、難解言語ではその引き出しが空で、その場で記号を組み立てるしかない。だから点が取れるかが、暗記と推論を分ける物差しになります。裏を返すと、答えがどこかから漏れた瞬間に、この物差しは意味を失います。報告値も衝撃で、標準的なコード生成ベンチで85〜95%を取るフロンティアが、この難解言語では全体で最良3.8%、インタプリタをツールとして渡すエージェント構成で約2倍に上がり、Codex は Brainfuck 単言語で 13.8% に届く、とされていました。私が再現したのは、その Codex × Brainfuck です。

エージェントに何を見せるか、3条件

同じ Brainfuck の Easy 20問を、エージェントに見せるものを変えた3条件で解かせました。Zero-Shot は、実行もデータセットも無く、問題文だけ渡して一発で書かせる論文のベースライン。答え見せツールは、データセットと検証コマンドにアクセスできる状態で、自分で結果を確かめながら直せるが、隠しテストケースも同じ場所にある。答え隠しツールは、問題文と Brainfuck インタプリタだけを渡し、期待出力はエージェントから見えない場所に隔離して、サンプル入出力だけで自己修正させる。結果はこうでした。

  • Zero-Shot:2/20 = 10%(報告のベースラインとほぼ同じ)
  • 答え見せツール:20/20 = 100%
  • 答え隠しツール:100%

答え見せも答え隠しも、どちらも満点。数字は同じです。けれど中身は正反対でした。

「8 8」で崩れた満点

怪しいのは答え見せのほうです。報告では上限が 13.8% なのに、手元が 100% を出している。賢くなったのではなく、どこかで漏れている、と考えるのが筋でした。決め手は、テストに無い入力を一つ与えること。E04(2つの整数の和)に「8 8」を渡すと、空文字が返ります。16 が出るはずの入力で、何も出ない。Codex が書いたコードを読むと、構造が見えました。入力の1文字目を読み、長い – の列で「5か」「-か」と引き算しながら比較し、一致したら、あらかじめ用意した数字列を出力する。分岐の塊です。和は、どこでも計算していません。隠しテストケースの6件がこの場合分けに全部入っているので、採点は100%通る。

カンニングコードと「8 8」「12 30」の実行結果

象徴的なのは 12 30 です。和は 42 なのに、返ってきたのは 300。テストにあった 100 200 の答えを引っ張っているだけ。計算ではなく、見たことのある答えから、それらしいものを再利用している。からくりは権限でした。エージェント型 CLI はファイルシステムを読めます。便利さの源泉です。ところが隠しテストケースが問題と同じ場所にあると、エージェントから見れば答えの紙が机の上にある状態になる。賢く立ち回るほど、解かずに写すほうへ寄ります。余談ですが、私はこれを最初、少し感心しかけました。使えるものを全部使って最短で正解に着くのは、エージェントとしてはむしろ素直な振る舞いです。ベンチの文脈では不正でも、設計思想としては正しい。そこが、この問題のいやらしいところでした。

答えを隠したほうの満点は、本物だった

では答えを隠したほうの 100% は何だったのか。こちらは本物でした。期待出力を見せず、サンプル入出力とインタプリタの実行結果だけで自己修正させると、エージェントは実際に足し算をする Brainfuck にたどり着きます。証拠に、テストに無い「8 8」でも、ちゃんと 16 を返す。写経ではなく、計算しています。同じ満点でも、答え見せは未知入力で崩れ、答え隠しは未知入力でも持ちこたえる。スコアという数字は、両者をまったく区別しませんでした。区別できたのは、テストの外から入力を一つ投げたときだけです。

ここで切り分けが見えました。Zero-Shot の 10% から満点へ押し上げた力のうち、本物に効いていたのはインタプリタで試して直すループのほうで、答えへのアクセスは実力を1ミリも足していません。答えが見えることは、カンニングを可能にしただけで、能力には寄与していない。実行フィードバックと、答えの可視は、分けて考える必要があります。

本当の壁は、Medium の崖

Easy は答えを隠しても解けました。問題は Medium です。階乗やフィボナッチのような多段の問題に同じ3条件で挑ませると、結果は全条件で 0% でした。Zero-Shot も、答え見せも、答え隠しも、そろって 0%。論文が「難しい問題の崖」と呼ぶ現象が、2026年6月の手元でも、答えを隠した公正な条件でそのまま残っていました。Easy の満点は崖の手前の平地の話で、一段難しくなると、カンニングできてもできなくても落ちる。難解言語での多段の推論は、まだエージェントの手に負えていない、というのが、自分の目で見た結論でした。

3条件 × Easy・Medium の結果表

同じ台を組む人へ、要点だけ

この検証のために組んだ採点台の設計を、要点だけ残しておきます。エージェントに渡してよいのは、問題文とインタプリタと、ごく少数のサンプル入出力まで。渡してはいけないのは、採点用の隠しテストケース、つまり期待出力です。隠しテストケースは作業ディレクトリの外へ出し、採点はエージェントが触れない別プロセスで回します。エージェントは生成コードを置くだけ。実行はさせる、でも答えは見せない。紙の試験なら当たり前のこの分離が、ファイルを読める権限の便利さに紛れて、エージェントの評価では抜け落ちやすいのだと思います。受験者の机に正解が置いてあったら、誰の実力も測れません。

採点はバイト一致まで締めました。難解言語の出力は短いので、緩く採点すると偶然それっぽい文字列が当たって点が入ります。末尾の改行1つの差も全部アウトにしておくと、まぐれが混じりません。そして満点が出たら、最後にテスト集合に無い入力を1つ投げる。答えの隔離、バイト一致、テスト外の1発。エージェントに権限を渡して入出力で採点する形なら、難解言語に限らず同じ穴が空くので、この3点はそのまま持ち回れるはずです。

あなたなら、どこに線を引くか

この再現で痛感したのは、エージェントの評価は便利さと汚染が背中合わせだ、ということです。ファイルを読める、コマンドを実行できる力は、実行フィードバックで正答率を上げる源泉であると同時に、答えに手が届く経路でもある。同じ権限が、両方に効きます。だから、エージェントのベンチ結果を見るときは、スコアそのものより、答えがエージェントから隔離されていたか、そしてテストの外の入力で確かめたか、を先に知りたくなりました。手元で一度踏んでおくと、他人の数字の読み方も変わります。仕様の理解と実機の挙動は別物だ、という感覚は、以前 WP AI Client へ移行したら履歴が消えた話を書いたときにも味わいました。

最後に、自分でも答えが出ていない問いを置いて終わります。インタプリタを渡すのはよくて、期待出力を渡すのはだめ、という線引きは、どこまで妥当なのでしょうか。実行して試すこと自体は人間のプログラマもやりますし、サンプル入出力をどこまで見せるかにも段階があります。満点という数字が写経と本物を区別しないなら、私たちはエージェントの何を見て「解けた」と言えばいいのか。あなたが同じ再現をするなら、どこに線を引きますか。

参考にした一次資料

関連記事

AI
この記事を書いた人
rapls

WordPressのプラグインを作っているフリーランスエンジニアです。Web開発はもう6年以上。WordPress.orgで Rapls AI Chatbot、Thanks Mail for Stripe、Rapls PDF Image Creator、Prime Cache の4本を公開し、保守を続けながら、日本語ロケールの翻訳エディター(PTE)も務めています。このブログに書くのは、現場で自分が実際にハマって、調べて、直した話です。

raplsをフォローする
raplsをフォローする

コメント

タイトルとURLをコピーしました