はじめに：データがあふれても答えが見つからない逆説

Cloudflareは毎秒10億以上のイベントを処理するグローバルネットワークを運用しています。しかし数年前までは、社内のアナリストが「今日登録したドメインのうち、トラフィック上位100に入るドメインはいくつか？」という質問に答えるには、Postgres、ClickHouse、BigQuery、R2、Kafkaなど多数のシステムを渡り歩き、それぞれの認証情報とクエリ言語を習得する必要がありました。データはあふれているのに、必要なデータを見つけることが極めて難しい状況でした。

この問題を解決するために、Cloudflareは2つの社内ツールを自前で構築しました。Town Lake（統合データ分析プラットフォーム）とSkipper（その上で動作するAIデータエージェント）です。この記事では、その構築プロセスから得た知見を共有します。特に、データ基盤を設計する際に考慮すべきガバナンス、スケーラビリティ、AI活用戦略に焦点を当てます。

Data lakehouse architecture diagram with query engine and metadata catalog Developer Related Image

Town Lake：データレイクハウスの実践設計

Town Lakeの中心となるアーキテクチャはデータレイクハウスです。オブジェクトストレージ（R2）にデータを保存し、その上にメタデータレイヤーを載せてデータベースのように動作させます。

主要コンポーネント

  • クエリエンジン（Apache Trino）: 単一のSQLクエリでPostgres、ClickHouse、R2のIcebergテーブルを結合できます。
  • R2 Data Catalog（Iceberg）: スキーマ進化、タイムトラベル、パーティション管理など、データレイクの主要機能を提供します。
  • DataHub: メタデータカタログであり、すべてのテーブル/カラム/オーナー/リネージ情報を管理します。
  • Lifeguard: アクセス制御サービスで、D1にルールを保存し、ユーザーグループ情報を動的に反映します。
  • Skimmer: PII検出スキャナーで、Workers AIを活用してカラムごとの機密情報を自動分類します。
  • Transformer: WorkflowsベースのELTエンジンで、SQL変換DAGを定義・実行します。
-- 例: 単一クエリで複数ソースを結合
SELECT
  c.customer_name,
  SUM(b.billed_amount) AS total_revenue
FROM fct.billings_allocated b
JOIN dim.accounts a ON b.account_id = a.account_id
JOIN dim.customers c ON a.customer_id = c.customer_id
WHERE b.billing_period = '2024-Q4'
GROUP BY c.customer_name
ORDER BY total_revenue DESC
LIMIT 100;

この構造の利点は、データを移動せずに複数のシステムを一つにまとめられることです。特に、フィルタをClickHouseにプッシュダウンし、Postgresのディメンションテーブルと結合し、R2の請求ロールアップをランキングするなど、複雑な処理を単一クエリで実行できます。

Cloudflare Town Lake platform dashboard showing query metrics Algorithm Concept Visual

Skipper：自然言語でデータを問い合わせるAIエージェント

Skipperは自然言語の質問を受け取り、正しいテーブルを見つけ、SQLを作成し、結果を検証するAIエージェントです。重要なのは多層的なコンテキストを提供することです。

  1. スキーマと使用メタデータ: DataHubがすべてのカラム/型/結合関係を提供します。
  2. 人間による注釈: テーブル所有者が作成した説明をコンテキストとして活用します。
  3. コード由来の知識: テーブルを生成するSQLパイプラインの.meta.jsonドキュメントを自動登録します。
  4. キュレーションされたデータモデル: 少数の手書きドキュメントでエージェントの優先順位を誘導します。
  5. ランタイムイントロスペクション: 必要に応じてDESCRIBEやSELECT DISTINCTなどのクエリを直接実行して検証します。

Code Mode：MCPサーバーの新しいパターン

SkipperのMCPサーバーは、30以上の個別ツールを公開する代わりに、searchとexecuteの2つのみを公開します。モデルはJavaScriptスニペットを記述して、ツールセット全体をプログラム的に呼び出します。

// 例: MCP Code Modeで複数ステップを一度に実行
const datasets = await skipper.search_datasets({ query: "billing product revenue" });
const queryId = await skipper.start_query({ sql: "SELECT ..." });
const results = await skipper.fetch_results({ queryId, mode: "inject" });
return skipper.create_chart({ chartType: "bar", data: results.rows, ... });

この方法により、モデルは複雑なワークフローを単一の往復で表現でき、監査可能なコードとして記録されます。

AI agent Skipper interface with natural language query and results chart System Abstract Visual

日本企業での適用文脈

日本の企業でもデータ基盤構築には同様の課題があります。特に金融やコマースでは、個人情報保護法などの規制によりPII管理がさらに重要です。Town Lakeのdefault-closed方式、つまりテーブルがレビューされるまでアクセスをブロックするポリシーは、日本の規制環境に適したアプローチです。ただし、初期構築時にレビューのボトルネックが生じる可能性があるため、自動化されたPII分類器などのツール導入が必須です。

注意点と限界

  • 初期構築コスト: Trino、Iceberg、DataHubなど複数のオープンソースコンポーネントを組み合わせるため、運用の複雑さが高まります。
  • メモリレイヤーの重要性: エージェントが繰り返しのミスを減らすには、長期メモリ（例: D1）が必須です。
  • セキュリティは設計の一部: アクセス制御と監査ログを後回しにすると、結局データ基盤全体の信頼性が低下します。

次のステップの学習方向

  • Apache IcebergとTrinoの応用を学んでみてください。
  • MCPサーバーとCode Modeパターンを実際に実装し、エージェント開発の経験を積んでください。
  • データガバナンスフレームワーク（例: DataHub）を実際のプロジェクトに適用することをお勧めします。

まとめ

Cloudflareの事例は単なる技術的成功談ではなく、データ文化を変える旅です。データ基盤を「バックオフィス」として扱わず、重要なインフラとして昇格させた点が最大の教訓です。皆さんの組織でも、データを単一の窓口に統合し、AIエージェントを通じてアクセス性を高める試みをぜひ行ってみてください。詳細はCloudflareブログ原文をご参照ください。

あわせて読みたい

本コンテンツは、信頼性の高い情報源をもとにAIツールを活用して作成され、編集者によるレビューを経て公開されています。専門家によるアドバイスの代替となるものではありません。