Claude Media
フェルマーの最終定理をClaudeが11日で形式化 — Lean1,300万行を機械検証

フェルマーの最終定理をClaudeが11日で形式化 — Lean1,300万行を機械検証

Claudeが11日でフェルマーの最終定理の証明をLeanで書き切り、機械検証まで通りました。1,300万行・29,500定理という規模の中身と、証明が正しいと言える3段構えの根拠を追います。

フェルマーの最終定理は、3以上の指数nについてaⁿ + bⁿ = cⁿ を満たす正の整数の組は存在しない、という主張です。答えは「存在しない」で、証明は1995年にAndrew WilesとRichard Taylorが発表しました。

その証明が、コンピュータで最後まで確かめられる形になりました。Claudeが11日間ほぼ自律で書いたLeanのコードは1,300万行、最終的な証明で使われた定理は29,500件に及びます。新しい数学が生まれたわけではありません。動いたのは、すでにある証明を機械が確認できる状態にするまでにかかる時間のほうです。Claudeと研究者が対話しながら理論を詰めるvibe physicsの動きとも重なり、AIとの数理研究の広がりの一部といえます。

数字で見る11日間

数字

今回の形式化の規模

  • 所要期間

    11日

    ほぼ自律。人間の数学的な指示は高レベルの声かけのみ

  • Leanのコード

    1,300万行

    Mathlibの5倍超。必要以上に長い可能性が高い

  • 使われた定理

    29,500件

    証明した分は30,300件

  • 出力トークン

    約60億

    社内の汎用研究モデル

Anthropicの発表とリポジトリのREADMEに載っている値です

主題は新定理ではなく検証です。証明そのものは1995年にAndrew Wilesが発表済みで、Claudeが担ったのは論証をLeanが1ステップずつ確認できる形に書き直す作業でした。始めたのはAnthropicの研究者Tianyi Pengです。成果物はGitHubの anthropics/fermats-last-theorem にApache-2.0で置かれています。2026年のカーネル健全性修正を含むLean 4.33.1とMathlib v4.33.0で再検証できます。使われたモデルの性能は、おおむねClaude Fable 5.1と同程度と説明されています。

リーマン予想での新記録と今回は何が違うのか

違いは「新しい数学を作ったか、既存の数学を検証したか」の一点にあります。2026年8月に公開されたリーマン予想の関連問題での新記録では、臨界線上の零点の割合の下限が41.6%から67.2%へ更新されました。あちらは、それまで誰も証明していなかった主張が新たに証明された事例です。

今回のフェルマーの最終定理には、新しい主張がありません。証明は31年前に完成しています。作られたのは、その論証を機械が読める言語に翻訳した成果物のほうです。電卓で計算を検算するのと同じ感覚で、証明の論理を1行ずつ確かめられるようになった、と考えると近くなります。

この違いが効くのは、信頼の作られ方です。新しい定理は、誰かが読んで納得するまで信頼できません。形式化された証明は、Leanのカーネルが通した時点で論理の穴がないことが確定します。読む人の熟練度にも、費やせる時間にも依存しません。

フェルマーの最終定理の350年と、形式化に費やされた11日

1637年頃にPierre de Fermatが本の余白に書きつけてから、1995年に正しい証明が出るまで350年以上かかりました。

あゆみ

フェルマーの最終定理が検証されるまで

  1. 1637年頃Fermatが余白に主張を残す

    「真に驚くべき証明を見つけたが、余白が狭すぎる」という走り書きが添えられていました。

  2. 1908年正しい証明に10万金マルクの懸賞金

    現在の100万〜200万ドル相当で、最初の1年だけで621件の誤った証明が寄せられました。

  3. 1993年6月Wilesが3日間の連続講義で証明を発表

    2か月後の検証で、査読者の質問から致命的な欠落が見つかります。

  4. 1995年5月WilesとRichard Taylorの正しい証明が発表

    129ページで、確認に数か月かかりました。

  5. 1995年の約10年後Jan Bergstraが証明の形式化を提案

    その後、形式化の手法の整備が続きます。

  6. 2024年Kevin Buzzardを中心にLeanでの形式化プロジェクトが始動

    初期段階を記述する設計書(ブループリント)だけで86ページあります。

  7. 2026年8月18日Claudeの証明がプラットフォーム上で「PROVED」に

    形式化に要したのは11日でした。

1993年の一件は、この分野で検証がどれだけ難しいかを示す例としてよく引かれます。Wilesは講義で証明を示したものの、2か月に及ぶ検証の途中で査読者の質問から穴が見つかりました。修復には1年を要し、いったんは断念寸前まで追い込まれています。完成にこぎ着けたのは、以前に捨てた方針が使えると気づいてからのことでした。

なお、Fermat自身が書き残した「真に驚くべき証明」については、初等的な証明が数世紀にわたって見つかっていないことから、誤りだったと考えるのが今の数学界の見方です。

検証の難しさはこの定理に限りません。Anthropicは別の例も挙げています。Thomas Halesのケプラー予想の証明(1998年)は4年にわたって審査され、12人の査読者団が最後は「99%確実」で折り合いました。Halesはその後、20人規模のプロジェクトFlyspeckで証明を形式化しています。Grigori Perelmanのポアンカレ予想の証明(2002年)は、コミュニティが受け入れるまでに約4年と300ページの解説3本を要しました。Harald Helfgottの弱いゴールドバッハ予想の証明(2013年)は、いまも審査中です。誤った結果が何年も受け入れられ、他の数学者がその上に理論を築いてしまう例もあるといいます。

Tianyi Peng本人にも、長い証明を確かめきれなかった経験があります。学部時代、指導教員から論文に載せる証明は確かかと問われ、「99%は確信しているが、これほど長い証明では100%とは言い切れない」と答えて、Natureの論文に成果を載せる機会を逃したそうです。

11日の内訳 — 数十体のエージェントとProve2Me

フェルマーの最終定理の形式化には数年かかると見込まれていました。人間の証明が「自明」として飛ばす手順もLeanは1つずつ確認する必要があり、しかも形式化済みの数学は全体のごく一部しかないためです。実際にかかったのは11日でした。

作業を進めたのは、数十体のClaudeエージェントによる分業です。概念の定義、中間定理の証明、その定理を使ったより難しい主張への挑戦を、エージェントが共同で進めました。人間からの数学的な指示は「スキームとしてのヤコビアンは優先度が高そう」「Mazurの定理を早めに片づけて」といった高レベルの声かけに限られています。

形式化の対象になったのは、Darmon・Diamond・Taylorによる解説に沿ったWilesの証明の簡略版です。論証の骨格そのものは、Frey、Serre、Ribet、Wiles、Taylor-Wilesの筋をたどります。なお1,300万行という行数は、必ずしも成果の大きさを表すものではありません。Mathlibが簡潔でよく吟味されているのに対し、この証明は必要以上に長くなっている可能性が高い、という但し書きが添えられています。

ただし最初からうまくいったわけではありません。初期の試みでは、エージェントが早い段階で成果を出したあとプロジェクト全体の状態を見失い、協調が崩れました。この失敗した作業が最終的な証明に残ったのは、定型部分を除いた行数の約7%です。

風向きが変わったのは、Prove2Meという形式化向けの共同プラットフォームに切り替えてからでした。Tianyi Pengとコロンビア大学の共同研究者が設計したもので、3つの仕組みが効いています。

  1. 定理の依存関係を有向非巡回グラフ(DAG)で保持する: 次にどの証明へ進むかをエージェント自身が判断できるようになり、記憶の劣化を抑えながら複数のエージェントを並列に走らせられます
  2. 定理の主張と証明を別ファイルに分ける: 両者のつながりは独立に管理されるため、Leanのコンパイルが速くなり資源の消費も減ります
  3. 各定理に自然言語の説明を持たせる: 既存の定理を検索して再利用でき、証明の道筋が単純になります

この仕組みとClaude Codeベースのマルチエージェント構成を組み合わせ、2週間弱で完走しました。エージェントを増やすだけでは崩れる作業が、状態を共有する土台を挟むと通る——今回の実務上の学びは、数学よりもこちらに寄っているように読めます。Prove2Meの設計は論文にまとまっています。Tianyi Pengを含む5人の共著で、題名は「Prove2Me: An open collaborative platform for scaling math formalization」です。

証明は背理法でどう組み上がっているか

リポジトリの PROOF-PATH.md は、証明の道筋を6つの段に分けて、それぞれを担うLean定理の名前を挙げています。中心にあるのは、「反例があるなら、あり得ない楕円曲線が作れてしまう」という背理法です。

手順

証明の道筋(PROOF-PATH.mdの6段)

  1. 1

    指数が5以上の素数pに絞る

    fermat_last_theorem は、Mathlibの定式化 FermatLastTheorem から1行で導かれます。指数4と3の場合はMathlib側で済み、残る5以上の素数を FreyPackage に渡します。

  2. 2

    反例からFrey曲線を作る

    a^p + b^p = c^pの反例から、楕円曲線(Frey曲線)を持つ FreyPackage を組み立てます。この曲線がありえないことを示せば、反例は存在しません。

  3. 3

    mod pの表現が既約だと示す(Mazur)

    p ≥ 17ではMazurのEisensteinイデアルの議論を、この状況向けに実装しています。この段の中で最も大きな部分です。pが5・7・11・13の指数は別の方法で先に片づきます。

  4. 4

    曲線が保型だと示す(Wiles)

    半安定な曲線が保型であることを、Langlands-Tunnellの定理、Taylor-Wilesのパッチング、「3-5の切り替え」で示します。

  5. 5

    レベルを下げる(Ribet)

    保型形式のレベルを素数1つずつ取り除き、最終的に Γ₀(2)上の重さ2の0でないカスプ形式を作ります。

  6. 6

    Γ₀(2)上の重さ2のカスプ形式は0だけ

    0でないカスプ形式はありえないので矛盾します。この段はMathlibだけで証明されています。

指数5はZ[(1+√5)/2]での降下法、7・11・13はKummerの正則素数の定理と、円分体の整数環が単項イデアル整域であることの証明で、それぞれ別に決着しています。

もう1つ見ておきたいのは、「どこまで証明したか」を PROOF-PATH.md が明示している点です。古典的な定理の名前が付いた段でも、証明されたのはFrey曲線の議論に必要な強さに限られます。

くらべる

名前の付いた定理は、どこまで証明されたか

この証明が必要とする強さ

証明されたこと

  • Mazur: Frey曲線のE[p]の既約性(p ≥ 17はEisenstein商、p ≤ 13はKummerまたは降下法)
  • Langlands-Tunnell: 全射なmod 3表現のうち八面体型の場合
  • Wiles: 半安定な整Weierstrassモデルは保型
  • Ribet: Frey表現のレベル低下を、トレースの合同として
一般形は対象外

証明されていないこと

  • Mazur: 一般の曲線の有理同種写像やねじれ点の定理
  • Langlands-Tunnell: 可解な像を持つ一般の2次元奇表現
  • Wiles: 非半安定な曲線、モジュラー的パラメータ付け、L関数
  • Ribet: 一般のmod p保型表現へのレベル低下

証明が正しいと言える根拠は3段構えになっている

公開リポジトリでは、3つの検査を通したことが示されています。

1つ目は、依存する公理の確認です。既定のビルドターゲット FinalCheck.lean は、証明が依存する公理をビルド時に確かめる仕組みです。対象は propext / Classical.choice / Quot.sound というLean標準の3公理だけに限られます。sorry(証明の保留)、独自公理、native_decide のいずれかが紛れ込んでいればビルドが失敗する設計です。あわせて unsafe / extern / implemented_by / partial def / #eval を加えた計8種の構文が、どのモジュールにも現れないことが確認されています。このビルドではリポジトリの60,475モジュールすべてが通り、各宣言がLeanのカーネルで検査されました。同ファイルは、Mathlibが持つフェルマーの最終定理の主張 FermatLastTheorem も、この定理から導出しています。ソースにはImperial College LondonのFLTプロジェクトとflt-regularに由来する106ファイルがあります。上流の著作権者と著者は ATTRIBUTION.md に記載されています。

2つ目は、comparatorによる照合です。leanprover/comparator v4.33.0が、Mathlibの語彙だけで書かれた挑戦用の主張とビルド結果を突き合わせました。証明された主張とそこに現れる定数がすべて一致すること、余分な公理が使われていないこと、Mathlibを含む証明全体がLeanカーネルを再通過することを確認しています。なお主張そのものはLean組み込みの自然数と + ≤ < ≠ で書かれており、Mathlib由来の要素は自然数上の ^ だけです。この ^ もMathlibがLean組み込みの冪乗として定義したもので、comparatorが素のMathlibと同一であることを確かめています。Mathlibライブラリ全体を信頼する必要はない、という設計です。

3つ目は、別実装のカーネルによる再検査です。Rustで書かれた独立のLeanカーネルnanoda 0.4.13が、同じ環境のエクスポートを受け取り、1,052,234件の宣言をエラーなしで検査しています。速度改善などの小さなパッチが4つ当てられていますが、型付け規則を足したり取り除いたり緩めたりするものは含まれません。

手元で検証し直すには何が要るか

公開された証明は読むだけでなく、自分の環境で再検証できます。ただしリポジトリは研究成果物として置かれたもので、保守も外部からの貢献の受け付けも行わないと冒頭に明記されています。要求される資源もかなり大きく、手元のノートPCで気軽に回せる規模ではありません。リポジトリに記載された実測値を工程ごとに並べると、次のようになります。

工程所要時間(リポジトリの実測値)メモリのピーク備考
Mathlibの取得とコンパイル所要時間(リポジトリの実測値)約13分(96並列)メモリのピーク—備考一致するビルド済みMathlibが無いためソースから
lake build所要時間(リポジトリの実測値)5時間32分(96並列)メモリのピーク153GB備考並列1本あたり約5GB、一部モジュールは最大36GB
comparator所要時間(リポジトリの実測値)14時間46分メモリのピーク230GB(300GBの確保を推奨)備考ほぼ全部がカーネル再実行で1コア動作
nanoda所要時間(リポジトリの実測値)エクスポート約1時間 + 検査約30分メモリのピーク書き出し約90GB / 検査約40GB備考37.8GBのエクスポートを16スレッドで検査

表のメモリ値は実測のピークで、並列1本あたり約5GBという目安とは別の数字です。

ディスクは .lake/ 配下に約67GB、加えてビルド中に生成されるCファイルが約220GBです。後者はビルドの進行に合わせて削除できます。

ビルドが動くのはLinuxとmacOSで、Windowsはパスが長すぎる箇所があるため対象外です。ただしcomparatorとnanodaの検証スクリプト2本はLinux専用のため、macOSではビルドまでしか通せません。スクリプトが使うのはbash / git / python3 / GNU coreutilsで、nanodaはさらに patch と cargo、そしてcrates.ioへの接続を必要とします。Leanの導入には elan とネットワーク接続も要ります。

git clone https://github.com/anthropics/fermats-last-theorem flt && cd flt
LEAN_NUM_THREADS=96 lake build
verification/comparator/run.sh
verification/nanoda/run.sh

LEAN_NUM_THREADS を省くと、ハードウェアスレッド数と同じ本数で並列に走ります。並列1本あたり約5GBを目安に、手元のメモリに合わせて値を下げてください。nanodaはcomparatorのスクリプトが用意した道具を再利用するため、この順序で走らせます。

合否の読み方も決まっています。ビルドが成功していれば、出力の末尾に依存公理が3つである旨と Build completed successfully が並びます。comparatorの判定は .verify-work/wrapper/comparator.log の最終行に出て、合格なら Your solution is okay! です。nanodaの判定は .verify-work/nanoda/run-*/nanoda.stdout に書かれ、どちらのスクリプトも成功時は終了コード0で終わります。途中でLeanの非推奨警告やスタイル警告が大量に出ますが、結果には影響しません。

資源をかけずに中身を見たい場合は、リポジトリに同梱された html/ フォルダ(約390MB)が使えます。29,511件の定理それぞれにページがあり、正確なLeanの主張、引用元と引用先、展開できる依存グラフが載っています。定義モジュール1,450件分のページと、定理名・定義名を横断する検索窓も含まれます。html/index.html をブラウザで開くだけで動き、サーバーは要りません。同じ内容はドキュメントサイト(tianyipeng.github.io/fermats-last-theorem)でも読めます。動作確認が取られているのはChromium系のブラウザのみです。

Claude Maxプランでも形式化に参加できるのか

小規模な題材であれば、個人向けプランの枠内でも形式化は成立しています。Anthropicの研究者が、個人契約のClaude Maxプラン3つだけを使い、Hardy-Littlewoodの円周法の応用を形式化する実験を行いました。Prove2Meだけを介して協調させたエージェント群は、ヴィノグラードフの3素数定理の形式化を3日で完了しています。

フェルマーの最終定理のほうはトークンを大量に消費するプロジェクトでしたが、こちらは規模が違います。適切な仕組みさえあれば、消費者向けの契約でも主要な定理を共同で形式化するところまで届きうるというのがAnthropicの見立てです。研究者向けの支援としては、無償・割引の契約や研究クレジットの提供が科学者向けClaude Teamプランの開放などの形で広がっています。LeanやMathlibの改善を含む大型プロジェクト向けの助成枠も、別途用意されています。

形式化が普通になると数学の書き方はどう変わるか

証明を読んだKevin Buzzardは、今回の成果を「現代の数学文献を自動的に形式化することへ向けた大きな一歩」と評しています。既存の文献に残る誤りを洗い出す道具になり、査読者の負担を軽くする方向に働く、とBuzzardは見ています。LLMが生成した数学を厳密に確認する手段としても挙げられており、現状では人手で高いコストをかけている作業にあたります。

Anthropicは、論文の提出物が2本立てになると見込んでいます。人間向けの説明と、機械検証を通した形式化の両方を添える運用が広がっていく見通しです。形式化が人間向けの解説に取って代わるという話ではなく、AIが生成する結果の量に数学界が追いつくための現実的な手段は、そこにしかないかもしれないとAnthropicは位置づけています。

もう1つ興味深いのは、Claudeにとっては、Leanを書くこと自体が新しい結果を出す助けになっているようだ、という観察です。Anthropicの最近のClaudeによる成果の多くは証明と並行して形式化されており、Claudeはその部分的な証明を使って自分の仮説を独立に確かめていると見られています。数値シミュレーションを書いて見立てを確かめるのと同じ使い方です。ここから先は見立てですが、証明支援系の役割は「答え合わせの道具」から「思考の途中で使う道具」へ移りつつあるように見えます。ただし人間の書き手が同じ使い方をするには、Leanを読み書きできることが前提になります。その層がどこまで広がるかは、また別の問題です。

まとめ

形式化にかかる時間は数年の見込みから11日に縮みましたが、機械が保証するのは論理の正しさまでです。定理名の意味や検査ツールの健全性は、人が信頼する前提として残ります。

この記事を共有:XはてブLinkedIn