ローカルAIの話は、たいてい「速い」「外に出ない」「自分のGPUで動く」で終わりがちです。今回の SemIf は、その先を少しだけ掘っています。モデルに文章をそのまま出させるのではなく、あらかじめ用意した選択肢に対して確率を返させるやり方を、ブラウザ内だけで試せるようにしたのです。しかも相手はクラウドではなく、ユーザーの端末上で動く open model です。こういう実験は地味に見えて、実は「WebGPU で何がどこまでできるのか」をかなりはっきり見せます。
SemIf は、もともと OpenJev と呼ばれていた独立研究プロジェクトで、TypeSafe とは無関係だと明記しています。ページの説明はかなり挑戦的で、「Semantic ifs from open models, in your browser.」とある通り、ブラウザの中で“意味に基づく if 文”を扱う実験です。ここでいう if は、コードの制御文そのものというより、状態と条件を入れたうえで「この選択肢のどれが妥当か」をモデルに判断させる仕組みです。
仕組みは2通りあります。ひとつは direct readout で、モデルの choice logits を読み出し、ユーザーが与えた選択肢だけに絞って softmax をかけます。つまり、A、B、C のような候補の相対的な確率を、そのまま数値として取るやり方です。もうひとつは generation で、同じ分布を JSON として文字列生成させます。モデルがトークンを一つずつ出していくので、確率を「書かせる」形になります。SemIf はこの2つを同じモデルで連続実行し、GPU 上での壁時計時間まで測ります。
デモはブラウザのみで動き、バックエンドはありません。重みは Hugging Face から取得し、ブラウザキャッシュに残ります。入力がページ外へ出ないことも明記されています。最初の読み込みは、選ぶモデルやネットワーク、GPU しだいで数分かかることがあります。デフォルトは MiniCPM5 2B で、スマホや小さな端末なら Qwen3 0.6B に切り替えるよう案内しています。デスクトップ向けには Qwen3.5 4B もあり、こちらはかなり大きいモデルです。
ページには、モデルごとのサイズと品質の目安も載っています。Qwen3 0.6B は 639 MB で、Owned が 44.0%、Perturbed が 52.8%、TypeSafe が 40.7%。MiniCPM5 2B は 1.56 GB で、それぞれ 68.6%、69.3%、63.7%。Qwen3.5 4B は 3.01 GB で、81.3%、76.6%、84.5% です。さらに Published Jev hosted は 88.3% とされ、これは公開された値です。ここでの Owned は balanced accuracy を意味し、TypeSafe は 102 行の公開サブセットでの equal-case agreement だと説明されています。量子化されたブラウザ実行では精度が変わりうるとも書かれています。
実際の画面では、たとえば「パスワード再設定は成功したのに、ログインすると account locked が返る。解除メールを2回送ったが届かない」といったサポート案件風の状態文が入り、A/B/C のどれを選ぶかを比べます。片方は logits を読んで答え、もう片方は JSON で分布を書きます。読み出しは「02A / direct readout Choice probabilities no decoding」、生成は「02B / generation JSON probabilities token by token」と分けて表示され、どちらも同じローカルモデルから出力されます。加えて、setup、model load、warmup、prompt preparation、direct execution、first generated token、generation completion がそれぞれ測定されるため、どこに時間がかかるかも見えるようになっています。
このデモで一番面白いのは、AI の出力を文章として読むのでなく、モデル内部の比較結果をそのまま使おうとしている点だと思う。ふつうのチャットUIは、モデルに「もっともらしい文」を書かせることを前提にしている。でも実務では、文章よりも「どの候補がどれだけ有力か」が欲しい場面のほうが多い。メールの振り分け、サポートのトリアージ、フォームの分岐、社内ツールの入力補助。そういう場面では、自然文を一度挟むより、選択肢の重みを直接取れたほうが扱いやすい。
ここで重要なのは、SemIf が“賢い回答を見せる”ことより、“どう取り出すか”に焦点を当てていることだ。生成ではなく readout を使えば、モデルが余計な文章を付け足す余地が減る。もちろん、元記事も書いているように、ここで出る数値は「選択肢トークンに限った softmax」であって、校正された confidence ではない。つまり、絶対的な正しさを示すわけではない。それでも、候補の相対比較としては十分役に立つ可能性がある。私は、この「絶対的な自信」ではなく「候補間の差」を見に行く方向が、地味だが実用的だと見ている。
SemIf は「入力がページを出ない」「バックエンドがない」と強調している。これを単なるプライバシー売りと受け取るのは少し浅いと思う。むしろ大きいのは、同じ環境で手元の端末からそのまま検証できることだ。サーバー越しの推論だと、遅延も料金も、実験条件も、全部が見えにくくなる。WebGPU とローカルキャッシュで動くなら、モデルを差し替えたときの違い、量子化で精度がどう揺れるか、生成と readout の時間差がどこで出るかを、かなり素直に観察できる。
しかもこのデモは、最初から「これは本番システムではない」と言っている点が誠実だ。Pinned GGUF builds through wllama、quantization may change accuracy and speed といった注意書きがあり、測定値をそのまま一般化しないよう釘を刺している。ここが大事で、ローカルAIのデモは派手に見えるほど、環境差で簡単に話が崩れる。だからこそ、どのタイミングを計測しているのか、どの重みを使っているのかを隠さない姿勢には意味がある。私は、こうした透明性こそがブラウザ実験の信用を支えると思う。
掲載されているサイズを見ると、Qwen3 0.6B の 639 MB、MiniCPM5 2B の 1.56 GB、Qwen3.5 4B の 3.01 GB という差はかなり大きい。数字だけ追えば、上位モデルほど精度が上がるのは自然だが、実際の利用者にとっては「どの端末で、どこまで待てるか」のほうが先に来る。スマホ向けに 0.6B が推奨され、デスクトップの標準が 2B、4B は高メモリ端末向けという切り分けは、かなり現実的だ。
ここで面白いのは、SemIf が“モデルを大きくすれば解決”という方向に寄っていないことだ。むしろ、同じ入力を食わせたときに readout と generation のどちらが軽いのか、どのサイズならブラウザで待てるのかを見せている。将来的に本当に価値が出るのは、巨大モデルを一発で回すことではなく、端末に応じて適切な精度と応答時間を選べることではないかと思う。2B で十分な場面は多いし、4B を載せるより、用途に応じて「軽い判断」を高速に返す設計のほうが、現場では効く。
direct readout はモデル内部に近く、理屈としてはきれいだ。ただ、製品の現場では JSON 生成のほうが接続しやすいこともある。既存の API、ログ、ワークフローは、たいてい文字列や構造化データを前提にしているからだ。SemIf が generation も並べているのは、単に比較のためではなく、モデルの判断をどの形で外に出すと扱いやすいかを考える材料になる。
私はここに、ローカルAIの今後が少し見える気がした。内部確率を直接読むやり方は速くて筋がいい。でも、そのままでは既存システムにつなぎにくい。逆に JSON にしてしまえば扱いやすいが、トークンを積み上げるぶん遅くなり、書き間違いも起きる。SemIf はその中間を実験している。つまり、モデルの思考をそのまま見せるのではなく、実務で使える形にどう変換するかを、ブラウザの中で測っているわけだ。こういう小さな実験の積み重ねが、ローカル推論を「面白いデモ」から「使える機能」に変えていくのだと思う。
