Retool と AI ネイティブなアプリ基盤：それが統治するのは誰がアプリを開くかであって、ロジックが何をするかではない
Retool はローコードで最高のアクセス統治を備える——RBAC、監査ログ、SSO、セルフホスト。だが業務ロジックは画面に散らばった JavaScript で、人間が diff として精査できず、AI も監査できない。そこにギャップがある。
TL;DR： Retool のアクセス統治はローコードで最高だ——クエリ単位の RBAC、行レベルセキュリティ、監査ログ、SSO、Enterprise でのセルフホスト。そのどれも問題ではないし、問題であるかのように装うべきではない。問題は、それが統治するレイヤーだ。RBAC は、あるロールがどのリソースに到達できるかを制御する。一方、実際の業務上の権限——この人物は 12,000 ドルの返金を発行できるか？——は、手書きの JavaScript の中に生きており、ボタンの Hidden プロパティ、入力欄の disabled バインディング、クエリの transformer に散らばっている。そのうち二つが一致する保証はなく、非エンジニアはどれも読めず、これらの式を書く AI は、いかなるプルリクエストがレビューできるよりも速く権限の決定を生み出す。ギャップはセキュリティではない。権限が、宣言され、レビュー可能な事実ではなくコードである、ということだ。
世界で最もありふれた Retool アプリを思い浮かべてほしい——返金コンソールだ。エンジニアが午後いっぱいで作り上げる——注文のテーブル、「返金」ボタン、いくつかのクエリ。サポートがそれを使う。素晴らしい。これが最高の状態の Retool であり、Retool はこの点で本当にカテゴリ最高だ。
さて、半年が過ぎた。それを作ったエンジニアはチームを移った。セキュリティがアクセスレビューを行い、新しい担当者に一行の質問を投げる：「どのロールが 10,000 ドルを超える返金を発行できるのか、そしてそれは正確にどこで強制されているのか？」
答えるために新しい担当者が何をしなければならないかを見てほしい。見るべき単一の場所はない。彼はアプリを開き、JavaScript を読み始める。
grep テスト
「どこで強制されているのか」が、現実の Retool アプリで実際にどう見えるかを示そう。大きな返金を発行する権限は、少なくとも三つの独立した式に散らばっており、それぞれが手書きで、それぞれ形が違う：
// 1. refundButton → "Hidden" プロパティ
{{ currentUser.groups.includes('admin') ||
(currentUser.groups.includes('support_lead') && refundAmount.value <= 10000) }}
// 2. refundAmount input → "disabled" プロパティ
{{ !currentUser.groups.includes('support_lead') }}
// 3. issueRefund query → transformer（ここが実際に書き込む部分だ）
if (refundAmount.value > 10000 && !currentUser.groups.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 エンジニアの反論はもっともで、正確に答えなければならない：「我々には 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 が正しい選択である場合——そしてメタデータモデルがあなたに代償を強いる場合
両方向に正直であれ。一方的な記事は、実際に決断しようとしている人にとっては無価値だからだ。
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 としてレビューできる事実であるべきだ——一致しなければならず、たいていは一致する三つの式の、一致しないその四半期までの、創発的な性質ではなく。