社内に放置された古いCSVログや監査データを、外部APIに送らずに分析したいと考えたことはないでしょうか。クラウド上のSaaS型AIサービスにデータを渡す前に、社内ネットワークだけで完結する分析基盤を検討している運用担当者やSREに向けて、ローカルLLM（手元の端末やサーバー上で動かす大規模言語モデル）を使ったデータ分析アプリの仕組みを手がかりに、監視設計とクラウド依存の見直しポイントを整理します。
題材にするのは、Hacktoberfest（毎年10月に開催されるオープンソース貢献イベント）向けに開発された「DataAfterlife」というアプリです。古い映画館の売上台帳CSV（1999〜2000年、72件のレコード）を読み込み、月次の最低売上541ユニット、最高7,199ユニット、総額62,477ユニットといった数値を自動集計し、グラフと短いストーリーとして提示します。特徴は、集計や解析処理がすべてブラウザ内で完結し、自然言語での質問応答部分だけがローカルで動くGemma 3 4B（Googleが公開する軽量オープンウェイトモデル）に委ねられている点です。
処理がどこで動いているかを分解する
このアプリの構成を監視の視点で見ると、処理が3層に分かれています。CSVの読み込みと数値計算はPapa Parse（CSV解析ライブラリ）を使い、ブラウザのWeb Worker（メイン画面をブロックせずバックグラウンドで処理を走らせる仕組み）内で実行されます。合計・平均・最大最小・月次集計といった決定的な計算はすべてここで完結し、外部に一切データが出ません。
次に、自然言語の質問を受け取る部分だけがOllama（ローカルでLLMを動かすためのランタイム）経由でGemma 3 4Bに渡ります。ここで渡されるのは質問文とカラム名だけで、生データの行そのものは送られません。モデルは「どう集計すべきか」という計算プランを提案するだけで、実際の計算はブラウザ側の決定的なコードが再度実行します。
この設計は、クラウド移行の文脈でよく出てくる「どこまでをクラウドに出し、どこを手元に残すか」という線引きの縮図です。オンプレミスからクラウドへ移行する際、よくある失敗は「とりあえず全部クラウドAPIに投げる」設計にしてしまい、後から機密データの越境問題に気づくパターンです。DataAfterlifeの構成は、計算のコア部分をローカルに残し、曖昧な自然言語理解だけを外部委託するという役割分担の参考例になります。
LLMの計算ミスをどう検知するか
開発過程で興味深い障害事例が記録されています。「合計の半分は」という質問に対し、モデルが平均値を返してしまったケース。1位と2位の集計が同じ月を指してしまったケース。そして「どの年が最大か」という質問に対し、年間合計ではなく単一レコードの最大値を返してしまったケースです。
これは典型的な根本原因分析（RCA: Root Cause Analysis）の題材です。表面的な症状は「答えが間違っている」ですが、根本原因は「時間粒度のグルーピング単位（年・四半期・月）とモデルの解釈がずれている」ことでした。対処として、アプリ側に時間粒度の不一致を検知する検証ロジックを追加し、不一致が見つかった場合はモデルに1回だけ計算プランの再提案を求める仕組みを入れています。
これは監視設計における「検知と自動復旧の分離」という考え方そのものです。本番システムの監視でも、アラートが上がった時点でまず自動リトライを1回試み、それでも解決しなければ人間にエスカレーションするパターンはよくあります。LLMをシステムの一部として組み込む場合も、出力をそのまま信用せず、決定的なコードで検証するレイヤーを挟む設計が、障害の再発防止につながることがこの事例から見えてきます。
運用コストの視点で比較する
クラウドのホスト型LLM API（OpenAIやAnthropicのAPIなど）を使う場合、コストはトークン数に応じた従量課金が基本です。1回の質問応答が数百トークン程度でも、月間のアクセス数が増えれば費用は線形に増加します。加えて、機密データを含む行をAPIに送る場合は、データ越境やログ保持ポリシーの確認も必要になります。
一方、Gemma 3 4Bのようなローカルモデルは、Ollamaでollama pull gemma3:4bを実行するだけで手元の環境に展開できます。推論コストは電力とハードウェアの減価償却に置き換わり、従量課金は発生しません。ただし、GPUメモリやCPUリソースを常時確保する必要があるため、アクセス頻度が低いシステムではクラウドAPIの方が総コストで有利になる場合もあります。
このあたりの判断は、クラウド移行でよく使われる「ワークロードの特性に応じたリフト&シフト vs リファクタリング」の議論と同じ構造です。アクセスパターンが読めない新規サービスはまずクラウドAPIで様子を見て、トラフィックが安定し規模が見えてきた段階でローカル推論基盤への切り替えを検討する、という段階的な移行が現実的な選択肢になります。
今日確認できること
自分のチームでローカルLLM導入を検討する場合、まず確認すべき項目を整理します。
- 対象データに個人情報や機密情報が含まれるか（含まれる場合はクラウドAPI送信の可否を情報セキュリティ部門に確認する）
- 質問応答の頻度とレイテンシ要件（リアルタイム性が低い用途ならローカル推論でも十分な場合が多い）
- 利用可能なGPU/CPUリソースの有無（Gemma 3 4Bクラスなら一般的なワークステーションでも動作検証が可能）
- LLMの出力を検証する決定的なロジックを別途用意できるか（できない場合はローカル・クラウド問わずリスクが残る）
DataAfterlifeのソースコードはGitHubで公開されており、Node.js 20以上とOllamaがあればgit cloneからnpm run devまでの手順でローカル動作を検証できます。自社データで同様の構成を試す際は、まずこの構成をそのまま動かし、Web Workerでの集計部分とOllama経由の質問応答部分がどこで切り替わっているかをコードレベルで確認してみると、役割分担の設計イメージが掴みやすくなります。
まとめ
ローカルLLMを使ったデータ分析の構成は、クラウド移行の判断軸をそのまま映す題材になっています。
- 決定的な計算処理とLLMの自然言語解釈を分離する設計は、監視における検知と復旧の分離と同じ考え方です
- 時間粒度の不一致のような根本原因は、表面的なアラートだけでは見えず、検証ロジックの追加が再発防止につながります
- 運用コストはアクセス頻度とデータ機密性の両軸で、クラウドAPIとローカル推論のどちらが有利かを見極める必要があります
まずは自社のデータ分析フローのうち、外部に出してよい部分と出せない部分を棚卸しすることから始めてみてはいかがでしょうか。