AIモデルの名前を信じる前に——PLaMo公開とFlashProveから作る「モデル受領票」

AIを導入するとき、私たちは画面に表示されたモデル名をかなり信頼しています。契約書には上位モデルの名称があり、社内サーバーには公開された重みを置き、翻訳アプリには「オンデバイス」と書かれています。しかし、その名前だけで、実際にどの重みが動き、どの量子化が使われ、入力がどこを通り、返答が途中で差し替えられていないかまで分かるわけではありません。

2026年11月、Preferred Networksは翻訳特化型LLM「PLaMo 3 Translate」の重みを公開しました。0.8B、2B、8B、31Bの四つのサイズを用意し、スマートフォン、ノートパソコン、社内サーバーなどで、クラウドを介さずに翻訳できる構成を示しています。機密文書や通信が不安定な場所で、日本語を含む53言語の翻訳を手元へ置ける可能性があります。

一方、Anthropicは、応答が本当に指定したモデルから出たことを暗号学的に確かめる研究用システム「FlashProve」を公開しました。モデル提供者が重みの短い指紋を先に示し、応答ごとに証明を作ることで、利用者は重みそのものを持たなくても、別モデルへの差し替えや応答の改変を見つけやすくします。

二つの発表は、公開モデルと非公開モデルという反対側から同じ問題を照らします。重みを入手できても、実際の配備がその重みのままとは限りません。証明が付いても、回答内容が正しい、ライセンスに合う、入力が安全に扱われた、という全てを保証するわけではありません。日本の企業、自治体、学校、個人に必要なのは、モデル名を受け取ることではなく、モデル、実行条件、仕事、結果、証拠を一件として受け取る「モデル受領票」です。

AIモデルが動く計算基盤を想起させる電子回路基板

結論——モデル名ではなく「この一件を何がどう処理したか」を受け取ります

AI調達で最初に変えるべきことは、製品名やモデル名を品質証明の代わりにしないことです。同じ名称でも、版、重み、量子化、推論エンジン、システム指示、検索データ、温度設定、提供地域が違えば、結果は変わります。提供者側の負荷や料金プランによって別モデルへ振り分ける仕組みがあれば、画面上の名称だけでは実行経路を確定できません。

モデル受領票では、次の四層を分けます。

層	受け取るもの	確かめる証拠
モデル	名称、版、重み、量子化、ライセンス	配布元、ハッシュ、モデルカード、契約
実行	推論エンジン、端末、地域、設定、外部接続	配備記録、構成表、通信記録、変更履歴
仕事	入力、目的、用語集、禁止事項、完了条件	作業識別子、承認済みテンプレート、受入例
結果	出力、証明、確認者、差分、復旧先	出力ログ、推論証明、受入結果、戻し手順

公開された重みを自社端末で動かす場合は、モデル層と実行層を自分で管理しやすくなります。クラウドの非公開モデルを使う場合は、提供者が出す契約、モデル識別情報、証明、監査報告へ依存します。どちらにも長所がありますが、「ローカルだから安全」「大手クラウドだから同一」という一語で閉じないことが大切です。

PLaMo 3 Translateは、翻訳モデルを手元へ持てる選択肢を増やします

Preferred Networksの発表によると、PLaMo 3 Translateは0.8B、2B、8B、31Bの四サイズで公開されました。利用者は求める品質、速度、処理量、端末に応じて選べます。最小の0.8Bモデルをネット接続のない機内モードのスマートフォンで動かすデモも示されています。

公開されたのは、アプリの画面だけではなく、端末で推論するためのモデル重みです。PFNの技術解説では、BF16に加え、複数の量子化形式、GGUF、MLX向けの配布も案内されています。日本語と英語を含む53言語、周辺文脈、用語集、常体と敬体の指定に対応すると説明されています。

これは日本で使う翻訳の入口を広げます。工場の手順書、研究開発資料、顧客とのやり取り、災害時の案内などは、外部サーバーへ原文を送りにくいことがあります。通信が細い場所や停止した場所では、クラウドだけに依存すると翻訳そのものが使えません。端末や社内サーバーへモデルを置ければ、送信先と通信状態を自分たちで管理できます。

ただし、重みを公開していることと、どの用途でも無条件に使えることは別です。PFNはPLaMoコミュニティライセンスを設け、個人や非商用利用、商用利用の条件を分けています。発表では、直近事業年度の収入または売上が10億円以下の企業と個人について、定められた条件の下で商用・非商用利用が可能と説明されています。規模を超える商用利用には別の契約が必要です。

配布元、モデルの大きさ、形式、ライセンス、取得日を一緒に保存しなければ、「オープンウェイトを使った」という記録だけが残ります。モデルを更新したときは、古い版を消す前に、何が改善し、何が変わり、以前の訳文を再現できるかを確認します。

オンデバイスは「外へ送らない経路」を作れますが、無条件の安全ではありません

ノートパソコンを二人で確認し、手元の実行環境を点検する場面

オンデバイス翻訳の分かりやすい利点は、原文と訳文を外部の推論APIへ送らずに済む構成を作れることです。しかし、モデルが端末内にあるだけで、情報管理の全工程が端末内に閉じるとは限りません。

アプリが利用状況を送信する場合があります。OSのバックアップが入力履歴や設定をクラウドへ同期する場合があります。用語集を共有ストレージへ置けば、そこから固有名詞や取引情報が漏れる可能性もあります。翻訳結果をメールやチャットへ貼り付けた後は、別のサービスの保存条件に移ります。端末の盗難、画面共有、マルウェア、権限設定も残ります。

したがって、「ローカル実行」を次の四つへ分解します。

モデルの重みがどこに保存され、誰が更新できるかを記録します。
原文、用語集、中間データ、訳文がどこに残るかを記録します。
推論中と推論後に、どの宛先へ通信するかを観測します。
端末を紛失、退職、交換したときに、何を削除して利用を止めるかを決めます。

この確認は、海外モデルか国産モデルかという分類より細かいものです。以前のAIの入力、記憶、実行、送信を一件で管理する実行経路票でも、モデルの出自だけで日常の権限管理を置き換えない方法を整理しました。今回のモデル受領票は、その実行経路へ重みと証明を追加するものです。

小型モデルは「小さいほど良い」ではなく、仕事へ十分な最小サイズを選びます

PLaMo 3 Translateの四サイズは、モデル選択を性能順位ではなく配置問題として考える材料になります。0.8Bは端末へ置きやすく、応答と消費電力を抑えやすい一方、文書の難しさや長さによっては上位サイズが適する可能性があります。31Bは品質余裕を期待できますが、メモリー、保存容量、導入時間、更新時間が増えます。

選定では、一般的なベンチマーク順位より、自分たちの文書を使います。観光案内、機械の警告、契約条項、研究要旨、医療・福祉の案内では、間違いの影響と許せる待ち時間が違います。PFNの比較結果には自社ベンチマークも含まれるため、公開された優位性をそのまま自社の合格判定へ移さず、代表文書と重要語で受け入れます。

モデル受領票には、少なくとも三段階の試験を置きます。

日常文では、意味、数字、固有名詞、敬体・常体、処理時間を確認します。
重要文では、否定、条件、単位、期限、責任主体、例外が保たれるかを確認します。
停止時では、端末がオフラインでも動くか、上位モデルへ送れないときに人へ渡せるかを確認します。

小型モデルが合格する仕事は小型へ置き、合格しない仕事だけを大きなモデルや人へ送ります。これなら、全件を最大モデルへ投げる費用と電力を避けながら、重要文書の品質を下げません。以前のAIモデルをAPI、一台、共有機、分散環境へ置き分ける記事と組み合わせると、モデルサイズと配置先を一件の仕事から逆算できます。

FlashProveは「表示された名前」から「重みに結び付く証明」へ進めます

クラウドサービスでは、利用者がモデルの重みを受け取れない場合があります。契約したモデルと実際に応答したモデルが同じかを、自分で再実行して比べることも難しいです。大規模モデルには高価な計算資源が必要で、同じ出力を必ず再現できるとも限りません。

Anthropicの研究発表は、この問題へ暗号学的な推論証明を使います。FlashProveでは、提供者がモデル重みに対応する短いコミットメント、つまり指紋を先に公開します。応答後には、その指紋へ結び付いた重みが、与えられた入力から指定の出力トークンを生成したことを示す証明を作ります。

利用者はモデル重みを知らなくても、コミットメント、入力、応答、証明を使って確認できます。証明が通らなければ、期待した重みと異なるモデル、変更された入力や出力、誤った証明のいずれかを疑えます。提供者の秘密である重みそのものは証明から漏らさない設計です。ただし、現在の仕組みはモデルの構造まで隠すものではありません。

TechCrunchの報道は、安価なモデルへひそかに差し替えて費用を下げる場合や、高価なモデルを使ったように見せて成果を誇張する場合を、想定される用途として紹介しています。これは料金だけの問題ではありません。安全評価、脆弱性調査、契約上の承認モデル、行政や医療周辺の利用では、どのモデルが作業したか自体が監査対象になります。

証明が通っても、回答が正しいとは限りません

推論処理を実装するコード画面の接写

ここは最も大切な境界です。FlashProveが目指すのは、「この重みのモデルが、この入力から、この出力を作った」という実行の同一性です。そのモデルが正しい知識を持つ、差別的でない、契約判断に適する、翻訳が正確である、といった内容の合格を自動的に示すものではありません。

たとえば、承認済みの翻訳モデルが数字を取り違えた場合でも、指定されたモデルが実際にその誤訳を出したなら、推論証明は成立し得ます。逆に、別のモデルが偶然に正しい訳を返しても、契約したモデルの証明は通りません。モデル同一性と出力品質は、別の試験です。

このため、モデル受領票では三つの問いを並べます。

誰が処理したかは、モデル識別子、重みのハッシュやコミットメント、実行記録で確かめます。
何を処理したかは、入力の版、用語集、システム指示、検索資料で確かめます。
仕事を終えたかは、数値、固有名詞、禁止事項、出力形式、人の承認などの受入条件で確かめます。

技術指示の翻訳では、自然な文に見えるだけでは足りません。AI翻訳を仕様、図面、変更、現物の受入試験へつなげた記事で整理したように、受け手が同じ部品を選び、同じ条件で停止し、同じ検査で合否を決められることが必要です。推論証明は、そこへ「どのモデルが訳したか」という証拠を足しますが、現物確認の代わりにはなりません。

現在のFlashProveは、日常サービスへそのまま載る完成品ではありません

AnthropicはFlashProveを研究途中のプロトタイプとして公開しています。発表時点の評価では、MetaのLlama 4 Maverickの公開4ビット版を使いました。4000億パラメータのMixture of Expertsモデルで、各トークンでは約170億パラメータが使われる構成です。

一台のH100と24コアCPUを使った測定では、24件をまとめた証明生成が毎秒約110トークン、各証明は約18.78MBでした。利用者側はGPUを必要とせず、24スレッドのCPUで一件を約17秒、単一スレッドで約21秒かけて確認したとされています。ただし、証明作成に使うGPU時間は、通常の推論と比べておよそ70〜95倍でした。

この数字は、以前の公開方式より大きな改善です。同時に、全てのチャット応答へ即時に付けるには重いことも示しています。現在は処理後にまとめて証明する方式で、即時の改変防止というより、監査対象の一部を後から確かめる使い方に向きます。

技術上の範囲も限定されています。

対象は現在、Mixture of Experts構造を使うモデルです。
整数化したモデルと、毎回もっとも確率が高い候補を選ぶgreedy decodingを前提にします。
浮動小数点計算や確率的なサンプリングの出力は、そのまま一致しない場合があります。
扱える文脈は最大1024トークンで、長い会話や大きな文書には短い範囲です。
高速な実行コードとLeanで表した形式仕様が完全に一致することまでは保証していません。
証明自体は重みを隠しますが、処理時間などを使う側信号攻撃は今回の範囲外です。

したがって、「暗号証明付きAIなら全面的に信頼できる」とは読みません。どの計算を証明し、どの計算を証明していないか、証明が届くまでの時間、保管費用、確認ソフトの版を受領票へ残します。

公開重みと推論証明は競合せず、役割を分けて組み合わせられます

オープンウェイトなら、利用者は配布元から重みを取得し、ハッシュを計算し、社内の承認版として固定できます。推論証明なら、重みを配布できない提供者でも、特定の重みに結び付く応答だと示せます。二つは「公開か非公開か」の勝ち負けではありません。

PLaMo 3 Translateのようなモデルを自社サーバーへ置く場合でも、複数部署や委託先へ推論サービスとして提供すれば、利用者側には実際の重みが見えなくなります。管理者が更新を間違えたり、軽量版へ切り替えたり、量子化を変えたりする可能性があります。公開重みから作った社内サービスにも、モデル識別子、配備ハッシュ、署名、推論ログが必要です。

反対に、クラウドの閉じたモデルへ証明が付いても、データの保存場所、学習利用、外部検索、契約終了時の削除は別問題です。証明は重みと出力を結べても、入力が目的外に保存されなかったことや、個人情報が適切に処理されたことまでは自動で示しません。

組み合わせるなら、次の順番が実用的です。

配布元と契約から、使ってよいモデルと用途を決めます。
重み、コミットメント、量子化、推論エンジンを配備版へ固定します。
入力、用語集、検索資料、出力形式を仕事ごとに固定します。
重要な一件へハッシュ、署名、推論証明、変更履歴を付けます。
内容の受入試験を行い、不合格なら人または別経路へ戻します。

この順序なら、暗号技術を品質評価の代わりにせず、品質評価に「誰が実行したか」を足せます。

日本企業は、委託先とモデルルーターの間へ受領点を置きます

日本企業のAI利用は、モデル開発会社と直接契約する場合だけではありません。SaaS、システムインテグレーター、業務アプリ、クラウド市場、再販事業者を通じて利用します。一件の応答までに、画面、業務API、モデルルーター、検索基盤、推論事業者が重なることがあります。

この構成で「当社はモデルAを利用しています」とだけ契約すると、誰がどの時点で別モデルへ切り替えられるかが曖昧になります。障害時の自動代替、混雑時の縮退、費用上限、地域別の提供差、モデル廃止後の後継指定を契約へ含めます。

受領点は、最終画面だけでなく、委託の境界ごとに置きます。

境界	受領する項目	変更時の扱い
配布元から社内基盤	重み、ハッシュ、モデルカード、ライセンス	旧版を残し、同じ試験を再実行します
AI事業者から業務アプリ	モデル識別子、地域、ルーティング条件	無断代替を禁止し、代替版を通知します
業務部門から利用者	用途、入力可能情報、出力の扱い	仕事の変更時に承認を取り直します
AI出力から業務記録	入力版、出力、証明、確認者	不合格時に原本と人の手順へ戻します

国内規制や業界指針への対応でも、モデル名だけの台帳より、一件の証拠が役立ちます。監査担当者は、高価なGPUを用意して全応答を再計算するのではなく、重要な標本のモデル同一性を確認し、別に内容と情報管理を点検できます。

個人利用でも、ダウンロード元と更新の記録が効きます

個人が公開モデルを使う場合、大きな監査制度は要りません。少なくとも、公式配布ページ、モデル名、サイズ、形式、取得日、ハッシュ、利用アプリ、保存先を一枚のメモへ残します。似た名前の再配布、改変版、古い量子化を取り違えにくくなります。

スマートフォンやノートPCで翻訳するときは、最初に短い非機密文で動作を確認します。次に、自分がよく使う固有名詞、数字、否定文を入れます。契約書、健康情報、身分証、顧客情報をいきなり投入しません。アプリのネットワーク権限、履歴、バックアップ、共有先も確認します。

更新通知が来たときは、旧版をすぐ削除せず、同じ十件を新旧で翻訳します。良くなった例だけでなく、数字、敬語、固有名詞が悪化した例も残します。問題があれば旧版へ戻せるようにします。モデルの版管理は開発者だけの作業ではなく、日常の辞書や翻訳アプリを安全に更新する方法でもあります。

モデル受領票は十二欄から始められます

大規模な監査基盤がなくても、表計算やチケットで始められます。一つのモデル配備と一つの仕事を結ぶため、次の十二欄を持ちます。

欄	記録する内容
仕事	翻訳、要約、検索、生成、判定などの作業識別子
完了条件	数字、固有名詞、形式、期限、人の承認などの合格条件
モデル	正式名称、提供者、版、サイズ、配布元
重み	公開ハッシュまたは非公開モデルのコミットメント
形式	BF16、量子化、GGUF、MLXなど実際に使う形式
ライセンス	商用・非商用、売上条件、地域、期間、再配布条件
実行環境	端末、サーバー、推論エンジン、地域、外部接続
入力	原文、版、用語集、機密区分、最小化した内容
設定	システム指示、温度、greedy decoding、検索先、出力形式
証拠	ハッシュ、署名、推論証明、ログ、取得時刻
受入結果	合格、不合格、差分、確認者、人へ戻した理由
変更と終了	更新日、旧版、復旧先、削除、契約終了の処理

全てのチャットへ十二欄を手入力する必要はありません。まず、外部へ送れない文書、金額や安全に関わる翻訳、公開物、顧客へ渡す成果、規制対象の仕事から始めます。日常のアイデア出しは軽く、戻しにくい仕事ほど証拠を厚くします。

30日でモデル名だけの管理から移行します

最初の一週間は、現在使っているAIを一覧にします。画面に表示される名称だけでなく、契約プラン、APIのモデルID、ローカルのファイル名、量子化、推論アプリ、外部検索、保存先を書きます。分からない項目は推測で埋めず、提供者または管理者へ質問します。

二週目は、代表する仕事を三件選びます。日常の低リスク文書、重要な社内文書、顧客や公共へ出る文書です。それぞれについて、数字、固有名詞、否定、形式、処理時間、外部送信、人の確認を合格条件にします。同じ入力を現在のモデルと代替モデルへ通し、差分を記録します。

三週目は、証拠を自動で残します。公開モデルなら配布ファイルのハッシュ、配備設定、コンテナやアプリの版を記録します。クラウドモデルならAPIのモデルID、応答時刻、提供地域、利用量、ルーティング条件を保存します。推論証明が利用できる将来に備え、入力と出力を同じ作業識別子へ結びます。

四週目は、変更と停止を試します。上位モデルが使えない、端末がオフライン、重みが更新された、提供者がモデルを廃止した、証明が通らない、という五つの場面を作ります。小型モデル、人の翻訳、旧版、別のクラウドへ安全に戻れるかを確認します。

運用開始後は、モデル数やトークン数だけでなく、次を追います。

承認された重みまたはモデルIDで処理した重要案件の割合です。
実行環境と量子化まで再現できる配備の割合です。
出力へモデル証拠と受入結果が結び付いた割合です。
モデル差し替えや更新後に、同じ試験を終えるまでの時間です。
重要語、数字、否定、形式の不合格率です。
不合格から人または代替経路へ戻るまでの時間です。
ライセンス条件と実際の利用部署が一致しない件数です。

これらが取れれば、「有名モデルを導入した」「ローカルで動かした」という導入報告から、「承認した条件で仕事を終えた」という運用報告へ移れます。

主な参考資料

Preferred NetworksのPLaMo 3 Translate公開発表（四サイズ、53言語、オンデバイス実行、利用条件を参照）
PFN技術ブログの開発・配布形式解説（量子化、GGUF、MLX、用語集、評価方法を参照）
ITmedia AI＋のPLaMo 3 Translate報道（国内報道時点の位置づけと訂正後の利用条件を参照）
AnthropicのFlashProve研究発表（証明方式、測定値、形式検証、制約を参照）
ITmedia AI＋のFlashProve解説（国内向けの仕組みと測定値の整理を参照）
TechCrunchの推論証明報道（モデル差し替えと第三者確認の用途を参照）

次に確認するのは、モデル名ではなく一件の受領記録です

PLaMo 3 Translateの公開は、翻訳モデルをスマートフォン、ノートPC、社内サーバーへ置き、外部通信へ頼らず使える選択肢を広げました。FlashProveの研究は、重みを公開できない大規模モデルでも、応答が指定された重みから出たことを暗号学的に示す道を前へ進めました。

ただし、公開重みは安全な運用を自動で作らず、推論証明は正しい回答を自動で作りません。配布元、重み、量子化、実行環境、入力、設定、出力、証拠、受入結果、復旧を同じ仕事へ結んで初めて、AIを名前ではなく工程として扱えます。

あなたの組織で次にAIの成果を受け取るとき、確認するのは画面のモデル名だけでしょうか。それとも、その一件が承認した重みと経路で処理され、内容の合格条件を満たし、問題があれば元へ戻せるところまで受け取れるでしょうか。モデルが小さく端末へ近づき、証明が応答へ近づく今こそ、「何を使ったか」から「何を証拠付きで終えたか」へ管理を進める時です。