会社ホームページの運用で、毎週月曜の朝にGoogle AnalyticsとSearch Consoleのデータを自動で集計し、ローカルLLMに分析レポートを書かせてSlackとGitLabに届ける、という仕組みを数ヶ月運用しています。
先に断っておくと、この記事はAIを批判するものではありません。むしろ逆で、運用の中で出てきた間違いが「なぜそうなるのか」を考えると非常に興味深く、同時に、指示の追加だけで到達できる精度には天井がありそうだ、という感触が得られてきました、という内容になります。同じようにLLMを業務パイプラインに組み込もうとしている方の参考になればと思い、仕組みと失敗と学びをまとめます。
仕組みの全体像
アーキテクチャはシンプルです。
crontabが毎週月曜9:00に発火し、git pullで最新のスクリプトを取得してからPythonスクリプトを実行します。スクリプトはGA4 APIからPV・セッション・ユーザー数・eコマースイベントを、Search Console APIから検索クエリとページ別パフォーマンスを取得します。この段階で、自社ドメインからの内部トラフィックの除外や、クリック数3未満・表示回数10未満の「低サンプル行」へのフラグ付けといった前処理も行います。
集めたデータは、サーバー上のOllamaで動くqwen3.6:27b(ローカルLLM)に渡し、分析コメント付きのレポート文を生成させます。完成したレポートはGitLabのIssueとして起票され、Slackのプロジェクトチャンネルにもサマリーが投稿されます。
外部通信の制御にはNemoClawというサンドボックス基盤を使っています。Slack APIとGoogle APIsだけを許可し、それ以外はdeny-by-defaultで遮断するネットワークポリシーの管理下でスクリプトが動く構成です。LLMエージェントに外部APIを触らせる以上、「どこに通信できるか」をコード側ではなくポリシー側で縛っておくのは安心材料になっています。
初期に起きた問題:数字の創作
運用初期のレポートで一番困ったのは、根拠のない数値が堂々と出てくることでした。
たとえば改善提案の「期待効果」として、CTR 12〜15%、コンバージョン20〜30%向上、Referralセッション45→80、といった具体的な数字が並んでいたのですが、これらはすべて何の裏付けもない創作値でした。もっともらしい数字ほどタチが悪く、知らずに読めば「そういう試算があるのか」と信じてしまいます。
統計的に無意味な解釈もありました。表示4回・クリック1回のクエリを「CTR 25%」と評価して有望キーワード扱いする、n=1の比率から結論を出すパターンです。さらに、GA4に存在しないレポート名(「取得 > テレグラム・ソース」)を引用したり、SEO施策として実行すると実害が出かねない誤った提案(英語版ページを日本語版へcanonical統合する、という英語版をインデックスから消しかねない指示)が「優先度1」で出てきたこともありました。
対策:LLMに計算させない、判断の材料は事前に作る
ここから指示とスクリプトの改修を重ねました。方針を一言でいうと「LLMに計算・推定をさせず、解釈だけをさせる」です。
前週比などの数値はすべてスクリプト側で丸め前の生値から事前計算してLLMに渡す。低サンプル行には⚠️参考値フラグを付けて「ここから結論を出すな」と明示する。根拠のない数値予測は禁止し、出力後にバリデーションチェックをかける。この改修の効果は大きく、直近の検証では前週比・CTR・導出値のすべてが手元の再計算と一致し、創作数値はゼロになりました。数字まわりは仕組みで解決できる問題だった、ということです。
副産物として面白い発見もありました。内部トラフィック(レビュー用プレビュー環境など)の除外を過去分まで遡って適用したところ、平均セッション時間の前週比が+19.6%から−10.0%へ反転したのです。社内レビューの長時間セッションが指標を大きく歪めていたことがデータで実証された瞬間で、しかもLLMはこの「悪化」を隠さず妥当な解釈を付けてきました。自動レポートの検証を続けたからこそ得られた知見です。
しぶとく残る問題:言語の混入と「新しい日本語」
一方で、指示をいくら足しても解決しきらない問題が残りました。出力言語の乱れです。
最初は中国語の混入でした。「权威性」「今週的数据显示」のような簡体字がレポートに紛れ込む。これには簡体字→日本語漢字の自動サニタイズと「日本語のみで出力」の指示で対処しました。
ところが、誤りは消えるのではなく形を変えて戻ってきます。次のレポートでは「围绕」という簡体字が再発し、その次の週には初の韓国語が登場しました。「ユーザーは 사이트에 は流入している」— 사이트에は「サイトに」の意味です。さらに「及相関クエリ」(正しくは「及び関連クエリ」)、「セッション数が個位数に留まり」(「個位数」は中国語で一桁の意)のように、正規の日本語漢字だけで書かれた中国語表現も現れました。簡体字の正規表現やハングル検出([가-])では、これはもう機械的に捕まえられません。
極めつけは造語です。あるレポートには「表示情報のズマス」という意味不明の語が出てきました。おそらく「ミスマッチ」の生成崩れですが、正規のカタカナだけで構成されているため、どんな文字種フィルタも素通りします。「スニippet」のような日本語と英語が融合した文字化けもありました。LLMが新しい日本語を作り出してくる、と社内で笑い話になったのですが、検出という観点では笑えない問題です。
見えてきた「天井」
数ヶ月の運用で見えてきたのは、誤りには「仕組みで潰せる層」と「モデルの地力に依存する層」がある、ということです。
数値の創作や統計的に無意味な解釈は、事前計算・フラグ・出力ルールという仕組みでほぼ根絶できました。しかし言語の混入は、対策するたびにより検出しにくい形へ変異していきました。簡体字→(サニタイズ)→漢字だけの中国語表現→韓国語→正規カタカナの造語。多言語で学習されたモデルの内部では日中韓の表現が近い場所にあり、生成時にわずかに「隣」を引いてしまうのだろうと想像していますが、これはプロンプトの指示で止まる種類の問題ではなさそうです。
使っているのはローカルで動く27Bの量子化モデルです。生成後にもう一度LLM自身に校正パスをかける、より大きなモデルに替える、といった対策候補はありますが、「指示を足せば直る」段階は過ぎて、モデルそのものの品質限界に触れている手応えがあります。現行モデルでの精度には、天井が見えてきた——というのが今の率直な感触です。
もちろん、商用の大規模モデルやAPIにお金をかければもっと良い結果が出るであろうことは予想しています。ただこの取り組みは、無料で使える仕組みだけでどこまでやれるかにこだわった挑戦でもあり、その制約の中で見えてきた天井だからこそ、記録する価値があると思っています。
まとめ
それでも、この仕組みは手放せません。毎週月曜の朝、人間が一切手を動かさずに、内部トラフィック除外済み・前週比計算済みのレポートがSlackに届く。数字は信頼でき、分析の着眼点も大半は妥当で、時には人間が気づいていなかった指標の歪みまで掘り当ててくれる。残る問題は「たまに変な日本語が混ざる」ことで、それは読めば分かります。
LLMをパイプラインに組み込むときの学びをまとめると:計算と集計は決定的なコードでやり、LLMには解釈だけをさせること。出力の検証を人間のループとして残すこと。そして、対策しても形を変えて残る誤りが出てきたら、それはプロンプトではなくモデルの限界のサインかもしれない、ということです。
誤りの変異の仕方そのものが、モデルの内部を垣間見るようで興味深い、そう思いながら今週も月曜9時のレポートを待っています。