タクシーアプリ『GO』の実践的データ活用

本資料はGO のデータ基盤の全容と実践的なデータ活用事例を紹介しています。

具体的には、以下の７つの工夫点を紹介しています。
1.RDBのデータ収集はシンプルに。難しいCDCはやらない。
2.車載デバイスのデータはProtobuf + Zstandardで極限まで圧縮して扱う。
3.SQLの開発はdbtではなく敷居の低いDataformを採用
4.Lookerだけだと提供が遅くなるため、 Streamlitやコネクテッド シートを使い分ける
5.ローカルPCで本番のデータを扱えるStreamtlit開発環境を整備
6.リネージ管理は100点を目指さない
7.メタデータカタログへはすぐに飛べるようにBigQueryのUIを改造

最後に、今チャレンジしているText to SQLの取り組みの紹介もしています

Transcript

1. Confidential © GO Inc. 1 2026/5/29 GO株式会社 データインテリジェンス部　部長 AI技術開発部　 GM 渡部　徹太郎 タクシーアプリ『 GO』の 実践的データ活用 Google Cloud Data & AI Summit '26 Spring
2. © GO Inc. Confidential 2 • 渡部徹太郎（わたなべてつたろう） • 職歴： ◦ 野村総合研究所→リクルートテクノロジーズ→GO株式会社 • 仕事 ◦ データ活用部隊の組織長 ◦ データ基盤管理グループのマネージャ ◦ 技術勉強会メディア「GO TechTalk」の主催 • 趣味 ◦ ギター（会社の軽音部） ◦ ゲーム（最近はストリートファイター６） ◦ 麻雀 ◦ 自宅サーバ 自己紹介 本３冊書いています @fetarodc
3. © GO Inc. Confidential 3 • 会社説明 • データ活用全体像 • 実践的な7つの工夫 ◦ データ収集、データ加工、データ活用、データ管理で工夫を説明 • チャレンジしていること ◦ Text to SQL • まとめ アジェンダ
4. © GO Inc. Confidential 4 会社説明 1
5. © GO Inc. 5
6. © GO Inc. Confidential 3,500万DL突破のNo.1*タクシーアプリ。 全国47都道府県と最大級のエリア展開。 ※Sensor Tower調べ - タクシー配車関連アプリにおける、日本国内ダウンロード数（ App Store/Google Play合算値） - 調査期間： 2020年10月1日~2026年3月31日 6 タクシーアプリ『 GO』とは？
7. © GO Inc. Confidential 7 タクシーアプリ『 GO』はユーザーとタクシーのマッチングプラットフォームです。 ドライバーさんが使う業務アプリケーションをハードウェア丸ごと設計して導入しています。 実はハードウェアに強い会社 ※地域によって車載構成が異なる可能性　※ソフトメーターは最短で 2025年以降の市場投入 ユーザアプリだけでなくドライバー向けアプリも開発 ① 乗務員端末 ② 決済機能付きサイネージ端末 ① ドライバー向け 端末 注文を取る 連絡を取る 送迎する 決済する
8. © GO Inc. Confidential 8 様々なサービスを展開 高級車　『GO PREMIUM』 相乗り　『GOエコノミー』 法人向け 広告事業
9. © GO Inc. Confidential 2024年12月、米国Alphabet傘下のWaymo社及び日本交通と、 Waymoの自動運転技術 「Waymo Driver」のテストを実施するため、戦略的パートナーシップを締結。 初期フェーズは 2025年より東京都心にて、日本交通の乗務員が Waymoの車両を運転し、 Waymoの自 動運転技術を東京の公道に導入するためのテストを実施中。 9 自動運転タクシーに関する取り組み
10. © GO Inc. Confidential 10 データ活用全体像 2
11. © GO Inc. Confidential タクシーアプリ『 GO』におけるデータ活用の全体像 データ基盤 バ ッ ク エ ン ド 地図 天気・ 電車遅延 ドライバー アプリ ユーザアプリ 1日23億レコードの車両データ 3500万ダウンロードのアプリデータ ※非圧縮 1.意思決定で利用 2. データプロダクト 11 データ量：8PB(ペタバイト) テーブル数：78万 ... 外部データ
12. © GO Inc. Confidential 12 • KPIモニタリング ◦ 主要KPI(売上やアプリでタクシーを呼んだ数等 )を毎朝全社員に速報レポート。 • 効果検証 ◦ 機能改善の効果検証： A/Bテストの結果は良好か。リリース後は KPIがどれだけ改善 したか。 ◦ マーケティングの効果検証：配布したクーポンの効果はあったか。 • 基礎分析 ◦ タクシーが不足しているエリアはどこか。 • 社外向けデータ提供 ◦ タクシー会社向けのレポート。国や自治体へのレポート • 開発支援 ◦ システム障害の統計的分析 • 意思決定で利用する例
13. © GO Inc. Confidential 13 • 到着時間予測 ◦ A地点からB地点に行くまでにどれだけ時間がかかるか。 • 供給・需要予測 ◦ ユーザーの需要と、タクシーの供給量を時空間的に把握。 ◦ これまでの実績に加え、リアルタイムな天気なども考慮。 • ユーザーとタクシーのマッチング • マッチングしやすくなるような場所に車両を誘導 • 予約枠の調整 • プレミアムチャージなどの料率算出 データプロダクトの例
14. © GO Inc. Confidential 14 システム構成 バックエンド データ基盤 バック エンド (k8s) 生データ (BigQuery) フロント エンド ユーザー アプリ 車載 デバイス 分析 ログ データ加工処理 (Dataform, Python + GKE) データ ウェア ハウス (BigQuery) データ マート (BigQuery) ビジ ネス ロジ ック 車載位置 ログ Looker 品質/リネージ/メタデータ管理 (Dataform Assertion,Knowledge Catalog) Streamlit (on GKE) コネクテッド シート 収集 (Dataflow) キュー (Cloud Pub/Sub) 収集 (自作) アナリスト サイエンティ スト 受益者 100名 RDB (RDS Aurora) RDB (Cloud SQL) ジョブコントローラ (Managed Service for Apache Airflow) バックエンドエンジニア + SRE データエンジニア (MLエンジニア) データエンジニア (アナリティクスエンジニア ) 意思決定で利用 データプロダクト AKE(k8s) 特徴量・ 推論値 ストア (Feast) コンテナ ML / アルゴ リズム バック エンド 収集 外部 データ 外部 データ
15. © GO Inc. Confidential 15 実践的な7つの工夫 3
16. © GO Inc. Confidential 16 • データ収集 ◦ 1.RDBのデータ収集はシンプルに ◦ 2.車載デバイスデータの収集は極限まで圧縮 • データ加工 ◦ 3.SQLの開発は敷居の低いDataformを採用 • データ活用 ◦ 4.Looker, Streamlit, コネクテッド シートを使い分ける ◦ 5.Streamtlitを安全に活用させるための基盤を用意 • データ管理 ◦ 6.リネージ管理は100点を目指さない ◦ 7.メタデータカタログはすぐに使えて気軽に編集できるようにする 色んな実践的な工夫をしています
17. © GO Inc. Confidential 17 1.RDBのデータ収集はシンプルに バックエンド データ基盤 バック エンド (k8s) 生データ (BigQuery) フロント エンド ユーザー アプリ 車載 デバイス 分析 ログ データ加工処理 (Dataform, Python + GKE) データ ウェア ハウス (BigQuery) データ マート (BigQuery) ビジ ネス ロジ ック 車載位置 ログ Looker 品質/リネージ/メタデータ管理 (Dataform Assertion,Knowledge Catalog) Streamlit (on GKE) コネクテッド シート 収集 (Dataflow) キュー (Cloud Pub/Sub) 収集 (自作) アナリスト サイエンティ スト 受益者 100名 RDB (RDS Aurora) RDB (Cloud SQL) ジョブコントローラ (Managed Service for Apache Airflow) バックエンドエンジニア + SRE データエンジニア (MLエンジニア) データエンジニア (アナリティクスエンジニア ) 意思決定で利用 データプロダクト AKE(k8s) 特徴量・ 推論値 ストア (Feast) コンテナ ML / アルゴ リズム バック エンド 収集 外部 データ 外部 データ
18. © GO Inc. Confidential 18 • ETL製品は辞めた ◦ 大量のプラグインがあってもほとんど使わない ◦ ソースコードレベルでデバッグできない ◦ 費用がかかる • リアルタイムデータ連携 CDC(Change Data Capture)も辞めた ◦ 理由は、システム構成が複雑になるため、加えて、同期が外れたときの復旧が大変すぎるため。 • 最終的に、シンプルな自作プログラムで、１時間に１回のデータ収集する方式に落ち着いた ◦ Cloud SQLのデータ収集は、BigQueryの連携クエリ機能を用いて、 SELECT INSERT ◦ Amazon Aurora のデータは、データをS3にダンプし、PythonでBigQueryへ挿入 ◦ →障害はほぼ無く安定的な運用ができている • 1時間に1回のデータ収集で間に合わない場合は、 DBではなく、リアルタイムに収集しているログのデータを使って実現す る 1.RDBのデータ収集はシンプルに 参考： AWS Aurora S3 Export を利用した、負荷をかけない GCP BigQuery へのデータ連携
19. © GO Inc. Confidential 19 2.車載デバイスデータの収集は極限まで圧縮 バックエンド データ基盤 バック エンド (k8s) 生データ (BigQuery) フロント エンド ユーザー アプリ 車載 デバイス 分析 ログ データ加工処理 (Dataform, Python + GKE) データ ウェア ハウス (BigQuery) データ マート (BigQuery) ビジ ネス ロジ ック 車載位置 ログ Looker 品質/リネージ/メタデータ管理 (Dataform Assertion,Knowledge Catalog) Streamlit (on GKE) コネクテッド シート 収集 (Dataflow) キュー (Cloud Pub/Sub) 収集 (自作) アナリスト サイエンティ スト 受益者 100名 RDB (RDS Aurora) RDB (Cloud SQL) ジョブコントローラ (Managed Service for Apache Airflow) バックエンドエンジニア + SRE データエンジニア (MLエンジニア) データエンジニア (アナリティクスエンジニア ) 意思決定で利用 データプロダクト AKE(k8s) 特徴量・ 推論値 ストア (Feast) コンテナ ML / アルゴ リズム バック エンド 収集 外部 データ 外部 データ
20. © GO Inc. Confidential 20 2.車載デバイスデータの収集は極限まで圧縮 参考：車両位置情報データの圧縮による Cloud Pub/Subのコスト削減 - Speaker Deck Dataflow Dataflow BigQuery Streaming insert Cloud Pub/Sub • 車載デバイスの位置状態情報は大量。 1日23億レコード。 • クラウドコストの高さが課題になっていた • そこで、JSONのデータをProtobuf + Zstandardに圧縮することで最適化 ◦ ZstandardはMeta社製の可逆圧縮アルゴリズムで、 GZIPと同程度の圧縮でより高速に計算できる ◦ Protobufは可変長のバイナリデータで、データを追記できるのでストリーミング処理との相性が良い ◦ JSONよりも1/15のデータ量になる JSON
21. © GO Inc. Confidential 21 3.SQLの開発は敷居の低い Dataformを採用 バックエンド データ基盤 バック エンド (k8s) 生データ (BigQuery) フロント エンド ユーザー アプリ 車載 デバイス 分析 ログ データ加工処理 (Dataform, Python + GKE) データ ウェア ハウス (BigQuery) データ マート (BigQuery) ビジ ネス ロジ ック 車載位置 ログ Looker 品質/リネージ/メタデータ管理 (Dataform Assertion,Knowledge Catalog) Streamlit (on GKE) コネクテッド シート 収集 (Dataflow) キュー (Cloud Pub/Sub) 収集 (自作) アナリスト サイエンティ スト 受益者 100名 RDB (RDS Aurora) RDB (Cloud SQL) ジョブコントローラ (Managed Service for Apache Airflow) バックエンドエンジニア + SRE データエンジニア (MLエンジニア) データエンジニア (アナリティクスエンジニア ) 意思決定で利用 データプロダクト AKE(k8s) 特徴量・ 推論値 ストア (Feast) コンテナ ML / アルゴ リズム バック エンド 収集 外部 データ 外部 データ
22. © GO Inc. Confidential 22 3.SQLの開発は敷居の低い Dataformを採用 • Dataformの特徴 ◦ SQLをGitHubでバージョン管理できる ◦ 生成したTable/View間の依存関係を宣言できる ◦ 日々継ぎ足す増分テーブルをフレームワークとして表現できる ◦ SQLのテストが書ける ◦ SQLそのものをJavascriptで生成できる。 • dbtではなくDataformを使っている理由 ◦ 全社員がGoogleアカウントを保持し、 Google Cloudで生活しているため、 dbtよりDataformの方が親和 性が高いため • その他 ◦ スケジュール実行は Dataformの機能は利用していない ▪ 理由は、Dataformの処理とDataform外の処理(例えばPythonの処理)に順序の依存関係を持た せたいため。Managed Service for Apache Airflowを利用 参考：dbt と Dataform を比較して Dataform を利用することにしました
23. © GO Inc. Confidential 23 4.Looker, Streamlit, コネクテッド シートを使い分ける バックエンド データ基盤 バック エンド (k8s) 生データ (BigQuery) フロント エンド ユーザー アプリ 車載 デバイス 分析 ログ データ加工処理 (Dataform, Python + GKE) データ ウェア ハウス (BigQuery) データ マート (BigQuery) ビジ ネス ロジ ック 車載位置 ログ Looker 品質/リネージ/メタデータ管理 (Dataform Assertion,Knowledge Catalog) Streamlit (on GKE) コネクテッド シート 収集 (Dataflow) キュー (Cloud Pub/Sub) 収集 (自作) アナリスト サイエンティ スト 受益者 100名 RDB (RDS Aurora) RDB (Cloud SQL) ジョブコントローラ (Managed Service for Apache Airflow) バックエンドエンジニア + SRE データエンジニア (MLエンジニア) データエンジニア (アナリティクスエンジニア ) 意思決定で利用 データプロダクト AKE(k8s) 特徴量・ 推論値 ストア (Feast) コンテナ ML / アルゴ リズム バック エンド 収集 外部 データ 外部 データ
24. © GO Inc. Confidential 24 4.Looker, Streamlit, コネクテッド シートを使い分ける コネクテッド シート ・Google Cloudの有償BIツール ・セマンティックレイヤーがある ・多次元分析ができる ・Pythonで簡単に可視化Webが 作れる ・インタラクティブなJupyter Notebook ・Google スプレッドシートの コネクテッド シート機能で直接 BigQueryのデータを見れる 各ツールの特徴
25. © GO Inc. Confidential 25 4.Looker, Streamlit, コネクテッド シートを使い分ける Looker Streamlit コネクテッド シート ユーザ自身で多次元分析 ◯　Looker Explorer ☓ △　ピボットテーブル 指標にガバナンスを効かせ る ◯　LookMLで指標を統一 ☓ ☓ 地理空間データの可視化 △ ◯ ☓ 値の加工の柔軟性 △　SQLのみ ◯　Pythonで計算可能 △　SQLのみ　 入力して絞り込み △　基本的なフィルタのみ ◎　豊富な入力手段 ☓ 画面に表示できるデータ量 ☓　5000件 ◎　制限なし ◯　100万行 開発容易性 ☓　LookMLのハードルが高い ◯　生成AIの力を借りれる ◎　SQLを書くだけ Slack定期配信 ◯ ◯　独自に作り込み ◯　独自に作り込み 各ツールの得意不得意
26. © GO Inc. Confidential 26 4.Looker, Streamlit, コネクテッド シートを使い分ける Looker Streamlit コネクテッド シート ・会社の重要指標のモニタ リング ・ビジネス担当に自分で多 次元分析をしてほしい場合 ・地理空間データを用いたデバッ グツール ・5000件以上扱う必要のあるログ の調査など ・SQLでは実現ができない計算 ・ボタンや入力フォームなどUI部品 を使いたい場合 ・とりあえず数字を出す ・出した数字にコメントを書いた り、スプレッドシートで加工したい 場合 各ツールのユースケース
27. © GO Inc. Confidential 27 5.Streamtlitを安全に活用させるための基盤を用意 バックエンド データ基盤 バック エンド (k8s) 生データ (BigQuery) フロント エンド ユーザー アプリ 車載 デバイス 分析 ログ データ加工処理 (Dataform, Python + GKE) データ ウェア ハウス (BigQuery) データ マート (BigQuery) ビジ ネス ロジ ック 車載位置 ログ Looker 品質/リネージ/メタデータ管理 (Dataform Assertion,Knowledge Catalog) Streamlit (on GKE) コネクテッド シート 収集 (Dataflow) キュー (Cloud Pub/Sub) 収集 (自作) アナリスト サイエンティ スト 受益者 100名 RDB (RDS Aurora) RDB (Cloud SQL) ジョブコントローラ (Managed Service for Apache Airflow) バックエンドエンジニア + SRE データエンジニア (MLエンジニア) データエンジニア (アナリティクスエンジニア ) 意思決定で利用 データプロダクト AKE(k8s) 特徴量・ 推論値 ストア (Feast) コンテナ ML / アルゴ リズム バック エンド 収集 外部 データ 外部 データ
28. © GO Inc. Confidential 本番GKE 28 5.Streamtlitを安全に活用させるための基盤を用意 参考：Streamlit ホスティング基盤をどのように作ったか 開発・プレビュー環境 ローカルで、本番データを用いた開 発ができる 本番環境 認証・認可・監査の 要件を満たした環境 ローカルPC 本番 BigQuery ソースコード プレビューGKE ブラウザ Web App IDE Web App IAP 全社 認証 開発 SKAFFOLD Port forward http://localhost:8501 認可・監査 (nginx) ソースコード ソースコード 監査 ログ CI/CD (GitHub) 手元の変更を 即時反映 localhostにア クセスすれば プレビューが見 れる デプロイ sync 30人の開発者 250+の画面 生成AI使える
29. © GO Inc. Confidential 29 6.リネージ管理は１００点を目指さない バックエンド データ基盤 バック エンド (k8s) 生データ (BigQuery) フロント エンド ユーザー アプリ 車載 デバイス 分析 ログ データ加工処理 (Dataform, Python + GKE) データ ウェア ハウス (BigQuery) データ マート (BigQuery) ビジ ネス ロジ ック 車載位置 ログ Looker 品質/リネージ/メタデータ管理 (Dataform Assertion,Knowledge Catalog) Streamlit (on GKE) コネクテッド シート 収集 (Dataflow) キュー (Cloud Pub/Sub) 収集 (自作) アナリスト サイエンティ スト 受益者 100名 RDB (RDS Aurora) RDB (Cloud SQL) ジョブコントローラ (Managed Service for Apache Airflow) バックエンドエンジニア + SRE データエンジニア (MLエンジニア) データエンジニア (アナリティクスエンジニア ) 意思決定で利用 データプロダクト AKE(k8s) 特徴量・ 推論値 ストア (Feast) コンテナ ML / アルゴ リズム バック エンド 収集 外部 データ 外部 データ
30. © GO Inc. Confidential 30 • リネージ管理とは、データ加工パイプラインにおいて、データ間の依存関係を把握すること • 機械的に分かる、DataformとLookerは自動計算 ◦ Dataformは、依存関係定義からテーブル間の依存関係を抽出 ◦ LookerはLookMLから、テーブルとLookの依存関係を抽出 • 機械的に分からない、Streamlitやコネクテッド シートは、重要なものだけ、作者にヒアリング ◦ データ基盤のアウトプットに重要度をつけ、重要なものだけ、リネージを管理する ◦ 作者に「何のテーブル使ってる？」と聞く 6.リネージ管理は１００点を目指さない tableA tableB tableX tableY Look Look ML Dataform Streamlit Streamlit作者 ソースコードの SQL Dataform tableC
31. © GO Inc. Confidential 31 7.メタデータカタログはすぐに使えて気軽に編集できる バックエンド データ基盤 バック エンド (k8s) 生データ (BigQuery) フロント エンド ユーザー アプリ 車載 デバイス 分析 ログ データ加工処理 (Dataform, Python + GKE) データ ウェア ハウス (BigQuery) データ マート (BigQuery) ビジ ネス ロジ ック 車載位置 ログ Looker 品質/リネージ/メタデータ管理 (Dataform Assertion,Knowledge Catalog) Streamlit (on GKE) コネクテッド シート 収集 (Dataflow) キュー (Cloud Pub/Sub) 収集 (自作) アナリスト サイエンティ スト 受益者 100名 RDB (RDS Aurora) RDB (Cloud SQL) ジョブコントローラ (Managed Service for Apache Airflow) バックエンドエンジニア + SRE データエンジニア (MLエンジニア) データエンジニア (アナリティクスエンジニア ) 意思決定で利用 データプロダクト AKE(k8s) 特徴量・ 推論値 ストア (Feast) コンテナ ML / アルゴ リズム バック エンド 収集 外部 データ 外部 データ
32. © GO Inc. Confidential 32 • メタデータ管理の方針 ◦ 気軽に編集できるし、壊しても戻せる ▪ メタデータの本体はGitHubにYAMLファイルで管理し、それをKnowledge CatalogやBigQueryのDescriptionに転 記 ◦ すぐに使える ▪ BigQueryのUIを改造し、メタデータカタログへのリンクが出るようにした Chrome 拡張 Tampermonkeyを用いて、jsを書き換え、リンクを表示 7.メタデータカタログはすぐに使えて気軽に編集できる xxxx.xxxx.xxx カタログへ のリンク 定義YAML へのリンク
33. © GO Inc. Confidential 33 チャレンジしていること 4
34. © GO Inc. Confidential レポジトリ上のSQL資産 34 • メタデータだけでは不十分。理由は同じデータが複数テーブルに存在するため • SQL資産や、定期ジョブなどで使われる信頼できるSQLの実行履歴や、RAGとして整備 • MCPサーバを立てて生成VSCode + Github Copilotから利用 Text to SQL 信頼できる SQL実行履歴 Dataform の SQLX Streamlit のSQL BigQuery RAG DB メタデータ クロール 検索 MCP サーバ アナリストの ワークスペース のSQL VSCode + GitHub Copilot
35. © GO Inc. Confidential 35 まとめ 5
36. © GO Inc. Confidential 36 • タクシーアプリ『GO』はユーザとタクシーのマッチングプラットフォーム • ユーザアプリと車載デバイスのデータを集め、データ基盤に格納 • 意思決定やデータプロダクトで利用 • 実践的な7つの工夫を紹介 ◦ 1.RDBのデータ収集はシンプルに。難しいCDCはやらない。 ◦ 2.車載デバイスのデータはProtobuf + Zstandardで極限まで圧縮して扱う。 ◦ 3.SQLの開発はdbtではなく敷居の低いDataformを採用 ◦ 4.Lookerだけだと提供が遅くなるため、 Streamlitやコネクテッド シートを使い分ける ◦ 5.ローカルPCで本番のデータを扱えるStreamtlit開発環境を整備 ◦ 6.リネージ管理は100点を目指さない ◦ 7.メタデータカタログへはすぐに飛べるようにBigQueryのUIを改造 • チャレンジしていること ◦ Text to SQL。SQL履歴やSQL資産をAIエージェントのコンテキストに与えるRAG+MCPを準備 まとめ
37. © GO Inc. Confidential 37 We are Hiring!
38. 文章・画像等の内容の無断転載及び複製等の行為はご遠慮ください。 Confidential © GO Inc.