数学研究のためのローカル Lean 4 証明自動化環境セットアップガイド
大規模な数学問題解決システムを研究室のデスクトップに導入する際、巨大なアーキテクチャの概要は何の役にも立ちません。ローカル環境で Lean 4 パイプラインを直接セットアップし、長期実行型のマルチエージェントを連携させて数学の探索作業を完全に自動化するための実務手順をまとめます。
ローカル Lean 証明検証環境の構築
開発環境で Lean 4を手動でインストールし、VS Code 言語サーバープロトコルに依存すると、大規模なAI検証時に深刻なボトルネックを引き起こします。Mathlib4 の事前コンパイル済みバイナリがキャッシュされない場合、ローカル CPU が数十万個の定理を直接再コンパイルするため、環境構築だけで 180分以上を要します。秒間数十回以上のコード検証リクエストを処理するには、FastAPI ベースの Kimina Lean Server パイプラインに切り替える必要があります。
長期実行型の数学問題検証作業のセットアップ時間を 180分から 20分以内に短縮する具体的な構築手順は以下の通りです。
- プロジェクトルートディレクトリの lean-toolchain ファイルにツールチェインを固定します。ファイル内部に leanprover/lean4:v4.15.0 テキストを入力します。
- lakefile.lean 設定ファイルを開き、Mathlib4 パッケージおよび stdio ベースの JSON 入出力を行う repl リポジトリを指定します。
`lean
import Lake
open Lake DSL
package «proof_automation» {
}
require mathlib from git
"https://github.com/leanprover-community/mathlib4.git" @ "v4.15.0"
require repl from git
"https://github.com/leanprover-community/repl.git" @ "main"
@[default_target]
lean_lib «ProofAutomation» {
}
`
- ターミナルを開き、次のコマンドを順次実行して事前コンパイル済みバイナリアーティファクトをダウンロードし、ビルドします。
`bash
lake update
lake exe cache get
lake build
`
この作業を完了すると、事前コンパイルキャッシュを即座に取得して 20分以内に完全なローカル REPL 実行環境が整い、秒間最大 50個の証明段落を同時に検証できます。
ルートおよびサブエージェントの役割分担設計
単一の大規模言語モデルのプロンプト呼び出しで複雑な定理証明を試みると、コンテキストが長くなるにつれてサブ目標を見失ったり、無限ループに陥ったりします。問題分割を担当するルートエージェントと、独立した下位タクティクスを実行するサブエージェントに役割を分離した階層型有向非巡回グラフアーキテクチャを適用する必要があります。
エージェント通信規格として JSON 形式を採用し、スコープを分離してプロンプトを渡すことで、API トークン消費量を 40パーセント以上削減できます。サブエージェント呼び出し時に使用する JSON スキーマは次のとおりです。
`json
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"title": "SubAgentProofTask",
"type": "object",
"properties": {
"task_id": { "type": "string" },
"target_hypothesis": { "type": "string" },
"current_goal_state": { "type": "string" },
"previous_failure_logs": {
"type": "array",
"items": {
"type": "object",
"properties": {
"attempted_tactic": { "type": "string" },
"error_message": { "type": "string" }
}
}
},
"sub_goal_target": { "type": "string" }
},
"required": ["task_id", "target_hypothesis", "current_goal_state", "sub_goal_target"]
}
`
エージェントのハルシネーションによる無限ループを遮断し、安定した階層構造を稼働させる段階的な制御手順は以下の通りです。
- サブエージェントに入力プロンプトをバインドする際、全体の会話履歴を削除し、仮説、Goal State、過去の失敗ログの 3つの核心要素のみを送信するようにプロンプトを構成します。
- Lean REPL から返される proofState 文字列を SHA-256 アルゴリズムでハッシュ化し、メモリに保存します。同一の状態ハッシュが 3回以上重複して検出された場合、該当する探索ブランチをプルーニングします。
- 単一の Tactic 演算に 5秒、サブエージェント全体の探索に 120秒のタイムアウトを設定し、超過時には SIGKILL シグナルを送信して REPL プロセスを即座に再整備します。
API トークン費用の制御に向けたコンテキスト管理戦略
数時間にわたって継続する証明探索作業において、リクエストごとに全体の会話履歴をバックエンド API に送信すると、トークン使用量が急増します。LeanExplore および Vector DB ベースのキャッシュレイヤーを構築し、すでに検証済みの中間 Tactic 結果を補題の形式でメモリグラフに要約反映させることで、入力トークンのオーバーヘッドを制御する必要があります。
バックエンドサーバーには REPL セッションの環境識別子を登録し、プロンプト上部で繰り返される import Mathlib の記述を削除します。これだけでも入力トークンを 50パーセントから 70パーセントまで即座に削減できます。予算上限の超過による API 費用の急騰を防止するための制御パイプラインの実装手順は次のとおりです。
- ローカル環境ディレクトリに .leanflow/cache/ および .leanflow/workflow-state/ のパスを生成します。
- Python ベースの CostMonitor モジュールを作成し、API 呼び出し時に消費されるトークンと費用をリアルタイムで加算追跡します。
- 閾値金額に到達するとチェックポイントスナップショットファイルを保存し、プロセスを安全に停止するスクリプトを稼働させます。
`python
import sys
import json
import logging
class CostMonitor:
def init(self, max_budget_usd: float, token_cost_per_1k: float):
self.max_budget = max_budget_usd
self.cost_per_1k = token_cost_per_1k
self.total_tokens_used = 0
self.current_cost = 0.0
def track_usage(self, prompt_tokens: int, completion_tokens: int):
tokens_in_call = prompt_tokens + completion_tokens
self.total_tokens_used += tokens_in_call
self.current_cost += (tokens_in_call / 1000.0) * self.cost_per_1k
logging.info(f"[TELEMETRY] Used Tokens: {tokens_in_call} | Total Cost: ${self.current_cost:.4f}")
if self.current_cost >= self.max_budget:
self.trigger_safe_pause()
def trigger_safe_pause(self):
logging.warning("[WARNING] Target budget threshold reached. Pausing workflow...")
with open(".leanflow/workflow-state/checkpoint.json", "w") as f:
json.dump({"status": "PAUSED_BUDGET_EXCEEDED", "tokens": self.total_tokens_used}, f)
sys.exit(0)
`
証明コードのエラー自動修正ループの実装
AI エージェントがコードを生成した後に手動でエラーをレビューする方式は、研究全体における致命的なボトルネックとなります。Lean REPL コンパイラが出力する構文エラー、型不一致、未解決目標などの JSON パースデータをエージェントのフィードバック入力に直接接続する必要があります。
手動レビューを代替し、研究速度を 2倍以上に向上させる自動修正制御ループの動作方式は以下の通りです。
- Lean REPL から返された JSON レスポンスを受信し、エラー位置とタイプエラーメッセージ、残りの目標を以下の Python パーサを通じて構造化データとして抽出します。
`python
def parse_lean_repl_output(repl_response_json: str):
data = json.loads(repl_response_json)
parsed_diagnostics = {
"has_error": False,
"errors": [],
"open_sorries": []
}
if "messages" in data:
for msg in data["messages"]:
if msg.get("severity") == "error":
parsed_diagnostics["has_error"] = True
parsed_diagnostics["errors The text has been translated"] = [] # Note: keeping original logic
parsed_diagnostics["errors"].append({
"line": msg["pos"]["line"],
"column": msg["pos"]["column"],
"data": msg["data"]
})
if "sorries" in data:
for sorry in data["sorries"]:
parsed_diagnostics["open_sorries"].append({
"goal": sorry["goal"],
"proof_state": sorry["proofState"],
"line": sorry["pos"]["line"]
})
return parsed_diagnostics
`
- 初期 1〜4回の試行の間は、パースされたエラーメッセージデータをサブエージェントプロンプトにバインドし、該当位置の Tactic パラメータを局所的に精密修正します。
- 同一地点で 5回以上連続して検証が失敗した場合、該当の証明戦略をバックトラックして破棄し、補題をより小さな単位に切り分けるスケッチ再分割モードに自動切り替えします。
完全に検証された Clean コードは doc-gen4 および paperproof 変換ツールを通過し、研究論文に即座に挿入可能な論理グラフの可視化および LaTeX コンテキストとして自動生成されます。
`bash
lake build LeanAutomation:docs
lean-graph extract --input Main.lean --output proof_dependency.json
`