サードパーティAPIの呼び出しは本当にあなたが選んだモデルなのか？Anthropic FlashProveが19MBの暗号学的証明で推論結果の身元を検証

作者注：通过第三方 API 调用大規模言語モデルを使う場合、回答の品質だけでは、実際にどのモデルが動いているのかを確認できません。本記事では、Anthropic がオープンソース化した FlashProve を取り上げます。zkSNARK を使って推論結果を指定した重みに結びつける仕組み、そのコスト、証明できること・できないこと、そして日常的な API 呼び出しに使えるようになるまでの距離を解説します。

2026 年 11 月 2 日、Anthropic Frontier Red Team は EPFL や MIT などの研究者と共同で、FlashProve：大規模言語モデル向けのオープンソースの検証可能推論（Provable Inference）プロトタイプを公開しました。400B パラメータの Llama 4 Maverick では、H100 1 枚で証明を生成でき、証明 1 件あたりのサイズは約 19 MB、通常の CPU で十数秒あれば検証できます。

これはコンセプトデモでも、スライド上だけの製品でもありません。Anthropic は技術レポート、プロトコル仕様書、実行可能な証明側（Prover）のコード、2 種類の検証側（Verifier）のコード、そして Lean による形式証明を同時に公開しており、すべて Apache 2.0 ライセンスのオープンソースです。ただし Anthropic 自身も、これはあくまで研究の途中経過であり、最終的な研究目標まではまだ道のりがあると明言しています。

この記事で得られること：第三方 API 呼び出しで「モデルの身元」を確認するのがなぜ難しいのか、FlashProve がどんな仕組みでそれを解決するのか、実際のコストと限界はどこにあるのか、そして API 利用者として今できることを整理します。

サードパーティAPIでモデルの身元が信頼できない理由

どのAPIにリクエストを送っても、返ってくるのはテキストとモデル名のフィールドだけです。Anthropicはリサーチブログで、今のユーザーには「回答が開発者の言うモデルから本当に返ってきたのか」を確認する手段がない、とはっきり述べています。ルーティングサービスがコスト削減のためにこっそりモデルをすり替えたり、攻撃者がトークンストリームを改ざんしたりする可能性があるためです。

さらに重要なのは、出力の品質が高いことは、モデルの身元が本物であることの証明にならないという点です。安価なモデルでも、特定の質問にはとてもよく答えることがあります。ダウングレードされたバージョンを、目で見て見分けられるとも限りません。チャット履歴を丸ごと公開したとしても、理論上はより安いモデルで偽造できてしまうので、そうした証拠には決定的な証明力がありません。

根本的な検証も簡単ではありません。最先端モデルのウェイトはほとんど公開されていません。仮にウェイトを入手できたとしても、推論をもう一度計算し直すのに必要な計算資源は、一般ユーザーはもちろん、評価機関にとっても負担できない規模です。Anthropicは、この種の信頼問題が生じる代表的なシナリオを次のように整理しています。

• サードパーティのルーティングサービス：顧客は、受け取ったトークンが、自分が料金を払って選んだモデルのものであることを確認したいと考えます。
• 独立評価：評価機関は、リリース前後にテストしたモデルが、実際にオンラインで提供されているモデルと同一であることを確認する必要があります。
• 改ざん検知：推論サーバーが侵害されると、攻撃者が悪意のある回答を紛れ込ませたり、ユーザーのコンピューターにマルウェアを送り込んだりするおそれがあります。
• 規制とコンプライアンス：規制当局は、安全審査を通過したモデルだけをデプロイするよう求めたり、ハードウェアが密かに学習ではなく本当に推論を実行していることの確認を求めたりする可能性があります。

証明可能な推論（Provable Inference）が目指すのは、計算資源が限られていて、ウェイトも知らないユーザーでも、ある回答が本当にリクエストしたモデルから返ってきたものかどうかを検証できるようにすることです。

FlashProve コア情報 早見表

特筆すべき点として、Anthropic はシステム内の最適化作業の多くを Claude が担ったと述べています。AI が大規模で複雑なシステムの中で下す「評価が難しい意思決定」に対処するため、チームは Lean で監査可能なトップレベルの安全宣言を記述し、その対抗策としました。

FlashProveが「指定モデルによる推論」を証明する仕組み

FlashProveの登場人物は2人だけです。モデル提供者が証明者(Prover)、ユーザーが検証者(Verifier)を務めます。全体の流れはオフラインとオンラインの2段階で、そこに検証側のチェックが加わります。

FlashProveの3ステップの仕組み

1. オフラインでのモデルコミットメント(Model Commitment):証明者は、モデルの重みに対するコミットメントを公開します。ごく短い「フィンガープリント」のようなものだと考えてください。これにより、特定の重みの組み合わせが確定しますが、重みそのものは隠されたままです。テストでは、この処理はモデルごとに1回だけ実行すれば済み、所要時間は約39分でした。生成されたコミットメントは約1600万リクエストを支えられ、それを超えたら再度コミットメントが必要になります。
2. オンラインでの証明生成:検証者からリクエスト(プロンプトと対応する出力トークン)を受け取ると、証明者は証明ファイルを生成します。この証明が示すのは「コミットされたモデルを実行すると、これらの出力トークンが生成される」という命題です。
3. 検証側でのチェック:コミットメント、プロンプト、回答を持っていれば、誰でも証明をチェックできます。重みは必要なく、必要な計算資源もわずかです。それでも、コミットされた重みがこのプロンプトに対して確かにそれらのトークンを生成したと確信できます。

FlashProveの4つのセキュリティ特性

最初の2つ(完全性と健全性)は、重みを知っていて計算資源も十分にある検証者なら、自分で再計算すれば実現できます。このシステムを意味あるものにしているのは、後半の2つです。

• 完全性(Completeness):正直な証明者が生成した証明は、必ず受理されます。
• 健全性(Soundness):虚偽の命題に対して有効な証明を偽造するのは、広く信頼されている暗号学的仮定を破るのと同じくらい困難です。そのため、検証者は証明者を信頼する必要がありません。
• ゼロ知識(Zero Knowledge):検証者は、重みや中間計算値を知ることができず、各層でどのエキスパートが活性化したかも分かりません。ただし、モデルのアーキテクチャ自体は秘匿されません。
• 簡潔性(Succinctness):証明の対象は約232 GBの量子化モデルによる1回の実行ですが、検証者が受け取るのは約19 MBのファイルだけです。24コアCPUなら数秒でチェックできます。

MoEアーキテクチャがFlashProveの証明コストを下げる理由

FlashProveの高速化は、MoE(Mixture of Experts、混合エキスパートモデル)の構造を大いに活用しています。Llama 4 Maverickでは、1トークンあたり400Bパラメータのうち約17Bしか使われません。証明者の作業量もこの約17Bに比例し、それでいて、どのエキスパートが選ばれたかは証明の中でも隠されたままです。

ほかに、2つの工夫も重要です。1つ目は事後バッチ証明です。証明者は、Prefillのように生成済みのテキストを一度に並列で読み込み、バッチごとに重みのコミットメントを1回だけ開きます。2つ目は単一GPUへの対応です。重みをレイヤーごとに分割して順番に証明し、通常のメモリからストリーミングで読み込みます。これにより、80 GBのGPU 1枚と約290 GBのホストメモリで動作します。

FlashProve の証明コスト実測データ

可証明推論(Provable Inference)が実用に耐えるかどうかを判断するうえで、コストは最も重要な指標です。Anthropic のテスト環境は次のとおりです。証明側は H100 1枚と CPU 24コア、検証側は CPU のみ、各リクエストは 1024 トークンのウィンドウです。

比較のベースラインは、H100 を 8 枚使い、vLLM で同じモデルの FP8 版を動かした場合です。言い換えると、1 バッチ分のリクエストを証明するのにかかる GPU 時間は、通常の推論で同じバッチを処理する場合の 70〜95 倍、つまり約 2 桁分のオーバーヘッドがかかることになります。

110 tokens/s は「回答全体をリアルタイムで証明できる」という意味ではない

FlashProve を読み解くうえで、ここは特に誤解されやすいポイントです。技術レポートでは、各証明が実際にチェックするのはプロンプトの後ろにある1 トークンだけだと明記されています。110 tokens/s は、証明側がリクエストのウィンドウを処理するスループットであり、回答全体をトークンごとに検証する速度ではありません。

したがって、「FlashProve はすでに回答全体をリアルタイムで証明できる」という言い方は正確ではありません。より厳密に言うなら、バッチ処理・短いコンテキスト・事後証明という条件のもとで、可証明推論のコストをこれまで想像できなかった水準まで引き下げた、ということになります。

FlashProve と既存の検証可能推論方式の比較

検証可能推論（provable inference）は、学術界では一般に zkML と呼ばれています。Anthropic はブログでこれまでの進展を振り返っており、数値を並べると違いがよくわかります。

VerInf との比較：VerInf は、これまでに同じモデルの証明を実現した唯一の方式として知られています。ただし証明サイズは 93.6 GB にもなり、検証にはほぼ丸一日かかるため、実用はほぼ不可能でした。これに対して FlashProve は、証明サイズを約 19 MB まで圧縮し、検証時間も十数秒まで短縮しています。一般的な CPU でも第三者による監査が現実的になったのは、これが初めてです。

Attestable との比較：Attestable は Dense モデルで商用レベルの優れた数値を出していますが、ブログ執筆時点では対応するオープンソースライブラリが公開されていません。FlashProve の強みは、コード・Lean の証明・ドキュメントがすべて公開されており、誰でも再現や改良ができる点です。その代わり、現状は MoE アーキテクチャへの依存度が高いという制約があります。

FlashProve が証明できること、できないこと

サードパーティAPIのユーザーにとって、できることと同じくらい、その限界を理解しておくことも大切です。下の表は、研究ブログと技術レポートに書かれている主な制約をまとめたものです。

FlashProve の事後証明が抱える検出の限界

FlashProve が採用しているのは事後証明（Post-hoc Proving）です。ユーザーが先にレスポンスを受け取り、そのあとで独立した証明サーバーが再計算して証明を生成し、最後に検証者がそれをチェックします。この方式では証明にある程度時間をかけられるため、安全性と効率のどちらかを犠牲にせずに済みます。一方で、保証が得られるまでに遅延が生じます。証明の失敗は問題を明らかにするだけで、ユーザーが回答を受け取る前に守ってくれるわけではありません。

技術レポートでは、次の点にも注意が促されています。ログシステム自体を攻撃者が掌握している場合、ユーザーには改ざんした内容を送りつつ、ログには正しい結果だけを記録させることが可能になります。そのため、FlashProve は信頼できるログやアクセス制御などのセキュリティ対策と組み合わせて使う必要があります。

FlashProve の形式検証で未完了の部分

「Lean で形式的に証明した」と聞くと、「システム全体の正しさが証明された」と受け取りがちですが、実際はそうではありません。技術レポートに挙げられている範囲の限界は次のとおりです。

• ゼロ知識性に関する Lean での証明は、現時点では単一リクエストの証明のみが対象で、バッチ証明には及んでいません。
• GPU 側の証明器のコードは、Lean での表現をもとに AI が生成したもので、Lean の表現と等価であることはまだ証明されていません。
• 日常的に使う C++ の高速検証器も AI が生成したもので、形式的な保証はありません。テストで Lean 側の検証器とすべて同じ結論になったという段階です。
• 長めのプロトコル仕様書は AI が生成したもので、著者が詳しく確認したわけではありません。著者自身が書いた技術レポートとは分けて読む必要があります。

これらの制約があるからといって、研究に意味がないわけではありません。現時点の形式検証が押さえているのはプロトコル層の数学的性質であり、実行されるコードとプロトコルのあいだは、人間やエージェントによる監査で埋める必要がある、ということです。

影響分析：FlashProve はサードパーティAPIの日常的な呼び出しにどこまで近づいたのか

開発者・API利用者への影響

• 当面は日常的な呼び出しフローには登場しません：GPUのオーバーヘッドが約2桁も増えること、リクエストごとに約19 MBの証明ファイルが必要になること、コンテキストウィンドウが1024トークンに限られることから、頻度の高い対話型APIにそのまま使うのは困難です。
• 適用範囲が限られます：このシステムはMoEアーキテクチャ、整数化されたモデル、貪欲デコーディングを前提としています。一方、本番環境の呼び出しの多くはランダムサンプリングと浮動小数点推論を使っているため、そのまま適用することはできません。
• 認識面での価値のほうが大きいといえます：「モデルの身元を検証する」ことが、不可能な話から工学的に取り組める課題へと初めて変わりました。レスポンスに含まれるモデル名のフィールド、モデルID、通常のリクエストログは、いずれも暗号学的な証明と同じものではない点に、開発者は注意しておく必要があります。

💡 選び方のヒント：証明可能な推論が成熟するまでは、サードパーティのサービスを選ぶ際に、課金の透明性、呼び出しログの追跡可能性、自分で試したときの出力の一貫性を重視するのがおすすめです。APIYI（apiyi.com）のような集約プラットフォーム経由で呼び出せば、複数のモデルに同時にリクエストを送り、呼び出し記録を完全な形で残せます。そのため、自分で相互比較や監査を行いやすくなります。

業界・規制への影響

• 評価とコンプライアンスのツールボックスに選択肢が1つ増えました：規制当局は、一定期間の推論リクエストに証明を付けるようプロバイダーに求めることで、指定されたモデルを実際にハードウェアが提供していることを確認できます。その際、独自の重みを知られることもありません。ただしAnthropicは、ハードウェアが裏でトレーニングを行っていないことまでは証明できないとも認めています。
• ソフトウェア方式と信頼できるハードウェアは補完関係にあります：信頼実行環境（TEE）はベンダーの耐タンパーハードウェアに依存し、zkSNARKは計算問題の困難性に依存します。zkSNARKは、ハードウェアやOSが侵害されても証明を偽造できません。両者はそれぞれ異なる場面で力を発揮するでしょう。
• Anthropicの本番環境での検証は別のアプローチです：Anthropicは2026年10月19日に更新したFrontier Safety Roadmapで、推論検証プロジェクトが本番の推論トラフィック上でプロトタイプ化されていると述べています。内部のトークントラフィックに署名を付け、信頼できるサーバー上で推論を再計算する仕組みで、極めてまれで悪意のない整合性の異常を1件検出したこともあるそうです。このプロジェクトは名称がinference verificationに変更されており、FlashProveとは関連はあるものの独立した別のプロジェクトです。混同しないようにしてください。

サードパーティAPI利用者が今できること：呼び出し監査ログを自作する

暗号学的な証明はまだ実用段階にありません。そこで開発者としては、まず「追跡可能性」をしっかり確保しておきましょう。以下のサンプルでは、呼び出し時に temperature=0 を固定し、リクエスト時刻・リクエストID・返却されたモデルフィールド・回答のハッシュ値をローカルのログに書き込みます。後から一貫性を再テストするときに役立ちます。ただし、これはあくまでエンジニアリング面での監査記録であり、モデルの同一性を暗号学的に証明するものではありません。

import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # APIYI の OpenAI 互換インターフェース
)

resp = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "用一句话解释零知识证明"}],
    temperature=0
)
print(resp.model, resp.id)
print(resp.choices[0].message.content)

import hashlib
import json
import time
import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # 1つのキーで複数社のモデルを呼び出せる
)

def audited_call(prompt: str, model: str, log_path: str = "audit.jsonl") -> str:
    """モデルを呼び出し、追跡可能な情報を記録する（暗号学的証明ではない）"""
    start = time.time()
    resp = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        temperature=0,
        max_tokens=512,
    )
    content = resp.choices[0].message.content or ""
    record = {
        "ts": int(start),
        "latency_s": round(time.time() - start, 3),
        "requested_model": model,
        "returned_model": resp.model,   # サーバー側が返した申告フィールドにすぎない
        "request_id": resp.id,
        "prompt_sha256": hashlib.sha256(prompt.encode()).hexdigest(),
        "output_sha256": hashlib.sha256(content.encode()).hexdigest(),
        "usage": resp.usage.model_dump() if resp.usage else None,
    }
    with open(log_path, "a", encoding="utf-8") as f:
        f.write(json.dumps(record, ensure_ascii=False) + "\n")
    return content

# 固定のプローブ用プロンプトを用意し、定期的に再テストして出力ハッシュとレイテンシ分布を比較する
probes = ["计算 37*43 并只输出结果", "列出三种排序算法的时间复杂度"]
for p in probes:
    for m in ["gpt-4o-mini", "claude-sonnet-4-5"]:
        print(m, audited_call(p, m)[:60])

🚀 クイックスタート：APIYI（apiyi.com）で無料のテスト枠を入手し、上記のプローブスクリプトで複数のモデルを定期的に再テストしてみましょう。なお、この方法で高められるのは追跡可能性だけで、FlashProve のような重みレベルの証明の代わりにはなりません。

これに加えて、次のような実践的な工夫も組み合わせられます。

• あいまいなエイリアスではなく、モデルIDを固定して指定する
• プローブ用プロンプトを一組残しておき、出力とレイテンシの変化を長期的に追跡する
• 重要な業務では、複数のモデルに同時にリクエストして相互検証する
• サービス提供元が重みに関するコミットメントや検証可能な仕組みを公開していないか、動向をチェックする

よくある質問 FAQ

FlashProve の重要ポイント Key Takeaways

• 信頼のギャップは実在する：サードパーティ API の呼び出しでは、回答の品質が高いからといって、モデルの身元が本物だと証明されるわけではありません。
• 基本の仕組み：オフラインの重みコミットメントと、オンラインの zkSNARK 証明を組み合わせます。ユーザーは CPU だけで検証できます。
• コストが大幅に低下：H100 1 枚のウィンドウスループットは約 110 tokens/s、証明サイズは約 19 MB、検証時間は約 17 秒です。
• 数値の基準を区別する：トークンごとのチェックのスループットは 39.1 tokens/s で、単一リクエストでは 17.6 tokens/s にとどまります。
• 適用範囲は限定的：対象は MoE、整数化した貪欲デコーディング、1024 トークンのコンテキスト、そして事後検出に限られます。
• 始め方：現時点では、APIYI（apiyi.com）のマルチモデル統合インターフェースを使えば、自分で再テストや監査を行えます。

まとめ

FlashProve の意義は、次の 3 点に整理できます。

1. モデルの身元確認をエンジニアリングの問題に変えた：これまで同一モデルであることを証明するには、十数時間と100 GB 近い証明サイズが必要でした。それがバッチ処理で100 tokens/s 前後のスループットと、19 MB の証明まで圧縮されました。
2. 本番利用にはまだ距離がある：オーバーヘッドが2桁も大きいこと、コンテキストが短いこと、アーキテクチャやデコード方式に制約があることに加え、形式検証のカバー範囲も不完全です。こうした点から、現状はあくまで研究プロトタイプといえます。
3. ほかのセキュリティ機構との併用が必要：事後証明でできるのは検出だけで、不正をその場で止めることはできません。信頼できるログやアクセス制御と組み合わせる必要があります。

今日サードパーティ API を使う方にとって、最も現実的な姿勢は次のとおりです。モデル名のフィールドを証明として扱わないこと。かといって、必要以上に不安になることもありません。まずは呼び出し記録、プローブによる再テスト、複数モデルでのクロスチェックをしっかり固めましょう。そのうえで、検証可能な推論技術が成熟していく様子を引き続き見守るのがおすすめです。APIYI（apiyi.com）なら 1 つのキーで複数のモデルを比較できるので、自社の業務データを使って、追跡可能な品質のベースラインを築くことができます。

📚 参考資料

1. Anthropic 研究ブログ – Progress on provable inference for large language models：FlashProve の公式発表記事
2. リンク： anthropic.com/research/provable-inference

3. 説明： システム設計、実測データ、既存手法との比較、制約事項が掲載されています

4. FlashProve 技術レポート：研究ブログに添付されている詳細な技術資料

5. リンク： anthropic.com/research/provable-inference（ページ内の Read the technical report から参照）

6. 説明： スループットの算出基準、事後証明の限界、形式検証の適用範囲など、重要な前提条件が記載されています

7. Anthropic Frontier Safety Roadmap：推論検証プロジェクトの進捗に関する説明

8. リンク： anthropic.com
9. 説明： inference verification と FlashProve の違いを把握できます

著者: APIYI 技術チーム
技術交流: APIYI 公式サイトのトップページからお気軽にお問い合わせください。接続に関する資料は docs.apiyi.com のドキュメントセンターでご覧いただけます

関連記事

• モデルが「賢くなくなった」のは、必ずしも別のモデルに置き換えられたからではない：API呼び出し時に性能が低下する6つのよくある原因と3ステップの切り分け手順:AnthropicがFlashProveの推論証明に関する研究を発表しましたが、重みの同一性を確認した後も、システムプロンプトやコンテキストの切り捨て、デコードパラメータなどによってモデルの性能が低下する可能性があるため、この記事ではその主な原因と具体的な調査手順を整理します。