すでに真実である事柄を書き留めることで、数十の Claude エージェントがフェルマーの最終定理を証明 (2026年)

設定：「数十の Claude エージェントが協力して概念を定義し、中間定理を証明し、それらの定理を使用してさらに難解な命題を証明しました。」ハーネスは Claude Code ベースであり、実行には「Claude Fable 5.1 にほぼ匹敵する汎用の内部研究モデルから約60億の出力トークン」が消費されました。人間による数学的な入力は最小限でした。Anthropic はそのすべてを次のように引用しています。「スキームとしてのヤコビアンは優先度が高そうだ」「マズールの定理を早めに終わらせるようプッシュしてくれ」

そして失敗と、その修正。「この取り組みは、コロンビア大学の Tianyi Peng 氏とその共同研究者らによって設計された、数学の定式化のためのオープンな共同プラットフォームである Prove2Me の使用に切り替えたことで成功しました。」Anthropic は、Prove2Me が貢献した内容を正確に3つの箇条書きでリストアップしています：

「エージェントが次にどの証明を試みるべきかを決定するために使用する、定理命題の有向非巡回グラフ（DAG）を維持すること。これは、記憶の劣化を軽減し、複数のエージェントが並行して作業できるようにする上で特に役立ちました。」

「定理の命題と証明を異なるファイルに分離し、それらの間のリンクを独立して維持することで、Lean のコンパイルを高速化し、リソース消費を最小限に抑えること。」

「各定理命題の自然言語による説明を維持することで、検索と再利用を可能にし、結果としてよりシンプルな証明経路を実現すること。」

これらを、数学ツールの3つの機能としてではなく、ストア（保存領域）の3つの特性として捉えてみてください。

1つ目は、依存関係構造を伴う外部化です。何が証明され、それぞれの結果が何に依存しているかの記録は、すべてのエージェントの外部に存在します。これが解決した問題に対する Anthropic の表現は、記憶に留めておく価値があります。「記憶の劣化を軽減する（mitigating memory degradation）」という言葉です。「作業の調整」ではなく、エージェントが保持していた記憶の劣化を軽減することだったのです。

2つ目は、主張と証拠の分離です。命題はある場所に、証明は別の場所に置かれ、「それらの間のリンクは独立して維持」されます。Anthropic はそのメリットをコンパイル速度とリソース消費の観点から説明しており、それは事実です。エージェントにとっての帰結は、証明の本体を引きずることなく、確立された主張のセット全体を読み取ることができる点にあります。コーパスが1,300万行を超えて成長しても、インデックスの参照コストは低いままに保たれます。

3つ目は、検索のための平易な言葉による説明です。すべての定理命題には自然言語による説明が付随しており、その目的は「検索と再利用を可能にすること」とされています。数式などの厳密な命題は、正確ではあるものの検索には極めて不向きです。説明は不正確かもしれませんが、見つけやすいものです。これがないと、すでに存在する結果を必要とするエージェントがそれを見つけることができず、再度証明してしまうことになります。

そして、これらの中でどれが最も重要であったかを最もよく物語る詳細があります。Anthropic は、全体の縮小版を実行しました。「Anthropic の研究者は、3つの個人向け Claude Max プランを使用して、ハーディ・リトルウッドの円法（Hardy-Littlewood Circle Method）の応用を定式化する小規模な実験を行いました。エージェントは完全に Prove2Me を介して協力し、わずか3日間でヴィノグラードフの3素数定理（Vinogradov's Three Primes Theorem）の定式化を共同で完了しました。」彼らの結論はこうです。「適切な足場があれば、コンシューマー向け AI サブスクリプションを利用した主要な結果の共同定式化は達成可能であると考えています。」

3つのコンシューマー向けサブスクリプションと、同じ足場によって、わずか3日間で有名な定理が導き出されました。その足場が、作業の大部分を担っていたのです。

これは、エージェントが能力を発揮するために外部記憶が必要であることを示すものではありません。エージェントは、失敗した試みにおいてさえ極めて優秀でした。Anthropic は、失敗した作業であっても、最終的な証明における定型文（ボイラープレート）以外の行の実質的な割合を占め、貢献していたと指摘しています。能力がボトルネックになったことは一度もありませんでした。

これは、規模が拡大したときに何が最初に破綻するかを示しています。そしてそれは推論能力ではありません。「何がすでに真実であるかを知ること」です。Prove2Me の3つの特性はすべて、この問いに関連しています。何が確立されているか、それは何に依存しているか、そしてそれを見つけることができるか。実行に数十の参加者と3万件の確立された結果が関わるようになると、「私たちはすでに何を知っているか」が支配的なコストになり、どの参加者もその答えを保持できなくなります。

コンテキストウィンドウが無関係であるという意味ではありません。ウィンドウが大きければ、個々のエージェントが1セッションあたりに実行できることが増えます。しかし、これほどの規模には対応できません。1,300万行 of Lean コードと30,300個の証明された定理は、現実的などのようなサイズであってもコンテキストウィンドウの問題ではなく、さらに重要なことに、それは検索の解決策ではありません。ウィンドウ内に資料があることと、そのどの部分が現在の疑問を解決するかを知っていることは同じではないからです。この区別こそが、なぜ長いコンテキストは記憶ではないのか で展開されている議論のすべてです。

また、これがすべてのエージェントの記憶に関する主張に一般化できるわけでもありません。形式数学は、共有レコードにとって例外的に相性の良い領域です。命題は曖昧さがなく、依存関係は明示的であり、チェッカーが真偽を判定します。あなたのコードベースには、これらの特性は一つもありません。移植できるのは DAG ではなく、どこでも通用する3つの特性です。

「これはToDoリストだ」 DAG は「次に何をすべきか」に答える部分であり、3つの特性の中で最も移植性が低いものです。あなたの仕事は、証明可能な命題の依存関係グラフに分解できるわけではありません。移植可能な部分は、主張と証拠の分離、および平易な言葉による説明であり、これらはどちらも作業の割り当てではなく、解決済みの事柄を見つけることに関するものです。

「だからグラフデータベースが必要だ」 いいえ。グラフが存在するのは、定理の依存関係が純粋にグラフだからです。あなたに必要なのは、参照コストが低く、検索可能な、確立された結論の記録です。データ構造は、あなたのドメインに応じて決まります。

「コンシューマープランで十分になった」 Anthropic はもっと限定的な言い方をしており、予防線を張っています。適切な足場があれば、共同定式化は「達成可能である」と。この主張は足場がもたらすレバレッジについてのものであり、プランの階層が互換可能であるという意味ではありません。

「Claude には記憶の問題がある」 自社の失敗した試みを公開した企業に対する誤った解釈です。Anthropic は自社製品全体で記憶機能をドキュメント化しており、今回の実行ではカスタムハーネス内の内部研究モデルが使用されました。正確な表現はアーキテクチャに関するものであり、すべてのベンダーに当てはまります。1つの成果物に対して11日間にわたり並行して作業する数十のエージェントは、確立された事柄の共有され成長し続ける記録を保持することはできず、その解決策は、その記録をすべてのエージェントの外部に置くことです。Anthropic が進んで失敗を公開したからこそ、この知見が役立つのです。

ステップ 1: 結論を書き留め、それを生み出した作業とは別に保管する

通常のプロジェクトにとって最も重要な Prove2Me のアプローチは、命題と証明を分離し、「それらの間のリンクを独立して維持する」ことです。エンジニアリングにおけるこれに相当するのは、結論を1つの場所に保管し、証拠はそれがすでに存在する場所に置いておくことです。

結論は1文です。「照合ジョブはバッチエンドポイントを使用してはならない。」証拠は、インシデントチケット、プルリクエスト、またはそれを解決したスレッドです。証拠を記録にコピーするのではなく、リンクしてください。制約を知る必要があるエージェントは、1文を読むだけで済みます。理由を知る必要があるエージェントは、1文を読んだ後、1つのリンクをたどります。

これこそが、記録が成長しても使い続けられるようにするための規律です。よくある失敗はその逆です。文字起こしや長いドキュメントでいっぱいのストアであり、解決済みの答えを見つけるために議論全体を読み直さなければなりません。それは単なるアーカイブであり、すべてのアーカイブは何も解決しません。

ステップ 2: 実際に実行する検索を想定して、すべてのエントリに平易な言葉による説明を付ける

Prove2Me は、特に「検索と再利用」を可能にするために、各定理命題に自然言語の説明を添付しました。形式的な命題はすでにそこにありましたが、見つけることができなかったのです。

あなたの同様の問題はさらに深刻です。なぜなら、あなたの結論はすでに文章で書かれており、それによって検索可能であると思い込んでしまうからです。しかし、その文章が書いた当日の語彙を使用している場合、検索は機能しません。「ストリーミングパーサーの決定」というタイトルの記録エントリは、6ヶ月後にインジェストパスのメモリ回帰に取り組んでいるエージェントには見つけられないでしょう。

障害の症状を含め、誰かがそれを探すときに使うであろう言葉で説明を書いてください。「インジェストパスはバッチローダーではなくストリーミングパーサーを使用する。バッチローダーはペイロード全体をメモリに保持するため、大容量のアップロード時に OOM による再起動を引き起こしたため。」これは冗長に思えるかもしれませんが、まさにこれによって検索可能になるのです。

ステップ 3: すべての参加者が同じコピーを読み取れる場所に置く

失敗した試みは、各エージェントが独自の全体像を維持していたために失敗しました。1つの共有された外部記録が解決策でした。そして「共有」には、後から追加する参加者や人間も含まれなければなりません。

実用上、これは1つのツールに組み込まれるのではなく、プロトコルを介してアクセス可能な1つのストアを意味します。記録が1つのリポジトリのフォルダ内にある場合、隣のサービスのエージェントはそれを見ることができません。1つのエディタのローカルストアにある場合、チームメイトは見ることができません。これらはどちらも、優れた記録が静かに個人のものになってしまう原因であり、Claude Code のエージェントチームとコンテキスト で説明した失敗モードそのものです。

MemoryLake は、これら3つの特性を中心に構築されたストアです。結論は背景にある資料とは別に保持され、ファイリングのためではなく検索のために記述され、プロジェクトのすべてのエージェントと人間が1つのインターフェースを介して読み取ることができます。これは証明アシスタントではなく、形式的検証を行うものでもありません。Anthropic の実行に不可欠だったレイヤーの、通常の業務向けバージョンです。

ステップ 1: API キーを作成する

キーを生成し、約30秒で最初のリクエストを送信します。1つのキーこそが、「すべての参加者が同じコピーを読み取る」ということを、単なる願望ではなく現実に変えるものです。

ステップ 2: 最初の記憶をアップロードする

事後分析（ポストモーテム）、アーキテクチャ決定レコード、誰もが引用するデザインレビューなど、すでに解決済みの結論が保持されているドキュメント、画像、ファイルをドロップします。次に、それらのドキュメントが実際に確立した1行の結論を追加し、長いドキュメントを読まなくても短いバージョンを検索できるようにします。

ステップ 3: AI とエージェントを接続する

Claude、Codex、OpenClaw、その他のエージェントに MCP または API 経由でアクセスを許可します。タスクの開始時に読み取り、決定が下されたときに結論を書き戻すことで、ドキュメント作成の日をスケジュールすることなく、記録を最新の状態に保つことができます。

並行して動作するエージェントが作業を重複させなくなります。これは Anthropic が報告したまさにそのメリット（DAG が「複数のエージェントが並行して作業できるようにした」）であり、グラフを必要としません。必要なのは、何かを解決しようとしているエージェントが、それがすでに解決されているかどうかを知ることができる点です。

長期プロジェクトの劣化が止まります。「記憶の劣化」は、エージェントを多用するプロジェクトの3週目あたりに起こる現象をうまく表現しています。共有された理解が薄れ、同じ質問がより不十分な情報で再議論されるようになります。外部記録がすべてを解決するわけではありませんが、何が決定されたかを誰も説明できないという種類の問題は排除されます。

モデルの変更がリセットではなくなります。FLT の実行では、カスタムハーネス内の1つの内部モデルが使用されましたが、あなたのプロジェクトでは年に数回モデルが変更されるでしょう。記録が外部にある場合、変更は蓄積された知識ではなく、速度とコストに影響を与えるだけになります。

そして、参加者を追加するコストが低下します。Anthropic の3つのサブスクリプションによる実験は、この投稿におけるその最も強力な証拠です。足場のおかげで、小規模なセットアップでも深刻な問題に対して生産性を発揮できました。本物の記録があるプロジェクトに参加する新しいエンジニアや新しいエージェントは、1ヶ月間コンテキストを吸収する代わりに、初日から仕事をこなすことができます。

結論は1文にする。 段落が必要な場合、その段落は証拠であり、リンクの先に置くべきです。

常に理由を添付する。 理由のない結論は単なるルールであり、ルールは上書きされてしまいます。Anthropic のエージェントが依存関係を必要としたのも同じ理由です。正当化できない結果は、安全に積み重ねることができない結果だからです。

後で実行する検索を想定して記述する。 解決した当日の語彙ではなく、障害の症状や問題の語彙を含めてください。

代替を明示的に記録する。 決定が覆った場合は、その旨と時期を明記してください。古いバージョンを黙って削除する記録では、新しいバージョンを説明できません。

単一のリポジトリやエディタの外部に保管する。 いずれか1つのローカルになった瞬間、それは共有されなくなり、共有こそが解決策のすべてだったのです。

主要な成果は数学的なものであり、注目に値します。フェルマーの最終定理の、コンピュータによって検証された初の完全な証明が11日間で作成され、Mathlib 自身の定理命題に対して Lean によって検証されました。証明が完了した瞬間の Claude の思考に関する Anthropic の抜粋（「prove2me で FLT のルートが PROVED と表示されている」）は、非常に感慨深いものです。

運用上の成果はより小さく、より移植性に優れています。最初の試みは、数十のエージェントが「すぐにプロジェクトの状態を見失った」ために失敗しました。それを解決したのは、すべてのエージェントの外部にあり、3つの特性を持つ記録でした。結果の上に結果を積み重ねられる依存関係構造、記録の読み取りコストを低く抑えるために背景にある証拠とは別に保管された主張、そしてすでに確立されたものを再び見つけられるようにするためのすべてのエントリへの平易な言葉による説明です。そして、3つのコンシューマー向けサブスクリプションで動作する同じ足場が、わずか3日間で別の有名な定理を導き出しました。

これらはどれも数学に関するものではありません。複数の参加者が関わる長期プロジェクトにおいては、制約となるのは能力ではなく、「何がすでに真実であるかを知ること」になるという事実についてです。Anthropic の実行には、それを書き留める場所が必要でした。あなたのプロジェクトにも必要なのです。