OpenAIのモデルが80年来の数学の予想を否定した話

Xのタイムラインを流し見してたら、えぐいニュースが飛び込んできた。OpenAIのモデルが「unit distance problem」という離散幾何学の予想を否定したらしい。80年間誰も解けなかったやつだ。

unit distance problemというのは、n個の点を2次元平面上に配置したとき、ちょうど距離1になる点のペアが最大で何組できるか、という問題だ。長らく「だいたい n^(1+c/log log n) くらいが上限じゃないか」という予想が定説になっていた。それをOpenAIのモデルが反例を構成して否定した。数学の専門家がレビューしてOKを出したという話なので、「AIが何となく答えを出した」レベルじゃない。証明として成立している。

これ、正直すごいと思う一方で、「どうやって?」という部分が気になって仕方がない。LLMが数学的証明を生成するアプローチはいくつか想像できるが、ざっくりこんな感じだろう。

• 探索空間を絞るheuristicをLLMが生成して、組み合わせ最適化ソルバーを走らせる
• 既存の証明手法をリミックスして新しい構造を提案する
• 人間のフィードバックを挟みながら反例の候補を絞り込む

公式ブログには詳細が載っていないので、実装の中身はわからない。でもどれにせよ、モデル単体というよりモデル+人間+ツールのシステムとして動いているはずだ。

「AIが数学を解いた」を実装者目線で読む

ここで一回、エンジニア的な目線に引き戻す。自分は最近、個人開発でLLMにコード生成をさせるパイプラインを組んでいる。やってみてわかったのは、LLMが本当に強いのは「次の一手を出す」ところで、「その一手が正しいか検証する」部分はまた別のレイヤーが必要だということだ。

数学の証明も同じ構造だと思う。モデルが「こういう構造の反例がありそう」という候補を出して、検証ループが「これは本当に成立するか」を確認する。人間の数学者がやることと本質は変わらない。速度と探索の広さが違うだけだ。

この話を彼女にしたら「80年間誰も解けなかったのにすごいね」で終わった。そうなんだけど、自分が気になるのはそこじゃなくて、そのシステムをどう設計したかだ。

自分のコードに引きつけると何が変わるか

今のパイプラインは、LLMにタスクを投げて結果を受け取るだけで、検証ステップが弱い。生成されたコードがテストを通るかどうかをチェックする仕組みはあるが、「そもそもアプローチが正しいか」を評価するレイヤーがない。

今回のOpenAIの事例は、そこに示唆を与えてくれる。生成と検証を明確に分離して、検証側にドメイン知識を持たせる設計だ。数学なら形式証明システム、コードならlinterや型チェッカーを組み合わせる。

# 今の自分のパイプライン (雑)
llm_generate() | run_tests

# 目指したい形
llm_generate() | domain_validator | refine_loop | run_tests

もちろんこれは擬似コードだし、domain_validator の中身を何にするかが全部の肝だ。でも「生成で終わりにしない」という発想の転換は、個人開発のパイプラインでも使えると思っている。

80年解けなかった問題が解けた、というヘッドラインだけで終わらせるのはもったいない。どういう設計で解いたかを追いかけると、自分の実装に直接フィードバックできるはずだ。OpenAIが論文や技術詳細を出してくれることを、とりあえず待っている。