AlphaProof Codeとは？DeepMindがSignalを機械語レベルで形式検証した仕組み・成果・限界

AlphaProof Codeは、Google DeepMindが開発した、ソフトウェアの「仕様づくり」と「形式検証（数学的な証明）」をAIエージェントのチームで進める研究用のフレームワークです。2026年11月10日、DeepMindはこれを使ってSignalの暗号プロトコル実装「libsignal」の主要なセキュリティ性質を、コンパイル後の機械語のレベルで証明したと発表しました。

この記事では、形式検証とは何か、AlphaProof Codeの仕組み、証明できたこととできていないこと、一般の人や企業が使えるのかを、DeepMindの公式ブログと技術論文をもとに整理します。セキュリティ担当者、AIコーディングの品質保証に関心がある開発者、Signalの利用者を想定しています。

AlphaProof Codeは製品やAPIではありません。料金プランもなく、公開されたのは検証の成果物（Leanの仕様と証明）だけです
検証の対象は、Signalアプリ全体ではなく1対1のメッセージ暗号の中核部分です。グループチャットや鍵生成などは対象外です
ポイントは「AIが証明を書き、Leanが機械的にチェックする」分担です。5人のチームが4週間で、約650万行の証明を生成しました
証明が安く作れるようになると、難しいのは「何を証明するか（仕様）」になる、というのが論文の教訓です

AlphaProof Codeとは

Google DeepMindがAlphaProof Codeを発表した公式ブログの画像

出典: Google DeepMind公式ブログ

AlphaProof Codeは、人間の専門家が「何を証明するか」を決め、AIエージェントが証明を書き上げる「形式検証のためのマルチエージェントの仕組み」です。DeepMindの公式ブログでは「multi-LLM agentic framework」と説明されています。

複数のAIが役割を分けて動く仕組み全般は、マルチエージェントとはやAIエージェントとはで解説しています。

公式情報の要点

項目	内容
開発元	Google DeepMind
発表日	2026年11月10日（ブログ・論文・成果物を同時公開）
位置づけ	研究用フレームワーク（一般提供・APIなし）
最初の検証対象	Signalの暗号プロトコルのリファレンス実装 libsignal（v0.105.4）とSPQR（v1.6.0）
検証のレベル	Rustのソースコードではなく、コンパイル後のAArch64機械語
証明を書いたモデル	Gemini 4 Carbon（論文による。ブログの表記は「Gemini Carbon」）
仕様づくりに使ったモデル	Gemini 4 CarbonとClaude Opus 5.5（論文による）
証明を確認する道具	定理証明支援系 Lean
公開物	仕様・証明・ビルドスクリプト一式（GitHub、Apache License 2.0）

一次資料は次の4つです。

公式ブログ: Introducing AlphaProof Code
技術論文（57ページ）: AlphaProof Code: Verifying Signal's Security at the Machine-Code Level
成果物ページ: code-verification
GitHubリポジトリ: google-deepmind/code-verification

名前の「AlphaProof」との関係

AlphaProofは、2024年に国際数学オリンピック（IMO）で銀メダル相当の成績を出したDeepMindの数学証明AIの名前です。AlphaProof Codeはこの名前を受け継いだシリーズですが、旧AlphaProofの強化学習モデルを使っているという記述は、ブログにも論文にも見当たりません。今回の証明を書いたのはGemini 4 Carbonのエージェントチームです。

形式検証とは：テストやバグ探しとの違い

形式検証とは、ソフトウェアが満たすべき性質を数式の形で「仕様」として書き、コードがその仕様を満たすことを数学的に証明する方法です。証明できれば、その性質に反するバグや攻撃は、すべて起こりえないと言えます。

テストは「試した入力で問題が出なかった」ことしか示せません。形式検証は、仕様に書いた範囲であれば、すべての入力・すべての実行について保証します。

方法	わかること	弱いところ
テスト	用意した入力で正しく動くか	試していない入力のバグは残る
脆弱性診断・バグ探し（ファジング、AIによる発見など）	見つかったバグ	「見つからなかった＝無い」とは言えない
形式検証	仕様に書いた性質が、どんな場合でも成り立つこと	仕様に書いていない性質には何も言えない。仕様と証明を書く手間が非常に大きい

AIでバグを見つける取り組みとしては、GoogleがChromeのバグをAIで発見した事例があります。AlphaProof Codeはその逆の立場で、「バグが無いこと」を証明する側の技術です。

なぜ今まで難しかったのか

形式検証は手間がかかりすぎて、ごく一部の重要なソフトウェアにしか使われてきませんでした。論文によると、検証済みのOSカーネル「seL4」は検証に20人年、検証済みのCコンパイラ「CompCert」は6人年かかっています。しかもこの2つは、最初から検証する前提で書かれたコードです。

すでに世界中で使われている製品のコードを、最適化コンパイラを通したあとの機械語の形で検証するのは、さらに難しくなります。AlphaProof Codeが挑んだのはこのケースです。

AlphaProof Codeが検証したもの：Signalの暗号の中核

出典: Signal公式サイト

今回検証されたのは、Signalの1対1のやり取りで使われる暗号処理の中核です。具体的には、libsignalとSPQRをコマンドライン用のプログラム「libsignal-cli」で包み、その中の「セッション開始（init）」「送信（send）」「受信（recv）」の3つの操作を検証しました。

対象となったプロトコルは次の2つです。

PQXDH: 会話を始めるときに、2人で共通の鍵を作る手順（鍵合意）。量子コンピューターでも破られにくい方式（耐量子暗号）を組み込んでいます
Triple Ratchet: メッセージをやり取りするたびに鍵を更新していく仕組み。従来のDouble Ratchetに、耐量子の仕組みであるSPQRを加えたものです

コードは標準のRustコンパイラ（rustc 1.98.1）でAArch64 Linux向けにビルドし、できた実行ファイルはSHA-256のハッシュ値で固定しています。つまり、証明は「このバージョンの、このバイナリ」についてのものです。

証明した主なセキュリティ性質

論文では、攻撃者がネットワークとサーバーを支配し、長期鍵やセッション状態を盗みうるという厳しい前提を置いています。そのうえで、次のような性質を証明しました。

性質	意味
前方秘匿性	今の鍵が漏れても、過去のメッセージは読まれない
侵害後の安全性	一時的に鍵が漏れても、その後のやり取りで安全性が回復する
送信側・受信側の秘匿性	当事者以外はメッセージの中身を知ることができない
認証・相手認証	メッセージが本当に相手から届いたものだと確かめられる
KCI耐性	自分の長期鍵を盗まれても、他人になりすまされない
セッション独立性	あるセッションが破られても、別のセッションには影響しない
「今収集して後で解読」への耐性	今の暗号文を保存しておき、将来の量子コンピューターで解読する攻撃への備え

これらは2つの方法で証明されています。1つは暗号が完全だと仮定して手順の穴を調べる「記号モデル」（10の定理）、もう1つは確率的な攻撃者に対して破られる確率の上限を示す「計算モデル」です。

AlphaProof Codeの仕組み：AIが証明を書き、Leanが判定する

出典: Lean公式サイト

AlphaProof Codeは、「人間が仕様を承認する」「AIが証明を書く」「Leanが機械的に確認する」という3段構えで動きます。AIの出力をそのまま信じるのではなく、Leanのチェックを通った証明だけを受け付けるのが特徴です。

構成要素	役割
仕様記述エージェント	人間の細かい指示のもとで、信頼できるLeanの定理と定義を下書きする。別のレビュアーエージェントが疑ってかかる立場で批評する
AArch64の形式意味論	ARMの機械語がどう動くかをLeanで書いたモデル。467命令・31システムコールを扱い、7,578行
証明エージェントのチーム	オーケストレーター、プルーフワーカー、チームリード、アーキテクト、インテグレーター、クリティック（仕様の修正案を審査する役。証明の試行は見ない）などに役割を分ける
ゲートキーパー	Leanのカーネルの検査を通り、かつ保管しておいた承認済みの仕様そのものを証明している場合だけ受理する。証明の穴埋め（`sorry`）や標準以外の公理は使えない

人間とAIの分担

論文によると、人間の担当は、検証の範囲を決めること、参考にする既存の安全性モデルを選ぶこと、信頼する仕様を承認すること、AIが困った場面への対応、仕様の修正案の判断、各作業の終わりに全修正をレビューすることです。著者は証明のコードを1行も書いていません。

DeepMindのブログによれば、エージェントが「人間の確認が必要」と判断した箇所はコードベースの約1%で、残りはLeanが自動で確認します（この1%という数字は論文には出てきません）。

使われたAIモデル

証明はすべてGemini 4 Carbonのエージェントチームが生成しました。仕様づくりでは、Gemini 4 CarbonとClaude Opus 5.5を使って人間とエージェントがやり取りし、下書きを「別のモデルファミリー」のエージェントがレビューしています。異なる会社のモデル同士でチェックし合うことで、1つのモデルの思い込みを減らす狙いです。

なお、ブログには「a mix of models」とあるだけで、Claudeの名前は論文にしか出てきません。各モデルの詳細はGemini 4 Carbonとは、Claude Opus 5.5とは、Gemini 4とはで解説しています。

数字で見るAlphaProof Codeの成果

今回の検証は、人手で何年もかかる規模の作業を5人のチームが4週間で終えた点が最大のニュースです。

項目	数値（出典）
生成された証明	約650万行のLean（論文。リポジトリ全体は約700万行。ブログは「600万行超」）
人間が信頼する部分（信頼ベース）	約2万6,000行（仕様約1万8,000行＋機械語の意味論など約8,000行）
検証したlibsignalのコード	約560KB、約14万命令
体制と期間	5人のチームで4週間（論文。論文の著者は9人）
エージェントの稼働	1回の作業で通常40〜80エージェント、1台のマシンで24〜72時間
計算コスト・費用	非公開

注目したいのは、証明そのものは650万行あっても、人間が中身を信じる必要があるのは約2万6,000行の仕様と前提だけという点です。証明が正しいかどうかはLeanが機械的に判定するため、人間はすべての証明を読む必要がありません。

過去のバグを入れ直して仕様の効き目を確認

仕様が本物のバグを捕まえられるかを確かめるため、過去に修正済みだったlibsignalのバグ2件を、隔離した環境でわざとコードに戻して再コンパイルしました。2件とも、セキュリティの定理に違反することが機械検査済みの証明で示されています。1件は、古いセッションでしか復号できないメッセージによって、秘密鍵のコピーを含むセッション状態が保存されてしまうバグ、もう1件は小部分群（small-subgroup）系のバグです。

既存の研究論文の誤りも見つかった

実際のコードに合わせて仕様を書く過程で、過去のSignalの安全性解析論文の誤りも見つかりました。論文によると、Double Ratchetの計算モデル解析に15の抜けやバグがあったほか、ProVerifという検証ツールを使った先行研究の条件にも誤りがありました。紙の上の解析と実装のずれを洗い出せた点も、この取り組みの成果です。

証明できたこと・できていないこと

AlphaProof Codeの成果は「Signalが完全に安全だと証明された」という意味ではありません。証明されたのは、範囲を絞った部分についての、仕様に書いた性質だけです。

区分	内容
証明できた	1対1セッションの開始・送信・受信（init / send / recv）の機械語レベルの安全性
証明できた	前方秘匿性、侵害後の安全性、認証、KCI耐性、セッション独立性など（記号モデル10定理）
証明できた	古典的な確率的攻撃者に対する、メッセージの機密性と真正性の上限（計算モデル）
対象外	鍵の生成（keygen）
対象外	グループメッセージ、3人以上の会話、複数端末の状態、sealed sender、サーバー側、ヘッダー暗号化
対象外	SPQRの「耐量子の回復（post-quantum healing）」。計算モデルの攻撃者は古典的なものだけ
対象外	ワンタイムのKyberプレキー。非常に長いセッションでは計算上の上限が意味をなさなくなる
対象外	サイドチャネル攻撃、メモリ内の他の秘密、リプレイによる前方秘匿性の喪失
前提として信頼	Leanのカーネル、AArch64の意味論、暗号プリミティブなど37ルーチンの約束事（契約）、ビルドスクリプト

AArch64の意味論が正しいかどうかは、形式的には証明できません。DeepMindはUnicorn、Sail、qemu-aarch64といった別のエミュレーターと動作を比べるテストで確認しています。

また、報道によれば今回の検証で新しい脆弱性は見つかっていません。今回の成果は「バグを見つけた」ではなく「調べた範囲にバグが無いことを示した」ものです。

AlphaProof Codeの強み

AlphaProof Codeの強みは、「AIの出力をLeanで検査する」ことで、AIが間違えても間違った証明が通らない仕組みにした点です。

未改変の製品コードを対象にできる: 検証のために書き直したコードではなく、実際に配布されているlibsignalをそのまま扱っています。論文は、広く使われている暗号プロトコル実装の未改変のコードとプロトコルレベルの安全性を結びつけた初の証明だと主張しています（DeepMind自身の主張で、第三者による評価はまだ出ていません）
コンパイラを信頼しなくてよい: 機械語で証明しているため、Rustのソースやコンパイラの最適化にバグがあっても、それを含めた最終的なバイナリについての保証になります
人手の作業が「仕様」に集中する: 証明はAIが書くので、人間は「何を保証したいか」を決めて承認する作業に集中できます

AlphaProof Codeの弱み・注意点

一方で、現時点では誰でも使える技術ではなく、保証の範囲にも明確な限界があります。

一般には使えない: エージェントの仕組みそのもの（オーケストレーターやエージェントの設定など）は公開されていません
バージョンが変わると検証し直し: 証明はlibsignal v0.105.4とSPQR v1.6.0の特定バイナリについてのものです。新しいリリースは改めて検証する必要があります
仕様の質がすべてを左右する: 仕様に穴があれば、証明が通っても安全とは言えません。論文でも、作業の大半は仕様づくりに使われたとしています
AIが仕様を弱めるリスク: エージェントが前提を勝手に足して証明しやすくするおそれがあります。ゲートキーパーや修正ルールで抑えていますが、これは運用上の対策で、数学的な保証ではありません
計算資源とコストが大きい: 数十のエージェントを数日動かす規模で、費用は非公開です

AIが書いたコードやAIエージェントの安全性全般については、AIコーディングのセキュリティリスクとAIエージェントのセキュリティ対策にまとめています。

AlphaProof Codeは使える？料金は？

DeepMindが検証の成果物を公開したGitHubリポジトリcode-verificationの画像

出典: GitHub google-deepmind/code-verification

AlphaProof Codeは現時点で一般提供されておらず、料金プランもありません。誰でも手に入るのは、検証の成果物（仕様・証明・ビルドスクリプト）です。

項目	現時点の状況
一般提供・アプリ	なし
API	なし
料金・プラン	なし（告知もなし）
フレームワーク本体の公開	確認できない（エージェントの設定などは非公開）
成果物の公開	あり（GitHub）
成果物のライセンス	Apache License 2.0。ただし同梱のlibsignalのコードはAGPL-3.0-only
今後の提供予定	発表なし

成果物を自分の業務で再利用する場合は、libsignal部分がAGPL-3.0である点に注意してください。

公開された証明を自分で確かめる方法

公開リポジトリのREADMEには、証明を自分の環境でビルドしてLeanに検査させる手順が載っています。DeepMindの主張を鵜呑みにせず、第三者が確認できるようにしています。

Leanのツールチェーン（leanprover/lean4:v4.34.0）のほか、Rust 1.98.1、protoc、LLVM ld.lld 22.1.8、Zig 0.16.0を用意する
lake exe cache get でMathlibを取得する
lake build を実行する
scripts/cli-elf-stock で検証対象の実行ファイルをビルドする
lake build CliElfLib を実行する
主定理（libsignal_cli_pq_secure_elf_binary_placed）が承認済みの仕様と一致するかを comparator/run.sh で確認する（Linuxのみ）

フルビルドには数時間かかり、メモリはピーク時で約15〜34GiB必要です。一般的なノートPCでは厳しいため、試すならメモリに余裕のあるLinuxマシンを使うのが現実的です。

他の検証の取り組みとの違い

AlphaProof Codeは、従来の人手による形式検証や、同時期に進むソースレベルの検証プロジェクトとは、対象と進め方が異なります。

比較項目	seL4・CompCert（従来の人手検証）	Signal Shot（ソースレベル）	AlphaProof Code（機械語レベル）
主体	研究者チーム	Beneficial AI Foundation・Signal・Lean FRO（2026年4月開始）	Google DeepMind
対象のコード	検証前提で書いたコード	SignalのRustソース	実際のlibsignalをビルドしたAArch64バイナリ
主な手段	人手で証明	RustをLeanに変換するAeneasとAIによる形式化	AIエージェントのチームが証明し、Leanが判定
かかった手間	seL4は20人年、CompCertは6人年	進行中	5人で4週間
コンパイラの扱い	CompCertはコンパイラ自体を検証	ソースで止まるためコンパイラは別問題	最終バイナリで証明するため信頼不要

論文では、AlphaProof CodeをSignal Shotに向けた「重要なマイルストーン」と位置づけています。競合ではなく、同じ目標に別の深さから取り組む関係です。

機械語レベルの検証にAIを使う動きはDeepMindだけではありません。論文の参考文献には、AnthropicとTheoremによる形式検証の研究や、OSカーネルxv6をAIエージェントでRISC-Vのハードウェアレベルまで検証した研究も挙がっています。Leanを使うAI研究の別の例としてはOpenAI Astraとはも参考になります。DeepMindのAIコーディングの取り組みでは、アルゴリズムを自動で改良するAlphaEvolveもあります。

Signalの利用者に影響はある？

Signalの利用者が何かを設定し直す必要はありません。今回の検証は、すでに使われているコードの安全性を後から証明したもので、アプリの動きは変わりません。

SignalのCTOであるEhren Kret氏は、DeepMindのブログで「Signalプロトコルの実装を厳密に検証できたことで、コードのプライバシー保証にさらに強い確信が持てる」とコメントしています。ただし、Signal公式ブログでの発表は確認できていません。また、検証の範囲は1対1の暗号の中核に限られ、グループチャットや端末のセキュリティまでは含みません。

企業・開発者にとっての意味

AlphaProof Codeそのものはまだ使えませんが、AIでコードを書く時代の品質保証の考え方として、企業や開発者にも示唆があります。

1つ目は、AIがコードを書くほど「何を保証したいか」を言葉にする力が重要になることです。論文の「証明が安くなると、難しいのは何を証明するかになる」という教訓は、形式検証を使わない現場でも、要件定義やテスト設計にそのまま当てはまります。

2つ目は、AIの出力を別の仕組みで機械的に検査するという設計です。AlphaProof CodeはAIを信じず、Leanが通したものだけを受け付けます。社内の業務システムにAIを組み込む場合も、出力をルールやテスト、別モデルのレビューで検査する層を設けると安全性が上がります。新しいモデルや機能を自社の業務システムに組み込むときの方法と費用の目安は、AI開発の費用相場【2026年10月】AI受託開発の改修・PoC・本開発の価格と見積の内訳で整理しています。

3つ目は、適用先が広がる可能性です。DeepMindはブログで、医療機器のファームウェアや電力網のソフトウェアといった重要システムへの応用と、コードの防御を自動で行うエージェント「CodeMender」との組み合わせを今後の方向として挙げています。論文では、コードを変更するたびにマージ前に検証するワークフローや、libsignalの新リリースを出荷前に検証することを目指すとしています。セキュリティ業界全体のAI活用はサイバーセキュリティ業界のAI活用事例でまとめています。

AlphaProof Codeの情報がおすすめな人・おすすめしない人

こんな人におすすめ

暗号や通信の安全性を担当するセキュリティエンジニア
AIが書いたコードの品質をどう担保するかを考えている開発者・テックリード
Lean、形式手法、定理証明に関心がある研究者・学生
Gemini 4 CarbonやClaude Opus 5.5が実務の難しいタスクでどう使われているかを知りたい人
Signalの安全性がどこまで確かめられたのかを知りたい利用者

よくある質問

AlphaProof Codeは無料で試せますか？

試せません。フレームワーク本体は公開されておらず、APIや無料枠もありません。無料で手に入るのはGitHubの検証成果物で、Leanの証明をビルドして検査する作業は誰でもできます。

Claude Opus 5.5は証明も書いたのですか？

いいえ。論文によると、Claude Opus 5.5が使われたのは仕様の作成とレビューで、証明はすべてGemini 4 Carbonのエージェントチームが生成しました。

「650万行」と「600万行超」はどちらが正しいですか？

どちらも同じ成果を指しています。論文では証明が約650万行（リポジトリ全体では約700万行）と細かく書かれ、ブログでは「600万行超」と丸めて表現しています。

形式検証されたコードは、ハッキングされないのですか？

仕様に書いた性質については、その前提が成り立つ限り破られないことが保証されます。ただし、仕様に書いていない攻撃（サイドチャネルなど）、信頼の前提にしたコンパイル環境や暗号の約束事、端末そのものの侵害には何も言えません。

自社のRustコードや他の言語のプログラムも検証できますか？

現時点で一般の人が自社コードをAlphaProof Codeにかける手段はありません。今回の対象はAArch64向けにビルドしたlibsignalだけで、他の言語や他のCPUへの対応も発表されていません。

生成AIでセキュリティ対策をするなら、まず何から始めればよいですか？

まずは、AIが書いたコードのレビュー体制、機密情報の扱い、AIツールの権限管理といった基本を固めるのが先です。全体像は生成AIのセキュリティリスクで解説しています。

まとめ

AlphaProof Codeは、Google DeepMindが2026年11月10日に発表した、AIエージェントのチームで形式検証を進める研究用の仕組みです。Signalの暗号実装libsignalについて、1対1の暗号の中核部分のセキュリティを、コンパイル後の機械語のレベルで証明しました。

証明はGemini 4 Carbonのエージェントが書き、Leanが機械的に判定。仕様づくりにはClaude Opus 5.5も使われた
5人のチームが4週間で約650万行の証明を生成。人間が信頼する部分は約2万6,000行
グループチャット、鍵生成、耐量子の回復などは対象外で、「Signalが完全に安全」と証明されたわけではない
一般提供・API・料金はなく、公開されたのは成果物（Apache 2.0）のみ

AIがコードを書く量が増えるほど、「何を保証すべきか」を決める人間の仕事と、AIの出力を機械的に検査する仕組みの重要性は高まります。AlphaProof Codeはその方向性を、実際に使われている暗号ソフトウェアで示した事例です。生成AIの基礎から整理したい人は生成AIとはもあわせてご覧ください。