成果発表 広瀬 エイトル 

大学 : 東京工科大学 学部2年 職種：バックエンドエンジニア 就業部署：サイバーエージェントDX トレーナー：村脇 光洋さん 自己紹介 広瀬 エイトル 

今回の成果 小売DXにおける生成AIサービスを 継続的に改善・維持していくための LLM Observability基盤を構築 

サイバーエージェントDX - AI POS 小売業界の複雑なPOSデータを、 生成AIを用いて 誰もが使える形 に 変える分析ツール 売上や傾向を、専門ツールなしで 手軽にレポートとして受け取れる 

プロダクトの問題点 - 課金体系が分散し、コストが把握しづらい - LLM周辺の不具合を簡単に追跡できない （普通のログからAIエージェントの推論を追うのは手間） - 定量的にLLMシステムを評価できないので 改善もできない。 Service A ? $
 Service B ? $
 Service C ? $
 OpenAI
 Python SDK
 128 $
 別々のモデル ・ ライブラリ 複数のマイクロサービス（Cloud Run） UX悪化とコスト増加の要因に なり得る。 

ユーザー体験が悪化した事案を想定してみる 

1. ユーザー側で想定外の生成結果 グリーンティー（15万円）と、人気の新商品スパークリング ウォーター（8万円）を比較した結果、グリーンティーの売 上が大幅に上回っています。 先月、A店で最も売れたドリンク上位2つの売上を比較して 顧客 自然 言語 モデ ル 実際の正しい比較対象は売上2位の『ブラックティー』で デタラメな回答を行っていた。 本当か...?、間違ってるな 

2. 開発者の原因追及 LLMがデータベースから取得した数値を計算し間違えたの か？ 参照したデータが古かったり、不正確だったりしたのか？ 他の店の情報と混同してしまったのか？ 呼び出すべき関数を間違えたのか？ 生成したSQLが不適切だったのか？ 記録が一連の流れとして残っていなかった結果、点在する ログを個別に追跡せざるを得ない状況に。 グリーンティー（15万円）と、人気の新商品スパークリング ウォーター（8万円）を比較した結果、グリーンティーの売上 が大幅に上回っています。 先月、A店で最も売れたドリンク上位2つの売上を比較して 顧客 自然 言語 モデ ル 実際の正しい比較対象は売上2位の『ブラックティー』で デタラメな回答を行っていた。 本当か...?、間違ってるな 

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つの売上を比較して ※ これはイメージであり、実際のプロダクトの動作と違います 

ユーザー体験を悪化させないための解決策 

ユーザー体験を悪化させないための解決策 ① LLM特化型Observability基盤の導入 AIエージェントの複雑な思考プロセスを記録・可視化する基盤を導入する。 ② 全リクエストの「トレース」取得 ユーザーの質問から最終回答までの全プロセスを追跡可能にする。 ③「定量的評価」の仕組み作り データを元にAIの品質やコストをデータに基づいて評価・改善するサイクルを構築する。 

全リクエストの「トレース」取得
 LLMのトレースだけでなく、全体のトレースを収集することで以下のメリットがある ① 該当リクエストのトレースを確認して複数サービスを横断的に視覚化 ② パフォーマンスのボトルネックの発見 → LLMが原因なのか？ データベースのクエリが原因なのか？ が明確に ③ 得られたトレースを分析することでユーザの需要特定や体験の向上に繋がる 

「定量的評価」の仕組み作り 改善 計測 分析 繰り返し 計測：
 Langfuseなどの監視基盤を導入し、本番環境で行われるすべてのリクエストに関する「品 質」「コスト」「パフォーマンス」のデータを自動的に収集 
 分析：
 開発者が正解データセットを用意して比較したり、ユーザーからのフィードバックなどを使 用してモデルやエージェント評価を行ったり、プロダクトの傾向をダッシュボードなどから確 認する。
 改善：
 Langf収集したデータから判明した事実に対して修正やアクションを行い、実施した改善が 正しかったかどうかを計測のフェーズから繰り返す。 
 感覚的な「良い/悪い」の判断から脱却し、客観的な指標に基づいた評価に 
 

やったこと。 

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

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

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

Google Cloud Traceの画面 

LLM Observability基盤「Langfuse」の導入 
 主な機能 - LLM向けのオブザーバビリティツール - トレーシングとログの収集 - 評価とモニタリング - プロンプト管理 - コスト可視化 - セッション／ユーザー単位のトレーシング - OpenTelemetryの入力に対応 

Langfuseを選択した理由。 ① OSSで開発されているプロダクト → 非Enterprise版でも十分な機能が揃っている ② セルフホストが可能。さらに必要なら企業プランも → Langfuse社が開発、保守を行っている ③ Langfuse Python SDK がある → 現在のプロダクトに軽量かつ直感的に導入できる 

Langfuse（セルフホスト）をGCP上に構築する 

Langfuseのセルフホストを選択した理由 Langfuse Cloudのリージョンが アメリカ または 欧州 に限られていた プロダクトの特性上、LLMのトレース顧客の売上データと密接しており、要件として 国外サーバーに保持したくなかった。 ほとんどのLLM Observabilityサービスは国内リージョンがなく、セルフホストができ るものに選択肢が限られる結果となった。 

実際のトレース確認画面 使用されたツールを明確に 
 出力、入力もわかりやすく 
 スパン別でコストもレイテンシー明確に 
 

ダッシュボード、アラート機能で監視を効率化 

GCPでLangfuseを構築する方法 調査したところ、主に構築ができた構成として ① GKEベース （Autopilot）x HelmChart　★ 公式推奨 ② Cloud Runベース 常時稼働の必要性と公式が推奨しているという点と、プロダクトの規模 が大きくなった際に最終的に移す必要が出てくると考えたのでGKEベース を選択しました。 

クラウドアーキテクチャ図 

陥った問題。 - Terraformわからない - Kubernetes, GKEわからない - OpenTelemetryわからない - ネットワークわからない - Langfuseもわからない 今回使用したほとんどすべての技術は初めて触ったので、 ひたすら知識を得るために勉強していました。 

苦労した点 Clickhouseをどう扱うか？ k8sの中で扱う？ Clickhouse Cloud？ Kubernetesのロードバランサーの設定 ネットワークポリシーを専用のものにするためトレース送信用の内部向けの ダッシュボードが閲覧できる社内ネットワーク向けで分けました。 現在の環境に合わせたTerraformを記述 公式からTerraformのサンプルが出ていますが、現状のAI POSにどのようにし て組み込むかなどの相談や考慮にとても苦労しました。 

このインターンで得られたもの ● Terraformを学び、実際にプロダクトに導入させる経験 ● OpenTelemetry や OpenTelemetry Collectorに対する知見 ● クラウドネイティブな構成を作る上での考え方、知識 ● サイバーエージェントで働いた時の将来像！ ● たくさんの美味しいランチと面白いお話。