はじめまして。セーフィー株式会社の池淵峻一です。2025 年 3 月より AI Studio チームで、バックエンドの開発を担当しています。 Safie AI Studio は、セーフィーのカメラ映像に対して AI 解析を導入・開発できるプラットフォームです。人検知や車番認識といった映像 AI ソリューションを、35 万台以上のカメラに展開できる基盤を提供しています。私はこのプラットフォームのバックエンド——API サーバー、データベース、非同期ワークフローなどの開発に携わっています。 この記事では、MLOps 基盤を作る上で AI コーディングアシスタント Claude Code を導

「Google Cloud Next Tokyo」はGoogle Cloudが年に1回開催するイベントの日本版で、クラウド技術の最新情報や事例の紹介に加え多彩なワークショップなどを含み、今年は2025年8月5日(火)と6日(水)の2日間、東京ビッグサイトで開催されました。 本記事は8月5日のセッションでunerryの3名が登壇した「Vertex AIで実現：購買データ x 約1億IDの人流データによる次世代広告ターゲティング」を書き起こし風にレポートします。 （実際の発言から編集を加えています） ※人員数やデータ量に関する記載等、本記事に関する内容は2025年8月5日時点での内容となります。 INDEX 会社紹介 次世代広告ターゲティング 購買特性と行動特性の関係 人流 X 購買データによる購買予測モデル Vertex AI Pipelinesによる開発期間短縮とコスト削減 Vertex AI Experimentsによる可視化でビジネスサイドとの共創 まとめ 皆さん、こんにちは。unerryは、位置情報を中心とした行動ビッグデータを保有する企業です。本日は、Vertex AIを活用して広告ビジネスにおける新たな強みを確立した事例を紹介します。 まず、自己紹介をさせていただきます。私は梅田と申します。unerryでは広告ビジネスの推進を担っており、本取り組みではビジネス側の要件定義とプロジェクト推進を担いました。 後ほど登壇するデータサイエンティストは2名おり、張が機械学習モデルの開発マネジメントを、上野が主に実装を担当しました。本日はこの3名で説明いたします。 アジェンダは、最初に弊社unerryについて、次に次世代広告ターゲティングの概要、最後にVertex AIを用いたMLOpsの活用方法についてお話しします。 会社紹介 unerryは、リアル行動データプラットフォーム「Beacon Bank」を中心に事業を展開しており、国内外で4.2億IDの生活者行動ビッグデータを保有しています。このデータを解釈するAI技術を活用し、以下の3つのサービスを提供しています。 1. 特定のお店や街への来訪者を分析・可視化するサービス 2. 分析結果に基づき広告を配信し、実際の来店を検証する広告配信の仕組み 3. One to Oneのパーソナライゼーションを行うシステム開発 当社が保有する生活者行動ビッグデータの核は人流ビッグデータです。データソースは主にスマートフォンのGPSデータと小型のビーコンセンサーの2種類です。日本と北米を中心に展開し、グローバルで4.2億IDを保有しています。この人流ビッグデータには、IDで紐づく形で購買データやテレビ視聴データなど、生活者のあらゆる行動データが結びついています。 4.2億IDはグローバルでもトップクラスの規模です。unerryは、データ量が一定の閾値を超えるとモデル性能が非線形に向上するデータスケーリング則の域に達しています。世界トップクラスのユーザー数を誇るプレイヤーは、このデータを用いて独自の生成AIモデルやレコメンドシステムを開発しており、unerryも同様のデータボリュームを有しています。 次世代広告ターゲティング 今回は行動変容サービス、すなわち広告領域での事例について説明します。 普段のお買い物のうち、リアルなお店、例えばコンビニとかスーパーで買い物する時の支出のどれくらいの割合がリアルで行われるか、ご存じですか？オンラインECサイトの普及により、オンラインでの購買が増加している印象がありますが、実際には9割がリアル店舗で発生しています。もし皆さんがメーカーの販売促進の予算を決める責任者だったとしたら、リアルの施策とオンラインECの施策、どっちに投資しますか？ もちろんインパクトが大きい9割のほう、リアル施策に投資しますよね。 このような背景から、リアル世界をデータ化しているunerryには、近年メーカーからの相談が増加しています。本セッションで紹介する次世代広告ターゲティングは、このようなメーカーのニーズに応えるものです。 次にシナリオを紹介します。広告主であるメーカーは、スーパーやコンビニに陳列される商品を製造し、店頭販促の予算を保有しています。この予算を効率的に活用するため、購買見込み層をターゲットとした広告を検討しています。 この要件に対し、unerryの広告配信サービスでは現在大きく2つのアプローチを提供しています。 1つは、人流データを用いて、例えば商品が陳列されているスーパーを普段利用する層に広告を配信すること。その際に、ジムに通っているなどの行動アフィニティも組み合わせることができます。もう1つは、unerryが提携する企業が保有する購買データを用いた、類似商品を購入している層への広告配信です。例えば、メーカーが新しい健康飲料を発売した場合、unerryのサービスでは、普段から健康食品を購入している層への広告ターゲティングが可能です。 現在提供している人流ターゲットと購買ターゲットの評価について説明します。人流データは国内でMAU約1億規模であるため、配信ボリュームを確保できます。購買データは購買レベルでの消費傾向が把握できるため、予測精度を高く保つことができます。しかし、人流データと購買データをそれぞれ単独で利用する現状では、配信ボリュームの最大化と購買パフォーマンスの最大化という2つの目標を両立することが困難なのが現状です。これは、どちらか一方を優先するともう一方が犠牲になるというトレードオフの関係にあります。 ではどうすればこのトレードオフを乗り越えられるか。人流データが1億IDあるなら、2つのデータソースもそれなりに重なるはずで、組み合わせて活用したら配信ボリュームも「◯」、パフォーマンスも「◯」、という夢のようなターゲティング手法が実現できるのではないかと考えました。 次に次世代広告ターゲティングの全体像について説明します。 日本国内で約1億の人流ビッグデータがあり、ここから独自の2つのプロセスでターゲットを絞り込みます。この2つの絞り込みは僕の体験がベースで、そこから得た教訓から見出しています。 日本昔ばなしと同じように「物語から教訓を得る」という構造でお話しします。 1つ目の絞り込みの元となった体験をご説明します。 あるメーカーさんの新食感のお菓子の広告を何回か見て、だんだん興味を持ち「一度食べてみたいな」と思いました。そこで普段行っているスーパーやコンビニで探したのですが、そのお菓子はまったく置いていませんでした。皆さんも広告を見て「これ欲しいな」と思ってお店に行ったけど置いてなかったことありますよね。結局、僕はいまだにそのお菓子を食べたことがないんです。 この経験から得られる教訓は、効率的な販促のためには、まず「商品を置いているお店に普段から行っている人」にターゲットを絞るべきであるということです。これは人流データを扱うunerryであれば容易に実現できます。 2つ目の絞り込みも体験から。 ある時期、YouTubeでの動画広告やニュースサイト上のディスプレイ広告など、様々なメディアで特定の調味料の広告が頻繁に表示されました。しかし僕は普段まったく料理をしないため、その調味料を購入することはありませんでした。なんならスーパーに行っても調味料の棚にすら行っていないです。スーパーに入ったらお惣菜コーナーに直行し、レジに直行し、家に直行します。料理しないんだから当然ですよね。 皆さんも、興味のない商品の広告が結構出てくる事があると思います。 この経験から得られる教訓は、効率的な販促のためには「商品を購入する可能性が高い人」にターゲットを絞り込むべきであるということです。 このステップは、先ほどの1つ目と違って、我々は本格的に取り組んだことがない領域でした。ただ、unerryは1億のIDを保有し、そのIDごとに「行動のプロファイリング」、すなわち特徴量を持っているので、何か見いだせるんじゃないかと、ビジネスサイドの人間として夢だけ大きく膨らませました。 この無邪気な夢を、データサイエンティスト2名がGoogleのサービスを使ってスマートに実現してくれました。ここからは、実際にどう筋道を立てて走り切ったかについてお話いただきます。 購買特性と行動特性の関係 こんにちは、データサイエンティストの張です。 さっそくですが、どのようにして人流データから「商品を購入する可能性」を推測するのでしょうか？まずは人流データを多様な外部データと統合し、いろんなユーザーの特徴量を作成します。 1つの例を挙げると、人流データを日本全国254万箇所以上のPOIデータと掛け合わせて、ユーザーが来訪する場所と頻度という特徴量を作れます。スライドの例のように、この特徴量はユーザーの行動特性を反映できると考えています。 また、先ほどの行動特性は購買特性と関係があるかについて確認しました。 実際の分析の例では、ベビー用品を購入するユーザーは大型商業施設への年間来訪回数が全体平均より30％多く、一方で居酒屋への年間来訪回数が全体平均より25％少ないという結果が得られました。ベビー用品の購入者像を想像すると、非常に腑に落ちる結果ですよね。 人流 X 購買データによる購買予測モデル アーキテクチャについては、要件が4つありました。 1つ目は「数億行の大規模データに対して効率よく学習できること」です。このアーキテクチャでは2つのタワーがニューラルネットワークなので、GPUを使えば大規模の並列学習が可能です。 2つ目は「商品の説明文や画像も利用したい」ということです。このモデルでは入力はベクトルになるため、今流行りのLLMを使って画像や説明文などの非構造データもベクトルに変換して取り込むことができます。 3つ目は「新商品に対しても効率よく再学習できること」。我々のデータは大規模なので、新しい商品が追加されたりユーザーの行動情報が変化しても、モデル全体を再学習すると時間がかかりますが、このアーキテクチャでは2つのタワーが独立に学習できるため、一方を更新する際にもう一方を必ずしも更新しなくて良いという構造になっています。 最後の4つ目は「広告対象の商品に対して1億ユーザーに対しても効率よく購買スコアを計算すること」です。ユーザーベクトルを事前に用意すれば、新しい商品のベクトルに対して近傍探索をすれば、例えば1億ユーザーから一番近い200万人のIDを抽出することが簡単にできます。 そして構築した購買予測モデルを評価するために、購買スコアの上位N％と全体平均を比較します。ベビー用品の例で説明すると、まずユーザー一人ひとりの購買スコアを推定し、スコアが高い上位10％のユーザーの購買率が全体平均と比べてどれだけ差があるのかを可視化します。 その結果の一部をお見せすると、お酒とベビー用品で上位10％のユーザーはそれぞれ全体平均より36％と57％高いという結果になりました。これは広告予算を購買見込みの高い層への最適配分に非常に価値のある精度を意味しています。 ここから最後のパートでは、モデル構築で直面した課題と、Google Cloudのソリューションを用いた解決手段について、実装を担当した上野から紹介します。 上野です。よろしくお願いします。 先ほどご紹介した購買予測モデルの開発には、非常に多くの試行錯誤がありました。 データサイエンティストの皆様であれば、何度も改良サイクルを重ねてモデルの改善を繰り返すご経験があると思います。そうした改善フェーズにおいて、今回Google CloudのAI開発プラットフォームであるVertex AIが非常に大きな支えとなりました。どう駆使したかを紹介します。 解決した課題は2つあります。 1つ目は開発期間の長期化・開発コストの増大、端的に言うとスピードとコストです。改良サイクルの回数が増えたり扱うデータの規模が大きいことが要因で期間が延び、コストが増大しがちです。ただ、精度を上げるという観点では試行錯誤は不可欠で、データ規模の拡大も受け入れる必要があります。 Vertex AI Pipelinesによる開発期間短縮とコスト削減 そこで登場するのがVertex AI Pipelinesです。 Google Cloud上で機械学習パイプラインを構築・実行するサービスで、例えばBigQueryからデータを取ってきて前処理を行いモデルを学習するといった各ステップを「コンポーネント」として定義します。 なぜ Vertex AI Pipelines が開発期間とコストの課題を解決するのか。これを、並列実行・キャッシュ・コンポーネント単位のマシン選択という3つの観点から説明したいと思います。 並列実行はその名の通りコンポーネントを同時に実行できます。例えばモデル学習を複数のハイパーパラメータ条件で走らせたいとき、Vertex AI Pipelines なら簡単に並列化でき、結果として開発時間の短縮につながります。 2つ目は「キャッシュ」です。これは一度実行した結果を保存し、2回目以降の実行時は保存結果を参照することで計算を省きます。 例えばモデルのコンポーネントのコードを修正したときに、上流の前処理コンポーネントをわざわざゼロから実行し直す必要はありません。 Vertex AI Pipelines はコードの変更に影響のないコンポーネントに自動でキャッシュを適用し、開発時間の短縮とコストの最小化につながります。 最後の「コンポーネント単位のマシン選択」は、学習だけGPUを使い、前処理は汎用マシンにする、のように各コンポーネントに合ったマシンタイプを割り当てられるということです。結果として、開発期間短縮とコスト最小化を行えます。 これがアーキテクチャ図です。Vertex AI Pipelines は「機械学習基盤」の中の「学習パイプライン」で活用しています。 Vertex AI Experimentsによる可視化でビジネスサイドとの共創 次に、2つ目の課題はビジネスサイドと開発サイドの壁です。 ビジネスサイドの方をいかに巻き込むかは非常に重要で、ドメイン知識やプロジェクトの目的は改善フェーズでも必要不可欠だからです。実際にビジネスサイドの方にヒアリングすると、1番の理由は「難しそうで意見を言いにくい」。逆に言えば、分かりやすく情報を伝えられれば議論は活性化します。図や言葉などの視覚情報とともに、シンプルに伝えることが重要です。 そこで支えになるのがVertex AI Experimentsです。 実験名やハイパーパラメータ、評価指標を可視化・管理できるだけでなく、“TensorBoard”を用いることで、コード内で定義した評価グラフやモデルの説明（文章）も自動でダッシュボードに反映できます。従来のスライドやノートブックに手で転記する方法と比べて、自動反映という点で作業時間を大幅に削減できますし、管理という観点でも常に自動で最新化されます。 イメージとしては、複数の実験ケースを一元管理し、モデルの説明をMarkdownで分かりやすく記載し、画像タブで実験結果の図も登録できます。ただし可視化はあくまで手段で、目的はビジネスサイドとの共創、その先のモデル改善です。 ではこの可視化によってどんな議論が生まれ、どんな改善につながったのか。2つ紹介します。 1つ目は評価指標に関して。はじめは購買スコアの妥当性を評価するのに、スコア上位50％と下位50％の購買率の差を見ていました。しかし「広告配信をした場合の差を想定したい」「現状の案件規模感的には他のレンジでも購買率を見たい」という意見が出て、10％刻みで上位N％の購買率を全体平均と比較できるようにしました。 2つ目は学習方法について。はじめはネガティブサンプリングを行って“買った／買ってない”で学習していたのですが、売上最大化を考えると「どれだけ買ったか」も考慮したい、という議論が生まれました。そこで学習時に購買点数で損失を重み付けして学習したところ、結果的に予測精度が大幅に改善しました。 まとめ 最後にまとめです。主に2つお話ししました。 1つ目は次世代広告ターゲティング、人流データと購買データを掛け合わせることで“ボリュームと精度”という広告ターゲティングの2つの課題解決に挑んだこと。 2つ目はモデル改善フェーズにおけるVertex AIの活用。Vertex AI Pipelinesでコストとスピードを最適化し、Vertex AI Experimentsで実験条件を可視化・管理して議論を活性化し、モデル改善に大きく貢献したことです。 ご清聴ありがとうございました。 最後に宣伝です。unerryは、一緒に働く仲間を募集中です。 膨大な人流データや購買データを扱えて、多く挑戦できる魅力的な環境です。ご興味いただけた方はぜひお話しましょう！ unerryはデータサイエンティストを募集中です！ 株式会社unerry 採用ページへ The post Vertex AIで実現：購買データ x 約1億IDの人流データによる次世代広告ターゲティング / 「 Google Cloud Next Tokyo 」登壇レポート first appeared on 株式会社unerry .

.table-of-contents > li > ul { display: none; } はじめに こんにちは、データサイエンス部コーディネートサイエンスブロックの清水です。私たちのチームでは、WEARへ投稿されているコーディネート画像からVLM（Vision Language Model）で特徴を自動抽出するシステムを開発・運用しています。 プロンプト設計から推論パイプラインの構築、大規模推論まで、VLM・LLMを本番環境で活用する中、いくつかの運用課題に直面しました。本記事では、LLMOpsの全体像を整理した上で、観測基盤としてLangfuseを導入し、原因特定と改善の事例を紹介します。 目次 はじめに 目次 1. 直面した運用課題 モニタリングの不足 プロンプトとパラメーターの管理が分散 コスト管理の不透明さ 生成AIモデルのライフサイクルへの追従 2. LLMOpsの全体像とLangfuseの導入 LLMOpsとは Langfuseの選定理由 3. Langfuseの機能紹介 Tracing — モニタリングの不足を解決 Prompt Management — プロンプト管理の分散を解決 Cost Tracking — コスト管理の不透明さを解決 Tags・Session — モデルライフサイクルへの追従を支援 4. トレースによるエラー調査と改善事例 ダッシュボードによる問題の発見 ケース1：503エラー（APIの接続失敗） ケース2：Langfuseプロンプト取得のレイテンシー増加 ケース3：無限文字列の繰り返し出力 改善の全体的な効果 まとめ おわりに 1. 直面した運用課題 私たちは、小規模なデータを用いた実験や検証を経て、VLM・LLMの本番運用フェーズに移行しました。その中で、以下の4つの課題が浮かび上がりました。 モニタリングの不足 API呼び出し時のエラーや構造化出力のJSONパースエラーなど、想定されるエラーの監視が実行時のロギングのみに留まっていました。ログの粒度を細かく設定することで対処していましたが、推論対象のデータ数が増加するにつれ運用上の限界が顕在化し、生成AIの処理を体系的に記録・監視する仕組みの整備が求められていました。 プロンプトとパラメーターの管理が分散 運用中の特徴抽出プロンプトは10個を超えており、今後も増加が見込まれます。当時はプロンプトをExcel、パラメーター・configをGitHubで管理しており、バージョン管理が分散していました。プロンプト更新時にはGitHub側のパラメーター設定との整合性を都度確認する必要があり、一元的に管理する仕組みが整っていませんでした。 コスト管理の不透明さ APIの利用コストは請求画面上の合算値や日次の概算でしか把握できず、コスト急増時に原因となるリクエストや処理を特定することが困難でした。生成AIのモデルは世代ごとに料金体系が変動するため、日次推論の運用を見据えると、原因を追跡可能なコスト監視体制の構築が不可欠でした。 生成AIモデルのライフサイクルへの追従 生成AIモデルはライフサイクルが短く、迅速な更新サイクルへの追従が求められます。例えば私たちが利用しているGeminiでは、Stableモデルのリリースから概ね半年〜1年程度で提供終了を迎えるペースです 1 。モデル更新時には、データセットを用いた更新前後の精度比較やレイテンシーへの影響評価が不可欠です。 2. LLMOpsの全体像とLangfuseの導入 LLMOpsとは LLMOpsとは、大規模言語モデルの開発・運用・改善を体系的に管理するための一連のプラクティスです。従来のMLOpsがモデルの学習・デプロイ・監視を対象としているのに対し、LLMOpsではLLM特有の運用課題をカバーします。具体的には、プロンプトエンジニアリングやモデルの選択と更新、入出力のトラッキング、コスト管理などが含まれます。 IBM 2 、NVIDIA 3 、Databricks 4 、Dify 5 など各社のLLMOpsに関するドキュメントを調査しました。LLMOpsの全体像はDesign（設計）・Development（開発）・Operation（運用）の3フェーズに分類しました。特にDevelopmentフェーズではプロンプト管理や入出力のトレーシングと評価が重要です。Operationフェーズではエラー監視やコストトラッキングが中心的なプラクティスとして位置づけられています。 セクション1で挙げた4つの課題は、いずれもこのDevelopmentとOperationの領域に該当します。そこで、トレーシング・プロンプト管理・コスト監視を備えたLLMOpsツールを導入する方針としました。 Langfuseの選定理由 今回は観測基盤としてLangfuse 6 を採用しました。選定にあたってはLangSmith 7 やDify 8 を含む複数のツールを候補とし、以下の3軸で比較評価した結果、最も適していると判断しました。 セルフホスティングの可否 ：社内のインフラ要件として、GCP上に自前でホスティングできることが重要でした。Langfuseはオープンソースで、この要件に最も合致しました。 既存の技術スタックとの統合のしやすさ ：LangfuseはPython SDKを提供しています。私たちが利用しているVertex AI・LangChainなど主要フレームワークとの互換性もあり、既存のコードベースに自然に統合できました。 必要な機能の充足度 ：Langfuseはトレーシング、プロンプト管理、コスト監視をワンストップで提供しており、マルチモーダル（画像入力のトレース）にも対応していることが決め手になりました。 3. Langfuseの機能紹介 ここからは、実際にLangfuseを導入した上で活用している主要な機能を、セクション1の課題との対応とあわせて紹介します 9 。 Tracing — モニタリングの不足を解決 Langfuseのトレーシングは、1回のリクエスト処理全体を Trace として記録し、その中の個々の処理ステップを Observation としてネストする階層構造をとります 10 。 上記の画像は、私たちの特徴抽出における実際のTrace画面です。左側のObservationツリーでは、1回の推論リクエスト全体が langfuse_gemini_request_with_retry というTraceとして記録されています。その配下に以下のObservationがネストされています。 fetch_langfuse_prompt （Span）— Langfuseからプロンプトを取得 append_feedback （Span）— フィードバック情報を付与 request_to_gemini （Generation, 8.36s, 4,986→302トークン、$0.000929）— Gemini APIの呼び出し validate_gemini_response （Span）— レスポンスの検証 parse_gemini_result （Span）— 結果のパース Observationには処理の期間を記録する Span と、LLM呼び出し特有の情報を記録する Generation の2種類があります。3番目の request_to_gemini がGenerationに該当し、実行時間・トークン数・コストといったLLM固有の情報が自動的に記録されます。右側のパネルでは入出力やメタデータも一覧表示され、1画面でリクエストの全容を把握できます。 従来のロギングでは個別のAPIコールしか追えず、エラー発生時にログを手動で突き合わせる必要がありました。Traceとして構造化することで、セクション1の「モニタリングの不足」を直接的に解決しました。導入も @observe デコレータを関数に付与するだけで済み、既存コードへの変更は最小限です。 Prompt Management — プロンプト管理の分散を解決 LangfuseのPrompt Management 11 は、プロンプトのバージョン管理・デプロイをLangfuse上で完結させる仕組みです。私たちが抱えていた「プロンプトはExcel、パラメーターはGitHub」という分散管理の課題に対して、以下の機能が直接的な解決策となりました。 バージョン管理とラベル 12 ：プロンプトを更新するたびにバージョンが自動で作成され、変更履歴がイミュータブルに保持されます。各バージョンには production ・ staging などのラベルを付与でき、SDKからラベル指定で取得可能です。Diff表示機能もあり、バージョン間の差分をハイライトで確認できます。 Config 13 ：プロンプトにモデル名・temperature・top_pなどのパラメーターを付与し、プロンプトと一緒にバージョン管理できます。コードの変更・再デプロイなしに、UI上でプロンプトとパラメーターをまとめて更新できるようになり、分散管理の解消に最も効いた機能です。 Traceとのリンク 14 ：プロンプトをTraceに紐付けることで、どのバージョンがどの出力を生成したかを追跡できます。バージョンごとのレイテンシーやコストを比較でき、プロンプト改善の効果を定量的に測定可能です。 これにより、Excelとコードに分散していたプロンプトとパラメーターがLangfuse上に一元化されました。「どのバージョンが本番で動いているか」「何を変えたか」「変更の効果はどうか」を1つのツールで把握できます。 Cost Tracking — コスト管理の不透明さを解決 ダッシュボード 15 でモデルごとのコストやトークン数を時系列で可視化でき、運用時にコスト推移を一目で監視できます。セクション1で挙げた「コスト管理の不透明さ」について、従来は請求画面で合算値しか確認できませんでした。Langfuseの導入によりTrace単位・Generation単位で分解でき、異常なトークン消費の検知も容易になりました。 Tags・Session — モデルライフサイクルへの追従を支援 Langfuseでは、TraceにTags 16 やSession 17 といった属性を付与し、目的に応じてトレースデータを整理・フィルタリングできます。Tagsは任意の文字列をTraceやObservationに複数付与でき、アプリバージョン・LLM手法・実験IDなどの軸でUIやAPIからフィルタリング・グルーピングが可能です。Sessionは複数のTraceを1つのまとまりとしてグルーピングする仕組みで、 session_id を指定するだけで関連するTraceがセッション単位で集約されます。 私たちの運用では、評価実験やモデル更新のたびにTagsでTraceをグルーピングし、バージョン間の精度・レイテンシー・コストを比較しています。これにより、モデルのライフサイクルが短い環境でも、更新前後の品質を定量的に検証した上で移行でき、精度を担保した運用が可能になりました。 4. トレースによるエラー調査と改善事例 Langfuseを導入したことで、本番運用時に感じていた課題を解決できました。その中でも最も効果を実感したのはエラー調査と改善のフェーズです。ダッシュボードから問題を発見し、原因特定から改善まで行った実例を紹介します。 ダッシュボードによる問題の発見 日次での推論実行において、「早く実行が終わる日もあれば、非常に時間がかかる日もある」という現象が発生していました。実行ログからは、それぞれの推論対象となる入力データ数が大きく異なっていないことが事前に分かっていました。まずは原因を調査するためにLangfuseのダッシュボードを確認しました。 ダッシュボードで実行が完了したTrace数の推移を確認すると、最初は短時間で多くのAPIコールが成功するものの、その後に推論完了数が大幅に減少するパターンが確認できました。下図はその時に観測されたものです。 TraceやObservationを詳細に分析することで、以下の3つのケースを特定しました。 ケース1：503エラー（APIの接続失敗） 事象 ：Geminiへの初回のAPIコールが503エラーで失敗し、その後に複数回の503エラーが起こった後にようやく成功するパターンが多発していました。 対策 ：503エラーはAPI接続時のエラーであることから、API接続設定を調査しました。Vertex AIのPython SDKにはデフォルトで指数関数的バックオフ（Exponential Backoff）を利用したリトライ機構が備わっています 18 。私たちはこの仕組みを活かしつつも、システム全体が長時間ブロックされるのを防ぐため、リトライの上限回数（例：3回）やタイムアウト設定をクライアント側で適切にチューニングしました。結果として、一時的なエラーを許容しつつ、実行時のレイテンシー増加をコントロールできるようになりました。 ケース2：Langfuseプロンプト取得のレイテンシー増加 事象 ：一部のTraceで、数時間〜最大10時間も処理がブロックされているケースが発生していました。Traceの実行時間を確認したところ、API呼び出しそのものではなく、Langfuseからのプロンプト取得処理のSpanに異常な時間がかかっていることが特定できました。 対策 ：原因を調査した結果、プロンプト取得処理がリトライループの中に組み込まれていたことが判明しました。加えて、ネットワーク通信のタイムアウトが適切に設定されておらず、一時的な通信障害時に長時間プロセスがハングしていました。対策として、プロンプトの取得を最初の1回のみとし、オンメモリで保持するよう初期化処理を最適化しました。さらに、通信時のタイムアウト値を明示的に設定したことで、レイテンシーの異常な増加を根絶できました。 ケース3：無限文字列の繰り返し出力 Geminiの出力で特定の文字列が延々と繰り返され、構造化出力を想定していたJSONのパース処理で失敗してリトライが頻発しました。Trace Detail画面で出力内容がそのまま記録されていたため、無限に繰り返される文字列パターンを直接確認できました。あるTraceでは入力9,616トークンに対して出力64,999トークンという異常なトークン消費も記録されていました。 対策 ：temperatureが0の場合、出力は決定的であるため、同じ入力に対してリトライしても同一の異常出力が再現されるだけで意味がありません。根本的な原因は特定の画像データとプロンプトの組み合わせにあると考えられます。しかし、膨大なコーディネート画像すべてのエッジケースを網羅する完璧なプロンプトの追求は困難です。そこで、エラー発生ごとにtemperatureを+0.1ずつインクリメントする実装を導入しました。temperatureを上げることで出力にランダム性が加わり、リトライ時に異なる出力が生成されるため、無限繰り返しから抜け出せる可能性が高まります。また max_tokens を明示的に指定し、万が一再発した場合でも異常な出力トークン数を制限できるようにしました。 改善の全体的な効果 それぞれ対策した結果、Traceのグラフも安定し、推論のスループットが一定で保たれるようになりました。Langfuse導入以前はVertex AIのログを手動で調査する必要があり、問題の全体像を把握するのに多大な時間を要していました。導入後は以下のような改善を実感しています。 エラー調査時間の短縮 ：Trace単位で調査が完結するようになり、Trace一覧からエラーが起きていたAPI呼び出しが一目瞭然になった 入出力の精緻な監視 ：各プロンプトの入力・出力・トークン数・コストを精緻に調査でき、異常検知が容易になった リトライ戦略の最適化 ：リトライ回数や各リトライの出力がObservationとして記録され、定量的なデータに基づく改善が可能になった チーム内のコミュニケーション改善 ：TraceのURLを共有するだけで、エンジニア間のエラー議論が具体的なデータに基づいて行えるようになった まとめ 本記事では、LLMの本番運用で直面した課題と、LangfuseによるLLMOps基盤の構築、トレースを活用したエラー調査と改善の事例を紹介しました。 Geminiのモデルライフサイクルに見られるように、Stableモデルのリリースから半年〜1年程度でRetirementを迎えるケースもあります。LLM特有の運用課題に対応するためには可観測性（Observability）の基盤を整えることが重要です。Langfuseは、トレーシング・プロンプト管理・コスト監視を統合的に提供するオープンソースのLLMOpsツールとして私たちの開発環境にフィットしました。特に、Traceの構造的な記録によってエラーの特定から対策実施までのサイクルを大幅に短縮できたことが最大の成果です。 今後は、Langfuseカスタムダッシュボードの活用、評価用データセットの構築とモデル更新時の自動評価パイプラインとの連携などに取り組んでいきます。さらなるLLMの安定した運用に活かしていきたいと考えております。 おわりに ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com Model versions and lifecycle ↩ LLMOpsとは ↩ LLM の手法をマスターする: LLMOps ↩ LLMOps ↩ What is Ops in LLMOps? ↩ Langfuse Documentation ↩ LangSmith Documentation ↩ Dify Documentation ↩ Why Langfuse? ↩ Tracing Overview - Langfuse ↩ Prompt Management Overview - Langfuse ↩ Prompt Versioning - Langfuse ↩ Prompt Config - Langfuse ↩ Link Prompts to Traces - Langfuse ↩ Model Usage & Cost Tracking - Langfuse ↩ Tags - Langfuse ↩ Sessions - Langfuse ↩ Vertex AI Generative AI inference API errors ↩