Redashから脱却 - データ基盤移行を振り返る - 弁護士ドットコム株式会社 Creators’ blog

この記事は、弁護士ドットコム Advent Calendar 2025 の 5日目の記事です。

こんにちは。クラウドサイン SRE チームの高橋と申します。

長年利用していたデータ分析ツール「Redash」の廃止に伴い、BigQuery Web コンソールや Trocco への移行対応を実施しました。本記事では、移行の背景から移行プロセス、直面した課題とその解決策、そして学びを振り返ります。これから同様の移行を検討している方々の参考になれば幸いです。

移行の背景
移行プロセス
主な課題
課題に対する解決策
- 権限整備
- クエリ移行
学び
まとめ

移行の背景

データ分析・ガバナンスの改善対応の一環として、全社的にデータ分析ツールは Tableau に集約していく方針になり、長らく利用していた Redash を廃止することにしました。

廃止に伴い、クエリベースでデータ詳細を参照したい人（主にエンジニア）向けには BigQuery Web コンソールを利用してもらう方針にしました。また Redash API によるデータ転送も利用されていたため、すでに他のデータソースからデータ基盤への転送で利用している Trocco へ集約する方針にしました。

移行プロセス

移行は以下の5つのステップで実施しました。

1. Redash 利用状況調査・リストアップ

直近 3 か月に絞り、Redash の DB（PostgreSQL）から対象を抽出しました。

操作ユーザー：約 80
保存クエリ：約 300
API：約 130

2. ヒアリング

クエリ・API 作成者および利用者に、利用状況・頻度や別ツールの移行状況を確認し整理しました。

3. 運用整備

BigQuery Web コンソール簡易操作マニュアル作成
権限付与用 Google グループ整備・操作検証
権限付与の依頼用ワークフロー整備

4. 移行対応

クエリ → BigQuery view およびテーブル関数：約 60 件
API → Trocco：約 10 件
移行後の利用者への結果確認

5. 廃止対応

AWS 上で稼働していた各種リソースを廃止しました。

Redash の DB のバックアップを取得
EC2・RDS などから対象リソースを削除

主な課題

移行プロセスの中で以下の3つの課題に直面し、移行スケジュールが遅延する影響を及ぼしました。

ヒアリングが大変

移行対象の選定に時間がかかる

長年に渡って利用されていたため、作成されたクエリ・ダッシュボード・API の総数はとても多かったです。業務フロー上利用されているもの、過去に利用されていたが現在は利用されていないもの、個人利用など判別がつかないため、各所にヒアリングする必要がありました。
クエリ・API 作成者が退職済みのものも多く、利用者だけでは利用状況や移行要否を確認し切れないものが複数ありました。
Redash 利用者はエンジニア・システム開発に携わるチームだけでなく、ビジネスサイドの事業部・チームにも渡るため、広く確認が必要でした。

権限整備が大変

統制された操作権限と、Redash 利用者への配慮との調整が難しい

データ基盤の 3 層構成に合わせた権限である必要がありました。

3層構成イメージ図

datalake 層
- ほぼ生の形式のデータを保持
- アクセス権限：管理者のみ
datawarehouse 層
- datalake 層のデータをクリーニング・構造化・マスキングして変換した中間テーブルを保持
- アクセス権限：エンジニア
datamart 層
- datawarehouse 層のデータをさらに集計・加工して変換した、特定のビジネス用途に限定されたデータを保持
- アクセス権限：エンジニア以外

Redash で利用されていたクエリは、エンジニア以外も利用していました。

上記 3 層構成だと、エンジニア以外の利用は datamart 層からのアクセス
クエリから参照するデータは、datawarehouse 層のテーブル群が相当

Redash クエリの移行が大変

Redash で分析できていたことを、極力制限のない形で BigQuery にて再現することが難しい

Redash で利用できたデータソースが複数あり、それを BigQuery に統一する必要がありました。

BigQuery
MySQL：BigQuery とテーブルやデータは同じ。BigQuery 利用以前に利用していた歴史的経緯で残存
Python：上記データソースからの取得データを加工

Redash の機能を活用したクエリを BigQuery で再現する必要もありました。

クエリキャッシュ：他クエリの実行結果のキャッシュを他のクエリで利用
クエリパラメータ：動的なクエリの実行

課題に対する解決策

課題に対して以下のアプローチで移行を進めることができました。

権限整備

承認済み view を利用して datawarehouse 層のデータセットに対して datamart 層から参照できるようにしました。

（参考：Google 公式ドキュメント）

datamart 層に移行用のデータセットを作成。そこに Redash クエリを再現した view を作成
datawarehouse 層のデータセットに対して、datamart 層の移行用データセットからの参照権限を付与

クエリ移行

Redash の DB（PostgreSQL）からクエリデータを CSV で抽出し変換ルールに則って AI による一括変換を実施しました。

markdown に変換ルールを記載

    # MySQL → BigQuery 変換ルール

    - クエリに記載されているテーブルは、WITH句でエイリアスを指定する
      - 例：`WITH table AS (SELECT * FROM dataset_name.table)`
    - フィールド名の指定部分はダブルクォートではなくバッククォートに変換する
      - 例：`SELECT table.id AS `テーブルID``
    - 日付関数の変換
      - `DATE_FORMAT(date, format)` → `FORMAT_DATE(format, date)`
    ...

CSV とルールファイルをインプットして、MySQL から BigQuery へのクエリ変換を実施
実行エラー・クエリ結果が変換前と異なる場合は、該当箇所をレビューすることで変換ルールに追記され、精度が向上
Python による加工やクエリキャッシュ利用分も、適宜情報を渡すことで 1 つのクエリで収まるよう対応

「テーブル関数」を利用して Redash のクエリパラメータを再現しました。

（参考：Google 公式ドキュメント）

    CREATE OR REPLACE TABLE FUNCTION `project-name.dataset-name.function-name`(TARGET_TEAM_ID STRING)
    OPTIONS (description="チーム別の契約完了までの平均日数を分析するテーブル関数\n\n【パラメータ】\n- TARGET_TEAM_ID: 分析対象のチームID（例: 'hogehoge-hoge-hoge'）") AS (
    {実行したいクエリ}
    );

上記権限整備との兼ね合いで運用負荷が大きいと判断し、クエリ移行分でのみ利用し、移行後の関数追加は NG としました。