【ITニュース解説】My Adventures with Client-Side AI Models: Lessons from Trying Transformer.js

あるプロジェクトで、人工知能（AI）システムをユーザーのウェブブラウザ上で直接動かすという野心的な目標を掲げた開発者の経験について解説する。この目標は、ユーザーの音声やテキストデータがデバイスから一切外部に送信されないようにすることで、高度なプライバシー保護を実現するという理想に基づいていた。具体的には、話しやすいように文章を書き換えたり、リアルタイムで流暢さを分析したり、吃音（きつおん）に関するアドバイスを提供したり、対話型のロールプレイングを可能にしたりといった機能を目指していた。データがデバイスの外に出ないため、ユーザーは安心してAIの恩恵を受けられるはずだと考えていたのだ。

しかし、この理想と現実の間には大きな隔たりがあった。開発者は、ブラウザの種類による基本的な非互換性、メモリ不足によるアプリケーションのクラッシュ、利用したライブラリ内部のバグといった問題に何週間も悩まされ、最終的にはブラウザ上でのAI実行を断念せざるを得なくなった。すべてのクライアントサイドAIコードを削除し、サーバー側でAIを動かす方法に切り替えることになったのだ。

まず、開発者は「transformer.js」という、ブラウザ内でAIモデルを動かせると謳（うた）うライブラリを使って実装を始めた。ドキュメントの記載はシンプルで、サーバー不要でAIが動作するとあったため、期待は大きかった。しかし、最初の段階で早くも問題が発生した。ライブラリがAIモデルのファイルをインターネット上（Hugging Faceというサービスのサーバー）からダウンロードしようとした際、モデルのデータファイルではなく、ファイルが見つからないことを示すHTML形式の404エラーページを受け取ってしまったのだ。ライブラリはこれをモデルデータであるJSON形式として解釈しようとしたため、「構文エラー」が発生した。複数のモデルやダウンロード設定を試したが、多くの「ブラウザ対応」とされていたモデルは実際には存在しないか、ダウンロードリンクが壊れており、モデルファイルを正しくダウンロードすることさえできず、すでに2日間を費やしてしまった。

ようやく一部のモデルのダウンロードに成功しても、次の問題がすぐに現れた。それは、ブラウザの「メモリ不足」によるクラッシュだ。たった6単語程度の短い入力に対しても、「offset is out of bounds（範囲外のオフセット）」というエラーが発生し、プログラムが停止してしまったのだ。入力の最大長を制限したり、AIの応答生成に関するパラメーターを調整したりするなど、あらゆる手を尽くしたが、解決には至らなかった。これは、ブラウザがアプリケーションに割り当てられるメモリの量が厳しく制限されているためで、たとえ「小さい」とされているAIモデルであっても、ブラウザの限られたメモリには大きすぎたのだ。この問題は開発者側でどうすることもできない根本的な制約だった。

さらに、メモリクラッシュを回避できた一部のモデルでは、別の奇妙な問題に直面した。それは「トークナイザー」と呼ばれる、AIがテキストを処理するために単語や記号に分割する部分でのエラーだ。開発者は、AIに入力するプロンプト（指示文）が常に文字列であることを何度も確認し、プログラムのログでもそれが文字列であることが示されていた。しかし、ライブラリの内部で非文字列のデータがトークナイザーに渡され、「text.split is not a function（text.splitは関数ではない）」というTypeErrorが発生したのだ。これはライブラリ内部のバグであり、提供する入力が正しくても、ライブラリ自体が誤動作していることを意味していた。この段階で、ライブラリがブラウザでの利用において根本的に壊れていると判断せざるを得なかった。

こうした状況を受けて、開発者は感情分析や特徴抽出のような、よりシンプルなタスクを実行するAIモデルに切り替えることを試みた。これらのモデルは、一見すると正常にロードされたため、わずかな希望が見えた。しかし、いざこれらのモデルを実行しようとすると、やはり以前と同じ「メモリ不足」のエラーが発生し、クラッシュしてしまった。感情分析の結果を使ってスピーチセラピーのアドバイスを生成するといった代替策も検討したが、モデルが結果を返す前にクラッシュしてしまうため、何も実現できなかった。

最終的に、開発者は苦渋の決断を下し、クライアントサイドAIの利用を完全に諦め、「transformer.js」ライブラリをプロジェクトから削除した。その結果、複雑なフォールバック処理や初期化、エラーハンドリングを含んでいた350行以上あったクライアント側のAI関連コードは、シンプルで信頼性の高い「サーバー側AIへのAPI呼び出し」に置き換わった。フロントエンドのロジックも劇的に簡素化され、もはやハイブリッドなフォールバックやクラッシュ、内部ライブラリのエラーに悩まされることはなくなった。

サーバーサイドAIへの移行は驚くほどスムーズだった。PythonのFastAPIというフレームワークと、OllamaというAIライブラリを使って、わずか10分で実装が完了した。このサーバーサイドのAIは常に期待通りに動作し、クライアントサイドでの数週間にわたる苦闘が嘘のように思えた。

この経験から得られた教訓は非常に明確だ。ブラウザ上でAIを動かす技術は、まだ実運用に耐えるレベルには達していない。ブラウザの厳しいメモリ制限により、たとえ小さなAIモデルであっても簡単にクラッシュしてしまう。また、利用するライブラリの内部バグはユーザー側では修正不可能であり、モデルの入手性も不安定で、多くの「ブラウザ対応」とされるモデルは使えなかったり、ダウンロードリンクが頻繁に壊れたりしていた。さらに、エラーが発生しても原因がライブラリの深く圧縮されたコード内部にあるため、デバッグはほぼ不可能だった。一方で、サーバーサイドAIは高いパフォーマンスと安定した応答を提供し、メモリの制約もなく、保守やデバッグも格段に容易だということが明らかになった。

結論として、数週間にわたるクライアントサイドAIとの格闘の末、テキスト生成モデルは完全に失敗し、分類モデルもロードはするものの実行時にクラッシュした。それに対し、サーバーサイドAIは常に信頼性高く機能した。時には、技術と戦うのをやめることが最善のエンジニアリング判断である。このプロジェクトでは、クライアントサイドAIを諦めてサーバーサイドに移行したことで、シンプルさ、信頼性、保守性、そして一貫した高品質なAI応答を得ることができた。ユーザーのプライバシーを完全に保護する「完全プライベートなクライアントサイドAI」の夢は、現時点ではまだ夢のままだが、現実的で実用的なAIはサーバー側で確実に実現できるという結果になった。