# AIがコードを書く時代、誰が正しさを証明するのか

- 番組: [The Data Exchange with Ben Lorica](https://ai-curator.jp/podcasts/shows/cmv3z5c0q000m5o10xxr4slsk)（Ben Lorica）
- 元のタイトル: When AI Writes the Code, Who Proves It Works?
- 配信日: 2026年10月29日
- 長さ: 46分
- 要約作成日: 2026年10月29日
- トピック: [#Lean](https://ai-curator.jp/topics/Lean) [#形式検証](https://ai-curator.jp/topics/%E5%BD%A2%E5%BC%8F%E6%A4%9C%E8%A8%BC) [#自動形式化](https://ai-curator.jp/topics/%E8%87%AA%E5%8B%95%E5%BD%A2%E5%BC%8F%E5%8C%96) [#AIエージェント](https://ai-curator.jp/topics/AI%E3%82%A8%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%B3%E3%83%88) [#数学のAI活用](https://ai-curator.jp/topics/%E6%95%B0%E5%AD%A6%E3%81%AEAI%E6%B4%BB%E7%94%A8) [#ソフトウェア工学](https://ai-curator.jp/topics/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E5%B7%A5%E5%AD%A6)
- URL: https://ai-curator.jp/podcasts/cmvtg6m8l00014e11ae88qejg

## 要約

Lean の生みの親である Leo de Moura 氏が、AI による自動形式化（auto-formalization）で形式検証が身近になりつつあると語った回。機械検証可能な証明がテストでは得られない「バグがないこと」の保証を与え、人間の役割は仕様やプロパティの記述へ移るという見方を示した。数学・エージェント・物理・金融など応用領域や、信頼の限界（モデルの忠実性、カーネル）も議論された。

## ポイント

- Lean はプログラミング言語兼証明支援系で、証明は小さなカーネルで機械検証される。複数の独立カーネル（うち2つは検証済み）があり、信頼の問題に対処している。
- テストはバグの存在を示せても不在は示せない。形式検証は「すべての入力」に対して性質を証明する点が異なり、両者は補完関係にあると述べている。
- フロンティアモデルが任意の言語のコードを Lean にモデル化できるようになり、Claude Code のバグ発見の例のように、すぐ価値が得られる点が普及を後押ししている。
- 残る課題は、Lean モデルが実コードに忠実か、そして仕様が本当に望む性質かどうか。今後は仕様・プロパティ記述に人間の重点が移ると予想している。
- 形式検証済みと主張するベンダーには、どの性質を、どの仕様に対し、どのカーネルで検証したか、信頼すべきコード基盤の大きさを尋ねるべきだと述べている。
- 数学では Mathlib が人手で約250万行なのに対し、AI生成の Lean 証明は約5000万行に達したと語る。物理・金融・化学・法の一部にも広がる可能性があるとした。

## 章立て

- [01:06] **Lean と形式検証の基本** — Lean は言語と証明支援系を兼ね、証明は小さなカーネルで機械検証される。複数のチェッカーが人間とAIの間の信頼ボトルネックに対処する。
- [03:07] **AIによる自動形式化と実例** — 仕様を先に書きAIに実装と証明を任せる流れや、zlib の Lean 移植、Aeneas による Rust 検証、Mathlib と AI 生成証明の規模を紹介。
- [07:30] **モデルの忠実性とバグ発見** — Lean モデルが実コードに忠実かという課題と差分テスト、Claude Code のバグ発見の例、Navier-Stokes の証明をめぐる議論を取り上げる。
- [12:40] **テストとの違い、仕様が主役に** — テストは不在を示せないこと、証明がAIの最適化のガードレールになること、仕様書がソース管理の中心になる展望を語る。
- [26:00] **信頼の問い方とエージェント検証** — ベンダーへの確認項目、複数カーネルによる防御、サンドボックスやポリシー実行コードの検証など、エージェント時代の形式検証を論じる。
- [32:32] **数学・物理への波及と人間の役割** — Mathlib と Terence Tao のプロジェクト、物理ライブラリ PhysLib、数学者の反応、計算資源が競争力を左右する可能性を議論。
- [41:56] **金融・法など他分野の可能性** — 金融、化学、生物学、法の手続き部分など、形式化が進みうる領域と、主観性や秘匿性という障壁を話した。

## 解説記事

AWS の Automated Reasoning Group で VP 兼 Distinguished Scientist を務め、Lean の生みの親でもある Leo de Moura 氏が、Ben Lorica 氏のポッドキャストで登場した。テーマは「コード生成が容易になった今、その正しさを誰がどう保証するのか」。de Moura 氏は、AI が形式検証のハードルを下げ、ソフトウェア開発や数学の進め方を変えつつあるという見方を示した。

#### 形式検証が加えるもの

Lean はプログラミング言語であると同時に証明支援系で、コードの性質を記述し、その証明を機械検証できる。結果を信頼するために信じるべきなのは、証明をチェックする小さな「カーネル」だけだという。証明はデータとして扱えるため、別のチェッカーに出力して検証でき、すでに2つの検証済みチェッカーがあり3つ目も近いと述べている。

テストはバグの存在は示せるが不在は示せない、というのが de Moura 氏の整理だ。形式検証なら、試した入力だけでなく「あらゆる入力」でプログラムが正しく動くことを証明できる。ただしテストを否定するのではなく、証明しようとする対象がそもそも誤りでは無駄になるため、テストで確信を高めてから証明に進むのが良いと、両者は補完関係にあると強調した。

#### AIが変えたこと：自動形式化

従来、形式検証が普及しなかったのは手作業で証明するコストが高すぎたためだと同氏は言う。いまはフロンティアモデルが、どの言語で書かれたコードでも Lean 上のモデルに変換できるようになった。数年前なら「SFだ」と思っただろうと語っている。数学では、論文の内容を Lean に翻訳する作業が自動形式化と呼ばれる。

具体例として、同僚の Kim Morrison 氏が圧縮ライブラリ zlib を Lean に移植し、「圧縮して展開すれば元のデータに戻る」という性質を定理として証明した事例が挙がった。Rust 製コードには検証ツール Aeneas があり、Microsoft の暗号ライブラリ検証チームが使っているという。規模面では、人間が10年かけた Mathlib が約250万行なのに対し、公開された Lean 証明は約5000万行に達し、Anthropic の AI が書いたフェルマーの最終定理の証明は1300万行だと述べている。

また Claude Code の開発者 Boris 氏が、Claude に Lean で Claude Code のバグを検証させ、実際のバグを見つけて修正を取り込んだ例も紹介された。Lean を知らなくてもすぐ価値が得られることが、学習への投資を促すと同氏は見ている。

#### 残る課題：モデルの忠実性と仕様

AI が作ったモデルが元のコードに忠実かどうかは、人間が責任を負う部分だ。差分テストで Lean モデルと実プログラムの出力を比べる手法があるという。数学でも、OpenAI の Navier-Stokes に関する結果をめぐり、自然言語の証明と Lean の証明の間に仮定の食い違い（四階か五階の導関数か）があったという議論に触れ、de Moura 氏は Lean と自然言語を対応づける Blueprint ツールで防げた可能性が高いと述べた。

そのため今後は、ソフトウェアの「仕様」や「満たすべき性質」に人間の重心が移ると予想している。従来の設計書は実装との同期が人手頼みだったが、形式化すれば一致をツールで確認でき、顧客の要望と仕様のずれは磨き続ける対象になる。Lorica 氏は、要件文書が中核資産としてソース管理される未来を指摘した。AI が最適化を試みても、証明がガードレールとなり同じ結果を保証できる点も利点として挙げられた。

#### 信頼とエージェント

CTO がベンダーの「形式検証済み」を鵜呑みにしないための質問として、どの性質を、どの仕様に対して、どのカーネルで検証したのか、信頼すべきコードベースは小さいか、が挙げられた。自明に真な性質を証明しただけでは主張が空虚になるという。

エージェントについては、信頼できるサンドボックス、挙動ポリシーとそれを実行するコードの検証が重要だとした。エージェントがカーネルの欠陥を突く懸念には、独立実装の複数カーネル（Rust、C#、Haskell、さらには TeX 実装まで）があり、arena.lean-lang.org で競わされていると答えた。AWS の AgentCore などでも Lean が使われているという。

#### 数学とその先

数学は Mathlib の存在により最も進んでいる。Terence Tao 氏が大規模プロジェクトを分割し、多数の人が穴を埋める形で進めた例があり、将来そこに AI が入るとは思っていたが、これほど早いとは誰も予想しなかったと述べた。数学者の反応は興奮と不安が混在するという。理論物理には PhysLib があり、論文のバグ発見の初勝利もあるが、物理モデルは現実の近似で不正確さが残る。金融、化学、生物学への関心もある一方、金融は秘匿性が壁になる。会計や法は主観が入るが、民事訴訟手続きのように形式化できる部分もあるとした。

計算資源の多寡が研究成果を左右するのではという問いには、James Webb 望遠鏡のように提案を出して巨大モデルへのアクセスを得る形になりうると答えた。

#### まとめ

AI がコードを書く時代に、機械検証できる証明が信頼の土台になるというのが de Moura 氏の主張だ。日本の開発者にとっての注目点は、実装そのものより仕様・性質の記述力が価値を持ちうることと、「検証済み」の中身を問う姿勢である。ただしこれは一人の推進者の見解であり、モデルの忠実性や仕様の妥当性といった課題は残る。まずは既存コードのバグ探しに Lean を試すことが、現実的な入口になりそうだ。

> この要約・解説記事は、元の音声の文字起こしをもとに AI（Claude）が日本語で作成したものです。出典: The Data Exchange with Ben Lorica「When AI Writes the Code, Who Proves It Works?」