最終編集日時：2026年10月26日
配車、食料品配送、フードデリバリー、送金などを手がけるUAEのスーパーアプリ「Careem」は、5,000を超えるモデルを支える少数精鋭のデータエンジニアリングチームによって運用されています。同社の技術スタックはすべて社内で構築されており、インジェストから変換、BIに至るまでエンドツーエンドでオープンソースで稼働しており、変換作業はdbtが担っています。2026年のdbt Summitの分科会において、データプラットフォームチームのエンジニアリングマネージャーであるニヤズッラー・カーン・パタン氏と、同チームのリードソフトウェアエンジニアであるアカシュ・スリヴァスタヴァ氏は、未処理のデータ要件が100件以上積み上がっている状況を説明し、それらの一つひとつに対応するのに従来は1〜2週間かかっていたと述べました。
彼らの最初の修正試行は、最も明白な方法でした。すなわち、LLMに問題を提示してモデルの作成を任せることです。しかし、これは失敗に終わりました。なぜなら、AIが生成したコードを一行ずつ読み込むのではなく、パターンをざっと見ただけでレビューを行う人間では、パイプラインを破壊するわずかな例外ケースを見落とし、ひいてはビジネスが数値に対する信頼を失ってしまうからです。
「自信は検証から生まれるものであり、コード生成器そのものから生まれるわけではありません」とスリバスタヴァ氏は述べました。「どんなLLMでもコードを書くことはできます。そのコードを統合する際の自信は、エンドツーエンドの検証によって得られるのです。」
それが、同社の四柱式エージェントアーキテクチャの設計原則となった。オープンメタデータに基づくコンテキスト層は、エージェントに対してテーブルおよび列レベルのドキュメント、リネージ、AOVやGTVといった部族固有用語の用語集、さらには一元化されたメトリック定義を提供し、曖昧な用語についてエージェントが推測するのを防ぐ。
スペックロックステップにより、エージェントは何かを書き込む前に、グレイン、メトリクスの定義、フィルターについて明確化のための質問を必ず行うよう強制されます。このステップだけで、よくある失敗パターンが解消されます。たとえばCareemでは、「収益」という用語だけでも、尋ねる相手によってGTV、GMV、あるいは注文数を指す場合がありましたが、今ではエージェントがそのいずれかを明示的に確認し、黙って一方を選んで期待するようなことはなくなりました。
同プラットフォームは、完全に管理されたフェデレーション型メトリクス専用の「ゴールデン層」と、一時的なアナリストのリクエスト用の「トランジエント層」を明確に区別しています。トランジエント層のデータは30日間の有効期限後に、正式なデータマートへ昇格するか、自動的にクリーンアップされます。Careem の規模においては、こうしたガバナンス上の取り扱いが極めて重要です。同社のチームは、昨年だけで3.6ペタバイトものトランジエントデータを整理しました。
構造的なガードレールにより、サンドボックス化された開発環境では、各エージェントが生成する変更が分離され、独立したIAMロール、ストレージパス、コンピュートリソースが設定されるため、エージェントの操作が本番環境に影響を及ぼすことはありません。さらに、エージェントループは各変更をコンパイル・テストし、適用することで、型の不一致などの障害を検出し、プルリクエストを人間がレビューする前に自動的に修正し、処理が成功するまで繰り返します。
ライブデモでは、アナリストによる「各マーチャントの毎日の食品売上を取得したい」という平易な英語のリクエストが、わずか数分で完全にテスト済みかつ文書化されたdbtモデルとプルリクエストに変換され、途中で2回のテスト失敗を経て自動的に修正されました。そのプルリクエストに対する自動検査は、標準的なdbtテストにとどまらず、データがブロンズ層からシルバーレベル、ゴールドレベルへと適切に移行していることを確認し、さらにモデルの格納場所がCareemのドメイン規約に準拠していることも検証しました。最初のサンドボックス実行ではデータ型の不一致により失敗しましたが、エージェントがそのエラーを読み取り、修正したうえで再実行しました。
2回目の実行は、必要な列が別のソーステーブルに存在していたため失敗しました。エージェントはコンテキストレイヤーを用いてその列を見つけ、結合してから再度実行しました。クリーンな実行が完了して初めて、プルリクエストは人間の手に渡りました。
結果として、メトリクスの納期は2〜3週間から数時間に短縮され、Careemでは現在、新規モデルの約90％がこのフレームワークから生み出されており、プロセス導入以降、sev0およびsev1のインシデントは一切発生していません。
チームは重複リクエストの保護機能も実装しました。すべての変更は dbt マニフェストを経由するため、すでに追加済みの列に対する二度目のリクエストは検出され、ほぼ同一のモデルを新たに作成するのではなく、既存のモデルへとリダイレクトされます。
そして、プラットフォーム全体の構築は迅速に進みました。Careemは12月にdbtの評価を開始し、3月までに全インフラを整備、4月か5月にはエージェントを本番稼働させました。さらに、レガシーデータウェアハウスの移行自体も、わずか数週間で完了しました。パタン氏は講演の締めくくりとして次のように述べました。「生成器は簡単です。重要なのは検証層であり、それが製品そのものです。」
dbt Summit 2026の基調講演および分科会をすべてオンデマンドで視聴できます。dbt Summit 2026をオンデマンドで視聴する →
dbtの利用を開始する
実際にスケールするデータインフラを構築しているアナリティクスエンジニアの仲間に加わりましょう。
dbt Wizard CLI をインストールする
分析エンジニアリング専用に設計されたエージェントで、すぐに使い始めることができます。どのツールを呼び出すべきか、どのコンテキストを取得すべきかを把握し、あなたに結果を提示する前に自らの作業を確認します。
最新の投稿
DocuSignがClaude Codeとdbt v2、dbt MCP、およびエージェントスキルを組み合わせることで、分析エンジニアリングにかかる時間を半分に短縮した方法
2026年10月26日
バージン・メディア・O2が、dbtにメモリを提供することでコンピュートコストを30％削減した方法
2026年10月26日
Rampの社内AIエージェントが100万セッションを突破した方法
2026年10月26日
データを形作る最大のコミュニティに参加しよう
dbt Communityは、世界中の数千ものデータリーダーやAI実務者とのベストプラクティス、イノベーション、直接的な協業への玄関口です。質問を投げかけ、知見を共有し、専門家とともにより良いものを構築しましょう。