ああ、それはね、証明の変更に関するルールのことだよ。開発者が「ここは変えていいけど、ここはダメ」って決めるんだ。

まず一つ目は、Isabelleのビルドが通るかどうか。二つ目は、契約チェッカーで、変更が許可された範囲内かどうかを確認する。この二つが独立してるから、ビルドが通っても契約違反なら拒否されるんだ。

12タスク・180回の実行で評価して、証明本体だけを編集可能にした条件では、契約違反ゼロで29/36の修復に成功したんだ。

うーん、契約をどう書くかが難しいところかな。複雑な証明だと、契約を細かく定義するのが大変かもしれない。あと、LLM自体の性能に依存する部分もあるから、完璧ではないよ。

まあ、完全に任せるのはまだ早いけど、CAPRIみたいな仕組みがあれば、人間が監視しやすくなるのは確かだよ。

因果推論の定理を自動で見つけて、証明までしてくれるフレームワークだよ。しかもLeanっていう証明検証器で正しさを保証するんだ。

従来の因果推論は、研究者が手動で定理を考えて証明してたけど、見落としや間違いが起きやすい。CausalForgeはそれを自動化して、さらにLeanで検証することで信頼性を高めてる。

そこがポイントで、LLMを使って定理の自然言語での説明と形式的な証明が一致してるか監査するステップを入れてるんだ。これで「形式的には正しいけど意味が違う」って問題を防いでる。

普通、LLMにレビューさせると間違った判断をすることがあるけど、CausalForgeでは形式的な証明が既にあるから、LLMは「証明と説明の対応」だけを見ればいい。そのタスクは比較的簡単で、誤りが少ないんだ。

いや、まだ限界もある。例えば、発見できる定理の複雑さに上限があるし、Leanのライブラリにない数学的概念を使うと証明が難しくなる。あと、監査用のLLMも完璧じゃないから、稀に誤った監査結果が出ることもある。

そのためには、もう少しユーザーフレンドリーなインターフェースが必要だね。今はLeanの知識がいるから。

それだと君が勉強する意味がなくなるけどな。

いや、全然違うよ。これはクラウドのインフラを構築するためのコード、つまりIaC（Infrastructure as Code）をAIに自動で作らせる研究だね。

確かに生成はできるけど、実は間違いがすごく多いんだ。クラウドの設定は複雑で、ちょっとした記述ミスで動かなかったり、セキュリティに穴が開いたりする。人間が手で書いても100分以上かかるような作業なんだよ。

物理的に爆発はしないけど、システムが動かなくて大損害が出ることはあるね。だからこの論文では、AIが作ったコードを「検証ツール」で厳しくチェックして、その結果をAIにフィードバックして鍛え直す仕組みを作ったんだ。

まず、3つの段階でチェックするんだ。1つ目は「構文が正しいか」、2つ目は「実際にデプロイ（配置）できるか」、3つ目は「セキュリティなどのポリシーを守っているか」。これを自動で行う『検証機（ベリファイア）』を使うんだよ。

そうそう。OPA（Open Policy Agent）っていうツールを使って、安全な設定になっているかを自動判定するんだ。この検証結果を報酬として与える「強化学習」っていう手法で、AIを賢くしていくんだよ。

そこがこの論文のすごいところで、エラーを含んだコードをAIに自己修正させるループを回して、高品質なデータを15万件以上も自動で作っちゃったんだ。特に、既存のコードを書き換える『修正（ミューテーション）』のデータセットは世界初だね。

めちゃくちゃすごいよ。実際、このTerraFormerは、GPT-4.1やClaude 3.7みたいな超巨大な最新AIよりも、インフラコードの正確さで勝っちゃったんだから。

今はTerraformっていう特定のツールに集中しているから、他のツールへの対応が必要だね。あと、検証ツール自体が完璧じゃない場合もあるから、そこをどうカバーするかが今後の研究課題かな。

それはインフラじゃなくて魔法のランプの仕事だよ。いい加減にして。

いや、全然違うよ。LoCは『Lines of Code』、つまりプログラムの行数のことだ。これは大規模なプログラムにバグがないか、AIを使ってどうやって数学的に証明するか、っていう硬い論文だよ。

それが意外と難しいんだ。プログラムが大きくなると、AIも一度に全部を理解できなくなるし、関数同士の複雑なやり取りを正確に把握して『仕様』を作るのは、今のLLMでも限界があるんだよ。

そうだね。形式検証では『この入力のときは、こう動かなきゃダメ』っていう厳密なルール（仕様）が必要なんだけど、これを人間が書くのはめちゃくちゃ大変なんだ。そこでこの論文が提案しているのが『Preguss』っていうフレームワークだよ。

名前の由来はともかく、中身は『分割統治』っていう賢いやり方なんだ。まず、静的解析っていうツールを使って、プログラムの中で『ゼロで割り算しそう』とか『メモリが溢れそう』っていう危ない場所（実行時エラー、RTE）を先に見つけるんだ。

その通り。それが第一段階の『Divide（分割）』。次に、その危ない場所ごとに、LLMを使って『ここがエラーにならないための条件』をピンポイントで作らせるんだ。これが第二段階の『Conquer（攻略）』だね。

そう。しかも、ただ仕様を作るだけじゃなくて、静的解析の結果をヒントにLLMに指示を出すから、精度がすごく高いんだ。実験では、人間が手作業で検証する手間を8割以上も減らせたらしいよ。

実際に使われている宇宙機の制御システムを調べたら、プロでも気づかなかったバグを6つも見つけたんだって。宇宙でエラーが起きたら大変だから、この成果はかなり大きいよ。

いや、まだ課題はあるよ。今は主に実行時エラーを防ぐのがメインだし、もっと複雑な『意図通りの機能か』っていう検証には、さらに高度な仕様生成が必要になる。それに、LLMが間違った仕様を作っちゃう可能性もゼロじゃないからね。

そこまで行くとSFだけど、ソフトウェアの信頼性を高めるための大きな一歩なのは間違いないね。これからは、もっと巨大なシステムにも対応できるように研究が進むはずだよ。

それはただの『賞味期限切れチェック』だろ。さっさと片付けなさい。