Claude形式検証は、Anthropicが2026年10月22日に発表した、大規模言語モデル（LLM）を使って実在のオープンソースソフトウェアのセキュリティ特性を数学的に証明する取り組みで、協働企業Theoremとともに123のライブラリで「64MB未満のあらゆる入力でクラッシュしない」ことを証明しました。
室谷代表取締役AnthropicのFrontier Red Teamが、Claudeを使ってソフトウェアの形式検証を大規模にやったという発表を出したんですよね。これ、地味に見えてかなり大きい話だと思っていて。
テキトー教師DotAI 認定講師そうなんですよ。単に「AIがバグを見つけました」という話じゃないんです。
形式検証という、これまで一部のミッションクリティカルな領域でしか使えなかった手法を、LLMで実用的な規模に押し広げたという発表なんです。
形式検証という、これまで一部のミッションクリティカルな領域でしか使えなかった手法を、LLMで実用的な規模に押し広げたという発表なんです。
室谷代表取締役まず何が発表されたのか、整理しておきたいですよね。
テキトー教師DotAI 認定講師はい。Anthropicの公式ブログによると、協働企業のTheoremとともに、Claudeを使って100を超える実在のオープンソースライブラリのセキュリティ特性を証明した、と。
Anthropicの表現では「AIを使ってアセンブリコードレベルで形式検証を本番ソフトウェアに適用した初の大規模な取り組み」だと位置づけられています。
Anthropicの表現では「AIを使ってアセンブリコードレベルで形式検証を本番ソフトウェアに適用した初の大規模な取り組み」だと位置づけられています。
室谷代表取締役発表は2026年10月22日付で、Frontier Red Teamのブログ記事として出ています。Xでも「New on our Frontier Red Team blog」として告知されていました。
テキトー教師DotAI 認定講師ここで大事なのは、発表の主語はあくまでAnthropicだということです。Xで告知されたからXが発表した、という話ではないんですよね。
室谷代表取締役そこは記事として正確に押さえておきたいところです。
Claudeによる形式検証の大規模適用とは？Anthropicが2026年10月に発表した内容
まとめ
Claudeによる形式検証の大規模適用（Anthropic 2026年10月発表）
- 発表元はAnthropic（Frontier Red Team）、協働先はTheorem、発表日は2026年10月22日
- Claudeを使い123の実在オープンソースライブラリ・239のエントリポイントのセキュリティ特性を証明
- 証明の規模は約1.8億行のRocqコード、期間は数週間（公式ブログで over the span of a few weeks）
- 対象はGoogleのOSS-Fuzzプロジェクト。開発者作成のエントリポイントを出発点に利用
- 既存のファズテストを「常にパスする」という仕様としてエンコードする発想が肝
- 仕様をゼロから書くコストが大規模検証の障害になるため、既存テスト資産を仕様に変換
- 証明作成の過程で長年検出されなかったバグを発見・修正
テキトー教師DotAI 認定講師まず発表の全体像を整理するとこうです。
- 発表元: Anthropic（Frontier Red Team）
- 協働先: Theorem
- 発表日: 2026年10月22日
- 内容: Claudeを使い、123の実在オープンソースライブラリ・239のエントリポイントについてセキュリティ特性を証明
- 証明の規模: 約1.8億行のRocqコード
- 副産物: 証明作成の過程で、長年検出されなかったバグを発見・修正
室谷代表取締役239エントリポイントで123ライブラリという数字がまず規模感ですよね。しかもこれを「数週間」でやったと。
テキトー教師DotAI 認定講師そうです。公式ブログでも「over the span of a few weeks」と書かれています。
従来なら専門家が何年もかけるような作業を、数週間のスパンで回したというのが発表の核心です。
従来なら専門家が何年もかけるような作業を、数週間のスパンで回したというのが発表の核心です。
室谷代表取締役しかも対象がGoogleのOSS-Fuzzのプロジェクトなんですよね。OSS-Fuzzは継続的にファジングテストを提供している取り組みで、そこにある開発者作成のエントリポイントを出発点にしている。
テキトー教師DotAI 認定講師はい。既存のテスト資産を仕様に変換する、という発想がこのプロジェクトの肝なんです。
ゼロから仕様を書くのではなく、すでにあるファズテストを「このテストは常にパスする」という仕様としてエンコードする。
ゼロから仕様を書くのではなく、すでにあるファズテストを「このテストは常にパスする」という仕様としてエンコードする。
室谷代表取締役そこが実務的でうまいなと思いました。仕様を新しく書くコストが、形式検証の大きな壁のひとつだったので。
テキトー教師DotAI 認定講師公式ブログでも、テキストエディタやウェブブラウザにとって「正しい」とは何かを定義するのは難しい、包括的で曖昧さのない仕様を得ることが大規模検証の大きな障害になる、と明言されています。だからこそ既存テストを仕様に変換するアプローチを取った、と。
室谷代表取締役このあたりの形式検証の基礎は、AI業界の動きとは別軸で押さえておきたいテーマですよね。Anthropicのモデル戦略についてはAnthropic、最強エージェントモデル「Claude Sonnet 5」発表 性能はOpus 4.8に迫る低価格でも解説していますが、今回はモデルの性能そのものより「何に使ったか」の話です。
Claudeは形式検証で何を証明したのか——123ライブラリ・1.8億行のRocqコード
まとめ
Claudeの形式検証が示したこと
- 証明した性質: 対象プログラムが「64MB未満のあらゆる入力」と「モデル化されたあらゆるLinux OSの応答・メモリレイアウト」に対して、メモリ安全性エラーやアサーション失敗を起こさず必ず正常終了する
- 前提条件: シングルスレッドの静的バイナリ、固定メモリ予算、RISC-V CPU、Linux OS上で動く場合という限定つき
- 位置づけ: 公式ブログに「This is still far away from fixing all possible bugs」と明記。すべてのバグを直せるわけではないが以前よりずっと近づいた
- 証明の規模: 約1.8億行のRocqコード、典型的な証明は約60万行、対象バイナリの中央値は約18,000命令
- 検証の仕組み: Rocqのカーネル(証明チェッカー)が証明を仕様に対して検証。膨大な証明コードのほとんどは人手レビュー不要とAnthropicは説明
- 信頼する土台: RISC-VとLinuxプロセスの形式モデル、証明された定理文そのもの、Rocqの証明チェッカーのみ
- 用語: Rocqは以前Coqと呼ばれていた証明支援系。表記はソース(Anthropic)に合わせる
テキトー教師DotAI 認定講師証明の中身を具体的に見ていきましょう。Anthropicが証明したのは、対象プログラムが「64MB未満のあらゆる入力」と「モデル化されたあらゆるLinux OSの応答・メモリレイアウト」に対して、メモリ安全性エラーやアサーション失敗を起こさず必ず正常終了する、という性質です。
室谷代表取締役前提条件もセットで押さえないといけないですよね。シングルスレッドの静的バイナリで、固定メモリ予算、RISC-V CPU、Linux OS上で動く場合、という限定つきだと。
テキトー教師DotAI 認定講師そこは正確に伝えないといけません。公式ブログには「This is still far away from fixing all possible bugs」とはっきり書かれています。
すべてのバグを直せるわけではない、ただし以前よりずっと近づいた、という位置づけです。
すべてのバグを直せるわけではない、ただし以前よりずっと近づいた、という位置づけです。
室谷代表取締役証明の規模が約1.8億行のRocqコードで、典型的な証明は約60万行、対象バイナリの中央値は18,000命令くらいだと。Rocqというのは証明支援系の言語ですね。
テキトー教師DotAI 認定講師はい。Rocqのカーネル（証明チェッカー）が証明を仕様に対して検証する仕組みです。
ここが重要な設計思想で、膨大な証明コードのほとんどは人手でレビューする必要がない、とAnthropicは説明しています。
ここが重要な設計思想で、膨大な証明コードのほとんどは人手でレビューする必要がない、とAnthropicは説明しています。
室谷代表取締役開発者が信頼する必要があるのは、RISC-VとLinuxプロセスの形式モデル、証明された定理文そのもの、そしてRocqの証明チェッカーだけ、という整理ですよね。
テキトー教師DotAI 認定講師そうです。証明本体を全部読むのではなく、信頼する土台を小さく保つ設計なんです。
これは形式検証の世界では定石の考え方ですが、それをこの規模で回したのが今回の成果です。
これは形式検証の世界では定石の考え方ですが、それをこの規模で回したのが今回の成果です。
室谷代表取締役ちなみにRocqという名称、以前はCoqと呼ばれていた証明支援系です。AnthropicはRocqと表記しています。
テキトー教師DotAI 認定講師用語はソースの表記に合わせるのが安全ですね。
形式検証とは何か、なぜAIなしでは大規模化できなかったのか
テスト vs 形式検証
テスト
- 有限の入力しか試せない
- 無限の入力は試し尽くせない
- 点の確認というイメージ
形式検証
- コードを数学的モデルに変換する
- 定義した規則に必ず従うことを証明する
- 全入力に対する保証になる
- 面全体の保証というイメージ
室谷代表取締役ここで一度、形式検証そのものを整理したいです。テストとの違いが一番大事なんですよね。
テキトー教師DotAI 認定講師整理するとこうです。
- テスト: 有限の入力しか試せない。無限の入力は試し尽くせない
- 形式検証: コードを数学的モデルに変換し、定義した規則に必ず従うことを証明する。全入力に対する保証になる
- 証明に失敗: 規則違反のバグが存在する可能性を示す。失敗の性質からバグの当たりがつく
- 修正して再証明: これを繰り返して最終的に「規則違反のバグが存在しない」証明を得る
室谷代表取締役テストは点の確認、形式検証は面全体の保証、というイメージですね。
テキトー教師DotAI 認定講師まさにその比喩が近いです。ただ、従来はとにかくコストがかかった。
公式ブログにはseL4カーネルの例が出ていて、実装に2人年、形式検証に20人年かかったと。
公式ブログにはseL4カーネルの例が出ていて、実装に2人年、形式検証に20人年かかったと。
室谷代表取締役10倍ですもんね。しかも証明は元のコードより何桁も大きくなることがある。
高度に専門的なスキルが必要で、Airbusの航空電子コードのようなミッションクリティカルな用途に限られてきた、と。
高度に専門的なスキルが必要で、Airbusの航空電子コードのようなミッションクリティカルな用途に限られてきた、と。
テキトー教師DotAI 認定講師だからこそ「バグがないことを証明したいが、コストが見合わない」という長年の壁があったわけです。そこにLLMが入ると何が変わるかというと、何百万行ものコードを、明確に定義されたゴールに向かって粘り強く処理するのがLLMの得意分野だ、というのがAnthropicの主張です。
室谷代表取締役これはMYUUUでも実感があって、証明そのものというより「証明を書くための試行錯誤のループ」を回し続けるのが人間だとしんどいんですよね。失敗して、直して、また失敗して、を延々やる。
テキトー教師DotAI 認定講師講座でも受講生さんに「AIは何が得意か」を説明するときに、この「ゴールが明確な反復作業」という言い方をよくするんです。形式検証はその典型例なんですよね。
室谷代表取締役逆に、ゴールが曖昧だとLLMも力を発揮しにくい。だからこそ「既存テストを仕様にする」というゴールの作り方が効いたんだと思います。
Claudeはどうやって証明を書くのか——テストから証明へ、バグ発見までの流れ
テキトー教師DotAI 認定講師実際の流れを整理しましょう。公式ブログの図の説明に沿うと、こういうパイプラインです。
- オープンソースライブラリと既存のファズテストをRISC-V実行ファイルにコンパイルする
- TheoremのRISC-V・OS形式セマンティクスと「クラッシュしない」性質から、証明すべき仕様を機械的に生成する
- Claudeが証明を書く
- Rocqカーネルが仕様に対して証明をチェックする
- 証明の反復中にクラッシュを起こすバグが見つかれば、Claudeが修正し、修正後のコードで仕様を再生成して証明を続ける
室谷代表取締役5番が効いてますよね。人間が毎回止まらなくていいように、Claude自身にバグを直させて、直したコードで仕様を作り直して、また証明する。
テキトー教師DotAI 認定講師はい。公式ブログにも「Claude didn’t have to stop for a human every time」と書かれています。
この自動ループが、数週間で123ライブラリという規模を可能にした運用上のポイントです。
この自動ループが、数週間で123ライブラリという規模を可能にした運用上のポイントです。
室谷代表取締役ここで大事なのは、Claudeが「証明を書く」役割で、証明が正しいかどうかの最終判定はRocqカーネルがやる、という役割分担です。LLMの出力をそのまま信頼する構造になっていない。
テキトー教師DotAI 認定講師そこは誤解されやすいので強調したいですね。「AIが証明した」と言うと、AIの言い分を鵜呑みにするように聞こえますが、実際はチェッカーが通らなければ証明にならない。
だからこそ、信頼すべき対象を小さくできる。
だからこそ、信頼すべき対象を小さくできる。
室谷代表取締役この「生成するAI」と「検証するチェッカー」を分ける設計は、他の開発文脈でも応用が効きそうですね。
テキトー教師DotAI 認定講師そう思います。テスト駆動開発や仕様駆動の考え方とも親和性が高いんですよ。
テストを仕様に変換するという発想自体が、既存のテスト資産を資産として活かす方向なんです。
テストを仕様に変換するという発想自体が、既存のテスト資産を資産として活かす方向なんです。
Claudeによる形式検証で見つかったバグと、テストでは届かない領域
室谷代表取締役ここが一番わかりやすい成果ですよね。ファザーでは見つけにくいバグが見つかった、と。
テキトー教師DotAI 認定講師公式ブログに具体的な例がいくつも出ています。整理するとこうです。
- あるライブラリの解凍器のコピーでカウンタのアンダーフローがあり、境界外書き込みにつながった。ただし約20MBの、まれな特定レイアウトの入力でのみ発生
- 画像デコーダの境界外読み取りで、64MBの入力と2GB超のメモリを必要としたもの
- 同じファイルへの2つのハンドルをまたぐ特定の呼び出し順序を必要とした、別ライブラリの境界外読み取り
- libexpatのCVE-2026-56132の再発見。深くネストした入力が必要だった
- クラッシュしない論理バグ。あるライブラリで、アプリが読み込めるファイルを制限する機能が常に強制されているわけではないことに気づいた
室谷代表取締役ファザーは通常1MB程度の小さな入力を変異させて、コードカバレッジを頼りにバグを探す。だから20MBとか64MBの入力でしか出ないバグは、原理的に届きにくいわけですよね。
テキトー教師DotAI 認定講師そこなんです。テストは有限の入力しか試せない。
しかもファザーは「たまたま当たる」ことに依存する。形式検証は全入力を対象にするから、巨大な入力でしか出ないバグにも到達できる。
しかもファザーは「たまたま当たる」ことに依存する。形式検証は全入力を対象にするから、巨大な入力でしか出ないバグにも到達できる。
室谷代表取締役しかも面白いのが、証明の過程で「メモリ安全性を証明するために、別の性質も証明しないといけなかった」という話です。cpp-httplibの例で、std::setのデストラクタの再帰によるスタックオーバーフローを排除する必要があって、libc++の赤黒木のリバランスが対数オーダーで深さを抑えることを機械語レベルで証明した、と。
テキトー教師DotAI 認定講師これは形式検証の本質的な難しさでもあり面白さでもありますね。ゴールを証明するために、依存している部品の性質まで証明する必要が出てくる。
室谷代表取締役テストでは「たまたま通った」で終わるところが、証明だと「なぜ通るのか」を全部積み上げないといけない。
テキトー教師DotAI 認定講師さらに公式ブログでは、ファズテストがメモリ安全性だけでなく、エンコード・デコードの往復、冪等性、代数法則、差分テスト、自己整合性、参照実装との等価性といった高水準の性質をテストしている場合も多いと説明されています。LZO圧縮の例では、圧縮して展開すると元に戻ることをアサートしていて、これが失敗するとクラッシュする。
だからテストがクラッシュしないことを証明するのは、その性質自体を証明するのと等価になる。
だからテストがクラッシュしないことを証明するのは、その性質自体を証明するのと等価になる。
室谷代表取締役これは大きいですね。メモリ安全性だけの話に見えて、実はもっと広い性質の証明につながる。
テキトー教師DotAI 認定講師単に「バグを見つけた」な話じゃないんですよ。証明の対象をどう設計するかで、得られる保証の範囲が変わる。
Claude形式検証の限界と前提条件——信頼できる範囲・適用できないケース
室谷代表取締役ここからは限界の話をちゃんとやりたいです。発表を都合よく解釈しないために。
テキトー教師DotAI 認定講師まず前提条件です。今回の証明は、シングルスレッドの静的バイナリ、固定メモリ予算、RISC-V CPU、Linux OSという条件の上で成立しています。
室谷代表取締役マルチスレッドのプログラムや、動的にメモリを確保するプログラム、別アーキテクチャのバイナリは、そのままでは対象外ということですね。
テキトー教師DotAI 認定講師はい。ただしAnthropicは、より多くのアセンブリ・アーキテクチャや他のOSプロセスのセマンティクスを標準化すれば範囲を広げることは十分可能だと書いています。
現時点でどこまで対応するかは明らかにされていません。
現時点でどこまで対応するかは明らかにされていません。
室谷代表取締役あと、信頼すべき土台の話も重要です。RISC-VとLinuxプロセスの形式モデル、証明された定理文、Rocqチェッカー。
この3つにバグがあれば、証明全体が崩れる。
この3つにバグがあれば、証明全体が崩れる。
テキトー教師DotAI 認定講師公式ブログでも、これらの信頼コンポーネントの堅牢化は決して小さくない作業だと認めています。ただ、証明がカバーする全コードをデバッグするよりはるかに扱いやすい、と。
室谷代表取締役あと「バグがゼロになったわけではない」という点も、正確に伝えないといけない。残ったバグは信頼コンポーネントの中にあるか、証明のスコープ外にあるか、どちらかだと。
テキトー教師DotAI 認定講師そうなんです。あと、Anthropicは証明の独立検証を歓迎するとしていて、公開可能な信頼コンポーネント、パッチ不要だったファズテストの完全なRocq証明、証明できなかったファズテストの仕様を公開しています。
室谷代表取締役再現性と検証可能性を開いているのは、研究として誠実ですよね。
テキトー教師DotAI 認定講師それとTheoremが、他のオープンソースプロジェクト向けに同じパイプラインを提供する意向を示していて、開発者が自分のコードの検証を始めるためのClaudeスキルも公開予定とされています。
室谷代表取締役ここは実務者としては気になりますね。ただ、提供時期や料金などの詳細は現時点では明らかにされていません。
Claude形式検証を業務に組み込むには——開発者は何から始めるべきか
室谷代表取締役では、うちの開発チームだったら何から始めるか、という話をしたいです。
テキトー教師DotAI 認定講師公式ブログのメッセージはシンプルで、すべての開発者にLLMでの形式検証を探求してほしい、特に以前に能力の低いモデルで試してうまくいかなかった人に再挑戦してほしい、というものです。
室谷代表取締役これは刺さる人多いと思います。数年前に形式手法を試して「コストに見合わない」と判断したチームは、もう一度見てみる価値がある、と。
テキトー教師DotAI 認定講師導入の順番としては、いきなり全部を証明するのではなく、まず既存のテスト資産を見直すところからだと思います。ファズテストやプロパティベースのテストがあるなら、それは仕様のタネになります。
室谷代表取締役あとは対象を絞ることですね。シングルスレッドで、入力が明確で、クラッシュしないことが重要な部品。
パーサやデコーダのような、外部入力を受けるところから始めるのが現実的です。
パーサやデコーダのような、外部入力を受けるところから始めるのが現実的です。
テキトー教師DotAI 認定講師講座で受講生さんによく言うのは、「AIに何をさせるか」と「AIの出力を何で検証するか」をセットで決めるということです。今回で言えば、Claudeが証明を書き、Rocqがチェックする。
この役割分担を自分の業務に置き換えて設計する。
この役割分担を自分の業務に置き換えて設計する。
室谷代表取締役そこはまさにAI活用の基本に戻りますね。生成と検証を分ける。
テキトー教師DotAI 認定講師あと、コストの考え方もAnthropicは示していて、モデルが賢くなるほど証明を書くコストは下がり、さらに多くのコードが形式化されて手法が標準化されれば、証明の再利用や改変でコストは償却されていく、と。
室谷代表取締役一度書いた証明が資産になる、という発想ですね。テストも資産ですが、証明はより強い資産になりうる。
テキトー教師DotAI 認定講師ただし、チーム体制としては、形式検証の専門知識がまったく不要になるわけではありません。信頼コンポーネントの理解や、定理文が意図を正しく表しているかの確認は人間の仕事として残ります。
室谷代表取締役定理文が間違っていれば、正しい証明でも意味がない。そこは人間の責任領域として残るわけです。
テキトー教師DotAI 認定講師そういう意味では、仕様を書く力、何を保証したいかを言語化する力が、これまで以上に大事になります。
室谷代表取締役Anthropicはセキュリティ文脈でこの取り組みを出していますが、ソフトウェア開発全般のワークフローに「証明された保証」が入ってくる流れは、追いかけておきたいですね。
テキトー教師DotAI 認定講師関連するAnthropicの動きとしては、Anthropic、科学者向けClaude Teamプラン発表 無料枠と$15のプレミアム枠のような提供形態の変化もありますし、開発者向けの機能はAnthropic「Claude Design」発表：デザインシステム自動適用とClaude Code双方向連携の革新でも解説しています。
室谷代表取締役あわせて、モデルの安全性と能力のバランスをどう取るかという議論はAnthropic、Claude Fable 5公開即停止、安全性と創造性の板挟みでも扱っています。形式検証はその延長線上にある「保証をどう作るか」の話なんですよね。
テキトー教師DotAI 認定講師まさに。バグを見つけるAIと、バグがないことを証明するAI。
後者が実用域に入ってきたというのが今回の発表の意味だと思います。
後者が実用域に入ってきたというのが今回の発表の意味だと思います。
よくある質問
室谷代表取締役最後に、よく聞かれそうな点を整理しておきましょう。
テキトー教師DotAI 認定講師まず「Claudeに形式検証の専用機能が追加されたのか」という疑問ですが、今回の発表はFrontier Red Teamの研究ブログであり、Claudeの製品機能として形式検証ボタンが付いたという話ではありません。現時点で製品としての提供形態は明らかにされていません。
室谷代表取締役「どんなツールを使っているのか」という点は、Rocqの証明チェッカーと、TheoremのRISC-V・Linuxプロセスの形式セマンティクスです。Z3やTLA+といった他のツールを使ったという記述は、今回のソースにはありません。
テキトー教師DotAI 認定講師「どのくらいの期間でやったのか」は数週間です。「どのくらいの規模か」は123ライブラリ・239エントリポイント、約1.8億行のRocqコードです。
室谷代表取締役「どんなバグが見つかったのか」は、20MB前後の特殊入力でしか出ないアンダーフロー、64MB入力と2GB超のメモリを要する境界外読み取り、2つのハンドルをまたぐ呼び出し順序が必要な境界外読み取り、libexpatのCVE-2026-56132の再発見、クラッシュしない論理バグなどです。
テキトー教師DotAI 認定講師「無料で使えるのか」「日本から使えるのか」という点は、今回の発表では明らかにされていません。Theoremが他プロジェクト向けにパイプラインを提供する意向と、Claudeスキルを公開予定というところまでがソースに書かれている内容です。
室谷代表取締役「すべてのバグがなくなるのか」という問いには、はっきりノーです。対象はシングルスレッドの静的バイナリ、固定メモリ、RISC-V、Linuxという前提の範囲で、64MB未満の入力に対するクラッシュ不在の証明です。
テキトー教師DotAI 認定講師「以前に形式検証を試して失敗したが、また試す価値はあるのか」という問いには、Anthropic自身が再挑戦を促しています。モデル能力の向上で証明コストは下がり、証明の再利用でコストは償却される、というのがその理由です。
室谷代表取締役まとめると、今回の発表は「AIがバグを見つける時代」から「AIがバグの不在を証明する時代」への入り口を示した、ということなんですよね。
テキトー教師DotAI 認定講師そうですね。ただし証明の前提と限界をセットで理解することが前提です。
そこを外すと、過大評価にも過小評価にもなってしまう。
そこを外すと、過大評価にも過小評価にもなってしまう。
室谷代表取締役まずは自分のチームのテスト資産を見直して、仕様に変換できそうなものはどれか、考えるところから始めるのが現実的だと思います。
