WebLLM: WebGPUでブラウザ内にLLM推論を閉じ込める設計と、その境界
High-performance In-browser LLM Inference Engine
ひと目でわかる
- これは何？
- WebLLMはサーバを介さずブラウザ内でLLMを動かすTypeScriptライブラリで、OpenAI API互換のインターフェースをWebGPU上に載せる。モデル配布とキャッシュの構造、そして初回ロードという避けられないコストを中心に、採用判断の材料を整理する。
- 誰に向いている？
- サーバ費用をゼロにしたい小規模なチャットUIや、入力を端末外に出したくないデモには向く。逆に、数百MBの初回ダウンロードを許容できない導線、WebGPU非対応ブラウザを切り捨てられない案件、モデル精度を最優先する用途では選ぶ理由が薄い。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 2 日前です。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
サーバを消すという選択が何を解決するのか
WebLLMが扱う問題は推論速度ではなく、推論をどこで実行するかという配置の問題である。READMEは「Everything runs inside the browser with no server support and is accelerated with WebGPU」と述べており、推論そのものをブラウザ内で完結させる。入力テキストは端末から出ない。APIキーを配る必要も、GPUインスタンスを常時確保する必要もない。
想定読者は、フロントエンドだけで完結するAI機能を組みたいTypeScript開発者だ。npmパッケージとして公開されており、UIコンポーネントに接続する前提のモジュール設計だとREADMEは説明している。サーバサイドの推論基盤を持たないチームが、チャットUIや要約機能を試作する場面が最初の接点になる。
ただしこれは万能の置き換えではない。モデルの重みは利用者のブラウザにダウンロードされる。サーバ費用は消えるが、転送量と待ち時間は利用者側に移る。この移転をどう扱うかが、採用可否のほぼ全てである。
MLCEngineとOpenAI互換レイヤーの関係
操作の入口はMLCEngineインターフェースに集約されている。READMEは「Most operations in WebLLM are invoked through the MLCEngine interface」と書き、インスタンス生成と同時にモデルをロードする流れを示している。生成側のコードはCreateMLCEngineをインポートしてエンジンを作る形になる。
このとき渡す設定が重要である。モデルの一覧はprebuiltAppConfig.model_listに定義されており、READMEはそのファイルの行まで指定して参照を促している。つまりビルド済みモデルの集合はライブラリ側の固定データであり、任意のHugging Faceモデルをそのまま指定できるわけではない。対応ファミリはLlama 3、Phi 3、Gemma-2B、Mistral-7B-v0.3、Qwen2の0.5Bから7Bまでが挙げられている。
API面はOpenAIのチャット補完と互換だと明記されている。ストリーミング、JSONモード、logitレベルの制御、シード指定が含まれる。function-callingはREADME上でWIPとされており、ここは完成していない。既存のOpenAIクライアントコードを流用できる点は移行コストを下げるが、互換をうたう範囲と未実装の範囲を分けて読む必要がある。
JSONモードがWasm側に置かれている理由
構造化出力はWebLLMの特徴の一つで、READMEは「implemented in the WebAssembly portion of the model library」と説明している。JSONスキーマに沿った生成をJavaScript側の後処理で行うのではなく、モデルライブラリのWasm層に組み込んでいる。トークン選択の段階でスキーマ制約を効かせる方が、生成後にパースし直して破綻を検出するより無駄が少ない。
ここから読み取れるのは、WebLLMが単なるWebGPUバインディングではないという点だ。MLC LLMをコンパニオンプロジェクトとして持ち、モデルのコンパイル済み形式を前提にしている。カスタムモデルを使う場合はMLC形式でコンパイルする必要があるとREADMEは述べており、量子化やスキーマ制約の実装はその形式の内側に入っている。
裏を返せば、モデルを差し替える自由度はMLCのコンパイル工程に依存する。GGUFファイルをそのまま渡す、といった使い方は想定されていない。
導入コマンドと最初に確認する設定値
インストールはパッケージマネージャ経由かCDN経由の二通りが示されている。npmならnpm install @mlc-ai/web-llm、yarnならyarn add @mlc-ai/web-llm、pnpmならpnpm install @mlc-ai/web-llmである。インポートはimport * as webllm from "@mlc-ai/web-llm"のように名前空間ごと取り込む方法と、import { CreateMLCEngine } from "@mlc-ai/web-llm"のように必要なものだけ取り込む方法が併記されている。
ビルド環境を持たない検証ではCDNが使える。import * as webllm from "https://esm.run/@mlc-ai/web-llm"、あるいはconst webllm = await import("https://esm.run/@mlc-ai/web-llm")という動的インポートの例がREADMEに載っている。jsfiddle.netやCodepen.ioで動くことが想定されている。
導入時に読むべき設定はprebuiltAppConfig.model_listである。ここに無いモデルはカスタムモデルの経路に進むしかない。加えて、計算を別スレッドに逃がすWeb WorkerとService Workerのサポート、Chrome拡張のサンプルが挙げられている。UIの応答性を保つにはWorker側でエンジンを動かす構成が前提になると考えてよい。
初回ロードという逃げられないコスト
最大の制約はモデル重みの取得である。推論がブラウザ内で完結する以上、重みは何らかの形で利用者の端末に届かなければならない。7Bクラスのモデルを選べば、その転送とキャッシュが初回体験の全てを決める。READMEはこの待ち時間を短縮する仕組みについて具体的な数値を示していない。ここは推測で埋めず、採用検討時に自前で計測すべき領域だ。
二つ目の制約はWebGPUへの依存である。READMEは「accelerated with WebGPU」と明記しており、WebGPUが使えない環境は対象外になる。フォールバックとしてCPU推論を用意する記述は与えられた資料には無い。対応ブラウザの範囲は導入前に自分で確認する必要がある。
三つ目はメモリである。モデルはブラウザのメモリ空間に載る。タブを複数開く、他の重いアプリと併用する、といった条件下での挙動は資料からは読み取れない。Web WorkerやService Workerでライフサイクルを管理する設計が用意されているのは、この問題への対処だと解釈できるが、限界値は示されていない。
MLC LLMとWebLLMをどう使い分けるか
比較対象として素直なのは、同じmlc-aiが公開しているMLC LLMである。READMEはWebLLMを「a companion project of MLC LLM」と位置づけ、MLC LLMの方を「universal deployment of LLM across hardware environments」と説明している。つまりMLC LLMはハードウェアを問わず展開する汎用の推論基盤で、WebLLMはそのうちブラウザという一環境に絞った入口である。
アプローチの違いは配布の単位にある。MLC LLMはネイティブ環境やサーバを含む広い対象を持つのに対し、WebLLMはnpmパッケージとCDNというWebの配布経路に最適化されている。OpenAI互換のAPI面を前面に出しているのもWeb側の都合だ。既存のWebアプリに組み込むならWebLLM、ブラウザ以外も含めて同じモデルを動かしたいならMLC LLM側を見る、という切り分けになる。
もう一つの現実的な選択肢は、クラウドの推論APIを呼ぶ構成である。この場合、モデルの品質とサイズを自由に選べ、初回ロードも不要になる。代わりに、入力が端末外に出ることと、リクエストごとの課金が残る。WebLLMを選ぶ判断は、この二つを引き換えにしてもよいかという問いに還元される。
ライセンスと更新の追い方
ライセンスはApache-2.0である。パッケージとして自社アプリに組み込む場合、この条件に従うことになる。ただしモデル重みそのもののライセンスは別問題で、LlamaやGemmaなどはそれぞれ独自の条件を持つ。READMEはモデルファミリの名前を挙げるだけで、重みのライセンスには触れていない。ここは法務判断の領域であり、本稿が示せるのはライブラリ本体がApache-2.0だという事実までである。
更新頻度は資料から読み取れる範囲で高い。直近のリリースはv0.2.85が2026年9月8日、その前がv0.2.83で2026年4月24日、v0.2.82が2026年3月13日となっている。パッチ番号が0.2台で進んでおり、APIが安定版に達していない段階だと分かる。マイナー更新のたびにprebuiltAppConfig.model_listの中身が変わる可能性を想定しておくべきだ。
追従コストはモデル一覧の固定に現れる。特定のモデル名に依存したコードを書くと、そのエントリが一覧から外れた時に壊れる。バージョンを固定して導入し、上げる時はmodel_listの差分を確認する運用が現実的である。
編集部の結論
サーバ費用をゼロにしたい小規模なチャットUIや、入力を端末外に出したくないデモには向く。逆に、数百MBの初回ダウンロードを許容できない導線、WebGPU非対応ブラウザを切り捨てられない案件、モデル精度を最優先する用途では選ぶ理由が薄い。導入前に、対象ブラウザでnavigator.gpuが返るか、prebuiltAppConfig.model_listに目的のモデルが載っているか、そして自社の回線でモデル取得が何秒かかるかを実測してほしい。
コミュニティノート