- 11個の正方形の最適詰め込み証明をLean 4で形式化し、検証を完了
- 7,920個のローカルLeanモジュールをすべて受理、最終監査のadmissionはゼロ
- 高コストな数値証明書チェックにnative_decideを使用、カーネルだけでは検証しない
何が形式化されたか
公開されたのは、11個の単位正方形を最小の正方形に詰め込む問題(最適詰め込み問題)の最適性を、証明支援系Lean 4で完全に形式化したリポジトリである。形式化された定理は、正方形の向きが任意でよく、境界での接触が合法であり、内部が互いに素であるというモデルの下で成り立つ。公開されている定理文(ElevenSquare/Optimality.lean)とT03ソースツリーは、このリポジトリの以前のmainブランチから変更されていないと説明されている。
検証はEvolvingProgramsの実行環境で行われ、7,920個のローカルLeanモジュールすべてが受理されたと報告されている。最終監査ではadmissionがゼロであり、証明のソース、レシート、依存関係、公理の監査も通過したとされる。
最適な辺の長さ
最適な正方形の辺の長さTは、(6u+4)/(1+2u−u²)で与えられると記されている。ここでuは、5u⁸−10u⁷−2u⁶+14u⁵+12u⁴−6u³+2u²+2u−1=0の(9/25, 37/100)区間における唯一の根である。この構成が達成する値は約3.8770835900228141773と示されている。
検証の信頼モデル
この形式化では、幾何、チェッカーの健全性、証明の組み立ては通常のLean証明で構成されている。一方、高コストで厳密な数値証明書のチェックの一部にはnative_decideが使われている。そのため最終定理が信頼するのはLeanのカーネルとネイティブコンパイラであり、「カーネルだけで検証した」という主張ではない点が明記されている。承認された数値宣言とそのソースハッシュはverification/native-certificates.jsonに記録されている。
再現手順と注意点
再現にはLean 4.34.1とMathlibのリビジョンd13f23b723b8a846827a245b89c10fc7d3f11612が固定されており、lake-manifest.jsonを変更しないことが求められる。LinuxまたはmacOSでスクリプトを実行し、オプションを付けると完全に再実行できる。検証成功の条件はOPTIMALITY_PROVED_WITH_NATIVE_CERTIFICATES、admissionゼロ、trust_model: lean_kernel_and_native_compilerであり、コンパイル済みモジュールが100%に達しただけでは不十分とされている。
なお、ソースのみのチェックは別のスクリプトで行える。成功した実行はEvolvingProgramsのより大きなランナーを用いたもので、コールドビルドの実行時間やmacOSでの2〜3時間という保証を示すものではないと注意されている。このスナップショットでは、過去のmaterializationコマンドやverify.py --setupを実行しないよう指示されている。
| 検証対象 | 検証方法 |
|---|---|
| 幾何・チェッカー健全性・証明の組み立て | 通常のLean証明 |
| 高コストな厳密数値証明書のチェック | native_decide(ネイティブ実行) |
Selected expensive, exact numerical certificate checks use native_decide. Geometry, checker soundness, and proof assembly retain ordinary Lean proofs.
高コストで厳密な数値証明書チェックの一部にはnative_decideを用いる。幾何、チェッカーの健全性、証明の組み立ては通常のLean証明のままとする。
今後の見通し
今回のリポジトリは、証明のソースと固定されたビルド構成を公開し、再現手順と検証条件を明示している。今後は、同様の手法が他の詰め込み問題や離散幾何の定理に広がるかが注目される。特に、native_decideをどこまで使うかという信頼モデルの線引きは、形式化コミュニティで議論になりそうだ。カーネルだけで完結する検証が将来的に可能になるのか、あるいは数値計算を伴う証明ではネイティブ検証が標準になるのかが明らかになれば、実務での採用判断がしやすくなる。コールドビルドの所要時間が公表されれば、再現コストの評価にもつながるとみられる。
日本の開発者・IT企業にとっての意味
日本のIT企業や開発者にとって、この事例は「形式手法をどこまで実務に取り込めるか」を考える材料になる。Lean 4のような証明支援系は、アルゴリズムの正しさや数値計算の境界条件を機械的に検証する用途に使える。今回のように、幾何や論理の部分は通常の証明で、計算コストの高い部分はネイティブ実行に委ねるという分担は、性能と信頼性のトレードオフをどう設計するかの参考になる。また、検証条件や信頼モデルを明示し、ソースハッシュとビルド構成を固定して再現可能にする運用は、セキュリティや安全性が重視される領域の開発プロセスにも応用できる。将来的に自社システムの重要ロジックを形式化する際、どこまでをカーネルに信頼させるかを判断する出発点になるとみられる。
気になる点
- この証明はどこまで信頼できるのか
- 幾何やチェッカーの健全性、証明の組み立ては通常のLean証明で構成されていますが、高コストな数値証明書のチェックにはnative_decideが使われています。そのため証明全体はLeanのカーネルとネイティブコンパイラの両方を信頼する立場になります。カーネルだけで検証した主張ではない点が明記されています。
- 自分の環境で再現できるのか
- リポジトリには再現手順が用意されています。Lean 4.34.1と特定のMathlibリビジョン、Python 3、Git、curl、tarが必要で、LinuxまたはmacOSでスクリプトを実行します。ただし成功した実行はEvolvingProgramsのより大きなランナーを使ったもので、一般的なマシンでの実行時間は保証されていないとされています。
- AIが証明を作ったのか
- Hacker Newsでは「AI-assisted(AI支援)」という題で投稿されていますが、リポジトリ本文にはAIの関与を具体的に説明する記述は見当たりません。EvolvingProgramsとコントリビューターへの謝辞は記載されており、AIがどこまで関与したかは現時点では公表されていないとみられます。
用語解説
- Lean 4
- 定理証明支援系を兼ねた関数型プログラミング言語。数学的な証明をコンピュータで検証できる。
- Mathlib
- Lean向けの大規模な数学ライブラリ。定義や定理があらかじめ整備されている。
- native_decide
- Leanの証明手順(タクティク)の一つ。ネイティブコードを実行して数値的な命題を判定する。
- カーネル
- Leanの証明を最終的に検査する中核部分。ここを通れば証明は正しいとみなされる。
- 最適詰め込み問題
- 与えられた図形を、できるだけ小さい領域に重なりなく配置する問題。
出典
AI-assisted proof of optimal packing for 11 squares
AI導入も顧問も、お任せください
何から手をつけるか、どこまでAIに任せるか。自社の業務に合わせて整理し、導入から運用まで伴走します。相談だけでも構いません。
AI導入について相談する