Retool の RBAC と監査ログ：統治された AI アプリ開発に Retool は使えるか

TL;DR： 統治された AI アプリ開発のために Retool を評価しているなら、そのアクセス層は合格だ。そうでないかのように装うべきではない。Retool には、権限グループによる RBAC、AI ビルダーを誰が使えるかのロールベースの制御、すべてのクエリ実行を記録する監査ログ、SSO、セルフホスト、そして（2026 年 10 月以降、Postgres 向けにパブリックベータで）どのクエリもオプトアウトできないリソースアクセスポリシーがある。2026 年 6 月以降は、Lovable、Cursor、Claude Code で作られたアプリにもこれらの制御を適用している。Retool が与えないのは、宣言された事実としての業務上の権限だ。「この人物は 12,000 ドルの返金を発行できるか？」は依然として、コンポーネントのプロパティやクエリロジックに散らばった JavaScript の中に生きていることが多く、AI はいかなるプルリクエストがレビューできるよりも速くそれらの式を書く。ギャップは基本的なセキュリティではない。権限がコードであって、レビュアーが一か所で読めるルールではない、ということだ。

世界で最もありふれた Retool アプリを思い浮かべてほしい——返金コンソールだ。エンジニアが午後いっぱいで作り上げる——注文のテーブル、「返金」ボタン、いくつかのクエリ。サポートがそれを使う。素晴らしい。これが最高の状態の Retool であり、Retool はこの点で本当にカテゴリ最高だ。

さて、半年が過ぎた。それを作ったエンジニアはチームを移った。セキュリティがアクセスレビューを行い、新しい担当者に一行の質問を投げる：「どのロールが 10,000 ドルを超える返金を発行できるのか、そしてそれは正確にどこで強制されているのか？」

答えるために新しい担当者が何をしなければならないかを見てほしい。見るべき単一の場所はない。彼はアプリを開き、JavaScript を読み始める。

grep テスト

「どこで強制されているのか」が、現実の Retool アプリで実際にどう見えるかを示そう。大きな返金を発行する権限は、少なくとも三つの独立した式に散らばっており、それぞれが手書きで、それぞれ形が違う：

// 1. refundButton → "Hidden" プロパティ
{{ current_user.groups.map(g => g.name).includes('admin') ||
   (current_user.groups.map(g => g.name).includes('support_lead') && refundAmount.value <= 10000) }}

// 2. refundAmount input → "disabled" プロパティ
{{ !current_user.groups.map(g => g.name).includes('support_lead') }}

// 3. issueRefund query → transformer（ここが実際に書き込む部分だ）
if (refundAmount.value > 10000 && !current_user.groups.map(g => g.name).includes('finance')) {
  throw new Error('Refunds over $10k require finance');
}

三か所。微妙に異なる三つの条件。ボタンは一部のユーザーに対して自らを隠す。入力欄は別のユーザーに対して自らを無効化する。クエリは三つ目の集合に対して例外を投げる。それらは一つの一貫したルール——「サポートリードは 10,000 ドルまで、それを超えると財務」——に合算されるはずだが、そうなる保証は何もない。ボタンを隠しても、誰かが別の経路でたどり着けば、その下にあるクエリは依然として実行される。来四半期に二つ目の書き込み経路を追加して finance チェックを忘れれば、どの画面も明かさない穴ができる。

これをgrep テストと呼ぼう：「誰が X をできるか」に答えるには、一つの宣言されたルールを読むのか、それともアプリを grep するのか？grep なら、そのアプリは権限のレイヤーで統治されていない——単にコード化されているだけであり、アクセス統治（Retool が完璧にこなすもの）は、実際にあなたを傷つけうるものの一つ上のレイヤーに座っている。

対比のために、同じ権限を宣言された事実として示そう——どのボタンやクエリから来たかにかかわらず、ランタイムがあらゆる経路で強制する一つのルールだ：

action: issue_refund
  who_can_run:
    - role: SupportLead   when: amount <= 10000
    - role: Finance       when: amount  > 10000
  requires_approval:      when: amount > 10000      # 投げられるエラーではなく、予防的なゲート
  audit: always

読む場所は一つ。変える場所は一つ。レビュアー——あるいは AI——が推論する対象は一つ。手作業で保守される三つの式と、一つの宣言されたルールとの違いは、「アプリがコード化されている」と「アプリの権限が統治されている」との違いそのものだ。

Retool の RBAC と監査ログ：各制御が実際にカバーする範囲

grep テストが公平であるためには、Retool が実際に持っている制御を正確に述べておく必要がある。以下は 2026 年 11 月に Retool 自身のドキュメントと照合したものだ：

制御	何を統治するか	どこで止まるか
権限グループ（RBAC）	グループは「ロールを付与し、アプリ、リソース、ワークフロー、エージェントへのアクセスを制御する」（Retool 権限ガイド）	誰が開けるか、編集できるか、クエリできるかであって、中に入った人のある操作が何をしてよいかではない
Assist RBAC（2026 年 2 月、Business と Enterprise）	ロールごとに、Ask と Build モード、Ask モードのみ、または AI ビルダーへのアクセスなし（変更履歴）	誰が変更を生成できるかであって、生成された変更が何を許可するかではない
監査ログ	「クエリ実行やパスワードリセットなど」のユーザー操作を、正確なクエリ、パラメーター、IP アドレス、応答時間とともに記録。Cloud では 1 年間保持、Business と Enterprise では CSV エクスポート、Enterprise では Datadog または Splunk へのストリーミング（監査ログ）	探偵的：実行されたものを、実行された後に記録する
`current_user` 行フィルター	値は「認証済みセッションからサーバー側で計算され」、各クエリに注入される（行レベルセキュリティ）	クエリごとに手作業：「フィルターを省いたクエリは、フィルターされていないデータを返す。」
リソースアクセスポリシー	リソース上のテーブル、列、行へのアクセスを、アプリ、クエリライブラリ、生の SQL、エージェントからのすべてのクエリに対して強制する（アクセスポリシー）	PostgreSQL のみ、2026 年 10 月からパブリックベータ。行フィルターは「ユーザーが作成する行や、ユーザーが書き込む値を検証しない」
AI でコーディングされたアプリの統治（2026 年 6 月）	Lovable、Replit、Cursor、Claude Code で作られたアプリは「既存の権限と監査証跡を継承する」。「権限はデータソースに付与される」（Retool ニュースルーム）	同じレイヤー：データソースの権限であって、操作レベルの業務ルールではない

このうち二つの行は他より重要だ。まさにこの記事が主張する方向へ Retool が動いていることを示しているからだ。

アクセスポリシーは宣言されたルールであって、三つの式ではない。 リソース上のポリシーはすべてのクエリに適用され、「どのクエリもオプトアウトできない」。これはクエリごとの current_user フィルターの正反対だ。データの権限——サポートリードがどの行を読み、削除できるか——について言えば、Postgres ではこれで grep テストの大半が解消される。この記事の 6 月版に対する誠実な更新は、Retool がいまやそのレイヤーに本物の答えを持っている、ということだ。

ポリシーが表現しないのは返金ルールだ。 アクセスポリシーのドキュメントが記述しているのは、テーブル、列、行に対する読み取り、書き込み、削除のアクセスだ。金額のしきい値、承認ゲート、書き込まれる値に対する条件は記述していない。そして行フィルターは、ユーザーが書き込む内容を明示的にチェックしない。「サポートリードは 10,000 ドルまで、それを超えると財務、ラインを超えたら承認」は操作とその引数についてのルールなので、依然として上のボタン、入力欄、transformer の中に生きている。ポリシーはデータの権限を一か所に移す。業務上の権限は JavaScript に残る。

この表をスコアカードとして読めば、Retool はセキュリティレビューが問うあらゆるアクセス統治の質問に合格する。一か所から答えられないのは、この記事の冒頭の質問だ：どのロールが 10,000 ドルを超える返金を発行できるのか、そしてそれはどこで強制されているのか？

なぜソース管理ではこれを塞げないのか

抜け目のない Retool エンジニアの反論はもっともで、正確に答えなければならない：「我々には Git に支えられたソース管理と監査ログと RBAC がある。変更は PR でレビューされる。アクセスは統治されている。何が欠けている？」

具体的に三つだ。

第一に、Retool アプリの PR は、コンポーネントに散らばった JavaScript とバインディングのレビューだ——あなたはコードレビューをしているのであり、つまり (a) エンジニアを必要とし、(b) 「この変更は誰が大きな返金を発行できるかを変えた」という構造化された表現が存在しない。レビュアーは、三つ離れたコンポーネントの Hidden 式へのちょっとした手直しが権限の境界を変えたことに気づかなければならない。散らばったロジックの diff は、あなたが最も見る必要のあるものを、まさに隠してしまう。

第二に、ソース管理がレビューするのはコードであって、事実としての権限ではない。「この PR は 10,000 ドル超を返金できる人を変えたか？」は、Git の diff が直接答える質問ではない。それは、頭の中でコードを追って答える質問だ。上記の宣言されたルールはその diff を自明にする：who_can_run が変わったか、変わっていないか。

第三に——そしてこれが業界の向かう先にとって最も重要なのだが——ローコードの前提そのものが、非エンジニアと AIがアプリを変える、しばしばビジュアルエディタの中で、しばしば PR をまったく介さずに、ということだ。あなたが頼りにしている統治（PR レビュー）は、ローコードがそのためにある変更には存在しない。監査ログは Hidden プロパティが変わったことを事後に教えてくれる——探偵的であって予防的ではない——が、それがリリースされる前にそれがどんな権限を付与したかを誰もレビューしなかった。

AI はこれを壊さない。これを増幅する。

長年、grep テストは生き延びられた。なぜなら人間が JavaScript を書き、別の人間が各ルールがどこに生きているかの知識を担っていたからだ。散らばったロジックは、人が作って覚えているなら、たどれる。

同じアプリに AI を向ければ、経済性は両方向に逆転する。AI は一分で五十のバインディングと十数の transformer を生成できる——いかなるレビュアーが追えるよりも速く権限の決定を生み出す。そして、それが生み出したものをレビューするには、また画面をまたいで JavaScript を読むことに戻る。なぜなら、diff の対象となる権限の構造化された単一の表現が依然として存在しないからだ。「Retool AI」とエージェント（2025）は実在し有用だが、それらは同じ手作りの基盤の上で自動化する：エージェントは統治されている（Retool は呼び出す対象を制限できる）が、エージェントが編集するアプリは——AI が——あるいは人間が——コードとしてではなく事実としてレビューできるいかなる形でも——権限統治されていない。

AI が最も速く生み出すものこそ、Retool が最もレビューしにくくするものだ。

エンタープライズアプリにおける Retool vs. Lovable

もう一つよく行われる比較は Retool 対 Lovable で、たいてい「社内ツールビルダー vs. AI アプリジェネレーター」として捉えられる。エンタープライズアプリにとってより有用な捉え方はこうだ：それぞれの制御は、誰のユーザーを統治するのか？

	Retool	Lovable
AI が生み出すもの	Retool のコンポーネントランタイム上で動くアプリで、既存のリソースに接続される	フルスタックのプロジェクトコード。デフォルトでは「Lovable のマネージドインフラ上に存在し」、GitHub、GitLab、Bitbucket と同期できる（Lovable for Enterprise）
ロール	権限グループが、アプリと、その背後にあるリソース、ワークフロー、エージェントへのアクセスを制御する	オーナー、管理者、編集者、閲覧者、外部コラボレーターが、アプリを作るワークスペースを統治する（同じページ）
エンドユーザーのデータアクセス	データソースの権限、`current_user` フィルター、アクセスポリシー	組み込みバックエンドの「ユーザーごとのデータ向け」行レベルセキュリティで、生成されたプロジェクトの一部。Quick scan は「公開のたびに実行され、データベースのアクセスルールをチェックする」
監査	クエリレベルの監査ログ、Cloud で 1 年	ワークスペースの監査ログは「13 週間保持」され、SIEM やストレージバケットへの定期エクスポートが可能
セルフホスト	Retool 管理型またはセルフマネージドのセルフホストインスタンス（セルフホスト版 Retool）	バックエンドとデータベースは、「セルフホストの Supabase を含め」自分たちが運用するインフラに移せる。ビルダー自体は SaaS のまま

二行目と三行目の区別こそが、エンタープライズへの適合性を決める。Lovable のロールと監査ログが統治するのは、アプリを作る人々だ。アプリを使う人々を守るのは、生成されたプロジェクト自身のバックエンド内のアクセスルールであり、それを公開のたびにスキャンがチェックする。Retool はアプリを使う人々を統治する。アプリが Retool の中で動くからだ。だからこそ Retool の 2026 年 6 月の一手は、生成で競うことではなく、Lovable や同様のツールで作られたアプリを自らのデータソース権限の下でホストすることなのだ。

つまり現実的なエンタープライズのパターンは「Retool か Lovable か」ではなく、「どこで生成してもよい、統治された場所で動かす」だ。どちらも grep テストを変えない。Lovable アプリの返金しきい値は生成されたコードの中に、Retool アプリのそれはバインディングと transformer の中に生きており、どちらの場合もレビュアーはコードを読んで業務上の権限を再構成することになる。

Retool が正しい選択である場合——そしてメタデータモデルがあなたに代償を強いる場合

両方向に正直であれ。一方的な記事は、実際に決断しようとしている人にとっては無価値だからだ。

Retool のアクセス統治は本当にクラス最高であり、多くのアプリにとって grep テストは表面化しない：信頼できるスタッフが運用し、SSO の背後にあり、それを書いた同じエンジニアが保守する社内ツールで、「サポートリードは 10,000 ドルまで返金できる」が、たまたま一致しめったに変わらない三か所で強制されている場合だ。そのため——そして要件が変わったときにいつでも SQL と任意の JavaScript に潜り込める自由のため——Retool は卓越しており、短時間で社内ツールをつなぐ用途では非常に強い。

そして宣言されたメタデータのモデルには、逆方向に実際の代償がある：あなたは生の柔軟性を、可読性と引き換えにする。モデルにそのための場所がないとき、プロパティに任意の JavaScript をただ貼り付けることはできない。本当に異例なロジックを宣言されたルールとして表現するのは、どこでも使える {{ }} よりも制約が強い。使い捨てのツールにとって、その制約は純然たるオーバーヘッドだ。このモデルが元を取るのは、「誰が何をできるか」が——監査人、規制当局、あるいは次の担当者によって——証明を求められるものであるとき、そして変更を行うのが元の作者ではなく AI であるとき、に限られる。

それが境界線だ。その下では、Retool は実力で勝つ。その上では、grep テストこそ、半年後にクリップボードを持った誰かの前であなたが落第するものだ。

ObjectStack の立場

ObjectStack は、Retool が正しくやっていること——強固なアクセス制御、セルフホスト、あなた自身のインフラ——を保ち、権限を同じ統治されたレイヤーへと降ろす。アプリのロジックは開かれた、読めるメタデータだ：issue_refund のようなアクションは、それ自身の who_can_run、それ自身の承認ゲート、それ自身の監査要件を携え、一度宣言され、ランタイムによってあらゆる経路で強制される。AI の変更は、その宣言された権限に対する diff だ——「この変更は SupportLead が 25,000 ドルまで返金できるようにする」は、非エンジニアがリリース前に読んで承認できる一行であって——後から grep して発見する Hidden 式ではない。

「JavaScript に潜り込んで昼までにツールを出荷する」で Retool を上回るつもりはない。主張はより狭く、境界線の上でのみ意味を持つ：AI があなたの社内ソフトウェアを書いているとき、誰が何をできるかは、一つの場所で読めて diff としてレビューできる事実であるべきだ——一致しなければならず、たいていは一致する三つの式の、一致しないその四半期までの、創発的な性質ではなく。