Skip to content

Fetch が ClickHouse Cloud 上に柔軟なエージェント型アナリティクスツールを構築した方法

neutral avatar 400804ae96
2026年7月28日 · 13分で読む

概要

  • Fetch は、レシートやオファーのデータから 1 日あたり 1,500 億行以上を取り込む、セルフサービス型で対話式の BI エージェント「FAST」を ClickHouse Cloud 上で構築しました。
  • 高速なアドホッククエリ、ユーザー同士のワークロードが衝突しないコンピュート分離、そして ClickPipes によるシンプルなバッチロードを求めて、同チームは ClickHouse Cloud を選択しました。
  • これまで数日かかっていた回答がわずか数分で得られるようになり、Fetch のアナリティクスチームは絶え間ない単発依頼への対応から解放され、より難易度の高い課題に集中できるようになりました。

Fetch は人気のリワード(報酬)アプリで、毎月1,300万人以上のユーザーがオンラインショッピングやレシートのスキャン、ゲームプレイを通じて、日々の買い物に対して報酬を受け取っています。これらのレシートは、消費者を360度から捉えるビューをFetchに提供しており、ユーザーがすでに愛用している商品を購入することに報酬を与えつつ、ブランドが生涯顧客を育てるのを支援するために活用されています。

1日あたり、Fetchのユーザーは1,300万件を超えるレシートをスキャンし、そのうち3,000万件を超える明細行が特定の商品と紐づけられ、1,500億行(非圧縮で50 TB、圧縮後で6.5 TB)のデータがAWS上の ClickHouse Cloud に取り込まれています。会社の成長に伴い、こうしたデータ量はアナリティクスのボトルネックを生み出しました。シニアアナリティクスエンジニアのBrendan Sigale氏は次のように語ります。「Fetchには収益を生み出す無限のデータがあるが、それを使いこなせる人材は有限だ」と。

「当社の営業とコマーシャライゼーションのチームは、ビジネスと、ブランドパートナーにとって何が重要かをよく理解しています。FASTはそうしたチームがアイデアを素早く反復し、より強力なキャンペーンを構築し、ブランドとユーザーの双方に優れた結果を届けることを助けてくれます。」

— Brendan Sigale, Senior Analytics Engineer, Fetch

Brendan氏は Open House SF 2026 に参加し、Fetchが構築したFAST——非技術系チームが自然言語で購買データを問い合わせ、数日ではなく数分で答えを得られる、柔軟なエージェント型アナリティクスプラットフォーム——について紹介してくれました。

FetchにおけるFASTの仕組み

FASTは「Fetch AI Semantic Technology」の略です。ユーザーは使い慣れた対話型UIで自然言語による質問を投げかけ、データと直接対話できます。「そのため速度が非常に重要になる」とBrendan氏は言います。「質問して数時間、数分、あるいは30秒待たされるだけでも、気が散り、創造性の流れが途切れてしまう……それではインタラクティブな体験とは言えません。」

FASTの使い方の基本的な例として、朝食カテゴリーのオファーを企画中のユーザーが「過去数か月でオレンジジュースを購入した人は何人いますか?」と尋ねた場合が挙げられます。FASTはその質問を解釈し、Fetchの商品タクソノミー上でのオレンジジュースの定義を参照し、基盤テーブルへのクエリ方法を定めたセマンティックモデルと照合したうえで、約260万人という答えを返しました。

そこからさらに複雑になっていきます。同じユーザーが、その購入者のうちマフィンや朝食用パンも購入した人が何人いるかを知りたがりました。これは2つのグループの積集合であり、事前に計算しておくのが難しい類のものです。「スケーラビリティの問題にすぐに直面します」とBrendan氏。クエリが実行され、答えは約116万人と返ってきました。

最後に、彼はさらにハードルを上げ、事前集計テーブルでは答えられない問いに絞り込みました。同じ買い物で一緒にベーグルも購入し、かつシングルサーブのオレンジジュースボトルを除外した人は何人か、というものです。「そんなものが事前集計されているはずがありません」とBrendan氏は言います。「カスタムクエリを実行するしかありません。」

まさにそれをFASTがやってのけました。同一レシート上で2つの異なる購入リストを結合し、2億700万行を1秒未満でスキャンし、130,883人のユーザーを返したのです。「他のプラットフォームでは絶対にできません。特にこの複雑さのクエリでは」とBrendan氏は言います。

対象オーディエンスを特定したうえで、ユーザーはFASTにオファーのピッチ案の作成を依頼しました。すると、オレンジジュースとベーグルを組み合わせた朝食バスケットのプロモーションが生成されました。「重要なのは、そうしたインサイトをFASTでアクションに変えられることです」とBrendan氏は言います。

データへのアクセスを民主化することで、Fetchの営業とコマーシャライゼーションのチームはより素早く動けるようになります。「これまでは不可能だった形で、非技術系のユーザーが自らのアイデアを非常に迅速かつ創造的に反復できるようになりました」とBrendan氏は語ります。

ClickHouse Cloudによる高速な対話型BIエージェントの応答

Brendan氏が言うように、対話型BIエージェントの有用性は、その裏にある速度に左右されます。「本当に速くなければ、FASTなどと呼べません。」ClickHouseを使うことで、エージェントの応答時間の中央値は1.9秒。「これは従来のクラウドデータウェアハウスなら簡単に数分かかっていたはずです」と彼は付け加えます。

さらにソリューションには柔軟性も必要です。「これらのクエリを事前集計しておくことはできません」とBrendan氏は言います。「アドホックなクエリに耐えられる柔軟性がありながら、インタラクティブなチャット体験を実現できるほど高速な、リアルタイムアナリティクスプラットフォームが必要でした。」

LLMが効果的でパフォーマンスの高いクエリを書くには、データベースがきちんとドキュメント化され、書きやすくトレーニングもしやすいものでなければなりません。そして負荷下でも一貫した動作をする必要があります。「私が実行している複雑なクエリが、他の複雑なクエリ、特に誰かが実行している簡単なクエリに影響を与えてはいけません」とBrendan氏は言います。「ClickHouse Cloudのクエリ間のコンピュート分離は、私たちにとって非常に大きな意味を持ちました。またアーキテクチャがシンプルなので、管理も立ち上げもとても簡単でした。」

Fetchが検討した他のリアルタイムアナリティクスソリューションは、こうした点で及ばなかったといいます。「他のプラットフォームは、質問のスケールや範囲があらかじめ分かっている、予測可能なワークロード向けに最適化されています」とBrendan氏は語ります。「私たちのユースケースでは、速度不足だったり信頼性の問題があったりと、いずれも課題を抱えていました。」

他のプラットフォームへのデータのロードも困難で、論理ビューのサポートは限定的で、取り込み経路も「明らかに私たちのバッチロードのワークフロー向けには設計されていなかった」といいます。一方、ClickPipesはデータ取り込みを容易にします。「ClickPipesを備えたClickHouse Cloudは、これを本当にシームレスに処理してくれました」とBrendan氏は言います。

これはFetchがスケーリングの課題を乗り越える助けにもなりました。「コンピュートを追加すればするほど、ノード間のネットワークホップとシャッフルが増えていき、これが真のボトルネックになりました」とBrendan氏は他のプラットフォームについて語ります。「一方、ClickHouseでは非常に簡単で一貫したスケーリングが可能でした。パフォーマンスが必要ならスケールアップするだけでよかったのです。」

さらに、他のプラットフォームでは良好なパフォーマンスを得るためにキャッシュのウォームアップなどの手順を要することが多かったのに対し、「ClickHouseではそういったことをする必要が全くありませんでした」とBrendan氏は言います。

FASTのClickHouseベースのパイプライン

毎晩、パイプラインはFASTに必要なデータの完全なコピーをSnowflakeから取得し、S3に同期し、ClickPipesを使って新しいバージョン付きテーブルにロードします。そして、そのテーブルにビューを再ポイントします。「ClickPipeの更新とビューの切り替えをするAPIコール付きのDAGにすぎません」とBrendan氏は言います。

Fetch カスタマーストーリー.jpg

Snowflakeから始まりS3を経由してバージョン付きのClickHouseテーブルへと至る、FASTの夜間パイプライン。

Brendan氏は、これが教科書通りのアプローチではないことも認めています。「理想を言えば増分でデータをロードするべきなのですが、結合を最小化してパフォーマンスを最大限引き出すために、各行にすべてのディメンションデータを含む非常にワイドなテーブル構造にしています。」その構造は軽量な更新と相性が悪いため、シンプルさで勝る夜間リフレッシュが採用されました。

「そして、私たちにとって最も重要なのは」とBrendan氏は続けます。「LLMにとって非常に扱いやすいことです。」モデルは、どのバージョンのテーブルが現行かを追跡したり、クエリの対象をその都度書き換えたりする必要が一切ありません。receiptsビューを参照して実行するだけで、そのビューは常に最新データを解決します。同じ仕組みはインシデント対応も容易にし、以前のバージョンのデータへのロールバックは単にビューを再ポイントするだけで済みます。

数日ではなく数分で得られる回答

現在、FASTは約100人のユーザーから1日あたり500件以上のクエリを処理しており、レイテンシの中央値は約1.9秒です。Brendan氏は、同等かそれ以下のパフォーマンスしか提供しないプラットフォームと比較してコスト効率が高いと言います。「私たちにとって最も重要なのは」と彼は付け加えます。「アナリティクスまでの時間です。以前はチケットが取り上げられるのを待つ必要があり数日かかっていた質問が、今では数分で答えを得られるのです。」

FetchのチャネルパートナーシップチームのメンバーであるSaraさんが、実際の例を挙げてくれます。

「あるライブミーティングで、チームがキャンペーンの潜在的な規模を把握したいという場面がありました。あとで折り返す代わりに、私はFASTを使ってオーディエンスサイジングをリアルタイムで取得しました。探索的な会話として始まったものが、データを即座に得られたおかげで、その場で確定した計画へと変わったのです。」

— Sara S., Channel Partnerships, Fetch

このメリットはFetchのアナリティクスチームにも及びます。以前であれば、Saraさんの質問はチケットになり、それに答えるためにアナリストが他の優先事項から引き離されていたでしょう。FASTがあれば、営業とコマーシャライゼーションのチームは自分たちのアイデアを自ら追いかけられる一方で、アナリティクスチームは全社に影響する基盤的な課題に時間を割けるようになります。

今すぐ始める

ClickHouseがあなたのデータでどのように動作するかご興味はありませんか?ClickHouse Cloudなら数分で始められ、$300の無料クレジットもご利用いただけます。

サインアップ

この記事をシェア

  • Y Combinator icon
  • X icon
  • Bluesky icon
  • Facebook icon
  • LinkedIn icon

Subscribe to our newsletter

Stay informed on feature releases, product roadmap, support, and cloud offerings!