概要
GA4 + Search Console のデータを毎週月曜に自動集計し、サーバー上のOllamaで動くローカルLLM（Qwen3系 27B量子化モデル）に分析レポートを書かせて、GitLab Issue と Slack に届ける仕組みを数ヶ月運用してきました。
やってみて分かったのは、LLMの誤りには「決定的なコードで潰せる層」と「モデルの地力に依存する層」がはっきり分かれる、ということです。数値の創作は仕組みで根絶できた一方、多言語混入は対策のたびに形を変えて残り続けました。LLMを業務パイプラインに組み込むエンジニアの参考になれば幸いです。
ポイント解説
1. 「LLMに計算させない」で数値の創作を根絶
初期は「CTR 12〜15%向上」「Referral 45→80」のような根拠のない数値や、表示4回・クリック1回を「CTR 25%」と評価するn=1解釈が頻発しました。対策の方針は一言で 「計算・推定はコード、解釈だけをLLM」。前週比などは丸め前の生値からPython側で事前計算して渡し、低サンプル行に⚠️参考値フラグを付与、出力後にバリデーションをかけます。結果、直近検証では導出値がすべて手元の再計算と一致し、創作数値はゼロになりました。
2. 前処理の副産物：指標の歪みが可視化された
内部トラフィック（プレビュー環境など）の除外を過去分に遡及適用したところ、平均セッション時間の前週比が +19.6% → −10.0% に反転。社内の長時間セッションが指標を歪めていたことがデータで裏付けられ、しかもLLMはこの「悪化」を隠さず妥当な解釈を付けてきました。
3. 指示で止まらない多言語混入の変異
出力言語の乱れは根深い問題でした。簡体字混入 →（サニタイズ）→ 漢字だけの中国語表現（「及相関クエリ」「個位数」）→ 初の韓国語（「사이트에」）→ 正規カタカナの造語（「ズマス」）へと、対策のたびに検出しにくい形へ変異。正規表現やハングル検出[가-]ではもう機械的に捕まえられません。多言語学習モデルの内部で日中韓の表現が近接し、生成時に「隣」を引くのだろうと推測しています。
まとめ
- 数値の創作・無意味な統計解釈は、事前計算・フラグ・出力バリデーションという仕組みでほぼ根絶できる
- 一方、多言語混入はプロンプトの指示では止まらず、**モデルの品質限界（天井）**のサインに見える
- 集計は決定的なコードで、LLMには解釈だけを。出力検証は人間のループとして残す
無料で動く仕組みだけでどこまでやれるかにこだわった挑戦で見えた天井なので、記録する価値があると考えています。
詳細はTechblogで
アーキテクチャ全体像、NemoClawによるdeny-by-default外部通信制御、実際に混入した誤りのスクリーンショットなど、技術的な詳細は当社Techblogをご覧ください。
👉 詳細記事を読む