Leanの証明自動化が実ソフトウェアの試験を通過、ただし証明はまだ本番対応ではない
Leanの証明自動化は、本番ソフトウェアのリリースにはほど遠いものの、7月26日に重要な一線を越えた。セキュリティエンジニアのAdam Langley氏はLeanで動作するZstandardデコンプレッサーを構築し、複数の大規模言語モデルを使って、その最も難しいロジックの周囲に機械検証可能な証明を生成した。
この実験で、より高速なデコンプレッサーや公開ライブラリが生まれたわけではなく、AIがあらゆる大規模アプリケーションを検証できることを示す証拠もない。Langley氏によれば、同氏のバージョンは標準のzstdコマンドより約10倍遅い。また、この実装を学習プロジェクトと位置づけ、コードの公開は控えた。
変化はより限定的だが、重要性は大きい。AIシステムが自明ではないソフトウェアの証明を生成し、Leanがその証明の有効性を独立して確認したのだ。これにより、AI支援検証は流暢な説明やもっともらしいコードの域を超え、極めて厳格な受け入れテストを備えたワークフローへと進んだ。
主要な競争軸は、もはやAI生成コードと人間が書いたコードの対決ではない。確率的な生成と決定論的な検証の対比だ。モデルは推測し、修正し、何度も失敗できる一方で、小さな信頼基盤のチェッカーが完成したプログラムに何を取り込むかを決める。
開発者にとって、このパターンは信頼性の低いコーディングエージェントへの回答となる可能性がある。ナレッジワーカーにとっては、AIに雑多な最初の試みを作らせつつ、受け入れを明示的で機械検証可能な条件に依存させる、より広範な自動化モデルを示唆する。
Zstandardの実験が証明自動化を具体的なものにした
Langley氏のテストが重要なのは、AI生成の証明を、別の孤立した数学ベンチマークではなく、一般的なシステムソフトウェアに適用したからだ。
Leanはプログラミング言語であると同時に、対話型定理証明支援系でもある。その依存型により、プログラムの型に、配列の正確な長さや複数の出力間の関係といった値に関する事実を含められる。
この機能により、関数シグネチャーが保証できる内容が変わる。通常のファイル読み込み関数はバイト配列を返すかもしれない。Leanの関数なら、要求されたバイト数と長さが一致することの証明を伴う配列を返せる。
公式のLean referenceは、このアーキテクチャーがAI生成作業にとって特別な価値を持つ理由を説明している。Leanのタクティクスは複雑で自動化されている場合があるが、それらが生成するすべての証明項は、比較的小さなカーネルを通過する。
欠陥のあるタクティクスは時間を浪費したり、無効な候補を生成したりすることはある。しかし、信頼された基盤自体にも欠陥がない限り、無効な証明を有効にはできない。最終的な権威は生成器ではなくチェッカーにある。
Langley氏がZstandardを選んだのは、意味のある実装上の課題を提供したためだ。通常zstdと呼ばれるZstandardは、LZ77形式のマッチングと2つのエントロピー符号化システムを中心に構築された可逆圧縮形式である。
そのformat specificationでは、リテラルデータにHuffman符号化を、その他のシンボルとHuffmanヘッダーにFinite State Entropy（FSE）を割り当てている。FSEはシンボル間で状態を引き継ぐため、ビットストリームを書き込み順とは逆に復号する必要がある。
この仕組みは、短い2つの算術式が等しいことを証明するよりはるかに要求が厳しい。デコンプレッサーはコンパクトなバイナリー構造を解析し、状態を維持し、無効な入力を拒否し、元のバイト列を正しく再構築しなければならない。
Langley氏のLean experimentは、特にFSEテーブル構築に注目した。このテーブルは、圧縮された状態をどのようにシンボルへ戻すか、またデコーダーが何ビット消費するかを決定する。
報告によれば、複数のLLMはこのテーブル構築コードの重要な性質について、約20分で証明を生成した。Langley氏は、得られた証明がLeanの型チェッカーを通過し、未証明の命題を一時的に認めるLeanの仕組みであるsorry宣言を含まないことを確認した。
モデルは一部の実装上の選択を変更する必要があった。Langley氏は、アルゴリズムの一部をより命令型に表現するためId.runを用いており、それが証明の仕組みを使いにくくしていた。
この詳細は、結果を単純に解釈することを防ぐ。AIは固定されたコードを単に検査して証明書を付けたのではない。証明構築を支えられる形へ実装を再構成する手助けもした。
それでも、この結果は完全なループを生み出した。意味のあるソフトウェアを書き、強い不変条件を述べ、証明を生成し、独立したカーネルにそれを受け入れるか拒否するかを判断させる。このループこそが本当の出来事だ。
Leanの証明自動化は検証コストの問題に挑む
形式検証はこれまでも卓越した保証をもたらしてきたが、証明に必要な労力が、ほとんどの日常的なソフトウェアプロジェクトの外にとどめてきた。
最も明確な歴史的事例は、機械検証済みの証明に支えられた小規模なOSカーネル、seL4だ。その検証済みの性質は、選ばれた入力集合に対するテストの合格をはるかに超える。
当初の検証には4年間で約20人年を要し、200,000行を超えるIsabelle証明スクリプトが作られた。seL4 researchで説明される回顧は、これらの数字を学術的な過剰さとして退けられない理由を示している。
検証チームは、正しい性質を定義し、異なる抽象化レイヤーを接続し、証明を構築し、それらの証明を変化するコードと整合させ続けなければならない。どの作業にも専門知識と慎重なエンジニアリングが必要だ。
見返りは大きい可能性がある。seL4プロジェクトは、2009年に主要な証明が完了して以降、検証済みコードに機能的正しさの欠陥は報告されていない。しかし、ほとんどのソフトウェアチームは、1つのコンポーネントを出荷する前に何年もの専門的労働を投じることはできない。
従来の証明自動化は、この負担の一部を軽減する。タクティクスは既知のパターンを解ける一方、SMTソルバーとして知られるsatisfiability modulo theoriesソルバーは、対応領域の論理条件を解消する。
こうしたシステムは、プログラマーが検証可能なコードを書く方法にも影響する。経験豊富な利用者は、ソルバーが扱える定式化と、一見無害に見えて探索を制御不能に拡大させる構造を学ぶ。
Langley氏は、LLMが柔軟な証明生成器であるため、この経済的方程式を変えると主張する。周囲の定義を読み、エラーメッセージを調べ、局所的なコードを書き換え、中間補題を提案し、拒否された後に別の経路を試せる。
証明の無関係性は、この主張を強める。Leanでは命題は証明無関係な宇宙に存在し、システムは一般に、有効な証明が存在することを重視し、どの有効な証明が提出されたかは重視しない。
人間の証明エンジニアは、明確な証明の方が後の変更にも耐えやすいため、しばしば優美さを重視する。LLMが検証済みの証明を迅速に再生成できるなら、この保守に関する計算は一部変わる。
それでも、証明エンジニアリングが不要になるわけではない。誰かが正しい定理を述べ、信頼境界を定義し、変更のたびの再生成が引き続き手頃かを判断する必要がある。
しかし、これは大きな反論の1つを弱める。開発者がその振る舞いを自信を持って評価できない場合、見栄えの悪い生成コードは危険だ。信頼されたカーネルが無効なバージョンをすべて拒否するなら、見栄えの悪い生成証明はそれほど懸念にならない。
生まれつつあるワークフローは、共同推論というよりコンパイルに似ている。開発者が性質を指定し、エージェントが受け入れ可能な成果物を探索し、チェッカーがビルドの成否を決める。
この違いは、AIがどこに属するかを判断するマネージャーにとって重要だ。関数が安全だと言うコーディング支援ツールは意見を提供する。カーネル検証済みの成果物を返す証明生成支援ツールは、宣言された前提のもとで証拠を提供する。
この区別は新たなボトルネックも明らかにする。証明生成が安価になれば、正しい仕様を書くことが希少なスキルになる。
チームには、要件を正確な不変条件へ翻訳できる人が必要になる。「このパーサーは安全であるべきだ」は検査可能ではない。「成功したすべての解析は、提供された入力バッファーの範囲内にとどまる」は、形式システムが評価できる性質により近い。
ナレッジワーカーにとって、これに相当する作業は、自動化を始める前に受け入れ条件を定義することだ。AIは予測の草案作成、ポリシーの照合、会議メモの統合を行えるが、信頼できる自動化には、何が真であり続けなければならないかについて明確な説明が必要になる。
新たな相手は検証なき生成だ
最も重要な教訓は、LLMが信頼できるようになったことではなく、信頼性の低い生成でも、信頼できる検証ループの中では有用になり得るということだ。
ほとんどの生成AI製品は、利用者に出力を直接判断するよう求める。モデルがメールを書き、会議を要約し、スプレッドシートを編集し、コードを提案する。その後、人間は限られた時間と注意力で微妙な誤りを探す。
このパターンは低リスクの作業では自動化を魅力的にする一方、セキュリティ、金融、コンプライアンス、インフラストラクチャー、不可逆な運用変更では信頼しにくい。流暢な言語は正しさを証明しないため、モデルの自信はほとんど保護にならない。
Leanの証明自動化は2つの仕事を分離する。LLMは可能な証明の広大な空間を探索し、証明支援系は正確なルールに基づく限定的な検証作業を担う。
生成器は定理名を幻覚したり、無効な変換を適用したり、定義を誤解したりする可能性がある。主張される性質と信頼境界が健全である限り、これらの失敗は受け入れられた結論ではなく、拒否された候補になる。
最近の研究は、この分離を中心に構築されたシステムを示している。2026年7月に公開されたOpenProverは、計画、ワーカーエージェント、Leanによる検証を、オープンソースの定理証明システムに組み合わせている。
そのアーキテクチャーは、専門化したエージェントに異なる責任を与えながら、自動的な形式検証を維持する。また、人間による誘導もサポートしており、証明探索がなお専門家の方向付けから恩恵を受けることを認めている。
これは、コードウィンドウを備えたチャットボットとは異なる製品モデルだ。価値ある出力は、証明がなぜ機能するはずかというモデルの説明ではない。独立した検証を通過する証明オブジェクトである。
完全な定理証明が不要な場合でも、同様のパターンは通常のナレッジワークを改善できる。例えば、プロダクトマネージャーがインタビュー、チケット、指標、意思決定から週次更新をまとめる場合を考えてみよう。
LLMは更新文書の草案を迅速に作成できる。しかし、すべての事実主張は情報源に追跡可能であるべきで、すべての指標は日付と定義を保持し、未解決の矛盾は見える状態に保たれるべきだ。
個人向けナレッジシステムは、こうしたつながりを維持する助けになる。例えば、knowledge blendingは、利用者が散在するファイルから再構成することを強いるのではなく、関連するローカル資料を1つの作業コンテキストにまとめられる。
これは数学的な証明と同じものではない。チェッカーは、ソース引用、スキーマ検証、アクセス制御、算術テスト、または人間による承認ステップで構成される場合がある。
ただし、アーキテクチャー上の原則は似ている。生成の自由はゲートの前に置かれる。決定論的なルール、文書化された証拠、または説明責任を伴うレビューが、何を通過させるかを決める。
これは、チームがAIの生産性を評価する方法も変える。草案作成で節約できる時間は、指標の1つにすぎない。レビュー時間、修正頻度、欠陥の流出率、裏付けとなる証拠の質も同じくらい重要だ。
草案を10倍速く作成してもレビューの労力が2倍になるエージェントは、作業を自動化していない。仕事を目に見えにくい段階へ移しただけだ。
対照的に、完全な来歴情報と自動検証を備えた結果を、最初はやや遅く出すエージェントのほうが、より有用な生産性をもたらす可能性がある。その証拠は、後続のすべての読者にとって不確実性を減らす。
Leanでは、受け入れ条件が二値であるため、この原則がひときわ明確に見える。証明はチェックに通るか、通らないかのどちらかだ。大半のオフィス業務自動化にはこのように明確な境界はないが、チームはより小さく、タスクに特化したゲートを設けられる。
財務サマリーでは、すべての合計値が元データのセルと照合できることを必須にできる。契約書比較では、検出されたすべての差異を正確な条項にリンクさせることができる。リサーチブリーフでは、裏付けのない引用が最終文書に入るのを防げる。
こうしたゲートは、基盤となるモデルを誠実にも決定論的にもするわけではない。だが、その弱点を封じ込めやすくする。
Zstandardテストが証明していないこと
この実験は有望な仕組みを検証しているが、AIが大規模な本番システムを低コストかつ完全に検証できることを立証するものではない。
最も明白な限界はスコープにある。Langleyはこのデコンプレッサーを玩具だと呼び、コードは非公開であり、他のLeanプログラマーの手本として提示しているわけでもない。
そのため、独立したレビュー担当者が結果を再現したり、正確な定理文を検討したり、未検証のコンポーネントを特定したりすることはできない。著者の報告に基づけば、選択された証明が型チェックを通過したことは分かる。
しかし、それらの文が本番用デコンプレッサーに必要なすべての性質をカバーしているかは分からない。不完全な仕様に対する完全に有効な証明は、その仕様の外側に深刻な欠陥が存在することと両立しうる。
これはしばしば仕様問題と呼ばれる。チェッカーはコードが形式的な文を満たすことを確立できるが、人間が正しい文を選んだかどうかは判断できない。
デコンプレッサーは、有効な入力が正しくラウンドトリップすることを証明できても、メモリー枯渇、サービス拒否への耐性、リソース制限、アーカイブ解析を定理の対象外に残す可能性がある。省かれた境界の一つひとつが、失敗の余地を生む。
信頼できるコンピューティング基盤も重要だ。Leanの小さなカーネルは、信頼すべきコンポーネントを大幅に減らすが、実際のプログラムはコンパイラー、オペレーティングシステム、外部関数、ハードウェア、外部ライブラリーと相互作用する。
Langleyは、Leanのextern機構を通じて最適化済みアセンブリーを呼び出す方法を検討した。小規模な等価性の例では動作したが、このアプローチを拡張しようとした試みでは、深刻なメモリー要件に直面するか、進展しなかったと報告されている。
この結果は、中心的なトレードオフを浮き彫りにしている。高水準の検証済みコードは強い論理的保証を提供できる一方、本番環境での性能は、多くの場合、直接の証明の範囲を超えた低水準実装とツールに依存する。
Zstandardの実装自体が、この隔たりを示している。Langleyによれば、彼のLeanデコーダーは標準のコマンドライン実装のおよそ10倍遅い。
圧縮ソフトウェアにとって、性能は些細な懸念ではない。デコンプレッションはしばしば、ストレージ、パッケージ配布、データベース、ネットワーク転送に関わるレイテンシーに敏感な経路に位置する。
証明の保守についても、依然として不確実性がある。Langleyは、迅速な再生成によって、将来の変更に備えて証明を慎重に設計する必要性を減らせる可能性を示唆している。
限定されたプロジェクトなら、それはもっともらしい。大規模なコードベースでは、相互依存する義務が数千件生じる可能性があり、小さな型変更がモジュール全体に広がり、エージェントのコンテキストや探索予算を圧倒しかねない。
研究ベンチマークだけで、この問題を決着させるべきではない。数学の定理コレクションには通常、明示的な目標と統制された環境がある。本番コードには、部分的な仕様、レガシーインターフェース、変化する依存関係、文書化されていない前提が含まれる。
人的要因に関するリスクもある。証明生成が容易になると、緑色のチェックマークが一つでも付けば包括的な保証だとみなす圧力が生まれかねない。
チェック済みの定理が述べるのは、形式的な文が正確に述べていることだけだ。セキュリティ、プライバシー、信頼性、業務上の正しさは、それらの性質がモデルに含まれていない限り、何も保証しない。
したがってチームは、現在コードレビューに向けられているのと同じ真剣さで仕様をレビューしなければならない。そうしなければ、AIは不完全な問いに対するもっともらしい回答の生産を加速するだけになる。
AIによる証明自動化はボトルネックを仕様へ移す
モデルが有能な証明生成器になれば、価値ある知的労働は成果物の構築から、主張と境界の定義へと移行する。
ソフトウェアチームはすでに、この移行の一端を経験している。コーディングエージェントは、関数、テスト、マイグレーション、ドキュメントを作成するコストを下げている。
出力が安価になるほど、何を構築すべきかを決めることの重要性は増す。要件、インターフェース、制約、脅威モデル、受け入れテストが、高速な生成が価値を生むのか、それとも確認すべき材料を増やすだけなのかを決める。
Leanはこの変化を正しさに関する主張へと拡張する。プログラマーは不変条件を型にエンコードし、LLMに証明の構築を依頼し、カーネルにその結果を検証させることができる。
最もレバレッジの高い人間の貢献は、多くの場合で上流にある。誰かがどの不変条件が重要かを見極め、抜け穴なく表現し、実際の運用環境に対応付けなければならない。
知識労働者も、より形式性の低いツールで同じ構造に直面している。アナリストは、市場に関する主張にどの証拠が適格かを決める必要がある。採用担当者は、どの候補者基準が合法かつ関連性があるかを定義する必要がある。
サポートマネージャーは、自動返信を送信できる条件と、エスカレーションを要するケースを明記しなければならない。研究者は、一次資料、二次的な要約、裏付けのない推論を区別しなければならない。
誰もLeanで書かなくても、これらは仕様の仕事である。曖昧な期待を観測可能な条件へと変える。
組織は、判断ルールを対象となる文書と並べて記録することで準備できる。「最新の顧客数を使用する」というメモは曖昧だ。権威あるダッシュボード、更新時刻、地域、報告期間を指定するルールはテスト可能である。
来歴情報も同様に重要になる。日付、所有者、バージョン、過去の意思決定との関係を失ったソース資料を、モデルがチームの知識として確実に照合することはできない。
このため、チャットインターフェースからエージェントシステムへの移行には、より優れた情報アーキテクチャが必要となる。エージェントには、構造化されたコンテキスト、権限、検証ルール、変更内容の永続的な記録が必要だ。
人間によるレビューも例外に向けるべきである。AIが生成したあらゆる文を一行ずつ確認しなければならないなら、そのシステムは自動化レイヤーではなく、依然としてアシスタントにとどまる。
有用なゲートは、明示的な条件を満たす定型ケースを自動承認できる。人間はその後、不足している証拠、矛盾する情報源、異常な値、セキュリティに敏感な操作、既知のパターン外の変更に集中できる。
形式的証明支援系はこのワークフローの最も強力な形を提供するが、すべてのタスクに適しているわけではない。多くの判断は、判断力、争いのある定義、不完全な情報に依存する。
目標は、すべてのメールを形式化することではない。失敗が現実的なコストをもたらす主張を特定し、それらに見合ったチェックを構築することだ。
ソフトウェアでは、ユーザーインターフェースを従来どおりテストしながら、パーサーの境界安全性を証明することかもしれない。オペレーションチームでは、支払い合計を自動照合しつつ、送金には人間の承認を求めることかもしれない。
研究者にとっては、すべての引用と引用箇所を検証しながら、解釈は議論に開かれたままにすることかもしれない。検証は、最も重要な境界を保護すべきである。
Langleyの実験は、この設計戦略をより想像しやすくする。LLMが完璧な数学者になる必要はなかった。より厳格なシステムが評価できる成果物を生成すればよかったのだ。
これは、モデルが誤りを犯さなくなるのを待つよりも、エンタープライズAIにとって現実的な道筋である。
この変化が本物かを示す三つのシグナル
次の段階を左右するのは、もう一つの印象的な単発の証明ではなく、再現性、規模、測定可能な保守コストである。
第一のシグナルは、一般的な検証済みソフトウェアについて、公開され再現可能なコーパスが現れることだ。ソースと証明が利用できないため、Langleyのデコンプレッサーはその役割を果たせない。
lean-zipのようなプロジェクトは、より検証しやすい参照例を提供する。Leanの共同開発者であるLeonardo de Mouraは最近、圧縮とデコンプレッションの両方を実装した検証済み圧縮プロジェクトとしてこれを紹介した。
今後のプロジェクトには、正確な定理文、文書化された前提、性能測定、確立された実装に対するテストが必要だ。独立したチームが各証明を再構築し、どのモジュールが検証境界の外に残るかを特定できるべきである。
パーサー、ネットワークコード、ストレージ形式、暗号関連のサポートなどで複数のプロジェクトがこのパターンを繰り返せば、Leanの証明自動化を支持する根拠は強まる。結果が小規模なデモに集中したままなら、より広範な主張は弱まる。
第二のシグナルは、実際のコード変更後に証明生成がどのように振る舞うかだ。初期の証明構築は注目を集めるが、経済性を決めるのは保守である。
チームは、リファクタリング、依存関係の更新、仕様変更、性能最適化の後にかかる再生成時間を測定すべきだ。また、人間の専門家がコードを再構成したり、中間補題を考案したりしなければならない頻度も記録すべきである。
安定した定理で素早く成功しても、生きたアプリケーションに関する証拠としては限定的だ。有用なシステムは、通常の開発を何か月も続けても、すべてのプルリクエストを予測不能な証明探索プロジェクトに変えることなく耐えなければならない。
証明コストが抑えられ、失敗が実行可能な診断を生むなら、AI生成の検証は継続的インテグレーションに組み込める。小さな変更で何時間もの不透明な探索が発生するなら、導入は限定的なままだろう。
第三のシグナルは、主流のコーディングエージェントへの統合である。現在、証明生成は研究ワークフローや専門的なLean環境に近い位置にある。
実用上の転換点は、エージェントが不変条件を提案し、その適用範囲を説明し、証明を生成し、チェッカーを実行し、未検証のまま残る前提を正確に示せるようになったときに訪れる。
そのインターフェースは、誤った安心感を防がなければならない。テスト済みの振る舞いと証明済みの振る舞い、検証済みモジュールと未検証ラッパーを区別すべきである。
また、定理の変更を非常に目立つ形で示す必要がある。エージェントは、ユーザーが保持されると期待した性質を密かに弱めて、失敗した証明を「修正」してはならない。
知識労働者にとって、これらのシグナルは単純な調達基準に置き換えられる。AI製品が回答を生成するだけなのか、それとも強制可能な受け入れ条件を備えた回答を生み出すのかを尋ねるべきだ。
ソースレベルの来歴情報、権限チェック、構造化された検証、再現可能な変換、明確なエスカレーション経路を探すべきである。こうした統制のない洗練された応答は、どれほど自信に満ちて聞こえても、下書きにすぎない。
Leanの証明自動化は、AIがいまや単独で信頼できることの証明ではない。主張が明示的で、検証が独立しているとき、AIを中心に信頼を設計できることを示す証拠である。
次のプロジェクトに向けた問いは実践的だ。どの反復的な判断が、実質的な受け入れゲートを正当化するほどのリスクを生むのか。そこから始め、維持すべきことを定義し、自動化にすべての緑色のチェックマークを獲得させよう。
