検索・タグ付け・推薦機能をクラウドから移行した理由

「AI搭載」を謳う多くのブラウザ拡張機能は、AIとはまったく無関係な処理を含め、すべてのデータをサーバーに送信しています。検索、タグ整理、「類似アイテムの検出」といった機能は、何十年も前から確立されている技術です。大規模言語モデルは不要であり、ネットワーク通信の遅延も一切必要ありません。AI Summary Helperでは機能を一つずつ見直し、「これは本当にクラウドが必要なのか、それとも設計が容易だからという理由だけで依存しているのではないか？」と検証を行いました。

その結果、ほとんどの機能においてクラウドは不要でした。

オンデバイス（ローカル）へ移行した機能

検索機能。 当初、本拡張機能は記事のタイトルとタグのみを照合していました。高速ではあるものの、本文の内容は検索できませんでした。キー入力ごとに全文を総当たりでスキャンしたり、すべてのクエリをサーバーに送信したりする代わりに、保存されたユーザー自身のアーカイブから軽量なTF-IDFインデックスを構築する手法を採用しました。タイトルやタグなどの軽量フィールドは従来通り瞬時に検証されます。長めのクエリに対しては、セッションごとに一度構築され差分更新されるインデックスを参照して検索範囲を広げます。

重複検出。 保存処理が完了する前に、階層化されたチェックが実行されます。まず正規化URLの完全一致（低コスト、O(1)）が行われ、次にそのフィルターを通過した候補に対してタイトルの類似度判定を実施します。そして、残ったわずかな候補に対してのみ、TF-IDFによるコサイン類似度の完全比較を行います。大半の保存処理は軽量な層で解決されるため、負荷の高い処理層に到達することはありません。

タグの正規化。 タグは運用に伴い表記揺れが生じがちです。「ML」「Machine Learning」「machine-learning」は人間にとっては同じ意味ですが、フィルターにとっては全く別の文字列です。軽量なエイリアステーブルで典型的な表記揺れを処理し、タグ全体の語彙に対する編集距離を用いたファジーマージで残りを補足します。この際、システムが「正解」を強制するのではなく、ユーザーが最も頻繁に使用した表記を正規形として採用します。

可読性とトーンの分析。 Flesch–Kincaidの可読性指標は、文と音節の数に基づく単純な算術処理であり、機械学習モデルは不要です。感情分析には内蔵のAFINN単語リストを使用し、直前2トークンの否定語チェックを行うだけで十分です。いずれの処理もブラウザ外にデータを送信する必要はありません。

「類似記事」およびダイジェスト機能。 これらはいずれも、検索機能向けに構築されたTF-IDFベクトルをそのまま再利用しています。3つの機能に対して個別の類似度システムを構築することも容易でしたが、単一のインデックスを構築し、検索・推薦・ダイジェスト生成のすべてがそれを参照するように設計しました。これによりシステム全体を軽量に保つことができ、インデックスを1度改善するだけで3つの機能すべてを同時に向上させることが可能になりました。

あえてクラウドに残した機能

実際の要約処理 — つまり言語モデルが真に必要となる工程 — においては、依然としてネットワーク通信が必要です。クラウドクラスのモデルと同等の出力品質を求める場合、現行のオンデバイスモデルのサイズでは限界があります。この工程では、ユーザー自身がAPIキー（OpenAI、Gemini、Mistral、DeepSeek）を設定するか、拡張機能をローカルのOllamaインスタンスに接続してネットワーク通信なしで利用することも可能です。ローカルモデルはホスト型モデルよりも処理速度や品質面でトレードオフが存在するため、オンデバイス処理はデフォルトではなく選択制としています。

単なるプライバシー対策にとどまらない理由

プライバシーの重要性は言うまでもありません。広範なホスト権限を持つ拡張機能が、不要な処理のためにページコンテンツをサーバーへ送信することは、単なる見栄えの問題ではなく信頼に関わる本質的な問題です。しかし、オンデバイス化を選択したより実務的な理由は、それがエンジニアリングとして純粋に適切な判断だからです。TF-IDF検索に200ミリ秒のネットワーク遅延は不要であり、タグの重複排除にAPI利用料をかける必要もありません。何でも安易にクラウド処理に依存するのではなく、目的に適した技術を選択することで、より高速で運用コストが低く、オフライン環境にも強いシステムが実現します。プライバシー保護のメリットは、その副産物として自然にもたらされるものです。