タイミー — dbt+Looker を意味層に据え、生 Text-to-SQL を避けた社内 AI エージェント基盤¶
作成日: 2026-07-24 出典 / きっかけ: Timee Product Team Blog（2025-12-18、chanyou/DRE チーム、Advent Calendar 18日目）＋ Findy 登壇「作って終わりにしない タイミーのセマンティックレイヤー育成の現在地」。Findy 3社の中で「本物の意味層寄り」の実例として調査 関連: 意味層_enforced_cube_dbt_looker_整理 カンム_synapse_セマンティックレイヤーの育て方_整理（同登壇・advisory 側の対比）メルカリ_socrates_データ基盤とマルチエージェント_整理 cursor_agent_swarm_planner_worker経済性_整理
0. 要点（3行）¶
- タイミーの DRE チームが作った社内 AI エージェント基盤。設計思想は「気軽に作って壊せる」— エージェントごとに Cloud Run＋Vertex AI Agent Engine(ADK) を個別デプロイし、複数を並行運用
- 意味層は Looker(LookML)。dbt でコード化した定義を Looker から一元管理し、エージェントはそれを経由して数値を返す。理由を明言: 「複雑なドメインロジックを全て Text-to-SQL させるのはクエリ結果の信頼性担保が難しい」→ カンムと逆の判断
- 運用の工夫が具体的: Slack メッセージに
[PR-123]タグでその PR のエージェント実装を即テストできるプレビュー環境、Slack スレッド=セッション（Agent Engine 内蔵ストレージで別 DB 不要）。課題は評価環境の未整備（モデル変更時のリグレッション防止）
1. アーキテクチャ¶
| レイヤ | 採用 |
|---|---|
| UI | Slack Bolt アプリ（Cloud Run） |
| エージェント実行 | Vertex AI Agent Engine（ADK: Agent Development Kit） |
| DWH | BigQuery |
| 変換 | dbt |
| BI・意味層 | Looker(LookML)（ビジネス用語の一元管理） |
| クラウド | GCP |
- エージェントごとに Cloud Run と Agent Engine を個別デプロイ → 「作って壊せる」を実現（1つのモノリスに詰めない）
- セッションは Slack スレッド単位。Agent Engine 内蔵のセッションストレージで永続化し、別途 DB を持たない
2. 意味層の据え方（ここがカンムとの分岐点）¶
- 「データをビジネス用語・概念に紐づけるレイヤー」として Looker を位置づけ、dbt でコード化した定義を Looker から参照する構造
- エージェントは Looker で参照できるデータをベースに「一定の信頼が置ける」数値を返す = 生 SQL を直接叩かせない
- 明示された判断: 「複雑なドメインロジックを全て Text-to-SQL させるのは信頼性担保が難しい」
- → カンム_synapse_セマンティックレイヤーの育て方_整理 は生 Text-to-SQL＋文脈注入で行ったのに対し、タイミーは意味層(Looker)経由に倒した。同じ登壇でも設計思想が逆
- → enforced 意味層の考え方（意味層_enforced_cube_dbt_looker_整理）の日本の実装例
3. 運用・開発の工夫¶
- プレビュー環境: Slack メッセージに
[PR-123]を含めると、その PR のエージェント実装を即座にテスト可能 → レビュー負荷を下げる（Coding Agent で開発が速くなり、コードレビューがボトルネック化したことへの対処） - MCP Tool と Function Tool の使い分け、ユーザー認証情報の扱い、マルチエージェントのデザインパターンを学びとして挙げる
- 全社展開済み。ただし定量成果は記事に未記載
4. 課題（記事が正直に書いている）¶
- 評価環境の未整備が最大の課題。プロンプトチューニングや基盤モデル変更時のリグレッション防止の仕組みが要る
- → メルカリ Socrates の Agent-as-Judge、カンムの Execution Accuracy と同じ悩み。「意味層を据えても、エージェントの回答品質を測る評価系は別途要る」は3社共通
5. 考察（自分の解釈）¶
- 一言でいうと「意味層は Looker に任せ、エージェント基盤は"使い捨て可能性"に全振り」。難しい部分（数字の正しさ）を既存の BI 資産(Looker)に外出しし、自分たちは「気軽に作って壊せる」実行基盤の速度に集中した割り切り。既に Looker があるなら最も現実的な入口
- 意味層 vs エージェント基盤の分離が綺麗。意味層（Looker）＝数字の正しさ、Agent Engine＝オーケストレーションと会話、と責務が切れている。自分の「基準の外化（harness.yaml）」と同じで、意味を実行基盤に埋め込まない
- 評価環境が未整備という正直な告白は重要。意味層を据えても回答品質の評価は自動化されない（意味層はクエリの正しさを保証するが、「そのクエリを選んだ判断」の妥当性は別）。ここが3社共通の宿題
- 留保: 定量成果なし。Findy 登壇スライド（作って終わりにしない…）に「育成の現在地」の続報があるはずで、意味層の育て方の詳細はそちらに
6. まとめ — 転用できる型¶
| 状況 | 型 |
|---|---|
| 既に Looker/dbt がある | それを意味層としてエージェントに経由させる（生 Text-to-SQL を避ける） |
| エージェントを量産したい | 1つずつ個別デプロイ（Cloud Run＋Agent Engine）で「作って壊せる」に |
| レビューがボトルネック | PR タグでプレビュー環境を即起動 |
| モデル/プロンプト変更が怖い | 評価環境（リグレッションテスト）を先に用意する（タイミーの積み残し＝先回りすべき所） |
参考リンク¶
- Timee Product Team Blog「社内AIエージェントを支える開発プラットフォームの紹介」（2025-12-18）: https://tech.timee.co.jp/entry/ai-agent-platform
- 登壇「作って終わりにしない タイミーのセマンティックレイヤー育成の現在地」: https://speakerdeck.com/chanyou0311/zuo-tutezhong-warinisinai-taiminosemanteitukureiyayu-cheng-noxian-zai-di
- 「LookerとADKで作る社内AIエージェント」: https://speakerdeck.com/chanyou0311/lookertoadkdezuo-rushe-nei-aieziento
- Findy イベント: https://findy.connpass.com/event/395577/
作成: 2026-07-24 ／ 最終更新: 2026-07-24