こんにちは、クラウドエース株式会社 技術本部 第三開発部の宮川です。 2026 年 3 月の「Agentic AI Summit '26 Spring」開催が目前に迫っています。今回のサミットが掲げるテーマは「生成から実行（Agentic）へ」。 AI が自律的に業務を完結させる時代の到来です。 3 月のサミットの前に、改めて 2025 年 秋に開催された「AI Agent Summit ’25 Fall」の内容を振り返ってみたいと思います。AI 活用は「生成」から、自律的に行動する「エージェント（Agentic）」へと進化を遂げようとしています。このような時代だからこそ、当時の大きなテ

こんにちは、unerry CTOの伊藤です。 2025年9月、データサイエンティスト上野優人が、北海道で開催された「情報科学技術フォーラム（FIT）」において、 「位置情報データと購買データを活用した広告セグメントの開発」 に関する発表を行いました。 今回の発表は8月の「Google Cloud Next Tokyo」での登壇に続くもので、最先端技術の実装に新卒のエンジニアが挑んだ記録でもあります。 講演内容の核心となる技術、そして若きデータサイエンティストとしての挑戦の舞台裏について、上野に話を聞きました。 登場人物 株式会社unerry テクノロジー＆オペレーション部 データサイエンス&AIチーム 上野 優人（うえの ゆうと） 入社日： 2025年4月 最近の推し： 令和ロマン 筑波大学を卒業後、上智大学大学院 応用データサイエンス学位プログラムを修了。大学院では、「価格・需要変動下における、利益最大化のための販売戦略」に関する研究を行った。在学中より、unerryでの長期インターンを経験し、保有するデータと働く人に魅力を感じて新卒入社。現在は、位置情報・購買データを用いたロジック開発および改善に取り組んでいる。 ＜聞き手＞株式会社unerry CTO 伊藤 清香（いとう さやか） 入社日： 2018年2月 最近の推し： ピェンロー鍋 ガラケーからスマホまで20年以上モバイルWebシステムを開発し、高負荷対策をノリと勘で支えた縁の下の力持ち。人生の節目にあたり、これからはIoTで人々の生活を便利にしようと考えて、当時10人位だったunerryへJoin。会社の成長とともに湯水のように湧き出る課題を解決し、働きやすい職場環境を作ることを生きがいとしている。趣味はサッカー観戦と音声制御技術。 第1章：推薦システムを革新する「Two-Tower モデル」の技術的深掘り 伊藤： 今回の講演の核となった技術について、詳しく教えてください。 上野： はい、講演では、一言でいうと 位置情報データと購買データ を掛け合わせた次世代ターゲティングモデルについてお話ししました。このモデルは、ユーザーが過去にどこで行動したかという情報（位置情報データ）を、どの商品を買ったかという情報（購買データ）と組み合わせることで、より高精度な広告セグメントの構築を実現するものです。 この推論モデルは、unerryの梅田と張が共同で発明した特許（番号：特許7641682）を実装したものです。(*1) そして、その技術的な中核を担っているのが 「Two-Towerモデル」 というアーキテクチャです。これは、大規模ユーザーに対して高速に推論できるという利点から、YouTubeなど大手テック企業で採用されている先進的なアルゴリズムです。 伊藤： その「Two-Towerモデル」が従来の推薦システムと比較して画期的なのはどのような点でしょうか？ 上野： 主に、従来のシステムが抱える大きな課題を解決できる2点にあります。 1. 新商品に対する推薦が可能： 一般的に、小売企業が持つPOSデータだけを使った推薦システムでは、新商品を販売する際、購買データが全くないため、誰に推薦したらよいか分かりません。しかし、Two-Tower モデルは、商品の特徴量（価格、カテゴリなど）から生成したベクトルで推薦を行うため、データがない新商品でも適切なユーザーに推薦できます。 2. 購買履歴がないユーザーにも推薦が可能： リテール（小売）の購買データがないユーザー、つまりそのお店で買ったことがないユーザーは、従来のシステムではターゲティングできませんでした。しかし、当社は位置情報データを持っています。位置情報データから抽出・推定したユーザーの行動DNA（unerry独自の指標：普段の行動傾向を示す）や性別・年代といった特徴量があれば、購買履歴がないユーザーに対しても、「この商品を買いそうだ」という可能性を予測できます。 伊藤： その高速な処理を実現するアーキテクチャについて、具体的に解説いただけますか？ 上野： Two-Tower モデルは、名前の通り、 ユーザーの特徴量と商品の特徴量という2つのタワー で構成されています。 ユーザーの性別や年代といった特徴量、そして商品の価格やカテゴリといった特徴量を、それぞれ深層学習（DNN）で処理することで、意味のある 「ベクトル」 （埋め込み表現、エンベディング）を生成します。 推薦のスコアは、この 「ユーザーベクトル」と「商品ベクトル」の内積 で算出されます。内積が大きいほど、ユーザーがその商品に興味を持っていると判断できます。 高速化の肝は、 オフラインとオンラインの処理を分けている点 です。 ●オフライン処理： 商品のベクトルは頻繁に変わらないため、事前に計算し、データベースに保存しておきます。 ●オンライン処理： ユーザーのベクトルだけをリアルタイムで計算し、保存しておいた商品ベクトルと照合（近似最近傍探索）することで、瞬時に推薦結果を出すことができます。 YouTubeなどのテック系企業で採用されているのも、この「大規模ユーザーに対して瞬時に結果を出せる」というスケーラビリティと速度が最大の要因です。ちなみに、今回採用したベクトルの次元数は128次元で、一般的なシステムで使われる700次元や1000次元と比較しても、 軽量でリーズナブルな計算資源 で済むという利点もあります。 第2章：実装を阻む壁と300回超のトライ＆エラー 伊藤： この最先端の技術を実装する過程で、特に大変だったのはどのようなことでしょうか？ 上野： 非常に多岐にわたりましたが、最大の困難は 「実装の難しさ」 でした。Two-Tower モデルは概念はシンプルですが、適切なベクトルを生成するための深層学習レイヤーの学習が非常にデリケートで難しいと言われています。実際に手を動かすと、なかなか期待通りの精度が出ませんでした。 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ＜補足＞ Two-Towerモデルについて： Google の YouTube 推薦アルゴリズムなど、大手テック企業で採用されており、大規模ユーザーに対して高速に推論できるという点で革新的。ただし扱いが難しくまだ広く浸透していない。 参考動画 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 私のログを確認したところ、モデルの試行回数は300回以上に及びました。最初はもちろん、コードの書き間違い（コーディングミス）も多くありましたが、その後は主に「ベクトルの精度をどう上げるか」という試行錯誤の連続でした。 伊藤： ベクトルの精度向上は、具体的にどのように進めたのでしょうか？ 上野： 精度を上げるためには、モデルに「正解」を教えて学習させる必要があります。私たちは、ユーザーIDに位置情報データの行動パターンから推定した属性を特徴量（性別、年代など）とし、実際の「購買データ」と紐づけました。「このユーザーがこの商品を買った」というデータには「1」（正解）を、「買ってない」というデータには「0」（不正解）を与えます。 そして、モデルが算出した内積スコアが、この正解（1か0）に近づくように、深層学習レイヤーを学習させていくんです。適当なベクトルだと意味のないスコアが出てしまうので、「ここは1ですよ」という正解を与えることで、ベクトルの精度を上げていきました。 伊藤： 講演の登壇準備と、このモデル開発を同時並行で進めるのは、相当な負荷だったと想像します。 上野： おっしゃる通りです。登壇の締め切りに追われる中で、コードを大量に書き、試行錯誤を繰り返す日々でした。しかし、その結果として、 YouTube や他のビッグテック企業が採用しているのと「同じレベルの技術」を、当社のビジネスに組み込むことができたのは、大きな達成感 でした。まさに「困難を乗り越えたからこそ、価値がある」と実感しています。 第3章：学会の独特な雰囲気と、2度の国際的な登壇経験 伊藤： 会場の雰囲気はいかがでしたか？ 上野： 学会の雰囲気は、一般の技術カンファレンスとは異なり、独特の緊張感がありました。リアル会場には20名程度の参加者がいたかと思います。 伊藤： 質問はありましたか？ 上野： はい、お一人の方から質問をいただきました。登壇内容というよりは、当社の事業領域である「人事領域のAI活用」に関する相談でした。これは、技術広報と採用という今回の登壇目的にも合致しており、意義のある交流となりました。 伊藤： 実は、このFITを含めて、上野さんは短期間で連続して登壇されていると聞きました。 上野： はい、プライベートも含めると5ヶ月で4回となります。 ① 5月：日本経営工学会（国内学会） 卒業後に参加。大学院での研究テーマ（中古スマートフォンの販売先最適化）を発表。 ② 7月：ICPR（国際会議、コロンビア） 指導教員の計らいで、単身コロンビアへ渡航。経営工学に関する研究を発表しました。治安や言語の面で非常にタフな環境でしたが、貴重な経験でした。 ③ 8月：Google Cloud Next Tokyo（国内）クラウド技術大規模カンファレンス ④ 9月：FIT（今回の登壇） 伊藤： コロンビアでの単身登壇は驚きです。短い準備期間での挑戦も大変だったと思いますが、何かエピソードはありますか？ 上野： FIT登壇の準備期間は1週間ほどしかありませんでした。特に大変だったエピソードとして、飛行機の機内で発表練習をしていたことがあります。 飛行機が遅延し、時間ができたため、PDF資料を読み込みながら、頭の中でプレゼンを再生し、タイマーで時間を計るというスタイルで練習を続けていました。ブツブツと声に出すことはしませんでしたが、頭の中ではひたすら時間を調整していました。 また、登壇全体を通して、先輩から非常に手厚いフィードバックをいただきました。 ●「短い言葉で言い切ること」 ●「初見の専門用語をいきなり使ってしまうと、聴衆がついていけなくなる」 といった、スライド作成術から話し方まで、実戦を通じて学ぶことができました。特にGoogle Cloud Nextの際は、他の登壇者との兼ね合いで持ち時間が短くなるという裏事情もありましたが、学んだ技術を活かし、説明の核を外さずにコンパクトにまとめることができたと思います。 第4章：未来の仲間へ。「交流」の場としての学会の価値 伊藤： 学会全体を通して、上野さんが最も重要だと感じたことは何でしょうか。 上野： それはやはり 「交流」 です。 発表者側としては、質問を1人からしか得られなかった反省から、いかに相手に興味を持ってもらえる発表をするかという難しさを痛感しました。一方で、聴衆側として、自社のビジネスに関連のあるセッションには積極的に質問しに行きました。例えば、 自然災害時に避難場所を教えるチャットボット に関する研究は、当社のビジネスとも関連しそうで、非常に興味深く、質問を通して発表者の方と有益な関わりを持つことができました。 学会は、最新の技術動向を知るだけでなく、普段関わることのない研究者や学生とコネクションを作り、自分では気づかなかった新しい観点での気づきを得られる場です。 伊藤： 最後に、同じようにデータサイエンスを深く突き詰めたい学生、そして未来の仲間たちにメッセージをお願いします。 上野： 私は大学院で数理最適化を学び、その専門性が現在のデータサイエンスの仕事にダイレクトに活きています。入社後わずか数ヶ月で、世界的にも先進的な技術であるTwo-Tower モデルの実装に挑戦し、それをビジネスに組み込むという経験ができました。 「学んできたことを、社会の現場で直線的に活かしたい」、「困難な技術に果敢に挑戦し、その成果を世の中に羽ばたかせたい」という熱意 を持った方にとって、unerryは非常に恵まれた環境です。 私たちと共に、最先端のデータサイエンスを深掘りし、世の中を動かす技術を生み出していく仲間になりませんか？ *1 Google Cloud Next Tokyo ‘25の登壇記事もありますので参照ください。 Vertex AIで実現：購買データ x 約1億IDの人流データによる次世代広告ターゲティング / 「 Google Cloud Next Tokyo 」登壇レポート https://www.unerry.co.jp/blog/google-cloud-next... 「Google Cloud Next Tokyo」はGoogle Cloudが年に1回開催するイベントの日本版で、クラウド技術の最新情報や事例の紹介に加え多彩なワークショップなどを含み、今年は2025年8月5日(火)と6日(水)の2日間、東京ビッグサイトで開催されました。 本記事は8月5... unerryでは、行動データの可能性を共に切り拓くデータサイエンティストやエンジニアを募集しています。挑戦できる環境で価値創造に取り組みたい方は、ぜひお問い合わせください。 株式会社unerry 採用ページへ The post 300回超の試行錯誤を経て新卒データサイエンティストが開発に挑む「人流×購買データによる広告ターゲティング手法」 first appeared on 株式会社unerry .

.table-of-contents > li > ul > li > ul { display: none; } はじめに こんにちは、データサイエンス部コーディネートサイエンスブロックの 大川 です。私たちは、WEARにおける「似合う」をユーザーに届けるため、LLMやマルチモーダルAIを活用してコーディネートの特徴抽出や似合うに関する独自の判定処理のR&Dを行っています。 LLMが台頭して以降、LLMに構造化出力を要求するタスクは増えています。数百件のテストでは問題なく動いていたシステムが、本番運用で10万件・100万件規模の推論を回すと思わぬエラーに直面することがあります。 本記事では、ファッション画像から柄の特徴を抽出するタスクを本番運用する過程で直面した課題と、その解決策を共有します。具体的には、エラー内容をプロンプトにフィードバックしてリトライする手法により、87％のエラー削減を達成しました。この手法はLLMの構造化出力タスク全般に応用可能です。 目次 はじめに 目次 サマリー 前提条件 発生した問題 問題1: 不正な出力（68件） 問題2: トークンが繰り返される出力（9件） 原因分析 原因1: 不正な出力 原因2: トークンが繰り返される出力 解決策 解決策1: バリデーション＆リトライの追加 解決策2: プロンプトへのエラーフィードバック追加 ValueErrorの場合 JSONDecodeErrorの場合 GoogleAPIError（APIエラー）の場合 結果 エラー削減効果 性能への影響 まとめ おわりに サマリー LLMの構造化出力で発生する「不正な値の出力」と「トークン繰り返し」問題に対し、バリデーション＋エラーフィードバックプロンプトで87％のエラー削減を達成（68件→9件） エラー内容だけでなく、リトライ回数とtemperatureもフィードバックに含めると効果が大きい（21件→9件） F1スコアへの影響は約0.02の低下にとどまり、安心して導入できる 前提条件 前提条件を揃えるため、タスク内容とLLMの仕様を共有します。 項目 内容 タスク ファッション画像から複数の柄の特徴を抽出するタスク（マルチラベル分類） 推論規模 約10万件の全身コーディネート画像 使用モデル gemini-2.5-flash-lite 出力形式 JSON（許可された値のリストから選択） リトライ 最大3回 構造化出力では、柄の種類（ pattern_type ）などの特徴に対して、事前定義された値のみを出力するようLLMに指示しています。例えば、ニュアンス柄（ nuance_pattern ）やグレンチェック柄（ glen_check_pattern ）などが定義済みの値です。この制約の実装にはGemini APIの response_schema パラメータを利用しています 1 。 ただし、 response_schema はJSONの 構文的な正しさ（型やフィールド名）は保証しますが、値の意味的な正しさは保証しません 。公式ドキュメントでも「最終的な出力は、使用する前に必ずアプリケーションコードで検証してください」と明記されています 2 。この仕様上の限界が、後述する「不正な出力」問題の背景にあります。 LLMにより画像から抽出されたpattern_typeのマルチラベル分類例 発生した問題 約10万件の画像を推論したところ、以下の2つの問題が発生しました。 問題1: 不正な出力（68件） 定義外の値が出力されるケースです。例えば pattern_type に対して、 logo 、 patchwork_pattern 、 graphic_pattern のような、あらかじめ指定したリストに含まれない値が返ってきました。 不正な値 件数 logo 26 patchwork_pattern 17 graphic_pattern 14 camouflage_pattern 6 その他 5 これらの不正な値は、いずれもファッション領域では実在する概念です。LLMが持つ一般知識から「もっともらしい値」を生成してしまったと考えられます。 問題2: トークンが繰り返される出力（9件） 同じトークンが無限に繰り返され、JSONパースに失敗するケースです。Gemini API公式ドキュメントでも「トークンの繰り返しに関する問題」として同様の事象が取り上げられています 3 。 実際のトークン繰り返しエラーのログ（Langfuse） この問題が厄介なのは、JSONパースエラーでリトライしても同様の事象が繰り返される点です。その結果、以下の影響が生じます。 出力が得られない : 3回リトライしても正常な結果を取得できない レイテンシーの悪化 : 1件あたり10分程度かかるケースも発生 コストの増加 : 無駄なトークンを大量に消費する この問題をスケールで考えると深刻さが分かります。10万件中9件の発生率（0.009％）は一見小さく見えますが、本番の全件推論で400万件を処理する場合、約360件でこの問題が発生する計算です。1件あたり10分の遅延とすると、トークン繰り返し問題だけで 約60時間（2.5日分）の遅延 が発生します。 原因分析 原因1: 不正な出力 不正な出力の原因は、出力値のバリデーションとリトライの仕組みが不十分だったことです。前述のとおり、Geminiの response_schema はJSONの構文を制約するものであり、enum値の完全な制約までは保証しません。従来の実装ではこれを検知してリトライする機能がなく、不正な出力がそのまま通過していました。 原因2: トークンが繰り返される出力 この問題の背景には、 再現性とトークン繰り返しのトレードオフ があります。分類タスクでは temperature=0 で出力を安定させたい一方、それがトークン繰り返し問題を引き起こします。実際、Gemini API公式のトラブルシューティングガイドでも、temperatureを低く設定すると「ループや性能劣化などの予期しない動作を引き起こす可能性がある」と警告されています 4 。 技術的には、 temperature=0 の貪欲デコーディングにより、特定の入力に対して同じ出力トークンが延々と選ばれ、適切にEOSトークンで終了できない状態に陥ります。この問題に対処するため、リトライ時にtemperatureを0.1ずつ増やす施策を導入していましたが、それだけでは完全には回避できませんでした。 解決策 2つのアプローチを組み合わせて改善を図りました。 解決策1: バリデーション＆リトライの追加 不正な値が出力された際に、許可された値のリストと照合してバリデーションし、失敗時はリトライする機能を追加しました。 解決策2: プロンプトへのエラーフィードバック追加 単にリトライするのではなく、前回のエラー内容をプロンプトの末尾にフィードバックして再試行させることでLLMの注意を問題点に向けさせました。このとき、エラーの種類によってフィードバック内容を変えるように設計しました。 ValueErrorの場合 ValueErrorの場合、問題1（不正な出力）の発生が予想されます。どの値が不正で、どの値が許可されているかをエラーメッセージとしてそのままフィードバックするようにしました。 前回の推論で以下のようなエラーが発生しましたので注意してください。 ** 前回のConfig・エラー情報 ** - 試行: {N} 回目 - temperature: {current_temp} - 前回エラー: ValueError: invalid result for feature=pattern_type: 'logo' (allowed: ['ethnic_pattern', 'geometric_pattern', ...]) JSONDecodeErrorの場合 JSONDecodeErrorの場合、トークンが繰り返されている可能性が高いと判断し、通常のプロンプトの末尾に以下のフィードバックを追加しました。この問題は公式ドキュメントでも言及されており、「同じことを繰り返さないでください」という指示を追記することが推奨されています 5 。 前回の推論で以下のようなエラーが発生しましたので注意してください。 ** 前回の Config・エラー情報 ** - 試行: {N} 回目 - temperature: {current_temp} - 前回エラー: JSONDecodeError: ... 無限にトークンが繰り返される問題が発生している可能性があります。**同じことを繰り返さないでください。** GoogleAPIError（APIエラー）の場合 GoogleAPIError（APIエラー）の場合、レート制限やネットワークエラーが主な原因となるため、プロンプトを改善しても解決しません。この場合はフィードバックを追加せず、指数バックオフによるリトライのみとしました。 結果 エラー削減効果 解決策の効果を検証するため、不正な出力を起こした68件を評価データとして用い、施策前後での改善度合いを比較しました。なお、トークンが繰り返される問題については、エラーの再現ができなかったため今回は評価データから除外しています。 3つの条件を用意して比較実験を行いました。 解決策1: バリデーションのみを追加 解決策2-1: バリデーションとエラーフィードバック（エラー内容のみ） 前回の推論で以下のようなエラーが発生しましたので注意してください。 - 前回エラー: ValueError: invalid result for feature=pattern_type: 'logo' (allowed: ['ethnic_pattern', 'geometric_pattern', ...]) 解決策2-2: バリデーションとエラーフィードバック（エラー内容 + リトライ数 + temperature） 前回の推論で以下のようなエラーが発生しましたので注意してください。 ** 前回のConfig・エラー情報 ** - 試行: {N} 回目 - temperature: {current_temp} - 前回エラー: ValueError: invalid result for feature=pattern_type: 'logo' (allowed: ['ethnic_pattern', 'geometric_pattern', ...]) 施策 バリデーションの有無 エラーFBの有無 エラー件数 削減率 ベースライン ✗ ✗ 68件 — 解決策1 ✓ ✗ 40件 41％ 解決策2-1 ✓ ✓ 21件 69％ 解決策2-2 ✓ ✓ 9件 87％ 実験結果として、 87％のエラー削減 （68件 → 9件）を達成しました。 重要な発見として、 エラー内容だけでなく、リトライ数とtemperatureも付与したほうが効果的である ことを確認しました（解決策2-1の21件→解決策2-2の9件）。これらの情報を付与することで、LLMが「何回目の試行で、どのような生成条件なのか」を把握でき、前回と異なる出力を生成しやすくなったと推察されます。 トークンが繰り返される問題についても、定量的な評価には至っていないものの、定性的には出現頻度の低下と出力の安定化を確認しています。 性能への影響 エラーフィードバックを追加することで性能への悪影響がないか検証しました。柄の評価データセットを用意し、エラーFBの有無で3回ずつ実行した平均値を比較しました。リトライ時にtemperatureを0.1ずつ増やす運用を想定し、temperature 0.0〜0.2の範囲で検証しています。 モデル temperature エラーFBの有無 F1スコア gemini-2.5-flash-lite 0.0 ✗ 0.8417 gemini-2.5-flash-lite 0.0 ✓ 0.8208 gemini-2.5-flash-lite 0.1 ✗ 0.8434 gemini-2.5-flash-lite 0.1 ✓ 0.8208 gemini-2.5-flash-lite 0.2 ✗ 0.8425 gemini-2.5-flash-lite 0.2 ✓ 0.8217 性能への大きな影響はないことを確認しました 。数値上ではF1スコアに約0.02の低下が見られますが、エラーフィードバックが適用されるのはバリデーション失敗時のリトライのみです。正常に出力された大多数のケースではフィードバックが付与されないため、システム全体への影響は軽微です。 まとめ 本記事では、LLMの構造化出力で発生するエラーを87％削減した手法を紹介しました。 本記事の貢献は以下のとおりです。 バリデーション＋エラーフィードバック をプロンプトに含めることでエラー件数を87％削減できる エラー内容だけでなく、 リトライ数とtemperatureも付与すると効果が高い フィードバックを追加してもF1スコアへの大きな悪影響はなく、安心して導入できる この手法はGeminiに限らず、 LLMの構造化出力タスク全般 に応用可能 LLMの構造化出力や、Gemini APIの出力の安定化（トークン繰り返し問題の回避）に悩むエンジニアの方々にとって、本手法が何らかのヒントになれば幸いです。 おわりに ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください！ corp.zozo.com Generative AI on Vertex AI - 構造化出力 ↩ Gemini API - 構造化出力 ↩ トラブルシューティング ガイド - トークンの繰り返しに関する問題 ↩ 朗読に関する問題 ↩ トークンの繰り返しに関する問題 ↩