AlphaProofのコードがSignalの暗号が正しいことを証明——コンパイル済みバイナリのレベルで

650万行のLeanコードが、人間が一切書くのを手伝っていないエージェントチームによって4週間で生成された。これが、G​oogle DeepMindが2026年11月10日にAlphaProof Codeについて発表した見出しの数字だ。AlphaProof Codeは形式検証のためのエージェント型フレームワークであり、同研究所はこれを使ってSignalプロトコルの暗号学的中核を機械検証した——しかも異例なことに、その上位にある設計書ではなく、コンパイル済みのAArch64バイナリのレベルで検証したのだ。 実際に作業を行ったモデルについては、また別の話だ。 プロバイダーの定価でマークアップ0%のAPIキー1つ 証明エージェントのエンジンは、当社が提供しているものではない。

このフレームワークは、呼び出せるモデルではない。それはハーネスだ。人間の専門家が何が真であるべきかを決め、複数のモデルの組み合わせがそれらの目標をLean仕様に変換し、その後、証明を書くエージェントのチームが—ブログではエンジンとしてGemini Carbonを挙げている—Leanのカーネルがそれらを受け入れるまで証明を埋めていく。発表と同時に公開されたのは、github.com/google-deepmind/code-verification にある成果物一式と、ブログ投稿よりも結果の限界についてはるかに率直な技術論文だ。以下の内容の大半はその論文に基づく。興味深い数値は論文にあるからだ。

実際に何が証明され、そして何に対して証明されたのか

対象は libsignal v0.105.4 と spqr v1.6.0 で、標準の rustc 1.98.1 によってビルドされ、musl に対して静的リンクされ、単一の AArch64 Linux 実行ファイルとして出力される。この詳細はどのベンチマークよりも重要だ。証明の対象は携帯電話上で実行されるバイト列であり、コンパイラが忠実に変換すると信頼されている Rust 関数ではない。チームは約 560 KB の libsignal ソース、約 140,000 個の AArch64 命令を検証し、それを、命令セットの Lean モデル（7,578 行で 467 命令と 31 システムコール）を書き、そのモデルの下でロードされ実行される実際の ELF イメージがセキュリティ特性を維持することを証明することで行った。

その特性は、プロトコルエンジニアなら当然求めるものだ。10個の記号定理が、前方秘匿性、侵害後安全性、イニシエータとレスポンダの秘匿性、認証、およびPQXDHの定理1の5つの系をカバーする。主結果の名前はsignal_session_secure_placedである。また、具体的なバウンドを伴う計算論的トラックもあり、2つのトラックは異なる敵対者モデルを用いる。記号論的側面（Dolev–Yao、DyLeanフレームワーク経由）は、ハンドシェイク後にDiffie–Hellmanを破る量子攻撃者さえもカバーする一方、計算論的側面は古典的敵対者のみをカバーする。

600万行はどこへ行くのか

「600万行超」というのがブログの表現で、正確だが大まかだ。論文の内訳こそ有用であり、誇示ではなくコスト表として読む価値がある：

• バイナリに関する証明 — 530万行。作業の大部分を占め、機械語のセマンティクスと、シンボリックモデルから実行可能コードに至るまでのリファインメントをカバーしています。

• 計算による証明 — 約86万行。

• 記号的証明 — 約350,000行。

• バグ反証証明 — 以下で説明する、意図的に再導入された2つの脆弱性に関する約140,000行。

• アロケータの証明 — 約70,000行。

コメントと空行を数に入れるなら約700万行で、論文はそう数え、ブログは数えていない。いずれにせよ重要なのは、証明と証明対象の間の比率だ。560 KB のバイナリの性質を確立するために Lean の650万行。この比率こそ、この手法が日常的なものになるまでどれだけ遠いかを正直に測る指標であり、形式検証が安くなったのかと誰かに尋ねられたときに引用すべき数字だ。

信頼できる基盤は証明よりも小さく、そこが要点です。

証明の信頼性は、それが何を前提としているかによって決まる。論文はこの点を具体的に述べており、その具体性こそがプレスリリースとの違いを生んでいる。信頼された仕様は約18,000行（ドキュメント込みで28,000行）、AArch64のセマンティクスは約8,000行、機械語のLeanエンコードは約95,000行である。37個のルーチンは検証されるのではなくコントラクトに置き換えられている。SHA-256とSHA-512の圧縮、AES-256-CBC、X25519、エドワーズ曲線演算、Kyber1024とML-KEM-768、およびlibcrux HMACである。同様に18個のパニックエントリポイントも、証明されるのではなく前提とされている。

つまり、主張は「すべてが証明されている」ということではない。主張は、暗号プロトコルのロジック、セッション状態機械、およびそのロジックから実際に実行される命令へのリファインメントが証明されており、一方でその下にあるプリミティブは、あらゆる検証プロジェクトが自らのプリミティブを信頼するのと同じように信頼されている、というものだ。注目すべきことに、Rustコンパイラは信頼基盤には含まれていない — チームはマシンコードレベルで推論することで、それを信頼する必要を回避した。これは、検証済みコンパイラを完全に回避できるのと同じ手法である。規模の参考として、論文はseL4を約20人年、CompCertを約6人年と挙げている。

2つのバグ、わざと元に戻されました

常に「正しい」としか答えない検証システムはテスト不可能です。そこでチームは、以前にSignalのコードで見つかって修正された2つの脆弱性——弱状態バグと小部分群バグ——を隔離されたコピーに再導入し、パイプラインを再実行しました。どちらの場合もAlphaProof Codeは、バグのあるバージョンがセキュリティ定理を満たさないことを機械検証済みの証明として生成しました。つまり、記号文は¬Sec(Asm_bug)に帰着します。

論文は、マーケティング用のページなら削っていたであろう注意書きを加えている。反駁の対象となるのは計算論的定理であり、それらのバグについては「はるかに難しい」として未解決のままにされた。言い換えれば、その否定的テストは記号的トラックではきれいに機能するが、計算論的トラックではまだ機能しない。読者がこの枠組みをバグ検出器として扱う前に知っておくべきなのは、まさにこの種の非対称性である。

エージェントの実行方法

4週間にわたり5人の研究者が、それぞれエージェントを休みなく稼働させた。証明の執筆自体は40～80体のエージェントからなるチームが行い、チームごとに1台のマシン上で24～72時間稼働し、チームのオーケストレーターの上には監督エージェントが置かれていた。ゲートキーパーエージェントは各提出物をコンパレーターで、仕様のホールドアウトコピーとLeanのカーネルに対して検査する——これは、エージェントが依頼された内容を微妙に弱めた版を証明してしまうことへの防御である。

人間の作業は仕様策定に前倒しで集中していた。証明作業が始まる前に、すべての仕様は専門家によってレビューされ、エージェント自身の監査パスはコードベースの約1%を人間の注意が必要な箇所としてフラグ付けした。人間が証明コードを書くことはなかった。論文はエンジニアリング面についても率直で、クリーンビルドには数時間かかることがあり、初期には軽微なソース編集やバイナリの再コンパイルが大規模な証明の修正を余儀なくさせたこと、またAIが生成した証明と証明技法そのものの両方に「最適化の余地が大きい」ことが述べられている。

証明がカバーしていないこと

限界は、論文の中で最も重要な節と言えるほど長く、率直に述べられている。SPQRの回復特性についてはポスト量子保証が確立されていない——ラチェット定理は、攻撃者がSPQR鍵を選ぶと仮定している。ペイロードのプライバシーは証明されていない。昇格されないハンドシェイクの最初のメッセージについて、レスポンダ認証は証明されていない。モデルでは、昇格ごとに1セッション、固定メッセージ長、マルチデバイス状態なし、初回使用時信頼（TOFU）の識別鍵が許容されている。

また、空虚になってしまうバウンドもある。8バイトMACの偽造項は試行あたり少なくとも2⁻⁶⁴であり、メッセージ数とエポック数に対して二次関数的に増大する。つまり、約25,000メッセージの単一セッション、または2¹⁰メッセージの2²⁰セッションでは、そのバウンドは何も言えなくなる。そして証明の対象は、新規プロセスとして実行されるチームのlibsignal-cliビルドであり、スマートフォン上のSignalアプリではない。いくつかの環境前提は証明されるのではなく、非形式的に論じられている。

APIも、価格も、呼び出せるモデルもありません。

モデルリーダーボードからやって来る人なら誰でも失望するのはこの部分だ。{{1}}AlphaProof Code{{/1}}は研究フレームワークであり、公開された成果物群である。エンドポイントも、トークンごとの料金表も、ウェイトリストも、重みもない。リポジトリに含まれているのは{{2}}Lean{{/2}}開発、{{3}}AArch64{{/3}}セマンティクス、{{4}}libsignal{{/4}}バインディング、そして仕様であり、チェックポイントではない。ブログでは成果物がオープンソース化されたと述べられているが、ランディングページにはライセンスについて何も記載がない。その上に構築することを計画する前に確認する価値がある。

実際に作業を担ったモデルはまた別の話だ。論文は証明エージェントにG​emini 4 Carbonを挙げ、仕様書の起草とレビューにはClaude Opus 5.5が他のモデルとともに使われたと述べている。Claude Opus 5.5は本日OrcaRouterのカタログに掲載されており、入力100万トークンあたり4ドル、出力100万トークンあたり20ドルで、プロバイダーの定価が0%のマークアップでそのまま適用されている——なので、あなたが得たい実用的な結論が「論文で使われたモデルで仕様書起草ループを回す」ことなら、その部分は通常のAPI呼び出しであり、ベンダーの価格変更は同日に当社側へ反映される。証明エージェントのエンジンは当社が提供するものではなく、ここでの内容は当社がAlphaProof Code自体をホストすることを何ら意味しない。

なぜこれがSignalの結果よりも大きな問題なのか

Signalの検証はそれ自体の観点で印象的だ——広く展開されているプロトコルの実装を、DeepMindによればAIの有無を問わずあらゆる手法で初めて形式的に検証したものであり、AIが展開済みの暗号プロトコルをこの深さで検証した初めての事例でもある。しかし、転用可能な主張はそのワークフローにある。5人のチームが4週間で、仕様レビューの工程とエージェントのゲートキーパーを置いて、以前なら複数年がかりのプロジェクトだったであろう証明コーパスを生み出した。その比率が多少なりとも保たれるなら、検証を手掛けられるシステムの集合は変わる。医療機器のファームウェア、電力網のソフトウェア、現在はコードレビューと祈りに頼っている類のコードだ。

それが成り立つかどうかは未検証だ。Signalの暗号は異例なほど仕様がしっかりしており、チームにはSignal自身のエンジニアが方法論をレビューし、プリミティブは検証されるのではなく外部委託されていた。次のシステムはそこまで好都合ではないだろう。論文自身の枠組み——形式検証をCodeMenderのような自動防御エージェントと組み合わせる——は、この提案の正直な姿だ。検証は何が真かを教え、真でないものを修正するのは別の何かでなければならない。

何を観るべきか

これを画期的な論文から産業技術へと押し上げるには、3つの要素がある。Google の外部の誰かによって検証された、第2の独立したコードベース——できれば、既存の分析から流用するのではなく、仕様をゼロから書かざるを得なかったもの。コスト数値——エージェント時間、アクセラレータ時間、ドル——。なぜなら、4週間と40〜80エージェントのチームというのは、どのエンジニアリングマネージャーも予算策定の基準にできる単位ではないからだ。そして、計算トラックにおけるバグ反証。論文はこれを未解決のままにしており、これは、性質を証明するシステムと、特定のバイナリが壊れていることを計算によって教えてくれるシステムとの違いである。

それまでは、告知ではなくアーティファクトリポジトリを読んでください。証明はそこにあり、Leanがそれらを検証し、論文はそれらが何を前提としているかを正確に示しています。