自信満々に、静かに間違える──オンデバイスLLMの監査が見つけた『Task-Asymmetric Miscalibration』

スマートフォンに搭載されるオンデバイスAIモデルは、サーバー側のモデレーションを介さず、数億台規模のデバイスに直接配布される。開発者が実際にデプロイできる設定は、独立した第三者による監査をほとんど受けていない。この空白を埋めようとした論文が、2026年8月24日にarXivで公開された(8月26日に改訂版)。

問い:ユーザーは「モデルが間違っている」ことに気づけるか

論文の出発点はシンプルな監督(オーバーサイト)の問いだ。

"We present a reproducible reliability audit of the developer-accessible on-device foundation model, framed as an oversight question: can a user or a resource-constrained developer tell when the model is wrong?"

開発者がアクセス可能なオンデバイス基盤モデルについて、再現可能な信頼性監査を実施する。これは監督の問いとして組み立てられている——ユーザーや、リソースの限られた開発者は、モデルが間違っているときにそれを見分けられるのか。

キャリブレーション、誤った前提の質問への確信を持った作話、無害なプロンプトへの過剰拒否をレッドチーミング(意図的な攻撃的検証)した結果がこうだ。

"we find a \emph{task-asymmetric miscalibration}: its guardrails fail in opposite directions across tasks (confabulating on 69% of false premises while refusing 18% of entirely benign inputs)"

「タスク非対称なミスキャリブレーション」が見つかった。ガードレールはタスクによって正反対の方向に失敗する。誤った前提を持つ質問の69%に対してもっともらしい作話をする一方、まったく無害な入力の18%を拒否してしまう。しかも自己申告の確信度は飽和しており、判別力を持たない(AUROC 0.47、ECE 70——比較可能な小型モデルの中で最悪)という。

数字:見た目では区別がつかない

論文が示す最も重い指摘はここにある。

"confident-correct and confident-wrong outputs are \emph{surface-indistinguishable}: a classifier over 15 user-visible features separates them at AUROC only 0.55 (equivalence-confirmed), leaving no signal for oversight at inference time."

自信を持って正しい出力と、自信を持って間違った出力は「見た目上、区別がつかない」。ユーザーから見える15個の特徴量を使った分類器でも、AUROCはわずか0.55にしかならない(等価性が確認されている)。つまり、推論時点でユーザー側が監督するための手がかりが実質的に存在しない、ということだ。「誤った前提には69%作話するが、無害な入力の18%は拒否する」という2つの数字を並べて見ると、このモデルの失敗は単純に「甘い」でも「厳しすぎる」でもなく、状況によって逆方向にブレる不安定さそのものが問題であることが分かる。開発者が一方の失敗だけを見て「拒否率を下げよう」と調整すれば、もう一方の作話がさらに悪化しかねない、という難しさをこの非対称性は示している。安価な単一生成のシグナルではこれらの失敗にフラグを立てられない(AUROC 0.68以下)一方、モデルへのアクセスを必要としないブラックボックスの一貫性ラッパーを使うと、信頼性が回復するという。

"a black-box consistency wrapper requiring no model access recovers reliability (confident confabulation 75%$\to$3%; selective accuracy 43%$\to$83%) at a tunable cost."

確信を伴う作話は75%から3%へ、選択的正答率は43%から83%へと改善する。ただし、これは調整可能なコスト(おそらく追加の生成・検証コスト)とのトレードオフのもとで達成される。

確信度表示を品質管理の根拠にしない

オンデバイスAI機能(要約、通知の生成、簡易な質問応答など)を製品に組み込んでいる場合、この論文は「モデルの自己申告の確信度」に頼った品質管理が機能しない可能性を具体的な数字で示している。ユーザーがモデルの誤りに気づけないという前提に立ち、重要な判断に関わる出力については、モデル自身の確信度表示ではなく、外部からの一貫性チェックのような仕組みを別途組み込む必要がある。オンデバイスAIの基本的な仕組みはオンデバイスAIとはを、ハルシネーション全般の対策はLLMのハルシネーション(幻覚)とはを参照してほしい。

どの機種のオンデバイスモデルかは書かれていない

本記事は、当サイトが論文の要旨を読んで書いている。監査対象となった具体的なオンデバイス基盤モデルの名称(どのOS・どのメーカーのモデルか)、15個の「ユーザーから見える特徴量」の内容、ブラックボックス整合性ラッパーの具体的な実装方法は、要旨には記載がなく、本文PDF(8ページ・図5点・表2点)を読み込んでいないため確認できていない。タイトルに「Deployed(配備済み)」とあることから実際に一般提供されているモデルを指していると推測されるが、機種名の裏取りはできていない。Zenn記事検索(2026年8月27日実施)では該当する日本語記事は見つからなかった。