Redashとは？SQLでダッシュボードを作るOSS BIの構成とDocker導入手順、後継選びの判断

Redashは、SQLで書いたクエリの結果を表やグラフにし、ダッシュボードとして社内で共有するためのオープンソースのBIツールです。この記事では2026年10月時点の最新版v26.9.0を前提に、クエリから可視化・ダッシュボード・アラートへつながる仕組み、公式のsetupスクリプトでDocker Composeに建てる手順、クエリパラメータとREST APIで結果を取り出す実装を順に追います。ホスト版の終了から再始動までの開発体制とv26.9.0の破壊的変更も確かめたうえで、Metabase・Apache Superset・Databricks SQLとの選び分けを言い切ります。

まとめ：RedashはSQLを書ける人がクエリと結果を共有するための軽量なOSS BI

Redashの中心はクエリエディタです。データベースに直接SQLを投げ、その結果に可視化を重ね、複数の可視化を1枚のダッシュボードに並べます。定期実行とアラート、REST APIも同じクエリを起点に動くため、「SQLを書ける人が書いたクエリを、書けない人にも見せる」ための道具だと捉えると理解が早いでしょう。

ホスト版のapp.redash.ioは2021年11月30日に終了し、現在はセルフホストのOSS版だけが残っています。v10.1.0のあと約3年は安定版が出ませんでしたが、2025年1月のv25.1.0から公開が再開し、2026年9月24日にv26.9.0が出ました。今から建てるならv26.9.0を選び、13件のセキュリティ修正を含むこの版より古いものは使わないと判断してください。

採用してよいのは、利用者の中心がSQLを書けるエンジニアや分析者で、自社でサーバを運用でき、クエリの共有が主な目的のときです。SQLを書かない現場の担当者に自分で集計させたいなら、Redashは合いません。

Redashの定義とクエリ・可視化・ダッシュボード・アラートが連なる基本の仕組み

まず、Redashがどの単位でデータを扱うのかを押さえます。画面の操作もAPIも、この単位の上に組み立てられています。

クエリエディタで書いたSQLの結果を可視化とダッシュボードへ積み上げる流れ

Redashの最小単位はクエリです。クエリエディタでSQLを書いて実行すると、結果はRedash側のメタデータ用データベースに保存され、そのクエリに表・折れ線・棒・円・ピボットなどの可視化を何個でもぶら下げられます。ダッシュボードは、別々のクエリにぶら下がった可視化をウィジェットとして並べた画面です。

クエリには実行スケジュールを付けられます。毎朝6時に売上集計を走らせておけば、ダッシュボードを開いた人は保存済みの結果を見るだけで済み、そのたびに本番データベースへ重いSQLが飛ぶことはありません。結果の値がしきい値を超えたらメールやSlackへ通知するアラートも、クエリ単位で設定します。

つまり、Redashで作る資産の実体はSQLそのものです。BIツール全般の役割と選定軸と照らすと、Redashはドラッグ操作で分析する製品群ではなく、SQLを共有・再利用する側に寄った製品だと分かります。

35種類超のデータソースに直接つなぐクエリランナーとBSD-2ライセンスの範囲

GitHubのREADMEは、SQLとNoSQLを合わせて35種類を超えるデータソースに対応すると記しています。PostgreSQL・MySQL・BigQuery・Snowflake・Amazon Athena・Databricksなどが並び、データソースごとの接続部分はクエリランナーと呼ばれるPythonのモジュールで実装されています。v26.9.0ではCloudflare D1のクエリランナーが加わりました。

Redashはデータを取り込んで独自の形式に変換しません。毎回データソースへクエリを投げ、返ってきた結果だけを保存します。そのため、データの整形はデータベース側のビューやdbtなどで済ませておき、Redashは見せる層に徹させる設計が素直です。

ライセンスはBSD-2-Clauseです。商用利用や社内での改変に制限は少なく、著作権表示を残せば再配布もできます。ホスト版が終わった現在、入手できるRedashはこのOSS版だけです。

Redashの実行処理とデータ保存を担うコンテナの内訳とサービス構成

構成要素はserver・scheduler・worker・PostgreSQL・Redisで、処理を実行する側とデータを保存する側に分かれます。

公式setupリポジトリのcompose.yamlを読むと、Redashは役割の違う複数のコンテナで動いていることが分かります。

設計で優先して見るべきはworkerの数です。重いクエリが同時に走ると、adhoc_workerの2つが埋まった時点で画面からの実行は順番待ちになります。利用者が増えたらまずここを増やし、それでも足りなくなった段階でサーバの台数を検討します。

Redashの開発体制とバージョン系列、2026年10月時点で選ぶv26.9.0の位置づけ

Redashを長く使えるかどうかは、機能よりも開発の継続性で決まります。採用前に、ここ5年の経緯を確認しておきます。

Databricksによる買収と2021年11月のホスト版終了までの経緯

終了したホスト版の提供先はapp.redash.ioです。買収後のホスト版終了とOSS版の開発体制を分けて確認します。

Redashの開発元は、Databricksの2020年6月24日の発表でDatabricksの傘下に入りました。その後、公式のホスト版終了案内のとおり、app.redash.ioで提供していたホスト版は2021年11月30日で終了しています。理由は、Databricksの中でSQLアナリスト向けの体験に注力するためと説明されました。

同じ案内は、移行先として2つを示しています。Databricksを使っている利用者にはDatabricks SQL、それ以外のデータソースも必要な利用者にはセルフホストのOSS版です。移行用にredash-migrateというツールも用意されました。

この経緯から読み取れるのは、Redashに「お金を払えば運用を任せられる公式の受け皿」が今は無いという事実です。サーバ・バックアップ・更新はすべて自社の担当になります。

v10.1.0から3年空いた後のv25.1.0以降の再始動とリリース間隔の実績

GitHubのリリース一覧を2026年10月21日に確認すると、安定版の公開日は次のとおりです。

v10.1.0とv25.1.0の間は、安定版が1つも出ていません。版番号もこの再開を境に「年＋月」の形へ変わりました。2025年以降はおおむね半年強の間隔で公開が続いており、リポジトリはアーカイブされず、2026年10月にもコードが更新されています。

ここから導ける判断は2つです。開発は止まっていないので、既存のRedashを今すぐ捨てる理由はありません。一方で、3年間の空白があった事実は残るため、新規採用ではSQLとダッシュボード定義をエクスポートできる状態を保ち、乗り換えの余地を残しておく運用を勧めます。

公式setupでRedashの検証環境をDocker Composeに建てる手順

ここからは手を動かします。公式のsetupリポジトリは、1台のLinuxサーバにDockerとDocker Composeを入れ、Redash一式を起動するスクリプトを配布しています。

4GB以上のRAMを持つLinuxサーバでsetup.shを実行し初期化するまでの手順

公式のセットアップ手順は、基本構成で最低4GBのRAMを推奨しています。READMEに載っている対応OSはUbuntu 20.04・22.04、Debian 12、RHEL・Rocky・Alma Linuxの8系と9系などで、スクリプトはまっさらなサーバで実行する前提です。

# root で実行する
git clone https://github.com/getredash/setup.git
cd setup

# 版を固定して導入する（省略すると最新の安定版を自動で選ぶ）
./setup.sh --version 26.9.0

# 起動したコンテナを確認する
docker compose -f /opt/redash/compose.yaml ps

スクリプトはDockerを入れ、/opt/redashを作り、データベースを初期化してから全コンテナを起動します。ブラウザでサーバのIPを開くと管理者アカウントの作成画面が出るので、ここで登録するのが最初のユーザーです。初回の表示はPythonのコンパイルで時間がかかりますが、2回目からは速くなります。

--versionを付けておくと、検証環境と本番環境で同じ版をそろえられます。--overwriteは既存のenvファイルとデータベースを消して入れ直すオプションなので、本番サーバでは使いません。

/opt/redash/envの秘密鍵とREDASH_HOST・メール設定の追加

setup.shは、Cookieの署名鍵やデータベースの暗号化鍵を乱数で生成し、/opt/redash/envに書き出します。この2つの鍵を失うと、保存済みのデータソース接続情報を復号できなくなります。サーバを作り直す前に、envファイルを必ず別の場所へ控えてください。

# /opt/redash/env（setup.sh が生成する主な行）
REDASH_COOKIE_SECRET=（32文字の乱数）
REDASH_SECRET_KEY=（32文字の乱数）
POSTGRES_PASSWORD=（32文字の乱数）
REDASH_ENFORCE_CSRF=true

# 自分で追記する行（招待メールやパスワード再設定のリンクに使う）
REDASH_HOST=https://redash.example.co.jp
REDASH_MAIL_SERVER=smtp.example.co.jp
REDASH_MAIL_PORT=587
REDASH_MAIL_USE_TLS=true
[email protected]

envを変えたらdocker compose up -dで反映します。公式手順の注意事項は、restartだけでは環境変数が読み直されないという点です。設定後はdocker compose run --rm server manage send_test_mailでテストメールを送り、届くことを確かめます。

クエリパラメータとREST APIで社内システムからRedashの結果を取り出す実装

Redashは見るだけの道具にとどまりません。パラメータ付きのクエリを、ほかの社内システムからAPIで呼び出すこともできます。

二重波括弧で書くクエリパラメータの型と共有ダッシュボードで使えないText型

クエリパラメータの公式解説によると、SQLの中で二重波括弧に囲んだ文字列がパラメータになります。型はText・Number・Date・Date and Time・Date and Time（秒付き）・Dropdown Listの6種類で、日付範囲を受けるときは.startと.endで両端を参照します。

-- 期間と店舗を画面から切り替えられる売上集計
SELECT order_date, SUM(amount) AS sales
FROM orders
WHERE order_date BETWEEN '{{ period.start }}' AND '{{ period.end }}'
  AND store_id = {{ store_id }}
GROUP BY order_date
ORDER BY order_date;

注意が要るのはText型です。公式解説は、Text型を使うクエリはSQLインジェクションに対して安全でないため、埋め込みや共有ダッシュボードに使えないとしています。Dropdown Listも、内部での扱いはText型と同じです。社外や他部署に公開する画面では、店舗IDのような値はNumber型にし、選択肢は別のクエリから引くドロップダウンにします。

Query API KeyでPOSTしジョブをポーリングしてJSONを得る実装例

公式のAPI解説は、APIキーを2種類に分けています。持ち主と同じ権限を持つUser API Keyと、特定のクエリとその結果だけに触れるQuery API Keyです。外部のシステムに渡すのは、公式の推奨どおりQuery API Keyにします。

import time
import requests

BASE = "https://redash.example.co.jp"
QUERY_ID = 42
HEADERS = {"Authorization": "Key YOUR_QUERY_API_KEY"}

# パラメータを付けて実行を依頼する（30分以内のキャッシュがあればそれを返す）
res = requests.post(
    f"{BASE}/api/queries/{QUERY_ID}/results",
    headers=HEADERS,
    json={"parameters": {"period": {"start": "2026-10-01", "end": "2026-10-20"}, "store_id": 3},
          "max_age": 1800},
).json()

if "job" in res:
    job_id = res["job"]["id"]
    while True:
        job = requests.get(f"{BASE}/api/queries/{QUERY_ID}/jobs/{job_id}", headers=HEADERS).json()["job"]
        if job["status"] == 3:  # 3 = SUCCESS
            result_id = job["query_result_id"]
            break
        if job["status"] in (4, 5):  # 4 = FAILURE, 5 = CANCELLED
            raise RuntimeError(job.get("error"))
        time.sleep(1)
    res = requests.get(
        f"{BASE}/api/queries/{QUERY_ID}/results/{result_id}.json", headers=HEADERS
    ).json()

rows = res["query_result"]["data"]["rows"]
print(len(rows), rows[:3])

実装でつまずきやすいのは結果の取り出し先です。公式解説は結果の取得先として/api/query_results/<id>を挙げていますが、認証処理のソースコードを読むと、Query API KeyはURLにクエリIDを含む経路でしか認可されません。上の例のように、ジョブも結果もクエリIDを含むURLで取りに行くと401を避けられます。max_ageを0にすると、キャッシュを使わず必ず再実行します。

v26.9.0へ上げる前に確かめる破壊的変更と自社で公開運用するときの設定

v26.9.0は13件のセキュリティ修正を含む版です。上げない選択肢はありませんが、上げると動かなくなるクエリや連携が出ます。

カスタムJSチャートの既定無効化と権限の厳格化で止まる既存クエリの洗い出し

v26.9.0のリリースノートは、破壊的変更を複数挙げています。影響が大きい順に並べると次のとおりです。

• Text型パラメータや宣言していないプレースホルダを使うクエリは、データソースへのフルアクセス権を持つ利用者しか実行できない
• カスタムJavaScriptのチャートは既定で無効になり、REDASH_FEATURE_ALLOW_CUSTOM_JS_VISUALIZATIONS=trueを設定しない限り描画されない
• SQLに付く注釈と実行ログの利用者識別子が、メールアドレスからuser_idに変わる
• ダッシュボードの公開共有を切り替えられるのは、オーナーと管理者だけになる
• DuckDBのデータソースから、ローカルファイルを読み書きするクエリが遮断される

実務では先頭の1件だけ先に調べれば足ります。閲覧専用の権限で使われているダッシュボードにText型のパラメータが含まれていると、上げた翌朝から利用者の画面がエラーになるためです。データベースのログを読んで利用者別の集計をしている連携があれば、3件目の変更にも合わせます。更新はメタデータDBのバックアップを取り、server・scheduler・全workerを同時に新しいイメージへ替え、docker compose run --rm server manage db upgradeでマイグレーションを流す順番です。

5000番の外部公開と初期設定のままの運用、漏えいしたAPIキーの放置

自社でRedashをインターネットに出すときに起きやすい失敗は3つあります。1つ目は、公式composeがserverの5000番もホストに公開している点を見落とし、nginxとTLSを迂回できる口を開けたままにすることです。ファイアウォールで5000番を閉じるか、ポートの公開行を消してください。

2つ目は、HTTPのまま運用することです。公式手順は本番でHTTPSの強制とcookie secretの設定を求めています。社内専用でも、VPNの内側に置くかTLSを終端するロードバランサを前段に置きます。

3つ目は、最も見落とされやすいAPIキーの放置です。リリースノートは、すでに漏れた可能性のあるクエリAPIキーは版を上げても無効にならず、共有ダッシュボード経由のものも含めて再生成が必要だと明記しています。BIツールの公開設定と既知の脆弱性が実際の情報流出につながった例は、Metabaseの脆弱性が悪用された不正アクセスの解説で詳しく扱っています。

Redashの採否をSQL作成者とサーバ運用者で判断する条件と代替製品の選び分け

比較する代替製品はMetabase・Superset・Databricks SQLです。Redashを採用する条件と見送る場面を、利用者と運用担当者の役割から整理します。

ここが採否の分かれ目です。機能の数ではなく、誰がSQLを書くのかと、誰がサーバを運用するのかの2軸で判断します。

SQLを書ける分析者が中心でクエリの共有が主目的ならRedashを採る判断基準

Redashを選んでよいのは、次の3つが同時に成り立つときです。1つ目は、ダッシュボードを作る側がSQLを書けるエンジニアや分析者で、閲覧する側は出来上がった画面を見るだけで足りること。2つ目は、Dockerのサーバを自社で運用し、半年強ごとの版更新とバックアップを回せる担当者がいること。3つ目は、複数のデータベースやクラウドのデータウェアハウスを1つの画面から横断して見たいことです。

典型的な採用場面は、開発チームが本番データベースの読み取り用レプリカにつなぎ、KPIの集計SQLを部署で共有する使い方です。書いたSQLがそのまま資産になり、ライセンス費用もかかりません。データソースの整理から画面設計、運用の引き継ぎまでを含めた構成の相談は、BIツール導入支援で受け付けています。

反対に、ダッシュボードを見る人が自分で絞り込みや集計の軸を変えたがる組織では、Redashは定着しません。SQLを書ける人に依頼が集中し、改修待ちの列ができるからです。

SQLを書かない利用者が多い場合やマネージドを望む場合に選ぶ代替手段の比較表

Redashの代わりに検討される製品を、選ぶ条件と合わせて並べます。

SQLを書かない利用者が多いなら、質問形式の画面で集計できるMetabaseの構成とエディション差を先に確かめてください。グラフの種類や行単位の権限まで要る規模ならApache Supersetの構成と導入手順が比較先になります。無料で使える製品をまとめて見比べたい場合は、無料BIツールの比較と有償化ラインで範囲を整理しています。

既存のRedashからの乗り換えも、急ぐ必要はありません。v26.9.0へ上げてセキュリティの穴を塞いだうえで、利用者の構成が変わったときに上の表で見直す、という順番で十分です。

よくある質問

Redashの検討や運用の段階でよく出る疑問に、公式ドキュメントとリリースノートの記述をもとに答えます。

Redashは無料で使えますか？

OSS版はBSD-2-Clauseのライセンスで公開されており、ライセンス費用はかかりません。かかるのはサーバ代と運用の人件費です。公式手順は基本構成で4GB以上のRAMを推奨しているため、クラウドで動かすならその規模の仮想マシン1台に、バックアップとストレージの費用が加わります。

Redashの開発は終了していますか？

終了していません。終わったのはDatabricksが運営していたホスト版で、2021年11月30日に停止しました。OSS版はv10.1.0のあと約3年安定版が出なかったものの、2025年1月のv25.1.0から公開が再開し、2026年9月24日にv26.9.0が出ています。GitHubのリポジトリもアーカイブされていません。

Redashの初期パスワードはありますか？

公式のsetupスクリプトで建てた場合、決まった初期パスワードはありません。初回にブラウザで開いた画面で、最初の管理者アカウントのメールアドレスとパスワードを自分で登録します。固定の初期IDとパスワードを書いた古い解説もありますが、公式のセットアップ手順にそうした記載はありません。登録した管理者のパスワードは、ほかの利用者と同じ強度で管理してください。

RedashをECSやKubernetesなど複数台の構成で動かせますか？

複数台の構成でも実行可能です。setupリポジトリのREADMEは、1台構成は小規模向けとしたうえで、大きな規模ではPostgreSQLとRedisを別のサーバ（できればマネージドサービス）へ分け、Redashのサーバを冗長化のため2台以上にするよう勧めています。server・scheduler・各workerは同じイメージをコマンド違いで起動するだけなので、コンテナ基盤のタスクやDeploymentに分けて載せられます。

RedashのデータをExcelやCSVで出力できますか？

できます。クエリの結果画面からCSVとExcel形式でダウンロードでき、APIでも結果のURL末尾を.csvにすればCSVで受け取れます。ただし保存されるのはクエリの実行結果だけなので、元データの全件を毎回書き出す用途には向きません。定期的な大量出力は、データベース側のエクスポートで行うほうが確実です。

関連記事

• BIツールとは？できること・ダッシュボードでの可視化・選定軸を解説：Redashを含むBIツール全体の判断軸。
• Metabaseとは？構成・エディション差と本番構成への移行を実装視点で解説：SQLを書かない利用者が多い場合の比較先。
• Apache Supersetとは？構成・Docker導入手順とMetabase比較で採用判断を解説：グラフの種類と権限管理を重視する場合の比較先。
• Lightdashとは？dbtで指標を定義するOSS BIの料金・AI機能・導入手順：dbtで指標を定義して見せる別のOSS BI。
• データ分析基盤とは？構成要素・費用・内製と外注の判断基準：Redashをつなぐデータ基盤側の設計。
• VOISINGの不正アクセスと約17万件の漏えい｜BIツールの既知脆弱性とパッチ適用の期限設計：BIツールの更新期限を決める考え方。