AI POSにおけるLLM Observability基盤の導入 ― サイバーエージェントDXインターン成果報告

株式会社サイバーエージェントDXでのインターンで、生成AIを活用した小売DXサービス「AI POS」の開発に取り組みました。
サービス品質や運用のしやすさを高めるため、LangfuseやOpenTelemetryを使ってLLMの動きを可視化するObservability基盤を構築しました。

GCP上での実装を通じて、AIの品質評価や監視の仕組みづくりを実践した内容を紹介します。

Transcript

1. 成果発表 広瀬 エイトル
2. 大学 : 東京工科大学 学部2年 職種：バックエンドエンジニア 就業部署：サイバーエージェントDX トレーナー：村脇 光洋さん 自己紹介 広瀬 エイトル
3. 今回の成果 小売DXにおける生成AIサービスを 継続的に改善・維持していくための LLM Observability基盤を構築
4. サイバーエージェントDX - AI POS 小売業界の複雑なPOSデータを、 生成AIを用いて 誰もが使える形 に 変える分析ツール 売上や傾向を、専門ツールなしで 手軽にレポートとして受け取れる
5. プロダクトの問題点 - 課金体系が分散し、コストが把握しづらい - LLM周辺の不具合を簡単に追跡できない （普通のログからAIエージェントの推論を追うのは手間） - 定量的にLLMシステムを評価できないので 改善もできない。 Service A ? $
 Service B ? $
 Service C ? $
 OpenAI
 Python SDK
 128 $
 別々のモデル ・ ライブラリ 複数のマイクロサービス（Cloud Run） UX悪化とコスト増加の要因に なり得る。
6. ユーザー体験が悪化した事案を想定してみる
7. 1. ユーザー側で想定外の生成結果 グリーンティー（15万円）と、人気の新商品スパークリング ウォーター（8万円）を比較した結果、グリーンティーの売 上が大幅に上回っています。 先月、A店で最も売れたドリンク上位2つの売上を比較して 顧客 自然 言語 モデ ル 実際の正しい比較対象は売上2位の『ブラックティー』で デタラメな回答を行っていた。 本当か...?、間違ってるな
8. 2. 開発者の原因追及 LLMがデータベースから取得した数値を計算し間違えたの か？ 参照したデータが古かったり、不正確だったりしたのか？ 他の店の情報と混同してしまったのか？ 呼び出すべき関数を間違えたのか？ 生成したSQLが不適切だったのか？ 記録が一連の流れとして残っていなかった結果、点在する ログを個別に追跡せざるを得ない状況に。 グリーンティー（15万円）と、人気の新商品スパークリング ウォーター（8万円）を比較した結果、グリーンティーの売上 が大幅に上回っています。 先月、A店で最も売れたドリンク上位2つの売上を比較して 顧客 自然 言語 モデ ル 実際の正しい比較対象は売上2位の『ブラックティー』で デタラメな回答を行っていた。 本当か...?、間違ってるな
9. AIエージェントの行った処理の流れ（イメージ） 1. 思考: 「A店の上位2ドリンクの比較だな。まず、1位のドリンクを特定しよう」 2. ツール利用 (SQL生成) : SELECT product, SUM(sales) FROM ... WHERE store='A店' ... ORDER BY sales DESC LIMIT 1 3. 観察 : 結果が返ってくる。「1位は『グリーンティー』で売上は15万円か。」 4. 思考 :「よし、1位は分かった。次に比較する対象は…。そうだ、最近人気の新商品と比較してみよう」 ※ 「2位のドリンクを探す」という本来の目的を忘れ、全く新しい目的を勝手に設定してしまった 5. ツール利用 (別の関数呼び出し) : 「A店の新商品で最も人気なもの」を取得する get_popular_new_product() を呼び出す。 ※ 目的と関係ないツール呼び出し (´ ・ω・) 6. 観察 : 結果が返ってくる。人気の新商品は『スパークリングウォーター』で売上は8万円。 … いくつかの処理終了時に最終回答の生成 ※ 自信をもって、間違った回答を生成 ユーザの要望 : 先月、A店で最も売れたドリンク上位2つの売上を比較して ※ これはイメージであり、実際のプロダクトの動作と違います
10. ユーザー体験を悪化させないための解決策
11. ユーザー体験を悪化させないための解決策 ① LLM特化型Observability基盤の導入 AIエージェントの複雑な思考プロセスを記録・可視化する基盤を導入する。 ② 全リクエストの「トレース」取得 ユーザーの質問から最終回答までの全プロセスを追跡可能にする。 ③「定量的評価」の仕組み作り データを元にAIの品質やコストをデータに基づいて評価・改善するサイクルを構築する。
12. 全リクエストの「トレース」取得
 LLMのトレースだけでなく、全体のトレースを収集することで以下のメリットがある ① 該当リクエストのトレースを確認して複数サービスを横断的に視覚化 ② パフォーマンスのボトルネックの発見 → LLMが原因なのか？ データベースのクエリが原因なのか？ が明確に ③ 得られたトレースを分析することでユーザの需要特定や体験の向上に繋がる
13. 「定量的評価」の仕組み作り 改善 計測 分析 繰り返し 計測：
 Langfuseなどの監視基盤を導入し、本番環境で行われるすべてのリクエストに関する「品 質」「コスト」「パフォーマンス」のデータを自動的に収集 
 分析：
 開発者が正解データセットを用意して比較したり、ユーザーからのフィードバックなどを使 用してモデルやエージェント評価を行ったり、プロダクトの傾向をダッシュボードなどから確 認する。
 改善：
 Langf収集したデータから判明した事実に対して修正やアクションを行い、実施した改善が 正しかったかどうかを計測のフェーズから繰り返す。 
 感覚的な「良い/悪い」の判断から脱却し、客観的な指標に基づいた評価に 

14. やったこと。
15. OpenTelemetry の導入 • 処理の流れや依存関係を可視化できる 
 • パフォーマンスのボトルネックを特定しやすくなる 
 • trace_id などでログ・メトリクスと紐づけ可能 
 ◦ 個別ユーザー、チャットなどを指定して紐付き 
 • 他の監視ツールと統合しやすい 
 ◦ Jaeger, Prometheusなど 
 • 標準化形式で将来の拡張が容易 
 
 トラブルシュートが簡単になるけれども、運用コストは増える 

16. Otel Collector をCloudRunのサイドカーとして追加 既存するCloud Runに対して、Otel Collectorをサイドカーとして設定し、出力するログのフィルタリン グ、加工、割合などの設定が可能となりました。 
 また、元々はCLIでデプロイしていたCloud Runを YAML を使用する形式に変更しました。 

17. Google Cloud Traceの導入 - すべてのサービスはGoogle Cloud上にあるので便利 
 
 - 設定がとても簡単にできる 
 
 - Google Cloud特有サービスと連携することも可能 

18. Google Cloud Traceの画面
19. LLM Observability基盤「Langfuse」の導入 
 主な機能 - LLM向けのオブザーバビリティツール - トレーシングとログの収集 - 評価とモニタリング - プロンプト管理 - コスト可視化 - セッション／ユーザー単位のトレーシング - OpenTelemetryの入力に対応
20. Langfuseを選択した理由。 ① OSSで開発されているプロダクト → 非Enterprise版でも十分な機能が揃っている ② セルフホストが可能。さらに必要なら企業プランも → Langfuse社が開発、保守を行っている ③ Langfuse Python SDK がある → 現在のプロダクトに軽量かつ直感的に導入できる
21. Langfuse（セルフホスト）をGCP上に構築する
22. Langfuseのセルフホストを選択した理由 Langfuse Cloudのリージョンが アメリカ または 欧州 に限られていた プロダクトの特性上、LLMのトレース顧客の売上データと密接しており、要件として 国外サーバーに保持したくなかった。 ほとんどのLLM Observabilityサービスは国内リージョンがなく、セルフホストができ るものに選択肢が限られる結果となった。
23. 実際のトレース確認画面 使用されたツールを明確に 
 出力、入力もわかりやすく 
 スパン別でコストもレイテンシー明確に 

24. ダッシュボード、アラート機能で監視を効率化
25. GCPでLangfuseを構築する方法 調査したところ、主に構築ができた構成として ① GKEベース （Autopilot）x HelmChart　★ 公式推奨 ② Cloud Runベース 常時稼働の必要性と公式が推奨しているという点と、プロダクトの規模 が大きくなった際に最終的に移す必要が出てくると考えたのでGKEベース を選択しました。
26. クラウドアーキテクチャ図
27. 陥った問題。 - Terraformわからない - Kubernetes, GKEわからない - OpenTelemetryわからない - ネットワークわからない - Langfuseもわからない 今回使用したほとんどすべての技術は初めて触ったので、 ひたすら知識を得るために勉強していました。
28. 苦労した点 Clickhouseをどう扱うか？ k8sの中で扱う？ Clickhouse Cloud？ Kubernetesのロードバランサーの設定 ネットワークポリシーを専用のものにするためトレース送信用の内部向けの ダッシュボードが閲覧できる社内ネットワーク向けで分けました。 現在の環境に合わせたTerraformを記述 公式からTerraformのサンプルが出ていますが、現状のAI POSにどのようにし て組み込むかなどの相談や考慮にとても苦労しました。
29. このインターンで得られたもの • Terraformを学び、実際にプロダクトに導入させる経験 • OpenTelemetry や OpenTelemetry Collectorに対する知見 • クラウドネイティブな構成を作る上での考え方、知識 • サイバーエージェントで働いた時の将来像！ • たくさんの美味しいランチと面白いお話。