Retoolは、社内のデータベースやAPIに直接つないだ管理画面を、部品の配置とSQLで短期間に組み立てるローコードの開発基盤です。この記事では2026年10月時点の公式情報をもとに、リソース・クエリ・コンポーネントで画面がつながる仕組み、ビルダー単位で課金される料金体系、セルフホスト版をDockerで建てる手順を順に追います。DBへ直結するからこそ必要になる権限設計を具体的なSQLで示し、Retoolを採用する条件と、コードで作る管理画面へ切り替える判断まで言い切ります。
まとめ：Retoolは社内向けの管理画面をDB直結で組み立てるローコード基盤
Retoolで作るものの中心は、社員が日々使う一覧・検索・編集の画面です。データベースやAPIを「リソース」として登録し、SQLやAPI呼び出しを「クエリ」として書き、表やフォームなどの部品に結果を流し込みます。画面のレイアウトはドラッグで済み、手で書くのはSQLと短いJavaScriptだけです。
料金は、その月にアプリを作成または編集した人数（ビルダー）と、使うだけの社員の人数で決まります。SSOやGit連携、セルフホストはEnterpriseプランに限られるため、情報システム部門の要件によっては最初からEnterpriseの見積もりが必要です。
採用してよいのは、利用者が社内に限られ、SQLを書けるエンジニアが少人数で多数の管理画面を回したいときです。社外の顧客に公開する画面や、業務ロジックが画面の外に大きく広がるシステムは、コードで作る構成を選びます。
Retoolの定義とリソース・クエリ・コンポーネントで画面を組む仕組み
Retoolの画面は、接続先・データの取り方・見せ方の3層を別々に定義し、それを式で結ぶ作りです。この層の分け方を押さえると、できることと苦手なことが見えてきます。
データベースやAPIをリソースとして登録しクエリで画面へつなぐ流れ
最初に登録するのはリソースです。PostgreSQL・MySQL・SQL Serverなどのデータベース、REST APIやGraphQL、Google スプレッドシートといった接続先を、接続情報ごと組織に1回だけ登録します。アプリを作る人は接続文字列やパスワードを知らなくても、登録済みのリソースを選ぶだけでクエリを書けます。
クエリは、リソースに対するSQLやAPIリクエストです。実行はブラウザからではなく、Retoolのサーバを経由してデータベースへ届きます。公式の行レベルセキュリティの解説も、リクエストはクライアントからRetoolのサーバへ渡り、サーバ側でprepared statementとして評価されてからデータベースで実行されると説明しています。
コンポーネントは、表・フォーム・ボタン・グラフ・モーダルなどの部品です。クエリの結果を表に流し、表で選んだ行をフォームに出し、ボタンで更新クエリを走らせる、という配線で1画面ができあがります。
二重波括弧の式で部品の値をSQLへ渡すクエリの書き方と実行例
部品とクエリを結ぶのが、二重波括弧で囲んだJavaScriptの式です。セレクトボックスで選んだ状態で受注を絞り込み、表で選んだ行の状態を更新する場合は、次の2本のクエリを書きます。
-- getOrders：画面の絞り込み条件で一覧を取る
SELECT id, customer_name, status, updated_at
FROM orders
WHERE status = {{ statusSelect.value }}
ORDER BY updated_at DESC
LIMIT 200;
-- updateOrderStatus：表で選んだ行の状態だけを更新する
UPDATE orders
SET status = {{ newStatusSelect.value }}, updated_at = now()
WHERE id = {{ table1.selectedRow.id }};見た目は文字列の埋め込みですが、公式のprepared statementの解説によると、RetoolはSQLクエリをprepared statementに変換し、式の値はパラメータとして渡します。これがSQLインジェクションの防御になっています。
裏返すと、テーブル名や列名を式で切り替える書き方は動きません。公式はテーブルごとにクエリを分けるよう案内しています。リソースの設定でprepared statementを無効にすれば動的な名前も使えますが、インジェクションへの防御も一緒に外れるため、本番の更新系リソースでは無効にしません。
アプリ・Workflows・Retool Databaseの守備範囲と旧エディタの扱い
Retoolの製品は画面を作るアプリだけではありません。定期実行やバッチ処理を組むWorkflows、Retoolの中にPostgreSQLベースの表を持てるRetool Database、AIのエージェント機能が同じ組織の中に並んでいます。公式の料金ページでは、Freeプランでも Retool Database に5GBまで保存できます。
注意したいのは、公式ドキュメントにアプリのエディタが2種類ある点です。従来のドラッグ操作のエディタは「classic apps」と表記され、新規開発の中心はAIで画面を生成する新しいアプリビルダーに移っています。検索で見つかる手順の多くはclassic apps向けなので、読むときはページ上部の表記を確かめてください。
ノーコードとローコードの線引きでいえば、RetoolはSQLとJavaScriptを書く前提のローコード側の製品です。両者の違いと向き不向きはノーコードとローコードの違いと限界で整理しています。
Retoolの料金体系とビルダー課金・セルフホストが要るときのプラン条件
Retoolの見積もりは、作る人と使う人を分けて数えるところから始まります。人数の数え方を誤ると、月額の桁が変わります。
Free・Team・Business・Enterpriseの単価と機能差の比較表
公式の料金ページを2026年10月21日に確認した内容を、年払い時の1人あたり月額で並べます。
| プラン | ビルダー | 社内の利用者 | 主な違い |
|---|---|---|---|
| Free | 無料 | 無料 | 5ユーザーまで・本番環境のみ |
| Team | 10ドル | 5ドル | ステージングと本番の2環境 |
| Business | 50ドル | 15ドル | 監査ログ・権限・社外ユーザー |
| Enterprise | 個別見積 | 個別見積 | SSO・Git連携・セルフホスト |
ビルダーとは、その請求期間にアプリかワークフローを作成または編集したユーザーです。作る人が3人、使う社員が40人ならBusinessで月に150ドル＋600ドルとなり、使う側の人数が費用の大半を占めます。社外の取引先に使わせる場合はBusiness以上で、0〜50人は無料、51〜250人は1人8ドルです。月払いは年払いより20%高くなります。
保守や改修の人件費まで含めた総額の考え方は、ローコード開発の費用相場とスクラッチの5年総額比較で扱っています。
SSOとGit連携とセルフホストがEnterprise限定になる点の見落とし
料金表で見落としやすいのは、Businessプランに含まれない機能です。公式の料金ページでは、SSO・SCIM・2要素認証、Gitによるソース管理、細かなカスタムロール、セルフホストやエアギャップ環境での運用は、いずれもEnterpriseの項目に並んでいます。
この線引きは、社内の情報システム部門が持つ要件とぶつかります。「社員の認証はIDプロバイダに一本化する」「データベースは社外のクラウドへ出さない」のどちらか一方でも必須なら、BusinessではなくEnterpriseの見積もりが前提です。Freeで試作した画面の評価が高くても、本番の要件で単価の前提が変わる点を、稟議の前に共有しておくと手戻りを防げます。
セルフホスト版RetoolをDockerで建てる手順と64GiBのサーバ要件
社内ネットワークの中でRetoolを動かすなら、公式のDocker構成を使います。ここでは検証環境を1台に建てるまでの作業を追います。
install.shの実行からdocker compose起動までの導入手順
公式のDocker導入手順に沿ってretool-onpremiseを導入する際に求められるサーバは、Ubuntu 22.04以降のx86機で、メモリ64GiB以上・8vCPU以上・ストレージ60GiB以上です。同じ構成には、ワークフローとエージェントの非同期処理を担うTemporalも含まれます。管理画面の基盤として見ると、検証用でも大きめのサーバを用意する前提です。
# 公式の構成一式を取得する
git clone https://github.com/tryretool/retool-onpremise.git retool
cd retool
# Dockerfile の X.Y.Z-stable を、採用する Stable 版のタグに全イメージそろえて書き換える
# 例：4.34 系の最新パッチ（タグはリリースノートで確認する）
# docker.env と retooldb.env を生成する
./install.sh
# docker.env に LICENSE_KEY と BASE_DOMAIN を設定し、ENCRYPTION_KEY を別の場所へ控える
sudo docker compose up -d
sudo docker compose psライセンスキーは、セルフホスト用のポータルで発行したものをdocker.envのLICENSE_KEYに入れます。Retoolはlicensing.tryretool.comの443番へ最低1日1回ライセンスを確認しに行くため、閉じたネットワークではこの通信の許可が必要です。retool-onpremiseのリポジトリには、HTTPSを終端するhttps-portalや、ファイル保存用のMinIOを含む構成が入っています。
ENCRYPTION_KEYは、データベースに保存するリソースの接続情報を暗号化する鍵です。サーバを作り直したときにこの鍵が無いと、登録済みの接続情報を復号できません。
四半期ごとのStable版と6か月の保守期間に合わせた更新計画
セルフホスト版のStableリリース一覧によると、Stable版は四半期ごとに出て、各版の保守は6か月です。クラウド版より概ね4版遅れて出るため、クラウドで見た新機能がすぐには手元に来ません。
| Stable版 | 公開日 |
|---|---|
| 4.34 | 2026年8月26日 |
| 4.0 | 2026年6月11日 |
| 3.334 | 2026年3月3日 |
| 3.300 | 2025年12月3日 |
6か月を過ぎた版は非推奨となり、修正パッチが出なくなります。運用担当は半年に1回、版を上げる作業を年間計画に組み込んでください。毎週出るEdge版もありますが、公式はほとんどの組織にStable版を勧めています。
DB直結の社内ツールで情報漏えいを防ぐRetoolの権限設計と行レベル制御
Retoolは本番データベースへ直接つながるため、権限設計を誤ると、画面を開けた社員に全件の参照や更新を許すことになります。守りは、データベース・Retoolのリソース・アプリの3段で組みます。
接続用DBユーザーを画面ごとに分け最小権限で付与するSQL例
最初の防御線は、Retoolがデータベースへ接続するときのユーザーです。管理者ユーザーをそのまま登録すると、Retool側の設定を1つ誤っただけで全テーブルに手が届きます。受注管理の画面なら、必要な表と列だけを許可した専用ユーザーを作ります。
-- Retool の受注管理リソース専用のユーザー（PostgreSQL）
CREATE ROLE retool_orders LOGIN PASSWORD 'change-me';
GRANT CONNECT ON DATABASE app TO retool_orders;
GRANT USAGE ON SCHEMA public TO retool_orders;
-- 参照は2表だけ、更新は status と updated_at の2列だけを許す
GRANT SELECT ON orders, customers TO retool_orders;
GRANT UPDATE (status, updated_at) ON orders TO retool_orders;列単位のUPDATE権限は、PostgreSQLのGRANTの仕様どおり列名を括弧で並べて付与します。こうしておけば、画面の改修で誤って金額の列を書き換えるクエリを作っても、データベースがその更新を受け付けません。リソースは用途ごとにこのユーザー単位で分けて登録し、参照専用の画面には参照専用のリソースだけを渡します。
current_userのクエリ内行フィルタとEnterpriseのアクセスポリシー
同じ表の中で「自分の部署の受注だけ見せる」には、ログイン中のユーザーを表すcurrent_userを条件に入れます。公式の行レベルセキュリティの解説は、current_user.emailを対応表に結合して見える行を絞る例を示しています。current_userを参照するクエリでは、通信の途中で別人のメールアドレスに書き換えられないよう、変数のなりすまし防止が既定で有効です。
ただし、この方式の弱点は条件を書いたクエリにしか効かない点です。新しく作ったクエリで条件を書き忘れると、全件が返ります。公式はもう1つの方式として、リソースそのものにアクセスポリシーを付け、そのリソースへのすべてのクエリに行の絞り込みを強制する方法を示しています。こちらはPostgreSQLのリソースでEnterpriseプラン限定です。ポリシーを付けたリソースには、ワークフローからのクエリが通りません。
実務では、個人情報や取引金額を含む表はアクセスポリシーかデータベース側の行レベルセキュリティで外枠を固め、画面ごとの見せ方はクエリ内の条件で整える、という二重の構成にします。
Use・Edit・Ownの権限グループで編集者と利用者を分ける運用
公式のロールベースアクセス制御の解説では、アプリ・リソース・ワークフロー・エージェントの各オブジェクトに対し、グループ単位でUse・Edit・Ownの3段階を付与します。このオブジェクトロールはBusinessとEnterpriseで使えます。
運用で守るべき線は1本です。リソースのEditとOwnは、接続情報を変えられる人に限り、アプリを作る人には付けません。アプリのEditは作る人、Useは使う社員だけに付与し、使う側のグループからは新規クエリを書ける権限を外しておきます。野良アプリや権限の棚卸しを含めた全体の対策はローコード開発のセキュリティリスクと権限設計にまとめています。
Retoolを採用する条件と内製の限界、コードで作る管理画面への切り替え判断
ここが採否の分かれ目です。機能の多さではなく、誰が使い、ロジックがどこにあり、何人で保守するのかで判断します。
社内向けCRUD画面を少人数で素早く回すならRetoolを採る判断基準
Retoolを選んでよいのは、次の3つがそろうときです。1つ目は、利用者が社内の社員で、画面の中心が一覧・検索・編集・承認といったCRUD操作であること。2つ目は、SQLを書けるエンジニアが1〜3人いて、部署ごとの小さな管理画面の依頼を次々にさばきたいこと。3つ目は、業務ロジックの本体がすでにデータベースや既存のAPIにあり、画面はそれを呼ぶだけで済むことです。
典型的なのは、カスタマーサポートが顧客の契約状況を照会して解約フラグを立てる画面や、倉庫の担当者が出荷の保留を解除する画面です。画面の作り込みよりも、本番データへ安全に触らせる配線のほうが手間のかかる仕事になります。既存システムとの接続や権限の切り方まで含めた構成の相談は、ノーコード・ローコードアプリ開発で受け付けています。
社外公開や複雑な業務ロジックで採用を見送る場面と代替手段の比較表
反対に、次の場面ではRetoolを見送ります。顧客や会員が使う公開サイトの画面、画面の中で複雑な計算や状態遷移を持つ業務、そして利用者が数百人規模に増えて利用者課金が開発費を上回る場合です。Retoolの内側で書いたJavaScriptが数千行に膨らみ始めたら、内製の限界に来ている合図と捉えてください。
| こんなとき | 判断 | 候補 |
|---|---|---|
| 社内CRUD画面を少人数で量産したい | Retoolを採用 | Retool |
| 利用者課金を避けて自社サーバで動かしたい | Retoolは見送り | Appsmith・ToolJet |
| React製の既存システムに管理画面を足す | Retoolは見送り | React-admin・Refine |
| Laravelの業務システムに管理画面を足す | Retoolは見送り | Filament |
| 顧客向けの公開画面を作る | Retoolは見送り | スクラッチ開発 |
OSSの代替では、AppsmithがApache-2.0、ToolJetがAGPL-3.0で公開されており、自社サーバで動かせば利用者数で課金されません。既存のコードベースに管理画面を足すなら、React-adminで管理画面を作る方法やLaravel Filamentの構成とNovaとの選択基準のように、同じリポジトリで型とテストを共有できる構成が保守で勝ります。用途別の製品の選び分けはローコードツールの比較と選定基準で整理しています。
よくある質問
Retoolの検討段階でよく出る疑問に、公式の料金ページとドキュメントの記述をもとに答えます。
Retoolは無料で使えますか？
Freeプランがあり、5ユーザーまでなら無料で使えます。クラウド版で本番環境1つ、Retool Databaseは5GBまで、AIクレジットは月250です。ステージング環境や監査ログ、社外ユーザーへの公開は含まれません。試作と小さなチームでの検証には足りますが、部署全体で使う段階ではTeam以上の見積もりが必要です。
Retoolはオープンソースですか？
オープンソースではありません。セルフホスト版のDocker構成はGitHubのretool-onpremiseで配布されていますが、起動にはRetoolが発行するライセンスキーが必要で、リポジトリにもOSSのライセンス表記はありません。ライセンス費用をかけずに自社サーバで動かしたい場合は、Apache-2.0のAppsmithやAGPL-3.0のToolJetが比較の対象になります。
Retoolで作ったアプリを社外の取引先に使わせられますか？
Businessプラン以上で、社外ユーザーとして招待できます。公式の料金ページでは、社外ユーザーは0〜50人まで無料、51〜250人は1人あたり月8ドル、251〜500人は6ドル、500人を超えると4ドルです。ただしRetoolは社内ツール向けの作りなので、不特定多数の顧客が使う公開サイトには向きません。
Retoolを使うとデータはRetoolのサーバに保存されますか？
クエリの実行はRetoolのサーバを経由しますが、データの保存先は接続した自社のデータベースのままです。Retoolのサーバには、リソースの接続情報やアプリの定義が保存されます。通信経路まで社内に閉じたい場合は、Enterpriseプランのセルフホスト版で、Retoolのサーバとデータベースを同じVPCに置く構成にします。
RetoolとAppsmithはどちらを選べばよいですか？
判断の軸は、運用を任せたいか自社で持ちたいかです。クラウドで運用を任せ、AI機能や監査ログを含む完成度を取るならRetool、ライセンス費用をかけずに自社サーバで動かし、ソースコードを読んで改修できる状態を保ちたいならAppsmithを選びます。セルフホスト版のRetoolはEnterprise限定で、メモリ64GiB以上のサーバも要ります。
関連記事
- ノーコードとは？ローコードとの違い・できること・限界を実務目線で解説：Retoolを含むローコード製品の位置づけ。
- ノーコードツール比較｜業務アプリ・Web・EC用途別の代表製品と選び方：業務アプリ用途での比較先。
- Refine（React）とは？react-adminとの違い・v5の使い方と管理画面の作り方：コードで作る管理画面の別の選択肢。
- Power Platformとは？5つのサービス・できること・料金と内製の判断まで解説：Microsoft 365環境で社内アプリを作る場合の比較先。
- ローコード開発のセキュリティリスクと対策｜権限設計・野良アプリ・発注時の確認項目：権限の棚卸しと野良アプリ対策。
