FountainがClickHouse Cloud上でデータプレーンを再構築し、現場向け超知能「Cue」を強化した方法

Fountain は、小売、物流、飲食、医療、ホスピタリティなど、世界の労働力の大半を占める時給制の現場スタッフ(フロントラインワーカー)向けソリューションを構築しています。2014年以降、Fountain のプラットフォームは 9,100 万人以上の応募者と 1,400 万件の採用を処理し、75 か国以上の顧客に 10 の製品を提供してきました。

応募から勤務開始日までの現場採用サイクルを支えるグローバル企業として、Fountain は 24 時間体制で稼働しており、同社を頼る企業(およびその従業員)も同様です。Fountain のデータプラットフォーム部門責任者である Alex Norton 氏は、「現場は眠りません」と述べています。「私たちの顧客は、何千もの拠点で 24 時間 365 日、採用、オンボーディング、シフト作成を行っています。」

以前、Fountain は 3 時間ごとのバッチジョブに依存していました。「これでは、“今” 意思決定を下す必要のある顧客の要望に応えられませんでした」と Alex 氏は語ります。そこで同社は、現場の業務運用を支えるエージェント型 AI プラットフォームである Cue Frontline Superintelligence を構築しました。Cue を使えば、現場の採用担当者は午前 9 時 2 分にシグナルを確認し、9 時 5 分には意思決定を下せます。

「現場の応募者の半減期は、数時間ではなく数分です。ClickPipes によって更新間隔を 3 時間から 2 分以内へと短縮できたことは、当社の顧客層にとって真の変革となりました。」

— Alex Norton 氏、Fountain データプラットフォーム部門責任者

Open House SF 2026 において、Alex 氏とシニアアナリティクスエンジニアの Cecily Storey 氏は、Cue をどのように構築したかを発表しました。かつてのマルチベンダーによるバッチアーキテクチャから、AWS 上の ClickPipes と ClickHouse Cloud を使った合理化されたシステムへと移行した経緯、そしてこれによってコストを約 3 分の 1(66% 削減)に抑えつつ 1 秒未満のクエリを実現した方法を紹介しています。

以前のスタックが行き詰まった 5 つの理由 #

Fountain の以前のアナリティクスアーキテクチャは、従来のバッチ処理モデルを採用していました。データは、ソースデータベース(本番環境の Postgres データベース 13 個と MongoDB データベース 4 個)からサードパーティのレプリケーションベンダー経由で S3 に移動し、Iceberg および Parquet 形式で保存された後、分析のために BigQuery および(s3 テーブル関数 を使用して)ClickHouse へと送られていました。

Fountain の以前のバッチアーキテクチャ: 高コストで脆弱、現場の需要に対して遅すぎる

「3 時間ごとの更新パイプラインとしてはこれでも機能していましたが、それでもコストがかさみ、脆弱になっていきました」と Alex 氏は述べています。チームは複数のベンダーやクラウドをまたぐパイプラインを管理していました。MongoDB が加わると、Fountain の少人数のデータチームにとって大きな負担となりました。「保守に多くの時間を取られ、イノベーションに費やせるはずの時間が削られていました」と同氏は語ります。

Alex 氏は、最終的に再構築を余儀なくされた 5 つの制約を挙げています。1 つ目は鮮度です。3 時間の間隔は、数分単位で行動するエージェントとは相容れませんでした。2 つ目はコストです。論理的な 1 回のデータ移動に対して、レプリケーション、S3 ストレージ、ウェアハウスへの取り込み、分析コンピュートという 4 つの個別請求が発生していました。「3 時間ごとの更新であっても、コストが跳ね上がっていました」と同氏は言います。

3 つ目は複雑さです。3 社のベンダーと 2 つの中間フォーマットが存在することで、システム間の連携部分で常にスキーマの不整合(schema drift)が発生していました。4 つ目はカーディナリティで、100 億行を超えるテーブルと状態遷移ウィンドウが指数関数的に爆発していました。そして 5 つ目は同時実行性です。数十のテナントにわたる数千人のユーザーが同じデータプレーンにアクセスする中、Alex 氏は「クエリレイテンシを 10 秒未満に抑えることすら苦戦を強いられており、1 秒未満にするなど不可能でした」と語っています。

ClickPipes と ClickHouse Cloud による再構築 #

Alex 氏は新しいアーキテクチャをシンプルに説明しています。「私たちは ClickPipes を中心に据え、その上に他のすべてを配置しています。」レプリケーション、オブジェクトストレージ、ウェアハウスを 1 本の長いチェーンにつなぎ合わせる代わりに、Fountain は ClickPipes のマネージド CDC を使用して、Postgres と MongoDB の両方を ClickHouse Cloud に直接ストリーミングしています。「ベンダーは 1 社、ソースデータベースごとに 1 つの接続、接着剤のようなグルーコードはゼロです。」

Fountain の ClickHouse をベースとした新アーキテクチャ: ベンダーは 1 社、ホップ数は 1 回、スケジューラは不要

ネイティブ JSON により、Fountain は文字列パースを行わずに MongoDB の深くネストされたドキュメントを処理できます。Alex 氏によれば、古いシステムではこの文字列パースが「特にニアリアルタイム処理において非常に高コストになっていた」とのことです。インクリメンタルマテリアライズドビュー は ClickPipes がバッチを書き込んだ瞬間にデータを変換するため、データパス上にオーケストレーターは存在しません。そして行レベルのアクセス制御により、誰かがクエリに条件を書き忘れる心配なく、構造上必然的に顧客ごとのデータが分離されます。

その結果、Postgres 用と MongoDB 用の 2 つの対称的なパイプラインが完成しました。どちらも「ソース → ClickPipes → マテリアライズドビュー → Cue」という同じ短いパスを実行します。以前のアーキテクチャでは 2 つのホップ、4 つの請求書、システムの境目でのスキーマ不整合が存在していましたが、新しいアーキテクチャでは 1 つのアナリティクスプラットフォーム、1 回のホップ、スケジューラなしという構成になりました。

「複数の分析プラットフォームを維持する代わりに、ユーザーはリアルタイム分析プラットフォームとして ClickHouse を信頼して利用できます。コストを 66% 削減でき、保守もはるかにシンプルになりました。」

— Alex Norton 氏、Fountain データプラットフォーム部門責任者

Fountain の新しいアーキテクチャの詳細 #

続いて Alex 氏は、Fountain のリアルタイムエンジンのリード開発者である Cecily Storey 氏にマイクを渡し、データプレーンを支える ClickHouse の 4 つの機能(ClickPipes、ネイティブ JSON、インクリメンタルマテリアライズドビュー、ロールベースのアクセス制御)について解説しました。

ClickPipes #

「ClickPipes が鍵です」と Cecily 氏は言います。「Alex と私の話から 1 つだけ持ち帰るとすれば、ClickPipes が当社のリアルタイムモデルをシンプルでスケーラブルなものにした、ということです。」

現在、Fountain は 15 個以上のコネクタを稼働させ、2,000 を超えるインクリメンタルマテリアライズドビューにデータを供給しています。Postgres 側では、11 個の本番デプロイメントが Postgres の主キーをキーとして SharedReplacingMergeTree テーブルへと継続的にレプリケーションされています。すべての行には、ClickPipes 自体によって付与される _peerdb_synced_at と _peerdb_is_deleted という 2 つのカラムが含まれます。「他に監視するものも、追加で支払う費用もありません」と Cecily 氏は述べています。「Iceberg 層も S3 バケットも存在しません。」

MongoDB のソースも、Fountain の労働力管理製品を支える 4 つのデータベースにわたって同じパターンを踏襲しています。各ドキュメントは、ネイティブ JSON 型の単一カラムに取り込まれます。「ClickPipes Mongo とネイティブ JSON の組み合わせこそが、MongoDB ソースのニアリアルタイム化を実現可能にした要因です」と Cecily 氏は言います。全体として、CDC 層は 1,550 テーブルにわたる 84.8 億行を、圧縮後約 953 GiB で保持しています。

ネイティブ JSON #

以前のバッチクラスターでは、すべての MongoDB フィールドを JSONExtract の呼び出しによって文字列カラムから抽出する必要がありました。「記述が冗長になりますし」と Cecily 氏は語ります。「パース対象となるデータのすべての行について、必要なフィールドごとにパースを行うのはコストがかかります。」

ClickHouse のネイティブ JSON データ型 は、これらすべてをシンプルなドット記法に置き換えました。フィールドは doc.companyUuid::String や doc.homeAddress.city::String のように指定するだけで、抽出関数を必要とせず、ドキュメントの必要な深さまでアクセスできます。「毎回 JSONExtract や JSONValue を記述しなくて済むのは快適です」と Cecily 氏は言います。

スキーマオンリードであるため、新しい MongoDB フィールドを追加する際も、下流の ReplacingMergeTree に対して 1 行の SQL 変更を加えるだけで済みます。「DDL もスキーマレジストリも不要です」と Cecily 氏は言います。「必要なデータはすべてその単一の doc フィールド内にすでに存在しているため、ClickPipe 自体をバックフィルする必要もありません。」ネストされた配列は動的値の配列として届き、ClickHouse の配列関数(arrayMap、arrayJoin、arrayFirst、arrayLast)ともスムーズに連携します。

最も重要な点として、ClickHouse は読み取りのたびに文字列を再パースするのではなく、JSON を内部的に列指向のサブ構造として保存します。「これは大規模環境において大きなメリットです」と Cecily 氏は述べています。「CPU とメモリの両方の消費量を大幅に削減してくれます。」

インクリメンタルマテリアライズドビュー #

この「アーキテクチャの心臓部」は、データ変換の方法にあります。CDC ソースの下流にあるすべてのマテリアライズドビューは、ClickPipes が生のテーブルにバッチを書き込んだ瞬間に起動します。「連鎖反応のようなものです」と Cecily 氏は言います。「1 つで変更が発生すると、それが次へと連鎖していきます。」

Fountain は 15 のデプロイメントのそれぞれで 100 以上のモデルをこの方法で実行しており、dbt で記述して ClickHouse 内に直接構築しています。クエリを高速に維持するために変換処理は意図的に浅く保たれ、大半のモデルは ReplacingMergeTree(状態遷移ログのような不変レコードの場合は通常の MergeTree)に格納されます。「Dagster も Airflow も cron もありません」と Cecily 氏は言います。「設定するだけで、あとは何もしなくて済みます。更新処理はストレージエンジンの特性そのものなのです。」

オーケストレーションなしのデータ変換: ClickPipes が生の CDC テーブルにバッチを書き込み、マテリアライズドビューが起動し、重複排除された行がスケジューラなしで ReplacingMergeTree に格納される

この挿入時の処理モデルは、チームにとって「最大の性能向上」ももたらしました。「応募者が特定のステージにどれくらいの期間滞在したか」という一般的な質問に答えるには、各状態遷移の前後のタイムスタンプが必要でした。クエリ実行時にテーブル全体に対してそのウィンドウ関数を実行する代わりに、彼らはその処理をマテリアライズドビューへと移し、ClickHouse の lagInFrame 関数 と ASOF JOIN を組み合わせました。lagInFrame が現在のバッチ内のレコードを処理し、ASOF JOIN がすでに保存されている過去のデータにアクセスし、coalesce がバッチ内の値が存在する場合はそれを採用し、存在しない場合は保存済みの値へとフォールバックします。

8 億 3,800 万行の状態遷移テーブルにおいて、この計算を挿入時に 1 回だけ行うようにしたことで、クエリごとのメモリ使用量は 778 MiB から 153 MiB へと 80% 削減されました。クエリの形状全体に一般化すると、同じパターンによって 60〜98% のメモリ削減が実現します。Cecily 氏は教訓を次のように要約しています。「高負荷な処理はインクリメンタルマテリアライズドビューに移し、クエリ自体は軽量に保つようにしましょう。」

セキュリティとガバナンス #

パズルの最後のピースは、おそらく最も斬新なものでした。Cue の LLM がセキュリティモデルを認識することも影響を与えることも決してできないようにすることです。「この課題の解決はとても楽しかったです」と Cecily 氏は語ります。

Cecily 氏の説明によると、Cue のアナリティクスクエリはすべて、デプロイメントごとのサービスユーザーとして実行されます。「これらは基本的には空の器として設計されており、単体では一切のアクセス権を持ちません。」アクセス権は、SELECT 権限と、デフォルトでは空になっている一連のセッション変数を持つ、タイムスタンプでバージョン管理された RBAC ロールから付与されます。Fountain のバックエンド MCP は、誰がクエリを実行しているのか、何を見る権限があるのかに基づいて、各クエリの開始時にこれらの変数を設定し、すべてのテーブルの行ポリシーがテナントキーに照らしてフィルタリングを行います。

テナントセーフなアナリティクス: Cue が呼び出し元ごとの権限変数を設定し、サービスユーザーのロールがクエリをルーティングし、行ポリシーがテナントキーでフィルタリングするため、LLM がセキュリティモデルを認識することはありません。

したがって、セキュリティは完全にデータプレーン内に存在し、モデルが構築する WHERE 句の中に置かれることは決してありません。「当社の LLM はセキュリティモデルについて何も知りません」と Cecily 氏は言います。「仮に誰かが当社のエージェントにプロンプトインジェクションを試みたとしても、顧客をまたぐデータが漏洩することはなく、閲覧が許可されていない製品のデータにアクセスすることもできません。これを制御する変数はすべてデータベースレベルにあり、エージェント LLM の完全に外部にある当社の MCP によって指定されるためです。」

また、この設計はフェイルセーフになっています。権限変数が不足または無効である場合、ロールが適用されていない場合、あるいは新しいテーブルが RBAC 構成に含まれていない場合、Cue にはデータが過剰に表示されるのではなく、単に何も表示されなくなります。Cecily 氏の言葉を借りれば、「これは本質的に安全な状態の動作です。」

成果: より速く、より安く、スケールする設計 #

これらすべては、Fountain のエージェント型アナリティクスおよびアクション層である Cue を支えるために存在しています。Alex 氏が言うように、「数時間前や数日前に収集されたシグナルを集約したダッシュボードを監視し、そのシグナルを特定するために積極的にダッシュボードを閲覧していた状態から、これらすべてをリアルタイム化し、Cue がインサイトを特定してアクションを起こせる状態へと移行しました。」

Cecily 氏はその変革を裏付ける数字を挙げ、「3 時間から 2 分を大幅に下回るまでになりました。実際のところ、大半のクエリについて言えば、リアルタイムパスでは 1 秒未満に近いです」と指摘しています。

全体として、現在このシステムは ClickPipes によって継続的にレプリケーションされる 84.8 億行の CDC データと、15 のデプロイメントにわたる 103 億行のアナリティクスデータを保持し、2,000 以上のインクリメンタルマテリアライズドビューによって提供されています。ウィンドウ関数の事前マテリアライズド化により、メモリ使用量は 60〜98% 削減されました。そして、Fountain の以前のバッチベースのプロセスと比較して、ClickHouse Cloud 上に構築された新しいプラットフォームは、運用コストが約 66% 削減されています。

エンジンを社内へも展開 #

顧客向けに Cue を構築した今、Alex 氏は「このエンジンを社内に向け、Fountain の社内チームでも利用できるようにする」計画だと語っています。ClickHouse のリモート MCP を使用して、同社は(スキル付きプラグインとしてパッケージ化された)Claude Desktop を通じてリアルタイムのセマンティックモデルを社内ステークホルダーに公開し、データチームに依頼を出すことなく、すべての Fountain 社員がデータモデルに直接クエリを実行できるようにする予定です。「これにより、プロダクトチームとデータとの距離がこれまで以上に縮まり、チームに大きな変革をもたらすでしょう」と同氏は述べています。

追いつかなくなったパイプラインへの対処として始まった取り組みは、今や会社全体がその上に構築を進める基盤となりました。Alex 氏は「ClickHouse で構築されたニアリアルタイムのパイプラインは、時給制の労働力とその管理方法を変革しているだけでなく、現場スタッフをさらに支援するための製品づくりのあり方も変革しています」と語っています。