Lean Refactor: Multi-Objective Controllable Proof Optimization via Agentic Strategy Search
Lean Refactor は、モデルの再学習を必要とせずにキュレーションされたリファクタリング戦略を動的に選択することにより、トークン圧縮、コンパイル速度、バージョン互換性といった複数の目的を最適化するための、検索拡張型エージェントフレームワークである。
原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
以下は、論文「Lean Refactor」を平易な言葉と創造的な比喩を用いて解説したものです。
問題：「過剰設計」された証明
想像してみてください。ある天才だが熱しやすく冷めやすい建築家（AI）が、ちょうど家（数学的証明）を建てたところだとします。その家は構造的には安全です——倒壊することはありませんし、すべての安全検査にも合格します。しかし、建築家は 50 個で十分だった壁を、500 個ものレンガを使って建ててしまいました。彼らはナッツを割るために金槌を使っているのです。
Lean（コンピュータが検証できる数学的証明を書くために使われる言語）の世界では、AI モデルはしばしば正解だが、信じられないほど長く、乱雑で、コンパイルに時間がかかる証明を生成します。
- 長すぎる： 証明が人間にとって読みづらい。
- 遅すぎる： 証明が不要なステップで肥大化しているため、コンピュータがその有効性を検証するのに長い時間がかかる。
- 壊れやすい： Lean 言語は頻繁に変更されます（ソフトウェアのアップデートのように）。「バージョン 1.0」向けに書かれた証明は、数学が正しいにもかかわらず、コンピュータが「バージョン 2.0」にアップデートされると完全に破綻してしまう可能性があります。
既存のツールは、この問題を解決しようとして、AI の再学習（高価で時間がかかる）を試みたり、単に「短くして」と頼んだり（そうすると証明の実行が遅くなることが多い）していました。
解決策：「賢い司書」システム
著者たちはLean Refactorを作成しました。AI を再学習させる代わりに、AI のための「プラグ＆プレイ」システム、つまり超優秀な司書のようなシステムを構築しました。
これがどのように機能するか、比喩を用いて説明します。
1. 戦略バンク（図書館）
「リファクタリングカード」で満たされた巨大な図書館を想像してください。各カードは、証明を短くするための特定のトリックを記述しています。
- トリック： 「すべての数字を一つずつ列挙する代わりに、この魔法の式を使いなさい」。
- メタデータ： 重要なのは、すべてのカードにラベルが付けられていることです。それは以下を示します。
- どれだけの時間を節約できるか？（例：「コンパイル時間を 30% 節約」）。
- どの言語バージョンで動作するか？（例：「Lean v4.16 および v4.22 で動作」）。
- 証明をどれくらい短くできるか？
この論文では、彼らがこれまでにない最大のカード図書館を構築したと主張しています。そこには、数十万の証明例から抽出された9,000 以上のユニークな戦略が含まれています。
2. エージェント（建築家＋司書）
AI が証明を修正する必要があるとき、それは推測しません。以下のループに従います。
- プランナー： AI は乱雑な証明を見て、「このセクションは『魔法の式』トリックが必要そうだ」と言います。
- 司書（検索）： システムは図書館に行き、そのセクションに一致する特定のカードを取り出します。
- 最も短い証明が欲しい場合： 最大のサイズ削減を約束するカードを取り出します。
- 最速のコンパイルが欲しい場合： 最大の速度向上を約束するカードを取り出します。
- 古いバージョンの Lean を使用している場合： そのバージョンでは機能しないカードを除外します。
- リファクタラー： AI はカードからのトリックを適用して証明を書き換えます。
- デバッガー： コンピュータが新しい証明をチェックします。もし破綻した場合、AI は全体の改善を元に戻すことなく、ローカルでエラーを修正しようと試みます。
これが特別である理由（論文の主張）
1. 競合する目標のバランスを取る（「マルチオブジェクティブ」の魔法）
通常、あなたは選択を迫られます。「証明を短くしたいのか、それともコンパイルを速くしたいのか？」
- 従来の方法： 一方を選び、他方が犠牲になります。
- Lean Refactor： システムに「短くしたいが、同時に 速くもしたい」と指示できます。システムは図書館のカードを見て、両方を提供してくれるものを見つけ、最適なバランスを選びます。
- 結果： 競技数学の問題において、証明を70% 以上縮小し、コンパイル時間を60% 以上削減しました。
2. ソフトウェアのアップデートに耐える（「バージョン堅牢性」）
図書館のカードには、動作する特定のソフトウェアバージョンがラベル付けされているため、システムは即座に「時代遅れ」のトリックを除外できます。
- 結果： 「Lean v4.16」向けの証明を要求すると、システムは v4.16 で動作するカードのみを使用します。これにより、AI がそのバージョンに存在しないツールを思い込み（ハルシネーション）、作り出すことを防ぎます。
3. どの AI でも機能する（「モデル非依存」機能）
これのために新しい AI を学習させる必要はありません。このシステムは、Google（Gemini）、Anthropic（Claude）、OpenAI（GPT）など、どの「凍結済み（事前学習済み）」AI モデルとも連携します。「知性」は AI の脳から来るのではなく、戦略の図書館から来ます。
- 結果： 彼らは異なる AI モデルでテストしたところ、すべてのモデルのパフォーマンスを向上させ、専門的なコーディングエージェントである「Claude Code」さえも凌駕しました。
結論
Lean Refactorは、建設チームに設計図と、事前テスト済みでラベル付けされたショートカットの工具箱を与えるようなものです。家をどう建てるか推測する代わりに、彼らは持っているツールと使用している建築基準法のバージョンに基づいて、特定の壁を建てる最良の方法を調べます。
この論文は、このアプローチが以下のことを実現すると主張しています。
- 数学競技において証明を70% 以上縮小する。
- コンパイルを60% 高速化する。
- ソフトウェア言語がアップデートされても動作し続けるようにする。
- これらすべてを、AI モデルの再学習なしで行う。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。