「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 .

こんにちは、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 .

Google Cloud Digital Native Leader’s Meetup に参加しましたチーフデータサイエンティストの Mario です！ 2023年3月24日（金）、Google Cloud Japan 様より Digital Native Leader’s Meetup にご招待頂き、参加してきましたのでレポートします。とてもありがたいことに Lightning Talk のスピーカーとして登壇させて頂きましたので、その内容についても触れていきます。 日本のデータ活用のリーダー達が渋谷ストリームに集結。ビッグデータ界隈で誰しもが知っている錚々たる企業の皆様に囲まれ、終始わくわくドキドキしてました。 Leader’s Meetupって？ このイベントは、各業界でデータ活用を推進するデジタルネイティブなリーダーたちが集まり、これからのデータ戦略や、開発・運用などにおける悩みをぶつけ合い、互いの知識と経験を共有し合うことで、相互成長が期待できるオフラインの語り場です。 今回は２回目の開催で、データ分析・活用とその基盤に関することがテーマだったため、主にアナリスト、データエンジニアの方々の参加が多かったようです。 会の流れとしては、 1.Google Cloud アップデート情報 2.Customer Lightning Talk 3.アンカンファレンス 4.ネットワーキング と、コンパクトながらも濃密な内容でした。 フード＆ドリンクもご提供頂きました。美味しいお寿司にたこ焼き、クラフトビールにこだわりの日本酒、そしてヴィーガン配慮まで（さすが！） アツい！Google Cloud の最新情報 イベントの冒頭で、Google Cloud の最新情報が発表されました。先行開示情報もあるのでここでの記載は控えますが、今回のテーマが分析ソリューションだけあって、BigQuery のアップデートに関する情報が中心でした。 BigQuery 単体としての機能性はもちろんですが、Google Cloud 全体でのプロダクト同士の親和性もかなり強化されてきていて、ますますビッグデータの活用においては欠かせないプラットフォームだなと改めて興奮を覚えます。 また昨今、組織内でのマルチクラウド化や自他組織間でのデータ連携活用が目を見張る勢いで広がっていますが、一方でデータのサイロ化が一つの問題として挙げられます。BigQuery x Analytics Hub x Dataplex を利用することで、シームレスかつセキュアな基盤を構築することができるという紹介もありました。 unerry においても、クライアントやパートナーが保有するデータと、弊社の行動情報を掛け合わせて新たなソリューションを多数開発しており、その連携性とデータガバナンスを改善していく上で重要なトピックでした。 登壇しました！Customer Lightning Talk お次は、お待ちかね？、Lightning Talk。 unerry 含む、Google Cloud Customer 2 社と、Google Cloud の 3 本立てでした。 私、この日のためにネタを作ってきました。 題して【行動情報 x BigQuery x 大規模言語モデルで叶えるパーソナルコンシェルジュ】。 やはり話題の LLM。とても好評を頂きまして、そのあとの懇親会でも活用方法についての議論が絶えないほど、皆さんの関心も高かったです。発表内容の詳細は　↓↓こちらの記事↓↓　にまとめていますので、是非ご一読ください。 『Beacon Bank x ChatGPT で叶えるパーソナルコンシェルジュ』を作ってみた https://www.unerry.co.jp/blog/beacon-bank-x-cha... チーフデータサイエンティストの Mario です！ 皆さん、ChatGPT、使ってますか？毎日何かと話題に事欠きませんね。私も日々 ChatGPT を使い倒しています。この記事も ChatGPT のサポートを得ながら書いています。unerry 社員も個人的に ChatGPT の活用する人... ちなみに、LT登壇の記念としてパーカーを頂きました！今の春の気温にぴったりなので、プライベートでも愛用しています。 白熱のアンカンファレンス Lightning Talk が終わると、今度はユーザー同士で語り合うアンカンファレンスです。 参加者はいくつかチームに分かれ、その中でも Solution : 課題解決のきっかけにしたい人 Discovery : 課題発見のきっかけにしたい人 に分かれて、機能の使い方から、基盤の構築方法やルール、チーム体制といったレイヤーの高いトピックまで、様々な悩みを打ち明けては別の方が解決策を提案するという流れで進みました。 他の人の悩みを聞いてみると、あぁその悩みは考えたらウチにもあるな、と意外と気づきがあります。 私がいたチームでは以下のような悩みが挙げられていました。 ・連続したデータバッチ処理において、どこかでこけた際の再処理時にスペックアップして、なるべく後続の処理を遅らせないようにしたい。 ・数千カラムにも及ぶJSONデータを効率よくインポートしたい。 ・BigQuery を全社的に活用していくために、特にデータサイズへの感覚がない人に対してのコストコントロールをどうしたらいいか。 ・Google Cloud Project の作成ポリシーで悩む。 個人的に面白かったのは、プロジェクト作成ポリシーの話題から派生して、「命名ルール決めが一番頭使う問題」という共通認識が皆さんにあって、エンジニアあるあるだなと実感しました。 ある方は、データレイク・データウェアハウスレイヤーまではデータエンジニア＆サイエンティストが決め、プロダクト寄りのデータマートでは分析チームが徹底して命名ルールを最初に決めたとお話頂いてました。 夜は長いよ カジュアルな雰囲気もありつつ、参加者皆さんのレベルが高いため非常に議論が発熱し、最後の最後まで話しながら会場に残っている方が多くいらっしゃいました。 また、会の終了後も二次会、三次会と懇親会が続きましたが、ずっと皆さん仕事の悩みや未来を楽しそうに語られていたのが印象的でした。 Google Cloud のカスタマーサクセスの方々がとても親切かつ知識に富んでいることに加え、参加者の皆様も年齢も知識・経験量もバラバラなのに尊敬し合う雰囲気があり、会の内容もさることながらコミュニティとしても、とても素晴らしかったです。 改めてこの素晴らしい会を企画・開催し、またコミュニティをつなげてくださった Google Cloud の皆様に、この場を借りて御礼申し上げます。 今後もこの会はテーマを変えながら開催されていくようですので、この記事を読んでくださった皆様も参加されてみてはいかがでしょうか？私も機会があれば参加していきますので、皆様とお話しできる時を楽しみにしています。 最後に、お土産で頂いたマグカップを載せておきます。保温・保冷ができる優れもので、やはりお土産まで一味違います。 The post Google Cloud Digital Native Leader’s Meetup に参加しました first appeared on 株式会社unerry .

チーフデータサイエンティストの Mario です！ 皆さん、ChatGPT、使ってますか？毎日何かと話題に事欠きませんね。私も日々 ChatGPT を使い倒しています。この記事も ChatGPT のサポートを得ながら書いています。unerry 社員も個人的に ChatGPT の活用する人が増え、度々 Slack が盛り上がっています。 ビッグデータと掛け合わせての活用方法は無限にあり、積極的に取り入れて行ってます。まだまだ私たちも個人レベルから組織レベルまで模索中ですが、一例としては以下があります。 – ユーザー嗜好性に合わせたコンテンツ（クリエイティブ）の自動生成 – 分析結果からインサイトを得るためのサポート – 新しいデータの掛け合わせによって期待される効果や商品の提案 まずは第一弾として、ユーザーの嗜好性に合わせ、お勧めの近隣店舗をレコメンドするメッセージを自動生成する仕組みを開発してみましたので、今日はその紹介をしていきます。 開発の狙い ところで皆さん、あまり慣れていない場所に来た時にどこでランチを食べようか迷ったことありませんか？その時、多くは Web 検索だったり、飲食店検索アプリだったり、あるいは SNS だったりで探すと思います。 でも、実際行ってみたら混んでて入れませんでした、とか、本当は静かな空間が好きなのにワイガヤしてました、とか、失敗することもありますよね。もし、初めて来た場所でも、自ら検索することもなく、嗜好にあったお店を自動で紹介してくれたら、こんな便利なことってありませんか？ 元々 unerry はそんな世界を創りたいと思って創業したわけですが、それをさらに ChatGPT によって加速させられないか、というのが発想の起点です。また、これによってクリエイティブ担当者やデータアナリストの工数を劇的に削減できる期待も込めています。 何をした？ unerry はユーザーのリアルの行動情報に基づいて、デモグラ（性別、年齢層、行動嗜好性）からリアルタイムの状況（通勤中、お買い物中、旅行中など）を推定するAIを開発しています。 そのユーザーの属性とコンテンツとのマッチングを行って情報配信を行っているのですが、リアルタイム性だったりパーソナライズという観点ではAI技術を活用することで、さらに改善や発展の余地があると考えました。 unerry ではセキュリティに配慮の上、全社員が BigQuery を共通の分析基盤として使用できる環境を整えています。そこで、BigQuery から ChatGPT を直接利用できるようにしました。 どうやって？ 具体的には、ChatGPT に対してリクエストを投げてレスポンスを得る Python プログラムを Cloud Functions にデプロイしておき、Remote Functions を介して、BigQuery から呼び出すという仕組みです。 例えば、渋谷に来たユーザーに対して、普段の食の嗜好性に基づいて近くのおすすめのお店を紹介するというケースです。ユーザーの年齢層、そして食の嗜好性として「食の好み（料理ジャンル）」と「環境（お店の雰囲気）」をパラメーターとしてリクエスト文に入れることで、一人ひとりの嗜好性に合ったレコメンドを返してもらうようにしました。 リクエスト文 「20～30代の韓国・アジア料理好きな人に向けて、渋谷でゆったりできるお勧めのお店を１つ紹介してください。」 レコメンド文 「『●●（店名・アジア料理店）』は、20-30代の韓国・アジア料理好きな方におすすめのお店です。渋谷駅から徒歩5分圏内にあり、居心地の良い空間でリラックスできます。メニューは韓国を中心にアジア各国の料理がそろい、カジュアルに食事するだけでなく、飲み会やデートにもおすすめです。」 と、このようなメッセージを受け取ることができます。 来訪者の分析 → レコメンドメッセージの生成まで、BigQuery ワンストップでできるため、例えばクリエイティブ作成の工数が劇的に減らせます。 今後の野望 冒頭にも書きましたが、積極的に ChatGPT を含む LLM、また画像や音声など様々な自動生成 AI を活用し、様々なサービスやプロダクトを進化させていきたいと考えています。 直近の課題としては、ChatGPT の学習データは 2021 年 9 月までのものとなるため、情報の鮮度が古かったり、そもそも店舗が実在しなくてもそれっぽい回答をすることもあるため、独自に全国の施設情報を網羅し、品質高く整備したデータを掛け合わせていく必要があります。 また、生成された文章が本当にユーザーにとって不快な印象を与えないかどうかの検証も必要です。今後は、例えば「友達と買い物中」や「仕事終わり」といったユーザー側のリアルタイムの推定状況データに加え、施設側の混雑状況を加味したマッチングにより、リアルタイムでパーソナライズされたレコメンドを行うことで、さらにユーザー体験を進化させていきます。 The post 『Beacon Bank x ChatGPT で叶えるパーソナルコンシェルジュ』を作ってみた first appeared on 株式会社unerry .

unerryのCTOをしております、伊藤と申します。 unerry CTO伊藤 Google 様の手厚いサポートをいただき、渋谷オフィスのセミナールームをお借りして、1/19(木)に「 LINE Botを Google Cloud で作ろう! ハンズオン勉強会 Vol.1」を開催いたしました 内容は、簡単なLINE Botを作り、Google Cloud 上でビルド/デプロイして実機で動かすところまでを学ぶ、2時間のハンズオンです。そこで講師をつとめさせていただきました。 Google Cloud のユーザーコミュニティ「 Jagu’e’r 」の会員と「 HarborS 」会員の方々を対象に参加者を募ったため、「 GCP には詳しいけれど LINE API には詳しくない」方と「 LINE API には詳しいけど GCP には詳しくない」方が混在することとなり、珍しいイベントとなりました。 必ず動くまでやり遂げる事を目標としたので、少しやさしめな内容とはなりましたが、2時間で全員もれなく完走できました。 講義資料はこちらで公開しています。 https://sitopp.github.io/Handson-LINE-Bot-GCP-template-01/ 構成は以下のようになります。 ポイントは Cloud Run です。自分は「人類が月面に降り立って以来の衝撃」と呼んでいるのですが、コンテナビルド&デプロイがとても簡単にでき、初めての人でも環境構築から公開までサクッと出来ます。 負荷に応じて自動的にスケールアウト/インしてくれるので、急なアクセス増加にも耐えることができ、中規模程度のアクセスまでなら、ファーストチョイスになると思います。 ※高負荷の場合は GKE(Google Kubernetes Engine)の方がコスト面では良いと思います。学習/保守の人的コストは高いですが。 河本さん 実は、一緒にイベントを主催したエンジニア仲間の河本さんが声をかけてくださり、河本さんご自身を含めてLINE API Expertの方々がメンターとして合計3名も参加して下さっていました。 また先日 Google Cloud Partner Top Engineer 2023に選出された弊社の蔵谷 も、私がコケた時のため静岡から東京に来て参加してくれていたので、大変心強かったです。 その後の懇親会では、Google 様にご用意いただいたピザや軽食をつまみながら、和気藹々と情報交換しました。 懇親会までが勉強会です 平日の夕方と言う事もあり、業務をぬけて来ていただくのは難しかったかもしれません。 快く送り出してくださった上司の方々には感謝します。 ロゴ入りのお饅頭 & どら焼き。歓喜 Google 様、会場やケータリングなどなど、手厚いサポートありがとうございました！ このお土産のお饅頭とどら焼きも大好評でした 実は2/16に第二回を開催しました。そのレポートもいずれブログに掲載します。 関連情報 Jagu’e’r https://jaguer.jp/ HarborS https://harbors.anti-pattern.co.jp/ #GoogleCloud #linebot #Jaguer The post LINE Botを Google Cloud で作ろう! ハンズオン勉強会 Vol.1を開催しました！ first appeared on 株式会社unerry .

本記事は、2020年5月に掲載されたEngineer Blog（Medium）からの転載です。 みなさん、こんにちは。GWはロードバイクで新潟まで行きたかった蔵谷です。(もちろん中止しました。。。) 今回からWordPressからMediumへ移行しました！ 最近BeaconBankに導入すべくAnthosについて勉強しています。Anthosでググるとマルチクラウドの記事がいっぱい出てきますが、他にも便利な機能がたくさんあります。今日は他の便利な機能について書いていきます。 Ingress for Anthos マルチクラスタ・マルチリージョン間のHTTP(S)ロードバランシングするためのサービスです。これを使うことについて、以下のメリットがあります。 マルチリージョンにクラスタを作ることによって、より近いサーバーにアクセスできるので、レイテンシが低くすることが可能になる。 リージョン障害等でクラスタが落ちた場合、他のリージョンのクラスタでサービス続行できる。 クラスタ再構築のような大規模なメンテナンスがしやすくなる。 逆にデメリットとしては、 アクセスが分散されることを見越したリソース調整をしておかないと、コストが高くなってしまう。 新しいサービスなので、ドキュメントが少なめ。 あと、KubernetesにはMulti Cluster Ingressというものが用意されているのですが、以下のような違いがあります。 Anthos for Ingress ・・・CRD形式。GCPのマネージドサービス。現状はGKEのみ設定できる。 Multi Cluster Ingress・・・CLI形式(別途kubemciをインストール)。サポートなし。 GKE使っていて、マルチクラスタで運用したい場合はAnthos for Ingressがおすすめです。 構成図 以下は登場人物の説明です。 MultiClusterIngress(mci)・・・静的IPとどのMutiClusterServiceを紐付けるかを書きます。必要に応じてSSL証明書の設定も書きます。 MultiClusterService(mcs)・・・MutiClusterServiceとどのアプリケーションを紐付けるかを書きます。 注意点としては、同じ名前空間をクラスタに作成しないと駄目な点です。(MultiClusterIngressとMultiClusterServiceとServiceのmetadata.namespaceを揃える。) 構築手順 構築手順については、公式ドキュメントが詳しいので、そちらを見てください。 Ingress for Anthos を設定する 　 【Anthos、GoogleCloudPlatform】はGoogleLLCの商標です。 The post Anthosについて (Ingress for Anthos) first appeared on 株式会社unerry .

本記事は、2020年6月に掲載されたEngineer Blog（Medium）からの転載です。 みなさん、こんにちは。蔵谷です。昨日から関東でも梅雨に入りましたね。自転車通勤の天敵です・・・。 昨日はDroidKaigiのオンラインイベントが行われていたので、どんなことが発表されたか簡単にまとめたいと思います。 Android Studio 4.0 ● Layout Inspector & Validation 結構動作が重いのですが、レイアウトが以下のように3D表示されます。この機能を使うと、どのレイヤにどのコンポーネントが配置されているか一発でわかるようになります。 ● Motion Layout Editor 今までアニメーションを作る時はxmlで作っていたと思うのですが、GUI上でモーションを作ることが可能になります。 ● Build Analyzer ビルドする時にどこに時間がかかっているかがわかるツールです。以下は作りたてのアプリなので表示される情報は少ないのですが、このような表示になります。遅い箇所はワーニングアイコンが表示されて教えてくれます。 ● Java 8 library desugaring minSdkVersionの値に依存せずにJava8言語APIが一部使えるようになりました。java.timeがAPI Lebel21でもエラーにならなくなっています。 ● Kotlin Android live templates どういう機能かというと、例えば、toastとタイプしてTabキーを押すと素早くToastを追加できるようになります。kotlinではこの機能使えなかったんですよね。個人的にすごい嬉しいです。 Android 11 β版がようやく公開されたようです。 Android 11 Beta | Android Developers ● Bubbles Facebookメッセンジャー知っている人はわかると思うのですが、メッセージが届くと画面の隅にアイコンが表示されるあの機能です。進行中の通信やチャット等に使われる想定しているそうですが、広告の通知にたくさん使われるんだろうな・・・。 イベント内ではデバッグメニューをバブル通知に入れると良いかもということで結構盛り上がっていました。 Bubbles | Android Developers ● One-time permissions 開発者泣かせのワンタイムパーミッション・・・。一回だけカメラ使わせたり、位置情報取らせたりできます。Activityが動いている間だけ有効らしいです。裏に回ると、約45秒後に使えなくなります。 https://developer.android.com/preview/privacy/permissions#one-time ● App Compatibility Changes アプリの互換性をテストするための機能です。アプリ毎・機能毎にON・OFF変更できます。adbコマンド経由でも変更できるらしい。 Test your app’s compatibility with Android 11 | Android Developers ● ApplicationExitInfo アプリのクラッシュやANR等のログをアプリ内に保存するための機能です。ANRのログをPlayConsoleまで探しに行かなくても良くなるので、デバック作業が捗りそうですね。 最後に 昨日のイベントの動画は以下に上がっているみたいなので、詳しく知りたい方は動画もチェックしてください。 【商品名】はGoogleLLCの商標です。 The post DroidKaigi On Air: Android 11&Android Studio 4.0 まとめ first appeared on 株式会社unerry .

本記事は、2020年6月に掲載されたEngineer Blog（Medium）からの転載です。 みなさん、こんにちは。バイオハザードRE:3にハマっている蔵谷です。 今回は私の中でイチオシの機能のAnthos Service Mesh(ASM)について解説していきます。 Anthos Service Mesh(ASM)とは？ 最近流行りのマイクロサービス化ですが、あまりにもサービスが増えすぎると、どのサービスとサービスが通信してるんだっけとか運用していく上で色々と問題に直面すると思います。 このような問題を解決するためのツールがAnthos Service Mesh(ASM)です。 ASMを導入すると以下の情報が可視化されます。 サービス間のトラフィック サービス単位の指標(RPSやエラー率、レイテンシ等) SLO エラーログ pod単位の指標(RPSやエラー率、レイテンシ等) どのメソッドが呼ばれているか SREの考えを取り入れている現場が増えてきているので、SLO設定 > エラーバジェット使い果たす > stackdriverからの通知が手軽に設定できるのが個人的にいいなと思いました。 あと、マネージドなistio使えるのも良いです。GKEにistioのインストール方法が3種類ありまして、 istioctlやhelmで直接インストールする方法 ・・・色々できるが、初めての人には敷居が高い。 Istio On GKEを使う方法 ・・・マネージドで良さそうに見えるのですが、GKEに含まれている内部のIstioがアップデートされると設定がリセットされる仕様なので要注意。 Anthos Service Mesh用istioをインストールする方法・・・テレメトリ収集等設定を行わなくても自動でやってくれるので敷居が低い。もちろんマネージド。自動でアップデートはなしなので、勝手に設定リセット等の心配もなし。 GKEを使っている＋SLO設定を使って監視したいのであれば、Anthos Service Mesh用istioを使うのが良いと思います。 設定方法 GCPのインストールガイドの手順通りにやれば問題なかったです。手順書くとメンテするの大変なので、ここでは書きません。 インストールガイド 　 【Anthos】はGoogleLLCの商標です。 The post Anthosについて (Anthos Service Mesh) first appeared on 株式会社unerry .