Retool の最良のセルフホスト代替は何ですか？

ドラッグ&ドロップ型ビルダーの中では Appsmith が最大のオープンソースの選択肢で、ToolJet、Budibase、Lowcoder がそれに続きます。いずれもセルフホスト可能です。ドラッグ&ドロップの限界を完全に避けたいなら、バックエンド（データベース、シークレット、cron、関数）込みで本物のアプリを構築するコードファーストなプラットフォームが、データベース持ち込みの負担を取り除く別のモデルになります。ビジュアルなキャンバスが欲しいのか、本物のコードが欲しいのかで選んでください。

Retool はなぜこれほど高いのですか？

シート単位で課金され、しかも閲覧者まで数に含まれるからです。Business プランではビルダーが $50/user/mo、社内ユーザーが $15/user/mo で、さらに従量制のワークフロー実行、AI クレジット、エージェント時間が上乗せされます。コストはツールを作る人数だけでなく、使う人数に比例して増えるため、うまくいくほど高くつく構造になっています。

オープンソースの社内ツールビルダーには自前のデータベースが必要ですか？

ほとんどの場合、必要です。ドラッグ&ドロップ型ビルダーは別の場所にあるデータに接続するインターフェース層なので、データベース、認証、シークレット、スケジューリングは自分で別途プロビジョニングして運用することになります。アプリごとのデータベース、シークレット、cron を内蔵したプラットフォームなら、その運用負担を丸ごとなくせます。

ローコードのツールビルダーは本物のソースコードをエクスポートできますか？

たいていは、きれいにはできません。アプリのロジックがビルダー独自のフォーマットに収められているため、人間が読めるソースコードをエクスポートできるものはごくわずかで、移行が難航します。ロックイン回避が重要なら、作ったものが本物のコードであり、しかも持ち出せる標準的なデータベースが付いてくるプラットフォームを選ぶのが賢明です。

ドラッグ&ドロップ型ビルダーの限界に達したらどうなりますか？

エスケープハッチ、つまりカスタムコードブロックに頼ることになりますが、多くはクライアントサイドの JavaScript とインライン CSS に限られ、ロジックが増えると扱いにくくなるワークフロー UI になりがちです。限界はたいてい、カスタムなデータ変換、ホスティング済みサーバーを要する連携、標準コンポーネントを超えた UI といった場面で現れます。コードファーストなプラットフォームはそもそもコードとして始まるため、その限界に達することはありません。

Appsmith、ToolJet、Budibase は本当に無料でセルフホストできますか？

オープンソースのコアは無料で、セルフホストすれば無料ユーザー数の上限も上がります（Budibase は Retool の 5 に対して 20 ユーザーまで許可）。ただし、デプロイ、保守、スケーリングは自前で負担することになり、有料版では依然としてプレミアム機能や作成者ごとの料金に制限がかかります。「無料」はライセンスを指すのであって、運用にかかる総コストを指すわけではありません。

AI ネイティブなビルダーと、AI を後付けしたビルダーの違いは何ですか？

後付け型の AI ビルダーは、AI が重要になる前に設計されたキャンバスの脇に AI ノードとクレジットプールを足すだけです。単純なフィールド単位のタスクには向いています。一方、AI ネイティブなプラットフォームはモデルの呼び出しをアプリコードの第一級プリミティブとして扱うため、AI は別ブロックに切り離されるのではなく、ツールのロジック全体に織り込まれています。

← Resources

By Marcus Okafor — Platform Engineer, Apps · 2026-06-02 · GUIDE

セルフホスト型 Retool 代替：シート課金なしで社内ツールを構築

ローコードの社内ツールビルダーは、別の場所にあるデータの上にかぶせるインターフェース層にすぎず、ビルダーと閲覧者のシート単位で課金されます。本ガイドでは、シート課金の罠、カスタマイズの限界、そしてバックエンドを内蔵したコードファーストなビルダーがコスト構造をどう変えるのかを解説します。

ローコード社内ツールビルダーの実際の仕組み

Retool、Appsmith、ToolJet、Budibase などのツールは、ビジュアルなドラッグ&ドロップキャンバスを中心に作られています。テーブル、フォーム、ボタン、チャートといった既製のコンポーネントを組み合わせ、クエリでデータに接続します。重要なのは、これらが別の場所にあるデータの上にかぶせるインターフェース層にすぎないという点です。ツール自体は何も保存せず、既存の Postgres、MySQL、Snowflake、REST API、スプレッドシートに接続します。

このアーキテクチャには、多くの人が見落としがちな帰結があります。それは、結局のところ自前のバックエンドを用意して運用し続けなければならないということです。データベース、認証、シークレット、スケジューリング、サーバーサイドのロジックはすべて、別途自分でホスティングし保守すべきものです。ビルダーが提供するのは画面であって、その下で動くランタイムではありません。

シート課金の罠（そして閲覧者シートという落とし穴）

Retool の料金は、ビルダーと閲覧者に分かれたシート単位の課金です。Business プランではビルダーが $50/user/mo（年払い）、社内ユーザーが $15/user/mo、Team プランではビルダー $10、社内ユーザー $5 で、無料プランは 5 ユーザーが上限です。多くのチームが見落とすのは、閲覧者にも費用がかかることです。ツールを使うだけの人も、無料枠を超えればシート単位で課金されるため、コストは開発者の数だけでなく、利用者全体の規模に比例して増えていきます。さらにシート料金の上に、Retool は従量課金の要素も積み重ねます。従量制のワークフロー実行、繰り越し不可の AI クレジット、別建てで課金されるエージェント時間です。

つまり、みんなに使ってほしいツールが、まさにみんなが使うからこそ高くついていくのです。

ドラッグ&ドロップの限界

ビジュアルビルダーは、限界に突き当たるまでは速いものです。ローコードは必然的にカスタマイズの限界に達し、定番の対処法は「エスケープハッチ」、つまりカスタムコードブロックです。問題は、このエスケープハッチがたいてい制約されていることです。サーバーサイドランナーを持たずクライアントサイドの JavaScript しかサポートしないビルダーもあり、スタイリングはインライン CSS に限られ、フローチャート形式のワークフロー UI はロジックが増えるほど煩雑になっていきます。

この限界は、決まったところで顔を出します。カスタムなデータ変換やアルゴリズム、ホスティング済みサーバーを要する連携、そして既製コンポーネントを超えた UI です。さらに、アプリのロジックがベンダー独自のフォーマットに収められているため、ほとんどのビルダーはクリーンで人間が読めるソースコードをエクスポートできません。結果として、キャンバス内で作り上げたものを外へ持ち出すのは困難なのです。

オープンソースのセルフホストという選択肢

シート課金とベンダーロックインから逃れるために、まさにそのためのオープンソースというカテゴリーが存在します。Appsmith が最大規模（GitHub スター数万件）で、ToolJet、Budibase、Lowcoder、NocoDB がそれに続きます。セルフホストはコスト構造を変えます。たとえば Budibase は、SSO と埋め込みを含む無料のセルフホスト版で、Retool の 5 ユーザーに対して 20 ユーザーまで許可しています。

とはいえ、セルフホストにも手間はつきものです。デプロイ、保守、スケーリングには技術的な知見が必要で、有料版では依然としてプレミアム機能に制限がかかり、ほとんどのツールは同じドラッグ&ドロップ型のアーキテクチャを保ったままです。つまり、シート課金の請求書がなくなるだけで、限界とデータベース持ち込みの負担はそのまま引き継がれるのです。

AI ネイティブか、後付けの AI か

2025〜2026 年におけるこの市場の分かれ目は、AI を中心に設計されたプラットフォームと、既存のローコードアーキテクチャに AI 機能を後付けしたプラットフォームの違いにあります。Retool は AI エージェントと AI ワークフローを追加し、Budibase は LLM 連携ワークフローと AI cron ジェネレーターを追加しました。いずれの場合も、AI は独自のクレジットプールを持つ後付けのノードであり、AI が重要になる前に設計されたキャンバスの脇に置かれています。「このフィールドを要約する」といった単純な用途には十分ですが、モデルの呼び出しがコードの第一級プリミティブであるアプリとは本質的に別物です。

osFoundry の位置づけ

osFoundry はローコードのモデルを反転させます。社内アプリを、フルバックエンドを内蔵した、本物の所有できるコードとして構築するのです。アプリごとの Postgres、シークレット、KV、cron、サーバーレス関数、サブドメインが含まれるため、データベース持ち込みの負担もなければ、超えるべき限界もありません。コードそのものがエスケープハッチだからです。AI は後付けではなく、AI ネイティブです。`invokeAI` はアプリコードの第一級の呼び出しであって、別建てのクレジットプールではありません。料金は従量制でシート単位ではないため、閲覧者やビルダーを追加しても一人当たりの請求が膨らむことはありません。これこそシートモデルの典型的なコストの罠です。ドラッグ&ドロップキャンバスの代わりに本物のコードを選ぶことで、バックエンド、AI、データのすべてを、エクスポート可能な一か所にまとめて手にできます。

Frequently asked questions

Retool の最良のセルフホスト代替は何ですか？: ドラッグ&ドロップ型ビルダーの中では Appsmith が最大のオープンソースの選択肢で、ToolJet、Budibase、Lowcoder がそれに続きます。いずれもセルフホスト可能です。ドラッグ&ドロップの限界を完全に避けたいなら、バックエンド（データベース、シークレット、cron、関数）込みで本物のアプリを構築するコードファーストなプラットフォームが、データベース持ち込みの負担を取り除く別のモデルになります。ビジュアルなキャンバスが欲しいのか、本物のコードが欲しいのかで選んでください。
Retool はなぜこれほど高いのですか？: シート単位で課金され、しかも閲覧者まで数に含まれるからです。Business プランではビルダーが $50/user/mo、社内ユーザーが $15/user/mo で、さらに従量制のワークフロー実行、AI クレジット、エージェント時間が上乗せされます。コストはツールを作る人数だけでなく、使う人数に比例して増えるため、うまくいくほど高くつく構造になっています。
オープンソースの社内ツールビルダーには自前のデータベースが必要ですか？: ほとんどの場合、必要です。ドラッグ&ドロップ型ビルダーは別の場所にあるデータに接続するインターフェース層なので、データベース、認証、シークレット、スケジューリングは自分で別途プロビジョニングして運用することになります。アプリごとのデータベース、シークレット、cron を内蔵したプラットフォームなら、その運用負担を丸ごとなくせます。
ローコードのツールビルダーは本物のソースコードをエクスポートできますか？: たいていは、きれいにはできません。アプリのロジックがビルダー独自のフォーマットに収められているため、人間が読めるソースコードをエクスポートできるものはごくわずかで、移行が難航します。ロックイン回避が重要なら、作ったものが本物のコードであり、しかも持ち出せる標準的なデータベースが付いてくるプラットフォームを選ぶのが賢明です。
ドラッグ&ドロップ型ビルダーの限界に達したらどうなりますか？: エスケープハッチ、つまりカスタムコードブロックに頼ることになりますが、多くはクライアントサイドの JavaScript とインライン CSS に限られ、ロジックが増えると扱いにくくなるワークフロー UI になりがちです。限界はたいてい、カスタムなデータ変換、ホスティング済みサーバーを要する連携、標準コンポーネントを超えた UI といった場面で現れます。コードファーストなプラットフォームはそもそもコードとして始まるため、その限界に達することはありません。
Appsmith、ToolJet、Budibase は本当に無料でセルフホストできますか？: オープンソースのコアは無料で、セルフホストすれば無料ユーザー数の上限も上がります（Budibase は Retool の 5 に対して 20 ユーザーまで許可）。ただし、デプロイ、保守、スケーリングは自前で負担することになり、有料版では依然としてプレミアム機能や作成者ごとの料金に制限がかかります。「無料」はライセンスを指すのであって、運用にかかる総コストを指すわけではありません。
AI ネイティブなビルダーと、AI を後付けしたビルダーの違いは何ですか？: 後付け型の AI ビルダーは、AI が重要になる前に設計されたキャンバスの脇に AI ノードとクレジットプールを足すだけです。単純なフィールド単位のタスクには向いています。一方、AI ネイティブなプラットフォームはモデルの呼び出しをアプリコードの第一級プリミティブとして扱うため、AI は別ブロックに切り離されるのではなく、ツールのロジック全体に織り込まれています。