気になるAIの動きを、分かりやすく
2026年9月4日、Anthropicがフェルマーの最終定理の、初めての完全な機械検証済み証明を公開しました[1]。Claudeが Lean というプログラミング言語で書き、かかった時間は11日。数学のコミュニティが数年かかると見ていた作業です。
ただ、この発表の読みどころは速さではありません。最初の試みは失敗していて、通った理由はモデルを賢くしたことではなかった——そして「機械検証済み」が何を保証して何を保証しないのかは、発表ページではなく、同時に公開されたリポジトリの README に書かれています。
この記事で分かること——①何が起きたか ②なぜ「検証」がニュースなのか ③最初の試みはなぜ失敗したか ④何を変えたら通ったのか ⑤「機械検証済み」は何を保証するのか ⑥公式が自分で書いた限界 ⑦自社の仕事に持ち帰れること。
01 11日で、1,300万行
数字から見ます。すべてAnthropicの公式発表に書かれているものです[1]。
| 項目 | 値 |
|---|---|
| かかった日数 | 11日（大部分は自律的に） |
| 書かれたLeanのコード | 1,300万行 |
| 証明された定理 | 30,300（うち29,500を最終証明で使用） |
| 消費した出力トークン | 約60億 |
| 使ったモデル | 社内の汎用リサーチモデル（Claude Fable 5.1 とおおよそ同等） |
| 動いたエージェント | 数十体（Claude Code ベースのマルチエージェント基盤） |
| 規模 | Mathlib（コミュニティの主要な定理ライブラリ）の5倍超 |
人間が入れた数学的な指示は「たまの高レベルな一言」だけだった、と公式は書いています。挙げられている実例は2つで、どちらも短いものです——「スキームとしてのヤコビアンが優先度高そうだ」「マズールの定理を早めに終わらせよう」。
比較のための前提も置かれています。数学のコミュニティは2024年から Kevin Buzzard（Imperial College London）を中心に形式化プロジェクトを進めていて、その初期フェーズを説明する設計図だけで86ページありました。全体は数年がかりと見られていた作業です。
この並外れた自動形式化の成果は、Anthropicの研究者によればわずか11日で、数学の公理以外の仮定を一切置かずにフェルマーの最終定理を証明している。（中略）AIによる自動形式化の成果物は、いまやその上に積み上げられるだけの頑健さを持つ。
Kevin Buzzard（Imperial College London）／公式発表に掲載されたコメント[1]
なお本文の数値は、公式発表・公開リポジトリの記述・筆者がリポジトリを機械的に数えた実測値に基づきます。証明そのもののビルドと再検証は電脳技巧集団では行っていません（その理由は06章で分かります）。
02 なぜ「速さ」ではなく、「検証」がニュースなのか
数学の証明は、長い論理の鎖でできています。鎖の輪が1つ壊れていると、その先が全部おかしくなる。だから新しい結果が正しいと確信するまでに、数ヶ月から数年かかることがあります。
フェルマーの最終定理そのものが、その見本でした。
- 1908年、正しい証明に10万金マルク（今の1〜2百万ドル相当）の賞金がかけられ、最初の1年だけで621件の誤った証明が寄せられた。
- 1993年6月、Andrew Wiles が3日間の連続講義で証明を発表。検証開始から2ヶ月後、レビュアーの質問が致命的な穴を露わにした。
- Wiles は1年かけて、最初は一人で、のちに教え子の Richard Taylor とともに修正にあたり、諦めかけたところで一度捨てた筋を思い出して穴を塞いだ。正しい証明が出たのは1995年5月、129ページ。
つまり数学では、「書く」より「確かめる」ほうが高くつきます。Anthropicは、最近のAIによるリーマン予想まわりの仕事が「新しい数学」を生んだのに対し、今回新しいのは検証のほうだと自分で書いています。
03 最初の試みは、失敗していた
ここが、他の記事があまり書いていないところです。公式ページは、うまくいった話の途中でこう書いています。
Claudeの初期の試みのいくつかは失敗した。エージェントは早い段階では多少うまくいったが、すぐにプロジェクトの現在地を見失い、効果的に協調しなくなった。
Anthropic 公式発表[1]
そして、その失敗は消えていません。失敗した作業が、最終的な証明の「定型部分を除いた行」の約7%を占めていると明記されています。書き直しではなく、残骸が混ざったまま完成しているということです。
注目したいのは、問題がモデルの能力ではなかった点です。数十体のエージェントが同時に動くと、誰が何を終わらせたのか、次に何をやるべきなのかが分からなくなる。長時間・多数のAIで進める仕事で最初に壊れたのは、賢さではなく現在地の管理でした。
04 何を変えたら通ったのか ──足場の3つ
うまくいったのは、Prove2Me という土台に乗り換えてからでした。Columbia University の Tianyi Peng（この形式化を主導したAnthropicの研究者でもあります）らが設計した、数学の形式化のためのオープンな協働プラットフォームで、論文は2026年8月28日にarXivで公開されています[4]。
公式が挙げている「効いた点」は3つです。専門用語を外して読むと、AIに長い仕事を任せるときの設計そのものになっています。
| 効いた仕組み | 公式の説明 | 一般の言葉にすると |
|---|---|---|
| DAG（有向非巡回グラフ） | 定理の主張を依存関係のグラフとして保持し、エージェントが次に何を証明すべきかをそこから決める。記憶の劣化を和らげ、並列作業を可能にした | やることの一覧を、依存の順で引ける形にしてAIの記憶の外に置く |
| 主張と証明の分離 | 定理の主張と証明を別々のファイルに分け、両者のつながりは独立に管理する。コンパイルが速くなり、資源の消費も減った | 「何をやるか」と「どうやるか」を別の場所に置く |
| 自然言語の説明 | すべての定理の主張に自然言語の説明を持たせる。検索と再利用ができるようになり、証明の道筋が単純になった | 各項目に、検索して再利用できる説明文を付ける |
この3つ目までやると、AIどうしが互いの成果を拾えるようになります。似た定理を誰かがすでに証明していれば、探して使い回せる。逆に説明文が無ければ、同じものが何度も証明されます。
実物で確かめられる
公開リポジトリ[2]を機械的に数えると、この設計がそのままディスク上の形になっていました（2026年9月5日時点・筆者実測[3]）。
| ディレクトリ | 中身 | .lean ファイル数 | 合計 |
|---|---|---|---|
| Theorems/ | 定理の主張 | 29,511 | 262.8 MB |
| P2M/ | その証明 | 29,513 | 841.4 MB |
| Definitions/ | 定義 | 1,450 | 12.2 MB |
主張と証明が、ほぼ1対1で別々のファイルに分かれています。しかも証明側は主張側の3倍以上の容量がある。「分ける」という設計判断が、そのまま29,511組のファイルとして残っているわけです。
規模の話でもありません。Anthropicは同じページで、個人向けの Claude Max プラン3つだけを使った小さな実験にも触れています。Prove2Me 上だけで協働させたエージェントたちは、Vinogradov の三素数定理の形式化を3日で完了しました。「適切な足場があれば、消費者向けのAIサブスクリプションでも主要な結果の協働形式化は達成できる」というのが公式の見立てです。
関連記事 ｜ モデルより「足場」が効く話AI開発の主戦場は、モデル比較から「作業環境」へ移った ──モデルは脳、harnessは職場
→
05 「機械検証済み」は、何を保証するのか
ここからはリポジトリの README の話です。発表ページには書かれていません[2]。
検証は三重にかかっていました。
| 何で | どこまで確かめたか | 結果 |
|---|---|---|
| Lean 本体のビルド | Lean 4.33.1（2026年のカーネル健全性修正を含む版）で、リポジトリの60,475モジュール全部を一から構築。すべての宣言をカーネルが検査 | 依存する公理は標準の3つのみ |
| comparator v4.33.0 | 証明された主張と、それが言及する定数がすべて「Mathlibだけで書いた課題文」と同一であること／他の公理を使っていないこと／Mathlib込みで全体がカーネルを通り直すこと | Your solution is okay! |
| nanoda 0.4.13 | Rustで書かれた独立した別のLeanカーネルが、同じ環境の書き出しを受理 | Checked 1052234 declarations with no errors |
抜け道も名指しで塞いであります。READMEは、どのモジュールにも axiom・sorry・native_decide・unsafe・partial def・#eval は含まれないと書いています（sorry は「ここはまだ証明していない」を意味するLeanの記法。1つでも残っていれば、そこが穴になります）。
そして最終チェックのファイル FinalCheck.lean は、わずか549バイトしかありません。要はこれだけです。
/-- info: 'fermat_last_theorem' depends on axioms:
[propext, Classical.choice, Quot.sound] -/
#guard_msgs in
#print axioms fermat_last_theorem依存する公理がこの3つと一字でも違えば、ビルドが落ちます。1,300万行が、最後はこの数行に集約される作りです。
06 では、何は保証しないのか
同じ README が、限界も自分で書いています。ここが一番読む価値のあるところです。
どんな道具にも確認できないのは、各中間定理が、その名前から想像されるとおりの意味かどうかである。それは読者が判断することである。
リポジトリの README[2]
つまり、「29,511個の定理が正しい」ことは機械が保証していますが、「その定理が、あなたの思っている定理か」は保証していません。READMEはさらに念を押します——名前は機械が生成したもので、P2M や16進数の接尾辞は作業パイプラインのラベルであって数学ではない。そして名前と主張が食い違ったら、正しいのは主張のほうだ、と。
同じ断りが、3箇所に繰り返し置かれています。
- README：ソースは「読まれるためではなく、検査されるために書かれている」。コメントは、上流の告知・説明文・引用を除いて削除されている。
- PROOF-PATH.md（証明の道筋を人向けに説明した文書）：「この散文とLeanが食い違う場合、Leanが正しい」。
- ブラウザで読める
html/（約390MB）：英語の要約と参考文献は自動生成であり、Leanの主張のほうが正。
AIがゼロから作ったわけでもない
ライセンスは Apache-2.0 で、READMEと NOTICE は、素材が3つの Apache-2.0 プロジェクト——Kevin Buzzard が率いる Imperial College London の FLT プロジェクト、flt-regular、そして Mathlib——から来ていることを明記しています。ATTRIBUTION.md（約50KB）は、前2者の材料を含む106ファイルと、Mathlibのテキストを再現している23ファイルを、上流のファイル名・著作権者・著者つきで1件ずつ並べています。READMEの言い方はこうです。
Leanのソースは、人間が書いたオープンソースのLeanの上にAIエージェントが積み上げて作られた。Leanを審判役として。
リポジトリの README[2]
「自分で確かめられる」の、実際
READMEには、再検証にかかる資源も数字で書いてあります。
| 手順 | 時間 | メモリ |
|---|---|---|
| lake build（96並列） | 5時間32分 | ピーク153GB（1ジョブ約5GB、一部モジュールは36GB） |
| comparator | 約15時間（実測14時間46分） | ピーク230GB（300GB見ておくこと） |
| nanoda | 書き出し約1時間＋検査約30分 | 書き出し約90GB／検査約40GB |
ディスクは .lake/ の下に約67GB、加えて途中で消せるCファイルが約220GB。書き出すファイルだけで37.8GBあります。「誰でも検証できる」と「実際に検証できる人がどれだけいるか」は別の話だと分かります。リポジトリ自身も冒頭に「研究成果物。保守しないし、貢献も受け付けない」と置いています。この記事で証明の再検証をしていないのは、この要件のためです。
細かい揺れも1つ。発表ページは「29,500の中間定理」と書き、READMEと実測は「29,511」（生成された定理は30,300）。どちらも誤りではなく、数え方（最終証明で使ったもの／リポジトリに入っているもの）の違いですが、数値を引くときは出どころを添えたほうが安全です。
07 持ち帰り ──長い仕事を、AIに任せるとき
数学の話に見えて、中身は「長い仕事を複数のAIに任せると何が壊れ、何で直るか」の実例でした。
| 人が読んで確かめる | 機械が検査する | |
|---|---|---|
| かかる時間 | 数ヶ月〜数年（FLTは1993→1995） | 一度通れば、再実行で確認できる |
| 見落とし | 起こる（2ヶ月後に穴が発覚） | 論理の穴は通らない |
| 保証されること | 意味も含めて理解される | その主張が、公理から導けること |
| 保証されないこと | 規模に追いつけない | その主張が、意図どおりの意味か |
自社でAIに長い仕事を任せるとき、この事例から素直に引けるのは次の5つです。
- 現在地（何が終わって、次に何をやるか）を、AIの記憶の外に置いたか
- やることの一覧は、依存関係の順で引けるか
- 「何をやるか」と「どうやるか」が、別々の場所に分かれているか
- 各項目に、検索して再利用できる自然言語の説明が付いているか
- 「検証済み」と言うとき、何が検証され、何が人の判断に残るかを言葉にできるか
最後の1つが、この事例のいちばん誠実なところだと思います。1,300万行を機械に通しきったうえで、「名前が意味どおりかは、読者が判断すること」と自分で書いてある。検証の強さを語る文書が、同じ場所で検証の届かない範囲を書いている——AIの成果物を外に出す側にとって、真似したい書き方です。
出典・注記
- Anthropic「Formalizing Fermat's Last Theorem」2026年9月4日公開。anthropic.com/research/formalizing-fermats-last-theorem
anthropics/fermats-last-theorem（GitHub・Apache-2.0）のREADME.md／PROOF-PATH.md／formalization.yaml／FinalCheck.lean。リポジトリ作成時刻 2026-09-04T14:21:04Z（GitHub API 実測）。github.com/anthropics/fermats-last-theorem- ディレクトリごとの
.leanファイル数と容量は、GitHub の git tree API で全件を取得して数えた実測値（2026年9月5日時点。応答のtruncatedが false であることを確認済み）。 - Shuze Chen, Kunal Marwaha, Xiaoyang Lu, Henry Yuen, Tianyi Peng「Prove2Me: An Open Collaborative Platform for Scaling Math Formalization」arXiv:2608.28433（v1: 2026年8月28日）。arxiv.org/abs/2608.28433
- 本文の数値は上記の公式発表・リポジトリ・論文に基づくもので、電脳技巧集団が証明のビルドや再検証を行ったものではありません（再検証には約300GBのメモリが必要なため）。当方で実測したのは、リポジトリの構造（ファイル数・容量・作成時刻）のみです。
言語化できるものは、全て作る。
AIに長い仕事を任せる設計から、Webサイト・LP・業務システムまで。成果物 × 定価の透明な見積りでお受けしています。サイトに常駐するAIに、そのままご相談ください。CAGに相談する →
