社内データを「誰でも自然言語で照会できる」状態にする——多くの企業が目指しながら、実現しきれていない課題です。Cloudflareはその問いに、自社製品だけを使って正面から答えを出しました。構築の一部始終が、今日公開されています。
2026年5月28日、Cloudflareは社内向け統合データ分析プラットフォーム「Town Lake」と、自然言語でデータを照会できるAIエージェント「Skipper」の社内リリースを発表した。同社の社内データ基盤は毎秒10億件超のイベントを処理しており、これまでPostgres、ClickHouse、Kafka、BigQuery、R2といった複数のシステムに分散していた。
Town LakeはCloudflare自社製品のみで構築されており、長期ストレージにR2、クエリ実行にWorkers、データオーケストレーションにWorkflowsを採用している。認証管理にはCloudflare Accessを使用し、PII（個人識別情報）の自動検出には専用の内部ツールを活用している。統一SQLインターフェースにより、ダッシュボードのレンダリング向けの「高速」ダウンサンプリングデータと、請求・セキュリティ調査向けの「正確」非サンプリングデータをそれぞれ使い分けることができる。
Skipperは自然言語の質問を監査可能なSQLクエリに変換し、数秒で回答を返す。現在AnthropicのClaude Managed Agentsを経由してリクエストを処理しているが、基盤モデルをコモディティAPIとして扱うモデル非依存設計を採用している。2026年5月時点で社内3,683ユーザーにサービスを提供しており、Cloudflare AI Gatewayを通じた処理トークン数はすでに2,410億に達している。
From: 
Cloudflare Ships Skipper AI Agent and Town Lake Data Platform
【編集部解説】
「自分で使う」という最も厳しいテスト
Cloudflareが今回Town LakeとSkipperを構築したとき、使ったのはすべて自社製品でした。ストレージはR2、計算処理はWorkers、オーケストレーションはWorkflows、認証はAccess、AIコード実行はDynamic Workers。外部のデータウェアハウスサービスやサードパーティのオーケストレーション基盤は一切使っていません。
これはCloudflareが長年続けてきた開発文化の延長線上にあります。同社は自社サイトの保護にも、内部通信にも、開発者向けに販売しているのと同じ製品を使います。Cloudflare Accessも、社内エンジニアが「なぜクラウドセキュリティ企業が古いハードウェアVPNを使っているのか」と疑問を持ったことから生まれました。製品の顧客が社内にいるということは、最も率直なフィードバックが最も早く届く、ということでもあります。
Town LakeとSkipperのリリースは、その意味で単なる「社内ツールの公開」ではありません。Cloudflareが自社の開発者向けプラットフォーム——R2、Workers、Workflows、Access、Dynamic Workers——が「データプラットフォームを本番運用する」という最も重いユースケースに耐えることを、自ら証明した結果です。
データの散乱は「成長の証拠」でもある
Town Lakeが解決しようとした問題は、実はどこにでもあります。急成長した組織ではデータがシステムごとに分散し、誰も全体像を把握できなくなります。
Cloudflareの場合、Postgresにはアカウントメタデータ、ClickHouseにはアナリティクスイベント、BigQueryには利用集計、R2には生ログ、Kafkaにはリアルタイムシグナルがそれぞれ蓄積されていました。毎秒10億件超を処理する規模でこれらが分断されていれば、「今週の上位10顧客をR2ストレージコスト順に並べ、先週比の変化も見たい」という一問が、数システムにまたがるJOINクエリを手書きする作業になります。
ここで選ばれたのがApache Trinoでした。Trinoは分散MPP（大規模並列処理）エンジンとして、オブジェクトストレージ・RDB・ストリーミング基盤といった異種ソースをまたぐフェデレーテッドクエリを実現します。データを中間システムに移さず、各ソースにクエリをプッシュダウンできるため、分散した現状を再設計せずに統合できます。さらにコールドデータの保管形式にはApache Icebergを採用しており、スキーマの進化、タイムトラベルクエリ、パーティション最適化といった機能を確保しています。
「自然言語でSQL」の難しさと、Skipperの設計上の答え
自然言語でデータベースを問い合わせるアイデア自体は新しくありません。しかし2026年時点でも、その実運用の難しさは広く認知されています。学術ベンチマークではLLMのText-to-SQL精度が85〜90%に達する一方で、実際のエンタープライズ環境ではデータの複雑さや曖昧さによってその精度が大きく下がることが報告されています。特に問題になるのが「サイレントエラー」——エラーを返さず、間違った答えを返すケースです。データの意思決定に使うなら、これは致命的です。
Skipperがこの問題に対して取った設計上の答えは二つあります。
一つは監査可能性。Skipperは自然言語を「結果」ではなく「SQLクエリ」に変換します。つまりユーザーは、AIが何をしたかを見ることができます。ブラックボックスではなく、検証可能なプロセスとして機能します。
もう一つは多層のコンテキスト付与。SkipperはDataHubのスキーマ情報、人手のアノテーション、テーブル生成SQL、内部データモデル文書、ライブインスペクションクエリといった複数の情報源を組み合わせることで、LLMが誤ったJOINや列の誤用をしないよう設計されている。
「モデルを使い捨てる」という宣言
SkipperはAnthropicのClaude Managed Agentsを通じて動作していますが、設計上は特定モデルに縛られていません。基盤モデルは「コモディティAPI」として扱われ、差し替え可能な部品として位置づけられています。
これは技術的な保険であると同時に、Cloudflareのビジネス上の立場の表明でもあります。AI基盤モデルの競争は今後も続き、何が「最良のモデル」かは変わり続けます。そのダイナミズムに乗りながら、特定ベンダーに縛られないアーキテクチャを選んでおくことは、大規模な社内システムを長期運用する上で合理的な判断です。
SkipperがAI生成コードの実行に使うDynamic Workersは、2026年3月に発表されたものです。
社内ツールが製品ロードマップになる
Cloudflareがこの構築経緯を公開した意味は、単なる技術共有にとどまらないかもしれません。Town Lakeを構成するR2・Workers・Workflows・Access・Dynamic Workersは、すべてCloudflareが顧客に提供しているプロダクトです。社内で「データプラットフォームを1から作れた」という事実は、外部の組織に対して「あなたたちも同じことができる」というメッセージになります。
そして今回公開されたブログ記事は、その設計図を詳細に書き起こしています。何を選び、なぜ選び、どう組み合わせたか。これ自体が、Cloudflareの開発者プラットフォームの最も説得力あるドキュメントです。
【用語解説】
Apache Trino
Facebookで2012年に生まれたPrestoを源流とし、独立コミュニティが発展させたオープンソースの分散SQLクエリエンジン。Prestoの創設者たちが2018年にFacebookを離れて、2019年にPrestoSQLとしてフォークし、2020年にTrinoと改名した。Postgres、ClickHouse、Icebergテーブルなど異種データソースをまたぐフェデレーテッドクエリを1つのSQL文で実行できる。データを中間システムに移動させる必要がないため、大規模環境での分析に適している。
Apache Iceberg
大規模分析テーブル向けのオープンソースのテーブルフォーマット。スキーマの進化（既存データを壊さずにテーブル定義を変更する機能）、タイムトラベルクエリ（過去の時点のデータを参照する機能）、パーティション最適化などを提供する。Spark、Trino、Flinkなど複数のクエリエンジンが同じテーブルを安全に利用できる。
Cloudflare R2
Cloudflareが提供するオブジェクトストレージサービス。AWS S3と互換性があり、他社クラウドで発生するデータ取り出し（エグレス）料金がかからない点が特徴。Town Lakeでは長期データの保管先として使用されている。
Cloudflare Workers
Cloudflareのエッジネットワーク上でコードを実行するサーバーレスコンピュートプラットフォーム。V8アイソレートを使用し、世界330拠点以上でミリ秒単位の起動を実現する。Town Lakeではクエリ実行の計算処理を担っている。
Dynamic Workers
2026年3月に公開されたCloudflareの新しいランタイム。AIが生成したコードスニペットをアイソレート環境でミリ秒単位で実行するために設計されており、Skipperの実行層で活用されている。
Cloudflare Mesh
自律エージェントが分離されたプライベートデータベースに安全にアクセスするためのCloudflareの機能。エージェントのアクセス権限を細かく制御できる。
コールグラフマッピング（Call-graph mapping）
プログラムの実行中に、どの関数がどの関数を呼び出すかの関係を図式化したもの。Skipperでは、AIが生成したSQLが実際に実行される前に、この解析によって安全性と構文の正確性を確認している。
フェデレーテッドクエリ（Federated query）
複数の異なるデータソース（データベース、ストレージ、ストリームなど）を、データを1か所に集約せずにまたいで実行するクエリ手法。Apache Trinoはこれを得意とする。
PII（個人識別情報）
Personally Identifiable Informationの略。氏名・メールアドレス・電話番号など、特定の個人を識別できる情報の総称。Town Lakeでは認証にCloudflare Accessが使われており、PIIの自動検出は社内の専用ツールが担っている。
【参考リンク】
Cloudflareブログ：Town Lake & Skipper 構築記録（一次情報源）（外部）
CloudflareがTown LakeとSkipperを構築した経緯・設計思想・技術的詳細を網羅した一次情報源。本記事の内容はここに基づいている。
Cloudflare Developer Platform（外部）
R2・Workers・Durable Objects・AI Gatewayなど、Town Lakeの構成要素でもあるCloudflareの開発者向けプロダクト群の総合ページ。
Cloudflare R2 オブジェクトストレージ（外部）
エグレス料金ゼロを特徴とするCloudflareのオブジェクトストレージ。Town Lakeの長期データ保管に使われている。
Cloudflare Workers AI（外部）
CloudflareのエッジネットワークでAIモデル推論をサーバーレスで実行できるサービス。Skipperのモデル実行基盤として活用されている。
Apache Trino 公式サイト（外部）
Town Lakeのクエリエンジンとして採用された分散SQLクエリエンジン。異種データソースをまたぐフェデレーテッドクエリが可能。
Apache Iceberg 公式ドキュメント（外部）
Town Lakeのコールドデータ・ウォームデータ保管形式として採用されたオープンテーブルフォーマット。スキーマ進化・タイムトラベルなどの機能を提供する。
Cloudflareブログ：Cloudflare Data Platform 発表（2025年12月）（外部）
Town Lakeの公開版インフラにつながるR2 Data Catalog・Pipelines・R2 SQLの発表記事。外部向けサービスとの関係を理解するための文脈として有用。
【参考動画】
Cloudflare Agents Week（2026年4月）で発表された20以上のAIエージェント関連機能をCloudflareのプロダクトマネージャーが解説。Town Lake / SkipperのベースとなるインフラのAgents Week発表内容が把握できる。
SkipperがAIモデルとのやり取りに使用しているClaude Managed AgentsのCloudflare連携を詳しく解説した動画。5msコールドスタート・セキュリティ制御・ツール設定の仕組みが分かる。
【参考記事】
How we built Cloudflare’s data platform and an AI agent on top of it（Cloudflare Blog）（外部）
本記事の一次情報源。Town LakeとSkipperの設計思想、Trino・Iceberg・R2の採用背景、DataHub活用などをCloudflareエンジニアが直接解説している。
The Text-to-SQL Performance Cliff (2026): Why “Natural Language to SQL” Breaks（Medium）（外部）
Text-to-SQLの学術ベンチマークと実運用環境の乖離を整理した論考。Skipperの設計上の選択が問題への回答になっていることの文脈を提供する。
Announcing the Cloudflare Data Platform（Cloudflare Blog、2025年12月）（外部）
Town Lakeの社内版に対応する外部向けプロダクト群の発表記事。Cloudflareが社内ユースケースを外部製品に転換してきた流れを追うために有用。
The Secret to Cloudflare’s Pace of Innovation（Cloudflare Blog）（外部）
「Cloudflare is built on Cloudflare」というドッグフーディング哲学を解説した記事。Town Lakeが自社インフラのみで構築された意味を理解する背景として参照。
Dogfooding from Home: How Cloudflare Built our Cloud VPN Replacement（Cloudflare Blog）（外部）
社内エンジニアの不満からCloudflare Accessが生まれた経緯。社内課題が製品になるというCloudflareの開発サイクルの代表的事例として参照。
【編集部後記】
Cloudflareが今回公開したのは「ツールを作った」という話ではなく、「どう作ったか」という記録でした。どのコンポーネントを選び、なぜそれが合理的だったのか——その選択の連鎖が丁寧に書き起こされています。
気になるのは、Skipperの設計で「モデルは差し替え可能な部品」と宣言されている点です。自然言語からSQLへの変換を担うモデルが「コモディティ」になるとすれば、価値はどこに残るのか。データの文脈を知っていること、クエリの構造を検証できること、組織の問いに答え続ける仕組みを維持できること——そのあたりに、私たちはまだ名前をつけられていない何かがあるような気がします。
