GPT-5の凄い能力～論文を読ませて応用課題が解けるようになった……と思ったけど、Gemini 2.5 Proも解けるようになっていた件

はじめに

こんばんは。GPT-5がリリースされてはや数日。ニュース記事に掲載されたうたい文句はともかく、好評よりはEQの性能低下によるあれこれ（#keep4o騒動参照）や、純粋な意味でそこまで性能が上がっていないのでは（むしろ低下した部分も大きいのでは）といった声もよく見聞きする気がします。

主観ではありますが、#keep4o騒動の話を脇に置いても、Xを見る限り期待したほどの高い評価は得られていないようです。筆者もその点は部分的に同感で、GPT-4oより性能が下がった部分はあるようにも感じられます。

他方、従来ありえないほどの高い性能を発揮した例もあり、かつ、このような素晴らしい性能についてはあまり知られてないようです。というわけで、GPT-5が素晴らしい性能を発揮した例についてここに記しておきます……とできるとよかったのですが、記事執筆中に最新のGemini 2.5 Proでやらせてみたら解けてしまったので、記事タイトルごと変更しておきました。加えて、そのせいで記事終盤がgdgdになっていますがご容赦を。

論文読解ベンチマーク

LLMのベンチマークには様々なものがあり、そのスコア向上を目指して、日々多くのLLM開発者がしのぎを削っているような状態ですが、既存ベンチマークには（「どの程度」かはともかく）、部分的にLLMが回答そのもの（か近いもの）を既に見てしまっているのではという疑念があります。いわば、チートに近いことを（意図せず）やってしまっている可能性ですね。

そのようなことを避け、初出に近い概念について的確な「理解」をしているかを示すために、私は新しい推論モデルが出るたびに、昔、SWoPP2016で発表した、Macro PEGを提案する論文（査読を通ってない途中段階のものなのので、正確には「発表資料」）を読み込ませて、論文に書かれていない応用課題を解けるかを試しています。

ちなみに発表資料についてはこちらからダウンロード可能なので、お手元で再現性をテストすることも可能です。

Macro PEGとは

この発表資料で提案しているMacro PEGは私の専門領域であるPEG（Parsing Expression Grammar）を独自拡張して、引数をとれるようにしたものです。これによって、規則をパラメタ化して関数のように扱うことができ、文法の再利用性が高まるというのが一つのうたい文句ですが、もう一つ重要な側面があって、それは表現能力の向上です。

たとえば、aa,bb,abba,baab,abbbba,...のような回文を表現するという問題を考えてみます。これは文脈自由文法では素直に以下のように表現することが可能です。

X -> a X a | b X b | ε

しかし、それに対応する以下のような規則ではうまく回文が表現できません（正確に言うと、長さが2の累乗 - kのような奇妙な形の回文だけを受理する形になってしまいます）。

S <- X !.
X <- "a" X "a" / "b" X "b" / |""

「回文をPEGで表現可能か」は実は答えがでていない問題ではあるのですが、知る限り多くの人が「これはPEGでは表現できないのでは」と考えています。

他方、Macro PEGを使えば以下のような記述で簡単に回文を表現できます。

S <- P("") !.
P(r) <- "a" P("a" r) / "b" P("b" r) / r

この「トリック」の詳細について知りたい方については資料を読んでいただくとして、Maro PEGではこれに加えて、（a^n b^n c^nのようなPEGで表現可能と知られているようなものとは別の意味で）文脈自由文法では表現できない言語を取り扱うことができます。

発表資料のみを根拠にして、そのような言語を果たしてGPT-5が自力で見出すことができるかが今回のテストの目的です。私見ですが、初見の論文を「それらしく」解説することは従来のLLMでも可能でしたが、それを応用する段になると途端に弱くなるというのがこれまでのモデル（o3含む）についてもっていた感想でしたし、同時にここをクリアできないのであれば、研究をサポートするモデルとしてはやや微妙な評価にならざるを得ないと考えています。

さて、このテストをGPT-5はクリアできるのでしょうか？

発表資料を読ませて解説してもらう

まずは実際に発表資料PDFを読ませて解説してもらいましょう。これだけで性能を測ることはできませんが、LLMは出力自体が後続の回答に影響を与える性質がある以上、このフェーズは重要です。

プロンプトは以下で、

（ファイル添付:SWoPP2016-mizushima.pdf)
この発表資料について解説してください。
```text

出力結果は以下のようになります（当然ながら、LLMの常としてそのたびごとに微妙に回答は変わります）。

```text
この資料は、従来の **PEG（Parsing Expression Grammar）** を拡張して、規則にパラメータを持たせられる **Macro PEG** を提案・説明した発表内容です。要点を整理すると以下のようになります。

---

## 1. 背景

* **PEG** は 2004 年に Ford が提案した構文解析用の形式文法。
* **特徴**:

  * 文法記述が比較的シンプル。
  * Packrat Parsing により、PEG で表現可能な言語は線形時間で解析可能。
  * 必ず一意の解析木が得られる（曖昧さがない）。
  * 字句解析器を必要としないため、文脈依存性の高い文法（例: 埋め込み式付き文字列）にも強い。
* **課題**:

  * 規則の再利用性が低い。
  * 順列や回文など、特定の文法表現が難しい。
  * 実際のプログラミング言語の文法を簡潔に表すには不足がある。

---

## 2. 提案: Macro PEG

* **発想**: Macro Grammar を参考に、PEG の規則に **引数（パラメータ）** を付けられるようにした。
* **メリット**:

  1. **規則の再利用性向上**
     → 例えば `"+" Spacing Primary` のようなパターンを `Token("+") Primary` とまとめられる。
  2. **表現力の強化**

     * 回文（従来 PEG では困難）
     * 順列言語（修飾子や属性の順不同対応）
     * コンテキスト依存ルール（例: Java の static クラス制約）
* **動作**: 引数は名前呼び出し（遅延評価）で扱われ、呼び出し時には評価されず参照時に評価される。

---

## 3. 応用例

* **式埋め込み文字列リテラル**（Ruby, Scala, Kotlin のような構文）を簡潔に記述。
* **カンマ区切りリスト** → `repsep(",", StringLiteral)` のように抽象化可能。
* **回文** → 引数を逆順比較に利用して表現可能。
* **順列言語** → 全パターン列挙不要で記述可能。
* **Java のネストクラス制約** → コンテキスト引数で static / 非 static 制約を管理。

---

## 4. パーザコンビネータとの関係

* Macro PEG は、関数型言語（例: Scala）で使われる **パーザコンビネータ** の構文とよく対応する。
* パーザコンビネータ側では引数としてパーザを受け取る関数として自然に実装できる。

---

## 5. 限界と今後

* Macro PEG でも難しい文法:

  * 変数宣言の前方参照禁止（C の typedef）
  * インデントベースの構文（Python, Haskell）
* 今後の課題:

  * 計算量の解析（最悪計算量は多項式時間になる可能性が高い）。
  * 線形時間で解析可能なサブセットや PEG への変換可能なサブセットの定義。

---

### 一言まとめ

Macro PEG は、PEG の弱点だった「規則の再利用性の低さ」と「特定文法の表現困難さ」を解消するためにパラメータ付き規則を導入した拡張です。結果として、より複雑で文脈依存な文法を簡潔かつ柔軟に記述できるようになりますが、計算量や表現限界については今後の研究課題が残っています。

---

もし必要であれば、この発表資料の **図や例をまとめた「Macro PEG 速習シート」** を作れます。そうすると実際の構文定義例が一覧できます。
作りますか？

ここについては（予想できていましたが）合格点といったところです。発表資料における問題提起と提案したMacro PEGの性質をうまくまとめています。

応用課題を解いてもらう

とはいえ、当然ながらここまではo3など既存モデルでもできたので驚きはありません。本番はここからです。XMLのサブセット（簡略化のため属性なし、テキスト要素もなし）をMacro PEGで表現できるかを問い、表現できる場合、どのようなMacro PEGになるか答えてもらうのです。

先に発表資料の著者として書いておくと、明らかにこれは実現可能なものの、若干トリッキーなやり方が必要なので、見た目をそれっぽく偽装してお茶を濁すことが多々あるLLMに対してはかなりきつい問題ですし、実際、o3ですら、この問題をきちんと解くことはできませんでした。

というわけで、いよいよ応用課題を解いてもらいます。先ほどの対話に対して以下の質問プロンプトを繋げます：

このMacro PEGを使って、XMLのサブセット（属性なし、テキスト要素なし、タグ名はa-bのみからなる）を構成できますか。できるとしたらMacro PEGを実際に出力してください。また、うまくいく理由を説明してください。

これに対するGPT-5(非Thinkingモデル）の回答は以下のようになりました。

はい、構成できます。ポイントは「開きタグを読みながら“その場で”同じ名前を後続で要求するパーザを組み立てる」ことです。Macro PEG では引数（パラメータ）に **パーザ式** を渡せるので、読んだタグ名の各文字（ここでは `a` または `b`）を **逐次的に前置** していくことで、「後で同じ並びをそっくり要求するパーザ」を生成できます。これにより、**同名の閉じタグ** を強制でき、入れ子も自然に保証されます。

---

# Macro PEG（XML サブセット）

* 属性なし
* テキスト要素なし（子は要素のみ・0 回以上）
* タグ名は `a` と `b` のみからなる 1 文字以上

# 文書 = 単一のルート要素のみ（必要なら Element* にしてもよい）
Document <- Element !.

# 要素：<name> Children </name>
# 開き山括弧の直後でタグ名を読みつつ、同名を後で要求するパーザ n を組み立てる
Element <- "<" ( "a" NameTail("a") / "b" NameTail("b") )

# NameTail(n) の意味：
#   これまで読んだ名前に対応するパーザ式 n を保持しながら
#   さらに 'a' または 'b' を読めば n の前に前置して更新していく。
#   基底分岐では '>' を読んだあと、子要素列、そして必ず "</" n ">" を読む。
NameTail(n) <-
      "a" NameTail("a" n)
    / "b" NameTail("b" n)
    / ">" Children "</" n ">"

# 子要素列（テキストは禁止）
Children <- Element Children / ""

---

## うまくいく理由

1. **同名強制**
   `NameTail` はパラメータ `n` に「これまで読んだ名前と同じ並びを要求するパーザ式」を保持します。
   1 文字読むたびに `"a" n` または `"b" n` として **前置** し、最終分岐 `">" Children "</" n ">"` に到達したとき、閉じタグで **厳密に同じ名前** を要求できます。これは回文例で逆順をパラメータに積むテクニックと同じ発想（“パーザを値として渡す”）です。

2. **名前の字句制約**
   タグ名の読み取りは `"a"`/`"b"` のみの選択肢で構成しており、基底ケースは `">"` にしか進めないため、**`[ab]+` に一致**する 1 文字以上の名前しか成立しません（最初の文字を必須にしてあるため空名は不可）。

3. **属性なし**
   開きタグは `"<" ... ">"` までを **名前連続のみ** で構成し、スペースや `=` など属性の開始を許す分岐が存在しないので、属性は表現不可能＝**禁止** になります。

4. **テキスト要素なし**
   `Children` は `Element` の繰り返し（または空）のみで、**生テキストを許す分岐がない**ため、テキストノードは受理されません。

5. **入れ子の整合**
   閉じタグは常に `"</" n ">"` で、`n` はその要素の開きタグで構築された **ローカルな“同名パーザ”**。したがって要素境界をまたいだ名前の取り違えが起きず、**適切な入れ子のみ受理**します。

---

必要なら、この文法を実際のパーザコンビネータ（例：Scala）に落とした実装サンプルも用意できます。

さて、この回答ですが、発表資料の著者としていうなら100点満点の回答といえます。

特に、回文の例にあったものと同様のテクニックを使っていることを明言しているのがポイントで、ここは明らかに非自明なのですが、うまく理解できていることがうかがえます。

ちなみに、従来のモデルはどれもここをのり超えることができず、勝手に後方参照ぽい拡張を追加するなどのズルに出て、お茶を濁したり、それを問い詰めると更に迷走するのが常でした（Claude 4.1 Opusは現在でもそうですし、Gemini 2.5 Proも記憶が間違っていなければ2025年5月頃のモデルでは同じ状況でした）。

というわけで、GPT-5凄い！博士号レベルと言えるかはともかくかなり近づいた……と締められれば良かったのですが、（内心ないだろうと思いつつ、万が一を考えて）Gemini 2.5 Pro（2025年8月13日時点）に解かせたら、なんと解けてしまった……ので、Gemini 2.5 Proも同様に凄い、というちょっとしょぼい結論になります。

おそらくGemini 2.5 Proの6-7月のアップデートでここに到達したのではと考えられますが、正直、Gemini 2.5 Proが短期間でここまですさまじい性能向上を果たしているのは予想外でした。思い込みにならないよう都度検証しながら記事を書く癖に救われたといったところでしょうか。ともあれ、Gemini 2.5 Proもこの地点に到達できたことがわかったので、Gemini 2.5 Proも改めていじって性能を検証していく必要がありそうです。