個人データを扱うLLM（大規模言語モデル）アプリケーションを設計・運用するエンジニアに向けた内容です。推論処理をクラウドAPIに置くか、自社環境やローカル端末に置くかという配置判断は、コストと障害対応の両面に効いてきます。
題材になるのは、チャット履歴から関係性の記憶を抽出し、対立が起きた際の返信案を提案する個人開発のツールです。Google製のオープンウェイトモデル（モデルの重みパラメータが公開され誰でもダウンロードして動かせるモデル）であるGemmaを使い、推論部分をクラウドAPIとローカル実行の両方で動かせるよう設計している点が、インフラ目線で見ると興味深い事例になっています。
何が起きているのか
このツールはWhatsApp（メッセージアプリ）のエクスポートファイルを読み込み、過去の約束や会話パターンを抽出し、そのまま使える引用付きの「記憶」としてブラウザのLocalStorage（ブラウザ内蔵の簡易データ保存領域）に保存します。
サーバー側はステートレス（状態を保持しない設計）にしてあり、個人データはユーザーのブラウザ内だけに閉じ込める方針です。推論エンジンにはGemmaファミリーのモデルが使われ、本番デモ環境ではGoogleがホストするGemma API（gemma-4-26b-a4b-it）を呼び出しています。
一方で環境変数LLM_PROVIDER=ollamaを設定すれば、Ollama（ローカルでLLMを動かすための実行基盤）経由でgemma3:4bをユーザー自身のPC上で動かせます。この場合、チャットのテキストは一切外部に送信されません。
技術的な仕組みを段階的に見る
パイプライン全体は次の流れで構成されています。
WhatsAppエクスポート(.txt)
→ ブラウザ内パーサー(双方向文字の除去等)
→ メッセージチャンク分割(直近1500件を120件ずつ)
→ Gemmaによる抽出(引用付きメモリ生成)
→ 引用検証コード(チャンク内に存在しない引用は破棄)
→ LocalStorageに保存ここで注目したいのは「引用検証コード」という工程です。LLMが生成した記憶の中に、元のチャンクに実在しない引用が含まれていたら、その記憶ごと破棄する仕組みになっています。
これはLLMのハルシネーション（事実に基づかない内容をもっともらしく生成してしまう現象）対策として、推論結果をコードで機械的に検証するパターンです。監視設計の観点で見ると、モデル出力の品質を人手レビューに頼らず、決定的なルールでフィルタする仕組みは、本番運用時の異常検知ロジックとしてそのまま流用できる考え方です。
返信案を生成する際は、キーワードの一致度・カテゴリの重み・直近性でスコアリングして関連する記憶を検索し、それをGemmaに渡して「Soft（柔らかい）」「Casual（カジュアル）」「Direct(率直)」の3パターンの返信を生成します。これはRAG（検索拡張生成、外部データを検索してからLLMに渡す手法）の軽量版と言える構成です。
クラウド推論とローカル推論、何が違うのか
この構成は、LLM搭載アプリケーションを設計する際によくぶつかる「推論をどこで実行するか」という選択を、環境変数ひとつで切り替えられるようにした例です。
クラウドAPIを使う場合のメリットは明快です。GPUインフラの調達・保守が不要で、スケールもAPI提供元に任せられます。ただし今回のケースのように、テキストチャンクがHTTPS経由でGoogleのサーバーに送信される点は、プライバシー要件が厳しい業務では見過ごせません。
オンプレミスやエッジ端末でOllamaのようなランタイムを使ってローカル推論する場合は、データが外に出ない代わりに、GPUメモリやCPU性能といったリソース制約がそのまま応答速度や精度の上限になります。gemma3:4bのような小型モデル（パラメータ数40億程度）を選んでいるのも、ノートPC程度のスペックでも動かせる現実的な落としどころを狙った結果と考えられます。
この「クラウドAPI版とセルフホスト版を同じコードベースで両立させる」設計は、オンプレからクラウドへの移行を検討する際の逆方向、つまり「クラウド前提で作ったがコンプライアンス要件でオンプレに戻す」ケースの参考にもなります。設定ファイルや環境変数でプロバイダーを切り替えられる抽象化層を最初から用意しておけば、移行時のコード改修を最小限に抑えられます。
運用コストと障害対応の視点で確認すべきこと
実際にこうした構成を自分のプロジェクトに取り入れるかどうかを判断する際は、以下の観点を確認しておくと見通しが立てやすくなります。
- 推論コストの比較: クラウドAPI課金はトークン数に比例するため、月間リクエスト数を見積もってAPI料金とGPUインスタンスの時間課金を比較する
- 障害時の切り分け: クラウドAPI障害時にローカルフォールバックへ自動切替する仕組みがあるか、単なる手動の環境変数切替に留まるかを確認する
- レイテンシ要件: ローカル推論はネットワーク往復がない分、応答は安定するが、GPUが貧弱だとクラウドより遅くなる場合がある
- データ所在地の要件: 個人情報保護法やGDPR相当の規制対象データを扱うなら、APIの送信先リージョンとログ保持ポリシーを公式ドキュメントで確認する
実際に手元で試す場合は、GitHubのリポジトリをクローンし、.envファイルにLLM_PROVIDER=ollamaを設定したうえで、事前にOllamaをインストールしてollama pull gemma3:4bでモデルを取得する流れになります。クラウド版との挙動差を比較するには、同じsamples/ios_sample.txtを両方のモードで処理し、応答時間と抽出結果の差分を記録しておくと判断材料が増えます。
障害対応の観点で見る引用検証の価値
監視設計の文脈では、LLMの出力をそのままユーザーに見せるシステムは、品質劣化が「エラー」として検知しにくいという課題を抱えています。
APIが200番台のレスポンスを返していても、中身が事実と異なる引用を含んでいれば、ログ監視だけでは異常に気づけません。引用検証コードのように、出力内容そのものをアプリケーション層で検証し、不合格なら破棄するロジックを組み込んでおくことは、LLM搭載システムにおける一種のヘルスチェック設計と言えます。
本番環境でLLMを使ったサービスを運用するなら、APIのレスポンスタイムやエラー率だけでなく、こうした「出力品質の検証失敗率」もメトリクスとして記録し、閾値を超えたらアラートを出す仕組みを検討する価値があります。
まとめ
オープンウェイトモデルを使ったアプリケーションは、クラウドAPI版とローカル実行版を環境変数の切り替えだけで両立できる設計が可能です。
自分のプロジェクトで検討する際は、以下を確認してみてください。
- 利用中のLLM APIの料金体系とセルフホスト時のGPUコストを月間リクエスト数ベースで比較する
- プロバイダー切替を環境変数で抽象化し、障害時や規制対応時に切り替えられる構成になっているか見直す
- LLM出力の品質検証(引用の実在確認など)をログ監視の一部に組み込めないか検討する
まずは手元でOllamaとgemma3:4bを動かし、クラウドAPIとの応答速度・精度の差を実測してみるところから始めてみてください。