なぜブラウザ完結AIツールはETO製造業の現場で機能するのか——BM25と辞書エンジンの設計思想

この記事で伝えること

製造業DXのAIツール選定で、「高性能」と「現場で使われる」は別の軸にある。

私はETO（一品一様受注生産）製造業の現場で、仕様書からデビクラ（Deviation & Clarification）を抽出するブラウザ完結ツールを開発・運用している。設計で最も重視したのは「性能の最大化」ではなく、**「現場が毎日使い続けられる条件を満たすこと」**だった。

この記事では、その技術的選択の根拠を説明する。

ブラウザ完結とは何か

「ブラウザ完結」とは、すべての処理がユーザーのPC上のブラウザで実行され、外部サーバーへのデータ送信が構造的に存在しないアーキテクチャだ。

処理の流れはこうなる：

仕様書テキスト（PDFまたはExcel）
  ↓ PDF.js / SheetJS（ブラウザ内処理）
テキスト抽出・行分割
  ↓ BM25スコアリング（JavaScript）
デビクラ辞書とのマッチング
  ↓ IndexedDB（ローカル保存）
判定結果の蓄積・学習
  ↓ Excel出力（SheetJS）
抽出レポート

この処理チェーンに、外部APIコールは1つも含まれない。サーバーが存在しない。通信ログが残らない。

これを「プライバシーバイデザイン（Privacy by Design）」と呼ぶ。「外に出ない」という運用方針ではなく、「外に出る経路がない」という構造的な保証だ。

なぜLLM+RAGを採用しなかったのか

LLM+RAGのアーキテクチャは意味的な理解力が高い。それは否定しない。

しかしETO製造業の仕様書処理には、LLM+RAGが不利になる条件がいくつか重なる。

条件①：データが顧客機密である

仕様書には顧客名・設備仕様・プロセス条件・設計余裕が含まれる。これらは最重要機密だ。クラウドAPIに送信するには顧客の明示的な同意が必要になる。ETO案件ごとに同意を取得するコストは現実的ではない。

ブラウザ完結型であれば、この問題は構造的に発生しない。

条件②：ドメイン用語の習得コストが高い

「デビエーション」「クラリフィケーション」「API 610」「NACE MR0175」「E&C&LT」「所掌」「引合番号」——これらはETO製造業固有の言語だ。

汎用LLMはこれらの用語の文脈を正確に把握していない。ファインチューニングまたはRAGでのコーパス整備が必要になるが、いずれも初期コストと継続的なメンテナンスを要する。

BM25＋ドメイン辞書のアプローチは、このコストを「辞書ファイルの編集」に圧縮できる。現場エンジニアが直接メンテナンスできる形だ。

条件③：即時稼働が必要

ETO案件は案件ごとに仕様書が届く。「来週からツールが使えます」では意味がない。

ブラウザ完結ツールはURLを開いた瞬間から動く。インストール不要。アカウント不要。ChromeでもEdgeでも、会社支給PCならどれでも起動する。

BM25エンジンの実装

コアのスコアリングにはBM25（Best Match 25）を採用した。

BM25は語彙的一致ベースの情報検索アルゴリズムだ。TF-IDFを改良したもので、文書長の正規化と語彙の飽和効果を組み込んでいる。

BM25(q, d) = Σ IDF(qi) × [f(qi,d) × (k1+1)] / [f(qi,d) + k1 × (1 - b + b × |d|/avgdl)]

パラメータはk1=1.5、b=0.75で設定した。ETO仕様書の文書長分布に基づいてチューニングしている。

デビクラ辞書は現在100語以上を収録し、各語にE&C&LT（Engineering/Cost/LeadTime）の影響軸スコアを付与している。抽出結果はE影響・C影響・LT影響の3軸で分類される。

学習機能：IndexedDBへの判定蓄積

このツールの設計で最も重視した点が「使うほど精度が上がる」仕組みだ。

「対象／要確認／対象外」の判定をするたびに、その結果がブラウザのIndexedDBに保存される。「学習実行」を行うと、判定データがBM25辞書の重みに反映される。

判定データ（IndexedDB）
  → カスタム辞書への語彙追加
  → BM25重みの更新
  → 次回抽出精度の向上

この学習ループは完全にオフラインで動く。クラウドサービスへの接続が切れても、ローカルに蓄積した知識は失われない。

AIオプション：Transformers.js と WebLLM

コアのBM25エンジンに加えて、2つのAI機能をオプションで実装した。

モードA：Transformers.js（117MB）

Xenova/paraphrase-multilingual-MiniLM-L12-v2 モデルをブラウザ内で実行し、過去デビクラとのEmbeddingベース類似検索を行う。コサイン類似度0.75以上の過去事例を提示する。

初回のみ117MBのダウンロードが発生するが、2回目以降はブラウザのCacheAPIから即起動する。

モードB：WebLLM + Llama 3.2 1B（700MB）

WebGPUを使ってLlama 3.2 1BをブラウザのGPU上で実行する。過去事例がない場合にデビクラ文を自動生成する。

700MBのダウンロードと WebGPU 対応ブラウザ（Chrome/Edge 113+）が必要だが、処理はすべてローカルGPUで完結する。

精度の現実

BM25＋辞書エンジン単体での抽出精度は、熟練エンジニアの判定と比較して60〜70%程度だ。

LLM+RAGの意味的理解力には及ばない。これは設計上のトレードオフだ。

しかし「精度」だけが評価軸ではない。

データが出る経路がない → 顧客機密を扱える
起動がゼロコスト → 毎回の案件で使われる
ETO用語が最初から入っている → 初日から有効
オフライン動作 → インフラ依存がない

これらを同時に満たせるアーキテクチャとして、ブラウザ完結BM25が現時点での最適解だと判断している。

オープンソース実装

このツールの実装はすべて公開している。

技術スタック：

Astro v6（SSG）
純粋なJavaScript（フレームワークなし）
BM25アルゴリズム（自実装）
PDF.js（PDF抽出）
SheetJS xlsx（Excel読み書き）
Transformers.js / WebLLM（AIオプション）
IndexedDB（ローカル学習データ保存）

理解できるエンジニアがいれば、フォークして自社固有の辞書・プリセットに改変できる。依存先のクラウドが消えても、GitHubリポジトリにソースが残る。

まとめ

ETO製造業における仕様書処理AIツールの設計で選んだ技術的方針：

プライバシーバイデザイン — データが出る経路を設計段階で排除する
ドメイン辞書＋BM25 — 汎用LLMの代わりに現場用語を直接記述する
ゼロ起動コスト — URLを開けば動く。IT手続きを必要としない
ローカル学習ループ — 判定を積み重ねるほどツールが現場に特化する
オープン実装 — 壊れたら自分で直せる透明な構造

高性能と定着性はトレードオフになることがある。私はこのツールで「定着性」を選んだ。

ツールを試す:
仕様書リスク抽出ツール — ブラウザ完結・インストール不要・無料